Listing called functions in .pro file [message #7364] |
Fri, 08 November 1996 00:00  |
David Foster
Messages: 341 Registered: January 1996
|
Senior Member |
|
|
Does someone have or know of a routine that can read an IDL .pro
file and output a list of called external functions, possibly with
their associated filenames?
I often share programs with people, but I always forget to include
necessary routines!
If I can't find one, I'll probably write one. Would anyone be
interested?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
David S. Foster Univ. of California, San Diego
Programmer/Analyst Brain Image Analysis Laboratory
foster@bial1.ucsd.edu Department of Psychiatry
(619) 622-5892 8950 Via La Jolla Drive, Suite 2200
La Jolla, CA 92037
[ UCSD Mail Code 0949 ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~
|
|
|
|
Re: Listing called functions in .pro file [message #7418 is a reply to message #7364] |
Tue, 12 November 1996 00:00   |
davidf
Messages: 2866 Registered: September 1996
|
Senior Member |
|
|
MICHEL KRUGLANSKI <M.Kruglanski@oma.be> writes:
> The RESOLVE_ALL code does not resolve every thing.
> For instance, it does not work correctly when you make
> use of MAP_GRID. The MAP_GRID procedure does not exist;
> it is "created" by MAP_SET (see below)
>
> IDL> map_grid
> % Attempt to call undefined procedure/function: 'MAP_GRID'.
> % Execution halted at: $MAIN$
> IDL> map_set
> IDL> map_grid
Well "created" is not really the right word, I don't think.
MAP_GRID is a program module in the MAP_SET code.
This suggests to me that MAP_GRID was originally a
utility routine for MAP_SET that became a little more
useful than the author of the MAP_SET program originally
intended.
When utility routines become more generally useful like this
they are usually taken out of the original program and put
into a file of their own. In this case, the MAP_GRID code
should be taken out of map_set.pro and put into a file
named map_grid.pro. Then it could still be used by
MAP_SET *and* it could be used by any other program
that wanted to use it. (Including typing its name at
the IDL command line.)
More important for this discussion, it could then be
*found* by programs like RESOLVE_ALL using the
normal rules for automatic compilation that IDL uses.
Since the MAP_SET code is available to you in the IDL
library, you can do what the original author should have
done, and take the MAP_GRID portion out.
David
*************************************************
* David Fanning, Ph.D.
* 2642 Bradbury Court, Fort Collins, CO 80521
* Phone: 970-221-0438 Fax: 970-221-4762
* E-Mail: davidf@dfanning.com
*
* Sometimes I go about pitying myself, and all along my
* soul is being blown by great winds across the sky.
* -- Ojibway saying
************************************************
|
|
|
|
Re: Listing called functions in .pro file [message #7473 is a reply to message #7364] |
Mon, 18 November 1996 00:00  |
Peter Mason
Messages: 145 Registered: June 1996
|
Senior Member |
|
|
On Tue, 12 Nov 1996, David Fanning wrote:
> MICHEL KRUGLANSKI <M.Kruglanski@oma.be> writes:
(...RESOLVE_ALL doesn't resolve procedures/functions which are in source files
containing more than 1 routine and which don't have the same name as the
source file.)
I've hacked RESOLVE_ALL so that it will work for some of these cases.
It will be slower than the original, but more persistent.
Anyone interested may pick up a copy from our anon FTP site:
Server: demsyd.syd.dem.csiro.au (130.155.34.2)
Subdir: pub/mmtg/idl
File: resolve_evenmore.pro
Briefly, RESOLVE_EVENMORE does not crash when it tries to compile a routine
which calls another routine which can't be found - it puts the failed-to-
compile routine's name on a "bad list" and carries on. It retries any
failed routines in later passes.
This sort of problem is commonly due to a reference to some utility/support
routine in a file containing routines specific to some module, or in a
"library file" of routines. (I quite favour this style of organising
routines (along with using "forward_function"), which is why I modified
RESOLVE_ALL. Purists kindly avert your gazes.)
Usually a module's "main" procedure or a library's "stub" procedure (at
the end of the file, and with the same name as the file) is referred to sooner
or later, at which point the whole file gets compiled. The routines which
failed to compile earlier now stand a better chance of being compiled.
Peter Mason
CSIRO division of Exploration and Mining
P.O Box 136, North Ryde, NSW, 2113, Australia
E-Mail: p.mason@syd.dem.csiro.au Tel: +61 2 9887-8883 Fax: 9887-8921/8909
"It never hurts to help. Well, not normally." - Eek the cat.
|
|
|