The Bug Report

So I get a bug report. It is on GNU/Linux, of course, because that is the only ecosystem that sends bug reports.

So first I boot up my work box (Computer #1, Windows 10) which is the one that has the sweet monitor and try to VPN to the Server box (Computer #2, GNU/Linux Fedora Server, amd64).  But, of course, at one point I'd stripped all the non-console-mode functionality off of the server, so VPN is a fail.  I could have done the fix easily via ssh and emacs-nox, but, I figure it will only take a minute to get a graphical environment up and running.

There's a GNU Linux VM running on VirtualBox on the work box, but, I get distracted from the actual problem when I can't figure out how to get VirtualBox to create a large screen.  Totally not a problem, but, I get obsessed with this minutiae and can't let it go. I waste time tweaking the virtual graphics card settings with no effect.

So then I boot up the old linux box (Computer #3, GNU/Linux Fedora Workstation). It is 64 bit, but, it is running the i686 distro for reasons lost to history.  And then I remember that when I upgraded my wireless router, it stopped connecting via USB-connected Wifi. There are wpa_supplicant errors. Don't know why.  Spent a couple of hours trying to make it work.

Thus, I drag the old linux box to the room with the router so I can plug it in directly.  The only table is covered in padlocks, bottles of sunscreen, beads, jars of coins, and multiple Rubik's Cubes.  I clear a space.

The power cable to the spare monitor has gone missing.  It is a tiny HP w17e, but, still higher resolution than what I was getting from VirtualBox.   I search for 20 minutes. Eventually steal the power cable from work box.  My mostly ruined back complains when I shimmy under the desk to untangle it from the cable octopus.

I boot up old linux box.  Huh, it is only 100BaseT.  I dutifully do a "dnf upgrade". 1404 packages to update.  That takes another half hour.

And thus, I've used up the four hours of Saturday morning time which is the only time I have to devote to personal hacking.  Sorry bug reporter.  I'm too stupid to work on your request, and the computer gods hate me.  Better luck next week.

Pip-Boy like terminal application in Guile, part 4: the terminal

This is the fourth in a series of articles where I try to recreate some Pip Boy like displays in GNU Guile and ncurses.

A Pip Boy is a fictional computer in the Fallout 4 computer games.  GNU Guile is an implementation of the Scheme language.  Ncurses is a library for creating text user interfaces on terminals like the Linux terminal, Xterm, or the Gnome Terminal.

One of the iconic experiences in Fallout 4 is using the in-game computers, which are bulky, green screen monochrome terminals not unlike a DEC VT100.  Actually a closer match is the Televideo TVI-912.  Generally they are used in two ways: displaying a text block with some selectable links, or playing a hacking minigame.  Today we'll look at the first.

The basic user experience is this:

• When activated, the terminal will begin an animation where it is add adding text to the screen one glyph at a time at about ~75 characters per second.  There is a tick sound associated with each glyph appearing on the screen.
• Clicking the mouse or pressing enter will interrupt this drawing animation and will make all the text appear on the screen.  There is a tick sound associated with this.
• Once drawing is complete, any text surrounded by square brackets become a link.
• The first link is highlighted.
• Mousing over a link or using the arrow keys will move between links.  There is a tick sound associated with moving between links.
• Clicking on a link or pressing enter will select the highlighted link and end the interaction.  There is a sound associated with selection.

So, here there is user interaction, audio cues, time-based rendering.  It actually is a fair bit of functionality, and it also is not too friendly to the paradigm provided by the ncurses toolkit.

So I put together three different code units

• a main event loop
• glue code to allow interaction with Pulseaudio
• and, the tui-terminal widget itself

As a side note, Guile has had a complete set of bindings to the multimedia enving GStreamer, which I wanted to use, but, it appears to be in need of some maintenance.  I did look at it so see if I could patch it up, but, the binding is related to the Glib binding, and I didn't want to take the time to understand all that right now.  Pulseaudio is much lower level, but, also much simpler.  I had code lying around from some old game engine attempt.

If you've coded in QT or GTK, you know that a central function of a GUI toolkit main loop is to allow each widget to send out notifications and to have other widgets be able to subscribe and react to these notifications.  In QT, these are "signals" and "slots".  In GTK they are "signals" and "signal handlers".
To keep things somewhat simple, the primitive main loop works like this...

• There are one or more event handlers. An event handler may have an associated widget.
• The main loop checks for an event in the queue: either a keypress, a mouse event, or a signal sent out by one of the widgets. If it finds an event, it sends it to all the event handlers.  Every handler receives every event: there is no attempt to be precise.
• If no event is ready, the main loop sends an "idle" event to all the signal handlers, does a single step in Pulseaudio's main loop, and then sleeps for a few microseconds.

This is familiar territory.  There's nothing new under the sun.

I had to choose between letting Pulseaudio run its own event loop in its own thread, or to merge Pulseaudio's event look in to my main event loop.  I chose the latter.

Put together, it all looks like this.  For the life of me, I cannot seem to record audio on my screengrab.  I blame Wayland.

The code, in its current form, is here.  It is not ready for use.