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

[Alexis Menard]

On Thu, Jul 19, 2012 at 4:11 PM, Filip Pizlo <fpizlo at apple.com> wrote:
> But I do want a debugging utility to does land, is always compiled in, and that everyone enjoys using.

The header itself in the patch would land so you can use it right away
(and compile even in release). But the actual "traces" or thingy()
calls in the code are not meant to stay/land. I'm not sure I'm clear.

>
> -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



-- 
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia