Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 11/22/19 12:44 PM, #!/JoePea wrote:
And (maybe unfortunately) for many people that amounts to being 
equivalent to "window".


It _is_ equivalent to "window".  The thing is, "window" returns a 
WindowProxy, not a Window...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 11/21/19 5:21 PM, #!/JoePea wrote:

They were duly marked invalid, because the problem was with the expectations, 
not the behavior...


It's a design bug.


Well, sure, if we're talking about the fact that there is no clear 
separation in the web platform's exposed objects between "a container 
that can be navigated" and "the thing currently loaded in that 
container"; both are represented, kinda weirdly, by "window".



I know, impossible to fix.


Then why was you previous mail saying that browsers should fix it?


I'm not sure I even know what "globalThis" means now. :)


It means "that thing that `this` would return in global scope".  No 
more, no less.


In practice, in web pages, that thing is a WindowProxy object as defined 
at 
https://html.spec.whatwg.org/multipage/window-object.html#the-windowproxy-exotic-object


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 11/16/19 12:52 PM, #!/JoePea wrote:

That's the thing: the only people that may get confused are Ecmascript
and JS-Engine experts who know the internals very intimately.


No, it's just people who have functions return values they do not expect.


and for those people that could possibly get confused, it would be
because they are familiar with browser internals (or hit a browser
*bug* like you describe)


No, you misunderstand.  The bug reports were filed because the behavior 
was not what people expected.  They were duly marked invalid, because 
the problem was with the expectations, not the behavior...



For all intents and purpose, every developer I've talked to, and every
article I've read, treats things like `window` as the global object.


And this is mostly fine as long as you don't call functions from 
navigated-away-from windows. Which most people don't, most of the time. 
And when they do, they get _very_ confused by the results, because 
reality does not match what they had been told.


But that doesn't mean we should double down on telling them things that 
don't match reality.



I strongly believe that things should be made intuitive for the vast
majority of users


I agree, but in this specific context, what does that mean in terms of 
concrete proposals you are making?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: function invocation with just commas for explicit undefined optional arguments in the middle

[Boris Zbarsky]

On 11/1/19 5:10 AM, Cyril Auburtin wrote:
yes true, it's even more annoying with eslint, you have to configure it 
with https://eslint.org/docs/rules/no-unused-vars#argsignorepattern for 
example


That's talking about function _declarations_, whereas the original 
proposal in this thread is about function _invocations_.


To be fair I considered this case mostly for `Array.from({length: n}, 
(,i) => i)`


Right, that's a function declaration, not invocation.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modify Promise.all() to accept an Object as a parameter

[Boris Zbarsky]

On 10/12/19 12:52 AM, Jacob Bloom wrote:

const responses = await Promise.all(requests);


As opposed to:

  const responses = await Primise.all(requests.values());

which works right now?

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 10/7/19 1:56 PM, #!/JoePea wrote:

Who's going to write code like that anyways?


In the general form of "function from a navigated-away-from document 
runs because it's called by some script from outside the document", I've 
seen this come up a number of times in web browser bug reports.



Everyone's moving to ES modules, where `this` for accessing the global
is just `undefined`.


It's not just "this".  The same thing applies to "window", "self", etc, 
etc.  There is no way to actually get your hands on the global object 
explicitly in a DOM Window scope: you always get the WindowProxy instead.



It's highly unlikely that any concept other than
"global object" will ever be conceived by the vast majority of users,
especially future users.


Well, the thing that globalThis returns is NOT the global object, and 
telling people that it is will just confuse them when it behaves in a 
way they don't expect.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 10/7/19 1:29 AM, #!/JoePea wrote:

I've never written any sort of code that can prove or verify any of
what you all are talking about. Mind showing code samples?


Did you not see 
https://mail.mozilla.org/pipermail/es-discuss/2019-October/053033.html ?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 10/6/19 2:58 PM, Raul-Sebastian Mihăilă wrote:
Also let's not forget that the WindowProxy behavior contradicts the JS 
object model in that the non-configurable 'something' own property of 
the window proxy is removed.


There is a proposal for addressing that.  Firefox has been shipping it 
in Nightly for a while, but we have seen zero interest from any other 
browsers for addressing that issue...


See https://github.com/tc39/ecma262/pull/688#issuecomment-430648819 and 
following comments for the details of the proposal.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

[Boris Zbarsky]

On 10/4/19 2:39 PM, #!/JoePea wrote:

but the global `this` you captured still has the same identity as the new 
reference.


Interesting, I never knew that. Do you have a code sample to show how
to detect or prove that?


Sure.  The following code logs "true, 5, 5, 5, 5, true, undefined, 
undefined, undefined, 5" in Firefox, Chrome, and Safari, which shows 
both the identity staying the same and the property disappearing from 
the WindowProxy, as well as showing the difference between the 
WindowProxy and the Window (the bareword lookup finds the var on the 
global, which is the Window, while `self.something` goes through the 
WindowProxy, which now points to the new `Window`):




  
var state = "first-load";
var cachedThis;
var cachedValueGetter;
var cachedBarewordGetter;
function loadHappened(iframe) {
  var win = iframe.contentWindow;

  if (state == "first-load") {
cachedThis = win.getGlobalThis();
cachedValueGetter = win.getPropertyValue;
cachedBarewordGetter = win.getBareword;
console.log(win == cachedThis);
console.log(win.something);
console.log(cachedThis.something);
console.log(cachedValueGetter());
console.log(cachedBarewordGetter());
state = "second-load";
iframe.srcdoc = iframe.srcdoc.replace("var something = 5;", "");
return;
  }

  console.log(frames[0] == cachedThis);
  console.log(frames[0].something);
  console.log(cachedThis.something);
  console.log(cachedValueGetter());
  console.log(cachedBarewordGetter());
}
  
  


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bind function without thisArg

[Boris Zbarsky]

On 1/14/19 9:47 AM, Andrea Giammarchi wrote:
rather because of the bloat it produces once transpiled: 


Hold on.

The transpiling is necessary because of lack of what features in 
implementations?


And what is the set of implementations that will lack those features but 
support bindArgs?


(None of that is an argument against having bindArgs in core per se; I'm 
just trying to understand the transpiling issue here.)


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Expectations around line ending behavior for U+2028 and U+2029

[Boris Zbarsky]

On 10/29/18 2:04 PM, Logan Smyth wrote:
This means that the expectation, from the standpoint of 
Unicode spec, is that all existing parsers and tooling for all languages 
would also be updated to have line numbering that include U+2028/29


There is also the somewhat widespread opinion that Unicode goofed by 
adding those characters and that the best thing to do with them is to 
simply ignore them.   So I expect a number of languages and tools to do 
just that.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise finally

[Boris Zbarsky]

On 2/23/18 9:30 AM, Michael Luder-Rosefield wrote:
Whenever you chain a promise with a then/finally, you're basically 
letting the runtime look at the callbacks at some arbitrary point in the 
future, no?


Not if the promise is already known to be resolved.  In that case, the 
exact behavior of the runtime is very clearly specified.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native Tensor support

[Boris Zbarsky]

On 1/27/18 9:53 PM, Isiah Meadows wrote:

4. For style elements and ref-accessible elements, you could still execute the 
changes in set slices, splitting on nodes/callbacks that require awareness of 
past effects. (This could just be a flag.) However, these are exceedingly rare.


This is not longer sounding embarrassingly parallel, fwiw, since you 
have to not do later things until earlier things are done under various 
conditions...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Native Tensor support

[Boris Zbarsky]

On 1/27/18 1:42 PM, Isiah Meadows wrote:

That is true, but script elements generated via the DOM are not inline
script elements


Just to make sure we're on the same page:

  var script = document.createElement("script");
  script.textContent = 'console.log("script running")';
  console.log("before");
  document.body.appendChild(script);
  console.log("after");

That is an inline script, it's generated via the DOM, and it runs sync 
before the appendChild call returns, as you can see by the order of 
messages in your console.



and they can't tell the browsers to *not*
schedule an async task for things the spec requires them to.


In my example there, the spec requires browsers to run the script sync. 
There's no "HTML semantics" involved, if you mean parser behavior by 
that; just DOM manipulation.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Performance of frozen vs non-frozen objects

[Boris Zbarsky]

On 12/26/17 9:07 AM, Mark Miller wrote:

I tried https://jsperf.com/freeze-vs-seal-vs-normal/3 and
https://jsperf.com/freeze-vs-seal-vs-normal/28 on Chrome, FF, and
Safari. I don't know why the bar charts are not updating. I am
traveling and do not currently have access to a machine running Edge.

Could someone who has access to all four browsers, and knows how to
get the displayed data to update, try these on all four? Thanks.


It's pretty hard to run both Edge and Safari on the same setup.

That said, at least https://jsperf.com/freeze-vs-seal-vs-normal/3 is 
being completely optimized away in Firefox for all of the testcases.  Or 
at least running at the same speed as 
; for some reason jsperf 
is refusing to create a revision that has both the control and the 
actual tests...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Boris Zbarsky]

On 10/24/17 2:03 PM, /#!/JoePea wrote:

I was trying to patch `Element` because there's also `SVGElement`


For what it's worth, looks like for the moment custom elements has given 
up on the idea of custom non-HTML elements...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

[Boris Zbarsky]

On 10/24/17 12:50 PM, /#!/JoePea wrote:
Is it possible to monkey-patch an intermediate constructor of a built-in 
subclass?


Right now, no.

For example, suppose I want all `Element` instances in a web app to have 
new instance properties, is there a way to monkey-patch the Element 
constructor so that when I make a custom element by extending a subclass 
of `Element` that the new logic will fire?


If you want to limit this to custom elements you control, in the sense 
of , then 
"sort of, yes".  You could just define a class that extends HTMLElement, 
have its constructor do whatever instance-property-setting you want, and 
have all your actual custom element classes extend that one class.


If you want to do this to custom elements you do NOT control, you can 
sort of do it too, using Andrea's suggestion later in this thread: as 
long as your code runs first, you can set your class as 
window.HTMLElement so everyone else is extending you, not the "real" 
HTMLElement.



const OldElement = window.Element


This won't work, because Element is not constructible, so all the 
constructor behavior lives in HTMLElement.  But if you did this with 
HTMLElement, I would expect it would work, as in Andrea's suggestion.


Is there a way to monkey patch a constructor in the middle of a built-in 
prototype chain or to otherwise inject construction logic to base 
classes of existing class hierarchies?


Right now, no.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

[Boris Zbarsky]

On 10/2/17 7:10 AM, Xavier Stouder wrote:

Don't know what Boris mean when he talks about recreation bits


Fwiw, it looks like the code at 
https://esbench.com/bench/595c1b1899634800a03488b9 does not have the 
array recreation bits (function whatever(...args)) that earlier 
benchmarks for this had.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

On 9/13/17 1:55 PM, Naveen Chawla wrote:

`x`  `[y]` would be invalid syntax, right?


Wrong.


What am I missing?


This is exactly why automatic X insertion with complicated rules is a 
bad idea for all values of X.  ;)


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement 
produces comma" version of this proposal), everything would work 
perfectly, no?


If by "perfectly" you mean "have hard-to-predict somewhat nonlocal 
behavior that makes any code relying on this a hard-to-read footgun", 
then the answer might be "yes".  For pretty much any other definition of 
"perfectly", I'm fairly sure the answer is "no".


Great to hear those counter-examples as I don't know enough about ASI, 


Still in the context of ASI, here are some examples of why ASI is a bad 
idea:


1) What does this return?

  function f() {
return
5;
  }

2) What does this alert?

  var str = "hello";
  var x = str
  [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

  function doStuff(
  x
  y
  z
  ){
  }

if someone changes doStuff to take an array as the second arg and you 
modify the call as:


  function doStuff(
  x
  [y]
  z
  ){
  }

suddenly you need to insert a comma after the "x" to preserve the right 
semantics, no?  This is not terribly intuitive or obvious.  It gets even 
worse in a situation like this:


  function doStuff(
  x
  /* The next argument is an array for good reasons that we
 will now expound on in a long comment, etc, etc */
  [y]
  ){
  }

Quick, tell me without testing this or looking at the spec for a while 
whether this is a valid call to doStuff, with one argument, or a syntax 
error that would trigger comma insertion.


But more generally, if you just use your favorite search engine on the 
phrase "automatic semicolon insertion", you will get a slew of articles 
explaining the pitfalls.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

On 9/13/17 9:05 AM, Naveen Chawla wrote:
Can someone remind me of the problem doing it this way, if any? 


You mean apart from all the existing footguns ASI has?

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: FW: Removal of language features

[Boris Zbarsky]

On 7/27/17 2:02 AM, Michael Kriegel wrote:

4. At a fixed date (e.g. 24 Months after X) all browsers must stop
supporting the feature


How do you plan to enforce this?

Please note that the people representing browsers in this committee may 
not (and afaict generally do not) make ship/no-ship product decisions 
for their browsers, so the can't even credibly commit to what you suggest.



Authors of Websites, for which there is still interest, will update
their code. Other websites will just break and nobody will care.


Unfortunately, you're wrong.  That's because interest is asymmetric: 
_users_ may have interest in a site even if the _author_ does not.  So 
it's quite possible (and in fact has happened before) that sites will 
not be updated, they will break, and users will in fact care.


This happens all the time, even with well-advertised multi-year 
deprecations, well publicized cutoff times and large companies that have 
the resources to update their sites if they want to.  See the story of 
Google Hangouts, for example.



So I do not see a risk of "breaking the web" when there is such a clear
plan set up. There would be just the question how browser vendors could
be punished, if they do not comply and try to get an advantage over
other browsers by continuing support of those old features...?


Good luck with that.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Boris Zbarsky]

On 7/23/17 1:19 AM, Alexander Craggs wrote:

I also feel that it is *impossible* for vendors to add such changes to
make error messages more useful because in the JavaScript syntax
specified ten years ago "await" didn't exist and it would just be an
unexpected string.


Just to be clear, the "unexpected string" in your testcase is the "hi", 
not the await keyword.  Safari's error message, which I cited earlier in 
this thread, makes this much more clear than Chrome's.



We would have to add some new detection feature for
this newer flavour to allow better messages.


Again, no; see Firefox behavior here.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JavaScript Versioning

[Boris Zbarsky]

On 7/23/17 12:30 AM, Alexander Craggs wrote:

Say we create such versioning, it would allow us to improve the language
so much more than we're currently able to, we'd no longer have to stick
with useless error messages for forgetting `async`:

```js
< function u() { let x = await "hi" }

Uncaught SyntaxError: Unexpected string


In Chrome, that's what you get.  In Firefox, you get:

  SyntaxError: await is only valid in async functions

which is about what you're asking for.  In Safari, you get:

  SyntaxError: Unexpected string literal "hi". Expected ';' after 
variable declaration.


which is a moderately more informative version of the Chrome error message.

In any case, it's quite clear that a JS engine _can_ report the "right" 
error here; Firefox does so.  Engines that don't do that should just 
start doing it, and this should not involve any spec changes.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

[Boris Zbarsky]

On 7/4/17 9:34 PM, Jordan Harband wrote:

The results I get range from a 2x improvement for 2 numbers, to a 3x
improvement for 1000 numbers


Again, did you test without the array destructuring and recreation bits? 
 I expect those dominate here, just like in the jsbench benchmarks 
posted before.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.minmax

[Boris Zbarsky]

On 6/29/17 1:49 AM, T.J. Crowder wrote:

I was going to make that very point, backed by a jsPerf, but the jsPerf
doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array
It says the minmax is faster on a 10-entry array (it reports the
separate calls as 46-48% slower on V8 and SpiderMonkey).


See https://jsperf.com/two-calls-vs-one-no-destructuring/1 which is the 
same as the above-linked testcase but doesn't do destructuring of an 
array into an arglist and the collapsing of an arglist into an array for 
every call.  In that one the two-call version is in fact faster.


That is, the cost of allocating and filling the two-element return value 
array is much smaller than the cost of allocating and filling the 
20-element array.  Since the two-call testcase in 
https://jsperf.com/two-calls-vs-one-returning-array does the latter 
twice, it ends up slower than the version that only does it once.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are thrown errors in a try block considered to be handled even if there's no catch block?

[Boris Zbarsky]

On 6/23/17 12:39 PM, Boris Zbarsky wrote:

The rest of what you see is because the console API and the internal
error reporting use slightly different mechanisms for notifying about
new messages:


I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375899 to 
hopefully align these more, fwiw.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are thrown errors in a try block considered to be handled even if there's no catch block?

[Boris Zbarsky]

On 6/23/17 7:01 AM, T.J. Crowder wrote:

On Firefox, I get

```
1
2; cancelling
dispatch complete
then
uncaught exception: 1
uncaught exception: 2
```

...where the traces point to the `dispatchEvent` line. So it seems to
store them up and then report them.


I should note that if you add this to your testcase:

  window.onerror = function(...args) {
console.log(...args);
  }

then you will see something like this in Firefox:

1
uncaught exception: 1 foo.html 20 1 1
2; cancelling
uncaught exception: 2 foo.html 20 1 2
dispatch complete
then
uncaught exception: 1
uncaught exception: 2

where those first two "uncaught exception" lines are the logs from the 
error handler.  So for the parts that are web-observable, Firefox does 
the error reporting synchronously.


The rest of what you see is because the console API and the internal 
error reporting use slightly different mechanisms for notifying about 
new messages: the former does it immediately and the latter does it 
after an event loop turn, because it's working with a threadsafe logging 
facility that always handles things via a job queued on the main event loop.



Replicating the Firefox behavior in your own `dispatchEvent` function is
fairly doable: Catch the exceptions, store them, and then fire them off
asynchronously when done (https://jsfiddle.net/gwwLkjmt/):


That won't give you the right onerror behavior.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.sincos(x)?

[Boris Zbarsky]

On 6/22/17 2:13 PM, Алексей wrote:

function sincos (a) {
const sin = Math.sin(a)
const cos = (1 - sin**2)**0.5


This will completely fail for a near pi/2.  It will return zero instead 
of the correct small but nonzero value it should be returning.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Math.sincos(x)?

[Boris Zbarsky]

On 6/22/17 2:02 PM, Robert Poor wrote:

However, most implementations for cos(theta) actually generate
sin(theta) as a "byproduct" (and vice-versa).


At first glance, the v8 implementation of cos typically uses a Taylor 
series and does not compute sin.


And the SpiderMonkey implementation of cos looks like it just calls the 
C standard library cos, so also doesn't compute sin(theta) in a way 
visible to it.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

[Boris Zbarsky]

On 5/23/17 3:44 AM, Alex Vincent wrote:

 3. I create matching "membrane" proxies for wetB and wet_b named dryB
and dry_b,


Shouldn't you also have a proxy for webB.prototype (called dryproto, 
let's say)?  Otherwise your "wet" and "dry" object graphs are actually a 
single kind of weird object graph...



Then:

  * Reflect.get(wetB, "prototype") === Reflect.getPrototypeOf(wet_b)
  * Reflect.get(dryB, "prototype") !== Reflect.getPrototypeOf(dry_b)


And then Reflect.get(dryB, "prototype") === dryproto === 
Reflect.getPrototypeOf(dry_b), I would hope.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A WeakMap where values (not keys) are weak references?

[Boris Zbarsky]

On 3/21/17 2:15 AM, /#!/JoePea wrote:

I'd like to have something like a WeakMap where the keys can be
primitives and the values are weakly-held Objects


It might be worth searching the archives: this has been proposed 
multiple times and discussed at quite some length.


If there isn't an existing document that summarizes the discussions (and 
quick searching doesn't find one in the top several hits, though it does 
find https://esdiscuss.org/topic/what-is-the-status-of-weak-references 
at the very least), there really should be one...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

bugs.ecmascript.org has an expired certificate

[Boris Zbarsky]

"The certificate expired on May 25, 2016 at 8:00 AM. The current time is 
March 21, 2017 at 10:10 AM." is what my browser tells me.


I know issue tracking has moved to github, but there are still links 
pointing into the bugs.ecmascript.org tracker in various places, and 
finding the corresponding github issue (if there is one) is impossible 
if you can't load pages from the old tracker...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Which engine is right about with statement and Symbol.unscopables?

[Boris Zbarsky]

On 2/20/17 10:00 AM, Michał Wadas wrote:

http://stackoverflow.com/questions/40595389/why-does-browser-get-symbol-unscopables-twice

Which implementation is bugged? Can someone familiar specification
details fill bug in proper engine?


  var a, b, flag = true

  with (a = { x: 7 })
with (b = { x: 4, get [Symbol.unscopables]() { return { x: flag=!flag } } })
  x++

   // Chrome   FF
  console.log(a)   // {x:5}{x:7}
  console.log(b)   // {x:4}{x:8}


TL;DR: both are buggy.  The correct output is {x:7}, {x:5}.  I have 
filed https://bugzilla.mozilla.org/show_bug.cgi?id=1341061 and 
https://bugs.chromium.org/p/v8/issues/detail?id=5992


I think we come into 
https://tc39.github.io/ecma262/#sec-postfix-increment-operator-runtime-semantics-evaluation 
here.  The first question is what "lhs" ends up being.


I'm pretty sure that evaluating "x" will call 
https://tc39.github.io/ecma262/#sec-getidentifierreference which will 
start with envRc being the object Environment Record created by the 
"with (b)" and start looking for the binding for "x".  Specifically, it 
will call HasBinding() on envRec, which will call 
https://tc39.github.io/ecma262/#sec-object-environment-records-hasbinding-n 
which will check @@unscopables.  It will get x: false, I think (assuming 
that none of the bareword lookups used in defining "b" end up looking up 
things in the "with (b)" environment.  So we will get back a Reference 
whose base is the object Environment Record for "with (b)".  This claim 
could use double-checking.


Anyway, if that's correct, then 
https://tc39.github.io/ecma262/#sec-postfix-increment-operator-runtime-semantics-evaluation 
step 2 does https://tc39.github.io/ecma262/#sec-getvalue which in step 
6a goes to 
https://tc39.github.io/ecma262/#sec-object-environment-records-getbindingvalue-n-s 
which will return the value "4" afaict, without ever checking @@unscopables.


And then 
https://tc39.github.io/ecma262/#sec-postfix-increment-operator-runtime-semantics-evaluation 
step 4 will call https://tc39.github.io/ecma262/#sec-putvalue which in 
step 7a will call 
https://tc39.github.io/ecma262/#sec-object-environment-records-setmutablebinding-n-v-s 
which will set b.x to 5.


So as far as I can tell from the spec, the output should be: {x:7}, 
{x:5}, and there should be one single call to the getter.  And both of 
the browsers tested are buggy.


In Safari, for what it's worth, I get the output I expect: {x:7}, {x:5}.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/21/17 1:14 AM, Jordan Harband wrote:

In that case I would be delighted if you filed this as an issue on the repo.


I would be delighted to do it, if it had not been filed back in 
November, including the comments about how your description of the 
Firefox behavior doesn't match the actual behavior.


See https://github.com/ljharb/proposal-error-stacks/issues/3

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/20/17 2:26 PM, Jordan Harband wrote:

Also note that for changing existing behavior to be "web incompatible",
all the browsers have to *agree* on it


That may or may not be true.

But in any case, this proposal specifies behavior that disagrees with 
all browsers, who agree with each other.  So it's "web incompatible" 
even by your very restrictive definition.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/19/17 12:24 PM, Isiah Meadows wrote:

1. What does Firefox do with the getter on non-errors?


Oh, I didn't make that clear, did I?  On a non-error in the getter, we 
have an Error object or Error.prototype (which appeared somewhere on our 
receiver's proto chain).  Those objects all have, in Spidermonkey, an 
internal slot that stores information about the stack.  The getter uses 
the information in that internal slot to create a string and return it.



2. How breaking is having the getter and setter throwing on non-errors?


Well, when we tried to do it it didn't even pass our test automation, so...

In particular it would throw on anyone doing ES5-style subclassing of 
Error and then doing anything with .stack.



I'm struggling to see how it'd be that breaking. It's a getter, not a
method, so it requires a call to `__locateGetter__` or
`Object.defineProperty` to even access.


No, it just requires that you have an Error on your prototype chain but 
not be an Error yourself, and suddenly you have exceptions everywhere.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/19/17 2:33 AM, Jordan Harband wrote:

The beginnings of the Error Stacks proposal is now up
at https://github.com/ljharb/proposal-error-stacks


I can't speak for other browsers, but the description of the Firefox 
behavior in that proposal does not look correct.


Here's what I understand the Firefox behavior to be:

1)  The getter does NOT throw on a non-Error receiver.  Doing that
would be very much not web-compatible.
2)  The behavior of the getter is as follows:

  a) If the receiver is not an object, throw.
  b) Walk up the prototype chain (note: this can invoke proxy
 [[GetPrototype]] traps) until we find either an Error object
 or Error.prototype.  If we reach null before doing either of
 those, throw.
  c) Return the stack string for the object we found.  For
 Error.prototype this would be the empty string; for an Error
 object it's the stack captured when it was created.

3)  The setter doesn't care what the receiver is, as long as it's
an object.  Again, throwing for non-Error would not be
web-compatible.
4)  The actual behavior of the setter is to throw if called with
no arguments.  Otherwise, the setter invokes its receiver's
[[DefineOwnProperty]] with the property name "stack" and a
property descriptor that looks like this:

{ [[Value]]: setterArg, [[Configurable]]: true,
  [[Writable]]: true, [[Enumerable]]: true }

where setterArg is the first argument that was passed to the
setter.

I should note, per items 1 and 3 above, that the proposal at 
https://ljharb.github.io/proposal-error-stacks/ as of today is in fact 
not web-compatible.


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/11/17 8:55 PM, Isiah Meadows wrote:

I was expecting the error to throw on invoking the getter. Calling
`Object.getOwnPropertyDescriptor` should *never* do that (spec invariant).


There is no getter, from the JS point of view.  It's a value property. 
That's the whole point of this conversation.


We seem to be in violent agreement that what v8 is doing is a spec 
violation, fwiw.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/11/17 3:12 PM, Isiah Meadows wrote:

Okay. The error stack being constructed that early is odd, though.


I'm not sure I follow.  The error stack in SpiderMonkey and V8 (and 
JavaScriptCore too, afaict) is captured at the point when the Error 
object is created.  The captured thing is information that can be used 
to construct a stack string later.


Then getting .stack constructs the stack string.  This operation is 
somewhat expensive, so is deferred until someone asks.


In V8, the stringification process includes an explicit 
script-modifiable hook: the "prepareStackTrace" property of the Error 
constructor.


Is the odd part the stack capture during Error object construction? 
Were you expecting it to only be captured at the throw point?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/11/17 6:43 AM, Isiah Meadows wrote:

Not if it's (likely) throwing from the `new Error`.


It's not.  The "stack" property in V8 quacks like a value property for 
the most part, but the first access to it invokes some code that does 
the (lazy) stack string construction.  That process involves calling 
Error.prepareStackTrace if such a thing exists.


Specifically, as of today, see 
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/messages.cc#L927-L954 
which is called from 
https://github.com/v8/v8/blob/d5a0860e87b5f8d88432cf628f4bbc0cc922317f/src/accessors.cc#L1169


The whole setup is basically designed to have things that look like data 
properties but actually involve executing code to compute the property 
value (and possibly executing code when the "value" property is set).


SpiderMonkey has similar things as well, though we've been getting rid 
of them as much as possible.  The obvious one that remains is .length on 
Array objects.  This allows Array objects to be non-exotic for practical 
purposes in terms of their engine representation, and hence not suffer 
the performance penalties exotic objects suffer.  In spec terms, of 
course, Array instances are just exotic objects.  In an ideal world, the 
implementation detail is just that and is not observable


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/10/17 2:54 PM, Michał Wadas wrote:

Internal slots correspond to internal state that is associated with
objects and used by various ECMAScript specification algorithms.
*Internal slots are not object properties* and they are not inherited.


OK, so having an internal slot for the value of .stack would be a spec 
violation too, yes?



So it's spec violation to have custom [[GetOwnProperty]] implementation
on ordinary objects.


Sure.  Ideally such things would be brought to the committee so the spec 
could be adjusted as needed for real-life (or implementations changed if 
real life does not actually require the exotic behavior).  That's what's 
happened in the past for things like the global object.


Really, .stack or equivalent just needs to be standardized; then this 
will all get sorted out.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/10/17 2:31 PM, Michał Wadas wrote:

Implementations are allowed to extend objects. Otherwise presence of
global/console/// would violate spec...


http://www.ecma-international.org/ecma-262/6.0/#sec-global-object 
explicitly says that the global object may have additional properties, 
so global .console is clearly not a spec violation.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/10/17 2:10 PM, Raul-Sebastian Mihăilă wrote:

Do you mean that an implementation is allowed to return an exotic object
from the Error constructor?


No, I'm saying some implementations do that, because they want to 
implement a non-standard "stack" property and the only way to get 
reasonable behavior (as those implementations define "reasonable") for 
it is to have the object be an exotic object.


There are other implementation strategies for "stack" that don't involve 
an exotic Error object, of course (e.g. SpiderMonkey implements it as an 
accessor property on Error.prototype).  They have their own tradeoffs, 
though.



Not returning an ordinary object from the Error constructor is
non-conformant and, assuming that conformance is a requirement for V8,
it's a bug.


Sure, just like arguably the presence of the "stack" property to start 
with is a bug, because per spec it's totally unexpected.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: getOwnPropertyDescriptor side effects

[Boris Zbarsky]

On 1/10/17 1:56 AM, Raul-Sebastian Mihăilă wrote:

Even if the `stack` property is non-standard, getting its property
descriptor must follow the same general rules for ordinary objects.


Not if its (non-standard) implementation makes the object itself 
non-ordinary (again, non-standard)...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Accesssing ES6 class constructor function

[Boris Zbarsky]

On 1/5/17 2:21 PM, James Treworgy wrote:

function createInstance(Cotr, args /* array */) {
function F() {
   // this is dynamic in reality but simple example of injecting
something...
   this.logger = new Logger();

   var instance = Cotr.apply(this, args)


So the thing is...

This works for script-defined constructors.  But it never worked right 
for constructors of built-ins.



   return instance; // in case Cotr returns something


At which point you've lost your logger, right?

Specifically, in the ES5 world, if the Cotr that's passed in there is 
Array or Date, say, then instance != this and you don't get the logger 
thing.


The behavior of ES6 constructors is meant to be able to explain the 
construction of such built-ins (and especially the new ones like Map, as 
well as the various DOM built-ins in browsers) _and_ to allow 
subclassing such built-ins usefully.




So the Cotr can refer to "this.logger" in the constructor. I don't think
there's a way to do this with dynamic class inheritance since you always
have to call super() before you can assign any properties in a constructor.


That's unavoidable if you want to allow Cotr to control the actual 
object allocation, which was one of the design constraints here to 
enable built-ins to work the same way as non-built-ins.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proxy

[Boris Zbarsky]

On 12/14/16 8:47 PM, Uther Pendragon wrote:

Perhaps it's a bit late... but I'd like to discuss the proxy object.
Notably:  why no way to define a hook for when a property is called as a
function.


See thread at .


I think I understand *why* there isn't one..  I presume because how a
property is used (I.e. as a property or called as a function) is a level
deeper than the recalling of said property.  If at all possible, I think
it would be incredibly useful.


It's possible, in general; it was there in the proxy proposals at some 
point, as the thread linked above says.  It leads to weird consequences 
like "foo.bar()" behaving differently from "foo.bar.call(foo)" when 
everyone expects them to be the same thing.



I presume most implementations define scope
variables much like object properties internally.


That's not clear to me at all.  In general, non-object environments 
don't need to support all the operations objects do (e.g. you can't 
delete bindings), so the implementation tradeoffs are quite different 
and using a separate codepath for environments and object properties is 
likely to be appropriate.  Certainly the one implementation for which I 
know this details (SpiderMonkey) has quite different implementations for 
scope variables and object properties.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring object outside of var declaration

[Boris Zbarsky]

On 11/15/16 1:57 PM, Claude Pache wrote:

My guess is that Thaddee Tyl was confused by a Chrome DevTools feature, as in:


I considered that, but I actually got consistent results both in 
Chrome's console and in a webpage...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring object outside of var declaration

[Boris Zbarsky]

On 11/13/16 1:28 PM, Thaddee Tyl wrote:

var foo, bar;
{foo, bar} = {foo: 2, bar: 3};

is a "SyntaxError: expected expression, got '='" in Firefox, and *it
works in Google Chrome*.


I get "Uncaught SyntaxError: Unexpected token =" in Chrome "56.0.2914.3 
dev" and in Chrome "54.0.2840.9" (release).


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal of Multithread JavaScript

[Boris Zbarsky]

On 11/4/16 3:16 AM, doodad-js Admin wrote:

Using threads and shared objects, IPC and serialization/deserialization of 
objects will no longer be required.


Just so we're clear, what _will_ be required, in the VM, is locking 
around property access and a GC that can deal with multiple threads, right?


SpiderMonkey used to have all that.  We removed it because the 
performance penalties it imposed were not acceptable.  Reintroducing it 
would be a pretty hard sell, for that same reason.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Conditional object properties

[Boris Zbarsky]

On 11/2/16 9:04 AM, kdex wrote:

I'd imagine that from an engine point of view, this means that fewer
object shapes land in memory, at least for v8.


I'm pretty sure it means nothing of the sort in SpiderMonkey (in terms 
of memory usage, not in terms of object shapes that flow through 
subsequent shape guards), for what it's worth.  I'm not sure it's worth 
adding things to the standard just to work around implementation quirks 
of a specific implementation.


No opinion on the ergonomics argument.


Reducing the number of object shapes currently boils down to using an
object literal and setting the properties to `value || null` instead of
extending the object with new properties imperatively.


This actually creates _more_ object shapes in SpiderMonkey, I believe, 
though fewer shapes that flow through code locations.  So it depends on 
whether you're trying to optimize memory usage or performance.  And of 
course on whether you're tuning to a particular engine's current 
implementation strategy...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/31/16 8:42 AM, Isiah Meadows wrote:

When the worker has finished loading, so you can send and receive messages


OK, what about a worker that when it loads just starts and infinite loop 
and starts sending you messages (but obviously never expects any 
messages from you, since it's in an infinite loop)?


Or is the idea to not support this behavior?  If so, I'm a little 
worried about specifying something with totally different behavior from 
DOM Workers and calling it "Worker".



What if the "result" of the message is a sequence of messages back?
This is a common thing to do with web workers: ask it to do something,
and it sends the answer back in chunks.

The result is the value returned from the worker's `onMessage`. This
does permit async return values, because it's fairly common (at least in
my case) to send a message and expect a response as effectively a return
value, and I would like to reify that.


I think we're talking past each other a bit here, but please see above 
about naming.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: change behavior of Array.prototype.push?

[Boris Zbarsky]

On 10/29/16 6:15 PM, Jordan Harband wrote:

Please do file this Firefox bug ASAP, so they can correct it.


I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1313891

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/27/16 6:18 PM, Isiah Meadows wrote:

1. Add a new `import.fork(script): Promise` method-like
expression that loads the worker and resolves when done/rejects if it
couldn't for some reason.


What does "done" mean in this case?


  - `worker.send(message, sharedBuffers?)` - Send a message and return a
Promise to its result.


What if the "result" of the message is a sequence of messages back? 
This is a common thing to do with web workers: ask it to do something, 
and it sends the answer back in chunks.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/27/16 1:47 PM, Michał Wadas wrote:

It's already handled by current specification as structured clone
algorithm.


Sort of.  Not all things can be structured cloned.  A fetch Response, 
for example, can't be, and that's what the example being discussed was 
using...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/27/16 10:02 AM, Frankie Bagnardi wrote:

It doesn't really need to clone anything, you just create a promise on
each side, on top of the normal events.


And how is the resolution value transferred over?  This is the cloning step!

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Standardize ES Worker

[Boris Zbarsky]

On 10/27/16 9:48 AM, Michał Wadas wrote:

Currently we put emphasis on request-response model - we request
something from function (returning Promise/taking callback) and we wait
for single return value. Workers are different beasts - they can emit
messages on their own and don't have to emit ANY messages on completion.


Right.  The point of workers in the web platform is to do computation in 
a separate context.  The computation need not be communicated back to 
the spawning page, because workers can do their own I/O.



// main.js
const worker = new Worker('worker.js');
worker.request('ajaxCall', {url: 'example.com '});
// return Promise resolving to Response object
worker.request('undefinedMethod'); // return rejected Promise

// worker.js

self.on('ajaxCall', (data)=>{ return Promise.resolve(new Response); });


Workers in the web platform have a shared-nothing model.  The above 
example seems to assume that the Response and the Promise are either 
shared across the main script and the worker or auto-cloned at the 
boundary, right?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Intl currency formatting and minimum significant digits

[Boris Zbarsky]

On 10/22/16 12:52 AM, Zach Lym wrote:

I recently ran into a discrepancy between Chrome and Firefox's
implementation of Intl's currency formatting mechanism and the
official spec.  I didn't want the output to have any significant
digits so I used the following:

new Intl.NumberFormat('en-US', {maximumSignificantDigits: 0,
currency: 'USD', style: 'currency', currencyDisplay: "symbol"});

This works fine on Chrome and Firefox


It does?  When I do that in Firefox I get an exception:

  RangeError: invalid digits value: 0

What would it even mean to have 0 significant digits?  Mathematically 
that makes no sense; if you have a digit at all, it's presumably 
significant so the smallest number of significant digits that makes 
sense is 1.  Which is what the spec and the polyfill and Firefox (and 
Safari; I just checked) do.  Sounds like V8 just has a bug.


I filed https://bugs.chromium.org/p/v8/issues/detail?id=5554 on V8.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Code smell? Iterator prototype has iterator method that returns "this"

[Boris Zbarsky]

On 7/25/16 11:19 AM, John Lenz wrote:

Can anyone provide any historical context on why this method was added
to the "iterator"?


The idea is that you can do this:

  for (var something of myarray.entries())

and similar for other iterator-returning methods.  The way for-of works 
is that it will try to call iterator() on the thing to the right of the 
"of", which in this case is an Iterator instance.


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Boris Zbarsky]

On 7/13/16 10:59 AM, Michael Kriegel wrote:

So what does gc do to determine, whether an object still has hard
references pointing towards it?


The GC may be conservative, not be precise.  That is, it may not collect 
some stuff that actually could be collected because the GC thinks there 
are references to it, while there actually aren't any.  The stuff may 
then end up being collected on a later collection, again depending on 
the contents of things like the machine stack and machine registers.



Depends on how the gc works. If "deleting the last reference to an
object" leads to an immediate deletion of all references to other
objects held by this object, then: no.


I'm not aware of any JS GC that uses reference counting.  It _could_ be 
done, together with a cycle collector, but you'd really really need the 
cycle collector.  And once you have a cycle collector, you need to run 
it to find out whether things really are unreachable; just looking at 
reference counts is no longer enough.



Any resources on what they do? E.g. chrome V8 or Firefox?


SpiderMonkey (the JS engine in Firefox) uses a tracing GC.  In terms of 
the "implementation strategies" described at 
https://en.wikipedia.org/wiki/Tracing_garbage_collection it's a moving, 
mark-and-sweep, generational, incremental, precise collector.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

[Boris Zbarsky]

On 7/13/16 10:18 AM, Michael Kriegel wrote:

But shouldn't it be predictable, whether there
are still "non-weak" references to an object?


Maybe.  The GC may include a machine stack scanner to root things 
referenced on the stack, which can give false positives depending on 
what integers happen to be hanging out on the stack.



does NOT depend on, whether the object has actually been gc'ed, but whether the 
object does
have "non-weak" references to it.


Determining this basically requires running a full gc, no?


I am not sure, which kinds of garbage collectors the implementations of
ECMAScript typically use. If they used a reference counter


They don't.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Has there been any discussions around standardizing socket or file io usage?

[Boris Zbarsky]

On 6/17/16 10:35 AM, David Bruant wrote:

Specifically, even if there was a standard why would Node or browser
makers implement it given they already have an API for the job and lots
of code is already written on top of these APIs?


The other issue, of course, is that Node and browsers have very 
different security models, which has a significant impact on how a 
feature like this would be exposed.  The ideal API for one security 
model may not match the ideal API for the another one...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Oddly accepted RegExps

[Boris Zbarsky]

On 6/3/16 4:20 AM, Isiah Meadows wrote:

These three RegExps don't appear valid, even after reading the Annex B,
but they do behave consistently in both Chrome and Firefox.


Note that Chrome and Firefox use the same regexp implementation, so them 
agreeing on how a regexp is handled means a lot less than if two 
independent implementations agreed.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extending an ES6 class using ES5 syntax?

[Boris Zbarsky]

On 5/14/16 3:11 AM, Andrea Giammarchi wrote:

 1. why is that?


Why does mutating the proto after an object has been exposed to script 
end up deoptimizing things?  Because it invalidates assumptions JITs 
otherwise make.  So the options are to make the 
proto-hasn't-been-mutated case slower by not making those assumptions or 
to make the proto-has-been-mutated case slower.  Guess which one is a 
better choice?



There is a
spec'd method that is not even on Annex B and Firefox deliberately
discourage its usage.


Sure.  Just because something specced doesn't mean it's a good idea to 
actually do it.


This is why in the HTML spec there's all sorts of stuff that's marked as 
"not valid HTML" for authoring purposes even though the spec then goes 
ahead and defines what a browser should do with that stuff if authors do 
it anyway.



Why I don't see warnings every time I
`[].slice.call(arguments)`?


Because that's not as big a performance hit?


I understand it might de-optimize but I
wonder if that's really always necessary (maybe it doesn't have to
deopt if it's a well known operation with a predictable result).


I'm not an expert on the type inference setup (which is what ends up 
deoptimizing on proto mutation, iirc), so I can't usefully answer this.



On the other side, I also wish Firefox woudn't show warnings about
modern and recent specifications. Deprecated stuff is OK,


There can totally be things that are both recently added to the spec 
(for UA implementation purposes, because everyone has to do it for web 
compat) and deprecated for authoring purposes (because they're a bad 
idea).  Dynamic proto mutation is one of those.  ;)



 2. where were you when the `__proto__` landed on specs? :P


You mean when every browser on the market implemented it, which was the 
relevant bit?  The addition to the spec was just acknowledging ugly reality.


Where was I when browsers implemented __proto__?  We're talking 20ish 
years ago, so probably high school or a few years into college.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extending an ES6 class using ES5 syntax?

[Boris Zbarsky]

On 5/13/16 9:04 PM, Domenic Denicola wrote:

   Object.setPrototypeOf(obj, new.target.prototype); // or B.prototype, but if 
you derive from B you'll have to do this dance again


This is highly undesirable because it will deoptimize in implementations 
in practice.


That said, can't the right thing be done using Reflect.construct?


Object.setPrototypeOf(B.prototype, A.prototype);


I believe this will, again, deoptimize in practice...

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error-Type Specific try/catch Blocks

[Boris Zbarsky]

On 5/13/16 11:06 AM, Joseph Groseclose wrote:

I sent this proposal via
http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php#
yesterday evening. Sharing it here now:
https://github.com/benderTheCrime/error-type-specific-catch-proposal


I'd like to understand the proposed semantics better, to see what's 
actually being proposed and how it interacts with a world in which 
multiple globals exist.


Given this:

  try {
something();
  } catch MyError (e) {
// when do I reach here?
  }

when does control enter the catch block, exactly?  Is it when "e 
instanceof MyError"?  Is it when "e.name == MyError.name"?  Something else?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Better way to maintain this reference on event listener functions

[Boris Zbarsky]

On 5/9/16 12:37 PM, Mark Kennedy wrote:

and also REMOVING the event listeners manually.


I think this is the key part.  What is the precise use case for removing 
here?  I think that affects how this would best be designed.


The obvious case is when you want to remove the listener at the point 
when it fires.  This would be most easily addressed by providing a way 
to get at the listener from inside itself somehow.  Are there other uses?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is `undefined` garabage collectable?

[Boris Zbarsky]

On 5/4/16 5:03 PM, Steve Fink wrote:

The only v8 shell I have lying around is too old (3.14.5.10) to have
Set, so I can't tell you what it would do.


I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and 
it does 1163 minor ("Scavenge") GCs on your testcase.  It also does 1163 
minor GCs if I take out the add() calls.  It does none if I remove the 
clear() calls, no matter whether the add() calls are there or not.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: Switch position of delay and callback in signature of `setTimeout()`

[Boris Zbarsky]

On 4/25/16 1:35 PM, Adrian Sieber wrote:

Everytime I use `setTimeout()`, I wonder why the the arguments are in
the wrong order. Usually the callback functions comes last, but in
'setTimeout' it's exactly the other way round.


First, this is the wrong list: setTimeout is defined by 
https://html.spec.whatwg.org/multipage/webappapis.html#dom-settimeout 
not the ES language spec.


Second, note that the delay argument to setTimeout is optional.


So a polyfill would be something like:

```
newSetTimeout = (delay, callback, ...args) => {
   if (typeof delay === 'function') {
 setTimeout(delay, callback, ...args)
   }
   else {
 setTimeout(callback, delay, ...args)
   }
}
```


Third, this is not compatible, obviously.  Consider what it would do with:

  setTimeout("doSomething()", 1000);

You could check for function or string, but even that is not compatible 
in cases like this:


  setTimeout({ toString: () => "doSomething()" }, 1000);

and then you're left discussing whether such cases exist in practice and 
whatnot, yes?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises, async functions, and requestAnimationFrame, together.

[Boris Zbarsky]

On 4/23/16 4:09 AM, Salvador de la Puente González wrote:

AFAIK, that should execute `drawSomething()` once per frame. Given a
frame is each time the animatinFrame() promise resolves.


What's not obvious to me is whether it will execute it before the actual 
paint for the frame (i.e. before or right after the loop that's 
notifying the animation frame callbacks completes) or whether it will do 
drawSomething() after the paint...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: {}+{} incosistency

[Boris Zbarsky]

On 4/13/16 12:08 PM, Boris Zbarsky wrote:

It sounds like all the actual JS engines involved get all of this right;
the only difference is whether evaluation in the browser's console
happens in an expression context or in a statement context.


And in particular, it seems like most browsers evaluate console stuff in 
a statement context, but Chrome is somewhat inconsistent about it.  Some 
experimentation suggests the following is happening, for various input 
strings:


1) "{}": expression context; claims to be an Object.
2) "   {}": expression context.
3) "var x = 1": statement context; defines a property named "x" on
   the global.
4) "let x = 1": statement context; creates a binding for "x".
5) "function f() {}": statement context; defines a property named "f"
   on the global.

I haven't experimented with more interesting whitespace preceding a '{' 
but it looks like the heuristic is to use expression context if the 
first non-whitespace character is '{' and to use statement context 
otherwise or something.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: {}+{} incosistency

[Boris Zbarsky]

On 4/13/16 12:04 PM, Allen Wirfs-Brock wrote:

The V8 result is correct


In an expression context.

It sounds like all the actual JS engines involved get all of this right; 
the only difference is whether evaluation in the browser's console 
happens in an expression context or in a statement context.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Is there a way to run test262 in a browser (and especially in web workers)?

[Boris Zbarsky]

On 3/17/16 11:42 AM, Leo Balter wrote:

The current website needs an update. If it makes less painful to run the
tests on a shell, you can try https://github.com/bterlson/eshost


I'm specifically looking for a harness that will run the tests in a web 
worker, so I'm not sure that this helps me... ;)


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Is there a way to run test262 in a browser (and especially in web workers)?

[Boris Zbarsky]

It looks like there used to be a 
http://ie.microsoft.com/testdrive/HTML5/WebWorkerTest262/Default.html 
but it's gone.


There also used to be a http://test262.ecmascript.org/ (linked from 
various places on the ecmascript.org wiki) but that's gone too.


Does anyone know whether this test is still available to be run outside 
of a shell, and especially in web workers, somewhere?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/13/16 10:43 PM, Brian Barnes wrote:

1. Potential mis-use of API could make things slower
2. People assuming things could freeze behavior
3. People will assume behavior outside of the spec
4. What does GC mean?  People will assume everything.


I think #1 there is a mechanism of #2, in that freezing behavior will 
happen because what used to be good use of the API would become slow 
misuse and browsers would therefore not make the corresponding change.


But yes, this seems like a reasonable summary.


A call that hints that next time control is released from a script, that it 
triggers whatever the next type of GC, whatever it is, of any of the methods, 
that would get triggered close to this time.


I think it's a good idea to not imply this API is specifically about GC. 
 I would much prefer we make it about what we actually care about: 
telling the engine that you have time right now for it to do some work, 
but won't have time later.  This captures the semantics we really care 
about, right?


Apart from that nit (which is basically about naming), this seems 
reasonable to me as a thing to have.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/13/16 5:30 PM, Brian Barnes wrote:

“Perfect is the enemy of the good.”


This is true, but...


I’m asking for a specific, useful function, not the perfect solution to my 
problem.


The problem is that the function you're asking for can be really really 
bad in some situations.  So if we introduce it without actually defining 
its behavior we run the very real risk of people using it in ways that 
work in some current browsers and thus constraining the future 
development of those browsers _and_ breaking other current browsers.


Note that I'm quite interested in helping solve the actual problem 
you're having.  I just don't think this is the right solution for it. 
Some of the suggestions Steve Fink made are much better, in my opinion.



The problems start when the best practice is different for different engines 
and people optimize their code based on only one engine.


That’s not our problem


It's _my_ problem as an engine developer.


and that’s not a solvable problem.


It's not a solvable problem in the abstract, sure.  But it's a problem 
that we can make worse or better (e.g. by not explicitly introducing 
APIs that make the problem worse, or by introducing ones that make it 
smaller).


Now _I_ will claim that the perfect is the enemy of the good.  ;)


Every engine will try to get ahead by some manner, and something like 
compiling, or GC, which isn’t spec nor should it be, will always be evolving.


Yes!  And we don't want to prevent that.


A System.gc() will in no way constrain further development.


I disagree most vehemently.


It’s not a guarantee to do anything but “free up objects that are no longer 
reachable and compact the heap.”


Except _you_ want to use it as a guarantee of "no more GC pauses after 
this point".  That's the use case it's being proposed for!



The contract is not “make my code run faster.”  It’s not “don’t do it again in 
a little bit.”  It’s not any of those things.


People will 100% surely assume that's the contract.  Especially if it 
happens to be true in one particular case they use it in, in the one 
browser they test in.


And then they will create things that depend on that behavior, and it 
will in fact become a de-facto contract.  I've seen this play out 
several times now.



I think you’re trying to force the API to be a problem solver


No, I think the right approach for API design is to figure out what 
problems you're trying to solve and then create APIs that ideally solve 
those and don't introduce new problems.


This is as opposed to coming up with an API and then trying to argue 
that it solves some specific problems therefore is the right API to 
have.  There may be better solutions for those problems!



Small contract: Free up objects that are no longer reachable and compact the 
heap, the objects being objects that aren’t attached by outside APIs (DOM, 
webgl, web audio, etc.)”


That's not a useful contact, because no one actually cares in practice 
about whether this has happened or not.  The real use cases mentioned so 
far are all about GC pauses, not internal details like whether things 
have been freed up or whatnot (which aren't even observable!).


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/13/16 4:06 PM, Brian Barnes wrote:

The second part was a hint to tell the engine to always take the most 
aggressive route with optimization


By which I assume you mean still running in the lower interpreter/JIT 
levels until you have gathered sufficient profiling information, but not 
gating the higher JIT levels on hotness per se?


I think one problem here is that right now hotness is used as a proxy 
for profiling information in at least some JITs; once code is hot enough 
you figure you've got enough information about its types.  Not a perfect 
assumption, of course.



A longer start-up time is something you want for a thing that will run 
continually and will almost always be guaranteed to fall into the compile path 
eventually.


Again, the fastest compile path relies on having run on the slower ones 
for a bit to gather the information needed to produce the fast code.


For example, you can run SpiderMonkey in --ion-eager mode, in which it 
immediately tries to compile with the last-level JIT.  This produces 
slower code than you get if you run in the first-level JIT for a bit 
first...


Having explicit types would help with this, of course.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/13/16 6:27 AM, Florian Bösch wrote:

JS'es stop-the-world mark for however long it takes
approach to GC'ing is very troublesome.


That's certainly not the way SpiderMonkey's GC is meant to work (it's an 
incremental GC with a per-slice time budget)...



Adding some more flexible ways to deal with GC'ing beyond "just making
it better" would be highly welcome.


Yes, this I agree on.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/12/16 10:52 PM, Brian Barnes wrote:

What I'm trying to say is that it may well not, if it just called JS_GC and if 
the problem to be solved is pauses on the order of several tens to hundreds of 
milliseconds due to memory collection activity…


Time is not my concern.  I’m trading time now for time when it’s critical.


I understand that.  What I am saying is that if you call JS_GC now, that 
doesn't mean that a cycle collection won't happen 30 seconds from now. 
To help prevent that, you'd have to run cycle collection now.


In other words, JS_GC would help somewhat in your situation, but not 
completely.  And maybe tomorrow it would help less than today.  Or maybe 
more...



OK, but then we run the very real risk of it not actually doing what people 
want.  Or more precisely browsers implementing it in various different ways as 
they attempt to map its not-really-defined semantics onto their actual GC 
systems and then people sprinkling it about based on the GC heuristics and 
setup in one particular browser they tested with and optimized for, and then 
other browsers having to reverse engineer those _and_ that one browser being 
locked into never changing how its GC operates.

And then we all lose.  :(


That’s modern web development


No, I don't think it is.  The way we prevent problems like this from 
arising is by actually creating standards, so that browsers know what 
behavior they need to have and consumers know what behavior they can 
depend on.



my code uses classes, and I had to fake them until FF 45 came out, and then 
realized they failed unless I was operating in strict under chrome; Safari 
doesn’t have let and nobody has proper implementation of stereo panning in web 
audio :)


Yes, but these are transitional problems.  I'm talking about it being a 
problem when current implementations constrain both each other and 
future evolution of themselves because someone comes to depend on 
undocumented details of them.


This _also_ happens in web development, but it's something no one likes 
to happen



Not asking for miracles; I’m asking for best practice on an engine.


The problems start when the best practice is different for different 
engines and people optimize their code based on only one engine.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/12/16 10:22 PM, Brian Barnes wrote:

We’re closing in on something!  This could have been clearer on my end;
I am looking at only javascript objects.  My code, for instance,
interacts only though a webgl context; it never creates any nodes or
does anything outside of javascript.


But it creates WebGL objects like WebGLUniformLocation or WebGLTexture? 
 Because those aren't mark-and-sweep either... They're much more like 
DOM nodes in terms of their memory management.



But again, the definition of "GC" as described on the page you link to
doesn't cover everything that's touched by "GC" as it matters for an
actual page in a web browser…


Yeah, again, I think this is where we are bumping heads over.  I never
meant it to matter at all to what goes on in the browser, just objects
created in code.


I think we might have different definitions of "objects created in 
code".  Are you including return values from getUniformLocation?



This, basically:

https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS_GC

Having System.gc() call that would solve my problem (I think.)


What I'm trying to say is that it may well not, if it just called JS_GC 
and if the problem to be solved is pauses on the order of several tens 
to hundreds of milliseconds due to memory collection activity...



Honestly, I never thought I’d get into this discussion.  I always saw
this as something that would be different, from engine to engine, as
engine GCs are different.  The end user doesn’t have a lot of control or
knowledge of the mechanics of such things.


OK.  We agree so far.  ;)


System.gc() would be the same thing.


OK, but then we run the very real risk of it not actually doing what 
people want.  Or more precisely browsers implementing it in various 
different ways as they attempt to map its not-really-defined semantics 
onto their actual GC systems and then people sprinkling it about based 
on the GC heuristics and setup in one particular browser they tested 
with and optimized for, and then other browsers having to reverse 
engineer those _and_ that one browser being locked into never changing 
how its GC operates.


And then we all lose.  :(

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/12/16 9:52 PM, Brian Barnes wrote:

This is key:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management

When the mozilla docs refer to GC, they refer to mark-and-sweep objects
created by the user’s code.


User code creates lots of objects in Firefox whose memory management 
model is not mark-and-sweep at the moment (for example, DOM nodes).


The docs you are looking at there are specifically for SpiderMonkey, not 
SpiderMonkey in a particular (browser) embedding.



I think this is all that needs to be done.


Not if you're actually trying to avoid memory collection pauses, 
sorry...  This is what makes all this rather annoying.



There’s certain other things that goes on, but they are things out of
control of the coder.  The objects the code creates are what we are
interested in.


OK.  Note that you can have some control over things the browser creates 
too, not just things you create.


But again, the definition of "GC" as described on the page you link to 
doesn't cover everything that's touched by "GC" as it matters for an 
actual page in a web browser...



We’re not talking past each other, we are talking at different levels of
grain.  I’m talking about what the end user experiences; which is
numerous quick GCs usually followed by a large GC.  You are talking
about the actual mechanics of what each of those GCs actually are, or
do, but to the end user, they are quick pauses and large pauses.


OK.  Say I have some gc pauses: 100us, 1ms, 5ms, 10ms, 20ms, 50ms, 600ms.

Which of those are quick pauses and which are large?  As far as I can 
tell, the answer depends on the application, what sort of real-time 
guarantees it needs, and how much processing it does itself.  About the 
only thing everyone would agree on is that 100us is small and 600ms is 
large.



But this has de-evolved; let’s reduce this to the regular mark-and-sweep
collection of objects.


That would correspond to the first three modes I described, but even 
within that a given mode can in theory lead to either a quick pause or a 
large one, and you don't necessarily know up front which it will be.


In practice, all the modes are incremental and aim to not have anything 
resembling 600ms pauses.  But if 5ms constitutes a "large" pause for 
you, then you might end up with "large" pauses from at least two of the 
modes.  Not sure whether a nursery collection can ever end up there...


But my larger point is that if we define this to be "regular 
mark-and-sweep collection of objects" that might well not be enough to 
avoid big memory collection pauses in the future anyway.  And if we 
don't define it to be that, then it's not clear what to define it to be 
because it really depends on what else is going on...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/12/16 9:11 PM, Brian Barnes wrote:

The contract would be, if the engine is GC (which is likely, as I pointed out 
without compiling or additions to the language), then do as much clean up as 
possible.


What does that mean, exactly?  In the case of SpiderMonkey+Gecko, should 
that run the cycle collector?  Should it run it multiple times (it might 
take multiple cycle collector runs with GC in between to collect 
everything that could be collected by a future collection).  Should it 
evict caches that can cause things to become garbage when they get 
evicted?  Should it perform maximal heap compaction (and therefore need 
slow heap growth on future allocations)?


Is this "as much cleanup as possible" allowed to take tens of seconds of 
wall-clock time, which is what you might need in some cases to really 
make sure you've found all the garbage?


And will people who make the call really expect all that to happen?


If the system isn’t GC, then the problem you are looking to solve — which is to 
make GC happen more predictably in special circumstances


The problem is that "GC" isn't a single thing that can happen.  It's 
multiple different things that can happen, and have vastly different 
heuristics.  It's not even necessarily clear which tasks fall under "GC" 
and which do not (c.f. cache evictions above).



For instance, you might have a system that has a flush() on it, this is 
something you see a lot.  Depending on the actually physical storage method 
(sometimes an OS might have a file in flash and the flush means next to 
nothing, or an OS might always write though), but flush is STILL a useful and 
understood function.


That's because the operation is controls is somewhat simpler than 
"collect all the memory" (though in practice flush() is not actually 
understood in terms of what it means about the bits actually being in 
non-volatile storage or not)



APIs do something


Sure.  Whether that something is what you wanted, or even what _anyone_ 
wants is a separate question.



Which of those are small and which are large?  And note that this set of modes is 
definitely not fixed in stone, and that for mode #2 the set of globals that constitute a 
single "zone" (what we call the sets in question) is not fixed in stone either 
across different Firefox versions…


Small and large GCs, in my parlance, would be in fact quick and full GCs


I just pointed out that SpiderMonkey has 3 or 4 different kinds of GCs, 
which scale from "fast" to "slow".  More if you include things like 
cache eviction.  You came back with, again, wanting to categorize things 
into two buckets.  I feel like we're talking past each other.



if you watch most GC system, you’ll get tons of little collections, and then, 
eventually, a large collection.


Note that I pointed out a specific production JS implementation, a 
fairly widely used one, where this is not exactly how things work.  As 
in, I'm not raising a theoretical objection to assuming this model here.



Contractually, though, this would be “every GC you can do, on any object you 
can.”


See my questions above.


In FF, it would go through everything it could.


I really don't think you want an API that would take tens of seconds to 
run in some cases, which is what you're asking for here.



As for a callback, it would be after the GC has finished, or finished as well 
as it can.


Ah, to avoid requiring stopping the world.  That's good, sure.  Maybe 
then you really _are_ OK with it taking a long time ...or never 
completing, if garbage is created between each async gc slice so we 
never "finish".



Maybe System.gc() is a bad name, if people are worried about a fundamental 
change to how a engine does memory management.  System.memoryCleanUp() — OK, 
that’s awful :)


Note that Firefox _does_ have some built-in "minimize memory usage" 
thing (you can get to it from about:memory).  This is an async operation 
that will in fact go through all renderer processes and ask each of them 
3 times (3 because 1 is not enough per comments above and we didn't 
really want an unbounded number) to flush all caches, do collection, etc.


I just tried it; took about 15 seconds with my set of tabs  And of 
course it clears all caches (so likely throws out things you might in 
fact care about).


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: GC/Compile requests, with 3D engine demonstration

[Boris Zbarsky]

On 3/12/16 8:08 PM, Brian Barnes wrote:

As for being a de-optimization hazard, that’s certain a problem, but we 
shouldn’t disallow the usage of something because programmers are bad.


It's not a matter of badness or goodness.  It's a matter of programmer 
expectations not matching the actual engine behavior.  Which is 
particularly easy to have happen when there are multiple engines that 
have _different_ behaviors.  Not to mention that engines might want to 
change their behavior.



It could certainly happen on a callback, too, which I think is perfectly fine.  
As far as I know, most all gcs I’ve seen have different modes, small gcs, and 
large gcs.


I'd like to understand the proposal here better.  What is happening off 
a callback?  The gc, or code that wants to run after the gc?


On another note, the above quoted text is a good example of my claim 
above about expectations and behaviors.  The SpiderMonkey GC (the JS GC 
I know most about) has 3 modes, I believe: (1) collect just in the 
nursery, (2) collect in the part of the heap that contains objects from 
a predetermined set of globals, treating any cross-global references 
into that part of the heap as roots, (3) collect across the entire JS 
heap, treating references from C++ to JS as roots.  When running in 
Firefox there is a fourth mode: collect across the JS heap but also run 
the cycle collector in Gecko to detect reference cycles that go through 
the C++ heap and collect those too.


Which of those are small and which are large?  And note that this set of 
modes is definitely not fixed in stone, and that for mode #2 the set of 
globals that constitute a single "zone" (what we call the sets in 
question) is not fixed in stone either across different Firefox versions...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 6:59 PM, Steve Fink wrote:

(Or at least, that's my understanding of what is going on. I'm not sure
if that stuff is used for Error.stack yet.)


It is.  See https://bugzilla.mozilla.org/show_bug.cgi?id=1038238

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 5:35 PM, Boris Zbarsky wrote:

Clearly this Just
Works with a value property, across all browsers at that point, so we
made it work with the accessor too.


Oh, and we made it work the way [Replaceable] stuff on window works: the 
setter defines a value property on the object which thereafter shadows 
the prototype's getter.


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/24/16 4:30 PM, Mark S. Miller wrote:

[1] For some reason the FF stack accessor has both getter and setter. I
don't see any reason for a setter.


We ran into code "in the wild" (more precisely, within our own test 
suite infrastructure, but we have no reason to believe this would not 
happen in the wild) where people were reading error.stack, doing some 
processing on it, and then setting error.stack on that same error, and 
expecting error.stack to be that thing after that.  Clearly this Just 
Works with a value property, across all browsers at that point, so we 
made it work with the accessor too.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

[Boris Zbarsky]

On 2/19/16 3:50 PM, Coroutines wrote:

Side discussion: Why does Javascript have this limitation? - what I
view as a limitation?  You'd think this could be supported without
breaking older JS..


I don't see how it could.  I'll bet $50 someone out there is using 
obj[location] for example.


-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak Reference proposal

[Boris Zbarsky]

On 2/17/16 8:30 AM, Joris van der Wel wrote:

XMLHttpRequest, fetch, WebSocket, etc would even require a something
similar to a phantom reference (like in java) so that we can close the
connection when the object is no longer strongly or weakly referenced.


None of these allow closing the connection merely because the object is 
not referenced from elsewhere.


Or put another way, the connection must hold a reference to the object.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Garbage collection in generators

[Boris Zbarsky]

On 2/17/16 3:59 AM, Benjamin Gruenbaum wrote:

Garbage collection can and does in fact manage resources in JavaScript
host environments right now. For example, an XMLHttpRequest /may /abort
the underlying HTTP request if the XMLHttpObject is not referenced
anywhere and gets garbage collected.


If an implementation does that, it's clearly buggy.  Consider:

  function foo() {
var xhr = new XMLHttpRequest();
xhr.addEventListener("load", function() {
  alert(this.responseText);
}
xhr.open(stuff);
xhr.send();
  }
  foo();

The XMLHttpRequest object is not "referenced anywhere" in JS terms 
between foo() returning and the load event being fired.  But the load 
event really does need to be fired.  Can you point me to the spec text 
that makes you think that in this situation not firing the load event 
would be an OK thing to do?


In practice what this means is that the UA needs to keep the object 
alive and prevent it being garbage collected until the end of the HTTP 
response is received.


-Boris

P.S. 
https://groups.google.com/d/msg/mozilla.dev.tech.js-engine.internals/V__5zqll3zc/hLJiNqd8Xq8J 
has some comments on this exact issue of resource management via GC.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Any reason why __proto__ is not a well known symbol?

[Boris Zbarsky]

On 2/16/16 12:01 PM, Coroutines wrote:

I hope ES7 makes breaking changes all over the place


Do you also hope ES7 never ships in any web browsers?

Just checking,
Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 4:52 AM, Jonathan Kingston wrote:

@Boris does the main difficulties hinge on document.domain?


Main difficulties with what?

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 9:47 PM, Jonathan Kingston wrote:

Could the trace output just finish early at these origin boundaries


The problem is that some browsers don't have origin boundaries at all in 
places where others do.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 2/10/16 7:12 PM, Jonathan Kingston wrote:

Is implementing stack traces cross browser mostly difficult because of
the use of document.domain or are there other issues blocking?


Ah, you mean in terms of interop?

I expect document.domain and built-ins to be the main thing that 
browsers will end up disagreeing if they just implement this 
willy-nilly; everything else is reasonably straightforward.


Deprecating document.domain is a noble goal, but given that sites that 
many people use (e.g. Facebook) make use of it, it's a pretty long-term 
goal at best...


-Boris


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/25/16 1:55 PM, Gary Guo wrote:

I believe a lot of additional work needs to be done for this proposal to
make it works across realm.

Consider the invocation chain:
alpha, alpha0 (in realm A)
beta, beta0 (in realm B)
alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 ->
throws

Here comes the question. What should be included in the stack and what
shouldn't?


What browsers will do is basically include everything, with some caveats.

The main caveat I'm aware of is that when the stack crosses between 
realms which have different effective script origins Gecko will sanitize 
the script view of the stack to only include the bits that the script 
asking for the stack is allowed to know about.  We do record the entire 
stack, and can show the entire thing in devtools if we want to.


In practice, such stacks are quite hard to produce on the web; they 
require changing document.domain partway through the script execution.



Same thing applies when calling native function.


Yeah, this needs some thought.  Browsers aren't even terribly consistent 
with each other or with themselves here.  A imple example:


  
  var div = document.createElement("div");
  div.onclick = function f() {
   console.log(new Error().stack);
  }
  div.dispatchEvent(new Event("click"));
  
  
  function g() {
console.log(new Error().stack);
  }
  [0].map(g);
  

this shows the following in Firefox:

  f@filename:4:13
  @filename:6:1

and

  g@filename:10:17
  @filename:12:3

Whereas in Chrome it shows:

 at HTMLDivElement.f (filename1:4)
 at filename1:6

and

 at g (filename2:10:17)
 at Array.map (native)
 at filename2:12:7

where filenam1 and filename2 are actually different: the latter is an 
absolute URI but the former is just the filename part of the URI...


Safari does:

  f@filename:4:22
  dispatchEvent@[native code]
  global code@filename:6:18

and

  g@filename:10:26
  map@[native code]
  global code@filename:12:10

which is what I was sort of hoping to see, possibly with better names 
for the built-ins (e.g. "Array.prototype.map" and 
"Node.prototype.dispatchEvent" or something).


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/22/16 4:51 PM, Terry Stanley wrote:

Breaking on console.log:
   FF debugger showed single turn call stack
   Chrome debugger with Async selected showed deep stack
Console output:
   FF showed deep stack (as expected)
   Chrome showed single turn


Seems like people are incrementally introducing this stuff or just have 
bugs.  :(



You are correct. The extended stack trace format in MarkM's message is
not enough to represent async stacks.


OK, it's not just me.  All I'm saying is we should go ahead and use a 
format that _can_ represent them.



The full Causeway format is more
than what's needed for the async stacks you are asking about.


Excellent.  That reduces the problem to using a larger subset of the 
Causeway format, right?



The deep stack you see here follows asynchronous causality as it flows
across worker boundaries.


That's pretty nifty.  Being able to represent that too would be nice.


It would be great to have browser support for such stitching together of
intra-vat (page/worker) and cross-worker causality. Do the Causeway
object formats
 for
representing these look like an interesting start?


I haven't had a chance to study them in detail, but at first glance yes.

-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

[Boris Zbarsky]

On 1/20/16 10:10 AM, Mark S. Miller wrote:

I think the useful thing to do is to standardize the extended
Causeway stack trace format:


This format doesn't have an obvious way to represent "async stacks" [1], 
short of hacks with the "functionName" or the "source", right?


Gecko right now represents these precisely by hacking the function name, 
but that's in the context of backwards compat with existing 
stack-processing tools, and a string-only stack representation.  It 
seems to me that moving to an object format should allow us to come up 
with a cleaner way to do this.


-Boris

[1] To see what I mean, try running this in a Firefox nightly:

  
  
  function g() {
console.log(new Error().stack);
  }
  function f() {
setTimeout(g, 0);
  }
  f();
  

the output you will get is:

  g@filename:4:17
  setTimeout handler*f@filename:7:5
  @filename:9:3

As in, the stack indicates the sequence of async steps that got you to 
the current source location.


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Could String internalize an ArrayBuffer?

[Boris Zbarsky]

On 12/5/15 8:44 AM, Coroutines wrote:

What I want is to be able to view a String through a typed array
without duplicating the memory/contents of that string.


The big problem with this is that the actual in-memory representations 
of strings and arraybuffers can be quite different in implementations 
right now.


For example, strings typically have a complicated representation that 
involves multiple fragments, ropes, etc, to make string concatenation 
fast.  Not only that, but to save memory in various engines some strings 
that only contain values less than 256 are stored with underlying 8-bit 
units, not 16-bit ones.  There has also been talk of using something 
like UTF-8 for the internal string representation in some engines, to 
reduce the impedance mismatch with engine consumers (like a browser 
rendering engine).


Arraybuffers, on the other hand, are typically an actual contiguous 
chunk of memory to make access fast.  And of course they just exposed 
whatever bytes they contain.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Javascript Code Churn Rate?

[Boris Zbarsky]

On 11/10/15 7:41 AM, Ethan Resnick wrote:

And how long until they could remove support for the rest of the
language altogether?


This makes the fundamental assumption that it's OK to break old things 
just because they're old.  To the extent that the web is used for 
applications, this is probably OK, but for documents this is really a 
bad approach because we (well at least some of us) want those to 
continue to be readable as the web evolves.  Otherwise we end up with a 
"dark ages" later on where things that appeared in print continue to be 
readable while later digital stuff, even if still available, is not.


And in this case "documents" includes things like interactive New York 
Times stuff and whatnot...


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: resolve()/reject() on Promise subclasses and @@species

[Boris Zbarsky]

On 11/4/15 10:29 PM, C. Scott Ananian wrote:

Again, the reasoning at the time was that `Promise.all(x)` could be
considered sugar for `Promise.resolve(x).all()` in ES7, and so
`Promise.all` was "really" an instance method after all.


OK, but note that the behavior of the two is different (or at least the 
behavior of @@species is different between Promise.prototype.then and 
Promise.all).  Specifically if I have:


  class MyPromise extends Promise {
static get [Symbol.species]() { return undefined; }
  }

then MyPromise.all() will return a MyPromise but 
MyPromise.resolve(x).then() will return a Promise, because 
SpeciesConstructor falls back to "defaultConstructor", not "C", if 
Get(@@species) returns null-or-undefined, while Promise.all()/race() 
fall back to "C".



I'm just saying it wasn't totally crazy, and no one
made any objection at the time.


Sure.  Also, no one has implemented any of this stuff yet.  ;)  I was 
just implementing it and was confused by the various inconsistencies.  I 
can implement it as written, of course, but I wanted to double-check 
that I wasn't misunderstanding something.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: resolve()/reject() on Promise subclasses and @@species

[Boris Zbarsky]

On 11/4/15 9:36 PM, Domenic Denicola wrote:

But it seems that
ES15 decided to only use @@species for instance methods


Except it also uses it for Promise.all and Promise.race.

-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss