diff options
author | Mike Pall <mike> | 2022-06-23 09:10:43 +0200 |
---|---|---|
committer | Mike Pall <mike> | 2022-06-23 09:10:43 +0200 |
commit | 4c2441c16ce3c4e312aaefecc6d40c4fe21de97c (patch) | |
tree | 0ee5ad7a3246f9a620265de9c6998308cb44a09b /doc | |
parent | 0065cff7e0222c234b75a71e72b8883df5d000c2 (diff) | |
parent | 2e98c3d0644fc0c265844908f43b7e4526dd819c (diff) | |
download | luajit-4c2441c16ce3c4e312aaefecc6d40c4fe21de97c.tar.gz luajit-4c2441c16ce3c4e312aaefecc6d40c4fe21de97c.tar.bz2 luajit-4c2441c16ce3c4e312aaefecc6d40c4fe21de97c.zip |
Merge branch 'master' into v2.1
Diffstat (limited to 'doc')
-rw-r--r-- | doc/ext_buffer.html | 14 | ||||
-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/ext_profiler.html | 8 | ||||
-rw-r--r-- | doc/extensions.html | 10 | ||||
-rw-r--r-- | doc/faq.html | 6 | ||||
-rw-r--r-- | doc/install.html | 6 | ||||
-rw-r--r-- | doc/running.html | 4 | ||||
-rw-r--r-- | doc/status.html | 2 |
13 files changed, 82 insertions, 82 deletions
diff --git a/doc/ext_buffer.html b/doc/ext_buffer.html index 7b874f57..192110a7 100644 --- a/doc/ext_buffer.html +++ b/doc/ext_buffer.html | |||
@@ -86,7 +86,7 @@ overhead. In conjunction with the FFI library, they allow zero-copy | |||
86 | operations. | 86 | operations. |
87 | </p> | 87 | </p> |
88 | <p> | 88 | <p> |
89 | The string buffer libary also includes a high-performance | 89 | The string buffer library also includes a high-performance |
90 | <a href="serialize">serializer</a> for Lua objects. | 90 | <a href="serialize">serializer</a> for Lua objects. |
91 | </p> | 91 | </p> |
92 | 92 | ||
@@ -434,8 +434,8 @@ unsupported object types, circular references or deeply nested tables. | |||
434 | <h3 id="buffer_decode"><tt>obj = buffer.decode(str)<br> | 434 | <h3 id="buffer_decode"><tt>obj = buffer.decode(str)<br> |
435 | obj = buf:decode()</tt></h3> | 435 | obj = buf:decode()</tt></h3> |
436 | <p> | 436 | <p> |
437 | The stand-alone function de-serializes (decodes) the string | 437 | The stand-alone function deserializes (decodes) the string |
438 | <tt>str</tt>, the buffer method de-serializes one object from the | 438 | <tt>str</tt>, the buffer method deserializes one object from the |
439 | buffer. Both return a Lua object <tt>obj</tt>. | 439 | buffer. Both return a Lua object <tt>obj</tt>. |
440 | </p> | 440 | </p> |
441 | <p> | 441 | <p> |
@@ -449,7 +449,7 @@ data after decoding a single top-level object. The buffer method leaves | |||
449 | any left-over data in the buffer. | 449 | any left-over data in the buffer. |
450 | </p> | 450 | </p> |
451 | <p> | 451 | <p> |
452 | Attempting to de-serialize an FFI type will throw an error, if the FFI | 452 | Attempting to deserialize an FFI type will throw an error, if the FFI |
453 | library is not built-in or has not been loaded, yet. | 453 | library is not built-in or has not been loaded, yet. |
454 | </p> | 454 | </p> |
455 | 455 | ||
@@ -462,7 +462,7 @@ the following members (all optional): | |||
462 | <li> | 462 | <li> |
463 | <tt>dict</tt> is a Lua table holding a <b>dictionary of strings</b> that | 463 | <tt>dict</tt> is a Lua table holding a <b>dictionary of strings</b> that |
464 | commonly occur as table keys of objects you are serializing. These keys | 464 | commonly occur as table keys of objects you are serializing. These keys |
465 | are compactly encoded as indexes during serialization. A well chosen | 465 | are compactly encoded as indexes during serialization. A well-chosen |
466 | dictionary saves space and improves serialization performance. | 466 | dictionary saves space and improves serialization performance. |
467 | </li> | 467 | </li> |
468 | <li> | 468 | <li> |
@@ -473,7 +473,7 @@ for the table objects you are serializing. | |||
473 | <p> | 473 | <p> |
474 | <tt>dict</tt> needs to be an array of strings and <tt>metatable</tt> needs | 474 | <tt>dict</tt> needs to be an array of strings and <tt>metatable</tt> needs |
475 | to be an array of tables. Both starting at index 1 and without holes (no | 475 | to be an array of tables. Both starting at index 1 and without holes (no |
476 | <tt>nil</tt> inbetween). The tables are anchored in the buffer object and | 476 | <tt>nil</tt> in between). The tables are anchored in the buffer object and |
477 | internally modified into a two-way index (don't do this yourself, just pass | 477 | internally modified into a two-way index (don't do this yourself, just pass |
478 | a plain array). The tables must not be modified after they have been passed | 478 | a plain array). The tables must not be modified after they have been passed |
479 | to <tt>buffer.new()</tt>. | 479 | to <tt>buffer.new()</tt>. |
@@ -624,7 +624,7 @@ errors are best caught with an outer wrapper for larger parts of code. | |||
624 | There's not much one can do after that, anyway. | 624 | There's not much one can do after that, anyway. |
625 | </p> | 625 | </p> |
626 | <p> | 626 | <p> |
627 | OTOH you may want to catch some errors individually. Buffer methods need | 627 | OTOH, you may want to catch some errors individually. Buffer methods need |
628 | to receive the buffer object as the first argument. The Lua colon-syntax | 628 | to receive the buffer object as the first argument. The Lua colon-syntax |
629 | <tt>obj:method()</tt> does that implicitly. But to wrap a method with | 629 | <tt>obj:method()</tt> does that implicitly. But to wrap a method with |
630 | <tt>pcall()</tt>, the arguments need to be passed like this: | 630 | <tt>pcall()</tt>, the arguments need to be passed like this: |
diff --git a/doc/ext_c_api.html b/doc/ext_c_api.html index ae8dbcbb..21dc1310 100644 --- a/doc/ext_c_api.html +++ b/doc/ext_c_api.html | |||
@@ -107,7 +107,7 @@ Turn the whole JIT compiler on or off or flush the whole cache of compiled code. | |||
107 | This sets the mode for the function at the stack index <tt>idx</tt> or | 107 | This sets the mode for the function at the stack index <tt>idx</tt> or |
108 | the parent of the calling function (<tt>idx = 0</tt>). It either | 108 | the parent of the calling function (<tt>idx = 0</tt>). It either |
109 | enables JIT compilation for a function, disables it and flushes any | 109 | enables JIT compilation for a function, disables it and flushes any |
110 | already compiled code or only flushes already compiled code. This | 110 | already compiled code, or only flushes already compiled code. This |
111 | applies recursively to all sub-functions of the function with | 111 | applies recursively to all sub-functions of the function with |
112 | <tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with | 112 | <tt>LUAJIT_MODE_ALLFUNC</tt> or only to the sub-functions with |
113 | <tt>LUAJIT_MODE_ALLSUBFUNC</tt>. | 113 | <tt>LUAJIT_MODE_ALLSUBFUNC</tt>. |
@@ -126,7 +126,7 @@ traces which link to it. | |||
126 | This mode defines a wrapper function for calls to C functions. If | 126 | This mode defines a wrapper function for calls to C functions. If |
127 | called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt> | 127 | called with <tt>LUAJIT_MODE_ON</tt>, the stack index at <tt>idx</tt> |
128 | must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper | 128 | must be a <tt>lightuserdata</tt> object holding a pointer to the wrapper |
129 | function. From now on all C functions are called through the wrapper | 129 | function. From now on, all C functions are called through the wrapper |
130 | function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned | 130 | function. If called with <tt>LUAJIT_MODE_OFF</tt> this mode is turned |
131 | off and all C functions are directly called. | 131 | off and all C functions are directly called. |
132 | </p> | 132 | </p> |
diff --git a/doc/ext_ffi.html b/doc/ext_ffi.html index 85104ba5..b39ae314 100644 --- a/doc/ext_ffi.html +++ b/doc/ext_ffi.html | |||
@@ -157,7 +157,7 @@ call the binding function. Phew! | |||
157 | <h2 id="cdata">Motivating Example: Using C Data Structures</h2> | 157 | <h2 id="cdata">Motivating Example: Using C Data Structures</h2> |
158 | <p> | 158 | <p> |
159 | The FFI library allows you to create and access C data | 159 | The FFI library allows you to create and access C data |
160 | structures. Of course the main use for this is for interfacing with | 160 | structures. Of course, the main use for this is for interfacing with |
161 | C functions. But they can be used stand-alone, too. | 161 | C functions. But they can be used stand-alone, too. |
162 | </p> | 162 | </p> |
163 | <p> | 163 | <p> |
@@ -169,7 +169,7 @@ implemented with a big table holding lots of tiny tables. This imposes | |||
169 | both a substantial memory overhead as well as a performance overhead. | 169 | both a substantial memory overhead as well as a performance overhead. |
170 | </p> | 170 | </p> |
171 | <p> | 171 | <p> |
172 | Here's a sketch of a library that operates on color images plus a | 172 | Here's a sketch of a library that operates on color images, plus a |
173 | simple benchmark. First, the plain Lua version: | 173 | simple benchmark. First, the plain Lua version: |
174 | </p> | 174 | </p> |
175 | <pre class="code"> | 175 | <pre class="code"> |
@@ -184,7 +184,7 @@ local function image_ramp_green(n) | |||
184 | return img | 184 | return img |
185 | end | 185 | end |
186 | 186 | ||
187 | local function image_to_grey(img, n) | 187 | local function image_to_gray(img, n) |
188 | for i=1,n do | 188 | for i=1,n do |
189 | local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue) | 189 | local y = floor(0.3*img[i].red + 0.59*img[i].green + 0.11*img[i].blue) |
190 | img[i].red = y; img[i].green = y; img[i].blue = y | 190 | img[i].red = y; img[i].green = y; img[i].blue = y |
@@ -194,14 +194,14 @@ end | |||
194 | local N = 400*400 | 194 | local N = 400*400 |
195 | local img = image_ramp_green(N) | 195 | local img = image_ramp_green(N) |
196 | for i=1,1000 do | 196 | for i=1,1000 do |
197 | image_to_grey(img, N) | 197 | image_to_gray(img, N) |
198 | end | 198 | end |
199 | </pre> | 199 | </pre> |
200 | <p> | 200 | <p> |
201 | This creates a table with 160.000 pixels, each of which is a table | 201 | This creates a table with 160.000 pixels, each of which is a table |
202 | holding four number values in the range of 0-255. First an image with | 202 | holding four number values in the range of 0-255. First, an image with |
203 | a green ramp is created (1D for simplicity), then the image is | 203 | a green ramp is created (1D for simplicity), then the image is |
204 | converted to greyscale 1000 times. Yes, that's silly, but I was in | 204 | converted to grayscale 1000 times. Yes, that's silly, but I was in |
205 | need of a simple example ... | 205 | need of a simple example ... |
206 | </p> | 206 | </p> |
207 | <p> | 207 | <p> |
@@ -308,7 +308,7 @@ be more compact and faster. This is certainly true (by a factor of | |||
308 | ~1.7x). Switching to a struct-of-arrays would help, too. | 308 | ~1.7x). Switching to a struct-of-arrays would help, too. |
309 | </p> | 309 | </p> |
310 | <p style="font-size: 8pt;"> | 310 | <p style="font-size: 8pt;"> |
311 | However the resulting code would be less idiomatic and rather | 311 | However, the resulting code would be less idiomatic and rather |
312 | error-prone. And it still doesn't get even close to the performance of | 312 | error-prone. And it still doesn't get even close to the performance of |
313 | the FFI version of the code. Also, high-level data structures cannot | 313 | the FFI version of the code. Also, high-level data structures cannot |
314 | be easily passed to other C functions, especially I/O functions, | 314 | 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 0b0e31f6..b8da1c95 100644 --- a/doc/ext_ffi_api.html +++ b/doc/ext_ffi_api.html | |||
@@ -121,7 +121,7 @@ separated by semicolons. The trailing semicolon for a single | |||
121 | declaration may be omitted. | 121 | declaration may be omitted. |
122 | </p> | 122 | </p> |
123 | <p> | 123 | <p> |
124 | Please note that external symbols are only <em>declared</em>, but they | 124 | Please note, that external symbols are only <em>declared</em>, but they |
125 | are <em>not bound</em> to any specific address, yet. Binding is | 125 | are <em>not bound</em> to any specific address, yet. Binding is |
126 | achieved with C library namespaces (see below). | 126 | achieved with C library namespaces (see below). |
127 | </p> | 127 | </p> |
@@ -209,7 +209,7 @@ parse the cdecl only once and get its ctype with | |||
209 | <tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly. | 209 | <tt>ffi.typeof()</tt>. Then use the ctype as a constructor repeatedly. |
210 | </p> | 210 | </p> |
211 | <p style="font-size: 8pt;"> | 211 | <p style="font-size: 8pt;"> |
212 | Please note that an anonymous <tt>struct</tt> declaration implicitly | 212 | Please note, that an anonymous <tt>struct</tt> declaration implicitly |
213 | creates a new and distinguished ctype every time you use it for | 213 | creates a new and distinguished ctype every time you use it for |
214 | <tt>ffi.new()</tt>. This is probably <b>not</b> what you want, | 214 | <tt>ffi.new()</tt>. This is probably <b>not</b> what you want, |
215 | especially if you create more than one cdata object. Different anonymous | 215 | especially if you create more than one cdata object. Different anonymous |
@@ -256,12 +256,12 @@ afterwards. Neither the contents of the <tt>metatable</tt> nor the | |||
256 | contents of an <tt>__index</tt> table (if any) may be modified | 256 | contents of an <tt>__index</tt> table (if any) may be modified |
257 | afterwards. The associated metatable automatically applies to all uses | 257 | afterwards. The associated metatable automatically applies to all uses |
258 | of this type, no matter how the objects are created or where they | 258 | of this type, no matter how the objects are created or where they |
259 | originate from. Note that pre-defined operations on types have | 259 | originate from. Note that predefined operations on types have |
260 | precedence (e.g. declared field names cannot be overridden). | 260 | precedence (e.g. declared field names cannot be overridden). |
261 | </p> | 261 | </p> |
262 | <p> | 262 | <p> |
263 | All standard Lua metamethods are implemented. These are called directly, | 263 | All standard Lua metamethods are implemented. These are called directly, |
264 | without shortcuts and on any mix of types. For binary operations, the | 264 | without shortcuts, and on any mix of types. For binary operations, the |
265 | left operand is checked first for a valid ctype metamethod. The | 265 | left operand is checked first for a valid ctype metamethod. The |
266 | <tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt> | 266 | <tt>__gc</tt> metamethod only applies to <tt>struct</tt>/<tt>union</tt> |
267 | types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a> | 267 | types and performs an implicit <a href="#ffi_gc"><tt>ffi.gc()</tt></a> |
@@ -492,7 +492,7 @@ have some extra methods: | |||
492 | <p> | 492 | <p> |
493 | Free the resources associated with a callback. The associated Lua | 493 | Free the resources associated with a callback. The associated Lua |
494 | function is unanchored and may be garbage collected. The callback | 494 | function is unanchored and may be garbage collected. The callback |
495 | function pointer is no longer valid and must not be called anymore | 495 | function pointer is no longer valid and must not be called again |
496 | (it may be reused by a subsequently created callback). | 496 | (it may be reused by a subsequently created callback). |
497 | </p> | 497 | </p> |
498 | 498 | ||
diff --git a/doc/ext_ffi_semantics.html b/doc/ext_ffi_semantics.html index d515a142..22f7f17c 100644 --- a/doc/ext_ffi_semantics.html +++ b/doc/ext_ffi_semantics.html | |||
@@ -88,7 +88,7 @@ footprint. It's used by the <a href="ext_ffi_api.html">ffi.* library | |||
88 | functions</a> to declare C types or external symbols. | 88 | functions</a> to declare C types or external symbols. |
89 | </p> | 89 | </p> |
90 | <p> | 90 | <p> |
91 | It's only purpose is to parse C declarations, as found e.g. in | 91 | Its only purpose is to parse C declarations, as found e.g. in |
92 | C header files. Although it does evaluate constant expressions, | 92 | C header files. Although it does evaluate constant expressions, |
93 | it's <em>not</em> a C compiler. The body of <tt>inline</tt> | 93 | it's <em>not</em> a C compiler. The body of <tt>inline</tt> |
94 | C function definitions is simply ignored. | 94 | C function definitions is simply ignored. |
@@ -165,7 +165,7 @@ function declarations.</li> | |||
165 | 165 | ||
166 | </ul> | 166 | </ul> |
167 | <p> | 167 | <p> |
168 | The following C types are pre-defined by the C parser (like | 168 | The following C types are predefined by the C parser (like |
169 | a <tt>typedef</tt>, except re-declarations will be ignored): | 169 | a <tt>typedef</tt>, except re-declarations will be ignored): |
170 | </p> | 170 | </p> |
171 | <ul> | 171 | <ul> |
@@ -583,9 +583,9 @@ ffi.new("struct nested", {x=1,y={2,3}}) --> x = 1, y.a = 2, y.b = 3 | |||
583 | 583 | ||
584 | <h2 id="cdata_ops">Operations on cdata Objects</h2> | 584 | <h2 id="cdata_ops">Operations on cdata Objects</h2> |
585 | <p> | 585 | <p> |
586 | All of the standard Lua operators can be applied to cdata objects or a | 586 | All standard Lua operators can be applied to cdata objects or a |
587 | mix of a cdata object and another Lua object. The following list shows | 587 | mix of a cdata object and another Lua object. The following list shows |
588 | the pre-defined operations. | 588 | the predefined operations. |
589 | </p> | 589 | </p> |
590 | <p> | 590 | <p> |
591 | Reference types are dereferenced <em>before</em> performing each of | 591 | Reference types are dereferenced <em>before</em> performing each of |
@@ -593,7 +593,7 @@ the operations below — the operation is applied to the | |||
593 | C type pointed to by the reference. | 593 | C type pointed to by the reference. |
594 | </p> | 594 | </p> |
595 | <p> | 595 | <p> |
596 | The pre-defined operations are always tried first before deferring to a | 596 | The predefined operations are always tried first before deferring to a |
597 | metamethod or index table (if any) for the corresponding ctype (except | 597 | metamethod or index table (if any) for the corresponding ctype (except |
598 | for <tt>__new</tt>). An error is raised if the metamethod lookup or | 598 | for <tt>__new</tt>). An error is raised if the metamethod lookup or |
599 | index table lookup fails. | 599 | index table lookup fails. |
@@ -643,7 +643,7 @@ assigning to an index of a vector raises an error.</li> | |||
643 | </ul> | 643 | </ul> |
644 | <p> | 644 | <p> |
645 | A ctype object can be indexed with a string key, too. The only | 645 | A ctype object can be indexed with a string key, too. The only |
646 | pre-defined operation is reading scoped constants of | 646 | predefined operation is reading scoped constants of |
647 | <tt>struct</tt>/<tt>union</tt> types. All other accesses defer | 647 | <tt>struct</tt>/<tt>union</tt> types. All other accesses defer |
648 | to the corresponding metamethods or index tables (if any). | 648 | to the corresponding metamethods or index tables (if any). |
649 | </p> | 649 | </p> |
@@ -656,7 +656,7 @@ certain optimizations. | |||
656 | <p> | 656 | <p> |
657 | As a consequence, the <em>elements</em> of complex numbers and | 657 | As a consequence, the <em>elements</em> of complex numbers and |
658 | vectors are immutable. But the elements of an aggregate holding these | 658 | vectors are immutable. But the elements of an aggregate holding these |
659 | types <em>may</em> be modified of course. I.e. you cannot assign to | 659 | types <em>may</em> be modified, of course. I.e. you cannot assign to |
660 | <tt>foo.c.im</tt>, but you can assign a (newly created) complex number | 660 | <tt>foo.c.im</tt>, but you can assign a (newly created) complex number |
661 | to <tt>foo.c</tt>. | 661 | to <tt>foo.c</tt>. |
662 | </p> | 662 | </p> |
@@ -675,8 +675,8 @@ through unions is explicitly detected and allowed. | |||
675 | to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is | 675 | to <tt>ffi.new(ct, ...)</tt>, unless a <tt>__new</tt> metamethod is |
676 | defined. The <tt>__new</tt> metamethod is called with the ctype object | 676 | defined. The <tt>__new</tt> metamethod is called with the ctype object |
677 | plus any other arguments passed to the constructor. Note that you have to | 677 | plus any other arguments passed to the constructor. Note that you have to |
678 | use <tt>ffi.new</tt> inside of it, since calling <tt>ct(...)</tt> would | 678 | use <tt>ffi.new</tt> inside the metamethod, since calling <tt>ct(...)</tt> |
679 | cause infinite recursion.</li> | 679 | would cause infinite recursion.</li> |
680 | 680 | ||
681 | <li><b>C function call</b>: a cdata function or cdata function | 681 | <li><b>C function call</b>: a cdata function or cdata function |
682 | pointer can be called. The passed arguments are | 682 | pointer can be called. The passed arguments are |
@@ -687,7 +687,7 @@ variable argument part of vararg C function use | |||
687 | C function is called and the return value (if any) is | 687 | C function is called and the return value (if any) is |
688 | <a href="#convert_tolua">converted to a Lua object</a>.<br> | 688 | <a href="#convert_tolua">converted to a Lua object</a>.<br> |
689 | On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically | 689 | On Windows/x86 systems, <tt>__stdcall</tt> functions are automatically |
690 | detected and a function declared as <tt>__cdecl</tt> (the default) is | 690 | detected, and a function declared as <tt>__cdecl</tt> (the default) is |
691 | silently fixed up after the first call.</li> | 691 | silently fixed up after the first call.</li> |
692 | 692 | ||
693 | </ul> | 693 | </ul> |
@@ -697,7 +697,7 @@ silently fixed up after the first call.</li> | |||
697 | 697 | ||
698 | <li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata | 698 | <li><b>Pointer arithmetic</b>: a cdata pointer/array and a cdata |
699 | number or a Lua number can be added or subtracted. The number must be | 699 | number or a Lua number can be added or subtracted. The number must be |
700 | on the right hand side for a subtraction. The result is a pointer of | 700 | on the right-hand side for a subtraction. The result is a pointer of |
701 | the same type with an address plus or minus the number value | 701 | the same type with an address plus or minus the number value |
702 | multiplied by the element size in bytes. An error is raised if the | 702 | multiplied by the element size in bytes. An error is raised if the |
703 | element size is undefined.</li> | 703 | element size is undefined.</li> |
@@ -712,7 +712,7 @@ operators (<tt>+ - * / % ^</tt> and unary | |||
712 | minus) can be applied to two cdata numbers, or a cdata number and a | 712 | minus) can be applied to two cdata numbers, or a cdata number and a |
713 | Lua number. If one of them is an <tt>uint64_t</tt>, the other side is | 713 | Lua number. If one of them is an <tt>uint64_t</tt>, the other side is |
714 | converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation | 714 | converted to an <tt>uint64_t</tt> and an unsigned arithmetic operation |
715 | is performed. Otherwise both sides are converted to an | 715 | is performed. Otherwise, both sides are converted to an |
716 | <tt>int64_t</tt> and a signed arithmetic operation is performed. The | 716 | <tt>int64_t</tt> and a signed arithmetic operation is performed. The |
717 | result is a boxed 64 bit cdata object.<br> | 717 | result is a boxed 64 bit cdata object.<br> |
718 | 718 | ||
@@ -759,7 +759,7 @@ which is compatible with any other pointer type.</li> | |||
759 | <li><b>64 bit integer comparison</b>: two cdata numbers, or a | 759 | <li><b>64 bit integer comparison</b>: two cdata numbers, or a |
760 | cdata number and a Lua number can be compared with each other. If one | 760 | cdata number and a Lua number can be compared with each other. If one |
761 | of them is an <tt>uint64_t</tt>, the other side is converted to an | 761 | of them is an <tt>uint64_t</tt>, the other side is converted to an |
762 | <tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise | 762 | <tt>uint64_t</tt> and an unsigned comparison is performed. Otherwise, |
763 | both sides are converted to an <tt>int64_t</tt> and a signed | 763 | both sides are converted to an <tt>int64_t</tt> and a signed |
764 | comparison is performed.<br> | 764 | comparison is performed.<br> |
765 | 765 | ||
@@ -784,9 +784,9 @@ keys!</b> | |||
784 | A cdata object is treated like any other garbage-collected object and | 784 | A cdata object is treated like any other garbage-collected object and |
785 | is hashed and compared by its address for table indexing. Since | 785 | is hashed and compared by its address for table indexing. Since |
786 | there's no interning for cdata value types, the same value may be | 786 | there's no interning for cdata value types, the same value may be |
787 | boxed in different cdata objects with different addresses. Thus | 787 | boxed in different cdata objects with different addresses. Thus, |
788 | <tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to | 788 | <tt>t[1LL+1LL]</tt> and <tt>t[2LL]</tt> usually <b>do not</b> point to |
789 | the same hash slot and they certainly <b>do not</b> point to the same | 789 | the same hash slot, and they certainly <b>do not</b> point to the same |
790 | hash slot as <tt>t[2]</tt>. | 790 | hash slot as <tt>t[2]</tt>. |
791 | </p> | 791 | </p> |
792 | <p> | 792 | <p> |
@@ -808,7 +808,7 @@ the resulting Lua number as a key when indexing tables.<br> | |||
808 | One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to | 808 | One obvious benefit: <tt>t[tonumber(2LL)]</tt> <b>does</b> point to |
809 | the same slot as <tt>t[2]</tt>.</li> | 809 | the same slot as <tt>t[2]</tt>.</li> |
810 | 810 | ||
811 | <li>Otherwise use either <tt>tostring()</tt> on 64 bit integers | 811 | <li>Otherwise, use either <tt>tostring()</tt> on 64 bit integers |
812 | or complex numbers or combine multiple fields of a cdata aggregate to | 812 | or complex numbers or combine multiple fields of a cdata aggregate to |
813 | a Lua string (e.g. with | 813 | a Lua string (e.g. with |
814 | <a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then | 814 | <a href="ext_ffi_api.html#ffi_string"><tt>ffi.string()</tt></a>). Then |
@@ -816,7 +816,7 @@ use the resulting Lua string as a key when indexing tables.</li> | |||
816 | 816 | ||
817 | <li>Create your own specialized hash table implementation using the | 817 | <li>Create your own specialized hash table implementation using the |
818 | C types provided by the FFI library, just like you would in | 818 | C types provided by the FFI library, just like you would in |
819 | C code. Ultimately this may give much better performance than the | 819 | C code. Ultimately, this may give much better performance than the |
820 | other alternatives or what a generic by-value hash table could | 820 | other alternatives or what a generic by-value hash table could |
821 | possibly provide.</li> | 821 | possibly provide.</li> |
822 | 822 | ||
@@ -882,7 +882,7 @@ garbage collector will automatically free the memory used by it (at | |||
882 | the end of the next GC cycle). | 882 | the end of the next GC cycle). |
883 | </p> | 883 | </p> |
884 | <p> | 884 | <p> |
885 | Please note that pointers themselves are cdata objects, however they | 885 | Please note, that pointers themselves are cdata objects, however they |
886 | are <b>not</b> followed by the garbage collector. So e.g. if you | 886 | are <b>not</b> followed by the garbage collector. So e.g. if you |
887 | assign a cdata array to a pointer, you must keep the cdata object | 887 | assign a cdata array to a pointer, you must keep the cdata object |
888 | holding the array alive as long as the pointer is still in use: | 888 | holding the array alive as long as the pointer is still in use: |
@@ -931,18 +931,18 @@ of the function pointer and the Lua function object (closure). | |||
931 | </p> | 931 | </p> |
932 | <p> | 932 | <p> |
933 | This can happen implicitly due to the usual conversions, e.g. when | 933 | This can happen implicitly due to the usual conversions, e.g. when |
934 | passing a Lua function to a function pointer argument. Or you can use | 934 | passing a Lua function to a function pointer argument. Or, you can use |
935 | <tt>ffi.cast()</tt> to explicitly cast a Lua function to a | 935 | <tt>ffi.cast()</tt> to explicitly cast a Lua function to a |
936 | C function pointer. | 936 | C function pointer. |
937 | </p> | 937 | </p> |
938 | <p> | 938 | <p> |
939 | Currently only certain C function types can be used as callback | 939 | Currently, only certain C function types can be used as callback |
940 | functions. Neither C vararg functions nor functions with | 940 | functions. Neither C vararg functions nor functions with |
941 | pass-by-value aggregate argument or result types are supported. There | 941 | pass-by-value aggregate argument or result types are supported. There |
942 | are no restrictions for the kind of Lua functions that can be called | 942 | are no restrictions on the kind of Lua functions that can be called |
943 | from the callback — no checks for the proper number of arguments | 943 | from the callback — no checks for the proper number of arguments |
944 | are made. The return value of the Lua function will be converted to the | 944 | are made. The return value of the Lua function will be converted to the |
945 | result type and an error will be thrown for invalid conversions. | 945 | result type, and an error will be thrown for invalid conversions. |
946 | </p> | 946 | </p> |
947 | <p> | 947 | <p> |
948 | It's allowed to throw errors across a callback invocation, but it's not | 948 | It's allowed to throw errors across a callback invocation, but it's not |
@@ -1003,7 +1003,7 @@ convention cannot be automatically detected, unlike for | |||
1003 | <tt>__stdcall</tt> calls <em>to</em> Windows functions. | 1003 | <tt>__stdcall</tt> calls <em>to</em> Windows functions. |
1004 | </p> | 1004 | </p> |
1005 | <p> | 1005 | <p> |
1006 | For some use cases it's necessary to free up the resources or to | 1006 | For some use cases, it's necessary to free up the resources or to |
1007 | dynamically redirect callbacks. Use an explicit cast to a | 1007 | dynamically redirect callbacks. Use an explicit cast to a |
1008 | C function pointer and keep the resulting cdata object. Then use | 1008 | C function pointer and keep the resulting cdata object. Then use |
1009 | the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a> | 1009 | the <a href="ext_ffi_api.html#callback_free"><tt>cb:free()</tt></a> |
@@ -1056,7 +1056,7 @@ GUI application, which waits for user input most of the time, anyway. | |||
1056 | </p> | 1056 | </p> |
1057 | <p> | 1057 | <p> |
1058 | For new designs <b>avoid push-style APIs</b>: a C function repeatedly | 1058 | For new designs <b>avoid push-style APIs</b>: a C function repeatedly |
1059 | calling a callback for each result. Instead <b>use pull-style APIs</b>: | 1059 | calling a callback for each result. Instead, <b>use pull-style APIs</b>: |
1060 | call a C function repeatedly to get a new result. Calls from Lua | 1060 | call a C function repeatedly to get a new result. Calls from Lua |
1061 | to C via the FFI are much faster than the other way round. Most well-designed | 1061 | to C via the FFI are much faster than the other way round. Most well-designed |
1062 | libraries already use pull-style APIs (read/write, get/put). | 1062 | libraries already use pull-style APIs (read/write, get/put). |
@@ -1075,7 +1075,7 @@ function. | |||
1075 | </p> | 1075 | </p> |
1076 | <p> | 1076 | <p> |
1077 | Indexing a C library namespace object with a symbol name (a Lua | 1077 | Indexing a C library namespace object with a symbol name (a Lua |
1078 | string) automatically binds it to the library. First the symbol type | 1078 | string) automatically binds it to the library. First, the symbol type |
1079 | is resolved — it must have been declared with | 1079 | is resolved — it must have been declared with |
1080 | <a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the | 1080 | <a href="ext_ffi_api.html#ffi_cdef"><tt>ffi.cdef</tt></a>. Then the |
1081 | symbol address is resolved by searching for the symbol name in the | 1081 | symbol address is resolved by searching for the symbol name in the |
@@ -1130,7 +1130,7 @@ Performance notice: the JIT compiler specializes to the identity of | |||
1130 | namespace objects and to the strings used to index it. This | 1130 | namespace objects and to the strings used to index it. This |
1131 | effectively turns function cdata objects into constants. It's not | 1131 | effectively turns function cdata objects into constants. It's not |
1132 | useful and actually counter-productive to explicitly cache these | 1132 | useful and actually counter-productive to explicitly cache these |
1133 | function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH it | 1133 | function objects, e.g. <tt>local strlen = ffi.C.strlen</tt>. OTOH, it |
1134 | <em>is</em> useful to cache the namespace itself, e.g. <tt>local C = | 1134 | <em>is</em> useful to cache the namespace itself, e.g. <tt>local C = |
1135 | ffi.C</tt>. | 1135 | ffi.C</tt>. |
1136 | </p> | 1136 | </p> |
@@ -1155,14 +1155,14 @@ This behavior is inevitable, since the goal is to provide full | |||
1155 | interoperability with C code. Adding extra safety measures, like | 1155 | interoperability with C code. Adding extra safety measures, like |
1156 | bounds checks, would be futile. There's no way to detect | 1156 | bounds checks, would be futile. There's no way to detect |
1157 | misdeclarations of C functions, since shared libraries only | 1157 | misdeclarations of C functions, since shared libraries only |
1158 | provide symbol names, but no type information. Likewise there's no way | 1158 | provide symbol names, but no type information. Likewise, there's no way |
1159 | to infer the valid range of indexes for a returned pointer. | 1159 | to infer the valid range of indexes for a returned pointer. |
1160 | </p> | 1160 | </p> |
1161 | <p> | 1161 | <p> |
1162 | Again: the FFI library is a low-level library. This implies it needs | 1162 | Again: the FFI library is a low-level library. This implies it needs |
1163 | to be used with care, but it's flexibility and performance often | 1163 | to be used with care, but it's flexibility and performance often |
1164 | outweigh this concern. If you're a C or C++ developer, it'll be easy | 1164 | outweigh this concern. If you're a C or C++ developer, it'll be easy |
1165 | to apply your existing knowledge. OTOH writing code for the FFI | 1165 | to apply your existing knowledge. OTOH, writing code for the FFI |
1166 | library is not for the faint of heart and probably shouldn't be the | 1166 | library is not for the faint of heart and probably shouldn't be the |
1167 | first exercise for someone with little experience in Lua, C or C++. | 1167 | first exercise for someone with little experience in Lua, C or C++. |
1168 | </p> | 1168 | </p> |
@@ -1190,7 +1190,7 @@ currently incomplete: | |||
1190 | <li>C declarations are not passed through a C pre-processor, | 1190 | <li>C declarations are not passed through a C pre-processor, |
1191 | yet.</li> | 1191 | yet.</li> |
1192 | <li>The C parser is able to evaluate most constant expressions | 1192 | <li>The C parser is able to evaluate most constant expressions |
1193 | commonly found in C header files. However it doesn't handle the | 1193 | commonly found in C header files. However, it doesn't handle the |
1194 | full range of C expression semantics and may fail for some | 1194 | full range of C expression semantics and may fail for some |
1195 | obscure constructs.</li> | 1195 | obscure constructs.</li> |
1196 | <li><tt>static const</tt> declarations only work for integer types | 1196 | <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 ff104f83..e0bf9040 100644 --- a/doc/ext_ffi_tutorial.html +++ b/doc/ext_ffi_tutorial.html | |||
@@ -85,7 +85,7 @@ of its functions: | |||
85 | local ffi = require("ffi") | 85 | local ffi = require("ffi") |
86 | </pre> | 86 | </pre> |
87 | <p> | 87 | <p> |
88 | Please note this doesn't define an <tt>ffi</tt> variable in the table | 88 | Please note, this doesn't define an <tt>ffi</tt> variable in the table |
89 | of globals — you really need to use the local variable. The | 89 | of globals — you really need to use the local variable. The |
90 | <tt>require</tt> function ensures the library is only loaded once. | 90 | <tt>require</tt> function ensures the library is only loaded once. |
91 | </p> | 91 | </p> |
@@ -194,7 +194,7 @@ don't need to declare them as such. | |||
194 | <span class="mark">⑤</span> The <tt>poll()</tt> | 194 | <span class="mark">⑤</span> The <tt>poll()</tt> |
195 | function takes a couple more arguments we're not going to use. You can | 195 | function takes a couple more arguments we're not going to use. You can |
196 | simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt> | 196 | simply use <tt>nil</tt> to pass a <tt>NULL</tt> pointer and <tt>0</tt> |
197 | for the <tt>nfds</tt> parameter. Please note that the | 197 | for the <tt>nfds</tt> parameter. Please note, that the |
198 | number <tt>0</tt> <em>does not convert to a pointer value</em>, | 198 | number <tt>0</tt> <em>does not convert to a pointer value</em>, |
199 | unlike in C++. You really have to pass pointers to pointer arguments | 199 | unlike in C++. You really have to pass pointers to pointer arguments |
200 | and numbers to number arguments. | 200 | and numbers to number arguments. |
@@ -291,12 +291,12 @@ Here's the step-by-step explanation: | |||
291 | <p> | 291 | <p> |
292 | <span class="mark">①</span> This defines some of the | 292 | <span class="mark">①</span> This defines some of the |
293 | C functions provided by zlib. For the sake of this example, some | 293 | C functions provided by zlib. For the sake of this example, some |
294 | type indirections have been reduced and it uses the pre-defined | 294 | type indirections have been reduced and it uses the predefined |
295 | fixed-size integer types, while still adhering to the zlib API/ABI. | 295 | fixed-size integer types, while still adhering to the zlib API/ABI. |
296 | </p> | 296 | </p> |
297 | <p> | 297 | <p> |
298 | <span class="mark">②</span> This loads the zlib shared | 298 | <span class="mark">②</span> This loads the zlib shared |
299 | library. On POSIX systems it's named <tt>libz.so</tt> and usually | 299 | library. On POSIX systems, it's named <tt>libz.so</tt> and usually |
300 | comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any | 300 | comes pre-installed. Since <tt>ffi.load()</tt> automatically adds any |
301 | missing standard prefixes/suffixes, we can simply load the | 301 | missing standard prefixes/suffixes, we can simply load the |
302 | <tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and | 302 | <tt>"z"</tt> library. On Windows it's named <tt>zlib1.dll</tt> and |
@@ -324,7 +324,7 @@ actual length that was used. | |||
324 | <p> | 324 | <p> |
325 | In C you'd pass in the address of a local variable | 325 | In C you'd pass in the address of a local variable |
326 | (<tt>&buflen</tt>). But since there's no address-of operator in | 326 | (<tt>&buflen</tt>). But since there's no address-of operator in |
327 | Lua, we'll just pass in a one-element array. Conveniently it can be | 327 | Lua, we'll just pass in a one-element array. Conveniently, it can be |
328 | initialized with the maximum buffer size in one step. Calling the | 328 | initialized with the maximum buffer size in one step. Calling the |
329 | actual <tt>zlib.compress2</tt> function is then straightforward. | 329 | actual <tt>zlib.compress2</tt> function is then straightforward. |
330 | </p> | 330 | </p> |
@@ -348,7 +348,7 @@ for garbage collection and string interning. | |||
348 | <span class="mark">⑥</span> The <tt>uncompress</tt> | 348 | <span class="mark">⑥</span> The <tt>uncompress</tt> |
349 | functions does the exact opposite of the <tt>compress</tt> function. | 349 | functions does the exact opposite of the <tt>compress</tt> function. |
350 | The compressed data doesn't include the size of the original string, | 350 | The compressed data doesn't include the size of the original string, |
351 | so this needs to be passed in. Otherwise no surprises here. | 351 | so this needs to be passed in. Otherwise, no surprises here. |
352 | </p> | 352 | </p> |
353 | <p> | 353 | <p> |
354 | <span class="mark">⑦</span> The code, that makes use | 354 | <span class="mark">⑦</span> The code, that makes use |
@@ -382,7 +382,7 @@ Ok, so the <tt>ffi.*</tt> functions generally accept cdata objects | |||
382 | wherever you'd want to use a number. That's why we get a away with | 382 | wherever you'd want to use a number. That's why we get a away with |
383 | passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua | 383 | passing <tt>n</tt> to <tt>ffi.string()</tt> above. But other Lua |
384 | library functions or modules don't know how to deal with this. So for | 384 | library functions or modules don't know how to deal with this. So for |
385 | maximum portability one needs to use <tt>tonumber()</tt> on returned | 385 | maximum portability, one needs to use <tt>tonumber()</tt> on returned |
386 | <tt>long</tt> results before passing them on. Otherwise the | 386 | <tt>long</tt> results before passing them on. Otherwise the |
387 | application might work on some systems, but would fail in a POSIX/x64 | 387 | application might work on some systems, but would fail in a POSIX/x64 |
388 | environment. | 388 | environment. |
@@ -454,7 +454,7 @@ the origin. | |||
454 | </p> | 454 | </p> |
455 | <p> | 455 | <p> |
456 | <span class="mark">④</span> If we run out of operators, we can | 456 | <span class="mark">④</span> If we run out of operators, we can |
457 | define named methods, too. Here the <tt>__index</tt> table defines an | 457 | define named methods, too. Here, the <tt>__index</tt> table defines an |
458 | <tt>area</tt> function. For custom indexing needs, one might want to | 458 | <tt>area</tt> function. For custom indexing needs, one might want to |
459 | define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead. | 459 | define <tt>__index</tt> and <tt>__newindex</tt> <em>functions</em> instead. |
460 | </p> | 460 | </p> |
@@ -468,13 +468,13 @@ be used e.g. to create an array of points. The metamethods automatically | |||
468 | apply to any and all uses of this type. | 468 | apply to any and all uses of this type. |
469 | </p> | 469 | </p> |
470 | <p> | 470 | <p> |
471 | Please note that the association with a metatable is permanent and | 471 | Please note, that the association with a metatable is permanent and |
472 | <b>the metatable must not be modified afterwards!</b> Ditto for the | 472 | <b>the metatable must not be modified afterwards!</b> Ditto for the |
473 | <tt>__index</tt> table. | 473 | <tt>__index</tt> table. |
474 | </p> | 474 | </p> |
475 | <p> | 475 | <p> |
476 | <span class="mark">⑥</span> Here are some simple usage examples | 476 | <span class="mark">⑥</span> Here are some simple usage examples |
477 | for the point type and their expected results. The pre-defined | 477 | for the point type and their expected results. The predefined |
478 | operations (such as <tt>a.x</tt>) can be freely mixed with the newly | 478 | operations (such as <tt>a.x</tt>) can be freely mixed with the newly |
479 | defined metamethods. Note that <tt>area</tt> is a method and must be | 479 | defined metamethods. Note that <tt>area</tt> is a method and must be |
480 | called with the Lua syntax for methods: <tt>a:area()</tt>, not | 480 | called with the Lua syntax for methods: <tt>a:area()</tt>, not |
@@ -483,7 +483,7 @@ called with the Lua syntax for methods: <tt>a:area()</tt>, not | |||
483 | <p> | 483 | <p> |
484 | The C type metamethod mechanism is most useful when used in | 484 | The C type metamethod mechanism is most useful when used in |
485 | conjunction with C libraries that are written in an object-oriented | 485 | conjunction with C libraries that are written in an object-oriented |
486 | style. Creators return a pointer to a new instance and methods take an | 486 | style. Creators return a pointer to a new instance, and methods take an |
487 | instance pointer as the first argument. Sometimes you can just point | 487 | instance pointer as the first argument. Sometimes you can just point |
488 | <tt>__index</tt> to the library namespace and <tt>__gc</tt> to the | 488 | <tt>__index</tt> to the library namespace and <tt>__gc</tt> to the |
489 | destructor and you're done. But often enough you'll want to add | 489 | destructor and you're done. But often enough you'll want to add |
@@ -569,7 +569,7 @@ end | |||
569 | </pre> | 569 | </pre> |
570 | <p> | 570 | <p> |
571 | This turns them into indirect calls and generates bigger and slower | 571 | This turns them into indirect calls and generates bigger and slower |
572 | machine code. Instead you'll want to cache the namespace itself and | 572 | machine code. Instead, you'll want to cache the namespace itself and |
573 | rely on the JIT compiler to eliminate the lookups: | 573 | rely on the JIT compiler to eliminate the lookups: |
574 | </p> | 574 | </p> |
575 | <pre class="code"> | 575 | <pre class="code"> |
diff --git a/doc/ext_jit.html b/doc/ext_jit.html index 41ebdc92..b8a25967 100644 --- a/doc/ext_jit.html +++ b/doc/ext_jit.html | |||
@@ -154,7 +154,7 @@ Contains the target architecture name: | |||
154 | 154 | ||
155 | <h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2> | 155 | <h2 id="jit_opt"><tt>jit.opt.*</tt> — JIT compiler optimization control</h2> |
156 | <p> | 156 | <p> |
157 | This sub-module provides the backend for the <tt>-O</tt> command line | 157 | This submodule provides the backend for the <tt>-O</tt> command line |
158 | option. | 158 | option. |
159 | </p> | 159 | </p> |
160 | <p> | 160 | <p> |
@@ -174,7 +174,7 @@ which was one of the ways to enable optimization. | |||
174 | 174 | ||
175 | <h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2> | 175 | <h2 id="jit_util"><tt>jit.util.*</tt> — JIT compiler introspection</h2> |
176 | <p> | 176 | <p> |
177 | This sub-module holds functions to introspect the bytecode, generated | 177 | This submodule holds functions to introspect the bytecode, generated |
178 | traces, the IR and the generated machine code. The functionality | 178 | traces, the IR and the generated machine code. The functionality |
179 | provided by this module is still in flux and therefore undocumented. | 179 | provided by this module is still in flux and therefore undocumented. |
180 | </p> | 180 | </p> |
diff --git a/doc/ext_profiler.html b/doc/ext_profiler.html index 6059b4ea..b645a204 100644 --- a/doc/ext_profiler.html +++ b/doc/ext_profiler.html | |||
@@ -158,7 +158,7 @@ To see how much time is spent in different VM states or | |||
158 | Combinations of <tt>v/z</tt> with <tt>f/F/l</tt> produce two-level | 158 | Combinations of <tt>v/z</tt> with <tt>f/F/l</tt> produce two-level |
159 | views, e.g. <tt>-jp=vf</tt> or <tt>-jp=fv</tt>. This shows the time | 159 | views, e.g. <tt>-jp=vf</tt> or <tt>-jp=fv</tt>. This shows the time |
160 | spent in a VM state or zone vs. hotspots. This can be used to answer | 160 | spent in a VM state or zone vs. hotspots. This can be used to answer |
161 | questions like "Which time consuming functions are only interpreted?" or | 161 | questions like "Which time-consuming functions are only interpreted?" or |
162 | "What's the garbage collector overhead for a specific function?". | 162 | "What's the garbage collector overhead for a specific function?". |
163 | </p> | 163 | </p> |
164 | <p> | 164 | <p> |
@@ -217,7 +217,7 @@ local profile = require("jit.profile") | |||
217 | This module can be used to implement your own higher-level profiler. | 217 | This module can be used to implement your own higher-level profiler. |
218 | A typical profiling run starts the profiler, captures stack dumps in | 218 | A typical profiling run starts the profiler, captures stack dumps in |
219 | the profiler callback, adds them to a hash table to aggregate the number | 219 | the profiler callback, adds them to a hash table to aggregate the number |
220 | of samples, stops the profiler and then analyzes all of the captured | 220 | of samples, stops the profiler and then analyzes all captured |
221 | stack dumps. Other parameters can be sampled in the profiler callback, | 221 | stack dumps. Other parameters can be sampled in the profiler callback, |
222 | too. But it's important not to spend too much time in the callback, | 222 | too. But it's important not to spend too much time in the callback, |
223 | since this may skew the statistics. | 223 | since this may skew the statistics. |
@@ -271,9 +271,9 @@ returns a string with a stack dump for the <tt>thread</tt> (coroutine), | |||
271 | formatted according to the <tt>fmt</tt> argument: | 271 | formatted according to the <tt>fmt</tt> argument: |
272 | </p> | 272 | </p> |
273 | <ul> | 273 | <ul> |
274 | <li><tt>p</tt> — Preserve the full path for module names. Otherwise | 274 | <li><tt>p</tt> — Preserve the full path for module names. Otherwise, |
275 | only the file name is used.</li> | 275 | only the file name is used.</li> |
276 | <li><tt>f</tt> — Dump the function name if it can be derived. Otherwise | 276 | <li><tt>f</tt> — Dump the function name if it can be derived. Otherwise, |
277 | use module:line.</li> | 277 | use module:line.</li> |
278 | <li><tt>F</tt> — Ditto, but dump module:name.</li> | 278 | <li><tt>F</tt> — Ditto, but dump module:name.</li> |
279 | <li><tt>l</tt> — Dump module:line.</li> | 279 | <li><tt>l</tt> — Dump module:line.</li> |
diff --git a/doc/extensions.html b/doc/extensions.html index 6802d964..040fc588 100644 --- a/doc/extensions.html +++ b/doc/extensions.html | |||
@@ -88,7 +88,7 @@ or LuaJIT. | |||
88 | </p> | 88 | </p> |
89 | <p> | 89 | <p> |
90 | LuaJIT extends the standard Lua VM with new functionality and adds | 90 | LuaJIT extends the standard Lua VM with new functionality and adds |
91 | several extension modules. Please note this page is only about | 91 | several extension modules. Please note, this page is only about |
92 | <em>functional</em> enhancements and not about performance enhancements, | 92 | <em>functional</em> enhancements and not about performance enhancements, |
93 | such as the optimized VM, the faster interpreter or the JIT compiler. | 93 | such as the optimized VM, the faster interpreter or the JIT compiler. |
94 | </p> | 94 | </p> |
@@ -197,7 +197,7 @@ usage. See also the | |||
197 | </p> | 197 | </p> |
198 | <p> | 198 | <p> |
199 | The generated bytecode is portable and can be loaded on any architecture | 199 | The generated bytecode is portable and can be loaded on any architecture |
200 | that LuaJIT supports, independent of word size or endianess. However the | 200 | that LuaJIT supports, independent of word size or endianess. However, the |
201 | bytecode compatibility versions must match. Bytecode stays compatible | 201 | bytecode compatibility versions must match. Bytecode stays compatible |
202 | for dot releases (x.y.0 → x.y.1), but may change with major or | 202 | for dot releases (x.y.0 → x.y.1), but may change with major or |
203 | minor releases (2.0 → 2.1) or between any beta release. Foreign | 203 | minor releases (2.0 → 2.1) or between any beta release. Foreign |
@@ -229,7 +229,7 @@ avoids managing backlinks, saves an allocation and the overhead of | |||
229 | incremental array/hash part growth. | 229 | incremental array/hash part growth. |
230 | </p> | 230 | </p> |
231 | <p> | 231 | <p> |
232 | Please note this function is meant for very specific situations. In most | 232 | Please note, this function is meant for very specific situations. In most |
233 | cases it's better to replace the (usually single) link with a new table | 233 | cases it's better to replace the (usually single) link with a new table |
234 | and let the GC do its work. | 234 | and let the GC do its work. |
235 | </p> | 235 | </p> |
@@ -239,7 +239,7 @@ and let the GC do its work. | |||
239 | LuaJIT uses a Tausworthe PRNG with period 2^223 to implement | 239 | LuaJIT uses a Tausworthe PRNG with period 2^223 to implement |
240 | <tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of | 240 | <tt>math.random()</tt> and <tt>math.randomseed()</tt>. The quality of |
241 | the PRNG results is much superior compared to the standard Lua | 241 | the PRNG results is much superior compared to the standard Lua |
242 | implementation which uses the platform-specific ANSI rand(). | 242 | implementation, which uses the platform-specific ANSI rand(). |
243 | </p> | 243 | </p> |
244 | <p> | 244 | <p> |
245 | The PRNG generates the same sequences from the same seeds on all | 245 | The PRNG generates the same sequences from the same seeds on all |
@@ -257,7 +257,7 @@ Important: Neither this nor any other PRNG based on the simplistic | |||
257 | <h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3> | 257 | <h3 id="io"><tt>io.*</tt> functions handle 64 bit file offsets</h3> |
258 | <p> | 258 | <p> |
259 | The file I/O functions in the standard <tt>io.*</tt> library handle | 259 | The file I/O functions in the standard <tt>io.*</tt> library handle |
260 | 64 bit file offsets. In particular this means it's possible | 260 | 64 bit file offsets. In particular, this means it's possible |
261 | to open files larger than 2 Gigabytes and to reposition or obtain | 261 | to open files larger than 2 Gigabytes and to reposition or obtain |
262 | the current file position for offsets beyond 2 GB | 262 | the current file position for offsets beyond 2 GB |
263 | (<tt>fp:seek()</tt> method). | 263 | (<tt>fp:seek()</tt> method). |
diff --git a/doc/faq.html b/doc/faq.html index b826bd00..9effeb16 100644 --- a/doc/faq.html +++ b/doc/faq.html | |||
@@ -120,7 +120,7 @@ Direct3D version 10 or higher do not show this behavior anymore. | |||
120 | Consider testing your application with older versions, too.<br> | 120 | Consider testing your application with older versions, too.<br> |
121 | 121 | ||
122 | Similarly, the Borland/Delphi runtime modifies the FPU control word and | 122 | Similarly, the Borland/Delphi runtime modifies the FPU control word and |
123 | enables FP exceptions. Of course this violates the Windows ABI, too. | 123 | enables FP exceptions. Of course, this violates the Windows ABI, too. |
124 | Please check the Delphi docs for the Set8087CW method.</dd> | 124 | Please check the Delphi docs for the Set8087CW method.</dd> |
125 | </dl> | 125 | </dl> |
126 | 126 | ||
@@ -130,7 +130,7 @@ Please check the Delphi docs for the Set8087CW method.</dd> | |||
130 | ignored by compiled code. If your program is running in a tight loop | 130 | ignored by compiled code. If your program is running in a tight loop |
131 | and never falls back to the interpreter, the debug hook never runs and | 131 | and never falls back to the interpreter, the debug hook never runs and |
132 | can't throw the "interrupted!" error.<br> | 132 | can't throw the "interrupted!" error.<br> |
133 | You have to press Ctrl-C twice to get stop your program. That's similar | 133 | You have to press Ctrl-C twice to stop your program. That's similar |
134 | to when it's stuck running inside a C function under the Lua interpreter.</dd> | 134 | to when it's stuck running inside a C function under the Lua interpreter.</dd> |
135 | </dl> | 135 | </dl> |
136 | 136 | ||
@@ -150,7 +150,7 @@ so it doesn't rely on the key order. Or sort the table keys, if you must.</dd> | |||
150 | <dl id="sandbox"> | 150 | <dl id="sandbox"> |
151 | <dt>Q: Can Lua code be safely sandboxed?</dt> | 151 | <dt>Q: Can Lua code be safely sandboxed?</dt> |
152 | <dd> | 152 | <dd> |
153 | Maybe for an extremly restricted subset of Lua and if you relentlessly | 153 | Maybe for an extremely restricted subset of Lua and if you relentlessly |
154 | scrutinize every single interface function you offer to the untrusted code.<br> | 154 | scrutinize every single interface function you offer to the untrusted code.<br> |
155 | 155 | ||
156 | Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks), | 156 | Although Lua provides some sandboxing functionality (<tt>setfenv()</tt>, hooks), |
diff --git a/doc/install.html b/doc/install.html index c3b951e4..9fad31f4 100644 --- a/doc/install.html +++ b/doc/install.html | |||
@@ -328,7 +328,7 @@ The recommended way to fetch the latest version is to do a pull from | |||
328 | the git repository. | 328 | the git repository. |
329 | </p> | 329 | </p> |
330 | <p> | 330 | <p> |
331 | Alternatively download the latest source package of LuaJIT (pick the .tar.gz). | 331 | Alternatively, download the latest source package of LuaJIT (pick the .tar.gz). |
332 | Move it to a directory of your choice, open a terminal window and change | 332 | Move it to a directory of your choice, open a terminal window and change |
333 | to this directory. Now unpack the archive and change to the newly created | 333 | to this directory. Now unpack the archive and change to the newly created |
334 | directory (replace XX.YY.ZZ with the version you downloaded): | 334 | directory (replace XX.YY.ZZ with the version you downloaded): |
@@ -697,7 +697,7 @@ allocator from your system (no support for this on 64 bit architectures).</ | |||
697 | of calling <tt>luaopen_base</tt> etc. directly.</li> | 697 | of calling <tt>luaopen_base</tt> etc. directly.</li> |
698 | <li>To change or extend the list of standard libraries to load, copy | 698 | <li>To change or extend the list of standard libraries to load, copy |
699 | <tt>src/lib_init.c</tt> to your project and modify it accordingly. | 699 | <tt>src/lib_init.c</tt> to your project and modify it accordingly. |
700 | Make sure the <tt>jit</tt> library is loaded or the JIT compiler | 700 | Make sure the <tt>jit</tt> library is loaded, or the JIT compiler |
701 | will not be activated.</li> | 701 | will not be activated.</li> |
702 | <li>The <tt>bit.*</tt> module for bitwise operations | 702 | <li>The <tt>bit.*</tt> module for bitwise operations |
703 | is already built-in. There's no need to statically link | 703 | is already built-in. There's no need to statically link |
@@ -716,7 +716,7 @@ in unspeakable ways. | |||
716 | There should be absolutely no need to patch <tt>luaconf.h</tt> or any | 716 | There should be absolutely no need to patch <tt>luaconf.h</tt> or any |
717 | of the Makefiles. And please do not hand-pick files for your packages — | 717 | of the Makefiles. And please do not hand-pick files for your packages — |
718 | simply use whatever <tt>make install</tt> creates. There's a reason | 718 | simply use whatever <tt>make install</tt> creates. There's a reason |
719 | for all of the files <em>and</em> directories it creates. | 719 | for all the files <em>and</em> directories it creates. |
720 | </p> | 720 | </p> |
721 | <p> | 721 | <p> |
722 | The build system uses GNU make and auto-detects most settings based on | 722 | The build system uses GNU make and auto-detects most settings based on |
diff --git a/doc/running.html b/doc/running.html index e44f00b7..177e6357 100644 --- a/doc/running.html +++ b/doc/running.html | |||
@@ -184,7 +184,7 @@ written in Lua. They are mainly used for debugging the JIT compiler | |||
184 | itself. For a description of their options and output format, please | 184 | itself. For a description of their options and output format, please |
185 | read the comment block at the start of their source. | 185 | read the comment block at the start of their source. |
186 | They can be found in the <tt>lib</tt> directory of the source | 186 | They can be found in the <tt>lib</tt> directory of the source |
187 | distribution or installed under the <tt>jit</tt> directory. By default | 187 | distribution or installed under the <tt>jit</tt> directory. By default, |
188 | this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX | 188 | this is <tt>/usr/local/share/luajit-XX.YY.ZZ>/jit</tt> on POSIX |
189 | systems (replace XX.YY.ZZ by the installed version). | 189 | systems (replace XX.YY.ZZ by the installed version). |
190 | </p> | 190 | </p> |
@@ -216,7 +216,7 @@ to a specific value. | |||
216 | You can either use this option multiple times (like <tt>-Ocse | 216 | You can either use this option multiple times (like <tt>-Ocse |
217 | -O-dce -Ohotloop=10</tt>) or separate several settings with a comma | 217 | -O-dce -Ohotloop=10</tt>) or separate several settings with a comma |
218 | (like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from | 218 | (like <tt>-O+cse,-dce,hotloop=10</tt>). The settings are applied from |
219 | left to right and later settings override earlier ones. You can freely | 219 | left to right, and later settings override earlier ones. You can freely |
220 | mix the three forms, but note that setting an optimization level | 220 | mix the three forms, but note that setting an optimization level |
221 | overrides all earlier flags. | 221 | overrides all earlier flags. |
222 | </p> | 222 | </p> |
diff --git a/doc/status.html b/doc/status.html index fd6ca3a8..1c86c103 100644 --- a/doc/status.html +++ b/doc/status.html | |||
@@ -83,7 +83,7 @@ Known incompatibilities and issues in LuaJIT 2.0: | |||
83 | <ul> | 83 | <ul> |
84 | <li> | 84 | <li> |
85 | There are some differences in <b>implementation-defined</b> behavior. | 85 | There are some differences in <b>implementation-defined</b> behavior. |
86 | These either have a good reason, are arbitrary design choices | 86 | These either have a good reason, are arbitrary design choices, |
87 | or are due to quirks in the VM. The latter cases may get fixed if a | 87 | or are due to quirks in the VM. The latter cases may get fixed if a |
88 | demonstrable need is shown. | 88 | demonstrable need is shown. |
89 | </li> | 89 | </li> |