Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using Rembulan as a Lua implementation? #1

Open
keturn opened this issue May 12, 2020 · 2 comments
Open

using Rembulan as a Lua implementation? #1

keturn opened this issue May 12, 2020 · 2 comments

Comments

@keturn
Copy link
Member

keturn commented May 12, 2020

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.

@asiekierka
Copy link
Collaborator

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.

@keturn
Copy link
Member Author

keturn commented May 15, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants