On Wed, Aug 12, 2015 at 11:11 AM, Levente Uzonyi <leves at 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.


>
> Levente
>
>
> 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
>>>> source.squeak.org/trunk.
>>>>
>>>> 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.
>>>>
>>>
>>> Yes.
>>>
>>> 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.
>>
>> Dave
>>
>>
>>
>> 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.
>>>>
>>>> Questions:
>>>>
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150812/d5dfd81c/attachment.htm