Why newline warning in Debian 8.5 WFDB?

[sami10007]

I get the warning many times per iterations now, began yesterday after apt-get update && apt-get upgrade

Warning: Function newline has the same name as a MATLAB builtin. We suggest you rename the function to avoid a potential name conflict. 
> In path (line 109)
  In addpath (line 88)
  In code (line 75) 

I initiate WFDB each time by doing

home=char(java.lang.System.getProperty('user.home')); % all systems
addpath(fullfile(home, 'Documents/bin/matlab/', 'wfdb-app-toolbox-0-9-9', 'mcode'));

OS: Debian 8.5 64 bit
Linux kernel: 4.6 of backports
Hardware: Asus Zenbook UX303UA

[sami10007]

I contacted MATLAB service portal and got the following answer

In order to know which built-in function is being used in each case, you can make use of the MATLAB command "which".

which function_name

Refer to the following documentation page for more information regarding the use of this functionality:

https://uk.mathworks.com/help/matlab/ref/which.html

On the other hand, a possible solution to prevent complications when it comes to shadowed functions is to wrap the entire toolbox in a package. Functions in a package are accessed in a scoped fashion, which means that you would need to write first the package name and then the function name, thus, avoiding name conflicts. For more information about the latter, refer to:

https://uk.mathworks.com/help/matlab/matlab_oop/scoping-classes-with-packages.html

I hope this information helps you. If you have any other questions please let me know.

Please, let me know what is the preferred solution, and what is the standard way to do it.

[ikarosilva]

Can you paste the entire stack trace from the MATLAB command window ? I am not sure how this would be related to any Linux updates, looks like it could be a bug somewhere else... The full MATLAB command history and warning log will help.

[sami10007]

This problem may be related to polaraxes and other things related to Matlab-figure. There are several limitations there, which the software team knows now, and they promised to work for the upgrades in the later releases. I think we cannot work out solution for this now because of MathWorks, only workarounds so I will focus on describing the case better in the following.

The workaround is - do not to use MATLAB polaraxes at all for sophisticated computing. I think it is not a memory problem. I have no problems with Cartesian plots. Basic pseudocode is

1. do polar data
2. do polaxes and plot there
3. mark specific points on polaraxes data (impossible at the moment, but next releases of MATLAB will target this one); take frame of polaraxes may also be enough for the condition

The problem may have temporal features connected to matlab-figure and polaraxes. This may cause the situation where the error message is hidden under other conditions. Weak evidence however.

The confounders are in Matlab figure, but they are not told to the public. Without them, I think this problem cannot be solved, only a workaround can be offered.

Other problem in MathWorks related the problem: they do much of their tests in Ubuntu Linux which is utterly too unstable as a system for my needs in scientific computing; I will not put high bets on MathWorks about the case because they do not have solid vertical line in software development. Their second line of Debian development is absolutely too little for the prompt resolution of the case. I think the best thing what we can do is to use Java for polaraxes and plots for the future development. Please, let me know the basic examples.