matplotlib-devel Mailing List for matplotlib (Page 2)

On 2008年7月29日 13:01:04 -0500
 "John Hunter" <jd...@gm...> wrote:
> On Tue, Jul 29, 2008 at 11:19 AM, Nils Wagner
> <nw...@ia...> wrote:
> 
>> Is that correct ?
>>
>> I will try it asap.
>>
>> Thanks in advance
> 
> OK, I just added a compatibility method for 
>isShownOnScreen. Can you
> give svn another test drive with your wx version, Nils?
> 
> Thanks,
> JDH
 
Hi John,
My wxpython version (2.5.3.1) seems to be outdated.
Anyway, is there any workaround ?
 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 125, in new_figure_manager
 frame = FigureFrameWxAgg(num, fig)
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
line 1346, 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 701, in __init__
 self.IsShownOnScreen = self.IsVisible
AttributeError: 'FigureCanvasWxAgg' object has no 
attribute 'IsVisible'
Nils

On Tue, Jul 29, 2008 at 11:19 AM, Nils Wagner
<nw...@ia...> wrote:
> Is that correct ?
>
> I will try it asap.
>
> Thanks in advance
OK, I just added a compatibility method for isShownOnScreen. Can you
give svn another test drive with your wx version, Nils?
Thanks,
JDH

On Tue, Jul 29, 2008 at 10:20 AM, Manuel Metz <mm...@as...> wrote:
> [ 2008303 ] AttributeError: Unknown property histtype
>
> I think this bug can be closed.
OK, do you want to take care of it?

On Mon, Jul 28, 2008 at 2:32 PM, Paul Kienzle <pki...@ni...> wrote:
> Clearly I'm developing on 2.8, otherwise I wouldn't be introducing
> so many issues for older versions. What version do people want
> supported?
For wxagg, we would like to support 2.6.3.2.2 and later (if it is not
too much work) since this is the version in lenny testing. I think
they've had a little trouble For wx native rendering, we must use 2.8
or later (if we are going to support this at all). So if you could
add the IsVisible compatibility layer to wxagg, that would be great.,
this would be ideal
JDH

On 2008年7月29日 12:10:09 -0400
 Paul Kienzle <pki...@ni...> wrote:
> On Tue, Jul 29, 2008 at 05:46:59PM +0200, Nils Wagner 
>wrote:
>> On 2008年7月28日 15:32:38 -0400
>> >> WxPython experts: what version do we require? If it 
>>is 
>> >>earlier than 
>> >> 2.8, then it appears we badly need a testing 
>>procedure 
>> >>to ensure 
>> >> compatibility. (A testing procedure for python 
>>version 
>> >>compatibility 
>> >> would be nice, also--has anyone looked into what it 
>> >>would take to set up 
>> >> and run a buildbot?)
> 
> Rather than cycling through the mailing list for each
> individual problem, can you please put together a patch
> that works on wx-2.6?
> 
> Preferably program to the 2.8 interface so that we don't
> build up too much cruft. For example, 
>IsVisible->IsShownOnScreen
> can be handled in __init__ with (untested!):
> 
> if not hasattr(self,'IsShownOnScreen'):
> 	self.IsShownOnScreen = self.IsVisible
> 
> I would like to test the changes on 2.8, but I'm gone
> July 31 to after Scipy.
> 
> - Paul 
Hi Paul,
Thank you for your prompt reply.
Where should I add the lines
if not hasattr(self,'IsShownOnScreen'):
 	self.IsShownOnScreen = self.IsVisible
I assume the corresponding file is in the directory
matplotlib/lib/matplotlib/backends
Is that correct ?
I will try it asap.
Thanks in advance
Nils

[ 2008303 ] AttributeError: Unknown property histtype
I think this bug can be closed.

Hi,
Sorry I didn't respond to this immediately - I have had my mind on other
things. plotyy is basically a wrapper around twinx that provides a bit
of extra/built-in functionality. The idea is that you have two curves
with similar x values, but different y that you want to plot together.
It plots them both using twinx, but to help with visualisation, it
changes the color of each curve and associated axis so that they are
easy to distinguish (e.g., left blue, right green). This is also
similar to a matlab function of the same name, so it helps us matlab
converts out.
An example of using this function might be:
x = linspace(0,pi,20)
y = sin(x)
x2 = linspace(0.1,pi-0.1,20)
y2 = cos(x2)
axs,h1,h2=plotyy(x,y,x2,y2)
axs is a list with [ax1,ax2]. As is evident from the code itself, there
isn't too much beyond what twinx already does, but this code aids matlab
compatibility and also the recursive handle property change is useful.
But this recursive code could be extricated to provide a general
setp_recursive function that would change a property on an object and
all its children (that have that property) if that is of interest.
Cheers,
David
On Fri, 2008年07月25日 at 15:00 -0400, Ryan May wrote:
> David Kaplan wrote:
> > The second patch is to pyplot.py to create a plotyy function. This is
> > like a matlab function of the same name that puts two curves with
> > different y ranges on the same x axis. It basically wraps the
> > two_scales.py demo functionality with a bit of extra stuff. I had to
> > use a real hack to change the colors of the y axes. Perhaps someone can
> > think of a better way or perhaps this sub-function should be moved out
> > of plotyy so it can be reused. Also, I couldn't find a way to color the
> > actual y-axis - i.e. the vertical line that is the y-axis. Is there an
> > easy way to do this?
> 
> Do you have an example of how to use this (or at least what the results 
> look like)? I'm having trouble seeing how this differs from twinx.
> 
> Ryan
> 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

Eric Bruning wrote:
> I raised this a week or so ago on mpl-users, and after some more
> digging I thought I'd bring it over to mpl-dev.
> 
> With the following snippet, I expect a vertical Line2D from y=(0, 2)
> and a Collection of squares at y=(4, 5, 6) at the specified time.
> 
> The actual result is a vertical line and no squares, even though the y
> axis limits adjust to (0,7) as if something is being plotted with the
> call to scatter.
> 
> from pylab import *
> from datetime import datetime
> f=figure()
> ax=f.add_subplot(111)
> d=datetime(2004,05,26,23,00,00)
> d=date2num(d)
> ax.xaxis_date()
> ln, = ax.plot((d,d,d),range(3)) # vertical line
> sc = ax.scatter((d,d,d),(4,5,6),marker='s') # no symbols plotted
> show()
> 
> However, with ax.xaxis_date() just before show(), I see the Collection.
> 
> What is the cause of this inconsistency? I was surprised by it, since
> I naively assumed that once the axis property was set, future
> additions to the axes would plot with the date axis in mind, as Line2D
> seems to. I poked around a bit with the _transform, _transforms, and
> _transOffset properties of the collections, but didn't get anywhere.
> 
> I'll be using date axes heavily in an interactive MPL project, where
> it would be nice to set the date axes once and forget about it. I'm
> willing to work on a fix if the problem is more than a lack
> understanding on my end.
> 
> Thanks,
> Eric
Eric,
I think most of us on the development side are a bit confused about the 
"units" support that handles dates among other things. In particular, a 
few days ago I was checking scatter and found that it did not work with 
dates (at least not in the simplest example). I fixed one thing that 
looked like it might have been causing the trouble, but it still didn't 
work. John has promised to provide some guidance, and so I hope we soon 
can make units work everywhere they should, and make it clear from the 
docstrings when they can or can't be used.
Eric

I raised this a week or so ago on mpl-users, and after some more
digging I thought I'd bring it over to mpl-dev.
With the following snippet, I expect a vertical Line2D from y=(0, 2)
and a Collection of squares at y=(4, 5, 6) at the specified time.
The actual result is a vertical line and no squares, even though the y
axis limits adjust to (0,7) as if something is being plotted with the
call to scatter.
from pylab import *
from datetime import datetime
f=figure()
ax=f.add_subplot(111)
d=datetime(2004,05,26,23,00,00)
d=date2num(d)
ax.xaxis_date()
ln, = ax.plot((d,d,d),range(3)) # vertical line
sc = ax.scatter((d,d,d),(4,5,6),marker='s') # no symbols plotted
show()
However, with ax.xaxis_date() just before show(), I see the Collection.
What is the cause of this inconsistency? I was surprised by it, since
I naively assumed that once the axis property was set, future
additions to the axes would plot with the date axis in mind, as Line2D
seems to. I poked around a bit with the _transform, _transforms, and
_transOffset properties of the collections, but didn't get anywhere.
I'll be using date axes heavily in an interactive MPL project, where
it would be nice to set the date axes once and forget about it. I'm
willing to work on a fix if the problem is more than a lack
understanding on my end.
Thanks,
Eric

On Mon, Jul 28, 2008 at 08:12:50AM -1000, Eric Firing wrote:
> Nils Wagner wrote:
> > On 2008年7月27日 07:19:24 -1000
> > Eric Firing <ef...@ha...> wrote:
> >> 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
> > 
> > Hi Eric,
> > 
> > Thank you very much ! The next problem is the following
> > 
> > Traceback (most recent call last):
> > File 
> > "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> > line 1094, in _onPaint
> > self.draw(drawDC=drawDC)
> > File 
> > "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> > line 64, in draw
> > self.gui_repaint(drawDC=drawDC)
> > File 
> > "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> > line 995, in gui_repaint
> > if self.IsShownOnScreen():
> > AttributeError: 'FigureCanvasWxAgg' object has no attribute 
> > 'IsShownOnScreen'
> > 
> > Nils
> > 
> 
> WxPython experts: what version do we require? If it is earlier than 
> 2.8, then it appears we badly need a testing procedure to ensure 
> compatibility. (A testing procedure for python version compatibility 
> would be nice, also--has anyone looked into what it would take to set up 
> and run a buildbot?)
Clearly I'm developing on 2.8, otherwise I wouldn't be introducing
so many issues for older versions. What version do people want
supported?
> I presume IsShownOnScreen is another 2.8-specific method, but a Google 
> search does not immediately turn up this information, and I don't 
> normally deal with wx, so I have to pass this problem on to someone who 
> does.
[41233]: IsVisible --> IsShownOnScreen
 http://trac.wxwidgets.org/changeset/41210
The date on this patch is 2006年09月14日, so almost two years old.
It seems like the old name is removed, so it is one or the other.
No indication on trac of which release number.
	- Paul

Nils Wagner wrote:
> On 2008年7月27日 07:19:24 -1000
> Eric Firing <ef...@ha...> wrote:
>> 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
> 
> Hi Eric,
> 
> Thank you very much ! The next problem is the following
> 
> Traceback (most recent call last):
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 1094, in _onPaint
> self.draw(drawDC=drawDC)
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
> line 64, in draw
> self.gui_repaint(drawDC=drawDC)
> File 
> "/usr/lib/python2.4/site-packages/matplotlib/backends/backend_wx.py", 
> line 995, in gui_repaint
> if self.IsShownOnScreen():
> AttributeError: 'FigureCanvasWxAgg' object has no attribute 
> 'IsShownOnScreen'
> 
> Nils
> 
WxPython experts: what version do we require? If it is earlier than 
2.8, then it appears we badly need a testing procedure to ensure 
compatibility. (A testing procedure for python version compatibility 
would be nice, also--has anyone looked into what it would take to set up 
and run a buildbot?)
I presume IsShownOnScreen is another 2.8-specific method, but a Google 
search does not immediately turn up this information, and I don't 
normally deal with wx, so I have to pass this problem on to someone who 
does.
Eric

On Mon, Jul 28, 2008 at 11:30 AM, Paul Kienzle <pki...@ni...> wrote:
> The issue is that my onHilite demo code sees the top frame, fills it,
can you use the alpha channel for your highlight so you can see through it?
The frame is slated to be rewritten to use lines rather than a
rectangle for better control. Tony has been working on this but got
stymied and I haven't had a chance to help get him unstuck yet...
> Please put a comment in the code saying why it is duplicated so
> that I don't stupidly remove it again the next time I work with
> onHilite.
comments added.
JDH

 --- the forwarded message follows ---

On Mon, Jul 28, 2008 at 10:40:47AM -0500, John Hunter wrote:
> On Mon, Jul 28, 2008 at 10:30 AM, Jae-Joon Lee <lee...@gm...> wrote:
> > Hi John,
> >
> > I'm a bit confused. When you say 1st instance, you mean
> >
> > if self.axison and self._frameon:
> > self.patch.draw(renderer)
> >
> > at line 1452?
> 
> Sorry, I was confused. I misread the first patch drawing as a frame
> drawing. I am adding the frame back in. Paul removed it in the
> commit
> 
> r5882 | pkienzle | 2008年07月25日 19:01:18 -0500 (2008年7月25日) | 1 line
> 
> Fix contains() for lines; don't redraw axis frame
> 
> Paul, were you also mistaking the patch for the frame? I looked at
> the Axes code and noticed the patch was drawing the edge, which is the
> job of the frame. I am turning the patch edgecolor off by default,
> which is what I think it should be doing, but Eric, can you confirm?
Sorry! I didn't look carefully enough at the problem.
The issue is that my onHilite demo code sees the top frame, fills it,
and blanks out the rest of the window, making it impossible for me
to check that it is doing the right thing. I was naively assuming
the rectangle that draws the frame also draws the background.
Please put a comment in the code saying why it is duplicated so
that I don't stupidly remove it again the next time I work with
onHilite.
	- Paul

On Mon, Jul 28, 2008 at 11:07 AM, Sandro Tosi <mat...@gm...> wrote:
> Now we got our bugs :) Mikhail, just give me a ping when you've done
> with sphinx, I'll try to rebuild mpl asap. John, are you coming nearer
> to a mpl full dot release, so that I can use it to build mpl for
> debian, or would you prefer to let me test the build process after
> sphinx update?
Yes, we are getting close. There are a few bugs on the tracker I would
like to clear
* html doc warnings -
https://sourceforge.net/tracker/index.php?func=detail&aid=2029956&group_id=80706&atid=560720
* symlog failing -
https://sourceforge.net/tracker/index.php?func=detail&aid=2029141&group_id=80706&atid=560720
* geo demo failing -
https://sourceforge.net/tracker/index.php?func=detail&aid=2029017&group_id=80706&atid=560720
* pdf memory leak -
https://sourceforge.net/tracker/index.php?func=detail&aid=2028431&group_id=80706&atid=560720
I will put out another release candidate as soon as the sphinx fixes
are in and we have had a chance to clear some of these. The last one
isn't a regression (it is present in 0.98.2) so it isn't a show
stopper, but it would be good to clear nonethless.
JDH

On Mon, Jul 28, 2008 at 06:51, Mikhail Gusarov <dot...@do...> wrote:
> Twas brillig at 12:51:35 27.07.2008 UTC-05 when jd...@gm... did gyre and gimble:
>
> >> It will help if you file a RC bug for sphinx :)
>
> JH> I'll be happy to, but should I wait until there is actually a
> JH> sphinx release out with the bugfix in it?
>
> No, just file a bug describing the problem with sphinx 0.4.1 and that it
> is fixed in svn.
Now we got our bugs :) Mikhail, just give me a ping when you've done
with sphinx, I'll try to rebuild mpl asap. John, are you coming nearer
to a mpl full dot release, so that I can use it to build mpl for
debian, or would you prefer to let me test the build process after
sphinx update?
TIA,
Sandro
-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Mon, Jul 28, 2008 at 10:30 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi John,
>
> I'm a bit confused. When you say 1st instance, you mean
>
> if self.axison and self._frameon:
> self.patch.draw(renderer)
>
> at line 1452?
Sorry, I was confused. I misread the first patch drawing as a frame
drawing. I am adding the frame back in. Paul removed it in the
commit
 r5882 | pkienzle | 2008年07月25日 19:01:18 -0500 (2008年7月25日) | 1 line
 Fix contains() for lines; don't redraw axis frame
Paul, were you also mistaking the patch for the frame? I looked at
the Axes code and noticed the patch was drawing the edge, which is the
job of the frame. I am turning the patch edgecolor off by default,
which is what I think it should be doing, but Eric, can you confirm?
JDH

Hi John,
I'm a bit confused. When you say 1st instance, you mean
 if self.axison and self._frameon:
 self.patch.draw(renderer)
at line 1452?
And you're saying that you tend to keep only the second instance,
instead of both?
(I'm sorry if I misunderstood you. I often have problems with my english)
I guess we need both. What I see is that self.patch is for axes
background (a "filled" patch), and self.frame is for axes border (a
patch with facecolor="none"). Aren't they?
(We may have self.patch.set_edgecolor("none") explicitly though).
Regards,
-JJ
On Mon, Jul 28, 2008 at 10:45 AM, John Hunter <jd...@gm...> wrote:
> On Mon, Jul 28, 2008 at 9:26 AM, Jae-Joon Lee <lee...@gm...> wrote:
>> Hello,
>>
>> I just noticed that,if I use imshow(), part of axes border is not
>> clearly visible (the image hides the border).
>> And this seems to be due to the following changes in axes.draw()
>> method made in r5882.
>>
>> --- lib/matplotlib/axes.py (revision 5881)
>> +++ lib/matplotlib/axes.py (revision 5882)
>> @@ -1503,8 +1503,6 @@
>> artists.extend(self.tables)
>> if self.legend_ is not None:
>> artists.append(self.legend_)
>> - if self.axison and self._frameon:
>> - artists.append(self.frame)
>>
>> dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)
>> if not a.get_animated() ]
>>
>>
>> Don't we need axes.frame to be drawn? Recovering those two lines
>> solved my problem.
>
> apparently the frame drawing code was in Axes.draw and Paul removed
> the 2nd instance of it. The first instance (which is the one that
> remains) draws the frame under the artists, and the 2nd instance (the
> one you want restored) draws the frame above the artists. I tend to
> agree that it is the 2nd one we want. Does anyone have a different
> opinion before I fix this?
>
> JDH
>
> Apparently someone moved the frame drawing code to be earlier so it
> would be under the artists.
>

On Mon, Jul 28, 2008 at 9:26 AM, Jae-Joon Lee <lee...@gm...> wrote:
> Hello,
>
> I just noticed that,if I use imshow(), part of axes border is not
> clearly visible (the image hides the border).
> And this seems to be due to the following changes in axes.draw()
> method made in r5882.
>
> --- lib/matplotlib/axes.py (revision 5881)
> +++ lib/matplotlib/axes.py (revision 5882)
> @@ -1503,8 +1503,6 @@
> artists.extend(self.tables)
> if self.legend_ is not None:
> artists.append(self.legend_)
> - if self.axison and self._frameon:
> - artists.append(self.frame)
>
> dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)
> if not a.get_animated() ]
>
>
> Don't we need axes.frame to be drawn? Recovering those two lines
> solved my problem.
apparently the frame drawing code was in Axes.draw and Paul removed
the 2nd instance of it. The first instance (which is the one that
remains) draws the frame under the artists, and the 2nd instance (the
one you want restored) draws the frame above the artists. I tend to
agree that it is the 2nd one we want. Does anyone have a different
opinion before I fix this?
JDH
Apparently someone moved the frame drawing code to be earlier so it
would be under the artists.

Hello,
I just noticed that,if I use imshow(), part of axes border is not
clearly visible (the image hides the border).
And this seems to be due to the following changes in axes.draw()
method made in r5882.
--- lib/matplotlib/axes.py (revision 5881)
+++ lib/matplotlib/axes.py (revision 5882)
@@ -1503,8 +1503,6 @@
 artists.extend(self.tables)
 if self.legend_ is not None:
 artists.append(self.legend_)
- if self.axison and self._frameon:
- artists.append(self.frame)
 dsu = [ (a.zorder, i, a) for i, a in enumerate(artists)
 if not a.get_animated() ]
Don't we need axes.frame to be drawn? Recovering those two lines
solved my problem.
Regards,
-JJ

On Mon, Jul 28, 2008 at 6:28 AM, David M. Kaplan <Dav...@ir...> wrote:
> Hi,
>
> Quick question: I have noticed that there are functions in cbook that
> have identical or near identical versions in numpy - unique, is_scalar
> (isscalar), iterable, .... Is this intentional?
At one point, Travis O went through mlab and ported a number of
functions he found useful into numpy. If the implementations are
identical, you can raise a Deprecation warning pointing to the numpy
version. If they are different, we need to look at them to make sure
the numpy version is doing what we want.
JDH

Hi,
Quick question: I have noticed that there are functions in cbook that
have identical or near identical versions in numpy - unique, is_scalar
(isscalar), iterable, .... Is this intentional?
Cheers,
David 
-- 
**********************************
David M. Kaplan
Charge de Recherche 1
Institut de Recherche pour le Developpement
Centre de Recherche Halieutique Mediterraneenne et Tropicale
av. Jean Monnet
B.P. 171
34203 Sete cedex
France
Phone: +33 (0)4 99 57 32 27
Fax: +33 (0)4 99 57 32 95
http://www.ur097.ird.fr/team/dkaplan/index.html
**********************************

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

I think that this is a nice addition to the hexbin function. At first, I didn't quite understand the documentation of the "C" functionality, but the new hexbin_demo2.py example makes everything clear.
In theory, if reduce_C_function is len, then this gives the usual hexbin result. It may be a good idea to add this to the docstring to help clarify how C,reduce_C_function works.
Thanks!
--Michiel.
--- On Sat, 7/26/08, John Hunter <jd...@gm...> wrote:
> From: John Hunter <jd...@gm...>
> Subject: Re: [matplotlib-devel] hexbin extension
> To: "Andrew Straw" <str...@as...>
> Cc: "matplotlib development list" <mat...@li...>, mjl...@ya...
> Date: Saturday, July 26, 2008, 5:18 PM
> On Sat, Jul 26, 2008 at 3:37 PM, Andrew Straw
> <str...@as...> 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.
> 
> Do you mean Michiel, the hexbin author? I m CC-ing him.
> 
> 
> > 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.
> 
> The functionality looks really nice. I don't really
> have a problem
> sneaking it in -- I'm a softie -- but we should hear
> from Michiel
> first. I am still waiting to hear from Sandro about his
> sphinx problem
> before trying to release anything anyhow.
> 
> JDH
 

Twas brillig at 12:51:35 27.07.2008 UTC-05 when jd...@gm... did gyre and gimble:
 >> It will help if you file a RC bug for sphinx :)
 JH> I'll be happy to, but should I wait until there is actually a
 JH> sphinx release out with the bugfix in it?
No, just file a bug describing the problem with sphinx 0.4.1 and that it
is fixed in svn.
--