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
On Sat, Jul 26, 2008 at 5:26 PM, Paul Kienzle <pki...@gm...> wrote:
> 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
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
On Sat, Jul 26, 2008 at 6:26 PM, John Hunter <jd...@gm...> 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?) >> 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)
John Hunter wrote: > On Sat, Jul 26, 2008 at 6:26 PM, John Hunter <jd...@gm...> 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 -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA
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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jd...@gm...> 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. - Paul
On Sun, Jul 27, 2008 at 7:43 AM, Paul Kienzle <pki...@gm...> wrote: > On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jd...@gm...> 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. 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 10:20 AM, John Hunter <jd...@gm...> wrote: > On Sun, Jul 27, 2008 at 7:43 AM, Paul Kienzle <pki...@gm...> wrote: >> On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jd...@gm...> 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. 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 7:43 AM, Paul Kienzle <pki...@gm...> wrote: > On Sat, Jul 26, 2008 at 7:26 PM, John Hunter <jd...@gm...> 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 11:28 AM, John Hunter <jd...@gm...> 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.
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 12:28 PM, John Hunter <jd...@gm...> > [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
On Sun, Jul 27, 2008 at 4:57 PM, Paul Kienzle <pki...@gm...> 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. > 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 9:54 PM, John Hunter <jd...@gm...> wrote: > On Sun, Jul 27, 2008 at 4:57 PM, Paul Kienzle <pki...@gm...> 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
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
On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <md...@st...> 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
No, you didn't screw up. It's just hard to arrive home to a pile of 1000's of e-mails... ;) Cheers, Mike John Hunter wrote: > On Thu, Jul 31, 2008 at 9:33 AM, Michael Droettboom <md...@st...> 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
On Thu, Jul 31, 2008 at 10:05 AM, Michael Droettboom <md...@st...> wrote: > No, you didn't screw up. It's just hard to arrive home to a pile of 1000's > of e-mails... ;) well, you are pressing through them with a remarkable terminator like efficiency. welcome back :-) JDH