matplotlib-devel Mailing List for matplotlib (Page 3)

Fernando Perez wrote:
> Hi all,
> 
> here's a small patch for two little things I saw today:
> 
> 1. The new mathtext has some unicode in it and on my system, python2.5
> was throwing a syntax error due to the lack of an encoding
> declaration. I just stuck utf-8 though I don't know if that's really
> corrrect. Since the complaint was about characters in a comment it
> doesn't matter too much, but it still might be a good idea to do the
> right thing, so someone who actually knows should check what the right
> value is.
UTF-8 is my default system encoding, so I didn't catch this. I just 
fixed the comment (the unicode character is unnecessary to get the point 
across and wasonly in there due to a cut-and-paste accident anyway).
> 2. Move a simple version check from runtime to class declaration time
> in the cairo backend. While this causes a repeated line, the code is
> small enough that it seems cleaner not to pay the version check on
> every method call.
I have committed this patch to SVN.
Cheers,
Mike
> 
> ------------------------------------------------------------------------
> 
> Index: lib/matplotlib/mathtext.py
> ===================================================================
> --- lib/matplotlib/mathtext.py	(revision 3715)
> +++ lib/matplotlib/mathtext.py	(working copy)
> @@ -1,3 +1,4 @@
> +# -*- coding: utf-8 -*-
> r"""
> 
> OVERVIEW
> Index: lib/matplotlib/backends/backend_gtkcairo.py
> ===================================================================
> --- lib/matplotlib/backends/backend_gtkcairo.py	(revision 3715)
> +++ lib/matplotlib/backends/backend_gtkcairo.py	(working copy)
> @@ -29,12 +29,16 @@
> 
> 
> class RendererGTKCairo (backend_cairo.RendererCairo):
> - def set_pixmap (self, pixmap):
> - if gtk.pygtk_version >= (2,7,0):
> + # Do the version check at class declaration time, so we don't pay for it on
> + # every invocation of the set_pixmap method.
> + if gtk.pygtk_version >= (2,7,0):
> + def set_pixmap (self, pixmap):
> self.ctx = pixmap.cairo_create()
> - else:
> + self.ctx.save() # restore, save - when call new_gc()
> + else:
> + def set_pixmap (self, pixmap):
> self.ctx = cairo.gtk.gdk_cairo_create (pixmap)
> - self.ctx.save() # restore, save - when call new_gc()
> + self.ctx.save() # restore, save - when call new_gc()
> 
> 
> class FigureCanvasGTKCairo(FigureCanvasGTK):
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,
here's a small patch for two little things I saw today:
1. The new mathtext has some unicode in it and on my system, python2.5
was throwing a syntax error due to the lack of an encoding
declaration. I just stuck utf-8 though I don't know if that's really
corrrect. Since the complaint was about characters in a comment it
doesn't matter too much, but it still might be a good idea to do the
right thing, so someone who actually knows should check what the right
value is.
2. Move a simple version check from runtime to class declaration time
in the cairo backend. While this causes a repeated line, the code is
small enough that it seems cleaner not to pay the version check on
every method call.
Cheers,
f

Mike,
I apologize for not reading through your script completely to test, but 
does this re-write the __init__.py files so that they don't declare 
namespace packages using pkg_resources? 
If you aren't doing this, then you still won't get to the time savings 
Fernando and I did because a significant part of the overhead was in 
setuptools/pkg_resources declaring namespace packages and importing from 
them. In fact, in Fernando's small test script using Traits, there were 
over 5,000 calls(!!!) to pkg_resources even when we'd de-eggified, but 
not de-package-namespace-ified.
-- Dave
Michael McLay wrote:
> The attached script creates an enthought packages out of enthought
> eggs. It uses symbolic links so it won't work on Windows and the eggs
> need to be kept on the filesystem. I'll rework it to copy the trees
> instead of just setting up symbolic links.
>
> On 8/18/07, Fernando Perez <fpe...@gm...> wrote:
> 
>> On 8/16/07, Eric Firing <ef...@ha...> wrote:
>> 
>>> So, 10% slower with backend_agg, 18% slower with backend_svg. It's not
>>> devastating, but it's not so great, either.
>>>
>>> 
>>>> Those results look fine to me. I dont know what has changed since we last
>>>> discussed this, but when Eric brought up the speed issue I remember the
>>>> traited config was significantly slower at that time. Maybe this is very good
>>>> news!
>>>> 
>>> Maybe there is some sensitivity to machine architecture; my tests were
>>> on a Lenovo T60 laptop, Core2 at 2 GHz.
>>>
>>> For Fernando's simple_plot, using /usr/bin/time, I get:
>>> 0.53user 0.11system 0:00.66elapsed without traits
>>> 0.66user 0.21system 0:00.89elapsed with traits
>>>
>>> (The figures are quite repeatable; numbers above are representative. CPU
>>> is 98% in both cases.)
>>>
>>> So the total time for this very simple plot (which makes it something of
>>> a worst case) is more than 30% longer with traits than without, implying
>>> that the startup time increase is even larger as a percentage. One
>>> might argue that the difference of 0.23 seconds doesn't matter, but I
>>> think it is still worth considering. Maybe it can be beaten down to a
>>> small fraction of that.
>>> 
>> Here's some interesting info. I'm sitting here with Dave Peterson,
>> from Enthought, and we've done a bunch of profiling that pointed to
>> setuptools, not Traits, being the culprit for the time increase.
>> We've now just done an install of Traits *without* any setuptools
>> (right now that requires manual surgery, but later it can be done
>> automatically if needed). Here are the resulting times:
>>
>> # Using traits
>>
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> *** Using Traits!!!
>> 1.844u 0.212s 0:02.13 96.2% 0+0k 0+0io 0pf+0w
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> *** Using Traits!!!
>> 1.840u 0.216s 0:02.58 79.4% 0+0k 0+0io 0pf+0w
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> *** Using Traits!!!
>> 1.836u 0.196s 0:02.12 95.2% 0+0k 0+0io 0pf+0w
>>
>> # NOT Using traits
>>
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> 2.200u 0.280s 0:02.67 92.8% 0+0k 0+0io 0pf+0w
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> 2.248u 0.220s 0:02.74 89.7% 0+0k 0+0io 0pf+0w
>> maqroll[mpl-traits-debug]> time ./simple_plot.py
>> 2.216u 0.244s 0:02.72 90.0% 0+0k 0+0io 0pf+0w
>>
>>
>> As you'll notice, the traits times are *lower*. This is what my gut
>> told me, since I know how tight the traits code is. The point is that
>> traits can actually give you a performance *benefit*, not a cost. The
>> problem is with setuptools, which goes ballistic on the filesystem at
>> init time. The profiles I sent earlier have already all the
>> information on that, if you use kcachegrind to see it (that's how Dave
>> and I pinned it down).
>>
>> This hopefully settles the argument on the performance side. We'll
>> leave the final decision up to you guys, obviously. For IPython, this
>> settles the matter and we're going with traits, with setuptools banned
>> til further notice from ipython.
>>
>> Cheers,
>>
>> f
>> 

Hi all,
On 8/16/07, Eric Firing <ef...@ha...> wrote:
> So, 10% slower with backend_agg, 18% slower with backend_svg. It's not
> devastating, but it's not so great, either.
>
> > Those results look fine to me. I dont know what has changed since we last
> > discussed this, but when Eric brought up the speed issue I remember the
> > traited config was significantly slower at that time. Maybe this is very good
> > news!
> >
> Maybe there is some sensitivity to machine architecture; my tests were
> on a Lenovo T60 laptop, Core2 at 2 GHz.
>
> For Fernando's simple_plot, using /usr/bin/time, I get:
> 0.53user 0.11system 0:00.66elapsed without traits
> 0.66user 0.21system 0:00.89elapsed with traits
>
> (The figures are quite repeatable; numbers above are representative. CPU
> is 98% in both cases.)
>
> So the total time for this very simple plot (which makes it something of
> a worst case) is more than 30% longer with traits than without, implying
> that the startup time increase is even larger as a percentage. One
> might argue that the difference of 0.23 seconds doesn't matter, but I
> think it is still worth considering. Maybe it can be beaten down to a
> small fraction of that.
Here's some interesting info. I'm sitting here with Dave Peterson,
from Enthought, and we've done a bunch of profiling that pointed to
setuptools, not Traits, being the culprit for the time increase.
We've now just done an install of Traits *without* any setuptools
(right now that requires manual surgery, but later it can be done
automatically if needed). Here are the resulting times:
# Using traits
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.844u 0.212s 0:02.13 96.2% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.840u 0.216s 0:02.58 79.4% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
*** Using Traits!!!
1.836u 0.196s 0:02.12 95.2% 0+0k 0+0io 0pf+0w
# NOT Using traits
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.200u 0.280s 0:02.67 92.8% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.248u 0.220s 0:02.74 89.7% 0+0k 0+0io 0pf+0w
maqroll[mpl-traits-debug]> time ./simple_plot.py
2.216u 0.244s 0:02.72 90.0% 0+0k 0+0io 0pf+0w
As you'll notice, the traits times are *lower*. This is what my gut
told me, since I know how tight the traits code is. The point is that
traits can actually give you a performance *benefit*, not a cost. The
problem is with setuptools, which goes ballistic on the filesystem at
init time. The profiles I sent earlier have already all the
information on that, if you use kcachegrind to see it (that's how Dave
and I pinned it down).
This hopefully settles the argument on the performance side. We'll
leave the final decision up to you guys, obviously. For IPython, this
settles the matter and we're going with traits, with setuptools banned
til further notice from ipython.
Cheers,
f

On Friday 17 August 2007 01:35:32 pm william ratcliff wrote:
> A simple question--if you add traits into matplotlib, will people still
> be able to build executables? I remember reports of py2exe having
> problems with traits.
Is this what you are referring to? 
https://svn.enthought.com/enthought/ticket/877

I have a question regarding the plots that are generated in Matplotlib
I was wondering if Matplotlib does autoscaling as well as makes sure
that the number of samples of data to pixels ratio is always an
integer. This is important when you zoom into the plot or readjust
the plot because then it readjusts the axis to fit the plot. This
ensures that data is accurate on the plot and data is not lost. It
also is an important feature when doing Signals processing and looking
at FFT's and Spectrograms.
I was also wondering if Matplotlib decimates the data
Thanks

 A simple question--if you add traits into matplotlib, will people still
 be able to build executables? I remember reports of py2exe having
 problems with traits.
 Cheers,
 William
On 8/17/07, Michael Droettboom <md...@st...> wrote:
>
> Thanks for fixing that. I haven't been running with the new traits config
> stuff, so I didn't catch that my new parameters weren't ported over.
>
> Cheers,
> Mike
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Thanks for fixing that. I haven't been running with the new traits config stuff, so I didn't catch that my new parameters weren't ported over.
Cheers,
Mike

Darren Dale wrote:
> On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:
>> On 8/16/07, Darren Dale <dd...@co...> wrote:
>>> On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
>>>> On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
>>>>> On 8/16/07, Eric Firing <ef...@ha...> wrote:
>>>>>> Fernando,
>>>>>>
>>>>>> Thanks for taking the opportunity of checking into this now. I
>>>>>> have to pass the buck, though--the bug you ran into looks like the
>>>>>> intersection between Mike's extensive mathtext work and Darren's
>>>>>> experimental replacement rc system, and apart from the testing you
>>>>>> refer to (prior to much of Mike's work) I have not dealt with
>>>>>> either of these areas.
>>>>> OK, understood. No worries.
>>>>>
>>>>> I'm rebuilding to SVN from August 1st, which is when this
>>>>> conversation started. That might do the trick and let us work here. 
>>>>> I'll pester again for help if I get stuck.
>>>> Eric is correct. I have to run in a minute, but I'll update the config
>>>> module early this evening to include Mikes recent changes.
>>> Fixed in svn 3711. gotta run!
>> Mmh, I'm afraid not:
> 
> Sorry, it should be fixed now. backend_driver.py runs all tests without any 
> failures for me, using svn 3713. Here are my results on my computer at home, 
> with the traited config disabled:
> 
> Backend Agg took 1.82 minutes to complete
> template ratio 1.417, template residual 0.537
> Backend PS took 1.64 minutes to complete
> template ratio 1.275, template residual 0.355
> Backend Template took 1.29 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend SVG took 1.69 minutes to complete
> template ratio 1.313, template residual 0.403
> 
> and with the traited config enabled:
> 
> Backend Agg took 1.98 minutes to complete
> template ratio 1.412, template residual 0.578
> Backend PS took 1.95 minutes to complete
> template ratio 1.388, template residual 0.545
> Backend Template took 1.41 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend SVG took 1.72 minutes to complete
> template ratio 1.226, template residual 0.318
> 
> That doesnt look too bad, compared to Eric's results. This is using a fresh 
> traits installation, installed today with:
> 
> sudo easy_install -f \ 
> http://code.enthought.com/enstaller/eggs/source "enthought.traits < 3.0a"
> 
> I dont know where to get the new eggs.
> 
> 
> I also tested it on my computer at work, which is 64bit, 4 processors, lots of 
> ram, and SATA disks. Here are the results with traited config disabled:
> 
> Backend Agg took 0.99 minutes to complete
> template ratio 1.639, template residual 0.386
> Backend PS took 0.82 minutes to complete
> template ratio 1.364, template residual 0.220
> Backend Template took 0.60 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend SVG took 0.77 minutes to complete
> template ratio 1.273, template residual 0.165
> 
> Here are the results with traited config enabled:
> 
> Backend Agg took 1.10 minutes to complete
> template ratio 1.463, template residual 0.346
> Backend PS took 0.97 minutes to complete
> template ratio 1.297, template residual 0.222
> Backend Template took 0.75 minutes to complete
> template ratio 1.000, template residual 0.000
> Backend SVG took 0.91 minutes to complete
> template ratio 1.220, template residual 0.165
> 
So, 10% slower with backend_agg, 18% slower with backend_svg. It's not 
devastating, but it's not so great, either.
> Those results look fine to me. I dont know what has changed since we last 
> discussed this, but when Eric brought up the speed issue I remember the 
> traited config was significantly slower at that time. Maybe this is very good 
> news!
> 
Maybe there is some sensitivity to machine architecture; my tests were 
on a Lenovo T60 laptop, Core2 at 2 GHz.
For Fernando's simple_plot, using /usr/bin/time, I get:
0.53user 0.11system 0:00.66elapsed without traits
0.66user 0.21system 0:00.89elapsed with traits
(The figures are quite repeatable; numbers above are representative. CPU 
is 98% in both cases.)
So the total time for this very simple plot (which makes it something of 
a worst case) is more than 30% longer with traits than without, implying 
that the startup time increase is even larger as a percentage. One 
might argue that the difference of 0.23 seconds doesn't matter, but I 
think it is still worth considering. Maybe it can be beaten down to a 
small fraction of that.
Other major chunks of the startup time are simply importing numpy and 
pylab. I don't know how much improvement is possible; maybe not much. 
I have already killed the biggest single contribution I could find, 
which was generation of the global FontManager instance. Now it is read 
from a pickle.
Eric
> Darren

On Thursday 16 August 2007 7:20:57 pm Bryce Hendrix wrote:
> Darren Dale wrote:
> > On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:
> >
> > ...
> >
> > Those results look fine to me. I dont know what has changed since we last
> > discussed this, but when Eric brought up the speed issue I remember the
> > traited config was significantly slower at that time. Maybe this is very
> > good news!
>
> A lot of work has gone in to reducing the dependency on wx, perhaps
> thats the cause for the improvement? Did you notice wx being imported
> still?
The only enthought packages that are installed on my machines are etsconfig 
and traits.
Darren

On Thursday 16 August 2007 5:25:47 pm Fernando Perez wrote:
> On 8/16/07, Darren Dale <dd...@co...> wrote:
> > On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
> > > On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
> > > > On 8/16/07, Eric Firing <ef...@ha...> wrote:
> > > > > Fernando,
> > > > >
> > > > > Thanks for taking the opportunity of checking into this now. I
> > > > > have to pass the buck, though--the bug you ran into looks like the
> > > > > intersection between Mike's extensive mathtext work and Darren's
> > > > > experimental replacement rc system, and apart from the testing you
> > > > > refer to (prior to much of Mike's work) I have not dealt with
> > > > > either of these areas.
> > > >
> > > > OK, understood. No worries.
> > > >
> > > > I'm rebuilding to SVN from August 1st, which is when this
> > > > conversation started. That might do the trick and let us work here. 
> > > > I'll pester again for help if I get stuck.
> > >
> > > Eric is correct. I have to run in a minute, but I'll update the config
> > > module early this evening to include Mikes recent changes.
> >
> > Fixed in svn 3711. gotta run!
>
> Mmh, I'm afraid not:
Sorry, it should be fixed now. backend_driver.py runs all tests without any 
failures for me, using svn 3713. Here are my results on my computer at home, 
with the traited config disabled:
Backend Agg took 1.82 minutes to complete
 template ratio 1.417, template residual 0.537
Backend PS took 1.64 minutes to complete
 template ratio 1.275, template residual 0.355
Backend Template took 1.29 minutes to complete
 template ratio 1.000, template residual 0.000
Backend SVG took 1.69 minutes to complete
 template ratio 1.313, template residual 0.403
and with the traited config enabled:
Backend Agg took 1.98 minutes to complete
 template ratio 1.412, template residual 0.578
Backend PS took 1.95 minutes to complete
 template ratio 1.388, template residual 0.545
Backend Template took 1.41 minutes to complete
 template ratio 1.000, template residual 0.000
Backend SVG took 1.72 minutes to complete
 template ratio 1.226, template residual 0.318
That doesnt look too bad, compared to Eric's results. This is using a fresh 
traits installation, installed today with:
sudo easy_install -f \ 
http://code.enthought.com/enstaller/eggs/source "enthought.traits < 3.0a"
I dont know where to get the new eggs.
I also tested it on my computer at work, which is 64bit, 4 processors, lots of 
ram, and SATA disks. Here are the results with traited config disabled:
Backend Agg took 0.99 minutes to complete
 template ratio 1.639, template residual 0.386
Backend PS took 0.82 minutes to complete
 template ratio 1.364, template residual 0.220
Backend Template took 0.60 minutes to complete
 template ratio 1.000, template residual 0.000
Backend SVG took 0.77 minutes to complete
 template ratio 1.273, template residual 0.165
Here are the results with traited config enabled:
Backend Agg took 1.10 minutes to complete
 template ratio 1.463, template residual 0.346
Backend PS took 0.97 minutes to complete
 template ratio 1.297, template residual 0.222
Backend Template took 0.75 minutes to complete
 template ratio 1.000, template residual 0.000
Backend SVG took 0.91 minutes to complete
 template ratio 1.220, template residual 0.165
Those results look fine to me. I dont know what has changed since we last 
discussed this, but when Eric brought up the speed issue I remember the 
traited config was significantly slower at that time. Maybe this is very good 
news!
Darren

[ Resending, attachment was too big ]
Hi all,
On 8/16/07, Darren Dale <dd...@co...> wrote:
> Fixed in svn 3711. gotta run!
Thanks, the r3712 did it. Here's some info. This little test:
maqroll[config]> cat simple_plot.py
#!/usr/bin/env python
"""
Example: simple line plot.
Show how to make and save a simple line plot with labels, title and grid
"""
from pylab import *
plot([1,2,3])
title("A simple plot")
xlabel("the x axis")
ylabel("the y axis")
savefig('simple_plot')
######## EOF
Produces the attached kcachegrind profiles when run with lsprofcalltree.
As far as I can see, the traits code is directly not a huge problem.
But it does seem to pull in:
- A lot of WX stuff
- pkg_resources calls that generate enormous amounts of filesystem
activity, as well as a lot of regular expression calls (probably in
compiling search patterns).
I have a talk to give now, but I've attached the kcachegrind logs so
others can play with this. Those who know Traits may be able to
extract more info out of this.
Cheers,
f
ps - We can move this to enthought-dev if you prefer, to cut on the x-posting.

On 8/16/07, Darren Dale <dd...@co...> wrote:
> On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
> > On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
> > > On 8/16/07, Eric Firing <ef...@ha...> wrote:
> > > > Fernando,
> > > >
> > > > Thanks for taking the opportunity of checking into this now. I have to
> > > > pass the buck, though--the bug you ran into looks like the intersection
> > > > between Mike's extensive mathtext work and Darren's experimental
> > > > replacement rc system, and apart from the testing you refer to (prior
> > > > to much of Mike's work) I have not dealt with either of these areas.
> > >
> > > OK, understood. No worries.
> > >
> > > I'm rebuilding to SVN from August 1st, which is when this conversation
> > > started. That might do the trick and let us work here. I'll pester
> > > again for help if I get stuck.
> >
> > Eric is correct. I have to run in a minute, but I'll update the config
> > module early this evening to include Mikes recent changes.
>
> Fixed in svn 3711. gotta run!
Mmh, I'm afraid not:
maqroll[config]> cat simple_plot.py
#!/usr/bin/env python
from pylab import plot, savefig
plot([1,2,3])
savefig('simple_plot')
maqroll[config]> python simple_plot.py
USING TRAITS!!!
Traceback (most recent call last):
 File "simple_plot.py", line 4, in <module>
 plot([1,2,3])
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 2061, in plot
 b = ishold()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 888, in ishold
 return gca().ishold()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 834, in gca
 ax = gcf().gca(**kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 722, in gca
 return self.add_subplot(111, **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 542, in add_subplot
 a = Subplot(self, *args, **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 5157, in __init__
 self.figW, self.figH], **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 507, in __init__
 self._init_axis()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 545, in _init_axis
 self.xaxis = maxis.XAxis(self)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 512, in __init__
 self.label = self._get_label()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 990, in _get_label
 horizontalalignment='center',
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 178, in __init__
 self.set_markup(markup)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 780, in set_markup
 self._markup = rcParams['text.markup']
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
line 437, in __getitem__
 return getattr(obj, attr)
AttributeError: 'str' object has no attribute 'markup'
This is with r3711
Cheers,
f

On Thursday 16 August 2007 03:33:37 pm Darren Dale wrote:
> On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
> > On 8/16/07, Eric Firing <ef...@ha...> wrote:
> > > Fernando,
> > >
> > > Thanks for taking the opportunity of checking into this now. I have to
> > > pass the buck, though--the bug you ran into looks like the intersection
> > > between Mike's extensive mathtext work and Darren's experimental
> > > replacement rc system, and apart from the testing you refer to (prior
> > > to much of Mike's work) I have not dealt with either of these areas.
> >
> > OK, understood. No worries.
> >
> > I'm rebuilding to SVN from August 1st, which is when this conversation
> > started. That might do the trick and let us work here. I'll pester
> > again for help if I get stuck.
>
> Eric is correct. I have to run in a minute, but I'll update the config
> module early this evening to include Mikes recent changes.
Fixed in svn 3711. gotta run!

On Thursday 16 August 2007 03:15:39 pm Fernando Perez wrote:
> On 8/16/07, Eric Firing <ef...@ha...> wrote:
> > Fernando,
> >
> > Thanks for taking the opportunity of checking into this now. I have to
> > pass the buck, though--the bug you ran into looks like the intersection
> > between Mike's extensive mathtext work and Darren's experimental
> > replacement rc system, and apart from the testing you refer to (prior to
> > much of Mike's work) I have not dealt with either of these areas.
>
> OK, understood. No worries.
>
> I'm rebuilding to SVN from August 1st, which is when this conversation
> started. That might do the trick and let us work here. I'll pester
> again for help if I get stuck.
Eric is correct. I have to run in a minute, but I'll update the config module 
early this evening to include Mikes recent changes.
Thank you for bringing it up with Enthought, Fernando.
Darren

On 8/16/07, Eric Firing <ef...@ha...> wrote:
> Fernando,
>
> Thanks for taking the opportunity of checking into this now. I have to
> pass the buck, though--the bug you ran into looks like the intersection
> between Mike's extensive mathtext work and Darren's experimental
> replacement rc system, and apart from the testing you refer to (prior to
> much of Mike's work) I have not dealt with either of these areas.
OK, understood. No worries.
I'm rebuilding to SVN from August 1st, which is when this conversation
started. That might do the trick and let us work here. I'll pester
again for help if I get stuck.
Regards,
f

Fernando,
Thanks for taking the opportunity of checking into this now. I have to 
pass the buck, though--the bug you ran into looks like the intersection 
between Mike's extensive mathtext work and Darren's experimental 
replacement rc system, and apart from the testing you refer to (prior to 
much of Mike's work) I have not dealt with either of these areas.
Eric
Fernando Perez wrote:
> Hi guys,
> 
> [ For the Enthought gang, sorry for the cross-post. This is the context:
> 
> http://www.mail-archive.com/mat...@li.../msg01451.html
> 
> We're trying to see if it would be reasonable to use Traits for the
> matplotlib config description, but there seem to be performance
> issues.
> ]
> 
> On 7/31/07, Eric Firing <ef...@ha...> wrote:
>> Darren,
>>
>> The two cases you ran have almost identical timing, so the problem is
>> not in reading matplotlib.conf. Instead, it seems to be in the
>> initialization of all the machinery, and I suspect that something may
>> be getting run many times in a loop instead of just once. I used the
>> profile.py script method to profile the whole simple_plot.py demo
>> modified to use Agg, with NEWCONFIG True versus False. Attached are the
>> top 100 lines of the output, sorted by cumulative time, with "new"
>> meaning NEWCONFIG=True. The execution time of the new version is 3.2
>> seconds versus 1.8 for the old. (Both are pretty slow for making a
>> minimal plot from a script.)
>>
> 
> I'm here at scipy'07 with the Enthought folks and trying to see if we
> can understand what the issue with this traits startup cost is. But I
> tried (with current SVN) to run a simple
> 
> python -c 'import pylab;pylab.plot([1,2,3])'
> 
> but I'm gettting:
> 
> obj: plain
> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
> line 2061, in plot
> b = ishold()
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
> line 888, in ishold
> return gca().ishold()
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
> line 834, in gca
> ax = gcf().gca(**kwargs)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
> line 722, in gca
> return self.add_subplot(111, **kwargs)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
> line 542, in add_subplot
> a = Subplot(self, *args, **kwargs)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
> line 5157, in __init__
> self.figW, self.figH], **kwargs)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
> line 507, in __init__
> self._init_axis()
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
> line 545, in _init_axis
> self.xaxis = maxis.XAxis(self)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
> line 512, in __init__
> self.label = self._get_label()
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
> line 990, in _get_label
> horizontalalignment='center',
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
> line 178, in __init__
> self.set_markup(markup)
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
> line 780, in set_markup
> self._markup = rcParams['text.markup']
> File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
> line 438, in __getitem__
> return getattr(obj, attr)
> AttributeError: 'str' object has no attribute 'markup'
> 
> 
> where the crash is coming from this (run interactively in ipdb):
> 
> /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py
> in __getitem__(self, key)
> 436 obj, attr = self.tconfig_map[key]
> 437 print 'obj:',obj
> --> 438 return getattr(obj, attr)
> 439
> 440 def keys(self):
> 
> AttributeError: 'str' object has no attribute 'markup'
> 
> In [2]: obj: MPLConfig
> 
> 
> In [3]: debug
>> /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__()
> 437 print 'obj:',obj
> --> 438 return getattr(obj, attr)
> 439
> 
> ipdb> print obj
> plain
> ipdb> print attr
> markup
> ipdb> print type(obj)
> <type 'str'>
> 
> 
> It looks like the 'text' object access is one level off, since it's
> trying to get 'markup' from 'plain', which is the *value* of
> 'text.markup' in the traits description.
> 
> This is with a just-built SVN.
> 
> If any of you could look into this (I can't really hack on it right
> now) it would be great, since we can look at the performance issues
> with the Enthought team, but we need the code to actually run.
> 
> If Eric/Darren want to talk directly, write to me off-list and I can
> call you on a phone.
> 
> Cheers,
> 
> f
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi guys,
[ For the Enthought gang, sorry for the cross-post. This is the context:
http://www.mail-archive.com/mat...@li.../msg01451.html
We're trying to see if it would be reasonable to use Traits for the
matplotlib config description, but there seem to be performance
issues.
]
On 7/31/07, Eric Firing <ef...@ha...> wrote:
> Darren,
>
> The two cases you ran have almost identical timing, so the problem is
> not in reading matplotlib.conf. Instead, it seems to be in the
> initialization of all the machinery, and I suspect that something may
> be getting run many times in a loop instead of just once. I used the
> profile.py script method to profile the whole simple_plot.py demo
> modified to use Agg, with NEWCONFIG True versus False. Attached are the
> top 100 lines of the output, sorted by cumulative time, with "new"
> meaning NEWCONFIG=True. The execution time of the new version is 3.2
> seconds versus 1.8 for the old. (Both are pretty slow for making a
> minimal plot from a script.)
>
I'm here at scipy'07 with the Enthought folks and trying to see if we
can understand what the issue with this traits startup cost is. But I
tried (with current SVN) to run a simple
python -c 'import pylab;pylab.plot([1,2,3])'
but I'm gettting:
obj: plain
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 2061, in plot
 b = ishold()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 888, in ishold
 return gca().ishold()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 834, in gca
 ax = gcf().gca(**kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 722, in gca
 return self.add_subplot(111, **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 542, in add_subplot
 a = Subplot(self, *args, **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 5157, in __init__
 self.figW, self.figH], **kwargs)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 507, in __init__
 self._init_axis()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 545, in _init_axis
 self.xaxis = maxis.XAxis(self)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 512, in __init__
 self.label = self._get_label()
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 990, in _get_label
 horizontalalignment='center',
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 178, in __init__
 self.set_markup(markup)
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 780, in set_markup
 self._markup = rcParams['text.markup']
 File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
line 438, in __getitem__
 return getattr(obj, attr)
AttributeError: 'str' object has no attribute 'markup'
where the crash is coming from this (run interactively in ipdb):
/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py
in __getitem__(self, key)
 436 obj, attr = self.tconfig_map[key]
 437 print 'obj:',obj
--> 438 return getattr(obj, attr)
 439
 440 def keys(self):
AttributeError: 'str' object has no attribute 'markup'
In [2]: obj: MPLConfig
In [3]: debug
> /home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__()
 437 print 'obj:',obj
--> 438 return getattr(obj, attr)
 439
ipdb> print obj
plain
ipdb> print attr
markup
ipdb> print type(obj)
<type 'str'>
It looks like the 'text' object access is one level off, since it's
trying to get 'markup' from 'plain', which is the *value* of
'text.markup' in the traits description.
This is with a just-built SVN.
If any of you could look into this (I can't really hack on it right
now) it would be great, since we can look at the performance issues
with the Enthought team, but we need the code to actually run.
If Eric/Darren want to talk directly, write to me off-list and I can
call you on a phone.
Cheers,
f

On Wednesday 15 August 2007 05:05:51 pm you wrote:
> Darren Dale wrote:
> > I'm doing something along the lines of:
> >
> > create an initial image with imshow
> > add a colorbar
> > update the image using the image's set_data method
> >
> > Occassionally, the extents of the image will change. How do I handle
> > that? The only place I can find to set the extents is in the call to
> > imshow. The resulting image has a get_extents, but not a setter. I can't
> > make repeated calls to imshow, because the new image isnt coupled to the
> > colorbar. I can't figure out how to couple the colorbar to the new image,
> > and I dont know how to get rid of the old colorbar to clear space for a
> > new one.
>
> Darren,
>
> Try directly setting the extent via the _extent attribute of the image
> object. If that works and doesn't cause any new problems, then we can
> add a trivial set_extent method.
I just committed this patch in svn. The additional code was lifted from 
imshow, to reshape the axes along with the image.
Darren
Index: lib/matplotlib/image.py
===================================================================
--- lib/matplotlib/image.py (revision 3709)
+++ lib/matplotlib/image.py (working copy)
@@ -236,6 +236,18 @@
 # by mistake.
 self.set_data(A)
+
+ def set_extent(self, extent):
+ """extent is data axes (left, right, bottom, top) for making image 
plots
+ """
+ self._extent = extent
+
+ xmin, xmax, ymin, ymax = extent
+ corners = (xmin, ymin), (xmax, ymax)
+ self.axes.update_datalim(corners)
+ if self.axes._autoscaleon:
+ self.axes.set_xlim((xmin, xmax))
+ self.axes.set_ylim((ymin, ymax))
 def get_interpolation(self):
 """

On Wednesday 15 August 2007 04:28:19 pm Darren Dale wrote:
> Also, does aspect='equal' work with the object oriented interface?
short answer: yes, if you expect it to do what its supposed to do.

I'm doing something along the lines of:
create an initial image with imshow
add a colorbar
update the image using the image's set_data method
Occassionally, the extents of the image will change. How do I handle that? The 
only place I can find to set the extents is in the call to imshow. The 
resulting image has a get_extents, but not a setter. I can't make repeated 
calls to imshow, because the new image isnt coupled to the colorbar. I can't 
figure out how to couple the colorbar to the new image, and I dont know how 
to get rid of the old colorbar to clear space for a new one.
Can someone offer some advice?
Also, does aspect='equal' work with the object oriented interface?
Thanks,
Darren

On Wednesday 15 August 2007 03:18:25 pm you wrote:
> On Wed, Aug 15, 2007 at 09:57:21AM -0400, Darren Dale wrote:
> > On Tuesday 14 August 2007 07:35:43 pm Darren Dale wrote:
> > > I'm developing an application for work and need to plot some spectra on
> > > a logscale. I can recreate my problem with embedding_in_qt4, by
> > > replacing MyDynamicMplCanvas.compute_initial_figure with this:
> > >
> > > def compute_initial_figure(self):
> > > self.axes.plot([0, 1, 2, 3], [1, 2, 0, 4], 'r')
> > > self.axes.set_yscale('log')
> > >
> > > [...]
> > > File
> > > "/usr/lib64/python2.5/site-packages/matplotlib-0.90.1_r3709-py2.5-linux
> > >-x86 _64.egg/matplotlib/axes.py", line 1664, in set_ylim
> > > raise ValueError('Cannot set nonpositive limits with log
> > > transform') ValueError: Cannot set nonpositive limits with log
> > > transform
> > >
> > > I get that error even if I modify the update figure function so there
> > > is no possibility of zeros occuring in the data
> >
> > I have tracked this back through axes.cla(), which is called when
> > axes._hold is False, to axis.cla(). axis.cla() resets the locators, but
> > the transforms are still set to mtrans.LOG10. Since plot is called by
> > loglog, and semilog*, it shouldn't be using any methods that modify
> > locators. If cla() resets the transforms, then the behavior of plot will
> > be different, preserving log transforms when hold is True, but changing
> > to linear transforms when hold is False.
> >
> > I wonder if cla() is trying to do too much. Maybe the initial setting of
> > locators should be moved out of cla(), which is called by Axes.__init__,
> > and into Axis.__init__. Then calls to cla() will preserve the scaling,
> > and the behavior of plot() will be consistent, regardless of the whether
> > hold is enabled or not.
>
> The other option is to do something sensible when axes limits are
> negative on the log scale. 
Thats a seperate, but important issue. In the case I described, the state of 
the plot becomes a mash of log transforms and linear locators.

On Wed, Aug 15, 2007 at 09:57:21AM -0400, Darren Dale wrote:
> On Tuesday 14 August 2007 07:35:43 pm Darren Dale wrote:
> > I'm developing an application for work and need to plot some spectra on a
> > logscale. I can recreate my problem with embedding_in_qt4, by replacing
> > MyDynamicMplCanvas.compute_initial_figure with this:
> >
> > def compute_initial_figure(self):
> > self.axes.plot([0, 1, 2, 3], [1, 2, 0, 4], 'r')
> > self.axes.set_yscale('log')
> >
> > [...]
> > File
> > "/usr/lib64/python2.5/site-packages/matplotlib-0.90.1_r3709-py2.5-linux-x86
> >_64.egg/matplotlib/axes.py", line 1664, in set_ylim
> > raise ValueError('Cannot set nonpositive limits with log transform')
> > ValueError: Cannot set nonpositive limits with log transform
> >
> > I get that error even if I modify the update figure function so there is no
> > possibility of zeros occuring in the data
> 
> I have tracked this back through axes.cla(), which is called when axes._hold 
> is False, to axis.cla(). axis.cla() resets the locators, but the transforms 
> are still set to mtrans.LOG10. Since plot is called by loglog, and semilog*, 
> it shouldn't be using any methods that modify locators. If cla() resets the 
> transforms, then the behavior of plot will be different, preserving log 
> transforms when hold is True, but changing to linear transforms when hold is 
> False.
> 
> I wonder if cla() is trying to do too much. Maybe the initial setting of 
> locators should be moved out of cla(), which is called by Axes.__init__, and 
> into Axis.__init__. Then calls to cla() will preserve the scaling, and the 
> behavior of plot() will be consistent, regardless of the whether hold is 
> enabled or not. 
The other option is to do something sensible when axes limits are
negative on the log scale. We switch back and forth between linear and log
while zooming/panning. Since it is difficult to keep the limits positive 
when using the linear scale we would love to have the plot handle bad
limits. I don't have a patch yet, but I don't mind if you beat me to it 8-)
Ultimately we would like negative data to be represented using
an inverted logarithmic scale, but this is a more difficult project.
For now we are masking out any data <= 0.
 - Paul

On Tuesday 14 August 2007 07:35:43 pm Darren Dale wrote:
> I'm developing an application for work and need to plot some spectra on a
> logscale. I can recreate my problem with embedding_in_qt4, by replacing
> MyDynamicMplCanvas.compute_initial_figure with this:
>
> def compute_initial_figure(self):
> self.axes.plot([0, 1, 2, 3], [1, 2, 0, 4], 'r')
> self.axes.set_yscale('log')
>
> [...]
> File
> "/usr/lib64/python2.5/site-packages/matplotlib-0.90.1_r3709-py2.5-linux-x86
>_64.egg/matplotlib/axes.py", line 1664, in set_ylim
> raise ValueError('Cannot set nonpositive limits with log transform')
> ValueError: Cannot set nonpositive limits with log transform
>
> I get that error even if I modify the update figure function so there is no
> possibility of zeros occuring in the data
I have tracked this back through axes.cla(), which is called when axes._hold 
is False, to axis.cla(). axis.cla() resets the locators, but the transforms 
are still set to mtrans.LOG10. Since plot is called by loglog, and semilog*, 
it shouldn't be using any methods that modify locators. If cla() resets the 
transforms, then the behavior of plot will be different, preserving log 
transforms when hold is True, but changing to linear transforms when hold is 
False.
I wonder if cla() is trying to do too much. Maybe the initial setting of 
locators should be moved out of cla(), which is called by Axes.__init__, and 
into Axis.__init__. Then calls to cla() will preserve the scaling, and the 
behavior of plot() will be consistent, regardless of the whether hold is 
enabled or not. 
Darren

Hi,
okay, I have added a keyword 'where' as suggested. I also now changed 
the way the incoming data is converted. I took this from the axes.pie() 
function. I don't know much about the unit types yet :-(
Concerning masked arrays: Do I have to consider something special there?
Manuel
Ted Drain wrote:
> At 10:36 AM 8/14/2007, Eric Firing wrote:
>> Ted Drain wrote:
>>> Manuel,
>>> We do plots like this all the time. One thing we've found that's 
>>> nice to have is a keyword that controls when the increase in y 
>>> happens. We use a step style keyword that can be 'pre' (go up then 
>>> right), 'post' (go right then up), and 'mid' (right 0.5, up, right 0.5).
>> Good idea.
>>> Regarding your patch, you might want to check other areas in MPL for 
>>> data processing examples. I could be wrong but I'm not sure you can 
>>> assume that incoming data is a float. Some of the unit conversion 
>>> examples or the line collection code might have better examples.
>>
>> Incoming data can be any numeric type, but it ends up getting 
>> converted to the default float type (not float32) internally.
>>
>> Whenever possible, it is good to support masked array input.
> 
> Agreed - but the way the patch was written, I don't think it will 
> support anything but float (especially not the unit types).
> 
>> Eric
>>> Ted
>>> At 07:59 AM 8/14/2007, Manuel Metz wrote:
>>>> Hi,
>>>>
>>>> I have created a patch against latest svn that adds a function step 
>>>> to the axes class to plot step-functions ;-) It's really simple but 
>>>> nice ... Any interest in adding this?
>>>>
>>>> Manuel
>>>>
>>>>
>>>>
>>>>
>>>> Index: axes.py
>>>> ===================================================================
>>>> --- axes.py (revision 3709)
>>>> +++ axes.py (working copy)
>>>> @@ -4995,6 +4995,18 @@
>>>> steps=[1, 2, 5, 10],
>>>> integer=True))
>>>> return im
>>>> +
>>>> + def step(self, x, y, *args, **kwargs):
>>>> + x2 = npy.zeros((2*len(x)), npy.float32)
>>>> + y2 = npy.zeros((2*len(x)), npy.float32)
>>>> +
>>>> + x2[0::2] = x
>>>> + x2[1::2] = x
>>>> +
>>>> + y2[1::2] = y
>>>> + y2[2::2] = y[:-1]
>>>> +
>>>> + self.plot(x2, y2, *args, **kwargs)
>>>>
>>>> class SubplotBase:
>>>> """
>>>>
>>>> ------------------------------------------------------------------------- 
>>>>
>>>> This SF.net email is sponsored by: Splunk Inc.
>>>> Still grepping through log files to find problems? Stop.
>>>> Now Search log events and configuration files using AJAX and a browser.
>>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> ------------------------------------------------------------------------
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>
>>> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel