On 19.07.2012 20:15, Brady Eidson wrote:
On Jul 19, 2012, at 11:01 AM, Oliver Buchtala
<oliver.bucht...@googlemail.com
<mailto:oliver.bucht...@googlemail.com>> wrote:
On 19.07.2012 19:53, Andreas Kling wrote:
On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beid...@apple.com
<mailto:beid...@apple.com>> wrote:
On Jul 10, 2012, at 5:25 AM, Alexis Menard
<alexis.men...@openbossa.org
<mailto:alexis.men...@openbossa.org>> wrote:
> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson
<beid...@apple.com <mailto:beid...@apple.com>> wrote:
>>
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard
<alexis.men...@openbossa.org
<mailto:alexis.men...@openbossa.org>> wrote:
>>
>>> Hi,
>>>
>>> For those who "secretly" use printf debugging :). I know the
>>> recommended way is to use a debugger and it's not the point
of this
>>> discussion.
>>
>> A lot of us do this, and sometimes it's necessary. I agree
with the gripe and support adding something easier.
>>
>>> So I propose wtf() and its stream operator.
>>>
>>> Usage :
>>>
>>> wtf()<<"Hello"<<"World"<<3<<4.53322323; will output : Hello
World 3 4.53322
>>
>> There is no reason to bring in stream operators - that are
willfully absent from WebCore - just for debugging.
>>
>
> But it's really nice for that purpose, and somehow match std::cout
And we quite purposefully don't use std::cout in the project.
>> Overloading functions works just as well.
>
> I'm not sure to understand what you mean here…
I mean relying on C++'s overloading of functions for the
different types you'd like to printf debug.
void debug(WebCore::String&);
void debug(WebCore::Frame*);
void debug(WebCore::Node*);
etc etc etc.
debug(someFrame);
debug(someNode);
debug(someString);
Especially that last one would help me from remembering how to
type "printf("%s", someString.utf8().data())" which is all I've
ever really wanted.
Hello fellow printfers!
While I'm just as ashamed of my printf habits as the next guy, I
think it'd be great if we could move forward with this somehow.
Coming from a background in Qt, the stream operator syntax looks
perfectly normal to me, perhaps you could expand on why we want to
avoid using these in WebKit. Is there a technical reason, or is it
more of a language purity issue?
Regardless, adding a consistent set of
debug(WebCore::MyCoolOverload) methods as suggested would still be
massively useful.
-Kling
Hi,
I am probably one of those people who much dislike printf-debugging.
What is your problem with using a debugger?
The beauty of this discussion is that people who prefer the purity of
using only the debugger can continue using only the debugger and
ignore what printf'ers need to do.
That said, to address your question of "what is your problem with
using a debugger", many issues in WebKit are highly timing related, or
highly dependent on multiple threads or even multiple processes
interacting.
Many crashes I've had the pleasure of working on go away simply by
hitting a breakpoint, and many misbehaviors correct themselves the
same way.
Most of the time the debugger is good enough for me. Other times the
mix of the debugger and printf's has been what cracked the case.
Occasionally ignoring the debugger completely and viewing an "event
stream" of printfs has been the only reasonable way to monitor the
complex interactions of what is going on.
FWIW, there is a gdb python API for changing the behavior... so
called pretty printers.
It is not too difficult to write such pretty-printers.
Some of us don't use gdb. I'm not sure if these work directly in lldb
or if there is an lldb alternative. But...
Maybe providing a set of useful pretty-printers is a better approach
than providing a set of debug functions?
Having a set of debug-build-only functions is also useful in the
debugger without having to turn to the pretty-printers.
I don't see how adding printf helpers for debug builds negatively
affects debugger purists, but I do see how it helps at least a handful
of prolific contributors to the project be more productive.
Thanks,
~Brady
Accepted.
Regards,
Oliver
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
