Hello Soeren and William,
The SWIG's Octave uses Octave's C++ API rather than MEX, as far as I've understood it (we are using this module in our project), so it's not so easily portable to Matlab.
Dispite this, I think that you're right that the easiest would be to base a Matlab module on the Octave module. If I would follow their approach, I would generate just one Matlab class, called swig_ref, deriving from "handle" and let all the function overloading be resolved in a C proxy. Global functions and constructors are also instances of swig_ref, acting at functors.
A "prettier approach" however would be to build up a class hierarchy in Matlab and let the function overloading be resolved by the Matlab interpretor. Global functions that only contain built-in types need to be wrapped in separate m-files calling the C proxy. The wrapper files would also contain documentation, just like in the Python case. If I have to program it myself, I would probably take the "easier" approach though.
About MEX, it might make sense to use MEX to port the input and output typemaps, but I still think it is better to avoid for wrapping the classes.
Are Xavier's mails on design decisions for a Matlab module archived somewhere? If not, I would of course be happy for any feedback. I won't start coding for another month or so.
Hmmhh, I don't really agree on this.On Mon, 2011-08-29 at 11:53 +0100, William S Fulton wrote:
> On 27/08/11 20:23, Joel Andersson wrote:
> > 2011/8/27 William S Fulton <email@example.com
> > <mailto:firstname.lastname@example.org>>
> > On 27/08/11 16:35, Joel Andersson wrote:
> > Hello SWIG developers!
> > I would like to create a new branch in the svn repository to
> > test adding
> > support to Matlab. As a first step it will be just a
> > proof-of-concept to
> > get an idea of it will work well and report back to the mailing
> > list.
> > Ultimately, we would like to use the Matlab branch to generate a
> > Matlab
> > front-end to a symbolic framework for automatic differentiation and
> > numerical optimization called CasADi (www.casadi.org
> > <http://www.casadi.org>
> > <http://www.casadi.org>). We already use SWIG to generate
> > front-ends to
> > Python and Octave which is working fine, partly because the
> > development
> > of CasADi has been made with SWIG in mind.
> > The Matlab module will consists of two parts:
> > 1. One C++ to C interface (possibly based on the c-interface in the
> > gsoc2008-maciekd branch). This will be completely independent on
> > Matlab.
> > It will be compiled to a shared library.
> > 2. A Matlab interface written completely in Matlab m-files, i.e. not
> > using MEX. The Matlab code generation will create a base class
> > inheriting from "handle" with all derived classes inheriting
> > from this
> > base class. The Matlab constructor, destructor and member
> > functions will
> > call the calllib function accessing the functions of the C
> > interface.
> > I would be grateful for any comments before starting coding and
> > if there
> > is some other active project for adding Matlab support to SWIG,
> > I would
> > consider joining this effort instead of creating a new branch.
> > Hi Joel
> > I don't follow why you need the C++ to C language module run
> > independently to make Matlab wrappers. Why not use one single Matlab
> > target language? This is the approach every other language takes.
> > Many of the languages generate an intermediate C layer and then
> > generate pure target language proxy classes on top of the C layer.
> > The C layer is often specific to what the proxy classes require, eg
> > using types in the C intermediate layer that are specific to the
> > target language.
> > I havn't heard of any work in progress for Matlab wrappers, but
> > you'd best pick up some of the mail threads about this subject on
> > the swig-user list to see if someone else has started something.
> > I'm willing to get you access to develop on a branch provided you
> > follow the coding guidelines and use the test-suite to show that it
> > is finished to a high enough standard for merging to trunk. Full
> > details http://www.swig.org/Doc2.0/__Extending.html
> > <http://www.swig.org/Doc2.0/Extending.html>.
> > We have a few branches now that aren't quite good enough for
> > releasing from trunk because the original authors havn't gone the
> > last mile. There are also some language modules that are shipped
> > with SWIG and are in an even worse state. I don't want to exacerbate
> > the problem. I don't want to put you off especially as it isn't too
> > hard to get a quality working language module as very large part of
> > the difficult stuff is already provided in SWIG core.
> > Hello William,
> > thanks for a fast answer. The reason why I wanted to make the C code
> > independent of Matlab was really just motivated from our own project,
> > where a C front-end would be interesting in its own right. But it's not
> > so important. If it turns out to be easier to write a Matlab-syntax
> > dependent C proxy, that would be ok too.
> > The point is that I would prefer generating Matlab-code and call the C
> > code using loadlibrary/calllib, which is more readable and easier to
> > maintain than to generate MEX code.
> Okay. I suspect that is very much a decision based on Matlab experience.
Joel, I am just wondering whether it wouldn't be best to base
> BTW, did you see this mail thread -
> which seems to imply not much is needed to get MEX code support.
> > I checked the mail threads for the Matlab interface and I didn't see any
> > recent activity. And I think it would probably be easier to write
> > something new from scratch than to pick up an unfinished project,
> > correct me if I'm wrong. I did mail to the swig-user some weeks ago and
> > did indeed got some response from people that were interested in using
> > it, but the real motivation would of course be to get a maintainable
> > front-end to our software.
> It is usually much easier to copy and modify an existing module than
> start from scratch. It is a matter of finding one that is most suitable.
> If you give examples of the generated code you want I can recommend some.
swig-matlab on swig-octave - maybe even 'just' using octave's mex
emulation such that one needs to maintain only one such wrapper. Xavier
is the one who wrote the octave swig wrapper and even started the matlab
one (but lacking time stopped working on it - almost immediately) - so
you could ask him for the batch of emails with some design ideas he had
back then if you really want to pursue this.