Perl and Python on Snow Leopard
John Gruber has some good information about the 64-bit versions of Perl and Python on Mac OS X 10.6. I think he’s mistaken about the AppleScript fragment, though. I don’t think it does what he expects on Mac OS X 10.5, either. As with most languages, “or” has low precedence in AppleScript, so his line was essentially saying if (_browser is not "Safari") or "WebKit" then. I think the most AppleScripty way to write this would be if _browser is not in {"Safari", "WebKit"} then.
6 Comments RSS · Twitter
[...] way than Gruber—I switched to a list, if theFoo is not in {"bar", "baz"}. (Update: Michael Tsai makes the argument, supported by actual Apple documentation, that what Gruber and I were doing shouldn’t really have [...]
"Once I got my first 10.6 bug report, this experience certainly led me to wonder if 10.6 was instead finally fixing a bug (flaky behavior that worked when it shouldn’t have)"
I believe this to be the correct interpretation.
"That’s not to say that it didn’t also *feel* like a regression in the OS when that bug report came in, but given my prior experience, it didn’t particularly surprise me, either."
Hey, thank the synecdoche of Sal for small favors. A compiler that intelligently notes bad code is a good thing.
I've got to say, I'm waiting on upgrading to SL until a couple of things I rely on get more compatiblized, but AppleScript/Automator seem like they've gotten among the biggest bumps in terms of shiny and useful stuff.
(Aside from AppleScript, I kinda feel like Apple should be paying us $29 each to deal with the SL carnage. The blood on the leopard's mouth is coming from breaking things in currently installed setups...)
[...] Original source : http://mjtsai.com/blog/2009/09/15/perl-and-python-… [...]
I am very worried about SL perl builds.
I have an extensive collection of my own modules which are large project efforts.
Most of these modules are 10k lines in length and have a few dozen functions each
on average.
Here is the first broken functionality that I have come across and it is a show stopper.
No longer can I call specific module functions without use'ing the module.
I.e. CGPW::ModuleX::functionAbc is errored as undefined.
These explicit calls are required to avoid use module connectivity loops, which I
cannot see going around as for any complex project such interconnectivity is
unavoidable.
I ran into a similar problem in one of my AppleScript applications, although I had previously experienced periodic “can’t make into a boolean” failures with that structure on certain OS versions, depending on what OS version I used when saving the app.
That statement “worked” fine on 10.3, 10.4, and 10.5 when I saved the app on 10.3 (yay Apple for not overwriting the Universal droplet when saving on 10.3), and it was fine on 10.5 when saving on 10.5, but the 10.5-saved version then generated the boolean error on 10.3 and 10.4. As a result, I had already slated the flaky statement for replacement by the is-not-in-list syntax in my next version. Once I got my first 10.6 bug report, this experience certainly led me to wonder if 10.6 was instead finally fixing a bug (flaky behavior that worked when it shouldn’t have). That’s not to say that it didn’t also *feel* like a regression in the OS when that bug report came in, but given my prior experience, it didn’t particularly surprise me, either.