Closed Whoome closed 1 year ago
I shall tomorrow when I get back to work.
I see what it is doing, it isn't treating it quite like the standard lua loader. The ? in the path isn't replacing the standard path. I'll work on fixing it up to work more correctly (per lua 5.3).
I fixed it up to work as much like Lua 5.3 as I reasonably could. Note that the package.config is still ignored, but it is really goofy and probably not that interesting to most people.
Native C libraries are of course not supported.
One other thing I should mention that I did was add a DefaultCompileOptions to the Lua class to allow for anything loaded with the "require" keyword or I think the load function to compile with whatever compiler options the integrator set up. This allows for me to still hook those things to get interruptible lua code, and not to have require or load work around that.
I think its a pretty clean solution.
Also, I added resources, but don't speak German so was unable to add them to the .de resource file, I think it was only 3, hopefully someone else (you?) can provide a reasonable translation.
Yes, I will clean up your pull request. We can comment and work on the PR.
I finally branched the bindconvert code. Can you revisit your pull request?
NeoLua Version: 1.3.14
Calling require function does not seem to do anything. I am unclear if this is intended (i.e. not yet implemented) or not.
I craete a silly file in my search path (package.path), to include "testrequire.lua":
Then try and require it:
There is no result from this. In fact, no matter what I put as an argument to require (e.g. require "asdfafdafdfdas") it behaves the same (no error) and the print never happens.
Secondly, though I suspect this is related to the first issue, package.searchers is not implemented. In particular searchers[2] is interesting to me as we have unusual ways of loading lua files that this allows. I am unsure if this is intended or just not implemented yet.