[squeak-dev] Re: Monticello 1.6 features

Matthew Fulmer tapplek at gmail.com
Sat Jul 4 22:26:45 UTC 2009


On Sat, Jul 04, 2009 at 02:56:04PM -0700, Andreas Raab wrote:
> Matthew Fulmer wrote:
> >> * 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. 
> 
> Wow. This sounds like an excellent reason to switch to MC 1.6 since this 
> has been a constant nightmare in the back of my for dealing with 
> incremental updates. Is 1.6 ready for wide-spread use?

Nearly.

The atomic loader cannot handle Traits, and this is non-trivial
to fix. However, Monticello could fall back to the sequential
loader when it detects a package with traits, as it is able to
handle them. As there are currently very few packages using
traits, this would make the reliability of mc1.6 available to
nearly all developers. Currently, the choice between the atomic
loader and the sequential loader is a user-settable preference
(Preferences > monticello > useAtomicLoader), set false in 1.5
and true in 1.6. This is the only difference between the two
versions, the setting of this switch.

One problem that users will nearly immediately run into,
however, is a long-standing bug regarding the order in which
class initialization methods are run. This causes some packages
(I forget a good example) to fail to load, as the multiple
initialization methods are run in a different order than what
MC1.0 would have run them. Arguably it's bad practice to rely on
the order in which class initialization methods are run, but I
see no reason to give MC1.6 the right to break packages that
used to work.

Those are the only two bugs I know of that actually cause MC1.6
to load a package improperly. I used MC1.6 myself for nearly a
year, and fixed any bugs that caused improper loads. The above
two are the only ones I know of that remain.

It has another bug in which obsolete classes are sometimes left
around, but that is less visible than the above two.

-- 
Matthew Fulmer -- http://mtfulmer.wordpress.com/



More information about the Squeak-dev mailing list