Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On Mon, Mar 26, 2012 at 7:08 AM, Rui DaCosta wrote: > Attached is the testing output on both Win7x64 and WinXPx32. > > FAILED (KNOWNFAIL=268, errors=144) > > In case anybody else is having issues, the head version of nose is > required to run the tests due to multiprocessing issues in the stable > version of nose. > > After installing PIL, most of the KNOWNFAIL issues are similar to: Cannot > compare pdf files on this system (why is this?) > most of the errors are: IOError: [Errno 24] Too many open files > > The bulk of the KNOWNFAILs are occurring because you do not have the pre-requisites installed for testing the PDF, SVG and PS backends. The test requirements for these backends are described at http://matplotlib.sourceforge.net/devel/coding_guide.html#requirements The bulk of the other failures are occurring because you are hitting the "too many open file" bug on windows. This has been addressed in this pull request, and we'd be happy to have testers on windows of this PR https://github.com/matplotlib/matplotlib/pull/798 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
Thanks - had been looking at obsolete information. WRT inkscape and ghostscript, I have installed both but still got the same fails. Upon inspection it appears that both executables need to be on system path (perhaps this should be mentioned on the coding guide?), and that the code was only looking for the 32bit GS exe name (gswin32c instead of gswin64c that i had) After that those tests all pass leaving me with: FAILED (KNOWNFAIL=2, errors=144) WRT files bug, I'll monitor that PR and test, thanks. Regards, RuiDC From: John Hunter To: Rui DaCosta Cc: matplotlib development list Sent: Monday, 26 March 2012, 15:02 Subject: Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday On Mon, Mar 26, 2012 at 7:08 AM, Rui DaCosta wrote: Attached is the testing output on both Win7x64 and WinXPx32. > > >FAILED (KNOWNFAIL=268, errors=144) > > > >In case anybody else is having issues, the head version of nose is required to >run the tests due to multiprocessing issues in the stable version of nose. > > >After installing PIL, most of the KNOWNFAIL issues are similar to: Cannot >compare pdf files on this system (why is this?) >most of the errors are: IOError: [Errno 24] Too many open files > > The bulk of the KNOWNFAILs are occurring because you do not have the pre-requisites installed for testing the PDF, SVG and PS backends. The test requirements for these backends are described at http://matplotlib.sourceforge.net/devel/coding_guide.html#requirements The bulk of the other failures are occurring because you are hitting the "too many open file" bug on windows. This has been addressed in this pull request, and we'd be happy to have testers on windows of this PR https://github.com/matplotlib/matplotlib/pull/798 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
> On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> wrote:
>> I used the 1.1.0 version to build with the fink Python installation on MaxOS
>> X
>> and everything seems to work there, passing the tests at least (does
>> pylab.test('full')
>> execute all tests? It seems a rather small number…).
>
> to run tests I use:
>
> python -c "import matplotlib as m ; m.test(verbosity=1)"
Thank you for the test instructions. That's a much more complete test than I
had been using. I get the following one failure on Mac OS X 10.6 using my new
binary installer (results are appended). I'm also concerned about the complaint:
"""
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921:
UserWarning: This call to matplotlib.use() has no effect
because the the backend has already been chosen;
matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
or matplotlib.backends is imported for the first time.
"""
which suggests a test that is mis-written.
-- Russell
localhost$ python
imporPython 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 14:13:39)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
matplotlib.>>> matplotlib.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.KKK...KK...KK.KK....KK.KK.KK.KK.KK..KK.KK.KKKK..K..K..KKKK.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../Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1218:
UserWarning: findfont: Font family ['sans-serif'] not found. Falling back to
Bitstream Vera Sans
(prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=normal:stretch=normal:size=14.0.
Returning
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=bold:stretch=500:size=14.0. Returning
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1218:
UserWarning: findfont: Font family ['sans serif'] not found. Falling back to
Bitstream Vera Sans
(prop.get_family(), self.defaultFamily[fontext]))
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=italic:variant=normal:weight=750:stretch=500:size=14.0. Returning
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=200:stretch=500:size=14.0. Returning
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
UserWarning)
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/font_manager.py:1228:
UserWarning: findfont: Could not match :family=Bitstream Vera
Sans:style=normal:variant=normal:weight=500:stretch=100:size=14.0. Returning
/Applications/TUI.app/Contents/Resources/lib/python2.7/matplotlib/mpl-data/fonts/ttf/Vera.ttf
UserWarning)
FKK.KK.KK.KK.KK.KK.KK.KK.K...K..KKK...KK.KK
==
FAIL: matplotlib.tests.test_text.test_font_styles.test
--
Traceback (most recent call last):
File
"/Library/Frameworks
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen wrote:
> On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
>
> > On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> > wrote:
> >> I used the 1.1.0 version to build with the fink Python installation on
> MaxOS X
> >> and everything seems to work there, passing the tests at least (does
> pylab.test('full')
> >> execute all tests? It seems a rather small number…).
> >
> > to run tests I use:
> >
> > python -c "import matplotlib as m ; m.test(verbosity=1)"
>
> Thank you for the test instructions. That's a much more complete test than
> I had been using. I get the following one failure on Mac OS X 10.6 using my
> new binary installer (results are appended). I'm also concerned about the
> complaint:
> """
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921:
> UserWarning: This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
> """
> which suggests a test that is mis-written.
At the end of the tests we try and switch back to the users original
backend (we switch into agg at the start) in case the user is running
interactively. This warning is mostly harmless, and doesn't indicate a
problem with any tests. It appears you have just the one failure on
fonts-styles.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Using `hexbin` with `edgecolors = 'none'`
I'm drawing hexbins with alpha < 1 and get dark lines at the bin edges. It turns out that setting `edgecolors = 'none'` sets the edge color to be the same as the face color, as mentioned in the docstring: If ``'none'``, draws the edges in the same color as the fill color. This is the default, as it avoids unsightly unpainted pixels between the hexagons. This behavior is a bit weird, since setting colors to 'none' usually makes the element invisible. Wouldn't it be more consistent to let 'none' be passed to the PolyCollection (which draws the hexbins), such that edges aren't drawn. Then, to maintain the current behavior, change the default to 'face'. (Of course, this wouldn't really maintain current behavior for code that explicitly passes `edgecolors='none'`.) Also, if I let 'none' get passed to the PolyCollection, I don't see the "unsightly unpainted pixels between the hexagons". Is this just a system-dependent artifact, or is it an outdated docstring? Thanks, -Tony -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On 26.03.2012, at 7:43PM, John Hunter wrote:
> On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen wrote:
> On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
>
> > On Sat, Mar 24, 2012 at 18:13, Derek Homeier
> > wrote:
> >> I used the 1.1.0 version to build with the fink Python installation on
> >> MaxOS X
> >> and everything seems to work there, passing the tests at least (does
> >> pylab.test('full')
> >> execute all tests? It seems a rather small number…).
> >
> > to run tests I use:
> >
> > python -c "import matplotlib as m ; m.test(verbosity=1)"
>
> Thank you for the test instructions. That's a much more complete test than I
> had been using. I get the following one failure on Mac OS X 10.6 using my new
> binary installer (results are appended). I'm also concerned about the
> complaint:
> """
> /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/__init__.py:921:
> UserWarning: This call to matplotlib.use() has no effect
> because the the backend has already been chosen;
> matplotlib.use() must be called *before* pylab, matplotlib.pyplot,
> or matplotlib.backends is imported for the first time.
> """
> which suggests a test that is mis-written.
>
> At the end of the tests we try and switch back to the users original backend
> (we switch into agg at the start) in case the user is running interactively.
> This warning is mostly harmless, and doesn't indicate a problem with any
> tests. It appears you have just the one failure on fonts-styles.
>
I also had two failures of this type on my first attempt to test the package;
now when
testing within the fink build environment, everything passes. This might have
to do
with the fontconfig setup, not sure if I can reproduce it any more or nail it
further down.
> Ran 1061 tests in 344.859s
>
> FAILED (KNOWNFAIL=541, failures=1)
Russel, you may also want to check the testing dependencies mentioned in
connection
with the tests under Windows in this thread - installing inkscape in addition
to ghostscript
and pil got me rid of the Known Failures (due to missing functionality for
comparing PDF
and SVG output) as well.
Does anyone see a problem with running the tests with 'python -B'? Otherwise
I'd need to
get rid of the byte-compiled files in the build directory afterwards, as they
would cause the
package validation to fail.
Cheers,
Derek
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
Hi Sandro, > yes, Debian has a separate package for documentation (since it > requires to be build just on time, whilc mpl requires to be built on > each architecture we support, so splitting the package results in a > lot of saved space). JFYR this is the layout of packages in Debian: > > python-matplotlib - the python module > python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + > fonts > python-matplotlib-dbg - debug symbols for python extensions > python-matplotlib-doc - all the built doc, in html and pdf formats thanks for the info; currently fink only has extra packages for the basemap toolkit. While there are not that many actual architectures, there are still up to 4 or 5 Python versions to support, so a single doc package could also save a lot (although I am not sure how to setup such a build yet…). The actual matplotlib module could also be reduced much further in size when building from the _notests tar ball. I am not sure how much demand there is for normal users to be able to run the complete test suite. Or is this just a temporary option for the rc builds anyway? Cheers, Derek -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On Mar 26, 2012, at 7:37 PM, Derek Homeier wrote: > Hi Sandro, > >> yes, Debian has a separate package for documentation (since it >> requires to be build just on time, whilc mpl requires to be built on >> each architecture we support, so splitting the package results in a >> lot of saved space). JFYR this is the layout of packages in Debian: >> >> python-matplotlib - the python module >> python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + >> fonts >> python-matplotlib-dbg - debug symbols for python extensions >> python-matplotlib-doc - all the built doc, in html and pdf formats > > thanks for the info; currently fink only has extra packages for the basemap > toolkit. > While there are not that many actual architectures, there are still up to 4 > or 5 > Python versions to support, so a single doc package could also save a lot > (although I am not sure how to setup such a build yet…). > The actual matplotlib module could also be reduced much further in size when > building from the _notests tar ball. I am not sure how much demand there is > for normal users to be able to run the complete test suite. Or is this just a > temporary option for the rc builds anyway? > I have also been uploading a "notests" tarball for those who do not want to carry the extra weight of the baseline test images. For packagers concerned about size, one option would be to provide just the baseline images as a separate package. These are all the PNGs recursively under lib/matplotlib/tests. -- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
