Hi all
We ***really*** need help. I start to be really exhausted. Here is the problem:
Marcus introduced a fix to speed up morphic isRectangle instead of isKindOf: in insetBy: and collected some other fixes.
Now when we take a 6693 image - merge MC275 - load scriptLoader-md.6.mcz - execute script 6
you end up after merging to an infinite loop because SmallInteger does not know isRectangle (even thought isRectangle is defined on Object). This sounds like MC loaded first the method insetBy: and that the progress bar needs it and Object>>isRectangle is not loaded yet. So what can we do?
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:
So I do not know what to do except ordering things by hand. I lost really a lot of time and be completely unproductive. So does anybody have any suggestion?
Stef
Stef,
Just like with change sets (which would suffer from the same ordering problem of #insetBy: vs. isRectangle) you can't just throw all of these changes in the same pot and hope it'll work. You need to be a bit more orderly than that.
In this case, the solution is to make package version(s) which *only* includes the method #isRectangle; then post a configuration that ensures this package version is loaded; then commit the other fixes. That's basically the same way you'd use change sets - first make one that includes #isRectangle, then post the remaining changes.
There is simply no way by which MC could decide how to load these methods in the proper order. Sometimes you do need to give a helping hand when migrating a running system and that's one of the places.
Cheers, - Andreas
stéphane ducasse wrote:
Hi all
We ***really*** need help. I start to be really exhausted. Here is the problem:
Marcus introduced a fix to speed up morphic isRectangle instead of isKindOf: in insetBy: and collected some other fixes.
Now when we take a 6693 image - merge MC275 - load scriptLoader-md.6.mcz - execute script 6
you end up after merging to an infinite loop because SmallInteger does not know isRectangle (even thought isRectangle is defined on Object). This sounds like MC loaded first the method insetBy: and that the progress bar needs it and Object>>isRectangle is not loaded yet. So what can we do?
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:
So I do not know what to do except ordering things by hand. I lost really a lot of time and be completely unproductive. So does anybody have any suggestion?
Stef
On 10 oct. 05, at 19:24, Andreas Raab wrote:
Stef,
Just like with change sets (which would suffer from the same ordering problem of #insetBy: vs. isRectangle) you can't just throw all of these changes in the same pot and hope it'll work. You need to be a bit more orderly than that.
I know!!!!! But I understood that MC would solved this kind of problem. At least I tried.
In this case, the solution is to make package version(s) which *only* includes the method #isRectangle; then post a configuration that ensures this package version is loaded; then commit the other fixes. That's basically the same way you'd use change sets - first make one that includes #isRectangle, then post the remaining changes.
Yes of course. But again. I would like to see how we could get a real atomic load.
There is simply no way by which MC could decide how to load these methods in the proper order. Sometimes you do need to give a helping hand when migrating a running system and that's one of the places.
Yes. I'm really wondering how envy was doing since it was atomic.
Stef
Cheers,
- Andreas
stéphane ducasse wrote:
Hi all We ***really*** need help. I start to be really exhausted. Here is the problem: Marcus introduced a fix to speed up morphic isRectangle instead of isKindOf: in insetBy: and collected some other fixes. Now when we take a 6693 image - merge MC275 - load scriptLoader-md.6.mcz - execute script 6 you end up after merging to an infinite loop because SmallInteger does not know isRectangle (even thought isRectangle is defined on Object). This sounds like MC loaded first the method insetBy: and that the progress bar needs it and Object>>isRectangle is not loaded yet. So what can we do? 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: So I do not know what to do except ordering things by hand. I lost really a lot of time and be completely unproductive. So does anybody have any suggestion? Stef
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
Actually, this is exactly the kind of problem I was having with bootstrapping Traits. In that case it seemed like a pretty freak occurance (changing how methods are added), and wasn't worth implementing the general solutions, so Adrian and I went the route of creating several versions that load stuff in order.
But both I and Avi proposed general solutions, and from the case you're presenting now, it seems the problem might be common enough to warrant implementing one of them.
I'll describe the two solutions, since I'm not yet sure what the tradeoffs are. 1. Have the loader sort the methods. 2. Do an atomic change of the method dictionaries
The first: the loader already loads classes superclass-first, for the obvious reasons. So we can tell it to sort the methods also - if Foo>>bar calls #baz, load all implementations of #baz before loading Foo>>bar. Of course this won't always work, because two methods can be mutually recursive, but that's rare. The second: have the loader apply all changes to copies of the method dictionaries of the classes. Then atomically swap in the modified copies instead of the old ones. I guess this means to purge all caches and do an array-become. This requires vm knowledge to know whether it will require anything else.
What do you guys think?
Daniel
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
Actually, this is exactly the kind of problem I was having with bootstrapping Traits.
I'm sure.
In that case it seemed like a pretty freak occurance (changing how methods are added), and wasn't worth implementing the general solutions, so Adrian and I went the route of creating several versions that load stuff in order.
But both I and Avi proposed general solutions, and from the case you're presenting now, it seems the problem might be common enough to warrant implementing one of them.
This is my impression.
I'll describe the two solutions, since I'm not yet sure what the tradeoffs are.
- Have the loader sort the methods.
I have the impression that this is really difficult since we can have really complex control flow.
- Do an atomic change of the method dictionaries
Could be cool but no idea how practical it is.
The first: the loader already loads classes superclass-first, for the obvious reasons. So we can tell it to sort the methods also - if Foo>>bar calls #baz, load all implementations of #baz before loading Foo>>bar. Of course this won't always work, because two methods can be mutually recursive, but that's rare.
But in the case of the fix of marcus, isRectangle on Object should have been loaded first and apparently SmallInteger DNU isRectangle and the fix of marcus was on other classes.
The second: have the loader apply all changes to copies of the method dictionaries of the classes. Then atomically swap in the modified copies instead of the old ones. I guess this means to purge all caches and do an array-become. This requires vm knowledge to know whether it will require anything else.
I have no idea how Envy did it. I will ask joseph if he knows it.
What do you guys think?
Daniel
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
Hi,
I''ve had a quick look... As I understand there are basically two problems - MC speed - load order
For the first, MC is very slow for big packages. I think, that what Impara did with the diff MC versions was to get around this a bit, maybe this could help here, maybe improving dictionariy performance would help too. Anyway, I guess that the complexity is not linear, thus, looking at the scripts in ScriptLoader does not surprise me if this is really slow. Do you need _all_ packages in these scripts to be loaded at once? I suggest to decompose as much as possible, else working on the second problem becomes very painful. Another question: why do you do a merge instead of a load? I don't think its worth merging, if people have their own changes they have to deal with them before loading an image update (after all, that was what changesets did anyway). I guess, loading would again be faster than merging.
For the second problem (that's what I've been confronted concerning loading traits): If the changes are not that complex (as it seems to be in this case of FasterRectangelInsetBy) it should be doable with two packages that have to be loaded one after the other (thus, not using the merger of the script!). The backporting feature of MC can help here to create the pre-load package (backport all changes without the critical one to the previous version).
Maybe I can have a closer look in the evening. How can I get to the latest working version (IIRC, MorphicSplitters loading was working)?
Adrian
On Oct 10, 2005, at 9:36 PM, 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
On 11 oct. 05, at 09:56, Adrian Lienhard wrote:
Hi,
I''ve had a quick look... As I understand there are basically two problems
- MC speed
- load order
For the first, MC is very slow for big packages. I think, that what Impara did with the diff MC versions was to get around this a bit, maybe this could help here, maybe improving dictionariy performance would help too. Anyway, I guess that the complexity is not linear, thus, looking at the scripts in ScriptLoader does not surprise me if this is really slow. Do you need _all_ packages in these scripts to be loaded at once?
for me this is really important to have complete script for a version. Else we may have problem at the end.
I suggest to decompose as much as possible, else working on the second problem becomes very painful. Another question: why do you do a merge instead of a load? I don't think its worth merging, if people have their own changes they have to deal with them before loading an image update (after all, that was what changesets did anyway). I guess, loading would again be faster than merging.
I follow what avi and daniel suggested
For the second problem (that's what I've been confronted concerning loading traits): If the changes are not that complex (as it seems to be in this case of FasterRectangelInsetBy)
I would say that it is trivial.
it should be doable with two packages that have to be loaded one after the other (thus, not using the merger of the script!). The backporting feature of MC can help here to create the pre-load package (backport all changes without the critical one to the previous version).
I do not understand what is backporting.
Maybe I can have a closer look in the evening. How can I get to the latest working version (IIRC, MorphicSplitters loading was working)?
Yes script 5 is working well.
Stef
Adrian
On Oct 10, 2005, at 9:36 PM, 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
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
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 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?
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
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
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
On Oct 15, 2005, at 6:37 PM, Daniel Vainsencher wrote:
Ok, a couple of things:
- 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.
Daniel, I think our readerCache isn't getting flushed - needs something like
MCHttpRepository>>flushCache readerCache := nil. super flushCache
Avi
Makes sense. Adrian, can you check whether that does the trick?
Otherwise let me know what image to try.
Daniel
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.
On Oct 15, 2005, at 6:37 PM, Daniel Vainsencher wrote:
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.
Avi Bryant wrote:
Daniel, I think our readerCache isn't getting flushed - needs something like
MCHttpRepository>>flushCache readerCache := nil. super flushCache
Avi
On 16 oct. 05, at 03:37, Daniel Vainsencher wrote:
Ok, a couple of things:
- 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.
- 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
Hi adrian
I tried your scripts and they loaded well. Daniel your fixes is good for avoiding the merge dialog I added
MCHttpRepository>>flushCache readerCache := nil. super flushCache
But the image is still 23 Mb starting from 14 mb
Stef
Now I was looking at your compiler fixes and I tried to produce a new script but I wanted to have to load only one script and it failed with is normal since nothing has changed in MC.
Stef
On 16 oct. 05, at 13:13, stéphane ducasse wrote:
Hi adrian
I tried your scripts and they loaded well. Daniel your fixes is good for avoiding the merge dialog I added
MCHttpRepository>>flushCache readerCache := nil. super flushCache
But the image is still 23 Mb starting from 14 mb
Stef
packages@lists.squeakfoundation.org
-
Adrian Lienhard -
Andreas Raab -
Avi Bryant -
Daniel Vainsencher -
Marcus Denker -
stéphane ducasse