From: Josef P. <jos...@gm...> - 2012-04-04 12:47:27
|
Hello, we are working on the module and deciding how to approach certain issues. Do you have any ideas of how to handle: - classes - pass all data back and forth between matlab and c++ or have some kind of persistent memory (managed by matlab), where the information may be stored? - namespaces - directories or special prefix to each namespace Any other hints or ideas? Did you ever get any help from mathworks other than what is available? I am not quite satisfied with the documentation that they provide. Best regards, Josef Pacula On 27 January 2012 09:09, Joel Andersson <joe...@es...> wrote: > Hello Josef! > > Is there any progress on the Matlab-module front? > > I have to say that I haven't had time to get my work really starting > on my matlab-branch. Sorry everyone for this. My hope is to find a > student you is able to help me doing it. > > Best, > Joel > > 2011/11/14 Josef Pacula <jos...@gm...>: >> Hi, >> >> Sorry for such a long delay. We aren't busy or anything, just >> procrastinating :). >> I think we will start the work soon and should be done by the >> beginning of summer 2012 - that is when our state exam takes place. >> Of course, we think there is no use for everyone to do their >> implementation. We will contribute our results back, if those are >> worth it, that is. >> Also, can anyone comment on whether or not this might be enough for >> two diploma theses (there is two of us:)). I mean, just an estimate. >> Is it too much work? Is it too little? >> Our goal will be to deal with (and maybe more): overloading, classes, >> optional parameters, templates... Rather basic and expected subset of >> C++. >> >> Sorry if I am being confused, I did not have time to read all the >> messages again, so I might be missing something. >> Regards, >> Josef >> >> On 17 October 2011 16:14, Joel Andersson >> <joe...@es...> wrote: >>> Hello Josef, >>> >>> how is this work proceeding? I skimmed through your bachelor thesis >>> quickly and got an idea of the approach you're using. >>> >>> I also started to work a bit myself on our approach for a SWIG Matlab >>> module which is a bit different. Basically, I see no fundamental >>> problems for writing a complete SWIG Matlab module using our approach, >>> which will be very similar in structure to for example the Python >>> module (one Python wrapper file and one internal C file). I do however >>> see some issues of the MEX-approach that you're using, in particular >>> when it comes to persistent memory and the fact that every function >>> will end up in a different compilation unit. But maybe it would be >>> possible to find some way around these issues as well. >>> >>> To be honest, I don't really care too much about _how_ a Matlab SWIG >>> module is implemented, just that it is done in a maintainable way >>> which will work reasonably well so that we can use it in our projects. >>> That means, that it must work well to wrap (template) classes, that >>> STL library is wrapped, with operator overloading working, >>> polymorphism etc. Is it the aim of your work to add a Matlab module to >>> SWIG or are you happy with a module that works for wrapping your own >>> project? >>> >>> I don't think it makes sense to write multiple Matlab modules, so if >>> we could cooperate, then I think that it would be in the interest of >>> everyone. >>> >>> Best, >>> Joel >>> >>> 2011/9/19 Josef Pacula <jos...@gm...>: >>>> On 29 August 2011 20:40, Joel Andersson <joe...@es...> wrote: >>>> Hello to everyone, >>>> >>>> Me and my colleague were working on a proof-of-concept SWIG Matlab >>>> module as our bachelor thesis. >>>> Mine http://is.muni.cz/th/256412/fi_b/thesis.pdf and my colleague's >>>> http://is.muni.cz/th/256594/fi_b/bachelor.pdf >>>> We did not go any too far, we just did a few first steps. >>>> And our intention is to continue further for our master thesis'. >>>> I am sorry for not investigating any further, I just want to inform you. >>>> We should start working quite soon as the semester has started today. >>>> >>>> Best regards, >>>> Josef Pacula >>>> >>>>> 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. >>>>> >>>>> Joel >>>>> >>>>> 2011/8/29 Soeren Sonnenburg <swi...@nn...> >>>>>> >>>>>> 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 <ws...@fu... >>>>>> > > <mailto: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> >>>>>> > > <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. >>>>>> >>>>>> Hmmhh, I don't really agree on this. >>>>>> >>>>>> > BTW, did you see this mail thread - >>>>>> > http://thread.gmane.org/gmane.comp.programming.swig/12883/focus=12886 >>>>>> > 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. >>>>>> >>>>>> Joel, I am just wondering whether it wouldn't be best to base >>>>>> 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. >>>>>> >>>>>> Soeren >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Special Offer -- Download ArcSight Logger for FREE! >>>>> Finally, a world-class log management solution at an even better >>>>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >>>>> download Logger. Secure your free ArcSight Logger TODAY! >>>>> http://p.sf.net/sfu/arcsisghtdev2dev >>>>> _______________________________________________ >>>>> Swig-devel mailing list >>>>> Swi...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/swig-devel >>>>> >>>>> >>>> >>> >>> >>> >>> -- >>> 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 >>> > > > > -- > 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-4408800 (Spain) / > +46-727-365878 (Sweden) > > Private address: Weidestraat 5, 3000 Leuven, Belgium |