comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Listing called functions in .pro file
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Listing called functions in .pro file [message #7364] Fri, 08 November 1996 00:00 Go to next message
David Foster is currently offline  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 #7411 is a reply to message #7364] Wed, 13 November 1996 00:00 Go to previous messageGo to next message
Robert Moss is currently offline  Robert Moss
Messages: 74
Registered: February 1996
Member
MICHEL KRUGLANSKI wrote:
>
> 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)
>
> Michel K.
>
> IDL> map_grid
> % Attempt to call undefined procedure/function: 'MAP_GRID'.
> % Execution halted at: $MAIN$
> IDL> map_set
> IDL> map_grid

What's happening here is that the MAP_GRID procedure is contained in
the same file as the MAP_SET procedure. It cannot be compiled at
the command line automatically (as you showed above) because there is
no .pro or .sav file by that name anywhere in your !PATH.

The moral of this story is that when you are using RESOLVE_ALL you have
to think about the order in which things are called in your program...
it matters. Of course, if your program compiles from the command line,
_most_ of it will be resolved by RESOLVE_ALL... after all, if you
havent compiled MAP_SET, you cant run MAP_GRID, regardless of where
your trying to do it.

--
Robert M. Moss, Ph.D. - mossrm@texaco.com - FAX (713)954-6911
------------------------------------------------------------ -----
This does not necessarily reflect the opinions of Texaco Inc.
Re: Listing called functions in .pro file [message #7418 is a reply to message #7364] Tue, 12 November 1996 00:00 Go to previous messageGo to next message
davidf is currently offline  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 #7440 is a reply to message #7364] Tue, 12 November 1996 00:00 Go to previous messageGo to next message
MICHEL KRUGLANSKI is currently offline  MICHEL KRUGLANSKI
Messages: 14
Registered: August 1996
Junior Member
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)

Michel K.

IDL> map_grid
% Attempt to call undefined procedure/function: 'MAP_GRID'.
% Execution halted at: $MAIN$
IDL> map_set
IDL> map_grid
Re: Listing called functions in .pro file [message #7473 is a reply to message #7364] Mon, 18 November 1996 00:00 Go to previous message
Peter Mason is currently offline  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.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: idl.el version 1.35
Next Topic: Asymetrix Embraces KaiZenWare

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 16:00:43 PDT 2025

Total time taken to generate the page: 0.00987 seconds