| Problem running functions [message #85800] |
Mon, 09 September 2013 18:15  |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
This is a problem I've had before several times that has caused me to change all my functions to procedures. This time I refuse! The basic problem is that I write a function, test it, have it work fine, then try to use it in a real program and it fails, generally with "Variable is undefined". Here are the details:
I have a directory for IDL functions and procedures I have written. Every new code I write starts out with the line adding this directory to my path: !path = '/home/disk/margaret/idl:' + !path
I wrote two new and very short functions in this directory. I tested them using a little program in a completely different directory: /home/dingo/2/snowmelt/MODIS.SW/data I ran this from the IDL command line, not IDLDE. They ran fine and gave the answers I expected.
Then I switched to a different directory (/home/dingo/2/ceres.syn/ed3a) and started writing the full program I intended. I included use of one of the functions. When I tested the new program, I got the "Variable is undefined" error. WTF?? I checked the path, I checked the spelling and case of the function name, etc., but no luck. The typical error I read about on line is an order of compilation error, but I don't see where there should be any issue if the function worked fine in the test program. I mean, the new code just loads some variables from a file, then calls the function to linearly interpolate two of the values. How can the order be incorrect?
Interestingly, I went back and tried to rerun the test program. I moved a copy to the second work directory (ceres etc.) and got an all-new error message: "Only 8 subscripts allowed." Huh?? I then tried running the test program in the directory where I had written it and it had previously worked fine and now also got the "Only 8 subscripts allowed." message. Note: I restart IDL _every_ time I run a program, so the memory is cleared.
(Don't ask me why I wrote the test code in a different directory. I must have just confused my terminal windows.)
Should I just give up again?? I was so careful and methodical....
|
|
|
|
| Re: Problem running functions [message #85801 is a reply to message #85800] |
Mon, 09 September 2013 18:20  |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
If it matters, I'm running IDL Version 8.2.1 (linux x86_64 m64) with Debian linux.
On Monday, September 9, 2013 6:15:57 PM UTC-7, laura...@gmail.com wrote:
> This is a problem I've had before several times that has caused me to change all my functions to procedures. This time I refuse! The basic problem is that I write a function, test it, have it work fine, then try to use it in a real program and it fails, generally with "Variable is undefined". Here are the details:
>
>
>
> I have a directory for IDL functions and procedures I have written. Every new code I write starts out with the line adding this directory to my path: !path = '/home/disk/margaret/idl:' + !path
>
>
>
> I wrote two new and very short functions in this directory. I tested them using a little program in a completely different directory: /home/dingo/2/snowmelt/MODIS.SW/data I ran this from the IDL command line, not IDLDE. They ran fine and gave the answers I expected.
>
>
>
> Then I switched to a different directory (/home/dingo/2/ceres.syn/ed3a) and started writing the full program I intended. I included use of one of the functions. When I tested the new program, I got the "Variable is undefined" error. WTF?? I checked the path, I checked the spelling and case of the function name, etc., but no luck. The typical error I read about on line is an order of compilation error, but I don't see where there should be any issue if the function worked fine in the test program. I mean, the new code just loads some variables from a file, then calls the function to linearly interpolate two of the values. How can the order be incorrect?
>
>
>
> Interestingly, I went back and tried to rerun the test program. I moved a copy to the second work directory (ceres etc.) and got an all-new error message: "Only 8 subscripts allowed." Huh?? I then tried running the test program in the directory where I had written it and it had previously worked fine and now also got the "Only 8 subscripts allowed." message. Note: I restart IDL _every_ time I run a program, so the memory is cleared.
>
>
>
> (Don't ask me why I wrote the test code in a different directory. I must have just confused my terminal windows.)
>
>
>
> Should I just give up again?? I was so careful and methodical....
|
|
|
|
| Re: Problem running functions [message #85802 is a reply to message #85800] |
Mon, 09 September 2013 19:48 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
laura.hike@gmail.com writes:
> This is a problem I've had before several times that has caused me to change all my functions to procedures. This time I refuse! The basic problem is that I write a function, test it, have it work fine, then try to use it in a real program and it fails, generally with "Variable is undefined". Here are the details:
>
> I have a directory for IDL functions and procedures I have written. Every new code I write starts out with the line adding this directory to my path: !path = '/home/disk/margaret/idl:' + !path
>
> I wrote two new and very short functions in this directory. I tested them using a little program in a completely different directory: /home/dingo/2/snowmelt/MODIS.SW/data I ran this from the IDL command line, not IDLDE. They ran fine and gave the answers I expected.
>
> Then I switched to a different directory (/home/dingo/2/ceres.syn/ed3a) and started writing the full program I intended. I included use of one of the functions. When I tested the new program, I got the "Variable is undefined" error. WTF?? I checked the path, I checked the spelling and case of the function name, etc., but no luck. The typical error I read about on line is an order of compilation error, but I don't see where there should be any issue if the function
worked fine in the test program. I mean, the new code just loads some variables from a file, then calls the function to linearly interpolate two of the values. How can the order be incorrect?
>
> Interestingly, I went back and tried to rerun the test program. I moved a copy to the second work directory (ceres etc.) and got an all-new error message: "Only 8 subscripts allowed." Huh?? I then tried running the test program in the directory where I had written it and it had previously worked fine and now also got the "Only 8 subscripts allowed." message. Note: I restart IDL _every_ time I run a program, so the memory is cleared.
>
> (Don't ask me why I wrote the test code in a different directory. I must have just confused my terminal windows.)
>
> Should I just give up again??
Yes, I think you should give up. Or, maybe just give up this
unbelievably unorthodox and inefficient way of working with IDL. One or
the other, I suppose. :-)
You restart IDL every time you run a program!? Wow.
How about you do this? Take that path statement out of all of your
programs. God only knows what your IDL path looks like after you run a
few programs.
Put your IDL programs, procedures and functions, in one directory. Add
that directory to your IDL path in some kind of normal fashion. Here are
some articles you can read to give you some ideas for how to do this:
http://www.idlcoyote.com/code_tips/installcoyote.php
http://www.idlcoyote.com/misc_tips/idl_startupfile.php
In place of all that path mumbo-jumbo you were including in your files,
add this line instead:
compile_opt strictarr
Now, read this article, particularly the part about naming files
correctly:
http://www.idlcoyote.com/code_tips/mostcommon.html
OK, ready to go? Now, just call your function normally. It will work
perfectly. No restart of IDL required, ever. :-)
result = MyFunction()
Hurrah!
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Problem running functions [message #85803 is a reply to message #85801] |
Tue, 10 September 2013 08:51 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Hello,
I'm running 8.2.2 on RHEL6
Here's the IDL portion of my ".bash_profile" file:
# Setup idl v8.x
. /usr/local/exelis/idl82/bin/idl_setup.bash
export IDL_PATH="<IDL_DEFAULT>"
export IDL_PATH="${IDL_PATH}:+\${CRTM_SCRIPTS_ROOT}/idl:+\${HOME}/idl "
export IDL_STARTUP="${CRTM_SCRIPTS_ROOT}/idl/idl_startup.pro"
(Don't worry about that "CRTM_SCRIPTS_ROOT" envar - that just points to
my repo current working copy.)
After making the above change you'll have to open a new terminal session
so they take. But from that point on all new terminal sessions will have
that setup.
With apologies if you already know this, but the important thing here is
the "+" - that indicates that all of the subdirectories are recursively
included in the IDL_PATH.
This is the only place I define IDL_PATH. I don't do it in the
IDL_STARTUP file like DavidF suggested (although there's nothing wrong
with doing it that way either)
So because I put ALL my IDL code under a directory of the above
"${CRTM_SCRIPTS_ROOT}/idl" and "${HOME}/idl", it is all available for
use in IDL. You also do the same thing so setting your IDL_PATH in your
.bash_profile/.profile/.whatever should solve the problem (he says with
confidence! Ha.) Maybe something like:
# Setup idl v8.x
. /usr/local/wherever-idl-is-installed-directory/idl_setup.bas h
export IDL_PATH="<IDL_DEFAULT>"
export IDL_PATH="${IDL_PATH}:+\${HOME}/margaret/idl"
export IDL_STARTUP="${HOME}/margaret/idl/idl_startup.pro"
?
But I think you will need to remove the paths you've inserted in the files.
I definitely *do not* put paths in individual files. That makes things
very non-portable (e.g. if you get a new machine, or give your code to
someone else).
cheers,
paulv
On 09/09/13 21:20, laura.hike@gmail.com wrote:
> If it matters, I'm running IDL Version 8.2.1 (linux x86_64 m64) with
> Debian linux.
>
>
> On Monday, September 9, 2013 6:15:57 PM UTC-7, laura...@gmail.com
> wrote:
>> This is a problem I've had before several times that has caused me
>> to change all my functions to procedures. This time I refuse! The
>> basic problem is that I write a function, test it, have it work
>> fine, then try to use it in a real program and it fails, generally
>> with "Variable is undefined". Here are the details:
>>
>>
>>
>> I have a directory for IDL functions and procedures I have written.
>> Every new code I write starts out with the line adding this
>> directory to my path: !path = '/home/disk/margaret/idl:' + !path
>>
>>
>>
>> I wrote two new and very short functions in this directory. I
>> tested them using a little program in a completely different
>> directory: /home/dingo/2/snowmelt/MODIS.SW/data I ran this from
>> the IDL command line, not IDLDE. They ran fine and gave the
>> answers I expected.
>>
>>
>>
>> Then I switched to a different directory
>> (/home/dingo/2/ceres.syn/ed3a) and started writing the full program
>> I intended. I included use of one of the functions. When I tested
>> the new program, I got the "Variable is undefined" error. WTF??
>> I checked the path, I checked the spelling and case of the function
>> name, etc., but no luck. The typical error I read about on line is
>> an order of compilation error, but I don't see where there should
>> be any issue if the function worked fine in the test program. I
>> mean, the new code just loads some variables from a file, then
>> calls the function to linearly interpolate two of the values. How
>> can the order be incorrect?
>>
>>
>>
>> Interestingly, I went back and tried to rerun the test program. I
>> moved a copy to the second work directory (ceres etc.) and got an
>> all-new error message: "Only 8 subscripts allowed." Huh?? I then
>> tried running the test program in the directory where I had written
>> it and it had previously worked fine and now also got the "Only 8
>> subscripts allowed." message. Note: I restart IDL _every_ time I
>> run a program, so the memory is cleared.
>>
>>
>>
>> (Don't ask me why I wrote the test code in a different directory.
>> I must have just confused my terminal windows.)
>>
>>
>>
>> Should I just give up again?? I was so careful and methodical....
>
|
|
|
|
|
|
| Re: Problem running functions [message #85818 is a reply to message #85802] |
Wed, 11 September 2013 16:01 |
laura.hike
Messages: 87
Registered: September 2013
|
Member |
|
|
Yes, I restart every time because sometimes crap gets stuck in the memory. You don't know how many times I tried running down an error that was easily solved by restarting.
I also have separate directories for each of my projects. Sorry if you don't like that.
Aside from solving all my life's problems, do you have an answer to the original question? I don't understand why procedures always run correctly from my idl subroutine directory but functions don't. I'd still like to know the answer whether I change my ways or not.
On Monday, September 9, 2013 7:48:37 PM UTC-7, David Fanning wrote:
> Laura wrote:
>
>
>
>> This is a problem I've had before several times that has caused me to change all my functions to procedures. This time I refuse! The basic problem is that I write a function, test it, have it work fine, then try to use it in a real program and it fails, generally with "Variable is undefined". Here are the details:
>
>>
>
>> I have a directory for IDL functions and procedures I have written. Every new code I write starts out with the line adding this directory to my path: !path = '/home/disk/margaret/idl:' + !path
>
>>
>
>> I wrote two new and very short functions in this directory. I tested them using a little program in a completely different directory: /home/dingo/2/snowmelt/MODIS.SW/data I ran this from the IDL command line, not IDLDE. They ran fine and gave the answers I expected.
>
>>
>
>> Then I switched to a different directory (/home/dingo/2/ceres.syn/ed3a) and started writing the full program I intended. I included use of one of the functions. When I tested the new program, I got the "Variable is undefined" error. WTF?? I checked the path, I checked the spelling and case of the function name, etc., but no luck. The typical error I read about on line is an order of compilation error, but I don't see where there should be any issue if the function
>
> worked fine in the test program. I mean, the new code just loads some variables from a file, then calls the function to linearly interpolate two of the values. How can the order be incorrect?
>
>>
>
>> Interestingly, I went back and tried to rerun the test program. I moved a copy to the second work directory (ceres etc.) and got an all-new error message: "Only 8 subscripts allowed." Huh?? I then tried running the test program in the directory where I had written it and it had previously worked fine and now also got the "Only 8 subscripts allowed." message. Note: I restart IDL _every_ time I run a program, so the memory is cleared.
>
>>
>
>> (Don't ask me why I wrote the test code in a different directory. I must have just confused my terminal windows.)
>
>>
>
>> Should I just give up again??
>
>
>
> Yes, I think you should give up. Or, maybe just give up this
>
> unbelievably unorthodox and inefficient way of working with IDL. One or
>
> the other, I suppose. :-)
>
>
>
> You restart IDL every time you run a program!? Wow.
>
>
>
> How about you do this? Take that path statement out of all of your
>
> programs. God only knows what your IDL path looks like after you run a
>
> few programs.
>
>
>
> Put your IDL programs, procedures and functions, in one directory. Add
>
> that directory to your IDL path in some kind of normal fashion. Here are
>
> some articles you can read to give you some ideas for how to do this:
>
>
>
> http://www.idlcoyote.com/code_tips/installcoyote.php
>
> http://www.idlcoyote.com/misc_tips/idl_startupfile.php
>
>
>
> In place of all that path mumbo-jumbo you were including in your files,
>
> add this line instead:
>
>
>
> compile_opt strictarr
>
>
>
> Now, read this article, particularly the part about naming files
>
> correctly:
>
>
>
> http://www.idlcoyote.com/code_tips/mostcommon.html
>
>
>
> OK, ready to go? Now, just call your function normally. It will work
>
> perfectly. No restart of IDL required, ever. :-)
>
>
>
> result = MyFunction()
>
>
>
> Hurrah!
>
>
>
> Cheers,
>
>
>
> David
>
>
>
>
>
>
>
> --
>
> David Fanning, Ph.D.
>
> Fanning Software Consulting, Inc.
>
> Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
>
> Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Problem running functions [message #85819 is a reply to message #85818] |
Wed, 11 September 2013 17:15 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
laura.hike@gmail.com writes:
> Yes, I restart every time because sometimes crap gets stuck in the memory. You don't know how many times I tried running down an error that was easily solved by restarting.
Well, it is true that if you ever call a technical support engineer the
first thing they will ask you to do is restart IDL, but it is not really
because it solves 50% of the problems people call in with. It is because
it gives them a fresh start in understanding what the real problem is.
If you find yourself restarting IDL often, something is seriously wrong
with IDL or with the way you are using it.
> I also have separate directories for each of my projects. Sorry if you don't like that.
Oh, I like it. This is how I organize my life, too. I was just offering
you the simplest solution that was sure to work. Once you know how to
put directories on your IDL path (and this is NOT the way you were
formerly doing it), you can put directories of programs anywhere you
like. IDL will find them, and compile them successfully, if it knows
where to find them.
> Aside from solving all my life's problems, do you have an answer to
the original question? I don't understand why procedures always run
correctly from my idl subroutine directory but functions don't. I'd
still like to know the answer whether I change my ways or not.
My guess is, your programs are named incorrectly and/or then can't be
found AND you are not using the STRICTARR compile option so that IDL can
tell the difference between a function call and an array subscript.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: Problem running functions [message #85848 is a reply to message #85847] |
Fri, 13 September 2013 18:09 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
laura.hike@gmail.com writes:
> It took a bit of figuring out because I found more than one possible syntax on the web, but I added
>
> setenv IDL_PATH":$HOME/shdom/idl"
>
> to my .cshrc file and now everything seems to work. (It took a while to figure out how to do that without wiping out the default path. Using the quotation marks with the colon wasn't obvious.)
The only downside to this approach is that you don't always know in
which order your directories are on your IDL path, and sometimes that
matters. I tend to add "project" directories individually, so I can move
them around as needed. This, of course, is trivial if you set the IDL
path in the IDL Workbench, since arrow buttons do the job of moving
directories around and getting them in the right order for you.
Otherwise, light editing of your .cshrc or IDL start-up file works, too.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Problem running functions [message #85853 is a reply to message #85851] |
Fri, 13 September 2013 20:59 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
laura.hike@gmail.com writes:
> I also don't seem to have an IDL start-up file. Unfortunately, I work in one of those offices where the sysadmins control a lot of things. They built a script that runs when you type "idl" that sets up the environment depending on what OS you're using. When I manage to put my library directory into the path, the default "path" (includes dozens of directories) gets lost. I thought I had it appending before, but haven't been able to duplicate for the rest of the
afternoon.
By the way, this may well be why nothing works for you. Since you can't
control your IDL_PATH you are at the mercy of of whatever path is set up
for you. You type an IDL command and you don't know WHAT is going to
happen.
This is why order matters. Even if someone dictates what you have to
have on your IDL path, you can put your own files FIRST, so they get
found and compiled before all those other, no doubt outdated, files with
the same name.
I think your motto should be "Return Control to the Programming
Sisterhood!"
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Problem running functions [message #85881 is a reply to message #85850] |
Mon, 16 September 2013 10:20 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
Hello,
I don't use the workbench. IMO it's just trading in a bunch of exposed
problems for others under a (generally) locked hood. But don't let my
bias stop you from giving it a go. You may really like/prefer it.
Getting back to your issue:
I'm not a CSH person, but the syntax you listed,
setenv IDL_PATH":$HOME/shdom/idl"
doesn't look right. Should it be:
setenv IDL_PATH "${IDL_PATH}:+\$HOME/shdom/idl"
?
You want to make sure you prepend (or append) the IDL_PATH to itself.
Also, DavidF's comment about the order may be an issue. I take great
pains to *not* have similarly named routines in different directories.
But if you do have several versions of the same routines, not specifying
a specific order may cause problems. I would recommend fixing that by
having only one version of everything, but that may not be a
workable/quick solution.
cheers,
paulv
p.s. Nothing wrong with being a Fortran programmer. That's what I am.
Fortran2003 all the way! :o)
On 09/13/13 21:43, laura.hike@gmail.com wrote:
> On Friday, September 13, 2013 6:38:58 PM UTC-7, laura...@gmail.com
> wrote:
>> I take it back: it's not working.
>
> Maybe this is why I gave up and put the path into the file in the
> first place.
>
> (I don't use the workbench, I write code like a FORTRAN programmer.
> Now THIS is where I need to move to the 21st century!)
>
|
|
|
|
| Re: Problem running functions [message #85883 is a reply to message #85881] |
Mon, 16 September 2013 10:40 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> Should it be:
>
> setenv IDL_PATH "${IDL_PATH}:+\$HOME/shdom/idl"
>
> ?
>
> You want to make sure you prepend (or append) the IDL_PATH to itself.
>
> Also, DavidF's comment about the order may be an issue. I take great
> pains to *not* have similarly named routines in different directories.
> But if you do have several versions of the same routines, not specifying
> a specific order may cause problems. I would recommend fixing that by
> having only one version of everything, but that may not be a
> workable/quick solution.
I'm really more concerned that she has a very long IDL path that was set
up for her and which she has little or no knowledge of. In such a case,
I would not be adding her files at the END of the path. Rather, I would
put them at the START of the path. That way, she at least has a chance
of getting her own files to compile properly, which was her original
concern, I think. Assuming, of course, she takes my advice about naming
things properly, using the right compile option, etc. She doesn't seem
inclined to. Old-school FORTRAN programmers often treat my advice like
this. ;-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: Problem running functions [message #85890 is a reply to message #85883] |
Mon, 16 September 2013 11:23 |
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
On 09/16/13 13:40, David Fanning wrote:
> Paul van Delst writes:
>
>> Should it be:
>>
>> setenv IDL_PATH "${IDL_PATH}:+\$HOME/shdom/idl"
>>
>> ?
>>
>> You want to make sure you prepend (or append) the IDL_PATH to itself.
>>
>
> I'm really more concerned that she has a very long IDL path that was set
> up for her and which she has little or no knowledge of. In such a case,
> I would not be adding her files at the END of the path. Rather, I would
> put them at the START of the path.
Oh, yes. After rereading her earlier post (where the "dozens of
directories" are mentioned) I agree.
So, Laura, maybe you should try:
setenv IDL_PATH "+\$HOME/shdom/idl:${IDL_PATH}"
instead.
> That way, she at least has a chance
> of getting her own files to compile properly, which was her original
> concern, I think. Assuming, of course, she takes my advice about naming
> things properly, using the right compile option, etc. She doesn't seem
> inclined to. Old-school FORTRAN programmers often treat my advice like
> this. ;-)
Now, now. Be nice. (Is the rain getting to you? :o)
cheers,
paulv
|
|
|
|
|
|
|
|
| Update on Rain in Colorado [message #85899 is a reply to message #85898] |
Mon, 16 September 2013 12:55 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Paul van Delst writes:
> My comment was a tad flippant - sorry about that. You guys are getting
> hammered out there. Even though Fort Collins is also being inundated,
> Boulder and Denver are really getting dumped on. The precip 7-day total
> in one location in Boulder is >20"!
>
> Crikey.
>
> http://www.crh.noaa.gov/bou/?n=preciptotals_multiday
The sun is shining outside my window, finally! Rescue helicopters are in
the air and flying directly over my office. We have over 300 people
still unaccounted for in the county--more in the Boulder area--and
pretty much all of the roads leading into the mountains are closed with
wash-outs or debris flow from the big fires last summer. Most of the
unaccounted for are probably OK, we just can't get to them or contact
them. The burn scar just to the west of me got hit with over 10 inches
of rain in the past couple of days, as compared to a little over 4
inches here in Fort Collins.
It has been reported that Highway 34, which leads from here to Rocky
Mountain National Park, is in worse shape than it was in 1976, when a
flash flood killed 144 people. So far, there have been only two presumed
deaths in that canyon, but it will take at least a year, they estimate,
to get the road open again. In the Narrows part of the canyon there is
simply no place to build a road anymore. Much of the soil is gone. I've
heard that over 1200 homes in northern Colorado have been damaged or
destroyed.
I belong to a group that patrols and maintains 54 hiking trails in the
immediate area. We expect many of those trails to remain closed for a
year or more until we can get to them and get them open again. We had 50
people on a trail the weekend before this, finally getting a trail open
that had been closed by last summer's fires. It was a total mess and a
tremendous amount of work opening it. We fully expect all that work to
be for naught and to have to start over on that. All of our local open
space (probably the reason many of us live in Colorado) is in the same
shape. Heavily eroded, bridges washed away, trees down on the trail,
etc. On most of our trails, chain saws are prohibited, so all of this
remediation work is done with hand tools and strong backs.
Fortunately, we realize this area is subjected to frequent flooding so
the city and county have done a great deal of mitigation work over the
years. There is no question what they have done has saved lives. The
area I live in flooded heavily in 1997, but new retention ponds, etc.
have kept everyone in my neighborhood out of water this year. We are
grateful for our blessings and our thoughts and prayers are with those
less fortunate this time.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: Problem running functions [message #85903 is a reply to message #85902] |
Mon, 16 September 2013 14:28 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
liam.gumley@ssec.wisc.edu writes:
>
> This is how I manage my IDL path. Try it if you like.
>
> 1. Remove the path setting from all of your IDL .pro files (procedures and functions).
>
> 2. Assuming that you keep all your IDL .pro files in subdirectories under $HOME/idl, then create a file named idl_startup.pro in $HOME/idl containing this line
>
> !path = !path + ':' + expand_path('+$HOME/idl')
>
> 3. In your $HOME/.cshrc file, add this line (remove any existing IDL_STARTUP or IDL_PATH settings)
>
> setenv IDL_STARTUP $HOME/idl/idl_startup.pro
>
> 4. Log out and then log back in to cleanly execute the .cshrc file.
>
> That's it. You may also want to switch to the convention of using square brackets for referencing arrays, e.g.,
>
> b = a[0]
>
> instead of
>
> b = a(0).
>
> It makes life much easier.
>
> Cheers,
> Liam.
> Practical IDL Programming
> http://www.gumley.com/
>
> PS #1: You should also have a careful read of the sections titled "Managing IDL Paths" and "Automatic Compilation and Execution" in the IDL online help (type idlhelp).
>
> PS #2: You don't need to restart IDL every time you run a program.
My advice, exactly, although I would do this for all the reasons I've
listed previously. :-)
!PATH = Expand_Path('+$HOME/idl/:') + !PATH
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.idlcoyote.com/
Sepore ma de ni thue. ("Perhaps thou speakest truth.")
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
