[edbrowse-dev] a crude 'step'

[edbrowse-dev] a crude 'step'

[Kevin Carhart]

I sort of innovated something while working on Maersk.  You can step a 
short sequence of code without having so many breakpoints that it's 
impractical.

First you add a flag to the top of startwindow just for this purpose, like 
stepper = false

Now you turn trace on and study the trace counter numbers a bit.  You have 
to identify where you want the breakpoints to start, which would be 
whichever counter number you would be setting an eval($bp) on, if using it 
as it works currently.

Now you have to write into trace, but not just turning alert3 into 
alert3;eval($bp)

You write in with 2 things.  The first involves both levels.  The trace 
routine, and the string where trace writes a+ alert +b.  In trace, you 
have a conditional.  It tests the counter number and says if the counter 
number has reached your desired start value (a1000) , you write in a 
string to a+alert+b.  This piece of text says, stepper= true.  For any 
other counter number, add nothing.

The second thing will be added to a+alert+b unconditionally.  It just says 
if stepper = true then eval($bp).

So this means that once a1000 is reached, it will continue to breakpoint 
at every possible juncture from then on, but you can also switch
stepping back off, by entering stepper=false at the breakpoint prompt!

So you can step the flow without needing to know what that flow is, and 
also be able to make it somewhat fine-grained.

I fear my ssh session is about to crash so I am sending here!



  is that you hardcode 
a conditional 
to say that if the counter number has reached a1000, stepper =true.  This 
happens at the time that the trace function is running because that is 
when the counter numbers are available.

The second thing is a level down.  It's JS that goes into the string that 
trace writes.

[edbrowse-dev] a crude 'step'

[Karl Dahlke]

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

Ok I tried to do what you wanted, since it sounds useful, but with a few caveats.

I am currently debugging a site where the trace function in jects an alert that causes a syntax error.

if(condition)
var x = stuff;
else
other stuff;

I key on the word var as a safe place for me to inject trace code, but this one is not safe.

alert("c334"); var x = stuff;

Causes a syntax error.
Worse, if there wasn't an else clause, there would be no syntax error,
and my tracing would just fuck up the way the code works.
Not sure what to do about that.

Why anybody would put a var variable in the if clause, where it can never be used again,
because as soon as you hit else it is out of scope,
why anybody would do that I don't know,
but it illustrates that my trace injecting code will never be perfect, and sometimes needs some manual cleanup.
So we need to deminimize once,
then snapshot locally,
then trace once,
then put the trace js files in place of the previous js files,
then manually clean them up in case I injected a syntax error,
then use those files forever more for debugging.
So I don't want a system where you have to say uvw trace again for different start points etc.

Now with all that in mind, the new macro is eval($step+"(location)");
	(The original bp and bpl macros are still there.)
It respondse to the step level, which is global.

$step$lev = 0  do nothing
$step$lev = 1 print out the location of where you are
$step$lev = 2 activate a breakpoint indicating the current location

In the breakpoint you can change $step$lev of course.
You can put it back to 0 because maybe you're not interested in the first time you hit this block of code, but maybe the second or third, and sure enough it comes back to life when you get to it again.
$step$start turns it on.
So in my base file, before the first javascript, I added this

  <script>$step$lev = 0, $step$start = "c2682";</script>

It is then silent until it gets to c2682.
Then it breaks where it can, and I now break at more points, again, hoping not to inject syntax errors.
It's all in startwindow.js line 3340
and maybe you can improve on it;
it's a gross mash of perl regular expressions plus the stripping done by tools/uncomment.
Not for the faint of heart!
The basic idea is to trace or break before var variables, or after
function(args) {
try {
catch (e) {
if(condition) {
else {
for(conditions) {

This is designed to work with the code that is produced by the deminimizer, and will probably be a disaster if run on any other kind of code.

Even as I write this I'm a little paranoid about

if(condition)
var x = stuff;

with no else clause which will cause no error but the tracing will change the way the code runs;
and I wonder if I should get rid of the tracing before var.
I don't think you would lose very many trace points, if all the others are working.
Usually one of the other lines comes just before the var line, so you wouldn't lose anything, and those lines are safer.
Let me know what you think.

Well all this is kindof harder to explain than to write, so send me private email or message if you have any questions.

Karl Dahlke

[edbrowse-dev] a crude "step"

[Kevin Carhart]

Thank you!  That's rad!  (Sorry, I'm a Californian :) )  That's terrific. 
I'll experiment with it.