we really need help

[Daniel Vainsencher]

Ok, a couple of things:
1. why should those scripts ever specify load? to my understanding, load 
vs. merge should always be controlled by a preference, so that 
developers are always able to merge their own changes. What do you think?
2. I put in inbox a version that doesn't bring up the merge dialog if 
there are no conflicts.

Adrian Lienhard wrote:
> 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.
What image are you starting from? the one I tried started and ended at 
around 27MB. I'll explore this, but I can't say I understand what the 
images mean exactly at the moment.

> - 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.
Got rid of the merge dialog for the case in which it is desirable. If 
there are conflicts, they need to be resolved explicitly.

> - dirty packages that actually don't have a change (are new ones  
> without repository)
Can someone give me a precise, tested scenario that shows this? when I 
last explored this I found that the flag was really required.

> - loading is very, very slow (this is a general MC, or even Squeak,  
> problem)
True, but we need a specific, real scenario to profile and optimize. 
BTW, are we talking also when loading a diff, or when loading mcz files?

> - 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 started out on making config maps do the load together, but actually, 
I'm not sure they are an improvement over the script loader - lots of 
code there we don't need (displaying them in repositories). I propose we 
get this working well, then think whether the code wants a different 
interface.

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