$ cat /home/buntine/mind_melting_brilliance

After pushing a large Rails app live recently, I was constantly struggling to keep Passenger live. Roughly, every 24 hours passenger would simply hang and stop handling requests. The machine (VPS running CentOS 5, 2gb RAM, 4 CPUs) had sufficient free resources and memory. Restarting Apache would instantly fix the issue and flush a bunch of "Broken pipe" errors to the error logs.

I found that killing the passenger process with a SIGABRT signal (6) would cause the process to write a stacktrace to Apaches error log. This was mildly useful.

As it turns out, I was able to solve the problem by finding and killing a couple of mysteriously dormant Ruby processes that passenger had left running. Why these were still running I am not sure. The Passenger team claim that the issue will be fixed in Passenger 3, but in the mean time, keeping an eye on Ruby processes may be beneficial. My (moderately heavy traffic) app has been online for about 7 days without a hitch now. Hopefully it will stay up indefinately now.

It's also worthwhile to make sure Apaches MaxClients setting is at an appropriate level (max_clients * average_process_size). My Passenger seemed to hang up as soon as this was hit. Be careful, though, as it turns out that Apache will keep spawning new clients even if you are out of memory -- I found this out the hard way.

Here are some useful discussions: http://code.google.com/p/phusion-passenger/issues/detail?id=318 and http://code.google.com/p/phusion-passenger/issues/detail?id=199.

I've been collecting Czech heavy metal LPs for several years now. There are just a few titles that I am missing. Some of these are so rare that only a few people even know they exist. The Sax Pijak is not so rare, but I still haven't got it yet.

I've seen some of them in photos and others I have been told exist from Czech nationals. The only one I have never actually seen is the Merlin "Nevada" LP. If anything has one of these, please let me know!

• Sifon - 100 høíchù LP (self, 1991) - FOUND 01/06/10
• TÖRR - Kladivo na čarodějnice LP (Monitor, 1993)
• Alkehol - Alkehol LP (Monitor, 1992)  - FOUND 20/05/10
• Alkehol - S úsmìvem se pije líp LP (Monitor, 1993)
• Arakain - Schizofrenie EP (NOT LP) (Suprahpon, 1991)
• Alien - Kino noc a kino den/Cesta všech EP (Best I.A, 1992)
• Distorze - Distorze / Zrcadlo (Best I.A, 1990)
• Distorze - Fuck of War EP (Private, 1991)
• Tarantula - Peklo pro všechny LP (Tony records, 1992)
• Merlin - Nevada LP (Monitor, 1991)
• Sebastian - Sny o Marii LP (Monitor, 1991) - FOUND 05/07/10
• Mac Beth - Mac Beth LP (Best I.A, 1992)
• Sax Piják - Válka nervù LP (Sacred records, 1992)
• Calibos - Calibos LP (Globus, 1992)
• Kabát - Děvky ty to znaj LP (Monitor, 1993)
• Pathologist - Putrefactive and Cadaverous Odes About Necroticism LP (M.A.B, 1993)
• Apolon - TVÁR SEBCA / ČACHTICKÁ PANI EP (Zeras, 1992)

ROT13 (that is, ROTate by 13 places) is a very simply substitution cipher that is often used in online forums, games and chat rooms. The idea was invented by Julius Caesar over 2,000 years ago (it was ROT3), but has been popular on the WWW since the '80s.

It works by rotating each character in a string of text by thirteen alphabetical characters, wrapping over to the beginning if necessary. For example:

Hello --> Uryyb --> Hello

As demonstrated above, one of the cool things about this simple technique is that it is it's own inverse. That is, applying the same filter twice will yield exactly what you started with. This, of course, makes it totally useless as a production-level encryption algorithm, but very handy for non-critical uses such as games and puzzles.

A very-similar alternative is ROT47, which applies the same concept to a larger range of characters in the ASCII set (94 to be exact: 33 to 127). This allows us to include several additional characters such as exclamation marks, commas, etc.

I've written a Firefox add-on, which allows you to select some text on a webpage, right-click it, and then generate the ROT13 or ROT47 substitute. From here you can re-apply the cipher and/or copy the new value to your local clipboard.

Please check it out and let me know of any problems you run into. Thanks!

Official download: https://addons.mozilla.org/en-US/firefox/addon/125128/

Or view/modify the source code: http://github.com/buntine/Quick-ROT13/

After I finished writing the Bolverk emulator (source, implementation) in early 2009, I instantly had ideas about designing an assembly language for it's native instruction set. It sounded like an interesting project.

After reading the first few hundred pages of Michael L. Scott's brilliant book "Programming Language Pragmatics" during February of this year, I felt that I had enough knowledge about writing simple compilers (most assemblers are not really considered compilers, but shhhh) in order to get started. In fact, the whole process turned out to be far more challenging and rewarding than I would ever have guessed before.

An assembler provides a level of abstraction above the native language of the machine at hand. Most basic assemblers provide a one-to-one mapping between named instructions and native commands (generally ones and zeroes). Many more modern assemblers also support more advanced features like macro expansion and control structures over basic JUMPing.
With an assembler, we can now express instructions to Bolverk in atleast slightly more memorable instructions. This is the reason the primitive procedures defined in an assembly language are often referred to as "mnemonics".

Another great advantage of an assembler is it's ability to define arbitrary abstractions that defy the architectural restrictions of it's target machine. In particular, the bolverk machine specifies that only 4-bits are used to identify an instruction. This leaves us with only sixteen (0..F) possible options. If chosen correctly, these sixteen natives will be more than enough to define useful abstractions by compounding and naming them. As an example, the PVDS mnemonic used in the example below will actally compile to 3 lines of machine code.

With the finished product, we can now write something like this:

-- Print the sum of two decimal numbers (-10 and 120)
-- followed by an exclamation mark.
VALL 1, -10
VALL 2, 120
PVDS 1, 2
PVCH '!'

Instead of the very-hard-to-remember machine code equivalent:

21f6
2278
2421
5123
33a0
34a1
d1a0
d0a1
c000

The assembly version required only four instructions opposed to the nine required in the machine code version. It was also presented in much more readable manner.

Once we know the following semantics:

• VALL: Load into register X the value Y
• PVDS: Print to STDOUT the value of the sum of register X and register Y
• PVCH: Print to STDOUT, the value of X as though it's an ASCII character

The assembly version becomes very easy to understand.

The source code is openly available from my git repository here: http://github.com/buntine/Bolverk-Assembler. I will add a front-end for it into the web-based implementation of Bolverk (linked above) in the coming days. I've also published the grammar and a language specification in the same git repository.

I feel that my work on this set of projects could really be beneficial in teaching the ideas behind a Von Neumann machine to beginning computer science students. If found by the right person in the right position, I think they could do wonders with it. If you are that person - please give me an email or some feedback! I'd happily donate all of my work to your organisation if it can be put to good use.

A big "thanks" to the people that emailed me and those who brought it up on forums, etc. Sorry for my delay, but I've just updated Witchhammer to be compatible with Firefox 3.6.*. All should be fine within the next 30 minutes or so (just waiting on Mozilla to update their cache).

As per usual, download it from the official repository: https://addons.mozilla.org/en-US/firefox/addon/9671/

Thanks again!

Exercise 1.12 in SICP is proposed as follows:

My brain saw it as:

I spent about 30 minutes working on a solution that would actually return a structure containing all of the elements of Pascals Triangle up to a particular row/width. I was wondering the whole time how any non-experienced programmer could ever solve the problem at such an early stage of the book! D'oh!

Here is what I came up with:

(define (pascal width)
  (reverse (pascal-helper '((1)) width)))

(define (pascal-helper rows width)
  (if (= (length rows) width)
    rows
    (pascal-helper (cons (next-row (car rows))
                         rows)
                   width)))

(define (next-row previous)
  (let ((body (row-body '() previous)))
    (if (null? body)
      '(1 1)
      (cons 1 (append body '(1))))))

(define (row-body body previous)
  (if (null? (cdr previous))
    body
    (row-body (cons (+ (car previous) (cadr previous))
                    body)
              (cdr previous))))

And lets see it in action:

> (pascal 5)
> ((1) (1 1) (1 2 1) (1 3 3 1) (1 4 6 4 1))

It works by building each row of the triangle in reverse order. Each row implements a linearly recursive process to build itself based on the contents of the previous row. We consume the previous row by taking it's cdr on each resursion. This means that the value of element y in row x is the sum of the first two elements in the previous row. This process is continued until the previous row has only one element left. At this point we throw a 1 on either side and we are done!

From now on I will be sure to pay more attention when interpreting the requirements for each exercise (although I secretly think this was much more fun)!

This is the second article in a two (maybe three) part series on tree data structures in Scheme. See the "representation article", also.

Previously, I've spoken about one way of representing a tree data structure in Scheme. This time, I'll talk about a simple algorithm for parsing such a structure, which uses a technique called mutual recursion.

Wikipedia defines mutual recursion as "a form of recursion where two mathematical or computational functions are defined in terms of each other". This is an appropriate explanation for our case, as we'll have two procedures which rely upon each other to produce a single result.

The first procedure will extract the child nodes from a tree structure. The second procedure will accept those children, a list of trees, and extract and parse each one. This process is performed recursively.

As an example, lets write an accumulative procedure that consumes a tree and returns a number representing the amount of parent nodes (that is, nodes which contain further children):

; Using the tree we created in the first article
> (count-parents family-tree)
  3

We can define this as follows:

(define (leaf? node)
  (null? (cdr node)))

(define (count-parents tree)
  (if (leaf? tree)
    0
    (+ 1 (count-parents-in-trees (cdr tree)))))

(define (count-parents-in-trees trees)
  (if (null? trees)
    0
    (+ (count-parents (car trees))
       (count-parents-in-trees (cdr trees)))))

It works by allowing the two procedures to only deal with the information they need. count-parents deals with trees, whilst count-parents-in-trees deals with a list of trees. leaf? is just a simple helper. Each branch of each tree is searched downwards until we reach a dead-end - a node with no children.

The recursive pattern in count-parents-in-trees should be fairly familiar. Basically, we take the first element (car) for inspection, and recurse with the remaining elements (cdr). Because of this, our base-case is the empty list, at which point we've hit every node in the branch and should have our result.

This general pattern can be applied to many tasks involving trees, from representing them graphically to mutating their structure. For example, to write a procedure that takes a tree and returns a new tree without the leaf nodes, all we need to do is use mutual recursion to build up a copy of the tree in question and ignore every leaf node.

This is the first part of a two (maybe three) part series on tree data structures in Scheme.

In many programming problems, an efficient way of organising data is in a tree-like structure. In essence, a tree in this sense consists of a root node, followed by zero or more sub-nodes, each of which can be followed by a set of further nodes. Common terminology for this node/subnodes relationship is mother and children, respectively. Other common terms are root/branch/leaf.

A picture is a great way to provide an example of such a structure:

The tree above is quite simple. It consists of a root node, followed by two children. The first child contains no further children (a leaf), and the second child is the parent to one child. An important thing to realise at this point is that every child is infact a perfectly valid tree in and of itself. We can see this in more detail a bit further on.

Representing such a structure in Scheme (or any implementation of LISP) is really quite easy. We use the obvious building block: lists. The tree in the image above would be encoded as:

'(a (b) (c (d)))

As I mentioned before, if we snap off the branches from the root node, we are left with a set of new trees; a forest. In LISP terms, the cdr of a tree is a list of lists:

'((b) (c (d)))

The first item in this list is a tree with only a root node. Not a very useful tree, but a tree none-the-less. The second; a tree with a root node and a single child element. The reason I've brought this up is because it shows us that there is most certainly a convenient recursive way to deal with such a structure (this I will talk about in the next article).

To help us with creating trees and get our terminology contextually proper, we can define the following helper procedures:

(define (tree root . children)
  (cons root children))

(define (leaf-node node)
  (tree node))

So, with these new procedures in place, lets create a basic tree structure:

> (define family-tree
          (tree 'family
                (tree 'karl
                      (leaf-node 'oak))
                (tree 'colin
                      (leaf-node 'celine)
                      (leaf-node 'ashin))))

> family-tree
  (family (karl (oak)) (colin (celine) (ashin)))

In the next article I'll talk about a cool way of recursively parsing such a structure.

If you're like me, you've probably read the first 150 pages of SICP (The Structure and Interpretation of Computer Programs) about three times. Personally, I find that it starts out extremely easy, but quickly becomes difficult. After a while I find that I am still reading, but not a whole lot is making sense to me. It's as though there is an underlying peice of knowledge that the authors assume I possess, which I don't.

I am of the school of "SICP should be read by all programmers". But I think my exact statement would be: "SICP should be read, and understood, by all programmers".

If we take a look on Amazon, we will see the strange mix of reviews SICP has received thus far (stars/reviews): 5/89, 4/8, 3/8, 2/3, 1/53

What?? So, I guess this implies that people either LOVE or HATE this book. If you go through the reviews in detail, you can see that a lot of the 1-star reviewers are upset with the text because it's simply too abstract and they do not leave with any confidence. I feel it is also worth mentioning that this text has received an elitist badge in our industry. If you read it, watch the lectures, and brainwash yourself into thinking you understood everything, you are now part of the genius club and can start quoting Paul Graham and Peter Norvig.

Enter Simply Scheme (Brain Harvey, Matthew Wright. 2nd ed, 1999, MIT press). A fundamental computer programming textbook for those of us who have trouble tackling SICP (and also for the people who, out of fear, pretend they could). According to the authors, SS was actually written as a pre-cursor to SICP. This textbook presents all the major concepts in a much more digestible way than SICP. This is good news!

As a word of warning, it's worth knowing that SS does use Scheme, but it teaches a slightly modified version of it. You will learn effective program design, but not the inner workings of Scheme itself. I already knew scheme when I started this book, and it annoyed me a little at the beginning, but I quickly got used to it.

The entire text is available free on the web. Take a look: http://www.eecs.berkeley.edu/~bh/ss-toc2.html.

I have also spent a lot of my freetime publishing my answers to all of the exercises at the end of each chapter. You can take a look at my solutions here: http://github.com/buntine/Simply-Scheme-Exercises (perhaps you can fork me and juxtapose your own solutions??). I hope this can help someone in their travels.

So, once you get through Simply Scheme, you may be much better suited to properly tackle SICP and finally become a master craftsman!