Hi all,

On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <kksubbu.ml at gmail.com> wrote:

> Is there a plan to spin out Squeak (the ST VM) from Squeak (the image)
> in this (or subsequent) release cycle? or will the two releases go
> hand-in-hand forever?
>

I always thought it was clear that with OpenSmalltalk release, I meant the
VMs and not a new Squeak release. But it looks like people thought I was
talking about a new Squeak release, thus Eliot's email I guess. Sorry for
the confusion, my bad!
I do agree that there should be a new Squeak release rather sooner than
later, but I am still interested in having a new checkpoint for the VMs
soon. This helps us to find out how stable current Squeak VMs are and it's
also useful for things like CI.


>
> Now that the same VM is used by multiple (image) projects like Scratch,
> Etoys, Pharo, Cuis and with binary variants like 32bit/64bit, cog/spur
> etc. putting the VM on a separate cycle may be easier than linking it
> with Squeak project releases. The VM may continue ship with a built-in
> image for bootstrapping other images or for VMMaker but that need not be
> linked with the latest Squeak release.
>

Those are some reasons why I think it would make sense to decouple the
release processes for both the vm and the image. Why couple a new vm
release to a Squeak or Pharo release if we could independently make new vm
releases and then dialects can use the version they want or need. Maybe,
this way we can fix VMs bugs without having to prepare a new image release:
treat image and vm versions independently and only say "Squeak-5.x" needs
"OpenSmalltalkVM Y or later" (assuming Squeak releases happen before
breaking vm changes, such as Spur support).

Best,
Fabio


>
> Regards .. Subbu
>
> On Thursday 01 March 2018 11:27 PM, Eliot Miranda wrote:
> > Hi All,
> >
> >      we're moving close to a new Squeak release.  There are some issues
> > to discuss before we decide  exactly what and when to release.  I have
> > two issues that I would like people's opinions on.
> >
> > 1. the VM can be compiled with support for read-only objects, and indeed
> > Pharo is already doing this.  Were we to enable read-only object support
> > we could introduce read-only bindings.  I have this code ready to go,
> > but the current Squeak VM does not include read-only object support.  We
> > could go ahead and release without read-only object support or enable
> > read-only object support in the VM, push the new VMs out and enable
> > read-only literals.  It would then take a few days for everyone to test
> > their code and fix issues with read-only literals.  For example, code
> > such as
> >
> > a := { 'one ' . 'two ' . 'three ' }.
> > a do: [:e | e at: e size put: (Character value: 0)].
> >
> > must be rewritten, e.g. as
> >
> > a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll:
> > Character space asString with: Character null asString].
> >
> > and the classic
> >
> > '' writeStream
> >
> > as
> >
> > '' copy writeStream
> >
> > i.e. literals are read-only but copies of literals are not.
> >
> > 2. the current VM, Monticello and the ClassBuilder has full support for
> > ephemerons, which provide instance based finalization. For example, if a
> > file that is the key of some ephemeron in a registration dictionary,
> > then, with a suitable finalization process, the VM will arrange that the
> > ephemeron gets sent finalize when the file is only referenced from
> > ephemeris, and then the ephemeron can finalize the file itself, flushing
> > any buffered characters and closing the file's descriptor. What we have
> > now is a copy of the file in a weak registry, which means we finalize
> > the copy not the actual file. This limits our ability to write clean
> > file implementations. The same applies to several other uses of weak
> > registries. Again Pharo is using the facility (and hence we can use
> > their finalization process and some of their code).
> >
> > So the question is should we hold up the release for these features or
> > should we go ahead and somehow arrange that we do address these (and
> > other?) issues promptly in a subsequent release?
> >
> > Let me make a proposal. We go ahead and make a release with what we
> > have, calling it Squeak 5.5, and then follow a plan to provide read-only
> > object support, read-only literals, and as mush of the
> > finalizationsystem rewritten to use ephemeron (where appropriate) as we
> > can manage by, say, September 1. This will be Squeak 6. And the trunk
> > process would update to requiring a rad-only-object enabled VM
> > immediately after the 5.5 release.
> >
> > _,,,^..^,,,_
> > best, Eliot
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180302/8df564e3/attachment.html>