we really need help

[Adrian Lienhard]

I've finally had a look into the issues reported by Stef and Macrus.

The scripts 5 and 6 were already working, though, I think the problem  
that Stef run into was because he tried to directly load script 6  
without loading script 5 before (which crashes for some reason I  
didn't investigate further).

Apart from factoring out some code in the ScriptLoader I did some  
simple optimization: Stef argued to always have the full list of  
versions for consistency. The problem with that is that the set of  
versions the merger has to deal with, becomes unnecessarily big. I  
added a filtering that sorts out the versions that are already loaded  
in the current image and hence can be left out.

Also, I added methods loadOneAfterTheOther: and loadTogether:. This  
should help to do the different kind of bootstrapping scripts we  
need: the former to be able to load versions in a specific order and  
the latter to load a bunch of versions together (which is for example  
needed for MorphicSplitters changes because it move methods between  
packages). If possible, I think the former should be used because I  
guess it is faster (haven't confirmed that).

I propose the following usage of script builder (at least until we  
have some other mechanism): have update methods like  
ScriptLoader>>updateFrom6693 that include all scripts to bring an  
image of this version (6693) up to date or to the next image version.  
Currently, updateFrom6693 includes script5 and script6.

I published ScriptLoader to the 3.9 inbox.

Daniel asked for specific problems that should be addressed and that  
other people can help with. So, here is a list:

- image grow: after running updateFrom6693 and evaluating  
"MCCacheRepository flushAllCaches" the image size is still about  
30MB, more than double of the size compared to before loading.

- get rid of merge dialog. I tried to do a load instead of a merge  
but run into problems during load phase. But I don't see what should  
be different between merge and load in this case.

- dirty packages that actually don't have a change (are new ones  
without repository)

- loading is very, very slow (this is a general MC, or even Squeak,  
problem)

- the script builder is an ad hoc solution to do bootstrapping.  
ConfigMaps (as I understand them would do only one part, that is,  
loading versions in a specific order). So, we should think about  
addressing the issues with MC in a more general manner, e.g., by  
enhancing ConfigMaps?

I hope, this will help to get the harvesting process running again...

Cheers,
Adrian


On Oct 11, 2005, at 7:57 PM, stéphane ducasse wrote:


> could you send me the cs that we integrated on your machine?
> Because digging in mcz and configuration is not that easy.
> This way I can try to recreate a new config with only isRectangle  
> and then insetBy:
> and continue harvesting.
>
> Stef
>
> On 10 oct. 05, at 21:36, 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
>>
>>
>>
>
>
>