Alan Miller was an important contributor of Fortran 90/95 code for statistics. He published many relatively small codes, with a program consisting of a module that defined KINDs, a module implementing the algorithm, and a main program. His codes should be in the Fortran Packages list, but how should they be grouped? Should each main program and associated sources be in a separate package, or should packages contain multiple programs for the same topic, such as least-squares regression, logistic regression, random number generation, optimization, and quadruple precision.
I have not used FPM seriously and would like to learn it by packaging Miller’s codes.
I forgot about this code collection; it looks like it would be useful to study it and add a suite of test cases. Those look like reasonably easy tasks for someone new to do.
Is there any convention on how modern Fortran code should be organized for testing? I’m most familiar with the Test Anything Protocol (TAP), which also has at least 2 Fortran implementations. There are implementations for TAP in a large number of languages (including Python).
Fpm currently doesn’t speak TAP natively, but you could have a TAP producing test suite and use a TAP consumer with the --runner keyword. Alternatively, you could pipe the standard output to a TAP consumer, but you might have to filter the actual TAP output first.
From my personal experience, adding fpm support to my meson-based projects required some rethinking of the testsuite. Meson has a quite decent support for unit testing and I usually use command line arguments, environment variables or test drivers to create unit tests, which return their status via the exit code (0: passed, 77: skip, everything else: failed).
One example is toml-f’s testsuite, which still doesn’t work with fpm (issue). But maybe my strategy for testing is just not the best one. I personally think testing should boil down to a single command, I want to run meson test -C build or fpm test and do not have to worry about setting a --runner command or something else.
What I settled with eventually for my newly started fpm project’s is having one test executable which collects all unit tests and runs the complete suite on fpm test. The original version I cooked up can be found in fpm itself here and now after I was asked for it several times also as separate project with support for fpm, meson and CMake. I think the overall test strategy is quite similar to vegetables which supports fpm and CMake.
@Beliavsky, in an effort to learn and make better use of fpm myself, I very recently turned Alan Miller’s to_f90.f90 program into an fpm package (not sure it’s ready for sharing, but if interested, it’s on https://github.com/jbdv-no/to_f90). I for one would certainly appreciate having more of Alan Miller’s codes easily accessible via fpm. Btw, it seems like in addition to Jason Blevins’ mirror, CSIRO now also hosts Alan Miller’s codes (see the to_f90.f90 link).
After discovering one of the Fortran TAP implementations mentioned by @R_cubed (via Milan Curcic 's book mentioning a paper by Bob Apthorpe on code recovery that mentions it), I also turned that into an fpm package (forTAPt on my GitHub, again very much meant as an effort to familiarise myself with the tools). What I really like about this Fortran TAP implementation, is that it provides output in a standardised form that can be processed by existing tools, and it is all in Fortran using functionality and features that are straightforward to understand (also for not super proficient programmers, like myself). A downside of this current implementation is perhaps that I have not yet found a way to conveniently summarise all my test with fpm, something like fpm test "*" --runner <my_test_runner> passes each of my fpm test executables to the runner individually, producing summaries for each test, instead of passing all tests at once to the runner, producing a summary for all (like <my_test_runner> ./build/<hash>/test/* does on Linux). There are certainly ways to change/improve/work around this. Another downside is the lack of automatic test collection. For a user like myself, @awvwgk’s test-drive looks like a perfect balance between functionality and complexity, so I would probably begin investing my efforts to make more use of that (possibly producing TAP output that can be consumed by existing tools?).
It should be able to produce TAP output quite easily, which would probably be better than just producing some format like it is doing now. If you are interested in using it with TAP, I can certainly turn it into a TAP producer.
The best description of the most recent version of TAP would be the Perl documents. The foundational module for TAP in Perl is the Test::Builder package.
More commonly used testing modules are subsets of the subroutines in this file.
I don’t think much has changed, but I’d be happy to compare the most recent version of Test::Builder (along with some other Perl modules) to see if the fortran-testanything git repo needs to be modified.