matplotlib-users Mailing List for matplotlib (Page 8)

On Sunday 12 August 2007 05:01:57 pm Angel Ezquerra Moreu wrote:
> > I would suggest not using the pylab interface. Try building off of one of
>
> the
>
> > embedding_in examples in
> > http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip.
>
> Thank you for the answer, Darren. However, could you explain a bit more in
> detail why is not a good idea to use the pylab interface? It is very simple
> and easy to use (I am a Matlab user as well) so it felt very natural to try
> to use it.
I guess there is no reason you can't do it with pylab after all, see 
animation_blit_qt4, for example. I think you would be better off using a gui 
timer/event handler like in the blit example.
Darren

On Sunday 12 August 2007 07:05:38 pm Xavier Gnata wrote:
> OK my matplotlibrc was out of date. Now it works but I have found
> another but playing with the sliders of the backend:
> As the log is quite long, here are only the most relevant parts :
[...]
> It looks like that the ranges of the sliders are checked in a wrong way.
> It may be due to numerical rounding issues.
Unfortunately I have my hands full at work, so I don't know when I will be 
able to look into this. I would need more information before I could start 
anyway: a simple script and a list of steps that reproduces the problem, and 
does it only occur with the qt4 backend.
Darren

Eugen Wintersberger <eug...@jk...>
writes:
> The first line is the printing of the ticklabel list before the
> pylab.show() command. The second after pylab.show(). Why the list
> contains 1 entry before and 7 (as is should) after pylab.show()?
I think matplotlib is deferring the creation of the tick labels because
for all it knows, you might be going to plot something that will cause
the axes to be rescaled and change the tick locations and labels.
> I would like to access the labels before the final show command in a
> script. But how is this possible with this behavior? 
You could set the tick positions and labels explicitly, or if you like
the default tick locator, add the following before getting the ticklabel
objects:
a.xaxis.get_major_locator().refresh()
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi there
 I have some problem with accessing ticklabels in a script (see
attachment). The output of the script looks pretty strange to me:
<a list of 1 Text ticklabel objects>
<a list of 7 Text ticklabel objects>
The first line is the printing of the ticklabel list before the
pylab.show() command. The second after pylab.show(). Why the list
contains 1 entry before and 7 (as is should) after pylab.show()?
I would like to access the labels before the final show command in a
script. But how is this possible with this behavior? 
Best regards 
 Eugen
-- 
--------------------------------------------
| |
| Dipl. Ing. Eugen Wintersberger |
| Department of semicondutor physics |
| University of Linz |
| Altenbergerstrasse 69 |
| A-4040 Linz |
| Austria |
| |
| Mobile.: +43 664 3112861 |
| Tel.: +43 732 2468 9605 |
| E-Mail.: eug...@jk... |
| Skype: eugen20056221 |
| ICQ: 214418739, nickname: thot |
| |
--------------------------------------------

Darren Dale wrote:
> On Saturday 11 August 2007 8:15:41 am Xavier Gnata wrote:
> 
>> Hi,
>>
>> Using pylab svn, the qt backend is broken.
>>
>> import pylab fails :
>>
>> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_qtagg.py
>> 11
>> 12 from backend_agg import FigureCanvasAgg
>> ---> 13 from backend_qt import qt, FigureManagerQT, FigureCanvasQT,\
>> 14 show, draw_if_interactive, backend_version, \
>> 15 NavigationToolbar2QT
>>
>> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_qt.py
>> 15 from matplotlib.widgets import SubplotTool
>> 16
>> ---> 17 import qt
>> 18
>> 19 backend_version = "0.9.1"
>>
>> ImportError: No module named qt
>> 
>
> That means you dont have PyQt-3 installed on your machine.
>
> 
>> If I replace import qt by import PyQt4
>> 
>
> dont!
>
> 
>> , I get another error : 
>> 
>
> If you want to use PyQt4, you should set your backend to qt4agg instead of 
> qtagg.
> 
OK my matplotlibrc was out of date. Now it works but I have found 
another but playing with the sliders of the backend:
As the log is quite long, here are only the most relevant parts :
imshow(a)
Out[7]: <matplotlib.image.AxesImage instance at 0xb262a8cc>
(play with the sliders of the qt4agg backend)
In [8]: 
---------------------------------------------------------------------------
exceptions.ValueError Python 2.4.4: 
/usr/bin/python
 Mon Aug 13 00:58:56 2007
A problem occured executing Python code. Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_qt4.py in 
funcleft(self=<matplotlib.backends.backend_qt4.SubplotToolQt object>, 
val=900)
/usr/lib/python2.4/site-packages/matplotlib/figure.py in 
update(self=<matplotlib.figure.SubplotParams instance>, 
left=0.90000000000000002, bottom=None, right=None, top=None, 
wspace=None, hspace=None)
 71 self._update_this('top', top)
 72 self._update_this('wspace', wspace)
 73 self._update_this('hspace', hspace)
 74
 75 def reset():
 76 self.left = thisleft
 77 self.right = thisright
 78 self.top = thistop
 79 self.bottom = thisbottom
 80 self.wspace = thiswspace
 81 self.hspace = thishspace
 82
 83 if self.validate:
 84 if self.left>=self.right:
 85 reset()
---> 86 raise ValueError('left cannot be >= right')
 global ValueError = undefined
 87
 88 if self.bottom>=self.top:
 89 reset()
 90 raise ValueError('bottom cannot be >= top')
 91
 92
 93
 94 def _update_this(self, s, val):
 95 if val is None:
 96 val = getattr(self, s, None)
 97 if val is None:
 98 key = 'figure.subplot.' + s
 99 val = rcParams[key]
 100
 101 setattr(self, s, val)
ValueError: left cannot be >= right
**********************************************************************
Oops, IPython crashed. We do our best to make it stable, but...
It looks like that the ranges of the sliders are checked in a wrong way. 
It may be due to numerical rounding issues.
Xavier
....

Also, after looking at the embedded_tk example, it seems that you end the
script with a tk.mainloop() which kind of defeats my whole purpose, as I
need the script to keep checking for changes on a file.
What it seems that I need is some why to trigger the gui loop, but also to
have an "event" be trigged every few seconds, and that event would be
responsible for checking if there is new data, reading the file, and
updating the plot if necessary.
Is there some way to accomplish something like this?
Thanks,
Angel
---------- Forwarded message ----------
From: Angel Ezquerra Moreu <ang...@gm...>
Date: Aug 12, 2007 11:01 PM
Subject: Re: [Matplotlib-users] Cannot maximize figure while script is
running
To: mat...@li...
> I would suggest not using the pylab interface. Try building off of one of
the
> embedding_in examples in
> http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip.
Thank you for the answer, Darren. However, could you explain a bit more in
detail why is not a good idea to use the pylab interface? It is very simple
and easy to use (I am a Matlab user as well) so it felt very natural to try
to use it.
Angel
P.S.- Thanks for the os.path.getmtime tip.

> I would suggest not using the pylab interface. Try building off of one of
the
> embedding_in examples in
> http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip.
Thank you for the answer, Darren. However, could you explain a bit more in
detail why is not a good idea to use the pylab interface? It is very simple
and easy to use (I am a Matlab user as well) so it felt very natural to try
to use it.
Angel
P.S.- Thanks for the os.path.getmtime tip.

On Sunday 12 August 2007 3:56:14 am Angel Ezquerra Moreu wrote:
> Hi,
>
> I want to make a small python script that monitors a text file and plots
> its contents. This script is meant to run in Windows. The file that is
> being monitored has one floating point number per line and new numbers can
> be appended to the end of the file at any moment by some external program.
>
> Therefore the script needs to keep reading the file and if new data is
> found, it should update the plot (a simple plot() command will do for now).
> To do so the script has an endless loop that tries to read new data and if
> it can it plots it and issues a pylab.draw() command.
>
> I got the script working, (based on the "anim.py" example from the
> Matplotlib web page: http://matplotlib.sourceforge.net/examples/anim.py).
> The script updates the plot correctly when new data is added to the file.
> However, the figure itself is not really functional. By that I mean that
> the figure cannot maximized while the script is running. It is not possible
> to change the zoom or use the toolbar either.
>
> The example script has the same problem (i.e. the figure cannot maximized),
> so I'd like to know if there is any way around this or if I should use
> something other than pylab instead.
I would suggest not using the pylab interface. Try building off of one of the 
embedding_in examples in 
http://matplotlib.sourceforge.net/matplotlib_examples_0.90.0.zip.
Also, rather than repeatedly reading your data file to determine when new data 
is available, I suggest using os.path.getmtime.
Darren

Hi,
I want to make a small python script that monitors a text file and plots its
contents. This script is meant to run in Windows. The file that is being
monitored has one floating point number per line and new numbers can be
appended to the end of the file at any moment by some external program.
Therefore the script needs to keep reading the file and if new data is
found, it should update the plot (a simple plot() command will do for now).
To do so the script has an endless loop that tries to read new data and if
it can it plots it and issues a pylab.draw() command.
I got the script working, (based on the "anim.py" example from the
Matplotlib web page: http://matplotlib.sourceforge.net/examples/anim.py).
The script updates the plot correctly when new data is added to the file.
However, the figure itself is not really functional. By that I mean that the
figure cannot maximized while the script is running. It is not possible to
change the zoom or use the toolbar either.
The example script has the same problem (i.e. the figure cannot maximized),
so I'd like to know if there is any way around this or if I should use
something other than pylab instead.
Thanks!
Angel

On Saturday 11 August 2007 8:15:41 am Xavier Gnata wrote:
> Hi,
>
> Using pylab svn, the qt backend is broken.
>
> import pylab fails :
>
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_qtagg.py
> 11
> 12 from backend_agg import FigureCanvasAgg
> ---> 13 from backend_qt import qt, FigureManagerQT, FigureCanvasQT,\
> 14 show, draw_if_interactive, backend_version, \
> 15 NavigationToolbar2QT
>
> /usr/lib/python2.4/site-packages/matplotlib/backends/backend_qt.py
> 15 from matplotlib.widgets import SubplotTool
> 16
> ---> 17 import qt
> 18
> 19 backend_version = "0.9.1"
>
> ImportError: No module named qt
That means you dont have PyQt-3 installed on your machine.
> If I replace import qt by import PyQt4
dont!
> , I get another error : 
If you want to use PyQt4, you should set your backend to qt4agg instead of 
qtagg.

Hi,
Using pylab svn, the qt backend is broken.
import pylab fails :
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_qtagg.py
 11
 12 from backend_agg import FigureCanvasAgg
---> 13 from backend_qt import qt, FigureManagerQT, FigureCanvasQT,\
 14 show, draw_if_interactive, backend_version, \
 15 NavigationToolbar2QT
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_qt.py
 15 from matplotlib.widgets import SubplotTool
 16
---> 17 import qt
 18
 19 backend_version = "0.9.1"
ImportError: No module named qt
If I replace import qt by import PyQt4, I get another error :
/usr/lib/python2.4/site-packages/matplotlib/backends/backend_qt.py
 22 DEBUG = False
 23
---> 24 cursord = {
 25 cursors.MOVE : qt.Qt.PointingHandCursor,
 26 cursors.HAND : qt.Qt.WaitCursor,
It is a well known problem ?
What could I do to help to debug that?
Xavier
-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gn...@ob...
############################################ 

Hi,
I have created a plot where I have time in minutes at the bottom x-axis. I
have another axis with clock-time (hh:mm) at the top x-axis. I use
SpanSelector to zoom in the x-axis only. Whenever I zoom in or zoom out on
the minute axis I would like to sync the hh:mm axis as well. I used xticks
= self.ax[0].xaxis.get_ticklocs() to get the tick locations on the minute
axis and then plot the labels at the corresponding tick locations on the
hh:mm axis. The behavior during zooms is not what I was expecting. When
the plot is first created the tick locations on both axes are correct and
they are as follows
0.0 07:51:08
50.0 08:41:08
100.0 09:31:08
150.0 10:21:08
200.0 11:11:08
250.0 12:01:08
300.0 12:51:08
After zoom in the reported tick locations are as follows
30.0 08:21:08
60.0 08:51:08
90.0 09:21:08
120.0 09:51:08
150.0 10:21:08
180.0 10:51:08
210.0 11:21:08
But the bottom minute axis shows 60, 90, 120, 150, 180. Because the span
starts at 31.5 minutes and ends at 185 minutes. Therefore, the bottom axis
does not draw the 30 and 210 ticks. However, get_ticklocs() gets the 30 and
210 min values and the hh:mm axis is drawn out of sync.
So now my question is: is there a method that only returns the tick
locations that are actually drawn on the plot?
Regards,
NG

3D plotting in mpl is unmaintained, so I don't recommend relying on it 
unless you can bring it up to date and maintain it.
After committing a bugfix to svn, the following works with svn mpl and 
does something like what you want (but might not work with whatever 
version of mpl you are using.)
----------------------------------
from pylab import *
from matplotlib import axes3d
N = 30
x = 0.9*rand(N)
y = 0.9*rand(N)
z = rand(N)
c = rand(N)
area = pi*(10 * rand(N))**2 # 0 to 10 point radiuses
fig = gcf()
ax3d = axes3d.Axes3D(fig)
plt = fig.axes.append(ax3d)
ax3d.scatter(x,y,z,s=area, marker='^', c=c)
show()
-----------------------------------------
A more general problem is that a 3D scatter plot is ambiguous--how do 
you know where a point really is in 3D? You would have to do something 
like mapping color to Z. Is that what you want to do?
Eric
william ratcliff wrote:
> Is there a way to choose the color map for doing scatter plots using 
> Axes3D? In the test_scatter() example in the class, there is a line 
> something like:
> 
> ax.scatter3D(xs,ys,zs, c='r')
> 
> I would like to plot points based on 3 dimensional coordinates specified 
> by xs,ys, zs, which works great. However, I would like to color the 
> points with a third array, for example, cs which would either specify an 
> index in a color map, or even just an intensity of a given color. Is 
> this possible within matplotlib?
> 
> Thanks,
> William
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

2007年8月10日, william ratcliff <wil...@gm...>:
>
> so it would be something like:
>
>
> c=numpy.array([[1,2,3],[0,0,4],[0,2,4]]), where the values in the array go
> from 0-255 and denote r,g,b values?
>
> Thanks!
I use floatting point values, don't know if integers work.
I thing that colormap could be used, but I really don't know, I do not use
them.
Matthieu

Is there a way to choose the color map for doing scatter plots using
Axes3D? In the test_scatter() example in the class, there is a line
something like:
ax.scatter3D(xs,ys,zs, c='r')
I would like to plot points based on 3 dimensional coordinates specified by
xs,ys, zs, which works great. However, I would like to color the points
with a third array, for example, cs which would either specify an index in a
color map, or even just an intensity of a given color. Is this possible
within matplotlib?
Thanks,
William

Hi Everyone,
I am trying to find a way of producing a graph in pylib and then
returning it as a graphic via a simple BaseHTTPRequestHandler
webserver.
I don't appear to be able to find any documentation on this, although
I am sure it must be possible to achieve this!
I know that I can produce a temporary file in pylib and then load it
and output it in BaseHTTPRequestHandler but I am looking to avoid this
unnecessary step!
Many thanks,
Alex

ok look like a missing font on my box. Will see...
Xavier
> I installed the necessary stuff in my LaTeX installation from here:
>
> http://www.unruh.de/DniQ/latex/unicode/
>
> and it's now working even when usetex is on.
>
> It would be great to figure out why it's broken for you.
>
> Do you get any error output from LaTeX?
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> 
>> I should clarify, I have this working with the TkAgg backend and 
>> "text.usetex : False". If "text.usetex : True", I can't confirm or deny 
>> whether that works since I don't have a proper LaTeX ucs.sty setup here 
>> to test with.
>>
>> As an aside, if you're looking to Gtk as a way around this, the Gtk 
>> backend uses the same rendering pipeline for text when text.usetex is 
>> True, so it likely will produce the same result.
>>
>> Cheers,
>> Mie
>>
>> Michael Droettboom wrote:
>> 
>>> Xavier Gnata wrote:
>>> 
>>>> With a = u"é" I get no error but also nothing as a title. No strange 
>>>> characters. Nothing.
>>>> 
>>> This is working for me with the latest svn version, as well as 0.90.1, 
>>> on Linux with Python 2.5 and Tcl/Tk 8.4.
>>>
>>> There are other things that could be going wrong. The encoding of 
>>> your terminal may not match your default encoding in your Python 
>>> interpreter. If you're using Linux, can you please send the output of:
>>>
>>> > locale
>>> > python -c "import locale; print locale.getpreferredencoding()"
>>>
>>> If all is working correctly, you should get the following in your 
>>> python interpreter:
>>>
>>> >>> a = u"é"
>>> >>> ord(a)
>>> 233
>>>
>>> If you're using an editor (i.e. not using pylab interactively), you'll 
>>> need to make sure that it is outputting in the correct encoding, and 
>>> respecting the
>>>
>>> # -*- coding: utf-8 -*-
>>>
>>> line. Recent versions of emacs do this, but I can't really speak for 
>>> others.
>>>
>>> I have attached a test script that works for me. It even includes 
>>> some Greek characters as Unicode which work if you select a Unicode 
>>> font with those characters.
>>>
>>> Cheers,
>>> Mike
>>> 
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 
-- 
############################################
Xavier Gnata
CRAL - Observatoire de Lyon
9, avenue Charles André
69561 Saint Genis Laval cedex
Phone: +33 4 78 86 85 28
Fax: +33 4 78 86 83 86
E-mail: gn...@ob...
############################################ 

hm, i was setting it after i imported pylab. You were right. I just
now tried calling matplotlib.use("Agg") just before import pylab, and
that did give me better results.
wxAgg did start leaking memory very quickly, and ps,svg, and pdf were
all holding constant - until i hit around loop number 440, at which
point they all started growing at about the same rate as the wxAgg was
-Luke
On 8/9/07, Eric Firing <ef...@ha...> wrote:
> Luke,
>
> Just to be sure: how are you selecting the backend?
>
> If you use the "matplotlib.use('Agg')" method, this must appear *before*
> importing pylab for the first time; it is something of a "gotcha" that
> if it appears after pylab has been imported it doesn't give you any clue
> that it is ineffective.
>
> Eric
>
>
> Luke Robison wrote:
> > I *am* able to see the same leak in 0.90.1 using Agg, Pdg, Ps, and
> > Svg with the same memory amount being leaked each time, so its
> > probably in matplotlib code, although I do not have the SVN sources to
> > check it there to see if it has been fixed there. I was originally
> > using the wxAgg backend, but during the batch job really all i needed
> > was the actual histogram numbers, so I looked through the code and
> > found matplotlib.mlab.hist which is all I really need, and doesn't
> > leak ;-).
> >
> > Thanks for the help,
> > Luke Robison
> >
> >
> > On 8/9/07, Michael Droettboom <md...@st...> wrote:
> >> There have been a number of memory leaks resolved since the 0.90.1
> >> release. However, there are still known memory leaks in all of the GUI
> >> backends, some of which are unfortunately just beyond easy reach of
> >> matplotlib. If this is an automated process and you only care about the
> >> file output, you could try using the "Agg", "Pdf", "Ps" or "Svg"
> >> backends, e.g.:
> >>
> >> import matplotlib
> >> matplotlib.use("Agg")
> >>
> >> I tried your script with both 0.90.1 and the latest svn, and I could
> >> reproduce your leak with the TkAgg backend, but not with the Agg backend.
> >>
> >> If you need a GUI, you may want to try using the latest svn version if
> >> you can. The leaks still exist there, but they are much smaller.
> >>
> >> BTW -- you can get the version of matplotlib with:
> >>
> >> >>> import matplotlib
> >> >>> matplotlib.__version__
> >> '0.90.1'
> >>
> >> Cheers,
> >> Mike
> >>
> >>
> >> Luke Robison wrote:
> >>> I'm writing a program that processes ~ 25,000 jobs and each iteration
> >>> draws a histogram and writes out some of the output. I let it run all
> >>> night and when I came back, python was filling up all my memory
> >>> (2Gigs) and was thrashing on and off of swap. I narrowed the problem
> >>> down to my calling of the hist() function, and was able to reproduce
> >>> it in the following code I copied from the mpl website.
> >>>
> >>> Am I not properly closing the figure somehow?
> >>> Has this issue already been addressed?
> >>>
> >>> I recently installed version 0.90.1 of matplotlib, although I don't
> >>> see any easy way to verify that version number from within python.
> >>>
> >>> -Luke Robison
> >>>
> >>>
> >>> Code:
> >>> -------------------
> >>> import os,time,sys
> >>> from pylab import *
> >>>
> >>> def report_memory(i):
> >>> pid = os.getpid()
> >>> a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
> >>> print i, ' ', a2[1],
> >>> return int(a2[1].split()[1])
> >>>
> >>> # take a memory snapshot on indStart and compare it with indEnd
> >>> indStart, indEnd = 100, 150
> >>> for i in range(indStart,indEnd):
> >>> ind = arange(100)
> >>> xx = rand(len(ind))
> >>>
> >>> figure(1)
> >>> hist(xx)
> >>> close(1)
> >>>
> >>> # wait a few cycles for memory usage to stabilize
> >>> if i==indStart: start = val
> >>> if i>indStart:
> >>> end = val
> >>> print 'Average memory consumed per loop: %1.4fk bytes' % \
> >>> ((end-start)/float(indEnd-indStart))
> >>>
> >>> -----------------
> >>>
> >>> Output:
> >>>
> >>>
> >>> python memtest.py
> >>>
> >>> Average memory consumed per loop: 0.0000k bytes
> >>> 102 39808 21991
> >>> Average memory consumed per loop: 0.0000k bytes
> >>> 103 39828 21991
> >>> Average memory consumed per loop: 0.0000k bytes
> >>> 104 39852 22024
> >>> Average memory consumed per loop: 0.6600k bytes
> >>> 105 39876 22024
> >>> Average memory consumed per loop: 0.6600k bytes
> >>> 106 39908 22024
> >>> Average memory consumed per loop: 0.6600k bytes
> >>> 107 39932 22024
> >>> Average memory consumed per loop: 0.6600k bytes
> >>> 108 39960 22024
> >>> Average memory consumed per loop: 0.6600k bytes
> >>> 109 39980 22057
> >>> Average memory consumed per loop: 1.3200k bytes
> >>> 110 40008 22057
> >>> Average memory consumed per loop: 1.3200k bytes
> >>> 111 40032 22057
> >>> Average memory consumed per loop: 1.3200k bytes
> >>> 112 40056 22057
> >>> Average memory consumed per loop: 1.3200k bytes
> >>> 113 40084 22057
> >>> Average memory consumed per loop: 1.3200k bytes
> >>> 114 40104 22090
> >>> Average memory consumed per loop: 1.9800k bytes
> >>> 115 40132 22090
> >>> Average memory consumed per loop: 1.9800k bytes
> >>> 116 40156 22090
> >>> Average memory consumed per loop: 1.9800k bytes
> >>> 117 40180 22090
> >>> Average memory consumed per loop: 1.9800k bytes
> >>> 118 40208 22090
> >>> Average memory consumed per loop: 1.9800k bytes
> >>> 119 40232 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 120 40256 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 121 40280 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 122 40304 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 123 40328 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 124 40356 22123
> >>> Average memory consumed per loop: 2.6400k bytes
> >>> 125 40380 22156
> >>> Average memory consumed per loop: 3.3000k bytes
> >>> 126 40404 22156
> >>> Average memory consumed per loop: 3.3000k bytes
> >>> 127 40428 22156
> >>> Average memory consumed per loop: 3.3000k bytes
> >>> 128 40452 22156
> >>> Average memory consumed per loop: 3.3000k bytes
> >>> 129 40476 22156
> >>> Average memory consumed per loop: 3.3000k bytes
> >>> 130 40500 22189
> >>> Average memory consumed per loop: 3.9600k bytes
> >>> 131 40528 22189
> >>> Average memory consumed per loop: 3.9600k bytes
> >>> 132 40548 22189
> >>> Average memory consumed per loop: 3.9600k bytes
> >>> 133 40576 22189
> >>> Average memory consumed per loop: 3.9600k bytes
> >>> 134 40596 22189
> >>> Average memory consumed per loop: 3.9600k bytes
> >>> 135 40624 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 136 40652 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 137 40676 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 138 40700 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 139 40724 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 140 40744 22222
> >>> Average memory consumed per loop: 4.6200k bytes
> >>> 141 40768 22255
> >>> Average memory consumed per loop: 5.2800k bytes
> >>> 142 40800 22255
> >>> Average memory consumed per loop: 5.2800k bytes
> >>> 143 40824 22255
> >>> Average memory consumed per loop: 5.2800k bytes
> >>> 144 40848 22255
> >>> Average memory consumed per loop: 5.2800k bytes
> >>> 145 40872 22255
> >>> Average memory consumed per loop: 5.2800k bytes
> >>> 146 40896 22288
> >>> Average memory consumed per loop: 5.9400k bytes
> >>> 147 40916 22288
> >>> Average memory consumed per loop: 5.9400k bytes
> >>> 148 40940 22288
> >>> Average memory consumed per loop: 5.9400k bytes
> >>> 149 40972 22288
> >>> Average memory consumed per loop: 5.9400k bytes
> >>>
> >>>
> >>> as you can see, the memory consumption is increasing each loop, and
> >>> furthermore, and an increasing rate :-(
> >>>
> >>> -------------------------------------------------------------------------
> >>> This SF.net email is sponsored by: Splunk Inc.
> >>> Still grepping through log files to find problems? Stop.
> >>> Now Search log events and configuration files using AJAX and a browser.
> >>> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >>> _______________________________________________
> >>> Matplotlib-users mailing list
> >>> Mat...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >>
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Luke,
Just to be sure: how are you selecting the backend?
If you use the "matplotlib.use('Agg')" method, this must appear *before* 
importing pylab for the first time; it is something of a "gotcha" that 
if it appears after pylab has been imported it doesn't give you any clue 
that it is ineffective.
Eric
Luke Robison wrote:
> I *am* able to see the same leak in 0.90.1 using Agg, Pdg, Ps, and
> Svg with the same memory amount being leaked each time, so its
> probably in matplotlib code, although I do not have the SVN sources to
> check it there to see if it has been fixed there. I was originally
> using the wxAgg backend, but during the batch job really all i needed
> was the actual histogram numbers, so I looked through the code and
> found matplotlib.mlab.hist which is all I really need, and doesn't
> leak ;-).
> 
> Thanks for the help,
> Luke Robison
> 
> 
> On 8/9/07, Michael Droettboom <md...@st...> wrote:
>> There have been a number of memory leaks resolved since the 0.90.1
>> release. However, there are still known memory leaks in all of the GUI
>> backends, some of which are unfortunately just beyond easy reach of
>> matplotlib. If this is an automated process and you only care about the
>> file output, you could try using the "Agg", "Pdf", "Ps" or "Svg"
>> backends, e.g.:
>>
>> import matplotlib
>> matplotlib.use("Agg")
>>
>> I tried your script with both 0.90.1 and the latest svn, and I could
>> reproduce your leak with the TkAgg backend, but not with the Agg backend.
>>
>> If you need a GUI, you may want to try using the latest svn version if
>> you can. The leaks still exist there, but they are much smaller.
>>
>> BTW -- you can get the version of matplotlib with:
>>
>> >>> import matplotlib
>> >>> matplotlib.__version__
>> '0.90.1'
>>
>> Cheers,
>> Mike
>>
>>
>> Luke Robison wrote:
>>> I'm writing a program that processes ~ 25,000 jobs and each iteration
>>> draws a histogram and writes out some of the output. I let it run all
>>> night and when I came back, python was filling up all my memory
>>> (2Gigs) and was thrashing on and off of swap. I narrowed the problem
>>> down to my calling of the hist() function, and was able to reproduce
>>> it in the following code I copied from the mpl website.
>>>
>>> Am I not properly closing the figure somehow?
>>> Has this issue already been addressed?
>>>
>>> I recently installed version 0.90.1 of matplotlib, although I don't
>>> see any easy way to verify that version number from within python.
>>>
>>> -Luke Robison
>>>
>>>
>>> Code:
>>> -------------------
>>> import os,time,sys
>>> from pylab import *
>>>
>>> def report_memory(i):
>>> pid = os.getpid()
>>> a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
>>> print i, ' ', a2[1],
>>> return int(a2[1].split()[1])
>>>
>>> # take a memory snapshot on indStart and compare it with indEnd
>>> indStart, indEnd = 100, 150
>>> for i in range(indStart,indEnd):
>>> ind = arange(100)
>>> xx = rand(len(ind))
>>>
>>> figure(1)
>>> hist(xx)
>>> close(1)
>>>
>>> # wait a few cycles for memory usage to stabilize
>>> if i==indStart: start = val
>>> if i>indStart:
>>> end = val
>>> print 'Average memory consumed per loop: %1.4fk bytes' % \
>>> ((end-start)/float(indEnd-indStart))
>>>
>>> -----------------
>>>
>>> Output:
>>>
>>>
>>> python memtest.py
>>>
>>> Average memory consumed per loop: 0.0000k bytes
>>> 102 39808 21991
>>> Average memory consumed per loop: 0.0000k bytes
>>> 103 39828 21991
>>> Average memory consumed per loop: 0.0000k bytes
>>> 104 39852 22024
>>> Average memory consumed per loop: 0.6600k bytes
>>> 105 39876 22024
>>> Average memory consumed per loop: 0.6600k bytes
>>> 106 39908 22024
>>> Average memory consumed per loop: 0.6600k bytes
>>> 107 39932 22024
>>> Average memory consumed per loop: 0.6600k bytes
>>> 108 39960 22024
>>> Average memory consumed per loop: 0.6600k bytes
>>> 109 39980 22057
>>> Average memory consumed per loop: 1.3200k bytes
>>> 110 40008 22057
>>> Average memory consumed per loop: 1.3200k bytes
>>> 111 40032 22057
>>> Average memory consumed per loop: 1.3200k bytes
>>> 112 40056 22057
>>> Average memory consumed per loop: 1.3200k bytes
>>> 113 40084 22057
>>> Average memory consumed per loop: 1.3200k bytes
>>> 114 40104 22090
>>> Average memory consumed per loop: 1.9800k bytes
>>> 115 40132 22090
>>> Average memory consumed per loop: 1.9800k bytes
>>> 116 40156 22090
>>> Average memory consumed per loop: 1.9800k bytes
>>> 117 40180 22090
>>> Average memory consumed per loop: 1.9800k bytes
>>> 118 40208 22090
>>> Average memory consumed per loop: 1.9800k bytes
>>> 119 40232 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 120 40256 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 121 40280 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 122 40304 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 123 40328 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 124 40356 22123
>>> Average memory consumed per loop: 2.6400k bytes
>>> 125 40380 22156
>>> Average memory consumed per loop: 3.3000k bytes
>>> 126 40404 22156
>>> Average memory consumed per loop: 3.3000k bytes
>>> 127 40428 22156
>>> Average memory consumed per loop: 3.3000k bytes
>>> 128 40452 22156
>>> Average memory consumed per loop: 3.3000k bytes
>>> 129 40476 22156
>>> Average memory consumed per loop: 3.3000k bytes
>>> 130 40500 22189
>>> Average memory consumed per loop: 3.9600k bytes
>>> 131 40528 22189
>>> Average memory consumed per loop: 3.9600k bytes
>>> 132 40548 22189
>>> Average memory consumed per loop: 3.9600k bytes
>>> 133 40576 22189
>>> Average memory consumed per loop: 3.9600k bytes
>>> 134 40596 22189
>>> Average memory consumed per loop: 3.9600k bytes
>>> 135 40624 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 136 40652 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 137 40676 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 138 40700 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 139 40724 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 140 40744 22222
>>> Average memory consumed per loop: 4.6200k bytes
>>> 141 40768 22255
>>> Average memory consumed per loop: 5.2800k bytes
>>> 142 40800 22255
>>> Average memory consumed per loop: 5.2800k bytes
>>> 143 40824 22255
>>> Average memory consumed per loop: 5.2800k bytes
>>> 144 40848 22255
>>> Average memory consumed per loop: 5.2800k bytes
>>> 145 40872 22255
>>> Average memory consumed per loop: 5.2800k bytes
>>> 146 40896 22288
>>> Average memory consumed per loop: 5.9400k bytes
>>> 147 40916 22288
>>> Average memory consumed per loop: 5.9400k bytes
>>> 148 40940 22288
>>> Average memory consumed per loop: 5.9400k bytes
>>> 149 40972 22288
>>> Average memory consumed per loop: 5.9400k bytes
>>>
>>>
>>> as you can see, the memory consumption is increasing each loop, and
>>> furthermore, and an increasing rate :-(
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Splunk Inc.
>>> Still grepping through log files to find problems? Stop.
>>> Now Search log events and configuration files using AJAX and a browser.
>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

 I *am* able to see the same leak in 0.90.1 using Agg, Pdg, Ps, and
Svg with the same memory amount being leaked each time, so its
probably in matplotlib code, although I do not have the SVN sources to
check it there to see if it has been fixed there. I was originally
using the wxAgg backend, but during the batch job really all i needed
was the actual histogram numbers, so I looked through the code and
found matplotlib.mlab.hist which is all I really need, and doesn't
leak ;-).
Thanks for the help,
Luke Robison
On 8/9/07, Michael Droettboom <md...@st...> wrote:
> There have been a number of memory leaks resolved since the 0.90.1
> release. However, there are still known memory leaks in all of the GUI
> backends, some of which are unfortunately just beyond easy reach of
> matplotlib. If this is an automated process and you only care about the
> file output, you could try using the "Agg", "Pdf", "Ps" or "Svg"
> backends, e.g.:
>
> import matplotlib
> matplotlib.use("Agg")
>
> I tried your script with both 0.90.1 and the latest svn, and I could
> reproduce your leak with the TkAgg backend, but not with the Agg backend.
>
> If you need a GUI, you may want to try using the latest svn version if
> you can. The leaks still exist there, but they are much smaller.
>
> BTW -- you can get the version of matplotlib with:
>
> >>> import matplotlib
> >>> matplotlib.__version__
> '0.90.1'
>
> Cheers,
> Mike
>
>
> Luke Robison wrote:
> > I'm writing a program that processes ~ 25,000 jobs and each iteration
> > draws a histogram and writes out some of the output. I let it run all
> > night and when I came back, python was filling up all my memory
> > (2Gigs) and was thrashing on and off of swap. I narrowed the problem
> > down to my calling of the hist() function, and was able to reproduce
> > it in the following code I copied from the mpl website.
> >
> > Am I not properly closing the figure somehow?
> > Has this issue already been addressed?
> >
> > I recently installed version 0.90.1 of matplotlib, although I don't
> > see any easy way to verify that version number from within python.
> >
> > -Luke Robison
> >
> >
> > Code:
> > -------------------
> > import os,time,sys
> > from pylab import *
> >
> > def report_memory(i):
> > pid = os.getpid()
> > a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
> > print i, ' ', a2[1],
> > return int(a2[1].split()[1])
> >
> > # take a memory snapshot on indStart and compare it with indEnd
> > indStart, indEnd = 100, 150
> > for i in range(indStart,indEnd):
> > ind = arange(100)
> > xx = rand(len(ind))
> >
> > figure(1)
> > hist(xx)
> > close(1)
> >
> > # wait a few cycles for memory usage to stabilize
> > if i==indStart: start = val
> > if i>indStart:
> > end = val
> > print 'Average memory consumed per loop: %1.4fk bytes' % \
> > ((end-start)/float(indEnd-indStart))
> >
> > -----------------
> >
> > Output:
> >
> >
> > python memtest.py
> >
> > Average memory consumed per loop: 0.0000k bytes
> > 102 39808 21991
> > Average memory consumed per loop: 0.0000k bytes
> > 103 39828 21991
> > Average memory consumed per loop: 0.0000k bytes
> > 104 39852 22024
> > Average memory consumed per loop: 0.6600k bytes
> > 105 39876 22024
> > Average memory consumed per loop: 0.6600k bytes
> > 106 39908 22024
> > Average memory consumed per loop: 0.6600k bytes
> > 107 39932 22024
> > Average memory consumed per loop: 0.6600k bytes
> > 108 39960 22024
> > Average memory consumed per loop: 0.6600k bytes
> > 109 39980 22057
> > Average memory consumed per loop: 1.3200k bytes
> > 110 40008 22057
> > Average memory consumed per loop: 1.3200k bytes
> > 111 40032 22057
> > Average memory consumed per loop: 1.3200k bytes
> > 112 40056 22057
> > Average memory consumed per loop: 1.3200k bytes
> > 113 40084 22057
> > Average memory consumed per loop: 1.3200k bytes
> > 114 40104 22090
> > Average memory consumed per loop: 1.9800k bytes
> > 115 40132 22090
> > Average memory consumed per loop: 1.9800k bytes
> > 116 40156 22090
> > Average memory consumed per loop: 1.9800k bytes
> > 117 40180 22090
> > Average memory consumed per loop: 1.9800k bytes
> > 118 40208 22090
> > Average memory consumed per loop: 1.9800k bytes
> > 119 40232 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 120 40256 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 121 40280 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 122 40304 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 123 40328 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 124 40356 22123
> > Average memory consumed per loop: 2.6400k bytes
> > 125 40380 22156
> > Average memory consumed per loop: 3.3000k bytes
> > 126 40404 22156
> > Average memory consumed per loop: 3.3000k bytes
> > 127 40428 22156
> > Average memory consumed per loop: 3.3000k bytes
> > 128 40452 22156
> > Average memory consumed per loop: 3.3000k bytes
> > 129 40476 22156
> > Average memory consumed per loop: 3.3000k bytes
> > 130 40500 22189
> > Average memory consumed per loop: 3.9600k bytes
> > 131 40528 22189
> > Average memory consumed per loop: 3.9600k bytes
> > 132 40548 22189
> > Average memory consumed per loop: 3.9600k bytes
> > 133 40576 22189
> > Average memory consumed per loop: 3.9600k bytes
> > 134 40596 22189
> > Average memory consumed per loop: 3.9600k bytes
> > 135 40624 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 136 40652 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 137 40676 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 138 40700 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 139 40724 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 140 40744 22222
> > Average memory consumed per loop: 4.6200k bytes
> > 141 40768 22255
> > Average memory consumed per loop: 5.2800k bytes
> > 142 40800 22255
> > Average memory consumed per loop: 5.2800k bytes
> > 143 40824 22255
> > Average memory consumed per loop: 5.2800k bytes
> > 144 40848 22255
> > Average memory consumed per loop: 5.2800k bytes
> > 145 40872 22255
> > Average memory consumed per loop: 5.2800k bytes
> > 146 40896 22288
> > Average memory consumed per loop: 5.9400k bytes
> > 147 40916 22288
> > Average memory consumed per loop: 5.9400k bytes
> > 148 40940 22288
> > Average memory consumed per loop: 5.9400k bytes
> > 149 40972 22288
> > Average memory consumed per loop: 5.9400k bytes
> >
> >
> > as you can see, the memory consumption is increasing each loop, and
> > furthermore, and an increasing rate :-(
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Sebastian,
I am trying to move things in the direction of simpler and cleaner 
namespaces, but I think that to do it well requires a systematic 
approach to the continuing numpification of mpl, so I have been working 
on mlab.py before tackling pylab. I hope everything can be done via 
reorganization, without requiring any import tricks, but that remains to 
be seen. I'm sorry this is taking a long time, but it is in the works.
Eric
Sebastian Haase wrote:
> Hi all,
> Here a quick update:
> I'm trying to have a concise / sparse module with containing only
> pylab-specific names and not all names I already have in numpy.
> To easy typing I want to call numpy "N" and my pylab "P".
> 
> I'm now using this code:
> <code snipplet for importing matplotlib>
> import matplotlib, new
> matplotlib.use('WXAgg')
> from matplotlib import pylab
> P = new.module("pylab_sparse","""pylab module minus stuff alreay
> in numpy""")
> for k,v in pylab.__dict__.iteritems():
> try:
> if v is N.__dict__[k]:
> continue
> except KeyError:
> pass
> P.__dict__[k] = v
> 
> P.ion()
> del matplotlib, new, pylab
> </code sniplet for importing matplotlib>
> 
> The result is "some" reduction in the number of non-pylab-specific
> names in my "P"-module. However there seem to be still many extra
> names left, like e.g.:
> alltrue, amax, array, ...
> look at this:
> # 20070802
> # >>> len(dir(pylab))
> # 441
> # >>> len(dir(P))
> # 346
> # >>> P.nx.numpy.__version__
> # '1.0.1'
> # >>> N.__version__
> # '1.0.1'
> # >>> N.alltrue
> # <function alltrue at 0x01471B70>
> # >>> P.alltrue
> # <function alltrue at 0x019142F0>
> # >>> N.alltrue.__doc__
> # 'Perform a logical_and over the given axis.'
> # >>> P.alltrue.__doc__
> # >>> #N.alltrue(x, axis=None, out=None)
> # >>> #P.alltrue(x, axis=0)
> 
> I'm using matplotlib with
> __version__ = '0.90.0'
> __revision__ = '$Revision: 3003 $'
> __date__ = '$Date: 2007年02月06日 22:24:06 -0500 (2007年2月06日) $'
> 
> 
> Any hint how to further reduce the number of names in "P" ?
> My ideal would be that the "P" module (short for pylab) would only
> contain the stuff described in the __doc__ strings of `pylab.py` and
> `__init__.py`(in matplotlib) (+ plus some extra, undocumented, yet
> pylab specific things)
> 
> Thanks
> -Sebastian
> 
> 
> On 3/16/07, Eric Firing <ef...@ha...> wrote:
>> Sebastian Haase wrote:
>>> Hi!
>>> I use the wxPython PyShell.
>>> I like especially the feature that when typing a module and then the
>>> dot "." I get a popup list of all available functions (names) inside
>>> that module.
>>>
>>> Secondly, I think it really makes code clearer when one can see where
>>> a function comes from.
>>>
>>> I have a default
>>> import numpy as N
>>> executed before my shell even starts.
>>> In fact I have a bunch of my "standard" modules imported as <some
>>> single capital letter>.
>>>
>>> This - I think - is a good compromise to the commonly used "extra
>>> typing" and "unreadable" argument.
>>>
>>> a = sin(b) * arange(10,50, .1) * cos(d)
>>> vs.
>>> a = N.sin(b) * N.arange(10,50, .1) * N.cos(d)
>> I generally do the latter, but really, all those "N." bits are still
>> visual noise when it comes to reading the code--that is, seeing the
>> algorithm rather than where the functions come from. I don't think
>> there is anything wrong with explicitly importing commonly-used names,
>> especially things like sin and cos.
>>
>>> I would like to hear some comments by others.
>>>
>>>
>>> On a different note: I just started using pylab, so I did added an
>>> automatic "from matplotlib import pylab as P" -- but now P contains
>>> everything that I already have in N. It makes it really hard to
>>> *find* (as in *see* n the popup-list) the pylab-only functions. --
>>> what can I do about this ?
>> A quick and dirty solution would be to comment out most of the imports
>> in pylab.py; they are not needed for the pylab functions and are there
>> only to give people lots of functionality in a single namespace.
>>
>> I am cross-posting this to matplotlib-users because it involves mpl, and
>> an alternative solution would be for us to add an rcParam entry to allow
>> one to turn off all of the namespace consolidation. A danger is that if
>> someone is using "from pylab import *" in a script, then whether it
>> would run would depend on the matplotlibrc file. To get around that,
>> another possibility would be to break pylab.py into two parts, with
>> pylab.py continuing to do the namespace consolidation and importing the
>> second part, which would contain the actual pylab functions. Then if
>> you don't want the namespace consolidation, you could simply import the
>> second part instead of pylab. There may be devils in the details, but
>> it seems to me that this last alternative--splitting pylab.py--might
>> make a number of people happier while having no adverse effects on
>> everyone else.
>>
>> Eric
>>>
>>> Thanks,
>>> Sebastian
> _______________________________________________
> Numpy-discussion mailing list
> Num...@sc...
> http://projects.scipy.org/mailman/listinfo/numpy-discussion

There have been a number of memory leaks resolved since the 0.90.1 
release. However, there are still known memory leaks in all of the GUI 
backends, some of which are unfortunately just beyond easy reach of 
matplotlib. If this is an automated process and you only care about the 
file output, you could try using the "Agg", "Pdf", "Ps" or "Svg" 
backends, e.g.:
	import matplotlib
	matplotlib.use("Agg")	
I tried your script with both 0.90.1 and the latest svn, and I could 
reproduce your leak with the TkAgg backend, but not with the Agg backend.
If you need a GUI, you may want to try using the latest svn version if 
you can. The leaks still exist there, but they are much smaller.
BTW -- you can get the version of matplotlib with:
 >>> import matplotlib
 >>> matplotlib.__version__
'0.90.1'
Cheers,
Mike
Luke Robison wrote:
> I'm writing a program that processes ~ 25,000 jobs and each iteration
> draws a histogram and writes out some of the output. I let it run all
> night and when I came back, python was filling up all my memory
> (2Gigs) and was thrashing on and off of swap. I narrowed the problem
> down to my calling of the hist() function, and was able to reproduce
> it in the following code I copied from the mpl website.
> 
> Am I not properly closing the figure somehow?
> Has this issue already been addressed?
> 
> I recently installed version 0.90.1 of matplotlib, although I don't
> see any easy way to verify that version number from within python.
> 
> -Luke Robison
> 
> 
> Code:
> -------------------
> import os,time,sys
> from pylab import *
> 
> def report_memory(i):
> pid = os.getpid()
> a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
> print i, ' ', a2[1],
> return int(a2[1].split()[1])
> 
> # take a memory snapshot on indStart and compare it with indEnd
> indStart, indEnd = 100, 150
> for i in range(indStart,indEnd):
> ind = arange(100)
> xx = rand(len(ind))
> 
> figure(1)
> hist(xx)
> close(1)
> 
> # wait a few cycles for memory usage to stabilize
> if i==indStart: start = val
> if i>indStart:
> end = val
> print 'Average memory consumed per loop: %1.4fk bytes' % \
> ((end-start)/float(indEnd-indStart))
> 
> -----------------
> 
> Output:
> 
> 
> python memtest.py
> 
> Average memory consumed per loop: 0.0000k bytes
> 102 39808 21991
> Average memory consumed per loop: 0.0000k bytes
> 103 39828 21991
> Average memory consumed per loop: 0.0000k bytes
> 104 39852 22024
> Average memory consumed per loop: 0.6600k bytes
> 105 39876 22024
> Average memory consumed per loop: 0.6600k bytes
> 106 39908 22024
> Average memory consumed per loop: 0.6600k bytes
> 107 39932 22024
> Average memory consumed per loop: 0.6600k bytes
> 108 39960 22024
> Average memory consumed per loop: 0.6600k bytes
> 109 39980 22057
> Average memory consumed per loop: 1.3200k bytes
> 110 40008 22057
> Average memory consumed per loop: 1.3200k bytes
> 111 40032 22057
> Average memory consumed per loop: 1.3200k bytes
> 112 40056 22057
> Average memory consumed per loop: 1.3200k bytes
> 113 40084 22057
> Average memory consumed per loop: 1.3200k bytes
> 114 40104 22090
> Average memory consumed per loop: 1.9800k bytes
> 115 40132 22090
> Average memory consumed per loop: 1.9800k bytes
> 116 40156 22090
> Average memory consumed per loop: 1.9800k bytes
> 117 40180 22090
> Average memory consumed per loop: 1.9800k bytes
> 118 40208 22090
> Average memory consumed per loop: 1.9800k bytes
> 119 40232 22123
> Average memory consumed per loop: 2.6400k bytes
> 120 40256 22123
> Average memory consumed per loop: 2.6400k bytes
> 121 40280 22123
> Average memory consumed per loop: 2.6400k bytes
> 122 40304 22123
> Average memory consumed per loop: 2.6400k bytes
> 123 40328 22123
> Average memory consumed per loop: 2.6400k bytes
> 124 40356 22123
> Average memory consumed per loop: 2.6400k bytes
> 125 40380 22156
> Average memory consumed per loop: 3.3000k bytes
> 126 40404 22156
> Average memory consumed per loop: 3.3000k bytes
> 127 40428 22156
> Average memory consumed per loop: 3.3000k bytes
> 128 40452 22156
> Average memory consumed per loop: 3.3000k bytes
> 129 40476 22156
> Average memory consumed per loop: 3.3000k bytes
> 130 40500 22189
> Average memory consumed per loop: 3.9600k bytes
> 131 40528 22189
> Average memory consumed per loop: 3.9600k bytes
> 132 40548 22189
> Average memory consumed per loop: 3.9600k bytes
> 133 40576 22189
> Average memory consumed per loop: 3.9600k bytes
> 134 40596 22189
> Average memory consumed per loop: 3.9600k bytes
> 135 40624 22222
> Average memory consumed per loop: 4.6200k bytes
> 136 40652 22222
> Average memory consumed per loop: 4.6200k bytes
> 137 40676 22222
> Average memory consumed per loop: 4.6200k bytes
> 138 40700 22222
> Average memory consumed per loop: 4.6200k bytes
> 139 40724 22222
> Average memory consumed per loop: 4.6200k bytes
> 140 40744 22222
> Average memory consumed per loop: 4.6200k bytes
> 141 40768 22255
> Average memory consumed per loop: 5.2800k bytes
> 142 40800 22255
> Average memory consumed per loop: 5.2800k bytes
> 143 40824 22255
> Average memory consumed per loop: 5.2800k bytes
> 144 40848 22255
> Average memory consumed per loop: 5.2800k bytes
> 145 40872 22255
> Average memory consumed per loop: 5.2800k bytes
> 146 40896 22288
> Average memory consumed per loop: 5.9400k bytes
> 147 40916 22288
> Average memory consumed per loop: 5.9400k bytes
> 148 40940 22288
> Average memory consumed per loop: 5.9400k bytes
> 149 40972 22288
> Average memory consumed per loop: 5.9400k bytes
> 
> 
> as you can see, the memory consumption is increasing each loop, and
> furthermore, and an increasing rate :-(
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I'm writing a program that processes ~ 25,000 jobs and each iteration
draws a histogram and writes out some of the output. I let it run all
night and when I came back, python was filling up all my memory
(2Gigs) and was thrashing on and off of swap. I narrowed the problem
down to my calling of the hist() function, and was able to reproduce
it in the following code I copied from the mpl website.
Am I not properly closing the figure somehow?
Has this issue already been addressed?
I recently installed version 0.90.1 of matplotlib, although I don't
see any easy way to verify that version number from within python.
-Luke Robison
Code:
-------------------
import os,time,sys
from pylab import *
def report_memory(i):
 pid = os.getpid()
 a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
 print i, ' ', a2[1],
 return int(a2[1].split()[1])
# take a memory snapshot on indStart and compare it with indEnd
indStart, indEnd = 100, 150
for i in range(indStart,indEnd):
 ind = arange(100)
 xx = rand(len(ind))
 figure(1)
 hist(xx)
 close(1)
# wait a few cycles for memory usage to stabilize
 if i==indStart: start = val
 if i>indStart:
 end = val
 print 'Average memory consumed per loop: %1.4fk bytes' % \
 ((end-start)/float(indEnd-indStart))
-----------------
Output:
python memtest.py
Average memory consumed per loop: 0.0000k bytes
102 39808 21991
Average memory consumed per loop: 0.0000k bytes
103 39828 21991
Average memory consumed per loop: 0.0000k bytes
104 39852 22024
Average memory consumed per loop: 0.6600k bytes
105 39876 22024
Average memory consumed per loop: 0.6600k bytes
106 39908 22024
Average memory consumed per loop: 0.6600k bytes
107 39932 22024
Average memory consumed per loop: 0.6600k bytes
108 39960 22024
Average memory consumed per loop: 0.6600k bytes
109 39980 22057
Average memory consumed per loop: 1.3200k bytes
110 40008 22057
Average memory consumed per loop: 1.3200k bytes
111 40032 22057
Average memory consumed per loop: 1.3200k bytes
112 40056 22057
Average memory consumed per loop: 1.3200k bytes
113 40084 22057
Average memory consumed per loop: 1.3200k bytes
114 40104 22090
Average memory consumed per loop: 1.9800k bytes
115 40132 22090
Average memory consumed per loop: 1.9800k bytes
116 40156 22090
Average memory consumed per loop: 1.9800k bytes
117 40180 22090
Average memory consumed per loop: 1.9800k bytes
118 40208 22090
Average memory consumed per loop: 1.9800k bytes
119 40232 22123
Average memory consumed per loop: 2.6400k bytes
120 40256 22123
Average memory consumed per loop: 2.6400k bytes
121 40280 22123
Average memory consumed per loop: 2.6400k bytes
122 40304 22123
Average memory consumed per loop: 2.6400k bytes
123 40328 22123
Average memory consumed per loop: 2.6400k bytes
124 40356 22123
Average memory consumed per loop: 2.6400k bytes
125 40380 22156
Average memory consumed per loop: 3.3000k bytes
126 40404 22156
Average memory consumed per loop: 3.3000k bytes
127 40428 22156
Average memory consumed per loop: 3.3000k bytes
128 40452 22156
Average memory consumed per loop: 3.3000k bytes
129 40476 22156
Average memory consumed per loop: 3.3000k bytes
130 40500 22189
Average memory consumed per loop: 3.9600k bytes
131 40528 22189
Average memory consumed per loop: 3.9600k bytes
132 40548 22189
Average memory consumed per loop: 3.9600k bytes
133 40576 22189
Average memory consumed per loop: 3.9600k bytes
134 40596 22189
Average memory consumed per loop: 3.9600k bytes
135 40624 22222
Average memory consumed per loop: 4.6200k bytes
136 40652 22222
Average memory consumed per loop: 4.6200k bytes
137 40676 22222
Average memory consumed per loop: 4.6200k bytes
138 40700 22222
Average memory consumed per loop: 4.6200k bytes
139 40724 22222
Average memory consumed per loop: 4.6200k bytes
140 40744 22222
Average memory consumed per loop: 4.6200k bytes
141 40768 22255
Average memory consumed per loop: 5.2800k bytes
142 40800 22255
Average memory consumed per loop: 5.2800k bytes
143 40824 22255
Average memory consumed per loop: 5.2800k bytes
144 40848 22255
Average memory consumed per loop: 5.2800k bytes
145 40872 22255
Average memory consumed per loop: 5.2800k bytes
146 40896 22288
Average memory consumed per loop: 5.9400k bytes
147 40916 22288
Average memory consumed per loop: 5.9400k bytes
148 40940 22288
Average memory consumed per loop: 5.9400k bytes
149 40972 22288
Average memory consumed per loop: 5.9400k bytes
as you can see, the memory consumption is increasing each loop, and
furthermore, and an increasing rate :-(

Hi,
 I've created a plot with the correct scale but I want to add more room at
the bottom of the plot to add a title block with out effecting the size of
the plot. Does anyone know how to do this?
 
Regards,
Jonathan
 
School of Mechanical and Aerospace Engineering
Ashby Building
Stranmillis Road
Belfast 
BT9 5AH
 
Tel: +44 (0)28 9097 4277
Fax: +44 (0)28 9066 1729
Email: <mailto:jma...@qu...> jma...@qu... 
 

I installed the necessary stuff in my LaTeX installation from here:
 http://www.unruh.de/DniQ/latex/unicode/
and it's now working even when usetex is on.
It would be great to figure out why it's broken for you.
Do you get any error output from LaTeX?
Cheers,
Mike
Michael Droettboom wrote:
> I should clarify, I have this working with the TkAgg backend and 
> "text.usetex : False". If "text.usetex : True", I can't confirm or deny 
> whether that works since I don't have a proper LaTeX ucs.sty setup here 
> to test with.
> 
> As an aside, if you're looking to Gtk as a way around this, the Gtk 
> backend uses the same rendering pipeline for text when text.usetex is 
> True, so it likely will produce the same result.
> 
> Cheers,
> Mie
> 
> Michael Droettboom wrote:
>> Xavier Gnata wrote:
>>> With a = u"é" I get no error but also nothing as a title. No strange 
>>> characters. Nothing.
>>
>> This is working for me with the latest svn version, as well as 0.90.1, 
>> on Linux with Python 2.5 and Tcl/Tk 8.4.
>>
>> There are other things that could be going wrong. The encoding of 
>> your terminal may not match your default encoding in your Python 
>> interpreter. If you're using Linux, can you please send the output of:
>>
>> > locale
>> > python -c "import locale; print locale.getpreferredencoding()"
>>
>> If all is working correctly, you should get the following in your 
>> python interpreter:
>>
>> >>> a = u"é"
>> >>> ord(a)
>> 233
>>
>> If you're using an editor (i.e. not using pylab interactively), you'll 
>> need to make sure that it is outputting in the correct encoding, and 
>> respecting the
>>
>> # -*- coding: utf-8 -*-
>>
>> line. Recent versions of emacs do this, but I can't really speak for 
>> others.
>>
>> I have attached a test script that works for me. It even includes 
>> some Greek characters as Unicode which work if you select a Unicode 
>> font with those characters.
>>
>> Cheers,
>> Mike
>