comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » IDL compatibility
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
IDL compatibility [message #23131] Wed, 10 January 2001 15:00
Craig Markwardt is currently offline  Craig Markwardt
Messages: 1869
Registered: November 1996
Senior Member
I had a chance to try an IDL 5.3 installation today. I know I am
behind the times, sorry :-)

Anyway, I was a bit surprised to find that one of my programs crashed
because of a call to STR_SEP. Okay, not amazed because one of my
programs crashes, because contrary to popular belief they do that all
the time. :-) Apparently STR_SEP has been declared "obsolete" in IDL
5.3 and above. A new built-in routine, STRSPLIT, is provided which
gives the same functionality, plus more.

I'm glad RSI keeps "improving" IDL. The regular expression aspect of
IDL 5.3 looks tantalizing indeed. However I would urge them to be
careful in the compatibility department. The revelations about STRTOK
and the date routines make me wonder what's going on there. Now that
STR_SEP may disappear too I am a bit more worried. It's been around
since IDL 3 for goodness's sake! It's entrenched!

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.

* 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.

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;

* in IDL 6.

Let's see if I have any sway with the big boys :-)

Craig


--
------------------------------------------------------------ --------------
Craig B. Markwardt, Ph.D. EMAIL: craigmnet@cow.physics.wisc.edu
Astrophysics, IDL, Finance, Derivatives | Remove "net" for better response
------------------------------------------------------------ --------------
[Message index]
 
Read Message
Previous Topic: IDL/Envi basic question
Next Topic: Re: _ref_extra

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 19:35:41 PDT 2025

Total time taken to generate the page: 0.64087 seconds