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@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."
-- www.tudorgirba.com "What we can governs what we wish."