You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure if it's worth the incompatibilities to have two slightly different implementations - and JNLua is based on the official Lua implementation. I think decent faith in Rembulan would be required to adopt it in place of JNLua/eris.
I agree that trying to keep up two implementations would be far too much work! You certainly would want to pick one and stick with it.
If one of your design goals is to work with existing libraries of Lua code from other sources (e.g. Lua that people have written for OpenComputers), I can see how compatibility would be a priority, which makes bindings to the canonical implementation a good choice.
Mostly my motivation to look at other lua implementations was driven by the fact that I've been working on things related to distribution, installation, and loading requirements, and requiring a "native" library involves different things than the rest of what's involved with distributing a Java application. But that is probably not something to worry about most of the time, I imagine lua must be pretty portable and well-behaved as such things go.
I've just run across this as I'm testing something that involves Terasology's use of native libraries, and that includes JNLua.
I was wondering if Kallisti could use an implementation of Lua written for the JVM, avoiding the use of native implementations.
I discovered that OpenComputers does fall back to LuaJ, but then the persistence features of Eris don't work, which sounds like a pretty big drawback.
I also found this about Rembulan on OpenComputers which sounded promising, but I don't know if anything came of it.
The original Rembulan repository is dormant, but there are a few forks that have had activity to make updated builds.
The text was updated successfully, but these errors were encountered: