A sandwich. A good one.

White Paper Bag
What’s inside?









How to end fear of the dark


svn merge -c


# to undo changeset 1234 in the working copy:
svn merge -c-1234 files

The c is for “change” and the - means “in reverse”. When you read that command to yourself, say “svn merge change in reverse 1234”. That is sensible enough that you can remember it forever, even in an emergency. Right?


# to undo two changesets at once:
svn merge -c-1234 -c-1220 files


# to re-apply the changes you undid:
svn merge -c1220 -c1234 files

May this knowledge shave precious seconds off your next svn emergency!

Programming is not Algebra

A friend discovered a small interest in learning to program computers. She tried an online course but she didn’t get far before losing interest. She may have had other reasons for giving it up but by watching her and asking questions I did locate one significant hurdle: she was trying to read code through the lens of algebra.

I have seen this before. A student encounters a word, symbol, or pattern they recognize from some other context. Believing they have sufficient information to understand it in the new context, they push ahead. Soon their mental model fills with contradictions and the entire subject becomes intractable. This state of affairs causes people to quit their studies.

I’ve been there. Fortunately I learned the solution:

  1. Find what word or symbol was misunderstood.
  2. Learn the correct meaning.
  3. Re-study the material from the first occurrence.

The hardest part is completing the first step. This is especially true of students who already know a great deal and who are confident in their knowledge. Preconceptions hide themselves well but they surrender easily once found. Most people will be eager to complete the remaining steps after they have identified a real misunderstanding.

In this article I will expose some common preconceptions which can cause students of programming to quit. Teachers of beginner programming classes and writers of books would do well to treat these handicaps before setting students to code.
Continue reading Programming is not Algebra

Atomically update serialized PHP arrays in MySQL


  serialized = "i:1;"
    serialized = CONCAT(



After unserializing, deconstruct it with this function:

function decons($list) {
    $res = array();
    while ( $list != array() ) {
            array_unshift( $res, $list[1] );
            $list = $list[2];
        } else {
            array_unshift( $res, $list );
    return $res;

The result:

array(1, 2, 3)



Erlang is a hoarder

One day you set aside a shoebox to store newspaper clippings. Suddenly you are trapped under an avalanche of whole newspapers and wondering how long your body will lie there before anyone misses you.

That is what kept happening to my Erlang apps. They would store obsolete binary data in memory until memory filled up. Then they would go into swap and become unresponsive and unrecoverable. Eventually somebody would notice the smell and restart the server.

The problem seems to be related to Erlang’s memory management optimizations. Sometimes an optimization becomes pathological. If you store a piece of binary data for a while (a newspaper clipping) Erlang “optimizes” by remembering the whole binary (the newspaper). When you remove all references to that data (toss the clipping) Erlang sometimes fails to purge the data (lets the newspapers pile up everywhere). If nobody shows up to collect the garbage, Erlang dies an embarrassing death.

The first step to recovery is to monitor the app’s memory footprint and log in every so often to sweep out the detritus. It can be tricky to find the PIDs that need attention and tragic if you arrive too late. The permanent solution is to build periodic garbage collection into the app. It’s not hard to do. The only hazard is doing it too often since it incurs some CPU overhead.

Each time I have found an app doing this, I’ve had to locate the offending module and install explicit garbage collection. If there is a periodic event, such as a timeout that happens every second, I’ll use it to call something like this:

gc(Tick) ->
    case Tick rem 60 of
        0 -> erlang:garbage_collect(self());
        _ -> ok

Today I installed this simple code and here is the result:

Memory footprint reduced drastically
Memory footprint reduced drastically

CPU utilization raised slightly
CPU utilization raised slightly

For the cost of 5% of one CPU core I stopped the cycle of swap and restart. I would like to learn why my binaries are not being garbage collected automatically. The processes involved queue the binaries in lists for a short time, then send them to socket loops which dispose of them via gen_tcp:send/2. Setting fullsweep_after to 0 had no effect. I’ll be interested in any theories. However, I’m not looking for a new solution since mine is satisfactory. I hope other Erlang hackers find it useful.

2011 in review


Here’s an excerpt:


Click here to see the complete report.