matplotlib-devel Mailing List for matplotlib

>>>>> "Patrik" == Patrik Simons <pat...@ne...> writes:

    Patrik> Here's a proposed patch for the caching problem in
    Patrik> text.py.  (I'm sending it before someone actually adds
    Patrik> matplotlib.text.Text.cached = {} to, e.g.,
    Patrik> matlab.close(). Oh, the horror :-)

What happened when you put it there?

It's not clear to me where to me where that misplaced zero is coming
from.  Since the two figures are identical in size, I would think the
cached location of '0' from the first iteration of the loop would be
suitable for the second iteration.  Do you understand how this is
failing?

The main reason for the cache was for efficiency in animated plots.
Eg, if you are just updating the data in a plot and then redrawing,
you don't want to do all the number crunching for text layout.  With
rotated text and matrix operations to get the layout right, this can
get expensive.

I read over your patch.  I wonder if a simpler and cleaner solution
might just be to move the cached into the __init__ method.  Ie, make
it instance specific.  This would still provide the cache efficiency
for animated plots, but should fix the problem  you encountered.
It might also be less mind-bending than the solution you posted, at
least at this hour of the morning :-)

But I *would* like to understand how the current situation is
failing.  I note that it does not occur if you replace figure(1) with
figure(i+1).

JDH

Here's a proposed patch for the caching problem in text.py.
(I'm sending it before someone actually adds
matplotlib.text.Text.cached = {}
to, e.g., matlab.close(). Oh, the horror :-)

-- 
Patrik

Hi there,

matplotlib.text.Text._get_layout(self, renderer) caches
its return value in the dictionary matplotlib.text.Text.cached.
Since it is never emptied, it causes problems when one
creates many figures.

Below, t0.png is ok but t1.png has the vertical tick label 0 in the
wrong place.

import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *

y = [[100, 250], [10, 25]]

for i in range(2):
    figure(1)
    bar([0,1], y[i])
    savefig('t%d.png' % i)
    # Uncomment to fix
    #matplotlib.text.Text.cached = {}
    close('all')

-- 
Patrik

John Hunter wrote:

>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>>            
>>>>>>
>
>    Steve> My view is that a software package should not distribute
>    Steve> and install its own dependencies.  I think matplotlib
>    Steve> should have a list of dependencies (Python 2.2+, Numeric or
>    Steve> numarray, ...) which it requires before it attempts an
>    Steve> install, and a list of optional dependencies (pytz,
>    Steve> dateutil, ...) which matplotlib supports if it finds they
>    Steve> are already installed.
>
>What's your argument for this?
>
>My motivation to include them is mainly to simplify the install
>process, to have some control over versioning, and to simplify the
>coding process.  
>
I agree with JDH on this one.  Including extra pure-Python packages is 
not likely to cause (m)any problems:

1) on systems where people do lots of "python setup.py install" the 
definitive list of installed packages is the contents of site-packages
2) on systems with real package managers (e.g. Debian), this is for the 
package maintainer to worry about. those extra packages should be made 
package-level dependencies and not in the matplotlib.deb itself. (this 
assumes people on these systems are using the package manager.  if not, 
see point #1)
3) on Windows, you want to double click something that just works.

(In fact, by this reasoning, there's nothing against including mixed 
C/Python packages, either.)

On Tue, 2004-09-21 at 19:44, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> My view is that a software package should not distribute
>     Steve> and install its own dependencies.  I think matplotlib
>     Steve> should have a list of dependencies (Python 2.2+, Numeric or
>     Steve> numarray, ...) which it requires before it attempts an
>     Steve> install, and a list of optional dependencies (pytz,
>     Steve> dateutil, ...) which matplotlib supports if it finds they
>     Steve> are already installed.
> 
> What's your argument for this?
My argument is that most other software I've looked at does this and it
seems to work OK. I guess the reasons are that
- it makes software packages smaller
- you only need to directly download one copy of a package and do not
indirectly download multiple copies of the same package.
- you can end up with multiple versions of a package. And later you may
try to recall - which package x did I use to install package y?
- the software package that includes other packages needs to make sure
it keeps up to date with with the included packages and does not install
old versions.

> My motivation to include them is mainly to simplify the install
> process, to have some control over versioning, and to simplify the
> coding process.  Since these are pure python packages, they present no
Yes, this is an advantage of including everything, and a disadvantage
for minimal packages.

> Does your opinion change for the win32 installer?  In that case, we
> also include freetype, libpng, zlib.  I guarantee the numbers of win32
> users would drop significantly if they had to install these extra
> packages.  Neither dateutil nor pytz distribute a win32 installer.
> dateutil doesn't include a zip file (only a tar.bz file).  So win32
> users would first have to get bunzip2, and then tar, figure out how to
> use them, install, etc, just to get matplotlib date support.
Win32 could be a special case.

As a way to encourage more users how about working towards moving from
the development status of version 0.62.4 "4 - Beta" to 1.0.0 "5 -
Production/Stable".
What's the criteria for this step?
My understanding is that it does not mean that all desired features are
implemented or complete, it just means that the software is stable, and
matplotlib seems to be pretty stable already.

Regards,
Steve