Re: Error stack strawman
On Mon, Jan 11, 2016 at 10:05 PM, Mark S. Miller wrote:
> I am very interested. See the extended Causeway stack format in
> https://github.com/google/caja/blob/master/src/com/google/caja/ses/debug.js
>
>From that page, the JSON Schema-ish in an ad-hoc notation:
stacktrace ::= {calls: [frame*]};
frame ::= {name: functionName,
source: source,
span: [[startLine, startCol?], [endLine, endCol?]?]};
functionName ::= STRING;
startLine, startCol, endLine, endCol ::= INTEGER
source ::= STRING | frame;
and the logic for scraping this information from the various stacktraces
> available on today's major platforms.
>
> The "extended" is about the multiple source position layers present when
> an "eval" in one place evals a string that, at some position in the string,
> does the call. Both FF and Chrome provide these nested positions, but
> differently.
>
The nesting is represented as the recursion through "frame" in the above
grammar.
>
> See the attachments for the information successfully scraped when visiting
> on each
> of the platforms, converted to Causeway extended stack trace format, and
> then re-rendered in a common textual format. As you see, even with all the
> work at canonicalizing this information, it still differs substantially
> between platforms.
>
>
>
>
> On Mon, Jan 11, 2016 at 7:10 PM, Jonathan Kingston
> wrote:
>
>> Hey all,
>>
>> Does anyone know if there is an active interest in revisiting the
>> Error.stack strawman proposal?
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:error_stack
>>
>> I ask because CSP wanted an algorithm for getting the non standard
>> properties defined in Error objects:
>> https://w3c.github.io/webappsec-csp/#issue-f447ede5
>>
>> A simpler start may be possible in standardising just: lineNumber,
>> columnNumber and fileName
>>
>> Kind regards
>> Jonathan
>>
>
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promises as Cancelation Tokens
>
> I think F#'s cancellation approach is also worth mentioning in the
> discussion of alternatives as it has implicit but token-based automatically
> propagating cancellation.
>
If you have any good links to reference materials on F#'s cancellation
architecture, feel free to include them for future reference. I was unable
to find anything that clearly explained how implicit cancellation tokens
are discovered by child tasks, for instance.
I find implicit cancellation to be somewhat sketchy. For async functions,
it would mean that any await expression could potentially throw a
CancelError:
async function f() {
let a = await 1; // This could throw? What?
}
And there are certainly going to be scenarios where you *don't* want to
cancel a subtask. It seems to me that cancellation semantics are best left
to the async operation itself, rather than assuming "crash-and-burn".
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Error stack strawman
Hey all, Does anyone know if there is an active interest in revisiting the Error.stack strawman proposal? http://wiki.ecmascript.org/doku.php?id=strawman:error_stack I ask because CSP wanted an algorithm for getting the non standard properties defined in Error objects: https://w3c.github.io/webappsec-csp/#issue-f447ede5 A simpler start may be possible in standardising just: lineNumber, columnNumber and fileName Kind regards Jonathan ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Add support for arbitrary code inside template tags without the 'do' keyword
The thing with template strings is that they are used at runtime. This
could be slow if we're compiling things at runtime all the time,
whereas a server-side templating solution might lead JavaScript
functions compiled from templates (like in the case with Meteor Blaze
Spacebars or React JSX), which can be faster at runtime.
What are template strings good for besides the obvious benefit that
they make things like
```
var str = "llo"
console.log(`he${str} world!`)
```
easier to read than
```
var str = "llo"
console.log('he'+'str'+' world!')
```
?
Maybe writing regexes can be nicer with template strings? I gave it a
try at npmjs.com/regexr.
On Mon, Jan 11, 2016 at 8:43 AM, Manuel Di Iorio wrote:
> Yes Bob, after a personal testing with a complete template engine using the
> ES6 template strings, I realized that their use (in mine use case, of
> course) is slowest than the approach that I'm using right now (like the
> Underscore template). Thanks everyone :)
>
> ___
> 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: String.prototype.padLeft / String.prototype.padRight
Thank you for renaming padLeft/padRight to padStart/padEnd. On the treatment of code units, I was hoping to find more detail in the meeting minutes, but haven’t seen those yet. The native encoding of strings in the language, with the exception of a few parts that we haven’t been able to fix in EcmaScript 2015, is UTF-16, in which some characters take one code unit and others two code units. The current padStart/padEnd proposal doesn’t take that into consideration – it truncates at code unit boundaries rather than code point boundaries, and thus perpetuates problems stemming from obsolete assumptions about Unicode from 1995. For background on the Unicode problems in pre-2015 EcmaScript see: https://mathiasbynens.be/notes/javascript-unicode and the proposed solution that got integrated into EcmaScript 2015: http://norbertlindenberg.com/2012/05/ecmascript-supplementary-characters/ Thanks, Norbert > On Nov 17, 2015, at 13:07 , Jordan Harband wrote: > > In the TC39 meeting today, we discussed these concerns and decided to rename > the proposal from padLeft/padRight to padStart/padEnd > (https://github.com/tc39/proposal-string-pad-start-end/commit/35f1ef676f692bfc1099f9ed7c123bd2146f9294) > - and correspondingly, to investigate providing trimStart/trimEnd (alongside > the legacy trimLeft/trimRight). The consensus remained the same around > treatment of code units - which is that, like every other string method, they > should conform to the native encoding of strings in the language. > > As such, the proposal has now been approved for stage 3 in the TC39 process. > > Thanks everyone for providing your input! > > - Jordan > > On Mon, Nov 16, 2015 at 10:59 AM, Mohsen Azimi wrote: > I might be late to this but please don't use "left" and "right" for referring > to start and end of a string. In right to left languages it's confusing. As > someone who writes right-to-left we have enough of those "left" and "rights" > based on English writing direction. CSS made this mistake but corrected it in > later specs. Original box model (margin and padding) used left and right but > newer flex box spec uses start and end. Because we made a mistake in the past > we don't have to repeat it. > > Thanks, > Mohsen Azimi > > On Mon, Nov 16, 2015 at 10:44 AM Claude Pache wrote: > > > Le 16 nov. 2015 à 14:01, Alexander Jones a écrit : > > > > I see about as little use case for this as `String.prototype.blink`. > > Date/hours is better solved with zero padding formatting, not just padding > > out the already stringified number (think negative values -42). Same > > applies to filenames for lexicographical sort. Fixed length fields in wire > > protocols already need to be converted to bytes first before padding, which > > makes the use of this feature impossible. > > Sure, in all those cases I could have used `sprintf` instead of `str_pad`. > However, the equivalent of neither one is natively available in JS. > > I could write a tagged template that does the equivalent of `sprintf` And > `.padLeft^H^H^H^HStart` and `.padEnd` would be nice to have for writing more > easily such a template,... oh well... :-/ > > —Claude > > > > > > > On Monday, 16 November 2015, Claude Pache wrote: > > Here are my typical use cases (found by scanning uses of "str_pad" in my > > PHP codebase): > > > > * transferring data through a protocol that uses fix-length fields; > > * formatting things like date/hours, e.g. "08:00" for "8am"; > > * generating filenames of fixed length, so that they sort correctly, e.g. > > "foo-00042.txt"; > > * generating codes of fixed length (e.g. barcodes). > > > > In all those cases, the set of characters is typically limited to ASCII or > > ISO-8559-1. > > Moreover, the filler string consists always of one ASCII character (usually > > " " or "0"). > > > > —Claude > > > > ___ > > 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 > > ___ > 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises as Cancelation Tokens
> Another cancellation scenario is when the consumer of an asynchronous task no longer > needs the result of an operation. In this case, they will only have access to the Promise > unless the cancellation token is routed to them through some other path. For what it's worth - this is exactly how promise cancellation is modeled in bluebird 3 and we have found it very nice. I think the distinction between cancellation because of disinterest and cancellation because we actively want to cancel the operation is very important - props for nailing it. That said - I think most scenarios that work with tokens work without them and vice versa. I think F#'s cancellation approach is also worth mentioning in the discussion of alternatives as it has implicit but token-based automatically propagating cancellation. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises as Cancelation Tokens
One key thing to recognize is that there are different reasons to cancel an operation and as a result, different approaches to cancellation. .NET cancellation tokens address one scenario (and do it fairly well), where the objective is for specific operations to expose cancellation and allow the caller to set up a way to cancel the operation once it is in progress. This requires co-operation on both sides but is very easy to debug and reason about. However, this does not address all cancellation scenarios. Another cancellation scenario is when the *consumer* of an asynchronous task no longer needs the result of an operation. In this case, they will only have access to the Promise unless the cancellation token is routed to them through some other path. This becomes especially unwieldy if you are dealing with a graph of asynchronous operations, where you want this 'no longer needed' property to propagate through all of the promises. This is somewhat equivalent to how you want a garbage collector to collect a whole tree of objects once they are no longer reachable. In JS (and in my opinion, basically all language environments) you want this to be explicit even if the GC is able to lazily flag the result of a promise as no longer needed. In the 'result no longer needed' scenario there are also cases where you do not want to cancel the operation even if it is not needed anymore. A third form of cancellation is already addressed by Promise implementations - error handling. In this case, an error occurs and the whole asynchronous process (usually) needs to be aborted and unwound so that the error can be responded to. In this scenario cancellation can occur at any time and in some cases it is not possible for the application to continue correctly under these circumstances. You could use exceptions to implement the other forms of cancellation, but it's pretty unwieldy - and injecting exceptions into code that doesn't expect that is a generally bad policy. .NET used to allow injecting exceptions into other threads but has since deprecated it because of all the nasty corner cases it introduces. In my opinion cancellation tokens are a great model that does not require any browser vendor/VM implementer support, but it can be beneficial for implementations of specific operations (i.e. XHR) to provide some sort of cancellation mechanism. Essentially, the XHR object acts as the cancellation token and you call a method on it to cancel. In most cases you can implement that in user space. 'Result no longer needed' requires some amount of support at the language/base framework level, so that it is possible to flag this state on any given Promise and it is possible for all Promise consumers to appropriately propagate this state through graphs of asynchronous dependencies. For example, cancelling a HTML pageload should flag any dependent image/script loads as 'no longer needed', but not necessarily *abort* them (aborting might kill the keepalive connection, and allowing the request to complete might helpfully prime the cache with those resources). -kg On 5 January 2016 at 19:58, Kevin Smith wrote: > Thanks for posting this. Great stuff! > >> >> On a page that loads 100 images four at a time, you would want 4 cleanup >> actions registered, not 100. > > > And in order to keep it to 4 you need a way to unregister the action when > you complete the operation, which the promise API doesn't give you. I see. > > Conceptually, you could of course set some "complete" flag when you finish > the operation and then have the cleanup action early-exit if that flag is > set, but that would be unwieldy. And it wouldn't stop the unbounded growth > of the promise's handler list. > > Interesting! > > > ___ > 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: Add support for arbitrary code inside template tags without the 'do' keyword
Yes Bob, after a personal testing with a complete template engine using the ES6 template strings, I realized that their use (in mine use case, of course) is slowest than the approach that I'm using right now (like the Underscore template). Thanks everyone :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add support for arbitrary code inside template tags without the 'do' keyword
> The idea to develop in native way a good templating engine is exciting
and I'm looking forward for its complete implementation :)
This topic arose in an earlier thread that I'm too lazy to track down. Some
insane person from Microsoft? actually showed us how to write ifs and
everything using horribly nested template strings.
Bottom line, template strings, with or without `do`, which is both
unnecessary and would break everything, are not a good starting point for
writing a templating engine. I'd definitely take a different approach.
Bob
On Mon, Jan 11, 2016 at 6:06 PM, Caitlin Potter
wrote:
> > Watch your precedence, Caitlin. You'll need to wrap that arrow in
> parentheses like so:
>
> Yes, I guess arrow functions aren’t a PrimaryExpression — doesn’t really
> matter, though
>
> On Jan 10, 2016, at 11:58 PM, Michael Ficarra
> wrote:
>
> Watch your precedence, Caitlin. You'll need to wrap that arrow in
> parentheses like so:
>
> ```js
> `Hello ${(_ => {
> if (a == 2) {
> console.log(‘world’);
> }
> })()}`;
> ```
>
> Michael
>
> On Sun, Jan 10, 2016 at 7:12 PM, Caitlin Potter
> wrote:
>
>> Do-Expressions are still floating around Stage 0, there’s no guarantee
>> that they will be incorporated into the language.
>>
>> The feature is implemented in v8 behind a flag, and can be used in Chrome
>> Canary by launching the browser with `—js-flags=“—harmony-do-expressions”`,
>> which would enable you to try it out.
>>
>> **INTERMISSION — Slightly more on-topic portion of post follows after a
>> short coffee break**
>>
>> However, to answer your question, you can implement an
>> immediately-invoked-function-expression, like this:
>>
>> ```js
>> `Hello ${_ => {
>> if (a == 2) {
>> console.log(‘world’);
>> }
>> }()}`;
>> ```
>>
>> So this wouldn’t depend on the Do-Expressions proposal, and wouldn’t
>> require a keyword per se, although you’d still have some extra tokens
>> making things a bit harder to read.
>>
>> It’s unlikely that the grammar would be changed to accommodate this use
>> case, given that people are using template literals already, and the
>> use-case is already supported by other means.
>>
>> On Jan 10, 2016, at 9:23 PM, Manuel Di Iorio wrote:
>>
>> Hi, I asked around and somebody said that there will be the possibility
>> to execute arbitrary code inside the template tags, using the *'do'*
>> keyword in this example way:
>>
>>`Hello ${ do if (a == 2) {
>>> console.log(' world');
>>> } }`
>>
>>
>> Is there the possibility in future to implement that feature without the
>> keyword?
>> What is the plan *(read 'estimated date')* for the rollout of this
>> feature ?
>>
>> The idea to develop in native way a good templating engine is exciting
>> and I'm looking forward for its complete implementation :)
>> ___
>> 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
>>
>>
>
>
> --
> Shape Security is hiring outstanding individuals. Check us out at
> *https://shapesecurity.com/jobs/
>
Re: Add support for arbitrary code inside template tags without the 'do' keyword
> Watch your precedence, Caitlin. You'll need to wrap that arrow in parentheses
> like so:
Yes, I guess arrow functions aren’t a PrimaryExpression — doesn’t really
matter, though
> On Jan 10, 2016, at 11:58 PM, Michael Ficarra
> wrote:
>
> Watch your precedence, Caitlin. You'll need to wrap that arrow in parentheses
> like so:
>
> ```js
> `Hello ${(_ => {
> if (a == 2) {
> console.log(‘world’);
> }
> })()}`;
> ```
>
> Michael
>
> On Sun, Jan 10, 2016 at 7:12 PM, Caitlin Potter > wrote:
> Do-Expressions are still floating around Stage 0, there’s no guarantee that
> they will be incorporated into the language.
>
> The feature is implemented in v8 behind a flag, and can be used in Chrome
> Canary by launching the browser with `—js-flags=“—harmony-do-expressions”`,
> which would enable you to try it out.
>
> **INTERMISSION — Slightly more on-topic portion of post follows after a short
> coffee break**
>
> However, to answer your question, you can implement an
> immediately-invoked-function-expression, like this:
>
> ```js
> `Hello ${_ => {
> if (a == 2) {
> console.log(‘world’);
> }
> }()}`;
> ```
>
> So this wouldn’t depend on the Do-Expressions proposal, and wouldn’t require
> a keyword per se, although you’d still have some extra tokens making things a
> bit harder to read.
>
> It’s unlikely that the grammar would be changed to accommodate this use case,
> given that people are using template literals already, and the use-case is
> already supported by other means.
>
>> On Jan 10, 2016, at 9:23 PM, Manuel Di Iorio > > wrote:
>>
>> Hi, I asked around and somebody said that there will be the possibility to
>> execute arbitrary code inside the template tags, using the 'do' keyword in
>> this example way:
>>
>>`Hello ${ do if (a == 2) {
>> console.log(' world');
>> } }`
>>
>> Is there the possibility in future to implement that feature without the
>> keyword?
>> What is the plan (read 'estimated date') for the rollout of this feature ?
>>
>> The idea to develop in native way a good templating engine is exciting and
>> I'm looking forward for its complete implementation :)
>> ___
>> 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
>
>
>
>
>
> --
> Shape Security is hiring outstanding individuals. Check us out at
> https://shapesecurity.com/jobs/
