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.

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.

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.

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

== 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.

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.

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.

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

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.

== 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