Codea 3.3.3 (280)

dave1707

@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()
    soc=require("socket")
    st=soc:gettime()
    cnt=0
    for z=1,20 do
        s=listProjectTabs("Examples:Cargo-Bot")
        for c,d in pairs(s) do
            print(d)
            cnt=cnt+1
        end
    end
    print(cnt)
    en=soc:gettime()
    print(en-st)    
end

Simeon

@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

Simeon

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

UberGoober

@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?

Simeon

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

dave1707

@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.

dave1707

@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.

UberGoober

@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.

Simeon

@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

dave1707

@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.

dave1707

@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.

dave1707

@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()
    soc=require("socket")
end

function touched(t)
    if t.state==CHANGED then
        print("save")
        st=soc:gettime()
        saveProjectTab("xxx","--qwertyuiop")
        en=soc:gettime()
        print(en-st)
    end
end

UberGoober

@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.

Simeon

@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 :P

Steppers

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

dave1707

@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?

Steppers

@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

Simeon

@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

Steppers

@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?

UberGoober

@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.

dave1707

@UberGoober If a position is changed, then you’re doing a save constantly as it’s being moved. From my example above, it looks like it takes .6 seconds per save and it gets buffered up and the updates continue until all the updates are done. I’ll have to add more code and see how it affects what else is running.

or a position is otherwise changed

UberGoober

@dave1707 maybe I was unclear: it saves on touch.state ENDED

dave1707

@UberGoober OK, now it’s clear, just on ENDED.

Simeon

@Steppers yeah for a self-modifying project you will see issues if you use non-coordinated read/writes. For modifying other projects you probably won't see issues, but if those projects are currently open in the Files app, or, say if Codea one day supports loading multiple projects at once, you might see issues.

RonJeffries

i'll be interested to see what this does to codeaunit, but i expect it has few users ...

Steppers

@Simeon Ok, I guess I’ll just deal with any issues if and when they arise then.

dave1707

@Simeon Ran into a problem with version 280. The code would not execute, it just stayed in the editor. I pressed the run icon at the top right, nothing. I pressed the run icon on the top right of the keyboard, it turned white but did nothing. I long pressed on the upper right run icon and it displayed the “Save and Run” selection. I pressed that and nothing. The editor worked as normal, I could delete and add code. I exited the editor and went back in. Tried to run the code, but nothing. I exited Codea and went back in and everything was OK.

dave1707

@Simeon So far I’ve had the problem of the code not executing 3 times. I can’t make it happen, but the conditions that was causing it was going into a possible infinite loop and having to force stop the code, but not exiting the editor.

Bri_G

@dave1707 - could you post some of your code. I’d like to know what area we need to focus on to see if we can narrow this down.

Just in general, recently I’ve found response to touch on my iPad getting poor. Sometimes needing a long touch to run from the editor. I was suspecting degradation of the screen protector or the screen itself - my pad does get some hammer.

Have modifications in iPadOS wrt touch changed - is it a result of upgrading iPadOS to meet the demands of metal?

dave1707

@Bri_G @Simeon I don’t have the exact code that was causing the problem anymore. But what I was doing was reading a large string and displaying small chunks of it to the screen, line after line. What I suspect was happening was that I was going into a tight loop reading the string but not displaying anything. Or possibly reading past the end of the string and not realizing I was supposed to stop. I would be able to stop the program without having to force close it, make changes, but then it wouldn’t execute until I exited Codea. I’ll try writing something again and see if I can force the problem.

UberGoober

@Simeon @dave1707 @Bri_G I had this happen to me too, yesterday. I don’t know if it had anything to do with it, but my project was also experimenting with heavy loop usage. I was trying to see if I could use coroutines to create a loop that I could break out of with a button press. Never got it to work, by the way, but I did see this bug.

UberGoober

@Simeon find and replace bug:

I downloaded this project and did a find/replace to turn “unpack” into “table.unpack”. After doing this:

• If I exit out of the project, and re-open it, the changes are gone
• If I run the project, it runs as if the changes have been made, but if I then exit the project and re-open it, the changes are gone

UberGoober

I’m still getting the project-reversion bug, now it seems like it happens every time I run a project that writes to tabs. It’s getting maddening. @Simeon if automatic save on run would fix this I am emphatically in favor of it.

UberGoober

@Simeon @dave1707 @Bri_G I’m getting this bug consistently now. I’ve been using my breakpoint code in conjunction with debug.sethook() to create a primitive step-by-step debugging system and every time I use it, when I exit to the editor the play buttons no longer work.

dave1707

@UberGoober Can you cut your code down as small as you can and still get the problem. Then post the code. That will help @Simeon fix the problem. That way he’s not spending time trying to write the code to cause the problem.

UberGoober

@dave1707 good point. I had thought maybe it would be obvious to @Simeon what was going on without any more information, but when you point it out, that seems like rather muddled thinking on my part.

This reproduces it:

-- PlayBug

parameter.boolean("breakpointsEnabled", false)

breakpoint = function()
    if not breakpointsEnabled then return end
    print("tap tab to advance a line, type 'qq' to exit breakpoints")
    local buffer = ""
    showKeyboard()
    while buffer ~= "\t" do
        buffer = keyboardBuffer()
        bufferLength = string.len(buffer)
        buffer = string.sub(buffer, string.len(buffer)-1)
        if buffer == "qq" then
            buffer = "\t"
            breakpointsEnabled = false
        end
    end
    hideKeyboard()
end

function trace(event, line)
    if not breakpointsEnabled then return end
    local s = debug.getinfo(2).short_src
    print(s .. ":" .. line)
    breakpoint()
end

function setup()
    needToStartDebug = true
end

function draw()
    if needToStartDebug then
        debug.sethook(trace, "l")
        needToStartDebug = false
    end
    for i=1, 2 do
        i = 0
    end
end

Run it, toggle breakpoints on, tap ‘tab’ a few times to advance a few lines, and exit to editor. Play button no longer works. At least, for me.

Simeon

@UberGoober thank you for that code, I can reproduce using the following steps:

1. Run code
2. Turn on breakpoints
3. Tab through a few breakpoints
4. Exit to the editor by swiping from the left to close the viewer
5. Try to play

If I exit by typing "qq" then the project runs fine on subsequent attempts. This leads me to thing it's something to do with the sethook call

dave1707

@Simeon I mentioned the project not running problem farther above and I wasn’t using a set hook call. I was doing a lot of looping in the code and would stop the code to make changes. After making changes, the run icons wouldn’t work.

UberGoober

@Simeon also as you may have noticed the breakpoint() function is mainly just one neverending loop, and that’s what sethook is fundamentally calling.

I also have seen this in projects where I didn’t use my breakpoints and it also seemed connected to loops.

dave1707

@Simeon This code also causes the no run problem. Run the code and slide right from the left edge to end the program then try running it again.

function draw()
    while true do       
    end
end

dave1707

@Simeon This also causes the problem. So it doesn’t matter where the loop is, setup() or draw(). It seems to be related to a loop and closing the program by sliding right from the left side of the screen.

function setup()
    while true do        
    end
end

UberGoober

Just had the tab-reversion bug happen in another project that does not write to tabs.

Simeon

This looks like a bug I introduced in handling how to terminate long-running Lua scripts, will try to fix

Bri_G

@Simeon - had two crashes with 280 today. One when I was editing, deleting a variable. The other just randomly. Couldn’t tie in any actions to the crashes.

Bri_G

@Simeon - this is a bit off the wall, it involved using Air Code and a browser.
I set up to use Opera on my Mac and connect to Codea. I opened a Craft project, the Catalogue Cube latest from @dave1707 and tried to paste some of the scene definitions in another project into it to a change the scene colouring. My iPad threw up an error 'Main:9: attempt to index a nil value (global 'scene') stack traceback: Main:9: in function 'setup' '.

After disconnecting and running the exact same project (unchanged) on my iPad there was no error.

I'm know that you may not be interested in the Aircode issue, but I thought it may give a pointer into current issues with 280.

Bri_G

@Simeon - accidently triggered record video for screen, selected don’t allow from the menu and Codea crashed v280.

UberGoober

@Simeon this seems very strange to me, maybe it’s a clue to something?

Start a new project, do a select all, and then paste this code on top of it, so that there is nothing else at all in the project.

This code runs a loop that you can escape by tapping q on the on screen keyboard, and every time it loops it calls background() with a pink color.

Run it and tap q very quickly, or else there’s a memory overload or something and it crashes.

The screen is all black until you tap q, at which point you’ll see the screen flash pink and black over and over and over. It’s like each background() command got saved up and was trying to execute all at once.

But the weirdest thing of all, to me, is that all this drawing is occurring even though there’s no draw() function in the project.

-- Delayed Drawing Bug

function setup()
    runLoop()
end

function runLoop()
    local buffer = ""
    viewer.mode = OVERLAY
    showKeyboard()
    while buffer ~= "q" do
        background(236, 67, 201)
        buffer = keyboardBuffer()
        bufferLength = string.len(buffer)
        buffer = string.sub(buffer, string.len(buffer))
    end
    hideKeyboard()
end

...it seems like weird behavior to me, maybe it’s a clue to what might be going on with loops?

dave1707

@UberGoober That's probably not a bug, but just the screen refreshing. This code below does the same thing. Slide the screen from the left edge to the right to exit the code.

 function setup()
    background(236, 67, 201)
end

UberGoober

@dave1707 huh, right you are, thanks. You do have a talent for cutting right to heart of the matter.

Bri_G

@Simeon - posted several times with a problem crashing 280 when trying to run an old project by @JMV38 which dealt with demonstrating Blend Modes. Crashed after loading and trying to run. Then subsequently crashed whilst trying to save & Run before the Save&Run menu was visible.

link to original thread

link to @JMV38 latest Gist with code

dave1707

@Bri_G If these 2 lines are commented out, Codea doesn’t crash. I didn’t see if the code actually ran or not, it just didn’t crash.

--back = grid()


--local colorGrid = smallColorPattern()