I’m very sad to hear that and I totally feel your pain. But I’ll take the opportunity to note that svn was probably a significant blocker for many people (for the exact same reason git appears a blocker to you). I hope you would understand better now why many people complain about GCC but do not take action: maybe there was an accessibility issue with the tooling around the code (other than the obvious learning curve that compiler development implies).
As far as I’m concerned once I wanted to contribute to Octave an improved version of ellipke, that takes complex m values, instead of the current - infty<m<1 (nothing really invented by me, just based on a follow up paper by the same author of the algorithm they currently implement, which somehow went unnoticed I guess). But, for real, I got road blocked by their mercurial and mailing list based workflow. Would it have been on git{hub,lab} I would have just done it right away and maybe it would be included now, but I would not enter what for me is a whole can of worms and a total detour to my work, just because their workflow does not match what the de facto standard is nowadays. So yes, I just have my own tweaked version included in my personal project and that’s it (I did not contribute it to Matlab neither, since they are not open source, nor I did to SciPy cause they do not really implement elliptic integrals, but just wrap cephes).
Sorry for the detour, the intended take home message is thag workflow and tooling accessibility is paramount to have contributions and I think you just got to taste (in the worst way possible) how bitter it gets when it is lacking.
The brights side I see in this is that most probably GCC would see a significant boost in contributions by the mere act of switching to git (not so sure about gfortran specifically, since there are not so much young people that regularly work with fortran, we’ll see). I hope that the whole GNU stack would gradually move to git (and hopefully to github or gitlab too).
Would it be possible to get those previous developers of gfortran in contact with users of this discourse, so the users can make the merge requests in their stead ?
I really feel like we shouldn’t throw away their expertise and work. I believe the ones making the merge request could and should credit the original contributor or something.
Ok, this is much concerning. I totally agree with the following
and I’ll add that there’s no way that a younger generation, no matter how talented and motivated, could start from zero to contribute to such a big project, with no tutoring whatsoever from the former, experienced contributors. It’s really just a matter of knowing the codebase.
Maybe we could try to make some arrangement, where the experienced gfortran developers put effort in explaining and guiding others about the code structure, conventions, generically navigating the project and the interested “git aware” developers in turn give back support with git (which should be, as I understand from the comment above, the big main blocker for the older generation, greatly adding to the “small numbers” problem).
Ideally at first it would mean to “just” get merged all the patches sitting around in laptopts (in lieu of others, i.e. I totally agree that credit must be preserved!) but I’d really hope at some point this would make for a true passing of the baton between generations. Otherwise I’m really afraid that gfortran might really die this time.
If you’d let me divagate a bit, this seems to resemble too much what might be suddenly happening with twitter (almost all experienced people are gone, so who would tutor new developers and maintainers for the website, or even the company?).
Anyway, I know nothing about compiler development and truly believe I do not have the skills (not currently at least). But, to be more concrete, I can surely commit to give help with git. I’m no big expert with it either, but I’m pretty comfortable with it, as it is basically the main non-physics-related hard skill I tamed during these PhD years.
So @kargl, feel free to contact me (also privately) if you need any help with getting those patches merged, I’ll try to help as reactively as I can with it.
Well, all closed PRs are unmerged, and there are some comments clarifying that no, the github mirror is not monitored and there is another procedure to be followed (e.g. this one). We probably should refer to this: Contributing to GCC - GNU Project, where the clunky legal procedures are still in place (in some form). But, given that the actual author of the patch is an already active GCC developer I think we could just go with the Signed-off-by method. @kargl, you and your colleagues working in gfortran have all “sign-off” privileges, right?
Finally, now I can see why git looks quite a barrier here, they are not using a branch-based (PR-based in github speech) workflow, but the older email-based one originally devised for the Linux kernel (and still in place therein, iirc). Oof… but still I think that we can overcome everything by joining forces
This reminds me of something that has bothered me for the last 30 years. I understand that most modern compilers have a front-end, a middle, and a back end. The front-end translates the language source code into some intermediate symbolic language, which is then passed on to the middle and back-end parts of the compiler to produce the machine instructions.
In gfortran, the front-end is written in C. This means that in order to contribute to the compiler effort, the programmer must be fluent with three languges, C, fortran, and the intermediate language. Both C and fortran have evolved significantly over the past 30 years, so it is quite an effort and requires some significant skills to be able to do that. The intermediate language may have evolved during that time too.
To use a common phrase, in fortran we aren’t “eating our own dog food” in this respect.
I have wondered how things might have been different if the front-end development (to gfortran, or the LLVM fortran compilers, or to any other fortran compiler project) had instead been written in fortran rather than in some other language. Writing compilers still requires special skills, and knowledge of the intermediate language, but if we were eating our own dogfood, there might be be a larger pool of motivated potential developers.
Yes, it could be done in principle. The reason I chose C++ and not Fortran for the LFortran’s frontend is to have the whole compiler in the same language and to actually deliver a compiler. I can’t fight all the fights, so the first task is to deliver a working compiler that can also compile quickly (very important). If there is interest, we could write a new frontend in Fortran later once LFortran is in wide usage (currently it is not, so I am just focusing on delivering what we have).
GFortran and Flang could also in principle be implemented in Fortran, but chose C or C++ for the same reasons I think, to have the GCC and LLVM compiler collection in the same language, so that people need to only learn one language to contribute to it.
You need to have some knowledge of how compilers are engineered: lexer, parser, semantic analysis but not necessarily be an expert on that.
If you are developing a new compiler you will most likely want llvm bindings (probably the C api at least until we have better generics support).
Most parser and lexer generators target C and C++ so you would need to add a Fortran target or more likely write the parser and lexer yourself.
Rustc was initially written in Ocaml, maybe LFortran could be rewritten in Fortran in some very distant future.
Thanks, for posting this. I almost feel like this (or some version of it) should be a separate post for people to find easily i.e. “Contributing to GFortran”. Do you have any other bits of advice on getting new contributors started with gfortran?
Another question: @everythingfunctional@RonShepard@meow464
What would be the benefit of eating our own dog food “Cutting out the middle man” (I like this quote better) and writing the compiler in pure Fortran ?
In general, in our case it would mean one less language to master before being able to contribute to future compiler developments. Other benefits are that the tools that are developed to support the compiler can also be used for other unrelated projects.
There are now three different free modern Fortran compilers (gfortran, lfortran and flang, which exists in a traditional and a “from scratch” version). One the one hand this is good, on the other hand, each of these compilers would profit from more manpower. So I don’t think a fouth free modern Fortran compiler would really be beneficial.
Furthermore these compilers profit from the existing llvn/gcc infrastructure, which has matured for at least a decade (or 3 in the case of gcc).
So while a Fortran compiler that can compile itself sounds like a nice idea, I do not really believe the Fortran community should increase the number of free compilers.
Disclaimer: My practical experience in building compilers is exactly zero, so take everything I wrote with a large grain of salt.
I appreciate and respect your opinion none the less.
However, I must push back.
The argument I have against this is that there is one common lisp implementation, yet there are different common lisp compilers each offering different things.
At one point in time there were more than three Fortran compilers, why then did those compiler manufacturers not use your argument ?
My point is how long do we have to wait until the proverbial well runs dry of gfortran devs ?
If we make a compiler in Fortran, we reduce the overhead required to contribute to the compiler.
I would also add intel’s ifort and ifx compilers to that list. They are now also freely available, so that makes five compilers, not three.
And one reason for a fortran-based fortran compiler is exactly to address the manpower issue.
As for whether reading the K&R C book is sufficient to contribute to the gfortran effort, consider the following. Here is the very first program in that book, on page 6:
main()
{
printf("hello, world\n");
}
Here is what happens when you try to run it.
$ gcc hello.c
hello.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main()
^
hello.c:3:3: error: implicitly declaring library function 'printf' with type 'int (const char *, ...)' [-Werror,-Wimplicit-function-declaration]
printf("hello, world\n");
^
hello.c:3:3: note: include the header <stdio.h> or explicitly provide a declaration for 'printf'
1 warning and 1 error generated.
I do know enough C to know how to fix these problems, but my point is that the C language has changed over the last four decades, just as fortran has changed, and it is sometimes difficult to keep up with all of the changes.
I know that’s not the main point of your post, but I really had to double check. In my book, there is an extra #include <stdio.h> before main.
Maybe that’s from the first version of the book (I have the second)?
One question: Do you think of a pure frontend, or also a backend (that cares about CPU-specific optimizations ect)?
I am not opposed to writing a compiler in Fortran and actually believe the fields where Fortran is used should not become to specialized.
And I do not want to be the one that contributes nothing, but tells people what can/should not be done
I am just a bit concerned wheter the intersection of people interested in Fortran (most of them are rather natural than computer scientists) and people able to and willing to contribute to writing a compiler (for free) is limited and a fully standard- conforming compiler requires years of work.
The development of gfortran to the current state took about 20 years.
By the way, while Steve is concerned about the current state of gfortran, I still want to thank the developers (like him) for providing a free, and platform-dependent optimizing Compiler for modern Fortran. I am not sure whether this community would exist without gfortran.
I can not judge whether a switch to Fortran to write a compiler would motivate more people.
I agree that a lot of compilers (e.g. Free Pascal ect.) aim to be self-hosting.
