On 16 March 2015 at 14:29, William Adams <william_a_adams@xxxxxxx> wrote: >> > [Actually, this is just one of the many problems of Lua 5.3: as a > >> > module writer, you can never be certain which number types you can > rely >> > on. This depends on how Lua was built, which is not under > your control. >> > IOW: using 3rd party modules is a gamble -- yet > another tombstone for the >> > Lua ecosystem.] > >> bit.c:83:2: error: #error "Unknown number type, check >> > LUA_NUMBER_* in luaconf.h" > > Yeah, they ripped out an important define in >> > Lua 5.3 luaconf.h. > Great job needlessly breaking compatibility, as >> > always. >> > > > --Mike > I know this has come up a couple of times before, but LuaJIT >> > > > is >> > my "Lua ecosystem". I left behind plain old Lua a long time ago because >> > they >> > didn't adopt a JIT strategy. I don't see any reason to delve back into >> > those >> > waters as there's not enough goodness for me and my applications to care >> > about. I'm happy following along with the evolution of LuaJIT, and whenever >> > I talk about 'Lua', I mean LuaJIT. So, soldier on man!! There's no time >> > like >> > the present to throw off the oppression of the origin platform and keep >> > extending LuaJIT in ways that make the most sense for a growing number of >> > consumers. -- William Your email formatting is off for me. I'm actually considering dropping luajit support for some of my libraries. Of particular nuisiance is lack of yielding over pcall and no __gc on tables (though I emulate it with newproxy just for luajit) not to mention wanting to take advantage of _ENV and new operators. When writing new libraries I write against the newest lua 5.3 api and use compat-5.3 ( https://github.com/keplerproject/lua-compat-5.3 ) to work everywhere else. However, I don't like the idea of forking the lua community, there's already so little that people agree on. So I put the extra few hours in to ensure luajit works too.