upgrading monticello
Avi Bryant
avi at beta4.com
Sun Jan 25 21:13:25 UTC 2004
I've just posted two new releases of Monticello to SM, revisions #86
and #90. Why two? Because one of the bugs fixed in release 86 is
triggered by release 90 - so if you're upgrading from an earlier
version, you have to upgrade to 86 *first* (fixing the bug), and then
upgrade to 90 (no longer triggering it). If you try to upgrade
directly from, eg, 69 to 90, you'll get an error halfway through the
load and your image will be left in a horrible inconsistent state.
Don't do this. (Isn't self-hosting fun?) Just loading 90 into a clean
image should be fine, though.
I'm mostly pushing these releases out to get this annoying double
upgrade out of the way, but they do provide some benefit:
- The aforementioned bug fix. The bug had to do with updates that
moved inst vars from subclasses up to superclasses (or, in some cases,
vice versa). These always have to be done by first removing the inst
var from the old class and then adding it to the new one - if you don't
do that, the ClassBuilder will complain about duplicate instance
variables. New versions of Monticello handle this in a pretty rough
and ready way - any class or method definitions that have errors like
this when being loaded will be deferred until everything else has been
loaded, and the user will then be given the option to try loading the
deferred definitions again. The second time through, they should work.
- Some fixes from Ned, including a repository type that lets MC raid
the SqueakMap cache.
- A lot of cleanup of the reader/writer classes. The barely used .mcv
format is no longer supported at all, and support for .mc files has
been moved to MonticelloCVS, which is now the only thing that uses it.
If you're one of the few using MonticelloCVS, make sure you upgrade it
at the same time.
- Packages and their dependencies are now loaded as one atomic unit (as
much as MC can load anything atomically), which means that you don't
need to worry about ordering (you could, say, have a class in package A
that subclassed one in package B and a class in package B that
subclassed one in package A, and it should all load ok - not that I
recommend this).
There's still *lots* more work to do on the dependency mechanism,
though.
Avi
More information about the Squeak-dev
mailing list
|