somy latest problem is that I wanted to download a compiler and play around with the tutorials but I tried installing cygwin and getting it to work and nothing at all is working and the information is basically not there
Would you have any thoughts on what it would take to create a Fortran Software Foundation a la PSF (you will know this link) that within the US is also recognized as 501(c)(3) and make Fortran-lang part of FSF and which can seek and gain funding and have administrative staff who can maintain infrastructure as part of official duties such as the Fortran playground?
Regarding the Fortran playground, I recommend we do not use a solution that requires a full time professional, but rather a solution that we can manage for free, if there is one. I am offering which is maintenance free (hosted at static github pages) and fast, with the only downside that LFortran is alpha. As we reach beta hopefully in less than a year, it will be very usable to use online. And use the saved money to pay a full time professional to advance some of our core libraries like fpm.
With 501(c)(3), I can be motivated to contribute an annual amount, in say low 4 figures, and perhaps others might also. Additionally, many orgs can be influenced to fund as well, possibly with some marketing angle. This can expand over time to bigger things. @awvwgk and you are already doing this to some extent with STF.
I am personally just focusing on getting LFortran to compile all codes. Then you get the online playground for free (fast, robust, maintenance free due to using static pages), and many other advantages. Yes, today you only get alpha, but there is no other way to get a production compiler than several years of development.
It may be a lower priority than other standard features, but I think that down the road it would be important for LFortran to provide distributed memory parallel features out of the box, without a 3rd party library.
I am personally just focusing on getting LFortran to compile all codes. Then you get the online playground for free (fast, robust, maintenance free due to using static pages), and many other advantages.
Perhaps if a wish-list is gathered here or as an extension of the original playground project it could act as a seed project for testing the funding method(s) such as mentioned above; pending review of the resulting proposals? Direct funding, donation of time and technical skills, creation of useful documentation and examples, and incorporation of the results into development processes are all in some form of progress but do not yet feel easily accessible or easy to contribute to in all cases.
So one wish is that a self-contained fortran post on this forum could automatically load on
the live Fortran pages. On the playground that is simple up to the point of the size allowed
in theory.
The first thing to note is that the code is in so-called fixed form. This is the original layout for Fortran source code. Ever since Fortran 90 there has been a second form, called free form, that is more flexible and preferred by many (most?) programmers. The two forms are commonly distinguished via the file extension: .f for fixed form and .f90 for free form. This is not chiseled in stone, but it does help to use this convention.
I downloaded the two files and used gfortran to compile them. With the default options I got messages about rank mismatches. That is a consequence of an ancient idiom. Use -std=legacy to get rid of them. (They are then turned into warnings).
Expanding on this: the original file seemed to have different indentation from the screenshot shown here. The keyword subroutine is indented 6 spaces in the original file, and the + continuation character is in the sixth column.
Fixed form requires the the first six characters to be blank, unless a continuation is used. It also assumes lines are ended unless explicitly continued. Here, on line 1 we see an error at the end highlighted because the line should be continued but is not.
@Arjen I followed your instruction but the code still seems weird(the indentation are all wrong here) Could you help me by telling the detailed flow of how you successfully ran the code? , e.g. the detailed commands and operations. It would help me a lot!
Well, I copied the code from netlib, as per the links you showed. By simply copying from the webpage, which preserved the indentation in my case, I got the source files I required. My command-line read:
As there are a number of routines (from the BLAS library) that were not included in that build command, I got a list of unresolved externals, but the compile errors were all gone - turned into warnings.
I need to be able to compile Fortran and C/C++ code and link the object files together. I also need to be able to compile on both Windows and Linux and detect which compilers are installed: VisualFortran, msbuild.exe, gcc, gfortran and ifort (if available). In Gradle it seems like I have a couple of options:
Write two tasks that detect what toolchains are installed and then execute the compilers from command line. With this approach I am going to miss a lot of the builtin features Gradle offers, so I figure this is the last resort.
A colleague of mine has been working with FORTRAN for decades, and currently operates a successful business using a model developed in the FORTRAN 2018 standard. They expressed curiosity regarding Rust, along the lines of "my daughter says it's all the rage".
The model performs a series of intensive calculations over a spatial extent (LiDAR data), and the business model operates by marketing this service to different areas. The model runs rarely, and FORTRAN is already reasonably fast, so while I can confidently claim Rust can be as fast or faster, this fails to disqualify Rust but does not give it a leg up.
"Rust is memory-safe, eliminating whole classes of common memory-related bugs," I add. But my colleague shrugs and says "this program has been pretty stable for 12 years now, I don't spend much time dealing with that."
When it comes to the microservice contribution that I intend to make to the model, the question naturally arises whether it would be better to implement it in FORTRAN, or split off the particular set of functions I am contributing into a Rust library. I am unfamiliar with the build process for FORTRAN, do any of you know if Rust and FORTRAN play nicely together?
Based on the FFI section in the Rust book and this FORTRAN FFI example, it appears that I can create a normal library crate and make the functions of interest available through a FFI. Is it this easy? Should I be reading the Rust FFI guide by @Michael-F-Bryan?
I would say that introducing additional languages to existing projects should be avoided unless there is a very large gain in using the new language. It doesn't sound like there is such a large gain for your purpose.
For things that are mostly about loading a large dataset and running a bunch of math over it, FORTRAN is probably a great choice. Its semantics are made to fit well for that, and the implementations are probably extra-good at optimizing the indexing+math stuff. (And LLVM is pretty good at that, but maybe not quite as good. And Rust hasn't exposed a bunch of things like "I want the approximate version of these float operations" that FORTRAN probably has.)
When it comes to the microservice contribution that I intend to make to the model, the question naturally arises whether it would be better to implement it in FORTRAN, or split off the particular set of functions I am contributing into a Rust library.
I would be wary of introducing a new language to a large project. Even if using FFI to bolt it in is dead easy. In doing that one has doubled the difficulty of any one understanding what is going on in the code, they now have two languages to learn. Then there are just practical complications in building the program.
I'm not clear on what you mean by "micro-service". I typically take that to mean some independent program that takes requests over a network, crunches on producing some result and returns a response over the network. If one really has a reason to use a different language then doing so as a micro-service seems like a clean way to do so.
I don't particularly see any particular reason why Rust should be any slower than FORTRAN. Although I can imagine there are FORTRAN libraries that are very well optimised and likely a lot of effort to rewrite in Rust. Or even use from Rust.
Metcalf's book "Modern Fortran Explained: Incorporating Fortran 2018" is effectively a human-readable version of the Fortran standard with examples. There are also several other good books in the market.
Beginning with Fortran 2003, the standard added significant powerful formal C-Fortran Interoperability (CFI) features via iso_c_binding module and the bind(C) attribute among other features. These along with the latest CFI additions to the Fortran 2018, make the language interoperable with any language that can interoperate with C, including Rust, in a standardized portable way.
People have prudently warned on this thread about the dangers of introducing a new programming language to a project. But that seems unavoidable given the description of this project and the strengths and weaknesses of Fortran. Who writes web services in Fortran? There are lots of systems where some optimized numeric routines are implemented in Fortran and the rest of the system is in C++ and/or Python. Numpy for example. If the Fortran model can be wrapped in a library and called from some language that is good at web services maybe that would make more sense than writing an HTTP server in Fortran.
Thank you to everyone for responding so thoughtfully. As @lambda-fairy notes, batch numerical computation on well-structured, trusted data presents an interesting use case, as many of the common "elevator pitch" arguments for Rust do not apply. Although "as fast or faster" may be more of an aspirational goal, even if it were true I appreciate the pragmatic advice of @alice and others to not complicate the model with multiple languages. This makes the links from @shahmoradi particularly helpful, although "go learn FORTRAN" was not what I was expecting to hear.
3a8082e126