1995: Forsøk i kjærlighet

I hadn’t kept up with the 1995 project in a while, so I pounced on Essays in Love: A Novel by Alain de Botton yesterday.

It’s a somewhat unusual novel.  As it says on the cover, it’s sort of an essay collection, and it’s sort of a novel.  So very avantey.  But not really.

It’s a love story, but the protagonist tends to overthink things.  It’s quite amusing.

But I just couldn’t get past this bit in the opening section.

Our hero is calculating the chance that he and The Love Of His Life were to sit in neighbouring seats on the plain from Paris, given that a) only this woman is TLOHS and b) they both were to take planes from Paris to London that day.  Fine.

But the numbers are somewhat odd.  And it doesn’t help that the Norwegian translator is mixing up decimal commas and decimal points, either. 

The chance of sitting next to each other, given that they take the same plane, is said to be either one in “162,245” or “162,(245)” (whatever that’s supposed to mean), which doesn’t seem all that unlikely to be correct.  (There are 192 seats on the plane.)

But then we get to the bit where there are six planes, so we should multiply the chance by 36?  And we should end up with a change of one in “5 840.81”? 

What? 

And what’s up with all the decimals, anyway?  Grr!  Pretend precision is Pet Peeve Number 241.456!

So while reading half the book, half my brain was kinda going through the maths while the other half was reading the book.  And I really don’t have half my brain to spare.  I can’t spare even a tenth.

Finally I went to An Online Retailer and looked at the English version of the book:

There all the numbers are totally different!  AAARGH!

But they look more sensible there, at least.

Did the Norwegian translator just throw down some random numbers on the page, or did de Botton fix this in later printings?  Could someone check an early (1993) copy of this book in English?
  
With that out of the way, I could finally pay more attention to the rest of the book, which made me notice stuff like the thing above.  It’s supposed to be an illusion, but the longer arrow is 3mm longer than the short one.

I’m totally open to the idea that de Botton would do something like that on purpose just to annoy us nerds, and if so, I applaud him.

Rating: Baitalicious.

Books, Emacs, and ISBN APIs

I have the worst memory.

But even so, I pretty much manage to remember what books I’ve read.  If I’ve read Anagrams by Lorrie Moore, I remember that.

The problem is with the less (how to put it?) good books.

I read a lot of crap.  Crap that I like, but it’s crap.  Book after book of entertaining, but not really essential books.

For instance, I’m now reading No Cooperation from the Cat by Marian Babson.  It’s amusing, quite decently written and is a pleasant read.  It’s ostensibly a mystery novel, but people mainly stand around talking wittily to each other while they cuddle cats.  And then somebody’s going to die or something, I’m guessing.  The suspense!
 
She has previously written books like The Company of Cats, To Catch a Cat, The Cat Next Door and Even Yuppies Die.

I have absolutely no idea whether I’ve read those books or not, but if I haven’t, I want to.  And there’s the problem.

My books are kinda organised on the shelves, so I can pretty much find any book if I look at four separate locations where a book is likely to be.  Unless I’ve recently read it.  Then there’s no hope, because it’ll be in the “just-read” stacks.

So I thought: Perhaps I should just enter all the Marian Babson books into a database of sorts, and then just buy all the ones I haven’t read in one fell swoop.  I like fell swoops.

And then I thought that that sounded kinda boring, so perhaps it would be an idea to have a bar-code scanner, and enter the ISBNs that way.

But then I needed to look up the ISBNs via some API, so that I could see that the book is look-up-able.

Strapped-on Keypad

And then I thought that I might as well just scan all the books.  But then I needed to have a routine going where I would scan newly bought books to.

You can see where this is going.

I wrote an Emacs ISBN interface and book database thingie: Bookiez, and a bought a wireless barcode scanner, so that I don’t have to bring the books to the computer to enter them into the database.

I also set up the computer so that the data from the scanner goes directly to Emacs so that I don’t have to futz around.  I can just grab the scanner, point it at a book, and then it’s registered, without me having to start the right program or put focus into the correct window.

The Cyborg

Bookiez looks up the ISBNs via the APIs from Google Books, OpenLibrary, ISBNDB and LibraryThing.  (Phew.)  They all seem to have vaguely differing ISBN coverage, and the data quality is also…  varying.

Anyway, after scanning about a K of books, I’m really impressed with the Datalogic Gryphon D120 Barcode Scanner (aka. Datalogic Quickscan M2130).

The wireless range is fantastic (more than 20 meters), and the user interface is perfect.  When I scan something successfully, it beeps immediately, and when it transmits to the base station, it beeps, too.  So there’s never any doubt whether the scan was successful or not.  It does require you to hold it in a certain angle when scanning, but overall I think it’s a great device.  Nine thumbs up!

Not all books have ISBN barcodes, so I have to enter those by hand.  So I gaffa-taped a wireless keypad to my right thigh.  I can enter numpad stuff by touch-typing, and it makes a fashion-forward statement, as you can see.

The main annoyance when scanning is really the network latency when looking up the ISBN codes.  I’m looking at you, OpenLibrary.  But I’ve scanned half my books in a handful of hours, so it’s not too bad.

So now I can order some more Marion Babson books.  I don’t think I over-engineered this one at all.

Input Device Routing

Lots of different (USB) devices come up as HID devices in Linux.  That is, they appear to the system as if they are keybords and mice.  You plug them in, and X deals with them the normal way.

When they output stuff, X will receive the events and characters will appear in whatever program has the focus.

But what if you don’t want that?  If you have a barcode scanner, you probably want the output from that device to go to one specific program, and not to whatever has the focus.  First setting focus on the barcode program and then scanning sounds just ridonculous.

Unfortunately, it seems like this isn’t trivial to do.  Unless something has changed lately, or my bing-fu is bad, there still doesn’t seem to be a simple “point-the-output-from-this-device-to-this-program”.

So here’s a long-winded detailed howto for doing this under Debian Squeeze, but I think it should work under any Linux version.

First of all, X will read all the HID devices under /dev/input/event* only.  (The details are in
/usr/share/X11/xorg.conf.d/10-evdev.conf.)  So if you make your device show up under a different name, X won’t know about it.

Doing device name trickery is what we have udev for.

In the following example, I’m using a wireless keypad device from Ortek.

Create a file called something like /etc/udev/rules.d/95-keyboard.rules with the following content:

# Ortek RF keypad
KERNEL==”event*”, ATTRS{idVendor}==”05a4″, ATTRS{idProduct}==”3270″, MODE=”0644″, NAME=”input/ortek%n”

This tells udev that if we plug in a device that would have been called “event*”, with that vendor/id pair, then call it “input/ortek*” instead.

You find the vendor/id pair by using lsusb:

stories:~# lsusb | grep -i Ortek
Bus 001 Device 051: ID 05a4:3270 Ortek Technology, Inc.

udev will complain bitterly:

Jan 12 12:58:27 stories udevd-work[16145]: kernel-provided name ‘input/event8’ and NAME= ‘input/ortek8’ disagree, please use SYMLINK+= or change the kernel to provide the proper name

Yeah, what are you gonna do about it, udev?  Start crying?  Go ahead.

stories:~# ls -l /dev/input/ortek*
crw-r–r– 1 root root 13, 71 Jan 12 12:58 /dev/input/ortek7
crw-r–r– 1 root root 13, 72 Jan 12 12:58 /dev/input/ortek8

See?  It works.

Now we have an input device that X doesn’t know about, so we can snoop its output without the data appearing spuriously in whatever window is active.

For snooping we use evrouter.  In debug mode it will tell us what the events we get are:

stories:~# /home/larsi/bin/evrouter-64 -d /dev/input/ortek*
device  0: /dev/input/ortek7:   RF USB Device
device  1: /dev/input/ortek8:   RF USB Device
”  RF USB Device” “/dev/input/ortek7” none key/55 “fill this in!”
”  RF USB Device” “/dev/input/ortek7” none key/98 “fill this in!”
”  RF USB Device” “/dev/input/ortek7” none key/28 “fill this in!”

So we need to create an evrouter.rc file that maps the events to whatever we want to have happen.

This is the file that maps all the keypad keys on the Ortek device:

“.*” “/dev/input/ortek.*” none key/15 “Shell/getchar TAB”
“.*” “/dev/input/ortek.*” none key/98 “Shell/getchar /”
“.*” “/dev/input/ortek.*” none key/55 “Shell/getchar *”
“.*” “/dev/input/ortek.*” none key/14 “Shell/getchar BACK”

“.*” “/dev/input/ortek.*” none key/71 “Shell/getchar 7”
“.*” “/dev/input/ortek.*” none key/72 “Shell/getchar 8”
“.*” “/dev/input/ortek.*” none key/73 “Shell/getchar 9”
“.*” “/dev/input/ortek.*” none key/74 “Shell/getchar -“

“.*” “/dev/input/ortek.*” none key/75 “Shell/getchar 4”
“.*” “/dev/input/ortek.*” none key/76 “Shell/getchar 5”
“.*” “/dev/input/ortek.*” none key/77 “Shell/getchar 6”
“.*” “/dev/input/ortek.*” none key/78 “Shell/getchar +”

“.*” “/dev/input/ortek.*” none key/79 “Shell/getchar 1”
“.*” “/dev/input/ortek.*” none key/80 “Shell/getchar 2”
“.*” “/dev/input/ortek.*” none key/81 “Shell/getchar 3”
“.*” “/dev/input/ortek.*” none key/28 “Shell/getchar ENTER”

“.*” “/dev/input/ortek.*” none key/82 “Shell/getchar 0”
“.*” “/dev/input/ortek.*” none key/83 “Shell/getchar .”

You can, of course, do anything with these events.  For this particular use case, though, I want to collect a single line, and then act upon it when I hit the ENTER key.  So I’ve written a tiny program called getchar that collects keys, and then acts upon the string when it gets ENTER.

So start evrouter:

evrouter -c ~/.evrouter-keypad.rc /dev/input/ortek*

And there you are.  Couldn’t be…  er…  perhaps it could be simpler.

Perhaps evrouter should be extended to allow storing longer strings, and then executing stuff based on the string contents and stuff.  That’s for another day, I guess.

Or perhaps someone should just put support for stuff like this into … something.  X?  Or the window manager(s)?  Or both?  Anyway, that would be nicer.

Has anybody made something like that?

Slightly More Useful Fluttering

Some weeks back I wondered whether I could use Youtube as a screen saver.  It turned out that I could.

That wasn’t, strictly speaking, very useful, but now I had a small USB monitor sitting in the hall, so I might as well make it display something practical in addition to the music videos.

Hence: flit.

Currently it checks what temperature it’s outside my bedroom window and displays that at the top right there.  (Yes!  It’s that warm here in Oslo now!)

And then it downloads the weather forecast from Yr.no, picks out the precipitation data for the next 24 hours, and plots that as a line at the bottom.

Somewhat cryptic, but that’s part of the fun.

Technologies used: LaTeX to render the temperature data, gnuplot to render the precipitation line, and qiv to display the image with a transparent background on top of the mplayer window.  As one does.