Working with weak announcements...

> 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

> On 14 February 2011 21:52, Esteban Lorenzano <[hidden email]> wrote:
>> Hi,
>> I'm working with weak announcements, 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?
>>
>
> Don't even try doing it until we will have ephemerons support at VM side :)
>
> I explained this few days ago to Stephane, and also i mentioned about
> this maybe half of year ago when i took a look at announcements.
>
> With ephemerons you can have:
> - reference a block strongly only if subscriber , which held weakly is alive.
>
> Once subscribed dies, you start referencing block weakly.
>
> In terms on GC it means, that during mark phase, you are visiting a
> references which reachable through block closure only if your
> subscriber are already marked as 'live'.
>
> So, this means that you can do weak subscriptions like following:
>
>
> self weakOn: Foo do: [:announcement | self bar ].
>
> A 'self' is a subscriber. But if you create a subscription from a pair of:
> <subscriber> and <block>
> without using ephemerons you should make sure that reference to
> subscriber are not reachable through given block.
> Otherwise, a weak reference become strong one, because you referencing
> a block strongly and therefore subscriber too,
> since block referencing subscriber through one of its vars.
>
> So, without ephemerons you have to invent some workarounds by
> rewriting above code with something like:
>
>
> self weakOn: Foo do: [:announcement :myself |
> myself bar
> ].
>
> in the above, a block no longer referencing receiver (a subsriber),
> and instead it will be passed as extra argument
> to the block.
>
> ( except that still, you will have a problem, if closure keeps a
> reference to home context, which in own turn referencing subscriber
> through context's receiver.. so without emphemerons you should be
> really careful)
>
> And of course, i think that the usefulness of Announcements is quite
> limited without proper weak subscription support,
> because weak subscriptions makes things a lot more easier: you don't
> have to explicitly unsubscribe some object, once you no longer using
> it ,
> which as to me means that about 99% of all subscriptions in system
> will be weak ones , simply to prevent potential problems with hanging
> references, and because you don't have to worry about unsubscribing.
>
> And of course, without weak-block subscriptions, the ease of use of
> subscription mechanism is a bit limited.
> So, instead of writing simple and cool:
>
> self weakOn: Foo do: [:announcement | self bar ].
>
>
> you must do more elaborate (and IMO less elegant)
>
> self weakOn: Foo send: #handleFooAnnouncement: .
>
> and then in #handleFooAnnouncement: you making 'self bar'
>
> P.S. the #weakOn: ... is not part of Announcements protocol , it is
> just an example of 'meta-message' to reveal an intent to create a weak
> subscription to some announcer by using receiver as a subscriber.
>
>
>> best,
>> Esteban
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> 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 <[hidden email]>
>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>> Para: [hidden email]
>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>> Responder a: [hidden email]
>>>>
>>>> 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."
>>
>>
>>
>

>
> Stef
>
>
> On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote:
>
>> On 14 February 2011 21:52, Esteban Lorenzano <[hidden email]> wrote:
>>> Hi,
>>> I'm working with weak announcements, 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?
>>>
>>
>> Don't even try doing it until we will have ephemerons support at VM side :)
>>
>> I explained this few days ago to Stephane, and also i mentioned about
>> this maybe half of year ago when i took a look at announcements.
>>
>> With ephemerons you can have:
>> - reference a block strongly only if subscriber , which held weakly is alive.
>>
>> Once subscribed dies, you start referencing block weakly.
>>
>> In terms on GC it means, that during mark phase, you are visiting a
>> references which reachable through block closure only if your
>> subscriber are already marked as 'live'.
>>
>> So, this means that you can do weak subscriptions like following:
>>
>>
>> self weakOn: Foo do: [:announcement | self bar ].
>>
>> A 'self' is a subscriber. But if you create a subscription from a pair of:
>> <subscriber> and <block>
>> without using ephemerons you should make sure that reference to
>> subscriber are not reachable through given block.
>> Otherwise, a weak reference become strong one, because you referencing
>> a block strongly and therefore subscriber too,
>> since block referencing subscriber through one of its vars.
>>
>> So, without ephemerons you have to invent some workarounds by
>> rewriting above code with something like:
>>
>>
>> self weakOn: Foo do: [:announcement :myself |
>> myself bar
>> ].
>>
>> in the above, a block no longer referencing receiver (a subsriber),
>> and instead it will be passed as extra argument
>> to the block.
>>
>> ( except that still, you will have a problem, if closure keeps a
>> reference to home context, which in own turn referencing subscriber
>> through context's receiver.. so without emphemerons you should be
>> really careful)
>>
>> And of course, i think that the usefulness of Announcements is quite
>> limited without proper weak subscription support,
>> because weak subscriptions makes things a lot more easier: you don't
>> have to explicitly unsubscribe some object, once you no longer using
>> it ,
>> which as to me means that about 99% of all subscriptions in system
>> will be weak ones , simply to prevent potential problems with hanging
>> references, and because you don't have to worry about unsubscribing.
>>
>> And of course, without weak-block subscriptions, the ease of use of
>> subscription mechanism is a bit limited.
>> So, instead of writing simple and cool:
>>
>> self weakOn: Foo do: [:announcement | self bar ].
>>
>>
>> you must do more elaborate (and IMO less elegant)
>>
>> self weakOn: Foo send: #handleFooAnnouncement: .
>>
>> and then in #handleFooAnnouncement: you making 'self bar'
>>
>> P.S. the #weakOn: ... is not part of Announcements protocol , it is
>> just an example of 'meta-message' to reveal an intent to create a weak
>> subscription to some announcer by using receiver as a subscriber.
>>
>>
>>> best,
>>> Esteban
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>

>
> Stef
>
>
> On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote:
>
>> On 14 February 2011 21:52, Esteban Lorenzano <[hidden email]> wrote:
>>> Hi,
>>> I'm working with weak announcements, 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?
>>>
>>
>> Don't even try doing it until we will have ephemerons support at VM side
>> :)
>>
>> I explained this few days ago to Stephane, and also i mentioned about
>> this maybe half of year ago when i took a look at announcements.
>>
>> With ephemerons you can have:
>> - reference a block strongly only if subscriber , which held weakly is
>> alive.
>>
>> Once subscribed dies, you start referencing block weakly.
>>
>> In terms on GC it means, that during mark phase, you are visiting a
>> references which reachable through block closure only if your
>> subscriber are already marked as 'live'.
>>
>> So, this means that you can do weak subscriptions like following:
>>
>>
>> self weakOn: Foo do: [:announcement | self bar ].
>>
>> A 'self' is a subscriber. But if you create a subscription from a pair
>> of:
>> <subscriber> and <block>
>> without using ephemerons you should make sure that reference to
>> subscriber are not reachable through given block.
>> Otherwise, a weak reference become strong one, because you referencing
>> a block strongly and therefore subscriber too,
>> since block referencing subscriber through one of its vars.
>>
>> So, without ephemerons you have to invent some workarounds by
>> rewriting above code with something like:
>>
>>
>> self weakOn: Foo do: [:announcement :myself |
>> myself bar
>> ].
>>
>> in the above, a block no longer referencing receiver (a subsriber),
>> and instead it will be passed as extra argument
>> to the block.
>>
>> ( except that still, you will have a problem, if closure keeps a
>> reference to home context, which in own turn referencing subscriber
>> through context's receiver.. so without emphemerons you should be
>> really careful)
>>
>> And of course, i think that the usefulness of Announcements is quite
>> limited without proper weak subscription support,
>> because weak subscriptions makes things a lot more easier: you don't
>> have to explicitly unsubscribe some object, once you no longer using
>> it ,
>> which as to me means that about 99% of all subscriptions in system
>> will be weak ones , simply to prevent potential problems with hanging
>> references, and because you don't have to worry about unsubscribing.
>>
>> And of course, without weak-block subscriptions, the ease of use of
>> subscription mechanism is a bit limited.
>> So, instead of writing simple and cool:
>>
>> self weakOn: Foo do: [:announcement | self bar ].
>>
>>
>> you must do more elaborate (and IMO less elegant)
>>
>> self weakOn: Foo send: #handleFooAnnouncement: .
>>
>> and then in #handleFooAnnouncement: you making 'self bar'
>>
>> P.S. the #weakOn: ... is not part of Announcements protocol , it is
>> just an example of 'meta-message' to reveal an intent to create a weak
>> subscription to some announcer by using receiver as a subscriber.
>>
>>
>>> best,
>>> Esteban
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>

> 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 <[hidden email]>
>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>> Para: [hidden email]
>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>> Responder a: [hidden email]
>>>>>
>>>>> 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."
>

> 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 <[hidden email]>
>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>> Para: [hidden email]
>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>> Responder a: [hidden email]
>>>>>>
>>>>>> 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."
>
>
>

> And also there is already an implementation somewhere made by Ian..
> which can be used as reference.
>
>>
>> Stef
>>
>>
>> On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote:
>>
>>> On 14 February 2011 21:52, Esteban Lorenzano <[hidden email]> wrote:
>>>> Hi,
>>>> I'm working with weak announcements, 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?
>>>>
>>>
>>> Don't even try doing it until we will have ephemerons support at VM side :)
>>>
>>> I explained this few days ago to Stephane, and also i mentioned about
>>> this maybe half of year ago when i took a look at announcements.
>>>
>>> With ephemerons you can have:
>>> - reference a block strongly only if subscriber , which held weakly is alive.
>>>
>>> Once subscribed dies, you start referencing block weakly.
>>>
>>> In terms on GC it means, that during mark phase, you are visiting a
>>> references which reachable through block closure only if your
>>> subscriber are already marked as 'live'.
>>>
>>> So, this means that you can do weak subscriptions like following:
>>>
>>>
>>> self weakOn: Foo do: [:announcement | self bar ].
>>>
>>> A 'self' is a subscriber. But if you create a subscription from a pair of:
>>> <subscriber> and <block>
>>> without using ephemerons you should make sure that reference to
>>> subscriber are not reachable through given block.
>>> Otherwise, a weak reference become strong one, because you referencing
>>> a block strongly and therefore subscriber too,
>>> since block referencing subscriber through one of its vars.
>>>
>>> So, without ephemerons you have to invent some workarounds by
>>> rewriting above code with something like:
>>>
>>>
>>> self weakOn: Foo do: [:announcement :myself |
>>> myself bar
>>> ].
>>>
>>> in the above, a block no longer referencing receiver (a subsriber),
>>> and instead it will be passed as extra argument
>>> to the block.
>>>
>>> ( except that still, you will have a problem, if closure keeps a
>>> reference to home context, which in own turn referencing subscriber
>>> through context's receiver.. so without emphemerons you should be
>>> really careful)
>>>
>>> And of course, i think that the usefulness of Announcements is quite
>>> limited without proper weak subscription support,
>>> because weak subscriptions makes things a lot more easier: you don't
>>> have to explicitly unsubscribe some object, once you no longer using
>>> it ,
>>> which as to me means that about 99% of all subscriptions in system
>>> will be weak ones , simply to prevent potential problems with hanging
>>> references, and because you don't have to worry about unsubscribing.
>>>
>>> And of course, without weak-block subscriptions, the ease of use of
>>> subscription mechanism is a bit limited.
>>> So, instead of writing simple and cool:
>>>
>>> self weakOn: Foo do: [:announcement | self bar ].
>>>
>>>
>>> you must do more elaborate (and IMO less elegant)
>>>
>>> self weakOn: Foo send: #handleFooAnnouncement: .
>>>
>>> and then in #handleFooAnnouncement: you making 'self bar'
>>>
>>> P.S. the #weakOn: ... is not part of Announcements protocol , it is
>>> just an example of 'meta-message' to reveal an intent to create a weak
>>> subscription to some announcer by using receiver as a subscriber.
>>>
>>>
>>>> best,
>>>> Esteban
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko AKA sig.
>>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> 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 <[hidden email]>
>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>>> Para: [hidden email]
>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>>> Responder a: [hidden email]
>>>>>>>
>>>>>>> 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."
>
>
>
>
>

> 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 <[hidden email]>
>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>>>> Para: [hidden email]
>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>>>> Responder a: [hidden email]
>>>>>>>>
>>>>>>>> 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."
>>
>>
>>
>>
>>
>
>

>
> 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 <[hidden email]>
>>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>>>>> Para: [hidden email]
>>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>>>>> Responder a: [hidden email]
>>>>>>>>>
>>>>>>>>> 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."
>
>
>
>

>>
>>> Igor
>>>
>>> now the problem is how much time do you expect it may take to introduce ephemerons?
>>> Else having well documented patterns is also important.
>>
>>
>> I think it is relatively easy to modify VM , since it touching only GC
>> related stuff.
>
> Ok how many weeks?

>
>> And also there is already an implementation somewhere made by Ian..
>> which can be used as reference.
>>
>>>
>>> Stef
>>>
>>>
>>> On Feb 14, 2011, at 10:33 PM, Igor Stasenko wrote:
>>>
>>>> On 14 February 2011 21:52, Esteban Lorenzano <[hidden email]> wrote:
>>>>> Hi,
>>>>> I'm working with weak announcements, 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?
>>>>>
>>>>
>>>> Don't even try doing it until we will have ephemerons support at VM side :)
>>>>
>>>> I explained this few days ago to Stephane, and also i mentioned about
>>>> this maybe half of year ago when i took a look at announcements.
>>>>
>>>> With ephemerons you can have:
>>>> - reference a block strongly only if subscriber , which held weakly is alive.
>>>>
>>>> Once subscribed dies, you start referencing block weakly.
>>>>
>>>> In terms on GC it means, that during mark phase, you are visiting a
>>>> references which reachable through block closure only if your
>>>> subscriber are already marked as 'live'.
>>>>
>>>> So, this means that you can do weak subscriptions like following:
>>>>
>>>>
>>>> self weakOn: Foo do: [:announcement | self bar ].
>>>>
>>>> A 'self' is a subscriber. But if you create a subscription from a pair of:
>>>> <subscriber> and <block>
>>>> without using ephemerons you should make sure that reference to
>>>> subscriber are not reachable through given block.
>>>> Otherwise, a weak reference become strong one, because you referencing
>>>> a block strongly and therefore subscriber too,
>>>> since block referencing subscriber through one of its vars.
>>>>
>>>> So, without ephemerons you have to invent some workarounds by
>>>> rewriting above code with something like:
>>>>
>>>>
>>>> self weakOn: Foo do: [:announcement :myself |
>>>> myself bar
>>>> ].
>>>>
>>>> in the above, a block no longer referencing receiver (a subsriber),
>>>> and instead it will be passed as extra argument
>>>> to the block.
>>>>
>>>> ( except that still, you will have a problem, if closure keeps a
>>>> reference to home context, which in own turn referencing subscriber
>>>> through context's receiver.. so without emphemerons you should be
>>>> really careful)
>>>>
>>>> And of course, i think that the usefulness of Announcements is quite
>>>> limited without proper weak subscription support,
>>>> because weak subscriptions makes things a lot more easier: you don't
>>>> have to explicitly unsubscribe some object, once you no longer using
>>>> it ,
>>>> which as to me means that about 99% of all subscriptions in system
>>>> will be weak ones , simply to prevent potential problems with hanging
>>>> references, and because you don't have to worry about unsubscribing.
>>>>
>>>> And of course, without weak-block subscriptions, the ease of use of
>>>> subscription mechanism is a bit limited.
>>>> So, instead of writing simple and cool:
>>>>
>>>> self weakOn: Foo do: [:announcement | self bar ].
>>>>
>>>>
>>>> you must do more elaborate (and IMO less elegant)
>>>>
>>>> self weakOn: Foo send: #handleFooAnnouncement: .
>>>>
>>>> and then in #handleFooAnnouncement: you making 'self bar'
>>>>
>>>> P.S. the #weakOn: ... is not part of Announcements protocol , it is
>>>> just an example of 'meta-message' to reveal an intent to create a weak
>>>> subscription to some announcer by using receiver as a subscriber.
>>>>
>>>>
>>>>> best,
>>>>> Esteban
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>

>
>
>> 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 <[hidden email]>
>>>>>>>>>> Fecha: 14 de febrero de 2011 17:57:07 GMT-03:00
>>>>>>>>>> Para: [hidden email]
>>>>>>>>>> Asunto: Re: [Pharo-project] Working with weak announcements...
>>>>>>>>>> Responder a: [hidden email]
>>>>>>>>>>
>>>>>>>>>> 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."
>>
>>
>>
>>
>
>