On Fri, Mar 02, 2018 at 12:13:01PM +0000, Fabio Niephaus wrote:
> 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!

Don't apologize, your messages and requests to test candidate OpenSmalltalk
release candidates have been clear.

> 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.
>

Yes this makes sense, and there is no reason that release checkpoints for
the VMs should be directly tied to the release schedules for Squeak, Pharo,
or Cuis or other images. And yes, having periodic checkpoints for the VM
is a good thing. Your efforts here are appreciated.
 
> 
> >
> > 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).
> 

+1000

Dave


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

>