Weekly report 20-12

Weekly report 20-12


  • There is a pandemy of a virus somewhat more deadly than your usual influenza, which is a decent stress-test for many healthcare systems and even funeral homes (by some luck the Czech republic has been evading deaths so far).

  • Many shops and other public places are closed and people are forced to cover their mouths and noses outside, the intention being to slow down the spreading.

  • Cash payments are discouraged and often disallowed. There are hints of payment cards being used to track people down, thus far anonymised. Of course, mobile phones are a much better locator. Or even cars.

The worst prospect for me is that the precautions will likely continue for at least a month. It gets annoying. On the other hand, I can delay resolving some issues, such as learning for driver’s license exams (truck exams are considerably harder), and focus on introvertial activities instead.

I still wish I had e.g. bought a rifle sooner, to have something to salivate over at home, instead of postponing it for made-up reasons. Rifles are lovely things. At the same time, I’m glad I didn’t postpone other things, such as getting a firearms pass in the first place.

Tick tock. Things won’t be there waiting for you forever. Much less people. (Add a dark undertone.)


At work I added support to format/style dates as such to our simple OOXML export library. Which was a success, even if this is a world of pain:

  • Again, the import filter in LibreOffice doesn’t adhere to the specification, and cannot decode an ISO 8601 time value alone.

  • Excel provided a very vague error message when it didn’t like my styles.xml file, while the official SDK didn’t report anything at all.

  • Google Docs just flipped me off. ‘The file is invalid, yo.’ I’ve given up on it, as it’s not a problem worth my time. Loading it in another application and saving it from there is a more than acceptable workaround.

All in all, the ECMA specification looks pretty neat, until you start to deal with unspecified details. And broken implementations.

IRC client

I’ve decided to port my IRC client from C to Go, while throwing out GNU Readline for good. I’m not seeing myself using the resulting TUI much, though, as there are some issues with my target ‘platform’ I’m not sure I want to address. What I’m actually looking forward to is a better maintainable codebase, allowing me to add a server mode, and to follow up with web and X11 frontends--just like weechat.

This is made easier for me by having ported my IRC daemon already, so I e.g. know what to do about my event-looped code. It’s still going to be a multi-week project, and if I follow through, it will be a decent ego boost.

It’s not like I came up with the idea last week. I dug it out after contemplating doing something about the primitive client in Serenity OS, since I possess domain knowledge and have been longing for a nice GUI client for a while. I realised that my vision wasn’t quite compatible with that of the project, and that if my application was to end up among the litter that are ‘ports’, it might just as well be a lightweight C++ client for the backend in Go.


I have finally found out that it’s /sys/power/image_size that causes my NUC to pause itself while resuming from hibernation. The default of 2/5 of RAM is just too low, so I’ve pushed it up a bit. I suspend to disk often enough while travelling to really enjoy the improvement.

Once relieved of having to maintain a sleep regime roughly compatible with that of others, I decided to shake it up. I usually get into a pattern of requiring too much sleep every single day and always getting up either tired, or just generally useless. I’ve noticed that a combination of modafinil and putting off sleep changes this. My sleep becomes shallower and I wake up alert. At least that’s how I perceive it.