Category "IDL"


Finally, for the my last (for now) IDL wish list item: a new widget toolkit. This wish list item is for a native widget toolkit, not the ability to create interactive web pages, though that would be [good too].

This widget toolkit would:

1. be supported on all platforms supported by IDL
2. have a clean, modern look
3. have all the capabilities of the current IDL widget toolkit
4. have an embeddable web browser window
5. have a richer set of features for existing widgets (tables, in particular)
6. be accessible through a consistent, object-oriented API

I think the main candidates currently are wxWidgets, Qt, and GTK. My experience with these toolkits has been with Qt. Potentially, this could be done by piggy backing on the PySide project which created several generic tools for generating bindings that could be used for IDL instead of Python.

All three of these toolkits are license under something close to LGPL. I think[^1] this should work for a commercial product like IDL since only the source code for the widget toolkit and its bindings would have to be provided since the library would be provided as a DLM and not part of the main IDL executable.

[good too]: http://michaelgalloy.com/2015/11/17/idl-wish-list-interactive-graphics-for-the-web.html "IDL wish list: interactive graphics for the web"

[^1]: I am not a lawyer.

When learning IDL many years ago, the first thing that caused me to do a double take was the comma between a procedure name and its first argument when calling it and between either a function or procedure name and its first argument when declaring it. While removing this comma would not provide any noteworthy capability to my code, it would:

1. be one less keystroke per procedure call
2. eliminate approximately 25% of my syntax errors when writing in other languages
3. look a lot prettier
4. eliminate most of the shame I feel when showing non-IDL programmers my IDL code

If `.` can be used for the `->` operator, the extra comma can be removed from IDL!

IDL has had keyword inheritance for a long time. The special keywords `_EXTRA`, `_REF_EXTRA`, and `_STRICT_EXTRA` are used to have a wrapper routine pass its keywords to some routine that it calls. It would be convenient to have corresponding inherited positional parameters, perhaps using the analogous specially named parameter `_extra`:

pro mg_print, _extra, _extra=e
compile_opt strictarr

print, _extra, _extra=e
end

This routine would accept any number of positional parameters/keywords and pass those that `PRINT` accepts along to it.

Harris Geospatial[^1] released IDL 8.5.1 yesterday. The [release notes] show a few nice additions, appropriate to a patch release version: a new `FILE_MODTIME`, an `::IsFoldCase` method for some of the container classes, routines for handling VGroup attributes in HDF4 files, `IDLnetURL::URLEncode`/`IDLnetURL::URLDecode` methods, writing a PNG to a buffer instead of a file, and an update to the HDF4 library.

[release notes]: http://www.exelisvis.com/MyAccount/TabId/175/ArtMID/890/ArticleID/14708/Whats-New-in-IDL-851.aspx "What's New in IDL 8.5.1"
[^1]: Exelis VIS changed their name yesterday too.

I migrated my libraries to git, and GitHub, from Subversion over eight and a half years ago. While there is a bit of a learning curve to git, it is possible to handle basic operations fairly easily. The following is an overview of the basic features of git with some comparisons to Subversion. This basic overview completely omits many features of git; for more information check out the [git docs].

[git docs]: https://git-scm.com/doc "Git - Documentation"

Continue reading "git basics."

Great [essay] about climate change and what you can do about it by Bret Victor:

> This is aimed at people in the tech industry, and is more about what you can do with your career than at a hackathon. I’m not going to discuss policy and regulation, although they’re no less important than technological innovation. A good way to think about it, via Saul Griffith, is that it’s the role of technologists to create options for policy-makers.

Also fascinating is the presentation of his argument and the surrounding facts, particularly the interactive "model-driven debate" text in the [Media] section. He imagines (and has implemented in the article) news articles with input values that the reader can modify to explore different scenarios and output values the reader can click to find an explanation of how they were calculated. Wow!

[essay]: http://worrydream.com/ClimateChange/ "What can a technologist do about climate change? A personal view"

[Media]: http://worrydream.com/ClimateChange/#media "Media for understanding situations"

I wrote an [overview] almost eight years ago about IDL's basic routines to visualize a vector field. Not much has changed since then. This [paper] by Laidlaw, et al, mentioned at the end of my overview, outlines six common visualization techniques and evaluates them on the speed and accuracy of doing common tasks with them.

I think it would be great to have two of the better performing techniques: OSTR (image-guided streamlines, integral curves) and LIC (line-integral convolution) techniques. Between the two of them, they have the best or nearly the best performance in every category. An example OSTR visualization is shown below:

OSTR example

I have tackled LIC and have [code][LIC code] to produce images from vector fields in my library.

[overview]: http://michaelgalloy.com/2008/03/19/overview-of-flow-visualization-in-idl.html "Overview of flow visualization in IDL"

[paper]: http://www.cs.utah.edu/~kirby/Publications/Kirby-10.pdf "Comparing 2D Vector Field Visualization Methods: A User Study"

[LIC code]: http://michaelgalloy.com/2008/04/10/line-integral-convolution-code.html "Line-integral convolution code"

While interactive graphics can be created in IDL, you are currently limited to distributing an IDL application to provide them to others. It would be useful to be able to create interactive web graphics from IDL — particularly if it was just a click or `->save` call from function graphics.

[Bokeh] is a library for Python capable of generating Javascript to display interactive visualizations. Check out its for examples. Bokeh has [bindings] for other languages; all that is required for the language is to output the correct JSON to the Javascript part of Bokeh. Bokeh is BSD licensed so it could be used in a commercial product like IDL.

Of course, Bokeh can be used via the Python bridge right now, but that adds an additional burden to its use.

[Bokeh]: http://bokeh.pydata.org/en/latest/# "Welcome to Bokeh"
: http://bokeh.pydata.org/en/latest/docs/gallery.html#gallery "Gallery"
[bindings]: http://bokeh.pydata.org/en/latest/docs/dev_guide/bindings.html "Language Bindings"

IDL already contains syntax for passing arbitrary (and perhaps unknown beforehand) keywords to a routine using the `_EXTRA` and `_REF_EXTRA` keywords, depending on whether you are passing a variable back to the caller through the keyword. For example, you can do something like this:

pro my_wrapper_routine, _extra=e
my_routine, _extra=e
end

Now, `MY_WRAPPER_ROUTINE` passes all the keywords that `MY_ROUTINE` accepts along to it (ignoring any others, use `_STRICT_EXTRA` on the `MY_ROUTINE` call to generate an error if an unknown keyword is passed in).

It would be useful to have a similar mechanism for positional parameters, making it possible to write routines in IDL which accept an arbitrary number of keywords or pass along parameters to another routine. For example, passing all parameters after the first two to another routine and printing the first "extra" parameter with the new library routine `GET_PARAM`:

pro my_wrapper_routine, a, b, _extra
my_routine, _extra
print, get_param(_extra, 0)
end

What exactly would the `_extra` variable be? I'm not sure. Maybe it isn't even needed in the `GET_PARAM` call, but it certainly is needed in the `MY_ROUTINE` call. Python handles this through tuples and the special `*` notation, maybe IDL can use structures and a bit of new notation?

But I would certainly like to get rid of code like the following:

case n_params() of
0: _sql_query = ''
1: _sql_query = sql_query
2: _sql_query = string(arg1, format='(%"' + sql_query + '")')
3: _sql_query = string(arg1, arg2, format='(%"' + sql_query + '")')
4: _sql_query = string(arg1, arg2, arg3, format='(%"' + sql_query + '")')

IDL has several places where *callback functions* are used to provide a mechanism for IDL library routines to call user-defined functions. For example, in curve fitting routines such as `CURVEFIT` the callback function allows the user to define custom functions that are evaluated by the fitting routine.

For many callbacks, this interface is perfectly adequate. But for some cases, the callback routine requires some data that is not passed to it in the interface defined by the calling routine. In this case, it is typical for the callback routine to use a technique like common blocks to access the data. But even Fortran recognizes the problems with common blocks; surely there must be a better way to do this in 2015.

IDL 8.5 provides just such a mechanism -- [function][function pointers] [pointers][IDLDataPoint]. Objects which inherit from `IDL_Object` and define an `_overloadFunction` method can be called like a function. This would allow passing a function pointer with the appropriate user-define data as a callback function. A reference to object could be kept and the data could be modified as needed.

This would provide a much nicer interface in a wide variety of applications which use a callback routine: numeric routines such as for curve fitting; several areas in widget programming such as `XMANAGER` itself, creating a compound widget, and `WIDGET_TREE` drag and drop; and some networking classes such as `IDLnetURL` and `IDLnetOGCW[CM]S`.

The change should not be difficult, just a check for a string versus and object passed as the callback. Something like:

function mg_call_callback, callback, arg1, arg2, _extra=e
compile_opt stricter

if (size(callback, /type) eq 11) then begin
return, callback(arg1, arg2, _extra=e)
endif else begin
return, call_function(callback, arg1, arg2, _extra=e)
endelse
end

Of course, this is complicated by the fact that the above routine assumes that there are two positional parameters (though it can handle any keywords), but I will save that for another wish.

[function pointers]: http://michaelgalloy.com/2015/08/11/idl-8-5-function-pointers.html "IDL 8.5: function pointers"

[IDLDataPoint]: http://www.exelisvis.com/Company/PressRoom/Blogs/IDLDataPointDetail/TabId/902/ArtMID/2926/ArticleID/14524/New-in-IDL-85-Function-Pointers-and-Dynamic-Methods.aspx "New in IDL 8.5, Function Pointers and Dynamic Methods"

« newer postsolder posts »