matplotlib-devel Mailing List for matplotlib (Page 2)

Here are the questions I asked during the hangouts session (paraphrased):
-------------------------------------------------------------
Regarding continuous integration:
Has looked into OBS? (open build server, https://build.opensuse.org/) It
can be installed on a local machine or server, supports automatically
creating and deleting fresh images with each build, and supposedly works
with osX as well as Linux although I haven't tested it (it does need a Mac
OsX VM).
-------------------------------------------------------------
Regarding bug handling:
It might be possible to do something with this with Google Code-in (
https://developers.google.com/open-source/gci/), although I am not 100%
sure this would be acceptable there.
Another possibility would be to allow volunteer triagers who may not be
developers but can at least handle basic stuff like finding duplicates and
following up with the reporters of old bugs.
-------------------------------------------------------------
Regarding embedding:
Perhaps there could be a generic "figure" widget for each backend. The
widget would automatically handle all the backend-specific stuff necessary
to create a figure object and display it in the widget (including resizing
and such). It would provide access to the low-level backend-specific parts
to make it possible to subclass it or change the details of how it works.
The figure windows would have this widget as their central widget, and
would probably access it using these low-level components.
However, for basic usage each widget would also have a "figure" attribute,
which would contain a single generic figure object. Basic users who just
want to embed a regular plot could access that figure object and use it in
the normal way.
These could probably all be accessed from a single module, although they
probably would all live in their own backend-specific modules.
It wouldn't allow people to use pyplot, but if this was the documented way
to do embedding and the documentation made it clear you needed to use the
OO interface when embedding I think it would greatly reduce the amount of
trouble people have.

Hi,
For the CI stuff, I think it would be worth discussing this with the
Enthought guys, specifically Didrik Pinte and David Cournapeau.
>From what I understood, they are developping some stuff to
automatically build canopy from projects hosted on github. Hence, they
have to run all the tests, on different plateforms, and they are OK
with chatting with some of us.
Cheers,
N
On 24 October 2013 17:29, Michael Droettboom <md...@st...> wrote:
> Here are the notes with action items from the meeting:
>
> https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing
>
> Sorry about not seeing questions posted from non-participants. I'll try
> to work out that kink for next time.
>
> Mike
>
> On 10/24/2013 09:41 AM, Michael Droettboom wrote:
>> Just a reminder, we are having a general matplotlib development hangout
>> today. Everyone that responded to the Doodle poll from a few weeks ago
>> will get an invite, along with Matthew Terry and Matthew Brett if they
>> can make it to discuss their work with testing and builds.
>>
>> We have a few extra spots, so let me know if you'd like an invite (first
>> come, first served).
>>
>> I'll post a public URL to watch along once it begins as well.
>>
>> Mike
>>
>
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Here are the notes with action items from the meeting:
https://docs.google.com/document/d/1nVM9qDooU5nX6WSKWPTYd2kN6wBxqOWZZTNOM1k0FdA/edit?usp=sharing
Sorry about not seeing questions posted from non-participants. I'll try 
to work out that kink for next time.
Mike
On 10/24/2013 09:41 AM, Michael Droettboom wrote:
> Just a reminder, we are having a general matplotlib development hangout
> today. Everyone that responded to the Doodle poll from a few weeks ago
> will get an invite, along with Matthew Terry and Matthew Brett if they
> can make it to discuss their work with testing and builds.
>
> We have a few extra spots, so let me know if you'd like an invite (first
> come, first served).
>
> I'll post a public URL to watch along once it begins as well.
>
> Mike
>
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Was anyone looking at the questions? I posted a bunch of questions but
nobody seemed to notice them.
On Thu, Oct 24, 2013 at 3:41 PM, Michael Droettboom <md...@st...> wrote:
> Just a reminder, we are having a general matplotlib development hangout
> today. Everyone that responded to the Doodle poll from a few weeks ago
> will get an invite, along with Matthew Terry and Matthew Brett if they
> can make it to discuss their work with testing and builds.
>
> We have a few extra spots, so let me know if you'd like an invite (first
> come, first served).
>
> I'll post a public URL to watch along once it begins as well.
>
> Mike
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Just a reminder, we are having a general matplotlib development hangout 
today. Everyone that responded to the Doodle poll from a few weeks ago 
will get an invite, along with Matthew Terry and Matthew Brett if they 
can make it to discuss their work with testing and builds.
We have a few extra spots, so let me know if you'd like an invite (first 
come, first served).
I'll post a public URL to watch along once it begins as well.
Mike
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Hi,
On Wed, Oct 23, 2013 at 12:37 PM, Chris Barker <chr...@no...> wrote:
> On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
>> The last ones I got from you worked very well: just a few test failures
>> and the current one seems to be doing about the same.
>
> worked well for me too (something odd with wx back end re-rendering,
> but I doubt that's a Mac build issue...)
>
> I tok a quick look at your waf scripts and I couldn't tell how you are
> handling the external compiled dependencies (png, zlib, freetype) --
> are these statically linked in?
Yup:
https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L20
through line 44 define the build rules for the libraries.
I then (this came from John H's make script I think) delete any shared
libraries:
https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183
and force mpl to link against these libraries first by setting
'basedir' in 'setup.cfg':
https://github.com/matthew-brett/mpl-osx-binaries/blob/master/wscript#L183
I should probably disable building the shared libraries as Matt T does
in his builds.
Cheers,
Matthew

On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
> The last ones I got from you worked very well: just a few test failures
> and the current one seems to be doing about the same.
worked well for me too (something odd with wx back end re-rendering,
but I doubt that's a Mac build issue...)
I tok a quick look at your waf scripts and I couldn't tell how you are
handling the external compiled dependencies (png, zlib, freetype) --
are these statically linked in?
It'll be good to see these posted on the MPL download site.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 10/23/2013 02:41 PM, Matthew Brett wrote:
> Hi,
>
> On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
>> In article
>> <CAH...@ma...>,
>> Matthew Brett <mat...@gm...>
>> wrote:
>>
>>> Hi Chris,
>>>
>>> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>>> <chr...@no...> wrote:
>>>> Are there recent binaries for OS-X anywhere? There don't seem to be
>>>> any for recent releases on the MPL download page.
>>>>
>>>> I know we had a discussion about this a whole back, but don't remember
>>>> the outcome. But I hope we'll continue to put them up-- macports and
>>>> friends really aren't the best solutions for everyone.
>>> I hope I have this cracked now, at least in principle.
>>>
>>> The latest versions are here:
>>>
>>> http://nipy.bic.berkeley.edu/scipy_installers/
>>>
>>> Following Matt Terry's example, I'm testing the builds and then the
>>> installers here:
>>>
>>> https://travis-ci.org/matthew-brett/mpl-osx-binaries
>> The last ones I got from you worked very well: just a few test failures
>> and the current one seems to be doing about the same.
>>
>> Thank you very much for providing these! I hope you will post them to
>> the matplotlib official site.
> I'd be happy to - I think I'm waiting for some agreement that that is
> OK. I suppose I don't have permission to do that at the moment.
Let's talk about this at tomorrow's meeting -- or offline if you can't 
make the meeting. Ideally, yes, these should be posted with the other 
files. We can sort out the required permissions etc. offlist.
>
>> One odd failure (in both of them) that I don't remember seeing before:
>> /2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485:
>> RuntimeWarning: invalid value encountered in arcsin
>> theta = np.arcsin(y / np.sqrt(2))
>>
>> There's a complaint about an invalid font name, but I've seen that for
>> quite some time:
>> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
>>
>> FAILED (KNOWNFAIL=2, SKIP=1, errors=2)
>>
>> One small suggestion: if it's not too much trouble, might you make them
>> .dmgs? It's a bit more convenient then having to unzip them to use them.
>> But if it's too much work don't bother; zipped mpkg are fine and it's
>> wonderful to have complete binary installers.
> Yes - sure - I'll build the DMGs - was just trying to save myself some
> effort while waiting for feedback - and - thanks for the feedback ...
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Hi,
On Wed, Oct 23, 2013 at 11:30 AM, Russell E. Owen <ro...@uw...> wrote:
> In article
> <CAH...@ma...>,
> Matthew Brett <mat...@gm...>
> wrote:
>
>> Hi Chris,
>>
>> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
>> <chr...@no...> wrote:
>> > Are there recent binaries for OS-X anywhere? There don't seem to be
>> > any for recent releases on the MPL download page.
>> >
>> > I know we had a discussion about this a whole back, but don't remember
>> > the outcome. But I hope we'll continue to put them up-- macports and
>> > friends really aren't the best solutions for everyone.
>>
>> I hope I have this cracked now, at least in principle.
>>
>> The latest versions are here:
>>
>> http://nipy.bic.berkeley.edu/scipy_installers/
>>
>> Following Matt Terry's example, I'm testing the builds and then the
>> installers here:
>>
>> https://travis-ci.org/matthew-brett/mpl-osx-binaries
>
> The last ones I got from you worked very well: just a few test failures
> and the current one seems to be doing about the same.
>
> Thank you very much for providing these! I hope you will post them to
> the matplotlib official site.
I'd be happy to - I think I'm waiting for some agreement that that is
OK. I suppose I don't have permission to do that at the moment.
> One odd failure (in both of them) that I don't remember seeing before:
> /2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485:
> RuntimeWarning: invalid value encountered in arcsin
> theta = np.arcsin(y / np.sqrt(2))
>
> There's a complaint about an invalid font name, but I've seen that for
> quite some time:
> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
>
> FAILED (KNOWNFAIL=2, SKIP=1, errors=2)
>
> One small suggestion: if it's not too much trouble, might you make them
> .dmgs? It's a bit more convenient then having to unzip them to use them.
> But if it's too much work don't bother; zipped mpkg are fine and it's
> wonderful to have complete binary installers.
Yes - sure - I'll build the DMGs - was just trying to save myself some
effort while waiting for feedback - and - thanks for the feedback ...
Cheers,
Matthew

In article 
<CAH...@ma...>,
 Matthew Brett <mat...@gm...> 
 wrote:
> Hi Chris,
> 
> On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
> <chr...@no...> wrote:
> > Are there recent binaries for OS-X anywhere? There don't seem to be
> > any for recent releases on the MPL download page.
> >
> > I know we had a discussion about this a whole back, but don't remember
> > the outcome. But I hope we'll continue to put them up-- macports and
> > friends really aren't the best solutions for everyone.
> 
> I hope I have this cracked now, at least in principle.
> 
> The latest versions are here:
> 
> http://nipy.bic.berkeley.edu/scipy_installers/
> 
> Following Matt Terry's example, I'm testing the builds and then the
> installers here:
> 
> https://travis-ci.org/matthew-brett/mpl-osx-binaries
The last ones I got from you worked very well: just a few test failures 
and the current one seems to be doing about the same.
Thank you very much for providing these! I hope you will post them to 
the matplotlib official site.
One odd failure (in both of them) that I don't remember seeing before:
/2.7/lib/python2.7/site-packages/matplotlib/projections/geo.py:485: 
RuntimeWarning: invalid value encountered in arcsin
 theta = np.arcsin(y / np.sqrt(2))
There's a complaint about an invalid font name, but I've seen that for 
quite some time:
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
FAILED (KNOWNFAIL=2, SKIP=1, errors=2)
One small suggestion: if it's not too much trouble, might you make them 
.dmgs? It's a bit more convenient then having to unzip them to use them. 
But if it's too much work don't bother; zipped mpkg are fine and it's 
wonderful to have complete binary installers.
-- Russell

On 10/23/2013 09:51 AM, Neal Becker wrote:
> Benjamin Root wrote:
>
>> Can you provide a code example to reproduce this. I suspect that recent
>> work on path effects might be to blame here. Also, exactly which version of
>> matplotlib and numpy were you using? The assert was placed there about a
>> year ago IIRC to deal with a short-lived numpy bug.
> The code is large and reads a bunch of data to plot.
>
>
> The line that triggers the error says:
>
> self.pdf.savefig (self.fig)
>
> Would it be useful to provide a pickled fig (umm,,, pickled figs)
No, we really need a self-contained example that triggers it. We 
already have a self-contained example that works (multipage_pdf.py in 
the examples)... So there's something extra that's happening in your 
context. Maybe start with multipage_pdf.py and add things from your own 
app until it breaks?
Mike
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

OK, this seems to be a pip caching bug. After rm -rf /tmp/pip*, it installed 
correctly
Neal Becker wrote:
> This is really strange. It d/l 1.3.1, but then builds installs 1.3.0???
> 
> python3-pip install --user --up --no-deps matplotlib
> Downloading/unpacking matplotlib from
> 
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.1/matplotlib-1.3.1.tar.gz
> Running setup.py egg_info for package matplotlib
> 
============================================================================
> Edit setup.cfg to change the build options
> 
> BUILDING MATPLOTLIB
> matplotlib: yes [1.3.0]
> python: yes [3.3.2 (default, Aug 23 2013, 19:00:04) [GCC
> 4.8.1 20130603 (Red Hat 4.8.1-1)]]
> platform: yes [linux]
> 
> REQUIRED DEPENDENCIES AND EXTENSIONS
> numpy: yes [version 1.7.1]
> dateutil: yes [using dateutil version 2.1]
> tornado: yes [using tornado version 3.1.1]
> pyparsing: yes [using pyparsing version 2.0.1]
> pycxx: yes [Official versions of PyCXX are not compatible
> with Python 3.x. Using local copy]
> libagg: yes [Requires patches that have not been merged
> upstream. Using local copy.]
> freetype: yes [version 16.0.10]
> png: yes [version 1.5.13]
> 
> OPTIONAL SUBPACKAGES
> sample_data: yes [installing]
> toolkits: yes [installing]
> tests: yes [using nose version 1.3.0]
> 
> OPTIONAL BACKEND EXTENSIONS
> macosx: no [Mac OS-X only]
> qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
> gtk3agg: no [gtk3agg backend does not work on Python 3]
> gtk3cairo: no [Requires pygobject to be installed.]
> gtkagg: no [Requires pygtk]
> tkagg: no [The C/C++ header for Tk (tk.h) could not be
> found. You may need to install the development
> package.]
> wxagg: no [requires wxPython]
> gtk: no [Requires pygtk]
> agg: yes [installing]
> cairo: yes [version 1.10.0]
> windowing: no [Microsoft Windows only]
> 
> OPTIONAL LATEX DEPENDENCIES
> dvipng: yes [version 1.14]
> ghostscript: yes [version 9.10]
> latex: yes [version 3.1415926]
> pdftops: yes [version 0.22.1]
> 
> 
> Installing collected packages: matplotlib
> Found existing installation: matplotlib 1.3.0
> Uninstalling matplotlib:
> Successfully uninstalled matplotlib
> Running setup.py install for matplotlib
> 
============================================================================
> Edit setup.cfg to change the build options
> 
> BUILDING MATPLOTLIB
> matplotlib: yes [1.3.0]
> python: yes [3.3.2 (default, Aug 23 2013, 19:00:04) [GCC
> 4.8.1 20130603 (Red Hat 4.8.1-1)]]
> platform: yes [linux]
> 
> REQUIRED DEPENDENCIES AND EXTENSIONS
> numpy: yes [version 1.7.1]
> dateutil: yes [using dateutil version 2.1]
> tornado: yes [using tornado version 3.1.1]
> pyparsing: yes [using pyparsing version 2.0.1]
> pycxx: yes [Official versions of PyCXX are not compatible
> with Python 3.x. Using local copy]
> libagg: yes [Requires patches that have not been merged
> upstream. Using local copy.]
> freetype: yes [version 16.0.10]
> png: yes [version 1.5.13]
> 
> OPTIONAL SUBPACKAGES
> sample_data: yes [installing]
> toolkits: yes [installing]
> tests: yes [using nose version 1.3.0]
> 
> OPTIONAL BACKEND EXTENSIONS
> macosx: no [Mac OS-X only]
> qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
> gtk3agg: no [gtk3agg backend does not work on Python 3]
> gtk3cairo: no [Requires pygobject to be installed.]
> gtkagg: no [Requires pygtk]
> tkagg: no [The C/C++ header for Tk (tk.h) could not be
> found. You may need to install the development
> package.]
> wxagg: no [requires wxPython]
> gtk: no [Requires pygtk]
> agg: yes [installing]
> cairo: yes [version 1.10.0]
> windowing: no [Microsoft Windows only]
> 
> OPTIONAL LATEX DEPENDENCIES
> dvipng: yes [version 1.14]
> ghostscript: yes [version 9.10]
> latex: yes [version 3.1415926]
> pdftops: yes [version 0.22.1]
> 
> Skipping installation of /home/nbecker/.local/lib/python3.3/site-
> packages/mpl_toolkits/__init__.py (namespace package)
> 
> Installing /home/nbecker/.local/lib/python3.3/site-
> packages/matplotlib-1.3.0-py3.3-nspkg.pth
> Successfully installed matplotlib
> Cleaning up...
> [
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

Benjamin Root wrote:
> Can you provide a code example to reproduce this. I suspect that recent
> work on path effects might be to blame here. Also, exactly which version of
> matplotlib and numpy were you using? The assert was placed there about a
> year ago IIRC to deal with a short-lived numpy bug.
The code is large and reads a bunch of data to plot.
The line that triggers the error says:
 self.pdf.savefig (self.fig)
Would it be useful to provide a pickled fig (umm,,, pickled figs)

This is really strange. It d/l 1.3.1, but then builds installs 1.3.0???
python3-pip install --user --up --no-deps matplotlib
Downloading/unpacking matplotlib from 
https://downloads.sourceforge.net/project/matplotlib/matplotlib/matplotlib-1.3.1/matplotlib-1.3.1.tar.gz
 Running setup.py egg_info for package matplotlib
 ============================================================================
 Edit setup.cfg to change the build options
 
 BUILDING MATPLOTLIB
 matplotlib: yes [1.3.0]
 python: yes [3.3.2 (default, Aug 23 2013, 19:00:04) [GCC
 4.8.1 20130603 (Red Hat 4.8.1-1)]]
 platform: yes [linux]
 
 REQUIRED DEPENDENCIES AND EXTENSIONS
 numpy: yes [version 1.7.1]
 dateutil: yes [using dateutil version 2.1]
 tornado: yes [using tornado version 3.1.1]
 pyparsing: yes [using pyparsing version 2.0.1]
 pycxx: yes [Official versions of PyCXX are not compatible
 with Python 3.x. Using local copy]
 libagg: yes [Requires patches that have not been merged
 upstream. Using local copy.]
 freetype: yes [version 16.0.10]
 png: yes [version 1.5.13]
 
 OPTIONAL SUBPACKAGES
 sample_data: yes [installing]
 toolkits: yes [installing]
 tests: yes [using nose version 1.3.0]
 
 OPTIONAL BACKEND EXTENSIONS
 macosx: no [Mac OS-X only]
 qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
 gtk3agg: no [gtk3agg backend does not work on Python 3]
 gtk3cairo: no [Requires pygobject to be installed.]
 gtkagg: no [Requires pygtk]
 tkagg: no [The C/C++ header for Tk (tk.h) could not be
 found. You may need to install the development
 package.]
 wxagg: no [requires wxPython]
 gtk: no [Requires pygtk]
 agg: yes [installing]
 cairo: yes [version 1.10.0]
 windowing: no [Microsoft Windows only]
 
 OPTIONAL LATEX DEPENDENCIES
 dvipng: yes [version 1.14]
 ghostscript: yes [version 9.10]
 latex: yes [version 3.1415926]
 pdftops: yes [version 0.22.1]
 
 
Installing collected packages: matplotlib
 Found existing installation: matplotlib 1.3.0
 Uninstalling matplotlib:
 Successfully uninstalled matplotlib
 Running setup.py install for matplotlib
 ============================================================================
 Edit setup.cfg to change the build options
 
 BUILDING MATPLOTLIB
 matplotlib: yes [1.3.0]
 python: yes [3.3.2 (default, Aug 23 2013, 19:00:04) [GCC
 4.8.1 20130603 (Red Hat 4.8.1-1)]]
 platform: yes [linux]
 
 REQUIRED DEPENDENCIES AND EXTENSIONS
 numpy: yes [version 1.7.1]
 dateutil: yes [using dateutil version 2.1]
 tornado: yes [using tornado version 3.1.1]
 pyparsing: yes [using pyparsing version 2.0.1]
 pycxx: yes [Official versions of PyCXX are not compatible
 with Python 3.x. Using local copy]
 libagg: yes [Requires patches that have not been merged
 upstream. Using local copy.]
 freetype: yes [version 16.0.10]
 png: yes [version 1.5.13]
 
 OPTIONAL SUBPACKAGES
 sample_data: yes [installing]
 toolkits: yes [installing]
 tests: yes [using nose version 1.3.0]
 
 OPTIONAL BACKEND EXTENSIONS
 macosx: no [Mac OS-X only]
 qt4agg: yes [Qt: 4.8.4, PyQt4: 4.10.1]
 gtk3agg: no [gtk3agg backend does not work on Python 3]
 gtk3cairo: no [Requires pygobject to be installed.]
 gtkagg: no [Requires pygtk]
 tkagg: no [The C/C++ header for Tk (tk.h) could not be
 found. You may need to install the development
 package.]
 wxagg: no [requires wxPython]
 gtk: no [Requires pygtk]
 agg: yes [installing]
 cairo: yes [version 1.10.0]
 windowing: no [Microsoft Windows only]
 
 OPTIONAL LATEX DEPENDENCIES
 dvipng: yes [version 1.14]
 ghostscript: yes [version 9.10]
 latex: yes [version 3.1415926]
 pdftops: yes [version 0.22.1]
 
 Skipping installation of /home/nbecker/.local/lib/python3.3/site-
packages/mpl_toolkits/__init__.py (namespace package)
 
 Installing /home/nbecker/.local/lib/python3.3/site-
packages/matplotlib-1.3.0-py3.3-nspkg.pth
Successfully installed matplotlib
Cleaning up...
[

Can you provide a standalone example to reproduce? The multipage_pdf.py 
example works fine with xkcd switched on.
Mike
On 10/23/2013 08:01 AM, Neal Becker wrote:
> This was using pdfpages (if that matters)
>
> Traceback (most recent call last):
> File "./plot_stuff2.py", line 326, in <module>
> the_plot.finish (args, opt, time, res)
> File "./plot_stuff2.py", line 145, in finish
> self.pdf.savefig (self.fig)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_pdf.py", line 2297, in savefig
> figure.savefig(self, format='pdf', **kwargs)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py",
> line 1421, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backend_bases.py", line 2220, in print_figure
> **kwargs)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_pdf.py", line 2340, in print_pdf
> self.figure.draw(renderer)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py",
> line 1034, in draw
> func(*args)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py",
> line 54, in draw_wrapper
> draw(artist, renderer, *args, **kwargs)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/text.py",
> line 589, in draw
> self._fontproperties, angle)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/patheffects.py", line 102, in draw_text
> self._draw_text_as_path(renderer, gc, x, y, s, prop, angle, ismath)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/patheffects.py", line 112, in _draw_text_as_path
> ismath)
> File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backend_bases.py", line 526, in _get_text_path_transform
> path = Path(verts, codes)
> File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/path.py",
> line 147, in __init__
> assert vertices.ndim == 2
> AssertionError
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Can you provide a code example to reproduce this. I suspect that recent
work on path effects might be to blame here. Also, exactly which version of
matplotlib and numpy were you using? The assert was placed there about a
year ago IIRC to deal with a short-lived numpy bug.

This isn't a matplotlib bug. Somehow, a py2.x version of nose got into your
python3.3 site-packages. Try clearing that out first. Of course, it might
still be possible that we are somehow forcing the wrong nose to be
installed...

This was using pdfpages (if that matters)
Traceback (most recent call last):
 File "./plot_stuff2.py", line 326, in <module>
 the_plot.finish (args, opt, time, res)
 File "./plot_stuff2.py", line 145, in finish
 self.pdf.savefig (self.fig)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backends/backend_pdf.py", line 2297, in savefig
 figure.savefig(self, format='pdf', **kwargs)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py", 
line 1421, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backend_bases.py", line 2220, in print_figure
 **kwargs)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backends/backend_pdf.py", line 2340, in print_pdf
 self.figure.draw(renderer)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py", 
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/figure.py", 
line 1034, in draw
 func(*args)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/artist.py", 
line 54, in draw_wrapper
 draw(artist, renderer, *args, **kwargs)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/text.py", 
line 589, in draw
 self._fontproperties, angle)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/patheffects.py", line 102, in draw_text
 self._draw_text_as_path(renderer, gc, x, y, s, prop, angle, ismath)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/patheffects.py", line 112, in _draw_text_as_path
 ismath)
 File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backend_bases.py", line 526, in _get_text_path_transform
 path = Path(verts, codes)
 File "/home/nbecker/.local/lib/python2.7/site-packages/matplotlib/path.py", 
line 147, in __init__
 assert vertices.ndim == 2
AssertionError

pip install of mpl 1.3.1 has issues.
It wants to install nose, but seems to be incompatible with py3.3:
 Running setup.py install for nose
 File "/home/nbecker/.local/lib/python3.3/site-
packages/nose/plugins/base.py", line 70
 except OptionConflictError, e:
 ^
 SyntaxError: invalid syntax
 
 File "/home/nbecker/.local/lib/python3.3/site-
packages/nose/plugins/multiprocess.py", line 481
 except (KeyboardInterrupt, SystemExit), e:
 ^
 SyntaxError: invalid syntax
 

Hello everybody
Its been a couple of weeks an I was wondering if anybody has feedback for me.
https://github.com/matplotlib/matplotlib/pull/2465
I changed the description on the PR to be more precise.
At the begining I called it tabbed gtk3 figuremanager but it is more a
multi-figure-manager with the first implementation in gtk3.
Thanks
Federico
-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
-- Antonio Alducin --

Hi Chris,
On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
<chr...@no...> wrote:
> Are there recent binaries for OS-X anywhere? There don't seem to be
> any for recent releases on the MPL download page.
>
> I know we had a discussion about this a whole back, but don't remember
> the outcome. But I hope we'll continue to put them up-- macports and
> friends really aren't the best solutions for everyone.
I hope I have this cracked now, at least in principle.
The latest versions are here:
http://nipy.bic.berkeley.edu/scipy_installers/
Following Matt Terry's example, I'm testing the builds and then the
installers here:
https://travis-ci.org/matthew-brett/mpl-osx-binaries
It would be great if you could give them a try.
Cheers,
Matthew

On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig <pie...@cr...>wrote:
> Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pie...@cr...
> > wrote:
>
> 1) is the terminology "phase" vs. "angle" spectrum standardized ? I
>> must
>> say I've never heard of one meaning "wrapped" and the other "unwrapped".
>> I didn't find similar terms in Matlab docs, but I didn't search that
>> thoroughly.
>>
>
> The "angle" function in numpy returns the wrapped angle, while the
> "unwrap" function documentation talks about phase, so it is consistent with
> the usage in numpy. Further, in signal processing, phases can have any
> value, while "angle" often refers to the angle between two lines, which
> must be wrapped.
>
> There may be some ambiguity, but I made sure to explain it in the
> documentation and provide links between the two functions so people know
> what they should do if they want to use the other approach.
>
>
>> 2) Should there be two separate functions for these two, or just one
>> function, with a switch argument `unwrap` ? (I guess it would be True by
>> default)
>>
>
> I originally was going to do that, but decided against it. The problem
> is with specgram. Here, I thought it would be needlessly complicated to
> add an "unwrap" parameter that is only useful for one "mode". To make it
> obvious to users, I wanted to keep specgram as similar as possible to the
> other plot types, and that involved keeping the parameter.
>
> Further, this approach is simpler to code and easier to maintain. Having
> to deal with the "unwrap" parameter would have been more difficult to
> program. Dealing with both an "unwrap" parameter in some cases and a
> separate "mode" in others would have been even more complicated.
>
> Further, _spectral_helper and specgram already have a huge number of
> arguments. This way I was able to get away with just adding one new
> argument rather than two.
>
> Thanks for the feedback. I agree that your documentation does make clear
> the distinction between "phase" and "angle" and that it has a consistency.
> I just feel that this distinction does not exist "outside" ...
>
> But beyond this question of phase vs. angle, I must say I don't see that
> big a use case for phase/angle spectrums[*] (as opposed to magnitude which
> are much used).
>
I personally use phase and angle spectrums a huge amount. In signal
processing it is extremely important. It is a critical component in
acoustics. It is also used a lot to separate out signals that have been
mixed together. Knowing the phases of signals can also be very important
in certain optics applications and for radio signals and RADAR. Changes in
the phase spectrum over time (like you would get from a phase spectrogram)
is important for doppler analysis both with optical and acoustic signals.
Also, from an educational perspective, anyone taking a digital signal
processing course will need to produce magnitude/phase plots, probably both
with and without wrapping (since any decent digital signal processing
course will teach you about the pitfalls that occur due to phase
wrapping). So this will make matplotlib much more useful for such courses.
> Also, in many cases, "spectrum" is synonymous with spectral density, which
> implies "magnitude". In the end I wonder whether the notion of phase even
> makes sense for a spectrogram ?
>
Yes, particularly electrical engineering. But there are many other fields
where spectral density is rarely used, and where more "ordinary" magnitude
and phase plots are the norm, as I explained in the previous paragraphs.

Matthew Brett has an experimental installer that includes the Python 
dependencies:
http://matplotlib.1069221.n5.nabble.com/Any-progress-on-binary-installer-for-OSX-td42163.html
Once the remaining issues are ironed out, we'll definitely link to this 
from matplotlib.org/downloads.html
Mike
On 10/22/2013 12:03 PM, Chris Barker - NOAA Federal wrote:
> Are there recent binaries for OS-X anywhere? There don't seem to be
> any for recent releases on the MPL download page.
>
> I know we had a discussion about this a whole back, but don't remember
> the outcome. But I hope we'll continue to put them up-- macports and
> friends really aren't the best solutions for everyone.
>
> Chris
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

On Tue, Oct 22, 2013 at 5:41 PM, Pierre Haessig <pie...@cr...>wrote:
> Hi,
>
> Le 22/10/2013 12:31, Todd a écrit :
> > Currently, both axes.psd and axes.csd return the same thing as
> > mlab.psd and mlab.csd, namely the spectrum and frequency points. They
> > do NOT return the line object that was plotted. This is different
> > than specgram, which returns the AxesImage object that was plotted in
> > addition to the mlab.specgram return values.
> >
> > I think having access to the line object is important, so
> > axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum
> > do return the line object. I know this is inconsistent, but I think
> > it is very important and would strongly objefct to removing this.
> >
> > The question, then, is whether this would be a good opportunity to add
> > the line object to the returned values for axes.psd and axes.csd.
> > This would be an API break, but would be very easy to fix, and it may
> > be beneficial enough to warrant it. What does everyone think?
>
> I agree that it may be nice to have plt.psd/csd to return lines just
> like plt.plot for increased consistency. I guess that returning the
> values comes from Matlab style inspiration.
>
> Maybe breaking the API is too strong. In that case, adding a
> transitional keyword (for example `return_line=False`) to psd/csd may
> help introduce your new proposed behavior in a softer manner. What do
> you think ?
>
> Of course, for your new functions, there is no API breakage problem.
>
> best,
> Pierre
>
I considered that solution as well, but it seemed ugly. However, I think
having it available is important, so I will add it. The current behavior
can probably be deprecated at some point, allowing for a smoother
transition.

Hi,
Le 21/10/2013 15:58, Todd a écrit :
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig
> <pie...@cr... <mailto:pie...@cr...>> wrote:
>
> 1) is the terminology "phase" vs. "angle" spectrum standardized ?
> I must
> say I've never heard of one meaning "wrapped" and the other
> "unwrapped".
> I didn't find similar terms in Matlab docs, but I didn't search that
> thoroughly.
>
>
> The "angle" function in numpy returns the wrapped angle, while the
> "unwrap" function documentation talks about phase, so it is consistent
> with the usage in numpy. Further, in signal processing, phases can
> have any value, while "angle" often refers to the angle between two
> lines, which must be wrapped.
>
> There may be some ambiguity, but I made sure to explain it in the
> documentation and provide links between the two functions so people
> know what they should do if they want to use the other approach.
> 
>
> 2) Should there be two separate functions for these two, or just one
> function, with a switch argument `unwrap` ? (I guess it would be
> True by
> default)
>
>
> I originally was going to do that, but decided against it. The
> problem is with specgram. Here, I thought it would be needlessly
> complicated to add an "unwrap" parameter that is only useful for one
> "mode". To make it obvious to users, I wanted to keep specgram as
> similar as possible to the other plot types, and that involved keeping
> the parameter.
>
> Further, this approach is simpler to code and easier to maintain.
> Having to deal with the "unwrap" parameter would have been more
> difficult to program. Dealing with both an "unwrap" parameter in some
> cases and a separate "mode" in others would have been even more
> complicated.
>
> Further, _spectral_helper and specgram already have a huge number of
> arguments. This way I was able to get away with just adding one new
> argument rather than two.
>
Thanks for the feedback. I agree that your documentation does make clear
the distinction between "phase" and "angle" and that it has a
consistency. I just feel that this distinction does not exist "outside" ...
But beyond this question of phase vs. angle, I must say I don't see that
big a use case for phase/angle spectrums[*] (as opposed to magnitude
which are much used). Also, in many cases, "spectrum" is synonymous
with spectral density, which implies "magnitude". In the end I wonder
whether the notion of phase even makes sense for a spectrogram ?
That's the reason why I'm a bit skeptical with the many new "mode
switches" in the spec helper, along with the new phase/angle_* functions.
best,
Pierre
[*] On the other hand I do see a usecase of magnitude and phase for
plotting transfer functions (i.e. Bode diagrams). Those are not fft
based plots, so it's a different topic I guess. Bode/Nyquist/Black
diagrams could be nice to have.