I’m having a problem with printing figures in octave when the figure’s visibility is set to false. For example, the following code produces a “panic: segmentation fault” in Octave version 4.2.2:
t = 1:10;
fh = figure(“visible”, false);
plot(t,sin(t))
print(“fig.png”)
If I run the above code in Octave version 5.2.0, there is no problem. Is this a bug that was fixed in the Octave 5 update? If so, is there a workaround that I can use for Octave 4? I would prefer to use Octave 4 if possible.
Other notes:
I am running this in Ubuntu 16.04.6 LTS and I installed octave 4 using apt.
The answer to your question is, yes. Here is the relevant line from the v5.1.0 NEWS:
Dependencies:
The GUI requires Qt libraries. The minimum Qt4 version supported is Qt4.8. Qt5 of any version is preferred.
The OSMesa library is no longer used. To print invisible figures when using OpenGL graphics, the Qt QOFFSCREENSURFACE feature must be available and you must use the qt graphics toolkit.
Apparently the now deprecated OSMESA dependency and the printing of invisible figures was a long-standing pain-in-the-butt. Maybe you'll have some luck going through bug comments (e.g. someone says that if you make it visible at least once, it may be possible to print).
But as people have said in the comments, the best thing to do would be to upgrade your octave version, and recompile your mexfiles for the new version.
Related
Although Intel MKL speeds up calculations in GNU Octave, the results are sometimes (tested with Octave 5.2.0 in Xubuntu 20.04) totally wrong when the size of the Matrices are big. This has been mentioned here and here.
For example, this gist shows an example that Octave and Scilab produce different results, and the Octave's result is wrong (it changes every time the script is run. Octave gives correct result with OpenBLAS).
This is the code in the gist.
for a = 1:500
for b = 1:500
c(a,b) = sin(a + b^2);
endfor
endfor
g = eig(c);
m = max(real(g))
%Correct result is ans = 16.915
%With MKL in Ubuntu 20.04, I get random numbers of order 10^5 - 10^6, which changes on every run
How to fix this issue?
This issue has been mentioned in some Debian bug reports (see this and this), and a bug report in Octave.
According to the Debian maintainers, this is neither a bug of Octave, nor of MKL. It arises due to a racing condition between libgomp and libiomp.
Here's how to fix it.
Enter the command
export MKL_THREADING_LAYER=gnu
in a terminal, and call octave from the same terminal. Now the issue should not arise.
To make this fix permanent, add the line export MKL_THREADING_LAYER=gnu to your .bashrc file.
Note: After installing MKL, I plotted a certain graph, and found something was seriously wrong (although the calculations were faster).
I posted it in the MKL community, and they said it's not their bug. Finally I opened a bug report with Octave and someone mentioned this workaround.
Warning: As mentioned in the bug report, the test suite of Octave (__run_test_suite__) fails with segmentation fault even when this workaround is applied. Therefore, it is advised that Octave with MKL is used with caution.
I've a compiled tcl version 8.4 and want to check if --enable-threads was set when it was compiled or not ?
or if there is any another way to get the list of all passed flags.
Thanks
IMPORTANT NOTE!
Tcl 8.4 is out of long-term support. Absolutely no further changes will be forthcoming to it, not even if a catastrophic security error is discovered; if your issue isn't fixed by 8.4.20, you'll need to go to 8.5 or later. We don't know of any such security issues, but we aren't looking and won't fix them if they're found.
Support here is only on a “because we feel nice” basis. You should not create new work based on 8.4.
The global array element tcl_platform(threaded) is defined and set to 1 when the currently-used Tcl library is built with thread support. This is true from at least Tcl 8.4 onwards. Here's how to reliably get a nice boolean value you can check:
set isThreaded [expr {
[info exist tcl_platform(threaded)] && $tcl_platform(threaded)
}]
NB: Some platforms are virtually always threaded anyway (because of how they work internally; this is the case with Windows and OSX if I remember right). Future versions of Tcl (8.7 onwards) will default to threaded everywhere; this will be the only supported build mode from 9.0 on. You'll still need the Thread package to work with threads in your script, but that's a standard extension these days.
Starting with 8.5 (TIP 59), one can retrieve details about the build configuration using tcl::pkgconfig:
% tcl::pkgconfig get threaded
1
Note that this is not available in Tcl 8.4; if available, one does not have to protect against requesting an inexistent array entry tcl_platform(threaded).
I have a Cython extension which I've compiled on Ubuntu 14 and uploaded as an Anaconda package. I'm trying to install the package on another machine which is running Scientific Linux (6?) which ships with an older version of glibc. When I try to import the module I get an error that looks (something like) this:
./myprogram: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./myprogram)
When I say "something like" - the "myprogram" is actually the .so name of the extension.
From what I understand this error is because I have a newer version of glibc on the build system which has an updated version of the memcpy function.
This page has a good description of the problem, and some rather impractical solutions: http://www.lightofdawn.org/wiki/wiki.cgi/NewAppsOnOldGlibc
There is also a much simpler answer proposed here: How can I link to a specific glibc version?
My question is: how to I apply this solution to my Cython extension? Assuming the __asm__ solution works (as given in the second link) what's the best way to get it into the C generated by Cython?
Also, more generally, how to other modules avoid this issue in the first place? For example, I installed and ran a pre-built copy of numpy without any issues.
This turned out to be quite simple.
Create the following header, glibc_fix.h:
__asm__(".symver memcpy,memcpy#GLIBC_2.2.5")
Then include it by using CFLAGS="-include glibc_fix.h". This can be set as an environment variable, or defined in setup.py.
Additionally, it turns out numpy doesn't do anything special in this regard. if I compile it myself it links with the newer version on my system.
I'm using Octave right now, but earlier I had used MatLab. In MatLab there is a function ord2 and according to this document (http://www.obihiro.ac.jp/~suzukim/masuda/octave/html3/octave_159.html/) it should also exist in Octave. Could anyone help me with this issue, since I'm new in Octave. How can I import or in other way use 'ord2' function (second-ordered system).
The documentation you mention is for Octave 3.0 which is a very very old version. All of Control functions, together with Finance and Quaternion, were removed from core Octave with release 3.2. If you see the news for Octave 3.2 (if you have a very recent version, this may be in one of the old news file:
** The Control, Finance and Quaternion functions have been removed.
These functions are now available as separate packages from
http://octave.sourceforge.net/packages.html
and can be reinstalled using the Octave package manager (see
the pkg function).
As it is mentioned, you can download the packages from Octave Forge website but depending on your operating system, you may be better off use your package manager.
Finally, the ord2 function does not actually exist in the control package and I'm even unsure that the version you are referring to in Octave 3.0 was even Matlab compatible. However, you can still see its source online right before it was removed.
After quite a bit of searching and trying different things, I am stumped on how to get mym to work (as found here: http://sourceforge.net/projects/mym/). I was wondering if anyone has a very simple list of actions needed to get this to work. I think my main trouble is installing zlib. I don't understand how to actually install it or work with it. I have tried to use Microsoft Visual C++ Express 2010 but then only the debug versions are compiled. That means when I try to use the mex function in matlab it gives me the error:
Error: Could not detect a compiler on local system
which can compile the specified input file(s)
I just don't understand the process and everywhere I look it says something different. I have tried multiple versions of each all of the programs involved and nothing seems to work. Any help would be greatly appreciated.
Do:
mex -setup
from the command line to define your compiler on your system. Once you do that then Matlab will correctly locate the compiler and build the mex libraries it needs.
See:
http://www.mathworks.com/help/matlab/matlab_external/building-mex-files.html