Tim:
> [Martin]
> > on XP SP2: test_mailbox fails to
> > me, with permission denied in some (random) test. I believe this
> > is due to Tortoise SVN: test_mailbox creates a few directories,
> > then Tortoise detects them (thanks to file change notifications)
> > and tries to walk them, to find out
Tim Peters wrote:
> [Andrew MacIntyre]
Hmm... I don't appear to have explained what I meant very well :-|
{...}
> This really needs an executable example. Here's my best guess about
> what you mean, but I don't see any of what you're describing on WinXP
> Pro SP2:
And a pretty good guess it w
[Martin]
> I see a similar phenomenon (sp?)
Yup! The plural is phenomena.
> on XP SP2: test_mailbox fails to
> me, with permission denied in some (random) test. I believe this
> is due to Tortoise SVN: test_mailbox creates a few directories,
> then Tortoise detects them (thanks to file change no
Tim Peters wrote:
>> I've never reported this as a Python bug
>
> If you do, I'll probably add a comment like the above ;-)
>
>> because I've considered the antivirus SW likely to be the culprit.
>
> Could be. FWIW, Norton AV was running during the above.
I see a similar phenomenon (sp?) on XP
[Andrew MacIntyre]
> I doubt it has anything to do with this issue, but I just thought I'd
> mention something strange I've encountered on Windows XP Pro (SP2) at
> work.
>
> If Python terminates due to an uncaught exception, with stdout & stderr
> redirected externally (ie within the batch file th
Jérôme Laheurte wrote:
> Ah, no, it's only available in XP. There are some alternatives though:
>
> http://www.robvanderwoude.com/index.html
Sure. Writing my own one wasn't that difficult, in the end, either
(except that I overlooked that the API I used first exists in XP
and later only).
regard
Le 20 avr. 06 à 22:25, Martin v. Löwis a écrit :
> Jérôme Laheurte wrote:
>> Sorry I'm late, but something like "os.popen('taskkill.exe /F /IM
>> python_d.exe')" would have worked; we use this at work.
>
> Thanks, I didn't know about it. Is it available on Windows 2000,
> too? (because the system
Le 17 avr. 06 à 20:59, Martin v. Löwis a écrit :
>> OTOH, we could just as well check in an executable that
>> does all that, e.g. like the one in
>
> I did something like this: I checked the source of a
> kill_python.exe application which looks at all running processes
> and tries to kill python
Jérôme Laheurte wrote:
> Sorry I'm late, but something like "os.popen('taskkill.exe /F /IM
> python_d.exe')" would have worked; we use this at work.
Thanks, I didn't know about it. Is it available on Windows 2000,
too? (because the system in question is Windows 2000, and I see
it on a "What's new
Martin v. Löwis wrote:
> It can't be that simple. Python's stdout should indeed be inherited
> from cmd.exe, but that, in turn, should have obtained it from
> buildbot. So even though cmd.exe closes its handle, Python's handle
> should still be fine. If buildbot then closes the other end of the
>
Tim Peters wrote:
> No, what's surprising is that it keeps running _forever_. This isn't
> Unix, and, e.g., a defunct child process doesn't sit around waiting
> for its parent to reap it. Why doesn't the leftover python_d.exe
> complete running the test suite, and then go away all by itself? It
[Tim]
>> ...
>> 2. The buildbot code tries to kill the process itself. It appears (to judge
>>from the buildbot messges) that this never works on Windows.
>>
>> 3. For reasons that are still unknown, python_d.exe keeps running,
>>and forever.
[Martin]
> It's actually not too surprising th
> OTOH, we could just as well check in an executable that
> does all that, e.g. like the one in
I did something like this: I checked the source of a
kill_python.exe application which looks at all running processes
and tries to kill python_d.exe. After several rounds of
experimentation, this now wa
Tim Peters wrote:
> 2. The buildbot code tries to kill the process itself. It appears (to judge
>from the buildbot messges) that this never works on Windows.
>
> 3. For reasons that are still unknown, python_d.exe keeps running,
>and forever.
It's actually not too surprising that python_
Neal Norwitz wrote:
> If the patch won't fix the problem, is there something else we can do
> to ensure the python DLL is no longer used regardless of whether the
> previous test passed or not?
Rebooting the machine will help, and might be the only cure.
It's Windows, after all :-(
Of course, we
[Neal Norwitz]
> The windows buildbot slaves (cygwin too) are still having problems
> with the DLL being in use when we start compiling so the compile
> fails. clean.bat is not called afterwards based on the buildbot log.
> I don't know if clean fixes the problem. If it does, would this patch
> f
16 matches
Mail list logo
