An automated 'printf' debugger

The Redneck's debugger, has to be independent of the sys calls, stack inspection, or tracebacks from the intrepreter.  If the user needs that, he jumps onto the more professional debugger.  I exercised the sys calls, including inspect, but no trace back. I printed, sorted, and looked at the results, and concluded it was over kill.

This debugger should just operate from inserting BreakHalts() into the source. , and the break halt code is python, part of the 150 lines of snippet debugger. , and completely system independent, an automated printfer. I can deal with the source on a block level, tab counts are obvious!

Hence, trace backs from the interpreter are not used in the Redneck's debugger. Sys is great, but over kill, except for one thing, a simple utility can extract the ine number and module name from the point BreakHalt was called.

One danger lurks, what if the interpreter is caching up the source code? It shouldn't, that violates its basic rules.   I am keeping the idea, for now, that the interpreter is a one pass interpreter, line by line, from the original source, no look aheads.  But, even if, the interpreter will see the call to BlockHalt, into a far module, and reset it caching.

Consider:
eval(myText)

The interpreter should be doing line by line directly from myText, which is in debugger space. Hence, the debugger knows that myText is safe, it van be modified from BreakHalt, we hope!