Why doesn't CC use luaj-3.0?

So, I was playing around with CC's src (it's really not hard too get so I have no idea why the source rules are as they are, but that's another question for another day) and I got quite tired of CC using such an old version of Luaj so I spent literally 10 minutes porting it over to luaj-3.0 which fixed alot of issues I'd had before hand (string bug, etc) It makes me wonder why we aren't using it. It didn't cause any issues.

Anyways, can't distrib that jar because of the source rules. I'd love some input from dan200 on this.

I agree.

EDIT: I probably should have posted something more constructive than two words haha

This is also in the wrong place!

I find it hard to believe that you had no problems when moving it from Lua 5.1 to Lua 5.2.

I guess I'll move this to Suggestions, but your question doesn't fit particularly well anywhere.

Lyqyd, on 28 February 2015 - 01:13 AM said:

I find it hard to believe that you had no problems when moving it from Lua 5.1 to Lua 5.2.

I guess I'll move this to Suggestions, but your question doesn't fit particularly well anywhere.

I really didn't, sure a bit of messing with dans code but not much..

Can vouch, he had no problems. (source: was there)

Well, to quote from the main website:

ComputerCraft 1.0 was released at 10pm on December 24th, 2011

And the first LuaJ 3.0 release was in late 2012. You can't blame Dan200 for not using LuaJ 3.0!

I haven't looked at the source of LuaJ 3.0, but looking at Lua 5.2's incompatibilities I'm surprised there aren't more issues. The key ones are that getfenv/setfenv have been removed which would disrupt pretty so much code. It would be possible to write a 'compatability' layer - table.unpack and unpack are the same, etc…

There are some benefits to LuaJ 3.0 - you can run more than one computer at once, and obviously the string bug is fixed. However the 5.1/2 issue would have to be addressed. If we are going to go all this effort though, it might be fun to update to Lua 5.3 (I know a version for LuaJ doesn't exist this is just wishful thinking), those bitwise operators look good.

Switching to 5.2 probably wouldn't impact most programs, but any OS or program which sandboxes will pretty much immediately break. I doesn't look like there would be too many issues. Even though many of my programs, in fact nowadays all, would break I'd still say that it should be put forward. I'd be happy to have to spend an hour or so fixing for the benefits it provides.

SquidDev, on 28 February 2015 - 09:09 AM said:

you can run more than one computer at once

Wow, that'd definitely be a huge improvement as poorly written programs can keep other computers on hold - for a long time.
I'd be happy to see an update happening :)/>

Big thing against moving forward in version for me is that sandboxing within Lua becomes impossible without the debug API. You can't make a function declare its globals in a user-defined environment. That function has to opt to have a _tEnv variable somewhere in its visibility that the sandboxer also has visibility of. And giving that level of access to the thing you're sandboxing kind of defeats the purpose.

And it's not just the general usage of sandboxing. The problem extends beyond keeping programs out of _G by default. LuaLua, for example, depends heavily on being able to set function environments. Otherwise it wouldn't be possible for instance methods and properties to work the way they do. There are countless applications to function environments and losing them makes it very difficult for me to accept leaving 5.1 behind.

Could it be possible to use both? The current system would be the default but if the program states that it uses the new system then it gets loaded on to that.
I understand that running two sets of lua inside of java could be an issue.

Another possibility is to make a backwards compatibility patch, and emulate the old system with the new one. But that may be not that much better than using both.

An alternative would be to backport the useful classes from 3.0 to 2.0. However I've looked through the diff and the most useful change is the ability to run more than one Computer at once. This is possible to implement in LuaJ 2.0 but it would require some rewriting of some elements. I don't see any evidence of 'The String Bug' being fixed though, most of the LuaString code is the same.

It would be possible to implement an alternative to get/setfenv on the Java side.

Personally I would like to see an entire re-write of LuaJ optimised to use LuaJC, the current version works pretty much perfectly though just feels slightly too hacky. However unless CC goes open source I don't think this is likely to happen, Dan has more important things on his plate.

I would like CC to go open source, 1: out of plain curiosity of seeing how it works; 2: allowing volunteers to help Dan200, allowing for faster development of new features/lua ports.

If CC goes open source and with lua being open source, we could make a version of lua optimised for computercraft.

ElvishJerricco, on 28 February 2015 - 01:10 PM said:

Big thing against moving forward in version for me is that sandboxing within Lua becomes impossible without the debug API. You can't make a function declare its globals in a user-defined environment. That function has to opt to have a _tEnv variable somewhere in its visibility that the sandboxer also has visibility of. And giving that level of access to the thing you're sandboxing kind of defeats the purpose.

And it's not just the general usage of sandboxing. The problem extends beyond keeping programs out of _G by default. LuaLua, for example, depends heavily on being able to set function environments. Otherwise it wouldn't be possible for instance methods and properties to work the way they do. There are countless applications to function environments and losing them makes it very difficult for me to accept leaving 5.1 behind.

What makes this worse is that the bios itself uses setfenv. However, if LuaJ 3.0 still provides the function on the Java side, it shouldn't be too hard to add it back in.

wieselkatze, on 28 February 2015 - 12:56 PM said:

Wow, that'd definitely be a huge improvement as poorly written programs can keep other computers on hold - for a long time.
I'd be happy to see an update happening :)/>

Er, no, it'd be quite the opposite.

Instead of having one system tying down all of ComputerCraft, malicious users would be able to build multiple systems and have them tie down the whole MineCraft server.

Lignum, on 28 February 2015 - 05:18 PM said:

What makes this worse is that the bios itself uses setfenv. However, if LuaJ 3.0 still provides the function on the Java side, it shouldn't be too hard to add it back in.

Unfortunately, I believe that environments are so fundamentally different int 5.2 that the concept of setfenv simply isn't possible.

Bomb Bloke, on 28 February 2015 - 10:48 PM said:

wieselkatze, on 28 February 2015 - 12:56 PM said:

Wow, that'd definitely be a huge improvement as poorly written programs can keep other computers on hold - for a long time.
I'd be happy to see an update happening :)/>

Er, no, it'd be quite the opposite.

Instead of having one system tying down all of ComputerCraft, malicious users would be able to build multiple systems and have them tie down the whole MineCraft server.

As there is a timer on the Java side to terminate those programs if they take too long that shouldn't be the problem.
The thing is - if a computer is taking too long it wouldn't have to affect other computers, because they would be executing normally. Then the other computer would get killed.
Also I don't see 3 or 4 computers tying down the whole server as 1 computer doesn't produce any load on my CPU ( not yielding, but computing ) - server CPUs do have a lot more performance.

wieselkatze, on 01 March 2015 - 05:05 PM said:

As there is a timer on the Java side to terminate those programs if they take too long that shouldn't be the problem.
The thing is - if a computer is taking too long it wouldn't have to affect other computers, because they would be executing normally. Then the other computer would get killed.
Also I don't see 3 or 4 computers tying down the whole server as 1 computer doesn't produce any load on my CPU ( not yielding, but computing ) - server CPUs do have a lot more performance.

And what about people who like to make an underground base full of computers (from 20 to 60) which are all running some piece of software all the time? Seriously, I've seen these things on every CC server I've been on. Imagine a server handling 100+ instances of LuaVM. Oh, and it would either have to create one for every new computer placed or whenever you'd opened up a computer. Though, there was a solution to this proposed somewhere on the subforum: have a few threads (LuaVMs) which would be running, lets say, 30 computers each.

I think with Lua 5.2 and it's environments they've made a big mistake. Function environments, how they worked previously (Lua 5.1), IMO were a lot better and more flexible. Now, what they did was adding "magic" to Lua. I'm talking about the _ENV table, it uses a local variable "magic". I'm not a fan of those "magical" powers a language may have. It seems like that kind of thing was already possible (kind of) with the debug library. Well, at least it is still possible to recreate [set|get]fenv with the debug library in Lua 5.2+. But if CC would update to Lua 5.2/5.3 then I think adding backwards compatibility would actually be nice, keeping in mind that we cannot use the debug library.

Mind you, Lua strikes me as a "magic" language. Tables, variables you don't have to declare, dynamic typing… it's not geared towards efficiency at runtime, it's geared towards making simple tasks simple to program.

Even though I prefer the old method, the old method definitely was more magical. With 5.2, it's literally just syntactic sugar. With 5.1, it's runtime black magic.

To add more to this: I've started a OpenComputerCraft mod which essentially is a source based rewrite of ComputerCraft but within legal limits. However, the name may need to be changed. It is being dubbed opencc, and will have an open-governance module. It's obviously still in the work but hopefully this is will help with alot of the Open Source issues and allow greater usage of CC as a whole as it should be compatible with CC itself. So, like a distro essentially.

https://github.com/OpenComputerCraft/opencc

RainbowDashDC, on 02 March 2015 - 05:44 AM said:

To add more to this: I've started a OpenComputerCraft mod which essentially is a source based rewrite of ComputerCraft but within legal limits. However, the name may need to be changed. It is being dubbed opencc, and will have an open-governance module. It's obviously still in the work but hopefully this is will help with alot of the Open Source issues and allow greater usage of CC as a whole as it should be compatible with CC itself. So, like a distro essentially.

https://github.com/O...terCraft/opencc

You may want to look into OpenComputers too. You may find some good stuff in their source.

MKlegoman357, on 01 March 2015 - 06:40 PM said:

wieselkatze, on 01 March 2015 - 05:05 PM said:

As there is a timer on the Java side to terminate those programs if they take too long that shouldn't be the problem.
The thing is - if a computer is taking too long it wouldn't have to affect other computers, because they would be executing normally. Then the other computer would get killed.
Also I don't see 3 or 4 computers tying down the whole server as 1 computer doesn't produce any load on my CPU ( not yielding, but computing ) - server CPUs do have a lot more performance.

And what about people who like to make an underground base full of computers (from 20 to 60) which are all running some piece of software all the time? Seriously, I've seen these things on every CC server I've been on. Imagine a server handling 100+ instances of LuaVM. Oh, and it would either have to create one for every new computer placed or whenever you'd opened up a computer. Though, there was a solution to this proposed somewhere on the subforum: have a few threads (LuaVMs) which would be running, lets say, 30 computers each.

I think with Lua 5.2 and it's environments they've made a big mistake. Function environments, how they worked previously (Lua 5.1), IMO were a lot better and more flexible. Now, what they did was adding "magic" to Lua. I'm talking about the _ENV table, it uses a local variable "magic". I'm not a fan of those "magical" powers a language may have. It seems like that kind of thing was already possible (kind of) with the debug library. Well, at least it is still possible to recreate [set|get]fenv with the debug library in Lua 5.2+. But if CC would update to Lua 5.2/5.3 then I think adding backwards compatibility would actually be nice, keeping in mind that we cannot use the debug library.

I meant 3 or 4 computers running at the same time.
Even if there are like 60 computers it would only execute 4 simultaneously - probably a misunderstanding.

RainbowDashDC, on 02 March 2015 - 05:44 AM said:

To add more to this: I've started a OpenComputerCraft mod which essentially is a source based rewrite of ComputerCraft but within legal limits. However, the name may need to be changed. It is being dubbed opencc, and will have an open-governance module. It's obviously still in the work but hopefully this is will help with alot of the Open Source issues and allow greater usage of CC as a whole as it should be compatible with CC itself. So, like a distro essentially.

https://github.com/O...terCraft/opencc

Computercraft stands to gain a lot by going open source, but not by dividing the community…

ElvishJerricco, on 02 March 2015 - 02:31 PM said:

RainbowDashDC, on 02 March 2015 - 05:44 AM said:

To add more to this: I've started a OpenComputerCraft mod which essentially is a source based rewrite of ComputerCraft but within legal limits. However, the name may need to be changed. It is being dubbed opencc, and will have an open-governance module. It's obviously still in the work but hopefully this is will help with alot of the Open Source issues and allow greater usage of CC as a whole as it should be compatible with CC itself. So, like a distro essentially.

https://github.com/O...terCraft/opencc

Computercraft stands to gain a lot by going open source, but not by dividing the community…

Look at FreeBSD, OpenBSD and BSD. They are all different from the original, yet they all unite as one community. It doesn't have to divide the community.

RainbowDashDC, on 02 March 2015 - 03:30 PM said:

ElvishJerricco, on 02 March 2015 - 02:31 PM said:

RainbowDashDC, on 02 March 2015 - 05:44 AM said:

-snip-

Computercraft stands to gain a lot by going open source, but not by dividing the community…

Look at FreeBSD, OpenBSD and BSD. They are all different from the original, yet they all unite as one community. It doesn't have to divide the community.

With the risk of sounding negative: there is probably a few examples of the opposite though too.



Perhaps Dan should change the CC licence to allow others to change the source provided that they/we don't use it in other places. That way he can make the source public but doesn't have to worry about other stealing his code. Although I doubt that a text document named LICENCE would get in the way of people stealing code.

However, if Dan is keeping CC closed source to hide possibly exploitable code from malicious players, there is not much we can do other than promise that the exploits will be removed before the malicious people can 'do their thing'.

Lupus590, on 02 March 2015 - 03:30 PM said:

However, if Dan is keeping CC closed source to hide possibly exploitable code from malicious players, there is not much we can do other than promise that the exploits will be removed before the malicious people can 'do their thing'.

If you want to understand ComputerCraft's inner workings, you can easily decompile it with a tool such as this one. Remember: You can never fully hide your source code from anyone.

Would it be too far to start a petition to open source CC? It'd help Dan out a lot to have the community working on bug fixes and performance boosts.

Opening the ComputerCraft source (or not doing so) is entirely up to Dan. He holds the copyright to it and can license it in any way he sees fit. I'm sure he's already aware that there are people in the community who would be interested in contributing if he did open it. Personally, I would see a petition asking him to open source it as disrespectful, giving the message that the signers feel that Dan is incompetent to manage his own mod.

Remember that modders work for free to generate content and give it away to everyone. If he chooses to keep the source code closed, that is entirely up to him. Dan doesn't owe us anything, and I'm sure all of us here will agree that his contribution to the Minecraft modding world has given us all many hours of entertainment. Let's tone back the calls for open-sourcing the mod somewhat, please. :)/>

Lyqyd, on 02 March 2015 - 04:27 PM said:

Opening the ComputerCraft source (or not doing so) is entirely up to Dan. He holds the copyright to it and can license it in any way he sees fit. I'm sure he's already aware that there are people in the community who would be interested in contributing if he did open it. Personally, I would see a petition asking him to open source it as disrespectful, giving the message that the signers feel that Dan is incompetent to manage his own mod.

Remember that modders work for free to generate content and give it away to everyone. If he chooses to keep the source code closed, that is entirely up to him. Dan doesn't owe us anything, and I'm sure all of us here will agree that his contribution to the Minecraft modding world has given us all many hours of entertainment. Let's tone back the calls for open-sourcing the mod somewhat, please. :)/>/>/>

Now, I think that suggesting something go open-source is in no way an insult of his abilities. Infact, I'd say thinking so might be a bit arrogant as not one person can be perfect, hence why we have open-source projects (then again this is my own opinion). A lot of the community wants it to be open-source because we like the mod, because we want to improve the mod and add to it.

This mod had and still has so much potential, as it's gone so far one person can't really do something that a community of hundreds wants in a quick time frame!

Regardless, I respectfully disagree with your opinion of how Dan200 may or may not take it, that's for him to say or not say, and with your call to lower the open-source talk as this is a forum on the mod, and this is a thread requesting a feature that if the mod was open-source could be already implemented or etc.

I think you missed the point that I was actually making, which is that I thought that a petition requesting that the mod be made open source would be disrespectful. I'm a big fan of open source, and I would also be appreciative if Dan decided to open up the mod.

I'm sure that Dan is aware that there are some of us who would like to see CC go open source. We just need to respectfully wait and politely ask.

PS: we seam to have had topic drift, the original post was about why CC doesn't use the latest version of luaj-3.0

Yea there's not much to say about why we don't use luaj-3.0. It would break backwards compatibility and we'd lose function environments, which are extremely important in an environment like CC. That's basically it.

But the point of the OP was that they tested it with a decompiled CC and didn't encounter any issues. (In fact, the port fixed one) And later on in the thread we discussed that the thinks like function environments would be re-implementable through java.

RainbowDashDC, on 02 March 2015 - 05:44 AM said:

To add more to this: I've started a OpenComputerCraft mod which essentially is a source based rewrite of ComputerCraft but within legal limits. However, the name may need to be changed. It is being dubbed opencc, and will have an open-governance module. It's obviously still in the work but hopefully this is will help with alot of the Open Source issues and allow greater usage of CC as a whole as it should be compatible with CC itself. So, like a distro essentially.

https://github.com/O...terCraft/opencc

CCV2
was fun, CCV1. You had a looooong run.

Id like to add that when I say no issues in referring to getting lua to actually run within MC. Not the bios or etc, that was all untested. I'm sorry for the confusion. However, a compatibility layer would most likely work with luaj-3 or even a modified fork with it re-implemented. (planned in opencc so far)

Lupus590, on 02 March 2015 - 11:31 PM said:

But the point of the OP was that they tested it with a decompiled CC and didn't encounter any issues. (In fact, the port fixed one) And later on in the thread we discussed that the thinks like function environments would be re-implementable through java.

RainbowDashDC, on 03 March 2015 - 12:06 AM said:

Id like to add that when I say no issues in referring to getting lua to actually run within MC. Not the bios or etc, that was all untested. I'm sorry for the confusion. However, a compatibility layer would most likely work with luaj-3 or even a modified fork with it re-implemented. (planned in opencc so far)

But function environments are fundamental to CC, and this can't be worked around in 5.3.

ElvishJerricco, on 03 March 2015 - 02:28 AM said:

Lupus590, on 02 March 2015 - 11:31 PM said:

But the point of the OP was that they tested it with a decompiled CC and didn't encounter any issues. (In fact, the port fixed one) And later on in the thread we discussed that the thinks like function environments would be re-implementable through java.

RainbowDashDC, on 03 March 2015 - 12:06 AM said:

Id like to add that when I say no issues in referring to getting lua to actually run within MC. Not the bios or etc, that was all untested. I'm sorry for the confusion. However, a compatibility layer would most likely work with luaj-3 or even a modified fork with it re-implemented. (planned in opencc so far)

But function environments are fundamental to CC, and this can't be worked around in 5.3.

I highly suggest we fork luaj-3 and implement a 5.3 w/ function enviroments.

RainbowDashDC, on 03 March 2015 - 02:45 AM said:

ElvishJerricco, on 03 March 2015 - 02:28 AM said:

Lupus590, on 02 March 2015 - 11:31 PM said:

But the point of the OP was that they tested it with a decompiled CC and didn't encounter any issues. (In fact, the port fixed one) And later on in the thread we discussed that the thinks like function environments would be re-implementable through java.

RainbowDashDC, on 03 March 2015 - 12:06 AM said:

Id like to add that when I say no issues in referring to getting lua to actually run within MC. Not the bios or etc, that was all untested. I'm sorry for the confusion. However, a compatibility layer would most likely work with luaj-3 or even a modified fork with it re-implemented. (planned in opencc so far)

But function environments are fundamental to CC, and this can't be worked around in 5.3.

I highly suggest we fork luaj-3 and implement a 5.3 w/ function enviroments.

But then 5.3 code doesn't work correctly…

ElvishJerricco, on 03 March 2015 - 05:33 AM said:

But then 5.3 code doesn't work correctly…

No no no, I mean alongside. It would be entirely possible to have a method of "switching" between the two if they couldn't be used at the same time.

RainbowDashDC, on 03 March 2015 - 05:45 AM said:

ElvishJerricco, on 03 March 2015 - 05:33 AM said:

But then 5.3 code doesn't work correctly…

No no no, I mean alongside. It would be entirely possible to have a method of "switching" between the two if they couldn't be used at the same time.

But lua 5.3 literally removes the getglobal instruction. Without it, it's actually impossible to use environments. And with it, it's impossible to do the normal 5.3 method.

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

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.

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

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

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.

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.

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.

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.

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/OpenComputerCraft/luaj Look at src/vm2.

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?

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.

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.

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

https://stackoverflow.com/questions/14290527/recreating-setfenv-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.

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!"})()

RainbowDashDC said:

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

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.

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?

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.

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…

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.

Guys, just so you know… I just finished a full Lua 5.1 compatibility layer for 5.2 (makes 5.1 programs work in a 5.2 environment). It's written in Lua, and does require the debug library. However, we could set debug to nil after loading up the compatibility layer. It has no non-standard dependencies, so you could literally copy-paste it to the top of bios.lua and pretty much every 5.1 program should work.

Now, there is one minor thing that may break a super advanced program. Lua 5.2 doesn't have thread environments. So, if you used `setfenv(0, newenv)` and then used loadstring, your code will have to be edited.

Other than that, I don't know of anything that would break when any CC program is run.

EDIT: I'm gonna' try decompiling and porting to LuaJ 3 like RainbowDash did, and test out my compatibility layer. I'll let you know if it holds up under more strenuous testing.