Re: Replacing PR_LOG levels
As I said earlier, I agree with Jesup. If people insist on not adding above debug, at least please allow individual modules to use a number that is DEBUG+1 on their own this is relevant for a lot of the media stuff which actually has its own logging and just shims to PR_LOG anyway). -Ekr On Wed, May 27, 2015 at 12:22 AM, Randell Jesup wrote: > >On Sat, May 23, 2015 at 4:46 AM, Randell Jesup > wrote: > >> This is used extensively in WebRTC and related media bits to enable > >> *huge* amounts of debugs (like every-frame debugs for audio or video or > >> per-network-packet debugs, which will swamp a system normally), and > since > >> people are used to enabling "debug" on random modules (or all:5), having > >> verbose debugs in the "normal" :5 setting will cause pain. > > > >Can this be controlled some other way? Via a #define? Via another > >environment variable? > > Definitely *not* a #define. That makes it close-to-useless. > > >I ask because in discussions with Eric I've been encouraging him to > >reduce the number of logging levels as much as possible. It would be > >sad to have to complicate the general mechanism because one module > >does things differently to the rest of the system. > > My point (as repeated here in other posts) is that you're reducing > complexity (in number of log levels) by adding complexity elsewhere (and > more total complexity, IMHO). I'd consider your suggestion above an > example of "complicating the general mechanism", but doing it indirectly > so it can *appear* to be simple (but isn't really). > > This isn't a single module using values above DEBUG - this is *all* over > the media modules in different debug tags. Audio, MediaDecoder, > MediaStreamGraph, MediaManager, WebM, etc. Also, the current patch > misses a number of uses like MediaEngine: > > #define LOG(msg) PR_LOG(GetMediaManagerLog(), PR_LOG_DEBUG, msg) > #define LOGFRAME(msg) PR_LOG(GetMediaManagerLog(), 6, msg) > > (yes, this uses 6, such that the common habit of blah:5 logging doesn't > turn on the spam - you have to *want* it) > > I like fixing up logging! I just think shoehorning a level *under* > DEBUG confuses things, while adding a level *above* DEBUG would let up > standardize/regularize current practice (and avoid the (temporary) > "which version am I using" problem.) > > /me stops arguing having said his piece > > -- > Randell Jesup, Mozilla Corp > remove "news" for personal email > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: AdBlock Plus as a ServiceWorker?
On Thursday, May 21, 2015 at 4:47:42 PM UTC+2, David Rajchenbach-Teller wrote: > Now, if ServiceWorker is not the right API, what would be? The webRequest-like API from bug 1157561 sounds pretty good, especially if it provides access to headers (Tom Schuster says that it does). However, we also need to get back from the request to the element that triggered it (this part can happen in a frame script). For some elements we simply need to hide them, for others we need to associate the request data with them so that it can be looked up later (and won't leak if the document is frequently adding and removing nodes). I'm not sure whether any general-purpose API can give us that - I suspect that a better strategy would be implementing both the chrome and the content parts of this ourselves. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Misplaced xpcomglue.lib
Hi, We are using Firefox SDKS for our FF extension. The libs generated after compiling Firefox 39 beta 1 source (using start-shell-msvc2013) did not contain few libs (xpcomglue.lib,xpcomglue_s.lib,...) in the "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\dist\lib" folder, instead it was found at "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\xpcom\glue\standalone". Can anyone kindly let us know, 1) If there is any change in FF 39 sdk build binaries 2) We need to pass any parameters during compilation to group the libs under one folder. Thanks & Regards Meenakshi ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing PR_LOG levels
After some back and forth in this thread, IRC, and in bugzilla I've been
convinced that adding a Verbose level will make this transition smoother.
The new enum will look something like:
enum class LogLevel {
Disabled = 0, // Logging is disabled for this module
Error,
Warning,
Info,
Debug,
Verbose
};
This also has the benefit of using the same numeric values for Debug
(PR_LOG_DEBUG = 4) and Verbose (PR_LOG_DEBUG + 1 = 5) as we currently do. So
for example setting "MediaManager:5" will output the same levels both before
and after this change.
Thanks for all the feedback!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Misplaced xpcomglue.lib
On Wed, May 27, 2015 at 11:38:30AM -0700, Meenakshi Shankar wrote: > Hi, > > We are using Firefox SDKS for our FF extension. The libs generated > after compiling Firefox 39 beta 1 source (using start-shell-msvc2013) > did not contain few libs (xpcomglue.lib,xpcomglue_s.lib,...) in the > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\dist\lib" folder, > instead it was found at > "\mozilla-build\mozilla-beta\obj-i686-pc-mingw32\xpcom\glue\standalone". > > Can anyone kindly let us know, > > 1) If there is any change in FF 39 sdk build binaries Yes and no. There were changes that make libraries not installed to dist/lib anymore, but those never were the sdk libraries. The sdk libraries are in dist/sdk/lib. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
