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,Joel2014-06-30 16:01 GMT+02:00 Ian Bell <email@example.com>:
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 <firstname.lastname@example.org> 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 filesThat'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:
??? 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,JoelIanRegards,
On Sun, Jun 29, 2014 at 8:01 PM, Joel Andersson <email@example.com> 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.Joel2014-06-29 16:07 GMT+02:00 Ian Bell <firstname.lastname@example.org>: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 <email@example.com> wrote:
> 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!
> 2014-06-28 17:43 GMT+02:00 Kris Thielemans <firstname.lastname@example.org>:
>> Hi all
>> Some more progress checked-in at https://github.com/KrisThielemans/swig
>> * fixed problem in typecheck for passing mxArray (was still using Octave
>> 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
>> 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
>> - 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