[squeak-dev] Re: [Cuis] Cuis - Cross fork compatibility of packages: A proposal

Eliot Miranda eliot.miranda at gmail.com
Thu Jan 28 23:04:06 UTC 2010


On Thu, Jan 28, 2010 at 12:25 PM, keith <keith_hodges at yahoo.co.uk> wrote:

>
> 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.
>

What is this scenario?  Does it break the following load ordering?

- add all new inst and class vars to existing classes (avoiding deleting any
that need to be deleted until later)
- add all new classes
- add all new methods
- change all to be changed methods
- delete all to be deleted methods
- remove all inst and class vars from existing classes (deferred from step
1)




> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100128/38f6df7e/attachment.htm


More information about the Squeak-dev mailing list