September 2015 - Pharo-dev - lists.pharo.org

[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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50314 Home: https://github.com/pharo-project/pharo-core

Sept. 9, 2015

[pharo-project/pharo-core] 8afa38: 50314

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8afa388a82651c08ea4af40f346923593f6868ce https://github.com/pharo-project/pharo-core/commit/8afa388a82651c08ea4af40f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-09-09 (Wed, 09 Sep 2015) Changed paths: M BlueInk-Core.package/BIConfigurableFormatter.class/instance/private-formatting/formatBlock_.st M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/stable_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v1%5F4%5F2_.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/README.md A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/as yet unclassified/bookName.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/as yet unclassified/pages.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/pages/AddingYourProject.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/class/pages/introduction.st A ContributingToTheCatalogHelp.package/ContributingToTheCatalogHelp.class/definition.st A QualityAssistant.package/QANautilusPlugin.class/instance/accessing/morph.st M QualityAssistant.package/QANautilusPlugin.class/instance/initialization/initialize.st M Refactoring-Critics.package/RBAssignmentInIfTrueRule.class/instance/accessing/rationale.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50313.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50314.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50313.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50314.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50314 16524 Assignment is misspelled in RBAssignmentInIfTrueRule>>#rationale https://pharo.fogbugz.com/f/cases/16524 16515 Adding an instance variable to Model broken by QualityAssistant https://pharo.fogbugz.com/f/cases/16515 16454 BlueInk block formatting https://pharo.fogbugz.com/f/cases/16454 16521 Help topic for contributing to the catalog https://pharo.fogbugz.com/f/cases/16521 http://files.pharo.org/image/50/50314.zip

Sept. 9, 2015

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

by Norbert Hartl

> 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