swig + matlab

[malat]

Hi there,

  I just saw that octave support was officially added to swig. Is it
flexible enough so that one can generate matlab mex file ? If not what
would you recommend instead ?

Thanks,
--
Mathieu

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Xavier Delacour]

On Tue, May 13, 2008 at 7:12 AM, Mathieu Malaterre
<mathieu.malaterre@...> wrote:
> Hi there,
>
>   I just saw that octave support was officially added to swig. Is it
>  flexible enough so that one can generate matlab mex file ?

No, at least not out of the box.

I haven't spent much time looking at a Matlab port, but the key
problem appears to be that supporting custom types is not possible
without much later versions (the one released this past March..), or
some undocumented mathworks interfaces (used for their Java bindings I
think). The SWIG runtime at a minimum requires a type that contains
custom data and that generates a call when Matlab wants to free it.
This is used to wrap pointers, classes, and so on.

That issue notwithstanding, most of the module can be reused
(including the test-suite, most of octave.cxx, and most of
Lib/octave/*). Required changes, in a nutshell:

(a) some of the function prototype and parameter handling is changed
to fit mex interface. These are a few simple changes to octave.cxx.

(b) Lib/octave/octprimtypes.swg is changed to use the mex interface to
marshal/unmarshal values.

(c) Either multiple calls are handled in a single mex file, a dispatch
function is added (with the first parameter the call id or something),
and possibly m-files for each call are emitted. Alternatively multiple
mex-files could be emitted for each call.

> If not what
>  would you recommend instead ?

If you want something already working, you might have a look at

http://lnc.usc.edu/~holt/matwrap/

If you want to help with some of the issues above, I would be willing
to invest some time to make the module work with Matlab.

Xavier

>
>  Thanks,
>  --
>  Mathieu
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>  _______________________________________________
>  Swig-user mailing list
>  Swig-user@...
>  https://lists.sourceforge.net/lists/listinfo/swig-user
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user

[Soeren Sonnenburg-9]

On Tue, 2008-05-13 at 10:34 -0400, Xavier Delacour wrote:

> On Tue, May 13, 2008 at 7:12 AM, Mathieu Malaterre
> <mathieu.malaterre@...> wrote:
> > Hi there,
> >
> >   I just saw that octave support was officially added to swig. Is it
> >  flexible enough so that one can generate matlab mex file ?
>
> No, at least not out of the box.
>
> I haven't spent much time looking at a Matlab port, but the key
> problem appears to be that supporting custom types is not possible
> without much later versions (the one released this past March..), or
> some undocumented mathworks interfaces (used for their Java bindings I
> think). The SWIG runtime at a minimum requires a type that contains
> custom data and that generates a call when Matlab wants to free it.
> This is used to wrap pointers, classes, and so on.
>
> That issue notwithstanding, most of the module can be reused
> (including the test-suite, most of octave.cxx, and most of
> Lib/octave/*). Required changes, in a nutshell:
>
> (a) some of the function prototype and parameter handling is changed
> to fit mex interface. These are a few simple changes to octave.cxx.
>
> (b) Lib/octave/octprimtypes.swg is changed to use the mex interface to
> marshal/unmarshal values.
>
> (c) Either multiple calls are handled in a single mex file, a dispatch
> function is added (with the first parameter the call id or something),
> and possibly m-files for each call are emitted. Alternatively multiple
> mex-files could be emitted for each call.

that sounds like (impressively!) few changes...

> > If not what
> >  would you recommend instead ?
>
> If you want something already working, you might have a look at
>
> http://lnc.usc.edu/~holt/matwrap/
>
> If you want to help with some of the issues above, I would be willing
> to invest some time to make the module work with Matlab.

I would certainly be interested in seeing this to happen, but I cannot
do more than testing things or maybe a little of (a) (as I am familiar
with both the octave and matlab interface)

Soeren

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Swig-user mailing list
Swig-user@...
https://lists.sourceforge.net/lists/listinfo/swig-user