Below are the five most recent posts in my weblog. You can also see a chronological list of all posts, dating back to 1999.

### Saturday 16 February

I'm a fan of the concept of Literate Programming (I explored it a little in my Undergraduate Dissertation a long time ago) which can be briefly (if inadequately) summarised as follows: the normal convention for computer code is by default the text within a source file is considered to be code; comments (or, human-oriented documentation) are exceptional and must be demarked in some way (such as via a special symbol). Literate Programming (amongst other things) inverts this. By default, the text in a source file is treated as comments and ignored by the compiler, code must be specially delimited.

Haskell has built-in support for this scheme: by naming your source code files .lhs, you can make use of one of two conventions for demarking source code: either prefix each source code line with a chevron (called Bird-style, after Richard Bird), or wrap code sections in a pair of delimiters \begin{code} and \end{code} (TeX-style, because it facilitates embedding Haskell into a TeX-formatted document).

For various convoluted reasons I wanted to embed Haskell into an AsciiDoc-formatted document and I couldn't use Bird-style literate Haskell, which would be my preference. The AsciiDoc delimiter for a section of code is a line of dash symbols, which can be interleaved with the TeX-style delimiters:

------------
\begin{code}
next a = if a == maxBound then minBound else succ a
\end{code}
------------


Unfortunately the Tex-style delimiters show up in the output once the AsciiDoc is processed. Luckily, we can swap the order of the AsciiDoc and Literate-Haskell delimiters, because the AsciiDoc ones are treated as a source-code comment by Haskell and ignored. This moves the visible TeX-style delimiters out of the code block, which is a minor improvement:

\begin{code}
------------
next a = if a == maxBound then minBound else succ a
------------
\end{code}


We can disguise the delimiters outside of the code block further by defining an empty AsciiDoc macro called "code". Macros are marked up with surrounding braces, leaving just stray \begin and \end tokens in the text. Towards the top of the AsciiDoc file, in the pre-amble:

= Document title
Document author
:code:


This could probably be further improved by some AsciiDoc markup to change the style of the text outside of the code block immediately prior to the \begin token (perhaps make the font 0pt or the text colour the same as the background colour) but this is legible enough for me, for now.

The resulting file can be fed to an AsciiDoc processor (like asciidoctor, or intepreted by GitHub's built-in AsciiDoc formatter) and to a Haskell compiler. Unfortunately GitHub insists on a .adoc extension to interpret the file as AsciiDoc; GHC insists on a .lhs extension to interpret it as Literate Haskell (who said extensions were semantically meaningless these days…). So I commit the file as .adoc for GitHub's benefit and maintain a local symlink with a .lhs extension for my own.

Finally, I am not interested in including some of the Haskell code in my document that I need to include in the file in order for it to work as Haskell source. This can be achieved by changing from the code delimiter to AsciiDoc comment delimeters on the outside:

////////////
\begin{code}
utilityFunction = "necessary but not interesting for the document"
\end{code}
////////////


You can see an example of a combined AsciiDoc-Haskell file here (which is otherwise a work in progress):

Tags:

## My first FOSDEM

### Wednesday 13 February

FOSDEM 2019 was my first FOSDEM. My work reason to attend was to meet many of my new team-mates from the Red Hat OpenJDK team, as well as people from the wider OpenJDK community, and learn a bit about what people are up to. I spent most of the first day entirely in the Free Java room, which was consistently over-full. On Monday I attended an OpenJDK Committer's meeting hosted by Oracle (despite not — yet — being an OpenJDK source contributor… soon!)

A sides from work and Java, I thought this would be a great opportunity to catch up with various friends from the Debian community. I didn't do quite as well as I hoped! By coincidence, I sat on a train next to Ben Hutchings On Friday, I tried to meet up with Steve McIntyre and others (I spotted at least Neil Williams and half a dozen others) for dinner, but alas the restaurant had (literally) nothing on the menu for vegetarians, so I waved and said hello for a mere 5 minutes before moving on.

On Saturday I bumped into Thomas Goirand (who sports a fantastic Debian Swirl umbrella) with whom I was not yet acquainted. I'm fairly sure I saw Mark Brown from across a room but didn't manage to say hello. I also managed a brief hello with Nattie Hutchings who was volunteering at one of the FOSDEM booths. I missed all the talks given by Debian people, including Karen Sandler, Molly De Blanc, irl, Steinar, Samuel Thibault.

Sunday was a little more successful: I did manage to shake Enrico's hand briefly in the queue for tea, and chat with Paul Sladen for all of 5 minutes. I think I bumped into Karen after FOSDEM in the street near my hotel whilst our respective groups searched for somewhere to eat dinner, but I didn't introduce myself. Finally I met Matthias Klose on Monday.

Quite apart from Debian people, I also failed to meet some Red Hat colleagues and fellow PhD students from Newcastle University who were in attendance, as well as several people from other social networks to which I'd hoped to say hello.

FOSDEM is a gigantic, unique conference, and there are definitely some more successful strategies for getting the most out of it. If I were to go again, I'd be more relaxed about seeing the talks I wanted to in real-time (although I didn't have unrealistic expectations about that for this one); I'd collect more freebie stickers (not for me, but for my daughter!); and I'd try much harder to pre-arrange social get-togethers with friends from various F/OSS communities for the "corridor track" as well as dinners and such around the edges. Things that worked: my tea flask was very handy, and using a lightweight messenger bag instead of my normal backpack made getting in and out of places much easier; things that didn't: I expected it to be much colder than it turned out to be, and wore my warmest jumper, which meant I was hot a lot of the time and had to stuff it (+bulky winter gloves and hat) into aformentioned messenger bag; bringing my own stash of tea bags and a large chocolate tear-and-share brioche for the hotel; in general I over-packed, although that wasn't a problem for the conference itself, just travelling to/from Brussels. I did manage to use the hotel swimming pool once, but it was generally a trade-off between swim or sleep for another 30 minutes.

I've written nothing at all about the talks themselves, yet, perhaps I'll do so in another post.

## glitched Amiga video

### Saturday 02 February

This is the fifth part in a series of blog posts. The previous post was Amiga/Gotek boot test.

Glitchy component-video out

As I was planning out my next Gotek-floppy-adaptor experiment, disaster struck: the video out from my Amiga had become terribly distorted, in a delightfully Rob Sheridan fashion, sufficiently so that it was impossible to operate the machine.

Reading around, the most likely explanation seemed to be a blown capacitor. These devices are nearly 30 years old, and blown capacitors are a common problem. If it were in the Amiga, then the advice is to replace all the capacitors on the mainboard. This is something that can be done by an amateur enthusiast with some soldering skills. I'm too much of a beginner with soldering to attempt something like this. I was recommended a company in Aberystwyth called Mutant Caterpillar who do a full recap and repair service for £60 which seems very reasonable.

Philips CRT

Luckily, the blown capacitor (if that's what it was) wasn't in the Amiga, but in the A520 video adaptor. I dug my old Philips CRT monitor out of the loft and connected it directly to the Amiga and the picture was perfect. I had been hoping to avoid fetching it down, as I don't have enough space on my desk to leave it in situ, and instead must lug it over whenever I've found a spare minute to play with the Amiga. But it's probably not worth repairing the A520 (or sourcing a replacement) and the upshot is the picture via the RGB out is much clearer.

As I write this, I'm in a hotel room recovering after my first day at FOSDEM 2019, my first FOSDEM conference. There was a Retrocomputing devroom this year that looked really interesting but I was fully booked into the Java room all day today. (And I don't see mention of Amigas in any of the abstracts)

Tags:

## multi-coloured Fedoras

### Thursday 17 January

My blog post about my Red Hat shell prompt proved very popular, although some people tried my instructions and couldn't get it to work, so here's some further information.

The unicode code-point I am using is "🎩", U+1F3A9 TOP HAT. My Terminal font of choice is Noto Mono Regular which does not contain a glyph for that code-point. Therefore the font system my Terminal uses (pango) is pulling it from another font. In my case, it's using OverPass Mono, an open source font created for Red Hat branding. The TOP HAT glyph in OverPass Mono is a Fedora. This is a nice little easter egg included by the font authors. (There's at least one other easter egg in the font, by the way!)

It's pure chance that my font system chose OverPass Mono to pull that glyph.

The simplest way to get this to work is (probably) to download and install "OverPass Mono" and set your Terminal font to it for all characters. Alternatively you may need to look at configuring Pango (or whatever font system you are using).

If your Terminal and font system support multicolour emojis, then the above alone may not work for you. Some of my colleagues got a nasty surprise when upgrading their systems: their red hats turned blue. It's possible to add a trailing Unicode modifying code-point that instructs the font system to not render the prior glyph using multicolour emojis. This reportedly fixes it:

hat="🎩"
combiner="$(perl -CS -e 'print "\N{VARIATION SELECTOR-15}"')" # ^ alternatively, "$(printf '\xef\xb8\x8e')"
export PS1="$\e[31m$${hat}${combiner}$\e[0m$"


(Thanks ilmari for the perl trick)

Tags:

## Amiga/Gotek boot test

### Monday 14 January

This is the fourth part in a series of blog posts. The previous post was part 3: preliminaries.

A500 mainboard

In 2015 Game 2.0, a Retro Gaming exhibition visited the Centre for Life in Newcastle. On display were a range of vintage home computers and consoles, rigged up so you could play them. There was a huge range of machines, including some Arcade units and various (relatively) modern VR systems that were drawing big crowds but something else caught my attention: a modest little Amiga A500, running the classic puzzle game, "Lemmings".

A couple of weeks ago I managed to disassemble my Amiga and remove the broken floppy disk drive. The machine was pretty clean under the hood, considering its age. I fed new, longer power and data ribbon cables out of the floppy slot in the case (in order to attach the Gotek Floppy Emulator externally) and re-assembled it.

Success! Lemmings!

I then iterated a bit with setting up disk images and configuring the firmware on the Gotek. It was supplied with FlashFloppy, a versatile and open source firmware that can operate in a number of different modes and read disk images in a variety of formats. I had some Amiga images in "IPF" format, others in "ADF" and also some packages with "RP9" suffixes. After a bit of reading around, I realised the "IPF" ones weren't going to work, the "RP9" ones were basically ZIP archives of other disk images and metadata, and the "ADF" format was supported.

Amiga & peripherals on my desk

For my first boot test of the Gotek adaptor, the disk image really had to be Lemmings. Success! Now that I knew the hardware worked, I spent some time re-arranging my desk at home, to try and squeeze the Amiga, its peripherals and the small LCD monitor alongside the equipment I use for my daily work. It was a struggle but they just about fit.

The next step was to be planning out and testing a workflow for writing to virtual floppies via the Gotek. Unfortunately, before I could get as far as performing the first write test, my hardware developed a problem…

Tags:

Older posts are available on the all posts page.