talideon.com

Klein bottle for rent: enquire within

Entries for October 2007

October 1, 2007 at 11:15AM Pet Peeves: People who try to increment void pointers.

Here’s a pet peeve of mine that I’ve stumbled across in other people’s code before. Type this into a file called test.cc or test.c, and compile it:

#include <stdio.h>

int main(void) {
    int foo[] = { 1, 2, 3, 4, 5 };
    void* pv;
    pv = foo;
    pv++;
    printf("pv is %p and points to %d\n", pv, *pv);
    return 0;
}

Now, compile it. Here’s what you get:

talisra% gcc test.cc
test.cc: In function `int main()':
test.cc:7: error: ISO C++ forbids incrementing a pointer of type `void*'
test.cc:8: error: `void*' is not a pointer-to-object type

Notice the bit that reads “ISO C++ forbids incrementing a pointer of type ‘void*’”? Or, as C:

talisra% gcc test.c
test.c: In function `main':
test.c:8: warning: dereferencing `void \*' pointer
test.c:8: error: invalid use of void expression

Of course, C doesn’t specify how wide a void is, many compilers treat a void* just like a char* for historical reasons, so pv++ above will increment the pointer by a byte. However, this is really just a compatibility hack because historically char* was used where void* would be used these days, and so is nothing that ought to be depended upon. If you need convincing, as yourself this: what is the result of sizeof(void)? As before, though logically and physically, because void can’t store anything, void has no width. However, in C for compatibility with ancient implementations, it has a width of 1 because it has to behave like char. In C++, it behaves sanely and treats void as having no valid width, refusing to compile it.

Are we clear? So don’t do it.

October 2, 2007 at 2:01PM SimpleXML treats attribute namespaces incorrectly.

Joy! I just submitted this bug to PHP’s bugtracker:

Description:
------------
According to "Namespaces in XML 1.0 (Second Edition)", SS6.2:

"A default namespace declaration applies to all unprefixed element names
within its scope. Default namespace declarations do not apply directly
to attribute names; the interpretation of unprefixed attributes is
determined by the element on which they appear."

However, SimpleXML appears to treat unprefixed attributes as in the
default namespace. This is incorrect.

Reproduce code:
---------------
<?php
$doc1 = <<<LEFIN
<foo:bar xmlns:foo="urn:1">
    <foo:baz fred="barney"/>
</foo:bar>
LEFIN;

$doc2 = <<<LEFIN
<foo:bar xmlns:foo="urn:1">
    <foo:baz foo:fred="barney"/>
</foo:bar>
LEFIN;

$kids1 = simplexml_load_string($doc1)->children('urn:1');
$kids2 = simplexml_load_string($doc2)->children('urn:1');

print_r($kids1);
print_r($kids2);

Expected result:
----------------
SimpleXMLElement Object
(
    [baz] => SimpleXMLElement Object
        (
            [@attributes] => Array
                (
                    [fred] => barney
                )
        )
)
SimpleXMLElement Object
(
    [baz] => SimpleXMLElement Object
        (
            [@attributes] => Array
                (
                    [fred] => barney
                )
        )
)

Actual result:
--------------
SimpleXMLElement Object
(
    [baz] => SimpleXMLElement Object
        (
        )
)
SimpleXMLElement Object
(
    [baz] => SimpleXMLElement Object
        (
            [@attributes] => Array
                (
                    [fred] => barney
                )
        )
)

This is a pretty dumb bug, especially within the context of this one. Interestingly, I found the same bug in a certain large domain registry’s external API...

The specification I’m referencing, and the specific section can be found here.

October 5, 2007 at 3:02PM I’m finally happy with my terminal colours

It’s been seven years since I’ve had a set of terminal colours that I’ve liked, but I think I’ve finally worked out the colour scheme I used to have back then. Here’s what I’m using now:

      Text: #A4CC28 (Lime)
Background: #283328 (Sea green)

   Black 1: #000000
   Black 2: #555555
     Red 1: #AA0000 (Slightly desaturated crimson)
     Red 2: #FF5555 (Erm, pink...)
   Green 1: #008000
   Green 2: #62C462
  Yellow 1: #BF6000 (Orange brown)
  Yellow 2: #FFBF00 (Orange yellow)
    Blue 1: #005FBF (Dark sky blue)
    Blue 2: #9BAEC2 (Light sky blue, with a dash of grey)
 Magenta 1: #AA00AA
 Magenta 2: #FF55FF
    Cyan 1: #008080
    Cyan 2: #66CCCC
   White 1: #808080
   White 2: #FFFFFF

Here’s what it looks like. The screen shot is of Vim with the koehler colour scheme running in a terminal displaying some of the templating code in AFK:

[What my term looks like]

Update: Aha! Here’s what I was trying to get close to! Here’s a Vim colour scheme that might be useful.

Update (Mar 18th): Urgh! Pasted the wrong value in for Green 1! Fixed.

October 8, 2007 at 10:17AM Moving from SVK to Bazaar-NG

I exported my projects from SVK’s hidden SVN repository on Saturday using tailor. I was expecting it to be simple, but it was anything but! Mind you, this is probably my fault.

I just wanted to get it working, so I read the documentation accompanying tailor to figure out what I was supposed to do. However, none of it seemed to work, not least of which was that it was saying Bazaar wasn’t a supported VCS! After a bit of investigating, I came to the conclusion that between the time that tailor-0.9.29 was released and bazaar-ng-0.91 was released, there were some minor, but important changes within bzrlib. The one that bit me was that in vcpx/repository/bzr.py, it was importing compare_trees from bzrlib.deltas (line 25), but the name of that particular function has changed to _compare_trees, as I discoved with a quick dir(bzrlib.deltas). It doesn’t seem to be used in the end, so I think that import line can probably be deleted.

After reinstalling it with my patch, I tried generating the configuration file again, but to no avail. Maybe I’m just dumb---not entirely unlikely---but the configuration options don’t seem to make any sense. Some end up being ignored, and others don’t seem to do exactly what you’d expect. I gave up and started bludgeoning the config file directly. To export AFK from my old SVK repository, here’s what I used:

[DEFAULT]
verbose = True

[project]
target = bzr:target
start-revision = INITIAL
root-directory = /usr/home/keith/branches/dev/personal/afk
state-file = tailor.state
source = svn:source
subdir = .

[bzr:target]
repository = .

[svn:source]
module = /afk/trunk
repository = file:///usr/home/keith/.svk/local

The key bits here are root-directory, which specifies where the repository you’re importing into is, module, which specifies the path in the SVK/SVN repository of the project, and the second repository line, which specifies the location of the subversion repository itself. I dropped this file in ~/branches/dev/personal, and then, in that directory, did the following:

talisra% mkdir afk
talisra% cd afk
talisra% bzr init
talisra% bzr whoami "Keith Gaughan <myemailaddress@example.com>"
talisra% cd ~-
talisra% tailor --configfile afk.tailor

Tailor should start moving the revisions from the old repository to the new one. After it’s finished, it leaves some crud behind, so do the following:

talisra% cd ~-
talisra% rm project.log tailor.state*
talisra% find . -name .svn -exec rm -rf {} +

That’ll clear out the .svn directories it created in the process of checking out the individual versions, and the logs it leaves behind.

Bingo! You’ve now turned a Subversion/SVK project into a BZR one! Now, I just have to contact the person maintaining tailor in the ports and the original author and get them to fix that problem...

I’ll see if I can find a less hacky way to do this, but for now this works.

Update: Submitted the bug report. Tailor’s ‘new ticket’ appears to be disabled, even if you’ve created an account. It appears you have to be explicitly given permission to post up new bugs. Hrumph. I emailed the maintainer the report directly.

Update (later that same day): Fixed! That was fast! Gotta love open source.

October 25, 2007 at 10:24AM A RELAX NG compact schema for RSD

I was feeling a bit bored last night and decided to write a schema for RSD in RELAX NG compact syntax. RSD is about five years old at this point, and nobody ever seems to have got around to writing one, so this might help somebody who wanted to make sure they’re producing valid RSD files:

default namespace = "http://archipelago.phrasewise.com/rsd"

# To make it explicit that these element do *not* contain any encoded HTML
# markup.
plainText = text

start = element rsd {
  attribute version { "1.0" },
  element service {
    element engineName { plainText },
    element engineLink { xsd:anyURI },
    element homePageLink { xsd:anyURI },
    element apis {
      element api {
        attribute name { text },
        attribute preferred { "true" | "false" },
        attribute apiLink { xsd:anyURI },
        attribute blogID { text },
        element settings {
          element docs { xsd:anyURI }?,
          element notes { plainText }?,
          element setting {
            attribute name { text },
            text
          }*
        }?
      }+
    }
  }
}

I’m not using xsd:boolean for the preferred attribute because it accepts 0 or false for false and 1 or true for true, whereas the spec states that it should only accept false and true.

Where this differs from the RSD spec, the spec is canonical, not this schema. However, this schema adds some rigour that the spec lacks, so where the spec is ambiguous, you can assume the schema above is correct.

October 26, 2007 at 9:47AM Consider a CEO...

...who’s running a company that’s facing a harsh drop in earnings. Would you give them a 10% raise?

I didn’t think so.

But Bertie Ahern, the Taoiseach of a country with a population smaller than many major cities, is giving himself such a raise [via]. Makes you sick, doesn’t it?

Now go compare it against what other world leaders are getting, and consider that all of these have much harder jobs than our very own “Pratai” Ahern.