plugin.bit uses global variables (at least one!)

Hello,

I followed your advice “Goodbye globals” long ago …

https://docs.coronalabs.com/tutorial/basics/globals/index.html

… and now trying to use plugin.bit this causes an error. Definitively caused by plugin.bit trying to write to some “settings”

Hope this helps.

jaime

Can you be more specific?  What error are you getting? 

Can you share your code that you’re using with the bit plugin? How is it involved in writing out settings?

Rob

Hi Rob,

sure thing. I’ve reduced it to this main.lua:

setmetatable(\_G, { \_\_newindex = function( \_, n) error( "Attempt to write an undeclared variable! " .. n, 2 ) end, \_\_index = function(\_, n) error( "Attempt to read an undeclared variable! " .. n, 2 ) end, }) local pbit = require( 'plugin.bit' ) print( "Hello there!" )

The error I’m getting is:

Copyright (C) 2009-2018 C o r o n a L a b s I n c . Version: 3.0.0 Build: 2018.3276 Loading project from: ~/Corona/Pruebas Project sandbox folder: ~/Library/Application Support/Corona Simulator/Pruebas-A75E94AAF1DE89AC09940DAF4DDF321E Platform: GT-I9300 / x86\_64 / 10.13.4 / Apple Software Renderer / 2.1 APPLE-16.5.10 / 2018.3276 / en-ES | ES | en\_ES | en ERROR: Runtime error [string "--..."]:91: Attempt to write an undeclared variable! settings stack traceback: [C]: in function 'error' /Users/jaime/Corona/Pruebas/main.lua:6: in function \</Users/jaime/Corona/Pruebas/main.lua:5\> [string "--..."]:91: in main chunk ?: in function 'require' /Users/jaime/Corona/Pruebas/main.lua:14: in main chunk

build.settings correctly asks for plugin.bit. Liine 14 is of course the one "local pbit = require( ‘plugin.bit’ ) "

Best regards

Okay, so you’re generating the error looking for globals. Globals themselves are bad when you don’t know you’re using them. But Lua wouldn’t support them if they were not useful in some circumstances.  I don’t know the code for the bit plugin, but sometimes adding libraries to the global table is what makes sense.

Rob

Hello, and, err, yes, looks kinda stupid now from my part…

I’ll load my “global forbiding” code the last in the require list and assume the former plugins are right.

Thanks.

fyi, many of the “older” libraries were apparently created with the depricated module("",package.seeall) and so leak themselves into the global environment, fe:

local fizziks = require("physics") print("physics:", physics, fizziks) -- Q: where did "physics" come from? A: global leak local kripto = require("crypto") print("crypto:", crypto, kripto) -- Q: where did "crypto" come from? A: global leak local seekwellite = require("sqlite3") print("sqlite3", sqlite3, seekwellite) -- Q: where did "sqlite3" come from? A: global leak

…just something you should be aware of when locking _G

oh, and easing.inOutBounce leaks an “s” which is a pain, because you’ll only experience it at runtime when called (probably long after you’ve locked _G) say via a transition.

fwiw, i only lock _G in simulator, mainly as a “typo check” that I didn’t forget a “local” somewhere, but never for production.  (would rather leak a global than crash in production)

Hi Dave, thanks, nice and potentially lifesaver information :slight_smile:

And yes, for sure, only in simulator, too risky otherwise.

Can you be more specific?  What error are you getting? 

Can you share your code that you’re using with the bit plugin? How is it involved in writing out settings?

Rob

Hi Rob,

sure thing. I’ve reduced it to this main.lua:

setmetatable(\_G, { \_\_newindex = function( \_, n) error( "Attempt to write an undeclared variable! " .. n, 2 ) end, \_\_index = function(\_, n) error( "Attempt to read an undeclared variable! " .. n, 2 ) end, }) local pbit = require( 'plugin.bit' ) print( "Hello there!" )

The error I’m getting is:

Copyright (C) 2009-2018 C o r o n a L a b s I n c . Version: 3.0.0 Build: 2018.3276 Loading project from: ~/Corona/Pruebas Project sandbox folder: ~/Library/Application Support/Corona Simulator/Pruebas-A75E94AAF1DE89AC09940DAF4DDF321E Platform: GT-I9300 / x86\_64 / 10.13.4 / Apple Software Renderer / 2.1 APPLE-16.5.10 / 2018.3276 / en-ES | ES | en\_ES | en ERROR: Runtime error [string "--..."]:91: Attempt to write an undeclared variable! settings stack traceback: [C]: in function 'error' /Users/jaime/Corona/Pruebas/main.lua:6: in function \</Users/jaime/Corona/Pruebas/main.lua:5\> [string "--..."]:91: in main chunk ?: in function 'require' /Users/jaime/Corona/Pruebas/main.lua:14: in main chunk

build.settings correctly asks for plugin.bit. Liine 14 is of course the one "local pbit = require( ‘plugin.bit’ ) "

Best regards

Okay, so you’re generating the error looking for globals. Globals themselves are bad when you don’t know you’re using them. But Lua wouldn’t support them if they were not useful in some circumstances.  I don’t know the code for the bit plugin, but sometimes adding libraries to the global table is what makes sense.

Rob

Hello, and, err, yes, looks kinda stupid now from my part…

I’ll load my “global forbiding” code the last in the require list and assume the former plugins are right.

Thanks.

fyi, many of the “older” libraries were apparently created with the depricated module("",package.seeall) and so leak themselves into the global environment, fe:

local fizziks = require("physics") print("physics:", physics, fizziks) -- Q: where did "physics" come from? A: global leak local kripto = require("crypto") print("crypto:", crypto, kripto) -- Q: where did "crypto" come from? A: global leak local seekwellite = require("sqlite3") print("sqlite3", sqlite3, seekwellite) -- Q: where did "sqlite3" come from? A: global leak

…just something you should be aware of when locking _G

oh, and easing.inOutBounce leaks an “s” which is a pain, because you’ll only experience it at runtime when called (probably long after you’ve locked _G) say via a transition.

fwiw, i only lock _G in simulator, mainly as a “typo check” that I didn’t forget a “local” somewhere, but never for production.  (would rather leak a global than crash in production)

Hi Dave, thanks, nice and potentially lifesaver information :slight_smile:

And yes, for sure, only in simulator, too risky otherwise.