Re: mach has landed

As an additional data point, my experience is that the interactivity of my machine is not noticeably impacted when I overcommit with -j12 on my 4core/8thread i7 windows machine. Task manager shows the cores often pegged at 100%, but the machine basically behaves normally. Neither is my Ubuntu

Re: reminder: content processes (e10s) are now used by desktop Firefox

Could this be why I'm starting to see banner ads in some of my newtab-page snapshots, despite never seeing them in a tab? I don't appear to see this on an old nightly24 snapshot I have lying around. -Jeff - Original Message - From: Gavin Sharp ga...@gavinsharp.com To: dev-platform

Re: reminder: content processes (e10s) are now used by desktop Firefox

It's certainly worrying given the number of security- and privacy-related addons people rely on working. Seeing ads in thumbnails is relatively harmless (if disconcerting), but if someone is relying on an addon for important security or privacy reasons, and we auto-updated them and bypassed

Re: vsync proposal

SwapBuffers w/SwapInterval(1) can block (or not) whenever it wants to, basically. With SwapInterval(0), I'm not sure we can guarantee we won't have tearing, (except on platforms which don't tear) since we don't really know how long SwapBuffers will take, or when vblank is. (This can probably be

Re: vsync proposal

Could you clarify number 2? It's a little dense. -Jeff - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Bas Schouten bschou...@mozilla.com Cc: Jeff Muizelaar jmuizel...@mozilla.com, Vladimir Vukicevic vladi...@mozilla.com, dev-platform@lists.mozilla.org,

Re: Mozilla Angle should enable D3D 11 renderer

This is already tracked here: https://bugzilla.mozilla.org/show_bug.cgi?id=912196 -Jeff - Original Message - From: xunxun xunxun1...@gmail.com To: dev-platform@lists.mozilla.org Sent: Thursday, September 26, 2013 4:40:03 AM Subject: Mozilla Angle should enable D3D 11 renderer Hi,

Re: Audit your code if you use mozilla::WeakPtr

It would appear to me that you really need to promote this to a strong reference while you're using it. Even `if (foo) foo-bar();` could theoretically have the value of `foo` change between the branch and the deref. Also, do we at least `MOZ_ASSERT(get())` in `operator-`? Yes, it will crash

Re: Layer Construction for Off Main Thread canvas

thing WebGL needs moved between the client and host size of things is the SurfaceStream pointer. -Jeff - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Nicolas Silva nical.si...@gmail.com Cc: Kyle Huey m...@kylehuey.com, Morris Tseng mts...@mozilla.com, Jeff Gilbert

Re: Reacting more strongly to low-memory situations in Firefox 25

A 64-bit build would, but we don't ship those. A win64 machine running a 32-bit program can have 4GB of VM, though. -Jeff - Original Message - From: Robert Kaiser ka...@kairo.at To: dev-platform@lists.mozilla.org Sent: Wednesday, November 27, 2013 4:35:36 PM Subject: Re: Reacting more

Re: Can we start using C++ STL containers in Mozilla code?

Erase-remove seems like poor naming, more than anything. I think that iterators (pretending things are arrays) are generally really handy. Alternatives (needing to do everything with pfns) really tend towards arcaneness and are often awkward to use. In my experience, docs for 'our' containers

Re: On the usefulness of style guides (Was: style guide proposal)

It's compromise. I think we can take it as given that we'll never all agree on one way to do things, so instead, different modules do their own things. I think this is a pretty decent solution, though the problem becomes needing different guides for different modules. (the just mime what you

Re: On the usefulness of style guides (Was: style guide proposal)

. -Jeff PS: Don't get me wrong: Moz-style has gotten way better recently. I agree with almost all of it, but there are a couple of points with which I really don't. - Original Message - From: Bobby Holley bobbyhol...@gmail.com To: Jeff Gilbert jgilb...@mozilla.com Cc: Ehsan Akhgari

Re: Mozilla style guide issues, from a JS point of view

FWIW, WebGL and GLContext do this for the same reasons. -jgilbert - Original Message - From: Jeff Walden jwalden+...@mit.edu To: dev-platform@lists.mozilla.org Sent: Tuesday, January 7, 2014 2:26:46 PM Subject: Re: Mozilla style guide issues, from a JS point of view On 01/07/2014 02:23

Re: Please take ask.mozilla.org for a spin

Seconded. I want to sign into Mozilla things via my Mozilla accounts. Any barrier like this in the way of otherwise-busy engineers is going to hamper adoption, and adoption will only solidify if enough people are using it and/or there's enough content. If you want Mozillians to use it, you

Re: MOZ_ASSUME_UNREACHABLE is being misused

My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE. It's really handy to have something like MOZ_ASSERT_UNREACHABLE, instead of having a bunch of MOZ_ASSERT(false, Unreachable.) lines. Consider MOZ_ASSERT_UNREACHABLE being the same as MOZ_OPTIMIZE_FOR_UNREACHABLE in

Re: C++ standards proposals of potential interest, and upcoming committee meeting

- Original Message - From: Rik Cabanier caban...@gmail.com To: Benoit Jacob jacob.benoi...@gmail.com Cc: Botond Ballo bba...@mozilla.com, dev-platform dev-platform@lists.mozilla.org, Jet Villegas j...@mozilla.com Sent: Monday, June 9, 2014 2:08:37 PM Subject: Re: C++ standards

Re: C++ standards proposals of potential interest, and upcoming committee meeting

2D graphic in C++. The reason it feels like B implies A is that using libraries is a terrible pain. Fix the cause of the friction for using existing graphics APIs, instead of just treating the symptoms. On Mon, Jun 9, 2014 at 11:38 PM, Jeff Gilbert jgilb...@mozilla.com wrote: We also use

Re: C++ standards proposals of potential interest, and upcoming committee meeting

- Original Message - On Mon, Jun 9, 2014 at 2:38 PM, Jeff Gilbert jgilb...@mozilla.com wrote: - Original Message - From: Rik Cabanier caban...@gmail.com To: Benoit Jacob jacob.benoi...@gmail.com Cc: Botond Ballo bba...@mozilla.com, dev-platform dev-platform

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

I would actually say that debug tests are more important for continuous integration than opt tests. At least in code I deal with, we have a ton of asserts to guarantee behavior, and we really want test coverage with these via CI. If a test passes on debug, it should almost certainly pass on

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

I was just going to ask about this. I glanced through the mozconfigs in the tree for at least Linux debug, but it looks like it only has --enable-debug, not even -O1. Maybe it's buried somewhere in there, but I didn't find it with a quick look. I took a look at the build log for WinXP debug,

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

...@mozilla.com To: Ehsan Akhgari ehsan.akhg...@gmail.com Cc: Jonathan Griffin jgrif...@mozilla.com, Jeff Gilbert jgilb...@mozilla.com, dev-platform@lists.mozilla.org Sent: Wednesday, August 20, 2014 9:02:14 AM Subject: Re: Experiment with running debug tests less often on mozilla-inbound the week

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

for non-graphics code to expose platform-specific bugs, but it's less likely, so maybe larger regression windows are acceptable for platform-specific bugs in non-graphics code. -Jeff - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Jeff Gilbert jgilb...@mozilla.com

Re: Running mochitests from a copy of the objdir?

From: Gregory Szorc g...@mozilla.com To: James Graham ja...@hoppipolla.co.uk, dev-platform@lists.mozilla.org Sent: Wednesday, August 20, 2014 11:24:00 AM Subject: Re: Running mochitests from a copy of the objdir? It sounds like the copy build to remote machine so we can run tests there is

Re: Experiment with running debug tests less often on mozilla-inbound the week of August 25

From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Jeff Gilbert jgilb...@mozilla.com Cc: Chris AtLee cat...@mozilla.com, Jonathan Griffin jgrif...@mozilla.com, dev-platform@lists.mozilla.org Sent: Wednesday, August 20, 2014 4:00:15 PM Subject: Re: Experiment with running debug tests less often

Re: Switching to Visual Studio 2013

From: Gian-Carlo Pascutto gpascu...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Wednesday, August 27, 2014 11:23:34 AM Subject: Re: Switching to Visual Studio 2013 On 27/08/2014 17:30, Ted Mielczarek wrote: I think our commitment to the Express versions should be ensure it

Re: JavaScript (strict) Warning from FF mochitest-plain test.

We should most likely assert when we have strict violations in chrome JS. We should *definitely* assert when we have JS errors in chrome JS. I don't see how there should be any excuse for either of these cases. We certainly can't assert on non-browser JS errors, but we should keep our own

Re: JavaScript (strict) Warning from FF mochitest-plain test.

Indeed, which is why I recommended assert, not warn. Warnings are basically useless from a CI standpoint. If you want to guarantee it, don't warn, assert. -Jeff - Original Message - From: Martin Thomson m...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Thursday, October 2, 2014

Intent to implement and ship: Unprivilaged WEBGL_debug_renderer_info

Summary: The WEBGL_debug_renderer_info extension allows for querying which driver (and commonly GPU) a WebGL context is running on. Specifically, it allows querying the RENDERER and VENDOR strings of the underlying OpenGL driver. By default, RENDERER and VENDOR queries in WebGL yield safe but

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

I propose that we stop recommending the universal use of an 'a' prefix for arguments to functions in C and C++. If the prefix helps with disambiguation, that's fine. However, use of this prefix should not be prescribed in general. `aFoo` does not provide any additional safety that I know of.[1]

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

On Tue, Jul 7, 2015 at 4:54 AM, Honza Bambas hbam...@mozilla.com wrote: I'm strongly against removing the prefix. I got used to this and it has its meaning all the time I inspect code (even my own) and doing reviews. Recognizing a variable is an argument is very very useful. It's important

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

On Tue, Jul 7, 2015 at 6:03 AM, Kartikaya Gupta kgu...@mozilla.com wrote: I'd be interested to know: of those people who are in favour of removing the prefix, how many regularly have to deal with functions that are longer than two pages (a page is however much code you can see at a time in

Re: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

On Tue, Jul 14, 2015 at 9:17 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley bobbyhol...@gmail.com wrote: I'm not wild about this idea. It's such a boil-the-ocean solution I honestly thought bsmedberg was joking at first... Well

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

On Thu, Jul 16, 2015 at 6:50 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: On 2015-07-15 6:47 PM, Jeff Gilbert wrote: Arg warts improve backtracking for debugging Regardless of the validity of Arg warts help illustrate information flow, the use-case of backtracking to 'origin' of aFoo

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

On Sun, Jul 12, 2015 at 10:45 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Thu, Jul 9, 2015 at 7:01 PM, Jeff Gilbert jgilb...@mozilla.com wrote: Arguments have the same lifetimes as locals, and the only exceptions to this apply to both args and locals. (references and pointers

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

On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann tzimmerm...@mozilla.com wrote: Am 08.07.2015 um 16:36 schrieb smaug: Do you actually have any data how many % of Gecko devs would prefer not using aFoo? I strongly prefer 'aFoo' over 'foo' for the extra context that it gives to the

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

On Tue, Jul 7, 2015 at 1:03 PM, smaug opet...@mozilla.com wrote: As someone who spends more than 50% of working time doing reviews I'm strongly against this proposal. aFoo helps with readability - reader knows immediately when the code is dealing with arguments. When and why is this useful

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

On Tue, Jul 7, 2015 at 1:20 PM, smaug opet...@mozilla.com wrote: readability / easier to follow the dataflow are rather compelling reasons. It hurts readability for me and many others. I don't see how it revolutionizes following dataflow, since we have locals that are pure functions of args,

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

Outvars are good candidates for having markings in the variable name. `aFoo` for all arguments is a poor solution for this, though. On Tue, Jul 7, 2015 at 1:22 PM, smaug opet...@mozilla.com wrote: On 07/07/2015 11:18 PM, Jeff Gilbert wrote: On Tue, Jul 7, 2015 at 1:03 PM, smaug opet

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

On Wed, Jul 8, 2015 at 7:48 AM, smaug opet...@mozilla.com wrote: Another example where aFoo tends to be rather useful is lifetime management. If I see aFoo being used somewhere in a method after some unsafe method call (layout flush, any script callback handling, event dispatch, observer

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

On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm er...@mozilla.com wrote: I'm not a huge fan of the 'aFoo' style, but I am a huge fan of consistency. So if we want to change the style guide we should update our codebase, and I don't think we can reasonably do that automatically without introducing

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

On Tue, Jul 7, 2015 at 6:06 PM, Karl Tomlinson mozn...@karlt.net wrote: Jeff Gilbert writes: I work with a number of these, but after a page or two, why is it at all relevant which vars were args? For information flow? Should we mark locals that purely derive from args as `aFoo` as well

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

On Mon, Jul 6, 2015 at 8:26 PM, Mike Hommey m...@glandium.org wrote: The existence of aFoo goes along with the existence of mFoo, sFoo, kFoo, and others I might have forgotten. Not that I particularly care about aFoo, but why strike this one and not the others?[1] It's not like they have

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

On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson mozn...@karlt.net wrote: Jeff Gilbert writes: It can be a burden on the hundreds of devs who have to read and understand the code in order to write more code. Some people find the prefix helps readability, because it makes extra information

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

WEBGL_dynamic_texture is due for a pruning refactor (I think I'm on the hook for this), so don't base anything on it as-is. IIRC, we don't believe WEBGL_security_sensitive_resources is viably implementable in a safe way (timing attacks!), so I suggest ignoring it. Extending texture uploads to

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Mon, Jan 4, 2016 at 4:46 PM, Robert O'Callahan wrote: > On Tue, Jan 5, 2016 at 10:46 AM, Kearwood "Kip" Gilbert < > kgilb...@mozilla.com> wrote: > >> In WebVR, we often present UI as a Head's Up Display (HUD) that floats >> in front of the user. Additionally, we often

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

, Jan 7, 2016 at 4:12 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Fri, Jan 8, 2016 at 11:08 AM, Jeff Gilbert <jgilb...@mozilla.com> wrote: >> >> On Wed, Jan 6, 2016 at 8:07 PM, Luke Wagner <lwag...@mozilla.com> wrote: >> > FWIW, I was wonderi

Re: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

On Wed, Jan 6, 2016 at 8:07 PM, Luke Wagner wrote: > FWIW, I was wondering if we could go a step further and allow > (optional) user interaction with the rendered DOM elements. That way > you could, say, select text on a 3d surface with a mouse or use an > tag. It seems

Re: Dan Stillman's concerns about Extension Signing

On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit wrote: > FWIW, I received questions about this via private email and phone calls > from two people working on extensions that support their products. Their > extensions sit in the review queue with not chance of getting

Re: A list of easy-ish gfxContext-to-DrawTarget conversions

For a similar situation, we used an etherpad to allow painless acquisition of pending todos. Just move the instances you want 'assigned' to you into a section in the etherpad. It's not perfect, but it's an alternative to responding to the email, and makes it easy to see the state of things. On

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote wrote: > On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg > wrote: >> You shouldn't need to annotate the file/line separately, because that is >> (or at least should be!) the top of the stack. >

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

It would be useful to have a dashboard that collates this information better. PS: Sarcasm is unhelpful. On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert <jgilb...@mozilla.com> wrote: >>

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

at 09:26 PM, Jeff Gilbert wrote: >> On Tue, May 31, 2016 at 4:39 PM, Nicholas Nethercote >> <n.netherc...@gmail.com> wrote: >> > On Wed, Jun 1, 2016 at 1:05 AM, Benjamin Smedberg <benja...@smedbergs.us> >> > wrote: >> >> Y

Re: Coding style for C++ enums

Strong preference against eFoo, here. :) Just use enum classes. On Fri, Apr 8, 2016 at 10:35 AM, smaug wrote: > On 04/08/2016 07:38 PM, Nick Fitzgerald wrote: >> >> On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas < >> birunt...@mohanathas.com> wrote: >> >>> On 8 April 2016

Re: Build System Project - Update from the last 2 weeks

I thought Linux did LTO but not PGO? On Tue, Apr 5, 2016 at 3:53 PM, Mike Hommey wrote: > On Tue, Apr 05, 2016 at 09:02:09PM +0100, David Burns wrote: >> Below is a highlight of all work the build peers have done in the last 2 >> weeks as part of their work to modernise the

Re: Coding style for C++ enums

On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote: >> I propose that if you're in a part of the codebase where you can't >> tell if it's an enum or a function poin

Re: Coding style for C++ enums

alone. It would also add to our already-pungent code smell. On Fri, Apr 8, 2016 at 3:03 PM, Mats Palmgren <m...@mozilla.com> wrote: > On 2016-04-08 23:03, Jeff Gilbert wrote: >> >> Strong preference against eFoo, here. :) > > > Strong preference *for* eFoo, here. :)

Re: Coding style for C++ enums

I'm not sure how this is compromise. We were already supposed to use enum classes with new code. Every additional glyph incurs mental load. Code should instead be written so these things are not necessary to explicitly state. *That* is the code we should be trying to write. In well-written code,

Re: Proposing preferring Clang over GCC for developer buidls

For standard development builds, --enable-debug build speed is (to me) the primary motivator since we've guaranteed that they're equally correct. (within reason) I'll gladly run some extra tests to gather data about this. FWIW, with a 26% speedup, it would definitely seems like it'd be worth

Re: Proposing preferring Clang over GCC for developer buidls

On Wed, Mar 2, 2016 at 3:45 PM, Mike Hommey wrote: > More importantly, changing the official toolchain has implications on > performance. Sorry, I meant for general automation. Our final spins (especially LTO/PGO builds) should remain whatever gives us maximum perf. (not

Re: Proposal: use nsresult& outparams in constructors to represent failure

FWIW, I use static Create functions for fallible heap-only objects, and StackFallible::ctor(bool* const out_success/error) for the rarer fallible stack-createable objects. It sounds like this lines up with existing proposals here. Example fallible heap-only:

Re: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

Pointers are prefereable for outparams because it makes it clearer what's going on at the callsite. (at least indicating that something non-trivial is happening) On Wed, Apr 20, 2016 at 8:07 PM, Kan-Ru Chen (陳侃如) wrote: > Nicholas Nethercote writes: >

Re: Generating Visual Studio project files by default

What's the build-time impact of this? On Tue, May 24, 2016 at 4:00 PM, Gregory Szorc wrote: > Coming soon to your local builds, Visual Studio project files will be > generated automatically when building on Windows because we want to > encourage more people to use them because

Re: Should &&/|| really be at the end of lines?

I don't visually like ||/&& at start of line, but I can't fault the reasoning, so I'm weakly for it. I don't think it's important enough to change existing code though. On Thu, Feb 16, 2017 at 1:47 PM, wrote: > Question of the day: > When breaking overlong expressions,

Re: Should &&/|| really be at the end of lines?

ean-Yves Avenard <jyaven...@mozilla.com> wrote: > Hi > > > On 16/02/17 23:56, Jeff Gilbert wrote: >> >> I don't visually like ||/&& at start of line, but I can't fault the >> reasoning, so I'm weakly for it. >> I don't think it's important enough to cha

Re: Should &&/|| really be at the end of lines?

If there are so many parens that we require an editor to disambiguate them, it's too dense. Add whitespace or decompose the expression until readable. On Thu, Feb 16, 2017 at 3:15 PM, Mike Hommey wrote: > On Fri, Feb 17, 2017 at 12:10:32AM +0100, Jean-Yves Avenard wrote: >>

Re: Should &&/|| really be at the end of lines?

, L. David Baron <dba...@dbaron.org> wrote: > On Thursday 2017-02-16 15:11 -0800, Jeff Gilbert wrote: >> I would not assume that's necessarily going to happen without >> contention. Consistency is not a goal in and of itself. > > Using clang-format on the entire

Re: Should &&/|| really be at the end of lines?

gt; important than personal preferences. > > g. > > On Friday, February 17, 2017 at 9:57:04 AM UTC+11, Jeff Gilbert wrote: >> I don't visually like ||/&& at start of line, but I can't fault the >> reasoning, so I'm weakly for it. >> I don't think it's important

Re: Changing the representation of rectangles in platform code

Reducing overflow risk and simplifying intersection both seem worth it, but godspeed whoever works on this! On Fri, Feb 10, 2017 at 12:45 PM, Milan Sreckovic wrote: > First step needs to happen completely before the second step does, so I > guess the danger is that we

Re: Intent to deprecate: Building mozilla-central without Skia enabled

Agreed. On Mon, Aug 22, 2016 at 11:08 AM, George Wright wrote: > I'm looking to remove the option to build mozilla-central without Skia. > > Currently we default to Skia being disabled, and enable it using > --enable-skia. This is problematic because all of our officially

Re: Faster gecko builds with IceCC on Mac and Linux

They're basically out of stock now, but if you can find them, old refurbished 2x Intel Xeon E5-2670 (2.6GHz Eight Core) machines were bottoming out under $1000/ea. It happily does GCC builds in 8m, and I have clang builds down to 5.5. As the v2s leave warranty, similar machines may hit the market

Re: Please do NOT hand-edit web platform test MANIFEST.json files

JSON allows comments if all the JSON processors we use handle comments. :) On Tue, Mar 21, 2017 at 8:52 AM, James Graham wrote: > On 20/03/17 22:15, gsquel...@mozilla.com wrote: > >> Sorry if it's a silly suggestion: >> Could the current tool insert some helpful reminders

Re: windows build anti-virus exclusion list?

Can confirm for Ryzen: FWIW, my stock R7 1800x (RAM @2133Mhz for now :( ) did a Windows debug clobber in 15:32.40 with the default -j16. (any directory that showed up as read by MsMpEng in Resource Monitor excluded for Defender) I'll give it a run through with Defender disabled, and see if

Re: Coding style: `else for` or `else { for... }`?

IMO: Never else-for. (or else-while) Else-if is a reasonable continuation of concept: "Well it wasn't that, what if it's this instead?" Else-for is just shorthand for "well it wasn't that, so let's loop over something". Else-if is generally used for chaining, often effectively as an advanced

Re: Follow up on clang-format

Now instead we will get to try to phrase code in a way that clang-format will preserve readably? I should think "it doesn't always produce nice formatting, but it's at least consistent" sounds like a major warning sign, particularly given that we definitely have tricky code for which we have made

Re: Hiding 'new' statements - Good or Evil?

ranged-for issues are the same as those for doing manual iteration, and your complaints about auto are caused by deficient code/design review. The further we deviate from standards, the harder it is for contributors (and not just new ones) to do the right thing. The default should be to move

Re: Hiding 'new' statements - Good or Evil?

I agree that MakeNotNull doesn't sound like it allocates. Reads to me as Make[Into]NotNull. Context will *usually* make this clear, but why not NewNotNull? (Honestly I don't like MakeUnique to begin with) NotNull::New(args...) is another option. "My first goal was to avoid the unnecessary

Re: Hiding 'new' statements - Good or Evil?

const auto& foo = getFoo(); foo->bar(); // foo is always safe here Use of auto instead of auto& should be less common. I only use it for: Casts: `const auto foo = static_cast(bar);` Or long (but obvious) types I need a value of, usually RefPtrs of long types. Almost every other auto is `const

Re: Intent to require Python 3 to build Firefox 59 and later

As long as we follow PEP 394, I'm super excited. (including on our mozilla-build windows system, which counts as 'unix-like') On Sun, Nov 12, 2017 at 9:12 AM, David Burns wrote: > I am not saying it should but if we have a requirement for python 3, we are > also going to have

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

ot onerous. On Mon, Nov 6, 2017 at 9:19 AM, Gregory Szorc <gsz...@mozilla.com> wrote: > > >> On Nov 6, 2017, at 05:19, Gabriele Svelto <gsve...@mozilla.com> wrote: >> >>> On 04/11/2017 01:10, Jeff Gilbert wrote: >>> Clock speed and core count matter much m

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

. If we've given developers ECC machines already when non-ECC was an option, absent a positive request for ECC from the developer, I would consider this to have been a minor mistake. On Mon, Nov 6, 2017 at 3:03 PM, Gabriele Svelto <gsve...@mozilla.com> wrote: > On 06/11/2017 22:44, Jef

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

If you don't want to get into the weeds on ECC again, please do not reinitiate discussion. I do not agree that "the additional cost of ECC is very low compared to the cost of developer time over the two years that they're expected to use it", but I will restrict my disagreement to the forked

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

Clock speed and core count matter much more than ECC. I wouldn't chase ECC support for general dev machines. On Thu, Nov 2, 2017 at 6:46 PM, Gregory Szorc wrote: > On Thu, Nov 2, 2017 at 3:43 PM, Nico Grunbaum wrote: > >> For rr I have an i7 desktop with

Proposal: WebIDL generated bindings classes renamed from dom::FooBinding to dom::binding::Foo

We have a name conflict under the current system when trying to use these two classes from the webgpu sketch webidl: - WebGPUBuffer - WebGPUBufferBinding I'm proposing renaming the generated bindings classes from dom::FooBinding to dom::binding::Foo. This seems like a reasonable use of

Re: Update on rustc/clang goodness

It would be sad to see us standardize on a clang monoculture. On Tue, May 1, 2018 at 7:56 PM, Anthony Jones wrote: > You may already know that the Low-Level Tools team support important tools > and code infrastructure. Lately we’ve also been improving our rustc/clang > (LLVM) story and I’d like

Re: Update on rustc/clang goodness

not win64 yet perf-wise, anyways) It would be nice to establish our plan here. On Tue, May 29, 2018 at 9:10 PM, Anthony Jones wrote: > On Wednesday, 30 May 2018 08:48:12 UTC+12, Jeff Gilbert wrote: >> It would be sad to see us standardize on a clang monoculture. > > It pays not to b

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

I don't believe e-prefix adds sufficient value. Mutable statics *must* always be s-prefixed. If this is not the case I will gladly bring the codebase into compliance. On Fri, Jun 29, 2018 at 11:36 AM, smaug wrote: > On 06/29/2018 05:58 PM, Boris Zbarsky wrote: >> >> On 6/29/18 10:30 AM, Nathan

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

If we can't agree, it shouldn't be in the style guide. On Mon, Jun 25, 2018 at 2:17 PM, Peter Saint-Andre wrote: > And perhaps good reason for removing it from the style guide? ;-) > > On 6/25/18 3:08 PM, Emilio Cobos Álvarez wrote: >> And Kris pointed out that we already had another huge thread

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

I agree with the sentiment in the write-up, that ideally beginner 2d graphics needs are better handled by improving library/packaging support, not by importing (and speccing??) an ancient library. For instance in JS, people are more likely to pull in a library (of many) to help with graphing,

Re: Hiding 'new' statements - Good or Evil?

I would say it comes down to the module. I'm very comfortable in my modules using auto, perhaps because our lifetime management is more clear. To me, the unsafe examples are pretty strawman-y, since it's very clear that there are at-risk lifetimes involved. (Returning a bare pointer and relying on

Re: Faster gecko builds with IceCC on Mac and Linux

It's way cheaper to get build clusters rolling than to get beefy hardware for every desk. Distributed compilation or other direct build optimizations also allow continued use of laptops for most devs, which definitely has value. On Wed, Jan 17, 2018 at 11:22 AM, Jean-Yves Avenard

Re: overly strict eslint rules

It's not just eslint either. We warn in static analysis now when using `!std::vector::size()` instead of `empty()`. Such over-prescriptive linting is unnecessary and unproductive. On Sun, Dec 24, 2017 at 2:07 PM, Masatoshi Kimura wrote: > > On 2017/12/25 6:31, Jonathan

Re: mozilla::Hash{Map,Set}

Awesome! What are the pros/cons to mozilla::Hash{Map,Set} vs std::unordered_{map,set}? I'm assuming perf is the main draw? Do we have a data on this too? On Mon, Aug 13, 2018 at 10:44 PM, Nicholas Nethercote wrote: > Hi, > > I recently moved Spidermonkey's js::Hash{Map,Set} classes from >

Re: Workaround for building with Visual Studio 15.7+

FWIW, I found that building with clang-cl works fine out-of-the-box with 15.7.x, and the Installer tells me that I don't have the 15.6 toolset installed. YMMV, but I've found that clang-cl builds Just Work with 15.7. On Thu, Aug 16, 2018 at 5:23 AM, Gabriele Svelto wrote: > Hello all, > being

Re: PSA: Avoid Visual Studio 2017 15.7.0

Consider instead building with clang-cl: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Building_Firefox_on_Windows_with_clang-cl If you build with clang-cl, you can keep the newest (gecko-incompatible) version of MSVC installed, which is particularly useful

Re: PSA: Major preference service architecture changes inbound

1PM -0700, Jeff Gilbert wrote: >> >> We should totally be able to afford the very low cost of a >> rarely-contended lock. What's going on that causes uncached pref reads >> to show up so hot in profiles? Do we have a list of problematic pref >> keys? > > &g

Re: PSA: Major preference service architecture changes inbound

as a future improvement? > > [1] https://searchfox.org/mozilla-central/source/xpcom/threads/RWLock.h > > On Thu, Jul 19, 2018 at 7:25 PM, Kris Maglione > wrote: >> >> On Thu, Jul 19, 2018 at 07:17:13PM -0700, Jeff Gilbert wrote: >>> >>> Using a clas

Re: PSA: Major preference service architecture changes inbound

We should totally be able to afford the very low cost of a rarely-contended lock. What's going on that causes uncached pref reads to show up so hot in profiles? Do we have a list of problematic pref keys? On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione wrote: > On Tue, Jul 17, 2018 at 02:06:48PM

Re: C++ standards proposal for a embedding library

It feels like the committee is burnt out on trying to solve the general library problem, but contemplating something massively complex like this instead doesn't follow, and is an answer to the wrong question. Make it easier to integrate libraries and we wouldn't see kludge proposals like this.

Re: minimum version of clang will become 3.9 soon.

I'm always happy for these updates! Thanks! On Sat, Sep 8, 2018 at 4:19 PM, wrote: > This is already practically the case as there are unfixed compilation errors > with clang 3.8 (https://bugzilla.mozilla.org/show_bug.cgi?id=1487810). > > Bug

Re: PSA: Visual Studio 2017 15.6 now required to build 61+

The patches have landed. Thanks! Are we ready to update this page?: https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code On Mon, Mar 12, 2018 at 5:29 PM, Ryan VanderMeulen wrote: > While I know I'm tempting fate by sending this out while the

  1   2   >