matplotlib-devel Mailing List for matplotlib (Page 2)

On 06/18/2013 07:09 PM, Fernando Perez wrote:
> Hi Mike,
>
> On Tue, Jun 18, 2013 at 3:37 PM, Michael Droettboom <md...@st...> wrote:
>> This was an attempt to fix a bug that mpl's KnownFailure plugin wouldn't
>> load when running tests directly using the nosetests commandline
>> script. I see IPython has a testing wrapper script (iptest) -- is that
>> in part to solve that problem?
> Only in part. We wrote iptest because we need to start nose multiple
> times in different subprocesses for each chunk of IPython, as trying
> to load all of IPython into a single python process ends up producing
> tears (conflicts between things that don't like to live together in
> sys.modules like multiple gui toolkits, etc).
We are likely to have to do the same thing in the near future -- we 
already have to spawn subprocesses in the setup script because we can't, 
for example, import pygtk (classic) and pygi (the new hotness) in the 
same process.
>
>> In any case, the revert should be simple -- can you try commenting out
>> the "entry_points" kwarg at the bottom of the setup.py script? (You'll
>> probably need to blitz the matplotlib installation directory and `build`
>> for good measure). I can't actually reproduce the bug myself, but I
>> suspect that's because this is somewhat dependent on the order in which
>> things are installed into the virtualenv or the phases of the moon...
> Yup, problem gone. With this change:
>
> ((v1.3.0rc3))longs[matplotlib]> git diff
> diff --git a/setup.py b/setup.py
> index 5f1b561..b4d1763 100644
> --- a/setup.py
> +++ b/setup.py
> @@ -230,9 +230,9 @@ if __name__ == '__main__':
> zip_safe=False,
>
> # Install our nose plugin so it will always be found
> - entry_points={
> - 'nose.plugins.0.10': [
> - 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
> - ]
> - },
> + # entry_points={
> + # 'nose.plugins.0.10': [
> + # 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
> + # ]
> + # },
> )
>
> I get as expected:
>
> ((v1.3.0rc3))longs[matplotlib]> iptest -vx IPython.core.tests.test_run
>
> [...]
>
> ----------------------------------------------------------------------
> Ran 23 tests in 2.277s
>
> OK (KNOWNFAIL=1)
>
>> If that works for you, we can just take that out and require testers to
>> use our testing script (and unfortunately will have to make another
>> release candidate).
> Well, I wouldn't want to force mpl to have to ship a custom testing
> script, that's kind of an ugly kludge that we live with but that is
> really sub-optimal. I wish we could just fix this plugin issue. The
> problem, I suspect, is the presence of multiple KnownFailure classes
> in a way that trips an isisnstance() check somewhere.
Well, this wouldn't be anything new. The 1.2 series (and I think as far 
back as we've had nosetests) requires this already, I was just hoping 
this would be a solution to that.
I think I'm fine with just taking this out for 1.3.0 and, as Thomas 
Kluyver suggested, dealing with this properly once we drop support for 
Python 2.6.
Cheers,
Mike
>
> Cheers,
>
> f

On Tue, Jun 18, 2013 at 2:20 PM, Michael Droettboom <md...@st...> wrote:
> I have tagged a 1.3.0rc3 and uploaded a tarball to Sourceforge.
>
> We may not get all the binaries up in the next little while, so I'll wait
> for those and then make an announcement on matplotlib-users. After a
> couple of weeks, assuming no serious problems, we'll be ready for 1.3.0
> final.
>
Russell, I see you seem to have had no issues (except for some warnings)
building the earlier 1.3 release candidates. That said, let me know if I
can do anything to help.
>
> Thanks again to everyone for their help with this release!
>
> Mike
>
>
> On 06/17/2013 02:53 PM, Damon McDougall wrote:
>
>
>
>
> On Mon, Jun 17, 2013 at 9:50 AM, Michael Droettboom <md...@st...>wrote:
>
>> We're a little behind schedule for 1.3.0 -- held up by the
>> distribute/setuptools upgrade debacle. I'd like to put out a 1.3.0rc3
>> late tonight or tomorrow, and hopefully get a final release out early
>> next week in advance of Scipy if all goes well. Any objections?
>>
>
> I'm too far behind on my email to be apprised of the state of distribute
> vs setuptools. I trust your judgement :)
>
>
>>
>> Mike
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229
>
>
>
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On 19 June 2013 00:09, Fernando Perez <fpe...@gm...> wrote:
> I wish we could just fix this plugin issue.
When we drop support for Python 2.6, I think we can use the expectedFailure
mechanism included in unittest from 2.7 onwards. So long as nose recognises
that, we should be able to drop our copy of the KnownFailure plugin.
Thomas

Good point, I didn't know about that new mechanism.
I think we should keep 2.6 support for IPython 1.0, but drop it
afterwards. We can discuss that during the dev meeting...
Cheers,
f
On Tue, Jun 18, 2013 at 4:16 PM, Thomas Kluyver <th...@kl...> wrote:
> On 19 June 2013 00:09, Fernando Perez <fpe...@gm...> wrote:
>>
>> I wish we could just fix this plugin issue.
>
>
> When we drop support for Python 2.6, I think we can use the expectedFailure
> mechanism included in unittest from 2.7 onwards. So long as nose recognises
> that, we should be able to drop our copy of the KnownFailure plugin.
>
> Thomas
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

Hi Mike,
On Tue, Jun 18, 2013 at 3:37 PM, Michael Droettboom <md...@st...> wrote:
> This was an attempt to fix a bug that mpl's KnownFailure plugin wouldn't
> load when running tests directly using the nosetests commandline
> script. I see IPython has a testing wrapper script (iptest) -- is that
> in part to solve that problem?
Only in part. We wrote iptest because we need to start nose multiple
times in different subprocesses for each chunk of IPython, as trying
to load all of IPython into a single python process ends up producing
tears (conflicts between things that don't like to live together in
sys.modules like multiple gui toolkits, etc).
> In any case, the revert should be simple -- can you try commenting out
> the "entry_points" kwarg at the bottom of the setup.py script? (You'll
> probably need to blitz the matplotlib installation directory and `build`
> for good measure). I can't actually reproduce the bug myself, but I
> suspect that's because this is somewhat dependent on the order in which
> things are installed into the virtualenv or the phases of the moon...
Yup, problem gone. With this change:
((v1.3.0rc3))longs[matplotlib]> git diff
diff --git a/setup.py b/setup.py
index 5f1b561..b4d1763 100644
--- a/setup.py
+++ b/setup.py
@@ -230,9 +230,9 @@ if __name__ == '__main__':
 zip_safe=False,
 # Install our nose plugin so it will always be found
- entry_points={
- 'nose.plugins.0.10': [
- 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
- ]
- },
+ # entry_points={
+ # 'nose.plugins.0.10': [
+ # 'KnownFailure = matplotlib.testing.noseclasses:KnownFailure'
+ # ]
+ # },
 )
I get as expected:
((v1.3.0rc3))longs[matplotlib]> iptest -vx IPython.core.tests.test_run
[...]
----------------------------------------------------------------------
Ran 23 tests in 2.277s
OK (KNOWNFAIL=1)
> If that works for you, we can just take that out and require testers to
> use our testing script (and unfortunately will have to make another
> release candidate).
Well, I wouldn't want to force mpl to have to ship a custom testing
script, that's kind of an ugly kludge that we live with but that is
really sub-optimal. I wish we could just fix this plugin issue. The
problem, I suspect, is the presence of multiple KnownFailure classes
in a way that trips an isisnstance() check somewhere.
Cheers,
f

This was an attempt to fix a bug that mpl's KnownFailure plugin wouldn't 
load when running tests directly using the nosetests commandline 
script. I see IPython has a testing wrapper script (iptest) -- is that 
in part to solve that problem?
In any case, the revert should be simple -- can you try commenting out 
the "entry_points" kwarg at the bottom of the setup.py script? (You'll 
probably need to blitz the matplotlib installation directory and `build` 
for good measure). I can't actually reproduce the bug myself, but I 
suspect that's because this is somewhat dependent on the order in which 
things are installed into the virtualenv or the phases of the moon...
If that works for you, we can just take that out and require testers to 
use our testing script (and unfortunately will have to make another 
release candidate).
Mike
On 06/18/2013 06:13 PM, Fernando Perez wrote:
> Hi Ben,
>
> On Tue, Jun 18, 2013 at 1:29 PM, Benjamin Root <ben...@ou...> wrote:
>
>> Does the same thing happen with the v1.3.x branch? You said you tested
>> master, but that isn't exactly the same as v1.3.x.
> I just tested with the v1.3.0rc3, and the problem is present there:
>
> ((v1.3.0rc3))longs[matplotlib]> iptest -vx IPython.core.tests.test_run
> Check that %run doesn't damage __builtins__ ... ok
> Check that the type of __builtins__ doesn't change with %run. ... ok
> Test that prompts correctly generate after %run ... ok
> Test that the option -p, which invokes the profiler, do not ... ok
> Test that namespace cleanup is not too aggressive GH-238 ... ERROR
>
> ======================================================================
> ERROR: Test that namespace cleanup is not too aggressive GH-238
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
> File "/usr/lib/python2.7/dist-packages/numpy/testing/decorators.py",
> line 213, in knownfailer
> raise KnownFailureTest(msg)
> KnownFailureTest: This test is known to fail
>
> ----------------------------------------------------------------------
> Ran 5 tests in 0.006s
>
> FAILED (errors=1)
>
>
> Cheers,
>
> f
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi Ben,
On Tue, Jun 18, 2013 at 1:29 PM, Benjamin Root <ben...@ou...> wrote:
> Does the same thing happen with the v1.3.x branch? You said you tested
> master, but that isn't exactly the same as v1.3.x.
I just tested with the v1.3.0rc3, and the problem is present there:
((v1.3.0rc3))longs[matplotlib]> iptest -vx IPython.core.tests.test_run
Check that %run doesn't damage __builtins__ ... ok
Check that the type of __builtins__ doesn't change with %run. ... ok
Test that prompts correctly generate after %run ... ok
Test that the option -p, which invokes the profiler, do not ... ok
Test that namespace cleanup is not too aggressive GH-238 ... ERROR
======================================================================
ERROR: Test that namespace cleanup is not too aggressive GH-238
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File "/usr/lib/python2.7/dist-packages/numpy/testing/decorators.py",
line 213, in knownfailer
 raise KnownFailureTest(msg)
KnownFailureTest: This test is known to fail
----------------------------------------------------------------------
Ran 5 tests in 0.006s
FAILED (errors=1)
Cheers,
f

On Tue, Jun 18, 2013 at 4:19 PM, Fernando Perez <fpe...@gm...>wrote:
> Hi folks,
>
> <snip>
>
> Since SciPy'13 is coming and I know Mike will be there, I'm happy to
> try to debug this face to face in Austin. I just wanted to put it on
> your radar, in case it's an easy fix (esp. if it's one you can apply
> before 1.3.0 goes out).
>
> Cheers,
>
>
Fernando,
Does the same thing happen with the v1.3.x branch? You said you tested
master, but that isn't exactly the same as v1.3.x.
Cheers!
Ben Root

Hi folks,
I'm wondering if the following rings any bells for you... Right now,
on an ubuntu 13.04 machine, if I install mpl master (say to my home
directory), the IPython test suite fails here:
iptest -vx IPython.core.tests.test_run
...
======================================================================
ERROR: Test that namespace cleanup is not too aggressive GH-238
----------------------------------------------------------------------
Traceback (most recent call last):
 File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
 File "/usr/lib/python2.7/dist-packages/numpy/testing/decorators.py",
line 213, in knownfailer
 raise KnownFailureTest(msg)
KnownFailureTest: This test is known to fail
If I uninstall mpl from master and revert to the system version
(1.2.1), then it's all OK. We'd seen this problem a few years ago,
but in that case it was the opposite: mpl master was OK and the issue
was mis-packaging by Ubuntu:
https://github.com/ipython/ipython/issues/823
https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/871176
But now the problem appears to be caused by mpl master. Can you think
of any recent changes to mpl in how you load your nose plugins that
could be causing this?
Since SciPy'13 is coming and I know Mike will be there, I'm happy to
try to debug this face to face in Austin. I just wanted to put it on
your radar, in case it's an easy fix (esp. if it's one you can apply
before 1.3.0 goes out).
Cheers,
f
--
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

I have tagged a 1.3.0rc3 and uploaded a tarball to Sourceforge.
We may not get all the binaries up in the next little while, so I'll 
wait for those and then make an announcement on matplotlib-users. After 
a couple of weeks, assuming no serious problems, we'll be ready for 
1.3.0 final.
Thanks again to everyone for their help with this release!
Mike
On 06/17/2013 02:53 PM, Damon McDougall wrote:
>
>
>
> On Mon, Jun 17, 2013 at 9:50 AM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> We're a little behind schedule for 1.3.0 -- held up by the
> distribute/setuptools upgrade debacle. I'd like to put out a 1.3.0rc3
> late tonight or tomorrow, and hopefully get a final release out early
> next week in advance of Scipy if all goes well. Any objections?
>
>
> I'm too far behind on my email to be apprised of the state of 
> distribute vs setuptools. I trust your judgement :)
>
>
> Mike
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> -- 
> Damon McDougall
> http://www.damon-is-a-geek.com
> Institute for Computational Engineering Sciences
> 201 E. 24th St.
> Stop C0200
> The University of Texas at Austin
> Austin, TX 78712-1229

On 06/17/2013 02:10 PM, Benjamin Root wrote:
>
>
> In the meantime, a "bug" I have noticed. In the list of markers: 
> http://matplotlib.org/1.3.0/api/markers_api.html, we have things like 
> "TICKLEFT", "CARETUP" and such. These seem to be some sort of 
> placeholder for the numerical values and is quite confusing. I 
> suspect this has been this way for a while now.
Yes -- these are numeric enumerations defined in matplotlib.markers. 
That should be made clearer, or we should add string aliases for these 
things.
Mike

On Mon, Jun 17, 2013 at 9:50 AM, Michael Droettboom <md...@st...> wrote:
> We're a little behind schedule for 1.3.0 -- held up by the
> distribute/setuptools upgrade debacle. I'd like to put out a 1.3.0rc3
> late tonight or tomorrow, and hopefully get a final release out early
> next week in advance of Scipy if all goes well. Any objections?
>
I'm too far behind on my email to be apprised of the state of distribute vs
setuptools. I trust your judgement :)
>
> Mike
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Damon McDougall
http://www.damon-is-a-geek.com
Institute for Computational Engineering Sciences
201 E. 24th St.
Stop C0200
The University of Texas at Austin
Austin, TX 78712-1229

On Mon, Jun 17, 2013 at 10:05 AM, Michael Droettboom <md...@st...>wrote:
> It might be a good idea to add some of these recommendations to MEP10,
> which serves somewhat as a guide to those that are going through and
> updating the docstrings.
>
>
Will do. I will try to put something together prior to SciPy 2013 so that
they can be discussed.
>
> On 06/15/2013 02:34 PM, Benjamin Root wrote:
>
> As I continue to put together my tutorial for SciPy 2013, I have come
> to realize several things that are lacking with our documentation. First
> of all, while the pyplot summary table:
> http://matplotlib.org/1.3.0/api/pyplot_summary.html is a great addition,
> it is still a huge mis-mash of different kinds of functions. Some
> functions are for plotting, others are for figure and axes prep, and others
> are for decorating the plot. I am just about done with my reorganized list
> and will post it for others to comment and possibly include for that page.
>
>
> Sounds good.
>
>
> Second, if there is one thing that Matlab gets right, it is its
> documentation. Let's compare the doc page for the hist() function:
>
> http://matplotlib.org/1.3.0/api/pyplot_api.html#matplotlib.pyplot.hist
> http://www.mathworks.com/help/matlab/ref/hist.html
> (for those with NoScript, you will want javascript turned on for the
> mathworks page)
>
> First off, I think there is some sort of error in the docstring because
> the sphinx rendering is a bit messed up. Second, in the matlab doc page,
> there is a dead simple, complete, concise example for each call signature,
> and an image of the plot to go with it.
>
> I think this is key. I am finding some functions that have examples that
> demonstrate more than just the plotting function, i.e., hexbin(), or are
> missng examples altogether, i.e., matshow() and pie().
>
> So, my proposal is this. For every plotting function, there should be a
> minimalist, complete example available to demonstrate it. Further, that
> example and its result should be easily viewable from the function's
> documentation. For organization's sake, I would suggest having a
> consistent naming scheme for this kind of example. Lastly, such an example
> should be required as part of any pull request to add new plotting
> functions.
>
> Also sounds good. Let's add that to the pull request checklist here:
>
> http://matplotlib.org/devel/coding_guide.html
>
>
I'll put together a PR with a proposed naming scheme and a first pass at
creating a bunch of these examples. I was thinking that it might be nice
to put together a "gallery" of some sort that showcases the plotting
functions that are available using these simple examples, and clicking on
the image would take you to the documentation for that function.
>
> As a side note related to "easily viewable example code", one thing I
> don't like about the examples in the doc strings is that they don't provide
> me a link to one of these pages:
> http://matplotlib.org/1.3.0/examples/pie_and_polar_charts/pie_demo_features.html.
> Those pages are nice because I can see the code and the image it produces
> at the same time. Instead, those API doc pages just gives me a link to
> download the source code, or to view the image. Is it at all possible to
> have the example sphinx directive include a link to those example pages
> when rendering the API documentation?
>
>
> It is possible -- it's not really how it works now. The example pages are
> generated from python source files in the examples/ tree, whereas the
> docstring examples are inserted inline into the docstring (or sometimes
> referencing external files). But with a little tweaking of the plot
> directive extension, it should be possible.
>
>
We can certainly flesh out the idea some more during SciPy2013.
In the meantime, a "bug" I have noticed. In the list of markers:
http://matplotlib.org/1.3.0/api/markers_api.html, we have things like
"TICKLEFT", "CARETUP" and such. These seem to be some sort of placeholder
for the numerical values and is quite confusing. I suspect this has been
this way for a while now.
Cheers!
Ben Root

We're a little behind schedule for 1.3.0 -- held up by the 
distribute/setuptools upgrade debacle. I'd like to put out a 1.3.0rc3 
late tonight or tomorrow, and hopefully get a final release out early 
next week in advance of Scipy if all goes well. Any objections?
Mike

It might be a good idea to add some of these recommendations to MEP10, 
which serves somewhat as a guide to those that are going through and 
updating the docstrings.
On 06/15/2013 02:34 PM, Benjamin Root wrote:
> As I continue to put together my tutorial for SciPy 2013, I have come 
> to realize several things that are lacking with our documentation. 
> First of all, while the pyplot summary table: 
> http://matplotlib.org/1.3.0/api/pyplot_summary.html is a great 
> addition, it is still a huge mis-mash of different kinds of 
> functions. Some functions are for plotting, others are for figure and 
> axes prep, and others are for decorating the plot. I am just about 
> done with my reorganized list and will post it for others to comment 
> and possibly include for that page.
Sounds good.
>
> Second, if there is one thing that Matlab gets right, it is its 
> documentation. Let's compare the doc page for the hist() function:
>
> http://matplotlib.org/1.3.0/api/pyplot_api.html#matplotlib.pyplot.hist
> http://www.mathworks.com/help/matlab/ref/hist.html
> (for those with NoScript, you will want javascript turned on for the 
> mathworks page)
>
> First off, I think there is some sort of error in the docstring 
> because the sphinx rendering is a bit messed up. Second, in the 
> matlab doc page, there is a dead simple, complete, concise example for 
> each call signature, and an image of the plot to go with it.
>
> I think this is key. I am finding some functions that have examples 
> that demonstrate more than just the plotting function, i.e., hexbin(), 
> or are missng examples altogether, i.e., matshow() and pie().
>
> So, my proposal is this. For every plotting function, there should be 
> a minimalist, complete example available to demonstrate it. Further, 
> that example and its result should be easily viewable from the 
> function's documentation. For organization's sake, I would suggest 
> having a consistent naming scheme for this kind of example. Lastly, 
> such an example should be required as part of any pull request to add 
> new plotting functions.
Also sounds good. Let's add that to the pull request checklist here:
http://matplotlib.org/devel/coding_guide.html
>
> As a side note related to "easily viewable example code", one thing I 
> don't like about the examples in the doc strings is that they don't 
> provide me a link to one of these pages: 
> http://matplotlib.org/1.3.0/examples/pie_and_polar_charts/pie_demo_features.html. 
> Those pages are nice because I can see the code and the image it 
> produces at the same time. Instead, those API doc pages just gives me 
> a link to download the source code, or to view the image. Is it at 
> all possible to have the example sphinx directive include a link to 
> those example pages when rendering the API documentation?
It is possible -- it's not really how it works now. The example pages 
are generated from python source files in the examples/ tree, whereas 
the docstring examples are inserted inline into the docstring (or 
sometimes referencing external files). But with a little tweaking of 
the plot directive extension, it should be possible.
Mike
>
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

As I continue to put together my tutorial for SciPy 2013, I have come to
realize several things that are lacking with our documentation. First of
all, while the pyplot summary table:
http://matplotlib.org/1.3.0/api/pyplot_summary.html is a great addition, it
is still a huge mis-mash of different kinds of functions. Some functions
are for plotting, others are for figure and axes prep, and others are for
decorating the plot. I am just about done with my reorganized list and
will post it for others to comment and possibly include for that page.
Second, if there is one thing that Matlab gets right, it is its
documentation. Let's compare the doc page for the hist() function:
http://matplotlib.org/1.3.0/api/pyplot_api.html#matplotlib.pyplot.hist
http://www.mathworks.com/help/matlab/ref/hist.html
(for those with NoScript, you will want javascript turned on for the
mathworks page)
First off, I think there is some sort of error in the docstring because the
sphinx rendering is a bit messed up. Second, in the matlab doc page, there
is a dead simple, complete, concise example for each call signature, and an
image of the plot to go with it.
I think this is key. I am finding some functions that have examples that
demonstrate more than just the plotting function, i.e., hexbin(), or are
missng examples altogether, i.e., matshow() and pie().
So, my proposal is this. For every plotting function, there should be a
minimalist, complete example available to demonstrate it. Further, that
example and its result should be easily viewable from the function's
documentation. For organization's sake, I would suggest having a
consistent naming scheme for this kind of example. Lastly, such an example
should be required as part of any pull request to add new plotting
functions.
As a side note related to "easily viewable example code", one thing I don't
like about the examples in the doc strings is that they don't provide me a
link to one of these pages:
http://matplotlib.org/1.3.0/examples/pie_and_polar_charts/pie_demo_features.html.
Those pages are nice because I can see the code and the image it produces
at the same time. Instead, those API doc pages just gives me a link to
download the source code, or to view the image. Is it at all possible to
have the example sphinx directive include a link to those example pages
when rendering the API documentation?
Cheers!
Ben Root

Thank you for the contribution. Would you mind creating this as a pull 
request so we can comment on it and keep track of its progress? (Visit 
your forks' page -- there should be a "pull request" button for your 
"topic;voronoi" branch there).
And also, just to note I have some immediate commitments and may not get 
to this for a while personally -- which isn't to say any of the other 
fine folks here won't :)
Mike
On 06/11/2013 08:28 AM, Eduard Bopp wrote:
> Dear matplotlib devs,
>
> I've been working on an implementation of Voronoi diagrams in
> matplotlib. It is based on the Delaunay triangulation and simply creates
> a PatchCollection of Voronoi cells.
>
> I added a function/method to the pyplot module and the Axes class,
> respectively, which is called like this:
>
> voronoi(X, Y, ...)
> voronoi(X, Y, C, ...)
>
> where X, Y are coordinates of an unstructured grid and C an optional
> mappable scalar.
>
> The topic branch in my fork is in a fully operational state now and I
> would like to ask you to review it.
>
> Check it out here:
> https://github.com/aepsil0n/matplotlib/compare/topic;voronoi
>
> Kind regards,
> Eduard Bopp
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Dear matplotlib devs,
I've been working on an implementation of Voronoi diagrams in
matplotlib. It is based on the Delaunay triangulation and simply creates
a PatchCollection of Voronoi cells.
I added a function/method to the pyplot module and the Axes class,
respectively, which is called like this:
voronoi(X, Y, ...)
voronoi(X, Y, C, ...)
where X, Y are coordinates of an unstructured grid and C an optional
mappable scalar.
The topic branch in my fork is in a fully operational state now and I
would like to ask you to review it.
Check it out here:
https://github.com/aepsil0n/matplotlib/compare/topic;voronoi
Kind regards,
Eduard Bopp

I think I may just have messed up a commit to the doc repository. It 
should be fixed once the documentation updates again in a few minutes.
Mike
On 06/08/2013 05:11 PM, Benjamin Root wrote:
> Just noticed that in the Annotation Guide for 1.3:
> http://matplotlib.org/1.3.0/users/annotations_guide.html
>
> There is a dead link to the source code for one of the examples:
> http://matplotlib.org/1.3.0/mpl_examples/pylab_examples/fancyarrow_demo.py
>
> In fact, the source code links to just about all of those examples are 
> 404's.
>
> Ben
>
>
> ------------------------------------------------------------------------------
> How ServiceNow helps IT people transform IT departments:
> 1. A cloud service to automate IT design, transition and operations
> 2. Dashboards that offer high-level views of enterprise services
> 3. A single system of record for all IT processes
> http://p.sf.net/sfu/servicenow-d2d-j
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Just noticed that in the Annotation Guide for 1.3:
http://matplotlib.org/1.3.0/users/annotations_guide.html
There is a dead link to the source code for one of the examples:
http://matplotlib.org/1.3.0/mpl_examples/pylab_examples/fancyarrow_demo.py
In fact, the source code links to just about all of those examples are
404's.
Ben

So, I tried all of that without much useful insight gained. I decided to
grep around for that unicode character, but it doesn't exist in any of the
sources (only images and font files). I am now wondering if it is an
obscure issue with sphinx. Looks like I am going to have to crack open
that mercurial book...
Ben Root

Hi there
I am not 100% sure whether this is a bug or whether I do something 
wrong. However, I have the problem that the __init__ of 
NavigationToolbar2Wx does not take the parent of the wx.ToolBar as an 
input parameter. Instead it takes a canvas, and assumes that the parent 
of the canvas is the parent of the toolbar as well.
In my attached example however, the parent of the wx.ToolBar should be 
PlotFrame, whereas the parent of the canvas should be PlotWindow. As a 
result, the NavigationToolbar is not placed correctly in the frame, and 
sometimes invisible.
The same problem was already reported here:
http://matplotlib.1069221.n5.nabble.com/NavigationToolbar2WxAgg-Buttons-Disappear-td38516.html
My python version is 2.7.5 and matplotlib version is 1.1.1rc2.
A simple backward compatible solution to this problem is adding an 
optional frame parameter to the NavigationToolbar2Wx __init__ like this:
class NavigationToolbar2Wx(NavigationToolbar2, wx.ToolBar):
def __init__(self, canvas, frame=None, can_kill=False):
 if frame=None:
wx.ToolBar.__init__(self, canvas.GetParent(), -1)
 else:
wx.ToolBar.__init__(self, frame, -1)
 NavigationToolbar2.__init__(self, canvas)
Could someone tell me whether this should be included into matplotlib 
like this?
With best regards
Matthias Baur

I have a series of streamlines that need to be animated...
animation.Artistanimation() does not allow since it says Streamplotset is
not iterable.
So I tried animation.Funcanimation() and seems like this doesnt work easily
too,
Have any of you tried this earlier...?
I am unable to get the velocity lines and arrows to point to the updated
values in the call back functin 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/plt-streamplot-and-animation-Funcanimation-tp41234.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

> No, there was no such message. That is all that was displayed to my
> screen.
>
I've seen this error before, and I think cleaning up all sphinx caching and
temporary files "fixed" it.
Try running a python make.py clean before building the documention.
Cheers,
N
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Thu, May 30, 2013 at 11:29 PM, Nicolas Rougier
<Nic...@in...> wrote:
>> I'm also concerned about the overhead of
>> ctypes, given that there are already so many required optimizations in
>> the matplotlib freetype wrapper to make it fast enough. But I'm willing
>> to hold judgement on that until some measurements have been made.
>>
>
> I would never have thought ctypes would be a problem for speed/optimization and I never benchmarked the freetype-py.
Well, I see it this way -- for high performing Python code, you often
need to "vectorize" operations one way or another. i.e. if you need to
do a given operation on a bunch of numbers, objects, whatever, you
need to be able to pass the collection in to lower-level code, so you
dont have all the overhead of python funciton calls, dynamic typing,
etc, inside your loop.
Many (most) C libraries are not designed this way. So when writing
python wrappers, you need to loop though a sequence in python, and
call the underlying c function for each item. With ctypes, you write
that code inPython, with cython, it's easy to write that code in
cython, which gets compiled down to C -- you can get major performance
benefits from this.
And Cython is almost at easy to write as Python.
How this applied to freetype, I don't know.
>> 2) It's not Numpy-aware. For example, it loads image buffers into
>> regular Python lists. This really should use Numpy for speed.
you can do this with ctypes, and would work fine for image buffers, by
many not as well as Cython for say, a large sequence of characters...
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...