www.digitalmars.com         C & C++   DMDScript  

D.gnu - GDC with later DMD's

reply Gregor Richards <Richards codu.org> writes:
GDC 0.17 is unfortunately out of date with respect to DMD.  I've been 
hacking at it and got a working GDC based on DMD 0.154, simply by 
incrementally going version-by-version, repatching it, and making sure 
it still compiles.  It seems to be working.  Most importantly, it 
compiles much of the stuff that GDC 0.17 doesn't due to language changes.

I don't want to fork or anything ... if the changes are relatively 
working, it'd be nice to get them into GDC proper.

Also, I fixed a strange bug that was annoying me.  It seems that GDC 
0.17 doesn't compile std.c.linux.linux in, even on a GNU/Linux system. 
The function is replicated by std.c.unix.unix, but unfortunately if a 
program does:

version (linux) { std.c.linux.linux... }

it would fail.  I dummied down std.c.linux.linux to not conflict with 
the other built-in things (and to import them of course), and it seems 
to work - at least I can finally build 'build' ^^


Another issue - libgphobos.a.  I don't quite understand why GDC 0.17 
only makes a .a.  It makes binaries quite big.  I modified phobos' auto* 
stuff to use libtool and make libgphobos.so.0.  That too seems to work.

If anybody wants a copy, I can get it to you.  David: What's your 
status?  Are you still maintaining GDC?  Do you have an accessible 
public repository?  It'd be nice if I could make changes without feeling 
like I was working against you :(

  - Gregor Richards
Apr 27 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 GDC 0.17 is unfortunately out of date with respect to DMD.  I've been
 hacking at it and got a working GDC based on DMD 0.154, simply by
 incrementally going version-by-version, repatching it, and making
 sure it still compiles.  It seems to be working.  Most importantly,
 it compiles much of the stuff that GDC 0.17 doesn't due to language
 changes.


I think Brad did something similar, so you might want to check with him.

And I've put all the DMD diffs up at http://www.algonet.se/~afb/d/diffs/


 Another issue - libgphobos.a.  I don't quite understand why GDC 0.17 
 only makes a .a.  It makes binaries quite big.  I modified phobos' auto* 
 stuff to use libtool and make libgphobos.so.0.  That too seems to work.


DMD does it this way too (libphobos.a), for the moment it's a good way 
to make sure the programs run since Phobos is in a constant state of 
flux... Eventually I'm sure something like "libstdc++" will emerge ?
(hopefully something less of a DLL Hell then what that one is, but)


 If anybody wants a copy, I can get it to you.


I'm interested, email me where it can be found.

--anders
Apr 28 2006
prev sibling next sibling parent Mathieu Chouinard <mchoui e-c.qc.ca> writes:
Gregor Richards wrote:


 GDC 0.17 is unfortunately out of date with respect to DMD.  I've been
 hacking at it and got a working GDC based on DMD 0.154, simply by
 incrementally going version-by-version, repatching it, and making sure
 it still compiles.  It seems to be working.  Most importantly, it
 compiles much of the stuff that GDC 0.17 doesn't due to language changes.
 
 I don't want to fork or anything ... if the changes are relatively
 working, it'd be nice to get them into GDC proper.
 
 Also, I fixed a strange bug that was annoying me.  It seems that GDC
 0.17 doesn't compile std.c.linux.linux in, even on a GNU/Linux system.
 The function is replicated by std.c.unix.unix, but unfortunately if a
 program does:
 
 version (linux) { std.c.linux.linux... }
 
 it would fail.  I dummied down std.c.linux.linux to not conflict with
 the other built-in things (and to import them of course), and it seems
 to work - at least I can finally build 'build' ^^
 
 
 Another issue - libgphobos.a.  I don't quite understand why GDC 0.17
 only makes a .a.  It makes binaries quite big.  I modified phobos' auto*
 stuff to use libtool and make libgphobos.so.0.  That too seems to work.
 
 If anybody wants a copy, I can get it to you.  David: What's your
 status?  Are you still maintaining GDC?  Do you have an accessible
 public repository?  It'd be nice if I could make changes without feeling
 like I was working against you :(
 
   - Gregor Richards


I'm also interested ... I'm currently trying to get it
working with gcc 4.1.0 ... 
Mathieu
Apr 28 2006
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
I'm trying to upload my patch to the D Journal, the owner gave me access 
but hasn't quite hacked it up so I can upload it properly.  If anybody 
wants a direct mail of it, email me at Richards codu.org

Also, I'm working on 0.156, should have that soon.

  - Gregor Richards
Apr 28 2006
parent reply Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 I'm trying to upload my patch to the D Journal, the owner gave me access 
 but hasn't quite hacked it up so I can upload it properly.  If anybody 
 wants a direct mail of it, email me at Richards codu.org
 
 Also, I'm working on 0.156, should have that soon.
 
  - Gregor Richards


void[] on IRC gave me some space to upload it:

http://www.dprogramming.com/~gregorr/gdc.php

  - Gregor Richards
Apr 28 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 void[] on IRC gave me some space to upload it:
 http://www.dprogramming.com/~gregorr/gdc.php


Thanks, got it... Will look at it later.

--anders
Apr 29 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 GDC 0.17 is unfortunately out of date with respect to DMD.  I've been 
 hacking at it and got a working GDC based on DMD 0.154, simply by 
 incrementally going version-by-version, repatching it, and making sure 
 it still compiles.  It seems to be working.  Most importantly, it 
 compiles much of the stuff that GDC 0.17 doesn't due to language changes.


Okay, I got your updated version ("gdc-Ego") and unpacked it.

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.

So now we're looking at integrating:
gdc-0.17        (DMD 0.140)
gdc-0.18-alpha1 (DMD 0.148)
gdc-Ego         (DMD 0.156)

Plus whatever changes that David has done for the gdc 0.18
release already, such as for Linux PowerPC or 64-bit support.

Will run some diffs and then try to compile this for the Mac.

--anders

PS.
The only differences between DMD 0.155 and 0.156 are prints.
(some debugging printfs were not commented out, expression.c)
Apr 29 2006
parent reply Gregor Richards <Richards codu.org> writes:
Anders F Björklund wrote:

 Gregor Richards wrote:
 

 GDC 0.17 is unfortunately out of date with respect to DMD.  I've been 
 hacking at it and got a working GDC based on DMD 0.154, simply by 
 incrementally going version-by-version, repatching it, and making sure 
 it still compiles.  It seems to be working.  Most importantly, it 
 compiles much of the stuff that GDC 0.17 doesn't due to language changes.


 
 
 Okay, I got your updated version ("gdc-Ego") and unpacked it.
 
 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 :)


 
 So now we're looking at integrating:
 gdc-0.17        (DMD 0.140)
 gdc-0.18-alpha1 (DMD 0.148)
 gdc-Ego         (DMD 0.156)


gdc-Ego is the combination of 0.17, 0.18-alpha1 and DMD-0.156


 
 Plus whatever changes that David has done for the gdc 0.18
 release already, such as for Linux PowerPC or 64-bit support.


Assuming he comes out of hibernation :(


 
 Will run some diffs and then try to compile this for the Mac.


That'd be awesome.


 
 --anders
 
 PS.
 The only differences between DMD 0.155 and 0.156 are prints.
 (some debugging printfs were not commented out, expression.c)


Yeah, I know, but from 0.154->0.155 was huge.

  - Gregor Richards
Apr 29 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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 :)


Excellent, I had reorganized it to match gdc-0.17, so I hadn't
run the diffs yet. All good then, we should be all synched :-)


 gdc-Ego is the combination of 0.17, 0.18-alpha1 and DMD-0.156


Great, would it be possible to reorganize it to match gdc-0.17,
and perhaps rename it to "0.18-alpha2" or something similar ?


 Plus whatever changes that David has done for the gdc 0.18
 release already, such as for Linux PowerPC or 64-bit support.


 
 Assuming he comes out of hibernation :(


If he doesn't, we just have to ignore those two fringe targets...
I don't see anything wrong with us releasing a gdc 0.18 anyway ?


 The only differences between DMD 0.155 and 0.156 are prints.
 (some debugging printfs were not commented out, expression.c)


 
 Yeah, I know, but from 0.154->0.155 was huge.


Yup, http://www.algonet.se/~afb/d/diffs/dmd-154-to-155-src.diff.gz
Just thought I'd mention the 156, since there was no "D Change Log"

--anders
Apr 29 2006
parent reply Gregor Richards <Richards codu.org> writes:
Anders F Björklund wrote:

 Gregor Richards wrote:
 

 gdc-Ego is the combination of 0.17, 0.18-alpha1 and DMD-0.156


 
 Great, would it be possible to reorganize it to match gdc-0.17,
 and perhaps rename it to "0.18-alpha2" or something similar ?


Probably a good idea.

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

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


 Assuming he comes out of hibernation :(


 
 
 If he doesn't, we just have to ignore those two fringe targets...
 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
Apr 29 2006
next sibling parent reply Gabe McArthur <Gabe_member pathlink.com> writes:
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
Apr 29 2006
next sibling parent Gregor Richards <Richards codu.org> writes:
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
Apr 29 2006
prev sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 29 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 29 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 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
Apr 29 2006
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.


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
Apr 29 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
 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
Apr 29 2006
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.
Apr 29 2006
parent reply Gregor Richards <Richards codu.org> writes:
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
Apr 30 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Apr 30 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Unfortunately, I've found several funky bugs with my patch, so I'm going 
to do a much more careful incremental patch, using a few real test 
programs that are known to fail.  See if I can avoid doing that again :)

  - Gregor Richards
Apr 30 2006
next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 Unfortunately, I've found several funky bugs with my patch, so I'm going 
 to do a much more careful incremental patch, using a few real test 
 programs that are known to fail.  See if I can avoid doing that again :)


The generated gcc.config for Darwin was still broken in it, too...
It doesn't include the "private import std.c.darwin.ldblcompat;" ?

There also needs to be some options added to the driver and wrapper:
http://d.puremagic.com/bugzilla/show_bug.cgi?id=2


But I got std.progress and std.c.fenv ported to Darwin, at least.
The former was just a simple change from "linux" over to "Unix",
the latter was a copy and paste from the the system's C headers.
Posting them as patches to the Bugzilla, once they're cleaned up.

--anders
May 01 2006
prev sibling parent reply Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 Unfortunately, I've found several funky bugs with my patch, so I'm going 
 to do a much more careful incremental patch, using a few real test 
 programs that are known to fail.  See if I can avoid doing that again :)
 
  - Gregor Richards


One bug came up in the 147-148 change.  Likely by no coincidence, this 
is also when the bit->bool change came into effect.

I've posted the working 147 and broken 148 patches to the D Journal:

http://www.tdjonline.com/?page_id=11

  - Gregor Richards

PS: Anders: Once I get back to 156, I'll integrate your patches.  Don't 
want to make the increments too complicated, sorry :)
May 01 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 PS: Anders: Once I get back to 156, I'll integrate your patches.
 Don't want to make the increments too complicated, sorry :)


Not a problem, so far they all apply equally well to DMD and GDC.
(there are just three, one to "mars.h" and two to Phobos modules)

I will probably just build and test for Mac, not develop anything.
At least not until Mac OS X 10.5, which is likely to have GCC 4.1...


Beyond the earlier mentioned Linux-PowerPC (and possibly X64 too???)
support, the most needed items for GDC are: DMD 0.156 and GCC 4.1.0

Well, that and the non-technical parts such as finalizing the name
and packaging up for end-users and writing a new home page and docs.

--anders

PS.
Supporting 64-bit might have to wait until DMD does too, I suppose.
Since the new Intel Macs are only 32-bit, it's not *my* big concern :-)
May 02 2006
parent reply Gregor Richards <Richards codu.org> writes:
Anders F Björklund wrote:

 Gregor Richards wrote:
 

 PS: Anders: Once I get back to 156, I'll integrate your patches.
 Don't want to make the increments too complicated, sorry :)


 
 
 Not a problem, so far they all apply equally well to DMD and GDC.
 (there are just three, one to "mars.h" and two to Phobos modules)
 
 I will probably just build and test for Mac, not develop anything.
 At least not until Mac OS X 10.5, which is likely to have GCC 4.1...


Nice to know it'll work on Mac at all ;)


 
 
 Beyond the earlier mentioned Linux-PowerPC (and possibly X64 too???)
 support, the most needed items for GDC are: DMD 0.156 and GCC 4.1.0


Seems to me like DMD 0.156 is by far the more important issue.  GCC 
4.1.0 can wait :)


 
 Well, that and the non-technical parts such as finalizing the name
 and packaging up for end-users and writing a new home page and docs.


"GCC D Compiler" forever ^^
And hopefully no new homepage will be necessary, since David will 
reappear and get things back on track.  Optimism is awesome 8-D


 
 --anders
 
 PS.
 Supporting 64-bit might have to wait until DMD does too, I suppose.
 Since the new Intel Macs are only 32-bit, it's not *my* big concern :-)


  - Gregor Richards
May 02 2006
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:


 Nice to know it'll work on Mac at all ;)


Oh, it does. On the ones using Intel, too...
(at least I think it does, no bug reports yet)


 Seems to me like DMD 0.156 is by far the more important issue.


It is, at least if you want the new things with templates and what not.
You can still run the "traditional" D programs, of course. (DMD 0.140)
But it would be nice if GDC could catch up with the newest D language.

Just meant that it is still useful, even while it haven't done so...


 GCC 4.1.0 can wait :)


The problem being that GCC 4.1.0 is now shipped as the default compiler
on for instance Fedora Core 5, which means that you right now can't even 
compile GDC on those machines without using a "compat" (GCC 3) compiler.

GCC 4.0 works though, so it should be OK for Mac OS X 10.4 - and Ubuntu.


 And hopefully no new homepage will be necessary, since David will 
 reappear and get things back on track.  Optimism is awesome 8-D


It needs a new* homepage anyway, but I definitely hope David returns!
(* = with the space/bandwidth for the binaries, some design and docs)

We will have to see how it goes, and also hear from Gabe on "gnu-d.org"

--anders
May 02 2006
prev sibling parent Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:

 Likely by no coincidence, this 
 is also when the bit->bool change came into effect.
 


No coincidence indeed.  I merged only the bit->bool change into the 
working 147 branch, and the problem persists.  Still investigating.

  - Gregor Richards
May 02 2006