Re: Inconsistency regarding the packagemodel...

[Ross Berteig <Ross@...>]

Sometime on 5/18/2007, Norman Ramsey wrote:
>Looking at the source, it does seem that if I want to provide some
>sort of precompiled or preloaded modules, I could simply write 
my own
>specialized package loader and then do 
table.insert(package.loaders....

And moments later on 5/18/2007, Stefan Sandberg wrote:
>Well, depends on what you mean by "preloaded", there's also
>package.preload :)

I agree that the direct approach is to put the preloaded modules
in package.preload. Unfortunately, this also suffers from the
light documentation of the details alluded to earlier in this thread.

As I understand it, each entry in package.preload is indexed by
the package name as will be passed to require(), and seems to be
a function that is the "initializer" for the module. For a C
module, that is the luaopen_foo() function; for a lua module that
is the module's main chunk or perhaps a wrapper around the main
chunk that also passes the module name so that the module(...)
idiom works.

Incidentally, I haven't found a good way to handle preloaded lua
modules using the stock versions of luac and bin2c. This is
because bin2c's output is code that executes the main chunk, but
allows for neither arguments passed in nor return values passed
out. (I noticed this in particular when trying to precompile Rici
Lake's ldb.lua which returns a function, not a table, which is
the entry point to his debugger.) I extended bin2c.lua to have a
mode that handles that by writing the guts of a function that
would act just like luaopen_foo() would if foo.lua had been
implemented in C instead of lua.

On the whole, I would probably have had bin2c write code that did
less in the first place, perhaps just leaving the main chunk on
the stack ready to be stored or called as needed.  To that end, I
am considering adding a second optional mode to bin2c.lua that
does just that.

I will happily clean that up and post a patch "soon", but I will
just as happily take advice about how I should be doing it...


Ross Berteig                               Ross@CheshireEng.com
Cheshire Engineering Corp.           http://www.CheshireEng.com/