Re: changes in 'require'

[David Burgess <dburgess@...>]

> Does anyone know how much is that price? As far as I can guess it seems
> to be much smaller than the price of loading the module itself (assuming
> a typical .lua module).

On Win32 - the 5 or 6 fopen()s for what is in LUA_PATH are very low cost.
The cost of a LoadLibrary is when  the library has not been previously loaded 
and the a *path* is not provided (e.g. "lua5.dll" vs "/lua5.dll") is expensive.
Windows searches the PATH, the current directory, system32 etc, it takes
a while. LoadLibrary() is never faster than fopen()/fclose(). (I was suprised by
this).


>Instead of a patch, I would appreciate some clarification :) Should we
>use NULL as the hModule argument? 

NULL gives the path of the executable (as MIke points out).

>Should we use "PathRemoveFileSpec" to
>strip the executable name? Is there a "reasonable" maximum size for the
>file name?

See above, LoadLibrary() with unqualified paths then gets expensive (and may
I say a tad unpredictable acros different versions of Windows OSs).

>I'm a proponent of the 'clean namespace' camp,
>so you can guess what I would recommend.
I agree. and I think MIkes solution for creating it would be fine.

> An alternative would be to use only the sub-module name, without the
> ... the main directory, and we simplify the generation of the funcname (no
> more LUA_OFSEP). (On the other hand, that could create name conflicts
> for homonymous sub-modules from different packages...)
I like LUA_OFSEP and its interaction with %LUA_PATH%,

> If the sugar is too important, maybe it's not a problem to always add
> it. If it is not, maybe init.lua should not load it; instead, one would
> call require "socket.sugar" to have it...
This is better.

>> Is there a "reasonable" maximum size for the file name?
> MAX_PATH is 260 on WIN32. Seems short enough for a stack-allocated > array.
This can fail. I would suggest using MAX_PATH but throw an error if
the filename is bigger than this. Windows users who use 
"C:\program files\once upon a time there were three bears\etc etc a
book follows\and we use MS suggested paths\lua" deserve what they get.

> > > I think a convenient solution would be to strip an underscore prefix
> > > from the module name before generating the init function name.
> >
> > ...
> 
> In fact identically named symbols from different shared libraries
> should not conflict. At least not the way Lua loads them:
> 
> 
> So, I do not see a problem with this change.
> 

I  do, What happens when we wish to statically link the library.

Then I skipped a few messages because they wnt in a circle.

> I still think the hierarchical require() is the best solution for
> this problem. And it solves other issues as well.
>
Hear! Hear!

> I still think the hierarchical require() is the best solution for
> this problem. And it solves other issues as well.
>

> Great. So let's do it.
I think I need to see some code to summarize all of this with some code.

For the benefit of the slow thinking people like myself, here is the summary
(I am interested in) (please tell me where I am wrong):

1) GetModuleFileName() is used for substitution in LUA_PATH and
LUA_CPATH. Who cares what substitution character is used.

2) require'a.b.c.d' will hierarchically check for the existence of each
component. Children can assume that parents have been require()d

3) We drop the getc(). (BTB on windows I have found _access() to be
reliable in non-threaded code and access() would be a nice addition to
the io or os library even if it is an emulated fopen()/fclose())

4) It was not clear to me whether there was consensus on LUA_OFSEP

5) I am sure I have missed something and I need to get a better timezone

David Burgess