@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:
- The Fortran Package Manager (fpm) might be the 10th code, since it exercises almost every modern Fortran feature.
- The SciPy package is huge, but it’s F77, so it’s not enough even if we compile it fully, and at the same time it is a LOT of work to compile it fully. We are making excellent progress there, we will decide if we give it one slot on the progress bar, or more, depending how we split the packages inside SciPy.
stdlib will likely be one slot
- The smaller packages like
featom will likely be one or two slots
SNAP 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.