DailyWTF is usually pretty reliably entertaining, but this CodeSOD article particularly tickled me with:
I’m sure a lot of you would have mocked Josh’s collegue for having a constant named COMMA. Ha! Who’s laughing now?
#define COMMA "|"
Less than impressed with this. Logged in earlier to blog about my iPhone, and was asked to upgrade WordPress to the latest stable release. Fair enough, I reckoned, as WordPress is an app with some history of being exploited; so I duly download the zip, do the upgrade, etc etc. All seems fine and I make my blog post… but I notice a typo, so I try to click through to the article to access the Edit link. I get a HTTP404/Not Found error. Odd, I think, and do some testing; it quickly becomes apparent that all my individual post pages are down.
Googling quickly turns up that this seems to be a known problem that WordPress 2.6 shipped with. It’s related to whenever “index.php” appears in the permalink tag, which admittedly is a bit ugly and unnecessary. There is a workaround but I must admit I just rolled back to my previous version right away. Good job I kept my old source tree and a snapshot of my database from just before the upgrade, eh?
I’m writing unit tests for a large solution which consists of a bunch of projects. Some small, calculation, utility type projects are in managed C++ and the rest are C#. When I run my tests under the GUI I get this error on one of the C++ DLLs:
Instrumentation error while processing file Util.dll: Error VSP1014 : Unable to open file 'F:\src\Util\bin\Debug\Util.dll' for writing..
Now, under Team Suite 2005, this seems to be a well-known problem but that Knowledgebase article does not describe what is wrong here. For one thing, the error message is different even though the error number is the same. For two, this is my DLL so I have the PDB file for it. And for three, if I hop to the command line immediately after this error and invoke mstest.exe manually, the test runs fine. I don’t get the same error and code coverage is generated.
For now I think all code coverage will have to be done on the command line, as I’m completely stymied now. I can’t see any way around this.
I always forget how to fix this, so here it is for my future reference: if it annoys you when you freshly install gvim on Windows and it does Windows stuff like ctrl-v as paste or not allowing you to visually select by pressing “v” and tapping the arrow keys, you need to find your system wide .vimrc file (<VIM_INSTALL_DIR\_vimrc by default) and remove lines like “”source $VIMRUNTIME/mswin.vim” and
“behave mswin”.
The gvim config file comment character is a double quote, remember!
For some reason I am missing the “Edit with Vim” menu, perhaps these are some fixes.
Is it just me or is this still rather half-baked, even now in 2008? Everywhere I turn I run across tiny little rough edges. Like this one: I am using Team Suite 2008 to generate code coverage data during a unit test run. I hit Run Tests and get 48 test run warnings, one per test/per referenced DLL, that say
“Code coverage instrumentation warning while processing file FooBar.dll: Warning VSP2013 : Instrumenting this image requires it to run as a 32-bit process. The CLR header flags have been updated to reflect this.”
So, yes. It simply cannot do code coverage on a 64-bit process. I’m running Vista x64, so naturally Visual Studio is starting up a 64 bit process, which the code coverage tool immediately fiddles with the CLR to drop it back to x86. This generates tons of sprurious warnings which (to top it all off) can be disabled on the comman line but not apparantly in the GUI. God knows what would happen if I were unit testing some subtle bug that only happened on the x64 platform.
On top of this, you still can’t Edit And Continue a running piece of code in the debugger properly if you are running x64. On my old Windows XP x64 workstation, it flat out didn’t work; now on Vista x64, it requires some messing around to breakpoint all running threads before it lets you get into the code.
I guess there must be some deep seated bits of the Windows API with some strongly held assumptions of 32 bittiness behind the scenes, and that what I am seeing are the rough edges of that hackery.
Settings I should make on a new Visual Studio install so it doesn’t annoy me to death:
Gah!
Say I am writing a unit test for a class that converts metres to feet. This, naturally, involves floats. Ideally my code looks like
float expected=32.91; // in feet
Distance dist = new Distance (10,”m”);
Assert.AlmostEquals(dist.convertToUnit(”ft”),expected);
where the “AlmostEquals” method does something smart like compares the first decimal place or so. I think JUnit/NUnit/etc actually allow you to spec a precision.
Microsoft haven’t managed this, so I have to write stuff like
float expected=32.91; // in feet
Distance dist = new Distance (10,”m”);
float difference = Math.abs(expected - dist.convertToUnit(ft)); // java ism, not sure of the .net Abs method offhand
Assert.IsTrue(difference<0.01);
Unit tests need to be as crystal clear in their intent and as quick to write as possible. Every little tiny rough edge will catch your project thousands of times over. So a big “bah” to Microsoft for this one.
Ctrl-R and then:
Add Ctrl as a modifier to the key above and you will debug tests instead of running then.
See also: http://blogs.msdn.com/robcaron/archive/2007/01/29/1552795.aspx.
Recent Comments