Handling sophisticated breaks with the debugger

Looking at the GUI for this ttap machine, automated printfer, debugger. Whatever it is, it has the source window on the left and watch to the right. Right now, the BreakHalt routine creates entries in the watch windows as the list of values to collect, it parses the watch window as well as writes it. (It reads its own stuff!).  Butthe watch window is editable, tkinter has the logic.  So for a few more source  lines, I will active direct editing on the watch window. Pbug don't care, it just grabs the valid expression and dumps it to eval.  Then, we have a simple task in setting up complex break points, just cut the expression from he watch window, after we test it, and paste into the expression pop up entry.

All of this great stuff is easy, once you have decided to parse text.  You have plenty of methods to grab symbols and expressions from text.  So we will be grabbing and putting stuff on the watch window, stuff that python knows what to do with, on a line by line basis.  But, never do we have a method to tamper with the original source under test, in fact, most of the time we are in  the interrupted frame from exec, and it is too late to screw with the source.

Which brings up a point, we need a stop button, one that sets the break flag negative and forces he interrupts off.

A note on methods.

I been here, done this, so I know when the interrupt loop needs to make the fast decision and exit out.  Ao, in the interrupt, for example, f the run flag is off, return right away.  If we want the traps off completely, we add a setting somewhere, so the traps always run three lines of python.  That is a big price, we will leanr how to use the traps better.

But no sting comparisons go on in the service code until it is certain the integer flag puts us in some break or step condition.  Once the user put's it in some kind of non-free run mode, we can, as necessary, go through a set of filters,  that determine any follow on break point checks trap expression evaluation, update the watch window, or call to external module.  Not much there, as long as the loop has a call back to user analysis code.

Filters
After the traps determine the run flag is positive, it then grabs the line number from the exception. But that is not quite enough, the traps need to distinguish exceptions from the code under test, and right now that is a string compare. But I can get that to a frame reference compare, make sure we got interrupted in the source, not just before or just after.

Now, we can get tricky.  If we ask the code to trapon the trace call back, we can, if line numbersmatch, turn on the profile tracer and/or turn off the normal tracer.  They operate differently, and one is likely to be subselect by the other when conditions are met.Then, the operating mode tells usto evaluate the more complex trap expression and call the usermodule.  But we only gohere when run mode is set to trapping.

Regular break points are an integer search over a small list, not much.  So, you see, if we rig this right, we make a limited number of integer checks, only when operating on or more traps.  Only after the short checks are done do we have complex evaluations.

User module
It is simple, load and run, an does not really work.  But, a few lines of code, and the system can load the module nce, extract the init and call backs.  ANything that gets the debuger out of the trap loop ASAP.