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
According to our web site, the current release is Squeak 5.1, and trunk is Squeak 6.0alpha.
I think it has been about a year since the last official release, and a lot of great stuff has gone into trunk during that time. So it would be good to put out an official release some time soon. For that we should identify a person to serve as release manager to make it happen. I expect we will discuss this in our board meeting next week, but input (and volunteers or nominations) from anyone in the community would certainly be welcome.
If we do something in the near term, then it would make sense to me if it was called Squeak 5.2. And if that happens, it would be good to incorporate full support for ephemerons and read only objects into whatever release comes next after that.
In the mean time, my view would be that any changes for support of read only objects and ephemerons should be introduced as soon as possible regardless of the release schedule, just as long as this can be done without requiring incompatible VM changes. I'm not quite clear on whether that is the case here. But basically what I am trying to say is let's move this forward as quickly as possible. If it is a change that would cause pain for general users of Squeak, then hold off until after then next release, and let's make sure that next release happens soon.
So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's find a release manager and make it happen.
And just so we do not forget - The last release was still focused on 32 bit images. The 64 bit system is not longer experimental, so we need to publicize this better in our next release and document the limitations so that users are aware that they will not be able run their 64 bit image on a 32 bit platform.
Dave
On Thu, Mar 01, 2018 at 09:57:52AM -0800, Eliot Miranda wrote:
Hi All,
we're moving close to a new Squeak release. There are some issues todiscuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on.
- 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.
- 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
On 01/03/2018, 23:17, "David T. Lewis" lewis@mail.msen.com wrote:
For that we should
identify a person to serve as release manager to make it
happen. I expect
we will discuss this in our board meeting next week, but
input (and volunteers
or nominations) from anyone in the community would
certainly be welcome
I'm could be that person.
Edgar @morplenauta
On Fri, Mar 02, 2018 at 05:39:32AM -0300, Edgar J. De Cleene wrote:
On 01/03/2018, 23:17, "David T. Lewis" lewis@mail.msen.com wrote:
For that we should
identify a person to serve as release manager to make it
happen. I expect
we will discuss this in our board meeting next week, but
input (and volunteers
or nominations) from anyone in the community would
certainly be welcome
I'm could be that person.
Edgar @morplenauta
Cool! Thanks Edgar :-)
To be honest the board has not paid enough attention to planning an upcoming release, so I think it's going to be on the top of our agenda this week.
Thanks a lot for volunteering, I have always admired the work that you do with FunSqueak.
Dave
On Fri, Mar 2, 2018 at 4:57 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Mar 02, 2018 at 05:39:32AM -0300, Edgar J. De Cleene wrote:
On 01/03/2018, 23:17, "David T. Lewis" lewis@mail.msen.com wrote:
For that we should
identify a person to serve as release manager to make it
happen. I expect
we will discuss this in our board meeting next week, but
input (and volunteers
or nominations) from anyone in the community would
certainly be welcome
I'm could be that person.
Edgar @morplenauta
Cool! Thanks Edgar :-)
To be honest the board has not paid enough attention to planning an upcoming release, so I think it's going to be on the top of our agenda this week.
Thanks a lot for volunteering, I have always admired the work that you do with FunSqueak.
Hear Hear! Definitely. -cbc
Dave
Hi Edgar,
The Squeak oversight board has been discussing the upcoming release in our last few meetings, and we would be very happy if you would agree to be the Release Manager for the next Squeak release.
Overall we are thinking that a new Squeak 5.2 release would make sense if it can be done in the next two or three months, so this should be our target.
There are also many advances happening in the VM that may lead to a Squeak 6 release some time later, but right now we have a lot of great improvements in Squeak that deserve to be officially released soon.
Are you still interested and willing to be the release manager for Squeak 5.2?
Thanks in advance,
Dave, on behalf of the Squeak Oversight Board
On Fri, Mar 02, 2018 at 07:27:15AM -0800, Chris Cunningham wrote:
On Fri, Mar 2, 2018 at 4:57 AM, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Mar 02, 2018 at 05:39:32AM -0300, Edgar J. De Cleene wrote:
On 01/03/2018, 23:17, "David T. Lewis" lewis@mail.msen.com wrote:
For that we should
identify a person to serve as release manager to make it happen. I expect we will discuss this in our board meeting next week, but input (and volunteers or nominations) from anyone in the community would certainly be welcome
I'm could be that person.
Edgar @morplenauta
Cool! Thanks Edgar :-)
To be honest the board has not paid enough attention to planning an upcoming release, so I think it's going to be on the top of our agenda this week.
Thanks a lot for volunteering, I have always admired the work that you do with FunSqueak.
Hear Hear! Definitely. -cbc
Dave
The las FunSqueak was here http://squeakros.org/FunSqueak4.6/ScreenSnapz.jpg http://squeakros.org/FunSqueak4.6/FunSqueak4dot.6.zip
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
When/if Board says working in a release 5.2 5.5 6.0 I start to work , redoing FunSqueak4.6 And with the release .image made all test inside and think made FunSqueak X.y let's know what need polish
Week reports to here for all know what's going on And here https://discord.gg/aVeXVkC for live chat in Spanish or English
On 02/03/2018, 09:57, "David T. Lewis" lewis@mail.msen.com wrote:
Cool! Thanks Edgar :-)
To be honest the board has not paid enough attention
to planning an
upcoming release, so I think it's going to be on the top of our
agenda
this week.
Thanks a lot for volunteering, I have always admired the
work that you
do with FunSqueak.
Dave
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
Is there somewhere a cog VM for windows with 3D support?
Stef
On Mar 3, 2018, at 12:41 PM, Stéphane Rollandin lecteur@zogotounga.net wrote:
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
Is there somewhere a cog VM for windows with 3D support?
Do the current bintray VMs not work?
Stef
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
Is there somewhere a cog VM for windows with 3D support?
Do the current bintray VMs not work?
I'm a bit lost wrt the VM flavors. Which one is the current bintray?
Stef
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
If this is not helpful it needs to be updated ......
--Hannes
On 3/4/18, Stéphane Rollandin lecteur@zogotounga.net wrote:
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
Is there somewhere a cog VM for windows with 3D support?
Do the current bintray VMs not work?
I'm a bit lost wrt the VM flavors. Which one is the current bintray?
Stef
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728
I tried it and got the same error, some 3D primitives are missing (see my post in anwer to Nikolay).
Stef
I can't even get that far. How did you get from the link mentioned before to the file you think might be the correct one?
On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728
I tried it and got the same error, some 3D primitives are missing (see my post in anwer to Nikolay).
Stef
I can't even get that far. How did you get from the link mentioned before to the file you think might be the correct one?
On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728
I used the first link...
now from the second I just found squeak.cog.v3_win32x86_201803032041 which is more recent, but still with the same outcome: 3D primitives are missing.
Stef
Hi Stéphane,
On Sun, Mar 4, 2018 at 6:17 AM, Stéphane Rollandin lecteur@zogotounga.net wrote:
I can't even get that far. How did you get from the link mentioned before
to the file you think might be the correct one?
On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728
I used the first link...
now from the second I just found squeak.cog.v3_win32x86_201803032041 which is more recent, but still with the same outcome: 3D primitives are missing.>
and if you put "B3DXUsesOpenGL=0" in Squeak.ini what happens then? AFAICT all the 3D support is included in the VM as it ever was. I'm sorry, but I'm not very familiar with the 3D support on Windows. I do know that Ronie got the OpenGL example working on Mac OS in 32 and 64 bits late last year. And I think we tested all platforms and found it worked. What that implies for the B3DAcceleratorPlugin on win32 I don't know.
Stef
_,,,^..^,,,_ best, Eliot
On 4 March 2018 at 19:16, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Stéphane,
On Sun, Mar 4, 2018 at 6:17 AM, Stéphane Rollandin <lecteur@zogotounga.net
wrote:
I can't even get that far. How did you get from the link mentioned before
to the file you think might be the correct one?
On 3/4/18 6:03 AM, Stéphane Rollandin wrote:
Le 04/03/2018 à 11:44, H. Hirzel a écrit :
should lead you to the correct place.
Under the heading 'Virtual machines' there is a link
https://bintray.com/opensmalltalk/vm/cog/_latestVersion#files
Ok, then I assume the current one for a 4.6 image is cog_win32x86_squeak.cog.v3_201608171728
I used the first link...
now from the second I just found squeak.cog.v3_win32x86_201803032041 which is more recent, but still with the same outcome: 3D primitives are missing.>
and if you put "B3DXUsesOpenGL=0" in Squeak.ini what happens then? AFAICT all the 3D support is included in the VM as it ever was. I'm sorry, but I'm not very familiar with the 3D support on Windows. I do know that Ronie got the OpenGL example working on Mac OS in 32 and 64 bits late last year. And I think we tested all platforms and found it worked. What that implies for the B3DAcceleratorPlugin on win32 I don't know.
Stef
_,,,^..^,,,_ best, Eliot
Is the Squeak3D plugin included as well? I think that's the one Stef wants, in addition to B3DAcceleratorPlugin.
- Bert -
On Sat, Mar 3, 2018 at 11:41 PM, Stéphane Rollandin lecteur@zogotounga.net wrote:
Aditional Alice stuff here
http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf http://squeakros.org/FunSqueak4.6/SqueakObjects.zip
Is there somewhere a cog VM for windows with 3D support?
Thinking, you need to check the Squeak.ini for B3DXUsesOpenGL=1
Regards, Nikolai
Stef
Aditional Alice stuff here http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf <http://squeakros.org/FunSqueak4.6/Alice%20in%20a%20Squeak.pdf> http://squeakros.org/FunSqueak4.6/SqueakObjects.zip <http://squeakros.org/FunSqueak4.6/SqueakObjects.zip> Is there somewhere a cog VM for windows with 3D support?Thinking, you need to check the Squeak.ini for B3DXUsesOpenGL=1
Thanks. It appears it is the case.
More details:
I have been using Cog VM 45 (release) from March 10, 2016 to open the FunSqueak4dot6 image provided by Edgar.
There I did 'Wonderland new' in a workspace, and got the warning message:
"This Squeak does not have read 3D support. Opening a Wonderland will be EXTREMELY time consuming"
Tracing back the origin of this message, I saw that 'B3DPrimitiveEngine isAvailable' returns false (because in turn B3DPrimitiveRasterizer, B3DPrimitiveShader and B3DPrimitiveTransformer are not available) hence my question.
Following your suggestion, I did checked that indeed B3DXUsesOpenGL=1 in the Squeak.ini
best,
Stef
Edgar J. De Cleene-3 wrote
The las FunSqueak was here http://squeakros.org/FunSqueak4.6/ScreenSnapz.jpg http://squeakros.org/FunSqueak4.6/FunSqueak4dot.6.zip
Is this still the most recent FunSqueak? If so, what VM does it work with? I flopped around between the available VMs from the Downloads page (cog/spur/stack/v3/etc), but couldn't find the magic combination! Thanks :)
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Is 4.6 so any Cog (no Cog Spur) should work well If you just don't'sure, download the official 4.6 All in one , Once you unzip , navigate inside folders (in Mac as me should right click and show Package Contents) Inside you found the folders with the appropiate VMs. Select yours, do a copy and paste where appropiate for your OS. Application folders for Mac, where also a copy of appropiate .sources should (4.6 in FunSqueaqk)/ Locate also info.plist and edit some like this to FunSqueak
<key>SqueakImageName</key> <string>Squeak6.0alpha-17606-32bit.image</string>
On Windows you could put all in Documents folder (or in a Squeak folder) and the trick launch your ,image.
Appreciate some on Linux give us the necessary tricks for have the right VM in the right place.
Edgar @morplenauta
On 01/04/2018, 23:26, "Sean P. DeNigris" sean@clipperadams.com wrote:
Is this still the most recent FunSqueak? If so, what VM does it work with? I
flopped around between the available VMs from the Downloads
page
(cog/spur/stack/v3/etc), but couldn't find the magic combination! Thanks
:)
Edgar J. De Cleene-3 wrote
Is 4.6 so any Cog (no Cog Spur) should work well
I navigated from the DL page to the OpenSmalltalk VMs [1] and tried four combinations starting with "cog_macos32x86_squeak". Nothing seemed to work :/
Edgar J. De Cleene-3 wrote
download the official 4.6 All in one…
That worked! I'm in business. Thanks :)
1. https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201608171728
----- Cheers, Sean -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Edgar J. De Cleene-3 wrote
On 01/03/2018, 23:17, "David T. Lewis" <
lewis@.msen
> wrote:
I'm could be that person.
Edgar @morplenauta
Go Edgar Go !
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi All,
I was looking for the written summary of what the current Release process looks like, but I couldn't find any. So, I was wondering what the current Release process looks like, and what the role of the Release manager is. I have a vague idea about these, but it would be nice to have a checklist at least.
Levente
On Thu, 1 Mar 2018, David T. Lewis wrote:
According to our web site, the current release is Squeak 5.1, and trunk is Squeak 6.0alpha.
I think it has been about a year since the last official release, and a lot of great stuff has gone into trunk during that time. So it would be good to put out an official release some time soon. For that we should identify a person to serve as release manager to make it happen. I expect we will discuss this in our board meeting next week, but input (and volunteers or nominations) from anyone in the community would certainly be welcome.
If we do something in the near term, then it would make sense to me if it was called Squeak 5.2. And if that happens, it would be good to incorporate full support for ephemerons and read only objects into whatever release comes next after that.
In the mean time, my view would be that any changes for support of read only objects and ephemerons should be introduced as soon as possible regardless of the release schedule, just as long as this can be done without requiring incompatible VM changes. I'm not quite clear on whether that is the case here. But basically what I am trying to say is let's move this forward as quickly as possible. If it is a change that would cause pain for general users of Squeak, then hold off until after then next release, and let's make sure that next release happens soon.
So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's find a release manager and make it happen.
And just so we do not forget - The last release was still focused on 32 bit images. The 64 bit system is not longer experimental, so we need to publicize this better in our next release and document the limitations so that users are aware that they will not be able run their 64 bit image on a 32 bit platform.
Dave
On Thu, Mar 01, 2018 at 09:57:52AM -0800, Eliot Miranda wrote:
Hi All,
we're moving close to a new Squeak release. There are some issues todiscuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on.
- 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.
- 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
Hi, there.
the release manager has to update the release notes [1], our Website [2], and our CI infrastructure [3][4].
The release-specific in-image code can be found here: ReleaseBuilder class >> #setPreferences ReleaseBuilder class >> #configureDesktop ReleaseBuilder class >> #configureTools ReleaseBuilder class >> #releaseRepositoryName (! read only !)
You can tell the community about the different steps in the release process by running step1*-step3* messages in ReleaseBuilder (see category "manual -steps"). This basically changes the system version, which you have to communicate in a changed "ReleaseBuilder class >> #initialize" method to be committed to the Trunk repository.
Finally, after you updated the CI to produce release images automatically, reset the Trunk version again via "ReleaseBuilder class >> #step0AssureAlpha". Make up some new version like "6.5" or "7.0" ... which will be the current Alpha Trunk version from that point on. Or return to "6.0" if this release would be "5.2".
Most of the other stuff you find in the ReleaseBuilder is for local try-outs only. You can also take a look at the full Smalltalk CI script [5].
Best regards, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/tree/squeak-trunk/release-not... [https://github.com/squeak-smalltalk/squeak-app/tree/squeak-trunk/release-not...] [2] https://github.com/squeak-smalltalk/squeak.org [https://github.com/squeak-smalltalk/squeak.org] [3] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/.travis.yml [https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/.travis.yml] [4] http://files.squeak.org/base/ [http://files.squeak.org/base/] [5] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_ima... [https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_ima...] Am 06.03.2018 16:25:25 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi All,
I was looking for the written summary of what the current Release process looks like, but I couldn't find any. So, I was wondering what the current Release process looks like, and what the role of the Release manager is. I have a vague idea about these, but it would be nice to have a checklist at least.
Levente
On Thu, 1 Mar 2018, David T. Lewis wrote:
According to our web site, the current release is Squeak 5.1, and trunk is Squeak 6.0alpha.
I think it has been about a year since the last official release, and a lot of great stuff has gone into trunk during that time. So it would be good to put out an official release some time soon. For that we should identify a person to serve as release manager to make it happen. I expect we will discuss this in our board meeting next week, but input (and volunteers or nominations) from anyone in the community would certainly be welcome.
If we do something in the near term, then it would make sense to me if it was called Squeak 5.2. And if that happens, it would be good to incorporate full support for ephemerons and read only objects into whatever release comes next after that.
In the mean time, my view would be that any changes for support of read only objects and ephemerons should be introduced as soon as possible regardless of the release schedule, just as long as this can be done without requiring incompatible VM changes. I'm not quite clear on whether that is the case here. But basically what I am trying to say is let's move this forward as quickly as possible. If it is a change that would cause pain for general users of Squeak, then hold off until after then next release, and let's make sure that next release happens soon.
So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's find a release manager and make it happen.
And just so we do not forget - The last release was still focused on 32 bit images. The 64 bit system is not longer experimental, so we need to publicize this better in our next release and document the limitations so that users are aware that they will not be able run their 64 bit image on a 32 bit platform.
Dave
On Thu, Mar 01, 2018 at 09:57:52AM -0800, 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.
- 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.
- 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
Resuming mail exchange with Marcel and my view about a release.
Beside administrative task, the person in charge should do.
Run the test for the Squeak X.y .image on and inform this to list. Use the image and try to do elemental task a average user do. Report any Debugger Window showing and put relevant info in Mantis. Try to found methods which could be the problem and inform to person if posible.
Board must set a date for things was done. In ten minutes I found three odd debugger windows running the test
Copy paste here some I send to Marcel
This was the third, in the middle another escape me for picture But at this early point we have
4465 run, 4384 passes, 34 expected failures, 34 failures, 13 errors, 0
unexpected passes
I>¹m afraid this could not go out
We all wish a good release or not ? Edgar @morplenauta
On 06/03/2018, 12:29, "Marcel Taeumel" marcel.taeumel@hpi.de wrote:
Hi, there.the release manager has to update the release notes [1], our Website [2], and our CI infrastructure [3][4].
The release-specific in-image code can be found here: ReleaseBuilder class >> #setPreferences ReleaseBuilder class >> #configureDesktop ReleaseBuilder class >> #configureTools ReleaseBuilder class >> #releaseRepositoryName (! read only !)
You can tell the community about the different steps in the release process by running step1*-step3* messages in ReleaseBuilder (see category "manual -steps"). This basically changes the system version, which you have to communicate in a changed "ReleaseBuilder class >> #initialize" method to be committed to the Trunk repository.
Finally, after you updated the CI to produce release images automatically, reset the Trunk version again via "ReleaseBuilder class >> #step0AssureAlpha". Make up some new version like "6.5" or "7.0" ... which will be the current Alpha Trunk version from that point on. Or return to "6.0" if this release would be "5.2".
Most of the other stuff you find in the ReleaseBuilder is for local try-outs only. You can also take a look at the full Smalltalk CI script [5].
Best regards, Marcel
[1] https://github.com/squeak-smalltalk/squeak-app/tree/squeak-trunk/release-not... [2] https://github.com/squeak-smalltalk/squeak.org [3] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/.travis.yml [4] http://files.squeak.org/base/ [5] https://github.com/squeak-smalltalk/squeak-app/blob/squeak-trunk/prepare_ima... .st
Am 06.03.2018 16:25:25 schrieb Levente Uzonyi leves@caesar.elte.hu: Hi All,
I was looking for the written summary of what the current Release process looks like, but I couldn't find any. So, I was wondering what the current Release process looks like, and what the role of the Release manager is. I have a vague idea about these, but it would be nice to have a checklist at least.
Levente
On Thu, 1 Mar 2018, David T. Lewis wrote:
According to our web site, the current release is Squeak 5.1, and trunk is Squeak 6.0alpha.
I think it has been about a year since the last official release, and a lot of great stuff has gone into trunk during that time. So it would be good to put out an official release some time soon. For that we should identify a person to serve as release manager to make it happen. I expect we will discuss this in our board meeting next week, but input (and
volunteers
or nominations) from anyone in the community would certainly be welcome.
If we do something in the near term, then it would make sense to me if it was called Squeak 5.2. And if that happens, it would be good to
incorporate
full support for ephemerons and read only objects into whatever release comes next after that.
In the mean time, my view would be that any changes for support of read only objects and ephemerons should be introduced as soon as possible regardless of the release schedule, just as long as this can be done without requiring incompatible VM changes. I'm not quite clear on whether that is the case here. But basically what I am trying to say is let's move this forward as quickly as possible. If it is a change that would cause pain for general users of Squeak, then hold off until after then next release, and let's make sure that next release happens soon.
So +1 for your proposal, but maybe call it 5.2 rather than 5.5, and let's find a release manager and make it happen.
And just so we do not forget - The last release was still focused on 32 bit images. The 64 bit system is not longer experimental, so we need to publicize this better in our next release and document the limitations so that users are aware that they will not be able run their 64 bit image on a 32 bit platform.
Dave
On Thu, Mar 01, 2018 at 09:57:52AM -0800, 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.
- 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.
- 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
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?
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.
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.
- 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.
- 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
Hi all,
On Fri, Mar 2, 2018 at 11:30 AM K K Subbu kksubbu.ml@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 issuesto discuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on.
- 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.
- 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
On Friday 02 March 2018 05:43 PM, Fabio Niephaus wrote:
Hi all,
On Fri, Mar 2, 2018 at 11:30 AM K K Subbu <kksubbu.ml@gmail.com mailto:kksubbu.ml@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!
The message was posted to squeak-dev, so I assumed it was about Squeak (the image). However, the Squeak VM is not really independent of Squeak (the image) today. Part of VM is written in Slang and translated by Squeak. My question was really about the plans to delink VM release from the image release cycle. When a new Squeak image is released, will it replace the reference image used to build the VM?
With the VM code moving to git and use of CI to automate patch, build and test cycles, a full Squeak image may be an overkill. If OpenSmalltalk is factored out to a separate release cycle, then only a tiny Squeak image will be required to configure and translate Slang to C.
Should this thread continue in vm-dev instead?
Regards .. Subbu
I like to know this tiny Squeak image
On 02/03/2018, 12:35, "K K Subbu" kksubbu.ml@gmail.com wrote:
With the VM code moving to git and use of CI to automate patch, build
and
test cycles, a full Squeak image may be an overkill. If
OpenSmalltalk is
factored out to a separate release cycle, then only a
tiny Squeak image will
be required to configure and translate Slang to C.
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@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 issuesto discuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on.
- 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.
- 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
Hi Fabio,
forgive me for not replying sooner. The felt more than a little foolish. Perhaps we could catch up on skype or google chat to discuss getting the release done. Clément has done a major merge of his recent work and we have to iron out those issues plus I want to enable read-only object support in the Squeak VMs. Hopefully there are only a few days work necessary.
_,,,^..^,,,_ (phone)
On Mar 2, 2018, at 4:13 AM, Fabio Niephaus lists@fniephaus.com wrote:
Hi all,
On Fri, Mar 2, 2018 at 11:30 AM K K Subbu kksubbu.ml@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 issuesto discuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on.
- 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.
- 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
About the next Squeak release:
May I push yet another call to include the 3D plugin in current VMs?
From where I am it does not seem that Eliot's call for checking what happened to 3D support has been answered.
Stef
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
Chris Cunningham -
David T. Lewis -
Edgar J. De Cleene -
Eliot Miranda -
Fabio Niephaus -
garduino -
H. Hirzel -
K K Subbu -
Levente Uzonyi -
Marcel Taeumel -
Nikolay Suslov -
Sean P. DeNigris -
Stéphane Rollandin