Eric Firing wrote:
> So, this test is still showing problems, with similar memory
> consumption in these three backends.
Not necessarily. By default, Python allocates large pools from the
operating system and then manages those pools itself (though its
PyMalloc call). Prior to Python 2.5, thos
Michael Droettboom wrote:
> Eric Firing wrote:
>> So, this test is still showing problems, with similar memory
>> consumption in these three backends.
> Not necessarily. By default, Python allocates large pools from the
> operating system and then manages those pools itself (though its
> PyMall
Norbert,
Revision 3445 has some very small changes to fix problems resulting from
your reorganization. The questions of module and other naming are still
open.
Eric
-
This SF.net email is sponsored by DB2 Express
Downloa
More results:
I've built and tested a more recent pygtk+ stack. (glib-2.12,
gtk+-2.10.9, librsvg-2.16.1, libxml2-2.6.29, pygobject-2.13.1,
pygtk-2.10.4...). The good news is that the C-level leaks I was seeing
in pygtk 2.2 and 2.4 are resolved. In particular, using an SVG icon and
Gdk rende
Forgot to attach the patches.
Oops,
Mike
Michael Droettboom wrote:
More results:
I've built and tested a more recent pygtk+ stack. (glib-2.12,
gtk+-2.10.9, librsvg-2.16.1, libxml2-2.6.29, pygobject-2.13.1,
pygtk-2.10.4...). The good news is that the C-level leaks I was seeing
in pygtk 2.2
On 7/2/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> Forgot to attach the patches.
Michael -- if you send me your sf ID I'll add you to the committers
list and you can check these in directly.
Vis-a-vis the gtk question, I agree that we should encourage people to
upgrade who are suffering f
John Hunter wrote:
> On 7/2/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> Forgot to attach the patches.
>
> Michael -- if you send me your sf ID I'll add you to the committers
> list and you can check these in directly.
mdboom
> Vis-a-vis the gtk question, I agree that we should encourage pe
