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.
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
···
On Mon, Oct 3, 2011 at 7:54 AM, John Hunter <jdh2358@…149…> 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
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](https://github.com/matplotlib/matplotlib/pull/505)
("Geo divide
zero") which I believe is ready to go.
[https://github.com/matplotlib/matplotlib/pull/496](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:
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
···
On 10/03/2011 01:01 PM, Benjamin Root wrote:
On Mon, Oct 3, 2011 at 7:54 AM, John > Hunter <jdh2358@...149...> > wrote:
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
···
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <mdroe@...31...> 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)?"
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
···
On Mon, Oct 3, 2011 at 12:06 PM, Michael Droettboom <mdroe@…31…> wrote:
On 10/03/2011 01:01 PM, Benjamin Root wrote:
On Mon, Oct 3, 2011 at 7:54 AM, John > > Hunter <jdh2358@...149...> > > 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?
On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben.root@...553...> 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?
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
···
On Mon, Oct 3, 2011 at 5:31 PM, Sandro Tosi <morph@…12…> wrote:
On Mon, Oct 3, 2011 at 23:00, Benjamin Root <ben.root@…553…> 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
On Tue, Oct 4, 2011 at 00:50, Benjamin Root <ben.root@...553...> 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).
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.
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?
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 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.
Matplotlib-devel mailing list
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.
Matplotlib-devel mailing list
-- Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
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,
···
On Tue, Oct 4, 2011 at 20:00, Michael Droettboom <mdroe@...31...> 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?
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
···
On 10/05/2011 03:38 AM, Sandro Tosi wrote:
On Tue, Oct 4, 2011 at 20:00, Michael Droettboom<mdroe@...31...> 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?
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.
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
···
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.
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 Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <efiring@...229...> 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.
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
···
On Wednesday, October 5, 2011, John Hunter <jdh2358@…149…> wrote:
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing <efiring@…229…> 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.
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
···
On 10/05/2011 11:17 AM, John Hunter wrote:
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> 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.
The backend_qt4.py problem--the line property editor is broken--remains.
Eric
···
On 10/05/2011 11:17 AM, John Hunter wrote:
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> 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
···
On 10/05/2011 05:17 PM, John Hunter wrote:
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> 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.
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<efiring@...229...> 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.
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!
···
On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <mdroe@...31...> wrote: