Working with weak announcements...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Working with weak announcements...

EstebanLM
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?

best,
Esteban
Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Stéphane Ducasse
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


Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Igor Stasenko
In reply to this post by EstebanLM
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.

Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Stéphane Ducasse
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.

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.
>



Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Tudor Girba
In reply to this post by Stéphane Ducasse
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."


Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Igor Stasenko
In reply to this post by Stéphane Ducasse
On 15 February 2011 10:00, Stéphane Ducasse <[hidden email]> wrote:
> 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.
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.

Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Gary Chambers-4
Lol, good luck!

Regards, Gary

----- Original Message -----
From: "Igor Stasenko" <[hidden email]>
To: <[hidden email]>
Sent: Tuesday, February 15, 2011 4:46 PM
Subject: Re: [Pharo-project] Working with weak announcements...


On 15 February 2011 10:00, Stéphane Ducasse <[hidden email]>
wrote:
> 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.
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.


Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Tudor Girba
In reply to this post by Tudor Girba
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."




Reply | Threaded
Open this post in threaded view
|

weak announcements

Tudor Girba
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."





Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Stéphane Ducasse
In reply to this post by Igor Stasenko
>
>> 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.
>


Reply | Threaded
Open this post in threaded view
|

Re: weak announcements

Stéphane Ducasse
In reply to this post by Tudor Girba
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."
>
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: weak announcements

Tudor Girba
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 <[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."




Reply | Threaded
Open this post in threaded view
|

Re: weak announcements

Stéphane Ducasse


> 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."
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Igor Stasenko
In reply to this post by Stéphane Ducasse
On 15 February 2011 18:52, Stéphane Ducasse <[hidden email]> wrote:

>>
>>> 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?

I have to read the paper about it to refresh my memory.. and then
apply these concepts to squeak/cog vm reality :)

>
>> 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.
>>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Working with weak announcements...

Stéphane Ducasse
>>> I think it is relatively easy to modify VM , since it touching only GC
>>> related stuff.
>>
>> Ok how many weeks?
>
> I have to read the paper about it to refresh my memory.. and then
> apply these concepts to squeak/cog vm reality :)

if you have a pointer I'm interested in reading it.


Reply | Threaded
Open this post in threaded view
|

Re: weak announcements

Tudor Girba
In reply to this post by Stéphane Ducasse
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 <[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."
>>
>>
>>
>>
>
>

--
www.tudorgirba.com

"What we can governs what we wish."