May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] SystemAnnouncer api question

by Sven Van Caekenberghe

Simpler is better: "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector. When the message expects one argument (eg #fooAnnouncement:) the announcement is passed as argument. When the message expects two arguments (eg #fooAnnouncement:announcer:) both the announcement and the announcer are passed as argument" And is it not when an an announcement of anAnnouncementClass is raised, .. ? Announcements are instances. On 27 May 2013, at 19:03, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> Hi guys >>> >>> why there is no variant to on:send:to: >>> "SystemAnnouncer uniqueInstance on: AddedLog send: #foo to: self. " >>> that pass also the announcement? >>> >>> Just because it is better to use on:do;? >>> >>> Stef >>> >> Huh? >> It should work do do >> SystemAnnouncer uniqueInstance on: AddedLog send: #foo: to: self >> >> and get the announcement as argumentâ¦ > > Ok now of course since there is a nice comment in the method explaining it I could have read it :( > I will try to write one. > > so is this one correct > "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector. > When the message is excepting one argument (eg #fooAnnouncement:) the announcement is passed as argument. > When the message is exception two arguments (eg #fooAnnouncement:announcer:) the announcement and the annoncer > are passed as argument" > >> >> or #foo:bar: >> to get the announcer as well as the announcement. >> >> This is one of the reasons cull: is cool! ;) >> >> Cheers, >> Henry >> > >

May 27, 2013

Re: [Pharo-dev] SystemAnnouncer api question

by stephane ducasse

Igor can you add a bug entry and propose a fix? So that we do not forget. Stef >>>> >>>> >>>>> Hi guys >>>>> >>>>> why there is no variant to on:send:to: >>>>> "SystemAnnouncer uniqueInstance on: AddedLog send: #foo to: self. " >>>>> that pass also the announcement? >>>>> >>>>> Just because it is better to use on:do;? >>>>> >>>>> Stef >>>>> >>>> Huh? >>>> It should work do do >>>> SystemAnnouncer uniqueInstance on: AddedLog send: #foo: to: self >>>> >>>> and get the announcement as argumentâ¦ >>>> >>>> or #foo:bar: >>>> to get the announcer as well as the announcement. >>>> >>>> This is one of the reasons cull: is cool! ;) >>>> >>>> Cheers, >>>> Henry >>>> >>> >>> Speaking of SystemAnnouncerâ¦ >>> In the latest dev image I've got: >>> SystemAnnouncer uniqueInstance numberOfSubscriptions 1327 >>> >>> Most of which are weak subscriptions for RecentMessageList. >>> >>> RecentMessageList class >> cleanUp >>> >>> self allInstancesDo: [:rml| rml initialize]. >>> >>> is clearly wrong, as initialize registers subscriptions for the announcements (thus introducing duplicates), done every time you shut down the imageâ¦ >>> >>> maybe it should do >>> self resetUniqueInstance instead? >>> >> >> i think >> RecentMessageList>>registerToAnnouncements >> >> should include >> >> SystemAnnouncer uniqueInstance unsubscribe: self. >> >> >> like that, even if you call #initialize multiple times, it won't >> create duplicates. >> > > tried it, with the change: > > SystemAnnouncer uniqueInstance numberOfSubscriptions 467 > > RecentMessageList cleanUp > > SystemAnnouncer uniqueInstance numberOfSubscriptions 93 > >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. >

May 27, 2013

Re: [Pharo-dev] SystemAnnouncer api question

by stephane ducasse

> >> Hi guys >> >> why there is no variant to on:send:to: >> "SystemAnnouncer uniqueInstance on: AddedLog send: #foo to: self. " >> that pass also the announcement? >> >> Just because it is better to use on:do;? >> >> Stef >> > Huh? > It should work do do > SystemAnnouncer uniqueInstance on: AddedLog send: #foo: to: self > > and get the announcement as argumentâ¦ Ok now of course since there is a nice comment in the method explaining it I could have read it :( I will try to write one. so is this one correct "Declare that when anAnnouncementClass is raised, anObject should receive the message aSelector. When the message is excepting one argument (eg #fooAnnouncement:) the announcement is passed as argument. When the message is exception two arguments (eg #fooAnnouncement:announcer:) the announcement and the annoncer are passed as argument" > > or #foo:bar: > to get the announcer as well as the announcement. > > This is one of the reasons cull: is cool! ;) > > Cheers, > Henry >

May 27, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,mac #244

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=mac…>

May 27, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,win #244

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=win…>

May 27, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,linux #244

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/./Run=run%201,VM=vm,label=lin…>

May 27, 2013

[update 2.0] #20605

by Marcus Denker

20605 ----- 10653 Some Jenkins images show a stdout is closed error https://pharo.fogbugz.com/f/cases/10653 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-CommandLine-MarcusDenker.83.diff

May 27, 2013

Re: [Pharo-dev] [update 3.0] #30171

by Marcus Denker

On May 27, 2013, at 4:52 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 May 2013, at 16:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> 10698 add back Block printing >> https://pharo.fogbugz.com/f/cases/10698 >> (Really only if Opal is Active) > > Aah, a good reason to active Opal then ;-) I did that because the mapping used needs that the bytecode of the method is the same that Opal will create, else the mapping can not workâ¦ In most cases we make the same bytecode, but for complex cases it can differ. So to be sure one needs to recompile the image. Marcus

May 27, 2013

Re: [Pharo-dev] [update 3.0] #30171

by Sven Van Caekenberghe

On 27 May 2013, at 16:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 10698 add back Block printing > https://pharo.fogbugz.com/f/cases/10698 > (Really only if Opal is Active) Aah, a good reason to active Opal then ;-) Sven

May 27, 2013

[update 3.0] #30171

by Marcus Denker

30171 ----- 10764 EyeInspector never terminate refresh process leading to no garbage collection https://pharo.fogbugz.com/f/cases/10764 10767 Object>>#assert:description: should take a block for the description https://pharo.fogbugz.com/f/cases/10767 10698 add back Block printing https://pharo.fogbugz.com/f/cases/10698 (Really only if Opal is Active) Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.2… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1467.diff

May 27, 2013