The parameter.watch display is messed up again. There doesn’t seem to be the right amount of space for the display (it seems to be clipped to a small rectangle) and there’s sometimes a table <address> shown as well as the result of the watch.
@Andrew_Stacey yes, I have noticed that one, another iOS 7 thing on the list to be fixed.
here is a case when the parser doesnt add an end.
foo(function ()
end):chain(function()
)
but more urgent would be to fix color dialog when it is a function argument 
m:setColors(color())
Regarding shader code I think most people now write it as a string in the normal editor, so maybe it would be better to add syntax support in that view instead. A bit tricky how though, but it works for javascript in html-pages for example.
Would be nice if you could export a project as text including encoded images, but might be a bit tricky.
The +*- button works great now. But using () slows down the coding quite a bit, then the current solution is better I think.
@tnlogy do you mean the color() popup is inaccessible when used as a function argument?
Can you elaborate on what you mean by using () slowing down coding?
The complex nested function example will likely not be solved — the auto scope completion is tailored for the common case, it relies on some assumptions to ensure that it doesn’t get in the way of normal coding.
yes, when color is an argument you have to wrap lines to make it work.
it’s the delay when pressing () to access the other buttons I mean, if the popup would show up immediately like the ±*button it would be better.
ok, that’s reasonable, just a bit inconsistent. but on the whole the update feels fresh and nice. like the color preview. would be nice with an image preview, and a ui for choosing texture for mesh, which is a bit inconvenient. Just a method returning the string itself but with a ui for it. loadTexture(“Document:image”).
Does anyone know of any function calls / bad arguments / things you can do in Lua that make Codea crash? I’d like to spend some time fixing some of these up (so that they instead report runtime errors, etc). Please let me know if you know of any.
Auto complete close statement/function is fired if there an ‘closing’ error under. Mmhh, I don’t know if it’s clear… From the following, put the cursor after fn() or then and hit return.
function fn()
end
if t == 0 then
print()
end
function
btw, I like the new in app doc design, lovely icons and nice background effect.
@toffer thank you for your feedback on the new docs design. Glad you like it.
I think I have fixed your auto-complete scope issue for the next build. Note that in some cases it is ambiguous whether an “end” needs to be added. But in your case it is pretty clear.
Also like the new docs design, looking nice! Is it supposed to focus the item you came from when you go up a level though?
Regarding design I think it would look a bit more clearer if the play button looked the same as when the keyboard is focused. Currently it doesn’t give so much feedback that you’ve pressed it.
If I would add a feature to the UI, I would add folders for the projects view similar to how icons on the iPad are handled.
I’m getting quite a few crashes when running code at the moment (generally on the second run of a project). I’m not sure if it’s due to the project I’m working on or the new Codea. Are the crash reports enough information to debug this or do you need more information from me?
@tnlogy features like folders will come, but it would probably delay 2.0 too much to add them now. I’m working on getting the bugs fixed and finishing the visual re-design.
Do you mean looking up from the editor shows the path from which you came? (E.g., Graphics → sprite() → details). That is intentional.
I agree with you about the play button on the toolbar, it’s lacking in thought at the moment. I’ll have to think about how to design it.
@Andrew_Stacey that’s odd, I’m not seeing the reports (maybe they haven’t come in yet). If it’s a project you don’t mind sending, I’d be happy to test it out and see what’s crashing.
There should be quite a few stability improvements in the next build, I’ve noticed parameter.watch() and the output pane can be quite buggy in the current build. So if you are using those then it might be related.
@Simeon the project is this one: https://gist.github.com/loopspace/8511991
It could well be the parameter.watch. I think I’ve removed them in that gist - in part because they aren’t much use right now due to earlier mentioned issues - so you might have to add in a few random ones. I’ll see if running it without parameter.watch helps.
(Is there something I need to do or should do to ensure you get reports?)
I mean when you go back from details to sprite() sprite is focused, but if that is intentional then ignore my comment.
To match iOS 7, it maybe should just say Play.
A bug: trying to show this image with sprite() or as a texture makes codea crash.
https://dl.dropboxusercontent.com/u/9710463/web/Codea/Slices.png
Must confess I still don’t understand how Codea handles retina images, and why there is a difference, so might be that it is double the size and crashes since the texture is to big?
(was trying out my old brute force volume renderer. http://m.youtube.com/watch?v=SOtriszSUac)
@tnlogy I can see the crash log relating to Slices.png, it has failed to load the image for some reason. When I try it here, it works. How did you get Slices.png into Codea?
@Andrew_Stacey I’m not sure why I am not seeing your crash logs, they are supposed to come through automatically. I will try your project.
It is created with this code https://gist.github.com/tnlogy/5219140#file-simple-volume-renderer-in-codea-lua-L117 from smaller images
I see, can you perhaps check the Slices.png in your Codea Documents directory using iTunes (app file sharing) or iExplorer?
It’s looking for the following file and is not able to load it:
/var/mobile/Applications/A5188B5B-0F1B-4BB3-932D-B53A3C398D8C/Documents/Slices.png
It would take an @2x version if it was there too.
Sure I’ll check it when I’m back from work.