<div dir="ltr">Joe Armstrong made this<div><a href="http://ubf.github.io/ubf/">http://ubf.github.io/ubf/</a><br></div><div><br></div><div>but i don't know how good it is or if it appropriate for your needs</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 9, 2016 at 7:42 PM, Dimitris Chloupis <span dir="ltr"><<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><br><div class="gmail_quote"><div dir="ltr">---------- Forwarded message ---------<br>From: Dimitris Chloupis <<a href="mailto:kilon.alios@gmail.com" target="_blank">kilon.alios@gmail.com</a>><br>Date: Wed, 9 Nov 2016 at 22:27<br>Subject: Ideas for a binary format for an image acting as an extension of the Pharo image<br>To: Any question about pharo is welcome <<a href="mailto:pharo-users@lists.pharo.org" target="_blank">pharo-users@lists.pharo.org</a>><br></div><br><br><div dir="ltr" class="m_4901496675018361043gmail_msg">So now that CPPBridge at least basic are sort out I have to figure out a binary file format<div class="m_4901496675018361043gmail_msg"><br class="m_4901496675018361043gmail_msg"></div><div class="m_4901496675018361043gmail_msg">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. </div><div class="m_4901496675018361043gmail_msg"><br class="m_4901496675018361043gmail_msg"></div><div class="m_4901496675018361043gmail_msg">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. </div><div class="m_4901496675018361043gmail_msg"><br class="m_4901496675018361043gmail_msg"></div><div class="m_4901496675018361043gmail_msg">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.</div><div class="m_4901496675018361043gmail_msg"><br class="m_4901496675018361043gmail_msg"></div><div class="m_4901496675018361043gmail_msg">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.</div><div class="m_4901496675018361043gmail_msg"><br class="m_4901496675018361043gmail_msg"></div><div class="m_4901496675018361043gmail_msg">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. </div></div></div><div style="white-space:pre-wrap"><br>I am also wondering if Pharo VM bytecode would a good binary format for my case </div>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Bernardo E.C.<div><br><div>Sent from a cheap desktop computer in South America.</div></div></div></div>
</div>