| Commit message (Collapse) | Author | Age |
|
|
|
| |
Had to move some export statements around, as there is now a circular dependency
|
| |
|
| |
|
|
|
|
|
|
| |
the unicode replacement character
Related to https://github.com/fengari-lua/fengari-interop/issues/30
|
|
|
|
|
| |
Takes similar approach as patch carried by debian.
https://anonscm.debian.org/cgit/pkg-lua/lua5.3.git/tree/debian/patches/0002-lua-modules-paths.patch?id=8dc227b2a85a160d2f1e92f9a21abd9e2e267735
|
| |
|
| |
|
|
|
|
| |
Closes #111
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
String manipulation functions now get exposed on 'fengari' object itself at top level
|
| |
|
|
|
|
|
|
|
|
|
| |
e.g. IE11
Instead iterate over string contents and manually build hash.
I have *not* tested this for performance.
An alternative option is to use Array.prototype.join.call
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
might not be available in older environments
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This removes requirement to set global.WEB before requiring in node
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Now fails on non-utf8 input.
Previously it would convert to equivalent unicode codepoints as bytes, which did not round-trip
|
| |
|
|
|
|
|
|
| |
utf8 dropped support for 5 and 6 byte sequences back in 2003
As we're converting from javascript strings (which are utf-16),
codepoints above U+10FFFF can't occur anyway
|
|
|
|
| |
Adds tests for to_luastring
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|