we really need help
daniel.vainsencher at gmail.com
Sun Oct 16 01:37:11 UTC 2005
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,
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
> I hope, this will help to get the harvesting process running again...
> 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.
>> On 10 oct. 05, at 21:36, Marcus Denker wrote:
>>> 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
>>> package, so just loading "kernel" will delete that method.
More information about the Packages