A simple demonstration of virtual memory

In discussion, it appears many people are unclear on how memory (RAM) is managed in modern OSs, and in particular the concept of virtual memory and its implications for a process. Also, how virtual memory is not the same as paging/swapping (or RAM, or 'storage', or the memory used by virtual machines, etc.).

Many modern computer architectures (e.g., x86-64) possess a Memory Management Unit (MMU) that translates memory addresses as used by processes running on the computer into physical addresses. The memory seen by processes, therefore, is only virtual memory. This allows an OS to present a contiguous and isolated virtual memory space to each process, irrespective of what else is running on the machine—each process in effect thinks it has all the memory to itself. This is simply demonstrated by the program below, which when compiled (on, e.g., Linux x86-64) will show the same memory address holding two different values 'simultaneously'!

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main() {
  int a, i;
  if (fork()) sleep(1);
  a = getpid();
  for (i = 0; i < 4; i++) {
    printf("pid=%i: &a=%p, a=%i\n", getpid(), &a, a);
  return 0;

Read more…

Nuclear throne

A game I consistently play from time to time is Nuclear Throne, a fairly addictive twin-stick shooter where you try to reach the eponymous Nuclear Throne. Which you won't, since the game is fairly hard too. It's also one of the most highly rated games on Steam with a 96% approval rating (while not being super-niche)—which means it must be good, right?

The basic premise of the game is that you move through procedurally generated levels while fighting enemies from a top-down perspective with various randomly-obtained weapons. As you reach higher levels, the enemies get harder but you are also able to obtain better weapons (still randomly, from chests), leading to an interesting power balance. Eventually (if you get that far) you are facing off against green blobs firing virtually insta-kill plasma balls while running away against other green blobs with insta-kill bite attacks. But you have a nuclear missile-launching bazooka. If you are lucky. Otherwise you have a really slow-firing crossbow. And then you die... probably.

The game by itself only has local co-op, but there is a fairly good online multiplayer mod for the game that enables two people to play together over the internet. It even works with the the Steam friends list for invites, which is pretty good.

Also of note from the developers of the game is Super Crate Box, which is free and also very addictive.


Some obscure (or not) letters and diacritics I have come across

  • The diaeresis mark: “ä”. In English, unambiguously indicates a vowel is pronounced separately from the one before it: Noël (no-el, not nol), coöperate (co-operate, not coop-erate), mediëval (medi-eval, not me-die-val), etc. Quite rare except on loanwords. Not like the German umlaut at all.

  • The macron: “ā”. Represents a lengthened vowel sound in transcriptions of some other languages, for example Japanese in Hepburn romanisation: Tokyo is actually Tōkyō, or とうきょう “Toukyou”.

  • The cedilla: “ç”. In French (among others), represents a “c” pronounced like an “s”: “façade”.

  • The eszett: “ß”. Represents a double s-like sound, i.e. “ss” (or “sz”). Originally because there was another letter in the alphabet for a “long s”, “ſ”. “ß” is thus a ligature of “ſs” (originally “ſʒ” (“sz”, hence eszett) but apparently our fonts messed it up back in the day). It is not pronounced like the letter “b”. And related to that…

  • The long s: “ſ”. A former letter in English that was used in place of “s” for non-terminal letters, such as in this cover page for Paradiſe Loſt. The title is not pronounced “Paradife Loft”. And related to that…

  • The thorn: “þ”. Another former letter in English that was pronounced like “th”, as in “þe”, “the”. In some fonts this character came to appear like “y”, leading to words like “ye”, pronounced “the”. So the “ye” in a phrase like “ye old times”, is not actually pronounced “ye”…

A small game from long ago


A long long time ago in high school, we used the TI-83 Plus as our calculators. These were "graphical" calculators that had small LCD monochrome screens and which could be programmed using the TI-BASIC scripting language. The display itself had various modes, but the default and easiest to access was the 24×7 (I think?) character text console. Being bored at times like I was, I ended up writing various non-school related programs for the calculator, including several games.

The programs themselves did not last long, in part because by default files were stored in RAM and deleted if the calculator was power cycled (the default "on/off" did not clear the RAM, but taking the batteries out would). Eventually we were upgraded to the amazing (or so it seemed) TI-89, which was much more powerful and capable of symbolic equation-solving—thus known as a "CAS" (Computer Algebra System) calculator (and thus, banned in many assessment environments) (but, it still stored programs in RAM by default). This was the end of my TI-83+ programs—though I did write some for the TI-89, which can be found here.

Anyway, to the subject of the post: some time after that (but still almost 10 years before this post!) I ported one of the games I wrote to JavaScript. The link to it can be found at the top of the page, and every time I play it, it brings back memories of my TI-83+ days. I hope you have at least a moment of fun with it too.

Read more…

What happened to, you ask?

It's gone. It was old (the codebase had barely been updated since 2007), hard to maintain and eventually broke. And that was the end.

All the article content from the site has been imported onto this one, so it is still available, for what it's worth—I really wrote some pretty strange stuff back in the day! The URL structure has not been retained though so it may be hard to find some stuff. Have a browse if you feel like it.

As for what it looked like, before memories of the site are lost to time...

Screenshot of Aspektas blog

Update: as a bonus, here is what the site used to look like in some of its previous iterations, in chronological order.

Read more…

Python iter()

A seemingly little-known use for the Python iter() built-in: it can be used to tidy up code that would otherwise need a separate statement for assignment.

with open('text') as f:
    for b in iter(lambda:, ''):

instead of:

with open('text') as f:
    while True:
        b =
        if b == '': break

A small extension to this idea can be constructed to allow for arbitrary exit conditions, as opposed to just equality to a single value:

def until(f, sentinel):
    while True:
        v = f()
        if sentinel(v): break
        yield v

with open('text') as f:
    for b in until(lambda:, lambda c: c in ('', '\n')):

A switch to Ghost

As may be evident, this blog is undergoing some more change. In particular, I have switched to another CMS yet again, this time Ghost. So I have had to redo the theme, and now fix up my content. More to come on the transition once that is done...


Orbiting Earth is just moving sideways so fast that you move away from Earth as fast as you fall back towards it. Just getting up there is easy, but it isn’t enough — you’d just fall straight back down. It’s the sideways speed which is so hard to reach.

You could do this in our atmosphere as well, if the atmosphere wasn’t slowing you down so much.

A card problem

I was recently party to a very simple, but nonetheless interesting card game. In the game, four players begin the game holding one suit of cards each from a single deck. Then, for thirteen rounds (until the players have run out of cards) every player discards one of their cards simultaneously into the centre, with the player who discards the highest-value card winning the round. If two or more players discard cards of the same face value, then the round is a draw. The winner of the most rounds at the end then wins the game.

While this game is pretty simple and at first glance largely up to luck, it did make me wonder whether there were any strategies that could increase a player’s chance of winning. It would seem so, especially since the starting hands are constant. Therefore, it would be interesting to find both the optimal strategy assuming everyone else plays randomly (i.e. equal probability to play any remaining card), as well as the optimal strategy assuming everyone else plays optimally.