The Windows buildbots are still failing because some tests keep files
opened. This causes subsequent tests which use the same file to fail.
Here is a recent run which had a failure early on:
http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1209/step-test/0
I'm assuming the
On Tue, Apr 1, 2008 at 6:34 AM, Neal Norwitz [EMAIL PROTECTED] wrote:
test_io is the only leaky test on trunk that I know of. I narrowed
down the leaks to the code below.
It's possible there are other leaks in test_io.
n
--
import sys, gc
import _fileio, io
class
I wrote:
FYI, I've uploaded a patch that provides for cross-compilation on
Windows between 32 and 64 bit platforms - all comments invited!
While I have some people's attention I'd like to re-raise another issue I
foresee for x64 builds. I've mentioned this over the last couple of months,
but
On Tue, Apr 1, 2008 at 12:42 AM, Neal Norwitz [EMAIL PROTECTED] wrote:
The Windows buildbots are still failing because some tests keep files
opened. This causes subsequent tests which use the same file to fail.
Here is a recent run which had a failure early on:
test_signal is failing on osx g4:
test test_signal failed -- Traceback (most recent call last):
File /Users/buildslave/bb/trunk.psf-g4/build/Lib/test/test_signal.py,
line 151, in test_main
self.fail(tb)
AssertionError: Traceback (most recent call last):
File
Steven Bethard wrote:
At the sprints, I ran into a bunch of similar errors running the test
suite on my Windows Vista box, even on tests that were properly
cleaning up after themselves in tearDown(). I even tried putting in
sleeps as long as 1 second, to no avail. The only way to get the test
Tim Golden wrote:
Steven Bethard wrote:
At the sprints, I ran into a bunch of similar errors running the test
suite on my Windows Vista box, even on tests that were properly
cleaning up after themselves in tearDown(). I even tried putting in
sleeps as long as 1 second, to no avail. The only
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a remove_file which does something of this sort?
+1 (I was thinking exactly that).
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a remove_file which does something of this sort?
+1 (I was thinking exactly that).
+1 here too. That looks
Howdy Folks-
I hope this is not too off topic. Sadly the current sys.settrace only
allows tracing at the line level. This isn't sufficient to do branch
and path coverage. The main problem is that many boolean operations
can appear on a single line, and so you can't be sure which
conditional
On 1 Apr, 18:27, Steven Bethard [EMAIL PROTECTED] wrote:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a remove_file which does something of this
Giampaolo Rodola' wrote:
On 1 Apr, 18:27, Steven Bethard [EMAIL PROTECTED] wrote:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a remove_file which
On 1 Apr, 21:03, Giampaolo Rodola' [EMAIL PROTECTED] wrote:
On 1 Apr, 18:27, Steven Bethard [EMAIL PROTECTED] wrote:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support
On 1 Apr, 21:06, Tim Golden [EMAIL PROTECTED] wrote:
Giampaolo Rodola' wrote:
On 1 Apr, 18:27, Steven Bethard [EMAIL PROTECTED] wrote:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do,
Giampaolo Rodola' wrote:
Why not just modifying test_support.unlink() like this?
Surely more convenient than modifying the whole suite.
def unlink(filename):
try:
if os.name == 'nt':
os.rename(filename, filename + .deleted)
filename = filename + .deleted
Tim Golden wrote:
Giampaolo Rodola' wrote:
On 1 Apr, 18:27, Steven Bethard [EMAIL PROTECTED] wrote:
On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
[EMAIL PROTECTED] wrote:
2008/4/1, Tim Golden [EMAIL PROTECTED]:
If this is the thing to do, presumably test_support should
grow a
this is http://bugs.python.org/issue1068268
On Tue, Apr 1, 2008 at 5:05 PM, [EMAIL PROTECTED] wrote:
test_signal is failing on osx g4:
test test_signal failed -- Traceback (most recent call last):
File
/Users/buildslave/bb/trunk.psf-g4/build/Lib/test/test_signal.py, line 151,
in
Hi all,
anyone care to take a look at:
http://bugs.python.org/issue2014
It's about xmlrpclib not being able to send datetime objects with dates
before 1900.
I would like to see this go in and would also like to work on
http://bugs.python.org/issue1745722
(xmlrpc wsgi support).
But this only makes
anyone care to take a look at:
http://bugs.python.org/issue2014
It's about xmlrpclib not being able to send datetime objects with dates
before 1900.
I would like to see this go in and would also like to work on
http://bugs.python.org/issue1745722
(xmlrpc wsgi support).
But this only makes
Currently, the official (by way of being de-facto) directory structure for
a build tree is 'PCBuild/.' for x86 builds and 'PCBuild/amd64' for x64
platforms. I believe this might cause problems for people trying to port
their applications to 64bit platforms. My proposal is that we change this
This is not something that keeps me awake at night, but I am aware of
it. Your solution (a counter) seems fine except I think perhaps the
close() call should not raise IOError -- instead, it should set a flag
so that the thread that makes the counter go to zero can close the
thread (after all the
Martin quoting me:
Currently, the official (by way of being de-facto) directory
structure for a build tree is 'PCBuild/.' for x86 builds and
'PCBuild/amd64' for x64
platforms. I believe this might cause problems for people trying to
port their applications to 64bit platforms. My
The reverse may also be true: some tools may expect PCbuild to contain
always x86 binaries, even on AMD64 - as they don't support non-x86 at
all. Those tools might break if PCbuild suddenly starts containing
AMD64 binaries.
I agree. However, it is my assertion that there are very few build
I've tried to fix test_signal at least. For those particular calls,
EINTR means that the kill I launched finished before I was expecting,
so we can ignore it without retrying. Figuring out subprocess in
general is a worthy goal but shouldn't block making the test less
flaky. :) r62102.
On Tue,
24 matches
Mail list logo
