Error with subprocess

[principejavier]

Ignorant about python, I get the following error when running:

$ ../../../Prog.down/fortran-tags/fortran-tags.py -g $F90FILES $I90FILES -o TAGS Traceback (most recent call last): File "../../../Prog.down/fortran-tags/fortran-tags.py", line 53, in from subprocess import run, PIPE ImportError: cannot import name run

Found a (possible) fix here but then I get

$ ../../../Prog.down/fortran-tags/fortran-tags.py -g $F90FILES $I90FILES -o TAGS Processing input files ... 49%Traceback (most recent call last): File "../../../Prog.down/fortran-tags/fortran-tags.py", line 497, in process_input(input_text, True, TAGS, path.abspath(f)) File "../../../Prog.down/fortran-tags/fortran-tags.py", line 399, in process_input m = search('[ :]'+name+'([ !]|$)', line_raw) File "/usr/lib/python2.7/re.py", line 146, in search return _compile(pattern, flags).search(string) File "/usr/lib/python2.7/re.py", line 251, in _compile raise error, v # invalid expression sre_constants.error: nothing to repeat

[raullaasner]

Which Python version are you using? Fortran-tags requires at least Python 3.

[principejavier]

$ python3 ../../../Prog.down/fortran-tags/fortran-tags.py -g $F90FILES $I90FILES Traceback (most recent call last): File "../../../Prog.down/fortran-tags/fortran-tags.py", line 53, in from subprocess import run, PIPE ImportError: cannot import name 'run'

$ ls -lat /usr/bin/python3 lrwxrwxrwx 1 root root 9 Mar 16 2015 /usr/bin/python3 -> python3.4

If I comment line 53 it works in some cases but I get the above error for a large project. I will let you know if I can isolate the reason.

[raullaasner]

The subprocess line can actually be removed, because it isn't used for anything. Can you post the Fortran source file for which it fails?

[principejavier]

Here you have it parameter_handler.f90.txt

I also noticed that when calling TBPs, e.g. call type%its_function(some, arg), definitions are not found. Am I doing something wrong? I can create a different issue for this if you prefer...that would be an essential feature to be 2008 conforming.

[raullaasner]

The script could not recognize select type constructs. This should be fixed now. How are the TBPs defined?

[principejavier]

Now it works. Thanks!

Regarding TBPs you can see exerice2 here. We used it in a Fotran Modernization Workshop we organized a couple of months ago.

FORTAGS is generated without problems.

If you then open the main program, exercise2.90 and go to line 42 col 17, M-. does not find the definition of "setup". It correctly finds the definition of problem if you go to col 10.

Then going to the definition of the TBP setup (line 24 col 19 of wathen.f90) of wathen_problem_t, M-s g finds exercise2.f90 and M-n sends you back to line 42 of it. Therefore, the symbol setup is identified as a TAG.

[raullaasner]

It seems "setup" is not written into the tags file at all. M-s g works because it is not dependent on the word under cursor being in the tags file. It basically does a grep across all source files, whether the word is in FORTAGS or not.

In this case, Fortran-tags is not able to recognize the renaming of a TBP. I'll try to find time to fix this and get back to you over the weekend.

Thanks for reporting the bugs. I usually fix things that I've come across myself or that people have pointed out. But there can still be issues that I haven't thought about.

[principejavier]

Great! There's no hurry at all...

Another issue is that two procedures with the same name bounded to different types are not distinguished, e.g. assembly (go to line 25, col 22 of wathen.f90 and M-s g also lists the call in line 82).

We work on the development of a relatively large finite element code written in F200X and we use understand, a tool that permits to easily navigate the code. If you fix these minot issues fotran-tags will tie regarding navigation (except for the fact that understand is friendly an opens a side window with, e.g. the results of M-s g).

However, the editor in understand is far from emacs.

For the future, a useful tool of understand is a rename procedure, that permits you to change the name of variable, type or procedure all along the code.

[raullaasner]

Sorry it took so long (I sort of forgot). Let me know if there are still issues.

[principejavier]

Now it works! Except when the name of the TBP has the same name in two different types, a typical situation (e.g. create, free, etc.). In the example I provided there are two TPBs named assembly bounded to different types and M-. may jump to the wrong place.

[principejavier]

It crashes when you have a generic overload, line 58 in this file vector.f90.txt

[raullaasner]

I fixed the last issue. As for name duplication, I'm not sure if there's an easy fix for that. Perhaps one level is doable, to handle cases like call a%b. But in general you could have something like call a%b%c(20)[1]%d(), where c is some array, for example. Parsing that could be very slow. I'll see if can find a good solution for this issue.

[raullaasner]

I'm closing for now, because we're quite far from the original question. But don't hesitate to start a new thread if necessary.