Mischievous Ramblings II

Printing 2 of X: Renaming (a lot of) Color Profiles on the Mac

With paper comes profiles.  With sample packs of paper come LOTS of profiles.  Profiles which invariably have unpleasant names, like "HFAPhoto_CanPro1000_PK_HahnemuehlePhotoSilkBaryta310" which neither rolls trippingly off the tongue nor makes it easy to pick "Hahnemuehle Fine Art Photo Silk Baryta 310 for the Canon PRO-1000" off of a menu.

Renaming the files is easy using Better Finder Rename, a mac utility I've been using for at least a decade.  It brings a step-by-step interface to simple and complex renaming of multiple files.  Well worth it.

But renaming the profiles isn't as simple as renaming the files.  ColorSync utility will let you do it, and there is a script provided to do the renames, but renaming dozens of profiles at once is a pain.  To use ColorSync directly, just double-click on the profile file, and then in ColorSync click on the 'dscm' Apple multi-localized description strings field if present and edit it, or click on the 'desc' field and edit it.  So far as I can tell, the 'dscm' field will take priority if it is present.  If you prefer, there is a 'Rename' script in the 'ColorSync' portion of the menubar script menu, which you turn on using the 'Preferences...' menu item of the 'Script Editor' app in the Utilities folder of the Applications folder.  But using either to rename a bunch of profiles remains a big pain.

So I wrote a shell script which renames profiles to their base filename.  It's crude and simple, and will probably break for other people, but here it is:

---

#!/bin/bash

for file in ./H*
do
    BASENAME="sips -s description '$(basename -s .icc $file)' '$file' "
    echo 'executing $BASENAME...'
    eval $BASENAME
done

---

Hope someone finds it useful.

I rename the files to roughly PaperManufacturer PaperName PaperWeight BlackType Printer, e.g. "Hahn Photo Pearl PK Canon PRO-1000" which still isn't a brilliant name to sing out at night, but at least tells me what I'm looking at.

Hilarious: Microsoft keeps it old-school with a pricey text adventure game

Microsoft keeps it old-school with a pricey text adventure game, Visual Studio 2010

Microsoft has jumped onto the free-to-play bandwagon with its latest game, a text-driven adventure called Visual Studio 2010. The innovative new game marries the traditional interactive fiction text adventure with its arcane commands and exploration with the free-form, open-ended gaming pioneered by the likes of SimCity.

There are two major modes to the game, a textual spell-casting game, and a more complex interactive puzzle mode.

Play starts with the spell game. The game has three difficulty modes. In the two easiest modes Visual Studio questers must cast spells to appease a malevolent gatekeeper known only as "the compiler," combining the text adventuring of Zork with the wizardy and magic of Loom. If the player's spell contains even a single faulty incantation, the compiler will respond with a torrent of abuse and spells of its own; the player must piece together clues contained within compiler's response to determine how they went wrong.

My Top 3 iPhone Programming Books

I learn by reading a lot of books, and working my way through several of them. I've got a bookshelf three feet wide completely full of iPhone development books, and I thought I'd put my top three up here.

1) Programming in Objective-C 2.0 by Stephen Kochan (Amazon Canada Link, Amazon US Link)  is the best book on Objective-C there is. If you are a language geek, or want to know as much as you can about Objective-C, this is the place to start.

2) Beginning iPhone 3 Development: Exploring the iPhone SDK by Jeff LaMarche and David Mark (Amazon Canada Link, Amazon US Link) is one of many books doing a survey of basic iPhone functionality and how you program it. I like it a lot. I worked through about 75% of the book and found it very enlightening as I was starting out.

3) The iPhone Developers Cookbook: Building Applications with iPhone 3.0 SDK by Erica Sadun (Amazon Canada Link, Amazon US Link) is a great reference resource as long as you get the second edition. Like most Cookbook titles it has wide ranging "recipes" that give you a good idea of where you're going. I use it as a reference and for occasional reading because the topics tend to be short and easily managed.

Objective-C: to dot, or not to dot, part deux

I've previously commented on the question of Objective-C dot notation.  After some additional thought and programming, I've got more commentary.

Assuming that all these lines occur inside a class implementation, consider the following assignments:

1) self.foo = somethingOrOther;

vs.

2) foo = somethingOrOther;

vs.

3) [self setFoo:somethingOrOther];

All are similar and would appear to be interchangeable.  But they're not.  And how they are not depends upon declarations elsewhere.  If foo has been declared (retain) in the interface declaration, 1) and 3) are distinctly different from 2).

The difference is that 1) & 3) may (depending upon the @property declaration in the @interface) retain or copy somethingOrOther while 2) will not.  IMO, this is a much bigger deal than whether 1) self.foo hides the explicit function call of 3) [self setFoo:...].

I digress...

Whenever we program with code written by others we are dependent upon the "kindness of strangers" -- we depend upon those other coders (often far away in time and in space) to behave according to some set of standards.  Despite years of wrangling over the minutiae of where braces go and whether tab characters are superior to space characters, what those standards are is largely less important than whether they are followed.  A mediocre standard followed religiously is better than a perfect standard used sporadically.  Standard ways of doing things mold your mental expectations, and you will see non-standard code as though it were standard code, opening the door to bugs which are difficult to find even though they are obvious.

Back to the three assignments...

Whether you believe in dot notation or not, all three of these things are basically similar, used for basically the same function (assignment to an ivar or instance variable), and they appear basically interchangeable.  The fact that they are not interchangeable is the same kind of problem as a poorly followed standard.

In a bunch of code, it's easy to see:

self.foo = someObject;

and

foo = someObject;

and

[self setFoo:someObject];

as the same thing.  One day you might sit down at the computer and be tired of writing 'self' and start using 2) instead of 1).  You should avoid this temptation.  It can lead to frustration if you don't remember that 1) & 3) use the property setter function and 2) does not.  And if you do remember that, and you take advantage of it, you face the risk that someone else will not (and that someone may be you in six months, or six days, or even six hours).

As I said, IMO this is a much bigger problem than the question of whether 1) or 3) is superior.

I recommend an iron-clad standard that you use one (and only one) of these constructs.  I don't care which one*. Or do not use the automatic generation of getters & setters (@property & @synthesize).

Just my toonie.

* I do note that using 2) means extra code everywhere you want to retain an object.  This has the advantage of explicitness -- you see the code when it is being used.  And the disadvantage of clutter -- there's extra "boilerplate" code around every assignment using retain -- which makes it harder to perceive the overall flow of the code.

XCode Error: dsymutil failed with exit code 10

I have been struggling for a while with what appears to be a systemic problem using XCode. Periodically, my projects will begin to display an error:
        ‘Command /Developer/usr/bin/dsymutil failed with exit code 10’
Once the error appears, it can sometimes be eliminated by some combination of:

• doing a clean build
• restarting XCode
• rebooting the computer
• reinstalling the developer tools

Sometimes, of course, it can’t be eliminated. As documented here and here, I found a workaround. But the problem recurs. Sometimes very quickly after implementing the workaround (which isn’t a real quick fix).

At the moment, I’m trying a full command-line uninstall of all developer tools to be followed by a re-install. Perhaps that will help. In the meantime, if anyone out there knows what’s going on here, I’d love to hear the cause and a solution.

The agony of agvtool, the ecstasy of XCode

OK, "agony" is a bit strong.

agvtool is Apple's generic versioning tool.  It can be used with XCode to automatically update build numbers and marketing version numbers within xcode projects.  It works well, except for the fact that it modifies your xcodeproj file.  If you're in XCode when you run agvtool, it asks you to reload your project file from disk.  It works, but it's annoying.  Especially when you hit command-R to run and then have to stop your executable because you need to reload your project file.

Turns out that you can get around this with a little bit of code.  Your build number is stored as XML under the key CFBundleVersion, while your marketing version is stored as XML under the key CFBundleShortVersionString.  Both are stored in the project info.plist file that XCode creates for you when you start a project (at least an iPhone project).  Because the info.plist file isn't part of the xcodeproj file, it doesn't require a reload when you modify it during a build sequence.

I wrote a little app that reads in the info.plist file (provided as a command-line argument), increments the CFBundleVersion, and writes the info.plist file back out.  Here's the code:

#import <Foundation/Foundation.h>

#define kCFBundleVersionKey @"CFBundleVersion"

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    NSString *filename = [[NSString alloc] initWithFormat:@"%s", argv[1]];
    NSDictionary *infoDictionary = [NSDictionary dictionaryWithContentsOfFile:filename];
    NSMutableDictionary *newDictionary = [infoDictionary mutableCopyWithZone:NULL];

    int cfBundleVersion = [(NSNumber *) [newDictionary valueForKey:kCFBundleVersionKey] intValue];
    ++cfBundleVersion;
    NSLog(@"new CFBundleVersion:%d", cfBundleVersion);
    [newDictionary setValue:[NSNumber numberWithInt:cfBundleVersion] forKey:kCFBundleVersionKey];

    [newDictionary writeToFile:filename atomically:YES];

    [pool drain];
    return 0;
}


Once you have this code compiled and put somewhere convenient (I used /usr/local/bin), you just add a new build phase to your target.  I used New Run Script Build Phase, and the script was just:

/usr/local/bin/versiontool Info.plist

Because I named my tool 'versiontool' and my info.plist file is named 'Info.plist' (duh).  YMMV.  If you have more than one plist file (like one for your full version and one for your lite version), just put two lines in the script and update them both.

Someday I may update this so it's smart enough to look for *.plist in the current directory, but for right now it's crude but effective.  Hope it helps someone out there.

Oh, and I plan to keep using agvtool for updating the marketing-version (1.01, etc.) manually.

Objective-C: to dot, or not to dot

There has been some discussion in the online Objective-C community about the propriety of using "dot notation" to access properties instead of getter/setter methods.  For those of you not up on the lingo and the language, Objective-C 1.0 had you use getter & setter methods to access object instance variables, so:

int foo = [someObject getFoo];
[someObject setFoo:newFooValue];

Objective-C 2.0 added properties, which are syntactic sugar in the compiler so that you can access these same getter/setter functions automatically by using the so-called "dot notation" which is commonly used in c and c++ to access members of structs (and therefore also members of classes, which are merely a special kind of struct). Like this:

int foo = someObject.foo
someObject.foo = newFooValue;

Clearly this newer syntax requires fewer square brackets and is more familiar to c/c++/c# programmers, but it also hides potential complexity. Is the code really just a memory access to a publicly available data member of the instance? Or is it a hidden method call of unknown complexity, possibly creating and tearing down multiple network connections in order to expend countless CPU cycles calculating an intermediate value?

The online discussion has been pretty civil as such things go.  Here's what I think: the dot notation is less annoying to read than the bracket notation.  That reflects my extensive background in c and c++ programming more than anything else.  Over time, as I do more and more Objective-C programming, I'll find the brackets less painful and will use them more often.

The concern about hidden complexity has a certain initial appeal: OMG! That variable access could be a network connection! Yeah, it could.  But in c++, the simple statement:

a = b + c

could be just as bad, because the '+' operator might be overloaded to do God knows what!

And it is always possible that you might assume a simple getter routine is just a getter routine even in bracket notation, only to discover that it, well, you know...

It's important to keep a little perspective here.  The person writing that code might have been an idiot.  That's always true, even when you're reading your own code.  But it might be a good idea to start out with the idea that they were reasonably smart and trying to do a reasonably good job.

And when that idea doesn't pan out, yeah, check to make sure that the getter and setter aren't accessing some server in Chelyabinsk every time you access a variable using dot notation :-).

update 20091009: I was working on an assignment for my iPhone Application Development class, and this came up.  Any construct that lets you write the following code must be considered eeevil:

CGPoint drawAt = CGPointMake((320 - [drawImage size].width)/2, (240 - drawImage.size.height)/2);

Compare the yellow highlighted code with the turquoise highlighted code: they are essentially the same, but I definitely prefer the turquoise, no matter how much detail is hidden in the [drawImage size] construct.  Ouch.

Alea Iacta Est, finale

Sorry for the delay in reporting...

On 2 September, I received an email containing the following:

We've reviewed Hero Roller and determined that we cannot post this version of your iPhone application to the App Store at this time because of inappropriate 'Keywords' used to identify your application.  We will not post applications that reference other applications in their search criteria. It would be appropriate to remove Dice Roller

But I cannot submit a new version because of an error.  Fortunately, on 16 September, Hero Roller was approved for sale!

So both the Lite and full versions of Hero Roller are now available on the App Store!  They are very specialized programs and I don't expect tremendous response, but I'll get around to posting some details to Hero forums wherever I can find them.

Hero Roller Lite

Hero Roller Full

Hero Roller FAQ

Expiration Date Fail

moar funny pictures

Stupid Documentation Tricks: Apple's "Using Subversion with Xcode 3 on Mac OS X Leopard"

Running the svnserve Server

If you've chosen to use the svnserve server over ssh, there isn't even a step two. The svnserve binary comes pre-installed on Leopard, and the ssh server (sshd) launches svnserve on demand, so svnserve doesn't need to run as a daemon. Therefore, as long as the repository is in place, and sshd is running on the server, svnserve will already accept connections. Skip ahead to the section, Using Subversion from Xcode to get started with your first project.  [emphasis mine]

Seems clear enough, doesn't it?  You're done.  You're ready.  Fire that puppy up and get started subverting!

Not so fast, though.  You can't actually connect to svn yet.  Let's enlarge the window on that document just a couple of lines or so....

Running the svnserve Server

If you've chosen to use the svnserve server over ssh, there isn't even a step two. The svnserve binary comes pre-installed on Leopard, and the ssh server (sshd) launches svnserve on demand, so svnserve doesn't need to run as a daemon. Therefore, as long as the repository is in place, and sshd is running on the server, svnserve will already accept connections. Skip ahead to the section, Using Subversion from Xcode to get started with your first project.

Note: To start sshd on the server, open System Preferences, select the Sharing icon and select the Remote Login checkbox. [emphasis mine]

To recap: '...there isn't even a step two'; 'Skip ahead to the section, Using Subversion from Xcode to get started...'; but make sure you do something else first!