Gravatar support

I’ve added gravatar support to the website. The gravatar system is a clever way to create identity on-line: e-mails are associated with images. Critically, the URL associated with an e-mail doesn’t include the e-mail itself, but instead an MD5 hash — this way, spammers can’t harvest your address.

I was disappointed to discover that Google Chat doesn’t have support for gravatars — a Google labs feature I would use.

PHPEnkoder 1.5

Martin Rees noticed that any user can change PHPEnkoder’s settings. I’ve change PHPEnkoder’s settings panel to require the manage_options capability. Now, by default, only administrators can change PHPEnkoder’s settings. (If you’re unfamiliar with the concept, check out the Codex documentation on roles and capabilities.)

As usual, the plugin is available from the PHPEnkoder website and its home in the plugin directory.

Open-Access Venue for Theoretical Computer Science

Via the TYPES-announce mailing list:

…we are launching

  Electronic Proceedings in Theoretic Computer Science (EPTCS)

a new international refereed open access venue for the rapid
electronic publication of the proceedings of workshops and
conferences, and of festschrifts, etc, in the general area of
theoretical computer science, broadly construed.

This is exciting news! I’m even willing to overlook the fact the plural of ‘festschrift’ is ‘festschriften’, not ‘festschrifts’.

Debounce and other callback combinators

It is serendipitous that I noticed a blog post about a callback combinator while adding a few drops to the Flapjax bucket.

Flapjax is nothing more than a coherent set of callback combinators. The key insight to this set of callback combinators is the “Event” abstraction — a Node in FJ’s implementation. Once callbacks are Nodes, you get two things:

  1. a handle that allows you to multiply operate on a single (time-varying) data source, and
  2. a whole host of useful abstractions for manipulating handles: mergeE, calmE, switchE, etc.

The last I saw the implementations of Resume and Continue, they were built using this idea. The more I think about it, the more the FJ-language seems like the wrong approach: the FJ-library is an awesome abstraction, in theory and practice.

PHPEnkoder 1.3

Ron Blaisdell pointed out that my use of noscript elements wasn’t XHTML compliant. Instead of using noscript tags, each enkoded section is preceded by a span containing the “you don’t have JavaScript” message. When the dekoded text is written to the document, this span is deleted.

The latest version is up on PHPEnkoder’s home page and the WordPress plugin directory. (For some reason, PHPEnkoder doesn’t come up when you search for it in the directory, but Google can see it. I’m not sure what the problem is here…)

Practical OCaml

Suppose you were trying to run some experiments about L1 D-caches. (You may also suppose that this is a homework problem, but that’s life.) You’re given a trace of loads and stores at certain addresses. These addresses are 32-bits wide, and the trace is in a textual format:
1A2B3C4D L
DEADBEEF S
1B2B3C4D L
represents a load to 0x1a2b3c4d, followed by a store to 0xdeadbeef, followed by a load to 0x1b2b3c4d. (You might notice the two loads may be in conflict, depending on the block and cache size and the degree associativity. In that case, you might be in my computer architecture class…)

This is problematic. Naturally, you’d like to process the trace in OCaml. But did I mention that the trace is rather large — some 600MB uncompressed? And that some of the addresses require all 32 bits? And some of the statistics you need to collect require 32 bits (or more)? OCaml could process the entire trace in under a minute, but the boxing and unboxing of int32s and int64s adds more than twenty minutes (even with -unsafe). I felt bad about this until a classmate using Haskell had a runtime of about two and a half hours. Yeesh. C can do this in a minute or less. And apparently the traces that real architecture researchers use are gigabytes in size. Writing the simulator in OCaml was a joy; testing and running it was not.

There were some optimizations I didn’t do. I was reading memop-by-memop rather than in blocks of memops. I ran all of my simulations in parallel: read in a memop, simulate the memop in each type of cache, repeat. I could have improved cache locality by reading in a block of memops and then simulating in sequence; I’m not sure how the compiler laid out my statistics structures. I could’ve also written the statistics functions in C on unboxed unsigned longs, but didn’t have the patience. I’d still have to pay for boxing and unboxing the C structure every time, though. Still: one lazy summer week, I may give the code generation for boxed integers a glance.