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

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by Ben Coman

On Fri, Sep 11, 2015 at 12:43 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: >> >> The bootstrap-dependency graph and report [1] mark dependency >> System-Announcements --> PragmaCollector for pruning. This is due to... >> >> SystemAnnouncer>>restoreAllNotifications >> | collector | >> self reset. >> collector := PragmaCollector filter: [ :pragma | >> pragma keyword = #systemEventRegistration ]. >> collector reset. >> collector do: [ :pragma | >> pragma methodClass theNonMetaClass perform: pragma selector ] >> >> Browsing around I came to understand that PragmaCollector is useful as >> a pragma cache, but here the collector is thrown away, so that >> facility is not needed. A key part is "collector reset" which does... >> self class allSystemPragmas >> do: [:pragma | self addPragma: pragma] >> >> where the #addPragma: evaluates the initialize'd #filter: block. Now >> it seems that #allSystemPragmas might fit nicely on Pragma rather than >> PragmaCollector >> such that the following should be equivalent... >> >> SystemAnnouncer>>restoreAllNotifications >> | systemPragmas | >> self reset. >> systemPragmas := Pragma allSystemPragmas collect: [ :pragma | >> pragma keyword = #systemEventRegistration ]. >> systemPragmas do: [ :pragma | >> pragma methodClass theNonMetaClass perform: pragma selector >> > > Cool. I like that better. > >> However #allSystemPragmas depends on SystemNavigation, so is it be >> okay for Pragma to depend on SystemNavigation? > > Spontaneously Iâd say that SystemNavigation should depend on Pragma or PragmaCollector for looking up pragmas, not the other way around. So you mean something like... SystemAnnouncer>>restoreAllNotifications self reset. SystemNavigation allPragmasNamed: #systemEventRegistration do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector ]. where... SystemNavigation>>allPragmasNamed: symbol do: aBlock | systemPragmas | systemPragmas := self allSystemPragmas collect: [ :pragma | pragma keyword = symbol ]. systemPragmas do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector SystemNavigation>>allSystemPragmas ^ (Array streamContents: [:stream | self allBehaviorsDo: [:behavior | Pragma withPragmasIn: behavior do: [:pragma | stream nextPut: pragma]]]) cheers -ben >> Actually, class side of Pragma has several #named:in: like methods, so >> something like the following would be neat... >> SystemAnnouncer>>restoreAllNotifications >> self reset. >> Pragma allNamed: #systemEventRegistration do: [ :pragma | >> pragma methodClass theNonMetaClass perform: pragma selector ].

Sept. 10, 2015

Re: [Pharo-dev] String concatenation using comma ","

by Max Leske

> On 10 Sep 2015, at 18:38, Chris Muller <asqueaker(a)gmail.com> wrote: > > I generally agree about implicit type-conversions, but I don't really > think this one is all that implicit. String concatentation returns a > String, no exceptions. > > By not having this for Strings actually led to Andreas getting bitten, > which is why it was added to Squeak. The "bite" comes when your > program encounters an error, and in your error-handler you wrote a > descriptive message, 'It didn''t work because the value is ', > someOtherString. Except someOtherString is nil. Now your > error-handler itself has an error, blowing up and leading you on a > wild goose chase because of a trivial message-concatentation problem > instead of the real problem. > > Can you describe an example where you feel this one could potentially > bite you by its "implicitnessâ? Thatâs a mean question :) I canât think of an example that is directly related but consider this method: doSomethingWith: someObject self printThisOntoAWebPage: âmy literal â, someObject The intention here is to print something out and âsomeObjectâ is supposed to have a certain format. Letâs say that âsomeObjectâ is a Date object and I want it to be printed as dd.mm.yyyy. The implicit conversion would yield âmy literal 10 September 2015â instead of the expected âmy literal 10.09.2015â. With an exception I would have seen that I need to format that object first, with implicit conversion I might overlook the mistake. Yes, itâs quite the construct I built here but in my experience the truth isnât that far away from it. Cheers, Max > > On Thu, Sep 10, 2015 at 9:34 AM, Max Leske <maxleske(a)gmail.com> wrote: >> Iâm with Sven on this. Just because JavaScript implementations (and others) choose to perform implicit type conversion doesnât mean itâs a good thing. It might make it easier for newcomers to write a hello world program but it will bite you when youâre trying to do actual work. >> >>> On 10 Sep 2015, at 16:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> No, this is not a good idea (silent conversions). It is one of the original differences between Pharo and Squeak. Try searching the MLs, I am sure it is all still there. >>> >>> You can also concatenate exceptions to create an exception set, I am sure there are other examples. >>> >>>> On 10 Sep 2015, at 16:12, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>>> >>>> Hi >>>> >>>> I'm just curious why "," doesn't convert object to string during concatenation? >>>> >>>> For example I expect >>>> 'answer is ', 42 >>>> to return 'answer is 42' instead of 'SmallInteger are not indexable'. >>>> >>>> Of course you could say that >>>> 'answer is ', 42 asString >>>> does the job... but still why not to put asString in concatenation method >>>> >>>> Cheers, >>>> Alex >>>> >>> >>> >> >> >

Sept. 10, 2015

Re: [Pharo-dev] Bootstrap dependency, System-Announcements --> PragmaCollector

by Max Leske

> On 10 Sep 2015, at 17:22, Ben Coman <btc(a)openInWorld.com> wrote: > > The bootstrap-dependency graph and report [1] mark dependency > System-Announcements --> PragmaCollector for pruning. This is due to... > > SystemAnnouncer>>restoreAllNotifications > | collector | > self reset. > collector := PragmaCollector filter: [ :pragma | > pragma keyword = #systemEventRegistration ]. > collector reset. > collector do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ] > > Browsing around I came to understand that PragmaCollector is useful as > a pragma cache, but here the collector is thrown away, so that > facility is not needed. A key part is "collector reset" which does... > self class allSystemPragmas > do: [:pragma | self addPragma: pragma] > > where the #addPragma: evaluates the initialize'd #filter: block. Now > it seems that #allSystemPragmas might fit nicely on Pragma rather than > PragmaCollector > such that the following should be equivalent... > > SystemAnnouncer>>restoreAllNotifications > | systemPragmas | > self reset. > systemPragmas := Pragma allSystemPragmas collect: [ :pragma | > pragma keyword = #systemEventRegistration ]. > systemPragmas do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector > Cool. I like that better. > However #allSystemPragmas depends on SystemNavigation, so is it be > okay for Pragma to depend on SystemNavigation? Spontaneously Iâd say that SystemNavigation should depend on Pragma or PragmaCollector for looking up pragmas, not the other way around. > > Actually, class side of Pragma has several #named:in: like methods, so > something like the following would be neat... > SystemAnnouncer>>restoreAllNotifications > self reset. > Pragma allNamed: #systemEventRegistration do: [ :pragma | > pragma methodClass theNonMetaClass perform: pragma selector ]. > > cheers -ben > > [1] https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM… >

Sept. 10, 2015

Re: [Pharo-dev] String concatenation using comma ","

by Chris Muller

I generally agree about implicit type-conversions, but I don't really think this one is all that implicit. String concatentation returns a String, no exceptions. By not having this for Strings actually led to Andreas getting bitten, which is why it was added to Squeak. The "bite" comes when your program encounters an error, and in your error-handler you wrote a descriptive message, 'It didn''t work because the value is ', someOtherString. Except someOtherString is nil. Now your error-handler itself has an error, blowing up and leading you on a wild goose chase because of a trivial message-concatentation problem instead of the real problem. Can you describe an example where you feel this one could potentially bite you by its "implicitness"? On Thu, Sep 10, 2015 at 9:34 AM, Max Leske <maxleske(a)gmail.com> wrote: > Iâm with Sven on this. Just because JavaScript implementations (and others) choose to perform implicit type conversion doesnât mean itâs a good thing. It might make it easier for newcomers to write a hello world program but it will bite you when youâre trying to do actual work. > >> On 10 Sep 2015, at 16:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> No, this is not a good idea (silent conversions). It is one of the original differences between Pharo and Squeak. Try searching the MLs, I am sure it is all still there. >> >> You can also concatenate exceptions to create an exception set, I am sure there are other examples. >> >>> On 10 Sep 2015, at 16:12, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>> >>> Hi >>> >>> I'm just curious why "," doesn't convert object to string during concatenation? >>> >>> For example I expect >>> 'answer is ', 42 >>> to return 'answer is 42' instead of 'SmallInteger are not indexable'. >>> >>> Of course you could say that >>> 'answer is ', 42 asString >>> does the job... but still why not to put asString in concatenation method >>> >>> Cheers, >>> Alex >>> >> >> > >

Sept. 10, 2015

Re: [Pharo-dev] String concatenation using comma ","

by Esteban A. Maringolo

Esteban A. Maringolo 2015-09-10 11:34 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > > Iâm with Sven on this. Just because JavaScript implementations (and others) choose to perform implicit type conversion doesnât mean itâs a good thing. It might make it easier for newcomers to write a hello world program but it will bite you when youâre trying to do actual work. > +1 To this. In the long term having explicit conversions is what I found more valuable. Regards!

Sept. 10, 2015

Bootstrap dependency, System-Announcements --> PragmaCollector

by Ben Coman

The bootstrap-dependency graph and report [1] mark dependency System-Announcements --> PragmaCollector for pruning. This is due to... SystemAnnouncer>>restoreAllNotifications | collector | self reset. collector := PragmaCollector filter: [ :pragma | pragma keyword = #systemEventRegistration ]. collector reset. collector do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector ] Browsing around I came to understand that PragmaCollector is useful as a pragma cache, but here the collector is thrown away, so that facility is not needed. A key part is "collector reset" which does... self class allSystemPragmas do: [:pragma | self addPragma: pragma] where the #addPragma: evaluates the initialize'd #filter: block. Now it seems that #allSystemPragmas might fit nicely on Pragma rather than PragmaCollector such that the following should be equivalent... SystemAnnouncer>>restoreAllNotifications | systemPragmas | self reset. systemPragmas := Pragma allSystemPragmas collect: [ :pragma | pragma keyword = #systemEventRegistration ]. systemPragmas do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector However #allSystemPragmas depends on SystemNavigation, so is it be okay for Pragma to depend on SystemNavigation? Actually, class side of Pragma has several #named:in: like methods, so something like the following would be neat... SystemAnnouncer>>restoreAllNotifications self reset. Pragma allNamed: #systemEventRegistration do: [ :pragma | pragma methodClass theNonMetaClass perform: pragma selector ]. cheers -ben [1] https://ci.inria.fr/pharo/job/Pharo-5.0-DependencyAnalysis/Dependencies_HTM…

Sept. 10, 2015

Re: [Pharo-dev] String concatenation using comma ","

by phil＠highoctane.be

I came to realize the value of that too. Phil On Thu, Sep 10, 2015 at 4:34 PM, Max Leske <maxleske(a)gmail.com> wrote: > Iâm with Sven on this. Just because JavaScript implementations (and > others) choose to perform implicit type conversion doesnât mean itâs a good > thing. It might make it easier for newcomers to write a hello world program > but it will bite you when youâre trying to do actual work. > > > On 10 Sep 2015, at 16:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > No, this is not a good idea (silent conversions). It is one of the > original differences between Pharo and Squeak. Try searching the MLs, I am > sure it is all still there. > > > > You can also concatenate exceptions to create an exception set, I am > sure there are other examples. > > > >> On 10 Sep 2015, at 16:12, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > >> > >> Hi > >> > >> I'm just curious why "," doesn't convert object to string during > concatenation? > >> > >> For example I expect > >> 'answer is ', 42 > >> to return 'answer is 42' instead of 'SmallInteger are not indexable'. > >> > >> Of course you could say that > >> 'answer is ', 42 asString > >> does the job... but still why not to put asString in concatenation > method > >> > >> Cheers, > >> Alex > >> > > > > > > >

Sept. 10, 2015

Re: [Pharo-dev] String concatenation using comma ","

by Max Leske

Iâm with Sven on this. Just because JavaScript implementations (and others) choose to perform implicit type conversion doesnât mean itâs a good thing. It might make it easier for newcomers to write a hello world program but it will bite you when youâre trying to do actual work. > On 10 Sep 2015, at 16:16, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > No, this is not a good idea (silent conversions). It is one of the original differences between Pharo and Squeak. Try searching the MLs, I am sure it is all still there. > > You can also concatenate exceptions to create an exception set, I am sure there are other examples. > >> On 10 Sep 2015, at 16:12, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hi >> >> I'm just curious why "," doesn't convert object to string during concatenation? >> >> For example I expect >> 'answer is ', 42 >> to return 'answer is 42' instead of 'SmallInteger are not indexable'. >> >> Of course you could say that >> 'answer is ', 42 asString >> does the job... but still why not to put asString in concatenation method >> >> Cheers, >> Alex >> > >

Sept. 10, 2015

Re: [Pharo-dev] FogBugz (Case [Issue]16520) CI and Bugtracker - Help topic for how to contribute to Pharo basecode

by Alexandre Bergel

Thanks Marcus! Apparently my two fixes are now in. This is cool! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 10, 2015, at 11:23 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I did some workaround for now > > => disabled some not that useful checks > => put the timout higher > > a normal run is now at around 30 min. > > >> On 09 Sep 2015, at 22:05, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> >> It needs to be fixed but I *really* did not find any time yet. >> >>> On 09 Sep 2015, at 22:00, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: >>> >>> Maybe change the error message until it is resolved to something like "Timeout blablabla... this is CI issue, please tell the monkey to try again". >>> So people know it's not their error and it will also tell them what to do, so they (me last week, Alex this week, someone else next week) don't need to ask again and again. >>> >>> Peter >>> >>> >>> On Wed, Sep 9, 2015 at 9:57 PM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> yes in that case why not fixing that because this is really really annoying to always get a fix rejected with a bad feedback. >>> >>> Stef >>> >>> >>> Le 9/9/15 21:52, Marcus Denker a Ã©crit : >>> >>> On 09 Sep 2015, at 20:27, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> Not much mark it as fix to include. >>> The last where this was done added an undeclared. Quality goes down very fast when we add changes without running the tests. >>> >>> Marcus >>> >>> >>> >>> >> >

Sept. 10, 2015

Re: [Pharo-dev] Image and bootstrap dependencies

by Ben Coman

Very cool. A couple of minor improvements: * The double-clicked "target" node is also hidden, so its label does not show. * When double-clicking a second node "B", it resets to show all links, rather than showing only the links for "B". Perhaps reset only when the "target" node is double-clicked again, or the background in double-clicked. cheers -ben On Thu, Sep 10, 2015 at 9:50 PM, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > I updated the graph. > There is now: > > dependencies to remove in red > if you double-click on a node, you only see links where the node is > involved. > > > > Le 10 sept. 2015 Ã 13:30, Ben Coman a Ã©crit : > > On Thu, Sep 10, 2015 at 3:54 PM, Christophe Demarey > <Christophe.Demarey(a)inria.fr> wrote: > > Hi Ben, > > > Le 9 sept. 2015 Ã 16:03, Ben Coman a Ã©crit : > > > The interactive graph is cool. Some suggestions: > > * Mark nodes of dependencies you want to prune in red. > > > > yes, I will add it ASAP > > > * Allow nodes to be pinned > > * http://bl.ocks.org/GerHobbelt/3637711 > > > > very good idea. > > TBH, I justa wanted to have a first visualization usable very fast. The > > current result can be improved a lot. > > > no problem. release early, release often is a good practice. > cheers -ben > >

Sept. 10, 2015