Hi,

i am facing 20,000 lines of code. I inherited them from a former phd
student who wrote the code but didn't care to show the structure of
what he wrote. Now i have to guess what the dependencies are, i mean,
what the main program is and how the subroutines are connected to each
other.

I wonder if there is a software/technicque that helps me do that in
Fortran. I accept any ideas. I hope you understand my inquiry.
Regards,


Victor

On Jun 14, 6:09=A0pm, VICTOR <victor.hera...@gmail.com> wrote:
> Hi,
>
> i am facing 20,000 lines of code. I inherited them from a former phd
> student who wrote the code but didn't care to show the structure of
> what he wrote. Now i have to guess what the dependencies are, i mean,
> what the main program is and how the subroutines are connected to each
> other.
>
> I wonder if there is a software/technicque that helps me do that in
> Fortran. I accept any ideas. I hope you understand my inquiry.
> Regards,
>
> Victor

If it's Fortran 77, you can look at http://pcbunn.cithep.caltech.edu/jjb/fl=
oppy.html

Regards,

Mike Metcalf

On Jun 14, 8:02=A0pm, m_b_metcalf <michaelmetc...@compuserve.com> wrote:
> On Jun 14, 6:09=A0pm, VICTOR <victor.hera...@gmail.com> wrote:
>
> > Hi,
>
> > i am facing 20,000 lines of code. I inherited them from a former phd
> > student who wrote the code but didn't care to show the structure of
> > what he wrote. Now i have to guess what the dependencies are, i mean,
> > what the main program is and how the subroutines are connected to each
> > other.
>
> > I wonder if there is a software/technicque that helps me do that in
> > Fortran. I accept any ideas. I hope you understand my inquiry.
> > Regards,
>
> > Victor
>
> If it's Fortran 77, you can look athttp://pcbunn.cithep.caltech.edu/jjb/f=
loppy.html
>
> Regards,
>
> Mike Metcalf

Thank you. I am dad to tell it's fortran 90. A funny thing: he old me
to read about subroutines in the first chapter of a book. I forgtot to
mention what he should have done. Funny isn't it ?

On Jun 14, 9:09=A0am, VICTOR <victor.hera...@gmail.com> wrote:
> Hi,
>
> i am facing 20,000 lines of code. I inherited them from a former phd
> student who wrote the code but didn't care to show the structure of
> what he wrote. Now i have to guess what the dependencies are, i mean,
> what the main program is and how the subroutines are connected to each
> other.
>
> I wonder if there is a software/technicque that helps me do that in
> Fortran. I accept any ideas. I hope you understand my inquiry.
> Regards,
>
> Victor

I wonder if Doxygen can help.  The Doxygen web page says, "You can
configure doxygen to extract the code structure from undocumented
source files."  See http://www.stack.nl/~dimitri/doxygen/.

Damian

On 15 jun, 06:50, Damian <dam...@rouson.net> wrote:
> On Jun 14, 9:09=A0am, VICTOR <victor.hera...@gmail.com> wrote:
>
> > Hi,
>
> > i am facing 20,000 lines of code. I inherited them from a former phd
> > student who wrote the code but didn't care to show the structure of
> > what he wrote. Now i have to guess what the dependencies are, i mean,
> > what the main program is and how the subroutines are connected to each
> > other.
>
> > I wonder if there is a software/technicque that helps me do that in
> > Fortran. I accept any ideas. I hope you understand my inquiry.
> > Regards,
>
> > Victor
>
> I wonder if Doxygen can help. =A0The Doxygen web page says, "You can
> configure doxygen to extract the code structure from undocumented
> source files." =A0Seehttp://www.stack.nl/~dimitri/doxygen/.
>
> Damian

Yes, it does that by generating call trees. The output can be in the
form of HTML pages showing the headers of the routines and the list of
routines that it calls and vice versa. (A colleague showed some
results
of DOXYGEN last week - I have not used it myself yet)

Regards,

Arjen

In article <f3b8a37f-f65c-4fa6-b278-da2e99a60d83@p6g2000pre.googlegroups.com>,
Damian  <damian@rouson.net> wrote:
>
>I wonder if Doxygen can help.  The Doxygen web page says, "You can
>configure doxygen to extract the code structure from undocumented
>source files."  See http://www.stack.nl/~dimitri/doxygen/.

And it squares circles, whitens your teeth and makes you irresistable
to the opposite sex.

That claim is obviously impossible to deliver.  However, it MAY be
able to extract the call chain, which is a feasible task.  It also
isn't hard to write a crude parser that will do the job, though is
a little painful if you have to be able to detect functions that
are declared as such merely by being called.

Alternatively, and this is the way I would proceed, split the code
apart into modules and procedures, compile each separately and use
nm or elfdump on the object files.  The write a program to display
that conveniently.  Tedious, but not difficult.


Regards,
Nick Maclaren.

On 15 jun, 09:13, n...@cam.ac.uk wrote:
> In article <f3b8a37f-f65c-4fa6-b278-da2e99a60...@p6g2000pre.googlegroups.=
com>,
>
> Damian =A0<dam...@rouson.net> wrote:
>
> >I wonder if Doxygen can help. =A0The Doxygen web page says, "You can
> >configure doxygen to extract the code structure from undocumented
> >source files." =A0Seehttp://www.stack.nl/~dimitri/doxygen/.
>
> And it squares circles, whitens your teeth and makes you irresistable
> to the opposite sex.
>
> That claim is obviously impossible to deliver. =A0However, it MAY be
> able to extract the call chain, which is a feasible task. =A0It also
> isn't hard to write a crude parser that will do the job, though is
> a little painful if you have to be able to detect functions that
> are declared as such merely by being called.
>
> Alternatively, and this is the way I would proceed, split the code
> apart into modules and procedures, compile each separately and use
> nm or elfdump on the object files. =A0The write a program to display
> that conveniently. =A0Tedious, but not difficult.
>
> Regards,
> Nick Maclaren.

DOYGEN is capable of generating call graphs (for each routine:
which routines are called, by which routines is it called itself).
I am not quite sure what it can do with functions that are not
explicitly declared, but it seems to be a nice enough tool.

Regards,

Arjen

In article <c29a003d-d24c-496a-b13f-d2703f212fdf@k2g2000yql.googlegroups.com>,
Arjen Markus  <arjen.markus@wldelft.nl> wrote:
>
>DOYGEN is capable of generating call graphs (for each routine:
>which routines are called, by which routines is it called itself).
>I am not quite sure what it can do with functions that are not
>explicitly declared, but it seems to be a nice enough tool.

As I said.

What it CANNOT do is to "extract the code structure from undocumented
source files."  Whether it does anything sensible with procedures
passed as arguments, I don't know,, but it assuredly cannot do
anything useful with programs that use procedure variables in
arbitrary ways.  To achieve that, it would have to solve the halting
problem.

My objection is to its hype, not its functionality.


Regards,
Nick Maclaren.

Arjen Markus schreef:
> On 15 jun, 09:13, n...@cam.ac.uk wrote:
>> In article <f3b8a37f-f65c-4fa6-b278-da2e99a60...@p6g2000pre.googlegroups.com>,
>>
>> Damian  <dam...@rouson.net> wrote:
>>
>>> I wonder if Doxygen can help.  The Doxygen web page says, "You can
>>> configure doxygen to extract the code structure from undocumented
>>> source files."  Seehttp://www.stack.nl/~dimitri/doxygen/.
>> And it squares circles, whitens your teeth and makes you irresistable
>> to the opposite sex.
>>
>> That claim is obviously impossible to deliver.  However, it MAY be
>> able to extract the call chain, which is a feasible task.  It also
>> isn't hard to write a crude parser that will do the job, though is
>> a little painful if you have to be able to detect functions that
>> are declared as such merely by being called.
>>
>> Alternatively, and this is the way I would proceed, split the code
>> apart into modules and procedures, compile each separately and use
>> nm or elfdump on the object files.  The write a program to display
>> that conveniently.  Tedious, but not difficult.
>>
>> Regards,
>> Nick Maclaren.
> 
> DOYGEN is capable of generating call graphs (for each routine:
> which routines are called, by which routines is it called itself).
> I am not quite sure what it can do with functions that are not
> explicitly declared, but it seems to be a nice enough tool.
> 
> Regards,
> 
> Arjen
Arjen,


Which version of doxygen do you use?

I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I 
used the rpm.

So I only use the style file.


Kind regards,


Jan Gerrit Kootstra

On 15 jun, 11:36, Jan Gerrit Kootstra <jan.ger...@kootstra.org.uk>
wrote:
> Arjen Markus schreef:
>
>
>
> > On 15 jun, 09:13, n...@cam.ac.uk wrote:
> >> In article <f3b8a37f-f65c-4fa6-b278-da2e99a60...@p6g2000pre.googlegrou=
ps.com>,
>
> >> Damian =A0<dam...@rouson.net> wrote:
>
> >>> I wonder if Doxygen can help. =A0The Doxygen web page says, "You can
> >>> configure doxygen to extract the code structure from undocumented
> >>> source files." =A0Seehttp://www.stack.nl/~dimitri/doxygen/.
> >> And it squares circles, whitens your teeth and makes you irresistable
> >> to the opposite sex.
>
> >> That claim is obviously impossible to deliver. =A0However, it MAY be
> >> able to extract the call chain, which is a feasible task. =A0It also
> >> isn't hard to write a crude parser that will do the job, though is
> >> a little painful if you have to be able to detect functions that
> >> are declared as such merely by being called.
>
> >> Alternatively, and this is the way I would proceed, split the code
> >> apart into modules and procedures, compile each separately and use
> >> nm or elfdump on the object files. =A0The write a program to display
> >> that conveniently. =A0Tedious, but not difficult.
>
> >> Regards,
> >> Nick Maclaren.
>
> > DOYGEN is capable of generating call graphs (for each routine:
> > which routines are called, by which routines is it called itself).
> > I am not quite sure what it can do with functions that are not
> > explicitly declared, but it seems to be a nice enough tool.
>
> > Regards,
>
> > Arjen
>
> Arjen,
>
> Which version of doxygen do you use?
>
> I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I
> used the rpm.
>
> So I only use the style file.
>
> Kind regards,
>
> Jan Gerrit Kootstra- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

I saw a demonstration by a colleague last week. He used version 1.5.9
on
Windows and that works fine.

I have tried it myself just now: you have to set a bunch of
configuration
options and it does not seem to like .f files very much, but it does
extract information in modules.

I am just experimenting right now and I will have to ask my colleague
what options he used exactly ...

Regards,

Arjen

On 15 jun, 14:35, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> On 15 jun, 11:36, Jan Gerrit Kootstra <jan.ger...@kootstra.org.uk>
> wrote:
>
>
>
>
>
> > Arjen Markus schreef:
>
> > > On 15 jun, 09:13, n...@cam.ac.uk wrote:
> > >> In article <f3b8a37f-f65c-4fa6-b278-da2e99a60...@p6g2000pre.googlegr=
oups.com>,
>
> > >> Damian =A0<dam...@rouson.net> wrote:
>
> > >>> I wonder if Doxygen can help. =A0The Doxygen web page says, "You ca=
n
> > >>> configure doxygen to extract the code structure from undocumented
> > >>> source files." =A0Seehttp://www.stack.nl/~dimitri/doxygen/.
> > >> And it squares circles, whitens your teeth and makes you irresistabl=
e
> > >> to the opposite sex.
>
> > >> That claim is obviously impossible to deliver. =A0However, it MAY be
> > >> able to extract the call chain, which is a feasible task. =A0It also
> > >> isn't hard to write a crude parser that will do the job, though is
> > >> a little painful if you have to be able to detect functions that
> > >> are declared as such merely by being called.
>
> > >> Alternatively, and this is the way I would proceed, split the code
> > >> apart into modules and procedures, compile each separately and use
> > >> nm or elfdump on the object files. =A0The write a program to display
> > >> that conveniently. =A0Tedious, but not difficult.
>
> > >> Regards,
> > >> Nick Maclaren.
>
> > > DOYGEN is capable of generating call graphs (for each routine:
> > > which routines are called, by which routines is it called itself).
> > > I am not quite sure what it can do with functions that are not
> > > explicitly declared, but it seems to be a nice enough tool.
>
> > > Regards,
>
> > > Arjen
>
> > Arjen,
>
> > Which version of doxygen do you use?
>
> > I did not get version 1.4.7 to work on Red Hat Enterprise Linux 5.3. I
> > used the rpm.
>
> > So I only use the style file.
>
> > Kind regards,
>
> > Jan Gerrit Kootstra- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -
>
> I saw a demonstration by a colleague last week. He used version 1.5.9
> on
> Windows and that works fine.
>
> I have tried it myself just now: you have to set a bunch of
> configuration
> options and it does not seem to like .f files very much, but it does
> extract information in modules.
>
> I am just experimenting right now and I will have to ask my colleague
> what options he used exactly ...
>
> Regards,
>
> Arjen- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Ah, the secret is in the \file comment: include something like

! ! \file filename.f

in the source files to get DOXYGEN to parse them and produce an
overview
of the routines it contains. That is the minimum requirement it seems
(unless
it contains modules).

Regards,

Arjen

<nmm1@cam.ac.uk> wrote in message 
news:h152nk$stu$1@smaug.linux.pwf.cam.ac.uk...
> In article 
> <c29a003d-d24c-496a-b13f-d2703f212fdf@k2g2000yql.googlegroups.com>,
> Arjen Markus  <arjen.markus@wldelft.nl> wrote:
>>
>>DOYGEN is capable of generating call graphs (for each routine:
>>which routines are called, by which routines is it called itself).
>>I am not quite sure what it can do with functions that are not
>>explicitly declared, but it seems to be a nice enough tool.
>
> As I said.
>
> What it CANNOT do is to "extract the code structure from undocumented
> source files."  Whether it does anything sensible with procedures
> passed as arguments, I don't know,, but it assuredly cannot do
> anything useful with programs that use procedure variables in
> arbitrary ways.  To achieve that, it would have to solve the halting
> problem.

Well, it probably *can* extract a subset of the true call graph,
as evidenced by code statements that clearly contain direct function calls.
This is pretty easy even with a "bad parser".

To get an upper bound on the call graph, you can do a conservative
analysis of function pointers, which gets you around the halting
problem with some obvious loss of precision.  That's still a lot
better than *just* the direct function calls.

> My objection is to its hype, not its functionality.

Agreed.


-- 
Ira Baxter, CTO
www.semanticdesigns.com

>
> Regards,
> Nick Maclaren.