Experimental, traited config module available in svn

Development matplotlib-devel
1

I just committed changes in svn that will allow matplotlib to use the
experimental traited mplconfig module. The traited config object itself is
called mplConfig, but I wrapped it in an object called rcParams to make it
compatible with matplotlib, so we can kick the tires without extensive
changes.

Some notes:

- All of the code associated with reading config files and creating config
objects has been organized into an experimental config package, and is
therefore disabled by default. To enable the config package, set "NEWCONFIG =
True" in matplotlib.__init__.py.

- Once enabled, the config package supports either the old matplotlibrc files
(used by the rcparams module) or the newer matplotlib.conf files (used by the
traited mplconfig module). The config package defaults to the traited
mplconfig option. The config package will use the old matplotlibrc system if
you set "USE_TRAITED_CONFIG = False" in matplotlib/config/__init__.py

-The traited config module will create a new matplotlib.conf file from a
standard matplotlibrc file when appropriate.

-Fernando's tconfig module will not work with the version of traits ships with
matplotlib (we can update our version when Enthought makes their release).
This will get you a more recent version:

sudo easy_install -f
http://code.enthought.com/enstaller/eggs/source/unstable "enthought.traits <
3.0a"

I ran backend_driver with the traited config enabled, and the only errors I
got were related to broken mathtext support in backend_svg, and I think those
are unrelated to my changes. If you have the luxury, please update from svn
and try working with the traited config module enabled. Any feedback would be
appreciated.

Darren

2

Darren Dale wrote:

I ran backend_driver with the traited config enabled, and the only errors I got were related to broken mathtext support in backend_svg, and I think those are unrelated to my changes.
  

I think I broke that for a few hours this morning, but it's working for me now. Next time you update, please let me know if it still isn't working for you.

Cheers,
Mike

3

Darren,

When I make a clean build and install, set NEWCONFIG, and try to run I get a permission problem. It looks like the problem is that the global matplotlib.conf is not getting generated and installed at build/install time, but I have not investigated it.

Eric

convert!
Traceback (most recent call last):
   File "backend_driver.py", line 20, in <module>
     import matplotlib.backends as mplbe
   File "/usr/local/lib/python2.5/site-packages/matplotlib/__init__.py", line 712, in <module>
     from config import rcParams, rcdefaults
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/__init__.py", line 10, in <module>
     from mplconfig import rcParams, mplConfig, save_config, rcdefaults
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/mplconfig.py", line 473, in <module>
     filePriority=True)
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/tconfig.py", line 549, in __init__
     rconf = RecursiveConfigObj(configFilename)
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/tconfig.py", line 311, in __init__
     self.conf = self._load(filename)
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/tconfig.py", line 314, in _load
     conf = mkConfigObj(filename,makeMissingFile)
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/tconfig.py", line 289, in mkConfigObj
     unrepr=True)
   File "/usr/local/lib/python2.5/site-packages/matplotlib/config/configobj.py", line 1189, in __init__
     h = open(infile, 'w')
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.5/site-packages/matplotlib/mpl-data/matplotlib.conf'

4

That was exactly the problem, I forgot to add the new file to the setup
script. It is fixed in svn 3640.

Darren

···

On Monday 30 July 2007 4:49:24 pm Eric Firing wrote:

Darren,

When I make a clean build and install, set NEWCONFIG, and try to run I
get a permission problem. It looks like the problem is that the global
matplotlib.conf is not getting generated and installed at build/install
time, but I have not investigated it.

5

Darren,

It looks like there is a problem with the grid lines. Although the matplotlib.conf file is specifying linestyle = ':', and False for the axes.grid parameter, everything is coming up with solid lines (see barh_demo.py, for example) by default. It looks like those two keys are not setting their respective rcParams entries.

Eric

6

Darren Dale wrote:

I just committed changes in svn that will allow matplotlib to use the experimental traited mplconfig module. The traited config object itself is called mplConfig, but I wrapped it in an object called rcParams to make it compatible with matplotlib, so we can kick the tires without extensive changes.

Darren,

There is *major* speed problem. Running "backend_driver.py Template":

0.95 minutes with NEWCONFIG = True
0.51 minutes False

Eric

7

It looks like creating the mplConfig object is adding to the startup time.
I'll look into it when I get a chance.

Darren

···

On Monday 30 July 2007 7:10:01 pm Eric Firing wrote:

Darren Dale wrote:
> I just committed changes in svn that will allow matplotlib to use the
> experimental traited mplconfig module. The traited config object itself
> is called mplConfig, but I wrapped it in an object called rcParams to
> make it compatible with matplotlib, so we can kick the tires without
> extensive changes.

Darren,

There is *major* speed problem. Running "backend_driver.py Template":

0.95 minutes with NEWCONFIG = True
0.51 minutes False

8

barh_demo turns the grid on. I accidentally set the default linestyle to '-'
in mplconfig for the grids, thats been fixed.

···

On Monday 30 July 2007 6:58:17 pm Eric Firing wrote:

Darren,

It looks like there is a problem with the grid lines. Although the
matplotlib.conf file is specifying linestyle = ':', and False for the
axes.grid parameter, everything is coming up with solid lines (see
barh_demo.py, for example) by default. It looks like those two keys are
not setting their respective rcParams entries.

9

Darren Dale wrote:

Darren,

It looks like there is a problem with the grid lines. Although the
matplotlib.conf file is specifying linestyle = ':', and False for the
axes.grid parameter, everything is coming up with solid lines (see
barh_demo.py, for example) by default. It looks like those two keys are
not setting their respective rcParams entries.

barh_demo turns the grid on. I accidentally set the default linestyle to '-' in mplconfig for the grids, thats been fixed.

Darren,

barh_demo turns the grid on for the first plot only, but the grid is shown for both. ipython -pylab also plots with a grid by default, and shows
In [3]:rcParams['axes.grid']
Out[3]:True

I have not made any matplotlib.conf other than the one that is now being installed correctly in mpl-data, and it contains

     # display grid on regular or polar axes
     grid = False
     polargrid = True

grep indicates the True value is coming from mplconfig:

config/mplconfig.py: grid = T.Trait(True, mplT.BoolHandler())

config/rcsetup.py: 'axes.grid' : [False, validate_bool]

so it looks like somehow this mplconfig initialization is overriding the value in matplotlib.conf.

Eric

···

On Monday 30 July 2007 6:58:17 pm Eric Firing wrote:

10

Hi Eric,

I have not made any matplotlib.conf other than the one that is now being
installed correctly in mpl-data, and it contains

     # display grid on regular or polar axes
     grid = False
     polargrid = True

grep indicates the True value is coming from mplconfig:

config/mplconfig.py: grid = T.Trait(True, mplT.BoolHandler())

config/rcsetup.py: 'axes.grid' : [False, validate_bool]

so it looks like somehow this mplconfig initialization is overriding the
value in matplotlib.conf.

Ok, sorry for the confusion. There were two problems:

-The .conf file in mpl-data was not being read. It is fixed in svn 3645.

-The .conf file is not auto-generated by setup.py. This is a more difficult
problem, so I am not going to work on it unless we decide to adopt the new
module. In the mean time, the file can be auto-generated by running
mplconfig.

Darren

···

On Monday 30 July 2007 10:14:22 pm Eric Firing wrote:

11

I used the following script in the matplotlib/config directory to profile the
mplconfig module:
def main():
    import mplconfig

if __name__=='__main__':
    import profile
    import pstats
    profile.run('main()', 'config.prof')
    
    p = pstats.Stats('config.prof')
    p.sort_stats('cumulative').print_stats(55)

I am attaching the results for two different tests. One is loading the default
mpl-data/matplotlib.conf, the other is loading an empty
~/.matplotlib/matplotlib.conf. I haven't done much work with profiling, maybe
others can make some comments about the results.

defaultconf.txt (5.65 KB)

emptyconf.txt (5.66 KB)

···

On Monday 30 July 2007 07:10:01 pm Eric Firing wrote:

Darren Dale wrote:
> I just committed changes in svn that will allow matplotlib to use the
> experimental traited mplconfig module. The traited config object itself
> is called mplConfig, but I wrapped it in an object called rcParams to
> make it compatible with matplotlib, so we can kick the tires without
> extensive changes.

Darren,

There is *major* speed problem. Running "backend_driver.py Template":

0.95 minutes with NEWCONFIG = True
0.51 minutes False

12

> Darren Dale wrote:
> > I just committed changes in svn that will allow matplotlib to use the
> > experimental traited mplconfig module. The traited config object itself
> > is called mplConfig, but I wrapped it in an object called rcParams to
> > make it compatible with matplotlib, so we can kick the tires without
> > extensive changes.
>
> Darren,
>
> There is *major* speed problem. Running "backend_driver.py Template":
>
> 0.95 minutes with NEWCONFIG = True
> 0.51 minutes False

I used the following script in the matplotlib/config directory to profile
the mplconfig module:
def main():
    import mplconfig

if __name__=='__main__':
    import profile
    import pstats
    profile.run('main()', 'config.prof')

    p = pstats.Stats('config.prof')
    p.sort_stats('cumulative').print_stats(55)

sorry, that should say 'time' instead of 'cumulative'

···

On Tuesday 31 July 2007 11:08:42 am Darren Dale wrote:

On Monday 30 July 2007 07:10:01 pm Eric Firing wrote:

I am attaching the results for two different tests. One is loading the
default mpl-data/matplotlib.conf, the other is loading an empty
~/.matplotlib/matplotlib.conf. I haven't done much work with profiling,
maybe others can make some comments about the results.

13

I'm afraid I can't help with this right now, but you may want to look at

http://amath.colorado.edu/faculty/fperez/python/profiling/

the little code I put in there makes using kcachegrind very easy for
python profiling, and it's really a useful tool for analyzing
profiling info.

Cheers,

f

···

On 7/31/07, Darren Dale <dd55@...143...> wrote:

I am attaching the results for two different tests. One is loading the default
mpl-data/matplotlib.conf, the other is loading an empty
~/.matplotlib/matplotlib.conf. I haven't done much work with profiling, maybe
others can make some comments about the results.

14

Darren,

The two cases you ran have almost identical timing, so the problem is not in reading matplotlib.conf. Instead, it seems to be in the initialization of all the machinery, and I suspect that something may be getting run many times in a loop instead of just once. I used the profile.py script method to profile the whole simple_plot.py demo modified to use Agg, with NEWCONFIG True versus False. Attached are the top 100 lines of the output, sorted by cumulative time, with "new" meaning NEWCONFIG=True. The execution time of the new version is 3.2 seconds versus 1.8 for the old. (Both are pretty slow for making a minimal plot from a script.)

Looking at the profile outputs, a couple of things stand out in the new version. First, various Traits things are prominent near the top. Second, look at the lines for posixpath functions, which are taking quite a bit of time. Here are two examples:

      5651 0.108 0.000 0.188 0.000 posixpath.py:56(join)
[...]
       273 0.012 0.000 0.164 0.001 posixpath.py:410(realpath)

If I understand correctly, path.join is being called 5651 times! And realpath is being called 273 times! Now, these calls are contributing only a little to the total time difference between the mpl versions, but they may be providing clues as to what is wrong. My guess is that there is a glitch in the program logic that is causing some operations that should be done once or a few times to be done hundreds or thousands of times, and this will turn out to be the biggest factor in the slowdown. If so, then we will still have to see whether a significant slowdown remains after the glitch is corrected.

I don't have a lot of experience with profiling, but it seems to me that ordering results by cumulative time is good for finding the major operations that are slow, whereas ordering by time is good for finding the lowest-level functions that are holding things up. Ordering by time shows these as the top two for the new system:

32581/31616 0.152 0.000 0.168 0.000 :0(len)
        98 0.132 0.001 0.372 0.004 has_traits.py:558(__init__)

This doesn't mean that the len builtin is too slow, but that it is getting called a lot of times, and we have to look elsewhere to figure out how to reduce that, if possible. The second line, however, suggests to me that even after the glitch problem is solved, we will be stuck with a distressing startup overhead from using traits. This line is saying that we are initializing 98 trait instances, and this initialization alone is taking 0.37 seconds, of which 0.13 seconds is in the init code, not in functions that it is calling. If you look at the code for that __init__, you will see that it is huge. It may be that the traits overhead is small once a program is up and running, but it certainly looks to me like the startup overhead is a killer if more than a few traits are to be used.

I would not like to see mpl become a library that is painfully sluggish to start up; it is already too slow for my liking, with font setup being a major contributor.

Eric

Darren Dale wrote:

simple_new.100 (6.76 KB)

simple_old.100 (6.55 KB)

···

On Monday 30 July 2007 07:10:01 pm Eric Firing wrote:

Darren Dale wrote:

I just committed changes in svn that will allow matplotlib to use the
experimental traited mplconfig module. The traited config object itself
is called mplConfig, but I wrapped it in an object called rcParams to
make it compatible with matplotlib, so we can kick the tires without
extensive changes.

Darren,

There is *major* speed problem. Running "backend_driver.py Template":

0.95 minutes with NEWCONFIG = True
0.51 minutes False

I used the following script in the matplotlib/config directory to profile the mplconfig module:
def main():
    import mplconfig

if __name__=='__main__':
    import profile
    import pstats
    profile.run('main()', 'config.prof')
        p = pstats.Stats('config.prof')
    p.sort_stats('cumulative').print_stats(55)

I am attaching the results for two different tests. One is loading the default mpl-data/matplotlib.conf, the other is loading an empty ~/.matplotlib/matplotlib.conf. I haven't done much work with profiling, maybe others can make some comments about the results.

15

Eric Firing wrote:

I don't have a lot of experience with profiling...

Slightly OT, but I do have a recommendation for anyone doing Python profiling. I don't usually get very excited about GUI tools, but KCachegrind (Linux only) is very slick and works great with Python. It's really handy to be able to "browse" the calltree interactively to explore what's going on.

The trick (which is very non-obvious from the documentation), is that you use Python's 'hotspot' profiler, then convert that to 'calltree' format using hotspot2calltree (included with KCachegrind), and then load that with KCachegrind.

Just my two cents for something you may want to try,
Mike

16

Yup. The link I posted earlier is basically a little wrapper that
does all that. I wrote it so you wouldn't have to think :slight_smile:

I keep it in my path and can profile any python script with
kcachegrind just by running one command. And yes, kcachegrind rocks.
I'm also very much a non-gui person, yet I've found it invaluable for
doing really complex profiling of very large python codes.

Cheers,

f

···

On 7/31/07, Michael Droettboom <mdroe@...31...> wrote:

Eric Firing wrote:
> I don't have a lot of experience with profiling...
Slightly OT, but I do have a recommendation for anyone doing Python
profiling. I don't usually get very excited about GUI tools, but
KCachegrind (Linux only) is very slick and works great with Python.
It's really handy to be able to "browse" the calltree interactively to
explore what's going on.

The trick (which is very non-obvious from the documentation), is that
you use Python's 'hotspot' profiler, then convert that to 'calltree'
format using hotspot2calltree (included with KCachegrind), and then load
that with KCachegrind.

Just my two cents for something you may want to try,

17

Looking at the profile outputs, a couple of things stand out in the new
version. First, various Traits things are prominent near the top.

pycachegrind is telling me that traits_db is responsible for about 20%,
configobj is responsible for about 30%, and the config package another 30%.

Second, look at the lines for posixpath functions, which are taking
quite a bit of time. Here are two examples:

  5651    0\.108    0\.000    0\.188    0\.000 posixpath\.py:56\(join\)

[...]
273 0.012 0.000 0.164 0.001 posixpath.py:410(realpath)

If I understand correctly, path.join is being called 5651 times! And
realpath is being called 273 times!

I think the posix_path stuff is being called most often by python while it
attempts to locate modules.

[...]

I would not like to see mpl become a library that is painfully sluggish
to start up; it is already too slow for my liking, with font setup being
a major contributor.

I agree.

Darren

···

On Tuesday 31 July 2007 02:12:06 pm you wrote:

18

Fernando,

Here is some more information about profiling that others may find useful:

1) The profile module reports times that are much longer than normal; I don't know to what extent the relative times are still correct; my impression is that they do still give a decent idea of where the bottlenecks and resource hogs are.

2) The combination of hotshot and hotshot2calltree (or similar) gets badly confused by duplicate function names such as __init__, so the kcachegrind view can be quite misleading.

3) A solution is to use the cProfile module in Python 2.5 with an appropriate reformatter. The following script runs a python script through cProfile and generates a *.log file that kcachegrind reads:

http://www.gnome.org/~johan/lsprofcalltree.py

So the sequence is simply

python lsprofcalltree.py testscript.py
kcachegrind testscript.py.log &

Here are a couple of relevant Google results:

https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003045.html
http://ddaa.net/blog/python/lsprof-calltree

Eric

Fernando Perez wrote:

···

On 7/31/07, Darren Dale <dd55@...143...> wrote:

I am attaching the results for two different tests. One is loading the default
mpl-data/matplotlib.conf, the other is loading an empty
~/.matplotlib/matplotlib.conf. I haven't done much work with profiling, maybe
others can make some comments about the results.

I'm afraid I can't help with this right now, but you may want to look at

http://amath.colorado.edu/faculty/fperez/python/profiling/

the little code I put in there makes using kcachegrind very easy for
python profiling, and it's really a useful tool for analyzing
profiling info.

Cheers,

f

19

Hi guys,

[ For the Enthought gang, sorry for the cross-post. This is the context:

http://www.mail-archive.com/matplotlib-devel@lists.sourceforge.net/msg01451.html

We're trying to see if it would be reasonable to use Traits for the
matplotlib config description, but there seem to be performance
issues.
]

Darren,

The two cases you ran have almost identical timing, so the problem is
not in reading matplotlib.conf. Instead, it seems to be in the
initialization of all the machinery, and I suspect that something may
be getting run many times in a loop instead of just once. I used the
profile.py script method to profile the whole simple_plot.py demo
modified to use Agg, with NEWCONFIG True versus False. Attached are the
top 100 lines of the output, sorted by cumulative time, with "new"
meaning NEWCONFIG=True. The execution time of the new version is 3.2
seconds versus 1.8 for the old. (Both are pretty slow for making a
minimal plot from a script.)

I'm here at scipy'07 with the Enthought folks and trying to see if we
can understand what the issue with this traits startup cost is. But I
tried (with current SVN) to run a simple

python -c 'import pylab;pylab.plot([1,2,3])'

but I'm gettting:

obj: plain
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 2061, in plot
    b = ishold()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 888, in ishold
    return gca().ishold()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 834, in gca
    ax = gcf().gca(**kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 722, in gca
    return self.add_subplot(111, **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 542, in add_subplot
    a = Subplot(self, *args, **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 5157, in __init__
    self.figW, self.figH], **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 507, in __init__
    self._init_axis()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 545, in _init_axis
    self.xaxis = maxis.XAxis(self)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 512, in __init__
    self.label = self._get_label()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 990, in _get_label
    horizontalalignment='center',
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 178, in __init__
    self.set_markup(markup)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 780, in set_markup
    self._markup = rcParams['text.markup']
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
line 438, in __getitem__
    return getattr(obj, attr)
AttributeError: 'str' object has no attribute 'markup'

where the crash is coming from this (run interactively in ipdb):

/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py
in __getitem__(self, key)
    436 obj, attr = self.tconfig_map[key]
    437 print 'obj:',obj
--> 438 return getattr(obj, attr)
    439
    440 def keys(self):

AttributeError: 'str' object has no attribute 'markup'

In [2]: obj: MPLConfig

In [3]: debug

/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__()

    437 print 'obj:',obj
--> 438 return getattr(obj, attr)
    439

print obj

plain

print attr

markup

print type(obj)

<type 'str'>

It looks like the 'text' object access is one level off, since it's
trying to get 'markup' from 'plain', which is the *value* of
'text.markup' in the traits description.

This is with a just-built SVN.

If any of you could look into this (I can't really hack on it right
now) it would be great, since we can look at the performance issues
with the Enthought team, but we need the code to actually run.

If Eric/Darren want to talk directly, write to me off-list and I can
call you on a phone.

Cheers,

f

···

On 7/31/07, Eric Firing <efiring@...229...> wrote:

20

Fernando,

Thanks for taking the opportunity of checking into this now. I have to pass the buck, though--the bug you ran into looks like the intersection between Mike's extensive mathtext work and Darren's experimental replacement rc system, and apart from the testing you refer to (prior to much of Mike's work) I have not dealt with either of these areas.

Eric

Fernando Perez wrote:

···

Hi guys,

[ For the Enthought gang, sorry for the cross-post. This is the context:

Re: [matplotlib-devel] Experimental, traited config module available in svn

We're trying to see if it would be reasonable to use Traits for the
matplotlib config description, but there seem to be performance
issues.
]

On 7/31/07, Eric Firing <efiring@...229...> wrote:

Darren,

The two cases you ran have almost identical timing, so the problem is
not in reading matplotlib.conf. Instead, it seems to be in the
initialization of all the machinery, and I suspect that something may
be getting run many times in a loop instead of just once. I used the
profile.py script method to profile the whole simple_plot.py demo
modified to use Agg, with NEWCONFIG True versus False. Attached are the
top 100 lines of the output, sorted by cumulative time, with "new"
meaning NEWCONFIG=True. The execution time of the new version is 3.2
seconds versus 1.8 for the old. (Both are pretty slow for making a
minimal plot from a script.)

I'm here at scipy'07 with the Enthought folks and trying to see if we
can understand what the issue with this traits startup cost is. But I
tried (with current SVN) to run a simple

python -c 'import pylab;pylab.plot([1,2,3])'

but I'm gettting:

obj: plain
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 2061, in plot
    b = ishold()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 888, in ishold
    return gca().ishold()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/pylab.py",
line 834, in gca
    ax = gcf().gca(**kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 722, in gca
    return self.add_subplot(111, **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/figure.py",
line 542, in add_subplot
    a = Subplot(self, *args, **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 5157, in __init__
    self.figW, self.figH], **kwargs)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 507, in __init__
    self._init_axis()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axes.py",
line 545, in _init_axis
    self.xaxis = maxis.XAxis(self)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 512, in __init__
    self.label = self._get_label()
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/axis.py",
line 990, in _get_label
    horizontalalignment='center',
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 178, in __init__
    self.set_markup(markup)
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/text.py",
line 780, in set_markup
    self._markup = rcParams['text.markup']
  File "/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py",
line 438, in __getitem__
    return getattr(obj, attr)
AttributeError: 'str' object has no attribute 'markup'

where the crash is coming from this (run interactively in ipdb):

/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py
in __getitem__(self, key)
    436 obj, attr = self.tconfig_map[key]
    437 print 'obj:',obj
--> 438 return getattr(obj, attr)
    439
    440 def keys(self):

AttributeError: 'str' object has no attribute 'markup'

In [2]: obj: MPLConfig

In [3]: debug

/home/fperez/usr/opt/lib/python2.5/site-packages/matplotlib/config/mplconfig.py(438)__getitem__()

    437 print 'obj:',obj
--> 438 return getattr(obj, attr)
    439

> print obj
plain
> print attr
markup
> print type(obj)
<type 'str'>

It looks like the 'text' object access is one level off, since it's
trying to get 'markup' from 'plain', which is the *value* of
'text.markup' in the traits description.

This is with a just-built SVN.

If any of you could look into this (I can't really hack on it right
now) it would be great, since we can look at the performance issues
with the Enthought team, but we need the code to actually run.

If Eric/Darren want to talk directly, write to me off-list and I can
call you on a phone.

Cheers,

f

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options