Well this makes no sense:
Me: "Hi, your letter said I needed to arrange a visit with you to check the gas safety of my flat."
Them: "That's right, what's your details?"
Me: "There's no gas supply in the building, but apparently you have to come see that in person yourselves."
Them: "Yes, that's true. .... OK, we'll send you a letter with the appointment details."
Me: "Uh, I can't just do any time, it needs to be arranged."
Them: "That's OK - if you can't make the appointment on the letter, then you can ring us up after you receive it and tell us."
Well this makes no sense:
Somewhat unpleasantly, I'm a vague acquaintance of a couple of holocaust deniers (in the sense that I've been in the same place as them once or twice). Really weird people:
- They always bring it up at parties. Seriously, what? If I were a terrorism expert, I'd tend to keep off the subject at parties, since people might see it as a little sensitive. Even if I was just a huge fan of He-Man or something I'd probably only mention it if we were talking about 1980s kids' TV. Why do they always start talking about it?
- It's never a slight correction. It's always some ridiculous figure they claim, like "zero" or "thousands". Surely if the figures are really dubious, they're not going to be 6 million off? It's equivalent to claiming that nobody lives in Libya.
- They appear to believe in either the most expertly executed hoax of all time, and their only apparent response to this is to moan about it to people they don't know. How does that make any sense?
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
- despite claims to the contrary, even 1.3.7 does not correctly alter labels when you modify the
audio. That means there's no way to Truncate Silence without re-doing all your labels!
- you can't split into tracks (or, apparently, make selections) based on labels added by the silence finder, so you can't remove inter-track silences that way either
- the labels dialog has a fun bug where it removes all your labels that don't have names (as
none of them do by default). This gets frustrating fast.
- there's no way to start a recording on the current track - I have to have a new one, it seems. This was fine until I discovered that Mix and Render completely screwed up the merging of all the tracks.
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.