>> It's right where we left it. Spur introduces a new object memory
>> format, so we're doing the right thing: we're breaking the format and
>> telling people.
>>
>> When you load packages into a Spur image, things will just work. When
>> you load changesets, things will just work. As far as I know, we've
>> taken care that ImageSegments will also load into Spur, and just work.
>
>
> Ah, not quite.  Image segments saved in 32-bit Spur will load in 32-bit
> Spur.  Image segments saved in 64-bit Spur will load in 64-bit Spur.  Image
> segments saved in Cog will load in Cog.  But no interoperability is possible
> (yet!).  And indeed I believe that image segments saved in the 64-bit
> Interpreter VM will only load in that 64-bit VM.

64-bit will not be ready in time for 5.0 on 4/30 right?

> The problem with image segments is that they are in the format of the VM's
> heap objects.  However, Bert and I want co co-mentor a project to implement
> image-level support for loading segments from "foreign" object memories.
> Alas GSoC did not approve our organization this year.  Maybe soon.  Or maybe
> some student at one of the teaching institutions using Squeak or Pharo would
> be interested in having a go.
>
> Note that e.g. Fuel does not have this problem.

Nor does Ma Object Serializer.  Ma Object Serializer has been updated
to be transparently Spur compatible, so for 32-bit systems anyway, one
could load ImageSegment file into a Cog image, save it with Ma, go
into spur and load it with Ma, and then finally save it as
ImageSegment.  You could even stay as Ma for a while because I intend
to do the same for 64-bit.

> +1.  Spur has lots of advantages over the existing system but these can't be
> introduced without forcing a change to a new image and a new VM.

Now that we've answered the troll-style question extensively, may we
please talk about ideas to help users manage multiple formats?