I recently finished reading The Elements of Murder: A History of Poison by John Emsley. It’s a fun book, if you like reading about such things as the historical use of toxic metals (and metalloids), both as medicines and as poisons. It’s really interesting how many had useful medical purposes, albeit with side effects that were often as bad as their benefits. (Typically, a lot of toxic heavy metal compounds are even more toxic against microorganisms than against humans, but not much.)

I’m currently reading You Are Not a Gadget by the decidedly-curmudgeonly Jaron Lanier. I’ll have more to say about it later, but I think he really has some important things to say about the prospects for culture in the modern world.

Also, I bought a single-tuner HD Homerun and a UHF TV antenna (there was an existing and unused satellite mount and a piece of coax routed in through the wall, so it was quite easy), and I set up the MythTV backend on my home fileserver. I’ve got it recording what little broadcast tv is worth watching.

I got engaged to Tien, though that was really only a question of when.

The time, or at least attention I had to devote to other activities was somewhat limited. I did a fair amount of gardening. I set up a 25 gallon aquarium with lots of plants, and now that the pH has stabilized, it’s doing very well.

I’m less impressed by mulching techniques and materials than most people seem to be. More on that in the future. Though, aside from being lazy, one possible reason not to mulch beds is that it may discourage ground-nesting bees. (See Mulch Madness, One More Deterrent To Beeing Successful).

In a dry climate, drip irrigation is the best thing ever. You can maintain good moisture levels without over and underwatering. You can avoid all the troubles of hitting plants too hard with water or disease related to having the tops of plants too moist. Just about the only thing it’s not good for is sprouting seeds, since you don’t get very even moisture levels at the very top of the soil.

Drip Irrigation for Every Landscape and All Climates by Robert Kourik is a good book on the subject, though I pretty much figured it out on my own beforehand. It’s ideal to avoid lots of connections and just use lengths of tubing that have integral emitters. Also, use a good filter, regulator, and always use a backflow preventer.

Mizuna is just about the only salad green you’re going to grow in the hot dry summer here. Arugula will do okay, but it gets too bitter and bolts easily. Nasturtium is trivial to grow even in partial shade (though you get less flowers that way.)

Give zucchini and tomatoes ample water and lots of manure. As with any fruiting crop, don’t let the zucchini get too mature before picking, or it’ll start to slow down. One zucchini plant is enough for two people unless you really love zucchini. Zucchini (and many other fruiting annuals) need calcium. If they don’t have enough, you get blossom-end rot. With this somewhat alkaline soil, gypsum seems to work (and should help make the clay easier to work). In more acidic soil, dolomitic lime is the standard thing, from what I hear.

Sunflowers are easy once they got big enough to resist slug and snail attack. Growing pole beans up sunflowers works, but I’ll build a trellis next time to space the vines out better. Also, if you’re unlucky, the weight of the beans breaks the sunflower in half. (This is the “mammoth” sunflower I’m talking about — 7 feet tall even with shade for part of the day.)

As for slugs and snails, the baited iron phosphate granules (Sluggo is one brand) seems reasonably effective and is essentially harmless to people, pets, and plants in the quantity used. Sprinkle on plenty at least monthly. Most of the trouble I had was with small plants as they sprouted — once things like beans and sunflowers got bigger, they have reasonably snail-unfriendly surfaces. And the zucchini is downright pest-unfriendly — the stems give me a temporary rash on my arms, though callouses on the my fingers make them okay to handle that way.

This was all the stuff in the ground, which I find vastly more enjoyable for growing annuals, compared to fiddly containers. More on the container stuff next time…

Anyway, if I do this, it will be my first serious foray into Windows programming.

I’ve also done a fair amount of gardening lately. You can see more on Flickr. I’m really looking forward to getting that Canon 100mm macro lens so I can take more of the sort of photos of plants and bugs that I find interesting.

I plan to allocate a bit more of my time for writing, soon.

The new commute sucked. An hour each way by car, hour and a half by train (total, door-to-door).

So, after looking for a couple weeks, and hurriedly packing for a couple more, we moved at the end of February to a house in Sunnyvale. More space, and I’m only 2 miles from work. I can even walk to work in about 40 to 45 minutes, slowed down somewhat by the necessity of crossing the street excessively. We’re still unpacking.

Somewhat annoyingly, VMware uses the lowest-common-denominator Linux sound API, OSS. Unfortunately, OSS, as typically implemented, only allows one application to have the sound device open at once. This might have been a acceptable design in 1995, but it sucks today.

However, as many people mention in several places on the web, you can use the ALSA-OSS emulation layer to give you the benefits of ALSA (such as multiple applications opening the audio device at once) with VMware. Almost all of them involve modifying the script which starts vmware to LD_PRELOAD the libaoss.so library. However, this seems to not work in the latest versions, since there are multiple levels of shell scripts which start the actual binary, and some of them modify the LD_PRELOAD environment variable. As far as I can discern, the “right” way is to add this line to /etc/vmware/config :

preload = “/usr/lib/libaoss.so”

And now, sound works just fine for me in VMware.
(Note, I did have to “sudo apt-get install alsa-oss” beforehand.)

I’m slowly heading back to my FPGA project. I haven’t set up FPGA design software again, nor have I been mucking about in Verilog, however I’ve started to thinking about the implementation of a basic stack machine again. I’m a little disinterested in Forth lately, so I may just code up a quick assembler for it and see what strikes my fancy after that. At the moment, I’ve been scrawling some ideas on paper and thinking about how to best map about 19 instructions into a 16 bit word to minimize decoding logic.

More than ever, I believe that understanding how compilers work is among the most important practical topics in computer science, once you get beyond the basics. I’m glad I took a “Programming Languages and Compilers” course in college, but it was just an intro really. To really understand what’s going on and to really have the ability to make new tools when your tools are insufficient, this is a subject you can’t gloss over. (Steve Yegge has a great rant about this.)

Mostly, I’ve just been cranking out solutions to Project Euler problems and reading books in my spare time.

I highly recommend it to anyone who enjoys writing code and math (especially number theory). And I especially like my “language flavor of the moment” approach. It keeps you nimble. (Though, some problems just more difficult if your language of choice doesn’t have a built-in bignum implementation — fortunately Haskell and Python do.)

It is somewhat bizarre to me that there is not an obvious way to make a io_device() as returned by file:open/2 from a socket() returned by gen_tcp:accept/1. Why would this be useful? So as to make it easy to do things like io:get_line/2 on it for protocols that are line-based. Much like, in C, how you can fdopen on a socket to get a FILE * from any integer file descriptor including sockets.

I suppose the right thing to do is to create a server which wraps the socket() in a io_device() interface. I’m not sure how that was going to perform, and I was just going to try doing the simplest thing that would work — which is to write my own line-buffering.

Now, in Erlang, strings are (linked) lists of chars (which are actually integers), so you don’t really want to use them for high performance IO. You instead want to use “binaries” which are arrays of integers, essentially. The standard functions for manipulation of binaries are pretty few in number, as far as I can tell. You can efficiently split a binary with split_binary/2, if you know the position you want to split it on, but if I wanted to split on a newline character (or character sequence) I’d need to be able to find the offset of that first, and I don’t see a function for searching a binary.

The obvious thing is to use pattern matching. Unfortunately, pattern matching on binaries only allows variable length sections at the end. So, I cannot do it in a single pattern match stage. Instead, it seems that I need to write a function that recurses over the binary character-by-character:

[Until I figure out how to post code in wordpress, see http://paste.lisp.org/display/69677]

I’ve yet to benchmark this and see how slow it is. I suppose it might not be that bad if the erlang compiler and VM are good. May not be much better than turning it into a string (list) and using the functions for strings:

http://www.erlang.org/pipermail/erlang-questions/2004-December/013650.html
http://www.erlang.org/pipermail/erlang-questions/2004-December/013666.html

[Edit: indeed. I need to get to sleep, but a little benchmarking suggests this is vastly faster: http://paste.lisp.org/display/69680]

At least I’m not the only one thinking along these lines: EEP 9 - Library for working with binaries

As a return to the original reason I started down this line of thought, it appears that both mochiweb (used both internally by Mochi Media and by CouchDB) and this http server use an undocumented feature:

{packet, http} puts the socket into http mode. This makes the socket wait for a HTTP Request line, and if this is received to immediately switch to receiving HTTP header lines. The socket stays in header mode until the end of header marker is received (CR,NL,CR,NL), at which time it goes back to wait for a following HTTP Request line.

And, according to that page:

The undocumented features presented in this HOWTO are undocumented because they are not supported by Ericsson. On the other hand they are used in commercially shipping systems.

That, if true, rubs me the wrong way.

I spent a few days playing with Haskell. I should write some more about what I found interesting about a strongly-typed pure functional language, one where you have to essentially do side-effects (such as I/O) by passing the state of the world to the function and returning it from the function, albeit with some neat shortcuts (Monads, etc.) to make that less awkward than you’d think. It was possibly even more fascinating than when I first learned Standard ML back in college.

I found that it was really difficult to express non-trivial things in Haskell however. I think this may become easier with more exposure to it in the future, but for now I’m putting it on the back burner. I think I’m going to aim to make one day a month “Haskell day” wherein I advance my exposure to Haskell, because I find it very perspective-expanding.

Largely because this renewed my belief in the usefulness of functional programming languages, I then decided to take a closer look at Erlang than I have in the past, including ordering the Joe Armstrong book. At the moment, the toy project I’m working on is a twitter client that acts as a irc daemon, so I can just connect to this in my irc client (which easily handles multiple irc networks), and then I can read twitters and send twitters from within it, not wasting interface-space with another application, or time by going to the twitter homepage.

Erlang is rather ideal for applications that do a bunch of network stuff, it provides for the easy creation of lightweight processes and the easy sending of messages between them. Sending messages is non-blocking, and the system insures that the message will be in the receiving process’ mailbox, ready to be received with a pattern-matching construct. It does not provide object-oriented programming constructs in the usual way people think of OOP, however, it can be argued that passing messages to processes is directly analogous to invoking methods on objects. (See a good blog post by Ralph Johnson and a comment thread on LtU.)

So far, I feel like I understand 95% of the language, and about 50% of OTP (Open Telecom Platform, an included set of libraries and conventions for building applications.) It feels pretty good, and practically quite usable. It does feel a little less modern as functional programming languages go. It doesn’t have currying, and some of the syntax is a little less clean than you find in Haskell. But, on the whole, it does have a lot of the features I do want, including a decent pattern matching syntax.