The Tyan K8WE motherboard in hinge has always seemed to have flaky DIMM slots. I seemed to have to wiggle the DIMMs just right in order for the machine to recognize all of the memory. A recent graphics card upgrade nudged things and I was unable to nudge them back into an agreeable position. The board had about a month left on its three year warranty; so, back to Tyan it went.

So I am without my primary development machine for at least a week. It’s hard to believe I’ve had this thing for nearly three years. Last year I upgraded the CPUs to Opteron 285s from the 242s I originally installed; but still it doesn’t seem that old. Its predecessor was a dual Pentium 3 machine that lasted me five years

When hinge is put back together, I think I’ll go ahead and release OpenVRML 0.17.6. I still haven’t fixed that damn JPEG bug; but I think there have been enough less consequential changes to warrant a release.

Another change I’d hoped to work into a point release in the 0.17 series is the use of D-Bus to replace the existing IPC mechanism used in openvrml-xembed. Aside from being generally cleaner and nicer than the existing hacky IPC solution, I’m thinking that expressing the IPC interface in D-Bus should lead to an improved code organization that will in turn make it easier to convert the existing multiprocess approach into a multithread approach for Mac OS X and Windows. This is becoming more pertinent as it seems there may be folks interested in contributing code to a Windows plug-in.

I have spent a large chunk of my free time over the last several months replacing OpenVRML’s ANTLR parsers with ones using Spirit. This was my first attempt to do something nontrivial with Spirit. So this comment from the author of Spirit absolutely made my day.

I have begun to wonder just what it would take to create an ActiveX control for OpenVRML.

It has been about a decade since I touched COM. At the time, I had just (barely) learned C++. And I was struck then that just about every Good Practice for C++ I was learning about was being flagrantly violated in COM.

I quickly lost an affinity for Windows programming for that and many other reasons. I’ve done development primarily on POSIXy platforms; but much of that has been sufficiently portable to Windows that I’ve maintained a superficial knowledge of Windows development. But I’ve done enough development and I have a sufficiently deep understanding of C++ that something like COM just isn’t intimidating anymore. Which is not to suggest that I relish picking it up; but, rather, my annoyance at it is overcome by both a desire to show something working and a morbid curiosity about Just How Bad It Is.

My first thought was to apply the “modern” technique for building COM components, ATL. ATL is a template library; though the Wikipedia entry that (as of this writing) claims that ATL was patterned after the C++ STL is quite far off the mark. Aside from being written in C++ and using templates, there isn’t much similarity between the two. For the most part, ATL seems to be a bunch of CRTP mixin class templates. I can see how I would value the legwork it saves me if I had 10 or 20 or 100 COM components to write. But as I have just one, the obfuscation implicit in ATL usage seems unlikely to pay off.

And it’s just as well. Apparently Microsoft no longer includes ATL with the Windows, née Platform, SDK. So if I want this thing to build with the Express version of the compiler, no ATL.

It’s a bit too early to say if this effort will actually pay off in terms of a usable OpenVRML ActiveX control. It could happen. It could also be the case that I become so put off with the API that I never consider doing this again.

I guess I shouldn’t be so surprised; I was immediately taken with Spirit upon discovering it. Though back in 2001 Spirit still had a good deal of growing up to do; it’s come a long way since then. And given that Joel de Guzman and his cohorts are hard at work on Spirit 2, I get the idea that it will yet go a good deal farther. But I digress.

It’s the middle of 2007 and I’ve gotten serious about writing a VRML parser for OpenVRML using Spirit. Why now? Well, ANTLR certainly hasn’t gotten to be any less of an annoying dependency over the years. But another factor is that a new major version of ANTLR has been released (3.0). I think my efforts are better spent moving away from ANTLR entirely than on upgrading to the new version (which I understand to include nontrivial changes to the grammar format).

Now, I don’t want to come across as disliking ANTLR. It’s a really nice tool. In fact, it’s the nicest parser generator I’ve ever used. Functionality is very discoverable and I found, for the most part, the general behavior of ANTLR parsers to be very intuitive. But it has its downsides:

It’s a code generator, and thus it has the caveats that go with any code generation.

It’s a Java program, and thus it has the caveats that go with any Java program.

Even though it can generate code for a number of languages that are Not Java, the Not Java language backends are maintained by persons other than the primary author of ANTLR; thus, these languages wind up being second class citizens. (For example, ANTLR 3.0 has been released without C++ support since the maintainer of the C++ backend for ANTLR 2.x didn’t have time to port it to the new version.)

I actually started in earnest on this project at the end of last summer. I made a good deal of headway, getting as far as developing a good understanding of how to use Spirit’s stored_rule to create a grammar with productions that get modified as part of the parse. This solved the somewhat tricky issue of parsing node field values. But then I got side-tracked with getting the stand-alone viewer (openvrml-player) working reliably; that took much, much longer than I’d anticipated. But now I’ve picked up pretty much where I left off. As of this writing, I can parse nodes, EXTERNPROTOs, and PROTOs, except for IS mappings. I still have to do ROUTEs; though they will be pretty easy now that I’ve got DEF working.

As with the ANTLR-based parser, I’m doing a good deal of semantic checking; this parser will be just as aggressive about rejecting code that’s Not Quite Right as OpenVRML’s current parser. But unlike OpenVRML’s current parser, I’m using very little of OpenVRML’s runtime machinery to accomplish this checking. The idea is to make this parser much more reusable than OpenVRML’s current parser. The current parser isn’t really exposed; users can read the file into the runtime and then inspect the node tree created for the runtime. It turns out, though, that a good deal of OpenVRML’s users (and prospective users) don’t care one bit about a VRML/X3D runtime—they just want to read a VRML or X3D file and do something with the data. So, the new parser will have

Pluggable semantic actions

Minimal dependencies on the rest of libopenvrml—ideally, linking with libopenvrml won’t be required at all for someone just using the parser

This will all be possible through the magic of Spirit and C++ templates.

Rounding out the weekend, an Extrusion bug. While at first glance it seems OpenVRML just isn’t normalizing a vector where it should, the larger problem is that the algorithm for identifying linear spines is broken. Sigh.

Since going a season without posting here, I feel like I ought to provide some resolution to some of the things I mentioned here earlier in 2006.

Fall was pretty good for OpenVRML. The 0.16 series (which saw its first release back in August) yielded 0.16.3 by the end of the year—which seems to be a pretty usable release. Even the Mozilla plug-in seems to be basically usable, caveat a really annoying bug in the JPEG decoder. Also, I’ve started packaging OpenVRML for Fedora Extras.

Lately I’ve been spending most of my OpenVRML development time working on a stand-alone player. Like the Mozilla plug-in, it is simply a host to the openvrml-gtkplug out-of-process component. But it exercises openvrml-gtkplug in different ways—which accounts for most of my interest in writing the stand-alone player.

The commonly accepted wisdom in C++ these days is that exception specifications aren’t worth bothering with. While it’s certainly the case that they could be substantially improved to provide more utility, I’m not so dismissive of what they do offer: an assertion that a function fails only in the ways it advertises that it can. In this respect, the exception specification is much like a specialized assert. And like assert, they are valuable as a debugging aid.

If an unexpected exception occurs in a codebase that has made thorough and appropriate use of exception specifications, the exception isn’t likely to propagate far before it results in the program being terminated. Without exception specifications, the exception would propagate all the way up to main before terminating the program. The difference is in the call stack you get from a debugger when termination happens: the nearer termination is to the point at which the unexpected exception was thrown, the easier it will be to find where and why that happened.

If the exception propagates all the way back to main, the call stack doesn’t give you much useful information. You can hope that the exception itself is sufficiently specific as to give you a clue about where it came from; beyond that, your best hope is a debugger that can be configured to break automatically when an exception is thrown.

The other service provided by exception specifications is simply documentation. One might reasonably suggest that this service is better provided by actual documentation; but that is only true to the extent that such documentation is complete and accurate. The fact is that assessment of the exceptions that can be thrown by a function requires a rather thorough inspection of that function an all the ones it calls. And when any of this code changes, the documentation needs to be checked to ensure it remains accurate. Unfortunately, that is all too easy to overlook—even with embedded documentation schemes such as that supported by Doxygen. There is a far more compelling interest in updating something that is likely to crash your program if it is wrong. And an accurate exception specification makes documentation that much easier.

However, as Sutter points out, exception specifications are likely to impact performance negatively. Like the validation done in an assert, the exception specification imposes additional run-time checking. assert, of course, is a macro—and that means that by twiddling a preprocessor symbol, the checking it does can be made to go away completely. And there’s no reason the same solution can’t be employed to toggle the presence of exception specifications: rather than use throw directly when writing an exception specification, use a macro that can be redefined to make the whole business go away when that’s desirable (e.g., optimized builds).

Annoyingly, I can’t expose all the functionality I need through a C interface. What does one do when one needs to pass a C++ type to something in the implementation of a GTK+ widget? I punted and added a C++-only interface to the widget. Not ideal; but I’m not about to implement my own GIOChannel just for this. Another perspective is that I should just be using gtkmm; however, this application doesn’t have nearly enough GUI to justify pulling in the *mm dependency chain.

I had not tested OpenVRML‘s Mozilla plug-in for some time, during which I’d made a number of nontrivial changes to the library. So when I went back to it a couple of weeks ago, I was not exactly shocked that it didn’t work at all. But when I finally realized what was causing the deadlock, it was one of those “How did this ever work?” moments.

So the plug-in has been restored to basically working condition. It still needs a bit more surgery before it will shut down gracefully. Right now it’s hacked by sending SIGTERM from the Web browser process. I also have no faith that its URI fetching is actually working.

OpenVRML‘s make check was busted with most tests failing ever since I checked in EXTERNPROTO support; that’s finally fixed now.

Memory leaks persist. I’ve spent some time tracking down the Spirit-related one and I’ve managed to reproduce it in a test case. Unfortunately, upgrading to Boost 1.33.1 didn’t magically fix the problem. The leak seems to be triggered by parsing in multiple threads.

As a side effect of this activity, my URI grammar is now available in its own package.