At 11:24 AM 10/03/2001 -0800, you wrote:
gerard patel gerard.patel@asi.fr writes:
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 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
I don't see why.
2 other points :
1) I wonder if I will not lose in speed with this approach; it seems to be more efficient to stop the output ASAP, than to filter data after it has passed through a pipe. I have timed Bcb4 loading with Wine on my computer (K6-350)
- without any trace : 48 seconds
With a simple -debugmsg +win,+relay :
- with my patch : 70 seconds -> 22 seconds overhead - with a redirection to /dev/null : 95 seconds -> 47 seconds overhead
I don't know if a pipe would be more efficient that a redirection, though.
2) I don't see how I will get the window list I generate with WIN_WalkWindows if there is no change at all in Wine - I should have said that to cut in the trace size in not a goal per se, but a mean to make debugging easier. If I have to make a first run with full trace that I have to browse to see what is the meaning of the window handles appearing in the trace, I lose a lot of time. Having immediately a view of all existing windows is *very* handy.
, and you don't need to hardcode a specific key that some apps may need.
But my patch does not use the Alt+F12 key if the -dt command line option is not used. It's true that some apps use this key, but in this case it's only debugging that is affected because the app does something when I use this key. It has never been a problem until now. Maybe a signal could be used instead.
Gerard
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.
-
gerard patel -
Rob Farnum