[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question for RSI: Call_external/dlms vs Callable IDL...

It's beginning to dawn on me that I may have misunderstood
something fundamental about the nature of call_external code
vs Callable IDL. This question is mostly directed towards the
friendly people at RSI who follow this newsgroup closely, but
if anyone else have information on this subject, please speak

Is it correct, as I now suspect, that none of the routines
described in the "Callable IDL" section of the External
Development Guide are supposed to work from within
call_external/dlm routines?

I.e., is it supposed to be impossible to use calls like
IDL_ExecuteStr("CALL_PROCEDURE,'myprog',F") inside an added
system routine?

If so, then I *strongly* suggest that you provide at least two
extra functions in the next version, e.g.:

   vptr = IDL_Call_Function("myfunc",argc,argv [,argk]);
   IDL_Call_Procedure("myproc",argc,argv [,argk]);

or possibly more generally:

   vptr = IDL_CallSysFunc("CALL_FUNCTION",argc,argv [,argk]);
   IDL_CallSysProc("CALL_PROCEDURE",argc,argv [,argk]);

The reason I'm asking is that I'm trying to implement the
MINPACK minimization routines (in Fortran) as system routines
in dlms, and for that purpose I need to be able to call
user-written procedures with input/output parameters.

Until yesterday, I was to be under the impression that an
added system routine had a local variable space of it's own
(since IDL_M_NAMED_GENERIC messages do report errors to occur
inside a named routine just like the MESSAGE procedure does
inside normal procedures), and that (named!) local variables
could safely be created/retrieved within this scope with
IDL_FindNamedVariable(), and referred to in execute statements
like "CALL_PROCEDURE,'myprog',F" (communicating the contents
of local variable "F" to and from routine "myprog").

If that's the way it's supposed to work, I have a bug
report. Consider the files idlmfun.pro, idlmder.c and
idlmder.dlm below for an absolutely *minimal* example.  As it
is, you may execute the function idlmder both with and without
a parameter, with no problem.  Note, however, that the
variable FF referred to in the execute string is created at
the $MAIN$ level.

Now, delete the IDL_ExecuteStr("help") call, and recompile
into a dlm. Calling idlmder with no argument still works, but
when given a parameter it crashes:

IDL> idlmder ;; Ok
IDL> idlmder,n
Segmentation fault

This is on { alpha OSF unix 5.2 Oct 30 1998}, btw.

If this is not supposed to work, well, then the
call_external/dlm mechanism is a lot less useful than it could
be (crippled, I'd say), and you definitely ought to spend the
(quite small) effort to tell us how to interface with the
internals of IDL to avoid it..

Those who have gone to great lengths to understand dlms in the
first place are surely capable of understanding how to call
the functions I've sketched above, with almost no further
explanation. Also, having functions like this would be a
benefit anyway, since it'll allow dlms to execute IDL
statements (through procedures/functions) without the
compilation overhead that's associated with every
IDL_ExecuteStr call (even when repeating the same statement a
zillion times).


Stein Vidar

PRO idlmfun,pder
  pder = dblarr(10)

#include "stdio.h"
#include "export.h"

void IDLMDER(int argc, IDL_VPTR argv[])
  IDL_ExecuteStr("help");/* Delete this & die! */

int IDL_Load(void)
  static IDL_SYSFUN_DEF proc_def[] = {
  return IDL_AddSystemRoutine(proc_def,FALSE,IDL_CARRAY_ELTS(proc_def));

BUILD_DATE 21 Apr 1999
SOURCE S. V. H. Haugan