comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Re: IDL procedure "knowing its own name"

Re: IDL procedure "knowing its own name"
type: item
description: Marshall Perrin wrote: > > Let's say I'm running somethingorother.pro. Is there any way for the procedure > to itself determine that IDL is running a file called somethingorother.pro, > indeed, specifically /some/file/path/somethingorother.pro? > > In more detail, what I've got is a script which processes a bunch of data > and produces some output which gets stored in a user-specified directory. > This script gets modified occasionally over time; it's useful to have a > copy of the script stored along with the data as a historical record so > that you can later look back and see exactly how the data was processed. > However, this tool is used on a number of different systems, and the > file path to the script varies from system to system. Right now I accomplish > this by hard-coding the path and name of the procedure as variables inside > the procedure, which means I have to change it by hand for each system. > Any ideas on how to automate this? > > - Marshall Dear Marshall write help,call=call print,call into your routine regards Reimar -- Reimar Bauer Institut fuer Stratosphaerische Chemie (ICG-1) Forschungszentrum Juelich email: R.Bauer@fz-juelich.de http://www.fz-juelich.de/icg/icg1/ ============================================================ ====== a IDL library at ForschungsZentrum Juelich http://www.fz-juelich.de/icg/icg1/idl_icglib/idl_lib_intro.h tml http://www.fz-juelich.de/zb/text/publikation/juel3786.html ============================================================ ====== read something about linux / windows http://www.suse.de/de/news/hotnews/MS.html
creator: R.Bauer
date: 2001-08-29T10:20:40-00:00

Re: IDL procedure "knowing its own name"
type: item
description: Marshall Perrin (mperrin+news@arkham.berkeley.edu) writes: > Let's say I'm running somethingorother.pro. Is there any way for the procedure > to itself determine that IDL is running a file called somethingorother.pro, > indeed, specifically /some/file/path/somethingorother.pro? You can use Help, /Source to find the specific path of compiled procedures and functions. > In more detail, what I've got is a script which processes a bunch of data > and produces some output which gets stored in a user-specified directory. > This script gets modified occasionally over time; it's useful to have a > copy of the script stored along with the data as a historical record so > that you can later look back and see exactly how the data was processed. > However, this tool is used on a number of different systems, and the > file path to the script varies from system to system. Right now I accomplish > this by hard-coding the path and name of the procedure as variables inside > the procedure, which means I have to change it by hand for each system. > Any ideas on how to automate this? I think you could use this: Help, /Source, Output=helpoutput to get the source output in a string array. Then it should be fairly easy to fish the proper line out of the helpoutput string array to indicate where the file came from 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
creator: David Fanning
date: 2001-08-29T12:58:36-00:00

Re: IDL procedure "knowing its own name"
type: item
description: Marshall Perrin wrote: > Let's say I'm running somethingorother.pro. Is there any way for the procedure > to itself determine that IDL is running a file called somethingorother.pro, > indeed, specifically /some/file/path/somethingorother.pro? > > In more detail, what I've got is a script which processes a bunch of data > and produces some output which gets stored in a user-specified directory. > This script gets modified occasionally over time; it's useful to have a > copy of the script stored along with the data as a historical record so > that you can later look back and see exactly how the data was processed. > However, this tool is used on a number of different systems, and the > file path to the script varies from system to system. Right now I accomplish > this by hard-coding the path and name of the procedure as variables inside > the procedure, which means I have to change it by hand for each system. > Any ideas on how to automate this? It sounds like a version control problem. I concur with other members of this group that CVS works very well for version control of IDL source code. If you use CVS or any other tool that supports RCS tags, you can simply embed an RCS tag (such as $Id$) in an IDL string variable: rcs_id = '$Id: imdisp.pro,v 1.45 2000/08/28 16:17:14 gumley Exp $' The procedure or function can then print or save the string variable to a file when it is called, and CVS takes care of inserting the version number, date, and owner of the last modification. For more CVS information, see http://cimss.ssec.wisc.edu/~gumley/ under the heading 'CVS'. Cheers, Liam. Practical IDL Programming http://www.gumley.com/
creator: Liam E. Gumley
date: 2001-08-29T14:36:16-00:00

Re: IDL procedure "knowing its own name"
type: item
description: Reimar Bauer <r.bauer@fz-juelich.de> wrote: > write > > help,call=call > print,call > > into your routine This is what I wanted exactly - many thanks! - Marshall
creator: mperrin+news
date: 2001-08-29T20:17:55-00:00

Re: IDL procedure "knowing its own name"
type: item
description: mperrin+news@arkham.berkeley.edu (Marshall Perrin) writes: > Let's say I'm running somethingorother.pro. Is there any way for the procedure > to itself determine that IDL is running a file called somethingorother.pro, > indeed, specifically /some/file/path/somethingorother.pro? > > In more detail, what I've got is a script which processes a bunch of data > and produces some output which gets stored in a user-specified directory. > This script gets modified occasionally over time; it's useful to have a > copy of the script stored along with the data as a historical record so > that you can later look back and see exactly how the data was processed. > However, this tool is used on a number of different systems, and the > file path to the script varies from system to system. Right now I accomplish > this by hard-coding the path and name of the procedure as variables inside > the procedure, which means I have to change it by hand for each system. > Any ideas on how to automate this? > > - Marshall You can use my routine_name() procedure (available at http://www.mpimet.mpg.de/~schultz.martin/idl/html/libmartin_ schultz.html#Routines_R ) It is based on what the others suggested, but wraps it into an easy-to-use procedure interface. Cheers, Martin -- [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[ [[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[ [[ Bundesstr. 55, 20146 Hamburg [[ [[ phone: +49 40 41173-308 [[ [[ fax: +49 40 41173-298 [[ [[ martin.schultz@dkrz.de [[ [[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
creator: Martin Schultz
date: 2001-08-31T07:44:51-00:00