Re: Proposed W3C Charter: Hardware Security Working Group

I'm currently planning to submit the following as a comment on the charter (mostly based on what Richard wrote, but somewhat reworded). Please let me know if you think this needs rewording. -David [X] Opposes this charter and requests that the group not be created [Formal Objection] The

Re: Proposed W3C Charter: Pointer Events Working Group

On Wednesday 2016-03-02 07:34 -0800, Matt Brubeck wrote: > I think that Mozilla should comment in favor of the PEWG charter. Mozilla has > been participating in the WG and it is doing important work for interop and > performance of pointer input handling. OK, I'll vote in support of the

Re: Submit to MozReview using Git

Thanks for the pointer! I ended up re-do the cloning from hg instead. I would recommend the mozreview docs points to these document and explicit states the origin of local clone mozreview is supposedly to work with. Tim On Wed, Mar 2, 2016 at 6:13 PM, Ting-Yu Lin wrote: > >

Re: Proposing preferring Clang over GCC for developer buidls

Note that, as you say, the debugging information produced by the compiler and the debugger that consumes it are completely orthogonal. I've tried several times to use lldb but I keep coming back to GDB. Particularly now with RR+GDB it's light years ahead. I find that GDB works quite well with the

Re: Proposing preferring Clang over GCC for developer buidls

On Thu, Mar 3, 2016 at 6:50 AM, Gregory Szorc wrote: > Over in bug 1253064 I'm proposing switching developer builds to prefer > Clang over GCC because the limited numbers we have say that Clang can build > mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my

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: Proposing preferring Clang over GCC for developer buidls

On Thu, Mar 3, 2016 at 10:45 AM, Mike Hommey wrote: > More importantly, changing the official toolchain has implications on > performance. Without any real evidence for this, I'm told that GCC still produces better (i.e., faster) output. But we could switch try builds to

Re: Proposing preferring Clang over GCC for developer buidls

Is the debugging information generated by clang as good or better than GCC's? My experience with lldb has been terrible, but that may have more to do with the debugger itself than with the information clang generates. -Bill On Wed, Mar 2, 2016 at 2:50 PM, Gregory Szorc wrote:

Re: Proposing preferring Clang over GCC for developer buidls

On Wed, Mar 02, 2016 at 03:21:14PM -0800, Gregory Szorc wrote: > On Wed, Mar 2, 2016 at 3:15 PM, Jeff Gilbert wrote: > > > For standard development builds, --enable-debug build speed is (to me) > > the primary motivator since we've guaranteed that they're equally > >

Re: Proposing preferring Clang over GCC for developer buidls

On Wed, Mar 2, 2016 at 3:15 PM, Jeff Gilbert wrote: > 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

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

Proposing preferring Clang over GCC for developer buidls

Over in bug 1253064 I'm proposing switching developer builds to prefer Clang over GCC because the limited numbers we have say that Clang can build mozilla-central several minutes faster than GCC (13 minutes vs 17.5 on my I7-6700K). I'm not proposing switching what we use to produce builds in

Re: Intent to implement: DOM Push API in Firefox for Android

This is great. As I said elsewhere, I don't think that we can pref this on until bug 1252650 lands. It turns out that "gecko not running" is pretty much the only interesting state for push. On Thu, Mar 3, 2016 at 5:06 AM, Nicholas Alexander wrote: > Summary: "The Push

Re: Intent to implement: DOM Push API in Firefox for Android

This would be extremely useful for Project Link and, I assume, other Connected Devices projects. Cheers, David On 02/03/16 19:06, Nicholas Alexander wrote: > Summary: "The Push API gives web applications the ability to receive > messages pushed to them from a server, whether or not the web app

Intent to implement: DOM Push API in Firefox for Android

Summary: "The Push API gives web applications the ability to receive messages pushed to them from a server, whether or not the web app is in the foreground, or even currently loaded, on a user agent. This lets developers deliver asynchronous notifications and updates to users that opt in,

Re: Proposed W3C Charter: Pointer Events Working Group

I think that Mozilla should comment in favor of the PEWG charter. Mozilla has been participating in the WG and it is doing important work for interop and performance of pointer input handling. ___ dev-platform mailing list

Re: APNG and Accept-Encoding

I think now, in 2010s most of internet content is made by regular users, not webdevs. Can we look at the problem from their perspective? Of course, CDNs and webdevs care about MIME types and Accept headers, but regular users know nothing about that and they've been happily posting apngs to

Re: Talos e10s dashboard

I've just visited guardian.co.uk, *(Bug 1252822* ) scrolling seems quite bad... :( On Wed, Mar 2, 2016 at 12:29 AM, Chris Peterson wrote: > On 3/1/16 9:57 AM, William Lachance wrote: > >> Also, mconley suggested being

Re: firefox-ui-tests are now in mozilla-central with TaskCluster support

Matthew N. wrote on 03/01/2016 06:18 PM: > Could you give an overview of what is tested by this suite and how it > differs from mochitest-browser-chrome? It seems one difference is that > some(?) tests run on non-en-US. So Andrew already told a lot, and just to emphasize here we really do not

Re: Submit to MozReview using Git

> ~/repo/gecko/gecko-dev master$ git mozreview configure > searching for appropriate review repository... > warning: error trying to resolve Mercurial changesets I saw the same error before. After setting mozilla-central in my git repo remote described in the following wiki, I can setup review

Re: Submit to MozReview using Git

Hi :gps, I am following the description here and try to set up git-mozreview on my local gecko-dev clone. Here is the error I got: ~/repo/gecko/gecko-dev master$ git mozreview configure searching for appropriate review repository... warning: error trying to resolve Mercurial changesets Could