www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - obsolete D libraries/modules

reply "Ramon" <spam thanks.no> writes:
Apologies if this is the wrong forum or even the wrong place but 
it seems to me there is a kind of tight connection between dlang 
and dsource.org (to which the following relates).

I can perfectly well understand that any group around a not yet 
globally known language with a not yet richly endowed assortment 
of libraries isn't eager to push the kill button on 3rd 
party/user created modules.

And yes, it sure gives a new user a warm nice feeling to discover 
lots of available modules (which after all translates to a quick 
start and efficiency for many taskS).

Let me, however, also share my experience and feelings as a 
(exited and pleased) newbie to D when one finds out that what 
seems to be easily 2/3rd of seemingly available modules are 
"dead, exitus, this bird is passed away, gone, dead, and only 
sitting there because someone drove a nail through the poor 
animal" or, at best optimistically pre-early-alpha (speaking with 
a friendly grin).

Feels like a 16 ton weight coming down (if I may borrow again 
from Python, here).

And there is another unpleasant side effect: It doesn't feel 
profoundly attractive to write something and put it in between 
all those dead parrots.

I'd like to suggest therefore that we begin to mildly weed out 
dead or stuck-in-dream stage modules or at least discreetly mark 
them as RIP.

In case someone is interested in what disappointed me most, it's 
hto2 and bcd-gen, bot of which address an important need and both 
of which don't look healthy and useful.
This is particularly troublesome as "make C libs work in D" type 
tools are essential in any effort to bring D forward in the world 
out there.

In case someone feels like hitting me: Hold it. This thread was 
written with good intention and the honest worry that a lack of 
libs and a lack of some support for bringing in C stuff might 
turn out to be regrettable bumps in the road.

A+ -R
Aug 28 2013
next sibling parent reply "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 29 August 2013 at 01:13:15 UTC, Ramon wrote:
 Apologies if this is the wrong forum or even the wrong place 
 but it seems to me there is a kind of tight connection between 
 dlang and dsource.org (to which the following relates).

 I can perfectly well understand that any group around a not yet 
 globally known language with a not yet richly endowed 
 assortment of libraries isn't eager to push the kill button on 
 3rd party/user created modules.

 And yes, it sure gives a new user a warm nice feeling to 
 discover lots of available modules (which after all translates 
 to a quick start and efficiency for many taskS).

 Let me, however, also share my experience and feelings as a 
 (exited and pleased) newbie to D when one finds out that what 
 seems to be easily 2/3rd of seemingly available modules are 
 "dead, exitus, this bird is passed away, gone, dead, and only 
 sitting there because someone drove a nail through the poor 
 animal" or, at best optimistically pre-early-alpha (speaking 
 with a friendly grin).

 Feels like a 16 ton weight coming down (if I may borrow again 
 from Python, here).

 And there is another unpleasant side effect: It doesn't feel 
 profoundly attractive to write something and put it in between 
 all those dead parrots.

 I'd like to suggest therefore that we begin to mildly weed out 
 dead or stuck-in-dream stage modules or at least discreetly 
 mark them as RIP.

 In case someone is interested in what disappointed me most, 
 it's hto2 and bcd-gen, bot of which address an important need 
 and both of which don't look healthy and useful.
 This is particularly troublesome as "make C libs work in D" 
 type tools are essential in any effort to bring D forward in 
 the world out there.

 In case someone feels like hitting me: Hold it. This thread was 
 written with good intention and the honest worry that a lack of 
 libs and a lack of some support for bringing in C stuff might 
 turn out to be regrettable bumps in the road.

 A+ -R

I agree we do need to deal with older projects. However I don't think we can. Instead maybe we should work towards keeping the wiki up to date with notable projects? With regards to c libraries maybe it would be a good idea to implement a shared library function loader for phobos itself. That would mean both shared libraries and static libraries are very easy to implement. There is e.g. DerelictUtil[0] which provides it if you want it however. With regards to making a converter for between C/D bindings. There is SWIG but I have yet to get that to work well either. Maybe someone else can elaborate more on this side of things. 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]. There is also a few tools missing here and there. For example the conversion of binary assets to D arrays [2]. Works, but not the best. I know I'm advertising some of my own projects here but I think it's relevant to point out my own experience. Another area that does need some work is database connectivity. I did make some bindings to OpenDBX[3]. Which I need to redo as of Derelict3 being split up. I might get that into DUB if somebody wants it. OpenDBX[4] has multiple database interfaces using a common api. We do have sqlite bindings in Phobos however and sqlite itself bundled with dmd (not zip on Windows I believe however). On that note DUB[5] is becoming quite "community official" build manager. These packages _should_ all be up to date however we may need to focus on that? Somebody else should suggest regarding this as I haven't got experience on it yet. This may solve the issue you mentioned with dsource. [0] https://github.com/DerelictOrg/DerelictUtil [1] https://github.com/rikkimax/DOOGLE [2] https://bitbucket.org/alphaglosined/misc-work/src/cf15ec6b1e3cf888885128b8ea5c5ce4a07f446f/Tools/Bin2D.d?at=default [3] https://github.com/rikkimax/Derelict3-Extras/tree/master/import/derelict/opendbx [4] http://www.linuxnetworks.de/doc/index.php/OpenDBX/Support [5] http://code.dlang.org/
Aug 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-08-29 08:11, Rikki Cattermole wrote:

 With regards to c libraries maybe it would be a good idea to implement a
 shared library function loader for phobos itself. That would mean both
 shared libraries and static libraries are very easy to implement.
 There is e.g. DerelictUtil[0] which provides it if you want it however.

The runtime already has functions for that, although not as good as Derelict and currently only for Windows.
 With regards to making a converter for between C/D bindings. There is
 SWIG but I have yet to get that to work well either.
 Maybe someone else can elaborate more on this side of things.

And DStep: https://github.com/jacob-carlborg/dstep
 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].

There's DWT: https://github.com/d-widget-toolkit/dwt You probably want to have a look at this recent thread as well: http://forum.dlang.org/thread/phnwyavzohoptdftqfxm forum.dlang.org -- /Jacob Carlborg
Aug 29 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
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. :-) Peter
Aug 28 2013
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Thursday, 29 August 2013 at 06:34:23 UTC, 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. :-) Peter

Nice :) Although be careful it was designed for more Posix environment. I'm keeping DOOGLE as far limited in terms of platform dependence. So porting is literally implement the OpenGL context creation and Window creation classes. Also for anyone interested I'm keeping the controls that require text out of DOOGLE because of the font rasterizer dependency.
Aug 28 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-29 03:13, Ramon wrote:
 Apologies if this is the wrong forum or even the wrong place but it
 seems to me there is a kind of tight connection between dlang and
 dsource.org (to which the following relates).

 I can perfectly well understand that any group around a not yet globally
 known language with a not yet richly endowed assortment of libraries
 isn't eager to push the kill button on 3rd party/user created modules.

 And yes, it sure gives a new user a warm nice feeling to discover lots
 of available modules (which after all translates to a quick start and
 efficiency for many taskS).

 Let me, however, also share my experience and feelings as a (exited and
 pleased) newbie to D when one finds out that what seems to be easily
 2/3rd of seemingly available modules are "dead, exitus, this bird is
 passed away, gone, dead, and only sitting there because someone drove a
 nail through the poor animal" or, at best optimistically pre-early-alpha
 (speaking with a friendly grin).

 Feels like a 16 ton weight coming down (if I may borrow again from
 Python, here).

Well, dsource.org is dead. The projects are basically there for reference only. Most project these days are at Github. I guess there isn't an obvious way to find all of them though.
 And there is another unpleasant side effect: It doesn't feel profoundly
 attractive to write something and put it in between all those dead parrots.

 I'd like to suggest therefore that we begin to mildly weed out dead or
 stuck-in-dream stage modules or at least discreetly mark them as RIP.

 In case someone is interested in what disappointed me most, it's hto2
 and bcd-gen, bot of which address an important need and both of which
 don't look healthy and useful.
 This is particularly troublesome as "make C libs work in D" type tools
 are essential in any effort to bring D forward in the world out there.

 In case someone feels like hitting me: Hold it. This thread was written
 with good intention and the honest worry that a lack of libs and a lack
 of some support for bringing in C stuff might turn out to be regrettable
 bumps in the road.

DStep is a a tool for automatically converting C headers to D modules: https://github.com/jacob-carlborg/dstep There's also a Github organization dedicated to C bindings, created by the D community and language authors: https://github.com/D-Programming-Deimos/ http://jkm.github.io/d-programming-language.org/deimos.html -- /Jacob Carlborg
Aug 29 2013
next sibling parent reply Marek Janukowicz <marek janukowicz.net> writes:
Jacob Carlborg wrote:
 Well, dsource.org is dead.

How would one know? I certainly didn't when as a complete D newbie I tried to find some libraries a few months ago.
 The projects are basically there for
 reference only. Most project these days are at Github. I guess there
 isn't an obvious way to find all of them though.

I'd say that's a pity and there should be some way to find them :) -- Marek Janukowicz
Aug 29 2013
next sibling parent Mike Parker <aldacron gmail.com> writes:
On 8/29/2013 4:29 PM, Marek Janukowicz wrote:
 Jacob Carlborg wrote:
 Well, dsource.org is dead.

How would one know? I certainly didn't when as a complete D newbie I tried to find some libraries a few months ago.

Not much anyone can do about it. The guy who maintained DSource has been inactive in the community for a long while.
Aug 29 2013
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 8/29/2013 4:29 PM, Marek Janukowicz wrote:
 Jacob Carlborg wrote:
 Well, dsource.org is dead.

How would one know? I certainly didn't when as a complete D newbie I tried to find some libraries a few months ago.
 The projects are basically there for
 reference only. Most project these days are at Github. I guess there
 isn't an obvious way to find all of them though.

I'd say that's a pity and there should be some way to find them :)

inactive in the community for a long while.
Aug 29 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-29 20:50, Ramon wrote:

 Maybe I'm simply mistaken but my impression so far is: There once were 2
 rt libraries, phobos and tango and (for whatever reason, no judgement
 implied) phobos won and today with D2 it's D + phobos, period.

In short: Tango for D2 is just another third party library. If I recall correctly basically the only major usage of Tango in DStep is the arguments parser. I'm practical, if something is missing, not working or not working good enough in Phobos I don't hesitate to use other libraries. -- /Jacob Carlborg
Aug 29 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-29 21:36, Ramon wrote:

 Being as was, hase come to be and is, some cleaning might be desirable.
 Frankly, the only reason I didn't just click away Dstep is because it's
 *so* bloody important. Otherwise seeing "tango" somewhere makes me click
 away.
 OTOH binding C libraries being so bloody vital for D I feel we should a)
 "port" Dstep to phobos and b) advertise prominently, happily and loudly.

It's a shame that people here think of Tango like that. I'm sincerely asking: "What's so bad about it?". Especially when most people just see "Tango" and turns a way without knowing that it is. It's just another third party library. -- /Jacob Carlborg
Aug 29 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-30 10:26, Ramon wrote:

 I understand your point and I understand that some reasonably
 (from their perspective) perceive a lack of fairness.

 My point of view, however, was that of a newbie. As such I won't
 make my learning curve steeper by learning two "standard
 libraries", which one to use when, etc.

There is just a single standard library. I don't know how many times I have to say this: "Tango is just another third party library". And as long as you don't compile DStep yourself you don't even have to know it uses Tango.
 - why tango? What's better there than in phobos?

In my opinion: * Argument parsing * XML package * Net package (not any external dependencies) * Zip package * I think it has more collections * Logging
 - what's the offering? (Is it a complete replacement for phobos?)

Yes, but you can use just what you want. As I said, I'm only using the argument parsing from Tango. -- /Jacob Carlborg
Aug 30 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-30 20:19, Ramon wrote:

 Thanks for the information and your thoughts. I'd like to ask one
 more question on that, as I happened to work a little with
 phobos' getopt and looked at your code and happened to notice
 (your use of) tangos arg parsing/handling:
 Why do you consider tangos arg parsing being better? Could you
 kindly elaborate that somewhat? (Because I, possibly due to my
 newbness, failed to see striking advantages in tangos arg parsing
 when looking at Dstep).

I think the Tango version is more flexible and has more features. With the Tango argument parser you can: * Restrict values * Specify the min and max number of arguments a given flag need to have * Aliases * Default value * Conflict handling The Phobos version accepts weird syntax's like: --t 4 -- /Jacob Carlborg
Aug 31 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/13 4:21 AM, Jacob Carlborg wrote:
 On 2013-08-30 20:19, Ramon wrote:

 Thanks for the information and your thoughts. I'd like to ask one
 more question on that, as I happened to work a little with
 phobos' getopt and looked at your code and happened to notice
 (your use of) tangos arg parsing/handling:
 Why do you consider tangos arg parsing being better? Could you
 kindly elaborate that somewhat? (Because I, possibly due to my
 newbness, failed to see striking advantages in tangos arg parsing
 when looking at Dstep).

I think the Tango version is more flexible and has more features. With the Tango argument parser you can: * Restrict values * Specify the min and max number of arguments a given flag need to have * Aliases * Default value * Conflict handling

Haven't seen Tango's arguments parser, but it's a given getopt can be improved in any number of ways. Yet the way I see it, with command line parsing, the margin between a good enough argument parser and a terrific one is razor thin. One parses arguments by definition once in every program, and things like checking against limits and constraints across multiple arguments can be easily done after basic parsing.
 The Phobos version accepts weird syntax's like:

 --t 4

Only if you tell it to! Andrei
Aug 31 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-31 19:11, Andrei Alexandrescu wrote:

 Haven't seen Tango's arguments parser, but it's a given getopt can be
 improved in any number of ways. Yet the way I see it, with command line
 parsing, the margin between a good enough argument parser and a terrific
 one is razor thin. One parses arguments by definition once in every
 program, and things like checking against limits and constraints across
 multiple arguments can be easily done after basic parsing.

I don't want this to start a huge argument about Tango versus Phobos. But Tango supports this _now_, out of the box, Phobos doesn't. No need to do any post processing. It's that simple. Again I don't understand why some people having so much trouble that some developers here are using Tango. -- /Jacob Carlborg
Aug 31 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/13 11:12 AM, Jacob Carlborg wrote:
 On 2013-08-31 19:11, Andrei Alexandrescu wrote:

 Haven't seen Tango's arguments parser, but it's a given getopt can be
 improved in any number of ways. Yet the way I see it, with command line
 parsing, the margin between a good enough argument parser and a terrific
 one is razor thin. One parses arguments by definition once in every
 program, and things like checking against limits and constraints across
 multiple arguments can be easily done after basic parsing.

I don't want this to start a huge argument about Tango versus Phobos. But Tango supports this _now_, out of the box, Phobos doesn't. No need to do any post processing. It's that simple.

I agree with the sentiment, but not with the example. It's just petty. There's no out-of-the-box vs it-could-be-built, it's just a difference without a distinction. We're talking about a few lines per application.
 Again I don't understand why some people having so much trouble that
 some developers here are using Tango.

In this case you're seeing things where they aren't. Speaking only for myself I think Tango is a fine library and I'm glad it's keeping traction in D. Andrei
Aug 31 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/31/13 4:37 PM, Peter Williams wrote:
 On 01/09/13 03:11, Andrei Alexandrescu wrote:
 Haven't seen Tango's arguments parser, but it's a given getopt can be
 improved in any number of ways. Yet the way I see it, with command line
 parsing, the margin between a good enough argument parser and a terrific
 one is razor thin. One parses arguments by definition once in every
 program, and things like checking against limits and constraints across
 multiple arguments can be easily done after basic parsing.

The Python Standard Library's argparse module <http://docs.python.org/2/library/argparse.html> would be a good model to base an improved option parsing module on. I've used it a lot in Python and it's very useful. Peter

I remember sitting next to Kirk McDonald at the D conference in 2007 as he was showing me Python's argparse. I personally found pretty much any example we could think of more verbose and uglier than std.getopt. Andrei
Aug 31 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 04:29, Jonathan M Davis wrote:

 std.getopt is definitely lacking some nice-to-have features (like automatically
 generating --help from the options), but for the most part, I don't think that
 it can be improved much without seriously complicating it. I think that it's
 about at the limit of what can be done and still have it be simple, and it
 works really well for the most part, so if we haven't hit the sweet spot,
 we're at least close. I've toyed with trying to figure out how to improve it,
 but I think that doing so cleanly would be very hard.

I don't know if you're referring to the API or the implementation. But if you're referring to the API I think something like this could be made to work: string outputFile; getopt(args, "output", &outputFile).min(2).max(4).restrict("a", "b", "c", "d"); The current API stays exactly the same, it's just extended. This assumes it's possible to call "getopt" multiple times and you setup one argument per call, unless you want the same restrictions for multiple arguments. -- /Jacob Carlborg
Sep 01 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/1/13 2:07 AM, Jacob Carlborg wrote:
 On 2013-09-01 04:29, Jonathan M Davis wrote:

 std.getopt is definitely lacking some nice-to-have features (like
 automatically
 generating --help from the options), but for the most part, I don't
 think that
 it can be improved much without seriously complicating it. I think
 that it's
 about at the limit of what can be done and still have it be simple,
 and it
 works really well for the most part, so if we haven't hit the sweet spot,
 we're at least close. I've toyed with trying to figure out how to
 improve it,
 but I think that doing so cleanly would be very hard.

I don't know if you're referring to the API or the implementation. But if you're referring to the API I think something like this could be made to work: string outputFile; getopt(args, "output", &outputFile).min(2).max(4).restrict("a", "b", "c", "d");

What would this line do? Andrei
Sep 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-01 16:28, Andrei Alexandrescu wrote:

 string outputFile;
 getopt(args, "output", &outputFile).min(2).max(4).restrict("a", "b",
 "c", "d");

What would this line do?

The "output" argument expects at least two values and at most four. The values can be "a", "b", "c" or "d". -- /Jacob Carlborg
Sep 01 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-09-01 20:10, Ramon wrote:

 Considering that a standard lib is rather close to (and by many
 considered part of) the language, there are, as in language
 design, many trade offs to be decided upon, generality and
 reliability weighing in much higher than "it can do everything
 including the kitchen sink and a colour picker".

That's why I don't use it since it doesn't fit my needs. Why should I reimplement something that is already available for me? -- /Jacob Carlborg
Sep 01 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/1/13 10:20 AM, Jacob Carlborg wrote:
 On 2013-09-01 16:28, Andrei Alexandrescu wrote:

 string outputFile;
 getopt(args, "output", &outputFile).min(2).max(4).restrict("a", "b",
 "c", "d");

What would this line do?

The "output" argument expects at least two values and at most four. The values can be "a", "b", "c" or "d".

So output should probably be a string[]. We're looking at: enforce(output.length >= 2 && output.length <= 4. "Incorrect number of outputs passed"); enforce(["a", "b", "c", "d"].any(output), "Invalid value for output"); This is a one-time work per program. Granted, error messages could be nicer so that's a couple more lines. The gain from integrating such checks would be small. Andrei
Sep 02 2013
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
02-Sep-2013 09:32, H. S. Teoh пишет:
 On Sat, Aug 31, 2013 at 07:29:42PM -0700, Jonathan M Davis wrote:
 On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
 I remember sitting next to Kirk McDonald at the D conference in 2007
 as he was showing me Python's argparse. I personally found pretty
 much any example we could think of more verbose and uglier than
 std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part, I don't think that it can be improved much without seriously complicating it. I think that it's about at the limit of what can be done and still have it be simple, and it works really well for the most part, so if we haven't hit the sweet spot, we're at least close. I've toyed with trying to figure out how to improve it, but I think that doing so cleanly would be very hard.

I've had several people complain to me about std.getopt not understanding / supporting "standard" command-line syntax. Like '-c5' vs. '-c 5'. I've also experienced some quirks in how it handles option parsing, such as being unable to distinguish between '-w' and '--water' where both are distinct options (the use case is that multiple options begin with 'w', but one is more common than the others so '-w' is desirable as a shorthand, but currently std.getopt support for this is sketchy and unreliable).

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. -- Dmitry Olshansky
Sep 02 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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. Andrei
Sep 03 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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. 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). -- Dmitry Olshansky
Sep 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 03 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-30 10:26, Ramon wrote:

 My point of view, however, was that of a newbie. As such I won't
 make my learning curve steeper by learning two "standard
 libraries", which one to use when, etc.

Oh, and BTW, if you want to code on DStep you need to learn libclang even more than you need to learn Tango. -- /Jacob Carlborg
Aug 30 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-30 07:05, H. S. Teoh wrote:

 Oh? Is that fork still alive? I've never heard of this before.

It's alive, last commit 8 days ago: https://github.com/SiegeLord/Tango-D2 -- /Jacob Carlborg
Aug 29 2013
prev sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 08/30/13 07:05, H. S. Teoh wrote:
 On Fri, Aug 30, 2013 at 06:48:33AM +0200, Jason den Dulk wrote:
 [...]
 The fight between Tango and Phobos was one that Tango was destined
 to lose. Phobos was the official library, backed by Walter, and
 Walter controlled the language.

 The Tango people eventually gave up and decided to fork their own
 language, and most of the Tango fans went with them. Tango for D was
 effectively abandoned.

Oh? Is that fork still alive? I've never heard of this before.

http://www.dsource.org/projects/tango/forums/topic/920 and it seems to be alive: https://bitbucket.org/larsivi/amber/commits artur
Aug 30 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-30 09:54, Artur Skawina wrote:

 and it seems to be alive:

 https://bitbucket.org/larsivi/amber/commits

That is not Tango. That is a completely separate language. Although is very similar to D1 and they do use Tango as their runtime and standard library. Tango for D2 is located here: https://github.com/SiegeLord/Tango-D2 -- /Jacob Carlborg
Aug 30 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-08-30 18:55, Artur Skawina wrote:

 The question was not about Tango.

Oh, my bad. -- /Jacob Carlborg
Aug 31 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 08/30/13 13:45, Jacob Carlborg wrote:
 On 2013-08-30 09:54, Artur Skawina wrote:
 
 and it seems to be alive:

 https://bitbucket.org/larsivi/amber/commits

That is not Tango. That is a completely separate language. Although is very similar to D1 and they do use Tango as their runtime and standard library.

The question was not about Tango. artur
Aug 30 2013
prev sibling next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Thu, 29 Aug 2013 03:13:11 +0200
"Ramon" <spam thanks.no> wrote:
 Apologies if this is the wrong forum or even the wrong place but 
 it seems to me there is a kind of tight connection between dlang 
 and dsource.org (to which the following relates).
 

 
 Let me, however, also share my experience and feelings as a 
 (exited and pleased) newbie to D when one finds out that what 
 seems to be easily 2/3rd of seemingly available modules are 
 "dead, exitus, this bird is passed away, gone, dead, and only 
 sitting there because someone drove a nail through the poor 
 animal" or, at best optimistically pre-early-alpha (speaking with 
 a friendly grin).
 

FWIW, most of the D community has moved from dsource to github. The things remaining on dsource are mostly going to be older things.
 
 I'd like to suggest therefore that we begin to mildly weed out 
 dead or stuck-in-dream stage modules or at least discreetly mark 
 them as RIP.
 

That's a very good point, I agree that may be a good thing to do.
Aug 29 2013
prev sibling next sibling parent "Paul Jurczak" <pauljurczak yahoo.com> writes:
On Thursday, 29 August 2013 at 06:34:23 UTC, 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. :-) Peter

In case you didn't know, there is a C++ wrapper for GTK+ called gtkmm (http://www.gtkmm.org/en/). It may be useful as an example of object oriented interface to GTK+.
Aug 29 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 29 August 2013 at 07:02:40 UTC, Jacob Carlborg wrote:
 Well, dsource.org is dead. The projects are basically there for 
 reference only. Most project these days are at Github. I guess 
 there isn't an obvious way to find all of them though.

Thanks for that information an for - even better - pointing me to something alive. I'll come back on that later in a more general way.
 DStep is a a tool for automatically converting C headers to D 
 modules:

 https://github.com/jacob-carlborg/dstep

That's really great news, thank you! But there is a (possibly very small) but, too: Tango. Maybe I'm simply mistaken but my impression so far is: There once were 2 rt libraries, phobos and tango and (for whatever reason, no judgement implied) phobos won and today with D2 it's D + phobos, period.
 There's also a Github organization dedicated to C bindings, 
 created by the D community and language authors:

 https://github.com/D-Programming-Deimos/
 http://jkm.github.io/d-programming-language.org/deimos.html

Thanks for that info.
Aug 29 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 29/08/13 09:03, Nick Sabalausky wrote:
 FWIW, most of the D community has moved from dsource to github. The
 things remaining on dsource are mostly going to be older things.

The problem for newcomers that a lot of searches wind up pointing you to dsource.org pages, and there's nothing there to tell you, "Hey, go over to dlang.org or GitHub!" At the very least I think that dlang.org ought to have a page about 3rd-party projects that notes the situation on dsource.org, and points the user to well-updated resources about currently active projects.
Aug 29 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
I'm still a newbie, which is not a pleasant but *can* be useful 
because, after all, D does not intend to be or stay a rarter 
closed insider group and a newbie might be better able to come up 
with certain, possibly stupid, issues.

So kindly allow me to share some thoughts with you.

I hear a lot about performance and sure enough that's important. 
Also very important, however, is the question of available 
libraries and of binding C libs.

If there is (and possibly DStep is) an up-to-date (workig with 
D2, phobos) a solution LET US ADVERTISE THAT and make it easy to 
find, too!
This is not some luxury like D being 7% faster than, say, Pascal. 
This is a go-or-break issue for many who have a first look at D.

I took dsource to be of relevance and learned it's not. One 
reason for that was that I was, of course, looking for existing 
modules/libraries and it seems there is not yet an "official" 
list of repositories and modules. Let's change that.

While I personally have not much of a problem with a funny 
assortment of cvs, svn, bzr, git and whatnot repositories spread 
all over the internet, some might consider that unattractive 
enough to stay away from D. Maybe we should create/have sth. like 
"the official D modules repository" where modules are sorted 
(gui, db, algo, etc. - and - D2, phobos, tango based, etc), where 
activity or last update or similar is shown, where some maturity 
indicator (like 1=concept ... 5=mature/production qual.) is shown.

Thanks for considering and discussing

A+ -R
Aug 29 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Aug 29, 2013 at 08:50:46PM +0200, Ramon wrote:
 On Thursday, 29 August 2013 at 07:02:40 UTC, Jacob Carlborg wrote:
Well, dsource.org is dead. The projects are basically there for
reference only. Most project these days are at Github. I guess
there isn't an obvious way to find all of them though.

Thanks for that information an for - even better - pointing me to something alive. I'll come back on that later in a more general way.

I wonder if we should post a notice on dlang.org to the effect that dsource.org is dead, and that people shouldn't rely on it. Right now, having no way to actually update that site to add a notice to this effect, the first thing people are going to do when they discover D is to hit the search engines and dsource.org is inevitably going to turn up. Then it's anyone's guess whether the net effect will be positive or negative -- I'm guessing negative, a bad first impression of D that it has lots of promising but dead projects. [...]
 But there is a (possibly very small) but, too: Tango.
 
 Maybe I'm simply mistaken but my impression so far is: There once
 were 2 rt libraries, phobos and tango and (for whatever reason, no
 judgement implied) phobos won and today with D2 it's D + phobos,
 period.

This is a dark part of D's history that people don't really like to talk about... but as I understand it (I wasn't around at the time), the story went something like this: back in the days of D1, the original version of Phobos sucked because Andrei hasn't come on board yet, so the D community, out of dissatisfaction with the state of Phobos at that time, revolted and wrote their own standard library called Tango. This was a problem, because back then, Phobos and druntime were one and the same thing, so Tango had to provide its own D runtime. This meant that programs compiled with Phobos can't be linked with programs compiled with Tango, and vice versa, since their respective runtimes would conflict. As a result, half of all D code was specific to Tango and the other half was specific to Phobos. One striking example was the concurrent incremental GC implemented for Tango: it was a superior GC (at the time) but only Tango users could reap the benefit. Things like this caused an unpleasant schism in the D community. Anyway, long story short, eventually the decision was made to move to D2, and by then, Andrei had come on board, and he made Phobos awesome (or so I heard). Druntime was separated out from Phobos so that alternative standard libraries like Tango could be supported while still allowing interoperatibility between code compiled with either library. Phobos became better and better, and eventually gained the support of the majority of D users. Tango isn't dead, though; the D2 port of Tango is alive and well, and available if you wish to use it instead of Phobos. But I'd say that the current recommendation for newcomers is to use Phobos, since Phobos idioms and conventions are quickly becoming synonymous with "the D way" nowadays. T -- Ruby is essentially Perl minus Wall.
Aug 29 2013
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, August 29, 2013 12:17:21 H. S. Teoh wrote:
 Druntime was separated out from Phobos so that
 alternative standard libraries like Tango could be supported while still
 allowing interoperatibility between code compiled with either library.

Actually, druntime is a fork of Tango's runtime. So, once the runtime was separated from the standard library, it's Tango's runtime which got used, not the old one that was used with D1 Phobos. But regardless, the separation of the runtime and standard library now makes it possible to swap out runtimes if you need to and still use the standard library, which wasn't possible with D1. - Jonathan M Davis
Aug 29 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 I wonder if we should post a notice on dlang.org to the effect 
 that
 dsource.org is dead, and that people shouldn't rely on it. 
 Right now,
 having no way to actually update that site to add a notice to 
 this
 effect, the first thing people are going to do when they 
 discover D is
 to hit the search engines and dsource.org is inevitably going 
 to turn
 up. Then it's anyone's guess whether the net effect will be 
 positive or
 negative -- I'm guessing negative, a bad first impression of D 
 that it
 has lots of promising but dead projects.

Yes. I, being a D newbie myself, can report that's exactly what happened. And it's particularly bad because, while a newb-newbie might happily hack along and learn D, a professional newbie has actual work to do. *of course* looking for what's available is one of the first things to do. This whole thing get's even more weight as D happend to be advertised like "use any C library to your liking".
 [...]
 But there is a (possibly very small) but, too: Tango.
 
 Maybe I'm simply mistaken but my impression so far is: There 
 once
 were 2 rt libraries, phobos and tango and (for whatever 
 reason, no
 judgement implied) phobos won and today with D2 it's D + 
 phobos,
 period.

This is a dark part of D's history that people don't really like to talk ...

Oh, I did b no means intend to dig in wounds. My point rather is: 2 "batteries included" libs is not a good thing but a bad thing because it confuses newbies. I go with phobos because it's the official thingy and because I don't see any major obstacles or bad issues. Being as was, hase come to be and is, some cleaning might be desirable. Frankly, the only reason I didn't just click away Dstep is because it's *so* bloody important. Otherwise seeing "tango" somewhere makes me click away. OTOH binding C libraries being so bloody vital for D I feel we should a) "port" Dstep to phobos and b) advertise prominently, happily and loudly. Being able to import C libs to D quite simply is vital, it's a go or break issue for many. And if Dstep is the reasonable and working way to get that done, we should put it on the front page. --- As for the modules, dsource etc., I very strongly feel that we should go the way of Python, span and others, i.e. we should build an official repository. A+ -R
Aug 29 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 29/08/13 16:44, Rikki Cattermole wrote:
 On Thursday, 29 August 2013 at 06:34:23 UTC, 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. :-) Peter

Nice :) Although be careful it was designed for more Posix environment. I'm keeping DOOGLE as far limited in terms of platform dependence. So porting is literally implement the OpenGL context creation and Window creation classes. Also for anyone interested I'm keeping the controls that require text out of DOOGLE because of the font rasterizer dependency.

I'm starting at the top and working towards the "down and dirty" bits so issues such as platform dependence haven't arisen yet. My strategy is to look at the header file for a widget and extract its public interface and then implement a D class with that interface using the widget's C source file for guidance. My thinking is that when I get to the bottom I define an abstract interface for the "down and dirty" part and then implement it for the back end of my choice leaving others to do the same for the back end of their if they can't wait for me to get around to it. Design of this interface is probably something I will need assistance from people familiar with Windows/Mac/X11/Weyland so that the interface is implementable and not biased towards one or another.
Aug 29 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 29/08/13 19:23, Paul Jurczak wrote:
 On Thursday, 29 August 2013 at 06:34:23 UTC, 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. :-) Peter

In case you didn't know, there is a C++ wrapper for GTK+ called gtkmm (http://www.gtkmm.org/en/). It may be useful as an example of object oriented interface to GTK+.

Thanks, but GTK+ IS an object oriented interface (just written C) so looking at the C++ interface would just mean more work for me with little gain.
Aug 29 2013
prev sibling next sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 On Thu, Aug 29, 2013 at 08:50:46PM +0200, Ramon wrote:

 But there is a (possibly very small) but, too: Tango.
 
 Maybe I'm simply mistaken but my impression so far is: There 
 once
 were 2 rt libraries, phobos and tango and (for whatever 
 reason, no
 judgement implied) phobos won and today with D2 it's D + 
 phobos,
 period.


The fight between Tango and Phobos was one that Tango was destined to lose. Phobos was the official library, backed by Walter, and Walter controlled the language. The Tango people eventually gave up and decided to fork their own language, and most of the Tango fans went with them. Tango for D was effectively abandoned. Tango for D was taken up by someone else and does run with the latest D2, but it is essentially a dinosaur.
 synonymous with "the D way" nowadays.

Is there an article on "the D way"? If not, maybe someone could put together a brief guide. Regards Jason
Aug 29 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 30, 2013 at 06:48:33AM +0200, Jason den Dulk wrote:
[...]
 The fight between Tango and Phobos was one that Tango was destined
 to lose. Phobos was the official library, backed by Walter, and
 Walter controlled the language.
 
 The Tango people eventually gave up and decided to fork their own
 language, and most of the Tango fans went with them. Tango for D was
 effectively abandoned.

Oh? Is that fork still alive? I've never heard of this before.
 Tango for D was taken up by someone else and does run with the
 latest D2, but it is essentially a dinosaur.
 
synonymous with "the D way" nowadays.

Is there an article on "the D way"? If not, maybe someone could put together a brief guide.

I don't know of any. I'd love to write one, but I don't feel qualified since I'm a relative newcomer to D. Probably one of the core devs would be more qualified. T -- In theory, there is no difference between theory and practice.
Aug 29 2013
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
What you have said is mostly true and is also found on the old 
wiki:
http://prowiki.org/wiki4d/wiki.cgi?StandardLib

What is wrong is druntime is Tango's runtime adopted by Phobos. 
And later adopted by Tango again which is available through:
https://github.com/SiegeLord/Tango-D2
Aug 29 2013
prev sibling next sibling parent "Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> writes:
On Friday, 30 August 2013 at 04:48:35 UTC, Jason den Dulk wrote:
 The Tango people eventually gave up and decided to fork their 
 own language, and most of the Tango fans went with them. Tango 
 for D was effectively abandoned.

I knew there'd been bad blood created and some exodus from the community, but I never knew the Tango devs had created a language fork. Is it still active?
Aug 30 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Friday, 30 August 2013 at 06:48:55 UTC, Jacob Carlborg wrote:
 On 2013-08-29 21:36, Ramon wrote:

 Being as was, hase come to be and is, some cleaning might be 
 desirable.
 Frankly, the only reason I didn't just click away Dstep is 
 because it's
 *so* bloody important. Otherwise seeing "tango" somewhere 
 makes me click
 away.
 OTOH binding C libraries being so bloody vital for D I feel we 
 should a)
 "port" Dstep to phobos and b) advertise prominently, happily 
 and loudly.

It's a shame that people here think of Tango like that. I'm sincerely asking: "What's so bad about it?". Especially when most people just see "Tango" and turns a way without knowing that it is. It's just another third party library.

I understand your point and I understand that some reasonably (from their perspective) perceive a lack of fairness. My point of view, however, was that of a newbie. As such I won't make my learning curve steeper by learning two "standard libraries", which one to use when, etc. And, you see, it's not just the lib, it's also about documentation, compatibility, the eco system. It might be helpful if you (or some tango guy) would explain - why tango? What's better there than in phobos? - what's the offering? (Is it a complete replacement for phobos?) etc. A+ -R
Aug 30 2013
prev sibling next sibling parent "Jason den Dulk" <public2 jasondendulk.com> writes:
On Friday, 30 August 2013 at 08:26:10 UTC, Ramon wrote:
 On Friday, 30 August 2013 at 06:48:55 UTC, Jacob Carlborg wrote:
 On 2013-08-29 21:36, Ramon wrote:

 Being as was, hase come to be and is, some cleaning might be 
 desirable.
 Frankly, the only reason I didn't just click away Dstep is 
 because it's
 *so* bloody important. Otherwise seeing "tango" somewhere 
 makes me click
 away.
 OTOH binding C libraries being so bloody vital for D I feel 
 we should a)
 "port" Dstep to phobos and b) advertise prominently, happily 
 and loudly.

It's a shame that people here think of Tango like that. I'm sincerely asking: "What's so bad about it?". Especially when most people just see "Tango" and turns a way without knowing that it is. It's just another third party library.


Technically, there's nothing 'bad' about Tango. Its popularity was testimony to its sophistication. It was the way they went about it, forcing people to choose between it an Phobos, that is the problem. It split the community into two factions and damaged D's reputation. Amongst D1 veterans, there is still a lingering resentment that makes Tango more than just a third party library.
 It might be helpful if you (or some tango guy) would explain
 - why tango? What's better there than in phobos?

At the time, Tango had more stuff. What I liked about it was the stream library. It was very rich and made working with input/output very straightforward. Even today Phobos's I/O leaves something to be desired. Regards
Aug 30 2013
prev sibling next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 Right now, having no way to actually update that site to add a
 notice to this effect

On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt
Aug 30 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Friday, 30 August 2013 at 11:42:00 UTC, Jacob Carlborg wrote:
 - why tango? What's better there than in phobos?

In my opinion: * Argument parsing * XML package * Net package (not any external dependencies) * Zip package * I think it has more collections * Logging
 - what's the offering? (Is it a complete replacement for 
 phobos?)

Yes, but you can use just what you want. As I said, I'm only using the argument parsing from Tango.

Thanks for the information and your thoughts. I'd like to ask one more question on that, as I happened to work a little with phobos' getopt and looked at your code and happened to notice (your use of) tangos arg parsing/handling: Why do you consider tangos arg parsing being better? Could you kindly elaborate that somewhat? (Because I, possibly due to my newbness, failed to see striking advantages in tangos arg parsing when looking at Dstep). On Friday, 30 August 2013 at 11:43:15 UTC, Jacob Carlborg wrote:
 Oh, and BTW, if you want to code on DStep you need to learn 
 libclang even more than you need to learn Tango.

libclang is a very interesting matter, anyway, and indeed one of the more reasonable ways to attack the C->D problem. On a sidenote, I also keep a very interested eye on the D frontend for llvm. Please, be assured that I have no interest whatsoever to dig in old wounds or to talk against tango which sure enough is a major piece of work. Thanks & A+ -R
Aug 30 2013
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:
 On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 Right now, having no way to actually update that site to add a
 notice to this effect

On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt

His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person.
Aug 31 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson wrote:
 On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:
 On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 Right now, having no way to actually update that site to add a
 notice to this effect

On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt

His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person.

He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R
Aug 31 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Saturday, 31 August 2013 at 19:11:25 UTC, Ramon wrote:
 On Saturday, 31 August 2013 at 18:44:52 UTC, Brad Anderson 
 wrote:
 On Friday, 30 August 2013 at 12:28:42 UTC, Wyatt wrote:
 On Thursday, 29 August 2013 at 19:18:48 UTC, H. S. Teoh wrote:
 Right now, having no way to actually update that site to add 
 a
 notice to this effect

On this point, when's the last time someone tried pinging him via email? Is the whois for the domain not current? -Wyatt

His email is supposedly brad at dsource.org. I know people have had difficulty contacting him in the past but I've never tried myself. And just to clarify, I'm not the same Brad Anderson that runs DSource (which has caused some confusion in the past). I'm pretty sure neither of us talk in the third person.

He, the dsource guy, is Brad AndersEn from Atlanta, GA, according to what little info is available. His whois email is at some company that seems to have gone away or changed name or ... dsource seems to be on a VPS at slicehost and, so it seems, just one in some more sites on that virtual host. It seems we shouldn't hold our breath to hear from Mr. Andersen, unless someone here knows him personally and is in contact with him. But then, most people looking for D arrive here at dlang anyway. I think, we should simply put some kind of marker here concering dsource being comatose. A+ -R

By reading this thread I just learn that dsource.org is "dead". And by going deeper in the wiki I found a page that replace dsource.org as an entry point to D related projects : http://wiki.dlang.org/Libraries_and_Frameworks I think this page should be more visible on dlang to show how much the community is large to the newcomers. Maybe a Dquick will have a little place near others GUI Libraries when it will be more than a protytpe. I can see that all multi-platforms ones are wrappers and others only support Windows. I am a Windows user, but I don't understand why others platforms are forgotten.
Aug 31 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/1/13, Flamaros <flamaros.xavier gmail.com> wrote:
 I am a Windows user, but I don't understand why others
 platforms are forgotten.

I think it's because win32 is the easiest to create a native library for, since the standard API functions for creating windows and widgets has been the same for many years. On OSX you probably have to interact with Objective-C code, which IIRC is hard to do from D without some extra language support (there's some pull request for it). And on Posix you basically don't have a standard API, so front-end libraries typically use GTK or Qt as the backend.
Aug 31 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Saturday, 31 August 2013 at 23:03:48 UTC, Andrej Mitrovic 
wrote:
 On 9/1/13, Flamaros <flamaros.xavier gmail.com> wrote:
 I am a Windows user, but I don't understand why others
 platforms are forgotten.

I think it's because win32 is the easiest to create a native library for, since the standard API functions for creating windows and widgets has been the same for many years. On OSX you probably have to interact with Objective-C code, which IIRC is hard to do from D without some extra language support (there's some pull request for it). And on Posix you basically don't have a standard API, so front-end libraries typically use GTK or Qt as the backend.

Yep, I know that for linux it's hard to use X11 or XCB direcly. Today linux window manager (unity, KDE) seems want migrate form gtk to QML that can interact efficiently with modern window compositors (wayland, Mir). Old GUI systems are to different on platforms that why we made the choice of doing something like QML which is based on a 3D renderer. If I am not wrong that so much hard to wrap native GUI systems in a portable way than QtWidgets is manually written to mimic native GUI.
Aug 31 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 01/09/13 03:11, Andrei Alexandrescu wrote:
 Haven't seen Tango's arguments parser, but it's a given getopt can be
 improved in any number of ways. Yet the way I see it, with command line
 parsing, the margin between a good enough argument parser and a terrific
 one is razor thin. One parses arguments by definition once in every
 program, and things like checking against limits and constraints across
 multiple arguments can be easily done after basic parsing.

The Python Standard Library's argparse module <http://docs.python.org/2/library/argparse.html> would be a good model to base an improved option parsing module on. I've used it a lot in Python and it's very useful. Peter
Aug 31 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
 I remember sitting next to Kirk McDonald at the D conference in 2007 as
 he was showing me Python's argparse. I personally found pretty much any
 example we could think of more verbose and uglier than std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part, I don't think that it can be improved much without seriously complicating it. I think that it's about at the limit of what can be done and still have it be simple, and it works really well for the most part, so if we haven't hit the sweet spot, we're at least close. I've toyed with trying to figure out how to improve it, but I think that doing so cleanly would be very hard. The main thing that I'd really like to see changed is the exception types that it throws, because I'd very much like to be able to have code which can give specific information about how the flags were incorrectly used and whatnot, and ConvException (which is usually what you get) doesn't cut it for that. You'd need getopt-specific exceptions for that. But we can fix that without changing the API. It's just that doing so would likely break code which was catching ConvException explicitly, so if we do that, we might be forced to introduce getOpt to replace getopt or something like that. But even if we did that, the basic design wouldn't change, just what it's throwing on failure. - Jonathan M Davis
Aug 31 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
On 01/09/13 12:29, Jonathan M Davis wrote:
 On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
 I remember sitting next to Kirk McDonald at the D conference in 2007 as
 he was showing me Python's argparse. I personally found pretty much any
 example we could think of more verbose and uglier than std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part,

That's the part of argparse that I miss the most. Also, its support for sub commands is excellent. I implemented a version of quilt in Python and argparse made adding sub commands a breeze once the main engine was complete. I must admit that I toyed with the idea of implementing argparse in D myself but rejected the idea when I realised that hard typing in D would make it a non trivial exercise. But I still think the basic ideas (i.e. integrated documentation, specifying how many no option arguments there can be and support for sub commands) are good. I especially like the integrated documentation as it makes code maintenance much easier when everything about an option/argument is in the one place. Peter PS before argparse I used to use getopt (C and Python) and I still haven't decided whether I like D's version better than the originals (probably yes for C and no for Python).
Aug 31 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
On Sunday, 1 September 2013 at 17:20:56 UTC, Jacob Carlborg wrote:
 On 2013-09-01 16:28, Andrei Alexandrescu wrote:

 string outputFile;
 getopt(args, "output", 
 &outputFile).min(2).max(4).restrict("a", "b",
 "c", "d");

What would this line do?

The "output" argument expects at least two values and at most four. The values can be "a", "b", "c" or "d".

Conceptionally questionable. The job of an argument parser is to parse arguments, to possibly do some comfort magic (like generating arg help) and to return info about the arguments in a sensible manner. It is *not* to do things that are not general but rather the programms job. And it is based on well established standards like having args in either short form '-' (or '/' on windoze) plus one letter or in long form '--' plus optionname and letting options have optional arguments as in '-o outfile'. Unless we want to arbitrarily (and therefore often uselessly) pick out one of the many multi option argument notations like "-x a:b=3:c=8859-15" it is - and should be - the task of the programm. phobos job shouldn't be to provide comfort and magic for any and every no matter how abstruse situation but to offer concise, clear, well defined and real world mechanisms. Considering that a standard lib is rather close to (and by many considered part of) the language, there are, as in language design, many trade offs to be decided upon, generality and reliability weighing in much higher than "it can do everything including the kitchen sink and a colour picker".
Sep 01 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Aug 31, 2013 at 07:29:42PM -0700, Jonathan M Davis wrote:
 On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
 I remember sitting next to Kirk McDonald at the D conference in 2007
 as he was showing me Python's argparse. I personally found pretty
 much any example we could think of more verbose and uglier than
 std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part, I don't think that it can be improved much without seriously complicating it. I think that it's about at the limit of what can be done and still have it be simple, and it works really well for the most part, so if we haven't hit the sweet spot, we're at least close. I've toyed with trying to figure out how to improve it, but I think that doing so cleanly would be very hard.

I've had several people complain to me about std.getopt not understanding / supporting "standard" command-line syntax. Like '-c5' vs. '-c 5'. I've also experienced some quirks in how it handles option parsing, such as being unable to distinguish between '-w' and '--water' where both are distinct options (the use case is that multiple options begin with 'w', but one is more common than the others so '-w' is desirable as a shorthand, but currently std.getopt support for this is sketchy and unreliable). I'm not sure how to address this issue, though; I assume some of the design decisions stemmed from Windows vs. Posix compatibility, which may make supporting this kind of syntax tricky to support.
 The main thing that I'd really like to see changed is the exception
 types that it throws, because I'd very much like to be able to have
 code which can give specific information about how the flags were
 incorrectly used and whatnot, and ConvException (which is usually what
 you get) doesn't cut it for that. You'd need getopt-specific
 exceptions for that. But we can fix that without changing the API.
 It's just that doing so would likely break code which was catching
 ConvException explicitly, so if we do that, we might be forced to
 introduce getOpt to replace getopt or something like that. But even if
 we did that, the basic design wouldn't change, just what it's throwing
 on failure.

Ideally, getopt should catch ConvExceptions (and whatever other exceptions that get thrown when a conversion fails, e.g., from a user-supplied delegate) and rethrow it with a better message. For example, "unable to convert 'abc' to int in option '-a'" instead of "std.exception.convException: illegal digit" or something similarly obscure, which is completely unhelpful to the end user. T -- Meat: euphemism for dead animal. -- Flora
Sep 01 2013
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, September 01, 2013 22:32:34 H. S. Teoh wrote:
 On Sat, Aug 31, 2013 at 07:29:42PM -0700, Jonathan M Davis wrote:
 On Saturday, August 31, 2013 19:18:11 Andrei Alexandrescu wrote:
 I remember sitting next to Kirk McDonald at the D conference in 2007
 as he was showing me Python's argparse. I personally found pretty
 much any example we could think of more verbose and uglier than
 std.getopt.

std.getopt is definitely lacking some nice-to-have features (like automatically generating --help from the options), but for the most part, I don't think that it can be improved much without seriously complicating it. I think that it's about at the limit of what can be done and still have it be simple, and it works really well for the most part, so if we haven't hit the sweet spot, we're at least close. I've toyed with trying to figure out how to improve it, but I think that doing so cleanly would be very hard.

I've had several people complain to me about std.getopt not understanding / supporting "standard" command-line syntax. Like '-c5' vs. '-c 5'. I've also experienced some quirks in how it handles option parsing, such as being unable to distinguish between '-w' and '--water' where both are distinct options (the use case is that multiple options begin with 'w', but one is more common than the others so '-w' is desirable as a shorthand, but currently std.getopt support for this is sketchy and unreliable). I'm not sure how to address this issue, though; I assume some of the design decisions stemmed from Windows vs. Posix compatibility, which may make supporting this kind of syntax tricky to support.

Some of its defaults are definitely wrong (e.g. bundling should be the default so that -water is identical to -w -a -t -e -r), but those are minor design flaws that could be fixed quite easily without really changing the API (though fixing some of them would change behavior enough that it would change the behavior of current code in a silent manner that might tick off some developers). If we were to have to create a new function to fix any of getopt's problems (e.g. the exception types that it throws), then I would want to fix some of getopt's defaults. If we had a nice list of getopt's quirks that should arguably be fixed, then we can look at creating a getOpt function with the improved behavior, but I think that that's very different from actually coming up with a new API, which is what would be required for some of the changes that some people want (like automatically generating --help), and that's what I think would be quite difficult to do cleanly. What we have is very close to ideal IMHO. It just needs a few tweaks.
 The main thing that I'd really like to see changed is the exception
 types that it throws, because I'd very much like to be able to have
 code which can give specific information about how the flags were
 incorrectly used and whatnot, and ConvException (which is usually what
 you get) doesn't cut it for that. You'd need getopt-specific
 exceptions for that. But we can fix that without changing the API.
 It's just that doing so would likely break code which was catching
 ConvException explicitly, so if we do that, we might be forced to
 introduce getOpt to replace getopt or something like that. But even if
 we did that, the basic design wouldn't change, just what it's throwing
 on failure.

[...] Ideally, getopt should catch ConvExceptions (and whatever other exceptions that get thrown when a conversion fails, e.g., from a user-supplied delegate) and rethrow it with a better message. For example, "unable to convert 'abc' to int in option '-a'" instead of "std.exception.convException: illegal digit" or something similarly obscure, which is completely unhelpful to the end user.

The message really isn't enough. I need to be able to programatically deal with the the error, meaning that I have to know things like exactly which flag failed. I may or may not have any interest in what the ConvException said. Having a nicer message for a GetOptException would be nice, but that would just be a bonus as far as I'm concerned. - Jonathan M Davis
Sep 01 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-09-02 07:58, Jonathan M Davis wrote:

 If we had a nice list of getopt's quirks that should arguably be fixed, then we
 can look at creating a getOpt function with the improved behavior, but I think
 that that's very different from actually coming up with a new API, which is
 what would be required for some of the changes that some people want (like
 automatically generating --help), and that's what I think would be quite
 difficult to do cleanly. What we have is very close to ideal IMHO. It just
needs
 a few tweaks.

I don't see why the API needs to be changed to support automatically generating help messages. Extended yes, but not changed. This is a simple idea: uint timeout; getopt(args, "timeout|t", &timeout).help("Set the timeout"); This interface assumes you can call "getopt" multiple times and call "getopt" once per flag. Alternatively pass in some form of options struct or similar: struct Options { string help; } auto options = Options("Set the timeout"); uint timeout; getopt(args, "timeout|t", &timeout, options); -- /Jacob Carlborg
Sep 02 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/2/13 7:16 AM, Andrej Mitrovic wrote:
 On 9/2/13, Jacob Carlborg <doob me.com> wrote:
 This is a simple idea:

 uint timeout;
 getopt(args, "timeout|t", &timeout).help("Set the timeout");

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?

Sounds great. There's a related bugzilla entry IIRC. Andrei
Sep 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/3/13 8:20 AM, Andrei Alexandrescu wrote:
 On 9/2/13 7:16 AM, Andrej Mitrovic wrote:
 On 9/2/13, Jacob Carlborg <doob me.com> wrote:
 This is a simple idea:

 uint timeout;
 getopt(args, "timeout|t", &timeout).help("Set the timeout");

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?

Sounds great. There's a related bugzilla entry IIRC. Andrei

Yep, that's the one. http://d.puremagic.com/issues/show_bug.cgi?id=3780. Thanks for looking into it, Andrej. Andrei
Sep 03 2013
parent reply Jacob Carlborg <doob me.com> writes:
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. -- /Jacob Carlborg
Sep 03 2013
parent Jacob Carlborg <doob me.com> writes:
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
Sep 03 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Sep 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/2/13, Jacob Carlborg <doob me.com> wrote:
 This is a simple idea:

 uint timeout;
 getopt(args, "timeout|t", &timeout).help("Set the timeout");

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?
Sep 02 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 02, 2013 at 04:16:30PM +0200, Andrej Mitrovic wrote:
 On 9/2/13, Jacob Carlborg <doob me.com> wrote:
 This is a simple idea:

 uint timeout;
 getopt(args, "timeout|t", &timeout).help("Set the timeout");


I don't like having to call getopt multiple times. This is D, we have delegates, we should only need to traverse args once and do whatever it is we need to do.
 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.

I like this idea. I like keeping the option definition, address, and help text all in one place. When a parse error occurs, getopt can display the help text for that particular option automatically. T -- Democracy: The triumph of popularity over principle. -- C.Bond
Sep 02 2013
prev sibling next sibling parent "Ramon" <spam thanks.no> writes:
I see strong points on both sides. Maybe it would be a good thing 
to really have two versions with the second one ("getOpts") 
getting the options in arrays (as introduced above). Like that 
the "simple" version we have now could, besides some minor 
corrections, stay like it is and not disturb existing programs 
using it. The second version would be the "bigger" one with help, 
valid ranges, eval funcs, and other goodies as identified by a 
crowd discussed wish list (and "auto help print" controlled e.g. 
by a flag).

A+ -R
Sep 02 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 02, 2013 at 09:28:37PM +0200, Ramon wrote:
 I see strong points on both sides. Maybe it would be a good thing to
 really have two versions with the second one ("getOpts") getting the
 options in arrays (as introduced above). Like that the "simple"
 version we have now could, besides some minor corrections, stay like
 it is and not disturb existing programs using it. The second version
 would be the "bigger" one with help, valid ranges, eval funcs, and
 other goodies as identified by a crowd discussed wish list (and
 "auto help print" controlled e.g. by a flag).

Actually, I think it's possible to please both sides with a single implementation. If we use what was suggested, and add an optional string parameter per option to serve as a help string, then that takes care of the auto help functionality. For checking ranges and stuff, we already support delegates passed to getopt, for example: void main(string[] args) { int size; getopt(args, "-s", (int s) { enforce(s >= 10 && s < 20); size = s; } ); } So we just need to provide a few commonly-used range-checking option parsers and we're good to go. For example, with the proposed enhancements, we could write: void main(string[] args) { enum A { Aa, Ab, Ac }; A a; int size; getopt(args, "-a", &a, "Type of data to generate", "-s", checkBounds(&size, 10, 20), "Size of input" ); } Where checkBounds (that is, std.getopt.checkBounds) is defined something like this: auto checkBounds(T)(T* targetVar, T lowerBound, T upperBound) { // Returns a delegate usable by the current version of // getopt. return (string optValue) { auto val = to!T(optValue); enforce(val >= lowerBound && val < upperBound); *targetVar = val; }; } Other similar helpers that can parse lists, arrays, etc., can be provided by std.getopt, so that user code will never have to re-implement any of this boilerplate by hand. T -- IBM = I'll Buy Microsoft!
Sep 02 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/3/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Sounds great. There's a related bugzilla entry IIRC.

There was this: http://d.puremagic.com/issues/show_bug.cgi?id=3780 And a pull: https://github.com/D-Programming-Language/phobos/pull/1030 However I think that pull request is over-reaching. We should improve getopt incrementally, where each pull adds one feature. If huge additions and rewrites are needed then a DIP should be made first, especially since the pull wanted to break code.
Sep 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/3/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 Yep, that's the one. http://d.puremagic.com/issues/show_bug.cgi?id=3780.

Another impotant note to make is that the pull for #3780 was made before UDAs were available. Now that we have them, we can make a more reliable and readable API rather than have to depend on argument position rules. For example: getopt(args, "count", &count, doc("This is the thread count"));
Sep 03 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Sep 03 2013
prev sibling next sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
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
Sep 05 2013
prev sibling parent Peter Williams <pwil3058 bigpond.net.au> writes:
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
Sep 06 2013