RE: LuaJIT project governance

  • From: William Adams <william_a_adams@xxxxxxxxxxx>
  • To: <luajit@xxxxxxxxxxxxx>
  • Date: Tue, 18 Aug 2015 12:40:08 -0700

Anything leveraging ffi.
I'm not saying change the language, only reconsider the ABI level of
compatibility.

Easy exaple of difference; byte code.

There was a recent thread on this.

Sent from my Windows Phone
________________________________
From: Alex Szpakowski<mailto:aszpakowski@xxxxxxxxx>
Sent: ‎8/‎18/‎2015 11:17 AM
To: luajit@xxxxxxxxxxxxx<mailto:luajit@xxxxxxxxxxxxx>
Subject: Re: LuaJIT project governance


On Aug 18, 2015, at 2:05 PM, William Adams <william_a_adams@xxxxxxxxxxx>
wrote:

Also, along the lines of 'vision', I say ditch the 'drop-in' compatibility
with Lua 5.1. We all know it's not a straight drop in replacement, so we
should just move on from that stance, as it will probably relax some of the
constraints that are currently in the system. Either that, or make a
concerted effort to remerge this work back to Lua mainline, and end the
differences. My vote would be for the former.

Do you have specific practical examples of where this would be a large benefit
to LuaJIT as a whole (its ecosystem and APIs, not just its codebase)? Maybe
motivated people could create a fork to evaluate what that sort of change in
direction could do in terms of code.

Keep in mind LuaJIT’s ecosystem is fairly dependent on PUC Lua’s right now,
including decades of various documentation and existing Lua code. What would
entice me to use versions of LuaJIT which might throw that away? What type of
people and projects do you have in mind who will use LuaJIT in the future?

Other related posts:

  1. Home
  2. luajit
  3. Archive
  4. 08-2015