Hi, Yes, it is meant to be integrated in Pharo 1.3.
Ok, but then PharoTaskForces should not delete the packages after they are integrated. The reason is that I want to use these announcements before you release 1.3, and thus it will appear in ConfigurationOfGlamour. Is that Ok? Cheers, Doru On 15 Feb 2011, at 18:53, Stéphane Ducasse wrote: > if this is to be integrated in 1.3 (which I hope :)) then I would prefer > PharoTaskForces > > Stef > > >> Hi everyone, >> >> So, the current situation is that we can make rather quickly on:send:to: >> work weakly. >> >> There is an almost working version in Lukas' repository, and Esteban and me >> will try to get it to work. Now, the question is where to publish this. I >> would suggest to create an official squeaksource.com/announcements >> repository. >> >> Is that Ok for you, or do you prefer to have it in >> squeaksource.com/PharoTaskForces? >> >> Cheers, >> Doru >> >> >> On 15 Feb 2011, at 18:21, Tudor Girba wrote: >> >>> Hi Esteban, >>> >>> I finished the Glamour changes to only use on:send:to: between the Glamour >>> model and the Glamour renderer. >>> >>> Cheers, >>> Doru >>> >>> >>> On 15 Feb 2011, at 17:37, Tudor Girba wrote: >>> >>>> Hi Esteban, >>>> >>>> I started to refactor all usages of on:do: and when:do: into on:send:to: >>>> in the core of Glamour. I am almost finished. >>>> >>>> Now the only question is if we want to distinguish between WeakAnnouncer >>>> and Announcer. Is there a performance penalty or another kind of drawback >>>> in merging the two and use the WeakAnnouncer implementation only? >>>> >>>> The other thing is that we need to add on:send:to:with: and >>>> on:send:to:withAll: because we need to handle extra parameters (given that >>>> we cannot access local variables). >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On 15 Feb 2011, at 13:45, Esteban Lorenzano wrote: >>>> >>>>> Well... not exactly, still something to do: the weak associations on >>>>> weakannouncer are getting a lot of pairs #selector->nil and we need to >>>>> think in a way to clean this. But this is doable :) >>>>> In other order of things, I think we should explicitly forbid the use of >>>>> #on:do: and #when:do: until the fix for blocks is ready. >>>>> >>>>> Cheers, >>>>> Esteban >>>>> >>>>> El 14/02/2011, a las 6:55p.m., Tudor Girba escribió: >>>>> >>>>>> Aha. Thanks a lot. Ok, let's do that. Is it true that the Lukas' >>>>>> Announcements already provide the support for on:send:to: ? >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 14 Feb 2011, at 22:04, Esteban Lorenzano wrote: >>>>>> >>>>>>> Hi, >>>>>>> Well, this means, in the mean time, if we want to solve our issue 492 >>>>>>> using weak announcements, we need to replace all #on:do: calls for >>>>>>> #on:send:to: >>>>>>> :( >>>>>>> >>>>>>> Cheers, >>>>>>> Esteban >>>>>>> >>>>>>> Inicio del mensaje reenviado: >>>>>>> >>>>>>>> De: Stéphane Ducasse <stephane.duca...@inria.fr> >>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>>>>>> Para: Pharo-project@lists.gforge.inria.fr >>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>>>>>> Responder a: Pharo-project@lists.gforge.inria.fr >>>>>>>> >>>>>>>> good question :) >>>>>>>> >>>>>>>> On FHi, >>>>>>>>> I'm working with weak announcements, >>>>>>>> >>>>>>>> good we need that. >>>>>>>> Igor was telling me that the right anwser are ephemerons (but for >>>>>>>> that: gc change is required). >>>>>>>> Now it would be good to have first a solution at image level >>>>>>>> >>>>>>>>> trying to make it work, and I have a problem in #on:do: protocol (or >>>>>>>>> #when:do:) >>>>>>>>> I try to explain: >>>>>>>>> >>>>>>>>> This method receives a block, not an object/selector, so I can't >>>>>>>>> create a WeakMessageSend which is the appropriate message to handle >>>>>>>>> in other cases. >>>>>>>>> Well, the real question is... how can I produce a "Weak BlockClosure >>>>>>>>> reference" who can die if receiver dies? >>>>>>>>> I tried some hacks (really ugly hacks, btw), but fail completely. >>>>>>>>> Any idea? >>>>>>>>> >>>>>>>>> best, >>>>>>>>> Esteban >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Problem solving efficiency grows with the abstractness level of problem >>>>>> understanding." >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every now and then stop and ask yourself if the war you're fighting is the >>> right one." >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> > > -- www.tudorgirba.com "Some battles are better lost than fought."
