Re: reducing high try macosx pending counts

Thanks to everyone involved for accommodating the extra load from the stylo side - it's a necessary part of our ramp-up to shipping. Luckily, we should only be running the two configurations side-by-side for a month or two, after which point load should drop back down to normal levels. Thanks Kim

reducing high try macosx pending counts

You may have noticed that the time to wait for macosx test results on try has been very long (>1day) this week. [tracking] macosx test load is unsustainable https://bugzilla.mozilla.org/show_bug.cgi?id=1386625 There are several factors that contributed to this situation. 1) Additional macosx

Re: security problems [WAS: Intent to remove: sensor APIs]

On 02.08.2017 15:53, Blair MacIntyre wrote: FWIW, I wouldn’t mind being involved in a discussion about this, > if people want to seriously consider putting it behind a > "user-permission prompt" (similar to geolocation) or "user-action requirement” I'd even go further and move it to an

Re: sccache as ccache

On Wed, Aug 2, 2017, at 12:26 PM, Ben Kelly wrote: > On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek > wrote:>> Yesterday I published sccache 0.2 to > crates.io, so you can now `cargo>> install sccache` and get the latest > version (it'll install to >> ~/.cargo/bin). > >

Re: sccache as ccache

On Wed, Aug 2, 2017 at 12:26 PM, Ben Kelly wrote: > On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek > wrote: > >> Yesterday I published sccache 0.2 to crates.io, so you can now `cargo >> install sccache` and get the latest version (it'll install to >>

Re: Upcoming C++ standards meeting in Toronto, Canada

On Wed, Jul 5, 2017 at 7:55 PM, Botond Ballo wrote: > I will be there, hanging out in the Evolution Working > Group as usual, and blogging about the meeting afterwards. If you're interested in what happened at this meeting, my blog post about it is now live:

Re: Firefox startup code coverage (ts_paint talos test)

This is great, thanks so much Marco! This will likely be a useful way for us to find more opportunities to make start-up faster. Thanks for your work! On 2017-08-02 10:28 AM, Marco Castelluccio wrote: > Hello all, > at https://marco-c.github.io/ts_paint_startup_coverage_report/ you can > find a

Re: sccache as ccache

On Wed, Jul 26, 2017 at 9:05 AM, Ted Mielczarek wrote: > Yesterday I published sccache 0.2 to crates.io, so you can now `cargo > install sccache` and get the latest version (it'll install to > ~/.cargo/bin). > I tried this on my linux build machine today and got: error:

Re: Actually-Infallible Fallible Allocations

On 8/2/17 11:18 AM, Nathan Froyd wrote: In particular, the API of Sequence<> is constrained because it inherits from FallibleTArray, which *only* exposes fallible operations. We should consider just fixing this. The history here is that FallibleTArray and InfallibleTArray used to bake the

Re: Intent to remove: sensor APIs

On 02.08.2017 14:39, Blair MacIntyre wrote: It’s used for panoramic image viewing (orient the pano with the camera movement), and google street view uses it for similar motion control. Okay, why not adding a generic interface for controlling the virtual view direction ? So, the user/operator

Re: security problems [WAS: Intent to remove: sensor APIs]

> At least these things should be purely optional and providing an > *easy* way to filter that data. (same for the geolocation stuff). FWIW, I wouldn’t mind being involved in a discussion about this, if people want to seriously consider putting it behind a "user-permission prompt" (similar to

Intent to ship: CSS font-display descriptor

For Firefox 57, I intend to turn the CSS 'font-display' descriptor for @font-face rules on by default. This feature was developed behind the layout.css.font-display.enabled preference. Blink has already shipped this feature as of Chrome 60:

Re: Actually-Infallible Fallible Allocations

On Tue, Aug 1, 2017 at 12:31 PM, Alexis Beingessner wrote: > I was recently searching through our codebase to look at all the ways we > use fallible allocations, and was startled when I came across several lines > that looked like this: > > dom::SocketElement =

security problems [WAS: Intent to remove: sensor APIs]

On 02.08.2017 14:29, Michael Hoye wrote: You need to dial this rhetoric back about 100%. It is not acceptable to bring even an implied accusation like that to a technical discussion, or indeed any conversation at all, at Mozilla. Who did I accuse of what exactly ? All I'd like to say here is

Re: Intent to remove: sensor APIs

> On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre > wrote: >> Are we still talking about deviceorientation? > > As I said twice and Frederik repeated, we're not, other than asking if > anyone has a plan for how to make it interoperable. Yes, I know; I was just

Re: Actually-Infallible Fallible Allocations

On 08/01/2017 08:16 PM, Jim Blandy wrote: I have to ask: does anyone recall the benchmarks that showed that bounds checks or vector reallocations were a measurable performance hit in this code? Extra needless bounds checks certainly have shown up in profiles, for an example see

Re: Intent to remove: sensor APIs

On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre wrote: > Are we still talking about deviceorientation? As I said twice and Frederik repeated, we're not, other than asking if anyone has a plan for how to make it interoperable. Note that it's far from a W3C standard:

Re: Intent to remove: sensor APIs

Are we still talking about deviceorientation? It’s used to determine the 3D orientation of the device, so that we can tell the direction it is facing. Developers use it to render 3D graphics (WebGL or CSS3D using perspective DIV) around the user. e.g., look at one of my project samples, like

Re: refcounting [WAS: More Rust code]

On 8/2/2017 6:37 AM, Enrico Weigelt, metux IT consult wrote: On 31.07.2017 13:53, smaug wrote: Reference counting is needed always if both JS and C++ can have a pointer to the object. By the way - just curious: Anybody already thought about garbage collection ? Yes. About a decade ago,

./mach try fuzzy: A Try Syntax Alternative

I'm pleased to announce an alternative method for scheduling tasks on try is now landed on mozilla-central. It makes use of the awesome fzf [1] project to filter down the list of all task labels with a fuzzy matching algorithm. It works both with mercurial or git. If using mercurial, you'll need

Re: Intent to remove: sensor APIs

On Aug 2, 2017 15:54, "Enrico Weigelt, metux IT consult" < enrico.weig...@gr13.net> wrote: Making that information visible to websites (even worse: movement tracking via g-sensor, etc), definitively looks like security nightmare which even the Stasi never dared dreaming of. You need to dial

Firefox startup code coverage (ts_paint talos test)

Hello all, at https://marco-c.github.io/ts_paint_startup_coverage_report/ you can find a (C/C++-only for now) code coverage report of Firefox startup. The report was generated using the ts_paint talos test, considering code executed until the "MozAfterPaint" event and after a setTimeout(, 0). It

Re: Intent to remove: sensor APIs

On 02.08.2017 13:01, Salvador de la Puente wrote: I strongly encourage you to take a look at the telemetry stats regarding the usage of deviceorientation API and other. I don't know the penetration of proximity and ambient light APIs but deviceorientation is definitively used. Just curious:

Re: refcounting [WAS: More Rust code]

On Wed, Aug 2, 2017, at 08:32 AM, Nathan Froyd wrote: > On Wed, Aug 2, 2017 at 7:37 AM, Enrico Weigelt, metux IT consult > wrote: > > On 31.07.2017 13:53, smaug wrote: > >> Reference counting is needed always if both JS and C++ can have a > >> pointer to the object. > > >

Re: Intent to remove: sensor APIs

As mentioned in thread, we will not disable deviceorientation. Please see below. On 02.08.2017 15:01, Salvador de la Puente wrote: > I strongly encourage you to take a look at the telemetry stats regarding > the usage of deviceorientation API and other. I don't know the penetration > of proximity

Re: Intent to remove: sensor APIs

I strongly encourage you to take a look at the telemetry stats regarding the usage of deviceorientation API and other. I don't know the penetration of proximity and ambient light APIs but deviceorientation is definitively used. Please, consider twice before taking a final decision. El 31 jul.

Re: refcounting [WAS: More Rust code]

On Wed, Aug 2, 2017 at 7:37 AM, Enrico Weigelt, metux IT consult wrote: > On 31.07.2017 13:53, smaug wrote: >> Reference counting is needed always if both JS and C++ can have a >> pointer to the object. > > Anybody already thought about garbage collection ? Reference

Re: nodejs for extensions ?

On 31.07.2017 20:30, David Teller wrote: Node dependency trees tend to be pretty large, so I'm a little concerned here. Has the memory footprint be measured? That would also concern me (OTOH, moz's footprint already is as large as a small skyscraper anyways ;-)). We also have similar problems

refcounting [WAS: More Rust code]

On 31.07.2017 13:53, smaug wrote: Reference counting is needed always if both JS and C++ can have a pointer to the object. By the way - just curious: Anybody already thought about garbage collection ? That wouldn't have the problem w/ circular graphs, and should make the whole code

Stack walking in Gecko

Hi, We have multiple ways of getting stack traces, and it is hard to keep track of them all. I wrote down some notes that reflect my understanding, and I thought I'd share it in case it's useful, and in case people have ideas on how to improve things. Nick