2009/12/6 Jeff Mahoney
On 12/06/2009 06:22 PM, Rajko M. wrote:
It often requires just ability to set break point with a message, to locate code that makes trouble. No much need to understand the code.
This is a really good point. Personally, I learned C after I was messing around with code. In a previous life, I ran a bunch of DEC Ultrix systems. No shared libraries, ancient X implementation, etc. I ended up building a *lot* of things for these systems and it didn't always go smoothly.
I had some MIPS based DECstations, I remember the "advance" getting
gcc installed and how it eased porting.
Not sure if it's always easier to read code, than write. As touched
on very many coders seem unable to see things from point of view of
other ppl, comment the obvious and leave the whacky & bizarre to speak
for itself.
2009/12/7 Karsten König
It is coming back to think how we can use better smolt and hardware detection tools, make information upload lesser labor intensive, from prospectives of user, developer and/or helper in forums.
This is something that we've discussed informally for a while. I would love to have a tool that automatically sends backtraces of every crashing program that we ship back to a server so that we can
KDE.org has something like this, the "new" Dr. Konqui makes a stacktrace etc what might be important and asks the user how to reproduce it etc, basicly the same as a bugzilla interface, just right after the program crashed and with all the infos at hand (if you have the -debug packages installed that is).
Problem with bugreports like these is people often don't respond to questions,
The problem I have had, is the stack trace doesn't have the symbolic information to make it "useful" and as one is very likely to be punted upstream, there's not much incentive to spend much time on KDE bug reports. Is including symbolics a performance hit, or just a disk space issue? Rob -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org