Forward declared variables with Composer scene management (to Nil or not to Nil)?

Hi Guys/Gals,

 This thought has been in the back of my mind for awhile. It relates to forward declared variables that are used in conjunction with Composer scene management.

Say I have “scene1.lua” and “scene2.lua”, both that use the standard Composer template. Within “scene1.lua” assume I have a couple forward declared variables (above the scene event functions) such as:

local scoreText local score

(Referring to the example https://coronalabs.com/blog/2015/06/16/tutorial-scope-for-beginners/)

In the case of “scoreText”… I will later allocate a display.newText() object to it within the scene:create() function… and also add that object to “scene.view” so it can be managed by Composer. 

In the case of “score”, it is never allocated “scene.view”.

Say I then transition out of “scene1.lua” and into “scene2.lua”. Within the “scene2.lua”, I call 

local prevScene = composer.getSceneName( "previous" ) composer.removeScene( prevScene)

which should dispose of all objects that were managed by “scene.view” within the “scene1.lua” file. I take the wording dispose to mean it both removes that object from the display group and NIL’s out any associated variables for garbage collection (correct me if not the case). Therefore upon removing “scene1.lua” (from within “scene2.lua”) it should automatically handle for me:

display.remove(scoreText) scoreText = nil

However, since the “score” variable lived outside the scene functions (forward declared “file level” variable) and was not specifically inserted into “scene.view” within “scene1.lua”… if I do not explicitly NIL out the “score” variable within the scene:destroy function within “scene1.lua”… once I transition to “scene2.lua” and then call “composer.removeScene(“scene1”)” as mentioned above… does the “score” variable from “scene1.lua” become a (albeit small) memory leak? or does calling “composer.removeScene(“scene1”)” somehow implicitly do this:

score = nil

Thanks in advance!

Any taker’s on this one…? 

I did a little test by adding this tiny block below in “scene1.lua” (within the “file level chunk”) and transitioned in/out of the scene while using Roaming Gamer’s SSK easy meter. No climbing of Memory shown while transiting in/out…  

local bigOne = {} for i=1,1000000 do bigOne[i] = i end

I then thought… hmmm… maybe each time back in I am simply redefining the variable “bigOne”. So I tried something slightly different… I defined a global in “main.lua” :

myCounterVar = 0

Although not very glamorous  :wacko: code… I then wrote the following within the “file level chunk” of “scene1.lua” - 

local bigOne1 = {} local bigOne2 = {} local bigOne3 = {} local bigOne4 = {} if myCounterVar == 0 then for i=1,1000000 do bigOne1[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 1 then for i=1,1000000 do bigOne2[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 2 then for i=1,1000000 do bigOne3[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 3 then for i=1,1000000 do bigOne4[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) else print("In the else....er") end

Again… no climbing of Memory shown while transiting in/out…  

So it would appear that calling “composer.removeScene()” cleans out not just the objects managed by “scene.view”… but also NILs out any “file level” forward declared variables behind the scenes (no pun intended… okay… maybe slightly intended).

composer.removeScene() by default will un-require the module. At that point all of the local variables are cleaned up. You can call composer.removeScene() in a way that it does not un-require the module, but when you come back to it, you’re just reusing what’s there.

I don’t know of any one who nil’s out every variable they use. Make sure your display objects are in scene.view. Dispose of any audio you loaded in the scene and you should be good to go.

Rob

Thanks Rob, that makes sense… very much appreciated!

Any taker’s on this one…? 

I did a little test by adding this tiny block below in “scene1.lua” (within the “file level chunk”) and transitioned in/out of the scene while using Roaming Gamer’s SSK easy meter. No climbing of Memory shown while transiting in/out…  

local bigOne = {} for i=1,1000000 do bigOne[i] = i end

I then thought… hmmm… maybe each time back in I am simply redefining the variable “bigOne”. So I tried something slightly different… I defined a global in “main.lua” :

myCounterVar = 0

Although not very glamorous  :wacko: code… I then wrote the following within the “file level chunk” of “scene1.lua” - 

local bigOne1 = {} local bigOne2 = {} local bigOne3 = {} local bigOne4 = {} if myCounterVar == 0 then for i=1,1000000 do bigOne1[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 1 then for i=1,1000000 do bigOne2[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 2 then for i=1,1000000 do bigOne3[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) elseif myCounterVar == 3 then for i=1,1000000 do bigOne4[i] = i end myCounterVar = myCounterVar + 1 print("myCounterVar: ", myCounterVar) else print("In the else....er") end

Again… no climbing of Memory shown while transiting in/out…  

So it would appear that calling “composer.removeScene()” cleans out not just the objects managed by “scene.view”… but also NILs out any “file level” forward declared variables behind the scenes (no pun intended… okay… maybe slightly intended).

composer.removeScene() by default will un-require the module. At that point all of the local variables are cleaned up. You can call composer.removeScene() in a way that it does not un-require the module, but when you come back to it, you’re just reusing what’s there.

I don’t know of any one who nil’s out every variable they use. Make sure your display objects are in scene.view. Dispose of any audio you loaded in the scene and you should be good to go.

Rob

Thanks Rob, that makes sense… very much appreciated!