matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Russell E. O. <ro...@uw...>]

In article <EF3...@uw...>,
 Russell Owen <ro...@uw...> wrote:

> I just uploaded the Mac binaries.
> 
> Several minor concerns:
> - Many unit tests failed on Mac OS X 10.4 (which is where I build the 10.3.9 
> version) due to "too many files open", but the same binary looks fine on 
> 10.5.
> - The 64-bit version (10.6 and later) had one unexpected failure on 10.7 (I 
> have not yet had time to test it on 10.6)...

When I tested on Mac OS X 10.6 I found that most unit tests were somehow 
missing. Rather than try to diagnose the problem, I built a new binary 
on 10.6, confirmed that it installed properly (with all unit tests) on 
10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary.

The same test I mentioned in my previous post still fails using the new 
binary, on both 10.6 and 10.7.

-- Russell

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Russell O. <ro...@uw...>]

I just uploaded the Mac binaries.

Several minor concerns:
- Many unit tests failed on Mac OS X 10.4 (which is where I build the 10.3.9 version) due to "too many files open", but the same binary looks fine on 10.5.
- The 64-bit version (10.6 and later) had one unexpected failure on 10.7 (I have not yet had time to test it on 10.6)

localhost$ python -c "import matplotlib as m ; m.test(verbosity=1)"
..K..............KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK..KK.KK.KK.KK.KK.KK.KKK...KK...KK.KK..KKKK..KK.KK.KK.KK.KK.KK..KK.KK.KK.............................................................................F..........................................................................................................KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK.KK...KK.KK.KK.KK.KK.KK.KK.KK..............................................................KK.KK
======================================================================
FAIL: matplotlib.tests.test_mathtext.mathfont_stix_14_test.test
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 36, in failer
    result = f(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 140, in do_test
    '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: /Users/rowen/result_images/test_mathtext/mathfont_stix_14.png vs. /Users/rowen/result_images/test_mathtext/expected-mathfont_stix_14.png (RMS 3377.889)

----------------------------------------------------------------------
Ran 1068 tests in 161.293s

-- Russell

On Jun 9, 2012, at 2:14 PM, John Hunter wrote:

> I just uploaded the v1.1.1rc2 tarballs to the sourceforge site
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
> 
> As soon as we get binaries, I'll send out another call for testing on
> the users list.  Russell and Christoph, easiest if you just upload the
> binaries directly.  You should both have permissions on the sf site.
> 
> A copy of the site docs are available at
> http://matplotlib.sourceforge.net/rc/v1.1.1rc2/

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Christoph G. <cg...@uc...>]

On 6/30/2012 1:24 PM, Christoph Gohlke wrote:
> On 6/30/2012 12:55 PM, John Hunter wrote:
>>
>>
>> On Sat, Jun 30, 2012 at 2:40 PM, Fernando Perez <fpe...@gm...
>> <mailto:fpe...@gm...>> wrote:
>>
>>      On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...
>>      <mailto:jd...@gm...>> wrote:
>>      > Well, looks like we better get moving then ;-)
>>
>>      Go MPL!  It would be great to have matching releases of IPython and
>>      MPL, just in time for the Debian freeze and SciPy 2012 :)
>>
>>
>> OK, the v1.1.1 tarball is up at
>> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
>> and this is now the download folder the main site points to.  I'm
>> leaving up the rc2 binaries til Russell and Christoph can build v1.1.1
>> binaries and we get them uploaded.  Sandro, if you're around, you are
>> good to go for including this in debian, hopefully squeaking in under
>> the freeze (sorry for the last minute push).
>>
>> I will hold off on the users and announce list emails til the updated
>> binaries are up.
>>
>> Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
>>
>> Thanks to all!
>> JDH
>
> Here are the Windows installers, built against numpy 1.6.2. Sorry, I can
> not upload them to SF. There seems to be some permission problems that
> the SF admins would need to fix manually.
>
> <http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>
>
> Christoph
>

Sourceforge has fixed the permissions. I uploaded the Windows installers.

Christoph

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Ryan M. <rm...@gm...>]

On Tue, Jul 3, 2012 at 10:03 AM, Tony Yu <ts...@gm...> wrote:
>
>
> On Tue, Jul 3, 2012 at 10:22 AM, Ryan May <rm...@gm...> wrote:
>>
>> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu <ts...@gm...> wrote:
>> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:
>> >> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu <ts...@gm...> wrote:
>> >>>
>> >>> I'm having a tough time figuring this out: Saving an animation seems
>> >>> to
>> >>> hang when using `streamplot`. The exact same animation runs without
>> >>> issue
>> >>> when calling show.
>> >>>
>> >>> On my system, the example below hangs consistently at frame 173.
>> >>> However,
>> >>> the number of saved frames (before hanging) varies with density of
>> >>> stream
>> >>> lines (i.e. number of line segments in streamplot): More frames saved
>> >>> for
>> >>> lower density.
>> >>>
>> >>> Seems to be a memory or file-size issue, but
>> >>>
>> >>>    * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
>> >>> frames to disk as opposed to memory.)
>> >>>    * Saving the animation up to the frame just before it hangs gives
>> >>> modest (~1MB) videos.
>> >>> Maybe this is a limitation of `ffmpeg`?
>> >>>
>> >>> Can someone confirm that the example hangs on their system? (Somehow,
>> >>> I
>> >>> often run into bugs that are not reproducible.)
>> >>>
>> >>> In case this is system dependent:
>> >>> * OSX 10.6
>> >>> * Python 2.6.1 (system install)
>> >>> * matplotlib master
>> >>> * ffmpeg 0.10
>> >>>
>> >>> Simple plots seem to work fine, but I should probably try to reproduce
>> >>> using something other than streamplot (maybe create the equivalent
>> >>> number of
>> >>> line and arrow collections).
>> >>>
>> >>> -Tony
>> >>>
>> >>> #~~~ Example
>> >>> import numpy as np
>> >>> import matplotlib.pyplot as plt
>> >>> import matplotlib.animation as animation
>> >>>
>> >>> fig, ax = plt.subplots()
>> >>>
>> >>> # do nothing function that prints frame
>> >>> def update(frame_num):
>> >>>     print frame_num
>> >>>     return []
>> >>>
>> >>> Y, X = np.mgrid[:1:100j, :1:100j]
>> >>> U = np.ones_like(X)
>> >>> V = np.ones_like(X)
>> >>> ax.streamplot(X, Y, U, V, density=1)
>> >>>
>> >>> ani = animation.FuncAnimation(fig, update, save_count=500)
>> >>>
>> >>> # save hangs at frame 173 (this probably varies by system, if it's
>> >>> reproducible).
>> >>> ani.save('animation.avi')
>> >>> # show animates all frames w/o issue.
>> >>> #plt.show()
>> >>>
>> >>>
>> >>
>> >> I finally had some time to revisit this issue. It seems that subprocess
>> >> PIPEs have fairly limited buffers [1] (also see docs for
>> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
>> >> decent
>> >> amount of output to stderr. A simple solution is to redirect stderr to
>> >> a
>> >> temporary file. This change fixes the issue on my system.
>> >>
>> >> If this bug is reproducible, I can submit a PR. The temporary file here
>> >> could be created using tempfile so it gets cleaned up automatically, or
>> >> maybe a more permanent log file for debugging. Thoughts?
>> >>
>> >> -Tony
>> >>
>> >> [1]
>> >>
>> >> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
>> >>
>> >> [2]
>> >>
>> >> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
>> >>
>> >
>> > And just to clarify: My original email mentioned that saving would hang
>> > only
>> > when `streamplot` was used to create the figure. It turns out that
>> > ffmpeg
>> > prints more output (keyframes?) for more complex images, so when I ran
>> > simpler plots, they didn't produce enough output to fill the subprocess
>> > `PIPE` (although they would eventually).
>> >
>> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
>> > set
>> > `-loglevel quiet` in the ffmpeg command.
>> >
>> > -Tony
>>
>> It's not a bad idea to have it logged to a file in a temp directory.
>> We could potentially just do this if debug is set to verbose, however,
>> and just use -loglevel quiet otherwise. Can you manage PR for this or
>> do I need to?
>>
>> Ryan
>>
>
> Hey Ryan,
>
> If you have time, that'd be great. Otherwise, I should have some time at the
> end of the week to submit a PR.
>
> -Tony
>

I might be able to squeeze it in. If you don't see anything by the end
of the week, hit me up.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu <ts...@gm...>]

On Tue, Jul 3, 2012 at 10:22 AM, Ryan May <rm...@gm...> wrote:

> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu <ts...@gm...> wrote:
> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:
> >> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu <ts...@gm...> wrote:
> >>>
> >>> I'm having a tough time figuring this out: Saving an animation seems to
> >>> hang when using `streamplot`. The exact same animation runs without
> issue
> >>> when calling show.
> >>>
> >>> On my system, the example below hangs consistently at frame 173.
> However,
> >>> the number of saved frames (before hanging) varies with density of
> stream
> >>> lines (i.e. number of line segments in streamplot): More frames saved
> for
> >>> lower density.
> >>>
> >>> Seems to be a memory or file-size issue, but
> >>>
> >>>    * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
> >>> frames to disk as opposed to memory.)
> >>>    * Saving the animation up to the frame just before it hangs gives
> >>> modest (~1MB) videos.
> >>> Maybe this is a limitation of `ffmpeg`?
> >>>
> >>> Can someone confirm that the example hangs on their system? (Somehow, I
> >>> often run into bugs that are not reproducible.)
> >>>
> >>> In case this is system dependent:
> >>> * OSX 10.6
> >>> * Python 2.6.1 (system install)
> >>> * matplotlib master
> >>> * ffmpeg 0.10
> >>>
> >>> Simple plots seem to work fine, but I should probably try to reproduce
> >>> using something other than streamplot (maybe create the equivalent
> number of
> >>> line and arrow collections).
> >>>
> >>> -Tony
> >>>
> >>> #~~~ Example
> >>> import numpy as np
> >>> import matplotlib.pyplot as plt
> >>> import matplotlib.animation as animation
> >>>
> >>> fig, ax = plt.subplots()
> >>>
> >>> # do nothing function that prints frame
> >>> def update(frame_num):
> >>>     print frame_num
> >>>     return []
> >>>
> >>> Y, X = np.mgrid[:1:100j, :1:100j]
> >>> U = np.ones_like(X)
> >>> V = np.ones_like(X)
> >>> ax.streamplot(X, Y, U, V, density=1)
> >>>
> >>> ani = animation.FuncAnimation(fig, update, save_count=500)
> >>>
> >>> # save hangs at frame 173 (this probably varies by system, if it's
> >>> reproducible).
> >>> ani.save('animation.avi')
> >>> # show animates all frames w/o issue.
> >>> #plt.show()
> >>>
> >>>
> >>
> >> I finally had some time to revisit this issue. It seems that subprocess
> >> PIPEs have fairly limited buffers [1] (also see docs for
> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
> decent
> >> amount of output to stderr. A simple solution is to redirect stderr to a
> >> temporary file. This change fixes the issue on my system.
> >>
> >> If this bug is reproducible, I can submit a PR. The temporary file here
> >> could be created using tempfile so it gets cleaned up automatically, or
> >> maybe a more permanent log file for debugging. Thoughts?
> >>
> >> -Tony
> >>
> >> [1]
> >>
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
> >>
> >> [2]
> >>
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
> >>
> >
> > And just to clarify: My original email mentioned that saving would hang
> only
> > when `streamplot` was used to create the figure. It turns out that ffmpeg
> > prints more output (keyframes?) for more complex images, so when I ran
> > simpler plots, they didn't produce enough output to fill the subprocess
> > `PIPE` (although they would eventually).
> >
> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
> set
> > `-loglevel quiet` in the ffmpeg command.
> >
> > -Tony
>
> It's not a bad idea to have it logged to a file in a temp directory.
> We could potentially just do this if debug is set to verbose, however,
> and just use -loglevel quiet otherwise. Can you manage PR for this or
> do I need to?
>
> Ryan
>
>
Hey Ryan,

If you have time, that'd be great. Otherwise, I should have some time at
the end of the week to submit a PR.

-Tony

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Ryan M. <rm...@gm...>]

On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu <ts...@gm...> wrote:
> On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:
>> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu <ts...@gm...> wrote:
>>>
>>> I'm having a tough time figuring this out: Saving an animation seems to
>>> hang when using `streamplot`. The exact same animation runs without issue
>>> when calling show.
>>>
>>> On my system, the example below hangs consistently at frame 173. However,
>>> the number of saved frames (before hanging) varies with density of stream
>>> lines (i.e. number of line segments in streamplot): More frames saved for
>>> lower density.
>>>
>>> Seems to be a memory or file-size issue, but
>>>
>>>    * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
>>> frames to disk as opposed to memory.)
>>>    * Saving the animation up to the frame just before it hangs gives
>>> modest (~1MB) videos.
>>> Maybe this is a limitation of `ffmpeg`?
>>>
>>> Can someone confirm that the example hangs on their system? (Somehow, I
>>> often run into bugs that are not reproducible.)
>>>
>>> In case this is system dependent:
>>> * OSX 10.6
>>> * Python 2.6.1 (system install)
>>> * matplotlib master
>>> * ffmpeg 0.10
>>>
>>> Simple plots seem to work fine, but I should probably try to reproduce
>>> using something other than streamplot (maybe create the equivalent number of
>>> line and arrow collections).
>>>
>>> -Tony
>>>
>>> #~~~ Example
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> import matplotlib.animation as animation
>>>
>>> fig, ax = plt.subplots()
>>>
>>> # do nothing function that prints frame
>>> def update(frame_num):
>>>     print frame_num
>>>     return []
>>>
>>> Y, X = np.mgrid[:1:100j, :1:100j]
>>> U = np.ones_like(X)
>>> V = np.ones_like(X)
>>> ax.streamplot(X, Y, U, V, density=1)
>>>
>>> ani = animation.FuncAnimation(fig, update, save_count=500)
>>>
>>> # save hangs at frame 173 (this probably varies by system, if it's
>>> reproducible).
>>> ani.save('animation.avi')
>>> # show animates all frames w/o issue.
>>> #plt.show()
>>>
>>>
>>
>> I finally had some time to revisit this issue. It seems that subprocess
>> PIPEs have fairly limited buffers [1] (also see docs for
>> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a decent
>> amount of output to stderr. A simple solution is to redirect stderr to a
>> temporary file. This change fixes the issue on my system.
>>
>> If this bug is reproducible, I can submit a PR. The temporary file here
>> could be created using tempfile so it gets cleaned up automatically, or
>> maybe a more permanent log file for debugging. Thoughts?
>>
>> -Tony
>>
>> [1]
>> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
>>
>> [2]
>> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
>>
>
> And just to clarify: My original email mentioned that saving would hang only
> when `streamplot` was used to create the figure. It turns out that ffmpeg
> prints more output (keyframes?) for more complex images, so when I ran
> simpler plots, they didn't produce enough output to fill the subprocess
> `PIPE` (although they would eventually).
>
> Also, theres's a simpler fix than piping ffmpeg output to a file: Just set
> `-loglevel quiet` in the ffmpeg command.
>
> -Tony

It's not a bad idea to have it logged to a file in a temp directory.
We could potentially just do this if debug is set to verbose, however,
and just use -loglevel quiet otherwise. Can you manage PR for this or
do I need to?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu <ts...@gm...>]

On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:

>
>
> On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu <ts...@gm...> wrote:
>
>> I'm having a tough time figuring this out: Saving an animation seems to
>> hang when using `streamplot`. The exact same animation runs without issue
>> when calling show.
>>
>> On my system, the example below hangs consistently at frame 173. However,
>> the number of saved frames (before hanging) varies with density of stream
>> lines (i.e. number of line segments in streamplot): More frames saved for
>> lower density.
>>
>> Seems to be a memory or file-size issue, but
>>
>>    * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
>> frames to disk as opposed to memory.)
>>    * Saving the animation up to the frame just before it hangs gives
>> modest (~1MB) videos.
>> Maybe this is a limitation of `ffmpeg`?
>>
>> Can someone confirm that the example hangs on their system? (Somehow, I
>> often run into bugs that are not reproducible.)
>>
>> In case this is system dependent:
>> * OSX 10.6
>> * Python 2.6.1 (system install)
>> * matplotlib master
>> * ffmpeg 0.10
>>
>> Simple plots seem to work fine, but I should probably try to reproduce
>> using something other than streamplot (maybe create the equivalent number
>> of line and arrow collections).
>>
>> -Tony
>>
>> #~~~ Example
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import matplotlib.animation as animation
>>
>> fig, ax = plt.subplots()
>>
>> # do nothing function that prints frame
>> def update(frame_num):
>>     print frame_num
>>     return []
>>
>> Y, X = np.mgrid[:1:100j, :1:100j]
>> U = np.ones_like(X)
>> V = np.ones_like(X)
>> ax.streamplot(X, Y, U, V, density=1)
>>
>> ani = animation.FuncAnimation(fig, update, save_count=500)
>>
>> # save hangs at frame 173 (this probably varies by system, if it's
>> reproducible).
>> ani.save('animation.avi')
>> # show animates all frames w/o issue.
>> #plt.show()
>>
>>
>>
> I finally had some time to revisit this issue. It seems that subprocess
> PIPEs have fairly limited buffers [1] (also see docs for
> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a decent
> amount of output to stderr. A simple solution is to redirect stderr to a
> temporary file. This change fixes the issue on my system.
>
> If this bug is reproducible, I can submit a PR. The temporary file here
> could be created using tempfile so it gets cleaned up automatically, or
> maybe a more permanent log file for debugging. Thoughts?
>
> -Tony
>
> [1]
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
>
> [2]
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
>
>
And just to clarify: My original email mentioned that saving would hang
only when `streamplot` was used to create the figure. It turns out that
ffmpeg prints more output (keyframes?) for more complex images, so when I
ran simpler plots, they didn't produce enough output to fill the subprocess
`PIPE` (although they would eventually).

Also, theres's a simpler fix than piping ffmpeg output to a file: Just
set `-loglevel quiet` in the ffmpeg command.

-Tony

Re: [matplotlib-devel] Strange bug when saving animations (with streamplot)

[Tony Yu <ts...@gm...>]

On Sun, Jun 24, 2012 at 10:02 AM, Tony Yu <ts...@gm...> wrote:

> I'm having a tough time figuring this out: Saving an animation seems to
> hang when using `streamplot`. The exact same animation runs without issue
> when calling show.
>
> On my system, the example below hangs consistently at frame 173. However,
> the number of saved frames (before hanging) varies with density of stream
> lines (i.e. number of line segments in streamplot): More frames saved for
> lower density.
>
> Seems to be a memory or file-size issue, but
>
>    * Memory use doesn't seem to grow. (this suggests that ffmpeg adds
> frames to disk as opposed to memory.)
>    * Saving the animation up to the frame just before it hangs gives
> modest (~1MB) videos.
> Maybe this is a limitation of `ffmpeg`?
>
> Can someone confirm that the example hangs on their system? (Somehow, I
> often run into bugs that are not reproducible.)
>
> In case this is system dependent:
> * OSX 10.6
> * Python 2.6.1 (system install)
> * matplotlib master
> * ffmpeg 0.10
>
> Simple plots seem to work fine, but I should probably try to reproduce
> using something other than streamplot (maybe create the equivalent number
> of line and arrow collections).
>
> -Tony
>
> #~~~ Example
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.animation as animation
>
> fig, ax = plt.subplots()
>
> # do nothing function that prints frame
> def update(frame_num):
>     print frame_num
>     return []
>
> Y, X = np.mgrid[:1:100j, :1:100j]
> U = np.ones_like(X)
> V = np.ones_like(X)
> ax.streamplot(X, Y, U, V, density=1)
>
> ani = animation.FuncAnimation(fig, update, save_count=500)
>
> # save hangs at frame 173 (this probably varies by system, if it's
> reproducible).
> ani.save('animation.avi')
> # show animates all frames w/o issue.
> #plt.show()
>
>
>
I finally had some time to revisit this issue. It seems that subprocess
PIPEs have fairly limited buffers [1] (also see docs for
`subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a decent
amount of output to stderr. A simple solution is to redirect stderr to a
temporary file. This change fixes the issue on my system.

If this bug is reproducible, I can submit a PR. The temporary file here
could be created using tempfile so it gets cleaned up automatically, or
maybe a more permanent log file for debugging. Thoughts?

-Tony

[1]
http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/

[2]
http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

On Sun, Jul 1, 2012 at 2:25 AM, John Hunter <jd...@gm...> wrote:
> It certainly was outside you control Sandro. You gave us ample warning and
> reminders. I misinterpreted the June 30th freeze date to mean we needed to
> get it in by that date, but maybe it meant before, or maybe at some earlier
> time today.

Timezones suck :) I need to balance the importance of the update with
the additional work the release team will need to carry to accept it
(so read another email from someone for a not-so-breaking-the-world
update, read the diff, understand it, comment it, reply - it seems few
steps, but multiply for all the possible minor updates to debian
packages and you'll see) so I think better leave time to deal with the
other problems they already have at hand without extra burden.

> In any care, I apologize for missing the deadline and for the trouble.

Oh don't! there's nothing to be sorry about, it's life and constraints
- we're still have a very stable mpl in wheezy, even if the version
has a RC in it :)

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Jun 30, 2012, at 6:27 PM, Derek Homeier <de...@as...> wrote:

>> 
>> And none of the rules match this situation. RC2 will be :)
> 
> What about the very last one?
> 
> "For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous, but you need to contact us on your own, and you need to contact us soon."
> 
> 

It certainly was outside you control Sandro. You gave us ample warning and reminders. I misinterpreted the June 30th freeze date to mean we needed to get it in by that date, but maybe it meant before, or maybe at some earlier time today. 

In any care, I apologize for missing the deadline and for the trouble. 

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Derek H. <de...@as...>]

On 01.07.2012, at 12:17AM, Sandro Tosi wrote:

>> 
>> Just out of curiosity, what is the mismatch?  (I believe you, I just
>> know very little about the debian process).
> 
> These are the rules: http://release.debian.org/wheezy/freeze_policy.html
> 
> And none of the rules match this situation. RC2 will be :)

What about the very last one?

"For packages which missed the freeze only for reasons outside of the control of the maintainers, we might be generous, but you need to contact us on your own, and you need to contact us soon."

Cheers,
					Derek

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

On Sun, Jul 1, 2012 at 12:08 AM, Fernando Perez <fpe...@gm...> wrote:
> On Sat, Jun 30, 2012 at 3:07 PM, Sandro Tosi <mo...@de...> wrote:
>> It's probably a nomenclature difference: it's a "freeze exception" so
>> asking to overrule the freeze in place and allow a package to enter
>> testing, but it must match basic rules, but in this case they are not
>> matched.
>
> Just out of curiosity, what is the mismatch?  (I believe you, I just
> know very little about the debian process).

These are the rules: http://release.debian.org/wheezy/freeze_policy.html

And none of the rules match this situation. RC2 will be :)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Fernando P. <fpe...@gm...>]

On Sat, Jun 30, 2012 at 3:07 PM, Sandro Tosi <mo...@de...> wrote:
> It's probably a nomenclature difference: it's a "freeze exception" so
> asking to overrule the freeze in place and allow a package to enter
> testing, but it must match basic rules, but in this case they are not
> matched.

Just out of curiosity, what is the mismatch?  (I believe you, I just
know very little about the debian process).

f

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

On Sun, Jul 1, 2012 at 12:04 AM, John Hunter <jd...@gm...> wrote:
> But I thought this is exactly when an *exception* is needed: when one
> doesn't match the rules.

It's probably a nomenclature difference: it's a "freeze exception" so
asking to overrule the freeze in place and allow a package to enter
testing, but it must match basic rules, but in this case they are not
matched.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Jun 30, 2012, at 4:35 PM, Sandro Tosi <mo...@de...> wrote
> 
> I've just reviewed the rules, and sadly realized the final mpl release
> doesn't match them, so it's not worth asking for the exception.

>> 

But I thought this is exactly when an *exception* is needed: when one doesn't match the rules. 

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

Hello,

On Sat, Jun 30, 2012 at 10:54 PM, John Hunter <jd...@gm...> wrote:
> Yeah, the diff Sandro is referring to for us is just between rc2 and final.  Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final.

I've just reviewed the rules, and sadly realized the final mpl release
doesn't match them, so it's not worth asking for the exception.

> If not,Sandro, is there any reason you can't just ship rc2 into debian?  It's essentially the same thing.

Oh sure, wheezy will release with RC2 - it's just my personal taste to
release with the last version :)

cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Fernando P. <fpe...@gm...>]

On Sat, Jun 30, 2012 at 1:54 PM, John Hunter <jd...@gm...> wrote:
> Yeah, the diff Sandro is referring to for us is just between rc2 and final.  Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final.

In our case unfortunately we didn't have time to cut an RC, so our
diff beta1-HEAD was way too big.  We just had to push through the
work.  Let's just say that my wife was not amused with my Friday night
being a non-stop IRC marathon with Min "because we really need to get
in before debian freeze tonight!!!" :)

f

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Jun 30, 2012, at 3:46 PM, Fernando Perez <fperez.net@
> 
> Wow, I guess it paid off for us to stay up until 2am last night to get
> IPython in... Our diff was enormous so we would have not been allowed
> in at al. Whew :)


Yeah, the diff Sandro is referring to for us is just between rc2 and final.  Hopefully he can argue that since r1.1.1-rc2 is already in, they can accept this minor diff to final. 

If not,Sandro, is there any reason you can't just ship rc2 into debian?  It's essentially the same thing. 

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Jun 30, 2012, at 3:42 PM, Sandro Tosi <mo...@de...> wrote:

> Hello John,
> thanks for your effort! but...
> 
> 
> ... we're already too late for the Debian freeze :( the diff is quite
> small, so I'll ask for a freeze exception.

Ouch. Sorry for the screwup. Good luck with the exception request: all that we added were minor bugfixes from the release candidate rc2 that you already uploaded.

 Keep us posted. 

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Fernando P. <fpe...@gm...>]

On Sat, Jun 30, 2012 at 1:42 PM, Sandro Tosi <mo...@de...> wrote:
> ... we're already too late for the Debian freeze :( the diff is quite
> small, so I'll ask for a freeze exception.

Wow, I guess it paid off for us to stay up until 2am last night to get
IPython in... Our diff was enormous so we would have not been allowed
in at al. Whew :)

I hope they'll grant the exception for mpl...

Cheers,

f

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Sandro T. <mo...@de...>]

Hello John,
thanks for your effort! but...

On Sat, Jun 30, 2012 at 9:55 PM, John Hunter <jd...@gm...> wrote:
> OK, the v1.1.1 tarball is up
> at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to.  I'm leaving up
> the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and we
> get them uploaded.  Sandro, if you're around, you are good to go for
> including this in debian, hopefully squeaking in under the freeze (sorry for
> the last minute push).

... we're already too late for the Debian freeze :( the diff is quite
small, so I'll ask for a freeze exception.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Christoph G. <cg...@uc...>]

On 6/30/2012 12:55 PM, John Hunter wrote:
>
>
> On Sat, Jun 30, 2012 at 2:40 PM, Fernando Perez <fpe...@gm...
> <mailto:fpe...@gm...>> wrote:
>
>     On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...
>     <mailto:jd...@gm...>> wrote:
>     > Well, looks like we better get moving then ;-)
>
>     Go MPL!  It would be great to have matching releases of IPython and
>     MPL, just in time for the Debian freeze and SciPy 2012 :)
>
>
> OK, the v1.1.1 tarball is up at
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to.  I'm
> leaving up the rc2 binaries til Russell and Christoph can build v1.1.1
> binaries and we get them uploaded.  Sandro, if you're around, you are
> good to go for including this in debian, hopefully squeaking in under
> the freeze (sorry for the last minute push).
>
> I will hold off on the users and announce list emails til the updated
> binaries are up.
>
> Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
>
> Thanks to all!
> JDH

Here are the Windows installers, built against numpy 1.6.2. Sorry, I can 
not upload them to SF. There seems to be some permission problems that 
the SF admins would need to fix manually.

<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>

Christoph

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Fernando P. <fpe...@gm...>]

On Sat, Jun 30, 2012 at 12:55 PM, John Hunter <jd...@gm...> wrote:
> OK, the v1.1.1 tarball is up
> at https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
> and this is now the download folder the main site points to.  I'm leaving up
> the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and we
> get them uploaded.  Sandro, if you're around, you are good to go for
> including this in debian, hopefully squeaking in under the freeze (sorry for
> the last minute push).
>
> I will hold off on the users and announce list emails til the updated
> binaries are up.
>
> Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f
>
> Thanks to all!

Awesome, congrats!

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[John H. <jd...@gm...>]

On Sat, Jun 30, 2012 at 2:40 PM, Fernando Perez <fpe...@gm...>wrote:

> On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...> wrote:
> > Well, looks like we better get moving then ;-)
>
> Go MPL!  It would be great to have matching releases of IPython and
> MPL, just in time for the Debian freeze and SciPy 2012 :)
>
>
OK, the v1.1.1 tarball is up at
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1
and this is now the download folder the main site points to.  I'm leaving
up the rc2 binaries til Russell and Christoph can build v1.1.1 binaries and
we get them uploaded.  Sandro, if you're around, you are good to go for
including this in debian, hopefully squeaking in under the freeze (sorry
for the last minute push).

I will hold off on the users and announce list emails til the updated
binaries are up.

Tagged: git tag v1.1.1 7e47149a7b05f8e5cf1cc899a7e4e7c90dd4244f

Thanks to all!
JDH

Re: [matplotlib-devel] v1.1.1rc2 tarballs are up

[Fernando P. <fpe...@gm...>]

On Sat, Jun 30, 2012 at 11:46 AM, John Hunter <jd...@gm...> wrote:
> Well, looks like we better get moving then ;-)

Go MPL!  It would be great to have matching releases of IPython and
MPL, just in time for the Debian freeze and SciPy 2012 :)

Cheers,

f