Re: Silencing debug spew
On 10/01/2013 12:25 AM, Karl Tomlinson wrote: Bill McCloskey writes: # Silence ++THIS and --THAT export MOZ_QUIET=1 # Silence NS_WARNING export MOZ_IGNORE_WARNINGS=1 then you won't get any more messages about DOM windows or docshell creation/destruction or about NS_WARNINGs firing. Thanks very much, Bill. I think I'll also find this useful. Can we all agree to only use NS_WARNING for things that are unlikely to happen? This includes NS_ENSURE_SUCCESS and friends. I thought there was almost consensus on avoiding NS_ENSURE_* because of the way jump statements are hidden, but I've still seen some advocating. No. The NS_ENSURE_* macros are incredibly useful when trying to figure out where things went wrong. To witness, just yesterday, in #content: > * khuey points out that NS_ENSURE_ spew is awsome cause > otherwise he'd have no clue where to start http://logbot.glob.com.au/?c=mozilla%23content&s=30+Sep+2013&e=30+Sep+2013#c137495 HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Silencing debug spew
If MOZ_IGNORE_WARNINGS=1 becomes common, I worry that warning spew will pile up even more than it does now, making it impossible to use warnings as part of the development process. Incorrect warnings should be removed. Especially noisy warnings, such as those that happen during startup and showdown, should be disabled until the underlying bugs are fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=fx-noise ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Silencing debug spew
Bill McCloskey writes: > # Silence ++THIS and --THAT > export MOZ_QUIET=1 > > # Silence NS_WARNING > export MOZ_IGNORE_WARNINGS=1 > > then you won't get any more messages about DOM windows or > docshell creation/destruction or about NS_WARNINGs firing. Thanks very much, Bill. I think I'll also find this useful. Can we all agree to only use NS_WARNING for things that are unlikely to happen? This includes NS_ENSURE_SUCCESS and friends. I thought there was almost consensus on avoiding NS_ENSURE_* because of the way jump statements are hidden, but I've still seen some advocating. Can we at least agree not to use NS_ENSURE_SUCCESS when failure is reasonably likely in normal use? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Silencing debug spew
Hi everyone, If you run debug builds, you're probably aware of all the gunk that gets dumped out to the console for even simple things like starting up a browser. There's probably a rationale for all of WARNING: No disk space watcher component available!: file /home/billm/mozilla/in1/dom/indexedDB/IndexedDatabaseManager.cpp, line 207 these messages and warnings, and we probably do fix some of them occasionally. But at this point, there are so many that it's a ++DOMWINDOW == 4 (0x7effb67f08b8) [serial = 4] [outer = 0x7effb67ef8b8] ++DOMWINDOW == 5 (0x7effb64f1cb8) [serial = 5] [outer = 0x7effbfbe70b8] little overwhelming. What's really bothersome is that my own WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv) && subjPrincipal) failed: file /home/billm/mozilla/in1/docshell/base/nsDocShell.cpp, line 8442 debugging printfs are hard to find in all the unrelated spew. I just landed bug 921293, which makes it possible to silence some of these messages with an environment variable. If you just add the following to your .bashrc or whatever: # Silence ++THIS and --THAT export MOZ_QUIET=1 # Silence NS_WARNING export MOZ_IGNORE_WARNINGS=1 then you won't get any more messages about DOM windows or docshell creation/destruction or about NS_WARNINGs firing. So far it's had a much more positive effect on my debugging experience than I would have expected. -Bill ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
