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

[Brady Eidson]

On Jul 19, 2012, at 3:09 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> On Jul 19, 2012, at 2:58 PM, Balazs Kelemen <kbalazs at webkit.org> 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