Re: spurious timeout on nth Apple event on Snow Leopard
Re: spurious timeout on nth Apple event on Snow Leopard
- Subject: Re: spurious timeout on nth Apple event on Snow Leopard
- From: email@hidden
- Date: Tue, 10 Nov 2009 12:16:01 +0100
On Nov 9, 2009, at 19:56, Matt Neuburg wrote:
> On Sat, 7 Nov 2009 14:46:36 +0100, email@hidden said:
>
>> Though, now I have something ;) When I strip the script a bit and run
>> it repeatedly in AppleScript Editor (still eats RAM):
>> -----
>> set L to ""
>> repeat with i from 1 to 300000
>> try
>> with timeout of 5 seconds
>> tell application "TextEdit" to current date
>> end timeout
>> on error errm number errn
>> --display dialog "timeout" & i & " " & errn
>> set L to (L & i & return)
>> exit repeat
>> end try
>> end repeat
>> L
>> -->
>> 3420
>> 44115
>> 131117
>> 170425
>> 26227
>> 104888
>> Should be always 65536, or a few counts under.
>
> No, because you don't know what Apple events may have been run in the
> meantime.
Between those test-runs there are only a few seconds. No chance that anything else always fires thousands of Apple events when I use AppleScript Editor and when I use Script Debugger nothing is fired.
> The overall count being maintained by the system is global. So,
> when we hit reply ID 65535 and the bug is triggered, that has nothing to do
> with what *your* "i" is. If the system happens to be at reply ID 65534 and
> you run your script, "i" will be 1, because it takes only one more Apple
> event to hit the bug.
Of course. If you read the Script Debugger results you will see that the first result is anything below 65534 ( here it was 20143). But then it's always exactly 65536 (a loop runs the timeout-test-loop).
I only removed the outer-loop because there's some bug that leads to heavy memory-leaking when using AppleScript Editor and it never finished. Therefore I did the subsequent runs in AppleScript Editor manually with only a few seconds between.
> Furthermore, your example is deeply flawed, because of the choice of "tell
> application "TextEdit" to current date", because that sends (at least) two
> Apple events.
Again, you can see that the rest-runs in Script Debugger produced 100% consistent results (i is always exactly 65534). You're right, Script Debugger shows about twice the events (I didn't noticed that). But that would mean the bug is not about every 65536nth event lost but about twice the amount.
That backups my guess that it not a 65534-counter-problem only. I think it's a combination of something and it manifests differently.
Or, it's just that AppleScript Debugger is so buggy that it leads to random results.
BUT, I know for sure that I already saw random results in Script Debugger, too.
> (...) Use my
> original, which sends exactly one Apple event, and your results will be more
> consistent ("tell application "Finder" to count windows").
In Script Debugger I already got consistent results with my method, so there's nothing wrong with it.
tell app "finder" is a no-go for me - one of Apple's buggiest apps. And scripting support is in the Cocoa-version even worse, so I only use the Finder if I absolutely have to...
But you're right on this one: if I replace that line with tell app "finder"... I now get consistent results in AppleScript Editor, too (it's still leaking lots of memory).
Christian _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden