[Buildroot] luaposix not working with luajit/lua5.1

[Buildroot] luaposix not working with luajit/lua5.1

[Arnout Vandecappelle]

 Hi Francois,

 Three years ago you submitted a patch that was supposed to fix luaposix by
adding the bitop module. However, with this defconfig:

BR2_x86_64=y
BR2_x86_core2=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-x86-64-core2-full-2017.02-rc1-2-g133c5ac.tar.bz2"
BR2_TOOLCHAIN_EXTERNAL_GCC_5=y
BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_4=y
BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
# BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
BR2_TOOLCHAIN_EXTERNAL_CXX=y
BR2_INIT_NONE=y
BR2_SYSTEM_BIN_SH_NONE=y
# BR2_PACKAGE_BUSYBOX is not set
BR2_PACKAGE_LUA=y
BR2_PACKAGE_LUA_5_1=y
BR2_PACKAGE_LUAPOSIX=y

 I get:
# chroot output/target /usr/bin/lua -e 'require "posix"'
[sudo] password for arnout:
/usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
        no field package.preload['bit32']
        no file './bit32.lua'
        no file '/usr/share/luajit-2.0.4/bit32.lua'
        no file '/usr/local/share/lua/5.1/bit32.lua'
        no file '/usr/local/share/lua/5.1/bit32/init.lua'
        no file '/usr/share/lua/5.1/bit32.lua'
        no file '/usr/share/lua/5.1/bit32/init.lua'
        no file './bit32.so'
        no file '/usr/local/lib/lua/5.1/bit32.so'
        no file '/usr/lib/lua/5.1/bit32.so'
        no file '/usr/local/lib/lua/5.1/loadall.so'
stack traceback:
        [C]: in function 'require'
        /usr/share/lua/5.1/posix/init.lua:17: in main chunk
        [C]: in function 'require'
        (command line):1: in main chunk
        [C]: at 0x00402068

 Am I missing something?


 I've worked around this by using the bit32 module instead of the bitop module.
I can submit this patch but I first wanted to check if I just did something wrong.

 Regards,
 Arnout
-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[François Perrad]

2017-02-20 8:35 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>  Hi Francois,
>
>  Three years ago you submitted a patch that was supposed to fix luaposix by
> adding the bitop module. However, with this defconfig:
>
> BR2_x86_64=y
> BR2_x86_core2=y
> BR2_TOOLCHAIN_EXTERNAL=y
> BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y
> BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y
> BR2_TOOLCHAIN_EXTERNAL_URL="http://autobuild.buildroot.org/toolchains/tarballs/br-x86-64-core2-full-2017.02-rc1-2-g133c5ac.tar.bz2"
> BR2_TOOLCHAIN_EXTERNAL_GCC_5=y
> BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_4=y
> BR2_TOOLCHAIN_EXTERNAL_LOCALE=y
> # BR2_TOOLCHAIN_EXTERNAL_HAS_THREADS_DEBUG is not set
> BR2_TOOLCHAIN_EXTERNAL_INET_RPC=y
> BR2_TOOLCHAIN_EXTERNAL_CXX=y
> BR2_INIT_NONE=y
> BR2_SYSTEM_BIN_SH_NONE=y
> # BR2_PACKAGE_BUSYBOX is not set
> BR2_PACKAGE_LUA=y
> BR2_PACKAGE_LUA_5_1=y
> BR2_PACKAGE_LUAPOSIX=y
>
>  I get:
> # chroot output/target /usr/bin/lua -e 'require "posix"'
> [sudo] password for arnout:
> /usr/bin/lua: /usr/share/lua/5.1/posix/init.lua:17: module 'bit32' not found:
>         no field package.preload['bit32']
>         no file './bit32.lua'
>         no file '/usr/share/luajit-2.0.4/bit32.lua'
>         no file '/usr/local/share/lua/5.1/bit32.lua'
>         no file '/usr/local/share/lua/5.1/bit32/init.lua'
>         no file '/usr/share/lua/5.1/bit32.lua'
>         no file '/usr/share/lua/5.1/bit32/init.lua'
>         no file './bit32.so'
>         no file '/usr/local/lib/lua/5.1/bit32.so'
>         no file '/usr/lib/lua/5.1/bit32.so'
>         no file '/usr/local/lib/lua/5.1/loadall.so'
> stack traceback:
>         [C]: in function 'require'
>         /usr/share/lua/5.1/posix/init.lua:17: in main chunk
>         [C]: in function 'require'
>         (command line):1: in main chunk
>         [C]: at 0x00402068
>
>  Am I missing something?
>
>
>  I've worked around this by using the bit32 module instead of the bitop module.
> I can submit this patch but I first wanted to check if I just did something wrong.
>

old versions of luaposix use :
    local bit = bit32 or require 'bit'
which work out of the box with LuaJIT, Lua 5.2 and Lua 5.3
Lua 5.1 requires an additionnal dependency
    - bit from LuaBitOp
    - or bit32 from https://github.com/keplerproject/lua-compat-5.2
In 2013, I choose LuaBitOp.

recent versions of luaposix use :
    local bit = require 'bit32'
which work out of the box with Lua 5.2 and Lua 5.3
LuaJIT and Lua 5.1 require an additionnal dependency
    - bit32 from https://github.com/keplerproject/lua-compat-5.2

The rockspec is available https://luarocks.org/modules/siffiejoe/bit32/5.3.0-1,
so it's easy to add this new package.

Fran?ois

>  Regards,
>  Arnout
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[Arnout Vandecappelle]

On 20-02-17 10:58, Fran?ois Perrad wrote:
> 2017-02-20 8:35 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>>  Hi Francois,
>>
>>  Three years ago you submitted a patch that was supposed to fix luaposix by
>> adding the bitop module.
[snip]
>>  I've worked around this by using the bit32 module instead of the bitop module.
>> I can submit this patch but I first wanted to check if I just did something wrong.
>>
> 
> old versions of luaposix use :
>     local bit = bit32 or require 'bit'
> which work out of the box with LuaJIT, Lua 5.2 and Lua 5.3
> Lua 5.1 requires an additionnal dependency
>     - bit from LuaBitOp
>     - or bit32 from https://github.com/keplerproject/lua-compat-5.2
> In 2013, I choose LuaBitOp.
> 
> recent versions of luaposix use :
>     local bit = require 'bit32'
> which work out of the box with Lua 5.2 and Lua 5.3
> LuaJIT and Lua 5.1 require an additionnal dependency
>     - bit32 from https://github.com/keplerproject/lua-compat-5.2
> 
> The rockspec is available https://luarocks.org/modules/siffiejoe/bit32/5.3.0-1,
> so it's easy to add this new package.

 That's exactly what I did, but I wanted your feedback before submitting. Thanks
for your confirmation that bit32 is needed.

 Integrating this package is not trivial, because our luarocks infra assumes
that the upstream name is the same as the Buildroot name. That's not the case
for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
requires a bit of infra change to clean it up. Therefore, it'll take me a couple
of days before I can submit.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[François Perrad]

2017-02-20 11:47 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 20-02-17 10:58, Fran?ois Perrad wrote:
>> 2017-02-20 8:35 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>>>  Hi Francois,
>>>
>>>  Three years ago you submitted a patch that was supposed to fix luaposix by
>>> adding the bitop module.
> [snip]
>>>  I've worked around this by using the bit32 module instead of the bitop module.
>>> I can submit this patch but I first wanted to check if I just did something wrong.
>>>
>>
>> old versions of luaposix use :
>>     local bit = bit32 or require 'bit'
>> which work out of the box with LuaJIT, Lua 5.2 and Lua 5.3
>> Lua 5.1 requires an additionnal dependency
>>     - bit from LuaBitOp
>>     - or bit32 from https://github.com/keplerproject/lua-compat-5.2
>> In 2013, I choose LuaBitOp.
>>
>> recent versions of luaposix use :
>>     local bit = require 'bit32'
>> which work out of the box with Lua 5.2 and Lua 5.3
>> LuaJIT and Lua 5.1 require an additionnal dependency
>>     - bit32 from https://github.com/keplerproject/lua-compat-5.2
>>
>> The rockspec is available https://luarocks.org/modules/siffiejoe/bit32/5.3.0-1,
>> so it's easy to add this new package.
>
>  That's exactly what I did, but I wanted your feedback before submitting. Thanks
> for your confirmation that bit32 is needed.
>
>  Integrating this package is not trivial, because our luarocks infra assumes
> that the upstream name is the same as the Buildroot name. That's not the case
> for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
> requires a bit of infra change to clean it up. Therefore, it'll take me a couple
> of days before I can submit.
>

We have already luarock packages which name is not prefixed by 'lua-'
: copas, cosmo, dado, orbit, rings, ...

Fran?ois

>
>  Regards,
>  Arnout
>
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[Arnout Vandecappelle]

On 20-02-17 12:01, Fran?ois Perrad wrote:
> 2017-02-20 11:47 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
[snip]
>>  Integrating this package is not trivial, because our luarocks infra assumes
>> that the upstream name is the same as the Buildroot name. That's not the case
>> for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
>> requires a bit of infra change to clean it up. Therefore, it'll take me a couple
>> of days before I can submit.
>>
> 
> We have already luarock packages which name is not prefixed by 'lua-'
> : copas, cosmo, dado, orbit, rings, ...

 These are really separate projects that happen to be using Lua, while bit32 is
really a Lua support module like luaposix.

 Although, now you mention it, copas and coxpcall are Lua support modules as
well. For Python and Perl, we always add a prefix for them. Is there a good
reason why we don't do this for Lua?

 Peter (and others), any opinion: should a module like coxpcall rather be called
lua-coxpcall? We actually have a lot of those. Things like "argparse"...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[François Perrad]

2017-02-20 16:33 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>
>
> On 20-02-17 12:01, Fran?ois Perrad wrote:
>> 2017-02-20 11:47 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
> [snip]
>>>  Integrating this package is not trivial, because our luarocks infra assumes
>>> that the upstream name is the same as the Buildroot name. That's not the case
>>> for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
>>> requires a bit of infra change to clean it up. Therefore, it'll take me a couple
>>> of days before I can submit.
>>>
>>
>> We have already luarock packages which name is not prefixed by 'lua-'
>> : copas, cosmo, dado, orbit, rings, ...
>
>  These are really separate projects that happen to be using Lua, while bit32 is
> really a Lua support module like luaposix.
>
>  Although, now you mention it, copas and coxpcall are Lua support modules as
> well. For Python and Perl, we always add a prefix for them. Is there a good
> reason why we don't do this for Lua?
>

History in BR:
- lua was added in 2007
- xavante and its dependencies (cgilua, copas, coxpcall,
luafilesystem, luasocket, wsapi) were added in 2010 as first Lua
modules
- luarocks infrastructure was added in 2014
- currently, we have 34 Lua modules (see
https://git.busybox.net/buildroot/tree/package/Config.in#n524)

The Lua ecosystem has no strict naming convention, you could use:
  - foo
  - luafoo
  - lua-foo
  - lfoo
  - ljfoo (LuaJIT only)
See the whole at https://luarocks.org/modules

Fran?ois

>  Peter (and others), any opinion: should a module like coxpcall rather be called
> lua-coxpcall? We actually have a lot of those. Things like "argparse"...
>
>  Regards,
>  Arnout
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 > On 20-02-17 12:01, Fran?ois Perrad wrote:
 >> 2017-02-20 11:47 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
 > [snip]
 >>> Integrating this package is not trivial, because our luarocks infra assumes
 >>> that the upstream name is the same as the Buildroot name. That's not the case
 >>> for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
 >>> requires a bit of infra change to clean it up. Therefore, it'll take me a couple
 >>> of days before I can submit.
 >>> 
 >> 
 >> We have already luarock packages which name is not prefixed by 'lua-'
 >> : copas, cosmo, dado, orbit, rings, ...

 >  These are really separate projects that happen to be using Lua, while bit32 is
 > really a Lua support module like luaposix.

 >  Although, now you mention it, copas and coxpcall are Lua support modules as
 > well. For Python and Perl, we always add a prefix for them. Is there a good
 > reason why we don't do this for Lua?

 >  Peter (and others), any opinion: should a module like coxpcall rather be called
 > lua-coxpcall? We actually have a lot of those. Things like "argparse"...

It would be nice from a consistency POV, but as Fran?ois says, renaming
stuff is a bit painful for existing users. Perhaps we can just make sure
new lua packages are prefixed with lua-?

-- 
Bye, Peter Korsgaard

[Buildroot] luaposix not working with luajit/lua5.1

[Arnout Vandecappelle]

On 20-02-17 21:25, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
>  > On 20-02-17 12:01, Fran?ois Perrad wrote:
>  >> 2017-02-20 11:47 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:
>  > [snip]
>  >>> Integrating this package is not trivial, because our luarocks infra assumes
>  >>> that the upstream name is the same as the Buildroot name. That's not the case
>  >>> for bit32, however: in Buildroot, we really want to call it "lua-bit32". So it
>  >>> requires a bit of infra change to clean it up. Therefore, it'll take me a couple
>  >>> of days before I can submit.
>  >>> 
>  >> 
>  >> We have already luarock packages which name is not prefixed by 'lua-'
>  >> : copas, cosmo, dado, orbit, rings, ...
> 
>  >  These are really separate projects that happen to be using Lua, while bit32 is
>  > really a Lua support module like luaposix.
> 
>  >  Although, now you mention it, copas and coxpcall are Lua support modules as
>  > well. For Python and Perl, we always add a prefix for them. Is there a good
>  > reason why we don't do this for Lua?
> 
>  >  Peter (and others), any opinion: should a module like coxpcall rather be called
>  > lua-coxpcall? We actually have a lot of those. Things like "argparse"...
> 
> It would be nice from a consistency POV, but as Fran?ois says, renaming
> stuff is a bit painful for existing users. Perhaps we can just make sure
> new lua packages are prefixed with lua-?

 I wasn't actually considering renaming all those packages :-)

 How about adding a comment in package/Config.in that explains that all new
packages should start with lua- ? I'll do that as part of submitting lua-bit32.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] luaposix not working with luajit/lua5.1

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 >> It would be nice from a consistency POV, but as Fran?ois says, renaming
 >> stuff is a bit painful for existing users. Perhaps we can just make sure
 >> new lua packages are prefixed with lua-?

 >  I wasn't actually considering renaming all those packages :-)

Ahh, ok - good.

 >  How about adding a comment in package/Config.in that explains that
 > all new packages should start with lua- ? I'll do that as part of
 > submitting lua-bit32.

Yes, sounds good - Thanks!

-- 
Bye, Peter Korsgaard