we really need help
adi at netstyle.ch
Fri Oct 14 13:09:39 UTC 2005
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
- loading is very, very slow (this is a general MC, or even Squeak,
- 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
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
>> 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