Re: [matplotlib-devel] [Anaconda Support] OSX: why not make "python" invoke the framework?
On 14 Aug 2014, at 11:40 pm, Chris Barker wrote: > On Thu, Aug 14, 2014 at 12:07 PM, Eric Firing 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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] ipython slowdown with qt
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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
On 15 Aug 2014, at 10:39 pm, Eric Firing 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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fwd: [IPython-dev] ipython slowdown with qt
-- Forwarded message -- From: Jens Nielsen Date: Fri, Aug 15, 2014 at 10:05 PM Subject: Re: [IPython-dev] ipython slowdown with qt To: IPython developers list 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 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 > ipython-...@scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
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 -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OSX framework detection
On 2014/08/15, 10:53 AM, Derek Homeier wrote: > On 15 Aug 2014, at 10:39 pm, Eric Firing > 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… Not exactly. Anaconda builds python without the --enable-framework option, and then somehow makes their own python.app directory and binary. Their bin/python has no connection to framework things; their bin/pythonw and bin/python.app point to an executable inside their framework directory, which is also named python.app, but is of course in a different location. No clue as to why they do it this way; they might have had a good reason. In any case, WITH_NEXT_FRAMEWORK is not defined in sysconfig. Nevertheless, when I was running their buggy ipython, which was being run with python rather than pythonw (or equivalent), matplotlib was *not* objecting to using the macosx backend--it was the default--and it was not segfaulting, but neither was it producing usable plot windows. They have fixed their ipython on python 3, so now the osx backend works. Eric > > Cheers, Derek > -- > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
