matplotlib-users Mailing List for matplotlib

In http://matplotlib.sourceforge.net/tutorial.html
the following link is brocken :
http://matplotlib.sourceforge.net/pylab.html#-rc
(in "Customizing matplotlib" part)

therefore, it is difficult to get information about rc...

What does one have to install from the command line to fix this? I'm getting
the same error running the basemap examples, after installing matplotlib
0.90 via egg and basemap via installer, and numpy via source.

Traceback (most recent call last):
  File "simpletest.py", line 1, in <module>
    from matplotlib.toolkits.basemap import Basemap
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/toolkits/basemap/__init__.py",
line 1, in <module>
    from basemap import __doc__, __version__
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/matplotlib/toolkits/basemap/basemap.py",
line 1, in <module>
    from matplotlib import rcParams
ImportError: cannot import name rcParams




Chris Fonnesbeck wrote:
> 
> Christopher Fonnesbeck <fonnesbeck@...> writes:
> 
>> 
>> On recent builds of matplotlib (svn and 0.90) I encounter an import error
>> when
>> trying to import pylab:
>> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
>> /matplotlib/numerix/__init__.py",
>> line 20, in <module>
>>     from matplotlib import rcParams, verbose
> ...
>> ImportError: cannot import name rcParams
>> 
> 
> Update: Actually this appears to be related to the bdist_mpkg module that
> I used
> to build the metapackage. Installing from the command line completely
> fixes the
> problem. Not sure how to fix this though.
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://www.nabble.com/rcParams-is-missing-tf3653185.html#a10242129
Sent from the matplotlib - users mailing list archive at Nabble.com.

Darren Dale wrote:
> On Monday 30 April 2007 02:31:59 pm Eric Firing wrote:
>> One way this could happen is if the .matplotlib directory exists but is
>> not writable; such a case would give the error traceback you see with
>> little clue as to what and where the problem really is.  So, __init__.py
>> certainly could be improved.  (Offhand, I don't even know why the
>> existence of such a writable config directory should be required.)
> 
> It is writeable because we use it for caching fonts and tex-related stuff. 
> Don't most programs require a writeable config directory? My home directory 
> is filled with them.

This occurred to me a couple minutes after I hit "send".  Yes, this sort 
of thing is common, but I wouldn't say "most programs"; and it is 
exactly the sort of thing that can cause trouble and confusion when 
running a program from something like a cron job or modpython instead of 
the usual command line.

Eric

   Hi Eric,

Thanks for your response.

> One way this could happen is if the .matplotlib directory exists  
> but is not writable; such a case would give the error traceback you  
> see with little clue as to what and where the problem really is.   
> So, __init__.py certainly could be improved.  (Offhand, I don't  
> even know why the existence of such a writable config directory  
> should be required.)

I'm pretty sure the directory is writeable, as my default settings  
are 755 for new files/dirs (umask=022). Unless, indeed, some process  
changed that. But when I looked after the crash, the permissions were  
writeable/executable.
And yes, I was somewhat surprised by the writeable requirement of the  
config dir as well.

> In the meantime, to solve your particular problem: my guess is that  
> when you run a script as a daemon, and it runs more scripts, the  
> environment is not what you think it is (or what it is when you run  
> interactively), so __init__.py is not looking where you think it  
> is.  Either that, or the uid/gid of the script are not the same as  
> yours, so the script can't write to your .matplotlib directory even  
> though you can.  Instead of ignoring the _is_writable(p) result,  
> you might want to try printing out os.path.abspath(p) to verify  
> where p really is.

The OSError does show it to be the correct directory, unless there's  
a way to fool that traceback. Also, I haven't set MATPLOTLIBRC  
anywhere, so I guess it picks up .matplotlibrc in my HOME (which I  
assume is set automatically by the system, even for daemon scripts).  
I'll put in the os.path.abspath output anyway.
I wouldn't know 100% about the uid/gid, but everything is done under  
my user account (I don't have access to any other account on this  
system anyway), so might be hard to have that changed).

Thanks again for the response.

Cheers,

   Evert


>>    Hi all,
>> I recently run into a problem with the .matplotlib directory. I  
>> run a  script as a daemon, that in its turn runs several scripts  
>> to create  graphs (often the same script with different input  
>> parameters),  dependent on an outside trigger. Recently, I found  
>> that these script  crashed with an OSError during the 'import  
>> matplotlib' phase, at the  point where it tries to check that  
>> the .matplotlib directory is  writeable. The exact traceback is  
>> appended below.
>> Searching on the mailing list, I found someone had the same  
>> problem  almost a year ago ( http://sourceforge.net/mailarchive/ 
>> message.php? msg_id=44964AD1.605%40yahoo.com ), but it appears  
>> that that post  doesn't have a response.
>> A wider search resulted in this post, http://osdir.com/ml/ 
>> python.peak/ 2006-06/msg00019.html , where the response suggests  
>> these problems  are caused by all the things mpl does in its  
>> __init__ file.
>> A few notes on my setup:
>> - the .matplotlib is a symbolic link to a .python/matplotlib   
>> directory, since I'd like to keep my python resources together   
>> (eg, .python also contains an ipython directory). I've currently   
>> changed the symlink to a proper directory, but haven't had a  
>> chance  to test this new setup. Anyway, afaik, symlinks should  
>> work properly
>> - the scripts that are run from the daemon script, are run in the   
>> background, and quite often shortly after each other. Whether  
>> that  creates a deadlock situation or something, I don't know.  
>> Obviously,  I'm using a non-interactive backend, agg in this case.
>> - the problem only showed after I upgraded from mpl version 0.87  
>> to 0.9.
>> - interactively, everything runs fine.
>> - everything runs under a locally installed python, which is  
>> called  with the appropriate path from the script
>> - python version 2.4.4, numpy version 1.0
>> Does anyone have a suggestion what went wrong, and how to  
>> properly  fix all this? As a temporary measure, I now ignore the  
>> _is_writeable (p) result in __init__.py (the directory, and  
>> therefore the symlink,  were/are writeable when this occurred, as  
>> far as I can tell).
>> I like mpl very much, but this problem may render it much less  
>> usable  for me; a temporary fix would be fine for now, but it  
>> actually feels  like a bug to me.
>> Thanks a lot,
>>    Evert
>> full traceback (note: replaced directories with ~)
>> Traceback (most recent call last):
>>    File "~/myscript.py", line 64, in ?
>>      sys.exit(main())
>>    File "~/myscript.py", line 59, in main
>>      return run(parser)
>>    File "~/myscript.py", line 27, in run
>>      sigmaclip=parser['sigmaclip'], invert=True, compass=True)
>>    File "~/python/modules/fitsimage/FITSImage_numpy.py", line 777,  
>> in  plot
>>      import matplotlib as mpl
>>    File "~/sw/lib/python2.4/site-packages/matplotlib/ 
>> __init__.py",  line 1019, in ?
>>      rcParams = rc_params()
>>    File "~/sw/lib/python2.4/site-packages/matplotlib/ 
>> __init__.py",  line 976, in rc_params
>>      fname = matplotlib_fname()
>>    File "~/sw/lib/python2.4/site-packages/matplotlib/ 
>> __init__.py",  line 922, in matplotlib_fname
>>      fname = os.path.join(get_configdir(), 'matplotlibrc')
>>    File "~/sw/lib/python2.4/site-packages/matplotlib/ 
>> __init__.py",  line 273, in wrapper
>>      ret = func(*args, **kwargs)
>>    File "~/sw/lib/python2.4/site-packages/matplotlib/ 
>> __init__.py",  line 329, in _get_configdir
>>      os.mkdir(p)
>> OSError: [Errno 17] File exists: '<...>/.matplotlib'

On Monday 30 April 2007 02:31:59 pm Eric Firing wrote:
> One way this could happen is if the .matplotlib directory exists but is
> not writable; such a case would give the error traceback you see with
> little clue as to what and where the problem really is.  So, __init__.py
> certainly could be improved.  (Offhand, I don't even know why the
> existence of such a writable config directory should be required.)

It is writeable because we use it for caching fonts and tex-related stuff. 
Don't most programs require a writeable config directory? My home directory 
is filled with them.

Darren

Try building it with g++. Generally you should be able to set
the env variable CC to g++ but I think distutils in python 2.3
does not look at the environment variables and you may need to tweak
python2.3/config/Makefile to use g++ instead of Sun's cc.
I may be wrong.
Later versions of python respect $CC.

Nadia Dencheva

Daniel Fan wrote:
> Hi, I am trying install matplotlib on a solaris
> machine. When I run 
> python setup.py build, I get the following error:
> 
> GTK requires pygtk
> GTKAgg requires pygtk
> TKAgg requires TkInter
> running build
> running build_py
> running build_ext
> building 'matplotlib._agg' extension
> cc -DNDEBUG -O -Iagg23/include -Isrc -Iswig 
> -I/usr/local/lang/python/2.3.2/include/python2.3 -c
> src/agg.cxx -o 
> build/temp.solaris-2.10-sun4u-2.3/src/agg.o
> cc: No input file specified, no output generated
> error: command 'cc' failed with exit status 1
> 
> How can there be no input file?
> 
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

One way this could happen is if the .matplotlib directory exists but is 
not writable; such a case would give the error traceback you see with 
little clue as to what and where the problem really is.  So, __init__.py 
certainly could be improved.  (Offhand, I don't even know why the 
existence of such a writable config directory should be required.)

In the meantime, to solve your particular problem: my guess is that when 
you run a script as a daemon, and it runs more scripts, the environment 
is not what you think it is (or what it is when you run interactively), 
so __init__.py is not looking where you think it is.  Either that, or 
the uid/gid of the script are not the same as yours, so the script can't 
write to your .matplotlib directory even though you can.  Instead of 
ignoring the _is_writable(p) result, you might want to try printing out 
os.path.abspath(p) to verify where p really is.

Eric

Evert Rol wrote:
>    Hi all,
> 
> I recently run into a problem with the .matplotlib directory. I run a  
> script as a daemon, that in its turn runs several scripts to create  
> graphs (often the same script with different input parameters),  
> dependent on an outside trigger. Recently, I found that these script  
> crashed with an OSError during the 'import matplotlib' phase, at the  
> point where it tries to check that the .matplotlib directory is  
> writeable. The exact traceback is appended below.
> 
> Searching on the mailing list, I found someone had the same problem  
> almost a year ago ( http://sourceforge.net/mailarchive/message.php? 
> msg_id=44964AD1.605%40yahoo.com ), but it appears that that post  
> doesn't have a response.
> A wider search resulted in this post, http://osdir.com/ml/python.peak/ 
> 2006-06/msg00019.html , where the response suggests these problems  
> are caused by all the things mpl does in its __init__ file.
> 
> A few notes on my setup:
> - the .matplotlib is a symbolic link to a .python/matplotlib  
> directory, since I'd like to keep my python resources together  
> (eg, .python also contains an ipython directory). I've currently  
> changed the symlink to a proper directory, but haven't had a chance  
> to test this new setup. Anyway, afaik, symlinks should work properly
> - the scripts that are run from the daemon script, are run in the  
> background, and quite often shortly after each other. Whether that  
> creates a deadlock situation or something, I don't know. Obviously,  
> I'm using a non-interactive backend, agg in this case.
> - the problem only showed after I upgraded from mpl version 0.87 to 0.9.
> - interactively, everything runs fine.
> - everything runs under a locally installed python, which is called  
> with the appropriate path from the script
> - python version 2.4.4, numpy version 1.0
> 
> 
> Does anyone have a suggestion what went wrong, and how to properly  
> fix all this? As a temporary measure, I now ignore the _is_writeable 
> (p) result in __init__.py (the directory, and therefore the symlink,  
> were/are writeable when this occurred, as far as I can tell).
> 
> I like mpl very much, but this problem may render it much less usable  
> for me; a temporary fix would be fine for now, but it actually feels  
> like a bug to me.
> 
> Thanks a lot,
> 
>    Evert
> 
> 
> full traceback (note: replaced directories with ~)
> 
> Traceback (most recent call last):
>    File "~/myscript.py", line 64, in ?
>      sys.exit(main())
>    File "~/myscript.py", line 59, in main
>      return run(parser)
>    File "~/myscript.py", line 27, in run
>      sigmaclip=parser['sigmaclip'], invert=True, compass=True)
>    File "~/python/modules/fitsimage/FITSImage_numpy.py", line 777, in  
> plot
>      import matplotlib as mpl
>    File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
> line 1019, in ?
>      rcParams = rc_params()
>    File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
> line 976, in rc_params
>      fname = matplotlib_fname()
>    File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
> line 922, in matplotlib_fname
>      fname = os.path.join(get_configdir(), 'matplotlibrc')
>    File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
> line 273, in wrapper
>      ret = func(*args, **kwargs)
>    File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
> line 329, in _get_configdir
>      os.mkdir(p)
> OSError: [Errno 17] File exists: '<...>/.matplotlib'
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Scott,

In svn, barh does accept the 'log' kwarg via **kwargs, and your example 
works correctly.  Here is the relevant CHANGELOG entry, after 0.90 was 
released:

2007-03-03 Change barh to take a kwargs dict and pass it to bar.
            Fixes sf bug #1669506.


I think it was just a matter of changing the barh signature to:

     def barh(self, bottom, width, height=0.8, left=None, **kwargs):

but I haven't looked back at the svn records to check that.

Eric

Scott Sinclair wrote:
> Hi,
>  
> The following code fails for me with matplotlib-0.90.0 --
>  
> ---------------------------------------------------
> import pylab as pl
>  
> x = pl.randn(1000)
>  
> pl.hist(x, orientation='horizontal')
>  
> pl.show()
> ---------------------------------------------------
>  
> This is because Axes.barh() [called by Axes.hist() in axes.py] doesn't 
> accept the keyword argument 'log'. The attached patch fixes the problem 
> for my purposes (linear scaling of the axes) but obviously fails to 
> scale the bin count axis correctly if hist() is called with log=True 
> i.e. pl.hist(x, orientation='horizontal', log=True).
>  
> It appears that this is still the case in the latest svn version of axes.py.
>  
> Cheers,
> Scott
>  
> 
> Please find our Email Disclaimer here-->: _ 
> http://www.ukzn.ac.za/disclaimer <http://www.ukzn.ac.za/disclaimer/>_
> 
> 
> ------------------------------------------------------------------------
> 
> --- axes.py	2007-01-22 18:57:58.000000000 +0200
> +++ patched_axes.py	2007-04-30 15:12:15.921875000 +0200
> @@ -4462,7 +4462,7 @@
>          if width is None: width = 0.9*(bins[1]-bins[0])
>          if orientation == 'horizontal':
>              patches = self.barh(bins, n, height=width, left=bottom,
> -                                align=align, log=log)
> +                                align=align)
>          elif orientation == 'vertical':
>              patches = self.bar(bins, n, width=width, bottom=bottom,
>                                  align=align, log=log)
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

   Hi all,

I recently run into a problem with the .matplotlib directory. I run a  
script as a daemon, that in its turn runs several scripts to create  
graphs (often the same script with different input parameters),  
dependent on an outside trigger. Recently, I found that these script  
crashed with an OSError during the 'import matplotlib' phase, at the  
point where it tries to check that the .matplotlib directory is  
writeable. The exact traceback is appended below.

Searching on the mailing list, I found someone had the same problem  
almost a year ago ( http://sourceforge.net/mailarchive/message.php? 
msg_id=44964AD1.605%40yahoo.com ), but it appears that that post  
doesn't have a response.
A wider search resulted in this post, http://osdir.com/ml/python.peak/ 
2006-06/msg00019.html , where the response suggests these problems  
are caused by all the things mpl does in its __init__ file.

A few notes on my setup:
- the .matplotlib is a symbolic link to a .python/matplotlib  
directory, since I'd like to keep my python resources together  
(eg, .python also contains an ipython directory). I've currently  
changed the symlink to a proper directory, but haven't had a chance  
to test this new setup. Anyway, afaik, symlinks should work properly
- the scripts that are run from the daemon script, are run in the  
background, and quite often shortly after each other. Whether that  
creates a deadlock situation or something, I don't know. Obviously,  
I'm using a non-interactive backend, agg in this case.
- the problem only showed after I upgraded from mpl version 0.87 to 0.9.
- interactively, everything runs fine.
- everything runs under a locally installed python, which is called  
with the appropriate path from the script
- python version 2.4.4, numpy version 1.0


Does anyone have a suggestion what went wrong, and how to properly  
fix all this? As a temporary measure, I now ignore the _is_writeable 
(p) result in __init__.py (the directory, and therefore the symlink,  
were/are writeable when this occurred, as far as I can tell).

I like mpl very much, but this problem may render it much less usable  
for me; a temporary fix would be fine for now, but it actually feels  
like a bug to me.

Thanks a lot,

   Evert


full traceback (note: replaced directories with ~)

Traceback (most recent call last):
   File "~/myscript.py", line 64, in ?
     sys.exit(main())
   File "~/myscript.py", line 59, in main
     return run(parser)
   File "~/myscript.py", line 27, in run
     sigmaclip=parser['sigmaclip'], invert=True, compass=True)
   File "~/python/modules/fitsimage/FITSImage_numpy.py", line 777, in  
plot
     import matplotlib as mpl
   File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
line 1019, in ?
     rcParams = rc_params()
   File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
line 976, in rc_params
     fname = matplotlib_fname()
   File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
line 922, in matplotlib_fname
     fname = os.path.join(get_configdir(), 'matplotlibrc')
   File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
line 273, in wrapper
     ret = func(*args, **kwargs)
   File "~/sw/lib/python2.4/site-packages/matplotlib/__init__.py",  
line 329, in _get_configdir
     os.mkdir(p)
OSError: [Errno 17] File exists: '<...>/.matplotlib'

--- axes.py	2007-01-22 18:57:58.000000000 +0200
+++ patched_axes.py	2007-04-30 15:12:15.921875000 +0200
@@ -4462,7 +4462,7 @@
         if width is None: width = 0.9*(bins[1]-bins[0])
         if orientation == 'horizontal':
             patches = self.barh(bins, n, height=width, left=bottom,
-                                align=align, log=log)
+                                align=align)
         elif orientation == 'vertical':
             patches = self.bar(bins, n, width=width, bottom=bottom,
                                 align=align, log=log)

On 4/30/07, Gonzalo A. de la Vega <gad...@gm...> wrote:
> Hi all,
> I'm trying to embed a polar plot into a glade gui. I modified the
> mpl_with_glade.py example script to have something to start with. No
> problems with normal plot, but when I try to do polar plot, it fails with
> the following:

Comment out the SpanSelector code -- this is using a matplotlib widget
that assumes separable axes, which polar does not have.

JDH

Claudio <cla...@ac...> writes:

> Is there any way i can handle the size (without having to actually
> modify the whole system through config file)?

Yes, the size keyword:

> xticks(ind, colors.keys())

xticks(ind, colors.keys(), size='smaller')

The possible values of size are listed at
http://matplotlib.sourceforge.net/fonts.html
(see font.size).

-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hello.
I'm writing for a question about the bar() object. My problem is that I
have to write long labels to the ticks to indicate the bins' meaning but
they are overlapping one onto another. Is there any way i can handle the
size (without having to actually modify the whole system through config
file)? I paste the code I'm using:

ind = arange(len(colors.keys()))
bar(ind, colorpie, width=0.8)
grid(True)
ylabel('good categorizations')
xticks(ind, colors.keys())
savefig(results+'cate_pie.eps')

TIA

claudio martella
-- 
Claudio Martella
cla...@ac...
MSN: cla...@ho...
SKYPE: thefly_pd

Hi all,

I've got the latest version of matplotlib (0.90) installed on my mac  
with the latest scipy and numpy. I'm trying to use matplotlib's 3D  
plotting functionality interactively from ipython on OS X (Intel Mac)  
with the TkAgg backend. Regular 2D plotting works just fine, but when  
I create an Axes3D instance using a pylab.figure instance (following  
the Scipy cookbook mplot3D page), as soon as  I click in the Tk  
window a raft of error messages pops up in the ipython console. There  
seem to be several of the following errors occurring wherever matrix  
multiplication is involved:

   File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ 
python2.4/site-packages/matplotlib/proj3d.py", line 185, in  
proj_transform_vec
     vecw = nx.matrixmultiply(M,vec)
TypeError: unsupported operand type(s) for *: 'NoneType' and 'float'
Exception in Tkinter callback

The stack traces for these errors are very long, so I haven't  
included them. Am I missing some simple configuration detail to get  
3D plotting working?

Thanks,
Aaron

ZnJvbSBweWxhYiBpbXBvcnQgKgoKeD1yYW5kKDEwMCkKeT1yYW5kKDEwMCkKCmF4MT1zdWJwbG90
KDIyMSkKYXgxLnBsb3QoMTAwKnJhbmQoKSp4LDEwMCpyYW5kKCkqeSwnKycpCkR4PWFicyhheDEu
Z2V0X3hsaW0oKVswXS1heDEuZ2V0X3hsaW0oKVsxXSkKRHk9YWJzKGF4MS5nZXRfeWxpbSgpWzBd
LWF4MS5nZXRfeWxpbSgpWzFdKQpheDEuc2V0X2FzcGVjdCgwLjMzMypEeC9EeSkKYXgxLnNldF94
dGlja2xhYmVscyhbXSkKCmF4Mj1zdWJwbG90KDI2NCkKYXgyLnBsb3QoMTAwKnJhbmQoKSp4LDEw
MCpyYW5kKCkqeSwnKycpCkR4PWFicyhheDIuZ2V0X3hsaW0oKVswXS1heDIuZ2V0X3hsaW0oKVsx
XSkKRHk9YWJzKGF4Mi5nZXRfeWxpbSgpWzBdLWF4Mi5nZXRfeWxpbSgpWzFdKQpheDIuc2V0X2Fz
cGVjdChEeC9EeSkKYXgyLnNldF94dGlja2xhYmVscyhbXSkKCmF4Mz1zdWJwbG90KDIyMykKYXgz
LnBsb3QoMTAwKnJhbmQoKSp4LDEwMCpyYW5kKCkqeSwnKycpCkR4PWFicyhheDMuZ2V0X3hsaW0o
KVswXS1heDMuZ2V0X3hsaW0oKVsxXSkKRHk9YWJzKGF4My5nZXRfeWxpbSgpWzBdLWF4My5nZXRf
eWxpbSgpWzFdKQpheDMuc2V0X2FzcGVjdCgwLjMzMypEeC9EeSkKCmF4ND1zdWJwbG90KDIsNiwx
MCkKYXg0LnBsb3QoMTAwKnJhbmQoKSp4LDEwMCpyYW5kKCkqeSwnKycpCkR4PWFicyhheDQuZ2V0
X3hsaW0oKVswXS1heDQuZ2V0X3hsaW0oKVsxXSkKRHk9YWJzKGF4NC5nZXRfeWxpbSgpWzBdLWF4
NC5nZXRfeWxpbSgpWzFdKQpheDQuc2V0X2FzcGVjdChEeC9EeSkKCnNob3coKQ==

Maybe you could be more precise, it's difficult to guess!

Maybe you just want to do something similar to the anim.py example?
Maybe you want to build an bigger application, you should look at embedding
in wxpython... cf wxmpl...

For data acquisition on the serial, maybe
http://pyserial.sourceforge.net/would help you.


On 4/26/07, Patrick McCavery <opt...@ro...> wrote:
>
> Hi Everyone
>
> I would like to create a live plot to plot data coming from a data port,
> such as a serial port.
>
> I am still very new to Matplotlib and a template to work from would
> really help.
>
> Any suggestions would be really appreciated.
>
> Thanks-Patrick
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi, I am trying install matplotlib on a solaris
machine. When I run 
python setup.py build, I get the following error:

GTK requires pygtk
GTKAgg requires pygtk
TKAgg requires TkInter
running build
running build_py
running build_ext
building 'matplotlib._agg' extension
cc -DNDEBUG -O -Iagg23/include -Isrc -Iswig 
-I/usr/local/lang/python/2.3.2/include/python2.3 -c
src/agg.cxx -o 
build/temp.solaris-2.10-sun4u-2.3/src/agg.o
cc: No input file specified, no output generated
error: command 'cc' failed with exit status 1

How can there be no input file?




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Hi,

I'd like to know if it is possible to control size of subplots let say
control the ratio between x and y axis in length units (not in units of x
and y). For example, I'd like to plot 2 graphics with one rectangular ratio
y:x 1:3 and the second squared 1:1.

example :

import pylab

x = pylab.nx.mlab.rand(10)
y = pylab.nx.mlab.rand(10)

ax=pylab.subplot(121)
ax.scatter(x,y)
#set_aspect is for x and y units not geometrical dimension of the subplot...
#ax.set_aspect(3)

pylab.subplot(122)
pylab.scatter(x,y)

pylab.show()

On Fri, 27 Apr 2007 23:22:04 +0100
  darkside <in....@gm...> wrote:
> 2007/4/27, John Hunter <jd...@gm...>:
>>
>> On 4/27/07, darkside <in....@gm...> wrote:
>> > hi everyone,
>> > I'm trying to solve a lineal differential equation 
>>system, and I,m
>> proving
>> > with the mlab.rk4 function.
>> > The problem I've found is that if the solution if a 
>>complex number, I
>> can't
>> > use this functin, because it doesn't accept complex 
>>number, and I can
>> only
>> > get the real case.
>> >
>> > Have anyone treat with this problem?
>> > What do you use to solve differential equation 
>>systems?
>>
>>
>> rk4 was something I wrote long ago to have a simple ODE 
>>integrator in
>> case scipy wasn't installed on my system.  You should be 
>>using the
>> scipy.integrate tools
> 
> 
> Thank you very much!!!
> 
> I used scipy.integrate tools, splitting complex and real 
>part of the
> equations, and it worked so good!!
> 
> I tried to use: In addition I have filed a ticket for a 
>complex ODE solver.
> http://projects.scipy.org/scipy/scipy/ticket/334
> 
> But I haven't been able to compile it. It returns a lot 
>of errors when I
> tried. I suposse that it's because of the fortran 
>compiler, but I don't
> know.

Please remove the lines in zvdemo beginning with line 121.
Rename zvdemo

mv zvdemo zvdemo.f

1. g77 -c zvdemo.f zvode.f
2. g77 -o test zvdemo.o zvode.o
3. ./test > test.out

HTH
        Nils

  

Ryan May wrote:
> Hi,
> 
> I'm looking into using matplotlib as the backend for doing visualization 
> for my dissertation work.  This would replace some existing Qt/OpenGL 
> code I've written (but isn't too extensible) for 2D plots of weather 
> radar data (think pcolor style plots).  I've been using matplotlib for 
> awhile for other projects, and love it, but it has the drawback that 
> it's interactive graphics are not all that quick (especially pcolor). 
> (Note: I know imshow is faster, but my data are on a polar grid.) I've 
> been spoiled by the speed of OpenGL graphics and the ease of interactive 
> data analysis, so I just can't go back.  Has anyone tried making an 
> OpenGL backend?  If not, can anyone think of any reason why it couldn't 
> be done, maybe using wx's GLCanvas?
> 
> Any comments, or starting points on where I could see how to go about 
> this would be _greatly_ appreciated.

I expect pcolor will be slow regardless of the backend.  Have you tried 
pcolormesh?  It is a much faster pcolor-workalike, but unfortunately it 
has a major bug.  If I remember correctly, alpha doesn't work right and 
resizing a window doesn't work right if some data are masked; things 
that should get erased, don't.  I tried to track it down once but got 
lost in Agg internals.  Anyway, try it and see if it is adequate for 
what you need to do now.

Eric

Ryan May wrote:
> Has anyone tried making an 
> OpenGL backend?  If not, can anyone think of any reason why it couldn't 
> be done, maybe using wx's GLCanvas?

I don't know enough about OpenGL, but I wonder if it would really help 
much, as much of the scaling, etc, it happening in MPL code anyway. It 
could be great for future stuff with more 3-d though.

VTK is worth a look for you, as well.

-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...

2007/4/27, John Hunter <jd...@gm...>:
>
> On 4/27/07, darkside <in....@gm...> wrote:
> > hi everyone,
> > I'm trying to solve a lineal differential equation system, and I,m
> proving
> > with the mlab.rk4 function.
> > The problem I've found is that if the solution if a complex number, I
> can't
> > use this functin, because it doesn't accept complex number, and I can
> only
> > get the real case.
> >
> > Have anyone treat with this problem?
> > What do you use to solve differential equation systems?
>
>
> rk4 was something I wrote long ago to have a simple ODE integrator in
> case scipy wasn't installed on my system.  You should be using the
> scipy.integrate tools


Thank you very much!!!

I used scipy.integrate tools, splitting complex and real part of the
equations, and it worked so good!!

I tried to use: In addition I have filed a ticket for a complex ODE solver.
http://projects.scipy.org/scipy/scipy/ticket/334

But I haven't been able to compile it. It returns a lot of errors when I
tried. I suposse that it's because of the fortran compiler, but I don't
know.

Hi,

I'm looking into using matplotlib as the backend for doing visualization 
for my dissertation work.  This would replace some existing Qt/OpenGL 
code I've written (but isn't too extensible) for 2D plots of weather 
radar data (think pcolor style plots).  I've been using matplotlib for 
awhile for other projects, and love it, but it has the drawback that 
it's interactive graphics are not all that quick (especially pcolor). 
(Note: I know imshow is faster, but my data are on a polar grid.) I've 
been spoiled by the speed of OpenGL graphics and the ease of interactive 
data analysis, so I just can't go back.  Has anyone tried making an 
OpenGL backend?  If not, can anyone think of any reason why it couldn't 
be done, maybe using wx's GLCanvas?

Any comments, or starting points on where I could see how to go about 
this would be _greatly_ appreciated.

Thanks,

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hello Andrew,

On Friday 27 April 2007 18:33, Andrew Straw wrote:
> It hasn't changed since rev 3131:
>
> $ svn info __init__.py | grep 'Rev'
> Revision: 3257
> Last Changed Rev: 3131

Thanks for you advice.
I asked because I thought that this __revision__ is the matplotlib.__revison__ 
that I get e.g. in IPython. That's why I thought it should be the revision of 
the whole project.
Just a remark - you can forget about it.

best regards,
Matthias 



> Matthias Michler wrote:
> > Hi devolopers,
> >
> > one small remark about the mpl svn. I recognized, that in the
> > file ./lib/matplotlib/__init__.py the actual revision is:
> > __revision__ = '$Revision: 3131 $'
> > and the svn info tells "Revision: 3257".
> >
> > best regards,
> > Matthias
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users

It hasn't changed since rev 3131:

$ svn info __init__.py | grep 'Rev'
Revision: 3257
Last Changed Rev: 3131

Matthias Michler wrote:
> Hi devolopers,
>
> one small remark about the mpl svn. I recognized, that in the 
> file ./lib/matplotlib/__init__.py the actual revision is: 
> __revision__ = '$Revision: 3131 $'
> and the svn info tells "Revision: 3257".
>
> best regards,
> Matthias   
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>