matplotlib-devel Mailing List for matplotlib

Hi,
On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom <md...@st...> wrote:
> On 10/18/2013 02:11 AM, Matthew Brett wrote:
>> Hi,
>>
>> I'm testing the binary installer build:
>>
>> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220
>>
>> and I'm getting a test failure on Python 3.3 (not Python 2.7):
>>
>> ======================================================================
>> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py",
>> line 198, in runTest
>> self.test(*self.arg)
>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py",
>> line 73, in test
>> self._func()
>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py",
>> line 54, in test_invisible_Line_rendering
>> assert_true(slowdown_factor < slowdown_threshold)
>> AssertionError: False is not true
>>
>> ----------------------------------------------------------------------
>> Ran 1464 tests in 656.822s
>>
>> Is this a problem? What should I do to debug further?
>>
>
> I've never seen that failure before...
>
> I wonder if Pierre Haessig has any thoughts, as the author of that test...
>
> Mike
Thanks. I get the same error running under Python 2.7 on a clean 10.6 machine.
Also I get:
======================================================================
FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.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 40, in failer
 result = f(*args, **kwargs)
 File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 159, in do_test
 '(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close:
/Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png
vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png
(RMS 15.521)
The images look identical to me...
Cheers,
Matthew

On 18 October 2013 19:18, Chris Barker <chr...@no...> wrote:
> Ian,
>
> > I am working on a PR to replace the use of matplotlib.delaunay with the
> > Qhull library.
>
> nice! -- ( though I sure wish Qhull did constrained delaunay...)
>
> > Installation will be similar to the existing packages LibAgg
> > and CXX in that if the system already has a sufficiently recent version
> of
> > Qhull installed then matplotlib will use that, otherwise it will build
> the
> > required library from the source code shipped with matplotlib.
>
> Why bother, why not just always build the internal version?
>
> (for that matter, same with agg)
>
> Wouldn't it be a lot easier and more robust to be sure that everyone
> is running the exact same code?
>
> What are the odds that folks are using qhull for something else, and
> even more to the point, what are the odds that the duplication of this
> lib would matter one wit?
>
> This isn't like LAPACK, where folks have a compellling reason to run a
> particular version.
>
> -- just my thoughts on how to keep things simpler.
>
Chris,
Todd has hit the nail on the head.
To expand slightly, with the current situation the onus is on us to ensure
that mpl builds OK and passes all of our tests with and without each of the
external libraries. Linux distro packagers will choose to set up qhull as
a required dependency for their mpl package, and once they have done this
can simply delete our directory containing the qhull source code in their
mpl source package, and it will build OK without any further changes and we
can all be confident that it will work correctly.
If we always used our internal version then distro packagers would have to
change our setup scripts to build using the external libraries. This would
be more time-consuming and error prone leading to less timely mpl distro
releases. We need to make their job as easy as possible.
Ian