I recently decided to try Julia 0.6. I installed a Generic Linux binary (nightly build) on my machine. For plotting, I installed PyPlot, using my system’s installation of matplotlib (i.e., not Conda). Plotting works fine in IJulia, but I’m not able to plot from the REPL. Issuing a plot() command doesn’t create a window; it just prints a message like below in the REPL:
PyPlot.Figure(PyObject <matplotlib.figure.Figure object at 0x7fa8653aa210>)
I tried a ion() command before plotting, and also a show() command after plotting, but neither helped. I suspect this can have something to do with Matplotlib 2.0 (I use Debian testing and matplotlib was recently upgraded from version 1.5 to 2.0). Does anybody have any pointers as to how I should go about debugging this?
Did you try using the version via Conda?
I had this issue and it went away either by re-installing anaconda distro (so maybe try just reinstalling matplotlib?)
Or by reinstalling PyCall and PyPlot
So probably this is not very helpful as it does not point to the root .
Maybe even just a restart would do it , cause it seems to me that the problem is that it gets plotted but nowhere where it is visible … maybe in another process?
I found I need to invoke pygui(true) to get a plot window from the REPL, with latest tagged PyPlot and a recent build of Julia v0.6.beta. (Also using Matplotlib 2.0 and the Qt5 backend, as installed by Conda.jl, on Linux.)
Further, if one uses PyPlot as a backend for Plots.jl in the above environment, this seems to work:
using Plots
import PyPlot: pygui
PyPlot.pygui(true)
# now ready to call Plots methods
otherwise Plots thinks PyPlot is not properly installed.
1 Like
I can’t reproduce; it works fine for me without pygui. Do you have something in your .juliarc that would affect it?
I don’t have a .juliarc or anything I can find in the environment or dot-files that should affect PyPlot/matplotlib. I’ll try stepping through the __init__ calls to see if I can find the problem.
After some investigation… for me (i.e. using Conda.jl) it seems to be a case of
https://github.com/JuliaPy/PyPlot.jl/issues/281
which is fixed in PyPlot master. In short, under Julia v0.6 version 2.3.1 of PyPlot acts as if the REPL is a graphical display and switches Matplotlib’s own backend to “Agg”.
I still need the above hack for Plots (with PyPlot master), but I’m waiting for Plots to be happier with v0.6 before investigating.
@dpsanders Yes, I did try with Conda but that didn’t help.
@stevengj PyPlot.backend is “qt5agg”. However, I tried different backends with the sequence below (as explained in the PyPlot documentation), but that didn’t help either:
using PyCall
pygui(gui)
using PyPlot
The values I tried for gui were (:tk, :gtk3, :gtk, :qt5, :qt4, :qt, :wx). None of them worked (some of them actually threw an error as I don’t have the required libraries for all of them installed on my system).
Doing pygui(true) before plotting as suggested by Ralph_Smith does solve the problem, but only when using Conda. If I uninstall PyPlot and PyCall and reinstall them using my system’s Python and matplotlib installations, Julia simply quits with the following error message when I try to plot something:
: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
In summary, if I use Conda, I have to use pygui(true) in order to be able to plot. If I use my system’s Python and matplotlib, I can’t plot because of the error above.
After some more investigation, I found out that I didn’t have the tk backend installed on my system. I installed it and now I can open a plot window after I issue the following commands:
using PyCall
pygui(:tk)
using PyPlot
pygui(true)
However, if I try any other backends, Julia quits with the error message below when I try to plot something:
: CommandLine Error: Option 'help-list' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
I switched to PyPlot master and things changed. Before switching to master, issuing a figure() command in the terminal didn’t open a window plot; it just printed a message like below in the terminal:
PyPlot.Figure(PyObject )
Only after doing pygui(true) and then trying to plot again I would get the LLVM error above. After switching to PyPlot master, any attempt to create a window plot (e.g., figure()) results in the LLVM error; now I don’t need to do pygui(true) in order to cause that. However, using the tk backend still works.
Apparently that is a problem due to conflicting versions of LLVM. Julia is linked against the LLVM shared library, but one of the Matplotlib backends is linking a different version: Add a build option to rename all LLVM symbols · Issue #12644 · JuliaLang/julia · GitHub
@stevengj Thanks. There are two weird things about this though. First, the version of my system’s LLVM is 3.9.1, exactly the same reported by Julia 0.6. Second, if I try to uninstall my system’s LLVM package (using Debian apt-get tools), no matplotlib related package (not even any of its backend packages) gets uninstalled, which, as far as I understand, means that no matplotlib or matplotlib backend package depends on LLVM.
I noticed there’s a more up-to-date version of libllvm in Debian’s experimental repository which fixes a couple of bugs. I installed it but the problem persists.
I then decided to compile Julia from source against my system’s LLVM installation. That solves the problem. However, I still have to do pygui(true) before I’m able to get a window plot.
Are you on PyPlot master? That should obviate the need for pygui(true) (see edited post upthread).
LLVM is linked by some low level Debian packages such as OpenGL-related libraries, which may be called by the matplotlib backends as needed (i.e. without explicit APT dependencies). Others have reported LLVM consistency problems in the context of OpenGL/CL Julia packages.
You’re right. Switching to PyPlot master does obviate the need for pygui(true). Thanks.
In summary, PyPlot master with the tk backend allows me to have a plotting system working again without having to rely on Conda (this saves me 1.3 GB of files pulled in by the Conda installation; I already have all the necessary libraries installed on my system for Python development).
Regarding the LLVM issue, is this something I should report to the Debian bug tracking system or is it just a matter of waiting for issue #12644 to be fixed?
I don’t think its a bug in Debian - the dependency seems indirect and probably depends on one’s hardware/drivers. Let’s hope #12644 is addressed before too many more of us stumble into it.
In the short term, on Linux it may be helpful to try dlopen with Libdl.RTLD_DEEPBIND as an argument. Make sure this is done for the first dlopen of a given shared object, because subsequent calls will return the existing handle without re-evaluating any load options.
It worked for me as well than you very much!!