@Simeon couple of issues with new editor. Searching for rect in my code which were all commented (—) out, just to check. The comment lines were not present in the code listing hits on find - no big deal but, the last hit was quoted as on line 35 but was actually line 37. Looks like listing doesn’t count blank lines - two blank lines in code above the last hit.
Note re-ran this and commented out all rect lines and the search was correct and included the comment lines in the hits ca’t explain. Photo to show this included.
@Simeon Here’s something that needs a little adjusting. Type the line a=b in setup like I have below and then hit the tab key multiple times to add a comment farther to the right.
@Simeon Did you remove the automatic collectgarbage(). The below code shows the memory usage. Tap the screen to create a 5,000,000 occurance table and view memory usage. Tap again to clear the table. I was expecting to see memory decrease after awhile, but after 5 minutes memory usage wasn’t cleared, but was still increasing. Tap the screen again to force a collectgarbage and memory returns to normal.
function setup()
tab={}
fill(255)
w=0
print("tap screen to create table")
end
function draw()
background(40, 40, 50)
str=string.format("memory %20.6f",collectgarbage("count"))
text(str,WIDTH/2,HEIGHT/2)
text(os.date(),WIDTH/2,HEIGHT-100)
end
function touched(t)
if t.state==BEGAN then
w=w+1
if w==1 then
for z=1,5000000 do
tab[z]=z
end
print("table created, size "..#tab)
print("tap screen to clear table")
end
if w==2 then
tab={}
print("table cleared, size "..#tab)
print("tap screen to collectgarbage")
end
if w==3 then
collectgarbage()
print("collectgarbage")
end
end
end
@dave1707@Simeon - just ran this demo above and the error is obvious.
Can you both tell me if any project running should hold at a steady memory usage level (as long as there is no interaction). I added an extra line with if w > 3 then collectgarbage() and the memory decreases to ~ 700 and then continues to rise. Repeated touches reduce it to ~700 and the process cycles again. Should the memory usage remain constant?
This could explain some of the dropouts from Codea I have seen since 160 was introduced.
If the memory usage continues to rise - what are the activities which cause it?
My iPad has a lot of memory, is Codea allocated a fixed memory slot by iOS (or a fixed range slot?). The dropouts would be inconsistent - depending on machine memory size etc. Also does Codea free memory up if you switch from one project to the next?
@Bri_G It used to be that memory usage would increase but after maybe 30 seconds there would be an automatic collectgarbage to reduce it. It would drop back down and then increase again. Collectgarbage would kick in again to reduce it. It would continue to cycle that way. I’m not sure in which version this stopped.
PS. This does the same thing on version 148.
PS. This does the same thing on my iPad 1 version 1.5.5 (21) .
If I don’t tap the screen and just watceh the memory usage increase, after it reaches a certain point, it start to go down. After awhile it increases again and then starts to decrease. So I’m not sure what’s really going on when a large table is redefined.
So the question is, should we manually collectgarbage when we think we need it or should Codea do an auto collectgarbage.
If I modify the above code to redefine the table and create the table again when I tap the screen, the memory usage just increases each time until Codea crashes.
@Simeon Run this code. Keep tapping the screen to double the numbers. Eventually Codea crashes.
PS. The values of vec2, vec3, and vec4 cause Codea to crash at different values. vec4 crashes at the value after (524288.000000, 524288.000000, 524288.000000, 524288.000000).
function setup()
a=vec2(1,1)
end
function touched(t)
if t.state==BEGAN then
a=a*2
print(a)
end
end
@dave1707 the memory behaviour is interesting. I believe the Lua VM decides when to collect garbage. I’m not sure exactly how it decides but it’s supposed to trigger when necessary. The behaviour may have changed as we updated versions of Lua
@Simeon I’ve used number * vec a lot, but not the vec * vec. I thought that vec4(2,4,6,8) * vec4(2,3,4,5) would have resulted in vec4(4,12,24,40). I’ve never tried doing that before and was surprised when it didn’t work.
Have you looked into why Codea crashes when number * vec get large values and why the values are different for the different vec sizes. Maybe instead of crashing, it could return inf or nil values.
The memory problem was a surprise to me. I thought there was an auto collectgarbage when needed. In my above code, if I just let the code run, memory would increase and there would be a collectgarbage to reduce memory. That would cycle every so many seconds. One thing I noticed with the code was if I created the table and then reinitialized it, the memory wasn’t reduced. If I would then let Codea increase it’s memory with the table memory, a collectgarbage would run and reduce memory but not clean up the memory from the initialized table. It’s like the auto collectgarbage would clear the normal memory increase but not the table memory. A forced collectgarbage would reduce the table memory. There must be two different collectgarbage routines.
@Simeon Why does print( vec4() ) show (0.000000, 0.000000, 0.000000, 1.000000) and not all zeroes. Or that print( vec4(1,2,3) ) prints a 1 for the missing 4 position.
@dave1707 - is that due to vec4() ‘s association with the alpha value in colour representation defaulting to 255 - which I think is 1.000000 in OpenGL.
@dave1707@bri_G the default w component of a vec4 is 1.0 because typically when you use vectors to represent 3D points in space, and want to transform them with 4x4 matrices, you set the w value to 1.0