Codea 3.3.3 (280)

@Simeon Somethings wrong with version 280. I noticed one of my projects wasn’t running the way I remembered. So I created this to show the problem. If I run the below code on version 280, it takes 3.68 seconds to complete. If I comment out the print(d) line, it takes 3.9 seconds. But that’s not the real problem. If I run this with version 279, it takes .028 seconds with the print statement. That’s 131 times faster (3.68/.028). I haven’t tried other things to see what else is wrong.

PS. Times may vary depending on the device used.

function setup()
    for z=1,20 do
        for c,d in pairs(s) do

@dave1707 yes these functions will be slower now because they coordinate with other file system operations to ensure that the locations are safe to read or write

To go into more detail, all of these functions now need to broadcast their intentions to read or write the specified file/directory

So when listProjectTabs is called, it broadcasts its intention to read the directory “Examples:Cargo-Bot” (…Documents/Examples/Cargo-Bot)

Any other parts of Codea (or the operating system) viewing this file are now notified of the intention to read. If any unsaved changes are pending, it will wait to ensure those are written before the read of the Cargo-Bot directory occurs

This process of broadcasting / awaiting results will make these operations take much longer than before, but it ensures that the system is correctly notified about file reads and writes so that other editors or viewers of the same file can save or reload their work

@Simeon can you give any more details on “much longer”? My SimpleButtons write to tabs any time someone changes the buttons’ positions, is that going to be impossible now?

@UberGoober the best thing would be to give it a try and see if you notice a difference

@UberGoober My above code does 20 listProjectTabs. There was a considerable slowdown. If your going to be writing to a tab every time you’re moving a button, you might have a problem. The only way to know for sure is to try it.

@UberGoober @Simeon I tried doing a saveProjectTab in the touched function as I moved my finger around the screen. It took approx .6 seconds per saveProjectTab. Apparently the saves are buffered because after I stopped moving my finger, the saves continued and didn’t stop for a long time.

PS. Probably what needs to be done is to not save anything until an ENDED state is reached.

@Simeon @dave1707

Attached is my SimpleButtons project. I couldn’t tell if it was slowing down or not. If I can’t tell, does that mean it’s fine?

But after running it I got the erroneous editor glitch shown in the screenshot.

I submitted it as a bug report. I tried to cut and paste and it looked like some code vanished, then I tapped the undo arrow and saw this.

Exiting the project and re-opening it made this go away.

@UberGoober thanks for sharing your project, I’ll give it a try.

If you can’t perceive the speed difference then my guess is that normal writes are so incredibly fast that even slowing them down significantly has no impact. It’s probably going to have more impact if you are looping over and reading / writing many files at a time, constantly

@Simeon I don’t know what’s going on, but changes I make to the code aren’t being applied when I run it. Even if I do the “Save and Run”, the changes aren’t being applied.

See my code above for the timings I did with saveProjectTab with touched.

PS. No matter how many times I run the code, the changes aren’t applied until I exit the project and go back in.

@Simeon I have a theory about what’s happening. Since I’m doing a saveProjectTab every time I move my finger with touched, the saves are being buffered up and are still being updated even after I stop the code. Then when I make changes, because the saves are still going, the changes aren’t being updated. Does that sound plausible.

@Simeon Heres the code I’m playing with. Run the code and slide your finger around the screen for about a second. The saves are buffered. Go back to the editor and change the text in the print statement and run the code. Exit the project and try again. Things in the print statement don’t seem to work until the tab xxx is deleted. I even exited Codea and went back in and the code was the original I started with no matter how many changes I made in the print statement.

function setup()

function touched(t)
    if t.state==CHANGED then

@Simeon just had the reversion bug, lost two lines of code. Project uses SimpleButtons, which write to tabs. I made a new button, ran the project to verify it was on screen, it was, I moved it a little, closed the project, code was gone.

@UberGoober I’m going to make “Save & Run” the default behaviour I think. It’s too unreliable to use Apple’s automatic document saving

@dave1707 I think calling saveProjectTab on ever single touch changed event is going to be extremely heavy. I’ll try it and see what’s going on, but I don’t support what you’re doing here :stuck_out_tongue:

@Simeon I assume regular Lua ‘io’ file access isn’t affected by this?

@Simeon Writing constantly to a tab isn’t something I’m doing, but that’s what @UberGoober sounded like he was doing in his SimpleButtons project above. So if they drag a button across the screen or change its size, then it updates the tab every CHANGED position. That’s what I was testing and it’s really slow and was causing problems with my test code.

My SimpleButtons write to tabs any time someone changes the buttons’ positions, is that going to be impossible now?

@dave1707 I’d suggest creating the tab using saveProjectTab during setup if it doesn’t exist (as Info.plist needs to know about it) and rather than going through saveProjectTab for each event, use Lua’s regular file io to overwrite it. That’s how WebRepo is saving downloaded project files to disk.

You should be able to get the path you’ll need using (asset .. “tabname.lua”).path

@Steppers it’s not affected but it’s also not safe and can cause writes and reads to happen out of sync. This is why when saveProjectTab("xxx","--qwertyuiop") was called in dave’s original example, the tab didn’t show up. Because the write wasn’t coordinated with the operating system, the editor didn’t know the document had changed and it needed to load the new tab. This gets more complicated when you have external documents and cloud based documents

@dave1707 oh I see, I assumed @UberGoober was updating the position on touch ENDED (i.e., when you dropped the control to its new position). Doing it on CHANGED would be a bad idea with coordinated writes

@Simeon Ah ok, I assume that’s out of sync with the currently loaded project? If for example I’m writing directly to files in another project (as WebRepo does) I assume I’d be ok as opening the project would load it fresh anyway?

@dave1707 @Simeon I misremembered my code, I just looked through it again and it does only save every time a touch ends or a position is otherwise changed.