Re: [ANN] mergelua

[David Manura <dm.lua@...>]

On Sun, Oct 16, 2011 at 7:49 PM, Petite Abeille
<petite.abeille@gmail.com> wrote:
> On Oct 17, 2011, at 1:38 AM, Roberto Ierusalimschy wrote:
>> Even in Lua 5.1 many (most?) modules follow that policy without using the 'module' function.
>
> Pure speculation on your part? Lets see... random selection... LuaSocket? ah, uses module...
> LuaJIT? Oh, module again... LuaRocks? module... CGILua? oh my... module again...

LuaJIT is an interesting case because the author's posts in the
anti-module camp were also cited in this discussion.  Its module usage
pattern is somewhat unconventional, though avoids some pitfalls in
LuaModuleFunctionCritiqued and (perhaps safely) assumes "jit" is a
global table:

  local vmdef = require("jit.vmdef")
  local function ctlsub ..... end
  local function bcline .....ctlsub..... end
  local function bcdump ..... end
  .....
  module(...)  -- this goes *near the very end* and without package.seeall
  line = bcline
  dump = bcdump

That said, DynASM skips 'module', and LuaJIT's unique requirements
make it a poor example--including its non-standard -j switch module
loading mechanism.  (Incidentally, that -j switch may be worth adding
to standard Lua as well to support the OP's question,
http://www.mail-archive.com/luarocks-developers@lists.sourceforge.net/msg00196.html
)

Along the theme of http://lua-users.org/wiki/MiningLuaCode , here's a
breakdown of which LuaForWindows packages use the "module" function ):

stdlib	 - YES (with package.seeall)
Copas - YES (with package.seeall)
Lanes - YES (with package.seeall)
LeMock - YES (with package.seeall)	
LuaRocks	- YES (with package.seeall)
MetaLua - YES (with.package.seeall), but does some odd things like
inject into global tables.
Alien - YES
LuaDoc - YES
LuaExpat - YES
LuaLogging - YES
LuaSocket - YES
MD5 - YES
Rings - YES
LOOP - YES
LuaXML - YES
Oil - YES
LuaJSON - YES
wxLua - ? (C module mostly)
IUP/CD/IM - ? (C module mostly, and does something odd)
LuaSQL - ? (C module mostly, and does something odd)
LuaUnit - no (exports globals)
Coxpcall - no (exports globals)
gzio - NO (tar.lua)
LPeg - NO
luadate - NO
LuaZip - NO (C module)
VStruct - NO
Penlight - NO (although apparently used to since module calls are commented out)
LuaInterface - N/A (C# module)
LuaProfiler - N/A (C module)
lrexlib - N/A (C module)
LuaTask - N/A (C module)
luaex - N/A (C module)
Lua-GD - N/A (C module)
LuaCOM - N/A (C module)
LuaCURL - N/A (C module)
LuaFileSystem - N/A (C module)
LuaBitOps - N/A (C module)
lpack - N/A (C module)
LuaGL - N/A (C module)
lbase64 - N/A (C module)
LuaRS232 - N/A (C module)

A lot of YES's are Kepler-related packages and may bias the breakdown.
 A lot are also N/A C packages, and no further check was made
concerning use of the related luaL_register in them.

The determination is not the simplest to do in an automated way on the
entire LuaDist repo, but, just roughly, out of 150 packages containing
at least one .lua file (not all of which are candidates to be
modules), here's a search for package.seeall, of which there are 52
package matches:

abelhas
cgilua
cheese
concurrentlua
copas
cosmo
diff
gslshell
kepler
kepler-fastcgi
kepler-xavante
lanes
lemock
lmock
lrexlib
lua
lua-colors
luacontractor
luacov
lua_discount
luadist
luagraph
luajit
luajson
lualnum
lua_memoryfile
luapi
luapod
luarocks
luasec
lua-stdlib
lua_tinycdb
luatokenf
luma
lunit
metalua
objectlua
olua
recaptcha
remdebug
saci
scite
sputnik
sputnik_markitup
sputnik_tickets
versium
wsapi
wsapi-fcgi
wsapi-xavante
wxlua
xavante
xssfilter