Specifically - I’d like to capture both error messages and warnings, for my own cunning plan to be exposed at a future date.
I know I can use pcall() (well - I haven’t tried it, but I should be able to, yes?) - but will that actually catch the error messages, and warnings? I suspect not. I also expect pcall() is going to slow things down, although I have no evidence of that.
time passes…
ok, I lied. pcall is there, but doesn’t work as I expected. There is a VERY good chance I’m simply expecting the wrong thing.
I’m trying to be able to do the “right thing”, whatever that is, for errors and warnings when you run fullscreen. Just sayin.
I DARE NOT SHARE MORE OF MY CUNNING PLAN. I DARE NOT!
I don’t like the Codea console. I rarely use the parameter commands, and the useful part is teeny and print() is so slow it’s difficult to use - I often will put it inside a deep loop, and the effect is to simply hang Codea.
But - I use print for debugging and testing a lot. So - I wanna replace it.
I’m working on an “overlay console”, like the old Quake console - errors (or text or whatever) printed just floats transparently over the rest of your graphics. Then you can go fullscreen, and your debugging print statements (or whatever) just float out over the screen, semi-transparent.
And what I really want to do is make it transparent to use - so you could enable it with a line or two, and be done with it. The idea is to store the font and it’s code in global persistent memory - you’d run an installer that dropped 8-10k of code in your global memory, and then any program could use the new console with a couple of lines. I’m not sure, but I think I can even override print() to go to the new console instead.
The problem is - right now, if you have an error… you just hang, and you can’t see the old console to see what’s going on.
Hmm you can’t actually override print() and have errors go through your version, since Codea puts errors straight through to the console.
I can add an error() function that gets called for errors instead, and you’ll be able to override that.
I was actually hoping to have a built-in overlay console for runtime errors, since I didn’t feel they were appropriate for the output console. Also there definitely ways to speed up the output console that I will implement in a future release.
@Bortels, picking up on what you said there about putting code in storage. That sounds pretty cool I think. If you store code in GloabalProjectData and load with loadstring, then it becomes a library that’s available from anywhere.
Yep. It scares me a bit, frankly. It becomes a poor-mans file system, with no real management and no permissions. We need to proceed carefully, or it could be a mess.
