00:15:03  * bradleymeckquit (Quit: bradleymeck)
00:28:45  * plutoniixjoined
00:29:22  * plutoniixquit (Max SendQ exceeded)
00:30:05  * plutoniixjoined
00:31:10  * plutoniixquit (Max SendQ exceeded)
00:31:35  * plutoniixjoined
00:32:41  * plutoniixquit (Max SendQ exceeded)
00:33:07  * plutoniixjoined
00:34:13  * plutoniixquit (Max SendQ exceeded)
00:34:38  * plutoniixjoined
00:35:45  * plutoniixquit (Max SendQ exceeded)
00:36:09  * plutoniixjoined
00:37:10  * plutoniixquit (Max SendQ exceeded)
00:37:39  * plutoniixjoined
00:51:15  * Guest59quit (Quit: Textual IRC Client: www.textualapp.com)
00:57:10  * Guest59joined
01:07:29  * bradleymeckjoined
01:08:54  * Guest59_joined
01:11:42  * Guest59quit (Ping timeout: 240 seconds)
01:55:03  * Cube8quit (Quit: Leaving)
02:48:10  * joyeejoined
02:53:00  * joyeequit (Ping timeout: 260 seconds)
03:56:55  * bradleymeckquit (Quit: bradleymeck)
05:37:47  * joyeejoined
05:42:08  * joyeequit (Ping timeout: 256 seconds)
06:03:15  * Guest59_quit (Quit: My Mac has gone to sleep. ZZZzzz…)
07:16:07  * plutoniixquit (Ping timeout: 240 seconds)
07:28:34  * plutoniixjoined
08:01:35  * joyeejoined
08:21:12  * joyeequit (Read error: Connection reset by peer)
08:21:36  * joyeejoined
08:42:46  * joyeequit (Read error: Connection reset by peer)
08:45:17  * joyeejoined
09:06:10  * joyeequit (Read error: Connection reset by peer)
09:13:16  * joyeejoined
09:33:49  * joyee_joined
09:37:41  * joyeequit (Ping timeout: 240 seconds)
09:54:59  * joyeejoined
09:57:39  * joyee__joined
09:57:39  * joyeequit (Read error: Connection reset by peer)
09:58:35  * joyee_quit (Ping timeout: 264 seconds)
10:05:45  * plutoniixquit (Quit: Leaving)
10:18:31  * joyee__quit (Read error: Connection reset by peer)
10:19:58  * joyeejoined
10:40:40  * joyeequit (Read error: Connection reset by peer)
10:41:41  * joyeejoined
11:02:29  * joyeequit (Read error: Connection reset by peer)
11:04:25  * joyeejoined
11:13:07  * saurikquit (Ping timeout: 248 seconds)
11:25:10  * joyeequit (Read error: Connection reset by peer)
11:25:58  * joyeejoined
11:54:58  * joyeequit (Read error: Connection reset by peer)
11:55:24  * joyeejoined
12:15:54  * joyeequit (Read error: Connection reset by peer)
12:15:54  * joyee_joined
12:29:51  * saurikjoined
12:35:50  * joyee_quit (Read error: Connection reset by peer)
12:36:22  * joyeejoined
13:29:11  * bedehojoined
13:31:07  * plutoniixjoined
14:05:40  * bradleymeckjoined
14:47:17  * wadeyquit (Ping timeout: 256 seconds)
14:51:52  * wadeyjoined
15:03:57  * joyeequit (Read error: Connection reset by peer)
15:04:30  * joyeejoined
15:24:52  * joyee_joined
15:24:53  * joyeequit (Read error: Connection reset by peer)
15:41:29  <bedeho>hey, is this an appropriate place to ask about how to work with the v8 library?
15:42:42  * bradleymeckquit (Quit: bradleymeck)
15:47:49  * joyee_quit (Read error: Connection reset by peer)
15:47:51  * joyeejoined
15:54:11  * bradleymeckjoined
16:19:38  * joyeequit (Read error: Connection reset by peer)
16:19:51  * joyeejoined
16:41:02  * joyeequit (Read error: Connection reset by peer)
17:02:00  * joyeejoined
17:03:36  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
17:25:15  <paulfryzel>bedeho, you can certainly try :) For longer usage-specific questions, v8-users is probably a better option (https://groups.google.com/forum/#!forum/v8-users).
17:33:20  * joyee_joined
17:33:33  * joyeequit (Read error: Connection reset by peer)
17:54:43  * joyeejoined
17:57:41  * joyee_quit (Ping timeout: 240 seconds)
18:15:35  * joyeequit (Read error: Connection reset by peer)
18:16:41  * seventhjoined
18:18:14  * joyeejoined
18:30:48  * rwlbuis_joined
18:31:56  * Guest59joined
18:52:00  * seventhquit (Quit: ...)
18:55:33  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:01:14  * joyeequit (Read error: Connection reset by peer)
19:01:43  * joyeejoined
19:11:04  * xiinotulpjoined
19:14:21  * plutoniixquit (Ping timeout: 252 seconds)
19:22:34  * joyeequit (Read error: Connection reset by peer)
19:23:39  * joyeejoined
19:34:20  * joyeequit (Read error: Connection reset by peer)
19:34:28  * joyeejoined
19:42:31  * Guest59joined
19:51:02  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:54:50  <trungl-bot>Tree closed by machenbach@chromium.org: closed - purple
19:54:59  * joyeequit (Read error: Connection reset by peer)
19:55:04  * joyee_joined
19:56:59  * Guest59joined
20:03:54  <trungl-bot>Tree closed by machenbach@chromium.org: closed - http://crbug.com/687279
20:13:48  * bradleymeckquit (Quit: bradleymeck)
20:14:17  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:14:57  * joyee_quit (Read error: Connection reset by peer)
20:15:22  * joyeejoined
20:16:14  * Guest59joined
20:22:03  <trungl-bot>Tree opened by machenbach@chromium.org: open
20:35:31  * s1wquit (Quit: ZNC 1.7.x-git-195-a314d30 - http://znc.in)
20:42:39  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:45:06  * Guest59joined
20:51:01  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:21:06  <jwolfe>can someone help me interpret the dry run results here: https://codereview.chromium.org/2638513002/ ?
21:38:01  * joyeequit (Read error: Connection reset by peer)
21:39:01  * joyeejoined
21:44:07  <jochen__>jwolfe: what exactly?
21:45:33  <jochen__>jwolfe: do you mean the purple bots? that'd be https://bugs.chromium.org/p/chromium/issues/detail?id=687279
21:56:44  <jwolfe>jochen__, thanks, but actually not allowed to view that page. ... hm.
21:57:08  <jwolfe>i'm also wondering if the blink failures really have anything to do with my code.
21:57:31  <jwolfe>i'm guessing the purple bots are not my fault?
21:58:17  <jochen__>yes
22:00:28  * AKPWDquit (Ping timeout: 255 seconds)
22:00:29  * Guest59joined
22:00:38  * AKPWDjoined
22:02:39  <jwolfe>i also have no idea how to diagnose the blink failure. it looks like something to do with xss security, which seems pretty unrelated to trailing commas. When i look at the log https://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/builds/4379/steps/webkit_tests%20%28with%20patch%29/logs/stdio i'm completely lost. I don't know how to find anything useful in there.
22:13:52  * xiinotulpquit (Remote host closed the connection)
22:15:22  <aklein>jwolfe: on this page: https://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/builds/4379/
22:15:35  <aklein>jwolfe: search for "layout_test_results"
22:15:58  <aklein>jwolfe: that will get you to https://storage.googleapis.com/chromium-layout-test-archives/linux_trusty_blink_rel/4379/layout-test-results/results.html
22:16:23  <aklein>and then "pretty diff" is my recommendation for further diagnoses
22:16:28  <aklein>fwiw this looks like a flake to me
22:16:42  <jwolfe>aklein, i'm following along, but it looks like i'm looking at a pass, not a failure. the link was green.
22:16:57  <aklein>jwolfe: it's right below a failure, right?
22:17:04  <aklein>the green is saying "this step succeeded"
22:17:05  <caitp>the "upload test results" step is green, not the actual test run
22:17:42  <jwolfe>aklein, 33 right below 32
22:17:59  <aklein>jwolfe: yup
22:18:04  <aklein>that layout_test_result link
22:18:45  <aklein>it corresponds to the "webkit_tests (with patch)" step
22:19:04  <jwolfe>wow. that's pretty confusing. ok, so i'm supposed to look for associated results in a passing step to learn more about a failing step that came before it.
22:19:57  <jwolfe>aren't flukes supposed to be mitigated by running all the tests up to 4 times until they pass?
22:20:18  <aklein>jwolfe: yeah, that usually works. looks like it just didn't in this case (you can see at the bottom that we tried to retry)
22:20:49  <aklein>I can't argue that the UI is intuitive, but I can tell you that following the above steps are definitely the way to diagnose a blink layout test bot failure
22:20:57  <aklein>(without having to run locally)
22:21:11  <caitp>not everything is deterministic in webkit/blink tests, so even with multiple tries, flakes and timeouts still happen
22:21:35  <jwolfe>is there any attempt to make the results more reliable instead of just rerolling the unreliable ones?
22:21:36  <caitp>well, in tests in general
22:21:56  <aklein>jwolfe: yes
22:22:06  <jwolfe>like why did those errors get printed in a different order? is that ok? if so, then make that a pass. if not, then fix the test.
22:22:16  <aklein>jwolfe: lots of work. it's a hard problem with 50,000+ integration tests
22:22:35  <aklein>jwolfe: the architecture of the layout test runner is that it's just doing a text diff
22:22:47  <aklein>so the out-of-order-ness is, as far as the runner can tell, a test failure
22:22:59  <aklein>it doesn't know those are individual assertions or anything
22:24:21  <jwolfe>aklein, right, but there could be a way to make tests so that you can specify if the order matters. that would be a significant feature for a test runner, but that's just one idea for how to make things more reliable. it sounds like people who know more than i are already thinking of that kind of thing though.
22:25:31  <aklein>jwolfe: yeah, in short, people have been fighting with these tests for years. I can tell you that they're at least less flaky than they used to be
22:25:43  <caitp>I think there have been some efforts to do bits of that in the past year, I vaguely recall some mail about it
22:26:01  <aklein>the most recent thing was to randomize the order tests run in
22:26:11  <aklein>which helped shake out implicit dependencies between tests
22:26:29  <aklein>(also makes it easier to run them faster on our test architecture using swarming)
22:27:10  <aklein>caitp: does your doc for async iterators/generators map to the plan you currently have for async generators-in-BytecodeGenerator?
22:27:52  <caitp>can't recall
22:29:36  <caitp>I know it talks about distinguishing yield types, which I did in BytecodeGenerator, but doesn't cover the actual implementation detail
22:36:00  <aklein>caitp: it seems like each person who looks at your async functions -> BytecodeGenerator patch starts not understanding where this is going. like yesterday when I wasn't clear why the fix for async functions in the parser wouldn't fit with your plan for async generators. if you could sketch out the plan in the doc I think it'd help folks
22:38:25  <caitp>It's not clear what's hard to follow about it, it follows a precedent that's already there, it's imperative and thus easier to understand, more concise than a bunch of AST nodes, it avoids adding things to the AST which requires touching stuff all over the codebase to add new AST visitors, it's been shown to work better in other impls (eg WebKit), and it arguably generates objectively better bytecode
22:38:45  <caitp>to me, that's a great sales pitch
22:39:38  <caitp>so, given all that, it's not clear where the disconnect is
22:41:11  <aklein>caitp: well rmcilroy just asked me about the patch, and it sounded like he wasn't necessarily comfortable with the overall approach of the async function patch
22:41:29  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:41:29  <aklein>in that some of the logic moving into the BytecodeGenerator wasn't of the sort that we'd had there before
22:42:24  <aklein>caitp: but I kind of feel like I'm playing telephone; I've asked rmcilroy if he can pop in here
22:44:13  <aklein>caitp: seems like today's not going to work, too busy with blinkon
22:44:25  <aklein>but he says he will followup by email
22:44:34  * s1341quit (Quit: Connection closed for inactivity)
22:45:05  <caitp>I'm not trying to make you act as a telephone, I've already answered his criticism on the patch itself in a comment, and I think it makes a lot of sense
22:52:28  <aklein>caitp: just saying I think some more detailed discussion is likely necessary; I'll let rmcilroy respond to your email. I'm not complaining about playing telephone, just raising that I think there's a disconnect here that could use more communication
22:56:44  * RT|Chatzillajoined
22:59:08  * bradleymeckjoined
23:07:02  * Guest59joined
23:39:57  * Guest59quit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:47:11  * Guest59joined