00:03:55  * zvquit (Quit: WeeChat 1.4)
00:04:17  * zvjoined
00:14:40  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
00:24:23  * ofrobotsjoined
01:31:16  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
02:55:07  * bradleymeckjoined
03:16:29  * saperquit (Ping timeout: 260 seconds)
03:21:03  * saperjoined
03:30:28  * saperquit (Ping timeout: 264 seconds)
03:32:54  * bradleymeckquit (Quit: bradleymeck)
03:33:44  * saperjoined
03:44:04  * bradleymeckjoined
03:47:22  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20gcc%204.8/builds/5590 "V8 Linux gcc 4.8" from 1d6dba43c2b61900be68777297634e05d479a25a: [email protected])
04:05:30  * zvquit (Ping timeout: 244 seconds)
05:10:31  * bradleymeckquit (Quit: bradleymeck)
05:12:59  * xiinotulpchanged nick to plutoniix
05:16:15  * ofrobotsjoined
05:41:02  <trungl-bot>Tree opened by [email protected]: Tree is open
05:47:29  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
08:53:28  * zv_joined
09:48:49  * rendarjoined
10:12:59  * foocraftjoined
10:47:49  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Mjsunit" on http://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/5049 "V8 Mac GC Stress" from 369a6ac01852d3991a556052c4af5beeb6fef92f: [email protected],[email protected])
10:50:18  * davi_joined
10:58:03  * davi_quit (Ping timeout: 240 seconds)
10:58:46  * davi_joined
10:59:33  * davi_quit (Remote host closed the connection)
11:01:55  <trungl-bot>Tree opened by [email protected]: open
11:37:34  * esasquit (Ping timeout: 260 seconds)
12:03:57  <foocraft>Is there any way to tell v8 not to forward "prototype" property requests to a given v8::Object's property handlers?
12:04:46  <foocraft>It seems the requests are going to the named property handlers I'm creating and even when I return an empty handler the prototype seems to be undefined
12:47:58  * xiinotulpjoined
12:50:57  * plutoniixquit (Ping timeout: 244 seconds)
12:55:13  * xiinotulpchanged nick to plutoniix
13:00:14  * bradleymeckjoined
13:45:47  * jugglinmikejoined
14:05:24  * ofrobotsjoined
15:05:16  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:06:23  * stalledquit (Read error: Connection reset by peer)
15:25:02  * ofrobotsjoined
15:27:36  * Venemojoined
15:33:06  * stalledjoined
15:35:02  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:49:19  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:26:04  * bradleymeckquit (Quit: bradleymeck)
16:42:12  * bradleymeckjoined
16:55:14  * foocraftquit (Remote host closed the connection)
17:13:02  * davijoined
17:17:39  * iamstefquit (Ping timeout: 260 seconds)
17:17:39  * sofquit (Ping timeout: 260 seconds)
17:18:00  * sofjoined
17:21:20  * iamstefjoined
17:35:17  * plutoniixquit (Read error: Connection reset by peer)
17:43:19  * ofrobotsjoined
17:59:27  * plutoniixjoined
18:22:34  * bobmcwjoined
18:24:51  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:25:50  * ofrobotsjoined
18:27:01  * ofrobotsquit (Client Quit)
18:30:37  * ofrobotsjoined
18:38:22  * Venemoquit (Ping timeout: 260 seconds)
18:43:58  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/8969 "V8 Win64" from 5ff7901e24c2c6029114567de5a08ed0f1494c81: [email protected])
18:52:15  * bobmcwquit (Remote host closed the connection)
19:12:52  * zv_changed nick to zv
19:12:59  * zvquit (Changing host)
19:12:59  * zvjoined
19:21:15  <trungl-bot>Unknown tree status set by [email protected]: [email protected])
19:22:08  <jugglinmike>That's a new one
19:22:15  <trungl-bot>Tree opened by [email protected]: Open
19:26:50  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:39:23  * evanlucasquit (Quit: Textual IRC Client: www.textualapp.com)
19:41:16  <bradleymeck>maybe I am misreading spec, but is the catch needed for iterator closing? wouldn't a finally still perform the same steps?
19:41:28  * evanlucasjoined
19:46:16  * ofrobotsjoined
19:58:32  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:59:37  * ofrobotsjoined
20:15:47  * rhalffquit (Ping timeout: 260 seconds)
20:23:56  <littledan__>bradleymeck: The spec is extremely specific about various cases where the exception is propagated and .return() is not called
20:24:05  <littledan__>there are extensive tests in test262 for this, and V8 passes them
20:24:42  <bradleymeck>well thats a bit annoying
20:27:32  <bradleymeck>littledan__: do you have the exact reason, I am staring at 7.4.6 / any my mind is just not seeing it
20:27:49  <littledan__>there are tons of parts of the spec for this
20:28:04  <littledan__>overall, it wasn't so bad for us to implement that; the real overhead comes from having a try/catch at all
20:29:22  <bradleymeck>yea, I see it now, it is just a bit strange for throwing in a loop to not close the iterator
20:29:56  <bradleymeck>hells, that makes my use case thrown out the window for now
20:31:47  <littledan__>well, you incur the overhead on all for-of loops, not just for-of loops that use it
20:31:54  <littledan__>or what's your use case?
20:32:04  <littledan__>is it throwing from next()?
20:32:14  <littledan__>the idea is, if next() itself throws, then you can put the try/catch there to call return
20:35:36  <bradleymeck>littledan__: no, the idea is I can create resource management using iterator closing
20:35:49  <littledan__>bradleymeck: what blocks you from doing that?
20:35:58  <littledan__>iterator closing is designed for that
20:36:07  <bradleymeck>littledan__: errors won't close resources in loops
20:36:26  <littledan__>they will, if they come from the iterator user, rather than inside of the iterator itself
20:36:30  <littledan__>do you have a test case?
20:36:48  <bradleymeck>so I still need the junky finally I use in https://github.com/bmeck/managed-task/blob/master/lib/examples/lockfile.js
20:36:58  <bradleymeck>littledan__: I do not for the real syntax, but I can write one
20:37:36  <littledan__>bradleymeck: That would be nice. The iterator close feature was a ton of work and we still may be able to tweak it if it would make it more useful
20:38:54  <bradleymeck>littledan__: https://gist.github.com/bmeck/e78f0fbc486369b05027
20:38:58  <littledan__>if you have a generator, you should be able to simply use try/finally inside the generator and the finally block will always run, as long as the iterator is either exhausted or the for-of loop exits early
20:39:05  <littledan__>yeah, that example should close it
20:39:13  <bradleymeck>now I am even more confused
20:39:21  <littledan__>it's only obscure cases where .return() is not called
20:39:28  <littledan__>they only matter if you implement your own iterator
20:39:30  <bradleymeck>can you point me to an example
20:39:33  <bradleymeck>oh
20:39:38  <bradleymeck>so thats only in the iterator
20:39:47  <littledan__>It doesn't come into play if you use generators, only for custom implementations of the iteration protocol
20:40:05  <littledan__>so it should work! But bug reports are welcome
20:40:12  <bradleymeck>littledan__: ok, so eventually generators may be able to skip the catch{}
20:40:25  <bradleymeck>littledan__: about to break it in for a parser so I had to ask XD
20:40:41  <bradleymeck>thanks much for the work!
20:41:02  <littledan__>well, the catch block will not be reached if an exception is thrown by the loop body, only the finally block
20:41:18  <littledan__>the catch block will only be reached if the generator body throws
20:41:38  <littledan__>it was mostly Georg Neis! I just did a couple little fixes
21:00:50  <aklein>caitp: any reason not to stage exponentiation?
21:03:18  * Venemojoined
21:23:11  * bradleymeckquit (Quit: bradleymeck)
21:24:39  <caitp>aklein: I mean there are no obvious problems with it, and the extra test coverage would be nice
21:25:34  <aklein>caitp: I would be happy to lgtm such a patch :)
21:25:44  <caitp>s/no obvious problems/no obvious (to me) problems/ --- but I've been sick the past few days and my head is a bit foggy
21:28:23  <aklein>k. seems like it wouldn't hurt to get it a bit more coverage
21:29:19  <caitp>alright, well there's a CL at https://codereview.chromium.org/1823683004
21:31:20  * bradleymeckjoined
21:51:26  * rendarquit (Ping timeout: 248 seconds)
21:57:35  * rendarjoined
22:04:37  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:08:27  * ofrobotsjoined
22:23:50  * bradleymeckquit (Quit: bradleymeck)
22:24:34  * plutoniixquit (Quit: จรลี จรลา)
22:32:24  * RT|Chatzillajoined
22:34:24  * daviquit (Ping timeout: 268 seconds)
22:37:17  * rhalffjoined
22:37:52  * jugglinmikequit (Ping timeout: 244 seconds)
22:56:51  * esasjoined
23:50:38  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)