On Fri, 24 Mar 2006, Jim Miller wrote:

> I'm trying to find the gdc-0.18 alpha1 that was supposedly released some time ago.  Is this still available?  I'm trying to figure out the best way that I can help move gdc forward but want to start from the "latest" sources.  I've looked at the D Bugzilla site for some ideas on what I can start on.  I'm not particularly familiar with the internals of gcc so I'm not sure how much I can help in that area but I'm very willing to write documentation or help clean up libraries if someone wants to make a suggestion on where I should start.

I don't recommend working on the gdc front end.  David, the gdc guy, has been working on getting a new release ready.  The 0.18 alpha 1 release I did is available if you want to play with it, but David's release won't be based on it, so I'm not sure what value it has.  I've stopped working on it and won't be making any sort of official gdc release based off of it at this point.  Once a new gdc release is done that's caught up, then more input on it might be of value.  Anything you find wrong with the current release, based on dmd 0.140, is so far out of date that I'm not sure how useful it is.

Are you interested in working on the d compiler itself or on libraries that people use to support their applications?  IMHO, the latter is where d needs the most help.  Looking at projects like ares or mango would be good, though I haven't looked at either yet.

That help?

Later,
Brad

On 3/24/06, Brad Roberts <braddr@puremagic.com> wrote:
>
> On Fri, 24 Mar 2006, Jim Miller wrote:
>
> > I'm trying to find the gdc-0.18 alpha1 that was supposedly released some time ago.  Is this still available?  I'm trying to figure out the best
> way
> > that I can help move gdc forward but want to start from the "latest" sources.  I've looked at the D Bugzilla site for some ideas on what I
> can
> > start on.  I'm not particularly familiar with the internals of gcc so
> I'm
> > not sure how much I can help in that area but I'm very willing to write documentation or help clean up libraries if someone wants to make a suggestion on where I should start.
>
> I don't recommend working on the gdc front end.  David, the gdc guy, has been working on getting a new release ready.  The 0.18 alpha 1 release I did is available if you want to play with it, but David's release won't be based on it, so I'm not sure what value it has.  I've stopped working on it and won't be making any sort of official gdc release based off of it at this point.  Once a new gdc release is done that's caught up, then more input on it might be of value.  Anything you find wrong with the current release, based on dmd 0.140, is so far out of date that I'm not sure how useful it is.
>
> Are you interested in working on the d compiler itself or on libraries that people use to support their applications?  IMHO, the latter is where d needs the most help.  Looking at projects like ares or mango would be good, though I haven't looked at either yet.
>
> That help?
>
> Later,
> Brad
>

Thanks for the feedback, I'll hold off on doing anything with the compiler until David releases his next version.

I'm actually more interested in the supporting libraries since that's what I think will hold back acceptance of D.  I'll take a look at Ares and see what I can do.

With regards to gdc, do you know if the intent is to continue using Phobos as it is distributed by Walter or is it going to use a parallel one?  Sorry for directing these questions to you but you seem to be the one that's the most vocal with gdc.

Thanks
Jim

On Fri, 24 Mar 2006, Jim Miller wrote:
> On 3/24/06, Brad Roberts <braddr@puremagic.com> wrote:
> > On Fri, 24 Mar 2006, Jim Miller wrote:
> >
> > > I'm trying to find the gdc-0.18 alpha1 that was supposedly released some time ago.  Is this still available?  I'm trying to figure out the best
> > way
> > > that I can help move gdc forward but want to start from the "latest" sources.  I've looked at the D Bugzilla site for some ideas on what I
> > can
> > > start on.  I'm not particularly familiar with the internals of gcc so
> > I'm
> > > not sure how much I can help in that area but I'm very willing to write documentation or help clean up libraries if someone wants to make a suggestion on where I should start.
> >
> > I don't recommend working on the gdc front end.  David, the gdc guy, has been working on getting a new release ready.  The 0.18 alpha 1 release I did is available if you want to play with it, but David's release won't be based on it, so I'm not sure what value it has.  I've stopped working on it and won't be making any sort of official gdc release based off of it at this point.  Once a new gdc release is done that's caught up, then more input on it might be of value.  Anything you find wrong with the current release, based on dmd 0.140, is so far out of date that I'm not sure how useful it is.
> >
> > Are you interested in working on the d compiler itself or on libraries that people use to support their applications?  IMHO, the latter is where d needs the most help.  Looking at projects like ares or mango would be good, though I haven't looked at either yet.
> >
> > That help?
> >
> > Later,
> > Brad
> >
> 
> Thanks for the feedback, I'll hold off on doing anything with the compiler until David releases his next version.
> 
> I'm actually more interested in the supporting libraries since that's what I think will hold back acceptance of D.  I'll take a look at Ares and see what I can do.

Agreed.

> With regards to gdc, do you know if the intent is to continue using Phobos as it is distributed by Walter or is it going to use a parallel one?  Sorry for directing these questions to you but you seem to be the one that's the most vocal with gdc.

I have never talked with David about that, but I suspect that the intent of gdc is to mirror dmd except for switching out the compiler backend. Therefore, it'd stick with phobos, adding runtime support for more platforms as porting work is done for them.  The phobos that comes with gdc isn't stock phobos, there's a number of changes, primarily constrained to the runtime support (exceptions, interfaces between the runtime and compiler, etc).

Later,
Brad

In article <mailman.15.1143256971.5269.d.gnu@puremagic.com>, Brad Roberts says...
>
>platforms as porting work is done for them.  The phobos that comes with gdc isn't stock phobos, there's a number of changes, primarily constrained to the runtime support (exceptions, interfaces between the runtime and compiler, etc).
>

Since you brought it up...

When are we going to be able to stop crapola like this?

|version (GNU)
|  import std.c.unix.unix;
|else
|  import std.c.linux.linux;

<g>

Can someone explain to me again the why behind this issue anyway? Are names really that important? I mean I think it should be std.c.posix.posix, but I'll settle for either one of the others. It's way to early to start forking the 'standard' runtime lib. for D <g>

Why linux? Marketing - because this will make the most sense to the most users.

Why unix?  Because this is more widely understood than linux as a 'type' of operating system.

Why posix? Because naming issues for API's like this are the reason POSIX was created in the first place. http://en.wikipedia.org/wiki/Posix

POSIX to me really makes the most sense, but it seems to have the least support.. Why?

- Dave

On Tue, 28 Mar 2006, Dave wrote:

> In article <mailman.15.1143256971.5269.d.gnu@puremagic.com>, Brad Roberts says...
> >
> >platforms as porting work is done for them.  The phobos that comes with gdc isn't stock phobos, there's a number of changes, primarily constrained to the runtime support (exceptions, interfaces between the runtime and compiler, etc).
> >
> 
> Since you brought it up...
> 
> When are we going to be able to stop crapola like this?

Well, I didn't start the trend, as I wasn't around then. :)

> |version (GNU)
> |  import std.c.unix.unix;
> |else
> |  import std.c.linux.linux;
> 
> <g>
> 
> Can someone explain to me again the why behind this issue anyway? Are names really that important? I mean I think it should be std.c.posix.posix, but I'll settle for either one of the others. It's way to early to start forking the 'standard' runtime lib. for D <g>
> 
> Why linux? Marketing - because this will make the most sense to the most users.
> 
> Why unix?  Because this is more widely understood than linux as a 'type' of operating system.
> 
> Why posix? Because naming issues for API's like this are the reason POSIX was created in the first place. http://en.wikipedia.org/wiki/Posix
> 
> POSIX to me really makes the most sense, but it seems to have the least support.. Why?

I'd vote for 'std.c.posix'.  I don't see why there's two levels there, though I admit to not having searched for a justification.  The problem, as you pointed out, is one of recognition.  Though I'd just point to correctness over branding as a justification for using posix.  Given that D is all about presenting a unified and consistent interface and that's what posix is all about, it just seems right.

That said, I hate to think of yet another source incompatible change like this, but better now than before 1.0, which seems to be all the rage right now.

Later,
Brad

In article <Pine.LNX.4.64.0603281559270.5795@bellevue.puremagic.com>, Brad Roberts says...
>
>On Tue, 28 Mar 2006, Dave wrote:
>
>> In article <mailman.15.1143256971.5269.d.gnu@puremagic.com>, Brad Roberts says...
>> >
>> >platforms as porting work is done for them.  The phobos that comes with gdc isn't stock phobos, there's a number of changes, primarily constrained to the runtime support (exceptions, interfaces between the runtime and compiler, etc).
>> >
>> 
>> Since you brought it up...
>> 
>> When are we going to be able to stop crapola like this?
>
>Well, I didn't start the trend, as I wasn't around then. :)
>

Sorry ;)

>> |version (GNU)
>> |  import std.c.unix.unix;
>> |else
>> |  import std.c.linux.linux;
>> 
>> <g>
>> 
>> POSIX to me really makes the most sense, but it seems to have the least support.. Why?
>
>I'd vote for 'std.c.posix'.  I don't see why there's two levels there, though I admit to not having searched for a justification.  The problem, as you pointed out, is one of recognition.  Though I'd just point to correctness over branding as a justification for using posix.  Given that D is all about presenting a unified and consistent interface and that's what posix is all about, it just seems right.
>
>That said, I hate to think of yet another source incompatible change like this, but better now than before 1.0, which seems to be all the rage right now.
>

Just to throw this out - I actually don't think this will be a big issue right now with alot of source code because it's "just" the 'nix op. sys. independent stuff, as opposed to renaming something like std.stdio. As I posted before, I'm willing to do the legwork (unless I'm severly misunderestimating and run out of time) if a decision is made one way or the other, but it has to be resolved.

I'd really like to know why the GDC folks made this decision in the first place[*]. If they wanted to add stuff for things like OS X, AIX, etc. I really think they should have lived within the original DMD framework and we'd all be better off, even if 'linux' is not really the correct namespace.

[*] I still appreciate all the work on GDC of course.

>
>Later,
>Brad
>

Brad Roberts wrote:
> On Tue, 28 Mar 2006, Dave wrote:
>>
>> |version (GNU)
>> |  import std.c.unix.unix;
>> |else
>> |  import std.c.linux.linux;
>>
>> <g>
>>
>> Can someone explain to me again the why behind this issue anyway? Are names
>> really that important? I mean I think it should be std.c.posix.posix, but I'll
>> settle for either one of the others. It's way to early to start forking the
>> 'standard' runtime lib. for D <g>
>>
>> Why linux? Marketing - because this will make the most sense to the most users.
>>
>> Why unix?  Because this is more widely understood than linux as a 'type' of
>> operating system.
>>
>> Why posix? Because naming issues for API's like this are the reason POSIX was
>> created in the first place. http://en.wikipedia.org/wiki/Posix
>>
>> POSIX to me really makes the most sense, but it seems to have the least
>> support.. Why?
> 
> I'd vote for 'std.c.posix'.  I don't see why there's two levels there, though I admit to not having searched for a justification.  The problem, as you pointed out, is one of recognition.  Though I'd just point to correctness over branding as a justification for using posix.  Given that D is all about presenting a unified and consistent interface and that's what posix is all about, it just seems right.

For what it's worth, Ares already uses 'std.c.posix' as the location for POSIX headers.


Sean

Dave wrote:

> Since you brought it up...
> 
> When are we going to be able to stop crapola like this?
> 
> |version (GNU)
> |  import std.c.unix.unix;
> |else
> |  import std.c.linux.linux;
> 
> <g>

When Walter gets with the program ;-)

DMD doesn't support other platforms.

> Just to throw this out - I actually don't think this will be a big issue right
> now with alot of source code because it's "just" the 'nix op. sys. independent
> stuff, as opposed to renaming something like std.stdio. As I posted before, I'm
> willing to do the legwork (unless I'm severly misunderestimating and run out of
> time) if a decision is made one way or the other, but it has to be resolved.

It has been an issue for quite some time, actually.

The import is just half of the headache, the other
one comes from aliasing in the right module functions...

Assuming that you want "portable" D code, that is.

> I'd really like to know why the GDC folks made this decision in the first
> place[*]. If they wanted to add stuff for things like OS X, AIX, etc. I really
> think they should have lived within the original DMD framework and we'd all be
> better off, even if 'linux' is not really the correct namespace.

DMD is not open to modifications, but GDC was and is ?

Originally there was one namespace for each platform:
linux.linux, darwin.darwin, and so on and so forth...

But David then managed to get most of it autoconfigured
into unix.unix, and only certain things remain specific

--anders

Brad Roberts wrote, in response to Dave:

>> Can someone explain to me again the why behind this issue anyway? Are names
>> really that important? I mean I think it should be std.c.posix.posix, but I'll
>> settle for either one of the others. It's way to early to start forking the
>> 'standard' runtime lib. for D <g>
> 
>>Why linux? Marketing - because this will make the most sense to the most users.
>>
>>Why unix?  Because this is more widely understood than linux as a 'type' of
>>operating system.
>>
>>Why posix? Because naming issues for API's like this are the reason POSIX was
>>created in the first place. http://en.wikipedia.org/wiki/Posix
>>
>>POSIX to me really makes the most sense, but it seems to have the least
>>support.. Why?

Note that "std.c.linux" and version(linux) are both still used in GDC.
Just that "std.c.unix" and version(Unix) are now a *superset* of them...

See http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version
(where "X86_64" should probably change *again*, to X64 <sigh>)


The Windows version of DMD uses both of "Windows" and "Win32",
but GDC only uses "Unix" at the moment - and not any "Posix".
(You can still add this version yourself of course - I believe
that both Ares and Mango has done so in the past, for instrance)

I recall this thread http://dsource.org/forums/viewtopic.php?t=681


> I'd vote for 'std.c.posix'.  I don't see why there's two levels there, though I admit to not having searched for a justification.  The problem, as you pointed out, is one of recognition.  Though I'd just point to correctness over branding as a justification for using posix.  Given that D is all about presenting a unified and consistent interface and that's what posix is all about, it just seems right.

It's not really a vote, David made the std.c.unix decision _long_ ago ?
See this thread: http://www.digitalmars.com/d/archives/D/gnu/1208.html

Compared to all the other problems that D is facing, I don't think that
changing "Unix" over to "Posix" is something that is worth fighting for.

--anders