<br><br><div class="gmail_quote">On Sun, Dec 13, 2009 at 5:01 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ken G. Brown wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
At 12:14 AM +0200 12/14/09, Igor Stasenko apparently wrote:<br></div><div class="im">
Not sure how this relates exactly but there has been quite a bit of work in the past re: Virtual Image 4.0 format.<br>
See:<br>
New Compiled Method Format<br>
<<a href="http://wiki.squeak.org/squeak/750" target="_blank">http://wiki.squeak.org/squeak/750</a>><br>
<br>
and:<br>
VI4 project<br>
<<a href="http://wiki.squeak.org/squeak/2119" target="_blank">http://wiki.squeak.org/squeak/2119</a>><br>
</div></blockquote>
<br>
It doesn't relate. There may be some inspiration for how to deal with source pointers but to be honest, I find Igors approach vastly more useful since it doesn't immediately add a megabyte or more to the image size (which would happen if you go to an explicit source pointer representation) but rather makes the encoding explicitly accessible.<br>
<br>
Go Igor!<br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font><br>
PS. The only person who I'd like to explicitly comment (even if only to say "that's fine") is Eliot, since he might have some additional thoughts about some of this stuff which relate to Cog.<br></blockquote>
<div><br></div><div>and I've been explicit on my blog that I don't think that the current compiled method format is bad. I still think its compactness makes sense. providing some abstraction for accessing trailers is a good thing as long as it doesn't add significant overhead, and Igor's approach respects that constraint nicely. </div>
<div><br></div><div><rant>I've been reading Codes at Work by Peter Seibel, and it's a quite brilliant book. A couple of people in the book crtiticise the OO crowd for unnecessary abstraction. KISS is really important, as in a networked world is compactness. I think it is wise to avoid unnecessary decomposition (heavy emphasis on unnecessary here; if it is necessary then by all means decompose). Arguably unnecessary decomposition are the fragments of SystemDictionary that have gone into SystemNavigation, SmalltalkImage et al (I like SystemNavigation, but SmalltalkImage seems pointless). Much better to have a well thought-out distinction such as development vs deployment than an abstraction of a function into a class. Related functions belong together in a single class. One would be insane to break out the arithmetic functions on Point (+,-,<<, >= et al) into a separate ArithmeticPoint from graphical operations such as e.g. isInRectangle:. So for me breaking out the source pointer, having a separate byte array for bytecodes etc is all quiche. Keep them compact. Likewise, SourceFilesArray and SmalltalkImage are incoherent fragments. Why not have a SystemFileManager that provides an interface to the sources files and the code to deal with renaming images etc?</rant></div>
</div><br>