Dear Everyone
Feb 21, 2009If you have a blog, and you ask questions in blog entries, have some way to leave comments, won’t you?
If you have a blog, and you ask questions in blog entries, have some way to leave comments, won’t you?
You might think that recording and then splitting it into separate audio
files based on silences
between each track would be easy to do - sadly not.
Aside from crashing a few times and failing to recover properly, I’ve
been hit by these
enormous frustrations:
Seriously, how do people actually use this thing?
After dealing with more code that gets it wrong I was reminded of the
numerous reasons why openpty() is such a broken API.
The prototype of
this “convenience” function is this:
int openpty(int *amaster, int *aslave, char *name, struct termios *termp, struct winsize *winp);
Now, sin number one should be obvious: the interface isn’t
const-correct. You’re passing in the winp
values, but there’s no
indication of that. Worse, you’re doing the same with termp
. Why
worse? Well, think about how you use this API. Typically, you want to
create the master/slave pair of the pseudo-terminal, then change the
terminal settings of the slave. (Let’s leave the master out of this for
now - but the settings are not always symmetrical.)
But where do we get the terminal settings from? We don’t have an open
slave to base them on yet! So you find
code
doing a cfmakeraw()
on stack junk and passing that in, because the API
almost insists you do the wrong thing.
Indeed, doing it right, namely with a
tcgetattr()/cfmakeraw()/tcsetattr()
stanza, you’d expect term
to be
an out parameter, that you could then use - precisely opposite to how it
actually works, and what const correctness suggests to the user. You can
see some
other
amusing
examples
of how people worked around the API though.
I’m sure you will have spotted by now that the name
parameter is
outgoing, but has no len
. It’s therefore impossible to use without the
risk of buffer overflow.
This API is not going to score well on the Rusty
scale.
What’s worst of all about openpty()
, though, is that it’s
non-standard, so almost every piece of code out there keeps its own
private copy of this broken, pointless interface. Yay!
I was bored so played around with Review Board a little more, including installing it myself.
Things seem to have got easier to install, at least to some degree. You
can use easy_install,
though at least
for CentOS 5.2, you’ll need to install a newer version of setuptools
first. It’s also far from automated, missing
out basic dependencies like pysqlite2, patchutils, and even patch
itself. Discovering these can be, and in my case was, rather tedious
work.
After that it’s pretty easy to install, for the sqlite version anyway.
The documentation isn’t exactly clear on
what permissions changes you need to make: you need to chown all of db/
to the apache user as well for anything to work. Expect to set up a
virtual host for the installation, like I did above.
Don’t forget to enable logging in the admin interface whilst you’re messing around.
Sadly, the Mercurial support seems some way behind. For example, it doesn’t pick up changeset comments.
The diff parser (how is this not in a library by now?) can’t handle git diffs, and the failure mode is horrible (basically, silent failure, with no debugging messages). This is because hg git diffs don’t contain the revisions being diffed, so Review Board can’t pull the files from the repo. Undoubtedly a Mercurial misfeature, but it does make Review Board near useless for my purposes unfortunately.
It can handle ssh repositories (which is all opensolaris.org provides), but there’s a horrible work around needed: you have to set up a correct known_hosts file in the apache user’s home directory. Yuck.
As for the main interface, it’s generally pretty slick. I can imagine it getting cumbersome quickly with large code reviews though. Compare and contrast Review Board’s diff viewer with webrev. The latter to me at least, is much more scalable, even though the actual diff mechanism is less smart. In particular, I can review each file with webrev in a separate tab, whereas Review Board insists on one big (very big!) screen. I’d still give my right arm for a webrev-based Review Board :)
Another thing I’d like to see is more integration with the repository, so I can click on a file and it will take me off to the repo browser for looking through history.
I’ve only just read the XML-RPC spec. I knew it was simple, but I didn’t know it was stupid. Seriously, no parameter names? Only 32-bit integers? And no “NULL”? WTF?