I committed the packages in PharoTaskForces. Cheers, Doru
On 15 Feb 2011, at 19:20, Stéphane Ducasse wrote: > > >> 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. > > they will just be moved to pharo for history management. > >> 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? > > Sure! > > >> >> 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 <[email protected]> >>>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00 >>>>>>>>>> Para: [email protected] >>>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements... >>>>>>>>>> Responder a: [email protected] >>>>>>>>>> >>>>>>>>>> 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." >> >> >> >> > > -- www.tudorgirba.com "What we can governs what we wish."
