On 13/12/2011 2.14, David Manura wrote:
On Sun, Dec 11, 2011 at 12:35 PM, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
LUA_LLE_FLAGS=LOAD_WITH_ALTERED_SEARCH_PATH
BTW, I think this will be a fairly common option for Windows users,
thus
wouldn't it be better to place it in luaconf.h or at least to
mention its
existence in a more visible place, such a Windows configuration
section in
the readme?
Last time I looked into it [1], I still wasn't completely satisfied
with it. For example, 'LoadLibraryEx triggering undefined behavior
with LUA_LLE_FLAGS=LOAD_WITH_ALTERED_SEARCH_PATH and relative paths
like package.cpath=".\\?.dll"'.
[1] http://lua-users.org/wiki/LoadLibrary
Thank you very much for the pointer!
I have a local "HTTracked" mirror of the WIKI which I don't update
often and I missed that page.
Extremely interesting, and a big headache too! :-(
I didn't know loading a DLL was *so* painful. Especially that thing
about LOAD_WITH_ALTERED_SEARCH_PATH triggering undefined behaviour (my
*very* old Win32 API docs didn't mention anything about it) is
*scary*, especially because building an absolute path in Lua is not
always reliable (you have to know the absolute path of your script,
and this in turn relies on using debug info AFAIK, since arg[0] gets a
relative path sometimes.)!!!
From what I understand it seems that no good solution exists that
makes most people reasonably happy :-(
I wonder whether expanding the interface of package.loadlib could be a
flexible solution (some extra parameters? an extra table with fields a
la os.time?) to allow tweaking the loading process.
I know Lua Team hate adding stuff that isn't ISO-C compliant,
especially if this is so system dependent, but otherwise what reliable
alternative is left to users with little or no knowledge of C and
Win32 API, beyond cramming all the DLLs in the dir of Lua.exe, but
this has other problems: say lua-foo.dll depends on sqlite.dll and
lua-bar.dll depends on another version of sqlite.dll!
Would it be a better solution to provide a new standard library which
would provide a small set of carefully selected system-dependent
non-ISO features (e.g. system.abspath?, system.scriptdir?,
system.sleep?, etc.)?
After all Lua already calls some non-ISO functions under the hood, so
exposing them in a carefully designed way could help write more robust
scripts. The problem would be to select the right stuff without
bloating or uglifying Lua.
BTW wasn't there a proposal to integrate lfs into Lua? Expanded with a
couple of functions to "complete the picture", it seems a good choice
for a standard "system" library. Perhaps also *NIX systems have their
own quirks that may be addressed by a common system library.
Moreover a separate library could be easily not be loaded (from the
Lua C side, I mean) if one wanted less non-ISO dependencies or for
embedded systems who, for example, have no OS.
Another approach would be to add a generally useful FFI library to
Lua, but IIRC Lua Team didn't like the idea (IIRC someone suggested it
some time ago, following the success of LuaJIT FFI). But probably this
would really bloat Lua.
Am I talking nonsense or are there better approaches?
Thanks!
-- Lorenzo
