Archive for the 'Mac OS X' Category

Now that Snow Leopard has shipped, the Blocks Programming Topics is available from developer.apple.com. Go have a read; it is a great primer for Blocks.

This post is focused solely on the core syntax of Blocks; declaring a block and calling a block.

Blocks are closures for C.

That is, a block is an anonymous inline collection of code that (Note: lexical scope means function or method or {}-surrounded collection of statements:

• has a typed argument list just like a function
• has an inferred or declared return type
• can capture state from the lexical scope within which it is defined
• can optionally modify the state of the lexical scope
• can share the potential for modification with other blocks defined within the same lexical scope
• can continue to share and modify state defined within the lexical scope [the stack frame] after the lexical scope [the stack frame] has been destroyed

Blocks is available in GCC and Clang as shipped with the Snow Leopard Xcode developer tools. The Blocks runtime is open source and can be found within LLVM’s compiler-rt subproject repository. Blocks have also been presented to the C standards working group as N1370: Apple’s Extensions to C (which also includes Garbage Collection).

As Objective-C and C++ are both derived from C, Blocks are designed to work fine with all three languages. Thus, the syntax reflects this goal.

A block is introduced using the ^ — the caret — character. The ^ was chosen as it had no unary form (and C++ couldn’t operator overload it).

For the purposes of an excruciatingly simple example, how about a block that multiplies two numbers?

Read the rest of this entry »

I recently picked up an ExpressCard/34 SD reader along with a Transcend 16GB SDHC card. The reader was to ease the transfer of photos from a digital camera and the high-cap SDHC card ensures I can take plenty of photos without shuffling about cards.

With the recent announcement of SD-slot-ness MacBook Pros (drool) that can boot from the SD slot, it made me wonder if a previous generation MacBook Pro could do so, too.

And it can! Which isn’t totally surprising. SD ExpressCard readers effectively act like USB drives and most (all?? I don’t know) Intel macs can boot from USB devices.

On the click through is instructions for formatting an SD car correctly and slapping down a bootable image.

Given the relatively low prices of SD cards, I’m making a habit of carrying around a “rescue card”. Tiny enough to not be noticeable, can be reformatted to use as photo-space trivially, one hell of a lot of tougher than optical media, and will prove to be indispensable if I ever need it.


Read the rest of this entry »

Out of the blue, I received a tweet from Steven Blackford:

@bbum Wanted to say thanks the old BackSpace Module LizardView. Still using it after all these years on all my NeXT systems.

Wow. That took me back nearly 20 years! From the moment I started writing Objective-C code on a NeXT in 1989, I have taken a break every couple of years to write a screensaver or five. They have always been fairly simple, always geometric in nature, and generally with a bit of fractally goodness.

At left is a screenshot of LizardView. It was one of the first screensavers I wrote for the NeXT. Fortunately, Steven still had the source for LizardView (I likely still do, too, on one of the optical discs in my garage) and it took me about 10 minutes to port it to Mac OS X Leopard.

Blast from the past.

If you’d like to experience this awzzum zele-bra-shun of k0l0rfull moiré patterns, I dropped Lizard.saver.zip on friday.com.

Funny story; in about 1996 or 97, I found myself at a rather random (and not that terribly good) rave like party in St. Louis, MO. There was a video projector that was running some “rave animations” loop. Lizard was used throughout as 5 or so second interstitial between different animation sequences!

Consider the two images at right. Neat images. Nothing spectacular, but special to my family in that they tell a story of part of an adventure to Bean Hollow State Beach (an awesome beach near Pescadero, CA).

And I would have neither those two pictures are a slew of others from the same trip if I hadn’t had CardRaider. Entirely due to PEBKAC (i.e. bbum was a dumbass), I reformatted the compact flash card after downloading only half the images — downloading just the images from the first beach we went to.

Now, fortunately, “reformatting” a compact flash card does very little other than mark the space as free for a variety of reasons that are quite interesting but more than I’ll reiterate here (including that the flash filesystem tends to be a lot less “chatty” than, say, a hard drive with log files, caches, VM, and the like).

End result? $20 and a short download later my photos were recovered via CardRaider .

Not much to say about the product. I have no knowledge about the competitors. CardRaider seemed highly ranked on various review sites and a search of weblogs revealed other folk who lost images for less stupid reasons than me who were quite happy.

It just worked.

And it just worked again. My wife has been dragging around a camera full of photos for over a year now. For whatever reason, all the normal means of downloading the photos didn’t work — i/o errors or some such nonsense.

CardRaider had no problem finding all the photos, including a couple that had been deleted that were save-worthy, and downloading them, apparently intact.

The source code for AutoZone, the Objective-C Garbage Collector found in Mac OS X Leopard, is now available. It has been released under the Apache v2 license.

This is the same collector that is found in Mac OS X Leopard 10.5.3 (the collector was not updated as a part of 10.5.4 or 10.5.5).

The garbage collector is not limited to Objective-C. It is actually a fairly generic scanning, conservative, generational, multi-threaded, language agnostic, collector. The implementation has certainly been tested and optimized with Mac OS X based applications.

Notably, MacRuby uses AutoZone to offer a common GC implementation across object graphs that span Ruby and Objective-C.

When analyzing an Objective-C application with Dtrace, one big challenge is how to introspect any objective-c objects that are passed as parameters into the various trace points.

While you can use the Objective-C provider (documented on the dtrace man page) to trace particular methods of specific classes, it doesn’t really help for actually introspecting an instance or class.

By “introspecting”, I mean “printing out the damned class name”, for example.

Full monty on the click through.

Read the rest of this entry »

Jim Correia asked on cocoa-dev:

Can you offer any advice for the times when I must write my own accessor, but want it to have similar behaviors to the autogenerated accessor? In particular, I’m thinking about the default atomic behavior. Is this simply wrapping the work in a @synchronized(self) block? Something else?

First, some context. Jim is referring to Objective-C 2.0′s properties and, more specifically, to the behavior of methods automatically synthesized by the compiler.

By default, synthesized accessors are atomic. Atomic does not mean thread safe.

Read the rest of this entry »

Update: CocoaHacks was quite a bit of fun. Not only did I demonstrate the rather silly little hack, but I ran it fully garbage collected. With one simple change (that should be in the next release), the MacFUSE framework works just fine with Garbage Collection enabled!

The best compliment came from Amit Singh; something along the lines of “That is absolutely the strangest filesystem I have seen.”

In any case, my little hack repository has been updated to be GC only. retain/release/autorelease/dealloc are dead to me (in this project, anyway).

If you want to build MacFUSE with GC enabled, simply set Objective-C Garbage Collection to “Supported” in Xcode in the MacFUSE framework project’s build settings.

At left, is a screenshot of the Finder browsing the Objective-C classes active in the runtime of a little Cocoa app that I wrote this evening.

The little app is called RuntimeFS and it contains a simple bit of code that traipses through the Objective-C runtime and collects information about the Objective-C classes encountered. This information is then barfed up by the elegantly simple delegate like API required by MacFuse to create a filesystem.

Let me restate that: MacFuse kicks ass. The Objective-C API is trivially easy to use. Trivially easy. I implemented this little hack in less than two hours, not having looked at the MacFuse API before. Nor did I read the docs; just looked at this example and one header file. I have implemented filesystems in a couple of different languages. Filesystems are hard. Or was. Not anymore.

I dropped the source code in the “Silly” directory of my public SVN repository.

Because, really, this is quite a silly hack. And hack it is — it doesn’t crash, but that is about all the quality assurance analysis I have done.

Free as in “MIT License” free. Have fun. I’m accepting patches, of course.

Future Stuff

If I were to go anywhere with this, the first thing I would do would be to move the subclasses into a subdirectory and then add other subdirectories to contain additional data.

Specifically, I would add directories like -1- Instance Variables, -2- Class Methods, -3- Instance Methods, -4- Subclasses, -5- Documentation (or something), etc…

The naming convention serves two purposes. First, it sorts nice like. Secondly, the names are invalid as class names and, thus, it makes handling the metadata vs. class directories trivially easy while also eliminating potential namespace conflicts.

In Leopard, Apple added a new tool to the developer tool suite called Instruments. It is a timeline based debugging and performance analysis tool. With a full suite of tools to analyze all kinds of dimensions of performance, correlating all data onto a timeline that can be inspected and navigated at will. And it remembers prior runs so you can compare results before and after changes.

And it fully consumes dtrace.

Clicking through the screenshot at right will show a run of Instruments with a single analysis instrument active.

I created a custom instrument that encapsulates the dtrace script I discussed in Objective-C: Using dtrace to trace messages-to-nil.

I ran the resulting instrument against TextEdit.

What can’t be conveyed by that screenshot is exactly how “live” the data can be examined. You can click and drag on the timeline to select a subset of the run, details of the selected instrument are shown in the table in bottom right, and any given row can be selected to show the backtrace active at the time the sample was taken.

I didn’t want to clutter up the screenshot with lots of data and, thus, didn’t demonstrate the awesomeness that is being able to relate data across multiple instruments, correlated by time.

That’ll be in the next Mac OS X / Software related post.

Click on through for an explanation with screenshots as to exactly how to convert the dtrace script to an instrument.

Read the rest of this entry »

Update: There are [at least] two different Objective-C messagers. objc_msgSend() and objc_msgSend_stret(). All of what is written here applies to both however objc_msgSend_stret() is the problematic one when it comes to messages to nil; it is the one used to return structures and, thus, the one that does not necessarily guarantee a zero return.

In my last post on the subject, Adrian Milliner posted a short dtrace script that would log the backtrace for all invocations of objc_msgSend where the first paramater — the target — was nil.

The script is as follows:

pid$1::objc_msgSend:entry
/arg0==0/
{
  ustack();
}

Once saved to a file (in this case objc-nil-trace.d, the trace can be applied to any running Cocoa process via:

sudo dtrace -s objc-nil-trace.d <pid>

The <pid> argument should, obviously, be the process ID of the process to be traced.

It works well enough and is certainly faster than a conditional breakpoint in GDB (likely, orders of magnitude faster), but it is far from a complete solution.

Read the rest of this entry »