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

[Lars Tandle Kyllingstad]

On Tue, 2010-08-17 at 22:03 -0500, Andrei Alexandrescu wrote: 
> 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?


Well, for one thing, I didn't know about setbuf() until just now. :)

I still think I prefer the UnbufferedFile solution, though.  setbuf()
should be called before anything is read or written to the stream.  This
means it will be up to the user to do so, and this is easily forgotten.
Compare

        auto f = UnbufferedFile("myfile.txt");
        ...
        auto p = spawnProcess("myapp", f);

to

        auto f = File("myfile.txt");
        setbuf(f.getFP(), null);      // DON'T FORGET THIS!
        ...
        auto p = spawnProcess("myapp", f);

An alternative solution is to have the user specify whether File should
be buffered or unbuffered upon construction.  Then spawnProcess() can
check this and throw an exception if the File is buffered.

        auto f = File("myfile.txt", Buffer.none);
        ...
        auto p = spawnProcess("myapp", f);  // succeeds

You mentioned a few months ago that you were considering
replacing/complementing the stdioOpenmode string argument to File's
constructor with an enum.  Perhaps buffered-ness could also be an option
here?

        auto f = File("myfile.txt", Mode.append | Mode.noBuffer);


-Lars




On Tue, 2010-08-17 at 22:03 -0500, Andrei Alexandrescu wrote:
> 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