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
Memory seems stable after 25 iterations on my machine (64bit Opterons, gentoo
linux)
···
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.
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
Chris.Barker@...236...
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
···
On 5/31/07, Christopher Barker <Chris.Barker@...236...> 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.
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
Chris.Barker@...236...
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 <Chris.Barker@...236...> 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
Chris.Barker@...236...
-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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
···
On May 31, 2007, at 12:42 PM, Christopher Barker 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.
Ken
···
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.
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 5/31/07, Ken McIvor <mcivor@...227...> 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.
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
Chris.Barker@...236...
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
···
On 5/31/07, Christopher Barker <Chris.Barker@...236...> 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
I've been running MPL 0.90 rev3250 since April 18 on numerous computers
around here using the wxAgg backend using stock wx on both Ubuntu Edgy
and Ubuntu Feisty. A quick look into exactly what that means shows that
Edgy is using 2.6 by default and 2.8 is used by Feisty. Therefore, I
conclude that, if your changes were present in that revision, everything
seems to be working OK for both 2.6 and 2.8.
Ken McIvor wrote:
···
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
-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
John Hunter wrote:
I am not a wx user, so I leave it to the rest of you to
confirm and or vet these changes.
I just built and tested SVN trunk on OS-X 10.4.9 with:
python 2.4 with wxPython2.6.3
and
python 2.5 with wxPython2.8.4
Not extensive testing, but it seems to work fine. Thanks!
NOTE: I first installed it over the older one in python2.4 with wxPython2.6, and got a garbage image. Then I deleted the old one, and re-installed, and it worked fine. I suspect that I had an old accelerator with the old one, which doesn't work right with the new one. It wasn't over-written, as the accelerator isn't being built by default anymore.
···
--
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
Chris.Barker@...236...
I have time to cut a release tomorrow. Are there any outstanding
issues that I should wait on?
- Charlie
···
On 6/1/07, Christopher Barker <Chris.Barker@...236...> wrote:
John Hunter wrote:
> I am not a wx user, so I leave it to the rest of you to
> confirm and or vet these changes.
I just built and tested SVN trunk on OS-X 10.4.9 with:
python 2.4 with wxPython2.6.3
and
python 2.5 with wxPython2.8.4
Not extensive testing, but it seems to work fine. Thanks!
NOTE: I first installed it over the older one in python2.4 with
wxPython2.6, and got a garbage image. Then I deleted the old one, and
re-installed, and it worked fine. I suspect that I had an old
accelerator with the old one, which doesn't work right with the new one.
It wasn't over-written, as the accelerator isn't being built by default
anymore.
--
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
Chris.Barker@...236...
-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Charlie Moad wrote:
I have time to cut a release tomorrow. Are there any outstanding
issues that I should wait on?
I just committed a change that raises a DeprecationWarning on use of
numarray or Numeric as the numerix backend -- we agreed on this back in
early April.
-Andrew
Excellent, thanks. I will update the website "news flash" saying the
same. Charlie, full speed ahead with 0.90.1 and 0.91 will be numpy
only.
Thanks!
JDH
···
On 6/1/07, Andrew Straw <strawman@...36...> wrote:
Charlie Moad wrote:
> I have time to cut a release tomorrow. Are there any outstanding
> issues that I should wait on?
>
I just committed a change that raises a DeprecationWarning on use of
numarray or Numeric as the numerix backend -- we agreed on this back in
early April.