we really need help

[stéphane ducasse]

> Actually, this is exactly the kind of problem I was having with  
> bootstrapping Traits.

I'm sure.

> In that case it seemed like a pretty freak occurance (changing how  
> methods are added), and wasn't worth implementing the general  
> solutions, so Adrian and I went the route of creating several  
> versions that load stuff in order.
>
> But both I and Avi proposed general solutions, and from the case  
> you're presenting now, it seems the problem might be common enough  
> to warrant implementing one of them.


This is my impression.

>
> I'll describe the two solutions, since I'm not yet sure what the  
> tradeoffs are.
> 1. Have the loader sort the methods.

I have the impression that this is really difficult since we can have  
really complex control flow.

> 2. Do an atomic change of the method dictionaries

Could be cool but no idea how practical it is.

> The first: the loader already loads classes superclass-first, for  
> the obvious reasons. So we can tell it to sort the methods also -  
> if Foo>>bar calls #baz, load all implementations of #baz before  
> loading Foo>>bar. Of course this won't always work, because two  
> methods can be mutually recursive, but that's rare.

But in the case of the fix of marcus, isRectangle on Object should  
have been loaded first and apparently SmallInteger DNU isRectangle  
and the fix of marcus was on other
classes.

> The second: have the loader apply all changes to copies of the  
> method dictionaries of the classes. Then atomically swap in the  
> modified copies instead of the old ones. I guess this means to  
> purge all caches and do an array-become. This requires vm knowledge  
> to know whether it will require anything else.

I have no idea how Envy did it. I will ask joseph if he knows it.

>
> What do you guys think?
>
> Daniel
>
> Marcus Denker wrote:
>
>> Hi,
>> Sadly I really have no time to work on Monticello... or even to  
>> look at
>> the current state too much. So no idea for that problem.
>> For sure, we need to get the whole mess working soon.... I will  
>> try  to find
>> some time, but I fear that this will need to wait till I'm settled  
>> in  Santiago,
>> so maybe end of next week.
>>
>>> I tried to tweak a bit the script by loading first kernel-md.42.mcz
>>> take a 6693 image
>>>     - merge MC275
>>>     - scriptloader-sd.8.mcz
>>>     script 6
>>>     - but now I get an error because Debugger does not know  
>>> stepAt:in:
>>>
>>>
>> This is caused by the fact that #stepAt:in: has been moved to the   
>> morphic
>> package, so just loading "kernel" will delete that method.
>>      Marcus
>>
>
>