Ok, now that bug 3979 is out of the way, there is, as far as we know, only one thing standing in the way of finalising the design of std.process, and that is the lack of unbuffered I/O in Phobos.

std.process needs a type akin to File, but without the buffering, for handling pipes.  So I wrote a new one, which I called UnbufferedFile. There was a debate about this on this list a while ago, in which Andrei seemed to oppose the idea of having a separate type for that purpose, and instead argued that File should be changed to allow unbuffered I/O. I didn't really get a clear impression of others' opinions.  And now the recent proposal for a streaming API has been thrown into the mix. (Should pipe ends be UnbufferedTransports, perhaps?  I don't even know how std.stdio.File will relate to the streaming module.)

What do you think, folks?


-Lars

I am one waiting expectantly for your contribution.

Perhaps I think that UnbufferedTransports meets that purpose.
I think that it is necessary to define specialized Unformatter(or
ByLine?) to treat strings.

BTW, In unbuffered stream, AFAIK, the handling of the character string
is very difficult. For example, you must perform reading by 1 byte for 1
line input. This is very inefficient reading.
What do you think about this?

--
SHOO

(2011/01/04 7:14), Lars Tandle Kyllingstad wrote:
> Ok, now that bug 3979 is out of the way, there is, as far as we know, only one thing standing in the way of finalising the design of std.process, and that is the lack of unbuffered I/O in Phobos.
>
> std.process needs a type akin to File, but without the buffering, for handling pipes.  So I wrote a new one, which I called UnbufferedFile. There was a debate about this on this list a while ago, in which Andrei seemed to oppose the idea of having a separate type for that purpose, and instead argued that File should be changed to allow unbuffered I/O. I didn't really get a clear impression of others' opinions.  And now the recent proposal for a streaming API has been thrown into the mix. (Should pipe ends be UnbufferedTransports, perhaps?  I don't even know how std.stdio.File will relate to the streaming module.)
>
> What do you think, folks?
>
>
> -Lars

I know how to implement the necessary primitives, I just couldn't find the time to do it. It's not difficult - I looked up google.com/codesearch for the implementation of I/O routines such as getc(), ungetc(), fread() and saw how the FILE* maintains its buffer.

We need them anyway. Right now, iterating a stream by character is very slow because each popFront is a fgetc followed by ungetc. That is necessary because in readf you need to be able to look at a character without removing it off the stream.


Andrei

On 1/7/11 9:18 AM, SHOO wrote:
> I am one waiting expectantly for your contribution.
>
> Perhaps I think that UnbufferedTransports meets that purpose.
> I think that it is necessary to define specialized Unformatter(or
> ByLine?) to treat strings.
>
> BTW, In unbuffered stream, AFAIK, the handling of the character string
> is very difficult. For example, you must perform reading by 1 byte for 1
> line input. This is very inefficient reading.
> What do you think about this?
>
> --
> SHOO
>
> (2011/01/04 7:14), Lars Tandle Kyllingstad wrote:
>> Ok, now that bug 3979 is out of the way, there is, as far as we know, only one thing standing in the way of finalising the design of std.process, and that is the lack of unbuffered I/O in Phobos.
>>
>> std.process needs a type akin to File, but without the buffering, for handling pipes. So I wrote a new one, which I called UnbufferedFile. There was a debate about this on this list a while ago, in which Andrei seemed to oppose the idea of having a separate type for that purpose, and instead argued that File should be changed to allow unbuffered I/O. I didn't really get a clear impression of others' opinions. And now the recent proposal for a streaming API has been thrown into the mix. (Should pipe ends be UnbufferedTransports, perhaps? I don't even know how std.stdio.File will relate to the streaming module.)
>>
>> What do you think, folks?
>>
>>
>> -Lars
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos