Pasting code with an else in it correctly indents the else statement.
Typing else and pressing return de-indents the else statement.
Find works for a single character. Haven’t tried it on every single character yet.
@dave1707 @Simeon - hi guys, running 275 and just trying out @UberGoober 's latest enhanced explosion. Worked fine but - I was looking for the explosion shader and tapped on the explosion asset link in the code - line:
pt.material = craft.material(asset.Explosion)
but couldn’t find it in any of the folders displayed. So I assumed it must be held in the “dave1707 Explosion Demo.codea” file which you can’t see with the asset browser. So I looked for it using the Files app and found the file mentioned here. On tapping it it started opening in Codea then Codea crashed. I repeated this both with and without Codea present in memory and it crashed inconsistently. Once it ran then I tried to run it from the Codea folder with it loaded in memory and it crashed. Will ensure I send a formal crash report.
Apart from the crash, why can’t we see the shader in the assets list?
@dave1707 - started to fill another crash report out but tried to scroll off and retest but report window disappeared. Here is what happened:
I had @UberGoobers carousel 1.5 loaded but he reported updating it in same zip link. So downloaded and installed. All seemed OK but when trying to re-install I took my finger off too soon so couldn’t share zip file to Codea. No probs as the file was unzipped into the Filer folder. So touched that to get sharing up and shared it with Codea, opened into Codea which then crashed. Seems to be a related problem.
@Simeon - I know you won’t be concerned about this but thought that I’d register it anyway. I was using Air Code and my Mac and was transferring tabs from one project to another. I had Main, Utils and StringThing tabs and wanted to add a fourth which I called FileManager - the latter was not visible on my Mac. So I logged out re-logged in and then tried again. Still no joy so I changed the order of the tabs and changed the FileManager name to FileBits thinking it may have clashed with something. Still no joy. So I logged out and duplicated the project file on my iPad then re-logged back in. The initial project still had three tabs the duplicate had 4 ?
Is anyone else experiencing files randomly reverting to old versions?
I used to be unsure whether or not I was imagining things, but since getting Working Copy I have proof positive, because I can see old versions of my projects.
It’s rare, but I’d say about once a week I open a project and think, hey, wait a second, didn’t I do x yesterday? And I go and check Working Copy and sure enough I did, but for some reason Codea threw it out.
Anyone else seeing this?
codea and working copy seem to work by sending telegrams to each other. in particular, i find that reverts often fail to update back to codea. i usually exit the project before reverting. i imagine the same could happen on a checkout of an earlier version. i don’t think i’ve seen changes in WC that got lost from Codea, but i could be wrong.
@Simeon - getting some funnies in 275, variables declared in setup eg str = “” throws an error up when trying to concatenation later.
@Simeon - my bad, that was version 276. Lost track of version changes - you’ve been busy.
I’m in 269. I’ve just seen something similar to @UberGoober 's issue, where my program tab and Codea were out of sync. I had added code to the tab, and it wasn’t running (it was a test, so I could see that it hadn’t even tried to run). The code was in the tab. I did the Save Project and Run thing and the code, still in the tab, still didn’t run.
I exited the project and went back … and the code that had been in the tab was all gone.
The project, like his, was under Working Copy, so it may be involved. I’ll send a note to the Working Copy author to see if he has any ideas. My fix, in case it is Working Copy, will be to exit the project before I do my Working Copy hookup and initial commit.
I have a solid reproduction of the problem. Here’s the note I sent to Anders:
Hi Anders, and Simeon ( on Codea Forum)
I’m seeing an odd new interaction between Codea and Working Copy. I’m sending the same report to both of you.
Summary
When an open Codea project is synched to a new Working Copy repo, further changes to the Codea tabs have no effect until the project is exited. New code shows in the Codea editor, but is clearly not compiled and executed. Working Copy does not show the changes either. If you exit the project, all the changes are lost.
The bug seems to be sensitive to the number of tabs you have. The example below is with just a Main tab and it seems to be able to be reproduced. I’ve seen it with two tabs but can’t reliably reproduce.
Details
Create a small new app in Codea. Little more than a hello world.
Init a Working Copy repo for it; share; attach the project. Initial commit. Repo looks good.
Make small change to the Codea program, to print “and felicitations”. Does not print.
Code is visible in Codea tab.
Codea: Save Project and Run, to be sure code is flushed.
New print still does not come out. Code still visible in the tab
Check Working Copy to see what it sees.
It sees no changes, Commit does not highlight.
Close Codea project.
Reopen Codea project. Tab is back to initial commit state, new code not shown. In other words, now shows what was running, missing out the “and felicitations” line.
Put the change back in.
It runs as expected.
Working Copy now shows the change.
That seems to happen every time.
Without Working Copy
OK, now I’m going to do the same exercise without Working Copy.
Both the new lines immediately print. Codea is not confused.
With Working Copy and Codea Project closed
Start again, same thing, except that this time we exit the project and THEN hook it into Working Copy.
Open the project, make a change, and the change takes.
Working Copy correctly shows the new code for commit.
Summary
It appears that if we init and connect a Working Copy repo with a Codea project open, Codea can become confused about what files it should be looking at, and does not see changes in its own tabs, which neither run nor ever show up in Working Copy.
Usually, when things are working right, Working Copy sees changes in Codea files even before Codea has run them or saved them. (I do not know how this magic occurs, but I see it.)
But it appears that if you don’t do your initial hookup with Codea’s project closed, something goes awry.
I’m available to try more things, and hope this is at least somewhat helpful.
@Simeon - just ignore my previous post, in stripping down the code to get a small demo I found a ‘beginners’ error - I had placed a variable definition after the function call using it in setup() - dooohhh (its an age thing !!!).
@RonJeffries I’ll take some time to reproduce your working set up. I’m noticing crash reports which involve trying to open a completely “blank” project (that is, a .codea/ folder with no files in it)
Anders is pretty knowledgable about iOS file system interactions, so my feeling is that Codea is doing something bad here and I’ll need to get to the bottom of it
i suspect so as well. the codea / working copy connection is weird at best. good luck!
I got the note shown below from Anders. After rebooting to look for Working Copy in Files, I could not reproduce the error.
Hi Anders,
On May 4, 2021, at 3:10 PM, Anders Borum anders@workingcopyapp.com wrote:
Could you check if Working Copy exists in the Files app and is functional here?
Sometimes when Working Copy is updated (as it was today) the Files app becomes confused and this also influences the ability for apps to share directories and files while editing in-place.
The solution if this is the Files app is to reboot your device.
I may have already rebooted yesterday, but today I did not find Working Copy in the Files app, neither under On My iPad nor in iCloud Drive. I rebooted (again?) and it is still in neither of those places.
I tried to reproduce the problem, and I was unable to do so, using the procedure I wrote up yesterday. So perhaps it has healed. I’ll pass a copy of this note on to Simeon.
Thanks!
Ron Jeffries
Speed is ppoor subsittute fo accurancy – Fortune Cookie
@RonJeffries interesting, thanks for following up. I’ll try your steps regardless as I’m sure we can find some things to fix on the Codea side.
I’m seeing this problem in projects I have no repository for. Working Copy shouldn’t know anything about them at all.