Squawks of the Parrot

On new things

Computer science research papers are funny things. On the one hand, there's all sorts of interesting stuff in them. And on the other it almost doesn't matter because the stuff just isn't accessible.

I found this out when I was doing research for Parrot, where a lot of the interesting things were done in Lisp, a language that, to a first approximation, nobody knows or cares about. I'm finding it again as I do research for Tornado where the interesting things are done in Haskell, again a language that, to a first approximation, nobody knows or cares about.

This, I think, is sad. Not that nobody cares about Lisp or Haskell (languages have to rise and fall on their own merits, and since it's all syntax I only have a limited interest in it) but rather because the relative obscurity of the languages being used makes it all that much more difficult to get some of these concepts in more wide-spread use.

As an example, take transactional memory. This is a really powerful concept that allows you to avoid a whole range of nasty problems when writing multithreaded code -- there's no worry about deadlocks or priority inversions, and in the common case where there's reading but not writing of global data it's much more performant. The problem is that most of the papers on STM express the code in Haskell with corresponding text that is written academically.

The problem is that if you don't read academic-speak (and most people don't) and don't read Haskell (which, again, most people don't) then you're just SOL. Granted, I'm not sure in practical terms it matters much for low-level constructs since most programmers aren't going to go implement things themselves, but still... for those of us who do want to implement this sort of thing it's a big pain.

More importantly, I think it makes it more difficult to recruit more people to write this sort of low-level code. Yes, it's tricky, but it's hardly rocket science. As we found with Parrot, most clever and willing programmers could do these low-level things but didn't because they were scared of them -- as an example, garbage collection terrified folks even though it just wasn't that tough. The problem was that all the literature was, bluntly, inaccessible.

So, I guess this is my complaint, or possibly my plea -- if you're writing papers about new things, by all means do your test implementation in whatever language you want, but when you write the paper? Use a language people actually know, dammit, even if you have to fake it.

Clever new things don't do anyone any good if nobody can understand the damn things. And when people don't understand them it's your failure as an author, not theirs as a reader, so... be understandable, even if you feel like you have to stoop. In the long run it'll be a lot more useful.

Quick notes on party prep #6

By far, the most important phrase that's not in the english language is mise en place.

Quick notes on party prep #5

Never underestimate the importance of flavored seltzer water. When surrounded by sugar and fat you're going to eat something, and best it's not something too calorie dense.

Quick notes on party prep #4

Heavy cream should always be bought in gallon quantities. Multiple gallon quantities...

Quick notes on party prep #3

There is no such thing as too much food when cooking for an organization of any size. There are, in fact, only three quantity categories: not enough, could have made some more, and the Mailroom says thanks for the goodies.

Always be nice to the Mailroom...

Quick notes on party prep, #2

The big O for these things is O(N ln B) where N is the number of recipes and B is the number of batches being made. That is, doing one batch each of five recipes is O(5 ln 5) but doing five batches of one recipe is O(1 ln 5). This is important to remember when planning out how much can be done before collapse...

Quick notes on party prep #1

When cooking for members of the legal profession, the phrase "too much alcohol" is only valid in the technical sense. That is, the statement there is too much alcohol for the gelatin to set is meaningful, while the statement there is too much whiskey in this pie, nobody will like it is entirely nonsensical.

You know times have changed

when you come across the phrase "when the heap fits in main memory" and you realize that the alternate case is ignorable -- swapping is such a catastrophic failure all by itself it doesn't matter how an algorithm or technique performs when that happens.

You know it's going to be a heck of a party...

When you look at the 30 pounds of sugar, 10 pounds of butter, and 9 dozen eggs in the kitchen and your first thought is "I don't think I have enough, better hit the store."

On the utility of benchmark implementations

One thing that's really useful to have, when experimenting with new things, is an existing thing that does something like what you're trying to build. I don't mean something to copy, but rather something that you can judge your performance against as you work on an alternate implementation. There are many different ways to do a task, but it's silly to spend much time working on a way that's slow and clunky.

As a for example, as I dive back into working on Tornado, I dusted off the implementation of Conway's Game of Life. It's a nice piece to work with -- it's small and easy to get your head around, but it exercises much of the core of a VM, including array work, basic math, conditional expressions, resource allocation, and looping. It's also very easy to throw together a reference implementation of, as a way to get a handle on how the VM version runs relative to a compiled version.

Not, mind, that the VM version is likely to run as fast as the compiled version. There's overhead involved in most VM designs (without JITs, at least, and even having a JIT involves the overhead of on-the-fly compilation) so we're not looking for parity, but that doesn't mean we should settle for bad performance. So... I tossed together a quick GOL implementation and gave it a run. It's a standard version, one that calculates each cell completely sequentially. This is different from the Tornado version, which does nine offset passes, but that's fine, the results are the same.

The Tornado version does 50,000 generations of a 10x80 board in 1.45 seconds. That's with a perl wrapper, but there's only 0.045s of overhead there, which I think we can reasonably ignore.

Surprisingly, the C version does 50,000 generations of a 10x80 board in 1.58 seconds with unoptimized C. That I didn't expect, but judging against this isn't appropriate, since Tornado is compiled optimized. (Still... woo! :)

The C version, when built optimized, runs 50,000 generations of a 10x80 board in 1.28 seconds.

The C version is faster than the Tornado version, but only 12%. That... is quite nice, actually. While I expected it to be reasonably performant (the main loop to calculate a generation is only 34 VM instructions, regardless of the board size) I was expecting something more like a 40% penalty at this point in the implementation, and this is where having a benchmark implementation is important.

If the VM was running 70% or more slower than the base version, then it was time to toss out a lot of the core work. It wouldn't matter how much I liked the design, if it doesn't perform it's got to go, and the sooner that non-performant design gets thrown out the better -- the longer it lasts the more things depend on it and the harder it is to get rid of it.

So... yay for benchmark implementations. Make them and test your new implementations against them, and don't be afraid to throw out code no matter how much you like it.

I really want an OS X version of iBooks...

I've been messing around with my epub creation script, and the thing's working pretty well at this point -- feed it a manifest file with some metadata in it, along with the files to be stuffed into the book, and it works just fine. Very cool. Most of the heavy lifting's done with some perl modules

Of course, actually building the ebook's the easy bit. Building a book that iBooks likes is the tricky bit, since it very sensibly assumes that you're only going to hand it ebooks it likes, and those books aren't going to change once you hand them off. If either of those things isn't true then it gets all sorts of cranky.

I'd like to bitch about that, I really would, but it's not really reasonable to do so. It's not a development tool, and treating it like one doesn't work too well.

For example, if you've handed iBooks a book that doesn't validate for some reason, or has an error in it, it'll yell. That's fine. But... if you fix that error, drop the new version of the book in iTunes and re-sync? Nothing happens. iBooks doesn't notice that a book's got new contents and happily re-displays the old contents for you, complete with errors. You have to delete the book, sync, re-add the book, and resync. All with iBooks running, or it doesn't reliably clear out its cache. Yech.

And lets not even get into the execrable HTML that Word, OS X's RTF->HTML methods, and various publishing tools create. They'll all happily ladle on vast amounts of crap that generally need to be stripped away if you want to make a simple ebook. Stripping that out's been huge amounts of fun, especially coupled with iBook's double-sync quirk. Thankfully there's http://www.threepress.org/document/epub-validate/ to do validation, but that only works if you're online, and doesn't catch formatting problems, just HTML issues. (Which, granted, is a big help)

All this'd be so much easier if there was an OS X version of iBooks I could work directly with. All the ePub capable ebook software I've got handy on my mac is altogether too forgiving (or, in the case of stanza, outright ignores a lot of stuff, which is nice as a reader but a pain in the neck for figuring out if things are working)

Ah, well, such is life. I think this thing is about ready to release for other folks to play with.

Mass-market paperback style epub files

I've got this shiny iPad, and I read a lot, and that means I've been digging through a lot of ebooks. Geek that I am, I've been fiddling with creating them too since the ePub format's not all that bad to work with once you get past the intrinsic horror that XML brings to anything it touches. (Perl modules help rather a lot here) I've found a few things out in the process.

Firstly, the formatting of an awful lot of ebooks is really sloppy. Books change font sizes from paragraph to paragraph, often times paragraph formatting shifts in the middle of a book (from indented paragraphs to extra leading between paragraphs and back), paragraphs are often not even there as the formatter uses breaks instead of paragraphs... the list goes on. We won't even talk about chaptering. Or the fact that a lot of ebooks look like someone took their Word doc, did a "Save as HTML", and threw the result at Calibre. And those are the better books.

Secondly, it turns out the ePub standard leaves out all sorts of important stuff. Like, for example, how to note cover art in an ePub book. Or how to handle tables of contents or indexes. I expect there are a number of practical reasons for that (probably dueling proposals, installed bases, intransigent committee members, and all the other political nonsense that goes with groups of more than one person) and that's fine. I'd rather have half a standard than none at all.

Here's a list of some things I've found while stripping crap out and reformatting things so they don't suck when read in iBooks. They seem to apply for Stanza, too, and hopefully to other ePub readers.

The Rules:

You're not controlling the formatting. Don't even try.
There are exactly four HTML tags you use in your text:
, , , and
. Maybe (maybe!) you use
for chapter heads.

There's exactly one tag attribute you use. align="center" You only use it on sub-chapter dividers. If you prefer horizontal rules instead, then you don't get to use align="center" and you can add
to your tag list

Use HTML entities for typographic characters (opening and closing quotes, em and en dashes, and ellipses)

Each chapter goes into a separate XHTML file.

No empty paragraphs! Or breaks, but since those aren't on your tag list you're not using them anyway.

The first xhtml file in your ebook holds the table of contents, cover-containing, and general front-of-book. This is the one xhtml file you get to have more tags in, and you can use... to link to the start of each chapter.

#1 drives the rest of the rules. You're building a book such that I can read it easily and straightforwardly, and I don't notice the formatting. There are plenty of books where I should notice the format, where the layout and art is breathtaking, where the book is interactive and linked to the world, where someone's spent days or weeks of their life putting together something that makes me damned impressed.

These rules are not for those books.

They're for mass-market paperbacks, things I pick up at Border's for $7 or $8. Books whose sole reason for being is the text the author wrote and anything that distracts from that is bad, because you're not going to spend the time to do the things to the text and layout that make it better. Think "overworked intern with a two hour deadline" here. Simple! The less formatting you apply the less there is to be screwed up.

#2 probably comes as a surprise. I and B are the tags we've been told to never use any more, since they specify formatting, and you're supposed to use CSS for that these days. Well, you can't do that. Refer to the list -- there's no class, no div, no span, no nothing that'd let you apply formatting to anything. Rule 2 is more for the mechanical parser than the ebook reader software. I can write code to rip out anything that's not an . Mechanically figuring out how something was tagged as italic and preserving that is a pain.

#3 is in grudgingly, because occasionally you want "* * *" or "~ * ~" or something like that to divide sections in a chapter.

While ebook reader software is generally clever enough to know what the quote characters are in unicode and the major 8-bit character sets, don't make it try. If you're going to use typographer's quotes, ellipses (that's three or four dots in a row, depending on the font), or proper em or en dashes, and you should, then encode them as HTML entities. Don't rely on the software to know you've used the Windows-1252 left quote character or the Unicode right double quote. &lsquot; or &rdquot; is better. Hence rule #4.

#5 is for performance. Separate files for each chapter make most ebook software perform better. (iBooks certainly much prefers it) Better performance means better battery life, and that's good. This is especially true at startup if you're in the middle of a book. For iBooks, at least, the time from startup to text display is dependent on how far your current position is from the start of the file the text is in. If you're on page 600 of 800, with all 800 pages in one file, it takes an annoying amount of time. If you're on page 600 of 800 but you're actually four pages into a chapter, it takes much, much less time. That's even better.

Some people really like a lot of space between their paragraphs. Some people don't. Either way is fine, but when you're building a book if you're under the impression there should be extra space after a paragraph the place to do it is in the .css file not with an extra

or
after each paragraph. Empty paragraphs are meaningless. Don't do that. Hence rule #6.
#7 is the one place where the previous 6 rules are a little looser. If you're going to have a title page and cover art and a table of contents you stick them in this first file. This is where you get to use links to point to each chapter start, where you embed the cover art link, and maybe get a little fiddlier with the fonts. Still very, very simple, but perhaps slightly less simple than the rest of the book
That's it. If you want to get fancy with fonts or leading or first-paragraph stuff or whatever then you do it in the .css file. Though, as a reader, I have to say please don't. Remember, mass market paperback. The point is for the formatting to be unobtrusive so it can get out of the way and I can enjoy the text.
One nice thing about these rules is that, if you want to get fancy, they give you base files that are in good shape for fanciness. You'll have nice clean input files with almost no crud in them, and with that you can do all sorts of Clever Things with CSS. It also means that if you feed these files into another program for WYSIWYG fancying up (and please don't, but...) you're not going to have to worry about that software getting confused by whatever fancy things the previous piece of software did.

Less ugly notes on the iPad

For reasons that probably made sense at the time (not that they were good reasons, just that they made sense) someone chose to use Marker Felt as the font for Notes on the iPhone and carried that over to the iPad. I dunno why exactly, as it's ugly and, worse, illegible at small sizes, but whatever. You also can't change it, which is doubly nasty. Yeah, I suppose font pickers are a bad thing in general and I can understand wanting to keep them away from the general user most of the time, but if you're going to do that you should choose a font that really doesn't suck.
Thankfully there's a way to get legible text out of Notes.
You need to enable the Japanese keyboard in the general settings. Once you do that, typing any single character off any of the japanese keyboards will flip the entire note over to use Helvetica. (I found this out by accident as it's really easy to switch keyboards) Doesn't matter how much text you've typed, and you can delete the japanese character without causing the note to shift back.
Yes, this is a horrible, nasty hack. It's lame and you shouldn't have to do it go get legible text, but it does work and if you happen to have the japanese keyboards enabled anyway it's even essentially effort-free.

A thing I want for my iPad

I've been fooling around with the thing since it showed up, and I like it. Using the iPad's different than I expected. I figured it'd be mostly like using my phone only with a screen big enough that I can see it from a distance, and with touch areas large enough that I can reasonably hit them. That, it turns out, is not the case. Having a huge screen makes interacting with it a mostly different experience, and one that's quite nice.
Having fiddled with it for a while, I realize that there's one thing very much missing in the accessory field. I want (I mean want, dammit!) a waterproof slide-in stand with screen protector. Something I can trivially slip the 'pad into and have it stand up so I can read it and tap the screen without worrying about getting stuff in the guts of the thing, mostly because of this:
Epicurious Recipes & Shopping List
Yeah, that's right, an iPad app with nicely formatted recipes, ready for use in the kitchen, a place where the iPad most definitely shouldn't go. (If the state of my cookbooks is anything to go by, given how spattered they are) Give me a way to use the 'pad in the kitchen and I will be very, very happy. (And likely start spending far too much on cookbooks in the book store)

Reasons to go large

Now that Apple's opened up the App Store so we can go look at the iPad apps, I find I'm very, very glad I sprung for the biggest of the pads. I was thinking that 64G was way too much, but I could toss all my music on it and maybe a few movies for when I want to watch something. I mean, I've got an 8G iPhone, and while it's a bit cramped that mostly means I have to not put music I don't much care about on it. Yeah, I'm gonna put a bunch of ebooks on it, but even that won't take all that much space.
The iPad apps, it turns out, are bloody enourmous. The biggest of the lot so far is The Elements: A Visual Exploration at 1.74G (Gig! Eeesh!) but the rest of these apps are coming in at 50-70M a pop. Well, okay, Bloomberg for iPad is only 2.7M because we're just that good, but still...
Folks who bought the 3G iPad are going to find they are not going to be downloading new apps over the air. And I don't want to think about what the load on the local Starbucks WiFi networks will look like. It'll only take a couple of people going "Oh cool!" to swamp the net for an hour or more. It's a darned good thing the iGadgets seem to handle partial downloads with retry pretty well.