Re: Many procedures, what to do?

[Craig Markwardt <craigmnet(at)cow.physics.wisc.edu>]

Hi Alex--

Thanks for your support.  Finally somebody who agrees with me! :-)
Actually I appreciate where David is coming from, and agree that
jumping through too many hoops just makes it harder for everyone.

I can offer some real numbers for consideration.  My SAVE library
would have a similar number of files to the MPFIT package if the
low-level files were compacted into one routine.  Going over about 1.3
years worth of download logs, I see that 725 people download a tar or
zip file of MPFIT, while 815 people downloaded the individual
MPFIT.PRO file.  So yes, David, people do like zip files, but they
also like to download the individual PRO file too!

I should mention that I converted a bunch of my functions to
procedures, so that makes it a little easier to support.  There are
really just two functions now, and they are *quite* low-level, so
almost noone will need to FORWARD_FUNCTION them.  So in principle I
could put all the files into one master library file with little or no
repercussions, as long as I force programmers to call CMSVLIB to
initialize the library.  I do still like this idea.

I will try it separate files in a zip archive to begin with.  I'm
getting close!

Craig

Alex Schuster <alex@pet.mpin-koeln.mpg.de> writes:

> Craig Markwardt wrote:
> 
> > 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.
> 
> That's what I do for large projects, too. 
> 
> > 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.
> 
> I tell all users that they have to call the big routine once before
> doing anything else, when they want to use it. Well, maybe short after
> DEVICE, DECOMPOSED=0 and such. 
> 
> > 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...
> 
> What about a startup file (the one that gets executed when IDL is
> started) containing all the FORWARD_FUNCTIONs. It could as well compile
> your CMSVLIB, but that would take some time, probably too long.
> That's another disadvantage of the many files, whenever IDL is started,
> it scans the whole $IDL_PATH for files. This is fast, but well
> noticeable here (2000 files).
> 
>         Alex
> -- 
>   Alex Schuster     Wonko@weird.cologne.de          PGP Key available
>                     alex@pet.mpin-koeln.mpg.de

-- 
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D.         EMAIL:    craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
--------------------------------------------------------------------------