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.
>
> FWI
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 p
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
e:
> On Friday, 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
> >
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 a
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 hav
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 less
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 insi
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 code-smel
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 l
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`.
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 `m
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 of
wrapping (and its effects on
> 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
>
>
ce to have a natural 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:
> > I
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 a
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 “In
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 fo
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 A
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 hand
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
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1482196
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 am
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
> js/pub
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 if
ad
> access 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:
>>>
>>>
, Jul 17, 2018 at 03:49:41PM -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 pr
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.
On
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 +
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 Fr
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
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, despi
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 namespaces,
like 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
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 b
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 wrote:
> On Tue, Apr 10, 2018, at 7:56 AM, Jeff Gilbert wrote:
>> Can we not put mo
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. SVG anchor elements s
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 wrote:
> Bug 1444274 will bump our minimum GCC version to 6.1. GCC-7 will
> continue to work.
>
> If you build with GCC instead of Cl
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 GC
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 continue to scale up ou
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
https://lists.mozilla.or
other blockers, upgrading our GCC required version may
follow relatively quickly.
On Tue, Mar 13, 2018 at 1:34 PM, Jeff Gilbert wrote:
> 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
>
&g
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 patches are
> still on autoland,
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
wrote:
>
>
>> On
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
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 Kingston wrote:
>> It has w
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 aut
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 towar
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 nullptr
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 a requirement for py
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 thread
Avoid workstation GPUs if you can. At best, they're just a more
expensive consumer GPU. At worst, they may sacrifice performance we
care about in their optimization for CAD and modelling workloads, in
addition to moving us further away from testing what our users use. We
have no need for workstatio
os we have.
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 wrote:
> On 06/11/2017 22:44, Jeff Gilbert wrote
is not onerous.
On Mon, Nov 6, 2017 at 9:19 AM, Gregory Szorc wrote:
>
>
>> On Nov 6, 2017, at 05:19, Gabriele Svelto wrote:
>>
>>> On 04/11/2017 01:10, Jeff Gilbert wrote:
>>> Clock speed and core count matter much more than ECC. I wouldn't chase
>
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 a base clock of 4.0 Ghz, and for building
Our insistence on namespace-miming include directories stands in the way again.
On Wed, Oct 11, 2017 at 3:40 AM, Marco Bonardo wrote:
> See the previous pragma once proposal:
> https://groups.google.com/forum/#!msg/mozilla.dev.platform/PgDjWw3xp8k/PLYQc5xoWmsJ
>
> On Wed, Oct 11, 2017 at 11:45 AM
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
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 swit
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 there's
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 a
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 *everywhere* in the
>> g
Let's drop this side-topic from this thread.
On Thu, Feb 16, 2017 at 4:40 PM, Martin Thomson wrote:
> On Fri, Feb 17, 2017 at 10:39 AM, Robert O'Callahan
> wrote:
>>> Using clang-format on the entire tree has the massive value of:
>>
>> Also, it's very liberating not having to think about format
2017 at 3:25 PM, L. David Baron 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 tree has t
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:
>> reading this: (turn on
ean-Yves Avenard
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 chang
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 th
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, should &&/|| go at the end
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 start and give up before we
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 supported
> build config
Awesome, this sounds like what I was after. (though actual components
isn't really necessary. If that part is a pain point, I would prefer
to have a tool without it, than to have no tool)
On Wed, Jun 1, 2016 at 12:23 PM, Ted Mielczarek wrote:
> On Tue, May 31, 2016, at 09:26 PM, Jeff
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
wrote:
> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert wrote:
>>
>> Perhaps this isn't meant for me then? I looked a
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.
>
> Yes. Don't get hung up on the lack of annotat
On Tue, May 31, 2016 at 6:18 AM, Gabriele Svelto wrote:
> On 31/05/2016 13:26, Gijs Kruitbosch wrote:
>> We could do a find/replace of no-arg calls to a new macro that uses
>> MOZ_CRASH with a boilerplate message, and make the argument non-optional
>> for new uses of MOZ_CRASH? That would avoid th
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 fully-featured IDEs
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:
>
>> Hi,
>>
>> C++ constructors can't be made
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:
https://dxr.mozilla.org/mozilla-centra
On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley wrote:
> On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert 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 pointer (regardless of the fact
>> that th
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,
s
ed on name alone.
It would also add to our already-pungent code smell.
On Fri, Apr 8, 2016 at 3:03 PM, Mats Palmgren wrote:
> On 2016-04-08 23:03, Jeff Gilbert wrote:
>>
>> Strong preference against eFoo, here. :)
>
>
> Strong preference *for* eFoo, here. :)
>
> If
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 build infrastructure.
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 at 18:10, Kartika
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
making any claims myself
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
inves
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 Tu
, Jan 7, 2016 at 4:12 PM, Robert O'Callahan wrote:
> On Fri, Jan 8, 2016 at 11:08 AM, Jeff Gilbert wrote:
>>
>> 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 inte
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 like this would be possi
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 wish to show 2d graphics,
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 all
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 through it
> before the sig
On Thu, Jul 16, 2015 at 6:50 AM, Ehsan Akhgari
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
On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann
wrote:
> The discussion has a number of good points in favor of using 'a', but I
> missed convincing arguments in favor of not using 'a'. Are there any? I
> don't consider "I don't get what 'a' is good for" a convincing argument.
>
On the other
On Tue, Jul 14, 2015 at 9:17 PM, Nicholas Nethercote wrote:
> On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley
> 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 consistency is a major concern, so as long
On Sun, Jul 12, 2015 at 6:45 PM, Thomas Zimmermann
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 variable. If we want t
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 wrote:
> >
> > Arguments have the same lifetimes as locals, and the only exceptions to
> > this apply to both args and locals. (referen
On Wed, Jul 8, 2015 at 7:48 AM, smaug 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
> service notifica
On Mon, Jul 6, 2015 at 8:26 PM, Mike Hommey 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 widespread use in
On Tue, Jul 7, 2015 at 6:06 PM, Karl Tomlinson 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 a
On Tue, Jul 7, 2015 at 5:41 PM, Karl Tomlinson 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 i
On Tue, Jul 7, 2015 at 3:59 PM, Eric Rahm 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 shadowing issue
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 wrote:
> On 07/07/2015 11:18 PM, Jeff Gilbert wrote:
>
>> On Tue, Jul 7, 2015 at 1:03 PM, smaug wrote:
>>
1 - 100 of 136 matches
Mail list logo
