60 replies to this topic

[jaredallard]

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.

[tenshae]

I agree.

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

This is also in the wrong place!

Edited by ashnwill, 28 February 2015 - 12:41 AM.

[Lyqyd]

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.

[jaredallard]

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..

[tenshae]

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

[SquidDev]

Well, to quote from the main website:

Quote

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.

Edited by SquidDev, 28 February 2015 - 09:14 AM.

[oeed]

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.

[wieselkatze]

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

[ElvishJerricco]

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.

[Lupus590]

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.

[SquidDev]

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.

[Lupus590]

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.

[Lignum]

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.

[Bomb Bloke]

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.

[ElvishJerricco]

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.

[wieselkatze]

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.

[MKlegoman357]

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.

[Bomb Bloke]

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.

[ElvishJerricco]

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.

[jaredallard]

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