2010/3/15 Chris Muller <asqueaker at gmail.com>:
> My sense is that StandardFileStream>>#readInto:startingAt:count: was
> supposed to provide (outside) access to the primitive method,
> #primRead:into:startingAt:count.  Now we don't have access to that
> primitive at all without doing a bunch of other stuff.  So I'm
> hard-pressed to believe this is really going to perform better...
>

Because all file stream are now buffered, you cannot access the
primitive directly.
The logical stream pointer (in the buffer) is not the file pointer.
In my XTream experiment I clearly dissociate buffered input from non
buffered, so you would have choice, but we cannot replace ugly huge
Stream hierarchy like that.

>
>
> On Mon, Mar 15, 2010 at 10:02 AM, Chris Muller <asqueaker at gmail.com> wrote:
>> The method, as stated by its comment, is supposed to answer the number
>> of bytes actually transferred from the file-system.  In fact, it
>> answers the size of the String input into the method.
>>
>> Magma won't even come close to running in the trunk image with this
>> problem.  StandardFileStream>>#readInto:startingAt:count: is breaking
>> its contract.
>>

I thought I did fix it In my image I have:
^(self next: count into: byteArray startingAt: startIndex) size - startIndex + 1

and next:into:startingAt: just return a copy truncated to last byte
read, so it relates to size read.
This stupid API was here before us, so we are just maintaining compatibility...
If it would be just me, no doubt code would be different (can't speak
for Levente, but I guess same for him).

>> Nicolas and/or Levente, can you help?  These recent changes you made
>> appear to be an optimization of FileStream?
>>
>> Thanks,
>>  Chris
>>
>
>