<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 11:11 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dave,<br>
<br>
I'm afraid it would be rather difficult to backport all changes to 4.6. The changes made by the Spur bootstrap would have to be reverted (Compiler, Collections, Kernel, System packages) along with all Spur-specific optimizations (e.g. #become:, immediate characters, etc) in future changes.</blockquote><div><br></div><div>Right. Some of this can be automated as long as the differences between the two systems are trivial. But soon enough the gulf will be too far because the differences will be in larger semantic units (for example a rewriting of finalization support to use Ephemerons could cause significant changes to the way file streams are finalized) and at that point automatic back-port will be impossible.</div><div><br></div><div>I think a much more fruitful direction is to work on developing an up-to-date Interpreter in VMMaker.oscog that can hence be mated to both the V3 memory manager and the Spur one.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Levente</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, 10 Aug 2015, David T. Lewis wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Thu, Aug 06, 2015 at 09:47:46AM -0500, Chris Muller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We currently have the trunk update stream, which is governed by update maps<br>
called 'update' in the <a href="http://source.squeak.org/trunk" rel="noreferrer" target="_blank">source.squeak.org/trunk</a> repository. This update<br>
stream is applicable to Squeak images up to the initial release of the<br>
Squeak 4.6 image. These are images in the non-Spur image formats (6504<br>
or 6505 for 32-bit images, and 68002 for a 64-bit image).<br>
</blockquote>
<br>
The .spur branch has already been collapsed onto trunk. There is no<br>
way to advance a non-spur image except through commits to the release<br>
repositories (e.g., 'squea46').<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
During the development period leading up to Squeak 5.0, which uses the<br>
new Spur image (format number 6521 for the 32-bit Spur image), the<br>
update stream has been governed by update maps called 'update.spur' in<br>
<a href="http://source.squeak.org/trunk" rel="noreferrer" target="_blank">source.squeak.org/trunk</a>.<br>
<br>
For Squeak 5.0, the update stream will continue to be governed by update<br>
maps called 'update' in the <a href="http://source.squeak.org/trunk" rel="noreferrer" target="_blank">source.squeak.org/trunk</a> repository. Users of<br>
Squeak 5.0 will see a normal trunk update stream from that point forward,<br>
and will now be using the Spur image format.<br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For Squeak 4.6, the update stream will continue to be called 'update',<br>
but will now be in the <a href="http://source.squeak.org/squeak46" rel="noreferrer" target="_blank">source.squeak.org/squeak46</a> repository. These update<br>
maps are not yet in the squeak46 repository,<br>
</blockquote>
<br>
I just made the first one in 'squeak46'.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but will be added as required.<br>
The Squeak 4.6 release image points to this update stream. An effort will<br>
be made to keep the squeak46 update stream in sync with trunk through the<br>
next Squeak release cycle.<br>
</blockquote>
<br>
Oh really, who is going to do that?<br>
<br>
</blockquote>
<br>
I fully understand that nothing gets done unless someone actually puts<br>
in the effort to do it. Within reasonable limits, this is something that<br>
I am willing to work on through the course of the next release cycle. I<br>
am expecting that this means 6 to 12 months, depending on how long it takes<br>
to go through another release cycle.<br>
<br>
My assumptions were, and still are, as follows:<br>
<br>
1) We are moving the main trunk development to the new Spur image format<br>
for Squeak 5.0. This is not a reversible change. Some things may break,<br>
but we are going to make it work and we are going to make it successful.<br>
<br>
2) We will attempt to do this during a transition period of one release<br>
cycle (whatever that might turn out to be). This allows us to learn<br>
during the transition period, and to work out any unanticipated problems.<br>
During that time period, we will make an effort to keep the classic image<br>
format (Squeak 4.6) healthy. My own assumption is that this should include<br>
a working update stream.<br>
<br>
3) We will not rely on Eliot to do all the work. Once we get to Squeak<br>
5.0 with Spur, other people (such as me) need to step forward if any<br>
backward compatibility with non-Spur images is going to be maintained.<br>
If nobody does it, then it will not get done.<br>
<br>
Hopefully these are reasonable objectives, and from my point of view<br>
I will be happy to put some time and effort into objective #3 in the<br>
coming months.<br>
<br>
Having said that, I do not actually know *how* to maintain an update<br>
stream for 4.6 to track the main trunk 5.0 stream.<br>
<br>
Dave<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For an existing trunk image, such as a Squeak 4.5 image that has been kept<br>
up to date with the trunk, it will be necessary to switch from<br>
<a href="http://source.squeak.org/trunk" rel="noreferrer" target="_blank">source.squeak.org/trunk</a> with update map name 'update', to a new setting<br>
of <a href="http://source.squeak.org/squeak46" rel="noreferrer" target="_blank">source.squeak.org/squeak46</a> with update map name 'update', This change<br>
must be made more or less concurrently with the Squeak 5.0 release.<br>
<br>
Questions:<br>
<br>
1) Is the above summary correct?<br>
<br>
2) Is it possible for the trunk update stream to force an existing trunk<br>
image (originating from Squeak 4.5 or earlier) to switch over to the squeak46<br>
repository automatically, such that updates can proceed without loading<br>
Spur-specific changes into a non-Spur trunk image?<br>
</blockquote>
<br>
You would need to make sure not to update past update-topa.322.mcm.<br>
Probably the code is not set up to do a limited updated.<br>
<br>
No, you have to update the updateURL in Preferences.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) Previously, the release-specific repository (e.g. <a href="http://source.squeak.org/squeak45" rel="noreferrer" target="_blank">source.squeak.org/squeak45</a><br>
for Squeak 4.5) was used for applying a few important fixes to a stable<br>
release. Assuming that this is also the intent for Squeak 4.6, and that we<br>
also want to make an effort to permit non-Spur images to stay in sync with<br>
trunk for some period of time (nominally one release cycle), then would it<br>
be helpful to consider providing a trunk-compatible update stream for non-Spur<br>
images during the transition period? I am not sure how that should work<br>
(possibly something involving an 'update.classic' update map), but I would<br>
like to know if conceptually it is something we should be trying to do.<br>
</blockquote>
<br>
Basically you are talking about a fork of Squeak. Unless someone has<br>
some kind of compatibility issue with their application, I don't know<br>
why anyone would want to expend resources maintaining an old fork..<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>