Hi,
On 2015/06/06 2:39, Eric Rahm wrote:
On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote:
After coping with voluminous messages in C-C TB |make mozmill| test
suite log [much smaller volume than full FF logs],
I think we should have NS_INFORMATION() macro that
prints out an information for someone who is developing code and
just wants to know how the code is doing.
I suppose we could add yet another macro, but really this sounds like a use
case for:
MOZ_LOG(myModule, LogLevel::Info, "Dev message!");
which could then be enabled with something like:
|NSPR_MODULES="myModule:3" ./mach run|
Thank you for the tips.
(I was referring to *NS*_INFORMATION() since
when I tried to use MOZ_ABORT() or something in some test codes,
I could not compile and link them and learned some MOZ_* macros and NS_*
macros don't mix very well during linking(?).)
Anyway, I am a little confused since MOZ_LOG() is very new.
What is the first argument to the following code?
|MOZ_LOG(myModule, LogLevel::Info, "Dev message!");|
Looking at how PR_LOG() was called with PRLogModuleInfo,
typedef struct PRLogModuleInfo {
const char *name;
PRLogModuleLevel level;
struct PRLogModuleInfo *next;
} PRLogModuleInfo;
Is |myModule| it declared as
PRLogModuleInfo myModule;
is passed to as the first argument of MOZ_LOG().?
But it sounds as if we should stay away from PRLog* data structure.
Or is it simply anything (and stringified internally) that
will be specified in environmental variable later?
It might be useful to eventually add a |MOZ_LOG_IF| to make things easier.
Yes, for readability, we need some creative macros.
1576 [10262] WARNING: '!mMainThread', file
/REF-COMM-CENTRAL/comm-central/mozilla/xpcom/threads/nsThreadManager.cpp, line
We're working on this in bug 1171716, it's related to cycle collection on
shutdown.
Anyway, I agree that we should simply try to attack the top entries
first to figure out whether they are indication of genuine issues/bugs, etc.
Yes! Please file blocking bugs for the top c-c entries against bug 765224.
I will try to do so.
Eventually we could cut down the number to manageable size.
(At near the beginning of 2013, the list became only about a dozen items
long, but started to grow again. In a sense it reflects the desire of
code authors to catch strange conditions, but I agree we must keep on
looking at the logs and do something about the top offenders in the log
list.)
It might be nice to create a very simple start/stop test that just makes sure
there are no warnings so that we can avoid regressing that in the future.
Sounds a sensible idea.
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
