matplotlib 1.0.1rc available for testing, building

Development matplotlib-devel
#1

In article
<AANLkTikmYCvkxLmQWTo9JCJnAoUp3sPXSKgKPOUua-eW@...150...>,

We are long overdue on getting a bugfix release of 1.0.0 out, so I have
uploaded an rc for testing at

https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/

Christoph and Russell -- if you have time could you build win32 and OSX
binaries for testing as well. I don't believe either of you have developer
permissions to upload directly to this site, but I would be happy to add you
if you send me an sf id. Alternatively, you can upload them to a site of
your choosing and I'll upload them for you (drop.io was acquired by facebook
and no longer works).

I have uploaded Mac installers for python.org Python 2.6 and 32-bit
Python 2.7.

I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In my opinion a matplotlib built against
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
might be of more use. Opinions?

-- Russell

···

John Hunter <jdh2358@...149...> wrote:

#2

I have uploaded Mac installers for python.org Python 2.6 and 32-bit
Python 2.7.

I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In my opinion a matplotlib built against
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
might be of more use. Opinions?

I'm afraid that would just complicate the situation. What numpy would it work with?

Eric

···

On 01/03/2011 02:49 PM, Russell E. Owen wrote:

-- Russell

#3

I cannot provide much input on those Python installations, but I've built rc1
against the fink installations of python/numpy for Intel and PPC 10.5 as well
as Intel 10.6. I could not reproduce the missing .matplotlib/.fontconfig-related
crashes with this build.

With the 64-bit installation on 10.6 I encountered a problem discussed a few months
ago on the list, due to the MacOS module being removed from standard 64-bit Python
builds (and being generally deprecated for Python 3); this had been resolved by
Michiel de Hoon in r8624 (and some parts in r8710, it seems), but those changes did
not make it into rc1. I have attached the patch in the form working for me.

HTH,
            Derek

matplotlib-py.patch (3.01 KB)

···

On 04.01.2011, at 1:49AM, Russell E. Owen wrote:

I have uploaded Mac installers for python.org Python 2.6 and 32-bit
Python 2.7.

I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In my opinion a matplotlib built against
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
might be of more use. Opinions?

#4

Michiel, can you review this and if it looks good contribute it to the 1.0.1 branch?

http://matplotlib.sourceforge.net/devel/coding_guide.html#version-control

Thanks,
JDH

···

On Tue, Jan 4, 2011 at 9:15 AM, Derek Homeier <derek@…909…> wrote:

With the 64-bit installation on 10.6 I encountered a problem discussed a few months

ago on the list, due to the MacOS module being removed from standard 64-bit Python

builds (and being generally deprecated for Python 3); this had been resolved by

Michiel de Hoon in r8624 (and some parts in r8710, it seems), but those changes did

not make it into rc1. I have attached the patch in the form working for me.

#5

Done.
Thanks,
–Michiel.

···

— On Tue, 1/4/11, John Hunter <jdh2358@…149…> wrote:

Michiel, can you review this and if it looks good contribute it to the 1.0.1 branch?

http://matplotlib.sourceforge.net/devel/coding_guide.html#version-control

Thanks,
JDH

#6

OK, I’m not aware of any outstanding issues that should hold this release. If there are any, please let me know, else I’ll upload the final later today.

···

On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjldehoon@…42…> wrote:

Done.

Thanks,
–Michiel.

#7

Hi John.

···

On Wed, Jan 5, 2011 at 14:36, John Hunter <jdh2358@...149...> wrote:

OK, I'm not aware of any outstanding issues that should hold this release.
If there are any, please let me know, else I'll upload the final later
today.

Could you please give your opinion on the documentation &
example.download issue on the other thread?

Thanks & cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

#8

Thanks for the reminder. I commented in the other thread.

JDH

···

On Wed, Jan 5, 2011 at 7:40 AM, Sandro Tosi <morph@…12…> wrote:

Could you please give your opinion on the documentation &

example.download issue on the other thread?

#9

Not sure if this should hold the release but 1.0.1rc fails to run two examples (contourf_log.py and pcolor_log.py) as described in bug #3143748 "Math domain error in ticker.py is_decade()" <http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720>

Christoph

···

On 1/5/2011 5:36 AM, John Hunter wrote:

OK, I'm not aware of any outstanding issues that should hold this
release. If there are any, please let me know, else I'll upload the
final later today.

On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjldehoon@…42… > <mailto:mjldehoon@…42…>> wrote:

    Done.

    Thanks,
    --Michiel.

#10

The fix that was applied to the development branch should have also been applied to the maintenance branch as well, but it appears that it wasn’t. The fix given in r8873 is correct, though. Adding the np.abs() fixes the domain error. Taking the lx calculation out would mess things up for those who are using various offsets for their plots.

Although, looking at the code closer, I have to wonder if it is still correct because of the “nearest_long()” function. Doesn’t python already have established rounding functions that should be used for these things?

Anyway, I don’t know why the tickers for the colorbars are wrong… the contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py code uses norm=LogNorm(). These are two different approaches, and the tick labels are still wrong. Does anybody else have any insight on this?

Ben Root

···

On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cgohlke@…910…> wrote:

Not sure if this should hold the release but 1.0.1rc fails to run two

examples (contourf_log.py and pcolor_log.py) as described in bug

#3143748 “Math domain error in ticker.py is_decade()”

<http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720>

Christoph

On 1/5/2011 5:36 AM, John Hunter wrote:

OK, I’m not aware of any outstanding issues that should hold this

release. If there are any, please let me know, else I’ll upload the

final later today.

On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjldehoon@…42… > > mailto:mjldehoon@...42...> wrote:

Done.

Thanks,

--Michiel.
#11

Interesting… if I use format=ticker.LogFormatter(labelOnlyBase=False) in the call to colorbar, it works as expected. Even more interesting, if I use format=ticker.LogFormatterMathtext() or format=ticker.LogFormatterExponent(), it also works as expected (even though labelOnlyBase=True for those two…).

btw, I would be nice if LogFormatterMathtext() was used instead of LogFormatter() for the default for colorbar. It appears that this is the case for regular plots, so I don’t know why the same doesn’t happen for colorbars (but that’s for another day…).

Ben Root

···

On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben.root@…854…> wrote:

On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cgohlke@…244…> wrote:

Not sure if this should hold the release but 1.0.1rc fails to run two

examples (contourf_log.py and pcolor_log.py) as described in bug

#3143748 “Math domain error in ticker.py is_decade()”

<http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720>

Christoph

On 1/5/2011 5:36 AM, John Hunter wrote:

OK, I’m not aware of any outstanding issues that should hold this

release. If there are any, please let me know, else I’ll upload the

final later today.

On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjldehoon@…42… > > > mailto:mjldehoon@...42...> wrote:

Done.

Thanks,

--Michiel.

The fix that was applied to the development branch should have also been applied to the maintenance branch as well, but it appears that it wasn’t. The fix given in r8873 is correct, though. Adding the np.abs() fixes the domain error. Taking the lx calculation out would mess things up for those who are using various offsets for their plots.

Although, looking at the code closer, I have to wonder if it is still correct because of the “nearest_long()” function. Doesn’t python already have established rounding functions that should be used for these things?

Anyway, I don’t know why the tickers for the colorbars are wrong… the contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py code uses norm=LogNorm(). These are two different approaches, and the tick labels are still wrong. Does anybody else have any insight on this?

Ben Root

#12

It appears that in the call for LogFormatter(), it calls is_decade(), while LogFormatterExponent() and LogFormatterMathtext() are using is_close_to_int() instead of is_decade(). Should LogFormatter() be changed to use is_close_to_int() or was the use of is_close_to_int() a temporary workaround with some issue in is_decade()?

Ben Root

···

On Wed, Jan 5, 2011 at 11:11 AM, Benjamin Root <ben.root@…553…> wrote:

On Wed, Jan 5, 2011 at 10:33 AM, Benjamin Root <ben.root@…553…> wrote:

On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cgohlke@…244…> wrote:

Not sure if this should hold the release but 1.0.1rc fails to run two

examples (contourf_log.py and pcolor_log.py) as described in bug

#3143748 “Math domain error in ticker.py is_decade()”

<http://sourceforge.net/tracker/?func=detail&aid=3143748&group_id=80706&atid=560720>

Christoph

On 1/5/2011 5:36 AM, John Hunter wrote:

OK, I’m not aware of any outstanding issues that should hold this

release. If there are any, please let me know, else I’ll upload the

final later today.

On Wed, Jan 5, 2011 at 7:33 AM, Michiel de Hoon <mjldehoon@…42… > > > > mailto:mjldehoon@...42...> wrote:

Done.

Thanks,

--Michiel.

The fix that was applied to the development branch should have also been applied to the maintenance branch as well, but it appears that it wasn’t. The fix given in r8873 is correct, though. Adding the np.abs() fixes the domain error. Taking the lx calculation out would mess things up for those who are using various offsets for their plots.

Although, looking at the code closer, I have to wonder if it is still correct because of the “nearest_long()” function. Doesn’t python already have established rounding functions that should be used for these things?

Anyway, I don’t know why the tickers for the colorbars are wrong… the contourf_log.py code uses locator=ticker.LogLocator() and the pcolor_log.py code uses norm=LogNorm(). These are two different approaches, and the tick labels are still wrong. Does anybody else have any insight on this?

Ben Root

Interesting… if I use format=ticker.LogFormatter(labelOnlyBase=False) in the call to colorbar, it works as expected. Even more interesting, if I use format=ticker.LogFormatterMathtext() or format=ticker.LogFormatterExponent(), it also works as expected (even though labelOnlyBase=True for those two…).

btw, I would be nice if LogFormatterMathtext() was used instead of LogFormatter() for the default for colorbar. It appears that this is the case for regular plots, so I don’t know why the same doesn’t happen for colorbars (but that’s for another day…).

Ben Root

#13

2011/1/4 Russell E. Owen <rowen@...748...>:

I'm not sure what to do about 64-bit Python 2.7. It does not even
support Mac OS X 10.5 due to tcl/tk issues that I think were resolved
too late for python 2.7.1. In my opinion a matplotlib built against
ActiveState's Python 2.7 (which is 64-bit and supports 10.5 and 10.6)
might be of more use. Opinions?

Here's the state of the art for numpy:
http://article.gmane.org/gmane.comp.python.numeric.general/41799.

So from my point of view mpl Mac OS X py2.7 32+64bit should be built
on Mac OS X 10.6 and should not support < 10.6.

Friedrich