It has been quite a while since 0.87.7, and I note that the ubuntu feisty upstream version freeze date is Feb. 8. Is it time for a new mpl release? If it were done within the next few days, would it get into feisty? I acknowledge that I can offer no help with the release process, and I don't know what it takes to get a release into ubuntu--presumably the debian maintainer has to get it into debian first--but I thought I would raise the question anyway. Eric
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
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)
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 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: > 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...
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 >
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 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
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, 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: > 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 Chr...@no...
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 <Chr...@no...> 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 > > 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 >
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
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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
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
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
On 6/1/07, Andrew Straw <str...@as...> 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. 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
I'm still learning how to reply-to with my new-fangled gmail. I'm forwarding this response on to the list.... ---------- Forwarded message ---------- From: John Hunter <jd...@gm...> Date: Feb 5, 2007 9:46 AM Subject: Re: [matplotlib-devel] release? To: Eric Firing <ef...@ha...> Cc: cw...@gm... On 2/5/07, Eric Firing <ef...@ha...> wrote: > It has been quite a while since 0.87.7, and I note that the ubuntu > feisty upstream version freeze date is Feb. 8. Is it time for a new mpl > release? If it were done within the next few days, would it get into > feisty? I acknowledge that I can offer no help with the release > process, and I don't know what it takes to get a release into > ubuntu--presumably the debian maintainer has to get it into debian > first--but I thought I would raise the question anyway. I'm severely ham-strung at the moment since my build box died and I haven't resurrected a new one yet. Charlie has been doing the win32 builds and may be able to do them for this release. That's the hard part. Other than that, the main thing that needs to be done is to get a fresh svn co and build, run backend_driver and memleak_hawaii and make sure everything looks OK. If you can do that Eric, and Charlie can do the win32 build, I'm all for it. I just googled ubuntu matplotlib and got a page pointing to the old debian 0.82 version. I know that is the main debian package people are using but is it also the most recent ubuntu version. If so, just getting them onto 0.87.7 would be a major advance. I thought ubuntu was better about keeping up with current releases. JDH
John Hunter wrote: > I'm still learning how to reply-to with my new-fangled gmail. I'm > forwarding this response on to the list.... > > ---------- Forwarded message ---------- > From: John Hunter <jd...@gm...> > Date: Feb 5, 2007 9:46 AM > Subject: Re: [matplotlib-devel] release? > To: Eric Firing <ef...@ha...> > Cc: cw...@gm... > > > On 2/5/07, Eric Firing <ef...@ha...> wrote: >> It has been quite a while since 0.87.7, and I note that the ubuntu >> feisty upstream version freeze date is Feb. 8. Is it time for a new mpl >> release? If it were done within the next few days, would it get into >> feisty? I acknowledge that I can offer no help with the release >> process, and I don't know what it takes to get a release into >> ubuntu--presumably the debian maintainer has to get it into debian >> first--but I thought I would raise the question anyway. > > I'm severely ham-strung at the moment since my build box died and I > haven't resurrected a new one yet. Charlie has been doing the win32 > builds and may be able to do them for this release. That's the hard > part. Other than that, the main thing that needs to be done is to get > a fresh svn co and build, run backend_driver and memleak_hawaii and > make sure everything looks OK. If you can do that Eric, and Charlie > can do the win32 build, I'm all for it. OK, I did the fresh co and build and the checking, and I don't see any problems. (There is a deprecation warning in unicode_demo.py--not a show-stopper.) > > I just googled ubuntu matplotlib and got a page pointing to the old > debian 0.82 version. I know that is the main debian package people > are using but is it also the most recent ubuntu version. If so, just > getting them onto 0.87.7 would be a major advance. I thought ubuntu > was better about keeping up with current releases. Edgy appears to be offering 0.87.5, which is not quite so bad. I have no idea what will happen in Feisty, however. Eric
Eric Firing wrote: > John Hunter wrote: >> I'm still learning how to reply-to with my new-fangled gmail. I'm >> forwarding this response on to the list.... >> >> ---------- Forwarded message ---------- >> From: John Hunter <jd...@gm...> >> Date: Feb 5, 2007 9:46 AM >> Subject: Re: [matplotlib-devel] release? >> To: Eric Firing <ef...@ha...> >> Cc: cw...@gm... >> >> >> On 2/5/07, Eric Firing <ef...@ha...> wrote: >>> It has been quite a while since 0.87.7, and I note that the ubuntu >>> feisty upstream version freeze date is Feb. 8. Is it time for a new mpl >>> release? If it were done within the next few days, would it get into >>> feisty? I acknowledge that I can offer no help with the release >>> process, and I don't know what it takes to get a release into >>> ubuntu--presumably the debian maintainer has to get it into debian >>> first--but I thought I would raise the question anyway. >> I'm severely ham-strung at the moment since my build box died and I >> haven't resurrected a new one yet. Charlie has been doing the win32 >> builds and may be able to do them for this release. That's the hard >> part. Other than that, the main thing that needs to be done is to get >> a fresh svn co and build, run backend_driver and memleak_hawaii and >> make sure everything looks OK. If you can do that Eric, and Charlie >> can do the win32 build, I'm all for it. > > OK, I did the fresh co and build and the checking, and I don't see any > problems. (There is a deprecation warning in unicode_demo.py--not a > show-stopper.) > >> I just googled ubuntu matplotlib and got a page pointing to the old >> debian 0.82 version. I know that is the main debian package people >> are using but is it also the most recent ubuntu version. If so, just >> getting them onto 0.87.7 would be a major advance. I thought ubuntu >> was better about keeping up with current releases. > > Edgy appears to be offering 0.87.5, which is not quite so bad. I have > no idea what will happen in Feisty, however. Yes, matplotlib version in edgy is 0.87.5, in feisty it is 0.87.7, see: http://packages.ubuntu.com/ Manuel -- --------------------------------------- Manuel Metz ............ Stw@AIfA Argelander Institut fuer Astronomie Auf dem Huegel 71 (room 3.06) D - 53121 Bonn E-Mail: mm...@as... Web: www.astro.uni-bonn.de/~mmetz Phone: (+49) 228 / 73-3660 Fax: (+49) 228 / 73-3672 ---------------------------------------
I'm listening, and I can do the windows builds. I'll run those tests tonight and get back to the list. - Charlie On 2/5/07, Eric Firing <ef...@ha...> wrote: > John Hunter wrote: > > I'm still learning how to reply-to with my new-fangled gmail. I'm > > forwarding this response on to the list.... > > > > ---------- Forwarded message ---------- > > From: John Hunter <jd...@gm...> > > Date: Feb 5, 2007 9:46 AM > > Subject: Re: [matplotlib-devel] release? > > To: Eric Firing <ef...@ha...> > > Cc: cw...@gm... > > > > > > On 2/5/07, Eric Firing <ef...@ha...> wrote: > >> It has been quite a while since 0.87.7, and I note that the ubuntu > >> feisty upstream version freeze date is Feb. 8. Is it time for a new mpl > >> release? If it were done within the next few days, would it get into > >> feisty? I acknowledge that I can offer no help with the release > >> process, and I don't know what it takes to get a release into > >> ubuntu--presumably the debian maintainer has to get it into debian > >> first--but I thought I would raise the question anyway. > > > > I'm severely ham-strung at the moment since my build box died and I > > haven't resurrected a new one yet. Charlie has been doing the win32 > > builds and may be able to do them for this release. That's the hard > > part. Other than that, the main thing that needs to be done is to get > > a fresh svn co and build, run backend_driver and memleak_hawaii and > > make sure everything looks OK. If you can do that Eric, and Charlie > > can do the win32 build, I'm all for it. > > OK, I did the fresh co and build and the checking, and I don't see any > problems. (There is a deprecation warning in unicode_demo.py--not a > show-stopper.) > > > > > I just googled ubuntu matplotlib and got a page pointing to the old > > debian 0.82 version. I know that is the main debian package people > > are using but is it also the most recent ubuntu version. If so, just > > getting them onto 0.87.7 would be a major advance. I thought ubuntu > > was better about keeping up with current releases. > > Edgy appears to be offering 0.87.5, which is not quite so bad. I have > no idea what will happen in Feisty, however. > > Eric > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
rev3002 works great for me. I can push the windows releases this Saturday. I could push a source release sooner. Is anyone opposed to me pushing a source release Friday with the binaries following up on Saturday? If there are no objections, let's avoid major commits until after then. - Charlie On 2/5/07, Charlie Moad <cw...@gm...> wrote: > I'm listening, and I can do the windows builds. I'll run those tests > tonight and get back to the list. > > - Charlie > > On 2/5/07, Eric Firing <ef...@ha...> wrote: > > John Hunter wrote: > > > I'm still learning how to reply-to with my new-fangled gmail. I'm > > > forwarding this response on to the list.... > > > > > > ---------- Forwarded message ---------- > > > From: John Hunter <jd...@gm...> > > > Date: Feb 5, 2007 9:46 AM > > > Subject: Re: [matplotlib-devel] release? > > > To: Eric Firing <ef...@ha...> > > > Cc: cw...@gm... > > > > > > > > > On 2/5/07, Eric Firing <ef...@ha...> wrote: > > >> It has been quite a while since 0.87.7, and I note that the ubuntu > > >> feisty upstream version freeze date is Feb. 8. Is it time for a new mpl > > >> release? If it were done within the next few days, would it get into > > >> feisty? I acknowledge that I can offer no help with the release > > >> process, and I don't know what it takes to get a release into > > >> ubuntu--presumably the debian maintainer has to get it into debian > > >> first--but I thought I would raise the question anyway. > > > > > > I'm severely ham-strung at the moment since my build box died and I > > > haven't resurrected a new one yet. Charlie has been doing the win32 > > > builds and may be able to do them for this release. That's the hard > > > part. Other than that, the main thing that needs to be done is to get > > > a fresh svn co and build, run backend_driver and memleak_hawaii and > > > make sure everything looks OK. If you can do that Eric, and Charlie > > > can do the win32 build, I'm all for it. > > > > OK, I did the fresh co and build and the checking, and I don't see any > > problems. (There is a deprecation warning in unicode_demo.py--not a > > show-stopper.) > > > > > > > > I just googled ubuntu matplotlib and got a page pointing to the old > > > debian 0.82 version. I know that is the main debian package people > > > are using but is it also the most recent ubuntu version. If so, just > > > getting them onto 0.87.7 would be a major advance. I thought ubuntu > > > was better about keeping up with current releases. > > > > Edgy appears to be offering 0.87.5, which is not quite so bad. I have > > no idea what will happen in Feisty, however. > > > > Eric > > > > ------------------------------------------------------------------------- > > Using Tomcat but need to do more? Need to support web services, security? > > Get stuff done quickly with pre-integrated technology to make your job easier. > > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Matplotlib-devel mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > >
On 2/6/07, Charlie Moad <cw...@gm...> wrote: > rev3002 works great for me. I can push the windows releases this > Saturday. I could push a source release sooner. Is anyone opposed to > me pushing a source release Friday with the binaries following up on > Saturday? If there are no objections, let's avoid major commits until > after then. Let's do the source release ASAP -- I'll update the website for win32 users to point to the older release so they can find it until the win32 binaries are out. That way if ubuntu wants to use this for their next release before the Feb 8th upstream freeze they can (and it will give us one day to do a point bugfix release if the whole world blows up). Just be sure that you use the same svn revision for the src release and the win32 builds which will help us with user errors. And email us when the new source is up so I'll know to make the website change. And let's call it 0.90 god-doggy. I'm getting tired of 0.87. There is at least one signficant API breaking new feature (the pick API) which alone justifies not making this a point release. There are also several new features sampled below 2007年01月22日 Extended the new picker API to text, patches and patch collections. Added support for user customizable pick hit testing and attribute tagging of the PickEvent - Details and examples in examples/pick_event_demo.py - 2007年01月11日 Added Axes.xcorr and Axes.acorr to plot the cross correlation of x vs y or the autocorrelation of x. pylab wrappers also provided. See examples/xcorr_demo.py 2007年01月10日 Added "Subplot.label_outer" method. It will set the visibility of the ticklabels so that yticklabels are only visible in the first column and xticklabels are only visible in the last row 2006年12月09日 Replaced spy and spy2 with the new spy that combines marker and image capabilities 2006年12月19日 Added Tim Leslie's spectral patch 2006年11月19日 Added semi-automatic docstring generation detailing all the kwargs that functions take using the artist introspection tools; eg 'help text now details the scatter kwargs that control the Text properties 2006年11月05日 Added broken_barh function for makring a sequence of horizontal bars broken by gaps -- see examples/broken_barh.py Thanks! JDH
Ok, I'll try to get it posted on SF tonight. On 2/6/07, John Hunter <jd...@gm...> wrote: > On 2/6/07, Charlie Moad <cw...@gm...> wrote: > > rev3002 works great for me. I can push the windows releases this > > Saturday. I could push a source release sooner. Is anyone opposed to > > me pushing a source release Friday with the binaries following up on > > Saturday? If there are no objections, let's avoid major commits until > > after then. > > Let's do the source release ASAP -- I'll update the website for win32 > users to point to the older release so they can find it until the > win32 binaries are out. That way if ubuntu wants to use this for > their next release before the Feb 8th upstream freeze they can (and it > will give us one day to do a point bugfix release if the whole world > blows up). Just be sure that you use the same svn revision for the > src release and the win32 builds which will help us with user errors. > And email us when the new source is up so I'll know to make the > website change. > > And let's call it 0.90 god-doggy. I'm getting tired of 0.87. There > is at least one signficant API breaking new feature (the pick API) > which alone justifies not making this a point release. There are also > several new features sampled below > > 2007年01月22日 Extended the new picker API to text, patches and patch > collections. Added support for user customizable pick hit > testing and attribute tagging of the PickEvent - Details > and examples in examples/pick_event_demo.py - > > 2007年01月11日 Added Axes.xcorr and Axes.acorr to plot the cross > correlation of x vs y or the autocorrelation of x. pylab > wrappers also provided. See examples/xcorr_demo.py > > 2007年01月10日 Added "Subplot.label_outer" method. It will set the > visibility of the ticklabels so that yticklabels are only > visible in the first column and xticklabels are only > visible in the last row > > 2006年12月09日 Replaced spy and spy2 with the new spy that combines > marker and image capabilities > > 2006年12月19日 Added Tim Leslie's spectral patch > > 2006年11月19日 Added semi-automatic docstring generation detailing all the > kwargs that functions take using the artist introspection > tools; eg 'help text now details the scatter kwargs > that control the Text properties > > 2006年11月05日 Added broken_barh function for makring a sequence of > horizontal bars broken by gaps -- see examples/broken_barh.py > > Thanks! > JDH >