macrobug

I am starting to see the light at the end of the tunnel.

So far, most of my work has been investigating how to solve technical problems. It’s frustrating, because you inevitably choose blind alleys and it takes weeks to get nowhere.

But last week I think I overcame the last big technical risk before having useful working tools - or at least prototypes thereof. There’s still a lot of work to go before I’m at that stage, but hopefully it’s just coding rather than sinking endless time into problem solving.

(That said, I have spent most of this week looking into some pesky technical problems. But they’re of the sort where you know there’s a solution, rather than the sort where there’s a big risk there might be no way to do something, and you might have to change your plans radically).

I’ve noticed too that I’m now working longer hours. When my wife is out doing her daft cycling stuff, I’m working. I’m even waking up before the alarm goes off, which is pretty unheard of for me, and getting working. This is not because I’m massively excited, it’s just because I can enjoy the coding phase whereas the risk-uncertainty-investigation phase was fairly unpleasant.

Anyway, that’s where I am. The next few weeks could be a rollercoaster: now I’ve got the underlying technology more-or-less in place, I have to see whether I can make tools out of it which I believe could be useful.

I want one!

I am going to be fascinated to see whether it’s open to new software, and above all, what networks it becomes available on. Are Apple really going to sacrifice any of their iPod profits to the phone companies?

Wahey! I’ve completed my first two tax returns. This post will consist purely of the boring details, for the benefit anyone else who has to do the same thing, so the rest of you, please switch off now.

To be fair the first one was cheating: PAYE. (i.e. employer’s and employee’s NI, plus employee’s income tax). This is the second time I’ve paid myself a salary, but the first time, no tax was due (because of course I’m paying myself less than my previous employment was). It was cheating because my accountants calculated it, together with HMRC, and I just got a letter telling me how much Macrobug needed to pay the HMRC. Then it was a simple matter of going to https://www.billpayment.co.uk/hmrc/ and paying them.

The second - VAT - was a proper tax return, where I actually had to add things up. It looks deceptively simple… there are just nine boxes.

1. VAT due on sales
2. VAT due on acquisitions from EC states
3. Box 1 + Box 2
4. VAT reclaimed on purchases
5. Box 3 - Box 4
6. Value of sales and other outputs excluding VAT
7. Value of purchases and other inputs excluding VAT
8. Value of all supplies excluding VAT to other EC states
9. Value of all acquisitions of goods from EC states

All three boxes relating to ‘EC’ were zero for me, so that was easy. Box 1 is simple… you worked that out when you invoiced your customers.

Box 4 is tricky. You need to go through each expenditure your company has made, and work out the VAT you paid on it. It will be shown on the invoice/receipt. Some things don’t charge VAT, e.g. train tickets. However you can only include things on which you can reclaim VAT - which is where it gets tricky. I’m not sure of all of the rules, but for example, you can’t reclaim VAT on entertaining.

So, if you buy some food or drink for business associates, when you record that in your spreadsheet, you must either put down 0 for VAT, or make a note that VAT mustn’t get charged on that entry. If the latter, your magic auto-VAT calculation formulae will have to take account of it.

The next box is easy - it’s the difference between box 3 and 4, and it’s the amount you pay to HMRC. You can do this electronically too, though there’s no nice Visa-compatible web page, you need to do a bank transfer.

All that was expected. It was boxes 6 and 7 that made me have to think. Here you have to add up the non-taxed bit of each thing. That’s quite easy for your sales, but for your purchases it is more tricky. Because you have to distinguish between things to include in your VAT calculations but which have zero-rate VAT, e.g. train fares, versus things that you’re not going to include in your VAT calculations at all, e.g. entertaining.

All of which required some extra columns and maths on my accounting spreadsheet. But hopefully it’s all done now and I won’t have to touch it again.

Anyway, here’s the form you get. You can choose to fill this in quarterly or annually. Quarterly seems best, or the annual reconciliation would be huge. You can also do it on-line, but not for the first one, as far as I can tell.

In computing, a stack is a list of things, where you can only take off the most recent thing that you have put on. Just like a real stack of items.

This week has been a bit like that with the different bugs and issues I’ve had to work through.

I started off trying to write some code to decode a function name from an address, using the APIs available within Carbide.c++. Then I discovered that Carbide.c++ doesn’t tell Eclipse to load modules in the normal way, so I had to work around that. My workaround revealed that Carbide.c++ appears to be doing something odd with parsers, too, so I had to download Nokia’s modifications to CDT to discover what. Upon downloading that, I discovered that they’ve provided their changes in a format which required me to install a tiny programme to use them. Installing the programme simultaneously upgraded lots of other programmes, which filled up my hard disk, so I had to move some big files to another hard disk. Then the programme that used those files would no longer work.

I can only solve each of these problems one at a time, in reverse order, before I go back to the previous problem. Eventually I’ll make my way back down the stack to the original problem I was trying to solve.

So, that’s what a stack is.

(Also I have found that Nokia’s uploaded patches appear to correspond to a prior version of Eclipse, so even now I’ve got patching working, they won’t apply cleanly. Grumble grumble.)

Previously I explained how to create a JNI plug-in for Eclipse, from Eclipse.

Here’s a basic recipe for how to debug such a plug-in.

1. Launch one of your Java-side plug-ins as an Eclipse application.
2. Go to Help -> About Carbide.c++ (or equivalent)
3. Select Configuration Details
4. Find eclipse.commands
5. Copy the command line shown. Mine was -name Eclipse -showsplash 600 -product com.nokia.carbide.cpp.product -data P:\runtime-EclipseApplication -configuration “file:P:/carbide-ws/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/” -dev “file:P:/carbide-ws/.metadata/.plugins/org.eclipse.pde.core/Eclipse Application/dev.properties” -pdelaunch -os win32 -ws win32 -arch x86
6. Put it into an editor and edit it. First make it into a single line, and insert quotes round multi-word arguments (as I have done above).
7. Prepend this: -Xms40m -Xmx512m -jar “c:\program files\nokia\carbide.c++ v1.1\startup.jar”. You may need to adjust slightly… use the startup.jar in the path of your Eclipse launcher binary. The bits before that are memory arguments to the VM. Get them out of the .ini file in the same directory. There may be other arguments there.
8. You should now have all the arguments required for a javaw process to launch Eclipse.
9. So, shut down the runtime Eclipse workspace.
10. Find your native JNI project. Go to Debug. Choose Local C/C++ Application. In the name of the program to run, put the appropriate Java VM (in my case, “c:\Program Files\Nokia\Carbide.c++ v1.1\jre\bin\javaw.exe”). Under Program Arguments, put the complex arguments string you came up with.
11. Now, you can click Debug and the runtime Eclipse workspace will launch, but running within GDB and the CDT debugger.

I have no idea whether you can actually set breakpoints. I don’t even know if you can debug crashes. Unfortunately I need to debug a debugging session, and gdb gets a bit stroppy about that. So the above recipe hasn’t actually proven useful to me yet, but I thought I’d post it in case anyone else did. (For all I know there’s a much simpler way anyway).

Note that it doesn’t allow stepping from Java to C code or anything fancy like that - this appears to be one of the Holy Grails of CDT/JDT interoperability…

Have a look at our new Technical Library for a series of articles related to Symbian OS, Eclipse and Carbide.C++.

As per my previous post, Carbide.C++ can be used for standard Win32 C++ development. This uses the facilities of the normal Eclipse C Development Toolkit (CDT) upon which Carbide.C++ is built. That, in turn, uses GCC for compilation, MinGW headers for Win32 API support, cygwin1.dll for UNIX API support, and GDB for debugging.

All of this works fine under Carbide.C++, except GDB support. That’s because Nokia has added support for their own (née Metrowerks) debugger.

These debuggers obviously have different capabilities, and they’re represented by different Java classes. The upper layers of CDT (which Nokia have branched) query these debugger classes to find out whether they support certain capabilities.

Unfortunately, the upper layers ask a series of questions which are not understood by the lower layers. Rather than replying ‘no’, the old GDB code simply fails.

To see this happening, turn on the GDB logging described here.

The solution is to add the required methods to the GDB debugger, returning false. Here’s how to do that, in very vague terms. You might need to know a bit about Eclipse to be able to follow this recipe.

1. Install the Eclipse plug-in development environment into Carbide.
2. Install the source code for the CDT plug-ins into Carbide, probably from the Carbide update site.
3. Open the plug-in development perspective.
4. Go to the Plug-ins view
5. Find org.eclipse.cdt.debug.mi.core, right-click, go to Import -> As source project
6. Switch to the Package Explorer view, and open org.eclipse.cdt.debug.mi.core.
7. You should find the Problems view lists about 10 compile errors relating to the unimplemented methods
8. If not, also import org.eclipse.debug.core in a similar way
9. For each compile error, double-click on it to open the relevant source.
10. Click on the class name (which will be underlined due to the error). Press Control-1 to bring a list of selections for how to fix them. Choose Add Unimplemented Methods
11. There should be no compile errors left (warnings are OK)
12. Open the plugin.xml
13. Increment the version number to 3.0.2.5. (Carbide-branched components gain an extra ‘.5′ on the end; we might as well do the same).
14. Right-click on the plug-in and choose Export. Pick Deployable Plug-ins and Fragments
15. Save the zip file to somewhere
16. Unzip the contents of the zip file to c:\program files\nokia\carbide.c++ or wherever appropriate. This will give Carbide an org.eclipse.cdt.debug.mi.core 3.0.2.5 plug-in alongside the existing 3.0.2; it will choose the later version
17. Restart Carbide.C++
18. Debugging Win32 programmes (or UNIX programmes using cygwin) should now work

If you want to use Carbide.C++ for standard Windows development, here’s what you’ll need to do.

Window->Preferences->General->Capabilities->Advanced->Nokia Debug->Unused CDT UI

You should then find that all the standard CDT (C Development Toolkit) features become available.

Nokia has branched CDT in a few places, so not everything will work perfectly. However the only problem I’ve found is that I couldn’t immediately get GDB debugging to work with Nokia’s version of CDT. This is caused by Nokia’s branching but I’ve found a solution which I will write up at some point.

Meanwhile I’m quite impressed that Carbide isn’t a hacked-apart version of CDT; they’ve tried to extend it as politely as possible, so that none of the old functionality functionality is removed or disabled.

When I left Symbian, the Japan office very kindly indeed sent me this Jinbei.

Obviously it’s not even remotely the summer right now. But it’s surprisingly comfortable!

Thanks very much Symbian KK :-)