00:09:54  <aklein>also, in general, no, jkummerow doesn't hang out here
00:12:46  * seventhquit (Ping timeout: 272 seconds)
00:13:46  * bradleymeckjoined
00:26:36  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
00:27:49  * BobGneuquit (Read error: Connection reset by peer)
00:38:53  * BobGneujoined
00:49:32  * jugglinmikequit (Ping timeout: 250 seconds)
00:55:32  * watildejoined
00:56:25  <dherman>aklein: who'd be the best person to ask about the relationship between FunctionTemplates and realms?
01:00:27  <aklein>dherman: depending on how big your question is you could try me :)
01:00:42  <dherman>thanks!
01:00:55  * watildequit (Ping timeout: 245 seconds)
01:01:32  <dherman>when I create a FunctionTemplate, it creates a new "brand"
01:01:46  <dherman>so HasInstance can distinguish instances of that "class" from any other object type
01:01:57  <dherman>and it also creates its own constructor and prototype
01:02:09  <dherman>so brands and constructor/prototype pairs seem to be in 1:1 correspondence
01:02:35  <dherman>on the web, you can have object types from multiple realms interact
01:02:41  <dherman>I'm fuzzy on the web semantics of this
01:02:52  <dherman>you get distinct constructor/prototype pairs in distinct realms
01:02:59  <dherman>say, for a DOM object type
01:03:07  <dherman>but I'm fuzzy on whether they are considered the same brand
01:03:22  <dherman>I'm curious whether chrome uses the v8 FunctionTemplate API for DOM types
01:03:36  <aklein>I believe it does, yes
01:03:40  <dherman>and whether the semantics of cross-realm DOM classes results in incompatible brands
01:03:42  <aklein>easy to create a quick test...
01:03:49  <dherman>I wasn't quite sure how to test it
01:04:03  <aklein>no, FunctionTemplate HasInstance works across realms
01:05:03  <dherman>I'm confused
01:05:13  <dherman>don't you have to create multiple FunctionTemplates?
01:05:15  <dherman>one per realm?
01:05:19  <aklein>no
01:05:34  <dherman>or do you create an "ur-constructor"
01:05:41  <dherman>and then a distinct function and prototype object in each realm
01:05:48  <dherman>where the distinct function delegates to the ur-constructor
01:05:52  <dherman>using constructor-override
01:05:53  <aklein>this makes more sense if you know the internals of V8...
01:05:59  <dherman>turns out I don't ;P
01:06:11  <aklein>so there are SharedFunctionInfo objects
01:06:18  <aklein>which represent Realm-independent functions
01:06:23  <aklein>and then there are JSFunction objects
01:06:48  <aklein>which represent the concrete instances of that SharedFunctionInfo
01:07:21  <dherman>does chrome use these internals for the DOM?
01:07:31  <aklein>and are associated with a Realm (along with other per-instance associations, like the set of closures they're nested inside of)
01:07:47  <aklein>so I'm working back out to the API now
01:08:03  <dherman>oh ok
01:08:06  <dherman>sorry continue :)
01:08:10  <aklein>given a JSFunction (say, the 'Window' constructor function)
01:08:32  <aklein>it's associated with some SharedFunctionInfo that has a 1:1 relationship with some FunctionTemplate
01:08:52  <aklein>and it's that linkage that lets us do brand checks
01:09:11  <aklein>for object's there's one more link, right, which is from the object to its constructor
01:10:08  <aklein>and you can observe this by, for example, calling methods on a DOM object of the "same" type from another realm and seeing that it works
01:11:05  <aklein>so now I'll ask, did I answer your question? :)
01:11:17  <dherman>partly
01:11:21  <dherman>I get what the semantics is
01:11:26  <dherman>but I don't get how it works with the v8 api
01:11:36  <dherman>because a FunctionTemplate doesn't let you create multiple distinct constructor functions
01:12:13  <dherman>unless you're saying that the implementation strategy is just to create an otherwise-unrelated distinct JSFunction
01:12:17  <dherman>that uses the constructor override pattern
01:12:25  <aklein>I'm probably missing something about the details of the API
01:12:46  <dherman>if I create a FunctionTemplate
01:12:50  <dherman>it represents a brand
01:12:57  <dherman>and has HasInstance to check the brand
01:13:08  <dherman>but I can only call GetFunction to get the one and only constructor function associated with it
01:13:22  <dherman>if I were implementing the DOM I could just create one such FunctionTemplate,
01:13:22  <aklein>GetFunction() takes a Context, right?
01:13:29  <dherman>oh!
01:13:31  <aklein>or has an implied current context
01:13:41  <aklein>(in the deprecated version)
01:13:44  <dherman>yeah it takes a context
01:13:50  <dherman>I see!
01:13:54  <dherman>that's the piece I was missing
01:13:54  <aklein>And the docc omment: /** Returns the unique function instance in the current execution context.*/
01:14:17  <dherman>got it, that's what I was missing
01:14:19  <aklein>cool
01:14:39  <aklein>sorry for the gritty details, I can't keep all the API and the internals in my head at the same time
01:14:46  <aklein>partially because they have overlapping but incompatible names
01:15:25  <dherman>np
01:15:28  <dherman>mystery solved
01:17:01  * bradleymeckquit (Ping timeout: 250 seconds)
01:25:45  <dherman>aklein: would it be accurate to say isolates correspond to workers and contexts to realms?
01:40:15  * jgiquit (Quit: jgi)
01:41:58  * jgijoined
01:47:58  * jgiquit (Quit: jgi)
02:07:19  <caitp>something in the past two weeks has made link times skyrocket for me in v8, and only with the bundled clang toolchain :|
02:07:42  <caitp>using system clang, it does a much better job
02:07:54  <caitp>I guess it must not be affecting most people or it would probably have been noticed
02:10:16  <caitp>just hangs there for like 8 minutes when it used to be almost instantaneous D:
02:32:17  * lerelaquit (Ping timeout: 276 seconds)
02:44:22  * plutoniixquit (Read error: Connection reset by peer)
02:45:02  * plutoniixjoined
03:32:11  * zv_joined
03:56:10  * zv_quit (Quit: WeeChat 1.4)
03:56:45  * zvjoined
04:01:11  * esasquit (Ping timeout: 245 seconds)
04:11:33  * ErikCorry__joined
04:11:33  * seththompson_joined
04:11:39  * Martijnc_joined
04:11:39  * mikolalysenkoquit (Ping timeout: 260 seconds)
04:11:39  * eseidel_joined
04:12:10  * seththompsonquit (Ping timeout: 260 seconds)
04:12:15  * seththompson_changed nick to seththompson
04:12:49  * ErikCorry_quit (Ping timeout: 260 seconds)
04:12:49  * Martijncquit (Ping timeout: 260 seconds)
04:12:49  * eseidelquit (Ping timeout: 260 seconds)
04:12:49  * ErikCorry__changed nick to ErikCorry_
04:12:56  * Martijnc_changed nick to Martijnc
04:13:24  * littledan_quit (Ping timeout: 260 seconds)
04:13:42  * eseidel_changed nick to eseidel
04:16:49  * saper_joined
04:19:09  * stalledquit (Ping timeout: 260 seconds)
04:19:09  * Guest50070quit (Ping timeout: 260 seconds)
04:19:49  * saperquit (Ping timeout: 260 seconds)
04:20:02  * s1wjoined
04:20:25  * s1wchanged nick to Guest51729
04:21:35  * mikolalysenkojoined
04:24:04  * ec\joined
04:24:50  * littledan_joined
04:32:41  * stalledjoined
05:11:17  * jgijoined
05:20:50  * xaxxonjoined
05:23:09  <xaxxon>I'm throwing an exception in a functinotemplate function.. and my program is instantly dying with SIGABRT and printing the contents of my exception to stdout. I have a TryCatch and a try{}catch(...)} in the call stack of the code that's throwing and it's all being ignored. When I put a breakpoint on the actual throw line, it's in the main thread. Any ideas? Here's the code that throws, the code that's supposed to catch (though t
05:23:10  <xaxxon>here's a TryCatch object in the call stack as well) and the stack trace here: https://gist.github.com/xaxxon/ab7093bf7d3888c0acbd
05:23:55  <xaxxon>does v8 do some crazy-whacked things to exception handling? Also, I tried this in code that shouldn't call v8::locker anywhere to try to stop it from being multi-thready but I'm not sure if I succeeded or not
05:24:24  <xaxxon>because there are a bunch of v8 workerthread's
05:35:49  <xaxxon>I literally do one "s"tep in the debugger after my thrown object constructor returns and I'm in pthread_kill
05:36:07  <xaxxon>but I guess if the stack isn't unwindable, that is what could happen?
05:36:12  <xaxxon>or... ?
05:41:55  <xaxxon>maybe it's the generated machine code, but I have a v8::TryCatch object before I run the script
05:55:08  <jgi>xaxxon: TryCatch instances catch JavaScript errors thrown from JavaScript code, you’re throwing a C++ exception from your native code
05:55:32  <xaxxon>jgi, it also catches things like compilation errors, doesn't it?
05:55:46  <xaxxon>jgi, anyhow, I have multiple try{}catch(...){} around it as well... and those don't fire, either
05:57:33  <xaxxon>like I said, it goes straight from the thrown object constructor to pthread_kill in one debugger "step"
05:57:39  <jgi>xaxxon: the code you posted doesn’t seem to be self-contained, and I don’t see where _add_method is called. Could you post some code that reproduces your problem with build instructions? It seems it would be easier to help you this way.
05:57:49  <xaxxon>yep
05:58:14  <xaxxon>it'll take like .. 15m
05:58:21  <jgi>xaxxon: I might be offline in a while though, but I could take a look tomorrow
05:58:37  <xaxxon>I may send it to the list if I get a full repro case
05:59:07  <jgi>that would be even better
05:59:32  <xaxxon>I was just hoping to make progress quickly, so I figured I'd check here to see if I was missing anything obvious
06:00:45  <xaxxon>valgrind shows no errors
06:18:43  <xaxxon>I've got it... posting it to gist now...
06:19:45  <xaxxon>jgi, https://gist.github.com/xaxxon/d45ba2bd11675735b4fa
06:20:17  <jgi>xaxxon: do you have a build script for that?
06:20:56  <xaxxon>i'll make something
06:23:41  <xaxxon>added to gist
06:24:23  <xaxxon>i mean.. it's just the command line I use..
06:24:30  <xaxxon>my makefile wouldn't make sense for anyone else
06:26:12  <xaxxon>I'm running latest v8 .. from a few days ago... on latest OS X
06:27:37  <xaxxon>not a bad estimate... I said it would take 15m.. took 18
06:36:29  <xaxxon>https://bugs.chromium.org/p/v8/issues/detail?id=1072 hrmm
06:36:40  <xaxxon>oh.. https://bugs.chromium.org/p/v8/source/detail?r=7548 <== page does not exist
06:38:08  <xaxxon>am I supposed to use this: v8::Isolate::ThrowException ( Local< Value > exception ) ?
06:38:57  <xaxxon>typedef bool(* v8::Isolate::AbortOnUncaughtExceptionCallback) (Isolate *) or maybe it has something to do with this? (I don't call this at all)
06:39:42  <xaxxon>SetAbortOnUncaughtExceptionCallback
06:40:17  <xaxxon>I never knew about any of this...
06:40:35  <xaxxon>jgi, maybe I'm supposed to use one or more of these things? I never knew they existed
06:41:42  <jgi>SetAbortOnUncaughtExceptionCallback is used to provide V8 with a callback to determine whether or not to abort when an uncaught exception is thrown
06:42:01  <jgi>xaxxon: it should not be related to what you’re doing
06:42:26  <xaxxon>ok
06:42:37  <jgi>xaxxon: if you don’t set a callback, your process will abort if you pass the —abort-on-uncaught-exception command line option to V8, it will not abort otherwise
06:42:46  <xaxxon>ok
06:43:03  <jgi>xaxxon: I don’t have the time to compile your program tonight :(, maybe I’ll have more time tomorrow
06:43:12  <xaxxon>jgi, no problem. I'll post to the list
06:43:22  <xaxxon>jgi, thank you
06:43:54  <jgi>xaxxon: and also yes, TryCatch instances can be used to “catch” errors when compiling JavaScript code with v8::Script::Compile
06:47:19  <jgi>xaxxon: but looking again at the code, the v8::TryCatch instance would “catch” an exception if you compiled “throw new Error(‘boom’);” instead of “throw_exception();”
06:48:07  <xaxxon>that makes sense. but my actual use case is the functiontemplate callback throwing because it didn't get enough arguments from javascript to call the real funciton I want to call
06:49:35  <jgi>xaxxon: in that case you should use v8::Isolate::ThrowException
06:49:47  <xaxxon> i->ThrowException(v8::Number::New(i, 4.4)); makes the trycatch fire
06:49:50  <xaxxon>yeah, that's what I just did
06:50:04  <jgi>xaxxon: and remove the c++ try/catch
06:50:20  <xaxxon>jgi, but you don't know offhand why I get the specific behavior I do when I throw the c++ exception?
06:50:42  <jgi>xaxxon: I don’t
06:50:44  <xaxxon>it's just weird that I don't see something in the call stack
06:51:02  <xaxxon>ok, well this is a good workaround, at least... maybe even a perfectly good final solution
06:51:04  <xaxxon>so thank you again :)
06:53:54  <xaxxon>jgi, I'm wondering if the V8-generated machine code in the stack trace isn't exception friendly and that causes the stack unwinding to barf... but I'm far from an expert on what goes on under the covers
06:54:23  <jgi>xaxxon: that would be my hunch too, but I’ve actually never looked at how the runtime support for C++ exception is implemented
06:54:31  <jgi>xaxxon: but now I’m tempted :)
06:54:42  <xaxxon>jgi, oh wait... what happens when you throw an exception through a function marked noexcept?
06:57:00  <jgi>xaxxon: yes, I think that could cause std::terminate to be called, but not the exception handler
06:57:11  <xaxxon>yeah..
06:57:35  <jgi>xaxxon: which of these functions is declared as noexcept?
06:57:50  <xaxxon>none of mine
06:57:54  <xaxxon>but I don't know about v8
06:58:09  <xaxxon>..or maybe the generated code is generated as if noexcept
06:59:34  <jgi>xaxxon: if you find out what’s going on, I’m interested
06:59:43  <jgi>xaxxon: I probably won’t have time to look into it
06:59:46  <xaxxon>I've started my post to the list
06:59:50  <xaxxon>so it'll be on v8-dev
07:00:33  <jgi>xaxxon: maybe v8-user would be more appropriate?
07:00:49  <jgi>xaxxon: sorry v8-userS
07:01:14  <xaxxon>oh didn't know about that. sure
07:11:00  * plutoniixquit (Quit: จรลี จรลา)
07:15:06  * plutoniixjoined
07:32:53  * watildejoined
07:33:20  * jgiquit (Quit: jgi)
07:49:03  * watildequit (Remote host closed the connection)
08:14:12  * davijoined
08:22:07  * daviquit (Ping timeout: 250 seconds)
08:25:32  * rendarjoined
08:42:15  * xaxxonquit (Ping timeout: 240 seconds)
09:18:37  * xaxxonjoined
09:47:15  * etnbrdjoined
10:05:59  * xaxxonquit (Ping timeout: 276 seconds)
11:59:23  * seventhjoined
13:07:06  * seventhquit (Ping timeout: 250 seconds)
14:16:20  * esasjoined
14:51:52  * jugglinmikejoined
14:58:55  * jugglinmikequit (Ping timeout: 240 seconds)
15:02:23  * jugglinmikejoined
15:10:21  * bobmcwquit (Ping timeout: 245 seconds)
15:13:09  * bobmcwjoined
15:13:09  * bobmcwquit (Changing host)
15:13:09  * bobmcwjoined
15:53:45  * RT|Chatzillaquit (Quit: ChatZilla 0.9.86.1 [Firefox 2.0.0.22pre/2010030309])
16:08:48  * jgijoined
16:31:22  * jgiquit (Quit: jgi)
16:47:39  * davijoined
16:47:39  * daviquit (Changing host)
16:47:39  * davijoined
17:01:05  * jgijoined
17:07:01  * C-Manjoined
17:18:23  * daviquit (Remote host closed the connection)
17:34:08  * watildejoined
17:35:13  * davijoined
17:35:13  * daviquit (Changing host)
17:35:13  * davijoined
17:41:47  * watildequit (Remote host closed the connection)
17:42:29  * watildejoined
17:43:40  * C-Manquit (Quit: Connection reset by beer)
17:56:07  * C-Manjoined
17:58:46  * C-Manquit (Client Quit)
18:00:08  * C-Manjoined
18:01:03  * C-Manquit (Client Quit)
18:01:58  * C-Manjoined
18:20:06  * lerelajoined
18:34:11  * daviquit (Remote host closed the connection)
18:37:43  * davijoined
18:42:17  * JoWiejoined
18:45:06  * bradleymeckjoined
19:07:35  * C-Manquit (Quit: Connection reset by beer)
19:10:02  * C-Manjoined
19:26:28  * watildequit (Remote host closed the connection)
19:36:13  * watildejoined
19:36:13  * watildequit (Remote host closed the connection)
19:36:45  * watildejoined
19:38:04  * kenansul-joined
19:40:56  * watildequit (Ping timeout: 240 seconds)
20:08:40  * bradleymeckquit (Quit: bradleymeck)
20:21:09  * bradleymeckjoined
20:24:16  * xiinotulpjoined
20:26:52  * plutoniixquit (Ping timeout: 272 seconds)
20:28:32  * rendarquit (Ping timeout: 256 seconds)
20:29:01  <trungl-bot>Tree closed by buildbot@chromium.org: Tree is closed (Automatic: "Test262 - no variants" on http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/485 "V8 Win32 - debug" from 271f68ba026d252753ca9b2c947f4807b473cd08: alph@chromium.org)
20:34:05  <trungl-bot>Tree opened by machenbach@chromium.org: open
20:34:14  * daviquit (Remote host closed the connection)
20:34:28  * rendarjoined
20:37:10  * lmkmplmjoined
20:39:29  * s1wjoined
20:39:52  * s1wchanged nick to Guest72371
20:47:46  * C-Manquit (*.net *.split)
20:47:50  * Guest51729quit (*.net *.split)
20:47:50  * ErikCorry_quit (*.net *.split)
20:47:50  * phpnodequit (*.net *.split)
20:49:38  * ErikCorry_joined
21:00:49  * phpnodejoined
21:09:22  * watildejoined
21:10:18  * davijoined
21:10:18  * daviquit (Changing host)
21:10:18  * davijoined
21:41:14  * bradleymeckquit (Quit: bradleymeck)
21:52:53  * bradleymeckjoined
22:01:26  * daviquit (Ping timeout: 240 seconds)
22:03:19  * saper_changed nick to saper
22:14:38  * watildequit (Ping timeout: 276 seconds)
22:26:23  * bradleymeckquit (Quit: bradleymeck)
22:32:32  * RT|Chatzillajoined
22:34:37  * bradleymeckjoined
23:10:08  * kenansul-quit (Read error: Connection reset by peer)
23:10:31  * kenansulaymanjoined
23:10:42  * watildejoined
23:10:54  * kenansulaymanchanged nick to Guest20356
23:15:56  * watildequit (Ping timeout: 240 seconds)
23:17:59  * lerelaquit (Quit: Leaving)
23:24:56  * seventhjoined
23:50:58  * seventhquit (Ping timeout: 240 seconds)
23:51:03  * xaxxonjoined
23:52:01  <xaxxon>jgi did you see the posting? turns out all of V8 is built with -fno-exceptions so any exception thrown through its code will cause the program to exit immediately... so in my code, I just catch all exceptions before it returns to V8 and wrap it in an isolate->ThrowException to be caught by a TryCatch on the backside
23:52:30  <xaxxon>also TryCatch and isolate->ThrowException have nothing to do with C++ exceptions... it's a completely proprietary exception system
23:59:55  <jgi>xaxxon: yes, I saw that for -fno-exceptions, thanks! As for TryCatch and Isolate::ThrowException having nothing to do with C++ exceptions, that’s exactly what I was describing last night :)