Archive for October, 2005

SF Restaurant: Tres Agaves

Saturday, October 29th, 2005

Tres Agaves opened this week and I rounded up 14 fellow Tequila Aficionados to enjoy an evening in the new restaurant.

It is located right at around the corner from SBC park at Townsend and 2nd (130 Townsend, to be specific).

The interior is quite beautifully designed/decorated and the food was absolutely spectacular. We ordered one of every appetizer and a large selection of dishes from the menu.

The fresh made guacamole, the slow roasted carnitas (pork), and the bread pudding with caramel ice cream were particularly delicious.

Like Tommy’s, Tres Agaves has an amazing tequila selection, makes awesome margaritas and, unlike every other restaurant in the area, the tequila and margaritas are fairly priced.

Tres Agaves can host parties and private functions quite nicely, too. If you are planning on a dinner at Mac World or WWDC, it is fairly close to Moscone and would be perfect for a corporate event.

Unit Testing and Code Coverage in Xcode

Saturday, October 29th, 2005

Chris Hanson and I both intended to write something like this someday. Now we don’t have to.

Go read this article about unit testing and code coverage. Specifically, Chris gives detailed instructions on how to integrate gcov based code coverage into Xcode while also leveraging Xcode’s support for unit testing.

Excellent article. Thanks for writing it, Chris. I hope you don’t mind if I file a couple of bugs against Xcode to remind us to integrate something like what you have done sometime in the future.

Tracing Python Execution

Thursday, October 27th, 2005

While working with Twisted and Nevow, I ran into a situation where something terribly nasty was happening well below any code I had written. Basically, I was faced with the classic high level development problem of “something I did long ago broke something deep within several layers of large scale systems I did not write”.

In these situations, a debugger does little good because there is little clue as to where things went awry. What I really needed was a way to trace execution.

It turns out that Python has excellent hooks for doing exactly that.

Add the following to any random hunk o’ code:

import sys
import linecache
import inspect

def traceit(frame, event, arg):
    if event == 'line':
        lineno = frame.f_lineno
        if '__file__' in frame.f_globals:
            filename = frame.f_globals['__file__']
            if (filename.endswith('.pyc') or
                filename = filename[:-1]
            name = frame.f_globals['__name__']
            line = linecache.getline(filename, lineno)
            name = '[unknown]'
                src = inspect.getsourcelines(frame)
                line = src[lineno]
            except IOError:
                line = 'Unknown code named [%s].  VM instruction #%d' % \
                    (frame.f_code.co_name, frame.f_lasti)
        print '%s:%s: %s' % (name, lineno, line.rstrip())
    return traceit

Then, to turn it on, call sys.settrace(). You can easily toggle the trace functionality, thus reducing the tracing to a very limited portion of the overall execution. This prevents one from drowning in data.


Note that the function has a frame object as an argument. That frame object allows for extremely deep introspection of the execution state, including variable state and just about anything else you would like to find out about the underlying virtual machine.

The original code was cribbed from the dalke scientific site. That article has an awesome explanation of the details of tracing. I just added some error checking and fallback code in the case where the original file/source cannot be determined. This enables the tracing functionality to work seamlessly within the context of Twisted.

It has already saved me a ton of time and I’m about to throw this permanently into my local Python library.

Neat PyObjC Trick

Wednesday, October 19th, 2005

I demoed the latest build of PyObjC at the recent CocoaHeads meeting in Cupertino.

The demo concluded with a “show all [most, really] the tricks at once” sequence.

  • How py2app, a part of PyObjC, will automatically create an installer package from a standard Python package
  • Injecting a live Python interpreter into a running application
  • Introspecting the application
  • Interacting with Core Data, including dealing with ** style parameters
  • Modifying a managed object and having KVO automatically fire on assignment

First, grab the top-of-tree source from the pyobjc repository:

svn co

Alternatively, you can mount that URL in the finder (click cancel on all the bloody attempts to write .DS_Store files) and cp -r the source to somewhere from the Terminal.


cd pyobjc
python bdist_mpkg --open

That will build PyObjC and open an Installer package that contains the runtime, documentation, examples, and Xcode templates.

Next, grab the OutlineEdit examples from /Developer/Examples/CoreData/ and run it.

Now, from the PyObjC source directory:
Read the rest of this entry »

Hurricane Wilma

Wednesday, October 19th, 2005

Jeff Mathers has a weblog where he analyzes the various Atlantic weather patterns. It is incredibly interesting. Of course, given the extraordinary 2005 storm season, the recent posts have been particularly enlightening.

Hurricane Wilma has proven to be an incredibly unique storm. Wilma strengthened from a Category 1 to Category 5 hurricane in something near 24 hours and has produced the lowest pressure ever recorded in an Atlantic hurricane.

How do the forecasters know the pressure? There is a hurricane hunter plane that flies through the eye of the hurricane. From Jeff’s current post on Wilma:

… It’s amazing the hurricane hunters were even able to penetrate the eye–it’s really tough to hit a 2 mile wide eye when you’re flying crabbed over at a 30 degree yaw angle fighting horizontal flight level winds of 185 mph and severe turbulence. This is an incredibly compact, amazingly intense hurricane, the likes of which has never been seen in the Atlantic. …

Holy crap! That sounds like one hell of a ride! Anyone know anyone that can get me a seat on just such a plane?

(Yeah, my spelling sucks. At least I was consistent.)

Delete Me!

Monday, October 17th, 2005
Skull and Sea Urchin

I just had my first truly useful “community site” experience.

I posted the image you see to the right into the Delete Me! Flickr group fully expecting that it would be harshly criticized. And, sure enough, it was.

I think the composition is good, but there are a number of relatively obvious faults with the actual execution. In particular, I did not use a tripod and the only way to get the shot was to bump the ISO to 1600 to make it possible to take the shot hand held.

While I couldn’t place exactly what was wrong with the image, the resulting criticism was hugely educational. Clearly, I need a tripod so that I can better control the exposure, use a significantly lower ISO to remove graininess and play with the depth of field a bit more. As well, a tripod would actually allow me to frame the shot considerably better than balancing on my tippy-toes.

Bark on Rock

I pretty much filter out the criticism along the lines of “I don’t like the subject material, therefore this photo sucks”. If I didn’t find the subject interesting, I wouldn’t take the photo and, ultimately, all of the photos are just for me anyway.

I’m definitely going to have to improve my posed still shot tools & skills. I have some ideas for lighting and environment that may prove interesting.

At left, is the second picture thrown to the wolves.

Advanced Breakpoints

Wednesday, October 12th, 2005

Chris Hanson discusses Xcode’s advanced breakpoints today.

One very important feature of the advanced breakpoints found within Xcode is the ability to cause something to happen in the debugger — play a sound, print some data, run some AppleScript or invoke a shell script — without interrupting the application being debugged beyond stopping it briefly to take whatever action is specified in the breakpoint.

For debugging stuff like drag-n-drop, mouse tracking, and other human-computer-interaction related functionality, being able to break, take action, and continue the application without de-activating the application or otherwise messing with the context of event processing is absolutely critical.

In modern applications, the challenges of debugging are often not about which line of code is broken, but a matter of figuring out which of the 100,000 executions of a particular line of code is broken. Worse, the line of code is generally going to be invoked along one of many paths, often further convoluted by the code’s presence within a class hierarchy such that invocation is determined by state or customization applied by subclasses.

printf style debugging is often derided as an amateurish approach to figuring out what is going on. And it does suck. But it is often the only way to really figure out what is going on.

Until now. I’m finding that I will configure a breakpoint to log-and-continue. Once I figure out what offensive value is at the root of a problem, I can easily configure the breakpoint to no longer continue and to only stop when that value is present.

End result; no more stop/print/continue by hand with the debugger constantly futzing with the event processing context of the application.

Very, very useful.

CocoaHeads San Jose

Monday, October 10th, 2005

I will be speaking at the CocoaHeads meeting on Thursday evening at the Apple campus. In particular, I’ll be focusing on PyObjC, including integration with various Tiger specific technologies, some history, and a focus on live demonstrations of the technology.

It will be rather freeform in nature. If anyone has any particular area of interest related to Python, Cocoa, and PyObjC, let me know.


Tuesday, October 4th, 2005

The image on the right is a close up of the mount point at which the pitch antenna attaches to a Moog Etherwave Theremin Standard musical instrument.

I gave said instrument to my wife for her birthday. It is quite the amazingly cool bit of electronics. Not only is it one of the oldest electronic instrument designs, but it is the only electronic instrument played without touching the instrument.

(Or so they claim — that isn’t really true. I played with a video harp at CMU that was played without touching. But it was about 2 orders of magnitude more complex and not nearly such a package of silvery-black coolness.)


On the left is a picture of my wife playing the Theremin for the first time. Roger clearly digs the Theremin, too. He has discovered that if you sneak up on it, it’ll make some very weird low pitched “I see you!” noises. She is considering offering herself up as Theremin soloist for the Saratoga Community Band. Still a lot to learn about the instrument, but she is one of those rare people that can learn any instrument given a few weeks of practice.


I took a series of photos of the Theremin. It is quite the interesting piece of engineering. Elegantly looped volume control antenna and solidly straight pitch antenna.

The manual is thorough beyond the call of duty. Not only providing excellent setup instructions, but also providing you with hints as to how to “turbocharge” your Theremin. The main board has an edge connector through which a number of hack points are provided.

As well, the board has a slew of different tunable parameters (through potentiometers). This is both for the purposes of hack-a-bility and because the instrument’s tuning can be vastly altered by construction of the case, down to and including the type of paint and/or stain used on the wood.

Analog is cool.