On Tue, Apr 2, 2013 at 11:31 AM, Victor Bombi <son...@telefonica.net> wrote:
>> Can you explain why these other modules cannot work with
>> LUA_COMPAT_ALL enabled? Are they providing their own duplicate
>> versions of Lua's functions and you get linker errors?
>>
>> Also, can you explain line 25 here?
>> https://github.com/diegonehab/luasocket/blob/unstable/src/luasocket.h
>>
> That true luasocket seems to need LUA_COMPAT_ALL
Actually, only LUA_COMPAT_MODULE which LUA_COMPAT_ALL enables, but the
bottom line is that you can probably expect that system installed Lua
libraries (on Linux) will have LUA_COMPAT_ALL enabled so Lua Lanes
will probably want to figure out some workaround in the long run
(unless they wait all the way until 5.3 which could be years away).
> This is the explanation for Lua Lanes:
>
> Lua 5.2 introduced a hash randomizer seed which causes table iteration to
> yield a different key order on different VMs even when the tables are
> populated the exact same way. When Lua is built with compatibility options
> (such as LUA_COMPAT_ALL), this causes several base libraries to register
> functions under multiple names. This, with the randomizer, can cause the
> first encountered name of a function to be different on different VMs, which
> breaks function transfer. This means that Lua 5.2 must be built WITHOUT
> compatibility options to be able to use Lanes. Even under Lua 5.1, this may
> cause trouble (even if this would be much less frequent). Unfortunately, we
> get bitten by string.gfind/string.gmatch when Lua 5.1 is built with
> LUA_COMPAT_GFIND (which is the case of LuaBinaries), so for the time being,
> Lanes fails only for Lua 5.2 as the randomizer is the real show breaker
> here.
I do remember something about the hash randomizer for security on the
Lua list, but I didn't read that thread...
It looks like all Lua Lanes cares about is that function names don't change.
See the comment above and the code below :
if( (LUA_VERSION_NUM > 501) && (prevName != NULL))
Here :
https://github.com/LuaLanes/lanes/blob/master/src/tools.c
Finally see the code for LUA_COMPAT_ALL here :
http://www.lua.org/source/5.2/luaconf.h.html
Maybe the offending define is LUA_COMPAT_MODULE, which of course, is
exactly the one that every Lua library that wants to stay compatible
with 5.1 and 5.2 will use. However, the check in Lua lanes is not for
any COMPAT define, but rather that you aren't calling the same
function with a different name.
The solution may be quite simple, always use the same name when
calling any particular function and you won't trigger the Lua Lanes
error. Off the top of my head I don't see why, technically, they care
what the name of the function is, but that might be something to look
into too. I would ask on the Lua Lanes mailing list, or wherever would
be appropriate, for a clarification of this statement; "causes several
base libraries to register functions under multiple names." Ideally,
people would need to know what the names of these multiply named
functions are so they can avoid the problem altogether.
Do you actually get an error now? And if so, for what function? Maybe
log() and log10() ?
----------------------------
Something to try... Do you get an error in Lua Lanes if you do
something like this?
string_format = string.format
local local_string_format = string.format
print("a", string.format("%d", 1))
print("b", string_format("%d", 1))
print("c", local_string_format("%d", 1))
Regards,
John
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
wxlua-users mailing list
wxlua-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxlua-users
