On 18 Nov 2009, at 19:45, ken manheimer wrote: > 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.
Testing on 10.5.8 here doesn't throw up any errors. Have you tried it with a different application? Have you tried it with AppleScript? > 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, The auto-incrementing return ID is global to the system, so if other apps send events, that will also increment the counter. And since the counter is probably non-zero on your first run, you'll need to run your script several times, ignoring the result from the first run as that will almost certainly be artificially low. > 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 recommend reading the optimisation chapter of the appscript manual - many commands can operate on multiple objects at once, which will reduce the number of events sent and generally speed things up. That won't solve the problem - the 10.6 timeout bug is an Apple problem (which they've still not fixed in 10.6.2; I suggest folks file lots of radar reports on this issue to make Apple aware that it's a serious problem). The only other thing I can suggest is to monkey-patch the aem.Application._createproc function (or possibly even code a permanent workaround into ae.c itself) so that any time the Apple Event Manager's AECreateAppleEvent function returns a new event with the known-to-be-bad return ID, it chucks it and asks for a fresh one. I really don't have time to work on this right now, but if anyone else wants to have a go and submit a patch they'd be welcome to. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
