Thanks for the responses!> I might be wrong (I'd love to be wrong here!) but I think this is a bit > too ambitious >You might be right about it being too ambitious, it would certainly be wise to aim for less. A more polished, but less broad product is definitely better than a buggy standard compliant one, and I think that it would go better with the general philosophy of GSoC. I will take this fact into consideration for the revised proposal. Also, in your proposal, it looks as though you're not writing tests until> the end; tests need to be written as soon as the features are testable. >That's kind of true, but I actually planned on writing tests during feature development, it's just that these tests wouldn't cover everything and should be expanded and tested fully towards the end of GSoC. I should definitely mention that in my plan. As for the tooling support, I guess that it wouldn't hurt to take the fact that tools should be integrated with flang in the future into account during the development. I will take a look on how clang and various tools for it operate. 2013/4/22 Hal Finkel <hfinkel at anl.gov>> ----- Original Message ----- > > From: "Dmitri Gribenko" <gribozavr at gmail.com> > > To: "Alex L" <arphaman at gmail.com> > > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > > Sent: Monday, April 22, 2013 9:00:51 AM > > Subject: Re: [LLVMdev] GSoC project questions. > > > > On Mon, Apr 22, 2013 at 4:30 PM, Alex L <arphaman at gmail.com> wrote: > > > Thanks for your support. > > > I wrote my draft GSoC proposal, it can be viewed here - > > > https://gist.github.com/hyp/5434845 > > > Please read it and tell me what you think. Any criticisms or > > > suggestions are > > > welcome! > > > > Hello Alex, > > > > > I plan to make flang a fully featured frontend which fully supports > > > Fortran 77 > > > > I might be wrong (I'd love to be wrong here!) but I think this is a > > bit too ambitious. Given that you have to write tests *as you > > implement the features*, handle corner cases (and one has to actually > > discover corner cases from the standard, if one is not familiar with > > Fortran) and produce diagnostics for invalid code, I don't think it > > is > > possible to implement all of the frontend + codegen within 12 weeks. > > Alex, I agree with Dmitri, I think that the proposal sounds a little too > ambitious. Maybe everything will go smoothly and you'll be able to > accomplish everything that you'd like, but we should plan for less. I favor > identifying a useful subset (such as that needed for BLAS) and focusing on > doing a really good job on that subset rather than trying to get full > feature coverage. In my experience, coding tests and high-quality > warning/error messages takes more time than coding the feature itself. > Also, in your proposal, it looks as though you're not writing tests until > the end; tests need to be written as soon as the features are testable. > > Regarding motivation, I would also like to bring the same kind of > "tooling" (analysis and transformation) support available in Clang to > Fortran. Not that this specifically impacts your project, but I think is an > important part of the longer-term motivation for developing an LLVM Fortran > frontend. > > I am glad that you're excited about working on this project! > > -Hal > > > > > Dmitri > > > > -- > > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if > > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130422/378e667d/attachment.html>
Hi again. I've though more about the full standard being too ambitious, and now I fully agree with that. So I had a go at choosing the useful subset of Fortran on which I would like to work on - my update proposal can be viewed at https://gist.github.com/hyp/5434845 . Focusing on less should also improve my productivity and lead to a better summer of code project by drastically reducing the pressure :) 2013/4/22 Alex L <arphaman at gmail.com>> Thanks for the responses! > > >> I might be wrong (I'd love to be wrong here!) but I think this is a bit >> too ambitious >> > You might be right about it being too ambitious, it would certainly be > wise to aim for less. A more polished, but less broad product is definitely > better than a buggy standard compliant one, and I think that it would go > better with the general philosophy of GSoC. I will take this fact into > consideration for the revised proposal. > > > Also, in your proposal, it looks as though you're not writing tests until >> the end; tests need to be written as soon as the features are testable. >> > That's kind of true, but I actually planned on writing tests during > feature development, it's just that these tests wouldn't cover everything > and should be expanded and tested fully towards the end of GSoC. I should > definitely mention that in my plan. > > As for the tooling support, I guess that it wouldn't hurt to take the > fact that tools should be integrated with flang in the future into account > during the development. I will take a look on how clang and various tools > for it operate. > > > 2013/4/22 Hal Finkel <hfinkel at anl.gov> > >> ----- Original Message ----- >> > From: "Dmitri Gribenko" <gribozavr at gmail.com> >> > To: "Alex L" <arphaman at gmail.com> >> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >> > Sent: Monday, April 22, 2013 9:00:51 AM >> > Subject: Re: [LLVMdev] GSoC project questions. >> > >> > On Mon, Apr 22, 2013 at 4:30 PM, Alex L <arphaman at gmail.com> wrote: >> > > Thanks for your support. >> > > I wrote my draft GSoC proposal, it can be viewed here - >> > > https://gist.github.com/hyp/5434845 >> > > Please read it and tell me what you think. Any criticisms or >> > > suggestions are >> > > welcome! >> > >> > Hello Alex, >> > >> > > I plan to make flang a fully featured frontend which fully supports >> > > Fortran 77 >> > >> > I might be wrong (I'd love to be wrong here!) but I think this is a >> > bit too ambitious. Given that you have to write tests *as you >> > implement the features*, handle corner cases (and one has to actually >> > discover corner cases from the standard, if one is not familiar with >> > Fortran) and produce diagnostics for invalid code, I don't think it >> > is >> > possible to implement all of the frontend + codegen within 12 weeks. >> >> Alex, I agree with Dmitri, I think that the proposal sounds a little too >> ambitious. Maybe everything will go smoothly and you'll be able to >> accomplish everything that you'd like, but we should plan for less. I favor >> identifying a useful subset (such as that needed for BLAS) and focusing on >> doing a really good job on that subset rather than trying to get full >> feature coverage. In my experience, coding tests and high-quality >> warning/error messages takes more time than coding the feature itself. >> Also, in your proposal, it looks as though you're not writing tests until >> the end; tests need to be written as soon as the features are testable. >> >> Regarding motivation, I would also like to bring the same kind of >> "tooling" (analysis and transformation) support available in Clang to >> Fortran. Not that this specifically impacts your project, but I think is an >> important part of the longer-term motivation for developing an LLVM Fortran >> frontend. >> >> I am glad that you're excited about working on this project! >> >> -Hal >> >> > >> > Dmitri >> > >> > -- >> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if >> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130424/85b18d8e/attachment.html>
Hi Alex, You may want to check the later versions of the standard also to check if some of your proposal is not deprecated there. The most important thing in the Fortran standard is the array support and it is a big task by itself. In my opinion, the I/O part is not the most important thing yet it is an enormous task. Usually, the Fortran routines are used externally in other computation and I/O is done through other and more efficient layers. I hope your proposal will be accepted and I'm looking forward to seeing the result of your work. Cheers, Matthieu 2013/4/24 Alex L <arphaman at gmail.com>> Hi again. > > I've though more about the full standard being too ambitious, and now I > fully agree with that. So I had a go at choosing the useful subset of > Fortran on which I would like to work on - my update proposal can be viewed > at https://gist.github.com/hyp/5434845 . > Focusing on less should also improve my productivity and lead to a better > summer of code project by drastically reducing the pressure :) > > > 2013/4/22 Alex L <arphaman at gmail.com> > >> Thanks for the responses! >> >> >>> I might be wrong (I'd love to be wrong here!) but I think this is a bit >>> too ambitious >>> >> You might be right about it being too ambitious, it would certainly be >> wise to aim for less. A more polished, but less broad product is definitely >> better than a buggy standard compliant one, and I think that it would go >> better with the general philosophy of GSoC. I will take this fact into >> consideration for the revised proposal. >> >> >> Also, in your proposal, it looks as though you're not writing tests until >>> the end; tests need to be written as soon as the features are testable. >>> >> That's kind of true, but I actually planned on writing tests during >> feature development, it's just that these tests wouldn't cover everything >> and should be expanded and tested fully towards the end of GSoC. I should >> definitely mention that in my plan. >> >> As for the tooling support, I guess that it wouldn't hurt to take the >> fact that tools should be integrated with flang in the future into account >> during the development. I will take a look on how clang and various tools >> for it operate. >> >> >> 2013/4/22 Hal Finkel <hfinkel at anl.gov> >> >>> ----- Original Message ----- >>> > From: "Dmitri Gribenko" <gribozavr at gmail.com> >>> > To: "Alex L" <arphaman at gmail.com> >>> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> >>> > Sent: Monday, April 22, 2013 9:00:51 AM >>> > Subject: Re: [LLVMdev] GSoC project questions. >>> > >>> > On Mon, Apr 22, 2013 at 4:30 PM, Alex L <arphaman at gmail.com> wrote: >>> > > Thanks for your support. >>> > > I wrote my draft GSoC proposal, it can be viewed here - >>> > > https://gist.github.com/hyp/5434845 >>> > > Please read it and tell me what you think. Any criticisms or >>> > > suggestions are >>> > > welcome! >>> > >>> > Hello Alex, >>> > >>> > > I plan to make flang a fully featured frontend which fully supports >>> > > Fortran 77 >>> > >>> > I might be wrong (I'd love to be wrong here!) but I think this is a >>> > bit too ambitious. Given that you have to write tests *as you >>> > implement the features*, handle corner cases (and one has to actually >>> > discover corner cases from the standard, if one is not familiar with >>> > Fortran) and produce diagnostics for invalid code, I don't think it >>> > is >>> > possible to implement all of the frontend + codegen within 12 weeks. >>> >>> Alex, I agree with Dmitri, I think that the proposal sounds a little too >>> ambitious. Maybe everything will go smoothly and you'll be able to >>> accomplish everything that you'd like, but we should plan for less. I favor >>> identifying a useful subset (such as that needed for BLAS) and focusing on >>> doing a really good job on that subset rather than trying to get full >>> feature coverage. In my experience, coding tests and high-quality >>> warning/error messages takes more time than coding the feature itself. >>> Also, in your proposal, it looks as though you're not writing tests until >>> the end; tests need to be written as soon as the features are testable. >>> >>> Regarding motivation, I would also like to bring the same kind of >>> "tooling" (analysis and transformation) support available in Clang to >>> Fortran. Not that this specifically impacts your project, but I think is an >>> important part of the longer-term motivation for developing an LLVM Fortran >>> frontend. >>> >>> I am glad that you're excited about working on this project! >>> >>> -Hal >>> >>> > >>> > Dmitri >>> > >>> > -- >>> > main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if >>> > (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/ >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > >>> >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-- Information System Engineer, Ph.D. Blog: http://matt.eifelle.com LinkedIn: http://www.linkedin.com/in/matthieubrucher Music band: http://liliejay.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130424/b082bc23/attachment.html>
On Wed, Apr 24, 2013 at 6:05 PM, Alex L <arphaman at gmail.com> wrote:> So I had a go at choosing the useful subset of > Fortran on which I would like to work on - my update proposal can be viewed > at https://gist.github.com/hyp/5434845 .Are expression parsing and AST implemented? What about type representation? Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/