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

[Darin Adler]

On Nov 9, 2012, at 9:59 AM, Rafael Brandao  wrote:

> I'd go with the overloads in a single file

Why? Seems the overloads should be in the files of the classes they are for.

-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Rafael Brandao]

You're right. Do you have any consensus of which approach is the best?
I'd go with the overloads in a single file, as each one of them are likely
inline, and  this would make easier to add overloads.

On Fri, Nov 9, 2012 at 2:33 PM, Maciej Stachowiak  wrote:

>
> You could either put the code in the headers for the relevant classes, or
> the base mechanism in WTF and specific overloads in a catchall header for
> WebCore. You don't have to put the basic mechanism in WebCore just to have
> overloads for WebCore types.
>
>  - Maciej
>
>
> On Nov 9, 2012, at 9:29 AM, Rafael Brandao 
> wrote:
>
> I was just trying to avoid adding code on other places, and it seemed
> wrong to include WebCore files inside WTF.
> If there's no problem on changing other files (like IntRect, IntSize,
> etc.), I have no problem with moving the appropriate overload around
> ENABLE(DEBUG_HELPERS).
>
> Regards,
>
> On Fri, Nov 9, 2012 at 2:19 PM, Filip Pizlo  wrote:
>
>> I like this patch.
>>
>> But I don't quite see why this couldn't live in WTF.  It would certainly
>> be useful from places in JSC and WTF, so it would be unfortunate if this
>> was WebCore-only.  And I don't see the circular dependency.  And if you
>> wanted to have a wtfPrint() for IntRect, then couldn't you put the
>> appropriate overload(s) in IntRect's header file?
>>
>> -F
>>
>>
>>
>> On Nov 9, 2012, at 6:18 AM, Rafael Brandao 
>> wrote:
>>
>> I've just submitted a patch for this issue (bug 
>> 90823).
>> I'm also a shameless printfer and I believe the project could benefit with
>> such debugging helpers.
>> I've decided to isolate the debug definitions in a single place, so
>> instead of adding alien code on IntRect to teach him how to debug, they're
>> all in
>> DebugHelpers.cpp/.h. This code is also protected by ENABLE(DEBUG_HELPERS)
>> so people could keep things untouched if they want to.
>>
>> Instead of putting it in WTF like the original proposal, I've put into
>> WebCore. The reasoning behind it was a cyclic dependency over
>> WTF and WebCore that would be introduced if I've tried to isolate things
>> in a single place in WTF (for example, there in WTF I would need to include
>> WebCore's IntRect, which is most likely wrong).
>>
>> Regards,
>>
>> --
>> Rafael Brandao @ INdT
>>  ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>
>
> --
> Rafael Brandao @ INdT
>  ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>


-- 
Rafael Brandao @ INdT
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

You could either put the code in the headers for the relevant classes, or the 
base mechanism in WTF and specific overloads in a catchall header for WebCore. 
You don't have to put the basic mechanism in WebCore just to have overloads for 
WebCore types.

 - Maciej

On Nov 9, 2012, at 9:29 AM, Rafael Brandao  wrote:

> I was just trying to avoid adding code on other places, and it seemed wrong 
> to include WebCore files inside WTF.
> If there's no problem on changing other files (like IntRect, IntSize, etc.), 
> I have no problem with moving the appropriate overload around 
> ENABLE(DEBUG_HELPERS).
> 
> Regards,
> 
> On Fri, Nov 9, 2012 at 2:19 PM, Filip Pizlo  wrote:
> I like this patch.
> 
> But I don't quite see why this couldn't live in WTF.  It would certainly be 
> useful from places in JSC and WTF, so it would be unfortunate if this was 
> WebCore-only.  And I don't see the circular dependency.  And if you wanted to 
> have a wtfPrint() for IntRect, then couldn't you put the appropriate 
> overload(s) in IntRect's header file?
> 
> -F
> 
> 
> 
> On Nov 9, 2012, at 6:18 AM, Rafael Brandao  wrote:
> 
>> I've just submitted a patch for this issue (bug 90823). I'm also a shameless 
>> printfer and I believe the project could benefit with such debugging helpers.
>> I've decided to isolate the debug definitions in a single place, so instead 
>> of adding alien code on IntRect to teach him how to debug, they're all in
>> DebugHelpers.cpp/.h. This code is also protected by ENABLE(DEBUG_HELPERS) so 
>> people could keep things untouched if they want to.
>> 
>> Instead of putting it in WTF like the original proposal, I've put into 
>> WebCore. The reasoning behind it was a cyclic dependency over
>> WTF and WebCore that would be introduced if I've tried to isolate things in 
>> a single place in WTF (for example, there in WTF I would need to include
>> WebCore's IntRect, which is most likely wrong).
>> 
>> Regards,
>> 
>> -- 
>> Rafael Brandao @ INdT
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> 
> 
> 
> -- 
> Rafael Brandao @ INdT
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Rafael Brandao]

I was just trying to avoid adding code on other places, and it seemed wrong
to include WebCore files inside WTF.
If there's no problem on changing other files (like IntRect, IntSize,
etc.), I have no problem with moving the appropriate overload around
ENABLE(DEBUG_HELPERS).

Regards,

On Fri, Nov 9, 2012 at 2:19 PM, Filip Pizlo  wrote:

> I like this patch.
>
> But I don't quite see why this couldn't live in WTF.  It would certainly
> be useful from places in JSC and WTF, so it would be unfortunate if this
> was WebCore-only.  And I don't see the circular dependency.  And if you
> wanted to have a wtfPrint() for IntRect, then couldn't you put the
> appropriate overload(s) in IntRect's header file?
>
> -F
>
>
>
> On Nov 9, 2012, at 6:18 AM, Rafael Brandao 
> wrote:
>
> I've just submitted a patch for this issue (bug 
> 90823).
> I'm also a shameless printfer and I believe the project could benefit with
> such debugging helpers.
> I've decided to isolate the debug definitions in a single place, so
> instead of adding alien code on IntRect to teach him how to debug, they're
> all in
> DebugHelpers.cpp/.h. This code is also protected by ENABLE(DEBUG_HELPERS)
> so people could keep things untouched if they want to.
>
> Instead of putting it in WTF like the original proposal, I've put into
> WebCore. The reasoning behind it was a cyclic dependency over
> WTF and WebCore that would be introduced if I've tried to isolate things
> in a single place in WTF (for example, there in WTF I would need to include
> WebCore's IntRect, which is most likely wrong).
>
> Regards,
>
> --
> Rafael Brandao @ INdT
>  ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>


-- 
Rafael Brandao @ INdT
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizlo]

I like this patch.

But I don't quite see why this couldn't live in WTF.  It would certainly be 
useful from places in JSC and WTF, so it would be unfortunate if this was 
WebCore-only.  And I don't see the circular dependency.  And if you wanted to 
have a wtfPrint() for IntRect, then couldn't you put the appropriate 
overload(s) in IntRect's header file?

-F



On Nov 9, 2012, at 6:18 AM, Rafael Brandao  wrote:

> I've just submitted a patch for this issue (bug 90823). I'm also a shameless 
> printfer and I believe the project could benefit with such debugging helpers.
> I've decided to isolate the debug definitions in a single place, so instead 
> of adding alien code on IntRect to teach him how to debug, they're all in
> DebugHelpers.cpp/.h. This code is also protected by ENABLE(DEBUG_HELPERS) so 
> people could keep things untouched if they want to.
> 
> Instead of putting it in WTF like the original proposal, I've put into 
> WebCore. The reasoning behind it was a cyclic dependency over
> WTF and WebCore that would be introduced if I've tried to isolate things in a 
> single place in WTF (for example, there in WTF I would need to include
> WebCore's IntRect, which is most likely wrong).
> 
> Regards,
> 
> -- 
> Rafael Brandao @ INdT
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Rafael Brandao]

I've just submitted a patch for this issue (bug
90823).
I'm also a shameless printfer and I believe the project could benefit with
such debugging helpers.
I've decided to isolate the debug definitions in a single place, so instead
of adding alien code on IntRect to teach him how to debug, they're all in
DebugHelpers.cpp/.h. This code is also protected by ENABLE(DEBUG_HELPERS)
so people could keep things untouched if they want to.

Instead of putting it in WTF like the original proposal, I've put into
WebCore. The reasoning behind it was a cyclic dependency over
WTF and WebCore that would be introduced if I've tried to isolate things in
a single place in WTF (for example, there in WTF I would need to include
WebCore's IntRect, which is most likely wrong).

Regards,

-- 
Rafael Brandao @ INdT
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Thiago Marcos P. Santos]

On Thu, Jul 19, 2012 at 9:27 PM, Andreas Kling  wrote:
> On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo  wrote:
>>
>>
>> dataLog("foo %d bar %x baz %p\n", a, b, c);
>
>
> Reasoning and valid arguments aside, that actually looks totally beautiful.
> Do want.
>

+1 from this shameless printfer.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[John Yani]

>> That possibility aside, the stronger part of my objection is language
>> purity.  WebCore uses C++ as "C with classes" and I don't think it's worth
>> it to confuse new (or existing) contributors about that going forward.
>>
>
> Can you elaborate why WebCore uses C++ as  "C with classes"?

Probably he meant that Webkit doesn't use STL, exceptions and RTTI.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 25, 2012, at 8:25 AM, Yong Li  wrote:

> 2012/7/19 Brady Eidson :
>> 
>> On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:
>> 
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>> 
>>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>>> wrote:
>>> 
 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> 
> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
> 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?
>> 
>> 
>> A possible technical reason - that I am 100% theorizing about - is that it
>> might bring in more libraries at link time or runtime since it would be the
>> absolute first use of stream operators in the project.
>> 
>> That possibility aside, the stronger part of my objection is language
>> purity.  WebCore uses C++ as "C with classes" and I don't think it's worth
>> it to confuse new (or existing) contributors about that going forward.
>> 
> 
> Can you elaborate why WebCore uses C++ as  "C with classes"?
> 
> We are using namespace, template, operator overloading, virtual
> functions, multi-inheritance, scope object, and even
> pointer-to-member. We prefer Vector<> to C array, and prefer
> OwnPtr/RefPtr to C pointer. Where is C stuff?

I mean we use all the things you just said but we do not use C++ streams.

~Brady

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Yong Li]

2012/7/19 Brady Eidson :
>
> On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:
>
> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> >> 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?
>
>
> A possible technical reason - that I am 100% theorizing about - is that it
> might bring in more libraries at link time or runtime since it would be the
> absolute first use of stream operators in the project.
>
> That possibility aside, the stronger part of my objection is language
> purity.  WebCore uses C++ as "C with classes" and I don't think it's worth
> it to confuse new (or existing) contributors about that going forward.
>

Can you elaborate why WebCore uses C++ as  "C with classes"?

We are using namespace, template, operator overloading, virtual
functions, multi-inheritance, scope object, and even
pointer-to-member. We prefer Vector<> to C array, and prefer
OwnPtr/RefPtr to C pointer. Where is C stuff?

> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload)
> methods as suggested would still be massively useful.
>
>
> Definitely.
>
> ~Brady
>
>
> -Kling
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Shezan Baig]

On Fri, Jul 20, 2012 at 11:48 AM, Brady Eidson  wrote:
> On Jul 20, 2012, at 7:53 AM, Shezan Baig  wrote:
>> And because I'm in the middle of debugging a particular issue, I don't
>> really want to create a new type that wraps up those (potentially
>> unrelated) variables, just in order to create an overloaded "debug()"
>> function that does the pretty printing.
>
> I'm not quite sure what your point is here.
>
> - If you mean you don't want to be hassled by added a new template for a 
> super long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when 
> the built in utility only supports up through k - then that seems somewhat 
> silly as doing so would be simple and mechanical.
>
> - If you mean you don't want to be hassled to add a new overload for the type 
> you'd like to print, then you'd still have to add a new operator << overload 
> for that type if it didn't already exist.
>
> - If you mean you don't think that debug() statements could be broken up in 
> to multiple lines, of course they can.
>
> debug("Selectively printing variables:";
>if (isSet(someVar1))
> debug("someVar1 = ", someVar1);
>if (isSet(someVar2))
> debug("someVar1 = ", someVar1);
>if (someVector.size())
> debug(" someVector.items = ", someVector);
> debug("\n");
>


Yes, this one is pretty much what I meant.  My example was a bit
simplified, but I was thinking more along the lines that the code
around the debug() statements could be expensive, for example,
calculating some value from multiple sources and printing the final
result.  Within the context of a single function, it might not make
sense to create a separate function that is responsible for
calculating those values, especially if the variables involved are not
typically related.

But your points about readability and such are understood.

Thanks,
-shez-


> Also notice it would be easy to templatize a debug() override to handle the 
> pretty-printing of the vector directly, in addition to other POD and 
> non-class types.
>
> Even without the vector enhancement, this version is simple easier on my eyes 
> as it's not at odds with the entire rest of our code base.
>
> ~Brady
>
>> -shez-
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 20, 2012, at 7:53 AM, Shezan Baig  wrote:

> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev  wrote:
>> 
>> 19.07.2012, 22:20, "Filip Pizlo" :
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " 
>>> baz " << c << endl;
>>> 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.
>> 
>> Well, if all << operators are inline, it will be optimized. You also don't 
>> have to add endl, because "thingy" can add '\n' and flush buffer at the end 
>> by default (like qDebug does)
>> 
> 
> 
> Also, if "START_THINGY" and "END_THINGY" are defined as:
> 
> #define START_THINGY  if (enableDebug) { thingy
> #define END_THINGY<< endl; }
> 
> Then a statement like:
> 
> START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
> << b << " baz " << c << END_THINGY;
> 
> will all be wrapped up within an "if (enableDebug)" condition, which
> we would only turn on when we need the log output, so the cost of the
> streaming/printing can be virtually eliminated even if we decide to
> land the code.

I see in your followup you realized we could further wrap these in #ifndef 
NDEBUG blocks.  That's all good and well until someone takes a block like...

> This also allows us to do more complex things like:
> 
> START_THINGY << "Selectively printing variables:";
>if (isSet(someVar1))
>thingy << " someVar1 = '" << someVar1 << "'";
>if (isSet(someVar2))
>thingy << " someVar2 = '" << someVar2 << "'";
> 
>if (someArray.length()) {
>thingy << " someArray.items = [";
>for (int i = 0; i < someArray.length(); ++i) {
>thingy << someArray[i] << ", ";
>}
>thingy << "]";
>}
> thingy << END_THINGY;

…this and tries to add their own internal #ifndef DEBUG blocks within the 
statement.  For this reason we tend to keep the "automatically #ifdef NDEBUG 
protected" utilities like LOG and ASSERT limited to a single statement.

In general this is voluminous code we'd probably not want landed the same way 
we like dataLog() and LOG() statements to be landed.  But a specific reason we 
wouldn't want it landed is that It's not at all obvious to a casual observer 
that this entire block is meant to be debug only.

> And because I'm in the middle of debugging a particular issue, I don't
> really want to create a new type that wraps up those (potentially
> unrelated) variables, just in order to create an overloaded "debug()"
> function that does the pretty printing.

I'm not quite sure what your point is here.

- If you mean you don't want to be hassled by added a new template for a super 
long debug statement - debug(a, b, c, d, e, f, g, h, i, j, k, l) when the built 
in utility only supports up through k - then that seems somewhat silly as doing 
so would be simple and mechanical.

- If you mean you don't want to be hassled to add a new overload for the type 
you'd like to print, then you'd still have to add a new operator << overload 
for that type if it didn't already exist.

- If you mean you don't think that debug() statements could be broken up in to 
multiple lines, of course they can.

debug("Selectively printing variables:";
   if (isSet(someVar1))
debug("someVar1 = ", someVar1);
   if (isSet(someVar2))
debug("someVar1 = ", someVar1);
   if (someVector.size())
debug(" someVector.items = ", someVector);
debug("\n");

Also notice it would be easy to templatize a debug() override to handle the 
pretty-printing of the vector directly, in addition to other POD and non-class 
types.

Even without the vector enhancement, this version is simple easier on my eyes 
as it's not at odds with the entire rest of our code base.

~Brady

> -shez-
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Shezan Baig]

On Fri, Jul 20, 2012 at 10:53 AM, Shezan Baig  wrote:
> On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev  wrote:
>>
>> 19.07.2012, 22:20, "Filip Pizlo" :
>>> Now consider the stream form:
>>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " 
>>> baz " << c << endl;
>>> 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.
>>
>> Well, if all << operators are inline, it will be optimized. You also don't 
>> have to add endl, because "thingy" can add '\n' and flush buffer at the end 
>> by default (like qDebug does)
>>
>
>
> Also, if "START_THINGY" and "END_THINGY" are defined as:
>
> #define START_THINGY  if (enableDebug) { thingy
> #define END_THINGY<< endl; }
>


And we could also wrap these macros with #ifdef ENABLE_THINGY, so even
the compile-time cost is eliminated if we don't want to include thingy
output in our build.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Shezan Baig]

On Fri, Jul 20, 2012 at 7:46 AM, Konstantin Tokarev  wrote:
>
> 19.07.2012, 22:20, "Filip Pizlo" :
>> Now consider the stream form:
>> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " 
>> baz " << c << endl;
>> 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.
>
> Well, if all << operators are inline, it will be optimized. You also don't 
> have to add endl, because "thingy" can add '\n' and flush buffer at the end 
> by default (like qDebug does)
>


Also, if "START_THINGY" and "END_THINGY" are defined as:

#define START_THINGY  if (enableDebug) { thingy
#define END_THINGY<< endl; }

Then a statement like:

START_THINGY << "foo " << a << " bar " << someWeirdNonsenseToEnableHex
<< b << " baz " << c << END_THINGY;

will all be wrapped up within an "if (enableDebug)" condition, which
we would only turn on when we need the log output, so the cost of the
streaming/printing can be virtually eliminated even if we decide to
land the code.

This also allows us to do more complex things like:

START_THINGY << "Selectively printing variables:";
if (isSet(someVar1))
thingy << " someVar1 = '" << someVar1 << "'";
if (isSet(someVar2))
thingy << " someVar2 = '" << someVar2 << "'";

if (someArray.length()) {
thingy << " someArray.items = [";
for (int i = 0; i < someArray.length(); ++i) {
thingy << someArray[i] << ", ";
}
thingy << "]";
}
thingy << END_THINGY;

Often when I'm debugging something, I really want to selectively craft
the log message so that I only need to see the variables I'm
interested in, depending on the state of the program *at that time*.
This reduces the clutter in the log message, and since this whole
block is wrapped within "if (enableDebug)", the cost of any additional
work used to generate the log message is completely eliminated if
debug mode is disabled.

And because I'm in the middle of debugging a particular issue, I don't
really want to create a new type that wraps up those (potentially
unrelated) variables, just in order to create an overloaded "debug()"
function that does the pretty printing.

-shez-
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Konstantin Tokarev]

19.07.2012, 22:20, "Filip Pizlo" :
> Now consider the stream form:
> thingy << "foo " << a << " bar " << someWeirdNonsenseToEnableHex << b << " 
> baz " << c << endl;
> 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.

Well, if all << operators are inline, it will be optimized. You also don't have 
to add endl, because "thingy" can add '\n' and flush buffer at the end by 
default (like qDebug does)

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 19, 2012, at 3:09 PM, Filip Pizlo  wrote:

> On Jul 19, 2012, at 2:58 PM, Balazs Kelemen  wrote:
> 
>> But neither these compile to a single function call. Or we could define 
>> simple inline debug() overrides but we could also do that with the stream 
>> operator. And anyway, if the actual calls are not supposed to land than it 
>> doesn't matter how compact it is. For me the stream operator is a bit nicer.
> 
> This goal of not landing the actual calls is nice in theory, but we quickly 
> found in JSC that it's impractical.  We did this for a while: each time 
> someone needed to debug something, they'd add some printf's, find the bug, 
> delete the printf's, land the change.  Then the next person to debug the code 
> would add in the same printf's, find another bug, delete those printf's 
> again, and land the change.  Rinse and repeat.  This got horrible very 
> quickly.

There's also been an ebb and flow of this with "LOG()" in WebCore and WebKit 
over the years.  Currently we're in a long ebb...

I used to be a proponent of checking in sensible LOG statements that multiple 
people could benefit from, but the syntax of having only printf() style 
formatters quickly make many potentially useful statements unwieldily.

This new proposal has the potential to clean up old LOG's and more easily 
introduce new ones going forward.

> In summary, I'm not arguing against having a nicer debug API than the current 
> dataLog(); I'm arguing quite the opposite: that we should investigate such an 
> API, and that the API should be robust enough that we land not just the API 
> but also allow for the landing of dump() methods for classes that webkittens 
> find themselves having to frequently add printf-style debugging to.

I wasn't originally considering the outcome of this thread to be a new log() 
pattern that we could actually land in code.  But seeing the form of Maciej's 
proposal has me tacitly excited.

~Brady

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizlo]

On Jul 19, 2012, at 2:58 PM, Balazs Kelemen  wrote:

> On 07/19/2012 11:27 PM, Maciej Stachowiak wrote:
>> On Jul 10, 2012, at 8:52 AM, Brady Eidson  wrote:
>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
>>> wrote:
>>> 
 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
> 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.
>> In principle, we could also have this support multiple arguments, so you 
>> could write:
>> 
>> debug("frame: ", someFrame, " node: ", someNode, " string", someString);
>> 
>> This would be no more verbose than the<<  style, but could compile to a 
>> single function call at the call site and therefore could be relatively 
>> compact. I would find this easier to deal with than a unary function or a 
>> printf-style format string. The way you'd do this is by defining template 
>> functions which call a unary overloaded function for each argument:
>> 
>> template  debug(A a, B b)
>> {
>> debug(a);
>> debug(b);
>> }
>> 
>> template  debug(A a, B b, C c)
>> {
>> debug(a);
>> debug(b);
>> debug(c);
>> }
>> 
>> template  debug(A a, B b, C 
>> c, D d)
>> {
>> debug(a);
>> debug(b);
>> debug(c);
>> debug(d);
>> }
>> 
>> ... and so on up to some reasonable number of arguments.
> 
> 
> But neither these compile to a single function call. Or we could define 
> simple inline debug() overrides but we could also do that with the stream 
> operator. And anyway, if the actual calls are not supposed to land than it 
> doesn't matter how compact it is. For me the stream operator is a bit nicer.

This goal of not landing the actual calls is nice in theory, but we quickly 
found in JSC that it's impractical.  We did this for a while: each time someone 
needed to debug something, they'd add some printf's, find the bug, delete the 
printf's, land the change.  Then the next person to debug the code would add in 
the same printf's, find another bug, delete those printf's again, and land the 
change.  Rinse and repeat.  This got horrible very quickly.

So instead, we decided on the dataLog() API, and made the policy that for any 
sizeable set of dataLog() calls that were found to be useful for a particular 
debugging task, we would encapsulate them behind a dump() method on the 
relevant class and land that method along with the fixes.  The thing that we 
would _not_ land is the call to the dump() method.  The point being that it's 
easier to add back in the call to dump(), than it is to add back in all of the 
calls to dataLog().  And even in some cases, we did land the call to dump(), 
behind a check of some flag that can be flipped in one .cpp file or via an 
environment variable, or even via a command-line switch if you wanted to go so 
far.

We've found that this is nicer in the long term and has sped up debugging for a 
lot of common scenarios.

Thus, I tend to think that we want to come up with a debug printing API that 
produces sufficiently compact code that this is practical.  I kind of like 
Maciej's approach; I think it could work, though you risk template bloat.  A 
good compiler and linker will probably reduce that bloat, but such things are 
imperfect.

It's also possible that our obsession with ensuring that the debug code (i.e. 
the innards of the dump() methods) is compact is unfounded.  With the dataLog() 
API I found that it generally adds much less than 1% to the size of the 
JavaScriptCore library, so we declared victory.  But maybe we can give 
ourselves more latitude and use a nicer API.

In summary, I'm not arguing against having a nicer debug API than the current 
dataLog(); I'm arguing quite the opposite: that

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

[Balazs Kelemen]

On 07/19/2012 11:27 PM, Maciej Stachowiak wrote:

On Jul 10, 2012, at 8:52 AM, Brady Eidson  wrote:


On Jul 10, 2012, at 5:25 AM, Alexis Menard  wrote:


On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:

On Jul 9, 2012, at 2:43 PM, Alexis Menard  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.

In principle, we could also have this support multiple arguments, so you could 
write:

debug("frame: ", someFrame, " node: ", someNode, " string", someString);

This would be no more verbose than the<<  style, but could compile to a single 
function call at the call site and therefore could be relatively compact. I would 
find this easier to deal with than a unary function or a printf-style format string. 
The way you'd do this is by defining template functions which call a unary overloaded 
function for each argument:

template  debug(A a, B b)
{
 debug(a);
 debug(b);
}

template  debug(A a, B b, C c)
{
 debug(a);
 debug(b);
 debug(c);
}

template  debug(A a, B b, C c, 
D d)
{
 debug(a);
 debug(b);
 debug(c);
 debug(d);
}

... and so on up to some reasonable number of arguments.



But neither these compile to a single function call. Or we could define 
simple inline debug() overrides but we could also do that with the 
stream operator. And anyway, if the actual calls are not supposed to 
land than it doesn't matter how compact it is. For me the stream 
operator is a bit nicer.


-kbalazs
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 19, 2012, at 2:46 PM, Antti Koivisto  wrote:

> Maciej Stachowiak  kirjoitti 20.7.2012 kello 0.27:
> 
>> 
>> In principle, we could also have this support multiple arguments, so you 
>> could write:
>> 
>> debug("frame: ", someFrame, " node: ", someNode, " string", someString);
> 
> I think this is the way to go for the easy syntax. A format string version 
> should also be available.

I'm totally on board with this, too.

~Brady

> 
> 
>  antti
> 
>> 
>> This would be no more verbose than the << style, but could compile to a 
>> single function call at the call site and therefore could be relatively 
>> compact. I would find this easier to deal with than a unary function or a 
>> printf-style format string. The way you'd do this is by defining template 
>> functions which call a unary overloaded function for each argument:
>> 
>> template debug(A a, B b)
>> {
>>   debug(a);
>>   debug(b);
>> }
>> 
>> template debug(A a, B b, C c)
>> {
>>   debug(a);
>>   debug(b);
>>   debug(c);
>> }
>> 
>> template debug(A a, B b, C 
>> c, D d)
>> {
>>   debug(a);
>>   debug(b);
>>   debug(c);
>>   debug(d);
>> }
>> 
>> ... and so on up to some reasonable number of arguments.
>> 
>> Regards,
>> Maciej
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

On Jul 10, 2012, at 8:52 AM, Brady Eidson  wrote:

> 
> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
> wrote:
> 
>> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>>> 
>>> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
>>> 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.

In principle, we could also have this support multiple arguments, so you could 
write:

debug("frame: ", someFrame, " node: ", someNode, " string", someString);

This would be no more verbose than the << style, but could compile to a single 
function call at the call site and therefore could be relatively compact. I 
would find this easier to deal with than a unary function or a printf-style 
format string. The way you'd do this is by defining template functions which 
call a unary overloaded function for each argument:

template debug(A a, B b)
{
debug(a);
debug(b);
}

template debug(A a, B b, C c)
{
debug(a);
debug(b);
debug(c);
}

template debug(A a, B b, C c, D 
d)
{
debug(a);
debug(b);
debug(c);
debug(d);
}

... and so on up to some reasonable number of arguments.

Regards,
Maciej






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexis Menard]

On Thu, Jul 19, 2012 at 4:11 PM, Filip Pizlo  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  
> wrote:
>
>> On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo  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  wrote:
>>>
>>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:


 On Jul 10, 2012, at 5:25 AM, Alexis Menard 
 wrote:

> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>>
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> 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 s

Re: [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  wrote:

> On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo  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  wrote:
>> 
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>> 
>>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>>> wrote:
>>> 
 On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> 
> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
> 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@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>> 
>> 
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.

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

[Tony Chang]

On Thu, Jul 19, 2012 at 11:35 AM, Oliver Buchtala <
oliver.bucht...@googlemail.com> wrote:

> On 19.07.2012 20:26, Maciej Stachowiak wrote:
>
>> On Jul 19, 2012, at 11:01 AM, Oliver Buchtala <
>> oliver.buchtala@googlemail.**com > wrote:
>> 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.
>>>
>>> Maybe providing a set of useful pretty-printers is a better approach
>>> than providing a set of debug functions?
>>>
>> I would love to see a set of useful pretty printers that we could share.
>> Do you have any we could use as a starting point?
>>
>>
>>  I have written some for other projects... not yet for webkit.
>
> Brady noted that there are some of them around?
> I could provide some pretty-printers, if necessary...
>

There are some already in WebKit/Tools/gdb/webkit.py.  It already includes
formatters for WTF::String, WTF::CString and more.  Feel free to add more
to it.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Jul 19, 2012 at 11:15 AM, Brady Eidson  wrote:

> 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  wrote:
>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> 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.
>

I usually avoid using printfs at all cost and prefer using a proper
debugger with IDE front end. However,

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

I can't agree more on these points.

Also, if you have to debug a function that gets called million times and
only subset of them matter, then going through each call with gdb is much
less productive than printf based logging at times.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexis Menard]

On Thu, Jul 19, 2012 at 3:20 PM, Filip Pizlo  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  wrote:
>
> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> >> 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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Oliver Buchtala]

On 19.07.2012 20:26, Maciej Stachowiak wrote:

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala  
wrote:


Hi,

I am probably one of those people who much dislike printf-debugging.
What is your problem with using a debugger?

Maybe because the displayed information is not appropriate?
E.g., you would like
 someString.utf8().data()
instead of
 someString

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.

Maybe providing a set of useful pretty-printers is a better approach than 
providing a set of debug functions?

I would love to see a set of useful pretty printers that we could share. Do you 
have any we could use as a starting point?

Regards,
Maciej



I have written some for other projects... not yet for webkit.

Brady noted that there are some of them around?
I could provide some pretty-printers, if necessary...

Regards,
Oliver

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizlo]

I should note that WTF already has an API for this. See DataLog.h. In JSC we've 
been using it quite extensively to add pretty printers for a bunch of classes. 

-Filip

On Jul 19, 2012, at 11:03 AM, Brady Eidson  wrote:

> 
> On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:
> 
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>> 
>>> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
>>> wrote:
>>> 
>>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>>> >>
>>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
>>> >> 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?
> 
> A possible technical reason - that I am 100% theorizing about - is that it 
> might bring in more libraries at link time or runtime since it would be the 
> absolute first use of stream operators in the project.
> 
> That possibility aside, the stronger part of my objection is language purity. 
>  WebCore uses C++ as "C with classes" and I don't think it's worth it to 
> confuse new (or existing) contributors about that going forward.
> 
>> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) 
>> methods as suggested would still be massively useful.
> 
> Definitely.
> 
> ~Brady
> 
>> 
>> -Kling
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Andreas Kling]

On Thu, Jul 19, 2012 at 7:20 PM, Filip Pizlo  wrote:

>
> dataLog("foo %d bar %x baz %p\n", a, b, c);
>

Reasoning and valid arguments aside, that actually looks totally beautiful.
Do want.

-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Maciej Stachowiak]

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala  
wrote:

> 
> Hi,
> 
> I am probably one of those people who much dislike printf-debugging.
> What is your problem with using a debugger?
> 
> Maybe because the displayed information is not appropriate?
> E.g., you would like
> someString.utf8().data()
> instead of
> someString
> 
> 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.
> 
> Maybe providing a set of useful pretty-printers is a better approach than 
> providing a set of debug functions?

I would love to see a set of useful pretty printers that we could share. Do you 
have any we could use as a starting point?

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [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 
> wrote:



On 19.07.2012 19:53, Andreas Kling wrote:
On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson > wrote:



On Jul 10, 2012, at 5:25 AM, Alexis Menard
mailto:alexis.men...@openbossa.org>> wrote:

> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson
mailto:beid...@apple.com>> wrote:
>>
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard
mailto: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




Accepted.

Regards,
Oliver


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Filip Pizlo]

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. 

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;

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.

And I'm not even going to start complaining about how unnatural it is to set 
padding preferences, switch to hex, etc. 

-Filip

On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:

> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>> 
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
>> wrote:
>> 
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
>> >> 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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Konstantin Tokarev]

19.07.2012, 22:06, "Alexis Menard" :
>
> Say you have a low powered machine that can't link WebKit in debug
> even stripped out of SVG etc...

... or you want to debug on device which cannot run debug WebKit under
gdb because of memory limit.

... or you want to print some value from code which is executed too many
times during page load and setting breakpoint is just non-productive.


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 19, 2012, at 11:01 AM, Oliver Buchtala  
wrote:

> On 19.07.2012 19:53, Andreas Kling wrote:
>> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>> 
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
>> wrote:
>> 
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
>> >> 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

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

[Alexis Menard]

On Thu, Jul 19, 2012 at 3:01 PM, Oliver Buchtala
 wrote:
> On 19.07.2012 19:53, Andreas Kling wrote:
>
> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
>>
>>
>> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
>> wrote:
>>
>> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> >>
>> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
>> >> 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?

Say you have a low powered machine that can't link WebKit in debug
even stripped out of SVG etc...

>
> Maybe because the displayed information is not appropriate?
> E.g., you would like
> someString.utf8().data()
> instead of
> someString
>
> 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.

I think we have some of those.

>
> Maybe providing a set of useful pretty-printers is a better approach than
> providing a set of debug functions?
>
> Regards,
> Oliver
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>



-- 
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 19, 2012, at 10:53 AM, Andreas Kling  wrote:

> On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:
> 
> On Jul 10, 2012, at 5:25 AM, Alexis Menard  
> wrote:
> 
> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> >>
> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
> >> 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?

A possible technical reason - that I am 100% theorizing about - is that it 
might bring in more libraries at link time or runtime since it would be the 
absolute first use of stream operators in the project.

That possibility aside, the stronger part of my objection is language purity.  
WebCore uses C++ as "C with classes" and I don't think it's worth it to confuse 
new (or existing) contributors about that going forward.

> Regardless, adding a consistent set of debug(WebCore::MyCoolOverload) methods 
> as suggested would still be massively useful.

Definitely.

~Brady

> 
> -Kling

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Oliver Buchtala]

On 19.07.2012 19:53, Andreas Kling wrote:
On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson > wrote:



On Jul 10, 2012, at 5:25 AM, Alexis Menard
mailto:alexis.men...@openbossa.org>>
wrote:

> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson mailto:beid...@apple.com>> wrote:
>>
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard
mailto: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?

Maybe because the displayed information is not appropriate?
E.g., you would like
someString.utf8().data()
instead of
someString

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.

Maybe providing a set of useful pretty-printers is a better approach 
than providing a set of debug functions?


Regards,
Oliver

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Andreas Kling]

On Tue, Jul 10, 2012 at 4:52 PM, Brady Eidson  wrote:

>
> On Jul 10, 2012, at 5:25 AM, Alexis Menard 
> wrote:
>
> > On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
> >>
> >> On Jul 9, 2012, at 2:43 PM, Alexis Menard 
> 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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 10, 2012, at 5:25 AM, Alexis Menard  wrote:

> On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>> 
>> On Jul 9, 2012, at 2:43 PM, Alexis Menard  
>> 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.

~Brady

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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexis Menard]

On Mon, Jul 9, 2012 at 6:53 PM, Brady Eidson  wrote:
>
> On Jul 9, 2012, at 2:43 PM, Alexis Menard  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

> Overloading functions works just as well.

I'm not sure to understand what you mean here...

>
> ~Brady



-- 
Alexis Menard (darktears)
Software Engineer
openBossa @ INdT - Instituto Nokia de Tecnologia
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Brady Eidson]

On Jul 9, 2012, at 2:43 PM, Alexis Menard  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.

Overloading functions works just as well.

~Brady
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Philip Rogers]

Not that I admit to using printf debugging, but if I were to,
hypothetically of course, I would find this patch helpful.


On Mon, Jul 9, 2012 at 2:43 PM, Alexis Menard
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.
>
> The other day I was working on the Mac port (with no real possibility
> to have a debug build) and I missed a lot a great feature we have in
> Qt : qDebug(). I find the usage of printf cumbersome (so is LOG and
> dataLog).
> QDebug prettify and ease printf based debug workflow. Even in WebKit
> using QDebug is pretty handy as very important core types of WebKit
> have a Qt representation (e.g. WTF::String can be converted to a
> QString). So you can do something like : String string("HELLO");
> qDebug()< efficient (to write ofc) than : fprintf(stderr, "%s\n",
> string.utf8().data());
> Still today a lot of WebKit core type have no counterpart in Qt (and
> will never have) so qDebug pretty much fail (worst case it shows a
> pointer address if possible).
>
> I'm also aware of NSLog but it unfortunately only work in objective c
> files.
>
> Then I thought about adding a dedicated debugging helper for WebKit in
> general, not Qt related so it could benefit everyone not just a given
> port.
>
> So I propose wtf() and its stream operator.
>
> Usage :
>
> wtf()<<"Hello"<<"World"<<3<<4.53322323; will output : Hello World 3 4.53322
>
> IntRect rect(10, 20, 50, 100);
> wtf()<<"Rect"<
> Vector v;
> v.append("3");
> v.append("4");
> v.append("5");
> wtf()<
> These are basic examples but we can really extend it to virtually
> anything, like higher level classes.
>
> Here is the bug with a patch attached :
>
> https://bugs.webkit.org/show_bug.cgi?id=90823
>
> wtf() is not meant to stay in a given function/patch. It is for
> developers only who wants to debug, we don't want to add overhead in
> release build and we do have the LOG macro doing a job similar.
>
> An other alternative could be to extend dataLog to support this
> streaming operator case. I'm open to this alternative too.
>
> It's a work in progress but I want to get feedback before I continue
> further (adding some stream operator overload for example) and also I
> need to make sure it builds on all ports.
>
> Do you think it is useful? Do you think it will ease/make you faster
> when debugging when you use printf? Do you want that in WebKit?
>
> I'm open to suggestion and maybe later improvements (such as showing
> the line numbers, fct names...). If people think that is useless then
> forget about it.
>
> Thanks.
>
> --
> Alexis Menard (darktears)
> Software Engineer
> openBossa @ INdT - Instituto Nokia de Tecnologia
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexis Menard]

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.

The other day I was working on the Mac port (with no real possibility
to have a debug build) and I missed a lot a great feature we have in
Qt : qDebug(). I find the usage of printf cumbersome (so is LOG and
dataLog).
QDebug prettify and ease printf based debug workflow. Even in WebKit
using QDebug is pretty handy as very important core types of WebKit
have a Qt representation (e.g. WTF::String can be converted to a
QString). So you can do something like : String string("HELLO");
qDebug()< v;
v.append("3");
v.append("4");
v.append("5");
wtf()