matplotlib-devel Mailing List for matplotlib

On Saturday, September 24, 2011, Mike Kaufman <mc...@gm...> wrote:
> Possible bug report:
>
> "Exception occurred rendering plot."
>
> http://matplotlib.github.com/examples/api/sankey_demo.html
>
> This is with firefox 6.0.2
>
> M
>
This was discovered and fixed in master a couple of months ago.
 Essentially, any example that did "if __name__ == '__main__'", then they
never got rendered by the doc builder, and no message is emitted to the
builder.
The upcoming release (just cut a RC this morning) has the new sankey module
and several fully working examples.
Cheers!
Ben Root

Possible bug report:
"Exception occurred rendering plot."
http://matplotlib.github.com/examples/api/sankey_demo.html
This is with firefox 6.0.2
M

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

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 9/24/2011 11:41 AM, Benjamin Root wrote:
> The source tarball for the rc can be found here:
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/
>
> binary builders can use this and upload the binaries there. Please let
> me know when the windows and mac binaries are ready so that we can make
> an official call for testing. I also tagged the v1.1.0-rc1 commit on
> github.
>
> Cheers!
> Ben Root
>
>
matplotlib-1.1.0.win installers are at 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>. They were built 
against numpy 1.6.1. I don't have time to test them today.
Christoph

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:
>>> 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

The source tarball for the rc can be found here:
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/
binary builders can use this and upload the binaries there. Please let me
know when the windows and mac binaries are ready so that we can make an
official call for testing. I also tagged the v1.1.0-rc1 commit on github.
Cheers!
Ben Root

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:
>> 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

Ok, the v1.1.0 branch has been created, and I am in the process of doing the
tarballs and such. Please file any pull requests against that branch. I
will also tag v1.1.0-rc1 when I make the official announcement.
Ben Root

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

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

I'm pleased to announce basemap has just been accepted into Debian,
and soon will be available to unstable/testing users! Thanks for your
help in this process!
On Sat, Sep 24, 2011 at 11:17, Debian FTP Masters
<ftp...@ft...> wrote:
>
>
>
> Accepted:
> basemap_1.0.1-1.debian.tar.gz
> to main/b/basemap/basemap_1.0.1-1.debian.tar.gz
> basemap_1.0.1-1.dsc
> to main/b/basemap/basemap_1.0.1-1.dsc
> basemap_1.0.1.orig.tar.gz
> to main/b/basemap/basemap_1.0.1.orig.tar.gz
> python-mpltoolkits.basemap-data_1.0.1-1_all.deb
> to main/b/basemap/python-mpltoolkits.basemap-data_1.0.1-1_all.deb
> python-mpltoolkits.basemap-doc_1.0.1-1_all.deb
> to main/b/basemap/python-mpltoolkits.basemap-doc_1.0.1-1_all.deb
> python-mpltoolkits.basemap_1.0.1-1_amd64.deb
> to main/b/basemap/python-mpltoolkits.basemap_1.0.1-1_amd64.deb
>
>
> Override entries for your package:
> basemap_1.0.1-1.dsc - source python
> python-mpltoolkits.basemap-data_1.0.1-1_all.deb - optional python
> python-mpltoolkits.basemap-doc_1.0.1-1_all.deb - optional doc
> python-mpltoolkits.basemap_1.0.1-1_amd64.deb - optional python
>
> Announcing to deb...@li...
> Closing bugs: 389638
>
>
> Thank you for your contribution to Debian.
>
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Fri, Sep 23, 2011 at 11:54 PM, Benjamin Root <ben...@ou...> wrote:
> I will see about cutting the release, but I won't be able to upload any
> files to SF, unless somebody can give me that permission for my account.
I have made you a project admin on the sf site. That means you have
full permission to do anything (except commit to the svn repo).
However, to enable access to the html directory, you will need to add
your public key to the list of authorized keys (don't have the link
handy at the moment). You might potentially encounter some unix file
permission issues on the server as well, if we don't have the group
bits set up right. You'll just have to experiment with it.
Alternatively, I'm happy to pick up the ball on Monday
JDH

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.

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
There are only two legit known fails, one in test_basic and one in
test_dates and these are the only two I am seeing. You are likely
seeing known fails on the pdf or svg tests because either you don't
have gs or inkscape installed to do the image conversion. Take a look
at ib/matplotlib/testing/compare.py to see the conversion commands
> 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.
I can't test this now because I am leaving for a roadtrip now until
tomorrow night; usually this steps up a bit on initial figures and
then stabilizes after a large number of figures. I don't have a
problem waiting til Monday to sort out a few lingering issues. I also
don't have a problem branching and cutting the rc now because we can
always fix things in the branch, but this increases the workload
because of the additional merge. So why don't we keep hammering on
the few remaining issues and shoot for Monday afternoon?

On Fri, Sep 23, 2011 at 11:54 PM, Benjamin Root <ben...@ou...> wrote:
> On Fri, Sep 23, 2011 at 6:35 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>> On Fri, Sep 23, 2011 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
>>
>>>
>>>
>>> On Friday, September 23, 2011, John Hunter <jd...@gm...> wrote:
>>> > On Fri, Sep 23, 2011 at 4:19 PM, Benjamin Root <ben...@ou...>
>>> wrote:
>>> >
>>> >> I wanted to do some changes to doc/users/installing.rst, but it is
>>> ignored
>>> >> by the .gitignore file. Is this information autogenerated somewhere
>>> else?
>>> >
>>> > This looks like an error in .gitignore. i wrote that file, and can
>>> > assure you it was not auto-generated :-)
>>> >
>>>
>>> Ok, give me an hour to get home, and I should be able to fix them and
>>> finish my polishing work for this release.
>>>
>>> Ben
>>
>>
>> Ok, looks like I was wrong. I was trying to figure out what was going on,
>> and found a commit that stated that the information in
>> doc/users/installing.rst was to be moved over to INSTALL.
>>
>> So, don't merge in my branch yet... I need to lop off a couple of
>> commits...
>>
>> Ben Root
>>
>>
> Ok, I did some reverts, and that should handle most issues. The vast bulk
> of the documentation work has been merged into master. If anybody encounters
> a problem where their rebase fails because it would modify an untracked
> "doc/users/installing.rst", it is ok to skip that commit. This should only
> happen if you happen to have a build of the documentation.
>
> I will see about cutting the release, but I won't be able to upload any
> files to SF, unless somebody can give me that permission for my account.
>
> Thanks,
> Ben Root
>
>
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.
Anybody else seeing these?
Ben Root

On Fri, Sep 23, 2011 at 6:35 PM, Benjamin Root <ben...@ou...> wrote:
>
> On Fri, Sep 23, 2011 at 4:46 PM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>> On Friday, September 23, 2011, John Hunter <jd...@gm...> wrote:
>> > On Fri, Sep 23, 2011 at 4:19 PM, Benjamin Root <ben...@ou...> wrote:
>> >
>> >> I wanted to do some changes to doc/users/installing.rst, but it is
>> ignored
>> >> by the .gitignore file. Is this information autogenerated somewhere
>> else?
>> >
>> > This looks like an error in .gitignore. i wrote that file, and can
>> > assure you it was not auto-generated :-)
>> >
>>
>> Ok, give me an hour to get home, and I should be able to fix them and
>> finish my polishing work for this release.
>>
>> Ben
>
>
> Ok, looks like I was wrong. I was trying to figure out what was going on,
> and found a commit that stated that the information in
> doc/users/installing.rst was to be moved over to INSTALL.
>
> So, don't merge in my branch yet... I need to lop off a couple of
> commits...
>
> Ben Root
>
>
Ok, I did some reverts, and that should handle most issues. The vast bulk
of the documentation work has been merged into master. If anybody encounters
a problem where their rebase fails because it would modify an untracked
"doc/users/installing.rst", it is ok to skip that commit. This should only
happen if you happen to have a build of the documentation.
I will see about cutting the release, but I won't be able to upload any
files to SF, unless somebody can give me that permission for my account.
Thanks,
Ben Root