00:18:01  * cybaijoined
00:19:06  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:21:34  * keith_millerjoined
00:39:11  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:42:22  * keith_millerjoined
00:46:51  * AtumTquit (Quit: AtumT)
01:01:20  * Jessidhiajoined
01:05:12  * cybaiquit (Remote host closed the connection)
01:30:37  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:41:42  * cybaijoined
03:03:06  * howdoiquit (Quit: Connection closed for inactivity)
03:22:57  * cloudshuquit (Quit: Connection closed for inactivity)
05:13:20  * gibson042quit (Quit: Leaving.)
05:36:33  * jmdyckquit (Remote host closed the connection)
06:50:11  * keith_millerjoined
06:56:26  * mquy90joined
06:56:39  * mquy90quit (Remote host closed the connection)
06:56:59  * kpattichajoined
07:01:39  * kpattichaquit (Ping timeout: 258 seconds)
07:10:27  * kpattichajoined
07:24:34  * mgoljoined
07:28:05  * mgolquit (Client Quit)
07:44:48  * mgoljoined
08:49:03  * srl295quit (Quit: Connection closed for inactivity)
09:11:02  * Jessidhiaquit (Disconnected by services)
10:30:07  * Jessidhiajoined
10:55:33  * cybaiquit (Remote host closed the connection)
10:59:47  * keith_millerquit (Quit: Textual IRC Client: www.textualapp.com)
11:29:44  * jmdyckjoined
11:40:08  * cybaijoined
13:13:54  * gibson042joined
14:02:40  <devsnek>is it acceptable to spec generator methods using `GeneratorYield` instead of a prototype with a next method?
14:03:20  <devsnek>that came out awkwardly
14:03:49  <devsnek>is it acceptable to spec functions in the spec that return iterators as generators and use GeneratorYield or something, instead of returning the big prototype+next thing
14:20:10  <Domenic>devsnek: the decision in the past has always been a new prototype. There was a thread about this at some point. I think it might be worth reconsidering, but I would give a 70% chance we stay the course.
14:35:01  * Nimelrian_joined
14:46:41  <devsnek>Domenic: I feel like people might change their minds with the iterator methods proposal
14:47:03  <Domenic>Maybe. There's already tons of iterators on the web platform, and I asked if we should consolidate, and people said we should not.
14:47:23  <devsnek>being able to say "a generator function that when called performs the following steps" seems so nice
14:47:50  <devsnek>would also get rid of having to manually define error and return handling
14:52:46  <Domenic>I think you should just macro harder
14:52:55  <Domenic>Create spec infra that will generate your iterator prototypes etc. for you
14:54:17  <devsnek>like the typed arrays?
15:01:36  <Domenic>Yeah, something like that
15:02:13  <Domenic>Or figure out a way to write a generator function-ish body that generates a set of next()/throw()/return() function
15:03:11  * cloudshujoined
15:09:23  * cybaiquit (Remote host closed the connection)
15:17:08  <devsnek>that sounds like "a generator function that when called runs the following steps"
15:24:53  * cybaijoined
15:27:03  * cybaiquit (Remote host closed the connection)
15:29:28  <Domenic>Yep but the spec text generates some new prototype
16:01:21  * cybaijoined
16:01:30  * kpattichaquit (Quit: Leaving)
16:06:43  * cybaiquit (Ping timeout: 276 seconds)
16:20:34  * srl295joined
16:58:26  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:04:39  * jwaldenjoined
17:19:32  * cybaijoined
17:21:03  <jmdyck>So if there's a PR against tc39/ecma262, that doesn't have any existence in the tc39/ecma262 repo, right?
17:22:07  <ljharb>jmdyck: github auto-creates a ref for every PR, so you can get to it programmatically if you want. but git won't fetch those refs by default
17:22:35  <jmdyck>ah, so how do it get to it?
17:23:35  <ljharb>jmdyck: https://gist.github.com/piscisaureus/3342247
17:24:08  * cybaiquit (Ping timeout: 258 seconds)
17:27:05  <jmdyck>wah, so many rull requests.
17:27:14  <jmdyck>-s/rull/pull/
17:27:21  <ljharb>lol yeah it'll be more useful on future fetches
17:28:24  <jmdyck>(hoping to detect editorial stuff before it gets merged into master.)
17:31:31  <ljharb>jmdyck: if you have any kind of reliable programmatic mechanism it'd be great to add it to CI on every PR :-D
17:34:08  <jmdyck>not reliable, no.
17:34:28  <jmdyck>not until ecmaspeak has a reliable spec.
17:35:48  <jmdyck>Mind you, checking for well-formedness of markup would be a good start.
17:36:17  <jmdyck>There should be reliable utilities for that.
17:42:13  * ljharbany correctness or consistency tools that you'd like to add would be very welcome :-)
17:44:35  <Domenic>We run validator.nu on every pull request for WHATWG specs
17:45:34  <Domenic>https://github.com/whatwg/whatwg.org/blob/be5d39e4bce5248039816c9fdbccd02f9f840f86/resources.whatwg.org/build/deploy.sh#L179
17:50:44  <jmdyck>I just ran validator.nu against spec.html: 19 errors + 5 warnings
17:55:48  <jmdyck>A bunch would disappear once my editorial PR is merged ;)
17:55:57  <jmdyck>but there'd still be some left.
18:03:47  <Domenic>Well, spec.html isn't the interesting thing
18:03:54  <Domenic>https://validator.nu/?doc=https%3A%2F%2Ftc39.github.io%2Fecma262 is the important one.
18:05:25  <jmdyck>that too, but it's easier to fix spec.html's problems.
18:07:23  <Domenic>ElementInternals & form-associated custom elements are one big topic
18:07:27  <Domenic>Oops wrong channel
18:08:13  <jmdyck>(and fixing spec.html is mostly a prerequisite to getting the rendered version error-free)
18:08:21  * keith_millerjoined
18:27:43  <ljharb>we could validate both the raw and the built version on PRs.
18:28:17  * AtumTjoined
18:30:59  * mgoljoined
18:51:18  * keith_millerquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:00:28  <Domenic>I just don't think validating the source document is useful.
19:02:11  <jmdyck>It gives you a smaller set of problems to look at, that you know aren't caused by the rendering process. That seems moderately useful.
19:03:15  <jmdyck>Moreover, once you've taken care of them, you know that all the errors in the rendered spec *are* caused by the rendering process.
19:03:45  <Domenic>But it's not clear there's any mapping between errors in the source doc vs. the output. E.g. the tooling fixes up some errors or changes them.
19:03:57  <Domenic>Like any well-formedness errors will get automatically fixed by the tooling.
19:04:03  <Domenic>(Since it parses and serializes)
19:06:40  <jmdyck>and yet the rendered spec *does* have well-formedness errors inherited from spec.html
19:11:39  <ljharb>? validating build output is what i'd expect to be not useful (except for maintainers of the build tool); just like linting, validating the source is what provides actional feedback to PR authors
19:13:55  <Domenic>The users see the build output
19:13:59  <Domenic>The source isn't even HTML
19:14:06  <Domenic>Validating it with a HTML validation tool is dubious
19:14:15  <ljharb>oh sure, i agree with that
19:14:21  <ljharb>what i think is useful on 262 tho is validating the source
19:14:44  <ljharb>(which validator.nu may not be the right tool for)
19:15:37  <jmdyck>based on the validator.nu ouput, it looks like spec.html is closer to being html than the rendered output is.
19:16:02  <Bakkot>in my ideal world ecmarkup would just be really strict about what it accepted, such that "ecmarkup accepts it" would be sufficient to validate the source
19:16:20  <ljharb>Bakkot: that would be totally great, and we could add that to CI too
19:16:27  <Bakkot>if we were comfortable assuming ecmarkup only produced well-formed output we would not then need to run the output through validator.nu; if we weren't we could do that as well
19:17:38  <Bakkot>while we're kicking all this around, prettier has this neat thing were every PR automatically gets a link to a place you can use the project as it would be after the PR merge (e.g. the link at the bottom of https://github.com/prettier/prettier/pull/5996 )
19:17:52  <Bakkot>and having a similar bot linking the rendered spec to each PR would be nice
19:18:17  <jmdyck>what if there are merge conflicts?
19:18:26  <Bakkot>it just doesn't work, IIRC
19:18:39  <Bakkot>updates when the branch updates, so when the conflicts are fixed you get a working link
19:20:16  <Domenic>Yes, we have that on all web specs
19:20:23  <jmdyck>Bakkot: my tools are pretty strict about what they accept, but that's why I have to change them frequently.
19:20:31  <Domenic>See e.g. https://github.com/whatwg/html/pull/4383 after the <hr>
19:27:18  <jmdyck>E.g., the dynamic import PR uses dl/dt/dt, which spec.html hasn't had before, so my code says (in effect) "what is this?" But it seems reasonable for the spec to use them, so I add them to my code. Which is why it'd be problematic to use my code in CI.
19:32:14  <jmdyck>And it's not uncommon for algorithm-related PRs to use new pseudocode syntax.
19:46:07  * Nimelrian_quit (Ping timeout: 240 seconds)
19:48:15  * mgolquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:40:31  * gibson042quit (Quit: Leaving.)
22:51:03  * keith_m__quit (Ping timeout: 264 seconds)
22:52:57  * keith_millerjoined