If an input stream would emit `end` event, like
`fs.createReadStream`, then readline need to get the last line
correctly even though that line isnt ended with `\n`.
Given the assert message, and the fact that endCb is always true
in the assert, I am pretty sure the test author was intending
to test for finishEvent, not endCb.
In this test, an HTTP server was ending the response before
consuming all the data sent in the PUT request.
Ending the response would cause the socket to be destroyed,
and since there is some data still to be read, an ECONNRESET is
surfaced on the client side, event though the client has already
ended its side and even seen a 'finish' event.
See:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.2
While it is certainly admissible for the server to send a response
before consuming the entire request, it seems reasonable to
expect that the server would close the connection afterwards
and that the ECONNRESET would be raised on the client.
So I have changed the test to wait until the entire request has been
consumed before sending the response.
Before sending a socket from a cluster master to a worker,
we would call listen in UV but not handle the error.
I made createServerHandle call listen on Windows so we get a chance
the handle any bind/listen errors early.
This fix is 100% windows specific.
It fixes test-cluster-bind-twice and
test-cluster-shared-handle-bind-error on Windows.
This implements the user-facing APIs that lets one run a child process
and block until it exits.
Logic shared with the async counterpart of each function was refactored
to enable code reuse.
Docs and tests are included.
Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue.
Adds to #7070 ("DNS — Throw meaningful error(s)").
The number of connections achieved by the test can vary by platform
and by machine. Lowering the acceptance threshold so that the
test passes on Windows.
Don't use argument as callback if it's not a valid callback function.
Throw a valid exception instead explaining the issue. Adds to #7070
("DNS — Throw meaningful error(s)").
Make vm.runInContext() and vm.runInNewContext() stop copying the Proxy
object from the parent context into the new context when --harmony or
--harmony_proxies is in effect because it overwrites the new context's
native Proxy object.
This commit also adds a regression test for Harmony symbols. They work
okay in the current implementation and the test should ensure it stays
that way.
Conditional globals like 'gc' should only be recognized when --expose_gc
is set. The global.gc feature check works only when done eagerly, else
it lets through a leaked variable called 'gc'.
Before, `new String('foo')` would be inspected as `"{}"` which
is simply not very helpful. Now, a more meaningful
`"[String: 'foo']"` result will be returned from `util.inspect()`.
Boxed String, Boolean, and Number types are all supported.
Closes#7047
Try embedding the ` ... ^` lines inside the `SyntaxError` (or any other
native error) object before giving up and printing them to the stderr.
fix#6920fix#1310
The AsyncListener API has been moved into the "tracing" module in order
to keep the process object free from unnecessary clutter.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
Now the second field in asyncFlags will tell if the provider is
currently being watched, or listened for.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
These will be used to allow users to filter for which types of calls
they wish their callbacks to run.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>
"flags" could mean one of many things, and multiple flag types could be
checked. So make the field more explicit on what type of flags are being
stored.
Signed-off-by: Timothy J Fontaine <tjfontaine@gmail.com>