- Pharo-dev - lists.pharo.org

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

by stepharo

Pragma should not depend on SystemNavigation. The inverse Le 10/9/15 19:44, Ben Coman a Ã©crit : > 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] Bootstrap dependency, System-Announcements --> PragmaCollector

by stepharo

Hi ben I agree with you. I had the impression that many pragmaCollector methods would make sense in Pragma class level. Please continue your analysis. We should drastically clean SystemNavigation. - It should work on environment - remove all the browse behavior. Stef Le 10/9/15 17:22, Ben Coman a Ã©crit : > 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

improvements of RB are cool!!!!

by stepharo

today I spend a couple of hours refactoring some hiearchies and I had many push them and others... and this was a really experience: - do you want to remove the methods in the other subclasses? oh yes please. We should continue to improve pharo because it is becoming better and better. Stef

Sept. 10, 2015

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