[Vm-dev] New Spur trunk image available

Eliot Miranda eliot.miranda at gmail.com
Fri Oct 17 06:51:20 UTC 2014

Hi All,

    finally the Spur Squeak trunk image is updateable.  The image in
http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/ was created
today and thanks to Bert Freudenberg's latest Monticello work can be
updated independently of the non-Spur trunk.  Spur VMs are available in
http://www.mirandabanda.org/files/Cog/VM/VM.r3105/ (and later as they
appear).  Without wanting to appear too overconfident the Spur system looks
to be ready for use apart from image segments (which I hope to have working
some time next month).  I'm really interested in having this stress tested
by as many people as possible.  Spur really does offer a significant
performance and functionality improvement over the current system, but it
needs testing to ensure its reliability.

Esteban Lorenzano is hard at work on the Pharo bootstrap for Spur so I hope
Pharo 4 Spur will be available soon.

As far as trunk goes, using Spur alongside non-Spur trunk is going to be
difficult to manage for the near future.  Right now, Spur modifies the
Collections, Compiler, Kernel and System packages, and this is done by
auto-editing the non-Spur versions of those packages, something I do
periodically as new versions arrive.  I also auto-edit trunk configurations
(the part of the image update scheme that ensures packages are loaded in
the right order when there are dependencies between packages) from non-Spur
"update" to Spur "update.spur" forms.  This at east means that Spur can
keep up with trunk.  But it does /not/ provide a way of committing
to Collections.spur, Compiler.spur, Kernel.spur or System.spur without
getting out of sync with non-Spur trunk.  Note that apart from these
packages, one /can/ safely commit any other package from a Spur image to

Right now the plan is to release both V3 (the pre-Spur format) and Spur
versions of Squeak 4.6 (I hope it'll be called Squeak 5.0).  This isn't my
preference.  I'd like to see just Spur released, once reliability is
verified.  But I understand the safety and backward-compatibility concerns
(Spur won't be able to load V3 image segments, and vice verse).  The issue
is of course that we have this tricky package situation to manage where, to
keep the two systems in sync, modifications to Collections, Compiler,
Kernel and System need to be committed from V3 and auto-edited to Spur. I
think that's too clumsy to be practicable.  Perhaps allowing the two
systems to fork and doing a manual merge will be acceptable, but it'll be
work to keep them in sync.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141016/cd420f08/attachment.htm

More information about the Vm-dev mailing list