Plain Lua Version

[alexbw]

With a plain-Lua FFI released, will Terra work with plain Lua? Asked another way, do any of Terra's internals depend on any LuaJIT internals, or does it just talk with LuaJIT via the FFI interface?

[zdevito]

99% of Terra goes through the LuaJIT FFI interface. The only thing that I
remember that doesn't is access to lj_strscan_scan, which could just be
copied over from LuaJIT as it is just a plain C file.

On Sat, Oct 24, 2015 at 6:40 AM, Alex Wiltschko [email protected]
wrote:

With a plain-Lua FFI released https://github.com/jmckaskill/luaffi,
will Terra work with plain Lua? Asked another way, do any of Terra's
internals depend on any LuaJIT internals, or does it just talk with LuaJIT
via the FFI interface?

—
Reply to this email directly or view it on GitHub
#128.

[Lupus]

It seems that develop branch includes some work towards PUC Lua compatible version of Terra.

LuaJIT is slowly floating to oblivion (no active maintainer, no new features, no perf improvements), plain Lua version might make sense long term. @zdevito, could you please shed some light on the game plan here? What are your long-term objectives/plans for Terra regarding the Lua part? Dropping LuaJIT and moving towards 5.3 compatibility?

[zdevito]

Yes, I've made the first step for a plain Lua version using a hacked up
version of https://github.com/facebook/luaffifb. I haven't figured out how
to package it up yet, but it passes about 98% of the Terra test suite.
Currently it uses 5.1, but this is primarily a stepping stone to make sure
everything works first. Once it does, upgrading to 5.3 should not be too
difficult. My would be to continue to support luajit, but also support the
most recent PUC Lua as well.

On Mon, Nov 21, 2016 at 12:56 PM, Konstantin A. Olkhovskiy <
[email protected]> wrote:

It seems that develop branch includes some work towards PUC Lua compatible
version of Terra.

LuaJIT is slowly floating to oblivion (no active maintainer, no new
features, no perf improvements), plain Lua version might make sense long
term. @zdevito https://github.com/zdevito, could you please shed some
light on the game plan here? What are your long-term objectives/plans for
Terra regarding the Lua part? Dropping LuaJIT and moving towards 5.3
compatibility?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#128 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAWmGlX50oLlJNC2l3KAQIJO_mdR7SBDks5rAdtogaJpZM4GVA30
.

[saptarshiguha]

Thanks so much!

On Mon, Nov 21, 2016 at 10:56 AM, Zachary DeVito [email protected]
wrote:

Yes, I've made the first step for a plain Lua version using a hacked up
version of https://github.com/facebook/luaffifb. I haven't figured out how
to package it up yet, but it passes about 98% of the Terra test suite.
Currently it uses 5.1, but this is primarily a stepping stone to make sure
everything works first. Once it does, upgrading to 5.3 should not be too
difficult. My would be to continue to support luajit, but also support the
most recent PUC Lua as well.

On Mon, Nov 21, 2016 at 12:56 PM, Konstantin A. Olkhovskiy <
[email protected]> wrote:

It seems that develop branch includes some work towards PUC Lua
compatible
version of Terra.

LuaJIT is slowly floating to oblivion (no active maintainer, no new
features, no perf improvements), plain Lua version might make sense long
term. @zdevito https://github.com/zdevito, could you please shed some
light on the game plan here? What are your long-term objectives/plans for
Terra regarding the Lua part? Dropping LuaJIT and moving towards 5.3
compatibility?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#128 (comment),
or mute
the thread
<https://github.com/notifications/unsubscribe-
auth/AAWmGlX50oLlJNC2l3KAQIJO_mdR7SBDks5rAdtogaJpZM4GVA30>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#128 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAG6rAVWdDugWug3Gewl8NJtrA01quVjks5rAel4gaJpZM4GVA30
.

[bananu7]

@Lupus Just because LuaJIT didn't see new features, I don't think it would be wise to drop support for it. It remains a good, fast Lua implementation.

[Lupus]

@bananu7 I'm not suggesting to drop it right now, furthermore we have large codebase which is LuaJIT dependant. We just don't believe it will survive, and adding support for PUC Lua in terra makes us more confident about the future of terra.

[diggr-roguelike]

I'd like to suggest you prioritize this issue higher. Obsolescence of LuaJIT is not a theoretical worry, it's a very real problem right now.

LuaJIT's garbage collector has an internal limit of no more than 2 Gb of total allocations per process. This makes LuaJIT basically unsuitable for use in serious 64-bit programs.

Since LuaJIT is abandoned it will likely never get proper 64-bit support at all.

[elliottslaughter]

I've cleaned up the develop branch and put this into a PR here: #320

The main thing is, all of the existing pure-Lua FFI implementations were non-portable. So for the moment, my "solution" has been to just cut out any functionality that can't be done in a portable way. At least for me this matters because my main reason for using non-LuaJIT Lua is to support PowerPC. The current solution is enough to build Terra code and call saveobj.

If anyone here is interested in helping that effort, there is still more to do, and we've got ideas for how to do full FFI support in a portable way. It just requires time that I don't have right now.