matplotlib-users Mailing List for matplotlib (Page 3)

jk...@ik... wrote:
> Arguably Matlab has the elegant Lisp-like feature lacking in Python of
> multiple return values. In Lisp you can write
> 
> (setq x (floor 3.14))
> 
> to set the value of x to 3, or
> 
> (multiple-value-setq (x y) (floor 3.14))
> 
> to set the value of x to 3 and the value of y to 0.14. Note how it is
> left up to the caller of the FLOOR function whether to capture just
> the first returned value or both of them. This is paralleled by
> Matlab's
> 
> x = some_function(a,b,c)
> [x,y] = some_function(a,b,c)
> 
> where the caller decides how many values will be returned.
Note that you can simply "emulate" this missing Python feature by 
appending indexes after your function call:
	x = some_function(a,b,c)[0]
	x, y = some_function(a,b,c)[:2]
	and so on...
Naturally this does not save computation as nargout could do, but is 
this really an issue? IMHO this is generally not.
JM. Philippe

Hello!
The problem was a problem with pygtk 2.4.0 and was caused by a parameter 
name "typename" which for C++ is also a keyword. Any C++ application 
using pygtk was affected and agg (which matplotlib is using) is written 
in C++. The fix to this problem was (among other few changes) to rename 
"typename" to "_typename", which was done in CVS shortly after pygtk 
2.4.0 was released.
In conclusion, just download pygtk 2.4.1 from pygtk.org and it will work!
Niklas Volbers.
Rich Drewes wrote:
> Hello,
> 
> Several users (including Humufr and Niklas Volbers) have reported on this
> list a compile error building matplotlib with pygtk. The error looks
> something like this:
> 
> In file included from src/_gtkagg.cpp:8:
> /usr/include/pygtk-2.0/pygobject.h:124: error: parse error before 
> `typename"
> /usr/include/pygtk-2.0/pygobject.h:131: error: parse error before 
> `typename"
> 
> I also experienced this problem. It appears to be some sort of namespace
> collision on the token "typename" (what this is colliding with isn't
> clear). By changing "typename" to "typname" or some other spelling in
> /usr/include/pygtk-2.0/pygobject.h I was then able to build matplotlib
> successfully.
> 
> If someone knows what is causing this and has a better solution, please
> advise. Perhaps it has something to do with GCC 3.4.x and that particular
> pygtk release.
> 
> Rich Drewes
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

>>>>> "Rich" == Rich Drewes <dr...@in...> writes:
 Rich> Hello, Several users (including Humufr and Niklas Volbers)
 Rich> have reported on this list a compile error building
 Rich> matplotlib with pygtk. The error looks something like this:
 Rich> In file included from src/_gtkagg.cpp:8:
 Rich> /usr/include/pygtk-2.0/pygobject.h:124: error: parse error
 Rich> before `typename" /usr/include/pygtk-2.0/pygobject.h:131:
 Rich> error: parse error before `typename"
 Rich> I also experienced this problem. It appears to be some sort
 Rich> of namespace collision on the token "typename" (what this is
 Rich> colliding with isn't clear). By changing "typename" to
 Rich> "typname" or some other spelling in
 Rich> /usr/include/pygtk-2.0/pygobject.h I was then able to build
 Rich> matplotlib successfully.
Don't do that! That looks brtually hackish.
See http://matplotlib.sourceforge.net/faq.html#PYGTK24

First off, thanks to everyone for the replies.
I think the problem turned out to be that when you do a `python setup.py
clean` it does not clean out the build directory (despite what it is
saying). I manually cleaned it out, rebuilt and everything is fine. There
must have been some strangeness left over from when I was trying to resolve
my include_dir issues I mentioned before. 
Just for the record, I am having no problems building against numarray 1.1
or 1.1.1. I started to try to use numeric, but it wanted a lib for cblas
that I didn't have. Before I started any of this, I deleted all old
versions of numarray and matplotlib is had in site-packages.
Thanks again for the help,
Scott.
-----Original Message-----
From: John Hunter [mailto:jdh...@ni...]
Sent: Wednesday, November 17, 2004 4:57 PM
To: Zelakiewicz, Scott (Research)
Cc: 'mat...@li...'
Subject: Re: [Matplotlib-users] Simple plot command fails
>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...>
writes:
 Scott> Still no luck. I am not trying to run this
 Scott> interactively. Switching between TkAgg and GTKAgg
 Scott> does not seem to do anything.
Did you try rm -rf your old site-packages/matplotlib and your build
subdirectory of the matplotlib src tree, and rebuild/install
matplotlib cleanly?
If that fails, it might be instructive to edit
"/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
and print len(x), len(y) and seeing what the hell is going on, since
the last error is
 if midPoint and self.gridOn: self.gridline.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
in draw
 xt, yt = self._transform.numerix_x_y(x, y)
ValueError: x and y must be equal length sequences
Finally, I can see that this is an error arising from drawing the
grid. Does it go away if you turn the grid off (axes.grid : False in
rc and comment out the grid call in simple_plot). 
I'm grasping at straws here - my best guess is above, that you have
some incompatible old matplotlib lying around.
JDH

>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...> writes:
 Scott> Still no luck. I am not trying to run this
 Scott> interactively. Switching between TkAgg and GTKAgg
 Scott> does not seem to do anything.
Did you try rm -rf your old site-packages/matplotlib and your build
subdirectory of the matplotlib src tree, and rebuild/install
matplotlib cleanly?
If that fails, it might be instructive to edit
"/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
and print len(x), len(y) and seeing what the hell is going on, since
the last error is
 if midPoint and self.gridOn: self.gridline.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
in draw
 xt, yt = self._transform.numerix_x_y(x, y)
ValueError: x and y must be equal length sequences
Finally, I can see that this is an error arising from drawing the
grid. Does it go away if you turn the grid off (axes.grid : False in
rc and comment out the grid call in simple_plot). 
I'm grasping at straws here - my best guess is above, that you have
some incompatible old matplotlib lying around.
JDH

Still no luck. I am not trying to run this interactively. Switching
between TkAgg and GTKAgg does not seem to do anything.
Here is the output from `python simple_plot.py --verbose-helpful`
Thanks again,
Scott.
zelakiew@shake> python simple_plot.py --verbose-helpful
matplotlib data path /local/share/matplotlib
loaded rc file /home/zelakiew/.matplotlibrc
matplotlib version 0.64
verbose.level helpful
interactive is 0
numerix numarray 1.1.1
font search path ['/local/share/matplotlib']
loaded ttfcache file /home/zelakiew/.ttffont.cache
matplotlib data path /local/share/matplotlib
loaded rc file /home/zelakiew/.matplotlibrc
matplotlib version 0.64
verbose.level helpful
interactive is 0
backend TkAgg version 8.3
Traceback (most recent call last):
 File "simple_plot.py", line 17, in ?
 show()
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_tkagg.py",
line 68, in show
 manager.show()
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_tkagg.py",
line 284, in show
 self.canvas.draw()
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_tkagg.py",
line 135, in draw
 FigureCanvasAgg.draw(self)
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py",
line 310, in draw
 self.figure.draw(self.renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/figure.py", line 254,
in draw
 for a in self.axes: a.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axes.py", line 963, in
draw
 self.xaxis.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axis.py", line 478, in
draw
 tick.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axis.py", line 131, in
draw
 if midPoint and self.gridOn: self.gridline.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
in draw
 xt, yt = self._transform.numerix_x_y(x, y)
ValueError: x and y must be equal length sequences
-----Original Message-----
From: John Hunter [mailto:jdh...@ni...]
Sent: Wednesday, November 17, 2004 4:21 PM
To: Zelakiewicz, Scott (Research)
Cc: 'Stephen Walton'; 'mat...@li...'
Subject: Re: [Matplotlib-users] Simple plot command fails
To test your installation, cd into the examples dir and try running
simple_plot.py from the unix shell.
 > cd examples
 > python simple_plot.py
 OR you can choose your backend from the shell with
 > python simple_plot.py -dTkAgg 
 > python simple_plot.py -dGTKAgg
If that works, almost surely you have an interactive problem that will
be cleared up with the links above. If now, rerun the script with
--verbose-helpful and report back.
Good luck,
JDH

>>>>> "Zelakiewicz," == Zelakiewicz, Scott (Research) <zel...@cr...> writes:
 Scott> Sorry, I should have explicitly stated most of this:
 Scott> This is on Redhat 9.0. I built numarray and
 Scott> matplotlib myself.
 Scott> Initially the matplotlib build had problems finding
 Scott> the numarray headers since I have to install
 Scott> everything to a non-standard place (I don't have
 Scott> root) and simply modifying basedir in setupext.py
 Scott> did not work. I made some sym-links and added to an
 Scott> include_dir to fix that and now there are no build
 Scott> problems.
 Scott> My .matplotlibrc is identical to the one put in
 Scott> share/matplotlib except numerix is set to 'numarray'
 Scott> and set datapath to '/local/share/matplotlib' which
 Scott> is where all the fonts and stuff are.
If you are running interactively from the python shell, you need to
make sure "interactive" is set to True in your rc file and do not use
show. 
 http://matplotlib.sourceforge.net/faq.html#SHOW
Also, to work interactively, you must use either the tkagg backend or
a python shell that supports threading for the GUI you are using (GTK
or WX) such as ipython http://ipython.scipy.org, which has explicit
support for matplotlib in the pylab mode
 http://matplotlib.sourceforge.net/interactive.html
To test your installation, cd into the examples dir and try running
simple_plot.py from the unix shell.
 > cd examples
 > python simple_plot.py
 OR you can choose your backend from the shell with
 > python simple_plot.py -dTkAgg 
 > python simple_plot.py -dGTKAgg
If that works, almost surely you have an interactive problem that will
be cleared up with the links above. If now, rerun the script with
--verbose-helpful and report back.
Good luck,
JDH

On Wed, 2004年11月17日 at 13:15 -0500, Zelakiewicz, Scott (Research) wrote:
> This is on Redhat 9.0. I built numarray and matplotlib myself. 
> 
> Initially the matplotlib build had problems finding the numarray headers
> since I have to install everything to a non-standard place (I don't have
> root)
Oof. I'm afraid I can't be much help. I long ago updated all my RH9
boxes to FC1 and I also have root access on them. Can anyone else
reproduce these problems?
-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
ste...@cs...

Sorry, I should have explicitly stated most of this:
This is on Redhat 9.0. I built numarray and matplotlib myself. 
Initially the matplotlib build had problems finding the numarray headers
since I have to install everything to a non-standard place (I don't have
root) and simply modifying basedir in setupext.py did not work. I made some
sym-links and added to an include_dir to fix that and now there are no build
problems. 
My .matplotlibrc is identical to the one put in share/matplotlib except
numerix is set to 'numarray' and set datapath to '/local/share/matplotlib'
which is where all the fonts and stuff are.
Thanks again,
Scott.
-----Original Message-----
From: Stephen Walton [mailto:ste...@cs...]
Sent: Wednesday, November 17, 2004 12:55 PM
To: Zelakiewicz, Scott (Research)
Cc: 'mat...@li...'
Subject: Re: [Matplotlib-users] Simple plot command fails
On Wed, 2004年11月17日 at 12:44 -0500, Zelakiewicz, Scott (Research) wrote:
> Any help/suggestions would be appreciated.
What OS version/distribution are you running? Did you built matplotlib
yourself? Any errors in the build? What is in your $HOME/.matplotlibrc
file?
-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
ste...@cs...

On Wed, 2004年11月17日 at 12:44 -0500, Zelakiewicz, Scott (Research) wrote:
> Any help/suggestions would be appreciated.
What OS version/distribution are you running? Did you built matplotlib
yourself? Any errors in the build? What is in your $HOME/.matplotlibrc
file?
-- 
Stephen Walton, Professor of Physics and Astronomy,
California State University, Northridge
ste...@cs...

Hi,
I am trying to get matplotlib (0.64) up and running. When I run the
following commands
	from matplotlib.matlab import *
	figure(1)
	plot([1,2,3,4])
	show()
I get an error message (shown below), the figure window draws with the
buttons on the bottom, but no plot is drawn. I have tried this with the
GTKAgg and TkAgg backends and they both give the same error. If it matters,
I am using numarray.
Any help/suggestions would be appreciated.
Thanks,
Scott.
Python 2.2.2 (#1, Feb 24 2003, 19:13:11)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from matplotlib.matlab import *
>>> figure(1)
<matplotlib.figure.Figure instance at 0x86cea2c>
>>> plot([1,2,3,4])
[<matplotlib.lines.Line2D instance at 0x87470cc>]
>>> show()
/local/usr/src/garnome2.6.2/lib/python2.2/site-packages/gtk-2.0/gtk/__init__
.py: 83: GtkDeprecationWarning: gtk.mainloop is deprecated, use gtk.main
instead
 self.warn(message, DeprecationWarning)
Traceback (most recent call last):
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py ",
line 96, in callback
 else: self.draw()
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_gtkagg.py ",
line 44, in draw
 FigureCanvasAgg.draw(self)
 File
"/local/lib/python2.2/site-packages/matplotlib/backends/backend_agg.py",
line 310, in draw
 self.figure.draw(self.renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/figure.py", line 254,
in d raw
 for a in self.axes: a.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axes.py", line 963, in
dra w
 self.xaxis.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axis.py", line 478, in
dra w
 tick.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/axis.py", line 132, in
dra w
 if midPoint and self.tick1On: self.tick1line.draw(renderer)
 File "/local/lib/python2.2/site-packages/matplotlib/lines.py", line 234,
in dr aw
 xt, yt = self._transform.numerix_x_y(x, y)
ValueError: x and y must be equal length sequences
 

>>>>> "Norbert" == Norbert Nemec <Nor...@gm...> writes:
 Norbert> I just sent patches about this to matplotlib-devel. The
 Norbert> current version has two problems with this:
Until these are incorporated, there is still an easy way to customize
the legend text (and other properties of legends) which is illustrated
in http://matplotlib.sf.net/examples/legend_demo.py. Here is the
approach, in brief
 leg = legend(... legend args here)
 texts = leg.get_texts()
 set(texts, fontsize='small', color='r')
JDH

[Apologies if this message is a duplicate; it seems that Gmane ate my
previous attempt at replying, since I sent another message to the list
before acking Gmane's autoreply.]
Andrew Straw writes:
> To me, nargout, like so much of Matlab, is a brutish hack introduced
> because that language is not as capable or elegant as Python. 
Arguably Matlab has the elegant Lisp-like feature lacking in Python of
multiple return values. In Lisp you can write
 (setq x (floor 3.14))
to set the value of x to 3, or
 (multiple-value-setq (x y) (floor 3.14))
to set the value of x to 3 and the value of y to 0.14. Note how it is
left up to the caller of the FLOOR function whether to capture just
the first returned value or both of them. This is paralleled by
Matlab's
 x = some_function(a,b,c)
 [x,y] = some_function(a,b,c)
where the caller decides how many values will be returned.
I imagine nargout could have arisen as an optimization aid: if a value
is not needed, the function can decide to not compute it. A reasonably
good Lisp compiler would probably do this optimization automatically,
but Matlab is (or was, until some recent version?) an interpreted
language with fewer opportunities for optimization.
Where Matlab goes terribly wrong (IMHO) is in that it encourages abuse
of the nargout mechanism: built-in functions like find change their
behavior depending on how many return values are expected. In effect,
the name "find" denotes two different functions, dispatched by the
value of nargouts.
> Regardless of whether your sense of aesthetics is different than mine,
> the kind of low-level shenanigans suggested as a work-around seems, at
> the very least, brittle and prone to maintenance and portability
> issues. (Would that even work on IronPython or PyPy?)
I imagine that the Psyco JIT compiler might have some problems with
the hack.
I would like to amend my suggestion upthread: instead of changing
mlab.find, add another function, say find2 unless someone thinks of a
better name, that always returns a tuple. The current version of find
could be left as it is, or, even better (this might be important for
automatic Matlab-to-Python translation), changed to return a single
index for any kind of array. This would require a mechanism for
addressing array elements by a single index, which probably doesn't
exist. For Matlab compatibility, the addressing should use the
column-major, i.e., Fortran, order.
In fact, I don't see why this wouldn't solve the problem of automatic
translation of functions that use nargout. The value of nargout is a
static feature of the function call, so the translator should easily
be able to dispatch according to the value, or add it as a keyword
argument. That is, if the user has a function like
 function [a,b]=foo(bar)
 switch nargout,
 case 1, a=bar;
 case 2, a=1; b=bar;
 end
the translator could produce the Python function
 def foo(bar, nargout=0):
 if nargout==1:
 return bar;
 elif nargout==2:
 return (1,bar);
and translate
 foo(1);
 a=foo(2);
 [b,c]=foo(3);
to
 foo(1);
 a=foo(2,nargout=1);
 (b,c)=foo(3,nargout=2);
I wouldn't do this for find, since (in my experience) the
two-return-value form of find is the more common case, and it would
not be very nice to always type in the nargout parameter when using
matplotlib interactively.
> it seems to me that early design mistakes resulted in terrible
> backwards compatibility issues, as well. For example, I remember
> being driven mad trying to figure out whether parentheses were
> needed when calling certain functions. I guess for some they are
> required and for others they aren't.
I wonder if this is the same problem that I had for a long time: I
finally realized that Matlab either does both auto-parenthesizing and
auto-quoting, or neither of them, so
 print -depsc2 fname
is equivalent to
 print('-depsc2', 'fname')
so if you want to create one of the parameters dynamically, you cannot
use the first form but will have to write something like
 print('-depsc2', sprintf('picture-%d', num))
(Then there is the confusion of {} vs () indexing, and cell strings
that are almost like real strings but sometimes need a {:} after them,
except that if you get them from a function, since the parser gets
confused if you type fun(param){:} so you need a temp variable, and
cell arrays of structs that sometimes act like structs of cell
arrays... Automatic translation of Matlab code will certainly have
some interesting challenges.)
-- 
Jouni K Seppänen

I just sent patches about this to matplotlib-devel.
The current version has two problems with this:
* legend does not take kwargs. All the options like FONTSIZE, PAD and others 
can only be set globally as class variables of Legend
* the option FONTSIZE - even if changed globally - is flat out ignored. It is 
used once for a calculation, but the crucial routine Legend.draw() completely 
ignores it.
Both problems are fixed with my patches (see matplotlib-devel or wait for them 
to appear in CVS)
Ciao,
Norbert
On Tuesday 16 November 2004 18:52, Cory Davis wrote:
> Hi All,
>
> Can anyone tell me how to change the size of the legend produced by
> matlab.legend independently of my axis tick labels?
>
> lh=legend(['a','b','c'],loc=4,fontsize=8)
>
> doesn't work and there seems to be nothing in the lh object that would
> help.
>
> Cheers,
> Cory
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi,
One thing that I really like about Matlab's handle graphics system is
that it is self-documenting: if I do h=plot(...), I can query the
current values of all properties with get:
 >> get(h)
 Color = [0 0 1]
 EraseMode = normal
 LineStyle = -
 LineWidth = [0.5]
[...] 
 UserData = []
 Visible = on
Also, if I'm interested in changing something but don't know the
allowed values, I can use set:
 >> set(h,'linestyle')
 [ {-} | -- | : | -. | none ]
 >> set(h,'erasemode')
 [ {normal} | background | xor | none ]
 >> set(h,'markersize')
 A line's "MarkerSize" property does not have a fixed set of property values.
I'm attaching a patch that adds something like this to Matplotlib. For
get, the changes are quite straightforward, but for set, the correct
design is not obvious. I have added some example documentation to axes
objects, so set(gca()) returns something useful.
But, again, I'm not sure about the design, so please consider this
patch not as something I'd like applied to matplotlib right now, but
as a suggestion of a feature I would like to see added.
-- 
Jouni K Seppänen

On Nov 16, 2004, at 4:51 PM, Darren Dale wrote:
> Maybe my example wasn't clear. There are good reasons for using 
> varargout and nargout in Matlab. If I write a function to fit a peak, 
> I can return the position, height, FWHM and sumResiduals along with 
> some information about how the peakfitting algorithm concluded. If a 
> user calls [p,h,fwhm,sr] = peakfit(x,y), you use nargout to determine 
> that the caller does not want the algorithm report.
Hi Darren,
I sometimes return a dict in cases like this:
fit = peakfit(x,y)
print fit['position']
print fit['height']
print fit['FWHM']
and so on...
Sometimes, the results I always want get returned on their own and 
optionally return all results:
p,h = peakfit(x,y) # return just the basic 
results
p,h,fit_extras = peakfit(x,y,full_output=True) # return everything
print fit_extras['FHWM']
(I think some scipy functions operate more-or-less like this, too. 
Perhaps without returning results in a dict, but merely as extra 
arguments.)
I have to agree with the opinions of Chris Barker and John Hunter 
cautioning against writing new code using an 'nargout-alike'. (When 
translating Matlab code to Python I can see that it might be useful.) 
Furthermore, I often find myself grabbing the results of a function 
call in one variable, stuffing it somewhere, and later, knowing it's a 
tuple, examining the elements later. This handy trick would be 
impossible with an nargout-based implementation.
To me, nargout, like so much of Matlab, is a brutish hack introduced 
because that language is not as capable or elegant as Python. (To 
digress further and probably show the era at which I left Matlab to be 
around 5.x, it seems to me that early design mistakes resulted in 
terrible backwards compatibility issues, as well. For example, I 
remember being driven mad trying to figure out whether parentheses were 
needed when calling certain functions. I guess for some they are 
required and for others they aren't. I think it would be very 
difficult to define the syntax for Matlab as done in the Python 
(Language) Reference Manual. And let's not get into issues of object 
oriented programming, types and 'everything is a (double precision) 
matrix'.)
Regardless of whether your sense of aesthetics is different than mine, 
the kind of low-level shenanigans suggested as a work-around seems, at 
the very least, brittle and prone to maintenance and portability 
issues. (Would that even work on IronPython or PyPy?)
Anyhow, if you're not scared by bytecode hacks in your initial 
toe-dipping forays into Python, I invite you to dive in!
Cheers!
Andrew

On Tue, 2004年11月16日 at 18:23 -0800, Rich Drewes wrote:
> Hello,
> 
> Several users (including Humufr and Niklas Volbers) have reported on this
> list a compile error building matplotlib with pygtk. The error looks
> something like this:
> 
> In file included from src/_gtkagg.cpp:8:
> /usr/include/pygtk-2.0/pygobject.h:124: error: parse error before 
> `typename"
> /usr/include/pygtk-2.0/pygobject.h:131: error: parse error before 
> `typename"
> 
> I also experienced this problem. It appears to be some sort of namespace
> collision on the token "typename" (what this is colliding with isn't
> clear). By changing "typename" to "typname" or some other spelling in
> /usr/include/pygtk-2.0/pygobject.h I was then able to build matplotlib
> successfully.
> 
> If someone knows what is causing this and has a better solution, please
> advise. Perhaps it has something to do with GCC 3.4.x and that particular
> pygtk release.
> 
> Rich Drewes
The problem is a bug in old versions of PyGTK, upgrading to a later version 
(2.4.1 I believe) will fix it.
Regards
Steve
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello,
Several users (including Humufr and Niklas Volbers) have reported on this
list a compile error building matplotlib with pygtk. The error looks
something like this:
In file included from src/_gtkagg.cpp:8:
 /usr/include/pygtk-2.0/pygobject.h:124: error: parse error before 
`typename"
 /usr/include/pygtk-2.0/pygobject.h:131: error: parse error before 
`typename"
I also experienced this problem. It appears to be some sort of namespace
collision on the token "typename" (what this is colliding with isn't
clear). By changing "typename" to "typname" or some other spelling in
/usr/include/pygtk-2.0/pygobject.h I was then able to build matplotlib
successfully.
If someone knows what is causing this and has a better solution, please
advise. Perhaps it has something to do with GCC 3.4.x and that particular
pygtk release.
Rich Drewes

Hi Chris,
>> Matlab also returns one object- the varargout cell array which is 
>> similar to Python's list or tuple. You write a function, and pack 
>> varargout with nargout results: [a,b]=matlabfun().
>
>
>
> I haven't used Matlab for a while, and not a newer version than 5.*, 
> but IIRC, while the above notation looks, like you are returning a 
> cell array, you could not call that fun with a single return argument. 
> Perhaps that's changed, in which case you shouldn't use nargout in 
> Matlab either!
Maybe my example wasn't clear. There are good reasons for using 
varargout and nargout in Matlab. If I write a function to fit a peak, I 
can return the position, height, FWHM and sumResiduals along with some 
information about how the peakfitting algorithm concluded. If a user 
calls [p,h,fwhm,sr] = peakfit(x,y), you use nargout to determine that 
the caller does not want the algorithm report.
>
> Anyway, my main point was that kludging a nargout implementation in 
> python was not a good idea. I'd much rather see matplotlib be 
> pythonesque than matlabesque. Perhaps my goals are different than 
> others, but I use Python, rather than Matlab, largely because I like 
> the language better.
>
I originally looked into Python because everyone who works with it loves 
it, and it is free. I felt that the switch could be quick and painless 
because of John and the other MPL developers efforts with the Matlab 
interface. I would probably have waited to switch until after graduating 
if I hadnt googled "Python AND Matlab" one fateful day. (Cornell 
recently sent me a survey asking whether I felt 230ドル was fair for a 12 
month license!). The matlab interface is already matlabesque. I think 
*args and Matlab's varargin are equivalent. Let me write up some 
examples using nargout as it is intended to be used, and I'll submit 
them to the list in a new thread. This one has strayed a bit from the 
original topic.
Darren

Thanks for your feedback. I ran it with --verbose-helpful, and indeed I 
got some helpful messages (see below). I'll have to remember that in future.
You are right, one module is loading the TKAgg backend, and the other is 
loading the GTK backend.
The reason I have this in my modules is that I have one module A which 
is intended to be very general purpose, but has a couple of hooks to do 
plots. Module A doesn't care which backend it uses, and at the moment it 
uses the matplotlib.matlab interface because that's what I knew when I 
wrote it.
Module B is a more specific application, which was using matlab calls, 
but I found I had to convert it to use GTK and the matplotlib API 
because I call it from application C which has a GUI window using GTK 
and glade.
Summary:
module A: general purpose, matlab API, no hardcoded backend
module B: more specialised, matplotlib API, GTK backend, explicit GTK 
window management
app C: more specialised, no matplotlib or matlab, GTK & glade GUI, 
functions from modules A and B used in callback threads
I don't really want to force module A to use GTK, because TKAgg (or 
whatever's in .matplotlibrc) is more likely to work for other users on 
other machines. So for the moment I can get by, if I import module A 
after module B.
But maybe there is some nice way to do things that I'm missing. Perhaps 
I can convert module A to use the matplotlib API but still not specify 
the backend, and it will still work standalone and also start playing 
nicely with module B and app C. I'll have a play with it when I get some 
time.
Here is the output from "python frog.py --verbose-helpful":
$ python frog.py --verbose-debug
matplotlib data path c:\Python23\share\matplotlib
loaded rc file c:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.64
verbose.level debug
interactive is False
numerix Numeric 23.3
font search path ['c:\\Python23\\share\\matplotlib', 
'/usr/share/fonts/msttf']
loaded ttfcache file M:\home\mra\.ttffont.cache
matplotlib data path c:\Python23\share\matplotlib
loaded rc file c:\Python23\share\matplotlib\.matplotlibrc
matplotlib version 0.64
verbose.level debug
interactive is False
backend TkAgg version 8.4
Could not load matplotlib icon: Couldn't recognize the image file format 
for file 'c:\Python23\share\matplotlib\matplotlib.svg'
Traceback (most recent call last):
 File "frog.py", line 6, in ?
 embedding_in_gtk2_mra.plotme()
 File "M:\home\My Documents\My 
Downloads\matplotlib-0.64\matplotlib-0.64\exampl 
 es\embedding_in_gtk2_mra.py", line 43, 
in plotme
 toolbar = NavigationToolbar(canvas, win)
 File 
"C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 
 963, in __init__
 NavigationToolbar2.__init__(self, canvas)
 File "C:\Python23\Lib\site-packages\matplotlib\backend_bases.py", 
line 786, in __init__
 self._init_toolbar()
 File 
"C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 
 1028, in 
_init_toolbar
 self._init_toolbar2_4()
 File 
"C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 
 1091, in 
_init_toolbar2_4
 parent=self.win,)
 File 
"C:\Python23\lib\site-packages\matplotlib\backends\backend_gtk.py", line 
 1423, in __init__
 self.IMAGE_FORMAT = 
matplotlib.backends.backend_mod.IMAGE_FORMAT
AttributeError: 'module' object has no attribute 'IMAGE_FORMAT'
Cheers,
Matthew.
John Hunter wrote:
>>>>>>"matthew" == matthew arnison <ma...@ca...> writes:
> 
> 
> matthew> Oh dear. I'm going to take another u-turn, and say I hit
> matthew> this IMAGE_FORMAT attribute glitch again.
> 
> Try running your script with --verbose-helpful or --verbose-debug and
> report the output. That way we can see what is happening behind the
> scenes.
> 
> matthew> To atone for my reversals, I have isolated a test case,
> matthew> and I attach sample code. It seems to be triggered by
> matthew> importing matplotlib.matlab in one module, and importing
> matthew> matplotlib backend stuff directly in another module.
> 
> matthew> Running frog.py gives:
> matthew> line 1423, in __init__ self.IMAGE_FORMAT =
> matthew> matplotlib.backends.backend_mod.IMAGE_FORMAT
> matthew> AttributeError: 'module' object has no attribute
> matthew> 'IMAGE_FORMAT'
> 
> Fernando added the backend_mod to matplotlib.backends.__init__.py --
> perhaps he has some insight into what is going on.
> 
> matthew> As commented in the code, changing the order of the
> matthew> import statements in frog.py avoids the bug. Or using the
> matthew> workaround I mentioned below.
> 
> matthew> Hmmm. Now I remember an email from John Hunter saying
> matthew> that pythonic matplotlib should not be mixed with the
> matthew> matlab interface. Maybe this glitch is an artefact of
> matthew> that. It does mean however that all my modules have to
> matthew> use one API or the other.
> 
> Yes, this is basically undefined. When using the API, you control
> figure canvases, windows, backends, etc, independently. When you
> import matplotlib.matlab, it parses your rc file (or not finding it
> falls back on a default) and may try and load a different backend.
> Since IMAGE_FORMAT is only used in some backends, my guess is you are
> seeing a backend conflict. Running --verbose-helpful should give you a
> clue about which backends matplotlib is loading.
> 
> Note there are scant few features in the matlab interface that you
> can't access directly from the API. There is no compelling reason to
> mix them, save laziness, and as you are finding, it doesn't really
> save you any time. If you want to use something from the matlab
> interface and aren't sure how to do it from the API, open up matlab.py
> and take a look at how that function does it. A large number if not
> the majority of matlab interface functions simply forward their calls
> on to the current axes.
> 
> JDH

Hi All,
Can anyone tell me how to change the size of the legend produced by
matlab.legend independently of my axis tick labels?
lh=legend(['a','b','c'],loc=4,fontsize=8)
doesn't work and there seems to be nothing in the lh object that would
help.
Cheers,
Cory

>>>>> "Chris" == Chris <bi...@Fu...> writes:
 Chris> Dear John, I see your points. However, after I changed to
 Chris> using add_artist. This is still nothing on the canvas. I
 Chris> think that there is some problem with the draw function of
 Chris> my arrow class. I have no idea what else should be
 Chris> there. At the moment, only one call in my case as below.
 Chris> 	def draw(self, renderer): self._stem.draw(renderer)
 Chris> Could u tell what else should be called?
Your drawing function looks fine. Could this be a problem with axes
limits. Make sure the x and y limits are set properly with the xlim,
ylim or axis commands. The limits are normally autoscaled by calling
plot, but you are not using it so you have to take care that the
limits are set. After you get a working prototype, I can help you
with the autoscaling part.
If this doesn't fix your problem, email me your matlab.py, axes.py and
test code as attachments off-list and I'll take a look.
JDH

Darren Dale wrote:
> Matlab also returns one object- the varargout cell array which is 
> similar to Python's list or tuple. You write a function, and pack 
> varargout with nargout results: [a,b]=matlabfun().
I haven't used Matlab for a while, and not a newer version than 5.*, but 
 IIRC, while the above notation looks, like you are returning a cell 
array, you could not call that fun with a single return argument. 
Perhaps that's changed, in which case you shouldn't use nargout in 
Matlab either!
Anyway, my main point was that kludging a nargout implementation in 
python was not a good idea. I'd much rather see matplotlib be 
pythonesque than matlabesque. Perhaps my goals are different than 
others, but I use Python, rather than Matlab, largely because I like the 
language better.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Dear John,
I see your points. However, after I changed to using add_artist. This is 
still nothing on the canvas. I think that there is some problem with the 
draw function of my arrow class. I have no idea what else should be 
there. At the moment, only one call in my case as below.
	def draw(self, renderer):
		self._stem.draw(renderer)
Could u tell what else should be called?
Best regards,
Chris
John Hunter wrote:
>>>>>>"Chris" == Chris <bi...@Fu...> writes:
> 
> 
> Chris> I tried with what you suggested to make an Arrow class. To
> Chris> begin with, I only put an Line2D instance. I searched for
> Chris> table stuff in axes.py, matlab.py to make the arrow
> Chris> importable from matplotlib.matlab. Then I also try a very
> Chris> very simple demo and I expect to see a simple
> Chris> line. However, I can not see it. Could someone tell me what
> Chris> is the problem. Here is my very very rudimental codes.
> 
> Nowhere in your code do you actually draw the arrows in self.arrows.
> In Axes.draw you would need to do
> 
> for arrow in self.arrows: 
> arrow.draw(renderer)
> 
> And this should work.
> 
> However, you can avoid all the overhead of add_arrow, and keeping a
> list of arrows in self.arrows simply by doing
> 
> 
> def arrow(self, x, y, *args, **kwargs):
> a = Arrow(x,y, *args, **kwargs)
> self.add_artist(a)
> ^^^
> return a
> 
> Ie, call add_artist which is a generic method for adding artists to
> the axes.
> 
> Hope this helps,
> JDH
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

>>>>> "Chris" == Chris <bi...@Fu...> writes:
 Chris> I tried with what you suggested to make an Arrow class. To
 Chris> begin with, I only put an Line2D instance. I searched for
 Chris> table stuff in axes.py, matlab.py to make the arrow
 Chris> importable from matplotlib.matlab. Then I also try a very
 Chris> very simple demo and I expect to see a simple
 Chris> line. However, I can not see it. Could someone tell me what
 Chris> is the problem. Here is my very very rudimental codes.
Nowhere in your code do you actually draw the arrows in self.arrows.
In Axes.draw you would need to do
 for arrow in self.arrows: 
 arrow.draw(renderer)
And this should work.
However, you can avoid all the overhead of add_arrow, and keeping a
list of arrows in self.arrows simply by doing
 def arrow(self, x, y, *args, **kwargs):
 a = Arrow(x,y, *args, **kwargs)
 self.add_artist(a)
 ^^^
 return a
Ie, call add_artist which is a generic method for adding artists to
the axes.
Hope this helps,
JDH