matplotlib-devel Mailing List for matplotlib

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