On Feb 17, 2004, at 12:52 PM, Timothy Rowledge wrote:

>> SM2 is going into the update stream, which includes a simple 
>> bootstrap installer for MC packages.  So when 3.7 is released you 
>> will indeed be able to load a .mcz into a stock image.
> But would that be a sensible thing to do. If, as I get the impression, 
> an mcz file is a full history of development then it would probably be 
> a daft thing to distribute generally. No? Surely  pulling out a 
> current-version .sar is more generally useful?

It's not a full history of development - it's a snapshot of the code at 
a single point in time, with a UUID identifying that snapshot, and a 
record of the UUIDs of all the previous snapshots it's descended from.  
So it's a great thing to distribute, IMO.

>> Temporary methods is an interesting use case.  That's not something 
>> you can do with a .mcz.  What do you need it for?
> Good question. One of the methods in VMMaker is #touch  which is sent 
> as part of the noteCompilationOf:isMeta: override in 
> InterpreterPlugin. Because this got filed out in advance of the 
> implementation of #touch, I used a sar preamble to add a dummy #touch 
> to Object, then removed it in the postscript. You may be able to 
> suggest an alternative to this. I imagine filein ordering must have 
> been an issue somewhere in your MC experience.

Monticello has a fairly generalized ordering system where each 
definition can provide a list of symbols/classes/whatever that it 
"provides" as well as a list that it "requires", and MC will make sure 
that things aren't loaded until all their requirements are provided.  
So the trick would be to somehow annotate #noteCompilationOf: that it 
required #touch, so that the ordering would happen correctly.  Every 
time I bring up method annotations somebody complains, but if anyone 
can suggest a generally acceptable mechanism of recording this 
information I will happily build it into MC.