RE: foreign function interface

[Lippert, Ross A.]

What about, instead, something less ambitious, but almost as powerful.  Suppose
that one had an "instant oct-file" version of mkoctfile, which produces a .oct
wrapper for a given function from a given library given some signature 
information
(and perhaps C, C++, Fortran linkage information).  This instant-octfile program
would be run outside octave (or within octave via system()).

e.g.
% inst-oct sqrt /lib/libmath.a -o ~/octave/oct-files/mysqrt.oct -sig 
'(double)*f(double)'

I think in practice, people would be just happen to ^Z out of octave, do 
something
quick to their favorite lib, and then jump back in and have the DLD available.  
Perhaps
some octave functions could be written which supply common signatures to a
system('inst-oct ...') call.

Anothing way to get .oct files written quickly, which people may like a lot if 
some sort
of template (like the famous oregonator example) file which can be instantly 
conjured into
an editor (which saves us the time to look up the oregonator example in the 
handbook).
A well commented template can be the key to fast function development.

-r

-----Original Message-----
From: Andy Adler [mailto:address@hidden
Sent: Monday, December 16, 2002 11:40 AM
To: Paul Kienzle
Cc: address@hidden
Subject: Re: foreign function interface


This is a great idea.

The best similar concept I'm aware of is Perl's Win32::API.
It is used like this:
    use Win32::API;
    $GetPID = new Win32::API("kernel32", "GetCurrentProcessId", '', 'N');
    $PID = $GetPID->Call();

This allows direct access to windows dll's.
The only tricky part is packing data into the appropriate
structs for each dll to use.

In order to offer a similar function from octave, we would
need something like perl's "pack" function.

I was thinking (for other reasons) that a we need a "sread"
and "swrite" analgous to "fread" and "fwrite".

These functions would read and write to a string (or other
byte data vector) rather than to a file.


Andy


On Sat, 14 Dec 2002, Paul Kienzle wrote:

> Hi, all.
>
> I've been trying to think of ways to lower the barrier for contributions to
> octave. In particular, there are a lot of prefectly good libraries out there
> that people could call if it were easy to call them. While oct-file
> programming is much easier than mex-file programming, I believe we can do
> even better than that.  I would like for us to be able to directly call
> sharable object code from a script without writing a DEFUN_DLD wrapper.
>
> The technique is called variously a foreign function interface or a native
> call interface.  Given a native type signature (e.g., double sin(double)) we
> should be able to have a definition ffi("libm","sin","dd","Nsin") which
> defines the octave function Nsin, which you could then call from octave as x
> = Nsin(y).  For extra convenience it would be nice to automatically apply
> scalar functions like this element-wise on a vector.  Functions like sqrt
> would be a problem, but these could be handled easily enough from a script
> such as: function x=sqrt(y), x = Nsqrt(abs(y)); x(y<0) *= 1i; end
>
> There are three approaches that I've encountered for doing this:
>
> (1) fortran style:  everything must be a pointer.  This is less than ideal
> since a lot of functions don't operate on pointers, so users would have to
> wrap the library functions with functions that accept pointers.  This is
> still easier than figuring out how to use the octave_value properly.  R
> seems to do this.
>
> (2) predefined type signatures: predefine functions for all the possible
> type signatures that you might want to call.  In principle you could write
> special functions for each possible type signature.  E.g., ffi(...,"dd",...)
> would call a function like dd_chain(double (*f)(double),octave_value &ov)
> which internally would be defined like:
> octave_value dd_chain(double (*f)(double), octave_value &ov)
>     Matrix in(ov.matrix_value());
>     Matrix out(ov.rows(),ov.columns());
>     const double *pin = in.data();
>     double *pout = out.fortran_vec();
>     for (int i=0; i < in.length(); i++) { pout[i] = (*f)(pin[i]); }
>     return octave_value(out);
> The problem with this approach is that the various combinations of
> void/character/integer/float/double/complex, and pointers thereto leads to a
> small
> explosion in the number of functions.  I believe Perl does this with its
> native call interface (or it will in Perl6 whenever that is released.)
>
> (3) compiler-like call.  Build a stackframe, jump to the function and await
> the return.  This is the ideal way since it is not limited in terms of the
> number or type of paramters, but it is very machine dependent.  libffi
> provides this for a number of platforms.
>
> Does anyone have experience in this sort of thing? Does it sound like a
> worthwhile venture?
>
> Paul Kienzle
> address@hidden
>
>