Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debugger - Filter out the ending of the Module wrapper when using the list command #9773

Conversation

lholmquist
Copy link
Contributor

@lholmquist lholmquist commented Nov 23, 2016

Checklist
  • make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

Debbuger

Description of change

PR for #9768.

When inside the debugger, doing a list(10) on a file with only say 5 lines, would print the end of the module wrapper on the last line.

There is code currently to make sure that the first part of the Module wrapper is filtered out. that is located here: https://github.com/nodejs/node/blob/master/lib/_debugger.js#L1107

The code added filters out the very last line of the lines array, which is the ending of the module wrapper.

I did not add a test for this. I don't believe there was one that tests List anyways. If there needs to be one, i will try and look at the other debugger tests as an example

@cjihrig
Copy link
Contributor

cjihrig commented Nov 23, 2016

Could you provide a test case please.

@lholmquist
Copy link
Contributor Author

sure

@lholmquist
Copy link
Contributor Author

@cjihrig Sorry for the delay(Thanksgiving Holiday), I've added a test case here

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch 3 times, most recently from 561c191 to d93bfa1 Compare December 5, 2016 15:06
@lholmquist
Copy link
Contributor Author

and rebased

const proc = spawn(process.execPath, args, { stdio: 'pipe' });
proc.stdout.setEncoding('utf8');

var stdout = '';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be let.


var stdout = '';

var sentCommand = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As can these.

proc.stdout.on('data', (data) => {
stdout += data;
if (!sentCommand && stdout.includes('> 1')) {
return sentCommand = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you split this into two separate lines. Same for the other similar lines below.

return sentEmpty = true;
}
if (!sentExit && sentCommand && sentEmpty) {
setTimeout(() => {proc.stdin.write('\n\n\n.exit\n\n\n');}, 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use setImmediate() above and setTimeout() here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i copied and pasted from another test, so to be honest, thats what happened. is there a preferences for me to switch too

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it works with setImmediate(), or plain synchronous code, that should be preferred over setTimeout().

false,
'the last line of the debugger should not have the module wrapping ending'
);
console.log(stdout);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove this.

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from d93bfa1 to 3b08903 Compare December 5, 2016 19:12
@lholmquist
Copy link
Contributor Author

@cjihrig ok, i think i got all the changes, and i also rebased against master too

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch 2 times, most recently from e712633 to ed4eec9 Compare December 8, 2016 15:30
@lholmquist
Copy link
Contributor Author

rebased again

Copy link
Contributor

@cjihrig cjihrig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, it would be nice if we could reuse the test/debugger/helper-debugger-repl.js file. I'm not sure how feasible it is or not though. Thoughts @nodejs/testing?

process.on('exit', (exitCode) => {
assert.strictEqual(exitCode, 0);
// No module wrapping at the first line
assert.equal(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make this strictEqual()

'debugger should not have the module wrapper'
);
// No module wrapping at the end
assert.equal(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

strictEqual() again please.

}
});

process.on('exit', (exitCode) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't this be on the child process close event?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that makes sense

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from ed4eec9 to fbd1287 Compare December 8, 2016 15:43
@lholmquist
Copy link
Contributor Author

@cjihrig updated

}
});

proc.on('close', (exitCode) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you assert the signal too (the second argument to the close handler.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added that too. it happens to be null, i was sort of expecting it to not be though

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from fbd1287 to 94f4a3f Compare December 8, 2016 15:59
@cjihrig
Copy link
Contributor

cjihrig commented Dec 8, 2016

@lholmquist
Copy link
Contributor Author

looks like some failures, not sure whats going on in those platforms though

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from 94f4a3f to 338c052 Compare December 8, 2016 19:35
@lholmquist
Copy link
Contributor Author

i rebased, maybe there was something missing

@cjihrig
Copy link
Contributor

cjihrig commented Dec 9, 2016

}
});

proc.on('exit', (exitCode, signal) => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be wrapped in common.mustCall()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lance made the update and rebased

@cjihrig
Copy link
Contributor

cjihrig commented Jan 20, 2017

Let's get a fresh CI and see what happens: https://ci.nodejs.org/job/node-test-pull-request/5959/

@lholmquist
Copy link
Contributor Author

i see that the ARM is reporting as failed, but the link to CI looks like it passed.

Also, looks like the smartOS 14-32 isn't failing anymore, but 14-64 still is

@cjihrig
Copy link
Contributor

cjihrig commented Jan 20, 2017

The ARM failure on GitHub can be ignored. If you look at the actual Jenkins link, only SmartOS failed.

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from df6f0fe to 0800565 Compare March 14, 2017 15:58
@TimothyGu
Copy link
Member

@cjihrig can this PR be merged or does it need some more work?

@cjihrig
Copy link
Contributor

cjihrig commented Mar 20, 2017

The last time we ran the CI, the test in this PR was failing on SmartOS.

@TimothyGu
Copy link
Member

The old CI URL seems to have expired. Let's try again then: https://ci.nodejs.org/job/node-test-pull-request/6926/

Copy link
Member

@TimothyGu TimothyGu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI seems to be passing on SmartOS this time around.

@lholmquist, can you fix this nit and @cjihrig's review comment here (in other words, reverting 8f10635360ffbdd158d3c088a0e19e066ac8cd8c), so we can merge this PR?


if (!sentEmpty) {
setImmediate(() => { proc.stdin.write('list(10)\n'); });
sentEmpty = true;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you change the variable name to something that is more applicable to this test, like sentList?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TimothyGu sure

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from 0800565 to edaba7d Compare March 20, 2017 13:40
@lholmquist
Copy link
Contributor Author

@TimothyGu @cjihrig I've reverted back that commit, and fixed that small nit. I've also rebased against master too.

@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from edaba7d to bb314f9 Compare March 21, 2017 16:59
… list command

When doing the list command using a number that is more than the amount lines in that files, ex: list(10),
the ending of the Module wrapper was still showing.  This removes that line.

Fixes: nodejs#9768
@lholmquist lholmquist force-pushed the debugger-outputs-module-wrapper-ending-#9768 branch from bb314f9 to acbc8bb Compare March 22, 2017 18:04
danbev
danbev approved these changes Mar 27, 2017
Copy link
Member

@danbev danbev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit: the subsystem should perhaps be lib:, and the commit message adhere to the guidelines. (I can make those changes when merging after all reviews have been approved)

@danbev
Copy link
Member

danbev commented Mar 28, 2017

@cjihrig @TimothyGu Would it be alright if I land this?

@gibfahn
Copy link
Member

gibfahn commented Mar 28, 2017

@cjihrig
Copy link
Contributor

cjihrig commented Mar 28, 2017

Looks like there are still related test failures.

@danbev
Copy link
Member

danbev commented Mar 28, 2017

Looks like there are still related test failures.

I'm running the test on windows to see if I can track down the issue.

This commit attempts to fix a failure that has been reported by CI and
that I was able to reproduce locally as well. Will run another CI and
see if this takes care of the issue.
@danbev
Copy link
Member

danbev commented Mar 31, 2017

@BridgeAR
Copy link
Member

This needs a rebase. @danbev did your commit solve the failure?

@lholmquist
Copy link
Contributor Author

@BridgeAR @cjihrig Since the file that i made changes to is now deleted, does it make sense to still continue this PR?

@cjihrig
Copy link
Contributor

cjihrig commented Aug 28, 2017

I don't think so. I'll close this.

@cjihrig cjihrig closed this Aug 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants