We are happy to announce that we can compile fastGPT now:
You can follow our progress towards compiling 10 third-party codes at https://lfortran.org/, we have a nice progress bar there, and links to blog posts for each code that we can compile.
Thanks, @certik and Team, fantastic progress.
Where can we find the list of 10 code milestones? I can’t seem to find it on the home page. It would be really cool if you can label the x-axis of the progress bar with names of each target codebase, say with a 45 degree angle so that longer project names still fit. And then, if you hit your milestones out of order you can still re-order the progress bar.
Am I mistaken, or we’re having great Fortran news almost every day this summer?
Congratulations for the hard work to @certik and all those involved!
Sounds cool, yes we should try incorporating something similar.
Where can we find the list of 10 code milestones?
We created a dedicated issue to track the milestones, you may find that at Roadmap for compiling codes · Issue #1251 · lfortran/lfortran · GitHub.
@milancurcic great idea, I also thought about putting dates on the progress bar too.
We have not finalized the list. I’ve been laser focused on delivering this milestone, now when it’s done, it’s time to plan the next. Here is roughly what we are thinking:
stdlib will likely be one slotdftatom and featom will likely be one or two slotsSNAP code could will likely be a slot.So this already fills the bar. We know for sure some 10 codes like the above is a necessary condition for beta, so we now have the progress bar so that it’s easy to follow the progress, and underneath the progress bar is a list of blog posts and dates, so you can extrapolate yourself how long it will likely take.
But it might not be sufficient. Once we compile all 10 codes, we will decide what needs to be done next. We can ask our users, if they think it is good enough quality for beta, or whether we should first compile most open source codes (such as all codes at fortran-lang github and more). The progress bar is linear, but the actual progress is exponential. It took us 4 years to compile legacy Minpack. It took us 4 months to compile modern Minpack. It took another 3 to 4 months to compile fastGPT. But each code is an order of magnitude more complex than the previous.
This fastGPT code uses pretty much all the features that I personally use — array syntax (slicing, array intrinsic functions, operations, etc.), functions returning arrays, allocatable arrays (even inside a derived type), loading binary data from a file, and string manipulation, formatting, etc. I wrote it without caring about LFortran. It exposed so many bugs in LFortran that we had no idea we had, but we fixed them all. I know we have many more, but the fact that fastGPT compiles unmodified means very solid progress.
I initially thought about communicating progress based on features in Fortran that we support, but it is fragile, since a test for a feature might work, but it fails when actually used inside a production code. So I think the above approach with the progress bar and actual third-party codes is the way to go, because every code that we fully compile and it gives the same bit to bit results as GFortran is truly delivered.
A partial list of Fortran features that you know LFortran does not support would be helpful. For example, for some time LFortran did not support array constructors (that is now fixed), and you probably got reports from many users about this. Avoiding duplicate reports saves the time of both the developers and users of LFortran.
A few of the more advanced features of Fortran are
IEEE_EXCEPTIONS , IEEE_ARITHMETIC , and IEEE_FEATURES modulesWhich of these are in LFortran? (Even if most are not, I have lots of programs without them that I will try with LFortran.)
We do not support any of this yet.
We support a lot of the OOP features, but I would call it a “prototype” mode or very early alpha.
The F95 derived types are supported, but you will also find bugs if you dig deep enough, such as some combination of nested derived types and allocatable arrays will fail, but simpler cases, such as a derived type with allocatable arrays works (we use that in fastGPT).
Congratulations @certik !
May I suggest PRIMA as a candidate for the ten packages?
The solvers included in PRIMA are renowned and widely used. In addition, the implementation of PRIMA emphasizes the usage of matrix-vector operations and array intrinsics. If LFortran can compile PRIMA, it will be a certificate for LFortran’s capability of handling arrays.
It may also be useful to know that PRIMA does not use any of the following advanced features. I did this on purpose.
Congratulations on reaching this impressive milestone, @certik !
@zaikunzhang yes, we will compile PRIMA, but I don’t know when yet. I suspect we need a few other simpler codes as intermediate steps, but we will get there.
Great @certik ! I look forward to that!
Meanwhile, if you and your team have suggestions on the PRIMA code, I am all ears. Thank you!
Thanks!
I’m excited for LFortran!
I’m very happy to see how far fortran’s support ecosystem has improved!
I had really great experience using fortls, and particularly I really appreciate the low RAM usage by fortls. Yesterday I checked, and even after opening 60 fortran files in neovim, fortls was only consuming 16 megabytes of memory.
Credit for fortls goes to @gnikit !
Mega kudos on the progress by you and your team with LFortran! It is great to also see pleasant surprises as you noticed with a case involving internal subprogram as a procedure argument here.
How about trying this code sample next!?
@FortranFan thanks for the encouragement!
It triggered a bug in our parser, nice! Parser: "class(numseq_t(n=*))" triggers "Token '*' is unexpected here" · Issue #2544 · lfortran/lfortran · GitHub
This example will have to wait until we compile a few more codes, since it’s using several features that we don’t support yet, including coarrays. We’ll tackle coarrays after we compile most codes. Note that it doesn’t compile with GFortran either, see the issue.