Exciting stuff - I'm starting with $bp. I'm unpacking the bp routine to
understand it, so if I write up a little paraphrasing here, could you
remark if I have grasped how it works?
The thing that you inject is eval($bp).
It's legal to call it with or without a line number passed in. If you
call it without a line,
it is called as $bp(0).
So now you're inside function(l)
If you passed in a line, it alerts what that line number is.
If l == 0 , it doesn't alert.
while (true) - on its own, this is an idiom for looping forever, right?
So potentially forever, you do a series of things.
Use window.prompt to prompt the user that they're at the breakpoint and
have a REPL which is
indistinguishable from jdb. You can run ok(window) or whatever!
The user's response is stored in res.
In case they said nothing, keep going with the infinite while(true) and
carry on to the
try-catch.
In case they typed ".", break out of while(true) and duktape can keep
processing JS.
Now if you're still going, you reach the try-catch
On the assumption that res is legal javascript, try to evaluate it.
If it worked, alert the returned value from eval.
If there was an error, alert the error
Now continue to while(true) forever until the user enters "."
So in aggregate, when duktape hits eval($bp), it evaluates $bp, where $bp
is JS code in its own
right which implements a self-contained REPL. It is indistinguishable
from jdb and will
evaluate your JS for as long as you want. The reason why you can find out
about things like
transitory private variables with a brief life is simply because you're
running a REPL at any
moment in time within the JS execution.
Very cool - I had no clue this was possible without needing to understand
the Duktape C.
Kevin
