matplotlib-devel Mailing List for matplotlib

On Fri, Nov 09, 2007 at 01:39:10PM -0600, John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
> > I've committed my changes on the transforms branch so you can play with
> > it -- I'm holding off on changing the trunk due to the pending release.
> > But if everyone agrees on the way to expose this, it would be nice to
> > merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
It is important for us that the entire cell have the same colour.
Is this what you get with shading='flat'? 
Sometimes shading='faceted' is useful. You should be able to do this
faster by simply blasting an array of lines over top of shading='flat'
than by drawing each individual quadrilateral.
Note that I found 'faceted' to be much nicer when the lines are drawn
with transparency. Without transparency, a large array turns the
entire image black --- not very useful.
 - Paul

Mike,
Thank you for once again blasting out such an array of improvements.
Regarding implementation and API details, such as what should go in 
imshow versus pcolor versus something with another name, I would like to 
review the situation (and your branch) and come up with a 
recommendation, but I can't do it immediately. I can have something 
waiting for you on Monday morning, however.
(But very briefly, an initial thought: an image is a very special 
"thing", and I am reluctant to overload imshow. We may do best to have 
separate methods for each distinctly separate case. That can keep both 
API and implementation simpler than trying to cram too many variations 
into a single method or function.)
(Arg! This brings up the *big* question of what should be a class, and 
how much functionality, and what kind, should be stuffed into axes methods.)
Eric
Michael Droettboom wrote:
> John Hunter wrote:
>> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
>>
>>> I've committed my changes on the transforms branch so you can play with
>>> it -- I'm holding off on changing the trunk due to the pending release.
>>> But if everyone agrees on the way to expose this, it would be nice to
>>> merge this over to trunk before the release.
>>
>> Am I right in assuming that the only thing we lose in this approach is
>> faceting (which Eric hates but others may care about)? Since it is
>> orders of magnitudes faster, we could have a pcolor_faceted which
>> pcolor calls the old function if shading='faceted'. Of course the two
>> functions would return different types (image vs patch collection)
>> which is potentially a bit confusing.... We could play with adding
>> faceting to images....
> 
> pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses 
> pcolor), where the edges of the quadrilaterals are not necessarily 
> parallel to the x or y axes. The NonUniformImage stuff requires that 
> the quadrilaterals are axis-aligned rectangles. To put it another way, 
> the X and Y arrays (that define the mesh) can be 2-dimensional for 
> pcolor, but only 1-dimensional for (the new) imshow.
> 
> pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, 
> but uses optimized quadmesh drawing under the hood, rather than a 
> PolyCollection. (Though the comments hint at subtle differences related 
> to masking.)
> 
> But you are right -- NonUniformImage does not support outlining each 
> quadrilateral -- though that may not be hard to add if needed.
> 
> The difference in return types is perhaps an argument for 
> NonUniformImages going in imshow, not pcolor. (I was thinking only of 
> ease of implementation...)
> 
> Cheers,
> Mike
> 

John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it would be nice to
>> merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
John, I agree that others may want faceting, but I have not yet heard 
from anyone who does. When I proposed making "flat" the default I got 
only positive comments, and there have been no complaints about the change.
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
Not worth the trouble; retaining an old-style pcolor with faceting that 
can be turned on is good enough support for the faceted use case--if 
anyone is even using it.
Eric

John Hunter wrote:
> On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> 
>> I've committed my changes on the transforms branch so you can play with
>> it -- I'm holding off on changing the trunk due to the pending release.
>> But if everyone agrees on the way to expose this, it would be nice to
>> merge this over to trunk before the release.
> 
> Am I right in assuming that the only thing we lose in this approach is
> faceting (which Eric hates but others may care about)? Since it is
> orders of magnitudes faster, we could have a pcolor_faceted which
> pcolor calls the old function if shading='faceted'. Of course the two
> functions would return different types (image vs patch collection)
> which is potentially a bit confusing.... We could play with adding
> faceting to images....
pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses 
pcolor), where the edges of the quadrilaterals are not necessarily 
parallel to the x or y axes. The NonUniformImage stuff requires that 
the quadrilaterals are axis-aligned rectangles. To put it another way, 
the X and Y arrays (that define the mesh) can be 2-dimensional for 
pcolor, but only 1-dimensional for (the new) imshow.
pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, 
but uses optimized quadmesh drawing under the hood, rather than a 
PolyCollection. (Though the comments hint at subtle differences related 
to masking.)
But you are right -- NonUniformImage does not support outlining each 
quadrilateral -- though that may not be hard to add if needed.
The difference in return types is perhaps an argument for 
NonUniformImages going in imshow, not pcolor. (I was thinking only of 
ease of implementation...)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 9, 2007 1:12 PM, Michael Droettboom <md...@st...> wrote:
> I've committed my changes on the transforms branch so you can play with
> it -- I'm holding off on changing the trunk due to the pending release.
> But if everyone agrees on the way to expose this, it would be nice to
> merge this over to trunk before the release.
Am I right in assuming that the only thing we lose in this approach is
faceting (which Eric hates but others may care about)? Since it is
orders of magnitudes faster, we could have a pcolor_faceted which
pcolor calls the old function if shading='faceted'. Of course the two
functions would return different types (image vs patch collection)
which is potentially a bit confusing.... We could play with adding
faceting to images....
JDH

[To summarize an off-list conversation -- Eric and I had been discussing 
ways to speed up pcolor plots. After some improvements, quadmeshes are 
still about a factor of 2 slower on the branch than on the trunk. His 
use case often involves the simpler problem of rectilinear meshes, which 
can be handled by NonUniformImage, which should be much faster in all 
cases.]
Eric Firing wrote:
> you might want 
> to look at the long-neglected but promising pcolor method in the 
> _image.cpp, used by the NonUniformImage class in image.py.
There is an example on using NonUniformImage in pcolor_nonuniform.py 
that seems to work -- so this code isn't too neglected ;)
> I suspect that the axes pcolor method should actually be using this if 
> the grid is rectilinear and using quadmesh otherwise.
Implementation wise (just to get something working), it was easier to 
extend imshow to take two 1D-arrays X and Y which define a non-uniform 
grid for the image. (My changes merely give NonUniformImage a pyplot 
API, so the user doesn't have to do as much work as in the example.) 
But if we think this functionality belongs with pcolor, it can be 
exposed that way instead. However, there should be some way to let 
pcolor know that the mesh is rectilinear. (It would otherwise be 
wasteful computation just to determine that and proceed accordingly).
As expected, there are significant performance benefits:
Branch:
	nonuniformimage:
		init: 0.27
		fps: 21.37
	pcolormesh:
		init: 0.42
		fps: 2.61
Trunk:
	nonuniformimage:
		init: 0.25
		fps: 22.52	
	pcolormesh:
		init: 0.28
		fps: 6.64
I've committed my changes on the transforms branch so you can play with 
it -- I'm holding off on changing the trunk due to the pending release. 
But if everyone agrees on the way to expose this, it would be nice to 
merge this over to trunk before the release.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom wrote:
> Christopher Barker wrote:
>> Michael Droettboom wrote:
>>> Wx supports polycurves in its new wxGraphicsContext API (but not the 
>>> wxDC API that mpl uses now). This means a fairly complete rewrite of 
>>> the wx backend,
>> not necessarily. You can create a GraphicsContext from a wx.DC, you may 
>> be able to just add that step for drawing polycurves.
>>
>>> since you 
>>> can no longer draw to an in-memory buffer, but only a true wxClientDC). 
>> you can create a GraphicsContext from a wxMemeoryDC, so yes, you can 
>> draw to a buffer.
> 
> I'm having trouble just getting a wxPython to compile with 
> wxGraphicsContext support (perhaps another argument against using it...)
> 
> I was basing this determination on the wx documentation which clearly 
> states one can only create a wxGraphicsContext from a wxWindowDC. 
> wxMemoryDC inherits from wxDC, not wxWindowDC. I'd be certainly happy to 
> find out that the documentation is incorrect on this point, as it would 
> certainly make the implementation easier.
I did finally get this to work -- thanks for the tip that you can use a 
wxGraphicsContext on a wxMemoryDC.
>> I haev no idea what the impact on performance would be, but in general, 
>> GraphicsContext is slower than DC.
> 
> Particularly, if it works as it appears to by rendering to a Cairo 
> buffer first.
It's really bad, actually. It's entirely possible that I'm doing things 
suboptimally, of course. If someone with more wx.GraphicsContext 
experience were to look at backend_wx.py on the branch, I'd appreciate it.
I particularly wonder if drawing directly to a wx.Window would perform 
better over the network than to a wx.MemoryDC and then blitting that to 
the window (as both trunk and branch do now). Clipping rectangles have 
a major impact also. I did optimize the code so that the clipping state 
changes as infrequently as possible (rather than with each drawing 
operation), but it still has a huge impact. I suspect that 
wx.GraphicsContext treats all clips as clipping paths, rather than the 
more efficient clipping rectangles when it can.
These benchmarks are on the branch on a RHEL4 box.
Local:
WxAgg: 27.5 fps
Wx: 1.8 fps
Wx:	16.8 fps (without clipping)
Network (X11 with compression):
WxAgg:	 2.0 fps
Wx:	 1.7 fps
Wx:	 2.0 fps (without clipping)
Windows and Mac may perform quite differently, given that they use 
completely different rendering code.
Unless some "trick" can be found to make this better, it's hard to 
recommend Wx over WxAgg on the branch.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

OK, the fix in the latest SVN does seem to work.
Andrew
On 9 Nov 2007, at 13:24, Michael Droettboom wrote:
> There is a (probable) fix for this in SVN r4179. I can't get to a 
> Mac to test right now -- can you please confirm that fixes your 
> problem? You may need to remove ~/.matplotlibrc/fontManager.cache 
> (just once) in case the earlier bug has messed up the cache.
>
> Andrew Jaffe wrote:
>> Andrew Jaffe wrote:
>>> Hi-
>>>
>>> I've got two Intel OSX machines running matplotlib.
>>>
>>> I recently upgraded one of them to the latest MPL svn. On one 
>>> machine, I had some pytz-related problems which I resolved, and I 
>>> was able to use it more or less fine. However, when the very 
>>> first time I started it, there was a huge pause which I 
>>> eventually realized had something to do with the font cache, but 
>>> it seems OK since then (but perhaps there should be a warning 
>>> message when the cache is being built?)
>
> Perhaps you have a lot of fonts on your system. I see your point 
> about the warning message, but sometimes when the user is presented 
> with too much information, they just train themselves to ignore all 
> of it...
>
>>> On the other machine, however, I got the traceback below, which I 
>>> eventually traced to the call OSXInstalledFonts() in 
>>> findSystemFonts(). Unfortunately, OSXInstalledFonts() is really
>>> OSXInstalledFonts(directory=None, fontext=None)
>>> which then calls
>>> fontext = get_fontext_synonyms(fontext)
>>> which fails with fontext=None.
>>>
>>> I was actually able to fix this by copying the .matplottlib 
>>> directory
>>> from the working machine, but it's still clearly a bug!
>> Actually, sorry, this *doesn't* fix the problem on machine number 
>> 2 (it just lets ipython -pylab start without crashing, but 
>> actually calling, e.g., plot(x,y) still fails for the same reason).
>>> Yours,
>>>
>>> Andrew
>>>
>>>
>>>
>>> Traceback (most recent call last):
>>> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
>>> load_entry_point('ipython==0.8.1', 'console_scripts', 
>>> 'ipython')()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipapi.py", line 356, in 
>>> launch_new_instance
>>> ses = make_session(user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipapi.py", line 405, in make_session
>>> return IPython.Shell.start(user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 1111, in start
>>> return shell(user_ns = user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 1008, in __init__
>>> shell_class=MatplotlibShell)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 74, in __init__
>>> debug=debug,shell_class=shell_class)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", line 95, in 
>>> make_IPython
>>> embedded=embedded,**kw)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 562, in __init__
>>> user_ns,b2 = self._matplotlib_config(name,user_ns)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> ipython-0.8.1-py2.5.egg/IPython/Shell.py", line 503, in 
>>> _matplotlib_config
>>> import matplotlib.pylab as pylab
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> pylab.py", line 208, in <module>
>>> from matplotlib import mpl # pulls in most modules
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> mpl.py", line 3, in <module>
>>> from matplotlib import axis
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> axis.py", line 20, in <module>
>>> from font_manager import FontProperties
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 1129, in <module>
>>> _rebuild()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 1120, in _rebuild
>>> fontManager = FontManager()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 884, in __init__
>>> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 254, in findSystemFonts
>>> for f in OSXInstalledFonts():
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 180, in OSXInstalledFonts
>>> fontext = get_fontext_synonyms(fontext)
>>> File "/Users/jaffe/Library/Python/2.5/site-packages/ 
>>> matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/ 
>>> font_manager.py", line 100, in get_fontext_synonyms
>>> 'afm': ('afm',)}[fontext]
>>> KeyError: None
>>> gog:~% mv .matplotlib tmp.matplotlib; scp
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -----
>>> 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/
>> --------------------------------------------------------------------- 
>> ----
>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
______________________________________________________________________
Andrew Jaffe a....@im...
Astrophysics Group +44 207 594-7526
Blackett Laboratory, Room 1013 FAX 7541
Imperial College, Prince Consort Road
London SW7 2AZ ENGLAND http://astro.imperial.ac.uk/~jaffe

There is a (probable) fix for this in SVN r4179. I can't get to a Mac 
to test right now -- can you please confirm that fixes your problem? 
You may need to remove ~/.matplotlibrc/fontManager.cache (just once) in 
case the earlier bug has messed up the cache.
Andrew Jaffe wrote:
> Andrew Jaffe wrote:
>> Hi-
>>
>> I've got two Intel OSX machines running matplotlib.
>>
>> I recently upgraded one of them to the latest MPL svn. On one machine, 
>> I had some pytz-related problems which I resolved, and I was able to use 
>> it more or less fine. However, when the very first time I started it, 
>> there was a huge pause which I eventually realized had something to do 
>> with the font cache, but it seems OK since then (but perhaps there 
>> should be a warning message when the cache is being built?)
Perhaps you have a lot of fonts on your system. I see your point about 
the warning message, but sometimes when the user is presented with too 
much information, they just train themselves to ignore all of it...
>> On the other machine, however, I got the traceback below, which I 
>> eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
>> Unfortunately, OSXInstalledFonts() is really
>> OSXInstalledFonts(directory=None, fontext=None)
>> which then calls
>> fontext = get_fontext_synonyms(fontext)
>> which fails with fontext=None.
>>
>> I was actually able to fix this by copying the .matplottlib directory
>> from the working machine, but it's still clearly a bug!
> 
> Actually, sorry, this *doesn't* fix the problem on machine number 2 (it 
> just lets ipython -pylab start without crashing, but actually calling, 
> e.g., plot(x,y) still fails for the same reason).
> 
> 
>> Yours,
>>
>> Andrew
>>
>>
>>
>> Traceback (most recent call last):
>> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
>> load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
>> line 356, in launch_new_instance
>> ses = make_session(user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
>> line 405, in make_session
>> return IPython.Shell.start(user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 1111, in start
>> return shell(user_ns = user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 1008, in __init__
>> shell_class=MatplotlibShell)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 74, in __init__
>> debug=debug,shell_class=shell_class)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
>> line 95, in make_IPython
>> embedded=embedded,**kw)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 562, in __init__
>> user_ns,b2 = self._matplotlib_config(name,user_ns)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
>> line 503, in _matplotlib_config
>> import matplotlib.pylab as pylab
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
>> line 208, in <module>
>> from matplotlib import mpl # pulls in most modules
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
>> line 3, in <module>
>> from matplotlib import axis
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
>> line 20, in <module>
>> from font_manager import FontProperties
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 1129, in <module>
>> _rebuild()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 1120, in _rebuild
>> fontManager = FontManager()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 884, in __init__
>> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 254, in findSystemFonts
>> for f in OSXInstalledFonts():
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 180, in OSXInstalledFonts
>> fontext = get_fontext_synonyms(fontext)
>> File 
>> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
>> line 100, in get_fontext_synonyms
>> 'afm': ('afm',)}[fontext]
>> KeyError: None
>> gog:~% mv .matplotlib tmp.matplotlib; scp
>>
>>
>> -------------------------------------------------------------------------
>> 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/
> 
> 
> 
> 
> -------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think that's something I recently introduced, and should probably be simple to fix. I'll have a look when I get into the office this morning.
Cheers,
Mike

Andrew Jaffe wrote:
> Hi-
> 
> I've got two Intel OSX machines running matplotlib.
> 
> I recently upgraded one of them to the latest MPL svn. On one machine, 
> I had some pytz-related problems which I resolved, and I was able to use 
> it more or less fine. However, when the very first time I started it, 
> there was a huge pause which I eventually realized had something to do 
> with the font cache, but it seems OK since then (but perhaps there 
> should be a warning message when the cache is being built?)
> 
> On the other machine, however, I got the traceback below, which I 
> eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
> Unfortunately, OSXInstalledFonts() is really
> OSXInstalledFonts(directory=None, fontext=None)
> which then calls
> fontext = get_fontext_synonyms(fontext)
> which fails with fontext=None.
> 
> I was actually able to fix this by copying the .matplottlib directory
> from the working machine, but it's still clearly a bug!
Actually, sorry, this *doesn't* fix the problem on machine number 2 (it 
just lets ipython -pylab start without crashing, but actually calling, 
e.g., plot(x,y) still fails for the same reason).
> 
> Yours,
> 
> Andrew
> 
> 
> 
> Traceback (most recent call last):
> File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
> load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
> line 356, in launch_new_instance
> ses = make_session(user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
> line 405, in make_session
> return IPython.Shell.start(user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 1111, in start
> return shell(user_ns = user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 1008, in __init__
> shell_class=MatplotlibShell)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 74, in __init__
> debug=debug,shell_class=shell_class)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
> line 95, in make_IPython
> embedded=embedded,**kw)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 562, in __init__
> user_ns,b2 = self._matplotlib_config(name,user_ns)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
> line 503, in _matplotlib_config
> import matplotlib.pylab as pylab
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
> line 208, in <module>
> from matplotlib import mpl # pulls in most modules
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
> line 3, in <module>
> from matplotlib import axis
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
> line 20, in <module>
> from font_manager import FontProperties
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 1129, in <module>
> _rebuild()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 1120, in _rebuild
> fontManager = FontManager()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 884, in __init__
> self.ttffiles = findSystemFonts(paths) + findSystemFonts()
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 254, in findSystemFonts
> for f in OSXInstalledFonts():
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 180, in OSXInstalledFonts
> fontext = get_fontext_synonyms(fontext)
> File 
> "/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
> line 100, in get_fontext_synonyms
> 'afm': ('afm',)}[fontext]
> KeyError: None
> gog:~% mv .matplotlib tmp.matplotlib; scp
> 
> 
> -------------------------------------------------------------------------
> 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/

Hi-
I've got two Intel OSX machines running matplotlib.
I recently upgraded one of them to the latest MPL svn. On one machine, 
I had some pytz-related problems which I resolved, and I was able to use 
it more or less fine. However, when the very first time I started it, 
there was a huge pause which I eventually realized had something to do 
with the font cache, but it seems OK since then (but perhaps there 
should be a warning message when the cache is being built?)
On the other machine, however, I got the traceback below, which I 
eventually traced to the call OSXInstalledFonts() in findSystemFonts(). 
Unfortunately, OSXInstalledFonts() is really
 OSXInstalledFonts(directory=None, fontext=None)
which then calls
 fontext = get_fontext_synonyms(fontext)
which fails with fontext=None.
I was actually able to fix this by copying the .matplottlib directory
from the working machine, but it's still clearly a bug!
Yours,
Andrew
Traceback (most recent call last):
 File "/Users/jaffe/home/local/bin/ipython", line 8, in <module>
 load_entry_point('ipython==0.8.1', 'console_scripts', 'ipython')()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
line 356, in launch_new_instance
 ses = make_session(user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipapi.py", 
line 405, in make_session
 return IPython.Shell.start(user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 1111, in start
 return shell(user_ns = user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 1008, in __init__
 shell_class=MatplotlibShell)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 74, in __init__
 debug=debug,shell_class=shell_class)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/ipmaker.py", 
line 95, in make_IPython
 embedded=embedded,**kw)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 562, in __init__
 user_ns,b2 = self._matplotlib_config(name,user_ns)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/ipython-0.8.1-py2.5.egg/IPython/Shell.py", 
line 503, in _matplotlib_config
 import matplotlib.pylab as pylab
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/pylab.py", 
line 208, in <module>
 from matplotlib import mpl # pulls in most modules
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/mpl.py", 
line 3, in <module>
 from matplotlib import axis
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/axis.py", 
line 20, in <module>
 from font_manager import FontProperties
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 1129, in <module>
 _rebuild()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 1120, in _rebuild
 fontManager = FontManager()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 884, in __init__
 self.ttffiles = findSystemFonts(paths) + findSystemFonts()
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 254, in findSystemFonts
 for f in OSXInstalledFonts():
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 180, in OSXInstalledFonts
 fontext = get_fontext_synonyms(fontext)
 File 
"/Users/jaffe/Library/Python/2.5/site-packages/matplotlib-0.90.1_r4176-py2.5-macosx-10.3-fat.egg/matplotlib/font_manager.py", 
line 100, in get_fontext_synonyms
 'afm': ('afm',)}[fontext]
KeyError: None
gog:~% mv .matplotlib tmp.matplotlib; scp