Just sent out beta 2. This includes Air Code — see the release notes for a brief overview of how it works. Let me know how it goes for you.
@Simeon: fair enough 
BTW, AirCode works great, this is a very cool feature!
Aircode rocks. Having said that - it would be nice to be able to “re-attach” a session after you break out (in my case, to look at the docs).
I also notice it doesn’t re-interpret setup() when you change it - I added a global to my draw loop (rotate(r)) - and it barfed, so I added “r=0” to setup() - no luck, even with ctrl-r.
This is a good opportunity to ask - are the docs online? I’ve been so busy at work I’ve been out of touch, and if they’re up, I dunno where (and neither does Google, which is a seperate bad thing; the first link there, for Codea 1.5, has a page that says “Documentation”, no link to anything) - before, docs online would be convenient, but with aircode - they’re essential.
BUT - those are quirks. This is awesome. I hope I can make it work at work, where we have some pretty silly/draconian wireless policies on our setup.
@Simeon: If you have a chance, would you mind explaining how you pulled this off (mainly on the Codea side, as I can see the page source from the browser side)? I am very interested in the implementation behind this.
The main reason I’m curious is because I’m also curious about whether bits of this could be integrated into the Codea API to allow us to do similar things from within our Codea programs.
@Bortels thanks for the feedback!
Air Code reloads the code in the current file when you make a change. It does re-interpret setup(), it just doesn’t re-run it (or else it would restart your project on every code change). This allows you to edit code and see visual changes in the current state of the app. (And if you pause your app then Codea will frame-step on Air Code changes.)
Cmd+R (or Ctrl+R) from the code editor should have worked, that will restart the project, running setup() and so on. I wonder what the issue was.
Re-attaching would be good, the state is entirely URL based, so it should be possible to make it work when you re-launch Air Code. I’ll look into it.
@toadkick it runs a web server in Codea, connections are handled by Objective-C code that parses the URL and figures out what projects to serve.
When a file is requested the editor document is populated with the file contents and sent to the browser.
When a file is edited in the browser an ajax.post request is made, Codea gets the updated file data and attempts to execute it (lua_pcall). If there are errors, the data is not written to the project. If no errors, then the project is updated — the Lua state will have already been updated from the pcall.
There is some fancy stuff going on in order to allow you to re-execute MyClass = class() tabs without overwriting the original class and failing to adjust existing instances. Basically when the changed code comes in, Codea uses a regex to find all class names from their code definitions. Before executing the changed code I check with Lua to see if the class has already been defined, and if so, strip the re-definition from the changed code. I was really happy that this aspect worked out. It lets you do things like alter the draw() function for a class and see all the existing instances update immediately.
@Simeon: very clever (particularly the part about handling classes), thanks for the explanation!
Confirmed: Alert is ok with ios5.
I had a go with one iPad from another. I know that that’s completely daft, but figured someone had to do it. When editing a line, the cursor position was not where it ought to be (the line in question was camera(0,0,10,0,0,0,0,1,0)) but was slightly to the right. (This was with the standard Safari browser.)
Using Firefox on my desktop worked just fine.
I’d quite like to be able to add, delete, and rename tabs. It’d be really easy to cut-and-paste code from one project to another using this.
@Andrew_Stacey yes, the code editor isn’t mobile compatible. Regarding file creation — there are plans to expand on the feature if Apple approves it. I’d like to have a tab bar with a split code view. But I don’t want to spend too much time on this feature until I know whether it’s allowed.
@Bortels sorry I missed your question — the docs are no longer online, but they are now all YAML source files. If anyone is interested in doing a quick YAML->HTML conversion on them I would be happy to put them up as a GitHub project or similar.
@toadkick we could expose a web server as a Codea API. That would be interesting.
@Simeon: I was thinking along the same lines
I tried a docs conversion in the past - but I don’t recall them being in YAML format. It proved to be a far uglier task than I had figured on, and I got distracted by bright lights and pretty colors. Got a link to the YAML docs? I may try it again.
Thanks for the offer @Bortels — they used to be written in JSON, we moved to YAML because it is much easier to write and much more readable.
I’ve set up an open source project for the documentation here:
https://github.com/TwoLivesLeft/Codea-Documentation
Anyone who wants to help with conversion scripts, submit fixes or improve the documentation in any way, feel free to send a pull request.
@Simeon - I found one possible issue with Air Code (which is amazing).
I ran it on this sample code
https://gist.github.com/dermotbalson/5719306
It worked fine when I loaded the main tab, but as soon as I pressed Crtl-R, even without changing anything, the colours in the image went black.
It is probably because the image is drawn using a shader. This is a stencil (fragment) shader that uses one image to “cut out” part of a second image.
It’s not serious, and I guess few people use shaders like this, so it may not be worth bothering with, but that’s up to you.
I have quite a few other shader projects, and they all seemed to work ok.
@Ignatz thanks for the report, I’ve added it to my list. I’ll probably only look at bug fixing Air Code if it actually gets approved. The first release is more of an experiment to see if it gets through and into a release version of Codea.
Alert() is great and was a must.
What about extending it a little bit?
I think of the following syntax:
alert(message, title, button1,button2,...,callback)
button1,button2,… are strings, displayed as buttons under the message. The number of buttons is leaved to the user.
When the user hits button1 then callback(button1) is fired.
Would really be all we need to interract with the user.
@Simeon any feedback on my suggestion?
@Jmv38 I like your idea a lot — perhaps the callback should take the index of the button pressed (1, 2, 3 …) instead of the name? That way you can change the button names without having to go and change your callback code.
An alternate API design might be
alert( message, title, { “Button Name” = function, “Button Name 2” = function } )
This is more stable (the button name is strongly associated with the callback, but it is harder to write.
Why not allowing both option? As for tables, we can index them with 1,2,3 or ''blabla1", etc…
My ‘dumb programmer’ experience is that it is easier for me to remember what i did if i use names, rather than numbers…
Thanks for considering my suggestion.