There is no single obvious form for a set in lua, and it is not very difficult
to accept a table and convert the sequence values into a set.
Also rename some methods as per discussion.
When talking about "loading" Lua code, it usually means compiling a
chunk of code into a runnable Lua function, but without actually
running it. This makes that clear.
For this to work, both `T` and `E` need to implement `ToLua`. An `Ok(t)`
passes the contained `T`, while an `Err(e)` passes `nil` followed by the
contained `E`. This matches the common Lua idiom used by functions like
`io.open`.
Closes#3
partially for the selfish reason that my submodule setup does not deal well with
ureleased versions of cargo libs where the version number ends with -pre
Allow load to return values, allows reimplementing require() like functions
properly.
Make globals table explicit in Lua, remove Lua::get / Lua::set in favor of
Lua::globals. Allows obeying globals metatable, using other Table functions on
the globals table.
Also added "has" method as shorthand for checking whether a table entry is not
nil.
There should be drastically less ways to cause unprotected lua errors now, as
the LuaTable functions which were trivial to cause unprotected errors are now
protected. Unfortunately, they are protected in a pretty slow, terrible way
right now, but it at least works.
Also, set the atpanic function in lua to call a proper rust panic instead.
I know that Lua::to uses FromLua and Lua::from uses ToLua, but it only
makes sense that Lua::from(42) would return the LuaValue for 42, and
that Lua::to::<i64>(v) would convert the given lua value TO an integer.
The way it was just incredibly backwards.
All lua types should now be at least somewhat usable from rust, if
incompletely so. Any lua value should be readable in Rust as a
LuaValue, pop_value should never panic except in internal logic errors.