Fwd: Confused about SystemChangeNotification

Alexandre Bergel bergel at iam.unibe.ch
Fri May 13 21:43:13 UTC 2005


Hello,

I almost spent the complete day to work on the test that Roel did for the System Change Notification. These tests are quite nice, it is really a pleasure to read them. What a good job you did Roel!

Roel made them a long time ago, but since the System Change notification (SCN) evolved. Because it is something critical, I updated the test. 62 tests are green out of 64. The 2 lefts require some more thoughts. 

By adapting these tests I found several bugs in the current version of the SCN. In the attached file, I put the tests and some fixes. 

I will put them on Mantis.

I can produce a single change set if needed...

Cheers,
Alexandre


On Fri, May 13, 2005 at 09:28:13AM +0200, stéphane ducasse wrote:
> peux-tu regarder et mettre a jour les tests de roel pour le system 
> notification?
> 
> Stef
> 
> Begin forwarded message:
> 
> >From: Roel Wuyts <Roel.Wuyts at ulb.ac.be>
> >Date: 13 mai 2005 8:44:44 GMT+02:00
> >To: Andreas Raab <andreas.raab at gmx.de>
> >Cc: Nathanael Schärli <n.schaerli at gmx.net>, Stephane Ducasse 
> ><ducasse at iam.unibe.ch>
> >Subject: Re: Confused about SystemChangeNotification
> >
> >Hah, found them. At least, I think it is the latest version (not sure 
> >though).
> >Had a quick look and found that I did the work for class 
> >recategorization, but not for methods "re-protocolization'. So you're 
> >free to go :-)
> >
> >Is there a specific place these tests should be put (I think it's 
> >absolutely necessary to have them around somewhere if tools really 
> >depend on it). Nathanael, was there a specific reason not to include 
> >them?
> >


> >
> >On 11 May 2005, at 02:55, Andreas Raab wrote:
> >
> >>Thanks for forwarding (I had missed this on Squeak-dev). Can you by 
> >>any chance dig up your old tests? I am curious if they might bring 
> >>some clarification about these issues (even if it only shows that you 
> >>didn't specifically test the behavior - in which case I'll change it 
> >>since it doesn't break the tests, right? ;-)
> >>
> >>Cheers,
> >>  - Andreas
> >>
> >>Roel Wuyts wrote:
> >>
> >>>Begin forwarded message:
> >>>
> >>>>From: Roel Wuyts <Roel.Wuyts at ulb.ac.be>
> >>>>Date: Fri 6 May 2005 14:35:45 CEST
> >>>>To: The general-purpose Squeak developers list 
> >>>><squeak-dev at lists.squeakfoundation.org>
> >>>>Subject: Re: Confused about SystemChangeNotification
> >>>>Reply-To: The general-purpose Squeak developers list 
> >>>><squeak-dev at lists.squeakfoundation.org>
> >>>>
> >>>>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 at lists.squeakfoundation.org
> >>>>>>[mailto:squeak-dev-bounces at 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 at 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
> >>>>
> >>>>
> >>>>
> >>>>
> >>>Roel Wuyts                                                           
> >>>     DeComp
> >>>roel.wuyts at 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
> >>>
> >>
> >>
> >


-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SystemChangeNotification.zip
Type: application/x-zip-compressed
Size: 14782 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050513/3e043e2d/SystemChangeNotification.bin


More information about the Squeak-dev mailing list