Very weird problem

[acroucher]

hi, I have come across a weird problem: if I set up a test project with a source directory containing these two files:

bob.F90:

module bob_module

end module bob_module

fred.F90:

module fred_module

  use npk_module

end module fred_module

and run FORD on it with the following config file:

project: Weird problem
project_dir: ./src
output_dir: ./doc/dev
extensions: F90
A very weird problem.

I get the following error:

acro018@des108:~/software/ford/test/super$ ford devdoc.md
Reading file src/fred.F90
Reading file src/bob.F90

Correlating information from different parts of your project...

Traceback (most recent call last):
  File "/usr/local/bin/ford", line 9, in <module>
    load_entry_point('FORD==2.0.0', 'console_scripts', 'ford')()
  File "/home/acro018/software/ford/code/ford/__init__.py", line 171, in main
    project.correlate()
  File "/home/acro018/software/ford/code/ford/fortran_project.py", line 136, in correlate
    ranklist = toposort.toposort_flatten(deplist)
  File "/usr/lib/python2.7/dist-packages/toposort.py", line 81, in toposort_flatten
    result.extend((sorted if sort else list)(d))
  File "/home/acro018/software/ford/code/ford/sourceform.py", line 136, in __lt__
    return (self.name < other.name)
AttributeError: 'str' object has no attribute 'name'

There is no npk_module defined in the source files. (It could be a module defined in a library that I link to- that usually seems to work OK.)

FORD works fine if:

• I add a third file containing a module called npk_module.
• I delete bob.F90.
• I put a 'use fred_module' statement in bob.F90.
• (really weird part) I change the name of npk_module to e.g. npl_module (or various other things, but not mpi_module or some others).

Am I doing something silly or is this a problem?

[cmacmackin]

Sorry for the delayed response. I've been doing a lot of coding for work lately and haven't had the mental energy to do much when I get home in the evening.

I'm failing to reproduce this bug. I'm wondering what version of Ford you're running. Don't bother trying to run ford -V, because it turns out that I'd forgotten to update that information when I released 2.0.0. You might need to check with pip/PyPI. In any case, between versions 1.1.0 and 2.0.0 I found some major bugs in my module dependency resolution which could cause it to break in various situations. It was shear luck that none of my test codes had broken it before. If you're running an old version of the code, try upgrading it to 2.0.0 or the GitHub version. If the bug still persists, let me know.

[acroucher]

Thanks Chris. I upgraded to the latest version in pip and the fred/bob test above now works.

However FORD still gets the same error on my actual code. I have boiled it down to a simpler example which still fails. There are 3 source files- I have taken all the actual code out of them, leaving pretty much just the use statements:

fson_mpi.F90:

module fson_mpi_module
  use kinds_module
  use mpi_module
  use fson
  implicit none
  private
end module fson_mpi_module

kinds.F90:

module kinds_module
  implicit none
  private  
end module kinds_module

mpi.F90:

module mpi_module
  implicit none
  private
end module mpi_module

Here fson, used by fson_mpi_module, is an external library. If I remove the use fson statement it works.

[cmacmackin]

I'm still not able to reproduce this bug, using either v2.0 of FORD, or my development version. I copied the code samples you've provided here exactly. Would you be able to provide the contents of your project file?

[acroucher]

Here it is:

project: Weird problem
project_dir: ./src
output_dir: ./doc/dev
extensions: F90
extra_vartypes: PetscErrorCode
                MPI_Comm
                PetscMPIInt
                PetscInt
                PetscReal
                PetscScalar
                PetscBool
                Vec
                NormType
                DM
                DMLabel
                PetscSection
                IS
                Mat
                KSP
                SNES
                SNESConvergedReason
Test FORD

However, I just tried taking out the extra_vartypes stuff (which isn't needed for these empty files- but is needed for my actual project), and then it works again. So maybe the problem is really something to do with the new extra_vartypes option?

[cmacmackin]

Okay, that was an embarrassing one on my part. The problem was that ford/toposort were not designed to be able to compare strings to the objects representing Fortran modules. This meant that any modules not included in the code-base (represented as strings) could end up breaking FORD/toposort. Because toposort uses a dictionary, which is an unordered object, sometimes no comparison would be needed between a string and a module and everything would run fine. Other times (somewhat randomly) a comparison would be made and you'd get the error message.

Anyway, moral of the story was that I needed to make sure no strings were being passed to toposort. This is now done and the fixed version is on GitHub. Hopefully I'll be authoring a new release on PyPI soon, which will include the bugfix.

[acroucher]

Thanks very much Chris, will give it a try.

[acroucher]

Strange, I just installed FORD v2.1.0 via PIP, and gave the above problem a try (with the extra_vartypes stuff in the project file), and I'm still getting the exact same error. I've double-checked with pip freeze that I'm running the updated version. Any ideas?

[cmacmackin]

I can't reproduce this at all, in either Python 2.7 or Python 3.4.2. I have absolutely no idea what the problem could be. Are you using any command-line options? The only other thing I can think to suggest as a way forward would be to do a completely fresh install of FORD in a virtualenv and see if that works. I don't know why it would behave any differently, but at least that way we'd know for certain that you are using exactly the same version of all of the packages as I am.

[acroucher]

I just tried uninstalling FORD and installing again, but no difference. The versions of everything I'm using are:

Python: 2.7.3 FORD: 2.1.0 markdown: 2.6.2 markdown-include: 0.5.1 toposort: 1.4 jinja2: 2.7.3 pygments: 2.0.2 beautifulsoup4: 4.3.2 markupsafe: 0.23

Would any of these be likely to cause trouble?

[cmacmackin]

The only difference between what you have and my local install is that I have Python 2.7.9 rather than 2.7.3. I wouldn't have thought that would cause problems, but who knows? I'm not aware of a way to install a previous patch-level release of Python on my system, so that makes testing the differences difficult. The only other route forward is if you could tar up the directory you're doing these tests in and send it to me as is, just to ensure that no changes have crept in since what you posted here. Of course, I understand if you're not willing to do that. Sorry I can't be more help.

[acroucher]

Oops, sorry, this was my fault- I had cloned FORD at some point and still had the directory in my PYTHONPATH. Once I got rid of that, this test example worked fine.

[cmacmackin]

Okay, glad to hear it!

On 22/06/15 11:42 PM, Adrian Croucher wrote:

Oops, sorry, this was my fault- I had cloned FORD at some point and still had the directory in my PYTHONPATH. Once I got rid of that, this test example worked fine.

— Reply to this email directly or view it on GitHub https://github.com/cmacmackin/ford/issues/41#issuecomment-114334239.

Chris MacMackin Saint Mary's University Curriculum Vitae http://ap.smu.ca/%7Ecmacmack/CV.pdf