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

Home » Public Forums » archive » Re: Many procedures, what to do?
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
Re: Many procedures, what to do? [message #23183] Fri, 12 January 2001 17:41
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Surendar Jeyadev (jeyadev@wrc.xerox.com) writes:

> By the time work begins all those things are pretty well debugged
> and I would prefer not to see them at all.

I'd put them in files of their own, move them to a subdirectory
named "hidden", put that on your path and forget you
ever saw them. :-)

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
Re: Many procedures, what to do? [message #23184 is a reply to message #23183] Fri, 12 January 2001 16:41 Go to previous message
jeyadev is currently offline  jeyadev
Messages: 78
Registered: February 1995
Member
In article <onr9297isv.fsf@cow.physics.wisc.edu>,
Craig Markwardt <craigmnet@cow.physics.wisc.edu> wrote:
>
> Greetings all!
>
> I have about twenty five functions that go into a single larger
> library. They are all pretty much inextricably linked together. This
> is the SAVE file library I have mentioned once or twice, with the
> ability to read and write and interogate save files yourself.
>
> Anyway, my question is what to do with all these files? I would
> imagine that for most people, including myself, this many files is a
> pain in the neck. Also they share a lot of the same parameters so it
> would be difficult to keep the documentation up to date.

I believe that you are stuck with this. This appears to be a fundamental
problem linked to the command line parsing method of IDS and PV Wave. I
use the latter for plotting purposes, but any serious computation in that
environment is out of the question for the reasons you state. And, I do
hate seeing the *lowest* level functions and procedures at the *top* of
a file! By the time work begins all those things are pretty well debugged
and I would prefer not to see them at all.

Amateur user's opinion, of course!
--

Surendar Jeyadev jeyadev@wrc.xerox.com
Re: Many procedures, what to do? [message #23185 is a reply to message #23184] Fri, 12 January 2001 15:41 Go to previous message
Craig Markwardt is currently offline  Craig Markwardt
Messages: 1869
Registered: November 1996
Senior Member
"Pavel A. Romashkin" <pavel.romashkin@noaa.gov> writes:

> No, it will not, but are you on 5.2? I personally dislike version
> checking for the purpose of disabling some portions of the code :-( But
> a library saved as .sav will not open in earlier versions anyway. Isn't
> this what you want to do? Save all routines in a .sav, then call it by
> the name and they all instantly become available (to those lucky ones
> who happen to have the same IDL version :-)

Hi Pavel--

The question is to have one big .PRO file, or many small .PRO files.
Save files do not enter into my question [except that the .PRO files
are designed to manipulate save files].

If I put a compile_opt directive in any of the .PRO files, then it
will surely fail to compile by anybody with an older version of IDL.
Right?

Craig

--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
Re: Many procedures, what to do? [message #23188 is a reply to message #23185] Fri, 12 January 2001 14:14 Go to previous message
Pavel A. Romashkin is currently offline  Pavel A. Romashkin
Messages: 531
Registered: November 2000
Senior Member
No, it will not, but are you on 5.2? I personally dislike version
checking for the purpose of disabling some portions of the code :-( But
a library saved as .sav will not open in earlier versions anyway. Isn't
this what you want to do? Save all routines in a .sav, then call it by
the name and they all instantly become available (to those lucky ones
who happen to have the same IDL version :-)

Cheers,
Pavel

Craig Markwardt wrote:
>
> Hmm, that would be nice, but can that work on IDL < 5.3?
>
> Not-living-in-the-here-and-now-when-it-comes-to-IDL-versions Craig
Re: Many procedures, what to do? [message #23190 is a reply to message #23188] Fri, 12 January 2001 12:09 Go to previous message
Craig Markwardt is currently offline  Craig Markwardt
Messages: 1869
Registered: November 1996
Senior Member
Hmm, that would be nice, but can that work on IDL < 5.3?

Not-living-in-the-here-and-now-when-it-comes-to-IDL-versions Craig

"Pavel A. Romashkin" <pavel.romashkin@noaa.gov> writes:

> How about using compile_opt, strictarr? It will eliminate the need for
> forward_function. I use it all the time and have no worries about IDL
> mixing functions with arrays. This way, the caller does not need
> compiled library functions to know they are functions - the syntax of
> the call implies that they are, and will be available at the execution time.
>
> Cheers,
> Pavel

--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
Re: Many procedures, what to do? [message #23197 is a reply to message #23190] Fri, 12 January 2001 08:42 Go to previous message
Pavel A. Romashkin is currently offline  Pavel A. Romashkin
Messages: 531
Registered: November 2000
Senior Member
How about using compile_opt, strictarr? It will eliminate the need for
forward_function. I use it all the time and have no worries about IDL
mixing functions with arrays. This way, the caller does not need
compiled library functions to know they are functions - the syntax of
the call implies that they are, and will be available at the execution time.

Cheers,
Pavel
Re: Many procedures, what to do? [message #23198 is a reply to message #23197] Fri, 12 January 2001 08:50 Go to previous message
Jaco van Gorkom is currently offline  Jaco van Gorkom
Messages: 97
Registered: November 2000
Member
Craig Markwardt wrote:
> My thought was to collapse all these routines into one single file.
> That way it's easy to keep everything in one place, and there can be
> lots of shared documentation.
>
> The problem with that is then there are a bunch of functions like
> CMSV_RLONG CMSV_RSTRING, CMSV_RCOMM, stored in a file called
> cmsvlib.pro. IDL has no way to figure out these functions are stored
> in cmsvlib.pro, or for that matter that they are functions at all.

If you'd really want to put all these function into one libfile, then
you could create a bunch of files like cmsv_rlong.pro , cmsv_rstring.pro
, etc., all containing just the one line "@cmsvlib.pro".
The one *big* problem with this is that automatic compilation stops once
the function is encountered, leaving part of the library uncompiled.
Things will get compiled twice or more. Worse, if your "user-accessible"
functions call each other, they might get "compiled while active" and
return in the middle of execution. The only solution I see is to call an
(empty) cmsvlib procedure first thing in each function. Complicated
again...

But don't let me keep you. I desperately need some smarter save/restore
functionality!

Jaco
Re: Many procedures, what to do? [message #23199 is a reply to message #23197] Fri, 12 January 2001 08:05 Go to previous message
Paul van Delst is currently offline  Paul van Delst
Messages: 364
Registered: March 1997
Senior Member
Craig Markwardt wrote:
>
> davidf@dfanning.com (David Fanning) writes:
>> I have to admit, I'm always confused when I read articles
>> like this. I've been writing IDL programs for over 12 years
>> now, and I've maybe used FORWARD_FUNCTION three times. I
>> have gotten the wrong FOO program from some other directory
>> maybe a few times more than that. But I have never, in all
>> those years, had difficulty getting programs to compile
>> and run when they are suppose to.
>
> Hi David--
>
> I guess what I'm saying is that I *already* have a library of 25
> individual files that do low-level stuff. I am feeling like this is a
> pain in the butt for me and for other people to manage. Also, all of
> these functions share a lot of common parameters and keywords, so it
> makes sense to only document them once, rather than in each file. All
> typing and no rest makes Craig a bad carpal tunnel boy.

Hmm. I have encountered a (far less numerous) problem like this that involved 4 functions. The top
level _REF_EXTRA dribbled all the way down to the lowest level, but each routine had, at some point,
been used as an entry point. At first I didn't want to document every single doc header with the
_REF_EXTRA keywords for the lowest level function, but then I considered the poor unfortunate user
that would have to doc_library, '' again and again to find out what the extra keywords actually
were. I bit the bullet and replicated the lowest level keyword documentation in all of them.

For your case with many more components, a utility to do this automatically would be the ticket. I
have done similar things with shell scripts using sed and awk. A pain I grant you, but once done,
it's done.

> My thought was to collapse all these routines into one single file.
> That way it's easy to keep everything in one place, and there can be
> lots of shared documentation.
>
> The problem with that is then there are a bunch of functions like
> CMSV_RLONG CMSV_RSTRING, CMSV_RCOMM, stored in a file called
> cmsvlib.pro. IDL has no way to figure out these functions are stored
> in cmsvlib.pro, or for that matter that they are functions at all.
>
> You are saying, "put each function in a separate file." I am saying,
> "I already have that, but am wondering whether one single library file
> would be more convenient for downloaders."

For downloading, why not use a tarball/zipfile? Personally, I dislike a whole bunch of routines
smooshed into one IDL file as you have suggested - IDL isn't geared to handle this sort of thing (as
you've pointed out).

Anyway....

paulv

--
Paul van Delst A little learning is a dangerous thing;
CIMSS @ NOAA/NCEP Drink deep, or taste not the Pierian spring;
Ph: (301) 763-8000 x7274 There shallow draughts intoxicate the brain,
Fax: (301) 763-8545 And drinking largely sobers us again.
Email: pvandelst@ncep.noaa.gov Alexander Pope.
Re: Many procedures, what to do? [message #23201 is a reply to message #23199] Fri, 12 January 2001 07:40 Go to previous message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:
>
> I guess what I'm saying is that I *already* have a library of 25
> individual files that do low-level stuff. I am feeling like this is a
> pain in the butt for me and for other people to manage. Also, all of
> these functions share a lot of common parameters and keywords, so it
> makes sense to only document them once, rather than in each file. All
> typing and no rest makes Craig a bad carpal tunnel boy.

Ah, this is what HTML files are for, IMHO. :-)

> My thought was to collapse all these routines into one single file.
> That way it's easy to keep everything in one place, and there can be
> lots of shared documentation.
>
> The problem with that is then there are a bunch of functions like
> CMSV_RLONG CMSV_RSTRING, CMSV_RCOMM, stored in a file called
> cmsvlib.pro. IDL has no way to figure out these functions are stored
> in cmsvlib.pro, or for that matter that they are functions at all.
>
> You are saying, "put each function in a separate file." I am saying,
> "I already have that, but am wondering whether one single library file
> would be more convenient for downloaders."

My experience suggests users like zip files. They don't really
care how many separate files there are. When I download these
files, I'm going to put them in my craigm subdirectory anyway.
I would just throw that HTML (or, better yet, PDF) documentation
file in with all the program files. People will figure it out,
most of them. The rest will hound you night and day until you
just finally take the time to put the documentation in each file.
But that's the way the world works, I'm afraid. :-)

Cheers,

David

--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
Re: Many procedures, what to do? [message #23202 is a reply to message #23201] Fri, 12 January 2001 07:11 Go to previous message
Craig Markwardt is currently offline  Craig Markwardt
Messages: 1869
Registered: November 1996
Senior Member
davidf@dfanning.com (David Fanning) writes:
> I have to admit, I'm always confused when I read articles
> like this. I've been writing IDL programs for over 12 years
> now, and I've maybe used FORWARD_FUNCTION three times. I
> have gotten the wrong FOO program from some other directory
> maybe a few times more than that. But I have never, in all
> those years, had difficulty getting programs to compile
> and run when they are suppose to.

Hi David--

I guess what I'm saying is that I *already* have a library of 25
individual files that do low-level stuff. I am feeling like this is a
pain in the butt for me and for other people to manage. Also, all of
these functions share a lot of common parameters and keywords, so it
makes sense to only document them once, rather than in each file. All
typing and no rest makes Craig a bad carpal tunnel boy.

My thought was to collapse all these routines into one single file.
That way it's easy to keep everything in one place, and there can be
lots of shared documentation.

The problem with that is then there are a bunch of functions like
CMSV_RLONG CMSV_RSTRING, CMSV_RCOMM, stored in a file called
cmsvlib.pro. IDL has no way to figure out these functions are stored
in cmsvlib.pro, or for that matter that they are functions at all.

You are saying, "put each function in a separate file." I am saying,
"I already have that, but am wondering whether one single library file
would be more convenient for downloaders."

Craig

--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
Re: Many procedures, what to do? [message #23210 is a reply to message #23202] Thu, 11 January 2001 16:35 Go to previous message
davidf is currently offline  davidf
Messages: 2866
Registered: September 1996
Senior Member
Craig Markwardt (craigmnet@cow.physics.wisc.edu) writes:

> I have about twenty five functions that go into a single larger
> library. They are all pretty much inextricably linked together. This
> is the SAVE file library I have mentioned once or twice, with the
> ability to read and write and interogate save files yourself.
>
> Anyway, my question is what to do with all these files? I would
> imagine that for most people, including myself, this many files is a
> pain in the neck. Also they share a lot of the same parameters so it
> would be difficult to keep the documentation up to date.
>
> My other option is to merge them into a single file called, say,
> CMSVLIB. There are a couple of problems with that.
>
> First, how to get them compiled. That's easy, I just require every
> program which calls the library to invoke CMSVLIB first. As long as
> there is actually a procedure called CMSVLIB at the end of the file,
> this should force all the other routines in the file to be compiled.
>
> The other problem is more subtle. Since none of the individual files
> are compiled when the invoking procedure is compiled, IDL won't know
> about the functions. It will see the round parenthesis of
> "cmsv_rlong(block, pointer)" and think it's an array subscript.
> Arghh.
>
> Okay, that can be solved by forcing everybody to declare the functions
> they use with FORWARD_FUNCTION. Now it's starting to get annoying
> again. I guess I could rewrite everything to be procedures...
>
> Does anybody else have suggestions, or experiences with something like
> this?

I have to admit, I'm always confused when I read articles
like this. I've been writing IDL programs for over 12 years
now, and I've maybe used FORWARD_FUNCTION three times. I
have gotten the wrong FOO program from some other directory
maybe a few times more than that. But I have never, in all
those years, had difficulty getting programs to compile
and run when they are suppose to.

What have I been doing wrong! :-(

My rigid rule of thumb is that if there is a "command" I am
trying to build (procedure or function), the file is given
that name and that module goes at the end of the file.
Any support routines that are NOT meant to be "commands",
in the sense that I want someone to use them from the
IDL command line, are placed in front of the command
module. If something becomes "command important", I
yank it out of the file and put it in a file of its
own, with the file given the command name, as before.

I just can't see how IDL can fail to get it right if
each "command" is in a separate file, and the files
are in a directory on the path. It works every time
for me.

Cheers,

David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Re: Code for Dynamically creating and repositioning Buttons during IDL runtime
Next Topic: CW_Field Observation

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

Current Time: Fri Oct 10 13:38:45 PDT 2025

Total time taken to generate the page: 1.12134 seconds