Thread: [matplotlib-devel] matplotlib 1.0.1rc available for testing, building

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).

There are a number of bugs and patches on the tracker that it would have
been nice to tackle before this release, but there have been enough
improvements in the branch that delaying at this point would be a case of
the perfect being the enemy of the good so I think we should move forward
now.  Nonetheless, if there are important bugs or patches that anyone can
tackle before we cut the final release, that would be great.

In sf, we used to be able to tag a file as the preferred file for a given
OS, but in the new file manager interface I no longer see a way to do this,
so that for example the rc files don't show up as the default download
options.  Does anyone know how to do this, or perhaps someone can suggest a
drop.io replacement that supports multiple user uploaders (eg the different
binary builders) and public, no-registration downloads.  I googled a bit and
didn't find anything that fit the bill.

JDH

Hi John,

On Sun, Jan 2, 2011 at 18:52, John Hunter <jd...@gm...> wrote:
> 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/

Maybe I just missed them, but I can't find in the tarball the data
files needed to run the examples without internet connection. I
thought it was decided to ship them directly in the tarball and so use
the examples.directory rc option to point to them at build-time and
avoid to download, but if they're not in the tarball.... :)

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

On Sun, Jan 2, 2011 at 4:25 PM, Sandro Tosi <mo...@de...> wrote:

>
> >
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1/
>
>
> Maybe I just missed them, but I can't find in the tarball the data
> files needed to run the examples without internet connection. I
> thought it was decided to ship them directly in the tarball and so use
> the examples.directory rc option to point to them at build-time and
> avoid to download, but if they're not in the tarball.... :)
>
>
I just added a sample data release file to the same dir --
mpl_sampledata-1.0.1rc.tar.gz
- different tarball, but should contain everything you need.  Will this meet
Debian's requirements?  We could add it to the main tarball, but part of the
original impetus in moving the data out of the main tree was to make the
main tarball smaller.  I can go either way if it is a major hassle for you
guys to do it differently.

JDH

On Sun, Jan 2, 2011 at 23:50, John Hunter <jd...@gm...> wrote:
> I just added a sample data release file to the same dir --
> mpl_sampledata-1.0.1rc.tar.gz - different tarball, but should contain
> everything you need.  Will this meet Debian's requirements?  We could add it
> to the main tarball, but part of the original impetus in moving the data out
> of the main tree was to make the main tarball smaller.  I can go either way
> if it is a major hassle for you guys to do it differently.

Thanks for the fast reply! There is a quite-new feature that allows
use to use several tarballs to create a single source package (in this
case the source & sample_data tarballs to generate the matplotlib
debian source package): I can try that, and I'll let you know if I
fail or not.

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

On Sun, 2 Jan 2011 23:25:12 +0100, Sandro Tosi <mo...@de...> wrote:
> Maybe I just missed them, but I can't find in the tarball the data
> files needed to run the examples without internet connection. I
> thought it was decided to ship them directly in the tarball and so use
> the examples.directory rc option to point to them at build-time and
> avoid to download, but if they're not in the tarball.... :)
> 
You might consider looking at my Ubuntu PPA[1] if you are going to work on
packaging. I seem to have everything working at this point, so perhaps
that can save you some work.

Cheers,

- Ben

[1] https://launchpad.net/~bgamari/+archive/matplotlib-unofficial

On Mon, Jan 3, 2011 at 00:21, Ben Gamari <bga...@gm...> wrote:
> On Sun, 2 Jan 2011 23:25:12 +0100, Sandro Tosi <mo...@de...> wrote:
>> Maybe I just missed them, but I can't find in the tarball the data
>> files needed to run the examples without internet connection. I
>> thought it was decided to ship them directly in the tarball and so use
>> the examples.directory rc option to point to them at build-time and
>> avoid to download, but if they're not in the tarball.... :)
>>
> You might consider looking at my Ubuntu PPA[1] if you are going to work on
> packaging. I seem to have everything working at this point, so perhaps
> that can save you some work.

I already looked at it, but it still needs some work.

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

On Sun, Jan 2, 2011 at 11:52 AM, John Hunter <jd...@gm...> wrote:

>
>
> In sf, we used to be able to tag a file as the preferred file for a given
> OS, but in the new file manager interface I no longer see a way to do this,
> so that for example the rc files don't show up as the default download
> options.



I found the answer to this -- I don't know why it wasn't working for me
yesterday.  In the file manager interface there is a little black icon with
a circle around "i", presumably for "info") in which you can check a button
indicating that this is the default download for a given platform.  I could
swear I tried this yesterday...

JDH

I just build and uploaded a version for python 2.6. I have tested it  
on Intel 10.4 and plan to test it on 10.5 and 10.6 before trying to  
build a version for 32-bit Python 2.7. I will keep you posted.

Regards,

-- Russell

On Jan 2, 2011, at 9:52 AM, John Hunter wrote:

> 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).
>
> There are a number of bugs and patches on the tracker that it would  
> have been nice to tackle before this release, but there have been  
> enough improvements in the branch that delaying at this point would  
> be a case of the perfect being the enemy of the good so I think we  
> should move forward now.  Nonetheless, if there are important bugs  
> or patches that anyone can tackle before we cut the final release,  
> that would be great.
>
> In sf, we used to be able to tag a file as the preferred file for a  
> given OS, but in the new file manager interface I no longer see a  
> way to do this, so that for example the rc files don't show up as  
> the default download options.  Does anyone know how to do this, or  
> perhaps someone can suggest a drop.io replacement that supports  
> multiple user uploaders (eg the different binary builders) and  
> public, no-registration downloads.  I googled a bit and didn't find  
> anything that fit the bill.
>
> JDH

The news:
- The Mac binary installer for python.org Python 2.6 works on my Mac  
OS X 10.4 and 10.5 machines (both Intel). However, it segfaults on my  
10.6 machine if there is no existing ~/.matplotlib and ~/.fontconfig.  
If others could test this it would be most helpful. I have not yet  
tried it on 10.3.9.

To reiterate: a proper test is:
- delete ~/.matplotlib if it exists
- delete ~/.fontconfig if it exists
- run python and try to import pylab or matplotlib

-- Russell

On Jan 2, 2011, at 9:52 AM, John Hunter wrote:

> 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).
>
> There are a number of bugs and patches on the tracker that it would  
> have been nice to tackle before this release, but there have been  
> enough improvements in the branch that delaying at this point would  
> be a case of the perfect being the enemy of the good so I think we  
> should move forward now.  Nonetheless, if there are important bugs  
> or patches that anyone can tackle before we cut the final release,  
> that would be great.
>
> In sf, we used to be able to tag a file as the preferred file for a  
> given OS, but in the new file manager interface I no longer see a  
> way to do this, so that for example the rc files don't show up as  
> the default download options.  Does anyone know how to do this, or  
> perhaps someone can suggest a drop.io replacement that supports  
> multiple user uploaders (eg the different binary builders) and  
> public, no-registration downloads.  I googled a bit and didn't find  
> anything that fit the bill.
>
> JDH

On Mon, Jan 3, 2011 at 1:57 PM, Russell Owen <ro...@uw...> wrote:

> The news:
> - The Mac binary installer for python.org Python 2.6 works on my Mac OS X
> 10.4 and 10.5 machines (both Intel). However, it segfaults on my 10.6
> machine if there is no existing ~/.matplotlib and ~/.fontconfig. If others
> could test this it would be most helpful. I have not yet tried it on 10.3.9.
>
> To reiterate: a proper test is:
> - delete ~/.matplotlib if it exists
> - delete ~/.fontconfig if it exists
> - run python and try to import pylab or matplotlib
>
> -- Russell
>


If you run an example with --verbose-debug-annoying with a clean cache,
you'll get more information about what font file it is parsing right before
the crash.  Not sure if this will help, but it would be interesting to see.

JDH

matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.  
(dateutil is current at 1.5).

Should I report this as a bug or is this email sufficient?

-- Russell

On Mon, Jan 3, 2011 at 2:00 PM, Russell Owen <ro...@uw...> wrote:

> matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.
> (dateutil is current at 1.5).
>
> Should I report this as a bug or is this email sufficient?
>


email is sufficient.  I'm inclined to fix this for the trunk (targeting a
1.1 release) rather than the branch as we are aiming for maximum stability
in the branch and 1.0.1 bugfix release.  However, if there are known bugs in
the wild vis-a-vid mpl that the old version of pytz is causing us, I am
happy to reconsider.

JDH

On 1/3/2011 12:00 PM, Russell Owen wrote:
> matplotlib 1.0.1rc has pytz 2010h but the current version is 2010o.
> (dateutil is current at 1.5).
>
> Should I report this as a bug or is this email sufficient?
>
> -- Russell
>
>

These packages should be kept up-to-date if possible. There is an old 
bug report that was closed.

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

--
Christoph

On Mon, Jan 3, 2011 at 2:19 PM, Christoph Gohlke <cg...@uc...> wrote:

>
> These packages should be kept up-to-date if possible. There is an old
> bug report that was closed.
>
> <
> http://sourceforge.net/tracker/index.php?func=detail&aid=3009273&group_id=80706&atid=560720
> >
>


Since the version is out of date and may contain bad tz or tzinfo, I'm
willing to consider it a bug and fixed it in the branch.  Seems to be
working fine on my tests.

In article 
<AAN...@ma...>,
 John Hunter <jd...@gm...> wrote:

> 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

2011/1/4 Russell E. Owen <ro...@uw...>:
> 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

On 01/03/2011 02:49 PM, 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?

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

Eric

>
> -- Russell
>

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?

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

On Tue, Jan 4, 2011 at 9:15 AM, Derek Homeier <
de...@as...> 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.
>

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

Done.

Thanks,
--Michiel.

--- On Tue, 1/4/11, John Hunter <jd...@gm...> 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




      

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 <mjl...@ya...> wrote:

> Done.
>
> Thanks,
> --Michiel.
>
>

Hi John.

On Wed, Jan 5, 2011 at 14:36, John Hunter <jd...@gm...> 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

On Wed, Jan 5, 2011 at 7:40 AM, Sandro Tosi <mo...@de...> wrote:

>
>
> Could you please give your opinion on the documentation &
> example.download issue on the other thread?
>
>
Thanks for the reminder.  I commented in the other thread.

JDH

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 <mjl...@ya...
> <mailto:mjl...@ya...>> wrote:
>
>     Done.
>
>     Thanks,
>     --Michiel.
>
>

On Wed, Jan 5, 2011 at 10:08 AM, Christoph Gohlke <cg...@uc...> 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 <mjl...@ya...
> > <mailto:mjl...@ya...>> 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