Hi Luís Eduardo
I am not sure if I understood your implementation correctly
but your problem reminds me of someone who wrote a module like:
-- mod.lua
M = {}
function M:f()
end
And a script to test it:
local m = require"mod"
print(m) --> true
`require' returns the contents of `package.loaded[modname]'
(in this case, `package.loaded["mod"]') which is set to true to avoid
loops of calls to `require'. However, the module could avoid this
problem if it implements one of the following:
- returns the constructed table (which could be a local for those
who don't want to have globals pointing to the packages). In the
above case, just add `return M' at the end of the file
- uses the `module' function (which registers the module at the
proper place: package.loaded[modname])
- manually register the new module in package.loaded[modname].
There is a rationale for that in PiL 2nd edition, chapter 15.
Regards,
Tomás
On Thu, 6 Dec 2007, Luís Eduardo Jason Santos wrote:
I wrote a custom module loader using LuaJava and set it to the package
loaders table.
The loader is a user type with a __call int the meta table.
My problem is, although I am sure the loader is being called and manages
complile and push a chunk of code as the result of a loadstring
operation,
require cannot get the module - returning a boolean instead.
Does anyone know if there's a problem returning a function from a loader
in
those conditions?
--
Luís Eduardo Jason Santos