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
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
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
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
On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jdh2358@…272…149…> 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.
Hi John,
Windows binaries, including the test files, are at <Archived: Python Extension Packages for Windows - Christoph Gohlke.
All my attempts to upload the files to SF failed (no error report).
I'll run tests later.
Christoph
On 3/22/2012 7:18 PM, John Hunter wrote:
On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jdh2358@...149... > <mailto:jdh2358@…149…>> 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 binariesmatplotlib - Browse /matplotlib/matplotlib-1.1.1 at SourceForge.net
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
Merge branch 'v1.1.x' of github.com:matplotlib/matplotlib into v1.1.x · matplotlib/matplotlib@c5593ee · GitHubThere 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.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" issuev1.1.1 release candidate testing · Issue #791 · matplotlib/matplotlib · GitHub
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
Hey Christoph, not sure why you are unable to upload, since I have you designated as a “release manager” on the sf site, but thanks for building these and I’ve uploaded these and they are good to go.
On Thu, Mar 22, 2012 at 10:57 PM, Christoph Gohlke <cgohlke@…244…> wrote:
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.
Hi John,
On Fri, Mar 23, 2012 at 03:18, John Hunter <jdh2358@...149...> wrote:
The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
are available for testing and building binariesmatplotlib - Browse /matplotlib/matplotlib-1.1.1 at SourceForge.net
After the binaries are up, I'll send out a notice to the users list
requesting wider testing, but intrepid developers can begin now.
I'll start testing debian packaging right away; for our package we
also need the sampledata tarball: can I reuse the one for 1.1.0 or is
a new one needed?
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
You can use the same one – because this is a bugfix release, we have not introduced any new features, examples or data. Just bugfixes.
JDH
On Fri, Mar 23, 2012 at 12:21 PM, Sandro Tosi <morph@…715…> wrote:
I’ll start testing debian packaging right away; for our package we
also need the sampledata tarball: can I reuse the one for 1.1.0 or is
a new one needed?
Hi Sandro,
The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
are available for testing and building binariesmatplotlib - Browse /matplotlib/matplotlib-1.1.1 at SourceForge.net
After the binaries are up, I'll send out a notice to the users list
requesting wider testing, but intrepid developers can begin now.I'll start testing debian packaging right away; for our package we
also need the sampledata tarball: can I reuse the one for 1.1.0 or is
a new one needed?
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…).
I have another question - I am trying to build a fink package with the documentation
and am wondering if "python make.py --small html" actually has any effect?
This still creates more than 70 MB of documentation, 24 MB in the _images subdir
alone, which increases the .deb size by a factor of ~2.5. How are you handling this
for the Debian package?
Cheers,
Derek
On Fri, Mar 23, 2012 at 03:18, John Hunter <jdh2358@...149...> 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)"
I have another question - I am trying to build a fink package with the documentation
and am wondering if "python make.py --small html"
In debian I use:
./make.py --small all
actually has any effect?
what do you mean?
This still creates more than 70 MB of documentation, 24 MB in the _images subdir
alone, which increases the .deb size by a factor of ~2.5. How are you handling this
for the Debian package?
well, yes, the doc is huge (the debian package size is 52M compressed)
and that is good; --small helped reducing the package size, setting
if small_docs:
options = "-D plot_formats=\"[('png', 80)]\""
which reduced the type and size of the output images.
Cheers,
On Sat, Mar 24, 2012 at 18:13, Derek Homeier <derek@...873...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
to run tests I use:
python -c "import matplotlib as m ; m.test(verbosity=1)"
Ah, thanks for the reminder; that looks much more comprehensive!
Actually the fink testing command requires an exit value of 1 or higher to
detect errors, so I am using something like
"… r=m.test(verbosity=1); sys.exit(len(r.errors+r.failures))"
I have another question - I am trying to build a fink package with the documentation
and am wondering if "python make.py --small html"In debian I use:
./make.py --small all
actually has any effect?
what do you mean?
This still creates more than 70 MB of documentation, 24 MB in the _images subdir
alone, which increases the .deb size by a factor of ~2.5. How are you handling this
for the Debian package?well, yes, the doc is huge (the debian package size is 52M compressed)
and that is good; --small helped reducing the package size, settingif small_docs:
options = "-D plot_formats=\"[('png', 80)]\""which reduced the type and size of the output images.
Indeed, I seemed to remember the regular output was not that much larger,
but I must have missed all the hires.png and pdf images in the mpl_examples.
They do account for additional 60-70 MB...
I was also curious if you had considered moving the docs to a separate package.
I will propose one for fink; since there probably more people are building their
packages themselves, the savings in build time might already justify that.
Cheers,
Derek
On 24.03.2012, at 8:16PM, Sandro Tosi wrote:
Hi Derek,
I was also curious if you had considered moving the docs to a separate package.
I will propose one for fink;
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
Cheers,
On Mon, Mar 26, 2012 at 02:50, Derek Homeier <derek@...873...> wrote:
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Great!
The only thing I've noticed is:
- INSTALL contains a weird "numpy version |minimum_numpy_version|"
probably a missing substitution?
Other than that, the package was fine, and i've uploaded to Debian unstable.
Cheers,
On Fri, Mar 23, 2012 at 18:55, John Hunter <jdh2358@...149...> wrote:
On Fri, Mar 23, 2012 at 12:21 PM, Sandro Tosi <morph@...12...> wrote:
I'll start testing debian packaging right away; for our package we
also need the sampledata tarball: can I reuse the one for 1.1.0 or is
a new one needed?You can use the same one -- because this is a bugfix release, we have not
introduced any new features, examples or data. Just bugfixes.
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
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
This appears to be due to the MS C Runtime default limit of 512 files referred to here: Carbon60: Managed Cloud Services
Is there any
workaround?
apart from these, there are still some others but i’m unsure if that is because of the above error:
ImportError: No module named dual
ImportError: No module named tight_layout
HTH
RuiDC
mpl_test_winXPx32.txt (211 KB)
mpl_test_win7x64.txt (211 KB)
From: Sandro Tosi <morph@…12…>
To: Derek Homeier <derek@…873…>
Cc: Russell E. Owen <rowen@…748…>; John Hunter <jdh2358@…149…>; Thomas Robitaille <thomas.robitaille@…322…9…>; matplotlib development list
matplotlib-devel@lists.sourceforge.net
Sent: Saturday, 24 March 2012, 20:16
Subject: Re: [matplotlib-devel] matplotlib v1.1.1 (bugfix) rc1 on Thursday
On Sat, Mar 24, 2012 at 18:13, Derek Homeier <derek@…873…> 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)”
I have another question - I am trying to build a fink package with the documentation
and am wondering if “python
make.py --small html”
In debian I use:
./make.py --small all
actually has any effect?
what do you mean?
This still creates more than 70 MB of documentation, 24 MB in the _images subdir
alone, which increases the .deb size by a factor of ~2.5. How are you handling this
for the Debian package?
well, yes, the doc is huge (the debian package size is 52M compressed)
and that is good; --small helped reducing the package size, setting
if small_docs:
options = "-D plot_formats=\"[('png', 80)]\""
which reduced the type and size of the output images.
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
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
On Mon, Mar 26, 2012 at 7:08 AM, Rui DaCosta <ruidc@…552…42…> 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
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 <jdh2358@…716…>
To: Rui DaCosta <ruidc@…42…>
Cc: matplotlib development list <matplotlib-devel@…712…et>
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 <ruidc@…42…> 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
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..KKKK..KK.KK.KK.KK.KK..KK.KK.KK............K................................................................K..K......................................K......................K....................................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.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..KK................K...........................KK.KK
On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
On Sat, Mar 24, 2012 at 18:13, Derek Homeier > <derek@...873...> wrote:
======================================================================
FAIL: matplotlib.tests.test_text.test_font_styles.test
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose-0.11.4-py2.7.egg/nose/case.py", line 186, in runTest
self.test(*self.arg)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 36, in failer
result = f(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 140, in do_test
'(RMS %(rms).3f)'%err)
ImageComparisonFailure: images not close: /Users/rowen/result_images/test_text/font_styles.png vs. /Users/rowen/result_images/test_text/expected-font_styles.png (RMS 47.138)
----------------------------------------------------------------------
Ran 1061 tests in 344.859s
FAILED (KNOWNFAIL=541, failures=1)
/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.
if warn: warnings.warn(_use_error_msg)
False
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
On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen <rowen@…1070…8…> wrote:
On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
On Sat, Mar 24, 2012 at 18:13, Derek Homeier > > > <derek@…873…> 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.
>> 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
On 26.03.2012, at 7:43PM, John Hunter wrote:
On Mon, Mar 26, 2012 at 12:00 PM, Russell Owen <rowen@...748...> wrote:
On Mar 24, 2012, at 12:16 PM, Sandro Tosi wrote:
> On Sat, Mar 24, 2012 at 18:13, Derek Homeier > > <derek@...873...> 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?
Cheers,
Derek