Older blog entries for braden (starting at number 52)

RickMuller: The defunct Cosmo Software's VRML player, Cosmo Player, effectively died in 1998. You can still get it here, but it is quite obsolete. ParallelGraphics' Cortona is a completely different codebase.
OpenVRML

My working copy with my event mechanism changes is finally compiling; after being in an uncompilable state for probably about a month. It doesn't link, of course—plenty of unresolved references to things I haven't implemented yet. And there are huge swaths of #if 0'd code that needs to be refactored into the new framework. But it feels like I've made some tangible progress.

I also released version 0.14.2 to address some crash bugs I introduced through carelessness.

ScopeGuard

As I reimplement PROTO support in OpenVRML, I'm making use of ScopeGuard. It's very cool. It's one of those fundamental utilities that anyone writing C++ ought to be using.

As is not particularly uncommon for clever techniques, it exposes C++'s annoying shortcomings at the same time it makes elegant use of its strengths. I wanted to do this:

scope_guard guard =
  make_obj_guard(my_map,
                 &my_map_t::erase,
                 my_map_iterator);

make_obj_guard is a function template whose three function parameters' types are all template parameters. These template parameters—that is, the types of the function parameters—should be able to be inferred, but for one subtlety: because std::map<>::erase is overloaded, the type of &my_map_t::erase is ambiguous. To disambiguate it, either the template parameters must be given explicitly (yuck), or a static_cast must be applied (okay, but still yuck):

typedef void (my_map_t::* erase_mem_fun_t)(my_map_t::iterator);
scope_guard guard =
  make_obj_guard(my_map,
                 static_cast<erase_mem_fun_t>(&my_map_t::erase),
                 my_map_iterator);
16 Oct 2003 (updated 16 Oct 2003 at 23:32 UTC) »
freeglut

It looks like the 2.0 release of freeglut addresses the issue of the header and library names being different from those of the original glut. That's a relief. Unfortunately, the initial release of Fedora will probably not include freeglut 2.0. That's particularly unfortunate given that a glitch seems to have rendered the freeglut 1.3 packages in the distribution nearly useless.

Fortunately OpenVRML builds against freeglut without a hitch. Unfortunately, it's really slow. To be fair, I'm not running accelerated drivers at the moment; but Kilgard's glut is a lot faster. There's also a segfault on exit that I'm pretty sure wasn't there before.

Fedora and glut

So Fedora now includes freeglut instead of glut. That's better than nothing; it will keep me from having to rewrite a toy app in SDL just to keep it compiling with commonly available libraries (or so I hope).

But annoyingly, freeglut doesn't use the same library and header names as glut; so it's not simply a drop-in replacement for glut. I can't imagine why not; it's been years since Mesa adopted the conventional library names used by OpenGL implementations. And these are the days of pkgconfig, when it no longer really matters where exactly libraries and headers are installed; so there's no reason to make the library name different just to coexist with glut.

Oh, well. So now I need to update my autoconf macro for glut to find freeglut as well.

OpenVRML

There always seems to be something I should do before really starting to modify the runtime to be asynchronous. Most recently it has been retooling the event propagation system to use an emitter/listener pattern. This—by itself a substantial undertaking—has in turn required a near-complete rethinking of the way PROTOs are instantiated. So this task, which has already taken a few months, will probably take a couple more.

Before the weekend, I became aware of certain input to OpenVRML that causes my X session to become completely unresponsive. Odds are I'm doing something I shouldn't, which is tripping some bug in my video driver. This is going to be fun to debug. I don't even currently have a machine where I could just log in remotely and see if killing the problem app would restore control; though, that will be changing shortly as I'm bringing another box online to be a Subversion server.

Toys

I ordered some doodads from Anthro for our carts. I should probably find less expensive excuses to clean off my desk.

27 Sep 2003 (updated 27 Sep 2003 at 17:17 UTC) »

I've installed Severn release 2, a.k.a. Fedora Core Test 2. Seems pretty slick; incremental improvements to Red Hat 9.0. The glut RPMs are gone; which is entirely justifiable, but nonetheless an annoyance for me since the piddly viewer program included with OpenVRML depends on glut. I suppose I should look at changing it to use SDL instead.

21 Sep 2003 (updated 22 Sep 2003 at 00:12 UTC) »

pphaneuf: Generally the preferred way to add include and lib directories to the respective search paths is simply by setting CPPFLAGS and LDFLAGS when running configure. Alternatively, there's smr_WITH_BUILD_PATH in the Autoconf Macro Archive, for those intent on adding Weird and Useless Options to their configure scripts.

Some would assert that the --with option is more user-friendly than requiring users to explicitly set CPPFLAGS and LDFLAGS to add weird directories to the search paths. These people are misguided. In general, using the argument to a --with option to add to CPPFLAGS and LDFLAGS adds redundancy—and thus unnecessary complexity—to the interface to your configure script. Importantly, since plenty of packages don't add redundant --with options, educating users on the use of CPPFLAGS and LDFLAGS provides them with knowledge they can reuse when configuring other packages.

The only good reason to provide a --with option for the purpose of adding directories to the search paths of the preprocessor and the linker is to deal with socially retarded packages that don't follow the conventional pattern of installing themselves into include, lib, bin, etc. subdirectories below some prefix. Such packages inevitably require special handling.

OpenVRML

Not a lot of time lately. Some weeks ago I began the large task of changing our naming convention from thisOne to this_one in order to be consistent with the C++ standard library and much other modern C++ code that's being produced these days. I'm also taking the opportunity to drastically reduce warningspew from Doxygen by adding doc-comments in the many, many places they are missing. I might make a release by the end of the month.

GNU Libtool

It has been a longstanding goal of mine to get OpenVRML's autotools build working with cl (the Microsoft Visual C++ compiler) under Cygwin. The obstacle to this has been GNU Libtool, which is pretty seriously busted for cl. Now, fixing libtool would be helpful for my day job, too; which has provided sufficient impetus for me to start looking seriously at what needs to be fixed. As I was warned, it is not a small task. And I don't have copious time to spend on it. But as far as I know, no one else is seriously working on this. I think I'll get it done sooner or later.

SpiderMonkey

Regardless of what might be said of the quality of the language itself, JavaScript has at least the benefit of being very widely known. (Though just how well it tends to be known is less clear to me.) But embedding SpiderMonkey, the mozilla.org JavaScript runtime, requires navigating a morass of subtleties and under-documented aspects of the API, the language, and often both. Or maybe it's just me. I have at times wanted to contribute to alleviating the documentation problem; and I still do, really; but it seems like the more I learn, the less competent I feel to do so.

43 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!