00:11:37  * bradleymeckjoined
00:33:16  * AtumTquit (Remote host closed the connection)
01:07:57  * bradleymeckquit (Quit: bradleymeck)
01:16:34  * caridyquit (Remote host closed the connection)
01:17:23  * caridyjoined
01:21:15  * bradleymeckjoined
02:04:11  * bradleymeckquit (Quit: bradleymeck)
02:17:45  * bradleymeckjoined
03:16:01  * bradleymeckquit (Quit: bradleymeck)
03:35:03  * howdoijoined
03:51:56  * jmdyckquit (Quit: Leaving.)
05:24:23  * gskachkovquit (Quit: gskachkov)
06:39:22  * Draggorquit (Ping timeout: 240 seconds)
06:45:21  * Draggorjoined
06:52:05  * gskachkovjoined
07:08:32  * cloudshuquit (Quit: Connection closed for inactivity)
07:29:36  * gskachkovquit (Quit: gskachkov)
07:30:22  * caridyquit (Ping timeout: 276 seconds)
07:31:45  * gskachkovjoined
07:35:15  * caridyjoined
10:17:10  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
10:25:10  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
10:25:52  * AtumTjoined
10:52:57  * caridyquit (Remote host closed the connection)
10:53:44  * caridyjoined
11:00:16  * STRMLquit (Ping timeout: 248 seconds)
11:05:06  * STRMLjoined
11:29:21  * jmdyckjoined
12:07:34  * gibson042quit (Ping timeout: 246 seconds)
13:06:42  * howdoiquit (Quit: Connection closed for inactivity)
13:22:21  * jmdyckquit (Ping timeout: 240 seconds)
13:22:23  * jmdyck1joined
13:54:30  * caridyquit (Remote host closed the connection)
13:55:08  * caridyjoined
14:22:34  * Fishrock123joined
15:04:59  * abernixjoined
15:06:41  * gskachkovquit (Quit: gskachkov)
15:07:15  * gskachkovjoined
15:11:23  * bradleymeckjoined
15:16:27  * gskachkovquit (Ping timeout: 240 seconds)
15:21:39  * Fishrock123quit (Remote host closed the connection)
15:40:05  * Fishrock123joined
15:44:52  * cloudshujoined
16:32:03  * Fishrock123quit (Remote host closed the connection)
16:32:40  * Fishrock123joined
16:32:48  * Fishrock123quit (Remote host closed the connection)
16:41:35  * Fishrock123joined
16:53:24  * howdoijoined
16:58:17  * bradleymeckquit (Quit: bradleymeck)
17:22:48  * gskachkovjoined
18:04:54  * bradleymeckjoined
18:31:28  * Fishrock123quit (Remote host closed the connection)
18:33:05  * Fishrock123joined
18:38:35  * Fishrock123quit (Remote host closed the connection)
18:42:34  * Fishrock123joined
18:43:49  * Fishrock123quit (Remote host closed the connection)
18:53:05  * Fishrock123joined
20:02:03  * not-an-aardvarkjoined
20:40:50  * jridgewelljoined
20:45:00  * jridgewellquit (Client Quit)
20:45:24  * jridgewelljoined
21:09:48  * abernixquit (Quit: Bye)
22:11:33  * jridgewellquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:17:33  * jridgewelljoined
22:18:30  * bradleymeckquit (Quit: bradleymeck)
22:18:48  <bterlson>jmdyck1: ping?
22:32:42  <jmdyck1>bterlson: pong?
22:33:59  <bterlson>jmdyck1: objections to adding use=example, use=definition, and default use=reference? (l like use over status, personally)
22:35:00  <bterlson>jmdyck1: sorry this is for https://github.com/tc39/ecma262/pull/960
22:37:08  <jmdyck1>if you like 'use' over 'status', i won't object. There's still my qualm about 'reference', but if it's the default, people won't actually see it, so not as big a deal.
22:38:12  <bterlson>which qualm over "reference"?
22:38:20  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
22:38:23  <bterlson>the word you mean?
22:38:33  <jmdyck1>yup,
22:38:43  <jmdyck1>see the issue.
22:39:44  <jmdyck1>https://github.com/tc39/ecma262/pull/960#issuecomment-318527414
22:39:45  <bterlson>right ok, just making sure it's not a semantic concern
22:39:56  <bterlson>I buy your point
22:40:01  <bterlson>I can read it both ways in my head
22:40:13  <bterlson>tbh I just want to get this in so I can get my nice tooling, we can discuss changes over time
22:40:20  <bterlson>Ron kind of wants them to be different elements entirely
22:40:38  <jmdyck1>oh!
22:40:51  <jmdyck1><emu-grammar-def>, etc?
22:41:04  <bterlson>yeah
22:41:20  <jmdyck1>hm
22:41:28  <bterlson>could even re-use emu-prodref
22:41:36  <bterlson>for use=reference
22:42:06  <jmdyck1>isn't emu-prodref a single production?
22:42:17  <bterlson>custom elements can't be void unfortunately
22:42:31  <bterlson>but its contents are replaced based on its attributes
22:42:58  <jmdyck1>i'm not following what you're suggesting
22:44:20  * bradleymeckjoined
22:44:21  <bterlson>Idea is you can either refer by using emu-prodref's attrs (emu-prodref name=NonTerminal) or by copying the production into the emu-prodref element (in which case it is verified to be identical to some existing production)
22:44:40  * bradleymeckquit (Client Quit)
22:45:12  <bterlson>jmdyck1: pick 1: use, status, mode, class, type
22:45:23  <bterlson>now that I look at type it feels good to me
22:46:42  <jmdyck1>"type" is better than "use", i'd say.
22:47:33  <jmdyck1>i might even prefer it over "status" if it weren't for the general overuse of "type"
22:48:09  <bterlson>hah I know
22:48:35  <bterlson>TabAtkins: pedantry afoot: ^
22:48:44  <jmdyck1>("mode" doesn't sound right to me at all.)
22:48:57  <TabAtkins>Ahaha, I don't care what y'all do for this. ^_^
22:49:13  <bterlson>mode makes sense when you look at it from the dev tools/GMD implementation perspective ;)
22:49:23  <TabAtkins>I'm busy micro-optimizing. Shaved about a second off of the DOM spec's generation time already!
22:49:25  <bterlson>which is not the right perspective I agree
22:49:38  <bterlson>TabAtkins: you and me both!! I spent the weekend trying to make loops go faster.
22:50:11  <TabAtkins>Turns out the secret is: don't do work you dont' need to, duh.
22:51:05  <bterlson>I think the next big gains for emu are going to come from incremental build
22:51:23  <bterlson>it's getting hard to justify perf work when I could just do incremental build and make it mostly irrelevant
22:51:58  <jmdyck1>Of those choices, I think i still prefer "status".
22:52:25  <jmdyck1>there might be a better word though...
22:52:32  <TabAtkins>Incremental build?
22:52:39  <bterlson>status > type > use, for you?
22:53:06  <bterlson>TabAtkins: yeah, only rebuilding the parts of the spec that changed, and just pull the rest of the content verbatim from an existing build source document or metadata file
22:53:23  <bterlson>s/build source document/built document
22:53:30  <TabAtkins>Interesting.
22:53:58  <TabAtkins>I'd like to do something like that, if only to let me start flagging some sorts of errors that are only obvious from a delta.
22:54:22  <jmdyck1>actually, i can see why "status" sounds wrong, if you think of something's status changing over time.
22:54:35  <jmdyck1>"kind"?
22:55:24  <bterlson>the "type" vs. "kind" debate is one I always have with myself and never have a good reason to pick one or the other
22:55:54  <TabAtkins>Go with Haskell/etc; "kind" describes higher-order types (types of types) only. ^_^
22:56:08  <jmdyck1>164 uses of "kind" in spec, 2682 of "type"
22:56:20  <jmdyck1>(case insensitive)
22:56:21  <bterlson>type= has a few uses
22:56:44  <bterlson>I think type is more common than kind (see, e.g., all the various AST formats)
22:56:44  <jmdyck1>kind= has 0 uses
22:57:14  <bterlson>ok going with type= for now, we can change it later
22:57:18  <jmdyck1>if it's a tossup between type and kind, i'm ok with either
22:57:19  <bterlson>I think we'll eventually want distinct elements
22:57:37  <jmdyck1>separate issue for that!
22:57:42  <bterlson>yep
22:58:00  <jmdyck1>done for now? (late for supper)
22:58:14  <bterlson>jmdyck1: yes thank you :-D
22:58:18  <jmdyck1>afk
23:08:53  * Fishrock123quit (Remote host closed the connection)
23:10:06  <Domenic>Incremental build seems a little easier in ecmarkup than Bikeshed due to Ecmarkup's extensive use of nested sections
23:10:16  <Domenic>(in the source document)
23:10:40  <Domenic>So you can very precisely say what part of the output tree will change, since you know what part of the input tree did, and you already have a good granularity (emu-clause)
23:10:51  <Domenic>Whereas in Bikeshed a lot of people do <hN> style flat documents
23:18:40  <TabAtkins>On that note, I'm strongly wondering if it's worthwhile to do an "automatically section-ize document" pass; I'm spending a decent amount of time searching for "relevant headings" for each element, when I'd prefer to just do an ancestor walk.
23:19:41  <TabAtkins>I'm also getting ever-more anxious to just write my own HTML parser and DOM tree; a ton of my runtime is spent in parsing and in running selectors, when I could instead just be heavily caching instead.
23:31:29  <bterlson>TabAtkins: biggest perf boost I got to date was the rewrite where I went from random builders calling querySelectorAll and etc. to a single forward pass of the document
23:31:42  <bterlson>code is now 10x more complex but 10x faster too
23:32:00  <TabAtkins>My querySelector calls only amount to 7% of runtime even on a large document; I've eliminated a lot of it.
23:32:19  <TabAtkins>Single forward pass would be... interesting, but I probably wouldn't get a ton out of it.
23:32:46  <TabAtkins>I presume you handle it by stashing the things you'll need to process based on whole-document info, and just running thru them at the end?
23:32:46  <bterlson>yeah if QSA is only 7%
23:32:56  <bterlson>exactly
23:33:01  <bterlson>including ALL text nodes
23:33:14  <TabAtkins>Oh gosh.
23:33:17  <bterlson>and other random bits
23:34:09  <TabAtkins>All told that would probably be worthwhile, honestly. qSA is only 7%, but I do lot more tree-walking and attr-checking that would speed up a ton if it was just some set-membership checks.
23:34:17  <TabAtkins>I bet I could drop 20% from it.
23:34:47  <bterlson>you're probably a better coder than I am but the understandability of the build process took a giant hit
23:35:04  <bterlson>that not even a massive "here's what's going to happen" comment could fix :-P
23:35:30  <TabAtkins>Eh, most of the complexity falls into the dom-mutator methods, which need to shuffle things around.
23:35:35  <bterlson>Domenic: You're right about emu-clause being helpful for this
23:35:45  <bterlson>Domenic: I'm also using it as the granularity level for my lazy renderer
23:36:16  <bterlson>(where this = incremental build)
23:36:48  <TabAtkins>(Interesting - checking over my empty-document cProfile data, it looks like about 30% of runtime is just loading modules.)
23:37:00  <bterlson>heh
23:37:09  <bterlson>require('jsdom') still takes like 500ms for me
23:37:27  <TabAtkins>Woah!
23:37:50  <TabAtkins>Luckily empty-document is down to about 500ms total now, so the module loading cost is only about 150ms.
23:40:46  * jridgewellquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
23:54:37  * cloudshuquit (Quit: Connection closed for inactivity)
23:56:32  * jridgewelljoined