Older blog entries for robertc (starting at number 61)

Just landed a sweet feature for bzr: dotted decimal revision numbers. There is a sample log (warning its 2Mb) where you can see this in all its glory. A sneak preview is here:

------------------------------------------------------------
revno: 1986
committer: Canonical.com Patch Queue
Manager<pqm@pqm.ubuntu.com>
branch nick: +trunk
timestamp: Wed 2006-09-06 00:33:01 +0100
message:
  (robertc) Add TestCase.applyDeprecated, a common-case
helper for testing deprecated functions.
    ------------------------------------------------------------
    revno: 1982.3.3
    merged:
robertc@robertcollins.net-20060905231840-bd95f673d0205a81
    committer: Robert Collins <robertc@robertcollins.net>
    branch nick: applyDeprecated
    timestamp: Wed 2006-09-06 09:18:40 +1000
    message:
      Change raise AssertionError to self.fail in the new
applyDeprecated test support method.
    ------------------------------------------------------------
    revno: 1982.3.2
    merged:
robertc@robertcollins.net-20060905230133-2c68611e38fd7922
    committer: Robert Collins <robertc@robertcollins.net>
    branch nick: applyDeprecated
    timestamp: Wed 2006-09-06 09:01:33 +1000
    message:
      New TestCase helper applyDeprecated. This allows you
to call a callable
      which is deprecated without it spewing to the screen,
just by supplying
      the deprecation format string issued for it. (Robert
Collins)
------------------------------------------------------------
revno: 1985
committer: Canonical.com Patch Queue
Manager<pqm@pqm.ubuntu.com>
branch nick: +trunk
timestamp: Tue 2006-09-05 23:13:00 +0100
message:
  (robertc) Add symbol_versioning.deprecation_string, a
helper for establishing what a deprecation warning for a
symbol, version-format pair will look like.

This is really nice for users, because it lets them address revisions in a somewhat more predictable manner than the UUID each revision has. This feature is in the mainline now, look for bzr 0.12 to be able to use it - or grab bzr.dev now!

It make be a small thing, but barriers to entry are .. barriers to entry.

Erlang has a make-life file built into the system. If you see something like 'Emakefile', you might be tempted to google 'emake'.

Dont.

Instead, run 'erl -make'.

And this is my point : that should be made much more obvious. Simply saying in the README for an app that uses this, 'build with erl -make' would remove all the mystery.

Man, paper selection is awesomely hard... but we've done it!

My second release as bzr release manager is over - 0.11 is released. John A Meinel will be doing the 0.12 release - and it looks to be a cracker!

I've just released bzr 0.11rc2 which unbreaks the test suite for windows and fixes our commit performance regression! The 0.12 release will be managed by John Arbash Meinel, giving me some more cycles to focus on local performance. Yay!

Had a great time at Shane & Kates housewarming last night... learnt a bit about north-german humour, and spent some hours with conrad on the status of open source:

We have an incredible amount of choice these days - 5 years ago C or C++ was the only default choice for high performance software. Now the boundary has shifted - a lot of high performance software can be written in highly productive languages, and there is robust open source Java support allowing software that needs more performance to be written with dropping down to the metal with C and C++. So C and C++ still have a place, but its becoming less and less the default, and more the special case.

Even when C and C++ is chosen, it seems very rare these days that a new low level library is released without at least one of python/perl/ruby language bindings.

So what does this mean? For most problems that one would like to write a program to automate, you can write it in a high level language and get acceptable performance on any computer bought in the last 3-4 years.

And thats awesome.

Very very cool: Unit testing Athena widgets. Athena is an AJAX toolkit for twisted/Nevow.

Should Mock Objects be considered harmful? As an optimisation for test suites they are convenient, but they mean you are not testing against the something which can be verified to behave as the concrete interface is meant to, which can lead to Interface Skew.

On Friday night at slug I did a 15 minute segment for the Linux Australia round-up entitled 'Why we should Test First'. The slides from the talk are online. The audio from LA-Update is also available. The nacent flamefest at the end of the talk turned into a list thread too.

So, I now have cppunit support for subunit - the patch cppunit-subunit-1.10.2.patch adds a TestProgressListener subclass of SubunitTestProgressListener.

So subunit is now able to integrate into one seamless whole test suites from python, C, C++ and shell using the primary xUnit implementation for those languages. Woo!