matplotlib-users Mailing List for matplotlib (Page 8)

Hi all.
I installed matplotlib using a python distribution with only numarray 
installed (no Numeric). The compilation was fine (but some troubles 
locating the GTK libraries... I solved) but when I started my python 
shell and I imported pylab I got this error:
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "***/installation/lib/python2.3/site-packages/pylab.py", line 1, 
in ?
 from matplotlib.pylab import *
 File 
"***/installation/lib/python2.3/site-packages/matplotlib/pylab.py", line 
194, in ?
 import cm
 File "***/installation/lib/python2.3/site-packages/matplotlib/cm.py", 
line 5, in ?
 import colors
 File 
"***/installation/lib/python2.3/site-packages/matplotlib/colors.py", 
line 33, in ?
 from numerix import array, arange, take, put, Float, Int, where, \
 File 
"***/installation/lib/python2.3/site-packages/matplotlib/numerix/__init__.py", 
line 58, in ?
 from Numeric import *
ImportError: No module named Numeric
 >
(I replaced the installation dir with ***)
OK, so I copied and modified the ~/.matplotlib/matplotlibrc file defining:
numerix : numarray
but nothing happened, the same error occured.
The only way I found to use matplotlib is modifing the file:
***/installation/lib/python2.3/site-packages/matplotlib/numerix/__init__.py
with a trick.
Is it an installation bug?
Thanks.
Luigi

Hi John,
Do you recieve the 2 scripts i send you concerning this problem?
The mails is dated from 02/11/2005 09:49
Rergards,
Philippe Collet

On Mon, 7 Nov 2005, Robert Hetland apparently wrote:=20
> It is not possible to plot a single point. For example:=20
> plot (0.4,0.6,'+'); #fails=20
Use lists.
hth,
Alan Isaac

While trying to create a series of labeled points, I noticed some 
inconsistent behavior in pylab.
It is not possible to plot a single point. For example:
plot (0.4,0.6,'+'); #fails
It is possible to work around this with:
text(0.4, 0.6,'+', 
horizontalalignment='center',verticalalignment='center')
but that seems to be counter to the philosophy that simple plots 
should be simple to make, and plotting commands should just work.
In a similar vein, it seems vectors could be added to text by 
allowing a user to plot a list of strings at an array of points.
These two additions would make is so one could either loop over a 
series of points, adding labels for each loop, or plot all the points 
and all the labels with two simple commands. Both seem like 
reasonable things to do, and both should be supported.
-Rob.
-----
Rob Hetland, Assistant Professor
Dept of Oceanography, Texas A&M University
p: 979-458-0096, f: 979-845-6331
e: he...@ta..., w: http://pong.tamu.edu

added a wiki entry for this, it can be found here:
http://www.scipy.org/wikis/topical_software/UsingMatPlotLibInACGIScript
On 11/5/05, frank h. <fra...@gm...> wrote:
> Hej Andrew,
> intersting solution! just a couple of days ago I was struggeling with
> the same problem
> I solved it by setting the environment variable from within my CGI script
> the following is a template for a cgi that uses matplotlib to create a
> png figure:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> #!/usr/bin/python
> import cgitb; cgitb.enable()
>
> # set HOME environment variable to a directory the httpd server can write=
 to
> import os
> myenv =3D os.environ
> myenv['HOME'] =3D '/tmp/'
>
> # chose a non-GUI backend
> import matplotlib
> matplotlib.use('Agg')
>
> # construct your plot
> from pylab import *
> ...
>
> # save the plot as image
> savefig(...)
>
> On 11/5/05, Andrew P <gr...@gm...> wrote:
> > OK, scratch that. Typing it out helped me see where my assumptions
> > were screwy. You can set environment variables quite happily in
> > .htaccess.
> >
> > If this gets past moderation, you can just do this:
> >
> > SetEnv HOME /user/home/directory
> >
> > In .htaccess and it fixes it right up :)
> >
> > On 11/4/05, Andrew P <gr...@gm...> wrote:
> > > Hello all,
> > >
> > > Matplotlib raises this error when I import it as a CGI program:
> > >
> > > RuntimeError: '/var/www' is not a writable dir; you must set
> > > environment variable HOME to be a writable dir
> > >
> > > I am a non-root user, and the Apache user's HOME =3D/var/www, so CGI
> > > script raises an exception when that directory isn't writeable. Ther=
e
> > > is nothing to be done about the Apache users's environment variables,
> > > or the writablity of that directory, as a non-root user :)
> > >
> > > It appears that matplotlib checks the HOME environment variable, then
> > > the MATPLOTLIBDATA variable, and then goes on to check the
> > > matplotlibrc starting with the current directory. But it raises an
> > > exception if the home directory isn't writeable without checking the
> > > rc file to see if the datapath inside it would work?
> > >
> > > Is there a way to either prevent matplotilb from checking for HOME,
> > > and go straight to the local matplotlibrc, or alternately have it
> > > check the matplotlibrc if the HOME directory isn't writable?
> > >
> > >
> > > Thanks,
> > >
> > > Andrew
> > >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server. Dow=
nload
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> Do you mean me? If so, I'm not sure, what I've objected to
 Chris> a lot are two things: procedural, rather than OO style; and
 Chris> compatibility with Matlab, rather than Python. Magic is OK,
 Chris> as long as it's easily over-written. In this case, as long
 Chris> as I can do:
OK, my bad. I was confusing your criticism of the procedural style of
the pylab interface with others criticism of the magic. Both are
valid, and both need to be able to be "turned off' which the OO
interface does...
 Chris> I'm not the OP, but I got the impression that his
 Chris> .matplotlibrc had numarray in it, even though it was not
 Chris> installed, and he hadn't edited it, so there was a mistake
 Chris> somewhere. Where, I don't know.
I don't think that's likely, unless was using an STScI matplotlib OS X
distribution, which I think they ship, or did ship at one point.
JDH

Hej Andrew,
intersting solution! just a couple of days ago I was struggeling with
the same problem
I solved it by setting the environment variable from within my CGI script
the following is a template for a cgi that uses matplotlib to create a
png figure:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#!/usr/bin/python
import cgitb; cgitb.enable()
# set HOME environment variable to a directory the httpd server can write t=
o
import os
myenv =3D os.environ
myenv['HOME'] =3D '/tmp/'
# chose a non-GUI backend
import matplotlib
matplotlib.use('Agg')
# construct your plot
from pylab import *
...
# save the plot as image
savefig(...)
On 11/5/05, Andrew P <gr...@gm...> wrote:
> OK, scratch that. Typing it out helped me see where my assumptions
> were screwy. You can set environment variables quite happily in
> .htaccess.
>
> If this gets past moderation, you can just do this:
>
> SetEnv HOME /user/home/directory
>
> In .htaccess and it fixes it right up :)
>
> On 11/4/05, Andrew P <gr...@gm...> wrote:
> > Hello all,
> >
> > Matplotlib raises this error when I import it as a CGI program:
> >
> > RuntimeError: '/var/www' is not a writable dir; you must set
> > environment variable HOME to be a writable dir
> >
> > I am a non-root user, and the Apache user's HOME =3D/var/www, so CGI
> > script raises an exception when that directory isn't writeable. There
> > is nothing to be done about the Apache users's environment variables,
> > or the writablity of that directory, as a non-root user :)
> >
> > It appears that matplotlib checks the HOME environment variable, then
> > the MATPLOTLIBDATA variable, and then goes on to check the
> > matplotlibrc starting with the current directory. But it raises an
> > exception if the home directory isn't writeable without checking the
> > rc file to see if the datapath inside it would work?
> >
> > Is there a way to either prevent matplotilb from checking for HOME,
> > and go straight to the local matplotlibrc, or alternately have it
> > check the matplotlibrc if the HOME directory isn't writable?
> >
> >
> > Thanks,
> >
> > Andrew
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 11/4/05, Chris Barker <Chr...@no...> wrote:
>
> Paul Barrett wrote:
> >>How about a setup.py option where you can explicitly set numeric or
> >
> > numarray, such as "--use=3Dnumarray"? This optional will build MPL for
> > numarray and modify the rc file so that it doesn't have to be edited by
> > hand.
>
> I'm confused. Is this a proposal, or is it implemented now? Either way,
> I like it.
>
It's a proposal. It's also explicit. :-)
-- Paul

Hello all,
Matplotlib raises this error when I import it as a CGI program:
RuntimeError: '/var/www' is not a writable dir; you must set
environment variable HOME to be a writable dir
I am a non-root user, and the Apache user's HOME =3D/var/www, so CGI
script raises an exception when that directory isn't writeable. There
is nothing to be done about the Apache users's environment variables,
or the writablity of that directory, as a non-root user :)
It appears that matplotlib checks the HOME environment variable, then
the MATPLOTLIBDATA variable, and then goes on to check the
matplotlibrc starting with the current directory. But it raises an
exception if the home directory isn't writeable without checking the
rc file to see if the datapath inside it would work?
Is there a way to either prevent matplotilb from checking for HOME,
and go straight to the local matplotlibrc, or alternately have it
check the matplotlibrc if the HOME directory isn't writable?
Thanks,
Andrew

John Hunter wrote:
> This is what I do for the win32 builds -- hand edit the file before
> each build. A little bit of a pain, bit it works (as long as you
> remember to tweak the file before the build <wink>)
I guess I could write a little script that did it for me easily enough. 
Who else is building MPL on OS-X. I may not have as much need for it 
now, we're moving a web app that uses it from an OS-X box to a Linux box.
> I think we would readily accept a patch for either or both of these,
> but there are those who already despise the amount of magic that pylab
> engages in (and you are usually near the front of that chorus).
Do you mean me? If so, I'm not sure, what I've objected to a lot are two 
things: procedural, rather than OO style; and compatibility with Matlab, 
rather than Python. Magic is OK, as long as it's easily over-written. In 
this case, as long as I can do:
import matplotlib
matplotlib.use(...)
I'm happy.
> Yes,
> explicit is (usually) better than implicit, but this tends to conflict
> with "just works".... Are you starting to experience a change of
> heart :-) ?
I like to think I've been totally consistent....
> In your use case is this correct, or do we need to amend the build,
> runtime or docs? According to your post, we should fall back on
> Numeric if numarray is specified but not present. Reasonable, but
> also a bit counter-intuitive since Numeric is the default and in this
> case the user would have explicitly overridden the default.
I'm not the OP, but I got the impression that his .matplotlibrc had 
numarray in it, even though it was not installed, and he hadn't edited 
it, so there was a mistake somewhere. Where, I don't know.
-CHB
-- 
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...

OK, scratch that. Typing it out helped me see where my assumptions
were screwy. You can set environment variables quite happily in
.htaccess.
If this gets past moderation, you can just do this:
SetEnv HOME /user/home/directory
In .htaccess and it fixes it right up :)
On 11/4/05, Andrew P <gr...@gm...> wrote:
> Hello all,
>
> Matplotlib raises this error when I import it as a CGI program:
>
> RuntimeError: '/var/www' is not a writable dir; you must set
> environment variable HOME to be a writable dir
>
> I am a non-root user, and the Apache user's HOME =3D/var/www, so CGI
> script raises an exception when that directory isn't writeable. There
> is nothing to be done about the Apache users's environment variables,
> or the writablity of that directory, as a non-root user :)
>
> It appears that matplotlib checks the HOME environment variable, then
> the MATPLOTLIBDATA variable, and then goes on to check the
> matplotlibrc starting with the current directory. But it raises an
> exception if the home directory isn't writeable without checking the
> rc file to see if the datapath inside it would work?
>
> Is there a way to either prevent matplotilb from checking for HOME,
> and go straight to the local matplotlibrc, or alternately have it
> check the matplotlibrc if the HOME directory isn't writable?
>
>
> Thanks,
>
> Andrew
>

Paul Barrett wrote:
>>How about a setup.py option where you can explicitly set numeric or
> 
> numarray, such as "--use=numarray"? This optional will build MPL for
> numarray and modify the rc file so that it doesn't have to be edited by
> hand.
I'm confused. Is this a proposal, or is it implemented now? Either way, 
I like it.
-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...

On 10/29/05 09:41, Ryan Krauss wrote:
> Here you go Ken. Thanks again. Let me know if I can do or try anything else:
I'm sorry it's taken so long to me to get back to you. I finally had some 
time to look into things this morning, and I must confess I'm stumped...
The stack trace you sent me indicates that the segfault occurs when _wxagg.cpp 
is trying to call wxPyConstructObject():
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1210517280 (LWP 10694)]
> 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
> 129 PyObject *pyWxBitmap = wxPyConstructObject(bitmap,
> _T("wxBitmap"), 1---Type <return> to continue, or q <return> to
> quit---
> );
> Current language: auto; currently c++
> (gdb) bt
> #0 0xb4fa3411 in _wxagg_module::convert_agg_to_wx_bitmap (this=0x81d8108,
> args=@0xbff1ccb0) at src/_wxagg.cpp:129
This didn't make a whole lot of sense to me at first, so I did some digging. 
It turns out that wxPyConstructObject() is actually a macro that invokes the 
function pointer wxPyCoreAPIPtr->p_wxPyConstructObject(). This is a pretty 
common idiom in Python for exposing extension module APIs to other extension 
modules... Numeric and numarray both use it, for example.
So, it appears that dereferencing the either the pointer to the wxPyCoreAPIPtr 
structure itself or the p_wxPyConstructObject function pointer within that 
structure causes the segmentation fault. I've reviewed the code involved and 
I can't come up with a plausible cause for this behavior. I think this could 
be caused by a mismatch between the wxPython headers and the wxPython 
extension itself, but I'm not even sure that would do it.
Could you try reinstalling the headers from the Ubuntu source package one more 
time and rebuilding, just to make sure that isn't the problem? I haven't been 
able to reproduce this problem under Debian, so I guess I'll need to get 
Ubuntu installed somewhere and hope that I can reproduce it myself.
If anyone else has experienced similar problems while using the WxAgg 
accelerator extension, has been able to reproduce this particular problem, or 
has any idea what might be going on, please let me know! Thanks.
Ken

[snip, snip]
To summarize: the commandline is examined first, the rc file second,
> and the default array package is Numeric.
>
> In your use case is this correct, or do we need to amend the build,
> runtime or docs? According to your post, we should fall back on
> Numeric if numarray is specified but not present. Reasonable, but
> also a bit counter-intuitive since Numeric is the default and in this
> case the user would have explicitly overridden the default. In the
> case of an explicit override from the default, failing might be better
> than just working....
>
> How about a setup.py option where you can explicitly set numeric or
numarray, such as "--use=3Dnumarray"? This optional will build MPL for
numarray and modify the rc file so that it doesn't have to be edited by
hand.
-- Paul

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> 1) I'm wondering if there's a way to pre-define different
 Chris> defaults for different platforms. For example, I built an
 Chris> OS-X installer that doesn't support GTK, but the
 Chris> .matplotlibrc still had GtkAgg as the default. Yes, I could
 Chris> have edited the .matplotlib rc in my installer, but I'd
 Chris> have to do that each time I built a new one. It would be
 Chris> nice to have something in CVS that just worked.
This is what I do for the win32 builds -- hand edit the file before
each build. A little bit of a pain, bit it works (as long as you
remember to tweak the file before the build <wink>)
 Chris> 2) Perhaps we could make the processing of matplotlibrc
 Chris> smarter. For example: if numarray is specified, but not
 Chris> installed, and Numeric is, it could roll over to
 Chris> Numeric. Same thing with back-ends. Of course, this kind of
 Chris> breaks the "explicit is better than implicit" rule, but it
 Chris> would greatly improve the "It just works" qualities of MPL.
There is a consensus that the backend selector should be smarter. One
proposal is to iterate over a list of candidates and choose the first
one that works. Another is to set the backend in the default rc file
at setup.py build time. Both could be done, and the same arguments
apply to the numerix setting (AFAIK, These are the only two rc file
settings that might be advantageously set at build time). 
I think we would readily accept a patch for either or both of these,
but there are those who already despise the amount of magic that pylab
engages in (and you are usually near the front of that chorus). Yes,
explicit is (usually) better than implicit, but this tends to conflict
with "just works".... Are you starting to experience a change of
heart :-) ?
FYI, the advertised behavior of numeric is as follows (eg
http://matplotlib.sf.net/matplotlib.numerix.html)
 numerix imports either Numeric or numarray based on various
 selectors.
 0. If the value "--numarray" or "--Numeric" is specified on the
 command line, then numerix imports the specified array package.
 1. The value of numerix in matplotlibrc: either Numeric or numarray
 2. If none of the above is done, the default array package is
 Numeric. Because the matplotlibrc always provides *some* value
 for numerix (it has it's own system of default values), this
 default is most likely never used.
 To summarize: the commandline is examined first, the rc file second,
 and the default array package is Numeric.
In your use case is this correct, or do we need to amend the build,
runtime or docs? According to your post, we should fall back on
Numeric if numarray is specified but not present. Reasonable, but
also a bit counter-intuitive since Numeric is the default and in this
case the user would have explicitly overridden the default. In the
case of an explicit override from the default, failing might be better
than just working....
JDH

>>>>> "frank" == frank h <fra...@gm...> writes:
 frank> RuntimeError: '/Library/WebServer'
 frank> is not a writable dir; you must set environment variable
 frank> HOME to be a writable dir
 frank> what am i doing wrong? any insight is appreciated thanks,
Python tracebacks are a little funny: you have to read them from the
end to make sense of them. In this case I'll quote the end of the
message you posted back to you
 RuntimeError: '/Library/WebServer' is not a writable dir; you must
 set environment variable HOME to be a writable dir
Is this not clear? If not, you need to learn a little bit about UNIX,
environment variables, and permissions. But feel free to ask
questions here along the way :-)
JDH

Hello,
I am trying to use matplotlib in a cgi script and I always get an error
the following script is the simplest script that reproduces the error
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
#!/sw/bin/python2.4
from pylab import *
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
and the error is always:
 File "/Library/WebServer/CGI-Executables/ldapstats.py", line 11, in ?
 from matplotlib.ticker import *
 File "/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line 862, =
in ?
 rcParams =3D rc_params()
 File "/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line
810, in rc_params
 fname =3D matplotlib_fname()
 File "/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line
786, in matplotlib_fname
 fname =3D os.path.join(get_configdir(), 'matplotlibrc')
 File "/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line
261, in wrapper
 ret =3D func(*args, **kwargs)
 File "/sw/lib/python2.4/site-packages/matplotlib/__init__.py", line
352, in _get_configdir
 raise RuntimeError("'%s' is not a writable dir; you must set
environment variable HOME to be a writable dir "%h)
RuntimeError: '/Library/WebServer' is not a writable dir; you must set
environment variable HOME to be a writable dir
what am i doing wrong?
any insight is appreciated
thanks,
-frank

Robert Kern wrote:
> Since one can have both Numeric and numarray enabled for numerix and
> certainly more than one backend built, the user still has to edit the
> matplotlibrc to specify their choice.
Yes, but I always like the concept of "sensible defaults", which in this 
case, at least something that will work on the users system!
That being said:
> It think that it's a clearer procedure to:
> 
> 1) Edit matplotlibrc to set the intended defaults for the
> installation-wide matplotlibrc.
> 2) python setup.py build install
> 3) Possibly customize a ~/.matplotlib/matplotlibrc for a given user.
Fair enough, let's just make sure that this procedure is well outlined 
in the docs. There are enough questions here making it clear that it's 
not clear from the docs that EVERYONE should at least examine their 
.matplotlibrc when installing.
Another couple thoughts:
1) I'm wondering if there's a way to pre-define different defaults for 
different platforms. For example, I built an OS-X installer that doesn't 
support GTK, but the .matplotlibrc still had GtkAgg as the default. Yes, 
I could have edited the .matplotlib rc in my installer, but I'd have to 
do that each time I built a new one. It would be nice to have something 
in CVS that just worked.
2) Perhaps we could make the processing of matplotlibrc smarter. For 
example: if numarray is specified, but not installed, and Numeric is, 
it could roll over to Numeric. Same thing with back-ends. Of course, 
this kind of breaks the "explicit is better than implicit" rule, but it 
would greatly improve the "It just works" qualities of MPL.
-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...

Brian Donovan wrote:
> Dr. Whitaker,
>
> Thank you for helping me with this. My point of confusion is what 
> should nx and ny contain when they are sent into the transform_scalar 
> function:
>
>
Brian: nx and ny define the resolution of the transformed grid - you 
should choose them so that the grid spacing on the transformed grid is 
at least as fine as the original lat/lon grid.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Chris Barker wrote:
> Robert Kern wrote:
> 
>> What's the value of the option "numerix" in your matplotlibrc? If you
>> want to use Numeric, then it should look like this:
>>
>> numerix : Numeric # Numeric or numarray
>>
>> For the most part, this is a run-time setting rather than a build-time
>> setting, so it shouldn't be set by setup.py.
> 
> Well, yes and no. setup.py does a nice job of figuring out what is on
> the system, and building an MPL that works with the components that are
> installed. After that, however, it installs a generic .matplotlibrc
> file. Is is just too much of a PITA to have setup.py build a custom
> .matplotlibrc that reflects the just-built matplotlib?
It can be. Customizing the distutils build process is always a very
fragile thing and should be avoided whenever possible.
> Numeric-numarray is one issue, default back end is the other, and I'm
> sure there are others.
Since one can have both Numeric and numarray enabled for numerix and
certainly more than one backend built, the user still has to edit the
matplotlibrc to specify their choice. It think that it's a clearer
procedure to:
1) Edit matplotlibrc to set the intended defaults for the
installation-wide matplotlibrc.
2) python setup.py build install
3) Possibly customize a ~/.matplotlib/matplotlibrc for a given user.
It's clear. It works in every environment. It works for every
customization one might want to do (i.e. for things that can't be
determined at build-time, like the fonts one wants as default).
-- 
Robert Kern
rk...@uc...
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
 -- Richard Harter

Dr. Kienzle,
Did you get my message before about improving the pcolor function by 
changing the way the "verts" array is created? Although I couldn't get it to 
work on my machine (maybe because I'm not actually re-building it, I'm just 
editing the source file and then exiting and restarting) someone else on the 
mailing list said he didn't have problems. If you can, make those changes 
and report back to me on how wll they work.
Also, is it just the "pcolor" function that is too slow or is the "draw" 
function too slow as well?
-Alex Mont
----- Original Message ----- 
From: "Paul Kienzle" <pki...@ja...>
To: "John Hunter" <jdh...@ni...>
Cc: "Alexander Mont" <ale...@co...>; 
<mat...@li...>
Sent: Thursday, November 03, 2005 11:10 AM
Subject: Re: [Matplotlib-users] Memory leak with pcolor
> On Tue, Nov 01, 2005 at 09:41:35PM -0600, John Hunter wrote:
>> >>>>> "Alexander" == Alexander Mont <ale...@co...> writes:
>>
>> Alexander> Thanks for your advice with installing matplotlib on
>> Alexander> cygwin. I downloaded and installed the windows binaries
>> Alexander> and it worked. Anyway, the reason that I didn't want
>> Alexander> to use binaries in the first place was because I wanted
>> Alexander> to modify the matplotilb source code. But it seems like
>> Alexander> even with the binaries, if I change the source code
>> Alexander> then it will still affect the operation of the program
>> Alexander> when I run it, which is what I want.
>>
>> Alexander> In particular, I am looking to speed up the pcolor()
>> Alexander> function because it runs exceedingly slow with large
>> Alexander> mesh sizes. I believe the reason it is running slow is
>> Alexander> because of a memory leak. When I do the following:
>>
>> Alexander> from pylab import * n=200
>> Alexander> [x,y]=meshgrid(arange(n+1)*1./n,arange(n+1)*1./n)
>> Alexander> z=sin(x**2 + y**2)
>>
>> Alexander> and then do
>>
>> Alexander> pcolor(x,y,z)
>>
>> Alexander> repeatedly, the memory usage increases by about 15 MB
>> Alexander> each time, and it runs progressively slower.each
>>
>> At least with matplotlib CVS (and I don't think it's a CVS vs 0.84
>> issue) the memory consumption is rock solid with your example (see
>> below for my test script). What is your default "hold" setting in rc?
>> If True, you will be overlaying plots and will get the behavior you
>> describe. In the example below, I make sure to "close" the figure
>> each time -- a plain clear with clf should suffice though. My guess
>> is that you are repeatedly calling pcolor with hold : True and are
>> simply overlaying umpteen pcolors (to test for this, print the length
>> of the collections list
>>
>> ax = gca()
>> print len(ax.collections)
>>
>> if this length is growing, you've found your problem. A simple
>>
>> pcolor(x,y,z,hold=False)
>>
>> should suffice.
>>
>> You can also change the default hold setting in your config file
>> http://matplotlib.sf.net/matplotlibrc
>>
>> JDH
>
> I can confirm that memory leaks indeed are not a problem with a CVS build
> on Debian. I can't seem to restore the pre-built Debian stable 0.82 so
> I haven't tested it.
>
> However, the problem is still that pcolor is too slow to use it
> interactively on a plot with a half-dozen 200x608 warped grids, even
> with shading='flat' and no antialiasing.
>
> Would you consider accepting a 'structured grid' as a primitive patch
> type? What consequence will this have for your various backends?
> Presumably someone will want triangular meshes as well if they are
> doing serious FEM work.
>
> I created a prototype app using OpenGL and quad strips. The performance
> with this is acceptable, but I need a lot more 2D graphing features.
> I would much rather make an existing product better than rewrite from
> scratch.
>
> In my particular case the grid warping function can be expressed
> analytically. Is it reasonable to consider warping a 2D image directly
> using an AGG filter function? Could this be embedded in an existing
> matplotlib graph, above some objects and below others?
>
> Thanks in advance,
>
> Paul Kienzle
> pki...@ni...
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Robert Kern wrote:
> What's the value of the option "numerix" in your matplotlibrc? If you
> want to use Numeric, then it should look like this:
> 
> numerix : Numeric # Numeric or numarray
> 
> For the most part, this is a run-time setting rather than a build-time
> setting, so it shouldn't be set by setup.py.
Well, yes and no. setup.py does a nice job of figuring out what is on 
the system, and building an MPL that works with the components that are 
installed. After that, however, it installs a generic .matplotlibrc 
file. Is is just too much of a PITA to have setup.py build a custom 
.matplotlibrc that reflects the just-built matplotlib?
Numeric-numarray is one issue, default back end is the other, and I'm 
sure there are others.
For that matter, it would be nice if some of the defaults were better 
tuned for platform: gtk is not the best choice for OS-X for example. 
speaking of which, how is the Cocoa back-end doing?
-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...

Dr. Whitaker,
 Thank you for helping me with this. My point of confusion is what 
should nx and ny contain when they are sent into the transform_scalar 
function:
>> xydata = m.transform_scalar(latlondata,lons,lats,nx,ny)
Thanks,
Brian
On Nov 2, 2005, at 9:32 PM, Jeff Whitaker wrote:
> Jeff Whitaker wrote:
>> Brian Donovan wrote:
>>> basemap folks,
>>>
>>> I'm trying to understand how the transform_scalar function 
>>> works. What are the units of the native projection grid and how 
>>> are they determined? I'm trying to scale a scalar data field and 
>>> overlay it on the map. Does the location of the origin matter 
>>> when I do this? To be clear here's what I'm trying to do.
>>>
>>> 1) I have a Numeric array with a scalar field
>>> 2) I want to overlay this onto a map projection
>>> 3) The data is slightly larger than the map area (in terms of 
>>> latitude and longitude)
>>> 4) From the examples it seams like transform_scalar and then 
>>> imshow can be used to show the data
>>> 5) I can't seem to use transform_scalar properly
>>>
>>> Thanks is advance,
>>>
>>> Brian
>> Brian: I'm going to assume your data (latlondata) is on a 
>> latitude/longitude grid with latitudes lats and longitude lons, 
>> and you have created a Basemap instance for your projection 
>> regrion (m). Then, to create a nx by ny grid to overlay on the 
>> map, all you need is
>>
>> xydata = m.transform_scalar(latlondata,lons,lats,nx,ny)
>>
>> you can then overlay xydata on the map with
>>
>> im = x.imshow(xydata, cm.jet)
>>
>> You only need to do this to plot the data with imshow - with 
>> pcolor or contourf you can plot the data on the original lat/lon 
>> grid using
>>
>> x,y = m(lons,lons)
>>
>> cs = m.contourf(x,y,latlondata,20,cmap=cm.jet)
>>
>> or
>>
>> im = m.pcolor(x,y,latlondata,shading='flat',cmap=cm.jet)
>>
>> HTH,
>>
>> -Jeff
>>
>>
> Brian:
>
> One correction -
>
> lons and lats are 1-d arrays describing the lat/lon grid, so 
> instead of
>
> x,y = m(lons,lats)
>
> you'll need
>
> lons, lats = pylab.meshgrid(lons, lats)
> x, y = m(lons, lats)
>
> -Jeff
>
> -- 
> Jeffrey S. Whitaker Phone : (303)497-6313
> Meteorologist FAX : (303)497-6449
> NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
> 325 Broadway Office : Skaggs Research Cntr 1D-124
> Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tue, Nov 01, 2005 at 09:41:35PM -0600, John Hunter wrote:
> >>>>> "Alexander" == Alexander Mont <ale...@co...> writes:
> 
> Alexander> Thanks for your advice with installing matplotlib on
> Alexander> cygwin. I downloaded and installed the windows binaries
> Alexander> and it worked. Anyway, the reason that I didn't want
> Alexander> to use binaries in the first place was because I wanted
> Alexander> to modify the matplotilb source code. But it seems like
> Alexander> even with the binaries, if I change the source code
> Alexander> then it will still affect the operation of the program
> Alexander> when I run it, which is what I want.
> 
> Alexander> In particular, I am looking to speed up the pcolor()
> Alexander> function because it runs exceedingly slow with large
> Alexander> mesh sizes. I believe the reason it is running slow is
> Alexander> because of a memory leak. When I do the following:
> 
> Alexander> from pylab import * n=200
> Alexander> [x,y]=meshgrid(arange(n+1)*1./n,arange(n+1)*1./n)
> Alexander> z=sin(x**2 + y**2)
> 
> Alexander> and then do
> 
> Alexander> pcolor(x,y,z)
> 
> Alexander> repeatedly, the memory usage increases by about 15 MB
> Alexander> each time, and it runs progressively slower.each
> 
> At least with matplotlib CVS (and I don't think it's a CVS vs 0.84
> issue) the memory consumption is rock solid with your example (see
> below for my test script). What is your default "hold" setting in rc?
> If True, you will be overlaying plots and will get the behavior you
> describe. In the example below, I make sure to "close" the figure
> each time -- a plain clear with clf should suffice though. My guess
> is that you are repeatedly calling pcolor with hold : True and are
> simply overlaying umpteen pcolors (to test for this, print the length
> of the collections list
> 
> ax = gca()
> print len(ax.collections)
> 
> if this length is growing, you've found your problem. A simple
> 
> pcolor(x,y,z,hold=False)
> 
> should suffice.
> 
> You can also change the default hold setting in your config file
> http://matplotlib.sf.net/matplotlibrc
> 
> JDH
I can confirm that memory leaks indeed are not a problem with a CVS build
on Debian. I can't seem to restore the pre-built Debian stable 0.82 so 
I haven't tested it.
However, the problem is still that pcolor is too slow to use it
interactively on a plot with a half-dozen 200x608 warped grids, even
with shading='flat' and no antialiasing.
Would you consider accepting a 'structured grid' as a primitive patch
type? What consequence will this have for your various backends?
Presumably someone will want triangular meshes as well if they are
doing serious FEM work.
I created a prototype app using OpenGL and quad strips. The performance
with this is acceptable, but I need a lot more 2D graphing features.
I would much rather make an existing product better than rewrite from 
scratch.
In my particular case the grid warping function can be expressed
analytically. Is it reasonable to consider warping a 2D image directly
using an AGG filter function? Could this be embedded in an existing
matplotlib graph, above some objects and below others?
Thanks in advance,
Paul Kienzle
pki...@ni...

On 11/3/05, Chris Fonnesbeck <fon...@gm...> wrote:
>
> I'm not sure why it should be looking for numarray when it doesnt
> exist. Doesnt the setup.py file set this up?
Please ignore. I discovered .matplotlibrc ...
--
Chris Fonnesbeck
Atlanta, GA