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.

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.

I’ve been having a redraw problem on Safari 2. The only solution I’d found so far that worked for me (found here) is to resize the window by 1 pixel and then resize it back. “Not pretty, but it works.”

This is also working for me:

awesomeness = 0;
safari2ForceRedraw = function() {
	if (awesomeness++ % 2) {
		jQuery('body').css('background', 'url(blank.gif) repeat');
	}
	else {
		jQuery('body').css('background', 'url(blank2.gif) repeat');
	}
}

Basically set the body (or some smaller element if you can get away with it) background to a copy of itself. I used jQuery but I’m guessing it’s not a critical part of this working.

It is critically important that you name the toggle variable “awesomeness.” ‘Cause that’s what Safari 2 is. And there’s more of it every time you call the function.

We use modified hosts and httpd.conf files to develop locally: we can use nice urls like http://project.dev. Here is the abbreviated tale, in stack format, of trying to get IE in Parallels to load pages served from the self-same MacBook running OS X and apache. I will be parachuting in with only a flint, a knife, and NO ADMIN PRIVILEGES on the Windows side. Let’s get going.

- set up Parallels to test web pages on Win IE
  - change /WINDOWS/system32/drivers/etc/hosts to talk to the Mac side
  - don’t have admin privileges on Windows side
    - attempt to write file from Mac side
    - can’t write to file: Tiger’s built-in NTFS driver is read-only
      - MacFUSE + a FUSE NTFS driver can do it
        - install MacFUSE
        - install Fink, configure
        - attempt to install ntfs-3g
        - Fink complains about missing files
          - fiddle with Fink for a while, get it the files it’s missing
        - Fink complains, “Can’t resolve dependency “gcc4.0 (>= 4.0.1-5363)” for package “fuse-0.4.0-3″ (no matching packages/versions found)”
          - download update to Mac Developer Tools …

Around now I think, wait … wasn’t all this just to write to one bloody file? Anyway, this part takes a while. I eat a live scorpion to maintain my energy.

          - install dev. tools
        - Fink agrees to install ntfs-3g (yay!)
      - follow rest of instructions on mounting the ntfs drive
    - edit hosts file (it works!)
  - attempt to hit the Mac’s apache from IE on Windows in Parallels …. FAIL.
    - iterate over combinations of hosts files, local IP addresses, loopback addresses, Parallels network configurations … each time:
      - shut down windows
      - wait for the Parallels VM to stop
      - mount the ntfs volume (eventually wrote a script* for this)
      - drill down to the hosts file
      - edit the file
      - unmount the ntfs volume
      - boot windows
      - (click through 20 superfluous notifications)
      - try combinations of network settings
      - NOTHING

I iterated on that about 20 times. Folks on the web who have done this have done it by hard-coding their machine’s IP address. I was being stubborn and wanted to avoid that if possible. It wasn’t. Eventually this did work, but yes, I had to hard-code my laptop’s IP address into windows’ hosts file, and ALSO add an entry for the IP in my mac’s httpd.conf file to make the nice URLs work.

This is a far from ideal solution in a world of cafés and DHCP. I hope, if you ever find yourself in this situation, you too can find your way back to civilization.