As I mentioned a while back, I got a Garmin eTrex Vista C handheld GPS as a Christmas present and there’s code available from the Garmin website that lets you talk to it via its USB interface. There’s also a specification document for the protocols that it uses. At first glance this is great. I’ve seen better specifications but with a little trial and error I’ve managed to transfer the saved GPS tracks from the device to my code and I can set the device up to send it GPS position every couple of seconds (so I could use it as an external GPS receiver for mapping software) etc.
Does anyone in IT use paper clips for anything other than resetting hardware either by pressing those hard to reach reset buttons or by shorting out bios batteries, etc?
I got a Garmin eTrex Vista C handheld GPS as a Christmas present. Another cool tool to add to my geeky ski stuff. So far I’ve only used it to navigate to and from a restaurant yesterday lunch time, but it seems to have lots of features that will make it useful on the mountain. The best thing about it? There’s an SDK that you can download to communicate with the device.
There’s an interesting article by Tomer Abramson in this month’s Dr Dobb’s Journal about deadlock detection. He provides a compile in tool that works in a similar way to my deadlock detection tool and reports on potential deadlocks in code even if they never occur during the program run in question.
His architecture is considerably different to mine but the idea is the same. By recording the sequence of lock acquisition and release on all threads in the program you can then examine the sequence that locks are taken out and spot potential deadlocks.
I’ve just finished the first cut of the code that handles the Win32 Thread Naming “API”. This means that my debugging tools can now report the name of a thread (if it has been named) rather than just its thread ID. Having implemented the code in the debugger to deal with the exception I find myself wondering about API design and why the original designer of this particular facility decided to make it hard on themselves.
Dennis Forbes talks about “Edit and Continue” in VS 2005 and asks “Is it, coupled with similar tool advances, making programmers sloppier, though?”
I think so…
In the Visual C++ debugger we’ve had “Edit and Continue” for years but I turned it off a long time ago as I didn’t find it that helpful. It enables and encourages quick hacky experimental fixes to running code. I never really liked that idea, I usually prefer to think about the problem rather than just hacking in a fix, and back in the early days of VC6 the whole incremental link/edit and continue thing sometimes introduced interesting bugs that seemed to go away if you did a full clean build.
Ben takes the “throw as an exception dispatcher” idiom to its logical conclusion by presenting a pluggable exception handler.
As Ben says “I’m not sure how many situations something like this would be useful in, but it fit the testing problem well and was fun to write anyway”. It’s not the kind of code you need every day, but it’s useful stuff if you’re working on a test framework, or if you’re interested in how you can use the “throw as an exception dispatcher” idiom.
I’m in the process of testing some of my code with Visual Stuio 2005 and the first thing I found that I needed to do was to upgrade my STLPort installation from 4.6.2 to 5.0.0 to get a version that built with VC8. Given that I like to test one change at a time I first upgraded my VC6 build to use STLPort 5; STLPort built fine with VC6 and all my tests passed.
In case you missed it the first time around…
We’re doing the old “assert is evil”/“Oh no it isn’t” thing over at Ned Batchelder’s place.
I’ve been using the SetThreadName() function from the MSDN docs for ages to provide a way of distinguishing between threads in the VC debugger. I always thought it was a bit of a weird ‘API’ but had never really thought to wonder why. Steve over at “Bug Babble” explains how the ‘API’ works from the debugger’s point of view and, well, then it all becomes obvious. For some reason I’d always thought that the ‘API’ was communicating with the OS in some weird and wacky manner; I hadn’t twigged that in fact it was just communicating with the debugger using the only method it could, via raising an exception which gets routed through the Win32 debug API.
