So, I’ve spent the last couple of days pushing a few things up. It’s not going to completely replace my need to have some Git repositories on my own server (there are things that aren’t open source or aren’t for public consumption, like my resume — although making that open source could be entertaining), but it’s definitely handy for other things.

Obviously, my user page is going to cover the full list of things at any given time, but the projects I’ve uploaded so far include:

• CineJS — the Javascript video processing library originally introduced at LCA 2010 and in an earlier blog post. There are a couple of releases probably coming for this in the next few months: an interim release to work around what looks like a bug in Mobile Safari on the iPad, and a more featureful release which will hopefully have the first steps towards WebGL support. I’ll probably get rid of the Google Code site for CineJS in the near future, since there’s no point having two issue trackers.
• Dubnium — long time readers will remember this as my Google Summer of Code project back in 2007, and it’s been neglected far too long. It is, in essence, a cross-platform GUI debugger for PHP code. It’s gotten a bit of love in the last few months and I really just need to spend a day or two cleaning it up for a release. Unfortunately, part of that process involves getting a Windows build environment set up, and that’s rather killed my motivation so far.
• A couple of little Gopher related things: the source tree for wp-gopher, my Python-driven Gopher interface to WordPress (which you can see in action on this very blog) and a Gopher stream wrapper for PHP that I knocked up on my lunch break today just for the hell of it, which I’m currently imaginatively calling php-gopher. Let’s face it: these are obviously Important Projects.

So, yay GitHub, helping me procrastinate from doing actual development work in my spare time for two days now. (Yay may not be the right word.)

I present this example from the DateTime::getTimestamp() manual page. It’ll be disappearing from the mirrors over the next few hours, because I’ve deleted it (and posted a much simpler note in its place), so here was its content, for posterity:

If you are using PHP < 5.3.0 you can use this function instead:

<?php
function DateTime_getTimestamp(&$dt) {
$dtz_original = $dt -> getTimezone();
$dtz_utc = new DateTimeZone("UTC");
$dt -> setTimezone($dtz_utc);
$year = intval($dt -> format("Y"));
$month = intval($dt -> format("n"));
$day = intval($dt -> format("j"));
$hour = intval($dt -> format("G"));
$minute = intval($dt -> format("i"));
$second = intval($dt -> format("s"));
$dt -> setTimezone($dtz_original);
return gmmktime($hour,$minute,$second,$month,$day,$year);
}
?>

It’s fair to say that’s an interesting approach. The normal way of doing it would be:

<?php $timestamp = $dt->format('U'); ?>

I don’t know what the answer is — moderation has its own problems to do with workload, as PEAR can attest — but a system that’s letting that go up as recommended practice (and stay up for a month) has to be looked at.

Thanks for not reporting this before release..

Now, Jani does a tremendous amount of work triaging PHP bugs and I — and every other PHP developer (particularly those of us who does this for a living) — owe him a huge debt for that. But frankly, I resent the implication that I’ve somehow sat on a crasher since before 5.3.0 was released and only submitted it now as some sort of weird vendetta against the PHP internals team. Funnily enough, I only found it while I was reducing the other, more trivial bug down to a minimal test case.

I get far worse things implied in my direction when I’m out on a Saturday night in Northbridge, so really, I’m not that fussed. (I’m obviously a bit fussed, though, since I’m writing this.) I do wonder how somebody new to the PHP community would feel, though — my guess is that you could forget about future bug reports in some cases, and that just isn’t a win for anyone.

All being well, I’m looking to get 1.7.14 final out around Monday (along with an Informix fix that I can’t work on without my Informix testing VM). Please feel free to test this release and report any issues.

include 'PEAR/Registry.php';

$reg = new PEAR_Registry;
foreach ($reg->listPackages() as $package) {
    print "$package\n";
}

This should work with pretty much any version of PEAR.

(Update: Ken has a nifty bit of code in the comments to check for a specific installed version of a package.)

Important note: It’s been this way for a couple of years now, but I’d again like to reiterate that DB is deprecated in favour of MDB2, which is pretty DB-like if you load the Extended module. If you haven’t already made plans to migrate your programs depending on DB to MDB2, now might be a good time to start.

Particularly in light of this post to PEAR-DEV, which I predict is going to create considerably more e-mail for me to sort through. Short version: I’m considering setting an end-of-life date for DB at 8/8/8, the same as PHP4′s end-of-security-fix-life date. If you want to address the open questions in that post, feel free to reply to PEAR-DEV or my e-mail directly. My e-mail address is on the sidebar both on my blog home page and my about page.

The hacked-up bit of Python that powers this can be had under the MIT license: wp-gopher-0.1.tar.gz. Time will tell if there’s a 0.2, but I wouldn’t hold your breath. Send any bug reports or patches to the e-mail address in the README. (Preferably patches.)

In related news, I think complete madness has now set in due to the stress of uni. Hooray!

Addendum: This is also available via IPv6 at gopher://[2001:5c0:8fff:fffe::6f6b]/. Is this the only IPv6 Gopher server on the Internet, I wonder?

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.

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.

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.