Menu
▾
▴
matplotlib-devel
|
From: Eric F. <ef...@ha...> - 2013-09-17 20:50:03
|
When I build mpl from master on python.org python 2.7, Mountain Lion, and try to plot anything with the macosx backend, I am now getting an Apple crash--the plot window flashes up and vanishes, and a big OS X crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have never seen anything like this before. Building from 1.3.0 works fine. Is anyone else seeing this? Master is also broken, at least on my machine, with other backends. The suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. Eric |
|
From: Damon M. <dam...@gm...> - 2013-09-18 01:55:55
|
On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: > When I build mpl from master on python.org python 2.7, Mountain Lion, > and try to plot anything with the macosx backend, I am now getting an > Apple crash--the plot window flashes up and vanishes, and a big OS X > crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have > never seen anything like this before. Building from 1.3.0 works fine. > > Is anyone else seeing this? > > Master is also broken, at least on my machine, with other backends. The > suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. > > Eric Building from master produces a broken build of matplotlib for me. After the build finishes, I get this warning from the linker: ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libfreetype.dylib I don't know why it's compiling with -arch i386. It's also compiling with -arch x86_64. When I install matplotlib, this is what happens from an ipython terminal: In [1]: import matplotlib In [2]: print matplotlib.__version__ 1.4.x In [3]: matplotlib.use('macosx') In [4]: import matplotlib.pyplot as plt In [5]: fig = plt.figure() In [6]: ax = fig.add_subplot(1, 1, 1) In [7]: ax.plot([1, 2, 3]) Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] In [8]: plt.show() Trace/BPT trap: 5 git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is the first bad commit, which you can see the diff of here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. That's a pretty big commit so it'll take a while to track down. I'm kind of swamped with work right now (a colleague I work with recently resigned) so I don't have as much time as I'd like to dedicate to helping out. Eric, I hope that helps a little bit. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 |
|
From: Damon M. <dam...@gm...> - 2013-09-18 02:14:43
|
On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall <dam...@gm...> wrote: > On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: >> When I build mpl from master on python.org python 2.7, Mountain Lion, >> and try to plot anything with the macosx backend, I am now getting an >> Apple crash--the plot window flashes up and vanishes, and a big OS X >> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have >> never seen anything like this before. Building from 1.3.0 works fine. >> >> Is anyone else seeing this? >> >> Master is also broken, at least on my machine, with other backends. The >> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. >> >> Eric > > Building from master produces a broken build of matplotlib for me. > After the build finishes, I get this warning from the linker: > > ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was > built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 > 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the > architecture being linked (i386): /opt/local/lib/libfreetype.dylib > > I don't know why it's compiling with -arch i386. It's also compiling > with -arch x86_64. > > When I install matplotlib, this is what happens from an ipython terminal: > > In [1]: import matplotlib > In [2]: print matplotlib.__version__ > 1.4.x > In [3]: matplotlib.use('macosx') > In [4]: import matplotlib.pyplot as plt > In [5]: fig = plt.figure() > In [6]: ax = fig.add_subplot(1, 1, 1) > In [7]: ax.plot([1, 2, 3]) > Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] > In [8]: plt.show() > Trace/BPT trap: 5 > > git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is > the first bad commit, which you can see the diff of > here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. > That's a pretty big commit so it'll take a while to track down. > > I'm kind of swamped with work right now (a colleague I work with > recently resigned) so I don't have as much time as I'd like to > dedicate to helping out. > > Eric, I hope that helps a little bit. > > Best wishes, > Damon > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 Oh, and I get the linker warning both with last good commit, *and* the first bad commit. Just as another data point. -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 |
|
From: Eric F. <ef...@ha...> - 2013-09-18 07:44:52
|
On 2013/09/17 4:14 PM, Damon McDougall wrote: > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <dam...@gm...> wrote: >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: >>> When I build mpl from master on python.org python 2.7, Mountain Lion, >>> and try to plot anything with the macosx backend, I am now getting an >>> Apple crash--the plot window flashes up and vanishes, and a big OS X >>> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have >>> never seen anything like this before. Building from 1.3.0 works fine. >>> >>> Is anyone else seeing this? >>> >>> Master is also broken, at least on my machine, with other backends. The >>> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. >>> >>> Eric >> >> Building from master produces a broken build of matplotlib for me. >> After the build finishes, I get this warning from the linker: >> >> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was >> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 >> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the >> architecture being linked (i386): /opt/local/lib/libfreetype.dylib >> >> I don't know why it's compiling with -arch i386. It's also compiling >> with -arch x86_64. >> >> When I install matplotlib, this is what happens from an ipython terminal: >> >> In [1]: import matplotlib >> In [2]: print matplotlib.__version__ >> 1.4.x >> In [3]: matplotlib.use('macosx') >> In [4]: import matplotlib.pyplot as plt >> In [5]: fig = plt.figure() >> In [6]: ax = fig.add_subplot(1, 1, 1) >> In [7]: ax.plot([1, 2, 3]) >> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] >> In [8]: plt.show() >> Trace/BPT trap: 5 >> >> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is >> the first bad commit, which you can see the diff of >> here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. >> That's a pretty big commit so it'll take a while to track down. >> >> I'm kind of swamped with work right now (a colleague I work with >> recently resigned) so I don't have as much time as I'd like to >> dedicate to helping out. >> >> Eric, I hope that helps a little bit. Damon, More than a little bit, thank you! Eric >> >> Best wishes, >> Damon >> >> -- >> Damon McDougall >> http://www.damon-is-a-geek.com >> Institute for Computational Engineering Sciences >> 201 E. 24th St. >> Stop C0200 >> The University of Texas at Austin >> Austin, TX 78712-1229 > > Oh, and I get the linker warning both with last good commit, *and* the > first bad commit. Just as another data point. > |
|
From: Phil E. <pel...@gm...> - 2013-09-18 12:30:18
|
Is it time to have the discussion about dropping the MacOS backend? I know an incredible amount of top quality developer time has gone into it, but in truth it is not up to the *Agg backends and without another massive amount of work, never will be. Not to mention the drag that having YAB (yet another backend) to maintain and support adds. Deleting the MacOS backend doesn't mean the end of its life - if somebody cares enough they will probably set up a repo and maintain it themselves, but I can think of a million and one things I'd sooner have matplotlib developers working on than getting the MacOS backend upto the *Agg standard. Thoughts? On 18 September 2013 08:44, Eric Firing <ef...@ha...> wrote: > On 2013/09/17 4:14 PM, Damon McDougall wrote: > > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > > <dam...@gm...> wrote: > >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> > wrote: > >>> When I build mpl from master on python.org python 2.7, Mountain Lion, > >>> and try to plot anything with the macosx backend, I am now getting an > >>> Apple crash--the plot window flashes up and vanishes, and a big OS X > >>> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I > have > >>> never seen anything like this before. Building from 1.3.0 works fine. > >>> > >>> Is anyone else seeing this? > >>> > >>> Master is also broken, at least on my machine, with other backends. > The > >>> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. > >>> > >>> Eric > >> > >> Building from master produces a broken build of matplotlib for me. > >> After the build finishes, I get this warning from the linker: > >> > >> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was > >> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 > >> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the > >> architecture being linked (i386): /opt/local/lib/libfreetype.dylib > >> > >> I don't know why it's compiling with -arch i386. It's also compiling > >> with -arch x86_64. > >> > >> When I install matplotlib, this is what happens from an ipython > terminal: > >> > >> In [1]: import matplotlib > >> In [2]: print matplotlib.__version__ > >> 1.4.x > >> In [3]: matplotlib.use('macosx') > >> In [4]: import matplotlib.pyplot as plt > >> In [5]: fig = plt.figure() > >> In [6]: ax = fig.add_subplot(1, 1, 1) > >> In [7]: ax.plot([1, 2, 3]) > >> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] > >> In [8]: plt.show() > >> Trace/BPT trap: 5 > >> > >> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is > >> the first bad commit, which you can see the diff of > >> here< > https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92 > >. > >> That's a pretty big commit so it'll take a while to track down. > >> > >> I'm kind of swamped with work right now (a colleague I work with > >> recently resigned) so I don't have as much time as I'd like to > >> dedicate to helping out. > >> > >> Eric, I hope that helps a little bit. > > Damon, > > More than a little bit, thank you! > > Eric > > >> > >> Best wishes, > >> Damon > >> > >> -- > >> Damon McDougall > >> http://www.damon-is-a-geek.com > >> Institute for Computational Engineering Sciences > >> 201 E. 24th St. > >> Stop C0200 > >> The University of Texas at Austin > >> Austin, TX 78712-1229 > > > > Oh, and I get the linker warning both with last good commit, *and* the > > first bad commit. Just as another data point. > > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Michael D. <md...@st...> - 2013-09-18 16:00:31
|
I think an objective comparison of features and performance between Agg and macosx would be a helpful place to start the discussion, just so we know what we're talking about here. I seem to recall one of Michiel de Hoon's original motivations was performance, perhaps related to hardware rendering, but I haven't seen any solid numbers on that, and I didn't have a Mac at the time. I have sort of a long term plan to start doing some benchmarking a la "Codespeed" on matplotlib, but haven't found the time to really dig into it. It might make sense to resurrect the PyObjC backend, if that makes sense as part of the solution, as it has some of the "native GUI" benefits of macosx without doing reimplementing any of the tricky rendering bits. Mike On 09/18/2013 08:30 AM, Phil Elson wrote: > Is it time to have the discussion about dropping the MacOS backend? > > I know an incredible amount of top quality developer time has gone > into it, but in truth it is not up to the *Agg backends and without > another massive amount of work, never will be. Not to mention the drag > that having YAB (yet another backend) to maintain and support adds. > > Deleting the MacOS backend doesn't mean the end of its life - if > somebody cares enough they will probably set up a repo and maintain it > themselves, but I can think of a million and one things I'd sooner > have matplotlib developers working on than getting the MacOS backend > upto the *Agg standard. > > Thoughts? > > > > > On 18 September 2013 08:44, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > > On 2013/09/17 4:14 PM, Damon McDougall wrote: > > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > > <dam...@gm... <mailto:dam...@gm...>> > wrote: > >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing > <ef...@ha... <mailto:ef...@ha...>> wrote: > >>> When I build mpl from master on python.org <http://python.org> > python 2.7, Mountain Lion, > >>> and try to plot anything with the macosx backend, I am now > getting an > >>> Apple crash--the plot window flashes up and vanishes, and a > big OS X > >>> crash report window pops up. Ipython shows "Trace/BPT trap: > 5". I have > >>> never seen anything like this before. Building from 1.3.0 > works fine. > >>> > >>> Is anyone else seeing this? > >>> > >>> Master is also broken, at least on my machine, with other > backends. The > >>> suggested fix is > https://github.com/matplotlib/matplotlib/pull/2431. > >>> > >>> Eric > >> > >> Building from master produces a broken build of matplotlib for me. > >> After the build finishes, I get this warning from the linker: > >> > >> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, > file was > >> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x > 0 0x 0 > >> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the > >> architecture being linked (i386): /opt/local/lib/libfreetype.dylib > >> > >> I don't know why it's compiling with -arch i386. It's also > compiling > >> with -arch x86_64. > >> > >> When I install matplotlib, this is what happens from an ipython > terminal: > >> > >> In [1]: import matplotlib > >> In [2]: print matplotlib.__version__ > >> 1.4.x > >> In [3]: matplotlib.use('macosx') > >> In [4]: import matplotlib.pyplot as plt > >> In [5]: fig = plt.figure() > >> In [6]: ax = fig.add_subplot(1, 1, 1) > >> In [7]: ax.plot([1, 2, 3]) > >> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] > >> In [8]: plt.show() > >> Trace/BPT trap: 5 > >> > >> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is > >> the first bad commit, which you can see the diff of > >> > here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. > >> That's a pretty big commit so it'll take a while to track down. > >> > >> I'm kind of swamped with work right now (a colleague I work with > >> recently resigned) so I don't have as much time as I'd like to > >> dedicate to helping out. > >> > >> Eric, I hope that helps a little bit. > > Damon, > > More than a little bit, thank you! > > Eric > > >> > >> Best wishes, > >> Damon > >> > >> -- > >> Damon McDougall > >> http://www.damon-is-a-geek.com > >> Institute for Computational Engineering Sciences > >> 201 E. 24th St. > >> Stop C0200 > >> The University of Texas at Austin > >> Austin, TX 78712-1229 > > > > Oh, and I get the linker warning both with last good commit, > *and* the > > first bad commit. Just as another data point. > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power > Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Michiel de H. <mjl...@ya...> - 2013-09-18 23:50:49
|
Hi all, At the time when the Mac OS X backend was first introduced, its performance was significantly better than other backends, but this was due to the way its event loop is organized. Nowadays the other backends use the same event loop organization, and as far as I know currently there is no significant performance difference between Agg and macosx. So now the only advantage of the Mac OS X backend is that it does not depend on 3rd-party libraries, and therefore is a reliable backend when Apple releases a new version of Mac OS X, whereas other backends may have to wait for updates to the 3rd-party libraries. Best, -Michiel. ________________________________ I think an objective comparison of features and performance between Agg and macosx would be a helpful place to start the discussion, just so we know what we're talking about here. I seem to recall one of Michiel de Hoon's original motivations was performance, perhaps related to hardware rendering, but I haven't seen any solid numbers on that, and I didn't have a Mac at the time. |
|
From: Matt T. <mat...@gm...> - 2013-09-18 16:28:35
|
On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pel...@gm...> wrote: > Is it time to have the discussion about dropping the MacOS backend? > > I know an incredible amount of top quality developer time has gone into > it, but in truth it is not up to the *Agg backends and without another > massive amount of work, never will be. Not to mention the drag that having > YAB (yet another backend) to maintain and support adds. > > Deleting the MacOS backend doesn't mean the end of its life - if somebody > cares enough they will probably set up a repo and maintain it themselves, > but I can think of a million and one things I'd sooner have matplotlib > developers working on than getting the MacOS backend upto the *Agg standard. > > Thoughts? > I'm not sure how much easier this will make our lives. The backend options on mac are (in order of mpl's preference): macosx (no deps) qt4agg (needs qt) gtk3agg (needs gtk) tkagg (needs tk) wxagg (needs wx) Don't get me wrong, I am not thrilled with the macosx backend, especially that can't-draw-outside-the-event-loop issue, but I doubt that dropping it will make our lives easier. Its big advantage is that it does not require a third-party windowing library. If we drop macosx, we're going to have to deal with automated installing of a windowing library. This is going to be hard because mac doesn't have a package manager we can rely on (in fact it has 5 that sometimes coexist brew/macports/fink/manually installed dmg/pip). The easiest target is probably tkagg. For that backend, there are known (segfaulting) issues between different combinations of macos/python.org-python/activetkl. So we will have to have an assortment of binary installers to cover that problem. We will also have to continue being wary of multiple versions of tkl installed on the system. This particular issue looks like a build problem. The change that introduce the bug was in the 2to3->six transition, which shouldn't have affect the internals, but obviously did. -matt |
|
From: Michael D. <md...@st...> - 2013-09-18 16:33:29
|
On 09/18/2013 12:28 PM, Matt Terry wrote: > On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pel...@gm... > <mailto:pel...@gm...>> wrote: > > Is it time to have the discussion about dropping the MacOS backend? > > I know an incredible amount of top quality developer time has gone > into it, but in truth it is not up to the *Agg backends and > without another massive amount of work, never will be. Not to > mention the drag that having YAB (yet another backend) to maintain > and support adds. > > Deleting the MacOS backend doesn't mean the end of its life - if > somebody cares enough they will probably set up a repo and > maintain it themselves, but I can think of a million and one > things I'd sooner have matplotlib developers working on than > getting the MacOS backend upto the *Agg standard. > > Thoughts? > > > I'm not sure how much easier this will make our lives. The backend > options on mac are (in order of mpl's preference): > macosx (no deps) > qt4agg (needs qt) > gtk3agg (needs gtk) > tkagg (needs tk) > wxagg (needs wx) > > Don't get me wrong, I am not thrilled with the macosx backend, > especially that can't-draw-outside-the-event-loop issue, but I doubt > that dropping it will make our lives easier. Its big advantage is > that it does not require a third-party windowing library. > > If we drop macosx, we're going to have to deal with automated > installing of a windowing library. This is going to be hard because > mac doesn't have a package manager we can rely on (in fact it has 5 > that sometimes coexist brew/macports/fink/manually installed dmg/pip). > > The easiest target is probably tkagg. For that backend, there are > known (segfaulting) issues between different combinations of > macos/python.org-python/activetkl. So we will have to have an > assortment of binary installers to cover that problem. We will also > have to continue being wary of multiple versions of tkl installed on > the system. > > This particular issue looks like a build problem. The change that > introduce the bug was in the 2to3->six transition, which shouldn't > have affect the internals, but obviously did. > I don't disagree with any of this, but we should add to consideration the resurrection of the cocoaagg backend, based on pyobjc. It does have the pyobjc dependency, but that is much smaller and less problematic than the windowing toolkits mentioned. Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Michael D. <md...@st...> - 2013-09-18 18:56:25
|
On 09/18/2013 12:33 PM, Michael Droettboom wrote: > On 09/18/2013 12:28 PM, Matt Terry wrote: >> On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pel...@gm... >> <mailto:pel...@gm...>> wrote: >> >> Is it time to have the discussion about dropping the MacOS backend? >> >> I know an incredible amount of top quality developer time has >> gone into it, but in truth it is not up to the *Agg backends and >> without another massive amount of work, never will be. Not to >> mention the drag that having YAB (yet another backend) to >> maintain and support adds. >> >> Deleting the MacOS backend doesn't mean the end of its life - if >> somebody cares enough they will probably set up a repo and >> maintain it themselves, but I can think of a million and one >> things I'd sooner have matplotlib developers working on than >> getting the MacOS backend upto the *Agg standard. >> >> Thoughts? >> >> >> I'm not sure how much easier this will make our lives. The backend >> options on mac are (in order of mpl's preference): >> macosx (no deps) >> qt4agg (needs qt) >> gtk3agg (needs gtk) >> tkagg (needs tk) >> wxagg (needs wx) >> >> Don't get me wrong, I am not thrilled with the macosx backend, >> especially that can't-draw-outside-the-event-loop issue, but I doubt >> that dropping it will make our lives easier. Its big advantage is >> that it does not require a third-party windowing library. >> >> If we drop macosx, we're going to have to deal with automated >> installing of a windowing library. This is going to be hard because >> mac doesn't have a package manager we can rely on (in fact it has 5 >> that sometimes coexist brew/macports/fink/manually installed dmg/pip). >> >> The easiest target is probably tkagg. For that backend, there are >> known (segfaulting) issues between different combinations of >> macos/python.org-python/activetkl. So we will have to have an >> assortment of binary installers to cover that problem. We will also >> have to continue being wary of multiple versions of tkl installed on >> the system. >> >> This particular issue looks like a build problem. The change that >> introduce the bug was in the 2to3->six transition, which shouldn't >> have affect the internals, but obviously did. >> > > I don't disagree with any of this, but we should add to consideration > the resurrection of the cocoaagg backend, based on pyobjc. It does > have the pyobjc dependency, but that is much smaller and less > problematic than the windowing toolkits mentioned. Yet another option -- we reduce the MacOSX backend to just the minimum required to display an Agg buffer on the screen and handle mouse and keyboard events. Basically turn it into a GUI backend, not a GUI and renderer backend. It would address Matt's dependency concern, while also being a whole lot more maintainable. Mike |
|
From: Michiel de H. <mjl...@ya...> - 2013-09-19 00:00:40
|
Hi all, Cocoaagg could solve a lot of problems, but it depends on whether pyojbc is being actively maintained. I seem to remember that that was not always the case in the past. If we do decide pyobjc, we may consider a agg-free backend that does not require any compilation. Best, -Michiel. ________________________________ I don't disagree with any of this, but we should add to consideration the resurrection of the cocoaagg backend, based on pyobjc. It does have the pyobjc dependency, but that is much smaller and less problematic than the windowing toolkits mentioned. _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Michiel de H. <mjl...@ya...> - 2013-09-18 23:54:37
|
Hi all, ________________________________ Don't get me wrong, I am not thrilled with the macosx backend, especially that can't-draw-outside-the-event-loop issue,... I don't think this is a disadvantage: The macosx backend just enforces a cleaner coding style. The other backends are more forgiving, but I don't think that that is a good thing. Best, -Michiel. _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Michael D. <md...@st...> - 2013-09-18 16:42:37
|
FWIW, once getting past the error reported by Eric in 2431, I am able to reproduce this on my Mac. I'm looking into it. I suspect something in the macosx backend is getting passed a unicode string where it used to get a byte string. Mike On 09/17/2013 10:14 PM, Damon McDougall wrote: > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <dam...@gm...> wrote: >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: >>> When I build mpl from master on python.org python 2.7, Mountain Lion, >>> and try to plot anything with the macosx backend, I am now getting an >>> Apple crash--the plot window flashes up and vanishes, and a big OS X >>> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have >>> never seen anything like this before. Building from 1.3.0 works fine. >>> >>> Is anyone else seeing this? >>> >>> Master is also broken, at least on my machine, with other backends. The >>> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. >>> >>> Eric >> Building from master produces a broken build of matplotlib for me. >> After the build finishes, I get this warning from the linker: >> >> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was >> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 >> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the >> architecture being linked (i386): /opt/local/lib/libfreetype.dylib >> >> I don't know why it's compiling with -arch i386. It's also compiling >> with -arch x86_64. >> >> When I install matplotlib, this is what happens from an ipython terminal: >> >> In [1]: import matplotlib >> In [2]: print matplotlib.__version__ >> 1.4.x >> In [3]: matplotlib.use('macosx') >> In [4]: import matplotlib.pyplot as plt >> In [5]: fig = plt.figure() >> In [6]: ax = fig.add_subplot(1, 1, 1) >> In [7]: ax.plot([1, 2, 3]) >> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] >> In [8]: plt.show() >> Trace/BPT trap: 5 >> >> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is >> the first bad commit, which you can see the diff of >> here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. >> That's a pretty big commit so it'll take a while to track down. >> >> I'm kind of swamped with work right now (a colleague I work with >> recently resigned) so I don't have as much time as I'd like to >> dedicate to helping out. >> >> Eric, I hope that helps a little bit. >> >> Best wishes, >> Damon >> >> -- >> Damon McDougall >> http://www.damon-is-a-geek.com >> Institute for Computational Engineering Sciences >> 201 E. 24th St. >> Stop C0200 >> The University of Texas at Austin >> Austin, TX 78712-1229 > Oh, and I get the linker warning both with last good commit, *and* the > first bad commit. Just as another data point. > -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Michael D. <md...@st...> - 2013-09-18 17:14:14
|
Try this. It at least gets "simple_plot.py" running again on the OS-X backend. https://github.com/matplotlib/matplotlib/pull/2433 Mike On 09/18/2013 12:42 PM, Michael Droettboom wrote: > FWIW, once getting past the error reported by Eric in 2431, I am able to > reproduce this on my Mac. I'm looking into it. I suspect something in > the macosx backend is getting passed a unicode string where it used to > get a byte string. > > Mike > > On 09/17/2013 10:14 PM, Damon McDougall wrote: >> On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall >> <dam...@gm...> wrote: >>> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: >>>> When I build mpl from master on python.org python 2.7, Mountain Lion, >>>> and try to plot anything with the macosx backend, I am now getting an >>>> Apple crash--the plot window flashes up and vanishes, and a big OS X >>>> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have >>>> never seen anything like this before. Building from 1.3.0 works fine. >>>> >>>> Is anyone else seeing this? >>>> >>>> Master is also broken, at least on my machine, with other backends. The >>>> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. >>>> >>>> Eric >>> Building from master produces a broken build of matplotlib for me. >>> After the build finishes, I get this warning from the linker: >>> >>> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was >>> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 >>> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the >>> architecture being linked (i386): /opt/local/lib/libfreetype.dylib >>> >>> I don't know why it's compiling with -arch i386. It's also compiling >>> with -arch x86_64. >>> >>> When I install matplotlib, this is what happens from an ipython terminal: >>> >>> In [1]: import matplotlib >>> In [2]: print matplotlib.__version__ >>> 1.4.x >>> In [3]: matplotlib.use('macosx') >>> In [4]: import matplotlib.pyplot as plt >>> In [5]: fig = plt.figure() >>> In [6]: ax = fig.add_subplot(1, 1, 1) >>> In [7]: ax.plot([1, 2, 3]) >>> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] >>> In [8]: plt.show() >>> Trace/BPT trap: 5 >>> >>> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is >>> the first bad commit, which you can see the diff of >>> here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. >>> That's a pretty big commit so it'll take a while to track down. >>> >>> I'm kind of swamped with work right now (a colleague I work with >>> recently resigned) so I don't have as much time as I'd like to >>> dedicate to helping out. >>> >>> Eric, I hope that helps a little bit. >>> >>> Best wishes, >>> Damon >>> >>> -- >>> Damon McDougall >>> http://www.damon-is-a-geek.com >>> Institute for Computational Engineering Sciences >>> 201 E. 24th St. >>> Stop C0200 >>> The University of Texas at Austin >>> Austin, TX 78712-1229 >> Oh, and I get the linker warning both with last good commit, *and* the >> first bad commit. Just as another data point. >> > -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Michiel de H. <mjl...@ya...> - 2013-09-19 10:52:28
|
The crash occurs in the call to get_text_width_height_descent(self, s, prop, ismath) due to the fact that family = prop.get_family() previously returned a list of strings, while now it returns a list of unicode strings. The backend then fails to find the font, and crashes over a NULL pointer. I will add a check for a NULL pointer and raise a Python exception appropriately, and also modify the backend to allow for unicode strings. Note that other backends may also trip over this). Best, -Michiel. ________________________________ From: Michael Droettboom <md...@st...> To: mat...@li... Sent: Thursday, September 19, 2013 2:14 AM Subject: Re: [matplotlib-devel] master macosx backend broken? Try this. It at least gets "simple_plot.py" running again on the OS-X backend. https://github.com/matplotlib/matplotlib/pull/2433 Mike On 09/18/2013 12:42 PM, Michael Droettboom wrote: FWIW, once getting past the error reported by Eric in 2431, I am able to reproduce this on my Mac. I'm looking into it. I suspect something in the macosx backend is getting passed a unicode string where it used to get a byte string. Mike On 09/17/2013 10:14 PM, Damon McDougall wrote: >On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall <dam...@gm...> wrote: >>On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: >>>When I build mpl from master on python.org python 2.7, Mountain Lion, and try to plot anything with the macosx backend, I am now getting an Apple crash--the plot window flashes up and vanishes, and a big OS X crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have never seen anything like this before. Building from 1.3.0 works fine. Is anyone else seeing this? Master is also broken, at least on my machine, with other backends. The suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. Eric >>>Building from master produces a broken build of matplotlib for me. After the build finishes, I get this warning from the linker: ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the architecture being linked (i386): /opt/local/lib/libfreetype.dylib I don't know why it's compiling with -arch i386. It's also compiling with -arch x86_64. When I install matplotlib, this is what happens from an ipython terminal: In [1]: import matplotlib In [2]: print matplotlib.__version__ 1.4.x In [3]: matplotlib.use('macosx') In [4]: import matplotlib.pyplot as plt In [5]: fig = plt.figure() In [6]: ax = fig.add_subplot(1, 1, 1) In [7]: ax.plot([1, 2, 3]) Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] In [8]: plt.show() Trace/BPT trap: 5 git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is the first bad commit, which you can see the diff of here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. That's a pretty big commit so it'll take a while to track down. I'm kind of swamped with work right now (a colleague I work with recently resigned) so I don't have as much time as I'd like to dedicate to helping out. Eric, I hope that helps a little bit. Best wishes, Damon -- Damon McDougall http://www.damon-is-a-geek.com Institute for Computational Engineering Sciences 201 E. 24th St. Stop C0200 The University of Texas at Austin Austin, TX 78712-1229 >>Oh, and I get the linker warning both with last good commit, *and* the first bad commit. Just as another data point. -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Michael D. <md...@st...> - 2013-09-19 16:45:43
|
You may want to look at or comment on the pull request I made yesterday to fix this: https://github.com/matplotlib/matplotlib/pull/2433 Mike On 09/19/2013 06:52 AM, Michiel de Hoon wrote: > The crash occurs in the call to get_text_width_height_descent(self, s, > prop, ismath) due to the fact that > family = prop.get_family() previously returned a list of strings, > while now it returns a list of unicode strings. The backend then fails > to find the font, and crashes over a NULL pointer. I will add a check > for a NULL pointer and raise a Python exception appropriately, and > also modify the backend to allow for unicode strings. > Note that other backends may also trip over this). > > Best, > -Michiel. > > ------------------------------------------------------------------------ > *From:* Michael Droettboom <md...@st...> > *To:* mat...@li... > *Sent:* Thursday, September 19, 2013 2:14 AM > *Subject:* Re: [matplotlib-devel] master macosx backend broken? > > Try this. It at least gets "simple_plot.py" running again on the OS-X > backend. > > https://github.com/matplotlib/matplotlib/pull/2433 > > Mike > > On 09/18/2013 12:42 PM, Michael Droettboom wrote: >> FWIW, once getting past the error reported by Eric in 2431, I am able to >> reproduce this on my Mac. I'm looking into it. I suspect something in >> the macosx backend is getting passed a unicode string where it used to >> get a byte string. >> >> Mike >> >> On 09/17/2013 10:14 PM, Damon McDougall wrote: >>> On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall >>> <dam...@gm...> <mailto:dam...@gm...> wrote: >>>> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing<ef...@ha...> <mailto:ef...@ha...> wrote: >>>>> When I build mpl from master on python.org python 2.7, Mountain Lion, >>>>> and try to plot anything with the macosx backend, I am now getting an >>>>> Apple crash--the plot window flashes up and vanishes, and a big OS X >>>>> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have >>>>> never seen anything like this before. Building from 1.3.0 works fine. >>>>> >>>>> Is anyone else seeing this? >>>>> >>>>> Master is also broken, at least on my machine, with other backends. The >>>>> suggested fix ishttps://github.com/matplotlib/matplotlib/pull/2431. >>>>> >>>>> Eric >>>> Building from master produces a broken build of matplotlib for me. >>>> After the build finishes, I get this warning from the linker: >>>> >>>> ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was >>>> built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 >>>> 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the >>>> architecture being linked (i386): /opt/local/lib/libfreetype.dylib >>>> >>>> I don't know why it's compiling with -arch i386. It's also compiling >>>> with -arch x86_64. >>>> >>>> When I install matplotlib, this is what happens from an ipython terminal: >>>> >>>> In [1]: import matplotlib >>>> In [2]: print matplotlib.__version__ >>>> 1.4.x >>>> In [3]: matplotlib.use('macosx') >>>> In [4]: import matplotlib.pyplot as plt >>>> In [5]: fig = plt.figure() >>>> In [6]: ax = fig.add_subplot(1, 1, 1) >>>> In [7]: ax.plot([1, 2, 3]) >>>> Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] >>>> In [8]: plt.show() >>>> Trace/BPT trap: 5 >>>> >>>> git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is >>>> the first bad commit, which you can see the diff of >>>> here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92> <https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. >>>> That's a pretty big commit so it'll take a while to track down. >>>> >>>> I'm kind of swamped with work right now (a colleague I work with >>>> recently resigned) so I don't have as much time as I'd like to >>>> dedicate to helping out. >>>> >>>> Eric, I hope that helps a little bit. >>>> >>>> Best wishes, >>>> Damon >>>> >>>> -- >>>> Damon McDougall >>>> http://www.damon-is-a-geek.com <http://www.damon-is-a-geek.com/> >>>> Institute for Computational Engineering Sciences >>>> 201 E. 24th St. >>>> Stop C0200 >>>> The University of Texas at Austin >>>> Austin, TX 78712-1229 >>> Oh, and I get the linker warning both with last good commit, *and* the >>> first bad commit. Just as another data point. >>> > > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com <http://www.droettboom.com/> > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
|
From: Matt T. <mat...@gm...> - 2013-09-18 06:09:35
|
My mac testing hasn't picked up on this, but I don't think we have any tests that actually draw to the screen. I have noticed a i386 linking error, but haven't gotten to it. Is there an automated way to test this? Something like: Make a simple plot show() close the window after 10s. -matt On Sep 17, 2013 7:15 PM, "Damon McDougall" <dam...@gm...> wrote: > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <dam...@gm...> wrote: > > On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha...> wrote: > >> When I build mpl from master on python.org python 2.7, Mountain Lion, > >> and try to plot anything with the macosx backend, I am now getting an > >> Apple crash--the plot window flashes up and vanishes, and a big OS X > >> crash report window pops up. Ipython shows "Trace/BPT trap: 5". I have > >> never seen anything like this before. Building from 1.3.0 works fine. > >> > >> Is anyone else seeing this? > >> > >> Master is also broken, at least on my machine, with other backends. The > >> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. > >> > >> Eric > > > > Building from master produces a broken build of matplotlib for me. > > After the build finishes, I get this warning from the linker: > > > > ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was > > built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 > > 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the > > architecture being linked (i386): /opt/local/lib/libfreetype.dylib > > > > I don't know why it's compiling with -arch i386. It's also compiling > > with -arch x86_64. > > > > When I install matplotlib, this is what happens from an ipython terminal: > > > > In [1]: import matplotlib > > In [2]: print matplotlib.__version__ > > 1.4.x > > In [3]: matplotlib.use('macosx') > > In [4]: import matplotlib.pyplot as plt > > In [5]: fig = plt.figure() > > In [6]: ax = fig.add_subplot(1, 1, 1) > > In [7]: ax.plot([1, 2, 3]) > > Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] > > In [8]: plt.show() > > Trace/BPT trap: 5 > > > > git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is > > the first bad commit, which you can see the diff of > > here< > https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92 > >. > > That's a pretty big commit so it'll take a while to track down. > > > > I'm kind of swamped with work right now (a colleague I work with > > recently resigned) so I don't have as much time as I'd like to > > dedicate to helping out. > > > > Eric, I hope that helps a little bit. > > > > Best wishes, > > Damon > > > > -- > > Damon McDougall > > http://www.damon-is-a-geek.com > > Institute for Computational Engineering Sciences > > 201 E. 24th St. > > Stop C0200 > > The University of Texas at Austin > > Austin, TX 78712-1229 > > Oh, and I get the linker warning both with last good commit, *and* the > first bad commit. Just as another data point. > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 > > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack > includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Eric F. <ef...@ha...> - 2013-09-18 07:43:46
|
On 2013/09/17 8:09 PM, Matt Terry wrote: > My mac testing hasn't picked up on this, but I don't think we have any > tests that actually draw to the screen. I have noticed a i386 linking > error, but haven't gotten to it. > > Is there an automated way to test this? Something like: > Make a simple plot > show() > close the window after 10s. Matt, I don't know--I would think it would be hard to make an automated test that can handle a full-on python crash. It leaves behind a screen with extensive diagnostics that it says are being sent to Apple. Eric > > -matt > > On Sep 17, 2013 7:15 PM, "Damon McDougall" <dam...@gm... > <mailto:dam...@gm...>> wrote: > > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <dam...@gm... <mailto:dam...@gm...>> wrote: > > On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <ef...@ha... > <mailto:ef...@ha...>> wrote: > >> When I build mpl from master on python.org <http://python.org> > python 2.7, Mountain Lion, > >> and try to plot anything with the macosx backend, I am now > getting an > >> Apple crash--the plot window flashes up and vanishes, and a big OS X > >> crash report window pops up. Ipython shows "Trace/BPT trap: 5". > I have > >> never seen anything like this before. Building from 1.3.0 works > fine. > >> > >> Is anyone else seeing this? > >> > >> Master is also broken, at least on my machine, with other > backends. The > >> suggested fix is https://github.com/matplotlib/matplotlib/pull/2431. > >> > >> Eric > > > > Building from master produces a broken build of matplotlib for me. > > After the build finishes, I get this warning from the linker: > > > > ld: warning: ignoring file /opt/local/lib/libfreetype.dylib, file was > > built for unsupported file format ( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 > 0x 0 > > 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) which is not the > > architecture being linked (i386): /opt/local/lib/libfreetype.dylib > > > > I don't know why it's compiling with -arch i386. It's also compiling > > with -arch x86_64. > > > > When I install matplotlib, this is what happens from an ipython > terminal: > > > > In [1]: import matplotlib > > In [2]: print matplotlib.__version__ > > 1.4.x > > In [3]: matplotlib.use('macosx') > > In [4]: import matplotlib.pyplot as plt > > In [5]: fig = plt.figure() > > In [6]: ax = fig.add_subplot(1, 1, 1) > > In [7]: ax.plot([1, 2, 3]) > > Out[7]: [<matplotlib.lines.Line2D at 0x107523250>] > > In [8]: plt.show() > > Trace/BPT trap: 5 > > > > git bisecting says that f4adec7b569cfd0b30e0f8367ba8618b9e160f92 is > > the first bad commit, which you can see the diff of > > > here<https://github.com/matplotlib/matplotlib/commit/f4adec7b569cfd0b30e0f8367ba8618b9e160f92>. > > That's a pretty big commit so it'll take a while to track down. > > > > I'm kind of swamped with work right now (a colleague I work with > > recently resigned) so I don't have as much time as I'd like to > > dedicate to helping out. > > > > Eric, I hope that helps a little bit. > > > > Best wishes, > > Damon > > > > -- > > Damon McDougall > > http://www.damon-is-a-geek.com > > Institute for Computational Engineering Sciences > > 201 E. 24th St. > > Stop C0200 > > The University of Texas at Austin > > Austin, TX 78712-1229 > > Oh, and I get the linker warning both with last good commit, *and* the > first bad commit. Just as another data point. > > -- > Damon McDougall > http://www.damon-is-a-geek.com > Institute for Computational Engineering Sciences > 201 E. 24th St. > Stop C0200 > The University of Texas at Austin > Austin, TX 78712-1229 > > ------------------------------------------------------------------------------ > LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! > 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, > SharePoint > 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power > Pack includes > Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. > http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto: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