Or you can compile from source. Our GSoC student @ThirumalaiShaktivel has done a tremendous job fixing every bug that we knew about in the parser and we tested it on quite a few codes. Now it’s a good time for the wider community to test it out. If you discover any bugs, please report them here or create an issue at: Issues · lfortran / lfortran · GitLab.
How to test:
lfortran fmt some_file.f90
If it prints the code back (in color), it works. If you get any kind of errors, it’s a bug in the compiler and we would appreciate it if you let us know about it. You can also replace the original file by lfortran fmt -i some_file.f90 (be careful, only do this if the original file is checked into git). If you compile the reformatted code with another Fortran compiler, it should compile and run correctly.
We are aware of the following issues, that we will fix soon:
comments are currently skipped (this includes pragmas like openmp)
empty lines are skipped
the location information can sometimes be incorect in AST (so when you get a syntax error, the line/column number might not be accurate)
If you discover anything else, please let us know.
In my case the lfortran package could not be found (probably I would have to update the conda channels first):
$ conda create -n test1 lfortran=0.11.0
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed
PackagesNotFoundError: The following packages are not available from current channels:
- lfortran=0.11.0
...
@certik would it be complicated to provide single file binaries for end-users for all typical platforms (like it is currently done for fpm) to lower the barrier?
I think the binary is not tested at the CI, so we should add a test for it (to unpack it and run some example say in the latest Ubuntu docker image) and then we should set it up to upload somewhere and link to it at Download -, just like we handle source tarballs there already.
I have tried a simple test program in both lfortran terminal and jupyter notebook. On terminal, the Enter to submit is awkward. People usually use Enter to make a new line in source file. On jupyter, running a cell once is ok, but the 2nd time raises “semantic error: Program already defined”
I have limited time to try it, but I made a script to pull all registered fpm packages and then use lfortran as the compiler via a little wrapper script and flag actual errors and eliminated obvious duplicates. Generally looked very promising, but had a few interesting outputs using -i on all the packages that might be related to these files with actual failures so just bundled these up in a tar file first. I am sure some are still duplicates, but I think it will still be useful, as that is the result of thousands of files from a good number of authors using significantly different programming styles (so even there is a decent number here it is quite good, and a higher percentage succeeded than with ifx, but that is not quite fair because ifx does not do BLOCK yet and allocatable CHARACTER arrays of allocatable length, which was the majority of ifx(1) issues, as that is commonly used in this set):
Thanks for trying it! What key would you find more natural to submit the cell? IPython, Python and Julia also use Enter I believe, so we used the same key. But we can change it.
You probably tried a program. Yes, we have to make redefinitions work still. In this thread I am only asking to test the parser, not the rest of the compiler, as we are still working on implementing enough features before we release the MVP. You can test the parser with lfortran fmt.
Awesome, thank you @urbanjost! Note that the gcp.f90 is already fixed in master, but some of the other ones still don’t work. We’ll fix it soon. @ThirumalaiShaktivel, would you mind please taking the tarball and reporting all errors in there? It contains a list of .f90 files that failed with the last release.
Great it that was useful, fmt_i.tgz in the same directory might be useful, although I admit I have not looked through it yet myself. It is the before and after copies of the files that compiled before reformatting with “-i” but did not after. At least one of them has to do with a discussion I had in the past about unary operators and complex constants (changing “(-3.0, 4.0)” to “(-(3.0),4.0)” ) is non-standard. Who would have thought?
PS:
making a _scratch directory and pulling all the fpm(1) packages using fpm-search is pretty straight-forward, and gives you a lot of tests already in git(1). I use that a lot for testing fpm(1).
What is a kluge but handy is to create an “lf” compiler command and using it as the compiler on the packages on the fpm(1) command. You want it to keep going on an error. On a ULS if you make a little bash(1) script like
#!/bin/bash
##################################################
#@(#) call lfortran for formatting and keep going on error
##################################################
(
FILE=$2
echo ">>>>lfortran $FILE fmt"
case "$FILE" in
*dependencies/*);;
*.f90|*.F90)
# create ANSI color version
(lfortran fmt $FILE >$FILE.txt|| echo "OUCH $FILE")|xargs
# actually replace the files with reformatted version
#(lfortran fmt -i $FILE || echo "OUCH $FILE")|xargs
;;
esac
)
#######################################
exit 0
#######################################
you can do a lot of tests, skipping the .c and .f files and not stopping on error. Interesting for testing compilers and fpm or looking for examples of usage