NSPR logging doesn't always cut it. And XPCOM logging is rather dead by now. dmose and I have been chatting, so here is a bug to store the ideas, so they don't get lost at all. Dan wanted to have a logging facility which would allow to get messages to both the log, and to the console service. It should be easier to use than the console service alone. It would be nice to use the log from js, so this is a higher level than xpcom or nspr (xp apps). How about a service for each log, with a contract IDs like @mozilla/log;1?name=my-foo-log The idl should have methods for messages and debug logging, so that debug blurb can be optimized out, and messages still make it to the console service. The logs should support a level of detail, too. And having a contract ID for each log would even allow a UI for setting the log parameters, like output, level of detail and such. Even dynamically. The signature should be the same for both debug and non debug builds, but non-debug builds should get a (at least almost) zero cost implementation. So much off my head Axel

Other features I'd like to see: * It would be nice to be able to put this stuff to stderr if desired by setting one more env vars. * It should have log levels like PR_Log and friends have, but with much more granularity (ie many more than 5 levels). Or maybe just adding sublevels to the NSPR stuff would be sufficient. Perhaps this can be built based on the existing (but not used much) xpcom logging stuff that warren wrote, or perhaps on NSPR logging. Can anyone that I've just CCed comment on what the last known state of the nsLogging stuff is? I seem to remember dbaron ultimately backing warren out, but my memory may be fuzzy.

Let's get warren to do it! Oh, wait... Cc'ing neo-warren. ;-) /be

Ugh. This was _such_ a disaster last time. Please don't invent an all-singing-all-dancing logging service again. I'll throw up. And don't try to #define away printf(). So... - What's wrong with |dump()| from JS? - NSPR logging sends stuff to stderr if you don't specify the NSPR_LOG_FILE environment variable. - You can hack the NSPR log level to mean whatever you want. If you want it to be bit-flags, let it be bit-flags. See nsHTMLContentSink.cpp for an example of this.

for javascript dump() in pac we're suggesting using the JavaScript console instead of the text console, if it's a success it might be suggested for javascript dump() in general

FWIW, Warren's stuff is still in the tree to some extent (it's used in one place, so bug 58966 still clutters up the leak stats). I wanted to back it out (I can't find the bug right now), but someone (can't remember who) said he wanted to clean up Warren's stuff and get it used. (Warren apparently had a branch with it significantly cleaned up ready to land the day he left Netscape.)

warren's branch was logging_102900_branch, and it was Darin who seemed interested in reviving warren's nslog.h the last time this was discussed. (That's actually from an email thread I have archived, not a bug.)

I'm actually far less keen on warren's logging branch now then i used to be ;-) I don't see any _real_ problems with NSPR logging, and the effort involved in changing things probably isn't worth the time IMO. So, I have no objections if you want to remove any last vestiges of warren's logging code.

Hrm. Just removing warrens logging is not the right thing. There are obviously a few places in the code that use that logging (or intend to), so they should at least get a chance to move to some other stuff, before you just prune the places they wanted to log. Axel

As far as I know, there is only one PRINTF in the tree, and that's the one removed above in nsAtomService.cpp. The above patch does compile -- there were a bunch of other places that declared logs but didn't use them.

Pavlov and I have both recently run into the problem that one can't use pr logging in a header that's included in nsXPComInit.cpp due to nslog.h. Anybody want to review attachment 45614 [details] [diff] [review]?

Comment on attachment 45614 [details] [diff] [review] quick attempt at patch to remove Warren's logging stuff from the build [Checkin: Comment 14] r=pavlov

Comment on attachment 45614 [details] [diff] [review] quick attempt at patch to remove Warren's logging stuff from the build [Checkin: Comment 14] sr=darin (looks good)

OK, it's out now, although the files aren't removed yet (I filed bug 107510 to give people a chance to object, although I hope nobody does). However, after I checked in I found out that some of that addressbook code (which I now know is only built on Windows) really was using the XPCOM logging stuff, and I had to convert it to NSPR logging. It wasn't as bad a landing as when it was landed initially, though. :-(

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

Is anyone still interested in this?

I am, but how about just providing a XPCOM interface to NSPR logging? Do we really need to unify console logging and "NSPR-style" logging? NSPR logging is pretty nice, and with support from preprocessor.pl, we could probably come up with a similarly nice solution for logging from JS that could be conditionally compiled out.

i have that, it's stuck waiting for wtc to accept patches to nspr. pushing is welcome.

darin: I don't think we want something that conditionally gets rid of this logging at build time, since it'll often be useful to sysadmins and extension authors trying to use regular builds. Better might be a pref to make spidermonkey ignore this when it compiles JS, perhaps. Changing the pref would have to blow away any fastload files, I assume.

Our JS files pass through preprocessor.pl, so it is incredibly trivial to implement conditionally included code in the JS files. There are times when you want increased amounts of debugging in a debug build (maybe inside some loop body) that would be cost prohibitive in a release build. Giving component authors the ability to optionally define FORCE_PR_LOG (or some equivalent) in Makefile.in should be sufficient to allow logging to remain in release builds. This is what we do for C++ logging, and it works well there. Why not go with something similar for JS?

Assigning bugs that I'm not actively working on back to nobody; use SearchForThis as a search term if you want to delete all related bugmail at once.

The latest attempts at improved logging are being tracked in bug 881389.