On Jul 19, 2012, at 11:01 AM, Oliver Buchtala <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> wrote:
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard <alexis.men...@openbossa.org>
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <beid...@apple.com> wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard <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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
