One of the more interesting areas in software development, to me at least, is language bindings. Being able to interface with a library written in one language in another language is kind of satisfying, as it allows me to develop without having to reinvent the wheel. There are two specific projects that I use and work on so that I can enhance the software that I develop: GObject Introspection (G-I) and python-spidermonkey.
GObject Introspection
As a quick overview, the goal of this project is to give C libraries the tools
to provide enough metadata about their API so that bindings can be written with
minimal effort. Given the time and effort that I have put into maintaining the
Awn bindings, it is not very surprising that I would be willing to help out
getting this framework working for Awn. My ultimate goal is to eliminate the
bindings/python folder in the Awn source tree. It is basically a mixture of
a Scheme definition file plus a very bizarrely formatted "override" file for
custom definitions, all integrated into autotools to produce a C library that is
ready to be dynamically loaded into python via import. To meet this goal, I
am contributing to the PyBank project, which is a prototype Python module
that interfaces with the GObject Introspection library to read compiled library
metadata files (called "typelibs") on the fly so that classes, functions, etc.
can be loaded and called at runtime. In addition to myself, a Google Summer of
Code student and a Sugar Labs developer are also working on the module, with
Johan Dahlin overseeing it all. So far, I've contributed a unit test suite,
ported from the gjs project (JavaScript bindings for GLib-based libraries based
on the Spidermonkey VM) and working type bindings for various simple types
(e.g., int64 and float).
I have also put some coding effort toward G-I integration in Vala. Vala supports G-I by both reading GIR files (the XML serialization of G-I metadata) to produce VAPI files (short for Vala API files), and writing GIR files when producing a library written in Vala (e.g., libdesktop-agnostic). I have contributed mostly what amounts to workarounds in the GIR reading code, with regards to Vala/G-I behavioral inconsistencies. Didier 'Ptitjes' has done much, much more solid work than I have on both fronts, which I greatly appreciate.
python-spidermonkey
This project, as the README states, lets you [execute] arbitrary JavaScript
code from Python[, and allows] you to reference arbitrary Python objects and
functions in the JavaScript VM
. As I've stated in an earlier blog post, I
use this in my custom website build system to both validate and pack my
JavaScript code, via JSLint and Packer, respectively. Since I published
that post almost two years ago, that project was revived twice - once by a
Mozilla employee (and co-founder of Humanized, which is quite awesome) named
Atul Varma, and the latest incarnation is on github. Since it is based on the
original implementation in C, and not the Python-based ctypes version, the Base2
recursion problem does not exist, and so I have happily written modules and
scripts which wrap the two JavaScript utilities. Recently, I have made them
available in a public project on Launchpad called python-jsutils. I haven't
really announced it until now because it currently relies on a change I made to
python-spidermonkey which allows one to iterate over a JavaScript array, instead
of having to write "unpythonic" code like for x in range(0, len(foo)): #....
While it is in my fork, it has not been merged to the "official" repository.
Posts
