Fix for pygame/PyOpenGL/NeHe tutorial windows not disappearing when run from IDLE

It's a long weekend here in the UK and I thought I'd spend some time working through Paul Furber's Python translations of the well-known NeHe OpenGL tutorial, which use the pygame and PyOpenGL libraries. (This is all with Python 2.6 on Windows XP.)

I noticed that when I ran the sample files from IDLE, the windows did not close -- it didn't matter whether I used the close box or hit escape; the program would seem to exit, but IDLE was in a messy state, and the OpenGL window would sit there not repainting.

Googling didn't turn up anything that sounded relevant, but this archived mailing list message mentioned a pygame.quit() function that sounded relevant. I tried putting this at the end of each of the samples, and it seems to fix the problem.

[ Read more ]

Workaround for Vista stupidity

When I run certain command-line tools from a command prompt in Windows Vista, it displays the results in a separate window. This separate window disappears when the tool exits. This is the most mind-bogglingly stupid behaviour I have encountered so far in an operating system famed for its mind-boggling stupidity. However, there is a workaround -- you need to start a shell as the Administrator user (not just as an Administrator).

Here's some more detail:

• If you are not the Administrator user (even if you are a member of the Administrators group) then when you run a command-line tool that requires admin privileges, you need to click on one of Vista's never-ending stream of "this program wants access to your computer" messages. This is pretty sensible, annoying though it can be.
• It then opens a new command-line window in which you can interact with the program. I can see no value in this whatsoever; the window is not highlighted in any way, so it's not to make it clear to you that this is a potentially dangerous program. Potential reasons welcome in the comments.
• The real stupidity, however, shows itself when the program exits. Because then the window closes -- taking with it all of the information the tool displayed for you. foo /help suddenly becomes totally useless. Error messages? Forget about them.
• And to make it worse, if you try to redirect the standard output or error of the program to a file or to more or anything else, you get nothing -- it still goes into the disappearing window.

After spending quite literally hours trying to debug a problem with the Python easy_install script, which was quite sensibly logging the details of the problem into a window that Vista promptly closed, I discovered a workaround:

H:\>runas /user:Administrator cmd
Enter the password for Administrator:
Attempting to start cmd as user "DRX\Administrator" ...

H:\>

And up comes a new command prompt. Anything you run in there will put the standard output and error into the command line it was started from, just as any sane user would have expected in the first place.

MSBuild WTF: 'The error was:'

Here's a fun one for anyone who uses msbuild (at least, v2.0.50727). Create a project file like this:

<Project DefaultTargets="Foo" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Foo">
        <Exec Command = "echo Hello!" />
  </Target>
</Project>

From a command prompt, run the project; you will get a the effect you would expect.

Now replace the word "Hello" with "The error was: something random". Run it again.

C:\\Dev\\Resolver>msbuild foo.proj
Microsoft (R) Build Engine Version 2.0.50727.42
[Microsoft .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

Build started 15/11/2006 17:50:22.
__________________________________________________
Project "C:\\Dev\\Resolver\\foo.proj" (default targets):

Target Foo:
    echo The error was: something random
    EXEC : The error was: something random
    C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
Done building target "Foo" in project "foo.proj" -- FAILED.

Done building project "foo.proj" -- FAILED.

Build FAILED.
EXEC : The error was:
C:\\Dev\\Resolver\\foo.proj(3,9): error MSB3073: The command "echo The error was: something random" exited with code -1.
    0 Warning(s)
    2 Error(s)

Time Elapsed 00:00:00.09

C:\\Dev\\Resolver>

Fuzzyman and I bumped into this one at work today; our continuous integration server, which watches our Subversion repository and checks out, builds, and tests any code changes it sees, had reported a failure despite the fact that none of the tests had failed. It turned out that one test was quite innocently printing out the text "The error was: " followed by some logging information; it wasn't an error at all. As far as I can tell, the statement that the echo command exited with code -1 is absolute nonsense.

This behaviour is not documented anywhere that we were able to find; I can only assume it was added for some specific purpose in the context of Visual Studio...