00:12:05  * Cube8quit (Quit: Leaving)
01:34:04  <caitp>jwolfe: no
01:34:21  <caitp>well, at least not by default
01:34:27  <caitp>I'm sure some people have mail filters or something
01:35:06  <jwolfe>am i supposed to say it when i submit a CL for people to look at? or is adding them as reviewers and writing prose describing my change enough?
01:35:24  <jwolfe>and sending the notification email.
01:35:57  <caitp>You could say "Please take a look" or "Hey, please review" or something
01:36:10  <caitp>just sort of helps notify readers that you want it looked at now
01:51:05  * thefourtheyequit (Quit: Connection closed for inactivity)
04:26:01  * saurik_changed nick to saurik
05:32:49  * seventhquit (Ping timeout: 265 seconds)
05:53:35  * thefourtheyejoined
06:39:00  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20builder/builds/11383 "V8 Win32 - debug builder" from 73a5db9d06051d85724b5846af3b3cb8aa97f60e: [email protected])
06:58:09  <trungl-bot>Tree opened by [email protected]: open - compile hiccup on win
07:15:15  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "compile" on http://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/11242 "V8 Win64 - debug" from 32346aaea037f23a6c312c323fcc8ba9673c22aa: [email protected])
07:18:17  <trungl-bot>Tree opened by [email protected]: Tree is open (win64 infra linker issue)
08:32:16  * jwolfequit (Ping timeout: 264 seconds)
08:35:50  * jwolfejoined
10:58:24  * Garbeejoined
11:00:49  <trungl-bot>Tree closed by [email protected]: Tree is closed (Automatic: "Ignition - turbofan" on http://build.chromium.org/p/client.v8/builders/V8%20Mac/builds/9233 "V8 Mac" from a55beb68e0ededb3773affa294a71edc50621458: [email protected],[email protected])
11:04:50  <trungl-bot>Tree closed by [email protected]: Tree is closed ([email protected] is finxing ignition_turbofan failures)
11:09:52  <trungl-bot>Unknown tree status set by [email protected]: Baum ist offen
11:17:54  <trungl-bot>Unknown tree status set by [email protected]: Baum ist offen, der Wald brennt!
12:51:43  * bobmcwjoined
13:12:20  * zvquit (Ping timeout: 244 seconds)
13:27:48  * zvjoined
14:37:18  * hferreiroquit (Remote host closed the connection)
14:37:37  * hferreirojoined
15:00:31  * jimrandomhjoined
15:04:21  <jimrandomh>Hello. I've got a JS app that's experiencing frequent crashes in both Chrome on Windows and in Electron in Linux, and I got a stack trace on a sigsegv with v8::internal::OptimizedCompileJob::CreateGraph on the stack (v8::internal::FeedbackNexus::ExtractMaps on the top)
15:04:56  <jimrandomh>How would I go about collecting more information to debug this?
15:22:03  <caitp>jimrandom: I strongly suggest sending an email to v8-users or v8-dev, maybe one of the compiler guys will answer
15:22:51  <caitp>or other knowledgable folks
15:23:13  <caitp>does it occur in release builds, or only debug builds?
15:23:25  <caitp>jimrandomh: ^ misspelled your name =)
15:25:02  * bobmcwquit (Remote host closed the connection)
15:25:56  <jimrandomh>Release
15:26:42  * davijoined
15:27:04  <jimrandomh>Yeah, will ask on their list, just want to make my first email not-useless if possible
15:27:15  * bradleymeckjoined
15:29:26  <jimrandomh>(Given that what I currently have is not so much a reduced test case as an unpublished app with lots of non-Javascript out-of-process dependencies, which crashes about once per hour when using the UI normally)
15:32:32  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
15:37:17  <caitp>reading a modern version of that code, it looks like it could break during a GC or OOM scenario, but that's really just a guess, not my area of expertise at all
15:39:44  <jimrandomh>Ah, thanks for the hint - that makes my job finding a better repro case much easier
15:39:59  <jimrandomh>(it's probably a GC scenario)
15:40:32  <caitp>--trace-gc and --trace-ic may help inform you get more details for a bug report or question, at any rate
15:41:06  <jimrandomh>Nasty caveat, the renderer process doesn't have a stdout or stderr
15:41:09  * daviquit (Ping timeout: 276 seconds)
15:41:32  <jimrandomh>I think I can get it one, though
16:03:54  * stalledquit (Ping timeout: 276 seconds)
16:03:59  * bradleymeckquit (Quit: bradleymeck)
16:08:47  * davijoined
16:08:54  * daviquit (Changing host)
16:08:54  * davijoined
16:35:03  * daviquit (Ping timeout: 240 seconds)
16:52:49  * unixpicklejoined
16:56:11  * plutoniixjoined
17:12:17  <jwolfe>if i want to claim an issue, is it ok if i set myself to the owner on monorail? is that what i'm supposed to do? or do i ask for permission/confirmation before doing that?
17:31:52  * iamstef_changed nick to iamstef
17:36:39  <aklein>jwolfe: yeah, setting yourself as the owner is the right thing. If an issue is currently unowned, no confirmation is really necessary
17:37:14  <jwolfe>aklein, thanks.
17:37:38  <aklein>also ideally change the status to "Assigned" or "Started" (depending on whether you've started working on it or not)
17:38:12  <jwolfe>ok. and is the "Send email" checkbox recommended/discouraged/doesn't matter for that updatE?
17:38:28  <jwolfe>is the "Send email" checkbox ever discouraged?
17:40:34  <aklein>I'd say always send email
17:42:56  <caitp>I am having trouble avoiding duplicated code in the ElementsAccessor without adding a way to get an elements accessor for special receiver types
17:43:25  <caitp>but doing that means adding dummy implementations of everything that should never work for those types, and I don't want to do that because that's a lot of code
17:43:43  <caitp>it's cheaper to just have a duplicated impl
17:44:48  <caitp>so many mixed messages from different people on this thing, I dunno if it will ever land and it feels like a waste of time now :(
17:45:44  <aklein>caitp: are the different people just cbruni and bmeurer?
17:46:08  <caitp>and jkummerow now, too
17:46:27  <aklein>ah, didn't see that yet
17:47:16  <aklein>where did jkummerow comment? I don't see it on the CL
17:47:21  <caitp>on the bug
17:48:21  <aklein>ah, I see. at least he seems to be mostly on the same page as cbruni?
17:49:45  <caitp>well mostly, but the main thing is just getting rid of the duplicated impls
17:50:12  <caitp>which is very hard to do in elements.cc, since it takes a lot of work to make that work with non-JSObject types
17:52:14  <caitp>work that is probably not useful for anything else, and so should probably not happen
17:52:33  <aklein>what's special about includes that makes this tricky?
17:52:50  <aklein>I'm wondering why this isn't like the other array builtins that cbruni already moved to ElementsAccessor
17:53:45  <caitp>the CL has it implemented in the ElementsAccessor for non-special receiver types, but the "slow" algorithm is duplicated in runtime-array.cc for the slow path
17:54:22  <caitp>so understandably, we don't want duplicated code in there, but the elements accessor has some properties that make it hard to generalize
17:54:53  <caitp>the super slow case needs to support lengths up to 2^53-1, while the elements accessor is limited to kMaxUint32
17:55:28  <caitp>there's no way to get an elements kind for special receivers. I could treat them as NO_ELEMENTS (which isn't really used anywhere currently), but that seems potentially dangerous
17:56:39  <caitp>for NO_ELEMENTS types, they shouldn't have a "backing store", but the recursive template pattern requires that it has a backing store type with the usual FixedArray methods --- making it FixedArray is potentially dangerous in case it's ever used for a non special receiver type
17:58:17  <aklein>my knowledge of the ElementsAccessor seems like it might be out of date...what's a "special" receiver?
17:58:27  * Keverwjoined
17:59:49  <aklein>(wow there are a lot of things we call "special" these days, that seems like asking for trouble)
18:00:37  <caitp>the main things are JSProxy, the global proxy on the web, the global object, api-created objects with indexed element handlers, named handlers, interceptors, etc
18:01:21  <caitp>all valid receivers, all non-JSObjects
18:01:31  <aklein>well, subclasses of JSObjects
18:01:34  <aklein>er
18:01:36  <caitp>well, okay
18:01:37  <aklein>JSProxy isn't
18:01:39  <caitp>in some cases yes
18:01:41  <aklein>yeah
18:02:07  <aklein>and I assume right now we bail out of ElementsAccessor for the other array methods before we have to deal with those
18:07:05  <aklein>caitp: my reading is that the minimum right now would be to have a "slow" C++ version and the "fast" ElementsAccessor version
18:07:24  <aklein>I don't think it makes sense to teach ElementsAccessor about things that don't have easily-manipulable elements
18:08:01  <aklein>when I say my reading I'm mostly reading the tea leaves of what everyone said so far, I'm not trying to push you in any different direction :)
18:08:08  * zvquit (Read error: Connection timed out)
18:09:24  * zvjoined
18:15:51  <caitp>aklein: that's basically my read, but he is pushing me to get rid of duplicated code :x
18:16:13  <caitp>I don't think it's really worth it to do that, for the reasons discussed above
18:16:22  <caitp>anyways, back in a bit
18:31:06  * thefourtheyequit (Quit: Connection closed for inactivity)
18:34:46  * Garbeequit (Quit: Connection closed for inactivity)
19:16:06  * thefourtheyejoined
19:28:26  * Garbeejoined
20:02:23  * stalledjoined
20:22:08  * seventhjoined
20:40:11  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
21:06:19  * jimrandomhquit (Quit: Page closed)
21:25:58  * wadeyquit (K-Lined)
21:27:00  * wadeyjoined
22:31:26  * unixpicklejoined
23:01:10  * unixpicklequit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:05:46  * seventhquit (Quit: ...)
23:18:28  * RT|Chatzillajoined
23:39:02  * unixpicklejoined