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.

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

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.

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.

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.

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

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

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

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

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