The following stem plot takes around half a minute to execute, all the while the REPL is blocked. I thought either PyPlot was supposed to automatically run plotting asynchronously in the background or at least there is supposed to be a way to do it; however, I could not figure out how to get it to work. The more relevant issue is that if I try to close the plot while it’s processing, it crashes Julia. At least once it gave me a strange error due to only clicking on the window, but usually it recovers from this.
Since I assume somewhere underneath there is a broken C call, I haven’t posted this as a bug. But I thought maybe there is a more graceful way to fail. Or it would be even better if it would run asynchronously and I would have less reason to attempt to stop it when it’s taking too long.
using PyPlot
stem(randn(32768))
versioninfo()
Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
System: NT (x86_64-w64-mingw32)
CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
WORD_SIZE: 64
BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
LAPACK: libopenblas64_
LIBM: libopenlibm
LLVM: libLLVM-3.7.1 (ORCJIT, broadwell)
I don’t know if it’s related, but before the ColorTypes.jl got broken on master (and hence breaking everything based on it; I’m enjoying UnicodePlots.jl these days), I ran into this problem with PyPlot: https://github.com/JuliaPy/PyPlot.jl/issues/269 I’m not really sure it’s related to matplotlib 2.0, but that’s the only that changed on my system, that I’m aware of. I asked to other people that reported the same problem on the bug tracker what version they were running, but no one answered.
To make it clear: matplotlib works in Python and via PyPlot in Julia 0.5, it was only in Julia master that crashed.
I’ve never used matplotlib in native Python. I’ve always used Matlab to do numerical computing. I started with PyPlot because that was the easiest starting point. Further, I don’t even know what version of matplotlib or python is being used.
Same behaviour in pure Python 2.7 + matplotlib 2.0 (on macOS X 10.12). Ran for minutes and ate >1GB of memory - no plot - I had to stop the process and force quit the MPL window.
Works fine (<< 1s) with GR (both in Python and Julia):
Can I use it as the backend for MPL in Julia? I set MPLBACKEND=gr, but it doesn’t appear to do anything. I can use it directly. Although it’s faster, I was having a problem with the plot not showing up the second time. I’m not familiar with how to use it however…
julia> using PyPlot
ERROR: InitError: PyError (:PyImport_ImportModule) <type ‘exceptions.ImportError’>
ImportError(‘No module named gr.matplotlib.backend_gr’,)
File “C:\Users\goldfing\.julia\v0.5\Conda\deps\usr\lib\site-packages\matplotlib\pyplot.py”, line 114, in
_backend_mod, new_figure_manager, draw_if_interactive, show = pylab_setup()
File "C:\Users\goldfing\.julia\v0.5\Conda\deps\usr\lib\site-packages\matplotlib\backends_init.py", line 32, in pylab_setup
globals(),locals(),[backend_name],0)
in pyerr_check at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:56 [inlined]
in pyerr_check at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:61 [inlined]
in macro expansion at C:\Users\goldfing\.julia\v0.5\PyCall\src\exception.jl:81 [inlined]
in pyimport(::String) at C:\Users\goldfing\.julia\v0.5\PyCall\src\PyCall.jl:387
in init() at C:\Users\goldfing\.julia\v0.5\PyPlot\src\PyPlot.jl:235
in _include_from_serialized(::String) at .\loading.jl:150
in _require_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at .\loading.jl:187
in _require_search_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at .\loading.jl:217
in require(::Symbol) at .\loading.jl:371
during initialization of module PyPlot
The GR framework must be installed within your Python environment or in a separate directory, as in our case (S:/gr):
ENV["MPLBACKEND"]="module://gr.matplotlib.backend_gr"
ENV["PYTHONPATH"]="S:/gr/python"
using PyPlot
x = linspace(0, 10, 200)
y = sin(x)
plot(x,y)
show()
I’m just thinking about adding the Python stuff to the Julia GR.jl installation. It’s just about copying some simple wrapper scripts …
OK. I don’t have time to figure this out right now. Keep in mind, not everyone has the official Python installed. My Julia is using Conda for Python as you can see from the error message. I’m not sure what that actually means. I found the Python binary in C:\Users\goldfing\.julia\v0.5\Conda\deps\usr.
I wanted to revisit the issue of Julia crashing. In my very limited experience, Julia seems to reliably go down when the shared library it calls into has a problem. I don’t know enough about how shared libraries work to know if this is in any way avoidable, BUT Matlab seems to reliably recover from calling into a bad mex file (just a dll) these days, although it may just be luck on my part…
The reason it matters is because sometimes you’re experimenting in the REPL, and suppose you happen to have generated a random data set that breaks your algorithm, and then you unexpectedly crash. You can’t get your data set back at that point.
In this case, not Julia is crashing, but Python. Python could not import the GR matplotlib backend, because it simply wasn’t installed.
As mentioned before, I can easily fix this problem in Julia(!) by adding the GR Python stuff to the Julia GR run-time package, thus allowing PyPlot to be used with any Python interpreter (2.x, 3.x) installed within Julia. I’ll change this in the next release …
A subroutine call into a shared library is running in the same process and memory space as the caller, and if it crashes then the caller crashes. I don’t think there is any way around this. In this case, Python is crashing because of a Matplotlib bug (I encourage you to file a Matplotlib issue).
Matlab’s computational process crashes if a mex file crashes, too (google “mex crash matlab” and you will see lots of examples). However, IIRC its user interface runs in a separate process these days, so the user interface stays running and launches a new kernel, but of course you lose all of the variables in your workspace. The analogous thing in Julia is to run your user interface in a separate process via e.g. IJulia or Juno. In IJulia, for example, if the julia process crashes, then it will give you a “kernel crashed, restarting” message, but the user interface will keep running, similar to Matlab.
Yes I understand this. Steven’s answer addressed my question. I had been hoping there was a way to fail gracefully without losing what I’m working on, but apparently that’s not the case.
Following instructions here, I attempted to install GR with anaconda, but it complained about an incompatibility with Python 3.5. I tried to build GR from scratch. I first had to install the MSVC 14 c++ compiler. Then I reran setup.py and failed with this message.