Hard to believe, but my last
Summer Winter of Code update was twelve days ago. Since then, I’ve experienced setbacks, progress, frustration, and a disproportionate number of sentences which used the structure
…the fuck? (For anyone who just wants a screenshot, that’s near the end of the post.)
Apart from the frustrations caused by Telstra, the main source of frustration for the last few days has been this line of code:
toolbar->AddControl(new wxStaticText(toolbar, wxID_ANY, _(“Show:”)));
See the problem? No, me neither. According to the documentation for wxToolBar::AddControl, that’s a perfectly cromulent line of code. Nevertheless, it caused truly epic levels of failure, both on Windows and Linux. I suspect there’s a wxWidgets bug there, but haven’t had time to condense it into a test case that doesn’t involve four levels of panels and wxAUI. Unfortunately, due to a combination of tiredness and stupidity on my part (mostly the latter), I ended up on a tangent for a few days thinking that the actual issue was to do with event handling in the communications library, which… well, it wasn’t.
Yes, that means the guy writing a debugger (of sorts) misread the output from gdb for about four days straight. Send pity baskets.
Once I figured that little gem out this morning, things flowed much better. So much better, in fact, that much of the UI is now in place. (My earlier plans to use wxFormBuilder were foiled by its lack of obvious support for nice, resizable pane things, which my design document — which I’m going to scan next week, since I think I should run a competition for whoever can decipher my handwriting — used heavily, so I ended up going back to the time-honoured approach of writing it all in C++. Fortunately, wxAUI rocks.) Therefore I now have a screenshot!
There’s still some work to be done. The breakpoint code works fine in the comms layer, for example, but isn’t fully hooked up yet in the editor. There’s no syntax highlighting (I have a rant percolating about wxStyledTextCtrl, but that’s for another post). There’s still a couple of panes to be implemented, namely breakpoints, so you can set breakpoints that aren’t just file/line based, and a watched variables pane. Plus there’s still a tonne of polish work to be done, ranging from actually having a preferences dialog box to not requiring horizontal scrolling in the call stack and properties panes.
Importantly, though, it’s starting to feel like an actual, working debugger, and I’ve had a couple of those moments tonight where things actually worked first time (mainly due to the unit tests for the comms library) without any poking and prodding. I damned near wet myself when I first tried a PHP script with a function call, hit the step into button, and it actually stepped into it, updated the call stack, displayed the correct source file and generally behaved properly. Maybe I’ll get the back of this broken before classes start again on Monday after all.