On Feb 17, 2004, at 3: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?

Actually, current practice is, in fact, to distribute mcz files. An mcz 
contains three things:

- packaging information, ie what package the code belongs to
- a fileOut of the package
- ancestry information

The third bit is just the metadata for the "full history of 
development." That is, what other versions contributed to the 
development of this version, who created them, when and why, etc. The 
source code to those versions is not included. It ends up being fairly 
compact, so it's not unreasonable to distribute with a release. It's 
also important that it be present if somebody decides to start hacking 
on your package. Then they can create a mcz with their version and it 
will have the correct ancestry information, enabling you to easily and 
correctly merge back it into your work.


>> 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.

MC does do some requirements analysis to ensure that definitions get 
loaded in a sensible order - classes get created before methods are 
compiled, etc - but I don't think it covers this case. Another 
question: is it important that #noteCompilationOf:meta: be operational 
while VMMaker is being loaded, or only afterwards?

Depending on the answer to that, we may be able to find a workaround, 
but this sort of meta/reflective programming can be difficult for a 
declarative system like Monticello to deal with. Perhaps we just need 
to address compilation hooks specifically.

Colin