2009/5/7 David T. Lewis lewis@mail.msen.com:
On Wed, May 06, 2009 at 08:28:13AM -0700, Andreas Raab wrote:
One thing we could do is for the next generation of VMs which have a new image format won't be referred to as Squeak 3x etc. to up the interpreter proxy major number and use only that mechanism. Thoughts?
I don't have a clear idea of what the roadmap to next generation VM's looks like. We have a lot of interesting projects and new ideas (Hydra, iPhone, Cog, Exupery, Croquet, ...).
I have a general sense that it is the responsibility of the image to identify its image format (hence what it requires of a VM) by means of an imageFormatVersionNumber known to the image and saved in the file header when saving the image. And it is the responsibility of a VM to know its capabilities in order to determine if it can interpret an image of some declared imageFormatVersionNumber.
My guess would be that yes, we will soon be due for a new interpreter proxy major number, but no that mechanism is not sufficient to identify the next generation VM(s). Specifically, knowing the major/minor interpreter proxy numbers will not tell you if a VM has the necessary capabilities to support the requirements of an image with a given imageFormatVersionNumber.
Right it doesn't. The interpreterProxy version numbers could only serve for indication, what version of external API is supported by VM , or not. But in Hydra, i eliminated that too. Interpreterproxy structure v.2.1 contains only 3 function pointers:
sqInt (*minorVersion)(void); sqInt (*majorVersion)(void);
/* IMPORTANT!!! * The rest of functions can be obtained by plugin by calling a getVMFunctionPointerBySelector function. * The need in defining additional functions in this struct is gone forever */ void * (*getVMFunctionPointerBySelector)(char * selector);
as you see, in case of Hydra, going past v.2.1. is quite pointless. :)
Dave