Beta 2.1 (1)

JakAttak

Anytime I open the in-app browser, when I close it my project gets reloaded (starts over from setup). I'm fairly certain this was not the case previously

Jmv38

Bug (big):

my blendmode project (http://codea.io/talk/discussion/comment/44704#Comment_44704) now freezes codea. Used to work fine.

Jmv38

Bug (big):

many programs that compute sprites with setContext() just produce a black square, even with JakAttak patch for WIDTH and HEIGHT. I dont know what is broken.

Andrew_Stacey

I'm having issues with setContext not drawing, but I haven't been able to pin down the exact circumstances when it fails.

Simeon

Interesting, thank you for the reports. Does it make a difference whether you set the useDepth flag to true or not?

Andrew_Stacey

Got it, setContext doesn't work in the touched function.

function setup()
    img = image(100,100)
    timg = image(100,100)
    frame = 0
    touchn = 0
    parameter.boolean("inTouch",true,function()
        if inTouch then
            doredraw = function(i,a,c)
                redraw(i,a,c)
            end
        else
            doredraw = function(i,a,c)
                dolater = function()
                    redraw(i,a,c)
                    dolater = nil
                end
            end
        end
    end)
end

function draw()
    frame = frame + 1
    redraw(img,frame,color(255, 10, 0, 255))
    if dolater then dolater() end
    background(96, 70, 70, 255)
    translate(WIDTH/2,HEIGHT/2)
    sprite(img)
    translate(0,-200)
    sprite(timg)

end

function touched(t)
    touchn = touchn + 1
    if t.state == BEGAN then
        doredraw(timg,touchn,color(255, 208, 0, 255))
    end
end

function redraw(img,a,c)
    pushMatrix()
    resetMatrix()
    setContext(img)
    background(0,0,0,0)
    stroke(c)
    strokeWidth(30)
    translate(50,50)
    rotate(a)
    line(-50,-50,50,50)
    setContext()
    popMatrix()
end

I haven't tried the useDepth flag as I wasn't aware of its existence. If it is what I think it is, then I have a project just waiting for it.

Simeon

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

Simeon

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

Simeon

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

Simeon

@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

@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

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

Simeon

@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

@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

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

Simeon

@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

you decide. ;-)

Jmv38

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

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

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

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

Jmv38

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

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

Jmv38

i've edited the bug report. Thanks.

Jmv38

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

1) 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

2) 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

Simeon

@JakAttak @Jmv38 do you know how it came about? (Getting stuck.) Has it happened often?

@Jmv38 could you provide the 3000 line code that you tried to paste? Maybe on pastebin or something, so I can try it out.

@JakAttak I understand why you aren't able to exit during a printed infinite loop, but I'm not sure how to fix it yet.

Simeon

@Jmv38 the newest build 2.1 (6) should fix your issues with displayMode() and supportedOrientations()

Jmv38

@Simeon.
1/ the width and height problems seem solved. Thanks!
2/ here is the long code: http://jmv38.comze.com/CODEA_4/buttonLibrary.txt

toffer

Opening Shader lab always crash 2.1 (6) for me. Same issue when opening from projects drawer or shader picker. It stay 2/3 sec open and exit.

When opening from the edit button of the shder picker, the left panel is opened and nothing and the shader I've picked for editing is not here.

I don't know if it's project specific, testesd from an empty one and the shader sample.

toffer

Small thing, the text editor does not reflect the text size defined in user preferences. And I've never noticed before and that don't really matter but in the code editor, the text antialiasing look blurry with a size 16 > s > 20 than 14 15 16 or 20.

Simeon

Thank you @toffer. I must have introduced that issue when fixing the displayMode one. I'll look into the text size issue.

JakAttak

@Simeon, not sure how to reproduce it, I've tried a bit, but it seems to be random.

Luatee

Here's something stopping me from running my game.. Happened after I rewrote the readImage function and stays there even if I comment out that line, it appears as the normal error banner for a split second then goes, still unable to start the project with a red shade on the tab:
https://www.dropbox.com/s/0errst9falmmxp1/Photo 18-08-2014 00 32 35.png

Edit: Also happens even if I comment the whole page

Simeon

@toffer when you say the text size does not reflect the text size in user preferences — do you mean the text size specified in the Settings app on your iPad? Or the text size specified in the Codea settings panel? The latter seems to work fine for me, and the text looks okay here, are you able to show a screenshot?

@Luatee so the beta install issues are all worked out now? The next build should stop the errors from disappearing, so you should be able to see what it is then and let me know.

@Jmv38 @JakAttak I've optimized the code editor for pasting and deleting large amounts of text. Hopefully this will solve your issue.

Luatee

@Simeon they are, I lost a tiny bit of work but nothing of any worry. It seems a lot more responsive, I fixed the error and it was because of an error in a dependency that it occurred. I can reproduce it and send you a project if you'd like?

Jmv38

Suggestion:

When the program is stopped, this often occurs during the draw(). Then there is an incomplete drawing on the last image. This is functionnally ok, but gives a 'buggy' look to the project. Could you consider waiting to have finished the draw loop, for 0.2s max, before actually stopping the program? The feeling would be better.

JakAttak

If I switch apps for a couple of seconds, and come back, Codea is frozen and restarts itself. This is incredibly annoying and definitely did not used to be the case (note I am on iOS 8 so it could be a combination of that and the new update)

Simeon

@JakAttak are you sure that it's doing that in the latest build — 2.1 (8) ?

Andrew_Stacey

I think that the default ellipseMode has changed to RADIUS instead of CENTER as it says in the documentation.

JakAttak

@Simeon, I was on #6, oops. Appears to be fixed in #8, thanks.

Jmv38

Bug:

the button on top right of keyboard doesnt work any longer.

Simeon

@Jmv38 the play button? Or do you mean += (I think there is a bug with += where it is disabled inappropriately).

@Andrew_Stacey thank you, will look into it.

Ignatz

Just going back to when parameters fire, why not include an optional true/false parameter as Jmv suggests, and default it to the old behaviour? Then it is backwards compatible but allows us to defer execution if we want to.

JakAttak

@Simeon, for me both - play button never works when showing keyboard, only works 40% of time when keyboard is down. += button is often grated out when i should be able to use it. (Side note: table.number then += results in table.number = number + as opposed to table.number = table.number +)

Simeon

@JakAttak thanks, I'm aware of the second issue (+=), but I didn't realise the play button wasn't working. Is this something that has been happening recently, or has always happened?

Jmv38

I meant the play button. It worked in the previous build (i use it all the time)

Jmv38

edito bug.

put that in the editor:

TitleButton.rectStyle1 = {fill=color(0,0,0,0), radius=4, strokeWidth=2, stroke = color(0,0) }
TitleButton.rectStyle2 = {fill=color(0,0,0,0), radius=4, strokeWidth=2, stroke = color(128,128) } 

do you see the last "}" when the color circle shows? No. Not very good for inspecting for errors...

Simeon

@Ignatz I'd very much like to break the API and go with @Jmv38's original suggestion for only having the callbacks after initialisation. Still weighing the options. I might try it out next build so people can see what it's actually like.

@Jmv38 does the play button not work under specific circumstances, or when there is specific code? Was 2.1 (7) OK?

The colour circles should disappear when you are editing that line (the intention is that you need to see everything on the line you are editing, so they disappear).

Andrew_Stacey

(These are old issues, but still there.)

When pressing search then the top row of buttons disappears and I think it would be useful for it to stay.

When in the documentation browser starting from a lookup on a selection then it takes two presses of the eye to dismiss it.