2021-08-09 20:09:14 +00:00
|
|
|
DESCRIPTION
|
|
|
|
|
|
|
|
Lua is a language designed for embedded use in native applications. It
|
|
|
|
has an impossibly elegant C API and the Lua language itself feels more
|
|
|
|
like Python compared to alternatives like Tcl except it's a great deal
|
|
|
|
faster and doesn't have strong opinions about character encoding.
|
|
|
|
|
|
|
|
PROVENANCE
|
|
|
|
|
|
|
|
https://github.com/lua/lua/
|
|
|
|
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
commit 6443185167c77adcc8552a3fee7edab7895db1a9
|
2021-08-09 20:09:14 +00:00
|
|
|
Author: Roberto Ierusalimschy <roberto@inf.puc-rio.br>
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
Date: May 2, 2023 at 3:44 PM EDT
|
2021-08-09 20:09:14 +00:00
|
|
|
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
New release number (5.4.6)
|
2021-08-09 20:09:14 +00:00
|
|
|
|
|
|
|
luac.c needed to be sourced from:
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
https://www.lua.org/ftp/lua-5.4.6.tar.gz
|
2021-08-09 20:09:14 +00:00
|
|
|
|
|
|
|
LOCAL MODIFICATIONS
|
|
|
|
|
2022-04-16 22:08:00 +00:00
|
|
|
Lua now uses a bestline REPL with bash-style code completion.
|
|
|
|
|
2022-04-13 15:49:17 +00:00
|
|
|
Integer literals such as `033` will now be interpreted as octal.
|
|
|
|
|
2022-04-29 13:06:23 +00:00
|
|
|
Integer literals such as `0b10` will now be interpreted as binary.
|
|
|
|
|
2021-08-09 20:09:14 +00:00
|
|
|
The `\e` string literal escape sequence has been added, which is
|
|
|
|
equivalent to `\27` (the Lua version of `\033`) or the ASCII ESC
|
|
|
|
character. It may be used for teletypewriter control like having
|
|
|
|
bold text, which can be encoded elegantly as `\e[1mHELLO\e[0m`.
|
2022-04-16 22:08:00 +00:00
|
|
|
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
Added Python-like printf modulus operator for strings, e.g.:
|
|
|
|
`"Hello, %s!" % {"world"}`.
|
|
|
|
|
|
|
|
Added Python-like printf multiply operator for strings, e.g.:
|
|
|
|
`"Hello, world! " * 3`.
|
2022-04-24 16:59:22 +00:00
|
|
|
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
Added `unix` module that exposes the low-level System Five system
|
|
|
|
call interface, e.g.: `require("unix"); print(unix.getcwd())`.
|
2022-07-09 06:06:46 +00:00
|
|
|
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
Added luaL_traceback2() for function parameters in traceback.
|
2024-05-20 07:46:27 +00:00
|
|
|
|
|
|
|
Fixed a buffer overflow in os.tmpname
|
Bring Lua to 5.4.6. (#1214)
This essentially re-does the work of #875 on top of master.
This is what I did to check that Cosmo's Lua extensions still worked:
```
$ build/bootstrap/make MODE=aarch64 o/aarch64/third_party/lua/lua
$ ape o/aarch64/third_party/lua/lua
>: 10
10
>: 010
8
>: 0b10
2
>: string.byte("\e")
27
>: "Hello, %s" % {"world"}
Hello, world
>: "*" * 3
***
```
`luaL_traceback2` was used to show the stack trace with parameter
values; it's used in `LuaCallWithTrace`, which is used in Redbean to run
Lua code. You should be able to see the extended stack trace by running
something like this: `redbean -e "function a(b)c()end a(2)"` (with
"params" indicating the extended stack trace):
```
stack traceback:
[string "function a(b)c()end a(2)"]:1: in function 'a', params: b = 2;
[string "function a(b)c()end a(2)"]:1: in main chunk
```
@pkulchenko confirmed that I get the expected result with the updated
code.
This is what I did to check that Lua itself still worked:
```
$ cd third_party/lua/test/
$ ape ../../../o/aarch64/third_party/lua/lua all.lua
```
There's one test failure, in `files.lua`:
```
***** FILE 'files.lua'*****
testing i/o
../../../o/aarch64/third_party/lua/lua: files.lua:84: assertion failed!
stack traceback:
[C]: in function 'assert'
files.lua:84: in main chunk
(...tail calls...)
all.lua:195: in main chunk
[C]: in ?
.>>> closing state <<<
```
That isn't a result of these changes; the same test is failing in
master.
The failure is here:
```lua
if not _port then -- invalid seek
local status, msg, code = io.stdin:seek("set", 1000)
assert(not status and type(msg) == "string" and type(code) == "number")
end
```
The test expects a seek to offset 1,000 on stdin to fail — but it
doesn't. `status` ends up being the new offset rather than `nil`.
If I comment out that one test, the remaining tests succeed.
2024-06-16 00:13:08 +00:00
|
|
|
|
|
|
|
NOTES
|
|
|
|
|
|
|
|
If you'd like to update Cosmo's Lua to the latest version, here
|
|
|
|
are some things that might be helpful to know.
|
|
|
|
|
|
|
|
Cosmo's Lua adds ~20 or so files (e.g., `luacallwithtrace.c`,
|
|
|
|
`luaencodejsondata.c`, `luaencodeluadata.c`, etc.) to the
|
|
|
|
directory. In other words, a bunch of Cosmo's files don't
|
|
|
|
have any Lua counterpart.
|
|
|
|
|
|
|
|
Some of those files (e.g., `lunix.c`, `lunix.h`) implement
|
|
|
|
functionality that's available within the `lua` that Cosmo builds;
|
|
|
|
most, though, implement functionality that's (currently?) only
|
|
|
|
available within `redbean`. In other words, not everything can be
|
|
|
|
tested using `lua`; some things need to be tested using `redbean`.
|
|
|
|
|
|
|
|
Some of Lua's files were renamed. For example, `lua.c` was renamed
|
|
|
|
to `lua.main.c`, and `luac.c` (which is only available in Lua's
|
|
|
|
distributions, and not in Lua's Github repo) was renamed to
|
|
|
|
`luac.main.c`. `ljumptab.h` was renamed to `ljumptab.inc`, and
|
|
|
|
`lopnames.h` was renamed to `lopnames.inc`. In other words, you'll
|
|
|
|
need to take some kind of action in order to properly diff all of
|
|
|
|
Lua's files.
|
|
|
|
|
|
|
|
Lua's `.h` files had the comment headers that look like this
|
|
|
|
removed:
|
|
|
|
|
|
|
|
/*
|
|
|
|
** $Id: lua.h $
|
|
|
|
** Lua - A Scripting Language
|
|
|
|
** Lua.org, PUC-Rio, Brazil (http://www.lua.org)
|
|
|
|
** See Copyright Notice at the end of this file
|
|
|
|
*/
|
|
|
|
|
|
|
|
Lua's `.c` files *replaced* those comment headers with a Cosmo
|
|
|
|
emacs/vim header followed by a Lua copyright declaration.
|
|
|
|
|
|
|
|
The `.c` files also added a `__static_yoink("lua_notice");`
|
|
|
|
right after the `#include`s.
|
|
|
|
|
|
|
|
Some of Lua's tests have been modified to accommodate Cosmo's
|
|
|
|
changes. (And some of Lua's tests have been commented out
|
|
|
|
due to Cosmo's changes.)
|
|
|
|
|
|
|
|
Five of Lua's test files intentionally contain ISO-8859-1 (rather
|
|
|
|
than UTF-8) characters:
|
|
|
|
|
|
|
|
* test/db.lua
|
|
|
|
* test/files.lua
|
|
|
|
* test/pm.lua
|
|
|
|
* test/sort.lua
|
|
|
|
* test/strings.lua
|
|
|
|
|
|
|
|
If you edit those files as if they were UTF-8-encoded you'll
|
|
|
|
corrupt the ISO-8859-1 characters and cause certain tests to fail.
|
|
|
|
(Some of the tests count bytes, so you can't just fix the problem
|
|
|
|
by converting the files — you also have to change various expected
|
|
|
|
results.)
|
|
|
|
|
|
|
|
The modifications listed way up above are really only the
|
|
|
|
*user-visible* modifications. There are many that aren't
|
|
|
|
user-visible. For example, `_longjmp` was replaced with
|
|
|
|
`gclongjmp`, and `abort` was replaced, ultimately, with a
|
|
|
|
call to `_Exit`.
|
|
|
|
|
|
|
|
To update Cosmo's Lua, you'll need to diff the latest Lua against
|
|
|
|
the previous Lua, and Cosmo's Lua against the latest Lua. As you
|
|
|
|
do that, you'll be trying to figure out both what Lua changed
|
|
|
|
*and* what Cosmo changed; you'll be trying to add Lua's changes
|
|
|
|
without accidentally removing Cosmo's changes.
|
|
|
|
|
|
|
|
It's tricky!
|
|
|
|
|
|
|
|
We've started to try to make that process a bit easier by tagging
|
|
|
|
Cosmo's changes with `[jart]`. For example, one side of the diff
|
|
|
|
might (now) show:
|
|
|
|
|
|
|
|
#define LUAI_THROW(L,c) _longjmp((c)->b, 1)
|
|
|
|
|
|
|
|
while the other side might (now) show:
|
|
|
|
|
|
|
|
#define LUAI_THROW(L,c) gclongjmp((c)->b, 1) // [jart]
|
|
|
|
|
|
|
|
The presence of the `[jart]` tag makes it easy to see that the
|
|
|
|
Cosmo change was intentional.
|
|
|
|
|
|
|
|
Be aware that not all changes have been tagged!
|
|
|
|
|
|
|
|
There are *other* things we've done that are *also* meant to make
|
|
|
|
diffing easier — though the intention is less obvious.
|
|
|
|
|
|
|
|
For example, Cosmo moved the `enum` of opcodes from `ltm.h` to
|
|
|
|
`tms.h`. Originally nothing at all was left behind in `ltm.h`.
|
|
|
|
Because of that, you'd see an `enum` in Lua that seemed to be
|
|
|
|
missing in Cosmo's Lua — as though the `enum` had recently been
|
|
|
|
added to Lua, and now needed to be added to Cosmo! To make the
|
|
|
|
intention of Cosmo's change more obvious, we added a tombstone
|
|
|
|
of sorts to `ltm.h`:
|
|
|
|
|
|
|
|
/*
|
|
|
|
* WARNING: if you change the order of this enumeration,
|
|
|
|
* grep "ORDER TM" and "ORDER OP"
|
|
|
|
*/
|
|
|
|
// [jart] moved to tms.h
|
|
|
|
|
|
|
|
The comment just above the tag comes from Lua; it's the comment
|
|
|
|
above Lua's original `enum`. *The presence of the comment in both
|
|
|
|
Lua and Cosmo helps diff tools "resync" at that point.* That in
|
|
|
|
turn makes it easier to see Cosmo's change, and to see that it was
|
|
|
|
intentional.
|
|
|
|
|
|
|
|
The more things like that we do — the easier we can make it to
|
|
|
|
quickly and correctly read diffs — the easier we'll make it to
|
|
|
|
keep Cosmo's Lua in sync with the latest Lua.
|