[edbrowse-dev] $bp

[edbrowse-dev] $bp

[Kevin Carhart]

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

[edbrowse-dev] $bp

[Karl Dahlke]

[-- Attachment #1: Type: text/plain, Size: 1221 bytes --]

> indistinguishable from jdb. You can run ok(window) or whatever!

Almost, but more restricted.
In jdb you can type e2 and switch to another session and do other things, like look at the code you're working on,
or change db levels or shell escape or a few other things; not here.
It's just js expressions only.
So if you want to read the code around your breakpoint you have to do it from another console / window.
I wanted to do all those other things here but it's just too hard for tecnical reasons.
In the breakpoint, js is actually running.
In jdb it is not.
Thus bp is more restricted and to remind you of that, you get the bp: prompt.

You have to  place your breakpoints then recompile so to speak, or actually, rebrowse, so it's not as cool as real breakpoints,
but you know, it's better than nothing.
I use to stick code in to copy local variables up to global so I could look at them after the fact, guessing which variables I might want to see, etc, that was pretty awkward.

I also mentioned in my comments that while in this breakpoint you can change local variables, then . to exit and duktape continues
with the modified variables; but not sure you should really do that.

Karl Dahlke