I created an infinite while loop for debugging reasons (printed out a variable, then did nothing). Nothing I did would exit, and I was forced to click "force exit" on the Not Responding window.
I also had this problem.
Yeah, ESC should break out of program immediately. If my thinking is correct, the way it currently works is that breaks only after reaching the end of TIC() routine which obviously can't happen with an infinite loop in place.
Have also encountered this - I think this is the most serious thing I have seen with TIC-80 (0.30.dev). It can potentially lead to data loss if you have unsaved changes and accidentally create an infinite loop.
hmm, don't know how to handle infinite loops :(
need some researching...
I guess it would need to be handled differently based on which interpreter is used. I'm pretty sure Pico-8 handles this as I tested it some time ago (didn't re-verify at this point).
Maybe something like: if the TIC() function doesn't return in X secs, break out of it. Kinda how Windows does to check for frozen processes. Obviously, this'd need multithreading, but it should not be ~that complex.
For infinite loops in LUA it is possible to hookup a function on the interpreter which is called after each N operations.
This function can then check if user do not want to quit.
For infinite loops in C, it is possible to ask for that inside each unbounded loop.
Another options is to listen on signals and kill the whole process on the kill signal.
but what if a user doesn't call any function in a loop
while true do end
as a solution, game could be run in another thread, don't like it
https://www.lua.org/pil/23.2.html allows to add count hook into the
interpreter. I am not sure how that would affect performance.
I think signals are handled as interrupts so they stop the thread anywhere
(but that also means that you cannot do much with the running thread).
čt 7. 12. 2017 v 16:42 odesílatel Vadim Grigoruk notifications@github.com
napsal:
as a solution, game could be run in another thread, don't like it
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nesbox/TIC-80/issues/197#issuecomment-350005313, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABPUj7QiO7nKnzbaAsnIFVtPwK8JZJViks5s-AdOgaJpZM4N9n1x
.
I think if a cartridge has a loop it should stay that way.
TIC-80, on the other hand, shouldnt freeze. Closing TIC-80 should work in normal fashion, without delays.
Please, correct me if Im wrong and if my mindset does not apply to what TIC-80 is, but I think @nesbox is building a fantasy computer here.
In the 80s, if you looped a program, you had to turn your computer off and then turn it back on.
I think that is the behavior TIC-80 should mimic.
If your game has an infinite loop, you have to close TIC-80 and open it back.
What happens if you have not saved your changes?
You lose it. Life is tough.
In the 80s, if you looped a program, you had to turn your computer off and then turn it back on.
That's not quite true. On an Apple II, for example, you could hit CTRL+Reset to break out of a running program, and many programming environments for whatever computer included a debugger that would let you break out, too.
So, certainly, an infinite loop in a running cartridge should keep running, but there's no reason we should have to suffer more when programming than we would have thirty years ago.
Im not going to lie. I really like my idea. Force people to close TIC-80. That would be fun (when it happens to others).
However, since pressing Esc quits the currently running cart, this behavior should work as expected when we have an infinite loop.
Im trying this simple fix, thanks to the tip from @jahodfra - using the line count hook helps a lot.
In this fix,we do not check if the user is pressing ESC or trying to close the TIC-80 window.
If it takes too long to draw a frame - run the TIC() method - it kills the cart with an error.
so, now you can exit infinite loop with ESC button
thanks all for the ideas 👍
@nesbox
NOT FIXED for JS
ok, let's try to fix it in JS
Looks like it can be done with DUK_USE_EXEC_TIMEOUT_CHECK. See https://github.com/svaarala/duktape/blob/master/doc/sandboxing.rst#use-the-bytecode-execution-timeout-mechanism and a section below for details.
fixed in JS 0e997f5
thank you @lolbot-iichan 👍