Home Renovations XIV: The Doorening

Last night, the sliding door (in front of my shelves of shortboxes of comics) popped off when I was sliding it open. I had noticed that it had gotten a bit “sticky” lately, but hadn’t really investigated.

And… this turned out to be the problem: Those “rails” at the bottom slid out. Like WTF.

And it turns out that they’re only fastened with double sided tape! Like… wat? I mean, there’s not supposed to be much pressure in an outwards direction, so you could see how that would work OK…

But look — this (aluminium, I guess) metal profile thing is so “hollowed out” that it only has these three narrow strips that make contact with the floor, anyway, so there isn’t that much surface to glue?

I was wondering whether I could drill a hole in the middle and fasten it with a screw, but:

Even the middle bit isn’t solid! Geez. So if I wanted to fasten it to the floor with a screw, I would have to drill either to the left and right of it, and then either use washers to fill in the gap (but that would be kinda precise; pretty fiddly) or cut a 2mm thick strip of wood and glue it in there, but…

In any case, the aluminium isn’t thick enough to do countersinking, so the screw head would stick up.

Which may not be a problem — there’s a couple millimetres worth of clearance.

But… eh…

I guess there was a reason the carpenter glued the thing in the first place — it’s designed to be glued, and there doesn’t really seem to be much of an option to do anything else.

But if we’re gluing, I can at least use better double-sided tape than was there originally.

So much red tape.

Don’t adjust your screen — your screen isn’t broken. That’s just a lot of tape.

There! Glued! It seems pretty solid to me — I can’t make it budge a nanometre.

All done!

But while messing around with this thing, I think I discovered what the actual problem here is. The carpenter who built this shelf for me put one of the feet of the shelf on top of nothing — the beam is about 4cm to the left (where the screw is), but where the foot is there’s just air.

So it’s sinking… slooowly. I mean, it’s lasted for about fifteen years, so that’s not bad, but I think I have to get somebody in to redo this thing, because it’s probably just going to get worse.

But not this week. Or month. It’s time to concentrate on procrastinating.

(What’s that I’m hearing? Is that a resounding crash? Nah.)

Keanu all together again

I bought this 3D printed Sad Keanu like a decade ago? But the other day he fell off the shelf and broke into a number of pieces. So I was going to throw it away, but then I saw that I still actually had all the various bits, and the breaks look clean — i.e., no actual splintering into dust anywhere.

So I applied some glue and…

He’s alive again! Yet still sad!

OK, back on the shelf you go — but this time around, with some sticky stuff to make you sit a bit more securely.

Emacs, movies and SQLite

Hey, it’s the… *counts on fingers*… 22nd anniversary of me using Emacs to watch TV and movies!

And in the start, it was a snappy, focused package that just listed directory contents and let me play the files… but then it grew to take care of resuming where I left off, and fixing the frame rate of the TV to fit the video file, and lately it’s also automatically choosing the correct subtitles and audio track.

This means that it’s now calling mediainfo before playing the file to get all that data. And since it’s accessing the files over nfs, and mediainfo apparently has to load the entire file (or large parts) to cough up that data, things have gotten slower:

Look at that! It’s horrible! I have to wait, er, two seconds before I can watch Saturday Night Live?! How can anybody live like this?

Now, sensible video player interfaces compute all this stuff when they incorporate a file. But I didn’t want to do that, because just having some directories of random files that I can move around without doing any synchronisation is just so convenient.

And it worked without that delay until I added the auto-subtitle selection thing.

But… one thing I’ve had to precompute anyway are the thumbnails, and I’ve just plopped them into the directories, which is icky:

Having the video player mangle the source directories like this is not ideal at all. I mean, I don’t look at the mess myself — the Emacs interface hides all this junk — but I know it’s there! *gasp*

So… taking all that into account (the new slowness and this yuckiness) I thought it was time, after 22 years, to bite the bullet and do things the traditional way. I.e., prescan the files and stash everything in an SQLite database. (And besides, the “use no database” thing fell apart very quickly — the file for keeping track of progress was a database file anyway, just very primitive.)

Tada!

Look how fast? Ish. Fastish. mpv still has to load the start of the file over nfs, so it’s not instantaneous, but it’s a fraction of a second, so that’s OK.

And look how pretty:

Putting everything into an SQLite database also means that I can keep track of more data. Previously I only kept track of whether I’d seen something, and how far I’d watched something (so it could resume automatically), but now I can also keep track of how many seconds I’ve watched something, for instance. (Skipping to the ten minute point and then abandoning isn’t the same as watching for ten minutes and then abandoning.)

And I think I still can keep my “just move files around” (to a “rainy day” directory, for instance) workflow — I store file hashes, so even if they move around, they’re recognised when they’re re-encountered.

But now for the real test — my kitchen computer. I use it to watch Star Trek while cooking, and it mounts the /tv/ directory over sshfs over wifi! (The TV computer mounts the directory over nfs over Ethernet, so it has much less latency.) Will it be able to access the SQLite database in a reasonable amount of time?

Yowza! That’s speedy! The only system, which ran mediainfo on the file before starting to play, was very, very slow — it took multiple seconds. The new thing is, like, a million percent faster! That’s bigly faster!

And with all the data stashed in a more convenient way, it’s easier to whip up stuff like this, which answers “when did I last watch DS9, and for how long a time?” (The answer is — “now”, and “not very”.)

The code is on Microsoft Github, for those that are curious.

Spellchecking Total Eclipse with an AI

I’ve spent a day test-driving that Emacs minor mode for spellchecking using an LLM that I wrote the other day. I went through all the posts on the Total Eclipse blog (all 260 of them) to see whether the thing works or not.

And, yes, it works now, but it took some tweaking. Well, I rewrote the mode.

Twice.

My original approach was to give the LLM the entire text, and then ask it to return it to me verbatim, but with changed words tagged up specially. This worked 90% of the time, but it would randomly decide to do something else… and I was never totally sure that it actually returned the entire text. That approach was a bit too nerve-racking.

But Sacha Chua has done something along similar lines, and her approach is to ask the LLM to return just the changed parts:

That sounds like a much more responsible approach, so I redid my package to do pretty much the same… but no matter how I phrased things in the prompt, I couldn’t get the LLM to follow my instructions more than 50% of the time, really.

The hard thing to make it (I’m using Sonnet 5) understand is that it should return a regexp that identifies the fragment uniquely, and that the word to be replaced should be inside a \(…\) group. But:

Some regexps would have zero grouping operators, and some would have several. And sometimes it would wrap the JSON in Markdown:

And worst of all, I could not get it to understand even once that it shouldn’t do this:

I.e., it seems like the LLM did the “regexps” by slapping a (…) around the term to be replaced, and then it put two backslashes before every parenthesis in the string. This is wrong.

So I redid the thing once again, but without regexps. Instead I asked it to return some JSON of the offending phrase (with enough context to uniquely identify it), and what it wants to replace it with:

And then I compute myself the actual difference between the phrases for markup purposes.

After this change, the LLM hasn’t screwed up the format once.

I guess what this really drives home for me is that the apparent enormous strides LLMs have taken the last six months for programming are mostly an illusion: You can now ask an LLM to whip you up, say, a Python script, and it chugs away at it, and then gives you a Python script that’s syntactically correct and mostly does what you asked.

But this isn’t because the LLMs now can generate correct syntax flawlessly. No, this is because the LLMs now have a sandbox they test-run all scripts before handing them over. So they discover that what they’ve generated is junk, and then iterate rapidly over it until it works.

But when I’m using the API here, it can’t check whether the regexps I asked it to generate are valid. It spits out something that’s close, but if it had its normal interactive harness, it would have tested the regexps and seen that they were invalid, and then fixed them.

So… it’s the LLM tooling that tricks us into believing that LLMs are pretty smart at computer stuff now. They aren’t, really.

Anyway, the Total Eclipse blog should now be 100% without typos! Woohoo! And since I’ve eyeballed every change, hopefully the LLM hasn’t changed too many instances of “important” to “load-bearing” without me noticing.

(One amusing thing I’ve noticed is that you can run the same article through the LLM several times, accepting the edits each time. As it finds fewer and fewer real things to complain about, it gets more and more nitpicky. But eventually it gives up and says “nothing to be changed”.)