[squeak-dev] A new Squeak release

Eliot Miranda eliot.miranda at gmail.com
Thu Mar 1 17:57:52 UTC 2018


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/20180301/a20f97d4/attachment.html>


More information about the Squeak-dev mailing list