[Vm-dev] VM packaging for Cog transition

David T. Lewis lewis at mail.msen.com
Sun Nov 7 20:27:22 UTC 2010

Bert and others have raised the question of how best to package the
Cog VM and traditional interpreter VM for the next round of VM releases
in December. Cog is a significant advance, and the Squeak board would
like this to be fully supported for the Squeak 4.2 release; clearly it
is a priority for Pharo as well. Meanwhile we have a responsibility for
Etoys, Scratch, OLPC etc to provide VMs that do not break those systems.

So - how best to do this?

For unix VMs, Bert has suggested this:

> Maybe we need a "squeak-interp" and "squeak-cog" binary, with "squeak"
> symlinking to either one (using the alternatives system) or "squeak"
> being a script choosing the right VM based on the image version. But
> we should present a coherent story to the packagers. As well as to
> Squeak users.

Personally I am inclined to think it would be best for this next release
not to automate the selection of VM, but instead have users make an
explicit selection. I say this for two reasons:

1) From a marketing point of view, it is good if users can directly experience
the improvement from Cog. So the message might be to first run in the standard
way (squeak-interp) to get a very cool system that is quite fast, then activate
turbo mode (squeak-cog) to get a system that is very noticeably 3X faster.

2) From a technical and support point of view, there may be various cases
where it will be necessary to say "sorry, you will need to run squeak-interp
if you want to do that." When that happens, it would be best if we do not need
to explain e.g. how to edit a shell script to force it to run squeak-interp.

The above is just my $.02 to get the discussion started. What do others think?


More information about the Vm-dev mailing list