On Wed, Aug 12, 2015 at 11:11 AM, Levente Uzonyi <leves@elte.hu> wrote:
Hi Dave,

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.

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.

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.


On Mon, 10 Aug 2015, David T. Lewis wrote:

On Thu, Aug 06, 2015 at 09:47:46AM -0500, Chris Muller wrote:
We currently have the trunk update stream, which is governed by update maps
called 'update' in the source.squeak.org/trunk repository. This update
stream is applicable to Squeak images up to the initial release of the
Squeak 4.6 image. These are images in the non-Spur image formats (6504
or 6505 for 32-bit images, and 68002 for a 64-bit image).

The .spur branch has already been collapsed onto trunk.  There is no
way to advance a non-spur image except through commits to the release
repositories (e.g., 'squea46').

During the development period leading up to Squeak 5.0, which uses the
new Spur image (format number 6521 for the 32-bit Spur image), the
update stream has been governed by update maps called 'update.spur' in

For Squeak 5.0, the update stream will continue to be governed by update
maps called 'update' in the source.squeak.org/trunk repository. Users of
Squeak 5.0 will see a normal trunk update stream from that point forward,
and will now be using the Spur image format.


For Squeak 4.6, the update stream will continue to be called 'update',
but will now be in the source.squeak.org/squeak46 repository. These update
maps are not yet in the squeak46 repository,

I just made the first one in 'squeak46'.

but will be added as required.
The Squeak 4.6 release image points to this update stream. An effort will
be made to keep the squeak46 update stream in sync with trunk through the
next Squeak release cycle.

Oh really, who is going to do that?

I fully understand that nothing gets done unless someone actually puts
in the effort to do it. Within reasonable limits, this is something that
I am willing to work on through the course of the next release cycle. I
am expecting that this means 6 to 12 months, depending on how long it takes
to go through another release cycle.

My assumptions were, and still are, as follows:

1) We are moving the main trunk development to the new Spur image format
for Squeak 5.0.  This is not a reversible change. Some things may break,
but we are going to make it work and we are going to make it successful.

2) We will attempt to do this during a transition period of one release
cycle (whatever that might turn out to be). This allows us to learn
during the transition period, and to work out any unanticipated problems.
During that time period, we will make an effort to keep the classic image
format (Squeak 4.6) healthy. My own assumption is that this should include
a working update stream.

3) We will not rely on Eliot to do all the work. Once we get to Squeak
5.0 with Spur, other people (such as me) need to step forward if any
backward compatibility with non-Spur images is going to be maintained.
If nobody does it, then it will not get done.

Hopefully these are reasonable objectives, and from my point of view
I will be happy to put some time and effort into objective #3 in the
coming months.

Having said that, I do not actually know *how* to maintain an update
stream for 4.6 to track the main trunk 5.0 stream.


For an existing trunk image, such as a Squeak 4.5 image that has been kept
up to date with the trunk, it will be necessary to switch from
source.squeak.org/trunk with update map name 'update', to a new setting
of source.squeak.org/squeak46 with update map name 'update', This change
must be made more or less concurrently with the Squeak 5.0 release.


1) Is the above summary correct?

2) Is it possible for the trunk update stream to force an existing trunk
image (originating from Squeak 4.5 or earlier) to switch over to the squeak46
repository automatically, such that updates can proceed without loading
Spur-specific changes into a non-Spur trunk image?

You would need to make sure not to update past update-topa.322.mcm.
Probably the code is not set up to do a limited updated.

No, you have to update the updateURL in Preferences.

3) Previously, the release-specific repository (e.g. source.squeak.org/squeak45
for Squeak 4.5) was used for applying a few important fixes to a stable
release. Assuming that this is also the intent for Squeak 4.6, and that we
also want to make an effort to permit non-Spur images to stay in sync with
trunk for some period of time (nominally one release cycle), then would it
be helpful to consider providing a trunk-compatible update stream for non-Spur
images during the transition period? I am not sure how that should work
(possibly something involving an 'update.classic' update map), but I would
like to know if conceptually it is something we should be trying to do.

Basically you are talking about a fork of Squeak.  Unless someone has
some kind of compatibility issue with their application, I don't know
why anyone would want to expend resources maintaining an old fork..

best, Eliot