[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: A major problem with the Lua ecosystem
- From: Sean Conner <sean@...>
- Date: Thu, 1 Feb 2018 18:22:06 -0500
It was thus said that the Great Dibyendu Majumdar once stated:
> > I didn't even realize that Lua supported require 'a.b.c' and that this
> > is translated to a filesystem path, maybe because I haven't seen it
> > being used.
> > Will certainly make sure that all modules in the Ravi distro follow a
> > supplier.modue (e.g. torch.paths) pattern - can't imagine why people
> > don't do this. It is a no brainer to me.
> Maybe there is one problem - the require function also loads shared
> libraries. Having these in multiple locations could be a problem as
> these need to be in the path.
It depends upon what you mean. For example, my syslog module  is a
C-based module. When you do:
local syslog = require "org.conman.syslog"
Lua will replace the dots with the file separator (in my case '/'):
and for each component in package.cpath (broken out for easier reading):
will replace the '?' with the modified module name:
and will attempt to load each .so file in turn. Further more, to illustrate
a potentinal problem, I installed org.conman.syslog twice, once manually and
once via LuaRocks.
[spc]lucy:~>luawhich org.conman.syslog # 
In this case, Lua will load "/home/spc/.luarocks/lib/lua/5.1/org/conman/syslog.so" since it is found
first by Lua.
 A Lua script that prints out the location of a module given its