+++*

Symbolic Forest

A homage to loading screens.

Blog : Posts from June 2022

In the countryside (part one)

Scenes from a rural idyll, or possibly not

It’s something of a cliché—it’s been something of a cliché for centuries, almost—that the English countryside is a haven of natural beauty, a green and pleasant land (to use Blake’s phrase) which is somehow a reservoir of timeless, genuine Englishness.

It’s not true, of course. It’s far from being a green desert, but it’s a strange, deserted place, peaceful due to absence, peaceful because strangers are forever unwelcome. Or am I just seeing it through the lens of folk horror? Nevertheless, whenever I go out for a long country walk, I try to avoid paths that will take me through farmyards and golf courses, because I’m always aware that I’m intruding, there, that I’m a stranger who just doesn’t fit in.

I do, though, still go out for long country walks when the weather is right. I can set out first thing on a Sunday morning and barely see another person other than relatively amiable middle-class hikers and dog-walkers who have driven out to their favourite rural circular walks to get their weekly exercise. All the people who can afford to live in the big houses are still in bed; all the farm workers are sleeping off their Saturday binge hangovers, and the countryside is mine and mine alone, has space for me to intrude in it. I watch swifts and swallows spiralling above catching insects; hares running away up the lane ahead of me; and dozens and hundreds of hedgerow butterflies. I haven’t seen deer yet; I suspect I would have to be up a lot earlier.*

A butterfly, apparently with another insect riding on it

I said the English countryside is a strange, deserted place. It’s a place for the wealthy and the very poor. The process of denudation, of removing the population, has been going on a long time; and Lincolnshire is full of the scars and landforms left behind by deserted villages, the inhabitants evicted centuries ago to turn the landscape into a series of sheep-ranches, the fleeces for export to Brugge.

The remains of Beesby

These lumps and bumps are the remains of the village of Beesby, a village which seems to have just gently faded away in the fifteenth and sixteenth centuries. At the edges of the village are its fields.

Old cultivation marks

The stripes are the result of six or seven hundred years of digging and planting the fields in the same pattern, each villager having rights to a few widely-scattered strips in the large open field, to give each villager land with a variety of soils and situations. After another four or five hundred years as pasture, the ridges they form are still clearly seen, as the sheep and cattle which have grazed here ever since never let anything grow to a height of more than a few inches. This is no hay-meadow full of flowers.

One reason sheep have been so popular on this land for such a long time, why mile after mile of it was turned over to sheep-ranching, is that the soil here is actually pretty poor, thin stuff. The chalk bedrock is only a foot or so below the surface in most places, and when you do find a ploughed field, its surface will be dappled white with lumps of chalk that have come up for air. If you take an archaeologist on your walk with you, be prepared for it to take a while, because each square foot will have a few flints that are probably natural but, you never know, might not be. Of course you might want to keep your eyes out for other things too; because we know there were Roman villages and villas in the area even if we don’t know exactly where all of them were. The land is dotted with pits, too, little quarries maybe a few hundred yards wide, maybe only tens of yards wide, most of them abandoned, some still worked. The larger ones feel as if you may have strayed onto a horror set.

Abandoned chalk pit

One thing that will grow, though, is Brassica napus, rapeseed, almost six feet tall and eye-wateringly yellow. For me, it’s been a sign of the early summer as far back as I can remember, so it’s strange to think that to people only a few years older than me it was a strange, alien plant when it first became popular with farmers here—British rapeseed production increased by a factor of 20 between 1975 and 1995. Where it almost swamps the path, it can be rough going.

Through a field of rapeseed

So much for the timeless nature of the countryside. And this, you see, this is the nice parts. I haven’t got on to the pristine, hygienic farmyards, deathly silent on a Sunday. Or the quiet churchyards hiding who knows whatever Jamesian horrors. Or the pile of wood twice my height, waiting for the sacrificial torch. This post is already getting long; think of this as the gentle, friendly, bucolic introduction, with the next act of the film containing all the scares.

* I have seen deer only just outside town, just after dawn, when I’ve been to the beach for a sunrise walk in autumn. In June, sunrise beach walks are just that bit too early for me.

Going through things one by one

Or, a coding exercise

One of my flaws is that as soon as I’m familiar with something, I assume it must be common knowledge. I love tutoring and mentoring people, but I’m bad at pitching exactly where their level might be, and in working out what they might not have come across before. Particularly, in my career, software development is one of those skills where beyond a certain base level nearly all your knowledge is picked up through osmosis and experience, rather than through formal training. Sometimes, when I’m reviewing my team’s code I come across things that surprise me a little. That’s where this post comes from, really: a few months back I spotted something in a review and realised it wouldn’t work.

This post is about C#, so apologies to anyone with no interest in coding in general or C# in particular; I’ll try to explain this at a straightforward level, so that even if you don’t know the language you can work out what’s going on. First, though, I have to explain a few basics. That’s because there’s one particular thing in C# (in .NET, in fact) that you can’t do, that people learn very on that you can’t do, and you have to find workarounds for. This post is about a very similar situation, which doesn’t work for the same reason, but that isn’t necessarily immediately obvious even to an experienced coder. In order for you to understand that, I’m going to explain the well-known case first.

Since its first version over twenty years ago, C# has had the concept of “enumerables” and “enumerators”. An enumerable is essentially something that consists of a set of items, all of the same type, that you can process or handle one-by-one. An enumerator is a thing that lets you do this. In other words, you can go to an enumerable and say “can I have an enumerator, please”, and you should get an enumerator that’s linked to your enumerable. You can then keep saying to the enumerator: “can I have the next thing from the enumerable?” until the enumerator tells you there’s none left.

This is all expressed in the methods IEnumerable<T>.GetEnumerator()* and IEnumerator<T>.MoveNext(), not to mention the IEnumerator<T>.Current property, which nobody ever actually uses. In fact, the documentation explicity recommends you don’t use them, because they have easier wrappers. For example, the foreach statement.

List<string> someWords = new List<string>() { "one", "two", "three" };
foreach (string word in someWords)
{
    Process(word);
}

Under the hood, this is equivalent** to:

List<string> someWords = new List<string>() { "one", "two", "three" };
IEnumerator<string> wordEnumerator = someWords.GetEnumerator();
while (wordEnumerator.MoveNext())
{
    string word = wordEnumerator.Current;
    Process(word);
}

The foreach statement is essentially using a hidden enumerator that the programmer doesn’t need to worry about.

The thing that developers generally learn very early on is that you can’t modify the contents of an enumerable whilst it’s being enumerated. Well, you can, but your enumerator will be rendered unusable. On your next call to the enumerator, it will throw an exception.

// This code won't work
List<string> someWords = new List<string>() { "one", "two", "three" };
foreach (string word in someWords)
{
    if (word.Contains('e'));
    {
        someWords.Remove(word);
    }
}

This makes sense, if you think about it: it’s reasonable for an enumerator to be able to expect that it’s working on solid ground, so to speak. If you try to jiggle the carpet underneath it, it falls over, because it might not know where to step next. If you want to do this using a foreach, you will need to do it some other way, such as by making a copy of the list.

List<string> someWords = new List<string>() { "one", "two", "three" };
List<string> copy = someWords.ToList();
foreach (string word in copy)
{
    if (word.Contains('e'));
    {
        someWords.Remove(word);
    }
}

So, one of my colleagues was in this situation, and came up with what seemed like a nice, clean way to handle this. They were going to use the LINQ API to both make the copy and do the filtering, in one go. LINQ is a very helpful API that gives you filtering, projection and aggregate methods on enumerables. It’s a “fluent API”, which means it’s designed for you to be able to chain calls together. In their code, they used the Where() method, which takes an enumerable and returns an enumerable containing the items from the first enumerable which matched a given condition.

// Can you see where the bug is?
List<string> someWords = new List<string>() { "one", "two", "three" };
IEnumerable<string> filteredWords = someWords.Where(w => w.Contains('e'));
foreach (string word in filteredWords)
{
    someWords.Remove(word);
}

This should work, right? We’re not iterating over the enumerable we’re modifying, we’re iterating over the new, filtered enumerable. So why does this crash with the same exception as the previous example?

The answer is that LINQ methods—strictly speaking, here, we’re using “LINQ-To-Objects”—don’t return the same type of thing as their parameter. They return an IEnunerable<T>, but they don’t guarantee exactly what implementation of IEnumerable<T> they might return. Moreover, in general, LINQ prefers “lazy evaluation”. This means that Where() doesn’t actually do the filtering when it’s called—that would be a very inefficient strategy on a large dataset, because you’d potentially be creating a second copy of the dataset in memory. Instead, it returns a wrapper object, which doesn’t actually evaulate its filter until something tries to enumerate it.

In other words, when the foreach loop iterates over filteredWords, filteredWords isn’t a list of words itself. It’s an object that, at that point, goes to its source data and thinks: “does that match? OK, pass it through.” And the next time: “does that match? No, next. Does that match? Yes, pass it through.” So the foreach loop is still, ultimately, triggering one or more enumerations of someWords each time we go around the loop, even though it doesn’t immediately appear to be used.

What’s the best way to fix this? Well, in this toy example, you really could just do this:

someWords = someWords.Where(w => !w.Contains('e')).ToList();

which gets rid of the loop completely. If you can’t do that for some reason—and I can’t remember why we couldn’t do that in the real-world code this is loosely based on—you can add a ToList() call onto the line creating filteredWords, forcing evaluation of the filter at that point. Or, you could avoid a foreach loop a different way by converting it to a for loop, which are a bit more flexible than a foreach and in this case would save memory slightly; the downside is a bit more typing and that your code becomes prone to subtle off-by-one errors if you don’t think it through thoroughly. There’s nearly always more than one way to do something like this, and they all have their own upsides and downsides.

I said at the start, I spotted the issue here straightaway just by reading the code, not by trying to run it. If I hadn’t spotted it inside somebody else’s code, I wouldn’t even have thought to write a blog post on something like this. There are always going to be people, though, who didn’t realise that the code would behave like this because they hadn’t really thought about how LINQ works; just as there are always developers who go the other way and slap a ToList() on the end of the LINQ chain because they don’t understand how LINQ works but have come across this problem before and know that ToList() fixed it. Hopefully, some of the people who read this post will now have learned something they didn’t know before; and if you didn’t, I hope at least you found it interesting.

* Note. for clarity I’m only going to use the generic interface in this post. There is also a non-generic interface, but as only the very first versions of C# didn’t support generics, we really don’t need to worry about that. If you write your own enumerable you’re still required to support the non-generic interface, but you can usually do so with one line of boilerplate: public IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();

** In recent versions of C#, at any rate. In earlier versions, the equivalence was slightly different. The change was a subtle but potentially breaking one, causing a change of behaviour in cases where the loop variable was captured by a lambda expression.

The Paper Archives (part three)

The title of this series is maybe not quite as suitable as it was

The previous post in this series is here.

Sometimes, sorting through the accumulated junk that fills my mother’s house, I come across things that I remember from my childhood. For example: alongside the stack of modern radio transceivers that my dad used to speak to random strangers over the airwaves, is the radio I remember being my Nanna’s kitchen radio, sitting on top of the fridge.

The old kitchen radio

It’s a big, clunky thing for a portable, its frame made of leather-covered plywood. I know it has valves (or tubes) inside, not transistors, because I remember my dad having to source spare valves for it and plug them in back when my Nanna still used it daily—he was the only person in the family who knew how to work out which of the valves had popped when it stopped working.

With only a vague idea how old it might be, I looked at the tuning dial to see if it would give me any clues.

The tuning dial

Clearly from before the Big BBC Renaming of the late 1960s. I’m not sure how much it can be trusted for dating, though, as Radio Athlone officially changed to Radio Éireann in the 1930s, but I was fairly sure the radio probably wasn’t quite that old. Of course, I should really have beeen looking at the bottom.

The makers' plate

And of course the internet can tell you exactly when a Murphy BU183M was first sold: 1956, a revision of the 1952 BU183, which had the same case. The rather more stylish B283 model came out the following year, so I suspect not that many of the BU183M were made.

I’m intrigued by the wide range of voltages it can run off: nowadays that sort of input voltage range is handled simply and automatically by power electronics, but in the 1950s you had to open your radio up and make sure the transformer was set correctly before you tried to plug it in, just in case you were about to blow yourself up otherwise. I suppose this is what radio shops were for, to do that for you, and potentially to hire out the large, chunky high-voltage batteries you might need if you didn’t have mains electricity. This radio is from the last years of the valve radio: low-voltage transistor sets were about to enter the marketplace and completely change how we listened to music. This beast—or the B283, which at least looks like an early transistor radio—needed a 90-volt battery to heat up the valves if you wanted to run them without mains power, not the sort of battery you can easily carry around in your handbag. The world has changed a lot in seventy years.

The shortest night

Some reflections on the solstice

There were sundogs, yesterday, as the sun was getting low on the horizon. After sunset, there were high, wispy, noctilucent clouds to be seen, and a red glow in the north-west sky which did not fade until getting on for midnight. This is, after all, the North, where midsummer sunset is dead on the North-West compass point.*

All the coverage of the Summer Solstice, at least in Britain, focus on this being the longest day of the year, with seventeen or so hours of sunlight depending on where you are.** The biggest focus of all is on this morning’s sunrise, especially at sacred spots like Stonehenge. Few discuss, though, how the longest day is also the shortest night; and after all, you can’t have the one without the other.

This has been a big year for me so far, and I’m sure it’s only going to get bigger. I’ve always been more of a dark, cold-loving person though than a hot, summer-loving person, so I’m all in favour of the winter coming back. The world turns, and we turn with it. The shortest nights are past us, and now they are growing again.

* This is true in southern England and the southernmost parts of Wales, and is a key part of the solar alignments at Stonehenge: midsummer sunrise is directly opposite midwinter sunset, and midsummer sunset and midwinter sunrise are at right-angles to them. In the English Midlands, northern England and Scotland, midsummer sunset moves further and further north around the compass.

** This wasn’t meant to be an astronomy post, but fun facts keep creeping in. This varies hugely from one end of the UK to the other, by over 90 minutes! On the south coast of England you get less than 16½ hours of day; in South Wales it’s more like 16 hours 40 minutes, in Lincolnshire or Yorkshire it’s around 17 hours and once you’re up to Inverness or further north it’s over 18 hours.

Hooked on a pattern (part two)

The crochet continues

The previous post in this series is here.

The crochet project I mentioned a couple of weeks ago has been coming along, if sometimes in fits and starts. Practicing my crochet stitches, my test piece came along quite a way, even if I did decide to pull it all down and start again because I was making my stitches far too tight, with the result that I then couldn’t stitch into them very easily on the following row, not without splitting the double-knit yarn. Before long, I had quite a substantial…um…rectangle.

A test piece

It must, I thought, be time to start on the thing itself. The first round was a little bit fiddly, but I perservered.

The first false start, and my legs

I just wasn’t happy. The shape didn’t seem right. The shape didn’t seem to match the pictures in the pattern, and I’d clearly messed up the start and stitched the second round, but only the second round, into the wrong side of the previous, so one tiny bit of the thing looked like it was inside out. So, pull it all down and start again. The second time, I got somewhat further…

That shape still isn't quite right

…and I still wasn’t happy. Because I seemed to have misread the pattern. Due, I assume, to my misunderstanding of crochet patterns. The pattern gives instructions for stitching each round, ending with “join with slip stitch”, and then a stitch count. The stitch count for each round matches up with the number of stitches produced in the main instructions for each round, minus the slip stitch at the end. Because of this, I was stitching the slip stitch into the first stitch of the round, then starting the next round by stitching into the second stitch. As a result, the whole thing was developing a twist, and as I started to do more asymmetrical increases and decreases the twist was becoming obvious. I begun again, and moreover, did the first round a number of times until I was quite happy with it. I begun again, treating the slip stitch as an extra stitch in addition to the stitch count for the round, and the shape started to make a little more sense.

Finally everything is lined up

All in all, then, it’s going quite well. I’m now thirty-something rounds into the main body of the thing, stuffing it as I go to help it take up the right sort of shape. It’s a bit lumpy compared to the pattern; it’s a bit larger too, because I’ve used slightly chunkier yarn and a slightly larger hook than the pattern suggested. But so far, I’m pleased.

Actually getting quite big

Whether I’m still going to be pleased when I’m making fiddly little decorative bits that then have to be stitched onto the main body, we’ll have to wait and see.

Voices through the wires

Or, hanging on the telephone

One of the tabs I’ve had open in my browser for a few weeks meaning to write about it here is this Guardian article about the steady decline of phone boxes in the UK.

It brought back memories, and it made me feel old at the same time. My first memories are from the early 1980s, when if you didn’t have a phone line and needed one installed, you went on a waiting list that was several months long. When we moved into a new-build house, on an estate with no phone boxes either, that meant several months of walking to the nearest one, on the main road at the edge of the estate, to make calls, and long, tedious waits—tedious if you’re a pre-schooler, at least—outside the box when you needed to receive one. We had the phone line fitted, the phone wired in because house phones were the property of BT, not you, back in those days; and then just a few months later, a lightning strike hit a phone pole a few hundred yards up the street, with a massive crash, scorching and burning out the newly-fitted phone line termination box (and presumably those of the neighbours too). We went back onto the waiting list, and by the time we reached the top again, the house was fitted with a socket and the phone had to be given a plug. The phone itself had survived the lightning strike, although its bell never quite worked properly again.

When I reached my teens, I became a heavy phone box user once more, partly because my father had bought a cordless phone—which was completely analogue, not at all encrypted, and therefore something that any nearby radio ham, such as my father, could tune in to and listen in on. I hoarded my silver coins and started phoning friends from the phone box on the main road again, feeding 10p and 20p coins into it every few minutes, occasionally getting turfed out by someone else who needed to make a call and thought I was hogging it. I’d do the same on camping holidays, finding the nearest phone box in whatever village or hamlet we were staying in. In fact, most campsites then had their own on-site phone box, for you to phone home to let people know you’d arrived safely—which my parents did religiously on the first evening of each holiday.

I remember the switch from fully-enclosed boxes, whose doors were so strongly sprung I could barely pull them open, to ones with gaps at the bottom of the glass on three sides; or in “deprived areas” like the Grimsby West Marsh, armoured-looking stainless steel phones on poles with no box around them at all. What I can’t remember, though, is when I last used one. I’ve had a mobile phone since the turn of the century; I can’t even remember the last time I had a voice call that wasn’t either for work, or with one of my elderly uncles. I probably stopped using phone boxes when I went to university, although I don’t really have any definite certainty on that. For me they’re a part of the landscape, I’d be sad to see them disappear, but I likely wouldn’t notice at all. When I lived in Bristol, the phone box on the corner of the next street had a sticker on its door saying it was due to be removed for about a year, before one day it suddenly wasn’t there any more. That must mean nobody had used it for, what, maybe a couple of years at least by that point.

Do we still need phone boxes? Yes, we undoubtedly do, but that’s just For Now. Within my lifetime, they’ll probably go completely. Still, the world moves on. They were a phase, a hundred-and-fifty year phase, but now, their time is fading. Their time will soon be past.