[Vm-dev] Fwd: Ideas for a binary format for an image acting as an extension of the Pharo image

[Dimitris Chloupis]

---------- Forwarded message ---------
From: Dimitris Chloupis <kilon.alios at gmail.com>
Date: Wed, 9 Nov 2016 at 22:27
Subject: Ideas for a binary format for an image acting as an extension of
the Pharo image
To: Any question about pharo is welcome <pharo-users at lists.pharo.org>


So now that CPPBridge at least basic are sort out I have to figure out a
binary file format

The idea here is to implement an image format which will be part of the
memory of the Pharo process but will live outside the memory of the Pharo
VM. Lets call this CPPMemory will be stored to an image file, lets call it
CPPImage, like we do with the Pharo image and will store a shared state
among all other processes (Pharo or not) that connect to this shared memory
(CPPMemory) via accessing the file (CPPImage). So basically it will act as
an extension to the Pharo image.

In the image file , objects will be stored obviously not in a byte-code
format but definitely in a byte format that will basically store the data
of this object using very basic primitives like character , integers and of
course bytes.

Obviously each object will have to have an id as a header and also its size
in bytes and the size of each of its instance variables.

There will be also a global headers for the entire file with the list of
the objects included and probably a references to other CPP images that
they will be able to interconnect with each other like lego blocks.

Thats my vague idea, but I am open to suggestions and even links to
articles and documentation about what a binary format must have to be
considered well architectured.  Obviously I dont expect perfection because
this is my first binary file format but at least I am looking for advise
for avoiding common pitfalls.

I am also wondering if Pharo VM bytecode would a good binary format for my
case
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161109/db74ce30/attachment.html>