02:56:58  * unixpicklejoined
03:10:38  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
04:16:56  * xaxxonjoined
04:42:43  * italoacasasquit (Quit: Connection closed for inactivity)
05:30:27  * Tweth-V-PDSquit (Ping timeout: 255 seconds)
05:30:55  * Tweth-U-PDSjoined
05:32:11  * Ultrasaucequit (Ping timeout: 240 seconds)
05:33:43  * Ultrasaucejoined
05:48:18  * Tweth-V-PDSjoined
05:50:42  * Tweth-U-PDSquit (Ping timeout: 255 seconds)
06:05:14  * plutoniixjoined
06:05:44  * plutoniixquit (Max SendQ exceeded)
06:06:22  * plutoniixjoined
06:07:24  * plutoniixquit (Max SendQ exceeded)
06:07:50  * plutoniixjoined
06:29:47  * Vbitzquit (K-Lined)
06:31:20  * Vbitzjoined
06:42:08  <trungl-bot>Tree closed by machenbach@chromium.org: closed - reverting
06:56:26  * jbrianceau_awayjoined
06:56:34  * jbrianceau_awaychanged nick to jbrianceau
07:11:20  <trungl-bot>Tree opened by machenbach@chromium.org: open
08:26:13  * battousaiquit (Ping timeout: 240 seconds)
08:30:43  * battousaijoined
09:17:08  * xaxxonquit (Quit: Leaving)
10:25:11  * mylesborinsquit (Quit: farewell for now)
10:25:41  * mylesborinsjoined
11:03:21  * plutoniixquit (Quit: Leaving)
11:47:59  * Cube8joined
11:59:03  <trungl-bot>Tree closed by buildbot@chromium.org: closed (/builders/V8%20Linux%20-%20noi18n%20-%20debug/builds/13314 from 1f3a863bbdb972f3314c9424ff6939152d4dd9ac)
12:10:07  <trungl-bot>Tree opened by machenbach@chromium.org: open
12:23:33  * battousaiquit (Ping timeout: 240 seconds)
12:25:58  * battousaijoined
12:33:50  * jbrianceaupart
12:47:14  * Cube8quit (Ping timeout: 260 seconds)
13:02:35  * Cube8joined
13:30:48  * seventhjoined
14:00:01  * plutoniixjoined
14:00:25  * plutoniixquit (Max SendQ exceeded)
14:00:55  * plutoniixjoined
14:18:31  * italoacasasjoined
14:59:34  * unixpicklejoined
15:06:39  * seventhquit (Ping timeout: 260 seconds)
15:08:16  * seventhjoined
15:09:28  * Cube8quit (Ping timeout: 260 seconds)
15:22:20  * Cube8joined
15:38:04  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:44:33  * unixpicklejoined
16:14:01  <caitp>aklein: just to clarify, were you suggesting that I should try to move that lexical variable desugaring to Ignition now, or keep going with the AST desugaring?
16:14:23  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:34:30  <aklein>caitp: I was genuinely asking why you went for this approach
16:35:02  <aklein>I'd had something like this on my back burner as something to do once BytecodeGenerator was the only consumer of this bit of AST
16:35:29  <aklein>I don't think we want to move it until Crankshaft is actually dead, though
16:35:50  <aklein>bmeurer already tried turning off CS for lexical variables and it tanked some stuff too much, had to revert
16:36:18  <aklein>so then the question is, is it worth it to do this in the short term? I'm not convinced it is.
16:36:30  <aklein>I'd rather the parser knew less about allocation, not more
16:36:39  <caitp>ok, it's better to just say that :)
16:36:48  <caitp>the parser doesn't know anything about allocation in that CL
16:37:44  <aklein>caitp: it passes kPreferLocal to stuff
16:37:56  <caitp>sure, but that doesn't guarantee anything
16:38:12  <aklein>sorry, when I say "know", I mean "be involved in decisions about..."
16:38:38  <aklein>caitp: re: "better to just say that", that was going to be my next email :)
16:39:02  <aklein>it wasn't clear to me from the initial CL whether there were reasons to prefer this approach over a BytecodeGenerator approach other than timing
16:39:47  <caitp>well, for the cases where you do still need the extra block scopes, I think that needs to happen at parse-time rather than in BCG
16:40:06  <caitp>unless ScopeInfo isn't built yet when BCG runs
16:50:16  * Cubonjoined
16:51:58  <caitp>aklein: suppose I reoved the "prefer local" stuff, and didn't try to do the optimization in resumable functions?
16:52:03  * Cube8quit (Ping timeout: 252 seconds)
16:58:42  <aklein>caitp: need to take another look at the CL since marja's comments...
16:59:48  * unixpicklejoined
16:59:58  <aklein>caitp: at a high level I'm also worried about making the parser depend on which backends are active
17:00:31  <caitp>that goes away, heh
17:00:46  <aklein>ahh
17:01:01  <caitp>most of the changes to scopes.h/cc and variable.h are no longer needed if you don't worry about resumable functions
17:01:19  <caitp>I plan to keep the has_inner_function thing because Marja said it would be useful for something else
17:04:17  <aklein>caitp: it does seem to me like that would be a small enough change to be worth the win
17:04:30  <aklein>I am indeed sad that people can avoid using let and speed up their for loops
17:06:14  * Cubonquit (Ping timeout: 255 seconds)
17:19:30  * Cubonjoined
17:25:24  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
17:38:30  * esasjoined
17:45:31  <esas>is there support yet, in any of the branches, for (un)serializing callbacks (FunctionTemplate etc) while creating a snapshot blob?
17:53:29  <esas>if not, how is it handled in the best way? I have some user scripts that needs to be able to resume from an earlier state
17:55:41  <esas>I currently only have callbacks set in the global object. do I just create a snapshot blob (expecting it to ignore the callbacks) then load the snapshot and recreate the callbacks? or do I need to unset the callbacks before creating the snapshot to avoid something going wrong?
17:58:36  * Guest59_quit (Read error: Connection reset by peer)
18:03:49  * Guest59_joined
18:18:56  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:44:42  * bnoordhuisjoined
18:55:59  * unixpicklejoined
19:13:49  * seventhquit (Quit: ...)
21:20:42  * bnoordhuisquit (Quit: leaving)
21:36:56  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:59:36  * Cubonquit (Quit: Leaving)
22:33:04  * plutoniixquit (Quit: Leaving)
22:50:13  * RT|Chatzillajoined
23:47:06  * unixpicklejoined
23:52:14  * xaxxonjoined