[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LoadLibrary and 5.2
- From: Ignacio Burgueño <ignaciob@...>
- Date: Tue, 12 Jan 2010 15:28:53 -0200
On 12/01/2010 14:51, Antonio Scuri wrote:
The modification you're asking for doesn't make Lua better, it makes
it more suited to your application (LfW). But changing the PATH
environment variable is not the only alternative.
I do think it makes Lua better because LfW is more than a simple "application". It is a very popular Lua distribution for general use. But if there are alternatives I would like to know them.
Or LuaRocks, for the same reasons.
In your situation I'd rather patch the lua.exe interpreter so that it
replaces the default C module searchers with a custom version that use
LOAD_WITH_ALTERED_SEARCH_PATH. The Lua dll stays intact, should it be
used by other applications (that may or may not use C modules from the
LfW install). Only the interpreter application has to know about the
specific way to load modules, and with a custom searcher that's
exactly the case.
How we do that?
Maybe the solution would imply having a module that would place our
custom loader in package.loaders.
require "alteredpath"
That module will roughly do something like:
table.insert(package.loaders, 1, function(modname)
local path, err = package.searchpath(modname, package.cpath)
if not path then deal_with_error end
load_module_with_altered_search_path(path)
-- etc
end)
The issue I have with this code is the index '1'. I'd like to insert
this loader before the C loader. How do I know where is it? If only
package.c_loader were available so one could look for it in the table...
Regards,
Ignacio
- References:
- LoadLibrary and 5.2, Antonio Scuri
- Re: LoadLibrary and 5.2, David Burgess
- Re: LoadLibrary and 5.2, Theodor-Iulian Ciobanu
- Re: LoadLibrary and 5.2, David Burgess
- RE: LoadLibrary and 5.2, Antonio Scuri
- Re: LoadLibrary and 5.2, David Burgess
- RE: LoadLibrary and 5.2, Antonio Scuri
- Re: LoadLibrary and 5.2, RJP Computing
- Re: LoadLibrary and 5.2, Jerome Vuarand
- RE: LoadLibrary and 5.2, Antonio Scuri