> Thanks for the prod, Trent. In short, yes, I spent some time
> on this over the weekend but haven't had time since. I found
> myself becoming more and more worried at the amount I had to
> change, especially given rumblings on the list concerning not
> changing the tests if possible.
> I was he
Trent Nelson wrote:
>
>> -Original Message-
>> From: Tim Golden [mailto:[EMAIL PROTECTED]
>> Sent: 04 April 2008 09:30
>> To: Trent Nelson
>> Cc: Python-Dev
>> Subject: Re: [Python-Dev] fixing tests on windows
>
>> Yes. I'm trying desp
> -Original Message-
> From: Tim Golden [mailto:[EMAIL PROTECTED]
> Sent: 04 April 2008 09:30
> To: Trent Nelson
> Cc: Python-Dev
> Subject: Re: [Python-Dev] fixing tests on windows
> Yes. I'm trying desperately hard to stick to a narrow remit
> of getting
"Tim Golden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| Terry Reedy wrote:
| > I suspect, but do not know, that the dialog box effects changes through
| > user-programmable interfaces. So while I would start with manual
changes
| > to see if that solves the problem, I presume
Trent.
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tim Golden [EMAIL
PROTECTED]
Sent: 04 April 2008 04:04
Cc: python-dev@python.org
Subject: Re: [Python-Dev] fixing tests on windows
Terry Reedy wrote:
> If the testdir disallows the search indexer, then there shou
Trent Nelson wrote:
> 1. For a given python[_d].exe, always use the same test directory,
> but hash it against the entire python process path such that it's
> unique only for a given python instance.
This is to guard against several build runs in parallel, presumably?
> 2. Make sure every tim
Terry Reedy wrote:
> If the testdir disallows the search indexer, then there should be no need
> to disable Windows Search Service. If privatizing the dir kept other
> programs out, then likewise.
>
> | Or were you suggesting that there is some programmatic way for the
> | test suite to create
At 3:52 PM -0600 4/3/08, Steven Bethard wrote:
>On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
...
>Or were you suggesting that there is some programmatic way for the
>test suite to create directories that disallow the Search Service,
>etc.?
I'd think that files and direct
"Steven Bethard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
| > "Tim Golden" <[EMAIL PROTECTED]> wrote in message
| > news:[EMAIL PROTECTED]
| >
| > | [re tests which fail because something's holding a fil
Terry Reedy wrote:
> "Tim Golden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | [re tests which fail because something's holding a file
> | open with SHARE_DELETE]
>
> There are a couple of things one can do in a directory's Properties box
> (right click) to reduce interferen
On Thu, Apr 3, 2008 at 3:09 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
> "Tim Golden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
> | [re tests which fail because something's holding a file
> | open with SHARE_DELETE]
>
> There are a couple of things one can do in a director
"Tim Golden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| [re tests which fail because something's holding a file
| open with SHARE_DELETE]
There are a couple of things one can do in a directory's Properties box
(right click) to reduce interference.
1. Under General/Advanced, u
om: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Tim Golden [EMAIL
PROTECTED]
Sent: 03 April 2008 09:39
To: Python-Dev
Subject: Re: [Python-Dev] fixing tests on windows
[re tests which fail because something's holding a file
open with SHARE_DELETE]
Well I've tried my best, but I can&
[re tests which fail because something's holding a file
open with SHARE_DELETE]
Well I've tried my best, but I can't come up with a solution
which guarantees to overcome this obstacle. I set up a fairly
aggressive directory watcher which, when it sees a test file
being created, takes a SHARE_DELET
Martin v. Löwis wrote:
>> Is using a fixed TESTFN just an old approach that predates the existence
>> of a robust tempfile module in the standard library?
>
> No. I believe the rationale for TESTFN is to provide a fixed name,
> precisely so that the test suite doesn't leave tons of garbage around
> Personally, I've never really understood the purpose of
> test_support.TESTFN. Whenever I've needed a temporary file for a test, I
> just use the tempfile module (e.g. test_cmd_line_script, test_runpy).
> Tests using that module don't care if the old files take 'a while' to
> get deleted on W
Tim Golden wrote:
> Gregory P. Smith wrote:
>> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>>
>>> Tim Golden wrote:
>
>>>
>>> import os, sys
>>> import win32file
>>>
>>> FILENAME = "test"
>>>
>>> def rename_and_remove (filename):
>>> os.rename (filename, filename + ".d
Nick Coghlan wrote:
> Tim Golden wrote:
>> I admit: this did occur to me on the train this am. While I
>> try to think of a robust way to handle this, other people have
>> proposed variations on pid-based / tempdir based filenames instead
>> of the same name for each test. In principle this sounds
Tim Golden wrote:
> I admit: this did occur to me on the train this am. While I
> try to think of a robust way to handle this, other people have
> proposed variations on pid-based / tempdir based filenames instead
> of the same name for each test. In principle this sounds good to me,
> but I'm not
Gregory P. Smith wrote:
> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>
>> Tim Golden wrote:
>>
>> import os, sys
>> import win32file
>>
>> FILENAME = "test"
>>
>> def rename_and_remove (filename):
>> os.rename (filename, filename + ".deleted")
>> os.remove (filenam
> def rename_and_remove (filename):
> os.rename (filename, filename + ".deleted")
> os.remove (filename + ".deleted")
> Isn't this still going to run into problems when the rename
> fails because the earlier tests remove still left the .deleted
> file around due to some other running desktop se
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
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
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
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
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
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, 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
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.
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
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
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
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.
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 fir
34 matches
Mail list logo
