Re: [Swig-devel] MATLAB module draft

[William S F. <ws...@fu...>]

Nowadays, I'll only accept new modules if the test-suite is also passing 
including some runtime tests converted from one of the other languages. 
Unfortunately we have too many half working languages which we are very 
hard to stop them from bit-rotting as the tests don't work. SWIG is also 
fairly mature, so I want to keep the quality of the new language modules 
up with the level of maturity of the majority of SWIG. Sorry, if this 
means extra work to finish off some areas, but I think it is for the 
best. You can demonstrate the test-suite by setting up Travis testing by 
modifying the .travis.yml file in your Github branch.

William

On 14/04/14 12:50, Joel Andersson wrote:
> Hello William, all,
>
> Good news, I managed to get a (still incomplete) wrapper of the "class"
> example compiling and running from MATLAB! Including constructors,
> destructors and member functions. You will find the generated interface
> at https://gist.github.com/jaeandersson/10169322.
>
> Compiling and linking it can be done with the one-liner "mex
> example_wrap.cxx example.cxx" inside MATLAB.
>
> I don't think there should be any major problems to completing the rest
> of the "class" example. I had a look at "39.10.14 Prerequisites for
> adding a new language module to the SWIG distribution" and if I
> understand it right, it's enough to have the "class" and "simple"
> examples running, plus some documentation. I'll try to find time to do
> this in the coming weeks. Please let me know if there are some other
> requirements other than those listed.
>
> After that I'll have a look at the other unit tests.
>
> Regards,
> Joel
>
>
>
>
> 2014-04-11 9:48 GMT+02:00 Joel Andersson <j.a...@gm...
> <mailto:j.a...@gm...>>:
>
>     OK, I will have to look into that. I guess you would need to add a
>     data member indicating ownership to my SwigRef MATLAB class (the ABC
>     holding the pointer). Or do you have some other suggestion? In the
>     public API of the software I need a MATLAB interface for we work
>     almost exclusively with reference counted objects, no pointers. So I
>     didn't give this much thought.
>
>     Anyway, I think I would prefer to focus on getting a complete
>     working wrapper for the "class" example and only then move on to
>     more advanced examples. I must say that the programming has been
>     going quite smoothly. Many things can be taken with little
>     modifications from the Octave module (Octave being essentially a
>     MATLAB clone).
>
>     Regards,
>     Joel
>
>
>
>     2014-04-10 21:24 GMT+02:00 William S Fulton <ws...@fu...
>     <mailto:ws...@fu...>>:
>
>         It's not clear how the memory management will work. What will
>         the wrappers look like for :
>
>         %newobject SquareFactory;
>         Square *SquareFactory() { return new Square(10); }
>
>         Factory *Grab() { static Square local(20); return &local; }
>
>         William
>
>
>         On 10/04/14 10:44, Joel Andersson wrote:
>
>             For reference, I updated the code and added support for
>             inheritance and
>             multiple inheritance (diamond problem avoided by adding a
>             swigRef ABC):
>             https://gist.github.com/__jaeandersson/10169322
>             <https://gist.github.com/jaeandersson/10169322>
>
>             Regards,
>             Joel
>
>
>
>             2014-04-10 9:43 GMT+02:00 Joel Andersson
>             <j.a...@gm... <mailto:j.a...@gm...>
>             <mailto:j.a.e.andersson@gmail.__com
>             <mailto:j.a...@gm...>>>:
>
>
>                  Hi!
>
>                  Thank you a lot for your feedback.
>
>                  I _am_ using the work of Josef et al but I decided that
>             it was
>                  easier for me to copy/adapt the parts I need rather
>             than going
>                  through the frustration of debugging and extended a
>             code I don't
>                  fully understand. At the same time, there are some
>             fundamental
>                  issues with their approach that I want to resolve. My
>             interest in
>                  this is that we need a MATLAB interface to our software
>             project (for
>                  which we already use SWIG). I want to make sure that
>             this interface
>                  is going to be essentially as good as a handwritten
>             interface. If
>                  this is not a possible outcome of my work, I'd rather
>             just keep
>                  directing users to the Python interface.
>
>                  What is the fundamental problem with the single entry
>             approach? The
>                  string identifier can of course be replaced by an
>             integer index and
>                  the "if-else if-else if -else" block be replaced by an
>             C++ switch,
>                  which should compile to a lookup table. Is it then still
>                  inefficient? MATLAB MEX functions, which is the
>             preferred way of
>                  interfacing C code, only have a single entry point.
>
>                  I'll update the names of "h" and "this" as suggested.
>
>                  The ownership of the C++ class is achieved by
>             inheriting from the
>                  "handle" class. That turns the MATLAB class into a
>             reference-counted
>                  object and copying is always by reference. The "delete"
>             member
>                  function is MATLAB's way of declaring a destructor,
>             called upon
>                  destruction.
>
>                  Inheritance relation will be added, the only issue is
>             that I still
>                  need to figure out how to avoid multiple copies of the
>             'h' property
>                  in the case of multiple inheritance.
>
>                  Greetings and thanks!
>
>                  Joel
>
>
>                  On Apr 10, 2014 8:16 AM, "William S Fulton"
>             <ws...@fu... <mailto:ws...@fu...>
>                  <mailto:ws...@fu....__uk
>             <mailto:ws...@fu...>>> wrote:
>
>                      On 08/04/14 20:34, Joel Andersson wrote:
>
>                          Hello!
>
>                          I did some work on a MATLAB module in my SWIG fork
>
>             (https://github.com/____jaeandersson/swig/tree/matlab
>             <https://github.com/__jaeandersson/swig/tree/matlab>
>
>             <https://github.com/__jaeandersson/swig/tree/matlab
>             <https://github.com/jaeandersson/swig/tree/matlab>>__)__. I had
>                          look at Josef
>                          Pacula's work
>             (https://github.com/twiho/____Matlab-in-SWIG
>             <https://github.com/twiho/__Matlab-in-SWIG>
>                          <https://github.com/twiho/__Matlab-in-SWIG
>             <https://github.com/twiho/Matlab-in-SWIG>>) and the master
>
>                          theses of him and his colleage, but in the end
>             I decided to
>                          start with a
>                          clean-sheet design. Although I advocated using
>             MATLAB's
>                          ability to call
>                          C shared libraries (via loadlibrary, calllib)
>             earlier, in
>                          the end I
>                          think the safest and user-friendliest is to let
>             all the
>                          calls for a SWIG
>                          module go through one MEX-function.
>
>                          I uploaded some MATLAB interface code for the
>             "class"
>                          example in SWIG.
>                          The code is incomplete, but the message should
>             come across:
>             https://gist.github.com/____jaeandersson/10169322/
>             <https://gist.github.com/__jaeandersson/10169322/>
>
>
>             <https://gist.github.com/__jaeandersson/10169322/
>             <https://gist.github.com/jaeandersson/10169322/>>
>
>                          My plan was to let C/C++ pointers be stored in
>             MATLAB by doing a
>                          reinterpret_cast to a 64-bit unsigned int
>             (uint64_t). This
>                          was suggested
>                          and has been tested in the following (non-SWIG)
>             example on
>                          how to
>                          interface C++ with MATLAB:
>             http://www.mathworks.com/____matlabcentral/fileexchange/____38964-example-matlab-class-____wrapper-for-a-c++-class
>             <http://www.mathworks.com/__matlabcentral/fileexchange/__38964-example-matlab-class-__wrapper-for-a-c++-class>
>
>             <http://www.mathworks.com/__matlabcentral/fileexchange/__38964-example-matlab-class-__wrapper-for-a-c++-class
>             <http://www.mathworks.com/matlabcentral/fileexchange/38964-example-matlab-class-wrapper-for-a-c++-class>>.
>
>
>                          I would be happy to get some feedback on this
>             draft. Also,
>                          if someone is
>                          interested in cooperating on this, please let
>             me know. I am
>                          not sure if
>                          I have the time/resources to finish the module
>             on my own.
>
>                      Hi Joel
>
>                      What are the essential problems for not using the
>             previous work
>                      of Josef Pacula et al? It would be a shame to have
>             another half
>                      finished module if you don't have the resources to
>             finish this
>                      new one.
>
>                      Using a single entry method sounds rather
>             inefficient for any
>                      reasonable sized module. Why not use multiple entry
>             points like
>                      the other languages? They can be generated easily.
>
>                      The 'h' property is cryptic to say the least. I
>             would mangle it
>                      and give it a sensible name. In Java it is called
>             swigCPtr.
>                      Unless 'this' means something special in Matlab,
>             call it 'self'
>                      as that is the naming used throughout SWIG. I don't
>             see anything
>                      around ownership of the underlying C++ class
>             pointers. I would
>                      take a look at the Java module - swigCMemOwn. I
>             don't see any
>                      inheritance relationship between the Matlab Shape
>             and Square
>                      classes, is that in the pipeline?
>
>                      William
>
>
>
>
>             --
>
>             --
>             Joel Andersson
>             Ptge. Busquets 11-13, atico 3
>             E-08940 Cornella de Llobregat, Spain
>             Home: +34-93-6034011 <tel:%2B34-93-6034011>
>             Mobile: +32-486-672874 <tel:%2B32-486-672874> (Belgium) /
>             +34-63-4408800 <tel:%2B34-63-4408800> (Spain) /
>             +46-707-360512 <tel:%2B46-707-360512> (Sweden)
>
>
>
>
>
>     --
>
>     --
>     Joel Andersson
>     Ptge. Busquets 11-13, atico 3
>     E-08940 Cornella de Llobregat, Spain
>     Home: +34-93-6034011 <tel:%2B34-93-6034011>
>     Mobile: +32-486-672874 <tel:%2B32-486-672874> (Belgium) /
>     +34-63-4408800 <tel:%2B34-63-4408800> (Spain) / +46-707-360512
>     <tel:%2B46-707-360512> (Sweden)
>
>
>
>
> --
>
> --
> Joel Andersson
> Ptge. Busquets 11-13, atico 3
> E-08940 Cornella de Llobregat, Spain
> Home: +34-93-6034011
> Mobile: +32-486-672874 (Belgium) / +34-63-4408800 (Spain) /
> +46-707-360512 (Sweden)