 |
lua-l archive |
|
|
||
|
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_PATHBTW, 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