| About call_external, AUTO_GLUE and gcc [message #39564] |
Fri, 28 May 2004 18:54  |
profxtjb
Messages: 22
Registered: October 2003
|
Junior Member |
|
|
I have been working on call_external to some C stuff I have, and today
I was messing with the AUTO_GLUE keyword, but I need a small helping
hand to get it all to work gracefully for me.
Specifically, if I compile and link 'try_glue4.c', containing a
function IDL_INT try( IDL_INT *k), that for example returns *k + 30,
viz.
% gcc -fPIC -c try_glue4.c
% ld -bundle -t -o try_glue4.so try_glue4.o
I get a nice piece of work out of call_external, viz.
IDL> result = call_external('try_glue4.so', 'try', 22, /AUTO_GLUE,
/I_VALUE)
IDL> print,result
52
It all works sweet. Great.
However, if I go back and add some new computation to my function
'try' in the source file 'try_glue4.c' and then save and recompile and
relink to 'try_glue4.so', then the next time I call_external to
'try_glue4.so' there is a repeat of the initial function computation.
It does not use the new function computation.
OK, I can save the changed source file to 'try_glue5.c' and go through
the process with that new file. It seems like you should be able to
flip one of the option switches on gcc or ld so that you can work on
one source file. Or is it some feature of AUTO_GLUE that produces
this trouble.
It is a small matter, but it would sure speed up my work if I could
get this sorted out, learning a bit more about gcc along the way.
GRACIAS
|
|
|
|
| Re: About call_external, AUTO_GLUE and gcc [message #39651 is a reply to message #39564] |
Tue, 01 June 2004 09:16  |
profxtjb
Messages: 22
Registered: October 2003
|
Junior Member |
|
|
"mwvogel" <mvogel@rdiag.fgg.eur.nl> wrote in message news:<c9fsk2$fai$1@brutus.eur.nl>...
<scratching head>
Well, I guess that conclusively concludes the conclusion that I need
to follow the unconventional practice of reading the instructions!
:)
Thanks!
> Concerning CALL_EXTERNAL, there seems to be an /UNLOAD switch. I guess that
> should do it.
> The excerpt from the help file :
> ***************************
> UNLOAD
>
> Normally, IDL keeps Image loaded in memory after the call to CALL_EXTERNAL
> completes. This is done for efficiency
> -loading a sharable object can be a slow operation. Setting the UNLOAD
> keyword will cause IDL to unload Image after the call to it is complete.
> This is useful if you are debugging code in Image
|
|
|
|
| Re: About call_external, AUTO_GLUE and gcc [message #39654 is a reply to message #39564] |
Mon, 31 May 2004 11:13 |
mwvogel
Messages: 9
Registered: February 2003
|
Junior Member |
|
|
"Thomas Brueckner" <profxtjb@earthlink.net> schreef in bericht
news:52e94d00.0405310546.2ab9a1b9@posting.google.com...
> mw vogel <m.vogel@erasmusmc.nl> wrote in message
news:<40B86601.E14DE0DD@erasmusmc.nl>...
>
>> Sounds to me like you want to unload your old DLM from memory, and then
>> reload the newly linked DLM.
>> My favourite way of doing this is by the .f -way :-)
>> The HELP, /DLM will show you what is loaded.
>
> I thought that making a call_external was different from making a DLM.
> In any case, HELP,/DLM gets me a lot of descriptions like
>
Yes, you are right, I got carried away. By the way, there is a performance
gain when coding a DLM.
Concerning CALL_EXTERNAL, there seems to be an /UNLOAD switch. I guess that
should do it.
The excerpt from the help file :
***************************
UNLOAD
Normally, IDL keeps Image loaded in memory after the call to CALL_EXTERNAL
completes. This is done for efficiency
-loading a sharable object can be a slow operation. Setting the UNLOAD
keyword will cause IDL to unload Image after the call to it is complete.
This is useful if you are debugging code in Image, as it allows you to
iterate on your code without having to exit IDL between tests. It can also
be a good idea if you do not intend to make any subsequent calls to routines
within Image.
***************************
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
