Wineconf follow up: Wine Usage Data Collection

[Chris Ahrendt]

Kai Blin wrote:
> On Thursday 09 October 2008 22:06:55 Chris Ahrendt wrote:
> 
> Whew, long post. I'll tackle this as I go.

Yes I am sorry for the long post =) but he did ask for some of my 
thoughts =)


> 
>> My wish list would be:
>>
>> 1) Some form of a Standard Gui Debugger GDB integration / eclipse etc..
> 
> gdb has a standard GUI? Which would that be in your case? I hear Eclipse is 
> useable for C development, but does any Wine dev use it?


I think it is a standard GUI... sorry meant something like DDD or KDB 
not gdb.. my bad =) Hell there is an eclipse plugin interface for gdb as 
well as the internal debug framework of eclipse.

> 
>> 2) A way to select  the debug flags used with an explanation of what
>> each is for... +seh is for this +relay does that...etc....
> 
> See http://wiki.winehq.org/DebugChannels and 
> http://bugs.winehq.org/show_bug.cgi?id=638
> 
> Feel free to flesh out the wiki page.

Ok I will take a look and see what I can add... but this is a little 
more than just the wiki... I don't always have internet connectivity 
when I am hacking around in wine (I travel alot so am on an airplane for 
  upto 20+ hours at a time with no connectivity) so it would be nice to 
have something simple that set up the command shell for wine say with a
checkbox and context based help before starting the wine session. If its 
not in a gui but a stand alone tool that would be fine as well.

> 
>> 3) When you do +relay you could open separate output for each thread or
>> send the +relay output for each thread to a different pipe so we can
>> then pipe that information  to a file or open that pipe and use a tool
>> to look at whats going on.
> 
> So you need to start guessing which thread to capture? Do you know about +tid 
> and tools/examine-relay ?

No.... I would like to be able to either pipe each thread to a different 
window or file.... in the case of looking through a relay log I have in 
the past had to manually sort through the log to determine that thread A 
is having the problem because of XY or Z.... it just would be nice not 
to have to do this. OR if its a thread we know is having the problem 
then be able to say I just want the +relay on that thread...IE we know 
only X processes run on thread A and we are having a problem with that 
process and not the others.. then why clutter the logs with the extra 
stuff... it just makes debugging alot easier. ESP when debugging some of 
the more esoteric and weird bugs.

> 
>> 4) The ability to turn each of the +relay wine thread output on or
>> off... Currently Wading through a relay log is a real pain and in some
>> cases it prevents the problem from occuring. Time outs because of too
>> much data being collected and then having to wade through and determine
>> what to and not to turn off. A best practice somewhere showing the heavy
>> hitters in a +relay log  and turn them off by default.  However, note
>> somewhere saying  if +relay doesn't give enough information then turn
>> on just these flags and run. That way we are not managing flag lists
>> when trying to figure out whats going wrong in an application. IMHO
>> +relay is too unweldly and turning each flag on individually is as well,
>> so there needs to be some sort of happy medium somewhere.
> 
> Actually most of the errors that disappeared for me when using +relay were 
> races and stack smashing bugs. Those are always a pain to debug, and will 
> probably disappear as well when only using parts of +relay.
> 

Maybe maybe not... +relay could and has for me masked the problem with 
races or such because the timing is off.... so we can say the problem 
exists both ways.. however I think it would help with timing related 
bugs and determining whats going on rather than not... less stuff going 
out = less overhead.


>> 5) A window or output  with a list of the important wine structures or
>> resources that can be watched as the application runs with some
>> explination of what those structures are for. And do the same with the
>> dump. If the execution space is in an application output that fact. If
>> we are in wine and we have the symbols of where we are then dump the
>> code where we are too =)
> 
> I don't know how this would be implemented, but it sounds like a performance 
> drag to me. So I take you intend this to be a debugging tool. What's wrong 
> with using a debugger?
> 

Nothing is wrong with using a debugger.... its an enhancement to one... 
when working on the kernel for another OS (not Win or Linux) we had the 
ability within the debugger to have a common list of kernel or PM level 
structures we could select to watch and the tool would show them.. Just 
think it would be a nice to have for Wine as well.


>> 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) and yes I know Gdb sort of works.. why not make it so it really
>> works.. its not like I am asking to use VC++ to debug wine here lol.
> 
> Most debugger GUIs on Linux are (somewhat sucky) frontends to gdb. I'm pretty 
> sure it's possible to create something similar for winedbg.
> 

Cool thats all I am saying here... is provide the hooks  =) the gdb 
interface for winedbg is really kludgy.... or I found it to be... so 
just get rid of the middleman =)


>> 7) Loading of application from gui debugger and then run it. This can be
>> done with gdb now but its not the easiest in the world to do. This would
>> be nice if it was made easier.
> 
> Sure, I'm pretty sure this can be done in aforementioned GUI.

yep....

> 
>> 8) Ability to look at a stack and backtrace in the GUI or exception list
>> and have the symbol associated with the backtrace placed in the
>> execution trace.
> 
> Yup, see above.
>

yep...


>> 9) Value Watches within the GUI.
> 
> And again. This all sounds like stuff you'd expect from a debugger. I take you 
> volunteer to write a GUI for winedbg?
> 

You provide the hooks I'll start seeing about a eclipse based plugin 
(its easier for me to do that than from scratch =) )

>> 10) Code Checking
>>         Some sort of bounds checking...
>>         Uninitialized variable checking....
>>         Unreachable Code Checking
>>         (I think is being done to an extent with Dan's runs of valgrind)
> 
> We're already running static analysis tools and other checkers on the code.
> 

I thought so.... this was from an older list so I just included it. 
Would not make sense that we were not already...


>> 11) Use the GUI to help enforce the Wine Coding standard.. most modern
>> GUI environments let you specify a style of coding. This would help the
>> new people understand and follow the coding standards set up... instead
>> of guessing like they do now.
> 
> What GUI? The last time you talked about a GUI you were talking about a 
> frontend for winedbg. I don't see how this links to coding standards. If 
> you're talking about IDEs, I think you will find that a lot of the Wine 
> developers consider vim or emacs to be all the GUI they need.
> 

Any Editor is what I mean... Most editors now have the ability to 
specify templates (atleast the ones I have used). This is what I am 
talking about... sorry if I confused you on this... just if we have a 
certain way of doing the code.. (which we do) why not make a template 
for people.



>> 12) Online help / Context help...  point to the IC in the wiki... lots
>> of good stuff there... just hard to find sometimes....
> 
> From the editor?
> 

yes...


>> 13) Integration with bugzilla... they find a bug... they create it in
>> the GUI.. dump out the screen, stack and the like... so some of the base
>> information is collected instead of wasting time back and forth and
>> having so many invalid bugs. Again this format can be enforced through
>> coding style templates... you want to submit a bug here is what you
>> do... check boxes to include things... like I said screen shots... logs,
>> traces, variables, hardware config, etc...
> 
> Your losing me here with "the GUI". Is this going to be a 
> debuger-codechecker-coffe-machine-mail-reader-vcs-compiler program that will 
> also fetch my newspaper?
> 

The debugger.... if a person has found and debugged an issue or just 
finds an issue.. ask for a screen dump... dump the stack to a file and 
so on.... maybe even collect the hardware when we dump and put that in 
the output as well.  This is so we have a consistant set of data coming 
in.. We not be able to say this is a kernel bug... or this is a d3d bug 
but we can atleast say this is a bug only effecting X program on Y 
hardware.. which is a start in the direction of gathering statistics and 
so forth and finding where we need to focus on.

>> 14) Integration with GIT... check and see if there is a new tree out
>> there.. if so... flag it and git it... (also update the GIT page with
>> the latest instructions. Some of us are not GIT people by background...
>> CVS, etc.. so there is a really steep learning curve and its easy to
>> mess a local GIT tree up and have to reload.
> 
> If you can point out what's missing from http://wiki.winehq.org/GitWine I'll 
> gladly add more information to that page.

Someone a few weeks back said the GitWINE page had not been updated in 
quite ahwile and needed to be. I'll see if I can remember who and where 
it was... it happened when I submitted a patch and Dan's patchwatcher 
failed because my tree had somehow got messed up and out of sync even 
though git claimed it was fine and upto date.

> 
>> 15) Link to whats fixed in the new GIT tree... or a list of it...
>> something off the main WINEHQ page that says ok here is 1.1.15 here is
>> what we fixed...
> 
> It's called "changelog", and we already have that.

I had a hard time finding it.... but eventually did.... so just drop 
this one.... other than maybe putting in a bit on the git page 
explaining how to list the deltas from a particular checkpoint... say 
all the delta's from 1.1.5 till current... that would be handy =). If 
GIT cant do that then no biggy....


> 
>> 16) Link to Dan's patchwatcher status... (kinda a workflow sort of
>> thing) to know whats good and bad...
> 
> I'm pretty sure that once patchwatcher is stable, it'll get a prominent link.
> 

ok cool...


>> 17) Generation of the GIT patch and then mail it to the list through a
>> button...
> 
> Oh, from the swiss army knife GUI? 
>

No not the Swiss army knife gui... sheesh.... from the normal GIT GUI... 
have the instructions on how to do that... having something like eclipse 
or other frameworks spawn and do the generation is easy as its just a 
shell call.


>> You have to remember alot of the new people coming in are not old
>> timers like some of us who grew up in a non-gui 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 bugs and helping fix them if we started
>> thinking of something along these lines. This of course is not a
>> complete list... But I think this might be a good next step for
>> something like the summer of code people to do.. or whomever maintains
>> the wine debugger to think seriously about. And no I am not criticizing
>> wine in the least by the above. I really enjoy using wine and hacking
>> around learning things. I want it to be the best it can be..
> 
> From looking at what you proposed, you're looking at a couple of man-years of 
> work on a GUI few if any of the existing Wine devs will use. And without 
> wanting to sound elitist, working on Wine is hard. At least hard enough to 
> make learning some command-line tools we require easy.
> 

Not really... most of the GUI /IDE stuff is already there... its a 
matter of picking something and integrating what we have.. and I am not 
talking of doing this for the existing Dev's... this is for people 
coming on board... or so forth. Its not hard to have both models =). And 
Yes,that did come across as a little elitist but I accept the point you 
are trying to make... However, it is no harder than writing boot loader 
code for embeded devices or device drivers, or kernel code,  etc... its 
just another bit of code... does wonderful stuff... but in the end... 
its just another bit of code people use.

So then is there a wiki page for learning what is needed and say this is 
our process for developing? Just trying to help here... not everything 
in wine is at the level of the kernel development wise.. there are many 
different levels to hack on.. atleast thats my impression....


> I'm convinced that someone who can't learn enough on the command-line to run 
> the basic git, configure and make steps will have a very hard time trying to 
> develop Wine code.
> 
I disagree... you want M$ apps to be ported using the wine libraries... 
your going to get requirements like these.. There are requests for stuff 
like this it in a few threads and bugs where people are asking for some 
of this or in some of the Dist. specific mailing lists.. I am as much a 
command line person as the next one but like I said alot of the newer 
people coming to linux are not and have no desire to even begin to learn 
that way but want to help. And its not just a matter of learning.. its a 
matter of how they are used to developing and  so forth. I deal with 
this problem every day in my RL job so I can see both sides of the 
issue.. But its somewhat of a loosing battle.



> That being said, I think a GUI for winedbg would be a nice tool, and if we can 
> come up with a tool that makes translations easier, that'd be helpful as 
> well. I just don't think that it's possible to create The One GUI To Rule 
> Them All.
> 
> Cheers,
> Kai
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
I agree... there isnt a way to make one gui to rule them all.. but there 
is a need for more tooling =).. Did you see my follow on message on 
other thoughts as well? Has nothing to do with GUI's at all but clearing 
up some of the output... if not I can email it to you..


Chris