custom interpreters and modules in zip files

classic Classic list List threaded Threaded
2 messages Options
Jim
Reply | Threaded
Open this post in threaded view
|

custom interpreters and modules in zip files

Jim
On 4/12/19, Sean Conner <[hidden email]> 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.

> 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 ?

> 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.

Reply | Threaded
Open this post in threaded view
|

Re: custom interpreters and modules in zip files

Sean Conner
It was thus said that the Great Jim once stated:
> On 4/12/19, Sean Conner <[hidden email]> 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