Joel Andersson
2016-07-08 20:56:13 UTC
Hi all,
I've spent the last couple of days working on the MATLAB module. Here is a
summary of the current status:
1. The MATLAB module is now MATLAB/Octave bilingual - the generated code
should work for both MATLAB and Octave. I've added an option
"--enable-octave-for-matlab" to configure.ac that instructs the build
system to use Octave instead of MATLAB to test the module. The "import"
command has been eliminated from the unit tests, since this is not
supported by Octave (and is probably bad coding practice in MATLAB).
2. The MATLAB module is different from Octave module in several ways: It
can be either C or C++ (Octave is always C++), it integrates with
MATLAB/Octave native support for object oriented programming, it supports
extending classes with MATLAB code (cf. %pythoncode, very useful IMO). On
the other hand, it's probably slower and has much less unit test coverage
than the Octave module. So it's far from being a drop-in-replacement.
3. I've resolved all (to my knowledge) blocking issues with the unit tests.
Wrapper code for all tests can now be generated and compiled. A reasonable
subset have "runme" scripts that can be executed successfully. I've removed
runme scripts that were copied from the Octave module, but never brought to
a working state. There is definitely work to be done to get a more complete
coverage, but I think that this can be handled by a case-by-case basis and
should not be a blocker for merging with SWIG master. In it's current
state, the module should be very useful for a lot of people.
4. The proxy class code for constructors is hacky and I would like to see
it refactored for maintainability and efficiency. This should be relatively
easy for me to do, but I would need some help for understanding the SWIG
internals in order to complete this task.
5. Directors don't work for Octave and I can't figure out why because the
corresponding code is too hacky (copy-paste from other modules).
Personally, I'd rather not support directors at all than supporting it
through hacky and unmaintainable code. I am willing to work on cleaning up
the director code, but I'd need some pointers on how it's supposed to work.
6. A user guide chapter has yet to be written. I'm willing to take on this
task if there is a clear path to having the module merged.
William, do you think that you'd have time for either a code review or just
a 1h Skype session to discuss the open issues?
Best regards,
Joel
I've spent the last couple of days working on the MATLAB module. Here is a
summary of the current status:
1. The MATLAB module is now MATLAB/Octave bilingual - the generated code
should work for both MATLAB and Octave. I've added an option
"--enable-octave-for-matlab" to configure.ac that instructs the build
system to use Octave instead of MATLAB to test the module. The "import"
command has been eliminated from the unit tests, since this is not
supported by Octave (and is probably bad coding practice in MATLAB).
2. The MATLAB module is different from Octave module in several ways: It
can be either C or C++ (Octave is always C++), it integrates with
MATLAB/Octave native support for object oriented programming, it supports
extending classes with MATLAB code (cf. %pythoncode, very useful IMO). On
the other hand, it's probably slower and has much less unit test coverage
than the Octave module. So it's far from being a drop-in-replacement.
3. I've resolved all (to my knowledge) blocking issues with the unit tests.
Wrapper code for all tests can now be generated and compiled. A reasonable
subset have "runme" scripts that can be executed successfully. I've removed
runme scripts that were copied from the Octave module, but never brought to
a working state. There is definitely work to be done to get a more complete
coverage, but I think that this can be handled by a case-by-case basis and
should not be a blocker for merging with SWIG master. In it's current
state, the module should be very useful for a lot of people.
4. The proxy class code for constructors is hacky and I would like to see
it refactored for maintainability and efficiency. This should be relatively
easy for me to do, but I would need some help for understanding the SWIG
internals in order to complete this task.
5. Directors don't work for Octave and I can't figure out why because the
corresponding code is too hacky (copy-paste from other modules).
Personally, I'd rather not support directors at all than supporting it
through hacky and unmaintainable code. I am willing to work on cleaning up
the director code, but I'd need some pointers on how it's supposed to work.
6. A user guide chapter has yet to be written. I'm willing to take on this
task if there is a clear path to having the module merged.
William, do you think that you'd have time for either a code review or just
a 1h Skype session to discuss the open issues?
Best regards,
Joel