matplotlib-devel Mailing List for matplotlib (Page 2)

Adam Mercer wrote:
> On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker<js...@fa...> wrote:
>
> 
>> Chris: This usually happens when you build mix different versions of
>> geos, i.e. build with the 3.1 lib but the 2.2.3 headers, or link with
>> the 3.1 shared lib and then have it pick up the 2.2.3 shared lib at run
>> time. Do you have two versions of geos on your system? If so, make
>> sure basemap is only finding one of them, both at build time and run time.
>> 
>
> So does basemap support GEOS-3.1 now?
Yes.
> I thought that it only worked
> with 2.2.3? If so this is great news.
>
> Cheers
>
> Adam
> 
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker<js...@fa...> wrote:
> Chris: This usually happens when you build mix different versions of
> geos, i.e. build with the 3.1 lib but the 2.2.3 headers, or link with
> the 3.1 shared lib and then have it pick up the 2.2.3 shared lib at run
> time. Do you have two versions of geos on your system? If so, make
> sure basemap is only finding one of them, both at build time and run time.
So does basemap support GEOS-3.1 now? I thought that it only worked
with 2.2.3? If so this is great news.
Cheers
Adam

On Mon, Jul 27, 2009 at 8:14 PM, Jeff Whitaker<js...@fa...> wrote:
> Chris Petrich wrote:
>>
>> Hi,
>>
>> I get a Topology Exception with GEOS 3.1:
>>
>> import mpl_toolkits.basemap as bm
>> print "GEOS version: ", bm._geoslib.__geos_version__
>> print "basemap version: ", bm.__version__
>>
>> m = bm.Basemap(width=12000000,height=8000000, \
>>      resolution='l',projection='laea',\
>>      lat_0=55,lon_0=175.)
>>
>> output:
>>
>> GEOS version: 3.1.0-CAPI-1.5.0
>> basemap version: 0.99.3
>> GEOS_ERROR: TopologyException: found non-noded intersection between
>> 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
>> 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
>> Segmentation fault
>>
>>
>> Any solutions?
>> cheers
>>
>> Chris
>>
>>
>
> Chris: This usually happens when you build mix different versions of geos,
> i.e. build with the 3.1 lib but the 2.2.3 headers, or link with the 3.1
> shared lib and then have it pick up the 2.2.3 shared lib at run time. Do
> you have two versions of geos on your system? If so, make sure basemap is
> only finding one of them, both at build time and run time.
>
> -Jeff
>
Thanks, Jeff,
that was it.
I had both geos 3.1 and 2.2.3 installed in /usr. basemap found 3.1
during build/installation while _libgeos tried to import 2.2.3 at run
time (this became obvious after I removed the 2.2.3 libraries).
Removed libgeos 2.2.3 and "python setup.py install"-ed basemap 0.99.3
from a fresh tar ball, works like a charm now!
I appreciate the effort you put into developing basemap. The result is awesome.
cheers
Chris

Chris Petrich wrote:
> Hi,
>
> I get a Topology Exception with GEOS 3.1:
>
> import mpl_toolkits.basemap as bm
> print "GEOS version: ", bm._geoslib.__geos_version__
> print "basemap version: ", bm.__version__
>
> m = bm.Basemap(width=12000000,height=8000000, \
> resolution='l',projection='laea',\
> lat_0=55,lon_0=175.)
>
> output:
>
> GEOS version: 3.1.0-CAPI-1.5.0
> basemap version: 0.99.3
> GEOS_ERROR: TopologyException: found non-noded intersection between
> 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
> 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
> Segmentation fault
>
>
> Any solutions?
> cheers
>
> Chris
>
> 
Chris: This usually happens when you build mix different versions of 
geos, i.e. build with the 3.1 lib but the 2.2.3 headers, or link with 
the 3.1 shared lib and then have it pick up the 2.2.3 shared lib at run 
time. Do you have two versions of geos on your system? If so, make 
sure basemap is only finding one of them, both at build time and run time.
-Jeff

Hi,
I get a Topology Exception with GEOS 3.1:
import mpl_toolkits.basemap as bm
print "GEOS version: ", bm._geoslib.__geos_version__
print "basemap version: ", bm.__version__
m = bm.Basemap(width=12000000,height=8000000, \
 resolution='l',projection='laea',\
 lat_0=55,lon_0=175.)
output:
GEOS version: 3.1.0-CAPI-1.5.0
basemap version: 0.99.3
GEOS_ERROR: TopologyException: found non-noded intersection between
3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
Segmentation fault
Any solutions?
cheers
Chris

I committed the original example into the svn, and I admit that I was
not careful with the code. I agree that the arguments should be float
(the doc does say that set_alpha takes float).
The example is now updated to use floats (svn r7300).
Regards,
-JJ
On Mon, Jul 27, 2009 at 9:15 AM, Michiel de Hoon<mjl...@ya...> wrote:
>
> Hi everybody,
>
> Should the set_alpha method of a graphics context accept a string (instead of a number) as an argument? Currently, some backends (agg, ps, pdf) accept strings such as "0.2", whereas others (svg, cairo, Mac OS X) do not. Usually that is not a problem, since in almost all cases set_alpha is called with a number as the argument. However, the example axes_zoom_effect.py, which was recently added to examples/pylab_examples, has these lines:
>
>  prop_patches["alpha"]="0.2"
>
> which causes a call to gc.set_alpha of the form gc.set_alpha("0.2"). Backends that do not allow strings choke on that.
>
> Whereas in general it may perhaps be useful to allow such strings, it adds complexity to the code, and I don't see a good use case for it.
>
> --Michiel.
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

In svn 7298 I changed a key chunk of code that was working fine, so I 
would like to explain why I fixed it when it wasn't broken, and ask for 
review and testing, or at least keeping your eyes open for anything I 
may have overlooked.
In the course of making the very simple change to support scalar 
arguments to plot (for plotting a single symbol), I found, as I have 
many times before, that the argument handling was rather complex, 
repetitive, and hard to follow. I couldn't resist seeing if I could 
simplify it, in the hope that this would make it easier to maintain. 
The result is a reduction in LOC and a codepath that to my eye, at 
least, is easier to follow.
Eric

Hi everybody,
Should the set_alpha method of a graphics context accept a string (instead of a number) as an argument? Currently, some backends (agg, ps, pdf) accept strings such as "0.2", whereas others (svg, cairo, Mac OS X) do not. Usually that is not a problem, since in almost all cases set_alpha is called with a number as the argument. However, the example axes_zoom_effect.py, which was recently added to examples/pylab_examples, has these lines:
 prop_patches["alpha"]="0.2"
which causes a call to gc.set_alpha of the form gc.set_alpha("0.2"). Backends that do not allow strings choke on that.
Whereas in general it may perhaps be useful to allow such strings, it adds complexity to the code, and I don't see a good use case for it.
--Michiel.
 

Hi,
> Anyway, since the mathtex setup infrastructure is based on what 
> matplotlib was already doing, there's a common convention we can 
> exploit. Essentially, the matplotlib setup.py builds up a list of 
> extension modules (ext_modules) and packages and then passes those 
> lists to distutils for building. So, in theory, all mathtex needs 
> to do is provide a function that will add extension modules and 
> packages to those lists (basically like all of the build_* methods 
> in setupext.py). So basically, matplotlib's setup.py would import 
> lib/mathtex/setupext.py (by filename) and call a method in it. Lots 
> of details I'm missing, but that should provide a general framework.
Not sure about the extension modules + lists stuff, although 
setuptools is not my area of expertise. Sadly executing the lib/ 
mathtex/setup.py file isn't really an option either, so I'll need to 
think on it. Might need to ask for some help though.
>
> Another issue this raises is whether to build the FT2Font and png 
> modules twice, once as part of matplotlib, and once as part of 
> mathtex. Once mathtex is a truly external dependency for 
> matplotlib, I don't see a way around this, so maybe we should just 
> pretend we're already there, despite the duplication. If we want to 
> be clever, I could see mathtex being smart about imports: try 
> importing its local copies of its libraries and failing that import 
> matplotlib's. I'm not entirely sure about that idea, but I sort of 
> feel "hacky-if-you-do, hacky-if-you-don't" here ;)
I don't think it hurts having two FT2Font wrappers lying around on a 
system.
> Please try to use svn:externals if you can -- that will make pulling 
> updates from mathtex easier. I've never used it cross-repository 
> like this, so there may be unforeseen issues.
svn:externals seems to work quite well and is currently used in the 
mathtex branch to pull mathtex.
> It also just occurred to me that we might want to take another step 
> in preparation for mathtex as an external dependency: make it 
> optional. That is, if importing mathtex fails, be able to render 
> regular text, and warn if trying to render math text.
Shouldn't be too hard to add, I'll write in backend support today.
Regards, Freddie.

Rob Clewley wrote:
> I wrote a wrapper to do this for my own code because I wanted it so
> much. I can't see why it would be a problem to support, it's only one
> extra if statement.
> 
> +1 from me!
Done in svn 7294.
Eric
> 
> On Sat, Jul 25, 2009 at 1:16 AM, Jan Müller<mu...@im...> wrote:
>> basically this works:
>>
>> plot([1], [1], "*")
>>
>> but I think it would be more convenient to add some kind of auto casting to the function in order to make this
>>
>> plot(1, 1, "*")
>>
>> work.
>>
>> I use those single-point-plotting-commands a lot in order to highlight a special point in a series of data, but I forget the [] all the time.
>>
>> Besides being much more convenient (at least for me) this behavior would also be much closer to the matlab version, since this works there without any problems.
>>
>> Any ideas/comments/criticism on this?
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> 
> 

On Sat, Jul 25, 2009 at 3:13 PM, Rob Clewley<rob...@gm...> wrote:
> I wrote a wrapper to do this for my own code because I wanted it so
> much. I can't see why it would be a problem to support, it's only one
> extra if statement.
Or zero extra statements, if one just replaces the
 if len(x.shape) == 1:
 x = x[:, np.newaxis]
lines with
 while len(x.shape) < 2:
 x = x[:, np.newaxis]
-- Nathaniel

I wrote a wrapper to do this for my own code because I wanted it so
much. I can't see why it would be a problem to support, it's only one
extra if statement.
+1 from me!
On Sat, Jul 25, 2009 at 1:16 AM, Jan Müller<mu...@im...> wrote:
> basically this works:
>
> plot([1], [1], "*")
>
> but I think it would be more convenient to add some kind of auto casting to the function in order to make this
>
> plot(1, 1, "*")
>
> work.
>
> I use those single-point-plotting-commands a lot in order to highlight a special point in a series of data, but I forget the [] all the time.
>
> Besides being much more convenient (at least for me) this behavior would also be much closer to the matlab version, since this works there without any problems.
>
> Any ideas/comments/criticism on this?
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Robert H. Clewley, Ph.D.
Assistant Professor
Department of Mathematics and Statistics
and Neuroscience Institute
Georgia State University
720 COE, 30 Pryor St
Atlanta, GA 30303, USA
tel: 404-413-6420 fax: 404-413-6403
http://www2.gsu.edu/~matrhc
http://brainsbehavior.gsu.edu/

basically this works:
plot([1], [1], "*")
but I think it would be more convenient to add some kind of auto casting to the function in order to make this
plot(1, 1, "*")
work.
I use those single-point-plotting-commands a lot in order to highlight a special point in a series of data, but I forget the [] all the time.
Besides being much more convenient (at least for me) this behavior would also be much closer to the matlab version, since this works there without any problems.
Any ideas/comments/criticism on this?

Hi,
On 23 Jul 2009, at 22:46, Gökhan SEVER wrote:
> Could you please the advantages of using mathtext? How does it 
> compare and contrast to the existing interface?
The interface itself is mostly the same, although there are a few 
enhancements to make it easier to use. To main advantages of using 
mathtex are that, being an external project, it is likely to 
experience a wider audience than the current code in matplotlib.
This should result in a package that is better maintained with more 
features. Currently, however, it is almost exactly the same as the 
mathtext code in matplotlib.
> Any pointers to read before getting more lost?
There is the project code site here: http://code.google.com/p/mathtex/ 
while my project blog is here: http://gsoc-mathtex.blogspot.com/
Regards, Freddie.

Hi all,
I've just tried the Qt4 backend and noticed that, different from the 
previous backend I was using, the last command of a script pylab.show() 
does not raise the figures to the front (they show up but in the 
background). This is the case at least on my OS X machine. I personally 
feels like the figures taking becoming the active windows should be the 
right behavior. In case, this is valuable to the project, please find 
below at patch that achieves that behavior.
Regards,
-Gellule

On Thu, Jul 23, 2009 at 8:36 AM, Freddie Witherden <fr...@wi...>wrote:
> Hi all,
>
> With the integration of mathtex into matplotlib nearing completion
> (just bug fixes really) I think now is a good time to be considering
> the best way to include mathtex into matplotlib.
>
> This has already been discussed on the mathtex mailing list, with
> Michael proposing a few ways of doing this. However, I am not an
> expert by any means when it comes to Python set-up/configuring. (As
> anyone who has looked at setup.py in mathtex will have seen.)
>
> While including the source is not difficult (it can be done directly
> or using svn:external) getting it built/configured is. Lets say that
> mathtex was dumped into lib/, how would one go about configuring and
> installing it from setup.py in matplotlib.
>
> Although I am sure that just executing a shell command would do it I
> am sure there must be a 'better' option for this type of 'package
> chaining'.
>
> Does anyone have any suggestions or recommendations?
>
> Regards, Freddie.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
Could you please the advantages of using mathtext? How does it compare and
contrast to the existing interface?
Any pointers to read before getting more lost?
Thanks,
-- 
Gökhan

There may be a setuptools solution here, but if there is, I'm not the 
one to know ;) matplotlib is for the most part ignorant of setuptools, 
and it's probably reasonable to keep it that way.
Anyway, since the mathtex setup infrastructure is based on what 
matplotlib was already doing, there's a common convention we can 
exploit. Essentially, the matplotlib setup.py builds up a list of 
extension modules (ext_modules) and packages and then passes those lists 
to distutils for building. So, in theory, all mathtex needs to do is 
provide a function that will add extension modules and packages to those 
lists (basically like all of the build_* methods in setupext.py). So 
basically, matplotlib's setup.py would import lib/mathtex/setupext.py 
(by filename) and call a method in it. Lots of details I'm missing, but 
that should provide a general framework.
Another issue this raises is whether to build the FT2Font and png 
modules twice, once as part of matplotlib, and once as part of mathtex. 
Once mathtex is a truly external dependency for matplotlib, I don't see 
a way around this, so maybe we should just pretend we're already there, 
despite the duplication. If we want to be clever, I could see mathtex 
being smart about imports: try importing its local copies of its 
libraries and failing that import matplotlib's. I'm not entirely sure 
about that idea, but I sort of feel "hacky-if-you-do, 
hacky-if-you-don't" here ;) 
I see the code maintenance problem of this duplication (i.e. making sure 
bugfixes to FT2Font make it into matplotlib and mathtex) almost as a 
separate issue. We know the solution to that: break out the freetype 
wrappers into its own project (which then both matplotlib and mathtex 
would rely on) -- but that's probably outside of the scope of this GSoC 
project.
Please try to use svn:externals if you can -- that will make pulling 
updates from mathtex easier. I've never used it cross-repository like 
this, so there may be unforeseen issues.
It also just occurred to me that we might want to take another step in 
preparation for mathtex as an external dependency: make it optional. 
That is, if importing mathtex fails, be able to render regular text, and 
warn if trying to render math text.
Mike
Freddie Witherden wrote:
> Hi all,
>
> With the integration of mathtex into matplotlib nearing completion 
> (just bug fixes really) I think now is a good time to be considering 
> the best way to include mathtex into matplotlib.
>
> This has already been discussed on the mathtex mailing list, with 
> Michael proposing a few ways of doing this. However, I am not an 
> expert by any means when it comes to Python set-up/configuring. (As 
> anyone who has looked at setup.py in mathtex will have seen.)
>
> While including the source is not difficult (it can be done directly 
> or using svn:external) getting it built/configured is. Lets say that 
> mathtex was dumped into lib/, how would one go about configuring and 
> installing it from setup.py in matplotlib.
>
> Although I am sure that just executing a shell command would do it I 
> am sure there must be a 'better' option for this type of 'package 
> chaining'.
>
> Does anyone have any suggestions or recommendations?
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
With the integration of mathtex into matplotlib nearing completion 
(just bug fixes really) I think now is a good time to be considering 
the best way to include mathtex into matplotlib.
This has already been discussed on the mathtex mailing list, with 
Michael proposing a few ways of doing this. However, I am not an 
expert by any means when it comes to Python set-up/configuring. (As 
anyone who has looked at setup.py in mathtex will have seen.)
While including the source is not difficult (it can be done directly 
or using svn:external) getting it built/configured is. Lets say that 
mathtex was dumped into lib/, how would one go about configuring and 
installing it from setup.py in matplotlib.
Although I am sure that just executing a shell command would do it I 
am sure there must be a 'better' option for this type of 'package 
chaining'.
Does anyone have any suggestions or recommendations?
Regards, Freddie.

Hi,
On 23 Jul 2009, at 03:34, John Hunter wrote:
> If experience is any guide, you won't hear from the people who depend
> on it until you remove support (plaintive pleas to the mailing list
> notwithstanding). The old timers love their small PS files, and we
> support this because many people have asked for it. I hesitate to
> remove support lacking compelling justification, though I prefer the
> embedded solution myself.
I am just pondering if it is a compelling enough reason to add support 
for it to mathtex -- as the only use for AFM support would be 
specifically for embedded PS/PDF fonts.
Would this be a valid alternative: bundling fonts with similar metrics 
as the PS fonts (we already have some unicode fonts in mathtex) and 
then on the matplotlib side choose not to embed such fonts. So mathtex 
works in terms of .ttf fonts, but at the matplotlib end of things it 
can opt not to embed them.
This way we retain support for the feature with no additional demands 
on mathtex.
Regards, Freddie.

Hi all,
I've been playing with pyglet and matplotlib integration using the Agg
backend as suggested some time ago on this list. The idea is to let
matplotlib do all the pretty stuff and let pyglet do the rendering of
images (currently, only imshow has been proxied).
Image rendering is done through GL texture using shaders for both
nearest/bilinear and bicubic filters and color LUT. Currently, this
allows to use matplotlib colormap with under/over colors but no bad
color yet.
Sources: http://www.loria.fr/~rougier/tmp/glumpy.tgz
Screenshot: http://www.loria.fr/~rougier/tmp/glumpy-matplotlib.png
Just run 'demo-matplotlib.py' and 'demo-matplotib-2.py' (implementation
of the dynamic_image.py animation demo).
Nicolas

On Wed, Jul 22, 2009 at 1:21 PM, Jouni K. Seppänen<jk...@ik...> wrote:
> Freddie Witherden <fr...@wi...> writes:
>
>> The question is how important are these as a feature? While I can add
>> support for them into mathtex I am unsure exactly how useful they are.
If experience is any guide, you won't hear from the people who depend
on it until you remove support (plaintive pleas to the mailing list
notwithstanding). The old timers love their small PS files, and we
support this because many people have asked for it. I hesitate to
remove support lacking compelling justification, though I prefer the
embedded solution myself.
JDH

Freddie Witherden <fr...@wi...> writes:
> The question is how important are these as a feature? While I can add 
> support for them into mathtex I am unsure exactly how useful they are. 
You can get really small output using the core fonts, which I'm sure
some users appreciate. They are also problematic, since not everyone has
a copy of the exact right fonts, and the viewer program substitutes
something else that has (or should have) the same metrics. Thus a figure
that you like on screen might look very different when printed (possibly
via a professional printer that does have a copy the real Helvetica
etc). To avoid such problems, some publishers require all fonts to be
embedded, and the latest version of the PDF spec deprecated the use of
the core fonts without embedding them.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi all,
Currently mathtex does not have support for anything other than 
TrueType fonts. However, matplotlib can make use of the 14 'core' 
fonts that are part of the PS/PDF specs. The metrics for these fonts 
come from AFM files.
The question is how important are these as a feature? While I can add 
support for them into mathtex I am unsure exactly how useful they are. 
Mathtex will always be built with FT2Font (FreeType) so it does not 
have any advantages dependency-wise.
Hence, I am interested if there is a demand/need for them.
Regards, Freddie.

Today is the last day to register for SciPy 2009 at the early bird rates.
Please register (http://conference.scipy.org/to_register )
by the end of the day to take advantage of the reduced early registration
rate.
The conference schedule is available here:
 http://conference.scipy.org/schedule
The special group rate for the Marriot Hotel is no longer available. However,
there are a number of closer and less expensive choices still available:
 http://admissions.caltech.edu/visiting/accommodations
I've been staying at the Vagabond Inn for the last several years:
 http://www.vagabondinn-pasadena-hotel.com/
It is within easy walking distance of the conference and has just been
completely renovated. Rooms at the Vagabond start at 79ドル/night.
About the conference
--------------------
SciPy 2009, the 8th Python in Science conference, will be held from
August 18-23, 2009 at Caltech in Pasadena, CA, USA. The conference
starts with two days of tutorials to the scientific Python tools.
There will be two tracks, one for introduction of the basic tools to
beginners, and one for more advanced tools. The tutorials will be
followed by two days of talks. Both days of talks will begin with a
keynote address. The first day’s keynote will be given by Peter
Norvig, the Director of Research at Google; while, the second keynote
will be delivered by Jon Guyer, a Materials Scientist in the
Thermodynamics and Kinetics Group at NIST. The program committee will
select the remaining talks from submissions to our call for papers.
All selected talks will be included in our conference proceedings
edited by the program committee. After the talks each day we will
provide several rooms for impromptu birds of a feather discussions.
Finally, the last two days of the conference will be used for a number
of coding sprints on the major software projects in our community.
For the 8th consecutive year, the conference will bring together the
developers and users of the open source software stack for scientific
computing with Python. Attendees have the opportunity to review the
available tools and how they apply to specific problems. By providing
a forum for developers to share their Python expertise with the wider
commercial, academic, and research communities, this conference
fosters collaboration and facilitates the sharing of software
components, techniques, and a vision for high level language use in
scientific computing.
For further information, please visit the conference homepage:
http://conference.scipy.org.
Important Dates
---------------
* Friday, July 3: Abstracts Due
* Wednesday, July 15: Announce accepted talks, post schedule
* Wednesday, July 22: Early Registration ends
* Tuesday-Wednesday, August 18-19: Tutorials
* Thursday-Friday, August 20-21: Conference
* Saturday-Sunday, August 22-23: Sprints
* Friday, September 4: Papers for proceedings due
Executive Committee
-------------------
* Jarrod Millman, UC Berkeley, USA (Conference Chair)
* Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair)
* Stéfan van der Walt, University of Stellenbosch, South Africa
(Program Co-Chair)
* Fernando Pérez, UC Berkeley, USA (Tutorial Chair)

Jouni K. Seppänen <jk...@ik...> writes:
> I now have two different implementations in two branches of my
> github repository (patches attached):
>
> http://github.com/jkseppan/matplotlib/tree/boilerplate
> http://github.com/jkseppan/matplotlib/tree/autoboiler
I finally committed the "boilerplate" variant. It seems to pass the
tests in pylab_examples, but now might be a good time for everyone to
take a look to see if I have broken anything.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks