From 31174537a3c974ea9885f08cedc094e4abd945ae Mon Sep 17 00:00:00 2001 From: Benoit Germain Date: Fri, 5 Apr 2013 18:34:04 +0300 Subject: Update index.html --- index.html | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index c65a17a..3bf000a 100644 --- a/index.html +++ b/index.html @@ -70,7 +70,7 @@

- This document was revised on 14-Mar-13, and applies to version 3.6.0. + This document was revised on 05-Apr-13, and applies to version 3.6.1.

@@ -1308,10 +1308,8 @@ events to a common Linda, but... :). 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. + Even under Lua 5.1, this may cause trouble if some module registers a function under several keys. + To circumvent this, Lanes has to select one name among all candidates, and the rule for this is to keep the 'smaller' one: first in bytes, then in lexical order. Another more immediate reason of failed transfer is when the destination state doesn't know about the C function that has to be transferred. This occurs if a function is transferred in a lane before it had a chance to scan the module. -- cgit v1.2.3-55-g6feb