I am waiting for things of Stef regarding SystemDictionary, since one 
or two hooks are in there. I do not want to create dependencies between 
the SystemDictionary refactoring and the change notification, so one of 
the two has to wait a bit. Since I think that Stef will post the 
changes before I will post mine (he is alwasy done, if I understand 
correctly), I will wait for this.

The second thing is the fix regarding the event system I sent 
yesterday. Is it ok to just send it to the mailinglist with a tag 
[FIX], or is there anything else I have to do? Without this fix, some 
dependents are not cleaned up properly, which can be very annoying. 
Everytime you run the tests you then get more dependents in the 
notification system. With the fix, everything works ok.

Apart from the hooks, everything else should work in 3.6 (the rest is 
straightforward, simple stuff).

On Wednesday, Jul 30, 2003, at 13:46 Europe/Zurich, Daniel Vainsencher 
wrote:

> This is great. The KCP stuff you are waiting for - where is it in the
> pipe line? I haven't heard of KCP updates since the previous bundle, 
> and
> the KCP minnow page shows only one change.
>
> Anyway, 3.6 will probably not include any new KCP stuff. It is not
> strictly impossible, if they do not deprecate or break anything. But I
> do want to understand if anything is stopping you with the
> notifications.
>
> Daniel
>
> Roel Wuyts <wuyts at iam.unibe.ch> wrote:
>> I will now continue by adding more triggers for methods (in the 
>> current
>> Squeakmap version only method additions are triggered - classes and
>> doIts are fully done): removals, renaming, recategorization, ... .
>> Next step after that will be to add the triggers for instance 
>> variables
>> (creation, addition, removal).
>> Then categories and protocols.
>> Then pool variables etc.
>>
>> As soon as certain KCP things are in the update stream, I will port 
>> the
>> notifications to 3.6 (need to move some hooks, so I cannot move to 3.6
>> right now since I have to wait for these things to be done and get
>> accepted).
>>
>> PS: Note that the granularity of the notifications is smaller than 
>> what
>> you can currently get. For example, changing the superclass of a class
>> results in a Resupered event being sent, while without the
>> notifications you just know that the class definition has been 
>> changed,
>> but you do not know why (for a change in instance variables? a
>> recategorization? another superclass?). So the notifications
>> differentiate between all these different actions, which is quite cool
>> (I think :-), and more declarative).
>>
>> On Wednesday, Jul 30, 2003, at 12:51 Europe/Zurich, Stephane Ducasse
>> wrote:
>>
>>> So roel what is the next step?
>>>
>>> Stef
>>> On Tuesday, July 29, 2003, at 07:10 PM, Roel Wuyts wrote:
>>>
>>>> Subject says it all, really :-)
>>>>
>>>> Following Daniel's suggestion, the latest version can be found on
>>>> SqueakMap. New in this release is that the registered clients for an
>>>> event are notified synchronously, but all the ones that throw errors
>>>> or halts do not block the update; they are queued and re-signaled
>>>> when everything is done.
>>>>
>>>> --
>>>> Roel Wuyts                                                   
>>>> Software
>>>> Composition Group
>>>> roel.wuyts at iam.unibe.ch                       University of Bern,
>>>> Switzerland
>>>> http://www.iam.unibe.ch/~wuyts/
>>>> Board Member of the European Smalltalk User Group: www.esug.org
>>>>
>>>>
>>>
>>>
>> Roel Wuyts                                                   Software
>> Composition Group
>> roel.wuyts at iam.unibe.ch                       University of Bern,
>> Switzerland
>> http://www.iam.unibe.ch/~wuyts/
>> Board Member of the European Smalltalk User Group: www.esug.org
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org