| Re: XSTRETCH and Library Lessons [message #48464 is a reply to message #48463] |
Mon, 24 April 2006 06:30   |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
JD Smith writes:
> XSTRETCH is pretty fun. I especially like the curve plot for
> non-linear (but why not draw it for linear as well?). I downloaded
> the new version, and immediately had problems: the histogram didn't
> show up for me any longer, as it did in older versions. Just a gray
> background. The min/max lines showed, and could be interacted with,
> but no histogram.
>
> Surely, I thought to myself, the good Dr. Fanning would not distribute
> such a mal-configured tool.
Sigh...
> So I looked into a bit deeper. It turns
> out, among the bread and butter COYOTE routines like FSC_COLOR and
> TVIMAGE, and FSC_FILESELECT, I had 3-4 copies of each of these on my
> IDL_PATH, included directly in other libraries, like PAN, ICG, CM,
> etc. Presumably you have since updated those files, and a standard
> load path shadowing issue (aka name space collisions --- the wrong
> routine of the same name getting called) caused XSTRETCH to break in a
> most unilluminating way.
This is really starting to be a pain. And not just for people
who download the library. It's a pain for me. When I write an
application for a client, I ship a snapshot of my library. But
I have to save that snapshot somewhere, because if my library
evolves, there is a good chance the client code won't work as it
did before a year or so down the road. Trying to work with this
old code and get your IDL path set up correctly is a problem
only truly appreciated by masochists and others of that ilk.
And in my latest offerings (XSTRETCH and TERMINATOR_MAP) I am moving
into a new realm: code that uses not only my libraries, but code
from other libraries as well. I've decided NOT to distribute code from
other libraries, as you suggest, but I see only nightmares ahead of me.
*Someone* has to support this stuff, and we are fast approaching the
Microsoft moment where we start pointing fingers at everyone else.
And, as you also suggest, some of the problems created by
name space collisions are not easily solved. In fact, not
even reproducible on my system! VERY hard to solve.
(The standard solution to a non-reproducible problem, as anyone
who has ever called a technical support line knows, is to reinstall
*everything* and see if this helps. About 90% of the time it does,
which ought to tell us something. Incidentally, the other 10% of
the problems we can reliably blame on idiotic system administrators.)
> The final solution, if you feel your users are too lazy to sort any of
> this out, is just to compile a .sav file of your entire library, and
> distribute that. These don't suffer name space collisions. As long
> as they are loaded first, their versions of, e.g., TVIMAGE, will trump
> any others, and since they have to explicitly or implicitly loaded,
> the true-blue TVIMAGE would continue to load and work as expected in
> sessions where your tool isn't being used.
Humm. Then we only have to maintain save files for 5e15 different
combinations of IDL and the library. I like it!! :-)
> P.S. IDLWAVE can help you identify offenders.
This is a help, but I think RSI should be investing some thought
on making it easier for people to maintain their IDL paths. In my
experience this is the real problem. Especially in UNIX systems,
a great many users have NO idea how to manipulate their IDL paths.
And even those who do know can't seem to get it right a surprisingly
large percentage of the time.
In one famous case, I had to make a trip to Munich to get my
Catalyst Library installed. And even though I worked two doors
down from a nice man and extremely competent IDL programmer,
it took us nearly two weeks to be working from the same page! Lord
knows just *thinking* about making a change to this library caused
me to sweat! :-)
(I will say that the excellent conversations and companionship
on long walks in the country or when fumbling with our prayer beads
in the Andechs Monastery more than made up for the disadvantages
of IDL library installation, however.)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
