Five Minutes

I’ve just released version 1.7.13 of PEAR’s DB package. This includes a couple of minor fixes for the MySQL, MySQLi and SQLite drivers, none of which I’d class as particularly urgent. Grab it at your leisure from a PEAR server near you.

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.

I’ve mentioned my final Computer Science project a couple of times now on the blog without actually describing what it is. Now seems like a good time to do so, having just spent a solid afternoon and evening on it. The summary (which remains one of only two pieces of actual paperwork written for the project thus far — thank $DEITY this isn’t a group project with meeting minutes and the like) reads as follows:

To develop a networked simulation of a garden system that allows users to maintain the garden by interacting with individual plants, which are simulated using the principles of L-systems.

Put more simply, the idea is to build a client/server system that provides something like a SimGarden over the Internet. Fortunately, much of the theoretical work needed for this has long been done, and most of it is in The Algorithmic Beauty of Plants, so that has largely left me to worry about the parts of the project that don’t involve quantifying plant physiology and behaviour, like rendering L-systems in a manner that can render a simple plant (without leaves) at more than 0.4 frames per second on my iBook.

I’m still working on that little problem, but the fact it’s rendering at all is progress — it means the 3D turtle is working (yes, it’s just like Logo, except in Python and with an extra dimension to confuse people), the L-system parser can at least deal with simple L-systems, and all in all, I’m feeling rather content with life, given that five weeks ago I didn’t even have a project (the project I had planned fell through due to the supervisor leaving the university) and four weeks ago I had no idea what OpenGL code even looked like. Of course, said contentedness is likely to evaporate any moment now, given the amount of work that’s still ahead.

I sign off tonight in the traditional fashion: screenshots.

One of the units I’m doing this semester is Internet and Java Programming, albeit not by choice — it’s a required unit for the Computer Science major here. Whether that actually makes sense is a debate for another blog post, but today’s lecture and workshop featured some gems. In particular, I wanted to share these three slides:

Now, I’m no Java expert, but that looks like a big fat SQL injection vulnerability to me. If so, it’s good to know we’re teaching our graduates of the (near) future secure coding practices. For the record, the sole mention of prepared queries in the course appears to have been a throwaway line in last week’s JDBC lecture which didn’t mention why you might want to use them. Oh, and the textbook uses very similar examples too, and fails to mention any potential problems even in the chapter on security.

It’s days like this I wonder why I tossed in a good job to finish my degree this year. 0.59 semesters to go.

(Slides © 2007 Edith Cowan University; fair dealing usage asserted under the criticism and review provisions of Australian copyright law.)

For your viewing pleasure, this blog is now available through the finest client-server protocol of 1991: Gopher! Yes, gopher://✎.net is now active.

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?

I’ve just had my first whooshing sound of the semester as a deadline whipped by at a rate of knots without the associated assignment actually being ready. Not a happy feeling, considering we’re still the best part of two weeks from the mid-semester break. Unfortunately, I just haven’t figured out yet how to juggle the seemingly insane requirements of the units I’m doing this semester, and consequently, two of the units (Feature Film Scriptwriting and the dreaded Internet and Java Programming) aren’t getting much love at present, let alone anything outside of uni.

Speaking of which, sorry, people waiting for a PEAR DB release. I haven’t forgotten about you.

Anyway, some things are happening, at least. The Computer Science project I’m working on is cool, and terrifyingly large in scope at present. (I’ll write a proper blog post about that later in the week, hopefully.) My latest film project has started shooting, and as we work our way through that process, I’m gradually realising just how much I’ve dropped myself in it as editor. The next time I write a script with that much chromakey work in it, I’m making sure that I don’t actually have to do anything related to said chromakeying. As things stand, I have to composite four — actually, it might be five, now that I think about it — scenes in post, including one against a virtual set which I’ve only had time to partially build so far. I mean, There are walls. There’s a screen. There isn’t anything resembling a door, though, and I still have to match the lighting to the actual set-up we’re using against the bluescreen, so partially built might be optimistic. Slightly built might have been a better phrase. Next time, we’re using flats, even if I have to spend all weekend painting them.

It’s interesting watching shooting take place for a script I wrote, though. I’m sure it’s even more fulfilling for Reuben, our director, since it was his story idea in the first place, but I keep feeling both proud of the fact that the scenes being shot are the ones I scribbled out, and worried that if we suck, it’s going to be largely my fault — you can talk about how the director is the true author of the film all you want, but JMS has referred to certain things on Babylon 5 being writer problems, and I suspect that most of the potential issues with this film are going to be in that basket.

At least I get the chance to fix them in post. (We’ll fix it in post is the film student mantra, it seems.) Of course, said fixing might require sock puppets…

Yep. Just like that.

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!