Code review(ed)

Today I had the rare, but pleasant experience of getting my code
reviewed by a colleague. We were talking about some aspects of Python at
lunch, and he volunteered to take a look at my code, so I said yes
please. Later in the afternoon he sat down with me, and we went through
almost 300 lines of my code and I learnt a couple of things. For one,
I'm not doing too badly (i.e. not too un-Pythonically), something I was
not at all sure about. For another, I was doing something quite ugly
with iterating over lists of tuples, where my reviewer pointed out I
could use a dictionary and get a much more elegant, readable &
maintainable result.

The point is that I learned stuff, and my code is now better.

Unfortunately, in this environment (an academic research institute) code
writing is still predominantly seen as a solo activity conducted as a
means to an end which does not need to be discussed. Only the results
need to be discussed.

The quality of code I see being written by doctoral students varies
greatly. Some is excellent, some less so. And I think it's a shame that
learning opportunities are being lost because hardly anyone reads
anybody else's code. It's not only the weaker coders who could gain in
terms of productivity during their PhDs, the better ones might happen to
find bugs sooner too, on the basis that two heads are better than one.
And in both cases, doing a bit of code review should stand them in good
stead for their future careers, in which they are very likely to
continue to write code, whether in academia or in industry.

IRQF_SAMPLE_RANDOM on its way out

According to Linux Weekly News article 507115
http://lwn.net/Articles/507115/ , the flag IRQF_SAMPLE_RANDOM, which
drivers use to tell the kernel whether to use interrupts from their
device(s) as a source of entropy for the entropy pool that backs the
kernel's RNG or not, is liable to become redundant from 3.6 onwards.
"After this change, adding randomness from interrupts ... is done by
default for all interrupts". This means that at that point I can remove
the flag in my out-of-line pciaer driver
(http://www.ini.uzh.ch/~amw/pciaer/index.html) along with the handling
of a module parameter (no_sample_random) which I provided to allow
paranoiacs to turn the use of IRQF_SAMPLE_RANDOM off. This might have
been important if very regular address-event senders and/or receivers
were in use (e.g. during test) but high quality random-number generation
were still important.

I've queued this change up in my TODO file.

Bibtex entry creation script used in anger

I've been using my Python script in anger to help convert two chapters
worth of references from plain text references to Bibtex entries.

It's a bit rough and ready and assumes quite a bit about the layout of
the references in the plain-text text, but it did a kind of 90% job
for me.

Maybe it could be helpful for others too, but you shouldn't expect too
much of it.

Of course it could be improved a lot, but at some point, faced by the
law of diminishing returns, I decided to stop improving it when it was
doing 90% OK, and the rest (the difficult cases) I've edited by hand.

Python script

I'm writing a Python script to generate Bibtex entries from more or less
free-form citations, trying to guess which parts are the author names,
article title, page numbers etc.

This is the first time I've written any Python for over a year, and I'm
a bit rusty. I keep on forgetting the colons at the end of if's and
function definitions.

Draft book chapters handed over

Yesterday and today I handed over the drafts of two chapters of a
forthcoming book to our lead editor, Shih-Chii Liu.