On 28 Jan 2010, at 07:16, Andreas Raab wrote:

> keith wrote:
>> It sounds like you loaded the right thing. You just need to turn  
>> the "useAtomicLoading" preference off, this uses MCPackageLoader1b,  
>> the non atomic loading code.
>
> So I tried this too and it doesn't get very far either (same process  
> described earlier). It fails very early on when it's trying to load  
> a variant of ProgressInitiationException>>defaultMorphicAction. The  
> failure originates from MCMethodDefinition>>preloadOver: which  
> actually *removes* the selector that is being changed.
>
> This is a fatal flaw since removing a method that's about to be  
> modified can't possibly work when it comes to any system critical  
> methods (compiler etc. comes to mind but even the progress display  
> is enought to blow up). This version won't be able to deal with  
> many, many changes that went into the trunk.
>
> Cheers,
>  - Andreas

Sigh,

Like I said, different bugs in different places.

The 1b loader tries to pre-empt problems, whereas the original loader  
just waits for the problems to occur, and catches the exceptions. It  
turns out that the 1b approach is a lot harder.

If I recall, and my memory is failing, methods are removed, in order  
to accomodate lukas' difficult load scenario, where the change in the  
instance vars breaks things.

We did think of returning to the old loader approach at one point, but  
figured it would be better to get AtomicLoading to work. So now we are  
caught in the middle.

Keith