From b45e3246cee8c92b72622808f03b5cb7d539e244 Mon Sep 17 00:00:00 2001 From: Mike Pall Date: Tue, 9 Nov 2010 18:11:35 +0100 Subject: [PATCH] Split up extension/API docs into sub-pages. --- doc/api.html | 337 -------------------------------------------- doc/changes.html | 7 +- doc/contact.html | 7 +- doc/ext_c_api.html | 174 +++++++++++++++++++++++ doc/ext_jit.html | 177 +++++++++++++++++++++++ doc/extensions.html | 303 +++++++++++++++++++++++++++++++++++++++ doc/faq.html | 7 +- doc/install.html | 21 +-- doc/luajit.html | 7 +- doc/running.html | 7 +- doc/status.html | 7 +- 11 files changed, 703 insertions(+), 351 deletions(-) delete mode 100644 doc/api.html create mode 100644 doc/ext_c_api.html create mode 100644 doc/ext_jit.html create mode 100644 doc/extensions.html diff --git a/doc/api.html b/doc/api.html deleted file mode 100644 index eee76afb..00000000 --- a/doc/api.html +++ /dev/null @@ -1,337 +0,0 @@ - - - -API Extensions - - - - - - - - -
-Lua -
- - -
-

-LuaJIT is fully upwards-compatible with Lua 5.1. It supports all -» standard Lua -library functions and the full set of -» Lua/C API -functions. -

-

-LuaJIT is also fully ABI-compatible to Lua 5.1 at the linker/dynamic -loader level. This means you can compile a C module against the -standard Lua headers and load the same shared library from either Lua -or LuaJIT. -

- -

bit.* — Bitwise Operations

-

-LuaJIT supports all bitwise operations as defined by -» Lua BitOp: -

-
-bit.tobit  bit.tohex  bit.bnot    bit.band bit.bor  bit.bxor
-bit.lshift bit.rshift bit.arshift bit.rol  bit.ror  bit.bswap
-
-

-This module is a LuaJIT built-in — you don't need to download or -install Lua BitOp. The Lua BitOp site has full documentation for all -» Lua BitOp API functions. -

-

-Please make sure to require the module before using any of -its functions: -

-
-local bit = require("bit")
-
-

-An already installed Lua BitOp module is ignored by LuaJIT. -This way you can use bit operations from both Lua and LuaJIT on a -shared installation. -

- -

jit.* — JIT compiler control

-

-The functions in this built-in module control the behavior -of the JIT compiler engine. -

- -

jit.on()
-jit.off()

-

-Turns the whole JIT compiler on (default) or off. -

-

-These functions are typically used with the command line options --j on or -j off. -

- -

jit.flush()

-

-Flushes the whole cache of compiled code. -

- -

jit.on(func|true [,true|false])
-jit.off(func|true [,true|false])
-jit.flush(func|true [,true|false])

-

-jit.on enables JIT compilation for a Lua function (this is -the default). -

-

-jit.off disables JIT compilation for a Lua function and -flushes any already compiled code from the code cache. -

-

-jit.flush flushes the code, but doesn't affect the -enable/disable status. -

-

-The current function, i.e. the Lua function calling this library -function, can also be specified by passing true as the first -argument. -

-

-If the second argument is true, JIT compilation is also -enabled, disabled or flushed recursively for all sub-functions of a -function. With false only the sub-functions are affected. -

-

-The jit.on and jit.off functions only set a flag -which is checked when the function is about to be compiled. They do -not trigger immediate compilation. -

-

-Typical usage is jit.off(true, true) in the main chunk -of a module to turn off JIT compilation for the whole module for -debugging purposes. -

- -

jit.flush(tr)

-

-Flushes the specified root trace and all of its side traces from the cache. -The code for the trace will be retained as long as there are any other -traces which link to it. -

- -

status, ... = jit.status()

-

-Returns the current status of the JIT compiler. The first result is -either true or false if the JIT compiler is turned -on or off. The remaining results are strings for CPU-specific features -and enabled optimizations. -

- -

jit.version

-

-Contains the LuaJIT version string. -

- -

jit.version_num

-

-Contains the version number of the LuaJIT core. Version xx.yy.zz -is represented by the decimal number xxyyzz. -

- -

jit.arch

-

-Contains the target architecture name (CPU and optional ABI). -

- -

jit.opt.* — JIT compiler optimization control

-

-This module provides the backend for the -O command line -option. -

-

-You can also use it programmatically, e.g.: -

-
-jit.opt.start(2) -- same as -O2
-jit.opt.start("-dce")
-jit.opt.start("hotloop=10", "hotexit=2")
-
-

-Unlike in LuaJIT 1.x, the module is built-in and -optimization is turned on by default! -It's no longer necessary to run require("jit.opt").start(), -which was one of the ways to enable optimization. -

- -

jit.util.* — JIT compiler introspection

-

-This module holds functions to introspect the bytecode, generated -traces, the IR and the generated machine code. The functionality -provided by this module is still in flux and therefore undocumented. -

-

-The debug modules -jbc, -jv and -jdump make -extensive use of these functions. Please check out their source code, -if you want to know more. -

- -

C API extensions

-

-LuaJIT adds some extensions to the Lua/C API. The LuaJIT include -directory must be in the compiler search path (-Ipath) -to be able to include the required header for C code: -

-
-#include "luajit.h"
-
-

-Or for C++ code: -

-
-#include "lua.hpp"
-
- -

luaJIT_setmode(L, idx, mode) -— Control VM

-

-This is a C API extension to allow control of the VM from C code. The -full prototype of LuaJIT_setmode is: -

-
-LUA_API int luaJIT_setmode(lua_State *L, int idx, int mode);
-
-

-The returned status is either success (1) or failure (0). -The second argument is either 0 or a stack index (similar to the -other Lua/C API functions). -

-

-The third argument specifies the mode, which is 'or'ed with a flag. -The flag can be LUAJIT_MODE_OFF to turn a feature on, -LUAJIT_MODE_ON to turn a feature off, or -LUAJIT_MODE_FLUSH to flush cached code. -

-

-The following modes are defined: -

- -

luaJIT_setmode(L, 0, LUAJIT_MODE_ENGINE|flag)

-

-Turn the whole JIT compiler on or off or flush the whole cache of compiled code. -

- -

luaJIT_setmode(L, idx, LUAJIT_MODE_FUNC|flag)
-luaJIT_setmode(L, idx, LUAJIT_MODE_ALLFUNC|flag)
-luaJIT_setmode(L, idx, LUAJIT_MODE_ALLSUBFUNC|flag)

-

-This sets the mode for the function at the stack index idx or -the parent of the calling function (idx = 0). It either -enables JIT compilation for a function, disables it and flushes any -already compiled code or only flushes already compiled code. This -applies recursively to all sub-functions of the function with -LUAJIT_MODE_ALLFUNC or only to the sub-functions with -LUAJIT_MODE_ALLSUBFUNC. -

- -

luaJIT_setmode(L, trace,
-  LUAJIT_MODE_TRACE|LUAJIT_MODE_FLUSH)

-

-Flushes the specified root trace and all of its side traces from the cache. -The code for the trace will be retained as long as there are any other -traces which link to it. -

- -

luaJIT_setmode(L, idx, LUAJIT_MODE_WRAPCFUNC|flag)

-

-This mode defines a wrapper function for calls to C functions. If -called with LUAJIT_MODE_ON, the stack index at idx -must be a lightuserdata object holding a pointer to the wrapper -function. From now on all C functions are called through the wrapper -function. If called with LUAJIT_MODE_OFF this mode is turned -off and all C functions are directly called. -

-

-The wrapper function can be used for debugging purposes or to catch -and convert foreign exceptions. Recommended usage can be seen in this -C++ code excerpt: -

-
-#include <exception>
-#include "lua.hpp"
-
-// Catch C++ exceptions and convert them to Lua error messages.
-// Customize as needed for your own exception classes.
-static int wrap_exceptions(lua_State *L, lua_CFunction f)
-{
-  try {
-    return f(L);  // Call wrapped function and return result.
-  } catch (const char *s) {  // Catch and convert exceptions.
-    lua_pushstring(L, s);
-  } catch (std::exception& e) {
-    lua_pushstring(L, e.what());
-  } catch (...) {
-    lua_pushliteral(L, "caught (...)");
-  }
-  return lua_error(L);  // Rethrow as a Lua error.
-}
-
-static int myinit(lua_State *L)
-{
-  ...
-  // Define wrapper function and enable it.
-  lua_pushlightuserdata(L, (void *)wrap_exceptions);
-  luaJIT_setmode(L, -1, LUAJIT_MODE_WRAPCFUNC|LUAJIT_MODE_ON);
-  lua_pop(L, 1);
-  ...
-}
-
-

-Note that you can only define a single global wrapper function, -so be careful when using this mechanism from multiple C++ modules. -Also note that this mechanism is not without overhead. -

-

-LuaJIT already intercepts exception handling for systems using DWARF2 -stack unwinding (e.g. Linux or OSX) and for Windows/x64 (but not -for Windows/x86). This is a zero-cost mechanism and always enabled. -You don't need to use any wrapper functions, except when you want to get -a more specific error message than "C++ exception". -

-
-
- - - diff --git a/doc/changes.html b/doc/changes.html index 54f17a16..b7ac0734 100644 --- a/doc/changes.html +++ b/doc/changes.html @@ -26,8 +26,13 @@ div.major { max-width: 600px; padding: 1em; margin: 1em 0 1em 0; } Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/contact.html b/doc/contact.html index afd17451..13175844 100644 --- a/doc/contact.html +++ b/doc/contact.html @@ -23,8 +23,13 @@ Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/ext_c_api.html b/doc/ext_c_api.html new file mode 100644 index 00000000..1418b2a9 --- /dev/null +++ b/doc/ext_c_api.html @@ -0,0 +1,174 @@ + + + +Lua/C API Extensions + + + + + + + + +
    +Lua +
    + + +
    +

    +LuaJIT adds some extensions to the standard Lua/C API. The LuaJIT include +directory must be in the compiler search path (-Ipath) +to be able to include the required header for C code: +

    +
    +#include "luajit.h"
+
    +

    +Or for C++ code: +

    +
    +#include "lua.hpp"
+
    + +

    luaJIT_setmode(L, idx, mode) +— Control VM

    +

    +This is a C API extension to allow control of the VM from C code. The +full prototype of LuaJIT_setmode is: +

    +
    +LUA_API int luaJIT_setmode(lua_State *L, int idx, int mode);
+
    +

    +The returned status is either success (1) or failure (0). +The second argument is either 0 or a stack index (similar to the +other Lua/C API functions). +

    +

    +The third argument specifies the mode, which is 'or'ed with a flag. +The flag can be LUAJIT_MODE_OFF to turn a feature on, +LUAJIT_MODE_ON to turn a feature off, or +LUAJIT_MODE_FLUSH to flush cached code. +

    +

    +The following modes are defined: +

    + +

    luaJIT_setmode(L, 0, LUAJIT_MODE_ENGINE|flag)

    +

    +Turn the whole JIT compiler on or off or flush the whole cache of compiled code. +

    + +

    luaJIT_setmode(L, idx, LUAJIT_MODE_FUNC|flag)
    +luaJIT_setmode(L, idx, LUAJIT_MODE_ALLFUNC|flag)
    +luaJIT_setmode(L, idx, LUAJIT_MODE_ALLSUBFUNC|flag)

    +

    +This sets the mode for the function at the stack index idx or +the parent of the calling function (idx = 0). It either +enables JIT compilation for a function, disables it and flushes any +already compiled code or only flushes already compiled code. This +applies recursively to all sub-functions of the function with +LUAJIT_MODE_ALLFUNC or only to the sub-functions with +LUAJIT_MODE_ALLSUBFUNC. +

    + +

    luaJIT_setmode(L, trace,
    +  LUAJIT_MODE_TRACE|LUAJIT_MODE_FLUSH)

    +

    +Flushes the specified root trace and all of its side traces from the cache. +The code for the trace will be retained as long as there are any other +traces which link to it. +

    + +

    luaJIT_setmode(L, idx, LUAJIT_MODE_WRAPCFUNC|flag)

    +

    +This mode defines a wrapper function for calls to C functions. If +called with LUAJIT_MODE_ON, the stack index at idx +must be a lightuserdata object holding a pointer to the wrapper +function. From now on all C functions are called through the wrapper +function. If called with LUAJIT_MODE_OFF this mode is turned +off and all C functions are directly called. +

    +

    +The wrapper function can be used for debugging purposes or to catch +and convert foreign exceptions. But please read the section on +C++ exception interoperability +first. Recommended usage can be seen in this C++ code excerpt: +

    +
    +#include <exception>
+#include "lua.hpp"
+
+// Catch C++ exceptions and convert them to Lua error messages.
+// Customize as needed for your own exception classes.
+static int wrap_exceptions(lua_State *L, lua_CFunction f)
+{
+  try {
+    return f(L);  // Call wrapped function and return result.
+  } catch (const char *s) {  // Catch and convert exceptions.
+    lua_pushstring(L, s);
+  } catch (std::exception& e) {
+    lua_pushstring(L, e.what());
+  } catch (...) {
+    lua_pushliteral(L, "caught (...)");
+  }
+  return lua_error(L);  // Rethrow as a Lua error.
+}
+
+static int myinit(lua_State *L)
+{
+  ...
+  // Define wrapper function and enable it.
+  lua_pushlightuserdata(L, (void *)wrap_exceptions);
+  luaJIT_setmode(L, -1, LUAJIT_MODE_WRAPCFUNC|LUAJIT_MODE_ON);
+  lua_pop(L, 1);
+  ...
+}
+
    +

    +Note that you can only define a single global wrapper function, +so be careful when using this mechanism from multiple C++ modules. +Also note that this mechanism is not without overhead. +

    +
    +
    + + + diff --git a/doc/ext_jit.html b/doc/ext_jit.html new file mode 100644 index 00000000..d621476b --- /dev/null +++ b/doc/ext_jit.html @@ -0,0 +1,177 @@ + + + +jit.* Library + + + + + + + + +
    +Lua +
    + + +
    +

    +The functions in this built-in module control the behavior +of the JIT compiler engine. +

    + +

    jit.on()
    +jit.off()

    +

    +Turns the whole JIT compiler on (default) or off. +

    +

    +These functions are typically used with the command line options +-j on or -j off. +

    + +

    jit.flush()

    +

    +Flushes the whole cache of compiled code. +

    + +

    jit.on(func|true [,true|false])
    +jit.off(func|true [,true|false])
    +jit.flush(func|true [,true|false])

    +

    +jit.on enables JIT compilation for a Lua function (this is +the default). +

    +

    +jit.off disables JIT compilation for a Lua function and +flushes any already compiled code from the code cache. +

    +

    +jit.flush flushes the code, but doesn't affect the +enable/disable status. +

    +

    +The current function, i.e. the Lua function calling this library +function, can also be specified by passing true as the first +argument. +

    +

    +If the second argument is true, JIT compilation is also +enabled, disabled or flushed recursively for all sub-functions of a +function. With false only the sub-functions are affected. +

    +

    +The jit.on and jit.off functions only set a flag +which is checked when the function is about to be compiled. They do +not trigger immediate compilation. +

    +

    +Typical usage is jit.off(true, true) in the main chunk +of a module to turn off JIT compilation for the whole module for +debugging purposes. +

    + +

    jit.flush(tr)

    +

    +Flushes the specified root trace and all of its side traces from the cache. +The code for the trace will be retained as long as there are any other +traces which link to it. +

    + +

    status, ... = jit.status()

    +

    +Returns the current status of the JIT compiler. The first result is +either true or false if the JIT compiler is turned +on or off. The remaining results are strings for CPU-specific features +and enabled optimizations. +

    + +

    jit.version

    +

    +Contains the LuaJIT version string. +

    + +

    jit.version_num

    +

    +Contains the version number of the LuaJIT core. Version xx.yy.zz +is represented by the decimal number xxyyzz. +

    + +

    jit.arch

    +

    +Contains the target architecture name (CPU and optional ABI). +

    + +

    jit.opt.* — JIT compiler optimization control

    +

    +This sub-module provides the backend for the -O command line +option. +

    +

    +You can also use it programmatically, e.g.: +

    +
    +jit.opt.start(2) -- same as -O2
+jit.opt.start("-dce")
+jit.opt.start("hotloop=10", "hotexit=2")
+
    +

    +Unlike in LuaJIT 1.x, the module is built-in and +optimization is turned on by default! +It's no longer necessary to run require("jit.opt").start(), +which was one of the ways to enable optimization. +

    + +

    jit.util.* — JIT compiler introspection

    +

    +This sub-module holds functions to introspect the bytecode, generated +traces, the IR and the generated machine code. The functionality +provided by this module is still in flux and therefore undocumented. +

    +

    +The debug modules -jbc, -jv and -jdump make +extensive use of these functions. Please check out their source code, +if you want to know more. +

    +
    +
    + + + diff --git a/doc/extensions.html b/doc/extensions.html new file mode 100644 index 00000000..e302952d --- /dev/null +++ b/doc/extensions.html @@ -0,0 +1,303 @@ + + + +Extensions + + + + + + + + + +
    +Lua +
    + + +
    +

    +LuaJIT is fully upwards-compatible with Lua 5.1. It supports all +» standard Lua +library functions and the full set of +» Lua/C API +functions. +

    +

    +LuaJIT is also fully ABI-compatible to Lua 5.1 at the linker/dynamic +loader level. This means you can compile a C module against the +standard Lua headers and load the same shared library from either Lua +or LuaJIT. +

    +

    +LuaJIT extends the standard Lua VM with new functionality and adds +several extension modules. Please note that this page is only about +functional enhancements and not about performance enhancements, +such as the optimized VM, the faster interpreter or the JIT compiler. +

    + +

    Extensions Modules

    +

    +LuaJIT comes with several built-in extension modules: +

    + +

    bit.* — Bitwise operations

    +

    +LuaJIT supports all bitwise operations as defined by +» Lua BitOp: +

    +
    +bit.tobit  bit.tohex  bit.bnot    bit.band bit.bor  bit.bxor
+bit.lshift bit.rshift bit.arshift bit.rol  bit.ror  bit.bswap
+
    +

    +This module is a LuaJIT built-in — you don't need to download or +install Lua BitOp. The Lua BitOp site has full documentation for all +» Lua BitOp API functions. +

    +

    +Please make sure to require the module before using any of +its functions: +

    +
    +local bit = require("bit")
+
    +

    +An already installed Lua BitOp module is ignored by LuaJIT. +This way you can use bit operations from both Lua and LuaJIT on a +shared installation. +

    + +

    jit.* — JIT compiler control

    +

    +The functions in this module +control the behavior of the JIT compiler engine. +

    + +

    C API extensions

    +

    +LuaJIT adds some +extra functions to the Lua/C API. +

    + +

    Enhanced Standard Library Functions

    + +

    xpcall(f, err [,args...]) passes arguments

    +

    +Unlike the standard implementation in Lua 5.1, xpcall() +passes any arguments after the error function to the function +which is called in a protected context. +

    + +

    loadfile() etc. handle UTF-8 source code

    +

    +Non-ASCII characters are handled transparently by the Lua source code parser. +This allows the use of UTF-8 characters in identifiers and strings. +A UTF-8 BOM is skipped at the start of the source code. +

    + +

    tostring() etc. canonicalize NaN and ±Inf

    +

    +All number-to-string conversions consistently convert non-finite numbers +to the same strings on all platforms. NaN results in "nan", +positive infinity results in "inf" and negative infinity results +in "-inf". +

    + +

    Enhanced PRNG for math.random()

    +

    +LuaJIT uses a Tausworthe PRNG with period 2^223 to implement +math.random() and math.randomseed(). The quality of +the PRNG results is much superior compared to the standard Lua +implementation which uses the platform-specific ANSI rand(). +

    +

    +The PRNG generates the same sequences from the same seeds on all +platforms and makes use of all bits in the seed argument. +math.random() without arguments generates 52 pseudo-random bits +for every call. The result is uniformly distributed between 0 and 1. +It's correctly scaled up and rounded for math.random(n [,m]) to +preserve uniformity. +

    + +

    io.* functions handle 64 bit file offsets

    +

    +The file I/O functions in the standard io.* library handle +64 bit file offsets. In particular this means it's possible +to open files larger than 2 Gigabytes and to reposition or obtain +the current file position for offsets beyond 2 GB +(fp:seek() method). +

    + +

    debug.* functions identify metamethods

    +

    +debug.getinfo() and lua_getinfo() also return information +about invoked metamethods. The namewhat field is set to +"metamethod" and the name field has the name of +the corresponding metamethod (e.g. "__index"). +

    + +

    Fully Resumable VM

    +

    +The LuaJIT 2.x VM is fully resumable. This means you can yield from a +coroutine even across contexts, where this would not possible with +the standard Lua 5.1 VM: e.g. you can yield across pcall() +and xpcall(), across iterators and across metamethods. +

    +

    +Note however that LuaJIT 2.x doesn't use +» Coco anymore. This means the +overhead for creating coroutines is much smaller and no extra +C stacks need to be allocated. OTOH you can no longer yield +across arbitrary C functions. Keep this in mind when +upgrading from LuaJIT 1.x. +

    + +

    C++ Exception Interoperability

    +

    +LuaJIT has built-in support for interoperating with C++ exceptions. +The available range of features depends on the target platform and +the toolchain used to compile LuaJIT: +

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PlatformCompilerInteroperability
    POSIX/x64, DWARF2 unwindingGCC 4.3+Full
    Other platforms, DWARF2 unwindingGCCLimited
    Windows/x64MSVC or WinSDKFull
    Windows/x86AnyNo
    Other platformsOther compilersNo
    +

    +Full interoperability means: +

    +
      +
    • C++ exceptions can be caught on the Lua side with pcall(), +lua_pcall() etc.
      • +
    • C++ exceptions will be converted to the generic Lua error +"C++ exception", unless you use the +C call wrapper feature.
      • +
    • It's safe to throw C++ exceptions across non-protected Lua frames +on the C stack. The contents of the C++ exception object +pass through unmodified.
      • +
    • Lua errors can be caught on the C++ side with catch(...). +The corresponding Lua error message can be retrieved from the Lua stack.
      • +
    • Throwing Lua errors across C++ frames is safe. C++ destructors +will be called.
      • +
    +

    +Limited interoperability means: +

    +
      +
    • C++ exceptions can be caught on the Lua side with pcall(), +lua_pcall() etc.
      • +
    • C++ exceptions will be converted to the generic Lua error +"C++ exception", unless you use the +C call wrapper feature.
      • +
    • C++ exceptions will be caught by non-protected Lua frames and +are rethrown as a generic Lua error. The C++ exception object will +be destroyed.
      • +
    • Lua errors cannot be caught on the C++ side.
      • +
    • Throwing Lua errors across C++ frames will not call +C++ destructors.
      • +
    + +

    +No interoperability means: +

    +
      +
    • It's not safe to throw C++ exceptions across Lua frames.
      • +
    • C++ exceptions cannot be caught on the Lua side.
      • +
    • Lua errors cannot be caught on the C++ side.
      • +
    • Throwing Lua errors across C++ frames will not call +C++ destructors.
      • +
    • Additionally, on Windows/x86 with SEH-based C++ exceptions: +it's not safe to throw a Lua error across any frames containing +a C++ function with any try/catch construct or using variables with +(implicit) destructors. This also applies to any functions which may be +inlined in such a function. It doesn't matter whether lua_error() +is called inside or outside of a try/catch or whether any object actually +needs to be destroyed: the SEH chain is corrupted and this will eventually +lead to the termination of the process.
      • +
    +
    +
    + + + diff --git a/doc/faq.html b/doc/faq.html index 9404f788..c1d86db9 100644 --- a/doc/faq.html +++ b/doc/faq.html @@ -26,8 +26,13 @@ dd { margin-left: 1.5em; } Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/install.html b/doc/install.html index 775b3470..9dac37a3 100644 --- a/doc/install.html +++ b/doc/install.html @@ -13,19 +13,19 @@ table.compat { line-height: 1.2; width: 600px; } -tr.compathead td { +table.compat td { + border: 1px solid #bfcfff; + font-size: 90%; + height: 2.5em; +} +table.compat tr.compathead td { font-weight: bold; border-bottom: 2px solid #bfcfff; } tr.compathead td.compatos { vertical-align: top; } -td { - border: 1px solid #bfcfff; - font-size: 90%; - height: 2.5em; -} -td.compatcpu { +table.compat td.compatcpu { width: 16%; border-right: 2px solid #bfcfff; } @@ -52,8 +52,13 @@ td.compatno { Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/luajit.html b/doc/luajit.html index 71e6a19f..990cd630 100644 --- a/doc/luajit.html +++ b/doc/luajit.html @@ -24,8 +24,13 @@ Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/running.html b/doc/running.html index e337d535..6991ef7a 100644 --- a/doc/running.html +++ b/doc/running.html @@ -45,8 +45,13 @@ td.param_default { Installation
  • Running +
  • -API Extensions +Extensions +
  • Status diff --git a/doc/status.html b/doc/status.html index a508dca1..15e114c2 100644 --- a/doc/status.html +++ b/doc/status.html @@ -26,8 +26,13 @@ ul li { padding-bottom: 0.3em; } Installation
  • Running +
  • -API Extensions +Extensions +
  • Status