<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 19, 2012, at 11:01 AM, Oliver Buchtala <<a href="mailto:oliver.buchtala@googlemail.com">oliver.buchtala@googlemail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 19.07.2012 19:53, Andreas Kling
wrote:<br>
</div>
<blockquote cite="mid:CABXa4CL=X=AmwuTvbs=pS4MfSBh-Oa67CHtrbJUy_+EHQ5CjiA@mail.gmail.com" type="cite">
<div class="gmail_quote">On Tue, Jul 10, 2012 at 4:52 PM, Brady
Eidson <span dir="ltr"><<a moz-do-not-send="true" href="mailto:beidson@apple.com" target="_blank">beidson@apple.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Jul 10, 2012, at 5:25 AM, Alexis Menard <<a moz-do-not-send="true" href="mailto:alexis.menard@openbossa.org">alexis.menard@openbossa.org</a>>
wrote:<br>
<br>
> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <<a moz-do-not-send="true" href="mailto:beidson@apple.com">beidson@apple.com</a>>
wrote:<br>
>><br>
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard <<a moz-do-not-send="true" href="mailto:alexis.menard@openbossa.org">alexis.menard@openbossa.org</a>>
wrote:<br>
>><br>
>>> Hi,<br>
>>><br>
>>> For those who "secretly" use printf debugging
:). I know the<br>
>>> recommended way is to use a debugger and it's
not the point of this<br>
>>> discussion.<br>
>><br>
>> A lot of us do this, and sometimes it's necessary.
I agree with the gripe and support adding something easier.<br>
>><br>
>>> So I propose wtf() and its stream operator.<br>
>>><br>
>>> Usage :<br>
>>><br>
>>>
wtf()<<"Hello"<<"World"<<3<<4.53322323;
will output : Hello World 3 4.53322<br>
>><br>
>> There is no reason to bring in stream operators -
that are willfully absent from WebCore - just for debugging.<br>
>><br>
><br>
> But it's really nice for that purpose, and somehow
match std::cout<br>
<br>
</div>
And we quite purposefully don't use std::cout in the project.<br>
<div class="im"><br>
>> Overloading functions works just as well.<br>
><br>
</div>
> I'm not sure to understand what you mean here…<br>
<br>
I mean relying on C++'s overloading of functions for the
different types you'd like to printf debug.<br>
<br>
void debug(WebCore::String&);<br>
void debug(WebCore::Frame*);<br>
void debug(WebCore::Node*);<br>
<br>
etc etc etc.<br>
<br>
debug(someFrame);<br>
debug(someNode);<br>
debug(someString);<br>
<br>
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.</blockquote>
<div><br>
</div>
<div>Hello fellow printfers!</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Regardless, adding a consistent set of
debug(WebCore::MyCoolOverload) methods as suggested would
still be massively useful.</div>
<div><br>
</div>
<div>-Kling</div>
</div>
<br>
</blockquote>
<br>
Hi,<br>
<br>
I am probably one of those people who much dislike printf-debugging.<br>
What is your problem with using a debugger?<br></div></blockquote><div><br></div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">FWIW, there is a gdb python API for changing the behavior... so
called pretty printers.<br>
It is not too difficult to write such pretty-printers.<br></div></blockquote><div><br></div>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...<br><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">Maybe providing a set of useful pretty-printers is a better approach
than providing a set of debug functions?<br></div></blockquote><div><br></div><div>Having a set of debug-build-only functions is also useful in the debugger without having to turn to the pretty-printers.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>~Brady</div><div><br></div><div><br></div><div><br></div></div></body></html>