00:24:52  * Fishrock123joined
00:25:39  * AtumTquit (Remote host closed the connection)
00:42:04  * Fishrock123quit (Remote host closed the connection)
00:47:44  * Fishrock123joined
01:27:35  * Fishrock123quit (Quit: Leaving...)
02:22:57  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
04:11:09  * jmdyckquit (Remote host closed the connection)
07:38:11  * wycatsquit (Read error: Connection reset by peer)
07:38:34  * wycatsjoined
09:11:02  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:08  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:25:50  * bathosquit (Quit: bathos)
12:04:49  * jmdyckjoined
12:20:11  * AtumTjoined
12:20:43  * bradleymeckjoined
12:43:50  * Jasuruzakovgmailquit (*.net *.split)
12:53:54  * Jasuruzakovgmailjoined
13:01:18  * gibson042joined
13:39:08  * gibson042quit (Ping timeout: 255 seconds)
13:49:47  * bathosjoined
13:57:27  * gibson042joined
14:39:36  * bathosquit (Quit: bathos)
15:34:47  * bathosjoined
15:58:26  * bradleymeckquit (Quit: bradleymeck)
16:13:50  * bathosquit (Quit: bathos)
16:26:30  * Fishrock123joined
16:27:24  * bathosjoined
16:27:26  * bathosquit (Client Quit)
17:15:46  * bathosjoined
17:40:31  * jwaldenjoined
18:06:00  * bathosquit (Quit: bathos)
18:07:40  * bathosjoined
18:40:36  <Bakkot>bterlson: I understand Edge has module support now
18:40:50  <Bakkot>you may be interested in, I just updated https://bakkot.github.io/test262-web-runner/ to support modules
18:40:59  * jwaldenspams test262 with more important tests like https://github.com/tc39/test262/pull/1299
18:41:01  <jwalden>:-)
18:41:03  <Bakkot>via service workers
18:45:25  <Bakkot>jwalden: your indentation style hurts me :(
18:45:40  <jwalden>2space4lyf
18:45:52  <Bakkot>also, wait, this looks like it would pass even if the iterator doesn’t throw
18:46:03  <Bakkot>or, for that matter, even if it does
18:46:22  <jwalden>hrm, would it? I tested without my bugfix and it failed, with it and it passed
18:46:31  <Bakkot>Maybe I’m just confused, then
18:46:38  <jwalden>but I am certainly open to the possibility that I don't know what I'm doing here :-)
18:47:33  <Bakkot>Oh, wait, right, I forgot how $DONE works.
18:47:40  <jwalden>so if I read the async docs correctly, if |async function f| returns a truthy value -- namely either of those two strings -- that'll get passed as argument to $DONE and that...yeah
18:47:58  <Bakkot>(i.e. it requires its argument to be falsy)
18:48:41  <Bakkot>I don’t _think_ the style is generally to rely on the condition in $DONE, but haven’t read too many of the async tests
18:48:44  <Bakkot>ignore my rambling
18:49:38  <jwalden>:-)
18:49:45  <jwalden>blind leading the blind here
18:49:55  <jwalden>where are the adults?
18:50:08  <Bakkot>leobalter, rwaldron ^ :)
18:50:17  <bterlson>lol I was just about to ping leobalter
18:50:43  <bterlson>should we call him "papa leo" from now on?
18:51:32  * Fishrock123quit (Remote host closed the connection)
18:52:09  * Fishrock123joined
18:54:30  <rwaldron>jswalden, your test looks correct to me!
18:54:45  <rwaldron>FWIW, I compared it to this .case: https://github.com/tc39/test262/blob/master/src/dstr-assignment-for-await/array-elem-trlg-iter-list-nrml-close-err.case#L53-L57
18:55:24  <rwaldron>👍🏽
18:55:47  <rwaldron>Oh wait...
18:55:58  <rwaldron>One thing, I can feedback here or on the PR?
18:56:47  * Fishrock123quit (Ping timeout: 252 seconds)
18:58:00  <jwalden>I'm watching both places :-)
18:58:59  <rwaldron>Just this:
18:59:08  <rwaldron>get [Symbol.iterator]
18:59:53  <jwalden>that's mostly just a fencepost to be sure the operation doesn't accidentally proceed past the @@asyncIterator get/test, and if it does things will Die
19:01:03  <rwaldron>Sorry, I just meant that it should be: "[Symbol.iterator]()", not "get [Symbol.iterator]()"
19:01:35  <jwalden>rwaldron: no, that was intentional -- even the mere act of *getting* is too far, shouldn't proceed past that to calling
19:01:48  <jwalden>I mean, sure, either would work
19:01:55  <jwalden>throw-on-get is just more restrictive
19:02:01  <rwaldron>Oh, because with get, you'll have this result: TypeError: fakeiter is not iterable
19:02:15  <rwaldron>I assumed you wanted that Test262Error to come through
19:02:32  * Fishrock123joined
19:03:20  <jwalden>hum, really? GetIterator's operation is "? GetMethod(obj, @@iterator)" so would just throw the T2E, and I think that would just propagate outward uncaught
19:04:30  <rwaldron>Can I try to walk through this with you? Maybe I've misunderstood something, so that might help
19:04:37  <jwalden>sure
19:05:02  <jwalden>https://tc39.github.io/proposal-async-iteration/#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind last step is what would make that GetIterator call, and seems like that would throw
19:06:57  <rwaldron>The normal execution of an asyncIter would first look for [Symbol.asyncIterator]() {} on an iterable, if it found that, it would call it (and so on); if it did not find one, it would then look for [Symbol.iterator]() {}, and if it found that, it would try to call it.
19:07:32  <rwaldron>In this case, it finds [Symbol.asyncIterator], but it's not a function, it's this other icky thing and that should end the whole show right there
19:08:31  <jwalden>rwaldron: yes, it'll call the icky thing and throw because the icky thing throws
19:09:06  <jwalden>rwaldron: the [Symbol.iterator] part is in case there's an implementation bug or something where the bad asyncIterator isn't called
19:09:13  <rwaldron>great, then my "concern" is downgraded to a "nit" and because it doesn't matter, nothing should ever get that far anyway
19:09:26  * rwaldronnods
19:09:29  <rwaldron>Cool
19:11:05  <rwaldron>Excuse me bterlson
19:11:13  <rwaldron>While we have your attention
19:11:14  <rwaldron>https://github.com/bterlson/eshost/pull/41
19:11:35  <rwaldron>That's relevant for supporting this ickiness that jwalden has uncovered
19:11:42  <rwaldron>thx in advance
19:11:53  <bterlson>rwaldron: I am investigating presently, IIRC ch.exe has some API to get the actual ULEO
19:12:01  <bterlson>will comment once I find it
19:12:01  <rwaldron>Oh rad
19:12:57  <rwaldron>I'm still trying to figure out how we might use %GetUndetectable() with d8 (as Bakkot mentions here https://github.com/bterlson/eshost/pull/41#issuecomment-337349144)
19:14:20  <rwaldron>I kind of want to do some fancy footwork with eshost and sniff out calls to `uncallableAndIsHTMLDDA()` in the source as a way to signal adding "--allow-natives-syntax" to hostArgs
19:14:50  <rwaldron>(in the d8 runtime)
19:15:12  <rwaldron>And by that I mean d8 agent. Obviously.
19:15:24  <rwaldron>;)
19:16:09  <bterlson>rwaldron: gah looks like the API is not available in ch.exe :/
19:22:23  <jwalden>rwaldron: whoops, was just looking at the test one last time to verify its failure in unpatched SpiderMonkey and saw a typo in it (plus an opportunity to put a bad-exception error message into the assert.sameValue message) -- mind taking a look at/merging the last micro-change on the same getiterator-async-funky branch?
19:24:22  <jwalden>rwaldron: https://github.com/jswalden/test262/commit/fe90a3f0db4f80114f10a4e4c1f05d817bea7b30
19:24:56  <jwalden>looks like when you push to a merged branch, Github switches to claiming the particular referenced commit is what was merged, loses recognition of what the branch was that was asked to be merged originally
19:25:00  <rwaldron>jwalden nope, don't mind
19:29:43  <rwaldron>jwalden https://github.com/tc39/test262/commit/99ee383d3fc2e10342842cad40bad89db123fdc1
19:29:55  <jwalden>woo
19:29:58  <jwalden>gentleman and a scholar
19:30:21  <rwaldron>lol 👍🏽
19:58:17  * bathosquit (Quit: bathos)
20:04:21  * Fishrock123quit (Remote host closed the connection)
20:04:48  * jwaldenhopes other impls will expose ULEOs in their shells, bets there are widespread bugs of this nature across implementations
20:04:59  * Fishrock123joined
20:06:03  <Bakkot>don’t necessarily need it in the shells! I will add the host hook to my web runner sometime soonish and just use the actual document.all
20:06:49  <Bakkot>in fact, I’m on lunch break right now, one sec…
20:08:25  <Bakkot>oh, wait. jwalden: uncallableAndIsHTMLDDA isn’t actually document.all?
20:09:09  <Bakkot>because document.all is callable without throwing a type error
20:09:12  * Fishrock123quit (Ping timeout: 258 seconds)
20:13:38  * bathosjoined
20:15:09  * Fishrock123joined
20:18:15  <jwalden>Bakkot: it *may* return document.all, but it isn't required to
20:18:29  <Bakkot>document.all doesn’t meet the requirements, though, does it?
20:18:42  <jwalden>Bakkot: Call(document.all, ..., <<>>) throws a TypeError
20:18:56  <jwalden>Bakkot: ^ that's the peculiar requirement of the return value of uncallableAndIsHTMLDDA
20:19:59  <Bakkot>… does it?
20:20:02  <jwalden>having an [[IsHTMLDDA]] internal slot is an optional add-on behavior that is permitted by uncallableAndIsHTMLDDA's interface
20:20:14  <jwalden>Bakkot: yes -- you're invoking it with too few arguments
20:20:42  <jwalden>Bakkot: uncallableAndIsHTMLDDA() { return {}; } is also an entirely permissible implementation, because it meets the uncallability requirement
20:20:56  <Bakkot>Ah. It does not throw when given no arguments in either chrome or safari
20:21:00  <Bakkot>Hence my confusion.
20:21:12  <jwalden>that...sounds wrong
20:21:19  * Fishrock123quit (Remote host closed the connection)
20:21:39  <Bakkot>Domenic would know the spec here, I expect
20:21:48  <jwalden>data:text/html,<script>try { document.all(); } catch (e) { document.write(e); }</script>
20:21:52  <jwalden>TypeError: Not enough arguments to HTMLAllCollection.__legacycaller.
20:21:55  <jwalden>^ Firefox behavior
20:22:15  <jwalden>and given we autogen the binding stuff for this I'd be very surprised if that's not the required behavior
20:22:18  * jwaldenconsults specs
20:22:46  <jwalden>oh, ugh
20:22:48  <jwalden>https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#HTMLAllCollection-call
20:23:02  <Domenic>Yeah... document.all is callable....
20:23:18  <Bakkot>Domenic: the question is, does calling it with no arguments throw or not
20:23:21  <jwalden>agreed it's callable, the question is its behavior on attempt to call
20:23:22  <Bakkot>Firefox thinks it does, for some reason
20:23:24  <Domenic>Why can't these just be WPT testing actual document.all, not this made up Mozilla JS she'll thing?
20:23:29  <jwalden>^ that URL seems pretty unambiguous
20:23:29  <Domenic>*shell
20:24:16  <Bakkot>Domenic: see discussion on https://github.com/tc39/test262/pull/1287
20:24:18  <jwalden>because WPT tests aren't run nearly as easily/frequently by people who primarily hack on an engine as an engine, not as an engine in a browser
20:24:38  <jwalden>sure, we write for browsers, but the majority of our work is browser-agnostic
20:24:40  * bathosquit (Quit: bathos)
20:24:51  <Domenic>How frequently does this test need to be run?
20:24:59  <jwalden>and for these tests, the vast bulk of the tests as written are ECMA functionality, and it's not really practical for WPT people to review them
20:25:45  <jwalden>depends how often we modify the relevant code, or even just write it
20:25:46  <Domenic>Isn't it normatively disallowed for other objects to have the IsHTMLDDA slot?
20:26:27  <jwalden>I don't believe it is -- spec heavily discourages having objects have it, but it doesn't/can't really restrict it to just document.all because that's beyond its purview
20:26:52  <Bakkot>Technically it’s a NOTE which I think implies not normative
20:27:08  <Domenic>Meh, I'm gonna give up on this, I'm burned out on test262 discussions. Sorry, gotta duck out.
20:27:08  <Bakkot>the “implementations should not create any [others]” bit, that is
20:27:14  * bathosjoined
20:27:38  <Bakkot>aaaanyway jwalden I think the hook in test262 should be fixed to match the spec’d behavior of document.all
20:28:44  <jwalden>definitely it's desirable/useful that a test here not require having a full browser build to test it, 'cause building a little JS engine versus a big browser is a very different degree of time requirement
20:28:46  <jwalden>anyway
20:28:50  * jwaldengoes to fix document.all()
20:35:17  <jwalden>now, it *may* be the case that .return === null or .@@asyncIterator === null causes a subsequent TypeError
20:35:27  <jwalden>or rather, when invoking either returns null causes one
20:37:27  <jwalden>"Let innerReturnResult be ? Call(return, iterator, « received.[[Value]] »)." "If Type(innerReturnResult) is not Object, throw a TypeError exception."
20:37:46  <jwalden>well, ugh
20:38:00  <jwalden>so in that case .return === document.all will cause a TypeError to be thrown
20:38:49  <jwalden>well, won't *necessarily*
20:39:20  <jwalden>on the other hand, if you can get received.[[Value]] to be "", then you would I think hit step 1 of https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#concept-get-all-named and return null and cause that TypeError
20:39:30  <jwalden>bah, this is all very sadmaking
20:44:47  * Fishrock123joined
20:49:03  * caitpquit (Ping timeout: 248 seconds)
20:53:16  * Fishrock123quit (Remote host closed the connection)
20:53:50  * Fishrock123joined
20:55:20  * caitpjoined
20:57:32  * not-an-aardvarkjoined
20:58:16  * Fishrock123quit (Ping timeout: 258 seconds)
21:04:47  * Fishrock123joined
21:09:03  * Fishrock123quit (Remote host closed the connection)
21:42:53  * bathosquit (Quit: bathos)
21:44:08  * bathosjoined
22:09:53  * Fishrock123joined
22:15:12  * Fishrock123quit (Ping timeout: 260 seconds)
22:20:32  * bathosquit (Quit: bathos)
22:51:58  * Fishrock123joined
23:33:36  * bathosjoined
23:34:09  * bathosquit (Client Quit)
23:34:47  * bathosjoined
23:38:10  * Fishrock123quit (Remote host closed the connection)
23:38:38  * Fishrock123joined
23:48:22  * bradleymeckjoined