I seem to have plateau’ed at 140-odd bugs. That’s great news! I have been trying hard to think what might be wrong, and I was really expecting to come up with hundreds upon hundreds of bugs.
Even better, I’ve fixed three already!
Mylar is indeed pretty good - it integrates very nicely with Bugzilla, although I don’t like all of its features as much as I should.
I’ll post more about it in a couple of weeks…
This will be the first article I’ve written in a while which is related to new-techie-business setup. The reason is simply that I did all my setup before Christmas, and have just been beavering away working since then.
However, as I mentioned a few days ago, I’ve now got to the end of my “experimental” phase, and my code is settling down into a proper portfolio of products. There are lots of bugs which need tracking, before things reach saleable quality.
For those non-techies reading, bug tracking may seem an obscure thing, but it’s very important. Programming is hard - sufficiently hard that it’s impossible not to make mistakes. Hence, for any given project, perhaps half the total programming time is just spent fixing bugs you made in the other half. It rather depends on your development methodology, but either way, you need a system to track your bugs.
My requirements for my bug tracking system were:
The first bug-tracking system I looked at, Bugzilla, fitted the bill, so I just went with that. I am not aware of any other open source bug tracking systems but I expect they exist - and I suspect some of the commercial ones are free for small-scale use (which would be a good policy for the creators, because once you’ve picked a system it’s hard to change).
I was pleasantly surprised to find out that my shared-hosting server at my ISP contained all the required dependencies to get Bugzilla running straight away. So I now have it running on an “intranet” part of the Macrobug website.
I also want to give Mylar a go, to integrate Bugzilla into Eclipse. I’ve only heard good things about it.
Meanwhile, I’m still coming up with that list of bugs to put into Bugzilla. Right now I’ve only thought of 96 things - which I’m sure will easily double, but it’s still less than the 500 or so I was estimating. Which is nice. Many of them will take several days to fix, though, so it’s still a while before I have a polished product.
Today, I raised my first bug on myself.
I predict I’ll be following up with several hundred more in the next few weeks.
This is quite an important milestone for me: it means my gubbins are reaching the end of the ‘hack-and-experiment’ stage, and hopefully settling down towards becoming a product. So, once I’ve raised those 500 bugs, I’ll be having to fix them all. (And a lot of them are going to say “this bit is missing test code” so I’ll be writing a lot of test code too).
In other news, Symbian OS tools-related contracts are like buses… you wait ages for any, then five come along at once.
However, also like buses, I fear that none of them will actually stop at my particular bus stop. We’ll see. Ting ting!
Useful tip for other techies out there: I just discovered that printf(”%ls”, (wchar_t pointer goes here)) prints out wide strings. Nice! At least, it does for MinGW.
I couldn’t possibly comment on whether I worked on it when I was at Symbian, when it’s due to ship etc.
Still - I quite fancy one.
Phew! It works.
The problem was a ‘missing link’ between two types of information which made the whole flow-of-control trace a bit useless. I have found a way to link the two types of information, and the trace now happily spans all the threads and tasks.
Screenshots hopefully soon - a few things to sort out before I can post them.
It won’t be long before I start to demonstrate my wares to people! (The real proof of the pudding.) Anyway, fortunately, my slow development progress before Christmas has been reversed since, and I’ve now reached the point that I had planned to reach at Easter. Woohoo!
At the beginning, I said I was scared about three things: the technical side, the co-operation-with-Symbian side, and the marketing side. The first is now officially ticked off the list. The second is going OK. The third is a big unknown :-)
Pepsmedia have asked me for a quote for their website on the basis that I’m a prior customer. I’m an extremely satisfied one, so I thought I’d post it here too:
I mean it!
My ultimate aim by capturing all this information is to produce a swish view of everything that’s happened to lead you up to your current breakpoint, across all threads and processes on the device. That’s really what I mean by “flow of control monitoring”. Everything I’ve done so far - the high-speed trace capturing system, the hooking into Eclipse APIs, the symbol resolution pain and even the Memory Tracer widget I came up with to test those subsystems - has been a prelude to getting this overall flow-of-control tracing working.
Unfortunately, the task is so complex that I’ve never really been able to convince myself whether or not the end product will actually work - or if there’s some logical or technical flaw which mean the results of my techniques will be useless.
Well, today, I finally got close enough to find out. I’ve pieced everything together enough to get the view to appear.
And indeed there was a logical flaw that means the whole thing is useless :-)
But I’m pretty sure it is solvable. More in the next couple of days…