diff options
| author | Mike Pall <mike> | 2022-06-23 09:10:09 +0200 |
|---|---|---|
| committer | Mike Pall <mike> | 2022-06-23 09:10:09 +0200 |
| commit | 2e98c3d0644fc0c265844908f43b7e4526dd819c (patch) | |
| tree | b9116c671f4268be7776696abdb189de4be5cf43 | |
| parent | 7dc3850e78493eed1e85fa7bc0b96068ae7fb9f4 (diff) | |
| download | luajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.tar.gz luajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.tar.bz2 luajit-2e98c3d0644fc0c265844908f43b7e4526dd819c.zip | |
Grammar and spell check.
| -rw-r--r-- | doc/ext_c_api.html | 4 | ||||
| -rw-r--r-- | doc/ext_ffi.html | 14 | ||||
| -rw-r--r-- | doc/ext_ffi_api.html | 10 | ||||
| -rw-r--r-- | doc/ext_ffi_semantics.html | 58 | ||||
| -rw-r--r-- | doc/ext_ffi_tutorial.html | 24 | ||||
| -rw-r--r-- | doc/ext_jit.html | 4 | ||||
| -rw-r--r-- | doc/extensions.html | 8 | ||||
| -rw-r--r-- | doc/faq.html | 6 | ||||
| -rw-r--r-- | doc/install.html | 8 | ||||
| -rw-r--r-- | doc/running.html | 4 | ||||
| -rw-r--r-- | doc/status.html | 4 |
11 files changed, 72 insertions, 72 deletions
diff --git a/doc/ext_c_api.html b/doc/ext_c_api.html index a5d02473..b328047a 100644 --- a/doc/ext_c_api.html +++ b/doc/ext_c_api.html | |||
| @@ -103,7 +103,7 @@ Turn the whole JIT compiler on or off or flush the whole cache of compiled code. | |||
| 103 | This sets the mode for the function at the stack index <tt>idx</tt> or | 103 | This sets the mode for the function at the stack index <tt>idx</tt> or |
| 104 | the parent of the calling function (<tt>idx = 0</tt>). It either | 104 | the parent of the calling function (<tt>idx = 0</tt>). It either |
| 105 | enables JIT compilation for a function, disables it and flushes any | 105 | enables JIT compilation for a function, disables it and flushes any |
| 106 | already compiled code or only flushes already compiled code. This | 106 | already compiled code, or only flushes already compiled code. This |
| 107 | applies recursively to all sub-functions of the function with | 107 | applies recursively to all sub-functions of the function with |
| 108 | <tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with | 108 | <tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with |
| 109 | <tt>LUAJIT_MODE_ALLSUBFUNC</tt>. | 109 | <tt>LUAJIT_MODE_ALLSUBFUNC</tt>. |
| @@ -122,7 +122,7 @@ traces which link to it. | |||
| 122 | This mode defines a wrapper function for calls to C functions. If | 122 | This mode defines a wrapper function for calls to C functions. If |
| 123 | called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt> | 123 | called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt> |
| 124 | must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper | 124 | must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper |
| 125 | function. From now on all C functions are called through the wrapper | 125 | function. From now on, all C functions are called through the wrapper |
| 126 | function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned | 126 | function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned |
| 127 | off and all C functions are directly called. | 127 | off and all C functions are directly called. |
| 128 | </p> | 128 | </p> |
diff --git a/doc/ext_ffi.html b/doc/ext_ffi.html index 7a87ca65..04b78d98 100644 --- a/doc/ext_ffi.html +++ b/doc/ext_ffi.html | |||
| @@ -153,7 +153,7 @@ call the binding function. Phew! | |||
| 153 | <h2 id="cdata">Motivating Example: Using C Data Structures</h2> | 153 | <h2 id="cdata">Motivating Example: Using C Data Structures</h2> |
| 154 | <p> | 154 | <p> |
| 155 | The FFI library allows you to create and access C data | 155 | The FFI library allows you to create and access C data |
| 156 | structures. Of course the main use for this is for interfacing with | 156 | structures. Of course, the main use for this is for interfacing with |
| 157 | C functions. But they can be used stand-alone, too. | 157 | C functions. But they can be used stand-alone, too. |
| 158 | </p> | 158 | </p> |
| 159 | <p> | 159 | <p> |
| @@ -165,7 +165,7 @@ implemented with a big table holding lots of tiny tables. This imposes | |||
| 165 | both a substantial memory overhead as well as a performance overhead. | 165 | both a substantial memory overhead as well as a performance overhead. |
| 166 | </p> | 166 | </p> |
| 167 | <p> | 167 | <p> |
| 168 | Here's a sketch of a library that operates on color images plus a | 168 | Here's a sketch of a library that operates on color images, plus a |
| 169 | simple benchmark. First, the plain Lua version: | 169 | simple benchmark. First, the plain Lua version: |
| 170 | </p> | 170 | </p> |
| 171 | <pre class="code"> | 171 | <pre class="code"> |
| @@ -180,7 +180,7 @@ local function image_ramp_green(n) | |||
| 180 | return img | 180 | return img |
| 181 | end | 181 | end |
| 182 | 182 | ||
| 183 | local function image_to_grey(img, n) | 183 | local function image_to_gray(img, n) |
| 184 | for i=1,n do | 184 | for i=1,n do |
| 185 | local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue) | 185 | local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue) |
| 186 | img[i].red = y; img[i].green = y; img[i].blue = y | 186 | img[i].red = y; img[i].green = y; img[i].blue = y |
| @@ -190,14 +190,14 @@ end | |||
| 190 | local N = 400*400 | 190 | local N = 400*400 |
| 191 | local img = image_ramp_green(N) | 191 | local img = image_ramp_green(N) |
| 192 | for i=1,1000 do | 192 | for i=1,1000 do |
| 193 | image_to_grey(img, N) | 193 | image_to_gray(img, N) |
| 194 | end | 194 | end |
| 195 | </pre> | 195 | </pre> |
| 196 | <p> | 196 | <p> |
| 197 | This creates a table with 160.000 pixels, each of which is a table | 197 | This creates a table with 160.000 pixels, each of which is a table |
| 198 | holding four number values in the range of 0-255. First an image with | 198 | holding four number values in the range of 0-255. First, an image with |
| 199 | a green ramp is created (1D for simplicity), then the image is | 199 | a green ramp is created (1D for simplicity), then the image is |
| 200 | converted to greyscale 1000 times. Yes, that's silly, but I was in | 200 | converted to grayscale 1000 times. Yes, that's silly, but I was in |
| 201 | need of a simple example ... | 201 | need of a simple example ... |
| 202 | </p> | 202 | </p> |
| 203 | <p> | 203 | <p> |
| @@ -304,7 +304,7 @@ be more compact and faster. This is certainly true (by a factor of | |||
| 304 | ~1.7x). Switching to a struct-of-arrays would help, too. | 304 | ~1.7x). Switching to a struct-of-arrays would help, too. |
| 305 | </p> | 305 | </p> |
| 306 | <p style="font-size: 8pt;"> | 306 | <p style="font-size: 8pt;"> |
| 307 | However the resulting code would be less idiomatic and rather | 307 | However, the resulting code would be less idiomatic and rather |
| 308 | error-prone. And it still doesn't get even close to the performance of | 308 | error-prone. And it still doesn't get even close to the performance of |
| 309 | the FFI version of the code. Also, high-level data structures cannot | 309 | the FFI version of the code. Also, high-level data structures cannot |
| 310 | be easily passed to other C functions, especially I/O functions, | 310 | be easily passed to other C functions, especially I/O functions, |
diff --git a/doc/ext_ffi_api.html b/doc/ext_ffi_api.html index 687b85c5..962db6dc 100644 --- a/doc/ext_ffi_api.html +++ b/doc/ext_ffi_api.html | |||
| @@ -117,7 +117,7 @@ separated by semicolons. The trailing semicolon for a single | |||
| 117 | declaration may be omitted. | 117 | declaration may be omitted. |
| 118 | </p> | 118 | </p> |
| 119 | <p> | 119 | <p> |
| 120 | Please note that external symbols are only <em>declared</em>, but they | 120 | Please note, that external symbols are only <em>declared</em>, but they |
| 121 | are <em>not bound</em> to any specific address, yet. Binding is | 121 | are <em>not bound</em> to any specific address, yet. Binding is |
| 122 | achieved with C library namespaces (see below). | 122 | achieved with C library namespaces (see below). |
| 123 | </p> | 123 | </p> |
| @@ -205,7 +205,7 @@ parse the cdecl only once and get its ctype with | |||
| 205 | <tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly. | 205 | <tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly. |
| 206 | </p> | 206 | </p> |
| 207 | <p style="font-size: 8pt;"> | 207 | <p style="font-size: 8pt;"> |
| 208 | Please note that an anonymous <tt>struct</tt> declaration implicitly | 208 | Please note, that an anonymous <tt>struct</tt> declaration implicitly |
| 209 | creates a new and distinguished ctype every time you use it for | 209 | creates a new and distinguished ctype every time you use it for |
| 210 | <tt>ffi.new()</tt>. This is probably <b>not</b> what you want, | 210 | <tt>ffi.new()</tt>. This is probably <b>not</b> what you want, |
| 211 | especially if you create more than one cdata object. Different anonymous | 211 | especially if you create more than one cdata object. Different anonymous |
| @@ -252,12 +252,12 @@ afterwards. Neither the contents of the <tt>metatable</tt> nor the | |||
| 252 | contents of an <tt>__index</tt> table (if any) may be modified | 252 | contents of an <tt>__index</tt> table (if any) may be modified |
| 253 | afterwards. The associated metatable automatically applies to all uses | 253 | afterwards. The associated metatable automatically applies to all uses |
| 254 | of this type, no matter how the objects are created or where they | 254 | of this type, no matter how the objects are created or where they |
| 255 | originate from. Note that pre-defined operations on types have | 255 | originate from. Note that predefined operations on types have |
| 256 | precedence (e.g. declared field names cannot be overridden). | 256 | precedence (e.g. declared field names cannot be overridden). |
| 257 | </p> | 257 | </p> |
| 258 | <p> | 258 | <p> |
| 259 | All standard Lua metamethods are implemented. These are called directly, | 259 | All standard Lua metamethods are implemented. These are called directly, |
| 260 | without shortcuts and on any mix of types. For binary operations, the | 260 | without shortcuts, and on any mix of types. For binary operations, the |
| 261 | left operand is checked first for a valid ctype metamethod. The | 261 | left operand is checked first for a valid ctype metamethod. The |
| 262 | <tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt> | 262 | <tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt> |
| 263 | types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a> | 263 | types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a> |
| @@ -484,7 +484,7 @@ have some extra methods: | |||
| 484 | <p> | 484 | <p> |
| 485 | Free the resources associated with a callback. The associated Lua | 485 | Free the resources associated with a callback. The associated Lua |
| 486 | function is unanchored and may be garbage collected. The callback | 486 | function is unanchored and may be garbage collected. The callback |
| 487 | function pointer is no longer valid and must not be called anymore | 487 | function pointer is no longer valid and must not be called again |
| 488 | (it may be reused by a subsequently created callback). | 488 | (it may be reused by a subsequently created callback). |
| 489 | </p> | 489 | </p> |
| 490 | 490 | ||
diff --git a/doc/ext_ffi_semantics.html b/doc/ext_ffi_semantics.html index 4909fedd..6c6f8ad7 100644 --- a/doc/ext_ffi_semantics.html +++ b/doc/ext_ffi_semantics.html | |||
| @@ -84,7 +84,7 @@ footprint. It's used by the <a href="ext_ffi_api.html">ffi.* library | |||
| 84 | functions</a> to declare C types or external symbols. | 84 | functions</a> to declare C types or external symbols. |
| 85 | </p> | 85 | </p> |
| 86 | <p> | 86 | <p> |
| 87 | It's only purpose is to parse C declarations, as found e.g. in | 87 | Its only purpose is to parse C declarations, as found e.g. in |
| 88 | C header files. Although it does evaluate constant expressions, | 88 | C header files. Although it does evaluate constant expressions, |
| 89 | it's <em>not</em> a C compiler. The body of <tt>inline</tt> | 89 | it's <em>not</em> a C compiler. The body of <tt>inline</tt> |
| 90 | C function definitions is simply ignored. | 90 | C function definitions is simply ignored. |
| @@ -161,7 +161,7 @@ function declarations.</li> | |||
| 161 | 161 | ||
| 162 | </ul> | 162 | </ul> |
| 163 | <p> | 163 | <p> |
| 164 | The following C types are pre-defined by the C parser (like | 164 | The following C types are predefined by the C parser (like |
| 165 | a <tt>typedef</tt>, except re-declarations will be ignored): | 165 | a <tt>typedef</tt>, except re-declarations will be ignored): |
| 166 | </p> | 166 | </p> |
| 167 | <ul> | 167 | <ul> |
| @@ -577,9 +577,9 @@ ffi.new("struct nested", {x=1,y={2,3}}) --> x = 1, y.a = 2, y.b = 3 | |||
| 577 | 577 | ||
| 578 | <h2 id="cdata_ops">Operations on cdata Objects</h2> | 578 | <h2 id="cdata_ops">Operations on cdata Objects</h2> |
| 579 | <p> | 579 | <p> |
| 580 | All of the standard Lua operators can be applied to cdata objects or a | 580 | All standard Lua operators can be applied to cdata objects or a |
| 581 | mix of a cdata object and another Lua object. The following list shows | 581 | mix of a cdata object and another Lua object. The following list shows |
| 582 | the pre-defined operations. | 582 | the predefined operations. |
| 583 | </p> | 583 | </p> |
| 584 | <p> | 584 | <p> |
| 585 | Reference types are dereferenced <em>before</em> performing each of | 585 | Reference types are dereferenced <em>before</em> performing each of |
| @@ -587,7 +587,7 @@ the operations below — the operation is applied to the | |||
| 587 | C type pointed to by the reference. | 587 | C type pointed to by the reference. |
| 588 | </p> | 588 | </p> |
| 589 | <p> | 589 | <p> |
| 590 | The pre-defined operations are always tried first before deferring to a | 590 | The predefined operations are always tried first before deferring to a |
| 591 | metamethod or index table (if any) for the corresponding ctype (except | 591 | metamethod or index table (if any) for the corresponding ctype (except |
| 592 | for <tt>__new</tt>). An error is raised if the metamethod lookup or | 592 | for <tt>__new</tt>). An error is raised if the metamethod lookup or |
| 593 | index table lookup fails. | 593 | index table lookup fails. |
| @@ -637,7 +637,7 @@ assigning to an index of a vector raises an error.</li> | |||
| 637 | </ul> | 637 | </ul> |
| 638 | <p> | 638 | <p> |
| 639 | A ctype object can be indexed with a string key, too. The only | 639 | A ctype object can be indexed with a string key, too. The only |
| 640 | pre-defined operation is reading scoped constants of | 640 | predefined operation is reading scoped constants of |
| 641 | <tt>struct</tt>/<tt>union</tt> types. All other accesses defer | 641 | <tt>struct</tt>/<tt>union</tt> types. All other accesses defer |
| 642 | to the corresponding metamethods or index tables (if any). | 642 | to the corresponding metamethods or index tables (if any). |
| 643 | </p> | 643 | </p> |
| @@ -650,7 +650,7 @@ certain optimizations. | |||
| 650 | <p> | 650 | <p> |
| 651 | As a consequence, the <em>elements</em> of complex numbers and | 651 | As a consequence, the <em>elements</em> of complex numbers and |
| 652 | vectors are immutable. But the elements of an aggregate holding these | 652 | vectors are immutable. But the elements of an aggregate holding these |
| 653 | types <em>may</em> be modified of course. I.e. you cannot assign to | 653 | types <em>may</em> be modified, of course. I.e. you cannot assign to |
| 654 | <tt>foo.c.im</tt>, but you can assign a (newly created) complex number | 654 | <tt>foo.c.im</tt>, but you can assign a (newly created) complex number |
| 655 | to <tt>foo.c</tt>. | 655 | to <tt>foo.c</tt>. |
| 656 | </p> | 656 | </p> |
| @@ -669,8 +669,8 @@ through unions is explicitly detected and allowed. | |||
| 669 | to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is | 669 | to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is |
| 670 | defined. The <tt>__new</tt> metamethod is called with the ctype object | 670 | defined. The <tt>__new</tt> metamethod is called with the ctype object |
| 671 | plus any other arguments passed to the constructor. Note that you have to | 671 | plus any other arguments passed to the constructor. Note that you have to |
| 672 | use <tt>ffi.new</tt> inside of it, since calling <tt>ct(...)</tt> would | 672 | use <tt>ffi.new</tt> inside the metamethod, since calling <tt>ct(...)</tt> |
| 673 | cause infinite recursion.</li> | 673 | would cause infinite recursion.</li> |
| 674 | 674 | ||
| 675 | <li><b>C function call</b>: a cdata function or cdata function | 675 | <li><b>C function call</b>: a cdata function or cdata function |
| 676 | pointer can be called. The passed arguments are | 676 | pointer can be called. The passed arguments are |
| @@ -681,7 +681,7 @@ variable argument part of vararg C function use | |||
| 681 | C function is called and the return value (if any) is | 681 | C function is called and the return value (if any) is |
| 682 | <a href="#convert_tolua">converted to a Lua object</a>.<br> | 682 | <a href="#convert_tolua">converted to a Lua object</a>.<br> |
| 683 | On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically | 683 | On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically |
| 684 | detected and a function declared as <tt>__cdecl</tt> (the default) is | 684 | detected, and a function declared as <tt>__cdecl</tt> (the default) is |
| 685 | silently fixed up after the first call.</li> | 685 | silently fixed up after the first call.</li> |
| 686 | 686 | ||
| 687 | </ul> | 687 | </ul> |
| @@ -691,7 +691,7 @@ silently fixed up after the first call.</li> | |||
| 691 | 691 | ||
| 692 | <li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata | 692 | <li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata |
| 693 | number or a Lua number can be added or subtracted. The number must be | 693 | number or a Lua number can be added or subtracted. The number must be |
| 694 | on the right hand side for a subtraction. The result is a pointer of | 694 | on the right-hand side for a subtraction. The result is a pointer of |
| 695 | the same type with an address plus or minus the number value | 695 | the same type with an address plus or minus the number value |
| 696 | multiplied by the element size in bytes. An error is raised if the | 696 | multiplied by the element size in bytes. An error is raised if the |
| 697 | element size is undefined.</li> | 697 | element size is undefined.</li> |
| @@ -706,7 +706,7 @@ operators (<tt>+ - * / % ^</tt> and unary | |||
| 706 | minus) can be applied to two cdata numbers, or a cdata number and a | 706 | minus) can be applied to two cdata numbers, or a cdata number and a |
| 707 | Lua number. If one of them is an <tt>uint64_t</tt>, the other side is | 707 | Lua number. If one of them is an <tt>uint64_t</tt>, the other side is |
| 708 | converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation | 708 | converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation |
| 709 | is performed. Otherwise both sides are converted to an | 709 | is performed. Otherwise, both sides are converted to an |
| 710 | <tt>int64_t</tt> and a signed arithmetic operation is performed. The | 710 | <tt>int64_t</tt> and a signed arithmetic operation is performed. The |
| 711 | result is a boxed 64 bit cdata object.<br> | 711 | result is a boxed 64 bit cdata object.<br> |
| 712 | 712 | ||
| @@ -737,7 +737,7 @@ which is compatible with any other pointer type.</li> | |||
| 737 | <li><b>64 bit integer comparison</b>: two cdata numbers, or a | 737 | <li><b>64 bit integer comparison</b>: two cdata numbers, or a |
| 738 | cdata number and a Lua number can be compared with each other. If one | 738 | cdata number and a Lua number can be compared with each other. If one |
| 739 | of them is an <tt>uint64_t</tt>, the other side is converted to an | 739 | of them is an <tt>uint64_t</tt>, the other side is converted to an |
| 740 | <tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise | 740 | <tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise, |
| 741 | both sides are converted to an <tt>int64_t</tt> and a signed | 741 | both sides are converted to an <tt>int64_t</tt> and a signed |
| 742 | comparison is performed.<br> | 742 | comparison is performed.<br> |
| 743 | 743 | ||
| @@ -762,9 +762,9 @@ keys!</b> | |||
| 762 | A cdata object is treated like any other garbage-collected object and | 762 | A cdata object is treated like any other garbage-collected object and |
| 763 | is hashed and compared by its address for table indexing. Since | 763 | is hashed and compared by its address for table indexing. Since |
| 764 | there's no interning for cdata value types, the same value may be | 764 | there's no interning for cdata value types, the same value may be |
| 765 | boxed in different cdata objects with different addresses. Thus | 765 | boxed in different cdata objects with different addresses. Thus, |
| 766 | <tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to | 766 | <tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to |
| 767 | the same hash slot and they certainly <b>do not</b> point to the same | 767 | the same hash slot, and they certainly <b>do not</b> point to the same |
| 768 | hash slot as <tt>t[2]</tt>. | 768 | hash slot as <tt>t[2]</tt>. |
| 769 | </p> | 769 | </p> |
| 770 | <p> | 770 | <p> |
| @@ -786,7 +786,7 @@ the resulting Lua number as a key when indexing tables.<br> | |||
| 786 | One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to | 786 | One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to |
| 787 | the same slot as <tt>t[2]</tt>.</li> | 787 | the same slot as <tt>t[2]</tt>.</li> |
| 788 | 788 | ||
| 789 | <li>Otherwise use either <tt>tostring()</tt> on 64 bit integers | 789 | <li>Otherwise, use either <tt>tostring()</tt> on 64 bit integers |
| 790 | or complex numbers or combine multiple fields of a cdata aggregate to | 790 | or complex numbers or combine multiple fields of a cdata aggregate to |
| 791 | a Lua string (e.g. with | 791 | a Lua string (e.g. with |
| 792 | <a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then | 792 | <a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then |
| @@ -794,7 +794,7 @@ use the resulting Lua string as a key when indexing tables.</li> | |||
| 794 | 794 | ||
| 795 | <li>Create your own specialized hash table implementation using the | 795 | <li>Create your own specialized hash table implementation using the |
| 796 | C types provided by the FFI library, just like you would in | 796 | C types provided by the FFI library, just like you would in |
| 797 | C code. Ultimately this may give much better performance than the | 797 | C code. Ultimately, this may give much better performance than the |
| 798 | other alternatives or what a generic by-value hash table could | 798 | other alternatives or what a generic by-value hash table could |
| 799 | possibly provide.</li> | 799 | possibly provide.</li> |
| 800 | 800 | ||
| @@ -860,7 +860,7 @@ garbage collector will automatically free the memory used by it (at | |||
| 860 | the end of the next GC cycle). | 860 | the end of the next GC cycle). |
| 861 | </p> | 861 | </p> |
| 862 | <p> | 862 | <p> |
| 863 | Please note that pointers themselves are cdata objects, however they | 863 | Please note, that pointers themselves are cdata objects, however they |
| 864 | are <b>not</b> followed by the garbage collector. So e.g. if you | 864 | are <b>not</b> followed by the garbage collector. So e.g. if you |
| 865 | assign a cdata array to a pointer, you must keep the cdata object | 865 | assign a cdata array to a pointer, you must keep the cdata object |
| 866 | holding the array alive as long as the pointer is still in use: | 866 | holding the array alive as long as the pointer is still in use: |
| @@ -909,18 +909,18 @@ of the function pointer and the Lua function object (closure). | |||
| 909 | </p> | 909 | </p> |
| 910 | <p> | 910 | <p> |
| 911 | This can happen implicitly due to the usual conversions, e.g. when | 911 | This can happen implicitly due to the usual conversions, e.g. when |
| 912 | passing a Lua function to a function pointer argument. Or you can use | 912 | passing a Lua function to a function pointer argument. Or, you can use |
| 913 | <tt>ffi.cast()</tt> to explicitly cast a Lua function to a | 913 | <tt>ffi.cast()</tt> to explicitly cast a Lua function to a |
| 914 | C function pointer. | 914 | C function pointer. |
| 915 | </p> | 915 | </p> |
| 916 | <p> | 916 | <p> |
| 917 | Currently only certain C function types can be used as callback | 917 | Currently, only certain C function types can be used as callback |
| 918 | functions. Neither C vararg functions nor functions with | 918 | functions. Neither C vararg functions nor functions with |
| 919 | pass-by-value aggregate argument or result types are supported. There | 919 | pass-by-value aggregate argument or result types are supported. There |
| 920 | are no restrictions for the kind of Lua functions that can be called | 920 | are no restrictions on the kind of Lua functions that can be called |
| 921 | from the callback — no checks for the proper number of arguments | 921 | from the callback — no checks for the proper number of arguments |
| 922 | are made. The return value of the Lua function will be converted to the | 922 | are made. The return value of the Lua function will be converted to the |
| 923 | result type and an error will be thrown for invalid conversions. | 923 | result type, and an error will be thrown for invalid conversions. |
| 924 | </p> | 924 | </p> |
| 925 | <p> | 925 | <p> |
| 926 | It's allowed to throw errors across a callback invocation, but it's not | 926 | It's allowed to throw errors across a callback invocation, but it's not |
| @@ -981,7 +981,7 @@ convention cannot be automatically detected, unlike for | |||
| 981 | <tt>__stdcall</tt> calls <em>to</em> Windows functions. | 981 | <tt>__stdcall</tt> calls <em>to</em> Windows functions. |
| 982 | </p> | 982 | </p> |
| 983 | <p> | 983 | <p> |
| 984 | For some use cases it's necessary to free up the resources or to | 984 | For some use cases, it's necessary to free up the resources or to |
| 985 | dynamically redirect callbacks. Use an explicit cast to a | 985 | dynamically redirect callbacks. Use an explicit cast to a |
| 986 | C function pointer and keep the resulting cdata object. Then use | 986 | C function pointer and keep the resulting cdata object. Then use |
| 987 | the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a> | 987 | the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a> |
| @@ -1034,7 +1034,7 @@ GUI application, which waits for user input most of the time, anyway. | |||
| 1034 | </p> | 1034 | </p> |
| 1035 | <p> | 1035 | <p> |
| 1036 | For new designs <b>avoid push-style APIs</b>: a C function repeatedly | 1036 | For new designs <b>avoid push-style APIs</b>: a C function repeatedly |
| 1037 | calling a callback for each result. Instead <b>use pull-style APIs</b>: | 1037 | calling a callback for each result. Instead, <b>use pull-style APIs</b>: |
| 1038 | call a C function repeatedly to get a new result. Calls from Lua | 1038 | call a C function repeatedly to get a new result. Calls from Lua |
| 1039 | to C via the FFI are much faster than the other way round. Most well-designed | 1039 | to C via the FFI are much faster than the other way round. Most well-designed |
| 1040 | libraries already use pull-style APIs (read/write, get/put). | 1040 | libraries already use pull-style APIs (read/write, get/put). |
| @@ -1053,7 +1053,7 @@ function. | |||
| 1053 | </p> | 1053 | </p> |
| 1054 | <p> | 1054 | <p> |
| 1055 | Indexing a C library namespace object with a symbol name (a Lua | 1055 | Indexing a C library namespace object with a symbol name (a Lua |
| 1056 | string) automatically binds it to the library. First the symbol type | 1056 | string) automatically binds it to the library. First, the symbol type |
| 1057 | is resolved — it must have been declared with | 1057 | is resolved — it must have been declared with |
| 1058 | <a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the | 1058 | <a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the |
| 1059 | symbol address is resolved by searching for the symbol name in the | 1059 | symbol address is resolved by searching for the symbol name in the |
| @@ -1108,7 +1108,7 @@ Performance notice: the JIT compiler specializes to the identity of | |||
| 1108 | namespace objects and to the strings used to index it. This | 1108 | namespace objects and to the strings used to index it. This |
| 1109 | effectively turns function cdata objects into constants. It's not | 1109 | effectively turns function cdata objects into constants. It's not |
| 1110 | useful and actually counter-productive to explicitly cache these | 1110 | useful and actually counter-productive to explicitly cache these |
| 1111 | function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH it | 1111 | function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH, it |
| 1112 | <em>is</em> useful to cache the namespace itself, e.g. <tt>local C = | 1112 | <em>is</em> useful to cache the namespace itself, e.g. <tt>local C = |
| 1113 | ffi.C</tt>. | 1113 | ffi.C</tt>. |
| 1114 | </p> | 1114 | </p> |
| @@ -1133,14 +1133,14 @@ This behavior is inevitable, since the goal is to provide full | |||
| 1133 | interoperability with C code. Adding extra safety measures, like | 1133 | interoperability with C code. Adding extra safety measures, like |
| 1134 | bounds checks, would be futile. There's no way to detect | 1134 | bounds checks, would be futile. There's no way to detect |
| 1135 | misdeclarations of C functions, since shared libraries only | 1135 | misdeclarations of C functions, since shared libraries only |
| 1136 | provide symbol names, but no type information. Likewise there's no way | 1136 | provide symbol names, but no type information. Likewise, there's no way |
| 1137 | to infer the valid range of indexes for a returned pointer. | 1137 | to infer the valid range of indexes for a returned pointer. |
| 1138 | </p> | 1138 | </p> |
| 1139 | <p> | 1139 | <p> |
| 1140 | Again: the FFI library is a low-level library. This implies it needs | 1140 | Again: the FFI library is a low-level library. This implies it needs |
| 1141 | to be used with care, but it's flexibility and performance often | 1141 | to be used with care, but it's flexibility and performance often |
| 1142 | outweigh this concern. If you're a C or C++ developer, it'll be easy | 1142 | outweigh this concern. If you're a C or C++ developer, it'll be easy |
| 1143 | to apply your existing knowledge. OTOH writing code for the FFI | 1143 | to apply your existing knowledge. OTOH, writing code for the FFI |
| 1144 | library is not for the faint of heart and probably shouldn't be the | 1144 | library is not for the faint of heart and probably shouldn't be the |
| 1145 | first exercise for someone with little experience in Lua, C or C++. | 1145 | first exercise for someone with little experience in Lua, C or C++. |
| 1146 | </p> | 1146 | </p> |
| @@ -1168,7 +1168,7 @@ currently incomplete: | |||
| 1168 | <li>C declarations are not passed through a C pre-processor, | 1168 | <li>C declarations are not passed through a C pre-processor, |
| 1169 | yet.</li> | 1169 | yet.</li> |
| 1170 | <li>The C parser is able to evaluate most constant expressions | 1170 | <li>The C parser is able to evaluate most constant expressions |
| 1171 | commonly found in C header files. However it doesn't handle the | 1171 | commonly found in C header files. However, it doesn't handle the |
| 1172 | full range of C expression semantics and may fail for some | 1172 | full range of C expression semantics and may fail for some |
| 1173 | obscure constructs.</li> | 1173 | obscure constructs.</li> |
| 1174 | <li><tt>static const</tt> declarations only work for integer types | 1174 | <li><tt>static const</tt> declarations only work for integer types |
diff --git a/doc/ext_ffi_tutorial.html b/doc/ext_ffi_tutorial.html index c5e423b8..de6b6f5e 100644 --- a/doc/ext_ffi_tutorial.html +++ b/doc/ext_ffi_tutorial.html | |||
| @@ -81,7 +81,7 @@ of its functions: | |||
| 81 | local ffi = require("ffi") | 81 | local ffi = require("ffi") |
| 82 | </pre> | 82 | </pre> |
| 83 | <p> | 83 | <p> |
| 84 | Please note this doesn't define an <tt>ffi</tt> variable in the table | 84 | Please note, this doesn't define an <tt>ffi</tt> variable in the table |
| 85 | of globals — you really need to use the local variable. The | 85 | of globals — you really need to use the local variable. The |
| 86 | <tt>require</tt> function ensures the library is only loaded once. | 86 | <tt>require</tt> function ensures the library is only loaded once. |
| 87 | </p> | 87 | </p> |
| @@ -190,7 +190,7 @@ don't need to declare them as such. | |||
| 190 | <span class="mark">⑤</span> The <tt>poll()</tt> | 190 | <span class="mark">⑤</span> The <tt>poll()</tt> |
| 191 | function takes a couple more arguments we're not going to use. You can | 191 | function takes a couple more arguments we're not going to use. You can |
| 192 | simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt> | 192 | simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt> |
| 193 | for the <tt>nfds</tt> parameter. Please note that the | 193 | for the <tt>nfds</tt> parameter. Please note, that the |
| 194 | number <tt>0</tt> <em>does not convert to a pointer value</em>, | 194 | number <tt>0</tt> <em>does not convert to a pointer value</em>, |
| 195 | unlike in C++. You really have to pass pointers to pointer arguments | 195 | unlike in C++. You really have to pass pointers to pointer arguments |
| 196 | and numbers to number arguments. | 196 | and numbers to number arguments. |
| @@ -287,12 +287,12 @@ Here's the step-by-step explanation: | |||
| 287 | <p> | 287 | <p> |
| 288 | <span class="mark">①</span> This defines some of the | 288 | <span class="mark">①</span> This defines some of the |
| 289 | C functions provided by zlib. For the sake of this example, some | 289 | C functions provided by zlib. For the sake of this example, some |
| 290 | type indirections have been reduced and it uses the pre-defined | 290 | type indirections have been reduced and it uses the predefined |
| 291 | fixed-size integer types, while still adhering to the zlib API/ABI. | 291 | fixed-size integer types, while still adhering to the zlib API/ABI. |
| 292 | </p> | 292 | </p> |
| 293 | <p> | 293 | <p> |
| 294 | <span class="mark">②</span> This loads the zlib shared | 294 | <span class="mark">②</span> This loads the zlib shared |
| 295 | library. On POSIX systems it's named <tt>libz.so</tt> and usually | 295 | library. On POSIX systems, it's named <tt>libz.so</tt> and usually |
| 296 | comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any | 296 | comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any |
| 297 | missing standard prefixes/suffixes, we can simply load the | 297 | missing standard prefixes/suffixes, we can simply load the |
| 298 | <tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and | 298 | <tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and |
| @@ -320,7 +320,7 @@ actual length that was used. | |||
| 320 | <p> | 320 | <p> |
| 321 | In C you'd pass in the address of a local variable | 321 | In C you'd pass in the address of a local variable |
| 322 | (<tt>&buflen</tt>). But since there's no address-of operator in | 322 | (<tt>&buflen</tt>). But since there's no address-of operator in |
| 323 | Lua, we'll just pass in a one-element array. Conveniently it can be | 323 | Lua, we'll just pass in a one-element array. Conveniently, it can be |
| 324 | initialized with the maximum buffer size in one step. Calling the | 324 | initialized with the maximum buffer size in one step. Calling the |
| 325 | actual <tt>zlib.compress2</tt> function is then straightforward. | 325 | actual <tt>zlib.compress2</tt> function is then straightforward. |
| 326 | </p> | 326 | </p> |
| @@ -344,7 +344,7 @@ for garbage collection and string interning. | |||
| 344 | <span class="mark">⑥</span> The <tt>uncompress</tt> | 344 | <span class="mark">⑥</span> The <tt>uncompress</tt> |
| 345 | functions does the exact opposite of the <tt>compress</tt> function. | 345 | functions does the exact opposite of the <tt>compress</tt> function. |
| 346 | The compressed data doesn't include the size of the original string, | 346 | The compressed data doesn't include the size of the original string, |
| 347 | so this needs to be passed in. Otherwise no surprises here. | 347 | so this needs to be passed in. Otherwise, no surprises here. |
| 348 | </p> | 348 | </p> |
| 349 | <p> | 349 | <p> |
| 350 | <span class="mark">⑦</span> The code, that makes use | 350 | <span class="mark">⑦</span> The code, that makes use |
| @@ -378,7 +378,7 @@ Ok, so the <tt>ffi.*</tt> functions generally accept cdata objects | |||
| 378 | wherever you'd want to use a number. That's why we get a away with | 378 | wherever you'd want to use a number. That's why we get a away with |
| 379 | passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua | 379 | passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua |
| 380 | library functions or modules don't know how to deal with this. So for | 380 | library functions or modules don't know how to deal with this. So for |
| 381 | maximum portability one needs to use <tt>tonumber()</tt> on returned | 381 | maximum portability, one needs to use <tt>tonumber()</tt> on returned |
| 382 | <tt>long</tt> results before passing them on. Otherwise the | 382 | <tt>long</tt> results before passing them on. Otherwise the |
| 383 | application might work on some systems, but would fail in a POSIX/x64 | 383 | application might work on some systems, but would fail in a POSIX/x64 |
| 384 | environment. | 384 | environment. |
| @@ -450,7 +450,7 @@ the origin. | |||
| 450 | </p> | 450 | </p> |
| 451 | <p> | 451 | <p> |
| 452 | <span class="mark">④</span> If we run out of operators, we can | 452 | <span class="mark">④</span> If we run out of operators, we can |
| 453 | define named methods, too. Here the <tt>__index</tt> table defines an | 453 | define named methods, too. Here, the <tt>__index</tt> table defines an |
| 454 | <tt>area</tt> function. For custom indexing needs, one might want to | 454 | <tt>area</tt> function. For custom indexing needs, one might want to |
| 455 | define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead. | 455 | define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead. |
| 456 | </p> | 456 | </p> |
| @@ -464,13 +464,13 @@ be used e.g. to create an array of points. The metamethods automatically | |||
| 464 | apply to any and all uses of this type. | 464 | apply to any and all uses of this type. |
| 465 | </p> | 465 | </p> |
| 466 | <p> | 466 | <p> |
| 467 | Please note that the association with a metatable is permanent and | 467 | Please note, that the association with a metatable is permanent and |
| 468 | <b>the metatable must not be modified afterwards!</b> Ditto for the | 468 | <b>the metatable must not be modified afterwards!</b> Ditto for the |
| 469 | <tt>__index</tt> table. | 469 | <tt>__index</tt> table. |
| 470 | </p> | 470 | </p> |
| 471 | <p> | 471 | <p> |
| 472 | <span class="mark">⑥</span> Here are some simple usage examples | 472 | <span class="mark">⑥</span> Here are some simple usage examples |
| 473 | for the point type and their expected results. The pre-defined | 473 | for the point type and their expected results. The predefined |
| 474 | operations (such as <tt>a.x</tt>) can be freely mixed with the newly | 474 | operations (such as <tt>a.x</tt>) can be freely mixed with the newly |
| 475 | defined metamethods. Note that <tt>area</tt> is a method and must be | 475 | defined metamethods. Note that <tt>area</tt> is a method and must be |
| 476 | called with the Lua syntax for methods: <tt>a:area()</tt>, not | 476 | called with the Lua syntax for methods: <tt>a:area()</tt>, not |
| @@ -479,7 +479,7 @@ called with the Lua syntax for methods: <tt>a:area()</tt>, not | |||
| 479 | <p> | 479 | <p> |
| 480 | The C type metamethod mechanism is most useful when used in | 480 | The C type metamethod mechanism is most useful when used in |
| 481 | conjunction with C libraries that are written in an object-oriented | 481 | conjunction with C libraries that are written in an object-oriented |
| 482 | style. Creators return a pointer to a new instance and methods take an | 482 | style. Creators return a pointer to a new instance, and methods take an |
| 483 | instance pointer as the first argument. Sometimes you can just point | 483 | instance pointer as the first argument. Sometimes you can just point |
| 484 | <tt>__index</tt> to the library namespace and <tt>__gc</tt> to the | 484 | <tt>__index</tt> to the library namespace and <tt>__gc</tt> to the |
| 485 | destructor and you're done. But often enough you'll want to add | 485 | destructor and you're done. But often enough you'll want to add |
| @@ -565,7 +565,7 @@ end | |||
| 565 | </pre> | 565 | </pre> |
| 566 | <p> | 566 | <p> |
| 567 | This turns them into indirect calls and generates bigger and slower | 567 | This turns them into indirect calls and generates bigger and slower |
| 568 | machine code. Instead you'll want to cache the namespace itself and | 568 | machine code. Instead, you'll want to cache the namespace itself and |
| 569 | rely on the JIT compiler to eliminate the lookups: | 569 | rely on the JIT compiler to eliminate the lookups: |
| 570 | </p> | 570 | </p> |
| 571 | <pre class="code"> | 571 | <pre class="code"> |
diff --git a/doc/ext_jit.html b/doc/ext_jit.html index be1bdcf6..8f58a0c7 100644 --- a/doc/ext_jit.html +++ b/doc/ext_jit.html | |||
| @@ -150,7 +150,7 @@ Contains the target architecture name: | |||
| 150 | 150 | ||
| 151 | <h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2> | 151 | <h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2> |
| 152 | <p> | 152 | <p> |
| 153 | This sub-module provides the backend for the <tt>-O</tt> command line | 153 | This submodule provides the backend for the <tt>-O</tt> command line |
| 154 | option. | 154 | option. |
| 155 | </p> | 155 | </p> |
| 156 | <p> | 156 | <p> |
| @@ -170,7 +170,7 @@ which was one of the ways to enable optimization. | |||
| 170 | 170 | ||
| 171 | <h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2> | 171 | <h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2> |
| 172 | <p> | 172 | <p> |
| 173 | This sub-module holds functions to introspect the bytecode, generated | 173 | This submodule holds functions to introspect the bytecode, generated |
| 174 | traces, the IR and the generated machine code. The functionality | 174 | traces, the IR and the generated machine code. The functionality |
| 175 | provided by this module is still in flux and therefore undocumented. | 175 | provided by this module is still in flux and therefore undocumented. |
| 176 | </p> | 176 | </p> |
diff --git a/doc/extensions.html b/doc/extensions.html index fe4df6f7..3ed13804 100644 --- a/doc/extensions.html +++ b/doc/extensions.html | |||
| @@ -84,7 +84,7 @@ or LuaJIT. | |||
| 84 | </p> | 84 | </p> |
| 85 | <p> | 85 | <p> |
| 86 | LuaJIT extends the standard Lua VM with new functionality and adds | 86 | LuaJIT extends the standard Lua VM with new functionality and adds |
| 87 | several extension modules. Please note this page is only about | 87 | several extension modules. Please note, this page is only about |
| 88 | <em>functional</em> enhancements and not about performance enhancements, | 88 | <em>functional</em> enhancements and not about performance enhancements, |
| 89 | such as the optimized VM, the faster interpreter or the JIT compiler. | 89 | such as the optimized VM, the faster interpreter or the JIT compiler. |
| 90 | </p> | 90 | </p> |
| @@ -185,7 +185,7 @@ usage. See also the | |||
| 185 | </p> | 185 | </p> |
| 186 | <p> | 186 | <p> |
| 187 | The generated bytecode is portable and can be loaded on any architecture | 187 | The generated bytecode is portable and can be loaded on any architecture |
| 188 | that LuaJIT supports, independent of word size or endianess. However the | 188 | that LuaJIT supports, independent of word size or endianess. However, the |
| 189 | bytecode compatibility versions must match. Bytecode stays compatible | 189 | bytecode compatibility versions must match. Bytecode stays compatible |
| 190 | for dot releases (x.y.0 → x.y.1), but may change with major or | 190 | for dot releases (x.y.0 → x.y.1), but may change with major or |
| 191 | minor releases (2.0 → 2.1) or between any beta release. Foreign | 191 | minor releases (2.0 → 2.1) or between any beta release. Foreign |
| @@ -197,7 +197,7 @@ bytecode (e.g. from Lua 5.1) is incompatible and cannot be loaded. | |||
| 197 | LuaJIT uses a Tausworthe PRNG with period 2^223 to implement | 197 | LuaJIT uses a Tausworthe PRNG with period 2^223 to implement |
| 198 | <tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of | 198 | <tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of |
| 199 | the PRNG results is much superior compared to the standard Lua | 199 | the PRNG results is much superior compared to the standard Lua |
| 200 | implementation which uses the platform-specific ANSI rand(). | 200 | implementation, which uses the platform-specific ANSI rand(). |
| 201 | </p> | 201 | </p> |
| 202 | <p> | 202 | <p> |
| 203 | The PRNG generates the same sequences from the same seeds on all | 203 | The PRNG generates the same sequences from the same seeds on all |
| @@ -215,7 +215,7 @@ Important: Neither this nor any other PRNG based on the simplistic | |||
| 215 | <h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3> | 215 | <h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3> |
| 216 | <p> | 216 | <p> |
| 217 | The file I/O functions in the standard <tt>io.*</tt> library handle | 217 | The file I/O functions in the standard <tt>io.*</tt> library handle |
| 218 | 64 bit file offsets. In particular this means it's possible | 218 | 64 bit file offsets. In particular, this means it's possible |
| 219 | to open files larger than 2 Gigabytes and to reposition or obtain | 219 | to open files larger than 2 Gigabytes and to reposition or obtain |
| 220 | the current file position for offsets beyond 2 GB | 220 | the current file position for offsets beyond 2 GB |
| 221 | (<tt>fp:seek()</tt> method). | 221 | (<tt>fp:seek()</tt> method). |
diff --git a/doc/faq.html b/doc/faq.html index 36b2eafc..0b4b2df0 100644 --- a/doc/faq.html +++ b/doc/faq.html | |||
| @@ -116,7 +116,7 @@ Direct3D version 10 or higher do not show this behavior anymore. | |||
| 116 | Consider testing your application with older versions, too.<br> | 116 | Consider testing your application with older versions, too.<br> |
| 117 | 117 | ||
| 118 | Similarly, the Borland/Delphi runtime modifies the FPU control word and | 118 | Similarly, the Borland/Delphi runtime modifies the FPU control word and |
| 119 | enables FP exceptions. Of course this violates the Windows ABI, too. | 119 | enables FP exceptions. Of course, this violates the Windows ABI, too. |
| 120 | Please check the Delphi docs for the Set8087CW method.</dd> | 120 | Please check the Delphi docs for the Set8087CW method.</dd> |
| 121 | </dl> | 121 | </dl> |
| 122 | 122 | ||
| @@ -126,7 +126,7 @@ Please check the Delphi docs for the Set8087CW method.</dd> | |||
| 126 | ignored by compiled code. If your program is running in a tight loop | 126 | ignored by compiled code. If your program is running in a tight loop |
| 127 | and never falls back to the interpreter, the debug hook never runs and | 127 | and never falls back to the interpreter, the debug hook never runs and |
| 128 | can't throw the "interrupted!" error.<br> | 128 | can't throw the "interrupted!" error.<br> |
| 129 | You have to press Ctrl-C twice to get stop your program. That's similar | 129 | You have to press Ctrl-C twice to stop your program. That's similar |
| 130 | to when it's stuck running inside a C function under the Lua interpreter.</dd> | 130 | to when it's stuck running inside a C function under the Lua interpreter.</dd> |
| 131 | </dl> | 131 | </dl> |
| 132 | 132 | ||
| @@ -146,7 +146,7 @@ so it doesn't rely on the key order. Or sort the table keys, if you must.</dd> | |||
| 146 | <dl id="sandbox"> | 146 | <dl id="sandbox"> |
| 147 | <dt>Q: Can Lua code be safely sandboxed?</dt> | 147 | <dt>Q: Can Lua code be safely sandboxed?</dt> |
| 148 | <dd> | 148 | <dd> |
| 149 | Maybe for an extremly restricted subset of Lua and if you relentlessly | 149 | Maybe for an extremely restricted subset of Lua and if you relentlessly |
| 150 | scrutinize every single interface function you offer to the untrusted code.<br> | 150 | scrutinize every single interface function you offer to the untrusted code.<br> |
| 151 | 151 | ||
| 152 | Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks), | 152 | Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks), |
diff --git a/doc/install.html b/doc/install.html index 19fab1b8..fe89fc5c 100644 --- a/doc/install.html +++ b/doc/install.html | |||
| @@ -317,7 +317,7 @@ The recommended way to fetch the latest version is to do a pull from | |||
| 317 | the git repository. | 317 | the git repository. |
| 318 | </p> | 318 | </p> |
| 319 | <p> | 319 | <p> |
| 320 | Alternatively download the latest source package of LuaJIT (pick the .tar.gz). | 320 | Alternatively, download the latest source package of LuaJIT (pick the .tar.gz). |
| 321 | Move it to a directory of your choice, open a terminal window and change | 321 | Move it to a directory of your choice, open a terminal window and change |
| 322 | to this directory. Now unpack the archive and change to the newly created | 322 | to this directory. Now unpack the archive and change to the newly created |
| 323 | directory (replace XX.YY.ZZ with the version you downloaded): | 323 | directory (replace XX.YY.ZZ with the version you downloaded): |
| @@ -475,7 +475,7 @@ important to compile with the proper CPU or architecture settings. You | |||
| 475 | can specify these when building the toolchain yourself. Or add | 475 | can specify these when building the toolchain yourself. Or add |
| 476 | <tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For | 476 | <tt>-mcpu=...</tt> or <tt>-march=...</tt> to <tt>TARGET_CFLAGS</tt>. For |
| 477 | ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting, | 477 | ARM it's important to have the correct <tt>-mfloat-abi=...</tt> setting, |
| 478 | too. Otherwise LuaJIT may not run at the full performance of your target | 478 | too. Otherwise, LuaJIT may not run at the full performance of your target |
| 479 | CPU. | 479 | CPU. |
| 480 | </p> | 480 | </p> |
| 481 | <pre class="code"> | 481 | <pre class="code"> |
| @@ -619,7 +619,7 @@ allocator from your system (no support for this on 64 bit architectures).</ | |||
| 619 | of calling <tt>luaopen_base</tt> etc. directly.</li> | 619 | of calling <tt>luaopen_base</tt> etc. directly.</li> |
| 620 | <li>To change or extend the list of standard libraries to load, copy | 620 | <li>To change or extend the list of standard libraries to load, copy |
| 621 | <tt>src/lib_init.c</tt> to your project and modify it accordingly. | 621 | <tt>src/lib_init.c</tt> to your project and modify it accordingly. |
| 622 | Make sure the <tt>jit</tt> library is loaded or the JIT compiler | 622 | Make sure the <tt>jit</tt> library is loaded, or the JIT compiler |
| 623 | will not be activated.</li> | 623 | will not be activated.</li> |
| 624 | <li>The <tt>bit.*</tt> module for bitwise operations | 624 | <li>The <tt>bit.*</tt> module for bitwise operations |
| 625 | is already built-in. There's no need to statically link | 625 | is already built-in. There's no need to statically link |
| @@ -638,7 +638,7 @@ in unspeakable ways. | |||
| 638 | There should be absolutely no need to patch <tt>luaconf.h</tt> or any | 638 | There should be absolutely no need to patch <tt>luaconf.h</tt> or any |
| 639 | of the Makefiles. And please do not hand-pick files for your packages — | 639 | of the Makefiles. And please do not hand-pick files for your packages — |
| 640 | simply use whatever <tt>make install</tt> creates. There's a reason | 640 | simply use whatever <tt>make install</tt> creates. There's a reason |
| 641 | for all of the files <em>and</em> directories it creates. | 641 | for all the files <em>and</em> directories it creates. |
| 642 | </p> | 642 | </p> |
| 643 | <p> | 643 | <p> |
| 644 | The build system uses GNU make and auto-detects most settings based on | 644 | The build system uses GNU make and auto-detects most settings based on |
diff --git a/doc/running.html b/doc/running.html index 2ce02bc4..3f408141 100644 --- a/doc/running.html +++ b/doc/running.html | |||
| @@ -179,7 +179,7 @@ written in Lua. They are mainly used for debugging the JIT compiler | |||
| 179 | itself. For a description of their options and output format, please | 179 | itself. For a description of their options and output format, please |
| 180 | read the comment block at the start of their source. | 180 | read the comment block at the start of their source. |
| 181 | They can be found in the <tt>lib</tt> directory of the source | 181 | They can be found in the <tt>lib</tt> directory of the source |
| 182 | distribution or installed under the <tt>jit</tt> directory. By default | 182 | distribution or installed under the <tt>jit</tt> directory. By default, |
| 183 | this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX | 183 | this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX |
| 184 | systems (replace XX.YY.ZZ by the installed version). | 184 | systems (replace XX.YY.ZZ by the installed version). |
| 185 | </p> | 185 | </p> |
| @@ -211,7 +211,7 @@ to a specific value. | |||
| 211 | You can either use this option multiple times (like <tt>-Ocse | 211 | You can either use this option multiple times (like <tt>-Ocse |
| 212 | -O-dce -Ohotloop=10</tt>) or separate several settings with a comma | 212 | -O-dce -Ohotloop=10</tt>) or separate several settings with a comma |
| 213 | (like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from | 213 | (like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from |
| 214 | left to right and later settings override earlier ones. You can freely | 214 | left to right, and later settings override earlier ones. You can freely |
| 215 | mix the three forms, but note that setting an optimization level | 215 | mix the three forms, but note that setting an optimization level |
| 216 | overrides all earlier flags. | 216 | overrides all earlier flags. |
| 217 | </p> | 217 | </p> |
diff --git a/doc/status.html b/doc/status.html index c251d224..7ecedf3d 100644 --- a/doc/status.html +++ b/doc/status.html | |||
| @@ -79,7 +79,7 @@ Known incompatibilities and issues in LuaJIT 2.0: | |||
| 79 | <ul> | 79 | <ul> |
| 80 | <li> | 80 | <li> |
| 81 | There are some differences in <b>implementation-defined</b> behavior. | 81 | There are some differences in <b>implementation-defined</b> behavior. |
| 82 | These either have a good reason, are arbitrary design choices | 82 | These either have a good reason, are arbitrary design choices, |
| 83 | or are due to quirks in the VM. The latter cases may get fixed if a | 83 | or are due to quirks in the VM. The latter cases may get fixed if a |
| 84 | demonstrable need is shown. | 84 | demonstrable need is shown. |
| 85 | </li> | 85 | </li> |
| @@ -89,7 +89,7 @@ hooks for non-Lua functions) and shows slightly different behavior | |||
| 89 | in LuaJIT (no per-coroutine hooks, no tail call counting). | 89 | in LuaJIT (no per-coroutine hooks, no tail call counting). |
| 90 | </li> | 90 | </li> |
| 91 | <li> | 91 | <li> |
| 92 | Currently some <b>out-of-memory</b> errors from <b>on-trace code</b> are not | 92 | Currently, some <b>out-of-memory</b> errors from <b>on-trace code</b> are not |
| 93 | handled correctly. The error may fall through an on-trace | 93 | handled correctly. The error may fall through an on-trace |
| 94 | <tt>pcall</tt> or it may be passed on to the function set with | 94 | <tt>pcall</tt> or it may be passed on to the function set with |
| 95 | <tt>lua_atpanic</tt> on x64. | 95 | <tt>lua_atpanic</tt> on x64. |
