matplotlib-devel Mailing List for matplotlib

Hi all,
On Thu, Dec 9, 2010 at 23:04, Ben Gamari <bg...@gm...> wrote:
> On 2010年12月09日 16:44:37 -0500, Ben Gamari <bg...@gm...> wrote:
>> rcdefaults()'s implementation appears to implement the latter, updating
>> rcParams from rcParamsDefault in rcsetup.py, which appears to describe
>> the factory default values. Perhaps we should
>> rcParamsDefault.update(rcParams) after loading matplotlibrc?
>>
> As expected, doing the update of rcParamsDefault proposed above (patch
> below) allows the examples.download setting to persist throughout the
> documentation build. It seems like either the documentation build
> process or rcParamsDefault has been badly broken for a very long
> time. Is rcParamsDefault really supposed to be the factory defaults or
> is this just a bug? If the former, we will need to introduce a variant
> of matplotlib.rcdefaults() to reset the configuration to that specified
> in matplotlibrc.
>
> - Ben
>
>
> diff --git a/lib/matplotlib/__init__.py b/lib/matplotlib/__init__.py
> --- a/lib/matplotlib/__init__.py
> +++ b/lib/matplotlib/__init__.py
> @@ -764,13 +772,13 @@ Please do not ask for support with these customizations active.
>
> # this is the instance used by the matplotlib classes
> rcParams = rc_params()
> -
> -rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \
> -          defaultParams.iteritems() ])
> -
> rcParams['ps.usedistiller'] = checkdep_ps_distiller(rcParams['ps.usedistiller'])
> rcParams['text.usetex'] = checkdep_usetex(rcParams['text.usetex'])
>
> +rcParamsDefault = RcParams([ (key, default) for key, (default, converter) in \
> +           defaultParams.iteritems() ])
> +rcParamsDefault.update(rcParams)
> +
> def rc(group, **kwargs):
>   """
>   Set the current rc params. Group is the grouping for the rc, eg.
With this patch we can indeed finally use the sampledata local dir -
thanks Ben for that!! anyhow, it seems to be quite a radical change,
that might have a bit of impact on what the users can experience, so
I'd like to hear from mpl devels what's the feelings about that.
Anyhow, please note that examples.directory RC param, must not
contains apex (') at the beginning/end of the value, else it would
fail; the example in matplotlibrc.template seems to suggests it's
apex-enclosed:
 #examples.directory : '' # directory to look in if download is false
else you would get:
 IOError: [Errno 2] No such file or directory:
"'/home/morph/deb/build-area/matplotlib-1.0.1~rc1/sampledata/'/axes_grid/bivariate_normal.npy"
it should be made it clearer (or make the get_sample_data() smarter) about that.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

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

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 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 01/02/2011 05:03 PM, Paul Ivanov wrote:
> I sent this to the -users list a little over a week ago - now
> resending to -devel list against the latest svn.
Paul,
Thanks, I applied your fix to the maintenance branch, so it should 
appear in the 1.0.1 release that is in the works.
I ran into an unrelated conflict when using svnmerge, so getting it into 
the trunk will wait until this can be sorted out.
Eric
>
>
> best,
>

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

In article <4D0...@no...>,
 Christopher Barker <Chr...@no...> wrote:
> On 12/9/10 11:57 PM, Ludwig Schwardt wrote:
> > This patch reminded me to ask why the builtin libpng, zlib and
> > libfreetype on Mac OS 10.5 and later are not used to build Matplotlib,
> 
> It may be because we still want to support OS-X 10.4 .
Yes -- we are still supporting Mac OS X 10.3.9 and later (the same 
versions supported by python.org python).
It will be a relief to stop building those libraries, but they're easy 
enough to build and some of them are newer than the versions originally 
supplied with Mac OS X (including libz and libfreetype) so it's not 
necessarily a bad thing to include static versions.
Regards,
-- Russell

In article <row...@ne...>,
 "Russell E. Owen" <ro...@uw...> wrote:
> In article 
> <AANLkTimbf_uGbX7y9akz6Ned=m8NJNC+R-tnsk__6c7Y-JsoAwUIsXosN+BqQ9rBEUg@public.g
> mane.org>,
> John Hunter <jd...@gm...> wrote:
> 
> > On Mon, Dec 20, 2010 at 6:31 PM, Russell E. Owen 
> > <ro...@uw...> wrote:
> > 
> > > I built a binary installer for matplotlib trunk rev 8843 (because it
> > > leaks memory less than 1.0.0 release). I built it the same way I built
> > > the 1.0.0 binary
> > > <http://www.astro.washington.edu/users/rowen/BuildingMatplotlibForMac.htm
> > > l> on Mac OS X 10.4 using python.org Python 2.6.x (where x is probably
> > > 6).
> > >
> > > The binary is available here:
> > > <http://www.astro.washington.edu/users/rowen/python/matplotlib-1.0.0+svn8
> > > 843-python.org-py2.6-macosx10.3.dmg<http://www.astro.washington.edu/users/
> > > ro
> > > wen/python/matplotlib-1.0.0+svn8%0A843-python.org-py2.6-macosx10.3.dmg>
> > > >
> > >
> > > It work fine on Mac OS X 10.4 and 10.5, but on 10.6 attempting to import
> > > pylab almost always segfaults (and the few times I've gotten it to work
> > > on 10.6 I can break it by deleting ~/.fontconfig and ~/.matplotlib and
> > > running Python again). I've tried it on newly created accounts and it
> > > segfaults. Another user of Snow Leopard first reported the problem. So
> > > it's not just me.
> > >
> > > I've appended part of a crash log.
> > >
> > > I built this binary the same way I built the matplotlib 1.0.0 binary,
> > > which has no problems.
> > >
> > 
> > 
> > Could you try a "divide and conquer" approach to narrow down which svn
> > revision introduced the breakage. I realize this is tedious, especially
> > since the bug manifestation is variable, but it if we could figure out the
> > revision number, we'd be more likely to be able to fix it.
> 
> Good suggestion. I tried remaking the an installer for 1.0.0 and it has 
> the exact same issue. I am surprised because I only use the machine for 
> one purpose: making binary installers) and I don't recall rebuilding any 
> of the libraries but either I did or there's been some corruption.
> 
> In any case the good news is that it has nothing to do with matplotlib 
> itself and is all my fault. Presumably libfreetype has gotten corrupted 
> or I built a new version and messed something up. I'll pursue it.
I cleared out /usr/local and rebuilt the necessary libraries and it now 
seems to work fine. I uploaded a new copy of the Mac installer for 
Python 2.6 after performing basic testing on 10.4, 10.5 and 10.6. Please 
give it a try. I'll upload a version for 32-bit Python 2.7 once I have 
it.
-- Russell