I’ve just uploaded this program to my github repository. It’s written in Fortran so I thought some people here might be interested. I’ve successfully built and run it on Linux and Windows but the only compiler I’ve found that will build it is ifort.
It is self-contained and uses quite a few of the more recent bells-and-whistles including parameterised derived types, user defined i/o, abstract interfaces and submodules. It has its own (simplistic) implementations of a linked-list and associative map.
It did not fix the ifx internal error or the gfortran-11 error, but are you sure the iomsg=“” assignments are allowed when ioerr is zero? Definitely uses a lot of features that exercise modern features. As mentioned, a good compiler test case. Primarily just moving the files around and tweaking the Makefile lets you support fpm, ford, and github CD/CI. I made a PR request that shows a prototype layout on how to re-arrange it if you are interested.
I’m afraid I’m guilty of a little psychological misdirection here. In an rpn calculator ‘=’ has no function so I decided to make it a synonym for quit (‘q’). Probably a bit naughty of me but it’s all part of the enjoyment!
If you don’t use it in the examples then you drop into interactive mode.
Thanks for doing that - I’ll look at it. Building with fpm is definitely a positive.
I do have some intrinsic reluctance to using fpm for my projects:
it constrains the layout - or does it? Nothing wrong with that really particularly for larger (and certainly commercial) projects but for small ones it seems unnecessary
it is another build tool and therefore point of failure. At work I have to build svn from source and there are three different build systems I have to use: scons, cmake and configure. If there were Fortran code I’d also have to be downloading and installing fpm. Whilst I’ve never had a problem with configure/make/install I’ve had nothing but problems with cmake - it is a nightmare. scons (like most python tools) might or might not work according to which version of python is available.
For small projects writing makefiles is easy and it doesn’t matter that you possible get more things built than necessary.
Having said all that I’m still keen to get it working with fpm so I’ve downloaded your branch, tested it and after initial problems (my fpm was 0.2.0) succeeded in building and running. So I’ve merged in your changes thanks.
I’ve add an issue on github, namely that ford fails and I’m getting regular emails about it. Do you know anything about it, can I disable it?
If I click on it in github I get
Error in user YAML: (): found character that cannot start any token while scanning for the next token at line 25 column 16
mv .githubs/workflow/docs.yml to docs.yml.OFF. I missed renaming that one. Those scripts are executed when you push to the repository and must return a zero exit status or you get an e-mail by default. It allows you to test on many system types automatically. There is a gfortran on Linux, gfortran on Microsoft using three common setups, intel ifx and ifort tests, and a MacOS gfortran test there. All but the docs ones install a Fortran compiler and fpm on a virtual machine and then run “fpm test”. The docs one runs “ford” and generates a nice HTML description of the project. It defaults to writing it to the recommended github branch gh-pages so it does not change the real project pages. You would have to create the gh-pages branch or change the script to write to the main page to make it work; but renaming the file so it does not end in .yml will turn if off; and then you have to add it with “git add -f .github” and then commit the change.
It is a “standard” setup I use for everything. The scripts in .github test the packages on a bunch of platforms which I do not even have, and generates developer documentation automatically. It can
be useful. If you look under the “Actions” menu of your page you can see the results.
The tar file is the documentation ford(1) generates when you run “ford ford.md” on your project.
Special comments can be placed in your code that I usually style after a man-page to provide nicely formatted documentation as well
Thanks. I’m playing catch-up on all this but will definitely look at it. In the meantime I’ve merged in your changes and fixed the GNUmakefile so that the project is build-able without fpm.