Who is using fortran-lang projects (fpm, stdlib, minpack, fftpack, vscode-support)?

[gnikit]

The fpm did all of the heavy lifting, the configuration files are pretty normal see METIS fpm.toml and ParMETIS fpm.toml

Both of them are still very work in progress (especially the ParMETIS repo) and I still need to fix a couple bugs in fpm that would make creating such projects a lot easier. This just goes to show that fpm has a lot of untapped potential; resolving compilation order, decentralised dependencies via Git, tree shaking and parallel builds are game changers!

I think that in a lot of cases we would be able to port major scientific codes to fpm with minimal effort.

[rgba]

I believe that for many “large” scientific projects having file-dependent compilation flags (and maybe other similar fine tuning functionality) is crucial, mainly when dealing with the inevitable amount of legacy stuff (that may well not reach the API, but still has to be compiled). As an example see my comment on a related post:

Fpm: profiles and file-dependent flags

Real world case Hi, reviving the post to ask for support defining file-dependent compile flags via response files, if possible. I want to make SciFortran[1] build (and even more importantly run a testsuite) via fpm as soon as possible. The long term goal would be to fpm-ize all the downstream condensed matter libraries we have and eventually just have a fpm.toml manifest for each single research project. With respect to our current CMake build system (which is very functional as far as build a…

More generally both CMake and cargo (which is the main inspiration for fpm, as I understand) provide easy directory-based differentiation of the build options. The former via the pervasive nested CMakeLists.txt + add_subdirectory pattern, the latter I don’t know well, but I see it’s extensively used in DFTWorks. But for what I got skimming through several disseminated discussions (github issues mostly I think) this is not planned for fpm, so that could be a nontrivial barrier for very large and especially heterogeneous projects…

[gnikit]

True, local preprocessor definitions within a package is not currently how things are done in fpm, but given that preprocessor support for fpm was added this summer I wouldn’t make any sweeping statements. Maybe this can be a GSoC project for next year, @lkedward what do you think?

[rgba]

@gnikit

I wouldn’t make any sweeping statements

Oh sorry, didn’t really mean to communicate that. I thought it was a precise design choice to have just a single, centralized, manifest file. I’m happy if it’s still to be decided

[lkedward]

Having more control over compilation flags, including per-file flags, is definitely planned for fpm. We had a GSoC student do a significant amount of good work towards this (see this presentation: https://tcevents.chem.uzh.ch/event/14/contributions/66/attachments/63/142/Hanling_compiler_flags_in_fpm.pdf). Unfortunately the full work hasn’t been merged since some implementation details remain unresolved. It is a really difficult problem to solve, that has no equivalent in other package managers, since we must support multiple compilers across multiple OSes while also respecting different flags for different dependencies and possible interactions between them. I’m very keen to get this finished since I think it’s the last major feature missing from fpm, unfortunately it will require paid time to do IMO.

[urbanjost]

Some internal programs (the biggest is 79 000, lines of Fortran, 16 000, lines of C) are now built with fpm; and nearly all of my github repositories, in different levels of progress from complete packages
to WIPs and experiments build with fpm -

Miscellaneous Modules

• M_time - expands on Fortran DATE_AND_TIME(3f) intrinsic
• M_strings - Fortran string manipulations
• M_system - Call C system routines(mostly POSIX)
• M_process - read or write to a process from Fortran via a C wrapper
• M_io - A collection of procedures that create a simple interface for common I/O tasks
• M_path - OOP interface to other GPF modules to manipulate and access files via fpm
• M_matrix - interact with your Fortran program with a matlab-like scripting language
• M_intrinsics - man-page style descriptions of Fortran intrinsics
• M_uuid - a module of FOX-derived routines for generating a UUID(Universally Unique ID)
• M_readline - Fortran interface to the readline(3c) procedure
• M_random - A collection of routines related to pseudo-random numbers
• M_stopwatch - package for measuring cpu and wall clock execution time
• paranoia - The Fortran compiler option inspection and testing program implemented as subroutines
• M_history - interactive program input line history editor
• M_ncurses - Fortran interface to the Ncurses C library
• M_msg - convert all common variables to a string in Fortran using unlimited polymorphic variables
• M_match - subset of Regular Expressions implemented in Fortran
• M_list - maintain a small array as a list
• M_LA - A small collection of Linear Algebra routines
• M_hashkeys - hash algorithms
• M_display - package for displaying small matrices based on dispmodule(3f)
• M_factor - Factors of whole numbers
• M_escape - Using in-band signaling wih ANSI control sequences to control terminal color from Fortran
• M_attr - set terminal text attributes using ANSI escape sequences
• M_color - convert between RGB color values and other common color models
• M_calculator - parse Fortran-like double precision scalar expressions
• M_anything - Use polymorphism to allow promoting, casting and molding intrinsic types

Command-line Arguments

• M_CLI2 - Fortran commandline-interface using a simple prototype command
• M_CLI - Unix-like command line parsing – prototype style converts command line to a NAMELIST group
• M_kracken95 - An almost Fortran-95 version of the command line parser procedure kracken(3f)
• M_kracken - parse command line arguments and create configuration files using syntax similar to ULS
• M_args - Command line parsing using a NAMELIST group

Graphics

• M_draw - low-level vector graphics library and module
• M_pixel - low-level graphics routines that write into a pixel array
• M_slices - A module for producing slice plots requiring fpm(1)
• M_calcomp - an old graphics library used in conjunction with M_draw for work with old codes

Apps

• prep - Fortran pre-processor
• la - application provides a shell for computations using linear algebra. Exercises the M_matrix(3f) module
• flower - a utility for changing cae of Fortran free-format files
• numdiff - compare numeric differences between two files
• Michel Olagnon’s f90split command for splitting free-format Fortran source files
• compute - command-line calculator exercises the M_calculator module
• xpand - program for expanding tab characters
• what - program for reading SCCS metatdata descriptions from files
• hashkeys - generate checksums of files using the modules from M_hashkeys

Plug-ins

• fpm-search - finds information about registered fpm(Fortran Package Manager) packages
• fpm-gdb - plugin for fpm(1) that runs gdb in vim

WIPs

• spag_lapack is an experimental WIP of LAPACK
• M_starpac - An update of NIST STARPAC 2.0.8 targetted at fpm
• orderpack - The ORDERPACK2.0 modules repackaged for fpm
• M_sort - basic sorting
• M_OS - Determine OS-specific information using standard Fortran – TEST ONLY
• M_graph - A simple XY plot utility(WIP)
• M_datapac - The NIST DATAPAC package modularized and made available via fpm
• M_blas - A Fortran BLAS library implemented as a free-format module.

Examples

• M_overload - Common examples of overloading of intrinsics and operators

Everything, almost

• General Purpose Fortran Conglomeration

[gnikit]

Amazing @urbanjost, thank you for putting this list together. I stumbled across many of these projects when I was trying to calculate the number of fpm projects. Your list is noticeably easier to navigate than the GitHub API JSON files I got.

[urbanjost]

That was generated by using curl to call the API:
curl ‘https://api.github.com/users/urbanjost/repos?per_page=1000’
and then making a throw-away fpm program that processed the JSON and wrote md.
Just extracting and formatting “Description” and "url_html"l and then some hand-editing rearranging some of the links and a little editing for some of the labels (they were grouped by hand). Maybe I should have kept that and dressed it up a bit.

[jacobwilliams]

Almost all of my opensource libs are now using FPM. Many of the big ones are listed here (see my GitHub repository list for all of them). I think FPM is a game-changer, just what we have needed for a very long time. I was actually a little skeptical at first that we needed such a thing, but am now 100% convinced. The days of manually downloading F77 code from Netlib and manually stuffing them in your makefile are over.

I have a couple of opensouce projects that show how to put all the libs together to do something nontrivial. The most complicated example is here which has a dependency listing in the toml file of:

[dependencies]
fortran-astrodynamics-toolkit = { git = "https://github.com/jacobwilliams/Fortran-Astrodynamics-Toolkit", tag = "0.5" }
NumDiff = { git = "https://github.com/jacobwilliams/NumDiff", tag = "1.7.0" }
ddeabm = { git = "https://github.com/jacobwilliams/ddeabm", tag = "3.0.0" }
json-fortran = { git = "https://github.com/jacobwilliams/json-fortran", tag = "8.2.5" }
bspline-fortran = { git = "https://github.com/jacobwilliams/bspline-fortran", tag = "6.1.0" }
pyplot-fortran = { git = "https://github.com/jacobwilliams/pyplot-fortran", tag = "3.2.0" }
fortran-search-and-sort = { git = "https://github.com/jacobwilliams/fortran-search-and-sort", tag = "1.0.0" }
fortran-csv-module = { git = "https://github.com/jacobwilliams/fortran-csv-module", tag = "1.3.0" }
nlesolver-fortran = { git = "https://github.com/jacobwilliams/nlesolver-fortran", tag = "1.2.0" }
argv-fortran = { git = "https://github.com/jacobwilliams/argv-fortran", tag = "1.0.0" }

So, that’s just my own walled garden, but I do have other projects using stuff from other folks. Haven’t yet used stdlib yet, but hopefully will in the future.

[jacobwilliams]

Terrific work @urbanjost!

[everythingfunctional]

Some of you put my productivity to shame. Well done. I’ll put my list here for since we’re at it (which you can also find here.

• veggies/garden - A unit testing framework for Fortran
• iso_varying_string - Implementation of the Fortran ISO_VARYING_STRING module
• strff - A library of of string functions for Fortran
• erloff - Errors and logging for Fortran
• quaff - Quantities for Fortran
• parff - A functional style parser combinator library
• rojff - Return of Json for Fortran
• materff - Manage material composition information at the isotopic level
• sqliteff - SQLite for Fortran
• dockerfpm - A publicly available docker image with the latest versions of fpm and gfortran installed

[henilp105]

here are Some Insights on Fortran Language and its repositories by me (source : github api),

• There are currently total 29649 repos using fortran . There has been considerable increase in the number of repos since 2019, ( every year 2-3.5k new repos) as compared to earlier ( 0.5k to 1.5k till 2019)

• As the FPM is new there is still only ~1.4% adoption in the github repos. ( 406 out of 29649), Which presents a very Large Scale growth opportunity , still it can grow exponentially for years.

• Reference-LAPACK/lapack remains the most starred, watched and forked repo in fortran.

I have curated a dataset of 2k fortran repos on github ( will share them soon) and trying to curate a dataset of all the fortran repos.

Thanks and Regards,
Henil

[gnikit]

Thank you @jacobwilliams, @everythingfunctional and @henilp105 for the added info.

BTW @henilp105 I would be a bit cautious with calculating adoption of fpm in Fortran projects. It’s difficult to measure the number of unique repos that use or could use a build system and are/aren’t using fpm. For example there are many repo duplicates (not just forks) of BLAS and LAPACK on GitHub that should be excluded from the stats. Another point for consideration is that fpm can be used to build C and C++ projects, should non-Fortran projects using fpm be excluded from the adoption stat? Just some food for thought.

[henilp105]

@gnikit , thanks sir for the insights and food for thought, for fpm adoption stats I have checked presence of fpm.toml file in repo (thus mostly it seems that it would have also included the c/c++ repos) it would be great if you can suggest a more robust method for it.

For duplicate repos detection (we can easily detect forks by api) how can we approach this problem, it would be great if you could share your insights on this problem.

One way I thought of was to check
1.file name
2.last updated date
3. sha256 checksum of files

In a nested way using graph ql api.

Thanks and Regards,
Henil

[gnikit]

When I was trying to get similar stats for the NumFOCUS application I ended up abandoning the idea of adoption %, it was too hard to estimate and I feared what I had was misleading. I thought a more interesting statistic is how many of the popular computational libraries can fpm build without having to modify the repo or modifying the repo in a standardised way e.g. copy all source files into the ./src directory. I suspect that project list would have to be manually compiled (I had no time for this so I simply skipped it altogether). This would also be a good strategy for finding and implementing new features for fpm.

[henilp105]

@gnikit Thanks for the idea and method, will try to make a script with docker to test if that can be done , ( for project list I will try to take most starred , watched and forked repos) .