@sim I have an old project that lists the names of variables, functions, etc in Codea. However when I tried to run it with V4, it doesn’t like some of the variables that show as type table. One example is animation. The below code prints type animation as a table, but the pairs loop errors out. Just wondering if those type of variables need a different type or how to identify them as not being a table.
function setup()
print(type(animation))
for a,b in pairs(animation) do
print(a,b)
end
end
@dave1707@sim@John - before I describe the issue - I know this is a stupid mistake but I think it should be trapped anyway. See the code below selecting photos to display. If you leave the image first loaded Codea would carry on until the batteries go flat. But if you change the image with the parameter it’s stays for a while then Codea crashes but I haven’t seen a crash dialogue with it. If you remove the rem comments from the line in update it cures the problem. This is obviously due to memory being consumed rapidly. Is there any way to trap this. (Please use your own images).
function setup()
--
parameter.integer("pic",1,#pics,1)
temp = readImage(pics[pic])
current = pic
end
function update()
--
if current ~= pic then
temp = nil
temp = readImage(pics[pic])
-- current = pic
end
end
function draw()
--
update(DeltaTime)
background(40, 40, 50)
spriteMode(CENTER)
sprite(temp,WIDTH//2,HEIGHT//2,WIDTH,HEIGHT)
end
Because you commented out the line current = pic, every frame the program will load the image and store it in the temp variable. The line temp = nil doesn’t do anything really since you assign to it on the next line. This program (if the image is a bit large) will essentially load a huge number of images as quickly as possible into memory, which may not be garbage collected until later and may crash due to running out of memory (since collection doesn’t happen frequently).
Lua normally does garbage collection for you automatically when you use up too much memory, however image data is allocated in a separate step, so Lua has no idea how much memory is being used and thus you need to trigger collection manually in situations like this. There’s not much we can do to detect it either
@Bri_G I’m not sure how that could be trapped. It’s a logic error. Computers do what you tell them to do, not what you want them to do. In this case, you were constantly calling readImage until memory was used up and Codea crashed. I remember those kind of crashes a lot when I first started using Codea. I still get them every now and then.
@John - thanks, I realised what was happening but hopef there was some way I could trap it. I assume the speed of memory consumption overcame the Codea error trapping and reporting.
Are there any system variables that we can access for optimising and avoiding development issues like memory limits and processor occupation other than FPS?
@Bri_G Maybe you can try something like this. This determines how much memory is being used. If it exceeds a certain amount, you can do whatever you want.
function setup()
end
function draw()
background(0)
text("KB Memory used "..collectgarbage("count")//1,WIDTH/2,HEIGHT-100)
mem=collectgarbage("count")
if mem>1150 then
stop() -- this causes an error
end
end
@John I know the stop() function doesn’t exist, but when the code is run under V3, the program stops because of an error. Under V4, it looks like the code is still running because the memory is constantly increasing.
PS. I use the stop() call to cause an error and stop the program when I’m testing code.
@dave1707 i see what you mean, V4 doesn’t pause when receiving an error. Maybe this can be an option from now on with something like viewer.pauseOnErrors = true|false
If you want to trigger an error you can also just do error(msg)
Here’s something interesting about errors in V4. According to the above comments, V4 continues to run after errors are found. In the code below, I force an error when memory is above 2000. ( You may have to change that value). In the first draw function, I have the error code after all the other code. Everything continues to run when the error happens. In the second draw function, I moved the error code up and the code after the error code doesn’t run when the error occurs. “change draw1() to draw()”. Not sure of the purpose to continue running a program when an error is detected.
viewer.mode=STANDARD
function setup()
x,y=WIDTH-200,100
end
function draw()
background(0)
text("KB Memory used "..collectgarbage("count")//1,WIDTH/2,HEIGHT-100)
mem=collectgarbage("count")
sprite(asset.builtin.Planet_Cute.Character_Horn_Girl,x,y)
y=y+.1
text("y = "..y,WIDTH/2,HEIGHT/2)
if mem>2000 then
error("mem greater than 2000")
end
end
function draw1()
background(0)
text("KB Memory used "..collectgarbage("count")//1,WIDTH/2,HEIGHT-100)
mem=collectgarbage("count")
if mem>2000 then
error("mem greater than 2000")
end
sprite(asset.builtin.Planet_Cute.Character_Horn_Girl,x,y)
y=y+.1
text("y = "..y,WIDTH/2,HEIGHT/2)
end
@dave1707@sim@John - modified your trap system and added to the image changing code I posted before but as a function. Function code below. Trapped the error and posted multiple times the value of mem. Also reported the error in a red error bar - image attached.
But, whilst posting this report Codea crashed. Crash report posted.
function errTrap()
-- trap errors before crashing
mem=collectgarbage("count")
if mem > 1000 then
error("mem report count = "..mem)
end
end
@dave1707 the error() function in Lua works like an exception, so any code after it will not be run since execution stops (redirected to the error handler code) at that point
@John@sim Here’s a question I asked awhile ago and I think it got overlooked. Just wondering if there’s a way around this.
I have an old project in V3 that lists the names of variables, functions, etc in Codea. However, when I tried to run it with V4, it doesn’t like some of the variables that show as type table. One example is animation. The below code prints type animation as a table, but the pairs loop errors out. Just wondering if those type of variables need a different type or how to identify them as not being a table so I don’t try to iterate thru them.
function setup()
print(type(animation))
for a,b in pairs(animation) do
print(a,b)
end
end
@John@sim @ dave1707 - just reported an error in the latest beta, when running V3. Thought I’d put it into an infinite graphics loop but I didn’t. It was due to a print statement in a loop in the draw() function. Crashed twice on me before I realised, added collectgarbage() but didn’t help.
Removing the print statement worked fine.
Another V3 error, which may also be in V4, is that when I tapped on a low line in the editor to amend code the keyboard is pushed up over it and the editor doesn’t scroll with it. Annoying rather than a serious error but would be nice to have it corrected.
Edit: could someone post up the links to the carbide error spreadsheet, and - where do we post V3 errors on the forum when using the latest beta?
As you might be aware, in V4 we use the sol2 lua bindings library. One of the main differences from other lua bindings libraries is the use of an opaque runtime format. Meaning that the inner workings of type tables is not exposed or intended to be user-friendly, and is also subject to change. Its possible that there are some metatable shenanigans happening which is preventing pairs() from functioning properly. It’ll probably take some digging to figure out how to introspect the type table
