00:39:44  * AtumTquit (Remote host closed the connection)
00:40:36  * xaxxonjoined
01:44:08  * bradleymeckquit (Quit: bradleymeck)
02:02:21  * stalledquit (Ping timeout: 240 seconds)
03:26:31  * Garbeequit (Quit: Connection closed for inactivity)
04:28:45  * xaxxonquit (Quit: xaxxon)
05:38:47  * xaxxonjoined
06:33:37  * xaxxonquit (Ping timeout: 248 seconds)
06:36:39  * xaxxonjoined
10:08:48  * stalledjoined
10:19:10  * xaxxonquit (Quit: xaxxon)
10:25:09  * mylesborinsquit (Quit: farewell for now)
10:25:39  * mylesborinsjoined
10:38:47  <trungl-bot>Tree closed by buildbot@chromium.org: closed (https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20builder/builds/32049 from 712b66da8168c36d350f2f7401f11440c8495830)
10:39:24  * AtumTjoined
10:41:48  <trungl-bot>Tree closed by machenbach@google.com: closed (waiting for more breakages)
10:49:22  * bradleymeckjoined
11:08:00  <trungl-bot>Tree opened by machenbach@google.com: open
11:36:59  * plutoniixquit (Quit: Leaving)
11:58:55  * bradleymeckquit (Quit: bradleymeck)
12:15:32  <trungl-bot>Tree closed by buildbot@chromium.org: closed (https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20builder/builds/32052 from 071cecc048b6cf1034ce0cd0902b8d3b9c743ee9)
12:24:36  <trungl-bot>Tree closed by machenbach@google.com: closed (machenbach fixing)
12:32:40  <trungl-bot>Tree opened by machenbach@google.com: open
12:59:52  <trungl-bot>Tree closed by buildbot@chromium.org: closed (https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20GC%20Stress/builds/187 from 61195eb6817727f6a6374b8bdf565c285af17cfb)
13:02:28  * bradleymeckjoined
13:09:56  <trungl-bot>Tree opened by marja@chromium.org: open (reverted)
13:19:00  <trungl-bot>Tree opened by machenbach@google.com: open
13:22:01  <trungl-bot>Tree closed by buildbot@chromium.org: closed (https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20GC%20Stress/builds/188 from fd059bc4403a706d46a8f09475f19f03e0274b4c)
13:26:03  <trungl-bot>Tree opened by machenbach@google.com: open
13:39:17  * RT|Chatzillaquit (Read error: Connection reset by peer)
13:39:53  * RT|Chatzillajoined
14:21:26  * bradleymeckquit (Quit: bradleymeck)
14:27:17  * bradleymeckjoined
14:33:55  * Garbeejoined
15:09:17  * mylesborinsquit (Quit: farewell for now)
15:13:47  * bradleymeckquit (Quit: bradleymeck)
15:38:57  * plutoniixjoined
15:40:02  * plutoniixquit (Max SendQ exceeded)
15:40:47  * plutoniixjoined
15:46:53  * bradleymeckjoined
16:17:23  <trungl-bot>Tree closed by buildbot@chromium.org: closed (https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20GC%20Stress/builds/196 from 3f6686c2c58a8ce63198977fe08ec9a416cf8b78)
16:28:44  * mylesborinsjoined
16:34:52  <Wes->Hey, folks, I'm looking at pushing binary distros of my embedding around to other linuces. Seeing errors like this:Mar 27 16:32:38 localhost kernel: traps: dcp-miner-v8[12641] trap invalid opcode ip:564266c71302 sp:7fff809322c8 error:0 in dcp-miner-v8[5642665c8000+7c5000]
16:35:10  <Wes->Is this because I didn't build the binary blobs on the target machine?
16:36:17  <Wes->(Are those blobs supposed to be portable?)
16:38:21  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
16:39:28  <caitp>Wes-: it may not be a startup issue at all
16:41:24  <caitp>ah.. there is platform specific code in the snapshot though
16:41:28  <caitp>afaik
16:42:58  <devsnek>I would assume that too cuz it's basically a fancy heap snapshot right
16:44:53  <caitp>my understanding of the snapshot is pretty limited compared to the experts, I think there are bits that are just serialized in a portable way, but things like builtins and code objects would not be in that category afaik
16:46:45  <Wes->Hm. Looks like in my case it was caused by being out of disk space. Whoops. But this is a useful discussion, nevertheless.
16:47:33  <Wes->I have been planning to bury those within executable binaries at some point, under the assumption if the arch, kernel major.minor and libc major.minor match then I should be good to go. Bad idead?
16:47:57  <Wes->(Used to deploying on Solaris where ABI compat is really good......still using a version of xemacs from 1996, for example, lol)
16:48:52  <Wes->I guess this is what Chrome does, so it should be okay?
16:48:55  <caitp>afaik, stuff in the snapshot shouldn't care about ABI, because all the v8 generated code basically uses v8's own JS calling convention or stub calling conventions
16:49:42  <Wes->caitp: That makes sense. The suggestion that the v8 devs are using their own calling convention also makes a lot of sense from an implementation:speed POV
16:50:54  <caitp>there are cases where snapshotted builtin code calls into C++, but it should always have a fairly narrow calling convention to enter C++ from generated code
16:51:00  <Wes->Actually, that might make it easier to emit code for x86 without having to relative branch trampolines....wish I had time to dig into this stuff more deeply
16:51:15  <Wes->caitp++
16:51:19  <caitp>which _may_ be enough to escape ABI differences between versions of GCC
16:52:05  <Wes->caitp: If they stuck with the arch C ABI they'd be totally safe from GCC / clang C++ ABI changes. You can bounce from C ABI to C++ ABI easily enough if you don't need polymorphism.
16:52:25  <caitp>there are probably a few cases where you can run into direct calls into C++ code which returns a double or float, and then you might run into trouble (some of the math builtins rely on code that behaves like that I think)
16:54:01  <Wes->caitp: Ah, yes, that has the potential to be exciting on platforms where sizeof(int) != sizeof(double).
16:54:57  <caitp>or hard vs soft float ABI, or any number of other things
16:55:32  <caitp>computers right... how do they even work
17:00:13  <Wes->caitp: I hear it has something to do with turtles
17:00:26  <devsnek>if i'm doing script streaming
17:00:36  <devsnek>where do i get the Local<String> for the compile call
17:01:11  <devsnek>am i expected to build it in GetMoreData or something
17:03:00  * bradleymeckquit (Quit: bradleymeck)
17:04:31  <caitp>whenever I have a question about the API, I usually go to cs.chromium.org and figure out what blink does
17:05:18  <caitp>where the magic mostly happens in src/third_party/WebKit/Source/bindings/
17:05:42  <devsnek>yea but webkit abstracts everything so much
17:05:54  <devsnek>its hard to follow
17:06:11  <caitp>that's why I use cs.chromium.org instead of grep, for the cross-referencing
17:07:18  <devsnek>having hotlinked functions doesn't help too much
17:07:25  <devsnek>if you have to read the entire codebase anyway
17:12:29  * cloudshujoined
17:12:52  <trungl-bot>Tree opened by buildbot@chromium.org: Tree is open (Automatic: ヽ(^。^)ノ)
17:30:50  * bradleymeckjoined
17:35:54  * bradleymeckquit (Quit: bradleymeck)
17:36:23  * bradleymeckjoined
17:54:37  * bradleymeckquit (Quit: bradleymeck)
17:55:10  * bradleymeckjoined
18:00:47  <devsnek>how come you can't produce a code cache from CompileModule
18:01:36  <aklein>devsnek: purely historical reasons (and "no one's done the work yet", the usual software engineering reason)
18:02:00  <devsnek>i recall hashseed telling me at some point about a change to producing code cache data
18:02:04  <aklein>that and streaming support for modules are both TODOs
18:02:06  <devsnek>like it could be done retroactively
18:02:16  <aklein>yeah, I think there's a new API for that
18:02:28  <aklein>where you say "hey I think I compiled this before, can you give me the code cache?"
18:02:29  <devsnek>i've been reading through v8.h and i can't figure this out lol
18:03:47  <devsnek>yeah i can't find the message from him telling me what it was
18:04:11  <devsnek>all i see is GetCodeCache which doesn't appears to just return a property which may be a nullptr
18:04:20  <devsnek>thats the "old" api afaict
18:04:28  <aklein>devsnek: https://cs.chromium.org/chromium/src/v8/include/v8.h?rcl=e8a11bdc997ea913761b9a61d8edfb73fa51b96a&l=1579
18:04:47  <devsnek>oooo
18:05:09  <devsnek>so as long as i hold on to my UnboundScript instance i can call that at any time?
18:05:30  <aklein>devsnek: I think so?
18:05:33  <aklein>this is all new to me too
18:05:54  <devsnek>who works on code cache stuff
18:05:57  <devsnek>hashseed i assume?
18:38:38  <aklein>historically yes
18:38:49  <aklein>the latest stuff was done by mythria
18:47:50  <aklein>devsnek: looks like d8 has some support if you want some sample usage
20:57:03  * zvquit (Quit: WeeChat 1.9)
21:26:28  * zvjoined
21:58:47  * plutoniixquit (Quit: Leaving)
22:02:47  * xaxxonjoined
22:20:03  * RT|Chatzillajoined
22:57:10  * bradleymeckquit (Quit: bradleymeck)
23:25:57  * xaxxonquit (Ping timeout: 240 seconds)