matplotlib-users Mailing List for matplotlib (Page 7)

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 Rich> Regardless, I added 'export
 Rich> PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' to .bash_profile
 Rich> and sourced that file. Did the same for root's
 Rich> .bash_profile. Now it's building.
You may also want to append /usr/local/pkgconfig/ to that path...
Glad it's working for you.
JDH

On 2007年1月11日, John Hunter wrote:
> In your build environment, see if these directories show up with
>
> > pkg-config --cflags-only-I pygtk-2.0
John,
 Nobody's home.
> That is what mpl uses to find your pygtk headers. If not, set your
> PKG_CONFIG_PATH environment variable accordingly, and make sure there is a
> pygtk-2.0.pc file in that directory. On my system it is in
>
> /usr/lib/pkgconfig/pygtk-2.0.pc
> and yours will probably be /usr/local/lib/pkgconfig
 Yes. That's just where it is.
> It looks like you did a local install of pygtk, but did not update the
> pkg-config path to point to it.
 Since I work on the main server/workstation, 'local' is a relative term.
:-)
 Regardless, I added 'export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/' to
.bash_profile and sourced that file. Did the same for root's .bash_profile.
Now it's building.
Many thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

>>>>> "Rich" == Rich Shepard <rsh...@ap...> writes:
 >> From 'python setup.py build':
 Rich> src/_ns_backend_gdk.c:17:25: pygtk/pygtk.h: No such file or
 Rich> directory
 Rich> However, ...
 Rich> [rshepard@salmo ~]$ locate pygtk.h
 Rich> /usr/local/pygtk-2.8.6/gtk/pygtk.h
 Rich> /usr/local/include/pygtk-2.0/pygtk/pygtk.h
 Rich> Do I need to add /usr/local/include/pygtk-2.0/ somewhere
 Rich> in setup.py?
In your build environment, see if these directories show up with
 > pkg-config --cflags-only-I pygtk-2.0
That is what mpl uses to find your pygtk headers. If not, set your
PKG_CONFIG_PATH environment variable accordingly, and make sure there
is a pygtk-2.0.pc file in that directory. On my system it is in 
 /usr/lib/pkgconfig/pygtk-2.0.pc
and yours will probably be /usr/local/lib/pkgconfig
It looks like you did a local install of pygtk, but did not update the
pkg-config path to point to it.
JDH

>From 'python setup.py build':
src/_ns_backend_gdk.c:17:25: pygtk/pygtk.h: No such file or directory
 However, ...
[rshepard@salmo ~]$ locate pygtk.h
/usr/local/pygtk-2.8.6/gtk/pygtk.h
/usr/local/include/pygtk-2.0/pygtk/pygtk.h
 Do I need to add /usr/local/include/pygtk-2.0/ somewhere in setup.py?
Thanks,
Rich
-- 
Richard B. Shepard, Ph.D. | The Environmental Permitting
Applied Ecosystem Services, Inc. | Accelerator(TM)
<http://www.appl-ecosys.com> Voice: 503-667-4517 Fax: 503-667-8863

John Hunter wrote:
>>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
> 
> Christopher> However, it is the case that there is a lot of stuff
> Christopher> in pylab that makes it easier to use MPL in
> Christopher> interactive mode. I kind of think that's a shame. I
> Christopher> don't think that there is any reason that an OO
> Christopher> interface is less suited to interactive mode.
> 
> It's currently implemented in pylab but could be moved up to the OO
> layer by doing something like
> 
> class Axes:
> def plot(self, *args, **kwargs):
> ...plot something
> if rcParams['interactive']:
> self.figure.canvas.draw()
I think this may be a slippery slope. The problem is that for it to 
work well, there has to be a clear distinction between methods that are 
endpoints, requiring a redraw, and methods that will be used by other 
methods. For example, errorbar makes multiple calls to plot, vline, 
etc. Even in interactive mode, we don't want redraws after each of 
those calls, only after the errorbar call itself. This could be handled 
by including an additional kwarg ("redraw=False"), or by requiring that 
methods like errorbar use only lower-level primitives, but either way, 
complexity increases.
Eric
> 
> or by providing some autowrapper facility to automate this. Probably
> could be done elegantly with decorators, but we can't use decorators
> yet...
> 
> Or OO users can just call fig.canvas.draw() themselves when they want
> to draw....
> 
> JDH
> 

belinda thom wrote:
> Hi,
> 
> On Jan 10, 2007, at 5:56 PM, Robert Kern wrote:
> 
>> belinda thom wrote:
>>> I went back and retried the plotting w/wx
>>> as a backend and discovered that wx FAILS with PYTHONW and PYTHON
>>> (appended).
>> Okay, what version of wxPython did you install? What version of 
>> wxPython is
>> actually imported (check wx.__version__)?
> 
> Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
> [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> history mechanism set up
> >>> import wx
> >>> wx.__version__
> '2.6.3.3'
Okay, let me rephrase: which binary package of wxPython did you install?
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Hi,
On Jan 10, 2007, at 5:56 PM, Robert Kern wrote:
> belinda thom wrote:
>> I went back and retried the plotting w/wx
>> as a backend and discovered that wx FAILS with PYTHONW and PYTHON
>> (appended).
>
> Okay, what version of wxPython did you install? What version of 
> wxPython is
> actually imported (check wx.__version__)?
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
 >>> import wx
 >>> wx.__version__
'2.6.3.3'
> (And we can leave off numpy-discussion, it's not relevant there).
>
> -- 
> Robert Kern
Thanks,
--b

belinda thom wrote:
> I went back and retried the plotting w/wx 
> as a backend and discovered that wx FAILS with PYTHONW and PYTHON 
> (appended).
Okay, what version of wxPython did you install? What version of wxPython is
actually imported (check wx.__version__)?
(And we can leave off numpy-discussion, it's not relevant there).
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Jan 10, 2007, at 4:57 PM, Eric Firing wrote:
> Christopher Barker wrote:
>> Eric Firing wrote:
>>> This is the big difference between most pylab functions and the
>>> corresponding axes or figure methods that they wrap: the pylab
>>> functions automatically take care of redrawing the figure if you are
>>> in an interactive mode.
>>
>> Now I feel bad -- I think I encouraged Belinda to work with the OO
>> interface, because I think it's the better way to go, and, in
>> particular, translates better to putting MPL code in larger programs.
Don't feel bad. The online community is great, and I've appreciated 
all the advise I've gotten.
>> However, it is the case that there is a lot of stuff in pylab that 
>> makes
>> it easier to use MPL in interactive mode. I kind of think that's a
>> shame. I don't think that there is any reason that an OO interface is
>> less suited to interactive mode.
>
> Even without the automatic-redraw difference, the OO interface 
> requires
> more typing, and more mental record-keeping, than the pylab interface.
> Typing "plot(x,y)" is easier to do and remember than creating a 
> figure,
> adding axes, and then typing "ax1.plot(x,y)". For interactive use, I
> really don't see any advantage to an OO interface. What advantage do
> you see?
In my case, the advantage of pylab over OO is its simplicity. If this 
simpler usage wasn't available, it would be much harder to teach 
Matlab-like stuff in introductory programming classes via Python.
At the same time, it is very easy to confuse the difference between 
the Matlab-like stuff, the OO-like stuff, and then there's also numpy.
I vote for better documentation regarding these pieces, their 
interactions and their differences, somewhere easy-to-find online.
--b

Hi Chris, Robert, ...?,
I'm glad you reminded me to make sure the path was right, b/c this 
time, I had forgotten to run the "Update Shell" command that came w/ 
MacPython2.4. This gave me:
lrwxr-xr-x 1 root wheel 67 Jan 7 14:29 /usr/local/bin/pydoc@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/pydoc
lrwxr-xr-x 1 root wheel 70 Jan 7 14:29 /usr/local/bin/pydoc2.4@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/ 
pydoc2.4
lrwxr-xr-x 1 root wheel 68 Jan 7 14:29 /usr/local/bin/python@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/python
lrwxr-xr-x 1 root wheel 71 Jan 7 14:29 /usr/local/bin/python2.4@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/ 
python2.4
lrwxr-xr-x 1 root wheel 69 Jan 7 14:29 /usr/local/bin/pythonw@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/pythonw
lrwxr-xr-x 1 root wheel 72 Jan 7 14:29 /usr/local/bin/pythonw2.4@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/ 
pythonw2.4
lrwxr-xr-x 1 root wheel 70 Jan 7 14:29 /usr/local/bin/smtpd.py@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/ 
smtpd.py
lrwxr-xr-x 1 root wheel 73 Jan 7 14:29 /usr/local/bin/smtpd2.4.py@ - 
 > ../../../Library/Frameworks/Python.framework/Versions/2.4/bin/ 
smtpd2.4.py
Nevertheless, the python I was using in the prior email looks like 
the same as what I'm using w/these path updates, that is, assuming 
version strings are enough to know:
 From prior run:
 Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
 [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
 New run:
 Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
 [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
As you'd suspected, it is indeed the case that:
 diff pythonw python
reports no differences. So, I went back and retried the plotting w/wx 
as a backend and discovered that wx FAILS with PYTHONW and PYTHON 
(appended).
If you saw how many notes I've collected on the different installs 
I've tried you'd laugh (except that its not funny). Its no wonder I 
can't keep all this stuff straight. (When I first embarked on this 
exercise several months ago, I tried macports; everything seemed to 
work fine, but the Wx backend failed---I remember something about a 
bitmap, so it was likely the same error I'm having now; and 
unfortunately w/the macports python, the tk/tcl stuff didn't come 
wrapped, so TkAgg was not an option).
After an email w/Robert, I switched to MacPython. As a result, I now 
have TkAgg working (and its using Aqua instead of that awful, klunky 
looking Tk stuff).
Fortunately (ha!), I have three versions of this stuff installed on 3 
different Macs (a G4, a G5, and an Intel). So I can say with safety 
that, using TkAgg backend, here's what's still not working:
1) Using macpython matplotlib, numpy, and scipy packages, you can't 
run scipy.test(); complaint: RuntimeError: module compiled against 
version 1000002 of C-API but this version of numpy is 1000009
2) Using superpak, everything (except ipython) worked out of the box, 
PROVIDED I had already installed the necessary fortran pieces (I used 
g77v3.4-bin.tar.gz, found somewhere on the scipy site).
3) Using Robert's install-from-source method (this install used 
gfortran.bin.tar.gz, with the caveat that the expected WXAgg doesn't 
work)
Machines 2 and 3 are enough to get me back to the real work I have to 
do. But it is obvious there's several real issues for Mac users who 
wish to use the scipy/numpy/matplotlib route. This coming summer I 
may have more time to devote to this stuff, and since it really irks 
me that there isn't a clean way to do this, I may end up figuring out 
how to make the needed binaries myself. In the meantime, I thought 
I'd never wish I was still using Windows...
Thanks to everyone for the time spent on this. And for posterity's 
sake, when you use matplotlib with Numeric, it also crashes. I've 
verified that behavior on Machines 1 and 2 above.
--b
54 % pythonw
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
 >>> import pylab as P
 >>> import matplotlib as M
 >>> M.rcParams['interactive']
True
 >>> M.rcParams['backend']
'WXAgg'
 >>> P.plot([1,2,3])
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wx.py", line 1048, in _onPaint
self.draw(repaint=False)
<snip>
draw_if_interactive()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wx.py", line 1172, in 
draw_if_interactive
figManager.canvas.draw()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wxagg.py", line 63, in draw
self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
wx.Bitmap
 >>
55 % python
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
 >>> import pylab as P
 >>> import matplotlib as M
 >>> M.rcParams['interactive']
True
 >>> M.rcParams['backend']
'WXAgg'
 >>> P.plot([1,2,3])
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wx.py", line 1048, in _onPaint
self.draw(repaint=False)
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wxagg.py", line 63, in draw
self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
wx.Bitmap
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/pylab.py", line 2022, in plot
<snip>
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wx.py", line 1172, in 
draw_if_interactive
figManager.canvas.draw()
File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ 
site-packages/matplotlib/backends/backend_wxagg.py", line 63, in draw
self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
wx.Bitmap
 >>>
On Jan 10, 2007, at 3:06 PM, Christopher Barker wrote:
>
>
> Robert Kern wrote:
>
>> Try running with pythonw.
>
> That's probably not it -- as of MacPython 2.4, pythonw ands python 
> are the same.
>
> belinda thom wrote:
>> And running w/pythonw does what it should :-).
>
> OK, now I'm confused:
>
> $ ls -l /Library/Frameworks/Python.framework/Versions/2.4/bin/ 
> python2.4
> -rwxrwxr-x 1 root admin 39936 Apr 7 2006 /Library/Frameworks/ 
> Python.framework/Versions/2.4/bin/python2.4
>
> $ ls -l /Library/Frameworks/Python.framework/Versions/2.4/bin/ 
> pythonw2.4
> -rwxrwxr-x 1 root admin 39936 Apr 7 2006 /Library/Frameworks/ 
> Python.framework/Versions/2.4/bin/pythonw2.4
>
> Those two look like the same binaries to me -- and diff tells me 
> they are.
>
> Are you sure you're running the same python with "python" and 
> "pythonw"? Try running them on the command line alone and see what 
> you get.
>
>> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
>> python2.4/site-packages/matplotlib/backends/backend_wxagg.py", 
>> line 63, in draw
>> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), 
>> None)
>> MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create 
>> the wx.Bitmap
>
> This looks like the error we usually get when you've built the 
> wxAgg extension against a different version of wx than the one 
> you're running. That's easy to do, as Apple has provided an old wx 
> with it's Python, it is often found by default by the MPL build 
> process.
>
> Search this list for the way to fix that, or, if you really can't 
> find it, I'll dig it up.
>
> -Chris
>
>
>
>
>
>
>
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...

Christopher Barker wrote:
> Eric Firing wrote:
>> This is the big difference between most pylab functions and the 
>> corresponding axes or figure methods that they wrap: the pylab 
>> functions automatically take care of redrawing the figure if you are 
>> in an interactive mode.
> 
> Now I feel bad -- I think I encouraged Belinda to work with the OO 
> interface, because I think it's the better way to go, and, in 
> particular, translates better to putting MPL code in larger programs.
> 
> However, it is the case that there is a lot of stuff in pylab that makes 
> it easier to use MPL in interactive mode. I kind of think that's a 
> shame. I don't think that there is any reason that an OO interface is 
> less suited to interactive mode.
Even without the automatic-redraw difference, the OO interface requires 
more typing, and more mental record-keeping, than the pylab interface.
Typing "plot(x,y)" is easier to do and remember than creating a figure, 
adding axes, and then typing "ax1.plot(x,y)". For interactive use, I 
really don't see any advantage to an OO interface. What advantage do 
you see?
Eric

John Hunter wrote:
> It's currently implemented in pylab but could be moved up to the OO
> layer by doing something like
> 
> class Axes:
> def plot(self, *args, **kwargs):
> ...plot something
> if rcParams['interactive']:
> self.figure.canvas.draw()
> 
> or by providing some autowrapper facility to automate this.
That could work -- and/or subclass the key classes, and wrap their plot, 
etc. methods. hmmm..
> Or OO users can just call fig.canvas.draw() themselves when they want
> to draw....
Well, yes, but the point I'm making is that it should be just as easy to 
use interactively -- that's a bit too much code to want to type at the 
command line.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Robert Kern wrote:
> Try running with pythonw.
That's probably not it -- as of MacPython 2.4, pythonw ands python are 
the same.
belinda thom wrote:
> And running w/pythonw does what it should :-).
OK, now I'm confused:
$ ls -l /Library/Frameworks/Python.framework/Versions/2.4/bin/python2.4
-rwxrwxr-x 1 root admin 39936 Apr 7 2006 
/Library/Frameworks/Python.framework/Versions/2.4/bin/python2.4
$ ls -l /Library/Frameworks/Python.framework/Versions/2.4/bin/pythonw2.4
-rwxrwxr-x 1 root admin 39936 Apr 7 2006 
/Library/Frameworks/Python.framework/Versions/2.4/bin/pythonw2.4
Those two look like the same binaries to me -- and diff tells me they are.
Are you sure you're running the same python with "python" and "pythonw"? 
Try running them on the command line alone and see what you get.
> File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
> python2.4/site-packages/matplotlib/backends/backend_wxagg.py", line 
> 63, in draw
> self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
> MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
> wx.Bitmap
This looks like the error we usually get when you've built the wxAgg 
extension against a different version of wx than the one you're running. 
That's easy to do, as Apple has provided an old wx with it's Python, it 
is often found by default by the MPL build process.
Search this list for the way to fix that, or, if you really can't find 
it, I'll dig it up.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

>>>>> "Christopher" == Christopher Barker <Chr...@no...> writes:
 Christopher> However, it is the case that there is a lot of stuff
 Christopher> in pylab that makes it easier to use MPL in
 Christopher> interactive mode. I kind of think that's a shame. I
 Christopher> don't think that there is any reason that an OO
 Christopher> interface is less suited to interactive mode.
It's currently implemented in pylab but could be moved up to the OO
layer by doing something like
class Axes:
 def plot(self, *args, **kwargs):
 ...plot something
 if rcParams['interactive']:
 self.figure.canvas.draw()
or by providing some autowrapper facility to automate this. Probably
could be done elegantly with decorators, but we can't use decorators
yet...
Or OO users can just call fig.canvas.draw() themselves when they want
to draw....
JDH

Eric Firing wrote:
> This is the big difference between most pylab functions and the 
> corresponding axes or figure methods that they wrap: the pylab functions 
> automatically take care of redrawing the figure if you are in an 
> interactive mode.
Now I feel bad -- I think I encouraged Belinda to work with the OO 
interface, because I think it's the better way to go, and, in 
particular, translates better to putting MPL code in larger programs.
However, it is the case that there is a lot of stuff in pylab that makes 
it easier to use MPL in interactive mode. I kind of think that's a 
shame. I don't think that there is any reason that an OO interface is 
less suited to interactive mode.
I've thought for a while that I'd love to write a "OOlab" module -- that 
is, an object oriented interface to matplotlib that is well suited to 
interactive use.
However,
1) who know when I'll get around to it, and I haven't yet because I 
hardly ever do much interactively anyway (I didn't with Matlab, either).
2) this is an example of how it's hard to do -- a method like 
Figure.Clear() clearly belongs just where it is in an OO framework. 
Would it be possible for all those OO drawing methods to be able to 
query an "interactive" property somewhere? Does it live only in pylab now?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

belinda thom wrote:
> Robert,
> 
>> Try running with pythonw.
> 
> Do you know how to fix this in IDLE (it must be using python as 
> opposed to pythonw somehow).
I'm afraid that I don't know enough about IDLE to help you.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

John Hunter wrote:
>>>>>> "Robert" == Robert Kern <rob...@gm...> writes:
> 
> Robert> Personally, I think the warnings are a bit overzealous and
> Robert> should be silenced. It's not as if the user is explicitly
> Robert> telling the font manager to load those specific
> Robert> fonts. They are automatically and unavoidably attempted.
> 
> I just modified the font manager to move this reporting into the
> verbose handler, so now they will only show up with verbose "helpful"
> or greater.
And there was much rejoicing!
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Robert,
> Try running with pythonw.
Do you know how to fix this in IDLE (it must be using python as 
opposed to pythonw somehow).
Thanks again for all your help,
--b

Thanks.
And running w/pythonw does what it should :-).
On Jan 10, 2007, at 12:16 PM, John Hunter wrote:
>>>>>> "Robert" == Robert Kern <rob...@gm...> writes:
>
> Robert> Personally, I think the warnings are a bit overzealous and
> Robert> should be silenced. It's not as if the user is explicitly
> Robert> telling the font manager to load those specific
> Robert> fonts. They are automatically and unavoidably attempted.
>
> I just modified the font manager to move this reporting into the
> verbose handler, so now they will only show up with verbose "helpful"
> or greater.
>
> JDH
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to 
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

>>>>> "Robert" == Robert Kern <rob...@gm...> writes:
 Robert> Personally, I think the warnings are a bit overzealous and
 Robert> should be silenced. It's not as if the user is explicitly
 Robert> telling the font manager to load those specific
 Robert> fonts. They are automatically and unavoidably attempted.
I just modified the font manager to move this reporting into the
verbose handler, so now they will only show up with verbose "helpful"
or greater.
JDH

belinda thom wrote:
> I am posting this message to both numpy and matplotlib mailing lists 
> because the thread relates to both.
Actually, it's really only relevant to matplotlib.
> However, after installing wx and matplotlib, various problems result:
> 
> 1) warnings about fonts
> 2) wx fails to work
> 
> I've appended the warnings below. These only occur the first time 
> pylab is imported (does this make sense?).
Yes. After the first time, a cache is built and the font manager doesn't go
trawling through your fonts again. matplotlib's font library cannot parse some
of the Mac fonts (damned resource forks), so it warns you.
Personally, I think the warnings are a bit overzealous and should be silenced.
It's not as if the user is explicitly telling the font manager to load those
specific fonts. They are automatically and unavoidably attempted.
> WX / MATPLOTLIB FAILURE
> --------------------------
> 
> 4 % python
Try running with pythonw.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

I am posting this message to both numpy and matplotlib mailing lists 
because the thread relates to both.
First, Robert Kern kindly provided step-by-step instructions for Macs 
(PPCs and Intels) regarding how to install FROM SOURCE the packages 
needed to allow Python to become a viable alternative for Matlab. 
Details regarding the installation of matplotlib (along with wx, 
which is supposed to allow the WxAgg backend to work), numpy, and 
scipy were provided.
The reason for installing FROM SOURCE on a Mac is because various 
packages need to be compiled in such a way that they rely on the same 
underling shared libraries, etc. for things to work (I've described 
some problems w/installing from numpy, scipy, and matplotlib dmgs at 
http://www.mail-archive.com/ numpy-discussion at scipy.org/ 
msg00481.html).
 From these instructions, I've been able to acheive numpy.test() anad 
scipy.test() that run w/no failures -- hooray!
However, after installing wx and matplotlib, various problems result:
1) warnings about fonts
2) wx fails to work
I've appended the warnings below. These only occur the first time 
pylab is imported (does this make sense?).
After that, I've appended the issues I've had when trying to use wx 
as a backend. One reason I'd like to be able to use wx is that it 
appears with TkAgg, running IDLE (w/the -n flag) can hang (see: 
http://www.mail-archive.com/mat...@li.../ 
msg02039.html).
Point that originally confused me: although wx is needed for the 
WxAgg backend, you don't need to install the analogous Tk package to 
use TkAgg PROVIDED you're using MacPython, for that comes bundled w/ 
an Aqua-based Tk interface.
I'm on a G4 PPC, w/OS X 10.4.8, and using MacPython 2.4. Any idea 
what wx doesn't work?
Thanks,
--b
ONE-TIME WARNINGS:
--------------------
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
 >>> import pylab as P
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- 
packages/matplotlib/font_manager.py:455: UserWarning: Could not open 
font file /Library/Fonts/NISC18030.ttf
 warnings.warn("Could not open font file %s"%fpath)
<snip>
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- 
packages/matplotlib/font_manager.py:455: UserWarning: Could not open 
font file /System/Library/Fonts/TimesLTMM
 warnings.warn("Could not open font file %s"%fpath)
 >>>
WX / MATPLOTLIB FAILURE
--------------------------
4 % python
Python 2.4.4 (#1, Oct 18 2006, 10:34:39)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
history mechanism set up
 >>> import matplotlib as M
 >>> import pylab as P
 >>> M.rcParams['interactive']
True
 >>> M.rcParams['backend']
'WXAgg'
 >>> P.plot([1,2,3])
Traceback (most recent call last):
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/backends/backend_wx.py", line 
1048, in _onPaint
 self.draw(repaint=False)
<snip>
 figManager.canvas.draw()
 File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/backends/backend_wxagg.py", line 
63, in draw
 self.bitmap = _convert_agg_to_wx_bitmap(self.get_renderer(), None)
MemoryError: _wxagg.convert_agg_to_wx_bitmap(): could not create the 
wx.Bitmap
 >>>

>>>>> "belinda" == belinda thom <bt...@cs...> writes:
 belinda> I am not sure, but I think this difference in behavior is
 belinda> b/c IPython is a bit better about calling
 belinda> draw_if_interactive after "most pylab functions" (see
 belinda> Eric Firing's http://www.mail-archive.com/matplotlib-
 belinda> us...@li.../msg02037.html) than IDLE is.
No, this isn't it. pylab does the draw_if_interactive call, and it is
called by pylab.axis:
def axis(*args, **kwargs):
 ax = gca()
 v = ax.axis(*v, **kwargs)
 draw_if_interactive()
 return v
I noticed in your subsequent post that interactive is set to True in
your rc file. Make sure you are not running from the matplotlib
install directory or it will pick up your directory specific
matplotlib rc file.
You might want to do
 >>> from matplotlib import rcParams
 >>> print rcParams['interactive']
from within your IDLE session to verify. Does interactive updating
work with other pylab commands. I would be very surprised if just
'axis' were failing.
JDH

Mark,
> BTW, when you use pylab in interactive mode, the axis() command 
> should scale your figure interactively, also under IDLE. Have you 
> tried that?
Yes, I tried using axis in both IDLE and IPython. IPython's redrew 
the axis automatically whereas IDLE's did not.
I am not sure, but I think this difference in behavior is b/c IPython 
is a bit better about calling draw_if_interactive after "most pylab 
functions" (see Eric Firing's http://www.mail-archive.com/matplotlib- 
us...@li.../msg02037.html) than IDLE is.
> I have experienced the same problem with IDLE.
> It only works with -n, but then you lose the nice feature of 
> 'starting over'.
> Does anybody know a fix so we can do both?
I too would LOVE to have the ability to start over as IDLE w/o the -n 
allows. Unfortunately for me (on a Mac) I've not yet been unable to 
use WxAgg w/matplotlib using Mac-available packages. I might be able 
to use it after I'm done following http://projects.scipy.org/ 
pipermail/numpy-discussion/2007-January/025368.html, but I'm in 
crunch-mode at the moment, so that install is going slowly.
--b

>>>>> "belinda" == belinda thom <bt...@cs...> writes:
 belinda> Hi,
 belinda> I've been playing w/both IDLE and IPython, using TkAgg in
 belinda> both cases as the back end. Also, I've got the latest
 belinda> matplotlib and ipython versions and am using MacPython's
 belinda> 2.4.4 IDLE.
 belinda> It seems that if IDLE is not invoked w/the -n flag, the
 belinda> figures that are drawn can often get the "whirling swirl
 belinda> of death" (i.e. they hang). Has it been other users'
 belinda> experience that the "-n" removes that problem (it
 belinda> mentioned this flag in the manual, but I didn't catch he
 belinda> motivation)? And if so, is there no other way to use IDLE
 belinda> when using matplotlib interactively? (The nice thing
 belinda> about IDLE is its "fresh" state each time you run a file;
 belinda> this goes away when -n is used).
>From http://matplotlib.sourceforge.net/backends.html#TkAgg
 Tkinter GUI backend
 
 Todd Miller has written a backend for Tkinter that uses the agg
 backend for rendering. To use Tkagg, you need to set the BUILD_TKAGG
 flag in setup.py. The windows installer comes with TkAgg prebuilt. See
 agg backend for more information on agg rendering and fonts. NOTE: on
 at least some versions of redhat linux, you must install a separate
 tkinter package, apparently tkinter-2.2.2-26.i386.rpm on Red Hat 9
 linux. Alternately, Python built from source code (Python.org tarball,
 not the redhat SRPM) includes Tkinter support by default on Red Hat
 Linux. In general, TkAgg is known to work with
 
 * python
 * idle -n (set tk.PYTHONINSPECT : True in matplotlibrc
 * IPython
 
 TkAgg is known not work with:
 
 * SciTE
 * pythonw
 * Pythonwin
 * idle
 
 Both of the latter shells fail with a RuntimeError "abnormal program
 termination". I checked on www.python.org about Tkinter and Pythonwin
 and they're known not to work together so that explains TkAgg on
 Pythonwin. tkinter trouble.
 
 I also looked into SciTE a little and discovered that it is related to
 Scintilla which in turn was derived from Pythonwin. scintilla This
 indicates to me that the same problem with Tkinter may be affecting
 both (SciTE and Pythonwin)... but I am out on a limb.
 
 
So yes, -n is required. There were lots of discussions of this on
the mailing list years ago when tkagg was being developed, so if you
are interested you might try searching the archives.