Beta 1.5.5(5)

I figured this would be the place to compile info on openURL() stopping the draw() function from resuming on close.

This may relate to the amount of data being transferred. If you browse for a bit, then close openUrl, draw will not continue. To test this I placed the codea icon in the center of the screen. If it stops drawing, then the screen goes black. I can replicate this fairly often but in some tests I can go awhile without an issue.

Sometimes if you close and run the project again, it will be fixed. However, I usually must close codea.

After the draw stops and you open another app, the app will ghost behind codea upon returning to codea. This happens both while the project is running and while in the code editor. This is fixed by clearing codea from memory and restarting.

I used this project to duplicate the issue:

function setup()
   parameter.action("url",function() openURL("",true) end)
function draw()
        background(255, 255, 255, 255)
        sprite("Cargo Bot:Codea Icon",WIDTH/2,HEIGHT/2)

I will keep playing with this to see if I can narrow down what’s causing it.

Unfortunately this build did not solve my stability issues :frowning: After about 5-10 minutes of hacking around and running my programs the text editor goes wacky, (large chunks of text start disappearing completely or getting corrupted) and usually takes a close and restart to fix. If I don’t restart, the app will usually crash. Not that I usually get that far, since the fear of losing work once the editor goes on the fritz compels me to restart the app immediately. I’m on an iPad 4 with 6.1 if that makes a difference.

Is this problem due to new beta 1.5.5 branch? I am still under 1.5.4 and i dont see such stability problems. However, i do see the editor starting to get lost after many hours.

@Jmv38: no, I had this problem in 1.5.4 as well. Honestly I’m not sure exactly which build I began to notice it.

@toadkick are you using a http.request that has a callback?

@Simeon: no :frowning: I’m aware of that issue, but unfortunately that’s not the problem in my case.

@toadkick I see these problems still with long lines of text. If I work in portrait mode and line break the text before it runs to the next line, my stability seems to be greatly improved. YMMV.

@Mark: I try to keep my lines short enough to fit in portrait mode, but there probably are a few I missed since I usually code in landscape with my keyboard. I’m thinking long files might be part of the cause also, though I generally try to keep my files less that 500-600 lines.

@toadkick I have fixed some issues with the editor and hopefully it helps with your issues. I will send out 1.5.5 (6) shortly.

Out of curiosity, @toadkick, are you switching between projects often? (Perhaps a dependency and your main project?) The bugs I fixed relate mostly to this scenario.

@Simeon: Actually yeah, I’m switching between 2 projects somewhat frequently. Looking forward to the next build, thanks!

@toadkick new build is out. Please let me know if it helps with your issues.

Thanks @Simeon! I’ll get back to you tomorrow with an update.

@Mark so it is crashing then? The line break issue is separate and is something I am working on as well (but it is not fixed yet).

@Simeon At first glance, I seem to be having longer between crashes with new version. However, I’m still seeing odd behavior with long strings. Attempting to edit a string that extends past the line break results in unpredictable behavior.

@Simeon No crashes so far. I’ll let you know.

If it’s feeling generally more stable I might submit this as an interim update before 1.6.

The PDF feature in (7) is spiffy. Among other things, it’s very handy for providing instructions, “about,” etc.

I agree with Mark. Thanks a lot!

Yay for PDF selection by pages! Thanks for that.

I’ve just registered a bug with spriteSize on a PDF on the issue tracker. I hope it is clear what I meant.

@Simeon: I’m happy to report that Codea seems much more stable. I’ve been hacking around most of the day now without any issues :slight_smile: