Older blog entries for braden (starting at number 117)

6 Oct 2008 (updated 21 Jun 2010 at 06:12 UTC) »

Dylan

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.

Syndicated 2008-10-06 04:22:33 (Updated 2010-06-21 06:02:26) from endoframe :: log

Fading memory

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.

Syndicated 2008-05-25 05:08:34 from endoframe :: log

An RSS parser in PHP for SourceForge feeds

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;
    }
}

Syndicated 2008-01-26 20:26:11 (Updated 2008-01-26 20:26:49) from endoframe :: log

Exception-safe management of JNI local references

…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.

Syndicated 2008-01-21 05:08:59 from endoframe :: log

We’ve got Spirit

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.

Syndicated 2007-12-15 05:27:24 from endoframe :: log

1 Dec 2007 (updated 2 Jan 2008 at 09:08 UTC) »

New Autoconf OpenGL macros

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.

Syndicated 2007-11-30 23:13:57 (Updated 2007-11-30 23:16:41) from endoframe :: log

1997 called…

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 [...]

Syndicated 2007-11-12 03:41:30 from endoframe :: log

Nokia N75

I’ve used Motorola mobile phones since I’ve had a mobile phone, starting with the V60i back in 2002 (as a customer of the original AT&T Wireless), followed with a V551 (with Cingular), which was in turn replaced with a RAZR V3 (upon its untimely demise). The latter two phones had nearly identical software; but I was [...]

Syndicated 2007-09-10 03:04:02 from endoframe :: log

Consolation prize

I discovered Consolas a couple of weeks ago; and I’ve been using it heavily since then. It renders nicely on the Mac (where it has supplanted Andale Mono) as well as with Xft (where it has supplanted DejaVu Sans Mono). Something about Consolas makes Emacs behave just a little bit goofy: for some reason windows sometimes [...]

Syndicated 2007-08-06 20:12:02 from endoframe :: log

A snake in a blender

I didn’t want to like Python. I’m still not sure that I do. But I have to admit that it is starting to grow on me. I’m beginning to get used to its goofy ideas about whitespace. And its double-underscore-emblazoned special identifiers are starting to hurt my eyes less. I have been learning to use Blender. [...]

Syndicated 2007-07-22 07:41:14 from endoframe :: log

108 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!