[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] The LEM Project
- From: Sean Conner <sean@...>
- Date: Sun, 25 May 2014 22:20:12 -0400
It was thus said that the Great Aaron B. once stated:
> On Sun, 25 May 2014 20:24:06 -0400
> Sean Conner <sean@conman.org> wrote:
>
> > While the code [6] has only been tested under a single Linux system, there
> > is enough there for a "proof-of-concept" (that is, I can load Lua modules
> > (both Lua based ones, and shared objects) directly from the ZIP file,
> > without need for full extraction first). At the very least, I think the
> > Windows guys would find this more useful than the Unix guys, but hey, I
> > could be wrong.
>
> I'm unix user only, and this looks very useful.
>
> > Anyway, enough with this---below is the README from the project [6]. I
> > welcome thoughts, discussion, criticisms, contributions, and what have you.
>
> So is this strictly a module-of-modules, or can the LEM have a
> standalone entry point and be more-or-less directly executable? Also,
> how much does a script need to do to pull the modules in from the LEM?
> Forgive me if it's obvious from the code, I haven't had a chance to
> look through it yet.
It can have a standalone entry point, which as of yet is undefined but
that I expect would be stated in the _LEM meta file (which is just some Lua
code that is loaded in an empty environment). The test script (tstzip.lua)
adds a function to package.loaders[] to search for modules in the LEM file,
so require() still works.
I also intend to support other files (say, image files, text files, other
data files) that can be loaded as well [1].
> Excellent choice on allowing multiple operating systems/processor
> architectures in the module. I'm supporting quite a mix of
> *BSD/Linux/Solaris systems with four different processor types; it's
> great to see other people care.
The original intent was to have some means of knowing when you can't load
a C module becuase of a difference in OS or CPU. Adding that lead to the
realization that I could include modules of the same name but differing
architectures. And from that, adding both Lua versions and module versions
fell into place (and then licensing information).
It also doesn't hurt that I use multiple systems at work (hence the
Solaris examples). And that the ZIP file format doesn't care about
duplicate names.
> Also, I love the name.
Thanks. It took a bit of time for me to come up with a suitable name.
[1] Say, by monkey patching io.open()?