David T. Lewis wrote
> I don't see any problem with making a 64-bit image available along with
> the 5.1 release. After all, we went for many years supporting both 6504
> and 6505 image format through several releases. The 32-bit and 64-bit
> Spur images will be essentially the same image, just saved in a different
> object format.
> 
> We do need to make sure that if someone chooses to load the 64-bit
> version, that they are aware of the compatibility restrictions. But
> that's nothing that we cannot handle with a good download page on
> the web site, and I'm sure we can do that :-)
> 
> Dave
> 
> 
> On Fri, Jul 15, 2016 at 12:34:04PM -0500, Chris Muller wrote:
>> I'm talking about version numbers, not features.  In the past,
>> whenever we broke backward compatibility, we incremented the major
>> version number.  This is what we did with the 4.6 / 5.0 release.
>> 
>> Image conversion utilities notwithstanding, 64-bit essentially breaks
>> backward compatibility, so "5.1" seems inappropriate for the new
>> 64-bit release.  Do you object to your 6.0 features list being part of
>> a "7.0" (or a 6.1, if we're not breaking backward compatibility with
>> 64-bit 6.0)?
>> 
>> Also, it wasn't clear to me what you wanted to call the 32-bit version
>> of "5.1".  Did you want to have have a 5.1-64 and a 5.1-32?
>> 
>> 
>> On Fri, Jul 15, 2016 at 11:33 AM, Eliot Miranda <

> eliot.miranda@

> > wrote:
>> > Hi Chris,
>> >
>> >
>> >> On Jul 13, 2016, at 9:40 AM, Chris Muller <

> asqueaker@

> > wrote:
>> >>
>> >> I thought "6.0" was planned to be the 64-bit version of "5.1", and 5.1
>> >> the 32-bit version of the same image contents...
>> >
>> > That's not what I tried to articulate at all.  What I want for 5.1 is
>> essentially what Marcel outlines below, a cleaned up 5.0 with 64-bit
>> support.
>> >
>> > For 6.0 I'm hoping we will do
>> >
>> > - the Sista bytecode set (with backwards compatibility support for the
>> existing set).  This gives us 32k literals,
>> > - FullBlockClosure, which means I depended method objects for blocks,
>> and hence (slightly) faster block activation
>> > - read-only objects and hence read-only literals
>> >
>> > These three provide the necessary support for the image-level Scorch
>> adaptive optimiser.  This will be demonstrated at ESUG in Prague and
>> productized by next year
>> >
>> > - collapsing of ContextPart and MethodContext onto Context.  The
>> closure model does not need BlockContext so this is a nice
>> simplification, one that Pharo has already released.
>> >
>> > Revised finalization.  Spur supports ephemerons which allow pre-mortem
>> finalisation (they identify objects about to die, not the death of
>> objects) and allow cycle-free addition of dependencies (which is how they
>> identify objects about to die).  Since individual ephemerons must be
>> identified (those whose keys are about to die) there is a finalisation
>> queue into which the GC places such ephemerons. Spur also enqueues weak
>> arrays that have lost efferent on the same queue.  Hence we can
>> profitably reimplement many finalisation facilities:
>> > - the current scheme has the VM signal a semaphore in any GC cycle that
>> collects one or more referents of one or more weak arrays, and weak
>> arrays are held in registries.  hence to finalise a single weak array
>> requires finalising any and all weak arrays in the registries.  Instead,
>> weak arrays can hold onto a manager directly through an inst var and have
>> this object do the work, now meaning that only those weak arrays that
>> lose references do work in each GC cycle.
>> > - DependentsFields can be reimplemented to use a non-finalising
>> ephemeron to attach dependents to objects without preventing their GC
>> (unlike the current weak array approach)
>> > - pre-mortem finalisation allows files to auto-finalise, hence flushing
>> their contents before closing instead of finalising a copy which merely
>> closes the file descriptor
>> > - exiting the image should be arguably be done only after running a
>> full GC and then draining the finalisation queue, and hence arguably
>> there may need to be an emergency exit
>> >
>> > All of these together will impact code, breaking some old code, but
>> always in simply fixable ways, and provide new facilities and pave the
>> way to a substantial performance increase with Sista.  Hence these
>> changes need IMO to be a full release, not a point release.
>> >
>> >>> On Wed, Jul 13, 2016 at 4:17 AM, Herbert K??nig <

> herbertkoenig@

> > wrote:
>> >>> Really exciting news!
>> >>>
>> >>> Herbert
>> >>>
>> >>>
>> >>> -------- Urspr??ngliche Nachricht --------
>> >>> Von: "marcel.taeumel"
>> >>> Datum:13.07.2016 10:29 (GMT+01:00)
>> >>> An: 

> squeak-dev at .squeakfoundation

>> >>> Betreff: [squeak-dev] [ANN] The Squeak 5.1 Release Plan
>> >>>
>> >>> Hey, there.
>> >>>
>> >>> I just want to inform all of you that we are in the middle of
>> preparing the
>> >>> next Squeak 5.1 release. We are working on automation for
>> >>> generating/updating all release artifacts so that we are eventually
>> able to
>> >>> shorten our release cycle in the future. For this, we are using
>> smalltalkCI
>> >>> (thanks Fabio!), TravisCI, and AppVeyor.
>> >>>
>> >>> Here are the important dates:
>> >>> * Feature Freeze on July 31, 23:59 AOE
>> >>> * Code Freeze on August 14, 23:59 AOE
>> >>> * Release between August 15 and 19
>> >>>
>> >>> As these dates suggest, our goal is to have the release before this
>> year's
>> >>> ESUG. However, there is another important Smalltalk-related event
>> this year:
>> >>> 20 years of Squeak. :-) Yeah! It was around October 1996, when the
>> first
>> >>> Squeak came into the world. ...having its own worlds. :D So, it would
>> only
>> >>> make sense to also have a special release for this birthday. For
>> this, we
>> >>> revived all of the cool multimedia content, known from Squeak 1
>> through
>> >>> Squeak 3, and made it fit for the current Squeak code base. Oh, this
>> is so
>> >>> exciting. :-)
>> >>>
>> >>> Anyway, what's with Squeak 5.1 and 64-bit? Since the release of
>> Squeak 5.0,
>> >>> we've been working hard and made a lot of bug fixes and added some
>> features
>> >>> to improve the overall usability and robustness of the Squeak live
>> >>> programming system. Meanwhile, the VMs improved as well. Cog's object
>> format
>> >>> "Spur" got more robust, the JIT improved, and the whole code base
>> moved from
>> >>> SVN to Git: https://github.com/OpenSmalltalk/opensmalltalk-vm.
>> >>>
>> >>> Still, what's up with 64-bit? We have working 64-bit VMs for Mac OS X
>> and
>> >>> Linux. Hence, we will take the chance and also release 64-bit bundles
>> for
>> >>> Squeak 5.1. Be informed that this means a new .image file. You cannot
>> open a
>> >>> 64-bit .image with a 32-bit VM and vice versa. This, however, is
>> nothing
>> >>> serious because we are working on an updated version of our
>> SystemTracer to
>> >>> convert back and forth. With limitations, of course. ;-) You cannot
>> fill a
>> >>> bottle of beer into a shot glass.
>> >>>
>> >>> What's up with the All-in-one? There will be the usual 32-bit
>> all-in-one
>> >>> package, which combines VMs for Linux, Mac OS X, and Windows. Since
>> there
>> >>> will be no 64-bit Windows VM within the next two months, we refrain
>> from
>> >>> creating an almost-all-in-one-32/64 package. This would only confuse
>> the
>> >>> users. In the future, we can arguably expand the concept of the
>> All-in-one
>> >>> to also contain 32-bit and 64-bit VMs and images.
>> >>>
>> >>> So, what are the prospective release artifacts for Squeak 5.1?
>> >>> * All-in-one (Linux/Mac/Win) 32-bit
>> >>> * Mac OS X App 32-bit, signed
>> >>> * Mac OS X App 64-bit, signed
>> >>> * Linux Bundle 32-bit
>> >>> * Linux Bundle 64-bit
>> >>> * Windows App (maybe with MSI Installer) 32-bit, maybe signed
>> >>> * ZIP archive containing .image and .changes, no VM, no .sources
>> >>>
>> >>> We plan to also use the new release automation process for Squeak 5.0
>> and
>> >>> update those release artifacts as well. We will update our squeak.org
>> >>> Website but you will always find the artifacts on
>> >>> http://files.squeak.org/5.0 and http://files.squeak.org/5.1 .
>> >>>
>> >>> :-)
>> >>>
>> >>> Best,
>> >>> Marcel
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>> http://forum.world.st/ANN-The-Squeak-5-1-Release-Plan-tp4906439.html
>> >>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>> >>

+1

I am not a fan of coupling VM-features to the Squeak version number. We
should avoid breaking compatibility again, if possible. At best, Squeak 6.0
will include the SystemTracer and support converting back-and-forth between
32-bit, 64-bit, Spur, Non-Spur, V3, Cog. This would justify an increment of
Squeak's main version number -- at least in terms of compatibility. :-)

Best,
Marcel



--
View this message in context: http://forum.world.st/AW-squeak-dev-ANN-The-Squeak-5-1-Release-Plan-tp4906443p4906777.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.