<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Thanks eliot I'm really eager to try and use Spur on Pharo. This
opens so much for the future.<br>
<br>
<div class="moz-cite-prefix">On 17/10/14 08:51, Eliot Miranda wrote:<br>
</div>
<blockquote
cite="mid:CAC20JE2Yk4JvuySkMRq_7WPUfy+6bot=FsrLZA_M0CmgC443eg@mail.gmail.com"
type="cite">
<pre wrap=""> </pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<div dir="ltr">Hi All,
<div><br>
</div>
<div> finally the Spur Squeak trunk image is updateable. The
image in <a moz-do-not-send="true"
href="http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/">http://www.mirandabanda.org/files/Cog/SpurImages/2014-10-16/</a>
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 <a moz-do-not-send="true"
href="http://www.mirandabanda.org/files/Cog/VM/VM.r3105/">http://www.mirandabanda.org/files/Cog/VM/VM.r3105/</a>
(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.</div>
<div><br>
</div>
<div>Esteban Lorenzano is hard at work on the Pharo bootstrap
for Spur so I hope Pharo 4 Spur will be available soon.</div>
<div><br>
</div>
<div>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 trunk.</div>
<div><br>
</div>
<div>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.</div>
<div>-- <br>
best,
<div>Eliot</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>