Found an anomaly

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Found an anomaly

Post by dunbarx » Fri Jul 11, 2014 12:15 am

There is another thread about timers:

http://forums.livecode.com/viewtopic.php?f=8&t=13090

While playing around with this, I finally found a case where stepping through a handler works fine but running it causes, not an error, but rather a recursion alert. Reliably.

Make two buttons and two fields. Place this into button 1:

Code: Select all

on mouseUp
   set the status of this card to "timing"
   put random (10) into fld 1
end mouseUp
And this into button 2:

Code: Select all

local startingTime

on mouseUp
   put the milliseconds into startingTime
   timeEvent startingTime
end mouseUp

on timeEvent startingTime
   if the status of this card = "timing"  then put the milliseconds - startingTime into fld 2
   if the mouse is down then
      set the status of this card to ""
      divide fld 2 by 1000
      wait 1 with messages --tried this to see if it did anything. It does not. 
      exit to top
   end if
   send "timeEvent" && startingTime to me
end timeEvent
Clicking on btn 1 sets up the process, loading a small integer into fld 1. The idea is to estimate the time in seconds of that value, with two successive clicks on btn 2. If I do this, I always get a valid result in fld 2, and always a recursion alert. If I step through the handler, though, I always get nothing at all. Place a breakpoint at the "wait' line to see this behavior.

I would love to know if anyone else sees this, and further, that this is a replicable example of this issue.

Craig Newman

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10058
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Found an anomaly

Post by FourthWorld » Fri Jul 11, 2014 12:37 am

Or more simply:

Code: Select all

on foo
  foo
end foo
Why would you not expect a recursion error when something keeps calling itself in a tight loop?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Re: Found an anomaly

Post by dunbarx » Fri Jul 11, 2014 4:40 am

Richard.

Hmmm. I am exiting quickly, with a millisecond difference of only a few thousand in that result field. I thought that meant that I am not going over the 40,000 call limit. Writing to the field is sort of like waiting for a small interval, and I can see the counter running in the thousands place. Am I wrong about this "loop" interpretation of the value of that field? I will think about it.

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10058
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Found an anomaly

Post by FourthWorld » Fri Jul 11, 2014 5:27 am

dunbarx wrote:Richard.

Hmmm. I am exiting quickly, with a millisecond difference of only a few thousand in that result field. I thought that meant that I am not going over the 40,000 call limit.
If I'm reading the code correcly, the field is storing a difference between millisecs, not iterations.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Re: Found an anomaly

Post by dunbarx » Sat Jul 12, 2014 2:42 am

Richard.

I was not counting the millisecond difference as a counter. I was informally watching that counter and considering it as an indicator of the number of calls. In this sense the number of calls should be less than the value of the field. In other words, since each update of the field reflects one call of the handler, the number of calls should be less, and certainly no more than, the field value. That difference might be whatever it feels like, but should not be more than the "index" of the number of calls, which increment by single digits:

Call 1 -- some millisec difference value
Call 2 -- some larger millisec difference value
Call 3 -- some even larger millisec difference value
etc.

I think.

But my question was more this: why does the recursion alert come after the handler ends? I certainly see how it can come in the middle of a runaway process. The one I run has a clean exit, and it is as if there is a queued number of calls that are banked after that ending. I am concerned that this question is related, and therefore reflects the same brain issues, as the recent thread I started about nested handler calls. What am I misunderstanding?

Craig

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Re: Found an anomaly

Post by dunbarx » Sat Jul 12, 2014 3:04 am

Not sure anyone is interested in this sort of minutiae, but I think the anomaly I mentioned involves interface elements. The original idea was that the user be able to press the same button to start and then stop a timing process. I made a change to the code to watch the number of calls. It made things odd:

Code: Select all

local startingTime

on mouseUp
      put the milliseconds into startingTime
   put 0 into line 2 of fld 2
   timeEvent startingTime
end mouseUp

on timeEvent startingTime
   if the status of this card = "timing"  then put the milliseconds - startingTime into line 1 of fld 2
   if the mouse is down then --This is very wierd
   -- if the optionKey is down then --This is reliable
      set the status of this card to ""
      divide line 1 of fld 2 by 1000
      wait 1 with messages --tried this to see if it did anything. It does not. 
      exit to top
   end if
add 1 to line 2 of fld 2
   send "timeEvent" && startingTime to me
end timeEvent
Not sure I can understand this at all. The "mouse is down" option does really odd things. The "optionKey is down" works like I would have thought it had to. And why does the value in field 1 change???

Craig

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10058
Joined: Sat Apr 08, 2006 7:05 am
Contact:

Re: Found an anomaly

Post by FourthWorld » Sat Jul 12, 2014 5:52 am

Thanks for the patient clarification. Intrigued, I copied the code into a stack there and I'm definitely seeing an anomalry: it consistently bails with a recursion error at iteration 621.

However, this is on Ubuntu 14.04, rather than Mac OS X, and I'm getting the handler interrupted rather than seeing the error after the mouse has been clicked. This difference may be due to the many oddities in the Mac event manager (the sort of thing that requires us to use the ol' "wait 0 with messages" trick just to get visible updates, something never needed on other platforms), but it doesn't explain why the recursion is being reported at all after just 621 iterations.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3901
Joined: Sat Mar 24, 2007 2:54 am

Re: Found an anomaly

Post by Simon » Sat Jul 12, 2014 6:48 am

I'm getting on Win 7 the recursion error at iteration 769.

Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Re: Found an anomaly

Post by dunbarx » Sat Jul 12, 2014 2:03 pm

I get what I originally wrote about, a sort of odd runaway action that bypasses what I wanted, and thought I scripted. If I place a soft breakpoint at, say, the "wait" line, and click the button a second time, the handler ends normally if I then step through. If I do not place that breakpoint, all hell breaks loose, the second line of the field starts to "count", and the only way out is cmd-period.

Oh, and did I mention that a spurious integer is placed into field 1?

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7394
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Found an anomaly

Post by jacque » Sat Jul 12, 2014 5:14 pm

A handler isn't removed from the queue until after its "end" line runs. Since neither of the "send" commands use an "in time" structure, every command that uses it goes on the queue. Basically that means the initial mouseUp never completes, nor any of the timeEvent iterations. Eventually a recursion error happens. Adding any amount of time to the send command, even zero, will fix it because each handler will complete before it runs again.

I'm not sure, but I wonder if the mouse check acts strangely because the initial mouseUp never completed. Essentially the mouse check is happening repeatedly inside a very deeply nested mouseUp handler.

Edit: The mouseUp handler doesn't use send, it just calls the handler directly. But it should use send-in-time, since the direct call also doesn't allow the mouseUp to complete.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7394
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Found an anomaly

Post by jacque » Sat Jul 12, 2014 8:11 pm

dunbarx wrote:If I place a soft breakpoint at, say, the "wait" line, and click the button a second time, the handler ends normally if I then step through. If I do not place that breakpoint, all hell breaks loose, the second line of the field starts to "count", and the only way out is cmd-period.
By necessity, the script editor must interrupt the message flow and intervene, so it will introduce enough idle periods for handlers to complete and exit.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 10356
Joined: Wed May 06, 2009 2:28 pm

Re: Found an anomaly

Post by dunbarx » Sat Jul 12, 2014 8:11 pm

Jacque.

I understand that the execution of handlers is not "perfect", in the sense that mental constructs do not sync perfectly with machine constructs. Hence the inclusion of "wait (even 0) with messages", as a technique, often allows the engine to catch its breath.

I have such a line, though. It makes no difference. But surely the issue lies somehow in what you mention; it just is not apparent to me where.

Craig

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7394
Joined: Sat Apr 08, 2006 8:31 pm
Contact:

Re: Found an anomaly

Post by jacque » Sat Jul 12, 2014 11:17 pm

Waiting with messages allows other background processes to happen but does not clear the call stack (the message queue.) I wouldn't expect it to; if it did, it would be a bug. Handlers must always complete. I probably shouldn't have used the term "idle" because I'm not sure that's correct here.

I don't know exactly how the debugger works, but it's doing something that prevents the call stack from accumulating too much cruft. For us normal peons, the backup has to be avoided by sending messages in time. I've been bitten by this enough that I pay attention now, and make sure that any handler that calls itself is sent in time rather than called directly.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

Post Reply