matplotlib-devel Mailing List for matplotlib (Page 2)

On Wed, Jul 24, 2013 at 9:39 AM, Michael Droettboom <md...@st...> wrote:
> On 07/23/2013 03:33 PM, Benjamin Root wrote:
>
> Just checked out rc5 from git and did an install, and ran into a
> pyparsing version check issue.
>
>
> What was the issue? Is it that you had 2.0.1 which rc5 still considers to
> be incompatible with Python 2? I'd like to know specifically what happened
> in case there's a deeper issue.
>
>
>
It claimed I didn't meet the minimum pyparsing version needed when I tried
importing matplotlib after installing from source. However, importing
pyparsing on its own yielded a version slightly above the minimum (I forget
the actual numbers). I had also just came from an build of an older
version of matplotlib.
Ben

First, I should say out loud that I'm personally embarrassed by how long 
it's taken to go from release candidate to a final release in the 1.3.0 
cycle. For those that haven't been following along the hold ups have 
all been along the lines of showstoppers like "won't install on platform 
X", so not just an expectation of absolute perfection. We're still not 
100% of the way there, but I hope we're real close now.
Part of this is due to the change to setuptools/distribute, and part of 
this is due to procedural things not going as well as they should that 
I'd like some help fixing.
To start with setuptools: That brought a lot of changes and kinks that 
needed to be worked out, and I'm not surprised that it created a few new 
wrinkles. The question in my mind is whether those wrinkles were a 
one-off result of the transition to setuptools or that similar things 
will reappear in the future. There was the setuptools/distribute 
remerge that IMHO was handled and communicated badly upstream, where by 
following the explicit directions in the documentation we had a package 
that would no longer install. It was hard to find the magic incantation 
that would work everywhere, but we got there eventually. Then there was 
the issue with pyparsing's upgrade where there's now a non-contiguous 
range of version numbers that are compatible with Python 2.x (everything 
*but* 2.0.0). It's somewhat fortunate that these happened during the 
release candidate cycle so that we could address them quickly. The 
theme here? These are problems that get created outside of the control 
of the matplotlib team. All of this was brought about because including 
copies of our dependencies created its own set of headaches, and 
setuptools is the standard solution to that problem, so that `setup.py 
install` and tools like `pip` will install the dependencies 
automatically. However, in the bad old days, it was at least possible 
to ship with some things that worked together, unfortunately, those who 
wanted their dependencies external (primarily packagers) were left to 
fend for themselves. Even though I was the one who spearheaded the move 
to setuptools, I'm wondering whether we shouldn't examine backtracking 
on some of this for the 1.4.x release.
The second issue is more one of process. When I make a release 
candidate, I announce it here, and Cc all of the packagers of the major 
Linux distributions, as well as Christoph and Russell who put together 
packages for Windows and Mac respectively. Part of that delegation is 
because I don't have installations of all of those platforms, and part 
is to spread some of the workload. And most of the time it works really 
well -- a big thanks to everyone involved. However, this cycle there 
have been a small number of critical bugs discovered in the fifth 
release candidate that existed in the first release candidate, which 
doesn't give me a lot of confidence that final won't have critical bugs 
either. I think some of this will be ameliorated over time as we build 
out a more effective continuous integration infrastructure (see MEP19: 
we could really use some help on this one), but some of it may have to 
do with users being unwilling to test a release until it has the word 
"final" attached. How can we get more ordinary users (who may have even 
more unusual environments) involved? I also suspect some of it has to 
do with the timing in the summer which hits in the middle of vacations 
and conference travel for many. We can certainly avoid the summer 
months next time. But I don't think it's just about building more time 
into the schedule. Let me know if I'm doing something boneheaded ;)
Mike

Would you mind testing https://github.com/matplotlib/matplotlib/pull/2250
On 07/23/2013 11:16 PM, Michiel de Hoon wrote:
> I noticed that this release candidate will always skip the Mac OS X 
> backend,
> as the .check() method of BackendMacOSX in setupext.py returns None. 
> Adding
> return "darwin"
> or some other string solves the issue.
> Also, if I am not mistaken, the files under 
> lib/matplotlib/backends/Matplotlib.nib (as returned by the 
> get_package_data() method of BackendMacOSX in setupext.py) are needed 
> by the cocoaagg backend, not by the MacOSX backend.

Sorry. We could have handled that better. I think we will probably do 
this again in the future, so we'll have an opportunity to be more 
explicit about these things.
Mike
On 07/24/2013 08:37 AM, Phil Elson wrote:
> I'm not quite back to normality here after getting back from over a 
> month out of the office (Scipy'13 taking a chunk of that time) and 
> didn't manage to fill in the questionnaire. I guess it doesn't matter 
> too much that I didn't manage to fill it in (I know my own users, all 
> 250+ of them, pretty well after all), but I wonder whether there are 
> others in a similar situation who didn't get a final social nudge to 
> get on and fill in the questionnaire because time was running out. If 
> we do something similar in the future I suggest we publish a deadline 
> and push the social media streams hard up-until that final deadline, 
> just to get those final last minute-ers (like me). :-)
>
> Anyway, that aside, having quickly glanced at the results of the 
> survey, I'm really impressed at the quality of the data and how clear 
> some of the messages in there have come out (i.e. there are backends 
> which are clearly dead horses). More on that in a separate thread...
>
> Cheers (its good to be back)!
>
> Phil
>
>
>
> On 18 July 2013 14:33, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> I'm fine with that. I actually had the same idea yesterday. I don't
> think we'll get many more responses than we already have.
>
> I'll go ahead close the survey and then make an official
> announcement on
> the usual channels.
>
> Mike
>
> On 07/17/2013 06:12 PM, Paul Ivanov wrote:
> > Hey everyone,
> >
> > I hope this email finds you well. I got a request today from
> > someone wanting to look at the survey results. How do you feel
> > about just sharing the full document? We're at 580 responses
> > right now, and it's been really a slow trickle in last couple of
> > weeks after the initial splash. Or we could do another round on
> > twitter and G+ and say the survey will be closed at the end of
> > the month, and then release the results.
> >
> > Thoughts?
> >
> > best,
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Thanks, David. I'll let you know. I am also planning on coming in by 
Google Hangout on Thursday and possibly parts of Friday.
Mike
On 07/24/2013 09:10 AM, David P. Sanders wrote:
> Hi,
>
> Just wanted to say that I am currently at the IPython developers' 
> meeting in case, so I can act as a conduit in case anybody has any 
> suggestions / comments / bugs related to the matplotlib--IPython 
> interaction.
>
> David.
>
> -- 
> Dr. David P. Sanders
>
> Profesor Titular "A" / Associate Professor
> Departamento de Física, Facultad de Ciencias
> Universidad Nacional Autónoma de México (UNAM)
>
> dps...@ci... <mailto:dps...@ci...>
> http://sistemas.fciencias.unam.mx/~dsanders 
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
>
> Cubículo / office: #414, 4o. piso del Depto. de Física
> Tel.: +52 55 5622 4965
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 07/23/2013 03:33 PM, Benjamin Root wrote:
> Just checked out rc5 from git and did an install, and ran into a 
> pyparsing version check issue.
What was the issue? Is it that you had 2.0.1 which rc5 still considers 
to be incompatible with Python 2? I'd like to know specifically what 
happened in case there's a deeper issue.
> Turns out I completely forgot to do a "git clean -fxd". Doing that 
> fixed the problem.
Interesting. I guess this would depend on what version you were on 
before the switch to rc5. If 1.2.x, I'm not surprised (since pyparsing 
was included in the source tree then). If master, I'm not sure what the 
cause would be.
> When we officially announce this, perhaps it would be best to 
> mention that command? In addition, it would probably be a good idea 
> to include this tidbit into the INSTALL?
But that only applies to users of git (in which case this is very often 
an issue), and not users who download the tarball or package. I think it 
makes sense to add it to the developer docs, not the INSTALL docs.
Mike

Thanks. I will address these issues before final.
None of this is new -- we've gone through 5 release candidates over many 
weeks. Why is this just coming to light now?
Mike
On 07/23/2013 11:16 PM, Michiel de Hoon wrote:
> I noticed that this release candidate will always skip the Mac OS X 
> backend,
> as the .check() method of BackendMacOSX in setupext.py returns None. 
> Adding
> return "darwin"
> or some other string solves the issue.
> Also, if I am not mistaken, the files under 
> lib/matplotlib/backends/Matplotlib.nib (as returned by the 
> get_package_data() method of BackendMacOSX in setupext.py) are needed 
> by the cocoaagg backend, not by the MacOSX backend.
>
> Best,
> -Michiel.
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li... 
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hi,
Just wanted to say that I am currently at the IPython developers' meeting
in case, so I can act as a conduit in case anybody has any suggestions /
comments / bugs related to the matplotlib--IPython interaction.
David.
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

I'm not quite back to normality here after getting back from over a month
out of the office (Scipy'13 taking a chunk of that time) and didn't manage
to fill in the questionnaire. I guess it doesn't matter too much that I
didn't manage to fill it in (I know my own users, all 250+ of them, pretty
well after all), but I wonder whether there are others in a similar
situation who didn't get a final social nudge to get on and fill in the
questionnaire because time was running out. If we do something similar in
the future I suggest we publish a deadline and push the social media
streams hard up-until that final deadline, just to get those final last
minute-ers (like me). :-)
Anyway, that aside, having quickly glanced at the results of the survey,
I'm really impressed at the quality of the data and how clear some of the
messages in there have come out (i.e. there are backends which are clearly
dead horses). More on that in a separate thread...
Cheers (its good to be back)!
Phil
On 18 July 2013 14:33, Michael Droettboom <md...@st...> wrote:
> I'm fine with that. I actually had the same idea yesterday. I don't
> think we'll get many more responses than we already have.
>
> I'll go ahead close the survey and then make an official announcement on
> the usual channels.
>
> Mike
>
> On 07/17/2013 06:12 PM, Paul Ivanov wrote:
> > Hey everyone,
> >
> > I hope this email finds you well. I got a request today from
> > someone wanting to look at the survey results. How do you feel
> > about just sharing the full document? We're at 580 responses
> > right now, and it's been really a slow trickle in last couple of
> > weeks after the initial splash. Or we could do another round on
> > twitter and G+ and say the survey will be closed at the end of
> > the month, and then release the results.
> >
> > Thoughts?
> >
> > best,
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I noticed that this release candidate will always skip the Mac OS X backend,
as the .check() method of BackendMacOSX in setupext.py returns None. Adding
  return "darwin"
or some other string solves the issue.
Also, if I am not mistaken, the files under lib/matplotlib/backends/Matplotlib.nib (as returned by the get_package_data() method of BackendMacOSX in setupext.py) are needed by the cocoaagg backend, not by the MacOSX backend.
Best,
-Michiel.
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel 

Just checked out rc5 from git and did an install, and ran into a pyparsing
version check issue. Turns out I completely forgot to do a "git clean
-fxd". Doing that fixed the problem. When we officially announce this,
perhaps it would be best to mention that command? In addition, it would
probably be a good idea to include this tidbit into the INSTALL?
Cheers!
Ben Root

On Tue, Jul 23, 2013 at 12:18 PM, Bruno L. Amadio Caires <
br...@ft...> wrote:
> Hi
>
> I am trying install scipy on AIX 6.1 power7, I saw how to install here
> https://sourceforge.net/mailarchive/forum.php?thread_name=4EFB7DC6.6020805%40ucar.edu&forum_name=matplotlib-devel
>
> But I got this error:
> *
> **bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # xlC -ma
> -I/opt/freeware/include -DAIX_GENUINE_CPLUSCPLUS -Wl,-brtl
> -bI:/opt/freeware/lib/python2.6/config/python.exp -qcpluscmt -qmkshrobj
> build/temp.aix-6.1-2.6/src/agg_py_transforms.o
> build/temp.aix-6.1-2.6/src/_tkagg.o
> build/temp.aix-6.1-2.6/CXX/IndirectPythonInterface.o
> build/temp.aix-6.1-2.6/CXX/cxx_extensions.o
> build/temp.aix-6.1-2.6/CXX/cxxsupport.o
> build/temp.aix-6.1-2.6/CXX/cxxextensions.o -LI:/usr/lib/libtcl8.4.exp
> -LI:/usr/lib/libtk8.4.exp -L/usr/local/lib -L/usr/local/lib64
> -L/opt/freeware/lib -L/usr/local/lib -L/usr/local/lib64 -lm -lfreetype -lz
> -lm -o build/lib.aix-6.1-2.6/matplotlib/backends/_tkagg.so**
> **ld: 0711-224 WARNING: Duplicate symbol: guesses**
> **ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.**
> **ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateCommand**
> **ld: 0711-317 ERROR: Undefined symbol: .Tk_MainWindow**
> **ld: 0711-317 ERROR: Undefined symbol: .Tk_FindPhoto**
> **ld: 0711-317 ERROR: Undefined symbol: .Tk_PhotoBlank**
> **ld: 0711-317 ERROR: Undefined symbol: .Tk_PhotoPutBlock_NoComposite**
> **ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendResult**
>
> Some informations :
>
> bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # rpm -qa | grep
> tcl
> tcl-8.4.7-3
> tcl-8.5.13-1
> tcllib-1.11.1-1
> bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # rpm -qa | grep
> tk
> tk-8.4.7-3
> atk-1.12.3-2
> tkinter-2.6.7-1
> gtk2-2.10.6-4
> tk-8.5.13-1
>
> *
> *Please get back to me with solution, how can I get Matplotlib in AIX 6.1?
>
> tks
>
> *
>
So, all of the errors appear related to linking _tkagg.so to the various
tkinter and tcl libraries. I see that you have tcl-8.4.7 and tcl-8.5.13,
and it is the 8.4 version that the linker is picking up. Which version of
tcl do you have the development package for? Perhaps you have the 8.5
version of the dev packages, would would have newer symbols and the linker
then tries linking against the older library without those symbols? This is
completely a guess, though.
Cheers!
Ben Root

Hi
I am trying install scipy on AIX 6.1 power7, I saw how to install here 
https://sourceforge.net/mailarchive/forum.php?thread_name=4EFB7DC6.6020805%40ucar.edu&forum_name=matplotlib-devel
But I got this error:
/
//bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # xlC -ma 
-I/opt/freeware/include -DAIX_GENUINE_CPLUSCPLUS -Wl,-brtl 
-bI:/opt/freeware/lib/python2.6/config/python.exp -qcpluscmt -qmkshrobj 
build/temp.aix-6.1-2.6/src/agg_py_transforms.o 
build/temp.aix-6.1-2.6/src/_tkagg.o 
build/temp.aix-6.1-2.6/CXX/IndirectPythonInterface.o 
build/temp.aix-6.1-2.6/CXX/cxx_extensions.o 
build/temp.aix-6.1-2.6/CXX/cxxsupport.o 
build/temp.aix-6.1-2.6/CXX/cxxextensions.o -LI:/usr/lib/libtcl8.4.exp 
-LI:/usr/lib/libtk8.4.exp -L/usr/local/lib -L/usr/local/lib64 
-L/opt/freeware/lib -L/usr/local/lib -L/usr/local/lib64 -lm -lfreetype 
-lz -lm -o build/lib.aix-6.1-2.6/matplotlib/backends/_tkagg.so//
//ld: 0711-224 WARNING: Duplicate symbol: guesses//
//ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more 
information.//
//ld: 0711-317 ERROR: Undefined symbol: .Tcl_CreateCommand//
//ld: 0711-317 ERROR: Undefined symbol: .Tk_MainWindow//
//ld: 0711-317 ERROR: Undefined symbol: .Tk_FindPhoto//
//ld: 0711-317 ERROR: Undefined symbol: .Tk_PhotoBlank//
//ld: 0711-317 ERROR: Undefined symbol: .Tk_PhotoPutBlock_NoComposite//
//ld: 0711-317 ERROR: Undefined symbol: .Tcl_AppendResult//
Some informations :
bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # rpm -qa | grep tcl
tcl-8.4.7-3
tcl-8.5.13-1
tcllib-1.11.1-1
bruno@xcat01 /home/bruno/local/sources/matplotlib-1.2.0 # rpm -qa | grep tk
tk-8.4.7-3
atk-1.12.3-2
tkinter-2.6.7-1
gtk2-2.10.6-4
tk-8.5.13-1
/
/Please get back to me with solution, how can I get Matplotlib in AIX 6.1?
tks
/
-- 
Bruno L. Amadio Caires
Informática - FT
Universidade Estadual de Campinas
Fone:(19)2113-3470

On 07/22/2013 05:59 PM, Russell E. Owen wrote:
> In article <51E...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> At long last, I have a 1.3.0rc5 tagged. I really hope to the software
>> deities that this is the last rc before final.
>>
>> If you wouldn't mind creating and posting the binaries, I'll make an
>> announcment on matplotlib-users, give this a week and then put final out.
> I have uploaded a binary for MacOS X 10.6 and later.
>
>
> There were a few oddities this time around:
> - matplotlib now requires pyparsing. I don't remember that being a
> requirement before -- even for previous 1.3 candidates.
It's been a requirement for time immemorial, but only in 1.3.0 (all of 
the release candidates) has it become an external dependency. What error 
occurred that suggests something changed?
>
> - I had a lot of trouble with matplotlib complaining that dateutil was
> not present, even though it was in my site-packages. So I tried to
> reinstall it using pip install -U dateutil. Unfortunately pip has never
> heard of "dateutil". After some searching I realized the package name is
> actually "python-dateutil" (and not dateutils, which is a different
> package, alas). Even then, I had to install/upgrade it twice -- for some
> reason matplotlib couldn't find it at first. Very puzzling. I have no
> idea what was going on, but also didn't want to spend a lot of time
> trying to debug it.
Does `python setup.py install` (of matplotlib) not install it 
automatically? We are bearing all the pain of setuptools in order for 
that to happen, so if it's not, that's a real problem.
>
> - I get a few unit tests failures, including a slew of
> DeprecationWarnings about Operator '<<' that I don't remember seeing
> before. I have appended the test log.
That's probably related to pyparsing 2.0.1 (released just this week). 
I'd like to fix those warnings, but then we'd have to *require* 
pyparsing 2.0.1 (no earlier Python 2.x release of pyparsing includes an 
alternative syntax). I think pyparsing moved too quickly on this one, 
but I'm not sure what we can do about it. It does make me long for the 
days when we included our dependencies so we have some control over this 
stuff.
>
> - I first tried building on 10.8 and running on 10.6 (since that's much
> simpler for me). Unfortunately it doesn't work; on 10.6 it acts as if
> the unit tests themselves aren't part of the package. I have no idea
> why. I appended a log snippet showing the basic message, but I haven't
> looked into it further. This sounds worth spending some time tracking
> down.
That's a puzzler. I've seen that crop up on Travis erratically as well, 
but not consistently. It's not clear what's going on here -- will have 
to think on it.
Thanks for all of your work on this!
Mike
>
> -- Russell
>
>
> Log of unit tests, with a few \n inserted for readability.
> This is for a package built on 10.6 and running on 10.8.
>
> python -c "import matplotlib as m ; m.test(verbosity=1)"
> .........................................................
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/mathtext.py:2182: DeprecationWarning: Operator '<<' is
> deprecated, use '<<=' instead
> float_literal << Regex(r"[-+]?([0-9]+\.?[0-9]*|\.[0-9]+)")
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/mathtext.py:2183: DeprecationWarning: Operator '<<' is
> deprecated, use '<<=' instead
> int_literal << Regex("[-+]?[0-9]+")
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/mathtext.py:2185: DeprecationWarning: Operator '<<' is
> deprecated, use '<<=' instead
> lbrace << Literal('{').suppress()
> ...(and 40-odd more examples of the same that I omitted)...
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/mathtext.py:2319: DeprecationWarning: Operator '<<' is
> deprecated, use '<<=' instead
> main << (non_math + ZeroOrMore(math_string + non_math)) +
> StringEnd()
> .........................................................................
> .........................................................................
> ......................
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family
> ['sans-serif'] not found. Falling back to Helvetica
> (prop.get_family(), self.defaultFamily[fontext]))
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match
> :family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
> l:size=medium. Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match
> :family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
> l:size=24.0. Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match
> :family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
> l:size=large. Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
> UserWarning)
> F...kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
> Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
> EK.....K.................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .........................................................................
> .....................................
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/ma/core.py:777: RuntimeWarning: invalid value encountered in
> absolute
> return umath.absolute(a) * self.tolerance >= umath.absolute(b)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked
> element to nan.
> warnings.warn("Warning: converting a masked element to nan.")
> ...............
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family
> ['sans-serif'] not found. Falling back to Bitstream Vera Sans
> (prop.get_family(), self.defaultFamily[fontext]))
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=14.0.
> Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=bold:stretch=500:size=14.0.
> Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family
> ['sans serif'] not found. Falling back to Bitstream Vera Sans
> (prop.get_family(), self.defaultFamily[fontext]))
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match :family=Bitstream Vera
> Sans:style=italic:variant=normal:weight=750:stretch=500:size=14.0.
> Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=200:stretch=500:size=14.0.
> Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
> UserWarning)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not
> match :family=Bitstream Vera
> Sans:style=normal:variant=normal:weight=500:stretch=100:size=14.0.
> Returning
> /Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
> UserWarning)
> FF...........................
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/gridspec.py:298: UserWarning: This figure includes Axes
> that are not compatible with tight_layout, so its results might be
> incorrect.
> warnings.warn("This figure includes Axes that are not "
> ............................................
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/numpy/testing/utils.py:807: RuntimeWarning: invalid value
> encountered in absolute
> z = abs(x-y)
> ........
> ======================================================================
> ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
> result = func(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 146, in test_pathclip
> plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/pyplot.py", line 561, in savefig
> return fig.savefig(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/figure.py", line 1421, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backend_bases.py", line 2220, in print_figure
> **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 865, in print_pdf
> self._print_pdf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 823, in _print_pdf_to_fh
> self.print_pgf(fname_pgf, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 805, in print_pgf
> self._print_pgf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 785, in _print_pgf_to_fh
> RendererPgf(self.figure, fh),
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
> self.latexManager = LatexManagerFactory.get_latex_manager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
> new_inst = LatexManager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
> raise LatexError("LaTeX returned an error, probably missing font or
> error in preamble:\n%s" % stdout)
> LatexError: LaTeX returned an error, probably missing font or error in
> preamble:
> This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
> restricted \write18 enabled.
> **entering extended mode
> LaTeX2e <2011年06月27日>
> Babel <v3.8m> and hyphenation patterns for english, dumylang,
> nohyphenation, ge
> rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek,
> ibycus, arabi
> c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian,
> czech, danis
> h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi,
> finnis
> h, french, friulan, galician, german, ngerman, swissgerman, monogreek,
> greek, h
> ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada,
> malayalam, ma
> rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish,
> italian,
> kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal,
> nynorsk,
> polish, portuguese, romanian, romansh, russian, sanskrit, serbian,
> serbianc, s
> lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian,
> uppersorbian,
> welsh, loaded.
>
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
> Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
> )
> (Please type a command or say `\end')
> *
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
> y)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
> ty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
> *************************************************
> * LaTeX warning: "xparse/redefine-command"
> *
> * Redefining document command \oldstylenums with arg. spec. 'm' on line
> 107.
> *************************************************
> )
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "Bitstream Vera Serif" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
> 
> <*> \setmainfont{Bitstream Vera Serif}
> 
> No pages of output.
> Transcript written on texput.log.
>
>
> ======================================================================
> ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
> result = func(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 158, in test_mixedmode
> compare_figure('pgf_mixedmode.pdf')
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/tests/test_backend_pgf.py", line 56, in compare_figure
> plt.savefig(actual)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/pyplot.py", line 561, in savefig
> return fig.savefig(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/figure.py", line 1421, in savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backend_bases.py", line 2220, in print_figure
> **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 865, in print_pdf
> self._print_pdf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 823, in _print_pdf_to_fh
> self.print_pgf(fname_pgf, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 805, in print_pgf
> self._print_pgf_to_fh(fh, *args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 785, in _print_pgf_to_fh
> RendererPgf(self.figure, fh),
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
> self.latexManager = LatexManagerFactory.get_latex_manager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
> new_inst = LatexManager()
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
> raise LatexError("LaTeX returned an error, probably missing font or
> error in preamble:\n%s" % stdout)
> LatexError: LaTeX returned an error, probably missing font or error in
> preamble:
> This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
> restricted \write18 enabled.
> **entering extended mode
> LaTeX2e <2011年06月27日>
> Babel <v3.8m> and hyphenation patterns for english, dumylang,
> nohyphenation, ge
> rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek,
> ibycus, arabi
> c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian,
> czech, danis
> h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi,
> finnis
> h, french, friulan, galician, german, ngerman, swissgerman, monogreek,
> greek, h
> ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada,
> malayalam, ma
> rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish,
> italian,
> kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal,
> nynorsk,
> polish, portuguese, romanian, romansh, russian, sanskrit, serbian,
> serbianc, s
> lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian,
> uppersorbian,
> welsh, loaded.
>
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
> Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
> )
> (Please type a command or say `\end')
> *
> *(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
> y)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
> ty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
> *************************************************
> * LaTeX warning: "xparse/redefine-command"
> *
> * Redefining document command \oldstylenums with arg. spec. 'm' on line
> 107.
> *************************************************
> )
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
> (/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
> (/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
> (/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
>
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !
> ! fontspec error: "font-not-found"
> !
> ! The font "Bitstream Vera Serif" cannot be found.
> !
> ! See the fontspec documentation for further information.
> !
> ! For immediate help type H <return>.
> !...............................................
> 
> <*> \setmainfont{Bitstream Vera Serif}
> 
> No pages of output.
> Transcript written on texput.log.
>
>
> ======================================================================
> FAIL: matplotlib.tests.test_backend_pdf.test_use14corefonts.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 40, in failer
> result = f(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 159, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /Users/rowen/result_images/test_backend_pdf/pdf_use14corefonts_pdf.png
> vs.
> /Users/rowen/result_images/test_backend_pdf/pdf_use14corefonts-expected_p
> df.png (RMS 49.430)
>
> ======================================================================
> FAIL: matplotlib.tests.test_text.test_font_styles.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 40, in failer
> result = f(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 159, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /Users/rowen/result_images/test_text/font_styles.png vs.
> /Users/rowen/result_images/test_text/font_styles-expected.png (RMS
> 13.676)
>
> ======================================================================
> FAIL: matplotlib.tests.test_text.test_font_styles.test
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 40, in failer
> result = f(*args, **kwargs)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/matplotlib/testing/decorators.py", line 159, in do_test
> '(RMS %(rms).3f)'%err)
> ImageComparisonFailure: images not close:
> /Users/rowen/result_images/test_text/font_styles_pdf.png vs.
> /Users/rowen/result_images/test_text/font_styles-expected_pdf.png (RMS
> 14.120)
>
> ----------------------------------------------------------------------
> Ran 1458 tests in 715.550s
>
> FAILED (KNOWNFAIL=2, errors=2, failures=3)
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
> ages/matplotlib/__init__.py:1141: UserWarning: This call to
> matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
>
> warnings.warn(_use_error_msg)
> localhost$
>
>
>
>
> ------------
>
> example of failure when building on 10.8 and running on 10.6:
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/loader.py", line 402, in loadTestsFromName
> module = resolve_name(addr.module)
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
> kages/nose/util.py", line 321, in resolve_name
> obj = getattr(obj, part)
> AttributeError: 'module' object has no attribute 'test_agg'
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

In article <51E...@st...>,
 Michael Droettboom <md...@st...> 
 wrote:
> At long last, I have a 1.3.0rc5 tagged. I really hope to the software 
> deities that this is the last rc before final.
> 
> If you wouldn't mind creating and posting the binaries, I'll make an 
> announcment on matplotlib-users, give this a week and then put final out.
I have uploaded a binary for MacOS X 10.6 and later.
There were a few oddities this time around:
- matplotlib now requires pyparsing. I don't remember that being a 
requirement before -- even for previous 1.3 candidates.
- I had a lot of trouble with matplotlib complaining that dateutil was 
not present, even though it was in my site-packages. So I tried to 
reinstall it using pip install -U dateutil. Unfortunately pip has never 
heard of "dateutil". After some searching I realized the package name is 
actually "python-dateutil" (and not dateutils, which is a different 
package, alas). Even then, I had to install/upgrade it twice -- for some 
reason matplotlib couldn't find it at first. Very puzzling. I have no 
idea what was going on, but also didn't want to spend a lot of time 
trying to debug it.
- I get a few unit tests failures, including a slew of 
DeprecationWarnings about Operator '<<' that I don't remember seeing 
before. I have appended the test log.
- I first tried building on 10.8 and running on 10.6 (since that's much 
simpler for me). Unfortunately it doesn't work; on 10.6 it acts as if 
the unit tests themselves aren't part of the package. I have no idea 
why. I appended a log snippet showing the basic message, but I haven't 
looked into it further. This sounds worth spending some time tracking 
down.
-- Russell
Log of unit tests, with a few \n inserted for readability.
This is for a package built on 10.6 and running on 10.8.
python -c "import matplotlib as m ; m.test(verbosity=1)"
.........................................................
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2182: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
 float_literal << Regex(r"[-+]?([0-9]+\.?[0-9]*|\.[0-9]+)")
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2183: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
 int_literal << Regex("[-+]?[0-9]+")
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2185: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
 lbrace << Literal('{').suppress()
...(and 40-odd more examples of the same that I omitted)...
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/mathtext.py:2319: DeprecationWarning: Operator '<<' is 
deprecated, use '<<=' instead
 main << (non_math + ZeroOrMore(math_string + non_math)) + 
StringEnd()
.........................................................................
.........................................................................
......................
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family 
['sans-serif'] not found. Falling back to Helvetica
 (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=medium. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=24.0. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match 
:family=Helvetica:style=normal:variant=normal:weight=normal:stretch=norma
l:size=large. Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/afm/putri8a.afm
 UserWarning)
F...kpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
Ekpathsea: Invalid fontname `Bitstream Vera Serif', contains ' '
EK.....K.................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.........................................................................
.....................................
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/ma/core.py:777: RuntimeWarning: invalid value encountered in 
absolute
 return umath.absolute(a) * self.tolerance >= umath.absolute(b)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/ma/core.py:3791: UserWarning: Warning: converting a masked 
element to nan.
 warnings.warn("Warning: converting a masked element to nan.")
...............
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family 
['sans-serif'] not found. Falling back to Bitstream Vera Sans
 (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=bold:stretch=500:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1236: UserWarning: findfont: Font family 
['sans serif'] not found. Falling back to Bitstream Vera Sans
 (prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match :family=Bitstream Vera 
Sans:style=italic:variant=normal:weight=750:stretch=500:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=200:stretch=500:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
 UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/font_manager.py:1246: UserWarning: findfont: Could not 
match :family=Bitstream Vera 
Sans:style=normal:variant=normal:weight=500:stretch=100:size=14.0. 
Returning 
/Applications/TUI.app/Contents/Resources/mpl-data/fonts/ttf/Vera.ttf
 UserWarning)
FF...........................
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/gridspec.py:298: UserWarning: This figure includes Axes 
that are not compatible with tight_layout, so its results might be 
incorrect.
 warnings.warn("This figure includes Axes that are not "
............................................
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/numpy/testing/utils.py:807: RuntimeWarning: invalid value 
encountered in absolute
 z = abs(x-y)
........
======================================================================
ERROR: matplotlib.tests.test_backend_pgf.test_pathclip
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
 result = func(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 146, in test_pathclip
 plt.savefig(os.path.join(result_dir, "pgf_pathclip.pdf"))
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1421, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
 **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 865, in print_pdf
 self._print_pdf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 823, in _print_pdf_to_fh
 self.print_pgf(fname_pgf, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 805, in print_pgf
 self._print_pgf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 785, in _print_pgf_to_fh
 RendererPgf(self.figure, fh),
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
 self.latexManager = LatexManagerFactory.get_latex_manager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
 new_inst = LatexManager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
 raise LatexError("LaTeX returned an error, probably missing font or 
error in preamble:\n%s" % stdout)
LatexError: LaTeX returned an error, probably missing font or error in 
preamble:
This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
 restricted \write18 enabled.
**entering extended mode
LaTeX2e <2011年06月27日>
Babel <v3.8m> and hyphenation patterns for english, dumylang, 
nohyphenation, ge
rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek, 
ibycus, arabi
c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, 
czech, danis
h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, 
finnis
h, french, friulan, galician, german, ngerman, swissgerman, monogreek, 
greek, h
ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada, 
malayalam, ma
rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish, 
italian, 
kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, 
nynorsk,
 polish, portuguese, romanian, romansh, russian, sanskrit, serbian, 
serbianc, s
lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian, 
uppersorbian, 
welsh, loaded.
*(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
)
(Please type a command or say `\end')
*
*(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
y)
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
ty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
*************************************************
* LaTeX warning: "xparse/redefine-command"
* 
* Redefining document command \oldstylenums with arg. spec. 'm' on line 
107.
*************************************************
) 
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! fontspec error: "font-not-found"
! 
! The font "Bitstream Vera Serif" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!............................................... 
 
<*> \setmainfont{Bitstream Vera Serif}
 
No pages of output.
Transcript written on texput.log.
======================================================================
ERROR: matplotlib.tests.test_backend_pgf.test_mixedmode
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 45, in backend_switcher
 result = func(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 158, in test_mixedmode
 compare_figure('pgf_mixedmode.pdf')
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/tests/test_backend_pgf.py", line 56, in compare_figure
 plt.savefig(actual)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/pyplot.py", line 561, in savefig
 return fig.savefig(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/figure.py", line 1421, in savefig
 self.canvas.print_figure(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backend_bases.py", line 2220, in print_figure
 **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 865, in print_pdf
 self._print_pdf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 823, in _print_pdf_to_fh
 self.print_pgf(fname_pgf, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 805, in print_pgf
 self._print_pgf_to_fh(fh, *args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 785, in _print_pgf_to_fh
 RendererPgf(self.figure, fh),
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 409, in __init__
 self.latexManager = LatexManagerFactory.get_latex_manager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 223, in get_latex_manager
 new_inst = LatexManager()
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/backends/backend_pgf.py", line 309, in __init__
 raise LatexError("LaTeX returned an error, probably missing font or 
error in preamble:\n%s" % stdout)
LatexError: LaTeX returned an error, probably missing font or error in 
preamble:
This is XeTeX, Version 3.1415926-2.4-0.9998 (TeX Live 2012)
 restricted \write18 enabled.
**entering extended mode
LaTeX2e <2011年06月27日>
Babel <v3.8m> and hyphenation patterns for english, dumylang, 
nohyphenation, ge
rman-x-2012年05月30日, ngerman-x-2012年05月30日, afrikaans, ancientgreek, 
ibycus, arabi
c, armenian, basque, bulgarian, catalan, pinyin, coptic, croatian, 
czech, danis
h, dutch, ukenglish, usenglishmax, esperanto, estonian, ethiopic, farsi, 
finnis
h, french, friulan, galician, german, ngerman, swissgerman, monogreek, 
greek, h
ungarian, icelandic, assamese, bengali, gujarati, hindi, kannada, 
malayalam, ma
rathi, oriya, panjabi, tamil, telugu, indonesian, interlingua, irish, 
italian, 
kurmanji, latin, latvian, lithuanian, mongolian, mongolianlmc, bokmal, 
nynorsk,
 polish, portuguese, romanian, romansh, russian, sanskrit, serbian, 
serbianc, s
lovak, slovenian, spanish, swedish, turkish, turkmen, ukrainian, 
uppersorbian, 
welsh, loaded.
*(/usr/local/texlive/2012/texmf-dist/tex/latex/base/minimal.cls
Document Class: minimal 2001年05月25日 Standard LaTeX minimal class
)
(Please type a command or say `\end')
*
*(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/expl3.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3names.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3bootstrap.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/etex-pkg/etex.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/color.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/color.cfg)
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xetex-def/xetex.def))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphics.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/trig.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/latexconfig/graphics.cfg))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3basics.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3expan.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3tl.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3seq.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3int.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3quark.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3clist.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3token.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3prop.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3msg.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3file.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3skip.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3keys.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3fp.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3box.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3coffins.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3color.sty)
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3kernel/l3luatex.sty))
(/usr/local/texlive/2012/texmf-dist/tex/latex/l3packages/xparse/xparse.st
y)
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-patches.s
ty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fixltx2e.sty)
*************************************************
* LaTeX warning: "xparse/redefine-command"
* 
* Redefining document command \oldstylenums with arg. spec. 'm' on line 
107.
*************************************************
) 
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/base/fontenc.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1enc.def)
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmr.fd))
(/usr/local/texlive/2012/texmf-dist/tex/xelatex/xunicode/xunicode.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/tipa/t3enc.def
(/usr/local/texlive/2012/texmf-dist/tex/latex/euenc/eu1lmss.fd))
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/graphicx.sty
(/usr/local/texlive/2012/texmf-dist/tex/latex/graphics/keyval.sty)))
(/usr/local/texlive/2012/texmf-dist/tex/latex/fontspec/fontspec.cfg)))
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!
! fontspec error: "font-not-found"
! 
! The font "Bitstream Vera Serif" cannot be found.
! 
! See the fontspec documentation for further information.
! 
! For immediate help type H <return>.
!............................................... 
 
<*> \setmainfont{Bitstream Vera Serif}
 
No pages of output.
Transcript written on texput.log.
======================================================================
FAIL: matplotlib.tests.test_backend_pdf.test_use14corefonts.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 40, in failer
 result = f(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 159, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: 
/Users/rowen/result_images/test_backend_pdf/pdf_use14corefonts_pdf.png 
vs. 
/Users/rowen/result_images/test_backend_pdf/pdf_use14corefonts-expected_p
df.png (RMS 49.430)
======================================================================
FAIL: matplotlib.tests.test_text.test_font_styles.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 40, in failer
 result = f(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 159, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: 
/Users/rowen/result_images/test_text/font_styles.png vs. 
/Users/rowen/result_images/test_text/font_styles-expected.png (RMS 
13.676)
======================================================================
FAIL: matplotlib.tests.test_text.test_font_styles.test
----------------------------------------------------------------------
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 40, in failer
 result = f(*args, **kwargs)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/matplotlib/testing/decorators.py", line 159, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: 
/Users/rowen/result_images/test_text/font_styles_pdf.png vs. 
/Users/rowen/result_images/test_text/font_styles-expected_pdf.png (RMS 
14.120)
----------------------------------------------------------------------
Ran 1458 tests in 715.550s
FAILED (KNOWNFAIL=2, errors=2, failures=3)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pack
ages/matplotlib/__init__.py:1141: UserWarning: This call to 
matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.
 warnings.warn(_use_error_msg)
localhost$ 
------------
example of failure when building on 10.8 and running on 10.6:
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/loader.py", line 402, in loadTestsFromName
 module = resolve_name(addr.module)
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-pac
kages/nose/util.py", line 321, in resolve_name
 obj = getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_agg'

On 07/22/2013 03:04 PM, Jouni K. Seppänen wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.python.matplotlib.devel as well.
>
> Michael Droettboom <mdr...@pu...> writes:
>
>> I've started a MEP related to improving our continuous integration
>> system for matplotlib.
>>
>> https://github.com/matplotlib/matplotlib/wiki/Mep19
>>
>> Rather than deal to much with implementation at this point, I thought
>> it best to start by outlining our requirements. At this point, let's
>> just get everything we'd like in, and we can worry about prioritizing
>> things later.
> Testing all pull requests means that sandboxing must be taken
> seriously. Imagine a pull request that sends spam via email or web
> forms, or reads the buildslave password and embeds it in the output.
> I suppose Travis must handle this somehow, but if we're going to roll
> our own, this may need serious thinking.
This should made explicit in the MEP, but I really hope not to our own. 
I'm a developer, not a sysadmin -- I don't have the skills or time to do 
this stuff effectively.
To address your question: both Travis and ShiningPanda (and I suspect 
other hosted testing services) fire up temporary virtual machines for 
each test run. By design, this virtual machine has no sensitive data on 
it, and thus none to steal in this way. ShiningPanda lets the virtual 
machine be customized upfront, and then cloned and thrown away on each 
test run, and is therefore a little more powerful IMHO.
>
> One thing I would like is to have results from all test cases in a
> format that allows them to be compared across the git history and the
> build environments, to discover things like "the text tests are failing
> with FreeType version X on Python version Y". There's an XUnit XML
> plugin for nose, and at least Jenkins has a reporting plugin that can
> read that format.
Indeed. Testing on a larger matrix of dependencies is something I'd 
like to do, and the results should be managable by human beings ;)
>
>> I would particularly like feedback from others who have set up similar
>> things. I have some experience with ShiningPanda (a service based on
>> Jenkins), and Travis. We used buildbot in the past, but I have little
>> direct experience with it. Are there other obvious candidates or
>> approaches?
> I've used buildbot at work, but with a much smaller range of build
> environments. It takes some work to configure but at least the
> configuration file is Python, and build steps can run pretty much any
> code. The waterfall display you get with the default settings isn't very
> much, but e.g. the Chromium project has a useful-looking setup:
>
> https://chromium-build.appspot.com/p/chromium/console
>
> Other options include at least CircleCI (a paid service), but I have no
> experience with it.
>
I will add CircleCI to the "to consider" list.
Mike

Michael Droettboom <md...@st...> writes:
> I've started a MEP related to improving our continuous integration
> system for matplotlib.
>
> https://github.com/matplotlib/matplotlib/wiki/Mep19
>
> Rather than deal to much with implementation at this point, I thought
> it best to start by outlining our requirements. At this point, let's
> just get everything we'd like in, and we can worry about prioritizing
> things later.
Testing all pull requests means that sandboxing must be taken
seriously. Imagine a pull request that sends spam via email or web
forms, or reads the buildslave password and embeds it in the output. 
I suppose Travis must handle this somehow, but if we're going to roll 
our own, this may need serious thinking.
One thing I would like is to have results from all test cases in a
format that allows them to be compared across the git history and the
build environments, to discover things like "the text tests are failing
with FreeType version X on Python version Y". There's an XUnit XML
plugin for nose, and at least Jenkins has a reporting plugin that can
read that format.
> I would particularly like feedback from others who have set up similar
> things. I have some experience with ShiningPanda (a service based on
> Jenkins), and Travis. We used buildbot in the past, but I have little
> direct experience with it. Are there other obvious candidates or
> approaches?
I've used buildbot at work, but with a much smaller range of build
environments. It takes some work to configure but at least the
configuration file is Python, and build steps can run pretty much any
code. The waterfall display you get with the default settings isn't very
much, but e.g. the Chromium project has a useful-looking setup:
https://chromium-build.appspot.com/p/chromium/console
Other options include at least CircleCI (a paid service), but I have no
experience with it.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 07/22/2013 01:05 PM, Jouni K. Seppänen wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.python.matplotlib.devel as well.
>
> Michael Droettboom <mdr...@pu...> writes:
>
>> I've drafted a MEP with a plan to improve some of the text and font
>> handling in matplotlib.
>>
>> I'd love any and all feedback.
>>
>> https://github.com/matplotlib/matplotlib/wiki/Mep14
> I'm a bit late to the party
Not too late -- the implementation has barely begun.
> , but here are a few thoughts:
>
> What I see as the biggest problem in the current font-selection system
> is its opaqueness. You can attempt to specify a style you'd like, but
> it's up to the backend to find the relevant font. The naive user has no
> way of knowing which font actually got selected, and no way of knowing
> how to modify the parameters to get what they want (except if they
> stumble upon the way to specify the full path to a font file). Each
> backend can override the font-selection code, so e.g. the ps backend
> has an option to use only "AFM fonts", meaning the core fonts built into
> PostScripts viewers.
Good point. I should add that in the MEP as an explicit example of 
another case where the font selection needs to be special-cased.
>
> The subsetting system proposed in MEP14 (reading the font via FreeType,
> then rendering or outputting the outlines into the result) would make
> backends consistent with each other, as long as the same text engine is
> used. Then at least the OO API could have font selection as an explicit
> step, i.e. instead of
>
> ax.text(x, y, s, family='serif', style='oblique')
>
> you could write
>
> font = text_engine.find_font(family='serif', style='oblique')
> ax.text(x, y, s, font=font)
>
> and also query the `font` object for what actual font is being used.
> (Or would it look more like ax.text(x, y, text_engine.layout(s, font))?)
>
> If we want to continue support for backend idiosyncracies like
> ps.use_afm, I suppose those would need to be parameters to the text
> engine.
My thinking was that there would just be engine-specific attributes on 
the font selector, e.g.:
font = FontProperties(family="serif", ps_family="Helvetica")
and then you can pass this into the regular text engine or the PS 
AFM-specific one and they would both know what to do.
But maybe that needs some more thinking. What I want to avoid is the 
current situation where things change radically when switching text 
engines because they *need* to handle fonts so differently. I'd rather 
make that more explicit -- because I don't think there's any way to make 
font selection work the same way across all of them. I think that's the 
assumption in the current design and it's not great. It works fine if 
you say "give me a sans serif font, I don't care which", but beyond 
that, the user needs domain-specific knowldege. Honestly, this is a 
part of the MEP that I think needs work -- I basically threw up my hands 
as a solution to the problem. Maybe there is a better way.
>
> ----
>
> The approach of subsetting fonts by writing a new Type-3 font in the
> PostScript or PDF file would allow supporting any fonts that FreeType
> can read, but this would lose hinting information in TTF and Type-1
> fonts. I think we should at least leave open the possibility to embed
> the original font (or a directly-derived subset).
Yes. But that's not a change from current behavior. We've had 
subsetting fonts as Type 3 fonts for *years* and no one has complained 
about the lack of hinting. And we do provide an option to embed the 
entire original font if necessary (and no reason to remove that). 
What's new in the MEP is that the subsetting would be based on the 
freetype API (and thus be able to read virtually any font as input), 
rather than ttconv (which can only read well-behaved TrueType fonts with 
Macintosh metadata). This will allow us to support Microsoft-specific 
TTF fonts (the ones that ship with Windows 7 and 8), OpenType fonts and 
Web fonts.
>
> ----
>
> The code that parses DVI files from TeX outputs not only glyphs but also
> boxes, which are black rectangles used to implement things like the
> underscore character and the varying-length part of the square-root
> sign. To support this, I guess TextSpan.get_chars should be able to
> return not only TextChar instances but also boxes.
>
Good point. We'll need that for the built-in mathtext renderer as well, 
for the same reason.
Mike

Michael Droettboom <md...@st...> writes:
> I've drafted a MEP with a plan to improve some of the text and font
> handling in matplotlib.
>
> I'd love any and all feedback.
>
> https://github.com/matplotlib/matplotlib/wiki/Mep14
I'm a bit late to the party, but here are a few thoughts:
What I see as the biggest problem in the current font-selection system
is its opaqueness. You can attempt to specify a style you'd like, but
it's up to the backend to find the relevant font. The naive user has no
way of knowing which font actually got selected, and no way of knowing
how to modify the parameters to get what they want (except if they
stumble upon the way to specify the full path to a font file). Each
backend can override the font-selection code, so e.g. the ps backend
has an option to use only "AFM fonts", meaning the core fonts built into
PostScripts viewers.
The subsetting system proposed in MEP14 (reading the font via FreeType,
then rendering or outputting the outlines into the result) would make
backends consistent with each other, as long as the same text engine is
used. Then at least the OO API could have font selection as an explicit
step, i.e. instead of 
 ax.text(x, y, s, family='serif', style='oblique')
you could write
 font = text_engine.find_font(family='serif', style='oblique')
 ax.text(x, y, s, font=font)
and also query the `font` object for what actual font is being used.
(Or would it look more like ax.text(x, y, text_engine.layout(s, font))?)
If we want to continue support for backend idiosyncracies like
ps.use_afm, I suppose those would need to be parameters to the text
engine.
 ----
The approach of subsetting fonts by writing a new Type-3 font in the
PostScript or PDF file would allow supporting any fonts that FreeType
can read, but this would lose hinting information in TTF and Type-1
fonts. I think we should at least leave open the possibility to embed
the original font (or a directly-derived subset).
 ----
The code that parses DVI files from TeX outputs not only glyphs but also
boxes, which are black rectangles used to implement things like the
underscore character and the varying-length part of the square-root
sign. To support this, I guess TextSpan.get_chars should be able to
return not only TextChar instances but also boxes.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

On 07/22/2013 11:34 AM, Chris Beaumont wrote:
> I had the same question about opt-out vs opt-in. Personally, I vote 
> for opt-out. I would like to see each release of MPL have an 
> associated style (which may be the same as the last release, but maybe 
> not). With Tony's style PR, users that need constant styles would 
> either put `style.use('1.3')` in their script, or `style: 1.3` in an 
> rcParams file. This would then freeze the style FOR-EV-ER (sandlot 
> voice). However, the default would be `style: latest`, so that the 
> default user benefits from the community's effort into making the best 
> possible set of defaults. Is that sufficiently pain-free for people 
> who want future proofing? Or do you think styles must be opt-in 
> (which, effectively, means that defaults cannot change).
In my experience, the vast majority of users don't read changelog notes, 
so we can't expect people to opt out of something that will change 
and/or break their existing plots. This is particularly a problem where 
matplotlib is upgraded by a sysadmin or distribution (about 58% percent 
of users, by our survey), because it doesn't even get upgraded on the 
user's timetable, necessarily. So I think any changes to the defaults 
have to be opt-in. However, we do have a policy of breaking things 
after a release cycle of deprecation warnings. So we can change the 
defaults in 1.5 after a round of warnings about them in 1.4 (if an 
explicit style is not set).
>
> I'm not sure if I understand what you're getting at re: 
> approximately_emulate.
I took Nathaniel's suggestion to just mean that default style should be 
selectable by a version number, so the user doesn't have to keep track 
of the mapping between a style set and a version of matplotlib.
> I'm in favor of two modes for style loading -- some kind of lazy 
> version that only touches the options explicitly addressed in the 
> file, and an explicit version that defaults all other options to 
> something. Thus, explicit loading would guarantee that a style never 
> changes.
>
Yes -- I agree there, too. "set_style" vs. "update_style" perhaps? 
("update" used for its similarity to dict.update?)
Mike

On Sun, Jul 21, 2013 at 2:48 AM, Chris Beaumont <bea...@ha...> wrote:
> I don't fully agree with Eric that changing the defaults should be treated
> as an API break -- yes, it may irritate a minority of users, but their code
> will still run. I'd flip around your argument for the role of rcParams and
> customization: the majority user is probably someone who doesn't know much
> about rcParams, or all the ways plots can be customized. *That* is the use
> case to optimize, not the "legacy" users invested in the current style.
As one small data point here, from a really excellent paper reviewing
the trade-offs in colormap design and deriving the "cool-warm"
colormap as a good default:
"This diverging color map interpolation has also been added to
ParaView, a free, open-source end-user scientific visualization
application, and was first featured in the 3.4 release in October
2008. Although ParaView does let users change the color map and there
is no way to track who does so, in our experience few users actually
do this. In the nearly 3000 messages on the ParaView users’ mailing
list from October 2008 to July 2009, there was no mention of the
change of color map from rainbow to cool-warm diverging. Users seem to
have accepted the change with little notice despite most users’
affinity for rainbow color maps."
- http://www.cs.unm.edu/~kmorel/documents/ColorMaps/ColorMapsExpanded.pdf
It absolutely should be easy to go back to the way things were, for
reproduction of old carefully hand-tweaked plots etc. But, there are
cases where our defaults are demonstrably terrible; and, these
defaults are demonstrably the direct cause of people producing
unnecessarily inferior plots; and, it's been many years now that this
situation has continued out and nothing has happened because we don't
want to be hasty. At some point we need to bite the bullet and make
these things better.
-n

I had the same question about opt-out vs opt-in. Personally, I vote for
opt-out. I would like to see each release of MPL have an associated style
(which may be the same as the last release, but maybe not). With Tony's
style PR, users that need constant styles would either put
`style.use('1.3')` in their script, or `style: 1.3` in an rcParams file.
This would then freeze the style FOR-EV-ER (sandlot voice). However, the
default would be `style: latest`, so that the default user benefits from
the community's effort into making the best possible set of defaults. Is
that sufficiently pain-free for people who want future proofing? Or do you
think styles must be opt-in (which, effectively, means that defaults cannot
change).
I'm not sure if I understand what you're getting at re:
approximately_emulate. I'm in favor of two modes for style loading -- some
kind of lazy version that only touches the options explicitly addressed in
the file, and an explicit version that defaults all other options to
something. Thus, explicit loading would guarantee that a style never
changes.
chris

On 07/22/2013 10:42 AM, Nathaniel Smith wrote:
> On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <md...@st...> wrote:
>> This is why I suggested that the best way forward is to implement some sort
>> of easy styling functionality (like what Tony Yu has submitted in #2236,
>> though I haven't had a chance to look at it yet), and make it explicit for
>> the user to select a new style. This could be either by adding a new line
>> to the top of the plotting script, or adding a single switch in the global
>> matplotlibrc file. But there needs to be an explicit turning on of this.
> Are you saying that the defaults can't change (i.e., any changes must
> be opt-in), or just that there needs to be some transition period
> before the defaults can change and a simple way to opt out afterwards?
> I agree with the latter :-).
I'm saying that there needs to be a transition period, and the start of 
that transition would be to require an explicit opt-in of the new defaults.
>
> I have mixed feelings about a full "styling system" though, since, how
> many coherent "styles" for plots are there? If we provide a menu of
> plot styles right in the main documentation then it seems like it
> would just end up being an excuse for people to procrastinate playing
> with the different settings, and increase the number of manuscripts I
> read that have baroque and poorly chosen colormaps, plots that use the
> "ggplot as drawn by xkcd" style, etc. And what value would it really
> add? IMO we have a responsibility to nudge users towards making good
> plots, and that means having good defaults, and perhaps also means
> encouraging people to use them instead of just picking things that
> optimize some vague aesthetic judgement at 2am before the submission
> deadline...
>
> How about
> mpl.approximately_emulate(<version number>)
> which sets the defaults to whatever version of matplotlib is named?
> That could be used a-priori by people who want to future-proof their
> scripts, is very easy to add after the fact if you upgrade matplotlib
> and discover some plot of yours has been broken, and also encompasses
> the "future" functionality (you could ask your current matplotlib to
> emulate the next version, if it knows how).
>
> The advantage of a limited API that just takes a version number is not
> just that it's simpler on the backend (no need for a system to name
> and discover styles, etc. etc.), but it can also easily encapsulate
> knowledge like "the defaults were the same from 0.99 through 1.2, so
> if anything in that range is requested use *this* file, but then in
> 1.3...". This means that if a user knows that their plot worked on 1.1
> but broke on 1.4, they don't have to care -- they can just say
> mpl.approximately_emulate("1.1")
> instead of having to somehow figure out that the right call is:
> mpl.style("0.99-through-1.2")
>
I like this version idea. (Not sure about the name 
"approximately_emulate", but that's a detail...) Other tools (sphinx, 
for example) have a way of declaring what version was used when 
something was created. If the user says:
matplotlib.styling_required('1.2')
then, if we're on 1.3, we do our best to load the styling defaults from 
1.2, and display a warning to the effect "this plot was written for 
matplotlib 1.2, we're running 1.3, so we're entering 1.2 compatibility 
mode, but some things still may be broken. See the changes 
documentation". (Again, we can work on the exact wording later).
I think this is a nice approach. I still think the ability to load 
arbitrary styles from files, online etc. is required, though. There's 
really two issues to resolve here: one is to make sharing of styles 
easier (to have an institutional or publication style, for example), the 
other is to transitition to better defaults with as little breakage and 
pain as possible. I think we need to do both.
Mike

On Mon, Jul 22, 2013 at 2:55 PM, Michael Droettboom <md...@st...> wrote:
> This is why I suggested that the best way forward is to implement some sort
> of easy styling functionality (like what Tony Yu has submitted in #2236,
> though I haven't had a chance to look at it yet), and make it explicit for
> the user to select a new style. This could be either by adding a new line
> to the top of the plotting script, or adding a single switch in the global
> matplotlibrc file. But there needs to be an explicit turning on of this.
Are you saying that the defaults can't change (i.e., any changes must
be opt-in), or just that there needs to be some transition period
before the defaults can change and a simple way to opt out afterwards?
I agree with the latter :-).
I have mixed feelings about a full "styling system" though, since, how
many coherent "styles" for plots are there? If we provide a menu of
plot styles right in the main documentation then it seems like it
would just end up being an excuse for people to procrastinate playing
with the different settings, and increase the number of manuscripts I
read that have baroque and poorly chosen colormaps, plots that use the
"ggplot as drawn by xkcd" style, etc. And what value would it really
add? IMO we have a responsibility to nudge users towards making good
plots, and that means having good defaults, and perhaps also means
encouraging people to use them instead of just picking things that
optimize some vague aesthetic judgement at 2am before the submission
deadline...
How about
 mpl.approximately_emulate(<version number>)
which sets the defaults to whatever version of matplotlib is named?
That could be used a-priori by people who want to future-proof their
scripts, is very easy to add after the fact if you upgrade matplotlib
and discover some plot of yours has been broken, and also encompasses
the "future" functionality (you could ask your current matplotlib to
emulate the next version, if it knows how).
The advantage of a limited API that just takes a version number is not
just that it's simpler on the backend (no need for a system to name
and discover styles, etc. etc.), but it can also easily encapsulate
knowledge like "the defaults were the same from 0.99 through 1.2, so
if anything in that range is requested use *this* file, but then in
1.3...". This means that if a user knows that their plot worked on 1.1
but broke on 1.4, they don't have to care -- they can just say
 mpl.approximately_emulate("1.1")
instead of having to somehow figure out that the right call is:
 mpl.style("0.99-through-1.2")
-n

Chris,
Thanks for outlining some of the issues with the defaults. I agree 
wholeheartedly and also agree that most of these are simple objective 
improvements, and have nothing to do with wishy-washy things like 
"aesthetics".
My objections to changing the defaults have nothing to do with the fact 
that it would be hard to find subjective improvements -- I agree a lot 
can be done that would be easy to get consensus on. Eric said it better 
than I could:
 inevitably there will be users who will be distressed when they
 upgrade and suddenly find that all their plots--perhaps generated
 automatically by their cron jobs or web apps--look very different,
 and perhaps don't even work well with the new defaults.
This is why I suggested that the best way forward is to implement some 
sort of easy styling functionality (like what Tony Yu has submitted in 
#2236, though I haven't had a chance to look at it yet), and make it 
explicit for the user to select a new style. This could be either by 
adding a new line to the top of the plotting script, or adding a single 
switch in the global matplotlibrc file. But there needs to be an 
explicit turning on of this. To the extent that some things can't be 
changed with rcParams, we can address those on a case-by-case basis.
Another thing that we could do would be to borrow from the "from 
__future__ import" concept in Python. Then users could say:
 style('future')
at the top of their script and see what it will look like in the default 
styling of the next version of matplotlib -- keeping the old defaults as 
default.
Mike
On 07/20/2013 05:47 PM, Chris Beaumont wrote:
> Hi,
>
> I thought I'd chime in on this discussion -- Adrian Price-Whelan and I 
> put together plotornot during the SciPy sprints.
>
> I wouldn't advocate for linking to plotornot from matplotlib -- the 
> idea is semi tongue-in-cheek, and meant to gauge to what extent there 
> is consensus about plot styles. It's not set up to teach about 
> rcParams, nor does it systematically explore all possible styles. The 
> votes (>10K, last I checked) are saved, and eventually Adrian or I 
> will look over the feedback and report back to you all. I haven't had 
> time for that yet. I hope the name didn't *actually* offend anyone.
>
> At the risk of sounding unappreciative of MPL (which I love, and rely 
> upon daily), I must admit I was disheartened after hearing the MPL 
> devs at SciPy discuss styles and defaults. I understand that you don't 
> want to change the default styles without a clearly better 
> alternative. I also understand that, to some extent, style preferences 
> are subjective. However, there seemed to be quite a bit of resistance 
> to the idea that MPL defaults should change *at all.*
>
> Even if you ignore the subjective component of this (which I think is 
> a mistake, since in my experience there is broad consensus that 
> projects like ggplot2, d3, tableau, and spotfire do a "better" job 
> than MPL at styling), there are some well-established visual 
> principles that matplotlib violates. Some of my biggest pet peeves are:
>
> 1) The default 'axes.color_cycle' values should be equally visible, 
> with similar luminance values. The current defaults (bgrcmyk) do not 
> have this property -- c and y are harder to see, and thus carry less 
> visual emphasis. A color table like the "Dark2" color brewer table 
> (http://learnr.files.wordpress.com/2009/04/colours-dark2.png, 
> colorbrewer2.org <http://colorbrewer2.org>) is more uniform, and 
> carefully designed for visibility and contrast. 'rgbcmyk' is clearly 
> an arbitrary choice -- why not use a smarter default?
>
> 2) The default 'jet' colormap for images has a lot of poor properties 
> (which is even mentioned on the MPL docs at 
> http://matplotlib.org/api/pyplot_summary.html#id1). The brain is bad 
> at ordering changes in hue (which is bigger -- purple or yellow?), and 
> better at ordering changes in intensity or saturation. A colleague of 
> mine designed a visualization tool for doctors, and found that the 
> rainbow color table had a dramatic negative effect on the 
> effectiveness of the tool (you can watch her TED talk about this at 
> https://www.youtube.com/watch?v=kU7veyGGps4&t=440s). The jet default 
> is especially frustrating, since it *cannot* be modified via rcParams
>
> 3) Some of the defaults violate Tufte principles like minimizing 
> "chart junk." For example, the 'stepfilled' mode for hist is probably 
> better than the default, which draws vertical lines between every bin. 
> Those lines make the histogram noisier -- do they convey any extra 
> information? Again, this can't be tweaked via rcParams.
>
> Sorry for being long-winded -- I just want to make the case that this 
> is an important (and not *entirely* subjective) issue. If nothing 
> else, it would be great to see some clear statement about where the 
> MPL devs stand on this issue -- what criteria must be met to consider 
> a change to the defaults? My apologies if such a document already 
> exists somewhere!
>
> Cheers,
> Chris Beaumont
>
>
>
>
>
> On Sat, Jul 20, 2013 at 3:03 PM, 
> <mat...@li... 
> <mailto:mat...@li...>> wrote:
>
> Send Matplotlib-devel mailing list submissions to
> mat...@li...
> <mailto:mat...@li...>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> or, via email, send a message with subject or body 'help' to
> mat...@li...
> <mailto:mat...@li...>
>
> You can reach the person managing the list at
> mat...@li...
> <mailto:mat...@li...>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Matplotlib-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Plot or Not: voting to create better matplotlibrc
> (Eric Firing)
> 2. Re: How to use STIX fonts in matplotlib plots? (Eric Firing)
> 3. Re: Plot or Not: voting to create better matplotlibrc
> (Benjamin Root)
> 4. Re: How to use STIX fonts in matplotlib plots? (Benjamin Root)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: 2013年7月20日 08:20:11 -1000
> From: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> matplotlibrc
> To: mat...@li...
> <mailto:mat...@li...>
> Message-ID: <51E...@ha...
> <mailto:51E...@ha...>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2013年07月20日 4:18 AM, David P. Sanders wrote:
> > Hi,
> >
> > Probably many of you know about "Plot or Not", a site where we
> vote on
> > the same plot presented in different ways, to get feedback about
> better
> > matplotlibrc params:
> >
> > http://warm-escarpment-9042.herokuapp.com/
> >
> > It seems to me an absolutely fantastic idea! I think many people
> do not
> > realise how fantastic the plots can look with some of this modern
> > styling. (Styling was mentioned several times at SciPy.)
> >
> > Would it be possible to put a link to this site on the
> matplotlib web
> > page and encourage people to use it?
>
> David,
>
> Interesting, but I'm not sure this is a good approach. I really don't
> see the point of the voting. What I think would be more useful
> would be
> a set of matplotlibrc files with examples of their effect on at
> least a
> few plot types.
>
> >
> > Definitely time to update the defaults!!
>
> Or maybe include a representative set of rcParams combinations to make
> it easier for people to choose a design that suits their purpose.
> This
> could be part of a toolkit.
>
> Eric
>
> >
> > Best wishes,
> > David.
> >
> > --
> > Dr. David P. Sanders
> >
> > Profesor Titular "A" / Associate Professor
> > Departamento de F?sica, Facultad de Ciencias
> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >
> > dps...@ci... <mailto:dps...@ci...>
> <mailto:dps...@ci...
> <mailto:dps...@ci...>>
> > http://sistemas.fciencias.unam.mx/~dsanders
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
> > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> >
> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from
> AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: 2013年7月20日 08:55:37 -1000
> From: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> plots?
> To: mat...@li...
> <mailto:mat...@li...>
> Message-ID: <51E...@ha...
> <mailto:51E...@ha...>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2013年07月20日 4:41 AM, David P. Sanders wrote:
> > I find the default font used in matplotlib horrible. We should
> be able
> > to do much better these days.
>
> Which font is being used as default on your installation? And
> what are
> the characteristics that earn the rating of "horrible"?
>
> Eric
>
>
>
> ------------------------------
>
> Message: 3
> Date: 2013年7月20日 14:58:12 -0400
> From: Benjamin Root <ben...@ou... <mailto:ben...@ou...>>
> Subject: Re: [matplotlib-devel] Plot or Not: voting to create better
> matplotlibrc
> To: Eric Firing <ef...@ha... <mailto:ef...@ha...>>
> Cc: matplotlib development list
> <mat...@li...
> <mailto:mat...@li...>>
> Message-ID:
> 
> <CANNq6F=pdWohTRYLqEkG3oy6VoWYJ=c4Q...@ma... <mailto:c4Q...@ma...>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> >From discussions with others at SciPy, we found ourselves
> disagreeing on
> what default we would want. We also weren't sure exactly which
> params were
> the ones that people tended to change. We have zero data on this.
> This site
> is intended to help start that data collection process.
>
> We can certainly improve this site to collect other kinds of info,
> but this
> is just a start. One could also view this as a launching point for
> teaching
> how to use rcParams (sorry David, i kinda like that name) in mpl.
> You all
> know I never let a good teaching moment go to waste!
>
> As for linking from matplotlib.org <http://matplotlib.org>, I am
> ambivalent. It is a bit gimmicky,
> and I do worry about being counterproductive to efforts in SciPy
> to be more
> inclusive of women (given the rather anti-feministic undertones of
> the site
> we are parodying). Of course, that could just be me being overly
> cautious.
>
> Cheers!
> Ben Root
> On Jul 20, 2013 2:20 PM, "Eric Firing" <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> > On 2013年07月20日 4:18 AM, David P. Sanders wrote:
> > > Hi,
> > >
> > > Probably many of you know about "Plot or Not", a site where we
> vote on
> > > the same plot presented in different ways, to get feedback
> about better
> > > matplotlibrc params:
> > >
> > > http://warm-escarpment-9042.herokuapp.com/
> > >
> > > It seems to me an absolutely fantastic idea! I think many
> people do not
> > > realise how fantastic the plots can look with some of this modern
> > > styling. (Styling was mentioned several times at SciPy.)
> > >
> > > Would it be possible to put a link to this site on the
> matplotlib web
> > > page and encourage people to use it?
> >
> > David,
> >
> > Interesting, but I'm not sure this is a good approach. I really
> don't
> > see the point of the voting. What I think would be more useful
> would be
> > a set of matplotlibrc files with examples of their effect on at
> least a
> > few plot types.
> >
> > >
> > > Definitely time to update the defaults!!
> >
> > Or maybe include a representative set of rcParams combinations
> to make
> > it easier for people to choose a design that suits their
> purpose. This
> > could be part of a toolkit.
> >
> > Eric
> >
> > >
> > > Best wishes,
> > > David.
> > >
> > > --
> > > Dr. David P. Sanders
> > >
> > > Profesor Titular "A" / Associate Professor
> > > Departamento de F?sica, Facultad de Ciencias
> > > Universidad Nacional Aut?noma de M?xico (UNAM)
> > >
> > > dps...@ci... <mailto:dps...@ci...>
> <mailto:dps...@ci...
> <mailto:dps...@ci...>>
> > > http://sistemas.fciencias.unam.mx/~dsanders
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
> > > <http://sistemas.fciencias.unam.mx/%7Edsanders>
> > >
> > > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> > > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------------
> > > See everything from the browser to the database with AppDynamics
> > > Get end-to-end visibility with application monitoring from
> AppDynamics
> > > Isolate bottlenecks and diagnose root cause in seconds.
> > > Start your free trial of AppDynamics Pro today!
> > >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > >
> > >
> > >
> > > _______________________________________________
> > > Matplotlib-devel mailing list
> > > Mat...@li...
> <mailto:Mat...@li...>
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> > >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from
> AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 4
> Date: 2013年7月20日 15:03:20 -0400
> From: Benjamin Root <ben...@ou... <mailto:ben...@ou...>>
> Subject: Re: [matplotlib-devel] How to use STIX fonts in matplotlib
> plots?
> To: "David P. Sanders" <dps...@ci...
> <mailto:dps...@ci...>>
> Cc: matplotlib development list
> <mat...@li...
> <mailto:mat...@li...>>
> Message-ID:
> 
> <CANNq6Fm0Oz=3uk...@ma... <mailto:3uk...@ma...>>
> Content-Type: text/plain; charset="iso-8859-1"
>
> David,
>
> IIRC, we were just starting to investigate how to produce retina
> graphics.
> Perhaps you might be able to help Mike D and Michael de Hoon with
> there
> efforts because very few of us have retina displays.
>
> Cheers!
> Ben Root
> On Jul 20, 2013 10:43 AM, "David P. Sanders"
> <dps...@ci... <mailto:dps...@ci...>>
> wrote:
>
> > I find the default font used in matplotlib horrible. We should
> be able to
> > do much better these days.
> >
> > One very interesting option, at least for standard (paper)
> publishing, is
> > the STIX fonts, which is a Times-like font set promoted by several
> > publishers.
> >
> > There are various options in matplotlib, such as
> > matplotlib.rcParams["mathtext.fontset"], which allow the option
> "stix",
> > but I have not been able to get it to work. Can anybody please
> help me with
> > this -- what is required?
> >
> > I have the STIX otf or ttf installed on my Mac, but I don't seem
> to manage
> > to get the LaTeX versions installed -- installing LaTeX fonts is
> *so*
> > disgusting (is there some helper script for that?).
> >
> > Thanks and best wishes,
> > David.
> >
> > --
> > Dr. David P. Sanders
> >
> > Profesor Titular "A" / Associate Professor
> > Departamento de F?sica, Facultad de Ciencias
> > Universidad Nacional Aut?noma de M?xico (UNAM)
> >
> > dps...@ci... <mailto:dps...@ci...>
> > http://sistemas.fciencias.unam.mx/~dsanders
> <http://sistemas.fciencias.unam.mx/%7Edsanders>
> >
> > Cub?culo / office: #414, 4o. piso del Depto. de F?sica
> >
> > Tel.: +52 55 5622 4965 <tel:%2B52%2055%205622%204965>
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from
> AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> <mailto:Mat...@li...>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> End of Matplotlib-devel Digest, Vol 86, Issue 17
> ************************************************
>
>
>
>
> -- 
> ************************************
> Chris Beaumont
> Graduate Student
> Institute for Astronomy
> University of Hawaii at Manoa
> 2680 Woodlawn Drive
> Honolulu, HI 96822
> www.ifa.hawaii.edu/~beaumont <http://www.ifa.hawaii.edu/%7Ebeaumont>
> ************************************
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel