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