[phobos] Removing std.stdio.File.popen()

[Andrei Alexandrescu]

I understand that, and the motivation has been thoroughly explained in 
the Unix lore. My question is, why define a separate type? Wouldn't 
creating a file and calling setbuf(null, 0) suffice?

Andrei

On 08/17/2010 01:59 AM, Lars Tandle Kyllingstad wrote:
> Basically because you want to know what you're piping to another
> process.  Say you read a file up to some point, and want to pass the
> rest of it through a pipe.  That won't work if you use File, because you
> don't know what has already been buffered, and what's left in the
> stream.
>
> I was originally using File, but after Steve pointed out the problem
> above we decided to add an UnbufferedFile type.  Hopefully, it will find
> other uses as well -- perhaps, at some point, we can even build a new
> buffered File on top of it.
>
> The current API for UnbufferedFile is here, if anyone is wondering:
>
>    http://www.kyllingen.net/code/ltk/doc/stdio.html
>
> -Lars
>
>
>
> On Mon, 2010-08-16 at 12:20 -0500, Andrei Alexandrescu wrote:
>> I also like ltk process quite a bit. One q - why the need for a special
>> type UnbufferedFile?
>>
>> Andrei
>>
>> David Simcha wrote:
>>> This looks terrific.  I've always found the old std.process to be way
>>> underpowered, especially on Windows.  Does your statement about
>>> cross-platformness imply that Windows will eventually be supported, too?
>>>
>>> On Mon, Aug 16, 2010 at 9:20 AM, Lars Tandle Kyllingstad
>>> <lars at kyllingen.net<mailto:lars at kyllingen.net>>  wrote:
>>>
>>>      On Mon, 2010-08-16 at 09:04 -0400, Adam Ruppe wrote:
>>>       >  I actually use it (which is why I duplicated your bug), but am OK
>>>      with
>>>       >  removing it, since it is easy enough to get at anyway. For a while, I
>>>       >  did a separate extern(C) for pclose anyway!
>>>       >
>>>       >  However, I don't think something being POSIX only is a good reason to
>>>       >  remove something. D should take advantages of whatever platform it is
>>>       >  on. Portability is good when you can have it, but it shouldn't be a
>>>       >  function killer alone.
>>>
>>>      Two comments:
>>>
>>>      1. I disagree with you. :)  I think that Phobos' user-visible interface
>>>      should be completely platform agnostic.  Code that depends only on
>>>      Phobos should compile and run on any platform.
>>>
>>>      2. Steve and I have been working on a new version of std.process, which
>>>      will at some point, hopefully, obviate the need for popen().  See
>>>      pipeProcess() here:
>>>
>>>       http://www.kyllingen.net/code/ltk/doc/process.html
>>>
>>>      The POSIX implementation is more or less complete, but its inclusion in
>>>      Phobos is currently being blocked by bug 3979.  Also, Steve has run into
>>>      some very tricky issues with pipes on Windows, fundamentally caused by
>>>      D's dependence on the DMC runtime.  I don't know how (or if) that is
>>>      working out.
>>>
>>>      -Lars
>>>
>>>      _______________________________________________
>>>      phobos mailing list
>>>      phobos at puremagic.com<mailto:phobos at puremagic.com>
>>>      http://lists.puremagic.com/mailman/listinfo/phobos
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> phobos mailing list
>>> phobos at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/phobos
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos