matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Matt T. <mat...@gm...>]

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

Re: [matplotlib-devel] muilti figure backend

[Federico A. <ari...@gm...>]

I forgot about the diff link.

https://github.com/fariza/matplotlib/compare/tabbed-gtk3-figuremanager

I try to place everything where it is supposed to go (backend_bases)




On Wed, Sep 18, 2013 at 8:38 AM, Phil Elson <pel...@gm...> wrote:
>
> No need to be nervous. We are a friendly bunch and this is cool stuff.
>
> I haven't looked at your code (a diff link would be useful), but the obvious first questions would be:
>



> Can I display multiple tabs at the same time (i.e. tab splitting)

At first sight, I do not see why not, the multiFigureBackend just
controls adding, removing and switching from one figure to another.
Giving the toolbar control to the active figure.

> If so, can I programatically control the splitting?
I was thinking about this, and I think it is possible to add as many
instances of the MultiFigureManager as we want, and place figures in
the desired one. Removing and adding them is also possible.

>
> On that front, did you consider looking at implementing the tabbing in matplotlib itself? Obviously there is nothing there at the moment, but it is conceivable that "tab" buttons could be added to a special "figure" which when clicked change which figure is being rendered in the plot area. Doing so would mean that your GUI doesn't look like native tabs, but it would mean that it would instantly work on all interactive backends. Just a thought.
>
I did not think about this, but to be honest, I do not like the
matplotlib widgets :(

> Anyway, I'm not sure how we take this forward - I can't imagine we would want to take on a whole new set of backends for tabbed browsing specifically, but it could potentially be integrated together with the existing backends I suppose.

As I tried to implement it, if the corresponding MultiFigureBackend is
implemented for the selected backend,  and
matplotlib.rcParams['backend.single_window'] = True
This will be loaded if not, the traditional backend work as always.

Of course all of these possibilities have to be tested, to see...

>
> Nice work!
>
> Phil
>
>
>
>
>
> On 18 September 2013 01:07, Federico Ariza <ari...@gm...> wrote:
>>
>> Hello everybody:
>>
>> This is my first post here, I am a little bit nervous, because this is my first post :D, and also because I want to talk about a touchy subject....
>>
>> In my work I have developped several backends to manage multiple figures at the same time, from what I see around, this is something that could be of interest for many people.
>> I have done it in gtk, wx, tk, and now I am doing it again in gtk3.
>>
>> So I thought it would be nice to try to run this idea by you.
>> If you look at the attached images, you will see what I mean.
>>
>> The code is in
>> https://github.com/fariza/matplotlib/tree/tabbed-gtk3-figuremanager
>>
>>
>> I know I should have done another file for the figure manager, but because it sits in between backend_bases.py and backend_gtk3xxx.py It was easier for me to test directly inside backend_gtk3.py
>>
>> Other think that I dislike, is that to extend the current backend, you have to get your hands pretty dirty and understand alot of things to make sense of how things work.
>>
>> I modified examples/pylab_examples/multiple_figs_demo.py
>> to show it working.
>>
>> In the example, I added a stupid class, to show how can we attach external tools to the toolbar without complex manipulations.
>> Also, this could be used to produce a tools library, and keeps things clean, in gtk3 backend there is a DialogLineprops, in qt there are other things similar, but all of them are separated and can not be reused....
>>
>> Take a look and let me know what you think.
>> The only think needed to run with other examples is to use (gtk3 agg or cairo) and set the rcparam
>>
>> matplotlib.use('gtk3agg')
>> matplotlib.rcParams['backend.gtk3.tabbed'] = True
>>
>> I tried to comment the code, but not to document it, because I want to have feedback before investing time in documenting something that maybe will be only for me.
>>
>> Thanks
>> Federico
>>
>>
>>
>>
>>
>> --
>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>
>> -- Antonio Alducin --
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin -

Re: [matplotlib-devel] master macosx backend broken?

[Michael D. <md...@st...>]

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

[matplotlib-devel] Regular matplotlib meetings

[Michael D. <md...@st...>]

As I had considered doing a while ago, I think it might be beneficial to 
start having regular Google Hangouts for matplotlib. I'm thinking 
monthly is probably adequate for now while we experiment with the format.

As you may know, Google Hangouts has a maximum number of 10 
participants, but an unlimited number of people may watch both live and 
from the archive.  I believe also (correct me if I'm wrong) there is no 
such limit on the people who can participate by text chat.

I've created a "Doodle" poll [1] to help find a time during the week 
that would be best for most.

[1] http://doodle.com/fek9q2wsyegg6ytt

I figure many of these meetings will include a "core" group of people 
with "special guests" for various specific topics as they arise.  Anyone 
can fill out the poll, but please send me an e-mail off list if you plan 
to attend on a regular basis rather than just drop in when possible so I 
can prioritize things.  Once we've determined a good time of the week 
for everyone, I'll schedule the next 6 or so months on the matplotlib 
Google calendar [2].

[2] 
https://www.google.com/calendar/feeds/79hk8jhvlks8jn8ds4ri1e6q4g%40group.calendar.google.com/public/basic

Cheers,
Mike

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

http://www.droettboom.com

Re: [matplotlib-devel] 1.4.0 release schedule

[Phil E. <pel...@gm...>]

Wooho. New year, new release! It's going to be a busy Christmas :-)


On 18 September 2013 16:14, Michael Droettboom <md...@st...> wrote:

> Looking approximately six months after when 1.3.0 was released
> (31-07-2013, after much delay), puts us in the January timeframe for
> release candidates for 1.4.0.  I think that's preferable than to try to
> do anything during December.
>
> I've put the following dates in the calendar:
>
> January 8, 1.4.0rc1
> January 22, 1.4.0rc2
> February 5, 1.4.0final
>
> Does that make sense to everyone as a rough estimate?
>
> (On January 8, I will make a new maintenance branch for 1.4.x, so we
> won't need to "freeze" other work, but we may have a period where PRs
> will need to be manually merged from master into the maintenance branch
> as we put things together.)
>
> Mike
>
> --
>                     _
> |\/|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
>

[matplotlib-devel] 1.4.0 release schedule

[Michael D. <md...@st...>]

Looking approximately six months after when 1.3.0 was released 
(31-07-2013, after much delay), puts us in the January timeframe for 
release candidates for 1.4.0.  I think that's preferable than to try to 
do anything during December.

I've put the following dates in the calendar:

January 8, 1.4.0rc1
January 22, 1.4.0rc2
February 5, 1.4.0final

Does that make sense to everyone as a rough estimate?

(On January 8, I will make a new maintenance branch for 1.4.x, so we 
won't need to "freeze" other work, but we may have a period where PRs 
will need to be manually merged from master into the maintenance branch 
as we put things together.)

Mike

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

http://www.droettboom.com

Re: [matplotlib-devel] matplotlib 1.3.1

[Phil E. <pel...@gm...>]

Sounds good. I'll do what I can to close down some of the bugs too.

Now would also be a good time to announce a v1.4 date IMHO...


On 17 September 2013 22:54, Damon McDougall <dam...@gm...>wrote:

> On Tue, Sep 17, 2013 at 8:03 AM, Michael Droettboom <md...@st...>
> wrote:
> > I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1
> > release.  We have 6 blocker and 12 known bugs on that branch still.  I
> > hope to devote some time to triaging and closing as many of these as I
> > can this week, and then maybe tagging a 1.3.1 release candidate early
> > next week.  As this is a bugfix release, I'm not feeling extremely
> > strict about closing all known bugs tagged 1.3.x -- it's worth closing
> > those we can, but anything more complex can wait so as not to delay
> > getting out the mass of existing bugfixes already on the branch.
> >
> > Any thoughts?
> >
>
> I like it!
>
> > Mike
> >
> > --
> >                     _
> > |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> > |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
> >
> > http://www.droettboom.com
>
> --
> 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
>

Re: [matplotlib-devel] master macosx backend broken?

[Phil E. <pel...@gm...>]

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
>

Re: [matplotlib-devel] master macosx backend broken?

[Eric F. <ef...@ha...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Eric F. <ef...@ha...>]

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
>

Re: [matplotlib-devel] master macosx backend broken?

[Matt T. <mat...@gm...>]

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
>

Re: [matplotlib-devel] master macosx backend broken?

[Damon M. <dam...@gm...>]

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

Re: [matplotlib-devel] master macosx backend broken?

[Damon M. <dam...@gm...>]

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

Re: [matplotlib-devel] matplotlib 1.3.1

[Damon M. <dam...@gm...>]

On Tue, Sep 17, 2013 at 8:03 AM, Michael Droettboom <md...@st...> wrote:
> I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1
> release.  We have 6 blocker and 12 known bugs on that branch still.  I
> hope to devote some time to triaging and closing as many of these as I
> can this week, and then maybe tagging a 1.3.1 release candidate early
> next week.  As this is a bugfix release, I'm not feeling extremely
> strict about closing all known bugs tagged 1.3.x -- it's worth closing
> those we can, but anything more complex can wait so as not to delay
> getting out the mass of existing bugfixes already on the branch.
>
> Any thoughts?
>

I like it!

> Mike
>
> --
>                     _
> |\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
> |  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com

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

Re: [matplotlib-devel] matplotlib 1.3.1

[Eric F. <ef...@ha...>]

On 2013/09/17 3:03 AM, Michael Droettboom wrote:
> I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1
> release.  We have 6 blocker and 12 known bugs on that branch still.  I
> hope to devote some time to triaging and closing as many of these as I
> can this week, and then maybe tagging a 1.3.1 release candidate early
> next week.  As this is a bugfix release, I'm not feeling extremely
> strict about closing all known bugs tagged 1.3.x -- it's worth closing
> those we can, but anything more complex can wait so as not to delay
> getting out the mass of existing bugfixes already on the branch.
>
> Any thoughts?

Sounds good to me.

Eric

>
> Mike
>

[matplotlib-devel] master macosx backend broken?

[Eric F. <ef...@ha...>]

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

[matplotlib-devel] matplotlib 1.3.1

[Michael D. <md...@st...>]

I think there's enough good bug fixes on 1.3.x now to warrant a 1.3.1 
release.  We have 6 blocker and 12 known bugs on that branch still.  I 
hope to devote some time to triaging and closing as many of these as I 
can this week, and then maybe tagging a 1.3.1 release candidate early 
next week.  As this is a bugfix release, I'm not feeling extremely 
strict about closing all known bugs tagged 1.3.x -- it's worth closing 
those we can, but anything more complex can wait so as not to delay 
getting out the mass of existing bugfixes already on the branch.

Any thoughts?

Mike

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

http://www.droettboom.com

Re: [matplotlib-devel] Bug in 1.3.0: AttributeError: 'NavigationToolbar2TkAgg' object has no attribute 'draw_idle'

[Michael D. <md...@st...>]

Yes, it does appear that the fix needs to be on 1.3.x as well.  I'll 
cherry-pick it.

In the meantime, Lorenzo, you can manually include the fix here:

https://github.com/matplotlib/matplotlib/pull/2319

but this will make it into the 1.3.1 release.

Mike

On 09/17/2013 08:36 AM, Thomas A Caswell wrote:
> This is addressed on the master branch via #2319, but the commit where 
> the problem was introduced is not included in 1.3.0, so I am not sure 
> what is going on.
>
> Although, it does look like the fix should be cherry picked to the 
> 1.3.x branch.
>
>
> On Tue, Sep 17, 2013 at 7:02 AM, Lorenzo Di Gregorio 
> <lor...@gm... <mailto:lor...@gm...>> 
> wrote:
>
>     Hi,
>
>     I've just installed matplotlib 1.3.0 and run into the following
>     error when using the "home" button of a figure():
>
>     Exception in Tkinter callback
>     Traceback (most recent call last):
>       File "C:\Python27\lib\lib-tk\Tkinter.py", line 1410, in __call__
>         return self.func(*args)
>       File
>     "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
>     2745, in home
>         self._update_view()
>       File
>     "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
>     3149, in _update_view
>         self.draw_idle()
>     AttributeError: 'NavigationToolbar2TkAgg' object has no attribute
>     'draw_idle'
>
>     In fact NavigationToolbar2, inherited by NavigationToolbas2TkAgg,
>     calls draw_idle(), in the update() method, but the definition of
>     draw_idle() is missing, so this seems to be a bug.
>
>     Best Regards,
>     Lorenzo
>
>     ------------------------------------------------------------------------------
>     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
>
>
>
>
> -- 
> Thomas A Caswell
> PhD Candidate University of Chicago
> Nagel and Gardel labs
> tca...@uc... <mailto:tca...@uc...>
> jfi.uchicago.edu/~tcaswell <http://jfi.uchicago.edu/%7Etcaswell>
> o: 773.702.7204
>
>
> ------------------------------------------------------------------------------
> 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

Re: [matplotlib-devel] Bug in 1.3.0: AttributeError: 'NavigationToolbar2TkAgg' object has no attribute 'draw_idle'

[Thomas A C. <tca...@uc...>]

This is addressed on the master branch via #2319, but the commit where the
problem was introduced is not included in 1.3.0, so I am not sure what is
going on.

Although, it does look like the fix should be cherry picked to the 1.3.x
branch.


On Tue, Sep 17, 2013 at 7:02 AM, Lorenzo Di Gregorio <
lor...@gm...> wrote:

> Hi,
>
> I've just installed matplotlib 1.3.0 and run into the following error when
> using the "home" button of a figure():
>
> Exception in Tkinter callback
> Traceback (most recent call last):
>   File "C:\Python27\lib\lib-tk\Tkinter.py", line 1410, in __call__
>     return self.func(*args)
>   File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
> 2745, in home
>     self._update_view()
>   File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
> 3149, in _update_view
>     self.draw_idle()
> AttributeError: 'NavigationToolbar2TkAgg' object has no attribute
> 'draw_idle'
>
> In fact NavigationToolbar2, inherited by NavigationToolbas2TkAgg, calls
> draw_idle(), in the update() method, but the definition of draw_idle() is
> missing, so this seems to be a bug.
>
> Best Regards,
> Lorenzo
>
>
> ------------------------------------------------------------------------------
> 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
>
>


-- 
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tca...@uc...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

[matplotlib-devel] Bug in 1.3.0: AttributeError: 'NavigationToolbar2TkAgg' object has no attribute 'draw_idle'

[Lorenzo Di G. <lor...@gm...>]

Hi,

I've just installed matplotlib 1.3.0 and run into the following error when
using the "home" button of a figure():

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python27\lib\lib-tk\Tkinter.py", line 1410, in __call__
    return self.func(*args)
  File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
2745, in home
    self._update_view()
  File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
3149, in _update_view
    self.draw_idle()
AttributeError: 'NavigationToolbar2TkAgg' object has no attribute
'draw_idle'

In fact NavigationToolbar2, inherited by NavigationToolbas2TkAgg, calls
draw_idle(), in the update() method, but the definition of draw_idle() is
missing, so this seems to be a bug.

Best Regards,
Lorenzo

Re: [matplotlib-devel] "cached" member of Text class appearing in docs

[Michael D. <md...@st...>]

Wow.  It definitely should be private, or at the very least excluded 
from the docs, through whatever mechanism Sphinx gives us.  I really 
hope no one is using that as a public API -- I think it's ok to just 
privatize this post haste without a deprecation period.

Mike

On 09/16/2013 12:39 PM, Benjamin Root wrote:
> While looking up some information, I came across this hideousness:
>
> http://matplotlib.org/api/artist_api.html?highlight=text#matplotlib.text.Text.cached
>
> Why is this member made public? I would have thought it should be 
> "private"?
>
>
> ------------------------------------------------------------------------------
> 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