00:00:00  * plutoniixjoined
00:01:19  <caitp>pikajude: yes, you can ask about #v8 in here
00:01:46  <caitp>bradleymeck: do you think you'd be able to help me test out a build of Node with a patched version of ToT v8? it seems pretty daunting to try to do it myself
00:02:00  <caitp>if you can't that's ok
00:02:45  * bradleymeckquit (Ping timeout: 246 seconds)
00:03:05  <pikajude>ok cool
00:03:18  <pikajude>sorry, i know this is going to be a really basic level question, but this is the 4th place i've gone trying to figure it out
00:03:40  <pikajude>i used v8-profiler to profile part of my testsuite for my node app. the test run takes 3300ms and v8-profiler says about 2800 of that is idle
00:03:45  <pikajude>what causes it to be idle
00:09:35  <caitp>pikajude: it looks like it's explained in the Node code at https://github.com/nodejs/node/blob/aac79dfd78a20ac66d99a55f24ddf91f937a2388/src/env.cc#L41-L53 --- when that handle is pinged, Node tells v8 that it's idle
00:09:49  <caitp>the comment makes it look like that's specifically done for some UV apis
00:10:57  <pikajude>i see
00:11:30  <caitp>bnoordhuis is probably the guy to ask, or one of the other Node guys in here
00:11:36  <caitp>dunno if any of them are around though
00:11:42  <pikajude>i can wait
00:14:44  * bradleymeckjoined
00:39:20  * mostynbquit (Quit: Leaving)
00:45:06  <jwolfe>if there are flags available like FLAG_harmony_something, why do the parsers have fields for enabled harmony flags?
00:53:18  * plutoniixquit (Quit: Leaving)
00:54:44  * bradleymeckquit (Read error: Connection reset by peer)
00:54:59  * bradleymeckjoined
02:18:17  * sin8hjoined
02:19:36  * plutoniixjoined
02:46:02  * bradleymeckquit (Read error: Connection reset by peer)
02:48:13  * bradleymeckjoined
03:48:31  * plutoniixquit (Ping timeout: 240 seconds)
03:51:03  * plutoniixjoined
05:04:10  * maltopic: see #chromium, http://code.google.com/p/v8/
05:04:49  * maltopic: see #chromium, http://code.google.com/p/v8/
05:05:48  * maltopic: see #chromium, http://code.google.com/p/v8/
05:06:25  * maltopic: see #chromium, http://code.google.com/p/v8/
05:08:55  * plutoniixquit (Quit: จรลี จรลา)
05:15:30  * bradleymeck_joined
05:15:38  * bradleymeckquit (Read error: Connection reset by peer)
05:15:38  * bradleymeck_changed nick to bradleymeck
05:18:07  * bradleymeckquit (Read error: Connection reset by peer)
06:24:44  * plutoniixjoined
06:24:47  * plutoniixquit (Max SendQ exceeded)
06:25:16  * plutoniixjoined
06:26:25  * plutoniixquit (Max SendQ exceeded)
06:26:54  * plutoniixjoined
06:27:55  * plutoniixquit (Max SendQ exceeded)
06:28:24  * plutoniixjoined
06:29:25  * plutoniixquit (Max SendQ exceeded)
06:29:54  * plutoniixjoined
06:30:55  * plutoniixquit (Max SendQ exceeded)
06:31:20  * plutoniixjoined
06:32:22  * plutoniixquit (Max SendQ exceeded)
06:32:52  * plutoniixjoined
06:33:54  * plutoniixquit (Max SendQ exceeded)
06:49:17  <trungl-bot>Tree opened by machenbach@chromium.org: open
07:22:26  * sin8hquit (Quit: Leaving.)
07:57:34  * sin8hjoined
08:24:18  * plutoniixjoined
08:52:12  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/9663 "V8 Linux - arm64 - sim - MSAN" from 73df92fc2fdbbfadc17e8ab4e58ec56ae2b3d91a: gdeepti@chromium.org)
09:03:16  <trungl-bot>Tree opened by machenbach@chromium.org: open
09:24:27  * plutoniixquit (Read error: Connection reset by peer)
09:35:33  * plutoniixjoined
10:44:45  * sin8hquit (Quit: Leaving.)
10:45:01  * sin8hjoined
11:15:05  * sin8hquit (Quit: Leaving.)
11:15:56  * aperezdcquit (Remote host closed the connection)
11:21:42  * sin8hjoined
11:21:54  * sin8hquit (Client Quit)
11:30:56  * thefourtheyequit (Quit: Connection closed for inactivity)
11:58:28  * plutoniixquit (Read error: Connection reset by peer)
12:04:10  * Garbeejoined
12:11:54  * sin8hjoined
12:12:50  * sin8hquit (Client Quit)
12:19:27  * bobmcwjoined
13:52:29  * sin8hjoined
14:02:07  * sin8hquit (Quit: Leaving.)
14:14:40  * Garbeequit (Quit: Connection closed for inactivity)
15:23:35  * plutoniixjoined
16:30:14  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
16:58:03  * unixpicklejoined
17:04:06  * seventhjoined
17:12:59  * bradleymeckjoined
17:18:11  * bradleymeckquit (Quit: bradleymeck)
17:21:12  * unixpicklequit (Ping timeout: 260 seconds)
17:26:15  * hferreirojoined
17:34:51  <pikajude>hey, anyone had a chance to look at my question from yesterday
17:52:36  * jwolfequit (Ping timeout: 276 seconds)
18:05:40  * jwolfejoined
18:07:35  * Garbeejoined
18:48:22  * hferreiroquit (Ping timeout: 272 seconds)
19:19:46  * bradleymeckjoined
19:33:47  <jwolfe>i'm guessing the reason that parser objects have fields like allow_harmony_for_in_ (which seem to be redundant with the global variable FLAG_harmony_for_in) is so that different compilation units can have differently configured harmony settings? if that's the case, then only harmony features that can be scoped to a compilation unit need to follow this pattern. is this correct?
19:52:18  * bradleymeckquit (Read error: Connection reset by peer)
19:54:54  * bradleymeckjoined
19:58:24  * seventhquit (Remote host closed the connection)
20:27:34  * bobmcwquit (Remote host closed the connection)
20:46:50  <aklein>jwolfe: my memory of why the parser does that is for threading reasons, actually
20:47:11  <aklein>the parser can run off the main thread
20:48:33  <jwolfe>are you implying that the values of FLAG_harmony_* change well after startup? like they can be turned on and off at runtime?
20:57:18  <aklein>jwolfe: not in practice, but in tests they are sometimes.
20:57:36  <aklein>let me see what I can unearth
20:58:01  * bobmcwjoined
20:59:25  <aklein>huh, maybe the threading thing was made up. the use of allow_* everywhere seems to have begun at https://codereview.chromium.org/13450007
21:01:21  * pikajudepart ("WeeChat 1.5")
21:03:27  <aklein>looks like it was done mostly for consistency
21:03:36  * bobmcwquit (Remote host closed the connection)
21:07:18  <jwolfe>aklein, but if we've got a global variable, why would we want a field? duplicating that information doesn't seem like it's good for anyone. i could argue that it's more "consistent" for all the v8 code to use the same global variable rather than all the parser configuration to be parser fields.
21:07:20  <jwolfe>anyway. the point at hand is what do i do in the code i'm writing right now. i'd like to ignore whole idea of parser fields for harmony flags and just use the global variables. is that ok?
21:09:15  <aklein>jwolfe: which is this for?
21:09:24  <aklein>function toString?
21:09:41  <jwolfe>aklein, yes
21:10:22  <aklein>I assume that has to touch stuff outside the parser
21:11:34  <jwolfe>aklein, yes.
21:12:12  <jwolfe>aklein, there might be a way to do it just in the parser, but probably not without adding fields to runtime objects. i think it's probably going to be easier to do it with logic outside the parser
21:13:42  <aklein>I suspect that it'll be OK to not use an allow_* field in the parser for this; you can certainly start out that way
21:13:59  <aklein>it would be good to get some _real_ consistency around that, though
21:14:05  <aklein>(outside the context of your CL)
21:16:12  <jwolfe>aklein, are you thinking of removing all the allow_* fields and changing the parser to just use the global FLAG_* fields?
21:16:29  <aklein>jwolfe: that would be one way to achieve consistency, yes
21:16:44  <jwolfe>aklein, ok thanks. i'll use FLAG_* for my CL.
21:28:40  * bradleymeckquit (Read error: Connection reset by peer)
22:00:28  * bradleymeckjoined
22:04:44  * bradleymeckquit (Ping timeout: 244 seconds)
22:58:45  * RT|Chatzillajoined