On Sun, Dec 13, 2009 at 5:01 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Ken G. Brown wrote:
>
>> At 12:14 AM +0200 12/14/09, Igor Stasenko apparently wrote:
>> Not sure how this relates exactly but there has been quite a bit of work
>> in the past re: Virtual Image 4.0 format.
>> See:
>> New Compiled Method Format
>> <http://wiki.squeak.org/squeak/750>
>>
>> and:
>> VI4 project
>> <http://wiki.squeak.org/squeak/2119>
>>
>
> 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.
>
> Go Igor!
>
> Cheers,
>  - Andreas
>
> 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.
>

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.

<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20091215/68162ef9/attachment.htm