updated artist contains methods

Hi,

I went through all the demos in pylab_examples to make sure that
the artist.contains() method would return true when the mouse
is on the object. I fixed a number of problems caused by the
new transforms code (collections, lines and images were not
detected). A few issues remain, but they are not show stoppers.

Broken examples:

barcode_demo, image_interp, etc: wx doesn't implement draw_image
dannys_example: wx doesn't implement draw_tex
font_table_ttf: list index out of range
geo_demo: invalid value in projections.geo for x = ... / sinc_alpha
multi_image: AxesImage has no attribute add_observer
stix_fonts_demo: error
    UnicodeDecodeError: 'rawunicodeescape' codec can't decode
    bytes in position 39-0: \Uxxxxxxxx out of range
symlog_demo: rendering causes the following error
    File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
      assert len(point) == self.input_dims
running reindent.py causes lots of changes

Hit test issues:

barb_demo: detecting filled areas but not lines
dashtick: not detecting dash ticks, except by tick
date_demo2: rotated text uses bounding box rather than rotated rectangle
newscalarformatter_demo: axis offset label not detected
quiver_demo: 1 m/s arrow legend not detected
scatter_star_poly: plus and star not detected

If you want to turn on hit testing for a plot, use:

    gcf().canvas.mpl_connect("motion_notify_event",
                             gcf().canvas.onHilite)

- Paul

I went through all the demos in pylab_examples to make sure that
the artist.contains() method would return true when the mouse
is on the object. I fixed a number of problems caused by the
new transforms code (collections, lines and images were not
detected). A few issues remain, but they are not show stoppers.

Thanks for the comprehensive tests. I've had a minute to work on a
couple of these before I have to run out

Broken examples:

barcode_demo

fixed -- added to backend_driver

image_interp, etc: wx doesn't implement draw_image

I'm not too concerned about wx, and am somewhat inclined to pull it,
especially now that we have support for external backends so those who
need it can use it. I won't pull it for this cycle. Anyone who
loves wx, now is the time to step up andstart adding support for
missing features like images and mathtext.

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered. So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called. I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first. *please test*.

dannys_example: wx doesn't implement draw_tex

not concerned here about wx, but we need to make sure wxagg is working
here (confirmed)

font_table_ttf: list index out of range

punting for now

geo_demo: invalid value in projections.geo for x = ... / sinc_alpha

added to the sf bug tracker, assigned to Michael. Added to
backend_driver (failing now)

multi_image: AxesImage has no attribute add_observer

fixed in svn to use the new callbacks API for scalar mappables. Added
to backend_driver

OK, that's all I have time for now. I'll take a look at the others
later. Thanks a lot

JDH

···

On Sat, Jul 26, 2008 at 5:26 PM, Paul Kienzle <pkienzle@...149...> wrote:

stix_fonts_demo: error
   UnicodeDecodeError: 'rawunicodeescape' codec can't decode
   bytes in position 39-0: \Uxxxxxxxx out of range
symlog_demo: rendering causes the following error
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
     assert len(point) == self.input_dims
running reindent.py causes lots of changes

Hit test issues:

barb_demo: detecting filled areas but not lines
dashtick: not detecting dash ticks, except by tick
date_demo2: rotated text uses bounding box rather than rotated rectangle
newscalarformatter_demo: axis offset label not detected
quiver_demo: 1 m/s arrow legend not detected
scatter_star_poly: plus and star not detected

If you want to turn on hit testing for a plot, use:

   gcf().canvas.mpl_connect("motion_notify_event",
                            gcf().canvas.onHilite)

- Paul

-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Paul Kienzle wrote:

Hi,

I went through all the demos in pylab_examples to make sure that
the artist.contains() method would return true when the mouse
is on the object. I fixed a number of problems caused by the
new transforms code (collections, lines and images were not
detected). A few issues remain, but they are not show stoppers.

[...]

Hit test issues:

barb_demo: detecting filled areas but not lines
dashtick: not detecting dash ticks, except by tick
date_demo2: rotated text uses bounding box rather than rotated rectangle
newscalarformatter_demo: axis offset label not detected
quiver_demo: 1 m/s arrow legend not detected

I added a minimal contains method to QuiverKey, so I think this is at least partly fixed. The whole legend is detected. I left the returned dictionary empty.

Eric

···

scatter_star_poly: plus and star not detected

If you want to turn on hit testing for a plot, use:

    gcf().canvas.mpl_connect("motion_notify_event",
                             gcf().canvas.onHilite)

- Paul

-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

That one is my fault. I was having trouble getting start_event_loop
and draw_idle from Wx to trigger from WxAgg. I have no explanation
why it works now with Agg before Wx --- Agg should pick up the default
draw_idle from Base so WxAgg shouldn't try to look for it in Wx.

- Paul

···

On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jdh2358@...149...> wrote:

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered. So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called. I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first. *please test*.

You are right -- I just tested with the example below. We need to be
very careful here and make sure we are getting the methods we want
start_event_loop, draw_idle and friends) from the wx base class and
not the base base class, and need to understand why it is working if
it is (my guess is it is not but I haven't dived in yet). I think the
only way to do this is to put the wx base class first and then make
sure we override the print method in wxagg. My aversion to multiple
inheritance grows by the day.

class Base:
    def speak(self):
        print 'base'

class Agg(Base):
    pass

class Wx(Base):
    def speak(self):
        print 'wx'

class WXAgg(Agg,Wx):
    pass

wxagg = WXAgg()
wxagg.speak()

···

On Sun, Jul 27, 2008 at 7:43 AM, Paul Kienzle <pkienzle@...149...> wrote:

On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jdh2358@...149...> wrote:

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered. So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called. I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first. *please test*.

That one is my fault. I was having trouble getting start_event_loop
and draw_idle from Wx to trigger from WxAgg. I have no explanation
why it works now with Agg before Wx --- Agg should pick up the default
draw_idle from Base so WxAgg shouldn't try to look for it in Wx.

It doesn't appear to be working for me. To keep things simple, I am
working with backend_wx so there are no issues of diamond inheritance.
It just appears that the specialization is broken. I get this
endless loop when I try to run the demo -- I have some extra debug
prints inserted to see what is getting called. Eg when I start the
example, a window pops up with the "you will define a triangle" title,
and the following is printed to the console

  home:~/mpl/examples/pylab_examples> python ginput_manual_clabel.py -dWX
  You will define a triangle, click to begin
  BlockingInput.__call__: calling canvas.start_event_loop
<matplotlib.backends.backend_wx.FigureCanvasWx; proxy of <Swig Object
of type 'wxPanel *' at 0xff091a0> >
  FigureCanvasWx.start_event_loop

and then it waits for me. When I click just a single time on the axes
to select a point, before I can actually select the points for the
triangle, it enters the following loop and the console prints the
output

    FigureCanvasWx.stop_event_loop
    BlockingInput.__call__: finally
    Select 3 corners with mouse
    BlockingInput.__call__: calling canvas.start_event_loop
<matplotlib.backends.backend_wx.FigureCanvasWx; proxy of <Swig Object
of type 'wxPanel *' at 0xff091a0> >
    FigureCanvasWx.start_event_loop
    BlockingInput.__call__: finally
    Too few points, starting over
    Select 3 corners with mouse
    BlockingInput.__call__: calling canvas.start_event_loop
<matplotlib.backends.backend_wx.FigureCanvasWx; proxy of <Swig Object
of type 'wxPanel *' at 0xff091a0> >
    FigureCanvasWx.start_event_loop
    BlockingInput.__call__: finally
    Too few points, starting over
    Select 3 corners with mouse
    BlockingInput.__call__: calling canvas.start_event_loop
<matplotlib.backends.backend_wx.FigureCanvasWx; proxy of <Swig Object
of type 'wxPanel *' at 0xff091a0> >
    FigureCanvasWx.start_event_loop
    BlockingInput.__call__: finally
    Too few points, starting over
    Select 3 corners with mouse
    BlockingInput.__call__: calling canvas.start_event_loop
<matplotlib.backends.backend_wx.FigureCanvasWx; proxy of <Swig Object
of type 'wxPanel *' at 0xff091a0> >
    FigureCanvasWx.start_event_loop
    FigureCanvasWx.stop_event_loop
    BlockingInput.__call__: finally

and so on endlessly until I finally click 'x' to close the figure, I
get the following dead object error

raceback (most recent call last):
  File "ginput_manual_clabel.py", line 40, in <module>
    pts = np.asarray( plt.ginput(3,timeout=-1) )
  File "/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/pyplot.py",
line 355, in ginput
    return gcf().ginput(*args, **kwargs)
  File "/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/figure.py",
line 1041, in ginput
    show_clicks=show_clicks)
  File "/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/blocking_input.py",
line 239, in __call__
    BlockingInput.__call__(self,n=n,timeout=timeout)
  File "/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/blocking_input.py",
line 109, in __call__
    self.cleanup()
  File "/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/blocking_input.py",
line 226, in cleanup
    self.fig.canvas.draw()
  File "//Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.py",
line 14029, in __getattr__
    raise PyDeadObjectError(self.attrStr % self._name)
wx._core.PyDeadObjectError: The C++ part of the FigureCanvasWx object
has been deleted, attribute access no longer allowed.

On a separate note, I also see the strangeness you are seeing with the
multiple inheritance order. When I run the example with backend
wxagg, I get the wx specialization called even though FigureCanvasAgg
is defined first in the multiple inheritance heirarchy and so the base
method should be picked up. And yet when I try and replicate this in
test code, I always get the base class method ... Looks like we've
got some work to do to sort all of this out.

    class Base:
        def speak(self, timeout):
            raise NotImplementedError

    class Agg(Base):
        pass

    class Wx(Base):
        def speak(self, timeout):
            print 'wx'

    class WXAgg(Agg,Wx):
        pass

    wxagg = WXAgg()
    wxagg.speak(timeout=1)

Here is my version info -- running on os x leopard with

home:~/mpl/examples/pylab_examples> python simple_plot.py
--verbose-helpful -dWX$HOME=/Users/jdhunter
CONFIGDIR=/Users/jdhunter/.matplotlib
matplotlib data path
/Users/jdhunter/dev/lib/python2.5/site-packages/matplotlib/mpl-data
loaded rc file /Users/jdhunter/.matplotlib/matplotlibrc
matplotlib version 0.98.3rc1
verbose.level helpful
interactive is False
units is False
platform is darwin
Using fontManager instance from /Users/jdhunter/.matplotlib/fontManager.cache
backend WX version 2.8.3.0

···

On Sun, Jul 27, 2008 at 7:43 AM, Paul Kienzle <pkienzle@...149...> wrote:

On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jdh2358@...149...> wrote:

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered. So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called. I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first. *please test*.

That one is my fault. I was having trouble getting start_event_loop
and draw_idle from Wx to trigger from WxAgg. I have no explanation
why it works now with Agg before Wx --- Agg should pick up the default
draw_idle from Base so WxAgg shouldn't try to look for it in Wx.

One possibility: since FigureCanvasWx inherits not only from
FigureCanvasBase, but also wx.Panel which is a SWIG object (eg look at
the repr of FigureCanvasWXAgg)

  <matplotlib.backends.backend_wxagg.FigureCanvasWxAgg; proxy of <Swig
Object of type 'wxPanel *' at 0x10117b30> >

is it possible that the swig part is doing some deep magic that screws
w/ the normal python mulitlple inheritance lookup ?

I just confirmed that something like this appears to be the case -- if
you add the wx panel to the multiple inheritance test case below, the
wx method gets called instead of the base

   import wx

    class Base:
        def __init__(self, x):
            self.x = 1

        def speak(self, timeout):
            raise NotImplementedError

    class Agg(Base):
        pass

    class Wx(Base, wx.Panel):
        def __init__(self, x):
            Base.__init__(self, x)

        def speak(self, timeout):
            print 'wx'

    class WXAgg(Agg,Wx):
        pass

    wxagg = WXAgg('hi')
    wxagg.speak(timeout=1)

Is this platform specific? I am seein this on os x w/ my versions but
am curious to know if it is consistent. God help us all.

One possibility is that since wx.Panel implemented __getattribute__,
it may be screwing up the python implementation of multiple
inheritance if it depends on getattr, eg I found the following on
__getattribute__:

__getattribute__( self, name)
Called unconditionally to implement attribute accesses for
instances of the class. If the class also defines __getattr__, it will
never be called (unless called explicitly). This method should return
the (computed) attribute value or raise an AttributeError exception. In
order to avoid infinite recursion in this method, its implementation
should always call the base class method with the same name to access
any attributes it needs, for example, "object.__getattribute__(self,
name)".
"""

Just grasping at straws here...

JDH

···

On Sun, Jul 27, 2008 at 11:28 AM, John Hunter <jdh2358@...149...> wrote:

On a separate note, I also see the strangeness you are seeing with the
multiple inheritance order. When I run the example with backend
wxagg, I get the wx specialization called even though FigureCanvasAgg
is defined first in the multiple inheritance heirarchy and so the base
method should be picked up. And yet when I try and replicate this in
test code, I always get the base class method ... Looks like we've
got some work to do to sort all of this out.

Yup. The problem is with diamond inheritance. Mixins tend not to
have this problem since they are not defining default behaviour,
but instead are adding particular behaviours to a given class hierarchy.

For the current situation we have a couple of options. One is
to separate the drawing backend (Renderer) completely from the
interaction backend (Canvas). This is mostly done already, and
may not take that much effort to complete. The faster and good
enough solution is to move the GUI parts of Wx into WxAgg and
deprecate Wx.

I don't understand why the current code seems to work. I put
print statements in Wx.draw_idle and WxAgg.draw and both
were called. I'll verify later if I get a chance.

  - Paul

···

On Sun, Jul 27, 2008 at 10:20 AM, John Hunter <jdh2358@...149...> wrote:

On Sun, Jul 27, 2008 at 7:43 AM, Paul Kienzle <pkienzle@...149...> wrote:

On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jdh2358@...149...> wrote:

But this example revealed a serious problem for wxagg -- the wx
backend save method was getting triggered. So wxagg couuld display an
image, but if we try to save it, it fails because backend_wx's
print_figure is getting called. I fixed this by reversing the order
of the inheritance in FigureCanvasWXAgg so that FigureCanvasAgg is
first. *please test*.

That one is my fault. I was having trouble getting start_event_loop
and draw_idle from Wx to trigger from WxAgg. I have no explanation
why it works now with Agg before Wx --- Agg should pick up the default
draw_idle from Base so WxAgg shouldn't try to look for it in Wx.

You are right -- I just tested with the example below. We need to be
very careful here and make sure we are getting the methods we want
start_event_loop, draw_idle and friends) from the wx base class and
not the base base class, and need to understand why it is working if
it is (my guess is it is not but I haven't dived in yet). I think the
only way to do this is to put the wx base class first and then make
sure we override the print method in wxagg. My aversion to multiple
inheritance grows by the day.

stix_fonts_demo: error
   UnicodeDecodeError: 'rawunicodeescape' codec can't decode
   bytes in position 39-0: \Uxxxxxxxx out of range

I'm pretty sure this is the result of a python build that does not
have support for wide unicode characters (this is a build time
configuration issue). It is not really an mpl bug, but I am going to
comment out the wide unicode line and add the example the
backend_driver (Michael, is there a way to check and see if the python
build has support for wide unicode at runtime so this line is included
conditionally?)

symlog_demo: rendering causes the following error
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
     assert len(point) == self.input_dims

I created a ticket on sf
(http://sourceforge.net/tracker/index.php?func=detail&aid=2029141&group_id=80706&atid=560720)
and assigned it to Michael since this is his baby. I also added the
demo to backend driver (currently failing)

···

On Sat, Jul 26, 2008 at 6:26 PM, John Hunter <jdh2358@...149...> wrote:

On Sun, Jul 27, 2008 at 12:28 PM, John Hunter <jdh2358@...149...>

[ginput_manual_clabel] doesn't appear to be working for me. To keep things simple, I am
working with backend_wx so there are no issues of diamond inheritance.
It just appears that the specialization is broken. I get this
endless loop when I try to run the demo

I didn't test with multiple calls to ginput. Apparently I can't reuse
the wx EventLoop. I posted a fix to backend_wx which creates a
new event loop each time, and now it works for me on wx-2.8.3
for macos 10.4.

On a separate note, I also see the strangeness you are seeing with the
multiple inheritance order. When I run the example with backend
wxagg, I get the wx specialization called even though FigureCanvasAgg
is defined first in the multiple inheritance heirarchy and so the base
method should be picked up. And yet when I try and replicate this in
test code, I always get the base class method ... Looks like we've
got some work to do to sort all of this out.

My inclination is to avoid diamond inheritance in this case by
moving the wx base class to wxagg. Let me know and I will
implement it.

It would be helpful to run through the tests for wx on linux and on
windows before a release. Particularly ginput_manual_clabel
for start/stop event loop. I can't think of how to test for draw_idle
short of putting a print statement in the window, or using a complicated
plot like multi_image and continuously resizing the window.

There is one more outstanding change to wx before I can stop
subclassing the WxAgg canvas in my own applications, which is
that draw is being called too often. Putting a print statement in
WxAgg draw and _onPaint I get the following:

$ python mri_demo.py
wxPaintEvt
WxAgg draw
WxAgg draw
wxPaintEvt
WxAgg draw
WxAgg draw
<image finally shown on screen; click close button>
wxPaintEvt
WxAgg draw
wxPaintEvt
WxAgg draw

By contrast TkAgg shows:

$ python mri_demo.py
tk draw

I don't have a patch for this ready, though I can get it down to two
draws by putting a draw_idle in _onPaint. I'll hold off committing
until I get it down to one.

  - Paul

My inclination is to avoid diamond inheritance in this case by
moving the wx base class to wxagg. Let me know and I will
implement it.

My weak preference would be to do this as a mixin factorint out the
renderer from the GUI stuff. If this is only marginally harder, it
makes it easier down the road if someone wants to mixin a different
renderer from agg, or if the wx renderer ever improces sufficiently to
make it usable. But if this seems like a lot more work, I am not
averse to simply deprecating the wx renderer, though factoring
everything to make mixing in a different renderer later will still be
useful. In the end, whatever you decide will be fine.

There is one more outstanding change to wx before I can stop
subclassing the WxAgg canvas in my own applications, which is
that draw is being called too often. Putting a print statement in
WxAgg draw and _onPaint I get the following:

OK, now that we have missed the debian freeze, the pressure to get
something out sooner is lessened, do we'll just work on getting it
right.

JDH

···

On Sun, Jul 27, 2008 at 4:57 PM, Paul Kienzle <pkienzle@...149...> wrote:

My inclination is to avoid diamond inheritance in this case by
moving the wx base class to wxagg. Let me know and I will
implement it.

My weak preference would be to do this as a mixin factorint out the
renderer from the GUI stuff. If this is only marginally harder, it
makes it easier down the road if someone wants to mixin a different
renderer from agg, or if the wx renderer ever improces sufficiently to
make it usable. But if this seems like a lot more work, I am not
averse to simply deprecating the wx renderer, though factoring
everything to make mixing in a different renderer later will still be
useful. In the end, whatever you decide will be fine.

I won't be able to spend time on this short term --- it took me too
long to sort out containment and drawing.

There is one more outstanding change to wx before I can stop
subclassing the WxAgg canvas in my own applications, which is
that draw is being called too often. Putting a print statement in
WxAgg draw and _onPaint I get the following:

OK, now that we have missed the debian freeze, the pressure to get
something out sooner is lessened, do we'll just work on getting it
right.

I hope that wasn't on account of wx. These were not show-stopper
issues.

Since we are not under pressure, I committed another set of changes
to Wx+WxAgg. Now they should only render the graph when the
window is shown. I would appreciate having windows and linux users
beat on it for a while, in particular testing lasso_demo before and after
printing.

I'm also attaching embedding_in_wx5.py, which puts a pair of graphs
into a wx notebook.

   - Paul

embedding_in_wx5.py (1.46 KB)

···

On Sun, Jul 27, 2008 at 9:54 PM, John Hunter <jdh2358@...149...> wrote:

On Sun, Jul 27, 2008 at 4:57 PM, Paul Kienzle <pkienzle@...149...> wrote:

John Hunter wrote:

symlog_demo: rendering causes the following error
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
     assert len(point) == self.input_dims
    

I can't reproduce this here. Has this been resolved in the meantime?

Cheers,
Mike

···

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

"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",

line 1072, in transform_point
    assert len(point) == self.input_dims

I can't reproduce this here. Has this been resolved in the meantime?

Yes, I fixed it -- it was a bug in ticker.py that was calling
transform_point rather than transform. I meant to update the list,
sorry if I screwed up the send button

JDH

···

On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <mdroe@...31...> wrote:

John Hunter wrote:

stix_fonts_demo: error
   UnicodeDecodeError: 'rawunicodeescape' codec can't decode
   bytes in position 39-0: \Uxxxxxxxx out of range
      
I'm pretty sure this is the result of a python build that does not
have support for wide unicode characters (this is a build time
configuration issue). It is not really an mpl bug, but I am going to
comment out the wide unicode line and add the example the
backend_driver (Michael, is there a way to check and see if the python
build has support for wide unicode at runtime so this line is included
conditionally?)
  

One can use sys.maxunicode. I've added a check to stix_fonts_demo.py

  

symlog_demo: rendering causes the following error
   File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
line 1072, in transform_point
     assert len(point) == self.input_dims
      
I created a ticket on sf
(http://sourceforge.net/tracker/index.php?func=detail&aid=2029141&group_id=80706&atid=560720)
and assigned it to Michael since this is his baby. I also added the
demo to backend driver (currently failing)

Thanks. Your fix mentioned in the bug report looks fine. The reason it broke is pretty subtle but I think that's right. I'll close the bug.

Cheers,
Mike

···

On Sat, Jul 26, 2008 at 6:26 PM, John Hunter <jdh2358@...149...> wrote:

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

No, you didn't screw up. It's just hard to arrive home to a pile of 1000's of e-mails... :wink:

Cheers,
Mike

John Hunter wrote:

···

On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <mdroe@...31...> wrote:
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/transforms.py",
  

line 1072, in transform_point
    assert len(point) == self.input_dims

I can't reproduce this here. Has this been resolved in the meantime?
    
Yes, I fixed it -- it was a bug in ticker.py that was calling
transform_point rather than transform. I meant to update the list,
sorry if I screwed up the send button

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

well, you are pressing through them with a remarkable terminator like
efficiency.

welcome back :slight_smile:

JDH

···

On Thu, Jul 31, 2008 at 10:05 AM, Michael Droettboom <mdroe@...31...> wrote:

No, you didn't screw up. It's just hard to arrive home to a pile of 1000's
of e-mails... :wink: