Re: obsolete D libraries/modules

[Peter Williams]

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

Re: obsolete D libraries/modules

[Peter Williams]

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

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/3/13, Jacob Carlborg  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.

Re: obsolete D libraries/modules

[Jacob Carlborg]

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


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


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


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


struct Foo
{
int bar;
}

Foo foo = { bar: 3 };

But this doesn't work:

void foo (Foo foo);

foo({ bar: 3 ));

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

int count;

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

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Jacob Carlborg]

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, --helpShow this message and exit.

Use the 'h' flag for help.

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Dmitry Olshansky]

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

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/3/13, Andrei Alexandrescu  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"));

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/3/13, Andrei Alexandrescu  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.

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

On 9/2/13 7:16 AM, Andrej Mitrovic wrote:

On 9/2/13, Jacob Carlborg  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

Re: obsolete D libraries/modules

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


Andrei

Re: obsolete D libraries/modules

[H. S. Teoh]

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!

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Dmitry Olshansky]

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

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[H. S. Teoh]

On Mon, Sep 02, 2013 at 04:16:30PM +0200, Andrej Mitrovic wrote:
> On 9/2/13, Jacob Carlborg  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

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/2/13, Jacob Carlborg  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?

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jonathan M Davis]

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

Re: obsolete D libraries/modules

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

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Peter Williams]

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

Re: obsolete D libraries/modules

[Jonathan M Davis]

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

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Peter Williams]

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

Re: obsolete D libraries/modules

[Flamaros]

On Saturday, 31 August 2013 at 23:03:48 UTC, Andrej Mitrovic 
wrote:

On 9/1/13, Flamaros  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.

Re: obsolete D libraries/modules

[Andrej Mitrovic]

On 9/1/13, Flamaros  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.

Re: obsolete D libraries/modules

[Flamaros]

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.

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Brad Anderson]

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.

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Andrei Alexandrescu]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

On 2013-08-30 18:55, Artur Skawina wrote:


The question was not about Tango.


Oh, my bad.

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Artur Skawina]

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

Re: obsolete D libraries/modules

[Wyatt]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jason den Dulk]

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

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Joseph Rushton Wakeling]

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?

Re: obsolete D libraries/modules

[Artur Skawina]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Jesse Phillips]

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

Re: obsolete D libraries/modules

[H. S. Teoh]

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.

Re: obsolete D libraries/modules

[Jason den Dulk]

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

Re: obsolete D libraries/modules

[Peter Williams]

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.

Re: obsolete D libraries/modules

[Peter Williams]

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.

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Jonathan M Davis]

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

Re: obsolete D libraries/modules

[H. S. Teoh]

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.

Re: obsolete D libraries/modules

[Ramon]

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

Re: obsolete D libraries/modules

[Joseph Rushton Wakeling]

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.

Re: obsolete D libraries/modules

[Ramon]

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.

Re: obsolete D libraries/modules

[Paul Jurczak]

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

Re: obsolete D libraries/modules

[Mike Parker]

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.

Re: obsolete D libraries/modules

[Mike Parker]

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.

Re: obsolete D libraries/modules

[Marek Janukowicz]

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

Re: obsolete D libraries/modules

[Jacob Carlborg]

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/phnwyavzohoptdftq...@forum.dlang.org

--
/Jacob Carlborg

Re: obsolete D libraries/modules

[Nick Sabalausky]

On Thu, 29 Aug 2013 03:13:11 +0200
"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).
> 
[...]
> 
> 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.

Re: obsolete D libraries/modules

[Jacob Carlborg]

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

Re: obsolete D libraries/modules

[Rikki Cattermole]

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.

Re: obsolete D libraries/modules

[Peter Williams]

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

Re: obsolete D libraries/modules

[Rikki Cattermole]

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

obsolete D libraries/modules

[Ramon]

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