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
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
fix the problem:
Index:
17 matches
Mail list logo
