|
|
| Re: One file for each procedure/function? [message #30335 is a reply to message #30329] |
Fri, 19 April 2002 07:28  |
![Paul Van Delst[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "Paul Van Delst[1] is currently offline")
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Pepijn Kenter wrote:
>
> Hi all.
>
> I'm currently writing analyses software (small programs plus routines) for
> an ozon measurement device and I'm new to IDL. A lot of the routines and
> programs have already been written and are ready for me to use. These
> routines have been grouped together in a few .pro files. These files are
> then compiled explicitly (by .compile statements) in the main programs. The
> programs are called from the command line.
>
> I'm under the strong impression that this is not the normal way of working
> and that you should create one file for each function or procedure, which is
> than compiled automaticly when it's needed. These files should be put in a
> directory that is included in the !path system variable.
>
> Still, I would like to keep functions that belong to each other grouped
> together; if not in one file, then at least in one directory. So I've
> devided the routines over a few directories and used the expand_path
> function to include these directories in the !path variable.
>
> Is this the best way of working?
> Or are there better way's of ordering your routines (like units in pascal)?
> I want to keep using the command line to start my programs (i.e. i don't
> want to be dependend on .prj files)
>
> I'm not happy with the 'one file for each function' concept but if this is
> the way IDL is designed I think I'd better stick to it, rather than using
> obscure tricks to circumvent it.
In my .bashrc file I have:
export IDL_PATH=${IDL_PATH}:+\${HOME}/idl
Note the +\${HOME}/idl
What this does is make everything in ${HOME}/idl, including nested subdirectories, "visible" to
IDL when you run it. My ${HOME}/idl directory looks like:
lnx:/home/paulv : dir idl
total 148
drwxr-xr-x 4 wd20pd wd4 4096 Oct 2 2001 AIRS/
drwxr-xr-x 6 wd20pd wd4 4096 Oct 2 2001 ATOVS/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 Ancillary/
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 CVS/
drwxr-xr-x 3 wd20pd wd4 4096 Apr 18 14:04 Constants/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 Date_Time/
drwxr-xr-x 4 wd20pd wd4 4096 Oct 2 2001 Development/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 Emissivity/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 Error_Handling/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 F90_Documentation/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 GIFTS/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 General/
drwxr-xr-x 4 wd20pd wd4 4096 Oct 2 2001 Graphics/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 HIS/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 Interpolation/
drwxr-xr-x 3 wd20pd wd4 4096 Apr 18 12:49 LBLRTM/
drwxr-xr-x 3 wd20pd wd4 4096 Apr 19 09:10 Meteorology/
drwxr-xr-x 4 wd20pd wd4 4096 Oct 2 2001 NAST-I/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 NCDF/
drwxr-xr-x 3 wd20pd wd4 4096 Apr 3 17:04 NCEP_RTM/
drwxr-xr-x 3 wd20pd wd4 4096 Dec 18 09:34 PDdata/
drwxr-xr-x 4 wd20pd wd4 4096 Mar 22 19:04 Radiance/
drwxr-xr-x 3 wd20pd wd4 4096 Feb 4 13:20 Spectral/
drwxr-xr-x 3 wd20pd wd4 4096 Nov 14 15:06 Swap_Endian/
drwxr-xr-x 5 wd20pd wd4 4096 Apr 18 14:12 Transmittance/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 UARS/
drwxr-xr-x 2 wd20pd wd4 4096 Jan 22 15:27 Utility/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 WgtFnGUI/
-rw-r--r-- 1 wd20pd wd4 288 Apr 18 12:44 idl_startup.pro
-rw-r--r-- 1 wd20pd wd4 3349 Jan 30 2001 template.pro
drwxr-xr-x 8 wd20pd wd4 4096 Oct 2 2001 user_contrib/
where the directory name usually refers to the "CATEGORY" item in the documentation template
that comes with IDL. I group my code into the above directories according to their use. Some
directories have subirectories, e.g.:
lnx:/home/paulv/idl : dir ATOVS
total 16
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 CVS/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 readers/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 scan_analysis/
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 visualisation/
lnx:/home/paulv/idl : dir user_contrib
total 24
drwxr-xr-x 3 wd20pd wd4 4096 Oct 2 2001 chris_sisko/
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 dfanning/
drwxr-xr-x 4 wd20pd wd4 4096 Oct 2 2001 liam_gumley/
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 markwardt/
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 martin_schultz/
drwxr-xr-x 2 wd20pd wd4 4096 Oct 2 2001 mcraig/
I'm sure there's more logical ways to organise stuff, but this works for me.
paulv
--
Paul van Delst Religious and cultural
CIMSS @ NOAA/NCEP purity is a fundamentalist
Ph: (301)763-8000 x7274 fantasy
Fax:(301)763-8545 V.S.Naipaul
|
|
|
|
| Re: One file for each procedure/function? [message #30336 is a reply to message #30335] |
Fri, 19 April 2002 06:44 |
David Burridge
Messages: 33
Registered: January 1998
|
Member |
|
|
Hi Pepijn,
"Pepijn Kenter" <p.t.kenter@twi.tudelft.nl> wrote in message
news:M%Tv8.115$2I3.3490@castor.casema.net...
<snip>
> I'm under the strong impression that this is not the normal way of working
> and that you should create one file for each function or procedure, which
is
> than compiled automaticly when it's needed. These files should be put in a
> directory that is included in the !path system variable.
>
> Still, I would like to keep functions that belong to each other grouped
> together; if not in one file, then at least in one directory. So I've
> devided the routines over a few directories and used the expand_path
> function to include these directories in the !path variable.
>
> Is this the best way of working?
> Or are there better way's of ordering your routines (like units in
pascal)?
> I want to keep using the command line to start my programs (i.e. i don't
> want to be dependend on .prj files)
>
> I'm not happy with the 'one file for each function' concept but if this is
> the way IDL is designed I think I'd better stick to it, rather than using
> obscure tricks to circumvent it.
As you mention, one file per routine is best and it makes the code easier to
debug too, as the routines are easier to find. Some programmers collect
routines together in one file when the code is interdependent. For example,
if you put the event handler for a widget program at the top of the widget
program file, it gets compiled when the main program is called, so is always
'ready-compiled' when it's needed.
I would advocate the use of directories in you case, coupled with the '+'
switch in your path statement. If you want to package up your code into
'libraries', an alternative is to put them into a save file which will also
cut the compile overhead.
Hope this is helpful,
Dave
|
|
|
|
| Re: One file for each procedure/function? [message #30338 is a reply to message #30336] |
Fri, 19 April 2002 06:19 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Pepijn Kenter wrote:
> I'm currently writing analyses software (small programs plus routines) for
> an ozon measurement device and I'm new to IDL. A lot of the routines and
> programs have already been written and are ready for me to use. These
> routines have been grouped together in a few .pro files. These files are
> then compiled explicitly (by .compile statements) in the main programs. The
> programs are called from the command line.
Just to add a bit to Riemar's useful advice, it is useful
to think of a program file as an IDL "command" you
are building. The procedure or function that has the
same name as the command (and the file) should be the last
module in the file. Other procedures and functions that are
used by the command module for its internal use can also be
placed in the file, but always above (in front) of the
command module in the file. In this way, everything is
compiled properly when the "command" is used.
Reimer is correct in recommending that these utility
routines be named starting with a base "command" name.
Otherwise, you have command name chaos and you can never
be sure what procedure or function with this name you
are actually running. For example, naming an event
handler module "Quit" is always a bad idea. The name
"MyProgram_Quit" is much more specific.
Sometimes utility routines take on a life of their own,
and we find them to have wider use than we expected them
to initially. In this case, we take them out of the command
file and place them in a command file of their own, so
they can enjoy wider use by other programs that want to
use them.
It is not unusual to place the programs from an entire
application in separate directories according to
functionality, etc. But typically, these are subdirectories
of an "application" directory that can be added to a user's
Path easily.
By the way, you are correct in thinking that the use
of compile statements goes completely against the
IDL WAY. They are typically used only as a last
resort to sort out command name chaos (see above). :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: One file for each procedure/function? [message #30339 is a reply to message #30338] |
Fri, 19 April 2002 05:49 |
R.Bauer
Messages: 1424
Registered: November 1998
|
Senior Member |
|
|
Pepijn Kenter wrote:
>
> Hi all.
>
> I'm currently writing analyses software (small programs plus routines) for
> an ozon measurement device and I'm new to IDL. A lot of the routines and
> programs have already been written and are ready for me to use. These
> routines have been grouped together in a few .pro files. These files are
> then compiled explicitly (by .compile statements) in the main programs. The
> programs are called from the command line.
Dear Pepijn,
the normal way for routines without widgets is to have only one routine
per file.
A widget has more as one routine. I am organizing all widget routines
e.g.
event_handler, init, set and get routine in one file.
To prevent conflicts with other routines I set as base name to all
routines
inside a file the same name.
e.g. "x_test.pro"
x_test_event,event
x_test
The other question is more about how to organize a library.
Some parts of a library is from external users and some are from members
of your group.
We did set up a path of idl_lib for external libraries and a path
idl_work
for our programmers. In the comment header of each routine
the routine is described and a category entry shows were it belongs too.
This header is used to build an online help system (html/javascript).
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl _html/idl_work_libraries.htm
The files are organized in user lib directories. All pathes are
collected
with one startup file to !path.
http://www.fz-juelich.de/icg/icg-i/idl_icglib/idl_source/idl .all
To get the most speed in searching idl routines by idl is to have all
routines
in one directory.
This is quite easy by unix with links. Our idl file server is a unix
machine.
All needed routines are linked into one idl_links path.
hope this helps a bit
regards
Reimar
--
Reimar Bauer
Institut fuer Stratosphaerische Chemie (ICG-I)
Forschungszentrum Juelich
email: R.Bauer@fz-juelich.de
------------------------------------------------------------ -------
a IDL library at ForschungsZentrum Juelich
http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml
============================================================ =======
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
