matplotlib-devel Mailing List for matplotlib

On Fri, Jul 31, 2009 at 1:10 PM, John Hunter<jd...@gm...> wrote:
> The gallery is becoming the goto place for most users of the website,
> and I would like as many examples as possible to run after a simple
> download to the desktop . I am sensitive to packagers who may not
> want to ship large amounts of data w/ the main library, so we may want
> to minimize the amount we ship in mpl-data which
> matplotlib.get_example_data uses, but it may be a good idea to setup a
> new svn directory at the top level (mpl_data) and write a urllib
> enabled matplotlib.get_example_data that fetches it from the repo if
> it can't find it locally.
OK, I committed a first pass at this to HEAD. I created a new svn
directory called mpl_data
 svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/mpl_data
and a cbook.get_mpl_data function, as used in this example::
 import matplotlib.cbook as cbook
 import matplotlib.pyplot as plt
 fname = cbook.get_mpl_data('lena.png', asfileobj=False)
 print 'fname', fname
 im = plt.imread(fname)
 plt.imshow(im)
 plt.show()
The function will check ~/.matplotlib/mpl_data and fetch it using
urllib from svn HEAD if it is not there, caching in the process. It
would be nice to support an svn revision (w/o relying on svn) as I
note in this comment in get_mpl_data:
 # TODO: how to handle stale data in the cache that has been
 # updated from svn -- is there a clean http way to get the current
 # revision number that will not leave us at the mercy of html
 # changes at sf?
If others agree w/ the basic concept, we should port as many data
requiring examples over, removing data from examples/data and
lib/matplotlib/mpl-data/example as we go. This will result in smaller
tarballs and binaries, and make the examples more portable.
JDH

On Wed, Jul 22, 2009 at 8:15 AM, Jouni K. Seppänen<jk...@ik...> wrote:
> 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.
There is one problem, but I am not sure what the workaround is yet.
The doc strings in rest are broken, eg compare the pyplot Line2D
properties with the Axes equivalent:
 http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.loglog
vs
 http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.loglog
Both use the artist.kwdocs inspector to autogenerate the tables.
There is a rc param in doc/matplotlibrc which we use to force rest
formatting
 docstring.hardcopy : True # set this when you want to generate
hardcopy docstring
which is False by default for src installs and True when we build the
docs. Then in matplotlib.artist, we do
def kwdoc(a):
 hardcopy = matplotlib.rcParams['docstring.hardcopy']
 if hardcopy:
 return '\n'.join(ArtistInspector(a).pprint_setters_rest(leadingspace=2))
 else:
 return '\n'.join(ArtistInspector(a).pprint_setters(leadingspace=2))
to format rest when making hardcopy.
Then we we interpolate into the docstring at runtime::
 # from Axes.loglog
 def loglog(self, *args, **kwargs):
 """
 ...snip
 The remaining valid kwargs are
 :class:`~matplotlib.lines.Line2D` properties:
 %(Line2D)s
 **Example:**
 .. plot:: mpl_examples/pylab_examples/log_demo.py
 """
 ...snip
 return l
 loglog.__doc__ = cbook.dedent(loglog.__doc__) % martist.kwdocd
we get plain text when hardcopy is False and rest when it is True.
Thus we have the best of both worlds from the interactive shell and on
the website and PDF.
It looks like you are interpolating the strings in in boilerplate,
when they should be left to be interpolated *at runtime* as we do in
the other modules. Ie, it appears you are doing runtime interpolating
when you generate pyplot.py from boilerplate.py. In the old version,
the interpolation of pyplot doc strings were deferred
until runtime, eg from older pyplot.py::
# This function was autogenerated by boilerplate.py. Do not edit as
# changes will be lost
def loglog(*args, **kwargs):
 # allow callers to override the hold state by passing hold=True|False
 b = ishold()
 h = kwargs.pop('hold', None)
 if h is not None:
 hold(h)
 try:
 ret = gca().loglog(*args, **kwargs)
 draw_if_interactive()
 except:
 hold(b)
 raise
 hold(b)
 return ret
if Axes.loglog.__doc__ is not None:
 loglog.__doc__ = dedent(Axes.loglog.__doc__) + """
Additional kwargs: hold = [True|False] overrides default hold state"""
Is there a way to preserve this in the new boilerplate configuration?
JDH

In some examples, I have been moving example functions and data into a
module, so that they can be run from anywhere. Many other examples
still rely on a relative path in the examples dir. Eg, I go to the
gallery and download the source for the axes grid toolkit example
simple_rgb.py, and try to run it from my desktop, I get the error "no
module names demo_image". While I know how to get the data, a naive
user will not. So in some examples I have been adopting the approach,
eg in examples/pylab_examples/scatter_demo2.py
 import matplotlib
 datafile = matplotlib.get_example_data('goog.npy')
These examples will run anywhere mpl is installed. Another approach
would to write a version of get_example_data that checks locally for a
datafile, and if it is not where you expect to be, attempt a
urlretrieve as a temp file.
The gallery is becoming the goto place for most users of the website,
and I would like as many examples as possible to run after a simple
download to the desktop . I am sensitive to packagers who may not
want to ship large amounts of data w/ the main library, so we may want
to minimize the amount we ship in mpl-data which
matplotlib.get_example_data uses, but it may be a good idea to setup a
new svn directory at the top level (mpl_data) and write a urllib
enabled matplotlib.get_example_data that fetches it from the repo if
it can't find it locally.
JDH

A 0.99 branch has been created at:
 https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint
This is where the first 0.99.0.rc1 release candidate and binary releases 
will be made from this weekend.
All potentially disruptive or experimental changes should be made only 
to the trunk. 
*All bug fixes should be made to the branch, and then merged into the 
trunk.* You will need to have svnmerge.py installed. The workflow for 
this is as follows:
1. Check out the branch, if you haven't already:
 svn co 
https://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_99_maint mpl99
2. Make/test bugfixes on your working copy of this branch
3. Commit your changes on this branch
4. 'cd' to your working copy of the trunk
5. Merge the changes from the branch into the trunk:
 svnmerge.py merge -S v0_99_maint
6. Resolve any conflicts, install, and test the merge.
7. Commit the merged changes to the trunk:
 svn commit -F svnmerge-commit-message.txt
Let me know if you have any questions.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Fri, Jul 31, 2009 at 8:25 AM, Tony Yu<ts...@gm...> wrote:
> Yes, that's correct. I called `rgrids` with arguments so I completely missed
> that call to `get_ticklines`. However, I think there's a typo in svn:
> yaxis.gridlines is called instead of yaxis.get_gridlines().
Oops, thanks for catching that. Fixed in svn

On Thu, Jul 30, 2009 at 9:46 AM, John Hunter<jd...@gm...> wrote:
> Sorry I fell behind and did not get a release out earlier as I
> intended. I am going to take another stab this weekend so we can have
> something by scipy. Please commit anything you need to before the
> release, and I will ask Michael to create the release branch tomorrow.
> There will still be ample time for testing and fixing stuff from the
> release branch, but this will be done on the branch rather than the
> trunk. Tentative schedule:
>
> * branch tomorrow
Michael, if you have time today, would you make the 0.99 release
branch, update doc/devel/coding_guide.rst with instructions on how to
check out the branch (basically just change the version numbers so
people are pointed to the current branch), and paste those
instructions here so developers can easily grab the release branch?
Thanks,
JDH

Sorry for sending this twice, John; I forgot to copy the list.
On Jul 31, 2009, at 9:14 AM, John Hunter wrote:
> On Thu, Jul 30, 2009 at 10:01 AM, Tony Yu<ts...@gm...> wrote:
>> Sorry for reposting, but the original may have been overlooked since
>> it was buried deep in a matplotlib-users thread.
>>
>> Currently, `pyplot.rgrids` is returning tick lines instead of grid
>> lines. My guess is that this is a typo, but there may be a compelling
>> reason to return the tick lines. If it is a typo, here's a patch:
>>
>
> Doesn't pyplot.rgrids need to be fixed too:
>
>
>
> def rgrids(*args, **kwargs):
> """
[Snip]
>
> Should
>
> lines = ax.yaxis.get_ticklines()
>
> be
>
> lines = ax.yaxis.get_gridlines()
>
>
> I'm going to make both these changes in svn , but I'd like you to 
> confirm this.
Yes, that's correct. I called `rgrids` with arguments so I completely 
missed that call to `get_ticklines`. However, I think there's a typo 
in svn: yaxis.gridlines is called instead of yaxis.get_gridlines().
-T
Index: lib/matplotlib/pyplot.py
===================================================================
--- lib/matplotlib/pyplot.py	(revision 7313)
+++ lib/matplotlib/pyplot.py	(working copy)
@@ -1102,7 +1102,7 @@
 if not isinstance(ax, PolarAxes):
 raise RuntimeError('rgrids only defined for polar axes')
 if len(args)==0:
- lines = ax.yaxis.gridlines()
+ lines = ax.yaxis.get_gridlines()
 labels = ax.yaxis.get_ticklabels()
 else:
 lines, labels = ax.set_rgrids(*args, **kwargs)

On Thu, Jul 30, 2009 at 10:01 AM, Tony Yu<ts...@gm...> wrote:
> Sorry for reposting, but the original may have been overlooked since
> it was buried deep in a matplotlib-users thread.
>
> Currently, `pyplot.rgrids` is returning tick lines instead of grid
> lines. My guess is that this is a typo, but there may be a compelling
> reason to return the tick lines. If it is a typo, here's a patch:
>
Doesn't pyplot.rgrids need to be fixed too:
def rgrids(*args, **kwargs):
 """
 Set/Get the radial locations of the gridlines and ticklabels on a
 polar plot.
 call signatures::
 lines, labels = rgrids()
 lines, labels = rgrids(radii, labels=None, angle=22.5, **kwargs)
 When called with no arguments, :func:`rgrid` simply returns the
 tuple (*lines*, *labels*), where *lines* is an array of radial
 gridlines (:class:`~matplotlib.lines.Line2D` instances) and
 *labels* is an array of tick labels
 (:class:`~matplotlib.text.Text` instances). When called with
 arguments, the labels will appear at the specified radial
 distances and angles.
 *labels*, if not *None*, is a len(*radii*) list of strings of the
 labels to use at each angle.
 If *labels* is None, the rformatter will be used
 Examples::
 # set the locations of the radial gridlines and labels
 lines, labels = rgrids( (0.25, 0.5, 1.0) )
 # set the locations and labels of the radial gridlines and labels
 lines, labels = rgrids( (0.25, 0.5, 1.0), ('Tom', 'Dick', 'Harry' )
 """
 ax = gca()
 if not isinstance(ax, PolarAxes):
 raise RuntimeError('rgrids only defined for polar axes')
 if len(args)==0:
 lines = ax.yaxis.get_ticklines()
 labels = ax.yaxis.get_ticklabels()
 else:
Should
 lines = ax.yaxis.get_ticklines()
be
 lines = ax.yaxis.get_gridlines()
I'm going to make both these changes in svn , but I'd like you to confirm this.
JDH

On Thu, Jul 30, 2009 at 9:49 PM, Jae-Joon Lee<lee...@gm...> wrote:
> I guess this is related with the decorator introduced by rasterization support. While most of the artist seems to explicitly require the renderer instance as the second argument of the draw method, the draw method in the Axes class have default value of None. The easiest fix seems to let the decorator returns the method with renderer=None as in the Axes. By the way, Jonathan, I guess the easiest workaround for you is to modify your code so that it explicitly gives the renderer argument.
I think the best approach is to use canvas draw rather than artist draw
 ax.figure.canvas.draw()
JDH

I guess this is related with the decorator introduced by rasterization support.
While most of the artist seems to explicitly require the renderer
instance as the second argument of the draw method, the draw method in
the Axes class have default value of None.
The easiest fix seems to let the decorator returns the method with
renderer=None as in the Axes.
By the way, Jonathan, I guess the easiest workaround for you is to
modify your code so that it explicitly gives the renderer argument. As
you see the default value for renderer is None. Just call it as
draw(None).
Regards,
-JJ
On Thu, Jul 30, 2009 at 3:50 AM, Jonathan
Demaeyer<jon...@ho...> wrote:
> Hello,
>
> I just compiled matplotlib using svn. Previously I was using a ubuntu package (version 0.98.3). I
> decided to use the svn version to have mplot3d available.
>
> Everything seem to work well but now when I start one of my python program that use matplotlib, I
> have problem with the axes draw method (a problem that I had not with the version 0.98.3).
>
> Here is the traceback.
>
> ---------------------------------------------------------------------------------------------------
>
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
>  return self.func(*args)
> File "./sg.py", line 1420, in <lambda>
>  bInvEns = Tix.Button(bt,text='Calculer',command=lambda : self.CSInvEns(self.cfr,self.gffr))
> File "./sg.py", line 3267, in CSInvEns
>  gffr.psaddData_m(u,xmin,xmax,pmin,pmax)
> File "./sg.py", line 3451, in psaddData_m
>  self.psDraw(xmin,xmax,pmin,pmax)
> File "./sg.py", line 3526, in psDraw
>  self.aps.draw()
> TypeError: draw_wrapper() takes at least 2 arguments (1 given)
>
> ----------------------------------------------------------------------------------------------------
>
> self.aps is an axes instance. I looked at the doc and effectively the draw method take two arguments
> (the artist - which is self.aps - and the renderer - which I don't know what it is).
>
> I suspect that prior to installing the svn version, with the 0.98.3 version, these two arguments
> were given automatically to the draw method, but now it is no more the case.
>
> As it could also be a bug (but I don't think so) I post it here. I join the log of the compilation
> and the log of a test run (resp. build.out and run.out).
>
> If you have any idea or comment, thank you in advance for sharing it with me.
>
> Jonathan
>
> ============================================================================
> BUILDING MATPLOTLIB
>      matplotlib: 0.98.6svn
>        python: 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC
>            4.3.2]
>       platform: linux2
>
> REQUIRED DEPENDENCIES
>         numpy: 1.2.1
>       freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
>        libpng: found, but unknown version (no pkg-config)
>        Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
>       wxPython: no
>            * wxPython not found
>            * You may need to install 'dev' package(s) to
>            * provide header files.
>         Gtk+: no
>            * Could not find Gtk+ headers in any of
>            * '/usr/local/include', '/usr/include', '.'
>    Mac OS X native: no
>          Qt: no
>          Qt4: no
>         Cairo: 1.4.12
>
> OPTIONAL DATE/TIMEZONE DEPENDENCIES
>       datetime: present, version unknown
>       dateutil: 1.4
>         pytz: 2008b
>
> OPTIONAL USETEX DEPENDENCIES
>        dvipng: 1.11
>      ghostscript: 8.63
>         latex: 3.141592
>        pdftops: 3.00
>
> [Edit setup.cfg to suppress the above messages]
> ============================================================================
> pymods ['pylab']
> packages ['matplotlib', 'matplotlib.backends', 'matplotlib.projections', 'mpl_toolkits', 'mpl_toolkits.mplot3d', 'mpl_toolkits.axes_grid', 'matplotlib.sphinxext', 'matplotlib.numerix', 'matplotlib.numerix.mlab', 'matplotlib.numerix.ma', 'matplotlib.numerix.linear_algebra', 'matplotlib.numerix.random_array', 'matplotlib.numerix.fft', 'matplotlib.delaunay']
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.5
> copying lib/pylab.py -> build/lib.linux-x86_64-2.5
> creating build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/cm.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/fontconfig_pattern.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/path.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/dates.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/axes.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/bezier.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/type1font.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/mlab.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/image.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/units.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/pyplot.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/artist.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/afm.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/backend_bases.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/finance.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/hatch.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/_pylab_helpers.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/mathtext.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/windowing.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/legend.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/ticker.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/figure.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/table.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/texmanager.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/transforms.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/contour.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/_cm.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/colors.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/collections.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/axis.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/cbook.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/text.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/quiver.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/blocking_input.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/lines.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/mpl.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/offsetbox.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/rcsetup.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/widgets.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/pylab.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/patches.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/scale.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/tight_bbox.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/colorbar.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/spines.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/_mathtext_data.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/font_manager.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/dviread.py -> build/lib.linux-x86_64-2.5/matplotlib
> copying lib/matplotlib/pyparsing.py -> build/lib.linux-x86_64-2.5/matplotlib
> creating build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_cocoaagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_ps.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_gdk.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_macosx.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_wx.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_qtagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_emf.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_gtkcairo.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/tkagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_svg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_qt4.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_cairo.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_gtkagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_template.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_qt.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_tkagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_wxagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_pdf.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_mixed.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_agg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_qt4agg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_gtk.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> copying lib/matplotlib/backends/backend_fltkagg.py -> build/lib.linux-x86_64-2.5/matplotlib/backends
> creating build/lib.linux-x86_64-2.5/matplotlib/projections
> copying lib/matplotlib/projections/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/projections
> copying lib/matplotlib/projections/geo.py -> build/lib.linux-x86_64-2.5/matplotlib/projections
> copying lib/matplotlib/projections/polar.py -> build/lib.linux-x86_64-2.5/matplotlib/projections
> creating build/lib.linux-x86_64-2.5/mpl_toolkits
> copying lib/mpl_toolkits/exceltools.py -> build/lib.linux-x86_64-2.5/mpl_toolkits
> copying lib/mpl_toolkits/gtktools.py -> build/lib.linux-x86_64-2.5/mpl_toolkits
> copying lib/mpl_toolkits/__init__.py -> build/lib.linux-x86_64-2.5/mpl_toolkits
> creating build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> copying lib/mpl_toolkits/mplot3d/art3d.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> copying lib/mpl_toolkits/mplot3d/proj3d.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> copying lib/mpl_toolkits/mplot3d/__init__.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> copying lib/mpl_toolkits/mplot3d/axes3d.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> copying lib/mpl_toolkits/mplot3d/axis3d.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/mplot3d
> creating build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/angle_helper.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/axislines.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/axes_rgb.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/grid_helper_curvelinear.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/axes_grid.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/grid_finder.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/anchored_artists.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/__init__.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/clip_path.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/axes_divider.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/axes_size.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/parasite_axes.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> copying lib/mpl_toolkits/axes_grid/inset_locator.py -> build/lib.linux-x86_64-2.5/mpl_toolkits/axes_grid
> creating build/lib.linux-x86_64-2.5/matplotlib/sphinxext
> copying lib/matplotlib/sphinxext/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/sphinxext
> copying lib/matplotlib/sphinxext/only_directives.py -> build/lib.linux-x86_64-2.5/matplotlib/sphinxext
> copying lib/matplotlib/sphinxext/mathmpl.py -> build/lib.linux-x86_64-2.5/matplotlib/sphinxext
> copying lib/matplotlib/sphinxext/plot_directive.py -> build/lib.linux-x86_64-2.5/matplotlib/sphinxext
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix
> copying lib/matplotlib/numerix/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix
> copying lib/matplotlib/numerix/_sp_imports.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix/mlab
> copying lib/matplotlib/numerix/mlab/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix/mlab
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix/ma
> copying lib/matplotlib/numerix/ma/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix/ma
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix/linear_algebra
> copying lib/matplotlib/numerix/linear_algebra/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix/linear_algebra
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix/random_array
> copying lib/matplotlib/numerix/random_array/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix/random_array
> creating build/lib.linux-x86_64-2.5/matplotlib/numerix/fft
> copying lib/matplotlib/numerix/fft/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/numerix/fft
> creating build/lib.linux-x86_64-2.5/matplotlib/delaunay
> copying lib/matplotlib/delaunay/triangulate.py -> build/lib.linux-x86_64-2.5/matplotlib/delaunay
> copying lib/matplotlib/delaunay/interpolate.py -> build/lib.linux-x86_64-2.5/matplotlib/delaunay
> copying lib/matplotlib/delaunay/__init__.py -> build/lib.linux-x86_64-2.5/matplotlib/delaunay
> copying lib/matplotlib/delaunay/testfuncs.py -> build/lib.linux-x86_64-2.5/matplotlib/delaunay
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvbo8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pbkd8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pcrr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pagd8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pncr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pcrbo8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/ptmbi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/psyr.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/ptmri8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pncbi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pzcmi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pcrb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pbkdi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/ptmb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvlo8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/cmtt10.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/putb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/putri8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvr8an.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvb8an.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pplbi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/cmmi10.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pbkl8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/putbi8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pcrro8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pplb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvl8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pplri8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pagdo8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pncri8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/putr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvro8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pagk8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pagko8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/ptmr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/cmsy10.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/cmr10.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvbo8an.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/cmex10.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pncb8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pzdr.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/phvro8an.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pbkli8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> copying lib/matplotlib/mpl-data/fonts/afm/pplr8a.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/afm
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Times-BoldItalic.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-BoldOblique.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Bold.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Symbol.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-Oblique.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-BoldOblique.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Italic.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Helvetica-Bold.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/ZapfDingbats.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Courier.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Times-Roman.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-Bold.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/Courier-Oblique.afm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> copying lib/matplotlib/mpl-data/fonts/pdfcorefonts/readme.txt -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/pdfcorefonts
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXGeneralItalic.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz4Sym.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz4SymBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz2SymBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXNonUniIta.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraMono.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraIt.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXGeneral.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraBd.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmtt10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraMoBd.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraSeBd.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraBI.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz5Sym.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmsy10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz1SymBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz2Sym.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXGeneralBolIta.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmmi10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz3SymBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXGeneralBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz3Sym.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraMoIt.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmss10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmb10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXNonUniBolIta.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmr10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraSe.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXSiz1Sym.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/cmex10.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXNonUniBol.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/STIXNonUni.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> copying lib/matplotlib/mpl-data/fonts/ttf/VeraMoBI.ttf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/fonts/ttf
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_refresh.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_close.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/zoom_to_rect.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/subplots.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/filesave.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_up.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_zoom-out.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/forward.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/home.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/back.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_down.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_left.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/move.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_save_as.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_right.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/hand.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_zoom-in.xpm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/move.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/matplotlib.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/filesave.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/back.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/hand.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/home.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/zoom_to_rect.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/forward.svg -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/filesave.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/zoom_to_rect.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/subplots.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/matplotlib.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/back.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/move.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/home.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/forward.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/hand.png -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_right.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_up.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/filesave.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/hand.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_zoom-out.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_down.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/zoom_to_rect.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_refresh.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_left.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/forward.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_zoom-in.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_save_as.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/subplots.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/move.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/back.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/stock_close.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> copying lib/matplotlib/mpl-data/images/home.ppm -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/images
> creating build/lib.linux-x86_64-2.5/matplotlib/mpl-data/example
> copying lib/matplotlib/mpl-data/example/msft_nasdaq.npy -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/example
> copying lib/matplotlib/mpl-data/example/aapl.npy -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/example
> copying lib/matplotlib/mpl-data/example/goog.npy -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data/example
> copying lib/matplotlib/mpl-data/matplotlibrc -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> copying lib/matplotlib/mpl-data/matplotlib.conf -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> copying lib/matplotlib/mpl-data/lineprops.glade -> build/lib.linux-x86_64-2.5/matplotlib/mpl-data
> creating build/lib.linux-x86_64-2.5/matplotlib/backends/Matplotlib.nib
> copying lib/matplotlib/backends/Matplotlib.nib/info.nib -> build/lib.linux-x86_64-2.5/matplotlib/backends/Matplotlib.nib
> copying lib/matplotlib/backends/Matplotlib.nib/keyedobjects.nib -> build/lib.linux-x86_64-2.5/matplotlib/backends/Matplotlib.nib
> copying lib/matplotlib/backends/Matplotlib.nib/classes.nib -> build/lib.linux-x86_64-2.5/matplotlib/backends/Matplotlib.nib
> running build_ext
> building 'matplotlib.ft2font' extension
> creating build/temp.linux-x86_64-2.5
> creating build/temp.linux-x86_64-2.5/src
> creating build/temp.linux-x86_64-2.5/CXX
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c src/ft2font.cpp -o build/temp.linux-x86_64-2.5/src/ft2font.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c src/mplutils.cpp -o build/temp.linux-x86_64-2.5/src/mplutils.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c CXX/IndirectPythonInterface.cxx -o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c CXX/cxx_extensions.cxx -o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c CXX/cxxsupport.cxx -o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c CXX/cxxextensions.c -o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/ft2font.o build/temp.linux-x86_64-2.5/src/mplutils.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o -L/usr/local/lib -lfreetype -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/ft2font.so
> building 'matplotlib.ttconv' extension
> creating build/temp.linux-x86_64-2.5/ttconv
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/_ttconv.cpp -o build/temp.linux-x86_64-2.5/src/_ttconv.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c ttconv/pprdrv_tt.cpp -o build/temp.linux-x86_64-2.5/ttconv/pprdrv_tt.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c ttconv/pprdrv_tt2.cpp -o build/temp.linux-x86_64-2.5/ttconv/pprdrv_tt2.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c ttconv/ttutil.cpp -o build/temp.linux-x86_64-2.5/ttconv/ttutil.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/_ttconv.o build/temp.linux-x86_64-2.5/ttconv/pprdrv_tt.o build/temp.linux-x86_64-2.5/ttconv/pprdrv_tt2.o build/temp.linux-x86_64-2.5/ttconv/ttutil.o -L/usr/local/lib -o build/lib.linux-x86_64-2.5/matplotlib/ttconv.so
> building 'matplotlib._cntr' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/cntr.c -o build/temp.linux-x86_64-2.5/src/cntr.o
> gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/cntr.o -L/usr/local/lib -o build/lib.linux-x86_64-2.5/matplotlib/_cntr.so
> building 'matplotlib._delaunay' extension
> creating build/temp.linux-x86_64-2.5/lib
> creating build/temp.linux-x86_64-2.5/lib/matplotlib
> creating build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c lib/matplotlib/delaunay/_delaunay.cpp -o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/_delaunay.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c lib/matplotlib/delaunay/VoronoiDiagramGenerator.cpp -o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/VoronoiDiagramGenerator.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c lib/matplotlib/delaunay/delaunay_utils.cpp -o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/delaunay_utils.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c lib/matplotlib/delaunay/natneighbors.cpp -o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/natneighbors.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/_delaunay.o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/VoronoiDiagramGenerator.o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/delaunay_utils.o build/temp.linux-x86_64-2.5/lib/matplotlib/delaunay/natneighbors.o -L/usr/local/lib -o build/lib.linux-x86_64-2.5/matplotlib/_delaunay.so
> building 'matplotlib.nxutils' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.5 -c src/nxutils.c -o build/temp.linux-x86_64-2.5/src/nxutils.o
> gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/nxutils.o -L/usr/local/lib -o build/lib.linux-x86_64-2.5/matplotlib/nxutils.so
> building 'matplotlib._path' extension
> creating build/temp.linux-x86_64-2.5/agg24
> creating build/temp.linux-x86_64-2.5/agg24/src
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_curves.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_curves.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_bezier_arc.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_trans_affine.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_vcgen_stroke.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_stroke.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c src/agg_py_transforms.cpp -o build/temp.linux-x86_64-2.5/src/agg_py_transforms.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c src/path_cleanup.cpp -o build/temp.linux-x86_64-2.5/src/path_cleanup.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c src/path.cpp -o build/temp.linux-x86_64-2.5/src/path.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/agg24/src/agg_curves.o build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_stroke.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o build/temp.linux-x86_64-2.5/src/agg_py_transforms.o build/temp.linux-x86_64-2.5/src/path_cleanup.o build/temp.linux-x86_64-2.5/src/path.o -L/usr/local/lib -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/_path.so
> building 'matplotlib.backends._backend_agg' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -Isrc/freetype2 -Iagg24/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c agg24/src/agg_vcgen_dash.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_dash.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -Isrc/freetype2 -Iagg24/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c agg24/src/agg_image_filters.cpp -o build/temp.linux-x86_64-2.5/agg24/src/agg_image_filters.o
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -Isrc/freetype2 -Iagg24/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c src/backend_agg.cpp -o build/temp.linux-x86_64-2.5/src/backend_agg.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o build/temp.linux-x86_64-2.5/agg24/src/agg_curves.o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_dash.o build/temp.linux-x86_64-2.5/agg24/src/agg_vcgen_stroke.o build/temp.linux-x86_64-2.5/agg24/src/agg_image_filters.o build/temp.linux-x86_64-2.5/src/mplutils.o build/temp.linux-x86_64-2.5/src/agg_py_transforms.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o build/temp.linux-x86_64-2.5/src/backend_agg.o -L/usr/local/lib -L/usr/local/lib -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/backends/_backend_agg.so
> building 'matplotlib._image' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/include/python2.5 -c src/image.cpp -o build/temp.linux-x86_64-2.5/src/image.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/image.o build/temp.linux-x86_64-2.5/src/mplutils.o build/temp.linux-x86_64-2.5/agg24/src/agg_trans_affine.o build/temp.linux-x86_64-2.5/agg24/src/agg_image_filters.o build/temp.linux-x86_64-2.5/agg24/src/agg_bezier_arc.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o -L/usr/local/lib -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/_image.so
> building 'matplotlib._png' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -I. -I/usr/include/python2.5 -c src/_png.cpp -o build/temp.linux-x86_64-2.5/src/_png.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/_png.o build/temp.linux-x86_64-2.5/src/mplutils.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o -L/usr/local/lib -lpng -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/_png.so
> building 'matplotlib.backends._tkagg' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_ARRAY_API -I/usr/include/tcl8.4 -I/usr/include/tcl8.4 -I/usr/local/include -I/usr/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/lib/python2.5/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/tcl8.4/freetype2 -I/usr/include/tcl8.4/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -Isrc/freetype2 -Iagg24/include/freetype2 -I./freetype2 -I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2 -I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2 -I/usr/include/python2.5 -c src/_tkagg.cpp -o build/temp.linux-x86_64-2.5/src/_tkagg.o
> g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.5/src/agg_py_transforms.o build/temp.linux-x86_64-2.5/src/_tkagg.o build/temp.linux-x86_64-2.5/CXX/IndirectPythonInterface.o build/temp.linux-x86_64-2.5/CXX/cxx_extensions.o build/temp.linux-x86_64-2.5/CXX/cxxsupport.o build/temp.linux-x86_64-2.5/CXX/cxxextensions.o -L/usr/local/lib -L/usr/local/lib -ltk8.4 -ltcl8.4 -lstdc++ -lm -lfreetype -lz -lstdc++ -lm -o build/lib.linux-x86_64-2.5/matplotlib/backends/_tkagg.so
> running install_lib
> creating /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/cm.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/fontconfig_pattern.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/path.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/dates.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/axes.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/bezier.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/type1font.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/mlab.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/image.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/units.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/ft2font.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/pyplot.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/artist.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/afm.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/backend_bases.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/finance.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_png.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_path.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/hatch.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_pylab_helpers.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/mathtext.py -> /usr/lib/python2.5/site-packages/matplotlib
> creating /usr/lib/python2.5/site-packages/matplotlib/sphinxext
> copying build/lib.linux-x86_64-2.5/matplotlib/sphinxext/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/sphinxext
> copying build/lib.linux-x86_64-2.5/matplotlib/sphinxext/only_directives.py -> /usr/lib/python2.5/site-packages/matplotlib/sphinxext
> copying build/lib.linux-x86_64-2.5/matplotlib/sphinxext/mathmpl.py -> /usr/lib/python2.5/site-packages/matplotlib/sphinxext
> copying build/lib.linux-x86_64-2.5/matplotlib/sphinxext/plot_directive.py -> /usr/lib/python2.5/site-packages/matplotlib/sphinxext
> copying build/lib.linux-x86_64-2.5/matplotlib/windowing.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/legend.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/ticker.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/figure.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/table.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/texmanager.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/ttconv.so -> /usr/lib/python2.5/site-packages/matplotlib
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix/mlab
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/mlab/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix/mlab
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix/ma
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/ma/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix/ma
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix/linear_algebra
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/linear_algebra/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix/linear_algebra
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix/random_array
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/random_array/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix/random_array
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix
> creating /usr/lib/python2.5/site-packages/matplotlib/numerix/fft
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/fft/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix/fft
> copying build/lib.linux-x86_64-2.5/matplotlib/numerix/_sp_imports.py -> /usr/lib/python2.5/site-packages/matplotlib/numerix
> copying build/lib.linux-x86_64-2.5/matplotlib/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/transforms.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_image.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/contour.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_cm.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/colors.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/collections.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/nxutils.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/axis.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/cbook.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/text.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/quiver.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/blocking_input.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/lines.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/mpl.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/offsetbox.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/rcsetup.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/widgets.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/pylab.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/patches.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_delaunay.so -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/scale.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/tight_bbox.py -> /usr/lib/python2.5/site-packages/matplotlib
> creating /usr/lib/python2.5/site-packages/matplotlib/delaunay
> copying build/lib.linux-x86_64-2.5/matplotlib/delaunay/triangulate.py -> /usr/lib/python2.5/site-packages/matplotlib/delaunay
> copying build/lib.linux-x86_64-2.5/matplotlib/delaunay/interpolate.py -> /usr/lib/python2.5/site-packages/matplotlib/delaunay
> copying build/lib.linux-x86_64-2.5/matplotlib/delaunay/__init__.py -> /usr/lib/python2.5/site-packages/matplotlib/delaunay
> copying build/lib.linux-x86_64-2.5/matplotlib/delaunay/testfuncs.py -> /usr/lib/python2.5/site-packages/matplotlib/delaunay
> copying build/lib.linux-x86_64-2.5/matplotlib/colorbar.py -> /usr/lib/python2.5/site-packages/matplotlib
> copying build/lib.linux-x86_64-2.5/matplotlib/_cntr.so -> /usr...
 
[truncated message content]

On Thu, Jul 30, 2009 at 1:56 PM, Jae-Joon Lee<lee...@gm...> wrote:
>
> ps. Are we having a sprint during the scipy conference by the way? I
> may join remotely.
I'll definitely be there Sat and Sun, so having you join in remotely
would be great. I haven't organized any official topics yet, but we
have plenty to do so I think we'll just look at the skills and
interests of those joining live or virtually and hammer away.
JDH

Hello,
I recently committed a support for a curvelinear grid in the axes_grid
toolkit. What it does for you is to draw a ticks and grid appropriate
for a curvelinear coordinate system, as in the example below.
http://matplotlib.sourceforge.net/_images/demo_floating_axis1.png
The main motivation behind this work was to display astronomical
images with matplotlib. However, I included this in the axes_grid
toolkit hoping that this could be also useful in other fields.
The reason I'm posting this email is related to a possible refactoring
of the matplolib, that John once mentioned, to better support the
ticks and spines. To support the curvelinear grid, I had to create a
customized Axes class, and I believe that some of my effort overlaps
with the refactoring that John mentioned. In the linked document
below, I tried to describe the changes I made for this.
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/axislines.html
I guess some of my idea or implementation may be considered to be a
part of the refactoring (if it ever happens :) ). Or, at least, I hope
that the issues I had with mpl's current Axes implementation are
reflected in the refactoring efforts.
Well, I just wanted to toss around some ideas and hear what others think.
Regards,
-JJ
 ps. Are we having a sprint during the scipy conference by the way? I
may join remotely.

Sorry for reposting, but the original may have been overlooked since 
it was buried deep in a matplotlib-users thread.
Currently, `pyplot.rgrids` is returning tick lines instead of grid 
lines. My guess is that this is a typo, but there may be a compelling 
reason to return the tick lines. If it is a typo, here's a patch:
Index: lib/matplotlib/projections/polar.py
===================================================================
--- lib/matplotlib/projections/polar.py	(revision 7300)
+++ lib/matplotlib/projections/polar.py	(working copy)
@@ -397,7 +397,7 @@
 self._r_label2_position.clear().translate(angle, -self._rpad 
* rmax)
 for t in self.yaxis.get_ticklabels():
 t.update(kwargs)
- return self.yaxis.get_ticklines(), self.yaxis.get_ticklabels()
+ return self.yaxis.get_gridlines(), self.yaxis.get_ticklabels()
 set_rgrids.__doc__ = cbook.dedent(set_rgrids.__doc__) % kwdocd

Sorry I fell behind and did not get a release out earlier as I
intended. I am going to take another stab this weekend so we can have
something by scipy. Please commit anything you need to before the
release, and I will ask Michael to create the release branch tomorrow.
 There will still be ample time for testing and fixing stuff from the
release branch, but this will be done on the branch rather than the
trunk. Tentative schedule:
 * branch tomorrow
 * src candidate Sunday
 * win32 and osx binaries for testing monday
 * official release late next week
JDH

Him
On 30 Jul 2009, at 02:27, John Hunter wrote:
> Isn't this a bit backwards? The point of the GSOC project is to make
> the mathtext project available as a smaller, lighter, more widely
> accessible project. If it depends on mpl, what have we achieved
> except complexity? Don't we want the ft2font and png to be provided
> by mathtext, and let mpl depend on it to get the stuff there?
> Admittedly, mathtex may not be the right name (mpltext?) but
> conceptually it seems like we want the low level stuff in mathtex. Or
> am I missing your point here?
I should have made myself clearer. Mathtex will attempt to firstly 
import its own versions of FT2Font and friends. Should this fail it 
will then attempt to import those in matplotlib. So yes, mathtex still 
has all of the required dependencies, nothing has changed there.
This means that if you have matplotlib installed you can use/install 
mathtex without compiling a single C-code extension. It also means 
that when matplotlib wishes to install mathtex it only need bother 
with copying over .py files -- the same way it does for pytz.
> You can punt on the setup/dependency issue for now. In the branch,
> you can assume mathtex exists and is installed. We can worry about
> how to handle the setup and distribution issues once we have the
> package organization rationalized. A simple set of install
> instructions for developers with very explicit commands to check out
> the branch, install the deps, and test would help us test as you
> progress.
Okay, I'll revert to the previous way of doing so (cd'ing to the 
directory where mathtex is checked out and running setup.py there).
Regards, Freddie.

Hello,
I just compiled matplotlib using svn. Previously I was using a ubuntu package (version 0.98.3). I
decided to use the svn version to have mplot3d available.
Everything seem to work well but now when I start one of my python program that use matplotlib, I
have problem with the axes draw method (a problem that I had not with the version 0.98.3).
Here is the traceback.
---------------------------------------------------------------------------------------------------
Exception in Tkinter callback
Traceback (most recent call last):
 File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1417, in __call__
 return self.func(*args)
 File "./sg.py", line 1420, in <lambda>
 bInvEns = Tix.Button(bt,text='Calculer',command=lambda : self.CSInvEns(self.cfr,self.gffr))
 File "./sg.py", line 3267, in CSInvEns
 gffr.psaddData_m(u,xmin,xmax,pmin,pmax)
 File "./sg.py", line 3451, in psaddData_m
 self.psDraw(xmin,xmax,pmin,pmax)
 File "./sg.py", line 3526, in psDraw
 self.aps.draw()
TypeError: draw_wrapper() takes at least 2 arguments (1 given)
----------------------------------------------------------------------------------------------------
self.aps is an axes instance. I looked at the doc and effectively the draw method take two arguments
(the artist - which is self.aps - and the renderer - which I don't know what it is).
I suspect that prior to installing the svn version, with the 0.98.3 version, these two arguments
were given automatically to the draw method, but now it is no more the case.
As it could also be a bug (but I don't think so) I post it here. I join the log of the compilation
and the log of a test run (resp. build.out and run.out).
If you have any idea or comment, thank you in advance for sharing it with me.
Jonathan

On Wed, Jul 29, 2009 at 4:32 PM, Freddie Witherden<fr...@wi...> wrote:
> After thinking about the problem a little bit I have gone for the following
> solution. I added support for mathtex to use the wrappers provided by
> matplotlib for FT2Font and _png. It is likely we will want to keep them in
> sync anyway -- so that should not be an issue.
Isn't this a bit backwards? The point of the GSOC project is to make
the mathtext project available as a smaller, lighter, more widely
accessible project. If it depends on mpl, what have we achieved
except complexity? Don't we want the ft2font and png to be provided
by mathtext, and let mpl depend on it to get the stuff there?
Admittedly, mathtex may not be the right name (mpltext?) but
conceptually it seems like we want the low level stuff in mathtex. Or
am I missing your point here?
> However, I am having trouble working around the fact that mathtex is two
> levels deep (lib/mathtex/mathtex). I can either get the setup.py file to
> install either just the setup* stuff from mathtex or install mathtex as
> mathtex/mathtex. Not sure how to work around this.
You can punt on the setup/dependency issue for now. In the branch,
you can assume mathtex exists and is installed. We can worry about
how to handle the setup and distribution issues once we have the
package organization rationalized. A simple set of install
instructions for developers with very explicit commands to check out
the branch, install the deps, and test would help us test as you
progress.
JDH

On Wed, Jul 29, 2009 at 5:05 PM, Robert Kern<rob...@gm...> wrote:
> Furthermore, you could put numpy in there, too. Maybe even recipes for
> downloading and building the C dependencies for those who need it. Basically, by
> freeing yourself from the shackles of distutils, you can make the
> "new-to-Python-just-give-me-matplotlib" experience much less painful while
> improving the situation for downstream packagers like Linux distributions, EPD,
> and python(x,y) at the same time.
For linux, unix and os x src installs, this is imminently viable. We
already have a start on this in the mpl/releases dir to autofetch the
deps and build them, but this is for the lower level deps, like
freetype, png and zlib. We could easily extend the approach to pytz
and dateutil, and provide some enhancements (remove make, use python
instead, have some sort of configure file support). The bugaboo is
the win32 installer and OSX binary. If we don't build this stuff in,
suddenly the dependency list grows from "just install numpy" to
"install pytz, dateutil, numpy and mathtext" which is a very different
picture. As I alluded to in my earlier post, I assume there is some
way to build smart windows installers (eg along the lines of the ETS
install tool or native win32 solutions) but this is a question of
manpower. None of our core developers are primarily win32 users, and
we often struggle to get anyone to even test a win32 release
candidate, much less do the heavy lifting to build a smart installer.
The ETS and PythonXY solutions have gotten so good that maybe I should
just give up worrying making life easy for win32 users, since these
solutions already satisfy the needs of someone who wants it to work
with one or two clicks. I already aggressively point them to these
solutions on our installing page. But windows users still make up
about half of our known installations, so I don't want to be cavalier
in dismissing the importance of making it easy for them.

On 2009年07月29日 15:29, Robert Kern wrote:
> On 2009年07月29日 08:17, John Hunter wrote:
>> On Wed, Jul 29, 2009 at 7:52 AM, Michael Droettboom<md...@st...> wrote:
>>> I think we need (at least as a transitional stopgap) a single "python
>>> setup.py install" to install both matplotlib and mathtex. Once
>>> distributions catch up (which could take more than a year, depending on
>>> cycles), we can consider being more loosely coupled.
>>>
>>> There are already examples of installing subpackages from matplotlib
>>> (pytz and dateutil) for example, and each of the extensions
>>> (_backend_agg etc.) have examples in setupext.py showing how to
>>> dynamically add extensions and packages to the list of things that
>>> matplotlib's setup.py will install and build. Are there fundamental
>>> differences in how that works vs. how mathtex needs to work that is a
>>> stumbling block? I must admit I haven't thought it all the way through,
>>> but I'm surprised that the existing examples there don't provide a
>>> template for how to deal with mathtex. That said, I know that distutils
>>> can be rather, um, labyrinthine.
>> I second this. I would like to see the new mathtext (and png and
>> freetype wrappers as necessary, possibly in mathtext) live in the
>> matplotlib trunk under lib, the same place we put pytz and dateutil.
>> It can have its own setup and release cycle, but I think it would make
>> matters simpler to have it there. If there is compelling reason to
>> have it live in a separate svn repo, we can always grab it externally,
>> as scipy does for our sphinx extensions.
>
> Instead of using the matplotlib package as a catch-all for these external
> packages, could you instead keep them all nominally separate and release a
> tarball that includes all of them side by side? You can even have an
> installation script that will run the setups for each. Even better, this
> installation script wouldn't use distutils, so you don't have to hack all of
> this "optional package" stuff into it.
Furthermore, you could put numpy in there, too. Maybe even recipes for 
downloading and building the C dependencies for those who need it. Basically, by 
freeing yourself from the shackles of distutils, you can make the 
"new-to-Python-just-give-me-matplotlib" experience much less painful while 
improving the situation for downstream packagers like Linux distributions, EPD, 
and python(x,y) at the same time.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

> I second this. I would like to see the new mathtext (and png and
> freetype wrappers as necessary, possibly in mathtext) live in the
> matplotlib trunk under lib, the same place we put pytz and dateutil.
> It can have its own setup and release cycle, but I think it would make
> matters simpler to have it there. If there is compelling reason to
> have it live in a separate svn repo, we can always grab it externally,
> as scipy does for our sphinx extensions.
>
> We can use the mpl configure setup.cfg to either
> no-install/force-install/auto-install as we do for these other
> packages. This works fine at build time, but is a little more
> complicated when distributing binaries. Eg for win32 binaries, we
> currently force these packages on, which is sometimes a problem. We
> might be able to be a little smarter about building win32 installers,
> so the user can select which subpackages to install, but I am not
> holding my breath on this one.
After thinking about the problem a little bit I have gone for the following 
solution. I added support for mathtex to use the wrappers provided by 
matplotlib for FT2Font and _png. It is likely we will want to keep them in 
sync anyway -- so that should not be an issue.
However, I am having trouble working around the fact that mathtex is two 
levels deep (lib/mathtex/mathtex). I can either get the setup.py file to 
install either just the setup* stuff from mathtex or install mathtex as 
mathtex/mathtex. Not sure how to work around this.
I have committed what I have thus far to the branch.
Regards, Freddie.

On 2009年07月29日 08:17, John Hunter wrote:
> On Wed, Jul 29, 2009 at 7:52 AM, Michael Droettboom<md...@st...> wrote:
>> I think we need (at least as a transitional stopgap) a single "python
>> setup.py install" to install both matplotlib and mathtex. Once
>> distributions catch up (which could take more than a year, depending on
>> cycles), we can consider being more loosely coupled.
>>
>> There are already examples of installing subpackages from matplotlib
>> (pytz and dateutil) for example, and each of the extensions
>> (_backend_agg etc.) have examples in setupext.py showing how to
>> dynamically add extensions and packages to the list of things that
>> matplotlib's setup.py will install and build. Are there fundamental
>> differences in how that works vs. how mathtex needs to work that is a
>> stumbling block? I must admit I haven't thought it all the way through,
>> but I'm surprised that the existing examples there don't provide a
>> template for how to deal with mathtex. That said, I know that distutils
>> can be rather, um, labyrinthine.
>
> I second this. I would like to see the new mathtext (and png and
> freetype wrappers as necessary, possibly in mathtext) live in the
> matplotlib trunk under lib, the same place we put pytz and dateutil.
> It can have its own setup and release cycle, but I think it would make
> matters simpler to have it there. If there is compelling reason to
> have it live in a separate svn repo, we can always grab it externally,
> as scipy does for our sphinx extensions.
Instead of using the matplotlib package as a catch-all for these external 
packages, could you instead keep them all nominally separate and release a 
tarball that includes all of them side by side? You can even have an 
installation script that will run the setups for each. Even better, this 
installation script wouldn't use distutils, so you don't have to hack all of 
this "optional package" stuff into it.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Wed, Jul 29, 2009 at 7:52 AM, Michael Droettboom<md...@st...> wrote:
> I think we need (at least as a transitional stopgap) a single "python
> setup.py install" to install both matplotlib and mathtex. Once
> distributions catch up (which could take more than a year, depending on
> cycles), we can consider being more loosely coupled.
>
> There are already examples of installing subpackages from matplotlib
> (pytz and dateutil) for example, and each of the extensions
> (_backend_agg etc.) have examples in setupext.py showing how to
> dynamically add extensions and packages to the list of things that
> matplotlib's setup.py will install and build. Are there fundamental
> differences in how that works vs. how mathtex needs to work that is a
> stumbling block? I must admit I haven't thought it all the way through,
> but I'm surprised that the existing examples there don't provide a
> template for how to deal with mathtex. That said, I know that distutils
> can be rather, um, labyrinthine.
I second this. I would like to see the new mathtext (and png and
freetype wrappers as necessary, possibly in mathtext) live in the
matplotlib trunk under lib, the same place we put pytz and dateutil.
It can have its own setup and release cycle, but I think it would make
matters simpler to have it there. If there is compelling reason to
have it live in a separate svn repo, we can always grab it externally,
as scipy does for our sphinx extensions.
We can use the mpl configure setup.cfg to either
no-install/force-install/auto-install as we do for these other
packages. This works fine at build time, but is a little more
complicated when distributing binaries. Eg for win32 binaries, we
currently force these packages on, which is sometimes a problem. We
might be able to be a little smarter about building win32 installers,
so the user can select which subpackages to install, but I am not
holding my breath on this one.
I am unwilling to rely on any setuptools solutions at this point, as
I've always viewed them with suspicion (maybe because I rarely found
easy_install to be easy) and the setuptools community is in a bit of
disarray, with the lead developer unable to adequately maintain the
package and unwilling to let those who want to take it over do so
since he feels they are not qualified, so a fork is in progress:
 http://www.mail-archive.com/dis...@py.../msg08111.html
JDH

I think we need (at least as a transitional stopgap) a single "python 
setup.py install" to install both matplotlib and mathtex. Once 
distributions catch up (which could take more than a year, depending on 
cycles), we can consider being more loosely coupled.
There are already examples of installing subpackages from matplotlib 
(pytz and dateutil) for example, and each of the extensions 
(_backend_agg etc.) have examples in setupext.py showing how to 
dynamically add extensions and packages to the list of things that 
matplotlib's setup.py will install and build. Are there fundamental 
differences in how that works vs. how mathtex needs to work that is a 
stumbling block? I must admit I haven't thought it all the way through, 
but I'm surprised that the existing examples there don't provide a 
template for how to deal with mathtex. That said, I know that distutils 
can be rather, um, labyrinthine.
Cheers,
Mike
Freddie Witherden wrote:
> Hi,
>
> I was thinking about the problem of including mathtex in matplotlib earlier 
> and came up with an alternative means of 'solving' the problem.
>
> Instead of hacking setup.py to install mathtex on the behalf of matplotlib it 
> may be easier to leave it up to the user/packager to install mathtex.
>
> While simplifying the code (not as many changed are need to the setup files) it 
> also eliminates the problems associated with one package installing another 
> package (matplotlib installing mathtex).
>
> This could be done either through ones distribution package manger, standalone 
> (getting the mathtex source) or just by following the instructions in 
> lib/mathtex/INSTALL. (Checking out matplotlib also checks out the mathtex 
> source into lib/mathtex.)
>
> However, I am interested if this solution is acceptable to the matplotlib 
> developers.
>
> It may also be worth pointing out that mathtex is an optional dependency of 
> matplotlib and is not required for matplotlib to function.
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> 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

Ray Speth wrote:
> I believe I have found a simple change that improves the rendering speed 
> of quiver plots, which can be quite slow for large vector fields. Based 
> on some profiling, the problem appears to stem from the use of numpy's 
> MaskedArrays in PolyCollection.set_verts. If I add the following line to 
> the top of the PolyCollection.set_verts function in collections.py:
> 
> 	verts = np.asarray(verts)
> 
> I find that quiver plots are drawn about 3 times as quickly, going from 
> 2.6 seconds for a 125x125 field to 0.65 seconds. This does not seem to 
> break the use of MaskedArrays as inputs, and masked regions are still 
> hidden in the final plot. I do not know if this has any adverse effects 
> in other classes that inherit from PolyCollection.
I made a change in PolyCollection.set_verts that has the effect of your 
suggestion but without affecting masked argument inputs in general. I 
also made a bunch of other changes in quiver.py to speed things up with 
or without masked inputs, but their net effect is minimal in practice; 
your suggestion was the key. I get a factor of 2, not 3; I think this 
must be a difference in our machines, though. In any case, I'm glad you 
found the time sink.
Eric
> 
> Using:
> python 2.6.2 on Windows XP
> numpy 1.3.0
> matplotlib 0.98.5.3, Qt4Agg backend
> 
> I do not know why iterating over MaskedArrays is so slow, but perhaps 
> this information can be used to speed up some other functions as well.
> 
> Ray Speth
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
I was thinking about the problem of including mathtex in matplotlib earlier 
and came up with an alternative means of 'solving' the problem.
Instead of hacking setup.py to install mathtex on the behalf of matplotlib it 
may be easier to leave it up to the user/packager to install mathtex.
While simplifying the code (not as many changed are need to the setup files) it 
also eliminates the problems associated with one package installing another 
package (matplotlib installing mathtex).
This could be done either through ones distribution package manger, standalone 
(getting the mathtex source) or just by following the instructions in 
lib/mathtex/INSTALL. (Checking out matplotlib also checks out the mathtex 
source into lib/mathtex.)
However, I am interested if this solution is acceptable to the matplotlib 
developers.
It may also be worth pointing out that mathtex is an optional dependency of 
matplotlib and is not required for matplotlib to function.
Regards, Freddie.