Hi, I wonder what’s changed that the images starting from Squeak6.0beta-21772-64bit on won’t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I’m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
Thanks,
--
Jaromír Matas
mail@jaromir.net
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
Hi Dave --
I wonder why I cannot change the format from 68021 to 68533 via
CompiledCode multipleBytecodeSetsActive: true. Smalltalk snapshot: true andQuit: true.
Any ideas? At least the System Reporter does not report that format. Is this a VM bug?
Best, Marcel Am 29.05.2022 16:04:04 schrieb David T. Lewis lewis@mail.msen.com: On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
Hi Dave --
See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638]
Should we fix this in the image or in the VM?
Best, Marcel Am 30.05.2022 11:48:03 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Dave --
I wonder why I cannot change the format from 68021 to 68533 via
CompiledCode multipleBytecodeSetsActive: true. Smalltalk snapshot: true andQuit: true.
Any ideas? At least the System Reporter does not report that format. Is this a VM bug?
Best, Marcel Am 29.05.2022 16:04:04 schrieb David T. Lewis lewis@mail.msen.com: On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
Hi Dave --
Here is a possible in-image fix for this problem.
Best, Marcel Am 30.05.2022 11:57:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Dave --
See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638 [https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638]
Should we fix this in the image or in the VM?
Best, Marcel Am 30.05.2022 11:48:03 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Dave --
I wonder why I cannot change the format from 68021 to 68533 via
CompiledCode multipleBytecodeSetsActive: true. Smalltalk snapshot: true andQuit: true.
Any ideas? At least the System Reporter does not report that format. Is this a VM bug?
Best, Marcel Am 29.05.2022 16:04:04 schrieb David T. Lewis lewis@mail.msen.com: On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
Hi all,
I wonder if (or how) this is supposed to work:
I’d like to open the latest image using an old VM; I used to do that by copying the old VM’s files into the new image’s directory but it doesn’t work any longer (I’m on Win10); I don’t know how these things are supposed to work; please, could someone point me in the right direction or maybe just confirm it’s not working yet :) Thanks, Jaromir
From: Marcel Taeumelmailto:marcel.taeumel@hpi.de Sent: Monday, May 30, 2022 13:48 To: squeak-devmailto:squeak-dev@lists.squeakfoundation.org; vm-devmailto:vm-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Older VM's won't start the latest beta images
Hi Dave --
Here is a possible in-image fix for this problem.
Best, Marcel
Am 30.05.2022 11:57:22 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Dave --
See https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/638
Should we fix this in the image or in the VM?
Best, Marcel
Am 30.05.2022 11:48:03 schrieb Marcel Taeumel marcel.taeumel@hpi.de: Hi Dave --
I wonder why I cannot change the format from 68021 to 68533 via
CompiledCode multipleBytecodeSetsActive: true. Smalltalk snapshot: true andQuit: true.
Any ideas? At least the System Reporter does not report that format. Is this a VM bug?
Best, Marcel
Am 29.05.2022 16:04:04 schrieb David T. Lewis lewis@mail.msen.com: On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
On Sat, Jun 25, 2022 at 11:32:48AM +0000, Jaromir Matas wrote:
Hi all,
I wonder if (or how) this is supposed to work:
I?d like to open the latest image using an old VM; I used to do that by copying the old VM?s files into the new image?s directory but it doesn?t work any longer (I?m on Win10); I don?t know how these things are supposed to work; please, could someone point me in the right direction or maybe just confirm it?s not working yet :) Thanks, Jaromir
This is a planned update to the image format number for the saved image files (saved in the first few bytes of the squeak.image file).
If you want to run the release image using an older VM, there are two things that you an do:
1) If you have a new VM available, use the new VM to open the image. Then, in a workspace, evaluate "CompiledCode multipleBytecodeSetsActive: false" and save the image. The image can now be run with an older VM.
2) Patch the image from another image. For example, you have newimage.image (e.g. the release image) that you want to change to have the older format number, and if you have an older image that works on your older VM, then open your older image and do this:
- In a Montecello browser, add http repository http://source.squeak.org/VMMaker - Load package ImageFormat - In a workspace, evaluate "ImageFormat clearSistaBit: 'path/to/newimage.image' "
This will rewrite the first 4 bytes of your image file, setting the format number back to something that an older VM will recognize.
More information is available at http://wiki.squeak.org/squeak/6290. Class ImageFormat exists largely for purposes of documentation, so the class and method comments provide some explanation:
HelpBrowser openOn: ImageFormat
ImageFormat also provides the source code for the ckformat utility (which probably can be compiled on Windows but I have not checked)
"ImageFormat createCkFormatProgram"
The generated source for ckformat is at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/ckformat.c
Dave
Brilliant, thanks a lot for the detailed explanation!
in a workspace, evaluate "CompiledCode multipleBytecodeSetsActive: false" and save the image. The image can now be run with an older VM.
Works like a charm :)
Thanks again, Jaromir
From: David T. Lewismailto:lewis@mail.msen.com Sent: Saturday, June 25, 2022 16:36 To: The general-purpose Squeak developers listmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Older VM's won't start the latest beta images
On Sat, Jun 25, 2022 at 11:32:48AM +0000, Jaromir Matas wrote:
Hi all,
I wonder if (or how) this is supposed to work:
I?d like to open the latest image using an old VM; I used to do that by copying the old VM?s files into the new image?s directory but it doesn?t work any longer (I?m on Win10); I don?t know how these things are supposed to work; please, could someone point me in the right direction or maybe just confirm it?s not working yet :) Thanks, Jaromir
This is a planned update to the image format number for the saved image files (saved in the first few bytes of the squeak.image file).
If you want to run the release image using an older VM, there are two things that you an do:
1) If you have a new VM available, use the new VM to open the image. Then, in a workspace, evaluate "CompiledCode multipleBytecodeSetsActive: false" and save the image. The image can now be run with an older VM.
2) Patch the image from another image. For example, you have newimage.image (e.g. the release image) that you want to change to have the older format number, and if you have an older image that works on your older VM, then open your older image and do this:
- In a Montecello browser, add http repository http://source.squeak.org/VMMaker - Load package ImageFormat - In a workspace, evaluate "ImageFormat clearSistaBit: 'path/to/newimage.image' "
This will rewrite the first 4 bytes of your image file, setting the format number back to something that an older VM will recognize.
More information is available at http://wiki.squeak.org/squeak/6290. Class ImageFormat exists largely for purposes of documentation, so the class and method comments provide some explanation:
HelpBrowser openOn: ImageFormat
ImageFormat also provides the source code for the ckformat utility (which probably can be compiled on Windows but I have not checked)
"ImageFormat createCkFormatProgram"
The generated source for ckformat is at https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/src/ckformat.c
Dave
Hi Dave, Hi Jaromir,
On May 29, 2022, at 7:03 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
I don’t think that’s the reason. Older VMs have supported the Sista bytecode set fir several years. However, older VMs lack the new suspend primitives. These have only been in the vm for about three months.
Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out. See the -trace argument. The documentation on the flag bits is (alas) in a VMMaker.oscog method on Cogit. (This I should fix)
Eliot, _,,,^..^,,,_ (phone)
Hi Eliot,
Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out.
The trouble with me is I’ve only ever run the VM by doubleclicking Sqeak.exe icon so far… I’ll try my best though :D
I only wanted to verify the older VMs run with the new #suspend ok - which they do except one thing: #isTerminated only recognizes the process as terminated when the pc is at the end of the bottom context - which is not true if suspend uses the fallback code and builds another context on top of the bottom one and suspends there…
I don’t know if this is relevant or not to keep this level of compatibility with the older VMs but fixing #isTerminated seems easy in case anyone’s interested - see attached.
Thanks, Jaromir
From: Eliot Mirandamailto:eliot.miranda@gmail.com Sent: Saturday, June 25, 2022 18:45 To: The general-purpose Squeak developers listmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Older VM's won't start the latest beta images
Hi Dave, Hi Jaromir,
On May 29, 2022, at 7:03 AM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
Dave
I don’t think that’s the reason. Older VMs have supported the Sista bytecode set fir several years. However, older VMs lack the new suspend primitives. These have only been in the vm for about three months.
Jaromir, you should be able to run the vm turning on the send trace and see where an image starts to crap out. See the -trace argument. The documentation on the flag bits is (alas) in a VMMaker.oscog method on Cogit. (This I should fix)
Eliot, _,,,^..^,,,_ (phone)
On Sun, May 29, 2022 at 7:03 AM David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from
Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe
and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
So given that older VMs supported the bytecode set and have (as do all Cog VMs) a VM parameter flag bit to indicate this, what's the rationale for the image format number including whether the image chooses to use the bytecode set or not?
Dave
On Sat, Jun 25, 2022 at 10:30:54AM -0700, Eliot Miranda wrote:
On Sun, May 29, 2022 at 7:03 AM David T. Lewis lewis@mail.msen.com wrote:
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from
Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new VMs (e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs WerFault.exe
and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
So given that older VMs supported the bytecode set and have (as do all Cog VMs) a VM parameter flag bit to indicate this, what's the rationale for the image format number including whether the image chooses to use the bytecode set or not?
To the best of my recollection, it's something that we all agreed on a few years ago. The commit notice in ImageFormat-dtl.37 refers to our oversight board meeting of 2019-05-15. You were part of that discussion.
Getting the update into the VM took longer than originally anticipated.
Dave
On Sat, Jun 25, 2022 at 11:16 AM David T. Lewis lewis@mail.msen.com wrote:
On Sat, Jun 25, 2022 at 10:30:54AM -0700, Eliot Miranda wrote:
On Sun, May 29, 2022 at 7:03 AM David T. Lewis lewis@mail.msen.com
wrote:
On Sun, May 29, 2022 at 08:06:59AM +0000, Jaromir Matas wrote:
Hi, I wonder what?s changed that the images starting from
Squeak6.0beta-21772-64bit on won?t start with the previous release VM (squeak.cog.spur_win64x64_202003021730) or even with pre-release new
VMs
(e.g. version 3154).
I?m on Win10, the process explorer (windows) shortly runs
WerFault.exe
and than the Squeak process is closed/disappears.
The change is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2022-May/220660.html
The current release candidate image does not have this, but it will be applied as soon as you update that image, and it expected to be part of the final release. The update applies a new image format number to the saved image files (stored in the first 4 bytes of the image file) when multiple bytecode set support is required from the VM. Effectively, the means that the image is using the Sista bytecode set. Older VMs can run the Sista bytecodes but do not yet have the code for recognizing the additional image format number.
So given that older VMs supported the bytecode set and have (as do all
Cog
VMs) a VM parameter flag bit to indicate this, what's the rationale for
the
image format number including whether the image chooses to use the
bytecode
set or not?
To the best of my recollection, it's something that we all agreed on a few years ago. The commit notice in ImageFormat-dtl.37 refers to our oversight board meeting of 2019-05-15. You were part of that discussion.
And of course I've long forgotten. It feels over complicated to me now. Bit I do see that setting the flags from the image via a primitive (preferably vmParameterAt: rather than a whole bespoke primitive for 1 parameter) is better than having the VM note when it's using a particular bytecode set.
BTW, part of the commit comment is probably wrong. I would expect both fields 0 implying a pre-Sista (V3) bytecode set. I would expect 0, 1 to imply V3 primary, SistaV1 secondary, etc.
Getting the update into the VM took longer than originally anticipated.
No matter. We have it now and you explained the fix to Jaromir, who wants to do this for special reasons (testing that the suspend fallback code functions properly, even though this isn't strictly necessary).
Dave
_,,,^..^,,,_ best, Eliot
squeak-dev@lists.squeakfoundation.org
-
David T. Lewis -
Eliot Miranda -
Jaromir Matas -
Marcel Taeumel