search

Fortran-FOSS-Programmers / ford

Automatically generates FORtran Documentation from comments within the code.
https://forddocs.readthedocs.io
GNU General Public License v3.0
408 stars 134 forks source link

Support for Fortran 2008/2015 #144

Closed zbeekman closed 8 years ago

zbeekman commented 8 years ago

I'm just curious what the status is here. I'm trying to work on documenting OpenCoarrays with FORD, but I get this error:

rocessing documentation comments...
Correlating information from different parts of your project...
Traceback (most recent call last):
  File "/usr/local/bin/ford", line 11, in <module>
    sys.exit(run())
  File "/usr/local/lib/python2.7/site-packages/ford/__init__.py", line 349, in run
    main(proj_data,proj_docs,md)
  File "/usr/local/lib/python2.7/site-packages/ford/__init__.py", line 311, in main
    project.correlate()
  File "/usr/local/lib/python2.7/site-packages/ford/fortran_project.py", line 141, in correlate
    i = item.index(':')
ValueError: substring not found

I'm wondering if this is cause by some coarray syntax or something similar...

CC: @rouson

rouson commented 8 years ago

@zbeekman I'm not sure where "here" is. What's the OpenCoarrays source file and line that are causing the problem?

zbeekman commented 8 years ago

@rouson : Sorry, I just wanted to CC you on this issue with FORD. I'm asking @cmacmackin if he knows what the status of support for Fortran 2008 and 2015 features is with FORD, because I'm not sure what the source of this FORD processing error is, and am wondering if it could be related to CAF or similar bleeding edge Fortran syntax.

zbeekman commented 8 years ago

OK, sorry for the noise everyone... I had a mistake in my meta-data in the project file... it would be nice if there was a better way to debug FORD, but this was a red-herring.... sorry!

rouson commented 8 years ago

No worries. Thanks for working on this.

cmacmackin commented 8 years ago

I'm interested to know what you mean by "a better way to debug ford". What features, specifically, do you want for this? On 6 Jun 2016 6:15 p.m., "Damian Rouson" notifications@github.com wrote:

No worries. Thanks for working on this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmacmackin/ford/issues/144#issuecomment-224024713, or mute the thread https://github.com/notifications/unsubscribe/AHxJPXsvvM5AE6yoBWh2mYGyrhlYHuz_ks5qJFXDgaJpZM4IvFOE .

zbeekman commented 8 years ago

@cmacmackin I know, I'm pobably your most annoying user... sorry... I didn't offer much by way of suggestions...

Adding --debug is helpful because it shows you the trace for where FORD died. However, it would be nice if there was a way to correlate this with a certain line of your project file, or of some typo/error introduced in the source documentation etc. that triggered FORD to crash/abort. Right now when the back trace is printed it is hard to know which part of the project FORD was processing, or if there were more clues as to what FORD was working on when it died. It does a good job of pointing you to the line in FORD that raised the error, but not necessarily the corresponding line (neighborhood, or file) in your project that triggered the issue.

I know your time is limited, and I am very, very grateful for the hard work you put into FORD. I understand that without more help it is difficult to attend to everyone's wishlist, and bugs, and sincerely apologize if I ever sound ungrateful.

cmacmackin commented 8 years ago

More often than not, the errors which you are catching are bugs in FORD and not an issue with the Fortran per se. That makes it difficult to pin down a line of code--something which would be very hard in any case, as FORD ends up reshaping the code as the first stage of processing, removing white space, comments, etc. Adding a file name to the error message may be doable, however.

On 16-06-06 11:04 PM, Izaak Beekman wrote:

@cmacmackin https://github.com/cmacmackin I know, I'm pobably your most annoying user... sorry... I didn't offer much by way of suggestions...

Adding |--debug| is helpful because it shows you the trace for where FORD died. However, it would be nice if there was a way to correlate this with a certain line of your project file, or of some typo/error introduced in the source documentation etc. that triggered FORD to crash/abort. Right now when the back trace is printed it is hard to know which part of the project FORD was processing, or if there were more clues as to what FORD was working on when it died. It does a good job of pointing you to the line in FORD that raised the error, but not necessarily the corresponding line (neighborhood, or file) in your project that triggered the issue.

I know your time is limited, and I am very, very grateful for the hard work you put into FORD. I understand that without more help it is difficult to attend to everyone's wishlist, and bugs, and sincerely apologize if I ever sound ungrateful.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cmacmackin/ford/issues/144#issuecomment-224102994, or mute the thread https://github.com/notifications/unsubscribe/AHxJPVRMaB2loyyYwXBsNVijfUbnsyWsks5qJJl_gaJpZM4IvFOE.

Chris MacMackin cmacmackin.github.io http://cmacmackin.github.io

rouson commented 8 years ago

On June 6, 2016 at 4:04:48 PM, Izaak Beekman (notifications@github.com) wrote:

I know your time is limited, and I am very, very grateful for the hard work you put into FORD. 

Ditto.  Thanks, @cmacmackin.  FORD is filling a critical need for OpenCoarrays.

Damian