Re: [Swig-devel] Request for a Matlab-branch

[Joel A. <joe...@es...>]

2011/8/27 William S Fulton <ws...@fu...>

> 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>). 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.

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.

Finally, about making a complete module, which will be merged with trunk I
don't want to give false hope here. My first goal would be a
proof-of-concept which would allow me to get an idea of how much work it
would be to go all the way. Whether a couple of days or some weeks. Also, I
am not sure at all that I would be the person to finish it, ideally I would
find someone new in our research group, who would at the same time get
proficient in developing our tool. Or we'll divide the work between us. Is
it not possible to create a branch just to test an idea?

Best,
Joel

P.S. Feel free to add CasADi (www.casadi.org) to the list of "Open-source
projects using SWIG" on the website

-- 
Joel Andersson, PhD Student
Electrical Engineering Department (ESAT-SCD), Room 05.11,
K.U.Leuven, Kasteelpark Arenberg 10 - bus 2446, 3001 Heverlee, Belgium
Phone: +32-16-321819
Mobile: +32-486-672874 (Belgium) / +34-63-4452111 (Spain) /
+46-727-365878(Sweden)

Private address: Weidestraat 5, 3000 Leuven, Belgium