On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna Cárdenas <offray.l...@mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the > PhD thesis is practically done and only dissertation is pending, I would like > to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, > stability, improved functionality, Iceberg for code management (but > supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like > some of them going into interactive documentation (a line I was trying to > explore with Pharo using Grafoscopio). But anytime I tried to use it I > stumble upon a stop: > > First time was something related with me having some kind of credential > enabled in GitHub to simple use it. I lost a whole morning just enabling that > and reporting it.
Was this on Windows? What was the fix for worked for you? (sorry its easier to ask again than try to identify in the archives a previous mention) cheers -ben > It was related with some mozilla library for font redering that didn't work > well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an > error message about inability to determine proper VM and when I tried > installing it from Pharo 7 I got something related with a > MemoryFileWriteStream dependency to be resolved before proper installation. > > I understand that this is alpha software and demos look amazing, but just > running them requires a lot of work that previous GT didn't require. > > This brings me this feeling that these jumps in Pharo put core of the user > experience at risk (kind of) and you end wondering how much an old tech will > be maintained once the jump to the new shinny stuff is done and which is the > migration path. > > In my case, I would like to have something like a Zeroconf script that just > takes care of the external libraries, VM and image, to have a real glipmse of > the upcoming future, beside the Tweets (which look great BTW). Maybe it will > happen in a year or two, once it is properly integrated with Pharo, Zeroconf > and thought for "end users" of interactive documents, which don't want to > enable GitHub stuff, deal with external rendering dependencies and so on. Now > the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will > reach the beta status, where users like myself can use it smoothly and build > on GT's promises and interesting features. > > Cheers, > > Offray > > On 21/12/18 10:59, Luke Gorrie wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tu...@tudorgirba.com> wrote: >> >> The goal of the new GT is to propose a completely reshaped programming >> experience that enables moldable development. You will find the concepts >> from the old GT in the new world as well. For example, the Inspector is >> extensible in similar ways and the API is similar as well. > > [...] >> >> Does this address the concern? > > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an object > inspector (etc) for examining diagnostic data. We have a Smalltalk > application that's similar to GDB and we are using GT as the front-end. > > In our world we use the Inspector and the Spotter but all of the Smalltalk > programming views are hidden. GT is "molded" to be a diagnostic tool *instead > of* a programming environment. Specifically, our main use case is > inspecting/debugging the operation of a JIT compiler written in C. We have > Smalltalk code to load binary coredumps from the JIT, decode them using DWARF > debug information, and represent the application-level compiler data > structures as Smalltalk objects. This way we can use GT to browse generated > code, cross-reference profiler data, examine runtime compilation errors, etc. > > The "old" GT is awesome for this. I feel like this application is also very > much in the spirit of the "moldable tools" thesis. Lots of diagnostic > workflows ultimately boil down to drill-down inspecting and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am talking > about diagnostics, you are talking about programming. I am talking about > zeros and ones, you are talking about feelings. I am maintaining a stable > application, you are talking about rewrites. I am having a hard time whether > I should be switching to the new GT in the immediate future, or waiting > another year or two for it to mature, or planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of the most > interesting work in the programming universe to my mind. I hope that this > discussion is useful for at least understanding the thought process of some > users / potential users. > > Cheers! > -Luke > > > > _______________________________________________ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev
