Change process._tickCallback so that if a callback throws an error but
there are other callbacks after it, we indicate that
process._tickCallback needs to be ran again.
Currently, if a callback in process._tickCallback throws an error, and
that error is caught by an uncaughtException handler and
process.nextTick is never called again, then any other callbacks already
added to the nextTickQueue won't be called again.
Updated the next-tick-errors test to catch this scenario.
If the function for a process.nextTick throws an error, then the
splice() never removes that function from the nextTickQueue array. This
makes sure the functions that have been run in _tickCallback get removed
regardless of errors.
Also add a test for this.
Separating "what to traverse" from "how to traverse and what to do with it "
in findModulePath. It may also fix one not-yet-found bug (absolute ids
weren't loaded when dirs.length = 0).
This makes the console methods more "browser-like",
for example:
console.log("foo", "bar", "baz");
// foo bar baz
but still works with formatting
console.log("hey %s", "tj", "whats up");
// hey tj whats up
If the first parameter passed into console.log() is not a string, all
parameters will be printed as formated by sys.inspect. This change
also affects console.info and console.warn.
Many programs do not handle non-blocking stdio very well. In particular,
man and less have serious problems with this, and since stdout isn't being
flushed after each write, the output jumps about on the screen as you page
down. Programs that do use non-blocking stdio will set that flag themselves
(as node does).
This puts the stdio file descriptors into blocking mode before sharing them
with the child process, so that one could spawn a vim subprocess, or some
other program that depends on blocking IO.