-
Notifications
You must be signed in to change notification settings - Fork 1
Cool things
In contrast to node debug, evaluation is done in the context of the debugged program when what you type isn't a debugger command. Suppose you have a local variable timeStep, you can see the value of this by just typing timeStep. Suppose this is your program:
function simulate() { return; }; for (var timeStep = 0; timeStep < 10; timeStep++ ) {
simulate()}
Here is part of a session:
trepanjs /tmp/ts.js debugger listening on port 5858 connecting to port 5858... ok break in /tmp/ts.js at line 2:1
1 __filename, __dirname) { function simulate() { return; };
- -> 2 for (var timeStep = 0; timeStep < 10; timeStep++ ) {
- 3 simulate()
(trepanjs) (trepanjs) break(3) Breakpoint 2 set in file /tmp/ts.js, line 3 .... break in /tmp/ts.js at line 3:3
2 for (var timeStep = 0; timeStep < 10; timeStep++ ) {
- -> 3 simulate()
- 4 }
(trepanjs) timeStep
1
In node debug you would get ReferenceError: timeStep is not defined because its default evaluation is not in the context of the debugged program, but is relative to a special debugger context.
However keep in mind with the auto-evaluation that goes on here there are some things you need to pay attention to. In particular, we parse the first token of each line and look that up in a list of debugger commands and aliases. If the token matches that, we too evaluate this in a special debugger-command context rather than the context of the debugged program. That is why when we typed break(3) it was interpreted as setting a breakpoint (break is debugger alias for the debugger command setBreakpoint). If you had a function in your program called break() that is not what is called here.
The place where this might be an annoyance is when there are short variable names, like s, or n, that also happen to be debugger aliases. For this, use the eval() function, e.g. eval('s'). Note that you need to put the thing you want to eval, "s" in quotes.
Alternatively you can go into a nodejs shell by issuing the shell command.
In order to see what's going to happen without advancing the program, often you can just type eval. This takes the current source line and runs it. Note however evaluation, may change the state of the program, so that when that statement is the run again the effects may be different than what it would be if you had run the program without the debugger.
Also note that we don't do any fancy parsing. So the current source line should be a complete Javascript statement or expression.
And speaking of expressions, sometimes you don't want to evaluate all of the statement but some expression-y part of it. That's where eval? comes in. It uses the following string translations:
{if|while} (<expr>) ... => <expr> return <expr> => <expr> <var> = <expr> => <expr>
Thanks to consolehighlighter, source text is colorized. Of course, you can turn this off with the command set('highlight', false)
As you'll see we provide a lot more information about the debugged program in common commands like backtrace or through additional commands like info('frame')
The backtrace command shows function names and parameter names when in the callstack when the frame was called inside a function. For example:
- (trepanjs) bt
- ->0 gcd(a, b) called from file /tmp/github/trepanjs/example/gcd.js
- ##1 gcd(a, b) called from file tmp/github/trepanjs/example/gcd.js
- at line 19:12
##2 in file /tmp/github/trepanjs/example/gcd.js at line 26:4
Sometimes node debug just doesn't show enough for another wrapper around that to be able to use the information. Specifically the Emacs debugger front-end realgud_. Because I work on both, I know what kind of information is useful. And this applies not only to that front end, but other front-ends that parse output the same way. For example ddd also works by parsing output, so it too would be able to do more with trepanjs.
https://www.npmjs.com/package/consolehighlighter .. _realgud: https://github.com/rocky/emacs-dbgr