On Sun, May 29, 2011 at 9:07 PM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:

At Sun, 29 May 2011 20:52:45 +0200,

Mariano Martinez Peck wrote:
>
> On Sun, May 29, 2011 at 8:45 PM, Yoshiki Ohshima <yoshiki@vpri.org> wrote:
>
> � � At Sat, 28 May 2011 09:33:27 +0200,
> � � St�phane Ducasse wrote:
> � � >
> � � > Yoshiki
> � � >
> � � > if you want to help testing, improving fuel you are welcome.
> � � > The idea is to make it fast fast fast without vm support.
>
> � � �Yeah. �The reason for example I went to pad data to 4 bytes
>
> What do you mean by padding data to 4 bytes?� I don't understand :(

�Say a string has length of 5 ('abcde'), the data in file for it
would be "97 98 99 100 101 0 0 0".

Sorry but I don't understand then how that is related to "The reason for example I went to pad data to 4 bytes was that
there may be a clever trick I may be able to do to read data into
arrays "directly" and stuff, but did not get around implementing it."
�

> � � was that
> � � there may be a clever trick I may be able to do to read data into
> � � arrays "directly" and stuff,
>
> what do you mean by that?� like ImageSegment does?� I mean, include also object headers in the stream and then avoid to recreate objects (using #basicNew) ?

�Not like ImageSegment, but more like #hackBits: reading from file
into a string object of right size.

I am not sure if I understand. For some kind of objects (those that are variable) we� store first its size and then at materialization time we directly create an object of that size using #basicNew:

but I guess you are talking about something else.

�

�For pointer arrays and actual
literal fields, I am not sure I can apply this however.

�I would not put object headers, as you would agree^^;

-- Yoshiki