00:04:42  * Garbeequit (Quit: Connection closed for inactivity)
00:07:53  <jwolfe>is there a more direct way to get to the GeneratorFunction constructor than `var GeneratorFunction = function*(){}.constructor;`?
00:52:07  <aklein>jwolfe: looks about right. I can't remember the rationale for not sticking GeneratorFunction on the global
03:01:16  * zvquit (Ping timeout: 272 seconds)
03:12:32  * zvjoined
04:18:12  * zvquit (Ping timeout: 276 seconds)
04:30:18  * zvjoined
05:24:29  * plutoniixquit (Quit: Leaving)
07:56:31  * thefourtheyejoined
10:40:25  * davijoined
10:40:25  * daviquit (Changing host)
10:40:25  * davijoined
11:40:17  * RT|Chatzillaquit (Read error: Connection reset by peer)
11:42:09  * RT|Chatzillajoined
12:18:11  * daviquit (Ping timeout: 240 seconds)
13:07:12  * Garbeejoined
13:23:26  * plutoniixjoined
15:53:02  <caitp>I thought they wanted to export it from a Module rather than sticking it in all global code
15:53:25  <caitp>ditto for the AsyncFunction constructor
15:55:06  <jwolfe>caitp, but modules aren't ready to go yet, right?
15:55:14  <caitp>correct
15:56:05  <caitp>and I have no idea why they thought Map and Set and WeakMap and WeakSet were okay on the global object, but "GeneratorFunction" was not okay.
16:43:13  <caitp>yo, so basically, all of our parsing contexts can certainly be implemented in headers, if that helps people --- but the actual grammar parsing stuff ought to be implemented in a source file
16:43:29  <caitp>something implementing "build-an-AST" might live in a header, but it wouldn't have to change that often
16:44:02  <caitp>but the code implementing the grammar ought to live elsewhere, imo
16:44:12  <caitp>because that changes often
16:47:50  <caitp>and not having multiple implementations of different grammar productions would be cool, too
16:48:18  <caitp>duplicated stuff in preparser.cc and parser.cc, yeah, we could do without
16:48:24  * davijoined
16:48:24  * daviquit (Changing host)
16:48:24  * davijoined
16:48:34  <caitp>there's no shortage of worthwhile cleanup for the frontend
16:48:46  * plutoniixquit (Quit: Leaving)
16:50:05  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:55:57  * hferreiroquit (Remote host closed the connection)
16:56:15  * hferreirojoined
17:02:05  * plutoniixjoined
17:37:40  * daviquit (Ping timeout: 264 seconds)
20:55:13  <jwolfe>i noticed that run-tests.py uses stderr very sparingly, and instead prints almost everything to stdout. does anyone know a reason for that? i would have expected progress, errors, or both to be printed to stderr, but only a very few errors are ever printed to stderr. was that an unconscious design decision, or is there a reason for that?
20:55:16  <jwolfe>and can i change it?
20:58:03  * jgijoined
21:03:36  * jgiquit (Quit: jgi)
21:34:43  * Garbeequit (Quit: Connection closed for inactivity)
21:57:55  * unixpicklejoined
22:14:12  <aklein>jwolfe: its design is lost to history, but I suspect things are open. I don't think a lot of people touch it ([email protected] is probably the closest thing it has to a maintainer)
22:15:44  <jwolfe>aklein, is machenbach in this room? sounds like that's the person i should direct my small questions to.
22:17:00  <aklein>jwolfe: only a few v8 folks hang out in here (mostly the SF team, y'all, and jochen). email, or CCing + commenting on issues is your best bet for Michael Achenbach
22:24:21  * plutoniixquit (Read error: Connection reset by peer)
22:51:28  * zvquit (Ping timeout: 264 seconds)
23:07:48  * zvjoined
23:30:59  <jwolfe>i'm starting the Function constructor parsing issue. Did someone say they knew of existing entry points into the parser for parsing parameters and function body separately?
23:32:15  <jwolfe>i don't see anything like that in compiler.h
23:34:35  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:42:02  <aklein>jwolfe: I was just thinking of places where we call the parser on...random stuff
23:42:35  <jwolfe>aklein, any examples you can point me to? i expect i'll be paving a bit of road for myself in this CL, but it'd be nice to see how others do it.
23:42:43  <aklein>https://cs.chromium.org/chromium/src/v8/src/runtime/runtime-internal.cc?rcl=0&l=499
23:43:08  <aklein>that code is used to try to get better output for "undefined is not a function"
23:44:36  * RT|Chatzillajoined
23:56:43  <jwolfe>aklein, thanks. i'll take a look tomorrow.