matplotlib-devel Mailing List for matplotlib (Page 3)

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 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:24 PM, John Hunter <jd...@gm...> wrote:

>        if midPoint:
>            if self.gridOn:
>                self.gridline.draw(renderer)
>            if self.tick1On:
>                self.tick1line.draw(renderer)
>            if self.tick2On:
>                self.tick2line.draw(renderer)

For a little extra color on what is going on here -- we don't want to
automatically clip the tick lines to the axes bounding box because
someone might choose the tick direction 'out'.  Since we can't use
graphical clipping, this test is trying to make sure the tick location
is in the view interval before drawing it.  You may want to consider a
overridable method 'is_draw_tick' or something along those lines,
which defaults to::

  mtransforms.interval_contains(self.get_view_interval(), self.get_loc())

JDH

On Sun, Jul 27, 2008 at 3:57 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Can anyone explain how the clipping code works?  Or maybe how the backends
> decide whether to draw a line?  In working on drawing skewT's, I need
> slanted gridlines.  Through proper setting of transforms, I can get them to
> draw slanted fine, but because they are slanted, the data x range at the top
> of the plot is not equal to the data x range at the bottom.

The clipping code works as you would expect -- you pass it a path and
the artist is clipped to that path.  I think you are being bitten by
something else (see below)

> One issue that crops up as a result (which I've mentioned before) is that
> the tickmarks at the top get drawn off past the right end of the plot
> (enabling clipping of ticklines fixes this).

Yes, you probably want to clip them

> The second issue, which is the focus here, is that it seems impossible to
> get matplotlib to draw any gridlines that start before the left side of the
> chart.  I can tweak Axis.draw() and get it to draw *all* the currently set
> tick marks and I can disable clipping so that the gridlines draw past the
> *right* side of the plot, but I can't seem to figure out how to draw a grid
> lines that starts from off the left side.

Look in the axis at the method:

    def draw(self, renderer):
        if not self.get_visible(): return
        renderer.open_group(self.__name__)
        midPoint =
mtransforms.interval_contains(self.get_view_interval(),
self.get_loc())

        if midPoint:
            if self.gridOn:
                self.gridline.draw(renderer)
            if self.tick1On:
                self.tick1line.draw(renderer)
            if self.tick2On:
                self.tick2line.draw(renderer)

The is midPoint is causing your troubles.  Replace that with 'if 1 or
midPoint' and your grids magically appear.  You may want to insert
some logic here so that custom classes can override this behavior.

You mentioned you were using GTK -- clipping is not properly supported
using the gdk renderer, so make sure you are using GTKAgg (or some
other Agg variant) for your UI while testing clipping.

JDH

"John Hunter" <jd...@gm...> writes:

> On Sun, Jul 27, 2008 at 12:39 PM, Mikhail Gusarov
> <dot...@do...> wrote:
> > Twas brillig at 12:30:39 27.07.2008 UTC-05 when jd...@gm... did gyre and gimble:
> >
> >  JH> Mikhail, if you are so inclined and there is still time, you may
> >  JH> want to see if Georg wants to put out another point release that
> >  JH> fixes this problem, and push the fix into the debian pipeline.
> >
> > Well, freeze just was declared, so I'll need to request an exception for
> > sphinx, as well as you for mpl :-|
> >
> > It will help if you file a RC bug for sphinx :)
> 
> I'll be happy to, but should I wait until there is actually a sphinx
> release out with the bugfix in it?

No, don't wait. Debian packages can included patches if necessary. 

Pointing at the fix in svn (in the bug report) would be helpful.

Chris

Hi,

Can anyone explain how the clipping code works?  Or maybe how the 
backends decide whether to draw a line?  In working on drawing skewT's, 
I need slanted gridlines.  Through proper setting of transforms, I can 
get them to draw slanted fine, but because they are slanted, the data x 
range at the top of the plot is not equal to the data x range at the bottom.

One issue that crops up as a result (which I've mentioned before) is 
that the tickmarks at the top get drawn off past the right end of the 
plot (enabling clipping of ticklines fixes this).

The second issue, which is the focus here, is that it seems impossible 
to get matplotlib to draw any gridlines that start before the left side 
of the chart.  I can tweak Axis.draw() and get it to draw *all* the 
currently set tick marks and I can disable clipping so that the 
gridlines draw past the *right* side of the plot, but I can't seem to 
figure out how to draw a grid lines that starts from off the left side.

I've attached a small example of what I'm trying to do and an example of 
the results I'm getting with a few of the mods I've done to MPL (also 
attached).

Can anybody point me where I've gone wrong?  I traced the calls down to 
the renderer (in this case GTK), but they for some reason won't trace 
down any further.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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)

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 12:39 PM, Mikhail Gusarov
<dot...@do...> wrote:
> Twas brillig at 12:30:39 27.07.2008 UTC-05 when jd...@gm... did gyre and gimble:
>
>  JH> Mikhail, if you are so inclined and there is still time, you may
>  JH> want to see if Georg wants to put out another point release that
>  JH> fixes this problem, and push the fix into the debian pipeline.
>
> Well, freeze just was declared, so I'll need to request an exception for
> sphinx, as well as you for mpl :-|
>
> It will help if you file a RC bug for sphinx :)

I'll be happy to, but should I wait until there is actually a sphinx
release out with the bugfix in it?

JDH

Twas brillig at 12:30:39 27.07.2008 UTC-05 when jd...@gm... did gyre and gimble:

 JH> Mikhail, if you are so inclined and there is still time, you may
 JH> want to see if Georg wants to put out another point release that
 JH> fixes this problem, and push the fix into the debian pipeline.

Well, freeze just was declared, so I'll need to request an exception for
sphinx, as well as you for mpl :-|

It will help if you file a RC bug for sphinx :)

-- 

On Sun, Jul 27, 2008 at 19:30, John Hunter <jd...@gm...> wrote:
> Mikhail, if you are so inclined and there is still time, you may want
> to see if Georg wants to put out another point release that fixes this
> problem, and push the fix into the debian pipeline.

Just as a note: today @ ~16.00 CEST the Lenny freeze was announced.
>From now on, it will be very difficult to have new stuff in Lenny.

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sun, Jul 27, 2008 at 11:05 AM, Sandro Tosi <mat...@gm...> wrote:
>> The docs require sphinx 0.4, which if I recall correctly, we got
>> pushed into debian on short notice precisely to support the mpl docs.
>>  What version of sphinx are you using?
>
> I'm using v0.4.1 or it's a strict depends on 0.4 only?

OK, this is a major SNAFU.  Michael Droetboom wrote show-inheritance
for matplotlib and it was included in sphinx.  Sphinx released this in
0.4 and we got this packaged into debian in a concerted push so that
we could get mpl into debian with working docs.  In the meantime, a
point release 0.4.1  of sphinx came out that broke the automodule
support on Jul 5th, and this broken version is now the one you have in
debian. On Jul 8th, Darren noticed the breakage, reported it on the
Sphinx mailing list, and it was fixed again in svn, but there has been
no sphinx point release.

Mikhail, if you are so inclined and there is still time, you may want
to see if Georg wants to put out another point release that fixes this
problem, and push the fix into the debian pipeline.

JDH

Nils Wagner wrote:
> Hi all,
> 
> I found a new bug
> 
> $HOME=/home/nwagner
> matplotlib data path 
> /usr/lib/python2.4/site-packages/matplotlib/mpl-data
> loaded rc file /home/nwagner/matplotlibrc
> matplotlib version 0.98.3rc1
> verbose.level helpful
> interactive is False
> units is False
> platform is linux2
> CONFIGDIR=/home/nwagner/.matplotlib
> Using fontManager instance from 
> /home/nwagner/.matplotlib/fontManager.cache
> backend WXAgg version 2.5.3.1
> 
>      spy(K_bc)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 2237, in spy
>      b = ishold()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 466, in ishold
>      return gca().ishold()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 566, in gca
>      ax =  gcf().gca(**kwargs)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 270, in gcf
>      return figure()
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
> line 247, in figure
>      FigureClass=FigureClass,
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> line 119, in new_figure_manager
>      frame = FigureFrameWxAgg(num, fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 1332, in __init__
>      self.canvas = self.get_canvas(fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> line 32, in get_canvas
>      return FigureCanvasWxAgg(self, -1, fig)
>    File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 734, in __init__
>      self.idletimer = wx.CallLater(1,self._onDrawIdle)
> AttributeError: 'module' object has no attribute 
> 'CallLater'

It looks like this was introduced in wxPython 2.7.1: 
http://mail.python.org/pipermail/python-announce-list/2006-October/005326.html

I have changed backend_wx to use the backwards-compatible alias, FutureCall.

Eric

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 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

> The docs require sphinx 0.4, which if I recall correctly, we got
> pushed into debian on short notice precisely to support the mpl docs.
>  What version of sphinx are you using?

I'm using v0.4.1 or it's a strict depends on 0.4 only?

I'm attaching the log for the build, it might be helpful.

Thanks,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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 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

Hi all,

I found a new bug

$HOME=/home/nwagner
matplotlib data path 
/usr/lib/python2.4/site-packages/matplotlib/mpl-data
loaded rc file /home/nwagner/matplotlibrc
matplotlib version 0.98.3rc1
verbose.level helpful
interactive is False
units is False
platform is linux2
CONFIGDIR=/home/nwagner/.matplotlib
Using fontManager instance from 
/home/nwagner/.matplotlib/fontManager.cache
backend WXAgg version 2.5.3.1

     spy(K_bc)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 2237, in spy
     b = ishold()
   File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 466, in ishold
     return gca().ishold()
   File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 566, in gca
     ax =  gcf().gca(**kwargs)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 270, in gcf
     return figure()
   File 
"/usr/lib/python2.4/site-packages/matplotlib/pyplot.py", 
line 247, in figure
     FigureClass=FigureClass,
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
line 119, in new_figure_manager
     frame = FigureFrameWxAgg(num, fig)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1332, in __init__
     self.canvas = self.get_canvas(fig)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
line 32, in get_canvas
     return FigureCanvasWxAgg(self, -1, fig)
   File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 734, in __init__
     self.idletimer = wx.CallLater(1,self._onDrawIdle)
AttributeError: 'module' object has no attribute 
'CallLater'


Nils

John Hunter wrote:
> On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
> 
>> The attached script gives a quick and simple illustration of the pdf backend
>> memory leak noted earlier by Paul Kienzle.  It seems to be entirely related
>> to rendering text.  Adding axes, lines, and images does not seem to matter,
>> except insofar as adding an axes will trigger the rendering of text for the
>> tick labels.  The leak per loop is roughly proportional to the number of
>> *different* characters being rendered--about 100 bytes per character.
>>
>> I don't think I could find the leak in any reasonable time; I hope someone
>> else who is more familiar with the pdf backend and more clever at such
>> things will be able to track it down ASAP.
> 
> In the past, if I recall correctly, these leaks have been in ttconv,
> which is Michael's area of expertise, so let's see if he has any
> flashes of insight Monday...  If this is the case it would likely
> affect ps and pdf but not the other backends.
> 
> JDH

The ps backend leak with this test is about 70 bytes/loop, and the same 
with either 20 or 10 characters, so it may have a different origin than 
the pdf leak; with no suptitle at all, the ps backend leak is 0.  svg 
and agg are both 0 in this test (with suptitle included).

Eric

On Sat, Jul 26, 2008 at 7:20 PM, Eric Firing <ef...@ha...> wrote:

> The attached script gives a quick and simple illustration of the pdf backend
> memory leak noted earlier by Paul Kienzle.  It seems to be entirely related
> to rendering text.  Adding axes, lines, and images does not seem to matter,
> except insofar as adding an axes will trigger the rendering of text for the
> tick labels.  The leak per loop is roughly proportional to the number of
> *different* characters being rendered--about 100 bytes per character.
>
> I don't think I could find the leak in any reasonable time; I hope someone
> else who is more familiar with the pdf backend and more clever at such
> things will be able to track it down ASAP.

In the past, if I recall correctly, these leaks have been in ttconv,
which is Michael's area of expertise, so let's see if he has any
flashes of insight Monday...  If this is the case it would likely
affect ps and pdf but not the other backends.

JDH

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

The attached script gives a quick and simple illustration of the pdf 
backend memory leak noted earlier by Paul Kienzle.  It seems to be 
entirely related to rendering text.  Adding axes, lines, and images does 
not seem to matter, except insofar as adding an axes will trigger the 
rendering of text for the tick labels.  The leak per loop is roughly 
proportional to the number of *different* characters being 
rendered--about 100 bytes per character.

I don't think I could find the leak in any reasonable time; I hope 
someone else who is more familiar with the pdf backend and more clever 
at such things will be able to track it down ASAP.

Eric

Eric Firing wrote:
> Andrew Straw wrote:
>> Hi all,
>>
>> I've added some functionality to my copy hexbin, and I thought I'd
>> bounce it off folks (esp. Michael) to see if it seems like a good idea
>> to add it to MPL.
>>
>> Here's the beginning of the docstring of the new version. What I've
>> added is the optional argument "C" -- inspired by scatter's "c" argument.
>>
>>> call signature::
>>>
>>>   hexbin(x, y, C = None, gridsize = 100, bins = None,
>>>          xscale = 'linear', yscale = 'linear',
>>>          cmap=None, norm=None, vmin=None, vmax=None,
>>>          alpha=1.0, linewidths=None, edgecolors='none'
>>>          reduce_C_function = np.mean,
>>>          **kwargs)
>>>
>>> Make a hexagonal binning plot of *x* versus *y*, where *x*,
>>> *y* are 1-D sequences of the same length, *N*. If *C* is None
>>> (the default), this is a histogram of the number of occurences
>>> of the observations at (x[i],y[i]).
>>>
>>> If *C* is specified, it specifies values at the coordinate
>>> (x[i],y[i]). These values are accumulated for each hexagonal
>>> bin and then reduced according to *reduce_C_function*, which
>>> defaults to numpy's mean function (np.mean). (If *C* is
>>> specified, it must also be a 1-D sequence of the same length
>>> as *x* and *y*.)
>>
>> What do you think? I've also implemented a simple demo making use of
>> this functionality and an image of the output of the demo. For my own
>> selfish reasons, I'd love if we could stick this in 0.98.3, but I'm also
>> happy to hold off to get the release out the door.
>>
>> -Andrew
> 
> Andrew,
> 
> That sounds like a nice addition, and one that does not interfere in any
> way with the original hexbin functionality.
> 
> Eric

OK, with John and Eric's encouragement, I've gone ahead and checked this
into svn along with the new example in pylab
(pylab_examples/hexbin_demo2.py). I've been pounding away on it all
afternoon, and haven't found any problems, and I left the original
functionality of hexbin() untouched, so I doubt this will cause a
problem for anyone.

-Andrew

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
>