[matplotlib-devel] better tick marks

2007-03-27 Thread Tom Holroyd (NIH/NIMH) [E]

I've got a routine, attached, which is simple and fast, and returns very nicely 
spaced ticks along with the number of minor ticks. It's an old algorithm from a 
'73 ACM article, but tried and true. I suppose this should be implemented as a 
Locator, but I'm not very familiar with the pylab code. Perhaps someone could 
demonstrate the appropriate way?
--
Tom Holroyd, Ph.D.
We experience the world not as it is, but as we expect it to be.


tics.py
Description: application/python
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


[matplotlib-devel] memory leaks

2007-03-27 Thread Eric Firing
In 2007, two different major memory leaks have been identified:

1) Eric Pellegrini showed that a loop over figure(); close() leaks.  I 
have verified that this occurs with any interactive backend, but not 
with non-interactive backends.  This may be the same problem that was 
reported in other messages, such as one by Dylan Passmore in January.

2) There is a recent thread "Re: Memory leak in basemap or matplotlib" 
showing that even with a non-interactive backend, a seemingly-pointless 
call to cla() is needed to prevent a leak.

I would like to suggest that we try harder to solve these problems ASAP. 
  This kind of malfunctioning at the core of mpl worries me.

I have spent quite a bit of time trying to figure out (1), and I have 
tracked it down to the NavigationToolbar2.  Eliminate the toolbar by 
putting None in the rc slot, and the memory leak vanishes.  It looks to 
me like some explicit call to a destroy method may be needed to 
dismantle the toolbar when a figure is closed and/or deleted.  I suspect 
that each gui toolkit is keeping references to components, and the 
toolbar is not getting the word when the window is destroyed. 
gc.garbage verifies that the toolbar components are what get left behind.

So, I hope a gui toolkit backend wizard can step forward and say, "Of 
course, we just need to put a __del__ method here with a call to 
destroy()", or something like that.

I have spent much less time on (2), and made no progress.

We are relying very heavily on the gc--mpl has cyclic references all 
over the place.  Is anyone sure that we don't need explicit gc support 
in any of the extension code?  Can *everything* in the extension code be 
handled correctly with reference counting?  Is this independent of how 
things defined in extension code are used at the python level?

It is not clear to me that gc debugging methods even allow one to see 
problems in extension code that do not have some degree of gc support. 
The standard documentation of the gc module and the gc C API is minimal.

Eric

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] memory leaks

2007-03-27 Thread Eric Firing
I can add a couple of things to item (1) below.  First, the problem 
occurs only with toolbar2, not with classic or None.  Second, a script 
that illustrates it is attached.


Eric

Eric Firing wrote:

In 2007, two different major memory leaks have been identified:

1) Eric Pellegrini showed that a loop over figure(); close() leaks.  I 
have verified that this occurs with any interactive backend, but not 
with non-interactive backends.  This may be the same problem that was 
reported in other messages, such as one by Dylan Passmore in January.


2) There is a recent thread "Re: Memory leak in basemap or matplotlib" 
showing that even with a non-interactive backend, a seemingly-pointless 
call to cla() is needed to prevent a leak.


I would like to suggest that we try harder to solve these problems ASAP. 
  This kind of malfunctioning at the core of mpl worries me.


I have spent quite a bit of time trying to figure out (1), and I have 
tracked it down to the NavigationToolbar2.  Eliminate the toolbar by 
putting None in the rc slot, and the memory leak vanishes.  It looks to 
me like some explicit call to a destroy method may be needed to 
dismantle the toolbar when a figure is closed and/or deleted.  I suspect 
that each gui toolkit is keeping references to components, and the 
toolbar is not getting the word when the window is destroyed. 
gc.garbage verifies that the toolbar components are what get left behind.


So, I hope a gui toolkit backend wizard can step forward and say, "Of 
course, we just need to put a __del__ method here with a call to 
destroy()", or something like that.


I have spent much less time on (2), and made no progress.

We are relying very heavily on the gc--mpl has cyclic references all 
over the place.  Is anyone sure that we don't need explicit gc support 
in any of the extension code?  Can *everything* in the extension code be 
handled correctly with reference counting?  Is this independent of how 
things defined in extension code are used at the python level?


It is not clear to me that gc debugging methods even allow one to see 
problems in extension code that do not have some degree of gc support. 
The standard documentation of the gc module and the gc C API is minimal.


Eric

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


#!/usr/bin/env python
'''
This illustrates a leak that occurs with any interactive backend.
'''
import os, sys, time
import gc
import matplotlib

matplotlib.use('TkAgg') # or TkAgg or WxAgg or QtAgg or Gtk
matplotlib.rcParams['toolbar'] = 'toolbar2'   # None, classic, toolbar2

import pylab
from matplotlib import _pylab_helpers as ph

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])

gc.disable()
#gc.set_debug(gc.DEBUG_LEAK)
gc.set_debug(gc.DEBUG_UNCOLLECTABLE
| gc.DEBUG_INSTANCES | gc.DEBUG_OBJECTS)

# take a memory snapshot on indStart and compare it with indEnd
indStart, indEnd = 30, 50
for i in range(indEnd):

fig = pylab.figure()
print 'after figure, unreachable:', gc.collect()
print 'total uncollectable:', len(gc.garbage)
#report_memory(i)
#fig.clear()
#pylab.cla()  #no effect
#pylab.clf()   # no effect
#pylab.show()   # makes it worse
pylab.close()
#del(fig)
#gc.collect()  #no effect
val = report_memory(i)
print 'after close, unreachable:', gc.collect()
print 'total uncollectable:', len(gc.garbage)
del(fig)
print 'after del(fig), unreachable:', gc.collect()
print 'total uncollectable:',len(gc.garbage)
if i==indStart: start = val # wait a few cycles for memory usage to stabilize
gc.collect()
print
print 'uncollectable list:', gc.garbage
print
end = val
if i > indStart:
print 'Average memory consumed per loop: %1.4fk bytes\n' % ((end-start)/float(indEnd-indStart))

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel