koldfront

Documentation of Haskell libraries #haskell #lantern

While I was improving Lantern I wanted to use the Haskell library Database.PostgreSQL.Simple.Notification to monitor update search index events.

I was a little confused when I read the documentation of getNotification and saw that it didn't take what channel to listen on as an argument - having just read the PostgreSQL documentation of NOTIFY channel + LISTEN channel that was what I was expecting.

After some digging I found a test for the library and from that saw that the way to use D.P.S.Notification is to execute one or more LISTEN channel before calling getNotification.

In hindsight it is obvious (you want to be able to listen to multiple channels in the same getNotification call), but to me, as a relative beginner in Haskell and using postgresql-simple, and never having tried LISTEN/NOTIFY before, it wasn't.

I have written to the maintainer and suggested that the documentation of D.P.S.Notification mention this.

One thing I miss in the documentation of many Haskell libraries is a couple of lines giving an example of how to use them - luckily I found the solution in a test this time.

Using LISTEN/NOTIFY in PostgreSQL #haskell #lantern #postgresql

The search functionality of my little NNTP engine for blogging, Lantern, uses PostgreSQL's full text search.

I have just made a VIEW that makes a tsvector for each article, and searching is then done by SELECT'ing from that view.

Recently using the view directly became a little too slow to my liking (above 1 second), so I discussed with myself whether to include the tsvector as a field on the article table with a trigger to update it on INSERT/UPDATE or whether it would be better to make the view MATERIALIZED.

Although the way the tsvector is constructed hasn't changed much recently, I felt that going the materialized view way was easier - it doesn't take that long to update it all, and then I don't have to think about old fields that are out of date.

So I added a trigger that would refresh the view on INSERT/UPDATE/DELETE on the table. That works nicely, but it does give me an annoying pause when posting a new article, which is long enough for my brain to go "Is something wrong?" before it completes.

I could move the refreshing to a cron job that would refresh the view once in a while, but since posting is quite irregular that feels like a waste.

Instead I looked into the LISTEN/NOTIFY functionality in PostgreSQL - and changed the trigger from refreshing the materialized view to executing a NOTIFY on a channel, and then I created a little program that runs continiously listening on the channel and refreshing the view when it receives an event.

The only aber dabei is that if the little program isn't running when a NOTIFY is sent, the event is lost. But I'll just start it before everything else, and it should be fine.

Upgrading to OpenWrt 21.02.0 #hardware #wifi

A week ago ago the OpenWrt project released a major new version, 21.02.0.

I used the firmware selector to download a "SYSUPGRADE" file, but when I tried uploading it on my Netgear R6350, running OpenWrt 19.07.06, I got an error.

Searching for that error revealed that I had to install from scratch instead of upgrading, due to a change in how networking is configured. So I decided to postpone updating until I had plenty of time.

Today I had plenty of time. And spent it.

Instead of thinking, I uploaded the second package I downloaded when I read the announcement and just overrode all the warnings. Bad move - the access point didn't come back online after that.

I had chosen the wrong package - I should have taken the "KERNEL (SQUASHFS)", but instead I went for the "KERNEL (INITRAMFS)". I'm not sure how I made that mistake, but, alas, I did.

After trying to trigger failsafe mode and performing a factory reset when that didn't work, without any luck, I took the access point apart and located the place to solder on pins for serial port access.

Luckily I found a nice slide deck showing exactly how to figure out which pin is which with a multi-meter, and I dug out an old serial-usb dongle, some wires and my basic soldering iron.

However, soldering wires onto pcb's is not something I have attempted before (I've used the soldering iron to make a cable for my Amiga 500 to make the keyboard "external" in the 1990's, and then I've cobbled together a cable for controlling my amplifier, and that's my complete soldering experience). So before going further down that route, I looked into one more debricking strategy, using the nmrpflash tool, which conveniently is readily available in Debian.

I didn't have high hopes, because I saw no evidence of the access point jumping into the network with tcpdump, but I thought I might as well try it.

In the first attempt I saw something transferred!

It ended with an error, so I tried a couple of more times, which also ended with errors, but something worked, and the access point started blinking, and then came up with OpenWrt 21.02.0 on 192.168.1.1!

After configuring it and testing that it worked, I put it back together and hung it where it belongs. I even got opkg update working, so I could install the crelay-package that I use to automatically control the power to my printer.

It could have taken 5 minutes, if I had taken the warnings seriously and double checked the file I was uploading. Instead I spent most of the afternoon recovering from my mistake. But it's working as it should now, so all's well that ends well, I guess.