error, when calling "ax.redraw_in_frame()"

Hello list,

I get an error, when calling "ax.redraw_in_frame()" (see below).

I think this is due to the fact that the draw_wrapper expects args instead of
kwargs for the "draw" of an Axes instance and therefore provide a patch,
which adds an additional star.

Could any of the developers have a look at it, please?

Kind regards,
Matthias

draw_wrapper_for_axes.patch (761 Bytes)

···

#----------------------------------------------------------------------------
File "textbox2_mod.py", line 37, in redraw
    self.ax.redraw_in_frame()
  
File "/scratch/michler/SOFT//lib/python2.5/site-packages/matplotlib/axes.py",
line 1795, in redraw_in_frame
    self.draw(self._cachedRenderer, inframe=True)
TypeError: draw_wrapper() got an unexpected keyword argument 'inframe'

JJ, this looks like something you are most qualified to look at.
Could we standardize on *args and **kwargs for the naming convention
of optional arguments and keyword arguments to help avoid some
ambiguity?

JDH

···

On Wed, Mar 3, 2010 at 10:09 AM, Matthias Michler <MatthiasMichler@...361...> wrote:

Hello list,

I get an error, when calling "ax.redraw_in_frame()" (see below).

I think this is due to the fact that the draw_wrapper expects args instead of
kwargs for the "draw" of an Axes instance and therefore provide a patch,
which adds an additional star.

Could any of the developers have a look at it, please?

I fixed this in the maintenance branch.
But I'm failing with the svnmerge.
I thought this issue has been fixed but I'm not sure what I'm doing
wrong. I cannot spend much more time on this right now, but John, if
you can, please merge the change and commit them for me.

Regards,

-JJ

···

On Wed, Mar 3, 2010 at 11:42 AM, John Hunter <jdh2358@...287...> wrote:

On Wed, Mar 3, 2010 at 10:09 AM, Matthias Michler > <MatthiasMichler@...361...> wrote:

Hello list,

I get an error, when calling "ax.redraw_in_frame()" (see below).

I think this is due to the fact that the draw_wrapper expects args instead of
kwargs for the "draw" of an Axes instance and therefore provide a patch,
which adds an additional star.

Could any of the developers have a look at it, please?

JJ, this looks like something you are most qualified to look at.
Could we standardize on *args and **kwargs for the naming convention
of optional arguments and keyword arguments to help avoid some
ambiguity?

JDH

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Jae-Joon Lee wrote:

I fixed this in the maintenance branch.
But I'm failing with the svnmerge.
I thought this issue has been fixed but I'm not sure what I'm doing
wrong.

I thought I had fixed it, but it seems to have broken again immediately after. I'm not sure how much additional time I want to spend on the problem given that the transition to git is imminent :wink:

Mike

···

I cannot spend much more time on this right now, but John, if
you can, please merge the change and commit them for me.

Regards,

-JJ

On Wed, Mar 3, 2010 at 11:42 AM, John Hunter <jdh2358@...287...> wrote:
  

On Wed, Mar 3, 2010 at 10:09 AM, Matthias Michler >> <MatthiasMichler@...361...> wrote:
    

Hello list,

I get an error, when calling "ax.redraw_in_frame()" (see below).

I think this is due to the fact that the draw_wrapper expects args instead of
kwargs for the "draw" of an Axes instance and therefore provide a patch,
which adds an additional star.

Could any of the developers have a look at it, please?
      

JJ, this looks like something you are most qualified to look at.
Could we standardize on *args and **kwargs for the naming convention
of optional arguments and keyword arguments to help avoid some
ambiguity?

JDH

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
  
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

OK, I just manually added this via a diff/patch. Keep your eyes out
for flakiness. I did try a matplotlib.test before committing and got
one error about the hexbin extent so there may be a little cleanup to
do. I ignored that because nothing in the diff I applied should
affect that so I thought it might be pre-existing or spurious

JDH

The patch I applied:

Index: doc/_static/favicon.ico

···

On Wed, Mar 3, 2010 at 12:21 PM, Michael Droettboom <mdroe@...86...> wrote:

Jae-Joon Lee wrote:

I fixed this in the maintenance branch.
But I'm failing with the svnmerge.
I thought this issue has been fixed but I'm not sure what I'm doing
wrong.

I thought I had fixed it, but it seems to have broken again immediately
after. I'm not sure how much additional time I want to spend on the problem
given that the transition to git is imminent :wink:

Mike

I cannot spend much more time on this right now, but John, if
you can, please merge the change and commit them for me.

===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream

Property changes on: doc/_static/favicon.ico
___________________________________________________________________
Added: svn:mime-type
   + application/octet-stream

Index: doc/_templates/layout.html

--- doc/_templates/layout.html (revision 8160)
+++ doc/_templates/layout.html (revision 8175)
@@ -23,8 +23,8 @@
</script>
<object><noscript><p><img
src="http://apps.sourceforge.net/piwik/matplotlib/piwik.php?idsite=1"
alt="piwik"/></p></noscript></object>
<!-- End Piwik Tag -->
+<link rel="shortcut icon" href="_static/favicon.ico">

-
<div style="background-color: white; text-align: left; padding: 10px
10px 15px 15px">
<a href="{{ pathto('index') }}"><img src="{{
pathto("_static/logo2.png", 1) }}" border="0" alt="matplotlib"/></a>
Index: doc/_templates/indexsidebar.html

--- doc/_templates/indexsidebar.html (revision 8160)
+++ doc/_templates/indexsidebar.html (revision 8175)
@@ -9,7 +9,7 @@
</p>

<p>Sandro Tosi has a new book
-<a href="http://www.packtpub.com/matplotlib-python-development/book">Matplotlib
for python
+<a href="http://www.packtpub.com/matplotlib-python-development/book?utm_source=matplotlib.sourceforge.net&utm_medium=link&utm_content=pod&utm_campaign=mdb_002124">Matplotlib
for python
developers</a>
also
at <a href="http://www.amazon.com/Matplotlib-Python-Developers-Sandro-Tosi/dp/1847197906">amazon</a>.</p>
Index: doc/devel/coding_guide.rst

--- doc/devel/coding_guide.rst (revision 8160)
+++ doc/devel/coding_guide.rst (revision 8175)
@@ -75,8 +75,8 @@

* install ``svnmerge.py`` in your PATH::

- > wget http://svn.collab.net/repos/svn/trunk/contrib/client-side/\
- svnmerge/svnmerge.py
+ > wget http://svn.apache.org/repos/asf/subversion/trunk/contrib/\
+ client-side/svnmerge/svnmerge.py

* get a svn checkout of the branch you'll be making bugfixes to and
   the trunk (see above)
Index: doc/users/artists.rst

--- doc/users/artists.rst (revision 8160)
+++ doc/users/artists.rst (revision 8175)
@@ -419,7 +419,7 @@
     # and notice that the ax.add_patch method has set the axes
     # instance
     In [267]: print rect.get_axes()
- Subplot(49,81.25)
+ Axes(0.125,0.1;0.775x0.8)

     # and the transformation has been set too
     In [268]: print rect.get_transform()
@@ -434,7 +434,7 @@
     (0.0, 1.0)

     # but the data limits have been updated to encompass the rectangle
- In [271]: print ax.dataLim.get_bounds()
+ In [271]: print ax.dataLim.bounds
     (1.0, 1.0, 5.0, 12.0)

     # we can manually invoke the auto-scaling machinery
Index: lib/matplotlib/finance.py

--- lib/matplotlib/finance.py (revision 8160)
+++ lib/matplotlib/finance.py (revision 8175)
@@ -597,8 +597,8 @@
     maxy = max([volume for d, open, close, high, low, volume in quotes])
     corners = (minpy, miny), (maxx, maxy)
     ax.update_datalim(corners)
- #print 'datalim', ax.dataLim.get_bounds()
- #print 'viewlim', ax.viewLim.get_bounds()
+ #print 'datalim', ax.dataLim.bounds
+ #print 'viewlim', ax.viewLim.bounds

     ax.add_collection(barCollection)
     ax.autoscale_view()
Index: lib/matplotlib/artist.py

--- lib/matplotlib/artist.py (revision 8160)
+++ lib/matplotlib/artist.py (revision 8175)
@@ -41,9 +41,9 @@
             renderer.stop_rasterizing()

     # the axes class has a second argument inframe for its draw method.
- def draw_wrapper(artist, renderer, *kl):
+ def draw_wrapper(artist, renderer, *args, **kwargs):
         before(artist, renderer)
- draw(artist, renderer, *kl)
+ draw(artist, renderer, *args, **kwargs)
         after(artist, renderer)

     # "safe wrapping" to exactly replicate anything we haven't overridden above
Index: lib/matplotlib/patches.py

--- lib/matplotlib/patches.py (revision 8160)
+++ lib/matplotlib/patches.py (revision 8175)
@@ -1383,12 +1383,12 @@
     pad = props.pop('pad', 4)
     pad = renderer.points_to_pixels(pad)
     bbox = artist.get_window_extent(renderer)
- l,b,w,h = bbox.bounds
- l-=pad/2.
- b-=pad/2.
- w+=pad
- h+=pad
- r = Rectangle(xy=(l,b),
+ l, b, w, h = bbox.bounds
+ l -= pad/2.
+ b -= pad/2.
+ w += pad
+ h += pad
+ r = Rectangle(xy=(l, b),
                   width=w,
                   height=h,
                   fill=fill,
@@ -1407,8 +1407,8 @@
     to test whether the artist is returning the correct bbox.
     """

- l,b,w,h = bbox.get_bounds()
- r = Rectangle(xy=(l,b),
+ l, b, w, h = bbox.bounds
+ r = Rectangle(xy=(l, b),
                   width=w,
                   height=h,
                   edgecolor=color,
@@ -3174,7 +3174,7 @@
                 cos_t, sin_t = get_cos_sin(x1, y1, x0, y0)
                 verticesA, codesA = self._get_bracket(x0, y0, cos_t, sin_t,
                                                       self.widthA*scaleA,
- self.legnthA*scaleA)
+ self.lengthA*scaleA)
                 vertices_list.append(verticesA)
                 codes_list.append(codesA)

Index: lib/matplotlib/backends/backend_wxagg.py

--- lib/matplotlib/backends/backend_wxagg.py (revision 8160)
+++ lib/matplotlib/backends/backend_wxagg.py (revision 8175)
@@ -171,7 +171,7 @@
     """
     Convert the region of a wx.Image bounded by bbox to a wx.Bitmap.
     """
- l, b, width, height = bbox.get_bounds()
+ l, b, width, height = bbox.bounds
     r = l + width
     t = b + height

@@ -238,7 +238,7 @@

     Note: agg must be a backend_agg.RendererAgg instance.
     """
- l, b, width, height = bbox.get_bounds()
+ l, b, width, height = bbox.bounds
     r = l + width
     t = b + height

The hexbin error was pre-existing and was introduced in a commit I
made to support LogNorm as arg to hexbin (r8149). I just committed a
new fix for this in HEAD

···

On Wed, Mar 3, 2010 at 3:23 PM, John Hunter <jdh2358@...287...> wrote:

OK, I just manually added this via a diff/patch. Keep your eyes out
for flakiness. I did try a matplotlib.test before committing and got
one error about the hexbin extent so there may be a little cleanup to
do. I ignored that because nothing in the diff I applied should
affect that so I thought it might be pre-existing or spurious