|
|
| Re: IDL 5.3 serious problem: save files sneakily restored [message #21380 is a reply to message #21379] |
Fri, 25 August 2000 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Martin Schultz (martin.schultz@dkrz.de) writes:
> This is at least contrary to the online help of 5.3:
Well, who ya gonna believe? Me or the on-line help? :-)
> So, at least theoretically, pro should get executed before sav.
> And this makes all the sense in the world, because otherwise it
> would be hard for authors of compiled files to develop them -
> they would have to delete the sav file each time they modify the
> pro file and want to test changes.
I can't understand how the pro should be executed before
the sav, even theoretically. How would the sav file *ever*
get executed unless it is the *first* once checked?
And it is not problem *testing* changed routines. Just
compile them. IDL *always* looks in memory first, sav
file second, and pro file third.
But I think you *do* have to delete the sav file
if you want the changed file to be found *automatically*.
Although I'm too busy right now to test it. I'm going
to leave that to Ben, since this is certainly an exam
question. :-)
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: IDL 5.3 serious problem: save files sneakily restored [message #21381 is a reply to message #21379] |
Fri, 25 August 2000 00:00 |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
David Fanning wrote:
>
> Vinay L. Kashyap (kashyap@head-cfa.harvard.edu) writes:
>
>> IDL 5.3 appears to have a major hull breach.
>>
>> If there is an idl save file named "<whatever>.sav" in the current
>> directory,
>> the contents of that file get restored whenever <whatever> is referenced as
>> a function within IDL.
>>
>> Comments?
>
> Uh, I'm not sure it's a hull breach. If I understand
> you correctly this has been a behavior of IDL for a
> long, long time.
>
> If you have a piece of code like this:
>
> IDL> a = junker()
>
> IDL assumes that JUNKER is a function. Many people
> think IDL goes looking in the !Path for a file junker.pro,
> but in fact it looks for a file junker.sav *first*. This
> is so that if you have compiled the file junker.pro and
> saved it:
>
This is at least contrary to the online help of 5.3:
Automatic Execution
When a file is specified by typing only the filename at the IDL
prompt, IDL searches the current directory for filename.pro
(where filename is the file specified) and then for filename.sav.
If no file is found in the current directory, IDL searches in the
same way in each directory specified by !PATH. If a file is
found, IDL automatically compiles the contents and executes any
functions or procedures that have the same name as the file
specified (excluding the suffix).
So, at least theoretically, pro should get executed before sav.
And this makes all the sense in the world, because otherwise it
would be hard for authors of compiled files to develop them -
they would have to delete the sav file each time they modify the
pro file and want to test changes.
Cheers,
Martin
> P.S. Of course, these would have to be LONG integers.
Oh so true! This cost me about an hour yesterday to figure out
why my grid generation program (gaussian grid) would fail for
resolutions finer than T106 (320x160 points), even though it was
an almost 1:1 conversion from a fortran program which works for
all resolutions. And, then, finally, I realized that
(8.*nlat^2)
would not yield what I had intended ...
IDL> nlat=[1,2,4,8,16,32,64,128,256]
IDL> print,8.*nlat^2
8.00000 32.0000 128.000 512.000 2048.00
8192.00 32768.0 131072. 0.00000
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ 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
[[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
|
|
| Re: IDL 5.3 serious problem: save files sneakily restored [message #21387 is a reply to message #21386] |
Thu, 24 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Vinay L. Kashyap (kashyap@head-cfa.harvard.edu) writes:
> There is an easy enough workaround (".save"), but please, why
> isn't this listed prominently somewhere, at least in the FFAQ?
Uh, maybe because in 10+ years of working with IDL, this
is the first time I've ever heard of anyone having a problem.
For the record, I always mention it in my IDL programming
course. At least, *most* of the time. :-)
> Which, if you are still taking requests for top 10 enhancements,
> has just made my personal list at -1:
> LOOK FOR THE .SAV FILE *LAST*
What would be the point? The file would have
already been compiled--again--and you could
look for it in memory.
> That's what makes this feature dangerous. There's such a
> tremendous number of functions floating around that it's
> practically impossible not to have *some* .sav files around
> that inadvertantly match a function name.
I think inadvertent integer division probably
claims far more victims each year. If we are going
to campaign for something, I would prefer we enforce
the convention that all integer variables (including
system variables) start with the letter "I" so they
can be readily identified. :-)
Cheers,
David
P.S. Of course, these would have to be LONG integers.
--
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: IDL 5.3 serious problem: save files sneakily restored [message #21388 is a reply to message #21387] |
Thu, 24 August 2000 00:00 |
kashyap
Messages: 26
Registered: April 1993
|
Junior Member |
|
|
In article <MPG.140f7e12fd8ffd61989bf0@news.frii.com>,
David Fanning <davidf@dfanning.com> wrote:
>
> Uh, I'm not sure it's a hull breach. If I understand
> you correctly this has been a behavior of IDL for a
> long, long time.
Good lord. It's a miracle we haven't shot ourselves in the foot
yet with a Gatling.
There is an easy enough workaround (".save"), but please, why
isn't this listed prominently somewhere, at least in the FFAQ?
> think IDL goes looking in the !Path for a file junker.pro,
> but in fact it looks for a file junker.sav *first*. This
Which, if you are still taking requests for top 10 enhancements,
has just made my personal list at -1:
LOOK FOR THE .SAV FILE *LAST*
> It's not an unknown problem in IDL, but a relatively
> rare one, given the huge number of functions and variables
> people create.
That's what makes this feature dangerous. There's such a
tremendous number of functions floating around that it's
practically impossible not to have *some* .sav files around
that inadvertantly match a function name.
Vinay
--
____________________________________________________________ __________________
kashyap@head-cfa.harvard.edu 617 495 7173 [CfA/P-146] 617 496 7173 [F]
|
|
|
|
| Re: IDL 5.3 serious problem: save files sneakily restored [message #21390 is a reply to message #21387] |
Thu, 24 August 2000 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Vinay L. Kashyap (kashyap@head-cfa.harvard.edu) writes:
> IDL 5.3 appears to have a major hull breach.
>
> If there is an idl save file named "<whatever>.sav" in the current
> directory,
> the contents of that file get restored whenever <whatever> is referenced as
> a function within IDL.
>
> Comments?
Uh, I'm not sure it's a hull breach. If I understand
you correctly this has been a behavior of IDL for a
long, long time.
If you have a piece of code like this:
IDL> a = junker()
IDL assumes that JUNKER is a function. Many people
think IDL goes looking in the !Path for a file junker.pro,
but in fact it looks for a file junker.sav *first*. This
is so that if you have compiled the file junker.pro and
saved it:
IDL> .Compile junker.pro
IDL> Save, junker, /Routines, File='junker.sav'
the compiled version will be found and used. You don't
have to always be compiling everything and slowing yourself
down. A *very* nice feature of IDL that I like a lot.
You are just running into a situation in which you
have a variable and a function with the same name.
It's not an unknown problem in IDL, but a relatively
rare one, given the huge number of functions and variables
people create. IDL does an excellent job of keeping track
normally.
I think the solution is to just be a little more
careful with naming conventions. Perhaps a dollar
sign ($) in the name if the file contains saved
variables and not saved routines.
Cheers,
David
P.S. Let's just say having to be careful is a whole
lot better than having to be rigorous and compile
everything every time we need it. :-)
--
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
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
