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 Fil
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:
>
> http://www.python.
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 "/Users/
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 te
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. Th
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.
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 bra
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 s
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
>>> > gr
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
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
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
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_su
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
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
Hello,
On Tue, Apr 1, 2008 at 9:02 PM, m h wrote:
> 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 appea
> 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
> 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 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 f
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 platform
>> 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
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, Apr
On Tue, Apr 1, 2008 at 5:09 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 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 th
On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
> 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 t
26 matches
Mail list logo
