"return" statements inside a function which is inside a method will
return from the surrounding method.
The implementation is surprisingly clean. It turns out using an upvalue
for "this", which we already do, give us all the state we need to find
the enclosing method on the stack.
- Add process module with Process class.
- Add "arguments" and "allArguments" methods.
- Docs for same.
- Support passing additional arguments to command line.
- Add "--help" support to command line.
It's failing when building with clang on Travis. The underlying problem
seems to be something broken with how LLVM is looking for the gold
linker, and working around that is outside of my skillset.
To learn more, Google: "LLVMgold.so: error loading plugin" lto
Now, you call wrenEnsureSlots() and then wrenSetSlot___() to set up the
receiver and arguments before the call. Then wrenCall() is passed a
handle to the stub function that makes the call. After that, you can
get the result using wrenGetSlot___().
This is a little more verbose to use, but it's more flexible, simpler,
and much faster in the VM. The call benchmark is 185% of the previous
speed.
Instead, finalizers just get access to the foreign object's raw bytes.
This is deliberately limiting, since it discourages the user from
interacting with the VM in the middle of a GC.
- wrenEnsureSlots()
Lets you go the foreign slot stack to make room for a temporary work
area.
- wrenSetSlotNewList()
Creates a new empty list and stores it in a slot.
- wrenInsertInList()
Takes a value from one slot and inserts it into the list in another.
Still need more functions like getting elements from a list, removing,
etc. but this at least lets you create, populate, and return lists from
foreign methods.
This turns those functions into general-purpose functions for writing
raw C values into slots on the foreign call stack.
Writing a return just means writing a value to slot 0.
- wrenGetArgumentCount() -> wrenGetSlotCount()
- wrenGetArgument___() -> wrenGetSlot___()
Also, the get functions assert that the value is the right type instead
of checking at runtime. This puts the onus on the caller to be safe,
but maximizes performance.
I've got some ideas on how to tweak the embedding API, but I want to
see what performance impact they have first, so this adds a little
benchmark that just calls a foreign method a ton of times.
This is the first step towards dynamically grown stacks. We don't want
to check for stack overflow on every single push, so we store the max
number of slots a function might need and (in later patches) ensure
at function call time that that many slots are available.
