we really need help

[stéphane ducasse]

On 16 oct. 05, at 03:37, Daniel Vainsencher wrote:

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

No idea. With load we got some problems and you with avi mentioned  
that merge should work better (and it worked better).
So I'm following.

> 2. I put in inbox a version that doesn't bring up the merge dialog  
> if there are no conflicts.

where? in ScriptLoader?
The inbox is not categorized right now. I will try to find some times  
(arghhhh) to collect the changes.
also the ones needed for traits.



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

Take the image 6693 and load script 4 normally you will dirty  
packages and no conflicts.
>
>
>> - 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?

mcz

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


Yes

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