On 09/24/2011 08:22 AM, John Hunter wrote: > On Fri, Sep 23, 2011 at 5:04 PM, Benjamin Root<ben...@ou...> wrote: >> Personally, my vote is to live with the deprecation warnings. They only >> happen if you turn warnings on in python 2.7 (by default, they are off). I >> am not that comfortable with such a change this close to release for a minor >> issue (unless I am missing something..?) > I trust Michael to get this right ahead of the release. It's a known > issue he's fixed before. I can test on a python 2.4 and 2.7 so if it > works on both of those I am comfortable. If we break something, we > can fix it. I have a pull request for this here: https://github.com/matplotlib/matplotlib/pull/493 Mike
I'm seeing five test failures on my Mac (Python 2.7): FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip FAIL: matplotlib.tests.test_text.test_font_styles.test FAIL: matplotlib.tests.test_text.test_font_styles.test FAIL: matplotlib.tests.test_tightlayout.test_tight_layout5.test FAIL: no_testCreateLocaltime (test_tzinfo.LocalTestCase) (The test_font_styles test produces two failures, one for agg and one for svg.) -- Jouni K. Seppänen http://www.iki.fi/jks
On Sat, Sep 24, 2011 at 8:25 AM, Jouni K. Seppänen <jk...@ik...> wrote: > I'm seeing five test failures on my Mac (Python 2.7): > > FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip > I am seeing this one on my 64-bit machine, but not on my 32-bit machine (both Linux). > FAIL: matplotlib.tests.test_text.test_font_styles.test > FAIL: matplotlib.tests.test_text.test_font_styles.test > How much was the difference? > FAIL: matplotlib.tests.test_tightlayout.test_tight_layout5.test > Hmm, I wonder if font issues on the macosx backend might cause the layout to not be exactly the same as on the other backends? (or does the test use Agg?) > FAIL: no_testCreateLocaltime (test_tzinfo.LocalTestCase) > > Any info provided on this failure? Ben Root
Benjamin Root <ben...@ou...> writes: >> I'm seeing five test failures on my Mac (Python 2.7): >> >> FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip >> > > I am seeing this one on my 64-bit machine, but not on my 32-bit machine > (both Linux). > > >> FAIL: matplotlib.tests.test_text.test_font_styles.test >> FAIL: matplotlib.tests.test_text.test_font_styles.test >> > > How much was the difference? Large: in all three result images, the condensed and light fonts look the same as normal, and there are differences in kerning. It's arguably a problem in the test that the pdf case did not fail as well, since it had the same erroneous output. I wonder if this is a Freetype version issue... >> FAIL: matplotlib.tests.test_tightlayout.test_tight_layout5.test >> > > Hmm, I wonder if font issues on the macosx backend might cause the layout to > not be exactly the same as on the other backends? (or does the test use > Agg?) This failure was with the svg backend, and the difference is in where exactly the borders of the colored squares are, nothing to do with fonts. I'll attach the relevant images. >> FAIL: no_testCreateLocaltime (test_tzinfo.LocalTestCase) >> >> > Any info provided on this failure? AssertionError: '2004-10-31 02:00:00 AMT+0020' != '2004-10-31 02:00:00 CET+0100' -- Jouni K. Seppänen http://www.iki.fi/jks
Jouni K. Seppänen <jk...@ik...> writes: >>> FAIL: matplotlib.tests.test_text.test_font_styles.test >>> FAIL: matplotlib.tests.test_text.test_font_styles.test >>> >> How much was the difference? > > Large: in all three result images, the condensed and light fonts look > the same as normal, and there are differences in kerning. It's arguably > a problem in the test that the pdf case did not fail as well, since it > had the same erroneous output. > > I wonder if this is a Freetype version issue... No, it's just that I don't happen to have the DejaVuSans fonts installed. The font selection falls back on the Bitstream Vera font delivered with matplotlib, but from the comparison pdf file we can find the fonts that were used to produce that pdf file, and presumably the other files: DejaVuSansCondensed BitstreamVeraSans-Bold BitstreamVeraSans-BoldOblique DejaVuSans-ExtraLight BitstreamVeraSans-Roman The light and condensed fonts are DejaVuSans, which happened to be installed on the system on which that test was created. I think the test should only rely on the fonts delivered with matplotlib. -- Jouni K. Seppänen http://www.iki.fi/jks
Jouni K. Seppänen <jk...@ik...> writes: > The light and condensed fonts are DejaVuSans, which happened to be > installed on the system on which that test was created. I think the test > should only rely on the fonts delivered with matplotlib. I created a github issue: https://github.com/matplotlib/matplotlib/issues/488 I'm not quite sure if this should be considered release critical: it does cause a test to break on some systems, but this reflects a problem in the test, not in the functionality being tested. -- Jouni K. Seppänen http://www.iki.fi/jks
Jouni K. Seppänen <jk...@ik...> writes: > Jouni K. Seppänen <jk...@ik...> writes: > >> The light and condensed fonts are DejaVuSans, which happened to be >> installed on the system on which that test was created. I think the test >> should only rely on the fonts delivered with matplotlib. > > I created a github issue: > > https://github.com/matplotlib/matplotlib/issues/488 > > I'm not quite sure if this should be considered release critical: it > does cause a test to break on some systems, but this reflects a problem > in the test, not in the functionality being tested. I marked it release_critical nonetheless, since I think we can expect downstream packagers and users to want the tests to pass. -- Jouni K. Seppänen http://www.iki.fi/jks
On 09/24/2011 03:33 PM, Jouni K. Seppänen wrote: > Jouni K. Seppänen<jk...@ik...> writes: > >> Jouni K. Seppänen<jk...@ik...> writes: >> >>> The light and condensed fonts are DejaVuSans, which happened to be >>> installed on the system on which that test was created. I think the test >>> should only rely on the fonts delivered with matplotlib. >> I created a github issue: >> >> https://github.com/matplotlib/matplotlib/issues/488 >> >> I'm not quite sure if this should be considered release critical: it >> does cause a test to break on some systems, but this reflects a problem >> in the test, not in the functionality being tested. > I marked it release_critical nonetheless, since I think we can expect > downstream packagers and users to want the tests to pass. > I just issued a pull request with a possible fix: https://github.com/matplotlib/matplotlib/pull/495 Mike
Jouni K. Seppänen <jk...@ik...> writes: >>> FAIL: no_testCreateLocaltime (test_tzinfo.LocalTestCase) >>> >> Any info provided on this failure? > > AssertionError: '2004-10-31 02:00:00 AMT+0020' != '2004-10-31 02:00:00 CET+0100' That test has a comment "It would be nice if this worked, but it doesn't." and I guess its name begins with "no_test" to avoid being run as a test, but "nosetests" when run in the matplotlib root directory picks it up nevertheless. That module is not listed in matplotlib.default_test_modules, so I guess this failure doesn't occur when tests are run via matplotlib.test(). So that particular failure was a false alarm. -- Jouni K. Seppänen http://www.iki.fi/jks
Benjamin Root <ben...@ou...> writes: >> FAIL: matplotlib.tests.test_mlab.test_recarray_csv_roundtrip > > I am seeing this one on my 64-bit machine, but not on my 32-bit machine > (both Linux). Fix in https://github.com/matplotlib/matplotlib/pull/490 The uninitialized memory being written to disk sometimes contained NaN values, and the test failed since NaN != NaN. -- Jouni K. Seppänen http://www.iki.fi/jks
On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> wrote: > Working through the checklist, I am wary of cutting an RC at this particular > moment. Why is just about a quarter of all the tests coming back as known > fails? Also, running unit/memleak_hawaii3.py is showing what seems to be a > memory leak (GTKAgg, Python 2.7, Ubuntu, 32-bit) on my system. The step ups > are about 40-50 KB at about once every 10 seconds. Hey Ben, You haven't announced or posted an rc tarball for testing yet have you? Would you like me to do this? Are we holding on anything before putting out something for general testing?
On Tue, Sep 27, 2011 at 18:23, John Hunter <jd...@gm...> wrote: > On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> wrote: > >> Working through the checklist, I am wary of cutting an RC at this particular >> moment. It was announced here: http://sourceforge.net/mailarchive/message.php?msg_id=28136691 I'm testing the debian package and I'll follow up with my thoughts on it when done. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Tue, Sep 27, 2011 at 11:30 AM, Sandro Tosi <mo...@de...> wrote: > On Tue, Sep 27, 2011 at 18:23, John Hunter <jd...@gm...> wrote: >> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> wrote: >> >>> Working through the checklist, I am wary of cutting an RC at this particular >>> moment. > > It was announced here: > > http://sourceforge.net/mailarchive/message.php?msg_id=28136691 > > I'm testing the debian package and I'll follow up with my thoughts on > it when done. Thanks, missed that. Christoph and Russell, will you have a chance to build some binaries we can upload for testing? Once this is done, we should announce to the user list.
On 9/27/2011 9:32 AM, John Hunter wrote: > On Tue, Sep 27, 2011 at 11:30 AM, Sandro Tosi<mo...@de...> wrote: >> On Tue, Sep 27, 2011 at 18:23, John Hunter<jd...@gm...> wrote: >>> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root<ben...@ou...> wrote: >>> >>>> Working through the checklist, I am wary of cutting an RC at this particular >>>> moment. >> >> It was announced here: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=28136691 >> >> I'm testing the debian package and I'll follow up with my thoughts on >> it when done. > > Thanks, missed that. Christoph and Russell, will you have a chance to > build some binaries we can upload for testing? Once this is done, we > should announce to the user list. > > matplotlib-1.1.0.win installers are at <http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. They were built against numpy 1.6.1. Christoph
On Tue, Sep 27, 2011 at 11:41 AM, Christoph Gohlke <cg...@uc...> wrote: > matplotlib-1.1.0.win installers are at > <http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. They were built > against numpy 1.6.1. Ahh, yes, I would have seen that if I had read Sandro's link to the end. Must read more carefully. Thanks.
On Tue, Sep 27, 2011 at 18:30, Sandro Tosi <mo...@de...> wrote: > On Tue, Sep 27, 2011 at 18:23, John Hunter <jd...@gm...> wrote: >> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> wrote: >> >>> Working through the checklist, I am wary of cutting an RC at this particular >>> moment. > > It was announced here: > > http://sourceforge.net/mailarchive/message.php?msg_id=28136691 > > I'm testing the debian package and I'll follow up with my thoughts on > it when done. Ok, so here they are: - what's the difference between examples/ and lib/mpl_examples/ dirs? diff says they are identical, but maybe there's a reason there are 2 copies of them. If not, maybe you can remove one, so to reduce confusion :) - the tarball has grown a lot in size, ~3 times, but in the changelog there's no mention of the reason of this growth (baseline images for testing) - the doc generation stops at thumbnails regen, it seems 'thumbnails' dict is empty and so it stucks there. If you want me to do any tests, just ask me. Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi
On Tue, Sep 27, 2011 at 12:20 PM, Sandro Tosi <mo...@de...> wrote: > On Tue, Sep 27, 2011 at 18:30, Sandro Tosi <mo...@de...> wrote: > > On Tue, Sep 27, 2011 at 18:23, John Hunter <jd...@gm...> wrote: > >> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> > wrote: > >> > >>> Working through the checklist, I am wary of cutting an RC at this > particular > >>> moment. > > > > It was announced here: > > > > http://sourceforge.net/mailarchive/message.php?msg_id=28136691 > > > > I'm testing the debian package and I'll follow up with my thoughts on > > it when done. > > Ok, so here they are: > > - what's the difference between examples/ and lib/mpl_examples/ dirs? > diff says they are identical, but maybe there's a reason there are 2 > copies of them. If not, maybe you can remove one, so to reduce > confusion :) > lib/mpl_examples/ is a symbolic link to examples. It is there because of issues with sphinx doc generation. > - the tarball has grown a lot in size, ~3 times, but in the changelog > there's no mention of the reason of this growth (baseline images for > testing) > Hmm, I tried my best to clean up the source tree after testing, but maybe I missed something? > - the doc generation stops at thumbnails regen, it seems 'thumbnails' > dict is empty and so it stucks there. > > And maybe I got rid of something I shouldn't have? Ben Root
I just uploaded a Mac binary for 32-bit Python 2.7. I propose to leave it at that unless the 2.6 version is required for the release candidate. -- Russell On Sep 27, 2011, at 9:32 AM, John Hunter wrote: > On Tue, Sep 27, 2011 at 11:30 AM, Sandro Tosi <mo...@de...> wrote: >> On Tue, Sep 27, 2011 at 18:23, John Hunter <jd...@gm...> wrote: >>> On Sat, Sep 24, 2011 at 12:37 AM, Benjamin Root <ben...@ou...> wrote: >>> >>>> Working through the checklist, I am wary of cutting an RC at this particular >>>> moment. >> >> It was announced here: >> >> http://sourceforge.net/mailarchive/message.php?msg_id=28136691 >> >> I'm testing the debian package and I'll follow up with my thoughts on >> it when done. > > Thanks, missed that. Christoph and Russell, will you have a chance to > build some binaries we can upload for testing? Once this is done, we > should announce to the user list.
On Tue, Sep 27, 2011 at 3:23 PM, Russell Owen <ro...@uw...> wrote: > I just uploaded a Mac binary for 32-bit Python 2.7. I propose to leave it at that unless the 2.6 version is required for the release candidate. Great. Ben, did you have any luck getting the 1.1.0 docs hosted in some temp location?
On Tue, Sep 27, 2011 at 3:58 PM, John Hunter <jd...@gm...> wrote: > On Tue, Sep 27, 2011 at 3:23 PM, Russell Owen <ro...@uw...> wrote: > > I just uploaded a Mac binary for 32-bit Python 2.7. I propose to leave it > at that unless the 2.6 version is required for the release candidate. > > Great. > > Ben, did you have any luck getting the 1.1.0 docs hosted in some temp > location? > No, I couldn't figure out how to do that on sourceforge. Ben Root
On Tue, Sep 27, 2011 at 4:00 PM, Benjamin Root <ben...@ou...> wrote: > No, I couldn't figure out how to do that on sourceforge. OK, I'm working on this and will send out the ANN when it is done. Thanks everyone for their help, and Ben especially for herding the cats and pushing us forward. JDH