Currently when I teach newcomers Fortran, I use VSCode, the Modern Fortran extension (@gnikit), then setup autosave (on focus change). We modify the code, then click on the built-in terminal, and compile by hand by executing commands, and run the generated binary. Then modify the code again and repeat.
It would be very nice if one could just click some kind of a button to compile and run the code. As well as clicking some key, such a F9, that would compile and run (probably executing fpm run underneath).
We also need some ways to pass in --compiler=LFortran into fpm, not sure if Modern Fortran VSCode extension should do it, or I should have some fpm config file for that.
My other big issue with explaining “implicit none” is now fixed by LFortran, that by default does not require it. So once we fix the issue above, then we have a solid environment to teach.
This has been something that I have been meaning to add for a while now. The project as a whole is being tracked here: FPM Integration VS Code · GitHub.
Having said that, this kind of build and debug automation is currently possible already through the use of tasks and launch.json scripts for debugging. You can bind these actions to keys, by default building is Ctrl/Cmd + Shift + B and debugging is F5. Other things that VS Code allows are: always building before launching the debugger and have multiple build tasks.
There was a post in FPM Discussions I think where I provided some scripts for VS Code and FPM integration. This is how currently one can debug in Modern Fortran using FPM. In that same thread there are more general purpose scripts for using FPM.
Techinically, we already have the ability to integrate with an FPM (or CMake or Autotools) it is just very user unfriendly.
Yes, I know one can setup things already by hand, so I am hoping there is no technical obstacle.
But I would like this to be the default, so that just installing the extension would just make things work (it’s ok for now to install fpm and a Fortran compiler separately).
It’s not the same as full integration with Modern Fortran, but I use an extension that adds a keyboard shortcut to repeat the last command executed in the terminal. As long as you just use the terminal to run fpm it would just compile and run the code. I think it’s this one:Re-run Last Command - Visual Studio Marketplace
We can do all of that. Downloading lfortran and fpm is quite easy, in theory. The problem we have in practice is that we wouldn’t want people to have to setup Anaconda for that. So we might want to look for another build system.
Yes, absolutely, if you have a look at the C++ extension, they have added Debug/Run, Choose build configuration and Build
Perfect! Yes, we want to have a working debugger too, but one step at a time. Just the “run” button (with a default simple key combination like F5 or F9) would be awesome.
Yes, so how to download fpm/lfortran?
My experience with Conda is that it’s best to leave it to the user to install. Installing it automatically does not seem to yield robust solid results.
We control how LFortran is distributed, so we could make a simple binary tarball for each platform. The extension could download, unpack. The same with fpm. I think that’s all that is needed.
One should never have to explain “implicit none” to newcomers!
And not have to waste any more precious time and energy and resources, however brief and small, with being forced to include the statement in one’s programs.
@awvwgk Do you have any ideas on this, I think my PyPi suggestion is likely to be more maintainance work than we want.
Whatever the solution ends up being I think we should keep a log of the download stats (somehow) and aggregate them with the Anaconda stats. If a lot of people are using the packages we want that to show.
If you have access to curl / wget / Invoke-WebRequest you could download one of the pre-built binaries from the GitHub release and add them to the system PATH at least for fpm. However, the distribution at the moment is limited to Linux/x86_64, MacOS/x86_64, and Windows/x86_64, but could be extended depending on the required platforms.
For LFortran creating pre-built binaries should be possible as well, but due to the dependency on LLVM for any serious application, downloading binaries on-demand seems resource-demanding and prone to conflicts with system libraries.
Both fpm and LFortran use conda-forge as primary distribution channel and offer a good coverage of platforms such as Linux (x86_64, aarch64, ppc64le), MacOS (x86_64, arm64), and Windows (x86_64). Installing compilers should preferably be done with a proper package manager, to avoid conflicts with the system libraries, which can lead to unnecessary user frustration.
We absolutely could, we can download anything from anywhere we want. The other idea that I had for fpm was to download the repo and compile it since we always have a working compiler (gfortran, ifort, nagfor) for the linter. Both of these approaches would effectively store the binaries somewhere inside the extension installation, similar to the C++ extension storing all the language servers.
lfortran still puzzles me a bit, I need to get more familiar with the codebase to be able to make any meaningful comments about how to install it reliably.
Ultimately, it might be worth prompting the user to install miniconda if not detected in their system and then creating a venv for the VS Code extension and doing everything inside that.
LLVM is linked statically, so that’s not a problem. On Linux at least, LFortran is a standalone statically linked binary. On macOS I think one has to always dynamically link to their “system” (libc), but otherwise everything else is also statically linked. On Windows I don’t have that much experience, but I assume it can also be done. You can have multiple versions of LFortran installed and they should not clash with each other.
FYI @certik this should be possible now with the latest pre-release. It can run/debug standalone files and if the dependencies are pre-built and properly included in the linter it can build/debug those as well.
For anything more serious we would have to properly
Integrate with CMake. Mostly done already on the CMake extension, we just need to fetch some info from the extension through their API
Integrate with Makefiles and Autoconf. The Makefile Tools extension is still a Preview so we would have to chat with Microsoft to see how we would do this and the direction where their extension is heading
Any of these is a fair bit of work so we might want to list them in next year’s GSoC projects or seek some funding to hire devs/do it ourselves.
I early used with C++ extension (cpptools) an offered solution from vscode issue to allow debug breakpoints “everywhere” :
“File → Preferences → Settings → Debug” and set parameter “debug.allowBreakpointsEverywhere” value “true”. When I used it several years ago VSCode could only output on debugging into xterm and gnome-terminal in Linux.
You don’t have to do that anymore. I think since late 2019 Modern Fortran for VS Code supports debugging natively. It still leverages the C/C++ extension’s debug adapters (that’s the program sitting between VS Code and the debugger).
The linked issue you provided, in my opinion, is the wrong way to go about this. You wouldn’t want the C/C++ extension being the one registering their debuggers for usage in other languages. The extension that should be doing that is the one providing language support for language X. There is nothing stopping current extension Devs from using cpptools as a dependency to their extension and leveraging their debug technology.
What we really want from Microsoft is for them to package their debug functionality in a module and provide a Typescript API instead of relying to an entire vscode extension. This would allow everyone else to very easily add debugging in their extensions. Although, I doubt that this will ever happen since a lot of Microsoft’s tech for this is proprietary and the current code is deeply embedded in the cppttools extension.
Yes, it was required for me in 2017. I should recheck all with new versions of vscode and fortran extension after cleanup vscode user configuration files. The quick test shows that my old task.json that called make (release or debug build) doesn’t work anymore with new versions maybe because of changing it’s format too and problems with paths.
Well, the path problem (linux) on build was related due to I opened separate file instread of folder with project. Maybe it requires additional changes in my tasks.json with env working directory variables. But after I opened folder instead of separate files the build tasks works ok.
The second problem was due to my too simple Makefile doesn’t manage separate debug and release directories. It uses targets “switching”. But if source files is unchanged then switch to another build task doesn’t rebuild executable. I.e. if I initially built release and rebuit as debug without changes then executable file will be the same without debug info. But it’s my fault of using such easy Makefile, I just need to improve it.
So debugging with breakpoints works for me if executable contains debug symbols. All works!
Just the “run” button (with a default simple key combination like F5 or F9) would be awesome.