Closed dlaidig closed 4 years ago
Thank you for your bug report.
If I understand this issue correctly, there is a bug in get_global
that produces an error other than TRANSPLANT:novariable
. As far as I can tell this means that either which('projectname')
or exist('projectname')
produced an error in Matlab.
If true, that is a bug in Matlab, not Transplant. (Am I understanding this correctly?)
That said, I'd be grateful for a pull request that fixes this issue, if it can be done on the Matlab side, and without adding a large performance overhead.
Thanks for the pointers. From a quick look, it seems like in the failing cases, exist('projectname')
returns 7 ("name is a folder") instead of 0.
If I find the time for it, I will try to investigate further and create a pull request.
That would be greatly appreciated.
I did spend some time looking into it. The good news it that a simple
- existance = existance | any(which(msg('name')));
+ existance = ~any(existance == [0, 7]) | any(which(msg('name')));
fixes the bug for me.
The bad news is that I am quite irritated by the next few lines of code:
existance = evalin('base', ['exist(''' msg('name') ''')']);
returns an number between 0 and 8, then
existance = existance | any(which(msg('name')));
turns this into a logical value, i.e. it is either 0 or 1. A few lines later
elseif any(existance == [2, 3, 5, 6]) | any(which(msg('name')))
is checked, and the first part can never be true as existance
is always 0 or 1.
I am not sure if I am missing something or the code is indeed broken. I feel like applying my fix without fixing the rest of this is not the right approach but I don't understand the transplant internals enough for a proper fix.
I wish I could help you. But at the moment, I am stuck at home, without access to Matlab.
But if that fix works, and the rest of the test suite still runs, I would assume it is good, and I would gratefully accept a pull request.
any news on this?
I am terribly sorry for the late response. Your PR somehow fell off my radar. Again, my apologies.
Thank you very much for dealing with the issue quickly and efficiently, though!
Slightly off-topic here, but do you have plans to release a new version that includes the fix at some point? Being able to install a version that includes the fix from PyPI would make things easier for me.
Sorry about that. I'll try to do it tomorrow morning.
Thanks! :) Any update on this?
Sorry about that. I had an accident that all made desk work all but impossible.
But I just uploaded the release. Thank you for your patience.
Thank you!
After spending some time trying to call a Matlab function in a package and wondering why I always got an UndefinedFunction error, I finally realized that this was actually caused by the current working directory having the same name as the package.
The same thing seems to happen if the current working directory contains another directory with the same name as the package. I didn't check further to see if this also applies to any directory in Matlab's path.
In
Matlab.__getattr__
, there is a very specific check for detecting packages:if not (err.identifier == 'TRANSPLANT:novariable' and packagedict):
. When the error appears,err.identifier
wasMATLAB:UndefinedFunction
instead ofTRANSPLANT:novariable
.Here is a minimum example that should make it possible to reproduce the bug just by pasting the commands: