RE: changes in 'require'

["Ive" <neosettlers@...>]

Hi all!

I am new to lua script... spent the last to days wrapping it in a c++ 3d
engine... not sure I m at the right place to discuss this... but ill
give it a try...

In my .lua file I got the following:

actor = CreateActor("ActorCubeName");
primitive = CreateCube("CubeName", 1, 1, 1);
ActorSetPrimitive(actor, primitive);

actor and primitive are pointers to c++ class objects... 
I ve use:

lua_pushlightuserdata to store the pointers to lua... (correct me if im
wrong)
and
lua_touserdata to retrieve them...

it works without problems so far... actor does its job with the
primitive pointer...

now... I ll rather do something like this:

actor = CreateActor("ActorCube");
primitive = CreateCube("CubeName", 1, 1, 1);
actor->SetPrimitive(primitive);

pretty sure it can be done but I have no clue where to look at!

I ll really appreciate any constructive input!

thx


-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of David Burgess
Sent: Thursday, July 14, 2005 9:41 PM
To: Lua list
Subject: Re: changes in 'require'

Just to be sure. I am presuming this is added to the current order
of preload, C loader, Lua Loader.

> - add another loader after the others:
> when requiring "a.b.c", it trys to find a module "a" in the C path;
> if found, tries to find the function luaopen_a_b_c there and returns
it.
Does this mean that require"a.b" will also try module "a" in the C path;
if found, tries to find the function luaopen_a_b?

This means I could package a socket.dll with entry points of
luaopen_socket
luaopen_socket_http
luaopen_socket_smtp
etc
Yes? If this is true then we have A DLL with entry point for everything
that we wish load rather than priming the preload table. This is
fine.

Having just rerread loadlib.c win32 loader code may I suggest one small
enhancement which will help the above strategy.

If we were to assume that it is fair that the LoadLibrary need only be
tried once when it is unsuccessful, the handle to the library could be
initialized to (HANDLE)-1 so that NULL means failed to find it and 
(HANDLE)-1 means we have not tried it. This means that 
require"a.b.c.d"
require"a.b.c.e"
will only perform the LoadLibrary test on "a.dll" once in the life of
the
registry.

> (I assume that there is no need to pack whole *submodules* as one DLL,
> so there is no need to look for a.b or anything like that.)
I do not understand what you mean.


> (Unlike the original C loader, it is not a hard error not to find the
> open function there. It is simply a soft error meaning "module not
found
> here".)
I cant see how this would work when we have a usual case of a library
like
require"a"  -- calls luaopen_a in library a
require"a.b" - -- expects "a/b.lua"

So "a/b.lua" happens to have been deleted which means that the second 
require will never fail.



> If we really want to care for the obsessive people:
> 
> - add yet another loader after the others:
No.
If this is the 5th loader, no. LoadLibrary() on Windows with a
LUA_CPATH of  "?.dll" would potentially search the the Windows path
each time (plus the Windows search strategy), this takes a looong
time. Adding this loader would be the third unsuccessful LoadLibrary()
call. This would take seconds.


David B