From: Kevin Carhart <email@example.com> To: firstname.lastname@example.org Subject: [edbrowse-dev] a crude 'step' Date: Tue, 9 Jul 2019 20:50:46 -0700 (PDT) Message-ID: <alpine.DEB.email@example.com> (raw) 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.
next reply other threads:[~2019-07-10 3:50 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-07-10 3:50 Kevin Carhart [this message] 2019-07-10 6:20 ` Karl Dahlke 2019-07-11 3:42 [edbrowse-dev] a crude "step" Kevin Carhart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.DEB.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
edbrowse-dev - development list for edbrowse This inbox may be cloned and mirrored by anyone: git clone --mirror http://inbox.vuxu.org/edbrowse-dev # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 edbrowse-dev edbrowse-dev/ http://inbox.vuxu.org/edbrowse-dev \ email@example.com public-inbox-index edbrowse-dev Example config snippet for mirrors. Newsgroup available over NNTP: nntp://inbox.vuxu.org/vuxu.archive.edbrowse.dev AGPL code for this site: git clone https://public-inbox.org/public-inbox.git