I’m new to the Codea forums, and I’ve enjoyed fiddling around with Codea quite a bit. I’m considering using it for an introductory CS class targeted at Jr. High students, but I had one reservation. I was interested in exploring computational complexity and computability, but I immediately ran into a challenge running longer processes to demonstrate scaling of computational load. I coded a simple Mandelbrot fractal generator, but rather quickly ran into the “Lua program has exceeded instruction limit” message with an image of any resolution higher than 90x90 cells. Now I expected this to happen when the code was embedded in the draw() function with the 30hz rendering cycle callback. But it the problem continued even when I moved the fractal generation code to run in the setup function where I imagined it would run once before the rendering cycle even started, without the cycle time limitation.
So now my question. Is there any simple way to either run a separate thread independent of the rendering cycle? Or is there any way to block the rendering cycle while computing something els? Is there any way to trap the rendering callback event or a precursor to it, or know about when it will happen so code can be written to deal with it intelligently? If not, I’d REALLY like to support adding those features ASAP!
My alternative would be to segment larger arrays that are updated on alternating runs through the rendering cycle.
I had a similar problem when writing a colorplot for 3D functions of type z=f(x,y). My first code showed a pretty poor resolution. A first help was to clean up the code as much as possible by reducing number of loops, if-then-else constructs , … as much as possible. This helped me in almost doubling the resolution, but in its end, I get the same error as alvelda does. I did not yet find any way to solve that problem. First I thought that the arrays are the problem, but when replacing the array with a direct function call (I mean, that I do not pre-process the data and store them in an array, but do the calculation on the fly, when I need that, to avoid large arrays of size nxn). Crazy enough this reduced my resolution, I got the error far earlier. My assumption is that this has something to do with the accessible memory. Or am I wrong in here?
Hi @alvelda, @CrazyEd
Please use setInstructionLimit(0) in your setup() call to remove the instruction limit – it’s there to stop people from setting up infinite loops and hanging their iPad.
ah cool. But re infinite loops I’ve definitely got stung by it so maybe not working correctly. Let me see if I can make a repro case
AWESOME! Works now. :et me refine it a bit and I’ll post some code.
Many many thanks Simeon for that hint! Now the plots look much nicer!
Which raises a couple of follow-up questions:
- Is there an in-between setting that allows a little more room, but still is a defence against infinite loops?
- If I get into an infinite loop and my iPad hangs, how bad a “hang” is it? Which button do I press and for how long to get my iPad back again, or is it a “connect to iTunes and restore from backup” hang?
I don’t have an answer to the first but concerning your second question I think that double-clicking the home button and killing Codea in the multi-tasking bar (holding down your finger until you see the small minus symbol and touching it) will kill the process.
@Blanchot is correct. It’s not bad, just annoying.
The in-between setting would be to carefully choose an instruction count that works for your application, as long as there is an upper-limit you can’t cause an infinite loop. The default instruction limit is set to 3,000,000. You could make this 30,000,000 or 100,000,000, and should have plenty of room to comfortably execute most projects.