From 45df0ee7171cf5f9642fb755be1b24075192347c Mon Sep 17 00:00:00 2001 From: Jaideep Bajwa Date: Tue, 1 Nov 2016 02:53:37 -0400 Subject: [PATCH 001/104] v8: update make-v8.sh to use git google build tool gclient doesn't support svn anymore. Updating v8 build script to use git instead. PR-URL: https://github.com/nodejs/node/pull/9393 Reviewed By: Sakthipriyan Vairamani Reviewed-By: Ben Noordhuis Reviewed-By: Michael Dawson --- Makefile | 2 +- tools/make-v8.sh | 49 ++++++++++++++++++++++++++++-------------------- 2 files changed, 30 insertions(+), 21 deletions(-) diff --git a/Makefile b/Makefile index 193319503557fe..6296f917385238 100644 --- a/Makefile +++ b/Makefile @@ -112,7 +112,7 @@ cctest: all @out/$(BUILDTYPE)/$@ v8: - tools/make-v8.sh v8 + tools/make-v8.sh $(MAKE) -C deps/v8 $(V8_ARCH).$(BUILDTYPE_LOWER) $(V8_BUILD_OPTIONS) test: all diff --git a/tools/make-v8.sh b/tools/make-v8.sh index f6efb66a565d54..786171facf52cd 100755 --- a/tools/make-v8.sh +++ b/tools/make-v8.sh @@ -1,38 +1,47 @@ #!/bin/bash - -git_origin=$(git config --get remote.origin.url | sed 's/.\+[\/:]\([^\/]\+\/[^\/]\+\)$/\1/') -git_branch=$(git rev-parse --abbrev-ref HEAD) -v8ver=${1:-v8} #default v8 -svn_prefix=https://github.com -svn_path="$svn_prefix/$git_origin/branches/$git_branch/deps/$v8ver" -#svn_path="$git_origin/branches/$git_branch/deps/$v8ver" -gclient_string="solutions = [{'name': 'v8', 'url': '$svn_path', 'managed': False}]" +# Get V8 branch from v8/include/v8-version.h +MAJOR=$(grep V8_MAJOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3) +MINOR=$(grep V8_MINOR_VERSION deps/v8/include/v8-version.h | cut -d ' ' -f 3) +BRANCH=$MAJOR.$MINOR # clean up if someone presses ctrl-c trap cleanup INT function cleanup() { trap - INT - rm .gclient || true rm .gclient_entries || true rm -rf _bad_scm/ || true - - #if v8ver isn't v8, move the v8 folders - #back to what they were - if [ "$v8ver" != "v8" ]; then - mv v8 $v8ver - mv .v8old v8 - fi + find v8 -name ".git" | xargs rm -rf || true + echo "git cleanup" + git reset --hard HEAD + git clean -fdq + # unstash local changes + git stash pop exit 0 } cd deps -echo $gclient_string > .gclient -if [ "$v8ver" != "v8" ]; then - mv v8 .v8old - mv $v8ver v8 +# stash local changes +git stash +rm -rf v8 + +echo "Fetching V8 from chromium.googlesource.com" +fetch v8 +if [ "$?" -ne 0 ]; then + echo "V8 fetch failed" + exit 1 fi +echo "V8 fetched" + +cd v8 + +echo "Checking out branch:$BRANCH" +git checkout remotes/branch-heads/$BRANCH + +echo "Sync dependencies" gclient sync + +cd .. cleanup From 33bcd6fec8a615e4fe65912eaaaa2cec45d781bb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Zasso?= Date: Wed, 2 Nov 2016 11:28:09 +0100 Subject: [PATCH 002/104] deps: update V8 to 5.4.500.41 PR-URL: https://github.com/nodejs/node/pull/9412 Reviewed-By: James M Snell Reviewed-By: Michael Dawson Reviewed-By: Colin Ihrig Reviewed-By: Ali Ijaz Sheikh Reviewed-By: Ben Noordhuis Reviewed-By: Franziska Hinkelmann --- deps/v8/include/v8-version.h | 2 +- deps/v8/src/bailout-reason.h | 1 + deps/v8/src/code-stubs.h | 7 +++ deps/v8/src/compiler/js-generic-lowering.cc | 10 ++-- .../js-global-object-specialization.cc | 9 +++- deps/v8/src/compiler/simplified-lowering.cc | 2 +- deps/v8/src/compiler/typer.cc | 2 +- .../src/crankshaft/arm/lithium-codegen-arm.cc | 16 ++++-- .../crankshaft/arm64/lithium-codegen-arm64.cc | 15 ++++-- deps/v8/src/crankshaft/hydrogen.cc | 16 ++++-- .../crankshaft/ia32/lithium-codegen-ia32.cc | 17 ++++--- .../crankshaft/mips/lithium-codegen-mips.cc | 16 ++++-- .../mips64/lithium-codegen-mips64.cc | 16 ++++-- .../src/crankshaft/ppc/lithium-codegen-ppc.cc | 16 ++++-- .../crankshaft/s390/lithium-codegen-s390.cc | 16 ++++-- .../src/crankshaft/x64/lithium-codegen-x64.cc | 15 ++++-- .../src/crankshaft/x87/lithium-codegen-x87.cc | 17 ++++--- .../src/full-codegen/arm/full-codegen-arm.cc | 16 ++++-- .../full-codegen/arm64/full-codegen-arm64.cc | 15 ++++-- .../full-codegen/ia32/full-codegen-ia32.cc | 17 ++++--- .../full-codegen/mips/full-codegen-mips.cc | 16 ++++-- .../mips64/full-codegen-mips64.cc | 16 ++++-- .../src/full-codegen/ppc/full-codegen-ppc.cc | 16 ++++-- .../full-codegen/s390/full-codegen-s390.cc | 16 ++++-- .../src/full-codegen/x64/full-codegen-x64.cc | 15 ++++-- .../src/full-codegen/x87/full-codegen-x87.cc | 17 ++++--- deps/v8/src/interpreter/bytecode-generator.cc | 7 ++- deps/v8/src/runtime/runtime-utils.h | 8 +-- deps/v8/src/type-cache.h | 4 +- deps/v8/test/mjsunit/compiler/math-sign.js | 51 +++++++++++++++++++ .../mjsunit/regress/regress-crbug-659475-1.js | 30 +++++++++++ .../mjsunit/regress/regress-crbug-659475-2.js | 31 +++++++++++ 32 files changed, 357 insertions(+), 111 deletions(-) create mode 100644 deps/v8/test/mjsunit/compiler/math-sign.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-659475-1.js create mode 100644 deps/v8/test/mjsunit/regress/regress-crbug-659475-2.js diff --git a/deps/v8/include/v8-version.h b/deps/v8/include/v8-version.h index a2abfc0485e57a..01b10d1d68edbb 100644 --- a/deps/v8/include/v8-version.h +++ b/deps/v8/include/v8-version.h @@ -11,7 +11,7 @@ #define V8_MAJOR_VERSION 5 #define V8_MINOR_VERSION 4 #define V8_BUILD_NUMBER 500 -#define V8_PATCH_LEVEL 36 +#define V8_PATCH_LEVEL 41 // Use 1 for candidates and 0 otherwise. // (Boolean macro values are not supported by all preprocessors.) diff --git a/deps/v8/src/bailout-reason.h b/deps/v8/src/bailout-reason.h index 0966334ffa4c6e..df47eb82b7c579 100644 --- a/deps/v8/src/bailout-reason.h +++ b/deps/v8/src/bailout-reason.h @@ -257,6 +257,7 @@ namespace internal { V(kUnexpectedReturnFromThrow, "Unexpectedly returned from a throw") \ V(kUnsupportedSwitchStatement, "Unsupported switch statement") \ V(kUnsupportedTaggedImmediate, "Unsupported tagged immediate") \ + V(kUnstableConstantTypeHeapObject, "Unstable constant-type heap object") \ V(kVariableResolvedToWithContext, "Variable resolved to with context") \ V(kWeShouldNotHaveAnEmptyLexicalContext, \ "We should not have an empty lexical context") \ diff --git a/deps/v8/src/code-stubs.h b/deps/v8/src/code-stubs.h index 36757c41c63c92..4793d74f9605f4 100644 --- a/deps/v8/src/code-stubs.h +++ b/deps/v8/src/code-stubs.h @@ -1160,6 +1160,8 @@ class FastNewClosureStub : public TurboFanCodeStub { class FastNewFunctionContextStub final : public TurboFanCodeStub { public: + static const int kMaximumSlots = 0x8000; + explicit FastNewFunctionContextStub(Isolate* isolate) : TurboFanCodeStub(isolate) {} @@ -1169,6 +1171,11 @@ class FastNewFunctionContextStub final : public TurboFanCodeStub { compiler::Node* context); private: + // FastNewFunctionContextStub can only allocate closures which fit in the + // new space. + STATIC_ASSERT(((kMaximumSlots + Context::MIN_CONTEXT_SLOTS) * kPointerSize + + FixedArray::kHeaderSize) < Page::kMaxRegularHeapObjectSize); + DEFINE_CALL_INTERFACE_DESCRIPTOR(FastNewFunctionContext); DEFINE_TURBOFAN_CODE_STUB(FastNewFunctionContext, TurboFanCodeStub); }; diff --git a/deps/v8/src/compiler/js-generic-lowering.cc b/deps/v8/src/compiler/js-generic-lowering.cc index 69526cd7eae8d4..812d3e7bcee0d1 100644 --- a/deps/v8/src/compiler/js-generic-lowering.cc +++ b/deps/v8/src/compiler/js-generic-lowering.cc @@ -444,9 +444,13 @@ void JSGenericLowering::LowerJSCreateFunctionContext(Node* node) { int const slot_count = OpParameter(node->op()); CallDescriptor::Flags flags = FrameStateFlagForCall(node); - Callable callable = CodeFactory::FastNewFunctionContext(isolate()); - node->InsertInput(zone(), 1, jsgraph()->Int32Constant(slot_count)); - ReplaceWithStubCall(node, callable, flags); + if (slot_count <= FastNewFunctionContextStub::kMaximumSlots) { + Callable callable = CodeFactory::FastNewFunctionContext(isolate()); + node->InsertInput(zone(), 1, jsgraph()->Int32Constant(slot_count)); + ReplaceWithStubCall(node, callable, flags); + } else { + ReplaceWithRuntimeCall(node, Runtime::kNewFunctionContext); + } } diff --git a/deps/v8/src/compiler/js-global-object-specialization.cc b/deps/v8/src/compiler/js-global-object-specialization.cc index 5ced04e9c15380..2b4bf1c019c0a6 100644 --- a/deps/v8/src/compiler/js-global-object-specialization.cc +++ b/deps/v8/src/compiler/js-global-object-specialization.cc @@ -181,13 +181,18 @@ Reduction JSGlobalObjectSpecialization::ReduceJSStoreGlobal(Node* node) { dependencies()->AssumePropertyCell(property_cell); Type* property_cell_value_type; if (property_cell_value->IsHeapObject()) { + // We cannot do anything if the {property_cell_value}s map is no + // longer stable. + Handle property_cell_value_map( + Handle::cast(property_cell_value)->map(), isolate()); + if (!property_cell_value_map->is_stable()) return NoChange(); + dependencies()->AssumeMapStable(property_cell_value_map); + // Check that the {value} is a HeapObject. value = effect = graph()->NewNode(simplified()->CheckTaggedPointer(), value, effect, control); // Check {value} map agains the {property_cell} map. - Handle property_cell_value_map( - Handle::cast(property_cell_value)->map(), isolate()); effect = graph()->NewNode( simplified()->CheckMaps(1), value, jsgraph()->HeapConstant(property_cell_value_map), effect, control); diff --git a/deps/v8/src/compiler/simplified-lowering.cc b/deps/v8/src/compiler/simplified-lowering.cc index de64de3e1fd7cf..d698fe926939ed 100644 --- a/deps/v8/src/compiler/simplified-lowering.cc +++ b/deps/v8/src/compiler/simplified-lowering.cc @@ -2977,7 +2977,7 @@ Node* SimplifiedLowering::Float64Sign(Node* const node) { graph()->NewNode( common()->Select(MachineRepresentation::kFloat64), graph()->NewNode(machine()->Float64LessThan(), zero, input), one, - zero)); + input)); } Node* SimplifiedLowering::Int32Abs(Node* const node) { diff --git a/deps/v8/src/compiler/typer.cc b/deps/v8/src/compiler/typer.cc index 0d07053dedd0a7..b4051e5547333e 100644 --- a/deps/v8/src/compiler/typer.cc +++ b/deps/v8/src/compiler/typer.cc @@ -1321,7 +1321,7 @@ Type* Typer::Visitor::JSCallFunctionTyper(Type* fun, Typer* t) { case kMathTan: return Type::Number(); case kMathSign: - return t->cache_.kMinusOneToOne; + return t->cache_.kMinusOneToOneOrMinusZeroOrNaN; // Binary math functions. case kMathAtan2: case kMathPow: diff --git a/deps/v8/src/crankshaft/arm/lithium-codegen-arm.cc b/deps/v8/src/crankshaft/arm/lithium-codegen-arm.cc index 072215d5fc8b47..ee3e54b6043c78 100644 --- a/deps/v8/src/crankshaft/arm/lithium-codegen-arm.cc +++ b/deps/v8/src/crankshaft/arm/lithium-codegen-arm.cc @@ -164,11 +164,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r1); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/arm64/lithium-codegen-arm64.cc b/deps/v8/src/crankshaft/arm64/lithium-codegen-arm64.cc index b5e1245f3a4593..ce5813b1e170bf 100644 --- a/deps/v8/src/crankshaft/arm64/lithium-codegen-arm64.cc +++ b/deps/v8/src/crankshaft/arm64/lithium-codegen-arm64.cc @@ -595,11 +595,16 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ Mov(FastNewFunctionContextDescriptor::SlotsRegister(), slots); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ Mov(FastNewFunctionContextDescriptor::SlotsRegister(), slots); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ Push(x1); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); // Context is returned in x0. It replaces the context passed to us. It's diff --git a/deps/v8/src/crankshaft/hydrogen.cc b/deps/v8/src/crankshaft/hydrogen.cc index 240101eeebdb37..a33d2a61200753 100644 --- a/deps/v8/src/crankshaft/hydrogen.cc +++ b/deps/v8/src/crankshaft/hydrogen.cc @@ -6899,11 +6899,19 @@ void HOptimizedGraphBuilder::HandleGlobalVariableAssignment( access = access.WithRepresentation(Representation::Smi()); break; case PropertyCellConstantType::kStableMap: { - // The map may no longer be stable, deopt if it's ever different from - // what is currently there, which will allow for restablization. - Handle map(HeapObject::cast(cell->value())->map()); + // First check that the previous value of the {cell} still has the + // map that we are about to check the new {value} for. If not, then + // the stable map assumption was invalidated and we cannot continue + // with the optimized code. + Handle cell_value(HeapObject::cast(cell->value())); + Handle cell_value_map(cell_value->map()); + if (!cell_value_map->is_stable()) { + return Bailout(kUnstableConstantTypeHeapObject); + } + top_info()->dependencies()->AssumeMapStable(cell_value_map); + // Now check that the new {value} is a HeapObject with the same map. Add(value); - value = Add(value, map); + value = Add(value, cell_value_map); access = access.WithRepresentation(Representation::HeapObject()); break; } diff --git a/deps/v8/src/crankshaft/ia32/lithium-codegen-ia32.cc b/deps/v8/src/crankshaft/ia32/lithium-codegen-ia32.cc index 8233659ddbe22c..2512e2be019866 100644 --- a/deps/v8/src/crankshaft/ia32/lithium-codegen-ia32.cc +++ b/deps/v8/src/crankshaft/ia32/lithium-codegen-ia32.cc @@ -176,12 +176,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), - Immediate(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Immediate(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(edi); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/mips/lithium-codegen-mips.cc b/deps/v8/src/crankshaft/mips/lithium-codegen-mips.cc index fa345e5173c21e..6be0d13f130b92 100644 --- a/deps/v8/src/crankshaft/mips/lithium-codegen-mips.cc +++ b/deps/v8/src/crankshaft/mips/lithium-codegen-mips.cc @@ -183,11 +183,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ li(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ li(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(a1); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/mips64/lithium-codegen-mips64.cc b/deps/v8/src/crankshaft/mips64/lithium-codegen-mips64.cc index 65e922848bc859..924f552ab02bb2 100644 --- a/deps/v8/src/crankshaft/mips64/lithium-codegen-mips64.cc +++ b/deps/v8/src/crankshaft/mips64/lithium-codegen-mips64.cc @@ -159,11 +159,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ li(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ li(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(a1); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/ppc/lithium-codegen-ppc.cc b/deps/v8/src/crankshaft/ppc/lithium-codegen-ppc.cc index fa1f430c58382f..e1203b86a49330 100644 --- a/deps/v8/src/crankshaft/ppc/lithium-codegen-ppc.cc +++ b/deps/v8/src/crankshaft/ppc/lithium-codegen-ppc.cc @@ -170,11 +170,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r4); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/s390/lithium-codegen-s390.cc b/deps/v8/src/crankshaft/s390/lithium-codegen-s390.cc index 7bb718df7e0d78..ec2a85a07b2e61 100644 --- a/deps/v8/src/crankshaft/s390/lithium-codegen-s390.cc +++ b/deps/v8/src/crankshaft/s390/lithium-codegen-s390.cc @@ -160,11 +160,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r3); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/x64/lithium-codegen-x64.cc b/deps/v8/src/crankshaft/x64/lithium-codegen-x64.cc index e417eaaeb19b72..66046a4e6875c8 100644 --- a/deps/v8/src/crankshaft/x64/lithium-codegen-x64.cc +++ b/deps/v8/src/crankshaft/x64/lithium-codegen-x64.cc @@ -179,11 +179,16 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ Set(FastNewFunctionContextDescriptor::SlotsRegister(), slots); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ Set(FastNewFunctionContextDescriptor::SlotsRegister(), slots); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ Push(rdi); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/crankshaft/x87/lithium-codegen-x87.cc b/deps/v8/src/crankshaft/x87/lithium-codegen-x87.cc index f6aa9639b3dd96..1a42d5b41b7dc1 100644 --- a/deps/v8/src/crankshaft/x87/lithium-codegen-x87.cc +++ b/deps/v8/src/crankshaft/x87/lithium-codegen-x87.cc @@ -146,12 +146,17 @@ void LCodeGen::DoPrologue(LPrologue* instr) { __ CallRuntime(Runtime::kNewScriptContext); deopt_mode = Safepoint::kLazyDeopt; } else { - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), - Immediate(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Immediate(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(edi); + __ CallRuntime(Runtime::kNewFunctionContext); + } } RecordSafepoint(deopt_mode); diff --git a/deps/v8/src/full-codegen/arm/full-codegen-arm.cc b/deps/v8/src/full-codegen/arm/full-codegen-arm.cc index e25a0441d8d72a..7887d32bdb8608 100644 --- a/deps/v8/src/full-codegen/arm/full-codegen-arm.cc +++ b/deps/v8/src/full-codegen/arm/full-codegen-arm.cc @@ -184,11 +184,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(r3); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r1); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(r3); // Preserve new target. } diff --git a/deps/v8/src/full-codegen/arm64/full-codegen-arm64.cc b/deps/v8/src/full-codegen/arm64/full-codegen-arm64.cc index 3330325df4447f..a4f32da2ef9675 100644 --- a/deps/v8/src/full-codegen/arm64/full-codegen-arm64.cc +++ b/deps/v8/src/full-codegen/arm64/full-codegen-arm64.cc @@ -187,11 +187,16 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ Push(x3); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ Mov(FastNewFunctionContextDescriptor::SlotsRegister(), slots); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ Mov(FastNewFunctionContextDescriptor::SlotsRegister(), slots); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ Push(x1); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ Pop(x3); // Restore new target. } diff --git a/deps/v8/src/full-codegen/ia32/full-codegen-ia32.cc b/deps/v8/src/full-codegen/ia32/full-codegen-ia32.cc index 0a00eeade87649..3571948216cc82 100644 --- a/deps/v8/src/full-codegen/ia32/full-codegen-ia32.cc +++ b/deps/v8/src/full-codegen/ia32/full-codegen-ia32.cc @@ -176,12 +176,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(edx); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), - Immediate(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Immediate(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(edi); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(edx); // Restore new target. } diff --git a/deps/v8/src/full-codegen/mips/full-codegen-mips.cc b/deps/v8/src/full-codegen/mips/full-codegen-mips.cc index 917474ae882fb1..67598d0a251198 100644 --- a/deps/v8/src/full-codegen/mips/full-codegen-mips.cc +++ b/deps/v8/src/full-codegen/mips/full-codegen-mips.cc @@ -194,11 +194,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(a3); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ li(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ li(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(a1); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(a3); // Restore new target. } diff --git a/deps/v8/src/full-codegen/mips64/full-codegen-mips64.cc b/deps/v8/src/full-codegen/mips64/full-codegen-mips64.cc index 0c09bdf176cc98..c149f137cf9111 100644 --- a/deps/v8/src/full-codegen/mips64/full-codegen-mips64.cc +++ b/deps/v8/src/full-codegen/mips64/full-codegen-mips64.cc @@ -193,11 +193,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(a3); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ li(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ li(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(a1); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(a3); // Restore new target. } diff --git a/deps/v8/src/full-codegen/ppc/full-codegen-ppc.cc b/deps/v8/src/full-codegen/ppc/full-codegen-ppc.cc index 6bac8b15a3399a..6813069d401d3a 100644 --- a/deps/v8/src/full-codegen/ppc/full-codegen-ppc.cc +++ b/deps/v8/src/full-codegen/ppc/full-codegen-ppc.cc @@ -190,11 +190,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(r6); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r4); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(r6); // Preserve new target. } diff --git a/deps/v8/src/full-codegen/s390/full-codegen-s390.cc b/deps/v8/src/full-codegen/s390/full-codegen-s390.cc index 003c9312e43f98..bd1509b77df3ed 100644 --- a/deps/v8/src/full-codegen/s390/full-codegen-s390.cc +++ b/deps/v8/src/full-codegen/s390/full-codegen-s390.cc @@ -195,11 +195,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(r5); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), Operand(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Operand(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(r3); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(r5); // Preserve new target. } diff --git a/deps/v8/src/full-codegen/x64/full-codegen-x64.cc b/deps/v8/src/full-codegen/x64/full-codegen-x64.cc index 4b0e43c9b21afc..ce94a990d54114 100644 --- a/deps/v8/src/full-codegen/x64/full-codegen-x64.cc +++ b/deps/v8/src/full-codegen/x64/full-codegen-x64.cc @@ -175,11 +175,16 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ Push(rdx); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ Set(FastNewFunctionContextDescriptor::SlotsRegister(), slots); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ Set(FastNewFunctionContextDescriptor::SlotsRegister(), slots); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ Push(rdi); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ Pop(rdx); // Restore new target. } diff --git a/deps/v8/src/full-codegen/x87/full-codegen-x87.cc b/deps/v8/src/full-codegen/x87/full-codegen-x87.cc index 0ccf63f9f079b1..28c8960c4b7a45 100644 --- a/deps/v8/src/full-codegen/x87/full-codegen-x87.cc +++ b/deps/v8/src/full-codegen/x87/full-codegen-x87.cc @@ -176,12 +176,17 @@ void FullCodeGenerator::Generate() { if (info->scope()->new_target_var() != nullptr) { __ push(edx); // Preserve new target. } - FastNewFunctionContextStub stub(isolate()); - __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), - Immediate(slots)); - __ CallStub(&stub); - // Result of FastNewFunctionContextStub is always in new space. - need_write_barrier = false; + if (slots <= FastNewFunctionContextStub::kMaximumSlots) { + FastNewFunctionContextStub stub(isolate()); + __ mov(FastNewFunctionContextDescriptor::SlotsRegister(), + Immediate(slots)); + __ CallStub(&stub); + // Result of FastNewFunctionContextStub is always in new space. + need_write_barrier = false; + } else { + __ push(edi); + __ CallRuntime(Runtime::kNewFunctionContext); + } if (info->scope()->new_target_var() != nullptr) { __ pop(edx); // Restore new target. } diff --git a/deps/v8/src/interpreter/bytecode-generator.cc b/deps/v8/src/interpreter/bytecode-generator.cc index a57399cf6f046e..6ff43a41707fe4 100644 --- a/deps/v8/src/interpreter/bytecode-generator.cc +++ b/deps/v8/src/interpreter/bytecode-generator.cc @@ -3168,7 +3168,12 @@ void BytecodeGenerator::VisitNewLocalFunctionContext() { .CallRuntime(Runtime::kNewScriptContext, closure, 2); } else { int slot_count = scope->num_heap_slots() - Context::MIN_CONTEXT_SLOTS; - builder()->CreateFunctionContext(slot_count); + if (slot_count <= FastNewFunctionContextStub::kMaximumSlots) { + builder()->CreateFunctionContext(slot_count); + } else { + builder()->CallRuntime(Runtime::kNewFunctionContext, + Register::function_closure(), 1); + } } execution_result()->SetResultInAccumulator(); } diff --git a/deps/v8/src/runtime/runtime-utils.h b/deps/v8/src/runtime/runtime-utils.h index 0d84354f4424d4..147efed092a742 100644 --- a/deps/v8/src/runtime/runtime-utils.h +++ b/deps/v8/src/runtime/runtime-utils.h @@ -69,9 +69,11 @@ namespace internal { // Assert that the given argument has a valid value for a LanguageMode // and store it in a LanguageMode variable with the given name. #define CONVERT_LANGUAGE_MODE_ARG_CHECKED(name, index) \ - CHECK(args[index]->IsSmi()); \ - CHECK(is_valid_language_mode(args.smi_at(index))); \ - LanguageMode name = static_cast(args.smi_at(index)); + CHECK(args[index]->IsNumber()); \ + int32_t __tmp_##name = 0; \ + CHECK(args[index]->ToInt32(&__tmp_##name)); \ + CHECK(is_valid_language_mode(__tmp_##name)); \ + LanguageMode name = static_cast(__tmp_##name); // Assert that the given argument is a number within the Int32 range // and convert it to int32_t. If the argument is not an Int32 we crash safely. diff --git a/deps/v8/src/type-cache.h b/deps/v8/src/type-cache.h index f83f3bdb7146b5..e7616ec3dce1cb 100644 --- a/deps/v8/src/type-cache.h +++ b/deps/v8/src/type-cache.h @@ -50,7 +50,9 @@ class TypeCache final { Type* const kTenOrUndefined = Type::Union(kSingletonTen, Type::Undefined(), zone()); Type* const kMinusOneOrZero = CreateRange(-1.0, 0.0); - Type* const kMinusOneToOne = CreateRange(-1.0, 1.0); + Type* const kMinusOneToOneOrMinusZeroOrNaN = Type::Union( + Type::Union(CreateRange(-1.0, 1.0), Type::MinusZero(), zone()), + Type::NaN(), zone()); Type* const kZeroOrOne = CreateRange(0.0, 1.0); Type* const kZeroOrOneOrNaN = Type::Union(kZeroOrOne, Type::NaN(), zone()); Type* const kZeroToThirtyOne = CreateRange(0.0, 31.0); diff --git a/deps/v8/test/mjsunit/compiler/math-sign.js b/deps/v8/test/mjsunit/compiler/math-sign.js new file mode 100644 index 00000000000000..0fff0982df8832 --- /dev/null +++ b/deps/v8/test/mjsunit/compiler/math-sign.js @@ -0,0 +1,51 @@ +// Copyright 2016 the V8 project authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. + +// Flags: --allow-natives-syntax + +function signInt32(i) { + i = i|0; + return Math.sign(i); +} + +signInt32(0); +signInt32(2); +%OptimizeFunctionOnNextCall(signInt32); +assertEquals(1, signInt32(1)); +assertEquals(0, signInt32(0)); +assertEquals(-1, signInt32(-1)); +assertEquals(-1, signInt32(-1)); +assertEquals(1, signInt32(2147483647)); +assertEquals(-1, signInt32(2147483648)); +assertEquals(-1, signInt32(-2147483648)); +assertEquals(0, signInt32(NaN)); +assertEquals(0, signInt32(undefined)); +assertEquals(0, signInt32(-0)); + +function signFloat64(i) { + return Math.sign(+i); +} + +signFloat64(0.1); +signFloat64(-0.1); +%OptimizeFunctionOnNextCall(signFloat64); +assertEquals(1, signFloat64(1)); +assertEquals(1, signFloat64(0.001)); +assertEquals(-1, signFloat64(-0.002)); +assertEquals(1, signFloat64(1e100)); +assertEquals(-1, signFloat64(-2e100)); +assertEquals(0, signFloat64(0)); +assertEquals(Infinity, 1/signFloat64(0)); +assertEquals(-1, signFloat64(-1)); +assertEquals(-1, signFloat64(-1)); +assertEquals(1, signFloat64(2147483647)); +assertEquals(1, signFloat64(2147483648)); +assertEquals(-1, signFloat64(-2147483647)); +assertEquals(-1, signFloat64(-2147483648)); +assertEquals(-1, signFloat64(-2147483649)); +assertEquals(-0, signFloat64(-0)); +assertEquals(NaN, signFloat64(NaN)); +assertEquals(NaN, signFloat64(undefined)); +assertEquals(1, signFloat64(Infinity)); +assertEquals(-1, signFloat64(-Infinity)); diff --git a/deps/v8/test/mjsunit/regress/regress-crbug-659475-1.js b/deps/v8/test/mjsunit/regress/regress-crbug-659475-1.js new file mode 100644 index 00000000000000..2648203b8c16d7 --- /dev/null +++ b/deps/v8/test/mjsunit/regress/regress-crbug-659475-1.js @@ -0,0 +1,30 @@ +// Copyright 2016 the V8 project authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. + +// Flags: --allow-natives-syntax + +var n; + +function Ctor() { + n = new Set(); +} + +function Check() { + n.xyz = 0x826852f4; +} + +Ctor(); +Ctor(); +%OptimizeFunctionOnNextCall(Ctor); +Ctor(); + +Check(); +Check(); +%OptimizeFunctionOnNextCall(Check); +Check(); + +Ctor(); +Check(); + +parseInt('AAAAAAAA'); diff --git a/deps/v8/test/mjsunit/regress/regress-crbug-659475-2.js b/deps/v8/test/mjsunit/regress/regress-crbug-659475-2.js new file mode 100644 index 00000000000000..49e02fde0093ef --- /dev/null +++ b/deps/v8/test/mjsunit/regress/regress-crbug-659475-2.js @@ -0,0 +1,31 @@ +// Copyright 2016 the V8 project authors. All rights reserved. +// Use of this source code is governed by a BSD-style license that can be +// found in the LICENSE file. + +// Flags: --allow-natives-syntax + +var n; + +function Ctor() { + try { } catch (e) {} + n = new Set(); +} + +function Check() { + n.xyz = 0x826852f4; +} + +Ctor(); +Ctor(); +%OptimizeFunctionOnNextCall(Ctor); +Ctor(); + +Check(); +Check(); +%OptimizeFunctionOnNextCall(Check); +Check(); + +Ctor(); +Check(); + +parseInt('AAAAAAAA'); From 6b01bfa9d6e582ea5b057ac0435cc565d3ca4e29 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johan=20Bergstr=C3=B6m?= Date: Tue, 25 Oct 2016 13:26:46 -0300 Subject: [PATCH 003/104] gitignore: ignore all tap files We now have multiple tap producers; just ignore all files with the `.tap` extension. PR-URL: https://github.com/nodejs/node/pull/9262 Reviewed-By: Gibson Fahnestock Reviewed-By: Ben Noordhuis Reviewed-By: Myles Borins --- .gitignore | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitignore b/.gitignore index 509a5a66593eaa..b6790e116cd6b5 100644 --- a/.gitignore +++ b/.gitignore @@ -88,7 +88,7 @@ deps/npm/node_modules/.bin/ # test artifacts tools/faketime icu_config.gypi -test.tap +*.tap # Xcode workspaces and project folders *.xcodeproj From 23584e4ec5fd47e20f6a11395b5e672e203fc1ab Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johan=20Bergstr=C3=B6m?= Date: Tue, 25 Oct 2016 12:23:48 -0300 Subject: [PATCH 004/104] gtest: output tap comments as yamlish This makes yaml-ish parsers happy. Note: gtest still seems to output the expected/result slightly different making the full traceback less informational. PR-URL: https://github.com/nodejs/node/pull/9262 Reviewed-By: Gibson Fahnestock Reviewed-By: Ben Noordhuis Reviewed-By: Myles Borins --- deps/gtest/src/gtest.cc | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/deps/gtest/src/gtest.cc b/deps/gtest/src/gtest.cc index 213740ca0c7943..87b67a2230fe55 100644 --- a/deps/gtest/src/gtest.cc +++ b/deps/gtest/src/gtest.cc @@ -3596,13 +3596,15 @@ void TapUnitTestResultPrinter::OutputTapTestInfo(int* count, *stream << " ---\n"; *stream << " duration_ms: " << FormatTimeInMillisAsSeconds(result.elapsed_time()) << "\n"; - *stream << " ...\n"; - for (int i = 0; i < result.total_part_count(); ++i) { - const TestPartResult& part = result.GetTestPartResult(i); - OutputTapComment(stream, part.message()); + if (result.total_part_count() > 0) { + *stream << " stack: |-\n"; + for (int i = 0; i < result.total_part_count(); ++i) { + const TestPartResult& part = result.GetTestPartResult(i); + OutputTapComment(stream, part.message()); + } } - + *stream << " ...\n"; *count += 1; } @@ -3610,11 +3612,11 @@ void TapUnitTestResultPrinter::OutputTapComment(::std::ostream* stream, const char* comment) { const char* start = comment; while (const char* end = strchr(start, '\n')) { - *stream << "# " << std::string(start, end) << "\n"; + *stream << " " << std::string(start, end) << "\n"; start = end + 1; } if (*start) - *stream << "# " << start << "\n"; + *stream << " " << start << "\n"; } // Formats the given time in milliseconds as seconds. From 6a94ffb1cfdb41c0746d6055e2fa3ac2f995f4de Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Johan=20Bergstr=C3=B6m?= Date: Wed, 12 Oct 2016 11:34:28 -0300 Subject: [PATCH 005/104] test: output tap13 instead of almost-tap Produce a tap13-compatible output which makes it simpler to parse. Output is still readable by the jenkins tap plugin. PR-URL: https://github.com/nodejs/node/pull/9262 Reviewed-By: Gibson Fahnestock Reviewed-By: Ben Noordhuis Reviewed-By: Myles Borins --- tools/test.py | 39 +++++++++++++++++++++++++++++---------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/tools/test.py b/tools/test.py index d57988f24d608e..6e1840b7672006 100755 --- a/tools/test.py +++ b/tools/test.py @@ -256,11 +256,15 @@ def HasRun(self, output): class TapProgressIndicator(SimpleProgressIndicator): - def _printDiagnostic(self, messages): - for l in messages.splitlines(): - logger.info('# ' + l) + def _printDiagnostic(self, traceback, severity): + logger.info(' severity: %s', severity) + logger.info(' stack: |-') + + for l in traceback.splitlines(): + logger.info(' ' + l) def Starting(self): + logger.info('TAP version 13') logger.info('1..%i' % len(self.cases)) self._done = 0 @@ -269,6 +273,8 @@ def AboutToRun(self, case): def HasRun(self, output): self._done += 1 + self.traceback = '' + self.severity = 'ok' # Print test name as (for example) "parallel/test-assert". Tests that are # scraped from the addons documentation are all named test.js, making it @@ -281,19 +287,23 @@ def HasRun(self, output): if output.UnexpectedOutput(): status_line = 'not ok %i %s' % (self._done, command) + self.severity = 'fail' + self.traceback = output.output.stdout + output.output.stderr + if FLAKY in output.test.outcomes and self.flaky_tests_mode == DONTCARE: status_line = status_line + ' # TODO : Fix flaky test' + self.severity = 'flaky' + logger.info(status_line) - self._printDiagnostic("\n".join(output.diagnostic)) if output.HasCrashed(): - self._printDiagnostic(PrintCrashed(output.output.exit_code)) + self.severity = 'crashed' + exit_code = output.output.exit_code + self.traceback = "oh no!\nexit code: " + PrintCrashed(exit_code) if output.HasTimedOut(): - self._printDiagnostic('TIMEOUT') + self.severity = 'fail' - self._printDiagnostic(output.output.stderr) - self._printDiagnostic(output.output.stdout) else: skip = skip_regex.search(output.output.stdout) if skip: @@ -304,7 +314,11 @@ def HasRun(self, output): if FLAKY in output.test.outcomes: status_line = status_line + ' # TODO : Fix flaky test' logger.info(status_line) - self._printDiagnostic("\n".join(output.diagnostic)) + + if output.diagnostic: + self.severity = 'ok' + self.traceback = output.diagnostic + duration = output.test.duration @@ -315,7 +329,12 @@ def HasRun(self, output): # duration_ms is measured in seconds and is read as such by TAP parsers. # It should read as "duration including ms" rather than "duration in ms" logger.info(' ---') - logger.info(' duration_ms: %d.%d' % (total_seconds, duration.microseconds / 1000)) + logger.info(' duration_ms: %d.%d' % + (total_seconds, duration.microseconds / 1000)) + if self.severity is not 'ok' or self.traceback is not '': + if output.HasTimedOut(): + self.traceback = 'timeout' + self._printDiagnostic(self.traceback, self.severity) logger.info(' ...') def Done(self): From f0d40e8be37af3a008e2223faefbeb5899ba95d9 Mon Sep 17 00:00:00 2001 From: Daniel Bevenius Date: Sat, 5 Nov 2016 15:37:36 +0100 Subject: [PATCH 006/104] doc: fix link to cli.md in vm.md Looks like the link to cli.md is missing in vm.md: https://nodejs.org/api/vm.html#vm_vm_runindebugcontext_code Added the link which can be verified by using the following commands: $ make doc $ open out/doc/api/vm.html PR-URL: https://github.com/nodejs/node/pull/9481 Reviewed-By: James M Snell Reviewed-By: Colin Ihrig --- doc/api/vm.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/api/vm.md b/doc/api/vm.md index be3a490336b62b..a62923c2a1a317 100644 --- a/doc/api/vm.md +++ b/doc/api/vm.md @@ -297,7 +297,7 @@ console.log(Debug.findScript(process.exit).name); // 'internal/process.js' implementation and may change (or even be removed) without prior warning. The `Debug` object can also be made available using the V8-specific -`--expose_debug_as=` [command line option][cli.md]. +`--expose_debug_as=` [command line option][]. ## vm.runInNewContext(code[, sandbox][, options]) +* {String} + Provides the platform-specific path delimiter: * `;` for Windows @@ -114,6 +117,7 @@ added: v0.1.16 --> * `path` {String} +* Return: {String} The `path.dirname()` method returns the directory name of a `path`, similar to the Unix `dirname` command. @@ -133,6 +137,7 @@ added: v0.1.25 --> * `path` {String} +* Return: {String} The `path.extname()` method returns the extension of the `path`, from the last occurrence of the `.` (period) character to end of string in the last portion of @@ -168,10 +173,11 @@ added: v0.11.15 * `pathObject` {Object} * `dir` {String} - * `root` {String} + * `root` {String} * `base` {String} * `name` {String} * `ext` {String} +* Return: {String} The `path.format()` method returns a path string from an object. This is the opposite of [`path.parse()`][]. @@ -244,6 +250,7 @@ added: v0.11.2 --> * `path` {String} +* Return: {Boolean} The `path.isAbsolute()` method determines if `path` is an absolute path. @@ -278,6 +285,7 @@ added: v0.1.16 --> * `...paths` {String} A sequence of path segments +* Return: {String} The `path.join()` method joins all given `path` segments together using the platform specific separator as a delimiter, then normalizes the resulting path. @@ -304,6 +312,7 @@ added: v0.1.23 --> * `path` {String} +* Return: {String} The `path.normalize()` method normalizes the given `path`, resolving `'..'` and `'.'` segments. @@ -337,6 +346,7 @@ added: v0.11.15 --> * `path` {String} +* Return: {Object} The `path.parse()` method returns an object whose properties represent significant elements of the `path`. @@ -404,6 +414,8 @@ A [`TypeError`][] is thrown if `path` is not a string. added: v0.11.15 --> +* {Object} + The `path.posix` property provides access to POSIX specific implementations of the `path` methods. @@ -414,6 +426,7 @@ added: v0.5.0 * `from` {String} * `to` {String} +* Return: {String} The `path.relative()` method returns the relative path from `from` to `to`. If `from` and `to` each resolve to the same path (after calling `path.resolve()` @@ -444,6 +457,7 @@ added: v0.3.4 --> * `...paths` {String} A sequence of paths or path segments +* Return: {String} The `path.resolve()` method resolves a sequence of paths or path segments into an absolute path. @@ -485,6 +499,8 @@ A [`TypeError`][] is thrown if any of the arguments is not a string. added: v0.7.9 --> +* {String} + Provides the platform-specific path segment separator: * `\` on Windows @@ -509,6 +525,8 @@ On Windows: added: v0.11.15 --> +* {Object} + The `path.win32` property provides access to Windows-specific implementations of the `path` methods. From 77aded3ba1f6f601b2ca9779099640795a8d9b48 Mon Sep 17 00:00:00 2001 From: imatvieiev Date: Mon, 7 Nov 2016 23:23:41 +0200 Subject: [PATCH 027/104] doc: add process api data types to documentation PR-URL: https://github.com/nodejs/node/pull/9505 Reviewed-By: Luigi Pinca Reviewed-By: Brian White Reviewed-By: Colin Ihrig Reviewed-By: Michael Dawson Reviewed-By: Roman Reiss --- doc/api/process.md | 58 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 56 insertions(+), 2 deletions(-) diff --git a/doc/api/process.md b/doc/api/process.md index d21be90237c356..d4779e6a2f8c77 100644 --- a/doc/api/process.md +++ b/doc/api/process.md @@ -447,6 +447,8 @@ generate a core file. added: v0.5.0 --> +* {String} + The `process.arch` property returns a String identifying the processor architecture that the Node.js process is currently running on. For instance `'arm'`, `'ia32'`, or `'x64'`. @@ -460,6 +462,8 @@ console.log(`This processor architecture is ${process.arch}`); added: v0.1.27 --> +* {Array} + The `process.argv` property returns an array containing the command line arguments passed when the Node.js process was launched. The first element will be [`process.execPath`]. See `process.argv0` if access to the original value of @@ -497,6 +501,8 @@ Would generate the output: added: 6.4.0 --> +* {String} + The `process.argv0` property stores a read-only copy of the original value of `argv[0]` passed when Node.js starts. @@ -545,6 +551,8 @@ catch (err) { added: v0.7.7 --> +* {Object} + The `process.config` property returns an Object containing the JavaScript representation of the configure options used to compile the current Node.js executable. This is the same as the `config.gypi` file that was produced when @@ -588,6 +596,8 @@ replace the value of `process.config`. added: v0.7.2 --> +* {Boolean} + If the Node.js process is spawned with an IPC channel (see the [Child Process][] and [Cluster][] documentation), the `process.connected` property will return `true` so long as the IPC channel is connected and will return `false` after @@ -603,6 +613,9 @@ added: v6.1.0 * `previousValue` {Object} A previous return value from calling `process.cpuUsage()` +* Return: {Object} + * `user` {Integer} + * `system` {Integer} The `process.cpuUsage()` method returns the user and system CPU time usage of the current process, in an object with properties `user` and `system`, whose @@ -630,6 +643,8 @@ console.log(process.cpuUsage(startUsage)); added: v0.1.8 --> +* Return: {String} + The `process.cwd()` method returns the current working directory of the Node.js process. @@ -658,6 +673,8 @@ If the Node.js process was not spawned with an IPC channel, added: v0.1.27 --> +* {Object} + The `process.env` property returns an object containing the user environment. See environ(7). @@ -822,6 +839,8 @@ emitMyWarning(); added: v0.7.7 --> +* {Object} + The `process.execArgv` property returns the set of Node.js-specific command-line options passed when the Node.js process was launched. These options do not appear in the array returned by the [`process.argv`][] property, and do not @@ -852,13 +871,15 @@ And `process.argv`: added: v0.1.100 --> +* {String} + The `process.execPath` property returns the absolute pathname of the executable that started the Node.js process. For example: -```sh -/usr/local/bin/node +```js +'/usr/local/bin/node' ``` @@ -931,6 +952,8 @@ is safer than calling `process.exit()`. added: v0.11.8 --> +* {Integer} + A number which will be the process exit code, when the process either exits gracefully, or is exited via [`process.exit()`][] without specifying a code. @@ -961,6 +984,8 @@ or Android) added: v2.0.0 --> +* Return: {Object} + The `process.geteuid()` method returns the numerical effective user identity of the process. (See geteuid(2).) @@ -978,6 +1003,8 @@ Android) added: v0.1.31 --> +* Return: {Object} + The `process.getgid()` method returns the numerical group identity of the process. (See getgid(2).) @@ -996,6 +1023,8 @@ Android) added: v0.9.4 --> +* Return: {Array} + The `process.getgroups()` method returns an array with the supplementary group IDs. POSIX leaves it unspecified if the effective group ID is included but Node.js ensures it always is. @@ -1008,6 +1037,8 @@ Android) added: v0.1.28 --> +* Return: {Integer} + The `process.getuid()` method returns the numeric user identity of the process. (See getuid(2).) @@ -1140,6 +1171,11 @@ is no entry script. added: v0.1.16 --> +* Return: {Object} + * `rss` {Integer} + * `heapTotal` {Integer} + * `heapUsed` {Integer} + The `process.memoryUsage()` method returns an object describing the memory usage of the Node.js process measured in bytes. @@ -1259,6 +1295,8 @@ happening, just like a `while(true);` loop. added: v0.1.15 --> +* {Integer} + The `process.pid` property returns the PID of the process. ```js @@ -1270,6 +1308,8 @@ console.log(`This process is pid ${process.pid}`); added: v0.1.16 --> +* {String} + The `process.platform` property returns a string identifying the operating system platform on which the Node.js process is running. For instance `'darwin'`, `'freebsd'`, `'linux'`, `'sunos'` or `'win32'` @@ -1471,6 +1511,8 @@ Android) ## process.stderr +* {Stream} + The `process.stderr` property returns a [Writable][] stream equivalent to or associated with `stderr` (fd `2`). @@ -1491,6 +1533,8 @@ on `process.stderr`, `process.stdout`, or `process.stdin`: ## process.stdin +* {Stream} + The `process.stdin` property returns a [Readable][] stream equivalent to or associated with `stdin` (fd `0`). @@ -1521,6 +1565,8 @@ must call `process.stdin.resume()` to read from it. Note also that calling ## process.stdout +* {Stream} + The `process.stdout` property returns a [Writable][] stream equivalent to or associated with `stdout` (fd `1`). @@ -1576,6 +1622,8 @@ See the [TTY][] documentation for more information. added: v0.1.104 --> +* {String} + The `process.title` property returns the current process title (i.e. returns the current value of `ps`). Assigning a new value to `process.title` modifies the current value of `ps`. @@ -1615,6 +1663,8 @@ console.log( added: v0.5.0 --> +* Return: {Number} + The `process.uptime()` method returns the number of seconds the current Node.js process has been running. @@ -1623,6 +1673,8 @@ process has been running. added: v0.1.3 --> +* {String} + The `process.version` property returns the Node.js version string. ```js @@ -1634,6 +1686,8 @@ console.log(`Version: ${process.version}`); added: v0.2.0 --> +* {Object} + The `process.versions` property returns an object listing the version strings of Node.js and its dependencies. From d09a9f4d2781a114f8926a0355d5117980b1a838 Mon Sep 17 00:00:00 2001 From: William Kapke Date: Thu, 10 Nov 2016 23:20:43 +0000 Subject: [PATCH 028/104] doc: remove Roadmap Working Group MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Refs: https://github.com/nodejs/CTC/issues/16 PR-URL: https://github.com/nodejs/node/pull/9545 Reviewed-By: Ben Noordhuis Reviewed-By: Rich Trott Reviewed-By: Luigi Pinca Reviewed-By: Evan Lucas Reviewed-By: Colin Ihrig Reviewed-By: Johan Bergström Reviewed-By: Michael Dawson Reviewed-By: Roman Reiss --- WORKING_GROUPS.md | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/WORKING_GROUPS.md b/WORKING_GROUPS.md index 4be238b4ac4ace..694325a0bfcf95 100644 --- a/WORKING_GROUPS.md +++ b/WORKING_GROUPS.md @@ -24,7 +24,6 @@ back in to the CTC. * [Diagnostics](#diagnostics) * [i18n](#i18n) * [Evangelism](#evangelism) -* [Roadmap](#roadmap) * [Docker](#docker) * [Addon API](#addon-api) * [Benchmarking](#benchmarking) @@ -196,19 +195,6 @@ Responsibilities include: * Messaging about the future of HTTP to give the community advance notice of changes. -### [Roadmap](https://github.com/nodejs/roadmap) - -The Roadmap Working Group is responsible for user community outreach -and the translation of their concerns into a plan of action for Node.js. - -The final [ROADMAP](./ROADMAP.md) document is still owned by the TC and requires -the same approval for changes as any other project asset. - -Their responsibilities are: -* Attracting and summarizing user community needs and feedback. -* Finding or potentially creating tools that allow for broader participation. -* Creating Pull Requests for relevant changes to [ROADMAP.md](./ROADMAP.md) - ### [Docker](https://github.com/nodejs/docker-iojs) The Docker Working Group's purpose is to build, maintain, and improve official From 7c9e8cbd762505430d4367ca167e93cbae4366ff Mon Sep 17 00:00:00 2001 From: kohta ito Date: Sat, 12 Nov 2016 16:18:05 +0900 Subject: [PATCH 029/104] doc: fix the index order in pseudocode of modules fix the index order in pseudocode of modules. PR-URL: https://github.com/nodejs/node/pull/9562 Reviewed-By: Shigeki Ohtsu Reviewed-By: Yosuke Furukawa Reviewed-By: Roman Reiss --- doc/api/modules.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/api/modules.md b/doc/api/modules.md index 66ac1ce22c2bca..e496dbe1ac52e2 100644 --- a/doc/api/modules.md +++ b/doc/api/modules.md @@ -181,9 +181,9 @@ NODE_MODULES_PATHS(START) 3. let DIRS = [] 4. while I >= 0, a. if PARTS[I] = "node_modules" CONTINUE - c. DIR = path join(PARTS[0 .. I] + "node_modules") - b. DIRS = DIRS + DIR - c. let I = I - 1 + b. DIR = path join(PARTS[0 .. I] + "node_modules") + c. DIRS = DIRS + DIR + d. let I = I - 1 5. return DIRS ``` From 8c859d58aba3eeba6bd8fd0d8416c6b189709948 Mon Sep 17 00:00:00 2001 From: Rich Trott Date: Wed, 9 Nov 2016 21:02:14 -0800 Subject: [PATCH 030/104] test: refactor test-tls-inception MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * buffer-to-string comparison replaced with string-to-string comparison * equal -> strictEqual * var -> const * rename identifiers to avoid masking PR-URL: https://github.com/nodejs/node/pull/9536 Reviewed-By: Santiago Gimeno Reviewed-By: Michaël Zasso Reviewed-By: Michael Dawson Reviewed-By: Colin Ihrig --- test/parallel/test-tls-inception.js | 36 ++++++++++++++--------------- 1 file changed, 17 insertions(+), 19 deletions(-) diff --git a/test/parallel/test-tls-inception.js b/test/parallel/test-tls-inception.js index ce6f60dc97a12e..760887d9f25264 100644 --- a/test/parallel/test-tls-inception.js +++ b/test/parallel/test-tls-inception.js @@ -1,34 +1,33 @@ 'use strict'; -var common = require('../common'); -var assert = require('assert'); +const common = require('../common'); if (!common.hasCrypto) { common.skip('missing crypto'); return; } -var tls = require('tls'); -var fs = require('fs'); -var path = require('path'); -var net = require('net'); +const assert = require('assert'); +const tls = require('tls'); -var options, a, b; +const fs = require('fs'); +const path = require('path'); +const net = require('net'); -var body = Buffer.alloc(400000, 'A'); - -options = { +const options = { key: fs.readFileSync(path.join(common.fixturesDir, 'test_key.pem')), cert: fs.readFileSync(path.join(common.fixturesDir, 'test_cert.pem')) }; +const body = 'A'.repeat(40000); + // the "proxy" server -a = tls.createServer(options, function(socket) { - var options = { +const a = tls.createServer(options, function(socket) { + const myOptions = { host: '127.0.0.1', port: b.address().port, rejectUnauthorized: false }; - var dest = net.connect(options); + const dest = net.connect(myOptions); dest.pipe(socket); socket.pipe(dest); @@ -38,20 +37,19 @@ a = tls.createServer(options, function(socket) { }); // the "target" server -b = tls.createServer(options, function(socket) { +const b = tls.createServer(options, function(socket) { socket.end(body); }); a.listen(0, function() { b.listen(0, function() { - options = { + const myOptions = { host: '127.0.0.1', port: a.address().port, rejectUnauthorized: false }; - var socket = tls.connect(options); - var ssl; - ssl = tls.connect({ + const socket = tls.connect(myOptions); + const ssl = tls.connect({ socket: socket, rejectUnauthorized: false }); @@ -61,7 +59,7 @@ a.listen(0, function() { buf += data; }); ssl.on('end', common.mustCall(function() { - assert.equal(buf, body); + assert.strictEqual(buf, body); ssl.end(); a.close(); b.close(); From dae3d3e53c5bed61dc70cc624c7fac50ca5af92d Mon Sep 17 00:00:00 2001 From: Rich Trott Date: Wed, 9 Nov 2016 22:09:56 -0800 Subject: [PATCH 031/104] test: refactor test-next-tick-error-spin * use common.mustCall() * setTimeout() -> setImmediate() * assert() -> assert.strictEqual() * var -> const * remove unneeded console.log() * remove commented-out code PR-URL: https://github.com/nodejs/node/pull/9537 Reviewed-By: Michael Dawson Reviewed-By: Colin Ihrig --- test/sequential/test-next-tick-error-spin.js | 25 +++++++++----------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/test/sequential/test-next-tick-error-spin.js b/test/sequential/test-next-tick-error-spin.js index 7a76ab1e12df68..911d99d7416db5 100644 --- a/test/sequential/test-next-tick-error-spin.js +++ b/test/sequential/test-next-tick-error-spin.js @@ -1,24 +1,23 @@ 'use strict'; -var common = require('../common'); -var assert = require('assert'); +const common = require('../common'); +const assert = require('assert'); if (process.argv[2] !== 'child') { - var spawn = require('child_process').spawn; - var child = spawn(process.execPath, [__filename, 'child'], { + const spawn = require('child_process').spawn; + const child = spawn(process.execPath, [__filename, 'child'], { stdio: 'pipe'//'inherit' }); - var timer = setTimeout(function() { + const timer = setTimeout(function() { throw new Error('child is hung'); }, common.platformTimeout(3000)); - child.on('exit', function(code) { - console.error('ok'); - assert(!code); + child.on('exit', common.mustCall(function(code) { + assert.strictEqual(code, 0); clearTimeout(timer); - }); + })); } else { - var domain = require('domain'); - var d = domain.create(); + const domain = require('domain'); + const d = domain.create(); process.maxTickDepth = 10; // in the error handler, we trigger several MakeCallback events @@ -40,10 +39,8 @@ if (process.argv[2] !== 'child') { } f(); - setTimeout(function() { + setImmediate(function() { console.error('broke in!'); - //process.stdout.close(); - //process.stderr.close(); process.exit(0); }); } From 64dec14502ab41036c23da7f501b4fc83945f427 Mon Sep 17 00:00:00 2001 From: ikasumi_wt Date: Sat, 12 Nov 2016 16:19:47 +0900 Subject: [PATCH 032/104] doc: fix e.g., to e.g. in doc/http.md fix e.g., to e.g. in doc/http.md Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9564 Reviewed-By: Yosuke Furukawa Reviewed-By: Roman Reiss Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- doc/api/http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/api/http.md b/doc/api/http.md index 3b3b93525709af..4888efa9e7085f 100644 --- a/doc/api/http.md +++ b/doc/api/http.md @@ -550,7 +550,7 @@ with a `100 Continue` as appropriate. Handling this event involves calling [`response.writeContinue()`][] if the client should continue to send the request body, or generating an appropriate HTTP -response (e.g., 400 Bad Request) if the client should not continue to send the +response (e.g. 400 Bad Request) if the client should not continue to send the request body. Note that when this event is emitted and handled, the [`'request'`][] event will @@ -853,7 +853,7 @@ This method adds HTTP trailing headers (a header but at the end of the message) to the response. Trailers will **only** be emitted if chunked encoding is used for the -response; if it is not (e.g., if the request was HTTP/1.0), they will +response; if it is not (e.g. if the request was HTTP/1.0), they will be silently discarded. Note that HTTP requires the `Trailer` header to be sent if you intend to From e7eb9ccdcfa7193b7b3736b2f6522b8d5c493d40 Mon Sep 17 00:00:00 2001 From: Yoshiya Hinosawa Date: Sat, 12 Nov 2016 16:26:52 +0900 Subject: [PATCH 033/104] test: improve test-stream2-objects.js This commit improves the test cases in test-stream2-objects.js by using assert.strictEqual instead of assert.equal. This is a part of Code And Learn at NodeFest 2016 Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9565 Reviewed-By: Shigeki Ohtsu Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca --- test/parallel/test-stream2-objects.js | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/test/parallel/test-stream2-objects.js b/test/parallel/test-stream2-objects.js index da0a8d3b41cde9..b18be26dc530fb 100644 --- a/test/parallel/test-stream2-objects.js +++ b/test/parallel/test-stream2-objects.js @@ -33,7 +33,7 @@ function run() { // ensure all tests have run process.on('exit', function() { - assert.equal(count, 0); + assert.strictEqual(count, 0); }); process.nextTick(run); @@ -210,16 +210,16 @@ test('high watermark _read', function(t) { var v = r.read(); - assert.equal(calls, 0); - assert.equal(v, '1'); + assert.strictEqual(calls, 0); + assert.strictEqual(v, '1'); var v2 = r.read(); - assert.equal(v2, '2'); + assert.strictEqual(v2, '2'); var v3 = r.read(); - assert.equal(v3, '3'); + assert.strictEqual(v3, '3'); - assert.equal(calls, 1); + assert.strictEqual(calls, 1); t.end(); }); @@ -232,7 +232,7 @@ test('high watermark push', function(t) { r._read = function(n) {}; for (var i = 0; i < 6; i++) { var bool = r.push(i); - assert.equal(bool, i === 5 ? false : true); + assert.strictEqual(bool, i !== 5); } t.end(); @@ -309,7 +309,7 @@ test('buffers finish until cb is called', function(t) { var called = false; w._write = function(chunk, encoding, cb) { - assert.equal(chunk, 'foo'); + assert.strictEqual(chunk, 'foo'); process.nextTick(function() { called = true; @@ -318,7 +318,7 @@ test('buffers finish until cb is called', function(t) { }; w.on('finish', function() { - assert.equal(called, true); + assert.strictEqual(called, true); t.end(); }); From 4ae4e00ae94a0b0039876e06db59381ccfa27998 Mon Sep 17 00:00:00 2001 From: YutamaKotaro Date: Sat, 12 Nov 2016 16:36:06 +0900 Subject: [PATCH 034/104] doc: fix typo about cluster doc, (eg. -> e.g.) Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9568 Reviewed-By: Roman Reiss Reviewed-By: Colin Ihrig Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- doc/api/cluster.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/api/cluster.md b/doc/api/cluster.md index c239c44ffb7d5d..07fdfb67458dab 100644 --- a/doc/api/cluster.md +++ b/doc/api/cluster.md @@ -144,7 +144,7 @@ added: v0.11.2 --> * `code` {Number} the exit code, if it exited normally. -* `signal` {String} the name of the signal (eg. `'SIGHUP'`) that caused +* `signal` {String} the name of the signal (e.g. `'SIGHUP'`) that caused the process to be killed. Similar to the `cluster.on('exit')` event, but specific to this worker. @@ -496,7 +496,7 @@ added: v0.7.9 * `worker` {cluster.Worker} * `code` {Number} the exit code, if it exited normally. -* `signal` {String} the name of the signal (eg. `'SIGHUP'`) that caused +* `signal` {String} the name of the signal (e.g. `'SIGHUP'`) that caused the process to be killed. When any of the workers die the cluster module will emit the `'exit'` event. From 58fc7a137c71ecc9abdad40846259121f26f8328 Mon Sep 17 00:00:00 2001 From: MURAKAMI Masahiko Date: Sat, 12 Nov 2016 17:04:42 +0900 Subject: [PATCH 035/104] test: change from setTimeout to setImmediate This is a part of Code And Learn at NodeFest 2016 Challenge Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9578 Reviewed-By: Yosuke Furukawa Reviewed-By: Shigeki Ohtsu Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen --- test/parallel/test-stream-unshift-empty-chunk.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/parallel/test-stream-unshift-empty-chunk.js b/test/parallel/test-stream-unshift-empty-chunk.js index 99c2e8b7520144..477f5c4be56bac 100644 --- a/test/parallel/test-stream-unshift-empty-chunk.js +++ b/test/parallel/test-stream-unshift-empty-chunk.js @@ -11,7 +11,7 @@ var nChunks = 10; var chunk = Buffer.alloc(10, 'x'); r._read = function(n) { - setTimeout(function() { + setImmediate(function() { r.push(--nChunks === 0 ? null : chunk); }); }; From 92bd19e0bdfb24776db6c5b325975843435acc62 Mon Sep 17 00:00:00 2001 From: Thomas Watson Steen Date: Sat, 12 Nov 2016 12:17:52 +0900 Subject: [PATCH 036/104] doc: simplify process.memoryUsage() example code Using util.inspect doesn't change the output in this case PR-URL: https://github.com/nodejs/node/pull/9560 Reviewed-By: Myles Borins Reviewed-By: Rich Trott Reviewed-By: Roman Reiss Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen --- doc/api/process.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/doc/api/process.md b/doc/api/process.md index d4779e6a2f8c77..ff32225cc04c65 100644 --- a/doc/api/process.md +++ b/doc/api/process.md @@ -1182,9 +1182,7 @@ of the Node.js process measured in bytes. For example, the code: ```js -const util = require('util'); - -console.log(util.inspect(process.memoryUsage())); +console.log(process.memoryUsage()); ``` Will generate: From d532a57a4b007e5a74ba9901c6aa1eff8ce676af Mon Sep 17 00:00:00 2001 From: Roman Reiss Date: Fri, 11 Nov 2016 21:29:01 +0100 Subject: [PATCH 037/104] doc: consistent 'Returns:' For consistency, changed all `Return:` to `Returns:` in the API docs. PR-URL: https://github.com/nodejs/node/pull/9554 Reviewed-By: Colin Ihrig Reviewed-By: Luigi Pinca Reviewed-By: Jeremiah Senkpiel --- doc/api/buffer.md | 84 ++++++++++++++++++++-------------------- doc/api/child_process.md | 8 ++-- doc/api/cluster.md | 2 +- doc/api/modules.md | 2 +- doc/api/path.md | 20 +++++----- doc/api/process.md | 18 ++++----- doc/api/stream.md | 10 ++--- 7 files changed, 72 insertions(+), 72 deletions(-) diff --git a/doc/api/buffer.md b/doc/api/buffer.md index 3396223a07287c..810f06825fd087 100644 --- a/doc/api/buffer.md +++ b/doc/api/buffer.md @@ -612,7 +612,7 @@ added: v0.1.90 calculate the length of * `encoding` {String} If `string` is a string, this is its encoding. **Default:** `'utf8'` -* Return: {Integer} The number of bytes contained within `string` +* Returns: {Integer} The number of bytes contained within `string` Returns the actual byte length of a string. This is not the same as [`String.prototype.length`] since that returns the number of *characters* in @@ -638,7 +638,7 @@ added: v0.11.13 * `buf1` {Buffer} * `buf2` {Buffer} -* Return: {Integer} +* Returns: {Integer} Compares `buf1` to `buf2` typically for the purpose of sorting arrays of `Buffer` instances. This is equivalent to calling @@ -664,7 +664,7 @@ added: v0.7.11 * `list` {Array} List of `Buffer` instances to concat * `totalLength` {Integer} Total length of the `Buffer` instances in `list` when concatenated -* Return: {Buffer} +* Returns: {Buffer} Returns a new `Buffer` which is the result of concatenating all the `Buffer` instances in the `list` together. @@ -829,7 +829,7 @@ added: v0.1.101 --> * `obj` {Object} -* Return: {Boolean} +* Returns: {Boolean} Returns `true` if `obj` is a `Buffer`, `false` otherwise. @@ -839,7 +839,7 @@ added: v0.9.1 --> * `encoding` {String} A character encoding name to check -* Return: {Boolean} +* Returns: {Boolean} Returns `true` if `encoding` contains a supported character encoding, or `false` otherwise. @@ -894,7 +894,7 @@ added: v0.11.13 * `sourceEnd` {Integer} The offset within `buf` at which to end comparison (not inclusive). Ignored when `targetStart` is `undefined`. **Default:** [`buf.length`] -* Return: {Integer} +* Returns: {Integer} Compares `buf` with `target` and returns a number indicating whether `buf` comes before, after, or is the same as `target` in sort order. @@ -966,7 +966,7 @@ added: v0.1.90 Ignored when `targetStart` is `undefined`. **Default:** `0` * `sourceEnd` {Integer} The offset within `buf` at which to stop copying (not inclusive). Ignored when `sourceStart` is `undefined`. **Default:** [`buf.length`] -* Return: {Integer} The number of bytes copied. +* Returns: {Integer} The number of bytes copied. Copies data from a region of `buf` to a region in `target` even if the `target` memory region overlaps with `buf`. @@ -1011,7 +1011,7 @@ console.log(buf.toString()); added: v1.1.0 --> -* Return: {Iterator} +* Returns: {Iterator} Creates and returns an [iterator] of `[index, byte]` pairs from the contents of `buf`. @@ -1039,7 +1039,7 @@ added: v0.11.13 --> * `otherBuffer` {Buffer} A `Buffer` to compare to -* Return: {Boolean} +* Returns: {Boolean} Returns `true` if both `buf` and `otherBuffer` have exactly the same bytes, `false` otherwise. @@ -1068,7 +1068,7 @@ added: v0.5.0 * `end` {Integer} Where to stop filling `buf` (not inclusive). **Default:** [`buf.length`] * `encoding` {String} If `value` is a string, this is its encoding. **Default:** `'utf8'` -* Return: {Buffer} A reference to `buf` +* Returns: {Buffer} A reference to `buf` Fills `buf` with the specified `value`. If the `offset` and `end` are not given, the entire `buf` will be filled. This is meant to be a small simplification to @@ -1104,7 +1104,7 @@ added: v1.5.0 * `byteOffset` {Integer} Where to begin searching in `buf`. **Default:** `0` * `encoding` {String} If `value` is a string, this is its encoding. **Default:** `'utf8'` -* Return: {Integer} The index of the first occurrence of `value` in `buf` or `-1` +* Returns: {Integer} The index of the first occurrence of `value` in `buf` or `-1` if `buf` does not contain `value` If `value` is: @@ -1159,7 +1159,7 @@ added: v5.3.0 * `byteOffset` {Integer} Where to begin searching in `buf`. **Default:** `0` * `encoding` {String} If `value` is a string, this is its encoding. **Default:** `'utf8'` -* Return: {Boolean} `true` if `value` was found in `buf`, `false` otherwise +* Returns: {Boolean} `true` if `value` was found in `buf`, `false` otherwise Equivalent to [`buf.indexOf() !== -1`][`buf.indexOf()`]. @@ -1196,7 +1196,7 @@ console.log(buf.includes('this', 4)); added: v1.1.0 --> -* Return: {Iterator} +* Returns: {Iterator} Creates and returns an [iterator] of `buf` keys (indices). @@ -1227,7 +1227,7 @@ added: v6.0.0 **Default:** [`buf.length`] * `encoding` {String} If `value` is a string, this is its encoding. **Default:** `'utf8'` -* Return: {Integer} The index of the last occurrence of `value` in `buf` or `-1` +* Returns: {Integer} The index of the last occurrence of `value` in `buf` or `-1` if `buf` does not contain `value` Identical to [`buf.indexOf()`], except `buf` is searched from back to front @@ -1323,7 +1323,7 @@ added: v0.11.15 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 8` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Number} +* Returns: {Number} Reads a 64-bit double from `buf` at the specified `offset` with specified endian format (`readDoubleBE()` returns big endian, `readDoubleLE()` returns @@ -1359,7 +1359,7 @@ added: v0.11.15 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Number} +* Returns: {Number} Reads a 32-bit float from `buf` at the specified `offset` with specified endian format (`readFloatBE()` returns big endian, `readFloatLE()` returns @@ -1394,7 +1394,7 @@ added: v0.5.0 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 1` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads a signed 8-bit integer from `buf` at the specified `offset`. @@ -1426,7 +1426,7 @@ added: v0.5.5 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 2` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads a signed 16-bit integer from `buf` at the specified `offset` with the specified endian format (`readInt16BE()` returns big endian, @@ -1460,7 +1460,7 @@ added: v0.5.5 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads a signed 32-bit integer from `buf` at the specified `offset` with the specified endian format (`readInt32BE()` returns big endian, @@ -1495,7 +1495,7 @@ added: v0.11.15 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - byteLength` * `byteLength` {Integer} How many bytes to read. Must satisfy: `0 < byteLength <= 6` * `noAssert` {Boolean} Skip `offset` and `byteLength` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads `byteLength` number of bytes from `buf` at the specified `offset` and interprets the result as a two's complement signed value. Supports up to 48 @@ -1526,7 +1526,7 @@ added: v0.5.0 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 1` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads an unsigned 8-bit integer from `buf` at the specified `offset`. @@ -1556,7 +1556,7 @@ added: v0.5.5 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 2` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads an unsigned 16-bit integer from `buf` at the specified `offset` with specified endian format (`readUInt16BE()` returns big endian, `readUInt16LE()` @@ -1594,7 +1594,7 @@ added: v0.5.5 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `offset` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads an unsigned 32-bit integer from `buf` at the specified `offset` with specified endian format (`readUInt32BE()` returns big endian, @@ -1627,7 +1627,7 @@ added: v0.11.15 * `offset` {Integer} Where to start reading. Must satisfy: `0 <= offset <= buf.length - byteLength` * `byteLength` {Integer} How many bytes to read. Must satisfy: `0 < byteLength <= 6` * `noAssert` {Boolean} Skip `offset` and `byteLength` validation? **Default:** `false` -* Return: {Integer} +* Returns: {Integer} Reads `byteLength` number of bytes from `buf` at the specified `offset` and interprets the result as an unsigned integer. Supports up to 48 @@ -1659,7 +1659,7 @@ added: v0.3.0 * `start` {Integer} Where the new `Buffer` will start. **Default:** `0` * `end` {Integer} Where the new `Buffer` will end (not inclusive). **Default:** [`buf.length`] -* Return: {Buffer} +* Returns: {Buffer} Returns a new `Buffer` that references the same memory as the original, but offset and cropped by the `start` and `end` indices. @@ -1715,7 +1715,7 @@ console.log(buf.slice(-5, -2).toString()); added: v5.10.0 --> -* Return: {Buffer} A reference to `buf` +* Returns: {Buffer} A reference to `buf` Interprets `buf` as an array of unsigned 16-bit integers and swaps the byte-order *in-place*. Throws a `RangeError` if [`buf.length`] is not a multiple of 2. @@ -1745,7 +1745,7 @@ buf2.swap32(); added: v5.10.0 --> -* Return: {Buffer} A reference to `buf` +* Returns: {Buffer} A reference to `buf` Interprets `buf` as an array of unsigned 32-bit integers and swaps the byte-order *in-place*. Throws a `RangeError` if [`buf.length`] is not a multiple of 4. @@ -1775,7 +1775,7 @@ buf2.swap32(); added: v6.3.0 --> -* Return: {Buffer} A reference to `buf` +* Returns: {Buffer} A reference to `buf` Interprets `buf` as an array of 64-bit numbers and swaps the byte-order *in-place*. Throws a `RangeError` if [`buf.length`] is not a multiple of 8. @@ -1812,7 +1812,7 @@ added: v0.1.90 * `start` {Integer} The byte offset to start decoding at. **Default:** `0` * `end` {Integer} The byte offset to stop decoding at (not inclusive). **Default:** [`buf.length`] -* Return: {String} +* Returns: {String} Decodes `buf` to a string according to the specified character encoding in `encoding`. `start` and `end` may be passed to decode only a subset of `buf`. @@ -1851,7 +1851,7 @@ console.log(buf2.toString(undefined, 0, 3)); added: v0.9.2 --> -* Return: {Object} +* Returns: {Object} Returns a JSON representation of `buf`. [`JSON.stringify()`] implicitly calls this function when stringifying a `Buffer` instance. @@ -1880,7 +1880,7 @@ console.log(copy); added: v1.1.0 --> -* Return: {Iterator} +* Returns: {Iterator} Creates and returns an [iterator] for `buf` values (bytes). This function is called automatically when a `Buffer` is used in a `for..of` statement. @@ -1922,7 +1922,7 @@ added: v0.1.90 * `offset` {Integer} Where to start writing `string`. **Default:** `0` * `length` {Integer} How many bytes to write. **Default:** `buf.length - offset` * `encoding` {String} The character encoding of `string`. **Default:** `'utf8'` -* Return: {Integer} Number of bytes written +* Returns: {Integer} Number of bytes written Writes `string` to `buf` at `offset` according to the character encoding in `encoding`. The `length` parameter is the number of bytes to write. If `buf` did not contain @@ -1949,7 +1949,7 @@ added: v0.11.15 * `value` {Number} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 8` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeDoubleBE()` writes big endian, `writeDoubleLE()` writes little @@ -1984,7 +1984,7 @@ added: v0.11.15 * `value` {Number} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeFloatBE()` writes big endian, `writeFloatLE()` writes little @@ -2018,7 +2018,7 @@ added: v0.5.0 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 1` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset`. `value` *should* be a valid signed 8-bit integer. Behavior is undefined when `value` is anything other than @@ -2050,7 +2050,7 @@ added: v0.5.5 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 2` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeInt16BE()` writes big endian, `writeInt16LE()` writes little @@ -2083,7 +2083,7 @@ added: v0.5.5 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeInt32BE()` writes big endian, `writeInt32LE()` writes little @@ -2118,7 +2118,7 @@ added: v0.11.15 * `byteLength` {Integer} How many bytes to write. Must satisfy: `0 < byteLength <= 6` * `noAssert` {Boolean} Skip `value`, `offset`, and `byteLength` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `byteLength` bytes of `value` to `buf` at the specified `offset`. Supports up to 48 bits of accuracy. Behavior is undefined when `value` is @@ -2151,7 +2151,7 @@ added: v0.5.0 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 1` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset`. `value` *should* be a valid unsigned 8-bit integer. Behavior is undefined when `value` is anything @@ -2183,7 +2183,7 @@ added: v0.5.5 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 2` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeUInt16BE()` writes big endian, `writeUInt16LE()` writes little @@ -2220,7 +2220,7 @@ added: v0.5.5 * `value` {Integer} Number to be written to `buf` * `offset` {Integer} Where to start writing. Must satisfy: `0 <= offset <= buf.length - 4` * `noAssert` {Boolean} Skip `value` and `offset` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `value` to `buf` at the specified `offset` with specified endian format (`writeUInt32BE()` writes big endian, `writeUInt32LE()` writes little @@ -2257,7 +2257,7 @@ added: v0.5.5 * `byteLength` {Integer} How many bytes to write. Must satisfy: `0 < byteLength <= 6` * `noAssert` {Boolean} Skip `value`, `offset`, and `byteLength` validation? **Default:** `false` -* Return: {Integer} `offset` plus the number of bytes written +* Returns: {Integer} `offset` plus the number of bytes written Writes `byteLength` bytes of `value` to `buf` at the specified `offset`. Supports up to 48 bits of accuracy. Behavior is undefined when `value` is diff --git a/doc/api/child_process.md b/doc/api/child_process.md index 96b4c16d9cee2b..e56c03a2bfc4f7 100644 --- a/doc/api/child_process.md +++ b/doc/api/child_process.md @@ -144,7 +144,7 @@ added: v0.1.90 * `error` {Error} * `stdout` {String|Buffer} * `stderr` {String|Buffer} -* Return: {ChildProcess} +* Returns: {ChildProcess} Spawns a shell then executes the `command` within that shell, buffering any generated output. @@ -217,7 +217,7 @@ added: v0.1.91 * `error` {Error} * `stdout` {String|Buffer} * `stderr` {String|Buffer} -* Return: {ChildProcess} +* Returns: {ChildProcess} The `child_process.execFile()` function is similar to [`child_process.exec()`][] except that it does not spawn a shell. Rather, the specified executable `file` @@ -267,7 +267,7 @@ added: v0.5.0 be thrown. For instance `[0, 1, 2, 'ipc']`. * `uid` {Number} Sets the user identity of the process. (See setuid(2).) * `gid` {Number} Sets the group identity of the process. (See setgid(2).) -* Return: {ChildProcess} +* Returns: {ChildProcess} The `child_process.fork()` method is a special case of [`child_process.spawn()`][] used specifically to spawn new Node.js processes. @@ -901,7 +901,7 @@ added: v0.5.9 * `sendHandle` {Handle} * `options` {Object} * `callback` {Function} -* Return: {Boolean} +* Returns: {Boolean} When an IPC channel has been established between the parent and child ( i.e. when using [`child_process.fork()`][]), the `child.send()` method can be diff --git a/doc/api/cluster.md b/doc/api/cluster.md index 07fdfb67458dab..c323282d0f94b1 100644 --- a/doc/api/cluster.md +++ b/doc/api/cluster.md @@ -414,7 +414,7 @@ added: v0.7.0 * `message` {Object} * `sendHandle` {Handle} * `callback` {Function} -* Return: Boolean +* Returns: Boolean Send a message to a worker or master, optionally with a handle. diff --git a/doc/api/modules.md b/doc/api/modules.md index e496dbe1ac52e2..ad98a0abcc20c4 100644 --- a/doc/api/modules.md +++ b/doc/api/modules.md @@ -601,7 +601,7 @@ added: v0.5.1 --> * `id` {String} -* Return: {Object} `module.exports` from the resolved module +* Returns: {Object} `module.exports` from the resolved module The `module.require` method provides a way to load a module as if `require()` was called from the original module. diff --git a/doc/api/path.md b/doc/api/path.md index 6a65f17be5bf10..45dac1069ce8c5 100644 --- a/doc/api/path.md +++ b/doc/api/path.md @@ -61,7 +61,7 @@ added: v0.1.25 * `path` {String} * `ext` {String} An optional file extension -* Return: {String} +* Returns: {String} The `path.basename()` methods returns the last portion of a `path`, similar to the Unix `basename` command. @@ -117,7 +117,7 @@ added: v0.1.16 --> * `path` {String} -* Return: {String} +* Returns: {String} The `path.dirname()` method returns the directory name of a `path`, similar to the Unix `dirname` command. @@ -137,7 +137,7 @@ added: v0.1.25 --> * `path` {String} -* Return: {String} +* Returns: {String} The `path.extname()` method returns the extension of the `path`, from the last occurrence of the `.` (period) character to end of string in the last portion of @@ -177,7 +177,7 @@ added: v0.11.15 * `base` {String} * `name` {String} * `ext` {String} -* Return: {String} +* Returns: {String} The `path.format()` method returns a path string from an object. This is the opposite of [`path.parse()`][]. @@ -250,7 +250,7 @@ added: v0.11.2 --> * `path` {String} -* Return: {Boolean} +* Returns: {Boolean} The `path.isAbsolute()` method determines if `path` is an absolute path. @@ -285,7 +285,7 @@ added: v0.1.16 --> * `...paths` {String} A sequence of path segments -* Return: {String} +* Returns: {String} The `path.join()` method joins all given `path` segments together using the platform specific separator as a delimiter, then normalizes the resulting path. @@ -312,7 +312,7 @@ added: v0.1.23 --> * `path` {String} -* Return: {String} +* Returns: {String} The `path.normalize()` method normalizes the given `path`, resolving `'..'` and `'.'` segments. @@ -346,7 +346,7 @@ added: v0.11.15 --> * `path` {String} -* Return: {Object} +* Returns: {Object} The `path.parse()` method returns an object whose properties represent significant elements of the `path`. @@ -426,7 +426,7 @@ added: v0.5.0 * `from` {String} * `to` {String} -* Return: {String} +* Returns: {String} The `path.relative()` method returns the relative path from `from` to `to`. If `from` and `to` each resolve to the same path (after calling `path.resolve()` @@ -457,7 +457,7 @@ added: v0.3.4 --> * `...paths` {String} A sequence of paths or path segments -* Return: {String} +* Returns: {String} The `path.resolve()` method resolves a sequence of paths or path segments into an absolute path. diff --git a/doc/api/process.md b/doc/api/process.md index ff32225cc04c65..133a3dd6467038 100644 --- a/doc/api/process.md +++ b/doc/api/process.md @@ -613,7 +613,7 @@ added: v6.1.0 * `previousValue` {Object} A previous return value from calling `process.cpuUsage()` -* Return: {Object} +* Returns: {Object} * `user` {Integer} * `system` {Integer} @@ -643,7 +643,7 @@ console.log(process.cpuUsage(startUsage)); added: v0.1.8 --> -* Return: {String} +* Returns: {String} The `process.cwd()` method returns the current working directory of the Node.js process. @@ -984,7 +984,7 @@ or Android) added: v2.0.0 --> -* Return: {Object} +* Returns: {Object} The `process.geteuid()` method returns the numerical effective user identity of the process. (See geteuid(2).) @@ -1003,7 +1003,7 @@ Android) added: v0.1.31 --> -* Return: {Object} +* Returns: {Object} The `process.getgid()` method returns the numerical group identity of the process. (See getgid(2).) @@ -1023,7 +1023,7 @@ Android) added: v0.9.4 --> -* Return: {Array} +* Returns: {Array} The `process.getgroups()` method returns an array with the supplementary group IDs. POSIX leaves it unspecified if the effective group ID is included but @@ -1037,7 +1037,7 @@ Android) added: v0.1.28 --> -* Return: {Integer} +* Returns: {Integer} The `process.getuid()` method returns the numeric user identity of the process. (See getuid(2).) @@ -1171,7 +1171,7 @@ is no entry script. added: v0.1.16 --> -* Return: {Object} +* Returns: {Object} * `rss` {Integer} * `heapTotal` {Integer} * `heapUsed` {Integer} @@ -1367,7 +1367,7 @@ added: v0.5.9 * `sendHandle` {Handle object} * `options` {Object} * `callback` {Function} -* Return: {Boolean} +* Returns: {Boolean} If Node.js is spawned with an IPC channel, the `process.send()` method can be used to send messages to the parent process. Messages will be received as a @@ -1661,7 +1661,7 @@ console.log( added: v0.5.0 --> -* Return: {Number} +* Returns: {Number} The `process.uptime()` method returns the number of seconds the current Node.js process has been running. diff --git a/doc/api/stream.md b/doc/api/stream.md index 6b12ea8ee0a981..cf31436f39f443 100644 --- a/doc/api/stream.md +++ b/doc/api/stream.md @@ -381,7 +381,7 @@ added: v0.11.15 --> * `encoding` {String} The new default encoding -* Return: `this` +* Returns: `this` The `writable.setDefaultEncoding()` method sets the default `encoding` for a [Writable][] stream. @@ -689,7 +689,7 @@ preferred over the use of the `'readable'` event. added: v0.11.14 --> -* Return: {Boolean} +* Returns: {Boolean} The `readable.isPaused()` method returns the current operating state of the Readable. This is used primarily by the mechanism that underlies the @@ -711,7 +711,7 @@ readable.isPaused() // === false added: v0.9.4 --> -* Return: `this` +* Returns: `this` The `readable.pause()` method will cause a stream in flowing mode to stop emitting [`'data'`][] events, switching out of flowing mode. Any data that @@ -843,7 +843,7 @@ event has been emitted will return `null`. No runtime error will be raised. added: v0.9.4 --> -* Return: `this` +* Returns: `this` The `readable.resume()` method causes an explicitly paused Readable stream to resume emitting [`'data'`][] events, switching the stream into flowing mode. @@ -866,7 +866,7 @@ added: v0.9.4 --> * `encoding` {String} The encoding to use. -* Return: `this` +* Returns: `this` The `readable.setEncoding()` method sets the default character encoding for data read from the Readable stream. From d83cb48b3a2059abec3cfb800a65aa5c013d2be0 Mon Sep 17 00:00:00 2001 From: Daijiro Yamada Date: Sat, 12 Nov 2016 16:24:46 +0900 Subject: [PATCH 038/104] doc: fix typo e.g., => e.g. Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9563 Reviewed-By: Yosuke Furukawa Reviewed-By: Roman Reiss Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- doc/api/dns.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/api/dns.md b/doc/api/dns.md index 95592f9cc3f144..bfb0074e3c68e4 100644 --- a/doc/api/dns.md +++ b/doc/api/dns.md @@ -260,7 +260,7 @@ added: v0.1.90 Uses the DNS protocol to resolve name server records (`NS` records) for the `hostname`. The `addresses` argument passed to the `callback` function will contain an array of name server records available for `hostname` -(e.g., `['ns1.example.com', 'ns2.example.com']`). +(e.g. `['ns1.example.com', 'ns2.example.com']`). ## dns.resolveSoa(hostname, callback) From 7af680e6fe531e06792ae2c0dbdf8d7c5c7243c4 Mon Sep 17 00:00:00 2001 From: Daniel Bevenius Date: Tue, 8 Nov 2016 21:04:57 +0100 Subject: [PATCH 054/104] doc: make comment indentation consistent MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, some of the docs use different indentation for comments in the code examples. This commit makes the indentation consistent by putting the comments at the beginning of the line (really no indentation that is). PR-URL: https://github.com/nodejs/node/pull/9518 Reviewed-By: Teddy Katz Reviewed-By: Roman Reiss Reviewed-By: Michaël Zasso --- doc/api/addons.md | 42 ++++++++++------ doc/api/assert.md | 96 +++++++++++++++++++----------------- doc/api/buffer.md | 16 +++--- doc/api/console.md | 52 ++++++++++---------- doc/api/crypto.md | 30 ++++++------ doc/api/dns.md | 2 +- doc/api/errors.md | 2 +- doc/api/events.md | 62 +++++++++++------------ doc/api/fs.md | 26 +++++----- doc/api/globals.md | 4 +- doc/api/path.md | 64 ++++++++++++------------ doc/api/process.md | 10 ++-- doc/api/stream.md | 6 +-- doc/api/util.md | 120 ++++++++++++++++++++++----------------------- 14 files changed, 277 insertions(+), 255 deletions(-) diff --git a/doc/api/addons.md b/doc/api/addons.md index 1dfdf8e3bb057a..d91f60ae7bf6ef 100644 --- a/doc/api/addons.md +++ b/doc/api/addons.md @@ -140,7 +140,8 @@ Once built, the binary Addon can be used from within Node.js by pointing // hello.js const addon = require('./build/Release/addon'); -console.log(addon.hello()); // 'world' +console.log(addon.hello()); +// Prints: 'world' ``` Please see the examples below for further information or @@ -372,7 +373,8 @@ To test it, run the following JavaScript: const addon = require('./build/Release/addon'); addon((msg) => { - console.log(msg); // 'hello world' + console.log(msg); +// Prints: 'hello world' }); ``` @@ -423,7 +425,8 @@ const addon = require('./build/Release/addon'); var obj1 = addon('hello'); var obj2 = addon('world'); -console.log(obj1.msg, obj2.msg); // 'hello world' +console.log(obj1.msg, obj2.msg); +// Prints: 'hello world' ``` @@ -480,7 +483,8 @@ To test: const addon = require('./build/Release/addon'); var fn = addon(); -console.log(fn()); // 'hello world' +console.log(fn()); +// Prints: 'hello world' ``` @@ -642,9 +646,12 @@ Test it with: const addon = require('./build/Release/addon'); var obj = new addon.MyObject(10); -console.log(obj.plusOne()); // 11 -console.log(obj.plusOne()); // 12 -console.log(obj.plusOne()); // 13 +console.log(obj.plusOne()); +// Prints: 11 +console.log(obj.plusOne()); +// Prints: 12 +console.log(obj.plusOne()); +// Prints: 13 ``` ### Factory of wrapped objects @@ -834,14 +841,20 @@ Test it with: const createObject = require('./build/Release/addon'); var obj = createObject(10); -console.log(obj.plusOne()); // 11 -console.log(obj.plusOne()); // 12 -console.log(obj.plusOne()); // 13 +console.log(obj.plusOne()); +// Prints: 11 +console.log(obj.plusOne()); +// Prints: 12 +console.log(obj.plusOne()); +// Prints: 13 var obj2 = createObject(20); -console.log(obj2.plusOne()); // 21 -console.log(obj2.plusOne()); // 22 -console.log(obj2.plusOne()); // 23 +console.log(obj2.plusOne()); +// Prints: 21 +console.log(obj2.plusOne()); +// Prints: 22 +console.log(obj2.plusOne()); +// Prints: 23 ``` @@ -1013,7 +1026,8 @@ var obj1 = addon.createObject(10); var obj2 = addon.createObject(20); var result = addon.add(obj1, obj2); -console.log(result); // 30 +console.log(result); +// Prints: 30 ``` ### AtExit hooks diff --git a/doc/api/assert.md b/doc/api/assert.md index ed7080323841fa..066a72215c658f 100644 --- a/doc/api/assert.md +++ b/doc/api/assert.md @@ -22,14 +22,16 @@ An alias of [`assert.ok()`][] . ```js const assert = require('assert'); -assert(true); // OK -assert(1); // OK +assert(true); +// OK +assert(1); +// OK assert(false); - // throws "AssertionError: false == true" +// throws "AssertionError: false == true" assert(0); - // throws "AssertionError: 0 == true" +// throws "AssertionError: 0 == true" assert(false, 'it\'s false'); - // throws "AssertionError: it's false" +// throws "AssertionError: it's false" ``` ## assert.deepEqual(actual, expected[, message]) @@ -75,18 +77,18 @@ const obj3 = { const obj4 = Object.create(obj1); assert.deepEqual(obj1, obj1); - // OK, object is equal to itself +// OK, object is equal to itself assert.deepEqual(obj1, obj2); - // AssertionError: { a: { b: 1 } } deepEqual { a: { b: 2 } } - // values of b are different +// AssertionError: { a: { b: 1 } } deepEqual { a: { b: 2 } } +// values of b are different assert.deepEqual(obj1, obj3); - // OK, objects are equal +// OK, objects are equal assert.deepEqual(obj1, obj4); - // AssertionError: { a: { b: 1 } } deepEqual {} - // Prototypes are ignored +// AssertionError: { a: { b: 1 } } deepEqual {} +// Prototypes are ignored ``` If the values are not equal, an `AssertionError` is thrown with a `message` @@ -106,11 +108,11 @@ Second, object comparisons include a strict equality check of their prototypes. const assert = require('assert'); assert.deepEqual({a:1}, {a:'1'}); - // OK, because 1 == '1' +// OK, because 1 == '1' assert.deepStrictEqual({a:1}, {a:'1'}); - // AssertionError: { a: 1 } deepStrictEqual { a: '1' } - // because 1 !== '1' using strict equality +// AssertionError: { a: 1 } deepStrictEqual { a: '1' } +// because 1 !== '1' using strict equality ``` If the values are not equal, an `AssertionError` is thrown with a `message` @@ -184,14 +186,14 @@ using the equal comparison operator ( `==` ). const assert = require('assert'); assert.equal(1, 1); - // OK, 1 == 1 +// OK, 1 == 1 assert.equal(1, '1'); - // OK, 1 == '1' +// OK, 1 == '1' assert.equal(1, 2); - // AssertionError: 1 == 2 +// AssertionError: 1 == 2 assert.equal({a: {b: 1}}, {a: {b: 1}}); - //AssertionError: { a: { b: 1 } } == { a: { b: 1 } } +//AssertionError: { a: { b: 1 } } == { a: { b: 1 } } ``` If the values are not equal, an `AssertionError` is thrown with a `message` @@ -211,10 +213,10 @@ Otherwise, the error message is the value of `message`. const assert = require('assert'); assert.fail(1, 2, undefined, '>'); - // AssertionError: 1 > 2 +// AssertionError: 1 > 2 assert.fail(1, 2, 'whoops', '>'); - // AssertionError: whoops +// AssertionError: whoops ``` ## assert.ifError(value) @@ -228,10 +230,14 @@ argument in callbacks. ```js const assert = require('assert'); -assert.ifError(0); // OK -assert.ifError(1); // Throws 1 -assert.ifError('error'); // Throws 'error' -assert.ifError(new Error()); // Throws Error +assert.ifError(0); +// OK +assert.ifError(1); +// Throws 1 +assert.ifError('error'); +// Throws 'error' +assert.ifError(new Error()); +// Throws Error ``` ## assert.notDeepEqual(actual, expected[, message]) @@ -262,16 +268,16 @@ const obj3 = { const obj4 = Object.create(obj1); assert.notDeepEqual(obj1, obj1); - // AssertionError: { a: { b: 1 } } notDeepEqual { a: { b: 1 } } +// AssertionError: { a: { b: 1 } } notDeepEqual { a: { b: 1 } } assert.notDeepEqual(obj1, obj2); - // OK, obj1 and obj2 are not deeply equal +// OK, obj1 and obj2 are not deeply equal assert.notDeepEqual(obj1, obj3); - // AssertionError: { a: { b: 1 } } notDeepEqual { a: { b: 1 } } +// AssertionError: { a: { b: 1 } } notDeepEqual { a: { b: 1 } } assert.notDeepEqual(obj1, obj4); - // OK, obj1 and obj4 are not deeply equal +// OK, obj1 and obj2 are not deeply equal ``` If the values are deeply equal, an `AssertionError` is thrown with a `message` @@ -289,10 +295,10 @@ Tests for deep strict inequality. Opposite of [`assert.deepStrictEqual()`][]. const assert = require('assert'); assert.notDeepEqual({a:1}, {a:'1'}); - // AssertionError: { a: 1 } notDeepEqual { a: '1' } +// AssertionError: { a: 1 } notDeepEqual { a: '1' } assert.notDeepStrictEqual({a:1}, {a:'1'}); - // OK +// OK ``` If the values are deeply and strictly equal, an `AssertionError` is thrown @@ -311,13 +317,13 @@ Tests shallow, coercive inequality with the not equal comparison operator const assert = require('assert'); assert.notEqual(1, 2); - // OK +// OK assert.notEqual(1, 1); - // AssertionError: 1 != 1 +// AssertionError: 1 != 1 assert.notEqual(1, '1'); - // AssertionError: 1 != '1' +// AssertionError: 1 != '1' ``` If the values are equal, an `AssertionError` is thrown with a `message` @@ -336,13 +342,13 @@ Tests strict inequality as determined by the strict not equal operator const assert = require('assert'); assert.notStrictEqual(1, 2); - // OK +// OK assert.notStrictEqual(1, 1); - // AssertionError: 1 != 1 +// AssertionError: 1 != 1 assert.notStrictEqual(1, '1'); - // OK +// OK ``` If the values are strictly equal, an `AssertionError` is thrown with a @@ -364,14 +370,16 @@ parameter is `undefined`, a default error message is assigned. ```js const assert = require('assert'); -assert.ok(true); // OK -assert.ok(1); // OK +assert.ok(true); +// OK +assert.ok(1); +// OK assert.ok(false); - // throws "AssertionError: false == true" +// throws "AssertionError: false == true" assert.ok(0); - // throws "AssertionError: 0 == true" +// throws "AssertionError: 0 == true" assert.ok(false, 'it\'s false'); - // throws "AssertionError: it's false" +// throws "AssertionError: it's false" ``` ## assert.strictEqual(actual, expected[, message]) @@ -385,13 +393,13 @@ Tests strict equality as determined by the strict equality operator ( `===` ). const assert = require('assert'); assert.strictEqual(1, 2); - // AssertionError: 1 === 2 +// AssertionError: 1 === 2 assert.strictEqual(1, 1); - // OK +// OK assert.strictEqual(1, '1'); - // AssertionError: 1 === '1' +// AssertionError: 1 === '1' ``` If the values are not strictly equal, an `AssertionError` is thrown with a diff --git a/doc/api/buffer.md b/doc/api/buffer.md index 810f06825fd087..093be3f09e9232 100644 --- a/doc/api/buffer.md +++ b/doc/api/buffer.md @@ -406,7 +406,7 @@ Example: ```js const buf = new Buffer(5); -// Prints (contents may vary): +// Prints: (contents may vary): console.log(buf); buf.fill(0); @@ -525,7 +525,7 @@ Example: ```js const buf = Buffer.allocUnsafe(5); -// Prints (contents may vary): +// Prints: (contents may vary): console.log(buf); buf.fill(0); @@ -1755,12 +1755,12 @@ Examples: ```js const buf1 = Buffer.from([0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8]); -// Prints +// Prints: console.log(buf1); buf1.swap32(); -// Prints +// Prints: console.log(buf1); @@ -1785,12 +1785,12 @@ Examples: ```js const buf1 = Buffer.from([0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8]); -// Prints +// Prints: console.log(buf1); buf1.swap64(); -// Prints +// Prints: console.log(buf1); @@ -2327,7 +2327,7 @@ sequence cannot be adequately represented in the target encoding. For instance: ```js const newBuf = buffer.transcode(Buffer.from('€'), 'utf8', 'ascii'); console.log(newBuf.toString('ascii')); - // prints '?' +// Prints: '?' ``` Because the Euro (`€`) sign is not representable in US-ASCII, it is replaced @@ -2397,7 +2397,7 @@ const SlowBuffer = require('buffer').SlowBuffer; const buf = new SlowBuffer(5); -// Prints (contents may vary): +// Prints: (contents may vary): console.log(buf); buf.fill(0); diff --git a/doc/api/console.md b/doc/api/console.md index 7b8d893197473f..054eacc2bc7f82 100644 --- a/doc/api/console.md +++ b/doc/api/console.md @@ -17,15 +17,15 @@ Example using the global `console`: ```js console.log('hello world'); - // Prints: hello world, to stdout +// Prints: hello world, to stdout console.log('hello %s', 'world'); - // Prints: hello world, to stdout +// Prints: hello world, to stdout console.error(new Error('Whoops, something bad happened')); - // Prints: [Error: Whoops, something bad happened], to stderr +// Prints: [Error: Whoops, something bad happened], to stderr const name = 'Will Robinson'; console.warn(`Danger ${name}! Danger!`); - // Prints: Danger Will Robinson! Danger!, to stderr +// Prints: Danger Will Robinson! Danger!, to stderr ``` Example using the `Console` class: @@ -36,15 +36,15 @@ const err = getStreamSomehow(); const myConsole = new console.Console(out, err); myConsole.log('hello world'); - // Prints: hello world, to out +// Prints: hello world, to out myConsole.log('hello %s', 'world'); - // Prints: hello world, to out +// Prints: hello world, to out myConsole.error(new Error('Whoops, something bad happened')); - // Prints: [Error: Whoops, something bad happened], to err +// Prints: [Error: Whoops, something bad happened], to err const name = 'Will Robinson'; myConsole.warn(`Danger ${name}! Danger!`); - // Prints: Danger Will Robinson! Danger!, to err +// Prints: Danger Will Robinson! Danger!, to err ``` While the API for the `Console` class is designed fundamentally around the @@ -111,9 +111,9 @@ using [`util.format()`][] and used as the error message. ```js console.assert(true, 'does nothing'); - // OK +// OK console.assert(false, 'Whoops %s', 'didn\'t work'); - // AssertionError: Whoops didn't work +// AssertionError: Whoops didn't work ``` *Note: the `console.assert()` method is implemented differently in Node.js @@ -190,9 +190,9 @@ values similar to `printf(3)` (the arguments are all passed to ```js const code = 5; console.error('error #%d', code); - // Prints: error #5, to stderr +// Prints: error #5, to stderr console.error('error', code); - // Prints: error 5, to stderr +// Prints: error 5, to stderr ``` If formatting elements (e.g. `%d`) are not found in the first string then @@ -219,9 +219,9 @@ values similar to `printf(3)` (the arguments are all passed to ```js var count = 5; console.log('count: %d', count); - // Prints: count: 5, to stdout +// Prints: count: 5, to stdout console.log('count:', count); - // Prints: count: 5, to stdout +// Prints: count: 5, to stdout ``` If formatting elements (e.g. `%d`) are not found in the first string then @@ -270,18 +270,18 @@ formatted message and stack trace to the current position in the code. ```js console.trace('Show me'); - // Prints: (stack trace will vary based on where trace is called) - // Trace: Show me - // at repl:2:9 - // at REPLServer.defaultEval (repl.js:248:27) - // at bound (domain.js:287:14) - // at REPLServer.runBound [as eval] (domain.js:300:12) - // at REPLServer. (repl.js:412:12) - // at emitOne (events.js:82:20) - // at REPLServer.emit (events.js:169:7) - // at REPLServer.Interface._onLine (readline.js:210:10) - // at REPLServer.Interface._line (readline.js:549:8) - // at REPLServer.Interface._ttyWrite (readline.js:826:14) +// Prints: (stack trace will vary based on where trace is called) +// Trace: Show me +// at repl:2:9 +// at REPLServer.defaultEval (repl.js:248:27) +// at bound (domain.js:287:14) +// at REPLServer.runBound [as eval] (domain.js:300:12) +// at REPLServer. (repl.js:412:12) +// at emitOne (events.js:82:20) +// at REPLServer.emit (events.js:169:7) +// at REPLServer.Interface._onLine (readline.js:210:10) +// at REPLServer.Interface._line (readline.js:549:8) +// at REPLServer.Interface._ttyWrite (readline.js:826:14) ``` ### console.warn([data][, ...args]) diff --git a/doc/api/crypto.md b/doc/api/crypto.md index 0f063157b7160a..7eddf0da2c1c81 100644 --- a/doc/api/crypto.md +++ b/doc/api/crypto.md @@ -15,8 +15,8 @@ const hash = crypto.createHmac('sha256', secret) .update('I love cupcakes') .digest('hex'); console.log(hash); - // Prints: - // c0fa1bc00531bd78ef38c628449c5102aeabd49b5dc3a2a516ea6ea959d6658e +// Prints: +// c0fa1bc00531bd78ef38c628449c5102aeabd49b5dc3a2a516ea6ea959d6658e ``` ## Determining if crypto support is unavailable @@ -73,7 +73,7 @@ const cert = require('crypto').Certificate(); const spkac = getSpkacSomehow(); const challenge = cert.exportChallenge(spkac); console.log(challenge.toString('utf8')); - // Prints the challenge as a UTF8 string +// Prints: the challenge as a UTF8 string ``` ### certificate.exportPublicKey(spkac) @@ -91,7 +91,7 @@ const cert = require('crypto').Certificate(); const spkac = getSpkacSomehow(); const publicKey = cert.exportPublicKey(spkac); console.log(publicKey); - // Prints the public key as +// Prints: the public key as ``` ### certificate.verifySpkac(spkac) @@ -106,7 +106,7 @@ The `spkac` argument must be a Node.js [`Buffer`][]. const cert = require('crypto').Certificate(); const spkac = getSpkacSomehow(); console.log(cert.verifySpkac(Buffer.from(spkac))); - // Prints true or false +// Prints: true or false ``` ## Class: Cipher @@ -169,7 +169,7 @@ const cipher = crypto.createCipher('aes192', 'a password'); var encrypted = cipher.update('some clear text data', 'utf8', 'hex'); encrypted += cipher.final('hex'); console.log(encrypted); - // Prints: ca981be48e90867604588e75d04feabb63cc007a8f8ad89b10616ed84d815504 +// Prints: ca981be48e90867604588e75d04feabb63cc007a8f8ad89b10616ed84d815504 ``` ### cipher.final([output_encoding]) @@ -304,7 +304,7 @@ var encrypted = 'ca981be48e90867604588e75d04feabb63cc007a8f8ad89b10616ed84d81550 var decrypted = decipher.update(encrypted, 'hex', 'utf8'); decrypted += decipher.final('utf8'); console.log(decrypted); - // Prints: some clear text data +// Prints: some clear text data ``` ### decipher.final([output_encoding]) @@ -700,8 +700,8 @@ const hash = crypto.createHash('sha256'); hash.update('some data to hash'); console.log(hash.digest('hex')); - // Prints: - // 6a2da20943931e9834fc12cfe5bb47bbd9ae43489a30726962b576f4e3993e50 +// Prints: +// 6a2da20943931e9834fc12cfe5bb47bbd9ae43489a30726962b576f4e3993e50 ``` ### hash.digest([encoding]) @@ -783,8 +783,8 @@ const hmac = crypto.createHmac('sha256', 'a secret'); hmac.update('some data to hash'); console.log(hmac.digest('hex')); - // Prints: - // 7fd04df92f636fd450bc841c9418e5825c17f33ad9c87c518115a45971f7f77e +// Prints: +// 7fd04df92f636fd450bc841c9418e5825c17f33ad9c87c518115a45971f7f77e ``` ### hmac.digest([encoding]) @@ -839,7 +839,7 @@ sign.end(); const private_key = getPrivateKeySomehow(); console.log(sign.sign(private_key, 'hex')); - // Prints the calculated signature +// Prints: the calculated signature ``` Example: Using the [`sign.update()`][] and [`sign.sign()`][] methods: @@ -852,7 +852,7 @@ sign.update('some data to sign'); const private_key = getPrivateKeySomehow(); console.log(sign.sign(private_key, 'hex')); - // Prints the calculated signature +// Prints: the calculated signature ``` A `Sign` instance can also be created by just passing in the digest @@ -940,7 +940,7 @@ verify.end(); const public_key = getPublicKeySomehow(); const signature = getSignatureToVerify(); console.log(verify.verify(public_key, signature)); - // Prints true or false +// Prints: true or false ``` Example: Using the [`verify.update()`][] and [`verify.verify()`][] methods: @@ -954,7 +954,7 @@ verify.update('some data to sign'); const public_key = getPublicKeySomehow(); const signature = getSignatureToVerify(); console.log(verify.verify(public_key, signature)); - // Prints true or false +// Prints: true or false ``` ### verifier.update(data[, input_encoding]) diff --git a/doc/api/dns.md b/doc/api/dns.md index bfb0074e3c68e4..e930892cedc927 100644 --- a/doc/api/dns.md +++ b/doc/api/dns.md @@ -148,7 +148,7 @@ On error, `err` is an [`Error`][] object, where `err.code` is the error code. const dns = require('dns'); dns.lookupService('127.0.0.1', 22, (err, hostname, service) => { console.log(hostname, service); - // Prints: localhost ssh + // Prints: localhost ssh }); ``` diff --git a/doc/api/errors.md b/doc/api/errors.md index 28f1858a1ded57..70588125a0f0c9 100644 --- a/doc/api/errors.md +++ b/doc/api/errors.md @@ -258,7 +258,7 @@ the stack trace of the `Error`, however changing this property after the ```js const err = new Error('The message'); console.log(err.message); - // Prints: The message +// Prints: The message ``` #### error.stack diff --git a/doc/api/events.md b/doc/api/events.md index 3cca1ada5b2efa..b468674c3613fa 100644 --- a/doc/api/events.md +++ b/doc/api/events.md @@ -51,12 +51,12 @@ listener is attached. const myEmitter = new MyEmitter(); myEmitter.on('event', function(a, b) { console.log(a, b, this); - // Prints: - // a b MyEmitter { - // domain: null, - // _events: { event: [Function] }, - // _eventsCount: 1, - // _maxListeners: undefined } + // Prints: + // a b MyEmitter { + // domain: null, + // _events: { event: [Function] }, + // _eventsCount: 1, + // _maxListeners: undefined } }); myEmitter.emit('event', 'a', 'b'); ``` @@ -68,7 +68,7 @@ the `this` keyword will no longer reference the `EventEmitter` instance: const myEmitter = new MyEmitter(); myEmitter.on('event', (a, b) => { console.log(a, b, this); - // Prints: a b {} + // Prints: a b {} }); myEmitter.emit('event', 'a', 'b'); ``` @@ -103,9 +103,9 @@ myEmitter.on('event', () => { console.log(++m); }); myEmitter.emit('event'); - // Prints: 1 +// Prints: 1 myEmitter.emit('event'); - // Prints: 2 +// Prints: 2 ``` Using the `eventEmitter.once()` method, it is possible to register a listener @@ -119,9 +119,9 @@ myEmitter.once('event', () => { console.log(++m); }); myEmitter.emit('event'); - // Prints: 1 +// Prints: 1 myEmitter.emit('event'); - // Ignored +// Ignored ``` ## Error events @@ -137,7 +137,7 @@ stack trace is printed, and the Node.js process exits. ```js const myEmitter = new MyEmitter(); myEmitter.emit('error', new Error('whoops!')); - // Throws and crashes Node.js +// Throws and crashes Node.js ``` To guard against crashing the Node.js process, a listener can be registered @@ -152,7 +152,7 @@ process.on('uncaughtException', (err) => { }); myEmitter.emit('error', new Error('whoops!')); - // Prints: whoops! there was an error +// Prints: whoops! there was an error ``` As a best practice, listeners should always be added for the `'error'` events. @@ -163,7 +163,7 @@ myEmitter.on('error', (err) => { console.log('whoops! there was an error'); }); myEmitter.emit('error', new Error('whoops!')); - // Prints: whoops! there was an error +// Prints: whoops! there was an error ``` ## Class: EventEmitter @@ -214,9 +214,9 @@ myEmitter.on('event', () => { console.log('A'); }); myEmitter.emit('event'); - // Prints: - // B - // A +// Prints: +// B +// A ``` ### Event: 'removeListener' @@ -245,7 +245,7 @@ const myEmitter = new MyEmitter(); myEmitter.on('event', () => {}); myEmitter.on('event', () => {}); console.log(EventEmitter.listenerCount(myEmitter, 'event')); - // Prints: 2 +// Prints: 2 ``` ### EventEmitter.defaultMaxListeners @@ -323,7 +323,7 @@ const sym = Symbol('symbol'); myEE.on(sym, () => {}); console.log(myEE.eventNames()); - // Prints [ 'foo', 'bar', Symbol(symbol) ] +// Prints: [ 'foo', 'bar', Symbol(symbol) ] ``` ### emitter.getMaxListeners() @@ -356,7 +356,7 @@ server.on('connection', (stream) => { console.log('someone connected!'); }); console.log(util.inspect(server.listeners('connection'))); - // Prints: [ [Function] ] +// Prints: [ [Function] ] ``` ### emitter.on(eventName, listener) @@ -390,9 +390,9 @@ const myEE = new EventEmitter(); myEE.on('foo', () => console.log('a')); myEE.prependListener('foo', () => console.log('b')); myEE.emit('foo'); - // Prints: - // b - // a +// Prints: +// b +// a ``` ### emitter.once(eventName, listener) @@ -423,9 +423,9 @@ const myEE = new EventEmitter(); myEE.once('foo', () => console.log('a')); myEE.prependOnceListener('foo', () => console.log('b')); myEE.emit('foo'); - // Prints: - // b - // a +// Prints: +// b +// a ``` ### emitter.prependListener(eventName, listener) @@ -530,15 +530,15 @@ myEmitter.on('event', callbackB); // callbackA removes listener callbackB but it will still be called. // Internal listener array at time of emit [callbackA, callbackB] myEmitter.emit('event'); - // Prints: - // A - // B +// Prints: +// A +// B // callbackB is now removed. // Internal listener array [callbackA] myEmitter.emit('event'); - // Prints: - // A +// Prints: +// A ``` diff --git a/doc/api/fs.md b/doc/api/fs.md index af1f2d6381e6c1..2786c64c2942be 100644 --- a/doc/api/fs.md +++ b/doc/api/fs.md @@ -918,7 +918,7 @@ For example, the following program retains only the first four bytes of the file ```js console.log(fs.readFileSync('temp.txt', 'utf8')); - // prints Node.js +// Prints: Node.js // get the file descriptor of the file to be truncated const fd = fs.openSync('temp.txt', 'r+'); @@ -928,7 +928,7 @@ fs.ftruncate(fd, 4, (err) => { assert.ifError(err); console.log(fs.readFileSync('temp.txt', 'utf8')); }); - // prints Node +// Prints: Node ``` If the file previously was shorter than `len` bytes, it is extended, and the @@ -936,7 +936,7 @@ extended part is filled with null bytes ('\0'). For example, ```js console.log(fs.readFileSync('temp.txt', 'utf-8')); - // prints Node.js +// Prints: Node.js // get the file descriptor of the file to be truncated const fd = fs.openSync('temp.txt', 'r+'); @@ -946,8 +946,8 @@ fs.ftruncate(fd, 10, (err) => { assert.ifError(!err); console.log(fs.readFileSync('temp.txt')); }); - // prints - // ('Node.js\0\0\0' in UTF8) +// Prints: +// ('Node.js\0\0\0' in UTF8) ``` The last three bytes are null bytes ('\0'), to compensate the over-truncation. @@ -1127,7 +1127,7 @@ Example: fs.mkdtemp('/tmp/foo-', (err, folder) => { if (err) throw err; console.log(folder); - // Prints: /tmp/foo-itXde2 + // Prints: /tmp/foo-itXde2 }); ``` @@ -1145,10 +1145,10 @@ const tmpDir = '/tmp'; fs.mkdtemp(tmpDir, (err, folder) => { if (err) throw err; console.log(folder); - // Will print something similar to `/tmpabc123`. - // Note that a new temporary directory is created - // at the file system root rather than *within* - // the /tmp directory. + // Will print something similar to `/tmpabc123`. + // Note that a new temporary directory is created + // at the file system root rather than *within* + // the /tmp directory. }); // This method is *CORRECT*: @@ -1156,9 +1156,9 @@ const path = require('path'); fs.mkdtemp(tmpDir + path.sep, (err, folder) => { if (err) throw err; console.log(folder); - // Will print something similar to `/tmp/abc123`. - // A new temporary directory is created within - // the /tmp directory. + // Will print something similar to `/tmp/abc123`. + // A new temporary directory is created within + // the /tmp directory. }); ``` diff --git a/doc/api/globals.md b/doc/api/globals.md index 885e2e09fc8879..ca96ec4478d6ca 100644 --- a/doc/api/globals.md +++ b/doc/api/globals.md @@ -35,7 +35,7 @@ Example: running `node example.js` from `/Users/mjr` ```js console.log(__dirname); -// /Users/mjr +// Prints: /Users/mjr ``` `__dirname` isn't actually a global but rather local to each module. @@ -68,7 +68,7 @@ Example: running `node example.js` from `/Users/mjr` ```js console.log(__filename); -// /Users/mjr/example.js +// Prints: /Users/mjr/example.js ``` `__filename` isn't actually a global but rather local to each module. diff --git a/doc/api/path.md b/doc/api/path.md index 45dac1069ce8c5..fdd3063e69bf81 100644 --- a/doc/api/path.md +++ b/doc/api/path.md @@ -24,14 +24,14 @@ On POSIX: ```js path.basename('C:\\temp\\myfile.html'); - // returns 'C:\temp\myfile.html' +// Returns: 'C:\temp\myfile.html' ``` On Windows: ```js path.basename('C:\\temp\\myfile.html'); - // returns 'myfile.html' +// Returns: 'myfile.html' ``` To achieve consistent results when working with Windows file paths on any @@ -41,7 +41,7 @@ On POSIX and Windows: ```js path.win32.basename('C:\\temp\\myfile.html'); - // returns 'myfile.html' +// Returns: 'myfile.html' ``` To achieve consistent results when working with POSIX file paths on any @@ -51,7 +51,7 @@ On POSIX and Windows: ```js path.posix.basename('/tmp/myfile.html'); - // returns 'myfile.html' +// Returns: 'myfile.html' ``` ## path.basename(path[, ext]) @@ -70,10 +70,10 @@ For example: ```js path.basename('/foo/bar/baz/asdf/quux.html') - // returns 'quux.html' +// Returns: 'quux.html' path.basename('/foo/bar/baz/asdf/quux.html', '.html') - // returns 'quux' +// Returns: 'quux' ``` A [`TypeError`][] is thrown if `path` is not a string or if `ext` is given @@ -95,20 +95,20 @@ For example, on POSIX: ```js console.log(process.env.PATH) -// '/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin' +// Prints: '/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin' process.env.PATH.split(path.delimiter) -// returns ['/usr/bin', '/bin', '/usr/sbin', '/sbin', '/usr/local/bin'] +// Returns: ['/usr/bin', '/bin', '/usr/sbin', '/sbin', '/usr/local/bin'] ``` On Windows: ```js console.log(process.env.PATH) -// 'C:\Windows\system32;C:\Windows;C:\Program Files\node\' +// Prints: 'C:\Windows\system32;C:\Windows;C:\Program Files\node\' process.env.PATH.split(path.delimiter) -// returns ['C:\\Windows\\system32', 'C:\\Windows', 'C:\\Program Files\\node\\'] +// Returns: ['C:\\Windows\\system32', 'C:\\Windows', 'C:\\Program Files\\node\\'] ``` ## path.dirname(path) @@ -126,7 +126,7 @@ For example: ```js path.dirname('/foo/bar/baz/asdf/quux') -// returns '/foo/bar/baz/asdf' +// Returns: '/foo/bar/baz/asdf' ``` A [`TypeError`][] is thrown if `path` is not a string. @@ -149,19 +149,19 @@ For example: ```js path.extname('index.html') -// returns '.html' +// Returns: '.html' path.extname('index.coffee.md') -// returns '.md' +// Returns: '.md' path.extname('index.') -// returns '.' +// Returns: '.' path.extname('index') -// returns '' +// Returns: '' path.extname('.index') -// returns '' +// Returns: '' ``` A [`TypeError`][] is thrown if `path` is not a string. @@ -205,7 +205,7 @@ path.format({ dir: '/home/user/dir', base: 'file.txt' }); -// returns '/home/user/dir/file.txt' +// Returns: '/home/user/dir/file.txt' // `root` will be used if `dir` is not specified. // If only `root` is provided or `dir` is equal to `root` then the @@ -214,7 +214,7 @@ path.format({ root: '/', base: 'file.txt' }); -// returns '/file.txt' +// Returns: '/file.txt' // `name` + `ext` will be used if `base` is not specified. path.format({ @@ -222,13 +222,13 @@ path.format({ name: 'file', ext: '.txt' }); -// returns '/file.txt' +// Returns: '/file.txt' // `base` will be returned if `dir` or `root` are not provided. path.format({ base: 'file.txt' }); -// returns 'file.txt' +// Returns: 'file.txt' ``` On Windows: @@ -241,7 +241,7 @@ path.format({ ext : ".txt", name : "file" }); -// returns 'C:\\path\\dir\\file.txt' +// Returns: 'C:\\path\\dir\\file.txt' ``` ## path.isAbsolute(path) @@ -298,7 +298,7 @@ For example: ```js path.join('/foo', 'bar', 'baz/asdf', 'quux', '..') -// returns '/foo/bar/baz/asdf' +// Returns: '/foo/bar/baz/asdf' path.join('foo', {}, 'bar') // throws TypeError: Arguments to path.join must be strings @@ -328,14 +328,14 @@ For example on POSIX: ```js path.normalize('/foo/bar//baz/asdf/quux/..') -// returns '/foo/bar/baz/asdf' +// Returns: '/foo/bar/baz/asdf' ``` On Windows: ```js path.normalize('C:\\temp\\\\foo\\bar\\..\\'); -// returns 'C:\\temp\\foo\\' +// Returns: 'C:\\temp\\foo\\' ``` A [`TypeError`][] is thrown if `path` is not a string. @@ -363,7 +363,7 @@ For example on POSIX: ```js path.parse('/home/user/dir/file.txt') -// returns +// Returns: // { // root : "/", // dir : "/home/user/dir", @@ -387,7 +387,7 @@ On Windows: ```js path.parse('C:\\path\\dir\\file.txt') -// returns +// Returns: // { // root : "C:\\", // dir : "C:\\path\\dir", @@ -439,14 +439,14 @@ For example on POSIX: ```js path.relative('/data/orandea/test/aaa', '/data/orandea/impl/bbb') -// returns '../../impl/bbb' +// Returns: '../../impl/bbb' ``` On Windows: ```js path.relative('C:\\orandea\\test\\aaa', 'C:\\orandea\\impl\\bbb') -// returns '..\\..\\impl\\bbb' +// Returns: '..\\..\\impl\\bbb' ``` A [`TypeError`][] is thrown if neither `from` nor `to` is a string. @@ -482,10 +482,10 @@ For example: ```js path.resolve('/foo/bar', './baz') -// returns '/foo/bar/baz' +// Returns: '/foo/bar/baz' path.resolve('/foo/bar', '/tmp/file/') -// returns '/tmp/file' +// Returns: '/tmp/file' path.resolve('wwwroot', 'static_files/png/', '../gif/image.gif') // if the current working directory is /home/myself/node, @@ -510,14 +510,14 @@ For example on POSIX: ```js 'foo/bar/baz'.split(path.sep) -// returns ['foo', 'bar', 'baz'] +// Returns: ['foo', 'bar', 'baz'] ``` On Windows: ```js 'foo\\bar\\baz'.split(path.sep) -// returns ['foo', 'bar', 'baz'] +// Returns: ['foo', 'bar', 'baz'] ``` ## path.win32 diff --git a/doc/api/process.md b/doc/api/process.md index 44db505eab8e04..18c23dda2de193 100644 --- a/doc/api/process.md +++ b/doc/api/process.md @@ -725,13 +725,13 @@ specific process warnings. These can be listened for by adding a handler to the ```js // Emit a warning using a string... process.emitWarning('Something happened!'); - // Emits: (node: 56338) Warning: Something happened! +// Emits: (node: 56338) Warning: Something happened! ``` ```js // Emit a warning using a string and a name... process.emitWarning('Something Happened!', 'CustomWarning'); - // Emits: (node:56338) CustomWarning: Something Happened! +// Emits: (node:56338) CustomWarning: Something Happened! ``` In each of the previous examples, an `Error` object is generated internally by @@ -756,7 +756,7 @@ const myWarning = new Error('Warning! Something happened!'); myWarning.name = 'CustomWarning'; process.emitWarning(myWarning); - // Emits: (node:56338) CustomWarning: Warning! Something Happened! +// Emits: (node:56338) CustomWarning: Warning! Something Happened! ``` A `TypeError` is thrown if `warning` is anything other than a string or `Error` @@ -789,9 +789,9 @@ function emitMyWarning() { } } emitMyWarning(); - // Emits: (node: 56339) Warning: Only warn once! +// Emits: (node: 56339) Warning: Only warn once! emitMyWarning(); - // Emits nothing +// Emits nothing ``` ## process.execArgv diff --git a/doc/api/stream.md b/doc/api/stream.md index cf31436f39f443..c3544f7939c4c0 100644 --- a/doc/api/stream.md +++ b/doc/api/stream.md @@ -1696,11 +1696,11 @@ myTransform.setEncoding('ascii'); myTransform.on('data', (chunk) => console.log(chunk)); myTransform.write(1); - // Prints: 01 +// Prints: 01 myTransform.write(10); - // Prints: 0a +// Prints: 0a myTransform.write(100); - // Prints: 64 +// Prints: 64 ``` ### Implementing a Transform Stream diff --git a/doc/api/util.md b/doc/api/util.md index 57ed7269f68b87..3e4a4b1d39fd82 100644 --- a/doc/api/util.md +++ b/doc/api/util.md @@ -113,7 +113,7 @@ not replaced. ```js util.format('%s:%s', 'foo'); - // Returns 'foo:%s' +// Returns: 'foo:%s' ``` If there are more arguments passed to the `util.format()` method than the @@ -310,7 +310,7 @@ class Box { const box = new Box(true); util.inspect(box); - // "Box< true >" +// Returns: "Box< true >" ``` Custom `[util.inspect.custom](depth, opts)` functions typically return a string @@ -326,7 +326,7 @@ obj[util.inspect.custom] = function(depth) { }; util.inspect(obj); - // "{ bar: 'baz' }" +// Returns: "{ bar: 'baz' }" ``` A custom inspection method can alternatively be provided by exposing @@ -341,7 +341,7 @@ obj.inspect = function(depth) { }; util.inspect(obj); - // "{ bar: 'baz' }" +// Returns: "{ bar: 'baz' }" ``` ### util.inspect.defaultOptions @@ -419,11 +419,11 @@ Returns `true` if the given `object` is an `Array`. Otherwise, returns `false`. const util = require('util'); util.isArray([]); - // true +// Returns: true util.isArray(new Array); - // true +// Returns: true util.isArray({}); - // false +// Returns: false ``` ### util.isBoolean(object) @@ -442,11 +442,11 @@ Returns `true` if the given `object` is a `Boolean`. Otherwise, returns `false`. const util = require('util'); util.isBoolean(1); - // false +// Returns: false util.isBoolean(0); - // false +// Returns: false util.isBoolean(false); - // true +// Returns: true ``` ### util.isBuffer(object) @@ -465,11 +465,11 @@ Returns `true` if the given `object` is a `Buffer`. Otherwise, returns `false`. const util = require('util'); util.isBuffer({ length: 0 }); - // false +// Returns: false util.isBuffer([]); - // false +// Returns: false util.isBuffer(Buffer.from('hello world')); - // true +// Returns: true ``` ### util.isDate(object) @@ -488,11 +488,11 @@ Returns `true` if the given `object` is a `Date`. Otherwise, returns `false`. const util = require('util'); util.isDate(new Date()); - // true +// Returns: true util.isDate(Date()); - // false (without 'new' returns a String) +// false (without 'new' returns a String) util.isDate({}); - // false +// Returns: false ``` ### util.isError(object) @@ -512,11 +512,11 @@ Returns `true` if the given `object` is an [`Error`][]. Otherwise, returns const util = require('util'); util.isError(new Error()); - // true +// Returns: true util.isError(new TypeError()); - // true +// Returns: true util.isError({ name: 'Error', message: 'an error occurred' }); - // false +// Returns: false ``` Note that this method relies on `Object.prototype.toString()` behavior. It is @@ -528,10 +528,10 @@ const util = require('util'); const obj = { name: 'Error', message: 'an error occurred' }; util.isError(obj); - // false +// Returns: false obj[Symbol.toStringTag] = 'Error'; util.isError(obj); - // true +// Returns: true ``` ### util.isFunction(object) @@ -554,11 +554,11 @@ function Foo() {} const Bar = function() {}; util.isFunction({}); - // false +// Returns: false util.isFunction(Foo); - // true +// Returns: true util.isFunction(Bar); - // true +// Returns: true ``` ### util.isNull(object) @@ -578,11 +578,11 @@ Returns `true` if the given `object` is strictly `null`. Otherwise, returns const util = require('util'); util.isNull(0); - // false +// Returns: false util.isNull(undefined); - // false +// Returns: false util.isNull(null); - // true +// Returns: true ``` ### util.isNullOrUndefined(object) @@ -602,11 +602,11 @@ returns `false`. const util = require('util'); util.isNullOrUndefined(0); - // false +// Returns: false util.isNullOrUndefined(undefined); - // true +// Returns: true util.isNullOrUndefined(null); - // true +// Returns: true ``` ### util.isNumber(object) @@ -625,13 +625,13 @@ Returns `true` if the given `object` is a `Number`. Otherwise, returns `false`. const util = require('util'); util.isNumber(false); - // false +// Returns: false util.isNumber(Infinity); - // true +// Returns: true util.isNumber(0); - // true +// Returns: true util.isNumber(NaN); - // true +// Returns: true ``` ### util.isObject(object) @@ -651,13 +651,13 @@ Returns `true` if the given `object` is strictly an `Object` **and** not a const util = require('util'); util.isObject(5); - // false +// Returns: false util.isObject(null); - // false +// Returns: false util.isObject({}); - // true +// Returns: true util.isObject(function(){}); - // false +// Returns: false ``` ### util.isPrimitive(object) @@ -677,23 +677,23 @@ Returns `true` if the given `object` is a primitive type. Otherwise, returns const util = require('util'); util.isPrimitive(5); - // true +// Returns: true util.isPrimitive('foo'); - // true +// Returns: true util.isPrimitive(false); - // true +// Returns: true util.isPrimitive(null); - // true +// Returns: true util.isPrimitive(undefined); - // true +// Returns: true util.isPrimitive({}); - // false +// Returns: false util.isPrimitive(function() {}); - // false +// Returns: false util.isPrimitive(/^$/); - // false +// Returns: false util.isPrimitive(new Date()); - // false +// Returns: false ``` ### util.isRegExp(object) @@ -712,11 +712,11 @@ Returns `true` if the given `object` is a `RegExp`. Otherwise, returns `false`. const util = require('util'); util.isRegExp(/some regexp/); - // true +// Returns: true util.isRegExp(new RegExp('another regexp')); - // true +// Returns: true util.isRegExp({}); - // false +// Returns: false ``` ### util.isString(object) @@ -735,13 +735,13 @@ Returns `true` if the given `object` is a `string`. Otherwise, returns `false`. const util = require('util'); util.isString(''); - // true +// Returns: true util.isString('foo'); - // true +// Returns: true util.isString(String('foo')); - // true +// Returns: true util.isString(5); - // false +// Returns: false ``` ### util.isSymbol(object) @@ -760,11 +760,11 @@ Returns `true` if the given `object` is a `Symbol`. Otherwise, returns `false`. const util = require('util'); util.isSymbol(5); - // false +// Returns: false util.isSymbol('foo'); - // false +// Returns: false util.isSymbol(Symbol('foo')); - // true +// Returns: true ``` ### util.isUndefined(object) @@ -784,11 +784,11 @@ const util = require('util'); const foo = undefined; util.isUndefined(5); - // false +// Returns: false util.isUndefined(foo); - // true +// Returns: true util.isUndefined(null); - // false +// Returns: false ``` ### util.log(string) From 9a0bcfc4522b233c5506da91b01b6d649cfe5020 Mon Sep 17 00:00:00 2001 From: Anna Henningsen Date: Fri, 30 Sep 2016 16:16:28 +0200 Subject: [PATCH 055/104] fs: export `realpathCacheKey` from `internal/fs` MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Move the internally defined symbol `fs.realpathCacheKey` to the internal fs module, where it’s more appropriate. The symbol was recently added in c084287a608ef, but since `internal/fs` is only available in the v7.x branch, this needs to be a separate follow-up change. PR-URL: https://github.com/nodejs/node/pull/8862 Reviewed-By: Colin Ihrig Reviewed-By: James M Snell --- lib/fs.js | 6 +----- lib/internal/fs.js | 2 ++ lib/module.js | 6 ++---- 3 files changed, 5 insertions(+), 9 deletions(-) diff --git a/lib/fs.js b/lib/fs.js index e22838da156fb2..a241e6c456e4a7 100644 --- a/lib/fs.js +++ b/lib/fs.js @@ -1455,10 +1455,6 @@ function encodeRealpathResult(result, options, err) { } } -// This is removed from the fs exports in lib/module.js in order to make -// sure that this stays internal. -const realpathCacheKey = fs.realpathCacheKey = Symbol('realpathCacheKey'); - fs.realpathSync = function realpathSync(p, options) { options = getOptions(options, {}); nullCheck(p); @@ -1468,7 +1464,7 @@ fs.realpathSync = function realpathSync(p, options) { const seenLinks = {}; const knownHard = {}; - const cache = options[realpathCacheKey]; + const cache = options[internalFS.realpathCacheKey]; const original = p; const maybeCachedResult = cache && cache.get(p); diff --git a/lib/internal/fs.js b/lib/internal/fs.js index 89ad30b78ce916..881679f99c4000 100644 --- a/lib/internal/fs.js +++ b/lib/internal/fs.js @@ -96,3 +96,5 @@ SyncWriteStream.prototype.destroy = function() { }; exports.SyncWriteStream = SyncWriteStream; + +exports.realpathCacheKey = Symbol('realpathCacheKey'); diff --git a/lib/module.js b/lib/module.js index 2da3dca35ae000..09c4b85b9e5599 100644 --- a/lib/module.js +++ b/lib/module.js @@ -6,6 +6,7 @@ const internalModule = require('internal/module'); const vm = require('vm'); const assert = require('assert').ok; const fs = require('fs'); +const internalFS = require('internal/fs'); const path = require('path'); const internalModuleReadFile = process.binding('fs').internalModuleReadFile; const internalModuleStat = process.binding('fs').internalModuleStat; @@ -113,9 +114,6 @@ function tryPackage(requestPath, exts, isMain) { // Set to an empty Map to reset. const realpathCache = new Map(); -const realpathCacheKey = fs.realpathCacheKey; -delete fs.realpathCacheKey; - // check if the file exists and is not a directory // if using --preserve-symlinks and isMain is false, // keep symlinks intact, otherwise resolve to the @@ -130,7 +128,7 @@ function tryFile(requestPath, isMain) { function toRealPath(requestPath) { return fs.realpathSync(requestPath, { - [realpathCacheKey]: realpathCache + [internalFS.realpathCacheKey]: realpathCache }); } From cc6901d48204363888fda4b54a85ca070f798092 Mon Sep 17 00:00:00 2001 From: "Sakthipriyan Vairamani (thefourtheye)" Date: Thu, 3 Nov 2016 14:33:13 +0530 Subject: [PATCH 056/104] tools: improve docopen target in Makefile 1. As it is, it just tries to build only the `all.html` file. If none of the other files are built already, generated page will not be good. To fix this, we process the assets and generate HTML files first. 2. After the HTML is generated, `google-chrome` is used to open the generated file in browser. This is not very portable as it might not be installed or installations might have used a different name. So, we use Python's webbrowser module to open the file. PR-URL: https://github.com/nodejs/node/pull/9436 Reviewed-By: Daniel Bevenius Reviewed-By: James M Snell Reviewed-By: Roman Reiss --- Makefile | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index ba017622ec71c4..24aa53b64d4fe7 100644 --- a/Makefile +++ b/Makefile @@ -296,15 +296,14 @@ test-v8 test-v8-intl test-v8-benchmarks test-v8-all: endif apidoc_sources = $(wildcard doc/api/*.md) -apidocs = $(addprefix out/,$(apidoc_sources:.md=.html)) \ - $(addprefix out/,$(apidoc_sources:.md=.json)) +apidocs_html = $(apidoc_dirs) $(apiassets) $(addprefix out/,$(apidoc_sources:.md=.html)) +apidocs_json = $(apidoc_dirs) $(apiassets) $(addprefix out/,$(apidoc_sources:.md=.json)) apidoc_dirs = out/doc out/doc/api/ out/doc/api/assets apiassets = $(subst api_assets,api/assets,$(addprefix out/,$(wildcard doc/api_assets/*))) -doc-only: $(apidoc_dirs) $(apiassets) $(apidocs) tools/doc/ - +doc-only: $(apidocs_html) $(apidocs_json) doc: $(NODE_EXE) doc-only $(apidoc_dirs): @@ -340,8 +339,8 @@ out/doc/api/%.html: doc/api/%.md fi [ -x $(NODE) ] && $(NODE) $(gen-html) || node $(gen-html) -docopen: out/doc/api/all.html - -google-chrome out/doc/api/all.html +docopen: $(apidocs_html) + @$(PYTHON) -mwebbrowser file://$(PWD)/out/doc/api/all.html docclean: -rm -rf out/doc From 875d1b93fc122902d2883a504212c0f97d1ff9cb Mon Sep 17 00:00:00 2001 From: Yoshiya Hinosawa Date: Sat, 12 Nov 2016 17:16:03 +0900 Subject: [PATCH 057/104] test: add test case of PassThrough This commit adds the test case of PassThrough. This test case checks that PassThrough can construct without new operator. This is a part of Code And Learn at NodeFest 2016 Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9581 Reviewed-By: Yosuke Furukawa Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- test/parallel/test-stream2-transform.js | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/test/parallel/test-stream2-transform.js b/test/parallel/test-stream2-transform.js index bc812ff30d6937..6a4036681f90b7 100644 --- a/test/parallel/test-stream2-transform.js +++ b/test/parallel/test-stream2-transform.js @@ -106,6 +106,14 @@ test('object passthrough', function(t) { t.end(); }); +test('passthrough constructor', function(t) { + const pt = PassThrough(); + + assert(pt instanceof PassThrough); + + t.end(); +}); + test('simple transform', function(t) { var pt = new Transform(); pt._transform = function(c, e, cb) { From 474d4aa2e38441aa5cf4f303b7b8ad48e20c8c6c Mon Sep 17 00:00:00 2001 From: Mitsuo Utano Date: Sat, 12 Nov 2016 17:04:28 +0900 Subject: [PATCH 058/104] doc: fix typo in doc/repl.md line: 6 fix doc/api/repl.md line 6 "includable" => "includible" Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9582 Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- doc/api/repl.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/api/repl.md b/doc/api/repl.md index b18488f4218174..67eae5d1cca6e8 100644 --- a/doc/api/repl.md +++ b/doc/api/repl.md @@ -3,7 +3,7 @@ > Stability: 2 - Stable The `repl` module provides a Read-Eval-Print-Loop (REPL) implementation that -is available both as a standalone program or includable in other applications. +is available both as a standalone program or includible in other applications. It can be accessed using: ```js From 51e24e770abf1e2c452969b508d5fea781cd3dc0 Mon Sep 17 00:00:00 2001 From: "masashi.g" Date: Sat, 12 Nov 2016 22:56:19 +0900 Subject: [PATCH 059/104] test: use setImmediate() in test of stream2 use setImmediate() insted of setTimeout() in test of stream2 push. The test is in test/parallel/test-stream2-push.js Fixes: https://github.com/nodejs/code-and-learn/issues/58 PR-URL: https://github.com/nodejs/node/pull/9583 Reviewed-By: Colin Ihrig Reviewed-By: Anna Henningsen Reviewed-By: Luigi Pinca Reviewed-By: Shigeki Ohtsu --- test/parallel/test-stream2-push.js | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/parallel/test-stream2-push.js b/test/parallel/test-stream2-push.js index a7ff95e7482015..445a186715b659 100644 --- a/test/parallel/test-stream2-push.js +++ b/test/parallel/test-stream2-push.js @@ -111,7 +111,7 @@ function end() { source.emit('end'); assert(!reading); writer.end(stream.read()); - setTimeout(function() { + setImmediate(function() { assert(ended); }); } From 4ddc23828d1acb57bbbca94ebabec2b03cfd49ec Mon Sep 17 00:00:00 2001 From: James M Snell Date: Mon, 7 Nov 2016 08:26:19 -0800 Subject: [PATCH 060/104] doc: move TSC and CTC meeting minutes out of core repo The TSC and CTC meeting minutes are more properly placed in the nodejs/tsc and nodejs/ctc repositories, respectively. PR-URL: https://github.com/nodejs/node/pull/9503 Reviewed-By: Colin Ihrig Reviewed-By: Myles Borins Reviewed-By: Michael Dawson Reviewed-By: Evan Lucas Reviewed-By: Rich Trott Reviewed-By: Luigi Pinca Reviewed-By: Roman Reiss --- doc/ctc-meetings/2015-10-28.md | 276 ------------------ doc/ctc-meetings/2015-11-04.md | 65 ----- doc/ctc-meetings/2015-11-11.md | 136 --------- doc/ctc-meetings/2015-12-02.md | 83 ------ doc/ctc-meetings/2015-12-16.md | 164 ----------- doc/ctc-meetings/2016-01-06.md | 216 -------------- doc/ctc-meetings/2016-01-20.md | 337 --------------------- doc/ctc-meetings/2016-01-27.md | 295 ------------------- doc/ctc-meetings/2016-02-03.md | 223 -------------- doc/ctc-meetings/2016-02-10.md | 167 ----------- doc/ctc-meetings/2016-02-17.md | 240 --------------- doc/ctc-meetings/2016-05-04.md | 192 ------------ doc/ctc-meetings/2016-06-15.md | 174 ----------- doc/ctc-meetings/2016-06-22.md | 151 ---------- doc/ctc-meetings/2016-06-29.md | 187 ------------ doc/ctc-meetings/2016-07-06.md | 150 ---------- doc/ctc-meetings/2016-07-13.md | 236 --------------- doc/ctc-meetings/2016-07-20.md | 202 ------------- doc/ctc-meetings/2016-07-27.md | 237 --------------- doc/ctc-meetings/2016-08-03.md | 336 --------------------- doc/ctc-meetings/2016-08-10.md | 281 ------------------ doc/ctc-meetings/2016-08-17.md | 300 ------------------- doc/ctc-meetings/2016-08-24.md | 328 --------------------- doc/ctc-meetings/2016-08-31.md | 315 -------------------- doc/ctc-meetings/2016-09-07.md | 245 ---------------- doc/ctc-meetings/2016-09-14.md | 153 ---------- doc/ctc-meetings/2016-09-21.md | 218 -------------- doc/ctc-meetings/2016-09-28.md | 303 ------------------- doc/ctc-meetings/2016-10-05.md | 312 -------------------- doc/ctc-meetings/2016-10-12.md | 157 ---------- doc/ctc-meetings/2016-10-19.md | 202 ------------- doc/ctc-meetings/2016-10-26.md | 151 ---------- doc/tsc-meetings/2015-05-27.md | 143 --------- doc/tsc-meetings/2015-06-03.md | 166 ----------- doc/tsc-meetings/2015-06-10.md | 184 ------------ doc/tsc-meetings/2015-06-17.md | 134 --------- doc/tsc-meetings/2015-07-01.md | 88 ------ doc/tsc-meetings/2015-07-08.md | 131 --------- doc/tsc-meetings/2015-07-15.md | 94 ------ doc/tsc-meetings/2015-07-22.md | 168 ----------- doc/tsc-meetings/2015-07-29.md | 89 ------ doc/tsc-meetings/2015-08-12.md | 87 ------ doc/tsc-meetings/2015-08-19.md | 120 -------- doc/tsc-meetings/2015-08-26.md | 112 ------- doc/tsc-meetings/2015-09-02.md | 418 --------------------------- doc/tsc-meetings/2015-09-16.md | 116 -------- doc/tsc-meetings/2015-09-30.md | 161 ----------- doc/tsc-meetings/2015-10-07.md | 102 ------- doc/tsc-meetings/2015-10-14.md | 121 -------- doc/tsc-meetings/2015-10-21.md | 214 -------------- doc/tsc-meetings/io.js/2014-10-09.md | 61 ---- doc/tsc-meetings/io.js/2014-10-15.md | 44 --- doc/tsc-meetings/io.js/2014-10-29.md | 33 --- doc/tsc-meetings/io.js/2014-12-10.md | 139 --------- doc/tsc-meetings/io.js/2014-12-17.md | 91 ------ doc/tsc-meetings/io.js/2014-12-30.md | 95 ------ doc/tsc-meetings/io.js/2015-01-07.md | 154 ---------- doc/tsc-meetings/io.js/2015-01-13.md | 101 ------- doc/tsc-meetings/io.js/2015-01-21.md | 166 ----------- doc/tsc-meetings/io.js/2015-01-28.md | 179 ------------ doc/tsc-meetings/io.js/2015-02-04.md | 107 ------- doc/tsc-meetings/io.js/2015-02-18.md | 129 --------- doc/tsc-meetings/io.js/2015-03-04.md | 164 ----------- doc/tsc-meetings/io.js/2015-03-18.md | 92 ------ doc/tsc-meetings/io.js/2015-04-01.md | 107 ------- doc/tsc-meetings/io.js/2015-04-08.md | 184 ------------ doc/tsc-meetings/io.js/2015-04-15.md | 87 ------ doc/tsc-meetings/io.js/2015-04-22.md | 127 -------- doc/tsc-meetings/io.js/2015-04-29.md | 101 ------- doc/tsc-meetings/io.js/2015-05-13.md | 137 --------- 70 files changed, 11978 deletions(-) delete mode 100644 doc/ctc-meetings/2015-10-28.md delete mode 100644 doc/ctc-meetings/2015-11-04.md delete mode 100644 doc/ctc-meetings/2015-11-11.md delete mode 100644 doc/ctc-meetings/2015-12-02.md delete mode 100644 doc/ctc-meetings/2015-12-16.md delete mode 100644 doc/ctc-meetings/2016-01-06.md delete mode 100644 doc/ctc-meetings/2016-01-20.md delete mode 100644 doc/ctc-meetings/2016-01-27.md delete mode 100644 doc/ctc-meetings/2016-02-03.md delete mode 100644 doc/ctc-meetings/2016-02-10.md delete mode 100644 doc/ctc-meetings/2016-02-17.md delete mode 100644 doc/ctc-meetings/2016-05-04.md delete mode 100644 doc/ctc-meetings/2016-06-15.md delete mode 100644 doc/ctc-meetings/2016-06-22.md delete mode 100644 doc/ctc-meetings/2016-06-29.md delete mode 100644 doc/ctc-meetings/2016-07-06.md delete mode 100644 doc/ctc-meetings/2016-07-13.md delete mode 100644 doc/ctc-meetings/2016-07-20.md delete mode 100644 doc/ctc-meetings/2016-07-27.md delete mode 100644 doc/ctc-meetings/2016-08-03.md delete mode 100644 doc/ctc-meetings/2016-08-10.md delete mode 100644 doc/ctc-meetings/2016-08-17.md delete mode 100644 doc/ctc-meetings/2016-08-24.md delete mode 100644 doc/ctc-meetings/2016-08-31.md delete mode 100644 doc/ctc-meetings/2016-09-07.md delete mode 100644 doc/ctc-meetings/2016-09-14.md delete mode 100644 doc/ctc-meetings/2016-09-21.md delete mode 100644 doc/ctc-meetings/2016-09-28.md delete mode 100644 doc/ctc-meetings/2016-10-05.md delete mode 100644 doc/ctc-meetings/2016-10-12.md delete mode 100644 doc/ctc-meetings/2016-10-19.md delete mode 100644 doc/ctc-meetings/2016-10-26.md delete mode 100644 doc/tsc-meetings/2015-05-27.md delete mode 100644 doc/tsc-meetings/2015-06-03.md delete mode 100644 doc/tsc-meetings/2015-06-10.md delete mode 100644 doc/tsc-meetings/2015-06-17.md delete mode 100644 doc/tsc-meetings/2015-07-01.md delete mode 100644 doc/tsc-meetings/2015-07-08.md delete mode 100644 doc/tsc-meetings/2015-07-15.md delete mode 100644 doc/tsc-meetings/2015-07-22.md delete mode 100644 doc/tsc-meetings/2015-07-29.md delete mode 100644 doc/tsc-meetings/2015-08-12.md delete mode 100644 doc/tsc-meetings/2015-08-19.md delete mode 100644 doc/tsc-meetings/2015-08-26.md delete mode 100644 doc/tsc-meetings/2015-09-02.md delete mode 100644 doc/tsc-meetings/2015-09-16.md delete mode 100644 doc/tsc-meetings/2015-09-30.md delete mode 100644 doc/tsc-meetings/2015-10-07.md delete mode 100644 doc/tsc-meetings/2015-10-14.md delete mode 100644 doc/tsc-meetings/2015-10-21.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-09.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-15.md delete mode 100644 doc/tsc-meetings/io.js/2014-10-29.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-10.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-17.md delete mode 100644 doc/tsc-meetings/io.js/2014-12-30.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-07.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-13.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-21.md delete mode 100644 doc/tsc-meetings/io.js/2015-01-28.md delete mode 100644 doc/tsc-meetings/io.js/2015-02-04.md delete mode 100644 doc/tsc-meetings/io.js/2015-02-18.md delete mode 100644 doc/tsc-meetings/io.js/2015-03-04.md delete mode 100644 doc/tsc-meetings/io.js/2015-03-18.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-01.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-08.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-15.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-22.md delete mode 100644 doc/tsc-meetings/io.js/2015-04-29.md delete mode 100644 doc/tsc-meetings/io.js/2015-05-13.md diff --git a/doc/ctc-meetings/2015-10-28.md b/doc/ctc-meetings/2015-10-28.md deleted file mode 100644 index 5efe94454ad3f8..00000000000000 --- a/doc/ctc-meetings/2015-10-28.md +++ /dev/null @@ -1,276 +0,0 @@ -# Node Foundation CTC Meeting 2015-10-28 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-10-28 -* **GitHub Issue**: https://github.com/nodejs/node/issues/3561 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Rod Vagg (CTC) -* Brian White (CTC) -* James Snell (CTC) -* Chris Dickinson (CTC) -* Ben Noordhuis (CTC) -* Jeremiah Senkpiel (CTC) -* Trevor Norris (CTC) -* Alexis Campailla (CTC) -* Mikeal Rogers (observer) -* Shigeki Ohtsu (CTC) -* Seth Thompson (observer) -* Bert Belder (CTC) -* Fedor Indutny (CTC) -* Ben Noordhuis (CTC) -* Colin Ihrig (CTC) - -## Agenda - -Extracted from **tsc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. - -### nodejs/node - -* Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) -* fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) -* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) - -## Minutes - -### Review of previous meeting - -* governance: add new collaborators #VIII [#3472](https://github.com/nodejs/node/issues/3472) -* detect "full-icu" module [#3460](https://github.com/nodejs/node/issues/3460) -* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) -* node: deprecate public access to `process.binding` [#2768](https://github.com/nodejs/node/pull/2768) -* node: make listen address configurable [#3316](https://github.com/nodejs/node/pull/3316) - -### Standup - -* Rod Vagg (CTC): Traveling, rc for v5.x, going to put another rc out today, comfortable with it getting released tomorrow. If it slips we’ll put it off until next week. Just need to do more smoke testing on this. -* Brian White (CTC): Not a whole lot this week — triaging, responding to issues. -* James Snell (CTC): Getting HTTP parser up to v2.6; getting 4.2.2 LTS update ready to go. open issue on LTS repo, would love eyes on it, to verify that the commits going into 4.2.2 look good. (https://github.com/nodejs/LTS/issues/50) working with Miles on getting CITGM updated. -* Chris Dickinson (CTC): Some silly build stuff -* Jeremiah Senkpiel (CTC): Not much — computer was dead since last Friday, ): but repaired now. -* Trevor Norris (CTC): Bugs and issues — couple of outstanding PRs around asyncwrap, one done at Fedor’s request to make AsyncWrap public, in order to make JSStream class public -* Alexis Campailla (CTC): Meetings; first API WG meeting, defining scope of the work for the WG, we want to address engine abstraction and native module API and some performance issues; small work in CI to add diagnostics; progress on module build service, going to post finding soon to get feedback -* Mikeal Rogers (observer): getting a lot of interest on a certification program for node, for alternative implementations, looking at notes for API WG (thanks for taking great notes! that was awesome) I reached out to a few people that may contribute as well -* Seth Thompson (observer): No updates this week. -* Bert Belder (CTC): nothing noteworthy -* Ben Noordhuis (CTC): Fixed debugger bugs, reviewed a lot of pull requests. -* Colin Ihrig (CTC): Trying to help out with issue tracker, anticipate in another week ½ I should have significantly more time to work on core. - -### Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) - -* adds .jsonld files to require.extensions so that they’d load using json loader - -Rod: I raised this to CTC. I see this as a slippery slope, adding anything more to require.extensions. I don’t see how this won’t turn into XML — turns into bloat in formats that folks want to support. My preference would be to let the ecosystem figure this out and let folks write their own JSON loaders. - -Jeremiah: also probably belongs in npm - -James: .jsonld is just a json file with a special syntax internally. I have a module that loads it. It’s very easy to work around. Rename the file to use a json extension. I don’t see the harm in landing it, but if we don’t want to go that route, - -Mikeal: is the patch to add the extension or to give you your own serializer (extension) - -Bert: It seems harmless, but 6 months from now what if someone shows up and says “hey you’re not validating it properly” and then we have to add a validator … I’m very sensitive to slippery slope argument - -Alexis: Is it a different syntax? - -Bert: is every json document a valid jsonld document? - -James: no. - -Mikeal: we’re using a parser from npm, are we going to get a war between parsers, swapping them out? - -James: this doesn’t do any special parsing for jsonld, it just aliases json and uses the existing process. - -Trevor: the problem is what it opens us up to. invariably this leads to more PRs. this patch I don’t have a problem with, but I have a problem with this kind of patch in the future - -Bert: I think we’re reaching consensus here, which is: reject this patch. is anyone here strongly in favor. - -Ben: not in favor. one argument is jsonld is now a standard. but I too am sensitive to the slippery slope argument, so I’m perfectly fine with rejecting it. - -James: when rejecting it, it would be worthwhile to note how to work around it. I can do this. - -Jeremiah: require.extensions is not going to change anytime soon, so folks can write their own. - -Bert: I think we can go to the next issue. - -### fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) - -See also [#3519](https://github.com/nodejs/node/issues/3519) - -Bert: this is Ben’s issue. - -Ben: I wouldn’t say it’s my issue, but I’ve been involved -the thing is that filenames are frequently (but not always) utf8, the problem is now that node in one or two places it doesn’t encode utf8 [Ben, post meeting addition: For background: I thought we had some file logic baked into node::Environment and the dtrace/etw/lttng/systemtap subsystems but turns out that's not the case.] - -Bert: where else are we encoding differently? - -Ben: I can answer this in a few seconds. At least, I think there are more places. Maybe I’m mistaken, also a possibility! - -Jeremiah: I think someone else said it was only fs.watch too. - -Bert: I’ve seen the discussion but I haven’t commented. I think there’s a problem with assuming that all files are all utf8, but it seems inconsequential to assume this everywhere but this one place - -Ben: this is not the best issue to link to, I agree it’s inconsistent to do utf8 in most places and latin1 in only one place. There’s a link to another issue 3519. my beef with the PR is not that it’s a terrible fix, it’s more that decoding to utf8 is not always the right thing to do because not all fs are utf-8. If we’re going to do this it has to be a semver major, and if we’re going to do a semver major, then it may as well be a full fix, which I’ve outlined in 3519. - -Bert: there’s actually some discussions we need to have around these things. Your suggestion is to not land this PR, and instead fix this the right way. Do you think it’s likely that 3519 will see attention any time soon? - -Ben: It’s on my todo list. I should mention that the way node deals with file names has been a thorn in my side for a long time now, I’ve been planning to do something about it for a long time, so take this as you will. - -Bert: my question is: do we take this PR now, ahead of - -Bert: customizable decoding - -Mikeal: is the other one going to be a breaking change? - -Ben: yes - -Bert: or it could be a bugfix? - -Mikeal: so it would make sense to buffer as many changes around that as possible. - -Jeremiah: we could land the semver-major fix on master which would go into 6.x, then if we have time before 6.x we could do the proper fix. maybe that keeps us from fixing it entirely though? - -Ben: that’s my problem, it’s a bandaid that lets us truck on for a another couple of years. - -James?: I don’t really like quick fixes, but … - -Trevor: on the fs doc page, a lot of those calls reference the system level call, on unix do those use utf8 - -Ben: how do you mean? - -Trevor: for example, stat, first arg is char* pathname, if i were to take a utf8 string and read that in… what encoding does it use? - -Ben: syscall is agnostic. kernel treats as string of bytes. in node, we call fs.stat in javascript, string is decoded to utf8, then passed on to the kernel. - -Trevor: if i have a file that’s latin1, I’d have to turn that into a buffer as a binary buffer then tostring it to a utf8 string in order for the file to be open? - -[multiple people are talking] - -Ben: yes. - -Ben: sometimes it’s not possible to open files with funny characters in their names. - -Trevor: if there were a file with invalid utf8 characters it’d be impossible to open those, right? - -Ben: yep. - -James: I’m not a fan of the quick fix. I am okay with incremental so long as the larger task gets done, but … - -Bert: I am in favor of the quick fix, it restores consistency in the way node does things. practically speaking, almost all fs are going to be utf-8. it fixes the problem where fs.watch tells you “hey a file changed” but you go to look and the file’s not there due to the encoding scheme. I’d like to make a little improvement. the problem has been known since at least 2011, and we’ve never gotten around to it. I would not be surprised if it takes another 4 years for someone to take a stab at it. - -Brian: is it possible to get the user’s LOCALE and convert to that before sending it off? - -Ben: that’s worse than what we have now. - -James: the LOCALE often lies. - -Bert: are we going to land the patch to fs.watch? I’d like to have a quick references. - -Trevor: it’s not going to land in 5, we could leave it open until near v6 and land it then if no one is able to get around to the full fix. there’s 5-6 months between 5 and 6… - -Rod: that sounds like a nice compromise. - -### WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) - -Rod: I left this on because I thought it’d be nice to get a report from the WG on how it went. - -James: [cd: I am missing folk here]: Jeremiah, Eran Hammer, Doug Wilson, Myles Borins Brian White, Patrick Mueller, and myself. - -We talked about the charter. Looking into what improvements can be made to better support the ecosystem. Making existing impl hookable so that modules could swap out parts of the implementation with their own. Like replacing the parser, or header specific handling. The charter covers that aspect of it, but emphasizes that existing systems are not broken. We have a number of issues that we’ve created to start discussing these. I’ll get these into the doc. - -That’s the short version. Still really early to tell what all will come of it and what kind of schedule it’ll be on. 5th, at [cd: TIME?] -We’ll be drawing up a charter and bringing it back to this group. - -Any other questions? - -Rod: could we get a report on the API WG? - -Trevor: the discussion was mainly around the native api. it went in a direction I wasn’t expecting. I explained my JS API proposal, then it went into a module discussion. ABI compat is straight out, it went in the direction of NAN (API compat, but occasional recompiles). Some discussion arose around abstracting node, like v8 completely. to replace with another VM. How do you handle specific difference like features that are available in one vm or another? or JS features that are/aren’t available between VMs. To target all vms, you end up having to use ES5. I was kind of losing where they were going with it. there are a lot of smart people. We’ll just have to have a discussion about feasibility. - -Ben: Was there any talk about who’s going to do the actual work? - -Trevor: No — it was more theoretical. It was more like the ES committee — develop features then say “go make these.” IF I bring it up I’m sure I can get some solid answers. - -Alexis: I’m trying to push for the Chakra folks to do some of this work. - -Mikeal: [cd: sorry, I missed this.] - -Rod: What companies are involved? Did MS show up? - -Trevor: Yes, I think so. JXCore, IBM was there, can’t remember offhand. - -Bert: JXCore is also secretly MS? - -Alexis: Not a secret! They’re on contract for an industrial IoT project. - -Alexis: IBM was there, Nodesource. - -Mikeal: Looking for someone from samsung’s jerryscript team to join. - -Trevor: My initial proposal was to get something usable. I’ll be out of there if it turns into WASM — if it blows up in size. - -Mikeal: The whole point is to be smaller than the current API, right? - -Bert: Well, not smaller, but … let’s not talk about technical issues - -Alexis: We’ve discussed multiple approaches, and we can tackle the problem from multiple sides. Trevor is tackling it by reducing the size of core. The approach I want to take is FFI interface into native modules. All of these approaches can help us tackle this huge beast into a manageable problem. They’re not competing solutions. - -Bert: We want to avoid scope creep. If the WG comes up with a HUGE proposal with 20 points of view, then no one will ever go do it. - -Trevor: I want to simplify the JS API, and get it to a point where all of the existing api can sit on top of it. If someone wants to do the work of replacing V8, they’ll have a clean entry point into the JS. And then write a set of compliance tests that specify what every entry point does. Writing a bunch for native code without JS tests to back it up would be futile. - -Bert: Restricting it to API design, that in theory, the sort of design goal, is for the API to be sufficient for Node to use. - -Alexis: This would include the native module api? - -Rod: It sounds like HTTP attacked charter first, maybe the API WG needs to do the same, to combat growth of scope. Maybe anyone else on this call that wants to could join and try to define scope? Is there another call scheduled, Trevor? - -Trevor: we’re still collecting times. I’ll mention the ctc in the issue. - -Rod: we should make a new @ctc GH group. - -Bert: which is going to be more fun? - -Rod: The CTC - -Bert: when are we going to split up? - -Rod: Mikeal is organizing another meeting. - -Mikeal: It’s tomorrow at this time slot. - -### node-gyp: Windows users are not happy. [node-gyp#629](https://github.com/nodejs/node-gyp/issues/629) - - -Jeremiah: Do we want to talk about the windows issue? - -Rod?: it kind of contains all of the windows problems. - -Alexis: I was asking about guidance on this. - -Rod: there’s a strategy of giving folks a place to vent, keeping it from spilling over elsewhere. Without this issue, it might explode into a bunch more issues. - -Alexis: We’re working on a module build service. The other thing is that MS is going to release a smaller SKU of the compiler, that might be able to be included with node-gyp. - -Rod: Next visual studio is going to be shipping with clang. - -Trevor: Yes for AST stuff. [cd: might have gotten this wrong] - -Rod: Alexis, you should post in there, but I think it’s going to always catch folks googling for the problem. I’m not sure you can resolve it by closing or locking it. Folks will go there and not see a proper resolution. - -Mikeal: make sure there are issues for everything in the thread, then close and lock. Make sure there are resolutions (even if it’s “move hte conversation”). - -Rod: I’m happy for Alexis to take the lead on this. - -Rod: Maybe change the title to “Windows users are happy?” - -Alexis: Maybe change to “Unix users are unhappy.” - -Rod: that’d be an epic troll. - -## Next Meeting - -November 4, 2015 diff --git a/doc/ctc-meetings/2015-11-04.md b/doc/ctc-meetings/2015-11-04.md deleted file mode 100644 index 1c83d453d8f20e..00000000000000 --- a/doc/ctc-meetings/2015-11-04.md +++ /dev/null @@ -1,65 +0,0 @@ -# Node Foundation CTC Meeting 2015-11-04 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-11-04 -* **GitHub Issue**: https://github.com/nodejs/node/issues/3660 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Rod Vagg (CTC) -* James Snell (CTC) -* Chris Dickinson (CTC) -* Ben Noordhuis (CTC) -* Jeremiah Senkpiel (CTC) -* Trevor Norris (CTC) -* Alexis Campailla (CTC) -* Mikeal Rogers (observer) -* Shigeki Ohtsu (CTC) -* Seth Thompson (observer) -* Bert Belder (CTC) -* Fedor Indutny (CTC) -* Ben Noordhuis (CTC) -* Colin Ihrig (CTC) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. - -### nodejs/node - -* deps: backport 9da3ab6 from V8 upstream [#3609](https://github.com/nodejs/node/pull/3609) - -## Minutes - -### Review of previous meeting - -* Load JSON-LD in the same way as JSON [#3502](https://github.com/nodejs/node/pull/3502) -* fs: decode filenames using UTF-8 in fs.watch [#3401](https://github.com/nodejs/node/pull/3401) -* WG: Considering a new HTTP WG [#3214](https://github.com/nodejs/node/issues/3214) -* node-gyp: Windows users are not happy. [node-gyp#629](https://github.com/nodejs/node-gyp/issues/629) - -### Standup - -* Rod: 0.12/0.10 build infra -* Michael: catching up from being away -* Trevor: reviewing PRs -* James: v4.2.2 - -### deps: backport 9da3ab6 from V8 upstream [#3609](https://github.com/nodejs/node/pull/3609) - -Discussed the semver for this feature, should it be patch or minor? LTS WG has agreed to land this patch but are unsure whether it should bump minor. Discussed some of the points in the issue. - -Trevor: this issue seems to have made it in thanks to a lot of noise made by users, is this going to be a factor in considering future changes for LTS? - -Discussed this topic, agreeing that we shouldn’t be held captive to bike-shedding. - -Bert: would be surprised if this landed as semver-minor, it’s clearly a feature addition. - -Trevor: can we stash this and wait to see what else might be landable—can we expect to have these conversations in the future? - -## Next Meeting - -November 11th, 2015 diff --git a/doc/ctc-meetings/2015-11-11.md b/doc/ctc-meetings/2015-11-11.md deleted file mode 100644 index de23a8192e6dd9..00000000000000 --- a/doc/ctc-meetings/2015-11-11.md +++ /dev/null @@ -1,136 +0,0 @@ -# Node Foundation CTC Meeting 2015-11-11 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-11-11 -* **GitHub Issue**: https://github.com/nodejs/node/issues/3777 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Rod Vagg (CTC) -* James Snell (CTC) -* Ben Noordhuis (CTC) -* Jeremiah Senkpiel (CTC) -* Trevor Norris (CTC) -* Mikeal Rogers (observer) -* Fedor Indutny (CTC) -* Ben Noordhuis (CTC) -* Colin Ihrig (CTC) -* Steven R Loomis (observer?) -* Brian White (CTC) -* Michael Dawson (observer) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests in the nodejs org prior to meeting. - -* Rediscuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) -* V8 working group [#3741](https://github.com/nodejs/node/issues/3741) - -### Standup - -* Rod Vagg: Way too busy, tz lagged. Nodefest JP (with translation)- good community event, large turnout. Ripe for node expansion. Hung out with Shigeki and Yosuke. 0.12 build stuff, Jenkins down but coming back up. Good changes, but put behind with 0.10/0.12 stuff -* James Snell: triaging issues, not a whole lot more beyond 4.2.2. CITGM with Myles, landing PRs. -* Ben Noordhuis: Fixed bug in cluster module, libuv minor work, reviewed lots of PRs/issues. Looking into node-gyp - lots of confusion around python requirement on Windows. Idea: embed in python interpreter, but complicated adventure. -* Jeremiah Senkpiel: Issue/PR work. 5.1.0 release work (delayed). Helping potential new collaborators get involved. -* Trevor Norris: Submitted patch for microbenchmark improvements, removing `Object::Set()` in C++. Helping community members get involved. -* Mikeal Rogers: Rewriting policies. Last-month contributors script, metrics. -* Fedor Indutny: v8 stuff. Tool for postmortem inspection of nodejs process using lldb on linux and osx. Review, requests. -* Colin Ihrig: Reviews, PRs. Opened a very popular PR on cluster suicide. -* Steven R Loomis: Unicode conferences and meetings for the last few weeks, not a lot to report other than moving the iojs language groups to node.js versions. (#2525) -* Brian White: reviewing PRs, triaging, commenting on issues -* Michael Dawson: PR for AIX based on comments, test issues, ppc release machines added to CI, work with Stefan on FIPS PR (unique value - equivalent coverage with FIPS enabled/disabled, and better error message). - -### Rediscuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) - -Mikeal: do not guarantee that error messages don’t change. v8 changes error messages. don’t [shouldn’t] check message text. - -Rod: Don’t think we can make an assumption that this is not done. - -Mikeal: this is a lot of messages changing all at once - -Rod: What about localized messages? (when they change) - -Jeremiah: Localized messages have an ID so that shouldn’t be an issue - -Trevor: if v8 doesn’t internationalize, we shouldn’t internationalize ours - -James: Looking at i18n [l10n] of v8’s messages… comes down to whether ICU will be there by default - -Mikeal: should we be attaaching IDs to messages now? - -_: Error code (such as in Visual Studio) makes it very googleable which is a great help - -Steven: that’s one of the benefits.. - -Trevor: how do you guarantee uniqueness? - -Mikeal: attach a unique code.. - -Rod: Have 2 files that collect the codes. - -Trevor: Pass a function name and string..? - -Rod: … consider this for our API - -Mikeal: don’t know how we can keep these from changing in the context of internationalization - -Rod: But they are not internationalized yet. Can say now, don’t depend on these saying a certain thing. - -Mikeal: we haven’t been aware of libuv’s changes , would need to keep track of libuv’s changes. - -Michael: will this make it hard to fix typos in messages? Would be nice to correct instead of leave the message as is. - -Jeremiah: If people need to check the text for something other than tests, not assigning a unique enough type of error. Seems like bad practice. - -Rod: people do bad things already… - -Jeremiah: make sure people don’t *need* to do these things for legitimate reasons - -Rod: Not fine with semver-major if we decide it’s not a change in general. - -Steven: make it major to put people on notice… ? ids may be good and helpful in general? - -Mikeal: semver-major could make people think they can depend on message text …… hold off on any text changes until ID in place? - -Mikeal: would not accept this in LTS. Question is, would we accept it for 5? - -Rod: policy could say: “will accept changes as semver-patch, but don’t put them into LTS” - -Mikeal: make it semver-minor, consider it a feature. … get this out as Canary (master) … leave tagged - -### V8 working group [#3741](https://github.com/nodejs/node/issues/3741) - -Ben: place to put v8 documentation - -Jeremiah: make sure that some v8 knowledge stays among the core collaborators - -Rod: Julien’s concern is around reducing exposure to v8 - -Michael: Want to involve more people in v8 - -Rod: The other way, a separate WG allows people to find the right people - -Jeremiah: Documentation (of v8) - -Rod: no firm objections - -Steven: Have WG charter include disseminating knowledge/processes around v8? - -Rod: WG allows a good place to do this. - - -### ICU data - ±1 on approach? -[#3460](https://github.com/nodejs/node/issues/3460) ? srl - -… “move ahead, open PR, people can discuss.. mark as experimental so that people don’t depend on it” - -[Chris is taking over note-taking.] - -Rod: Take this to GitHub so we can have a proper discussion - -## Next Meeting - -November 18th, 2015 diff --git a/doc/ctc-meetings/2015-12-02.md b/doc/ctc-meetings/2015-12-02.md deleted file mode 100644 index aaf3357f74bd93..00000000000000 --- a/doc/ctc-meetings/2015-12-02.md +++ /dev/null @@ -1,83 +0,0 @@ -# Node Foundation CTC Meeting 2015-12-02 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-12-02 -* **GitHub Issue**: https://github.com/nodejs/node/issues/4115 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Rod Vagg (CTC) -* James Snell (CTC) -* Ben Noordhuis (CTC) -* Jeremiah Senkpiel (CTC) -* Trevor Norris (CTC) -* Mikeal Rogers (observer) -* Fedor Indutny (CTC) -* Colin Ihrig (CTC) -* Steven R Loomis (observer) -* Brian White (CTC) -* Michael Dawson (observer) -* Alexis Campailla (CTC) -* Bert Belder (CTC) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) -* doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) - - -### Standup - -* Rod Vagg: Catching up from some time off, preparing for security releases tomorrow. -* Ben Noordhuis: Pull requests and bug reports. -* Jeremiah Senkpiel: Large refactoring of timers, general project stuff—PRs and issues, spinning up the CI WG, trying to do more onboarding. -* Trevor Norris: PR review & merging, not too much. -* Mikeal Rogers: Prep for board meeting, new events page on website. -* Fedor Indutny: PR review, fixing fsevents bug in libuv -* Colin Ihrig: Usual issues & PRs -* Brian White: landed a few PRs, commented on issues -* Michael Dawson - Addition of FIPS tests to regression job and some ongoing FIPs related work, still trying to line up AIX machines, investigation with team on some failures on AIX, scheduled next benchmarking meeting, hoping to add charts for initial footprint benchmark, adding other build team members to softlayer/osu environments. -* Alexis Campailla: some build stuff, further investigation into native module build service -* Bert Belder: ? - - -## Review of last meeting - -* Re-discuss if error message changes are semver-major [#3776](https://github.com/nodejs/node/issues/3776) - -## tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) - -* Ben: Matthew Loring from google has been working on this but has found an npm package with the name “node-tick-processor” - -* Discussed how we should deal with potential node core tooling that already shares a same name on npm. - -## Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -1. Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -2. Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) - -* Rod outlined the approach he came up with in https://github.com/nodejs/node/issues/3979 for seeking legal input from the board (via whatever means they want) on (1) the head LICENSE file and (2) copyright and license blocks at the top of files and (3) the npm licensing issues raised in #3959. - -* Group agreed to move forward with the approach and to allow Rod and Mikeal to tune the wording before handing off. - -## doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) - -* No objections to renaming to #node-dev - -## TSC meeting tomorrow - -Briefly discussed the meeting tomorrow in this timeslot. Admitting libuv to the foundation as an incubator project. - -## Next Meeting - -December 9th, 2015 diff --git a/doc/ctc-meetings/2015-12-16.md b/doc/ctc-meetings/2015-12-16.md deleted file mode 100644 index 0ad4603a39589a..00000000000000 --- a/doc/ctc-meetings/2015-12-16.md +++ /dev/null @@ -1,164 +0,0 @@ -# Node Foundation CTC Meeting 2015-12-16 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2015-12-16 -* **GitHub Issue**: https://github.com/nodejs/node/issues/4309 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Michael Dawson (observer) -* Alexis Campailla (CTC) -* Bert Belder (CTC) -* Chris Dickinson (CTC) -* Ali Ijaz Sheikh (observer) -* Shigeki Ohtsu (CTC) -* Seth Thompson (observer) -* Steven Loomis (observer) -* Mikeal Rogers (observer) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) - -### nodejs/LTS - -* Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) -* AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) - - -### Standup - -* James Snell (CTC) — Node interactive, looking at PRs, i18n -* Trevor Norris (CTC) — Been sick, some review -* Colin Ihrig (CTC) — Node interactive, reviewing issues and PRs, yesterday started 5.3.0 release (held up to issue with debugging), am process of releasing 5.3.0 right now -* Brian White (CTC) — Submitted PRs, commenting on issues and PRs -* Michael Dawson (observer) - Node interactive - catching up -* Alexis Campailla (CTC) — Node interactive – MS is open sourcing Chakra, and submitting a PR to Node, mid-January -* Bert Belder (CTC) — Missed NI, was on vacation, commented on some issues -* Chris Dickinson (CTC) — Node Interactive, commenting on issues and PRs -* Shigeki Ohtsu (CTC) - Looking at new version of openssl-1.1.0 -* Steven Loomis (observer) — Node interactive, INTL meeting, went over existing issues (esp. re: TC39 standards-level happenings) -* Mikeal Rogers (observer) — Node interactive, board meeting last week, the board accepted the request for legal advice, kicked off to legal committee which will come back with a recommendation or will be handed off to outside counsel -* Jeremiah Senkpiel (CTC)- Node.js Interactive, general issues/PRs, made #io.js on freenode irc forward to #node-dev - -## Review of last meeting - -* tools: change tick processor install path [#4021](https://github.com/nodejs/node/pull/4021) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) -* doc: update irc channels to point to #node.js and #node-dev [#2743](https://github.com/nodejs/node/pull/2743) - -## Minutes - -### Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) - -Do we want to delay v6 release for OpenSSL 1.1.0? - -James: If we stick with the current LTS cycle, the current version of OpenSSL would be supported for well past the v6 LTS. - -Alexis: Would an OpenSSL upgrade be forbidden once v6 goes LTS? - -James: - -Shigeki: API changes are large, it may be costly to upgrade before LTS. Current 1.0.2 is supported until 2019. It might be best to wait until October - -James: So, better to launch this with v7 than v6? -Jeremiah: What does it give us? - -Rod: There’s a discussion in the thread. - -Alexis: OpenSSL 1.0.2 would be supported for lifetime of v6? - -James: If the changes are large, it’s probably best not to rush it in. - -Brian: I think I agree. - -Alexis: Yes, based on the case presented here. - -James: Does anyone think we absolutely should get v1.1.0 into v6? - -`` - -James: Hearing nothing, I’m going to assume that - -Jeremiah: Do we know Fedor’s opinion on this? - -Rod: He was interested in chacha but that’s about it. -There isn’t really anything hugely compelling here. - -James: I think we’ve got general consensus for not delaying for this. We may have other reasons (V8) but not for OpenSSL v1.1.0. - -Bert: I know only the version number, delaying would require someone to make a case for it. [CD — I missed some of this due to an errant notification] - -Jeremiah: I agree with Bert - -### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -Rod — left this on the agenda to provide an update. It went to the board last week. There was a bit of discussion, it went to the legal committee. They will shape the document I provided into a request for proper legal advice from a paid lawyer, somewhere — something bounded, “please give advice on these points”. the legal committee is meeting tomorrow. - -Bert: OK, cool. Why is this part of the private section of the board meeting? - -Mikeal: I can answer that. You really can’t talk about legal issues in the public section. It’s a strange constraint to be under. I’m pushing to change how we do these meetings. - -Bert: But it’s okay for the CTC to talk about? - -Mikeal: CTC is not fiduciarily bound like the board. - -### Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) - -Rod: No updates. We have got clarification that npm is moving to the LICENSE on master branch, which is the Artistic License. - -### Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) - -Rod: Same bundle as above. - -### AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) - -Rod: We have AsyncWrap in v4 and v5, but undocumented, so breaking changes are okay. The question is whether or not to bring v4’s asyncwrap up to parity with v5. We landed on not documenting it in v4, but making it public in v5. - -James: I have no objections. - -Michael: Are there any performance effects? - -Trevor: No. - -Bert: I find it really strange in the state that node is in, to designate an undocumented API as LTS stable. Three people in the world, maybe, know how this API works. I’d like to have this documented before we freeze it. - -Trevor: Touching asyncwrap means touching everything. IMO it’s more about possible mitigation of issues, because you’re right, it’s totally undocumented, hidden behind process.bindings, by keeping parity, it offers advantages for backporting. It’s in a place where a lot of things will touch it, so not backporting it will make other backports difficult if not impossible. - -Bert: What you want is folks not touching it in an LTS release, because it’s risky, not to freeze it. - -Trevor: Once it is documented, I believe people will want to use it in v4, so at least we’ll have parity between v5 and v4. - -Rod: It’s in v4 now, it’s just not in the same state as in v5; the risk is that we publicize it, folks try to use it on v4, and it breaks unexpectedly. - -Trevor: There are a few places where improper use will trigger an abort. I don’t like the idea that exposing something to JS that can cause abrupt core dumps. - -James: I’d prefer not to document it in v4, - -Chris: I don’t think not documenting it in v4 will keep folks from using it once the docs hit v5. - -[minutes not captured beyond this point] - -### Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) - -## Next Meeting - -December 23rd, 2015 diff --git a/doc/ctc-meetings/2016-01-06.md b/doc/ctc-meetings/2016-01-06.md deleted file mode 100644 index 53b04709de57c8..00000000000000 --- a/doc/ctc-meetings/2016-01-06.md +++ /dev/null @@ -1,216 +0,0 @@ -# Node Foundation CTC Meeting 2016-01-06 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-06 -* **GitHub Issue**: https://github.com/nodejs/node/issues/4553 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Michael Dawson (observer) -* Alexis Campailla (CTC) -* Bert Belder (CTC) -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) -* Steven Loomis (observer) -* Mikeal Rogers (observer) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) -* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) -* gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) - - -## Standup - -* James Snell (CTC): Docs work, refactoring some docs, about halfway through currently. Working on landing some PRs, 4.2.4 release came out before xmas, 4.2.5 next week with Myles -* Trevor Norris (CTC): Working with Fedor to make callbacks reentrant. -* Colin Ihrig (CTC): Opened a PR for the releases doc page, reviewing issues and PRs, working on a PR to libuv -* Brian White (CTC): JS DNS resolver PR updated against master, perf compared to existing impl isn’t very good (yet?), other than that: fixed some flaky tests -* Michael Dawson (observer):Benchmarking infrastructure to generate charts, meeting this week to discuss proposed approach. Chasing down last dependency updates for AIX, adding zLinux machine. -* Alexis Campailla (CTC): Prototyping module building service -* Bert Belder (CTC): Nothing interesting -* Chris Dickinson (CTC): Poking at AsyncWrap -* Shigeki Ohtsu (CTC): Reviewing james doc improvements and small fix for tool. -* Steven Loomis (observer): Some issue review. -* Mikeal Rogers (observer): Foundation strategy for 2016, legal stuff; individual member elections are coming up. -* Jeremiah Senkpiel (CTC): Working on the v5.4.0 release at the time of the meeting. Nothing else interesting. (vacation!) -* Rod Vagg (CTC): Download metrics, analyzing that; put out infographics regarding DL numbers, end of year v4 became the most popular downloaded version, taking over from v0.10, which had been very persistent in its popularity. v5 took over 2nd place from v0.12. Reworking readme in the build repo to mention infra providers. -* Ben Noordhuis (CTC): Gloriously nothing. - -## Review of last meeting - -* Discussion: OpenSSL 1.1.0 planning [#4270](https://github.com/nodejs/node/issues/4270) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) -* AsyncWrap for LTS Argon [#59](https://github.com/nodejs/LTS/issues/59) -* Discuss possibility of adjusting LTS schedule for better alignment with V8 schedule [#62](https://github.com/nodejs/LTS/issues/62) - -## Minutes - -### Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) - -Rod: Ratification is desired here? -James: Any objections to adding Myles and Evan to the release team? - -`[crickets]` - -James: No objections. Who wants to take the lead on adding them? -Jeremiah: I can do that. - -* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) - -_Discussion in minutes doc prior to meeting discussion:_ -> CD: I won’t be able to note this one, so someone should take over for this issue. -> RV: CD - do you have an opinion to offer here? -> CD — yep! mostly: it’s a breaking change that doesn’t seem to be worth breaking things for. -> RV: thanks! - -Rod: do we want to - -Ben: seems like a pointless change, not very compelling, -1 - -Trevor: how’s it going to work when jumping between versions? my history will be all over the place. - -James: haven’t review, is this fixing an actual bug? - -Jeremiah: no, it’s just changing the order that it’s saved. - -Ben: anyone on the call in favour of making the change? - -James: Unless new information is presented, we’re leaning towards not accepting the change. - -### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) - -Chris: last month, @bengl opened a PR to add the doc working group, lots of conversation has been had. Tried to pull out docs from core, came against some difficulties with finding a space to work on them and commiting them back, also wanted to have a better editorial review process so made a new repo and this also has problems because the website repo hosts some docs so docs are spanned across multiple issues. - -Ben: what’s the problem with following the contributing rules/guidelines on the node repo? - -Chris: mainly about relaxing the requirements for commit-bit, having documentation authors able to land PRs, and only docs PRs. - -Mikeal: there are several doc writers who have commit-bits, we’re talking about trying to do the clean-up prior to landing on the node repo by doing it in the docs repo first. Is there still a problem with needing commit-bit for docs people? A lot of them are collaborators already. - -Chris: I think we’re fine - -James: current process has been working well enough, this is just about giving the WG responsibility for the docs directory in the main repo - -Mikeal: sounds like the WG wants to be a holistic group working on docs across the project, not just the docs dir in the node repo? - -Chris: yes - -Mikeal: one problem I have with chartering the group at this stage then is: is the membership representative of all of these efforts? - -Chris: is the parallel effort you’re talking about in the website group? - -Mikeal: yes, and the website group is the most liberal about adding contributors so it’s not very organized - -Chris: last touch-point with the website WG was at the collab summit and they are aware of the docs WF - -Mikeal: in-person meeting not very representative of actual activity, prefer to look at who is actually contributing and pull them into the effort - -Chris: cool, will circle back and look at the two repos and pull in more individuals, concern is about doing lots of work without any guarantee of getting ratified - -Mikeal: we can’t give any guarantees without seeing things - -Chris: big amounts of work re pulling out docs into topic-tocs and tutorials - -Mikeal: but that’s already going on in the website repo, there’s tutorials that are being iterated on so why can’t we just continue that? - -Chris: core docs and tutorials etc. should live in the same place - -Mikeal: still not sure why this single issue is a blocker and how being ratified changes anything - -.. discussion .. - -Mikeal: if you wanted all of the tutorials etc. to live in core then that could just be a PR, if you want the tutorials to be moved out of the website then you’d need to be chartered and have this accepted by the website group - -Chris: problem with building momentum is that the scope of responsibility lives between two groups - -Mikeal: but there’s a ton of momentum going on in the two main places already, moving everything into a separate repo is a separate issue. - -James: need to move on, propose that we continue the conversation there - -Trevor: is there a dot-point list of what this list wants to achieve? - -Chris to update with a link to what this is - -Bert: sounds like this is not about whether this WG should exist but there is a technical blocker that we should focus on. - -James: moving discussion to github, will come back if necessary - -### Legal update - -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) - -Rod: Legal committee had a meeting this week, didn’t quite get through all of it. Not resolved yet but looking like a recommendation to put a simplified license block at the top of each source file. Those were removed in io.js but DCO process discusses license in each source file. Copyright is still Joyent and that was not assigned when things were moved so we need to resolve that. - -(James: Note: we should add that to linting) - -Mikeal: Leaving Joyent in the copyright doesn’t assign new rights but may need to seek their permission to remove. Nor do we need Joyent to assign copyright. - -Rod: npm license issue still being looked at. The way npm licensing is being handled is still being worked out. - -Mikeal: May be moving towards SPDX approach. - -Ben: Question about Joyent boilerplate… is it possible that copyright actually belongs to other entity? - -Mikeal: The copyright is owned by the contributors and Joyent. Going forward, copyright is owned by the contributors. We won’t be assigning copyright to the foundation. - -James: I’ll *possibly* take the todo to get those updated - -Bert: What about binary files? - -Mikeal: It’s unclear. - -James: Can we change the DCO language? - -Mikeal: Modifying the DCO is an expensive process. Recommendation is to wait until the current stuff is resolved. - -### gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) - -Bert: is the “deprecation” language useful here? - -Trevor: this was discussed - -Bert: “deprecation” is not really working - -Jeremiah: there has been some work here - -Bert: I’m against any form of deprecation from now on. - -James: Let’s keep `deprecate` to mean that the thing is strongly discouraged, let’s come up with a stronger term that means this thing will definitely be going away. - -Jeremiah: not sure if this discussion is relevant to the actual conversation. existSync is not something we want to keep because it’s different from everything else. Switch to accessibleSync? - -Trevor: (explains the issues with access and exists on windows vs linux) - -(more back and forth technical discussion about the nuances of determining if a file actually exists and is accessible) - -(James: Let’s have a function that simply returns ‘\_(ツ)_/’ on Windows in response to `accessibleSync()`) - -Trevor: Let’s take the conversation back to Github to see if we can get resolution. Agnostic on the resolution. - -## Next Meeting - -2016-01-13 diff --git a/doc/ctc-meetings/2016-01-20.md b/doc/ctc-meetings/2016-01-20.md deleted file mode 100644 index ceffa500b103b6..00000000000000 --- a/doc/ctc-meetings/2016-01-20.md +++ /dev/null @@ -1,337 +0,0 @@ -# Node Foundation CTC Meeting 2016-01-20 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-20 -* **GitHub Issue**: https://github.com/nodejs/node/issues/4780 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Alexis Campailla (CTC) -* Bert Belder (CTC) -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) -* Steven Loomis (observer) -* Mikeal Rogers (observer) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) -* Domenic Denicola (observer) -* Nikita Skovoroda (observer) -* Ali Sheikh (observer) -* Evan Lucas (observer) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) -* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) -* ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) - -## Standup - -* James Snell (CTC): Working on the Buffer issue, work on HTTP module, reviewing issues and PRs, attempting to help on 4.2.5, -* Trevor Norris (CTC): AsyncWrap related things -* Colin Ihrig (CTC): Reviewing issues and PRs. Reverted a commit -* Brian White (CTC): Not much, commenting on PRs and issues. -* Alexis Campailla (CTC): Fixing Windows issues on libuv and npm -* Bert Belder (CTC): _[CD - missed what you were looking into due to cross talk]_ -* Mikeal Rogers (observer): Various projects coming into the Foundation -* Jeremiah Senkpiel (CTC): Onboarding new release team members, Working on Timers Refactor more, trying to make sure Chakra and Buffer discussions remain productive -* Rod Vagg (CTC): Working with new contributors, lots of meetings -* Chris Dickinson (CTC): Docs WG stuff -* Shigeki Ohtsu (CTC): -* Steven Loomis (observer): -* Ben Noordhuis (CTC): Been sick, still catching up. -* Rich Trott (observer): Making tests more reliable, spinning up Testing WG -* Nikita Skovoroda “Chalker” (observer): mostly buffer, also the api usage greps are now sorted based on downloads count -* Ali Sheikh (observer): sampling heap profiler in V8 -* Domenic (observer): modules and zones -* Evan Lucas (observer): Working on getting v5.5.0 Release out and looking into v8 extras for some of the builtins. - -## Review of last meeting - -* Nominating new Release team members [#4319](https://github.com/nodejs/node/issues/4319) -* repl: Reverses order of .node_repl_history [#4313](https://github.com/nodejs/node/pull/4313) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Potential Licensing issues with npm [#3959](https://github.com/nodejs/node/issues/3959) -* Joyent Copyright still in header of many files [#3926](https://github.com/nodejs/node/issues/3926) -* gripe: deprecating fs.exists/existsSync [#1592](https://github.com/nodejs/node/issues/1592) - -## Minutes - -### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) - -Put on agenda by Alexis - -Alexis: MS submitted a PR for supporting Chakracore, change in node is fairly small — the shim is in the deps folder. A few CTC members have expressed interest in landing. I was wondering if anyone had opinions about how to proceed with this? - -Domenic: I’m curious about what level of support is implied. Landing it reduces the requirement of maintaining a separate fork, but - -Domenic: What’s the CTC’s goal in merging it in? - -Alexis: Adds Windows IoT. - -Domenic: but it doesn’t, because we’re not supporting it. - -Alexis: I still can build it myself. - -James: As for “why would we land it” — if this is something we think we will eventually support, landing it sends a clear signal that this is the direction we are heading. Landing it now lets the community start contributing to it, and to figure out how - -Trevor: If it was landed, we would not be providing official builds on the website. - -Jeremiah: Maybe Canary builds? - -Mikeal: Microsoft is already providing builds of this. By bringing this into the mainline, the changes get reviewed by the Core team. Its a matter of are those builds off of Node core mainline, or - -Jeremiah: Have we decided we want to this? - -Rod: We’re making a lot of assumptions. - -Trevor: Could we start an issue and list concerns? - -Domenic: Would it be a good idea to restrict to collaborators? - -Jeremiah: There’s not enough outside noise. - -Trevor: Well, the PR has garnered over 100 comments in 24 hours. - -Jeremiah: But it’s not spam. - -Mikeal: What is the title of that issue? - -Domenic: “What is the CTC’s decision on whether to merge the ChakraCore PR?” - -Trevor: or, “Things that prevent it from landing” — if we would hold back a V8 version due to incompability with the shim. James mentioned some concerns as well. - -Jeremiah: How are we going to support a shimmed VM — not officially, but for ourselves in the codebase, when we’re still using a V8 api and exposing that. - -Rod: that’s just one of the questions. - -Mikeal: No one is ever going to say “let’s support chakra” until it’s been in the codebase for a while, and has seen the MS folks show up and support it. - -Rod: We still need to get everyone on board that we want to head in that direction. I don’t think it’s fair to say “get it in the codebase and we’ll sort it out”. I see a lot of assumptions in the thread, and we need to air those assumptions and discuss them - -Mikeal: Is the discussion, “do we want to move in a VM agnostic direction?” Can we scope this? - -Domenic: My worry is: I don’t think the CTC might want to imply full VM agnosticity — they might not want to accept a spidermonkey PR? Maybe making it smaller would makemaek it easier. - -Bert: I agree with Rod that we haven’t actually had the discussion. I’ve always thought it was cool, and pushed for it, but I think _[CD ...]_ -What’s frustrating is that someone has done all the work to land a VM, but we kind of expect it to be “more than perfect” before we land it. I would suggest landing it first but not including it as a default, so we can do comparisons. - -Trevor: don’t feel too bad about this — they had to do this to support IoT. -Bert: I don’t feel bad; are we going to build a higher and higher wall until - -Rod: the problem is that we’re not on the same page, and we need to get on the same page. I’m not hearing anyone say outright that they don’t want VM agnostic. But we’re all saying different things. - -James: I agree. I don’t think there should be any rush in getting the PR landed. We can do some of that review process and take our time over the next few weeks to figure out if this is what we want to do. I don’t think anyone is saying “land it now!” We can take our time. - -Rod: My suggestion is to move back to the issue and let it evolve, and suss out the main philosophical issues from there. There’s so many things to talk about in that thread, and everyone’s g -ot a different take. We’ve got to summarize, and take our time. - -### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - -Rod: A vote will be held in a few weeks time. In the meantime we’ll be in observer mode for these additional people. Not much to discuss here other than, “welcome!” - -### buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) -### Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -Rod: want to take it away, James? - -James: Sure everyone’s familiar with the issue up to this point. `Buffer` constructor (`Buffer(num)` or `Buffer(value)` with overloaded). Some portion of the community saying that needs changed, some real world examples of security flaws in the wild, community consensus seems to be that the API should be cleaned up — introducing new factory methods, - -Trevor: Careful saying “community consensus” - -James: Yeah — yes, the discussion seems to lead to where 4682 is now, which has been created as an EPS issue as well (https://github.com/nodejs/node-eps/pull/4). The basic idea is to introduce `Buffer.{from,alloc,allocUnsafe}()`. `allocUnsafe()` would be our current behavior for `Buffer(num)`, alloc would be zero-filled, `.from` takes the place of `Buffer(value)`. Deprecation of constructor would be docs-only, with _possibly_ a warning printed, similar to the memory leak warning on event emitter listeners. The documentation updates go along with that. That’s the overview of the discussion. _[CD phew!]_ - -Bert: What is the argument for not zeroing out buffers, exactly? why do we want to keep supporting that behavior? - -James: comes down to perf - -Trevor: That’s it. You don’t always need to zero fill. - -Domenic: I tried to read through the threads, last I saw there were no benchmarks that were completely fair. `calloc` vs. `memset`, etc. Have there been updated benchmarks? - -Trevor: if the allocation is small enough that it can use the pool, it’s not going to have perf degradation when it becomes larger. - -Domenic: My understanding with larger values is that with calloc makes it free. - -Trevor: No — over 1-4kb. - -Domenic: I don’t know what size “large” is supposed to be for calloc. - -Trevor: I’ve tried for 1mb; perf penalty is 2-3x slower, depending on size. From a dozen to a couple hundred microseconds. - -Domenic: That kind of argues to me for “safe by default.” - -Trevor: I can read in 100’s and 100’s of JSON files all of which are large, I can use fs.read with a buffer, so you have to allocate a buffer, if I have to zerofill it when I’m just going to fill it anyway, that’s just wasted cycle. - -Bert: I think most of the time that will not be the bottleneck. We might have an internal api… - -Trevor: No — the perf penalty on that is so big. This is why I initially got rid of the pooling after my first rewrite. - -Bert: optimization doesn’t have to be done right away. If you’re allocating large buffers, you’re usually mmaping it, so you don’t have to zero fill. - -Ben: But the OS is zeroing it out. - -Bert: So we don’t have to. - -Ben: There’s still CPU time being used there — it’s not free. - -James: The PR has three methods: _[CD — missed the first part]_ `alloc` will do `calloc` under the covers. If a 2nd param is passed, it will do `allocUnsafe` and fill with the string. We can compare all of these using the PR. The current implementation alloc can be 30-60% slower than `allocUnsafe`. - -Ben: We can farm out allocations to another thread, the other thread might need to overalloc a little just to have a bit in reserve. - -Trevor: At minimum that would work for the buffer pool, which is a set size anyway. - -Ben: Is anyone volunteering to write that code? - -James: I already have my hands in there. I need to look into the native buffer constructor anyway. I’ll bring it back to the discussion when I get there. - -Bert: that sounds great. I’m very happy that some experimentation and benchmarking is going on. I’m much in favor of a simple api that is safe by default. Adding a bunch of stuff — like the deprecation in the docs — we are doing too much to deal with not a very complicated issue. - -Mikeal: If you look at all of the exploits, just zero filling doesn’t solve them — they’re still a DoS vector, but no longer a disclosure. WE need the from and alloc APIs to avoid these - -Domenic: that’s a good point. I think adding more explicit APIs would help. - -James: Thank you for pointing that out — it’s an API usability issue. If we decide to zero fill by default this becomes much easier to figure out and we don’t have as much surface area to expand. There is an LTS concern with that — if we switch the default then we run into an issue where we open up a security problem, where modules assume buffer zero fills by default when it doesn’t on the current node version. I’m fine with zero-fill by default. - -Domenic: Real world apps don’t run into perf problems with this quite so often. - -Rod: What do we need to do to move forward? - -James: Ideas on speeding up initialization. Comment on the thread and we’ll go from there. - -### util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) - -Rod: A bunch of +1’s and -1’s. - -Jeremiah: `util._extend` was added Object.assign wasn’t a thing back when we needed it, but since it was publicly exposed, all kinds of folks have used this thing and it’s in wide use. We’re discussing what we want to do with this now that Object.assign is a thing — phase out it’s use? - -Trevor: Is object.assign able to be swapped in? - -Domenic: 95% sure that is the case. - -Trevor: Could we deprecate `_extends` and change it to do Object.assign for the user. - -Domenic: If you overrode object.keys it would give different results. - -Jeremiah: `_extend` is not documented anyway, so for folks to move off of it we’d have to add docs for it or add a deprecation warning - -Rod: my concern: It’s in wide use, it’s undocumented — it just seems like a purist thing to me. “Stop using core stuff!” Apparently Object.assign is a bit slower than extend for our use in core, anyway. I just don’t see any justification for this. - -Domenic: I tend to agree. On the web we’ve got all of this stuff “webkitMatchesSelector” – better to just document it. - -Trevor: I guess what I’m getting at is that there are philosophical issues in trying to - -Document deprecation, but don’t warn on use. - -Domenic is writing a list of minor differences: https://github.com/nodejs/node/pull/4593#issuecomment-173357276 - -### ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) - -Trevor: now that buffer inherits from uint8array, there are undocumented methods on it. If we document that buffer extends from uint8array, then we are supporting those APIs. - -Domenic: I think it’s confusing. Either the TypedArray methods are supported or they aren’t — null them out if they’re not. - -Jeremiah: Probably nulling these things out is a good idea. - -James: in the docs we tell folks that it is a Uint8Array. - -Trevor: Documenting sounds great to me — I can get on that if everyone agrees. - -### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) - -Chris: current state: call for new members (GitHub, Twitter), got significant reach, several people raising hands. Worked to define what membership means in the governance doc. Onboarding people that raised their hands. Had a second meeting for the group today. Everyone happy to work within the node repo, transition period with guides in the website repo before we get them building in the node repo. Don’t want to block core work so happy to do post-review of docs instead of holding up merges. Have a slack for collaboration now too. - -Rod: what would the post-review process look like? Similar to what we have now with the addition of review for style etc. from docs group? - -Chris: Yes, normal process, lgtm from collaborators, etc. Do a weekly review of the changes in the docs directory and do updates for that. Use slack for this by having a GitHub integration. - -Rod: Happy with progress? - -Chris: yes, going well. Building a Roadmap now for what’s going to be done. Need to telegraph what’s going to be done before it’s done. - -Jeremiah: nobody has worked on the doctool for years, is that on the roadmap? - -Chris: Plan is to build something new alongside it. - -Chris: What else needs to be done to move forward with ratification? - -Rod: Sounds like the boxes have been ticked so probably best to move back to the PR-to-core process and bring it for a vote at this meeting. - -### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -Rod: No progress on that. There’s supposed be another meeting, maybe next week — no material update. I’ll keep it on the agenda to make sure we’re updated with the progress. - -### fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) - -Trevor: There’s now realpath in libuv, making the syscall is much faster than going through the JS logic we now have. Using the cache reduces the number of lstat calls — the question is: can we work towards changing the current realpath impl to call realpath in libuv more frequently as our investigation shows is useful — since it’s faster than doing the JS logic, even with the cache. - -Jeremiah: Were there concerns about changing behavior? - -Trevor: If you give it a bad cache it would no longer fail. Some of those issues were nonissues — there’s another one about symlinks. Little edge cases that we wouldn’t consider a problem. - -Jeremiah: If we use realpath(2) that would affect the module resolution? - -Bert: Module also goes through realpath. Hopefully it doesn’t change semantics if impl changes. If the semantics stay the same, it shouldn’t be an issue. Trevor, I’ll give you an issue on why it is the way it is. On OSX, realpath could trigger a buffer overflow, there was no workaround but to write your own. On windows, it used to not exist. We used readlink on all platforms to build our realpath. - -Trevor: To clarify: we make a libuv call, not a syscall - -Bert: Libuv would need to implement this logic — maybe Ben knows? - -Ben: The issue where you could not safely allocate a buffer for the call to store its result in? That used to be an issue with OSX until 10.7 I believe, but we don’t support that anymore, so should not be an issue anymore - -Bert: If we drop WinXP support, it becomes very easy to support - -Trevor: I think we have - -Bert: I’m pretty sure it does not — [cd: might need filled in] - -Trevor: Going to test more, if the results support what you said, are you OK with using the native implementation? This boiled down to throwing away the second optional argument of the cache. - -Bert: The cache has other issues — it can be inconsistent with what’s on disk, for example - -Trevor: We’ll test it and post results. Thank you. - -Bert: cool. - -Rod: do we need to open an issue to officially drop support WinXP? - -Alexis: Changing to prevent install? - -Bert: Sooner rather than later, I think. It’d have to be a major version, and libuv would have to bump to v2 before we could drop the platform. - -Jeremiah: I don’t think that’s an issue on our end. - -Bert: It is — - -Rod: Alexis, are you in on that discussion? - -Alexis: it was a constraint of node, I thought. Everybody agreed that we would prevent node startup on winxp. - -Rod: Back to GitHub! - -### ES Module EP [nodejs/node-eps#3](https://github.com/nodejs/node-eps/pull/3) - -Trevor: One quick thing: bmeck has been working on a EP for ES2015 module loading, figuring out how it could work in node alongside commonJS — originally it was going to be [a?]synchronous. He posted a proposed API for V8, they agreed to implement it, but they want assurances that the CTC agrees on that API. What I want to say: everybody go read the module spec and +1 it. To say “Yes, if V8 adds this API, we will use it to implement ES2015 modules and the Loader spec, too.” Any questions on that? - -## Next Meeting - -2016-01-27 diff --git a/doc/ctc-meetings/2016-01-27.md b/doc/ctc-meetings/2016-01-27.md deleted file mode 100644 index 3e185c973babfd..00000000000000 --- a/doc/ctc-meetings/2016-01-27.md +++ /dev/null @@ -1,295 +0,0 @@ -# Node Foundation CTC Meeting 2016-01-27 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-01-27 -* **GitHub Issue**: https://github.com/nodejs/node/issues/4901 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Alexis Campailla (CTC) -* Bert Belder (CTC) (absent) -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) (absent) -* Steven Loomis (observer) (absent) -* Mikeal Rogers (observer) -* Fedor Indutny (CTC) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) -* Domenic Denicola (observer) (absent) -* Nikita Skovoroda (observer) -* Ali Sheikh (observer) (absent) -* Evan Lucas (observer) -* Rich Trott (observer) -* Michael Dawson (observer) - - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) -* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) - -## Standup - -* James Snell (CTC) — Buffer API change proposal, PR review, error handling summit yesterday, community related issues -* Trevor Norris (CTC) — Writing a patch for Buffer#fill, so it can accept an encoding and a buffer; making MakeCallback reentrant; have a fix but not sure how it’ll affect 3p debugger modules; want to be thorough because this should extend back to v4 -* Colin Ihrig (CTC) — Reviewing issues/PRs, fixing bugs; PR landed in libuv for looking up tmpdir, PR into child process -* Brian White (CTC) — Reviewing/commenting on PRs and issues, working on JS optimizations inside core modules. -* Alexis Campailla (CTC) — Issues/PRs, some work in the testing repo, some work in CI, visual C++ build tools for making modules, investigated a couple issues in libuv -* Chris Dickinson (CTC) — docs WG organization -* Mikeal Rogers (observer) — New education initiatives coming up from Foundation board, legal, working on size & scope of TSC stuff and the incubator -* Jeremiah Senkpiel (CTC) — Administrative and TSC stuff; moderating large issues [CD — thank you!] -* Rod Vagg (CTC) — (Possibly catching up on sleep) -* Ben Noordhuis (CTC) — Reviewing libuv+node PRs, reply to issues, 2 months ahead are busy -* Nikita Skovoroda (observer) — some comments/reviews, nothing interesting. Npm code search update. [JS - Thanks for doing the npm search things!] -* Evan Lucas (observer) — Minor dns/net cleanups, Responding to issues/PRs -* Rich Trott (observer) — Tests, spinning up Testing WG, removing redeclaration of vars from code, especially tests, thus reducing side effects and making it easier to split up tests. -* Michael Dawson (observer) — Benchmarks, results of benchmarks on the website, PPC for big endian machines, V8 testing separate from the node install -* Fedor Indutny (CTC) - Reviewing Pull Requests, fixing issues, V8 code cache API -* Seth Thompson (observer) - Google folks replied to James’ scheduling for face to face meeting for talking about swapping out VMs - -## Review of last meeting - - -* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* buffer: add Buffer.from(), Buffer.zalloc() and Buffer.alloc(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) -* Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* util: deprecate `util._extend` [#4593](https://github.com/nodejs/node/pull/4593) -* ArrayBuffer.isView() and buffer.buffer property [#4420](https://github.com/nodejs/node/issues/4420) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* fs: optimize realpath using uv_fs_realpath() [#3594](https://github.com/nodejs/node/pull/3594) - - -## Minutes - -### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) - -Alexis: No action items on the PR itself, which was locked to collabs, since it was turning into noise. Another issue was opened (roadmap#54) by Mikeal re: whether we should be VM agnostic in the future, there’s discussion of pros and cons as well as talk of how this might happen in the future. Chakra folks are on board for the API wg group / VM agnostic API. - -Fedor: Do we have consensus yet? - -Alexis: Not yet. - -Mikeal: The vast majority agree that we should be moving toward it, - -Ben: Is it actually true? I’ve seen it go both ways. - -Mikeal: I haven’t seen objections to being VM neutral, but how we go about it — there’s no agreement at all. - -James: There’s concerns around language support between the two and how that affects us — there’s a lot of issues like that, related to the “how” we go about this, but there seems to be a consensus that this is the way we want to go. - -Mikeal: I’d like to do this before April? - -Ben: Are there collaborators that haven’t spoken up yet, on the principle that they don’t feel too strongly about it? - -Jeremiah: I’m more in line with Oglas (the guy maintaining JXCore), he’s got a lot of experience with this, and his idea was to move to its own VM. I’m not sure we could - -Trevor: You mean maintaining our own VM? - -Mikeal: I had a conversation with Mark Mayo and he thought that would be the direction we’d actually land. - -Alexis: That would require an enormous amount of resources. - -Mikeal: This PR, you say we locked it to collabs, but aren’t the folks posting it not collabs? - -Jeremiah: In the meantime we can add them to a team for this purpose. - -Alexis: I think it looks like the original PR submitter can still comment. - -Alexis: I can facilitate since I’m in contact with them daily. - -Mikeal: We should create teams for V8 and a team for Chakra, for our convenience. - -Alexis: We do have a v8 team, but I think it’s the Node experts on V8. - -Seth: I can make sure the right people from the team are on there. - -Alexis: And I can create one for the Chakra team. - -Michael: there are a few folks I’d like to add from my team, how would I do it. - -Mikeal: James can do it. - -Another question: assuming we do move this direction, should we start an issue around no longer pulling deps into the source tree? - -Michael: Being vm-neutral doesn’t mean we bring in every VM into the source tree? - -Mikeal: But we’re set up to do that right now. - -Alexis: This also affects ICU. - -Jeremiah: I don’t think this is an immediate concern. - -Fedor: Release cycle — Chakra and V8’s release cycle are not aligned, how will that affect us? - -Alexis: Chakra team has folks dedicated to working with Node’s release cycle, so we would align. - -Mikeal: If we tackle this ABI compatibility problem, we may end up revisiting the release cycle since that’s driven by these big VM breaks. - -### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - -Jeremiah: We’re going to keep this open for a couple weeks while the nominees sit in. The vote is TBD. We don’t do this often so the process is rusty. - -### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) - -James: Where we’re at right now: continuing to update the PR and the EPS proposal that goes along with this based on the conversation. The new APIs seem uncontroversial. Unsurprisingly the name of one method is the most controversial. Currently, it’s allocUnsafe, a few folks don’t like “Unsafe”, would prefer “Raw”. [CD - yay bikesheds!] - -Some of the feedback from Trevor was that the API should be tweaked a bit, where we can pass encoding or a buffer to `.fill`, other than that the conversation around it is dying down. We haven’t decided if we’re going to change the default `new Buffer(n)` to zero-fill — if we do make that change we have to make it all the way down to v0.10 to keep it consistent. - -Mikeal: Call it buffer.remoteDisclosure(). - -Just kidding. - -Ben: if we could make zero-fill as fast as the current impl, then we would of course pick that. - -James: Yes. - -Ben: I’ve been playing with doing init in a separate thread. Perhaps I can close the gap. - -Mikeal: The only objection is perf. - -James: Yep. The baseline impl is that zero fill uses calloc. - -Trevor: We use a pool. It’s always been possible to reach the pool from any buffer instance. Do we want to remove pooling? - -James: Current impl is that zerofill does not pool. - -Trevor: So much overhead! - -_(in document chat)_ - -_Chris: why not use WeakMap for pooling?_ - -_Ben: no weakmaps in v0.10._ - -Jeremiah: Do we have benchmarks for calloc? - -James: Once we get a little further, I’ll revisit benchmarks. - -Trevor: Can the kernel do magic where memory isn’t actually allocated when it’s done in a tight loop? [CD - I didn’t capture this completely] - -Ben: You can mmap memory, memory isn’t actually allocated + zerofilled until you touch it, but touching it causes a page fault. - -### Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -Jeremiah: Looks like we covered this. - -### doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) - -Chris: Onboarded some folks. Completed drafting the docs roadmap proposal. Making sure we have adequate tooling to build docs to the website from the node.js core repo. - -Chris: There is a docs wg meeting next week [10AM PST] [Wednesday @ 10am Feb 3rd] - -Chris: Also working with the inclusivity WG to make a new collaborator guide. - -Ben: No loosening of commit formatting, right? - -Chris, Mikeal: nope - -Jeremiah: Has anyone read through the proposed charter? - -Mikeal: hasn’t changed recently - -Ben, James: read though it recently, lgtm - -Jeremiah: Vote? - -Mikeal: No need, no-one objects. - -Jeremiah: Ok, good to go. - -### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -Mikeal: We’re nearing final documents, and we have some additions to contributing guide that come from legal. The SPDX stuff we talked about. The Foundations IP policy, we mention that we’re going to use CC-4.0 for docs. We should put this to the Docs WG about this. We should have a proper policy from the legal committee really soon. - -Chris: I will bring the CC-4.0 license to the Docs WG. - -### Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) - -Jeremiah: Realpath brought this back up. - -Ben: That was Rod but I can take over. The proposal was to drop vista support in the next major release, that would let us drop a lot of legacy of code. TBH, I thought we had already decided on this, so I’m surprised about this. If you’re not in favor, now would be the time to speak up. - -Trevor: Didn’t libuv drop XP? - -Ben: Nope. - -Trevor: Everything but some subset of the API works on XP? - -Alexis: I also thought this decision was already made. - -Jeremiah: It might have been in some other issue. I seem to recall. - -Alexis: Does anyone object to dropping XP? - -_[crickets]_ - -Fedor: I do! `` - -No objections. - -Alexis: Does anyone object to drop Vista support. - -Mikeal: Let’s get data from NPM. - -Ben: Info was posted on the issue, looks like there’s more XP users than Vista, but still very small percentage. - -Mikeal: Last I checked there were banks that required it, so it’s still out there. - -Trevor: They have LTS, right? - -Colin: If we were going to drop support, that we need to start messaging as soon as possible. - -Alexis: And that we’d put a check so that Node would exit on those platforms. - -Mikeal: It sounds like we’re going to cut some number of users. As long as we’re okay with that… - -Alexis: I think we’re going to support the other users better. - -Trevor: We have v4, and that will be around for [another year? CD] Maybe even V8 won’t support XP by the time v4 expires. - -Jeremiah: I think V8 already stopped supporting it. - -Alexis: I think Nikita articulated that. - -Jeremiah: Seth, if you’re still there, do you have any idea when V8 will drop XP support. - -Seth: We’ve planned that Chrome will probably drop XP support at the same time as … I have to double check. I’ll come back when I find out. - -Mikeal: We’ll drop it, and if anyone complains we’ll just say Microsoft told us to do it :) - -Alexis: I can make the change to stop on startup; in terms of messaging what needs to happen? - -Colin: We just need to get the word out. A tweet or a blogpost or something? - -Jeremiah: We should loop in marketing. - -Seth: It’s April 2016 for sure on the Chrome side. - -Jeremiah: So we have 3 months. - -Mikeal: It’d be a major? - -Jeremiah: Yep. v6. - -Alexis to PR this in. - -## Next Meeting - -2016-02-03 diff --git a/doc/ctc-meetings/2016-02-03.md b/doc/ctc-meetings/2016-02-03.md deleted file mode 100644 index 687cbe7ee7e9a3..00000000000000 --- a/doc/ctc-meetings/2016-02-03.md +++ /dev/null @@ -1,223 +0,0 @@ -# Node Foundation CTC Meeting 2016-02-03 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-03 -* **GitHub Issue**: https://github.com/nodejs/node/issues/5058 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Alexis Campailla (CTC) -* Bert Belder (CTC) x -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) -* Steven Loomis (observer) -* Mikeal Rogers (observer) -* Fedor Indutny (CTC) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) -* Nikita Skovoroda (observer) -* Evan Lucas (observer) -* Rich Trott (observer) -* Michael Dawson (observer) - - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -## Standup - -* James Snell (CTC) — Working on the security fix stuff, buffer stuff, express TLP proposal -* Trevor Norris (CTC) — Commenting, working on making AsyncWrap a public API -* Colin Ihrig (CTC) — Just reviewing PRs and issues -* Brian White (CTC) — Reviewing PRs and issues, submitting various PRs. Working on performance improvements throughout core. -* Alexis Campailla (CTC) — Reviewing issues & PRs, drop XP support PR -* Chris Dickinson (CTC) — Docs WG Roadmap ratified (!), Promises PR -* Shigeki Ohtsu (CTC) — Upgrading OpenSSL and reviewing several PRs. -* Steven R. Loomis (observer) — met w/ TC39/Ecma402 folks to move items forward. worked on full-icu (#3460 - in the agenda) packaging and also locale negotiation https://github.com/nodejs/Intl/issues/10 - recommend docs (?) + small non-core module. -* Mikeal Rogers (observer) — TSC-level stuff, contribution agreement; updates on copyright stuff for core. -* Fedor Indutny (CTC) — reviewing PRs/issues, working on landing c-ares, OpenSSL patches -* Jeremiah Senkpiel (CTC) — Not much notable, TSC things (administrative wrangling) -* Rod Vagg (CTC) — Security issue, administrative wrangling, struggling a little to keep on top of everything -* Ben Noordhuis (CTC) — Wrote some code, reviewed some code, answered questions, replied to bug reports. -* Nikita Skovoroda (observer) — Commenting, nothing significant. Minor work on the npm code search tool. -* Evan Lucas (observer) — Issue and PR review. Looking into some minor stream performance things. -* Rich Trott (observer) — Test improvements; tightening linting rules; finding/closing old/stalled issues/PRs; Testing WG second meeting later this week -* Michael Dawson (observer) — Adding AIX machine, CI jobs, Job for V8 testing in Node tree, PPC BE release machine investigation, Benchmarking infra. - -## Review of last meeting - -* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) - - (Skip, also in this meeting) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - - (Skip, also in this meeting) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - - (Skip, also in this meeting) -* doc: add Docs working group [#4244](https://github.com/nodejs/node/pull/4244) - - Ratified -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - - (Skip, also in this meeting) -* Drop Windows XP (and Vista) support in 6.0 [#3804](https://github.com/nodejs/node/issues/3804) - - Agreed to drop - -## Minutes - -### Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) - -_(Jeremiah: This should probably be the VM neutral discussion https://github.com/nodejs/roadmap/issues/54)_ - -Jeremiah: Someone tagged the roadmap issue on this. It might be more useful to talk about the VM neutrality issue rather than the PR. - -Ben: Has anyone started reviewing the PR yet? - -Alexis: Yes, there was a first review, an update, and a follow-up. I agree that the most interesting discussion is on the roadmap issue. - -Rod: How are we going to make progress on this? Should we wait until after the VM summit that James is organizing, or is there another way? - -Alexis: We could make a high level evaluation of whether we see value in VM neutrality or not, that could make progress. - -Michael: That’s what the issue was intended for in the first place. - -Jeremiah: There’s been a suggestion that the PR should be broken up a bit, to make reviewing more reasonable. - -Mikeal: I think the question CTC needs to answer sooner rather than later: do we hold up Chakra on a resolution, land it on a branch, etc. What is a “good” solution to work from while we don’t have a “perfect solution” [cd - some paraphrasing here] - -Rod: We need the high level questions answered — the ones too hard to answer in github. - -Mikeal: We need to give the people that want to work on Chakra specifically a place to work on it, while we figure out what we want. - -Alexis: Answering whether we want VM neutrality at all could make progress. - -James: Does anyone have objections to being VM neutral, at a high level. - -Ben: Not objections as such, but I do question how valuable it is. - -Alexis: It’s a matter of value vs. cost then. If it’s free, then of course we would add it. - -Ben: Yes. - -Michael: Even if we never add another VM, making the VM bindings more stable is a net win. - -Rod: We do have to be careful assuming this is something people are actually for. - -Michael: Shipping with a different VM might be more controversial than making it _possible_ to ship with a different VM. - -Trevor: [CD interpretation: part of the difficulty is the degree to which VM is complected with node c++, perhaps we should focus instead on a low level JS api.] - -Michael: Would this let us land V8 updates easier? - -Trevor: Once we have a sanctioned API, yes. Buffers are a good example of this. - -Mikeal: There are lots of examples of folks that copy over the entire JS API — even they end up writing something of a shim layer to get native modules. This LLJS API would not be the entire story. - -[CD: Michael and Trevor discuss subsets of APIs to support.] - -Mikeal: We should have this conversation at the summit. Where do we tell folks who want to work on Chakra to work? - -Ben: It only works on Windows. - -Mikeal: We could say, we’re going to put it on a branch, and you can work with the Build WG to produce builds. There’s a lot of MS folk that want to see this work, and we stand to learn a lot from the process of how this works. - -Ben: Are we the first line support? - -Alexis: There is a team of engineers dedicated to this. - -James: We could stand up a separate repo, with its own issue tracker + PRs. - -Rod: It’s also a discussion about the size of the tree. We talking in the build WG about different ways of vendoring to address this. A separate repo sounds interest. - -Jeremiah: Would that separate repo be the shim, or a fork of Node.js? - -Rod: it would be a fork. - -Jeremiah: It’d be nice to have the build process pull in the shim and chakra and build it. - -Rod: There’s a discussion in the Build WG repo about this. There’s not an easy way to do this. - -Rod: In terms of making progress right now, a fork repo is probably the best way to go — reducing the number of - -Jeremiah: I don’t think VM neutral is the way to go, I think our own VM is the way to go. There are concerns in the thread about how we impact userland — it’s unclear how modules will have to support that between different VMs. - -Mikeal: Folks using ES6 transpile. - -[CD and Jeremiah: not always!] - -Rod: The folks who care will do the work — when I publish a module I publish it to work for me — when someone else needs it to work else where they can PR it. The big benefit I see of VM neutrality is that we become part of a competitive landscape of VMs. MS really wants to get into this game, and compete with V8. We see it in the browser ecosystem, where the competition has shifted from perf to features, and it’d be interesting to see that applied to the node ecosystem. - -Jeremiah: Time check. - -Rod: in terms of progress, does anyone object to making a separate repo for this? - -[No objections!] - -### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - -Rod: We’ll leave this for a couple more weeks. Moving on. - -### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -James: Discussion has settled out. No new comments. Updated PR yesterday with a couple changes I discussed with Trevor. Close to being done, just a matter of cleaning up the PR a bit and making sure there are no objections. It is a semver-major. We haven’t decided if we’re going to deprecate the Buffer(n) api. - -Rod: Is it worth jumping in with naming issues — e.g., opposing the word “Unsafe” — now? - -James: Some folk really don’t like typing “unsafe”, but it is, _technically_, unsafe. - -[CD: Perhaps we should call it “allocXtreme”] - -Rod: Personally I don’t want “unsafe”, but I’ve been holding off. - -James: If you’ve been holding off on it, I don’t really care about the name too much. We can take it back to GH. - -### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -Rod: Likely a two line comment at the top of all files. - -### @srl295: [path for full-icu data?](https://github.com/nodejs/node/issues/3460) - ./node_modules vs ./node/ ? (npm linkage) - -Steven: Put together a proof of concept. Core question here is: is full-icu try to use a directory such as node_modules, or is that hijacking it for improper use [cd: unsure if I captured that correctly] - -Result from Nov CTC meeting was “No objections to using node_modules”, and so I’m looking for feedback. - -Alexis: I thought the no objection was to a separate directory. - -Steven: Node module writes into some other known directory. - -Steven: The node installer or deb pkg could have a checkbox to install icu data. - -Rod: We could ship multiple installers. - -Re the package: Perhaps we should use `execPath` to determine installation location? - -Steven: Is execPath relative? - -Rod: It’s absolute. - -Steven: so that would be for global install — local install would use `node_modules/`. - -Rod: We could take a page from npm’s `.bin` and use `.lib`. I’m assuming the problem is that Node needs to look for this before it even gets to module resolution. - -Steven: Right, this has to happen before ~~V8~~ **your VM** starts up. - -Alexis: So I don’t think this belongs in `node_modules/`. - -Rod: Possibly `.node-icu`? - -Steven: Local is `node_modules/.node-icu`? - -Rod: Maybe writing up the details on GH and pulling us in? - -Steven: This is some good progress. It seems like it deals with the problem that it doesn’t overload an actual module; I’ll write up a proposal for this. Probably tomorrow. - -Rod: Any other comments for that? - -## Next Meeting - -2016-02-10 diff --git a/doc/ctc-meetings/2016-02-10.md b/doc/ctc-meetings/2016-02-10.md deleted file mode 100644 index 06bf35994e3ca9..00000000000000 --- a/doc/ctc-meetings/2016-02-10.md +++ /dev/null @@ -1,167 +0,0 @@ -# Node Foundation CTC Meeting 2016-02-10 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-10 -* **GitHub Issue**: https://github.com/nodejs/node/issues/5176 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Alexis Campailla (CTC) -* Bert Belder (CTC) -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) -* Steven Loomis (observer) -* Mikeal Rogers (observer) -* Fedor Indutny (CTC) -* Jeremiah Senkpiel (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) -* Nikita Skovoroda (observer) -* Ali Sheikh (observer) -* Evan Lucas (observer) -* Rich Trott (observer) -* Michael Dawson (observer) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -* Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -## Standup - -* Brian White: Working more on improving performance in various areas of core, reviewing PRs and issues. -* Chris Dickinson: Promises PR + discussions with the error symposium group. -* Rich Trott: addressing flaky tests, enhancing linting, working to find a path to more automation in landing of PRs (although others, including Alexis, seem to have picked that ball up, thankfully) -* James Snell: Working on express stuff in, security stuff out, buffer API finished, moving forward on string externalization. -* Jeremiah Senkpiel: Hook for unhandled rejections that detects when the GC fires on a promise. That is currently blocked on V8 bug with weak callbacks + promises. -* Chris Dickinson: Promises PR + discussions with the error symposium group. -* Trevor Norris — MakeCallback reentrant fix for HTTP parser / AsyncWrap interaction. -* Michael Dawson - Working on getting AIX up in the CI. Also on running v8 tests in the Node tree. Added AIX to libuv tests. -* Steven R. Loomis - not much to add -* Nikita Skovoroda — like ususal, mostly comments and the initial version of the codesearch API on a VPS. Nothing major. -* Rod Vagg - Security stuff, catching up on issues and discussions. Legal committee meeting yesterday. - -## Review of last meeting - -* Enable Node.js to run with Microsoft's ChakraCore engine [#4765](https://github.com/nodejs/node/pull/4765) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) -* @srl295: [path for full-icu data?](https://github.com/nodejs/node/issues/3460) - ./node_modules vs ./node/ ? (npm linkage) - todo, update ticket with meeting resolution - - -## Minutes - -### Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) - -Rod: Simple deprecation warning for the particular argument usage. Pulling in the internal util module for deprecation messes up older versions of graceful-fs (and thus older versions of npm.) The question is whether to revert the PR, or to add a helper (that Nikita proposed.) I would suggest that this is urgent enough that we need to do something about it. - -Jeremiah: This is a poor reason to revert it. -James: From everything that I’ve seen, adding the warning is the least bad option. Folks seems to be against reverting. Maybe making the warning less specific to graceful-fs. - -Ben: I don’t agree. I think it’s right to point them to the newer version. - -Jeremiah: I agree (with Ben). - -Rod: Anytime you break the build, it’s an immediate candidate for reversion. It’s not permanently reverted, but it’s “let’s fix the build.” - -Jeremiah: This doesn’t actually break CI though. It breaks newer versions of npm on master. .. It might be npm in general just on the master branch. - -James: Forrest noted that pretty much any change other than reverting will have a significant effect on the npm user base. - -Jeremiah: Yeah but we’re not shipping this in a stable. - -Michael: If it breaks in master, doesn’t that prevent folks from doing other tests? - -Ben: I think the problem lies with npm here. - -Mikeal: You make that sound so easy. - -Ben: The version of npm we’re talking about is still in a PR, yes? - -Jeremiah: We don’t regularly run tests on master, so it might already be broken. I can test it right now.. - -Rod: I think Myles has been trying to run the npm tests more regularly, as part of smoke testing — and it’s broken for the smoke testing now. - -Michael: It seems like we’d want to keep things as green as possible. It seems like we’d want npm to do something. - -Rod: It’s a fact of life that we exist in an ecosystem that has these kinds of issues. My vote is to revert, and then revisit after we’ve gotten the build fixed. - -Ben: Well, yeah, I do. I think Nikita’s PR is an acceptable intermediate solution. - -Jeremiah: Likewise. The resolution is that we try to require it, if that fails, we use a deprecation helper we build in that emits a warning that something is breaking an internal module — that would fix it and seems quite reasonable. It will also help people note where stuff is going to break. - -Rod: Does someone want to help Nikita get this in? - -Ben: Didn’t you already get a couple of LGTMs? - -James: I think there’s one -1 and three LGTMs. - -Rod: We can force it if we have to. - -James: I propose: if we accept this now, let’s try to get it resolved better before v6 goes out — which gives us a deadline so it’s not pushed off indefinitely. npm gets a fix, and that’s where it happens. - -Ben: I think it’s a good idea to push npm to update their dependencies. Whether or not npm updates, I think it’s a good idea to include Nikita’s PR. - -Jeremiah: I think so too. - -Rod: Let’s take it back to GitHub. - -### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -James: There were some changes I was waiting for from Trevor w/r/t fill encoding. There was a desire to bikeshed a bit more on the name, not sure if you want to do that here. I think absent that the PR is probably in a place where we can land it. - -Rod: Sounds like we need a last call for objections, otherwise it’s going in. - -James: Yep. - -Rod: How about you do that on GitHub? - -James: OK. - -Jeremiah: Are you adding a zero-fill flag? - -James: Yes — it will switch all allocations to use calloc under the hood. The one thing this does not do is change the default behavior of `new Buffer(size)`. If we did that, it would be a breaking change going back to 0.10. - -Bert: Is the plan to deprecate it off the table? - -James: It’s a soft deprecate — docs only. - -Jeremiah: We should try to just deprecate it. The problem is that folks are running different versions against modules, and it would be bad to rely on zero-fill behavior where it doesn’t exist [CD — didn’t capture this entirely] - -James: We need to refine our deprecation strategy — and define whether something is deprecated vs. end-of-life. Will probably be returning to that next week or the week after. - -Rod: It sounds like we’ve got a way forward, here. - -Bert: It’s ugly but I won’t object. - -Rod: Noted. - -### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - -Rod: We should start to line up a vote. - -### Seek legal advice on LICENSE and copyright blocks in code [#3979](https://github.com/nodejs/node/issues/3979) - -Rod: There was a PR that Mikeal put in that updates the DCO from v1.0 to v1.1. If you’d like to review that, please comment on that. - -### Other business - -James noted that the express application landed today. I will be working to move that into the new organization. More of an update on tomorrow’s TSC call. - -Jeremiah notes that he will be a bit preoccupied by that for a while. - -## Next Meeting - -2016-02-17 diff --git a/doc/ctc-meetings/2016-02-17.md b/doc/ctc-meetings/2016-02-17.md deleted file mode 100644 index 25aa39594043cd..00000000000000 --- a/doc/ctc-meetings/2016-02-17.md +++ /dev/null @@ -1,240 +0,0 @@ -# Node Foundation CTC Meeting 2016-02-17 - -## Links - -* **Audio Recording**: https://soundcloud.com/node-foundation/ctc-meeting-2016-02-17 -* **GitHub Issue**: https://github.com/nodejs/node/issues/5274 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* James Snell (CTC) -* Trevor Norris (CTC) -* Colin Ihrig (CTC) -* Brian White (CTC) -* Alexis Campailla (CTC) -* Bert Belder (CTC) -* Chris Dickinson (CTC) -* Shigeki Ohtsu (CTC) -* Steven Loomis (observer) -* Fedor Indutny (CTC) -* Rod Vagg (CTC) -* Ben Noordhuis (CTC) -* Nikita Skovoroda (observer) -* Ali Sheikh (observer) -* Evan Lucas (observer) -* Rich Trott (observer) -* Michael Dawson (observer) -* Seth Thompson (observer) -* Mikeal Rogers (observer) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -* Issue management: discuss caine again [#5246](https://github.com/nodejs/node/issues/5246) -* refactor src/node.js into internal files [#5103](https://github.com/nodejs/node/pull/5103) -* process: add 'warn' event [#4782](https://github.com/nodejs/node/pull/4782) -* CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) -* Check in ICU into repo? [#3476](https://github.com/nodejs/node/issues/3476) - Steven R. Loomis - +1 on checking in <45M into repo? so Jenkins servers will never again have to download ICU -* Detect ICU data at startup? [#3460](https://github.com/nodejs/node/issues/3460) - Steven R. Loomis - +1 on ≈/node_modules/.node-icu ? - - -## Standup - -* James Snell: Working on a few PRs, the buffer change, the process.warning, looking at doc updates — backporting. Looking at other PRs, getting ready for conference. -* Trevor Norris: AsyncWrap bug on raspberry pi, getting two tcpwraps when creating a server instead of just one. -* Colin Ihrig: Review of issues tagged with child_process label and PR for adding options to process.send(). -* Brian White: fixing bugs, cleaning up code, more performance testing, reviewing PRs and issues. -* Bert: N/A -* Alexis: Mostly working on chakracore, moved the repo from ms/node, define participation guidelines; adding support in CI -* Chris Dickinson: Promises PR + WG (https://github.com/nodejs/promises). Microtask queue pluggability (https://github.com/chrisdickinson/node-1/pull/2). -* Shigeki Ohtsu: Reviewing a few PRs and issues and make my internal works. -* Steven R. Loomis: Intl packaging stuff -* Fedor Indutny: Reviewing PRs, fixing issues -* Rod: Promises, v5.x management, people & administrative stuff -* Ben: Promises PR, and ES2015 module interop, there’s a lot to take in, no fully formed opinions yet. -* Nikita Skovoroda: mostly comments and reviews, as usual. -* Ali Sheikh: Back from 2 weeks of vacation. Catching up on mail & jetlag. Progress on Sampling Heap Profiler in V8. Was involved in Error summit before vacation. -* Evan Lucas: Working on some http things (cleanup, etc.). Wrote CLI tool for submitting jenkins builds and viewing CI status. -* Rich Trott: flaky tests; updating ESLint; finding stale issues and closing, tagging, or taking other appropriate action -* Michael Dawson: Working through AIX issues, landing pr, working on setting up job/answering question on running V8 tests in Node tree, benchmarking infra/new benchmarks, discussion with Richard on post-mortem WG activity and work, trying to read issues with high traffic. -* Mikeal Rogers: Foundation stuff, DCO 1.1 patch. -* Seth Thompson: Traveling the past week or so; working on revamping profiling and metrics on our perfbots, and trying to get Node building on the chromium bots, to assist with the benchmarking WG. - -## Review of last meeting - - -* Revert "fs: deprecate fs.read's string interface" [#5163](https://github.com/nodejs/node/pull/5163) & fs: add a temporary fix for re-evaluation support [#5102](https://github.com/nodejs/node/pull/5102) -* buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -## Minutes - -### Issue management: discuss caine again [#5246](https://github.com/nodejs/node/issues/5246) - -Fedor: A year ago I submitted an idea, and we tried it for a bit, to use a GH bot to help us manage issues on GH. This was to address the pace of issues. The idea was to introduce a bot that automatically assigns issues to people based on tags & user responses to questions. It didn’t take off at the time, the reason being we didn’t want to be too automatic. Chris had some issues with it. I wanted to see if we could take another look. - -Mikeal: Today GH slipped in an issue template feature. We may want to investigate that. - -Fedor: Indeed this should solve the thing for us. We can ask folks to mention some specific working groups. - -Bert: I also had objections to the first version of caine, I felt like it would only add noise — it would still ask questions even if the issues had been answered. I would suggest we start with the template then look at what caine could add to it. Maybe autotagging? - -Mikeal: We have a lot of folks tagging, but we don’t have a good way for limiting email notifications. Maybe autoassign tags to users? - -Bert: I am not opposed to this. - -Mikeal: Maybe it should never comment. - -Fedor: I kind of disagree with this. My workflow: I was actively using GH teams to filter emails. If the bot would be able to assign the tags — and cc teams in a single comment. - -Chris: I’d second that. - -Rod: I’d advise starting light; it may get pushback if it comments too much. - -Ben: What exactly would you change? - -Fedor: Autotagging based on responses in template. We’ll ask folks to name the part of core in the template, and add a mention of the relevant GH team so that they get notifications. - -Mikeal: If someone wanted to take on an interesting side project, feeding issues + tags into ML would be pretty cool. - -Bert: I think that’s a really interesting idea actually. - -Mikeal: Maybe some IBM folks that have access to Watson could do this? - -Bert: Maybe we could give interested folks an account? - -James: [CD: Paraphrasing: It seems possible.] If anyone’s interested in this, send me a note offline. - -### refactor src/node.js into internal files [#5103](https://github.com/nodejs/node/pull/5103) - -Jeremiah tagged this one. Tagged because it’s heavy-handed into splitting `src/node.js` into sub-files in the internal directory. - -James: It is a big change, but it seems to be one that’s fairly safe. I didn’t notice any things that would obviously break. Given the code that it does touch, it’s worth being conservative and careful pulling it in. I’m +1 on it, but I think we need to be careful. - -Chris: Naming issues. - -Ben: Memory overhead. Script objects have a moderately sized footprint, so that’s a thing to keep in mind. - -Rod: I think we could name the files with `bootstrap-`. With regards to any objections to doing this… There’s the usual fear re: size of changes, memory, breaking people’s workflows. Is there anything else to discuss here? - -Michael: Suggest running the footprint benchmark to get a feel. - -Ben: Will post on GH. - -[CD: Moved to GH] - -### process: add 'warn' event [#4782](https://github.com/nodejs/node/pull/4782) - -James: Came from how we do warnings currently, which is to drop it out into console.error now. This restructures it a bit to put it into a warning event on the process object, allows users to listen to those warnings. Mainly looking for review. Existing command line arguments are still supported, but messages are changed a bit. Adds ability for us to add warning for security purposes or bad practices. Process.emit ‘warning’ allows users to emit their own warnings. It came up via the buffer changes — where we could issue a warning for users using the new Buffer constructor in an unsafe way. Just looking for review, nothing too controversial. - -Trevor: The buffer constructor needs to have to have the same signature as Uint8Array for subclassing purposes. - -Michael: This captures all output to stderr from core? - -James: No, just the warnings, like the EE maxlisteners warning. The default behavior is to print it to console, but it may be overridden by user handlers. Folks from electron have said that this is something that they like. - -Rod: Any concerns or objections raised in GH? - -James: Not thus far — tty check raised by Jeremiah - -Trevor: Does it sent the output to stderr/stdout only or could one provide a file descriptor? Looks like you're building a messaging system... - -James: Default behavior is to print to stderr, but you can turn off this behavior by installing your own listener. - -Chris: Are we sure no one’s using process.emit(‘warning’)? - -James: Did a search and came up with no results. - -Chris: Excellent. - -Rod: It’s more than adding an event, it’s worth taking a look. - -James: [CD: my internet is flaking out] Mostly trying to get it on folks’ radar. If folks can take a look and provide their feedback. - -Rod: FWIW I think this is a great change. Unifies and adds some nice functionality around these warnings. - -### CTC Membership Nominations [#4750](https://github.com/nodejs/node/issues/4750) - -Rod: Any objections to putting this to a vote next week? - -[crickets] - -### buffer: add Buffer.from(), Buffer.alloc() and Buffer.allocUnsafe(), soft-deprecate Buffer(num) [#4682](https://github.com/nodejs/node/pull/4682) & Buffer(number) is unsafe [#4660](https://github.com/nodejs/node/issues/4660) - -James: added ability to specify byte offset and length, both to `.from` and [CD: missed this] - -James: No significant objections, except to allocUnsafe which folks really don’t like the naming of. This is shaping up, we should be able to get that landed fairly soon, just need to hear from this group if there’s objections on naming or status of this? - -Rod: Myself and Trevor still don’t like the name. I’m not willing to object too strongly to that. - -Bert: The names are ugly, but I don’t want to bikeshed. Same as Rod, I guess. - -James: If I could ask folks to do a final review, it’s a big PR. All buffer uses in core are updated to use this. Let me know if there’s any objections. I’d like to get this landed before too long. - -Trevor: The documentation changes are what took me the longest to get through. - -Rod: Documenting this stuff has caused problems in the past. - -### Check in ICU into repo? [#3476](https://github.com/nodejs/node/issues/3476 ) - Steven R. Loomis - +1 on checking in <45M into repo? so Jenkins servers will never again have to download ICU - -Steven: Speaking of massive PRs! I haven’t created the PR for this. I have been doing some slicing on ICU, I have now a 45mb branch that includes all of ICU, enough to build a full set or a full-icu, or a small icu, and removes the requirements for the servers to download anything at all at build time. I’m asking for sign-off on this. It would make small-icu the default for `./configure`. - -Steven: it will be located in source: `deps/icu` - -Trevor: How often would this need to be updated? - -Steven: [CD - missed this] - -Trevor: A good chunk of the deps/v8 updates include tarballs. - -Ben: Does it write the data files at compile-time? - -Steven: This just checks in the binary blobs. - -Ben: In that case Trevor makes a good point. - -Steven: The data file is not compressed, it does compress fairly easily. (59% by gzip) - -Trevor: One of the original reason for not landing this was that the source files were 200mb, but when they’re compressed down they’re 45mb. Git works better with the former. We’d almost have to do a test to see which is a more sustainable in the long run. - -Steven: Including the source data means that the source data has to be compiled which takes a long time. (+75M source + tools) - -update schedule - http://source.icu-project.org/repos/icu/data/trunk/meta/xml/icumeta.json - -Trevor: We’ve discussed all of this. If we just include English, how do we present this on the website? There’s a lot of contention - -Rod: I’ve had trouble getting my license updater to work because not having it in-repo breaks things. On the other hand, the repo is growing at a fast pace, and it’s pretty bad UX (have you ever tried cloning the Mozilla repo?) - -Chris: It seems like including the full source - -Steven: We could do the 20mb, only 3mb of which is the binary blob. And we could pick it up every year. full data available via npm (see next issue) - -Ben: what about security releases? Do those require updating the binary blob? - -Steven: No. - -Trevor: My only concern is the binary blobs. - -Rod: Let’s start with the small binary blob will allay a lot of our concerns here. - -Steven: I may be able to slice the 20mb more. This is with no configure source changes to ICU. It may be further reducible. - -### Detect ICU data at startup? [#3460](https://github.com/nodejs/node/issues/3460 ) - Steven R. Loomis - +1 on ≈/node_modules/.node-icu ? - -Steven: This is the companion to the above. The basic idea here is that I went through the resolver code and what I’m proposing is having the data files in a directory inside of `node_modules/.node-icu`, installed by npm module or by some other installer could install it to that directory. - -Trevor: Has there been any thought to some sort of integration with npm? - -Steven: I hadn’t thought about that. Nathan had commented much earlier, concerned with linkage between Node and npm. This only uses the node_modules directory, not npm itself. -Chris to point CLI team at issue. - -### Other business - -_Discussed decision making process around the Promises PR_ - -## Next Meeting - -2016-02-24 diff --git a/doc/ctc-meetings/2016-05-04.md b/doc/ctc-meetings/2016-05-04.md deleted file mode 100644 index 3b5abb7ad98901..00000000000000 --- a/doc/ctc-meetings/2016-05-04.md +++ /dev/null @@ -1,192 +0,0 @@ -# Node Foundation CTC Meeting 2016-05-04 - -## Links - -* **Audio Recording**: https://www.youtube.com/watch?v=3M95wsWs7qQ -* **GitHub Issue**: https://github.com/nodejs/node/issues/6567 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Bradley Farias @bmeck (observer/modules EPS/GoDaddy) -* Brian Terlson @bterlson (observer/modules EPS/tc39/Microsoft) -* Сковорода Никита Андреевич @ChALkeR (CTC) -* Colin Ihrig @cjihrig (CTC) -* Evan Lucas @evanlucas (CTC) -* Jeremiah Senkpiel @Fishrock123 (CTC) -* James M Snell @jasnell (CTC) -* Josh Gavant (observer/Microsoft) -* Michael Dawson @mhdawson (CTC) -* Brian White @mscdex (CTC) -* Rod Vagg @rvagg (CTC) -* Seth Thompson (observer/Google) -* Shigeki Ohtsu @shigeki (CTC) -* Steven R Loomis @srl295 (observer/IBM/ICU) -* Trevor Norris @trevnorris (CTC) -* Rich Trott @Trott (CTC) - - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* Revert 5950 [#6537](https://github.com/nodejs/node/pull/6537) -* src: refactor constants, deprecate require('constants') [#6534](https://github.com/nodejs/node/pull/6534) -* doc: refactor the changelog by version [#6503](https://github.com/nodejs/node/pull/6503) -* Request for discussion of https://github.com/dherman/defense-of-dot-js vs EPS on modules - - - -## Standup - -* Сковорода Никита Андреевич: - * Nothing too significant, some comments (as usual). - -* Colin Ihrig: - * A few PRs - * Reviewing issues and PRs - -* Evan Lucas: - * Submitted a doc and util pr. - * Working on a http bug. - * Been trying to help some packages get updated to work with v6. - * Left some comments on a few issues. - * Have been working on a commit validator tool. - -* Jeremiah Senkpiel: - * v6 Breaking changes doc - * working on v6.1.0 release - * assorted PRs, Issues, EPs -- done a bunch of reviews - -* James M Snell: - * v6 Release - * Fixed 2 util.inspect bugs (proxy and array length) - * Helped troubleshoot buffer indexOf/lastIndexOf bug - * Troubleshooting 5950 issues - * Work on error code refactoring - * Work on constants refactoring - * Work on changelog refactoring - * Ongoing http implementation security / spec compliance review - * Working on compliance follow ups from vm summit - * Investigating possible alternative solutions for stdout/stderr - non-blocking issues - -* Josh Gavant: - * Testing use of trace-event macros, designing tracing module, reviewing AsyncWrap and alternatives. - -* Michael Dawson: - * Investigated ppc be release machine issues - * validating be build from nightly release job - * AsyncWrap EP review - * switched benchmarking vof v6 over to new v6 branch - * wrote/submitted stable ABI module EP - * misc reviews/lands - -* Brian White: - * Worked on http server code refactor and other http performance improvements - * Reviewed PRs/issues - -* Rod Vagg: - * Time off, now catching up - -* Seth Thompson: - * continue to work on getting v8 inspector to work with node - * meeting with Ali as he.s visiting in person - -* Shigeki Ohtsu: - * Upgrading openssl and reviewing one PR for GCM IV - -* Steven R Loomis: - * turn/rebase/clean ci for https://github.com/nodejs/node/pull/6088 ( checkin ICU into master ) and https://github.com/nodejs/node/pull/4253 ( v8BreakIterator to throw error rather than fatal crash - * opened Doodle poll to get Intl WG going again (monthly) https://github.com/nodejs/Intl/issues/33 - -* Trevor Norris: - * Don't abort on access of invalid pointer returned by Unwrap PR - * Tuning the AsyncWrap EP and writing patches as result - -* Rich Trott: - * Added undocumented-for-now -F flag to jslint.js to automatically fix lint issues. Dog-fooding it right now. Give it a shot if you.re brave. - * Open PR to have `known_issues` tests run via CI and `make test`. PTAL. https://github.com/nodejs/node/pull/6559 - * Assessments for long-dormant issues. - -* Bradley Farias: - * Investigated counter proposal details to node EP for modules - * Started test framework for modules EP - - -## Review of last meeting - - -* governance: add new collaborators XII [#6282](https://github.com/nodejs/node/issues/6282) -* doc: doc-only deprecation for util.log() [#6161](https://github.com/nodejs/node/pull/6161) -* Check (small) ICU into repo [#6088](https://github.com/nodejs/node/pull/6088) -* doc, tls: deprecate createSecurePair [#6063](https://github.com/nodejs/node/pull/6063) -* Planning for v6 [#5766](https://github.com/nodejs/node/issues/5766) -* Introduce staging branch for stable release streams [#6306](https://github.com/nodejs/node/issues/6306) -* ES6 Modules detection update / https://github.com/nodejs/node-eps/issues/13 - - -## Minutes - -### Revert 5950 [#6537](https://github.com/nodejs/node/pull/6537) -* James: Bug picked up in v6 for symlinked peer dependencies, our tests/CI didn.t pick it up unfortunately. Proposal is to revert the change and review it after adding some tests for this. -* Rod: there was some discussion about a revert being semver major -* Jeremiah: not optimal, reverting is technically a semver-major -* Rod: does anyone have an objection to a revert at this stage? -* Jeremiah: I believe some of the new behaviour was useful, is there a path to reintroducing it? -* James: least invasive route would be to add the new behaviour behind a flag, there are some other approaches being investigated. The folks who proposed this change in the first place are behind the reversion at this stage. - -### Request for discussion of https://github.com/dherman/defense-of-dot-js vs EPS on modules - - -* Bradley: we merged our proposal last week and afterward a counter-proposal (that we.ve been waiting on for many weeks) showed up. The proposal is a package.json-based solution. It does address all of the major use-cases of Node and it does this in slightly different ways than we.ve seen before. It.s still lacking some existing behaviour of CJS files (you can.t detect some filepaths for CJS), e.g. ~/.config.js. It introduces a path-expansion mechanism. You add a module.root to your package.json. I still have concerns about this but it.s much better than the previous ones based on package.json. I.ll be having a more in-depth conversation with Brian Terlson (TC39/Microsoft), if anyone wants to join. -* Jeremiah: is the main downside of the file extension about sharing files from servers that aren.t configured for it? -* Bradley: yes, the main concern is about firewalls and configs that block transmission of the new files. -* Rod: can you help us empathise with the sentimentality around the file extension, are there objective problems that we are not picking up on? -* Bradley: there.s a concern . _something about a lodash example_ . shell scripts not finding the new files with *.js. -* Brian Terlson: there.s an expectation that JavaScript is contained in a .js file and we.re in a nice place now that this is true with some minor exceptions. For TypeScript we.d have to add a .mts and .mtsx extension. -* Rod: _asking about the sentimentality again_ -* Brian Terlson: that.s a mischaracterisation of the defense of .js proposal -* Jeremiah: there will be developer friction either way -* Brian Terlson: but friction will be limited to node developers as opposed to all javascript developers -* Rod: what state is standard ? -* Bradley: Some pieces still have minor changes going on but mostly locked down. -* Brian Terlson: we have been thinking about all of these kinds of things during the whole process. I don.t think spec changes are off the table, TC39 could reconsider some aspects of the spec to improve matters. No promises, but don.t feel like you shouldn.t bring it up because we.re so late in process. -* Bradley: forward detection is the main problem. Have examples of specifics. As long as implicit strict mode is enforced we are going to have a hard time. -Rod: what.s the path forward ? On our side seems like strong preference is still on the file extension side. -* Bradley: Either way was ecosystem effects. Personally towards file extensions, most response on social media is either .better than nothing. or .don.t like file extension but not pushing for package.json either.. Will discuss further with Brian and others from Microsoft. -* Rod: EP does not mean it is final, but it does mean it is the preferred way forward and CTC members would have to be convinced otherwise. -* Bradley: likely need longer discussion in next week or so either way. - - -### src: refactor constants, deprecate require('constants') [#6534](https://github.com/nodejs/node/pull/6534) -* James: recent PR asking to add new constant. They are mentioned in the docs in a few places, but not well documented. Figured should take a run at documenting and refactoring to make it make more sense. Cleans up the structure and properly documents. Would it be semver major since we have never documented before ? -* Jeremiah: marked as semver major because it was deprecating existing constants. -* James: hard deprecation pretty much blows up everything as npm uses them ,etc. Thats why it is a soft deprecation. -* Jerimiah: we should find way to document -* James: add to release notes saying to use the new versions. -* Rich: Move discussion back to github -* Rod: Any objection to doing this, want consensus before we spend a lot of time doing it. - - -### doc: refactor the changelog by version [#6503](https://github.com/nodejs/node/pull/6503) - -* James: changelog grew to point where it is no longer visible/usable on github. To make it at least visible it was temporarily split out into an archive. This PR is to split it out by version instead. Each version release would link to the individual version change log. One at top level becomes an index to the version specific ones. Acceptable or do we need another approach? Archive for io.js release and before v.10. Should not add too much additional work to release process. -* Rod: maybe io.js ones should be in separate files as well instead archive. -* Jeremiah: io.js v1 has particularly large set of changes -* James: any major objections ? -* Rod: take it back to github, roll forward unless objections on github. - -### Q/A on public fora -* call for questions on public channels. -* no existing ones so far. -* will wait a few minutes to see if any come in -* ok moving on. - - -## Next Meeting - -2016-05-11 diff --git a/doc/ctc-meetings/2016-06-15.md b/doc/ctc-meetings/2016-06-15.md deleted file mode 100644 index 6fce3b0d4d72e4..00000000000000 --- a/doc/ctc-meetings/2016-06-15.md +++ /dev/null @@ -1,174 +0,0 @@ -# Node Foundation CTC Meeting 2016-06-15 - -## Links - -* **Audio Recording**: https://www.youtube.com/watch?v=qWX8i9SKatQ -* **GitHub Issue**: https://github.com/nodejs/node/issues/7307 -* **Minutes Google Doc**: -* _Previous Minutes Google Doc: _ - -## Present - -* Bradley Meck @bmeck (observer/GoDaddy) -* Сковорода Никита Андреевич @ChALkeR (CTC) -* Chris Dickinson @chrisdickinson (CTC) -* Evan Lucas @evanlucas (CTC) -* Jeremiah Senkpiel @Fishrock123 (CTC) -* John-David Dalton @jdalton (observer/Microsoft) -* Josh Gavant @joshgav (observer/Microsoft) -* Michael Dawson @mhdawson (CTC) -* Brian White @mscdex (CTC) -* Ali Ijaz Sheikh @ofrobots (CTC) -* Alexis Campailla @orangemocha (CTC) -* Rod Vagg @rvagg (CTC) -* Rich Trott @Trott (CTC) -* Trevor Norris @trevnorris (CTC) - -## Agenda - -Extracted from **ctc-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. - -### nodejs/node - -* url: return valid file: urls fom url.format() [#7234](https://github.com/nodejs/node/pull/7234) -* http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102) - -### Standup - -* Bradley Meck @bmeck - * fleshing out a proposal for if we could disambiguate the grammars for Script and Module. - -* Сковорода Никита Андреевич @ChALkeR (CTC) - * some issue/PRs reviews - -* Chris Dickinson @chrisdickinson (CTC) - * NodeConf - * modules.guide - -* Evan Lucas @evanlucas (CTC) - * Preparing for security release - -* Jeremiah Senkpiel @Fishrock123 (CTC) - * (Previous week: fixed the primary OS X stdio bug) - * NodeConf - -* Fedor Indutny @indutny (CTC) - * fixing bugs, reviewing PRs, working on llnode - -* Josh Gavant @joshgav - * debug protocol stuff - -* Michael Dawson @mhdawson (CTC) - * Still chasing PPC machine issues - * AIX/malloc(0) issue - * ABI stable module API work with Stefan/Ian, filling in Nan examples - * Input on some benchmarking related PRs - * Other misc reviews/lands - * Keeping up with issues - -* Brian White @mscdex (CTC) - * Landed some old PRs - * Submitting PRs to fix some regressions - * Reviewed PRs and issues - -* Ali Ijaz Sheikh @ofrobots (CTC) - * More work on v8_inspector - * Starting to look at backporting some V8 fixes for LTS - -* Alexis Campailla @orangemocha (CTC) - * Landed a fix for node-gyp, broke with VS update 3 - -* Rod Vagg @rvagg (CTC) - * Alpine Linux in CI - * Security release hoo haa - * Reviews & discussions - * Electron / Node relationship - * New CTC repo - * Jenkins upkeep - -* Rich Trott @Trott (CTC) - * Setting up the next onboarding - * Facilitated a session on releases at NodeConf. Will share notes with Build WG, LTS WG, and people who can sign releases. - -* Trevor Norris @trevnorris (CTC) - * Finished updating AsyncWrap EP and now investigating proposed implementation. - * Helping identify old issue in Atom editor in regards to writing to disk. - - -### Review of last meeting -* Tracking issue: stdio problems [#6980](https://github.com/nodejs/node/issues/6980) -* module: expose `Module._runInThisContext` [#6288](https://github.com/nodejs/node/pull/6288) - - -## Minutes - - -### url: return valid file: urls from url.format() [#7234](https://github.com/nodejs/node/pull/7234) - -@trott: semver-major change, needs approval from CTC. -Real fix will be @jasnell’s HTTP compliance work. - -In browsers `file:/home/joshgav/myfile.txt` is auto-corrected to `file:///home/joshgav/myfile.txt` (i.e. slashes are prepended to the path and hostname is an empty string). This change institutes the same in Node.js. - -Are there other protocols which require additional slashes (`//`) if hostname isn’t specified? Yes, but hard to heuristically determine if needed. - - -### http: don't inherit from Object.prototype [#6102](https://github.com/nodejs/node/pull/6102) - -Replace headers object ({}) in req/res with StorageObject, which doesn’t delegate to Object.prototype. But this will break anyone using regular `Object` methods on header props. - -@trevnorris: Why don’t we intercept calls to properties with checks to an internal dictionary of actual headers? If the key isn’t there, then try to call Object.prototype. - -How would that effect perf? - -It’s the right decision because otherwise can’t use headers with certain names like `__proto__`. - -Better to do a deprecation cycle. How? Insert something (proxy) between actual call to property, would issue deprecation warning first. This would be temporary, eventually this interceptor/proxy would go away. - - -### ES6 Modules [node-eps/002-es6-modules.md](https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md) - -Need to disambiguate ES6 modules and regular scripts (which include CJS modules). Cannot determine if file is module, script, etc. from code itself. For this reason Node decided to use `.mjs` extension for ES6 modules. - -New proposal: If `import` or `export` keywords are in module code, then use module goal. So no need for extra metadata or file extension. But would have to parse file to check for presence of these keywords. - -https://github.com/bmeck/UnambiguousJavaScriptGrammar -replaces https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md#51-determining-if-source-is-an-es-module - -This would be part of ECMA262 so browsers would do the same, but needs to be ironed out in TC39. On [agenda][TC39 Agenda] for 7/26 TC39 meeting. - -What if nothing is imported or exported? Could do `export default null` to export nothing. - -Starting off, preferred goal when preparing code would be CommonJS/script, later on could change to ES6/module. - -Caching is more feasible. - -Provides more seamless flow from CJS to ES6 in the future. - -Will packaging tools need to implement parsing logic too to package properly? Yes, but there are possibilities listed in the repo. - -What other differences between scripts and modules? -- `await` keyword only in modules according to ECMA262 -- `modules.root` in package.json is intended to allow mirrored directory structure for use with ES6; but technically all it does is redirect file system calls and it could be used for other purposes, so it’s not reliable. - -Purpose of modules.root - allows redirection within a module, e.g. `module/file.js` doesn’t necessarily resolve to `./file.js` within the directory, could be redirected to `${module.root}/file.js`. This allows side-by-side CJS and ES6 among other things. - -What about for human reading? How can people differentiate at a glance between CJS and ES6? -- `import`’s are generally at the top, `export`s at the bottom. If you see `import` it’s an ES6 module. - -How are browsers dealing with this? Older browsers which encounter `