In article <4453BB28.40105@codu.org>, Gregor Richards says...
>> I don't see anything wrong with us releasing a gdc 0.18 anyway ?
>
>Well, I've e-mailed him, hope to get a response one way or the other.
>
>  - Gregor Richards
I would like to offer you guys a solution: allow me to import the gdc 0.17 into svn at www.gnu-d.org.  All of you can then have svn access to commit a 0.18 branch; you can keep that in development and schedule it for release.  At that point, together you can decide when to merge everything back into the main tree (perhaps after all of you have tried to contact David and get a response as to whether he has any patches or not).

Once you get 0.18 ready between yourselves, please let me know, and I will post it on the www.gnu-d.org website.  I will also go about setting up a download for sourceforge.org.

I think we'd all like to see David come back to this project, but I think we need to organize and centralize this until he gets back.

Salud!
Gabe

Gabe McArthur wrote:
> In article <4453BB28.40105@codu.org>, Gregor Richards says...
> 
>>>I don't see anything wrong with us releasing a gdc 0.18 anyway ?
>>
>>Well, I've e-mailed him, hope to get a response one way or the other.
>>
>> - Gregor Richards
> 
> I would like to offer you guys a solution: allow me to import the gdc 0.17 into
> svn at www.gnu-d.org.  All of you can then have svn access to commit a 0.18
> branch; you can keep that in development and schedule it for release.  At that
> point, together you can decide when to merge everything back into the main tree
> (perhaps after all of you have tried to contact David and get a response as to
> whether he has any patches or not).
> 
> Once you get 0.18 ready between yourselves, please let me know, and I will post
> it on the www.gnu-d.org website.  I will also go about setting up a download for
> sourceforge.org.
> 
> I think we'd all like to see David come back to this project, but I think we
> need to organize and centralize this until he gets back.
> 
> Salud!
> Gabe
> 
> 

I'd like to wait a day or so to see if he responds to my email.  If not, this would be a great solution - it definitely needs a centralized repository.

 - Gregor Richards

Gabe McArthur wrote:

> Once you get 0.18 ready between yourselves, please let me know, and I will post
> it on the www.gnu-d.org website.  I will also go about setting up a download for
> sourceforge.org.

If you do get in contact with David Friedman, there's
http://sourceforge.net/projects/dgcc/ already set up.

--anders

Gregor Richards wrote:

> Though I don't like that the version numbering scheme of GDC has no connection to the DMD frontend it uses ... guess that's just me :)

No, but in the past there's been a *lot* more to GDC updates than just
the DMD updates which have been more like a side effect when upgrading
:-)

I mean amazing things like rewriting the entire GC, or upgrading from
GCC 3.x to 4.x, and so on. There was even 64-bit support in the works.


The downside is that the D *language* has changed a lot between DMD releases, so when it says "requires DMD 0.150" you don't really know which GDC version to get unless you skim through the changelogs...

> The reason I was organizing it like this is it keeps the middle IR-code stuff separate from the frontend stuff, but since that's not how it's compiled I guess that's not really a good choice X-P

I know, but for now I think it's easier to keep it as it is used ?

--anders

> The downside is that the D *language* has changed a lot between DMD releases, so when it says "requires DMD 0.150" you don't really know which GDC version to get unless you skim through the changelogs...

That should have read before downloading, as you can view it by "gdmd":

"gdc (GCC) 3.3.6 (gdc 0.17, using dmd 0.140)"

"gdc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)"

--anders

Gregor Richards wrote:

>> Will run some diffs and then try to compile this for the Mac.
> 
> That'd be awesome.

Ran into some kind of error with "gcc/d/dmd/expression.c":
{standard input}:26:FATAL:Symbol __ZN10IntegerExp1tE already defined.

# echo __ZN10IntegerExp1tE | c++filt
IntegerExp::t

And the root of the error seems to be the "integer_t" type:

In file included from /usr/include/mach/machine/vm_types.h:27,
                 from /usr/include/mach/vm_statistics.h:63,
                 from /usr/include/mach/host_info.h:62,
                 from /usr/include/mach/mach_types.h:66,
                 from /usr/include/pthread.h:66,
                 from /usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/gthr-default.h:37,
                 from /usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/gthr.h:98,
                 from /usr/include/gcc/darwin/3.3/c++/ppc-darwin/bits/c++io.h:37,
                 from /usr/include/gcc/darwin/3.3/c++/bits/fpos.h:44,
                 from /usr/include/gcc/darwin/3.3/c++/iosfwd:49,
                 from /usr/include/gcc/darwin/3.3/c++/ios:44,
                 from /usr/include/gcc/darwin/3.3/c++/istream:44,
                 from /usr/include/gcc/darwin/3.3/c++/sstream:44,
                 from /usr/include/gcc/darwin/3.3/c++/complex:51,
                 from /usr/include/gcc/darwin/3.3/c++/backward/complex.h:32,
                 from ../../gcc/d/dmd/expression.c:23:
/usr/include/mach/ppc/vm_types.h:86: error: conflicting types for `typedef int integer_t'
../../gcc/d/dmd/mars.h:146: error: previous declaration as `typedef long long unsigned int integer_t'


--anders

> Ran into some kind of error with "gcc/d/dmd/expression.c":
> {standard input}:26:FATAL:Symbol __ZN10IntegerExp1tE already defined.

Looks like it was a botched macro integration from upstream...

Will bugreport the "mars.h" header file from DMD to Bugzilla,
but here's the trivial patch needed for the gdc-Ego snapshot:

--- gcc/d/dmd/mars.h.orig    Sat Apr 29 04:56:03 2006
+++ gcc/d/dmd/mars.h Sun Apr 30 00:45:13 2006
@@ -131,7 +131,6 @@

 #ifdef __DMC__
 typedef _Complex long double complex_t;
-#elif IN_GCC
 #else
 #ifndef IN_GCC
 #include "complex_t.h"

It wasn't defining the "integer_t" type properly on __APPLE__
(integer_t is a system type, so it uses dmd_integer_t instead)

--anders

Gregor Richards wrote:

>> You didn't say if you had been merging with what Brad did for
>> "gdc-0.18-alpha1", so I will initially assume that you didn't.
> 
> That would be the wrong assumption, actually I did :)
[...]
>> Will run some diffs and then try to compile this for the Mac.
> 
> That'd be awesome.

The entire std.c.darwin and std.c.mach modules were missing ?

It also seemed that gcc/config.d ended up the wrong way,
thinking that GCC had long double functions defined...

I copied them over from Brad's 0.18, and edited the config.d
Wonder if the config will work next time, if dirs are there ?


There was also a "version" error in the new std.process module:

./../../libphobos/std/process.d:98: undefined identifier (module process).spawnvp

Seems that it only had "alternate" C versions for Windows...
(the good old "there are only two platforms" bug, revisited)

--- ../libphobos/std/process.d.orig     Sat Apr 29 04:56:39 2006
+++ ../libphobos/std/process.d  Sun Apr 30 01:51:39 2006
@@ -93,9 +93,13 @@
     {
         return _spawnvp(mode, toStringz(pathname), argv_);
     }
-    else
+    else version(Windows)
     {
         return std.c.process.spawnvp(mode, toStringz(pathname), argv_);
+    }
+    else
+    {
+       assert(0);
     }
 }

Wonder if that's a DMD bug, since DMD only supports Windows/Linux ?
I'll report it anyway I think, as it really should be sent upstream.


There are a few similar bugs, where version(linux) should be (Unix)...
(Or at least I need to port std.c.fenv over to Darwin and Mac OS X.)

--anders


PS.
Commenting fenv out for now finally built Phobos OK, calling it a night.
Will run the unit tests and other checks later, then it's Dstress time.

Anders F Björklund wrote:
> Gregor Richards wrote:
> 
>>> You didn't say if you had been merging with what Brad did for
>>> "gdc-0.18-alpha1", so I will initially assume that you didn't.
>>
>>
>> That would be the wrong assumption, actually I did :)
> 
> [...]
> 
>>> Will run some diffs and then try to compile this for the Mac.
>>
>>
>> That'd be awesome.
> 
> 
> The entire std.c.darwin and std.c.mach modules were missing ?
> 
> It also seemed that gcc/config.d ended up the wrong way,
> thinking that GCC had long double functions defined...
> 
> I copied them over from Brad's 0.18, and edited the config.d
> Wonder if the config will work next time, if dirs are there ?
> 
> 
> There was also a "version" error in the new std.process module:
> 
> ./../../libphobos/std/process.d:98: undefined identifier (module process).spawnvp
> 
> Seems that it only had "alternate" C versions for Windows...
> (the good old "there are only two platforms" bug, revisited)
> 
> --- ../libphobos/std/process.d.orig     Sat Apr 29 04:56:39 2006
> +++ ../libphobos/std/process.d  Sun Apr 30 01:51:39 2006
> @@ -93,9 +93,13 @@
>      {
>          return _spawnvp(mode, toStringz(pathname), argv_);
>      }
> -    else
> +    else version(Windows)
>      {
>          return std.c.process.spawnvp(mode, toStringz(pathname), argv_);
> +    }
> +    else
> +    {
> +       assert(0);
>      }
>  }
> 
> Wonder if that's a DMD bug, since DMD only supports Windows/Linux ?
> I'll report it anyway I think, as it really should be sent upstream.
> 
> 
> There are a few similar bugs, where version(linux) should be (Unix)...
> (Or at least I need to port std.c.fenv over to Darwin and Mac OS X.)
> 
> --anders
> 
> 
> PS.
> Commenting fenv out for now finally built Phobos OK, calling it a night.
> Will run the unit tests and other checks later, then it's Dstress time.

I guess I lost some libraries in the process of forward porting, sorry ... I clearly wasn't as careful as I should have been :)

 - Gregor Richards

Gregor Richards wrote:

> I guess I lost some libraries in the process of forward porting, sorry ... I clearly wasn't as careful as I should have been :)

No problem, std.c.process and std.c.fenv are really missing code
(implementations for Darwin), so those errors were to be expected.

I really wish Walter could add version(Unix) to DMD... Any Day Now.

Adding the "std.c.darwin" and "std.c.mach" directories back in was
easy enough, and then they worked alright with the rest of Phobos.

The "mars.h" error was merged from upstream, again not your fault :-)


I'm still seeing some errors from the configure and from "make check",
but I haven't run those in a long time so they could be old news...

So far, it's all looking good. I am happy that you released it early.

--anders