I can’t figure out what’s causing it, but since the latest update, Codea is crashing pretty frequently. It always happens while I’m editing code. I’m usually just typing or deleting something when Codea suddenly closes. If it helps, I have the latest version of Codea on the latest version of iOS.
It’s not impossible to keep coding and make progress, but it’s a bit frustrating 
That sounds frustrating! Is there anything you are doing that could help us pin this down. Does it occur in a particular file, or project?
Edit: are you on version 3.10 or beta 3.10.1? Are you opted-in to sharing analytics with app developers (just wondering if I will be able to see your crash logs on this)
If you are not on the beta, would you be able to join so we can try to address your crash issues?
I’m using 3.10, not the beta. I’d be happy to try out the beta, but I’m not sure how I get access.
I’ll do more research, but so far I can’t pin down anything. I thought it was only when I was typing, but earlier today Codea closed after about 20 seconds when I hadn’t done anything but open a file. I’m using shaders (written as part of the code) in a new project, and haven’t tried working on another project that doesn’t use shaders, so maybe there’s something in that?
I’ll keep trying things out.
I’m running the latest beta (not the latest iOS)
I have the same issue, codea will suddenly close without any crash screen and it happens while editing code, I’ve only had it happen after testing the project, going back into the editor it can continue to run just fine but might suddenly crash usually just as I tap some other part of my code, not another tab but just moving the text cursor. maybe that helps?
With the latest beta i am also experiencing frequent random crashes while editing. When it crashes it does not offer the possibility to send a crash report.
I also see that my code is running much slower than before. Something is seriously wrong.
Thanks everyone for pointing out these issues. I’m trying hard to debug and reproduce them so we can fix it.
@piinthesky is this the rendering that is slower in the latest version?
@sim it is a loop where i create hundreds of entities and add a sphere model to each and then set all their properties- so i guess it is connected with creating entities. I’ll keep trying to narrow it down.
@sim the line that slows everything is setting the material of the model
mys.material = craft.material(asset.builtin.Materials.Standard)
Hope that helps.
By the way, while trying to figure that out i had some crashes which did allow me to send a crash report.
@sim if i load the material to a variable before the loop and then use the variable inside the loop, it is very fast. Should have done that before!
It seems the access to the builtin.Materials has slowed down a lot in the newer beta versions.
Great find on the slowdown! I think I know why that is (and unfortunately, it may not be fixable in a safe way)
Basically we had to restructure how assets are loaded via asset keys (eg asset.folder.File). Because an asset can be located anywhere, we have to inform the operating system that we intend to read the file. This gives other applications an opportunity to save it if they have the file open. We also have to ensure that we resolve any security tokens in case the file lives outside of the application sandbox (e.g., you may have it in iCloud drive, or somewhere else on your iPad)
It’s even possible that you refer to an asset that has not yet been downloaded by iCloud, and Codea will wait for it to download when you refer to it via asset key
This overhead slows down the resolution of the asset key. We could probably implement a fast-path for assets located in builtin and in documents, but it’s probably not worthwhile. I would suggest doing what you did — load the asset when necessary and not during every iteration of your loop
Previously Codea didn’t do this. And much of the time, it worked fine. But sometimes when using external assets, they would just stop working because Codea did not correctly indicate its intent to read the file
@sim glad we figured it out! I don’t think a fast-path is necessary.
Update on this: I think we will have many of the crashes fixed in the next beta build. Should be out shortly