I agree that disabling for chrome is the right thing here over prefs. I
want Nightly and DevEdition to have stage 3+ TC39 proposals unflagged and
ready to play with -- asking folks to turn on prefs to do that is not the
way to go here from my perspective.
Benjamin's concern is legit, though, so le
restrictions will be lifted when the
proposal fully matures to be in the next standard.
*PLEASE DO NOT USE ASYNC GENERATORS IN CHROME CODE.*
On Mon, Mar 27, 2017 at 9:31 AM, Shu-yu Guo wrote:
> I agree that disabling for chrome is the right thing here over prefs. I
> want Nightly and DevEdition t
No evidence either way. Given we've had non-compat parameter defaults for a
while, your worry is legit. We'll deal with web compat issues with JS as it
comes up -- unfortunately the reality is that until we ship something, we
have very little idea if it's breaking.
On Fri, Oct 7, 2016 at 8:14 AM,
Good catch and thanks for the correction! The take-home from the example is
that: due to the global lexical scope, a TDZ error could arise later due to
newly introduced bindings.
On Thu, Sep 17, 2015 at 7:34 PM, Boris Zbarsky wrote:
> On 9/17/15 8:26 PM, Shu-yu Guo wrote:
>
>> Th
(Isn't that bananas, by the way?)
On Thu, Sep 17, 2015 at 5:26 PM, Shu-yu Guo wrote:
> On Thu, Sep 17, 2015 at 5:18 PM, Neil wrote:
>
>> Shu-yu Guo wrote:
>>
>> 4. The global lexical scope is extensible. This means dynamic scope
>>> (lol!):
>&g
On Thu, Sep 17, 2015 at 5:18 PM, Neil wrote:
> Shu-yu Guo wrote:
>
> 4. The global lexical scope is extensible. This means dynamic scope (lol!):
>>
>>
>> function f() { dump(x); }
>> f(); // prints undefined
>>
>>
>>
>> let x = 42;
Hello all,
We are in the process of implementing the global lexical scope per ES6.
This changes the semantics of global level 'let' and 'const' bindings from
our non-standard semantics to standard semantics.
Currently, global 'let' and 'const' bindings introduce properties onto the
global objec
I landed bug 1154115 today, which changes the format of the JSON spit out
by the Gecko profiler. If the patches stick, the Gecko Profiler Addon and
Cleopatra will be broken until they are updated.
I have submitted pull requests to the two repos.
In the meantime, you may elect to use my version of
To build off this idea, I'd like a "run-until-failure" mode (with an upper
limit, of course) on try itself. I don't want to spend N+ hours spinning my
CPU locally to repro an intermittent. I also don't want to wait until a
build is done to press the retrigger button 40 times.
My blue-sky wish woul
I'm with Jeff on this one. I'm very much against special casing add-on code --
which will invariably develop into another compatibility to break when we
finally do decide to break it.
- Original Message -
From: "Jeff Walden"
To: dev-platform@lists.mozilla.org
Sent: Friday, September 19,
Peterson"
To: dev-platform@lists.mozilla.org
Sent: Wednesday, September 17, 2014 4:37:17 PM
Subject: Re: ES6 lexical temporal dead zone has landed on central
On 9/15/14 4:43 PM, Shu-yu Guo wrote:
> If you work with JS that contains `let` bindings, you may start encountering
> the followi
Hello all,
Today I landed bug 1001090 (assuming it doesn't bounce), implementing ES6
lexical temporal dead zone for function-level `let` declarations, on
mozilla-central. As a refresher on the email I sent on Aug. 13, this is a
backwards-incompatible change.
Everything inside mozilla-central need
very unsavory.
- Original Message -
From: "Ehsan Akhgari"
To: "Shu-yu Guo" , dev-platform@lists.mozilla.org,
dev-g...@lists.mozilla.org
Cc: "Jorge Villalobos"
Sent: Wednesday, August 13, 2014 2:45:17 PM
Subject: Re: Non-backward compatible changes to J
Hello all,
We are in the process of making JS 'let' semantics ES6-compliant in
SpiderMonkey. I hope to land bug 1001090 sometime this month or early next
month (I've been told there's a B2G uplift on Sept 1st), which is one of many
for ES6 'let'-compliance. It changes 'let' semantics in two non-ba
Hi Katelyn,
I'm going to refer to what you're talking about with cloning and monomorphism
as the "context sensitivity problem". As far as I know, this is still an open
problem (not in the fundamental sense, just that nobody has a good solution for
it yet) in the JS JITs. The argument types (cou
15 matches
Mail list logo
