Five 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.

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

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

Well, I’ve applied for the Google Summer of Code, but it looks like I’m only going to have time to submit one proposal, sadly. I guess I’ll just have to cross fingers and toes on this one.

Now for the countdown to the announcement of who got accepted on April 11…

Note to everyone posting on Mozilla bug 18574 (restore support for MNG animation format and JNG image format): it’s time to get over it. The Mozilla/Firefox drivers have once again made their decision (which I’m convinced is the wrong one made for the wrong reasons, but hey, nobody’s perfect), and I for one could do without the endless, circular arguments that have been filling up my inbox today. Take it to the MozillaZine topic in the URL field, for crying out loud.

Still, I think this does highlight a major flaw in the Firefox development structure: the wishes of users are generally completely ignored. This isn’t the first time this has happened, and won’t be the last. I just hope it never gets to the point where I drop the browser again and switch back to Konqueror.

(And yes, I’ve removed myself from the CC list. No, I don’t have the motivation to maintain my own fork of Firefox. Yes, that makes me a whiner. No, I don’t care. :)

I’ve been awaiting the arrival of the Summer of Code mentoring organisations, which were due today. Sadly, there seem to have been some technical glitches at Google, as they first posted five or six mentoring organisations, then dropped them again and put up a message that they’ll be posted here soon.

Obviously I now have the time to actually take part in the Summer of Code (plus, the money would be really handy), but the catch is that I have to figure out what I actually want to attempt. The obvious thing to do is something PHP related, given my work background, but I don’t know if I’d actually be happier picking something a bit different as a change of pace. (I was, for a moment, interested by the idea from Richard Lynch on PHP-DEV to write a JIT compiler as a SoC project — then I attended my PLP lecture on compilers and thought better of it.)

Unfortunately, this is the point where I start second-guessing myself because I’m not visible enough within the open source community and hence feel as though it’s not worth applying for anything. I guess the challenge is to get over myself before the application deadline on March 24 and get at least a couple of applications in.

Anyway, I look forward to the list of organisations and project ideas going up. I’ll doubtless post which ones I apply for on here — provided I actually do apply!

Last day at the office, so I guess I won’t be seeing my desk again in its natural, paper-covered state. Behold!

Also, bought a new mobile phone, which took the above picture and then (after a bit of jiggery) even managed to transfer it to my laptop via Bluetooth. Sweet.

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.