@Simeon - Ok. yep in previous version too. That’s strange, why it not happen when rect size is power of 2 ?
Apologies for the big jump in build number (38 → 41). iTunes Connect has been having problems and it forced me to upload quite a few builds that got trapped in “Processing”
@Simeon The stretched image with different orientations is OK. The saveText and readText is OK.
@Simeon, readText now works which is great, and I’m not seeing the multiple copy buttons either.
@Simeon, a question about saveText: are they saved to the project or locally. What I mean by this is if I have an app and I push a new version, are the files saved with saveText replaced?
@Simeon - didn’t want to post this in a new thread as I’m running the latest 2.3 (41) build, but I noticed some weirdness with memory allocation / garbage collection that I wanted to get some feedback on…
-- GarbageTest
function setup()
print("Garbage Test")
--collectgarbage()
end
function draw()
background(50,0,0)
translate(WIDTH/2,HEIGHT/2)
fill(255,255,255)
fontSize(40)
text(collectgarbage("count"),0,0)
--collectgarbage()
end
Run the above and (on my iPad 3) I get a starting figure of about 528k that keeps increasing, I get the fact that the string returned from collectgarbage() will actually require some allocation but it seems to increase at a significant rate (several k per second)
Automatic garbage collection kicks in very sporadically (if at all - I’ve had the above run for a good 2-3 mins with an increasing counter that got up to over 1mb of allocated space).
If I uncomment the first collectgarbage() I get similar behaviour - but it starts at around 328’ish k
If I uncomment the second call (inside draw) then the count remains rock solid at 283k (which is what I’d expect).
I know there is some kind of set interval code to control when automatic GC is run, but I was wondering if it was working.
Also would it be worth adding an explicit call to the GC behind the scenes in the run time when setup() is complete?
@TechDojo I think that’s OK. Lua will determine when to do garbage collection, and Codea will force a gc when iOS triggers a memory warning.
For me, your example gets up to about 800K then drops down to 500K and hovers there, occasionally collecting once in a while.
It’s better to let Lua decide when it’s optimal to garbage collect, forcing it will hurt performance.
@Simeon - fair enough I just wanted to mention it incase it was relevant 
Just want to say thanks to all of you for your great feedback and testing. Codea would be no where near as good without all your help.
@Simeon neither would it if it wasn’t for your dedication so thank you and the rest of the team for all your hard work.
Well done @Simeon - another great release in the offing 
@Simeon, I agree with the others, it’s you that should be getting the thanks for all your hard work in making Codea the amazing app it is.
@Simeon - I’ve had so much fun the past two years, I don’t know how to thank you
^:)^ ^:)^ ^:)^
@Simeon codea has been THE thing which has helped me learn alot about coding, I was a total noob, didn’t know what classes were etc, thanks to codea, I’m now able to make decent programs (though not as complicated as someone like dave or ignatz, … could do)
So thank you and all of TLL for making and maintaining this amazing app <3
Yeah, a big thanks to you TLL to have build and constantly improve Codea. You guys rocks!
@Loopspace, @Ignatz - Apologies if I’ve already missed this, but I just downloaded the 3D Shape library with a view to playing with it in the latest beta and it’s falling foul of Lua 5.3 (mostly to do with variable args). Do you have an updated version that works with the new setup or would it be easier if I fix it and submit the code for review?
Just found this really annoying bug. If you go into settings and put zoom on, and put the low light filter on, when you go onto codea, the screen randomly flickers black. It’s not only on the beta.
@TechDojo Loopspace can’t read this thread as it’s in the Beta testers category. The 3D shape library has been updated to run in the beta, I’ll see if I can prod loopspace to post the update to github.
Oh, hang on. I just looked at the code and I think that it is only the discreteNormal that uses the ... stuff. Try replacing that function with:
function __discreteNormal(a,o,...)
local arg = {...}
local n = #arg
local na,nb
na = vec3(0,0,0)
for k=2,n do
nb = (arg[k] - a):cross(arg[k-1] - a)
na = na + nb/nb:lenSqr()
end
na = na:normalize()
if na:dot(a-o) < 0 then
na = -na
end
return na
end
and see if that fixes it.