Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
a) When I compile a method in another category, no recategorized event is generated. Why? It is impossible to find out where a method "came from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector withMethod: compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains - why do it in the first place?
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the environment we get it under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the invariant "aClass == aClass environment at: aClass name" is temporarily broken. Why?
If there are any good reasons for the strange behavior above I'd really like to know why it behaves that way.
Cheers, - Andreas
On Wed, Apr 27, 2005 at 02:27:46PM -0700, Andreas Raab wrote:
Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
Hi Andreas,
I can't answer your questions directly, but be sure to check Mantis bug number #856. This affected Squeak versions after 3.6. I think that the fix has been applied to Squeak 3.9, but 3.8 and 3.7 may still be broken. At any rate, the issue is still listed as "new" on Mantis so I don't know the real status.
Dave
Am 28.04.2005 um 12:49 schrieb David T. Lewis:
On Wed, Apr 27, 2005 at 02:27:46PM -0700, Andreas Raab wrote:
Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
Hi Andreas,
I can't answer your questions directly, but be sure to check Mantis bug number #856. This affected Squeak versions after 3.6. I think that the fix has been applied to Squeak 3.9, but 3.8 and 3.7 may still be broken. At any rate, the issue is still listed as "new" on Mantis so I don't know the real status.
Can't see what http://bugs.impara.de/view.php?id=856 should have to do with the problem ...
- Bert -
Thanks, but #856 has nothing to do with it. Anyone else who can shed light on it? Who wrote it?
Cheers, - Andreas
David T. Lewis wrote:
On Wed, Apr 27, 2005 at 02:27:46PM -0700, Andreas Raab wrote:
Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
Hi Andreas,
I can't answer your questions directly, but be sure to check Mantis bug number #856. This affected Squeak versions after 3.6. I think that the fix has been applied to Squeak 3.9, but 3.8 and 3.7 may still be broken. At any rate, the issue is still listed as "new" on Mantis so I don't know the real status.
Dave
Apologies for the typo, I was still on my first cup of coffee. I meant to refer you to this:
0000845: ChangeSet losing class category changes in Squeak 3.7+
Dave
On Thu, Apr 28, 2005 at 09:55:07AM -0700, Andreas Raab wrote:
Thanks, but #856 has nothing to do with it. Anyone else who can shed light on it? Who wrote it?
Cheers,
- Andreas
David T. Lewis wrote:
On Wed, Apr 27, 2005 at 02:27:46PM -0700, Andreas Raab wrote:
Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
Hi Andreas,
I can't answer your questions directly, but be sure to check Mantis bug number #856. This affected Squeak versions after 3.6. I think that the fix has been applied to Squeak 3.9, but 3.8 and 3.7 may still be broken. At any rate, the issue is still listed as "new" on Mantis so I don't know the real status.
Dave
Hi David,
0000845: ChangeSet losing class category changes in Squeak 3.7+
I checked this but it's only relevant in such that it exposes even more obscure behavior of SystemChangeNotification. For example, the notification that a class was recategorized happens to be done by ClassBuilder instead of SystemOrganizer. This is contrary to the pattern which we observe with classifying methods where the notification is handled by ClassOrganizer instead of Compiler or any other place. Having third parties notify these changes seems a fragile solution at best.
Cheers, - Andreas
PS. Okay, I'm sorry but I can't resist. Some of this code makes me sick - who came up with the great idea of requiring a pattern like:
anEvent itemKind = SystemChangeNotifier classKind
instead of a simple "anEvent isClassChange"? And, not unexpectedly, zero comments and zero tests. Instead 13 classes where -by my careful counting- three are probably more than enough (in Tweak I'd do it without any new classes at all). This is so grossly over-"engineered" it's hardly believable. Where is the cleanup crew when you need it?
a) When I compile a method in another category, no recategorized event is generated. Why? It is impossible to find out where a method "came from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector withMethod: compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains - why do it in the first place?
This is simply a bug. I fixed it and sent a fix to the mailing list a long time ago. But it seems that it got lost somehow. This is also something that Nathanael already pointed out.
I cannot find the Test that Roel wrote. There are a class EventTest and EventManagerTest
Alexandre
Alexandre Bergel bergel at iam.unibe.ch wrote:
This is simply a bug. I fixed it and sent a fix to the mailing list a long time ago. But it seems that it got lost somehow. This is also something that Nathanael already pointed out.
Could it be this:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088049....
In BFAV with ID 27105.
Ken
Hi Ken -
This looks like the fix for c) (the odd mixture of classbuilder handling class change notifications instead of SystemOrganization).
Cheers, - Andreas
Ken Causey wrote:
Alexandre Bergel bergel at iam.unibe.ch wrote:
This is simply a bug. I fixed it and sent a fix to the mailing list a long time ago. But it seems that it got lost somehow. This is also something that Nathanael already pointed out.
Could it be this:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/088049....
In BFAV with ID 27105.
Ken
andreas
will you push it in 3.8? 3.9? So that we do not lose it.
Stef
This looks like the fix for c) (the odd mixture of classbuilder handling class change notifications instead of SystemOrganization).
Cheers,
- Andreas
Ken Causey wrote:
Alexandre Bergel bergel at iam.unibe.ch wrote:
This is simply a bug. I fixed it and sent a fix to the mailing list a long time ago. But it seems that it got lost somehow. This is also something that Nathanael already pointed out.
Could it be this: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-February/ 088049.html In BFAV with ID 27105. Ken
--
I asked nathanael to reply since he refactored roel's code.
Stef
Hi -
I am running into ever more trouble with SystemChangeNotification. Can somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
a) When I compile a method in another category, no recategorized event is generated. Why? It is impossible to find out where a method "came from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector withMethod: compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains - why do it in the first place?
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the environment we get it under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the invariant "aClass == aClass environment at: aClass name" is temporarily broken. Why?
If there are any good reasons for the strange behavior above I'd really like to know why it behaves that way.
Cheers,
- Andreas
Hi Stef and Andreas
I asked nathanael to reply since he refactored roel's code.
Well, the word "refactoring" is maybe a bit too much. What I did was fixing whatever was necessary to make it actually work. However, the idea and structure of the framework is still Roel's. So, he should know the most about why he took certain design decisions.
a) When I compile a method in another category, no recategorized
event
is generated. Why? It is impossible to find out where a method "came
from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector
withMethod:
compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains - why do it
in
the first place?
I guess the reason is that this information is also not communicated in the older versions of Squeak. If a method is compiled in another category, the method
Changeset>>noteNewMethod:forClass:selector:priorMethod:
is called, and this also does not contain the information where a method came from. Therefore, I think what happened is that Roel tried to "emulate" the old protocol and simply forgot that more information (such as where the method "came from") would actually be very handy. I also didn't realize this when I integrated the code afterwards because I was mainly fixing bugs in an attempt to make sure that everything that used to work still works. (As I said above, I didn't add any new features and also kept Roel's design/architecture as it was.)
That said, I absolutely agree with Andreas that this information could be very useful and should be provided (especially, since it is quite easy to fix).
(BTW: Note that in older Squeaks, things were even worse because recategorization events never occured. Thus, if a method was recategorized with drag and drop, the changeset was not informed at all.)
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the environment we get
it
under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the
invariant
"aClass == aClass environment at: aClass name" is temporarily
broken.
Why?
Also for this question I can't really give a final answer as it concerns code from Roel. But again, I think the reason is that Roel's work is based on the older versions of Squeak, which shows the exact same artefact! In fact, in Squeak 3.6 (and earlier), there is a method
Changeset>>renameClass: class as: newName
which also gets called with the argument "class" still having the old name. So, I presume that Roel just replaced the call to this method (which happened in the Class>>rename:) with a call to the SystemChangeNotification mechanism. So, he kind of "inherited" this artefact.
That said, I again agree with Andreas that passing a class with the "new name" is safer and more consistent. Changing this should also not be too hard. However, since this is strictly speaking not a "fix" but a "change", we need to make sure that none of the existing code actually relies on the historic/traditional way of doing things.
Last but not least, I would like to say that while I'm convinced that having a mechanism that factors out system change notifications is very important, I also think that the current version is not quite ideal for several reasons. For example, I have a feeling that having so many different event classes is not always ideal because certain events often occur together and are related. (E.g., when a method is changed and compiled in a n ew category as well).
In this sense, it is important to view Roel's design not as a totally final/perfect solution, but more as the first attempt to do something better.
Cheers, Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of stéphane ducasse Sent: Sonntag, 1. Mai 2005 17:18 To: The general-purpose Squeak developers list Subject: Re: Confused about SystemChangeNotification
I asked nathanael to reply since he refactored roel's code.
Stef
Hi -
I am running into ever more trouble with
SystemChangeNotification. Can
somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
a) When I compile a method in another category, no
recategorized event
is generated. Why? It is impossible to find out where a
method "came
from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector
withMethod:
compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains -
why do it in
the first place?
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the
environment we get it
under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the
invariant
"aClass == aClass environment at: aClass name" is
temporarily broken.
Why?
If there are any good reasons for the strange behavior above I'd really like to know why it behaves that way.
Cheers,
- Andreas
Hi y'all!
I provided unit tests to sort out these things. I remember that I triggered a category-changed event for classes, for example, which I tested. All kind of renaming or removal events passed a string with the old name as argument, in case you needed to know. But I do not know what exactly Nathanael refactored, what parts got removed, etc.
So I wanted to check my unit tests but I could not find them in the stock 3.7 image that I downloaded. I can have a look at the code if someone can point me in the right direction.
PS: I remember some problems with class renames in general in 3.6 that I had to work around. I submitted a separate bugfix for this (there were some problems there). The system event changes were meant to be used in a Squeak where these patches were applied. Maybe they got added, or got added in a different fashion, and the change mechanism is unhappy about it. Again, the unit tests should show this (they used to fail in an image where these class-rename-patches were not loaded).
Regarding the 'design' of the system: I considered the unit tests the most important part of the implementation. Regarding the design itself: I started out with a more complicated system, but simplified it in the end. In the more complicated system I had general events and specific events. The specific events knew the general event they belonged to. Clients could register for all events, general events, or specific events. For example, some clients that keep a cache are interested in very fine-grained events (as it is now). But some other ones could do with a coarse-grained approach. After discussing with several people about this at Camp Smalltalk in Bled (Slovenia), I decided to only keep the fine-grained model. But of course I agree with Nathanael: this was not meant to be, nor is it, the 'perfect' solution.
On 02 May 2005, at 10:11, Nathanael Schärli wrote:
Hi Stef and Andreas
I asked nathanael to reply since he refactored roel's code.
Well, the word "refactoring" is maybe a bit too much. What I did was fixing whatever was necessary to make it actually work. However, the idea and structure of the framework is still Roel's. So, he should know the most about why he took certain design decisions.
a) When I compile a method in another category, no recategorized
event
is generated. Why? It is impossible to find out where a method "came
from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector
withMethod:
compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains - why do it
in
the first place?
I guess the reason is that this information is also not communicated in the older versions of Squeak. If a method is compiled in another category, the method
Changeset>>noteNewMethod:forClass:selector:priorMethod:
is called, and this also does not contain the information where a method came from. Therefore, I think what happened is that Roel tried to "emulate" the old protocol and simply forgot that more information (such as where the method "came from") would actually be very handy. I also didn't realize this when I integrated the code afterwards because I was mainly fixing bugs in an attempt to make sure that everything that used to work still works. (As I said above, I didn't add any new features and also kept Roel's design/architecture as it was.)
That said, I absolutely agree with Andreas that this information could be very useful and should be provided (especially, since it is quite easy to fix).
(BTW: Note that in older Squeaks, things were even worse because recategorization events never occured. Thus, if a method was recategorized with drag and drop, the changeset was not informed at all.)
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the environment we get
it
under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the
invariant
"aClass == aClass environment at: aClass name" is temporarily
broken.
Why?
Also for this question I can't really give a final answer as it concerns code from Roel. But again, I think the reason is that Roel's work is based on the older versions of Squeak, which shows the exact same artefact! In fact, in Squeak 3.6 (and earlier), there is a method
Changeset>>renameClass: class as: newName
which also gets called with the argument "class" still having the old name. So, I presume that Roel just replaced the call to this method (which happened in the Class>>rename:) with a call to the SystemChangeNotification mechanism. So, he kind of "inherited" this artefact.
That said, I again agree with Andreas that passing a class with the "new name" is safer and more consistent. Changing this should also not be too hard. However, since this is strictly speaking not a "fix" but a "change", we need to make sure that none of the existing code actually relies on the historic/traditional way of doing things.
Last but not least, I would like to say that while I'm convinced that having a mechanism that factors out system change notifications is very important, I also think that the current version is not quite ideal for several reasons. For example, I have a feeling that having so many different event classes is not always ideal because certain events often occur together and are related. (E.g., when a method is changed and compiled in a n ew category as well).
In this sense, it is important to view Roel's design not as a totally final/perfect solution, but more as the first attempt to do something better.
Cheers, Nathanael
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of stéphane ducasse Sent: Sonntag, 1. Mai 2005 17:18 To: The general-purpose Squeak developers list Subject: Re: Confused about SystemChangeNotification
I asked nathanael to reply since he refactored roel's code.
Stef
Hi -
I am running into ever more trouble with
SystemChangeNotification. Can
somebody give me a brief rundown on how it is supposed to work? Any tests associated with it to document boundary cases? Here are two rather obscure issues that I am just running into:
a) When I compile a method in another category, no
recategorized event
is generated. Why? It is impossible to find out where a
method "came
from" when using the modified event. This is easy to fix since the code in ClassDescription>>addAndClassifySelector: selector
withMethod:
compiledMethod inProtocol: category notifying: requestor explicitly suppresses this notification. But the question remains -
why do it in
the first place?
b) When renaming a class the renamed event refers to the class under the old name. In other words, rather than getting our hands on the class under the name by which it is known in the
environment we get it
under the old name which no longer exists in the environment. Why? This is totally inconsistent - it exposes the fact that the
invariant
"aClass == aClass environment at: aClass name" is
temporarily broken.
Why?
If there are any good reasons for the strange behavior above I'd really like to know why it behaves that way.
Cheers,
- Andreas
Roel Wuyts DeComp roel.wuyts@ulb.ac.be Université Libre de Bruxelles http://homepages.ulb.ac.be/~rowuyts/ Belgique Vice-President of the European Smalltalk Users Group: www.esug.org
squeak-dev@lists.squeakfoundation.org
-
Alexandre Bergel -
Andreas Raab -
Bert Freudenberg -
David T. Lewis -
Ken Causey -
Nathanael Schärli -
Roel Wuyts -
stéphane ducasse