saturn return to sender

Quick geeky public service announcement. PHP 5’s Exception objects have line number and file name fields which are automatically populated for you. Refer to this page for details.

Ok, cool, but the question is: do those fields correspond to the construction site or the throw site? Based on this little experiment:

try {
	$exception = new Exception('exception constructed on '.__LINE__);
	throw $exception;
}
catch (Exception $e) {
	echo $e->getMessage().', (internal line:'.$e->getLine().')';
}

… they appear to refer to the construction site. In this case, the line number in the message (which is produced by the __LINE__ magic constant at the point of construction) and the return value of getLine() (made however it is the exception facility determines the line number) is the same number.

At first blush, this behavior seems less useful to me than if line numbers and file names were attached to the throw site. That’s where the exception actually occurs. It may be constructed entirely elsewhere. Hmmm.

Anyway, I couldn’t find an answer out there right away, at least with the terms I used to ask The Great Oracle. So here ’tis.

Meanwhile, in other music-and-math news, this is pretty impressive: software that will extract individual notes from multitimbral performances. Hrmmm. I’m skeptical about how reliably it will work in practice, but I will believe it when I see it.

Also, who pronounces MIDI like “meaty?”

“Now, we can control the chords with our MEATY keyboard … nom nom nom …”

Maybe it’s just me, but I couldn’t figure out how to specify an itemIdentifier for a toolbar item in Interface Builder 3.0 (OS X 10.5 Leopard). So I didn’t know what to return from the toolbar’s delegate method toolbarSelectableItemIdentifiers to flag items as selectable. Nor could I just flag an item as selectable directly in IB. The default identifiers given to the items are GUIDs and completely meaningless. I’m guessing these are just oversights in the newly-minted IB. (Prior to Leopard you couldn’t define toolbars in IB at all.)

I also didn’t google any obvious hits on this topic, so here’s my community contribution for today. Specify view tags on your toolbar items in IB instead of identifiers. Then implement toolbarSelectableItemIdentifiers in your delegate to check for the tags you want.

- (NSArray*) toolbarSelectableItemIdentifiers: (NSToolbar *)toolbar
{
	// yarr. leopard be toyin' with me, yarr!
	static NSMutableArray* identifiers = nil;
	if (identifiers == nil) {
		NSArray* items = [toolbar items];
		identifiers = [[NSMutableArray alloc] init];
		for(NSToolbarItem* item in items) {
			if ([item tag] == 1 || [item tag] == 2) {
				[identifiers addObject:[item itemIdentifier]];
			}
		}
	}
	return identifiers;
}

I happened to have two toolbar items I wanted to be selectable, with tags 1 and 2. Modify to suit your needs …

The pirate-speak comment is of course critical to this method’s success.

Dipping my toes into the 3Trace project again … for future reference, (and because it’s weirdly hard to google this info) here’s my global-ignore setting in ~/.subversion/config:

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *~.nib *.pbxuser .xvpics build *.mode1 *.mode1v3

Stuff after .DS_Store is what I added. I think that’s what you want to keep svn from complaining about transient XCode/Infterface Builder files. According to the XCode docs, you might want to let .pbxuser files through. Will edit this if it turns out to be wrong.

(As an aside, there’s some discussion on Alex’s blog about iWork bundles and subversion. Apple blows away the .svn folder inside iWork document bundles when you save them, making them impossible/annoyingly hard to manage via subversion. I think I’m the only one who thinks they’re justified in doing that, even though I agree that it’s less than ideal behavior. =) )