A method to distribute self-contained Lua applications.
License
spc476/LEM
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
master
Could not load branches
Nothing to show
Could not load tags
Nothing to show
{{ refName }}
default
Name already in use
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
Code
-
Clone
Use Git or checkout with SVN using the web URL.
Work fast with our official CLI. Learn more.
- Open with GitHub Desktop
- Download ZIP
Sign In Required
Please sign in to use Codespaces.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching GitHub Desktop
If nothing happens, download GitHub Desktop and try again.
Launching Xcode
If nothing happens, download Xcode and try again.
Launching Visual Studio Code
Your codespace will open once ready.
There was a problem preparing your codespace, please try again.
Latest commit
Git stats
Files
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
The LEM Project
The LEM project is a project to make the distribution of Lua applications
easier, through a similar mechanism that of Java's jar files. A LEM [1] is
a ZIP file that contains Lua modules and scripts. And given that Lua can be
extended to load modules from just about anywhere and from anything, we can
load such files and modules directly from a ZIP file.
So far, this is a the "proof-of-concept" stage. I can load modules from a
LEM file, but it's far from foolproof and could use more work.
As mentioned the LEM file is a ZIP file, but one with Lua specific
extensions. For example, if we just list the contents of a sample LEM file:
GenericUnixPrompt> unzip -l sample.lem
Archive: sample.lem
Length Date Time Name
-------- ---- ---- ----
25472 05-24-14 21:10 MODULES/org.conman.base64
13448 05-24-14 21:10 MODULES/org.conman.crc
12200 05-24-14 21:10 MODULES/org.conman.env
18688 05-24-14 21:10 MODULES/org.conman.errno
57032 05-24-14 21:10 MODULES/org.conman.fsys
24952 05-24-14 21:10 MODULES/org.conman.hash
17664 05-24-14 21:10 MODULES/org.conman.iconv
17648 05-24-14 21:10 MODULES/org.conman.math
77944 05-24-14 21:10 MODULES/org.conman.net
26296 05-24-14 21:10 MODULES/org.conman.pollset
88256 05-24-14 21:10 MODULES/org.conman.process
37848 05-24-14 21:10 MODULES/org.conman.strcore
15392 05-24-14 21:10 MODULES/org.conman.sys
24312 05-24-14 21:10 MODULES/org.conman.syslog
14175 05-18-14 01:34 MODULES/org.conman.base64
8214 05-18-14 01:34 MODULES/org.conman.crc
7205 05-18-14 01:34 MODULES/org.conman.env
10690 05-18-14 01:34 MODULES/org.conman.errno
31885 05-18-14 01:34 MODULES/org.conman.fsys
15567 05-18-14 01:34 MODULES/org.conman.fsys.magic
14067 05-18-14 01:34 MODULES/org.conman.hash
10197 05-18-14 01:34 MODULES/org.conman.iconv
10816 05-18-14 01:34 MODULES/org.conman.math
43651 05-18-14 01:34 MODULES/org.conman.net
25248 04-19-14 00:06 MODULES/org.conman.net.ipacl
15910 05-18-14 01:34 MODULES/org.conman.pollset
49386 05-18-14 01:34 MODULES/org.conman.process
21379 05-18-14 01:34 MODULES/org.conman.strcore
10223 05-18-14 01:34 MODULES/org.conman.sys
13303 05-18-14 01:34 MODULES/org.conman.syslog
21218 05-18-14 01:34 MODULES/org.conman.tcc
5619 05-18-14 01:34 MODULES/org.conman.cc
2365 05-18-14 01:34 MODULES/org.conman.date
3829 05-18-14 01:34 MODULES/org.conman.debug
2966 05-18-14 01:34 MODULES/org.conman.dns.resolv
3260 05-18-14 01:34 MODULES/org.conman.getopt
1943 05-18-14 01:34 MODULES/org.conman.string
5111 05-18-14 01:34 MODULES/org.conman.table
2820 05-18-14 01:34 MODULES/org.conman.unix
40081 05-25-14 19:17 MODULES/lpeg
6029 05-24-14 04:36 MODULES/re
40045 05-25-14 21:07 MODULES/lpeg
40045 05-25-14 21:07 MODULES/lpeg
6286 05-25-14 21:07 MODULES/re
161412 05-09-14 05:24 FILES/APPNOTE.TXT
7651 05-25-14 22:53 FILES/COPYING
8840 05-25-14 23:51 FILES/README
-------- -------
1118763 47 files
One immedate things comes to mind---there are no file extensions. They're
not required (for reasons that will become apparent). Second thing that
comes to mind---there are duplicate modules. Only they aren't exact
duplicates, as this output (from a custom tool provided in this
distribution) shows:
GenericUnixPrompt> ./zipf.lua sample.lem
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.base64
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.crc
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.env
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.errno
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.fsys
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.hash
SunOS sparcv9 LGPL3+ Lua 5.1 1.1 MODULES/org.conman.iconv
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.math
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.net
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.pollset
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.process
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.strcore
SunOS sparcv9 LGPL3+ Lua 5.1 MODULES/org.conman.sys
SunOS sparcv9 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.syslog
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.base64
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.crc
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.env
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.errno
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.fsys
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.fsys.magic
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.hash
Linux x86 LGPL3+ Lua 5.1 1.1 MODULES/org.conman.iconv
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.math
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.net
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.net.ipacl
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.pollset
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.process
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.strcore
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.sys
Linux x86 LGPL3+ Lua 5.1 5.1 MODULES/org.conman.syslog
Linux x86 LGPL3+ Lua 5.1 MODULES/org.conman.tcc
LGPL3+ Lua 5.1 MODULES/org.conman.cc
LGPL3+ Lua 5.1 MODULES/org.conman.date
LGPL3+ Lua 5.1 MODULES/org.conman.debug
LGPL3+ Lua 5.1 MODULES/org.conman.dns.resolv
LGPL3+ Lua 5.1 MODULES/org.conman.getopt
LGPL3+ Lua 5.1 MODULES/org.conman.string
LGPL3+ Lua 5.1 MODULES/org.conman.table
LGPL3+ Lua 5.1 MODULES/org.conman.unix
Linux x86 MIT Lua 5.1 0.10 MODULES/lpeg
MIT Lua 5.1 0.10 MODULES/re
Linux x86 MIT Lua 5.1 0.12 MODULES/lpeg
Linux x86 MIT Lua 5.2 0.12 MODULES/lpeg
MIT Lua 5.1-5.2 0.12 MODULES/re
FILES/APPNOTE.TXT
FILES/COPYING
FILES/README
The first column shows the operating system the module is intended to be
used for, in this case we have some Linux modules and some Solaris [2]
modules. The files that don't have an operating system listed are in Lua
(text files with Lua code). The second column lists the architecture (for
Solaris, it's a 64 bit SPARC architecture; the Linux ones are 32 bit
Pentiums). The third column lists the license for each module (given that I
was including a bunch of other metainformtaion about the modules, I felt
that including the license was a no-brainer). The fourth column lists the
minimum and maximum Lua versions the module can run under. The fifth column
is the version of the module itself, and the last column is the module name
(or "file name" if you will).
So now you can see that even though we have three different LPeg [3]
modules, all for an x86 Linux system, one is LPeg 0.10 for Lua 5.1, one is
LPeg 0.12 for Lua 5.1 and the third is LPeg 0.12 for Lua 5.2. This shows
that not only can you include operating system specific modules, but Lua
specific modules, and version specific modules, all in the same LEM file.
I should note that this information isn't stored in the _LEM file listed
first---it's stored at extra information associated with each file (the ZIP
standard [4] allows applications to include addtional information with each
file).
Currently, the code is rather rough, but it does show the potential of this.
And much of this might change, or it might not. It's still a work in
progress.
Also, to use the existing code base, you need to be running a POSIX system,
and install the Lua modules from:
https://github.com/spc476/lua-conmanorg
You have been warned.
[1] I'm not sure why Java picked the term "jar" for its distribution
file name, but I suspect it's because a "jar" can hold coffee
("java" is a slang term for "coffee" in the US).
The main method of module installation is the LuaRock, named so
because "Lua" is Portuguese for "moon" and what you have on the
Moon? Rocks. Thus LuaRocks (and it does). But what name to use to
designate a self-contained Lua application? What can carry a bunch
of LuaRocks as well as the main application?
Well, there's NASA's Apollo Project with its Lunar Excursion Module,
(LEM), the actual vehicle that landed on the Moon, and was able to
bring back a lot of moon rocks.
And for me, that's a good enough name.
[2] Why "SunOS" then? Because that's how Solaris identifies itself via
uame(), that's why. Also, the C compiler defines "__SunOS".
[3] http://www.inf.puc-rio.br/~roberto/lpeg/
[4] See APPNOTE.TXT
About
A method to distribute self-contained Lua applications.
Resources
License
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published