Kind of postmortem analysis for 3.9

Pavel Krivanek squeak1 at
Mon Oct 9 13:36:10 UTC 2006

Some next MC comments:

- the classes initialization part must be optional
- the classes must be initialized in the right order. When I was
preparing the MC packages for my kernel image, I saw that sometimes
the inherited class is initialized before the parent class. If the
derived class needs for example some parent constants during class
initialization, it may fail.
- there must be possible to create class definition change. For
example if some package adds an instance variable (and some next
methods) to a class that is not part of the package
- as far as I remember it was not possible to create a package that
contained only new method extension for a trait

If this will be solved, if packages will include package
initialization scripts and if it will be possible to define package
that contains code of several next packages, it will be possible to
create MC package for the RestOfSqueak of my kernel image

-- Pavel

On 10/9/06, Stéphane Ducasse <stephane.ducasse at> wrote:
> May be this email did not show up, so I resent it
> Hi
> Here are some thoughts about the problems we got with 3.9.
> - MC misses the notion of slices (groups of packages version together).
> When introducing a changes touching different packages we need to
> identify the changes as a
> slice of brotherhood of packages.
>         -- would be good for slices identification but also to be able to
> load a given version or tag it.
>         - - seems that MC2 is going in that direction.
> We need the ability to define a certain state (that consists of
> multiple packages all with a certain version)
> as one overall version. Like we would do in CVS with taging.
> Then, related but different: patches are cross-cutting. That's what
> nice with a .cs: "This is the fix of bug X". Applying
> the fix will change set version of the package, but we don't want to
> loose the information that all these changes are
> one thing.
> Right now we have no way of expressing that with MC, changesets did
> that quite well.
> - Moving methods between packages is difficult. We LOST a LOT of time
> there. In particular the way class extension is encoded in string of
> category is a pain. Since we can load a cs which can contain a
> category reorganization and we could lose simply the package
> extensions. So there is a real clash of way of managing the code.
> - In general, we need package refactorings.. splitting, joining,
> moving stuff between them.
> - having an load and unload actions protocols would be nice.
> - atomic loading is really needed. Apparently SystemEditor (funny
> name, aka atomic loader) is doing that. So this should be really
> investigated. We lost a LOT of energy/time there.
> - We should invest in better tests and a test server.
> Not only a test server, but an integration server: Building up a
> bigger image from a  smaller one, then runs
> all the tests.
> - Package decomposition and responsibility started to work.
> - SqueakMap should be improved to avoid all the problems with the
> data corruption.
> - Took too much time. Would be good to have a 6 months release cycle
> - Should have given name to source = 39a, 39b....
> - Good idea to have release candidates
> - We should have removed packages (nebraska and other much earlier)
> We got trapped at the end with that.
> Stef and Marcus

More information about the Squeak-dev mailing list