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

Some notes:

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.

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.

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

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.

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.

Ian


On Mon, Jun 30, 2014 at 4:10 PM, Joel Andersson <j.a.e.andersson@gmail.com> 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.h.bell@gmail.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 <j.a.e.andersson@gmail.com> 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.e.andersson@gmail.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.

Joel


2014-06-29 16:07 GMT+02:00 Ian Bell <ian.h.bell@gmail.com>:

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.e.andersson@gmail.com> 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 <kris.f.thielemans@gmail.com>:
>
>> 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)