Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PyPlot works but calling matplotlib directly from PyCall aborts #665

Open
musm opened this issue Mar 13, 2019 · 13 comments

Comments

@musm
Copy link
Contributor

commented Mar 13, 2019

julia> using PyCall

julia> plt = pyimport("matplotlib.pyplot")
PyObject <module 'matplotlib.pyplot' from 'C:\\tools\\Miniconda3\\lib\\site-packages\\matplotlib\\pyplot.py'>

julia> x = range(0; stop=2*pi, length=1000); y = sin.(3 * x + 4 * cos.(2 * x));

julia> plt.plot(x, y)
This application failed to start because it could not find or load the Qt platform plugin "windows"
in "".

Reinstalling the application may fix this problem.

This causes Julia to terminate abruptly.

Yet using PyPlot works ?

@musm musm changed the title PyPlot works by calling matplotlib directly crashes julia silently PyPlot works but calling matplotlib directly from PyCall crashes julia silently Mar 14, 2019

@stevengj

This comment has been minimized.

Copy link
Collaborator

commented Mar 15, 2019

PyPlot works because it uses a different backend, presumably.

Some of the Matplotlib backends only seem to work with the python executable, though I'm not sure why in this particular case — PyPlot usually works with Qt.

@musm

This comment has been minimized.

Copy link
Contributor Author

commented Mar 20, 2019

@stevengj I did some investigating to see if loading the matplotlib package with PyCall vs loading it with PyPlot was somehow loading the wrong dll leading to the crash, via process explorer.

However that confirmed BOTH methods loaded the exact same dll's (backend for both is QT5)

@tkf

This comment has been minimized.

Copy link
Contributor

commented Mar 22, 2019

Maybe call pygui_start(:qt_pyqt5)? That's another difference to PyPlot. Although I guess it only matters if you have non-default Qt configuration.

@stevengj

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

By default, Matplotlib starts in non-interactive mode, so you shouldn't need a pygui event loop in Julia. The plot window doesn't appear until you run plt.show(), in which case Python implements the event loop.

@stevengj

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

There are multiple Python Qt libraries. Maybe PyPlot is importing a different one and Matplotlib is respecting that? See https://github.com/JuliaPy/PyPlot.jl/blob/master/src/init.jl

@musm

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2019

It's quite strange because calling matplotlib from python works, PyPlot works, just from PyCall it fails.

@tkf

This comment has been minimized.

Copy link
Contributor

commented Mar 23, 2019

pygui_start(:qt_pyqt5) calls fixqtpath before starting the event loop. I thought it could be doing something.

@stevengj

This comment has been minimized.

Copy link
Collaborator

commented Mar 25, 2019

Oh right, I forgot about fixqtpath(). You could definitely try calling PyCall.fixqtpath() manually.

(Retitling this issue because I wouldn't call this silent or a crash — matplotlib is aborting with an error message.)

@stevengj stevengj changed the title PyPlot works but calling matplotlib directly from PyCall crashes julia silently PyPlot works but calling matplotlib directly from PyCall aborts Mar 25, 2019

@musm

This comment has been minimized.

Copy link
Contributor Author

commented Mar 25, 2019

Yes calling PyCall.fixqtpath() manually after import matplotlib fixes the issue. @tkf it seems PyCall.fixqtpath() is good enough to avoid the crash.

We'll the error ends up killing julia, which is pretty annoying. Is that avoidable?

@tkf

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2019

Yeah, it'd be nice if we can avoid it. Though I don't know what's the best way to do it. Is it too crazy to always call fixqtpath in PyCall.__init__?

@musm

This comment has been minimized.

Copy link
Contributor Author

commented Mar 26, 2019

Doesn't seem too crazy, until a proper fix is implemented. Are there any other instances that can crash julia like this or is it only the QT path loading issue.

@stevengj

This comment has been minimized.

Copy link
Collaborator

commented Mar 26, 2019

I guess since fixqtpath just sets an environment variable, it is not so bad to run unconditionally on startup for Windows. (Only mildly insane, but we are used to that. 🙄 )

Any library that calls os.abort() or similar will terminate Julia (or any other program). This is not a "crash" in the usual sense, and it is impossible to prevent in general.

A "proper" fix here would be to fix Qt (or its Python wrapper) to either be more robust about finding library paths and/or to throw an exception rather than aborting when it fails to load. (The Qt folks seem to think that the location of qt.conf is not their problem. https://bugreports.qt.io/browse/QTBUG-58637) Not much we can do on our end short of hacks like fixqtpath.

@tkf

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Only mildly insane, but we are used to that.

🤣

The Qt folks seem to think that the location of qt.conf is not their problem. https://bugreports.qt.io/browse/QTBUG-58637

Reporting it to all four Python Qt bindings sounds like a nightmare... Especially if just a subset of them support it.

I guess the upside is that Qt team seems at least positive for solving the "root cause" https://bugreports.qt.io/browse/QTBUG-14150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.