chanson

The time is upon us once again — WWDC time!

As I have the past few years, I'll be in San Francisco all week, staying at the Hotel Kabuki in Japantown.

And of course, I'll be around the conference all week — especially in the labs. Come by and say hi, and I'll be happy to help with any questions you have!

I'd like to make it to NSCoder Night tonight, but I just have too much else to do today — again.

I won't be seeing anyone at NSCoder Night next week, either, as I'll be in San Francisco for the Apple Worldwide Developers Conference! If you're attending, be sure to find me and say hi!

I'd like to make it to NSCoder Night tonight, but I just have too much else to do today. Hopefully I'll see everyone there next week!

The next CocoaHeads Silicon Valley meeting will be on Thursday, May 15, 2008 — that's tonight! — at 7:30 in the Garage 1 meeting room at Infinite Loop 4 on Apple's main campus. That's inside and upstairs at Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's main presentation is on the Best of Both Worlds — an introduction to Cocoa development by Scott Stevenson.

This talk is a combination of an introduction to Cocoa, as well as a series of advanced tips and tricks that even relatively experienced Mac programmers may not know about.

The idea here is that we want to give all of the people who are new to Mac and iPhone development a chance to get started, but we also want to do something special for our advanced programmers. So rather than choosing one, we're just going to go ahead and do both.

Joel Norvell will also be presenting on how to edit PDF forms using Cocoa — he's done a lot of work with PDFKit and Cocoa, and I'm looking forward to learning from him.

Thanks a ton to Scott Stevenson, Steve Zyszkiewicz, Michael Jurewitz and Joar Wingfors for organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

I'd like to make it to NSCoder Night tonight, but I won't be able to as I'll be looking at a new place. Wish me luck, and have fun everybody!

I've talked about the LLVM Compiler Infrastructure in the past, but what I haven't talked about yet is just how easy and quickly you can build it on your own Mac running Leopard! This is a great way to get into hacking on compiler lexical analyzers and parsers, code generators, optimizers, and so on.

What's more, you can build both LLVM and the new C front-end clang very easily and in five to ten minutes.

First, create a work area to check them out into, wherever you normally create your projects.

[~]% cd /Projects
[/Projects]% mkdir LLVM
[/Projects]% cd LLVM
[/Projects/LLVM]%

Then check out LLVM itself and clang from the LLVM Subversion repository.

[/Projects/LLVM]% svn checkout http://llvm.org/svn/llvm-project/llvm/trunk llvm
[/Projects/LLVM]% cd llvm/tools
[/Projects/LLVM/llvm/tools]% svn checkout http://llvm.org/svn/llvm-project/cfe/trunk clang
[/Projects/LLVM/llvm/tools]% cd ../..
[/Projects/LLVM]%

Then edit the PARALLEL_DIRS definition in llvm/tools/Makefile to tell it about clang. Just add clang onto the end, like this:

PARALLEL_DIRS := llvm-config  \
                 opt llvm-as llvm-dis \
                 llc llvm-ranlib llvm-ar llvm-nm \
                 llvm-ld llvm-prof llvm-link \
                 lli gccas gccld llvm-extract llvm-db \
                 bugpoint llvm-bcanalyzer llvm-stub llvmc2 \
                 clang

Now create a directory to build into, next to your llvm directory, and change into it.

[/Projects/LLVM]% mkdir build
[/Projects/LLVM]% cd build
[/Projects/LLVM/build]%

This is where you'll actually run configure. This will ensure your source tree isn't polluted with build products, and that everything stays self-contained while you hack.

[/Projects/LLVM/build]% ../llvm/configure --enable-targets=host-only
# lots of logging
[/Projects/LLVM/build]%

You'll note that above I passed an argument to configure. This ensures that LLVM is only built to target the architecture I'm running on, to speed up the build process; this is generally fine for simple front-end development.

Now, to build LLVM as well as clang all I have to do is invoke make. LLVM is set up to correctly do parallel builds, so I'll pass the number of CPUs I have in my machine via make -j 4.

[/Projects/LLVM/build]% make -j 4
# lots of logging
[/Projects/LLVM/build]%

That's it! LLVM is now (hopefully) successfully built. All of the pieces are in the build directory under Debug/bin and Debug/lib and so on; see the LLVM web site for details about what the various components are.

One thing that's nagged at me lately has been the series of applications I've seen lately with copyright statements that appear to be from the Bizarro universe. I don't mean that they have weird license restrictions; rather, they have a copyright statement in their standard About panel that's formatted strangely. It's a minor pet peeve to be sure, but it's a simple thing to get right and getting it wrong looks silly.

Note that the following is not legal advice on asserting or protecting your copyright — you'll have to go to a lawyer for that — it's just a suggestion on how to concisely format your statement that your work is covered under copyright.

In a Cocoa application, the standard About panel will show the copyright statement specified under the NSHumanReadableCopyright of its Info.plist file. This should generally be of the form

Copyright © «YEARS» «HOLDERS». All rights reserved.

where «YEARS» represents the individual year, set of years, or range of years during which the application was authored and «HOLDERS» represent the authors of the application.

Thus if I were to start writing an application in 2007 and finish it in 2008, I would put

Copyright © 2007–2008 Chris Hanson. All rights reserved.

in the NSHumanReadableCopyright key of its Info.plist file. (Yes, that's an en-dash between the years, option-hyphen gets you one.) It wouldn't have the year at the end, or random commas after things, or random abbreviations. Just one simple statement.

Someday I'll figure out how to add

Copyright © 2002–2008 Chris Hanson. All rights reserved.

to the bottom of my weblog, too. Hopefully in such a way that I can actually update it easily when the year rolls over…

The next CocoaHeads Silicon Valley meeting will be on Thursday, April 17, 2008 — that's tonight! — at 7:30 in the De Anza 3 auditorium at Apple. That's just inside the south side of De Anza 3, right across Mariani Avenue from Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's presentation is all about designing and implementing your human interface. User experience and human interface design are critical for Mac OS X software to get right. To that end, there's even going to be a UI makeover as Scott describes in his post on the meeting!

Thanks a ton to Scott Stevenson, Steve Zyszkiewicz, Michael Jurewitz and Joar Wingfors for organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

I love good fonts. It's one of the things that I enjoy most about Mac OS X — the font rendering is wonderful.

Lately for programming and Terminal use, I've used Inconsolata by Raph Levien. It's a very clean monospaced font that renders really well at 12 points and higher, and is perfectly usable for coding at that size. It avoids the Vera Sans Mono problems with too-thin horizontal lines at common sizes.

Tonight — thanks to Jens Alfke and his logo design for the Mercurial distributed SCM system — I've discovered the free fonts from Yanone, specifically Kaffeesatz and Tagesschrift. Kaffeesatz in particular is a pretty slick font; hopefully I can find a use for it in something.

Any other free & open font suggestions? Let me know in the comments. I can always use more great fonts.

The next CocoaHeads Silicon Valley meeting will be on Thursday, February 7, 2008 — that's tonight! — at 7:30 in the De Anza 3 auditorium at Apple. That's just inside the south side of De Anza 3, right across Mariani Avenue from Apple's Infinite Loop campus in Cupertino. See the web site for directions.

This month's presentation is by Scott Stevenson about Core Animation, one of the great new technologies available to Cocoa developers in Mac OS X 10.5 Leopard.

Thanks a ton to Scott Stevenson and Steve Zyszkiewicz for doing the organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion until it's time to go at 9:30. Often a subset of the meeting moves to BJ's Brewhouse in Cupertino, which is right in front of the Apple Infinite Loop campus on De Anza Boulevard.

A while back, I mentioned that launchd was pretty cool. But what’s so great about it?

Simply put, launchd is what makes it easy to get tasks launched on-demand on Mac OS X 10.4 and later. It obviates lots of different archaic Unix infrastructure — init.d, cron, inetd — in favor of a single self-consistent and easy to use mechanism. Dave Zarzycki’s post Where to begin? describes the launchd design philosophy in some depth.

Processes launched at startup on Mac OS X are managed by launchd. There’s no careful balancing of init.d or SystemStarter scripts on modern releases of the operating system. Instead, launchd jobs have property list entries in the LaunchAgents and LaunchDaemons directories in the system and local domains. Some specify that launchd should keep them alive indefinitely, others simply provide conditions under which they should be launched.

For instance, the standard finger daemon indicates that it should be run whenever something connects to the socket corresponding to the finger service; it doesn’t run all the time, nor does it rely upon a separate “network service daemon” to launch. Similarly, the Bluetooth daemon is only run only when a particular Mach port is connected to; it doesn’t need to be running all the time, and a framework interacting with it can easily just connect to it and start using it, without worrying about the mechanics of launching it, ensuring only one instance is running, and so on.

Where launchd really shines is in the level of integration it lets developers offer between frameworks and daemons or agents when it comes to managing shared state.

Let’s say you’re creating a framework that manages access to a device (or any other shared resource). Only one process should actually actually interact with the device at the IOKit level with the device itself at a time. And besides, you want to provide a nice high-level Cocoa API anyway. So you need to create some sort of background process — a daemon — to actually talk to the device, and a framework that can talk to the daemon on behalf of any number of applications.

The most straightforward way to do this is to put your daemon executable within your framework, and install your framework in /Library/Frameworks. Then you can install a property list describing when launchd should launch the daemon, and in what type of environment to launch it. Since everything is going to be local to a single machine, you can use a Unix-domain socket — which, if you don’t already know, is represented via a path in the filesystem — by describing it in the Sockets key in the property list. That way, any time the framework wants to communicate with the daemon, it can just connect to the socket at that path and it will have a channel.

(You can even use the SecureSocketWithKey option to have launchd generate the path for you, and pass it to all processes via the specified environment variable. See the ssh-agent property list for an example; it's how ssh-agent is launched on-demand in Leopard.)

Your framework and daemon can then use Distributed Objects over that socket (thanks to NSSocketPort) to communicate by sending standard Objective-C messages back and forth. Just be sure to support NSCoding for any objects they exchange, and to annotate your methods with oneway, bycopy, byref and so on as appropriate to keep communication efficient. The daemon can even distinguish between clients by keeping track of which socket it’s accepted their connection on.

Wait, though — how does the daemon actually get that Unix-domain socket if launchd is what’s actually listening on it? There’s a process that the daemon needs to go through when it first starts up called launchd check-in. This process lets launchd pass the daemon information from the property list that was used to start the daemon. You just have to use the launch_msg() API described in <launch.h> to send a LAUNCH_KEY_CHECKIN string:

- (void)checkInWithLaunchd {
    launch_data_t checkinRequest = launch_data_new_string(LAUNCH_KEY_CHECKIN);
    launch_data_t checkinResponse = launch_msg(checkinRequest);
    
    switch (launch_data_get_type(checkinResponse)) {
        // launchd will return an errno if an error occurs
        case LAUNCH_DATA_ERRNO: {
            int error = launch_data_get_errno(checkinResponse);

            // handle it
        }
        break;

        // launchd will return your job's dictionary for successful checkin
        case LAUNCH_DATA_DICTIONARY: {
            // The dictionary isn't an exact copy of your plist.
            // It has file descriptors substituted for socket descriptions,
            // Mach ports substituted for Mach port descriptions, and so on.
        }
        break;

        // launchd returned some other bad response
        default: {
            // handle it
        }
        break;
    }
    
    launch_data_free(checkinRequest);
    launch_data_free(checkinResponse);
}

The trick is that the dictionary given back by launchd upon check-in is not simply a literal copy of what’s specified in the job’s property list! Instead, where you had specified in the property list how you wanted launchd to listen on a socket, upon check-in launchd will actually pass the socket itself as a file descriptor. You can retrieve it easily using the launch_data_get_fd() function, accept the connection (on another socket), and continue listening.

For a bunch more detailed information on how to leverage launchd in your own designs, see the launchd(8) and launchd.plist(5) manual pages, as well as Tech Note TN2083: Daemons and Agents and the System Startup Programming Topics guide. There’s an example daemon called SampleD which illustrates how launchd check-in works, and of course you can browse the source code to launchd — it’s under the Apache License, Version 2.0 — at the launchd site on Mac OS forge.

The next CocoaHeads Silicon Valley meeting will be on Thursday, January 10, 2008 — that's tonight! — at 7:30 in the Garage 1 conference room at Apple. That's just upstairs from the Town Hall auditorium in Infinite Loop 4, right around the loop at Apple's campus in Cupertino. See the web site for directions.

This month's presentation is by Ted Bonkenburg of Google, who is going to be talking about the MacFUSE project for creating user-space filesystems for Mac OS X!

Thanks a ton to Scott Stevenson and Steve Zyszkiewicz for doing the organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion — especially at BJ's Brewhouse, which is right along De Anza Blvd. in front of Apple's Infinite Loop 1 headquarters building.

As seen on the LLVMdev mailing list: Jon Harrop, Fibonacci example in OCaml:

Here is a complete 104-line native code compiler for a tiny subset of OCaml that is expressive enough to compile an external Fibonacci program: [...]

The compiler is itself written in OCaml, of course; for those who don't know, OCaml or Objective Caml is an object-oriented dialect of Standard ML, a purely functional language.

Jon's name rang a bell because I just listened to the second of two podcasts from .NET Rocks on the F# functional programming language — Jon Harrop Makes Us F# and F# Moves Forward — that Microsoft will be including with future versions of VIsual Studio. F# is itself a derivative of OCaml, runs atop the .NET Common Language Runtime, and can interoperate with other code

F# is interesting because, due to its functional and side-effect-free nature, one can get a huge amount of parallelism out of straightforward code. (It's the lack of side effects that allow such analysis to be performed.) The Xbox Live matching service, for example, is using a TrueSkill engine developed in F# by Microsoft Research.

OCaml on LLVM is interesting in a lot of the same ways: You have a functional language that's very amenable to all sorts of analysis and optimization, and an abstract platform that can run on an extremely wide variety of systems very efficiently. It's really the best of both worlds, where you will be able to write the parts of your software that need to be highly parallel and mathematically rigorous in a language amenable to it, and interface that to the rest of your application in a very natural fashion.

It's great to see that Jon is enjoying exploring OCaml atop LLVM and I can't wait to see what kind of fun results!

This is just a gentle reminder that NSCoder Night is tonight, 7PM to 9PM!

NSCoder Night Silicon Valley is at Orchard Valley Coffee in Campbell, CA.

NSCoder Night Washington DC is at Panera Bread in Tyson's Corner.

And finally, cocoaCodingNight in St. Louis, Missouri is tonight at the Kaldi's Coffee in Kirkwood, MO from 4:30PM through 10PM. It's tonight rather than Thursday due to the Thanksgiving holiday.

If you're interested in hanging out, but can't make it in person, there's always IRC. Get the latest build of Colloquy and join channel #nscodernight on FreeNode.

This is just a gentle reminder that NSCoder Night is tonight, 7PM to 9PM!

NSCoder Night Silicon Valley is at Orchard Valley Coffee in Campbell, CA.

NSCoder Night Washington DC is at Panera Bread in Tyson's Corner.

If you're interested in hanging out, but can't make it in person, there's always IRC. Get the latest build of Colloquy and join channel #nscodernight on FreeNode.

The next CocoaHeads Silicon Valley meeting will be on Thursday, November 8, 2007 — that's tonight! — at 7:30 in the Town Hall auditorium at Apple. That's just inside Infinite Loop 4, right around the loop at Apple's campus in Cupertino. See the web site for directions.

This month's presentation is by Deric Horn, Application Frameworks Evangelist at Apple. He's going to take us on a tour through what's new in Cocoa in Leopard!

Thanks a ton to Scott Stevenson and Steve Zyszkiewicz for doing the organizing!

In general, at a CocoaHeads meeting we do some introductions, have a presentation including Q&A time with the presenter, and then have an open Q&A and demo-your-cool-app period. After the meeting there's more independent mingling and discussion.

When we haven't had a presentation or two lined up, we've also had some great "unmeetings" (in the spirit of "unconferences") where we came up with an agenda for the core of the meeting on the fly by writing down topics and questions on our room's whiteboard and talking about each one of them for a few minutes. It worked really well.

Update: Every CocoaHeads gets bigger. Tonight's meeting has 59 people so far, which is nearly a 20% increase over last month's meeting!

This is just a gentle reminder that NSCoder Night is tonight, 7PM to 9PM!

NSCoder Night Silicon Valley is at Orchard Valley Coffee in Campbell, CA.

NSCoder Night Washington DC is at Panera Bread in Tyson's Corner.

If you're interested in hanging out, but can't make it in person, there's always IRC. Get the latest build of Colloquy and join channel #nscodernight on FreeNode.

This is just a gentle reminder that NSCoder Night starts tonight, 7PM to 9PM!

NSCoder Night Silicon Valley is at Orchard Valley Coffee in Campbell, CA.

NSCoder Night Washington DC is at Panera Bread in Tyson's Corner.

And, thanks to the magic of time zones, NSCoder Night Washington DC will actually be the first NSCoder Night get-together!

If you're interested in hanging out, but can't make it in person, there's always IRC. Get the latest build of Colloquy and join channel #nscodernight on FreeNode. (And also consider joining some of the other channels there, such as #macdev and #macsb, where you can meet other fellow Mac developers!)

One of the great new features in Leopard is a standard way of supporting source lists — those blue outline views with a gradient highlight, like in iTunes, that provide an interface to some collections of objects.

These have become quite common in a lot of applications since their introduction in iTunes, and everybody does them slightly differently. Now, though, there's a simple way for applications running on Leopard to get the source list look and feel almost for free!

There's a new property added to NSTableView called selection highlight style. There are currently two possible values for the highlight style: Normal, the default, which gets you the regular look and feel and selection highlight behavior, and source list, which gets you not just source list-style selection highlighting, but also gets you the proper background color — whether you're in the foreground or the background — and for outline views, will also get you the proper indentation per level, the row height, and inter-cell spacing.

You can even set this property directly on your table or outline view in Interface Builder 3!

Of course, the obvious next question is "How do I get the small-caps look for section headers like in iTunes, Mail, and the Finder?" It's pretty simple! There are just a couple of methods you'll need to implement in your NSOutlineView delegate as described by Jim Puls in this message to the cocoa-dev list on October 26; conceptually, all you need to do is tell the outline view that your header items are group items — another new feature in Leopard — and then, when the cell containing them is displayed, adjust their string to be all-caps.

I've been toying with this idea for a while now, and now that Leopard is coming out, it's finally time to make it happen! I call it NSCoder Night! (Major thanks to Scott Stevenson for coming up with the name!) Here's the inaugural announcement:

NSCoder Night Silicon Valley will be having its inaugural get-together between 7:00 and 9:00 PM on October 30, 2007 — next Tuesday night — at Orchard Valley Coffee in Campbell, CA. From then on, we'll be getting together there every Tuesday!

What's the point? To get together with other folks who are also writing Cocoa code for Mac OS X, of course! There's no formal structure, which is why I described it as a "get-together" rather than a meeting. There's no need to RSVP, either; just show up if you like, or don't if you can't make it. Just bring your brain, laptop, and enthusiasm, pick up one of the tasty drinks available at Orchard Valley Coffee, and have a great time!

Why did I pick Orchard Valley Coffee for the inaugural Silicon Valley get-together? I first went there one afternoon during a little vacation I took after WWDC, and I found it a nice, large, relaxing place. It has wireless connectivity, reasonable hours, plenty of room, and great drinks, and it's also quite accessible since it's right in the heart of downtown Campbell.

So come on down, say hi, and see just how much fun it is to hang out and hack for a couple hours!

Want to hold your own NSCoder Night? Just let me know — here, on the NSCoder Night web site, or via email — and I'll post the announcement. Hopefully we'll have get-togethers across the world, even in places where there's not yet a CocoaHeads chapter.

What's the difference between NSCoder Night and CocoaHeads? CocoaHeads is a once-a-month user group meeting, typically with presentations and demos. NSCoder Night is a weekly get-together, a time to talk to your fellow hackers, to get help with issues you're bumping into, to show off cool tricks, and to actually have some time specifically set aside for your side projects.