Lua input effecting current code

Hello! I am messing around with running Lua code read from the read function. The code is running fine, but there's one thing it isn't doing. It's not effecting any variables. For example:

local chicken = "Default Value"
assert( loadstring( read( nil ) ) )
print ("Chicken: "..chicken)

When you input 'chicken = "pie"' to the read function, the code will still output 'Chicken: Default Value' when I want it to output 'Chicken: pie'. Is it possible to have the loaded string effect the current program?

The act of applying an effect to something, is to affect it.

Anyway, this has to do with environments. The "user scripts" executed on a given ComputerCraft system run in an environment that's separate to _G. The function you generated with loadstring gets a separate one again, and it can't touch variables that're local to your script.

Well, that, and you're never actually running that function you're generating.

I'd recommend setting the function to use a specific environment table, one you can pull stuff out of later. Eg:

local myEnvironment = {["chicken"] = "Default Value"}

local myFunction = assert(loadstring(read()))  -- Type eg chicken = "pie"

setfenv(myFunction, myEnvironment)

myFunction()

print("Chicken: "..myEnvironment.chicken)

Bomb Bloke, on 03 May 2015 - 03:00 AM said:

The act of applying an effect to something, is to affect it.

Ugh, I always mix the two up :P/> Anyways, thanks for the help.

Bomb Bloke, on 03 May 2015 - 03:00 AM said:

-snip

I'm now getting an 'attempt to call nil' on the line I'm using this on. I've replaced every variable that went into it, and have figured out that it has to be the function. It works perfectly fine in the lua command line program, and it worked fine earlier. Nothing going into it has changed. Any idea why this might be happening?

ShadowDisruptor, on 03 May 2015 - 11:42 PM said:

I'm now getting an 'attempt to call nil' on the line I'm using this on.

Er, which line?

Bomb Bloke, on 04 May 2015 - 12:13 AM said:

ShadowDisruptor, on 03 May 2015 - 11:42 PM said:

I'm now getting an 'attempt to call nil' on the line I'm using this on.

Er, which line?

My bad, thought I only mentioned one in the original post.
local myFunction = assert(loadstring(read()))

That line will only trigger that error if you've overwritten one of the functions in concern. Start out by rebooting the computer, then if it still does it, double check the line number the error's pointing you at.

Bomb Bloke, on 04 May 2015 - 01:13 AM said:

That line will only trigger that error if you've overwritten one of the functions in concern. Start out by rebooting the computer, then if it still does it, double check the line number the error's pointing you at.

It's definitely the line that has the loadstring. Here is the code I'm working with. I'm getting the error on line 44. This worked perfectly fine, until I changed the way the 'lesson' table is laid out. Nothing on that specific line has changed.

That's caused by your typo on line 33. You end up changing the environment of your current function instead of the one you want to target. Since your empty environment table is empty, it doesn't contain loadstring, so as soon as you try to call that, you'll crash out.

An empty environment is fine for the purposes of simple strings (eg chicken = "pie"), but for more complex stuff you'll want access to _G as well. One way to grant it is to build a metatable out of your environment and _G; I suggest taking a look at the source of os.loadAPI() in bios.lua (in the assets folder of the ComputerCraft mod archive file).

Thanks for the help, I would have never caught that typo.