[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: r76358 and r76360 and r76361 Thanks David ! -- status: open -> closed ___ Python tracker ___ ___ Pytho

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: > If it's something for general use, how about HKCU\ControlPanel\Desktop\DragFullWindows Yes I'll just use this one. > I can do some quick test installs to verify if I get a moment tonight though. Don't worry about it. XP and Windows 7 are enough to make the te

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Oh, my bad - I was working on the assumption that test_msvc9compiler was testing compiler related stuff, so obviously would have the compiler installed. But it makes sense you might test support for that compiler on a machine other than the one doing the building.

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: There's one more thing we didn't take care of in our change: windows platforms where people just install Python and run tests, so there's no VC++ installed. For them I guess we can use: r'Software\Microsoft\Windows\CurrentVersion' and look for the u'productid' val

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: Ooops my bet, that's a typo, it's backlashes you are right. I'll change the test now, thanks a lot for all the feedback ! -- priority: -> normal resolution: -> accepted ___ Python tracker

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Yes to both examples (the first on my VS 2008 full installs on XP and Windows 7, and the second on my XP with VC++ Express). Two caveats (that I don't think invalidates the result) though. First, I can't use forward slashes in the path I supply to Reg.get_value,

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: Ok so, can you confirm this is working on your side ? VisualStudio 9: >>> from distutils.msvc9compiler import Reg >>> path = r'Software/Microsoft/VisualStudio/9.0' >>> Reg.get_value(path, u"applicationid") 'VisualStudio' >>> import _winreg >>> HKCU = _winreg.HKEY

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Oh, BTW, you were missing the VC part of the path in your test. But if I run the same code with that corrected on my Win7 box, I get: >>> from distutils.msvc9compiler import Reg >>> path = r'Software\Microsoft\VisualStudio\9.0' >>> Reg.get_value(path, u"fullscree

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: The "Build Timing" key (not Build Time) is the only one at all under HKCU/VisualStudio/9.0/VC (and actually the only key under the entire HKCU/VisualStudio tree) on both my XP and Win7 new VS 2008 installation. I can't rule out it being part of SP1 which I include

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: I made a test on my Express edition on the "FullScreen" value, but I don't have a "Build Time" one. Do you have a "FullScreen" key ? can you run this in a shell, to see what value you get for FullScreen, and for build time ? (I find it strange that this one has

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Oh, Tarek, something I missed in your last comment - for the "Build Timing" key, it should probably permit the value to be either 0 or 1, just as the current test does. Just in case someone happens to have build timing turned on. -- _

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Our last comments may have crossed, but as I mentioned in my last one, yes, as best I can tell from my slaves (XP+VS-Express, XP+VS-Standard, Win7+VS-Standard), the Visual Studio key is present in a brand new install. Note that it is not present in a brand new XP

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Tarek Ziadé added the comment: > Does it have to be a DWORD, or a 0/1 value, or under HKCU for a > specific reason? This notepad test was just to make sure the registry reader works by returning a known value. I can change it using: Reg.get_value("Software\Microsoft\VisualStudio\9.0\VC", "Bui

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Since I was feeling bad for the Windows 7 build slave not being able to pass the tests due to this (at least when other tests weren't failing), I manually added a matching key on the slave pending any test changes. In looking around, since this test is specificall

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

David Bolen added the comment: Well, I can at least start by comparing XP and Win7 immediately post-installation. Any suggestions on guidelines to what can be chosen? Does it have to be a DWORD, or a 0/1 value, or under HKCU for a specific reason? -- _

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

Martin v. Löwis added the comment: As you now have access to freshly-installed systems: can you propose such a key? -- nosy: +loewis ___ Python tracker ___ __

[issue7293] test_msvc9compiler test_reg_class failure on new Windows box

New submission from David Bolen : This is a pretty tiny bug.. The test_reg_class test in test_msvc9compiler.py assumes that there is a Notepad registry key on Windows systems. That appears to be false until Notepad is run the very first time. I ran into this setting up a build slave VM, where