www.digitalmars.com         C & C++   DMDScript  

D.gnu - D2 Blockers?

reply dsimcha <dsimcha yahoo.com> writes:
What are the current blockers to merging non-ancient versions of D2 into GDC?
 I've been quietly following the project and noticed that:

1.  It's actively being worked on.

2.  D1 is up to date.

3.  There were a bunch of issues w.r.t. druntime, but these seem to be resolved.

4.  A new version of D2 hasn't been merged in ~1 month, even though the
project is generally active.

5.  There was some concern about breaking the currently working 2.019.  IMHO
this is **completely** unwarranted, as support for such an outdated D2 version
is probably **completely useless** to just about everyone.  Probably no
non-trivial code that compiles for 2.019 will work on the latest version or
vice-versa, and the only code that's still written for 2.019 is really old,
unmaintained code that noone cares about.  IMHO until you're at least close to
the latest version, you should just break older versions with reckless abandon
to march towards getting recent, useful versions working.
Aug 16 2010
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 8/16/2010 9:33 PM, dsimcha wrote:
 What are the current blockers to merging non-ancient versions of D2 into GDC?
  I've been quietly following the project and noticed that:
 
 1.  It's actively being worked on.
 
 2.  D1 is up to date.
 
 3.  There were a bunch of issues w.r.t. druntime, but these seem to be
resolved.
 
 4.  A new version of D2 hasn't been merged in ~1 month, even though the
 project is generally active.
 
 5.  There was some concern about breaking the currently working 2.019.  IMHO
 this is **completely** unwarranted, as support for such an outdated D2 version
 is probably **completely useless** to just about everyone.  Probably no
 non-trivial code that compiles for 2.019 will work on the latest version or
 vice-versa, and the only code that's still written for 2.019 is really old,
 unmaintained code that noone cares about.  IMHO until you're at least close to
 the latest version, you should just break older versions with reckless abandon
 to march towards getting recent, useful versions working.
Along similar lines, I'd dearly love to see gdc+d2 sitting on top of the druntime rather than maintaining an internal, ever drifting, fork. To that end, I'd welcome patches (preferably small baby-step type patches, not huge lump sum code drops) to narrow the differences.
Aug 16 2010
prev sibling next sibling parent Michael Parrott <baseball.mjp gmail.com> writes:
dsimcha Wrote:

 What are the current blockers to merging non-ancient versions of D2 into GDC?
  I've been quietly following the project and noticed that:
 
 1.  It's actively being worked on.
 
 2.  D1 is up to date.
 
 3.  There were a bunch of issues w.r.t. druntime, but these seem to be
resolved.
 
 4.  A new version of D2 hasn't been merged in ~1 month, even though the
 project is generally active.
 
 5.  There was some concern about breaking the currently working 2.019.  IMHO
 this is **completely** unwarranted, as support for such an outdated D2 version
 is probably **completely useless** to just about everyone.  Probably no
 non-trivial code that compiles for 2.019 will work on the latest version or
 vice-versa, and the only code that's still written for 2.019 is really old,
 unmaintained code that noone cares about.  IMHO until you're at least close to
 the latest version, you should just break older versions with reckless abandon
 to march towards getting recent, useful versions working.
I'll assume you're aware of this issue then: http://bitbucket.org/goshawk/gdc/issue/40/dmd-2020 Right now, AFAIK, all that is needed to have druntime be built with gdc, rather than have it standalone as it is now. So that means updating the configure scripts, Makefiles, and all that to include druntime and phobos to be built. I think D2 Phobos needs to be updated to 2.020 as well.
Aug 17 2010
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 17 August 2010 05:47, Brad Roberts <braddr puremagic.com> wrote:

 On 8/16/2010 9:33 PM, dsimcha wrote:
 What are the current blockers to merging non-ancient versions of D2 into
GDC?
  I've been quietly following the project and noticed that:

 1.  It's actively being worked on.

 2.  D1 is up to date.

 3.  There were a bunch of issues w.r.t. druntime, but these seem to be
resolved.
 4.  A new version of D2 hasn't been merged in ~1 month, even though the
 project is generally active.

 5.  There was some concern about breaking the currently working 2.019.
IMHO
 this is **completely** unwarranted, as support for such an outdated D2
version
 is probably **completely useless** to just about everyone.  Probably no
 non-trivial code that compiles for 2.019 will work on the latest version
or
 vice-versa, and the only code that's still written for 2.019 is really
old,
 unmaintained code that noone cares about.  IMHO until you're at least
close to
 the latest version, you should just break older versions with reckless
abandon
 to march towards getting recent, useful versions working.
Along similar lines, I'd dearly love to see gdc+d2 sitting on top of the druntime rather than maintaining an internal, ever drifting, fork. To that end, I'd welcome patches (preferably small baby-step type patches, not huge lump sum code drops) to narrow the differences.
To be honest, currently it's been like writing the first chapter of a novel. I *will* get started on it ... right after I get X done first, and maybe check my email, because that it important too ( and can often consume a day ;) Current developments that are taking priority first (in order) are: * Updating/Uploading packages in Debian and Ubuntu - as of writing, package is currently being built in Debian, with a predicted success across all 14 supported architectures. >:-) * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining with static chain decls and exprs. * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere along the line lost 64bit support. !!! - barely even started looking into it yet. Current blockers that need to be organised out (in my opinion) before D2 can be emerged are: * Integration into current GCC patches, which will require a regeneration of _all_ patches in the patch directory (even those I cannot account for as working). * Figuring out what internals need to be migrated from the current phobos2 directory, what needs to keep. * A general consensus needs to be reached on how we should handle ASM version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out calling conventions? * GDC Driver updates to tie the whole thing together - the easy bit. ;-) Anything I missed? Should I be pushing D2 further up the stack of my list of TODOs? Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Aug 17 2010
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 Current developments that are taking priority first (in order) are:
 * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
 is currently being built in Debian, with a predicted success across all 14
 supported architectures. >:-)
 * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
 with static chain decls and exprs.
 * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
 along the line lost 64bit support. !!! - barely even started looking into it
 yet.
 Current blockers that need to be organised out (in my opinion) before D2 can
 be emerged are:
 * Integration into current GCC patches, which will require a regeneration of
 _all_ patches in the patch directory (even those I cannot account for as
 working).
 * Figuring out what internals need to be migrated from the current phobos2
 directory, what needs to keep.
 * A general consensus needs to be reached on how we should handle ASM
 version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out
 calling conventions?
 * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
 Anything I missed? Should I be pushing D2 further up the stack of my list of
 TODOs?
 Regards
It's tough to say where D2 support should be prioritized relative to packaging, D1 fixes, general infrastructure improvements, etc. My biased opinion (since I personally don't use D1 and have tons of code written for the latest versions of D2) is that getting a basically-working D2.048 compiler is by far the highest priority. I personally (definitely NOT speaking for the rest of the community) have no use whatsoever for a D compiler that doesn't work with code written for DMD 2.048. However, I'm sure D1 users would beg to differ. I guess it really comes down to the ratio of D1 users to D2 users.
Aug 17 2010
next sibling parent Norbert Nemec <Norbert Nemec-online.de> writes:
On 17/08/10 19:07, dsimcha wrote:
 I guess it really comes down to the ratio of D1 users to D2 users.
Or -- potential D2 users. I could imagine that D2 support in GDC would be a significant step towards general adoption of D2. Furthermore: I could imagine that D2 users are more likely to contribute back to the development of the GDC than the typical D1 user. Whoever uses D1 does so to get a job done. A D2 user is more likely to be willing to do some tinkering and help GDC to move forward.
Aug 21 2010
prev sibling parent reply Jordi <jordi rovira.cat> writes:
On 08/18/2010 03:07 AM, dsimcha wrote:
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 Current developments that are taking priority first (in order) are:
 * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
 is currently being built in Debian, with a predicted success across all 14
 supported architectures.>:-)
 * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
 with static chain decls and exprs.
 * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
 along the line lost 64bit support. !!! - barely even started looking into it
 yet.
 Current blockers that need to be organised out (in my opinion) before D2 can
 be emerged are:
 * Integration into current GCC patches, which will require a regeneration of
 _all_ patches in the patch directory (even those I cannot account for as
 working).
 * Figuring out what internals need to be migrated from the current phobos2
 directory, what needs to keep.
 * A general consensus needs to be reached on how we should handle ASM
 version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out
 calling conventions?
 * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
 Anything I missed? Should I be pushing D2 further up the stack of my list of
 TODOs?
 Regards
It's tough to say where D2 support should be prioritized relative to packaging, D1 fixes, general infrastructure improvements, etc. My biased opinion (since I personally don't use D1 and have tons of code written for the latest versions of D2) is that getting a basically-working D2.048 compiler is by far the highest priority. I personally (definitely NOT speaking for the rest of the community) have no use whatsoever for a D compiler that doesn't work with code written for DMD 2.048. However, I'm sure D1 users would beg to differ. I guess it really comes down to the ratio of D1 users to D2 users.
I just wanted to drop a small note to say i totally agree with dsimcha on prioritizing the version upgrades for gdc for d2. This would really strengthen D in general.
Sep 19 2010
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Jordi (jordi rovira.cat)'s article
 On 08/18/2010 03:07 AM, dsimcha wrote:
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 Current developments that are taking priority first (in order) are:
 * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
 is currently being built in Debian, with a predicted success across all 14
 supported architectures.>:-)
 * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
 with static chain decls and exprs.
 * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
 along the line lost 64bit support. !!! - barely even started looking into it
 yet.
 Current blockers that need to be organised out (in my opinion) before D2 can
 be emerged are:
 * Integration into current GCC patches, which will require a regeneration of
 _all_ patches in the patch directory (even those I cannot account for as
 working).
 * Figuring out what internals need to be migrated from the current phobos2
 directory, what needs to keep.
 * A general consensus needs to be reached on how we should handle ASM
 version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out* A
general consensus needs to be reached on how we should handle ASM version
 calling conventions?
 * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
 Anything I missed? Should I be pushing D2 further up the stack of my list of
 TODOs?
 Regards
It's tough to say where D2 support should be prioritized relative to packaging, D1 fixes, general infrastructure improvements, etc. My biased opinion (since I personally don't use D1 and have tons of code written for the latest versions of D2) is that getting a basically-working D2.048 compiler is by far the highest priority. I personally (definitely NOT speaking for the rest of the community) have no use whatsoever for a D compiler that doesn't work with code written for DMD 2.048. However, I'm sure D1 users would beg to differ. I guess it really comes down to the ratio of D1 users to D2 users.> >
I just wanted to drop a small note to say i totally agree with dsimcha on prioritizing the version upgrades for gdc for d2. This would really strengthen D in general.
I think it's pretty safe to say now that all other priorities I gave mention to a month ago have been done and dusted. I've switched all my builds to D2 (so you could say that I'm solely working on it now), and druntime is getting on a little bit better with non-i386 architectures - having removed/replaced most problematic code. Thanks to everyone who's been giving me feedback on that. I suppose the next step is to get on with the next frontend merge, 2.021. Though admittedly it wouldn't have taken this long if the changes weren't so breaking. ;-)
Sep 20 2010
parent reply Jordi <jordi rovira.cat> writes:
On 09/20/2010 08:48 PM, Iain Buclaw wrote:
 == Quote from Jordi (jordi rovira.cat)'s article
 On 08/18/2010 03:07 AM, dsimcha wrote:
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 Current developments that are taking priority first (in order) are:
 * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
 is currently being built in Debian, with a predicted success across all 14
 supported architectures.>:-)
 * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
 with static chain decls and exprs.
 * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
 along the line lost 64bit support. !!! - barely even started looking into it
 yet.
 Current blockers that need to be organised out (in my opinion) before D2 can
 be emerged are:
 * Integration into current GCC patches, which will require a regeneration of
 _all_ patches in the patch directory (even those I cannot account for as
 working).
 * Figuring out what internals need to be migrated from the current phobos2
 directory, what needs to keep.
 * A general consensus needs to be reached on how we should handle ASM
 version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out* A
general consensus needs to be reached on how we should handle ASM version
 calling conventions?
 * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
 Anything I missed? Should I be pushing D2 further up the stack of my list of
 TODOs?
 Regards
It's tough to say where D2 support should be prioritized relative to packaging, D1 fixes, general infrastructure improvements, etc. My biased opinion (since I personally don't use D1 and have tons of code written for the latest versions of D2) is that getting a basically-working D2.048 compiler is by far the highest priority. I personally (definitely NOT speaking for the rest of the community) have no use whatsoever for a D compiler that doesn't work with code written for DMD 2.048. However, I'm sure D1 users would beg to differ. I guess it really comes down to the ratio of D1 users to D2 users.> >
I just wanted to drop a small note to say i totally agree with dsimcha on prioritizing the version upgrades for gdc for d2. This would really strengthen D in general.
I think it's pretty safe to say now that all other priorities I gave mention to a month ago have been done and dusted. I've switched all my builds to D2 (so you could say that I'm solely working on it now), and druntime is getting on a little bit better with non-i386 architectures - having removed/replaced most problematic code. Thanks to everyone who's been giving me feedback on that. I suppose the next step is to get on with the next frontend merge, 2.021. Though admittedly it wouldn't have taken this long if the changes weren't so breaking. ;-)
Sound great. If i were to help on this, what would be the easiest task to do? I guess merging revisions of druntime and phobos should be easier than dmd itself, as they might have less modifications. Actually i have tried merging with a 3-way merge tool the druntime in 2.020 and 2.021 with the current gdc and it didn't seem complicated. What do you use for testing it? dstress? j.
Sep 21 2010
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Jordi (jordi rovira.cat)'s article
 On 09/20/2010 08:48 PM, Iain Buclaw wrote:
 == Quote from Jordi (jordi rovira.cat)'s article
 On 08/18/2010 03:07 AM, dsimcha wrote:
 == Quote from Iain Buclaw (ibuclaw ubuntu.com)'s article
 Current developments that are taking priority first (in order) are:
 * Updating/Uploading packages in Debian and Ubuntu - as of writing, package
 is currently being built in Debian, with a predicted success across all 14
 supported architectures.>:-)
 * Port GDC to GCC-4.4 - nearly done, with one or two show-stoppers remaining
 with static chain decls and exprs.
 * Sort out the outstanding merges of D 1.062 and 1.063 - which somewhere
 along the line lost 64bit support. !!! - barely even started looking into it
 yet.
 Current blockers that need to be organised out (in my opinion) before D2 can
 be emerged are:
 * Integration into current GCC patches, which will require a regeneration of
 _all_ patches in the patch directory (even those I cannot account for as
 working).
 * Figuring out what internals need to be migrated from the current phobos2
 directory, what needs to keep.
 * A general consensus needs to be reached on how we should handle ASM
 version specifiers. Gnu_InlineAsmX86? D_InlineAsmX86? 64bit? Sort out* A
general consensus needs to be reached on how we should handle ASM version
 calling conventions?
 * GDC Driver updates to tie the whole thing together - the easy bit. ;-)
 Anything I missed? Should I be pushing D2 further up the stack of my list of
 TODOs?
 Regards
It's tough to say where D2 support should be prioritized relative to
packaging, D1
 fixes, general infrastructure improvements, etc.  My biased opinion (since I
 personally don't use D1 and have tons of code written for the latest versions
of
 D2) is that getting a basically-working D2.048 compiler is by far the highest
 priority.  I personally (definitely NOT speaking for the rest of the community)
 have no use whatsoever for a D compiler that doesn't work with code written for
 DMD 2.048.  However, I'm sure D1 users would beg to differ.  I guess it really
 comes down to the ratio of D1 users to D2 users.>  >
I just wanted to drop a small note to say i totally agree with dsimcha on prioritizing the version upgrades for gdc for d2. This would really strengthen D in general.
I think it's pretty safe to say now that all other priorities I gave mention to a month ago have been done and dusted. I've switched all my builds to D2 (so you could say that I'm solely working on it now), and druntime is getting on a little bit better with non-i386 architectures - having removed/replaced most problematic code. Thanks to everyone who's been giving me feedback on that. I suppose the next step is to get on with the next frontend merge, 2.021. Though admittedly it wouldn't have taken this long if the changes weren't so
breaking. ;-)

 Sound great. If i were to help on this, what would be the easiest task
 to do? I guess merging revisions of druntime and phobos should be easier
 than dmd itself, as they might have less modifications.
 Actually i have tried merging with a 3-way merge tool the druntime in
 2.020 and 2.021 with the current gdc and it didn't seem complicated.
 What do you use for testing it? dstress?
 j.
Dstress is the only testsuite to use currently, yes. It can take a long while though to run through. Preferably we'd have our own testsuite using dejagnu, but I haven't yet gotten down to work out how Expect works yet. Unfortunately, there is no easy change going from 2.020 -> 2.021, because the 'this' parameter to struct member functions is now a reference type, rather than a pointer (breaks all code implementations). Because of this change, gdc will also ICE in quite a few locations for varying reasons... Help on fixing the codegen to adapt for 2.021 would help greatly, though would require diving in the deep end of GCC internals. Regards Iain
Sep 21 2010
parent Iain Buclaw <ibuclaw ubuntu.com> writes:
I've pushed the initial merge for 2.021

Download available here: http://bitbucket.org/goshawk/gdc/get/ed6460a378bc.gz
There are still some features missing, most of which I've mentioned in on this
issue: http://bitbucket.org/goshawk/gdc/issue/67/dmd-2021-merge

Any input is welcome.
Thanks!
Sep 28 2010