[squeak-dev] Monticello 1.6 features (was: Monticello/MCM tricks)
Matthew Fulmer
tapplek at gmail.com
Sat Jul 4 20:17:39 UTC 2009
On Sat, Jul 04, 2009 at 12:18:11PM -0700, Andreas Raab wrote:
> Ken Causey wrote:
> > Oh good, I have to admit I wasn't absolutely sure there wasn't something
> > more I needed to do.
>
> If the change is local to a single package there is not much you need to
> do. Monticello is reasonable in this case and the updater will just load
> the version of the package. Where it gets nasty is:
>
> * When you rename classes (this may have been addressed in one of the
> later MC versions?) as Monticello will delete the old class mercilessly,
> leaving all the instances in the dust
No Monticello version deals correctly with this case.
DeltaStreams does, however. SystemEditor can handle this case,
but the Monticello snapshot mechanism simply looks at the state
of the system and stores no metadata about what changed between
versions
> * When you move classes between packages where you need to issue an
> update.mcm so that you have the destination package before the source
> package so that the class doesn't get deleted in the middle (of course,
> some of the time the update.mcm will be in the right order and you get
> lucky ;-)
With MC1.6, if the packages are loaded together, it should
always work, but I don't think I ever tested this. MCM's
probably load packages together; I've never looked at them.
> * When you have system methods that are modified during load and rely on
> new methods in the package. This is by far the biggest issue (and a
> problem even with Change Sets). For example,
> http://bugs.squeak.org/view.php?id=6535 contains a change to
> OrderedCollection>>copyFrom:to: which utilizes postCopyFrom:to: that is
> defined in the same place. In change sets you can at least manually
> reorder the methods. Monticello does it unpredictably so it may work for
> one person and not for another (I wish MC would load methods in a
> well-defined order).
This is never a problem in MC1.6, period. In MC1.6, the new code is
never run until the entire package is loaded; during the load,
the system is static; only after the load is the new code. MC1.6
is able to move instance variables and rename core Monticello
methods during the load, with never a hiccup.
MC1.5 is an improved version of Monticello with a number of bug
fixes and improvements:
- compatibility with both the 3.8 and the 3.9 format of .mcz
files.
- Better handling of out-of-order loading: loading extensions
and subclasses of not-yet-loaded classes is delayed until the
missing class is loaded.
- More versatile package naming; branching and real-world version
numbers are supported: Monticello-mtf.experimental.1.5.147
- A new dual changes tool, that can quickly compare arbitrary
versions without loading
- A recent history of commit messages, so you can reuse them
easily (merged from Pharo)
- Completely rewritten image scanning code, resulting in about
10x faster snapshotting.
- And some others.
MC1.6 is identical to MC1.5, except that it has a vastly smarter
loader, which first compiles all classes and methods outside the
live class hierarchy, then migrates all methods, classes, and
instances during a single mass-become primitive, making it truly
atomic, and up to 6x faster at loading.
There are currently 2 outstanding bugs in MC1.6:
- No traits support in SystemEditor
- SystemEditor is the engine that manages the compilation and
migration of the temporary classes and methods outside the
class hierarchy. It needs to know a lot about the internal
structure of Classes to do this, but it was never taught
about Traits, and I have not yet finished this coding.
- Obsolete classes are sometimes left behind
And one bug in both MC1.5 and 1.6:
- Class initialization methods are run in a different order than
previous Monticellos.
- This causes problems when loading some packages from
Universes, although I forget which packages.
--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
More information about the Squeak-dev
mailing list
|