On 9/3/13, Jacob Carlborg <doob@me.com> wrote:
> On 2013-09-03 18:43, Andrej Mitrovic wrote:
>
>> getopt(args,
>>      "count", &count, @doc("This is the thread count"));
>
> That's a lot better, but it still needs to match the help text to the flag.

Ah, maybe @doc("count", "This is the thread count") ? Then you could inject it at any place. There's lots of playground here with UDAs.

On 2013-09-02 16:16, Andrej Mitrovic wrote:

> W.r.t. help strings, I would prefer if we could instead use:
>
> getopt(args,
>    "timeout|t", &timeout, "Set the timeout",
>    "other", &other,  // note: no comment!
>    "flag|f", &flag, "Set the flag")
>
> I think we could make getopt support this. For example:
>
> ["foo", &foo] => name, field
> ["foo", &foo, "foo text"] => name, field, #3 is a comment
> ["foo", &foo, "foo text", "bar", &bar] => #3 is a commen
> ["foo", &foo, "foo text", &bar] => #3 is a new name
>
> Essentially all getopt has to do is slice up the arguments into
> groups, where an address and the string before it begin a new group.
>
> @Andrei: What do you think?

Could we get some form of API to set a header and footer that is printed with the help text. Possible idea:

bool help;

getopt(args, "h|help", &help, @doc("Show this message and exit.");
getopt.header = "Usage foo [options]\nVersion 0.0.1\n\n";
getopt.footer = "\n\nUse the 'h' flag for help.";

Will print:

Usage foo [options]
Version 0.0.1

Options:
    -h, --help    Show this message and exit.

Use the 'h' flag for help.

-- 
/Jacob Carlborg

On 2013-09-03 21:00, Andrej Mitrovic wrote:

> Ah, maybe @doc("count", "This is the thread count") ? Then you could
> inject it at any place. There's lots of playground here with UDAs.

I don't like that idea to have to repeat the name of the flag. But maybe that's only needed if you want to place the help string anywhere.

I'm just thinking out loud here. An idea that would make it more readable. Currently this is supported:

struct Foo
{
    int bar;
}

Foo foo = { bar: 3 };

But this doesn't work:

void foo (Foo foo);

foo({ bar: 3 ));

If that worked we could possibly have an API like this:

int count;

getop(
    { name: "count", value: &bool, doc: "This is the thread count" )
);

-- 
/Jacob Carlborg

On 9/3/13 11:36 AM, Dmitry Olshansky wrote:
> 03-Sep-2013 18:44, Andrei Alexandrescu пишет:
>> On 9/2/13 9:58 AM, Dmitry Olshansky wrote:
>>> Last time I tried (about a year or so ago) I was frustrated with how
>>> rigid and strange it was.
>>> In the end I just rolled back to some hacks like to!int(args[1]) and so
>>> on. At least that was under my control.
>>
>> std.getopt implements simple and widely used command-line options. If
>> you used to!int(args[1]) that's not an option, it's a straight argument
>> that getopt will let pass through unchanged.
>>
>
> Well that bit about to!int(args[1]) was somewhat tongue in cheek, I
> can't recall the details now anyway.
>
> To sum up my experience I tried to for a few hours, it didn't quite work
> the way I wanted (nor I've found a way to tweak it through) so I dropped
> it.

If you ever hit that again, please bugzillize.

> Looking at it now I think the key feature missing is automatic
> generation of the summary of switches. std.getopt loses a lot of charm
> by not automating this part of the job (maintained by hand the summary
> would get out of sync sooner or later).

Agreed, we need to add that.


Andrei

On 29/08/13 16:34, Peter Williams wrote:
> On 29/08/13 16:11, Rikki Cattermole wrote:
>> I will say this, one thing about D that has annoyed me from the
>> beginning is the state of the gui libs. Hence why in last month I've
>> been having a real good play around with OpengGL and creating my own
>> library [1].
>
> On this topic, I started looking at porting one of my PyGTK applications
> to GtkD and found that the knowledge of PyGTK API wasn't a great deal of
> help in this endeavor.  I think the problem is Python's "duck typing"
> and dynamic typing allow for a very flexible API that is much simpler
> than GTK+'s and GtkD's is much like GTK+'s.  The problem is complicated
> by the fact that the amount of documentation is huge and it's often
> difficult to find where something is defined.
>
> Anyway, long story short, I've decided to investigate the feasibility of
> rewriting the parts of GTK+ that I like directly in D.  It's early days
> yet and the code is in a private repository on github.  I'll keep it
> private until I have some useful subset working at which time I'll make
> it public.  Of course, if I find that it's all too hard I'll just delete
> it.
>
> Early indications are that the code will be much simpler than the
> original as GTK+ implements its own OOP and GC where I'll just delegate
> that to D. :-)

Reality check :-) - this is a huge job.  So I've amended my goals a little.  New plan is to start with just replacing the gtk+/gtk component and use wrappers to gdk, pango etc.  I did think about chucking it in altogether and using GtkD but the API in there hints that the onus of managing memory is placed on the user and that just makes writing a GUI that much harder.

I'm hoping that my wrappers can be implemented in such a way that memory management is hidden inside them.

Peter

On 06/09/13 14:18, Peter Williams wrote:
> On 29/08/13 16:34, Peter Williams wrote:
>> On this topic, I started looking at porting one of my PyGTK applications
>> to GtkD and found that the knowledge of PyGTK API wasn't a great deal of
>> help in this endeavor.  I think the problem is Python's "duck typing"
>> and dynamic typing allow for a very flexible API that is much simpler
>> than GTK+'s and GtkD's is much like GTK+'s.  The problem is complicated
>> by the fact that the amount of documentation is huge and it's often
>> difficult to find where something is defined.
>>
>> Anyway, long story short, I've decided to investigate the feasibility of
>> rewriting the parts of GTK+ that I like directly in D.  It's early days
>> yet and the code is in a private repository on github.  I'll keep it
>> private until I have some useful subset working at which time I'll make
>> it public.  Of course, if I find that it's all too hard I'll just delete
>> it.
>>
>> Early indications are that the code will be much simpler than the
>> original as GTK+ implements its own OOP and GC where I'll just delegate
>> that to D. :-)
>
> Reality check :-) - this is a huge job.  So I've amended my goals a
> little.  New plan is to start with just replacing the gtk+/gtk component
> and use wrappers to gdk, pango etc.  I did think about chucking it in
> altogether and using GtkD but the API in there hints that the onus of
> managing memory is placed on the user and that just makes writing a GUI
> that much harder.
>
> I'm hoping that my wrappers can be implemented in such a way that memory
> management is hidden inside them.

One thing that's obvious with my progress so far is that a huge amount of the code in GTK+ is there to implement coding features/conveniences that come for free with D (with much simpler APIs).  I reckon that if D had been around to implement the original GTK+ the source would be an order of magnitude smaller and a lot easier to understand.

Peter