60 replies to this topic

[Lupus590]

Which is why you add a new function for the lua scripts on the java side
something like:

uses luaj-3

anything without this line on the top will use the old/current system

[ElvishJerricco]

Lupus590, on 03 March 2015 - 08:01 AM, said:

Which is why you add a new function for the lua scripts on the java side
something like:

uses luaj-3

anything without this line on the top will use the old/current system

This still doesn't work. What if I write a script with "uses luaj-3", and I put a function in the global space, then some current code tries to set its environment? You can't set the environment of a 5.3 function. They're completely incompatible because both versions expect everything to be done their way.

EDIT: More importantly, os.run can't set the environment of a program that says "uses luaj-3" at the top, which is essential.

Edited by ElvishJerricco, 03 March 2015 - 02:57 PM.

[CoderPuppy]

In Lua 5.2 and 5.3 loadfile takes an environment argument, so os.run and os.loadAPI can still work.

[Engineer]

CoderPuppy, on 03 March 2015 - 03:33 PM, said:

In Lua 5.2 and 5.3 loadfile takes an environment argument, so os.run and os.loadAPI can still work.

Yet not the custom environments which can currently be setup with setfenv, which is removed in Lua 5.2 IIRC

[ElvishJerricco]

CoderPuppy, on 03 March 2015 - 03:33 PM, said:

In Lua 5.2 and 5.3 loadfile takes an environment argument, so os.run and os.loadAPI can still work.

Oh cool I didn't know about that. That makes up for it enough for CraftOS itself I guess, but there's still a lot of programs that abuse function environments, and I use that a lot.

EDIT: It would also require rewrites of bios.lua and of programs that would have to change to use the loadfile method, which means exact compatibility is still broken.

Edited by ElvishJerricco, 03 March 2015 - 04:13 PM.

[CoderPuppy]

Can you give an example of a program that can't replace setfenv with some combination of _ENV and load environments?

And yes exact compatibility is broken, but I don't think that is a big deal.

[MKlegoman357]

CoderPuppy, on 03 March 2015 - 04:20 PM, said:

Can you give an example of a program that can't replace setfenv with some combination of _ENV and load environments?

And yes exact compatibility is broken, but I don't think that is a big deal.

Well, a lot of people are actually still using CC 1.5 and lower. Also, some programs would have to be rewritten to work in Lua 5.2/5.3 and even loose some features. You wouldn't be able to recreate any system written for Lua 5.1 that changes the environment of a function which uses any upvalues in Lua 5.2/5.3 without the debug library. And dynamic changing of environments also is not that possible, which in some APIs and development environments is essential.

Edited by MKlegoman357, 03 March 2015 - 04:38 PM.

[ElvishJerricco]

CoderPuppy, on 03 March 2015 - 04:20 PM, said:

Can you give an example of a program that can't replace setfenv with some combination of _ENV and load environments?

And yes exact compatibility is broken, but I don't think that is a big deal.

As a practical example, look at LuaLua (in my signature). It uses function environments to change the environment of functions that it can't add _ENV variables to from the outside. As a hypothetical example, look at this code.

local function createRecursiveEnv(parentEnv)
	local new = {}
	setmetatable(new, {__newindex=function(t,k,v)
		if type(v) == "function" then
			setfenv(v, createRecursiveEnv(new))
			rawset(t, k, v)
		end
	end, __index = parent})
	return new
end

local f = assert(loadfile("somefile.lua"))
setfenv(f, createRecursiveEnv({}))
f()

The idea of the code above is that all globally declared functions in a file get their own global space instead of all sharing one. This recurses so that each function gets its own global scope.

With 5.3, while you can set the global scope of the file as a whole, you can't change the scope of the individual functions declared inside.

This isn't particularly useful, but its a usecase that can't be replicated in 5.3 without the debug API.

Edited by ElvishJerricco, 03 March 2015 - 04:48 PM.

[jaredallard]

One thing that is important to recognize is that we are not held back but what Lua decides to do, luaj is a from the ground up lua parser. Anything that we could ever want done could be done. If we wanted to ditch the _ENV process in lua 5.3 and make it a lua 5.3 with setfenv instead we could do it.


Don't believe me? Here's proof: https://github.com/O...puterCraft/luaj Look at src/vm2.

Edited by RainbowDashDC, 03 March 2015 - 05:02 PM.

[CoderPuppy]

Ok, I see how the way you're doing those does require setfenv (and I see why you're doing it that way). Would it be possible to implement setfenv using the debug API?

Edit: Doesn't Lua 5.3 already break backwards compatability somewhat?

Edited by CoderPuppy, 03 March 2015 - 05:04 PM.

[MKlegoman357]

Yes, there are some implementations of set/getfenv in Lua 5.3 using the debug library. Also, I don't think CC should actually change the Language itself, like removing _ENV and adding setfenv. CC should be running actual Lua, not modified Lua IMO.

[Lignum]

RainbowDashDC, on 03 March 2015 - 04:57 PM, said:

One thing that is important to recognize is that we are not held back but what Lua decides to do, luaj is a from the ground up lua parser. Anything that we could ever want done could be done. If we wanted to ditch the _ENV process in lua 5.3 and make it a lua 5.3 with setfenv instead we could do it.


Don't believe me? Here's proof: https://github.com/O...puterCraft/luaj Look at src/vm2.

Um, your proof is not a proof? It doesn't implement setfenv (from what I can see). But regardless, I'd be surprised if you'd manage to implement it. The lack of getglobal will make this very difficult.

But yeah, I agree with MK. Don't change Lua, change ComputerCraft. Some programs may break, but alas, we can't stay on 5.1 forever.

[jaredallard]

Here's a post on SO that should help in this terms of recreating setfenv or using _ENV from setfenv.

https://stackoverflo...fenv-in-lua-5-2

Lignum, on 03 March 2015 - 05:11 PM, said:

RainbowDashDC, on 03 March 2015 - 04:57 PM, said:

One thing that is important to recognize is that we are not held back but what Lua decides to do, luaj is a from the ground up lua parser. Anything that we could ever want done could be done. If we wanted to ditch the _ENV process in lua 5.3 and make it a lua 5.3 with setfenv instead we could do it.


Don't believe me? Here's proof: https://github.com/O...puterCraft/luaj Look at src/vm2.

Um, your proof is not a proof? It doesn't implement setfenv (from what I can see). But regardless, I'd be surprised if you'd manage to implement it. The lack of getglobal will make this very difficult.

But yeah, I agree with MK. Don't change Lua, change ComputerCraft. Some programs may break, but alas, we can't stay on 5.1 forever.

Sorry, I meant proof asin proof that it *could* be done.

[jaredallard]

Interesting solution I found on that SO link.

function setfenv(f, env)
    return load(string.dump(f), nil, nil, env)
end
function foo()
    herp(derp)
end
setfenv(foo, {herp = print, derp = "Hello, world!"})()

[ElvishJerricco]

RainbowDashDC said:

1425403775[/url]' post='208030']
Interesting solution I found on that SO link.

function setfenv(f, env)
	return load(string.dump(f), nil, nil, env)
end
function foo()
	herp(derp)
end
setfenv(foo, {herp = print, derp = "Hello, world!"})()

breaks when the function has upvalues

edit: also doesn't change the function in place. I.E. You have to reassign the function once you set its env, which makes it incompatible with most usage of setfenv

Edited by ElvishJerricco, 03 March 2015 - 06:15 PM.

[Lyqyd]

That is not a viable replacement for setfenv either, since it doesn't even work. You'd need the last line to be `foo = setfenv( [...]`, which is not how fenv works currently, and would not change the value of other references to the function.

[SquidDev]

This has sort of devolved into a discussion about setfenv. I am probably unique in the feeling that _ENV is nicer than setfenv, though that is probably a discussion for another thread. I feel the key questions are should Computer Craft use LuaJ3.0 and Lua 5.2?

It is impractical (read pretty much impossible) to have two LuaJ versions running in sync, whilst they are similar they are not identical, and so you get the joys of DLL hell. They will not interop with each other, unless you then have a LuaJ 2.0 and a LuaJ 3.0 computer which would be hell to maintain and would ruin the simplicity of Computer Craft.

So an alternative would be to back-port segments of LuaJ 3.0 to the Computer Craft. This is perfectly possible. However it begs the question, why do we want this in the first place. The only benefit it gives us is more than one computer at once. This is most useful if one computer is blocking all the others - though this is most likely to happen due to malicious means, and a user is capable of building 5 computers and blocking 5 threads as computers are so cheap.

Multi-threading support would be useful for Command Computers. I guess what we should be asking is what are the benefits? Do we really need them? Is it worthwhile implementing them in the first place?

Edited by SquidDev, 03 March 2015 - 08:49 PM.

[jaredallard]

SquidDev, on 03 March 2015 - 08:49 PM, said:

This has sort of devolved into a discussion about setfenv. I am probably unique in the feeling that _ENV is nicer than setfenv, though that is probably a discussion for another thread. I feel the key questions are should Computer Craft use LuaJ3.0 and Lua 5.2?

It is impractical (read pretty much impossible) to have two LuaJ versions running in sync, whilst they are similar they are not identical, and so you get the joys of DLL hell. They will not interop with each other, unless you then have a LuaJ 2.0 and a LuaJ 3.0 computer which would be hell to maintain and would ruin the simplicity of Computer Craft.

So an alternative would be to back-port segments of LuaJ 3.0 to the Computer Craft. This is perfectly possible. However it begs the question, why do we want this in the first place. The only benefit it gives us is more than one computer at once. This is most useful if one computer is blocking all the others - though this is most likely to happen due to malicious means, and a user is capable of building 5 computers and blocking 5 threads as computers are so cheap.

Multi-threading support would be useful for Command Computers. I guess what we should be asking is what are the benefits? Do we really need them? Is it worthwhile implementing them in the first place?

Not to mention the string bug being fixed. Honestly, I think we should use _ENV because in the end it's less "magic" than the other ones, it follows a real enviroment strategy method. I think people, and I know saying this seems like an insult, need to adapt to newer versions. We can't stay at ages old software forever, we can't keep backporting forver either.

[SquidDev]

RainbowDashDC, on 03 March 2015 - 09:09 PM, said:

SquidDev, on 03 March 2015 - 08:49 PM, said:

-snip-

Not to mention the string bug being fixed. Honestly, I think we should use _ENV because in the end it's less "magic" than the other ones, it follows a real environment strategy method. I think people, and I know saying this seems like an insult, need to adapt to newer versions. We can't stay at ages old software forever, we can't keep backporting forever either.

From what I can tell, the fix for the string bug is:

- for ( int i=0, j=off; i  < n; i++ ) {
+ int j = off;
+ for ( int i=0; i < nchars; i++ ) {
  ...
+ return j - off;

(Ok, there is maybe a couple more lines but you get my point).

I agree we can't keep back-porting for ever, however I don't think this is a change that should happen now, or at least is an urgent change. If we ever get ComputerCraft 2.0 as in a complete rewrite with a loss of backwards compatibility anyway I think we should totally switch to Lua 5.2/3(/4?), however I don't think that a rewrite of many programs is worth the "loss of magic". I much prefer the _ENV system, but there is generally no backwards compatibility changes between versions, the worst you get is rednet not returning distance...

Edited by SquidDev, 03 March 2015 - 09:58 PM.

[jaredallard]

I agree with you SquidDev, except I don't feel like in this period, unless it's pushed, luaj won't ever be updated. People won't be anymore keen to want to support it later than they do now, I think it should be implement as soon as possible because that means less new exciting programs will depend on old lua 5.1 technology.

Change sucks, especially when it removes features (heck lua should've deprecated setfenfv not removed it, but that's their poor choice. Not mine.) however, people are never going to be really more inclined to change, people will always keep saying "nah, we can do that later", except later more often than not, never comes! So, while I agree it would cause a great deal of issues, it's not going to get better unfortunately.

Edited by RainbowDashDC, 03 March 2015 - 11:58 PM.