On 31.08.2009, at 21:58, Eliot Miranda wrote:

>
>
> On Sun, Aug 30, 2009 at 8:56 PM, Andreas Raab <andreas.raab at gmx.de>  
> wrote:
> Folks -
>
> We're all clear now. The problem with trunk updating was caused by  
> Monticello (more precisely Monticello-rej.309) which attempted to  
> make MC loading atomic but in the process introduced some serious  
> breakage in MC. In short, what the changes did was to first compile  
> new methods and classes and defer installation the newly compiled  
> methods until later. That sounds good at first but only to the point  
> where you realize that methods often need to be recompiled in the  
> process of class definition changes.
>
> In this case, we had various methods in subclasses of  
> CharacterScanner which were updated at the same time as a new  
> variable was added in CharacterScanner (pendingKernX). The process  
> involved compiling some methods with the *old* CharacterScanner  
> definition and some methods with the *new* CharacterScanner  
> definition (depending on whether the method was compiled before or  
> after CharacterScanner's redefinition). As a consequence, when the  
> methods were installed (some of which referred to the old, and some  
> of which referred to the new layout) everything crashed and burned.
>
> I have added a workaround in the form of an extra loading pass in MC  
> that first loads class definitions and then the rest. This gets us  
> past the hurdle but is probably not a proper long-term solution. Any  
> ideas on how to address this issue would be greatly appreciated. At  
> this point I'm leaning towards getting rid of MC's dependency driven  
> load process and replace it with a declarative version that is  
> explicit about what it does (i.e., adding/removing categories,  
> adding/redefining/removing classes, adding/redefining/removing  
> traits, adding/redefining/removing methods etc.) since the current  
> MC version also has the problem that removals now again happen  
> before additions which is yet another problem.
>
> If one doesn't have a truly atomic install then it seems to me that  
> the safest order is as follows:
>
> 1. make a pass that adds instance variables & class variables,  
> leaving any to-be-deleted instance & class variables in place
> 2. compile and install added methods (this still isn't safe since  
> one may add a method that overrides a method in a superclass, but  
> its a reasonable default)
> 3. compile and install modified methods; these can rely on instance  
> variables and new methods having been added (pace the aforementioned  
> override gotcha)
> 4. remove methods
> 5. delete instance & class variables
>
> If you want to do a real atomic install you have to
> - create a duplicate class hierarchy of all classes with any  
> modification, only sharing methods on classes whose shape doesn't  
> change between the actual class and the shadow class, and   
> recompiling methods on classes whose shape changes
> - collect all the instances of all the classes
> - do a mass become that replaces the classes with their shadows and  
> updates instances in one go
>
> Which ever approach one takes, a safer order or a truly atomic  
> install, I think the right approach is a plan/execute one (a.k.a.  
> compile) where the various updates are created as a sequence of  
> operation objects before being run together in some context, instead  
> of interpreting.
>
> Presumably (Hi Colin,) the MC2.0 atomic install works somewhat like  
> this.  The question is therefore whether one should try and extract  
> that from MC2 or move to MC2 adding backward compatibility to load  
> MC1.5 format packages.

I don't think MC1.5 changed the package format - did it? But it uses  
the same SystemEditor as MC2. Which supposedly gets all this right.

- Bert -


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090831/9e1f40cd/attachment.htm