Hi Igor,<div><br></div><div><br></div><div><div class="gmail_quote">On Wed, Aug 19, 2009 at 6:00 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/8/20 Jecel Assumpcao Jr <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>>:<br>
<div><div></div><div class="h5">> Colin Putney wrote on Wed, 19 Aug 2009 14:25:21 -0700:<br>
>> On 19-Aug-09, at 10:15 AM, Jecel Assumpcao Jr wrote:<br>
>><br>
>> > For example, I would far prefer to<br>
>> > see Squeak move to a binary based development model (I would mention<br>
>> > Projects and Etoys here) than the current source based things we are<br>
>> > doing (trunk, bob or whatever).<br>
>><br>
>> Forgive me for seizing on a throw-away comment like this, but would<br>
>> you mind expanding on this a bit? Are you saying you prefer something<br>
>> spoonish, where CompiledMethods are passed directly from image to<br>
>> image? Something else?<br>
><br>
> Heh, I got asked about this on IRC as well. Though I had actually<br>
> started to explain this a little in the original email, I ended up<br>
> deleting it to keep on topic. With a new subject line I don't feel I<br>
> have to worry about that. Some details about this (with a few drawings)<br>
> can be found in the Chunky Squeak wiki page:<br>
><br>
> <a href="http://wiki.squeak.org/squeak/584" target="_blank">http://wiki.squeak.org/squeak/584</a><br>
><br>
> The idea is to be more like the Etoys users which can load binary<br>
> projects containing not only the code they need but also hand crafted<br>
> objects which have no source (like a drawing, some nested Morphs or even<br>
> some text). This is very simplistic compared to Spoon, and my proposal<br>
> was even more simplistic. In particular, this doesn't handle the case<br>
> where any changes to bytecodes or object format are needed.<br>
><br>
<br>
</div></div>The central question, which arising immediately is, what is the<br>
credible way(s) to reproduce such artifacts?<br>
When we having a source code, we could (re)compile it on a different<br>
system. But what you propose to do with pure binary data, a soup of<br>
objects, in respect that it is incredibly hard to understand, what<br>
bits you need and what's not, in case if you need to do clean-up ,<br>
refactor, rewrite and simply analyze what is happening.<br>
This is what making a huge difference, for instance, between<br>
applications with open source code and applications shipped in binary<br>
form - you can only report bugs, but can't realy make any suggestions<br>
about what happening.<br>
I don't think that developers of Squeak should be victims of such situation(s).<br>
</blockquote><div><br></div><div> it is possible to have your cake and eat it too. One can create a binary format that includes source and includes the meta-source for its creation. But including a binary representation allows much faster loading, loading without a compiler, and source hiding if one choses not to include the source.</div>
<div><br></div><div>There are other advantages, such as not cluttering up the changes file when one loads a package In the VW parcel system, to which I added source management, we replaced the SourceFiles with a SourceFileManager whose job was to manage the sources and changes file and an arbitrary number of source files for parcels, the binary format. In the parcel file the source pointers of compiled methods are the positions of their source in the parcel source file. When one loads a parcel the SourceFileManager adds the file to its set of managed files and assigns an index for the source file. The parcle loader then swizzles all the source pointers so that they include the source file index along with the position. So accessing the source for a method loaded form a parcel accesses that parcel's source file. We used a floating-point like format for source pointers, where the exponent was the source file index, and the mantissa was the position in the file.</div>
<div><br></div><div>We didn't create a single file format, having two separate files for binary and source, which is probably a mistake. A format with a short header, followed by source, followed by binary, followed by metasource, would be easier to manage than three separate files.</div>
<div><br></div><div>We didn't include any metasource, but we did include pre-read, load and unload actions. I did a very bad job on version numbering and prerequisite selection.</div><div><br></div><div>That's not the whole story but enough to start answering your question. If there is a well-defined definition of the objects in a package and that definition is included in the package as metasource, then one can comprehend the binary package's contents by examining the metasource and can reproduce creating the package, provided that the tools are careful to impose ordering, etc.</div>
<div><br></div><div>best</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
> -- Jecel<br>
><br>
<font color="#888888"><br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div><br></div>