AW: [squeak-dev] [ANN] The Squeak 5.1 Release Plan

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

AW: [squeak-dev] [ANN] The Squeak 5.1 Release Plan

Herbert König
Really exciting news! 

Herbert


-------- Ursprüngliche Nachricht --------
Von: "marcel.taeumel"
Datum:13.07.2016 10:29 (GMT+01:00)
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.



Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

Chris Muller-3
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...

On Wed, Jul 13, 2016 at 4:17 AM, Herbert König <[hidden email]> wrote:

> Really exciting news!
>
> Herbert
>
>
> -------- Ursprüngliche Nachricht --------
> Von: "marcel.taeumel"
> Datum:13.07.2016 10:29 (GMT+01:00)
> An: [hidden email]
> 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.
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

marcel.taeumel
Chris Muller-3 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...

On Wed, Jul 13, 2016 at 4:17 AM, Herbert König <[hidden email]> wrote:
> Really exciting news!
>
> Herbert
>
>
> -------- Ursprüngliche Nachricht --------
> Von: "marcel.taeumel"
> Datum:13.07.2016 10:29 (GMT+01:00)
> An: [hidden email]
> 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.
>
>
>
>
Hi Chris,

yes, there were several loose ideas about 64-bit and version numbering. I'd say that if we manage to have 64-bit support for all platforms, we can release 64-bit image versions on a regular basis and then raise the version to 6.0. Right now, I consider 64-bit support as kind of experimental. Especially since we cannot just convert back to 32-bit and debug if something goes seriously wrong. There are still several strange things going on with rectangles and points becoming arbitrary fractions. Or something like that. :-)

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

David T. Lewis
On Thu, Jul 14, 2016 at 04:05:35AM -0700, marcel.taeumel wrote:

> Chris Muller-3 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...
> >
> > On Wed, Jul 13, 2016 at 4:17 AM, Herbert K??nig &lt;
>
> > herbertkoenig@
>
> > &gt; wrote:
> >> Really exciting news!
> >>
> >> Herbert
> >>
> >>
> >> -------- Urspr??ngliche Nachricht --------
> >> Von: "marcel.taeumel"
> >> Datum:13.07.2016 10:29 (GMT+01:00)
> >> An:
>
> > squeak-dev@.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.
> >>
> >>
> >>
> >>
>
> Hi Chris,
>
> yes, there were several loose ideas about 64-bit and version numbering. I'd
> say that if we manage to have 64-bit support for all platforms, we can
> release 64-bit image versions on a regular basis and then raise the version
> to 6.0. Right now, I consider 64-bit support as kind of experimental.
> Especially since we cannot just convert back to 32-bit and debug if
> something goes seriously wrong. There are still several strange things going
> on with rectangles and points becoming arbitrary fractions. Or something
> like that. :-)
>

I think that is a very good way to look at it. We want to get the 64-bit
image into wider use. As long as we make the limitations clear it should
be no problem.

Dave

 

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

Eliot Miranda-2
In reply to this post by Chris Muller-3
Hi Chris,


> On Jul 13, 2016, at 9:40 AM, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:
>> Really exciting news!
>>
>> Herbert
>>
>>
>> -------- Ursprüngliche Nachricht --------
>> Von: "marcel.taeumel"
>> Datum:13.07.2016 10:29 (GMT+01:00)
>> An: [hidden email]
>> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

Chris Muller-4
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 <[hidden email]> wrote:

> Hi Chris,
>
>
>> On Jul 13, 2016, at 9:40 AM, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:
>>> Really exciting news!
>>>
>>> Herbert
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: "marcel.taeumel"
>>> Datum:13.07.2016 10:29 (GMT+01:00)
>>> An: [hidden email]
>>> 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.
>>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

David T. Lewis
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 <[hidden email]> wrote:
> > Hi Chris,
> >
> >
> >> On Jul 13, 2016, at 9:40 AM, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:
> >>> Really exciting news!
> >>>
> >>> Herbert
> >>>
> >>>
> >>> -------- Urspr??ngliche Nachricht --------
> >>> Von: "marcel.taeumel"
> >>> Datum:13.07.2016 10:29 (GMT+01:00)
> >>> An: [hidden email]
> >>> 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.
> >>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

Chris Muller-3
On Fri, Jul 15, 2016 at 2:44 PM, David T. Lewis <[hidden email]> wrote:
> I don't see any problem with making a 64-bit image available along with
> the 5.1 release.

Nor do I, but...

> 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 :-)

... we talked about in our meeting that we were gonna have two
separate downloads, one for 32-bit, one for 64-bit.  If so, what will
be the basis for somone to be able discern which one they need to
download?

I assume you want to call them "5.1/32" and "5.1/64" because you want
to support 32-bit for years to come, and so the "5.1" names the image
contents, while the "32" or "64" names the word size.

That buys me a lot more time to upgrade Magma to work on 64-bit, and
makes sense if we really are going to support 32-bit for years to
come, but as the RPi 3 is 64-bit, it seems like new installations with
new versions of Squeak are most likely going to go 64-bit.  I could be
wrong.

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

marcel.taeumel
In reply to this post by David T. Lewis
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 <[hidden email]> wrote:
> > Hi Chris,
> >
> >
> >> On Jul 13, 2016, at 9:40 AM, Chris Muller <[hidden email]> 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 <[hidden email]> wrote:
> >>> Really exciting news!
> >>>
> >>> Herbert
> >>>
> >>>
> >>> -------- Urspr??ngliche Nachricht --------
> >>> Von: "marcel.taeumel"
> >>> Datum:13.07.2016 10:29 (GMT+01:00)
> >>> An: [hidden email]
> >>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

John Pfersich-2
In reply to this post by Chris Muller-3
The Pi is 64 bit, but the OS, at least Raspian, is 32 bit, and they don't seem to be in a rush to take it to 64 bits.

Sent from my iPad

> On Jul 16, 2016, at 10:14, Chris Muller <[hidden email]> wrote:
>
>> On Fri, Jul 15, 2016 at 2:44 PM, David T. Lewis <[hidden email]> wrote:
>> I don't see any problem with making a 64-bit image available along with
>> the 5.1 release.
>
> Nor do I, but...
>
>> 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 :-)
>
> ... we talked about in our meeting that we were gonna have two
> separate downloads, one for 32-bit, one for 64-bit.  If so, what will
> be the basis for somone to be able discern which one they need to
> download?
>
> I assume you want to call them "5.1/32" and "5.1/64" because you want
> to support 32-bit for years to come, and so the "5.1" names the image
> contents, while the "32" or "64" names the word size.
>
> That buys me a lot more time to upgrade Magma to work on 64-bit, and
> makes sense if we really are going to support 32-bit for years to
> come, but as the RPi 3 is 64-bit, it seems like new installations with
> new versions of Squeak are most likely going to go 64-bit.  I could be
> wrong.
>

Reply | Threaded
Open this post in threaded view
|

Re: [ANN] The Squeak 5.1 Release Plan

timrowledge

> On 16-07-2016, at 8:18 PM, John Pfersich <[hidden email]> wrote:
>
> The Pi is 64 bit, but the OS, at least Raspian, is 32 bit, and they don't seem to be in a rush to take it to 64 bits.

As you say, no rush. It’ll happen eventually.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: XM: Exclusive Maybe