[Vm-dev] Re: Numbered primitives in images

Bert Freudenberg bert at freudenbergs.de
Sun Jan 17 19:02:23 UTC 2010


On 17.01.2010, at 16:39, David T. Lewis wrote:
> 
> 
> On Sun, Jan 17, 2010 at 08:43:37PM +0530, K. K. Subramaniam wrote:
>> On Sunday 17 January 2010 12:50:17 am David T. Lewis wrote:
>>> Doing it automatically based on imageFormatVersion would probably
>>> work, but has a catch-22 for someone adding closures to an older
>>> image (e.g. adding the closure support to Etoys). For that situation
>>> you want to be able to turn on closure support even though the image
>>> does not yet need them, so perhaps e.g. a "-closures" command line
>>> option turn on closure support in that case.
>>> 
>>> Any other ideas?
>> An image may run on a VM on multiple platforms and not all may be at the same 
>> rev, breaking backward compatibility between 3.10 and 3.11 may cause more 
>> grief than necessary.
>> 
>> How about patching the VM to check for env variable (say SQUEAK_PRIM311) in 
>> addition to checking for -closures?
> 
> I guess we're still looking for ideas at this point. As Eliot points
> out, rewriting the primitive table (which is probably what we would
> do based on s SQUEAK_PRIM311 flag) is a messy hack, and it would be
> best not to put that sort of thing into the VM.
> 
> Perhaps a BackwardCompatibilityHacksPlugin to keep the messy stuff
> out of the main VM would be possible. To extend the challenge a bit
> further, it would be interesting to see how far back in time we could
> go with a single VM. The ftp.squeak.org site has images going all the
> way back to Squeak 1.1.
> 
> Dave

IIUC the unix 3.10-5 VM is still okay and 3.10-6 changed this. We're sort-of lucky that the latest VM package in Fedora is still 3.10-5 (meaning the new OLPC OS will still support Scratch) but it is unfortunate that a minor version would break this. At least I wasn't aware the closure support does break backwards compatibility, and apparently Ian neither, or he would have at least made the change in 3.11 (if not 4.x).

- Bert -




More information about the Vm-dev mailing list