Codea Beta 2.3.1 (47)

@Simeon I added this line of code at the end of draw and the memory usage just keeps increasing until it closes.

    text(collectgarbage("count"),WIDTH/2,HEIGHT/2)

@Simeon It appears mesh isn’t releasing memory. If I run the code below, memory usage constantly increases even though collectgarbage() is getting called constantly. If I comment out the mesh line in arc(), memory doesn’t increase at all.


function setup()
    fill(255)
end

function draw()
    background(40, 40, 50)
    for z=1,20 do
        arc()
    end
    text("memory used  "..collectgarbage("count")//1,WIDTH/2,HEIGHT/2)
    collectgarbage()
end

function arc()
    local  m=mesh()
end

Thanks @dave1707, that’s really helpful!

Hi All,

Just a thought - I’ve been playing around with this and come to the same conclusion as @dave1707, but for my own clarification - is it OK to declare a local mesh in a sub function of draw and then use m:draw() from the sub function? If you move the m:draw() to the draw function after the calls there is an error that m is not declared. I tried building the mesh in the setup and editing the mesh components separately but it didn’t work - I’m assuming you have to repeatedly build the mesh to facilitate any changes in it.

Way above my level - leave it to @Simeon.

Bri_G

:smiley:

Thanks everyone, I fixed the memory leak in mesh. I’ll update the Xcode runtime so that everyone who exports apps is not affected, and the next version of Codea will include the fix.

@Bri_G

You said:

If you move the m:draw() to the draw function after the calls there is an error that m is not declared.

This would be because m would be a local variable to the sub-function of draw().

Thanks @Saturn031000,

Brought up on minimising memory etc I don’t like the idea of building structures using them, destroying them and rebuilding them. I can see that in animation etc it is necessary. The use of the local definition in a sub function seems a bit counter intuitive. The local aspect should destroy the mesh on leaving the function, but ideally you need to destroy the mesh at the end of each draw() loop outside of the mesh function. I think it may have contributed to the memory drain problem.

Thanks for confirming my thought processes.

Bri_G

:smiley:

@Simeon - my beta copy of Build 47 expired 23 minutes ago :frowning:
Is there another beta in the works or has the latest version been submitted yet?

(or did I miss the latest version???)

EDIT - Looks like I did - how did THAT happen! :slight_smile:

EDIT 2 - However now I have the issue that I can no longer access files via iExplorer as I’ve had to install the latest version via the app store :frowning:

My version expired also. I had to reload the old App Store version.

And me. Looks like the last release hit its due date. If there’s a newer one in Testflight, I don’t see it.

One of the things the old Testflight did better IMO… I liked that the builds never expired.

@JakAttak eventually old builds expired when the profile expired.

The latest TestFlight beta you had access to was identical to the App Store version. I will look into the iTunes File Sharing key being enabled for future builds (hopefully Apple will allow).

Sorry I disappeared for the last week or so. Just had my second child, so I have been pleasantly preoccupied :slight_smile:

=D>

@Simeon, I stand corrected :slight_smile: Certainly they lasted longer than 30 days.

Congrats on the child! =D>

@Simeon - congrats dude, I guess now all your (very little) spare time will be spent making amusement and educational app’s for babies with Codea (that and feed trackers, height and weight trackers etc etc)

:slight_smile:

@TechDojo I’m not so sure. My three year old and I play Cities: Skylines together constantly. So we’ll probably stick with making simulations.

@Simeon - congratulations to you - and your partner! :-bd

Congratulations!

Not really beta (47) related, but it didn’t seem worth a whole thread just to say that I’ve been running Codea against each step of the iOS 9 beta and have had only a few problems. The most consistent issue is the way the new keyboard is laid out with the cut / copy / paste keys, which pushes the extra codea row higher and obscures more of the screen. However, it’s not a huge issue. The appearance of the popup copy / paste options within the editor has become spotty, often forcing me to use those new keys rather than the popup values. This may be Apple’s intent, but if there’s a pattern to when I get a popup and when I don’t, I don’t see it. Also, there’s sometimes a blank area above the keyboard that extends significantly into the text, but disappears if the keyboard is closed.

That’s about it. Programs compile and execute just fine. I think I’ve had one complete app-closing failure after a long session of coding, but I saw those occasionally under 8.

@Mark I have removed the extra keyboard keys in the current dev branch. Thanks for the report on the copy/paste menu items not appearing, I’ll give it a try.