[Pharo-project] Why don't we always register weakly in SystemAnnouncer?
Hi, with the help of Guille I noticed that normal instances usually register weakly: TestRunner >> initialize ..... SystemAnnouncer current weak on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. ..... and classes don't: TestCase class >> registerForNotifications ... SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self. so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ? thanks for the explanation, -- Mariano http://marianopeck.wordpress.com
On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi, with the help of Guille I noticed that normal instances usually register weakly:
TestRunner >> initialize ..... SystemAnnouncer current       weak       on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. .....
and classes don't:
TestCase class >> registerForNotifications    ...   SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self.
so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ?
Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it.
thanks for the explanation,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
So, what about making weak a default and notWeak the explicit one? :D On Sat, Jun 16, 2012 at 11:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi, with the help of Guille I noticed that normal instances usually register weakly:
TestRunner >> initialize ..... SystemAnnouncer current weak on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. .....
and classes don't:
TestCase class >> registerForNotifications ... SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self.
so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ?
Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it.
thanks for the explanation,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
On 16 June 2012 23:12, Guillermo Polito <guillermopolito@gmail.com> wrote:
So, what about making weak a default and notWeak the explicit one? :D
you can, but this could lead to confusion. because 'announcer weak subscribe: ' is explicit while 'announcer subscribe: ' is implicit.. so i would leave it like it is now.
On Sat, Jun 16, 2012 at 11:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi, with the help of Guille I noticed that normal instances usually register weakly:
TestRunner >> initialize ..... SystemAnnouncer current       weak       on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. .....
and classes don't:
TestCase class >> registerForNotifications    ...   SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self.
so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ?
Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it.
thanks for the explanation,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
because 'announcer weak subscribe: ' is explicit
Either way, something is implicit. Why not make the common case implicit and the uncommon one slightly more verbose? "Make common things easy, rare things possible" b.t.w. I like that we are all independently discovering many of the same things. It makes me think we're really on the right track... http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4083086.html -- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnouncer... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 June 2012 01:30, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
because 'announcer weak subscribe: ' is explicit
Either way, something is implicit. Why not make the common case implicit and the uncommon one slightly more verbose? "Make common things easy, rare things possible"
I bet if you do that, some people will be alienated/antagonized by this change (oh... its really hard to make everyone happy). As a compromise i would suggest to force people to explicitly tell their intent.. i.e. if they want to subscribe strongly, then they should say: announcer strong on:.. and weakly, is announcer weak on:.. but if they do: announcer on: they shall get a DNU/error. -- Best regards, Igor Stasenko.
On Sun, Jun 17, 2012 at 2:42 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 June 2012 01:30, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
because 'announcer weak subscribe: ' is explicit
Either way, something is implicit. Why not make the common case implicit
and
the uncommon one slightly more verbose? "Make common things easy, rare things possible"
I bet if you do that, some people will be alienated/antagonized by this change (oh... its really hard to make everyone happy).
As a compromise i would suggest to force people to explicitly tell their intent.. i.e. if they want to subscribe strongly, then they should say:
announcer strong on:..
and weakly, is
announcer weak on:..
but if they do:
announcer on:
they shall get a DNU/error.
He, I like that!
-- Best regards, Igor Stasenko.
Igor Stasenko wrote
I bet if you do that, some people will be alienated/antagonized by this change
Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in :) Like pulling off a BandAid... the best thing to do is pull fast and get it over with. Igor Stasenko wrote
As a compromise i would suggest to force people to explicitly tell their intent
That would be an improvement... Also, what's the status of this limitation (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) : when:do: anActionBlock subscription does
not work weakly, you are constrained to when:send:to
IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html) -- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnouncer... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 17 June 2012 15:09, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
I bet if you do that, some people will be alienated/antagonized by this change
Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in :) Like pulling off a BandAid... the best thing to do is pull fast and get it over with.
Igor Stasenko wrote
As a compromise i would suggest to force people to explicitly tell their intent
That would be an improvement... Also, what's the status of this limitation (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) :
when:do: anActionBlock subscription does
not work weakly, you are constrained to when:send:to
IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html)
yes. we can add Ephemerons at any moment now. But then people should use only VMs built on Jenkins, because Eliot's VMs not support them.
-- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnouncer... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
On Sun, Jun 17, 2012 at 7:40 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 June 2012 15:09, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
I bet if you do that, some people will be alienated/antagonized by this change
Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in
:)
Like pulling off a BandAid... the best thing to do is pull fast and get it over with.
Igor Stasenko wrote
As a compromise i would suggest to force people to explicitly tell their intent
That would be an improvement... Also, what's the status of this limitation ( http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html ) :
when:do: anActionBlock subscription does
not work weakly, you are constrained to when:send:to
IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html)
yes. we can add Ephemerons at any moment now. But then people should use only VMs built on Jenkins, because Eliot's VMs not support them.
I wish you would reconsider and reimplement VM ephemeron support using the format field as we discussed not the class hack you've implemented which is I think buggy and unsafe.
-- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnouncer... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
-- best, Eliot
On 18 June 2012 01:36, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Sun, Jun 17, 2012 at 7:40 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 17 June 2012 15:09, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote
I bet if you do that, some people will be alienated/antagonized by this change
Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in :) Like pulling off a BandAid... the best thing to do is pull fast and get it over with.
Igor Stasenko wrote
As a compromise i would suggest to force people to explicitly tell their intent
That would be an improvement... Also, what's the status of this limitation
(http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) :
when:do: anActionBlock subscription does
not work weakly, you are constrained to when:send:to
IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html)
yes. we can add Ephemerons at any moment now. But then people should use only VMs built on Jenkins, because Eliot's VMs not support them.
I wish you would reconsider and reimplement VM ephemeron support using the format field as we discussed not the class hack you've implemented which is I think buggy and unsafe.
I don't think changing the format will make it less buggy. The main problem (or perhaps uncertainty) which i faced is the routines to manage stack/JIT space, which run after usual heap tracing is done, which not very well fit with ephemeron strategy, and it won't change if i just use different format. See the #markPhase: i inserted "Process ephemerons" +++ self processEphemeronsQueue: fullGCFlag. before following: "Free unused stack pages. Only safe to free stack pages after all have been traced. " fullGCFlag ifTrue: [ self freeUnusedStackPages ]. "Only safe to free any machine code methods after all stack pages have been traced." self markAndTraceOrFreeMachineCode: fullGCFlag. that means that potentially (in some very unlikely situation), if new ephemeron will be disovered in #markAndTraceOrFreeMachineCode , it won't be processed as it should. I still don't understand why you tracing machine code, because this is just a cache of corresponding compiled methods, and discovering references which reachable only via machine code but not via conventional object memory heap, should actually point to an error in design. And that's why by knowing that, i were so bold to put #processEphemeronsQueue: before that code. So, if an object format is the only concern, and not the above, i can just change it (thanks we have unused format #5 ). -- Best regards, Igor Stasenko.
and besides, concerning buggy, the tests which i implemented for ephemerons are green. It maybe, that tests are not fully cover the specs.. sure it can be possible. So if you have some more complex/tricky tests in mind, feel free to add them. -- Best regards, Igor Stasenko.
Igor could you tell us what we should do with the issues on handle (feedback of lukas) http://code.google.com/p/pharo/issues/detail?id=5145 Stef On Jun 16, 2012, at 11:09 PM, Igor Stasenko wrote:
On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi, with the help of Guille I noticed that normal instances usually register weakly:
TestRunner >> initialize ..... SystemAnnouncer current weak on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. .....
and classes don't:
TestCase class >> registerForNotifications ... SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self.
so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ?
Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it.
thanks for the explanation,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
On 17 June 2012 09:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Igor
could you tell us what we should do with the issues on handle (feedback of lukas)
http://code.google.com/p/pharo/issues/detail?id=5145
Stef
oh, i thought this was already integrated. i think we shall integrate it, and then we will see. the main change is allow object-based announcements, as long an object understands #handlesAnnouncement: message.
On Jun 16, 2012, at 11:09 PM, Igor Stasenko wrote:
On 16 June 2012 22:51, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
Hi, with the help of Guille I noticed that normal instances usually register weakly:
TestRunner >> initialize ..... SystemAnnouncer current     weak     on: ClassAdded, CategoryAdded, ClassRemoved, CategoryRemoved, ClassRenamed, CategoryRenamed, ClassRecategorized send: #update to: self. .....
and classes don't:
TestCase class >> registerForNotifications   ...   SystemAnnouncer current on: MethodAdded, MethodModified, MethodRemoved send: #methodChanged: to: self.
so..Guille told me this is because usually the cycle-life of instances is short in comparisson with classes. But classes can be removed as well. What happen then? the announcer will hold always a reference to an obsolete class? my question is, should we always use weakly? if not, why ?
Yes, i think most of subscriptions should be weak, because it is kind of implied by loose-coupling. And classes is not an exception - because then you don't need to explicitly unsubscribe, and don't have to worry that it kept in memory just because you forgot to do it.
thanks for the explanation,
-- Mariano http://marianopeck.wordpress.com
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
participants (6)
-
Eliot Miranda -
Guillermo Polito -
Igor Stasenko -
Mariano Martinez Peck -
Sean P. DeNigris -
Stéphane Ducasse