Re: More Rust code

[Henri Sivonen]

I guess I buried my questions in too long a post, so extracting them:

On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen  wrote:
> Naïvely, one would think that it should be possible to do that with
> clang producing "object files" holding LLVM IR and rustc producing
> "object files" holding LLVM IR and the "link" step involving mashing
> those together, running LLVM optimizations again and then producing
> machine code from a massive collection of mashed-together LLVM IR.
...
> If we were compiling C++ using clang on all platforms, how far off
> would such cross-language inlining be?
>
> If we could have the cross-language inlining benefit from compiling
> C++ using clang on all platforms, how far off would we be from being
> able to switch to clang on all platforms?
...
>  2) Rust code reading from the DOM when the DOM is guaranteed not to change.
...
> I've been talking about wishing to rewrite our DOM serializers (likely
> excluding the one we use for innerHTML in the document is in the HTML
> mode) in Rust. I have been assuming that such work could reuse the
> code that Stylo of has for viewing the DOM from Rust in a read-only
> stop-the-world  fashion.
>
> I haven't actually examined how reusable that Stylo code is for
> non-Stylo purposes. Is it usable for non-Stylo purposes?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: EME support on insecure contexts

[Chris Pearce]

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.

Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1322517

Link to standard:
https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

The EME spec requires that EME only be usable from a secure context, e.g., on 
origins served over HTTPS, and not those served over HTTP.

EME is a powerful feature which makes use of sandboxed closed source CDMs which 
send messages (relayed via the JavaScript video player) to third party servers, 
and the risks are greater if the transport is not encrypted.

Chrome has already removed support for EME on insecure origins in M58:
https://www.chromestatus.com/feature/5724389932793856

Firefox is already logging a deprecation warning to the WebConsole when EME is 
used on an insecure origin (bug 1361000), and we have telemetry to track 
whether EME requests are made in a secure or insecure context:
https://mzl.la/2hsC7Dq

Timeframe:
I am hoping we can remove EME on insecure origins in Q4 2017 or Q1 2018.

Our telemetry shows about 8% of sites using EME are still in insecure contexts, 
and I'd prefer to see that number lower before we disable EME in insecure 
contexts. Given that Chrome have already removed their support for EME in 
insecure contexts, I expect this telemetry to show improvement quickly.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Actually-Infallible Fallible Allocations

[Valentin Gosu]

On 3 August 2017 at 23:12, Jim Blandy  wrote:

>
> But my question wasn't, "is pre-reservation ever valuable?" but rather "is
> it valuable in this particular code?" My assumption is that most code isn't
> performance-sensitive, and so simplicity should be the priority.
>
> The code Alexis cited at the top of the thread is here:
> http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f55
> 4da0b89a33/netwerk/base/Dashboard.cpp#435
>
> Is Dashboard performance-sensitive?
>

Not really.
When I wrote the code I copied most of it from code automatically generated
by webidl.
Some things have changed in the meantime - such as fallible allocations -
maybe we should update to resemble something a human would write :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Actually-Infallible Fallible Allocations

[Jim Blandy]

On Wed, Aug 2, 2017 at 7:58 AM, Ehsan Akhgari 
wrote:

> Vector reallocations show up in profiles all the time, literally in more
> than half of the profiles I look at every day.  If you examine for example
> the large dependency graph of https://bugzilla.mozilla.org/s
> how_bug.cgi?id=Speedometer_V2, a large number of optimizations that are
> landing every day are merely removing various types of extra needless
> buffer reallocations we have in profiles.


Okay, that's a surprise to me, and definitely something I will try to keep
in mind.

But my question wasn't, "is pre-reservation ever valuable?" but rather "is
it valuable in this particular code?" My assumption is that most code isn't
performance-sensitive, and so simplicity should be the priority.

The code Alexis cited at the top of the thread is here:
http://searchfox.org/mozilla-central/rev/f0e4ae5f8c40ba742214e89aba3f554da0b89a33/netwerk/base/Dashboard.cpp#435

Is Dashboard performance-sensitive?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: reducing high try macosx pending counts

[Andrew Halberstadt]

Using the new |mach try fuzzy| selector will also make it a lot easier to
only schedule exactly what you need. To run what the above try syntax uses,
do:

$ ./mach try fuzzy
!osx 'web-platform 

That will run every task that doesn't contain the string 'osx', and does
contain the string 'web-platform'.

On Thu, Aug 3, 2017 at 3:51 AM James Graham  wrote:

> On 02/08/17 22:30, Kim Moir wrote:
> > You may have noticed that the time to wait for macosx test results on try
> > has been very long (>1day) this week.
> >
> > We have taken the following steps to address this problem
> [...]
>
> That sounds great! Thanks.
>
> For everyone else:
>
> It looks like the queues are still pretty long, and I imagine there are
> lots of pending jobs people scheduled that aren't really necessary any
> more (e.g. because you already found issues with a patch on other
> platforms, or landed in spite of the missing results).
>
> If you have a try push which requested OSX jobs, but you don't need them
> now, it would help if you go back and cancel the remaining jobs for that
> push from treeherder (look for the grey circle with a cross inside in
> the top right of the push to cancel all unfinished jobs, and the similar
> icon in the bottom panel for individual jobs). Also if you are making
> new try pushes and don't specifically need OSX testing, it's possible to
> limit tests to certain platforms with try syntax like (for running tests
> on linux64 and linux64-stylo only):
>
> try: -b do -p all -u web-platform-tests[x64,linux64-stylo]
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: reducing high try macosx pending counts

[James Graham]

On 02/08/17 22:30, Kim Moir wrote:

You may have noticed that the time to wait for macosx test results on try
has been very long (>1day) this week.

We have taken the following steps to address this problem

[...]

That sounds great! Thanks.

For everyone else:

It looks like the queues are still pretty long, and I imagine there are 
lots of pending jobs people scheduled that aren't really necessary any 
more (e.g. because you already found issues with a patch on other 
platforms, or landed in spite of the missing results).


If you have a try push which requested OSX jobs, but you don't need them 
now, it would help if you go back and cancel the remaining jobs for that 
push from treeherder (look for the grey circle with a cross inside in 
the top right of the push to cancel all unfinished jobs, and the similar 
icon in the bottom panel for individual jobs). Also if you are making 
new try pushes and don't specifically need OSX testing, it's possible to 
limit tests to certain platforms with try syntax like (for running tests 
on linux64 and linux64-stylo only):


try: -b do -p all -u web-platform-tests[x64,linux64-stylo]

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform