Re: [Reduce-algebra-developers] interface to NLopt, 0-th step

[Kostas O. <k.o...@at...>]

Dear Arthur,

Thanks, I can test quite easily in the way you suggest.  But it seems
that I'm missing something:

5* in ""nlopt.red"
....
6* {v1,v2,v3} := nlopt_version();
+++ Error bad args for call-foreign-function

So I must be doing something wrong in these lines from nlopt.red:

 % NLOPT_EXTERN(void) nlopt_version(int *major, int *minor, int *bugfix);
 call!-foreign!-function(nlopt_version!*, 'int32, major, 'int32, minor,
'int32, bugfix);

First, I don't really know where the 'int32, etc. are coming from. 
I.e., how does Reduce or CSL know about them?  I am just imitating what
is in gurobi.red.  Second, what about the fact that in the real C
function these are pointers to ints, not actual ints?
Perhaps there is some other code I should be looking at for guidance?

                            Kostas

On 06/05/2014 09:06, Arthur Norman wrote:
>> module nlopt;
>>
>> #if (memq 'csl lispsystem!*)
>>
>> fluid '(nlopt_lib!*);
>   ...
>> endmodule;  % nlopt
>>
>> My question for the moment is: how do I test this with CSL Reduce?  Do I
>> have to put this file in packages/foreign/nlopt/ and rebuild Reduce?
>> Since I
>> am going to be adding more functions and doing repeated testing, I would
>> like to avoid having to rebuild Reduce every time.
>
>