Re: [ANN] luaposix 33.0.0 released

[Gary V. Vaughan <gary@...>]

Hi Philipp,

> On Nov 5, 2014, at 10:07 AM, Philipp Janda <siffiejoe@gmx.net> wrote:
> 
> Am 04.11.2014 um 19:01 schröbte Hisham:
>> On 4 November 2014 15:52, Ką Mykolas <kamicc@gmail.com> wrote:
>>> And I doubt it's going to be ported. Since 5.3 Lua does have native
>>> binary operators, so....
>> 
>> ...so it should be semi-trivial to write a compatibility layer that
>> maps to either luabitop or bit32?
> 
> Judging from `local bit = bit32 or require "bit"` in `posix.lua` that compatibility layer is already in place more or less -- but you have to put one or the other in the dependencies table in the rockspec ...
> 
> Maybe `bit32` would have been a better dependency because it is available for Lua 5.1, 5.2, and 5.3-beta (with compatibility switches), but I don't know for sure whether it really works for LuaJIT (which provides some of the same Lua 5.2 C API symbols as `lua-compat-5.2` which `bit32` uses internally).
> 
> Or, if `bor` is really the only bit operation that `luaposix` requires, maybe it should provide its own (fallback) implementation and don't specify a dependency in the rockspec at all. Then the library user can decide which bit operations to use.

Great idea, thanks!

It uses band, bnot and bor internally, all of which are trivial.  Accordingly, master has a new posix.bit32 module to provide those, and I've switched to using them internally so that the luabitop dependency can be dropped.

After a few small tweaks, luaposix master now builds and loads without warnings on lua-5.3.0-beta.  I haven't ported stdlib nor specl to lua-5.3.0 though, so I couldn't run the behavior specs to confirm that everything is in full working order.  There are instructions in the README explaining how to install from git master using luarocks if anyone wants to try.

Cheers,
-- 
Gary V. Vaughan (gary AT vaughan DOT pe)