• dsimcha (15/15) Aug 16 2010 What are the current blockers to merging non-ancient versions of D2 into...
• Brad Roberts (5/25) Aug 16 2010 Along similar lines, I'd dearly love to see gdc+d2 sitting on top of the
• Michael Parrott (5/25) Aug 17 2010 I'll assume you're aware of this issue then:
• Iain Buclaw (31/66) Aug 17 2010 To be honest, currently it's been like writing the first chapter of a no...
• dsimcha (9/32) Aug 17 2010 It's tough to say where D2 support should be prioritized relative to pac...
• Norbert Nemec (7/8) Aug 21 2010 Or -- potential D2 users. I could imagine that D2 support in GDC would
• Jordi (4/36) Sep 19 2010 I just wanted to drop a small note to say i totally agree with dsimcha
• Iain Buclaw (9/46) Sep 20 2010 I think it's pretty safe to say now that all other priorities I gave men...
• Jordi (8/55) Sep 21 2010 Sound great. If i were to help on this, what would be the easiest task
• Iain Buclaw (15/73) Sep 21 2010 breaking. ;-)
• Iain Buclaw (6/6) Sep 28 2010 I've pushed the initial merge for 2.021

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.

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.

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.

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';

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.

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.

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.

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

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.

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

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!