[self-interest] Snapshot binary compatibility ?
Jecel Assumpcao Jr
jecel at merlintec.com
Mon Jul 1 17:31:56 UTC 2002
On Friday 28 June 2002 19:47, Harald Gliebe wrote:
> Thanks, with a quick hack I was able to convert the Demo.snap from
> the Sparc version for the Linux version(available at
Great! That is much easier than trying to recreate the tutorials inside
a new empty snapshot. One little difference relative to the Sparc
version was that all the label morphs showed the '\n' character as a
little box, while in the Sparc they are invisible. But it does complain
about a missing "arialBold" font on the Sparc while my Linux box is set
up to import it from Windows...
> I just had to convert everything
> except one char (which indicates if the maps are canonical in the
> snapshot) and the bytes of byteVectorOops and stringOops (which are
> stored in the upper part of the spaces).
This non pointer "segregation" really comes in handy here.
> Adding a header field to
> determine the endianess would be ideal, but might break backward
> compatibility with existing snapshots and would also require changes
> in the Sparc and Mac-versions.
It would require changes to the Sparc and Mac VMs, but it would be the
exact same code in all three versions. The modified VMs should be able
to read old snapshots.
> Another possibilty would be to store everything in bigendian format,
> swaping some bytes while loading and saving doesn't cost to much (the
> disk is probably slower anyway).
This is probably the best option. It seems wasteful to swap bytes twice
when saving and then reading on the PC but, as you said, the overhead
is not noticeable.
> I'll have a look at Squeak images before I decide wether to add an
> command-line option to import Sparc/Mac-snapshots or use the
> big-endian format as default.
See method #reverseBytesInImage in class Interpreter (category
VMConstruction-Interpreter). They essentially do the exact same thing
as you did but less elegantly since non pointer objects are mixed in
with the rest in the snapshot. The only real complication was Form
objects, since their endianess should really match that of the video
board, not of the processor.
> > [separating Linux stuff into different modules]
> That's a very good idea, I'll do it for the next version. Using diff
> with *.self files isn't much fun.
After thinking about this a little, it might be better to keep things as
they are and merge the Linux patches into the Sparc/Mac sources.
Specially if we will be sharing snapshots from now on.
Doing diff on the *.self files worked better than I expected. I found
this change surprising:
diff -r Self4Linux-0.2.2.src/objects/glue/xlib_glue.cpp
< strncpy(buffer, result, size);
> strncat(buffer, result, size);
All the rest made perfect sense.
More information about the Self-interest