we really need help

[stéphane ducasse]

On 14 oct. 05, at 15:09, Adrian Lienhard wrote:

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

This is was I was confused because normally a script should not have  
a dependency on another one.
The idea is to take an image and load the script and it should load.
Then if we encounter a problem we create a new image and restart from  
there.

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

Nice

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

Thanks.

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


Thanks adrian.
this is the right way to go.

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

I hope too. Even if I would prefer not to have dependency between  
scripts.
I think that this is important to try and learn and improve. So this  
is what we are doing...
I will try your scripts and published in 3.9alpha

Stef

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