matplotlib-devel Mailing List for matplotlib (Page 4)

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

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

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 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

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

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

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

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

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

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

On Sun, Oct 2, 2011 at 10:27 AM, John Hunter <jd...@gm...> wrote:
> I am trying to make an animation of the double pendulum using the
> attached script (v1.1.x branch). It creates all the files _tmp*.png,
> and creates the mpg but it has zero file size. If I manually make the
> movie with the resultant PNGs, it works fine
>
> mencoder mf://_tmp*.png -mf type=png:fps=15 -ovc lavc -lavcopts
> vcodec=mpeg4 -oac copy -o test2.mpg
Looks like the filename kwarg wants the "mp4" extension not the "mpg"
extension. I am updating the animation docs in my docstring pull
request.

I am trying to make an animation of the double pendulum using the
attached script (v1.1.x branch). It creates all the files _tmp*.png,
and creates the mpg but it has zero file size. If I manually make the
movie with the resultant PNGs, it works fine
mencoder mf://_tmp*.png -mf type=png:fps=15 -ovc lavc -lavcopts
vcodec=mpeg4 -oac copy -o test2.mpg
I need to add some debugging output to animation.py (we should add
lots of verbose.report command in there to see what is going on, I'm
going to try and get a pull request together) but I thought I'd fire
this off to anyone else has the same problems or if I'm doing it
wrong. I do have ffmpeg and mencoder installed on my 64bit ubuntu
11.04 box.
Thanks,
JDH