Compile Fortran to OS kernel module so that there is no other user code running.
Heck. Lets just compile the whole human genome (which you might be able to make the case that its natures form of computer code) into Fortran. That way all you have to do to clone yourself is just recompile it (with LFortran of course). Of course in my case it would insist on outputing the new me as punch cards. ![]()
I did not set out to build a full Fortran IDE…but I seem to have done it…
Here’s what I used:
| Dependency | Used for |
|---|---|
| fpm |
Building, running, testing, updating and cleaning projects; reading their dependency tree |
| fortls |
The Fortran language server: hover info, completion, go to definition/implementation, references, rename, outline, diagnostics |
| fortitude |
Linting Fortran files as you type, and its automatic fixes |
| fprettify |
Auto-formatting Fortran files |
| pyside6 | Python Qt interface for creating the GUI |
| pyqtgraph | Drawing the interactive dependency graph |
| pigments | Syntax highlighting |
| pathspec | .gitignore matching for file list display |
| pyte | Built in terminal |
| pyspellchecker | Spell checking comments and strings in the editor |
| ollama | AI code review with a local models |
It’s very close to having everything I currently use VSCode for, and lots that VSCode doesn’t have at all. It certainly seems better now than anything Intel has ever produced for ifort/ifx (which is sad really). It launches instantly, doesn’t use all my RAM, has no feature I don’t want. Is it useable for a daily driver? I have no idea! Maybe! It certainly was a fun experiment to make. Is it AI slop? Maybe!! Does it scale? No clue!!!
What else can I add? I think the largest missing piece is debugger integration…
Here’s what it looks like to run fpm test. It’s using the Openmp-enabled fpm from conda-forge so it can build in parallel. But I also added a feature to also run the tests in parallel:

YES! My hate for GDB would fill the known universe. I liked the interactive debugger that Intel used to ship with ifort etc. Not sure why they dropped it.
The problem is i’m on an arm Mac and I don’t think gdb exists for that? I guess I’d have to try an llvm debugger? @certik what is the debugging situation for LFortran?
I believe there is a LDBG or something similar for LLVM based compilers but I’m not sure about Apple silicon. I believe most compilers and Unix based OSes use the DWARF debugging specification so maybe with AI you can roll your own debugger but they might be a bridge too far for what you are trying to do.
We support -g, although there will still be some bugs. We’ll iron them all out after beta. Then you need to use some debugger, like lldb to debug the binary. I looked into the VSCode debugger protocol and it’s really complex. Although with AI we might be able to use it somehow. Without AI I didn’t even attempt that. I still think there must be some simpler way.
I should also say that I let my AI agent debug my codes, so I probably haven’t used a debugger myself in like a year now. Do you still debug by hand?
You’re doing it wrong. This should be a TUI.
You should call it VSPunch.
Claude: convert all of Qt to a TUI framework. Make no mistakes.
This is a helpful tool, thank you for sharing this GUI package manager. Because of the AI heritage, have you examined the Python code with a Linter or a security scanner (e.g. bandit)? I’d be curious to know how AI generated code performs against lint-ing tests and security scans.
There is a project at LLVM to bring Fortran language support into lldb. Not sure how long that will take. You can search the lldb subproject to follow along.
i’ve had ruff for Python linting on since the start, so all that passes.
i’d never heard of bandit but I added it to the CI and now it runs on every commit. There were a few high-level issues it found originally that I had Claude fix. Some of the low ones don’t apply or we have to ignore since the point of this program is to run other programs (fpm, etc.)
Thanks for the reply. I am glad I was able to point you towards bandit. It has found some interesting high level holes that I have “plugged” on occasion.
How about a cyclomatic complexity analysis panel with auto-generated control-flow diagrams of the code?
Added debugger support! You can set breakpoints, step through them, view variable values and the call stack, etc. Here’s an example using gdb (the only debugger i’ve tested, so probably the only one that works). It’s running on a Mac in a Linux Docker container. Claude set all that up for me…I have absolutely no idea how Docker works. I also added valgrind support to check for memory leaks.
@certik To answer your question: Yes, Claude can do a lot of debugging on its own nowadays! It’s amazingly useful for that. Historically, I have occasionally needed to crack open a debugger to track down very hard problems (The intel debugger in Visual Studio on Windows. I never remember how to use gdb). Maybe those days are gone now, but probably it’s still something to keep in the toolbox just in case.
ifx and I think other LLVM based compilers can use the LLVM memory sanitizer tools. For ifx you set the -fsanitizer=address etc. I prefer that to valgrind which I have found to give false positives for Fortran codes on Linux. Of course there is the old saying that “If God had intended Fortran programmers to use debuggers, He wouldn’t have created the PRINT statement” ![]()




