January 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [squeak-dev] [ANN] OpenSmalltalk VM Meeting

by Ben Coman

On 16 January 2018 at 05:27, Fabio Niephaus <lists(a)fniephaus.com> wrote: > Dear all, > > The OpenSmalltalk VM Meeting will be held this Wednesday, 17th January, 5pm > - 6pm CET. Click [1] for a quick timezone conversion. That timezone converter didn't work for me. Here is another... https://www.timeanddate.com/worldclock/meetingtime.html?iso=20180117&p1=195… Click "Change cities" to add your own. cheers -ben > Please find the link to a public Google Hangout in the Google Doc at [2]. > The document also includes a preliminary agenda, feel free to leave any > comments. > > See you on Wednesday! > > Fabio > > [1] > http://www.thetimezoneconverter.com/?t=5pm&tz=CET%20(Central%20European%20T… > [2] > https://docs.google.com/document/d/1nu3JLDvxJqKbDv1DsQoREtXPJNnqB-adB5zC-Uh… > > >

Jan. 15, 2018

Re: [Pharo-dev] [Moose-dev] [ann] gt connector

by Ben Coman

On 15 January 2018 at 05:54, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Towards the end of last year we worked on GT Connector, a new kind of > interface that allows us to exercise and test the limits (or the lack > thereof) of Bloc. > > It looks like this: > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 > > In the current implementation, the Connector allows us to navigate and > connect example methods. The focus is not on examples, but on the > connections. We used examples because the engine was already around and > offered us a nice use case. We want to extend it in the near future to > other kinds of objects. > > There are a couple of things that are worth noting: > â¢ The editor works live, and the connection points appear and disappear as > you type. > â¢ The layout of the editor elements is based on a tree-based graph layout > that only works with constrains (no actual visible edges between the editor > elements). > â¢ The editor works live, so adding new elements to the scene properly > rearranges the scene. > â¢ But, perhaps, the most exciting part is the fact that the lines connect > an element from inside the text editor element with another that lives > outside of the editor element. > > All these validate the architecture of Bloc of having exactly one > rendering tree. It was not an obvious goal a couple of years ago, but we > are really happy that it works. > > To put it in perspective, let's compare this with the html world. Text is > text is rendered through the DOM tree. If you want graphics you might > use something like SVG which comes with its own tree. However, these are > two distinct worlds, and you cannot go from one to another, or at least > not easily. This is the case in most engines we looked at. > Thanks for this review. Its good to get a peek behind the curtain to understand what has been learnt (wrong and right) that feeds into the design. > > Why is this important? One thing we learn in the Smalltalk world is that > covering the same space with less concepts opens up a whole dimension > of creativity that is simply not possible outside of it. > > The goal with Bloc is to enable new kinds of user interfaces. As we are > late to the game of modern interfaces, even though the field was invented > in Smalltalk, our only chance to take the lead again is to rethink the > model. > > Let's look at the Connector again. In most user interfaces we have panes > on the outside, and visuals confined within the boundaries of those > panes. Interestingly, we can trace this pattern to the very first Smalltalk > interfaces. In the Connector interface we have no boundaries with text > and visualization being intertwined to form a new kind of workflow. > > Talking about workflows, we now have two distinct and novel ways to > explore examples: one is Connector, and the other one is the expandable > code editor. For example, the scene from above looks like this in the > example expanding editor: > > > > > Both of these interfaces are not found in other infrastructures, and yet > they were both inexpensive to implement in Bloc. > This is fantastic. I dreamed a little of such an interface. Another good example would be a deep expansion of "super initialize". I guess this works easiest with "self" and "super" since there is only one method to expand. For message chains or where messages are sent to variables and multiple implementors need to be considered, it might not be completely practical but still a cool demonstration to have horizontally scrolling of multiple methods - similar to GTInspector panes scroll horizontally. cheers -ben > > We believe this will have a deep impact for all sorts of interfaces, and > especially for the IDE. If you are interested in more details related to > the IDE, take a look at the following paper from 2015: > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualization > s.pdf > > Please let us know what you think. > > Cheers, > The feenk team >

Jan. 15, 2018

[ANN] OpenSmalltalk VM Meeting

by Fabio Niephaus

Dear all, The OpenSmalltalk VM Meeting will be held *this Wednesday, 17th January, 5pm - 6pm CET*. Click [1] for a quick timezone conversion. Please find the link to a public Google Hangout in the Google Doc at [2]. The document also includes a preliminary agenda, feel free to leave any comments. See you on Wednesday! Fabio [1] http://www.thetimezoneconverter.com/?t=5pm&tz=CET%20(Central%20European%20T… ) [2] https://docs.google.com/document/d/1nu3JLDvxJqKbDv1DsQoREtXPJNnqB-adB5zC-Uh…

Jan. 15, 2018

Re: [Pharo-dev] Tonel code?

by Dale Henrichs

On 1/15/18 6:16 AM, Javier PimÃ¡s wrote: > Hi Dale! I'm afraid I have very little knowledge on the topic and > there is a big vocabulary. I don't even know how to load/see the code. > Maybe we can start a small wiki here [1] to put a glossary and some > more info, what do you think? I think I interpreted your "how hard would it be to have a port without monticello/port the needed monticello dependencies?" as indicating that you had more knowledge than I thought:) Perhaps you could expand on what "dialect porting experiments" you are planning - we can take the conversation to private email if you are more comfortable with that - and perhaps our conversation can form the basis of a wiki? Dale > > https://github.com/dalehenrich/CypressReferenceImplementation > > On Sun, Jan 14, 2018 at 2:20 PM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com > <mailto:dale.henrichs@gemtalksystems.com>> wrote: > > Javier, > > I have a port of Tonel to GemStone[1] that runs against both > Monticello and CypressReferenceImplementation[2]. I have yet to > merge my work back into pharo-vcs/tonel, because I'm waiting for > Tonel to stabilize and well ... I'm also busy:). > > It might be useful for you to see how I've spliced in readers and > writers for both Monticello and CypressReferenceImplementation. > > The CypressReferenceImplementation was written by Richard Sargent > as a non-Monticello-based package loader and has been ported to VW > and GemStone. Richard's work was based on some work that I had > done in creating a Cypress format[3] loader for Cuis[4] The > CypressReferenceImplementation is definition-based like > Monticello, but the definition model has been pared down to bare > essentials. It was written to be a reference implementation for > other non-Monticello-based Smalltalk platforms. > > Unless you already have a native definition-based system you > should look at the CypressReferenceImplementation for inspiration. > > Anyway, I'd be willing to answer any questions you have on the > work I've done with Tonel and the CypressReferenceImplementation > and I'd especially be interested on any improvements you migiht > suggest as I'm currently working on a second generation > implementation of the CypressReferenceImplementation called > Rowan[5] that is targeted for inclusion in the next GemStone release:) > > Dale > > [1] https://github.com/GsDevKit/tonel > <https://github.com/GsDevKit/tonel> > [2] > https://github.com/dalehenrich/CypressReferenceImplementation/tree/portabil… > <https://github.com/dalehenrich/CypressReferenceImplementation/tree/portabil…> > [3] https://github.com/CampSmalltalk/Cypress > <https://github.com/CampSmalltalk/Cypress> > [4] https://github.com/CampSmalltalk/cuis-cypress > <https://github.com/CampSmalltalk/cuis-cypress> > [5] > https://github.com/dalehenrich/CypressReferenceImplementation/tree/rowan/to… > <https://github.com/dalehenrich/CypressReferenceImplementation/tree/rowan/to…> > > > > > On 1/13/18 7:56 AM, Javier PimÃ¡s wrote: >> Hi, I wanted to do some dialect porting experiments. I want to >> export to pharo using tonel file format and got some questions. >> >> 1. Is this the main source? https://github.com/pharo-vcs/tonel >> <https://github.com/pharo-vcs/tonel> >> 2. Is it already loaded in pharo 7? >> 3. Seems to have dependencies with monticello, how hard would it >> be to have a port without monticello/port the needed monticello >> dependencies? >> 4. Any advice? >> >> Cheers, >> Javier >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires

Jan. 15, 2018

Re: [Pharo-dev] [Moose-dev] [ann] gt connector

by Alexandre Bergel

Impressive!! Would be used for a visual implementer/sender browser Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 14, 2018, at 6:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc. > > It looks like this: > <connector2.jpeg> > > You can see it in action here: > https://twitter.com/feenkcom/status/936109463462965248 <https://twitter.com/feenkcom/status/936109463462965248> > > In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects. > > There are a couple of things that are worth noting: > â¢ The editor works live, and the connection points appear and disappear as you type. > â¢ The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements). > â¢ The editor works live, so adding new elements to the scene properly rearranges the scene. > â¢ But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element. > > All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works. > > To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at. > > Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it. > > The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model. > > Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow. > > Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor: > > <editor.jpg> > > > Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc. > > We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015: > http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… > > Please let us know what you think. > > Cheers, > The feenk team > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 15, 2018

Re: [Pharo-dev] Blame support P7

by Esteban A. Maringolo

2018-01-14 8:04 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > > Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > (1) what non-trivial code is actively maintained from a single code base > > between Pharo, Squeak and Cuis ? > > That is nice, but too limited a question > > What about the need to maintain non-trivial large code bases between > multiple smalltalks? If we only limit ourselves to open source, just look > at Glorp and PDFTalk. I wouldn't use Glorp as a good example of multi-dialect portability. It has safeguards and "ifs" all around the code, but it goes more in the direction of making the dialects as much VW compatible as possible, instead of being truly dialect neutral like Seaside is, and have the proper "adapter" layer and packaging. Regards!

Jan. 15, 2018

Re: [Pharo-dev] Tonel code?

by Javier PimÃ¡s

Hi Dale! I'm afraid I have very little knowledge on the topic and there is a big vocabulary. I don't even know how to load/see the code. Maybe we can start a small wiki here [1] to put a glossary and some more info, what do you think? https://github.com/dalehenrich/CypressReferenceImplementation On Sun, Jan 14, 2018 at 2:20 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Javier, > > I have a port of Tonel to GemStone[1] that runs against both Monticello > and CypressReferenceImplementation[2]. I have yet to merge my work back > into pharo-vcs/tonel, because I'm waiting for Tonel to stabilize and well > ... I'm also busy:). > > It might be useful for you to see how I've spliced in readers and writers > for both Monticello and CypressReferenceImplementation. > > The CypressReferenceImplementation was written by Richard Sargent as a > non-Monticello-based package loader and has been ported to VW and GemStone. > Richard's work was based on some work that I had done in creating a Cypress > format[3] loader for Cuis[4] The CypressReferenceImplementation is > definition-based like Monticello, but the definition model has been pared > down to bare essentials. It was written to be a reference implementation > for other non-Monticello-based Smalltalk platforms. > > Unless you already have a native definition-based system you should look > at the CypressReferenceImplementation for inspiration. > > Anyway, I'd be willing to answer any questions you have on the work I've > done with Tonel and the CypressReferenceImplementation and I'd especially > be interested on any improvements you migiht suggest as I'm currently > working on a second generation implementation of the > CypressReferenceImplementation called Rowan[5] that is targeted for > inclusion in the next GemStone release:) > > Dale > [1] https://github.com/GsDevKit/tonel > [2] https://github.com/dalehenrich/CypressReferenceImplementation > /tree/portability/cypress > [3] https://github.com/CampSmalltalk/Cypress > [4] https://github.com/CampSmalltalk/cuis-cypress > [5] https://github.com/dalehenrich/CypressReferenceImplementation > /tree/rowan/tonel > > > > On 1/13/18 7:56 AM, Javier PimÃ¡s wrote: > > Hi, I wanted to do some dialect porting experiments. I want to export to > pharo using tonel file format and got some questions. > > 1. Is this the main source? https://github.com/pharo-vcs/tonel > 2. Is it already loaded in pharo 7? > 3. Seems to have dependencies with monticello, how hard would it be to > have a port without monticello/port the needed monticello dependencies? > 4. Any advice? > > Cheers, > Javier > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > > -- Javier PimÃ¡s Ciudad de Buenos Aires

Jan. 15, 2018

Re: [Pharo-dev] [Ann] Calypso scoped refactoring

by Julien

This scope list in the widget was definitely something missing in Nautilus. Thanks a lot for this! Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 15 janv. 2018 Ã 12:10, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > > I finally implemented scopes support for refactorings in Calypso to be able restrict system changes to particular set of packages or classes. > The new preview tool is copy of old ChangesBrowser with additional scopes list widget: > > <CalypsoScopedRefactoring.png> > > In this picture I requested Announcer>>initialize rename and switched scope to the Announcer package. > > Scopes are filled by browser where refactoring was requested. It is same logic how method browser receives scopes from original browser. > > When user changes scope all refactoring changes are recomputed. > > It was last dependency of Calypso from Nautilus related packages. Now it can be loaded without Nautilus. > > Best regards, > Denis

Jan. 15, 2018

Re: [Pharo-dev] Tonel code?

by Javier PimÃ¡s

On Sun, Jan 14, 2018 at 8:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi, I wanted to do some dialect porting experiments. I want to export to > > pharo using tonel file format and got some questions. > > > > 1. Is this the main source? https://github.com/pharo-vcs/tonel > > yes > > > 2. Is it already loaded in pharo 7? > > did you open Pharo 70? because this is what I should do to answer your > question. > Yes, but I wasn't sure if there were more/other code, now I know that's all, thanks. > > 3. Seems to have dependencies with monticello, how hard would it be to > have > > a port without monticello/port the needed monticello dependencies? > > No idea. > > > 4. Any advice? > > > > Cheers, > > Javier > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > -- Javier PimÃ¡s Ciudad de Buenos Aires

Jan. 15, 2018

Re: [Pharo-dev] [Ann] Calypso scoped refactoring

by Sven Van Caekenberghe

> On 15 Jan 2018, at 12:10, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > I finally implemented scopes support for refactorings in Calypso to be able restrict system changes to particular set of packages or classes. > The new preview tool is copy of old ChangesBrowser with additional scopes list widget: > > <CalypsoScopedRefactoring.png> > > In this picture I requested Announcer>>initialize rename and switched scope to the Announcer package. > > Scopes are filled by browser where refactoring was requested. It is same logic how method browser receives scopes from original browser. > > When user changes scope all refactoring changes are recomputed. > > It was last dependency of Calypso from Nautilus related packages. Now it can be loaded without Nautilus. > > Best regards, > Denis Very nice !

Jan. 15, 2018