Marc Charbonneau’s Blog

If you’re an experienced Objective-C developer, chances are you’ve at least heard of spicing up your log statements with __FILE__ and __LINE__. Here’s one method I wrote last night that includes variable arguments similar to NSLog(). To use it, just stick this line in your prefix header file:

 #define DebugLog( s, ... ) NSLog( @"<%p %@:(%d)> %@", self, [[NSString stringWithUTF8String:__FILE__] lastPathComponent], __LINE__, [NSString stringWithFormat:(s), ##__VA_ARGS__] )

The great thing about the preprocessor #define is that you can build all sorts of things into the DebugLog() function. For example, you could set it up so that the code is only included when you define a variable like BETA_VERSION in your code, or you could send the message to a custom logging class that writes to your own log file or database.

Paul Kim:

Recently, Quentin Carnicelli of Rogue Amoeba asked if there were NSResponder methods that you could hook your “OK” and “Cancel” buttons to to dismiss a modal panel (or sheet). As far as I knew there wasn’t but, gosh darnit, that would be a useful thing to have.

To clarify what I’m talking about here, when you run your own modal window or sheet with “OK” and “Cancel” buttons (or some equivalents), you end up hooking those up to methods that dismiss the window/sheet, stop the modal session and return some code (either one for confirmation or cancellation). Most of the time, you end up writing the exact same code. It’s glue code that shouldn’t have to be written.

Jeff Johnson:

With STABS, you could build the release version of your app with debugging symbols, make a copy of the executable MyApp.app/Contents/MacOS/MyApp to keep, strip the executable for shipping, and then use the unstripped executable for symbolizing crash reports by giving a space-separated list of stack trace addresses to the command-line tool atos. Unfortunately, atos cannot currently serve this purpose with DWARF. Unlike STABS, DWARF does not include the debugging symbols in the executable itself but merely includes references to the intermediate object files, which do contain debugging symbols. You can usually find these .o files in a sub-directory of the build/MyApp.build directory. If you delete the object files after building with dwarf, you won’t be able to step through your app’s code. (With stabs, the object files are refuse.) You also won’t be able to step through the code if you strip debugging symbols from your app, even if you keep the object files, because the references to the object files will be gone from the executable.

Mike Ash:

Ultimately I think the trend is bad. Code signing itself is a neutral technology, but it gives incredible power to the system vendor, and that power is just waiting to be exercised and abused. I believe that the iPhone is serving as a testbed to see how users and developers will react to an environment with ubiquitous code signing and control. If it goes well I think we can expect to see our desktop Macs gradually move in this direction as well. Judging by how badly Apple’s developer servers were flattened during the SDK release it seems like there’s no way it won’t go well.

Great writeup from Daniel Jalkut on examining crash logs with the atos command line tool:

Many developers seem to think that gathering useful crash logs requires shipping a symbol-laden application, but aren’t willing to do so. The fact is, you can have the best of both worlds by shipping a symbol-stripped version of your application, but keeping a symbol-laden version on-hand for the developer’s convenience.

What am I getting at? Apple offers a tool called “atos”, which makes it relatively easy to map an address from a symbol-stripped application to a name in a symbol-laden version of that same application. As long as the two applications were built with the same sources and using the same build options, the addresses are bound to match up. It’s just the symbols that are “stripped” from the shipping application.

Mac OS X 10.5 Leopard: the Ars Technica review:

DTrace and Xray invite good questions. “How many files does my application open on launch?” “How many times is a particular function called?” “What does the memory usage of my application look like over time?” DTrace and Xray make the previously daunting task of answering these questions almost trivial and (dare I say it) fun. I can’t imagine any Mac developer seeing Xray and not instantly longing to sic it on his application.

A Quick Objective-C 2.0 Tutorial:

There’s a lot more ground to cover, but this should give you a good start. We can look at more advanced topics in future tutorials. The 64-bit runtime has some features that the 32-bit version does not, such as the ability to synthesize instance variables. All of the hardware Apple currently ships is 64-bit, but we’re a ways off from 64-bit being a majority of the installed base.

Remember that all of the new features in Objective-C 2.0 are optional. Aside from some lower-level runtime functions and hacks, anything that was valid code in Objective 1.x is valid in 2.0, as well.

Get rid of your code with Leopard:

I’ve been using Leopard for the last few months, and I thought I’d post a partial list of new and improved APIs which may be of interest to Cocoa application developers. I’m going to classify these in terms of what you can do with them, rather than by class-name or other such relatively obscure aspect, and I’ll include some screenshots where appropriate. Please feel free to add your own observations via the comments. I’ll stick roughly to the order used in the AppKit and Foundation release notes, which you should also read if you’re serious about getting the skinny on what’s new in Leopard.