Five Minutes

Well, it’s deadline time, so I’m going to push a release of the DBGp frontend formerly known as wxDBGp and now known as Dubnium out for GSWoC evaluation. Nevertheless, I don’t really recommend using this just at the moment, because this release is cursed.

No, really.

In the last week, I’ve shredded my left knee for the second time in eighteen months, rendering me unable to drive a manual car (again), unable to walk without pain (again) and, importantly, unable to sit at a computer for long periods (again, and it’s made finishing off a release difficult). On top of that, I’ve been wholly unsuccessful in finding hosting that doesn’t suck (which rules out Sourceforge) and actually works more than 43% of the time (rules out Google Code Hosting and its entertaining array of internal server errors). To top that off, I discovered tonight that the secondary DNS for the domain that would have been the fallback has apparently chewed up my carefully crafted zone file, spat it out, and replaced it with an old one — and, naturally, it’s getting used instead of the primary for some reason I don’t have time to figure out. I blame Virtualmin anyway. Oh, and my ADSL connection has spent the night going up and down entertainingly, which I suspect is a sign of imminent phone line doom (again).

It hasn’t been a good few days.

So, with the venting and dire warnings out of the way, and the unhappy thought that I’m actually not really done with this and don’t actually consider what’s done releasable just yet, you can now get a copy of Dubnium for yourself. At some point I’ll get Trac and a public Subversion server set up for it, but for now, you’ll have to content yourselves with either a source tarball featuring a wacky SCons-based build process or an MSI that features absolutely no user interface, but which does actually seem to install and uninstall correctly. You can report bugs in the comments if you really want, but I’d wait for Trac.

Source tarball: dubnium-0.1.0.tar.bz2 (119kB)

Windows MSI: dubnium-0.1.0.msi (1.3MB)

Mac OS X users will have to wait a little longer, as I haven’t had time to whip the application bundle generation into shape (and won’t bother now that I’ve decided to scrap SCons as a build system and — sigh — move to more platform-specific systems) as will anybody wanting something that doesn’t suck. I’ll try to get a real release out the door when time permits, which with my courseload this semester, may be a bit further away than I’d like.

I’d say this will be my last (or next to last, if I decide to send through a post when there’s a home page for Dubnium) post on Planet SoC, so if you’ve made it this far, thanks for reading. I’d like to thank Google once again for letting me have a go at this, and Derick for mentoring the project.

So, Dub on! Just… not until 0.2.0.

Another quick Summer Winter of Code update, since I have to be up again in about six hours to go to my feature film scriptwriting class. While there’s not much visible progress to report, some behind the scenes work has taken place — some of it feature and stabilisation work, some of it deciding what’s in and what’s out of the first release. (More on the upcoming 0.1.0 release later.) In bullet form, here’s what little I’ve managed to accomplish since the last update:

Things done since a week and a bit ago

• Added a dialog that pops up with a property is double clicked and shows the value and type of that property, along with its children. The UI for this isn’t all that pretty (if only wxWidgets had a combo tree/grid control…), but it is functional, and the somewhat ugly nature of the dialog is something that can be dealt with after 0.1.0.
• Rejigged the output in the call stack pane to be more useful without requiring either horizontal scrolling or a tooltip implementation that works. Again, this can be polished a bit more after 0.1.0; the important part for now is that it’s functional.

Things I’ve done but which are currently #ifdef’d out:

• Support for saving a default pane layout. I had issues with wxAuiManager::LoadPerspective and wxAuiManager::SavePerspective the only other time I’ve tried to use them, too, so I’ve presumably misunderstood something fundamental about how they work.
• Watchlist support. Actually, this is on a branch, rather than being #ifdef’d, but that’s mostly because it involved a bit of invasive refactoring of the breakpoint pane code to make it more generic. Said refactoring broke something, and I don’t think I’m going to have time to fix it before 0.1.0 — the priority of this went down considerably when I remembered that XDebug doesn’t actually support watch breakpoints anyway at the moment.

Things pushed to after 0.1.0

• Watchlist support, as above.
• Syntax highlighting rules for languages other than PHP.

The rationale for the above items is that 0.1.0 needs to be out shortly; given the ever-increasing workload of uni (including now having an actual final Computer Science project to do — it’s an interesting one, and I’ll doubtless blog about that soon, but it’s also going to chew up that little sliver of remaining spare time I had outside of film-related work), that means next week, regardless of the SWoC deadlines. Therefore I’m going to concentrate on the functionality required for PHP and XDebug right now, and revisit supporting other DBGp implementations after that.

So, what’s left before 0.1.0?

• Finding a better name than wxDBGp and producing some sort of icon.
• Add an options dialog for font and basic network (IDE key and listening port) settings.
• Windows packaging.
• Write some rudimentary documentation.

That’s now a pretty short list, which is obviously good, given the limited amount of time I have available to work on it now. At this stage, I’m going to try to get that done mid-late next week, so hopefully by this time next week, I can pop up a blog post pointing people to a tarball (and, with luck, an MSI, an OSX application bundle…) and simply stress about everything else.

No screenshot this time, but as threatened a couple of updates ago, here’s a scan of my initial UI design document for the main debugger window. Mark Greenaway can take heart in the knowledge that he’s not the only one with bad handwriting.

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.

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!

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.

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.

(more…)

This humble little blog has ended up on a couple of Planets lately: specifically Planet SoC, the Google Summer of Code planet which is getting a limited feed of GSoC related posts, and Planet Linux Australia, who are unfortunate lucky enough to be getting a full feed at the moment.

So, uh, hi. I’m Adam. For the benefit of the Planet SoCers, I’m going to be working on a GUI frontend for debugging PHP applications. When I’m not doing that, I spend entirely too much time in film edit suites, writing scripts of both the film and computing variety, taking part in the usual third year computer science group projects, and trying to work my way up the PEAR bugs-fixed ladder. When I’m not doing any of that and I have money, I go to excellent conferences and take part in ill-advised experiments with wireless networking.

Sometime this year I hope to get a full night’s sleep. I’m planning it sometime in December after OSDC. Until then, expect occasional rambling blog posts. Like this one.

Well, I’ve been accepted into the Google Summer Winter of Code. My proposal is to build a GUI frontend for Xdebug‘s debugging functionality — and to answer a question I’ve already been asked on IRC, I’m currently planning on using wxWidgets as the GUI toolkit.

For the record, the abstract is:

Xdebug [1] provides a range of useful functionality for PHP developers, including detailed error information, code coverage and profiling support, and support for remote debugging using the GDB or DBGp protocols. At present, there are several DBGp implementations available as part of larger IDEs [2], however there is currently no standalone GUI application that can be run to debug applications using DBGp without tying the developer to a particular IDE.

Under this proposal, a cross-platform GUI application will be developed that implements the DBGp protocol to allow PHP applications to be debugged using Xdebug in a development environment agnostic fashion. This application could then be further developed to include support for other run-time environments that support the DBGp protocol, which includes Python with Komodo [3] and may also include Ruby in the future [4].

[1] http://xdebug.org/
[2] http://xdebug.org/docs-debugger.php#clients
[3] http://aspn.activestate.com/ASPN/docs/Komodo/4.0/komodo-doc-debugpython.html
[4] http://dev.eclipse.org/mhonarc/lists/dltk-dev/msg00001.html

I’m really looking forward to working on this, and will doubtless blog about it as development gets going. Thanks to Google, the PHP developers who selected the projects, and Derick, who’s going to be the mentor on the project.