matplotlib-devel Mailing List for matplotlib

Hi Chris,
> the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
> pythonw and a non-frameworked python?
> 
> This is right -- the GUI backends to matplotlib cause python to crash, but not pythonw. This is annoying, since the two binaries
> are equivalent under most other python installs. E.g. the mac system python manpage reads:
> 
> To support multiple versions, the programs named python and pythonw now
> just select the real version of Python to run, depending on various set-
> tings. (As of Python 2.5, python and pythonw are interchangeable; both
> execute Python in the context of an application bundle, which means they
> have access to the Graphical User Interface; thus both can, when properly
> programmed, display windows, dialogs, etc.) 
> 
> So people don't usually think to invoke different anaconda python commands, leading to unexpected crashes (especially when using tools like pytest, which invoke python, run a test that needs MPL, and crash).
> 
well, the way it is currently designed to would be to ‘crash’ resp. exit with an error right on starting up the
non-framework interpreter. But besides that it’s curious that its python actually crashes with the macosx
backend, which I have never seen with Fink’s non-framework Python. Just tested this with 1.4.0rc3 and
Python2.7 (previously with 1.5.x HEAD in Python3.4), and it works the same - the same little quirks,
but no signs of performance or stability problems.
> This definitely seems like Anaconda's problem rather than matplotlib's (it affects any program that tries to import Qt, e.g.)
> 
So it affects other backends besides macosx or even all? Yes, this seems to be rather Anaconda-specific.
I’ve looked for anything special in the build options, but besides adding the right include and linker paths
there isn’t really anything.
Cheers,
					Derek

Hi Derek,
> the framework. Though, if I understand correctly, Anaconda provides a
> framework version of the interpreter
> pythonw and a non-frameworked python?
This is right -- the GUI backends to matplotlib cause python to crash, but
not pythonw. This is annoying, since the two binaries
are equivalent under most other python installs. E.g. the mac system python
manpage reads:
 To support multiple versions, the programs named python and pythonw now
 just select the real version of Python to run, depending on various
set-
 tings. (As of Python 2.5, python and pythonw are interchangeable; both
 execute Python in the context of an application bundle, which means
they
 have access to the Graphical User Interface; thus both can, when
properly
 programmed, display windows, dialogs, etc.)
So people don't usually think to invoke different anaconda python commands,
leading to unexpected crashes (especially when using tools like pytest,
which invoke python, run a test that needs MPL, and crash).
This definitely seems like Anaconda's problem rather than matplotlib's (it
affects any program that tries to import Qt, e.g.)
chris

---------- Forwarded message ----------
From: Jens Nielsen <jen...@gm...>
Date: Fri, Aug 15, 2014 at 10:05 PM
Subject: Re: [IPython-dev] ipython slowdown with qt
To: IPython developers list <ipy...@sc...>
While I can reproduce the issue using %gui qt I can also reproduce it with
the WX backend (%qui wx) with more or less the same symptoms. However, I
don't see the issue with either of the 'tk' or the 'osx' backends. And yes
the issue is reproducible in a python installation without any mpl
installed.
/Jens
On Fri, Aug 15, 2014 at 9:22 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
> > When using MPL with ipython —pylab and the Quartz version of PyQT4,
> > the interpreter seems to be slow down extremely after running for a
> > little while. Weirdly this is not connected to any graphics display
> > and in fact happens even without any plotting window opened, i.e. the
> > ipython shell just randomly becomes completely unresponsive and hangs
> > for several seconds on simple tasks like typing or navigating through
> > history. The plotting itself actually does not appear to perform any
> > worse than it used to under Mountain Lion.
>
> [I'm switching the subject because my comments below relate to ipython
> and matplotlib, and are no longer Anaconda-specific.]
>
> Derek,
>
> Thanks. A few days ago, when I switched from testing on linux to
> testing on osx, exactly this ipython slowdown was happening to me--but I
> lost track of what combination of versions and invocations was causing
> it. Therefore I have been concentrating on the severe problem which
> was, for me, 100% repeatable, and involved macosx backend, not Qt. I
> expect the macosx-relatec problem will go away after Ilan uploads the
> revised Anaconda ipython for python 3.
>
> Now I find I can repeat the ipython problem on Homebrew python 3
> (framework--with Quartz app) and Anaconda with the un-fixed ipython
> (which is running without starting a Quartz app):
>
> ipython --pylab=qt
>
> Leave it alone for a bit. Try scrolling through history. Long delay,
> even in responding to Ctrl-C. Evidently key events are stacking up and
> not being processed. Now try:
>
> ipython
> %pylab qt
>
> I see the slowdown with this, also. The response delay seems to get
> worse with time. It renders the session unusable after only a few minutes.
>
> ipython
> %gui qt
>
> And I still see it, so this appears to be a problem in ipython's PyQt4
> gui handling, not directly related to matplotlib. All on Mavericks,
> running ipython from Apple's terminal.
>
> Eric
>
>
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>

On 15 Aug 2014, at 10:39 pm, Eric Firing <efi...@gm...> wrote:
> On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
> 
>> Just to make sure I understand - this is about whether the MPL macosx
>> backend would run with non-framework Python at all? It certainly
>> should not, as _macosx.m has been enforcing an error in this case for
>> some versions. That put aside, when I disable the error at the end of
>> _macosx.m I found the OSX backend to still work as it used to under
>> OS X 10.9 with the Fink Python installation (which is not built as a
>> framework, and unfortunately unlikely to change in foreseeable time).
> 
> It sounds like whatever mechanism _macosx.m has been using to determine whether it is running inside a Python Quartz app, does not work in all cases--I gather it works with Fink, but it certainly does not with Anaconda. Any idea why, and how this might be fixed? Wx does detect this correctly, and refuses to run if in a script invoked with Anaconda's python rather than pythonw, for example. (As an aside, wx is not available yet for python 3 except in phoenix development daily builds, so my comment above is based on a test some time ago with python 2.7)
I don’t know much about Anaconda, but since this is hardcoded in macros, the only way I see this failing
is if they somehow incorrectly define WITH_NEXT_FRAMEWORK in pyconfig.h without actually building
the framework. Though, if I understand correctly, Anaconda provides a framework version of the interpreter
pythonw and a non-frameworked python? But matplotlib is probably only built against one of them, thus
not getting the correct header version...
Cheers,
					Derek

On 2014年08月15日, 9:37 AM, Derek Homeier wrote:
> When using MPL with ipython —pylab and the Quartz version of PyQT4,
> the interpreter seems to be slow down extremely after running for a
> little while. Weirdly this is not connected to any graphics display
> and in fact happens even without any plotting window opened, i.e. the
> ipython shell just randomly becomes completely unresponsive and hangs
> for several seconds on simple tasks like typing or navigating through
> history. The plotting itself actually does not appear to perform any
> worse than it used to under Mountain Lion.
[I'm switching the subject because my comments below relate to ipython 
and matplotlib, and are no longer Anaconda-specific.]
Derek,
Thanks. A few days ago, when I switched from testing on linux to 
testing on osx, exactly this ipython slowdown was happening to me--but I 
lost track of what combination of versions and invocations was causing 
it. Therefore I have been concentrating on the severe problem which 
was, for me, 100% repeatable, and involved macosx backend, not Qt. I 
expect the macosx-relatec problem will go away after Ilan uploads the 
revised Anaconda ipython for python 3.
Now I find I can repeat the ipython problem on Homebrew python 3 
(framework--with Quartz app) and Anaconda with the un-fixed ipython 
(which is running without starting a Quartz app):
ipython --pylab=qt
Leave it alone for a bit. Try scrolling through history. Long delay, 
even in responding to Ctrl-C. Evidently key events are stacking up and 
not being processed. Now try:
ipython
%pylab qt
I see the slowdown with this, also. The response delay seems to get 
worse with time. It renders the session unusable after only a few minutes.
ipython
%gui qt
And I still see it, so this appears to be a problem in ipython's PyQt4 
gui handling, not directly related to matplotlib. All on Mavericks, 
running ipython from Apple's terminal.
Eric

On 14 Aug 2014, at 11:40 pm, Chris Barker <chr...@no...> wrote:
> On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing <efi...@gm...> wrote:
> but as far as I can see, on OSX, there is no *advantage* to non-framework python. Is this correct?
> 
> Suggestion for anaconda:
> make bin/python a link to ../python.app/Contents/MacOS/python
> 
> NOTE: the python.org python build has been doing this (or something like it) for years and many versions -- I had gotten pretty used to it and was pretty annoyed when I discovered Anaconda keeps anon-framework binary as the default.
> 
> It was annoying enough that I had to explicitly call pythonw (or alter the #! line) for my wxPython scripts, but with ipython it's even worse -- how would I start up ipython with a framework build?
> 
> NOTE: if the Anaconda folks really think there is a real downside to using the framework executable for the default python, maybe the ipython start up script could use pythonw ?
> 
> Eric - have you tried recent MPL with the python.org builds to confirm the issue? I'm a bit surprised that it would even semi-work -- when I try wxPython with the regular executable, I get an error message and it wont run at all.
> 
Just to make sure I understand - this is about whether the MPL macosx backend would run with non-framework
Python at all? It certainly should not, as _macosx.m has been enforcing an error in this case for some versions.
That put aside, when I disable the error at the end of _macosx.m I found the OSX backend to still work as it used
to under OS X 10.9 with the Fink Python installation (which is not built as a framework, and unfortunately unlikely
to change in foreseeable time). I.e. the only obvious problem is the lack of control by the window manager.
Overall I still find it to perform better than any of the alternative backends. But having switched to PyQT4 as the
default backend due to the above Fink troubles, I did notice some oddities under Mavericks. I have no idea if they
are related to the problems Eric had originally reported, but they are clearly Mavericks-specific:
When using MPL with ipython —pylab and the Quartz version of PyQT4, the interpreter seems to be slow down
extremely after running for a little while. Weirdly this is not connected to any graphics display and in fact happens
even without any plotting window opened, i.e. the ipython shell just randomly becomes completely unresponsive
and hangs for several seconds on simple tasks like typing or navigating through history. The plotting itself actually
does not appear to perform any worse than it used to under Mountain Lion.
None of this seems to occur with the X11 variant of PyQT4.
When launching ipython without the —pylab flag and loading MPL later (e.g. with ‘import matplotlib’ in the ipython
profile), none of these stalls or hangups occur, but plots sometimes seem not to refresh properly even with a
plt.draw() and one has to manually resize the plot window to force redrawing of the figure.
This might be primarily a PyQT4 or Ipython issue, but obviously it is somehow connected to the pylab mode of Ipython.
Cheers,
					Derek