macrobug

As many readers (oxymoron?) know, my ideal is to get some tools-related contracts, and pull together a reputation as a solid tools developer for Symbian OS, as well as trying to sell my pre-existing tools.

Right now I am doing a short-term contract for a major Symbian licensee. It’s not tools-related, but it is related to debugging difficult problems so I’m coming up with a useful list of things which could be solved by tools. (Actually, I’m not – all the problems I’m trying to solve are too difficult to automate, but hopefully I’ll have some ideas!)

But better still, the prospects for further contracts, all tools-related, are gradually firming up for after this one. If all my current prospects worked out, I’d be a very happy bunny. Having said that, this contracting lark is quite a roller-coaster… one minute you have rosy looking prospects and the next minute you have nothing at all. So I shan’t be counting my chickens yet. They don’t like roller-coasters anyway.

Meanwhile back to phone bug fixing. Byeee….

Ouch! Bitten by a VAT quirk! Contractors – read this.

If you’re doing a contract, typically you’ll provide an invoice to a customer which lists your fees, plus any expenses incurred in performing that contract (assuming you’ve persuaded them to pay your expenses). For my last contract, nearly all of those expenses were train fares to and from the place of work. So, my invoice might have looked like this:

Note that there’s no VAT on the train fares. That’s because train fares are public transport, which attracts a 0% rate of VAT.

And therein lies the problem. Even though train fares don’t attract VAT, when I put them on an invoice for my services, apparently they are not train fares any longer. They’re part of the service I’m providing, and therefore should have attracted standard 17.5% VAT.

Sadly I didn’t know this, and didn’t find out until I went to an HMRC seminar last week. (Yes, yes, I accept it’s my responsibility to know all these things – but as I’ve said in a previous post, you can’t keep on top of everything and still have time to actually do any work.) So I am £66 down, assuming I correct this mistake on my next VAT return, and assuming I don’t try to squeeze this money out of my customer due to wanting to save face.

Oh well. Ho-hum.

I think I will be signing up to the flat-rate VAT scheme soon, to save myself some paperwork.

One of my most troublesome bits of code has been to resolve numeric memory locations into useful descriptions of the code that lived there. Many of my tools squirt thousands of these memory locations from the device to the debugger, and I later present them to the programmer. They’re useless if I can’t convert from the memory location to something the programmer can understand: the function name and source code location.

(Even a non-programmer can see that the “after” results are likely to be more useful for any techie.)

In the autumn I tried, in vain, for weeks to find a “nice” way to perform this conversion. I tried dozens of potential methods in increasing desperation. Each branch on this tree is something I tried, or a reason why it didn’t work:

The last method I tried – and the one which worked – was a Microsoft library. It’s called dbghelp.dll, and performed this conversion. But it had some problems:

• It’s slow
• It has to load big databases of symbol information, using lots of memory
• It’s hard to use from Java tools like those I’m developing
• It could conflict with Carbide’s own debugger
• It would only work on the Symbian OS emulator, running under Windows

Because of that, the code was complex and I didn’t properly trust it.

Nokia came to my rescue.

At the pluginfest back in January, Ken Ryall from Nokia offered to make an API available within Carbide to perform this conversion on my behalf. (API = application programming interface, essentially a means to provide access to somebody else’s code). The theory being that Nokia’s debugger code already has routines to perform this conversion – it’s just that independent plug-in developers like myself didn’t have access to it.

Well, in the past couple of Carbide beta releases, he’s done it. And it works. I expect I owe him (or somebody) a few beers, but other than that, Nokia have just done it out of the goodness of their hearts, and because they want to encourage third-party plug-in developers like Macrobug.

Thanks Nokia, and Ken specifically!

Now, for the techies, here’s how to use it:

ICDITarget cdit = ((CDebugTarget)dt).getCDITarget();
if (cdit instanceof ICDIAddressToSource) {
	IMappedSourceLocation loc;
	try {
		loc = ((ICDIAddressToSource)cdit).getSourceForAddress(address);
	} catch (CDIException e) {
		throw new SymbolResolutionException(e);
	}
}

The resulting ‘loc’ contains everything you need.

Ken is contributing this as a standard part of Eclipse CDT, so it should even be available outside Carbide.c++. Woohoo!