matplotlib-devel Mailing List for matplotlib (Page 2)

Abraham Schneider wrote:
> Just tried the 'rm -fr ...../site-packages/matplotlib', and I still get 
> the same behavior. Also, if that were the cause, then shouldn't it also 
> crash outside of ipython as well?
I should note that I'v also seen this same crash with 0.83.2 official.
I haven't bothered to track it down, because I hardly ever use GTK except when 
testing for problems on the list.
It may not happen outside of ipython, if somehow the crash is triggered by the 
threading tricks which ipython uses to enable GTK interactive use. Nasty...
Cheers,
f

Just tried the 'rm -fr ...../site-packages/matplotlib', and I still get 
the same behavior. Also, if that were the cause, then shouldn't it also 
crash outside of ipython as well?
John Hunter wrote:
>>>>>>"Abraham" == Abraham Schneider <ab...@cn...> writes:
>>>>>> 
>>>>>>
>
> Abraham> Okay, here's the patch. I'm also including a quick demo
> Abraham> with a button that gets added directly to the canvas.
>
>OK, great. Steve could you take a look at this when you get a minute
>and give some feedback about whether you think this is a god idea.
>
> Abraham> On a side note, I can't get the CVS version to work under
> Abraham> ipython, and get this error (it was working fine with
> Abraham> 0.83.2):
> Abraham> ---------------------------------------------------------------------------
> Abraham> exceptions.SystemError Traceback (most recent call last)
>
> Abraham> SystemError: Objects/moduleobject.c:48: bad argument to
> Abraham> internal function Segmentation fault
>
>Have you done the standard clean install
>
> > sudo rm -rf build /your/path/to/site-packages/matplotlib
> > sudo python setup.py install
>
>I recently upgraded pycxx in CVS and my first guess is you have some stale
>object code lying around.
>
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Okay, here's the patch. I'm also including a quick demo
 Abraham> with a button that gets added directly to the canvas.
OK, great. Steve could you take a look at this when you get a minute
and give some feedback about whether you think this is a god idea.
 Abraham> On a side note, I can't get the CVS version to work under
 Abraham> ipython, and get this error (it was working fine with
 Abraham> 0.83.2):
 Abraham> ---------------------------------------------------------------------------
 Abraham> exceptions.SystemError Traceback (most recent call last)
 Abraham> SystemError: Objects/moduleobject.c:48: bad argument to
 Abraham> internal function Segmentation fault
Have you done the standard clean install
 > sudo rm -rf build /your/path/to/site-packages/matplotlib
 > sudo python setup.py install
I recently upgraded pycxx in CVS and my first guess is you have some stale
object code lying around.
JDH

Okay, here's the patch. I'm also including a quick demo with a button 
that gets added directly to the canvas.
On a side note, I can't get the CVS version to work under ipython, and 
get this error (it was working fine with 0.83.2):
---------------------------------------------------------------------------
exceptions.SystemError Traceback (most 
recent call last)
SystemError: Objects/moduleobject.c:48: bad argument to internal function
Segmentation fault
Abe
John Hunter wrote:
>>>>>>"Abraham" == Abraham Schneider <ab...@cn...> writes:
>>>>>> 
>>>>>>
>
> Abraham> Is there a reason that for the GTK backend
> Abraham> gtk.DrawingArea was used instead of gtk.Layout? As far as
> Abraham> I can tell gtk.Layout can do everything that
> Abraham> gtk.DrawingArea can, but has the additional advantage
> Abraham> that you can place widgets on the canvas, which can be
> Abraham> extremely useful. I tried a quick patch (which I can send
> Abraham> if anyone wants), where I got it working fine. The main
> Abraham> changes (there aren't many) are where changes to the
> Abraham> window would be make, 'self.window' needs to be replaced
> Abraham> with 'self.bin_window', and I also found I had to connect
> Abraham> to the 'size-allocate' event to have it properly
> Abraham> redrawwhen the window size changed.
>
>
> Abraham> As a side note, one feature that this might allow, would
> Abraham> be to allow for matplotlib-widgets to be drawn using the
> Abraham> GTK if the backend were detected (much like how SWT, for
> Abraham> Eclipse works).
>
>
>This sounds useful -- could you post a patch against CVS on the
>sourceforge site (and email here when it is up) so we can test it.
>I think the only reason that this wasn't used initially was ignorance
>on my part. I was hoping I could blame version numbers, that this
>wasn't available in pygtk 1.99.16 when mpl was released, but on quick
>inspection this explanation does not appear to hold water.
>
> Abraham> Also, on a complete tanget, does anyone know of a good
> Abraham> method of saving animations done in MPL? The only two
> Abraham> methods that I can think of right now are to (1)
> Abraham> interface with matlab, or (2) save each frame, and create
> Abraham> an animated gif. As my movies are fairly large, neither
> Abraham> seem like a great option.
>
> Abraham> After searching around some, I found pymedia, but when I
> Abraham> try to import it, all it manages to do is crash. While a
> Abraham> SWIG interface could be created for FFMPEG, it would be
> Abraham> nice if there were some other option.
>
>Something like this could usefully be placed in a toolkit following
>the basemap model, where adding an extra layer of extension code
>doesn't pose any installation or distribution woes for the core. I
>think it would be useful.
>
>In the meantime, I typically save a series of PNGs and convert them to
>MPEG using image magick's "convert" or mencoder.
>
> http://matplotlib.sourceforge.net/faq.html#MOVIE
>
>See also examples/movie_demo.py.
>
>If you come up with other/better alternatives, let us know.
>
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by:
>Tame your development challenges with Apache's Geronimo App Server. Download
>it for free - -and be entered to win a 42" plasma tv or your very own
>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
>

There is a new method in the figure canvas in CVS that I would like
the maintainers of the various GUI backends to implement 
class FigureCanvasYourBackend
 def resize(self, w, h):
 """
 set the canvas size in pixels
 """
 pass
This should set the canvas (not window) size and trigger a GUI resize
event so that the window is resized accordingly. There is a reference
implementation in backend_gtk.py. You should be able to lift the
logic for computing the new canvas size directly from that code.
Among other things, this will allow better control of the canvas size
from a script or shell. Eg, the following works with GTKAgg in an
interactive session:
 In [1]: fig = figure()
 In [2]: fig.set_figsize_inches(3,4,forward=True)
 In [3]: fig.canvas.resize(500,600)
Ie, you can set the canvas size either in pixels or inches depending
on which method you choose. 
Also, I added a new connect signal 'resize_event' that triggers a
backend_bases.ResizeEvent on a canvas.resize. You should call
 self.resize_event()
from the part of your code that handles GUI configure events (see for
example the GTK and GTKAgg backends). Note depending on your toolkit,
you may not want to call this from the FigureCanvas.resize method.
Eg, in GTK* calling "canvas.resize" triggers a call to
canvas.configure_event, which in turn sets the new figure size
properties and once all this is done, calls canvas.resize_event.
Here is some test code
 from pylab import figure, connect, show
 fig = figure()
 def resize(event):
 print 'resize canvas', event.width, event.height
 connect('resize_event', resize)
 show()
Checking in lib/matplotlib/backend_bases.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/backend_bases.py,v <-- backend_bases.py
new revision: 1.69; previous revision: 1.68
Thanks!
JDH

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:
 Abraham> Is there a reason that for the GTK backend
 Abraham> gtk.DrawingArea was used instead of gtk.Layout? As far as
 Abraham> I can tell gtk.Layout can do everything that
 Abraham> gtk.DrawingArea can, but has the additional advantage
 Abraham> that you can place widgets on the canvas, which can be
 Abraham> extremely useful. I tried a quick patch (which I can send
 Abraham> if anyone wants), where I got it working fine. The main
 Abraham> changes (there aren't many) are where changes to the
 Abraham> window would be make, 'self.window' needs to be replaced
 Abraham> with 'self.bin_window', and I also found I had to connect
 Abraham> to the 'size-allocate' event to have it properly
 Abraham> redrawwhen the window size changed.
 Abraham> As a side note, one feature that this might allow, would
 Abraham> be to allow for matplotlib-widgets to be drawn using the
 Abraham> GTK if the backend were detected (much like how SWT, for
 Abraham> Eclipse works).
This sounds useful -- could you post a patch against CVS on the
sourceforge site (and email here when it is up) so we can test it.
I think the only reason that this wasn't used initially was ignorance
on my part. I was hoping I could blame version numbers, that this
wasn't available in pygtk 1.99.16 when mpl was released, but on quick
inspection this explanation does not appear to hold water.
 Abraham> Also, on a complete tanget, does anyone know of a good
 Abraham> method of saving animations done in MPL? The only two
 Abraham> methods that I can think of right now are to (1)
 Abraham> interface with matlab, or (2) save each frame, and create
 Abraham> an animated gif. As my movies are fairly large, neither
 Abraham> seem like a great option.
 Abraham> After searching around some, I found pymedia, but when I
 Abraham> try to import it, all it manages to do is crash. While a
 Abraham> SWIG interface could be created for FFMPEG, it would be
 Abraham> nice if there were some other option.
Something like this could usefully be placed in a toolkit following
the basemap model, where adding an extra layer of extension code
doesn't pose any installation or distribution woes for the core. I
think it would be useful.
In the meantime, I typically save a series of PNGs and convert them to
MPEG using image magick's "convert" or mencoder.
 http://matplotlib.sourceforge.net/faq.html#MOVIE
See also examples/movie_demo.py.
If you come up with other/better alternatives, let us know.
JDH

Is there a reason that for the GTK backend gtk.DrawingArea was used 
instead of gtk.Layout? As far as I can tell gtk.Layout can do everything 
that gtk.DrawingArea can, but has the additional advantage that you can 
place widgets on the canvas, which can be extremely useful. I tried a 
quick patch (which I can send if anyone wants), where I got it working 
fine. The main changes (there aren't many) are where changes to the 
window would be make, 'self.window' needs to be replaced with 
'self.bin_window', and I also found I had to connect to the 
'size-allocate' event to have it properly redrawwhen the window size 
changed.
As a side note, one feature that this might allow, would be to allow for 
matplotlib-widgets to be drawn using the GTK if the backend were 
detected (much like how SWT, for Eclipse works).
Also, on a complete tanget, does anyone know of a good method of saving 
animations done in MPL? The only two methods that I can think of right 
now are to (1) interface with matlab, or (2) save each frame, and create 
an animated gif. As my movies are fairly large, neither seem like a 
great option.
After searching around some, I found pymedia, but when I try to import 
it, all it manages to do is crash. While a SWIG interface could be 
created for FFMPEG, it would be nice if there were some other option.
Thanks,
Abe

> Ed> The shutil.move() is somewhat more robust than os.rename().
> Ed> For more information see
> Ed> http://mail.python.org/pipermail/python-list/2005-February/266553.html
> Ed> and /266632.html.
>
>John>Is this expected to work across platforms, eg win32, linux, os x and
>John>unix?
> 
>
Yes, I believe so. Confirmed on Linux. The shutil.py source code 
implements move() by copying the file, including stat info, and then 
deleting it. On Mac filesystems it ignores resource forks, but the DVI 
file should be stored entirely in the data fork.

On Wednesday 01 June 2005 18:57, Nicolas Girard wrote:
> On Wednesday 01 June 2005 18:50, Fernando Perez wrote:
> > I wonder though: if we also get 'reversed' colormaps, is this going to
> > be a cause for confusion with the 'reversed' colorbar keyword? It may
> > not be a problem in the end, as long as the two different ideas are
> > clearly explained, to prevent others falling into the same trap I did.
>
> Please feel free to use any keyword you want, provided the feature is
> implemented ! English is not my native language, so I just came to
> "reverse" as the closest word to what I had in mind, but for sure there
> must be better alternatives (invert, mirror, whatever)
>
What do you think about this point, finally ? Do you think such option should 
be added to colorbars ?
As you can see on http://nicolasgirard.nerim.net/img/artifacts.png it would 
allow colors from the colorbars to fit colors in the figure much better...
Cheers,
Nicolas

I just verified that shutil.move works fine in Windows 98.
Gary R.
John Hunter wrote:
>>>>>>"Ed" == Ed Schofield <sch...@ft...> writes:
> 
> 
> >> shutil.move(dvibase, dvifile)
> 
> Ed> The shutil.move() is somewhat more robust than os.rename().
> Ed> For more information see
> Ed> http://mail.python.org/pipermail/python-list/2005-February/266553.html
> Ed> and /266632.html.
> 
> Is this expected to work across platforms, eg win32, linux, os x and
> unix?
> 
> JDH

>>>>> "Ed" == Ed Schofield <sch...@ft...> writes:
 >> shutil.move(dvibase, dvifile)
 Ed> The shutil.move() is somewhat more robust than os.rename().
 Ed> For more information see
 Ed> http://mail.python.org/pipermail/python-list/2005-February/266553.html
 Ed> and /266632.html.
Is this expected to work across platforms, eg win32, linux, os x and
unix?
JDH

There is some news about the STIX fonts. It looks like they will be releasing 
a beta sometime in October (translation: November-December). At this time, 
they have a draft copy of the license up on their website and are welcoming 
comments.
http://www.stixfonts.org/user_license.html
What I saw was encouraging, but maybe somebody else might see something that 
concerns bundling and distributing with MPL.
Darren

>>>>> "John" == John Hunter <jdh...@ac...> writes:
 John> self.canvas.set_size_request(w,h)
I've thought about this a little more and realize we have to proceed
with some caution. A minor nit is that set_size_request is the wrong
name, since this sets the minimum size in the GTK API, which is not
what we mean. We want something like "resize". Here is an
implementation for gtk which can be called on the canvas and resizes
the window to account for the other objects in the window
 def resize(self, w, h):
 """
 set the canvas size in pixels
 """
 # the window size
 winw, winh = self.parent.parent.get_size()
 tmp, tmp, myw, myh = self.get_allocation()
 padw = winw-myw
 padh = winh-myh
 neww = w+padw
 newh = h+padh
 self.parent.parent.resize(neww, newh)
The question is: how do we want to expose this? If the user calls
fig.set_figsize_inches, should the Figure forward the call to
canvas.resize? We have to be careful of a potential infinite
recursion, because the resize method will trigger a GUI resize event
which calls fig.set_figsize_inches in the various backends.
We could define an optional kwarg to fig.set_figsize_inches, eg
 def set_figsize_inches(self, w, h, forward=False):
where when forward is False the call is not forwarded on to the
canvas. This would enable the canvas to set the figure size on mouse
resizes, the typical case, w/o triggering the infinite recursion.
My inclination is to support the user being able to use either the
fig.set_figsize_inches method or the canvas.resize method because
sometimes it's more natural to think in terms of inches and sometimes
pixels.
class Canvas:
 def resize(self, w, h):
 # resize the window/canvas this will automatically trigger a
 # GUI resize event that will cause the figure size to be updated
 # because the various backends already call set_figsize_inches on
 # resize events
class Figure:
 def set_figsize_inches(self, w, h, forward=False):
 # by default this will not forward events to canvas.resize
 # but when forward is True call self.canvas.resize
This prevents the infinite recursion on mouse resizes (the resize
event calls set_figsize_inches and the event is not propagated back to
canvas.resize).
The user who *wants* to resize the canvas, eg from the shell, calls
 fig.set_figsize_inches(w, h, forward=True)
which triggers canvas.resize(w,h) which triggers the GUI resize event
which in turn calls fig.set_figsize_inches(w, h, forward=False) and
the recursion is blocked. It seems a bit strange that
fig.set_figsize_inches triggers a call to itself, but this is where my
screwy Friday afternoon logic has led me in thinking about how to
support resizes in the three ways people want to do it
 * with the mouse
 * with fig.set_figsize_inches(winch, hinch)
 * with canvas.resize(wpixe, hpixel)
On light testing, this appears to be working in GTK:
 Checking in lib/matplotlib/figure.py;
 /cvsroot/matplotlib/matplotlib/lib/matplotlib/figure.py,v <-- figure.py
 new revision: 1.37; previous revision: 1.36
 done
 Checking in lib/matplotlib/backends/backend_gtk.py;
 /cvsroot/matplotlib/matplotlib/lib/matplotlib/backends/backend_gtk.py,v <-- backend_gtk.py
 new revision: 1.112; previous revision: 1.111
Or is there a simpler solution that is escaping me?
JDH

Hello all,
I've fixed the quiver function so it works on non-square arrays. I
believe I've generated a patch against the 0.83.2 sources properly, but
this is the first time I've done this.
Regards,
John
--
John Byrnes (by...@bu...)
Graduate Student
Electrical Engineering
Boston University
The law will never make men free; it is men who have got to make the law free.
		-- Henry David Thoreau

On Thu, 2005年09月08日 at 23:18 -0500, John Hunter wrote:
> Yes. We need to abstract the set size request call across backends to
> make it work properly, eg GTK's win.set_size_request. This should be
> a FigureCanvas method. The base class should "pass" (ignore) and the
> derived GUI classes should implement the proper GUI code. My
> intuition is that the args to this function should be width, height in
> pixels. The fig.set_figsize_inches will compute w,h in pixels and
> call something like
If this API is being corrected I'd suggest adding a setting somewhere in
the api of the gui backends to allow setting an additional size and dpi
to be used when a user presses the save button on the toolbar (and give
this setting a default that fits onto both letter and A4 paper). This
behaviour is probably preferable for the majority of users (who want to
save things at a size they can print) and could be easily overridden
where it is not. Personally I would also find it useful to be able to
easily use gui tools to zoom and pan multiple plots and then to produce
outputs which are of a consistent size (although I'll probably produce
my own subclass of a backend to do this if others don't). 
Whilst I'd be willing to produce a patch to do this myself it seems
better in this case for someone more familiar with the each of the
backends to do so.
Nick

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> set_figsize_inches will change the printed output,
 Darren> although it does not seem to effect the screen size (is
 Darren> this a bug?).
Yes. We need to abstract the set size request call across backends to
make it work properly, eg GTK's win.set_size_request. This should be
a FigureCanvas method. The base class should "pass" (ignore) and the
derived GUI classes should implement the proper GUI code. My
intuition is that the args to this function should be width, height in
pixels. The fig.set_figsize_inches will compute w,h in pixels and
call something like
 self.canvas.set_size_request(w,h)
where self is a Figure instance.
This has come up before in other contexts. If you could file this on
the sf site, it'll help keep it from falling through the cracks. If
you also can define the base class method in CVS and write the
docstring, that will help. Once/if you have done this, reply to the
list to ask other GUI backend maintainers to implement the behavior
for their respective GUIs.
Thanks,
JDH

Thanks Darren!
I managed to wite a bit of wrapper code to handle this now.
The only bad thing to data is that I hardcode "A4".
Maybe this can be moved into backend_ps.
<snip>
def my_print(self, fname,orientation=None):
 w = self.figure.figwidth.get()
 h = self.figure.figheight.get() 
 a4w = 8.25
 a4h = 11.25
 
 if orientation is None:
 # auto-oriented
 if w > h:
 orientation = 'landscape'
 else:
 orientation = 'portrait'
 ds = None
 if orientation == 'landscape':
 ds = min(a4h/w,a4w/h)
 else:
 ds = min(a4w/w,a4h/h)
 ow = ds * w
 oh = ds * h
 self.figure.set_figsize_inches((ow,oh)) 
 self.canvas.print_figure(fname,orientation=orientation)
 

On Thursday 08 September 2005 6:30 pm, Mal...@cs... wrote:
> "My users" want to see the ps output scaled to A4, which I also think is
> the correct behaviour. Usually you increase the size of the window on the
> screen to get a better view of things, but when you want to print the
> figure it should adjust to the papersize. Also, how do you know the figure
> is larger than the papersize?!
f = figure(figsize=(5,4))
# resize with mouse, and when you are ready to save:
f.set_figsize_inches(5,4)
savefig('t.ps')
set_figsize_inches will change the printed output, although it does not seem 
to effect the screen size (is this a bug?).
Darren

"My users" want to see the ps output scaled to A4, which I also think is =
the correct behaviour. Usually you increase the size of the window on =
the screen to get a better view of things, but when you want to print =
the figure it should adjust to the papersize.
Also, how do you know the figure is larger than the papersize?!

Yes, I've also seen the same problem and have been meaning to fix it. I've=
=20
not got time right now, but will look into it when I do.
-- Paul
On 9/8/05, Malte Marquarding <Mal...@cs...> wrote:
>=20
> Hi,
>=20
> I haven't managed to get savefig to give correct results on the following=
=20
> (I
> am using ps.papersize=3D"A4")
>=20
>=20
> subplot(211)
> subplot(222)
> #resize the window by mouse
> savefig("t.ps <http://t.ps>",orientation=3D"landscape")
>=20
> If viewed in a e.g. "gv" the drawings extend past the "A4" page.
>=20
> This behaviour seems only be present after resizing the figure window.
>=20
> Cheers,
> Malte.
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle=20
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Thursday 08 September 2005 1:55 am, Malte Marquarding wrote:
> Hi,
>
> I haven't managed to get savefig to give correct results on the following
> (I am using ps.papersize="A4")
>
>
> subplot(211)
> subplot(222)
> #resize the window by mouse
> savefig("t.ps",orientation="landscape")
>
> If viewed in a e.g. "gv" the drawings extend past the "A4" page.
>
> This behaviour seems only be present after resizing the figure window.
I am not able to reproduce this behavior, unless I resize the window to make 
the figure larger than A4 paper. That's not what you are talking about, is 
it?
-- 
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...
http://people.ccmr.cornell.edu/~dd55/

x11FontDirectory() uses '/usr/sbin/chkfontpath' if available, to find system 
font directories.
I believe chkfontpath was developed to work with the old X server method
of font handling and is now obsolete, and gives unreliable results. 
On my system (Fedora 4) chkfontpath lists subdirectories of 
 /usr/X11R6/lib/X11/fonts/
 /usr/share/fonts/
but fails to list
 /usr/share/fonts/bitstream-vera
I propose deleting the use of chkfontpath, and simply using:
X11FontDirectories = [
 "/usr/X11R6/lib/X11/fonts/TTF/",
 "/usr/share/fonts/"
 ]
Also, fontconfig (part of the newer font handling system than makes chkfontpath
obsolete) provides utilities to query fonts:
'fc-list' lists the available fonts,
'fc-cache -v' (as root) lists the font directories.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

Hi,
I haven't managed to get savefig to give correct results on the following (I 
am using ps.papersize="A4")
subplot(211)
subplot(222)
#resize the window by mouse
savefig("t.ps",orientation="landscape")
If viewed in a e.g. "gv" the drawings extend past the "A4" page.
This behaviour seems only be present after resizing the figure window.
Cheers,
Malte.

Hi all,
The file texmanager.py up until matplotlib 0.83.2 throws an exception 
when the current directory is on a different filesystem from the 
.matplotlib/tex.cache directory:
OSError: [Errno 18] Invalid cross-device link
This patch helps:
124c124
< os.rename(dvibase, dvifile)
---
 > shutil.move(dvibase, dvifile)
The shutil.move() is somewhat more robust than os.rename(). For more 
information see 
http://mail.python.org/pipermail/python-list/2005-February/266553.html 
and /266632.html.

On Wed, 2005年09月07日 at 12:12 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <N.P...@wa...> writes:
> Nicholas> My patch contained memory leaks which I've fixed in the
> Nicholas> attachment - but I'm not that experienced in c/c++ so
> Nicholas> there could be more I haven't noticed.
>
> You should see little or no leak if everything checks out.
Thanks for the suggestion John. After following it I've found another
two leaks (revised patch attached) and as a result on testing with your
suggestions get following output (at the start):
0 52604 18235
1 52608 18236
2 52608 18235
3 52608 18235
4 52608 18236
5 52608 18235
6 52608 18235
7 52608 18235
8 52612 18235
9 52612 18235
10 52612 18235
11 52612 18235
12 52612 18235
13 52612 18236
14 52612 18235
15 52616 18235
16 52616 18235
17 52616 18235
18 52616 18236
19 52616 18235
20 52616 18235
21 52616 18236
22 52616 18236
23 52616 18235
24 52616 18235
25 52616 18235
26 52616 18235
27 52616 18235
28 52616 18235
29 52616 18236
30 52616 18235
Am I correct in thinking the occasional slight increase in memory is due
to python not me?
Nick