[webkit-dev] Easing printf based debugging in WebKit with an helper.

[Oliver Buchtala]

On 19.07.2012 20:15, Brady Eidson wrote:
>
> On Jul 19, 2012, at 11:01 AM, Oliver Buchtala 
> <oliver.buchtala at googlemail.com 
> <mailto:oliver.buchtala at googlemail.com>> wrote:
>
>> On 19.07.2012 19:53, Andreas Kling wrote:
>>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beidson at apple.com 
>>> <mailto:beidson at apple.com>> wrote:
>>>
>>>
>>>     On Jul 10, 2012, at 5:25 AM, Alexis Menard
>>>     <alexis.menard at openbossa.org
>>>     <mailto:alexis.menard at openbossa.org>> wrote:
>>>
>>>     > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson
>>>     <beidson at apple.com <mailto:beidson at apple.com>> wrote:
>>>     >>
>>>     >> On Jul 9, 2012, at 2:43 PM, Alexis Menard
>>>     <alexis.menard at openbossa.org
>>>     <mailto:alexis.menard at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120719/d306d6a0/attachment.html>