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