From the uncrustify website:

The goals of this project are simple: Create a highly configurable, easily modifiable source code beautifier.

Since Tony had provided nice Automator actions, I figured I’d take it for a spin. After a quick

brew install uncrustify

and a few minutes messing with Tony’s sample .uncrustify.cfg making my own, I was impressed.

While in Xcode 4 I used Tony’s Automator service to uncrustify the selected text (I select whole files at a time). However, I had to give up on Xcode 4 due to stability issues so found myself back in Xcode 3.2.x. While in Xcode 3 I decided to create a User Script for uncrustify, thinking it would be much faster to execute. So now I have a shell script execute uncrustify on the selection and replace the selection with the uncrustified result (stealing the uncrustify line from Tony’s Automator service). I also have this bound to cmd+option+ctrl+u.

#!/bin/sh
/usr/local/bin/uncrustify -l OC -q

Here’s the User Script setup:

Liar! Note that it says I’m using ‘g’ as the shortcut instead of ‘u’ like I said. I’m pushing the ‘u’ key but it’s bound to ‘g’ in the Dvorak keyboard layout.

I’m not sure if I’m early or late to the uncrustify party, but I’m happy to be here.

Oh, and if someone does know how to setup User Scripts in Xcode 4, do tell!

Wait, one more thing! I’m working on a project where my 6 lines of whitespace after each function body wasn’t appreciated (understandable, it’s not for everyone ). rooSwitch to the rescue! I already have profiles for slight differences in Xcode prefs, so I dropped my .uncrustify.cfg on each profile and am now switching that file with the slight difference for this project. Success.

1) update 6.7.06: there is no #1 – I just had this blatantly wrong – see comments. Thanks Jean-Francois.

<

p> Binding to a BOOL requires the result to be returned in an NSNumber. My isIndeterminate method, although backed by a simple BOOL, needed to be

- (NSNumber ) isIndeterminate
{
return [NSNumber numberWithBool:isIndeterminate];
}

- (void)setIsIndeteriminate:(NSNumber *)flag
{
[self willChangeValueForKey:@“isIndeteriminate”];
isIndeteriminate = [flag boolValue];
[self didChangeValueForKey:@“isIndeteriminate”];
}

Some other goodies:

• Accessorizer can create your accessor methods for you. This is a great tool that greatly speeds up a tedious task.

• Core Data can generate similar code for you. Go to your data model and right click on an entities attribute. You should see a “Copy Method Declarations to Clipboard” and a “Copy Method Implementations to Clipboard”. Core Data doesn’t need you to generate these. If you use the setValue:foo forKey:@“bar” syntax the correct things happen. However, it’s often nice to just say [obj setBar:foo];

NO is defined as:

define NO (BOOL)0

we have an issue. 0 is also ‘nil’. Just below the definition of NO we see nil:

define nil 0 /* id of Nil instance */

Since ‘nil’ has to be a valid NSNumber *, you are allowed to pass NO as a NSNumber * parameter. If object ‘foo’ has a method ’setBarOn’ with a declaration of

- (void) setBarOn:(NSNumber *)aBooleanAsANumber;
- (NSNumber *) barOn;

You need to make sure you never call that method with NO, as in:

[foo setBarOn:NO]; 

If you were to try to read the boolValue by hand you’d be OK. Calling ‘boolValue’ on a nil object seems to return 0, which is NO, so you wouldn’t notice the problem. The problem comes in when you use predicates.

I had a predicate that looked like:

“isBarOn == 0”

If you setBarOn:NO instead of setBarOn:[NSNumber numberWithBool:NO] the instance in question will not be returned by this predicate. Ouch. Fortunately if you were to look at the attribute that had been set to :NO you’ll see it reported as (null), which is a good hint your Boolean got set wrong.

I’m not sure how common this is or not, but it seemed worthy of pointing out. Hopefully it made some sense to someone.

The other funny thing about this is that if you try to use the name “isDeleted”, Xcode squawks up and makes it clear that “isDeleted” is a no no. See image of squawking:

I settled on “isProfileDeleted”. Redundant, but it works a heck of a lot better now (reads and writes!). Why the “name clash” code in Xcode isn’t catching “deleted” I don’t know.

I did some searching and couldn’t find a list of reserved words. If you know of one, please share.

I’m spending some time working on a new project (sorry, not quite ready to explain what it is) and have spent the time to write some unit tests[1]. The tests run in a script and one problem I had was that there seemed to be no way to debug the tests if things went wrong. I couldn’t even figure out how to show the NSLog calls that were surely being made. This drove me nuts. Then I found the little “show or hide build transcript” button under the normal ‘build’ view. This shows the build output as Xcode compiles the files as well as any shell scripts run during the build process. Showing the transcript showed me the NSLog’s I needed to see and all was well again.

It would be a lot nicer if I could step through the code when the unit tests ran. If anyone knows how to do this I’d greatly appreciate the knowledge.

[1] – thanks to http://developer.apple.com/documentation/DeveloperTools/Conceptual/UnitTesting/UnitTesting.html and http://www.supermegaultragroovy.com/Software%20Development/xcode_code_coverage_howto

- (id)propertyList

What does it do? To quote the docs:

Parses the receiver as a text representation of a property list, returning an NSString, NSData, NSArray, or NSDictionary object, according to the topmost element.

If you started staring at CFPropertyList(…) functions, just trying to figure out how to read a plist file, the ‘propertyList’ method of NSString is tums for your heart burn.

Also, I’m loving the developer doc’s new “hover over a method to see the short description” as pictured above. If you don’t see this, grab the March ADC Reference Library Update.

I’m still trying to figure out how I best work in Xcode. For most of rooVid Lite I was running in the “All-In-One” layout using Xcode’s editor. I’m now on the default layout + SubEthaEdit, but I’m guessing I’ll be back to “All-In-One” + Xcode’s editor before too long (it takes me a while to admit that the way I was previously working was a better way of working (for me) – I might be addicted to change). My biggest fear is that I’ll download and give every editor known to OS X a chance as my Xcode external editor.

defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions \
'{ "ORGANIZATIONNAME" = "YourCompanyName";}'

To change more of the template, find and edit the template file in “/Library/Application Support/Apple/Developer Tools/File Templates”

I’m a

foo
{
}

foo {
}

update after a nice nights sleep:
I haven’t felt this stupid in a while. The problem was that I was building and attempting to debug in the “Release” build configuration. Doh. Breakpoints don’t work when debugging release. I’m sure this burns a handful of people. Too bad Xcode couldn’t see me loading a release built binary into gdb and popup a nice “hey bozo, you sure?” message. Oh well, all is better now that I switched back to debug. I’m not sure how I switched to release to begin with. I have a separate sandbox for doing those tests.

[1] I guess I should be happy that NSLog is working

Longer version:
I recently added Growl support to my app. It was super easy. I snagged the Growl source, built the Growl.framework and followed the online dev docs for cocoa. Fifteen minutes later and I was done (seriously). Little did I know, I was being deceived. This morning I did a release build for the first time and ran into some issues. The first problem was easy, I wasn’t linking with Quicktime.framework. I’m not sure how debug builds got away with this, but oh well. The second issue was slightly more interesting. I got this error message from the linker:

/usr/bin/ld: warning ../build/Deployment/Growl.framework/Growl 
    cputype (18, architecture ppc) does not match cputype (7) 
    for specified -arch flag: i386 (file not loaded)

Wah!? I’m pretty sure I hadn’t built Growl or my app as a universal binary, but I double checked. Both project’s architectures were set to $(NATIVE_ARCH). I couldn’t figure it out.

After some grep’ing for i386 in my project directory I found my apps release configuration was being compiled for i386, regardless of the project settings shown in Xcode. I triple checked the xcode project settings for all configurations and even explicitly set ‘ppc’. Regardless of the setting, i386 was always in my .pbxproj file. What’s one to do? I closed my project in Xcode and removed the i386 by hand. Re-open in Xcode and all was well. My app linked as release with Growl just fine.

To confirm what I was seeing I created a new Cocoa application in Xcode. I confirmed the project settings for both release and debug were set to only build for $(NATIVE_ARCH) and did a release build. All went well. Now I checked the .app file in Finder and sure enough, it was built for Intel, PowerPC. Weird. Is this a bug? Is Apple trying to trick us into building new apps as universal binaries? My guess is it’s a bug, and potentially just a bug in my environment. I did a little digging, but couldn’t find anyone else complaining about this. Oh well, at least now I know.

update: Luis de la Rosa of WebnoteHappy fame was kind enough to try to reproduce this for me. His results were better. Although release was building Intel by default, the architecture setting for the project made it clear that that’s what was going on. When he unchecked i386 it stopped compiling for i386 (how nice). So, one has to assume it’s something in my environment somewhere causing this.