Menu
▾
▴
matplotlib-devel
|
From: Chris B. <chr...@no...> - 2014-08-14 21:41:11
|
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. > (On 2.7, I think this would also make wxpython applications work, but I > haven't checked recently.) > yup -- it should -- does for me anyway. If there is some reason why this default to a framework is not a good idea, > and/or cannot be implemented very soon in Anaconda, then I think we need to > immediately remove macosx as a default in matplotlib. A situation where a > new Anaconda user fires up ipython and tries to plot, and it fails, is > intolerable. for what it's worth, I get odd os-x errors trying to se default MPL with Anaconda as well -- haven't tried pythonw for that yet. (kludged it by using the Agg back end only) -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Jens N. <jen...@gm...> - 2014-08-15 21:06:06
|
---------- 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 > |
|
From: Chris B. <bea...@ha...> - 2014-08-15 21:24:12
|
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
|
|
From: Derek H. <de...@as...> - 2014-08-15 22:42:38
|
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 |
|
From: Chris B. <chr...@no...> - 2014-08-21 23:00:18
|
On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aar...@co...> wrote: > The only potential issue I can think of for making python=pythonw is > that pythonw is a shell script: > I agree -- that could create issues (though will mostly work, I suppose) But somehow the python.org build has managed to make a pythonw that IS a proper executable: ORRW-M-1275474:bin chris.barker$ pwd /Library/Frameworks/Python.framework/Versions/2.7/bin ORRW-M-1275474:bin chris.barker$ ls -l pythonw lrwxr-xr-x 1 root wheel 8 Jul 16 2013 pythonw -> pythonw2 ORRW-M-1275474:bin chris.barker$ ls -l pythonw2 lrwxr-xr-x 1 root wheel 10 Jul 16 2013 pythonw2 -> pythonw2.7 ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7 -rwxr-xr-x 1 chris.barker admin 9180 May 13 2013 pythonw2.7 ORRW-M-1275474:bin chris.barker$ file pythonw2.7 pythonw2.7: Mach-O executable i386 (yes, ti works for 64 bit too -- this just happens to be what I have) It would be nice if Anaconda would do it the same way. -Chris > #!/bin/bash > export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python > /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@ > > This is needed because otherwise Python thinks its sys.prefix is > ../../ from the executable, i.e., > /Users/aaronmeurer/anaconda/python.app/Contents/MacOS > > $~/anaconda/python.app/Contents/MacOS/python > Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03) > [GCC 4.2.1 (Apple Inc. build 5577)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> sys.prefix > '/Users/aaronmeurer/anaconda/python.app/Contents' > > I'm not sure what kinds of issues this would cause having python be a > shell script rather than a Mach-O 64-bit x86_64 executable (or a > symlink to a Mach-O 64-bit x86_64 executable). > > I suppose you could do this (replace 3.4 with 2.7 if you use Python 2): > > $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig > $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4 > > and see if anything breaks (or if you don't want to risk breaking your > main Python install, do it in a separate conda environment). > > Aaron Meurer > > On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier > <de...@as...> wrote: > > 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 > > > > -- > > Anaconda Community Support Group Brought to you by Continuum Analytics > > --- > > You received this message because you are subscribed to the Google > Groups "Anaconda - Public" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to ana...@co.... > > To post to this group, send email to ana...@co.... > > Visit this group at > http://groups.google.com/a/continuum.io/group/anaconda/. > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Chris B. <bea...@ha...> - 2014-08-21 23:40:12
|
There are some idiosyncrasies to Anaconda's pythonw -- for example, the behavior of "-c": python -c "print 1+2" -> 3 pythonw -c "print 1+2" -> Nothing /usr/bin/pythonw -c "print 1+2" -> 3 chris On Thu, Aug 21, 2014 at 6:59 PM, Chris Barker <chr...@no...> wrote: > On Thu, Aug 21, 2014 at 3:53 PM, Aaron Meurer <aar...@co...> > wrote: > >> The only potential issue I can think of for making python=pythonw is >> that pythonw is a shell script: >> > > I agree -- that could create issues (though will mostly work, I suppose) > > But somehow the python.org build has managed to make a pythonw that IS a > proper executable: > > ORRW-M-1275474:bin chris.barker$ pwd > /Library/Frameworks/Python.framework/Versions/2.7/bin > > ORRW-M-1275474:bin chris.barker$ ls -l pythonw > lrwxr-xr-x 1 root wheel 8 Jul 16 2013 pythonw -> pythonw2 > > ORRW-M-1275474:bin chris.barker$ ls -l pythonw2 > lrwxr-xr-x 1 root wheel 10 Jul 16 2013 pythonw2 -> pythonw2.7 > > ORRW-M-1275474:bin chris.barker$ ls -l pythonw2.7 > -rwxr-xr-x 1 chris.barker admin 9180 May 13 2013 pythonw2.7 > > ORRW-M-1275474:bin chris.barker$ file pythonw2.7 > pythonw2.7: Mach-O executable i386 > > (yes, ti works for 64 bit too -- this just happens to be what I have) > > It would be nice if Anaconda would do it the same way. > > -Chris > > > > > > > >> #!/bin/bash >> export PYTHONEXECUTABLE=/Users/aaronmeurer/anaconda/bin/python >> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS/python $@ >> >> This is needed because otherwise Python thinks its sys.prefix is >> ../../ from the executable, i.e., >> /Users/aaronmeurer/anaconda/python.app/Contents/MacOS >> >> $~/anaconda/python.app/Contents/MacOS/python >> Python 3.4.1 |Continuum Analytics, Inc.| (default, Aug 11 2014, 14:17:03) >> [GCC 4.2.1 (Apple Inc. build 5577)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import sys >> >>> sys.prefix >> '/Users/aaronmeurer/anaconda/python.app/Contents' >> >> I'm not sure what kinds of issues this would cause having python be a >> shell script rather than a Mach-O 64-bit x86_64 executable (or a >> symlink to a Mach-O 64-bit x86_64 executable). >> >> I suppose you could do this (replace 3.4 with 2.7 if you use Python 2): >> >> $mv ~/anaconda/bin/python3.4 ~/anaconda/bin/python3.4-orig >> $ln -s ~/anaconda/bin/pythonw /Users/aaronmeurer/anaconda/bin/python3.4 >> >> and see if anything breaks (or if you don't want to risk breaking your >> main Python install, do it in a separate conda environment). >> >> Aaron Meurer >> >> >> On Fri, Aug 15, 2014 at 2:37 PM, Derek Homeier >> <de...@as...> wrote: >> > 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 >> > >> > -- >> > Anaconda Community Support Group Brought to you by Continuum Analytics >> > --- >> > You received this message because you are subscribed to the Google >> Groups "Anaconda - Public" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to ana...@co.... >> > To post to this group, send email to ana...@co.... >> > Visit this group at >> http://groups.google.com/a/continuum.io/group/anaconda/. >> > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chr...@no... > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- ************************************* Chris Beaumont Senior Software Engineer Harvard Center for Astrophysics 60 Garden Street, MS 42 Cambridge, MA 02138 chrisbeaumont.org ************************************* |
|
From: Derek H. <de...@as...> - 2014-08-15 19:38:09
|
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 |
|
From: Eric F. <ef...@ha...> - 2014-08-15 20:22:23
|
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 |
|
From: Derek H. <de...@as...> - 2014-08-15 21:02:38
|
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 |
|
From: Eric F. <ef...@ha...> - 2014-08-16 02:32:05
|
On 2014/08/15, 10:53 AM, Derek Homeier wrote: > 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… 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X