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.
I have created a project for uri_grammar on Google’s new code hosting service, largely as a means of testing the waters. Though right now the only thing of interest that’s there is another link to the tarball. While Google provides Subversion hosting, it doesn’t look like there’s currently a way to import the contents of an existing repository into it. I won’t be populating the Subversion repository there until I can do that.
The site sports the type of clean, uncluttered interface one would expect from a Google property. And it’s quite snappy, too. It’s a pleasant departure in these respects from SourceForge. But while Google hosting executes very well the things it provides, there is a lot missing compared to SourceForge. Significantly, Web hosting and release hosting are absent. It will be very interesting to see where this goes, though.
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).
More Mozilla plug-in twiddling over the weekend. Perhaps it is only my naïveté about GTK+ and my preconceived notions of encapsulation; but it seems like GTK+ really wants me to implement my own widget in order to tie the lifetime of something to that of a widget. So that is what I have done, yielding GtkVrmlBrowser. It works; except that GtkGLExt doesn’t seem to clean up after itself properly.
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.
So autotools sniping is in season on advogato. This really does get old.
To those claiming that GNU make + pkg-config can do the job, Do It: show me a build system that will give me all that automake does with no more work than that tool makes me do. I won’t be satisfied with anything less than a fully functional make distcheck.
Don’t stress. I’m not holding my breath.
The fact is that there’s an enormous amount of knowledge about portability and general build requirements encoded in autoconf, automake, and libtool. Solving the portability problem and providing sufficient primitives for automating a sufficient number of tasks to satisfy a sufficiently large and diverse sampling of projects in order to be taken seriously is no mean feat. The burden borne by the autotools in facilitating open source (and other) software should not be underestimated, much less trivialized.
Whining that configure wasn’t checked in because the project developers don’t want the noise in their changesets? Spare me. Learn to use the autotools.
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.
I’ve been a fan of Spirit ever since it was first released. But trying to use it in any sort of nonobvious way always makes me feel not quite smart enough. The documentation is what I’d call a Good Start; maybe it’s even 70% of the way there. It is well-written; but it is written for someone as smart as its author or nearly so. I for one could use a little more exposition and a lot more examples.
But slowly, I think I am Getting It. After rereading documentation several times and searching the mailing list archives, I think I have attained my goal of making the semantic actions for my URI parser pluggable as a template parameter.
I wrote the URI parser for OpenVRML. But it is an implementation detail there, which makes it a bit difficult to test in that context. So I have broken it out into its own package to facilitate testing. That was really prompted by this claim that the URI parser leaks memory.