00:46:40
| * AtumT | quit (Remote host closed the connection) |
01:14:31
| * bradleymeck | joined |
01:55:04
| * bradleymeck | quit (Quit: bradleymeck) |
02:08:35
| <jmdyck> | https://tc39.github.io/ecma262/#sec-well-known-intrinsic-objects says that well-known intrinsics *usually* have realm-specific identities. Which *don't*? |
02:10:46
| <jmdyck> | https://tc39.github.io/ecma262/#sec-createintrinsics says that everything in table 7 has a new instance created for each new realm. |
02:21:02
| * caitp | quit (Ping timeout: 276 seconds) |
02:22:22
| * caitp | joined |
02:22:47
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
02:22:49
| <jmdyck> | I suppose a host env could define intrinsics that exist outside any realm, but does the spec define any such? |
02:25:40
| <Domenic> | All of the well-known symbols are realm-agnostic... |
02:35:16
| <jmdyck> | right, but a symbol isn't an intrinsic |
02:39:47
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
02:41:51
| * keith_miller | joined |
02:42:02
| * keith_miller | quit (Client Quit) |
02:44:26
| <jschoi> | No term resembling “nearest outer environment” is defined in https://tc39.github.io/ecma262/#sec-lexical-environments; what would be the best way to refer to such a concept? For instance, “For each identifier _N_, the running execution context’s Lexical Environment uses the binding from the nearest outer environment that defines a binding for _N_.” |
02:45:55
| <jschoi> | Only “outer environment” and “inner environment” are defined; concepts such as recursive lexical “inheritance” of bindings seem to be left implied in the algorithms. |
02:49:47
| <jmdyck> | best way might be to define an operation. |
02:55:16
| <jschoi> | Yeah, a recursive operation is defined. This terminology problem is occurring in a prose description of that operation, heh. |
03:03:18
| <jmdyck> | You can define a prose phrase as the result of invoking an operation. |
03:07:10
| <jmdyck> | no wait, if this is in a prose description of the operation that defines the desired semantics, then you shouldn't need to refer to something else. |
03:10:40
| * cloudshu | quit (Quit: Connection closed for inactivity) |
03:33:41
| * leobalter | quit (Ping timeout: 265 seconds) |
03:33:55
| * leobalter | joined |
03:37:34
| * keith_miller | joined |
03:37:41
| * cloudshu | joined |
04:28:16
| * jmdyck | quit (Remote host closed the connection) |
04:32:56
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
04:34:37
| * keith_miller | joined |
04:57:02
| * spion | quit (Excess Flood) |
04:58:09
| * spion | joined |
05:15:52
| * gibson042 | quit (Quit: Leaving.) |
05:23:43
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
05:24:51
| * keith_miller | joined |
05:34:39
| <jschoi> | In https://tc39.github.io/ecma262/#sec-variablestatements-in-catch-blocks, `<emu-alg>` elements use a type attribute with value `i`, in a manner undocumented on https://bterlson.github.io/ecmarkup/ – `<emu-alg type="i">`. What does this attribute mean? |
07:29:19
| * gskachkov | joined |
07:35:59
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
08:13:35
| * jwalden | joined |
08:29:30
| * gskachkov_ | joined |
08:32:35
| * gskachkov | quit (Ping timeout: 256 seconds) |
08:32:35
| * gskachkov_ | changed nick to gskachkov |
08:35:49
| * keith_miller | joined |
08:39:36
| * gskachkov | quit (Quit: gskachkov) |
08:55:58
| * gskachkov | joined |
08:58:55
| * gskachkov_ | joined |
09:00:47
| * gskachkov | quit (Ping timeout: 276 seconds) |
09:00:47
| * gskachkov_ | changed nick to gskachkov |
09:22:23
| * not-an-aardvark | quit (Quit: Connection closed for inactivity) |
09:36:51
| * keith_miller | quit (Read error: Connection reset by peer) |
09:40:31
| * keith_miller | joined |
09:56:48
| * jwalden | quit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805]) |
10:29:33
| * AtumT | joined |
10:30:40
| * cloudshu | quit (Quit: Connection closed for inactivity) |
10:38:40
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
10:59:12
| * spectranaut | quit (Ping timeout: 264 seconds) |
10:59:13
| * spectranaut | joined |
11:25:12
| * mylesborins | quit (Quit: farewell for now) |
11:25:42
| * mylesborins | joined |
11:27:46
| * spectranaut_ | joined |
11:34:26
| * spectranaut | quit (Ping timeout: 264 seconds) |
12:12:58
| * gskachkov_ | joined |
12:14:09
| * gskachkov | quit (Ping timeout: 256 seconds) |
12:14:09
| * gskachkov_ | changed nick to gskachkov |
12:16:55
| * gskachkov_ | joined |
12:18:35
| * gskachkov | quit (Ping timeout: 255 seconds) |
12:18:36
| * gskachkov_ | changed nick to gskachkov |
12:24:29
| * bob___ | joined |
12:35:45
| <bob___> | yo |
12:35:51
| * bob___ | quit (Quit: Page closed) |
12:50:32
| * Wizek | quit (Ping timeout: 255 seconds) |
12:52:38
| * zkat | quit (Ping timeout: 255 seconds) |
12:54:20
| * zkat | joined |
12:56:36
| * Wizek | joined |
13:09:23
| * jmdyck | joined |
13:16:38
| * flet | quit (Ping timeout: 255 seconds) |
13:18:13
| * serbang | quit (Quit: Connection closed for inactivity) |
13:18:59
| * flet | joined |
13:33:06
| <jmdyck> | jschoi: `<emu-alg type="i">` is, I think, supposed to render the steps in lower-case roman numerals, to match what they would get if you spliced them in at the designated place. It doesn't work though. |
13:33:30
| <jschoi> | Ah, thank you. |
13:35:58
| <jmdyck> | https://github.com/domenic/ecmarkdown/issues/37 |
13:52:02
| * mathiasbynens | quit (Ping timeout: 255 seconds) |
13:54:01
| * mathiasbynens | joined |
14:04:51
| * bradleymeck | joined |
14:43:55
| * bradleymeck | quit (Quit: bradleymeck) |
15:00:24
| * bradleymeck | joined |
15:15:32
| * keith_miller | joined |
15:17:27
| * cloudshu | joined |
15:29:28
| * bradleymeck | quit (Read error: Connection reset by peer) |
15:29:42
| * bradleymeck | joined |
15:56:10
| * gskachkov | quit (Ping timeout: 240 seconds) |
16:06:07
| * bradleymeck | quit (Quit: bradleymeck) |
16:13:52
| * AtumT_ | joined |
16:17:03
| * AtumT | quit (Ping timeout: 256 seconds) |
16:27:41
| * AtumT | joined |
16:28:17
| * AtumT_ | quit (Ping timeout: 248 seconds) |
16:57:24
| * Fishrock123 | joined |
17:15:25
| * bradleymeck | joined |
17:26:13
| * gskachkov | joined |
17:54:02
| * gskachkov | quit (Quit: gskachkov) |
17:54:06
| * bradleymeck | quit (Quit: bradleymeck) |
18:02:57
| * gskachkov | joined |
18:04:57
| * Wizek | quit (Remote host closed the connection) |
18:05:35
| * Wizek | joined |
18:05:44
| * Wes- | joined |
18:26:58
| * gskachkov | quit (Quit: gskachkov) |
18:27:57
| * bradleymeck | joined |
18:35:07
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
18:37:30
| * not-an-aardvark | joined |
18:46:31
| * keith_miller | joined |
18:55:01
| * gskachkov | joined |
18:58:55
| * gskachkov | quit (Client Quit) |
19:00:38
| * gskachkov | joined |
19:05:55
| * jmdyck1 | joined |
19:06:14
| * jmdyck | quit (Ping timeout: 256 seconds) |
19:07:49
| * Fishrock123 | quit (Remote host closed the connection) |
19:16:49
| * Fishrock123 | joined |
19:17:02
| * Fishrock123 | quit (Remote host closed the connection) |
19:29:08
| * gskachkov | quit (Quit: gskachkov) |
19:31:47
| * gskachkov | joined |
19:33:47
| * Fishrock123 | joined |
19:41:03
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
19:46:56
| * keith_miller | joined |
20:09:57
| * Wes- | quit (Quit: Leaving) |
20:41:00
| * keith_miller | quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:42:56
| * keith_miller | joined |
20:46:57
| * jwalden | joined |
21:47:25
| * bradleymeck | quit (Quit: bradleymeck) |
22:05:19
| * jmdyck1 | quit (Ping timeout: 248 seconds) |
22:05:37
| * jmdyck | joined |
22:30:20
| * bradleymeck | joined |
23:01:35
| * bradleymeck | quit (Quit: bradleymeck) |
23:10:50
| <jschoi> | Is a copyright notice and license required at the end of a proposal spec? For instance, the appendix of https://tc39.github.io/proposal-nullish-coalescing/. |
23:11:12
| <jschoi> | I’m also a little confused how I would add it. The source for that spec doesn’t have the appendix: https://github.com/tc39/proposal-nullish-coalescing/blob/master/spec.html. |
23:13:34
| <jschoi> | Ah, I had missed there was a --copyright flag for the ecmarkup CLI…Strange, though; https://bterlson.github.io/ecmarkup/ says that the flag is default true. That hasn’t been true for me. |
23:15:04
| <jschoi> | …And that flag isn’t even working for me. Is it trying to transclude some license file in my repository? |
23:15:34
| <jschoi> | `ecmarkup spec.html out/index.html --assets inline --copyright true`, that is. |
23:16:02
| <bterlson> | jschoi: it gets generated automatically if you have contributors set in your frontmatter |
23:16:12
| <jschoi> | Ah, thank you. |
23:16:13
| <bterlson> | without contributors it doesn't know what to generate |
23:16:22
| <bterlson> | if there isn't an error for that case, it's a bug and you should file it ;) |
23:16:49
| <jschoi> | Will do. |
23:22:22
| <jschoi> | Looks like `--contributors "J. S Choi, Ecma International”`also is insufficient to generate a copyright. You still need `--copyright true`, contrary to the documentation. Is that also a bug? |
23:22:37
| <jschoi> | That `”` is supposed to be a straight quote. |
23:26:05
| <jschoi> | Also, is it “ECMA International” or “Ecma International”? |
23:28:46
| <jschoi> | Incidentally, https://bterlson.github.io/ecmarkup/ is somewhow now crashing Safari Technology Preview 50. That’s pretty funny… |
23:29:00
| <jschoi> | Or, er, rather, its tab process. |
23:32:45
| <bterlson> | jschoi: fun!!! LMK if you find out why (or report a bug I can track) |
23:33:02
| <bterlson> | jschoi: it should be Ecma now (recentish name change) |
23:33:26
| <bterlson> | jschoi: seems possibly a bug. You may also need to specify stage, as the boilerplate changes depending on whether it's a proposal or draft |
23:33:52
| <bterlson> | jschoi: I'm going back to emu changes tomorrow, I'll take a look then |
23:38:15
| <jschoi> | Oh, yeah, `--stage -1` doesn’t seem to be supported. Which isn’t surprising, since it’s not even actually a thing, but I can’t say I’m Stage 0 yet, haha… |
23:38:24
| <jschoi> | https://jschoi.org/18/es-smart-pipelines/spec will have to do for now. |
23:38:26
| <bterlson> | stage 0 |
23:38:27
| <jschoi> | Thanks for explaining everything. |
23:38:33
| <jschoi> | Okay, I’ll do that. |
23:38:33
| <bterlson> | is the first stage |
23:38:42
| <bterlson> | any idea a delegate has is already stage 0 ;) |
23:38:46
| <jschoi> | Yeah, but it has to be Backed by a Delegate. |
23:38:56
| <jschoi> | Which I guess I can probably say, but… |
23:40:01
| <bterlson> | jschoi: looks good at a high level, though I think you could dispense with ins for entirely new clauses |
23:40:02
| <jschoi> | I really like how it automatically marks the date of generation as the default draft version number. |
23:40:15
| <jschoi> | Thanks! |
23:40:23
| <bterlson> | we tend to just use ins/del for finer-grain changes |
23:40:55
| <jschoi> | Okay, so not so much for editors’ notes. |
23:40:58
| <jschoi> | Will remove. |
23:41:04
| <jschoi> | Thanks for checking. |
23:41:29
| <jschoi> | What about the new sections’ content? |
23:41:36
| <jschoi> | Should `<ins class=block>` be removed from them too? |
23:42:28
| <bterlson> | I mean, there's no rule, but IMO if you're adding an entire clause, no ins needed, it's clearly new. |
23:42:30
| <jschoi> | Oh wait, I misunderstood. |
23:42:37
| <jschoi> | You said “new clauses” not “editors’ notes about new clauses”. |
23:42:41
| <bterlson> | yeah :) |
23:42:56
| <jschoi> | 👍🏻 |
23:42:58
| <bterlson> | ins/del are just clarity aids, you can use them if you think it helps, or not if you don't :) |
23:43:22
| <jschoi> | Right. Someone will manually merge the final proposal spec, I presume. No automatic merging by clause ID. |
23:43:30
| <jschoi> | *would |
23:43:56
| <bterlson> | Yeah, that's done once you're ready for Stage 4. We can cross that bridge when the time comes. |
23:44:07
| <jschoi> | Ah, so that *is* how it’s done. Super cool. |
23:44:20
| <bterlson> | it's a manual process for now |
23:44:22
| <jschoi> | Oh, wait, no, you didn’t say whether it was manual or automatic. Oh well, either way. |
23:44:25
| <jschoi> | Haha, I need a nap. |
23:44:28
| <jschoi> | Thank you again for your guidance. |
23:44:28
| <bterlson> | I will start working soon on actual support for modifying another spec document (what I'm calling a diffspec) which would allow simply "applying" it |
23:44:33
| <jschoi> | Oh, nice. |
23:44:47
| <jschoi> | Like a…big annotation. |
23:45:02
| <jschoi> | With automatic application to target anchors. |
23:45:43
| <bterlson> | jschoi: https://github.com/bterlson/ecmarkup/issues/114 |
23:46:02
| <jschoi> | Super cool. |
23:46:12
| <jschoi> | I have been very impressed with this spec process. |
23:46:54
| <bterlson> | Glad to hear it, though it can always be better ;) |
23:51:54
| * Fishrock123 | quit (Quit: Leaving...) |
23:56:00
| <ljharb> | bterlson: i dunno, i tend to think "stage 0" requires at least mentioning it at a meeting :-p |
23:56:29
| <jschoi> | Hopefully it’s now more readable without all the `<ins class=block>`blocks: file:///Users/sunchild/Developer/proposal-smart-pipelines/out/index.html. |
23:56:41
| <ljharb> | jschoi: that's a local path :-p |
23:56:43
| <jschoi> | Oh, whoops. Dang, and now that path is public, pft. |
23:56:52
| <jschoi> | https://jschoi.org/18/es-smart-pipelines/spec |
23:56:56
| <jschoi> | Oh well. |