diff options
author | Benoit Germain <bnt.germain@gmail.com> | 2013-01-24 22:46:21 +0100 |
---|---|---|
committer | Benoit Germain <bnt.germain@gmail.com> | 2013-01-24 22:46:21 +0100 |
commit | 68d8db431ec2b739dc53233d6b4d8aeee9324e48 (patch) | |
tree | d8f0fbe0f8c4e1a07ac4248fd1b7673f49beb4d3 /docs | |
parent | 623fb3c0cae9beb3d5e7d3f7424b47d80041c1ac (diff) | |
download | lanes-3.4.3.tar.gz lanes-3.4.3.tar.bz2 lanes-3.4.3.zip |
version 3.4.3v3.4.3
* raise an error if lane generator libs specification contains a lib more than once
* bit32 is a valid lib name in the libs specification (silently ignored by the Lua 5.1 build)
* improved lanes.nameof to search inside table- and userdata- metatables for an object's name
* fixed an unwarranted error when trying to discover a function name upon a failed transfer
* contents of package.[path,cpath,preload,loaders|searchers] are pulled *only once* inside keeper states at initialisation
* Lua function upvalues equal to the global environment aren't copied by value, but bound to the destination's global environment
especially useful for Lua 5.2 _ENV
* fixed loading of base libraries that didn't create the global tables when built for Lua 5.2
Diffstat (limited to '')
-rw-r--r-- | docs/index.html | 27 |
1 files changed, 18 insertions, 9 deletions
diff --git a/docs/index.html b/docs/index.html index 4d11371..8188fe9 100644 --- a/docs/index.html +++ b/docs/index.html | |||
@@ -63,13 +63,13 @@ | |||
63 | <font size="-1"> | 63 | <font size="-1"> |
64 | <p> | 64 | <p> |
65 | <br> | 65 | <br> |
66 | <i>Copyright © 2007-12 Asko Kauppi, Benoit Germain. All rights reserved.</i> | 66 | <i>Copyright © 2007-13 Asko Kauppi, Benoit Germain. All rights reserved.</i> |
67 | <br> | 67 | <br> |
68 | Lua Lanes is published under the same <a href="http://en.wikipedia.org/wiki/MIT_License">MIT license</a> as Lua 5.1 and 5.2. | 68 | Lua Lanes is published under the same <a href="http://en.wikipedia.org/wiki/MIT_License">MIT license</a> as Lua 5.1 and 5.2. |
69 | </p> | 69 | </p> |
70 | 70 | ||
71 | <p> | 71 | <p> |
72 | This document was revised on 10-Jan-13, and applies to version <tt>3.4.2</tt>. | 72 | This document was revised on 24-Jan-13, and applies to version <tt>3.4.3</tt>. |
73 | </p> | 73 | </p> |
74 | </font> | 74 | </font> |
75 | </center> | 75 | </center> |
@@ -246,7 +246,7 @@ | |||
246 | 246 | ||
247 | <tr valign=top> | 247 | <tr valign=top> |
248 | <td> | 248 | <td> |
249 | <code>.on_create_state</code> | 249 | <code>.on_state_create</code> |
250 | </td> | 250 | </td> |
251 | <td> | 251 | <td> |
252 | C function/<tt>nil</tt> | 252 | C function/<tt>nil</tt> |
@@ -415,7 +415,7 @@ | |||
415 | </td> | 415 | </td> |
416 | <td/> | 416 | <td/> |
417 | <td> | 417 | <td> |
418 | all standard libraries (including those specific to LuaJIT and not listed above) | 418 | All standard libraries (including those specific to LuaJIT and not listed above). This must be used alone. |
419 | </td> | 419 | </td> |
420 | </tr> | 420 | </tr> |
421 | </table> | 421 | </table> |
@@ -487,9 +487,13 @@ | |||
487 | </td> | 487 | </td> |
488 | <td> table</td> | 488 | <td> table</td> |
489 | <td> | 489 | <td> |
490 | Introduced at version 3.0. | ||
491 | <br> | ||
490 | Specifying it when <code>libs_str</code> doesn't cause the <code>package</code> library to be loaded will generate an error. | 492 | Specifying it when <code>libs_str</code> doesn't cause the <code>package</code> library to be loaded will generate an error. |
491 | <br> | 493 | <br> |
492 | If not specified, the created lane will receive the current values of <tt>package</tt>. Only <tt>path</tt>, <tt>cpath</tt>, <tt>preload</tt> and <tt>loaders</tt> (Lua 5.1)/<tt>searchers</tt> (Lua 5.2) are transfered. | 494 | If not specified, the created lane will receive the current values of <tt>package</tt>. Only <tt>path</tt>, <tt>cpath</tt>, <tt>preload</tt> and <tt>loaders</tt> (Lua 5.1)/<tt>searchers</tt> (Lua 5.2) are transfered. |
495 | <br> | ||
496 | IMPORTANT: The contents of whatever package table is actually provided to the lane won't be known to the keeper states: they will stick to whatever was found in the main state's package table when Lane was required. | ||
493 | </td> | 497 | </td> |
494 | </tr> | 498 | </tr> |
495 | </table> | 499 | </table> |
@@ -1119,12 +1123,17 @@ events to a common Linda, but... :).</font> | |||
1119 | </ul> | 1123 | </ul> |
1120 | </li> | 1124 | </li> |
1121 | <li> | 1125 | <li> |
1126 | Lua 5.2 functions may have a special <tt>_ENV</tt> upvalue if they perform 'global namespace' lookups. Unless special care is taken, this upvalue defaults to the table found at <tt>LUA_RIDX_GLOBALS</tt>. | ||
1127 | Obviously, we don't want to transfer the whole global table along with each Lua function. Therefore, any upvalue equal to the global table is not transfered by value, but simply bound | ||
1128 | to the global table in the destination state. Note that this also applies when Lanes is built for Lua 5.1, as it doesn't hurt. | ||
1129 | </li> | ||
1130 | <li> | ||
1122 | Full userdata can be passed only if it's prepared using the <a href="#deep_userdata">deep userdata</a> system, which handles its lifespan management | 1131 | Full userdata can be passed only if it's prepared using the <a href="#deep_userdata">deep userdata</a> system, which handles its lifespan management |
1123 | <ul> | 1132 | <ul> |
1124 | <li>In particular, lane handles cannot be passed between lanes.</li> | 1133 | <li>In particular, lane handles cannot be passed between lanes.</li> |
1125 | </ul> | 1134 | </ul> |
1126 | </li> | 1135 | </li> |
1127 | <li>Coroutines cannot be passed. A coroutine's Lua state is tied to the Lua state that created it, and there is no way the mixed C/Lua stack of a couroutine can be transfered from one Lua state to another.</li> | 1136 | <li>Coroutines cannot be passed. A coroutine's Lua state is tied to the Lua state that created it, and there is no way the mixed C/Lua stack of a coroutine can be transfered from one Lua state to another.</li> |
1128 | </ul> | 1137 | </ul> |
1129 | </p> | 1138 | </p> |
1130 | 1139 | ||
@@ -1158,7 +1167,7 @@ events to a common Linda, but... :).</font> | |||
1158 | // expects a C function on top of the source Lua stack | 1167 | // expects a C function on top of the source Lua stack |
1159 | copy_func( lua_State *dest, lua_State* source) | 1168 | copy_func( lua_State *dest, lua_State* source) |
1160 | { | 1169 | { |
1161 | // extract C function pointer from source | 1170 | // fetch function 'name' from source lookup database |
1162 | char const* funcname = lookup_func_name( source, -1); | 1171 | char const* funcname = lookup_func_name( source, -1); |
1163 | // lookup a function bound to this name in the destination state, and push it on the stack | 1172 | // lookup a function bound to this name in the destination state, and push it on the stack |
1164 | push_resolved_func( dest, funcname); | 1173 | push_resolved_func( dest, funcname); |
@@ -1200,14 +1209,14 @@ events to a common Linda, but... :).</font> | |||
1200 | <li> | 1209 | <li> |
1201 | 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. | 1210 | 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. |
1202 | When Lua is built with compatibility options (such as LUA_COMPAT_ALL), this causes several base libraries to register functions under multiple names. | 1211 | When Lua is built with compatibility options (such as LUA_COMPAT_ALL), this causes several base libraries to register functions under multiple names. |
1203 | This, with the randomizer, can cause the first name of a function to be different on different VMs, which breaks function transfer. | 1212 | This, with the randomizer, can cause the first encountered name of a function to be different on different VMs, which breaks function transfer. |
1204 | <b>This means that Lua 5.2 must be built WITHOUT compatibility options to be able to use Lanes.</b> | 1213 | <b>This means that Lua 5.2 must be built WITHOUT compatibility options to be able to use Lanes.</b> |
1205 | Even under Lua 5.1, this may cause trouble (even if this would be much less frequent). | 1214 | Even under Lua 5.1, this may cause trouble (even if this would be much less frequent). |
1206 | Unfortunately, this fails with <tt>string.gfind</tt>/<tt>string.gmatch</tt> when Lua 5.1 is built with <tt>LUA_COMPAT_GFIND</tt> (which is the case of LuaBinaries), | 1215 | Unfortunately, we get bitten by <tt>string.gfind</tt>/<tt>string.gmatch</tt> when Lua 5.1 is built with <tt>LUA_COMPAT_GFIND</tt> (which is the case of LuaBinaries), |
1207 | so for the time being, Lanes fails only for Lua 5.2 as the randomizer is the real show breaker here. | 1216 | so for the time being, Lanes fails only for Lua 5.2 as the randomizer is the real show breaker here. |
1208 | </li> | 1217 | </li> |
1209 | </ul> | 1218 | </ul> |
1210 | Another more direct reason of failed transfer is that 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. | 1219 | 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. |
1211 | If the C function is sent through a linda, it is enough for the destination lane body to have required the module before the function is sent. | 1220 | If the C function is sent through a linda, it is enough for the destination lane body to have required the module before the function is sent. |
1212 | But if the lane body provided to the generator has a C function as upvalue, the transfer itself must succeed, therefore the module that imported that C function must be required in the destination lane before the lane body starts executing. This is where the <a href = "#.required"><tt>.required</tt></a> options play their role. | 1221 | But if the lane body provided to the generator has a C function as upvalue, the transfer itself must succeed, therefore the module that imported that C function must be required in the destination lane before the lane body starts executing. This is where the <a href = "#.required"><tt>.required</tt></a> options play their role. |
1213 | </p> | 1222 | </p> |