Re: [Swig-devel] [Swig-user] MATLAB module - work in progress

[Joel A. <j.a...@gm...>]

Hi!

Awesome.  We are 99% in business.  Super work guys.
>

Glad to hear!


> When building with CMake, you need to add a .def file to the list of
> sources that has the contents of "EXPORTS mexFunction" so that mexFunction
> gets exported.
>

OK, will keep that in mind and add to the generator if I get it work.

Generated mexw64 must be on the path - perhaps best to keep it in the
> folder with the generated m files?  Or maybe in the same folder with the
> SwigRef.m and make it part of the same generated namespace?  I have mixed
> feelings on this since the .m files are version/OS agnostic and it is best
> to not mix things that are and are not platform dependent.
>

As I've understood it, each supported MATLAB platform correspond to a
different name suffix so they can live together in the same directory.
Looking at the toolboxes shipped with MATLAB, I see both mex and .m files.
So I would just put it in the same folder as SwigRef.m (although putting it
in the generated namespace should also be fine I guess).


> Naming convention for the output AAA_wrap.cxx could be improved.  I
> propose MODULENAME_wrap.cxx like the other languages. (removing the MATLAB
> from the DLL name).
>

Not sure I understand. My "wrap" files are now named e.g.
"example_wrap.cxx". Maybe some bug?


> I have to manually hack the generated .m files to strip the path to the
> mex file.  Where does the generation of the path happen in the code?  I
> think I could probably fix that.
>

The code you are looking for is the following in matlab.cxx:

  // Create output (mex) file
  f_begin = NewFile(outfile, "w", SWIG_output_files());
  if (!f_begin) {
    FileErrorDisplay(outfile);
    SWIG_exit(EXIT_FAILURE);
  }

  /* To get the name the mex function (when calling from Matlab), we remove
the suffix */
  mex_fcn=NewString(outfile);
  char *suffix = Strchr(mex_fcn,'.');
  char *suffix_end = Char(mex_fcn)+Len(mex_fcn);
  while(suffix!=suffix_end) *suffix++ = ' '; // Replace suffix with
whitespaces
  Chop(mex_fcn); // Remove trailing whitespaces


> With my hacking, I can call my function, which is very exciting, and
> suggests that pretty much everything else will work too.  Only a few small
> things remain it would seem.
>

Cool!

Best regards,
Joel





> Ian
>
>
> On Mon, Jun 30, 2014 at 4:10 PM, Joel Andersson <j.a...@gm...
> > wrote:
>
>> Hi! Yeah, my MATLAB is also a bit out-of-date... But working on this
>> module did force me to read the MATLAB documentation, discovering some neat
>> new features... About CMake, I also need that. We also use CMake in our
>> project, including for building the Python front-end using SWIG and for the
>> now-deprecated Octave front-end.
>>
>> All the best,
>> Joel
>>
>>
>>
>>
>>
>> 2014-06-30 16:01 GMT+02:00 Ian Bell <ian...@gm...>:
>>
>> Ah sorry I guess a lot of these issues are due to my experience with
>>> MATLAB being a few years out of date.  Last time I used MATLAB they didn't
>>> have namespaces :)  Thanks for the reply, I'll see about at least making
>>> sure I can run the simple example, and work from there.
>>>
>>> CMake integration isn't too painful, now that I understand it.  The
>>> learning curve is mighty steep, but once you "get it" it's a huge
>>> time-saver.
>>>
>>>
>>> On Mon, Jun 30, 2014 at 3:47 PM, Joel Andersson <
>>> j.a...@gm...> wrote:
>>>
>>>> Hi Ian,
>>>>
>>>> The MATLAB module is as you see still in a quite rudimentary state...
>>>>
>>>> 1. I am doing out-of-source builds using CMake, and when I do, I get
>>>>> hardcoded paths in the generated M files (see attached).  Furthermore, the
>>>>> name of the hardcoded path is the location of CoolProp_wrap.cxx, not the
>>>>> DLL that is compiled.
>>>>>
>>>>
>>>> This has to do with the fact that the mex-name is now just the
>>>> "outfile" attribute with the suffix dropped. That is not generally the case
>>>> of course. I would have a look at how generators for other languages handle
>>>> this.
>>>>
>>>>
>>>>> 2. The SwigRef.m file is not generated in the same folder as the rest
>>>>> of the .m files
>>>>>
>>>>
>>>> That's by design. The idea was to have a single SwigRef class common
>>>> for all modules. The SwigRef is in the directory which you should add to
>>>> your MATLAB path.
>>>>
>>>>
>>>>> 3. It doesn't seem too happy with the generated M files and when I try
>>>>> to call one of the functions, it gives me an error like:
>>>>>
>>>>> >> PropsSI('T','P',101325,'Q',0,'Water')
>>>>> ??? Undefined function or method 'PropsSI' for input arguments of type
>>>>> 'char'.
>>>>>
>>>>> - there is definitely a PropsSI.m file in the working directory.
>>>>> Maybe the parsing errors are keeping the function from being called?
>>>>>
>>>>
>>>> Normally, the package (the directory beginning with +) should be in
>>>> your path, not the .m files. You import the package by issuing "import
>>>> your_module_name.*" or use a namespace qualifier: "your_module_name
>>>> .PropsSI(...)".
>>>>
>>>>
>>>>>  4. The generated mexw64 file exports no symbols.
>>>>>
>>>>> How are you building examples?  For instance, how do you build and run
>>>>> the simple example?
>>>>>
>>>>
>>>>  So far I only built and linked it from inside MATLAB, e.g. "mex
>>>> example_wrap.cxx example.c" for the "simple" example. Building from the
>>>> command line (or with CMake) would be great of course, but I have not
>>>> looked into that yet. But I think this is more of a MATLAB/MEX issue than a
>>>> SWIG issue.
>>>>
>>>> If you manage to fix some stuff, please consider forking and making a
>>>> pull request.
>>>>
>>>> Best regards,
>>>> Joel
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Ian
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jun 29, 2014 at 8:01 PM, Joel Andersson <
>>>>> j.a...@gm...> wrote:
>>>>>
>>>>>> Hi Ian!
>>>>>>
>>>>>> We work from https://github.com/jaeandersson/swig and
>>>>>> https://github.com/KrisThielemans/swig (branch: matlab). They are
>>>>>> currently in sync. You can fork either of those and add both as remotes.
>>>>>>
>>>>>> There are no particular command line options. For usage, check the
>>>>>> examples that have already been translated.
>>>>>>
>>>>>> Joel
>>>>>>
>>>>>>
>>>>>> 2014-06-29 16:07 GMT+02:00 Ian Bell <ian...@gm...>:
>>>>>>
>>>>>> Nice work guys!  I'm keen to give the MATLAB module a shot - what
>>>>>>> forks are you working from?  I understand there are no docs yet, is
>>>>>>> there anything special in the use of the matlab module that differs
>>>>>>> from lets say octave aside from changing -octvave to -matlab?  I'm
>>>>>>> sure there will be some issues, but I can't tell you how excited I am
>>>>>>> to have a working MATLAB module in Swig.
>>>>>>>
>>>>>>> On 6/29/14, Joel Andersson <j.a...@gm...> wrote:
>>>>>>> > Hi!
>>>>>>> >
>>>>>>> > Some really great work there, great! I have pulled those commits.
>>>>>>> >
>>>>>>> > Two major remaining tasks are to add support for multiple modules
>>>>>>> and
>>>>>>> > directors. I will make a shot at multiple modules and then I will
>>>>>>> > transition to work on wrapping my C++ project and address issues
>>>>>>> appearing
>>>>>>> > out doing that.
>>>>>>> >
>>>>>>> > It would be really great if there are more people willing to
>>>>>>> contribute,
>>>>>>> > for example by setting up the unit testing.
>>>>>>> >
>>>>>>> > Best regards!
>>>>>>> > Joel
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > 2014-06-28 17:43 GMT+02:00 Kris Thielemans <
>>>>>>> kri...@gm...>:
>>>>>>> >
>>>>>>> >> Hi all
>>>>>>> >>
>>>>>>> >> Some more progress checked-in at
>>>>>>> https://github.com/KrisThielemans/swig
>>>>>>> >>
>>>>>>> >>  * fixed problem in typecheck for passing mxArray (was still
>>>>>>> using Octave
>>>>>>> >> classes)
>>>>>>> >> Therefore we can now write functions that take mxArray objects
>>>>>>> and do
>>>>>>> >> something clever with them.
>>>>>>> >>
>>>>>>> >> * emit autodoc for functions (and remove Octave-specific texinfo
>>>>>>> stuff)
>>>>>>> >> In some cases, the documentation string still contains C++ types
>>>>>>> as
>>>>>>> >> opposed to matlab types (this is indicated as a TODO in
>>>>>>> matlab.cxx).
>>>>>>> >> There is still no class documentation (not sure where I'd get it
>>>>>>> from
>>>>>>> >> anyway).
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> This is now working well for me. A few remaining problems:
>>>>>>> >> - the memory problem with "clear all" from the previous email
>>>>>>> >> - I think we need to change the solution for indexing (I don't
>>>>>>> think we
>>>>>>> >> can rely on the user making a "getitem" function)
>>>>>>> >> - in a few cases, I'm still missing a set function for variables
>>>>>>> (derived
>>>>>>> >> class?)
>>>>>>> >> - no automatic test cases (swig tests don't work on windows as
>>>>>>> far as I
>>>>>>> >> can see, and I don't have matlab on linux at present).
>>>>>>> >> - no documentation
>>>>>>> >>
>>>>>>> >> Kris
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Joel Andersson, PhD
>>>>>> 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, PhD
>>>> 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, PhD
>> 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, PhD
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)