- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ANSICompatibility package

by Ben Coman

On Wed, Sep 9, 2015 at 4:31 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Whoever created http://smalltalkhub.com/#!/~PharoExtras/Compatibility/ > > I would rename it to SmalltalkCompatibility to ANSICompatibility because > "Compatibility" is a too general term and could mean backward compatibility > of Pharo versions or compatibility to other languages as well. That was me :) I was thinking more broadly that over time the "repository" might hold different packages Compatibility-ANSI, Compatibility-VW, Compatibility-Dolphin. But maybe that is overreaching and its better to be more focussed. Let me know what you think on this and restate what you think the repository name should be. > Also see http://wiki.squeak.org/squeak/2384 and http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec > which could be a start. I saw those, but they interact with existing classes, so I thought it easier to kickstart by loading in the tests first, which are all new classes. I only created the repository since the tests were *hard* to find eventually at http://www.spacmunke.org/svn/jst/trunk/src/test/ansi/ansi-compatibility/ So I thought it would be good make them more accessible as a Monticello Package. cheers -ben P.S. I don't quite follow "to SmalltalkCompatibility to ANSICompatibility" do you mean "to SmalltalkCompatibility or ANSICompatibility" ? > >> Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr >> Von: stepharo <stepharo(a)free.fr> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] ANSICompatibility package >> >> We should have a SmalltalkCompatibility (not Ansi per se) package >> were we can add some methods to help migration. >> >> Stef >> >> >> Le 8/9/15 06:04, Ben Coman a Ã©crit : >> > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >> Hi, >> >> >> >> is there actually such a thing like ANSICompatibility package? >> >> (it has been mentioned here lately, but I cannot find it) >> >> >> >> Thanks, Jan >> >> >> > I made it up for the purpose of discussion to see what interest it generated. >> > Should we start one ? >> > cheers -ben >> > >> > >> >> >> >

Sept. 9, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

The interactive graph is cool. Some suggestions: * Mark nodes of dependencies you want to prune in red. * Allow nodes to be pinned * http://bl.ocks.org/GerHobbelt/3637711 * http://stackoverflow.com/questions/11584757/interactively-fixing-a-node-in-… * http://stackoverflow.com/questions/12496851/d3-force-graph-sticky-nodes * http://bl.ocks.org/mbostock/3750558 * Node size to reflect size of package. A small number of dependencies to a fat node might be best to tackle first. * Highlighting & Fisheye * http://www.coppelia.io/2014/07/an-a-to-z-of-extra-features-for-the-d3-force… * Mark in bootstrap-dependency-report-graph-data.csv <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> which dependencies you want to eliminate, so that others might have a play with visualisation. More exotic... * Serve the bootstrap-dependency-report-graph.html <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> and bootstrap-dependency-report-graph-data.csv <https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/ws/bootstrap-dep…> out from Zinc, so I can point my browser at my local Pharo Image, and when a dependency is deleted, the graph updates automagically * When I double-click a node in the graph, it selects that item in the dependency analyzer in Image. * I guess the same might be done with two local Images - Moose as the observer and Pharo as the subject. cheers -ben On Wed, Sep 9, 2015 at 5:33 PM, Christophe Demarey < Christophe.Demarey(a)inria.fr> wrote: > Hi, > > We now have a best overview of bootstrap dependencies. > You can check the latest report at > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > . > With Max, we reused Dijkstra algo in Moose to help finding dependencies > leading to Morphic and co. > It is now possible to have a visualization that is usable (there is also a > button to open it in the report): > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > Next steps are to cut dependencies in red in the report table. > > Christophe. > > ps: by the way the dependency analyzer (with fixes asked) will be > introduced soon in the image. > > > Le 4 sept. 2015 Ã 15:13, Christophe Demarey a Ã©crit : > > Hi, > > I created a job to automatically generate a report of the Pharo image > dependencies as well as current bootstrap dependencies. > You can find them here: > > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > - > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > > There are a lot (too many) dependencies but you can focus on some of them > with the search field. > Dependencies inside orange boxes are dependencies that are there but that > we ignore (for example, an example method adds an extra-dependency). It > should be fixed later but is not a problem for now. Ignored dependencies > are declared in the package manifest in #ignoredDependencies. > Dependencies inside red boxes are dependencies we want to remove for the > bootstrap. For now, they are listed in the bootstrap dependency report. > > People that are willing to help to have a more modular Pharo could first > take a look at the bootstrap dependency report and check dependencies that > we should cut. > Once we know, we can open issues on fogbugz in the 'bootstrap category' > and update manifests accordingly. > To investigate more deeply dependencies, you can use the > DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies > (inheritance, reference, extension, traits, message send). > > Regards, > Christophe. > > >

Sept. 9, 2015

Strategies with Nautilus announcements

by Yuriy Tymchuk

Hi, as NautilusMethodSelected contains also an information about protocol, class, package; NautilusProtocolSelected contains an information about class and package; . . . Iâve inherited NautilusClassSelected from NautilusPackageSelected and NautilusProtocolSelected from NautilusClassSelectedâ¦ to remove duplication. But as announcement subscription also includes itâs subclasses, if you subscribe to NautilusPackageSelected, you end up receiving also NautilusClassSelected, NautilusProtocolSelected and NautilusMethodSelected. What is a good way to resolve this (I can simply separate all the classes, but maybe there is something important from conceptual point of view)? Uko

Sept. 9, 2015

[ANN] MessageFlowBrowser

by Torsten Bergmann

A new tool to browse and dive deep into the flow of messages using a tree representation (messages, senders, implementors, ...) and further on. I know such a tool from Smalltalk/MT and it is really helpful to trace a message flow without running in the debugger. See the attached screenshot, the best is to try it: In a latest Pharo 5.0 image (Pharo5.0 Latest update: #50314) you can evaluate: Gofer new url: 'http://smalltalkhub.com/mc/TorstenBergmann/MessageFlowBrowser/main'; package: 'Tool-MessageFlowBrowser'; load to load it. Then open whatever method in Nautilus and choose "Message Flow" from the context menu. The nice thing is that you can dive into senders, implementors, messages sent deeper and deeper (or up again) and you do not open more and more windows but stay in a single window !!! Alternatively you can start the tool from the playground: MessageFlowBrowser openOn: #inspect "open the flow browser on a selector" MessageFlowBrowser openOn: (Compiler>>#evaluate) "open the flow browser on a method" MessageFlowBrowser openOn: Object "open the flow browser on a class" 1 messageFlow. "open the flow browser on the class of an instance" If someone with GT knowledge and time could help to correct the syntax highlighting in the code pane this would be super cool (see method MessageFlowBrowser #openOn:). Also selection could be improved to show/highlight the messages sent directly in the code. Unfortunately I'm not so familar with the current code editors - so any help is appreciated. Repo is open for contribution. Thanks T.

Sept. 9, 2015

Ctrl-Click on selectors doesn't jump on the method (Linux)

by phil＠highoctane.be

Under Linux, I can't Ctrl-click on these things and wondered where I'd have to look as under OSX things do work. Clues? Phi

Sept. 9, 2015

Re: [Pharo-dev] ANSICompatibility package

by Jan Vrany

On Wed, 2015-09-09 at 10:31 +0200, Torsten Bergmann wrote: > Whoever created > http://smalltalkhub.com/#!/~PharoExtras/Compatibility/ > > I would rename it to SmalltalkCompatibility to ANSICompatibility > because > "Compatibility" is a too general term and could mean backward > compatibility > of Pharo versions or compatibility to other languages as well. +1 to ANSICompatibility > > Also see http://wiki.squeak.org/squeak/2384 and > http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec > which could be a start. > > > > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > > Von: stepharo <stepharo(a)free.fr> > > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Betreff: Re: [Pharo-dev] ANSICompatibility package > > > > We should have a SmalltalkCompatibility (not Ansi per se) package > > were we can add some methods to help migration. > > > > Stef > > > > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> > > > wrote: > > > > Hi, > > > > > > > > is there actually such a thing like ANSICompatibility package? > > > > (it has been mentioned here lately, but I cannot find it) > > > > > > > > Thanks, Jan > > > > > > > I made it up for the purpose of discussion to see what interest > > > it generated. > > > Should we start one ? > > > cheers -ben > > > > > > > > > > > > > >

Sept. 9, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Craig Latta

Hoi Christophe-- > We now have a best overview of bootstrap dependencies. That's a pretty grim picture. :) Can you post a movie of you picking through that ball of connections? (E.g., with the search feature as you described, or any with any other UI affordance that you have with this system.) thanks! -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 9, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Christophe Demarey

Hi, We now have a best overview of bootstrap dependencies. You can check the latest report at https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM…. With Max, we reused Dijkstra algo in Moose to help finding dependencies leading to Morphic and co. It is now possible to have a visualization that is usable (there is also a button to open it in the report): https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… Next steps are to cut dependencies in red in the report table. Christophe. ps: by the way the dependency analyzer (with fixes asked) will be introduced soon in the image. Le 4 sept. 2015 Ã 15:13, Christophe Demarey a Ã©crit : > Hi, > > I created a job to automatically generate a report of the Pharo image dependencies as well as current bootstrap dependencies. > You can find them here: > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… > > There are a lot (too many) dependencies but you can focus on some of them with the search field. > Dependencies inside orange boxes are dependencies that are there but that we ignore (for example, an example method adds an extra-dependency). It should be fixed later but is not a problem for now. Ignored dependencies are declared in the package manifest in #ignoredDependencies. > Dependencies inside red boxes are dependencies we want to remove for the bootstrap. For now, they are listed in the bootstrap dependency report. > > People that are willing to help to have a more modular Pharo could first take a look at the bootstrap dependency report and check dependencies that we should cut. > Once we know, we can open issues on fogbugz in the 'bootstrap category' and update manifests accordingly. > To investigate more deeply dependencies, you can use the DependencyAnalyzer (in the Pharo Catalog) to actually check dependencies (inheritance, reference, extension, traits, message send). > > Regards, > Christophe.

Sept. 9, 2015

Re: [Pharo-dev] when:send:to: vs. subscribe:send:to:

by Nicolas Cellier

Note that when:send:to: already existed in VW before announcements (it did work with a symbol like when: #someAspectChanged send: #someAction to: self, and this was tiggered thru dependents mechanism - self changed: #someAspectChanged...). IMO, it is very expressive, whatever the underlying mechanism (dependents or Announcement). 2015-09-09 8:49 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > > > > > Am 08.09.2015 um 22:49 schrieb stepharo <stepharo(a)free.fr>: > > > > Me too :) > > I do not care that they is a registration mechanism behind. > > > But you get a subscription back. Und the user should be aware of that > there is no magical unsubscribe mechanism. So this no reason for me but I > still like when:send:to: better although it feels a bit awkward. > > Norbert > > Stef > > > > Le 8/9/15 16:30, Ferlicot D. Cyril a Ã©crit : > >> Le 08/09/2015 10:13, Stephan Eggermont a Ã©crit : > >> > >>> When looking at the implementation, it looks as if we should > >>> replace all #when:send:to: by #subscribe:when:do:, not the other way > >>> around. > >>> > >>> Where is this all coming from? > >>> > >>> Stephan > >> I think that #when:send:to: is more explicit and more understandable, > >> but this is a personal opinion. > > > > > >

Sept. 9, 2015

Re: [Pharo-dev] ANSICompatibility package

by Torsten Bergmann

Whoever created http://smalltalkhub.com/#!/~PharoExtras/Compatibility/ I would rename it to SmalltalkCompatibility to ANSICompatibility because "Compatibility" is a too general term and could mean backward compatibility of Pharo versions or compatibility to other languages as well. Also see http://wiki.squeak.org/squeak/2384 and http://map.squeak.org/package/d7011055-4446-4b8e-b6da-e7e32d3389ec which could be a start. > Gesendet: Dienstag, 08. September 2015 um 22:53 Uhr > Von: stepharo <stepharo(a)free.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] ANSICompatibility package > > We should have a SmalltalkCompatibility (not Ansi per se) package > were we can add some methods to help migration. > > Stef > > > Le 8/9/15 06:04, Ben Coman a Ã©crit : > > On Tue, Sep 8, 2015 at 9:21 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> Hi, > >> > >> is there actually such a thing like ANSICompatibility package? > >> (it has been mentioned here lately, but I cannot find it) > >> > >> Thanks, Jan > >> > > I made it up for the purpose of discussion to see what interest it generated. > > Should we start one ? > > cheers -ben > > > > > > >

Sept. 9, 2015