Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0
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@tudorgirba.com <mailto:tudor@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-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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@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@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-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Hi Doru, On 21/12/18 17:40, Tudor Girba wrote:
Hi Offray,
Thanks for describing your concerns.
Thanks to you for this conversation.
First, letâs address the technical part. Please go to gtoolkit.com <http://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.
On the technical side, the 64Bit distribution in the smoothest installation of the new GT I had have so far. Just unzip it and launch the image and you are done! After that you are welcomed with a nice welcome window with beauty typographical render and you can explore what the GT has to offer and experience its potential first hand, which still brings kind of a mixed experience: * The new interfaces and some demo of the graphical elements look pretty good * After just some operations including window resizing I just get the Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png). * I like the little triangles to expand thing in the document and the run buttons for embedded code, and the "embeddability" of elements in the document in a tree like fashion, which of course could lead to documents that embed pieces of documents, which embed pieces of documents... But the dual panel view of code in one side with results in the right panel of old GT didn't tend to create such "recursion". This dual modal view is the same of Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi) for interactive documentation and I would like to see examples more in that line... but I don't know how it suits the philosophy behind Documenter, which seems more aligned to a modal non dual view of the document where you enter into edit mode once you click a piece of the document and into a view mode once you are out of it (instead of the proposed dual view). Would be nice to see is such dual view can be used to directly operate on the rendered view and see changes in the markup (i.e resizing an image in the rendered view changes the value on the edit view). * I like the different view that a document can have, markup wise: Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the authoring part [4](https://i.imgur.com/Jc1T5Rm.png). * Its difficult to travel between the panels of a playground. Previously you just make click in the lower circle representing the panel you want to go at it was done [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper rectangle representing such panel has no effect [6](https://i.imgur.com/8Obo3Ct.png). * Auto-completion and shortcuts for selecting text doesn't work well on code cells of the new playground. Selecting whole words with Ctrl arrow doesn't work, neither using down arrows to choose from suggestions and even you can end with previous suggestions floating around your playground [7](https://i.imgur.com/4awyIft.png) [8](https://i.imgur.com/7qXc64b.png). * The default data science example didn't work at all [8](https://i.imgur.com/YhNb8el.png)
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.
I used Moose to build the first Grafoscopio versions, but there was a lot of stuff that was related with software analysis that I didn't really need for reproducible interactive documentation and publishing nor for data science, activism and storytelling. So once old GT was integrated into Pharo with Spec I used a more minimal setup to deliver a more focused experience. I think that most times this relationship between Pharo and Moose can be of creative tension, one pushing the boundaries and the other offering a more stable experience where the innovations of the former are integrated and debugged. But even after using Moose as a fully integrated vision of what old GT have to offer in the back and front end, I didn't see any migration path from previous Moose with the old GT to the current GT, which is kind of worrisome. I understand the idea of forks in FLOSS as a way of dealing with politics behind the FLOSS movement and the relationship between different visions and actors (individuals, communities, enterprises, foundations, associations and so on). It has happened before with Squeak, Pharo and Cuis and I'm fine with that. And I understand that a healthy relationship with the past means sometimes to break with it and jump into the future. That's why I think that the role of for profit and non for profit institutions is to balance a sense of momentum and stability around FLOSS. I would like to see a more clear road map for GT, knowing ahead where backward compatibility will be broken and why, which are the visions and, more importantly, how to participate and where are the boundaries. These are difficult tasks, but if the participation and boundaries are explored collectively, you can also know about the first ones (visions, versions, forks, compatibility). In that sense I think that Pharo is putting a good example: we have a clear road map document and participation process in the public repositories, there are public channels for users and developers and the private companies know about them, so they can put the boundaries about what is going to be done in the open, with the community, and what is to be kept closed inside company's frontiers and channels and the company's own velocity. I don't know if Feenk is planing something similar for its new vision, product and identity, and I don't know if the new alternative will have its own non-profit organizations as a neutral entity for all players using GT, but would be good to know about that, not because there are not people willing to jump into the future, but we would like to know to which future we're jumping on. Without that I think that is a safer bet for myself to rely on Pharo and see how migration paths could ensure compatibility with my own past and the one of my local community using Pharo and GT based tools. I hope that the open source nature of both products (Pharo and new GT) will ease the cross-pollination of the more interesting ideas, even without sharing code, visions or UI.
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.
I think that not only installation inconveniences is related alpha, but also this jumping from old GT to new one without a clear migration path (as is expected from alpha software and processes). I'm fine with that too, but I think that once the new GT reaches beta status the backward compatibility should be more important and meanwhile the non regard of that should be stated more promptly for previous and future GT users. I imagine that, at some point Feenk will provide its users and customers with clear support and migration paths regarding its open source products (kind of what happens with Canonical and the Long Term Support versions of Ubuntu).
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
Yes, it does. It seems that a fork is coming, at least UI wise regarding Pharo and new GT, but if the community knows about it, I'm fine with that. I think this thread also clarifies what active users of old GT will expect from upcoming versions of new (non alpha) GT regarding compatibility, open processes, visions and so on. Hopefully we will reach that place together. Cheers, Offray
On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna Cárdenas <offray.luna@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 <tudor@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-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Fri, 21 Dec 2018 17:02:48 -0500 Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
Iceberg for code management (but supporting Fossil instead of Git).
Fossil support in Iceberg is going to be officially supported? Sincerely, Gour -- A person who has given up all desires for sense gratification, who lives free from desires, who has given up all sense of proprietorship and is devoid of false ego â he alone can attain real peace.
On 22/12/18 10:44, Gour wrote:
On Fri, 21 Dec 2018 17:02:48 -0500 Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
Iceberg for code management (but supporting Fossil instead of Git). Fossil support in Iceberg is going to be officially supported?
I don't know yet, but I would like to use Tonel and some import/export tools to use Fossil as my backend for file based storage instead of Git. I think that the Git migration tool can be used for that (adding some Fossil<->Git) scripts. These days are particularly slow in Colombia, but I will post advances as soon as I have something.
Sincerely, Gour
Cheers, Offray
On Sat, 22 Dec 2018 12:53:16 -0500 Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
I don't know yet, but I would like to use Tonel and some import/export tools to use Fossil as my backend for file based storage instead of Git.
I can fully understand you - using Fossil is so easy and safe in comparison with Git where one never knows...
These days are particularly slow in Colombia, but I will post advances as soon as I have something.
Thank you. Btw, I looked at Grafoscopio and it is interesting you had been looking or using tools like Leo editor, Pollen - I also considered Skribilo (Guile) - since I am also searching some toolchain to improve web publishing (paper output is not problem with LateX or ConTeXt) , but still haven't decided what to use/learn since learning Racket/Pharo requires some extra time until it can pay off (I want to stay focused on my writing and studying and not turn myself into programmer)...for now I'm still using Emacs/markdown-mode although in the past I spent time with both AÑciidoc(tor) and rst markups. Sincerely, Gour -- The senses, the mind and the intelligence are the sitting places of this lust. Through them lust covers the real knowledge of the living entity and bewilders him.
On 23/12/18 3:21, Gour wrote:
On Sat, 22 Dec 2018 12:53:16 -0500 Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:
I don't know yet, but I would like to use Tonel and some import/export tools to use Fossil as my backend for file based storage instead of Git. I can fully understand you - using Fossil is so easy and safe in comparison with Git where one never knows...
Yes. I think that DVCS wise, developers imagination has been monopolized by Git/GitHub. There are powerful simple little tools out there that are practically outside of the developers' radar. Let's see what happens in the Fossil + Pharo integration front.
These days are particularly slow in Colombia, but I will post advances as soon as I have something. Thank you.
Btw, I looked at Grafoscopio and it is interesting you had been looking or using tools like Leo editor, Pollen - I also considered Skribilo (Guile) - since I am also searching some toolchain to improve web publishing (paper output is not problem with LateX or ConTeXt) , but still haven't decided what to use/learn since learning Racket/Pharo requires some extra time until it can pay off (I want to stay focused on my writing and studying and not turn myself into programmer)...for now I'm still using Emacs/markdown-mode although in the past I spent time with both AÑciidoc(tor) and rst markups.
I looked also at Skribilo in my search for more powerful tools for interactive writing and documentation, and Emacs/OrgMode (see [1]). I really liked the Racket approach of a meta programming tool for making Domain Specific Languages (like the ones used for documentation). But in the development front I think that Pharo/Smalltalk is hardly beaten by anything, more if you're thinking not only in publishing (web, mobile or print) but also in agile data visualization (see [2]). In that regard becoming a coder was a valuable deviation from my research and study that paid huge reward later in those fronts also. [1] https://duckduckgo.com/?q=devops+org+mode&atb=v76-7&iar=videos&iax=videos&ia... [2] https://vimeo.com/94724841 Is good to see more interest in interactive documentation in this community. It seems that good times are coming. Cheers, Offray
participants (4)
-
Ben Coman -
Gour -
Offray Vladimir Luna Cárdenas -
Tudor Girba