Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

The New York Times’ Executive Suite Blog says that The Worst Is Yet To Come: Anonymous Banker Weighs In On The Coming Credit Card Debacle.

I’ve been pondering this very topic for a while, and wonder what’s in store for all of us in the spring.

[Via Daring Fireball.]

Irrational Exuberance has An Epic Introduction to PyObjC and Cocoa. Skimming over it, it really does seem to start at the ground level — and that’s what I need. I have high hopes it will help me figure out PyObjC.

[Via PyObjC Development mailing list.]

While trying to troubleshoot what I’d done to mess up the Mercurial repositories managing my Drupal installations last weekend, I really would have liked a way to see what files had changes in specific revisions. Each revision to a Mercurial repository affects some files, of course, but it seems awfully hard to figure what files changed in that check-in.

I have since found a way to do that by customizing the output of Mercurial. To customize output, you can create templates on the command line (with --template) or for more powerful reformatting, create an output style file.

I struggled for a while to figure out how to use style files, and eventually came up with something that works for me so far.

Since I’ve installed Mercurial from Lee Cantey’s standard binary package for Mac OS X Leopard, I created the file “map-cmdline.changedfiles” at the “/Library/Python/2.5/site-packages/mercurial/templates” path. (Where you put the file may vary depending on where Mercurial is installed, and I’m sorry but I don’t know where it gets installed on other systems.) The contents of “map-cmdline.changedfiles” are below, along with my possibly inept description of what each line is doing:

# Get all of the files in the selected revision
# and stringify them, whatever that means
# but do not 'tabindent' or wrap them to 68/76 columns
# Without first setting changeset to the list of files
# you won't get output from subsequent lines
changeset = '{files|stringify}'
# List modified files, one per line
# preceded by M to mimic `hg status`
file = 'M {file}\n'
last_file = 'M {file}\n'
# List added files, one per line
# preceded by A to mimic `hg status`
file_add = 'A {file_add}\n'
last_file_add = 'A {file_add}\n'
# List deleted files, one per line
# preceded by ! to mimic `hg status`
file_del = '! {file_del}\n'
last_file_del = '! {file_del}\n'

I don’t know why the “map-cmdline.” portion of the filename is there, but as long as I have it, I can call the style file from the command line with what follows the period. So, I can call the style with “--style changedfiles” — and that tiny bit of voodoo seems reasonable enough to me. (The other styles in the directory above, many of which end in “.tmpl” extensions, seem related to the Mercurial Web server, hgweb. I tried, but I couldn’t use their names at the command line, with or without their extensions. Plus, their contents looked HTML-ish.)

With the “map-cmdline.changedfiles” style file saved in that location, I can call Mercurial’s “log” command:

$ hg log --style changedfiles -r tip

… which gives me a list of the files changed in the “tip” (or latest revision) of the repository. I could substitute in any revision identifier for “tip.”

I haven’t actually seen the “file_add” and “file_del” keywords in action; every time I’ve used this style file in the manner described, I’ve only seen files marked as “M” — even if I’m looking at a revision where new files were first checked into the repo. I’m confused by that, but I’m not going to let it sour my day at this point.

There might have been an easier way to do this but I didn’t find one last weekend. It took me some time to figure even this bit out, and I hope writing this post saves someone new to Mercurial from future frustration.

While you could clear the various LaunchServices databases by deleting files, I prefer to use a more targeted command line tool when possible. My assumption is that the command line tool is canonical and will therefore produce more reliable results.

In Mac OS X Tiger, you could clear the LaunchServices database using the following “lsregister” command:

$ /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/
Versions/Current/Support/lsregister -kill -r -domain system -domain local -domain user

But, in Leopard, the LaunchServices framework’s path has moved; it is now in the CoreServices framework bundle. You can find it with the “find” command:

$ find /System -name lsregister -type f -print 2>/dev/null
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/
Versions/A/Support/lsregister

Once you find it, you can get the usage statement for the “lsregister” command in Leopard, which will at least tell you what options it has:

$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/
Versions/A/Support/lsregister
lsregister: [OPTIONS] [ ... ]
[ -apps [,domain]... ]
[ -libs [,domain]... ]
[ -all [,domain]... ]
Paths are searched for applications to register with the Launch Service database.
Valid domains are "system", "local", "network" and "user". Domains can also
be specified using only the first letter.
-kill Reset the Launch Services database before doing anything else
-seed If database isn't seeded, scan default locations for applications and libraries to register
-lint Print information about plist errors while registering bundles
-convert Register apps found in older LS database files
-lazy n Sleep for n seconds before registering/scanning
-r Recursive directory scan, do not recurse into packages or invisible directories
-R Recursive directory scan, descending into packages and invisible directories
-f force-update registration even if mod date is unchanged
-u unregister instead of register
-v Display progress information
-dump Display full database contents after registration
-h Display this help

Note that if you’re having Launch Services-related problems in one user account but not another, you’ll likely want to start with the “user” domain. (It pays to understand the domain structure of Mac OS X, so that you only make changes where you need to.)

In my Mercurial-based workflow for updating Drupal sites, there is a sequence of commands I need whenever a new version of Drupal comes out. I have a hard time remembering the options for “tar” in this sequence — and my original source for the instructions differs from what I need to do on my Web host — so I need to help my memory. The tar command, as constructed below, places its output into the specified destination directory.

Here it is, with tar’s “--strip-path=1” and “-C” options:

$ cd path/to/repository/parent/directory
$ curl -O http://ftp.drupal.org/files/projects/drupal-5.12.tar.gz
$ tar --strip-path=1 -C drupal_source -zxv -f drupal-5.12.tar.gz

These are some really interesting predictions for the digital camera market of 2009. Although it’s supposed to be Nikon predictions, it touches upon other vendors, especially those in the DSLR space.

There is some important information in the Info.plist files contained in Mac OS X applications. But, some of that information isn’t really standardized — I’m looking at all of you, you crazy version number and vendor attributes (just the ones I'm interested in!). So, given that, how do you find them all to make comparisons between Apple and third-party apps?

Answer: You can use the “find” command to find all of the Info.plist files for applications in your /Applications directory.

$ find /Applications -name Info.plist -ipath /Applications/\*.app/Contents/Info.plist -depth 3 -print 2>/dev/null

Since that intentionally limits the depth traversal, you could modify it slightly to support finding Info.plists in your /Applications/Utilities directory, as well. However, I would say it’s less likely you’ll be dropping third-party applications in the Utilities directory, so you might not care.

Having once been a newsroom intern, I have a soft spot for newspapers and newspaper people. It’s a bit disheartening to see the scale of layoffs and buyouts at U.S. newspapers.

Even though some would newspapers are anachronistic or dinosaurs, this mashup still represents good people trying to do important work.

I was concerned when reading Kerberos: The Definitive Guide that Mac OS X clients bound to an Active Directory didn’t have an easy way to specify that their Kerberos tickets should work behind NAT. The option to obtain addressless tickets is defined in the krb5.conf file (or, for Mac OS X, the edu.mit.Kerberos.plist file) with:

noaddresses = true

… And it is not an option you can choose either in the Directory Utility GUI or the dsconfigad command line tool. This is important because addressless tickets don’t have IP addresses associated with them, and thus work in situations such as those where a client is behind NAT.

Before I submitted a feature request, though, I looked up the option in the krb5.conf man page on a Leopard system. I’m glad I did, because it says:

noaddresses

Setting this flag causes the initial Kerberos ticket to be addressless. The default for the flag is true.

Presumably, this documented default is applying on Leopard with Active Directory Kerberos. When I examined a TGT issued by a domain, I did not see any IP addresses associated with it, so the default does appear to be the case for me.

I am happy about a solution I just came up with to the problem of not being able to define an arbitrary set of dates as the recurrence pattern for an event in Microsoft Entourage 2008.

I wanted to enter an event that was split across two days, and wouldn’t have obviously fit any type of “every Wednesday” or “every second Thursday” pattern. The ideal way to handle this, I think, was available in the Steltor CorporateTime calendar I used to use: create an event and add arbitrary dates to it, so that each recurrence appeared as part of the series. You can’t do that in Entourage — or I’ve never found any trickery to allow it.

Luckily, however, the event’s start time and duration was the same on each of the two days, so I realized I didn’t need to make two different events for it. And, I only had two recurrences to deal with — if there’d been more, it’s unlikely they would have been evenly spaced.

I used my “Compare dates” AppleScript to determine how many days apart the two instances of this particular event were. I came up with 20. I entered that as the number of days between recurrences. I set the recurrence to end on the date after the last event.

The result? I got two events (and two events only), both on the days I intended, and they were linked as part of a recurrence pattern. Sweet. It’s the little victories, you know?