Posted on

Paint the Silence/2

Continuing the ongoing saga…

Using the --silence hackery from Jacob Berkman I found a way to finally STFU at least libtool. In your configure.ac add:

changequote(,)dnl
LIBTOOL="\\$(QUIET_LT)${LIBTOOL}"
changequote([,])dnl

Add a Makefile.decls file to the root of your project, containing:

QUIET_LT = @echo '    ' LIBTOOL $@;

And include it in every Makefile.am:

include $(top_srcdir)/Makefile.decls

This will silence all libtool invocations; you can make this all conditional, obviously: just sorround the QUIET_* declarations with if VARIABLE...endif and define VARIABLE using AM_CONDITIONAL in your configure template.

Now, I’ll just have to find a way to make gcc shut up1, and so the saga will end with a third chapter.

  1. no, you cannot redefine CC, as it will be invoked by libtool as well [↩]
Posted on

Rag And Bone

Usually, when writing bindings for a C library in a high level language, there’s a sweet spot where you have to leave the relative safety of an API similar to the library you are wrapping and the idiomatic correctness dictated by the language itself.

For instance, in the PyClutter bindings a typical clutter.Behaviour constructor is lifted directly from the equivalend function call:

  behaviour = clutter.BehaviourDepth(alpha, -100, 100)

  behaviour = clutter_behaviour_depth_new (alpha, -100, 100);

The ClutterAlpha parameter, though, can ben NULL, so a “keep the API similar to the C equivalent” approach would be:

  behaviour = clutter.BehaviourDepth(None, -100, 100)

  behaviour = clutter_behaviour_depth_new (NULL, -100, 100);

This is, though, different from the “pythonic” approach; as Python has the syntactic sugar to support arguments with default values, the place for those parameters would be at the end of the function call:

  behaviour = clutter.BehaviourDepth(-100, 100)

Correctness issue aside, let’s add the fact that a pythonic approach allows the poor maintainer (yours truly) to drop a lot of hand-written code.

Unfortunately, though, the pythonic approach breaks the API1; more unfortunately, it breaks the API without giving a useful error message: the PyGObject bindings will raise a not very useful

  "TypeError: could not convert parameter 'depth_start' of type 'gint'"

exception when encountering the wrong value type for the argument2.

The question then is: should the idiomatic correctness sway in favour of the language or the underlying library?

Here the blog post ends. I’d like to have an answer for the question, but I’m still undecided; if anyone has some insight, especially Python developers, I’d appreciate a comment

  1. This is not a huge issue as it might seem: the underlying C library has already done that for us [↩]
  2. The error message should be a more useful “could not convert value of type X, and parameter Y requires a value of type Z”, which would require a bit of tinkering in the bindings themselves and it wouldn’t be useful anyway because only the new versions would pick that change up [↩]
Posted on

Kingdom of Spain

Clutter: Today I released the first developers snapshot of Clutter 0.6 – Clutter 0.5.0. The full announcement is on the Clutter blog, and since it’s very long, I won’t copy and paste it here. You can grab 0.5.0 here; as usual, this is a unstable snapshot, and it’s meant to be used to play with the new API, start binding it and find the inevitable bugs that might have creeped in – and help us fixing them as well. :-)

Last week I also went through the huge list of changes, additions and removals in the public API; the result is a collection of seven emails (1, 2, 3, 4, 5, 6 and 7) I sent on the clutter-list – complete of mistakes which I can only attribute to the amount of food, wine and beer I had during the Xmas break.

I’m incredibly proud of how much Clutter grew since the 0.4 release we did after GUADEC; the amount of bug fixes alone makes it worth to check it out – and the new features list is impressive. A lot happened, and a lot more will happen in the near future; some things are already here – but will be announced in due time.

As always, kudos to everyone that has helped by filing bugs and patches; started writing bindings; and last, but not least, contributed documentation.