Is there an oversight with the physics library?

[XeduR]

I’ve been polishing the code for one plugin that I am planning on releasing next week, but while doing so, I think I may have stumbled across a bug.

I have three files: main.lua, myScene.lua and myLibrary.lua. I don’t require the physics library in any file. In main.lua, I check to see if physics exists by trying to print it. I also try to check if it exists in the myLibrary.lua by requiring it. As expected, physics is nil in both files.

However, after using composer to move to myScene.lua and checking to see if physics now exists, I get a table in both myScene.lua and myLibrary.lua files. So after using composer.gotoScene, the physics library has mysteriously been required.

Here’s the code.

main.lua:

print( "main", physics ) -- nil local myLibrary = require( "myLibrary" ) print( myLibrary.check() ) local composer = require("composer") composer.gotoScene( "myScene" )

myLibrary.lua:

local lib = {} function lib.check() print( "myLibrary", physics ) end return lib

myScene.lua:

local composer = require( "composer" ) local scene = composer.newScene() local myLibrary = require( "myLibrary" ) print( myLibrary.check() ) -- table: 04025818 print( "myScene", physics ) -- table: 04025818 -- since physics library suddenly exists, I can start it and create physics bodies physics.setDrawMode( "hybrid" ) physics.start() local rect = display.newRect( display.contentCenterX, display.contentCenterY, 100, 100 ) physics.addBody( rect ) return scene

I have also attached the project. If it isn’t a bug, could someone enlighten me as to why this is happening?
 

[schroederapps]

@XeduR: The Composer library requires in the physics library, so as soon as you call require('composer'), the global physics variable has been established (because requiring physics, even as a local variable, results in the global _G.physics variable being defined).

You can see where physics gets required by composer here: https://github.com/coronalabs/framework-composer/blob/b6b4bf4dcaeb895cb1e294c0cc9ea1ea780b2a54/composer_scene.lua#L18

And you can see how the physics library establishes a global ‘physics’ variable by running this simple main.lua in the simulator:

print(\_G.physics) -- prints out nil local physics = require('physics') -- sets local physics variable print(\_G.physics) -- prints out table pointer

If there is a bug here, it’s in the establishment of a global variable when requiring the physics library: but calling that a bug might be presumptuous. It’s not out of bounds for the framework to define a library in the global namespace (i.e. display.*). You might also take issue with the composer library utilizing physics: but since it’s open-source you could always fork it and modify it to work without physics if you wish.

[XeduR]

@schroederapps, thanks for the info! So it definitely isn’t a bug. I might do exactly what you suggested and fork it.

[anon63346430]

Well… I can’t see the point in composer_scene?  And why it needs physics also - why does a scene manager need joints, newText, newImage, etc?

[roaminggamer]

I’m sure that the Corona staff decided that it would be helpful to require the physics library for users, since most action games use physics, and one would suppose many new developers will want to make action games.

[XeduR]

I’m with SGS in wondering why things like physics, joints, newText, newImage, etc. are needed in a scene manager.

I understand the usefulness of the physics library, after all, I’m working with it constantly. I had, however, previously worked under the assumption that if I need it in my projects, then I needed to explicitly require it. Since I use composer in almost all of my projects, it turns out the physics library is in almost all of my projects regardless of whether I need it there or not.

[anon63346430]

It looks like  composer_scene.lua loads a JSON file, parses it and creates UI and physics objects. 

I’m wondering if this was some a test unit for making scenes whilst developing/debugging the composer library and it actually is a lazy bug/bad management to include that into production?

[richard11]

Hmm. I personally only use Composer for its transition effects, (lazy I know), but if it’s including other frameworks just for the sake of it, then I might have to be less lazy next time.

Would be interested in any benchmarks somebody might have done with this. Do we know how much it adds to the size of an APK? Any runtime performance impacts? Memory usage?

[rob]

I think I have an explanation. Years ago, we created storyboard 2.0, but because of breaking changes, we chose to give it a different name. At the same time we started creating a visual UI named Composer. This UI would create code using the new scene manager which we also called composer.* APIs. with the expectation that everyone would use the UI and to load the needed features, we probably included some of the libraries like physics for you. 

While we don’t like globals specially for users who don’t understand scope and the bugs created by that and are hard to track down, including “system” libraries like physics in global space is okay. Its the way Lua does things like math and table for instance. Corona also includes network, display and audio for you all in global space.

This is a historical curiosity and a few kbytes and not a lot more.

Rob

[davebollinger]

Adding further to Rob’s history, fwiw, and my $0.02:

Once upon a time there was NO built-in scene manager.  Then there was Director (a third-party scene manager).  Then Corona borrowed ideas to create Storyboard (a scene manager).  Then Storyboard was rebranded as Composer (a scene manager, essentially “Storyboard 2.0”).

Composer also contained new code to support the development of “Composer GUI” (which was NOT a scene manager in-and-of-itself, but rather a short-lived wysiwyg scene “designer”, built on top of the actual scene manager: Composer).  Presumably to make that new code more manageable, they split out some of the scene-specific code from composer.lua into composer_scene.lua.

Composer GUI allowed you to define some basic physics properties on the display objects defined in the scene - in this way you could create simple physics-based “apps” without coding.  Or, at least, that was the plan…  though the wysiwyg designer never reached the stage where you could actually do anything truly “useful” with it.  But that is why composer_scene requires physics.

Aside:  The physics library itself leaks a global “physics” probably because it was implemented with the old-style module system via package.seeall.  (we don’t know for sure, as they haven’t open-sourced that one yet, but it’s a reasonable guess given its age)  But there’s no “good” reason that it should leak.  (ie, it could easily be rewritten with modern module style to eliminate that leak)

Composer GUI is now abandoned and long-dead.  Thus, the vast bulk of code in composer_scene.lua (including the require of the physics library) is now completely useless (and almost all of which is completely undocumented, including some that was apparently abandoned in-progress/incomplete).

IMHO, “Composer GUI” should never have been so tightly “bundled” with Composer.  (IMVHO they shouldn’t have wasted their time on Composer GUI in the first place!)  It should have been a separate require, (with self-contained functionality where possible/feasible, and monkey-patching scene only if/as needed, in much the same way that widget monkey-patches display), so as to leave Composer “clean”.

As it stands, Composer is now in need of a “Composer 2.0” overhaul to clear out the “junk” from the Composer GUI era.  It would be similar to the Storyboard->Composer rebranding all over again, except in reverse. (instead of adding code to support Composer GUI, it’d be to remove that code)

[StarCrunch]

@davebollinger

Aside:  The physics library itself leaks a global “physics” probably because it was implemented with the old-style module system via package.seeall.  (we don’t know for sure, as they haven’t open-sourced that one yet, but it’s a reasonable guess given its age)  But there’s no “good” reason that it should leak.  (ie, it could easily be rewritten with modern module style to eliminate that leak)

It’s done here and when used like that with a name, luaL_register will assign the global. Would be a quick fix but who knows how much code now depends on having it.

[davebollinger]

@StarCrunch

It’s done here and when used like that with a name, luaL_register will assign the global. Would be a quick fix but who knows how much code now depends on having it.

Hah!  That’s what I get for not browsing source before posting!  :D  Guess I assumed there was a thin lua wrapper sitting in there.

…cuz…

Given the way it’s implemented it seems odd that it wouldn’t have just “always” been a preloaded part of core (like “display”, “graphics”, et al).  Then it’d be a moot point.

Agreed (re regression) - it’s too late to discuss “shouldn’t leak”, except to suggest that it “shouldn’t have leaked”.

[roaminggamer]

@XeduR

I’m with SGS in wondering why things like physics, joints, newText, newImage, etc. are needed in a scene manager.

I understand the usefulness of the physics library, after all, I’m working with it constantly. I had, however, previously worked under the assumption that if I need it in my projects, then I needed to explicitly require it. Since I use composer in almost all of my projects, it turns out the physics library is in almost all of my projects regardless of whether I need it there or not.

I’m late in coming back to this discussion, but wanted to say that whether it is required or not, physics will always be built into your project. so if this discussion is predicated on the idea that “If I require it, it costs me more memory.”, then we should but that idea to bed.

‘require’ it, don’t ‘require’ it.  The binary size won’t change.

[anon63346430]

well… if you never use physics (like me) then it should never be included in the build.  but saying that nor should a whole heap of stuff (like themes, etc)

[roaminggamer]

It is always included in all binaries.  Unless something has changed, it is a core library.

In a perfect world, we would only get what we use in our binaries, but it just isn’t that simple. 

Also, this is part of the price we pay for using (at least partially if not fully) pre-compiled binaries.

[schroederapps]

@XeduR: The Composer library requires in the physics library, so as soon as you call require('composer'), the global physics variable has been established (because requiring physics, even as a local variable, results in the global _G.physics variable being defined).

You can see where physics gets required by composer here: https://github.com/coronalabs/framework-composer/blob/b6b4bf4dcaeb895cb1e294c0cc9ea1ea780b2a54/composer_scene.lua#L18

And you can see how the physics library establishes a global ‘physics’ variable by running this simple main.lua in the simulator:

print(\_G.physics) -- prints out nil local physics = require('physics') -- sets local physics variable print(\_G.physics) -- prints out table pointer

If there is a bug here, it’s in the establishment of a global variable when requiring the physics library: but calling that a bug might be presumptuous. It’s not out of bounds for the framework to define a library in the global namespace (i.e. display.*). You might also take issue with the composer library utilizing physics: but since it’s open-source you could always fork it and modify it to work without physics if you wish.

[XeduR]

@schroederapps, thanks for the info! So it definitely isn’t a bug. I might do exactly what you suggested and fork it.

[anon63346430]

Well… I can’t see the point in composer_scene?  And why it needs physics also - why does a scene manager need joints, newText, newImage, etc?

[roaminggamer]

I’m sure that the Corona staff decided that it would be helpful to require the physics library for users, since most action games use physics, and one would suppose many new developers will want to make action games.

[XeduR]

I’m with SGS in wondering why things like physics, joints, newText, newImage, etc. are needed in a scene manager.

I understand the usefulness of the physics library, after all, I’m working with it constantly. I had, however, previously worked under the assumption that if I need it in my projects, then I needed to explicitly require it. Since I use composer in almost all of my projects, it turns out the physics library is in almost all of my projects regardless of whether I need it there or not.