On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: I'm feeling excited and confused :). Excited because I love seeing all these new demos streaming out and I'm itching to put new capabilities to work. Confused about the roadmap. How does this "new" Glamorous Toolkit relate to the "old" one that I learned about last year from the Moldable Tools thesis? Is this a new version or a complete rewrite? Is it backwards compatible or completely reimagined? Is adopting the new version a seamless process or is porting required? Are frameworks like Glamour still there behind the scenes or were they replaced? etc.

On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: [...] 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

And here is the tweet I was mentioning: https://twitter.com/feenkcom/status/1075011040373551104?s=21 Cheers, Doru -- www.feenk.com "Every thing has its own flow."

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."

Tudor Girba-2 wrote Does this mean it will offer Pharo an alternative UI (what I think you mean), or that the final product will not be Pharo-based? ----- Cheers, Sean -- Sent from: http://forum.world.st/Moose-f1310756.html

On 22/12/18 12:57, Offray Vladimir Luna Cárdenas wrote: I meant: the script requiring the GitHub credentials requirement was disabled

Hi Doru, On 21/12/18 17:40, Tudor Girba wrote: Thanks to you for this conversation. 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) 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. 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). 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

... Some comments and questions if I may: The "+" button to quickly maximize a panel is fantastic. I am often looking at complex visualizations that should really be full-screen and it was always too much trouble to "drag" them to full screen and back. Is the Spotter still a part of GToolkit? If not then what replaces it? (I can see that it is present in the image but Shift-Return doesn't seem to invoke it when the GTInspector window has focus.) Is it still possible to pan left-right between "miller columns"? I see the squares at the top representing panes but clicking and dragging them doesn't seem to do anything. How come a double-click is now needed to inspect an object? Is single-click going to have a new function? Once more - great work you guys are doing ! On Thu, 27 Dec 2018 at 11:06, Luke Gorrie <luke(a)snabb.co> wrote:

Thanks for the explanations! I like the separation between selecting (single-click) and spawning (double-click). The miller column panning is indeed working with a two-finger drag on the touchpad. I will need to test whether this gesture works when running GT on Linux and operating it on a Mac via VNC. That's the most common setup for our application. Spotter is not urgent for us. I have written some extensions for it but we aren't really using them much yet. If the inspector is working well then that's the main thing. I do have one very important Roassal visualization that I need to bring with me smoothly somehow. Question is whether to port if over to the new framework or somehow smoothly embed Roassal in the new GT? The visualization is for compile SSA intermediate representation code and looks like this: [image: Screen Shot 2018-12-28 at 11.25.06.png] There are some important properties about this diagram: - These are two digraphs stacked on top of each other. - Nodes are always placed below their parents. - Y-position indicates the max number of edges to reach parent nodes. - Extra edges (red) can create cycles and should be ignored for layout purposes. - Nodes can be compound shapes i.e. colored opcode and optionally fused immediate operands in white. - Each node is an object that can be selected and inspected in the next miller column. Can this be done in the new framework with similar effort to the old one? On Fri, 28 Dec 2018 at 09:46, Tudor Girba <tudor(a)tudorgirba.com> wrote:

Hi, The visualization you describe should be easily doable in the new world. Did you write the visualization in plain Roassal or with the RTMondrian API? Cheers, Doru -- www.feenk.com "The coherence of a trip is given by the clearness of the goal."

On Fri, 28 Dec 2018 at 14:03, Tudor Girba <tudor(a)tudorgirba.com> wrote: IIRC, I started with the Mondrian API, but switched to Roassal API to expose the functionality and extension points that I needed. Maybe wasn't necessary, I'm not sure, but Mondrian felt like a "middle man." So in the new universe I could try again to formulate it with Mondrian or otherwise switch to... is there a counterpart to Roassal? Here is the meat of the code for the visualization: https://github.com/studio/studio/blob/master/frontend/Studio-RaptorJIT/RJIT… It's not much. Separately there is some code for defining the shapes and colours of the nodes, and filtering which edges should be considered for the tree layout.

On 28/12/18 8:03, Tudor Girba wrote: And which parts you don't? I wrote a long mail regarding good and no so good parts of the new GT experience, including features possible forks, that I hope will be answered also in detail, to keep the big picture. Cheers, Offray

This post seems to have come through from the moose mailing list... moose-dev(a)list.inf.unibe.ch On Sat, 29 Dec 2018 at 02:59, Kjell Godo <squeaklist(a)gmail.com> wrote: Kjell, This is awkward. Some of your posts seem human produced... http://forum.world.st/unsolicited-package-cache-use-td5060335.html But such off topic poetry is not appropriate, doubly so since the above looks bot generated. There have been several incidents in the past where the community has requested your account be blocked in response to such posts. The key red flag for me is that you've never responded directly to requests to block your account. http://forum.world.st/The-Inbox-Tools-LM-828-mcz-tp5082873p5082979.html On Wed, 15 Aug 2018 at 06:14, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: http://forum.world.st/unsolicited-package-cache-use-tp5060335p5063447.html On Thu, 18 Jan 2018 at 19:09, Tudor Girba <tudor(a)tudorgirba.com> wrote: http://forum.world.st/NAtiveBoost-error-tp4788132p4840572.html On Sat, 1 Aug 2015 at 21:46, Marcus Denker <marcus.denker(a)inria.fr> wrote: On Sat, 1 Aug 2015 at 22:38, Marcus Denker <marcus.denker(a)inria.fr> wrote:

Hi, We have no interest in playing politics in any way. That is why we are making explicit both our aims and the ways in which we work. As I mentioned, we work as a team and our goal is specifically to offer a different alternative to approaching programming. At the moment, this is different from the goal of Pharo, although the two are likely not incompatible. Interestingly, this goal is not far from the work that happened around Moose. Humane assessment was born in the Moose context, and in fact, the first GT was developed for several years in the context of Moose as well. The most concrete thing that people see from our current effort is the new GT interface, but we are building other things as well. First, GT has tools inside that are interesting for other purposes. We mentioned recently Releaser, a new tool that we think solves a significant problem in Pharo. Also, the Examples engine might be interesting, too. And so is the Bloc stack in which we invested heavily. Less obvious is that we have created xdoc, a format and associated technology for sharing executable documents. We also develop the moldable development approach that is enabled by the new kinds of tools. From a concrete perspective, indeed, we are only relying on about half of the current Pharo (the language&runtime, but not the graphics&environment). At the same time, most code we build is available as open-source in ways that are compatible with Pharo both from a license and from a technical perspective. At present time, our code loads cleanly and works in the latest Pharo without any modifications required for Pharo. While we love working in Pharo, we are not the ones that decide its course, and we leave the decisions of what will happen with Pharo with the Pharo team. Cheers, Doru -- www.feenk.com "To lead is not to demand things, it is to make them happen."

Hi, Thanks for the link. For some strange reason, I do not see the linked email in my inbox. I am happy to hear that you could install GT. Indeed, that is a known problem: https://github.com/feenkcom/gtoolkit/issues/64 Interesting observation. The linked tools as all other notebook technologies I saw rely on two distinct modes for edit and view that reside in two distinct widgets (editor and viewer). They do that because they simply cannot have it in one. Because of the design of Bloc we are not constrained to that. Instead, we build a seamless interface that is both optimized for viewing, and for editing with live preview that does not rely on an explicit render button. This approach enables direct manipulation without friction, and we think this is a significant advancement in this space. About the remark related "to documents that embed pieces of documents, which embed pieces of documents”: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part? Interestingly, those extensions exist in the old Inspector as well. For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready. Indeed. These are known issues that we will tackle soon. Nice catch. Thanks. The path of the file is incorrect when the image is copied. We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke. I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments. What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, and we think this is trivially possible. About the roadmap, here it is: we aim to build a complete development environment that will enable moldable development. We understand how this can appear vague. I think it’s not because I and my colleagues talk about it since many years now. People pay little attention, so now we set ourselves to deliver a concrete incarnation of what we think the future should look like. We set to create something that does not exist in other parts, and we simply do not quite know how this will look like in details. For example, we do know that we want to build a Coder or a Debugger, we even have advanced ideas and implementations, but we do not know exactly how it will look like and because of that we also do not quite know how long it will take. We have a particular way of approaching development that relies on fast feedback and storytelling, and at the end we always get surprised of where the journey takes us. For example, the current state of Documenter was simply difficult to imagine even 4 months ago, and in the process we threw away more code than is now released. So, we will not detail the concrete steps because we do not work like that. We do have a clear vision of what we think software development should be, and we will put forward our guiding principles shortly. About the governance process: GT is built by feenk and will continue to be so for the foreseeable future. We put things that we create in the open, we do so for free, and we welcome people to engage with us. As mentioned above, our focus is to build a new experience. It is likely that a typical Pharo user will not have much issues adapting to the new interface. A developer that depended on the old APIs will be somewhat impacted, but we do not expect a too large effort will be required to adopt the new world. Nevertheless, if it’s stability and predictability you are looking for, it is best to wait for now. I do not think a new piece of code should be called a fork. At this point in time, GT and everything it comes with, loads cleanly in Pharo 7. Cheers, Doru -- www.feenk.com "No matter how many recipes we know, we still value a chef."