Re: Quality-of-Life patches

[Olexa Bilaniuk <obilaniu@...>]

[1/4] Yes it's possible to engineer a 2-letter flag with a file u.lua;
Still, it requires the existence of just such a file with just such
contents. In Python this is a built-in flag -u. It's only 3 extra
calls to setbuf(stdXXX, NULL) in C in the driver program, it's not
part of the Lua VM, and it's fully backwards compatible because it
isn't a codepath taken by default.
[2/4] "Embedding within other programs is pretty much Lua's main
selling point." Yes, indeed, I agree; But as the bulk of lua and luac
are in liblua.a, it's possible to also embed the full interpreter and
compiler itself, and by suitable dispatching on argv[0] you can invoke
lua, luac, or anything else.
[4/4] By "static searcher", I imply a searcher that provides access to
C and Lua packages statically linked with the binary. Preload does
*not* find such packages unless they were loaded into the lua_State
and its package.preload manually. It also does not solve the problem
of LPeg's re.lua, which is distributed as not a C but a pure-Lua
addon.

I have therefore contrived to include the entire contents of re.lua as
a const char[] and statically link the entire contents of LPeg's
compiled C code. I then add a "static searcher" that keys off the
requested module, and if equal to "lpeg" for instance it invokes
luaopen_lpeg(), or if equal to "re" loads the code string containing
the body of re.lua. This is made fairly easy with GNU ld linker
scripts.

The resulting Lua interpreter therefore carries within itself a
self-contained copy of LPeg, which it uses in preference to any
locally-installed copy (and this is fine, since LPeg hasn't changed
anytime recently), and it also does not probe the filesystem for it
(because the static searcher has higher priority than the Lua, C and
Croot searchers).

Is there a better way to go about this you'd recommend?



Olexa Bilaniuk


On Thu, Feb 24, 2022 at 5:53 PM Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > > [4/4] Add a dummy static searcher, and its entry in the searcher table
> > > modified according to patch 3. This reduces the size of a diff that
> > > adds statically-linked packages, and serves as a constructive example
> > > of adding a new searcher.
> >
> > Again, that seems too specific. Constructive examples seem better
> > served by appropriate documentation.
>
> BTW, I am not sure I get what you mean by a "static searcher".
> Statically-linked packages are already served by preload, you should not
> need a new searcher for that.
>
> -- Roberto