21 Dec
2018
21 Dec
'18
11:40 p.m.
Hi Offray,
Thanks for describing your concerns.
First, let’s address the technical part. Please go to gtoolkit.com and download the 64Bit
distribution that includes the image and the VM. We will remove the standalone image
option from the website until the VM situation gets clarified.
Now, a clarification. The old GT was produced over a period of 4 years by an open-source
team. The project had its own identity, and in 2014 the core of it was first integrated in
Pharo. I say the core of it, because the visual part and other libraries are not in Pharo
today. The full potential is found in Moose. In any case, during this process, GT got to
be identified with Pharo and that was a good thing.
The new GT is a product produced by feenk, a company. Much of the original team is still
active in the new version, but now we commit to our product in a different way. The
product is free and open-source, but it’s still a product with an identity and a goal. At
present time, both the team, identity and goal are different than those of Pharo.
Our goal is to offer a fundamentally new alternative to program (including comparing to
what is possible now in Pharo). We are not looking for marginal improvements, and we are
not aiming at backward compatibility.
To build this alternative we invested in a whole new stack. That is not a tiny challenge
and getting it right requires many iterations and feedback. We say we are in alpha not
because of inconveniences of installation but because we are still very much developing
the product.
We announced the first alpha version in September and since then much has changed. At
present time, we did manage to reach a situation where downloading the distribution should
run on Mac, Linux and Windows. Even so, the current version is only for people that do
want to try knowing that there will be hurdles.
A word about the user experience. The current version runs inside the Pharo UI because we
need to bootstrap. But, our goal is to build a complete IDE on the new stack. If you want
to judge the user experience, it is only meaningful to do it within the GT windows, and
not by comparing it with the rest of the existing Pharo UI.
Does this clarify the situation?
Cheers,
Doru
--
www.feenk.com
"Every thing has its own flow."
On 21 Dec 2018, at 23:02, Offray Vladimir Luna
Cárdenas <offray.luna(a)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. 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 <tudor(a)tudorgirba.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev 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-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev