* New and complete character class support
* string.gsub implemented
* rawset implemented
* lua_call added (based on lua_pcall)
* lua_pop added
* newCall removed; luaGetTable and luaSetTable in LFunction updated to
use lua_call instead.
* StandardTest changed to avoid an ArrayIndexOutOfBoundsException
Unfortunately I discovered a problem where execute() will loop around too
many times and call exec() with a call frame that has already completed.
This might be due to the lack of the "tailcalls" field in our CallInfo class
that the C version maintains?
factor out negative index handling to separate function, posrelat (to
match C Lua). When converting numbers to strings, see if the double value
can be represented exactly as a long, and if so format the string as
an integer. With these changes the standard test case "strings.lua" runs
to line 104 (over half way through!), where it uses string.format.
(1) Fix string.char and string.byte (argument indexing was off by one)
(2) Implement string.find
(3) Change calls to charAt, which does array bounds checking, in the
pattern matcher with calls to luaByte, which does not.
(4) Replace use of recursion with while/continue in pattern matcher.
(1) getKeys() in LTable is now public. It provides a convenient interface
to access the table's elements from Java instead of Lua.
(2) LString.toInputStream produces an instance of InputStream from which
the string's bytes can be read.
on strings as the string package, so that string functions can be called
with self (:) syntax. Autoload test case now inexplicably fails more,
but it was already broken.
Includes a new VM method, newCall, which must be called before pushing
a call onto the stack to make sure that base is set correctly.
A couple of weird issues remain with autoload.lua.
uses plain Java arrays directly to keep heap allocation to a minimum.
Includes some unit tests that seem to indicate the basic operations are
correct. However, the following things are not implemented:
* Shrinking the capacity when elements are removed
* Optimal storage of each element in array vs. hash when entries are
added out of order. A junit test case is there for this.
