[Tim]
>> and filecmp contains a module-level _cache with a funky scheme for
>> avoiding file comparisons if various os.stat() values haven't changed.
>> But st_mtime on Windows doesn't necessarily change when a file is
>> modified -- it has limited resolution (2 seconds on FAT32, and I'm
>> having
[Tim and Martin talking about leak tests when running regtest with -R]
I've disabled the LEAKY_TESTS exclusion in build.sh. This means if
any test reports leaks when regtest.py -R :: is run, mail will be sent
to python-checkins. The next run should kick off in a few hours (4
and 16 ET). We'll s
Tim Peters wrote:
> and filecmp contains a module-level _cache with a funky scheme for
> avoiding file comparisons if various os.stat() values haven't changed.
> But st_mtime on Windows doesn't necessarily change when a file is
> modified -- it has limited resolution (2 seconds on FAT32, and I'm
>
[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
I think I found the cause for test_filecmp giving different results
across runs, at least on Windows. It appears to be due to this test
line:
self.failUnless(d
[moving to python-dev]
[Tim, gets different results across whole runs of
python_d ../Lib/test/regrtest.py -R 2:40: test_filecmp test_exceptions
]
>>> Does that make any sense? Not to me -- I don't know of a clear reason
>>> other than wild loads/stores for why such runs should ever differ.
[Neal Norwitz]
> ...
> I have disabled the leak warning for:
>
> LEAKY_TESTS="test_(cmd_line|ctypes|filecmp|socket|threadedtempfile|threading|urllib2)
>
> This is an attempt to reduce the spam. Would people rather me reduce
> this list so we can try to find the problems? The test runs 2 times
> p
On 4/22/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [19 Apr 2006, Neal Norwitz]
> > test_cmd_line leaked [0, 17, -17] references
> > test_filecmp leaked [0, 13, 0] references
> > test_threading_local leaked [-93, 0, 0] references
> > test_urllib2 leaked [-121, 88, 99] references
>
> Thanks to Thom
[19 Apr 2006, Neal Norwitz]
> test_cmd_line leaked [0, 17, -17] references
> test_filecmp leaked [0, 13, 0] references
> test_threading_local leaked [-93, 0, 0] references
> test_urllib2 leaked [-121, 88, 99] references
Thanks to Thomas digging into test_threading_local, I checked in what
appeare
[Thomas Wouters]
> I did the same narrowing-down last week, and submitted a patch to add
> cycle-GC support to itertools.tee . It really needs it.
I agree.
> Come to think of it, now that I remember how to properly do GC, I think
> the patch cuts some corners, but it solved the problem.
You mean
On 3/5/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
test_generators leaked [255, 255, 255] references254 of those 255 leaks seem to be caused by the two recursive-generator examples at the bottom of the fun_tests doctest: fib() and the last m235() implementation. The recursiveness isn't in the gener
10 matches
Mail list logo
