matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] Upstream Matplotlib Qt Designer Plugin

[todd r. <tod...@gm...>]

I've included this in openSUSE's matplotlib packages, it seems to work great.

-Todd

On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut
<pie...@gm...> wrote:
> Hi all,
>
> Is anyone interested in including the Matplotlib QtDesigner plugin
> which I wrote for Python(x,y)?
>
> The code is quite simple and hasn't evolved for a while now (3 years)
> but apparently it is still appreciated by users even outside
> Python(x,y).
>
> Here are the two files which are necessary to make this plugin work:
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py
>
> The directory struture also has its importance:
> http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins
>
> Cheers,
> Pierre
>
> ---------- Message transféré ----------
> De : todd rme <tod...@gm...>
> Date : 11 mars 2012 12:14
> Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin
> À : "python(x,y)" <pyt...@go...>
>
>
> I notice that python(x,y) has a matplotlib plugin for Qt Designer.  I
> think this would be very helpful for general users of matplotlib
> outside of python(x,y).  Is there any possibility of submitting this
> plugin upstream for inclusion with the official matplotlib release?
> That way people who aren't using python(x,y) (for instance Linux users
> who are using their official distribution python packages) could
> benefit from the plugin as well.  Thank you very much.
>
> -Todd
>
> --
> You received this message because you are subscribed to the Google
> Groups "python(x,y)" group.
> To post to this group, send email to pyt...@go....
> To unsubscribe from this group, send email to
> pyt...@go....
> For more options, visit this group at
> http://groups.google.com/group/pythonxy?hl=en.

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

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

On 3/22/2012 7:18 PM, John Hunter wrote:
>
>
> On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
>     I think we are pretty close to cleaning up issues and PRs related to
>     v1.1.x, so I'd like to cut the release candidate this Thursday.
>       Let's continue to hammer on closing open issues and pull requests,
>     and flag anything that needs to be addressed before the release as
>     "release_critical" in the issue tracker.  If there are show stoppers
>     I am not aware of, chime in.
>
>
> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to
> and are available for testing and building binaries
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>
> After the binaries are up, I'll send out a notice to the users list
> requesting wider testing, but intrepid developers can begin now.
>
> The reference github commit for rc1 is
> https://github.com/matplotlib/matplotlib/commit/c5593eea91d82559c6e30e999635b93a35a13bc9
>
> There was a heroic effort by Michael Droetboom and Thomas Robitaille in
> the last two days to get past the freetype version and platform specific
> rendering issues, mainly revolving around anti-aliasing, and we are
> pretty close to there, so going forward we can expect almost all of the
> tests to pass for almost all of the developers, and have a mechanism for
> adding freetype version dependent known fails.  This will make our tests
> much more useful.  Thomas in particular did a crazy amount of testing on
> every conceivable combination of freetype settings and versions which
> really pushed the success of this effort, and Michael stayed right there
> with him committing fixes faster than any human could test.
>
> https://github.com/matplotlib/matplotlib/pull/779
>
> This will be the last release supporting python 2.4 and in all
> likelihood the last of the 1.1.x line, so I'd like to make it rock
> solid.  Testing will be appreciated.  For those of you who prefer the
> github interface/workflow, I'm opening up an "open thread" issue
>
> https://github.com/matplotlib/matplotlib/issues/791
>
> Thanks to all who've contributed -- I'll work up detailed notes for the
> real release, hopefully next week.  Russell and Christoph, you should be
> able to access to file manager interface directly on sf to upload your
> binaries, but let me know if you have any troubles.
>
> JDH
>

Hi John,

Windows binaries, including the test files, are at 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>.

All my attempts to upload the files to SF failed (no error report).

I'll run tests later.

Christoph

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

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

On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jd...@gm...> wrote:

> I think we are pretty close to cleaning up issues and PRs related to
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> continue to hammer on closing open issues and pull requests, and flag
> anything that needs to be addressed before the release as
> "release_critical" in the issue tracker.  If there are show stoppers I am
> not aware of, chime in.
>
>
The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
are available for testing and building binaries


https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/

After the binaries are up, I'll send out a notice to the users list
requesting wider testing, but intrepid developers can begin now.

The reference github commit for rc1 is
https://github.com/matplotlib/matplotlib/commit/c5593eea91d82559c6e30e999635b93a35a13bc9

There was a heroic effort by Michael Droetboom and Thomas Robitaille in the
last two days to get past the freetype version and platform specific
rendering issues, mainly revolving around anti-aliasing, and we are pretty
close to there, so going forward we can expect almost all of the tests to
pass for almost all of the developers, and have a mechanism for adding
freetype version dependent known fails.  This will make our tests much more
useful.  Thomas in particular did a crazy amount of testing on every
conceivable combination of freetype settings and versions which really
pushed the success of this effort, and Michael stayed right there with him
committing fixes faster than any human could test.

https://github.com/matplotlib/matplotlib/pull/779

This will be the last release supporting python 2.4 and in all likelihood
the last of the 1.1.x line, so I'd like to make it rock solid.  Testing
will be appreciated.  For those of you who prefer the github
interface/workflow, I'm opening up an "open thread" issue

https://github.com/matplotlib/matplotlib/issues/791

Thanks to all who've contributed -- I'll work up detailed notes for the
real release, hopefully next week.  Russell and Christoph, you should be
able to access to file manager interface directly on sf to upload your
binaries, but let me know if you have any troubles.

JDH

[matplotlib-devel] [ANN] PyData workshop videos are up online, including panel with Guido

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

Hi all,

just to let you know that the videos from the PyData workshop we held
at Google a couple of weeks ago are now online (not all talks are up
yet, so watch the page over the next few days if a talk you wanted to
see isn't posted yet):

http://marakana.com/s/2012_pydata_workshop,1090/index.html

The panel discussion with Guido that we talked about on these lists is
in there; I hope to write up a short summary about it soon.

Many thanks to Simeon Franklin and the rest of the Marakana team for
doing all this work (for free)!

Cheers,

f

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

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

In article 
<CAGD8yY91gGfk4OUyhx0c2zUoCbNW6OjKrLrB=NRN...@ma...>,
 John Hunter <jd...@gm...> wrote:

> I think we are pretty close to cleaning up issues and PRs related to
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> continue to hammer on closing open issues and pull requests, and flag
> anything that needs to be addressed before the release as
> "release_critical" in the issue tracker.  If there are show stoppers I am
> not aware of, chime in.
> 
> Thanks,
> JDH
> 
> ---------------------------------------------------------------------
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> ---------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Let me know when the source is ready to be pulled (and a link to 
instructions would be helpful) and I'll cut the Mac binaries.

-- Russell

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

[Michael D. <md...@st...>]

I just put a pull request up that resolves these tests for me: #779.  If 
it's working for others, we should go ahead and merge that into v1.1.x 
before the release.

Mike

On 03/20/2012 09:49 AM, Michael Droettboom wrote:
> We seem to have a large number of failing tests due to the recent 
> fixes to the snapping behavior.  Mainly these just need to be triaged 
> and have the baseline images replaced.  I'm going to see how far I get 
> on this today.
>
> Mike
>
> On 03/19/2012 01:58 PM, John Hunter wrote:
>> I think we are pretty close to cleaning up issues and PRs related to 
>> v1.1.x, so I'd like to cut the release candidate this Thursday. 
>>  Let's continue to hammer on closing open issues and pull requests, 
>> and flag anything that needs to be addressed before the release as 
>> "release_critical" in the issue tracker.  If there are show stoppers 
>> I am not aware of, chime in.
>>
>> Thanks,
>> JDH
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] test images update

[Michael D. <md...@st...>]

Have a look at #779.  Can you let me know if this resolves the tests for 
you?

https://github.com/matplotlib/matplotlib/pull/779

Mike

On 03/20/2012 09:48 AM, Michael Droettboom wrote:
> I've mainly done this using a thumbnailing tool like gthumb on one 
> side of the screen and a console to copy files on the other.  Since 
> the diff images are already generated, it's generally not so bad.  I'm 
> going to try to get all tests passing before the release if possible.  
> Wish me luck.  :)
>
> There are some related bug reports to this in #743 and #744.
>
> Mike
>
> On 03/14/2012 05:38 PM, Benjamin Root wrote:
>> So, I just tried running the test suite on matplotlib and it came 
>> back with 70+ failures.  I personally don't have the time or the 
>> focus to go through them all, but I suspect most if not all are 
>> related to some "snapping" fixes as most of the diff images seem to 
>> be related to changes in the graph borders and slight changes in text 
>> placement.  Maybe it would be useful to come up with a tool that 
>> could process through the result_images directory and display the 
>> images and their diffs and help us replace the images we deem as 
>> acceptable (or bump thresholds if we don't want to replace the image).
>>
>> What do others think? Maybe someone already has such a script?
>>
>> Ben Root
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization&  Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

[Michael D. <md...@st...>]

We seem to have a large number of failing tests due to the recent fixes 
to the snapping behavior.  Mainly these just need to be triaged and have 
the baseline images replaced.  I'm going to see how far I get on this today.

Mike

On 03/19/2012 01:58 PM, John Hunter wrote:
> I think we are pretty close to cleaning up issues and PRs related to 
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's 
> continue to hammer on closing open issues and pull requests, and flag 
> anything that needs to be addressed before the release as 
> "release_critical" in the issue tracker.  If there are show stoppers I 
> am not aware of, chime in.
>
> Thanks,
> JDH
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] test images update

[Michael D. <md...@st...>]

I've mainly done this using a thumbnailing tool like gthumb on one side 
of the screen and a console to copy files on the other.  Since the diff 
images are already generated, it's generally not so bad.  I'm going to 
try to get all tests passing before the release if possible.  Wish me 
luck.  :)

There are some related bug reports to this in #743 and #744.

Mike

On 03/14/2012 05:38 PM, Benjamin Root wrote:
> So, I just tried running the test suite on matplotlib and it came back 
> with 70+ failures.  I personally don't have the time or the focus to 
> go through them all, but I suspect most if not all are related to some 
> "snapping" fixes as most of the diff images seem to be related to 
> changes in the graph borders and slight changes in text placement.  
> Maybe it would be useful to come up with a tool that could process 
> through the result_images directory and display the images and their 
> diffs and help us replace the images we deem as acceptable (or bump 
> thresholds if we don't want to replace the image).
>
> What do others think? Maybe someone already has such a script?
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Upstream Matplotlib Qt Designer Plugin

[Pierre R. <pie...@gm...>]

Hi all,

Is anyone interested in including the Matplotlib QtDesigner plugin
which I wrote for Python(x,y)?

The code is quite simple and hasn't evolved for a while now (3 years)
but apparently it is still appreciated by users even outside
Python(x,y).

Here are the two files which are necessary to make this plugin work:
http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py
http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py

The directory struture also has its importance:
http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins

Cheers,
Pierre

---------- Message transféré ----------
De : todd rme <tod...@gm...>
Date : 11 mars 2012 12:14
Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin
À : "python(x,y)" <pyt...@go...>


I notice that python(x,y) has a matplotlib plugin for Qt Designer.  I
think this would be very helpful for general users of matplotlib
outside of python(x,y).  Is there any possibility of submitting this
plugin upstream for inclusion with the official matplotlib release?
That way people who aren't using python(x,y) (for instance Linux users
who are using their official distribution python packages) could
benefit from the plugin as well.  Thank you very much.

-Todd

--
You received this message because you are subscribed to the Google
Groups "python(x,y)" group.
To post to this group, send email to pyt...@go....
To unsubscribe from this group, send email to
pyt...@go....
For more options, visit this group at
http://groups.google.com/group/pythonxy?hl=en.

[matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday

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

I think we are pretty close to cleaning up issues and PRs related to
v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
continue to hammer on closing open issues and pull requests, and flag
anything that needs to be addressed before the release as
"release_critical" in the issue tracker.  If there are show stoppers I am
not aware of, chime in.

Thanks,
JDH

Re: [matplotlib-devel] Is snapping still right?

[Michael D. <md...@st...>]

Assuming there's no bugs, this doesn't look like the kind of thing that 
the snapping algorithm would cause or address.  Snapping is only 
supposed to kick in when the lines are rectilinear (i.e. perfectly 
horizontal or vertical) which none of the lines in this plot appear to 
be.  This plot actually looks "correct" to me -- it would be nice if the 
axis at the bottom had less stair-stepping, which some sort of gamma 
correction or perhaps tweaking of line width might help, but we don't 
currently do anything like that.

Mike

On 03/17/2012 03:58 PM, Benjamin Root wrote:
>
>
> On Sat, Mar 17, 2012 at 2:49 PM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>     I know this has been addressed so many times, but as I was testing
>     out mplot3d in v1.1.x, I swear the axes lines were aliasing like
>     crazy at some viewing angles.  If it is just mplot3d, then
>     probably should not hold up the bugfixes release, but maybe we
>     should get some eyes on the test results before releasing???
>
>     Ben Root 
>
>
>
> I have attached an image of the aliasing here.  I am going to test to 
> see if the recent snapping changes caused this.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Is snapping still right?

[Benjamin R. <ben...@ou...>]

I know this has been addressed so many times, but as I was testing out
mplot3d in v1.1.x, I swear the axes lines were aliasing like crazy at some
viewing angles.  If it is just mplot3d, then probably should not hold up
the bugfixes release, but maybe we should get some eyes on the test results
before releasing???

Ben Root

[matplotlib-devel] Bug report: colorbar ticks doesn't display

[ROCHE B. <ben...@ce...>]

Hi,

Here is an example to report a small bug in colorbars: ticks outside the "boundaries" doesn't display. "Boundaries" doesn't matter, only "values" do (cf example). It appends only when values and boundaries are differents (usefull for what I'm doing).

import scipy
from matplotlib import pyplot

pyplot.imshow(scipy.lena())
cbar_boundaries = scipy.linspace(-1000,1000,100)
cbar_values = scipy.linspace(0,255,99)
cb = pyplot.colorbar(boundaries=cbar_boundaries, values=cbar_values)
cb.set_ticks([-500, 50, 500])
pyplot.show()

Cheers,
Benoît

[matplotlib-devel] Different alphas for patch edges and faces

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

Is it possible to set different alpha values for patch edges and faces?

I found an old thread on this
topic<http://old.nabble.com/patches-have-incorrect-alpha-values-td22667217.html>.
It seems like there was some general agreement about the design. Was there
any progress on the implementation?

Thanks,
-Tony

[matplotlib-devel] test images update

[Benjamin R. <ben...@ou...>]

So, I just tried running the test suite on matplotlib and it came back with
70+ failures.  I personally don't have the time or the focus to go through
them all, but I suspect most if not all are related to some "snapping"
fixes as most of the diff images seem to be related to changes in the graph
borders and slight changes in text placement.  Maybe it would be useful to
come up with a tool that could process through the result_images directory
and display the images and their diffs and help us replace the images we
deem as acceptable (or bump thresholds if we don't want to replace the
image).

What do others think? Maybe someone already has such a script?

Ben Root

Re: [matplotlib-devel] colorbar extensions

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

On Wed, Mar 14, 2012 at 2:44 PM, Andrew Dawson <aj...@gm...> wrote:

> I implemented a new feature for colorbars, allowing the user to control
> the length of the triangular extensions at either end. This is useful for
> making plots consistent with those produced with other graphics packages.
>
> The URL for the comparison is:
>
> http://github.com/ajdawson/matplotlib/compare/master...colorbar-extensions
>
> I think this is a useful feature, I hope it can be included. Let me know
> when/if I need to do anything else.
>
>
Typically, these changes are submitted as a github pull request.

http://matplotlib.sourceforge.net/devel/gitwash/development_workflow.html#asking-for-your-changes-to-be-merged-into-the-main-repo

JDH

[matplotlib-devel] colorbar extensions

[Andrew D. <aj...@gm...>]

I implemented a new feature for colorbars, allowing the user to control the
length of the triangular extensions at either end. This is useful for
making plots consistent with those produced with other graphics packages.

The URL for the comparison is:

http://github.com/ajdawson/matplotlib/compare/master...colorbar-extensions

I think this is a useful feature, I hope it can be included. Let me know
when/if I need to do anything else.

Cheers,
Andrew

Re: [matplotlib-devel] Bug report: _make_movie hanging waiting for ffmpeg

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

On Tue, Mar 13, 2012 at 10:43 PM, Stephane Gagnon
<ste...@gm...> wrote:
> while trying out animation.ArtistAnimation, my script would not
> terminate.  The .mp4 file was generated and later found out that the
> script would block at proc.wait() within _make_movie.  ffmpeg
> generates quite a bit of text and it seems that if stdout/stderr are
> not closed, wait() does not return (this is on Windows).  I have made
> some modifications to animation.py to get it to work, but can't tell
> how this will behave on other platforms.
>
>
> Proposed change in matplotlib/animation.py:
>
>     def _make_movie(self, fname, fps, codec, frame_prefix, cmd_gen=None):
>         # Uses subprocess to call the program for assembling frames into a
>         # movie file.  *cmd_gen* is a callable that generates the sequence
>         # of command line arguments from a few configuration options.
>         from subprocess import Popen, PIPE
>         if cmd_gen is None:
>             cmd_gen = self.ffmpeg_cmd
>         command = cmd_gen(fname, fps, codec, frame_prefix)
>         verbose.report('Animation._make_movie running command: %s'%'
> '.join(command))
>         proc = Popen(command, shell=False,
>             stdout=PIPE, stderr=PIPE)
> +      proc.stdout.close()
> +      proc.stderr.close()
>         proc.wait()

Thanks for the report. The code to write movie files has been
refactored substantially to improve a wide variety of problems. One
changes has been to use communicate() instead of wait(), both to get
stdout and stderr text, but also to fix a similar problem on linux.
Can you try replacing the close() and wait() calls with just a single
call to communicate() and see if that also fixes your problem?

Thanks,

Ryan

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

[matplotlib-devel] Bug report: _make_movie hanging waiting for ffmpeg

[Stephane G. <ste...@gm...>]

Hi,

while trying out animation.ArtistAnimation, my script would not
terminate.  The .mp4 file was generated and later found out that the
script would block at proc.wait() within _make_movie.  ffmpeg
generates quite a bit of text and it seems that if stdout/stderr are
not closed, wait() does not return (this is on Windows).  I have made
some modifications to animation.py to get it to work, but can't tell
how this will behave on other platforms.


Proposed change in matplotlib/animation.py:

    def _make_movie(self, fname, fps, codec, frame_prefix, cmd_gen=None):
        # Uses subprocess to call the program for assembling frames into a
        # movie file.  *cmd_gen* is a callable that generates the sequence
        # of command line arguments from a few configuration options.
        from subprocess import Popen, PIPE
        if cmd_gen is None:
            cmd_gen = self.ffmpeg_cmd
        command = cmd_gen(fname, fps, codec, frame_prefix)
        verbose.report('Animation._make_movie running command: %s'%'
'.join(command))
        proc = Popen(command, shell=False,
            stdout=PIPE, stderr=PIPE)
+      proc.stdout.close()
+      proc.stderr.close()
        proc.wait()

This was tested to work with the configuration below.

OS: Windows 7
Python Version: Python 2.7.2 |EPD 7.2-1 (32-bit)| (default, Sep 14
2011, 11:02:05) [MSC v.1500 32 bit (Intel)]
Matplotlib version: 1.1.0
ffmpeg version N-38622-g1eabd71

Best regards

Re: [matplotlib-devel] quiver warnings

[Eric F. <ef...@ha...>]

On 03/11/2012 12:27 PM, D. S. McNeil wrote:
> Hi!  Bumping this upstream from Sage, where we use quiver to draw
> slope fields.  The following code
>
> ###
> import matplotlib.pyplot as plt
> import numpy as np
>
> fig = plt.figure()
> r = np.arange(10)
> X,Y = np.meshgrid(r,r)
> U, V = np.cos(X), np.sin(Y)
> Q = plt.quiver( U, V, headlength=0, headaxislength=0)
> ###
>
> produces exactly what we want, but generates some warnings:
>
> /usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:622:
> RuntimeWarning: divide by zero encountered in divide
>    shrink = length/minsh
> /usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:623:
> RuntimeWarning: invalid value encountered in multiply
>    X0 = shrink * X0[np.newaxis,:]
> /usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:624:
> RuntimeWarning: invalid value encountered in multiply
>    Y0 = shrink * Y0[np.newaxis,:]
>
> We can get around this by using some tiny headlength (minsh =
> self.minshaft * self.headlength) but it seems more natural to avoid
> drawing one entirely.  Would there be any objections to a pull request
> which special-cased 0 to avoid this?

No objections at all; it sounds like a good idea.

Eric

>
>
> Doug
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] quiver warnings

[D. S. M. <ds...@gm...>]

Hi!  Bumping this upstream from Sage, where we use quiver to draw
slope fields.  The following code

###
import matplotlib.pyplot as plt
import numpy as np

fig = plt.figure()
r = np.arange(10)
X,Y = np.meshgrid(r,r)
U, V = np.cos(X), np.sin(Y)
Q = plt.quiver( U, V, headlength=0, headaxislength=0)
###

produces exactly what we want, but generates some warnings:

/usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:622:
RuntimeWarning: divide by zero encountered in divide
  shrink = length/minsh
/usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:623:
RuntimeWarning: invalid value encountered in multiply
  X0 = shrink * X0[np.newaxis,:]
/usr/local/lib/python2.7/dist-packages/matplotlib/quiver.py:624:
RuntimeWarning: invalid value encountered in multiply
  Y0 = shrink * Y0[np.newaxis,:]

We can get around this by using some tiny headlength (minsh =
self.minshaft * self.headlength) but it seems more natural to avoid
drawing one entirely.  Would there be any objections to a pull request
which special-cased 0 to avoid this?


Doug

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Eric F. <ef...@ha...>]

On 03/09/2012 11:42 AM, Tony Yu wrote:
>
>
> On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen <pe...@en...
> <mailto:pe...@en...>> wrote:
>
>     I was just analyzing why 145 colours were listed in
>     matplotlib.colors.cnames instead of the 140 that are apparently "HTML
>     standard" and, although there's a good reason for that, in the process I
>     discovered that an issue reported in 2007 in the mailing list is still
>     outstanding in 1.1.0:
>
>     http://www.mail-archive.com/mat...@li.../msg00669.html
>
>     Basically, although there is block of code there to "add british
>     equivs", the master list already has the British 'lightgrey' in it,
>     instead of 'lightgray'.  For consistency with all the other cases
>     ('darkgray', 'dimgray', etc) the patch in the message above should be
>     applied, with the result that both "lightgray" and "lightgrey" would be
>     legal, as all the other types of gray already are.
>
>     Is this something I should just ticket, or is a report here sufficient?
>
>     Thanks.
>     --
>     Peter Hansen, P.Eng.
>     Engenuity Corporation
>
>
> It's a trivial change, but I added a PR to fix this
> <https://github.com/matplotlib/matplotlib/pull/754>, just to make it as
> easy as possible for the devs.

Tony,

Thank you.  If you have time, would you make a new pull request, please, 
against v1.1.x instead of master?  This seems like a bug that might as 
well be fixed before the next maintenance release.  If it goes into 
v1.1.x then it will automatically be included in master as well, as soon 
as someone merges v1.1.x into master.

Eric

> -Tony
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

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

On Fri, Mar 9, 2012 at 3:54 PM, Peter Hansen <pe...@en...> wrote:

> I was just analyzing why 145 colours were listed in
> matplotlib.colors.cnames instead of the 140 that are apparently "HTML
> standard" and, although there's a good reason for that, in the process I
> discovered that an issue reported in 2007 in the mailing list is still
> outstanding in 1.1.0:
>
>
> http://www.mail-archive.com/mat...@li.../msg00669.html
>
> Basically, although there is block of code there to "add british
> equivs", the master list already has the British 'lightgrey' in it,
> instead of 'lightgray'.  For consistency with all the other cases
> ('darkgray', 'dimgray', etc) the patch in the message above should be
> applied, with the result that both "lightgray" and "lightgrey" would be
> legal, as all the other types of gray already are.
>
> Is this something I should just ticket, or is a report here sufficient?
>
> Thanks.
> --
> Peter Hansen, P.Eng.
> Engenuity Corporation


It's a trivial change, but I added a PR to fix
this<https://github.com/matplotlib/matplotlib/pull/754>,
just to make it as easy as possible for the devs.
-Tony

[matplotlib-devel] Minor bug with colo(u)rs outstanding since 2007

[Peter H. <pe...@en...>]

I was just analyzing why 145 colours were listed in 
matplotlib.colors.cnames instead of the 140 that are apparently "HTML 
standard" and, although there's a good reason for that, in the process I 
discovered that an issue reported in 2007 in the mailing list is still 
outstanding in 1.1.0:

http://www.mail-archive.com/mat...@li.../msg00669.html

Basically, although there is block of code there to "add british 
equivs", the master list already has the British 'lightgrey' in it, 
instead of 'lightgray'.  For consistency with all the other cases 
('darkgray', 'dimgray', etc) the patch in the message above should be 
applied, with the result that both "lightgray" and "lightgrey" would be 
legal, as all the other types of gray already are.

Is this something I should just ticket, or is a report here sufficient?

Thanks.
-- 
Peter Hansen, P.Eng.
Engenuity Corporation