hi. a while back i posted about an appscript CommandError timeout i
encounter at high command interaction counts. not surprisingly, the problem
(i'll reiterate the details below) still happens in 0.20.2. i'm wondering
if you (or any of the other appscript developers) have any thoughts about
this? it might be an apple events problem (eg,
http://db.tidbits.com/article/10643, except i was seeing the problem in 10.5
leopard and not just snow leopard), or a problem with my machine, but the
2^16 limit happens always, and sometimes the machine gets in a state where
it happens much sooner.
here are the details:
the behavior is an appscript.reference.CommandError timeout after some
number of appscript transactions. there seems to be a hard limit just
before 2**16 (65536) commands (actually, at 65529 commands, but i presume
the difference is accounted for by preliminary setup). the limit is
sometimes a little to a lot lower, even across separate python sessions.
occasionally the limit is as low as tens or hundreds of transactions, at
which point working with appscript is untenable and i need to reboot my
machine to clear it.
i only have one mac to test it on, so i haven't even confirmed it occurs for
anyone else. the machine is only a few months old, so doesn't have too much
cruft, and it happens in every python i've tried on the machine. (i've
reproduced the problem with the appscript 0.20.0 installed via easy_install
on the leopard system python 2.5.4, snow leopard system python 2.6.1, a 2.6
python built from scratch, etc; the machine is a 2.66 GHz macbook pro.)
i'd be very interested to hear whether it occurs for others, and to make it
easy for you to try:
def first_timeout():
"""Gratuitous itunes appscript reference cycle to elicit a timeout.
It usually happens on some systems after just about 2**16 (= 2**2**2**2)
interactions, and sometimes substantially before that."""
import appscript
import sys
itunes = appscript.app('itunes')
t = itunes.tracks[1]
count = 0
class PassedLimit(Exception): pass
try:
while True:
count += 1
if count % 1000 == 0:
sys.stderr.write("%i\n" % count)
if count > 65530:
sys.stderr.write("%i\n" % count)
elif count > 66000:
raise PassedLimit
x = t.name.get()
except appscript.reference.CommandError:
sys.stderr.write("got a CommandError at count %i\n" % count)
raise
except PassedLimit:
sys.stderr.write("exceeded threshold without triggering the
timeout\n")
to try it, paste the function into a mac python session (with
appscriptinstalled) and invoked 'first_timeout()'. if you have iTunes
populated with
at least one track, you'll see a count emitted at every 1000 transactions,
and either a hang and then "got a CommandError ..." message followed by a
traceback, if the error is encountered, or else an "exceeded threshold ..."
message if the limit was passed without triggering the timeout.
while i'm curious about the reason for the high hard limit, the reduced
limits are actually a problem - even the 57000/58000 ceiling interferes with
my script operation when running against a lot of playlists and tracks
(88/9300), to the point that i've had to include kludgy measures to work
around the problem. i'd love it if the problem could be confirmed by
others, and if it's widespread, whether someone familiar with
appscriptinternals could look into repairing it.
thanks for any light you can shed on this!
--
ken
http://myriadicity.net
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
