[Pharo-project] weak announcements

Tudor Girba tudor.girba at gmail.com
Tue Feb 15 22:05:13 CET 2011


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 <stephane.ducasse at inria.fr>
>>>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>>>>>> Para: Pharo-project at lists.gforge.inria.fr
>>>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>>>>>> Responder a: Pharo-project at 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."
>> 
>> 
>> 
>> 
> 
> 

--
www.tudorgirba.com

"What we can governs what we wish."







More information about the Pharo-project mailing list