[LMH] Diagnostic output

[Nyef]

On Thu, 11 Sep 2003, James A. Crippen wrote:

> > The diagnostic output is getting verbose enough that I want to start 
> > disabling some of it, but I don't dare because it will become completely 
> > impossible to track down any of the more subtle bugs the instant I take 
> > anything out.
> 
> I was actually thinking about this last week. What I figured was best
> was to do a line by line scan for all the debugging output and then
> come up with a handful of categories which the various output data
> fall under. Then add a command line option to choose the appropriate
> amount/type of debugging output. Amount in the sense of the canonical
> 'verbose' option, and type in the sense of 'FEF' versus 'miscop' or
> the like.

Well, what I was thinking was that it might be nice to have an 
'uninteresting function' list, like the error handler system has, which 
just disables diagnostic output while in those functions (but not in 
subfunctions, so we can ignore stuff like dolist when it's not inlined 
by the compiler and other such).

Another idea would be disabling the whole bit about dumping a full FEF
when entering it and having a separate utility to dump a FEF given its
address (or, if we're feeling adventurous, its name). This would be kindof
inconvenient if it didn't dump the FEF that emulation stopped on, though.  
Perhaps a 'do-not-dump-fef' list would be appropriate?

Yet another idea is to replace all the calls to exit(-1) with a call to a 
function that dumps out some of the interpreter state before exiting. The 
context structure, the current function stack, etc.

> I'll volunteer to do this if you want. It'll be a good diversion from
> getting qmail and Mailman configured. (Ugh.)

My sympathies. I had enough trouble just getting postfix, procmail, pine, 
and fetchmail on speaking terms.

Let's think for a little bit about exactly what sort of debug output 
control we really want before implementing it, though. We both could be 
completely off base about what's really needed, after all...

---------------------------
All programming can be viewed as an exercise.
---------------------------
Alastair Bridgewater
e-mail: nyef@softhome.net