Mr. Bald Eagle

A bald eagle lives somewhere around here. Arianna and I have seen him a few times. I saw him once last November, flying over the house on a blustery gust of wind. Ari saw him again in the middle of winter, along with my Dad, again flying directly over the house.

Today, Arianna spotted him again. He was flying low over the lake, being chased by a flock of seagulls. I ran downstairs and grabbed the binoculars, and went out on the breakwall to try to catch a glimpse of him. He was sitting on a sandbar a couple hundred yards north of the house, pecking at something on the ground and looking over his shoulder at the huge crowd of seagulls which were keeping their distance. I suspect he had caught a fish, and the seagulls were pretty pissed off about not getting any.

I wish we could have gotten a picture, but he was too far away. Hopefully Ari's next camera will be telephoto capable so we can get some nice shots of far-away stuff.

Debugging JavaScript

One of the things I hate about web development is the absolute pain in the ass that is JavaScript. It's not a terribly bad language in itself, with a decent anonymous function syntax and prototype-based object system (even if it's completely useless because there is no object database). But the fact that errors often pass silently and the debugging tools available are tedious and a pain to use makes developing with JS almost unbearable. I have often wished for the staple, the crutch of development in tool-poor environments, of the 'print' statement.

Here is how to configure Mozilla so that calls to 'dump()' will show up in the console:

Fire up Mozilla and type 'about:config' in the url bar.

Right click and choose 'New->Boolean'

Type 'browser.dom.window.dump.enabled'

Type 'true'

Start Mozilla from a shell, and you will finally be able to debug complex javascripts by printing things to the console using the 'dump' function.

By the way, to start Mozilla from the Terminal on Mac OS X, execute the binary:

'Mozilla.app/Contents/MacOS/mozilla-bin'

Dark Castle!

The entire Dark Castle, for your viewing pleasure.

Ahh, Dark Castle

Bill writes about both Return to Dark Castle and Zelda today.

There were a few NES games which consumed much of the time I should have been playing outside in my youth. Number one on that list was certainly the original Zelda. As Bill notes, Zelda is interesting historically mostly because of the influence it had on later games, not because of stellar game design. The stilted english translations and inherent limitations of the cartridge format made the game tough to play unless you had access to a walkthrough, which Nintendo Power did a good job of providing every month.

But the amount of time I spent playing Zelda was nothing compared to how much time I wasted playing Dark Castle. I remember it came on two 400k floppies, DC and DC Data, and it took me a while to start it up on the ol' 128 (upgraded to 512k, but no 'e'). Like many early side-scrolling platformers, every time you started the game you had to play from the beginning. I got pretty good at it; I could get the shield 100% of the time, fireball a lot of the time. I could usually make it through Dark Knight 1, and often the game was over in Dark Knight 2. I still remember the first time I beat it, and finally toppled the Dark Knight.

Dark Castle was one of those games that I wished had a level editor. Another game I played a lot around the same time was Pinball Construction Set, and I spent quite a lot of time imagining the levels I would design had a level editor been available for Dark Castle. I remember vividly one time when I sat in the waiting room at the dentist, drawing a Dark Castle level which was a combination of the slide into Trouble 3 and the swinging ropes in Trouble 2.

When Beyond Dark Castle came out, unfortunately the ol' machine wasn't powerful enough to play it. Once or twice a year we would go visit family friends in Lansing who had both an SE/30 and a Mac II (color!). It was the best thing in the world to be able to play Beyond Dark Castle on that SE/30. I never did get enough time to finish it, though.

openit

For a while now I have been using a very useful one-off script I wrote which I call 'openit'. You provide it with the dotted name of any python package or module, and it opens it in your editor. You don't have to worry whether the module is in the stdlib, in your sitepackages, or somewhere else on your pythonpath. I have been using it more and more recently, and the implementation is trivial, so I thought I would share it here:

#!/usr/bin/python

import os, sys

numargs = len(sys.argv)
if numargs == 1 or numargs > 2:
print """Usage: %s modulename""" % sys.argv[0]
sys.exit()

from twisted.python import reflect

obj = reflect.namedAny(sys.argv[1])

fileName = obj.__file__
if fileName[-1] == 'c':
fileName = fileName[:-1]

os.system("open %s" % fileName)

This implementation uses twisted.python because it is convenient, but the implementation of namedAny is short enough that you could really just copy it into the script if you wanted to. It also uses the Mac OS X specific 'open' command, so you will have had to tell the Finder which application you want to edit .py files. If you are on any other OS besides OS X, you can replace the open command with $EDITOR or whatever command you use to edit a file with your editor of choice.