Dec 262008
 

I started using Linux with Red Hat 5.0. When that distribution morphed into Fedora, I continued using it. And I’ve eagerly installed each new version within days of its release.

In the past 9 years of using Red Hat/Fedora, only my attempts to get Red Hat 5.0 to work with some on-the-motherboard SCSI hardware rivals the pain I’ve experienced installing Fedora 10. While there was some self-inflicted pain described in my previous posting, it was quite mild compared to what I was walking into unwittingly.

Bug 466607 was my first, and biggest, problem. Now, after finding this bug report, the problem isn’t too difficult to work around: there’s a kernel parameter that can be passed at boot time that would get things working. But until one has managed to find this bug report, life sucks.

Then there is the relatively well known problem that NetworkManager—the magical take-control-of-all-your-network-interfaces-and-everything-will-Just-Work system service—actually doesn’t work very well at all with static IPs. Turning it off, one is then bound to run into bug 469434. This one isn’t a show-stopper by any means; but it’s also something that’s clearly a simple goof somewhere that’s bound to be trivial to fix. And yet, even though it was reported back at the end of October, it made it into Fedora 10. Bug 466607, which is much more severe, was reported earlier in October and it made it into Fedora 10, too.

Both of these bugs are, fortunately, now fixed. But my impression is that Fedora release managers need to be more willing to hold up a release to fix bugs that are outright showstoppers for users or simply instances of an egregious lack of polish.

Nov 202008
 

So Evolution decided to go sideways yesterday. I think this was prompted by me changing my SMTP server password. But rather than prompt me for a new password, Evolution simply froze when sending mail. As in “by-all-appearances-totally-hosed-because-the-UI-hasn’t-been-even-redrawn-in-several-minutes” frozen. Attempts to make Evolution forget the old password don’t change this outcome. Ugh.

While it would be ever so slightly gratifying to report a bug on this issue, I figure the Evolution developers won’t be particularly interested since I’m using version 2.22 and the latest is 2.24. Hell, I’d be inclined to blow me off on that basis. And I figure, “The Fedora 10 Preview has Evolution 2.24, I can just update to that.” What could go wrong, right? Well, if you’re the least bit familiar with these things, you know lots can go wrong; and you’re probably figuring that this is where things really start to go south.

But it’s not. In defiance of the odds, that part went okay. And when it was done, the shiny new Evolution 2.24 installation would send mail just fine. There was only one niggling problem: attempting to compose a new message now froze Evolution. Okay, so it just went mostly okay.

Ugh. But at this point I’m inclined to blame myself. After all, I knew I was tempting fate by upgrading to a partial set of Fedora 10 Preview packages. So I figure there must be some poorly-connected dependency I need to upgrade; and I figure “Fuck it; just upgrade the whole damn thing.” And I proceed to torrent the Fedora 10 Preview DVD image.

Deluge pulls it down at around 1 MB/s. Nice. On my bottom-tier cable connection. And I proceed to burn the disc image.

Hmm… Can’t mount that one. Crap. Try again (with Nautilus), but at a slower burn speed.

Damnit. That one won’t mount either. WTF? Check the SHA1 sum. It’s good. Okay, install K3B and try it. Its interface is a mess; but at least it’s produced reliable results in the past.

Fuck. Number three won’t mount and won’t boot. Another coaster.

Or is it? Stick it in the MacBook Pro. Hm. That reads it fine. Hm. Now let’s try stile (which runs i386 Fedora 9). Well fuck me. stile mounts it and boots it as well.

So let me get this straight: my DVD burner on hinge will burn apparently-valid DVDs that the same damn burner can’t read.

Fuck you, Plextor. Fuck you real hard.

This afternoon I ordered a Samsung DVD burner from Newegg for $28. I think I paid around $150 for the Plextor drive three or so years ago.

Meanwhile, I seem to have updated enough packages over the Internet to make Evolution happy. I’m trying to avoid updating X and the kernel so that I can keep my Nvidia driver happy.

 Posted by at 5:57 am
Oct 062008
 

Nvidia has stuck libraries that their libGL needs into a subdirectory; a subdirectory that the linker doesn’t know about. So the customary -lGL is insufficient; one needs to add

-L/usr/lib/nvidia

as well.

So I’ve made a lame hack to AX_CHECK_GL that should accommodate this. (Well, it’s no more—or less—lame than what I had to do for Mac OS X a little while ago.) And there’s a new release.

Oct 052008
 

I have neglected this space for far longer than usual. Time has been short; and most of the time I have free I’d rather spend doing stuff than writing about what’s been done/happening. But there has been no shortage of happenings.

Back on July 14, my son was born.

Dylan, day 2

Dylan, day 2

Now he’s nearly three months old. I’ll post some more recent pictures later. He’s only gotten better looking. For now, Gina’s posted some videos to Vimeo.

 Posted by at 11:22 pm
May 252008
 

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.

 Posted by at 12:08 am
Jan 262008
 

I wrote this for parsing RSS feeds associated with a SourceForge project. It should be reasonably capable for that purpose; though I do not expect it to be generally robust for handling arbitrary feeds. Reed suggested that this might be generally useful; however, I don’t want to put it anywhere that I might feel compelled to maintain it. So this seems like a good spot.

//
// Copyright 2008  Braden McDaniel
//
// This program is free software; you can redistribute it and/or modify it
// under the terms of the GNU General Public License as published by the Free
// Software Foundation; either version 3 of the License, or (at your option)
// any later version.
//
// This program is distributed in the hope that it will be useful, but WITHOUT
// ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
// more details.
//
// You should have received a copy of the GNU General Public License along
// with this library; if not, see .
//

class RSS2Image
{
    var $url = "";
    var $title = "";
    var $link = "";
    var $width = "";
    var $height = "";
}

class RSS2Item
{
    var $title = "";
    var $link = "";
    var $description = "";
    var $author = "";
    var $category = "";
    var $comments = "";
    var $enclosure = "";
    var $guid = "";
    var $pub_date = "";
    var $source = "";
}

class RSS2Channel
{
    var $title;
    var $link;
    var $description;
    var $copyright;
    var $last_build_date;
    var $generator;
    var $image;
    var $items;

    function RSS2Channel()
    {
        $this->title = "";
        $this->link = "";
        $this->description = "";
        $this->copyright = "";
        $this->last_build_date = "";
        $this->generator = "";
        $this->image = null;
        $this->items = array();
    }
}

class RSS2Parser
{
    var $parser;
    var $channel;

    var $in_channel, $in_image, $in_item;
    var $current_element;

    function RSS2Parser()
    {
        $this->in_channel = false;
        $this->in_image = false;
        $this->in_item = false;
        $this->parser = xml_parser_create();
        xml_set_object($this->parser, $this);
        xml_set_element_handler($this->parser,
                                "start_element",
                                "end_element");
        xml_set_character_data_handler($this->parser,
                                       "character_data");
    }

    function parse($data)
    {
        xml_parse($this->parser, $data);
        return $this->channel;
    }

    function start_element($parser, $name, $attribs)
    {
        $name = strtolower($name);
        if ($name == "channel") {
            $this->in_channel = true;
            $this->channel = new RSS2Channel();
            return true;
        }

        if ($this->in_channel) {
            if ($name == "image") {
                $this->in_image = true;
                $this->channel->image = new RSS2Image();
                return true;
            } elseif ($name == "item") {
                $this->in_item = true;
                $this->channel->items[] = new RSS2Item();
                return true;
            }
        }

        if ($this->in_image) {
            $this->current_element = &$this->channel->image->$name;
        } elseif ($this->in_item) {
            $this->current_element = &end($this->channel->items)->$name;
        }
        return true;
    }

    function end_element($parser, $name)
    {
        $name = strtolower($name);
        if ($name == "channel") {
            $this->in_channel = false;
        } elseif ($name == "image") {
            $this->in_image = false;
        } elseif ($name == "item") {
            $this->in_item = false;
        }
        unset($this->current_element);
        return true;
    }

    function character_data($parser, $data)
    {
        if (isset($this->current_element)) {
            $this->current_element .= $data;
        }
        return true;
    }
}
Jan 212008
 

…or, solving the problem of how to delete local references when the execution context isn’t clear.

JNI includes notions of “local” and “global” references. Loosely speaking, local references correspond to those that are local to the scope of a function; and global references correspond to those that persist outside the scope of a function. When Java calls a native method, it provides the native code with at stack frame where local references can be stored. The native code can then proceed to make calls to JNI functions which, in general, return local references. These local references are automatically stored in the stack frame; and the Java runtime takes care of cleaning them up when it pops the stack frame upon leaving the native method implementation.

So far, so good. But not all JNI function calls occur in response to Java calling a native method implementation. In fact, if you’re starting up the VM via JNI, you probably end up calling JNI functions that return local references just the same. Only in this case, the Java runtime hasn’t provided you with a stack frame that it will magically clean up once your code is done executing. Instead, you’ll need to delete the local references explicitly.

Thus we have two very different ways local references must be handled, depending on the context of the JNI function calls. And the inevitable problem: in a utility function which might be called from either context, how should intermediate local references be handled? Consider a function that creates a java.net.URL instance:

jobject create_url(JNIEnv & env, const char * const url)
{
    const jstring url_string = env.NewStringUTF(url);
    if (!url_string) {
        env.ExceptionClear();
        throw std::runtime_error("failed to construct string for URL");
    }

    const jclass url_class = env.FindClass("java/net/URL");
    if (!url_class) {
        env.ExceptionClear();
        throw std::runtime_error("could not find java.net.URL class");
    }

    const jmethodID ctor_id =
        env.GetMethodID(url_class, "", "(Ljava/lang/String;)V");
    if (!ctor_id) {
        env.ExceptionClear();
        throw std::runtime_error("failed to get "
                                 "java.net.URL.URL(java.lang.String) "
                                 "constructor");
    }

    const jobject url_obj =
        env.NewObject(url_class, ctor_id, url_string);
    if (!url_obj) {
        env.ExceptionClear();
        throw std::runtime_error("could not create java.net.URL "
                                 "instance");
    }

    return url_obj;
}

The above code will work just fine when it is called from a native method implementation. But if it is called outside that context, it will leak the local references corresponding to url_string and url_class. (We can assume the caller has responsibility for the local reference corresponding to url_obj in both cases.)

So, let’s toss in the code to delete the local references. We need to be exception-safe, so let’s use ScopeGuard:

jobject create_url(JNIEnv & env, const char * const url)
{
    const jstring url_string = env.NewStringUTF(url);
    if (!url_string) {
        env.ExceptionClear();
        throw std::runtime_error("failed to construct string for URL");
    }
    scope_guard url_string_guard =
        make_obj_guard(env, &JNIEnv::DeleteLocalRef, url_string);

    const jclass url_class = env.FindClass("java/net/URL");
    if (!url_class) {
        env.ExceptionClear();
        throw std::runtime_error("could not find java.net.URL class");
    }
    scope_guard url_class_guard =
        make_obj_guard(env, &JNIEnv::DeleteLocalRef, url_class);

    const jmethodID ctor_id =
        env.GetMethodID(url_class, "", "(Ljava/lang/String;)V");
    if (!ctor_id) {
        env.ExceptionClear();
        throw std::runtime_error("failed to get "
                                 "java.net.URL.URL(java.lang.String) "
                                 "constructor");
    }

    const jobject url_obj =
        env.NewObject(url_class, ctor_id, url_string);
    if (!url_obj) {
        env.ExceptionClear();
        throw std::runtime_error("could not create java.net.URL "
                                 "instance");
    }

    return url_obj;
}

There. Now we can call the function outside a native method implementation. But in making that work, we’ve made the function unusable from within a native method implementation. Clearly we need to make the calls to JNIEnv::DeleteLocalRef conditional; and we’ll have to let the caller tell us what context the function is being called in.

jobject create_url(JNIEnv & env,
                    const char * const url,
                    const bool delete_local_refs)
{
    const jstring url_string = env.NewStringUTF(url);
    if (!url_string) {
        env.ExceptionClear();
        throw std::runtime_error("failed to construct string for URL");
    }
    scope_guard url_string_guard =
        make_obj_guard(env, &JNIEnv::DeleteLocalRef, url_string);
    if (!delete_local_refs) { url_string_guard.dismiss(); }

    const jclass url_class = env.FindClass("java/net/URL");
    if (!url_class) {
        env.ExceptionClear();
        throw std::runtime_error("could not find java.net.URL class");
    }
    scope_guard url_class_guard =
        make_obj_guard(env, &JNIEnv::DeleteLocalRef, url_class);
    if (!delete_local_refs) { url_class_guard.dismiss(); }

    const jmethodID ctor_id =
        env.GetMethodID(url_class, "", "(Ljava/lang/String;)V");
    if (!ctor_id) {
        env.ExceptionClear();
        throw std::runtime_error("failed to get "
                                 "java.net.URL.URL(java.lang.String) "
                                 "constructor");
    }

    const jobject url_obj =
        env.NewObject(url_class, ctor_id, url_string);
    if (!url_obj) {
        env.ExceptionClear();
        throw std::runtime_error("could not create java.net.URL "
                                 "instance");
    }

    return url_obj;
}

Well, there we are. It’s exception-safe and the caller can tell it the Right Thing to do. But…It sure does Suck.

  • It relies on the caller telling it to do the right thing; which means it’s pretty easy to use wrong.
  • We wind up having to check delete_local_refs at each point where we might (or might not) need to call JNIEnv::DeleteLocalRefs. Our need for exception-safety prevents us from consolidating this logic near the end of the function. Consequently, the code is interspersed with yet more error handling logic that gets in the way of understanding the function’s primary logic when reading the code.

So, is there a better way? Fortunately, yes.

JNI provides functions that allow us to create (and destroy) stack frames for local references, JNIEnv::PushLocalFrame and JNIEnv::PopLocalFrame. So, instead of relying on a stack frame that may or may not be there depending on the calling context, we can just create our own, regardless.

jobject create_url(JNIEnv & env, const char * const url)
{
    if (env.PushLocalFrame(3) < 0) { return 0; }
    scope_guard local_frame_guard =
        make_obj_guard(env, &JNIEnv::PopLocalFrame, 0);

    const jstring url_string = env.NewStringUTF(url);
    if (!url_string) {
        env.ExceptionClear();
        throw std::runtime_error("failed to construct string for URL");
    }

    const jclass url_class = env.FindClass("java/net/URL");
    if (!url_class) {
        env.ExceptionClear();
        throw std::runtime_error("could not find java.net.URL class");
    }

    const jmethodID ctor_id =
        env.GetMethodID(url_class, "", "(Ljava/lang/String;)V");
    if (!ctor_id) {
        env.ExceptionClear();
        throw std::runtime_error("failed to get "
                                 "java.net.URL.URL(java.lang.String) "
                                 "constructor");
    }

    const jobject url_obj =
        env.NewObject(url_class, ctor_id, url_string);
    if (!url_obj) {
        env.ExceptionClear();
        throw std::runtime_error("could not create java.net.URL "
                                 "instance");
    }

    return url_obj;
}

Once again, we use ScopeGuard; only now we’re using it to call JNIEnv::PopLocalFrame. Note that we’ve provided space for three local references in our frame, corresponding to url_string, url_class, and url_obj.

But the above code is horribly broken: when we return from the function, the local reference associated with url_obj gets cleaned up with all the others! So, how do we get this reference out of our local frame and return it, unbound, to the caller?

The solution is a temporary global reference. We can convert url_obj to a global reference for the remaining duration of the local frame; and then convert it back to a local reference before returning to the caller. Once more, ScopeGuard is our friend:

jobject create_url(JNIEnv & env, const char * const url)
{
    using boost::ref;

    //
    // We can safely run DeleteGlobalRef in the scope guard because
    // calling DeleteGlobalRef with 0 is a no-op.
    //
    jobject result_global_ref = 0;
    scope_guard result_global_ref_guard =
        make_obj_guard(env,
                       &JNIEnv::DeleteGlobalRef,
                       ref(result_global_ref));
    {
        if (env.PushLocalFrame(3) < 0) { return 0; }
        scope_guard local_frame_guard =
            make_obj_guard(env, &JNIEnv::PopLocalFrame, 0);

        const jstring url_string = env.NewStringUTF(url);
        if (!url_string) {
            env.ExceptionClear();
            throw std::runtime_error("failed to construct string for URL");
        }

        const jclass url_class = env.FindClass("java/net/URL");
        if (!url_class) {
            env.ExceptionClear();
            throw std::runtime_error("could not find java.net.URL class");
        }

        const jmethodID ctor_id =
            env.GetMethodID(url_class, "", "(Ljava/lang/String;)V");
        if (!ctor_id) {
            env.ExceptionClear();
            throw std::runtime_error("failed to get "
                                     "java.net.URL.URL(java.lang.String) "
                                     "constructor");
        }

        const jobject url_obj =
            env.NewObject(url_class, ctor_id, url_string);
        if (!url_obj) {
            env.ExceptionClear();
            throw std::runtime_error("could not create java.net.URL "
                                     "instance");
        }

        //
        // Create a global reference so that the new object will outlive
        // the local frame.
        //
        result_global_ref = env.NewGlobalRef(url_obj);
        if (!result_global_ref) { return 0; }
    }

    //
    // NewLocalRef does not throw any Java exceptions.
    //
    const jobject result = env.NewLocalRef(result_global_ref);
    if (!result) { throw std::bad_alloc(); }

    return result;
}

Ta da. We introduce an additional block scope for the duration of our local stack frame. We propagate the reference to the URL class instance out of the frame’s lifetime by creating an additional global reference. Once the frame is destroyed, this global reference is all that’s left. We then create a new local reference to return to the caller, and let a scope guard take care of cleaning up the global reference.

Nov 302007
 

After nearly a year since pushing this project to Google’s project hosting, I’ve finally made a release tarball of my Autoconf macros for OpenGL. This was motivated mostly by significant changes that were precipitated by requirements for building on Mac OS X 10.5.

10.5 is a bit of a mixed bag relative to its predecessor as far as building with OpenGL is concerned. The good: they finally fixed the longstanding bug with the GLU tesselator callback function type being interpreted incorrectly. The bad: linking with X11 now requires some extremely goofy linker flags.

One nice thing, though, is that I was finally able to get rid of the annoying ‑‑with‑apple‑opengl‑framework option.

Nov 112007
 

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.