njr 3.0

Pester 1.1b5 is out. If you’re wondering where betas 1–4 went, they were released privately…in 2003. Looking back at my weblog posts from May 2003, I see my comment about my parents “finally finishing up renovations on their house in Boston”—four years later, they’re still living in a single room of that house, though they continue to make steady progress on fixing the disaster left by their contractors.

For various reasons I didn’t pick Pester back up until this weekend, because NSDateFormatter broke natural language date parsing for Pester 1.0 in Leopard. Pester 1.0–1.1b4 ran on Mac OS X 10.1 or later; Pester 1.1b5 requires Mac OS X 10.4 or later. It was a bit sad to rip out painstakingly developed workarounds for old Cocoa date parsing bugs, but good to see that the new ICU-based formatters basically work, even if they completely lack any natural language parsing ability.

In an effort to get something usable on Leopard released, this version has some features disabled because they aren’t stable enough yet (QuickTime playback, speech), don’t work at all (dock bouncing) or are untested (wake from sleep). The user interface is still mostly what I came up with back in November 2002 (wow, Jaguar really was that ugly).

Among the changes that aren’t from 2003 are my first use of Sparkle:

Subsequent updates should therefore be simple.

Back to the reason for this update: NSDateFormatter in pre-10.4 mode used to understand “tomorrow”; in Leopard, it doesn’t, despite being documented as doing so.
There seems to be a severe lack of open source libraries for natural language date parsing—all I found was chronic (Ruby, English only); jchronic (Java port of chronic, English only) and Date::Manip (Perl, multilanguage).

I chose Date::Manip.

Yes, this means Pester now embeds a Perl interpreter.

Perl’s embedding API is interesting, but it works, and aside from the memory usage, nobody has to know. I don’t actually have non-English parsing in this version yet, because I ran into some weird bugs in Date::Manip; I’ve emailed the author but haven’t heard back yet.

I’m otherwise in the middle of the final work for my PhD, so I can’t guarantee 1.1 final will come out soon, but I think it’ll be less than 4 years!

10:45 PM | Computing, macOS
3 Comments

Onne Gorter’s AntiRSI is a Mac OS X application which reminds you to take periodic breaks from typing. Along with my beloved IBM model M15 keyboard, it’s essential to my getting any work done at all.

However, AntiRSI had some problems. The animated progress bar displayed during breaks sucked CPU like crazy, causing problems if I was watching a video at the time. Breaks kept getting prematurely reset because AntiRSI thought I was typing when it was a program like VLC calling UpdateSystemActivity, trying to avoid triggering the screensaver. Finally, the break window was just plain ugly—look at those poorly antialiased corners.

The last problem was more of a missing feature. While programming, I spend enough time thinking that I’m generally pain-free even if I work all day; unfortunately, debugging, writing and system administration can be much more typing-intensive, so I have to limit my daily typing time in aggregate, but AntiRSI didn’t keep track of it.

Over the past few years I’ve fixed these issues, and since my previous emails offering patches have gone unanswered, thought the result might be useful to others: download AntiRSI 1.4njr2 if you’re interested.

Some screenshots:

If you have a Mac and don’t like AntiRSI, try Time Out: it’s much more customizable, but takes over the entire screen, making it unusable for me. According to a VersionTracker review, it also hogs CPU during breaks.

For Windows and X11, check out Workrave; it’s great, includes a session timer and even comes with network support if you use multiple computers.

10:33 PM | Computing, macOS
2 Comments

While taking a break to work on ICeCoffEE today, I discovered an annoying internationalization bug.

First, some background. Since version 1.4, ICeCoffEE has let you hide items in contextual Services menus. Peter Hosey covers the feature nicely here.

Service menu items can be localized, like almost everything else in Mac OS X. The service provider apps include one or more language translations for their item names. The user configures a list of languages in order of preference in the International System Preferences. And the service-invoking application—the one from which you pull down or pop up the Services menu—also has a list of languages in which its user interface is localized.

Mac OS X makes the (sensible) choice that the service-invoking application’s user interface language dictates the language of all text in that application. But the fact that we’re dealing with ordered lists of languages, rather than individual languages, makes things a bit more complicated. Let’s take an example:

Your user interface language preferences are, in order, Japanese, German and English.

(Those also happen to be the languages I understand in ascending order of proficiency, with a gigantic gap between Japanese and German.)

Service menu item A has Japanese, German and English localizations. Item B has only German and English.

Say the app you’re running has only an English localization. Items A and B both appear in English.

What if your app has a Japanese localization? Item A appears in Japanese, but item B appears in German, even if the app has no German localization.

I’m guessing (have not completely verified) that OS X picks a list of potential service menu item languages by looking at the user’s preferred language list, starting with the user interface language of the current application.

What’s the bug? ICeCoffEE’s configuration sheet is hosted in System Preferences. When looking for a list of filter-able services, ICeCoffEE asks System Preferences for its Services menu and saves your choices according to the displayed item text. See for yourself:

% defaults read net.sabi.icecoffee ICServiceOptions
{
    ChineseTextConverter = {ICServiceHidden = 1; }; 
    "CocoaMySQL-SBG" = {ICServiceHidden = 1; }; 
    "Define in OmniDictionary" = {ICServiceHidden = 1; }; 
[...]

I did this because it seemed to be a WYSIWYG method of filtering, but it means that the user interface language of System Preferences influences what service names you see. If an item is also localized in a different language, it won’t get hidden.

I’ve never received a report of this bug. However, if it affects you, I can suggest two workarounds.

1. Edit the preferences property list yourself. The format is pretty simple, but I don’t recommend this. If you break it, you get to keep both pieces.
2. For every user interface language you use, launch System Preferences with that language at the top of the preferred list, and select the localized service names for that language in ICeCoffEE’s preferences. This assumes, of course, that System Preferences is localized in every language for which a service item you want to hide is localized. At worst, you will end up with something like this, where ICeCoffEE’s interface is in German and the service names are in Japanese:

   

   (Sharp-eyed people may notice two changes in the screenshot above, which hint at features coming in ICeCoffEE 1.5 :-)

I plan to fix the bug by doing something like option 2, adding the text of every available service menu item localization to the ignore list. It makes things more complicated because I currently store hidden services hierarchically, such that if you disable the submenu, everything inside it goes away; however, it’s possible that different localizations of service names will have different submenu structures. (Yuck.) This method also breaks if a newer version of an application adds a service name localization, but simply opening and closing the ICeCoffEE configuration sheet should fix that problem.

There are other ways I could handle this. I could store the bits used to define a service (NSMessage, NSPortName, etc.) but that would mean a lot more work to do when filtering the service list without scanning the disk as Service Scrubber does. Or I could canonicalize to English before filtering, which conflicts with applications that have no English localization, or applications like Monolingual which delete localizations—although deleting English is often unsafe because it’s the ultimate “fallback” language.

10:35 PM | Computing, macOS
No Comments

These days nearly 100% of my iPod listening is podcasts, and iTunes’ iPod-syncing podcast support is decent but lacking in a few areas.

One issue that bugs me is that, after connecting my iPod, I must update podcasts then update the iPod again in order for the already-listened episodes to disappear from the iPod. While the play counts update on the first, automatic iPod sync, the associated action (removing the corresponding episodes) doesn’t happen until you do another podcast update.

Another issue is the update timeout—after a few days if you haven’t played an episode of a podcast, it’ll stop updating. For people like my father who abandon their iPod for months at a time (hi, Dad!) it is a great bandwidth-conserving idea, but for me, with video podcasts and a non-video iPod, I like to accumulate episodes to watch when I’m exercising at home.

One of Doug’s AppleScripts for iTunes handily solves the second issue, and I’ve written a script to deal with the first. iTunes doesn’t let you query its iPod update status, so I instead wait for iTunes to unmount the iPod. I found this script which periodically checks the iPod disk space usage, but it fails for me, probably because iSync takes a long time to often do nothing.

Embedding this bash script into AppleScript was a real pain, what with do shell script‘s many and varied limitations, as I had to remove line breaks, indentation, my use of extended globs and even the while loop, because iTunes failed to finish updating the iPod while the script was executing. I think I will be checking out the newly revived PyOSA so I can do all this in Python instead.

Download the AppleScript, unzip it and place it in ~/Library/iTunes/Scripts.

(Note: this script is only tested on my Mac with my 3G FireWire-connected iPod; it definitely won’t work if you have iPod disk mode turned on, and may not work on other configurations.)

8:37 PM | Computing, macOS
2 Comments

So Illinois is mandating carbon monoxide detector/alarms in residences as of January 1. Today I decided to buy one. I wanted to get a combination smoke/CO detector, that way I wouldn’t need to change two batteries. Sounds easy, doesn’t it?

Let’s see, this one is on clearance because its battery lasts 2 weeks.

This one seems to give a lot of false alarms, and has a rather humorous review attached.

Reviewer: A Kitchen & Housewares enthusiast
This is not and I repeat is not a good alarm. There is one alarm light and you can hardly tell which one is sounding. It looks as if the specs are lying to me and I hate lies. Also the battery died after 6-8 months. The low battery alert is loud and chirps so anoyingly. I also noticed that the alarm sounds a loud shrieking alarm when it sounds. I will return this alarm. Never again will I trust in First Alert!

It also makes me wish I never meet a “kitchen and housewares enthusiast” in person.

This one goes off when you try to use an infrared remote control. The detector goes in the hallway behind my stereo, so that one’s out.

Finally, I give up on Amazon.com and do a Google search. I eventually stumble upon the Firex 12000, which has such useful features as a mute button that actually mutes for longer than you hold it down, an alarm that starts out quiet, a battery that’s easy to replace, and an industrial design that looks vaguely like someone cared. It’s AC/DC so I don’t have to replace batteries every 6 months, and even communicates over the power line with other units of its type. I read prior ones have freaked out after 4–6 years, but I plan to be gone by then.

A bonus review (for a CO-only alarm). The username is a nice touch.

4:43 PM | Web
3 Comments