Posts

I’ve been using darcs recently for some Haskell-related revision control tasks, as it’s the revision control tool of choice for the Haskell community (no surprise; it’s the most widely used Haskell program in existence). However, I can’t say I’ve been all that happy with darcs during my first few days of use. It has some behaviours that I think of as ill-considered, and not oriented towards making new users comfortable quickly. By default, “darcs record” (the equivalent of “commit” in other tools–why the different command name?) prompts me for every single hunk, to see if I really want to commit that hunk. The"-all" option records all hunks, but why is this not the default? It’s all very well that I can pick and choose hunks, but why isn’t by far the most frequent use case embodied in the default behaviour of the command? When I run “darcs record” without “-all”, darcs presents me with a prompt that is impressive in its opacity. ...

The Hilbert curve is a fractal space-filling curve that is rather pretty to look at. [!hilbert.png](http://mathworld.wolfram.com/HilbertCurve.html) A Hilbert curve of order n traces a single path over a square of side 2^n units, as you can see in the images from MathWorld above (with curves of order 2 through 6). If you pick a point p from within the square covered by a curve, and trace out the curve until you reach that point, the number of intermediate points that you passed through along your way to p is called the Hilbert distance. The notion of distance along a space-filling curve is useful for a few reasons. ...

As part of my remedial Haskell learning process, I’ve been getting my feet wet once more with monads. Here are a few notes on the techniques that I’ve tried, and how I’ve fared with them. Not surprisingly, my first step was to try reading some tutorials. If you’ve looked, you may have noticed that the web is awash with monad tutorials. There’s something about monads that seems to compel people to write tutorials about them. They sound scary: what’s this chunk of category theory doing in my language soup? After a few nights of reading, but absorbing little, I concluded that this was getting me nowhere. I’m happy to concede that this was in large part my fault; I prefer taking things apart to reading about how they’re put together; and I have two little kids, so my attention is perforce limited to brief spans, right before bed. But I suspect that Sturgeon’s Revelation may have had more than a little to do with my indifferent level of enlightenment. My reaction was to abandon the tutorials, and start reading the source code of the Haskell prelude (the chunk of standard library that’s always available without you having to explicitly pull it in). To my delight, I found that the Maybe type was a monad; even better, it looked like it might be easy to use. Armed with a text editor and a Haskell interpreter, I wrote a simple parser and interpreter for a pattern language, and used the Maybe monad to represent the results of both parsing and matching. (In case you’re interested, I reimplemented the Unix fnmatch library call. It’s a nice, tidy problem that doesn’t require a full regexp engine to solve, and that provides a bit of useful functionality that’s not available through any standard Haskell library.) While I was doing this, I deliberately avoided Haskell’s “do” syntax, the better to give me an idea of what was really happening. And rather than try to follow the rickety exposition of a tutorial, I simply made lots of elementary mistakes. Each infinite loop and type error was my own shining beacon of stupid, lighting a step on the random walk towards slightly less stupid. At the end of a few hours of hacking, I had a nifty little piece of code going, complete with uses of the three monad functions. I was satisfied that I at least had some notion of the use of the Maybe monad, albeit in splendid isolation. This turned out to be an especially good place to start, because the Maybe datatype is incredibly simple, as are the monad functions defined on it. Once I was happy with the Maybe monad, I decided to try the State monad. My programming vehicle this time was much simpler than fnmatch; I just decided to count repeated instances of an item in a tree. This turned out to be a lucky choice, because I found State much harder to grasp than Maybe. (Perhaps this was because I was coming from the direction of reading the source code in a vacuum and trying to decide how to put the pieces together. I won’t be surprised if the “read the source” approach fails me at some point, but so far, so good.) This was an endeavour where Haskell’s brevity and type system really shone for me. Even though I had little initial idea of what I was doing, I was able to run my initial State-using code through the interpreter, have it point out something egregious that I was misunderstanding, and iteratively refine (I mean “rip to shreds and rewrite”) my code until I got it to actually work, all the while referring to the source for the State monad so that I could find functions like evalState, get, and put. The brevity of Haskell helped me here because the State monad is tiny; even though it’s much more complex than the Maybe monad, it’s still small enough that the source fits in a single editor window. And the type system was valuable not only because the interpreter could spank me whenever I was being dull-witted, but because I could read the type signatures of functions and actions around the State monad that I thought I might need, and tell whether they had a chance of doing what I wanted. Once I had a basic grasp of the Maybe and State monads, I found that going back and rereading the same tutorials that had initially baffled me had a profoundly different result. I now had a framework in which I could think usefully about what the tutorial authors were trying to tell me. (I also have stronger opinions as to which of the tutorials and references are best, but I’ll save those for another time.) After a few days of tinkering with them, monads are looking decidedly less scary to me. We’ll see if I’m still saying that after spending a little time with StateT and a few stacked monads, but getting my hands dirty has given me a degree of understanding that I could not have matched with reading. If monads still give you palpitations, I urge you to dive in, create a silly contrived problem for yourself, and just wallow with Maybe for a while.

Since I’ve been away from the Haskell world for a long time, it’s been interesting to return and observe some surprises about the practical side of working with the language. For me, an early gotcha has been the relative paucity of information on how to obtain and install third-party software packages. So here’s my little contribution, in the form of simple instructions for the newcomer. I hope that someone will find them useful. If you’re using Debian, you’re in great shape; there’s a good chance that whatever third-party package you’re interested in is already available. Whatever the Haskell package is named, if there’s a corresponding Debian package, it will ave a lowercase name. So here’s how use the regular package management tools to see if, for example, the indispensable MissingH is available: ...

One of the exciting things about upgrading to Fedora Core 6 is that the yum package manager now frequently hangs on me. This does not fill me with joy. The most common way in which it falls over is by hanging hard after printing this message: Parsing package install arguments What it means to “hang hard” here is that you can’t interrupt it using control-C, or by killing it with a normal, neighbourly signal like SIGINT or SIGTERM. A little bit of digging in another terminal window indicates why: ...

Carol Lloyd at the Chron wrote a second article about our fun with green building in San Francisco recently, which elicited a mention at SocketSite. The peanut gallery had a variety of comments, which I’ll quickly address here. Someone noticed that our planning drawings were sent back to an “earlier” desk in the review process because they differed from the original drawings we submitted. What happened was that the plans accumulated a number of small changes as they went from desk to desk in the City’s planning departments; this is almost inevitable if you’re not going by the numbers with a standard construction plan. The accumulated changes prompted one of the reviewers to send our plans back to make sure they were still conformant. It’s not a big deal, though the added delay is unwelcome. Another commenter: ...

Set him on fire, and he’ll be warm for the rest of his life. [!Tickle Me Elmo on fire](https://web.archive.org/web/20100308130050/http://video.google.com:80/videoplay?docid=-4024457809967804989) Tip of the hat to Quinn.

I’ve lately become interested in the Haskell programming language again, after a long time (eleven years!) away from the fold. During the process of thrashing about and trying to find my footing, I discovered a new module, named Data.ByteString, which makes dealing with strings in Haskell both sane and impressively fast. So I started to read the code, and whoa! There’s my name! Because it had been so long since I’d done any Haskell programming, I’d almost completely forgotten about everything that I had written, including Data.PackedString (a pale precursor of the stream-fusing beauty that is Data.ByteString). I wrote PackedString in 1994 (before Haskell acquired a half-decent module system), when I spent a summer interning for Simon Peyton Jones. It was almost a physical shock to see my name in a context that I had so thoroughly forgotten. I must have sat staring at the screen for a good 15 seconds, and even then I had to ask Don Stewart on #haskell about the connection, beause I could just not figure it out (he pointed me at Data.PackedString). I don’t know whether to be more amused by seeing my name in a chunk of code that’s far superior to my original or my own astonishment at seeing it there.

Since FC6 ships with Python 2.4, you’re a bit stuck if you want to play with the new features of Python 2.5. Here’s a quick and easy way to build and install a cleanly-packaged version of Python 2.5 for FC6. First, you must ensure that you have a sufficient development environment available. Fortunately, you can do this in one step. Note: this is the only command you’ll need to run with root privileges until the time comes for you to install the Python RPM that you’ve built. ...

I’ve had a Sony Ericsson Z520a phone for a little under a year now, and as it’s still widely available through cellular carriers, I thought I’d write up my experiences with it. I’m writing in part as a reaction to the weakness of phone review web sites, which tend to publish reviews from people who’ve had their phones for somewhere between an hour and a month. The reviews thus rarely shed any light on the medium- to long-term issues of using the phones they cover, instead clustering around the same few obviously good or bad points that immediately come to light. Case in point: CNET’s review of the Z520a, which cites the crummy picture quality, but doesn’t note much else, and gives the phone a “very good” rating. First, a few positive observations. Call quality is generally decent, and I’ve had fewer problems with dropout than with my previous phone. Battery life is impressive, at about five days, and it hasn’t diminished noticeably over the year I’ve been using the phone. The phone’s user interface is only indifferently responsive. It takes a perceptible fraction of a second to respond to keypresses. The lag isn’t enough to be a serious problem; it’s more of a peeve. The Z520a is a clamshell phone, and it’s surprisingly difficult to open with one hand. This is due to two design flaws. The grooves in the fold of the phone are small enough to require both precision and force to insert the inside of a thumb to start the opening process. Once you’ve cracked the shell open, the mechanism is unsprung, and requires constant application of force to open it fully. This makes the phones much more difficult to open than similar models from other manufacturers, such as Motorola. What drives me absolutely crazy, though, are the side operation buttons. Thanks to Sony Ericsson’s fine design, I take upwards of half a dozen photos of the inside of my pocket every day. As if that weren’t insult enough, the volume control rocker button can’t take the abuse of sitting in a pocket, and my “increase volume” button no longer works at all. I somehow managed to avoid fat-fingering the “decrease volume” side of the rocker for about a month after this happened, but the inevitable eventually occurred, and my phone is now stuck permanently at minimum talk volume. And the only way I can even monkey with the volume is to use those buttons during a call (they do nothing useful when the phone is in standby mode); there’s no redundancy in the design, and I have to use up my miserly supply of minutes to even try. I also have some sour words for AT&T’s mangling of the user interface. At every level of menu hierarchy, the first option I’m presented with is to visit AT&T’s mobile web site to buy ringtones, pictures (who the hell buys pictures from their cellular provider?), and other stuff I don’t want. And accidentally fat-fingering such a menu item means that I’m paying for the data transfer involved. Bah. Really, though, all other opinions I have of the phone are overshadowed by its fragility, the result of which is that I can no longer hear anything during a call unless I’m in an empty, silent room. If it weren’t for the side controls, I’d actually call it a reasonably decent phone, but it snatches defeat from the jaws of victory to get a default score of “crap” instead.