On Tue, Jan 7, 2014 at 12:31 PM, Benjamin Smedberg
wrote:
>
> I am the owner of at least the C/C++ portions of the style guide; I propose
> to wait and see whether the C++ reformatting tools are of sufficient quality
> that we can use them directly, to avoid hand-reformatting, and make a final
> d
On Thu, Jan 30, 2014 at 11:42 AM, Anthony Jones wrote:
>>
>> This tool is not going to be very helpful in a lot of modules until we
>> do style-rewriting. I'm not about to start taking piecemeal
>> 2-space-indented patches in XPConnect.
>
> When I said "style rewriting" I was referring to changing
On Sun, Feb 2, 2014 at 5:38 PM, Bobby Holley wrote:
>
> XPConnect currently follows JS-style, which is the most divergent style in
> the tree (in particular, 4-space indents mean that a restyle is going to
> rewrite every line). As such, I don't think it's a great place to prototype
> clang-format
On Mon, Feb 3, 2014 at 2:32 PM, Taras Glek wrote:
> A few people noticed that we do not have a nice, searchable knowledge base
> for Gecko tech. We have places to ask questions such as various newsgroups,
> irc and places to document things like the wikis. It is hard to search
> through all of tha
On Fri, Jan 31, 2014 at 6:08 AM, Benjamin Smedberg
wrote:
>
> I'm not sure that we need to fix all the problems in order to be useful. I'd
> certainly automatically-generated whole-file patches which just do
> re-indenting and some simple brace fixup.
Attachment https://bugzilla.mozilla.org/attac
On Wed, Feb 12, 2014 at 7:14 PM, Ehsan Akhgari wrote:
> On 2/10/2014, 4:32 AM, Nicholas Nethercote wrote:
>>
>> Can we just allow hand-written fixes and move forward, please?
>
> Absolutely. I don't see any reason to enforce the usage of a tool as a
> criteria fo
On Thu, Feb 13, 2014 at 1:39 PM, Botond Ballo wrote:
>>
>> landing - For comments that include commit URLs
>> summary - For comments that summarize a previously lengthy discussion
>> workaround - For comments that include a workaround for an unfixed bug
>> spam - For comments that don't provide te
On Thu, Feb 20, 2014 at 2:41 AM, Neil wrote:
>
> Also I tried looking up the callers of a constexpr function and got no
> results. Is this because the compiler optimised them all away?
"callers:" searches are entirely unreliable in my experience. I filed
https://bugzilla.mozilla.org/show_bug.cgi?
Greetings,
We now live in a memory-constrained world. By "we", I mean anyone
working on Mozilla platform code. When desktop Firefox was our only
product, this wasn't especially true -- bad leaks and the like were a
problem, sure, but ordinary usage wasn't much of an issue. But now
with Firefox on
On Sat, Feb 22, 2014 at 9:30 AM, David Rajchenbach-Teller
wrote:
> Does this memory-constrained policy apply only to release builds or also
> to debug builds?
Debug builds are definitely less important. But it's also nice to not
have big differences between debug and opt builds. E.g. in
https://b
On Sat, Feb 22, 2014 at 9:40 AM, Brian Smith wrote:
>
> How worthwhile is it to cut 100KiB from the parent process?
We don't have a fixed memory budget per se. If it's easy and doesn't
have bad side-effects, do it. Otherwise... use your judgment. Having a
Firefox OS device to test on helps with e
On Sat, Feb 22, 2014 at 1:00 PM, Till Schneidereit
wrote:
>
>> If your data is read-only after the point at which Nuwa forks the
>> process (which is once things are mostly loaded but before we load the
>> app) then generally yes. It's copy-on-write at page granularity of
>> course, so if you hav
On Sat, Feb 22, 2014 at 11:22 PM, Andreas Gal wrote:
>
>> So, I'm wondering how much effort we should put in reducing the number
>> of ChromeWorkers.
>
> We should continue to use JS in Chrome where it makes sense. Its often easier
> and faster to write some functionality in JS (and sometimes als
On Fri, Feb 21, 2014 at 9:56 PM, Nicholas Nethercote
wrote:
>>
>>> If your data is read-only after the point at which Nuwa forks the
>>> process (which is once things are mostly loaded but before we load the
>>> app) then generally yes. It's copy-on-write at
On Mon, Feb 24, 2014 at 6:50 PM, Ehsan Akhgari wrote:
> Nick, do we run any kind of automated leak checking through valgrind? I
> found bug 976363 today, it's something that any automated leak detection
> tool should be able to catch.
The Valgrind test job does leak checking, and it's recently c
On Tue, Feb 25, 2014 at 12:48 PM, Ehsan Akhgari wrote:
>>
>> The Valgrind test job does leak checking, and it's recently caught
>> some leaks and caused the offending patches to be backed out. However,
>> the test coverage is pretty meagre, and it's desktop only so can't
>> detect leaks in IPC cod
On Tue, Feb 25, 2014 at 1:10 PM, Ehsan Akhgari wrote:
>
> How much slower is a valgrind run of let's say mochitest-1 on a test slave?
> I don't think that we can run many interesting tests on valgrind on the
> build machine (and the PGO test set is *really* old and doesn't cover a lot
> of the pla
On Tue, Feb 25, 2014 at 2:32 PM, Mike Hommey wrote:
>
> I never understood why we need those jobs to be builds. Why not turn
> --enable-valgrind on m-c builds, and run valgrind as a test job?
--disable-jemalloc is needed as well.
As for the structure... I just took what already existed and got i
On Tue, Feb 25, 2014 at 8:18 PM, Mike Hommey wrote:
>> >
>> > I never understood why we need those jobs to be builds. Why not turn
>> > --enable-valgrind on m-c builds, and run valgrind as a test job?
>>
>> --disable-jemalloc is needed as well.
>
> That shouldn't be needed anymore with --soname-sy
On Thu, Feb 27, 2014 at 12:44 PM, Zack Weinberg wrote:
>>>
>> Treating these as warnings, not errors, is probably the best thing
>> here. If you see the warning and you've recently changed that
>> code, then check it. If you haven't, you see the "may be" and
>> ignore it.
>
> This is exactly the
On Sat, Mar 1, 2014 at 3:26 AM, Zack Weinberg wrote:
>
> Then, when you get a false-positive maybe-uninitialized warning, you
> could just replace T var; with mfbt::ConditionalUse var; In a
> release build, there would be no overhead; in a debug or valgrind
> build you would get a prompt assertio
On Mon, Mar 3, 2014 at 11:48 PM, Henri Sivonen wrote:
>
> Are static atoms and the HTML parser's pre-interned element name and
> attribute name objects that are on the heap shared between processes
> under Nuwa already? I.e. is the heap cloned with copy-on-write
> sharing? On the memory page granu
On Thu, Mar 6, 2014 at 8:20 AM, Kyle Huey wrote:
> It's taken over 3 years, but Bug 619487 is now fixed, and the
> preferences service will assert (fatally) if you try to use it off the
> main thread.
Out of curiosity, what's the benefit of this? Is it just a correctness
issue? The bug didn't hav
Hi,
At start-up, with a new profile, Firefox creates more than 230 system
compartments. This is about 90 more than a year ago, and it's part of
the reason why Firefox uses almost twice as much physical memory at
start-up than it did two years ago. (Have a look at
https://areweslimyet.com/ for the
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc wrote:
> Could someone please provide an update on reducing compartment overhead?
>
> Are we at a point where things like services/healthreport/HealthReport.jsm
> should be considered a "necessary evil" rather than a "gross hack?"
>
> What other sol
On Fri, Mar 21, 2014 at 6:31 AM, Benjamin Smedberg
wrote:
>
> What is the per-compartment overhead?
It's hard to pin an exact number on it. It depends on exactly the
mixture of GC things allocated by the compartment. But in my current
session, the smallest two system compartments take up only 4,7
On Fri, Mar 21, 2014 at 2:00 PM, Nicholas Nethercote
wrote:
>>
>> What is the per-compartment overhead?
>
> It's hard to pin an exact number on it. It depends on exactly the
> mixture of GC things allocated by the compartment. But in my current
> session, the smallest
On Fri, Mar 21, 2014 at 5:44 PM, Nicholas Nethercote
wrote:
>
> I should clarify: that's the memory consumption that's identified as
> belonging to the compartment, but that's not the whole picture. Some
> compartment data gets reported at the level of the runtime,
On Fri, Mar 21, 2014 at 5:00 PM, Nicholas Nethercote
wrote:
> On Fri, Mar 21, 2014 at 6:31 AM, Benjamin Smedberg
> wrote:
>>
>> What is the per-compartment overhead?
>
> It's hard to pin an exact number on it.
I talked to Bill about this today, and the overhead i
This sounds like a worthy and interesting idea, but also a very difficult one.
> PC games allow the user to turn certain features (mostly graphics
> related ones) on and off so that they can find their own level of
> acceptable performance/quality. This doesn't seem like the right
> approach for
If Oculus doesn't mind relicensing, then this whole discussion is
moot, right? So find that out ASAP.
Nick
On Tue, Apr 15, 2014 at 12:08 AM, Henri Sivonen wrote:
> On Tue, Apr 15, 2014 at 1:41 AM, Vladimir Vukicevic
> wrote:
>> 1. Check in the LibOVR sources as-is, in other-licenses/oculus. A
On Thu, Mar 20, 2014 at 11:46 PM, Nicholas Nethercote
wrote:
>
> At start-up, with a new profile, Firefox creates more than 230 system
> compartments.
I just measured again and got 198, which is great! The start-up
numbers on AWSY have improved by maybe 5-10 MiB since I started th
On Thu, Apr 24, 2014 at 9:38 PM, Henri Sivonen wrote:
>
> And the numbers are in with the complete set of removals:
> apk size reduction: 193 KB
> libxul size reduction: 181 KB
This is good stuff! Thanks.
Nick
___
dev-platform mailing list
dev-platform
On Thu, May 8, 2014 at 3:48 PM, Vladan Djeric wrote:
> Why didn't TP5 report a regression in memory usage?
Because TP5's memory measurements are meagre and usually fail to
detect even obvious regressions. And this leak only occurred in
unusual circumstances; AWSY is much better than TP5 at detect
Hi,
Do we still need Trace Malloc? I suspect it's barely used these days.
For memory profiling, we have about:memory and DMD. For shutdown leak
detection we have ASAN and Valgrind.
Trace Malloc is documented here:
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_memory_leaks#T
On Mon, May 19, 2014 at 3:05 PM, L. David Baron wrote:
>> Do we still need Trace Malloc?
>
> Are you talking about removing it from the debug builds done on our
> infra, or removing it from the tree?
I'm aiming for the latter, though the former is a reasonable first step :)
> I think the former
On Mon, May 19, 2014 at 5:32 PM, L. David Baron wrote:
>
> There are some things that I do with trace-malloc that I'm not sure
> if the other tools do.
>
> One is to check for leaks that involve caches (i.e., don't involve
> unreachable pointers). One can take two memory dumps at different
> time
On Mon, May 19, 2014 at 5:32 PM, L. David Baron wrote:
>
> There are some things that I do with trace-malloc that I'm not sure
> if the other tools do.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1014341 for
removing trace-malloc. Please add any dependencies that I've missed.
Thanks!
On Tue, Jan 7, 2014 at 12:53 PM, Robert O'Callahan wrote:
>
> We have a lot of places where we write "void Method() { ... }" all on one
> line for trivial setters and getters. I wonder if we should permit that.
The conclusion for this question was "no", but I will ask for it to be
reconsidered.
I've added the "tiny methods can be written in a single line" rule.
Search for "TinyFunction" and "LargerFunction" at
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes
Nick
___
dev-platform mailing list
dev-platform@li
On Tue, Jun 17, 2014 at 8:01 AM, Nathan Froyd wrote:
>
> In the continuing effort to make our testsuites more reliable, bug 995417 has
> landed on inbound. This bug enforces the long-standing policy of no external
> network connections in the testsuite with code: external network connections
>
Hi,
MFBT is in the process of being converted to standard Mozilla style.
(See https://bugzilla.mozilla.org/show_bug.cgi?id=1014377 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1026319.)
As a result, please write any new modules in standard Mozilla style.
There's one wrinkle: existing modules
On Sat, Jun 21, 2014 at 6:30 AM, Andrew McCreight
wrote:
> I just enabled LeakSanitizer (LSan) for ASan Mochitest runs on inbound, in
> bug 988041.
Woohoo! This is great news. Here are some of the larger leaks that
Andrew told me about:
> * Bug 1000548 - The new PKIX library was (I think) call
Hi,
The comment at the top of mfbt/DebugOnly.h includes this text:
* Note that DebugOnly instances still take up one byte of space, plus padding,
* when used as members of structs.
I'm in the process of making js::HashTable (a very common class)
smaller by converting some DebugOnly fields to i
On Tue, Jul 15, 2014 at 6:33 PM, Benoit Jacob wrote:
> Having to guard them in #ifdef DEBUG takes away much of the point
> of DebugOnly, doesn't it?
Yes. For the fields I've converted, I removed the DebugOnly<> wrapper.
Nick
___
dev-platform mailing li
I just landed the patch in bug 1041914, which finishes converting MFBT
to standard Mozilla style.
[[The crowd goes wild as the number of style variants in the tree
drops by one.]]
Nick
On Wed, Jun 18, 2014 at 5:37 PM, Nicholas Nethercote
wrote:
> Hi,
>
> MFBT is in the process
One comment: the visual distinction between a dark grey (running) and
green (successful) job is much less than on TBPL. Could a very light
green background and darker green border be used, similar to the
orange and red boxes, to make the green jobs stand out a bit more?
Another comment: compare th
On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey wrote:
> Static*Ptrs are there to avoid
> static constructors and destructors so they can't clear themselves at
> shutdown. That means that they behave quite differently than
> "regular" smart pointers. Am I the only one who is bothered by this?
To use
Hi,
PLDHashTable, nsTHashtable, and all their subclasses require a
*capacity* to be specified when they are created. If the given
capacity is not a power-of-two, it is rounded up to the next highest
power-of-two. A table with a given capacity can hold at most
0.75*capacity elements, and the averag
Hi,
I wrote a blog post about a bug that was hard to diagnose because it
involved a rarely-used cookie-related preference
(https://blog.mozilla.org/nnethercote/2014/08/15/the-story-of-a-tricky-bug/).
One of the commenters made an interesting suggestion: some kind of
about:config export tool that w
On Fri, Aug 22, 2014 at 4:27 PM, David Major wrote:
> We plan to switch the Windows build machines to Visual Studio 2013 on the
> Firefox 35 train.
>
> Some benefits from this change:
> * No more linker OOM crashes. VS2013 includes a 64-bit toolchain for 32-bit
> builds, so the linker will no lo
A few thoughts.
- |mach build binaries| is awesome.
- The build team has a difficult job. Dealing with both "the build
system sucks" and "don't make me change my workflow" is hard. The real
wins will come when the build system is fully uncoupled from |make|,
which is a big task. glandium and froy
On Wed, Aug 27, 2014 at 5:49 AM, Zack Weinberg wrote:
>
> Seems to me there might be value in applying -style controls
> to animated s *in general* -- not just for mobile.
That's a great idea!
Nick
___
dev-platform mailing list
dev-platform@lists.mozil
On Mon, Aug 25, 2014 at 5:48 PM, Nicholas Nethercote
wrote:
>
> - |mach build binaries| is awesome.
Here's an illustrative story. In my .bashrc file I have *18* aliases
for building subdirectories within Firefox: js, xpconnect, xpcom,
layout, etc. I used to use them all the time...
On Wed, Sep 3, 2014 at 5:52 PM, Boris Zbarsky wrote:
> On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
>>
>> |mach build binaries| suffices most of the time
>
> It really doesn't for the use case of not building the world when you change
> a header and want to just r
On Wed, Sep 3, 2014 at 8:47 PM, Nicholas Nethercote
wrote:
>>
>> It really doesn't for the use case of not building the world when you change
>> a header and want to just rebuild the files that use the changed part of the
>> header...
Thinking about this some more
On Mon, Sep 29, 2014 at 3:46 PM, Julian Viereck
wrote:
>
> Maybe we could use a hierarchical structure for the lint rules. At the top of
> the tree there are general rules, that are very weak - e.g. don't have
> trailing white-spaces and a maximum of 100 characters per line. Further down
> into
On Wed, Oct 1, 2014 at 1:08 AM, Cameron McCormack wrote:
> On 01/10/14 17:57, Kan-Ru Chen (陳侃如) wrote:
>>
>> It seems all the compilers we use support the c++11 ">>" in template,
>> could we start using it in new code?
>
> Yes we have some uses of that already. It's also mentioned in
> https://de
Hi alll,
I just landed https://bugzilla.mozilla.org/show_bug.cgi?id=1074656 on
mozilla-inbound, which merged |mach debug| and |mach dmd| into |mach
run|. This avoids a lot of code duplication in mach and also lets you
run the browser under a debugger and DMD at the same time.
If you used to use |
Hi,
About half of the contents of the tools/ directory is useful stuff, and the
other half is ancient and unused stuff that hasn't been touched since the early
2000s. I've gone through and written patches to remove the latter half. can.
The meta-bug tracking this work is
https://bugzilla.mozilla.o
On Sun, Oct 12, 2014 at 9:36 PM, Nicholas Nethercote
wrote:
>
> - tools/performance/pageload -- is this Talos(tp)? Bug 342089 added this.
> - tools/performance/startup -- has seen various more changes than all the
>to-be-removed stuff above; phil
Hi,
I was wondering what people think is the worst piece of code in the
entire Mozilla codebase. I'll leave the exact meanings of "worst" and
"piece of code" unspecified...
Thanks.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote
wrote:
>
> I was wondering what people think is the worst piece of code in the
> entire Mozilla codebase. I'll leave the exact meanings of "worst" and
> "piece of code" unspecified...
Thanks for the rep
On Fri, Oct 17, 2014 at 8:55 AM, Andreas Gal wrote:
>
> I would like to nominate image/src/* and in particular its class hierarchy
> which completely doesn’t make any sense what so ever. imgRequest,
> imgIRequest, we got it all.
Does this cause correctness problems, or is it just hard to read a
On Mon, Oct 20, 2014 at 1:17 PM, Robert O'Callahan wrote:
> Hurrah!
Indeed. Thank you, Poiru, for all your work sanding down rough edges
throughout the codebase.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.or
On Tue, Oct 21, 2014 at 1:00 PM, Chris AtLee wrote:
>
> Just a quick note that we're hoping to enable 64-bit windows builds & tests
> across most trunk branches this week. This includes branches such as
> mozilla-central, mozilla-inbound, fx-team, etc.
Excellent news! Thank you.
Nick
___
Hello.
Our command-line option handling is *interesting*. Did you know that:
- our options work in -foo form and --foo form;
- they are case-insensitive;
- this holds for both short options (e.g. -h) and long options (e.g. -help).
So, for example, the following are all equivalent: -h, -H, --h,
On Thu, Oct 23, 2014 at 6:20 PM, Nicholas Nethercote
wrote:
>
>
> So, for example, the following are all equivalent: -h, -H, --h, --H.
On Windows, /h and /H are also equivalent.
> As are -help, --help, -HELP, --HeLp.
Again on Windows, /help, /HELP, /HelP, etc. are equivalent. A
On Fri, Oct 24, 2014 at 6:31 AM, Benjamin Smedberg
wrote:
>>
>> Some of our options are handled elsewhere, via ad hoc
>> code that is generally less flexible.
>
> Can you point me to this? Pretty much any code handling command lines should
> either be use the nsAppRunner code or using the nsIComma
Hi,
In https://bugzilla.mozilla.org/show_bug.cgi?id=1089446 I'm removing
some old, unused Perl scripts from the tree. I'm giving notice here
just in case any of the scripts I'm planning to remove are still being
used, and also to find out if more scripts can be removed.
My working list and notes
A clarification: I'm not planning to do anything with the scripts in
the "THIRD-PARTY" section, unless somebody tells me "foo.pl is not
third-party and can be safely removed".
Nick
On Mon, Oct 27, 2014 at 3:18 PM, Nicholas Nethercote
wrote:
> Hi,
>
> In https:/
On Mon, Oct 27, 2014 at 4:49 PM, Karl Tomlinson wrote:
>
>> ./layout/mathml/updateOperatorDictionary.pl
>> - appears to be in fairly recent use
>
> This was used to generate an in-tree file from an external spec.
> It is reasonably likely that there will be future changes to the
> spec, in which c
Hi,
I've just finished a major overhaul of our documentation about memory-related
tools. We used to have two main pages on this topic:
- https://wiki.mozilla.org/Performance:Leak_Tools
-
https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_memory_leaks
There was some overlap bet
On Tue, Oct 28, 2014 at 9:17 PM, Nicholas Nethercote
wrote:
>
> Both of these pages now just contain a single link to
> https://developer.mozilla.org/en-US/docs/Mozilla/Performance, which has a new
> section "Memory profiling and leak detection tools" with links to pages for
Hi,
NS_StackWalk is totally broken on Win64. I've been looking into this
because it prevents DMD from working usefully, but I am stuck. Details
are in https://bugzilla.mozilla.org/show_bug.cgi?id=1088343.
You can see examples of this in debug mochitest logs when assertions
failures occur. E.g. he
On Fri, Nov 7, 2014 at 8:26 AM, Dave Townsend wrote:
> We started that with prompting users to opt-in to e10s
> around a month ago and since then around 25% of Nightly users have been
> running with e10s enabled. As we hoped this saw a surge in the number of
> bugs filed and helped us understand t
On Sun, Nov 9, 2014 at 12:29 AM, wrote:
>
> Everyone should start familiarizing themselves with the idiosyncrasies of
> debugging three processes at once, it'll be the norm this spring.
Three? I've only seen two...
> (..and just you wait until we turn on process-per-domain!)
Let's have some c
On Sat, Nov 8, 2014 at 2:39 PM, Mike Hommey wrote:
>
> BTW, does AWSY deal with e10s?
That's an excellent question... I suspect not. I wonder if it'll get
confused or just report measurements (e.g. "explicit", "resident") for
one of the processes.
AWSY's a little behind and it's most recent meas
On Sun, Nov 9, 2014 at 2:35 PM, Nicholas Nethercote
wrote:
>>
>> BTW, does AWSY deal with e10s?
>
> That's an excellent question... I suspect not. I wonder if it'll get
> confused or just report measurements (e.g. "explicit", "resident") for
>
What exactly do you mean by "unit tests"?
At first I thought you were just referring to "C++ unit tests", i.e.
the ones that show up on Treeherder as "Cpp". But the first page of
the survey says "We care about tests which are also run on tbpl (e.g.
mochitests, reftest, xpcshell, marionette, etc.)"
On Thu, Dec 4, 2014 at 8:54 AM, Seth Fowler wrote:
> So I noticed that we don’t say anything about initializer list formatting in
> our coding style guide. I’d like to propose that we standardize this
> formatting:
>
> Foo::Foo(int aBar, char aBaz)
> : mBar(aBar)
> , mBaz(aBaz)
> {
> ….
>
On Fri, Dec 5, 2014 at 5:41 AM, Eric Rescorla wrote:
>
>> I’d like to change the coding style guide to let us make out-params more
>> obvious by using an ‘o’ prefix for their name instead of an ‘a’. For
>> example,
>
> What fraction of these cases can't be distinguished by making non-out
> ref/poi
You sometimes see comments for this, e.g.
int foo(int aX, /* out */ char* aS);
If we recommended/required this, it might make the interregnum period
problem smaller?
Nick
On Fri, Dec 5, 2014 at 1:31 PM, Robert O'Callahan wrote:
> On Fri, Dec 5, 2014 at 12:08 PM, Seth Fowler wrote:
>
>> Well
On Tue, Dec 9, 2014 at 10:46 AM, Gregory Szorc wrote:
>
> I discussed options with Mike Hommey and we believe that moz.build files are
> the appropriate default location for this metadata. We considered
> alternatives such as moz.build-like Python sandboxes under a different
> filename and standal
On Tue, Dec 16, 2014 at 6:33 AM, Gijs Kruitbosch
wrote:
> Please file a bug with a testcase that people can run (e.g. an add-on that
> creates such a tree on such a window) and look for a regression window using
> e.g. mozregression ( http://mozilla.github.io/mozregression/ ).
It's not clear to m
Hi,
If you do |mach build| and get compile errors, often those errors
scroll quickly off screen and they are mixed in with other lines of
output and it's hard to find them.
I deal with this by using a bash alias that calls |mach build| and
pipes the output to file. I can then use Vim's quicklists
Hi,
I just landed on mozilla-inbound the patches for
https://bugzilla.mozilla.org/show_bug.cgi?id=1124973, which replaced
PL_DHashTableLookup() with PL_DHashTableSearch().
(If you haven't heard of PL_DHashTableLookup(), that's because it is
quite new. https://bugzilla.mozilla.org/show_bug.cgi?id=
Hi,
I just landed the patches in
https://bugzilla.mozilla.org/show_bug.cgi?id=1050035. They
affect PLDHashTable's API in the following ways.
- PLDHashTable now allocates its entry storage lazily. (nsTHashtable and
friends do too, since they are just layers on top of PLDHashTable.) This is a
n
On Fri, Feb 6, 2015 at 6:59 PM, Philip Chee wrote:
>>
>> - PLD_NewDHashTable() and PLD_HashTableDestroy() have been removed. You
>> should
>> now just use |new|+PL_DHashTableInit() and PLD_HashTableDestroy()+|delete|,
>
> ITYM PL_DHashTableFinish()+|delete|
I do. Thank you for the correction.
I had to back these changes out due to some infrequent and
intermittent crashes and assertion failures, alas.
Nick
On Wed, Feb 4, 2015 at 7:45 PM, Nicholas Nethercote
wrote:
> Hi,
>
> I just landed the patches in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1050035. T
Hooray! Thank you.
Nick
On Fri, Feb 20, 2015 at 12:33 PM, Birunthan Mohanathas
wrote:
> Greetings,
>
> If your commit modifies an IDL interface (think `[...] interface Foo
> {};`), you will now have to either
>
> 1) Bump the corresponding interface UUID.
> Use e.g. `./mach update-uuids nsISo
Hi,
I just landed the patch from
https://bugzilla.mozilla.org/show_bug.cgi?id=1134030 which adds a new
memory reporter for the Windows address space. Sample output:
> 2,147,418,112 B (100.0%) -- address-space
> +--1,662,676,992 B (77.43%) -- free [229]
> +299,868,160 B (13.96%) -- commit
> |
On Sun, Feb 22, 2015 at 10:46 PM, Mike Hommey wrote:
>>
>> We've had increasing numbers of cases lately on Windows where memory
>> usage goes out of control but the existing memory reporters (e.g. the
>> "explicit" tree in about:memory) doesn't show anything. This is
>> because the memory usage is
On Fri, Mar 27, 2015 at 10:25 AM, Robert O'Callahan
wrote:
>
> Switching method names to start with a capital letter would be helpful too
> ... especially where it's leaked into MFBT.
FWIW, here is the contents of mfbt/STYLE:
> MFBT uses standard Mozilla style, with the following exceptions.
>
>
An update on some pldhash changes that were backed out and then
gradually relanded...
On Wed, Feb 4, 2015 at 7:45 PM, Nicholas Nethercote
wrote:
> Hi,
>
> I just landed the patches in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1050035. They
> affect PLDHashTable's API i
On Sat, May 2, 2015 at 2:20 AM, wrote:
>
> In summary, you're batshit insane, power hungry, and mad, and you're using
> double speek at its finest.
Please refrain from further discussion until you can avoid making
crude personal attacks such as these.
Nick
_
On Mon, May 4, 2015 at 11:53 PM, Leman Bennett (Omega X)
wrote:
>
> I heard that there was rumor of a plan to limit process count spawn to
> per-domain. But I've not seen offhand of a bug filed for it or anything else
> that relates to achieving more than one content process instance.
There are m
On Wed, May 6, 2015 at 2:12 AM, Bill McCloskey wrote:
>
> Regarding process-per-core or process-per-domain or whatever, I just want
> to point out that responsiveness will improve even beyond process-per-core.
You're probably right, but as you increase the number of processes the
responsiveness i
On Sat, May 23, 2015 at 4:46 AM, Randell Jesup wrote:
>>
>>Various bits of code invented a log level that was less important than
>>debug (I would call this verbose). This was not specified in NSPR logging,
>>but just kind of worked. With the addition of |Info| we can transition code
>>that was us
On Sat, May 23, 2015 at 5:11 AM, Gregory Szorc wrote:
>
> Better than a log level is an event type (possibly enumerated).
I suspect that's right.
Having said that, Eric is trying to clean up an existing system which
is large and messy. Just fixing up the log levels is challenging
enough, as seen
301 - 400 of 492 matches
Mail list logo
