Off-topic: functions in *new* DLMs are not taken into acct. after user function has been compiled

[steinhh]

Here's another plugin-unrelated thing. When I compile/run this:

PRO test
    my_procedure,'blah'
END

make_dll, .... ; defines my_procedure previously not in IDL_DLM_PATH
test
END

then IDL claims that my_procedure is not defined when executing test. I believe it simply doesn't recheck the list of built-in routines after compiling a procedure that references a non-existent procedure/function. I think it does re-check for new .PRO-defined procedures/functions, just not DLM-defined ones. I also think it doesn't pick up when a .PRO-defined procedure/function should become shadowed by a new DLM-defined one.

[chris-torrence]

If I recall, for efficiency IDL doesn't scan for new DLM's until you restart (or maybe do a .full_reset). I guess the thinking was that adding a new DLM was a big-enough change that it's not supposed to be done on-the-fly.
Cheers,
Chris

[steinhh]

Not scanning for new DLMs all the time seems reasonable (it does seem to rescan when !DLM_PATH is changed though, not just a one-shot at startup).

But is this how it works for regular routines in !PATH as well? I.e. if you compile a routine X with a call to my_procedure and that is not in the !PATH yet, then change !PATH to include my_procedure, will routine X stay "broken" until recompiled?

Something I forgot to specify earlier is that the new DLM was not just generated but also loaded explicitly with DLM_LOAD after the compilation but prior to the execution of the test routine. I.e.:

PRO test
    my_procedure,'blah'
END

make_dll, .... ; defines my_procedure previously not in IDL_DLM_PATH
dlm_load, .... ; load DLM defining my_procedure
test
END

and still it crashes on the my_procedure call. Checking for newly defined system functions when the alternative is a crash doesn't seem unreasonable :)

[steinhh]

(Although I realise it's not necessarily a tiny fix to do so)

[chris-torrence]

Yeah, that path searching code is pretty tricky, so I would hesitate to perturb it. By "crash" do you mean it doesn't find the routine and IDL reports an error, or does it actually crash IDL completely? If it's "just" an IDL error then I think restarting IDL is reasonable. If it actually crashes IDL then we should probably take a look...

[steinhh]

Just an error report, not a core dump ;-).

Restarting won't help, though, if the DLM is still not in the IDL_DLM_PATH prior to compilation of the same code.

If a software library comes with DLMs that are not in the existing DLM path, precompiled or not, the only way it would work is to ensure that the DLM is found prior to compilation of the .PRO code using it. Which requires a change either in the shell startup script or in the IDL_STARTUP file. Not a terrible solution, but it still requires users to do something more than "just using it inside IDL".

There's one thing that would fix it through a restart though: include !MAKE_DLL.COMPILE_DIR in the standard !DLM_PATH. Libraries containing precompiled DLMs could then copy them there, and all subsequent IDL sessions would work. That's not a complicated fix, can I change my request to that😜?