Borkware Miniblog

August 30, 2007

Saving my Beacon

Filed under: Random — Mark Dalrymple @ 8:28 pm

I have a love/hate relationship with the MacBook keyboard. I really like the feel, but when I come to the MacBook (personal machine) keyboard after using the MacBookPro (work machine) keyboard (which I like even better), I have a hard time adjusting. In short, my typing is utter and total crap because I hit the corner of keys, which register a keypress by feel, but it doesn’t actually engage the key switch. This makes me sad.

On a whim, I picked up the Mavis Beacon typing tutor thing at the apple store (after going there to caress an iPhone in person). It’s an old, cheesy program, and some of the “games” are embarrassingly awful, but after doing a couple of basic typing exercise, I have the MacBook keyboard “feel” back again, and my typing accuracy improves a whole bunch. Which makes me happy.

August 25, 2007

It pays to kiss-up

Filed under: Uncategorized — Mark Dalrymple @ 2:08 pm

Emperor Darth Jalkut of the Red-Sweater Empire recently plugged my humble miniblog. My feedburner reader stats went from 84 to 268 overnight. It took long enough to get my mom to subscribe 81 times, so it’s not her that’s doing it. So thanks to D.J. It pays to kiss-up to famous online personalities.

P.S. Mars Edit is still cool.

In praise of little command-line apps

Filed under: irc, programming — Mark Dalrymple @ 1:54 pm

Folks who have hung around with me know I’m an emacs weenie. It’s not that its necessarily the best tool in the known universe, but it’s what I’ve been using for 17+ years as a paid professional on a number of different platforms, and I’ve developed a number of workflow habits that give me the illusion of being productive.

Central to my daily workflow is having several shell buffers open in my emacs session. This means I can boing from a source file to a shell with a half dozen keystrokes.
One side effect of this is that I can create, use, then forget about little command-line programs extremely quickly. They become great little testbeds. No need to create an Xcode project, or create an Executable in an existing Xcode project. I understand that BBedit and Textmate let you run shells within the editor without any extra baggage, which is all kinds of awesome.

One day on the #macdev IRC channel, someone was complaining (gee, that never happen!) that they tried to NSLog a dictionary, and It Didn’t Work. Someone else, who is ordinarily always correct, suggested that NSLog might send -description to the first argument. I didn’t think so, but wasn’t sure enough to argue. So I hopped over to Terminal, made a little program, and tried it out. Turns out you get a compiler warning if you pass a non-NSString to NSLog, and then the program gets an exception when NSLog tries to send -length to the passed-in object.

Knowledge gained in under a minute.

And now I’ve burned an hour writing about it. Oh well. But I’m waiting on a flight, so it’s time better spent than reading yet another Lord Peter Wimsey novel.

Here’s the program:

#import <Foundation/Foundation.h>
 
/*
gcc -g -Wall -framework Foundation -o logger logger.m
*/
 
int main (void) {
    [[NSAutoreleasePool alloc] init];
    NSDictionary *arg = [NSDictionary dictionary];
 
    NSLog(arg);
 
    return (0);
 
} // main

And it took about a minute from initial question to the acquisition of knowledge, including fixing a syntax error. More sophisticated test programs may take longer, but usually not that much longer.

I do this kind of stuff when playing with a new Cocoa class, too. It’s much easier to cook up a little ad-hoc test case to verify my understanding of some aspect of NSWhatever than to try to scaffold something in a big application.

OK, so what are the important highlights of the code? The first interesting bit is the compile line I’ve got in the comment. Having a compile line in each source file makes it easy to find the file, copy out the compile line, paste it into a terminal and go. No need to modify a project or a central makefile (although those studlier than I with makefiles could make an implicit rule for *.m files, but I’ve already have enough scar tissue on my soul courtesy of make) This also makes it handy for folks who are looking at the code after you put it into a pastebin. No need for them to figure out how to run it. Just save the text, copy the command and then paste it into Terminal.

For folks not familiar with the gcc command, here are the moving parts:

  • gcc : run the C compiler. If you’re doing C++, use g++
  • -g : turn on debugging. You might need to run your program in the debugger.
  • -Wall : turn on a bunch of warnings. If your code has any warnings, don’t ask anyone for help until you fix those warnings. To do otherwise would be rude. Although it’s ok to ask for help if you’re having trouble figuring out what a warning means.
  • -framework Foundation : use the Foundation framework. This lets #import <Foundation/Foundation.h> work, and also satisfy the linker when you use Foundation functions and classes. If you’re using AppKit too, then use #import <Cocoa/Cocoa.h> in the code and -framework Cocoa on the command line.
  • -o logger : create an executable program called logger. If you omit this, the incredibly obvious name of a.out is picked by the compiler.
  • logger.m : the source file to compile.

After that comes the main() function. You don’t need to declare argc and argv if you’re not interested in the command line arguments. After that I usually make an autorelease pool, and then the stuff I want to test. main requries a return, so you gotta add one, or else the compiler will whine at you.

You may have noticed I didn’t use a template file with all this boilerplate stuff already filled out. It’s just a personal weirdism I guess. It takes me longer to find the file, edit the parts that change (whether to use Foundation, Cocoa, or neither; the file name; any additional complier flags like -D), and navigate around than it does to just blort out everything linearly. But I’m a very fast typer and don’t like to wait for personal pipeline stalls when having to make decisions.

Many of the examples in AMOSXP are like this — small stand-alone programs that explore one thing. I’m not sure which came first, doing all of the examples, or using small apps to test something I need to figure out. But no matter where it cam from, I’m a big fan of the technique.

August 24, 2007

ObPhotoAlbum

Filed under: Random — Mark Dalrymple @ 11:24 pm

I promise to keep the non-programming content to a minimum (I’m sure many folks tune right out when camera nerds start talking). But I figured I’d point folks to my photo album: http://picasaweb.google.com/borkwareLLC.

August 23, 2007

Book Mania

Filed under: amosxp, programming — Mark Dalrymple @ 11:38 pm

Thanks to Vinoodle for pointing me to Antonio Cangiano’s blog, and A preliminary review of three Cocoa and Objective-C related books., where he has some very kind words for AMOSXP.

One book I like to point folks to, particularly folks who already know how to program and/or already know C (which don’t always necessarily occur at the same time :-), is Andrew Duncan’s Objective-C Pocket Reference If you can find it, that is. I see with horror that it’s currently unavailable via Amazon and Barnes’N’Ignoble.

It’s a mercifully short book, especially compared with the giant C++/Java in a NutCaseShell books, and it hits the important goodies that Objective-C adds. It even talks about the extra syntax relating to Distributed Objects.

I also have to plug Learn Objective-C on the Macintosh (a.k.a. LoC), co-written with Scott Knaster. What many folks don’t know is that Scott’s early Macintosh books in the mid to late 80’s were some of my main inspirations for becoming a professional programmer, and a Mac programmer in particular. I pretty much owe my career, and my current gig at Google, to Scott. I had a chance to meet him at a Big Nerd Ranch course a couple of years ago, discovered he’s a really great guy, and eventually we ended up collaborating on LoC (oh man was that fun). I figured out what we were covering and blazed the main trails, and he made it understandable and fun to read.

If you’re already slinging bits and swizzling IMPs then LoC will be too basic for you. Otherwise, check out the sample chapter and see if it speaks to you. If you’re truly coming up from scratch, you might want to start out with Dave Mark’s Learn C on the Macintosh (LoC is designed to pick up where LearnC leaves off, and Dave was the editor for LoC), and there’s also Stephen Kochan’s Programming in Objective-C, which Antonio also reviews. (I liked it, but I’m a pretty nerdy bookworm.)

August 22, 2007

Movies as Bug Reports

Filed under: Random — Mark Dalrymple @ 12:06 am

Sometimes when I’m building a bug report for somebody, I’ll make a movie of the application misbehaving. A picture is a thousand words, so a movie is at least 15,000 words a second.

For instance, I saw some strange behavior in Mars Edit’s preview panel with a <pre> block. I could spend a chunk of time describing the behavior, and even then would probably omit some important piece of evidence. Instead, I sent This Movie on to the Red Sweater Empire. DCJ asked me to try some stuff, we narrowed it down to line break conversion, and I found a work-around by putting in a space character in the <pre> block.

Similarly, we have an internal tool at the GOOG which I had difficulty getting working. I made a quick movie of it not working, sent it on to the developer, and he said “huh. you’re doing everything right. Lemme go look for the problem.” Sure saved a lot of back and forth, and also saved a lot of wondering “Is this a PEBKAC problem?” (I’m the first to admit I do stupid stuff.)

Naturally, include a link to the movie in any bug report. Sending someone ten megabytes in an email without prior warning could be interpreted as rude.

There are a number of screenShotMovieMakers. I’ve used SnapzPro for years, and have certainly gotten my money’s worth.

August 20, 2007

Daring Fireball, the TV Show?

Filed under: Random — Mark Dalrymple @ 11:57 pm

http://video.google.com/videoplay?docid=4641800997253041180&q=macgruber

August 19, 2007

Objective-C is Stupid (but I still like it)

Filed under: irc, programming — Mark Dalrymple @ 6:47 pm

One of my guilty pleasures is hanging out on Mac programming IRC channels (#macsb and #macdev on irc.freenode.net) Occasionally an interesting discussion erupts over some esoteric topic, but for the most part it’s ordinary questions about the basics of Cocoa programming.

One misconception about Objective-C that comes up occasionally is the assumption that Objective-C does more than it does. In particular things like


“I compare two strings/objects/dictionaries with ==, and the test fails. Cocoa is broken!”
(quickly followed by the Mac sucks, Xcode blows goats, and so on)

or


“Can I concatenate two strings by using + ?”
(quickly followed by the Mac sucks, Xcode blows goats, ObjC2 should have gotten operator overloading, and so on)

Objective-C is a pretty old language, predating Java, Perl, Pythong, Ruby, and many of the modern features of C++. It is just C with a couple of extra knobs on it, with very little extra behavior added to the language. All of the magic is in the runtime which does message dispatching. There is no operator overloading in the language. Pretty much all the language lets you do is interact with integer and floating point values, and calculate addresses via pointers and offsets. In C and Objective-C, there is no implicit complex behavior hiding behind the operators.

Now, folks who come from VB (I presume), Java, scripting languages, and C++ expect things like the == operator to be an equality operator, knowing the contents of the objects being compared; or expect the + operator to be a concatenating operator, dynamically creating objects.

Think about what happens under the hood: comparing two strings compares each of the characters in the string (looping over the contents), or comparing two dictionaries would compare each of the elements in the dictionary (looping over the keys). Likewise, to concatenate two strings, you’ll probably be looping over the two, or allocating blocks and using a memcpy()-like operation. (and in general, using concatenation to build strings can bite you when you go to internationalize your application)

C and Objective-C don’t do anything that convenient. All == does is compare a small number of bytes for an address when dealing with pointers or an integer/float value. And when you come down to it, those are the same operation. In particular, no looping. All + does is add two values. In particular, no allocations.

So, when you’re dealing with Objective-C, and things don’t behave the way you think they should, consider what’s going on under the hood:

NSString *thing1 = ...;
NSString *thing2 = ...;
 
if (thing1 == thing2) {

This is just pure C right here (no @‘s or []‘s are involved, so the Objective-C part of the world doesn’t kick in. No ()‘s involved, so no function calls are happening. Therefore, only a small number of bytes are involved. Each string could be megabytes long, but the comparison will just be four bytes (eight bytes on a 64-bit system). So this is just testing whether one address is equal to another address. An “identity test”, vs a test for equivalency, which is what the programmer probably wanted in the first place. Assuming that the two strings are not pointing to the same @"literal NSString", these will have different addresses, and the comparison will be a false one. (it’s not my nose, it’s a false one)

Now this code:

if ([thing1 isEqualToString: thing2]) {

Does do an equivalency test. Since you’re actually invoking a method here, and methods are arbitrary code, this has the opportunity to loop through the strings and compare them character by character.

So the moral of this poorly-organized story? C is dumb about data. It only does a few blindingly simple things. Objective-C is a very thin layer on top of C, and adds nothing to the existing C syntax. If you’re getting unexpected results with the built-in operators, you’re probably assuming the base language is doing more than it should, and you should update your expectations appropriately.

And while I’m thinking about it, I’m quite glad Objective-C does not have operator overloading. The gotchas are just too subtle, and I don’t mind trading some extra typing or an explicit function or method call in exchange for not having to track down subtle changes in behavior when some class I’m using decides to overload an operator. Hint: in C++, how does operator&& change behavior when it’s overridden, vs the compiler default? You’d be surprised how many experienced C++ developers don’t know that bit of trivia.

If you really want operator overloading (it does make sense in some situations, like the canonical matrix libraries everyone seems to be writing, or at least using for examples of why overloading is a Good Thing), there’s always Objective-C++.

August 18, 2007

Rich Programmer Food Resources

Filed under: programming — Mark Dalrymple @ 5:07 pm

Steve Yegge has a posting about Rich Programmer Food, which boils down to “if you know how compilers work, you can become heap big powerful programmer.” (I find most of Steve’s non-fiction to be interesting reading. The fiction and allegories I can never read all the way through.)

I asked Steve if he had any particular resources to recommend, and he didn’t have a “go here for enlightenment” pointer (short of “write your own language, and you’ll eventually have to learn everything you need to know”), but here are some books and things that Steve and others have recommended to me. I have not read most of the books, so apologies if you get them and they end up sucking.

August 17, 2007

The tools behind the book

Filed under: amosxp — Mark Dalrymple @ 9:10 pm

A discussion on my Local Linux User’s Group‘s mailing list talks about Open Source tools used to write books.For the curious and/or terminally bored, here are the tools that were used to make AMOSXP:

Along with makefiles and perl scripts to hold everything together. It was a real PITA to get build and configured. But once that horror was dealt with, it’s a fun toolchain.

First Post!

Filed under: meta — Mark Dalrymple @ 7:41 pm

Greetings,

As annoyed as I get with blogs that devolve into the meta (look at my redesign! I just changed blog hosts!), I must consume the humble pie and say I’m moving the Borkware Miniblog to WordPress, mainly so I can use the most excellent Red Planet Mars Edit editor. Web forms just don’t do it for me any more. Hopefully just setting up a redirect from my previous blog location to this one will work correctly for both of my subscribers.

Theme: Shocking Blue Green. Get a free blog at WordPress.com

Follow

Get every new post delivered to your Inbox.