Use of Python Script plugin to work with FORTRAN project

Arjan van Dijk

@Alan-Kilborn : A smile a day keeps the doctor away! So it will become a two-stage rocker then. How? I tried a simple command:

getdeps.exe NuclideDecay01.f90 > tempfile

but all the console says is:

getdeps.exe NuclideDecay01.f90 > tempfile
Process started (PID=20132) >>>
<<< Process finished (PID=20132). (Exit code -1073741515)
================ READY ================

There is no new file named tempfile. How to proceed?

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

So it will become a two-stage rocker then

I never said that, but two steps makes sense.

There is no new file named tempfile

If I try a simple test NppExec script:

cmd /c echo hello >hello123.txt

then my NppExec console shows:

cmd /c echo hello >hello123.txt
Process started (PID=19720) >>>
<<< Process finished (PID=19720). (Exit code 0)
================ READY ================

and I get a hello123.txt file in the same file as my Notepad++ .exe file. I’m using a portable version of N++, so I don’t know what happens with this example with the installed version.

If I were you, I’d do a search of your file system for tempfile, or even better, put an absolute path on it in the script, e.g.:

getdeps.exe NuclideDecay01.f90 >D:\tempfile

and then see if the file is created in the known path.

Otherwise, this definitely looks suspicious from your output:

Exit code -1073741515

Arjan van Dijk

@Alan-Kilborn : Your example gave a nice file hello123.txt in the latest working directory, so this part works. I found out that part of my problem has to do with the MINGW/MSYS environment from which I generally work. When I call getdeps.exe from Windows, it misses a set of dll’s. I copied them to the same directory as getdeps.exe and now I get an exit code 0 from NppExec when I call getdeps from there.

But…

When getdeps.exe sees 1 arguement, it only returns the string with the filenames in order of dependency. When it sees 2 arguements, then it first gives debug info logging its intermediate steps finding the dependent files. With

getdeps.exe myprogram.f90 > tempfile

it considers

tempfile

as its second and third arguements for getdeps.exe… How can I tell NppExec that “> tempfile” is not part of the commandline arguements for getdeps.exe, but for the shell?

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

How can I tell NppExec that “> tempfile” is not part of the commandline arguements for getdeps.exe, but for the shell?

I’d try:

cmd /c getdeps.exe myprogram.f90 >tempfile

Arjan van Dijk

@Alan-Kilborn This works. I get a nice file with the filenames.

Now how do I put the content of this file with sorted filenames into a string that I can offer to NppExec? Because when I call

gfortran tempfile

gfortran thinks that it has to compile tempfile as if it were a source file and not that it contains a list of source filenames…

Arjan van Dijk

I tried

gfortran < tempfile

but that did not work…

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

Now how do I put the content of this file with sorted filenames into a string that I can offer to NppExec?

Well, you’re sort of getting to the bottom of my knowledge about NppExec :-) so perhaps someone else could chime in, but…

You could try something like this; no idea if it will work for your exact case or not (worked for a simple trial I did as I don’t have your Fortran setup):

cmd /c getdeps.exe myprogram.f90 | clip

and then:

gfortran $(CLIPBOARD_TEXT) followed by the rest of your gfortran command line…

Arjan van Dijk

@Alan-Kilborn
The construction with the clipboard “does something”, but not completely what I want. To start, I just tried to call gfortran for the set of files listed on the clipboard, without any other option, not even the name of the executable, as there is always a default name. The NppExec line with the call to the compiler seems to get correct instructions from the clipboard, as the console tells me:

gfortran libxmath.f90 libutil.f90 libdate.f90 libexponential.f90 libinterval.f90 libtest.f90 test.f90

Process started (PID=7852) >>>
gfortran: error: test.f90
: Invalid argument
<<< Process finished (PID=7852). (Exit code 1)
================ READY ================

But test.f90 is just a normal source file. When I run the same command from MINGW/MSYS, gfortran has no problems and produces a nice executable. How to proceed?

Arjan van Dijk

Two decades ago, I wrote a set of macro’s that turned NEdit into a full IDE. And then they changed the macro language…

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

Two decades ago, I wrote a set of macro’s that turned NEdit into a full IDE. And then they changed the macro language…

Relevance to the subject at hand?

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

gfortran libxmath.f90 libutil.f90 libdate.f90 libexponential.f90 libinterval.f90 libtest.f90 test.f90
gfortran: error: test.f90
: Invalid argument
But test.f90 is just a normal source file. When I run the same command from MINGW/MSYS, gfortran has no problems and produces a nice executable.

How to proceed?

Well, unknown, at least by me. Maybe someone else…
Often such things are solved by continued experimentation by the one that has the specific tools that are giving trouble, i.e., you. :-)
But I realize that you may only want to put a certain amount of effort in.

Arjan van Dijk

@Alan-Kilborn: Just to demonstrate my level of ambition with this project. And therefore maybe boost your willingness to help.

Alan Kilborn

@Arjan-van-Dijk said in Use of Python Script plugin to work with FORTRAN project:

Just to demonstrate my level of ambition with this project

Well, it sounds like you have it. :-)

And therefore maybe boost your willingness to help.

It’s not about willingness; it is about ability, of which I’m tapped out on. :-(

Arjan van Dijk

@Alan-Kilborn
Thanks for helping me so far, the system at least does something now. I hope now some other expert steps in.

PeterJones

@Arjan-van-Dijk

Is there a way to just write and load/edit/save your own set of scripts directly, instead of copy/pasting them from an Npp text file into a menu window in Plugins > NppExec > Execute NppExec Scripts?

You paste them in there once, and then hit Save…, and now NppExec has saved the script.

Or you edit %AppData%\Notepad++\plugins\config\npes_saved.txt (which is where NppExec stores its saved scripts), and put the scripts in there. The name of each script is on the :: lines, so the script I showed you above is in npes_saved.txt as

::gcc-CompileAndRun
NPP_SAVE
cd "$(CURRENT_DIRECTORY)"
gcc -o "$(NAME_PART)" "$(FILE_NAME)"
$(NAME_PART)

After editing npes_saved.txt manually, you will have to restart Notepad++ to get NppExec to see those scripts.

Once you have the scripts in NppExec, if you don’t want to have to go select from the pulldown, you can use Plugins > NppExec > Advanced Options… to put individual scripts into the Macro menu. And once it’s in the Macro menu (and Notepad++ is restarted), you can use Settings > Shortcut Mapper to assign a keyboard shortcut to the script.

It seems as if NppExec does not like the construction with the reverse primes

Neither does cmd.exe. The “reverse primes” aka “backticks” aka “grave-accents” are a linux thing. I didn’t think they ever worked like that in the Windows environment: I’ve never had them work like that in cmd.exe, and I don’t use powershell enough to know whether they work there or not. Oh, right, you’ve mentioned MINGW/MSYS – Please understand that NppExec isn’t running in your MINGW/MSYS environment; it’s running in something much closer to cmd.exe. So you won’t get all the MINGW/MSYS magic automatically inside NppExec.

It seems as if NppExec does not like the construction with the reverse primes

As @Alan-Kilborn later said, it might end up in a different directory. There is a reason that nearly every one of my NppExec scripts has cd "$(CURRENT_DIRECTORY)" as one of the first couple lines… because I always want NppExec running relative to the file’s directory, not whatever directory it happens to start in (the notepad++.exe’s directory, or whatever directory the last script happened to leave me in).

gfortran tempfile thinks that it has to compile tempfile as if it were a source file and not that it contains a list of source filenames…

Does the gfortran executable have a command line option for “get the list of source names out of a file”? Many such commands do have that, and that would be the easiest method

But test.f90 is just a normal source file. When I run the same command from MINGW/MSYS, gfortran has no problems and produces a nice executable. How to proceed?

You need to figure out the exact sequence of events necessary to run your gfortran command from cmd.exe. Once you figure that out, using that series of commands in NppExec will usually work. Or, if you write a MINGW/MSYS-compatible script file or makefile, and have NppExec call that script or makefile using an appropriate command that launches the MINGW/MSYS environment. (I am not a MINGW/MSYS user, but I believe that they have a bash.exe or similar environment, IIRC. If so, then something like bash.exe fortran-bash-script.sh could be used to call it, or bash make myFortranProjectTargetName or whatever the right syntax is.)

Also, just to confirm: are all of those .f90 files mentioned in the same directory?

cmd /c getdeps.exe myprogram.f90 | clip
gfortran $(CLIPBOARD_TEXT)

It would very much surprise me if there wasn’t a slightly more elegant way of getting the output. @Michael-Vincent is more of an expert in using the details of NppExec than I am, so maybe he’ll have a chance to chime in.

Michael Vincent

@PeterJones said in Use of Python Script plugin to work with FORTRAN project:

@Michael-Vincent is more of an expert in using the details of NppExec than I am, so maybe he’ll have a chance to chime in.

I think between you and @Alan-Kilborn , you got it covered. If I can’t get it work in NppExec, I try to make a Windows Batch file (.bat) do it. If I can get it to run in a batch file, I use NppExec to call the batch file with appropriate command line arguments and then do the Macro menu thing.

For example, I have a Macro menu from NppExec called “Compile” and it “compiles” whatever is in Notepad++, be it Perl (perl -c), Python (pylint), C/C++ (msbuild or gcc depending on if there is a Makefile or .vcxproj or .sln file in an assigned project directory set as an NppExec global variable), JSON (jq), Yang, (pyang), YAML (yamllint -d relaxed), docker-compose… you get the picture. It got way to complicated to create all that logic in NppExec, so this is the NppExec “command”:

::compile
NPP_CONSOLE on
NPE_CONSOLE -- x+
NPP_SAVE
cd "$(CURRENT_DIRECTORY)"
IF "$(ARGC)"<="1" THEN
    NPP_EXEC project check
ENDIF
"$(NPP_DIRECTORY)\plugins\NppExtTasks\NppExtTasks.bat" compile "$(FULL_CURRENT_PATH)"
NPE_CONSOLE -- x-

And the NppExtTasks.bat file does all the magic!

Cheers.

Alan Kilborn

@PeterJones said

You (Arjan-van-Dijk) need to figure out the exact sequence of events necessary to run your gfortran command from cmd.exe.

I think this is the absolute key point. Nobody can really help with that, because nobody has this same toolchain.