CommentBlock : it is a member of fortran code.
TakaoKotani
Thank you so much for your recent efforts on fparser. fparser really
encouraged me so much.
I did some tests. And look into codes a little by eric4.
-----------
But a problem (unsatisfactory point) for me is on Comment.
In my opinion, the FortranFileReader should not distinguish Comment
from Line.
So, all items in reader should be Line as for normal fortran code
(when codes are gramatically correct) .
CommentBlock should be distinguished by FortranParser as a component
as other classes
on the same footing.
The parser.block.content.blocktype should be CommentBlock for
CommentBlock.
So, could you may make this change soon?
I think it is better to do it soon for future development.
Then I hope you would not skip "C\n","\n" or so in CommentBlock (the
last thing in issue7).
Do you agree?
best regards,
takao kotani
In future, the preprocessor (cpp or fpp) may be included in fparser.
Usually people write fortran codes which have clear block structures
(#if block are nested well in fortran code. I use very limited
function of cpp),
even though fpp is used. So, probably not so difficult.
TakaoKotani
I will somehow manage this.
I looked int torepr in BeginStatement class, and learned how it works.
takao
Pearu Peterson
The Fortran parser is designed such that readfortran parses
comments and line continuations and then parsefortran
carries out the rest of parsing, that is, parses statements
and builds up parser tree.
In applications, such as wrapper generators and code translators,
one does not care much about reproducing exactly the original
codes comments and line continuations. Reproducing
actual Fortran code is crucial. That is why fparser does
not care much about the empty comments and lines.
That said, now I think preserving empty comments might be
important for documentation generator applications.
I'll see if that can be easily fixed..
About preprocessor support in fparser.
If at all, this must be implemented in ppfortran. The original
though was that preprocessing should be carried out before
feeding Fortran code to fparser - this is practical for wrapper
generator and translator applications. I now see that
for documentation generators it might be reasonable to
keep preprocessor directives and implement ppfortran
such that it will produce a tree of preprocessor constructs
that can be evaluated (read: parsing its codelets) when
one specifies preprocessing macros, or just leave the
tree unevaluated (which might mean that parsing codelets
becomes impossible). Anyway, ppfortran should not
affect the readfortran and parsefortran implementations.
Could you write up the corresponding feature request to f2py issues?
Also give a small example that contains all preprocessing
directives that are encountered in your Fortran codes.
Pearu
TakaoKotani
Thank you so much for your reply.
As far as I know , (last year when I was looking around fortran
parser),
I could not find something which is like fparser.
So, I want to emphasize importance of your fparser as a tool to
analyze/rewrite fortran codes.
As a purpose of fortran analyzer, even the empty lines should be kept.
I want to write to you about what I want as a fortran user. But I
have no time today.
I have my package in github, so easy to get it. But not so convenient
for you maybe.
So, Here is a typical case of my usage on fpp.
--------------------------------------
takao@takaot61:~/ecal/lm7K$ grep -n '^#' */symvec.F
1:#define F90 1
2:#define unix 1
41:#if F90
47:#elif POINTER
52:#endif
61:#if unix
63:#endif
64:#if F90
68:#elif POINTER
72:#endif
106:#if F90
115:#elif POINTER
119:#endif
128:#if ! (F90 | POINTER)
130:#endif
132:#if unix
134:#endif
152:#if F90
157:#elif POINTER
163:#endif
--------------------------------------
Don't care what each symbol means.
In my opinion, I guess that fpp thing are used in a very limited way
by ordinary fortran users.
Most of all are rewritten by
...
if (.not.F90_ POINTER_switch()) then
xxxxxx
endif
...
-------
logical function F90_ POINTER_switch()
F90_ POINTER_switch=.true.
end
I think it is not necessary to allow all features of fpp.
(In a few case of my code, a "#if ... #endif block" is not well nested
in a fortran block.
But such a thing can be rewritten so that it is well nested in
fortran blocks itself.).
Anyway, I have to leave today now---my wife is getting angry.
I will write again soon tomorrow or so.
regards,
takao kotani
Omar Awile
I also think that having the comments in the parse tree is a really
useful thing. I actually wrote a fortran documentation generator based
on the legacy f2py code that would take all comments starting with !!!
feed them into asciidoc after adding some more information about
module dependencies and finally generate a pdf or html api
documentation.
So here is a patch I propose.. I don't know.. it's a first attempt and
maybe I am approaching this code still with a bit too much of
naiveté... what do you think Pearu?
best,
omar
--
Omar Awile
Institute of Theoretical Computer Science
ETH Zurich, Universitaetstr. 6, CAB G39.3
CH-8092 Zurich, Switzerland
Tel: +41 44 632 92 74
GPG: http://www.inf.ethz.ch/personal/oawile/gpg/
> --
> You received this message because you are subscribed to the Google Groups "F2PY Developers" group.
> To post to this group, send email to f2py...@googlegroups.com.
> To unsubscribe from this group, send email to f2py-dev+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/f2py-dev?hl=en.
>
>
Pearu Peterson
The patch is working for comments consisting of one line.
I have commited a patch to f2py svn, see
http://code.google.com/p/f2py/source/detail?r=23#
that processes also multiline comments. For example,
{{{
from fparser.api import parse
source_str = '''
!comment line 1
!comment line 2
module foo
!comment line 3
subroutine f
!comment line 4
end subroutine f
end module foo
'''
tree = parse(source_str, isfree=True, isstrict=False,
ignore_comments=False)
print tree
}}}
will display
{{{
!comment line 1
!comment line 2
MODULE foo
!comment line 3
SUBROUTINE f()
!comment line 4
END SUBROUTINE f
END MODULE foo
}}}
That is, randomly aligned comments are now aligned according to
the structure of Fortran code.
Note the usage of `ignore_comments=False` in parse call.
Is that what you are looking for from parsing comments?
Regards,
Pearu
On Mar 16, 8:48 pm, Omar Awile <omar.aw...@gmail.com> wrote:
> Hey all,
>
> I also think that having the comments in the parse tree is a really
> useful thing. I actually wrote a fortran documentation generator based
> on the legacy f2py code that would take all comments starting with !!!
> feed them into asciidoc after adding some more information about
> module dependencies and finally generate a pdf or html api
> documentation.
> So here is a patch I propose.. I don't know.. it's a first attempt and
> maybe I am approaching this code still with a bit too much of
> naiveté... what do you think Pearu?
>
> best,
>
> omar
> --
> Omar Awile
> Institute of Theoretical Computer Science
> ETH Zurich, Universitaetstr. 6, CAB G39.3
> CH-8092 Zurich, Switzerland
> Tel: +41 44 632 92 74
> GPG:http://www.inf.ethz.ch/personal/oawile/gpg/
>
> f2py_comment.patch
> < 1KViewDownload
Omar Awile
works like a charm!
Yeah, I thought all comment lines where already stored in that one
"line" variable, and didn't check thoroughly...
thanks!
omar
--
Omar Awile
Institute of Theoretical Computer Science
ETH Zurich, Universitaetstr. 6, CAB G39.3
CH-8092 Zurich, Switzerland
Tel: +41 44 632 92 74
GPG: http://www.inf.ethz.ch/personal/oawile/gpg/