Now working on 0.8.19
blog: Post for v0.8.18 release
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
blog: Post for v0.9.8
doc: fix typo in crypto Hash.digest() note

Added the word 'has' to the sentence.
Closes #4652.
benchmark: Port http.sh from master
buffer: slow buffer copy compatibility fix

Fix issue where SlowBuffers couldn't be passed as target to Buffer
copy().

Also included checks to see if Argument parameters are defined before
assigning their values. This offered ~3x's performance gain.

Backport of 16bbecc from master branch. Closes #4633.
doc: fix typo in cluster module documentation

Fix a small typo in the cluster.settings documentation.
deps: upgrade libuv to 034ea31
blog: Correct shasums for v0.9.8 release
doc: don't suggest to reuse net.Socket objects

Using Socket.prototype.connect() to reconnect an existing Socket object
is not reliable. Users should just create a new Socket object.

See #4698.
zlib: reduce memory consumption, release early

In zlibBuffer(), don't wait for the garbage collector to reclaim the zlib memory
but release it manually. Reduces memory consumption by a factor of 10 or more
with some workloads.

Test case:

  function f() {
    require('zlib').deflate('xxx', g);
  }
  function g() {
    setTimeout(f, 5);
  }
  f();

Observe RSS memory usage with and without this commit. After 10,000 iterations,
RSS stabilizes at ~35 MB with this commit. Without, RSS is over 300 MB and keeps
growing.

Cause: whenever the JS object heap hits the high-water mark, the V8 GC sweeps
it clean, then tries to grow it in order to avoid more sweeps in the near
future. Rule of thumb: the bigger the JS heap, the lazier the GC can be.

A side effect of a bigger heap is that objects now live longer. This is harmless
in general but it affects zlib context objects because those are tied to large
buffers that live outside the JS heap, on the order of 16K per context object.

Ergo, don't wait for the GC to reclaim the memory - it may take a long time.

Fixes #4172.
zlib: pass object size hint to V8

Inform V8 that the zlib context object is tied to a large off-heap buffer.

This makes the GC run more often (in theory) and improves the accuracy of
--trace_external_memory.
blog: remove dangling symlink

Fixes #4716.
npm: Upgrade to v1.2.10
2013.02.06, Version 0.8.19 (Stable)

* npm: Upgrade to v1.2.10

* zlib: pass object size hint to V8 (Ben Noordhuis)

* zlib: reduce memory consumption, release early (Ben Noordhuis)

* buffer: slow buffer copy compatibility fix (Trevor Norris)

* zlib: don't assert on malformed dictionary (Ben Noordhuis)

* zlib: don't assert on missing dictionary (Ben Noordhuis)

* windows: better ipv6 support (Bert Belder)

* windows: add error mappings related to unsupported protocols (Bert Belder)

* windows: map ERROR_DIRECTORY to UV_ENOENT (Bert Belder)
Merge branch 'v0.8.19-release' into v0.8
updated v0.8.19

Merge branch 'v0.8' into japanese-v0.8

Conflicts:
	doc/api/cluster.markdown
	doc/api/crypto.markdown
	doc/api/net.markdown