Heartbeat

Date: October 15th, 2010 by Author: Daniel Elstner

Just a quick note to reassure everyone that I’m still alive and kicking. I’ve been pretty busy with university work and and general life stuff. Well, I finally managed to complete one semester of formal university education, and it turns out I have passed all six subjects nicely.

I had to put GNOME work in general and gtkmm work in particular on hold for the time being. This is unlikely to change anytime soon, but I’m sure things are going on well without my indefatigable pedantry. ;)

Bjarne Stroupstrup on C++0x

Date: March 18th, 2010 by Author: Daniel Elstner

I’m just back from Aalto University School of Science and Technology in Espoo, Finland, where I attended Bjarne Stroustrup‘s roadshow talk on C++0x. In the talk, Stroustrup provided a very nice overview of the features in the C++ standard and how they fit into the evolution of the C++ programming language.

Bjarne Stroustrup made the impression of a down-to-earth guy with a very healthy attitude about C++ features and their development. I was excited to learn that the C++0x draft standard had just been declared final the week before. That means the content of the standard is de-facto finished now, and it will be formalized as an ISO standard in about one year. There sure are quite a number of nice goodies in C++0x, I can’t wait to get my hands dirty on code using it.

For the C++ groupies among us, I took photographs of all presentation slides and of course also of Bjarne Stroustrup himself.

Why I hate Qt

Date: February 25th, 2010 by Author: Daniel Elstner

Although I’m a GNOME and gtkmm guy, my paid work involves Qt. It’s no secret that I have a very strong antipathy towards the Qt mania to assimilate everything into their framework, the culture of their community, and their nonchalant abuse of the C++ programming language. Often, people suggest that I’m exaggerating the faults of Qt, and that there are much worse alternatives out there. Fair enough.

But today I happened onto another one of those little inanities which so often add up to a huge stinking pile. I decided to share this particular example, as I think it may help people to understand why I’m feeling so strongly about Qt.

A while ago, I filed Qt bug #5732, together with a patch to fix the problem. In addition to the fix for the central problem reported in the bug, I also provided a second patch to correct another problem I stumbled upon while I worked on the actual bug fix. The bug was acknowledged by a Qt developer and the code got fixed. They decided to fix it their own way instead of applying my patch, which is fair enough. I may not have agreed with the way it was implemented, but the problem I reported was fixed.

Today, I again looked at the Qt OpenGL code, and happened to stumble upon the OpenGL extension checks. Apparently, the extension checking had now finally been factored out into a separate class, with a more efficient implementation to avoid the numerous temporary memory allocations of the string splitting method that was used before. Of course I was curious and had a look at the code which implements the string parsing.

Here is how it looks like:

// This class can be used to match GL extensions without doing any mallocs. The
// class assumes that the GL extension string ends with a space character,
// which it should do on all conformant platforms. Create the object and pass
// in a pointer to the extension string, then call match() on each extension
// that should be matched. The match() function takes the extension name
// *without* the terminating space character as input.
 
class QGLExtensionMatcher
{
public:
    QGLExtensionMatcher(const char *str)
        : gl_extensions(str), gl_extensions_length(qstrlen(str))
    {}
 
    bool match(const char *str) {
        int str_length = qstrlen(str);
        const char *extensions = gl_extensions;
        int extensions_length = gl_extensions_length;
 
        while (1) {
            // the total length that needs to be matched is the str_length +
            // the space character that terminates the extension name
            if (extensions_length < str_length + 1)
                return false;
            if (qstrncmp(extensions, str, str_length) == 0 && extensions[str_length] == ' ')
                return true;
 
            int split_pos = 0;
            while (split_pos < extensions_length && extensions[split_pos] != ' ')
                ++split_pos;
            ++split_pos; // added for the terminating space character
            extensions += split_pos;
            extensions_length -= split_pos;
        }
        return false;
    }
 
private:
    const char *gl_extensions;
    int gl_extensions_length;
};

According to the log message the piece of code just shown went through internal code review. For comparison, here is the equivalent piece of code from my original patch, which was not considered good enough to be applied:

static bool parse_extensions_string(const char* extensions, const char* name)
{
  const size_t name_length = (name) ? strlen(name) : 0;
 
  Q_ASSERT(name_length > 0);
 
  if (extensions) {
    const char* pos = extensions;
 
    while (const char *const space = strchr(pos, ' ')) {
      const size_t length = space - pos;
 
      if (length == name_length && memcmp(pos, name, length) == 0)
        return true;
 
      pos = space + 1;
    }
    return (strcmp(pos, name) == 0);
  }
  return false;
}

So, instead of just taking the code handed to them on a silver platter, the Qt developers decided to roll their own version. Which I wouldn’t even consider a problem if it weren’t for the fact that the code that went in is longer, less readable, and generally ugly. It’s also broken, because there is not a single word in the OpenGL specification about glGetString() always returning a list terminated by a space character, contrary to what the code comment claims about “all conformant platforms”.

What the fuck is this shit?

Simon Singh Wins Leave to Appeal!

Date: October 14th, 2009 by Author: Daniel Elstner

Rejoice! Simon Singh wins leave to appeal in BCA libel case!

And now it begins!

Using config.site to set default options

Date: September 21st, 2009 by Author: Daniel Elstner

Just a quick note about a little-used feature of GNU Autoconf: site defaults.

Until recently, I used to have a long list of assignments to module_autogenargs['...'] in my ~/.jhbuildrc file to set up default configure options for various modules. This became unwieldy and there was always one module I forgot.

Autoconf comes to the rescue with its support for site defaults. For illustration, here is my ${prefix}/etc/config.site file:

# Autoconf site defaults
test -n "$enable_silent_rules" || enable_silent_rules=yes
test -n "$enable_static" || enable_static=no
test -n "$enable_warnings" || enable_warnings=fatal

The effect is as if I had passed --enable-silent-rules --disable-static --enable-warnings=fatal to every module’s ./autogen.sh, except that I don’t get any annoying warnings if a module doesn’t actually support a particular option. The test conditionals ensure that command-line arguments have precedence over the default values in the config.site file.

Read the manual for the gory details, if you want to. Otherwise, enjoy!

« Previous Entries