Re: Dropping support for VS2013

> On Jul 7, 2016, at 09:55, Gregory Szorc wrote: > > On Thu, Jun 30, 2016 at 5:55 PM, Gregory Szorc wrote: > >> On Tue, May 31, 2016 at 4:22 PM, Gregory Szorc wrote: >> >>> Heads up: we'll soon be dropping support for building mozilla-central >>> with VS2013. Bug 1186064 tracks and the patch

Re: Mercurial performance (vs git)

Printing dirty state would require a potentially expensive filesystem operation to see if the working directory is modified. Your shell prompt can either be consistently fast or randomly slow'ish. Pick 1. FWIW on a clean working directory on my machine: 1000+ms `hg status` or `git status` if the

Re: Mercurial performance (vs git)

This looks really great until I realized it did not print dirty state. There is probably no way to get the state without, say, `git status --porcelain --u=no`, right? On Tue, Aug 16, 2016 at 4:09 AM, Gregory Szorc wrote: > I use Facebook's scm-prompt.sh from > https://bitbucket.org/facebook/hg-

PSA: nsCSSProperty is being renamed to nsCSSPropertyID -- local patches may need updates

Just a heads-up, for anyone working on layout / style-system-related code: In bug 1293739 [1], Jonathan Chan has some patches that will rename the enumerated type "nsCSSProperty" to now be named "nsCSSPropertyID" (adding the "ID" suffix). I plan on landing his patches on inbound later today. It's

Re: Mercurial performance (vs git)

On Monday, August 15, 2016 at 1:12:51 PM UTC-7, Matthew N. wrote: > Make sure you have enabled the fsmonitor[1] extension for mercurial if > your prompt is using `hg` commands. I believe `mach mercurial-setup` now > helps with this. Ugh, that helps as hell! I installed watchman and turned on fs

Neo - Platform Operations Project of the Month

Hello from Platform Operations! Every month we highlight one of our projects to help the Mozilla community discover a useful tools or interesting contribution opportunity. This month's project is Neo! Neo is a tool for creating and building React web apps with zero initial configuration and minima

Re: Mercurial performance (vs git)

Make sure you have enabled the fsmonitor[1] extension for mercurial if your prompt is using `hg` commands. I believe `mach mercurial-setup` now helps with this. Matthew N. (:MattN) [1] https://www.mercurial-scm.org/wiki/FsMonitorExtension On 2016-08-15 12:46 PM, Botond Ballo wrote: Cross-pos

Re: Mercurial performance (vs git)

I use Facebook's scm-prompt.sh from https://bitbucket.org/facebook/hg-experimental/src/3a45413794a0252a817e7e1fda02182658b85183/scripts/scm-prompt.sh. It works with both Git and Mercurial and is fast because it pokes at the repo internals directly instead of going through `git` or `hg`. On Mon, Au

Re: Mercurial performance (vs git)

When I use https://gist.github.com/mikedeboer/fa806e2868c5962b9741715e5fd762d5 (homegrown script that evolved over years) I get instant results. I didn’t measure its perf. It might suit your needs, it might not. It comes with

Re: Mercurial performance (vs git)

Cross-posting to dev-version-control On Mon, Aug 15, 2016 at 3:39 PM, wrote: > For the last few months I've been mostly using git clone of mozilla-central > because I'm used to git. Now I'm trying to set up my mercurial environment to > match what I have for git in order to reduce the bias tow

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Mon, Aug 15, 2016 at 11:59 AM, Bobby Holley wrote: > On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen > wrote: > >> What I'm asking is: >> >> When I take encoding_rs_cpp.h and adapt it to XPCOM/MFBT types for use >> in Gecko, should this be >> Encoding::for_label(const nsACString& label) // ch

Mercurial performance (vs git)

For the last few months I've been mostly using git clone of mozilla-central because I'm used to git. Now I'm trying to set up my mercurial environment to match what I have for git in order to reduce the bias toward the latter. One of the crucial parts of my workflow is the git completion shell p

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Aug 15, 2016 21:59, "Bobby Holley" wrote: > > On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen wrote: >> >> On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote: >> > We're using Cheddar to produce C headers for our Rust mp4parse crate; as far >> > as I can see, Cheddar doesn't mangle Rust names.

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Mon, Aug 15, 2016 at 9:56 AM, Henri Sivonen wrote: > Relatedly, on the topic of MFBT Range and GSL, under the subject "C++ > Core Guidelines" Jim Blandy wrote: >> One of the main roles of MFBT is to provide polyfills for features >> standardized in C++ that we can't use yet for toolchain reaso

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Mon, Aug 15, 2016 at 11:53 AM, Henri Sivonen wrote: > On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote: > > We're using Cheddar to produce C headers for our Rust mp4parse crate; as > far > > as I can see, Cheddar doesn't mangle Rust names. > > > > The Mozilla C++ style applies only to identi

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

On Mon, Aug 15, 2016 at 6:45 PM, Jim Blandy wrote: > We're using Cheddar to produce C headers for our Rust mp4parse crate; as far > as I can see, Cheddar doesn't mangle Rust names. > > The Mozilla C++ style applies only to identifiers defined in Mozilla's C++ > code base, not things that we merely

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

I agree with Jim that the introduction of Rust code doesn't fundamentally alter the dynamic of our style conventions. We're not going to get consistency with all upstream projects and bound languages no matter what convention we pick, and changing mozilla style would be hugely disruptive. Regardin

Re: Intent to implement and ship: SVGElement.prototype.dataset

On Thu, Aug 11, 2016 at 12:53 AM, Boris Zbarsky wrote: > Summary: HTML elements have a .dataset property that allows convenient > somewhat structured access to data-* attributes. The proposal is to add > this to SVG elements too, following corresponding changes in the SVG > specification. Why do

Fwd: PLANNED week ending 2016-08-21 people.m.o (Tue) and Tree Closing Window (Sat)

FYI, TCW Next Saturday, Aug 20, 1300 UTC -> 2000 UTC Correct tracking bug number is https://bugzilla.mozilla.org/show_bug.cgi?id=1289548 -- Forwarded message -- From: m...@mozilla.com Date: Mon, Aug 15, 2016 at 8:53 AM Subject: PLANNED week ending 2016-08-21 people.m.o (Tue) and

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

tl;dr: There's a reason it's called "mangling"... On Mon, Aug 15, 2016 at 8:45 AM, Jim Blandy wrote: > I suggest that we start allowing snake_case C++ in m-c so that C++ >> wrappers for the C interfaces to Rust code can be named with mere >> copy-paste of the Rust method names and so that we don

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

> > I suggest that we start allowing snake_case C++ in m-c so that C++ > wrappers for the C interfaces to Rust code can be named with mere > copy-paste of the Rust method names and so that we don't need to > change naming style of GSL stuff regardless of whether what's in the > tree is a Mozilla po

snake_case C++ in m-c (was: Re: C++ Core Guidelines)

We've already established that Rust code in m-c will use the Rust coding style, so we'll have snake_case methods and functions in Rust code in m-c. Also, Rust code that exposes an FFI interface typically does so with snake_case functions, which look natural both for Rust and for C as C style is inf

Re: Return-value-optimization when return type is RefPtr

On Mon, Aug 15, 2016 at 3:55 PM, Aryeh Gregor wrote: > IMO, it makes sense to move ahead with this. One more point I forgot to (re-?)mention: with proper move constructors, it's not just already_AddRefed return values that should be changed to RefPtr, but also T* return values, in the case where

Re: Return-value-optimization when return type is RefPtr

Sorry for the necroposting, but some points that I think are still worth correcting: On Thu, Jun 16, 2016 at 11:50 AM, Boris Zbarsky wrote: > On 6/16/16 3:15 AM, jww...@mozilla.com wrote: >> >> I think that is the legacy when we don't have move semantics. Returning >> RefPtr won't incur ref-count