It wouldn’t save what I put on air code. Is it supposed to not save?
No. Did you exit the Codea app to close it, and did you close your browser before Codea?
I’m not sure, but anyways now it always says there was an error creating server, even when I’m on wifi.
I have found that AirCode can get confused and basically stop updating pretty frequently. It looks to me like an Alpha-quality feature that’s mostly just for seeing how it works at this point; I wouldn’t rely on it until it’s a bit more stable.
I think I know what the problem is (but it’s still a bug). If you don’t notice compile errors in one tab when you move to another one, then come back, AirCode (helpfully?) reverts the code in the first tab back to the last known working state. Never leave a tab with erroneous syntax–fix it with legal Lua or comment it out before switching tabs. AirCode doesn’t report an erroneous tab like the code editor does (it should).
It probably has something to do with Codea trying to keep your program running at all times, even while you’re revising it. That aspect is helpful when you’re debugging the draw loop, because you can see your changes on-screen in real-time, but in other situations, not so much, particularly when it loses the code in the process. I’d rather it’d work like the code editor in that regard–highlight the tab in error and show a message at the line in error–the code editor doesn’t try to “fix” anything.
There may be other situations, too, but the above is easily replicated.
@Simeon Video. That supposed to happen?
Nice, concise demo, @SkyTheCoder.
@SkyTheCoder @starblue Air Code intentionally does not save / attempt to execute invalid code. If the code cannot be loaded into the Lua runtime, it is not saved to the project.
Ok
@Simeon. It’s fine that the code isn’t saved to the runtime on the iPad, but why does that mean blitzing it in the browser? After all, one is trying to modify it to get it to run successfully, and having it vanish on you doesn’t advance that goal.
In the video, what if the user had just typed in a 100-line function rather than a line of garbage and then went back to the main tab to create the call to it and then ran the program? It fails, he goes back to the tab to fix the bug, except…
I consider it to be a bug, but since there’s a ready workaround, even I don’t consider it high priority to fix. But when you run of things to do 
you might want to reconsider.
@starblue that’s a good point. The original intention of Air Code was to make instantaneous changes to an already-running project. The idea being to see code changes live.
I can see how someone making large scale changes could find this behaviour unpleasant. I’ll try to find a solution to it.
@simeon: Why does it have to be a live action? Why not just put a run/play button so user can run the program at wish? Just like the regular editor. Or provide an option so user could select whether AirCode to run live or not. A good automation is good on some cases but it can be annoying at other cases.
@Simeon 's idea isn’t bad, just different, with benefits of its own. I don’t see it as an either-or thing–why can’t it be live yet leave the code in the browser alone? Maybe the current implementation makes it hard to do, but it seems doable. Right now, though, his idea just comes through as buggy. That’s what I’m asking him to review.
I’ve discovered another problem with the current implementation. If one types in valid code that puts you into an infinite loop, you can’t regain control in either AirCode or Codea. (Aside: I think triple-tap is supposed to break out of loops, but I have that set to zoom the screen via Apple’s Accessibility feature.) Even if you abort Codea (via the iPad’s “wiggle dance”), restart it, and invoke AirCode again, you’re put right back into your infinite loop (it’s valid code, remember). The only way to regain control is to restart Codea and go into the code editor to fix the code causing the infinite loop. This could be construed as an argument to not run live from AirCode. If AirCode could issue an “abort” signal to stop the interpreter, I don’t see that we have to scrap the “live” feature.
http://www.youtube.com/watch?v=J1Wf2Bhn5NM&feature=youtu.be
My Codea is still frozen.
I didn’t show in there, but even after I removed the while true loop it’s still frozen.
Triple-tapping with three fingers isn’t doing anything, either.
Try exiting Codea and double tapping the home button. A little thing should come up at the bottom of the screen. Hold down on the Codea icon until a little red thing comes up in the corner. Tap the red thing. Then go back into Codea. It should be fixed. Just remove the while true statement. Now it should not freeze.(doing all this will restart Codea. You can do this with other apps to if they are freezing.)
When AirCode becomes frozen due to an infinite loop, typing further into the browser is futile. The browser window is still active, and you can type whatever you want into it, but Codea’s WiFi link has been lost (or at least it can’t look for it while caught in the loop).
@EpicPotato I know how to restart an app, I was just saying what should work that didn’t.
@starblue Apparently.
@SkyTheCoder this is not related to Air Code. Running an infinite loop in Codea is going to cause issues.
We used to have a default instruction limit set to avoid these issues. If you would like to use that, please call setInstructionLimit( 10000000 ) in setup(). We stopped this default behaviour because hitting an instruction limit was more problematic than running into infinite loops.
@Simeon, did you see above where I discussed where an infinite loop causes problems with AirCode because, since it’s valid code, even if you get out of Codea, come back, and restart AirCode, you’re back in the loop. It’s starting to look more and more like there needs to be a mode where you’re not running live while in AirCode.
An alternative, though specific to this case, is that when you enter AirCode, live mode is off until the first Ctrl-R–that gives a window where one can fix the infinite loop. A third option is to implement a live mode on/off switch as @bee described, with the default as “off”.
Incidentally, what is the command to interrupt the program and return to the code editor? Where is it documented? The “Getting Started” box on the front page would be a good place to mention it.