00:07:32  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
00:09:16  * xaxxonjoined
00:26:52  * jugglinmikequit (Quit: Leaving.)
00:27:38  * jugglinmikejoined
00:30:25  * bnoordhuisjoined
00:35:03  * bnoordhuisquit (Ping timeout: 240 seconds)
00:45:58  * evanluca_joined
00:47:57  * evanlucasquit (Ping timeout: 276 seconds)
00:49:28  * plutoniixjoined
00:51:46  <xaxxon>ok, so what I "know" now is that the function is taking the global object with it, even when I say js_function->Call(different_context...) it still looks up variables in its original context.. what's the point of even passing in a context to Call() then?
01:10:36  * jugglinmikequit (Quit: Leaving.)
01:10:41  * jugglinmike1joined
01:19:43  * jugglinmike1quit (Ping timeout: 252 seconds)
01:21:28  * ofrobotsjoined
01:30:37  * petka____quit (Quit: Connection closed for inactivity)
01:39:36  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
01:41:58  * ofrobotsjoined
01:43:22  * ofrobotsquit (Client Quit)
01:46:02  * ofrobotsjoined
01:49:45  * ofrobotsquit (Client Quit)
01:54:50  * zvquit (Quit: WeeChat 1.4)
01:55:38  * zvjoined
02:01:23  * evanluca_quit (Read error: Connection reset by peer)
02:04:07  * evanlucasjoined
02:11:19  * etnbrdjoined
03:59:49  * evanlucasquit (Read error: Connection reset by peer)
04:00:26  * evanlucasjoined
05:15:43  * evanlucasquit (Read error: Connection reset by peer)
05:16:21  * evanlucasjoined
05:29:20  * evanlucasquit (Read error: Connection reset by peer)
05:30:01  * evanlucasjoined
06:31:22  * evanluca_joined
06:31:31  * evanlucasquit (Read error: Connection reset by peer)
07:23:49  * evanlucasjoined
07:23:56  * evanluca_quit (Read error: Connection reset by peer)
07:43:57  * evanluca_joined
07:44:04  * evanlucasquit (Read error: Connection reset by peer)
07:48:50  * evanluca_quit (Read error: Connection reset by peer)
07:49:54  * evanlucasjoined
08:37:27  <jochen__>if eg an exception is thrown before the function is even called, it'll be created in different_context
08:37:27  * xaxxonquit (Read error: Connection reset by peer)
08:37:56  <jochen__>now I scared him off...
08:44:07  * petka____joined
08:55:05  * evanlucasquit (Read error: Connection reset by peer)
08:55:24  * evanlucasjoined
10:23:42  * davijoined
10:24:19  * plutoniixquit (Quit: จรลี จรลา)
10:41:04  * daviquit (Ping timeout: 240 seconds)
10:44:29  * bnoordhuisjoined
10:55:10  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Mjsunit" on http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/builds/5843 "V8 Linux - arm64 - sim - gc stress" from a8d5d176598c131bb16b0c9767facf7d768c2d68: [email protected],[email protected],[email protected])
10:59:11  <trungl-bot>Tree opened by [email protected]: open
11:02:12  <trungl-bot>Tree opened by [email protected]: open (test on arm64 to be blacklisted)
11:05:09  * esasquit (Read error: Connection reset by peer)
11:12:16  <trungl-bot>Tree opened by [email protected]: open (test on arm64 gc stress to be blacklisted)
11:40:11  * rendarjoined
11:41:25  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check" on http://build.chromium.org/p/client.v8/builders/V8%20Mac/builds/6407 "V8 Mac" from ee8108b71c7e63392ba9814d859aa06f47acf5e5: [email protected],[email protected],[email protected])
11:52:29  <trungl-bot>Tree opened by [email protected]: open
12:19:55  * evanlucasquit (Read error: Connection reset by peer)
12:20:14  * evanlucasjoined
12:37:45  <trungl-bot>Tree closed by [email protected]: closed (maintenance)
12:45:55  * bnoordhuisquit (Ping timeout: 248 seconds)
12:48:03  * mostynbjoined
12:53:51  <trungl-bot>Tree opened by [email protected]: open
13:17:00  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN%20arm64%20-%20debug%20builder/builds/4829 "V8 Linux64 ASAN arm64 - debug builder" from a6f41f7b8226555c5900440f6e3092b3545ee0f6: [email protected])
13:22:01  <trungl-bot>Tree opened by [email protected]: open - ASAN arm64 has issues after switching to trusty
13:41:08  <trungl-bot>Tree opened by [email protected]: open
13:47:15  * evanlucasquit (Read error: Connection reset by peer)
13:47:34  * evanlucasjoined
13:51:49  * bnoordhuisjoined
13:56:22  * bnoordhuisquit (Ping timeout: 255 seconds)
14:16:24  * mounibecjoined
14:27:38  * jugglinmikejoined
15:15:06  <jugglinmike>aklein: Thanks for the review! I'm going to start by adding the requested module flag to the Parser class. Let me know if you think it belongs on ParserTraits (or somewhere else) instead
15:18:39  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:19:59  * plutoniixjoined
15:29:59  * mounibecjoined
15:34:54  <jugglinmike>Looks like it might belong in ParserBase instead
15:38:51  * bnoordhuisjoined
15:50:08  * mostynbquit (Quit: Leaving)
15:58:04  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:59:04  * mounibecjoined
16:04:33  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
16:05:56  * C-Manjoined
16:21:43  * bnoordhuisquit (Ping timeout: 255 seconds)
16:29:02  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:30:34  * davijoined
16:34:51  * mounibecjoined
16:48:29  * bnoordhuisjoined
17:01:21  * ofrobotsjoined
17:03:12  <aklein>jugglinmike: yeah, ParserBase is probably what I meant
17:03:24  <jugglinmike>great :)
17:13:44  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:21:19  * ofrobotsjoined
17:24:02  * mounibecquit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:34:56  * jugglinmikequit (Quit: Leaving.)
17:35:12  * jugglinmikejoined
17:39:11  * bradleymeckjoined
17:46:37  <bradleymeck>caitp: I looked at the code for why cyclical promises are blowing up chrome stable and node LTS, but can't figure out what caused it, the places in promise.js that I would expect to be causing the infinite microtask/memleak have 0 diff, so idk
17:52:21  <bradleymeck>a fun fact is that it doesn't blow up until a .then / .catch is registered
18:44:32  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:49:28  * ofrobotsjoined
19:09:57  * daviquit (Ping timeout: 244 seconds)
19:20:53  <caitp>bradleymeck: I lost the repro you showed me before (client history doesn't go back far enough)
19:21:22  <bradleymeck>caitp: https://jsfiddle.net/r3fot0fd/1/ (remove /1/ to bring the bomb)
19:21:44  <bradleymeck>basically once you make a cycle, and then cause a .then/.catch it blows up
19:22:04  <bradleymeck>newest v8 doesn't do this, but reading through the code it doesn't look like it detects cycles either
19:23:25  <bradleymeck>ES6 doesn't require TypeError for cycles except self cycling, but A+ did, trying to discuss in more depth, spec says you should infinite loop in the Promise Jobs queue
19:23:55  <bradleymeck>will probably get back later and make a ticket once the actual desired effect is determined
19:26:05  <bradleymeck>if it helps userland libs also bomb, so once a native Promise interacts with a userland Promise you can still have this effect
19:31:16  <caitp>the current lts branch is "v4.4.0-proposal", right?
19:34:37  <bradleymeck>yea
19:43:46  * bradleymeckquit (Quit: bradleymeck)
19:45:16  * bradleymeckjoined
19:54:47  <caitp>bradleymeck: anyways, there are at least a lot of promise-specific fixes that are missing --- I think my promise resolution refactoring is a good starting point (from back in november), but it's probably not the only relevant fix
19:55:59  <caitp>you might want to look the history of src/js/promise.js to look at things that are cherrypickable
19:56:06  <bradleymeck>yea, tried a simple copy pasta, and it didn't work which is about the amount of time I will have for looking at it in the next few weeks.
19:56:21  <bradleymeck>caitp: mksnapshot failed on the copied promise.js missing natives
19:59:53  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:00:19  * ofrobotsjoined
20:33:59  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
20:34:54  * bradleymeck_joined
20:35:58  * bradleymeckquit (Ping timeout: 255 seconds)
20:35:58  * bradleymeck_changed nick to bradleymeck
20:41:37  * xaxxonjoined
20:41:40  * ofrobotsjoined
20:43:09  <xaxxon>still looking for any help associated with moving a function between contexts within an isolate. Specifically around the global object present when running the function being the global object of the context the function was created in, not the one of the context it's running in
20:51:29  * bradleymeckquit (Ping timeout: 240 seconds)
20:51:40  * bradleymeckjoined
21:03:48  <aklein>xaxxon: that's just how functions work in JavaScript
21:04:06  <aklein>same as if you pull a function out of a same-origin <iframe>
21:05:00  <xaxxon>aklein do you know exactly when it grabs it? is it during compilation?
21:05:45  <xaxxon>I think my tests are saying that is when it is bound
21:05:52  <aklein>xaxxon: yes. A Function is basically a chunk of code plus a Context chain (which includes the global context)
21:06:12  <aklein>ah, right
21:06:17  <aklein>so "compilation" has a few stages
21:06:31  <aklein>but there's no way to have a v8::Function that isn't associated with a particular v8::Context
21:06:50  <bradleymeck>aklein: if you get some time I would like to bend your ear about ES6 modules, we are doing a NodeUp around them Friday
21:07:05  <aklein>bradleymeck: sure
21:07:32  <xaxxon>aklein I simply mean is the global object associated with the function when I call Script::Compile ?
21:07:58  <aklein>xaxxon: yes. if you want to pass it around and use it elsewhere, use CompileUnbound()
21:08:07  <aklein>er, CompileUnboundSCript?
21:08:19  <xaxxon>oh, I didn't know about that. I can find it I'm sure :) THank you so much
21:08:37  <bradleymeck>aklein: hangouts/skype/or other work? (idk your info on anything, so pm that maybe?)
21:20:10  * bradleymeckquit (Ping timeout: 244 seconds)
21:30:23  * watildejoined
21:33:28  <bnoordhuis>xaxxon: the approach we use in node is to put a proxy object between the script and the global object
21:33:47  <bnoordhuis>that way you can (if you wanted to) replace the global object on the fly with another one
21:34:04  <bnoordhuis>the source is in src/node_contextify.cc if you're interested
21:34:16  <xaxxon>bnoordhuis is that used to "protect" against required modules messing with the global object during require()?
21:34:22  <xaxxon>that's basically what I was trying to do
21:34:46  <bnoordhuis>well, we make a point in the documentation that the vm module is not for secure sandboxing
21:35:04  <xaxxon>I see
21:35:33  <xaxxon>I'll take a look at proxy objects. I've heard about them but never looked at what they do. Thank you.
21:35:38  <bnoordhuis>np
21:36:41  * bradleymeckjoined
21:37:36  * esasjoined
21:41:03  <xaxxon>given what everyone has just said, why does v8::Script::Run() take a context object? Can someone give me an example of what else the context is used for other than providing the global object?
21:59:44  * xaxxonquit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:30:39  * RT|Chatzillajoined
22:41:14  <jugglinmike>aklein: This check for the PreParser--should I make a standalone test case for it? Or extend the existing tests to also run with that flag set?
22:41:55  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Mac/builds/3592 "V8-Blink Mac" from 546ea6b8393a894f07597ade5ec1c7db02c1e425: [email protected])
22:46:25  * bradleymeckquit (Read error: Connection reset by peer)
22:47:48  <jugglinmike>hmm, might be that I need a special test for this, given that it's specific to lazily-parsed function bodies (which none of the existing tests describe)
22:47:55  <jugglinmike>I'll find out soon enough. Compiling
22:49:37  <aklein>jugglinmike: I think you want a standalone case, see my second email
22:49:58  <trungl-bot>Tree opened by [email protected] (:aklein): Tree is open
22:53:13  <jugglinmike>aklein: I think I've got something wrong. As I wrote it, the test passes without any change to the patch https://gist.github.com/jugglinmike/b595db3ece6103bdbe08
22:53:36  * bradleymeck_joined
22:53:52  * bradleymeckjoined
22:55:56  <aklein>jugglinmike: it's possibly we just never do lazy parsing inside a module at the moment?
22:56:27  <aklein>some printf debugging (or gdb debugging) could tell you that
22:56:33  <aklein>so it's possible this doesn't matter at the moment
22:57:15  <jugglinmike>Is DCHECK still around when preparsing occurs?
22:57:59  <jugglinmike>Or will implementing this involve more than that assertion statement?
22:59:39  <aklein>sorry, what do you mean exactly?
22:59:50  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:00:09  <aklein>which assertion would you add? DCHECK(!parsing_module_) inside SkipLazyFunctionBody?
23:01:38  <jugglinmike>I'm thinking of the assertion I had to modify in PreParser::ParseExpressionOrLabelledStatement
23:01:59  <jugglinmike>DCHECK(!expr.AsIdentifier().IsFutureReserved());
23:02:05  <jugglinmike>to be replaced with
23:02:31  * ofrobotsjoined
23:02:48  <caitp>bradleymeck: yeah, there have been a lot of changes, but most of them shouldn't really matter --- it should be possible to backport the collection of promise fixes. if I get some time next week I could probably put together a patch for it
23:02:49  <jugglinmike>DCHECK(!expr.AsIdentifier().IsEnum()); and DCHECK(!parsing_module_ || !expr.AsIdentifier().IsAwait());
23:07:53  <aklein>jugglinmike: that will work anyway as long as parsing_module_ defaults to false anyway
23:16:34  * bradleymeck_quit (Read error: Connection reset by peer)
23:16:51  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:21:49  * ofrobotsjoined
23:23:25  * ofrobotsquit (Client Quit)
23:24:19  * watildequit (Remote host closed the connection)
23:27:39  * bradleymeck_joined
23:28:33  <jugglinmike>aklein: maybe I need something like this? https://github.com/v8/v8/blob/24e85029caf443a980cd46e286a4ab1333d8522e/test/cctest/test-parsing.cc#L239-L248
23:28:55  <jugglinmike>...or https://github.com/v8/v8/blob/24e85029caf443a980cd46e286a4ab1333d8522e/test/cctest/test-parsing.cc#L334
23:29:28  <aklein>jugglinmike: neither of those two
23:29:30  <jugglinmike>but there's also this https://github.com/v8/v8/blob/24e85029caf443a980cd46e286a4ab1333d8522e/test/cctest/test-parsing.cc#L1122
23:29:51  <jugglinmike>heh, I'm grasping at straws here
23:30:01  <aklein>jugglinmike: the last one set to true is what you should need
23:30:09  <aklein>but as I said it may be that it's getting disabled inside the parser
23:30:14  <aklein>I haven't had a chance to check
23:30:29  <aklein>which is why I suggested printf (or gdb) debugging to see if you're even going down the preparser path
23:30:52  <aklein>basically the Parser chugs along until it sees a function, and then decides whether it should keep parsing or skip over it using the preparser
23:33:11  <aklein>and it uses various bits of state and input to make that decision
23:33:36  <jugglinmike>Got it. Digging in with printf now
23:33:42  <aklein>cool
23:34:03  <aklein>sorry if I didn't explain it well, it's a little wonky. especially since test-parsing.cc uses a different entry-point for the preparser
23:34:30  * ofrobotsjoined
23:34:58  * bnoordhuisquit (Ping timeout: 244 seconds)
23:35:44  <jugglinmike>It's alright! I think I'm just trying to do too much all at once
23:37:52  * xaxxonjoined
23:39:12  * rendar_joined
23:39:44  * ofrobotsquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:42:16  * rendarquit (Ping timeout: 255 seconds)
23:42:45  <jugglinmike>aklein: It looks like something is intercepting standard out from the cctest suite. Does that sound right to you?
23:43:22  <aklein>jugglinmike: run-tests.py is, yes
23:43:26  <aklein>you can run it manually
23:43:27  <jugglinmike>(my printf statements aren't coming through when I run the tests, though they're visible from d8)
23:44:16  <jugglinmike>got it. I'll look into run-tests.py to learn more
23:45:13  <aklein>out/path/to/cctest test-parsing/MyTestName
23:48:14  <jugglinmike>bingo
23:51:34  * ofrobotsjoined
23:53:10  * ofrobotsquit (Client Quit)
23:54:18  * ofrobotsjoined
23:58:52  <jugglinmike>close, but still not quite sure what is going wrong
23:59:08  <jugglinmike>I'll pick it up in the morning. Thanks again, aklein