<font face="Arial, Helvetica, sans-serif">Dan / All,<br>
I think what the guy was asking on improving winedbg is to have some sort of visual debugger much like VC/C++ , Eclipse, <br>
Borland C++ or the like... Where you can step through the code (seeing the whole thing like any visual debugger). <br>
Then when looking at stacks you click on a variable or stack and it either winds it back or display's it. <br>
<br>
Below is my thoughts on what would be a nice to have in some form of Debugger / Gui Debugger for Wine<br>
<br>
So my wish list would be:<br>
1) Some form of a Standard Gui Debugger<br>
2) A way to select the debug flags used with an explanation of what each is for... +sed is for this +relay does that...etc.... <br>
3) When you do +relay you could open separate output windows for each thread <br>
4) The ability to turn each of the +relay wine thread output on or off... <br>
4) Currently Wading through a relay log is a real pain and in some cases it prevents the problem from occuring.<br>
Time outs because of too much data being collected and then having to wade through and determine what to and not to turn off.<br>
So a note or best practice somewhere showing the heavy hitters in a +relay log and turn them off by default. However, note <br>
somewhere saying if +relay doesnt give enough information then turn on just these flags and run. That way we are not managing <br>
flag lists when trying to figure out whats going wrong in an application. IMHO +relay is too unweldly and turning each flag on <br>
individually is as well, so there needs to be some sort of happy medium somewhere.<br>
5) A window with a list of the important wine structures or resources that can be watched as the application runs.<br>
6) Source code debugging in the GUI with step through, break points, etc..( not like now in winedbg but more like one of the GUI's mentioned before)<br>
7) Loading of application from gui debugger and run it<br>
8) Ability to look at a stack and backtrace in the GUI<br>
9) Value Watches within the GUI.<br>
10) Code Checking<br>
Some sort of bounds checking...<br>
Uninitialized variable checking....<br>
Unreachable Code Checking<br>
11) Use the GUI to help enforce the Wine Coding standard.. most modern GUI environments let you specify a style of coding.<br>
This would help the new people understand and follow the coding standards set up... instead of guessing like they do now.<br>
12) Online help / Context help... point to the IC in the wiki... lots of good stuff there... just hard to find sometimes....<br>
13) Integration with bugzilla... they find a bug... they create it in the GUI.. dump out the screen, stack and the like... so some <br>
of the base information is collected instead of wasting time back and forth and having so many invalid bugs. Again this format <br>
can be enforced through coding style templates... you want to submit a bug here is what you do... check boxes to include things...<br>
like I said screen shots... logs, traces, variables, hardware config, etc...<br>
14) Integration with GIT... check and see if there is a new tree out there.. if so... flag it and git it...<br>
15) Link to whats fixed in the new GIT tree... or a list of it...<br>
16) Link to Dan's patchwatcher status... (kinda a workflow sort of thing) to know whats good and bad...<br>
17) Generation of the GIT patch and then mail it to the list through a button...<br>
18) GIT integration<br>
<br>
You have to remember guy's alot of the new people coming in are not old timers like some of us who grew up in a non-gui <br>
world.. Like it or not they are used to doing things in certain ways and I think we could get alot more people looking at <br>
bugs and helping fix them if we started thinking of something along these lines. This of course is not a complete list... <br>
And I am sure this is going to start a flame war or something close to it.. But I think this might be a good next step for something<br>
like the summer of code people to do.. or whomever maintains the wine debugger to think seriously about.<br>
<br>
Most of these things I think could be implemented using the current wine debugger with some form of pipe between it and the GUI.<br>
That way the 'purists' can still debug using winedebug like now and the new people who choose to can use the GUI?<br>
<br>
Thoughts????????????????????????????????<br>
<br>
<br>
Problems I have noticed when debugging...<br>
If I kill (press the X button or close it from the task bar) the wine application, Wine does not clean up from itself... it leaves the <br>
wine mount daemon running. so I have to kill all the wine processes before I can restart wine. Otherwise any windows <br>
application which loads another application fails to start IE a game with a loader which then starts the game (I have found this<br>
in alot of MMO's where you have some form of login screen / loader which then loads in the actual game) (and no you cant<br>
always just call the main exe)<br>
<br>
Question :<br>
Why does wine have to allocate all its memory at startup? re... the issue that is causing the ATI drivers to have such<br>
a fuss.... why not just allocate as needed? or have the ability (if its not there already) to specify the total amount of memory<br>
which is available to the wine process and limit wine to just that ammount of memory (kind of like the way most VM machines<br>
have the option of setting the maximum amount of memory which is available).<br>
<br>
</font><!-- end of AOLMsgPart_0_fb74dc62-b542-4660-a262-36dec926b399 -->
<div id='u8CAE16F5B96B607-7FC-22' class='aol_ad_footer'><FONT style="color: black; font: normal 10pt ARIAL, SAN-SERIF;"><HR style="MARGIN-TOP: 10px">Looking for spoilers and reviews on the new TV season? <A title="http://television.aol.com/feature/fall_tv?ncid=aoletv00050000000037" href="http://television.aol.com/feature/fall_tv?ncid=aoletv00050000000037" target="_blank">Get AOL's ultimate guide to fall TV</A>.</FONT> </div>