Archives / Search ›

Pester 1.1b5 released

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!

3 comments on “Pester 1.1b5 released”

  1. 25 November 2007 | 12:15 AM

    Looking at the docs, I think it isn’t a bug—I think they removed the natural-language-parsing feature entirely from 10.4-style formatters.

    The Apple docs don’t say what “lenient” means, which is clearly a documentation bug, but the ICU docs do define it:

    With lenient interpretation, a date such as “February 942, 1996” will be treated as being equivalent to the 941st day after February 1, 1996. With strict interpretation, such dates will cause an error when computing time from the time field values representing the dates.

    That’s clearly not the same as the old allowsNaturalLanguage feature.

    I agree with you: the natural-language feature was cool, and should be restored—ideally, with a patch from Apple to ICU.

  2. 25 November 2007 | 3:12 AM

    You’re right, 10.4-style formatters have no natural language parsing ability because ICU doesn’t. But Pester 1.0 doesn’t use 10.4-style formatters; it uses 10.0-style, which Apple documents as continuing to work just as they did in 10.0 through 10.3.

    The exact same Pester 1.0 binary running on 10.4 and 10.5 has different behavior: on 10.4 it understands “tomorrow”, on 10.5 it understands “today” but not “tomorrow”. Formatters still default to the 10.0 style, even on code compiled on 10.5; you have to explicitly tell them to not be buggy.

    Thanks for the link on “lenient”; I had no idea what it actually did, but have got that flag set on all the formatters used for input. What Pester 1.1b5 actually does is try a series of ICU-based formatters for various styles before falling back on Date::Manip. There are some corner cases (try a time of “12a” or “12p”) where none of them get it right, which I’ll have to either hack into Date::Manip or special-case.

  3. 29 November 2007 | 7:39 PM

    I ran into this problem recently. I have a solution that is working for now but it’s probably not as robust. It has the benefit of being easy to implement so I figured I’d share.

Leave a reply