Just entered a bug, experiencing the same symptom.
—Claude
Le 29 avr. 2014 à 00:40, Michael Dyck jmd...@ibiblio.org a écrit :
For the past couple of days, when I create or modify a bug on
bugs.ecmascript.org, my browser doesn't get a response. I know
the requests are being received, because
On Fri 25 Apr 2014 17:14, Filip Pizlo fpi...@apple.com writes:
It's just a matter of common sense that JS implementations move to
totally-free entry/exit into try-catch and a sensible cost model for
when you throw, regardless of how this proposal goes. The fact that
either of these things is
On Fri 25 Apr 2014 16:22, Domenic Denicola dome...@domenicdenicola.com writes:
(2) not well-motivated according to some participants of the
discussion (e.g., it's not necessarily a good idea to rely on
finally-blocks for scarce resource management in the first place, since
they provide only
On Mon 28 Apr 2014 17:35, Jason Orendorff jason.orendo...@gmail.com writes:
The HTML version is available now.
http://people.mozilla.org/~jorendorff/es6-draft.html
As ever, you are a hero.
A
___
es-discuss mailing list
es-discuss@mozilla.org
On 29/04/2014 08:41, Andy Wingo wrote:
On Mon 28 Apr 2014 17:35, Jason Orendorff jason.orendo...@gmail.com
writes:
The HTML version is available now.
http://people.mozilla.org/~jorendorff/es6-draft.html
As ever, you are a hero.
A
Thanks. I am new to the list so this might be a recurrent
On Tue, Apr 29, 2014 at 10:38 AM, Paulo Matos pa...@matos-sorge.com wrote:
Thanks. I am new to the list so this might be a recurrent question but is
there any working prototype implementation of ES6 that people can
experiment language features with?
There isn't a complete implementation, no.
I agree with pretty much everything Andy had to say, and would like to add
a meta-perspective:
We should be viewing this as a last-minute feature request. The churn that
this request has introduced is (in my opinion) exactly the kind of problem
that the ES7 process is meant to address. In fact,
On Tue, Apr 29, 2014 at 4:38 AM, Paulo Matos pa...@matos-sorge.com wrote:
On 29/04/2014 08:41, Andy Wingo wrote:
On Mon 28 Apr 2014 17:35, Jason Orendorff jason.orendo...@gmail.com
writes:
The HTML version is available now.
http://people.mozilla.org/~jorendorff/es6-draft.html
As ever,
https://github.com/zenparsing/esparse
The actual transpiler is at https://github.com/zenparsing/es6now. I really
need to add some documentation, but you can play with classes, arrows, and
other things in the REPL. If you have Node 0.11+, you can also try async
functions (yay). Traceur is a
On Apr 29, 2014, at 12:40 AM, Andy Wingo wi...@igalia.com wrote:
I'm a bit grumpy that this is being brought up again, and
this late, and in multiple forums, but as it seems that people want to
talk about it again, that talking about it again is the thing to do...
Sorry about that. :( But the
On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Nope, it's always been designed this, going back to the original wiki
strawman
http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I
assume the original FF implementation.
It has also
I'm sympathetic to the simplicity argument that says that `.throw` is the
proper way in JS to clean up an iterator. The `.return` proposal seems
like a kludge to work around the fact that ES6 still doesn't have a
discriminatory `catch` clause that can avoid catching the thrown cleanup
exception.
Dave and Andy's responses have me pinging back and forth as to which side I'm
on. Both seem convincing. Dave's response especially brought the issue into
focus for me in a way that I think is clear, so let me explain what I learned
from it:
What we are essentially talking about here are two
Domenic Denicola wrote:
Dave and Andy's responses have me pinging back and forth as to which side I'm
on.
Are you off the fence yet? I can't tell :-P.
But inconvenience is easily solved via MOAR SUGAR:
```js
for (var line using files) {
if (line == '-- mark --') {
break;
}
}
```
Brendan Eich wrote:
Indeed with rapid release, penalizing convenience and waiting for
ecosystem effects can make overcomplicated, convenient
inconvenient
, and just bad total designs out of piecewise steps that you might
like because they avoid committing to convenience :-P.
/be
The [[Origin]] field of Property Descriptor Records is not yet
implemented in Firefox. Eric Faust is looking at implementing it.[1]
We noticed two interesting cases:
1. Suppose handler.getOwnPropertyDescriptor returns ({value: 0}). Then
9.5.5 Proxy.[[GetOwnProperty]] calls 6.2.4.6
On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wi...@igalia.com wrote:
== Calling return() on early exit from for-of is expensive
Wrapping a try/finally around each for-of is going to be really
expensive in all engines right now. I'm skeptical about our ability to
optimize this one away.
On Apr 29, 2014, at 12:17 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Anyway, regardless of the specifics of my `using` proposal, I hope that
highlighting the iterability vs. disposability aspects of this conversation
was helpful to people.
I do think it's helpful for
I think Eric Faust is right over there when he says: It is easily fixed if
we do the conversion to PropSpec in the proxy api
my 2 cents
On Tue, Apr 29, 2014 at 3:43 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
The [[Origin]] field of Property Descriptor Records is not yet
implemented
On Tue, Apr 29, 2014 at 4:07 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Tue, Apr 29, 2014 at 2:40 AM, Andy Wingo wi...@igalia.com wrote:
== Calling return() on early exit from for-of is expensive
Wrapping a try/finally around each for-of is going to be really
expensive in all
On Apr 25, 2014, at 9:10 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
People will write code like this if we allow it. But we don't have to allow.
We can preserve the semantics of try-finally by simply making the occurrence
of the 'yield' operator syntactically illegal within the try
On Apr 30, 2014, at 8:43 AM, Jason Orendorff jason.orendo...@gmail.com wrote:
The [[Origin]] field of Property Descriptor Records is not yet
implemented in Firefox. Eric Faust is looking at implementing it.[1]
We noticed two interesting cases:
1. Suppose handler.getOwnPropertyDescriptor
On Tue, Apr 29, 2014 at 5:49 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Apr 30, 2014, at 8:43 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
The [[Origin]] field of Property Descriptor Records is not yet
implemented in Firefox. Eric Faust is looking at implementing it.[1]
On Apr 30, 2014, at 11:08 AM, Mark S. Miller erig...@google.com wrote:
I'm surprised and alarmed by this, and it seems wrong. It is also not what I
think I remember. What about, for example, the invariant that an object
cannot both claim that a property is non-configurable but then later
Minor correction to Domenic's comments in this (interesting)
discussion; IEnumerable and IDisposable are separate concepts in C#.
Neither IEnumerable or IEnumerator are disposable objects in C#;
*however*, if you use 'for each' on an object that yields an
enumerator that is *also* disposable, the
25 matches
Mail list logo
