01:01:15  * Allyzjoined
01:05:33  * Allyzquit (Ping timeout: 240 seconds)
01:13:35  * iamdustanjoined
01:17:11  * jmar777joined
01:53:10  * jmar777quit (Remote host closed the connection)
01:57:08  * jmar777joined
02:28:19  * Allyzjoined
03:01:02  * RT|Chatzillaquit (Ping timeout: 252 seconds)
03:08:12  * RT|Chatzillajoined
03:13:26  * RT|Chatzilla_joined
03:13:41  * RT|Chatzillaquit (Read error: Connection reset by peer)
03:13:46  * RT|Chatzilla_changed nick to RT|Chatzilla
03:53:48  * jmar777quit (Remote host closed the connection)
03:57:17  * c4milojoined
04:00:41  * jmar777joined
04:08:08  * iamdustanquit (Ping timeout: 252 seconds)
04:44:04  * plutoniixquit (Quit: จรลี จรลา)
04:47:00  * c4miloquit (Remote host closed the connection)
04:47:26  * c4milojoined
04:48:41  * jmar777quit (Remote host closed the connection)
04:52:03  * c4miloquit (Ping timeout: 255 seconds)
05:15:08  * mostynbjoined
05:19:28  * jmar777joined
05:23:33  * jmar777quit (Ping timeout: 240 seconds)
05:51:37  * jmar777joined
05:56:22  * jmar777quit (Ping timeout: 264 seconds)
06:31:09  * plutoniixjoined
06:36:12  * c4milojoined
06:41:01  * c4miloquit (Ping timeout: 256 seconds)
06:43:03  * rendarjoined
06:52:16  * jmar777joined
06:56:53  * jmar777quit (Ping timeout: 256 seconds)
07:32:59  * Lethalmanjoined
07:37:15  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on "Webkit Linux 64" from 22311: [email protected])
07:46:57  * muelli_joined
08:25:47  * jmar777joined
08:30:03  * jmar777quit (Ping timeout: 240 seconds)
08:47:45  <trungl-bot>Tree opened by [email protected]: Tree is open (r22311 reverted)
09:13:54  <trungl-bot>Tree closed by [email protected]: Tree is closed (master restart - no commits please)
09:19:50  * plutoniixquit (Quit: จรลี จรลา)
09:48:11  <trungl-bot>Tree opened by [email protected]: Tree is open
09:54:14  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on "Webkit Linux" from 22312: [email protected])
10:01:15  <trungl-bot>Tree opened by [email protected]: Tree is open
10:11:08  * deavidquit (Ping timeout: 252 seconds)
10:12:57  * deavidjoined
10:14:12  * c4milojoined
10:18:37  * c4miloquit (Ping timeout: 256 seconds)
10:27:21  * jmar777joined
10:31:48  * jmar777quit (Ping timeout: 255 seconds)
10:37:16  * mostynbquit (Quit: Leaving)
10:38:56  * Allyzquit (Remote host closed the connection)
10:39:56  * Allyzjoined
10:41:34  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on "NaCl V8 Linux" from 22314: [email protected], [email protected], [email protected])
10:44:18  * Allyzquit (Ping timeout: 240 seconds)
10:49:36  <trungl-bot>Tree opened by [email protected]: Tree is open
10:49:58  * C-Manjoined
11:16:10  * mostynbjoined
11:25:52  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check" on "V8 Linux64 ASAN" from 22316: [email protected], [email protected])
11:26:53  <trungl-bot>Tree opened by [email protected]: Tree is open (yangguo investigating asan issue)
11:34:57  <trungl-bot>Tree opened by [email protected]: Tree is open
12:02:51  * c4milojoined
12:07:18  * c4miloquit (Ping timeout: 240 seconds)
12:28:50  * jmar777joined
12:29:06  * Allyzjoined
12:32:58  * jmar777quit (Ping timeout: 240 seconds)
12:34:33  * Allyzquit (Ping timeout: 240 seconds)
12:46:17  <caitp>so now that we're parsing arrow functions, I guess it's time to make them actually work :d
13:08:39  <caitp>well, I guess fixing the parsing bugs would need to be done first
13:08:42  <caitp>mm
13:15:43  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on "V8 Win64" from 22321: [email protected], [email protected], [email protected])
13:29:19  * plutoniixjoined
13:38:33  <jochen__>i blame hannes
13:52:02  * c4milojoined
13:56:52  * c4miloquit (Ping timeout: 260 seconds)
14:04:02  <trungl-bot>Tree opened by [email protected]: Tree is open (Win64 build fix committed)
14:07:43  <marja___>caitp: :)
14:13:05  * mostynbquit (Quit: Leaving)
14:18:33  <caitp>marja___, there are a few issues with the preparser, and the lazy parsing seems to always result in an error :[ should I open a new issue regarding the preparsing problems?
14:20:47  <marja___>caitp: related to arrow functions, or other issues?
14:20:55  <caitp>yes, arrow functions
14:21:22  <marja___>caitp: opening a new issue sounds good, pls cc me and [email protected]
14:21:55  <marja___>soon we will see how come the tests didn't catch it!
14:23:19  <caitp>well this one is pretty simple, it looks like there are no test cases covering it, which would explain why =)
14:30:00  <caitp>marja___, I can't add CCs, but https://code.google.com/p/v8/issues/detail?id=3431&thanks=3431&ts=1405002576
14:30:38  <caitp>but yeah, lazy binding is an issue even for the supported syntaxes, calling an arrow function will result in a syntax error
14:30:58  <caitp>which is unfortunate, and maybe a bit more work to fix
14:33:55  <marja___>caitp: thx, i'll add the ccs
14:34:08  <caitp>actually, maybe I'm wrong... hmm,
14:34:35  <caitp>yeah I'm wrong there is actually a test for this
14:34:41  <caitp>and it is passing, so there you go
14:34:48  <caitp>lets close that, it's definitely just the lazy parsing issues
14:35:04  <marja___>yes, there should be a test, that's such a simple case
14:35:46  <marja___>caitp: but... hmm.. what do yo mean by lazy parsing issues
14:36:16  <marja___>caitp: as in, is there a bug in arrow function parsing, or not?
14:36:16  <caitp>so, if you declare `var x = () => whatever;` and invoke x(), we go through a second run of parsing
14:36:41  <caitp>and in that second run of parsing, we always trip over the `=>` token
14:38:38  <caitp>although interestingly, `(function() { var x = () => 6; return x(); })()` is a syntax error, while `(() => 6)()` isn't
14:39:08  <marja___>... now i'm thinking whether it makes sense for arrow functions to be lazy at all
14:39:14  <marja___>but anyway, that aside...
14:40:14  <marja___>argh, the preparse data
14:40:23  <marja___>i think that just breaks with arrow functions, whoops
14:40:27  <marja___>but that's probably a separate issue...
14:41:41  <caitp>it is separate to the one I opened, I think that can be closed
14:41:42  <marja___>wait no, it works, we produce the preparse data for lazy arrow functions too. that was just a sidetrack.
14:41:48  <marja___>okay, back to the problem you're talking about..
14:42:35  * aperezdcjoined
14:42:53  <aperezdc>marja___: here I am
14:42:55  <marja___>okay, so, the problem is...
14:43:08  <marja___><caitp> so, if you declare `var x = () => whatever;` and invoke x(), we go through a second run of parsing
14:43:08  * aperezdcadds #v8 to autojoin channels
14:43:13  <marja___><caitp> and in that second run of parsing, we always trip over the `=>` token
14:43:18  <marja___><caitp> although interestingly, `(function() { var x = () => 6; return x(); })()` is a syntax error, while `(() => 6)()` isn't
14:43:52  <caitp>hi aperez, nice work on landing the arrow function parsing regardless of the issues still remaining =)
14:44:00  <marja___>(a side thing is that i'm still not convinced that lazy arrow functions make much sense! but that's a separate thing.)
14:44:36  <caitp>maybe we don't need to lazy parse arrow functions with concise bodies?
14:44:50  <marja___>but we don't know how long the arrow function is before we parse it :)
14:45:11  <marja___>so the decision whether to lazy-parse it or normal-parse it needs to be made when the function starts.
14:45:12  <caitp>well if it's a concise body then it can only be so long, right, a single expression
14:45:23  <marja___>yeah
14:45:34  <marja___>but even if it's something very �{ short; } we probably shouldn't
14:46:06  <marja___>anyhow
14:46:11  <aperezdc>about that, I'd say concise ones (single expression body) arrow functions would not be lazy parsed
14:46:23  <aperezdc>it is guaranteed that it is always only one expression
14:46:35  <aperezdc>so I would not expect those to be long in mosy of the cases
14:46:35  <marja___>actually, would the problem go away if we just say all arrow functions are parsed eagerly?
14:47:04  <aperezdc>marja___: yes
14:47:23  <marja___>is there any reason to have lazy arrow functions? (i remember we discussed this but then it slipped out of my radar)
14:47:25  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check" on "V8 Linux - arm64 - sim - debug" from 22323: [email protected])
14:47:45  <caitp>I thought the argument was that people would use them for event handlers that are crazy-long in node.js or something
14:47:52  <marja___>oh my.
14:47:53  <aperezdc>the issue that caitp found is because in Parser::ParseLazy() we want to check for: if (shared_info->is_arrow()) { ParseAssignmentExpression() } else { ParseFunctionLiteral() }
14:48:05  <marja___>alright.
14:48:23  <aperezdc>caitp: yes, that is my though as well, long callbacks in node.js and so
14:48:54  <marja___>i'm not so sure what we should think of that. we'll take a performance hit on small arrow functions :/
14:48:58  <aperezdc>but SharedFunctionInfo::is_arrow() is gonna be added in the next patch
14:49:05  <marja___>yup. okay. that is fair enough.
14:50:32  <marja___>and the always-eager vs. lazy arrow functions can be solved separately.
14:50:37  <marja___>at some point in time.
14:52:19  <marja___>caitp: thanks for reaching out, we're ofc excited to find all the problems as early as possible. :)
14:52:20  <aperezdc>fwiw, I have the follow-up patch ready, I am making a run of the tests
14:54:21  <marja___>aperezdc: regarding that, i route you to [email protected] who'll review that part.
14:55:26  <aperezdc>marja___: yeah, I know... what I can make for you is a separate patch for disabling lazy parsing for concise arrow functions
14:55:29  <trungl-bot>Tree opened by [email protected]: Tree is open
14:55:53  <marja___>aperezdc: ok
14:57:06  <marja___>aperezdc: btw, it would be good to have a test that we produce sane preparse data for arrow functions and also use it in a sane way. maybe.
14:57:42  <marja___>there are already some tests which test that we actually do use the preparse data (because whoops, there were some year-long bugs where we actually didn't use parts of it :P) which might be helpful or not.
14:57:53  <aperezdc>marja___: sure, I can look into that as well
14:58:14  <aperezdc>as a bonus, making sure that the concise ones are parsed eagerly and do not generate preparse data
14:58:22  <marja___>sg :)
14:59:02  <marja___>ah yes, there is a test "don't regeress data sizes" or such, you can see there how you assert that you get the right amount of data
14:59:16  <marja___>and a separate one which asserts that it's actually used.
14:59:28  <aperezdc>marja___: sounds like the perfect place to add those test cases
14:59:30  <aperezdc>:)
15:08:34  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check" on "V8 Mac64 - debug" from 22325: [email protected], [email protected], [email protected])
15:14:28  * mostynbjoined
15:20:43  <rmcilroy>I blame mstarzinger
15:25:44  * dpino__joined
15:26:07  * mostynbquit (Quit: Leaving)
15:27:14  * dpinojoined
15:27:33  * dpino__quit (Client Quit)
15:34:22  * dpinoquit (Ping timeout: 245 seconds)
15:34:34  * unixpicklejoined
15:37:18  * dpinojoined
15:43:59  * dpinoquit (Ping timeout: 272 seconds)
15:45:40  * dpinojoined
15:53:14  * dpinoquit (Ping timeout: 252 seconds)
15:57:21  * dpinojoined
16:00:48  * iamdustanjoined
16:01:57  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2009081014])
16:05:58  * dpinoquit (Ping timeout: 240 seconds)
16:07:48  * Allyzjoined
16:08:48  * dpinojoined
16:12:29  * Allyzquit (Ping timeout: 252 seconds)
16:13:18  * dpinoquit (Ping timeout: 240 seconds)
16:21:34  * iamdustanquit (Ping timeout: 264 seconds)
16:26:23  * caitpquit (Ping timeout: 264 seconds)
16:27:28  * dpinojoined
16:33:38  * dpinoquit (Ping timeout: 240 seconds)
16:34:52  * dpinojoined
16:52:36  * caitpjoined
16:57:35  * caitpquit (Ping timeout: 264 seconds)
16:58:33  * Lethalmanquit (Remote host closed the connection)
17:12:24  * iamdustanjoined
17:18:21  * muelli_quit (Ping timeout: 272 seconds)
17:18:42  <trungl-bot>Tree closed by [email protected]: Tree is closed (waiting for r22331)
17:30:47  * iamdustanquit (Ping timeout: 240 seconds)
17:46:33  * trungl-botquit (Quit: Ctrl-C at console.)
17:47:10  * trungl-botjoined
17:53:02  <trungl-bot>Tree opened by [email protected]: Tree is open
17:53:19  * caitpjoined
17:56:33  * dpinoquit (Ping timeout: 240 seconds)
17:56:48  * Allyzjoined
17:58:10  * caitpquit (Ping timeout: 264 seconds)
18:01:33  * Allyzquit (Ping timeout: 240 seconds)
18:39:23  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Check" on "V8 Win32 - nosnap - shared" from 22333: [email protected])
18:40:41  * rendarquit (Ping timeout: 256 seconds)
18:46:57  * rendarjoined
18:52:02  * unixpicklequit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:53:58  * caitpjoined
18:59:22  * caitpquit (Ping timeout: 264 seconds)
19:03:36  * unixpicklejoined
19:09:37  <trungl-bot>Tree closed by [email protected]: Tree is closed (who takes care of the leaks?)
19:10:38  <trungl-bot>Tree closed by [email protected]: Tree is closed (who takes care of the leaks and arm?)
19:12:39  * iamdustanjoined
19:24:03  * iamdustanquit (Ping timeout: 240 seconds)
19:29:42  * C-Manquit (Quit: Connection reset by beer)
19:32:14  <rmcilroy>I'm not sure if the arm failure is mine
19:32:45  <rmcilroy>when I try to reproduce locally I get the same error messages with or without my change
19:33:28  <rmcilroy>hpayer, mstarzinger - if you don't think it's your changes then feel free to speculatively revert mine
19:34:57  <rmcilroy>asan failiure definitely shouldn't be mine as my change only touches arm
19:41:37  * iamdustanjoined
19:46:35  * Allyzjoined
19:50:47  * Allyzquit (Ping timeout: 240 seconds)
19:55:08  * caitpjoined
19:59:59  * caitpquit (Ping timeout: 264 seconds)
20:01:13  * unixpicklequit (Quit: Textual IRC Client: www.textualapp.com)
20:06:09  * muelli_joined
20:08:48  * iamdustanquit (Ping timeout: 260 seconds)
20:18:39  * iamdustanjoined
20:48:32  * iamdustanquit (Ping timeout: 240 seconds)
20:48:38  * muelli_quit (Ping timeout: 240 seconds)
20:49:12  * muelli_joined
20:55:44  * caitpjoined
21:02:22  * caitpquit (Ping timeout: 264 seconds)
21:18:45  * octetcloudjoined
21:35:37  * Allyzjoined
21:40:50  * Allyzquit (Ping timeout: 252 seconds)
21:48:09  * iamdustanjoined
21:48:47  * caitpjoined
21:53:38  * rendarquit
22:19:29  * RT|Chatzillajoined
22:25:03  * iamdustanquit (Ping timeout: 255 seconds)
22:32:56  * Martijncquit (*.net *.split)
22:32:56  * Halcy0nquit (*.net *.split)
22:32:57  * mawequit (*.net *.split)
22:32:57  * saurik_quit (*.net *.split)
22:32:57  * machenbachquit (*.net *.split)
22:32:57  * guorquit (*.net *.split)
22:32:57  * rmcilroyquit (*.net *.split)
22:32:58  * aperezdcquit (*.net *.split)
22:32:58  * agerquit (*.net *.split)
22:32:58  * Vbitzquit (*.net *.split)
22:32:58  * marja___quit (*.net *.split)
22:32:58  * iamstefquit (*.net *.split)
22:32:58  * wadeyquit (*.net *.split)
22:32:58  * mvstantonquit (*.net *.split)
22:32:59  * rosseauxquit (*.net *.split)
22:33:33  * Halcy0njoined
22:33:34  * Halcy0nquit (Changing host)
22:33:34  * Halcy0njoined
22:36:05  * aperezdcjoined
22:36:05  * saurik_joined
22:36:05  * machenbachjoined
22:36:05  * guorjoined
22:36:05  * rmcilroyjoined
22:36:05  * agerjoined
22:36:05  * Vbitzjoined
22:36:05  * marja___joined
22:36:05  * iamstefjoined
22:36:05  * wadeyjoined
22:36:05  * mvstantonjoined
22:36:07  * rosseauxjoined
22:37:19  * Martijncjoined
22:41:52  * iamdustanjoined
22:42:18  <trungl-bot>Tree closed by [email protected]: Tree is closed (r22332 reverted to fix arm, not sure about leaks)
23:05:16  * muelli__joined
23:07:11  * muelli_quit (Ping timeout: 264 seconds)
23:21:47  * iamdustanquit (Ping timeout: 240 seconds)
23:22:39  * iamdustanjoined
23:25:29  * Allyzjoined
23:26:57  * octetcloudquit (Quit: WeeChat 0.4.3)
23:27:17  * muelli__quit (Ping timeout: 240 seconds)
23:30:24  * Allyzquit (Ping timeout: 260 seconds)
23:53:17  * iamdustanquit (Ping timeout: 240 seconds)