Lua 5.2

Title: Lua 5.2

Why is the mod using an old version of lua? There are implementations of {get,set}fenv for 5.2 in https://github.com/davidm/lua-compat-env.

The mod is still on Lua 5.1 because it would break backwards compatibility with scripts (or at least, that is the reason that has been given when this question is asked - see the suggestions thread).

Additionally, the link you posted would never be compatible with ComputerCraft because it uses the debug library, which is removed for security purposes.

Spoiler

Snippet from the program:

 if up then
      debug.upvaluejoin(f, up, function() return up end, 1) --unique upval[*]
      debug.setupvalue(f, up, t)
    else
      local what = debug.getinfo(f, 'S').what
      if what ~= 'Lua' and what ~= 'main' then -- not Lua func
        error("'setfenv' cannot change environment of given object", 2)
      end -- else ignore no _ENV upvalue (warning: incompatible with 5.1)
    end
 end

Why exactly is the debug library removed?

hvenev, on 20 September 2013 - 12:54 PM said:

Why exactly is the debug library removed?

Bubba, on 20 September 2013 - 06:22 AM said:

it uses the debug library, which is removed for security purposes.

Basically though to expand upon that, it allowed you to be able to break out of the sandbox applied to the computer and gave the script full access to all the files on the host (real!) computer.

Give me the source code and I'll do my best to fix that. I NEED _ENV and debug!

You can only break the sandbox by getting the right functions from luaj.
You can get such functions from:
- Anything reachable from the global table
- A function's upvalue
- A function's local variable
In luaj 3.0-beta1, there are exactly 0 builtin functions with upvalues. So if we remove these 0 functions, upvalues should not be a problem.
Also, all of luaj is implemented in java so builtin functions' local variables cannot be used in any way.

Assuming all ComputerCraft/CCTurtle functions are implemented in java, by simply removing/replacing the bad functions (io, package, os, require, module) you can achieve perfect sandboxing.

Is there anything I'm missing?

For the record, setfenv can be emulated using string.dump and load:

function setfenv(f, env)
  return load(string.dump(f), nil, nil, env)
end

function foo()
  a( b )
end

foo = setfenv(foo, { a = print, b = "test" })
foo()

It's expensive, but works.

Well, we are not going to change Lua 5.1 for 5.2, unless Dan has a really good reason to break some programs.
As to the reason for 5.1 over 5.2? I assume because 5.1 was the only version out when he started working on this, and now we're a little deep into it, and changing it breaks things.

hvenev, on 20 September 2013 - 02:05 PM said:

Give me the source code and I'll do my best to fix that. I NEED _ENV and debug!

You can only break the sandbox by getting the right functions from luaj.
You can get such functions from:
- Anything reachable from the global table
- A function's upvalue
- A function's local variable
In luaj 3.0-beta1, there are exactly 0 builtin functions with upvalues. So if we remove these 0 functions, upvalues should not be a problem.
Also, all of luaj is implemented in java so builtin functions' local variables cannot be used in any way.

Assuming all ComputerCraft/CCTurtle functions are implemented in java, by simply removing/replacing the bad functions (io, package, os, require, module) you can achieve perfect sandboxing.

Is there anything I'm missing?

Yeah, you're missing that neither __env nor debug are needed. You're missing that all that work to allow them has a less than stellar cost/benefit ratio. You're missing that certain things may be design decisions rather than limitations.

I'm actually glad ComputerCraft uses 5.1. I'd really rather not have to deal with Ask a Pro questions wherein the usage of goto is possible. :P/>

Lyqyd, on 20 September 2013 - 04:19 PM said:

I'm actually glad ComputerCraft uses 5.1. I'd really rather not have to deal with Ask a Pro questions wherein the usage of goto is possible. :P/>

Seconded. Dealing with AaP questions sometimes can be hard enough, let alone people having access to goto.

theoriginalbit, on 20 September 2013 - 04:25 PM said:

Lyqyd, on 20 September 2013 - 04:19 PM said:

I'm actually glad ComputerCraft uses 5.1. I'd really rather not have to deal with Ask a Pro questions wherein the usage of goto is possible. :P/>/>

Seconded. Dealing with AaP questions sometimes can be hard enough, let alone people having access to goto.

It would be better than how people currently use functions as goto.

THIS IS NOT ABOUT GOTO

I'm trying to create a multitasking OS for ComputerCraft.

1. The only proper way to stop processes from doing bad things to each other/the kernel is for them to have different environments. That can be done with 5.2 load()/_ENV.
2. Shared libraries. Here is how I'm doing that:

• Load a library (from source) in its own environment
• Recursively copy that environment into every process using it.
• Functions with no upvalues are copied by pointer.
• For others, load(string.dump()) and copy upvalues.
• This should be faster than simply loading from source again because it doesn't go through parsing the source code/initializing again.
• Yes, my implementation supports nested tables, tables containing themselves, multiple functions sharing an upvalue, etc. I know what I am doing.

Nah, there are other ways to do it. Don't get locked in to features you can't have. You can do multitasking sandboxing just fine with 5.1, as far as I'm aware.

You're probably better off loading the API fresh instead of dumping and reloading individual functions. I'm not sure why you think that breaking it up would be faster.

hvenev, on 21 September 2013 - 04:54 AM said:

THIS IS NOT ABOUT GOTO

I'm trying to create a multitasking OS for ComputerCraft.

1. The only proper way to stop processes from doing bad things to each other/the kernel is for them to have different environments. That can be done with 5.2 load()/_ENV.
2. Shared libraries. Here is how I'm doing that:

• Load a library (from source) in its own environment
• Recursively copy that environment into every process using it.
• Functions with no upvalues are copied by pointer.
• For others, load(string.dump()) and copy upvalues.
• This should be faster than simply loading from source again because it doesn't go through parsing the source code/initializing again.
• Yes, my implementation supports nested tables, tables containing themselves, multiple functions sharing an upvalue, etc. I know what I am doing.

Have you looked at the other Multitasking OS's that have been or are being created? It may be possible that are re-inventing the wheel here and as we all know that is against the programmer's mantra.

On the subject of function environments, without the debug library, it really isn't possible to properly implement them in Lua 5.2. You can use string.dump and loadstring, but if the function uses any upvalues, you will get VM errors, and it doesn't change the environment of every reference to the function. The way 5.2 breaks environments is a real shame to me. The system in 5.1 is insanely useful for lots of reasons.

Really….you're not going to get 5.2, as we have explained several times, and we have provided MANY reasons as to why not.
You should try working around the problem, it'll be fun.