I’m on this week’s Mac Developer Roundtable regarding source control management. This was the first podcast I’ve participated in, and I’m happy how it turned out. The fact that I don’t utterly hate my voice when I hear it is a little unexpected. Thanks for having me on Scotty.
I talk a bit about my experiences with Mercurial as well as some generic version control topics, like branching, merging, and tagging. I probably could have talked more about the advantages of Mercurial and distributed version control systems (DVCSs), but it was hard in such a short time.
I’m glad I was able to talk a bit about unconventional uses of DVCSs, such as managing Unix configuration files and using them to keep track of changes I make to Apple’s sample code. I’d like to elaborate more on these in a future post, but for now, enjoy the podcast.
Writing GUI applications in Objective-C is easy thanks to Cocoa. It takes care of a lot of mundane things like setting up the standard main function, running the event loop, and handling preferences. If you write a command line application in Objective-C, though, you don’t get very much help. You’ve got to remember to setup an NSAutoreleasePool (assuming you’re not using garbage collection) and parsing command line options is left up to you. This is unfortunate, as handling options “properly” is one of the more important aspects of a command line application. This means handling long options (those with a double dash) and short options (those with a single dash).
Thankfully, you do get some support for parsing command line options from the FreeBSD layer in the form of getopt_long(3). But using getopt_long is a bit of a pain: you’ve got to setup a structure of options, then repeatedly call it, followed by a switch statement. See the example in the man page. Yuck!
In order to simplify all aspects of writing command line applications I’ve written ddcli, a framework for writing command line applications in Objective-C, released under the MIT license, of course. The meat of it is an Objective-C wrapper around getopt_long that (ab)uses Key-Value Coding to simplify parsing options. But it also does things like setup the autorelease pool and provide handy wrappers around printf that work with the %@ format. Check out the extensive Doxygen documentation for examples and API reference. I think it makes writing command line applications a lot more painless.
Whether distributing Mac OS X software as a disk image (DMG) or a zip file is “better” (or “easier”) for the user is still an open debate. However, there’s one technical difference to be aware of: the permissions of the installed application are slightly different. They aren’t different enough to affect anything, but it is still interesting to know for Unix geeks like myself.
Not one to let sleeping dogs lie, I wanted to know why the MOSI pin was only being pulled down to 2.8 V with the 1.5K Ohm resistor on R6 in my previous post. The resulting schematic is this fairly simple transistor circuit:
Seeing schematics with transistors in them brings back a flood of memories to my college days when I was taking EE classes and I used to know how to do this stuff in my sleep. Unfortunately, that was about 15 years ago, and now a schematic like that looks like gibberish. It was bugging me that I used to be able to figure this stuff out, so I pulled out my old textbooks. Those were nearly as incomprehensible as the schematic, unfortunately.
Luckily we have teh internets these days, and I found instructions on transistor circuit analysis that I could actually understand on the website for EECS 312 at the University of Kansas. Kudos to Prof. Stiles for making this understandable. This transistor is in saturation mode, and I calculated the emitter voltage to be about 2.7 V. I measured the voltage drop to be 2.72 V with the scope, which you can see on the right side of the scope’s screen in this picture. It’s nice when theory and practice align. It’s even nicer when I don’t have to show my work.
In my post about the STK500 and USBtinyISP, I linked to a thread about how to fix a design error in version 2.0 of the USBtinyISP. It mentioned shorting out R6 and R7 to fix communications errors during programming. I did this, but I was still having trouble programming over ISP while I had the LEDs connected. bbum mentioned that he was able to program with LEDs attached, so I suspected something about my setup. At first, I thought it was specific to the STK500, but it turns out the problem was with the USBtinyISP itself. The STK500 just tweaked the right conditions to expose it.
The thread mentions shorting out R6 and R7, but that was in reference to the v2.0 schematic where R6 and R7 are in series with the MOSI and SCK signals. Unfortunately, the v2.0 circuit board has R6 and R4 mislabeled on the silkscreen: they’re swapped! So if you followed the instructions and shorted out what’s labeled as R6, you really shorted out R4. This not only doesn’t fix the MOSI signal, it also connects the red LED up to an I/O port without a current limiting resistor. Now you’ve got two problems.
The proper fix is to short out what’s labeled on the PCB as R4 and R7. Once I did this, it fixed my avrdude communications errors with LEDs connected. If you did short out what’s labeled as R6, I suggest you put a 1.5K Ohm resistor back to properly limit current through the red LED. Hopefully ladyada will update the official instructions about this, and even build a v2.1 version of the PCB without the 1.5K resistors on MOSI and SCK.
Here’s a picture of the final result. Read on for details and more pictures about the problem.
Reading Bill Bumgarner’s latest posts on Atmel AVRs got me interested in AVR development, again. I’ve done a fair amount of microcontroller hacking in the past, and I bought an STK500 when they went on sale last year for $50 (plus a free AVR Dragon). Unfortunately, I never even bothered to power it up! Reading his posts finally got me motivated to setup an AVR development environment on my Mac.
One downside to the STK500 is that it typically requires a serial port to program the chips. This is especially problematic for Macs, as they haven’t shipped with a serial port in a long time. Yeah, you can buy USB to RS-232 adapters, but that’s a bit clunky. The supported programming software (AVR Studio) only runs on Windows, as well.
One the upside, AVRs support low-voltage in-system programming (ISP) using a standard 6- or 10-pin header. The STK500 also has these headers, so theoretically any ISP programmer should work.
ISP programming is superior to programming over RS-232 since it’s much more versatile, anyways. AVR ISP doesn’t require a high voltage or sacrificing of any I/O pins, and you can put a 6-pin ISP header on your own custom hardware very easily. This allows you to reprogram your chips without having to pull them out and into a special-purpose programmer. So if I could get ISP and the STK500 to work together, this would be an ideal setup.
I couldn’t find a lot of information about using ISP programmers and the STK500 (most people probably just use the serial port), but it turns out, you can program chips on the STK500 over ISP, even on a Mac, just fine. Read on for the details.
As part of my Daring Furball project, I needed a LOLspeak translation dictionary. I’ve finally pushed out a 1.0 release and setup a project page. The dictionary itself is just a big YAML file. However, there’s Ruby code to translate whole strings as well as the text portions of an XML document. The Ruby code (which comes with the dictionary) is available as a gem under the lolspeak project. To install it, simply use the gem command:
% sudo gem install lolspeak
It’s pure Ruby code, so this should run on any Ruby-supported platform (though I’ve only tested on OS X and Linux). The main API you’ll use is the extension to the String class:
"Hi cat".to_lolspeak -> "oh hai kitteh"
Oh hai! I’ve been working an a rather unusual project, a website, actually: Daring Furball (http://daringfurball.org), a translation of John Gruber’s Daring Fireball into LOLspeak. It gets updated once an hour (no feed, yet). Read it and enjoy. Let’s hope Gruber keeps on using “jiminy” as I quite like the LOLspeak translation.
It all started about a month ago when I accidentally typed “daringfurball” into my browser. I got a nice chuckle and told my wife about it. Immediately, the topic of LOLcats came up. We make a daily routine of reading I Can Has Cheezburger? together at the end of the day to ease the stress, so this wasn’t a big stretch. From LOLcats, conversation veered towards LOLspeak, the language of the LOLcat. Then we got the idea. Wouldn’t it be cool to translate Daring Fireball into LOLspeak? OMGWTFBBQ!
This was also just before I was to give a presentation on Apple’s PubSub framework for PSIG. I thought it would be a cool demonstration to use PubSub to pull the DF feed, translate it to LOLspeak, and then regenerate the HTML. Sure enough, it made for a nice demo of PubSub and RubyCocoa. I chose Ruby due to it’s regular expressions and the Erubis templating engine. After the presentation, many PSIGers helped me with the Daring Furball logo. In all it was a lot of fun.
But the fun doesn’t stop there. I’m open sourcing the dictionary and the Ruby back-end and it’ll be available as a Ruby gem. I’ll talk more about that in a future article, though. kthxbye!
One of the new features of Objective-C 2.0 included with Leopard is fast enumeration. This is essentially new syntax to iterate collections using new for...in syntax:
NSArray *array = [NSArray arrayWithObjects:
@"One", @"Two", @"Three", @"Four", nil];
for (NSString *element in array) {
NSLog(@"element: %@", element);
}
The best part about this is that you can use this on your own collection classes by implementing the NSFastEnumeration protocol. This is quite similar to Ruby’s Enumerable module. You can loop through integers really easily in Ruby since Ruby’s Range class implements Enumerable:
#!/usr/bin/env ruby
(1..5).each { |i| puts i }
I thought this would be pretty cool to add to Objective-C, but it turned out to be more difficult than I thought.
The latest script I added to the dld-tools project (in my public Mercurial repositories) is called fswatch. The script, as of this writing, is available here. Click on “raw” to get a file you can save and run. Check the repository for newer updates.
fswatch is a Ruby script that uses the built-in RubyCocoa bridge to access the new File System Events (FSEvents) framework added in Leopard and watches for filesystem modifications while a command is run. Since FSEvents can efficiently watch a directory hierarchy, you can see what files a command touches or spews anywhere on the filesystem. One use case would be to see what a make install actually does. Here’s an example installing the GNU Hello program:
% sudo fswatch -o /tmp/hello-install.txt make install
% cat /tmp/hello-install.txt
/
tmp
/private/tmp/
.
hello-install.txt
/usr/local/bin/
.
hello
/usr/local/share/
.
info
/usr/local/share/info/
.
..
dir
hello.info
/usr/local/share/man/man1/
.
hello.1
