VM/Image magic numbers (Re: Pharo 6 snap install)
The "magic decode for image files" seems related and possibly *very* useful.... http://forum.world.st/magic-decode-for-image-files-td4941712.html#a4941837 Now traditionally the VM has been backward compatible with old Images, but Pharo doesn't necessarily adhere to that and policy IIUC is release specific VM/Image pairs. So does Pharo require extra magic numbers to co-ordinate this? And how would this interact with OpenSmalltalk policy on these magic numbers? cheers -ben On Sat, Apr 15, 2017 at 4:20 AM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
This is what we always have when we release and we freeze it. The vm 60 will be compatible with latest pharo 60 image.
On Fri, Apr 14, 2017 at 12:09 PM, Luke Gorrie <luke@snabb.co> wrote:
On 14 April 2017 at 08:53, Stephane Ducasse <stepharo.self@gmail.com> wrote:
We always try to have a major release around mid/end of april
Once the dust settles, I think it would be wonderful to have this invariant:
- The latest Pharo VM source release is compatible with the latest Pharo image.
This would make it easy for me to help nix users. My job will be to package the latest source release of the VM, period, and I will know that users can use this to run the latest image. I don't have much scope to screw things up and make people sad e.g. by shipping a bad commit from the master branch.
(Of course it makes life harder for you upstream Pharo maintainers. Now updating the VM source release is a blocker for releasing a new image. Could be that this is too constraining in practice, I dunno. I'm just a guy who wants to setup a stable Pharo that I can use to build an application :-))
On 15 April 2017 at 01:22, Ben Coman <btc@openinworld.com> wrote:
The "magic decode for image files" seems related and possibly *very* useful.... http://forum.world.st/magic-decode-for-image-files-td4941712.html#a4941837
Now traditionally the VM has been backward compatible with old Images, but Pharo doesn't necessarily adhere to that and policy IIUC is release specific VM/Image pairs. So does Pharo require extra magic numbers to co-ordinate this? And how would this interact with OpenSmalltalk policy on these magic numbers?
I would really like a copy of the script that checks the magic number and starts the right VM. David, could you share yours please? I started writing case file -m @share@/magic "$image" in 'Smalltalk image V3 32b*') vm=@pharo-vm-cog@ ;; 'Smalltalk image Spur 32b*') vm=@pharo-vm-spur@ ;; 'Smalltalk image Spur 64b*') vm=@pharo-vm-spur64@ ;; *) echo unrecognized image file format ;; esac ... but would prefer to avoid reinventing the wheel e.g. on how to find the image name in amongst the various options passed to $@. I would quite like for my package to be able to open the pharo-launcher image and the various images that this downloads. This means supporting pre-spur images. I would ideally like to do that by building a non-spur version of the latest VM, but I am not sure if that is supported for pharo, there is no mvm script for non-spur. The alternative would be to just build an old VM release with cmake.
On Tue, Apr 18, 2017 at 11:11:07PM +0200, Luke Gorrie wrote:
On 15 April 2017 at 01:22, Ben Coman <btc@openinworld.com> wrote:
The "magic decode for image files" seems related and possibly *very* useful.... http://forum.world.st/magic-decode-for-image-files-td4941712.html#a4941837
Now traditionally the VM has been backward compatible with old Images, but Pharo doesn't necessarily adhere to that and policy IIUC is release specific VM/Image pairs. So does Pharo require extra magic numbers to co-ordinate this? And how would this interact with OpenSmalltalk policy on these magic numbers?
I would really like a copy of the script that checks the magic number and starts the right VM. David, could you share yours please?
Attached. Dave
participants (3)
-
Ben Coman -
David T. Lewis -
Luke Gorrie