On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
> Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for that particular documentation.

I don't think it gives any advantage here :)

docopt looks cool, though my I'd prefer something that works other way around - automatically generates argument parsing code and help messages from aggregate that represents configuration and/or CLI API (with help of few UDA).

On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce wrote:
> On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
>> Pretty cool idea. Are you aware of that in D you can, at compile time, parse the doc string and generate a command line parser for that particular documentation.
>
> I don't think it gives any advantage here :)
>
> docopt looks cool, though my I'd prefer something that works other way around - automatically generates argument parsing code and help messages from aggregate that represents configuration and/or CLI API (with help of few UDA).
+1 I could use reviews for this PR https://github.com/D-Programming-Language/phobos/pull/2072

On Monday, 16 June 2014 at 21:21:47 UTC, Robert Schadek via Digitalmars-d-announce wrote:
> On 06/16/2014 11:11 PM, Dicebot via Digitalmars-d-announce wrote:
>> On Monday, 16 June 2014 at 06:51:41 UTC, Jacob Carlborg wrote:
>>> Pretty cool idea. Are you aware of that in D you can, at compile
>>> time, parse the doc string and generate a command line parser for
>>> that particular documentation.
>>
>> I don't think it gives any advantage here :)
>>
>> docopt looks cool, though my I'd prefer something that works other way
>> around - automatically generates argument parsing code and help
>> messages from aggregate that represents configuration and/or CLI API
>> (with help of few UDA).
> +1 I could use reviews for this PR
> https://github.com/D-Programming-Language/phobos/pull/2072

Sure, will have a look.

Though I don't see how what I propose can fit into Phobos as std.getopt, it is something for an alternative module. The way I see it, getopt will be more suitable for small simple CLI implementations and that imaginary module - for programs with huge amount of options and complicated nested commands.

Something like this:

@help("
Header used to describe this configuration option block
")
struct CLI
{
    @descr("Some optional parameter")
    Optional!int param1;

    @descr("Mandatory parameter")
    int          param2;

    struct Command
    {
        string nested_param;

        void opCall(ref A outer)
        {
            // called after parsing relevant args into this instance
        }
    }

    Command command;
}

void main(string[] args)
{
    Config config;
    parseCLI!config(args);
    // ./app --param2 42 command --nested_param yay
}

Bob Tolbert, el 15 de June a las 17:35 me escribiste:
> In order to learn D, I've worked up a port of the docopt commandline parser (original in Python http://docopt.org).
> 
> https://github.com/rwtolbert/docopt.d

THANK YOU. I love docopt!

> Since this is my first code in D, I apologize in advance for the mix if Python and C++ idioms. Since this is ported from Python, with the intention of staying compatible with future Python versions, some of that is expected, but I look for this as an chance to learn more about D.
> 
> It is also a pretty useful way to write commandline interfaces. The included example that mimics the git CLI is pretty impressive.
> 
> This is also my first submission as a dub project, so hopefully I got that right as well.
> 
> Still needs more tests ported from Python, but it does pass the entire functional test suite for the current Python version.
> 
> Regards,
> Bob

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
This is what you get,
when you mess with us.

On 16/06/14 15:31, Bob Tolbert wrote:

> While that is true, I'd argue that if you are writing an app with
> a command line that complicated, then you have your work cut out
> for you no matter what the system is you use.

It would be nice to see a simpler example of how to use the library after parsing. Most examples now just do "writeln(arguments);".

-- 
/Jacob Carlborg

On 16/06/14 23:11, Dicebot wrote:

> I don't think it gives any advantage here :)
>
> docopt looks cool, though my I'd prefer something that works other way
> around - automatically generates argument parsing code and help messages
> from aggregate that represents configuration and/or CLI API (with help
> of few UDA).

Same here. I use the argument parser in Tango [1], which I think works well. I have extended the one in Tango to support generating the help message, and some other stuff as well [2].

[1] http://siegelord.github.io/Tango-D2/tango.text.Arguments.html
[2] https://github.com/jacob-carlborg/mambo/tree/master/mambo/arguments

-- 
/Jacob Carlborg

On Tuesday, 17 June 2014 at 06:29:14 UTC, Jacob Carlborg wrote:
> On 16/06/14 15:31, Bob Tolbert wrote:
>
>> While that is true, I'd argue that if you are writing an app with
>> a command line that complicated, then you have your work cut out
>> for you no matter what the system is you use.
>
> It would be nice to see a simpler example of how to use the library after parsing. Most examples now just do "writeln(arguments);".

So I agree it would be nice to have a more real example. I am open to suggestions or working with someone that needs a CLI update.

I thought about a small version of grep or ack written in D, but not sure if that is a waste of time when there might be a more interesting need for something new or different.

Bob