Five Minutes

My first classes for second semester are tomorrow morning, so it’s fortunate that I’m now not too far off having my Summer Winter of Code project at a releasable state. Since I need a decent night’s sleep before being up bright and early for Video Production (should be fun) and Internet and Java Programming (…less so), here’s the state of play in bullet form:

Things done since the last update

• Switched to wxStyledTextCtrl for the source code display, which means that syntax highlighting now works, at least for PHP. (Side rant: Why is the documentation for wxStyledTextCtrl so lacking? The only decent source of documentation for it is the documentation for the Python binding, which is hardly ideal, and still requires a fair bit of piecing things together.)
• Breakpoints and the current line are now shown by (differently shaped) markers in the gutter, rather than changing the background colour of the line(s), which should be far friendlier for everyone, especially people who are colour-blind.
• Added a popup menu within the source viewer to provide another way to run to the cursor and toggle breakpoints.
• Tooltips now work (mostly) when hovering over variable names in the source viewer.
• Added the breakpoint pane to the main interface. At present, it supports function call and return and exception breakpoints, plus the usual file/line based ones set within the source viewer. Watch breakpoints are to get a different interface.

Things left to do before releasing 0.1.0

• Come up with a better name than wxDBGp. Suggestions welcome. An icon might be a good idea, too.
• Figure out some wacky method for making tooltips work in the call stack and properties panes, since mouse motion events don’t seem to be emitted after the pointer initially enters wxListBox and wxTreeCtrl controls.
• Add a watchlist pane (it’s going between Output and Breakpoints).

And now, the moment you all look forward to: more screenshots! (Well, I look forward to it.)

Syntax highlighting now works. Mostly. For PHP, anyway, since I haven’t wired up the other wxSTC lexers yet with style rules.

No Windows screenshot this time. This is far, far better, as proprietary operating systems go. There’s a few graphical glitches, particularly in the toolbars (the alpha blending doesn’t appear to be actual alpha blending, for one), but it works entirely better than I expected, given that I’ve put very little work into a Mac version thus far.

From here, I guess the remaining work will be done in minutes stolen here and there from uni assignments, but I’m confident it’ll be released — nay, unleashed — upon an unsuspecting world before the final date of August 20.

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.

Shockingly, Telstra have managed to fix my phone line in one day. This is a new record for me when dealing with their residential arm. Hell, I once worked for a company who had a contract with Telstra that boiled down to we will fix any possible problem with your bundle of regular lines and fixed landlines within four hours, guaranteed (don’t ask how much it cost — suffice to say that I could have had a small army of minions with the money that was spent each month) and they still once suffered a fault of three days duration. At least the compensation could also have paid for the minions. (It didn’t, sadly. Volunteer minions are surprisingly hard to find.)

That said, their definition of fix isn’t all that reassuring, since it basically involved replacing one temporary line (complete with bite marks — the finger of suspicion is pointed squarely at the two rabbits that have taken up residence on our block) with… another temporary line. Great.

Ended up going to the Pinnacles this afternoon to spend a sunset there, which has been on my list of things to do for a while. It might have been more impressive without the cloud cover that swept in late in the afternoon, but it was still seriously cool in a way that I’m sure my mobile phone camera has completely failed to reproduce. Still, I got a bit of writing done for next semester’s film units, so at least today wasn’t a complete wash.

Courtesy of Telstra, who have finally succeeded in their ongoing quest to kill our phone line, it looks like I’m going to have a couple of days without Internet access. This is, of course, as inconveniently timed as possible, given the work I need to do on the GSWoC project and said work being about ten times harder without the aforementioned Internet access.

So, I’ll be back in a couple of days, give or take. Guess I’ll take it as an enforced break.

Short Summer Winter of Code update this time, since I’m tired and don’t have much to report that’s going to be all that interesting. Reasonable progress has been made since the last update, and I’m basically done with the communication library for now, which has reasonable code-level documentation, reasonable unit test coverage, and has a @todo:file ratio of less than 1.0. Derick raised a good point about the wxWidgets dependency (the library depends on 2.8 for the XML parsing, but many distros are still shipping 2.6 and are unlikely to change until new versions come out, so Debian users are in trouble for a while), but I don’t think it’s something I can deal with at the moment given the time constraints, so the first version’s going to require 2.8, and I’ll revisit it after that to look at using libxml2.

The next step is therefore to work on the GUI. Tomorrow, assuming my car is dealt with one way or the other reasonably early in the day, I’m going to sit down and start working on the layout and workflows — initially in my usual first draft manner involving a pen and a notebook, then progressing to some mock-ups in wxFormBuilder. There are obviously quite a few reasonably good graphical debuggers out there now, and I don’t intend to deviate too far from the mould, but I think it’d be remiss if I didn’t at least work through it myself to see if I have any bright ideas. (In other words, no, it won’t be any different from the norm.)

It’s also mid-term evaluation week, as I’m sure every student is keenly aware. This year the evaluation has taken the form of a survey, which wasn’t quite what I was expecting, both in form and content. It’s not a particularly difficult survey to fill out, but some of the questions were related to the community, which is something that I’m not really connected to — this project is quite distinct from the PHP project proper, and I don’t think there’s a strong community it does belong to. I think about a quarter of my answers ended up using some sort of construction along the lines of I don’t really feel that I have much to say about this, but…, which I suspect will probably get me a smack (even if only karmically) from somebody at Google.

So, that’s that. Next time: pretty screenshots! Singing and dancing! Cowbell!

Odds: My university marks should be out in the next 24-48 hours. I’ve got the whole bag this time: one unit for which I already know, give or take a couple of percent, what I finished with, one unit for which I have a rough idea, and one unit for which I have no clue whatsoever as the exam was worth 70% of the mark. I’m not particularly worried about any of them, but I’m still nervous. I’m always nervous at this point in the grading cycle.

Sods: My car decided not to start tonight when I wanted to go and pick up a pizza. It’s definitely an electrical problem and the battery’s definitely fine, so I can already feel part of my tax refund slipping away getting it fixed. (Well, that or the Google Summer Winter of Code mid-term payment.) Will probably spend part of tomorrow morning looking at it myself before coming to the inevitable conclusion that I’m going to need to get some sort of professional to do so if I actually want it fixed.

Procrastinatods (which I’m claiming as a word, dammit, if ginormous made it, so can this): I resolved to write my short film script for next semester during the break, along with a rough outline for the documentary proposal I have to do. Thus far, I have done neither, and classes start again in two and a half weeks. I also have plenty of work left to do on the GSoC project (more on that later). This isn’t looking good. Guess I’ll have to revise my estimates of sleep for the rest of the year down from two hours per night to 90 minutes.

Yes, it’s Google Summer Winter of Code update time, because it’s probably not a great idea for me to continue coding at 2:30 am. After a frustrating couple of days grappling with the inadequately documented mess of #defines, deprecated macros, encouraged macros and various other things that constitute the custom event support in wxWidgets, the DBGp library is now basically up to an alpha state, modulo a bit of documentation and the unit tests promised in the last update.

The breakthrough came late this afternoon when I decided to trash what I had, ignore the custom event documentation completely, and instead work off what an application found after some Googling actually did. Lo and behold, things worked. With that in place, it was easy to code the events needed in the library and start playing with them.

Although I’m still a little way off doing any work on the GUI, I decided to look at a couple of issues that impact on it tonight. I attempted to get the project building on Windows last week, but had little success. I don’t know what the difference was tonight, but things went very smoothly, and the library builds cleanly on Windows with no code changes. (For the record, I’m using SCons as a build system at present. I’ll probably — well, I might — end up switching to autoconf when it’s near time for the first release, but I much prefer SCons when I’m hacking away.)

After that, I decided to have a play with some form builders. Through a scientific process (look at the list on the wxWidgets Wiki, exclude the ones that weren’t open source, pick one at random), I came to wxFormBuilder, which seems pretty nifty. To give it a workout, I quickly hacked together a test application that was more featureful than my previous one (which had one giant button to send a status call to the debugging engine and spat out reams of output to stdout).

Therefore, for the first time, I give you screenshots! The final application will look nothing like this, but it’s nice to have something to show off.

It’s an about box. It’s quite Gnomey, though.

Source code that a CS 101 student would get a pass minus for. Needs more comments. Also more cowbell.

Output brought to you by wxHtmlWindow. Don’t bother sending it CSS.

The debug log — now in a text control instead of stdout!

And, to prove that the Windows build works:



SCons + wxWidgets FTW. Well, apart from that whole custom event business, anyway.