[squeak-dev] Trunk Update Warning

On 8/31/09 6:44 AM, "Alexander Lazarević" <[hidden email]> wrote:

Edgar,

just did a clean update from scratch (based on the first trunk image published by andreas).

Alex

You mean do it all again from 7159 start image ?

It’s a long way, but if works...

On Sun, Aug 30, 2009 at 8:56 PM, Andreas Raab <[hidden email]> 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.