matplotlib-devel Mailing List for matplotlib

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

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

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

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

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

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

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