matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>   
>> I'm guessing some of Eric's recent changes to alpha handling in paths
>> require modifications to the MacOS X backend?
>>     
>
> Correct.  I'll fix it.
>   

I see the Mac OS X buildbot is back online now, so perhaps we could add
some unit tests that run on that backend? (I don't know the mac backend
at all -- is it possible for it to save output, or even to run without
access to the graphics system?)

-Andrew

On 08/17/2010 06:36 AM, Jeff Whitaker wrote:
>
> I've started to see these errors today:
>
> TypeError: function takes exactly 3 arguments (4 given)
> Traceback (most recent call last):
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py",
> line 55, in draw_wrapper
>       draw(artist, renderer, *args, **kwargs)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/figure.py",
> line 738, in draw
>       if self.frameon: self.patch.draw(renderer)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py",
> line 55, in draw_wrapper
>       draw(artist, renderer, *args, **kwargs)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/patches.py",
> line 406, in draw
>       renderer.draw_path(gc, tpath, affine, rgbFace)
>     File
> "/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/backends/backend_macosx.py",
> line 54, in draw_path
>       gc.draw_path(path, transform, linewidth, rgbFace)
> TypeError: function takes exactly 3 arguments (4 given)
>
> I'm guessing some of Eric's recent changes to alpha handling in paths
> require modifications to the MacOS X backend?

Correct.  I'll fix it.

Eric

>
> -Jeff
>

I've started to see these errors today:

TypeError: function takes exactly 3 arguments (4 given)
Traceback (most recent call last):
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py", 
line 55, in draw_wrapper
     draw(artist, renderer, *args, **kwargs)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/figure.py", 
line 738, in draw
     if self.frameon: self.patch.draw(renderer)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/artist.py", 
line 55, in draw_wrapper
     draw(artist, renderer, *args, **kwargs)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/patches.py", 
line 406, in draw
     renderer.draw_path(gc, tpath, affine, rgbFace)
   File 
"/Users/jwhitaker/.local/lib/python2.6/site-packages/matplotlib/backends/backend_macosx.py", 
line 54, in draw_path
     gc.draw_path(path, transform, linewidth, rgbFace)
TypeError: function takes exactly 3 arguments (4 given)

I'm guessing some of Eric's recent changes to alpha handling in paths 
require modifications to the MacOS X backend?

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

Sorry about that.  I believe it is fixed now.

Mike

On 08/16/2010 05:54 PM, Andrew Straw wrote:
> Michael Droettboom wrote:
>    
>> On 08/14/2010 07:22 PM, Eric Firing wrote:
>>
>>      
>>> Mike,
>>>
>>> Is there any reason why the Path.unit_* methods shouldn't include the
>>> codes, so that they can all have CLOSEPOLY?  Or shouldn't they at
>>> least have a kwarg to allow that as an option?  In working on patch
>>> drawing via bar(), I noticed that the rectangle outline is not closing
>>> properly, with the same rounded join as at the other 3 corners.  It
>>> isn't apparent unless you set a large linewidth.
>>>
>>> Or is there a better way to ensure that polygons close correctly?
>>>
>>>        
>> I don't think there's a better way.  The renderer can't assume CLOSEPOLY
>> at the end, obviously, because it may in fact by a line and not a filled
>> shape.
>>
>> I think this was left out just as shorthand (not having a codes array
>> makes things a little faster, too), but I think for correctness the
>> unit_* methods should have explicit codes arrays with CLOSEPOLYs.  I'll
>> go ahead and fix this.
>>
>> Mike
>>
>>
>>      
> Hi Mike, all the buildbots have errors with the
> matplotlib.tests.test_simplification.test_hatch test on r8639 that
> weren't there in r8635, and I think it's due to the code you committed.
> Could you have a look?
>
> (Don't worry about the doc build errors -- I think that's a bug with the
> recent Sphinx 1.0.2 release, for which I have filed a report at
> http://bitbucket.org/birkenfeld/sphinx/issue/501 for.)
>
> (I was proud of all the green on the buildbot -- hopefully it won't turn
> me into a chronic nag!)
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA