matplotlib-devel Mailing List for matplotlib

On 5/31/07, Christopher Barker <Chr...@no...> wrote:
> John Hunter wrote:
> > If we have a pure python wxagg implementation that supports blitting,
> > eg your Just Work with 2.8 changes, let's not bother building the 2.6
> > extension code at all,
>
> I think this is the way to go. Even with 2.6, it's a pain to get MPL to
> find the right libs, etc, if there is more than one version of wx on the
> system (like OS-X). I actually wrote some code to version check and find
> the right one, but I don't see the point with the changes Ken has made
> for 2.8
>
OK, I just turned of BUILD_WXAGG by default and committed this in setup.py:
# build wxPython extension code to efficiently blit agg into wx. Only
# needed for wxpython <2.8 if you plan on doing animations
BUILD_WXAGG = 0
I made no changes to backend_wxagg.py because it looks like the
use_accelator code will do the right thing if _wxagg.so is not
present. I am not a wx user, so I leave it to the rest of you to
confirm and or vet these changes.
JDH

John Hunter wrote:
> If we have a pure python wxagg implementation that supports blitting,
> eg your Just Work with 2.8 changes, let's not bother building the 2.6
> extension code at all,
I think this is the way to go. Even with 2.6, it's a pain to get MPL to 
find the right libs, etc, if there is more than one version of wx on the 
system (like OS-X). I actually wrote some code to version check and find 
the right one, but I don't see the point with the changes Ken has made 
for 2.8
Pure Python is so much easier!
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 5/31/07, Ken McIvor <mc...@ii...> wrote:
> At this point it should be possible to include a _wxagg.so built for
> wxPython 2.6 and have everything Just Work with 2.8. If mixing
> versions causes linking errors it won't be hard to fix in
> backend_wxagg.py.
If we have a pure python wxagg implementation that supports blitting,
eg your Just Work with 2.8 changes, let's not bother building the 2.6
extension code at all, and if someone needs it they can
 1) use wx 2.8
 2) use an older mpl
 3) build the _wxagg extension themselves
 4) beg one of us to do it
Does this work?
JDH

On May 31, 2007, at 12:51 PM, Charlie Moad wrote:
>
> It would be nice to use the pure-python wx so we don't have to 
> provide separate 2.6 and 2.8 builds.
At this point it should be possible to include a _wxagg.so built for 
wxPython 2.6 and have everything Just Work with 2.8. If mixing 
versions causes linking errors it won't be hard to fix in 
backend_wxagg.py.
Ken

On May 31, 2007, at 12:42 PM, Christopher Barker wrote:
>
> I think all the real work is done, but I"m not totally sure what's
> checked in now. There may be some changes needed to the build 
> scripts so
> that it doesn't try to build the accelerator by default.
I'm not sure either. My modifications of setup.py, which disable the 
accelerator for wxPython >= 2.8, should already be in the trunk. I 
also modified backend_wxagg.py to ignore the accelerator when running 
with 2.8. I haven't heard any negative feedback about these changes, 
but I'm not sure anyone has rigorously tested them.
> I propose that we just stop building the accelerator, and if people 
> want
> better performance they need to switch to 2.8 (actually, I think the
> pre-2.8 code could be improved with pure python too, but I"m not going
> to bother, as I use 2.8 anyway)
I'm fine with that, given that the difficulties of getting the 
accelerator built under Debian and Ubuntu make it pretty useless to 
my current target audience. It should be as simple making 
BUILD_WXAGG default to False.
Ken

Hi. I've been trying to port an application to older distros such as RH3 without much luck.
I'm using numpy and pylab. I can usually get numpy installed but pylab has lots of dependencies on gtk2 and other things. What's the minimal backend to use to eliminate, as much as possible, the dependencies on distro stuff? Relatedly, is it possible to make a static build of pylab that can be included with my app? And finally, could somebody explain what buffer objects are and how they can be used to increase performance?
Thanks
John Hunter wrote:
> I am in favor of getting *all* the GUI dependent extension code out of
> MPL -- it is a support nightmare. Each of us should take the time to
> figure out how to get the best performance where possible using python
> buffer objects in the python layer for each of the main backends
> rather than rely on extension code. But I don't want to hold up the
> release cycle with known bugs in the wild unless someone says, "wait I
> just need a day or two".
-- 
Tom Holroyd, Ph.D.
"The fundamentally misconceived nature versus nurture debate should be
abandoned: child development is inextricably both." -- Louann Brizendine

I'm here. It would be nice to use the pure-python wx so we don't have
to provide separate 2.6 and 2.8 builds.
- Charlie
On 5/31/07, Christopher Barker <Chr...@no...> wrote:
> John Hunter wrote:
> > So if the wx stuff is ready to
> > go, by all means let's check it in and include it, but if not I don't
> > see that we need to hold for it.
>
> I think all the real work is done, but I"m not totally sure what's
> checked in now. There may be some changes needed to the build scripts so
> that it doesn't try to build the accelerator by default.
>
> > I am in favor of getting *all* the GUI dependent extension code out of
> > MPL -- it is a support nightmare.
>
> Actually, that's my proposal (and I think what Ken has done). The latest
> pure-python back-end uses wxPython2.8 methods to transfer the buffer. I
> propose that we just stop building the accelerator, and if people want
> better performance they need to switch to 2.8 (actually, I think the
> pre-2.8 code could be improved with pure python too, but I"m not going
> to bother, as I use 2.8 anyway)
>
> > But I don't want to hold up the
> > release cycle with known bugs in the wild unless someone says, "wait I
> > just need a day or two".
>
> I'll try to see if I can find a few hours to test and fix this stuff,
> but I've got some tight deadlines right now. If you don't hear from me
> or Ken, then I guess you might as well release away! (though just
> turning off the accelerator build may be all we need to do)
>
> -Chris
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John Hunter wrote:
> So if the wx stuff is ready to
> go, by all means let's check it in and include it, but if not I don't
> see that we need to hold for it.
I think all the real work is done, but I"m not totally sure what's 
checked in now. There may be some changes needed to the build scripts so 
that it doesn't try to build the accelerator by default.
> I am in favor of getting *all* the GUI dependent extension code out of
> MPL -- it is a support nightmare.
Actually, that's my proposal (and I think what Ken has done). The latest 
pure-python back-end uses wxPython2.8 methods to transfer the buffer. I 
propose that we just stop building the accelerator, and if people want 
better performance they need to switch to 2.8 (actually, I think the 
pre-2.8 code could be improved with pure python too, but I"m not going 
to bother, as I use 2.8 anyway)
> But I don't want to hold up the
> release cycle with known bugs in the wild unless someone says, "wait I
> just need a day or two".
I'll try to see if I can find a few hours to test and fix this stuff, 
but I've got some tight deadlines right now. If you don't hear from me 
or Ken, then I guess you might as well release away! (though just 
turning off the accelerator build may be all we need to do)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On 5/31/07, Christopher Barker <Chr...@no...> wrote:
> John Hunter wrote:
> > Many moons ago, we talked about doing a bugfix release 0.90.1. Since
> > there are known bugs in the production release (eg Jeff Peery's recent
> > plot_date bug) I would like to put out a new release. Any objections?
>
> I'd love to see a new release resolve the wxPython issues. Has this been
> done yet? See post a little while back for my suggestions.
>
> Ken, are you there? Is it ready to go? Your thoughts?
>
> When are thinking of getting it out -- I'm not sure when I'll have time
> to work on this (not in the next two days), but I'd really like to see
> this issue put to bed.
I've always been a big fan of release early, release often. I'd
rather get a point release out with all the improvements and bugfixes
since the last one than hold out for some additional piece. When that
piece is ready, we can release again. Yes, there is some labor
overhead -- Charlie are you out there :-) -- but I think more releases
rather than fewer are a good thing. So if the wx stuff is ready to
go, by all means let's check it in and include it, but if not I don't
see that we need to hold for it.
I am in favor of getting *all* the GUI dependent extension code out of
MPL -- it is a support nightmare. Each of us should take the time to
figure out how to get the best performance where possible using python
buffer objects in the python layer for each of the main backends
rather than rely on extension code. But I don't want to hold up the
release cycle with known bugs in the wild unless someone says, "wait I
just need a day or two".
JDH

John Hunter wrote:
> Many moons ago, we talked about doing a bugfix release 0.90.1. Since
> there are known bugs in the production release (eg Jeff Peery's recent
> plot_date bug) I would like to put out a new release. Any objections?
I'd love to see a new release resolve the wxPython issues. Has this been 
done yet? See post a little while back for my suggestions.
Ken, are you there? Is it ready to go? Your thoughts?
When are thinking of getting it out -- I'm not sure when I'll have time 
to work on this (not in the next two days), but I'd really like to see 
this issue put to bed.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Thursday 31 May 2007 10:27:30 am John Hunter wrote:
> Many moons ago, we talked about doing a bugfix release 0.90.1. Since
> there are known bugs in the production release (eg Jeff Peery's recent
> plot_date bug) I would like to put out a new release. Any objections?
>
> backend driver looks good.
>
> I've run some tests with memleak_hawaii with the agg backend and there
> appears to be a small leak, but I am not sure if there is a leak or if
> it is just converging slowly. At first I thought it was in pcolor,
> but when I tried increasing the size of the mesh the leak disappeared
> rather than grow, so that is why I am not sure if it is real. Plus I
> am running on solaris which is funky. What are you seeing? In my
> most recent test memory stabilized at 100 iterations and did not grow
> from 100->200.
Memory seems stable after 25 iterations on my machine (64bit Opterons, gentoo 
linux)

Many moons ago, we talked about doing a bugfix release 0.90.1. Since
there are known bugs in the production release (eg Jeff Peery's recent
plot_date bug) I would like to put out a new release. Any objections?
backend driver looks good.
I've run some tests with memleak_hawaii with the agg backend and there
appears to be a small leak, but I am not sure if there is a leak or if
it is just converging slowly. At first I thought it was in pcolor,
but when I tried increasing the size of the mesh the leak disappeared
rather than grow, so that is why I am not sure if it is real. Plus I
am running on solaris which is funky. What are you seeing? In my
most recent test memory stabilized at 100 iterations and did not grow
from 100->200.
JDH

hi,
i have come across the following problem:
matplotlib leaves open x server connections with various backends.
even after i del all relevant objects and del pylab. sometimes (the
gtkagg backend, i believe) even after i quit the python interpreter
(???).
i found this when trying to use matplotlib in a python session open
across a ssh -X connection . the ssh hangs upon disconnect, meaning
that x connections are still open.
i would like to use matplotlib interactively from a python app that
runs on a remote machine and be able to disconnect (using screen). the
issue mentioned above, however, ruins the reconnect, i get a "x server
connection broken" error when i try to use matplotlib after
reconnection. is there a way around this?
thanks,
ondrej marsalek

Jeff,
Your sensible change required one other, so I have committed both in rev 
3312.
Eric
Jeff Whitaker wrote:
> Eric: I came across what may be a small bug in colorbar. If you pass a 
> list to colorbar with the 'ticks' keyword, and the list is longer than 
> 10, you don't actually get the ticks at the locations you specify. This 
> patch seems to fix it:
> 
> --- colorbar.py 2007年04月09日 11:12:19.000000000 -0600
> +++ colorbar.py 2007年05月25日 12:20:20.000000000 -0600
> @@ -145,7 +145,7 @@
> self.solids = None
> self.lines = None
> if iterable(ticks):
> - self.locator = ticker.FixedLocator(ticks, nbins=10)
> + self.locator = ticker.FixedLocator(ticks, nbins=len(ticks))
> else:
> self.locator = ticks # Handle default in _ticker()
> if format is None:
> 
> 
> Notice that the Locator was being created with 10 bins, regardless of 
> how many ticks were being asked for.
> 
> If this looks OK I can commit.
> 
> -Jeff
> 

Eric: I came across what may be a small bug in colorbar. If you pass a 
list to colorbar with the 'ticks' keyword, and the list is longer than 
10, you don't actually get the ticks at the locations you specify. This 
patch seems to fix it:
--- colorbar.py 2007年04月09日 11:12:19.000000000 -0600
+++ colorbar.py 2007年05月25日 12:20:20.000000000 -0600
@@ -145,7 +145,7 @@
 self.solids = None
 self.lines = None
 if iterable(ticks):
- self.locator = ticker.FixedLocator(ticks, nbins=10)
+ self.locator = ticker.FixedLocator(ticks, nbins=len(ticks))
 else:
 self.locator = ticks # Handle default in _ticker()
 if format is None:
Notice that the Locator was being created with 10 bins, regardless of 
how many ticks were being asked for.
If this looks OK I can commit.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On 5/24/07, John Hunter <jd...@gm...> wrote:
> It turned out to be an easy fix. I was experimenting with even-odd
> and non-zero filling rules when I was working on polygon clipping and
> left a setting turned on that I did not mean to. Problem fixed in
> svn.
Great, thanks. Works perfectly now.
Cheers,
f

On 5/24/07, John Hunter <jd...@gm...> wrote:
> On 5/24/07, John Hunter <jd...@gm...> wrote:
>
> > > svn up src/_backend_agg.h -r3254
> > > svn up src/_backend_agg.cpp -r3254
>
> Oops, make that revision 3092
OK, just ignore me :-)
It turned out to be an easy fix. I was experimenting with even-odd
and non-zero filling rules when I was working on polygon clipping and
left a setting turned on that I did not mean to. Problem fixed in
svn.
JDH

On 5/24/07, John Hunter <jd...@gm...> wrote:
> > svn up src/_backend_agg.h -r3254
> > svn up src/_backend_agg.cpp -r3254
Oops, make that revision 3092

On 5/23/07, Fernando Perez <fpe...@gm...> wrote:
> Fortunately for me, the generated EPS don't have the problem (it's a
> pure Agg bug), so I'm OK for the final output. But it's really
> annoying on screen. My plots have tons of nearly retracing lines on
> them, and they look atrociously bad now.
Apparently I broke something when I added the support for general
polygon clipping to agg. Unfortunately, this code was pretty hairy so
it will take me a little time to fix. Those of you who are annoyed by
this should simply revert your local copy to
 > svn up src/_backend_agg.h -r3254
 > svn up src/_backend_agg.cpp -r3254
and hopefully I can find and fix the problem in the main line ASAP.
JDH

On 5/23/07, John Hunter <jd...@gm...> wrote:
> I seem to be getting some corner artifacts when using *Agg that I
> haven't seen before. Anyone else seeing something strange and any
> idea why?
Glad you wrote this, I was about to. I noticed them only recently,
and they're driving me nuts. They aren't just corners, they have to
do with the overlap of two lines and Agg messing something up when
thick lines overlap.
Here's an example that illustrates it more easily (that's how I ran into it):
import numpy as N
from pylab import figure, show
t = N.linspace(-1.0, 1.0, 2001)
s = N.exp(-300*N.abs(t))
fig = figure()
ax = fig.add_subplot(111)
ax.plot(t, s, '-', lw=2)
show()
###
Plot this, then click on the little zoom tool (the cross) and do a
horizontal right-mouse motion to widen/tighten the exponential.
You'll see the white artifact move across the region of overlap of the
vertical lines.
Fortunately for me, the generated EPS don't have the problem (it's a
pure Agg bug), so I'm OK for the final output. But it's really
annoying on screen. My plots have tons of nearly retracing lines on
them, and they look atrociously bad now.
Cheers,
f

On Wed, May 23, 2007 at 03:15:45PM -0500, John Hunter wrote:
> I seem to be getting some corner artifacts when using *Agg that I
> haven't seen before. Anyone else seeing something strange and any
> idea why?
I started seeing them with the QtAgg backend when I updated the svn
version I was using. That was about 2 weeks ago, and the previous
version was about 6 weeks old, at that point.
Glen

John Hunter wrote:
> I seem to be getting some corner artifacts when using *Agg that I
> haven't seen before. Anyone else seeing something strange and any
> idea why?
>
> import numpy
>
> from pylab import figure, show
>
> t = numpy.arange(0.0, 1.0, 0.1)
> s = numpy.ones(len(t), dtype=numpy.float_)
> s[1::2] = 0.
>
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot(t, s, '-', lw=2)
> ax.set_ylim(-.5, 1.5)
> show()
Confirmed with GTKAgg on OS X, latest svn (but not with 0.90). No idea 
why though.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Works for me, python 2.4, matplotlib 0.90.0, .matplotlibrc:
numerix: numpy
backend: GTKAgg
even with lw=20
John Hunter wrote:
> I seem to be getting some corner artifacts when using *Agg that I
> haven't seen before. Anyone else seeing something strange and any
> idea why?
> 
> import numpy
> 
> from pylab import figure, show
> 
> t = numpy.arange(0.0, 1.0, 0.1)
> s = numpy.ones(len(t), dtype=numpy.float_)
> s[1::2] = 0.
> 
> fig = figure()
> ax = fig.add_subplot(111)
> ax.plot(t, s, '-', lw=2)
> ax.set_ylim(-.5, 1.5)
> show()
>
-- 
Tom Holroyd, Ph.D.
"The fundamentally misconceived nature versus nurture debate should be
abandoned: child development is inextricably both." -- Louann Brizendine

I seem to be getting some corner artifacts when using *Agg that I
haven't seen before. Anyone else seeing something strange and any
idea why?
import numpy
from pylab import figure, show
t = numpy.arange(0.0, 1.0, 0.1)
s = numpy.ones(len(t), dtype=numpy.float_)
s[1::2] = 0.
fig = figure()
ax = fig.add_subplot(111)
ax.plot(t, s, '-', lw=2)
ax.set_ylim(-.5, 1.5)
show()

Timothy wrote:
> Please let me know if there is a 
> better way to submit the code.
> 
Hi Timothy,
If you make it into a complete example that plots something, send it as
an attachment to the list (so their are no line-break issues), I will
commit it into the examples directory. From there, we can figure out
where the key dendrogram() function should live, but at least your work
will get in the repository as soon as possible.
-Andrew