| Re: IDL compatibility [message #23127] |
Thu, 11 January 2001 03:02 |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
Craig Markwardt wrote:
>
>
> In my case I eventually found my own error. I misconfigured the
> !PATH, so lib/obsolete wasn't included. Thankfully STR_SEP is still
> there, for now.
>
> However, here's what I think should happen. This is me tickling the
> RSI secret agents who read this newsgroup. :-) See if people agree:
>
> * when replacing one routine with another (as in the case of STR_SEP
> and STRSPLIT), leave STR_SEP.PRO as a wrapper routine. Then at
> least people's programs won't break. So far this is not an issue
> since STR_SEP is still included in the "obsolete" directory.
Well, I think this is what the obsolete directory is there for! So I
don't see a need to have a wrapper here. The only thing that bothers
here is (as JD recently pointed out): you normally get the obsolete
directory in your library search path *before* the up-to-date library
(because subdirectories are included first). Maybe, therefore, the
obsolete directory should be on the same level as lib ?
>
> * when adding undocumented built-in functions, as for STRTOK, the
> function name should really have a unique prefix, like "RSI_". This
> avoids name clashes with innocent user routines.
I certainly agree on this (despite the warning that RSI folks give in
that *you* should preceed all your programs with your initials. With
undocumented internal functions, this is really something different.
>
> And generally, I would advise RSI that they should only break
> functional IDL code if:
>
> * it fixes a serious bug (would people classify the Y2K problem in the
> date routines as a serious bug? I'm not sure I do), or;
Certainly
>
> * in IDL 6.
Well, if you inclide the obsolete directory to your search path, your
code should still work. And I think the RSI folks are already doing a
tremendous job in terms of backward compatibility. In fact, sometimes
I wish they could go much more overboard and throw away some of this
old ballast that has piled up in IDL over the years. Maybe version 6
could really be a good point to say:
"Hey folks, here it is. We've cleaned the thing up, so now it's
your turn (to clean up your code). If you don't want to pay for that
cleaning woman, then please stick to version 5.<last> . We are sure
you can do tremendous work with this version already." ;-)
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 [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
| Re: IDL compatibility [message #23130 is a reply to message #23127] |
Wed, 10 January 2001 15:32  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"Craig Markwardt" <craigmnet@cow.physics.wisc.edu> wrote in message
news:onpuhvhv1v.fsf@cow.physics.wisc.edu...
> [stuff about commonly-used IDL routines being made obsolete]
Just adding to Craig's message (with which I fully agree) perhaps not
everyone is aware of the !WARN system variable. From the documentation:
!WARN
A structure variable that causes IDL to print warnings to the console or
command log when obsolete IDL features are found at compile time. !WARN has
the following fields:
*****
** Structure !WARN, 3 tags, length=3:
OBS_ROUTINES BYTE 0
OBS_SYSVARS BYTE 0
PARENS BYTE 0
TRUNCATED_FILENAME BYTE 0
Setting each of the four fields to 1 (one) generates a warning for a
different type of obsolete code [remainder deleted]
*****
A routine is considered to be obsolete if it has "compile_opt OBSOLETE" in
the header or if its .pro file is in a directory named "obsolete".
By the way, I find it amusing that in if !warn.obs_sysvars is set in IDL
5.3, then several warning messages are produced in compiling XMANAGER! This
has been fixed in version 5.4.
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
