doc: Fix syntax in cluster example code
zlib: don't assert on missing dictionary

Handle Z_NEED_DICT errors graciously. Fixes the following assertion:

  node: ../src/node_zlib.cc:161: static void node::ZCtx::Process
  (uv_work_t*): Assertion`ctx->dictionary_ != __null && "Stream
  has no dictionary"' failed.
  Aborted (core dumped)

Fixes #4632.
zlib: don't assert on malformed dictionary

Handle Z_DATA_ERROR errors from inflateSetDictionary() gracefully.
Fixes the following assertion:

  node: ../src/node_zlib.cc:167: static void node::ZCtx::Process
  (uv_work_t*): Assertion `ctx->err_ == 0 && "Failed to set
  dictionary"' failed.
  Aborted (core dumped)

Fixes #4632.
doc: document PYTHON env var in README
deps: upgrade libuv to 7841f77
deps: upgrade libuv to e4d8cba
http: close connection on 304 and chunked encoding

Force the connection to close when the response is a 304 Not Modified
and the user has set a "Transfer-Encoding: chunked" header.

RFC 2616 mandates that 304 responses MUST NOT have a body but node.js
used to send out a zero chunk anyway to accommodate clients that don't
have special handling for 304 responses.

It was pointed out that this might confuse reverse proxies to the point
of creating security liabilities, so suppress the zero chunk and force
the connection to close.
buffer: remove float write range checks

Removed range checks when writing float values, and removed a few
includes and defines. Also updated api docs to reflect that invalid 32
bit float is an unspecified behavior.
build: Add some gyp artifacts to .gitignore
http: close connection on 204 and chunked encoding

This is similar to commit 2cbf458 but this time for 204 No Content
instead of 304 Not Modified responses.

When the user sends a 204 response with a Transfer-Encoding: chunked
header, suppress sending the zero chunk and force the connection to
close.
gitignore: ignore v8.log files
streams: Support objects other than Buffers

We detect for non-string and non-buffer values in onread and
turn the stream into an "objectMode" stream.

If we are in "objectMode" mode then howMuchToRead will
always return 1, state.length will always have 1 appended
to it when there is a new item and fromList always takes
the first value from the list.

This means that for object streams, the n in read(n) is
ignored and read() will always return a single value

Fixed a bug with unpipe where the pipe would break because
the flowing state was not reset to false.

Fixed a bug with sync cb(null, null) in _read which would
forget to end the readable stream
streams2: Handle sync read callbacks nicely
test: Add test for negative stream drain counter
tls: make slab buffer's size configurable

see #4636
V8: Upgrade to 3.15.11.10
V8: Reapply floating patches
npm: Upgrade to v1.2.3
2013.01.24, Version 0.9.8 (Unstable)

* npm: Upgrade to v1.2.3

* V8: Upgrade to 3.15.11.10

* streams: Support objects other than Buffers (Jake Verbaten)

* buffer: remove float write range checks (Trevor Norris)

* http: close connection on 304/204 responses with chunked encoding (Ben Noordhuis)

* build: fix build with dtrace support on FreeBSD (Fedor Indutny)

* console: Support formatting options in trace() (isaacs)

* domain: empty stack on all exceptions (Dave Olszewski)

* unix, windows: make uv_*_bind() error codes consistent (Andrius Bentkus)

* linux: add futimes() fallback (Ben Noordhuis)
test: Add transform objectMode test