Re: Building Lua 5.3 from Lua.org on FreeBSD

[Jay Carlson <nop@...>]

> On Jul 28, 2017, at 5:39 PM, Coda Highland <chighland@gmail.com> wrote:
> 
> On Fri, Jul 28, 2017 at 3:55 PM, Jay Carlson <nop@nop.com> wrote:
>> It may open a bigger can of worms: PUC-Rio Lua might ship live code written
>> in Lua as part of the standard Lua install!
>> 
>> ...oh, you're going to write it all in C again, aren't you. Wouldn't it be
>> easier in a real language?
>> 
>> Jay
> 
> Given that PUC-Rio Lua doesn't have an FFI? Probably not.

I think I was getting ahead of myself: completion against keywords, globals, table.subtable. That part is better handled in Lua, IMO. 

Long ago, I wrote a nasty .so module that grabbed /usr/bin/lua's readline and added tab-completion triggers that called back into Lua. If we get the repl-readline.so Lua loadable module, can I please have some callbacks?

It isn't a problem for repl-readline.so to find libreadline.so.6, because repl-readline.so should be linked with the libraries it depends on. That's the way libreadline.so.6 itself works:

$ ldd /lib/x86_64-linux-gnu/libreadline.so.6
        linux-vdso.so.1 =>  (0x00007ffff73ad000)
---->   libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
        /lib64/ld-linux-x86-64.so.2

Remember when some systems used termcap and others used terminfo? This system happens to use terminfo, but users of -lreadline shouldn't have to care, and neither should users of the Lua module repl-readline.so.

As a bonus, repl-readline.so can be installed anywhere in cpath, and I think without a corresponding .lua file to handle dlopen paths. So this preserves the imperative that Lua not contain any Lua.

Jay