Crash with macro about ford HOT 49 CLOSED

Probably a little bit off-topic, but some of you may be interested: I've released the BSD-licensed Fortran preprocessor Fypp. It's written in Python, it can be either used as command line tool or embedded into Python programs, so theoretically, even Ford could support it natively. 😄

from ford.

@szaghi Dear Stefano, thanks, see my answer on Google Groups. As for migrating the repo to github: At the moment, I have all my own projects on bitbucket (they were the only one offering unlimited private repos for academia when I first looked around for git-hosting), so I'd prefer to keep it primarily there. But, if one has a google account, registering on bitbucket is just one click, so I hope, that won't keep anybody from contributing. 😄

from ford.

One of the many (many) things which I will do for the next feature release--once I've finally finished some work on other projects--will be to allow the user to specify an arbitrary preprocessor command. This is the only practical option for me as FORD's maintainer, given the number of different preprocessors out there, is to not show any preference, other than letting the default be GNU's implementation of CPP. I feel that this is sufficiently standard that it is a reasonable choice for a default.

Fypp looks interesting. I too am not convinced by the colons. You mention that breaking CPP compatibility has advantages such as being able to "substitute a macro or a variable within a string." However, I'd consider that not so much breaking compatibility as offering an extension--much as Fortran compilers all have their own extensions while still being considered standard-compliant compilers. Perhaps one choice would be to allow all commands which are in common with CPP to work with or without the semicolon.

In any case, those quibbles aside, Fypp does look very useful. One question I have is whether it supports multiline macros. Much of that functionality could be imitated with loops, but a multiline macro could still be useful in many circumstances. I consider the lack of these to be one of the greatest shortcomings of CPP. Something else I'm wondering is whether Fypp generates line markers (#line ...). Without these, dealing with compile-time errors in preprocessed files can be incredibly painful.

from ford.

I would opt for having a customizable general preprocessing command. While many Fortran projects use CPP preprocessor directives, some others are based on other preprocessors (like coco or m4). Therefore, allowing the user to pass the entire preprocessor command iine (including macro definitions), would be needed to cover all those cases. (Also, CPP is for sure not optimal for preprocessing Fortran, so maybe even from the didactical point of view, one shouldn't promote it too much by making it the only choice 😄)

from ford.

@aradi Cool looking project!

I must note, however, that as far as there is any "standard" preprocessing for Fortran, the syntax of your preprocessor statements seems to be very exotic.

Due to the lack of standardization of preprocessing and Fortran, I don't think any one special preprocessor should be built into FORD. The most practical solution, IMO, is to let the user specify some arbitrary command to be run as a preprocessor on the source code.

from ford.

Sure, the suggestion to put Fypp inside Ford was only half serious. Preprocessing the sources by a custom command before passing them to Ford is usually fine. However, if a library also provided macros/templates, they could not be documented that way.

As for the exotic syntax of Fypp: Indeed it differs considerably from the cpp/fpp syntax as it was more inspired by templating engines. The colons could be easily removed, but they offer a visual aid to distinguish between full line and inline directives (latter not supported by cpp). As for the rest, consistency and minimization of the chance to accidently collide with a valid Fortran statement (Fypp does not understand Fortran) had higher priority. But breaking cpp compatibility has also advantages: You can for example substitute a macro or a variable within a string, which does not work in cpp...

from ford.

Fair enough. It's a pity I didn't discover this a couple of weeks earlier, before I wrote ~1000 lines of incredibly tedious and repetitive code.

from ford.

I'm getting exactly this error on my code too (thanks for putting the minimal example together- that's saved me from doing it!) I have got preprocessor macros in my code as well.

from ford.

Okay, I know what would be causing the error message and how to ensure that it doesn't show up. What it comes down to is that FORD doesn't recognize pre-processor directives--it treats them like comments. Because of this, FORD wasn't able to match the type-binding to the corresponding subroutine. When the template system tried to access information about the subroutine it found that this information did not exist.

The quick fix will be to add checks which ensure FORD won't try to access information which doesn't exist. This is a good safety feature in any case. However, that will mean that your code won't get proper documentation for these type-bound procedures. Obviously that is problematic. The obvious way to fix these issues would be to preprocess the file first and then extract documentation from the preprocessed version. As someone who has never used a preprocessor, I'm not sure whether or not that would be the best way to approach documentation. Any thoughts?

As for how to do that, I can see two approaches:

• Pipe a call to cpp and parse the results. This issue with this is that when I ran cpp for your sample code it gave the following output. As you can see, the substitution wasn't done correctly, as there is an extra space present.

module blah_module

private



    type,public :: blah
        !! blah
    contains
        generic,public :: info => blah_info , wrap_ blah_info !blah blah blah
        procedure :: blah_info , wrap_ blah_info
    end type blah

    contains

    subroutine blah_info(me,i)
    !! blah info
    class(blah),intent(in) :: me
    integer,intent(in) :: i
    end subroutine blah_info

    subroutine wrap_blah_info(me,r)
    !! wrap blah info
    class(blah),intent(in) :: me
    real,intent(in) :: r
    end subroutine wrap_blah_info

end module blah_module

• Make calls to @szaghi's PreForM. This has the advantage of keeping everything internal to Python, but I don't think it implements all of the CPP directives.

from ford.

@cmacmackin: Try giving the source code a Capital .F90 extension and run it through gfortran with the -E flag:

# 1 "pptest.F90"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pptest.F90"
module blah_module

private



    type,public :: blah
        !! blah
    contains
        generic,public :: info => blah_info , wrap_blah_info  !blah blah blah
        procedure :: blah_info , wrap_blah_info
    end type blah

    contains

    subroutine blah_info(me,i)
    !! blah info
    class(blah),intent(in) :: me
    integer,intent(in) :: i
    end subroutine blah_info

    subroutine wrap_blah_info(me,r)
    !! wrap blah info
    class(blah),intent(in) :: me
    real,intent(in) :: r
    end subroutine wrap_blah_info

end module blah_module

from ford.

Okay, that works. I was trying to run it through the cpp command, which didn't for some reason. Does my proposal (preprocessing the code before extracting documentation) sound reasonable?

from ford.

@cmacmackin I guess to elaborate further, it might be prudent to allow the user to pass the intended preprocessor command to FORD, or, as you suggest, just run FORD on the output of the preprocessor, since standards are quite lacking. For example, there are differences on how gfortran chooses to preprocess and how intel’s fpp preprocess and how cpp does it… The concatenation example that @jacobwilliams posted is used in json-fortran to work around some compiler differences for ISO_10646 (Unicode) support. Annoyingly, the preprocessor concatenation syntax/support differs between gfortran and ifort.

The reason json-fortran needs this is that if the compiler supports Unicode, interfaces need to be overloaded so that users can pass normal literal string constants. If there is no Unicode/ISO_10646 support then the extra routines will either a) have the same signatures and collide, or b) will have an unsupported type and thus also cause compilation errors. So the only solution is conditional compilation.

from ford.

Yes I would say the best short term fix is to make the parsing more robust, and maybe issue a warning if preprocessor directives are used. Then either make it mandatory that the source code is preprocessed first or provide a means of passing the preprocessor command and arguments/defines to FORD which can then invoke it.

It would be preferable to eventually teach FORD about the notions of preprocessor directives, since the generated documentation, if run on the preprocessed source code, will be documenting an intermediate product rather than the source code used by the developers of the project. The current setup is beneficial, perhaps, for client code and public APIs, but cumbersome for internal documentation and development.

from ford.

I'm certainly open to that, but I'm not sure what it would mean for the appearance of the documentation. Without that it is difficult for me to implement it! Would you be able to point me towards any documentation (from Doxygen, perhaps) which accounts for preprocessor directives such as these? It need to be a Fortran project.

from ford.

Well, I guess my point is that #defines may need some documentation if they implement macro expansion and places where macros are expanded (as in the json-fortran macro usage) may need extra care to be handled gracefully, but, in general, the onus of dealing with macros should be left almost entirely to the programmer, since there is no agreed upon standard. #defines and #includes are really the only common element that seem to be universal among preprocessors.

To document #defines I think you could parse the #define line to extract the name of the definition and documentation below it. (Or above it if using pre-doc-mark) A regexp would be relatively simple to extract the names of macros and defines: something like ^[ \t]*\#define \([a-zA-Z_][a-zA-Z0-9_]*\)[ (] should work to pull them out. The name is the stuff between \( and \)… Below these you could look for comments in the usual manner:

#define MACRO(PROCEDURE) PROCEDURE , wrap_/**/PROCEDURE
!! preprocessor macro that wraps procedures taking string arguments and adds
!! them to overloaded interfaces when ISO_10646 support is detected

Or you could use a special sentinel like !# to denote preprocessor documentation so it can be excluded from processing sources that have already been pre-processed… just brainstorming here.

Another idea is to use the macro name parsed using the regexp to examine other text that FORD treats specially. In the above example the type-bound procedure bindings seem—to my admittedly untrained eye—to be the cause of the crash. If FORD knew that MACRO was a macro created with a #define then, even if FORD can’t understand and expand the macro, FORD could link/reference back to the macro definition, without attempting to resolve the TBPs. (Indeed, that is the whole point of macros, allowing expansion at compile time to multiple or user defined values, so there is no hope of anticipating what the expansions will be, nor is there a need for this.)

As for good examples of projects using pre-processing directives, Fortran AND documentation generators, sadly I know of none…

from ford.

Sorry, I meant to say that an example need NOT be a Fortran program. I made a typo. Thanks for the other information. I don't really know what the appropriate action would be. For the moment I'll just look at running it through the preprocessor before extracting documentation.

from ford.

I've gotten an initial implementation of preprocessing capabilities added to FORD. However, I'm not sure what the best options are for this. Should the user provide a list of file-extensions to preprocess? Or I could just have FORD preprocess any files with a capital F in the extension.

from ford.

AFAIK most compilers treat capital F files as needed preprocessing (I know at least Intel and GFortran do this) so that option is suitable for me.

from ford.

I know that is the standard, but it can be overridden with compiler flags. That said, the simplicity of just using the capital letters in FORD has much to commend it.

from ford.

You can always add an option later to change the behavior, say with a command line argument.

from ford.

A version of FORD with preprocessing capabilities is now available on PyPI.

from ford.

I just upgraded to FORD 3 and tried this. It seems to go fine on my code. It does produce a "Warning: error preprocessing filename.F90" message for every one of my source files, but the output documentation seems to be fine, as far as I can see. Thanks!

from ford.

You got that message because at some point the preprocessor wrote something to stderr. If you want to try to figure out what the error is, add the line print(err) just after line 63 of reader.py.

from ford.

AFAICT this bug is fixed in the latest release… is the issue ready to be closed?

from ford.

I've kept it open to remind me to look at making FORD more aware of precompiler syntax, as discussed above. It's not on the immediate horizon, but it's something I should tackle at some point.

from ford.

6 month laters...
Currently, it seems that gfortran is used for preprocessing by FORD. I would suggest to check for cpp as a fallback if gfortran is not present. Currently, gfortran uses cpp as preprocessor... in traditional mode (as pointed in the doc). Thus in order to get the same result as gfortran for preprocessing one should call cpp with the option: -traditional-cpp.

IMHO I think that cpp should be directly used instead of gfortran. The latter is not systematically installed on OS (I mean linux-like of course) while cpp is. Thus for someone who uses another compiler than gfortran, FORD could at least try to perform the preprocessing. Such implementation should be done easily.
Now maybe in a future release you could add a cpp_command option in the project file to point the full command to use for preprocessing ?

from ford.

I'll take a look at it. I remember that when I added this feature I had
looked at using CPP but couldn't get it to generate the same sort of
output as gfortran. It may be that I had forgotten the -traditional-cpp
flag.

On 16-01-13 07:00 PM, Jérémie Burgalat wrote:

6 month laters...
Currently, it seems that gfortran is used for preprocessing by FORD. I
would suggest to check for cpp as a fallback if gfortran is not
present. Currently, gfortran uses cpp as preprocessor
https://gcc.gnu.org/onlinedocs/gfortran/Preprocessing-and-conditional-compilation.html#Preprocessing-and-conditional-compilation...
in traditional mode (as pointed in the doc). Thus in order to get the
same result as gfortran for preprocessing one should call cpp with the
option: |-traditional-cpp|.

IMHO I think that cpp should be directly used instead of gfortran. The
latter is not systematically installed on OS (I mean linux-like of
course) while cpp is. Thus for someone who uses another compiler than
gfortran, FORD could at least try to perform the preprocessing. Such
implementation should be done easily.
Now maybe in a future release you could add a |cpp_command| option in
the project file to point the /full/ command to use for preprocessing ?

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

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

from ford.

I have made the test yesterday for the example provided in the issue:
gfortran -ccp -E blah.F90 gives the same results as cpp -traditional-cpp -E blah.F90 😄.

from ford.

👍

from ford.

I agree with Aradi. However having a fallback to cpp seems to be , IMHO, an acceptable choice. In such case, macro definitions should be deported from the command-line.
To be continued.

from ford.

I'm late to the party, just want to say "me too". Is the consensus that I should preprocess first, generate documentation later, or is this something that will be implemented in the immediate future?

from ford.

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

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

from ford.

So am I doing something strange then? I like to split large files into small ones (since not all compilers can inline from other modules) by something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file, it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

from ford.

Do your files use the F90 (note capital F) extension? The preprocessor
is only run if on F90 files, and not on f90 files.

On 18/03/16 09:42, Olle Hellman wrote:

So am I doing something strange then? I like to split large files into
small ones (since not all compilers can inline from other modules) by
something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file,
it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198280308

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

from ford.

Thanks, that works. Awesome. Now I just have to rewrite all the makefiles, but that is still no work at all compared to getting doxygen to play nice.

Really nice piece of software by the way, do you want me to cite it somehow?

On 18 March 2016 at 02:47:41, Chris MacMackin ([email protected]) wrote:

Do your files use the F90 (note capital F) extension? The preprocessor
is only run if on F90 files, and not on f90 files.

On 18/03/16 09:42, Olle Hellman wrote:

So am I doing something strange then? I like to split large files into
small ones (since not all compilers can inline from other modules) by
something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file,
it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198280308

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

from ford.

Thanks! There aren't any papers on FORD, so I'm not sure how you'd go
about citing it. It automatically adds a note to the footer in the
documentation advertising itself, so no need to reference it there. If
you want to mention it in a README or something then you can just
provide a link to the GitHub repository.

On 16-03-18 10:02 AM, Olle Hellman wrote:

Thanks, that works. Awesome. Now I just have to rewrite all the
makefiles, but that is still no work at all compared to getting
doxygen to play nice.

Really nice piece of software by the way, do you want me to cite it
somehow?

On 18 March 2016 at 02:47:41, Chris MacMackin
([email protected]) wrote:

Do your files use the F90 (note capital F) extension? The preprocessor
is only run if on F90 files, and not on f90 files.

On 18/03/16 09:42, Olle Hellman wrote:

So am I doing something strange then? I like to split large files into
small ones (since not all compilers can inline from other modules) by
something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file,
it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198280308

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198287931

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

from ford.

And while I am barraging you with comments, I found the following issue: I have

type A

type B, extends A

type C, abstract, extends A

type D, extends C

In the inheritance graph, only A and B are seen, with the proper inheritance. D is shown as it’s own thing, but with no inheritance. C is not seen at all in the documentation. Is this the desired output?

Regards,

/Olle

On 18 March 2016 at 03:11:27, Chris MacMackin ([email protected]) wrote:

Thanks! There aren't any papers on FORD, so I'm not sure how you'd go
about citing it. It automatically adds a note to the footer in the
documentation advertising itself, so no need to reference it there. If
you want to mention it in a README or something then you can just
provide a link to the GitHub repository.

On 16-03-18 10:02 AM, Olle Hellman wrote:

Thanks, that works. Awesome. Now I just have to rewrite all the
makefiles, but that is still no work at all compared to getting
doxygen to play nice.

Really nice piece of software by the way, do you want me to cite it
somehow?

On 18 March 2016 at 02:47:41, Chris MacMackin
([email protected]) wrote:

Do your files use the F90 (note capital F) extension? The preprocessor
is only run if on F90 files, and not on f90 files.

On 18/03/16 09:42, Olle Hellman wrote:

So am I doing something strange then? I like to split large files into
small ones (since not all compilers can inline from other modules) by
something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file,
it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198280308

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198287931

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

from ford.

This really belongs on its own thread. There was previously an issue
with some types not showing inheritance in the graphs, but I thought I
had fixed that with the latest version. Run ford --version to check
the version. The latest is v4.5.2. If you are on the latest version and
the problem persists, then you can try cloning the spoof branch of the
repository and installing that in a virtualenv by running pip install --editable . in the root directory of the repository. That branch
contains some bug fixes which I have yet to author a release for.

On 18/03/16 10:24, Olle Hellman wrote:

And while I am barraging you with comments, I found the following
issue: I have

type A

type B, extends A

type C, abstract, extends A

type D, extends C

In the inheritance graph, only A and B are seen, with the proper
inheritance. D is shown as it’s own thing, but with no inheritance. C
is not seen at all in the documentation. Is this the desired output?

Regards,

/Olle

On 18 March 2016 at 03:11:27, Chris MacMackin
([email protected]) wrote:

Thanks! There aren't any papers on FORD, so I'm not sure how you'd go
about citing it. It automatically adds a note to the footer in the
documentation advertising itself, so no need to reference it there. If
you want to mention it in a README or something then you can just
provide a link to the GitHub repository.

On 16-03-18 10:02 AM, Olle Hellman wrote:

Thanks, that works. Awesome. Now I just have to rewrite all the
makefiles, but that is still no work at all compared to getting
doxygen to play nice.

Really nice piece of software by the way, do you want me to cite it
somehow?

On 18 March 2016 at 02:47:41, Chris MacMackin
([email protected]) wrote:

Do your files use the F90 (note capital F) extension? The preprocessor
is only run if on F90 files, and not on f90 files.

On 18/03/16 09:42, Olle Hellman wrote:

So am I doing something strange then? I like to split large files into
small ones (since not all compilers can inline from other modules) by
something like

#include "pbe_qs.f90"

and FORD does not like that. If I manually paste the code in the file,
it works fine. Is there something magical I have to do?

/Olle

It already does that, although in future I may change FORD to be
able to
use arbitrary preprocessors rather than just GNU's implementation of
CPP. The reason I keep this issue open is in case I ever get to the
point where FORD can provide documentation for the actual macros.

On 16-03-18 09:37 AM, Olle Hellman wrote:

I'm late to the party, just want to say "me too". Is the consensus
that I should preprocess first, generate documentation later, or is
this something that will be implemented in the immediate future?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

https://github.com/cmacmackin/ford/issues/45#issuecomment-198277005

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198280308

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198287931

Chris MacMackin
cmacmackin.github.io http://cmacmackin.github.io
—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/cmacmackin/ford/issues/45#issuecomment-198296446

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

from ford.

Hi,

I got it to work with the spoof branch, great!

However, it might have been not a bug at all. In the A>B>C inheritance, B was private, whereas A and C where public. When I made all of it public, I got the proper inheritance. Is this the desired behaviour?

from ford.

In FORD, you specify what is to be shown (public, private, and/or protected entities) using the display setting in the project file. If an entity has a visibility which is not set to be displayed then it will be removed from the output (after things like type-bindings have been processed). That would be why the inheritance is not showing the way you wanted. I confess that I hadn't considered the possibility of a public type inheriting from a private type. You wouldn't be able to access any of the methods of the private type vias the public type in that case, no? This is a case where it is ambiguous how best to display the output. I guess, ideally, I would display the private type in the inheritance graph but it wouldn't be a link to anything. Unfortunately, I don't think this will be in the upcoming bug-fix release.

If you would simply like to display private entities in addition to public ones, just add

display: public
         protected
         private

to the metadata in your project file.

from ford.

@aradi Dear Bálint, I see your advice on Google group: it is very interesting, thank you very much. I was developing a similar tool (https://github.com/szaghi/PreForM), but your is surely superior. I will study it as soon as possible.

Thank you very much for sharing your work!

P.S. is there any chance to migrate it from bitbucket to here on github?

from ford.

@aradi Sure, I am just very lazy... I will create a bitbucket account!

Thank you again!

from ford.

@zbeekman I agree with Zaak (it is so frustrating that Zaak is so wise... 😄 )

from ford.

For sure Fypp supports multiline macros and line numbering directives. Actually, apart of the loops, those two features were the main reason to write yet an other preprocessor and not using whatever is available already there.

As for extending cpp: I was considering a lot to do so at the beginning. However (inspired by pyratemp), I wanted Fypp to consistently use Python expressions everywhere, and that already breaks cpp-compatibllity. (Python expressions are so powerful, it would be a shame to use a rather dumb domain specific language instead.) Of course, if the colon is the only concern preventing folks to use Fypp, I can allow for an abbreviated syntax without the colons, so that Fypp directives look more like cpp ones, but they still won't be cpp compatible.

Also, if you really want to be cpp compatible, you would have to use a lexer to parse the full Fortran source code, which I definitely wanted to avoid. It would have been tedious (and I wanted a compact standalone Python script), and we would be back to some annoying limitations of cpp again. (Try to write an assert() macro in cpp, which not just reports the line of the assertion, but also the condition which was not fulfilled. In Fypp it is a no-brainer, in cpp, as far as I can see, impossible.)

from ford.

@cmacmackin

...before I wrote ~1000 lines of incredibly tedious and repetitive code...

Factual rocks!

from ford.

@szaghi
Wait until I have it actually working before giving any praise!

from ford.

@cmacmackin It's never too late to purify your code 😄

from ford.

@cmacmackin I've implemented a customizable preprocessor option for Ford, see pull request #129

from ford.

I think this is fixed/implemented

from ford.