Amaury Forgeot d'Arc schrieb:
> The approach I used is a bit brute-force, but it may work for other
> reference leaks:
> - First write a big leaking script:
> for x in xrange(10): leaking_function()
> - Since memory usage does not increase dramatically, it's only a
> refcount problem - no n
Christian Heimes wrote:
> Georg Brandl schrieb:
>
> > Somehow I knew you'd be the one to find the problem :)
>
> Agreed! :)
>
> Amaury is really good in finding loose ends in the parser and AST code.
> I still can't wrap my brain around the AST code but it can see the light
> at the end of the
Georg Brandl schrieb:
> Somehow I knew you'd be the one to find the problem :)
Agreed! :)
Amaury is really good in finding loose ends in the parser and AST code.
I still can't wrap my brain around the AST code but it can see the light
at the end of the code.
_
Amaury Forgeot d'Arc schrieb:
> On Fri, Mar 28, 2008 at 11:50 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> While preparing the Python-AST compilation patch, I noticed that each
>> class nested in a class leaks one reference (2.5 and trunk).
>>
>> It wasn't found by regrtest -R because it only h
On Fri, Mar 28, 2008 at 11:50 AM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> While preparing the Python-AST compilation patch, I noticed that each
> class nested in a class leaks one reference (2.5 and trunk).
>
> It wasn't found by regrtest -R because it only happens on compiling,
> and it seems
While preparing the Python-AST compilation patch, I noticed that each
class nested in a class leaks one reference (2.5 and trunk).
It wasn't found by regrtest -R because it only happens on compiling,
and it seems that all snippets compiled during the tests as opposed to
on import didn't contain su
