- No more single line "node.js:176:9" errors
- No more strange output when error happens on first line due to
module wrapper function.
- A few tests to check these things
While VM::Integer::Value() offers an int64_t, V8::Integer::New() only
accepts an int32_t, truncating fs.Stat's size in BuildStatsObject().
I consider this a bug in V8, and we should move back to V8::Integer
when it gets a ctr that allows a int64_t. Until then, this work-around
should hold.
After getting some feedback from Mikeal Rogers and Tim Smart, it was decided
that evalcx should not try to do any fancy security stuff, and instead leave
that in the hands of the user. To comply more with spidermonkey, everything
is passed in, and objects are passed in by reference rather than being
cloned.
1. Move the context->Enter() call so that the global obj is available for writing.
2. On success, copy the modified global out to the sandbox object.
3. Don't copy functions in either direction. They have scope and closures, and make for craziness when trying to keep contexts separate.
4. Only do the ->ToObject->Clone() on objects, so that simple values stay simple.
5. Update the test so that it tests all this stuff.
Instead of installing the files in /usr/lib/node/libraries and loading them
from the file system, the files are built-in to the node executable.
However, they are only compiled on demand.
The reasoning is:
1. Allow for more complex internal javascript. In particular,
process.stdout and process.stdin can be js implemented streams.
2. Ease system installs. Loading from disk each time is unnecessary
overhead. Note that there is no "system" path for modules anymore. Only
$HOME/.node_libraries.