Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Lee Clagett (forum_at_[hidden])
Date: 2016-11-05 20:39:03

On Sat, 5 Nov 2016 17:15:58 +0100
Bjorn Reese <breese_at_[hidden]> wrote:

> On 11/05/2016 02:47 PM, Klemens Morgenstern wrote:
> 
> > auto c = child("foo").args("bar"). std_out(pipe).std_err(null);  
> 
> That is not the syntax I have proposed.
> 
> The core of my proposal is to keep attributes separate from arguments
> (granted, this was not explicitly mentioned before.)
> 

I'm glad you brought this up - I think Niall did as well - if you look
at the constructor documentation for `process::child` it is very bare.
And I am not sure how to easily describe how to use it. I think
maintainability is going to be difficult without a more strict contract
of expected arguments and behavior.

> You mentioned elsewhere that you modelled bp::child after thread.
> Boost.Thread handles attributes separate from arguments.
> 
> The syntax for creating attributes is less important to me, although I
> would strongly prefer a syntax where invalid attribute parameters
> results in reasonable compiler error messages (e.g. not SFINAE
> errors.)
> 
> > child antlr("java");
> > antlr("-jar", "antlr4.jar", "language.g4"); //here I'd much rather
> > have antlr("language.g4");
>
> I do not recall having imposed any constraints on how arguments are
> collected. I would fine with something like this:
> 
> argument with_jar = {"-jar", "antlr4.jar"};
> antlr(with_jar, "language.g4");

Again, I think Niall proposed something similar (callable). Also, I do
not think partial evaluation support is necessary in boost::process
- `boost::fit` (which I hope/think will be a boost lib) could partially
bind command arguments or even std::bind. The syntax would be
different, but once its a callable its much more flexible:

    auto with_jar = std::bind(child("java"), "-jar", "antlr4.jar", _1);

Now `with_jar` requires a single string argument to be invoked, and
invoking it executes the process and returns a handle to that process.

> > It's not an argument in a discussion really, it's just what I though
> > would make the most sense. I though it ain't CWD, i.e. current
> > working directory, but it's the one it's starts in, hence
> > start_dir. It's a directory not a path, because that might a path
> > to a file.  
> 
> Then initial_path() as used by Boost.Filesystem may be a better name.
> 

Lee