May I know why visual studio + intel Fortran is very user-unfriendly?
It seems Intel OneAPI + visual studio is not too bad. But I am not good at using debugger, perhaps you could elaborate a little bit more? Thanks.
We’ve been using Intel Fortran in our company to build a small FEM solver + a set of libraries for about 10 years. We have a solution containing about 15 projects (some executables, some libraries.
The problems I run into on a daily basis are:
ifort randomly stops building for an unknown reason. Writes something like “Operation didn’t succeed” to output, nothing more. VS restart needed.
after several hours of usage, the editor gradually slows down to a snail’s pace for fortran files, to the point where the letters you type appear several seconds after you press the keys. This has been happening on all the machines we have on all the versions of Intel Fortran we’ve had. VS restart needed.
the UI for configuring projects is annoying and makes making mistakes easy.
There’s no way to just type a list of command line switches you want to pass to the compiler. You have to go through a graphical interface and click through 20 different sections to find your options. The names of the options have no hint as to what they actually generate in the command line, you have to guess or search for each of the names in the manual to find out.
All of this is completely redundant just to please Microsoft people who thought everything needs to fit in a GUI. I very much prefer Makefiles and I would migrate to them instantly if I had the choice.
the supplied IntelliSense for Fortran is useless.
It provides virtually no useful hints, the only one I’ve noticed is use modulename .
In vscode, one can at least use fortran-language-server, which is still work in progress and buggy (it’s basically a one man job AFAIK), but is orders of magnitude better than what Intel provides.
sometimes VS just randomly freezes
All in all, I end up having to restart VS several times on an average day.
My current workflow is I usually rather use vscode to write new code or refactor old one, and only use VS to build and debug. It’s fiddly process, but much faster than putting up with the constant annoyances of VS while trying to think about the code I want to write.
If I had the option, I would leave VS instantly and would rarely look back.
There’s little missing from having a usable debugger for vscode, IMO.
I tried running a fortran executable under a C++ debug configuration in vscode and if I remember correctly, one can see a list of the appropriate variables, it’s just the debugger doesn’t know how to display the content of any of the Fortran types.
If Intel (or anyone else) supplied this, that would be a huge win.
(Sorry for the text not being too polished, I needed to write this quickly, but wanted to reply before the notification gets lost in time.)
Thank you very much for listing the 5 issues.
Issue 1 sometimes happens, restart VS solve the problem. I think it is perhaps related with Windows, after windows 10 1909 I sometimes have this issue.
Issue 2 is always a problem. Yes the IDE will begin to slow down after several hours or so. I usually need to restart VS.
Issue 3 is OK, not a big problem for me, but yes I understand it bothers some people.
Issue 4 I agree. I usually try my best to enable those intelliSense stuff, like below. But it is just not that intelligent.
Issue 5 rarely happens. But always ctrl + s and save project is necessary.
Overall I agree with you. But I can still live with VS + intel Fortran LOL.
But I do wish Microsoft and Intel people can make big improvements and make VS + intel Fortran better.
Thanks for pointing out the IntelliSense settings, somehow I never noticed those!
It’s still not what I would imagine (for example, I love to use ctrl+click to navigate to function definitions, which this doesn’t have), but a huge improvement over the default settings.
I don’t understand why Intel sets almost everything to false as default.
@mkonecny , here I think you’re referring to Visual Studio’s infamous unspecified error, “The operation could not be completed.”
This is systemic in Visual Studio due to which the cyberspace is full of complaints and issue threads but for which the root cause(s) are unclear and where many a remedy is posted but no definitive cure is in sight.
Now, Intel software team’s integration of their Fortran compiler system with Visual Studio may be further exacerbating the problems for Intel Fortran users but it is a case where a very complex IDE solution with complicated dependencies are also at play:
I strongly recommend you try out the debugger. It saves me a huge amount of time and is honestly the only reason why I’m stuck with Visual Studio.
It’s easy to use. Just setup your command arguments in the project configuration under Debugger, if needed. Put breakpoints in your code wherever you want to stop. You can then inspect your local variables and step through your code.
One weird thing that happens with Fortran is that often when you have a matrix operation on a line (I think it usually happens with matmul()) and you want to Step Over that line, it takes an incredible amount of time for no apparent reason. Sometimes it’s minutes.
In this case, just go to the following line, and do Run To Cursor (Ctrl+F10), which works instantly.
…btw, I had to restart Studio about 20 times during 4 hours today…
I agree that Intel’s Visual Studio integrations are just terrible. The “IntelliSense” stuff is entirely useless and makes the whole application unstable. You basically have to disable all that. Intel has never seemed to care enough to fix this (it’s been years and years like this). I don’t use VS as an editor anymore, I also use VSCode. With a few of the open source plugins, VSCode is a vastly better Fortran editor than the Intel Visual Studio integrations. I keep VS open to hit “Compile”, or when I need to use the debugger, but otherwise do all editing in VSCode. I too wish they would provide a debugger that works with VSCode.
@mkonecny, it would be nice if we can implement and document how to use a debugger with Fortran in VSCode, since it is open source and runs on Windows, macOS and Linux. I haven’t had time to investigate whether it is even possible to set up.
I guess this is going to be different on different platforms - vscode can either use Visual Studio Windows debugger (vsdbg) or GDB or LLDB as the underlying debugger (depending on the type option in launch.json).
Vsdbg is going to understand .pdb symbol files generated by ifort on Windows and gdb is going to understand whatever gcc/gfortran generates, but not vice-versa.
I tested the vsdbg option today and found out that Fortran binaries can indeed be debugged on Windows.
Everything seems to work except you can’t see the contents of arrays, because the debugger doesn’t know the data type.
Scalars and user-defined types are visible just fine. (I was surprised by the user-defined types.)
When working with ifort on Linux, one can use the gdb-based debugger that Intel supplies.
It worked seamlessly, as far as I can remember (I used it a year ago).
I can write some sort of a how-to for these two cases, but the Windows case is very spartan and practically unusable without the arrays.
But if it would lead to someone (maybe it doesn’t even have to be Intel) writing an extension that makes the arrays viewable, I’m all for it.
I have had decent luck with gdb (including the one that comes with the Intel compiler) on Linux. I have not had good luck with debuggers on other platforms. I suspect that has to do with the proprietary nature of Mac and Windows, but that’s just a hunch.
Also, without mentioning Intel Fortran integration at first, I suggest you start threads looking for feedback and assistance on how to avoid this Visual Studio problem at MSDN Social site as well as StackOverflow.
Separately consider planning an update to Visual Studio 2022 if you are able to - it holds promise as a 64-bit application with improvements in performance on Windows OS. I have been trying it off and on for over a week now to help another team I work with and VS2022 seems to perform better thus far: no "The operation could not be completed” errors yet. But I admit with mixed-language projects (C, C++ with Fortran or C#, Visual Basic with Fortran) I will soon face this error - my hope is only for a reduced frequency of this error.