Re: JSON: remove gap between Ecma-404 and IETF draft
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 b) Process the rest according to rfc4627bis or ECMA-404 (whichever works better if they are not in full alignment). That will make sure that variation is confined as locally as possible. So that is roughly how it is defined. Using the web's utf-8 text resource decode method that removes a BOM and then passing the rest to something equivalent to JSON.parse(). However, if we are defining a new text transport format I think it would make sense to allow a leading BOM similar to how text/css, text/html, etc. allow for that. -- http://annevankesteren.nl/ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: computed property keys and ES5 duplicate rule enforcement
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
(https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out an issue with
the current spec. For example, the current spec. throws an error on:
({get a() {},
get [a]() {}
});
but not on:
({get [a]() {},
get a() {}
});
Basically, it isn't sufficient to only check for an already defined property
key when processing property definitions that contains a computed key. If
any computed keys exist the checking has to be done even for the definitions
that have literal property names. And it isn't sufficient to just consider
the property keys and the data/accessor property distinction, the validation
also has to take into account the syntactic form of the definition and
whether or not strict mode applies..
It turns out that even in pseudo code, this is a fairly complicated set of
runtime validation rules to apply. I'm having a hard time convincing myself
that the runtime computational and meta data costs of this dynamic
validation is justified. It costs too much and the actual benefit is pretty
small.
***For that reason, I propose that we drop this runtime validation of object
literals (and class definition). We would still have the static validation
and early errors for property definitions that don't have computed keys. But
anything that makes it past those checks (including all property definitions
with computed names) are just processed sequentially with no duplicate name
checking.***
I'm not convinced. I think the check is useful, and erroneous
situations like this going unnoticed could lead to really nasty
surprises.
Is their a chance that the check could be factored into the
DefineProperty meta operator? I.e., just like the strict mode flag it
also has a flag saying whether redefinitions are allowed?
What about predetermining the shape of literal objects that include
computed property keys?
One of the reason for the dynamic checks was the desire to preserve the
characteristics that allowed an implementation to look at an object literal
and statically determine exactly how many own properties the resulting
objects would have. The hope was that an implementation could still
determine an intended shape and that the dynamic checks would guarantee that
the actual constructed objects conform to that predicted shape. If we drop
the dynamic checks we loose that shape guarantee.
I think this ability to predict an intended shape was probably a committee
pipe-dream. Consider this function:
function makeObj(a,b,c,d,e) {
return {
get [a] () {},
get [b] () {},
set [c] (v) {},
set [d] (v) {},
set [e] (v) {}
}
}
The object returned by this function might validly have 3, 4, or 5
properties. The is no clearly intended shape to try to guarantee.
Fair enough, I always considered the shape argument a red herring.
On the other hand, I think what the above primarily demonstrates is
that get/set was a regrettable choice of syntax. :)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rev21 ES6 Draft now available
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 http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#november_8_2013_draft_rev_21 New in this revision: • Updated Module Syntax and static semantics • Scripts no longer may contain import statements • Specified how to determine if a call is in tail position • The call and apply functions now internally do tail calls to the target function • Tweaked the new operator so it will work in tail position • Eliminated the [[Invoke]] MOP operation • Calling the next method of an completed generator returns a “done” result instead of throwing • The length property of bound functions is now configurable/non-writable • Clarified requirements of String localeCompare when no language sensitive comparison support is available. • Tweaked the ordering of a few steps in Array.from to enable self-hosting using for-of • Added ToInt8 and similar abstract operation • Defined name property of %TypedArray% and the individual typed array constructors • Significant fixed to yield * evaluation semantics • Fixed handling of identifier ‘yield’ in generator function parameter lists • A little static semantic cleanup making sure that FunctionDeclarations and GeneratorDeclarations have the same top level scoping rules ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: computed property keys and ES5 duplicate rule enforcement
+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, 2013 at 3:55 AM, Andreas Rossberg rossb...@google.comwrote:
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
(https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out an issue
with
the current spec. For example, the current spec. throws an error on:
({get a() {},
get [a]() {}
});
but not on:
({get [a]() {},
get a() {}
});
Basically, it isn't sufficient to only check for an already defined
property
key when processing property definitions that contains a computed key. If
any computed keys exist the checking has to be done even for the
definitions
that have literal property names. And it isn't sufficient to just
consider
the property keys and the data/accessor property distinction, the
validation
also has to take into account the syntactic form of the definition and
whether or not strict mode applies..
It turns out that even in pseudo code, this is a fairly complicated set
of
runtime validation rules to apply. I'm having a hard time convincing
myself
that the runtime computational and meta data costs of this dynamic
validation is justified. It costs too much and the actual benefit is
pretty
small.
***For that reason, I propose that we drop this runtime validation of
object
literals (and class definition). We would still have the static
validation
and early errors for property definitions that don't have computed keys.
But
anything that makes it past those checks (including all property
definitions
with computed names) are just processed sequentially with no duplicate
name
checking.***
I'm not convinced. I think the check is useful, and erroneous
situations like this going unnoticed could lead to really nasty
surprises.
Is their a chance that the check could be factored into the
DefineProperty meta operator? I.e., just like the strict mode flag it
also has a flag saying whether redefinitions are allowed?
What about predetermining the shape of literal objects that include
computed property keys?
One of the reason for the dynamic checks was the desire to preserve the
characteristics that allowed an implementation to look at an object
literal
and statically determine exactly how many own properties the resulting
objects would have. The hope was that an implementation could still
determine an intended shape and that the dynamic checks would guarantee
that
the actual constructed objects conform to that predicted shape. If we
drop
the dynamic checks we loose that shape guarantee.
I think this ability to predict an intended shape was probably a
committee
pipe-dream. Consider this function:
function makeObj(a,b,c,d,e) {
return {
get [a] () {},
get [b] () {},
set [c] (v) {},
set [d] (v) {},
set [e] (v) {}
}
}
The object returned by this function might validly have 3, 4, or 5
properties. The is no clearly intended shape to try to guarantee.
Fair enough, I always considered the shape argument a red herring.
On the other hand, I think what the above primarily demonstrates is
that get/set was a regrettable choice of syntax. :)
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: an idea for replacing arguments.length
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 older crazy APIs, and WebIDL supports this. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an idea for replacing arguments.length
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 got changed to the other way, but implementations had already shipped the first way, so now for compat they support both. If webidl didn't allow this, they'd just use any... and define it all in prose, I assume. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Formalize error.stack?
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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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 -- and (crucially for the bug) not anything ending in
AssignmentExpression. Allen?
Playing devil's advocate for the movement. Sure, general Expression
You must mean AssignmentExpression -- no ES6 draft allows comma expressions after extends.
Yes, my recollection is we wanted to leave open the possibility that comma in
the extends clause might, in the future, have special meaning.
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, yet, but it's a possibility. If
class body always starts with { and no expression can adjoin a braced
form and make a larger expression, we're ok. This prohibition must be
kept in all future editions.
Hardly any programmers, in the first place, will write any ternary, binary,
or unary operator expression after extends.
No, I think you're missing the point. Of course, most programmers will never
even consider writhing anything more complex than a function call in the
extends clause. But the extra complexity of having restricted expression forms
in some places does add to the overall conceptual burden on programmers.
You're just repeating your assertion as its own proof here. Sorry, it's
not an axiom.
Most programmers do not think about grammar in this level of detail.
If your grammar parameterization only prohibits unparenthesized yield at
the end of the extends RHS, that may be worth the ugliness in the spec.
But first let's make sure we aren't going wrong in allowing arbitrary
AssignmentExpression after 'extends'. The paren-free gotcha needs
another look.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
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 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Formalize error.stack?
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 https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js#221 . These avoid the information leakage problem of err.stack, since the getStack and getCWStack functions can be denied to untrusted guests, and can only reveal the stacks of errors from their own realm. As with makeWeakRef, we could also provide a combiner to combine multiple getStack functions into one that could unseal the errors from any of the originating realms. On Tue, Nov 12, 2013 at 9:23 AM, Erik Arvidsson erik.arvids...@gmail.comwrote: 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.comwrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Weak callbacks?
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 retrieve a company project and its participants. I need the members of the employee list and the members of the participant list to point to the same objects. The other requirement is not to leak, if an object is only accessible from within the management layer it should be candidate for garbage collection. With the current ECMAScript I have multiple problem implementing this. Each object has a unique identifier (UUID) but as strings cannot be used as keys in WeakMap I have to keep a reference to objects in a regular Map. This causes a major leak… In order to plug it we have to rely on the user notifying the management layer for checkin/checkout of objects doing ref counting. This is clumsy. I had a similar design working with WeafRef in Java with no constrains on the user. Why could we not do this with JS? WeakRef would solve this issue quite naturally. I understand that this would make GC observable and there is a security concern. We should however strike a balance between usability and security. I am no security expert but it looks to me that in this case we could tilt the balance a little more in favour of usability. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Weak callbacks?
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 pierre.fri...@spearway.comwrote: 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 retrieve a company project and its participants. I need the members of the employee list and the members of the participant list to point to the same objects. The other requirement is not to leak, if an object is only accessible from within the management layer it should be candidate for garbage collection. With the current ECMAScript I have multiple problem implementing this. Each object has a unique identifier (UUID) but as strings cannot be used as keys in WeakMap I have to keep a reference to objects in a regular Map. This causes a major leak… In order to plug it we have to rely on the user notifying the management layer for checkin/checkout of objects doing ref counting. This is clumsy. I had a similar design working with WeafRef in Java with no constrains on the user. Why could we not do this with JS? WeakRef would solve this issue quite naturally. I understand that this would make GC observable and there is a security concern. We should however strike a balance between usability and security. I am no security expert but it looks to me that in this case we could tilt the balance a little more in favour of usability. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 remember the mid-late '80s to '90s RPC wars, Sun RPC vs. Apollo RPC, Ken Birman et al.'s work at Cornell (and on Wall Street back end systems), CORBA, Java RMI, all that. I have some scars myself. That history, plus some of the names dropped above, form a large super-counterexample in my opinion. Lessons painfully learned: * One cannot ignore network latency and partitioning. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. * As Mike Stonebraker observes, hardware trade-offs flipped upside down with a vengeance. The example of the Web, messy as it is, shows a success story so big that we live inside it without often being conscious of it, like happy fish in bubbly water. True, it's still too client/server, too stateless with login and session state built into silos on server networks, too subject to dreary XSS and CSRF threats. I agree it is not the full distributed system that it should be. But are we really going to build distributed-GC systems at Web scale, with mutual suspicion and accidental failure accounted for? It's as far as I know fair to say that Erlang is used in mutual trust settings, even though trust means assume failure happens, deal with it as part of the design. So, Erlang is good for systems that distribute across a server peer-to-peer network, but not yet demonstrated as good for client/server/p2p/Web in full. Perhaps it or a language/system it inspired (Go, Rust) will break out across the Web, but this is in the future. If we must go once more unto the distributed-GC breach, it would give me more confidence to see some literature outside the OCap/RPC/tightly-coupled/research/unshipped-OS world, which AFAIK has never been demonstrated at anything approaching Web scale. Something built on the Web and even deployed to cite along with the listed names above would be better. What cowpath could we pave? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: optional yield expression creates ambiguity
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, yet, but it's a possibility. If class
body always starts with { and no expression can adjoin a braced form and make
a larger expression, we're ok. This prohibition must be kept in all future
editions.
...
If your grammar parameterization only prohibits unparenthesized yield at the
end of the extends RHS, that may be worth the ugliness in the spec.
But first let's make sure we aren't going wrong in allowing arbitrary
AssignmentExpression after 'extends'. The paren-free gotcha needs another
look.
The { is a mandatory part of the class declaration syntax, not part of the
class body. In that regard, it is more like:
CaseClause :
'case' Expression ':' StatementList
which has a mandatory delimiter after the Expression, then it is like
IfExpression and friends that have an undelimted Statement as their tail.
But the message you referenced above is more about refactoring/editing hazards
so lets look at those types of hazards with 'extends' AssignmentExpression
Assume we start with
class foo extends bar {}
If somebody added an binary operator after 'bar' but forgot to add its right
operand
we would have
class foo extends bar+ {}
The braces would be interpreter as an object literal that was part of the
expression. But the class body braces are still mandatory so if the next
meaningful line starts with anything other than a { we have a syntax error (and
one that ASI can't fix).
Assuming the program was syntactically valid before inserting the + the only
thing that could be on the next line starting with a { is a Block.
If the following Block was empty it would be interpreter as the class body and
the program would parse correctly. Of course, a runtime error will occur when
the extends expression evaluates to a non-function (but perhaps if 'bar' was a
value object with operator overloading, the + might evaluate to a function, but
it still seems unlikely).
If the following Block looked like this:
{f(a) /*ASI here */
{/*any Valid StatementList */}
}
the ClassDeclaration would also parses correctly using the following Block as
the class body. EG,
class foo extends bar+ {}
{f(a) /*no ASI here in a ClassBody*/
{/*any Valid StatementList */}
}
Note that the hazard of this occurring is essentially the same as if somebody
inadvertently inserted a '+' after the 'foo()' in:
foo() /*ASI here */
{f(a) /*ASI here */
{/*any Valid StatementList */}
}
except the class declaration case still has the runtime check that the
'extends' expression evaluates to a function.
My conclusion from the above is that 'extends' AssignmentExpression, assuming
we fix the 'yield' ambiguity, doesn't introduce any editing/refactoring hazards
that don't already exist for common ES language constructs and my impression is
that those hazards don't appear to be significant issues for developers using
the current language.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 destruction phase of a dom element's lifecycle ( this seems messier from an authoring standpoint ). 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. 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 this as sincere feedback from a fan -- I mean this in the best possible way: I remember the mid-late '80s to '90s RPC wars, Sun RPC vs. Apollo RPC, Ken Birman et al.'s work at Cornell (and on Wall Street back end systems), CORBA, Java RMI, all that. I have some scars myself. That history, plus some of the names dropped above, form a large super-counterexample in my opinion. Lessons painfully learned: * One cannot ignore network latency and partitioning. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. * As Mike Stonebraker observes, hardware trade-offs flipped upside down with a vengeance. The example of the Web, messy as it is, shows a success story so big that we live inside it without often being conscious of it, like happy fish in bubbly water. True, it's still too client/server, too stateless with login and session state built into silos on server networks, too subject to dreary XSS and CSRF threats. I agree it is not the full distributed system that it should be. But are we really going to build distributed-GC systems at Web scale, with mutual suspicion and accidental failure accounted for? It's as far as I know fair to say that Erlang is used in mutual trust settings, even though trust means assume failure happens, deal with it as part of the design. So, Erlang is good for systems that distribute across a server peer-to-peer network, but not yet demonstrated as good for client/server/p2p/Web in full. Perhaps it or a language/system it inspired (Go, Rust) will break out across the Web, but this is in the future. If we must go once more unto the distributed-GC breach, it would give me more confidence to see some literature outside the OCap/RPC/tightly-coupled/research/unshipped-OS world, which AFAIK has never been demonstrated at anything approaching Web scale. Something built on the Web and even deployed to cite along with the listed names above would be better. What cowpath could we pave? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- - Matthew Robb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 research, a few maybe shouldn't be in the list because we don't actually know anything about them, and a couple I couldn't find online. The distributed object systems that saw widespread use were DCOM, CORBA, and Java RMI. They all happened in the 1990's, they were widely used for a little while, and then they vanished. They were considered painful to use. (Of course, none of them were E.) I'm not opposed to people trying to bring the distributed objects idea back. If it stuck, it would be rather glorious. But until it's been proven, it just isn't a use case that should drive the evolution of JS. That's my only point in this thread. Much of the early Actors research did cyclic GC as well, but this early distribibuted GC work notably violated the general Actors assumption of mutual suspicion. Right, implementing full DGC (with cycles) in untrusted JS isn't in the cards. Cap'n Proto is designed primarily for the local C++ bindings. It has the distributed acyclic GC logic I explain, but typically driven by local manual deallocation rather than local GC and finalization. I don't see anything in Cap'n Proto that is related to weak references or GC. At the protocol level, it seems capabilities are explicitly dereferenced. It is possible for a peer to hook up with a GC to manage those capability lifetimes on one side, but then, there are also other possible designs that wouldn't require weakrefs and would tend to provide more timely cleanup, e.g. leases, resource pools, or FIFO allocation (like the C++ bindings --- that API is a whole lot better than explicit malloc/free). There are also alternatives at the protocol level. What abundance of widely used alternative designs do you mean? Alternatives to distributed objects-based designs (CORBA, DCOM, Java RMI, E) for distributed computing. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 some way to hook into the destruction phase of a dom element's lifecycle ( this seems messier from an authoring standpoint ). You've heard this before: we are not going to do pre-mortem finalization. We are not doing post-mortem easily, in a way that telegraphs fine-grained GC schedules. 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. ref count? Engines use GC. True, GC and ref-counting have the same asymptotic performance with cycles across all the generations, but engines are not switching to ref-counting. It sounds like weak listeners would be helpful, both in abstracting from weak refs to avoid post-mortem finalization GC non-determinism leakage; and in giving hints to the GC so it can be prompt. But you ain't gonna get a callback on zero refcount! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
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 case. —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 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.comwrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 retrieve a company and its employees and later retrieve a company project and its participants. I need the members of the employee list and the members of the participant list to point to the same objects. The other requirement is not to leak, if an object is only accessible from within the management layer it should be candidate for garbage collection. Your description suggests that there is an external source of truth dictating which objects are expected to be the same. I imagine ids in a database. I feel your use case is very close what has been covered so far with attempts to reimplement CapTP or the Cap'n'proto protocol in JS. These contain a form of object management layer like the one you describe. Among other things, they preserve object identity within one Vat. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Speculations on Erlang (was: Weak callbacks?)
(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 fine-grained manual deallocation nor distributed GC. I didn't say fine-grained. Erlang requires manual deallocation of processes. 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? Also, you did specify untrusted. Distributed Erlang does not qualify, exactly because pid are forgeable. That's fair, but let me clarify what I mean. It's true that Erlang doesn't use an ocap model for security. An Erlang process that doesn't check auth on incoming messages must be protected by some sort of wrapper that does. Typically some front-end code plus a firewall. This particular factoring of responsibilities is not Erlang-specific. The Web is chock full of JS code (client and server) doing remote API calls. These systems generally don't use object capabilities. They don't use any distributed GC equivalent either, except perhaps in the sense of leases: server-side objects often live in sessions that expire if unused for some period of time. (Offhand, I would expect leases/sessions to continue being good enough even if many systems did migrate to distributed objects and capabilities. I don't think distributed GC was anyone's favorite feature of RMI.) What do you mean then by strong reference? If Erlang pids are not strong references, then I don't understand what you are saying. I just meant strong reference in the usual sense: https://en.wikipedia.org/wiki/Strong_reference A pid doesn't keep the referred-to process alive. A pid has no effect at all on the process it addresses, local or remote. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
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 the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: 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 case. —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 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Formalize error.stack?
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 https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
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, 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 the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: 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 case. —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 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Formalize error.stack?
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 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, 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 the same view in our .stack string) —Oliver On Nov 12, 2013, at 11:17 AM, Erik Arvidsson erik.arvids...@gmail.com wrote: 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 case. —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 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 data instead of a plain old string. I haven't had the time to work on this since my initial analysis of the state of the stack property. On Mon, Nov 11, 2013 at 7:51 PM, John Barton johnjbar...@google.com wrote: Note that in Chrome the devtools are remote and error.stack is a getter which issues a remote method call to the backend. Only when the stack property is accessed will the internal representation be converted to a string. Anything else is too expensive. A plain JS object format would be much more useful for development tools developers. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Speculations on Erlang (was: Weak callbacks?)
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 locally? I don't. That's why I cited several examples of systems that require neither fine-grained manual deallocation nor distributed GC. I didn't say fine-grained. Erlang requires manual deallocation of processes. 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? Also, you did specify untrusted. Distributed Erlang does not qualify, exactly because pid are forgeable. That's fair, but let me clarify what I mean. It's true that Erlang doesn't use an ocap model for security. An Erlang process that doesn't check auth on incoming messages must be protected by some sort of wrapper that does. Typically some front-end code plus a firewall. This particular factoring of responsibilities is not Erlang-specific. The Web is chock full of JS code (client and server) doing remote API calls. These systems generally don't use object capabilities. They don't use any distributed GC equivalent either, except perhaps in the sense of leases: server-side objects often live in sessions that expire if unused for some period of time. (Offhand, I would expect leases/sessions to continue being good enough even if many systems did migrate to distributed objects and capabilities. I don't think distributed GC was anyone's favorite feature of RMI.) What do you mean then by strong reference? If Erlang pids are not strong references, then I don't understand what you are saying. I just meant strong reference in the usual sense: https://en.wikipedia.org/wiki/Strong_reference A pid doesn't keep the referred-to process alive. A pid has no effect at all on the process it addresses, local or remote. Same thing with a remote strong reference in any of the distributed GC systems I mention. The owner of the machine on which a hosting process or vat is running can still shut down the vat, whether it hosts objects remotely referred to or not. These remote references do not keep the object alive. The distributed GC protocols are merely a way for the client to inform the host, if it wishes, that it is no longer interested. It is up to the client whether it wishes to tell the host about such a lack of interest. It is up to the host how to react to such reports of lack of interest. A host that takes down an object or a vat prior to such reports of disinterest may be disrupting clients, but that's its decision. Likewise with terminating an Erlang process. The difference is only whether there's a standard way for a client to inform a host that it should no longer worry about disrupting this client if it takes down a particular object. So I put scare quotes around strong above because I'm not sure whether you'd call them strong. I don't see any basis for considering them to be stronger than an Erlang pid. -j -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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. I can only echo Brendan's critique. None of the projects you listed are in JS, most are research, a few maybe shouldn't be in the list because we don't actually know anything about them, and a couple I couldn't find online. The distributed object systems that saw widespread use were DCOM, CORBA, and Java RMI. They all happened in the 1990's, they were widely used for a little while, and then they vanished. They were considered painful to use. (Of course, none of them were E.) I'm not opposed to people trying to bring the distributed objects idea back. If it stuck, it would be rather glorious. But until it's been proven, it just isn't a use case that should drive the evolution of JS. That's my only point in this thread. Much of the early Actors research did cyclic GC as well, but this early distribibuted GC work notably violated the general Actors assumption of mutual suspicion. Right, implementing full DGC (with cycles) in untrusted JS isn't in the cards. Cap'n Proto is designed primarily for the local C++ bindings. It has the distributed acyclic GC logic I explain, but typically driven by local manual deallocation rather than local GC and finalization. I don't see anything in Cap'n Proto that is related to weak references or GC. At the protocol level, it seems capabilities are explicitly dereferenced. I assume you meant dropped, decremented, deleted, or destroyed rather that dereferenced? If so... At the CapTP level they are as well. Likewise within the implementation of any GC system, whether local or remote. https://github.com/kentonv/capnproto/blob/master/c++/src/capnp/rpc.capnp http://www.erights.org/elib/distrib/captp/dagc.html It is possible for a peer to hook up with a GC to manage those capability lifetimes on one side, but then, there are also other possible designs that wouldn't require weakrefs and would tend to provide more timely cleanup, e.g. leases, resource pools, or FIFO allocation (like the C++ bindings --- that API is a whole lot better than explicit malloc/free). There are also alternatives at the protocol level. What abundance of widely used alternative designs do you mean? Alternatives to distributed objects-based designs (CORBA, DCOM, Java RMI, E) for distributed computing. -j -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 that were eventually garbage collected, and therefore provably never-to-be-handled. It is true that this problem can be decisively mitigated in other ways, like requiring a promise to forward to a terminal done() in the same turn of the event loop, but I find this particular solution unpalatable. I do find a promise inspector compelling, one that will show an error until it is handled, but even in this case, I think it is compelling to visually elevate an unhandled error to a provably never-to-be-handled error, and this is not possible, at least outside chrome-space, without WeakRef. Kris Kowal ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 this as sincere feedback from a fan -- I mean this in the best possible way: I remember the mid-late '80s to '90s RPC wars, Sun RPC vs. Apollo RPC, Ken Birman et al.'s work at Cornell (and on Wall Street back end systems), CORBA, Java RMI, all that. I have some scars myself. That history, plus some of the names dropped above, form a large super-counterexample in my opinion. Lessons painfully learned: * One cannot ignore network latency and partitioning. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. * As Mike Stonebraker observes, hardware trade-offs flipped upside down with a vengeance. Link please for the Stonebreaker point? On your other bullets, you're preaching to the choir. These are exactly the considerations that led to the E promise design, now adopted by JS. http://www.erights.org/elib/concurrency/semi-transparent.html Where it says -, substitute !. In addition, promise pipelining gives us a huge win over network latency beyond the points made on that page. Now that we've adopted such promises, we've paid the anti-transparency costs of good distributed objects. This was quite intentional. Now that we've paid the costs, we may as well collect the benefits. The example of the Web, messy as it is, shows a success story so big that we live inside it without often being conscious of it, like happy fish in bubbly water. True, it's still too client/server, too stateless with login and session state built into silos on server networks, too subject to dreary XSS and CSRF threats. I agree it is not the full distributed system that it should be. But are we really going to build distributed-GC systems at Web scale, with mutual suspicion and accidental failure accounted for? It's as far as I know fair to say that Erlang is used in mutual trust settings, even though trust means assume failure happens, deal with it as part of the design. So, Erlang is good for systems that distribute across a server peer-to-peer network, but not yet demonstrated as good for client/server/p2p/Web in full. Perhaps it or a language/system it inspired (Go, Rust) will break out across the Web, but this is in the future. If we must go once more unto the distributed-GC breach, it would give me more confidence to see some literature outside the OCap/RPC/tightly-coupled/research/unshipped-OS world, which AFAIK has never been demonstrated at anything approaching Web scale. Something built on the Web and even deployed to cite along with the listed names above would be better. What cowpath could we pave? /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Speculations on Erlang (was: Weak callbacks?)
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 management, monitoring and pagers and pain. New-style devops cannot lose the pager, but the developer carries it (not the admin). Lots of automation helps on resource monitoring, provisioning, changing. There's also teh OOM-killer, which guns down what looks like the guiltiest and most bloated among processes when VM (RAM + swap) runs low. No silver bullets. Static allocation still gives the best predictability. Some things never change! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Weak callbacks?
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 application by providing two main services: progressive loading of the object graph and change management. Progressive loading is the ability to load objects as they are displayed in the UI including following relation between objects. Real object are replacing proxy objects as needed. The key is to maintain a graph of unique objects and to prevent leaks. Only objects retain by the UI should be kept in memory any object that is not displayed and does not participate in the object graph is candidate for GC. The change management is the ability to track changes to the objects as they occurs and to be able to identify all the insertion, changes and deletion on the graph so that the developer can commit all his changes in one operation. These concept are not new. They have been successfully tested and implemented over the years. All of iTunes and the Apple store is build on this. A lot of iOS application use CoreData that uses the same model. If we want user to build interesting application with our technology we need to provide the services that will enable them to focus on the business and not the CS. Our team know how to build that layer but to make it really compelling we need WeakRef. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 promise design, now adopted by JS. http://www.erights.org/elib/concurrency/semi-transparent.html Where it says -, substitute !. In addition, promise pipelining gives us a huge win over network latency beyond the points made on that page. Fair point. Now that we've adopted such promises, we've paid the anti-transparency costs of good distributed objects. This was quite intentional. Now that we've paid the costs, we may as well collect the benefits. I think your use of we and past tense here are not shared as widely as you'd like. Anything deployed on the public web yet? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 = document.createElement(div); elem.innerHTML = span/spanSome text; At what point does elem reach 1 ref? -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an idea for replacing arguments.length
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 overloading that WebIDL supports, but it wouldn't have affected this case. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 even honest clients in this kind of system can inadvertently hog server resources simply by not doing GC for a while (because, for example, there isn't memory pressure *on the client*). In these cases I'm not sure how the server can tell which clients to cut off. It seems like it would require automation of the sort of memory tooling you characterized as experimental earlier in this thread. That's fair. Driving distributed GC by observing local GC has exactly the problem you point out: As we give one vat more memory, reducing its memory pressure, it observes far fewer finalizations, increasing the memory pressure on its counter-party vats. Perhaps the reason this problem hasn't been too pressing in the past is that none of our vats had enough local memory to cause the problem. This seems like an important open question to research, since I doubt we can constrain vats to small-local-memory _a prior_ given how much dynamic range web content has (think Ember.js windowing into a large database, building DOM view on the fly). Jason's right about leases being predominant for distributed resource management. These expire right in the user's face, too often. But they are easier to model. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an idea for replacing arguments.length
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 functions having the same name? Isn't that a design choice? If so, then I am arguing it was the wrong choice, but looked ok by precedent including WebIDL support. I'm all for simplifying the overloading that WebIDL supports, but it wouldn't have affected this case. Whatever I'm trying to affect, the idea is norms, not outright bans or removals of code required for backward compatibility. If createTouchList is relatively new, then I bet there will be a next time. What spec of doc should promulgate a norm that says use a different name for the second createTouchList? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 back to E. Approximately: JS Promises from Promises/A+ from merge(Promises/A, Q) Promises/A from Dojo Deferred from MochiKit Deferred from Twisted Python Deferred from E Promises. Q from Promises/C from Waterken Q from E Promises My point is that the differences between hard references and JS Promises are exactly the non-transparencies needed to address your non-Stonebreaker bullets: * One cannot ignore network latency and partitioning. Latency: JS Promises are asynchronous and were carefully designed to not preclude future promise pipelining. Q makes use of this pipelining. Partition: JS Promises have a terminal rejected state indicating that they will never designate any object. This descends directly from the E broken state, where it was was also used to make network partition apparent in a fail-stop manner. Q makes use of this. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). Exactly! * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. Because Promises are asynchronous, even locally, the state of the world when a promise-based request is made differs from the one in which the request is received. Since partition induces rejection of all promises across that partition, connection recovery takes distinct paths through the code where one copes, in an application dependent manner, with having been out of communication. Further support for weak consistency should come at a higher level, e.g., via the Unum model https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt. Promises are a good substrate on which to build Una. On Tue, Nov 12, 2013 at 3:57 PM, Brendan Eich bren...@mozilla.com wrote: 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 promise design, now adopted by JS. http://www.erights.org/elib/concurrency/semi-transparent.html Where it says -, substitute !. In addition, promise pipelining gives us a huge win over network latency beyond the points made on that page. Fair point. Now that we've adopted such promises, we've paid the anti-transparency costs of good distributed objects. This was quite intentional. Now that we've paid the costs, we may as well collect the benefits. I think your use of we and past tense here are not shared as widely as you'd like. Anything deployed on the public web yet? /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 resource demands. Perhaps, but they still need to cut off bad clients, and even honest clients in this kind of system can inadvertently hog server resources simply by not doing GC for a while (because, for example, there isn't memory pressure *on the client*). In these cases I'm not sure how the server can tell which clients to cut off. It seems like it would require automation of the sort of memory tooling you characterized as experimental earlier in this thread. That's fair. Driving distributed GC by observing local GC has exactly the problem you point out: As we give one vat more memory, reducing its memory pressure, it observes far fewer finalizations, increasing the memory pressure on its counter-party vats. Perhaps the reason this problem hasn't been too pressing in the past is that none of our vats had enough local memory to cause the problem. This seems like an important open question to research, since I doubt we can constrain vats to small-local-memory _a prior_ given how much dynamic range web content has (think Ember.js windowing into a large database, building DOM view on the fly). Jason's right about leases being predominant for distributed resource management. These expire right in the user's face, too often. But they are easier to model. Yeah, this point is valid, and I am worried about it too. I do not currently have any satisfying answers to suggest. 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 -- weakrefs with postmortem finalization. In this thread, we've already seen posts for other compelling uses of these, so they need not be considered purely because of their support for distributed objects. If, because of the above memory pressure point, weakrefs turn out not to be the right way to do distributed GC after all, we will still have gained by adding these to ES7. /be -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Generator Arrow Functions
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 hierarchy and the fact that arrow functions don't have
prototypes. I think this could be worked around somehow though.
The use case I've started running into a lot is using Task.js with methods:
```js
class Foo {
foo() { //-- Promise
return Task.spawn(*() = {
const value = yield this.get(this.base + /foo);
if (yield this.bar(value)) {
return true;
}
});
}
bar(value) { //-- Promise
/***/
}
get(url) { //-- Promise
/***/
}
}
```
Without generator arrows, I'm back to using `var self = this` or
`.bind(this)`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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, E-like promises would never have made it into JS, and if they had they would have been far worse. Thanks! On Tue, Nov 12, 2013 at 4:22 PM, Mark S. Miller erig...@google.com wrote: 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 back to E. Approximately: JS Promises from Promises/A+ from merge(Promises/A, Q) Promises/A from Dojo Deferred from MochiKit Deferred from Twisted Python Deferred from E Promises. Q from Promises/C from Waterken Q from E Promises My point is that the differences between hard references and JS Promises are exactly the non-transparencies needed to address your non-Stonebreaker bullets: * One cannot ignore network latency and partitioning. Latency: JS Promises are asynchronous and were carefully designed to not preclude future promise pipelining. Q makes use of this pipelining. Partition: JS Promises have a terminal rejected state indicating that they will never designate any object. This descends directly from the E broken state, where it was was also used to make network partition apparent in a fail-stop manner. Q makes use of this. * Sync RPC is the wrong model (it already yielded to async calls, futures/promises, and the like). Exactly! * Weak consistency (I know, people hear CAP and give up too much) won, which surprised some. Because Promises are asynchronous, even locally, the state of the world when a promise-based request is made differs from the one in which the request is received. Since partition induces rejection of all promises across that partition, connection recovery takes distinct paths through the code where one copes, in an application dependent manner, with having been out of communication. Further support for weak consistency should come at a higher level, e.g., via the Unum model https://www.cypherpunks.to/erights/talks/uni-tea/uni-tea.ppt. Promises are a good substrate on which to build Una. On Tue, Nov 12, 2013 at 3:57 PM, Brendan Eich bren...@mozilla.com wrote: 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 promise design, now adopted by JS. http://www.erights.org/elib/concurrency/semi-transparent.html Where it says -, substitute !. In addition, promise pipelining gives us a huge win over network latency beyond the points made on that page. Fair point. Now that we've adopted such promises, we've paid the anti-transparency costs of good distributed objects. This was quite intentional. Now that we've paid the costs, we may as well collect the benefits. I think your use of we and past tense here are not shared as widely as you'd like. Anything deployed on the public web yet? /be -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: an idea for replacing arguments.length
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 was already code in the wild using the other version, so those UAs are now just supporting both signatures to avoid breaking that code. Isn't that a design choice? Sure. A bad one; the working group should have changed the name when they changed the semantics. If so, then I am arguing it was the wrong choice, but looked ok by precedent including WebIDL support. It didn't look ok. They just made a backwards-incompatible change, period. Whatever I'm trying to affect, the idea is norms Sure. My point is that in this particular case the norm of overloads in WebIDL wasn't the real norm that got broken. The don't break shipping stuff norm was the real issue. What spec of doc should promulgate a norm that says use a different name for the second createTouchList? You mean don't effing randomly break backwards compat? No spec for that, sadly. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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
necessary to add them at this late data.
As you mention, there are issues with arrow functions not being constructors,
although it probably could be dealt with similarly to how generator
comprehensions are handled (generator comprehensions are essentially treated in
the spec. as a special form of generator function).
I also need to think a bit about whether there might be any this binding issues.
Allen
On Nov 12, 2013, at 4:37 PM, Brandon Benvie wrote:
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
hierarchy and the fact that arrow functions don't have prototypes. I think
this could be worked around somehow though.
The use case I've started running into a lot is using Task.js with methods:
```js
class Foo {
foo() { //-- Promise
return Task.spawn(*() = {
const value = yield this.get(this.base + /foo);
if (yield this.bar(value)) {
return true;
}
});
}
bar(value) { //-- Promise
/***/
}
get(url) { //-- Promise
/***/
}
}
```
Without generator arrows, I'm back to using `var self = this` or
`.bind(this)`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 -- weakrefs with postmortem finalization. In this thread, we've already seen posts for other compelling uses of these, so they need not be considered purely because of their support for distributed objects. If, because of the above memory pressure point, weakrefs turn out not to be the right way to do distributed GC after all, we will still have gained by adding these to ES7. I appreciate that what I'm about to suggest isn't a small ask, but would a stronger starting point being a research demonstraction that this style of weakref (with turn based processing) is both feasible and efficient in JS. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 only regarding the remaining necessary primitive to start these paving efforts -- weakrefs with postmortem finalization. In this thread, we've already seen posts for other compelling uses of these, so they need not be considered purely because of their support for distributed objects. If, because of the above memory pressure point, weakrefs turn out not to be the right way to do distributed GC after all, we will still have gained by adding these to ES7. I appreciate that what I'm about to suggest isn't a small ask, but would a stronger starting point being a research demonstraction that this style of weakref (with turn based processing) is both feasible and efficient in JS. Yes, I accept that. Btw, is a demonstraction a cross between a demo and a distraction ;) ? Allen -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Generator Arrow Functions
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 seen something relevant in Angus Croll's slides [1] recently: let idGenerator = (id=0) = () = id++; let nextFrom1000 = idGenerator(1000); nextFrom1000(); // 1000 nextFrom1000(); // 1001 David [1] https://speakerdeck.com/anguscroll/es6-uncensored?slide=42 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 error that was trapped by a promise or promises that were eventually garbage collected, and therefore provably never-to-be-handled. It is true that this problem can be decisively mitigated in other ways, like requiring a promise to forward to a terminal done() in the same turn of the event loop, but I find this particular solution unpalatable. I do find a promise inspector compelling, one that will show an error until it is handled, but even in this case, I think it is compelling to visually elevate an unhandled error to a provably never-to-be-handled error, and this is not possible, at least outside chrome-space, without WeakRef. I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? If you think of wrapping promises in weakrefs, why not just add error handling? To me, it looks like the same amount of effort. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rev21 ES6 Draft now available
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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak callbacks?
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 lots of opportunities for human mistakes to hide failures at runtime. When you have error handlers written properly for something like 95% of your promises, catching the other 5% when they rarely fail gets pretty complicated. Consider how a developer testing out some network code might only ever run the application in the office, so they'll never see the kind of exceptions you get when running an application over a modem. Getting useful diagnostic information when one of those rare exceptions isn't handled correctly lets you fix those problems without being able to necessarily reproduce them on demand. On Tue, Nov 12, 2013 at 8:07 PM, David Bruant bruan...@gmail.com wrote: 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 error that was trapped by a promise or promises that were eventually garbage collected, and therefore provably never-to-be-handled. It is true that this problem can be decisively mitigated in other ways, like requiring a promise to forward to a terminal done() in the same turn of the event loop, but I find this particular solution unpalatable. I do find a promise inspector compelling, one that will show an error until it is handled, but even in this case, I think it is compelling to visually elevate an unhandled error to a provably never-to-be-handled error, and this is not possible, at least outside chrome-space, without WeakRef. I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? If you think of wrapping promises in weakrefs, why not just add error handling? To me, it looks like the same amount of effort. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
