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

[Filip Pizlo]

But I do want a debugging utility to does land, is always compiled in, and that everyone enjoys using. 

-Filip

On Jul 19, 2012, at 11:37 AM, Alexis Menard <alexis.menard at openbossa.org> wrote:

> On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> One reason for preferring printf syntax is that it results in dramatically
>> more compact code. In JSC we take advantage of this to have debug printf
>> support built even in release builds. So or example if you want CodeBlock to
>> print itself in a release build, you don't first have to #define a bunch of
>> things - the relevant method is already built.
> 
> As the Changelog said in the patch, thingy() << ... are not meant to
> land but to help you locally.
> 
>> 
>> The reason for the compactness is the number of calls for a typical printing
>> action. Consider this:
>> 
>> dataLog("foo %d bar %x baz %p\n", a, b, c);
>> 
>> This is one procedure call and one string constant. Note that the machine
>> code to get the string constant is often as big as a procedure call, on some
>> platforms.
>> 
>> Now consider the stream form:
>> 
>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << "
>> baz " << c << endl;
> 
> Ok you give me a valid example (and nice looking) for you in JSC.
> Nobody force you to use the thingy if you don't like it. It seems low
> level printf is better for you, great!
> 
> Now see another use case :
> 
> LayoutRect rect;
> printf("Rect is %i %i %i %i, rect.x(), rect().y(), rect.width(), rect.height());
> 
> for me to get the rect values.
> 
> thingy() << rect; (as LayoutRect could have a << overload, I give an
> example in the patch with IntRect)
> 
> Granted we can achieve it with a
> 
> printf("Rect is %s", debug(rect)); same provided that debug() for a
> LayoutRect is implemented.
> 
> One way or another I'm fine. I just want to ease the process here.
> 
>> 
>> This is 8 procedure calls and three string constants. This code will be
>> somewhere around 8 times fatter. Hence, you will be less likely to want to
>> enable such debug statements in release builds both due to fears concerning
>> unnecessary increases in binary size, and unnecessary increases in compile
>> times.
> 
> As I said, we do not want to land these thingy() <<.
> 
>> 
>> And I'm not even going to start complaining about how unnatural it is to set
>> padding preferences, switch to hex, etc.
> 
> Which is not what the class is meant to solve.
> 
>> 
>> -Filip
>> 
>> On Jul 19, 2012, at 10:53 AM, Andreas Kling <kling at webkit.org> wrote:
>> 
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson <beidson at apple.com> wrote:
>>> 
>>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard <alexis.menard at openbossa.org>
>>> wrote:
>>> 
>>>> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson <beidson at apple.com> wrote:
>>>>> 
>>>>> On Jul 9, 2012, at 2:43 PM, Alexis Menard <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
>> 
>> _______________________________________________
>> 
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> -- 
> Alexis Menard (darktears)
> Software Engineer
> openBossa @ INdT - Instituto Nokia de Tecnologia