Symbolic Forest

Sometimes, given that I often work with people who are twenty years or so younger than me, I feel old. I mean, the archives of this blog go back over twenty years now: these are serious, intelligent colleagues, and when I started writing my first blog posts they were likely still toddlers.

Sometimes, though, that has an advantage. I was thinking of this when debugging some code a colleague had written, which worked fine up to a point, but failed if its input file was more than, say, a few tens of megabytes. When the input reached that size, the whole thing crashed with OutOfMemoryException even on a computer with multiple gigabytes of memory, a hundred times more memory than the hundred-megabyte example file the client had sent.

When I was younger, you see, that would have seemed a ridiculous amount of data, unimaginable to fit in one file. Even when I had my first PC, the thought of a file too big to fit on even a superfloppy like a Zip disk was a little bit mindblowing, even though the PC seemed massive compared to what I’d experienced before.

Back when I was at school, I’d tried to teach myself how to code on an Amstrad CPC, a mid-1980s 8-bit machine with a 64k address space and a floppy disk drive of 180k capacity. It was the second-generation of 8-bit home machine really, more powerful than a C64 or a Sinclair Spectrum despite sharing the same CPU as the latter. Unlike those, it had a fully-bitmapped screen with individual pixels all fully addressable; however, that took up 16k of the 64k address space, so the actual code on it had to be pretty damn tight to fit. The programmers’ Firmware Manual—what we’d now call the API reference documentation—is of course scanned and online; one of the reasons I was never very succssful coding on the machine itself^* was that in the 1980s and 90s copies of it were almost impossible to find once Amstrad’s print run was exhausted. On the CPC, every byte you used counted; a lot of software development houses ended up cross-assembling their code purely because for a large program it was difficult to fit the source code itself onto the machine.^** That’s the background I came from, and it makes me wary still nowadays not to waste too much memory or resources. I’m the sort of developer who will pass an expected size parameter to the List<T> constructor if it’s known, to avoid unnecessary reallocations, who doesn’t add ToList() automatically by reflex to the end of every LINQ operation—which is a good idea in any case, as long as you know when you do need to.

Returning to the present: what had my team member done, then, that he was provoking a machine into running out of memory when in theory he had plenty to play with? Well, there were two problems at work.

Firstly, yes, we’re talking about someone who has never tried building code on a tiny tiny environment. The purpose of this particular code was to take an input zip file, open it, modify some of its content, recompress it, and send it off to an API elsewhere. Moreover, this had been done re-using existing internal code, some of which wanted to operate on a Stream and some of which, for whatever reason I don’t know, wanted to operate on a byte[]. We had ended up with code that received the data in a MemoryStream, unzipped it in memory, and copied the contents out into more MemoryStream objects. Each of those was being copied into a byte array which was being passed to a routine that immediately copied its input into a new MemoryStream, before deserializing…well, you get the idea. The whole thing ended up with many, many copies of the input data in memory, either in essentially its original format, or in a slightly modified form, and all of these copies were still in memory at the end of the process.

Secondly, there was another issue that was not quite so much the developer’s responsibility. This .NET code was being combined in “Portable” form, and the server was, again for reasons best known to itself, deciding that it should run it with the 32-bit runtime. Therefore, although there should have been 16Gb of memory on the server instance, we were working with a 2Gb memory ceiling.

I did dig in and rewrite as much of the code as I thought I needed to. Some of the copying could be elided altogether; and as this wasn’t a time-critical piece of code, I changed a lot of the rest to use a temporary file instead of memory. The second issue had an easy, lazy fix: compile the thing as 64-bit only, so the server would have no choice of runtime. As a result I never did get to the bottom of why it was preferring the 32-bit runtime, but I had working, shippable, code at the end of the day, and that’s what mattered here.

What I couldn’t help thinking, though, was that the rewriting might not have been needed to begin with. A young developer—who’s never worked on a genuinely small system—has spent so much time, though, never worrying about working anywhere near the boundaries of what their virtual servers can cope with, that when they do hit those boundaries, it comes as a nasty, sudden shock. They have no idea at all what to do, or even where to start: an OutOfMemoryException may as well be an act of the gods. Maybe when I’m helping train people up, I should give them all an Amstrad CPC emulator and see what the result is.

* My high point was successfully cloning Minesweeper, but with keyboard controls.

** Some software was shipped on 16k ROMs, to go along with third-party ROM socket boxes that attached to the expansion bus; this kept the assembler and editor code out of the main address space, but it could still be difficult to fit the source code and the assembler output in memory at the same time. The ROMs were scanned on boot and each declared named entrypoints which could then be accessed as BASIC commands. At least one game I can remember—The Bard’s Tale—crashed if too many ROMs were attached, because each ROM could reserve an area of RAM for its own bookkeeping, and the game found itself without enough memory available.

Keyword noise: software, software development, resources, coding.

It’s been quiet around here lately, partly because I’ve been trying to hide from the various summer heatwaves, and partly because I’ve been beavering away at something else in the background. I’ve set up a YouTube channel, and have posted my first proper video, the start of a Lego build. It’s only small, and I’m still learning, but one thing I’ve already learned is that coming up with the idea, shooting all the footage, writing the narration, recording it, editing the whole thing together…well, it’s a lot more work than just writing a blog post.

It makes me think, actually: years and years and years ago, Radio Scotland had a documentary about blogging, and included posts from me, read by an actor. I wonder if the actor who played me found it as much effort.

Incidentally, after the previous post on the Perseids, I did go outside for a while each night last weekend, lie down on the grass, and watch for meteors. There were a few, each night, streaking across the sky; and lying on my back looking up seemed to be the best, most comfortable way to get a full view of as much of the sky as I could. The grass is much nicer for lying on, at this time of year, than it will be for the big meteor showers of winter.

Keyword noise: videos, crafting, Lego, astronomy, Perseids, meteors, meteor shower.

Just as it was this time last year, it’s Astronomy News time because we’re coming into the season of the best and biggest meteor shower of the year, the Perseids, which reach their peak next weekend. This year the peak coincides roughly with the full moon, which is in the early hours of Friday morning, but hopefully the brightest meteors will still stand out—or you can always wait a few days into the following week, because the like most meteor showers you can still see plenty of meteors in the few days either side of the Perseids’ peak. Get a chair you can lean back in, sit outside on a clear night, and watch the sky until you see them flash across it.

Incidentally, Saturn is also the largest it gets in the sky at the moment, as we’re the closest that we will be to it this year. I might be tempted, if there’s a clear sky, to get the telescope out and have a look, to see how well I can spot its rings. Of course, annoyingly, it will also be close in the sky to the full moon next weekend just because that’s how the geometry of the solar system works. The moon is full when it’s directly opposite the sun from us. The outer planets are closest to us when we’re directly between them and the sun—which is the same thing. At least the moon moves relatively quickly in the sky, day to day, so even one day after the full moon it should be far enough away from Saturn to not be too much of a problem. I’ll just have to hope the skies are clear.

Keyword noise: astronomy, meteors, meteor shower, Perseids.

There are so many preserved and heritage railways in the UK—there must be something around a hundred at the moment, depending on your definition—that it’s very difficult to know all of them intimately, or even to visit them all. It doesn’t help that still, around 55 years after the “great contraction” of the railway network in a quixotic attempt to make it return to profitability, new heritage railways occasionally appear, like mushrooms out of the ground after rain.

Which is why, a few weeks ago, I decided to pop over to Another Part Of The Forest and visit one of the very newest: the Crowle Peatland Railway. It’s still only about three and a half years since the CPR first started laying track; only about ten years since the railway’s founders first conceived of the idea, and less than a year since passengers have been able to ride on it.

The CPR was built to preserve the memory of a very specific, industrial type of narrow-gauge railway, one that is associated more with Ireland than with Britain. The Crowle Peatlands are part of one of the largest lowland bogs in England, the Thorne Moors, on the boundary between North Lincolnshire and South Yorkshire. Drained from natural wetland by the engineer Cornelis Vermuyden in the late 1620s, from the mid-19th century the area started to be mined for peat, with a network of railways bringing the peat from the moors to factories at their edges for processing and transshipment. For many decades these railways used horse haulage, but from around 1950 the peat company switched to petrol and diesel locomotives.

This map shows the Moors at around the time the railways started using locomotive power: you can see the lines of railways across the moors, following the drainage canals, making sharp, almost-hairpin corners. Even in the 1980s there were still between 15 and 20 miles of narrow gauge railway across Thorne Moors, remaining in use until peat mining ended around 2000; the newest locomotive on the railway was bought new as late as 1991.

The preserved railway is in the area shown on that map as “Ribbon Row”, west of Crowle, reached along a narrow, dead-straight lane across the flat landscape of the Moors. As soon as you are outside the town, it feels disconnected, remote, outside the normal world entirely. As I drove, in my mirrors, I saw a young deer crossing the road behind me.

To date, the railway has a café with very nice home-made cake. a maintenance shed, and a straight line of track stretching out across the moor. The shed is full of the sort of small diesel locomotives that worked on the moors from the 1950s onwards—and also, a Portuguese tram.

I think the loco on the left is Schöma 5130 of 1990; the diamond-shaped plate is the builder’s plate of Alan Keef of Ross-on-Wye, to mark the loco being rebuilt in the late 1990s with a more powerful engine, which you can see here.

The newest loco to run on the peat railways was named after a retired member of staff in the early 1990s, shortly after it was built.

The railway’s other locomotive is a Motor-Rail Simplex built in 1967 and abandoned around 1996 due to worn bearings.

It’s a nice little engine, much less powerful than the newer ones, but I’m not sure what I think of lime green as a locomotive colour.

On a map—if it had made it onto any maps yet—the railway would no doubt appear as a dead straight ine; but on the ground it follows gentle curves and undulations. At 3ft gauge the track feels wide for a narrow-gauge line, especially given the small size of the powered trolley that takes you out onto the moor. On my run I was the only passenger, with a driver and guard to look after me, as we pottered out along the track, surrounded by wildflowers pressing close up to the track, fat bumblebees buzzing close to the car as we went.

No stations; no platforms; no sidings. No signals other than a fixed distant sign warning that the track will run out soon. Just a single line of track, which stops. Back we go; with me and the guard having the best view this time, although I tried to make myself thinner and not block the driver’s line of sight.

That photo shows practically the whole railway, with the shed visible in the distance. We trundled back in, feeling far faster than the handful of miles per hour we were actually doing. Retracing our steps, back to the yard.

The Crowle Peatland Railway isn’t somewhere I’ll be going back to again that soon, because for now, I’ve seen all there is to see. But it is a nice little place to visit, a reminder that everyone starts somewhere, and that sometimes a railway is just a stretch of line running out into a field. It’s open and running trains about one weekend a month at the moment, and it’s worth visiting for the cakes. Or, indeed, if you just want to be out in a landscape where the horizon is straight as a ruler, and there are few noises beyond the wind blowing the grass.

Keyword noise: Lincolnshire, North Lincolnshire, Crowle, Crowle Peatlands Railway, railway, narrow gauge, photography, maps.

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.

Keyword noise: coding, software, .NET, .NET Framework, computing, C#, development.

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.

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.

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.

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.

Keyword noise: radio, history, electronics, domestic appliances.

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.

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

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…

…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.

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.

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.

Keyword noise: crafting, crochet, amigurumi.

A visit to the Rheilffordd Ffestiniog/Ffestiniog Railway, back in April.

Keyword noise: photography, rheilffordd, railway, train, steam train, Cymru, Wales, Gogledd Cymru, North Wales, Rheilffordd Ffestiniog, Ffestiniog Railway, Blaenau Ffestiniog, Porthmadog, Dduallt, Merddin Emrys, David Lloyd George.

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.

Keyword noise: phones, phone boxes.

Over the last few months I haven’t done much crafting, for one reason and another, but various crafting projects have slowly built up in my mind, a bit like a slowly-filling bath, until the other day someone sent me a link to an amigurumi pattern they thought I might want to buy, and it finally slopped the water all over the edge of the bath that is my mind and onto the bathroom floor that is my working table. Amigurumi, I should say, is specifically a term for making cute cuddly toys out of crochet.

Now, I haven’t done any crochet for over ten years, and I hadn’t tried to follow a crochet pattern for over ten years before that. On reading the pattern I’d bought, I quickly realised that right this minute my crochet skills are no where near good enough to actually make the thing properly. Rather than give up, though, I started making a trial swatch using the yarn I’d bought, to get used to using it, to remind myself how the various stitches work, and to get used to the difference between American crochet terminology (as used by the pattern) and British crochet terminology (as used by me in the past). They are confusingly similar: to go from American terminology to British you add one to all the names, so a single stitch becomes a double stitch and a double becomes a treble. Within a few minutes really, I had myself a few rows of double single crochet.

My big mistake was buying the wrong yarn, basically. The pattern said to use “baby yarn”, but the shop I went in didn’t have the right colours, so I went for “double knit” instead, thinking “well it’s the same sort of thickness”. The difference is that double knit is twisted from two strands (hence the name, presumably?) and in my hands, the crochet hook is liable to split the yarn when I try to insert it into a stitch or pull through a tight loop.

Making a practice swatch, though, is definitely a good idea if only so I get myself used to how not to do that. Indeed, when a pattern says “insert hook into next stitch”, exactly where in said stitch do they mean? A few times in my first few rows I accidentally decreased or increased several stitches, from either skipping my hook ahead too far or accidentally putting it back into the previous stitch, giving my test piece a rather wobbly and wrinkled look.

I’m not going to start the pattern itself until I’ve done quite a few rows of every stitch it needs, and until I’ve “got my eye in”, reached the point I can look at the piece and see where each stitch is and which part of each stitch each thread belongs to. That was something I learned years ago doing archaeology: you can’t just come into a new situation, look at a thing, and immediately parse it all visually, immediately see how the different things slot together. You have to “get your eye in”, and let your brain learn how things work in this new context. At first my crochet piece was a uniform brown blob, which is why I made mistakes, but now I’m starting to see what to do.

The next part in this series is here

Keyword noise: crafting, crochet, amigurumi, relearning things.