Using Monticello and SqueakSource and distributing packages
cputney at wiresong.ca
Tue Feb 17 21:22:23 UTC 2004
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.
More information about the Squeak-dev