matplotlib-devel Mailing List for matplotlib (Page 7)

I'm getting this when trying to commit to SVN this morning:

> svn: Commit failed (details follow):
> svn: MKACTIVITY of 
> '/svnroot/matplotlib/!svn/act/6b28eb9b-4b59-0410-81bc-d80e6be37be8': 
> 403 Forbidden (https://matplotlib.svn.sf.net)
Googling suggests this occurs when the developer doesn't have write 
permissions (not the case here), or using http rather than https (also 
not the case).

Filed a bug here:

https://sourceforge.net/tracker/?func=detail&atid=200001&aid=2168647&group_id=1

Anyone else experiencing this?

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Oct 15, 2008 at 9:48 AM, Michael Droettboom <md...@st...> wrote:
> Yep... just sent a message before seeing this one.  The few possible causes
> I could find through Google didn't seem relevant.
>
> Feel free to pile on to this bug report -->
>
> https://sourceforge.net/tracker/?func=detail&atid=200001&aid=2168647&group_id=1
>

I did -- and since others are now adding comments that they see the
same, it looks like a generic sf problem.  Hopefully they will get it
sorted out soon.

JDH

On Wed, Oct 15, 2008 at 8:18 AM, Michael Droettboom <md...@st...> wrote:
> The new stylesheet for the docs looks great, John!

I just ripped this off hook-line-and-sinker from the sphinx docs, and
added the few css bits you created earlier.  They do look nice :-)

> One extremely minor nit: perhaps the logo is a too large in this
> context.  On smaller screens, like a 1024x768 laptop, it encompasses
> about a third of the usable browser window space.
>
> Would it be possible to keep it the current size for the main home page,
> but use a smaller version for the documentation pages?  Or, to the
> extreme, just use a small icon-sized logo like in the Python 2.6 docs?

I'm happy to do use a smaller logo on the doc pages, but off hand do
not know how to do it.  I am knee deep in trying to convert the
existing docs, because as you probably gathered the sphinx docs will
soon entirely replace the existing web pages entirely.  So if you
could help with this logo change that would be great.  Either route
(smaller logo or single icon) is fine by me.....

Yep... just sent a message before seeing this one.  The few possible 
causes I could find through Google didn't seem relevant.

Feel free to pile on to this bug report -->

https://sourceforge.net/tracker/?func=detail&atid=200001&aid=2168647&group_id=1

Mike

John Hunter wrote:
> I am getting this error on a couple of machines when I try to commit
>
> johnh@flag:mpl> svn commit -m 'some more doc mods'
> svn: Commit failed (details follow):
> svn: MKACTIVITY of
> '/svnroot/matplotlib/!svn/act/5726e9f3-f4eb-cc5e-bc97-ffd78106e3fc':
> 403 Forbidden (https://matplotlib.svn.sourceforge.net)
>
> Anyone else seeing this and does anyone have any idea what is wrong?
>
> Thanks,
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> 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

I am getting this error on a couple of machines when I try to commit

johnh@flag:mpl> svn commit -m 'some more doc mods'
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/matplotlib/!svn/act/5726e9f3-f4eb-cc5e-bc97-ffd78106e3fc':
403 Forbidden (https://matplotlib.svn.sourceforge.net)

Anyone else seeing this and does anyone have any idea what is wrong?

Thanks,
JDH

The new stylesheet for the docs looks great, John!

One extremely minor nit: perhaps the logo is a too large in this 
context.  On smaller screens, like a 1024x768 laptop, it encompasses 
about a third of the usable browser window space.

Would it be possible to keep it the current size for the main home page, 
but use a smaller version for the documentation pages?  Or, to the 
extreme, just use a small icon-sized logo like in the Python 2.6 docs?

http://www.python.org/doc/current/library/

Mike

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thanks.  Fixed in SVN.

Benjamin Drung wrote:
> Hello,
>
> there is a typo in matplotlibrc.template. Appended the fix.
>
> Greeting,
> Benjamin
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Hello,

there is a typo in matplotlibrc.template. Appended the fix.

Greeting,
Benjamin

Anne Archibald wrote:
> Hi,
> 
> First of all, matplotlib is a very nice piece of software - I use it
> all the time for interactive data analysis, for posters, and for
> published papers.
> 
> For visualizing low-resolution vector fields, quiver() is quite nice.
> But for high-resolution vector fields there is a technique called
> "line integral convolution" that can be quite effective. Matplotlib
> doesn't seem to implement it, but I have written a simple line
> integral convolution operator I'd be happy to contribute. It's written
> in cython, and is quite fast and fairly general. There is no
> high-level interface like quiver() yet, in part because of the many
> ways you might want to use the operator. In fact I don't know for sure
> that it belongs here rather than (say) scipy.
> 
> Are you interested in including this in matplotlib?

Possibly.  As you note, the question may be whether this belongs in 
scipy, or in an mpl toolkit, or in mpl itself.  I had to google to find 
out what "line integral convolution" is.  It does look like it would be 
a nice thing to offer.  I presume the actual plot would be via image (or 
maybe pcolorfast if anything but a uniform rectangular grid is used). 
Is that correct, or are there other ways the output of the operator 
would be displayed?

So far, mpl has not had pyrex or cython as a build dependency, but 
cython is used in the basemap toolkit.  Personally, I like pyrex/cython 
very much and would be happy to see one of them--presumably cython--used
in mpl.  Others may disagree.

Based on what you say above, my guess is that scipy might be the most 
natural home for your code, in which case we would want to have an 
example of its use for generating an image in the set of mpl examples. 
But if something more elaborate is needed in the way of a high-level 
interface, then either putting it in mpl directly, or in a toolkit, 
would be good.

Eric

> 
> Anne
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,

First of all, matplotlib is a very nice piece of software - I use it
all the time for interactive data analysis, for posters, and for
published papers.

For visualizing low-resolution vector fields, quiver() is quite nice.
But for high-resolution vector fields there is a technique called
"line integral convolution" that can be quite effective. Matplotlib
doesn't seem to implement it, but I have written a simple line
integral convolution operator I'd be happy to contribute. It's written
in cython, and is quite fast and fairly general. There is no
high-level interface like quiver() yet, in part because of the many
ways you might want to use the operator. In fact I don't know for sure
that it belongs here rather than (say) scipy.

Are you interested in including this in matplotlib?

Anne

Jae-Joon Lee wrote:
>> - the parameter numpoints should be used (it's ignored right now)
>>
> 
> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
> 
> 
>> - Some private variables are accessed and a new RegularPolycollection is
>> created (does this work eg. with a StarPolygonCollection? I haven't
>> checked, but I don't think so !). Instead of creating a new
>> RegularPolyCollection it might be more useful to make a copy of the
>> existing object... I was thinking about a update_from() method for the
>> Collection class(es) similar to update_from() for lines.
>>
> 
> By changing "RegularPolyCoolection"  to "type(handles)", it works for
> StarPolygonCollection.
> In Erik's current implementation, the markers in the legend have
> varying colors, sizes, and y offsets.
> The color variation seems fine.

+1

> But do we need to vary the sizes and
> y-offsets? My inclination is to use a fixed size (median?) and a fixed
> y offset. How does Erik and others think?

I also would prefer fixed sizes for the legend, but maybe one should
ensure that the markers are not too large (larger than text height)?

mm

> Regards,
> 
> -JJ

> - the parameter numpoints should be used (it's ignored right now)
>

Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.


> - Some private variables are accessed and a new RegularPolycollection is
> created (does this work eg. with a StarPolygonCollection? I haven't
> checked, but I don't think so !). Instead of creating a new
> RegularPolyCollection it might be more useful to make a copy of the
> existing object... I was thinking about a update_from() method for the
> Collection class(es) similar to update_from() for lines.
>

By changing "RegularPolyCoolection"  to "type(handles)", it works for
StarPolygonCollection.

In Erik's current implementation, the markers in the legend have
varying colors, sizes, and y offsets.
The color variation seems fine. But do we need to vary the sizes and
y-offsets? My inclination is to use a fixed size (median?) and a fixed
y offset. How does Erik and others think?

Regards,

-JJ

On Fri, Oct 10, 2008 at 11:31 AM, Gregor Thalhammer
<gre...@gm...> wrote:

> Is this really an intended behaviour? Wouldn't it be better if
> get_xlim() already returns a copy? Or could at least the documentation
> be updated to mention this pitfall?

I think it should return a copy -- if I don't hear any objections I'll
change it.

JDH

Dear developers,

the following example shows a somewhat unexpected behaviour of the 
get_xlim() method of an axis object: it returns a view to the internal 
data structure used to store the data limits. Because of this saving and 
restoring the data limits failed in this example (I am using matplotlib 
0.98.3):

from pylab import *
plot([0,1], [0,1]) #create some plot
ax = gca() #keep reference to axis
#after some time, I want to change the plot content, but keep the data 
limits
xlimits = ax.get_xlim() #save limits
print xlimits
ax.clear()            #first clear axis, then
plot([1,2], [1,2])    #create new plot content
ax.set_xlim(xlimits)  #does _not_ restore old limits
print xlimits         #since saved xlimits also changed

Now I know that I have to use

xlimits = ax.get_xlim().copy()

if I want to save the data limits.

Is this really an intended behaviour? Wouldn't it be better if 
get_xlim() already returns a copy? Or could at least the documentation 
be updated to mention this pitfall?

Gregor

John Hunter wrote:
> On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote:
>> Ah, that makes more sense Jae-Joon - thanks!
> 
> Jae-Joon -- could you handle this patch submission?
> 
> Thanks,
> JDH

Hi,
  I also had a look at this patch -- as that's a feature I was
interested in, too. There are a few things that I think need to be
changed; just want to share my thoughts:

- the parameter numpoints should be used (it's ignored right now)

- Some private variables are accessed and a new RegularPolycollection is
created (does this work eg. with a StarPolygonCollection? I haven't
checked, but I don't think so !). Instead of creating a new
RegularPolyCollection it might be more useful to make a copy of the
existing object... I was thinking about a update_from() method for the
Collection class(es) similar to update_from() for lines.

mm

> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Gregor Thalhammer wrote:
> Dear developers,
> 
> in matplotlib 0.98.3 I discoverd that in scatter individual alpha 
> settings (by giving a list of rgba values) are ignered. Here an example 
> that show this behaviour: All points show the same alpha value as given 
> by the alpha keyword argument. (Omitting it equals to the setting alpha=1).
> 
> 
> from pylab import *
> 
> x = [1,2,3]
> y = [1,2,3]
> 
> c = [[1,0,0, 0.0],
>      [1,0,0, 0.5],
>      [1,0,0, 1.0]]
> 
> gca()
> cla()
> scatter(x,y, c=c, s = 200, alpha = 0.5)
> draw()
> show()
> 
> 
> I had a look at the sources. In axes.py/scatter I simply removed the line
> 
> collection.set_alpha(alpha)

You are correct that there is a bug, in that the alpha in rgba arrays is 
  always overridden, but removing that line is not the solution.  I will 
try to fix it in the next few days.  I think the intention was that 
alpha=None would be used to mean "don't disturb existing alpha in an 
rgba array; but use alpha=1 if color comes in as other than rgba", but 
this has not been propagated uniformly.  Small changes in quite a few 
places may be needed.

Eric

> 
> The recent svn version also contains this line.
> With this change it worked as expected, also e.g. for the case of a 
> single color for all points,
> 
> scatter(x,y, c = 'r', alpha = 0.5)
> 
> Gregor

Okay.
I may work on it sometime tomorrow or during the weekends.

Regards,

-JJ


On Thu, Oct 9, 2008 at 12:54 PM, John Hunter <jd...@gm...> wrote:
> On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote:
>> Ah, that makes more sense Jae-Joon - thanks!
>
> Jae-Joon -- could you handle this patch submission?
>
> Thanks,
> JDH
>

On Wed, Oct 8, 2008 at 10:27 PM, Erik Tollerud <eri...@gm...> wrote:
> Ah, that makes more sense Jae-Joon - thanks!

Jae-Joon -- could you handle this patch submission?

Thanks,
JDH

On Thu, Oct 9, 2008 at 6:14 AM, Michael Droettboom <md...@st...> wrote:

>> If  2) in the choices above is the case you are concerned about, and
>> you want this warning feature in this case, we can add an rc param
>> which is autoset at build time, something like "show.warn =
>> True|False" since the build script is setting the default image
>> backend and can set "show.warn = True" when it sets an image backend
>> by default, otherwise False.
>>
>
> I intended the warning to warn against misconfiguration, so one shouldn't
> have to explicitly configure anything to get it... ;)

This is mostly academic, since I am happy with your latest changes
because I can run backend driver or do

 > python somefile.py -dAgg

and get no warning.

But .... I wasn't suggesting explicit configuration by the user.  At
build time, mpl looks for a functioning backend in setup.py and if it
fails to find one, sets Agg and creates the default matplotlibrc from
matplotlibrc.template.  In the case where a no GUI was detected, the
build script could also set a rc warn-on-show flag.  The ubuntu
packager, who probably built mpl in an environment with no X11 and got
no functioning GUI, would get a rc file with backend Agg and the
warn-on-show flag set.

But I think we can leave things as they are.

Michael Droettboom wrote:
> John Hunter wrote:
>   
>> In unrelated news, I am not in favor of the recent change to warn on
>> non-GUI backends when "show" is called.  I realize this may sometimes
>> cause head-scratching behavior for some users who call show and no
>> figure pops up, but I think this must be pretty rare.  99% of users
>> have a matplotlibrc which defines a GUI default.  AFAIK, the only
>> exceptions to this are 1) when the user has changed the rc (power
>> user, needs no protection) or 2) no GUI was available at build time
>> and the image backend was the default backend chosen (warning more
>> appropriate at build time).  If I am missing a use case, let me know.
>>   
>>     
> The motivation was when a popular Linux distribution misconfigured the 
> default to the Agg backend:
>
> https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764
>
> This warning was meant as future insurance against this happening -- and 
> hoping that if the packagers don't make a GUI backend the default (in an 
> attempt to reduce dependencies), that they at least would include the 
> warning patch so that users aren't left feeling that matplotlib is "broken".
>
> But we can't prevent all downstream packaging errors, so maybe this 
> patch doesn't belong in trunk. ;)
>   
>> I like the design where the same script can be used to either generate
>> a UI figure or hardcopy depending on an rc settng or a command flag
>> (eg backend driver) and would rather not do the warning.  This has
>> been a very infrequent problem for users over the years (a few times
>> at most?) so I am not sure that the annoyance of the warning is
>> justified.
>>   
>>     
> Perhaps the warning could only be emitted when running inside an 
> interactive console (ipython or standard python) -- if that's possible.  
> Alternatively, "ipython -pylab" could warn on startup if the backend is 
> non-GUI (and that change would probably live in ipython).
I have modified the code to only do this when show() is called directly 
from the python or ipython console.  Calling show() from a script will 
not emit this warning.

If that's still too noisy, I'm happy to revert the whole thing.

Mike

John Hunter wrote:
> On Wed, Oct 8, 2008 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
>   
>> Thanks for doing this--it has already helped me in my testing of the
>> gappy-path simplification support, which I have now committed.  As you
>> suggested earlier, I included in path.py a check for a compatible codes
>> array.
>>
>> The agg limit still can be a problem.  It looks like chunking could be added
>> easily by making the backend_agg draw_path a python method calling the
>> renderer method; if the path length exceeds some threshold, then subpaths
>> would be generated and passed to the renderer method.
>>     
>
> In unrelated news, I am not in favor of the recent change to warn on
> non-GUI backends when "show" is called.  I realize this may sometimes
> cause head-scratching behavior for some users who call show and no
> figure pops up, but I think this must be pretty rare.  99% of users
> have a matplotlibrc which defines a GUI default.  AFAIK, the only
> exceptions to this are 1) when the user has changed the rc (power
> user, needs no protection) or 2) no GUI was available at build time
> and the image backend was the default backend chosen (warning more
> appropriate at build time).  If I am missing a use case, let me know.
>   
The motivation was when a popular Linux distribution misconfigured the 
default to the Agg backend:

https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/278764

This warning was meant as future insurance against this happening -- and 
hoping that if the packagers don't make a GUI backend the default (in an 
attempt to reduce dependencies), that they at least would include the 
warning patch so that users aren't left feeling that matplotlib is "broken".

But we can't prevent all downstream packaging errors, so maybe this 
patch doesn't belong in trunk. ;)
> I like the design where the same script can be used to either generate
> a UI figure or hardcopy depending on an rc settng or a command flag
> (eg backend driver) and would rather not do the warning.  This has
> been a very infrequent problem for users over the years (a few times
> at most?) so I am not sure that the annoyance of the warning is
> justified.
>   
Perhaps the warning could only be emitted when running inside an 
interactive console (ipython or standard python) -- if that's possible.  
Alternatively, "ipython -pylab" could warn on startup if the backend is 
non-GUI (and that change would probably live in ipython).
> If  2) in the choices above is the case you are concerned about, and
> you want this warning feature in this case, we can add an rc param
> which is autoset at build time, something like "show.warn =
> True|False" since the build script is setting the default image
> backend and can set "show.warn = True" when it sets an image backend
> by default, otherwise False.
>   
I intended the warning to warn against misconfiguration, so one 
shouldn't have to explicitly configure anything to get it... ;)

Mike

Ah, that makes more sense Jae-Joon - thanks!

With this addition it all looks fine to me - I've attached a patch
against 6174 that does everything I'd like to see it do... note that
I've left in the TODO in collections.py simply because I still am not
certain that what I'm doing there is correct in all use-cases...

On Mon, Oct 6, 2008 at 11:22 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi Eric,
>
> As far as I know, get_window_extent is meant to return the extent of
> the object in the display coordinate. And, as you may have noticed,
> often this is used to calculate the relative position of  objects.
>
> I quickly went through your patch and my guess is your implementation
> of get_window_extent is correct in this regard, but I haven't
> considered this seriously so I may be wrong.
>
> On the other hand, I guess the original problem you had is not related
> with the get_window_extents() method.
> The legend class has a _update_positions() method  which is called
> before the legends are drawn. And you have to update positions of your
> handles within this method.
>
> In the simple patch below. I tried to implement some basic update code
> for the polycollections ( I also slightly adjusted the y-offsets. This
> is just my personal preference). See if this patch works for you.
>
> Regards,
>
> -JJ
>
>
>
> Index: lib/matplotlib/legend.py
> ===================================================================
> --- lib/matplotlib/legend.py    (revision 6163)
> +++ lib/matplotlib/legend.py    (working copy)
> @@ -532,6 +540,12 @@
>             elif isinstance(handle, Rectangle):
>                 handle.set_y(y+1/4*h)
>                 handle.set_height(h/2)
> +            elif isinstance(handle, RegularPolyCollection):
> +                offsets = handle.get_offsets()
> +                xvals = [x for (x, _) in offsets]
> +                yy = y + h
> +                yvals=[yy-4./8*h,yy-3./8*h,yy-4./8*h]
> +                handle.set_offsets(zip(xvals, yvals))
>
>         # Set the data for the legend patch
>         bbox = self._get_handle_text_bbox(renderer)
>
>
>
> On Tue, Oct 7, 2008 at 12:15 AM, Erik Tollerud <eri...@gm...> wrote:
>> Does anyone have anything new here? I'm perfectly willing to
>> experiment, but I'm really at a loss as to what
>> get_window_extent(self,render) is supposed to do (clearly get some
>> window extent, but exactly what window and what coordinates the extent
>> is in is what is confusing me).
>>
>> On Tue, Sep 23, 2008 at 11:41 AM, John Hunter <jd...@gm...> wrote:
>>> On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud <eri...@gm...> wrote:
>>>> Attached is a diff against revision 6115 that contains a patch to
>>>> improve the behavior of the legend function when showing legends for
>>>
>>> Erik,
>>>
>>> I haven't had a chance to get to this yet.  Could you please also post
>>> it on the sf patch tracker so it doesn't get dropped, and ping us with
>>> a reminder in a few days if nothing has happened....
>>>
>>> JDH
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>



-- 
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
2142 Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2587
Cell: (651)307-9409
eto...@uc...

On Wed, Oct 8, 2008 at 8:40 PM, Eric Firing <ef...@ha...> wrote:
> Thanks for doing this--it has already helped me in my testing of the
> gappy-path simplification support, which I have now committed.  As you
> suggested earlier, I included in path.py a check for a compatible codes
> array.
>
> The agg limit still can be a problem.  It looks like chunking could be added
> easily by making the backend_agg draw_path a python method calling the
> renderer method; if the path length exceeds some threshold, then subpaths
> would be generated and passed to the renderer method.

In unrelated news, I am not in favor of the recent change to warn on
non-GUI backends when "show" is called.  I realize this may sometimes
cause head-scratching behavior for some users who call show and no
figure pops up, but I think this must be pretty rare.  99% of users
have a matplotlibrc which defines a GUI default.  AFAIK, the only
exceptions to this are 1) when the user has changed the rc (power
user, needs no protection) or 2) no GUI was available at build time
and the image backend was the default backend chosen (warning more
appropriate at build time).  If I am missing a use case, let me know.

I like the design where the same script can be used to either generate
a UI figure or hardcopy depending on an rc settng or a command flag
(eg backend driver) and would rather not do the warning.  This has
been a very infrequent problem for users over the years (a few times
at most?) so I am not sure that the annoyance of the warning is
justified.

If  2) in the choices above is the case you are concerned about, and
you want this warning feature in this case, we can add an rc param
which is autoset at build time, something like "show.warn =
True|False" since the build script is setting the default image
backend and can set "show.warn = True" when it sets an image backend
by default, otherwise False.

JDH

Michael Droettboom wrote:
> John Hunter wrote:
>> On Wed, Oct 8, 2008 at 11:37 AM, Michael Droettboom <md...@st...> wrote:
>>
>>   
>>> I figured this out.  When this happens, a RuntimeError("Agg rendering
>>> complexity exceeded") is thrown.
>>>     
>> Do you think it is a good idea to put a little helper note in the
>> exception along the lines of
>>
>>   throw "Agg rendering complexity exceeded; you may want to increase
>> the cell_block_size in agg_rasterizer_cells_aa.h"
>>
>> in case someone gets this exception two years from now and none of us
>> can remember this brilliant fix :-)
>>   
> We can suggest that, or suggest that the size of the data is too large 
> (which is easier for most users to fix, I would suspect).  What about:
> 
> "Agg rendering complexity exceeded.  Consider downsampling or decimating 
> your data."
> 
> along with a comment (not thrown), saying
> 
> /* If this is thrown too often, increase cell_block_limit. */
> 
> Mike
> 

Mike,

Thanks for doing this--it has already helped me in my testing of the 
gappy-path simplification support, which I have now committed.  As you 
suggested earlier, I included in path.py a check for a compatible codes 
array.

The agg limit still can be a problem.  It looks like chunking could be 
added easily by making the backend_agg draw_path a python method calling 
the renderer method; if the path length exceeds some threshold, then 
subpaths would be generated and passed to the renderer method.

Eric

On Wed, Oct 8, 2008 at 1:44 PM, David Huard <dav...@gm...> wrote:

> /usr/local/lib64/python2.5/site-packages/matplotlib/legend.pyc in
> __init__(self, parent, handles, labels, loc, numpoints, prop, pad,
> borderpad, markerscale, labelsep, handlelen, handletextsep, axespad, shadow)
>     125             setattr(self,name,value)
>     126         if pad:
> --> 127             warnings.DeprecationWarning("Use 'borderpad' instead of
> 'pad'.")
>     128             # 2008/10/04
>     129         if self.numpoints <= 0:
>
> AttributeError: 'module' object has no attribute 'DeprecationWarning'

I just replaced this with

  warnings.warn("Use 'borderpad' instead of 'pad'.", DeprecationWarning)

which is what we have been doing in other parts of the code, so please
give svn 6173 a try.

Thanks,
JDH