search

mrkrd / matlab_wrapper

Easy to use MATLAB wrapper for Python
GNU General Public License v3.0
78 stars 23 forks source link

Python3 pass tests and libssl #23

Closed deeuu closed 7 years ago

deeuu commented 7 years ago

Hi,

Thanks for the good work!

Due to the data types of structured arrays, a few tests failed on the python3 branch (at least after I merged with master). All tests now pass using Python 3.5.2 and Python 2.7.12, but for compatibility with Python 2, unicode strings have to be input as data to numpy arrays explicitly (u''). I can't seem to find an elegant solution because dtype field names can't be unicode in numpy (see here).

Also, when first used with Matlab 9.0.0.341360 (R2016a), I got the error: OSError: /opt/MWmatlabR2016a/bin/glnxa64/libssl.so.1.0.0: undefined symbol: EVP_idea_cbc which occurs because Matlab 2016a is using an older version of libssl.. Unfortunately, I don't have permission to modify the system environment, so one workaround is to load the system's libssl prior to loading libeng and libmg.

Only tested on Ubuntu 16.04.2 LTS.

Cheers

mrkrd commented 7 years ago

Hi Dominik,

Thanks for you PR!

Unfortunately, I wasn't able to have a closer look at it yet. Please be patient. Thanks.

Marek

mrkrd commented 7 years ago

Re: libssl workaround

I'm reluctant to merge this part, because it seems to be a local issue and seem to be too invasive to load libssl in every installation of matlab_wrapper on every system. It could have some unpredictable consequences.

If more people report it and we can pinpoint the versions of MATLAB and system where the issue occurs, then we could make it a conditional load behind an 'if'.

For now, I recommend that you load libssl before importing matlab_wrapper if necessary.

mrkrd commented 7 years ago

Re: removal of import unicode_literals and Python 3 compat.

ATM matlab_wrapper is Python 2 compatible and the backward compatibility is one of the most important properties of this library. I don't want to break people's code! So if Python 3 compatibility can be added without loosing the backward compatibility then it can be merged.

I actually believe that's it's better/easier to make a new library by forking matlab_wrapper that would be purely Python 3 compatible. It would also allow to adjust some initial design decisions that went into matlab_wrapper and cannot be changed now.