Vincent Gable

As I have written before, the best way to convert a FourCharCode to an NSString* for NSLog()ing is to use the NSFileTypeForHFSTypeCode() function. But for the life of me I can’t remember that name, even though I use it about once a month. It’s too long, and it has too little to do with what I’m using it for.

So I have added the line:
#define FourCharCode2NSString(err) NSFileTypeForHFSTypeCode(err)
To my prefix-files, because I can remember FourCharCode2NSString().

The only time you should call ever call -dealloc in Objective-C is on the last line of your own -dealloc method. This call should be [super dealloc];. The proper way to dispose of an object is to send it a -release message — -dealloc will then be called if appropriate.

Now when I was first learning Cocoa, I sometimes disposed of objects by calling -dealloc directly. This caused all sorts of problems. Truth be known, if I’ve been messing with several object’s -dealloc methods, I’ll sometimes dyslex out and type dealloc when I mean release, just because it’s more fresh in my head. This is very rare, but it has happened once, and will happen again. I’m fallible like that. Murphy’s law tells us that I won’t catch it every time.

So I humbly propose that GCC should warn you if you use -dealloc any way other then calling [super dealloc]; on the last line of your own -dealloc methods.

I tried using an AMWorkflowView in a project, but when I ran it, I would crash with the following printed to the console:

*** Terminating app due to uncaught exception ‘NSInvalidUnarchiveOperationException’, reason: ‘*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (AMWorkflowView)’

It turns out I just forgot to include Automator.framework in my project!

It turns out that you also have to include Automator.framework to use any OSAScriptView objects.

I hope this helps someone who googles the error message :-).

There are a lot of problems that are, in theory, incredibly difficult - but because the difficult cases are very rare and rather contrived, they’re actually very easy to solve. Two examples of this that I find particularly interesting are both NP complete. Type checking in Haskell is one of them: in fact, the general type inference in Haskell is worse that NP complete: the type validation is NP-complete; type inference is NP-hard. But on real code, it’s effectively approximately linear. The other one is a logic problem called 3-SAT. I once attended a great talk by a guy named Daniel Jackson, talking about a formal specification language he’d designed called Alloy. Alloy reduces its specification checking to 3-SAT. Dan explained this saying: “The bad news is, analyzing Alloy specifications is 3-SAT, so it’s exponential and NP-complete. But the good news is that analyzing Alloy specifications is 3-SAT, so we can solve it really quickly

–Mark Chu-Carroll (aka MarkCC

The value stored under the NSApplicationName key of the result of [[NSWorkspace sharedWorkspace] activeApplication] is not the always the name the user knows the application by. Worse, it’s not always the same as the name for the application that other APIs expect or return. Even fullPathForApplication: in NSWorkspace sometimes won’t recognize it!

The problem stems from the fact that there are at least five application names floating around, at least in concept: (1) the file name the Finder sees, which in the case of an application package is the package (bundle) name; (2) the name of the executable inside the package, (3) the long name used in many places for display purposes only; (4) the short name used as the application menu title and in a few other places where a long name won’t fit for display purposes; and (5) the process name of a running application. They aren’t always the same, especially in Microsoft and Adobe products.

–From an informative message by Bill Cheeseman.

So instead of relying on NSApplicationName I now use -[[NSFileManager defaultManager] displayNameAtPath:] then strip off the filename extension. This should give exactly the filename the user sees. Every time.


NSDictionary *appInfo = [[NSWorkspace sharedWorkspace] activeApplication];
NSString *appPath = [appInfo objectForKey:@”NSApplicationPath”];
NSString *name = [[[NSFileManager defaultManager] displayNameAtPath:appPath] stringByDeletingPathExtension];

And of course, you really should be using bundle identifiers, instead of names, to identify an application. Unfortunately, a very few applications are not bundles. (For example, Microsoft stuff prior to Office 2008), so it might be necessary to fall back on using a name to locate them in a path-independent way.

Creating a custom CFBundleName in an application’s info.plist file seems to confuse NSApplicationName. For this reason I don’t think setting it is a good idea.

Epic Fail.

The PC version is awful too.

Facebook’s “People You May Know” feature shows you a few links to profiles of people you … well, may know. Put another way it’s a feature that
shows you people that all your friends know who you are not friends with. There aren’t pleasant names for these kinds of people.

Facebook is a spiteful conniving bitch

It continues to put my ex in the “people you may know” section.
You fuckin’ dirty backstabbing whore, facebook, I’ll kill you. Just keep rubbing that shit in, I’ll fucking kill you.

–some bitter guy.

Applying the ‘The Security Mindset’ can keep you from implementing a similar feature.

Today, most people I see making phone calls use cellphones. As near as I can tell, every time they call someone they know, they do it using their phone’s address book, instead of keying in their a ten-digit “telephone number”. It’s pretty obvious why. Nobody wants to have to memorize ten-digit numbers. And we think of people by their name, not some number.

This was not something that was hard to predict. Rolodexes have been in every office for decades, because people want to look up people by name, not number. Only recently has software supplanted them.

I was very surprised when I found this unknown invention from the late 1930’s

A NEW desk telephone directory not only finds the number you want but actually dials it for you. All you have to do is slide the knob on the face of the device, called an Auto Dial, to the name you want, then press the small lever at the foot of the machine. When the lever returns to its normal position, in five or six seconds, your call is made and you pick up the phone.

The Auto Dial was invented by a German before (World War II). The only sample in (America) is owned by Alfred Altman, President of the National Dairymen Association. The machine can handle any 50 telephone numbers desired by the user, and changes can be made at will.

The signals can be made up of any number of letters and digits, according to the system used in the local exchange. The regular hand dial on the telephone can be used in the ordinary way when the automatic device has been attached.

What an improvement over memorizing and/or dialing a number! We all have these devices built into our cellphones today. Frighteningly, the original appears easier to use then my cellphone’s “Address Book”.

So why didn’t this invention catch on half a century ago, not just a decade ago? I don’t know. I can only speculate, and I don’t think there is value in writing uninformed guesses down. But understanding why the Auto Dial was never popular is probably very instructive.

Technology improves at an overwhelming pace. The prospect of exponential growth has some people making fantastic predictions. Eg. “In 15 years, life expectancies will start rising faster than we age”.

I’m a big believer in the power of human invention. But I stumbled upon a somewhat sobering magazine article a few days ago.
CAN WE CRASH THE DEADLY FLAME BARRIER? (Oct, 1955)

Fly a plane fast enough and friction will melt it. Can we “put out the fire?”

As near as I can tell, the answer is “no”. In fact, it is my understanding that maximum airspeed has declined over the years. For example, the absolute air-speed record, 2,194 MPH, was set in 1976 with a currently retired aircraft. In 1976, we came up against the heat barrier, and could not break it. Since then, we have also retired the only two models of supersonic transport aircraft to see active service. The minimum time to cross the Atlantic is higher today then 20 years ago.

Now it’s certainly true that miles per gallon of fuel, and speed / gallon, have increased since 1976. This is almost certainly of more practical importance to the world. But I think it’s worth noting an example of a purly-technological dimension that has regressed with time. Not everything in technology “doubles every two years“.

And unfortunately, open source just isn’t a very good strategy for fixing ugly.

–Hank Williams.