Five Minutes

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.

It’s about a month later than I originally planned, but PEAR DB 1.7.12 has just been uploaded to a PEAR server near you. If you’re using DB with PostgreSQL and PHP 5.2.x, you’ll want this version, due to a backward compatibility break in PHP 5.2′s pg_escape_string. Otherwise, there’s not too much that’s exciting, although hopefully the Fedora Extras packaging guys will forgive me for screwing up the test suite slightly in 1.7.11!

Note that DB will no longer install with PEAR installers earlier than PEAR 1.4.0, as it now uses the newer package.xml format introduced in that version. That being said, if you’re still using PEAR 1.3, you really should upgrade per the instructions on the PEAR web site, since it’s no longer supported and all.

As per my usual plan, I’ll release 1.7.13 at the end of July (hopefully) if any bugs are reported.

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…)

Bertrand Gugger, better known to many as toggg, passed away on Saturday night from a heart attack. Bertrand was a contributor to PEAR, jQuery, TikiWiki and SPIP, who have compiled a tribute page to him.

He was a strong, valued member of the PEAR community who was always ready with an opinion, a joke, and helpful advice. Indeed, last year, Bertrand was the first person to help me when I was getting involved with PEAR development, and I always enjoyed chatting to him on #pear. Like many others, I’ll miss his company and experience.

Bertrand is survived by his wife and four children, and my condolences go to them on their loss.

(Image from Flickr; taken by Olivier Gendrin.)

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.

One of the problems with maintaining PEAR DB is that it’s a little hard to plan out future releases, given that it only gets bug fixes and no new features. The approach I’ve been using since the release of DB 1.7.8 (the last big catch-up release) is to push out new releases more or less as I fix stuff, which tends to result in numerous small releases, sometimes quite close together. This works, but I know that it would have annoyed me when I was wearing my sysadmin hat, so I’m going to try something different for the next little while.

What I’m going to do for now is to plan a release on the roadmap for the end of each calendar month. Non-critical bugs, instead of causing a full release, will instead be fixed in CVS and a release will be pushed out at the end of the month with that fix and any others that went in. Obviously, if there are no bugs reported during the month, then the release won’t occur and I’ll instead change the roadmap to push the release back a month.

Critical bugs will still get the immediate attention they need, and releases will be made as quickly as possible for them, rather than waiting for the end of the month. However, I think it’s important not to overload programmers, packagers and sysadmins with overly frequent releases, so we’ll give this a whirl for now.

Incidentally, you can assume that DB 1.7.11, which I’ve just released with a FrontBase-only fix, is the end of March release.

(Oh, side note I forgot to put in the initial post: I’ve re-enabled trackbacks on DB for now. If the spam starts annoying me again, then I’ll disable them once again. Here’s hoping.)

For some reason I still can’t quite fathom, people have been interested in my Hackfest entry at LCA. Specifically, the entry I put in for the Audioscrobbler question, which asked us to create a program that could interface with the Audioscrobber related artists API. I decided to write a buzzword compliant Web page. So, I’ve uploaded it to http://www.adamharvey.name/hackfest/ for your viewing pleasure. You’ll need a browser with decent XHTML and SVG support. Firefox 2 seems to handle it nicely.

It uses PHP 5 for the little bit of backend processing it requires, but most of the heavy lifting is in Javascript. The only other dependency is the HTML_AJAX PEAR package — I developed against a test release of 0.5.1, but 0.5.0 should work as well.

The files I actually wrote (be warned, they’re messy and undocumented):

• index.php: The entry point for the user. It’s only in PHP so I can control the Content-Type header.
• server.php: The AJAX server which pulls in the Audioscrobber related artists information.
• audio.js: The Javascript that does the heavy lifting of getting the related artists information and spitting out SVG via the DOM to render it.

You can consider these files to be licensed under either the GPL (which was a condition of entering Hackfest) or the MIT License. HTML_AJAX is licensed under the LGPL.

Today’s the first day I’ve really gotten down and dirty with PEAR DB development. The important bug I wanted to jump on was bug #9599, which meant that error handling was broken in PHP 5.2 for people using DB with mSQL, SQLite or Sybase databases.

Although my earlier post indicated that I was going to try to have DB 1.7.7 out before the New Year with this fix, that now won’t happen, mostly because I can’t test the release to my satisfaction here at home. I’m back at the office on Tuesday, however, and hopefully the release should be out next week.

For the particularly adventurous, I’ve packaged up a 1.7.7 release candidate from CVS, which you can get here. I’m reasonably confident it’s OK, but I’m not going to release this through PEAR — there’s just too much that can go wrong, since I haven’t even looked at some of the drivers yet, nor have I done much testing with PHP 4.