Create a model with a go (forever) button, and give it this code:
to go
if (mouse-down?) [
while [mouse-down?] []
show "No more Mr. Mouse"
]
end
Click on the View. In JVM NetLogo, you will see the message "No more Mr. Mouse". In Tortoise, the code for that line will never be reached. The mouse is never given a chance to update whether it's down or not, since the JS for while [mouse-down] [] is a while loop that dominates control of the system.
This could maybe be fixed by actually having while compile to recursive(esque) setTimeout calls. It's kind of gross, but... it would maybe get us better NetLogo semantics. I'm not sure if that would work out well with how we're currently throwing StopInterrupts, though. The whole things a big mess of wonky control flow that doesn't translate well into JavaScript.
This problem also prevents Mouse Drag One Example from working correctly (since it, too, goes into an endless while loop).
Discovered while investigating #150.
Create a model with a
go(forever) button, and give it this code:Click on the View. In JVM NetLogo, you will see the message "No more Mr. Mouse". In Tortoise, the code for that line will never be reached. The mouse is never given a chance to update whether it's down or not, since the JS for
while [mouse-down] []is awhileloop that dominates control of the system.This could maybe be fixed by actually having
whilecompile to recursive(esque)setTimeoutcalls. It's kind of gross, but... it would maybe get us better NetLogo semantics. I'm not sure if that would work out well with how we're currently throwingStopInterrupts, though. The whole things a big mess of wonky control flow that doesn't translate well into JavaScript.This problem also prevents Mouse Drag One Example from working correctly (since it, too, goes into an endless
whileloop).Discovered while investigating #150.