Re: custom interpreters and modules in zip files

[Sean Conner <sean@...>]

It was thus said that the Great Jim once stated:
> On 4/12/19, Sean Conner <sean@conman.org> wrote:
> > At work, I have a custom Lua interpreter that embeds
> > all the Lua modules we need into a single Lua executable.
> 
> we did similar and wrote a new interpreter that already
> provides our C functions in a global table.

  For the modules written in C, I registered the luaopen() function in
the package.preload[] array.

> > This includes modules written in C and Lua.
> 
> how do you handle the pure Lua code ?
> is it directly included as C strings in the binary
> (as "premake" does) or is it loaded from files ?

  We use GNUMake as the build system, so I created this implicit rule to
compile Lua code into object files:

%.o : %.lua
        $(LUAC) -o $(*D)/$(*F).out $<
        $(BIN2C) -9 -o $(*D)/$(*F).l.c -t $(NS)$(*F) $(*D)/$(*F).out
        $(CC) $(CFLAGS) -c -o $@ $(*D)/$(*F).l.c
        $(RM) $(*D)/$(*F).out $(*D)/$(*F).l.c

$(LUAC) is the Lua compiler, but the one checked into the repo (not all our
systems have Lua installed).  $(BIN2C) is a program that takes the given
file (text or binary, doesn't matter), and generates a C file with an
external symbol given by '-t', which is then compiled into a .o file and the
.c file removed.

> > Then I played around with an idea to load Lua modules directly from a zip
> > file [2][3].  What's the path for these?  That of the zip file?  It doesn't
> > make sense.
> 
> why not ? Tcl has something like this built in and can handle
> "file systems" on zip files (and elsewhere).
> 
> >  It kind of worked, in that I could load and run Lua modules written
> >  in Lua directly from the zip file, but not those written in C.
> 
> interesting.

  It's a limitation of dlopen()---it will *only* load shared objects from a
file, not from memory.

  -spc