About MC for managing the image

[stéphane ducasse]

On 18 sept. 05, at 21:39, Andreas Raab wrote:

> Hi -
>
>
>> The implications with this setup is that we have to produce often  
>> an image (validate a configuration of changes working together) and
>>
> > this can be quite painful. At least they are a lot of try and error
>
>> when there are a lot of dependencies between packages.
>>
>
> In my experience that's a sign that a) you haven't found a good  
> package structure and/or b) you don't test early enough. In the  
> first case the effect is that higher-level changes get intermangled  
> with lower-level changes (that do in fact require careful folding  
> into a running system).

Not sure we got a problem with deltas since we got a change that  
removed a classVar on compiled method and the diff
was not in sync.

> An indication towards that point is the effect that the Kernel  
> package has (I think) the most revisions, where clearly it is one  
> of the most stable packages (if it isn't we're in big trouble) and  
> should have the least number of modifications. The same is probably  
> true for Morphic at this point - you *need* a better package  
> structure for Morphic which makes clear when you touch the critical  
> parts (requiring very careful testing) and when the non-critical ones.

Yes but this is exactly what we were doing with the introduction of  
morphic splitters. Now I simply cannot load the
morphic splitters changes since they move classes around and  
introduced packages. I think that the script idea
is not good for package restructuring. Because the morphic splitters  
is not complex but still finding the right order is terrible.
Squeak died on me when I tried to load Morphic-aftermorphicsplitters.  
And I could NOT try sooner since we got a large
set of changes from the morphicsplitter team.

> In comparison, in Tweak I can typically tell by just looking at the  
> package name whether this will require any effort to make sure it  
> loads correctly or not.

I imagine.
Once your system is well factored and if you do not change the  
structure it should work.

> It is also really important to test "early enough" whether you can  
> load a package or not after you've done a modification.  
> Unfortunately, you guys are somewhat handicapped since you don't  
> have an automatic default update mechanism like we're using in  
> Tweak. When I post a new version of a package that has even the  
> slightest chance to affect anything I immediately get a fresh  
> image, hit update and test it.

this was what I did with Envy...
Joseph always told me that you have only finished when you can load  
from a fresh image.
I do the same with store.
Now previously this was easier since this is my code :)
I know it and this is easier and smaller.

> Cost me perhaps twenty seconds but if it doesn't work I can easily  
> either post an appropriate configuration or make a change to the  
> package to make it load and post a new version of the package. I  
> really couldn't imagine to work like you do,

me too so this is why it should change or 3.9 is stuck. Nobody will  
want to do that.

> e.g., make a whole set of new package versions, try to load and  
> figure out where and why it dies.

But how can we do something else?


What I'm trying now is to use MC fully.
So I did
     a squeak package
         added all the packages as dependent
         saved.
     loaded all the morphic splitters
     updated the squeak required packages
     saved
     and now I'm trying to load from the latest image to see if this  
is working
     this is just plain slow and I'm waiting to see the result.

I hope that this is good. Because I think that this is the right way  
to use MC.

>> Bert I have the impression that using package dependencies with a
>>
> > root package (ie havgin Squeak and all the image package as
> > required) would help to minimize inter package dependencies,
> > now why do you use your script (the explicit  list of packages)
>
>> instead of required package. Is it because you can push that in the
>>
> > update stream?
>
> Early on we looked at using dependencies but they didn't work very  
> well for what we wanted to do. Most importantly, if you have a  
> newer version of a package it will load the older version instead  
> (VERY bad).

I think that this is disconnected. The process should be
- load the latest build
- check most recent package (or the build should always be the most  
recent ie. we do not publish individual packages)

Avi?
What is your point of view on that.?

> There were also some serious issues with nested dependencies (Bert  
> and I had a lot of fun figuring that out).

I think that we should not use nested dependencies.

> And keep in mind that dependencies are not as good as a load-order  
> since they typically only specify a partial  relation (A dependsOn:  
> X and B dependsOn: X does not specify whether A is loaded before B  
> or vice versa) whereas we wanted to make sure that the updating  
> process uses a single well-defined load order for everyone.

I see.
But right now there are situation where I simply cannot load at all.