00:04:31  * xaxxonquit (Quit: This computer has gone to sleep)
00:05:05  * xaxxonjoined
00:05:18  * xaxxonquit (Remote host closed the connection)
00:31:15  * trungl-botjoined
01:08:51  * bradleymeckjoined
01:09:38  * jwolfequit (Ping timeout: 245 seconds)
01:12:27  * Keverwquit (Quit: Textual IRC Client: www.textualapp.com)
01:23:32  * jwolfejoined
01:55:50  * Keverwjoined
02:00:02  * bradleymeckquit (Quit: bradleymeck)
02:42:07  * xiinotulpjoined
02:43:06  * xiinotulpquit (Max SendQ exceeded)
02:43:32  * xiinotulpjoined
02:44:30  * xiinotulpquit (Max SendQ exceeded)
02:44:57  * xiinotulpjoined
02:45:57  * plutoniixquit (Ping timeout: 260 seconds)
02:46:33  * xiinotulpquit (Max SendQ exceeded)
02:47:01  * xiinotulpjoined
06:56:32  <koldbrutality>i am trying to fix the x32 build (x86_64 with 32-bit pointers) for v8. i found undoing https://chromium.googlesource.com/v8/v8.git/+/ed2be747ad13746797b655fa4f5c23dc6b0ef3e3 changeset fixed the problem for 4.19.40-4.19.45. any suggestions for a tiny patch?
07:07:00  <koldbrutality>it causes a segfault with mksnapshot
08:18:56  <koldbrutality>i think i found it
08:30:05  * zvquit (Ping timeout: 256 seconds)
08:32:40  * zvjoined
09:15:28  * koldbrutalityquit (Ping timeout: 245 seconds)
10:01:14  * xaxxonjoined
10:01:36  <xaxxon>anyone know why my setter/deleter named handler callbacks aren't being called but my getters would be?
11:23:22  * Cube8joined
12:50:00  * bradleymeckjoined
13:52:50  * xaxxonquit (Quit: This computer has gone to sleep)
14:05:36  * xiinotulpchanged nick to plutoniix
14:41:48  * bradleymeckquit (Quit: bradleymeck)
14:58:52  * bradleymeckjoined
15:52:42  * bradleymeckquit (Quit: bradleymeck)
15:53:54  * bradleymeckjoined
15:54:39  * plutoniixquit (Quit: Leaving)
15:57:01  * RT|Chatzillaquit (Quit: ChatZilla [Firefox])
15:57:06  * plutoniixjoined
15:57:09  * plutoniixquit (Max SendQ exceeded)
16:01:56  * koldbrutalityjoined
16:04:11  * koldbrutalityquit (Remote host closed the connection)
16:12:43  * plutoniixjoined
16:26:18  * koldbrutalityjoined
17:01:29  * xaxxonjoined
17:26:55  * bradleymeckquit (Quit: bradleymeck)
18:02:56  <xaxxon>anyone know why my setter/deleter named handler callbacks aren't being called but my getters would be?
18:03:19  <xaxxon>my query (or getter if I have no query) is called, but setter/deleter never called
18:52:08  <xaxxon>is having an accessor and interceptor on the same object not allowed?
19:21:09  <koldbrutality>dunno but it could be a bug or incomplete code. or something you forgot to do
19:22:01  <koldbrutality>need to check code coverage
19:26:20  <xaxxon>koldbrutality, if you have a couple minutes, I posted on v8-users: https://groups.google.com/forum/#!topic/v8-users/8tahYBsHpgY
19:26:39  <xaxxon>I did some digging down into the decision path in v8 as to how it was deciding to call/not call
19:28:25  <xaxxon>it just quickly starts getting down into terms I don't understand
19:40:24  <koldbrutality>i was looking at the unit test and they have few arguments to SetHandler
19:40:59  <koldbrutality>and NamedPropertyHandlerConfiguration
19:43:31  <koldbrutality>maybe u need to flush
19:51:03  <xaxxon>"flush"?
19:52:07  <xaxxon>i'll go watch the code path for my code that works and see how it's different. but the problem is i don't know if the different is "wrong"
20:13:49  <xaxxon>so the difference between my real "not working" code and my "working" simple test code is that the working code returns true from HolderIsReceiverOrHiddenPrototype but my real code doesnt. inside that funciton, it returns true one line: if (!check_prototype_chain()) return true;
20:14:32  <xaxxon>and all that function does is: return (configuration_ & kPrototypeChain) != 0;
20:15:34  <xaxxon>so my simple test the configuration has a prototype chain but my complex code it doesnt? that doesn't seem right
20:17:42  <xaxxon>koldbrutality, any of these words mean anything to you? sorry to keep bugging but I've been stuck on this for.. like 5-6 hours now :(
20:24:04  <xaxxon>hrmm... just realized it's getting to that call from different places... my working code calls it from case LookupIterator::DATA whereas the broken code from case LookupIterator::INTERCEPTOR: {
20:24:22  <xaxxon>which is (it->state()
20:26:56  <xaxxon>shoot... that may not even be right. so much code :(
20:38:25  <xaxxon>https://gist.github.com/xaxxon/a95f0a854ba962c2a8927546e1e82c0f <== stack trace comparisons
20:38:43  <xaxxon>is Runtime_StoreIC_Miss vs StoreIC important I wonder?
20:50:36  <xaxxon>ok, yeah.. it all boils back down to whether this call returns true/false: HolderIsReceiverOrHiddenPrototype https://github.com/v8/v8/blob/master/src/lookup.cc#L550 which returns true here: https://github.com/v8/v8/blob/c2a5dc81c7a26579a599ddaf31a7cf84706135b9/src/lookup.h#L193 in the working code because configuration_ & kPrototypeChain
20:50:55  <xaxxon>which is a state on the lookup iterator
20:55:13  <xaxxon>when it DOESN"T have a prototype chain we succeed
20:55:28  <xaxxon>ok, that makes sense as tothe difference between my real code and test code
20:57:09  <xaxxon>so let me set up a prototype chain in my test case, I suppose
21:07:31  * xaxxonquit (Quit: This computer has gone to sleep)
21:19:45  * xaxxonjoined
21:51:04  <xaxxon>so at this point my question is simply: what causes a LookupIterator::configuration & kPrototypeChain to be true?
21:52:43  <xaxxon>name->IsPrivate() seems like it can.. but no clue waht that means
22:26:31  * RT|Chatzillajoined
22:59:33  <koldbrutality>it is used for iterator
23:04:15  <xaxxon>koldbrutality, I just noticed in my stack traces a difference between setting something to a keyedstore when it works and just "store" when it doesnt. the entry out of the javascript and back into C++ starts at: Runtime_KeyedStoreIC_Miss (works) vs Runtime_StoreIC_Miss (doesn't work) - could that be relevant?
23:08:46  <koldbrutality>did you change the LookupIterator's configuration property?
23:09:28  <koldbrutality>i mean argument
23:11:33  <xaxxon>koldbrutality, I didn't touch anything about LookupIterator. I just noticed that when I started diving into the code with the debugger, the place where it diverged between my working/notworking tests was when it worked, the iterators's state/configuration was 0 when it worked and kPrototypeChain when it didn't. And that directly caused the expected/unexpected code paths
23:28:12  <koldbrutality>what does the signature of StoreIC:Store look like?
23:29:33  <koldbrutality>i can't see the source for ic.cc
23:30:41  <koldbrutality>it diverged at objects.cc
23:31:08  <koldbrutality>what changeset/version are you using?
23:31:43  <koldbrutality>or commit
23:48:30  * plutoniixquit (Quit: Leaving)
23:59:38  * Cube8quit (Remote host closed the connection)