Skip to content

Conversation

@deeuu
Copy link

@deeuu deeuu commented Jul 17, 2017

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
Copy link
Owner

mrkrd commented Jul 30, 2017 via email

mrkrd pushed a commit that referenced this pull request Aug 3, 2017
@mrkrd
Copy link
Owner

mrkrd commented Nov 10, 2017

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
Copy link
Owner

mrkrd commented Nov 10, 2017

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.

@mrkrd mrkrd closed this Nov 10, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants