Codea 3.5.3 (337)

@Simeon Just ran into this bug. Don’t remember if this was reported or not since this version has been out awhile. Run the below code which is an infinite loop. Slide the screen from the left side to the right to show the editor. The editor is locked up because the code is still running in the while loop. You have to swipe Codea off the top of the screen to exit. Codea eventually crashes. I thought sliding the screen to the editor was supposed to stop a running program.

function setup()
    while not a do

Seen the same issue here.

i’ve locked up codea many times in many past versions, i don’t think it’s out of the ordinary

@skar @Simeon It’s not unusual that the code locked up, that’s what an infinite loop will do. What I’m questioning is sliding the screen from left to right to get back to the editor and the program is still in the infinite loop. I was under the impression that sliding the screen over to the editor would stop the program. Apparently it does in most cases, but not in this. I don’t know if that’s a problem to be fixed or an infinite loop can’t be stopped that way.

hmm that’s interesting because most of the time if it locks up me i can’t slide to go back to the editor, i have to force close the app and wait for the “Codea crashed” alert

@dave1707 - does that occur when you are running without buttons in viewer.mode or does it occur with or without buttons?

I always play with buttons and never exit by sliding the screen.

@Bri_G It doesn’t matter what viewer.mode is. The slide screen to the editor doesn’t stop the while loop. I don’t normally stop a program that way, but I thought swiping back to the editor stopped anything running. That’s why I was asking if it was a bug or that Codea can’t stop a tight loop.

@dave1707 - just wondered if there was a routine built into Codea to properly stop Codea project activity that works when the button bar is present and stop activated. If so that routine should be called when the Codea window is dragged offscreen - perhaps it’s not?

I’ve been suspecting for a while that certain loops keep running no matter how you exit to the editor.

It’s nothing I’ve been able to pin down, just that sometimes projects with big or complex loops run fine the first time I run them and then crash Codea entirely the second time.

@dave1707 I wonder if this is a special case where a loop has no body, like you say. So there are no intermediate instructions into which we can hook to disable the Lua runtime. Good find!

In the latest version I just had the dreaded “suddenly lose all work” bug, which I haven’t seen in a long time.

I had set up an assertion to check dependencies, and to test it I unchecked one of the dependencies and ran the project.

The assertion failed, as expected, and the error message printed out, but there was also a second error that I didn’t really look at.

It seemed odd that any error would occur after a failed assertion, but I didn’t pay any more attention to it than that.

When I returned to my project, there was another oddity, in that about four words had been deleted from an unrelated line down near the end of the project.

I assumed I’d made some mistake, so I hit the undo button (this is on the iPhone 8), but nothing happened.

Then I went to turn back on the dependency that I’d turned off, and was surprised to see that it was already checked on again–which I know for sure it wasn’t a second ago, because as you’ll recall I’d just failed an assertion regarding including it.

And when I left the dependencies screen:

  • all my assertion code was gone
  • a bunch of other code adjustments were gone
  • the oddly missing four words of code were back

…it was upsetting. OTOH it also made me realize it hasn’t happened in a long time, and that’s pretty great.

BTW, in case it has anything to do with it, my phone was at 1% battery.

The code I was working on is the same code posted here:

What you are describing sounds very similar to what I experience when I’m running out-of-memory in Codea. Things start disappearing in the text editor, and saving doesn’t seem to work consistently.

I would say the memory and/or the low battery could be in cause, as the OS will start doing as much as it can to recover memory, or save on battery usage. But I’ve also noticed that’s pretty much the only case where I can lose work now. So I’m happy to hear it’s also a lot more stable for you :slight_smile: