lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 2018-02-25 04:51 PM, Sean Conner wrote:

It was thus said that the Great Soni They/Them L. once stated:

On 2018-02-25 01:26 AM, Sean Conner wrote:

It was thus said that the Great Soni They/Them L. once stated:

On 2018-02-24 07:19 PM, Sean Conner wrote:

It was thus said that the Great Soni They/Them L. once stated:

Why does nobody support renaming modules, it's 2018 :(

   Please rename a module written in C and get it to run, without
recompilation.  Then report your findings back here.

   -spc



Am I allowed to recompile Lua, or monkeypatch require? The default
behaviour is very much crap for C modules and I've been talking about it
for months now.

   Why can't you just rename the modules?

   Hint:  the thread starting here:
   http://lua-users.org/lists/lua-l/2013-06/msg00464.html

   -spc (You have?)





Yes, Lua likes to hardcode C module names and doesn't call them with
their modname + path.

   I don't think Roberto "likes to hardcode C module names":


Modules are not always linked dynamically (see, for instance, the
standard Lua libraries). With a single name, one would not be able to
statically link a set of modules to a program.
Yes, static linking is a case where the shared object is "", so the resulting submodule path is always the full name.
E.g. "" . "hello.world" = "luaopen_hello_world" (this is always the case for the stdlib), "hello" . "world" = "luaopen_world", "hello.world" . "" = "luaopen_", etc.
Are there cases of static linking where you can't just change the symbol names? 



(Moreover, I am not sure your experience number [5] is portable. IIRC,
we had problems in the past with some systems that signalled name
conflicts even with dynamic libraries.)

-- Roberto

and the footnote:


[5]	Years ago I wrote a program that would load modules at run time, and
	each module exports the same symbol.
Since C modules are already architecture- and OS-specific, it seems reasonable to have it one way in general, but support alternatives for OSes that can handle it better. 


   And if you read the documentation under "package.searchers":


My idea is for a module loading system that looks for "luaopen_" symbol.
then "luaopen_submod" and so on.

When requiring something that leads to an .so, it looks for "luaopen_"
if the full path matched, "luaopen_submod" if it only matched up to the
last, and so on.

And then I'd give it the modname and the path to SO, and maybe also the
partial modname used to find the SO.

It would be a much better system that Lua doesn't support.

   I direct you to the documentation to package.searchers:

	When looking for a module, require calls each of these searchers in
	ascending order, with the module name (the argument given to
	require) as its sole parameter.

	...

	The fourth searcher tries an all-in-one loader. It searches the C
	path for a library for the root name of the given module. For
	instance, when requiring a.b.c, it will search for a C library for
	a. If found, it looks into it for an open function for the
	submodule; in our example, that would be luaopen_a_b_c. With this
	facility, a package can pack several C submodules into one single
	library, with each submodule keeping its original open function.

   It does appear that Lua 5.3 also passes in the path (as the second Lua
parameter) to each searcher, so either the documenation is wrong, or it's an
undocumted feature.


$ lua
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
> package.preload.hello = print
> require "hello"
hello    nil
true
> io.open("world.lua", "w"):write("print (...)"):close()
true
> require "world"
world    ./world.lua
true
> -- can't test a C module here but w/e, what happens if you print the C stack from a C module? 


   -spc



--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.