lib,src: Ensure '(node:pid)' prefix for stdout logging #3833

JungMinu · 2015-11-15T10:31:16Z

Fixes issue: #3789
add '(node:pid)' prefix message for stdout logging

martfors · 2015-11-15T10:54:50Z

If there aren't any reason template string can't be used in these files maybe this would be a good time to do that switch for these lines?

thefourtheye · 2015-11-15T11:29:05Z

I would recommend moving this to function in internal/util and use template strings as suggested by @martfors

JungMinu · 2015-11-15T11:44:21Z

@thefourtheye will do :)

bnoordhuis · 2015-11-15T12:02:32Z

The square brackets don't really add anything useful. I would format it as (node:1234), it's shorter.

JungMinu · 2015-11-15T12:16:00Z

@bnoordhuis Thanks :)

silverwind · 2015-11-15T12:42:01Z

lib/_debugger.js

@@ -1641,7 +1643,7 @@ Interface.prototype.trySpawn = function(cb) {
        process._debugProcess(pid);
      } catch (e) {
        if (e.code === 'ESRCH') {
-          console.error(`Target process: ${pid} doesn't exist.`);
+          console.error(prefix + pid + `Target process: ${pid} doesn't exist.`);


Careful here, pid is defined in this inner scope, overshadowing your top-scope definition. Won't be an issue when you use a function, though :)

@silverwind Yup, I will use a function :)

JungMinu · 2015-11-15T14:44:51Z

@thefourtheye Thanks, updated :)

thefourtheye · 2015-11-15T15:22:00Z

lib/events.js

@@ -232,7 +233,7 @@ EventEmitter.prototype.addListener = function addListener(type, listener) {
      m = $getMaxListeners(this);
      if (m && m > 0 && existing.length > m) {
        existing.warned = true;
-        console.error('(node) warning: possible EventEmitter memory ' +
+        iutil.printStdoutError('warning: possible EventEmitter memory ' +
                      'leak detected. %d %s listeners added. ' +


The string should align with the previous line's string.

jwueller · 2015-11-15T17:15:37Z

@bnoordhuis (node) [pid] would be grepable. (node:pid) is as well, but not as easily. I find that to be very useful.

bnoordhuis · 2015-11-15T20:27:54Z

I would think that (node:pid) is easier to grep for, or at least more precisely. With a naive grep '(node) [1234]', the [1234] gets interpreted as (1|2|3|4).

jwueller · 2015-11-15T23:15:28Z

Yes, the [] are probably a poor choice, but if I am not mistaken, there is more than once place in node where the (node) prefix is used. Making that consistent sounds like the right thing to do. Additionally providing the PID is a good thing, but it feels like that should not interfere with the existing pattern.

jwueller · 2015-11-15T23:19:54Z

Oh wait, are we changing the prefix for everything? In that case, I am good with (node:pid) everywhere! Sorry about the confusion.

JungMinu · 2015-11-16T08:26:41Z

@silverwind @bnoordhuis @thefourtheye Thanks, updated 😄

thefourtheye · 2015-11-16T09:48:57Z

lib/_debugger.js

@@ -31,8 +32,8 @@ exports.start = function(argv, stdin, stdout) {
  stdin.resume();

  process.on('uncaughtException', function(e) {
-    console.error("There was an internal error in Node's debugger. " +
-        'Please report this bug.');
+    internalUtil.error("There was an internal error in Node's debugger. " +


We normally use ' for string literals, but in this case it is okay, I guess.

@thefourtheye Because of ' in Node's , we can't use ' for string literals in this case.

I'd prefer we just escape the apostrophe like so:

'There was an internal error in Node\'s debugger. '

Or alternatively, just use a template string.

@Fishrock123 Thanks :)

thefourtheye · 2015-11-16T09:51:33Z

Overall change LGTM

JungMinu · 2015-11-16T13:53:32Z

@thefourtheye updated :)

evanlucas · 2015-11-16T13:59:37Z

Can you run make test on this? This change seems to make all tests fail

internal/util.js:3
const prefix = `(node:${process.pid}) `;
                        ^

ReferenceError: process is not defined

thefourtheye · 2015-11-21T06:48:25Z

src/cares_wrap.cc

@@ -205,7 +205,7 @@ static void ares_sockstate_cb(void* data,
  } else {
    /* read == 0 and write == 0 this is c-ares's way of notifying us that */
    /* the socket is now closed. We must free the data associated with */
-    /* socket. */
+    /* the socket. */


Is this really necessary as part of this PR?

JungMinu · 2015-11-21T09:00:22Z

@jasnell @thefourtheye finished and rebased, Thanks :)

silverwind · 2015-11-22T20:10:14Z

lib/_debugger.js

@@ -1737,7 +1738,7 @@ Interface.prototype.trySpawn = function(cb) {
  function connectError() {
    // If it's failed to connect 10 times then print failed message
    if (connectionAttempts >= 10) {
-      console.error(' failed, please retry');
+      internalUtil.error(' failed to connect, please retry');


Not sure about the context of this error, but the message change seems unnecessary.

@silverwind Editing this error message is suggested by @thefourtheye

I think this error message could be more descriptive. If you like to do it, you can do it now.

Ah, alright. Guess it's ok then :)

silverwind · 2015-11-23T14:19:25Z

LGTM. What happened to the C++ ambitions?

silverwind · 2015-11-23T14:20:23Z

CI: https://ci.nodejs.org/job/node-test-pull-request/815/

JungMinu · 2015-11-23T14:29:16Z

@silverwind I found that the problem was not from C++,but there was a mistake in test script for new functions. I fixed it in my previous PR :)
Is there any error from c++ that I missed?

silverwind · 2015-11-23T14:35:52Z

Searching for printf in src reveals quite a few cases, like here. I suppose C++ could be done in another PR, and these prints should be handled on a per-case basis. I suggest not adding the prefix when the process terminates after the error.

JungMinu · 2015-12-03T09:02:33Z

I've added more C++ files in src, please review again :)

silverwind · 2015-12-03T12:09:14Z

test/parallel/test-sync-io-option.js

@@ -20,7 +20,7 @@ if (process.argv[2] === 'child') {
    execFile(process.execPath, args, function(err, stdout, stderr) {
      assert.equal(err, null);
      assert.equal(stdout, '');
-      if (/^WARNING[\s\S]*fs\.readFileSync/.test(stderr))
+      if (/^[\s\S]*fs\.readFileSync/.test(stderr))


I'd suggest you just remove the ^ here, so the regex is /WARNING[\s\S]*fs\.readFileSync/.

JungMinu · 2015-12-03T12:33:35Z

@silverwind Thanks, fixed :)

silverwind · 2015-12-03T12:42:04Z

src/node_crypto.cc

@@ -813,7 +813,7 @@ void SecureContext::SetDHParam(const FunctionCallbackInfo<Value>& args) {
    return env->ThrowError("DH parameter is less than 1024 bits");
  } else if (size < 2048) {
    args.GetReturnValue().Set(FIXED_ONE_BYTE_STRING(
-        env->isolate(), "WARNING: DH parameter is less than 2048 bits"));
+        env->isolate(), "(node) WARNING: DH parameter is less than 2048 bits"));


Can we get a PID here too?

@silverwind this gets logged in here, which is already handled in js code :)

JungMinu · 2015-12-03T18:10:00Z

updated and finished :)

silverwind · 2015-12-03T18:12:51Z

src/node_crypto.cc

-        env->isolate(), "WARNING: DH parameter is less than 2048 bits"));
-  }
+         env->isolate(), "WARNING: DH parameter is less than 2048 bits"));
+   }


Remove the added spaces here.

Yep, I am doing that :)

Btw, git reset origin/master src/node_crypto.cc could help in resetting just that file :)

JungMinu · 2015-12-03T18:16:23Z

@silverwind fixed, thanks :)

add '(node:pid)' prefix message for stdout logging

silverwind · 2015-12-03T18:18:09Z

CI: https://ci.nodejs.org/job/node-test-pull-request/912/

silverwind · 2015-12-03T18:48:20Z

Failures are unrelated, LGTM

jasnell · 2015-12-03T20:16:58Z

LGTM

Add '(node:pid)' prefix message for stdout logging PR-URL: #3833 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Evan Lucas <[email protected]>

jasnell · 2015-12-03T20:25:21Z

Landed in 94b9948

rvagg · 2015-12-05T05:14:25Z

marking as semver-major so it doesn't get caught up in v5.x, I think that's appropriate, please correct me if I'm wrong.

silverwind · 2015-12-05T05:25:00Z

@rvagg well, it could certainly break things that parse our stdout, so I guess it's fine to conservatibely label it as major.

Add '(node:pid)' prefix message for stdout logging PR-URL: nodejs#3833 Reviewed-By: Sakthipriyan Vairamani <[email protected]> Reviewed-By: Roman Reiss <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Evan Lucas <[email protected]>

This was referenced Nov 15, 2015

Ensure '(node)' prefix for stdout logging #3789

Closed

lib: Ensure '(node) [pid]' prefix for stdout logging #3832

Closed

thefourtheye added the lib / src Issues and PRs related to general changes in the lib or src directory. label Nov 15, 2015

JungMinu changed the title ~~lib: Ensure '(node) [pid]' prefix for stdout logging~~ lib: Ensure '(node:pid)' prefix for stdout logging Nov 15, 2015

silverwind reviewed Nov 15, 2015
View reviewed changes

thefourtheye reviewed Nov 15, 2015
View reviewed changes

thefourtheye reviewed Nov 16, 2015
View reviewed changes

thefourtheye reviewed Nov 21, 2015
View reviewed changes

silverwind reviewed Nov 22, 2015
View reviewed changes

JungMinu changed the title ~~lib: Ensure '(node:pid)' prefix for stdout logging~~ lib,src: Ensure '(node:pid)' prefix for stdout logging Dec 3, 2015

silverwind reviewed Dec 3, 2015
View reviewed changes

lib,src: Ensure '(node:pid)' prefix for stdout logging

a4c5e7e

add '(node:pid)' prefix message for stdout logging

jasnell closed this Dec 3, 2015

rvagg added the semver-major PRs that contain breaking changes and should be released in the next major version. label Dec 5, 2015

Fishrock123 mentioned this pull request Dec 15, 2015

v5.3.0 Release Proposal (Stable) #4281

Closed

jasnell mentioned this pull request Mar 17, 2016

Planning for v6 #5766

Closed

lib,src: Ensure '(node:pid)' prefix for stdout logging #3833

lib,src: Ensure '(node:pid)' prefix for stdout logging #3833

Conversation

JungMinu commented Nov 15, 2015

martfors commented Nov 15, 2015

thefourtheye commented Nov 15, 2015

JungMinu commented Nov 15, 2015

bnoordhuis commented Nov 15, 2015

JungMinu commented Nov 15, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JungMinu commented Nov 15, 2015

Choose a reason for hiding this comment

jwueller commented Nov 15, 2015

bnoordhuis commented Nov 15, 2015

jwueller commented Nov 15, 2015

jwueller commented Nov 15, 2015

JungMinu commented Nov 16, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thefourtheye commented Nov 16, 2015

JungMinu commented Nov 16, 2015

evanlucas commented Nov 16, 2015

Choose a reason for hiding this comment

JungMinu commented Nov 21, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

silverwind commented Nov 23, 2015

silverwind commented Nov 23, 2015

JungMinu commented Nov 23, 2015

silverwind commented Nov 23, 2015

JungMinu commented Dec 3, 2015

Choose a reason for hiding this comment

JungMinu commented Dec 3, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JungMinu commented Dec 3, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JungMinu commented Dec 3, 2015

silverwind commented Dec 3, 2015

silverwind commented Dec 3, 2015

jasnell commented Dec 3, 2015

jasnell commented Dec 3, 2015

rvagg commented Dec 5, 2015

silverwind commented Dec 5, 2015