michael/mlua
michael
/
mlua
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
569 Commits 1 Branch 0 Tags 2.7 MiB
Commit Graph

21 Commits

Author SHA1 Message Date
Alex Orlenko 0a13a9631d Fix LuaJIT 2.1 libraries loading 2020-06-07 20:38:19 +01:00
Alex Orlenko 2fd6757f39 Add LuaJIT 2.0.5 stable support 2020-06-06 16:07:16 +01:00
Alex Orlenko 5a9a308790 Provide safe and unsafe Lua modes: 
- In safe mode Lua would not have ability to load C code via `require` or `package.loadlib`
- Unsafe mode allows everything.
 2020-05-12 02:14:48 +01:00
Alex Orlenko 539b569ff4 Add Lua 5.4 (rc2) support 2020-05-11 02:43:34 +01:00
Alex Orlenko 7b0e4b4280 Add Send capability to Lua 2020-05-11 02:43:34 +01:00
Alex Orlenko 47e8a80c1c v0.3.0-alpha.1 with async support 
Squashed commit of the async branch.
 2020-04-17 22:39:50 +01:00
Alex Orlenko 07fc4642ae Support vendored versions of Lua and LuaJIT 2020-01-25 20:47:31 +00:00
Alex Orlenko 5eec0ef56b Implement PartialEq trait for Value (and subtypes) 
Add equals() method to compare values optionally invoking __eq.
 2020-01-07 00:03:03 +00:00
Alex Orlenko fd17a01456 Add Lua 5.2 support 2019-11-30 00:58:41 +00:00
Alex Orlenko ae677b0918 Move lua 5.1 support under new "lua51" feature 2019-11-04 22:23:15 +00:00
Alex Orlenko 6f42a6cca9 Add LuaJIT support 2019-11-04 22:23:15 +00:00
Alex Orlenko c4fd7a9faf Lua 5.1 support 2019-10-17 17:05:42 +01:00
Alex Orlenko cb109f6e36 Rename to mlua 2019-10-01 16:11:12 +01:00
Alex Orlenko 54f4627195 Update tests (excl. compile-fail) 2019-09-29 13:03:32 +01:00
Alex Orlenko b23ee6a162 cargo fmt 2019-09-29 12:56:03 +01:00
kyren 65d8ad2f86 Allow non-utf8 Lua source in load / exec / eval 2018-10-01 06:00:21 -04:00
kyren 8810c36979 Add test for i128 Lua round-trip 2018-09-26 21:13:25 -04:00
kyren 58ce05ff9a Improve the situation with numerical conversion 
This is a somewhat involved change with two breaking API changes:

1) Lua::coerce_xxx methods now return Option (this is easier and faster than
dealing with Result)
2) rlua numeric conversions now allow more loss of precision
conversions (e.g. 1.5f32 to 1i32)

The logic for the first breaking change is that mostly the coerce methods are
probably used internally, and they make sense as low-level fallible casts and
are now used as such, and there's no reason to confuse things with a Result with
a large error type and force the user to match on the error which will hopefully
only be FromLuaConversionError anyway.

The logic for the second change is that it matches the behavior of
num_traits::cast, and is more consistent in that *some* loss of precision
conversions were previously allowed (e.g. f64 to f32).

The problem is that now, Lua::coerce_integer and Lua::unpack::<i64> have
different behavior when given, for example, the number 1.5.  I still think this
is the best option, though, because the Lua::coerce_xxx methods represent how
Lua works internally and the standard C API cast functions that Lua provides,
and the ToLua / FromLua code represents the most common form of fallible Rust
numeric conversion.

I could revert this change and turn `Lua::eval::<i64>("1.5", None)` back into an
error, but it seems inconsistent to allow f64 -> f32 loss of precision but not
f64 -> i64 loss of precision.
 2018-09-26 21:01:54 -04:00
kyren c3d0110722 Return rlua::Error on out of range numeric conversions using num_traits::cast 2018-09-24 22:14:50 -04:00
kyren 6a5ec6b387 cargo fmt 2018-09-24 22:13:42 -04:00
kyren b8da08187d Move integration tests into top-level tests directory 
other minor refactors
 2018-09-16 20:15:51 -04:00
Renamed from src/tests/mod.rs (Browse further)