Re: [PATCH 0/13] D: Submission of D Front End
On 13 July 2017 at 10:46, Iain Buclaw wrote: > On 24 June 2017 at 19:23, Iain Buclaw wrote: >> Hi, >> >> Just doing an update of the patch series, rebased against trunk, and >> applied changes as requested by every comment so far. >> >> Notes on changes have been made on each patch where applicable. >> > > Hi, > > So what would be the best way forward with this? > > In the meantime, I've set-up a buildbot to build and run the testsuite > on 7 different targets, and will add another 5 when I get round to > moving to a server with more disk space. > > Iain. Ping on this. :-)
Re: [PATCH 0/13] D: Submission of D Front End
On 24 June 2017 at 19:23, Iain Buclaw wrote: > Hi, > > Just doing an update of the patch series, rebased against trunk, and > applied changes as requested by every comment so far. > > Notes on changes have been made on each patch where applicable. > Hi, So what would be the best way forward with this? In the meantime, I've set-up a buildbot to build and run the testsuite on 7 different targets, and will add another 5 when I get round to moving to a server with more disk space. Iain.
Re: [PATCH 0/13] D: Submission of D Front End
On 06/13/2017 02:05 AM, Richard Biener wrote: > On Tue, Jun 13, 2017 at 2:09 AM, Iain Buclaw wrote: >> On 13 June 2017 at 01:22, Mike Stump wrote: >>> On Jun 12, 2017, at 11:34 AM, Richard Sandiford >>> wrote: I'm not sure who this is a question to really, but how much value is there in reviewing the other patches? >>> Maybe people who know the frontend interface well could comment on that part, but would anyone here be able to do a meaningful review of the core frontend? And AIUI some of the patches are straight imports from an external upstream. I was just wondering whether, once 5, 6 and 7 have been reviewed, accepting the rest would be a policy decision, or whether there was a plan for someone to review the whole series. >>> >>> So Iain might not have the whole game plan pre-arranged. My guess is that >>> it isn't yet. So, technically, people can argue for or against the FE as >>> the want, but ultimately, the SC I think gets to make the decision in the >>> form of accepting the FE contribution and appointing a FE maintainer. If >>> they say yes, then that person can technically self-review the changes to >>> the non-shared bits. For the shared bits, the usual maintainer for those >>> bits should review and approve those bits. For example, the testsuite >>> changes are reviewed by the testsuite maintainer; I've done that, so that's >>> done. If there are doc changes, a doc reviewer will review those bits and >>> so on. >>> >>> I'd expect that for the changes that aren't shared, we treat it kinda like >>> we do for a new port. There, we usually have a person or two go through >>> and weigh in where useful and help refine things a little. If someone >>> wants to help out and volunteer to do this, they will. If not, then we >>> just trust the FE coming in. The SC will weigh in if they want the >>> contribution contingent upon a review. Of course, the global reviewers >>> and/or the SC might be able to clarify, as they keep track of the little >>> details better than I, the above is just my guess to help get the process >>> started. >> >> >> Right, I actually gave no forewarning other than via IRC, where it got >> an acknowledgement from Jakub and Richi, if I recall right, the >> response was asking if the SC has formally accepted D and myself as a >> maintainer. The answer is 'no' on that front. My initial intent was >> to get things in motion again, after they were abruptly halted 4 years >> ago. > > Yeah, it was to make sure the issue is raised with the SC. Jeff? David E. raised it earlier today. Jeff
Re: [PATCH 0/13] D: Submission of D Front End
On Tue, Jun 13, 2017 at 2:09 AM, Iain Buclaw wrote: > On 13 June 2017 at 01:22, Mike Stump wrote: >> On Jun 12, 2017, at 11:34 AM, Richard Sandiford >> wrote: >>> >>> I'm not sure who this is a question to really, but how much value is >>> there in reviewing the other patches? >> >>> Maybe people who know the >>> frontend interface well could comment on that part, but would anyone >>> here be able to do a meaningful review of the core frontend? And AIUI >>> some of the patches are straight imports from an external upstream. >>> >>> I was just wondering whether, once 5, 6 and 7 have been reviewed, >>> accepting the rest would be a policy decision, or whether there >>> was a plan for someone to review the whole series. >> >> So Iain might not have the whole game plan pre-arranged. My guess is that >> it isn't yet. So, technically, people can argue for or against the FE as >> the want, but ultimately, the SC I think gets to make the decision in the >> form of accepting the FE contribution and appointing a FE maintainer. If >> they say yes, then that person can technically self-review the changes to >> the non-shared bits. For the shared bits, the usual maintainer for those >> bits should review and approve those bits. For example, the testsuite >> changes are reviewed by the testsuite maintainer; I've done that, so that's >> done. If there are doc changes, a doc reviewer will review those bits and >> so on. >> >> I'd expect that for the changes that aren't shared, we treat it kinda like >> we do for a new port. There, we usually have a person or two go through and >> weigh in where useful and help refine things a little. If someone wants to >> help out and volunteer to do this, they will. If not, then we just trust >> the FE coming in. The SC will weigh in if they want the contribution >> contingent upon a review. Of course, the global reviewers and/or the SC >> might be able to clarify, as they keep track of the little details better >> than I, the above is just my guess to help get the process started. > > > Right, I actually gave no forewarning other than via IRC, where it got > an acknowledgement from Jakub and Richi, if I recall right, the > response was asking if the SC has formally accepted D and myself as a > maintainer. The answer is 'no' on that front. My initial intent was > to get things in motion again, after they were abruptly halted 4 years > ago. Yeah, it was to make sure the issue is raised with the SC. Jeff? Richard. > Regards, > Iain.
Re: [PATCH 0/13] D: Submission of D Front End
On 13 June 2017 at 01:22, Mike Stump wrote: > On Jun 12, 2017, at 11:34 AM, Richard Sandiford > wrote: >> >> I'm not sure who this is a question to really, but how much value is >> there in reviewing the other patches? > >> Maybe people who know the >> frontend interface well could comment on that part, but would anyone >> here be able to do a meaningful review of the core frontend? And AIUI >> some of the patches are straight imports from an external upstream. >> >> I was just wondering whether, once 5, 6 and 7 have been reviewed, >> accepting the rest would be a policy decision, or whether there >> was a plan for someone to review the whole series. > > So Iain might not have the whole game plan pre-arranged. My guess is that it > isn't yet. So, technically, people can argue for or against the FE as the > want, but ultimately, the SC I think gets to make the decision in the form of > accepting the FE contribution and appointing a FE maintainer. If they say > yes, then that person can technically self-review the changes to the > non-shared bits. For the shared bits, the usual maintainer for those bits > should review and approve those bits. For example, the testsuite changes are > reviewed by the testsuite maintainer; I've done that, so that's done. If > there are doc changes, a doc reviewer will review those bits and so on. > > I'd expect that for the changes that aren't shared, we treat it kinda like we > do for a new port. There, we usually have a person or two go through and > weigh in where useful and help refine things a little. If someone wants to > help out and volunteer to do this, they will. If not, then we just trust the > FE coming in. The SC will weigh in if they want the contribution contingent > upon a review. Of course, the global reviewers and/or the SC might be able > to clarify, as they keep track of the little details better than I, the above > is just my guess to help get the process started. Right, I actually gave no forewarning other than via IRC, where it got an acknowledgement from Jakub and Richi, if I recall right, the response was asking if the SC has formally accepted D and myself as a maintainer. The answer is 'no' on that front. My initial intent was to get things in motion again, after they were abruptly halted 4 years ago. Regards, Iain.
Re: [PATCH 0/13] D: Submission of D Front End
On 12 June 2017 at 20:34, Richard Sandiford wrote: > [Disclaimer: I can't approve any of this :-)] > > Iain Buclaw writes: >> 001 - The front-end (DMD) language implementation and license. >> 002 - The front-end (GDC) implementation. >> 003 - The front-end (GDC) changelogs (here be dragons). >> 004 - The front-end (GDC) config, makefile, and manpages. >> 005 - GCC configuration file changes and documentation. >> 006 - Add D language support to GCC proper. >> 007 - Add D language support to GCC targets. >> 008 - D2 Testsuite tests. >> 009 - D2 Testsuite Dejagnu files. >> 010 - The D runtime library and license. >> 011 - GCC builtins and runtime support (part of D runtime) >> 012 - The Phobos runtime library and license. >> 013 - Phobos config, makefiles, and testsuite. > > Just checking, but is it right that of these, the only parts that > touch generic code are: > >> 005 - GCC configuration file changes and documentation. >> 006 - Add D language support to GCC proper. > > Both seem fairly small (bar the autogenerated bits) and almost > unobjectionable. > That is correct. >> 007 - Add D language support to GCC targets. > > In a sense you get to define what's correct here. > I've tried to keep a close relationship to where TARGET_CPU_CPP_BUILTINS and TARGET_OS_CPP_BUILTINS are defined. The versions emitted are documented in the D spec. >> 009 - D2 Testsuite Dejagnu files. > > Already approved by Mike. > > If that's all, then that's pretty impressive. :-) > > I'm not sure who this is a question to really, but how much value is > there in reviewing the other patches? Maybe people who know the > frontend interface well could comment on that part, but would anyone > here be able to do a meaningful review of the core frontend? And AIUI > some of the patches are straight imports from an external upstream. > Patches 002 and 004 would also be points of interest, as they interact with the GCC code and build scripts respectively. I'm sure there are parts in there where people will have questions, I certainly will have questions over whether there's ways to improve things too. > I was just wondering whether, once 5, 6 and 7 have been reviewed, > accepting the rest would be a policy decision, or whether there > was a plan for someone to review the whole series. > Patches 001 and 008 are maintained at github.com/dlang/dmd, and patches 010 and 012 at github.com/dlang/druntime and github.com/dlang/phobos. The rest may only be 10% of the entire set, but that covers everything that was written by both myself, and others who've contributed t gdc. > (Sorry if this was discussed and I missed it.) > I might be able to dig up some comments from a few years back when I first proposed this, but otherwise no, I've not seen it discussed yet. Regards Iain.
Re: [PATCH 0/13] D: Submission of D Front End
On Jun 12, 2017, at 11:34 AM, Richard Sandiford wrote: > > I'm not sure who this is a question to really, but how much value is > there in reviewing the other patches? > Maybe people who know the > frontend interface well could comment on that part, but would anyone > here be able to do a meaningful review of the core frontend? And AIUI > some of the patches are straight imports from an external upstream. > > I was just wondering whether, once 5, 6 and 7 have been reviewed, > accepting the rest would be a policy decision, or whether there > was a plan for someone to review the whole series. So Iain might not have the whole game plan pre-arranged. My guess is that it isn't yet. So, technically, people can argue for or against the FE as the want, but ultimately, the SC I think gets to make the decision in the form of accepting the FE contribution and appointing a FE maintainer. If they say yes, then that person can technically self-review the changes to the non-shared bits. For the shared bits, the usual maintainer for those bits should review and approve those bits. For example, the testsuite changes are reviewed by the testsuite maintainer; I've done that, so that's done. If there are doc changes, a doc reviewer will review those bits and so on. I'd expect that for the changes that aren't shared, we treat it kinda like we do for a new port. There, we usually have a person or two go through and weigh in where useful and help refine things a little. If someone wants to help out and volunteer to do this, they will. If not, then we just trust the FE coming in. The SC will weigh in if they want the contribution contingent upon a review. Of course, the global reviewers and/or the SC might be able to clarify, as they keep track of the little details better than I, the above is just my guess to help get the process started.
Re: [PATCH 0/13] D: Submission of D Front End
[Disclaimer: I can't approve any of this :-)] Iain Buclaw writes: > 001 - The front-end (DMD) language implementation and license. > 002 - The front-end (GDC) implementation. > 003 - The front-end (GDC) changelogs (here be dragons). > 004 - The front-end (GDC) config, makefile, and manpages. > 005 - GCC configuration file changes and documentation. > 006 - Add D language support to GCC proper. > 007 - Add D language support to GCC targets. > 008 - D2 Testsuite tests. > 009 - D2 Testsuite Dejagnu files. > 010 - The D runtime library and license. > 011 - GCC builtins and runtime support (part of D runtime) > 012 - The Phobos runtime library and license. > 013 - Phobos config, makefiles, and testsuite. Just checking, but is it right that of these, the only parts that touch generic code are: > 005 - GCC configuration file changes and documentation. > 006 - Add D language support to GCC proper. Both seem fairly small (bar the autogenerated bits) and almost unobjectionable. > 007 - Add D language support to GCC targets. In a sense you get to define what's correct here. > 009 - D2 Testsuite Dejagnu files. Already approved by Mike. If that's all, then that's pretty impressive. :-) I'm not sure who this is a question to really, but how much value is there in reviewing the other patches? Maybe people who know the frontend interface well could comment on that part, but would anyone here be able to do a meaningful review of the core frontend? And AIUI some of the patches are straight imports from an external upstream. I was just wondering whether, once 5, 6 and 7 have been reviewed, accepting the rest would be a policy decision, or whether there was a plan for someone to review the whole series. (Sorry if this was discussed and I missed it.) Thanks, Richard
Re: [PATCH 0/13] D: Submission of D Front End
On 29 May 2017 at 22:57, Eric Botcazou wrote: >> The upstream DMD compiler that comprises all components of the >> standalone part is now implemented in D programming language itself. >> However here GDC is still using the C++ implementation, it is a future >> goal to switch to being a self-hosted compiler minus the GCC binding >> interface (similar to Ada?), however extended platform support is >> something I wish to address first before I make this a consideration. > > Yes, the Ada compiler is written in Ada and the glue code (called gigi) lives > in ada/gcc-interface and is written in C++. > > -- > Eric Botcazou OK, so there should be no surprises when d/dfrontend itself is replaced by D sources. Iain.
Re: [PATCH 0/13] D: Submission of D Front End
> The upstream DMD compiler that comprises all components of the > standalone part is now implemented in D programming language itself. > However here GDC is still using the C++ implementation, it is a future > goal to switch to being a self-hosted compiler minus the GCC binding > interface (similar to Ada?), however extended platform support is > something I wish to address first before I make this a consideration. Yes, the Ada compiler is written in Ada and the glue code (called gigi) lives in ada/gcc-interface and is written in C++. -- Eric Botcazou
Re: [PATCH 0/13] D: Submission of D Front End
On 28 May 2017 at 22:31, Iain Buclaw wrote: > On 28 May 2017 at 15:30, Iain Buclaw wrote: >> >> --- >> >> Iain Buclaw (13): >> 001 - The front-end (DMD) language implementation and license. >> 002 - The front-end (GDC) implementation. >> 003 - The front-end (GDC) changelogs (here be dragons). >> 004 - The front-end (GDC) config, makefile, and manpages. >> 005 - GCC configuration file changes and documentation. >> 006 - Add D language support to GCC proper. >> 007 - Add D language support to GCC targets. >> 008 - D2 Testsuite tests. >> 009 - D2 Testsuite Dejagnu files. >> 010 - The D runtime library and license. >> 011 - GCC builtins and runtime support (part of D runtime) >> 012 - The Phobos runtime library and license. >> 013 - Phobos config, makefiles, and testsuite. >> > > Well, it looks like this will need breaking down even more. The GDC > parts should be OK, it's just the upstream bits that are far to big to > attach here. > In the meantime, I've uploaded the series here too: ftp://ftp.gdcproject.org/patches/ I look forward to the discussion when I'm back. Thanks, Iain.
Re: [PATCH 0/13] D: Submission of D Front End
On 28 May 2017 at 15:30, Iain Buclaw wrote: > > --- > > Iain Buclaw (13): > 001 - The front-end (DMD) language implementation and license. > 002 - The front-end (GDC) implementation. > 003 - The front-end (GDC) changelogs (here be dragons). > 004 - The front-end (GDC) config, makefile, and manpages. > 005 - GCC configuration file changes and documentation. > 006 - Add D language support to GCC proper. > 007 - Add D language support to GCC targets. > 008 - D2 Testsuite tests. > 009 - D2 Testsuite Dejagnu files. > 010 - The D runtime library and license. > 011 - GCC builtins and runtime support (part of D runtime) > 012 - The Phobos runtime library and license. > 013 - Phobos config, makefiles, and testsuite. > Well, it looks like this will need breaking down even more. The GDC parts should be OK, it's just the upstream bits that are far to big to attach here. Regards Iain.
