Re: Doxygen output?

I was just thinking about this as I probably wouldn't use the standard doxygen output much, but can definitely see the usefulness when integrated into our code indexers which I use quite often. Most useful to me would be: - @param doc when hovering over a param (in function, or when calling a

Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

I'm unaware of a bug for this decision, but https://archive.mozilla.org stopped adding tinderbox builds back on January 18th. One side effect is that the AreWeSlimYet project [1] is no longer updating and tracking memory regressions. It needs to be converted to a revision based system rather than

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

I filed bug 1344936 [1] for the archive.m.o issue and updated mozdownload's "add support for taskcluster" bug [2]. -e [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1344936 [2] https://github.com/mozilla/mozdownload/issues/365 On Mon, Mar 6, 2017 at 1:33 PM, Henrik Skupin wrot

Re: All the processes

It should be pretty easy to measure at a high level with ATSY [1], but I agree coordination on overall memory requirements before adding new processes would be useful. For more detailed breakdowns of memory usage we can depend on about:memory reports for content processes, we added support for mem

Re: All the processes

On Mon, Mar 6, 2017 at 4:27 PM, wrote: > Just about the "4 good, 8 bad" part, it seems quite arbitrary -- Wouldn't > that be hardware-dependent? > I would think users with "only" 1GB may have different needs and > expectations from users with 16+GB. > It's more about acceptable memory usage in c

Re: Heads up: archive.m.o is no longer updating tinderbox builds, AWSY is effectively dead

Can you add these details to the bug? We should probably take the conversation on the best way to fix bustage there. Given the fallout (read: memory regression tracking is gone) and, as you noted, we have the ability to continue posting taskcluster builds to archive.m.o, we should at least continu

Re: Is there a way to improve partial compilation times?

I often wonder if unified builds are making things slower for folks who use ccache (I assume one file changing would mean a rebuild for the entire unified chunk), I'm not sure if there's a solution to that but it would be interesting to see if compiling w/o ccache is actually faster at this point.

Re: windows build anti-virus exclusion list?

I filed meta bug 1326328 [1] a few months ago for tracking things we can do to improve Windows build times. It would be great to file / block existing bugs against the meta bug to track these issues. There hasn't been much traction on any of the bugs though, perhaps a good topic for the next all-ha

Re: windows build anti-virus exclusion list?

It looks like there's bug 1188823 [1] for enabling fastlink to improve link times, but that's in a bad way right now. FWIW on my ThankPad laptop I have clobber build times in the 35 - 40 minute range, so even things that seem small for a 16 core desktop are a bigger win for me. -e [1] https://bu

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

This doesn't affect the behavior of |Preferences::AddStrongObserver| which does prefix matching, correct? -e On Tue, Mar 21, 2017 at 12:07 PM, Boris Zbarsky wrote: > I have just landed a change[1] which changes > Preferences::RegisterCallback/RegisterCallbackAndCall > to do an exact, not prefi

PSA: ArenaAllocator is the new plarena.h

Hi folks- *tl;dr **plarena.h has been replaced, stop using it.* In bug 943156 [0] I recently landed [1] a templatized arena allocator, mozilla::ArenaAllocator, that we can used as a drop-in replacement for PLArenaPool. This has the benefit of getting rid of the odd "#define this thing before incl

Re: Have you run 'mach bootstrap' lately?

Didn't it somehow cause builds to fail? A gentle reminder is probably fine. TBH I'd be fine if it auto-updated but maybe I'm in the minority. On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek wrote: > On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote: > > Would it be possible to add a chec

Re: Removing Jemalloc 4

Having been involved with jemalloc 3/4/5 work as well, I agree with Mike's conclusions. -e On Mon, May 15, 2017 at 6:19 PM, Nicholas Nethercote wrote: > Just to add some context: glandium is deeply familiar with jemalloc4's > internals, having submitted numerous patches and fixes to it. And he

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

I second Kris' concern re: memory, particularly given this is in multiple processes. I'd suggest something more along the lines of a timeout; AFAICT 'memory-pressure' isn't actually fired in low-memory situations (it's still useful, and registering for it and handling it would make sense for anythi

Re: Scope of XML parser rewrite?

I was hoping to write a more thorough blog post about this proposal (I have some notes in a gist [1]), but for now I've added comments inline. The main takeaway here is that I want to do a bare-bones replacement of just the parts of expat we currently use. It needs to support DTD entities, have a s

Re: Start logging at runtime (Firefox 52)

> > The log modules are automatically set to the most common networking > > > > > modules, but you may instruct the bug reporters to change them - > just > > > > tell > > > > > them the string. > > > > > > > > &

Re: Scope of XML parser rewrite?

Thanks Henri, I think we can find a middle ground so as to avoid a ton of scope creep but leave the door open to a better iterative solution. See notes inline. -e On Wed, May 24, 2017 at 11:18 PM, Henri Sivonen wrote: > On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen > wrote: > >> Our current

Re: Improving visibility of compiler warnings

I think we disable it for local builds because we don't control what versions of tools folks use. So clang vFOO might spit out errors we don't see in clang vBAR and it would be a huge pain if those failed locally even though they'd be fine in automation. -e On Thu, May 25, 2017 at 4:07 PM, Andrew

Re: Profiling nightlies on Mac - what tools are used?

DMD [1], although it's a bit busted on mac right now [2] I'd prefer if it didn't get more busted :) -e [1] https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1371397 On Mon, Jun 19, 2017 at 3:03 PM, Chris Cooper wrote: > Hey all, >

Re: More Rust code

Interesting points. - *using breakpad* - was the problem that creating wrappers to access the c/c++ code was too tedious? Could bindgen help with that, if not it would be interesting gather some details about why it wouldn't work and file bugs against it. - *pingsender* - was someth

Re: Actually-Infallible Fallible Allocations

nsTArray has various Append methods, in this case just using the infallible AppendElements w/o out a SetCapacity call would do the job. Another option would be to use SetLength which would default initialize the new elements. If we're trying to make things fast-but-safeish in this case, the prefer

Re: Actually-Infallible Fallible Allocations

emplace although it does have AppendElement(T&&), but that wouldn't really help in this case. It's possible we could add that of course! -e On Tue, Aug 1, 2017 at 1:11 PM, Kris Maglione wrote: > On Tue, Aug 01, 2017 at 12:57:31PM -0700, Eric Rahm wrote: > >> nsTA

Is Pico Synth Synthesis used anymore?

In bug 1389598 [1] I'm removing a few remaining gonk (b2g) references. We have support for "pico speech synthesis" that implies it's gonk-only [2]. Does anyone know if we're using it elsewhere? If so I'll add a note in the configure script, if not I'll file a bug for removal. -e [1] https://bugzi

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew wrote: > > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix, > and perhaps put Auto[C]String into the mozilla namespace? > > As Nick said, renaming all the things is a job for another day :) Coincidentally I have some pending c

PSA: Use nsStringFwd.h for forward declaring strings

Hi all- In bug 1391803 I'm removing all manually forward declared string types and replacing them with a #include "nsStringFwd.h". Moving forward please use that include file if you want to forward declare a string class. In the next few week

Coding style: Argument alignment

Hi folks- Do we explicitly state a preferred alignment of arguments in multi-line function declarations (primarily in the context of C++) [1]? This question has come up in regards to using clang-format for cleaning up code [2] and it would be helpful to be able to reference a concrete example in t

Re: Coding style: Argument alignment

Okay sounds like there's agreement on a). Thanks everyone! -e On Tue, Aug 29, 2017 at 11:40 PM, Martin Thomson wrote: > On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron > wrote: > > I think I do this because (b) has the disadvantage that more code > > changes require touching additional lines,

Coding style: Placement of binary operators when breaking a long line

Hi folks- *Note: Previously we've discussed the placement of logical operators && and ||; a decision was made and I do not wish to re-litigate that here*. Currently we have a somewhat convoluted set of rules about where to place boolean operators when breaking long lines [1]. Essentially we say t

Re: Coding style: Placement of binary operators when breaking a long line

dLckkuFjBwAJ [2] https://groups.google.com/d/msg/mozilla.dev.platform/LD_KCtmmH74/ErPunKZ_BwAJ On Wed, Sep 6, 2017 at 5:18 PM, Mike Hommey wrote: > On Wed, Sep 06, 2017 at 12:30:58PM -0700, Eric Rahm wrote: > > Hi folks- > > > > *Note: Previously we've discussed the placemen

Re: Coding style: Placement of binary operators when breaking a long line

erall given the back and forth it seems like we're leaning towards going with unifying the style for splitting binary operators by leaving them on the original line. At this point I'll leave it to Ehsan, the code-style module owner, to make the final decision. -e On Wed, Sep 6, 2017 at

Re: Re-visiting the DOM tree depth limit in layout

Jan is right, increasing the stack size for all threads would cause a very large memory regression. Lets not do that ;) Selectively increasing might make sense but we'd need to keep an eye on how large of an increase we're expecting. -e On Wed, Sep 13, 2017 at 7:19 AM, Jan de Mooij wrote: > On

Re: Null[C]String() has been renamed Void[C]String()

The problem is these were never a null string, they're a voided empty string. If you do a `str.get()` it gives you a valid pointer, not nullptr. Regardless, while this was primarily a string change, we probably should have pinged a dom peer; I had forgotten the weirdness that is DOMString [1]. Argu

Re: Changes to tab min-width

I settled on 110px as well for the same reason. -e On Fri, Oct 6, 2017 at 9:05 AM, Boris Zbarsky wrote: > On 10/3/17 5:18 PM, Boris Zbarsky wrote: > >> So just to make sure I understand the change (and this is a theoretical >> point, because I haven't had a chance to try the change yet)... >> >

Re: Is realloc() between bucket sizes worthwhile with jemalloc?

On Mon, Apr 9, 2018 at 4:58 AM, Henri Sivonen wrote: > My understanding is that under some "huge" size, jemalloc returns > allocations from particularly-sized buckets. > The mozjemalloc source has a decent ascii-art table [1]. > This makes me expect that realloc() between bucket sizes is going

Re: Coding style: brace initialization syntax

Reading back through I think the consensus, at least for initializer lists was: 1. Prefer parenthesis, ie: , mBool(true) 2. If using braces, maintain the same spacing you would use with parenthesis, ie: , mStructWithoutCtor{42} 1. was pragmatic as this is what we already do, 2. was

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

This was added in bug 1255843 [1]. I don't feel to strongly about keeping it around, I believe mconley and mrbkap came up with the idea of adding it. It's *much* more lightweight than about:memory and provides automatic updates which is nice for monitoring without external tools. What performance

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

sense. -e [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1475301 On Thu, Jul 12, 2018 at 12:41 AM, Florian Quèze wrote: > On Thu, Jul 12, 2018 at 1:18 AM, Eric Rahm wrote: > > > What performance issues are you seeing? RSS and USS should be relatively > > lightweight and

Re: PSA: Major preference service architecture changes inbound

We *could* special case prefs with an appropriate data structure that works in a thread-safe nature; as far as RWLock's go, we do have one in tree [1]. This has gone off the rails a bit from Kris' original announcement, which I'll reiterate: Watch out for prefs related bustage. Jeff, would you min

The War on Warnings Redux

TL;DR - We have reduced the amount of runtime warnings during testing by 90%. As of today we are down to 66K warnings during linux64 debug testing; this is down from >600K back in June. There are bugs on file for most of the remaining top offenders blocking tracking bug 765224 [1]. It's time to

Re: Removing "nsDebug" logger

On Monday, October 19, 2015 at 11:39:20 AM UTC-7, eric...@gmail.com wrote: > I am removing the "nsDebug" logger [1] in bug 1215629 [2]. It was added some > 12 years ago and the purpose has seemingly been lost over the years. > > If you happen to rely on this being available please let us know. If

LazyLogModule, a thread-safe replacement for declaring a PRLogModuleInfo

Hi All- I recently landed a lazily-loaded log module class, LazyLogModule [1], suitable for declaring static references to log modules in a thread-safe way. Currently this class is opt-in and PRLogModuleInfo can still be used w/ MOZ_LOG. But be forewarned, as we move forward to a glorious wor

MemShrink: an ongoing initiative to reduce memory consumption

Hi folks- The MemShrink project [1] has been around for several years. You may have seen the [MemShrink] tag added to bugs and then later on given a priority of P1, P2, or P3. This was the product of weekly (and then bi-weekly) video meetings held to triage these unprioritized bugs and discuss all

Dynamic Logging

Hi Folks- With bug 1233881 we landed the ability turn on logging via prefs. Lets say you have a log module "Foo", if you add a "logging.Foo" pref and set it to "Debug" you will now see all output from the Foo log module that is of Debug and h

Re: Dynamic Logging

n Fri, Jan 8, 2016 at 5:38 PM, Patrick McManus > wrote: > >> On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm wrote: >> >> > Why is this so cool? Well now you don't need to restart your browser to >> > enable logging [1]. You also don't have to s

Re: Dynamic Logging

Eric, is there an option to make the NSPR log output go directly into the > regular test output? > > On Fri, Jan 8, 2016 at 5:32 PM, Eric Rahm wrote: > >> Hi Folks- >> >> With bug 1233881 <https://bugzilla.mozilla.org/show_bug.cgi?id=1233881> >> we >>

Re: any concerns with dropping the talos test v8 and using AWFY Octane instead?

On Monday, January 11, 2016 at 8:42:11 AM UTC-8, William Lachance wrote: > It seems like another alternative might be to run Octane in Talos, > instead of v8_7. > > It seems like Talos has two advantages over AWFY (correct me if I'm wrong): > > 1. Easy for developers to schedule jobs via try (ma

Re: Dynamic Logging

On Monday, January 25, 2016 at 11:06:15 AM UTC-8, Honza Bambas wrote: > Nice idea although unfortunately incomplete. On Windows this has no > effect at all. We cannot use it for common users. When you set the > pref, it logs only to the debug output that can be captured only with > visual stu

Re: Proposal to stop revving UUIDs when changing XPIDL interfaces

On Thursday, January 28, 2016 at 2:56:19 PM UTC-8, Ehsan Akhgari wrote: > 10 days and no objections. This is now the new rule! Please stop updating > UUIDs when changing XPIDL interfaces. > > On Fri, Jan 15, 2016 at 10:58 AM, Ehsan Akhgari > wrote: > > > Historically we have enforced updating

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

Really interesting project, is this currently Windows only? It would be great if we could get memory usage as well. Also just to clarify, this is WPT that runs on webpagetest.org with code from https://github.com/WPO-Foundation/webpagetest? -e ___ dev

Re: Memory Usage on Perfherder & Memory Reduction

On Tuesday, February 9, 2016 at 2:25:42 PM UTC-8, Mark Finkle wrote: > Hi All, > > Recently Geoff Brown landed an AWSY-like system [1] for tracking memory > usage on Perfherder. This is awesome. It's one of my pinned tabs. > > I was happy to see two recent "drops" in memory usage: > > 1. A ~3% d

Re: Memory Usage on Perfherder & Memory Reduction

On Wednesday, February 10, 2016 at 7:46:11 AM UTC-8, William Lachance wrote: > Incidentally, the automatic regression detection dashboard has been > coming together recently with Perfherder, which should let you track > such things as this much more easily (as well as providing a convenient > in

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On Thursday, February 11, 2016 at 5:03:05 PM UTC-8, Patrick Meenan wrote: > "Memory Usage" is complicated. Specially when you try to compare > different architectures. Sure, but this is all Windows for desktop at least. > Working set? Virtual memory? Accounting for shared pages, etc. Work

Re: Presto: Comparing Firefox performance with other browsers (and e10s with non-e10s)

On Friday, February 12, 2016 at 9:41:02 AM UTC-8, Patrick Meenan wrote: > > > For example with Firefox I would be interested in the RSS of the parent > > > process (firefox.exe) and the USS of the child processes > > > (plugin-container.exe). For Chrome it would be more along the lines of > > >

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

On Thursday, March 24, 2016 at 10:10:30 AM UTC-7, Justin Dolske wrote: > On 3/24/16 9:54 AM, Ralph Giles wrote: > > On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote: > > > >> tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't > >> worry about backward compatibility tho, wh

Re: Updating 32-bit Windows users to 64-bit Windows builds?

Last time I checked we saw something like a 35% increase in overhead on AWSY going from 32-bit to 64-bit Firefox on 64-bit Windows, so yes there is a significant impact. On the other hand you no-longer run into the OOM-because-of-address-space-exhaustion and OOM-because-we-can't-find-a-one-meg-chu

Re: Updating 32-bit Windows users to 64-bit Windows builds?

I filed bug 1274659 [1] to track this proposal and attempted to summarize the issues brought up. Please add any technical comments and blocking bugs there. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1274659 -e On Fri, May 20, 2016 at 5:56 AM, Tobias B. Besemer < tobias.bese...@googlemail.c

Re: All about crashes

Thanks for putting this together! It would be nice to see some consolidated details on how to investigate crashes, ie loading minidumps in Visual Studio, interpreting results, figuring out when VS is lying to you and what disassembly to look at. I think there's some great institutional knowledge h

How do we measure active users on a given architecture?

I've seen statements such as "0.04% Firefox users don't have SSE"*. What I'd like to know is if when we make these measurements we also ascertain whether or not those users are on the most recent release. There's often pushback, which I think is certainly reasonable, related to abandoning users or

Re: MXR permanently offline, please transition to DXR

While mxr being retired is unfortunate, at this point would it not make more sense to just file bugs against dxr for features you would like to be added? It's not clear to me after this lengthy discussion if anything actionable has been accomplished. -e On Fri, Jul 8, 2016 at 7:57 PM, Boris Zbar

Re: MXR permanently offline, please transition to DXR

On Monday, July 11, 2016 at 6:45:29 AM UTC-7, Matthew N. wrote: > On Fri, Jul 8, 2016 at 12:27 PM, Lawrence Mandel > wrote: > > > We do in the case of 3rd party software referencing files from MXR (and > > I'm told there is a lot of this). > > > > ​That's an existing problem which is orthogonal

Re: Why I don't like DXR

It's sounds like some sort of mxr => dxr transition wiki entry would be useful. Perhaps you can start by collecting the feedback you received here? -e On Wed, Sep 28, 2016 at 8:52 AM, Honza Bambas wrote: > Thanks everyone for answers. This is helpful, but why don't I see any > help like this r

Re: Some recent crash-stats improvements

Is there a reason you need permissions for the memory report? Don't we anonymize it? -e On Mon, Oct 10, 2016 at 8:34 AM, Benjamin Smedberg wrote: > Yes, downloading raw minidumps and memory reports requires the PII > permission in crash-stats. This can be obtained by Mozilla employees with > th

Re: Please do not add any new CppUnitTests/GeckoCppUnitTests

Would that be a fourth copy in the tree at this point? -e On Wed, Nov 9, 2016 at 4:17 PM, Mike Hommey wrote: > On Thu, Nov 10, 2016 at 11:04:05AM +1100, Nicholas Nethercote wrote: > > On Thu, Nov 10, 2016 at 10:00 AM, Mike Hommey wrote: > > > > > > > > CppUnitTests are fine to keep. > > > > >

nsISupportsArray and friends are deprecated, slated for removal in 55

nsISupportsArray, nsICollection, nsIEnumerator, nsIBidirectionalEnumerator have all been marked as deprecated in their IDL declarations as of Firefox 52 (currently dev edition). This is not a new thing -- they've been semi-deprecated for 12 years [1] -- we just never fully removed them. Over the

Re: Introducing mozilla::Result for better error handling

I like the idea of pulling in some Rusty concepts, but I'm concerned about adding yet another early return macro -- absolutely no arguments on the new type, just the |MOZ_TRY| macro. In practice these have lead to security issues (UAF, etc) and memory leaks in the C++ world (I'm looking at you NS_E

Re: Introducing mozilla::Result for better error handling

ngs I look at I much prefer an explicit return. It makes both the writer and reviewer think about the consequences. If MOZ_TRY just release asserted on error I wouldn't have an issue. On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione wrote: > On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric

Re: Several leak failures have slipped passed continuous integration

Also note this has happened before. mccr8 was looking into similar leak-checking-is-totally-busted-but-nobody-noticed issues a few years ago in https://bugzilla.mozilla.org/show_bug.cgi?id=1045316 Glad to hear you're looking into end-to-end tests! -e On Thu, Dec 29, 2016 at 8:37 AM, Andrew Halbe

Frame Pointer Omission Unconditionally Disabled on Win32

As of landing bug 1322735 [1], we now unconditionally disable frame pointer omission (FPO) on all win32 builds. FPO was already disabled on nightly/aurora builds as a side-effect of having profiling enabled, but will now be disabled in beta (and release eventually) after the next uplift. Please no

Re: Oculus VR support & somehwat-non-free code in the tree

So who actually needs to talk to Oculus? I can try to reach out some folks I used to work with who are there now and see if they're interested in making license modifications. -e On 4/16/14, 7:01 AM, Gervase Markham wrote: On 14/04/14 23:41, Vladimir Vukicevic wrote: I'd like to get this che

Enabling NSPR logging in release builds

Hi all- In bug 806819 we're planning on landing a change that allows us to turn on NSPR logging in release builds [1]. To be clear, by default all logging output is disabled, this will just allow you to turn on logging via the same mechanisms [2] that have been available to debug builds and m

Re: Enabling NSPR logging in release builds

On 10/3/14 1:12 PM, Eric Rahm wrote: Hi all- In bug 806819 we're planning on landing a change that allows us to turn on NSPR logging in release builds [1]. To be clear, by default all logging output is disabled, this will just allow you to turn on logging via the same mechanisms [2] that

PSA: JavaScript, const, and you

Just a heads up, a few of us have run into problems with extensions breaking in nightly. The problem is probably not restricted to extensions. The scoping rules for const in JavaScript have changed to conform w/ the ES6 spec [1]. My understanding is that a const variable is now restricted to t

PSA: PR_LOGGING is dead, please stop using it

Way back yonder in September we enabled logging by default on all builds. The world did not end. The |--disable-logging| flag remained which in theory, does in fact disable logging but none of our default builds use it, and unsurprisingly we occasionally started breaking custom builds that attem

Meet "mozilla/Logging.h"

I just landed a patch [1] that replaces all instances of "prlog.h" in gecko code with "mozilla/Logging.h". Currently it's not terribly interesting, it just includes "prlog.h", but in the future we're going to start swapping out functionality. To support this effort please use "mozilla/Logging.h

Replacing PR_LOG levels

As part of the effort to improve logging in gecko we'd like to introduce a new set of unified log levels. Currently we use NSPR logging which defines the following log levels: typedef enum PRLogModuleLevel { PR_LOG_NONE = 0,/* nothing */ PR_LOG_ALWAYS = 1, /*

Re: Replacing PR_LOG levels

> +1 - I actually wasn't aware of this debug+1 mechanism and now that I am I > would like to make use of it. Please, please, please don't do this until we work this out (once we switch to enum class this will not be an option). > requiring special builds is much much less satisfying, especiall

Re: Replacing PR_LOG levels

Thank you for the feedback, you make some good points. On Friday, May 22, 2015 at 1:31:14 AM UTC-7, masayuki nakano wrote: > Hi, > > I still want a same level as PR_LOG_ALWAYS. Would switching this to the new level 'Info' suffice? The main difference is that by enabling the Info level you will

Re: Replacing PR_LOG levels

Thanks Adam, these are good points. On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote: > On 5/22/15 15:51, Eric Rahm wrote: > > I agree, we shouldn't make it harder to turn on logging. The easy solution > > is just to add a separate logger for verbose messages

Re: Replacing PR_LOG levels

Thanks Randell, these are good points. I'll address a few of your comments that have not already been covered in the rest of the conversation. > 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-netw

Re: Replacing PR_LOG levels

On Friday, May 22, 2015 at 12:06:05 PM UTC-7, David Rajchenbach-Teller wrote: > On 22/05/15 04:06, Eric Rahm wrote: > > After a rather thorough examination of usages of each I have come up with a > > set that I believe would fit our needs: > > > > enum class Lo

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, Deb

PSA: Goodbye PR_LOG, hello MOZ_LOG

tl;dr - PR_LOG* are deprecated. Use MOZ_LOG* instead. As part of the effort to improving logging in gecko we've started a transition to using a MOZ prefix and a new set of log levels [1]. I've just landed these changes on mozilla-inbound, if they stick this means you should no longer use PR_LOG

The War on Warnings

We emit a *lot* of runtime warnings when running debug tests. I inadvertently triggered a max log size failure during a landing this week which encouraged me to take a look at what all is being logged, and what I found was a ton of warnings (sometimes accompanied by stack traces). Most of these

Re: PSA: Goodbye PR_LOG, hello MOZ_LOG

This has landed; PR_LOG(_TEST) is now verboten. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: The War on Warnings

On Thursday, June 4, 2015 at 1:48:30 PM UTC-7, Luke Wagner wrote: > In addition to judging noisiness by volume over a whole test run, can we > also include any warning that happens on normal browser startup, new tab, > and other vanilla browser operations? This has always annoyed me. Yes, this bo

Re: The War on Warnings

On Thursday, June 4, 2015 at 11:14:59 AM UTC-7, Martin Thomson wrote: > On Jun 4, 2015 10:27 AM, "Daniel Holbert" wrote: > > Also: in layout, there are various warnings related to coordinate > > wraparound/overflow, where we're basically throwing up our hands and > > warning that broken layout is

Re: The War on Warnings

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 develop

Re: The War on Warnings

An update on progress. I've landed bugs which should clean up ~180,000 warnings. I have bugs pending for another ~26,000. The latest top 40: *Note: I improved my normalization a bit so it might look a bit different 18012 [N] WARNING: Subdocument container has no frame: file layout/base/nsD

Re: The War on Warnings

On Wednesday, June 17, 2015 at 7:40:14 AM UTC-7, Milan Sreckovic wrote: > Do we have a all encompassing meta bug to collect all of the bugs that fix > the warnings? > -- > - Milan > Bug 765224 ___ dev-platform mailing list dev-platform@lists.mozilla.or

Re: The War on Warnings

On Wednesday, June 17, 2015 at 6:49:00 AM UTC-7, kgu...@mozilla.com wrote: > > 4606 [N] WARNING: No widget found in TabParent::UpdateDimensions: file > > dom/ipc/TabParent.cpp, line 974 > > Do you know if this one occurs on b2g or also on other platforms? I added > this warning recently in

Re: Revisiting modelines in source files

On Thursday, June 18, 2015 at 7:28:44 AM UTC-7, kgu...@mozilla.com wrote: > 1) Comments that exceed the 80-char limit get wrapped blindly, rather than > being rewrapped properly. This results in comment blocks that look like this: > > // This is a comment that was previously just over the eighty

Re: Revisiting modelines in source files

> If someone commits to producing a suitable clang-format binary/config, I'll > sign up for creating all the tooling. It looks like Birunthan stated he'd be willing to work on the clang-format side (I'm also happy to help out) if we are committed to integrating it into our wrorkflow. I found an

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On Tuesday, July 7, 2015 at 3:30:59 PM UTC-7, Birunthan Mohanathas wrote: > On 7 July 2015 at 15:02, Mike Hommey wrote: > > On Tue, Jul 07, 2015 at 11:52:12PM +0300, smaug wrote: > >> until the tools (and poiru) are run and make the code follow Mozilla > >> coding style. > > > > Assuming you're t

Re: mozilla::Hash{Map,Set}

On Thu, Aug 16, 2018 at 6:07 AM, Alex Gaynor wrote: > Would it make sense to consider giving nsTHashtable and PLDHashTable > different names? Right now the names suggest that we have 3 general purpose > hash tables, but it might be easier if the names better suggested their > purpose, e.g. PLDHas

Fission MemShrink Newsletter #2

latforms (Bug 1475899 <https://bugzilla.mozilla.org/show_bug.cgi?id=1475899>, Bug 1476405 <https://bugzilla.mozilla.org/show_bug.cgi?id=1476405>, Bug 1477512) <https://bugzilla.mozilla.org/show_bug.cgi?id=1477512> - Kris reduced memory usage on Linux by *~3MB* (that'

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

Just a heads up, it looks like this landed sometime last week for platforms that support PGO. This has an unintended consequence of making it look like perf data for integration branches went awol, but in fact you need to switch from looking at "opt" data to "pgo" data. Unfortunately since we didn

Re: Structured bindings and minimum GCC & clang versions

We are actively working on this. Unfortunately, as expected, its never as simple as we'd like. Updating the minimum gcc version ( https://bugzilla.mozilla.org/show_bug.cgi?id=1536848) is blocked on getting our hazard builds updated, updating to c++17 has some of it's own quirks. We're currently at

Re: Must we rebuild all our rust code constantly?

You can use |mach clobber --full| to remove the incremental cache. It might be worth filing a bug for the large size, my best guess is that we're keeping around items from old compiler versions. It's possible we could do a full clobber of the IC when we detect a new compiler version, but that might

Re: Must we rebuild all our rust code constantly?

A fix for this (https://bugzilla.mozilla.org/show_bug.cgi?id=1576030) should be on m-c shortly, no need to tweak mozconfigs. -e On Fri, Aug 23, 2019 at 9:45 AM Nicholas Alexander wrote: > On Fri, Aug 23, 2019 at 2:11 AM ishikawa wrote: > > > On 2019/08/23 11:00, Mike Hommey wrote: > > > > > >

Re: Intent to Implement and Ship: Make MOZ_QUIET the default, require opt-in for DOMWINDOW/DOCSHELL logs

This sounds great. Is there a reason we can't just use MOZ_LOG for the docshell/domwindow logging? -e On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote: > In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to > remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by defa

  1   2   >