On Thu, Jul 17, 2008 at 12:42 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Anyone have any thoughts on this? It seems like it's serious enough to try
> to resolve before the next bugfix release.
I think what we are seeing here is the known GUI figure canvas leak
(Michael, I think our offli
Anyone have any thoughts on this? It seems like it's serious enough to
try to resolve before the next bugfix release.
Cheers,
Mike
Michael Droettboom wrote:
> Yes, it should be. I'm further puzzled that removing "del
> Gcf.figs[num]" prevents the memory leak. There is some side effect that
Yes, it should be. I'm further puzzled that removing "del
Gcf.figs[num]" prevents the memory leak. There is some side effect that
happens when all of the figures have been closed (I think it shuts down
the GUI mainloop), that keeping at least one figure around at all times
avoids. But I have
I am puzzled. Wasn't the whole point of close() to avoid memory leaks?
Laurent
2008/7/15 Michael Droettboom <[EMAIL PROTECTED]>:
> Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.
>
> Manuel has discovered a seemingly generic leak that occurs when
> pyplot.close() is call
Yes, as of r5747 twinx (well, shared axes specifically) no longer leaks.
Manuel has discovered a seemingly generic leak that occurs when
pyplot.close() is called and running a GUI backend. I can confirm his
results with the script he last sent.
Cheers,
Mike
Manuel Metz wrote:
> John Hunter wr
John Hunter wrote:
On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
I can confirm this.
Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
also seems to resolve the leak. But I have no idea why, so I won't
commit it just yet. I don't have mu
On Mon, Jul 14, 2008 at 3:05 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> I can confirm this.
>
> Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
> also seems to resolve the leak. But I have no idea why, so I won't
> commit it just yet. I don't have much time to lo
I can confirm this.
Commenting out "del Gcf.figs[num]" in Gcf.destroy (in _pylab_helpers.py)
also seems to resolve the leak. But I have no idea why, so I won't
commit it just yet. I don't have much time to look deeper now. Does
anyone (who probably understands figure management better than m
Michael Droettboom wrote:
> Which backend?
GTK, GTKAgg, TK, but not with any backend without a window: Agg, Cairo,
PS, PDF, SVG ...
Cheers,
Manuel
> Cheers,
> Mike
>
> Manuel Metz wrote:
>> Michael Droettboom wrote:
>>> Thanks for the report. So we can diagnose this, what version of
>>> m
Which backend?
Cheers,
Mike
Manuel Metz wrote:
> Michael Droettboom wrote:
>> Thanks for the report. So we can diagnose this, what version of
>> matplotlib are you reporting this for?
>>
>> Also, you may be interested in the following FAQ (and the one
>> following it):
>>
>> http://matplotlib.
Michael Droettboom wrote:
> Thanks for the report. So we can diagnose this, what version of
> matplotlib are you reporting this for?
>
> Also, you may be interested in the following FAQ (and the one following it):
>
> http://matplotlib.sourceforge.net/faq.html#LEAKS
Hi,
I tested this with
Thanks for the report. So we can diagnose this, what version of
matplotlib are you reporting this for?
Also, you may be interested in the following FAQ (and the one following it):
http://matplotlib.sourceforge.net/faq.html#LEAKS
Cheers,
Mike
laurent oget wrote:
> i forgot two imports.
>
> >>>
i forgot two imports.
>
import math
import gc
import pylab as PL
def looptest():
while(1):
fig=PL.figure(1)
ax=fig.add_subplot(211)
ax.set_position((0,0,0.9,0.45))
ax1=PL.twinx(ax)
t=range(1000)
st=[math.sin(x*0.01)
I think i narrowed down the memory leak i have been chasing for a while.
If i remove the call to twinx i get a slow leak, which would cause me
trouble
after a very long time. With the call to twinx, however i am losing
thousands of objects
at each loop.
Thanks,
Laurent
14 matches
Mail list logo
