You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
(1) |
4
(2) |
5
|
6
|
7
(1) |
8
(2) |
|
9
|
10
(1) |
11
(3) |
12
(7) |
13
(5) |
14
(3) |
15
(1) |
|
16
(1) |
17
(4) |
18
|
19
(2) |
20
|
21
(10) |
22
(2) |
|
23
(2) |
24
|
25
(1) |
26
|
27
|
28
(15) |
29
(5) |
|
30
(8) |
31
(3) |
|
|
|
|
|
|
From: Pearu P. <pe...@ce...> - 2010-05-28 20:21:25
|
Thanks, John! Calling ax.autoscale_view after ax.relim makes the script work. Best regards, Pearu |
|
From: Ryan M. <rm...@gm...> - 2010-05-28 20:06:07
|
Hi,
Ben Root gave me a bug report that pcolormesh (and hence QuadMesh)
were not respecting zorder. This turns out to be due to the fact that
kwargs are not being forwarded on as appropriate. This is easy enough
to fix and make work, but I wanted to first ask for any insight on the
following "helpful" comment in axes.py:
collection = mcoll.QuadMesh(
Nx - 1, Ny - 1, coords, showedges,
antialiased=antialiased, shading=shading) # kwargs are not used
(It's be great if this comment gave some actual reasoning rather than
stating the obvious).
Anyone know if there's an explicit design choice for QuadMesh not
taking kwargs, or is it just an omission?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
|
|
From: Pearu P. <pe...@ce...> - 2010-05-28 19:32:02
|
Thanks, John! Adding ax.autoscale_view after ax.relim makes the script work correctly. Best regards, Pearu |
|
From: John H. <jd...@gm...> - 2010-05-28 18:41:16
|
On Fri, May 28, 2010 at 1:37 PM, Pearu Peterson <pe...@ce...> wrote: > While the new data is plotted correctly, the plot shows fixed axes > from the first plot call. What I am doing wrong? ax.relim() causes the data limits to be updated based on the current objects it contains, ax.autoscale_view() causes the view limits to be updated based on the data limits, and fig.canvas.draw() forces a redraw. JDH |
|
From: Pearu P. <pe...@ce...> - 2010-05-28 18:37:16
|
On Fri, May 28, 2010 9:15 pm, John Hunter wrote:
> On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson <pe...@ce...> wrote:
>
>> Regarding reusing existing line --- I have understood that this
>> will work only if the length of the line data does not change.
>
> This is not correct -- you can change the line length with calls to
> set_data
>
>> In my case the data grows as more data points are acquired and I have
>> not figured out how to make axes to set new limits after changing
>> the line data.
>
> ax.relim()
Ok, very good. However, it does not seem to have effect. Consider
the following example:
#
import numpy
from numpy.testing.utils import memusage
import matplotlib
matplotlib.use('GTKAgg')
import matplotlib.pyplot as plt
fig = plt.figure()
axes1 = fig.add_subplot( 111 )
def animate():
x = [0]
while 1:
y = numpy.random.rand (len (x))
if 1:
# updating line in place
if not axes1.lines:
line, = axes1.plot(x, y, 'b')
else:
line.set_data(x, y)
# relim does not have effect in updating axes
axes1.relim()
else:
# demonstrates expected behaviour, has leakage w/o Mike patch
for line in axes1.lines:
line.remove()
line, = axes1.plot(x, y, 'b')
fig.canvas.draw()
print memusage ()/(1024.0*1024.0),"MB", len (axes1.lines), len(x)
x.append(x[-1]+1)
import gobject
print 'adding idle'
gobject.idle_add(animate)
print 'showing'
plt.show()
#eof
While the new data is plotted correctly, the plot shows fixed axes
from the first plot call. What I am doing wrong?
Pearu
|
|
From: Eric F. <ef...@ha...> - 2010-05-28 18:29:38
|
On 05/28/2010 08:04 AM, Pearu Peterson wrote: > On Fri, May 28, 2010 5:12 pm, John Hunter wrote: > >> Hey Pearu -- thanks for the report. We'll try and track down and fix >> this leak. In the interim, would an acceptable work around for you be >> to *reuse* an existing line by calling set_data on it. That way you >> wouldn't have to do the add/remove that is causing your leak. Have >> you confirmed this leak on various backends (eg Agg, PDF, PS)? > > No, I haven't but I can try it. > > Regarding reusing existing line --- I have understood that this > will work only if the length of the line data does not change. Not so. > In my case the data grows as more data points are acquired and I have > not figured out how to make axes to set new limits after changing > the line data. lineobj = plot([0], [0])[0] ax = gca() x = np.arange(10) y = 20 * np.sin(x) lineobj.set_data(x, y) xy = np.concatenate((x[:,np.newaxis], y[:,np.newaxis]), axis=1) ax.update_datalim(xy) ax.autoscale_view() draw() Eric > > Currently I am using a work around where the axes are cleared > after every 60 seconds - this seems to keep memory usage under control. > > It seems that Mike has resolved the problem. I'll try the latest > SVN.. > > Thanks! > Pearu > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: John H. <jd...@gm...> - 2010-05-28 18:15:07
|
On Fri, May 28, 2010 at 1:04 PM, Pearu Peterson <pe...@ce...> wrote: > Regarding reusing existing line --- I have understood that this > will work only if the length of the line data does not change. This is not correct -- you can change the line length with calls to set_data > In my case the data grows as more data points are acquired and I have > not figured out how to make axes to set new limits after changing > the line data. ax.relim() Cheers, JDH |
|
From: Pearu P. <pe...@ce...> - 2010-05-28 18:05:10
|
On Fri, May 28, 2010 5:12 pm, John Hunter wrote: > Hey Pearu -- thanks for the report. We'll try and track down and fix > this leak. In the interim, would an acceptable work around for you be > to *reuse* an existing line by calling set_data on it. That way you > wouldn't have to do the add/remove that is causing your leak. Have > you confirmed this leak on various backends (eg Agg, PDF, PS)? No, I haven't but I can try it. Regarding reusing existing line --- I have understood that this will work only if the length of the line data does not change. In my case the data grows as more data points are acquired and I have not figured out how to make axes to set new limits after changing the line data. Currently I am using a work around where the axes are cleared after every 60 seconds - this seems to keep memory usage under control. It seems that Mike has resolved the problem. I'll try the latest SVN.. Thanks! Pearu |
|
From: Michael D. <md...@st...> - 2010-05-28 17:48:17
|
There is a fix in r8341. It passes the regression tests, and all of the
event handling examples I tried seem to still work.
It seems that many places in matplotlib were never disconnecting
callbacks, and these callbacks keep references to the destination
objects alive.
Unfortunately, it's not quite obvious where the "disconnect" calls
should be added -- the lifetime of objects isn't very symmetrical. For
example, the "units" callback is set up by Lines2D inside of its
"set_axes" method, but there is no "remove_axes" method in which to put
the disconnect. Tracking down all of the ways in which a line could be
removed from an axes seems daunting.
Instead, my solution is to store weak references to the methods stored
in the CallbackRegistry -- that way the CallbackRegistry won't leak
references like it does now. Since the Python stdlib weakref module
doesn't directly support weak references to bound methods, the whole
thing is a bit hairy -- but I think it's a more permanent solution than
trying to ensure that all callbacks get explicitly disconnected.
As this change is rather fundamental and may have unintended
consequences, please play with it in your contexts and let me know if
you see anything strange.
Mike
On 05/28/2010 10:47 AM, Michael Droettboom wrote:
> I'm on to something -- some callbacks are being created that are never
> disconnected.
>
> In Line2D.set_axes:
>
> self._xcid = ax.xaxis.callbacks.connect('units', self.recache_always)
>
> gets called twice. This is problematic because the id of the first
> connection is simply lost. Also, there doesn't seem to be any code to
> attempt to remove either of them.
>
> I'm looking into it further -- forcibly deleting these callbacks reduces
> the reference count on the line object, but doesn't seem to completely
> eliminate the leak.
>
> Mike
>
> On 05/28/2010 10:12 AM, John Hunter wrote:
>
>> On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson<pe...@ce...> wrote:
>>
>>
>>> Hi,
>>>
>>> In an application that updates a plot with
>>> new experimental data, say, every second and the experiment
>>> can last hours, I have tried two approaches:
>>> 1) clear axes and plot new experimental data - this is
>>> slow and takes too much cpu resources.
>>> 2) remove lines and plot new experimental data - this is
>>> fast enough but unfortunately there seems to be a memory
>>> leakage, the application runs out of memory.
>>>
>>> Here follows a simple script that demonstrates the
>>> leakage problem:
>>>
>>> #
>>> import numpy
>>> from numpy.testing.utils import memusage
>>> import matplotlib.pyplot as plt
>>> x = range (1000)
>>> axes1 = plt.figure().add_subplot( 111 )
>>> y = numpy.random.rand (len (x))
>>> while 1:
>>> if 1:
>>> # leakage
>>> for line in axes1.lines:
>>> if line.get_label ()=='data':
>>> line.remove()
>>> else:
>>> # no leak, but slow
>>> axes1.clear()
>>> axes1.plot(x, y, 'b', label='data')
>>> print memusage (), len (axes1.lines)
>>> #eof
>>>
>>> When running the script, the memory usage
>>> is increasing by 132 kbytes per iteration, that is,
>>> with an hour this example application will consume
>>> 464MB RAM while no new data has been generated. In real
>>> application this effect will be even worse.
>>>
>>> So, I am looking for an advice how to avoid
>>> this memory leakage without clearing axes.
>>>
>>>
>> Hey Pearu -- thanks for the report. We'll try and track down and fix
>> this leak. In the interim, would an acceptable work around for you be
>> to *reuse* an existing line by calling set_data on it. That way you
>> wouldn't have to do the add/remove that is causing your leak. Have
>> you confirmed this leak on various backends (eg Agg, PDF, PS)?
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
|
|
From: Ryan M. <rm...@gm...> - 2010-05-28 16:57:31
|
On Fri, May 28, 2010 at 10:52 AM, Jason Grout <jas...@cr...> wrote: > I just noticed here: > > http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim > > that the keywords that are documented for set_xlim are actually the > keywords for set_ylim. Surely this is just a copy-paste error. Surely. Fixed in SVN, thanks for the report. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma |
|
From: Jason G. <jas...@cr...> - 2010-05-28 16:10:58
|
I just noticed here: http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_xlim that the keywords that are documented for set_xlim are actually the keywords for set_ylim. Surely this is just a copy-paste error. Thanks, Jason |
|
From: Michael D. <md...@st...> - 2010-05-28 14:48:07
|
I'm on to something -- some callbacks are being created that are never
disconnected.
In Line2D.set_axes:
self._xcid = ax.xaxis.callbacks.connect('units', self.recache_always)
gets called twice. This is problematic because the id of the first
connection is simply lost. Also, there doesn't seem to be any code to
attempt to remove either of them.
I'm looking into it further -- forcibly deleting these callbacks reduces
the reference count on the line object, but doesn't seem to completely
eliminate the leak.
Mike
On 05/28/2010 10:12 AM, John Hunter wrote:
> On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson<pe...@ce...> wrote:
>
>> Hi,
>>
>> In an application that updates a plot with
>> new experimental data, say, every second and the experiment
>> can last hours, I have tried two approaches:
>> 1) clear axes and plot new experimental data - this is
>> slow and takes too much cpu resources.
>> 2) remove lines and plot new experimental data - this is
>> fast enough but unfortunately there seems to be a memory
>> leakage, the application runs out of memory.
>>
>> Here follows a simple script that demonstrates the
>> leakage problem:
>>
>> #
>> import numpy
>> from numpy.testing.utils import memusage
>> import matplotlib.pyplot as plt
>> x = range (1000)
>> axes1 = plt.figure().add_subplot( 111 )
>> y = numpy.random.rand (len (x))
>> while 1:
>> if 1:
>> # leakage
>> for line in axes1.lines:
>> if line.get_label ()=='data':
>> line.remove()
>> else:
>> # no leak, but slow
>> axes1.clear()
>> axes1.plot(x, y, 'b', label='data')
>> print memusage (), len (axes1.lines)
>> #eof
>>
>> When running the script, the memory usage
>> is increasing by 132 kbytes per iteration, that is,
>> with an hour this example application will consume
>> 464MB RAM while no new data has been generated. In real
>> application this effect will be even worse.
>>
>> So, I am looking for an advice how to avoid
>> this memory leakage without clearing axes.
>>
> Hey Pearu -- thanks for the report. We'll try and track down and fix
> this leak. In the interim, would an acceptable work around for you be
> to *reuse* an existing line by calling set_data on it. That way you
> wouldn't have to do the add/remove that is causing your leak. Have
> you confirmed this leak on various backends (eg Agg, PDF, PS)?
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
|
|
From: John H. <jd...@gm...> - 2010-05-28 14:13:00
|
On Fri, May 28, 2010 at 3:18 AM, Pearu Peterson <pe...@ce...> wrote: > > Hi, > > In an application that updates a plot with > new experimental data, say, every second and the experiment > can last hours, I have tried two approaches: > 1) clear axes and plot new experimental data - this is > slow and takes too much cpu resources. > 2) remove lines and plot new experimental data - this is > fast enough but unfortunately there seems to be a memory > leakage, the application runs out of memory. > > Here follows a simple script that demonstrates the > leakage problem: > > # > import numpy > from numpy.testing.utils import memusage > import matplotlib.pyplot as plt > x = range (1000) > axes1 = plt.figure().add_subplot( 111 ) > y = numpy.random.rand (len (x)) > while 1: > if 1: > # leakage > for line in axes1.lines: > if line.get_label ()=='data': > line.remove() > else: > # no leak, but slow > axes1.clear() > axes1.plot(x, y, 'b', label='data') > print memusage (), len (axes1.lines) > #eof > > When running the script, the memory usage > is increasing by 132 kbytes per iteration, that is, > with an hour this example application will consume > 464MB RAM while no new data has been generated. In real > application this effect will be even worse. > > So, I am looking for an advice how to avoid > this memory leakage without clearing axes. Hey Pearu -- thanks for the report. We'll try and track down and fix this leak. In the interim, would an acceptable work around for you be to *reuse* an existing line by calling set_data on it. That way you wouldn't have to do the add/remove that is causing your leak. Have you confirmed this leak on various backends (eg Agg, PDF, PS)? |
|
From: João L. S. <js...@fc...> - 2010-05-28 14:11:16
|
On 05/28/2010 09:18 AM, Pearu Peterson wrote: > , say, every second and the experiment > can last hours, I have tried two approaches: > 1) clear axes and plot new experimental data - this is > slow and takes too much cpu resources. > 2) remove lines and plot new experimental data - this is > fast enough but unfortunately there seems to be a memory > leakage, the application runs out of memory. > Why don't you just update the exiting line with the new data, as shown in the animation examples in http://matplotlib.sourceforge.net/examples/animation/index.html ? For example: # import numpy from numpy.testing.utils import memusage import matplotlib.pyplot as plt x = range (1000) fig = plt.figure() axes1 = fig.add_subplot( 111 ) y = numpy.random.rand (len (x)) line = None while 1: if not line: line, = axes1.plot(x, y, 'b', label='data') else: line.set_data(x,y) fig.canvas.draw() print memusage ()/(1024.0*1024.0),"MB", len (axes1.lines) #eof Regards, João Silva |
|
From: Pearu P. <pe...@ce...> - 2010-05-28 08:51:22
|
Hi,
In an application that updates a plot with
new experimental data, say, every second and the experiment
can last hours, I have tried two approaches:
1) clear axes and plot new experimental data - this is
slow and takes too much cpu resources.
2) remove lines and plot new experimental data - this is
fast enough but unfortunately there seems to be a memory
leakage, the application runs out of memory.
Here follows a simple script that demonstrates the
leakage problem:
#
import numpy
from numpy.testing.utils import memusage
import matplotlib.pyplot as plt
x = range (1000)
axes1 = plt.figure().add_subplot( 111 )
y = numpy.random.rand (len (x))
while 1:
if 1:
# leakage
for line in axes1.lines:
if line.get_label ()=='data':
line.remove()
else:
# no leak, but slow
axes1.clear()
axes1.plot(x, y, 'b', label='data')
print memusage (), len (axes1.lines)
#eof
When running the script, the memory usage
is increasing by 132 kbytes per iteration, that is,
with an hour this example application will consume
464MB RAM while no new data has been generated. In real
application this effect will be even worse.
So, I am looking for an advice how to avoid
this memory leakage without clearing axes.
I am using matplotlib from SVN.
Thanks,
Pearu
|