Menu
▾
▴
matplotlib-devel
|
From: John H. <jd...@gm...> - 2011-10-03 12:55:09
|
We made some additional progress over the weekend closing pull requests and issues, and I think we are ready to release tomorrow if no one objects. I want to hold off for a day to give people who do most of their work during the week a chance to close/finish/polish any lingering issues. The only open pull request that should be closed ahead of the release is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide zero") which I believe is ready to go. https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey Rappaport's CMRmap colour map") ooks harmless and if someone wants to merge it into v1.1.x rather than master (as the request states) I see no reason not to. On the issue list, nothing is tagged as release critical. Christoph had requested an upgrade of pytz ahead of the release, but I am reluctant to make a big change at the final hour unless there are some known, fairly serious bugs in the version we are shipping in which case we can consider it release critical and hold for upgrade and testing. Once we cut the release, we'll want to merge all the changes into master. I discussed this with Jouni over the weekend and we think that the only thing that doesn't need to be merged is the __version__ string so it will probably be pretty simple, but if we are missing something please speak up. JDH |
|
From: Benjamin R. <ben...@ou...> - 2011-10-03 17:02:10
|
On Mon, Oct 3, 2011 at 7:54 AM, John Hunter <jd...@gm...> wrote: > We made some additional progress over the weekend closing pull > requests and issues, and I think we are ready to release tomorrow if > no one objects. I want to hold off for a day to give people who do > most of their work during the week a chance to close/finish/polish any > lingering issues. > > The only open pull request that should be closed ahead of the release > is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide > zero") which I believe is ready to go. > https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey > Rappaport's CMRmap colour map") ooks harmless and if someone wants to > merge it into v1.1.x rather than master (as the request states) I see > no reason not to. On the issue list, nothing is tagged as release > critical. > > Christoph had requested an upgrade of pytz ahead of the release, but I > am reluctant to make a big change at the final hour unless there are > some known, fairly serious bugs in the version we are shipping in > which case we can consider it release critical and hold for upgrade > and testing. > > Once we cut the release, we'll want to merge all the changes into > master. I discussed this with Jouni over the weekend and we think > that the only thing that doesn't need to be merged is the __version__ > string so it will probably be pretty simple, but if we are missing > something please speak up. > > JDH > > I am fine with that, so long as we have confirmed that there are no critical issues with the Windows and Mac binaries. I also remember Sandro having difficulties with building the docs for Debian, but I haven't been able to replicate his problem. It sounds like he is having an exception being thrown and kicking him over to the pdb, but with the multiprocessing feature we added, it just hangs because the pdb can't connect to the terminal as a child process. Maybe it would be useful to have a switch to turn off multiprocessing for debugging purposes? Ben Root |
|
From: Michael D. <md...@st...> - 2011-10-03 17:06:35
|
On 10/03/2011 01:01 PM, Benjamin Root wrote: > On Mon, Oct 3, 2011 at 7:54 AM, John Hunter <jd...@gm... > <mailto:jd...@gm...>> wrote: > > We made some additional progress over the weekend closing pull > requests and issues, and I think we are ready to release tomorrow if > no one objects. I want to hold off for a day to give people who do > most of their work during the week a chance to close/finish/polish any > lingering issues. > > The only open pull request that should be closed ahead of the release > is https://github.com/matplotlib/matplotlib/pull/505 ("Geo divide > zero") which I believe is ready to go. > https://github.com/matplotlib/matplotlib/pull/496 ("Added Carey > Rappaport's CMRmap colour map") ooks harmless and if someone wants to > merge it into v1.1.x rather than master (as the request states) I see > no reason not to. On the issue list, nothing is tagged as release > critical. > > Christoph had requested an upgrade of pytz ahead of the release, but I > am reluctant to make a big change at the final hour unless there are > some known, fairly serious bugs in the version we are shipping in > which case we can consider it release critical and hold for upgrade > and testing. > > Once we cut the release, we'll want to merge all the changes into > master. I discussed this with Jouni over the weekend and we think > that the only thing that doesn't need to be merged is the __version__ > string so it will probably be pretty simple, but if we are missing > something please speak up. > > JDH > > > I am fine with that, so long as we have confirmed that there are no > critical issues with the Windows and Mac binaries. I'm just getting back from vacation, so excuse me if I'm late to the party. This sounds fine to me, but there was one pretty serious report about the Qt backend. I haven't had a chance to investigate this yet, but will do so soon. See the thread: "[matplotlib-devel] Typo in backend_qt4.py (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" > > I also remember Sandro having difficulties with building the docs for > Debian, but I haven't been able to replicate his problem. It sounds > like he is having an exception being thrown and kicking him over to > the pdb, but with the multiprocessing feature we added, it just hangs > because the pdb can't connect to the terminal as a child process. > Maybe it would be useful to have a switch to turn off multiprocessing > for debugging purposes? That's probably a good idea. Mike |
|
From: John H. <jd...@gm...> - 2011-10-03 17:18:49
|
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <md...@st...> wrote: > I'm just getting back from vacation, so excuse me if I'm late to the party. > This sounds fine to me, but there was one pretty serious report about the Qt > backend. I haven't had a chance to investigate this yet, but will do so > soon. See the thread: > > "[matplotlib-devel] Typo in backend_qt4.py > (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" Since you were away, you may have missed the introduction of the tag "release_critical". As you are working through the issues, if you add this tag to anything I'll hold off until they are cleared. JDH |
|
From: Benjamin R. <ben...@ou...> - 2011-10-03 21:01:21
|
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <md...@st...> wrote: > ** > On 10/03/2011 01:01 PM, Benjamin Root wrote: > > On Mon, Oct 3, 2011 at 7:54 AM, John Hunter <jd...@gm...> wrote: > > > I also remember Sandro having difficulties with building the docs for > Debian, but I haven't been able to replicate his problem. It sounds like he > is having an exception being thrown and kicking him over to the pdb, but > with the multiprocessing feature we added, it just hangs because the pdb > can't connect to the terminal as a child process. Maybe it would be useful > to have a switch to turn off multiprocessing for debugging purposes? > > > That's probably a good idea. > > Sandro, I tried this once, but I don't remember if it worked or not. In doc/make.py, there is a os.system call to sphinx-build. The "-P" option apparently forces sphinx to kick over to the pdb upon an exception. Try removing that option and rebuild the docs again. Maybe it won't hang anymore? Ben Root |
|
From: Sandro T. <mo...@de...> - 2011-10-03 22:31:52
|
On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben...@ou...> wrote: > I tried this once, but I don't remember if it worked or not. In > doc/make.py, there is a os.system call to sphinx-build. The "-P" option > apparently forces sphinx to kick over to the pdb upon an exception. Try > removing that option and rebuild the docs again. Maybe it won't hang > anymore? nope, sadly that doesn't help. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Benjamin R. <ben...@ou...> - 2011-10-03 22:51:22
|
On Mon, Oct 3, 2011 at 5:31 PM, Sandro Tosi <mo...@de...> wrote: > On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben...@ou...> wrote: > > I tried this once, but I don't remember if it worked or not. In > > doc/make.py, there is a os.system call to sphinx-build. The "-P" option > > apparently forces sphinx to kick over to the pdb upon an exception. Try > > removing that option and rebuild the docs again. Maybe it won't hang > > anymore? > > nope, sadly that doesn't help. > > Regards, > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > Ok, then on line 112 of doc/sphinxext/gen_gallery.py, get rid of "pool." and just do a regular map() call. This will force single processing mode and reveal which example is causing issues. Ben Root |
|
From: Sandro T. <mo...@de...> - 2011-10-04 06:36:05
Attachments:
log
|
Hi Ben, thanks for your support on this On Tue, Oct 4, 2011 at 00:50, Benjamin Root <ben...@ou...> wrote: > Ok, then on line 112 of doc/sphinxext/gen_gallery.py, get rid of "pool." and > just do a regular map() call. This will force single processing mode and > reveal which example is causing issues. Here attached the log (at the start of "writing output" I've Ctrl+c). HTH, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Michael D. <md...@st...> - 2011-10-04 14:47:08
|
I'm looking into this. It seems there's a pretty straightforward-to-fix bug parsing the commandline arguments. Beyond that, though, there appears to be a pretty serious (and relatively recent) memory leak in the plot directive that's preventing my own runs from finishing. I will let you know when I have some changes to try. Mike On 10/04/2011 02:35 AM, Sandro Tosi wrote: > Hi Ben, > thanks for your support on this > > On Tue, Oct 4, 2011 at 00:50, Benjamin Root<ben...@ou...> wrote: >> Ok, then on line 112 of doc/sphinxext/gen_gallery.py, get rid of "pool." and >> just do a regular map() call. This will force single processing mode and >> reveal which example is causing issues. > Here attached the log (at the start of "writing output" I've Ctrl+c). > > HTH, > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Michael D. <md...@st...> - 2011-10-04 17:57:08
|
It seems the memory leak was due to a problem in Numpy git master (I've yet to track down the root cause). Reverting to Numpy 1.6.1 resolves the issue, though. As for your bug, it seems there is a bug in how the plot_formats commandline argument is parsed. Could you please try this branch and let me know if it resolves the issue? https://github.com/mdboom/matplotlib/tree/doc_build_fail Mike On 10/04/2011 10:50 AM, Michael Droettboom wrote: > I'm looking into this. It seems there's a pretty > straightforward-to-fix bug parsing the commandline arguments. Beyond > that, though, there appears to be a pretty serious (and relatively > recent) memory leak in the plot directive that's preventing my own > runs from finishing. I will let you know when I have some changes to try. > > Mike > > On 10/04/2011 02:35 AM, Sandro Tosi wrote: >> Hi Ben, >> thanks for your support on this >> >> On Tue, Oct 4, 2011 at 00:50, Benjamin Root<ben...@ou...> wrote: >>> Ok, then on line 112 of doc/sphinxext/gen_gallery.py, get rid of "pool." and >>> just do a regular map() call. This will force single processing mode and >>> reveal which example is causing issues. >> Here attached the log (at the start of "writing output" I've Ctrl+c). >> >> HTH, >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> >> >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > -- > Michael Droettboom > Science Software Branch > Space Telescope Science Institute > Baltimore, Maryland, USA > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA |
|
From: Sandro T. <mo...@de...> - 2011-10-05 07:39:31
|
On Tue, Oct 4, 2011 at 20:00, Michael Droettboom <md...@st...> wrote: > As for your bug, it seems there is a bug in how the plot_formats commandline > argument is parsed. Could you please try this branch and let me know if it > resolves the issue? > > https://github.com/mdboom/matplotlib/tree/doc_build_fail Nope, sadly I can still replicate it. Anyhow, I don't know how you want to consider this blocking or not, I can live with the map() instead of pool.map() as Ben suggested. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Michael D. <md...@st...> - 2011-10-05 10:40:59
|
On 10/05/2011 03:38 AM, Sandro Tosi wrote: > On Tue, Oct 4, 2011 at 20:00, Michael Droettboom<md...@st...> wrote: >> As for your bug, it seems there is a bug in how the plot_formats commandline >> argument is parsed. Could you please try this branch and let me know if it >> resolves the issue? >> >> https://github.com/mdboom/matplotlib/tree/doc_build_fail > Nope, sadly I can still replicate it. Anyhow, I don't know how you > want to consider this blocking or not, I can live with the map() > instead of pool.map() as Ben suggested. I think we should probably take the multiprocessing out -- it's only purpose is to increase the speed of the build, but if it fails in some circumstances, it's not worth saving a few seconds. I'd still like to address this properly in the future, so I'll file a bug. Mike |
|
From: Eric F. <ef...@ha...> - 2011-10-05 18:49:51
|
On 10/03/2011 02:54 AM, John Hunter wrote: > We made some additional progress over the weekend closing pull > requests and issues, and I think we are ready to release tomorrow if > no one objects. I want to hold off for a day to give people who do > most of their work during the week a chance to close/finish/polish any > lingering issues. John, Sorry to be holding things up after having nagged about getting a release out, but I just now marked #506 "release_critical". It looks like a pretty fundamental bug in blitting on qt4agg, and I think I introduced it back in January, right after 1.0.1. I can look more closely this evening; I am hoping it will be fairly simple and safe to fix. Eric |
|
From: John H. <jd...@gm...> - 2011-10-05 21:17:45
|
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <ef...@ha...> wrote: > Sorry to be holding things up after having nagged about getting a > release out, but I just now marked #506 "release_critical". It looks > like a pretty fundamental bug in blitting on qt4agg, and I think I > introduced it back in January, right after 1.0.1. I can look more > closely this evening; I am hoping it will be fairly simple and safe to fix. Is this the issue Michael identified in this thread above pointing to: "[matplotlib-devel] Typo in backend_qt4.py (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was holding on that issue until I heard from him. JDH |
|
From: Benjamin R. <ben...@ou...> - 2011-10-05 21:51:34
|
On Wednesday, October 5, 2011, John Hunter <jd...@gm...> wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <ef...@ha...> wrote: > >> Sorry to be holding things up after having nagged about getting a >> release out, but I just now marked #506 "release_critical". It looks >> like a pretty fundamental bug in blitting on qt4agg, and I think I >> introduced it back in January, right after 1.0.1. I can look more >> closely this evening; I am hoping it will be fairly simple and safe to fix. > > Is this the issue Michael identified in this thread above pointing to: > "[matplotlib-devel] Typo in backend_qt4.py > (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was > holding on that issue until I heard from him. > > JDH On a separate note, I want to make sure I cut the rc1 correctly. The notes said to bump the version number in __unit__.py, but it was already at v1.1.0. Was I suppose to bump the version number *from* 1.1.0 in the master branch, or *to* v1.1.0 in the v1.1.x branch? Right now, it is 1.1.0 in both branches. Thanks, Ben Root |
|
From: Michael D. <md...@st...> - 2011-10-06 13:33:28
|
On 10/05/2011 05:17 PM, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote: > >> Sorry to be holding things up after having nagged about getting a >> release out, but I just now marked #506 "release_critical". It looks >> like a pretty fundamental bug in blitting on qt4agg, and I think I >> introduced it back in January, right after 1.0.1. I can look more >> closely this evening; I am hoping it will be fairly simple and safe to fix. > Is this the issue Michael identified in this thread above pointing to: > "[matplotlib-devel] Typo in backend_qt4.py > (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was > holding on that issue until I heard from him. I'm just getting to look at this now -- I'll report back once I have a sense of what the issues are. Mike |
|
From: Eric F. <ef...@ha...> - 2011-10-05 22:12:25
|
On 10/05/2011 11:17 AM, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote: > >> Sorry to be holding things up after having nagged about getting a >> release out, but I just now marked #506 "release_critical". It looks >> like a pretty fundamental bug in blitting on qt4agg, and I think I >> introduced it back in January, right after 1.0.1. I can look more >> closely this evening; I am hoping it will be fairly simple and safe to fix. > > Is this the issue Michael identified in this thread above pointing to: > "[matplotlib-devel] Typo in backend_qt4.py > (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was > holding on that issue until I heard from him. > > JDH John, No, I had forgotten about that one--from that message it looks like there are two problems in backend_qt4 that are separate from the backend_qt4agg problem noted in #506. I am only trying to deal with the latter. Eric |
|
From: Eric F. <ef...@ha...> - 2011-10-06 00:32:49
|
On 10/05/2011 11:17 AM, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote: > >> Sorry to be holding things up after having nagged about getting a >> release out, but I just now marked #506 "release_critical". It looks >> like a pretty fundamental bug in blitting on qt4agg, and I think I >> introduced it back in January, right after 1.0.1. I can look more >> closely this evening; I am hoping it will be fairly simple and safe to fix. > > Is this the issue Michael identified in this thread above pointing to: > "[matplotlib-devel] Typo in backend_qt4.py > (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was > holding on that issue until I heard from him. > > JDH #508 solves #506 The backend_qt4.py problem--the line property editor is broken--remains. Eric |
|
From: Michael D. <md...@st...> - 2011-10-06 14:18:01
|
On 10/06/2011 09:33 AM, Michael Droettboom wrote: > On 10/05/2011 05:17 PM, John Hunter wrote: >> On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote: >> >>> Sorry to be holding things up after having nagged about getting a >>> release out, but I just now marked #506 "release_critical". It looks >>> like a pretty fundamental bug in blitting on qt4agg, and I think I >>> introduced it back in January, right after 1.0.1. I can look more >>> closely this evening; I am hoping it will be fairly simple and safe to fix. >> Is this the issue Michael identified in this thread above pointing to: >> "[matplotlib-devel] Typo in backend_qt4.py >> (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was >> holding on that issue until I heard from him. > I'm just getting to look at this now -- I'll report back once I have a > sense of what the issues are. Pretty simple. I have a pull request here: https://github.com/matplotlib/matplotlib/pull/509 Mike |
|
From: John H. <jd...@gm...> - 2011-10-06 14:44:45
|
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <md...@st...> wrote: > Pretty simple. I have a pull request here: > > https://github.com/matplotlib/matplotlib/pull/509 I confirmed the qt bugs Eric and Michael were working on and tested the fixes, so i merged and closed these two. The only remaining issue I am aware of is Sandro's map issue, and he said earlier in this thread that he can use the map function rather than the pool, so I think we are good to go today. Speak now if I am missing something! |
|
From: John H. <jd...@gm...> - 2011-10-06 14:47:10
|
On Thu, Oct 6, 2011 at 9:44 AM, John Hunter <jd...@gm...> wrote: > On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <md...@st...> wrote: > >> Pretty simple. I have a pull request here: >> >> https://github.com/matplotlib/matplotlib/pull/509 > > I confirmed the qt bugs Eric and Michael were working on and tested > the fixes, so i merged and closed these two. The only remaining issue > I am aware of is Sandro's map issue, and he said earlier in this > thread that he can use the map function rather than the pool, so I > think we are good to go today. Speak now if I am missing something! OK, and now I see that Michael removed multi-processing entirely in #507 |
|
From: Michael D. <md...@st...> - 2011-10-06 14:48:53
|
On 10/06/2011 10:46 AM, John Hunter wrote: > On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote: >> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...> wrote: >> >>> Pretty simple. I have a pull request here: >>> >>> https://github.com/matplotlib/matplotlib/pull/509 >> I confirmed the qt bugs Eric and Michael were working on and tested >> the fixes, so i merged and closed these two. The only remaining issue >> I am aware of is Sandro's map issue, and he said earlier in this >> thread that he can use the map function rather than the pool, so I >> think we are good to go today. Speak now if I am missing something! > OK, and now I see that Michael removed multi-processing entirely in #507 Yeah -- it only really saves around 30seconds anyway. I thought it best to have it work reliably -- we can investigate the cause of Sandro's failure (which I'm not able to reproduce) later -- no need for it to hold up the release. Mike |
|
From: John H. <jd...@gm...> - 2011-10-06 14:58:18
|
On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom <md...@st...> wrote: > On 10/06/2011 10:46 AM, John Hunter wrote: >> >> On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote: >>> >>> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...> >>> wrote: >>> >>>> Pretty simple. I have a pull request here: >>>> >>>> https://github.com/matplotlib/matplotlib/pull/509 >>> >>> I confirmed the qt bugs Eric and Michael were working on and tested >>> the fixes, so i merged and closed these two. The only remaining issue >>> I am aware of is Sandro's map issue, and he said earlier in this >>> thread that he can use the map function rather than the pool, so I >>> think we are good to go today. Speak now if I am missing something! >> >> OK, and now I see that Michael removed multi-processing entirely in #507 > > Yeah -- it only really saves around 30seconds anyway. I thought it best to > have it work reliably -- we can investigate the cause of Sandro's failure > (which I'm not able to reproduce) later -- no need for it to hold up the > release. Great -- they tarballs for the mpl src and sample_data are at https://github.com/matplotlib/matplotlib/archives/master if Sandro would like to start with the debian packaging. Russell and Christoph, if you could point me to some binary builds I'll upload these to the sf site along with the tarballs and do the ANN. Thanks all, JDH |
|
From: John H. <jd...@gm...> - 2011-10-06 15:18:45
|
On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> wrote: > Great -- they tarballs for the mpl src and sample_data are at > > https://github.com/matplotlib/matplotlib/archives/master > > if Sandro would like to start with the debian packaging. Russell and > Christoph, if you could point me to some binary builds I'll upload > these to the sf site along with the tarballs and do the ANN. Actually, if you can just upload the binaries directly to https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/ that will save a step. Christoph, if you send me you sf ID I'll make sure you have upload permissions. Russell, you should already be good to go. JDH |
|
From: Russell O. <ro...@uw...> - 2011-10-07 21:08:37
|
Mac binaries for Python 2.6 and 32-bit Python 2.7 are now uploaded. -- Russell On Oct 6, 2011, at 8:18 AM, John Hunter wrote: > On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> wrote: > ... > Actually, if you can just upload the binaries directly to > > https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/ > > that will save a step... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X