On 8/26/14 8:06 AM, Mike Habicher wrote:
On 14-08-26 02:00 AM, Tim Chien wrote:
On Fri, Aug 22, 2014 at 12:19 AM, Fabrice Desré<[email protected]> wrote:
On 08/21/2014 07:51 AM, Andreas Gal wrote:
console.log doesn’t have to be slow. Its only slow in Gecko. Its ridiculously
fast in Chrome. We should probably simply optimize it.
Yes, it's very ancient code. I think when I tweaked the buffering to
limit memory usage some parts had not been touched since... the CVS import!
I think it's a nice project for someone that want to get his/her hands
dirty with gecko stuff.
What's the action item here? Should I file a bug and point to someone?
Who is that someone?
We definitely need this improved so we could put more log to fulfill
the testing needs.
Somewhat related: bug 881389
<https://bugzilla.mozilla.org/show_bug.cgi?id=881389> has been around
for a while, but hasn't received a lot of attention since jlebar left..
--m.
I'm interested in following up on the "one true logger" in gecko and
have been given the go-ahead to dedicate some time to it. I'll comment
more on the bug.
To add to the discussion on gaia logging, if it were up to me I would
want something like the following:
* output should include some nice metadata (app/component, log level)
* output should go to logcat if on a B2G device
* output should go to debug console if not on a B2G device
* levels should be configurable via UI and command-line
Below is an attempt to gather together the various topics discussed so
far, please feel free to elaborate, add etc.
#1 - Gaia needs a better unified logging mechanism
Key feature required:
* One logging component usable by all Gaia applications
Possible options:
* dump() is the current defacto logger as far as I understand, I
assume it can't be toggled on and off
* DUMP() existed (or exists) and was able to be disabled, we could
build off of that
* console.log is a more standard solution but is "slow":
I'm not sure how much this matters, it depends what slow means. Does
it take a while for the log to show up, does it cost a lot of CPU
(even when not being viewed), does it actually have a lot of overhead
for the calling application?
How does application level filtering work with console.log? Are
console.log statements written to logcat as well?
#2 - Gaia needs the ability to specify log levels
Key features required:
* Need to be able to dynamically set the log levels
* Should work during application startup
Possible options:
* use mozSettings to enable logging, it has been noted that this will
not work during app startup. Maybe that's okay.
* use android properties, it seems like this would be limited to actual
devices w/ root access. I don't know if this has the same startup
issues.
#3 - Gecko needs a better unified logging mechanism
Discussion and details can be found in bug 881389
-e
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g