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
next sibling parent reply 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
next sibling parent reply "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
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 parent reply "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
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 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 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: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
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 :)


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 reply "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
next sibling parent reply "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
next sibling parent reply "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
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
parent reply "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
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 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 "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
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 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
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 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
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 reply "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
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 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 parent reply "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
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
next sibling parent reply "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
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 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 reply "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
next sibling parent reply "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
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 next 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
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 reply 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
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 "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 "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 parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply 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
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 "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 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 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
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 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 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




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
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




 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
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 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




 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 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.



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
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 reply 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
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




 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 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



 
 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