Beta 2.1 (1)

sim · August 13, 2014, 5:59am

@Andrew_Stacey excellent, thank you for isolating it!

Since Codea 2.0 setContext was changed to use a depth buffer by default - but that reduced performance pretty severely. 2.1 adds an optional useDepth flag and disables it by default.

sim · August 13, 2014, 8:22am

@Jmv38 the setContext inside touched() issue is fixed for the next build. Thanks again for the helpful example @Andrew_Stacey.

sim · August 13, 2014, 11:21am

@Jmv38 thank you for your blendmode project.

The bug was triggered by creating more parameters inside a parameter callback, this created a deadlock where Codea would freeze up.

This bug is now fixed in 2.1 (4), however due to the nature of the threaded renderer it was very hard to retain identical behaviour that you relied on in your blendmode project.

Specifically, you rely on the initial callback of a parameter being called immediately. This is no longer the case, so for example:

function controlPanel()
    parameter.clear()
    ready = false
    paramBlendMode()
    parameter.boolean("bicolorOnly",bicolorOnly,function()
        if bicolorOnly then 
            parameter.color("c0",c0,function() bicolor() end)
            parameter.color("c1",c1,function() bicolor() end)
            bicolor()
        else 
            multicolor() 
        end
        if ready then controlPanel() end
    end)
    ready = true
end

```


In your function `controlPanel` you set `ready` to false, construct a `parameter.boolean` which relies on `ready == false` in order to avoid infinite recursion. 

This is no longer the case because parameter callbacks are deferred (parameters need to be set up on the main thread for UI purposes, but they call back into the Lua thread once initialized).

So the order of execution cannot be relied upon in 2.1 (4) — `ready` is set to `true` inside the first `parameter.boolean` callback because the `controlPanel` function finishes executing *before* the `parameter.boolean` first callback is made.

@Dylan and I are still trying to restore the original behaviour, but it is possible that we might not be able to guarantee `parameter` callbacks are called immediately upon creation.

sim · August 13, 2014, 11:32am

@Jmv38 I take it all back, it turns out I can guarantee the old behaviour and the next build should have it working as normal.

Edit: That said, it’s probably good practice not to assume the parameter callbacks are called immediately within the context of your code.

Jmv38 · August 13, 2014, 12:10pm

@Simeon thank you for pointing all this out.
Actually, i was strongly in favor of parameter NOT being called immediately, if you remember old discussions. But there was no choice, so we (with toadkick) developped some complex solution to bypass this behavior!
So it would be completely ok for me to be not backward compatible in this special case! Having to rework some of my projects for this would be ok.
Personnally i would still favor the new behavior, but it is up to you to choose…

Jmv38 · August 13, 2014, 1:41pm

@Simeon very good job with (5), now most things work!

sim · August 13, 2014, 9:06pm

@Jmv38 thank you, the displayMode() and supported orientation stuff will hopefully be fixed soon.

I am still conflicted over the parameter callback behaviour. The reason for the initial callback is because using the parameter functions actually creates a new variable if one doesn’t exist.

So the initial callback was a way for you to get that first value. That said, it can be both good and bad.

For example, code with an initial callback:

function setup()
    parameter.integer("CurrentScene", 1, 5, 1, function(value)
        setScene(value)
    end)
end

Without an initial callback:

function setup()
    parameter.integer("CurrentScene", 1, 5, 1, function(value)
        -- Not called until slider is actually changed
        setScene(value)
    end)

    -- This needs to be called to set the first scene
    setScene(1)
end

The second is more explicit, but can also feel redundant. I probably will not change it, but at the moment I don’t really prefer one option over the other.

JakAttak · August 13, 2014, 10:34pm

@Simeon, personally I prefer without the initial callback. If you need the callback straight away, you can always do that, but if you need it not to happen, you have to modify parameter.

Jmv38 · August 14, 2014, 1:45am

+1 for JakAttak.
A possible way to:

be bacward compatible.
and allow new behavior.

function setup()
    parameter.integer("CurrentScene", 1, 5, 1, setScene, true | false )
end

if the new last input is true then dont fire first pass.
If false or nil, fire first pass.

sim · August 14, 2014, 2:19am

@Jmv38 I had the same thought. It might make code harder to understand, though.

I’d like to change it permanently, but it would break a lot of existing code.

Jmv38 · August 14, 2014, 2:26am

you decide.

Jmv38 · August 14, 2014, 2:28am

####Remark:
I have noticed that when i stop the running project:

the graphics are partially drawn. Before it was 0% or 100%.
there is an error printed, but it disappears immediately because the project is closing.

Jmv38 · August 15, 2014, 2:20pm

####Bug:

-- this wont compile but doesnt throw any error
-- => impossible to find the error in a 30 tab project!
-- The error should be: myClass is undefined

function myClass:doThis()
    
end

function setup()
end

[EDIT] rather funny: after posting this, i came back to my ‘quick project viewer’ and, by mistake, i have tapped ‘run code in the pasteboard’, and it has thrown the following error:

error: [string "-- this wont compile but doesnt throw any e..."]:5: attempt to index global 'myClass' (a nil value)

Took me some time to understand that the above post was still in the pasteboard!
And you can see that, from loadstring(), the error is correctly thrown! Lol!

Jmv38 · August 16, 2014, 1:13am

####Bug:
i have tried to paste a 3000 lines code in 1 tab, named lib, in a project with 2 tabs only, lib and main, both completely empty.
=> Codea freezes.
i did not expect this because just before i had pasted the whole project, 4000 lines, in the main tab and it worked, after a few seconds.
[EDIT] the bug is actually: paste takes 5 min in a tab, and 1/2s in the main! For the same 2700 lines of code…

JakAttak · August 16, 2014, 1:17am

@Jmv38, I believe that if you wait long enough it will work.

Jmv38 · August 16, 2014, 1:31am

mmm as i wrote, worked fine with 4000 lines and freezes with 3000 lines, the same project where i have remove the 1000 last lines… It must be due to some bug in the way the editor colors the text.
[edit] @jakattak you were right: it took 5 minutes, but it worked.
[edit] and i’ve pasted the exact same text into the main: 1/2 second!

JakAttak · August 16, 2014, 1:58am

@Jmv38, yes but I think it freezing permanently and it just taking longer would be different bugs.

Jmv38 · August 16, 2014, 2:02am

i’ve edited the bug report. Thanks.

Jmv38 · August 16, 2014, 8:22am

####Bug:
i got stuck into a project (1tab project), i could not exit from the editor view. When i finally tried to run it, codea closed, and it was ok when i restarted codea.

JakAttak · August 17, 2014, 2:42am

Had similar as Jmv with regards to getting stuck inside a project and you can’t get out without running, but in a more than 1 tab project
You can’t get out of infinte loops if there is a print statement in them. For reference:

function setup()
    print("tap to create an infinte loop")
end

function touched(t)
    if t.state == ENDED then
        print("created it")
        
        while true do
            print("oops")    -- comment this line and you can quit during the infinite loop
        end
    end
end