Five Minutes

This is an edited version of the update on my Google Summer Winter of Code project that I’ve just sent to Derick, my project mentor. For those playing the home game, my project is to write a wxWidgets-based debugger frontend for PHP’s XDebug extension. This is a long (almost 1000 words) update and pretty dry, so you can read it after the jump if you’re particularly interested in the details. If not, the short version is that I started very late courtesy of my final TV scriptwriting project not being complete until the 15th, but reasonable progress has been made on the library that will talk to XDebug via the DBGp protocol.

I’ve been meaning to write an update on my project for about a week now, but every time I’ve sat down to do it, I’ve ended up writing more code. Bad habit, that.

Due to the rather late start I had, I’m somewhat behind the schedule I originally planned out, but not as far behind as I originally feared I would be. I’ll break down the report into a summary of where I am with each area of the project.

DBGp Library

Development

I’m partway through DBGp library development at present (the major missing pieces as I write are support for the property_* commands, stdin/stdout/stderr redirection, eval/expr/exec and spawnpoints, and I’m planning to work on the property support today). I’ve compromised somewhat on the library — my original hope was to write a fairly general C library that could be used in other projects, but to speed up the development process and ease integration with the UI, I’ve instead made it dependent on wxWidgets. The advantage of this is that I can use the wxWidgets event and socket functionality, which neatly integrates socket handling and associated callbacks with the wxWidgets main loop without needing to worry about spawning threads to save blocking the UI (and I know from past experience that wxWidgets is difficult to use in a multi-threaded application, due to the fact that most of its GUI classes can only be called from the main thread), but the obvious disadvantage is that it’s no longer particularly useful for people who aren’t using wxWidgets. I’m keeping it internally separate from the UI code and building it as a library within the build process, but it won’t be released as a separate library now.

Library Documentation

The main classes have full docblock documentation which can be parsed by doxygen. The breakpoint- and stack-related classes don’t yet have docblocks, simply because I wrote them last night and haven’t gotten around to it yet, but I intend to complete the documentation over the weekend. I’m not sure if there’s much point writing much higher-level documentation for the library, due to its aforementioned lack of general utility, but I definitely want the code-level documentation to be as complete as possible to ease maintenance.

Testing

The other thing I have left to do on the library apart from finishing off the feature support is to write unit tests (using CPPUnit) for it. At this stage, I’m expecting to spend most (if not all) of next week on that. I strongly suspect there won’t be sufficient time for complete code coverage, but I’d like to get the key parts of the library covered and then leave the option open to come back and fill out the test suite further down the track.

GUI

The delayed start has meant that I haven’t had time to prototype the GUI yet. I do have a couple of trivial programs written for basic ad-hoc testing, but they won’t form the basis of the final GUI. Writing those programs suggests that the library, as it stands, is quite wxWidgetsy (OK, I made that up, but I’m using it to mean the wxWidgets version of Pythonic) and is quite simple to integrate with wxWidgets GUI classes. I expect to start sketching out UI ideas late next week using my usual process — random scribbles on paper, followed by quick and dirty prototypes in wxPython, then followed by actual development.

End User Documentation

Not started yet and won’t be for a while, obviously.

Naming

I’ve gone for the imaginative route so far and am calling the library libDBGp and the application wxDBGp at present. I expect they’ll change to something less prosaic when I get closer to a release.

Portability

Because I’m using wxWidgets to abstract the socket and event handling, this should be at worst a minor issue. At this stage, I’ve only developed and tested on Linux (albeit with two architectures: AMD64 and PPC32); part of my motivation in writing the unit tests next week is so that I can build them on Windows and run the test suite there rather than relying on ad-hoc testing.

Plans

At this stage, I’m hoping to get the library to a feature-complete (if only patchily tested) state by Sunday night, which will then lead into an exciting week of writing unit tests next week. After that, I’ll prototype the GUI, probably pop a couple of ideas up on my blog for people to point and laugh at, and then start working on the GUI proper.

So, that’s pretty much that. Lots of work still to be done, but progress is happening, and I’m pretty confident that the project will be complete by the time the Summer Winter of Code concludes.

This entry was posted on Thursday, June 28th, 2007 at 13:53 and is filed under GSoC, PHP, Tech Geekery. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.