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.



> Cheers,
>  - Andreas
>
> Andreas Raab wrote:
>
>> Folks -
>>
>> Just as a warning, something went wrong in the last round of updates I
>> posted and I'm trying to understand what happened. I recommend you stay away
>> from updating until I send an "all clear" message.
>>
>> Cheers,
>>  - Andreas
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090831/874653b7/attachment.htm