Proposal to update v7.x-staging

.eslintignore

@@ -6,3 +6,4 @@ test/disabled
 test/tmp*/
 tools/eslint
 node_modules
+benchmark/tmp/

.eslintrc → .eslintrc.yaml

@@ -84,7 +84,11 @@ rules:
   eol-last: 2
   func-call-spacing: 2
   func-name-matching: 2
-  indent: [2, 2, {SwitchCase: 1, MemberExpression: 1}]
+  indent: [2, 2, {ArrayExpression: first,
+                  CallExpression: {arguments: first},
+                  MemberExpression: 1, 
+                  ObjectExpression: first,
+                  SwitchCase: 1}]
   key-spacing: [2, {mode: minimum}]
   keyword-spacing: 2
   linebreak-style: [2, unix]
@@ -120,12 +124,11 @@ rules:
   template-curly-spacing: 2
 
   # Custom rules in tools/eslint-rules
-  align-function-arguments: 2
   align-multiline-assignment: 2
   assert-fail-single-argument: 2
   assert-throws-arguments: [2, { requireTwo: false }]
   new-with-error: [2, Error, RangeError, TypeError, SyntaxError, ReferenceError]
-  no-useless-regex-char-class-escape: [2, { override: ['[', ']'] }]
+  timer-arguments: 2
 
 # Global scoped method and vars
 globals:

AUTHORS

@@ -935,7 +935,7 @@ Felix Becker <felix.b@outlook.com>
 Igor Klopov <igor@klopov.com>
 Tsarevich Dmitry <dimhotepus@users.noreply.github.com>
 Ojas Shirekar <ojas.shirekar@gmail.com>
-Noah Rose <noahroseledesma@seattleacademy.org>
+Noah Rose Ledesma <noahroseledesma@seattleacademy.org>
 Rafael Cepeda <rcepeda1993@gmail.com>
 Chinedu Francis Nwafili <frankie.nwafili@gmail.com>
 Braydon Fuller <braydon@bitpay.com>

BUILDING.md

@@ -109,7 +109,8 @@ Prerequisites:
 * One of:
   * [Visual C++ Build Tools](http://landinghub.visualstudio.com/visual-cpp-build-tools)
   * [Visual Studio 2015 Update 3](https://www.visualstudio.com/), all editions
-    including the Community edition.
+    including the Community edition (remember to select
+    "Common Tools for Visual C++ 2015" feature during installation).
 * Basic Unix tools required for some tests,
   [Git for Windows](http://git-scm.com/download/win) includes Git Bash
   and tools which can be included in the global `PATH`.

COLLABORATOR_GUIDE.md

@@ -120,6 +120,7 @@ information regarding the change process:
   for an issue, and/or the hash and commit message if the commit fixes
   a bug in a previous commit. Multiple `Fixes:` lines may be added if
   appropriate.
+- A `Refs:` line referencing a URL for any relevant background.
 - A `Reviewed-By: Name <email>` line for yourself and any
   other Collaborators who have reviewed the change.
   - Useful for @mentions / contact list if something goes wrong in the PR.
@@ -318,9 +319,8 @@ CTC for further discussion.
 
 #### How are LTS Branches Managed?
 
-There are currently three LTS branches: `v4.x`, `v0.10`, and `v0.12`. Each
-of these is paired with a "staging" branch: `v4.x-staging`, `v0.10-staging`,
-and `v0.12-staging`.
+There are currently two LTS branches: `v6.x` and `v4.x`. Each of these is paired
+with a "staging" branch: `v6.x-staging` and `v4.x-staging`.
 
 As commits land in `master`, they are cherry-picked back to each staging
 branch as appropriate. If the commit applies only to the LTS branch, the
@@ -341,18 +341,14 @@ please feel free to include that information in the PR thread.
 
 Several LTS related issue and PR labels have been provided:
 
+* `lts-watch-v6.x` - tells the LTS WG that the issue/PR needs to be considered
+  for landing in the `v6.x-staging` branch.
 * `lts-watch-v4.x` - tells the LTS WG that the issue/PR needs to be considered
   for landing in the `v4.x-staging` branch.
-* `lts-watch-v0.10` - tells the LTS WG that the issue/PR needs to be considered
-  for landing in the `v0.10-staging` branch.
-* `lts-watch-v0.12` - tells the LTS WG that the issue/PR needs to be considered
-  for landing in the `v0.12-staging` branch.
+* `land-on-v6.x` - tells the release team that the commit should be landed
+  in a future v6.x release
 * `land-on-v4.x` - tells the release team that the commit should be landed
   in a future v4.x release
-* `land-on-v0.10` - tells the release team that the commit should be landed
-  in a future v0.10 release
-* `land-on-v0.12` - tells the release team that the commit should be landed
-  in a future v0.12 release
 
 Any collaborator can attach these labels to any PR/issue. As commits are
 landed into the staging branches, the `lts-watch-` label will be removed.

CONTRIBUTING.md

@@ -136,10 +136,13 @@ Check the output of `git log --oneline files_that_you_changed` to find out
 what subsystem (or subsystems) your changes touch.
 
 If your patch fixes an open issue, you can add a reference to it at the end
-of the log. Use the `Fixes:` prefix and the full issue URL. For example:
+of the log. Use the `Fixes:` prefix and the full issue URL. For other references
+use `Refs:`. For example:
 
 ```txt
 Fixes: https://github.com/nodejs/node/issues/1337
+Refs: http://eslint.org/docs/rules/space-in-parens.html
+Refs: https://github.com/nodejs/node/pull/3615
 ```
 
 ### Step 4: Rebase

README.md

@@ -178,6 +178,8 @@ more information about the governance of the Node.js project, see
 **Julien Gilli** <jgilli@nodejs.org>
 * [mscdex](https://github.com/mscdex) -
 **Brian White** <mscdex@mscdex.net>
+* [MylesBorins](https://github.com/MylesBorins) -
+**Myles Borins** <myles.borins@gmail.com>
 * [ofrobots](https://github.com/ofrobots) -
 **Ali Ijaz Sheikh** <ofrobots@google.com>
 * [rvagg](https://github.com/rvagg) -
@@ -186,8 +188,6 @@ more information about the governance of the Node.js project, see
 **Shigeki Ohtsu** <ohtsu@iij.ad.jp>
 * [targos](https://github.com/targos) -
 **Michaël Zasso** <targos@protonmail.com>
-* [TheAlphaNerd](https://github.com/TheAlphaNerd) -
-**Myles Borins** <myles.borins@gmail.com>
 * [thefourtheye](https://github.com/thefourtheye) -
 **Sakthipriyan Vairamani** <thechargingvolcano@gmail.com>
 * [trevnorris](https://github.com/trevnorris) -
@@ -219,6 +219,8 @@ more information about the governance of the Node.js project, see
 **Claudio Rodriguez** <cjrodr@yahoo.com>
 * [danbev](https://github.com/danbev) -
 **Daniel Bevenius** <daniel.bevenius@gmail.com>
+* [edsadr](https://github.com/edsadr) -
+**Adrian Estrada** <edsadr@gmail.com>
 * [eljefedelrodeodeljefe](https://github.com/eljefedelrodeodeljefe) -
 **Robert Jefe Lindstaedt** <robert.lindstaedt@gmail.com>
 * [estliberitas](https://github.com/estliberitas) -
@@ -327,6 +329,8 @@ more information about the governance of the Node.js project, see
 **Glen Keane** <glenkeane.94@gmail.com>
 * [thlorenz](https://github.com/thlorenz) -
 **Thorsten Lorenz** <thlorenz@gmx.de>
+* [TimothyGu](https://github.com/TimothyGu) -
+**Timothy Gu** <timothygu99@gmail.com>
 * [tunniclm](https://github.com/tunniclm) -
 **Mike Tunnicliffe** <m.j.tunnicliffe@gmail.com>
 * [vkurchatkin](https://github.com/vkurchatkin) -

WORKING_GROUPS.md

@@ -42,7 +42,6 @@ Top Level Working Group](https://github.com/nodejs/TSC/blob/master/WORKING_GROUP
 * [Benchmarking](#benchmarking)
 * [Post-mortem](#post-mortem)
 * [Intl](#intl)
-* [HTTP](#http)
 * [Documentation](#documentation)
 * [Testing](#testing)
 
@@ -189,21 +188,6 @@ Responsibilities include:
 * Publishing regular update summaries and other promotional
   content.
 
-### [HTTP](https://github.com/nodejs/http)
-
-The HTTP Working Group is chartered for the support and improvement of the
-HTTP implementation in Node.js.
-
-Responsibilities include:
-* Addressing HTTP issues on the Node.js issue tracker.
-* Authoring and editing HTTP documentation within the Node.js project.
-* Reviewing changes to HTTP functionality within the Node.js project.
-* Working with the ecosystem of HTTP related module developers to evolve the
-  HTTP implementation and APIs in core.
-* Advising the CTC on all HTTP related issues and discussions.
-* Messaging about the future of HTTP to give the community advance notice of
-  changes.
-
 ### [Docker](https://github.com/nodejs/docker-iojs)
 
 The Docker Working Group's purpose is to build, maintain, and improve official

benchmark/README.md

@@ -161,7 +161,7 @@ For analysing the benchmark results use the `compare.R` tool.
 ```console
 $ cat compare-pr-5134.csv | Rscript benchmark/compare.R
 
-                                                                                      improvement significant      p.value
+                                                                                      improvement confidence      p.value
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=ascii           12.46 %         *** 1.165345e-04
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=base64-ascii    24.70 %         *** 1.820615e-15
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=base64-utf8     23.60 %         *** 2.105625e-12
@@ -171,7 +171,7 @@ string_decoder/string-decoder.js n=250000 chunk=1024 inlen=128  encoding=ascii
 ```
 
 In the output, _improvement_ is the relative improvement of the new version,
-hopefully this is positive. _significant_ tells if there is enough
+hopefully this is positive. _confidence_ tells if there is enough
 statistical evidence to validate the _improvement_. If there is enough evidence
 then there will be at least one star (`*`), more stars is just better. **However
 if there are no stars, then you shouldn't make any conclusions based on the
@@ -189,7 +189,7 @@ may require more runs to obtain (can be set with `--runs`).
 
 _For the statistically minded, the R script performs an [independent/unpaired
 2-group t-test][t-test], with the null hypothesis that the performance is the
-same for both versions. The significant field will show a star if the p-value
+same for both versions. The confidence field will show a star if the p-value
 is less than `0.05`._
 
 The `compare.R` tool can also produce a box plot by using the `--plot filename`
@@ -202,7 +202,7 @@ keep the first line since that contains the header information.
 ```console
 $ cat compare-pr-5134.csv | sed '1p;/encoding=ascii/!d' | Rscript benchmark/compare.R --plot compare-plot.png
 
-                                                                               improvement significant      p.value
+                                                                               improvement confidence      p.value
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=1024 encoding=ascii    12.46 %         *** 1.165345e-04
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=128 encoding=ascii      6.70 %           * 2.928003e-02
 string_decoder/string-decoder.js n=250000 chunk=1024 inlen=32 encoding=ascii       7.47 %         *** 5.780583e-04

benchmark/buffers/buffer-tojson.js

@@ -0,0 +1,18 @@
+'use strict';
+
+const common = require('../common.js');
+
+const bench = common.createBenchmark(main, {
+  n: [1e4],
+  len: [0, 10, 256, 4 * 1024]
+});
+
+function main(conf) {
+  var n = +conf.n;
+  var buf = Buffer.allocUnsafe(+conf.len);
+
+  bench.start();
+  for (var i = 0; i < n; ++i)
+    buf.toJSON();
+  bench.end(n);
+}

benchmark/child_process/child-process-read-ipc.js

@@ -1,14 +1,20 @@
 'use strict';
 if (process.argv[2] === 'child') {
   const len = +process.argv[3];
-  const msg = `"${'.'.repeat(len)}"`;
-  while (true) {
-    process.send(msg);
-  }
+  const msg = '.'.repeat(len);
+  const send = () => {
+    while (process.send(msg));
+    // Wait: backlog of unsent messages exceeds threshold
+    setImmediate(send);
+  };
+  send();
 } else {
   const common = require('../common.js');
   const bench = common.createBenchmark(main, {
-    len: [64, 256, 1024, 4096, 32768],
+    len: [
+      64, 256, 1024, 4096, 16384, 65536,
+      65536 << 4, 65536 << 8
+    ],
     dur: [5]
   });
   const spawn = require('child_process').spawn;
@@ -18,7 +24,7 @@ if (process.argv[2] === 'child') {
     const dur = +conf.dur;
     const len = +conf.len;
 
-    const options = { 'stdio': ['ignore', 'ignore', 'ignore', 'ipc'] };
+    const options = { 'stdio': ['ignore', 1, 2, 'ipc'] };
     const child = spawn(process.argv[0],
       [process.argv[1], 'child', len], options);
 
@@ -29,8 +35,7 @@ if (process.argv[2] === 'child') {
 
     setTimeout(function() {
       child.kill();
-      const gbits = (bytes * 8) / (1024 * 1024 * 1024);
-      bench.end(gbits);
+      bench.end(bytes);
     }, dur * 1000);
   }
 }

benchmark/common.js

@@ -195,8 +195,9 @@ function formatResult(data) {
     conf += ' ' + key + '=' + JSON.stringify(data.conf[key]);
   }
 
-  const rate = Math.floor(data.rate)
-                   .toString().replace(/(\d)(?=(\d\d\d)+(?!\d))/g, '$1,');
+  var rate = data.rate.toString().split('.');
+  rate[0] = rate[0].replace(/(\d)(?=(\d\d\d)+(?!\d))/g, '$1,');
+  rate = (rate[1] ? rate.join('.') : rate[0]);
   return `${data.name}${conf}: ${rate}`;
 }
 

benchmark/compare.R

@@ -46,7 +46,7 @@ statistics = ddply(dat, "name", function(subdat) {
   improvement = sprintf("%.2f %%", ((new.mu - old.mu) / old.mu * 100));
 
   p.value = NA;
-  significant = 'NA';
+  confidence = 'NA';
   # Check if there is enough data to calulate the calculate the p-value
   if (length(old.rate) > 1 && length(new.rate) > 1) {
     # Perform a statistics test to see of there actually is a difference in
@@ -56,19 +56,19 @@ statistics = ddply(dat, "name", function(subdat) {
 
     # Add user friendly stars to the table. There should be at least one star
     # before you can say that there is an improvement.
-    significant = '';
+    confidence = '';
     if (p.value < 0.001) {
-      significant = '***';
+      confidence = '***';
     } else if (p.value < 0.01) {
-      significant = '**';
+      confidence = '**';
     } else if (p.value < 0.05) {
-      significant = '*';
+      confidence = '*';
     }
   }
 
   r = list(
     improvement = improvement,
-    significant = significant,
+    confidence = confidence,
     p.value = p.value
   );
   return(data.frame(r));

benchmark/http/create-clientrequest.js

@@ -0,0 +1,23 @@
+'use strict';
+
+var common = require('../common.js');
+var ClientRequest = require('http').ClientRequest;
+
+var bench = common.createBenchmark(main, {
+  pathlen: [1, 8, 16, 32, 64, 128],
+  n: [1e6]
+});
+
+function main(conf) {
+  var pathlen = +conf.pathlen;
+  var n = +conf.n;
+
+  var path = '/'.repeat(pathlen);
+  var opts = { path: path, createConnection: function() {} };
+
+  bench.start();
+  for (var i = 0; i < n; i++) {
+    new ClientRequest(opts);
+  }
+  bench.end(n);
+}

benchmark/net/net-c2s.js

@@ -65,8 +65,17 @@ Writer.prototype.emit = function() {};
 Writer.prototype.prependListener = function() {};
 
 
+function flow() {
+  var dest = this.dest;
+  var res = dest.write(chunk, encoding);
+  if (!res)
+    dest.once('drain', this.flow);
+  else
+    process.nextTick(this.flow);
+}
+
 function Reader() {
-  this.flow = this.flow.bind(this);
+  this.flow = flow.bind(this);
   this.readable = true;
 }
 
@@ -76,15 +85,6 @@ Reader.prototype.pipe = function(dest) {
   return dest;
 };
 
-Reader.prototype.flow = function() {
-  var dest = this.dest;
-  var res = dest.write(chunk, encoding);
-  if (!res)
-    dest.once('drain', this.flow);
-  else
-    process.nextTick(this.flow);
-};
-
 
 function server() {
   var reader = new Reader();