Re: Adopting the black Python code style

2020-10-20 Thread Jeff Gilbert
Well we generally don't seek consensus anymore for these sorts of things, it seems, but it's reassuring that I'm not alone. On Tue, Oct 20, 2020 at 1:17 AM James Graham wrote: > > On 19/10/2020 22:01, Jeff Gilbert wrote: > > I'm disappointed by that. > > FWIW last time I looked

Re: Adopting the black Python code style

2020-10-19 Thread Jeff Gilbert
I'm disappointed by that. On Mon, Oct 19, 2020 at 2:00 PM Ricky Stewart wrote: > > On Monday, October 19, 2020 at 8:53:59 AM UTC-5, Andrew Halberstadt wrote: > > No, black now has a `--skip-string-normalization` flag, which I would be > > all for using in our code base. Not sure if that was the

Re: Please don't use locale-dependent C standard library functions (was: Re: Please don't use functions from ctype.h and strings.h)

2020-06-12 Thread Jeff Gilbert
It would be great to have CI linting for these! On Fri, Jun 12, 2020 at 2:19 AM Henri Sivonen wrote: > > This is an occasional re-reminder that anything in the C standard > library that is locale-sensitive is fundamentally broken and should > not be used. > > Today's example is strerr(), which

Re: To what extent is sccache's distributed compilation usable?

2019-10-25 Thread Jeff Gilbert
day, October 25, 2019 at 4:14:05 AM UTC+11, Jeff Gilbert wrote: > > My home Ryzen 3900x builds windows debug clobbers in under 10 minutes. > > Whoa, that's awesome! > > > Beefy desktops are relatively cheap, and I believe we continue to > encourage > > firefox-builder

Re: To what extent is sccache's distributed compilation usable?

2019-10-24 Thread Jeff Gilbert
My home Ryzen 3900x builds windows debug clobbers in under 10 minutes. Beefy desktops are relatively cheap, and I believe we continue to encourage firefox-builders to request desktop workstations for builds. On Wed, Oct 23, 2019 at 11:20 PM Marcos Caceres wrote: > On Thursday, October 24, 2019

Re: Using MozPhab without Arcanist

2019-10-23 Thread Jeff Gilbert
Likewise I use `phlay` on git. On Wed, Oct 23, 2019 at 1:35 PM Jörg Knobloch wrote: > On 23 Oct 2019 22:24, Emma Humphries wrote: > > Will this make it easier for non-staff contributors to get their change > > sets reviewed and landed? > > > > What else should we be doing for that. > > > > I

Re: C++ standards proposal for a embedding library

2019-10-22 Thread Jeff Gilbert
We that's bleak. Get pumped for a surge in "Download our desktop app for the full experience"! Rather than spending our limited resources giving guiding technical feedback to proposals we fundamentally oppose, I would rather see us putting effort into satisfying the target user stories with a

Re: Coding style: Naming parameters in lambda expressions

2019-09-06 Thread Jeff Gilbert
Notably, aFoo is neither Google nor Rust style. If we didn't already have aFoo as a style, we certainly wouldn't adopt it today. On Fri, Sep 6, 2019 at 6:59 AM Botond Ballo wrote: > On Fri, Sep 6, 2019 at 9:40 AM Andrew Sutherland > wrote: > > But of course, if this was all being done from

Re: Coding style: Naming parameters in lambda expressions

2019-09-05 Thread Jeff Gilbert
I remain against aFoo style. I still think it's low-signal-high-noise, and doesn't provide value that modern syntax highlighting doesn't provide for those who find it useful. I'm absolutely opposed to adding a new prefix. That would be moving even further down the path of our proprietary

Re: Upcoming C++ standards meeting in Cologne

2019-07-30 Thread Jeff Gilbert
I want to underline how insane this is: "...the groups which looked at [the web_view] proposal [...] largely viewed it favourably, a promising way of allow C++ applications to do things like graphical output without having to standardize a graphics API ourselves, as previously attempted." I feel

Re: non-const reference parameters in new and older code

2019-07-22 Thread Jeff Gilbert
I could grudgingly get on board with that, though I feel that there are sort of two levels of mutability I use: casual and essential. Essential is protected by constness, whereas casual is sort of everyday minor changes, but changes I don't want to allow in `const` code, thus don't want `mutable`.

Re: NotNull and pointer parameters that may or may not be null

2019-07-22 Thread Jeff Gilbert
FWIW RefPtr already behaves as MaybeNull for assert-on-deref, making them functionally Maybe. (though they don't represent a contract that it's nullable) For non-outvar-args, I tend to use references to document non-null, though I do so even for many non-const uses. (balancing what is and isn't

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

2019-07-05 Thread Jeff Gilbert
dom/canvas has enabled -Werror=implicit-int-conversion since 68! :) https://bugzilla.mozilla.org/show_bug.cgi?id=1540357 On Fri, Jul 5, 2019 at 11:15 AM Chris Peterson wrote: > > On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote: > >> FWIW once in a while I have come across bugs caused by truncation

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

2019-07-05 Thread Jeff Gilbert
gt; bug-finding tools and compiler optimizations). > `class Unsigned { int mValue; /* magic API here */ }` -- feels like unsigned, > but underneath it's all `int` arithmetics, with optional >=0 assertions. > Would that help? > > Gerald > > > On Friday, July 5, 2019 at 5:35:3

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

2019-07-04 Thread Jeff Gilbert
way to document which we expect /at compile time/. Saying "no unsigned types" really throws out the baby with the bathwater for me. On Thu, Jul 4, 2019 at 11:46 AM Botond Ballo wrote: > > On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote: > > It's a huge > >

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

2019-07-04 Thread Jeff Gilbert
I really, really like unsigned types, to the point of validating and casting into unsigned versions for almost all webgl code. It's a huge help to have a compile-time constraint that values can't be negative. (Also webgl has implicit integer truncation warnings-as-errors, so we don't really worry

Re: Changes to “ExposureGuidelines” (Intent to *)

2019-07-03 Thread Jeff Gilbert
I think "Intent to prototype" is a good clarity improvement, thanks! On Wed, Jul 3, 2019 at 2:48 AM Anne van Kesteren wrote: > > Hi all, > > In consultation with others I have made some adjustments to > https://wiki.mozilla.org/ExposureGuidelines. > > “Intent to implement” has been renamed to

Re: Moving reviews to Phabricator

2019-02-06 Thread Jeff Gilbert
FWIW, I have exactly one machine with everything set up, and git-fetch/push and ssh into it in order to push up or pull down from moz-central. On Wed, Feb 6, 2019 at 12:49 PM Jörg Knobloch wrote: > > On 06/02/2019 21:42, Kim Moir wrote: > > On February 28 Bugzilla review flags will be disabled

Re: Intent to Desupport: Fennec Automated Updates (when Sideload Installed)

2019-02-05 Thread Jeff Gilbert
Did we figure out how to tell users they're not going to get updates anymore? I don't see a resolution in that PR. This used to be the only way to get Nightly, so I'd expect long time users to be surprised. I only stopped using the downloaded APK last year, I think. On Tue, Feb 5, 2019 at 10:04

Re: C++ method definition comments

2019-01-28 Thread Jeff Gilbert
I would much rather revert to: /*static*/ void Foo::Bar() The Foo::Bar is the most relevant part of that whole expression, which makes it nice to keep up against the start of the line. In a clang-format world, we should feel more free to make such deviations from Google Style, since it's all

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

2018-09-17 Thread Jeff Gilbert
I would be excited for something between MOZ_ASSERT and MOZ_CRASH, but I think raising MOZ_ASSERTs to MOZ_ASSERT_NIGHTLY should be done by hand and reviewed. On Mon, Sep 17, 2018 at 11:46 AM, Kris Maglione wrote: > There are some non-trivial snags for this proposal. A lot of assertions rely > on

Re: minimum version of clang will become 3.9 soon.

2018-09-10 Thread Jeff Gilbert
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: Workaround for building with Visual Studio 15.7+

2018-08-16 Thread Jeff Gilbert
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: mozilla::Hash{Map,Set}

2018-08-15 Thread Jeff Gilbert
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: PSA: Avoid Visual Studio 2017 15.7.0

2018-08-06 Thread Jeff Gilbert
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

2018-07-20 Thread Jeff Gilbert
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

2018-07-19 Thread Jeff Gilbert
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: C++ standards proposal for a embedding library

2018-07-18 Thread Jeff Gilbert
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: PSA: Major preference service architecture changes inbound

2018-07-17 Thread Jeff Gilbert
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: Coding style: Making the `e` prefix for enum variants not mandatory?

2018-06-29 Thread Jeff Gilbert
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?

2018-06-25 Thread Jeff Gilbert
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

2018-06-20 Thread Jeff Gilbert
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,

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

2018-06-07 Thread Jeff Gilbert
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

2018-05-29 Thread Jeff Gilbert
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: Update on rustc/clang goodness

2018-05-29 Thread Jeff Gilbert
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: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

2018-04-09 Thread Jeff Gilbert
from embedding pings (et al) in images? I suppose we better have been handling CORS requests from within SVGs properly already, so it should Just Work? On Mon, Apr 9, 2018 at 6:26 PM, Cameron McCormack <c...@mcc.id.au> wrote: > On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote:

Re: Intent to implement and ship: ping, rel, referrerPolicy, relList, hreflang, type and text properties on SVG elements

2018-04-09 Thread Jeff Gilbert
Can we not put more things into SVG? Making SVG more complicated seems like it should be an anti-goal for the web platform. On Mon, Apr 9, 2018 at 2:11 PM, wrote: > Summary: HTML anchor elements have ping, rel, referrerPolicy, relList, > hreflang, type and text properties.

Re: PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+

2018-04-05 Thread Jeff Gilbert
I have updated our table: https://developer.mozilla.org/en-US/docs/Mozilla/Using_CXX_in_Mozilla_code On Mon, Apr 2, 2018 at 5:30 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote: > Bug 1444274 will bump our minimum GCC version to 6.1. GCC-7 will > continue to work. > > If you buil

PSA: Building Firefox 61+ with GCC will soon require version GCC 6.1+

2018-04-05 Thread Jeff Gilbert
Bug 1444274 will bump our minimum GCC version to 6.1. GCC-7 will continue to work. If you build with GCC instead of Clang on Linux, I've been told that the system gcc package for Ubuntu 16.04 LTS is gcc-5, so very soon you'll need to install a gcc-6 package to continue to build. With a bump to

Re: CPU core count game!

2018-03-31 Thread Jeff Gilbert
Are these actual "physical cores", or is this "hardware threads"? There's very big difference between 2 and 2+HT these days. On Tue, Mar 27, 2018 at 2:02 PM, Mike Conley wrote: > Thanks for drawing attention to this, sfink. > > This is likely to become more important as we

Blockers for GCC 6?

2018-03-14 Thread Jeff Gilbert
I have a bug to track updating our requirement to GCC 6: https://bugzilla.mozilla.org/show_bug.cgi?id=1444274 Are there any other dependents that require GCC 4.9 still? ___ dev-platform mailing list dev-platform@lists.mozilla.org

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

2018-03-13 Thread Jeff Gilbert
blockers, upgrading our GCC required version may follow relatively quickly. On Tue, Mar 13, 2018 at 1:34 PM, Jeff Gilbert <jgilb...@mozilla.com> wrote: > The patches have landed. Thanks! > > Are we ready to update this page?: > https://developer.mozilla.org/en-US/docs/Mozilla/Using_C

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

2018-03-13 Thread Jeff Gilbert
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

Re: Faster gecko builds with IceCC on Mac and Linux

2018-01-17 Thread Jeff Gilbert
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: Hiding 'new' statements - Good or Evil?

2018-01-04 Thread Jeff Gilbert
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: overly strict eslint rules

2017-12-27 Thread Jeff Gilbert
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: Hiding 'new' statements - Good or Evil?

2017-11-28 Thread Jeff Gilbert
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: Hiding 'new' statements - Good or Evil?

2017-11-27 Thread Jeff Gilbert
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?

2017-11-23 Thread Jeff Gilbert
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: Intent to require Python 3 to build Firefox 59 and later

2017-11-13 Thread Jeff Gilbert
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)

2017-11-07 Thread Jeff Gilbert
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)

2017-11-06 Thread Jeff Gilbert
. 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)

2017-11-06 Thread Jeff Gilbert
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)

2017-11-03 Thread Jeff Gilbert
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

Re: Follow up on clang-format

2017-09-29 Thread Jeff Gilbert
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: Coding style: `else for` or `else { for... }`?

2017-08-30 Thread Jeff Gilbert
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: windows build anti-virus exclusion list?

2017-04-20 Thread Jeff Gilbert
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: Faster gecko builds with IceCC on Mac and Linux

2017-03-23 Thread Jeff Gilbert
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

2017-03-21 Thread Jeff Gilbert
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: Should &&/|| really be at the end of lines?

2017-02-16 Thread Jeff Gilbert
, 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?

2017-02-16 Thread Jeff Gilbert
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?

2017-02-16 Thread Jeff Gilbert
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?

2017-02-16 Thread Jeff Gilbert
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: Should &&/|| really be at the end of lines?

2017-02-16 Thread Jeff Gilbert
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: Changing the representation of rectangles in platform code

2017-02-10 Thread Jeff Gilbert
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

2016-08-23 Thread Jeff Gilbert
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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

2016-06-01 Thread Jeff Gilbert
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: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

2016-06-01 Thread Jeff Gilbert
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

2016-05-31 Thread Jeff Gilbert
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: Generating Visual Studio project files by default

2016-05-24 Thread Jeff Gilbert
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: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

2016-04-21 Thread Jeff Gilbert
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: Proposal: use nsresult& outparams in constructors to represent failure

2016-04-21 Thread Jeff Gilbert
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: Coding style for C++ enums

2016-04-11 Thread Jeff Gilbert
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

2016-04-11 Thread Jeff Gilbert
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: Coding style for C++ enums

2016-04-08 Thread Jeff Gilbert
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: Build System Project - Update from the last 2 weeks

2016-04-08 Thread Jeff Gilbert
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

2016-04-08 Thread Jeff Gilbert
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: Proposing preferring Clang over GCC for developer buidls

2016-03-02 Thread Jeff Gilbert
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: Proposing preferring Clang over GCC for developer buidls

2016-03-02 Thread Jeff Gilbert
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: A list of easy-ish gfxContext-to-DrawTarget conversions

2016-01-12 Thread Jeff Gilbert
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: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

2016-01-07 Thread Jeff Gilbert
, 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

2016-01-07 Thread Jeff Gilbert
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: "-Moz-Element" -like API by extending WEBGL_dynamic_texture

2016-01-04 Thread Jeff Gilbert
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

2016-01-04 Thread Jeff Gilbert
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: Dan Stillman's concerns about Extension Signing

2015-11-25 Thread Jeff Gilbert
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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

2015-07-16 Thread Jeff Gilbert
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: Switch to Google C++ Style Wholesale (was Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++)

2015-07-15 Thread Jeff Gilbert
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++

2015-07-13 Thread Jeff Gilbert
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++

2015-07-13 Thread Jeff Gilbert
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++

2015-07-09 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

2015-07-07 Thread Jeff Gilbert
On Tue, Jul 7, 2015 at 12:36 PM, Honza Bambas hbam...@mozilla.com wrote: On 7/7/2015 21:27, Jeff Gilbert wrote: 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

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

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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++

2015-07-07 Thread Jeff Gilbert
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

  1   2   >