December 2018 - Pharo-users

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: > > WOW :) What part of it do you like? Cheers, Doru > On Thu, Dec 20, 2018 at 01:57 Tudor Girba <tudor(a)tudorgirba.com> 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 <luke(a)snabb.co> wrote: > > > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> 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. > > > > > > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)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-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)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."

Dec. 28, 2018

Re: [Pharo-users] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

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 > On Dec 28, 2018, at 11:32 AM, 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: > > <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, > > 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 <luke(a)snabb.co> 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 <luke(a)snabb.co> 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-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Every thing has its own flow." > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Dec. 28, 2018

Re: [Pharo-users] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

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 <luke(a)snabb.co> 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 <luke(a)snabb.co> 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-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Every thing has its own flow."

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Konrad Hinsen

Richard Sargent <richard.sargent(a)gemtalksystems.com> writes: > I understand your desire to utilize the existing Smalltalk mechanisms. But, > I think the most important thing is modelling consistency. > > What are the behaviours you expect from Expression, SumExpression, and > ProductExpression? Do they know their parent expression? Their children? > Other things? I certainly agree that this should be the main consideration, but in my case that's done. Each Expression subclass stored its own specific information, which for leaf nodes such as integer expressions is really just a value. All I need is integers with added behavior. > I think that, in general, you will benefit from fully and consistently > modelling the parse tree. I should have mentioned that my Expressions are not parse trees. They are used as values in symbolic computation. They are constructed and deconstructed all the time, which is one reason I want to eliminate overhead, the other reason being clarity of code. Konrad.

Dec. 28, 2018

Re: [Pharo-users] (no subject)

by Richard Sargent

On Thu, Dec 27, 2018 at 8:43 AM Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > Hi everyone, > > I am confronted with an implementation choice that I expect to be not so > rare, and I wonder what "the Pharo way" is for dealing with it. I will > use a toy example for illustration, my real case is more complex but not > fundamentally different. > > Suppose I want to represent arithmetic expressions that support various > operations (evaluation, simplification, compilation to whatever > language, ...). In the textbook discussion, I'd have a class hierarchy > such as > > Expression (abstract) > IntegerExpression > VariableNameExpression > SumExpression > ProductExpression > ... > > What I really want is not some IntegerExpression, but plain Pharo > integers, and for variable names I want to use plain Pharo symbols. > I understand your desire to utilize the existing Smalltalk mechanisms. But, I think the most important thing is modelling consistency. What are the behaviours you expect from Expression, SumExpression, and ProductExpression? Do they know their parent expression? Their children? Other things? What was their actual representation (source code)? 16rDEADBEEF may be more meaningful than 3735928559, for example. Likewise, 2r111110111101110110101 versus 2063285. Being able to reason fully about what was parsed will almost always be important. I think that, in general, you will benefit from fully and consistently modelling the parse tree. The actual evaluation is probably the smallest part of the problem. e.g. if every node implements #evaluate, it is easy to implement their operations. SumExpression would answer "self leftNode evaluate + self rightNode evaluate". IntegerExpression would implement is as "^self value" or something similar. > From my current understanding of Pharo, my options are > > 1. Use wrapper objects for integers and symbols, i.e. have a class > IntegerExpression that stores an integer in an instance variable. > > 2. Add the methods of my abstract Expression class to all the classes > representing integers and symbols. > > 3. Implement my own dispatch that does not rely on method lookup. > > None of these really looks attractive. 1) adds a lot of overhead, both > in the code ("IntegerExpression withValue: 5" rather than just "5") and > at runtime. 3) also adds a lot of overhead because I have to implement > my own dispatch. 2) would probably be the least effort, but looks like a > kludge. > > For comparison, in the Lisp world (CLOS, Racket, ...) that I know much > better, I would use generic functions and provide implementations for > integers and symbols as well as for my own Expression types. > > So... how would you approach this problem? > > Thanks in advance, > Konrad. > >

Dec. 27, 2018

(no subject)

by Konrad Hinsen

Hi everyone, I am confronted with an implementation choice that I expect to be not so rare, and I wonder what "the Pharo way" is for dealing with it. I will use a toy example for illustration, my real case is more complex but not fundamentally different. Suppose I want to represent arithmetic expressions that support various operations (evaluation, simplification, compilation to whatever language, ...). In the textbook discussion, I'd have a class hierarchy such as Expression (abstract) IntegerExpression VariableNameExpression SumExpression ProductExpression ... What I really want is not some IntegerExpression, but plain Pharo integers, and for variable names I want to use plain Pharo symbols. >From my current understanding of Pharo, my options are 1. Use wrapper objects for integers and symbols, i.e. have a class IntegerExpression that stores an integer in an instance variable. 2. Add the methods of my abstract Expression class to all the classes representing integers and symbols. 3. Implement my own dispatch that does not rely on method lookup. None of these really looks attractive. 1) adds a lot of overhead, both in the code ("IntegerExpression withValue: 5" rather than just "5") and at runtime. 3) also adds a lot of overhead because I have to implement my own dispatch. 2) would probably be the least effort, but looks like a kludge. For comparison, in the Lisp world (CLOS, Racket, ...) that I know much better, I would use generic functions and provide implementations for integers and symbols as well as for my own Expression types. So... how would you approach this problem? Thanks in advance, Konrad.

Dec. 27, 2018

Re: [Pharo-users] Subscribing to streaming input with ZnClient

by Sven Van Caekenberghe

Hi Kimmy, > On 27 Dec 2018, at 15:15, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > Hello, > > I am wanting to subscribe to a perpetual stream of JSON data in my app. I have failed to find an example which helps me understand how to do so. It may be there but I have not discovered it. > > How do I do something like that? A curl example from the website. > > curl \ > -H "Authorization: abcdefg?????" \ > > "https://stream-mystreamingsite.com/stream?query=whatIwant" > Response Headers > HTTP/1.1 200 OK > Access-Control-Allow-Headers: Authorization, Content-Type, Accept-Datetime-Format > Access-Control-Allow-Methods: PUT, PATCH, POST, GET, OPTIONS, DELETE > Access-Control-Allow-Origin: * > Content-Type: application/octet-stream > > > After subscribing to the stream I will need to get and access the JSON data so that my app can process it. > > Any help and wisdom greatly appreciated. > > Thanks. > > Jimmie The client and server part of the WebSockets extension to Zinc HTTP Components already supports similar functionality, so this is certainly doable. Unless you can give me a public end point to test, I can only write some untested pseudo code. | client reader | client := ZnClient new. client url: 'https://stream-mystreamingsite.com/stream?query=whatIwant'. client streaming: true. client headerAt: 'Authorization' put: 'xxx'. client get. reader := NeoJSONReader on: (ZnCharacterReadStream on: client contents). [ reader atEnd] whileFalse: [ reader next ]. reader close. client close. Be sure to tell us how you got it working. HTH, Sven

Dec. 27, 2018

Subscribing to streaming input with ZnClient

by Jimmie Houchin

Hello, I am wanting to subscribe to a perpetual stream of JSON data in my app. I have failed to find an example which helps me understand how to do so. It may be there but I have not discovered it. How do I do something like that? A curl example from the website. curl \ -H "Authorization: abcdefg?????" \ "https://stream-mystreamingsite.com/stream?query=whatIwant" *Response Headers* HTTP/1.1 200 OK Access-Control-Allow-Headers: Authorization, Content-Type, Accept-Datetime-Format Access-Control-Allow-Methods: PUT, PATCH, POST, GET, OPTIONS, DELETE Access-Control-Allow-Origin: * Content-Type: application/octet-stream After subscribing to the stream I will need to get and access the JSON data so that my app can process it. Any help and wisdom greatly appreciated. Thanks. Jimmie

Dec. 27, 2018

Re: [Pharo-users] GPS / Longitude / Latitude library

by Alistair Grant

Hi BenoÃ®t, On Sat, 22 Dec 2018 at 09:02, Benoit St-Jean <bstjean(a)yahoo.com> wrote: > > Hi Alistair! > > First off, thanks for the "thank you note" in this email & on GitHub. > > Would you be interested in working on a port of GeoSphere > (https://cran.r-project.org/web/packages/geosphere/geosphere.pdf) to > Pharo ? I'll have some spare time in the next weeks so we could work on > that together. Since this package is widely known and used, it could > serve as a base for a Geo package for Pharo. I have R installed with > this package here so cross-checking Pharo results vs R calculations > wouldn't be a problem! That also means plenty of unit tests are > possible ! ;) I'm happy to work on this together (and with whoever else is interested). Pharo is my hobby which has to fit in with family, etc., so my time is rather sporadic. > I noticed (at least on Pharo 6.1) that you reference "WebBrowser" which > is either present in P7 (and not in P6) or it indicates a dependency > problem. That's why I put "Pharo 7" in the installation section :-) I haven't tried, but I expect that loading WebBrowser in to Pharo 6 is straightfoward. With Pharo 7 about to go GA I have to admit that personally I'm not interested in putting much effort in to supporting earlier versions (other than a bit of testing, I haven't used Pharo 6 since it was released :-)). > I also noticed that you use the WGS84 reference ellipsoid as a hardcoded > constant (in other works, assuming the earth radius is 6378137 meters > for all calculations). Modifying the code to have reference ellipsoids > objects and use the WGS84 as the default (which is what everyone uses) > would be a more flexible solution. Actually, there's #haversineDistanceTo:radius: for exactly this reason (more below). > Besides, it would also allow funky > stuff like being able to use the same framework to work for every known > spatial body like say, the Moon or Mars or whatever! Besides, that way > (using reference ellipsoid objects), older maps/coordinates/calculations > could still be used just by changing the ellipsoid reference. At the moment the EarthRadius is a class variable. It would be better and more flexible to remove it and create separate objects for the different standards and bodies. > Let me know if you're interested! Sure. I had planned to extend this as required, but if you've got a particular approach I'm happy to try and fit in (within the time limitation mentioned above). > P.S. I couldn't find a similar package/framework for > Pharo/Squeak/WhateverSmalltalk. If I missed it, let me know guys!! I'm > not a big fan of reinventing the wheel!! Ditto. Cheers, Alistair > On 2018-12-19 02:32, Alistair Grant wrote: > > Hi All, > > > > If anyone is interested, I've created the beginnings of a library for > > handling coordinates at: https://github.com/akgrant43/GeoSphere > > > > It only: > > > > - Parses string coordinates > > - Calculates the distance between coordinates > > - Opens a web browser in OpenStreetMap at the receiver's coordinates > > > > Examples of string formats that can be parsed: > > > > - 144.61025 @ -38.28697 > > - 38Â° 17â² 13.09â³ S, 144Â° 36â² 36.9â³ E > > - 38 deg 17' 13.09" S, 144 deg 36' 36.9" E > > - https://www.openstreetmap.org/#map=18/-38.28697/144.61025 > > > > The distance calculation uses haversine (assumes the earth is a > > sphere), which is good enough for my needs at the moment. > > > > Thanks again to Sven, Benoit, Pierce and Richard for their input. > > > > Cheers, > > Alistair > > > -- > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >

Dec. 27, 2018

Re: [Pharo-users] Move methods to other class in P7/Calypso

by Denis Kudriashov

Hi. Use Drag&Drop for this. And create issue to add this operation into context menu if needed. ÑÑ, 26 Ð´ÐµÐº. 2018 Ð³. Ð² 14:14, Esteban Maringolo <emaringolo(a)gmail.com>: > What the canonical way of moving a set of methods from one class to > another? > > I couldn't find it in the contextual menu or in the refactorings. > > Regards, > > Esteban A. Maringolo > >

Dec. 27, 2018