On Tue, 2 Nov 2010, Bert Freudenberg wrote:

>
> On 02.11.2010, at 17:41, Levente Uzonyi wrote:
>
>> Hi,
>>
>> yesterday I added Eliot's stdio change set to the Trunk. There are some questions left to be answered:
>>
>> 1) Do we want to use CrLfFileStream?
>> Currently it has only two users in the image, but the class is "patched" so #new will return an instance of MultiByteFileStream in those cases. The change set overrides this "patch" for the stdio streams.
>
> Should use MultiByteFileStream.
>
>> 2) Read buffering: currently it's enabled for the stdio streams. For stdout and stderr it doesn't make a difference. For stdin it's a problem if these streams should be really shared. For example: if there are 10 bytes readable from stdin and you evaluate [StandardFileStream stdin next], then it will fetch all 10 bytes. If you then evaluate [MultiByteFileStream stdin next], then you'll get nothing (nil). If we want these streams to be shared like this (accessible via both
>> MultiByteFileStream and StandardFileStream), then this is a problem.
>
> Only stdout should be buffered.

This is about image level buffering, where we only have read buffering. 
I'm pretty sure these streams use the OS's default buffering scheme at the 
VM level. For example stdout is line buffered on windows.

>
>> 3) Should we set the line end convention of MultiByteFileStream for these streams? It's currently not set.
>
> IMHO, yes, set it to LF.

Why LF?


Levente

>
> - Bert -
>
>
>
>