[PATCH] deferred trace

[Rob Farnum]

> >> This implements a way to not output the debug trace to disk until the
> >> user hits Alf + F12. The goal is to avoid too big trace files.


I had this problem, and solved it using an external mechanism.  I wrote an
app
that sends a clientmessage, and wrote a handler for that client message.

The things I could do are change debugging flags, so effectively, i could
turn
trace on/off.

I could call functions, like WIN_WalkWindows and others, if i knew ahead of
time what they were.

This lead me to another thought I think might be useful, adding a runtime
interpreter, and using something my clientmessage, send snippets of code to
be executed,
much like running gdb, but not as invasive.   the language could be anything
that
has a reasonable interpreter, something like C# :-)  My goal is to have
something
that could look for events, when they happen, rather than trying to wade
through
dbg_printf statements.  something that is potentially interactive...ie. when
event A
happens, the trigger action B to happen....

another thought is that i could dynamically load/unload a dll, that would
load,
do its diagnostics during init, and then unload when done.

> >
> >I think it would be much better to do that with a small external
> >program that you pipe the debug output into. This way you can have
> >much more flexibility


the problem is that you cant change things on the fly...what you want is to
have
the debugging options you want, selected when you want them, and then turned
off.  my clientmessage tool does this.  i can start with no debugging, then
have it
start with what i want, and then, i can turn it off again...

My goal is to use what is already there, but to make it much more dynamic.
Then
rather than doing post mortem examination, we can do it live.  My thought is
why
can't we use the builtin debugger, asyncronously, driven by an external
application
that has some logic that can be used in real time.