OK, no problem. We need essentially all SWIG features anyway to be able to wrap our C++ project, so it doesn't hurt addressing right away.

I've never managed to get the test suite running on the Mac that I'm developing on, but I guess I could find a Linux machine.

Thanks for your help!

2014-04-15 21:34 GMT+02:00 William S Fulton <wsf@fultondesigns.co.uk>:
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.


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.


2014-04-11 9:48 GMT+02:00 Joel Andersson <j.a.e.andersson@gmail.com

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


    2014-04-10 21:24 GMT+02:00 William S Fulton <wsf@fultondesigns.co.uk

        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; }


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



            2014-04-10 9:43 GMT+02:00 Joel Andersson
            <j.a.e.andersson@gmail.com <mailto:j.a.e.andersson@gmail.com>



                 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
                 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
                 object and copying is always by reference. The "delete"
                 function is MATLAB's way of declaring a destructor,
            called upon

                 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!


                 On Apr 10, 2014 8:16 AM, "William S Fulton"
            <wsf@fultondesigns.co.uk <mailto:wsf@fultondesigns.co.uk>

            <mailto:wsf@fultondesigns.co.uk>>> wrote:

                     On 08/04/14 20:34, Joel Andersson wrote:


                         I did some work on a MATLAB module in my SWIG fork


            <https://github.com/jaeandersson/swig/tree/matlab>>__)__. I had

                         look at Josef
                         Pacula's work

            <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
                         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
                         example in SWIG.
                         The code is incomplete, but the message should
            come across:


                         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:


                         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
                     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?



            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)


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)