IDL 8.2 was released today, and while it might not have many headline grabbing features, there are some nice additions to IDL’s libraries as well as some fixes for old problems. The Workbench finally seems to work for me; a bug in the way curl library was linked was fixed, allowing me to use OPeNDAP on my Mac. Unlike releases like IDL 8.0 with its many new features and also many new bugs, IDL 8.2 feels much more stable to me.

Continue reading “IDL 8.2 review.”

In addition to VISualize coming up soon in June, Exelis VIS is holding a fall User Group meeting as well:

The IDL User Group Meeting 2012 will be held September 19-20 at the beautiful LASP facility on CU-Boulder’s East Campus. Please join us for presentations by members of the IDL community and by the IDL development team at Exelis VIS. We’ll also have a competition for the best IDL visualization. Pre-registration will be required since seating is limited.

The preliminary schedule is:

Day 1 (Wed Sep 19):

• Short workshops on selected topics in IDL (bring a laptop, if you wish)
• Presentations by the IDL development team
• User discussion groups

Day 2 (Thu Sep 20):

• User presentations
• Visualization contest

I will definitely be there (especially since it’s less than two miles from here)!

Ars Technica has a summary of Stack Exchange responses to the question:

I’m working on a project solo and have to maintain my own code. Usually code review should be done by someone other than the author so the reviewer can look at the code with the fresh eyes. I don’t have such luxury. What practices can I employ to more effectively review my own code?

There are some good suggestions listed for what I think is a common situation, e.g., scientists developing code for their own use.

Of course, I would recommend writing some unit tests as well.

The IDL Data Point has a post showing an example of using the new object-oriented interface for user functions in ENVI 5. Mark discussed batch programs in ENVI 5 last week.

I don’t look forward to rewriting old ENVI user functions, but the new interface does look much better than the clunky old ENVI programming interface. My biggest question is how well is it documented?¹

This year’s VISualize, the IDL/ENVI User Group meeting, will have the theme “Climate Change and Environmental Monitoring.” It will be held June 18 to 19 in the World Wildlife Fund Conference Center in Washington, DC.

Exelis VIS is now accepting abstracts—due May 18! Not sure what I should talk about this year (I’ve talked about GPULib for the past couple of years), but I will definitely submit something and attend in any case.

While looking up some Python docs generated by the excellent Sphinx documentation tool¹, I noticed that Sphinx can show/hide the prompts and output in a code snippet. This allows the user to see the full code and output, but then can hit a button and get text suitable for cut-and-pasting onto the command line to try it for themselves. Check out my simple experiment to see how it works.

I will definitely have to work this into an IDLdoc release soon.

David Fanning says he is retiring from IDL:

I’m retiring. No, really, this time I’m really retiring. :-)

Hopefully this is a false alarm, but in any case, good luck David and thanks for years of valuable information!

The IDL Data Point recently had an article about writing a simple main-level program at the bottom of each file which would give an example or test of the routine(s) in the files. I like this idea and have been doing it for quite a while, but one of the annoyances of this approach is that I also typically want the code to be included in the documentation for the routine, so I end up copy-and-pasting the code into the examples section of the docs (and, of course, reformatting it for the doc syntax). Also, the main-level program just is a place to put some code, I have to do all the work if I actually want to write multiple pass/fail tests.

Continue reading “Doc testing thoughts.”

Jason Ferrara, of Jacquette Engineering for Research, the creators of Slither, on getting an OpenGL context of an IDL object graphics window:

IDL doesn’t provide any way to access or manage OpenGL contexts. IDL Object Graphics does use OpenGL to do its drawing though, so there must be valid OpenGL contexts floating around in there somewhere. It’s a reasonable assumption (and testing shows it to be true) that when the Draw method of an IDLgrModel object is called, the current OpenGL context is set to the window into which the model should be drawn.

This is from one of a series of articles about using this trick along with Slither to have PyMOL draw into an IDL object graphics window.

I’ve been trying to get a way to get an OpenGL context for awhile. I definitely will be keeping an eye out for future articles from Jacquette.

Instead of just listening to me complain about Xcode 4.3 in Lion, I thought you might like some backgrounds for your iPhone. I have both lock screen and home screen versions. The images are subsets of the first image described in my entry to the ITT VIS User Group Meeting a couple years ago (and now appears at the top of this blog):

These images show a line-integral convolution (LIC) representation of the global NASA wind velocity data. The first image shows the LIC output, while the second and third images combine the LIC output with the Earth image in the IDL distribution. The fourth image shows the combination texture mapped on a sphere representing the Earth’s surface. Dark colors represent low velocity winds, lighter colors higher velocity winds. All aspects of the creation of the images were done in IDL. The code to compute the LIC was written in C and integrated with IDL using a DLM. The data access was done from NASA’s DAP server using OPeNDAP’s client IDL bindings (another DLM).

Images are retina sized, i.e., iPhone 4/4S only.