I have merged my website and blog
As you may have noticed, I have merged my website and blog. This is because I barely updated my website, and so it wasn't really doing anything useful, and thus I decided it'd be better (and easier) if I just scrapped the separate blog and combined them into some sort of website-blog hybrid. You know, like most blogs out there. Anyway, there are bugs (makes it more fun), which are (or will shortly be) worked on. Additionally, I have a little to-do list which, incidentally, covers all of the bugs, unless there are any I haven't found:
- Make the gallery css and template consistent with the one used in the rest of the blog (I just copied that across from the old website)
- Update the 'about' page; I did edit it during the merge, combining it with the operating systems and contact pages, but I really need to read through it and update anything that needs updating.
- Write a Habari flattr plugin to have flattr images on all of my posts (hey, maybe also digg and 'like' buttons, too. I'll think about it)
- Redesign barrucadu.co.uk—this was the main motivation for the change, I want to overhaul my website (again)
TL;DR expect things to be broken and changing for a while. Hopefully I'll have a much better website by the end of it. blog.barrucadu.co.uk is currently redirecting traffic to barrucadu.co.uk, but it won't stay that way forever.
On an unrelated note, the new Arch Hurd livecd is progressing nicely. I expect to have it ready soon.
FlattrFeed
I am happy to announce the (almost) launch of FlattrFeed. At the time of writing, I'm still actually making it, and this post is a way of testing it. It's nearly done, though, so I shouldn't be much longer. I've signed up to Flattr, in an attempt to generate some revenue for Arch Hurd, and I decided to play with it and see what I could get for myself. The obvious way to do this is through my blog, but alas there is no Habari Flattr plugin yet. Thus, an idea was born...
I thought to myself, why make a plugin for one particular blogging software, when I can tackle everything with a feed in one go? So what started as a way to get my blog on Flattr, evolved very rapidly into a much grander idea. So, what is FlattrFeed? It is a simple system where you register, add your RSS and Atom feeds, and have it generate a page for users to flattr your articles either hourly, daily, weekly, or monthly (though I doubt many people will use that one).
To see an example of a user page, have a look at mine: http://www.flattrfeed.com/user/barrucadu. I'll add a more prominent link to my website and blog tomorrow.
In a way, this is a gamble. If I make back the money I spent on the domain, I'll keep it going. If not, I might take it down and write a Habari plugin. Or I might write one anyway. One thing that is certain, though, is that for now, FlattrFeed is here to stay. Enjoy!
Cool things to do with the Hurd: a read/write web
The credit for this idea goes to Arne Babenhauserheide, who submitted it to the bug-hurd mailing list. Basically, using a couple of Hurd translators (hostmux with httpfs, unionfs, and hgmerger), as well as a version control system (such as mercurial, git, or subversion), you can create a read/write version of the World Wide Web, in stark contrast to the mainly read-only one we have currently.
The full email can be seen in the bug-hurd archives.
The goal is to be able to make local edits of the world wide web and share those edits with others. We shall accomplish this using the translators hostmux with httpfs, unionfs, and hgmerger.
Now, using the hostmux translator, we can access websites at the path /http://..., this can be used to obtain the files to edit. On top of that, we shall use unionfs, to show our edited files in place over the original ones. For files in our local edit tree, all reads are directed to those, otherwise to the remote file. On top of that, we have hgmerger. hgmerger gets writes, merges them with the original files, and saves the changes to our local tree. Let's use this directory structure for reference:
/http://* - the real web
~/.http://* - the overlay
~/.bare-http://* - incoming changes.
When reading a site, hgmerger copies it from /http:// to ~/.bare-http and merges in to ~/.http://. In the case of a merge conflict, the original remote file will win. Our unionfs set up from earlier will ensure that the modified files are now seen when you request them through your browser, rather than the original files. This is getting pretty cool now.
Now, the repository in ~/.http:// can be shared online so other people can access your changes. And behold, a read/write web using the power of the Hurd and translators.
When I get my Hurd qemu image working again, I'll almost certainly be trying this and report back with my progress.
Using cron as an alarm clock
Yesterday I left my Archos at work, which I usually use as an alarm, so I had to improvise. I settled on using cron to play some music very loudly in the morning. My first thought was to use mplayer for this, but then I realised that I didn't have it installed on my server, so I went for MPD instead.
The first thing to do, an entry in the crontab, looks innocent enough:
15 08 * * * /usr/local/bin/alarmsound
The alarmsound script is also pretty simple, but with a devastating effect...
#!/bin/zsh
mpc pause
mpc clear
mpc add "Music/DragonForce/Inhuman Rampage/Through the Fire and Flames.ogg"
amixer set Master 100%
mpc play
mpc | grep -q "repeat: off" && mpc repeat
Now simply mute the sound with amixer set Master 0%, turn up the volume on your speakers (I have pretty good speakers, so I only went for 50% or so), and fall asleep. The next morning, you will be pleasantly awakened by a storm of sound that will cause you to fly out of your bed to mute it.
I don't think any alarm has ever gotten me out of bed faster.
Turing machines in Python
Lately I've been working through the recommended reading list for computer science at York and, naturally, Turing machines get mentioned in these books, being the computing machines. Today, something finally clicked and I understood how they work and how to program them. The result is a Python module for constructing and using Turing machines.
The module can be found on my github account, along with all my other stuff.
Before writing this module I designed a simple Turing machine on paper to increment and decrement binary numbers an arbitrary number of times to calculate simple addition and subtraction problems. For example:
Input tape: <10>+++-#
Output tape: <100>////#
What has been calculated there is 2 + 3 - 1, and you can see it has found the correct answer of 4. I shall firstly explain how this particular Turing machine works, then I'll explain how it was implemented using my module.
The Machine
The machine, hereinafter referred to as M increments and decrements an input binary number, N, as dictated by a series of +'s and -'s. M uses an alphabet of 8 symbols, plus a special blank symbol, which fills every cell not occupied by another symbol (as is the case for all Turing machines). It is assumed that the tape extends infinitely to the left and the right of the input expression, that M starts with the read/write mechanism pointing at the cell containing the > symbol, and that M starts in the ready state.
Alphabet
The alphabet used by M is as follows:
0 = binary zero
1 = binary one
> = lower end of number
< = upper end of number
+ = increment number
- = decrement number
/ = no operation
# = halt
The alphabet could actually be contracted, as the < and > symbols are not required (only being present for convenience), and could be replaced by a few more state transitions. In fact, the # and possibly / could also be removed, reducing to an alphabet of four symbols. Additionally, if I chose to represent numbers in unary rather than binary, an alphabet of three symbols could therefore be used. However, for now, I shall use the eight-symbol variant.
State transitions
The state transitions are the key to the machine, the following diagram shows how the machine behaves in each state for every symbol it encounters in that state. This diagram could perhaps be contracted, though I have not tried.
As you can see, if a < symbol is reached before a 1 when decrementing N (ie: subtracting 1 from 0), the machine halts. This machine only works for positive integer values of N (and zero, when incrementing).
Just a note on the notation used in the diagram for state transformations, "A/B,C" is used, where A corresponds to the symbol read, B corresponds to the symbol written, and C corresponds to the direction moved. A downside of using a slash as a separator between A and B means that, when a slash is read and written, the string "///" appears. Additionally, if A is missing (as is the case when moving from the grow state to the reset state), the symbol read is the blank symbol.
Knowing alphabet and transitions
It is trivial to see how it works. Here is an example showing 1 + 1 - 2= 0.
<1>+--# symbol read '>', state 'ready'
<1>+--# symbol read '+', state 'ready'
<1>/--# symbol read '>', state 'inc'
<1>/--# symbol read '1', state 'inc'
<0>/--# symbol read '<', state 'inc'
10>/--# symbol read ' ', state 'grow'
<10>/--# symbol read '1', state 'reset'
<10>/--# symbol read '0', state 'reset'
<10>/--# symbol read '>', state 'reset'
<10>/--# symbol read '/', state 'ready'
<10>/--# symbol read '-', state 'ready'
<10>//-# symbol read '/', state 'dec'
<10>//-# symbol read '>', state 'dec'
<10>//-# symbol read '0', state 'dec'
<11>//-# symbol read '1', state 'dec'
<01>//-# symbol read '1', state 'reset'
<01>//-# symbol read '>', state 'reset'
<01>//-# symbol read '/', state 'ready'
<01>//-# symbol read '/', state 'ready'
<01>//-# symbol read '-', state 'ready'
<01>///# symbol read '/', state 'dec'
<01>///# symbol read '/', state 'dec'
<01>///# symbol read '>', state 'dec'
<01>///# symbol read '1', state 'dec'
<00>///# symbol read '>', state 'reset'
<00>///# symbol read '/', state 'ready'
<00>///# symbol read '/', state 'ready'
<00>///# symbol read '/', state 'ready'
<00>///# symbol read '#', state 'ready'
However, even for such a simple calculation, 29 steps are required.
The Implementation
My class does most of the work, so all that needs to be done is to provide information about the desired machine, and provide an input. The basic code to create and run a Turing machine is as follows:
from turing import *
M = Turing(tape, states, haltstates, initialstate, transitions, alphabet, tapepos, blanksymbol)
M.run()
# At this point, the finished tape can be read:
print(M.tape)
Turing() parameters
Many of the parameters are fairly self-descriptive, however I will explain all of them:
- tape = an input tape to the machine, given as a string. This will be expanded to the left and right as required.
- states = a list of state names that the machine can be in.
- haltstates = a list of those states in states which should cause the machine to halt.
- initialstate = the name of the initial state of the machine.
- transitions = a dictionary showing state transitions (explained below).
- alphabet = a list of allowed symbols for this machine.
- tapepos = the starting tape position, given as a string index for tape (eg, tapepos = 0 corresponds to the first entry in tape).
- blanksymbol = the symbol used to fill newly-added cells in the tape, must be one character, by default set to a space. If not in alphabet, it will be added automatically.
Now, for the transitions dictionary. This consists of entries in the forms:
"state-symbol" : ["newsymbol", "newstate", "direction"],
"state-" : ["newsymbol", "newstate", "direction"]
Where the state-symbol syntax matches that symbol in the given state, and the state- syntax matches the blank symbol in the given state. newsymbol is the symbol to replace the current one on the tape with, newstate is the name of the state to enter, and direction is the direction to move in ("R" or "L").
Implementation of incdec
You are now fully armed to use my Turing class, and so I give you the example of my incdec Turing machine. The machine definition section which follows is the most interesting, particularly the state transition dictionary which, you should check for yourself, contains all of the transitions described in the previous diagram:
states = ["ready", "inc", "dec", "grow", "reset", "halt"]
haltstates = ["halt"]
alphabet = ["0", "1", "<", ">", "+", "-", "/", "#"]
transitions = {"ready->" : [">", "ready", "R"],
"ready-/" : ["/", "ready", "R"],
"ready-#" : ["#", "halt", "L"],
"ready-+" : ["/", "inc", "L"],
"ready--" : ["/", "dec", "L"],
"inc->" : [">", "inc", "L"],
"inc-<" : ["1", "grow", "L"],
"inc-/" : ["/", "inc", "L"],
"inc-0" : ["1", "reset", "R"],
"inc-1" : ["0", "inc", "L"],
"dec->" : [">", "dec", "L"],
"dec-<" : ["<", "halt", "R"],
"dec-/" : ["/", "dec", "L"],
"dec-0" : ["1", "dec", "L"],
"dec-1" : ["0", "reset", "R"],
"grow-" : ["<", "reset", "R"],
"reset-0" : ["0", "reset", "R"],
"reset-1" : ["1", "reset", "R"],
"reset->" : [">", "ready", "R"]}
After the machine definition, the rest of the code is trivial in comparison:
tape = "<1>+--#"
incdec = Turing(tape, states, haltstates, "ready", transitions, alphabet, tape.index(">"))
incdec.run()
print("Input tape: " + tape)
print("Output tape: " + incdec.tape)
print("Last state: " + incdec.states[incdec.mystate])
print("Symbols read: " + str(incdec.symbols))
As a side effect of this whole endeavour, I have proven to myself that Python 3 is a Turing-complete language :)
An edit
I have reduced incdec to an alphabet of five symbols, removed the grow state, and added a new state to indicate an overflow has occurred on decrementing, ovrflw. New state transition diagram follows (colour coded :))
Now it is assumed that the starting position of the tape is somewhere in the number. Additionally, this diagram is very pretty with red for halt states and blue for the initial state, and I have reduced the number of arrows by clumping state transitions that act on the same pair of states together.
