Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Pharo Smalltalk Users mailing list wrote > My holy grail is a document that describes both software and > computations Yes!!! Capturing mindshare in the data analysis field would be *huge* for Pharo/GT because there are a lot of people who are new and view languages/environments as means to an end, and hence seem to be much less poisoned against blue plane ideas by years of Stockholm syndrome with obsolete but common technologies. - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- Hi Doru and Offray, Tudor Girba via Pharo-users writes: > A separate editor is needed when the markup has little resemblance > with the output, which is the case for HTML. In this case, > bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very > nice thing. Or when the output reflects only a part of the input document. I suspect Offray has the same kind of application in mind as myself, knowing a bit of his work, and it is indeed a bit different from what you are designing GT for. What we do (mainly) is documenting computations, not software. A computation consists of code, input data, and selected results. This inevitably requires some metadata that needs to be editable but should not necessarily appear in the output. The most basic technology for documenting computations is the notebook (Mathematica, Jupyter, ...) where the metadata is just the cell structure (which does show in the output). More sophisticated systems (Emacs OrgMode for example) allow more fine-tuning, making for much nicer output, but also requiring quite a bit more metadata. > However, in the case of Documenter and the Pillar markup the output is > closely related to the sources part. In this case, having the two >From what I know about Pillar, I agree. The way this is handled in Documenter is indeed very appropriate for very simple markup like that. And simple markup is highly desirable whenever sufficient. > worlds be supported seamlessly in the same experience is a huge > advantage, especially for non-technical people. The interface from > Documenter is not trivially possible (I for now never saw one like > that, and I looked specifically for it) because of the prerequisites The closest I have seen is MarkText: https://marktext.github.io/website/ Its "focus mode" works much like Documenter in principle, but feels less fluent somehow. Offray Vladimir Luna Cárdenas via Pharo-users writes: > but is not their only concern. ATM seems that new GT is pretty tied to > Pillar and software documentation (which is fine, but not the path I'm > primarily interested). Me neither, but I still find a lot of interesting ideas in GT and I suspect that a tool closer to my interests could be built with reasonable effort from the bricks that GT provides. My holy grail is a document that describes both software and computations, combining the features of notebooks and literate programming into a hypertext-like system in which I can start at the surface (the computation) and "zoom in" to any part of the software, getting documentation and not just source code. Cheers, Konrad. --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- Hi, Thanks Konrad for the Sketch-n-Sketch link. I think that you hit the point about having multiple editors and views for the same object. I think that for interactive documentation that goes beyond software, that is needed, specially when you are targeting single source input and multi device/format output (like here [1]). Several Markdown variants are targeting such scenario, that includes interactive documentation, but is not their only concern. ATM seems that new GT is pretty tied to Pillar and software documentation (which is fine, but not the path I'm primarily interested). [1] https://mutabit.com/repos.fossil/mapeda/ I will see what future Pharo 7 based toolkits bring on that front. Cheers, Offray On 1/1/19 16:50, Tudor Girba via Pharo-users wrote: --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
--- Begin Message --- Hi, A separate editor is needed when the markup has little resemblance with the output, which is the case for HTML. In this case, bidirectional editing, as shown in Sketch-n-Sketch, is indeed a very nice thing. However, in the case of Documenter and the Pillar markup the output is closely related to the sources part. In this case, having the two worlds be supported seamlessly in the same experience is a huge advantage, especially for non-technical people. The interface from Documenter is not trivially possible (I for now never saw one like that, and I looked specifically for it) because of the prerequisites it needs from underlying graphical framework, but I do think it’s a significant step forward in the notebooks space. Cheers, Doru > On Jan 1, 2019, at 8:01 PM, Konrad Hinsen wrote: > > Hi Offray and Doru, > > allow me to chirp in on a topic that I have been thinking about for a > while: > >>> 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. > >> I don't think is only because other editors can't do it, but because >> some (most) times you don't want "to conflate two tasks that are >> /conceptually/ distinct and that, to ensure that people's time is used >> most effectively and that the final communication is most effective, >> ought also to be kept /practically/ distinct"[1] which are Composition >> and typesetting. > > Two remarks. > > First, this is a special case of the more general issue of having > multiple views and even multiple editors for a single object. No matter > what you believe to be the best approach to editing text with markup, in > many other situations it is clearly desirable to have multiple > views/editors side by side, and I have regretted more than once that > this doesn't seem to be possible in Pharo's inspector. > > For multiple editors the need to have them side by side is probably more > obvious than for mere views, so it may be useful to look at practical > examples and see how one would realize them in Pharo and/or in GT. One > of my favorite applications is graphics that are generated by program > code but can also be edited graphically, as implemented in > Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/). > You definitely want the two panes, code and graphics, side by side. > > Second, the example of editing text with markup also illustrates that it > matters if views are complete (i.e. show all the available data) or > partial, and if they are invertible, i.e. if a change in an editable > view can be translated unambiguously into a change in the underlying > data. Markup with comments, as mentioned by Offray, is a case in which > the rendered view is partial but nevertheless invertible, so it makes > sense to have two types of editors, one for the raw markup text and one > for the rendered version. Some people may want both side by side, > whereas others may prefer a single one with the possibility to switch, > depending on how important the non-rendered information is. > > Scientific data visualization provides plenty of interesting examples by > the way, often with the additional challenge of significant > computational cost in rendering. > > Konrad. > -- www.feenk.com "Innovation comes in the least expected form. That is, if it is expected, it already happened." --- End Message ---
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi Offray and Doru, allow me to chirp in on a topic that I have been thinking about for a while: >> 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. > I don't think is only because other editors can't do it, but because > some (most) times you don't want "to conflate two tasks that are > /conceptually/ distinct and that, to ensure that people's time is used > most effectively and that the final communication is most effective, > ought also to be kept /practically/ distinct"[1] which are Composition > and typesetting. Two remarks. First, this is a special case of the more general issue of having multiple views and even multiple editors for a single object. No matter what you believe to be the best approach to editing text with markup, in many other situations it is clearly desirable to have multiple views/editors side by side, and I have regretted more than once that this doesn't seem to be possible in Pharo's inspector. For multiple editors the need to have them side by side is probably more obvious than for mere views, so it may be useful to look at practical examples and see how one would realize them in Pharo and/or in GT. One of my favorite applications is graphics that are generated by program code but can also be edited graphically, as implemented in Sketch-n-Sketch (https://ravichugh.github.io/sketch-n-sketch/). You definitely want the two panes, code and graphics, side by side. Second, the example of editing text with markup also illustrates that it matters if views are complete (i.e. show all the available data) or partial, and if they are invertible, i.e. if a change in an editable view can be translated unambiguously into a change in the underlying data. Markup with comments, as mentioned by Offray, is a case in which the rendered view is partial but nevertheless invertible, so it makes sense to have two types of editors, one for the raw markup text and one for the rendered version. Some people may want both side by side, whereas others may prefer a single one with the possibility to switch, depending on how important the non-rendered information is. Scientific data visualization provides plenty of interesting examples by the way, often with the additional challenge of significant computational cost in rendering. Konrad.
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi Doru, On 29/12/18 15:50, Tudor Girba wrote: > Hi, > > Thanks for the link. For some strange reason, I do not see the linked email > in my inbox. It was also absent from the web archives of the Pharo mailing list and, as I'm not subscribed to Pharo-Dev I always get a warning about a rejected message (I don't know if this is related somehow to the mails being hard to find). Anyway, I'm hitting "Reply all" button so you'll have the answers from this thread also in your personal mail (and have stopped cc to Pharo-Dev). > > I am happy to hear that you could install GT. > Thanks. >> * 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). > Indeed, that is a known problem: > https://github.com/feenkcom/gtoolkit/issues/64 Maybe the main window should indicate more promptly about expected but strange behaviors and point to the Issues repository, somehow. > >> * 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). > 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. I don't think is only because other editors can't do it, but because some (most) times you don't want "to conflate two tasks that are /conceptually/ distinct and that, to ensure that people's time is used most effectively and that the final communication is most effective, ought also to be kept /practically/ distinct"[1] which are Composition and typesetting. This seems kind of strange in interactive documentation, because of the bad habits that WYSIWYG word processors installed on authors, but most of the time What You See Is **Only** What You Get, but you need enable comments to yourself, use admonitions, refer to bibliographic keys, and so son. That's why I think is a healthy practice to separate both, composition and typeseting and think in a bi-modal way, instead of a conflated way, in a similar fashion to what Bret Victor demos show for working with graphics and code in a bi-modal way [2][3]. I have experience, first hand, in "documentathons" using CodiMD, how document authors could benefit from bi-modal thinking for their documents, by showing side by side, Markdown and the rendered document changing in real time. I would like something similar for the Pharo environment. [1] http://ricardo.ecn.wfu.edu/~cottrell/wp.html [2] http://worrydream.com/#!/InventingOnPrinciple [3] https://i.imgur.com/vi6bX21.png [4] https://en.wikipedia.org/wiki/GNU_TeXmacs TeXmacs[4] has a really good What You See Is What You *Mea*n (WYSIWYM) editor that conflates composition and typography, but it works like a charm, specially while you're writing mathematics that I have not seen elsewhere (not even in comercial word processors). But when you start to push boundaries (for example by using non traditional templates) the visual approach shows its limits compared to a bi-modal editor. > > 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? > Some times when I was browsing the examples I made click on an icon that shows the
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
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. > * 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). Indeed, that is a known problem: https://github.com/feenkcom/gtoolkit/issues/64 > * 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). 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? > * 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). Interestingly, those extensions exist in the old Inspector as well. > * 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). 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. > * 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). Indeed. These are known issues that we will tackle soon. > * The default data science example didn't work at all > [8](https://i.imgur.com/YhNb8el.png) Nice catch. Thanks. The path of the file is incorrect when the image is copied. >> 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
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi Doru, This one is still pending: https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html Of course we have slow days at end of year and I don't expect immediate answer, but now that discussion was active is good to point some pending conversation, even to be taken after holidays. Cheers, Offray On 29/12/18 6:38, Tudor Girba wrote: > Hi Offray, > > I believe I replied to all your emails. If I missed one, please point me to > it. > > Cheers, > Doru > > >> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas >> wrote: >> >> >> On 28/12/18 8:03, Tudor Girba wrote: On Dec 28, 2018, at 1:08 PM, Kjell Godo wrote: WOW >>> :) >>> >>> What part of it do you like? >>> >>> Cheers, >>> Doru >> 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 >> >> >> > -- > www.feenk.com > > "You can inspect and adapt only what is explicit." > >
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi Offray, I believe I replied to all your emails. If I missed one, please point me to it. Cheers, Doru > On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna Cárdenas > wrote: > > > On 28/12/18 8:03, Tudor Girba wrote: >>> On Dec 28, 2018, at 1:08 PM, Kjell Godo wrote: >>> >>> WOW >> :) >> >> What part of it do you like? >> >> Cheers, >> Doru > > 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 > > > -- www.feenk.com "You can inspect and adapt only what is explicit."
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
> On Dec 28, 2018, at 1:08 PM, Kjell Godo wrote: > > WOW :) What part of it do you like? Cheers, Doru > On Thu, Dec 20, 2018 at 01:57 Tudor Girba wrote: > Hi Luke, > > I am happy this looks exciting :). > > About the confusion part: The Glamorous Toolkit we are working on right now > is a complete new world built on a complete new graphical stack that does is > not based on the existing stack that ships with Pharo. It is not an > evolution. It is a leap. > > 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. > > But, in the new world, we are bringing the concept much further. For example, > Documenter provides a whole new kind of a tool that can mold to unify > multiple workflows (like data notebooks, code documentation, or tutorials) > right in the IDE. Coder provides the infrastructure for manipulating code > that can mold its shape as you type. Transcript allows you to embed various > widgets to transform the otherwise dull experience of a console into a live > one. > > Behind the scenes GT comes with several engines. The Examples engine enables > example-driven development which also bridges the gap between testing and > documentation effort, especially when combined with Documenter. Releaser is > able to release deeply nested projects. Phlow offers an engine that shares > similarities with Glamour. Completer provides moldable completion. Visualizer > offers a couple of visualization engines such as Mondrian. > > All of these are possible because of the underlying graphical stack made of > Sparta/Bloc/Brick. > > All in all, we believe that the new GT enables a new way of programming. > Individual features can be attractive, but our goal is to reshape the > development experience. > > Does this address the concern? > > Cheers, > Doru > > > > On Dec 19, 2018, at 2:09 PM, Luke Gorrie wrote: > > > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba wrote: > > Please do let us know what you think .. and, of course, what you feel. > > > > 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. > > > > > > ___ > > Moose-dev mailing list > > moose-...@list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." > > ___ > 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 -- www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi, Thanks for the feedback! I am happy you like the new possibilities and that you see the incentives to move to the new world :). The inspector part is working quite well. The main reason we call it an alpha is because of the missing pieces to get to a full environment. You noticed the issue of Spotter. The existing Spotter is the one that is included in the old GT and it lives in the Morphic world. When the focus is in the new inspector, that means that keybindings are handled by Bloc and this is a separate world from Morphic. At present time, we can embed Bloc in Morphic but not the other way around as we want no binding from Bloc to Morphic. For this reason, unhandled keys are not propagated from Bloc to Morphic and that is why pressing Shift+Enter does not open Spotter. So, we will have a Spotter, but that will be another implementation. Other unfinished tools are the Debugger and Coder, but these are likely less relevant for your use case. A few other missing pieces: - some widgets such as a tree are not yet implemented. So, we do not yet have a tree view in inspector. - the text editor requires a few enhancements for navigation support. - scrollbar The Miller-columns interface can be scrolled with the touchpad left-right. Can you confirm? About clicking vs double-clicking: Indeed, we now distinguish between selecting and spawning. As soon as there is a page to the right, selecting will populate that page. However, if there is no page to the right, simply selecting in a list will not spawn, like in the old inspector. Like this, you can work on a page without the page scrolling from underneath you. Please note that between pages we have triangles which are actually buttons. Selecting in a list shows a triangle. Clicking on the triangle spawns. So, you can either double-click to spawn, or you can select and then click on the triangle. Once spawned, simple selection is enough. Does this clarify the situation? About Roassal: In the new GT we have GtMondrian which is similar to the one from Roassal. We do not yet have support for creating charts (like bar or line charts). About the porting strategy: When you have the new GT loaded, the old Inspector will get a _GT pane that will essentially embed the new views in the old inspector. These also allow for interaction. Like this, you can port at your pace and switch only when you are ready. Cheers, Doru > On Dec 27, 2018, at 11:36 AM, Luke Gorrie wrote: > > ... 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 wrote: > Hi Doru, > > Thank you very much for the detailed explanation. > > I have spent some time with the alpha now. I think it is absolutely fantastic! > > I love the new narrative style of the UI. This ties everything together > beautifully and makes it easy to explore. That's really what I am lacking in > my application. Currently it simply opens to a blank quasi-playground and it > is not obvious what to type or how to get started. I started writing a > separate HTML manual but I don't think that's the right medium -- much better > with something interactive in the image like the Documenter. > > Just clicking around everything seemed to work basically smoothly for me. > Maybe it's already time for me to port over to the new GT? Or what do you > think the most likely obstacles would be in transitioning to this alpha > version? > > Currently my custom inspector extensions are mostly based on Roassal and > List/Tree/Table views. I also have one or two Glamour browsers. Is that all > still there in one form or another? > > > ___ > Moose-dev mailing list > moose-...@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Every thing has its own flow."
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
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." > On 21 Dec 2018, at 21:32, Tudor Girba wrote: > > Hi, > > Thanks for detailing your thoughts. > > Indeed, I know about your application. Whatever you can do with the current > GT you will be able to do with the new one. > > Except that for the new one you will be able to do extra things. Here are a > few: > - You can build and share documents that embed those inspector views. This > can be useful for reporting or sharing diagnostics with your users. > - Because the underlying rendering engine is much more powerful, you can > express modern and interfaces that integrate with the rest of the environment > smoothly. > - You likely have to deal with log files that might get large. First, the new > editor allows you to smoothly work with such files. But, you can go well > beyond this. Imagine that you build a tooling that produces the same editor > only the text is interactive, and you might even embed visual artifacts right > in the text to bridge the gap between what you would see in a typical > console. For example, this tweet shows the new Transcript used to debug an > animation. For every animation frame, we output the text corresponding with > the frame and we insert the graphical preview corresponding to that step. > > You look at GT from the point of view of an end-user. You likely like the > fact that you could mold the environment to your context and that you could > do this incrementally. It happens that the same principles and tools can be > applied to the whole programming, and once you do that, you actually can > fundamentally change the act of programming. In fact, the same thing applies > to the old GT: we built the new GT using that version and we believe that > this allowed us to work much faster than if we would have used more > traditional tools. The new GT pushes the envelope significantly further. > > So, that is why we are excited about that perspective, but even if you do not > spend much time programming in Pharo, you can still take advantage for the > user point of view as described above :). > > Is this answer better? > > Cheers, > Doru > > > >> On Dec 21, 2018, at 4:59 PM, Luke Gorrie wrote: >> >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba 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 > > -- > www.feenk.com > > "Being happy is a matter of choice." > > > > >
Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0
Hi, Thanks for detailing your thoughts. Indeed, I know about your application. Whatever you can do with the current GT you will be able to do with the new one. Except that for the new one you will be able to do extra things. Here are a few: - You can build and share documents that embed those inspector views. This can be useful for reporting or sharing diagnostics with your users. - Because the underlying rendering engine is much more powerful, you can express modern and interfaces that integrate with the rest of the environment smoothly. - You likely have to deal with log files that might get large. First, the new editor allows you to smoothly work with such files. But, you can go well beyond this. Imagine that you build a tooling that produces the same editor only the text is interactive, and you might even embed visual artifacts right in the text to bridge the gap between what you would see in a typical console. For example, this tweet shows the new Transcript used to debug an animation. For every animation frame, we output the text corresponding with the frame and we insert the graphical preview corresponding to that step. You look at GT from the point of view of an end-user. You likely like the fact that you could mold the environment to your context and that you could do this incrementally. It happens that the same principles and tools can be applied to the whole programming, and once you do that, you actually can fundamentally change the act of programming. In fact, the same thing applies to the old GT: we built the new GT using that version and we believe that this allowed us to work much faster than if we would have used more traditional tools. The new GT pushes the envelope significantly further. So, that is why we are excited about that perspective, but even if you do not spend much time programming in Pharo, you can still take advantage for the user point of view as described above :). Is this answer better? Cheers, Doru > On Dec 21, 2018, at 4:59 PM, Luke Gorrie wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba 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 -- www.feenk.com "Being happy is a matter of choice."
