On Tue, Nov 12, 2013 at 5:20 PM, Martin J. Dürst
due...@it.aoyama.ac.jp wrote:
If XMLHttpRequest has reasons to continue allowing it, I'd suggest that:
1) It strongly discurages it, and
2) It defines processing as something roughly like
a) If the first few bytes look like a BOM, ignore them
On 26 October 2013 04:49, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The plan has been that runtime validation would be performed for any object
literals containing computed property keys and the current spec. draft
contains pseudo code for doing the checks. However a bug report
I have a nit: would it possible to use international standard date
format (YY-MM-DD) for the revision's file names? Then they would sort
in a meaningful manner. :)
/Andreas
On 8 November 2013 21:25, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
PDFs and .doc file available at
+1. I was always glad that the shape argument had seemed to lead to the
same conclusion and I am sad to see it go. But my reason for supporting the
check was to catch errors early for strict object literals. I don't much
care what happens here if the object literal is sloppy.
On Tue, Nov 12,
Allen Wirfs-Brock wrote:
Also, I would outlaw (new) overloads like
Document:
TouchList createTouchList(Touch... touches);
TouchList createTouchList(sequenceTouch touches);
Yeah, why are *new* (this is from Web Events, not legacy) APIs doing the
crazy. Answer: because people imitate
On 11/12/13 11:24 AM, Brendan Eich wrote:
Yeah, why are *new* (this is from Web Events, not legacy) APIs doing the
crazy. Answer: because people imitate older crazy APIs, and WebIDL
supports this.
No. In this case it's because the spec started out one way (with the
sequence, iirc) but then
When I started investigating this I had the hope that stack could be
standardized. However, the format of the string is cannot be changed
without breaking the web so the way forward is to introduce a new property
name. But since we are introducing a new property name we should return
structured
Allen Wirfs-Brock wrote:
On Nov 11, 2013, at 12:51 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
Yep -- I'm warming up to LeftHandSideExpression. It allows new and
call forms, member expressions, primary expressions, but not unparenthesized ternary,
binary or unary operators --
The only formatting requirement for the stack property is that if it is
present, it must be a string.
—Oliver
On Nov 12, 2013, at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
When I started investigating this I had the hope that stack could be
standardized. However, the format of
See getCWStack() at
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#128
.
Of course, we should choose a better name than getCWStack.
On the string form, see getStack() at
Could I present another example where WeakRef are required.
I am writing an object management layer similar to what exist in other language
and systems. One of the requirement is uniquing so that each object exist only
once in memory. Let say I retrieve a company and its employees and later
Hi Pierre, as long as this use would not need inter-realm weakrefs to be
weak, as seems likely, then I think it could live fine with the existing
proposal for securing weakrefs. No need to tilt any balance away from
security.
On Tue, Nov 12, 2013 at 10:18 AM, Pierre Frisch
Mark S. Miller wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
Midori
Orleans
AmbientTalk
Cap'n Proto
Mark (and Tom, cc'ed), please take this as sincere feedback from a fan
-- I mean this in the best possible way:
I
On Nov 12, 2013, at 9:27 AM, Brendan Eich wrote:
...
We have problems with paren-free heads for if, while, etc. because statement
bodies need not be braced in the paren-ful case:
https://mail.mozilla.org/pipermail/es-discuss/2011-September/016804.html
I don't see a similar problem here,
With the introduction of custom elements I find myself more and more
interested in script that is tightly coupled to DOM nodes but that can be
safely spun down when that node is GC'd (not just lifecycle removed).
This could be achieved by having a callback on weakmaps or some way to hook
into the
On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller erig...@google.com wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
[...]
Sure. I can only echo Brendan's critique. None of the projects you
listed are in JS, most are
Matthew Robb wrote:
With the introduction of custom elements I find myself more and more
interested in script that is tightly coupled to DOM nodes but that can
be safely spun down when that node is GC'd (not just lifecycle
removed). This could be achieved by having a callback on weakmaps or
On Tue, Nov 12, 2013 at 12:35 PM, Oliver Hunt oli...@apple.com wrote:
The only formatting requirement for the stack property is that if it is
present, it must be a string.
No. There is a lot of code out there that parses this string and depend on
the format.
See Mark's reply for one such
Le 12/11/2013 10:18, Pierre Frisch a écrit :
Could I present another example where WeakRef are required.
I am writing an object management layer similar to what exist in other language
and systems. One of the requirement is uniquing so that each object exist only
once in memory. Let say I
(factoring out this part of the conversation because it seems like a
bit of a sidetrack)
Mark and me:
Why do you believe manual deallocation decisions will be easier in
distributed systems than they are locally?
I don't. That's why I cited several examples of systems that require
neither
Righto, do we know whether Carakan/V8’s text or SM’s text is preferred?
Currently it seems like JSC’s is a little bit weird compare to others, and as
i’ve said earlier i’m happy to change it to match another engine (we all have
the same info in varying ways, so we can all technically produce
I think V8's is preferred. IE10 adopted it, and there's a lot of stack-parsing
going on in Node.js land. If SpiderMonkey and JSC would come around to that, it
would be lovely.
___
es-discuss mailing list
es-discuss@mozilla.org
FWIW, the code I linked to, which arv refers to, when it finds itself on
SM, normalizes the SM error stack string to approx v8's format. But the
more important part of the answer is the parsed form provided by
getCWStack.
On Tue, Nov 12, 2013 at 12:20 PM, Oliver Hunt oli...@apple.com wrote:
Righto, filed https://bugs.webkit.org/show_bug.cgi?id=124220
—Oliver
On Nov 12, 2013, at 12:30 PM, Mark Miller erig...@gmail.com wrote:
FWIW, the code I linked to, which arv refers to, when it finds itself on SM,
normalizes the SM error stack string to approx v8's format. But the more
On Tue, Nov 12, 2013 at 11:23 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
(factoring out this part of the conversation because it seems like a
bit of a sidetrack)
Mark and me:
Why do you believe manual deallocation decisions will be easier in
distributed systems than they are
On Tue, Nov 12, 2013 at 11:10 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller erig...@google.com
wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
[...]
Sure.
One of the concerns with promises is that they consume exceptions that may
or may not be handled. I have been looking forward for WeakRef as one of
the avenues available to mitigate this problem. A post-mortem finalizer
would be able to surface an error that was trapped by a promise or promises
On Tue, Nov 12, 2013 at 10:49 AM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
Midori
Orleans
AmbientTalk
Cap'n Proto
Mark (and Tom, cc'ed), please take
Mark S. Miller wrote:
I don't think it does in practice, any more than UNIX does. How does a
UNIX admin (or the kernel) decide when to kill a process?
Good question. How do they?
Old-style Unix admin involves dedicating process seats, doing shallow
supervision-tree-style
Just to be clear on my use case. I am not trying to build distributed objects.
I am building an object management layer similar to what EOF/WebObjects was.
The purpose is to expose in the client a graph of object for display and
edition. The purpose of this is to simplify writing client side
Mark S. Miller wrote:
Link please for the Stonebreaker point?
Sorry, having a hard time finding it now. It was about the longer
history since SQL was pioneered; also about NoSQL.
On your other bullets, you're preaching to the choir. These are
exactly the considerations that led to the E
On 11/12/13 2:01 PM, Matthew Robb wrote:
Perhaps somewhere in the middle would work, something like a regular map
but that also pays attention to the ref count changes of key and an
author can hook in with a callback that effectively means reached 1 ref.
Consider this testcase:
var elem =
On 11/12/13 12:21 PM, Brendan Eich wrote:
Oh, ok -- new-ish legacy. This makes the case for stronger normative
specs against such overloading, starting with WebIDL.
Again, WebIDL disallowing this would not have helped; the real issue was
a semantic problem.
I'm all for simplifying the
Mark S. Miller wrote:
However, many clients will engage in honest GC to keep their
requirements on
service memory low. Many services will not need to cut such
clients off
because of excessive resource demands.
Perhaps, but they still need to cut off bad clients, and
Boris Zbarsky wrote:
Oh, ok -- new-ish legacy. This makes the case for stronger normative
specs against such overloading, starting with WebIDL.
Again, WebIDL disallowing this would not have helped; the real issue
was a semantic problem.
What semantic problem required two createTouchList
I mean the promises-unwrapping proposal that has now been accepted into ES6
and the DOM, and IIUC is being implemented by several browser makers. Let's
call these JS Promises. These descend from Promises/A+ which have a long
and complicated history, but the major branches of that history all to
On Tue, Nov 12, 2013 at 4:16 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
However, many clients will engage in honest GC to keep their
requirements on
service memory low. Many services will not need to cut such
clients off
because of excessive
Currently, it's not allowed that arrow functions be generators. I did a
bit of searching and couldn't find the original reasoning behind this.
`*() = {}` doesn't seem to be a problematic grammar since `foo * () =
{}` isn't valid. The problem I do see is the mismatch between the
generator class
In summarizing the history, I held back from mentioning names because it is
a long history and many people deserve thanks. Nevertheless, a few names
stand out so much I can't talk about the history without thanking them:
E. Dean Tribble
Domenic Denicola
Kris Kowal
Tyler Close
Without them,
On 11/12/13 7:19 PM, Brendan Eich wrote:
What semantic problem required two createTouchList functions having
the same name?
The fact that some UAs shipped one version of it others shipped another
(as the spec evolved), then the working group decided to spec one of
those versions but there
Everybody should probably review
esdiscuss.org/topic/why-do-generator-expressions-return-generators where we
discussed this before.
It wasn't that there was necessarily anything bad about them, but there also
didn't seem to be a strong enough case made in that thread to justify the work
On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote:
Nevertheless, remember that I am not yet asking TC39 to standardize
distributed JS itself, and will not until we have some cowpaths. The ES7
question is only regarding the remaining necessary primitive to start these
paving efforts --
On Tue, Nov 12, 2013 at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote:
Nevertheless, remember that I am not yet asking TC39 to standardize
distributed JS itself, and will not until we have some cowpaths. The ES7
question is
Le 12/11/2013 18:30, Axel Rauschmayer a écrit :
This is relevant, too:
http://esdiscuss.org/topic/function-declarations-with-lexical-this
I'd still argue that generator arrow functions make more sense than
generator function declarations.
I don't have a strong opinion in this debate, but I've
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled. I have been looking forward for WeakRef as
one of the avenues available to mitigate this problem. A post-mortem
finalizer would be able to surface an
Rev. 21 is now available in HTML at
http://people.mozilla.org/~jorendorff/es6-draft.html.
As always, bug reports are greatly appreciated. Email me or file
issues at https://github.com/jorendorff/es-spec-html.
-j
___
es-discuss mailing list
Finding out at runtime (by doing a sanity check in the finalizer) is a way
to catch bugs in the application that were not caught at
compile/development time, so you can log/report them and go back and fix
them. This is an incredibly useful facility since (generally speaking)
promise libraries have
47 matches
Mail list logo
