Yeah good point, I’ll change “Run only” to “Cancel” instead
@Simeon Maybe I should have asked this sooner. Why not just do the Save all the time before running the code.
It’s not the recommended way to deal with documents on iOS now days. But the Runtime portion of Codea is a bit old-fashioned and expects stuff to be on disk immediately for the project-editing APIs.
The ideal way to work would be to use the in-memory representation entirely in the runtime, and editing the project just behaves like any other document editing operation in the code editor. That’s where I’d like to get things.
It’s also possible to open Codea documents from other locations now (such as another app like Working Copy, or from a USB drive, or iCloud, etc). Saving might take a long time if your document is on iCloud, or worse, it could fail (you unplugged the USB drive, for example).
The way it works is that there is a process monitoring changes to the document, and a background daemon which ensures that the document is saved. Other processes might also be interested in the document, and asking to save the document in Codea would tell those processes to save their changes first, which could add delays.
@Simeon - just tried to use Air code on 179 and Codea bombs straight back to iPad apps screen. Switched Airplay on and off no change. Have you modified this recently?
I have been playing around with WebDav - could that affect it?
@Bri_G it does crash straight away! I’ll look into it, I haven’t touched it but I must have done something
Fixed the Air Code issue, thank you for the report
@Simeon - thanks for the update, have been trying to use WebDAV to use external editors on my Mac. But ran into a brick wall, couldn’t get a proper link. Couldn’t get the Davify Codea package to install from the zip file. Eventually had to copy and paste Davify in, but running it still wouldn’t give me access. Also trouble with WorkingCopy.
I’ll shelve this for a while, until you next update, and work on my latest project. I’ll be getting in touch with you about that later. Thanks again.
@Simeon - 179 giving problems with formatting of comments again - see photo below.
I have already taken out a couple of — formatters from within the —[[ and —]] the touch routine with no effect. There was no red error bar before I put in the paragraph comment fields.
@Simeon - yes - also the error bar, see attached photo, is giving a false error.
@Simeon - new editor, drop down list of tabs - when you switch tabs top tab (usually Main) is red. Select another tab and current tab is green, top tab red an rest black. Is this the intended color scheme?
@Simeon - Aha, is it red because there is an error there - if so just ignore the question.
@Bri_G any way I could get that project from you to see if I get the incorrect highlighting too? Would love to fix
@Simeon - very big project, and a bit of a mess at moment, so I started stripping out code that didn’t influence the error and combined into one tab. Error still present. Not sure how you can play with this - I will be sending the full code to you later when finished, but hopefully free from errors. Trying to attach as a zip.
Thank you! I was able to open it straight from the zip into Codea on my phone and I can see the error
Ohh I see the bug in Codea. It’s the double bracket ]] in the line ending rotMats[face[chkbut]]). If you put a space between those two for now ] ] it will fix the highlighting until I can fix this properly
@Simeon - great, I thought it may have been down to control codes for text formatting. I’m sure I’ve used that before without problem problem. Then again it may have been something like data[table[table2].x] - how deep can you nest these? I need to get better with tables.
By the way, thanks for the Aircode update, will be testing later.
@Simeon - Aircode working fine now. Thanks again.
@Bri_G surprisingly, your snippet of code is highlighted correctly
Lua treats the double ]] as the end of the multi-line comment, even when it’s matching other brackets inside the comment. So Codea is highlighting this correctly. The code will error in the Lua interpreter
If you try paste this code
print("Hello World!")
--[[
local tbl = {}
local lookup = { bar = "foo" }
tbl["foo"] = 55
print(tbl[lookup["bar"]])
--]]
Into the Lua interpreter on the official web site here: https://www.lua.org/cgi-bin/demo
You’ll get an error input:7: unexpected symbol near ')'
If you want to change your commenting style, you can place an = sign between the comment brackets, and then Lua will match to the closing brackets containing the same number of equals signs
This will highlight and run correctly:
print("Hello World!")
--[=[
local tbl = {}
local lookup = { bar = "foo" }
tbl["foo"] = 55
print(tbl[lookup["bar"]])
--]=]
@Bri_G See this link about comments. You can have a lot of nested comments by using matching equal signs between the starting and ending square brackets. I don’t know if there’s a limit to the number of equal signs that can be used.
http://www.wellho.net/mouth/4271_Line-block-and-nested-comments-Lua-compared-to-other-languages.html