Loading ...
Sorry, an error occurred while loading the content.

Re: [self-interest] Snapshot binary compatibility ?

Expand Messages
  • David Ungar
    Sure--I move snapshots back and forth all the time. The endianness makes it easier. - David ... -- David Ungar Sun Microsystems Laboratories (650) 336-2618
    Message 1 of 8 , Jun 28, 2002
    • 0 Attachment
      Sure--I move snapshots back and forth all the time.
      The endianness makes it easier.

      - David


      At 3:25 PM +0200 6/28/02, Harald Gliebe wrote:
      >Hi all,
      >
      >could anyone who is lucky enough to own a Sparc and a Mac tell me if it's
      >possible to exchange snapshots between these two platforms ?
      >One reason why the sparc-Snapshots don't work on Linux/Intel is of course
      >the different endianess of the architectures, but this could easily be
      >converted. If the snapshots work on Sparc and Mac, I'll try to add this
      >feature for the Linux version.
      >
      >Best regards,
      >Harald Gliebe
      >
      >
      >
      >
      >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


      --


      David Ungar
      Sun Microsystems Laboratories
      (650) 336-2618
    • Jecel Assumpcao Jr
      ... 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
      Message 2 of 8 , Jul 1, 2002
      • 0 Attachment
        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
        > http://gliebe.de/self/Demo.snap.gz),

        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
        self4.1.5/glue/xlib_glue.cpp
        547c547
        < strncpy(buffer, result, size);
        ---
        > strncat(buffer, result, size);

        All the rest made perfect sense.

        -- Jecel
      • Harald Gliebe
        ... That is caused by the different X servers, if I redirect the display from a Sparc VM to a linux box, I also get these boxes, while the other way round
        Message 3 of 8 , Jul 1, 2002
        • 0 Attachment
          > 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.

          That is caused by the different X servers, if I redirect the display from
          a Sparc VM to a linux box, I also get these boxes, while the other way
          round (Linux VM, Sun's X server) everything looks fine.
          Don't know what would be the best place to handle the difference.

          > 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
          > self4.1.5/glue/xlib_glue.cpp
          > 547c547
          > < strncpy(buffer, result, size);
          > ---
          > > strncat(buffer, result, size);
          >
          This is IMHO a bug in Sun's code that showed up only under linux (probably
          due to different malloc implementations). The context of this line is:
          buffer = (char*) malloc(size + 1);
          strncpy(buffer, result, size);
          buffer[size] = '\0';
          The original strncat appends result to the newly allocated buffer after the
          first '\0', depending on the contents of the malloc'd buffer this may
          overwrite arbitrary memory. strncpy just copies the result in the right
          place. Since the original code works on Solaris, I assume their malloc will
          at least clear the first byte of the returned memory.

          Harald
        • Jecel Assumpcao Jr
          ... I should have done this test too, but this was what I expected. BTW, I was wrong about the unknown font: arialBold thing - it also happens in Linux
          Message 4 of 8 , Jul 2, 2002
          • 0 Attachment
            On Monday 01 July 2002 18:02, Harald Gliebe wrote:
            > That is caused by the different X servers, if I redirect the display
            > from a Sparc VM to a linux box, I also get these boxes, while the
            > other way round (Linux VM, Sun's X server) everything looks fine.

            I should have done this test too, but this was what I expected. BTW, I
            was wrong about the "unknown font: arialBold" thing - it also happens
            in Linux whenever I open an evaluator.

            > Don't know what would be the best place to handle the difference.

            It is best to fix this at the Self level. The newlines shouldn't be
            there and we can make them all go away by executing

            (browse childrenOf: traits labelMorph) do: [ | :m. v |
            v: m reflectee.
            (v morphTypeName == 'labelMorph') && "skip clockMorphs and such"
            [(v label lastIfAbsent: '.') = '\n'] ifTrue: [
            v label: v label copyWithoutLast
            ]
            ]

            Of course, any new labels created in whatever way these were created
            will have the same problem so that code should be fixed as well.

            > > [ strncpy and strncat ]
            >
            > This is IMHO a bug in Sun's code that showed up only under linux
            > (probably due to different malloc implementations). The context of
            > this line is: buffer = (char*) malloc(size + 1);
            > strncpy(buffer, result, size);
            > buffer[size] = '\0';
            > The original strncat appends result to the newly allocated buffer
            > after the first '\0', depending on the contents of the malloc'd
            > buffer this may overwrite arbitrary memory. strncpy just copies the
            > result in the right place. Since the original code works on Solaris,
            > I assume their malloc will at least clear the first byte of the
            > returned memory.

            You are probably right.

            -- Jecel
          • Harald Gliebe
            Jecel Assumpcao wrote: ... Thanks, that was easier than I expected. Harald
            Message 5 of 8 , Jul 2, 2002
            • 0 Attachment
              Jecel Assumpcao wrote:
              ...
              > (browse childrenOf: traits labelMorph) do: [ | :m. v |
              > v: m reflectee.
              > (v morphTypeName == 'labelMorph') && "skip clockMorphs and such"
              > [(v label lastIfAbsent: '.') = '\n'] ifTrue: [
              > v label: v label copyWithoutLast
              > ]
              > ]
              Thanks, that was easier than I expected.

              Harald
            Your message has been successfully submitted and would be delivered to recipients shortly.