master macosx backend broken?

Eric_Firing2 · September 17, 2013, 8:49pm

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

Damon_McDougall2 · September 18, 2013, 1:55am

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

···

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> 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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.

Eric

--
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

Damon_McDougall2 · September 18, 2013, 2:14am

Oh, and I get the linker warning both with last good commit, *and* the
first bad commit. Just as another data point.

···

On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall <damon.mcdougall@...149...> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> 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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.

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

--
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

Matt_Terry · September 18, 2013, 6:09am

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” <damon.mcdougall@…322…9…> wrote:

On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > > <damon.mcdougall@…149…> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@…229…> 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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Eric_Firing2 · September 18, 2013, 7:43am

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

···

On 2013/09/17 8:09 PM, Matt Terry wrote:

-matt

On Sep 17, 2013 7:15 PM, "Damon McDougall" <damon.mcdougall@...149... > <mailto:damon.mcdougall@…149…>> wrote:

    On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <damon.mcdougall@...149... <mailto:damon.mcdougall@…149…>> wrote:
     > On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229... > <mailto:efiring@…229…>> 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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.
     >>
     >> 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
    Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    matplotlib-devel List Signup and Options

Eric_Firing2 · September 18, 2013, 7:44am

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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.

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

···

On 2013/09/17 4:14 PM, Damon McDougall wrote:

On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > <damon.mcdougall@...149...> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> wrote:

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.

Phil_Elson · September 18, 2013, 12:30pm

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 <efiring@…229…> wrote:

On 2013/09/17 4:14 PM, Damon McDougall wrote:

On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall

<damon.mcdougall@…322…9…> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@…229…> 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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael_Droettboom · September 18, 2013, 4:00pm

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 <efiring@...229... > <mailto:efiring@…229…>> wrote:

    On 2013/09/17 4:14 PM, Damon McDougall wrote:
    > On Tue, Sep 17, 2013 at 8:55 PM, Damon McDougall > > <damon.mcdougall@...149... <mailto:damon.mcdougall@…149…>> > wrote:
    >> On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing > <efiring@...229... <mailto:efiring@…229…>> 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
    BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.
    >>>
    >>> 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
    Matplotlib-devel@lists.sourceforge.net
    <mailto:Matplotlib-devel@lists.sourceforge.net>
    matplotlib-devel List Signup and Options

------------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
_

\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

Matt_Terry · September 18, 2013, 4:28pm

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

···

On Wed, Sep 18, 2013 at 5:30 AM, Phil Elson <pelson.pub@...149...> 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?

Michael_Droettboom · September 18, 2013, 4:33pm

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

···

On 09/18/2013 12:28 PM, Matt Terry
wrote:

          On Wed, Sep 18, 2013 at 5:30 AM,
Phil Elson <pelson.pub@…149…>
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.

                   -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

Michael_Droettboom · September 18, 2013, 4:42pm

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 > <damon.mcdougall@...149...> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> 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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.

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 _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

Michael_Droettboom · September 18, 2013, 5:14pm

Try this. It at least gets "simple_plot.py" running again on the OS-X backend.

github.com/matplotlib/matplotlib

Handle Unicode font filenames correctly/Fix crashing MacOSX backend

matplotlib:master ← mdboom:unicode-font-filenames

opened 02:21PM - 18 Sep 13 UTC

mdboom

+95 -72

This is an alternative to #2431. First, when handling the output of fontconfig …(fc-match and fc-list), the bulk of the output is in ascii, so it is maintained, parsed and handled as bytes. Only once the filename part of the output is extracted do we decode it using sys.getfilesystemencoding(). Behind that bug, if you actually try to use a font file with non-ascii characters in the path: 1) Every time we passed the path to FT2Font, we were calling str() on it. This was required when FT2Font did not handle Unicode paths, prior to f4adec. However, then and now, it just serves to raise an exception when provided with a non-ascii path. 2) Within FT2Font, that unicode string was encoded for the purpose of displaying error messages. This could fail both on encoding and displaying it. Encoding it using "unicode_escape" ensures that we'll have something printable in any environment. 3) ttconv does not handle Unicode filenames. ttconv is in the process of being eliminated for MEP14, so I didn't want to invest a lot of effort fixing that. Instead, since it is only called from two places, the path is encoded back to filesystemencoding on the Python side before calling into it. This doesn't change the API to ttconv. This will require a manual backport to 1.3.x if we want that -- things are different enough there that this won't really work or apply. This approach is not necessarily "best practice" for POSIX platforms, which is to keep paths as byte strings everywhere. I tried that first, but there are too many assumptions throughout the code that file paths are unicode (particularly post f4adec with the move to six and `from __future__ import unicode_literals`). The downside of that is pretty minor -- if a path contains a sequence that does not decode using the filesystemencoding, such as an invalid utf-8 surrogate pair, it will not be openable by matplotlib. I'd consider that a pathological, even if technically legal, case, however, so I don't think we should worry too much about it. Keeping the paths as unicode objects does make the processing of them much easier, particularly with `six` and Python 3.

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 >> <damon.mcdougall@...149...> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> 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 BUG: in font_manager, handle unicode output from fontconfig by efiring · Pull Request #2431 · matplotlib/matplotlib · GitHub.

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 _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

Michael_Droettboom · September 18, 2013, 6:53pm

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

···

On 09/18/2013 12:33 PM, Michael
Droettboom wrote:

  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.

    On 09/18/2013 12:28 PM, Matt Terry

wrote:

            On Wed, Sep 18, 2013 at 5:30 AM,
Phil Elson <pelson.pub@…149…>
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.

Michiel_de_Hoon · September 18, 2013, 11:50pm

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.

Michiel_de_Hoon · September 18, 2013, 11:54pm

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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michiel_de_Hoon · September 19, 2013, 12:00am

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
Matplotlib-devel@…1034…s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michiel_de_Hoon · September 19, 2013, 10:52am

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 <mdroe@…31…>
To: matplotlib-devel@lists.sourceforge.net
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](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 > > <damon.mcdougall@...149...> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing <efiring@...229...> 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](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>](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
Matplotlib-devel@…1034…s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael_Droettboom · September 19, 2013, 4:42pm

You may want to look at or comment on the pull request I made yesterday to fix this:

github.com/matplotlib/matplotlib

Handle Unicode font filenames correctly/Fix crashing MacOSX backend

matplotlib:master ← mdboom:unicode-font-filenames

opened 02:21PM - 18 Sep 13 UTC

mdboom

+95 -72

This is an alternative to #2431. First, when handling the output of fontconfig …(fc-match and fc-list), the bulk of the output is in ascii, so it is maintained, parsed and handled as bytes. Only once the filename part of the output is extracted do we decode it using sys.getfilesystemencoding(). Behind that bug, if you actually try to use a font file with non-ascii characters in the path: 1) Every time we passed the path to FT2Font, we were calling str() on it. This was required when FT2Font did not handle Unicode paths, prior to f4adec. However, then and now, it just serves to raise an exception when provided with a non-ascii path. 2) Within FT2Font, that unicode string was encoded for the purpose of displaying error messages. This could fail both on encoding and displaying it. Encoding it using "unicode_escape" ensures that we'll have something printable in any environment. 3) ttconv does not handle Unicode filenames. ttconv is in the process of being eliminated for MEP14, so I didn't want to invest a lot of effort fixing that. Instead, since it is only called from two places, the path is encoded back to filesystemencoding on the Python side before calling into it. This doesn't change the API to ttconv. This will require a manual backport to 1.3.x if we want that -- things are different enough there that this won't really work or apply. This approach is not necessarily "best practice" for POSIX platforms, which is to keep paths as byte strings everywhere. I tried that first, but there are too many assumptions throughout the code that file paths are unicode (particularly post f4adec with the move to six and `from __future__ import unicode_literals`). The downside of that is pretty minor -- if a path contains a sequence that does not decode using the filesystemencoding, such as an invalid utf-8 surrogate pair, it will not be openable by matplotlib. I'd consider that a pathological, even if technically legal, case, however, so I don't think we should worry too much about it. Keeping the paths as unicode objects does make the processing of them much easier, particularly with `six` and Python 3.

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 <mdroe@...31...>
*To:* matplotlib-devel@lists.sourceforge.net
*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.

Handle Unicode font filenames correctly/Fix crashing MacOSX backend by mdboom · Pull Request #2433 · matplotlib/matplotlib · GitHub

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 >>> <damon.mcdougall@...149...> <mailto:damon.mcdougall@…149…> wrote:

On Tue, Sep 17, 2013 at 3:49 PM, Eric Firing<efiring@...229...> <mailto:efiring@…229…> 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/>
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
Matplotlib-devel@lists.sourceforge.net <mailto:Matplotlib-devel@lists.sourceforge.net>
matplotlib-devel List Signup and Options

--
_

\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
>>(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |