00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:05:29  <MI6>nodejs-master-windows: #313 UNSTABLE windows-x64 (19/642) windows-ia32 (19/642) http://jenkins.nodejs.org/job/nodejs-master-windows/313/
00:09:14  * bnoordhuisquit (Ping timeout: 264 seconds)
00:09:39  <MI6>libuv-master-gyp: #155 UNSTABLE windows-x64 (3/194) windows-ia32 (4/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/155/
00:10:07  * mikealquit (Quit: Leaving.)
00:12:16  * mikealjoined
00:13:19  * kazuponquit (Read error: Connection reset by peer)
00:13:46  * kazuponjoined
00:29:49  * tjholowaychukquit (Quit: Leaving...)
00:30:31  * kazuponquit (Remote host closed the connection)
00:42:13  * dshaw_quit (Ping timeout: 246 seconds)
00:45:35  * defunctzombie_zzchanged nick to defunctzombie
00:46:47  * tjholowaychukjoined
00:50:05  * hzquit
00:51:16  * kazuponjoined
01:07:32  * kazuponquit (Remote host closed the connection)
01:27:30  * abraxasjoined
01:39:27  * dshaw_joined
01:48:38  * st_lukejoined
01:55:08  * kazuponjoined
01:55:18  * roxluquit (Ping timeout: 256 seconds)
01:56:23  * roxlujoined
01:57:18  * AvianFluquit (Remote host closed the connection)
01:59:45  * kazuponquit (Remote host closed the connection)
02:02:15  * st_lukequit (Read error: Connection reset by peer)
02:02:43  * st_lukejoined
02:08:15  * AvianFlujoined
02:31:38  * tjholowaychukquit (Quit: Linkinus - http://linkinus.com)
03:16:45  <MI6>joyent/node: isaacs master * 906a175 : process: Add internal _rawDebug() method (+1 more commits) - http://git.io/TdidsQ
03:16:48  <isaacs>trevnorris: landed process._rawDebug ^
03:21:41  * LOUDBOTquit (Ping timeout: 248 seconds)
03:23:03  * LOUDBOTjoined
03:26:29  <MI6>nodejs-master: #521 UNSTABLE linux-ia32 (1/643) smartos-x64 (6/643) linux-x64 (1/643) http://jenkins.nodejs.org/job/nodejs-master/521/
03:50:45  <MI6>nodejs-master-windows: #314 UNSTABLE windows-x64 (18/643) windows-ia32 (19/643) http://jenkins.nodejs.org/job/nodejs-master-windows/314/
04:09:11  * kazuponjoined
05:01:23  * st_lukequit (Remote host closed the connection)
05:02:33  * kazuponquit (Read error: Connection reset by peer)
05:02:46  * kazuponjoined
05:36:11  * AvianFluquit (Remote host closed the connection)
05:42:18  * st_lukejoined
05:51:01  <trevnorris>ircretary: tell bnoordhuis I added that for every malloc. saw it done like that in v8 so followed suit.
05:51:01  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
06:09:03  * csaohjoined
06:14:39  * csaohquit (Quit: csaoh)
06:28:54  <trevnorris>i'm getting so many test failures right now it's sort of ridiculous
06:41:59  * rendarjoined
06:42:03  <MI6>nodejs-v0.10-windows: #189 UNSTABLE windows-x64 (8/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/189/
06:50:46  * defunctzombiechanged nick to defunctzombie_zz
06:52:51  * wolfeidauquit (Remote host closed the connection)
06:53:05  * wolfeidaujoined
06:53:15  * wolfeidauquit (Remote host closed the connection)
06:57:49  * defunctzombie_zzchanged nick to defunctzombie
07:04:19  * defunctzombiechanged nick to defunctzombie_zz
07:09:36  * st_lukequit (Remote host closed the connection)
07:12:47  * bajtosjoined
07:17:18  * abraxasquit (Remote host closed the connection)
07:26:06  * wolfeidaujoined
07:28:43  * dominictarrjoined
07:36:35  * abraxasjoined
07:39:11  * tooxiejoined
07:49:24  * wolfeidauquit (Remote host closed the connection)
07:51:48  * wolfeidaujoined
07:57:39  * dominictarrquit (Quit: dominictarr)
08:01:57  * bnoordhuisjoined
08:04:46  * csaohjoined
08:05:08  * tooxiequit (Ping timeout: 245 seconds)
08:16:18  * groundwaterquit (Quit: groundwater)
08:22:24  * dominictarrjoined
08:29:40  * hzjoined
09:15:17  * inolenjoined
09:17:40  <trevnorris>bnoordhuis: sup
09:18:14  * bnoordhuisquit (Ping timeout: 240 seconds)
09:28:22  * bnoordhuisjoined
09:42:55  * bnoordhuisquit (Ping timeout: 245 seconds)
10:03:15  * wolfeidauquit (Remote host closed the connection)
10:17:30  * rendarquit (Ping timeout: 245 seconds)
10:18:47  * rendarjoined
10:29:01  * kazuponquit (Remote host closed the connection)
10:34:47  * abraxasquit (Remote host closed the connection)
10:36:08  * rendarquit (Ping timeout: 298 seconds)
10:45:28  * rendarjoined
10:45:55  <MI6>nodejs-v0.10: #1461 UNSTABLE osx-ia32 (1/598) smartos-x64 (2/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1461/
10:52:45  * csaohquit (Quit: csaoh)
11:02:49  * aldobeejoined
11:22:07  * csaohjoined
11:41:24  * wolfeidaujoined
11:41:52  * bajtosquit (Quit: bajtos)
11:48:03  * rendarquit (Ping timeout: 245 seconds)
13:22:21  * bajtosjoined
13:50:43  * kevinswiberjoined
13:52:35  * julianduquequit (Quit: leaving)
13:53:43  * c4milojoined
13:53:48  * c4miloquit (Remote host closed the connection)
13:53:54  * c4milojoined
14:06:33  * jmar777joined
14:06:34  * c4miloquit (Remote host closed the connection)
14:06:37  * philipsquit (Read error: Connection reset by peer)
14:07:51  * philipsjoined
14:25:55  * kazuponjoined
14:36:25  * swajjoined
14:36:27  * swajquit (Changing host)
14:36:27  * swajjoined
14:37:03  * groundwaterjoined
14:41:58  * AvianFlujoined
14:42:26  * AvianFlu_joined
14:42:33  * rendarjoined
14:43:37  * AvianFluquit (Disconnected by services)
14:43:39  * AvianFlu_changed nick to AvianFlu
14:53:57  * tjholowaychukjoined
15:06:29  * hzquit (Disconnected by services)
15:06:35  * hzjoined
15:12:44  * mikeal1joined
15:13:35  * mikealquit (Ping timeout: 256 seconds)
15:16:09  * piscisaureus_joined
15:17:32  <MI6>nodejs-master: #522 UNSTABLE linux-ia32 (1/643) smartos-x64 (7/643) linux-x64 (1/643) http://jenkins.nodejs.org/job/nodejs-master/522/
15:18:52  * tuxie_joined
15:21:03  * mikeal1quit (Quit: Leaving.)
15:21:42  * piscisaureus_quit (Ping timeout: 264 seconds)
15:21:51  * mikealjoined
15:32:17  * bajtosquit (Quit: bajtos)
15:40:44  <indutny>hey people
15:40:45  <indutny>so long
15:41:34  <tjfontaine>so long?
15:43:12  <indutny>ouch
15:43:15  <tuxie_>that's what she said ^___^
15:43:16  <indutny>not exactly what I meant
15:44:05  <tuxie_>a little late =/
15:46:55  * groundwaterquit (Quit: groundwater)
15:50:03  * dominictarrquit (Quit: dominictarr)
15:50:59  <isaacs>hola
15:51:35  <tjfontaine>hello from burbank california.
15:52:52  * c4milojoined
15:54:47  * groundwaterjoined
15:56:28  <isaacs>tjfontaine: whoa, how's burbank?
15:56:45  <tjfontaine>fine, I wasn't supposed to be here this long
15:56:51  <tjfontaine>but SFO cancelled my flight last night
15:56:55  <isaacs>oh, that sucks
15:57:10  <isaacs>ok, i'm heading to a room for cal
15:57:12  <isaacs>*call
16:00:03  <isaacs>indutny, bnoordhuis, sblom: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:02:36  * bajtosjoined
16:02:50  * bnoordhuisjoined
16:03:00  * sblomjoined
16:03:05  <isaacs>bnoordhuis: http://en.wikipedia.org/wiki/Cinque_Terre
16:03:07  <isaacs>sblom: http://en.wikipedia.org/wiki/Cinque_Terre
16:03:12  * piscisaureus_joined
16:05:00  <isaacs>trevnorris: http://en.wikipedia.org/wiki/Cinque_Terre
16:05:07  <isaacs>er, trevnorris: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:05:10  <isaacs>sorry, wrong url :)
16:08:03  * kevinswiberquit (Remote host closed the connection)
16:13:06  * dapjoined
16:15:34  * bradleymeckjoined
16:17:28  * c4miloquit (Remote host closed the connection)
16:20:58  * hzquit
16:22:26  * groundwaterquit (Quit: groundwater)
16:24:41  <rendar>isaacs, lol, have you been to cinque terre? :)
16:25:01  <isaacs>rendar: no, but i will be in a few weeks
16:25:11  <rendar>thats great!
16:25:29  <rendar>unfortunately its pretty far from where i live
16:31:27  * c4milojoined
16:35:22  <othiym23>isaacs: that looks like a rad place to be, super jelly
16:37:24  * CoverSlidejoined
16:39:39  * TooTallNatejoined
16:42:47  * csaohquit (Quit: csaoh)
16:48:46  <indutny>:)
16:52:38  * ecrjoined
16:56:18  * dominictarrjoined
16:58:35  * brsonjoined
17:01:09  <trevnorris>tiny pr for anyone to review https://github.com/joyent/node/pull/6172
17:01:13  <trevnorris>doesn't affect multi-context :)
17:02:29  <isaacs>trevnorris: lgtm
17:02:43  <trevnorris>isaacs: thanks :)
17:03:28  <isaacs>bnoordhuis: are you rebasing onto master, or got a PR i can review?
17:04:04  <bnoordhuis>rebasing
17:04:10  * AvianFluquit (Remote host closed the connection)
17:04:28  * defunctzombie_zzchanged nick to defunctzombie
17:05:17  * mikealquit (Quit: Leaving.)
17:06:01  * defunctzombiechanged nick to defunctzombie_zz
17:06:22  <MI6>joyent/node: Trevor Norris master * 7a235f9 : string_bytes: use extern for length and write utf8 - http://git.io/Lm22qg
17:07:19  * hzjoined
17:08:58  <trevnorris>isaacs: so, strange problem. I wrote tests for the async listener. their not passing, because their detecting too many async events.
17:09:12  <trevnorris>isaacs: and it's been a pain to track down where their coming from :P
17:09:24  <trevnorris>*they're
17:10:14  <trevnorris>though _rawDebug is making that much easier :)
17:11:07  * AvianFlujoined
17:12:22  <bnoordhuis>https://github.com/joyent/node/pull/6173 <- multi-context
17:12:43  <trevnorris>man you rebased that quickly
17:12:45  <bnoordhuis>trevnorris: btw, you had a fix for that timer test that's failing right?
17:13:00  <trevnorris>bnoordhuis: yeah. https://github.com/trevnorris/node/commit/1308170150abc4198004e2ba2bca26971e2e3571
17:13:00  <tjfontaine>which timer test?
17:13:22  <bnoordhuis>ah right, that was it
17:13:50  <trevnorris>tjfontaine: just had to do when they required('domain') in the middle of an async call
17:14:11  <bnoordhuis>guess i should just fix that and force-push
17:14:12  <tjfontaine>ah
17:14:21  <trevnorris>sounds good to me
17:15:49  <indutny>piscisaureus_: I've an idea
17:16:01  <indutny>strongloop node "extra support" edition
17:16:07  <trevnorris>bnoordhuis: still getting failing test-debug-port-from-cmdline and test-debug-signal-cluster. i'll look into those.
17:16:07  <indutny>basically node 0.12 RC
17:16:21  <isaacs>trevnorris: don't tie your tests to a specific number of async events, i'd think.
17:16:24  <indutny>if advertised properly - we can make it out
17:16:34  <isaacs>trevnorris: just set some minimum, and make sure it's at least as many as you expect, and not, like 10x as much
17:17:27  <bnoordhuis>trevnorris: yeah, those tests are not exactly bad tests but they depend a little too much on the exact order of things at startup
17:17:38  <trevnorris>bnoordhuis:
17:17:38  <trevnorris>src/node.cc:2716: Using sizeof(type). Use sizeof(varname) instead if possible [runtime/sizeof] [1]
17:17:39  <trevnorris>src/node.cc:2721: Using sizeof(type). Use sizeof(varname) instead if possible [runtime/sizeof] [1]
17:18:00  <indutny>piscisaureus_: thoughts?
17:18:12  <indutny>trevnorris: sizeof(*val) ?
17:18:27  <bnoordhuis>trevnorris: oh, i didn't lint it yet :)
17:18:31  <trevnorris>:)
17:18:33  <indutny>aah, that's yours ben :)
17:18:39  <piscisaureus_>indutny: prefer sizeof(varname) usually. What's your question?
17:18:42  * groundwaterjoined
17:18:51  <piscisaureus_>in fact I'd use `sizeof varname`
17:18:55  <indutny>piscisaureus_: what do you think about strongloop node "extra support" edition
17:19:03  <indutny>piscisaureus_: good idea for your business ;)
17:19:20  <piscisaureus_>indutny: what do you mean with "extra support edition"
17:19:27  <indutny>piscisaureus_: basically 0.12 RC with limited time free extra support edition
17:19:37  <indutny>with me and probably others from core team helping out people
17:19:47  <indutny>basically, what we usually do, but in an another manner
17:19:51  * tuxie_quit (Ping timeout: 260 seconds)
17:19:57  <indutny>and at another scale, hopefuly
17:20:08  <MI6>nodejs-master: #523 UNSTABLE linux-ia32 (1/643) smartos-x64 (12/643) smartos-ia32 (4/643) linux-x64 (1/643) http://jenkins.nodejs.org/job/nodejs-master/523/
17:20:50  <piscisaureus_>indutny: interesting idea but I need to have some backoffice discussion about that.
17:21:10  <indutny>cool
17:21:12  <piscisaureus_>indutny: also, you could be into it but it's questionable to what extent it'd work for isaac, trevnorris etc
17:21:27  <indutny>well, I'm not saying its implied
17:21:36  <indutny>just whoever wants to help - should be able to
17:22:58  * bradleymeckquit (Quit: bradleymeck)
17:23:42  <piscisaureus_>indutny: I'll let you know. I have to think whether/how it could be made to work.
17:24:25  <indutny>thanks for listening :)
17:24:29  * bradleymeckjoined
17:24:53  * defunctzombie_zzchanged nick to defunctzombie
17:25:19  <piscisaureus_>:)
17:25:23  <piscisaureus_>you're welcome
17:25:25  <piscisaureus_>listening is easy
17:25:39  <piscisaureus_>However I am super hungry and getting some foot. bbl
17:25:47  <piscisaureus_>*food
17:25:53  <piscisaureus_>Not a cannibal yet
17:26:00  <indutny>ttyl
17:26:39  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:27:53  <trevnorris>bnoordhuis: i'd really like if Object's had a super cheap way of storing flags. just like a uint32_t field on the v8 Object class.
17:28:21  <trevnorris>bnoordhuis: then it's be super cheap to store random tidbits of things, like if there's specific data on the object we need to grab.
17:28:58  <bnoordhuis>trevnorris: alas, there isn't except maybe SetIndexedPropertiesToExternalArrayData()
17:29:33  <trevnorris>bnoordhuis: yeah. problem is that takes just enough time to make it not as useful as it could be. :(
17:29:51  <trevnorris>I hate you EAI!
17:30:03  <bnoordhuis>oh, that's trivial to fix
17:30:10  <bnoordhuis>it makes me kind of say though
17:30:34  <MI6>nodejs-master-windows: #315 UNSTABLE windows-x64 (19/643) windows-ia32 (19/643) http://jenkins.nodejs.org/job/nodejs-master-windows/315/
17:30:56  * dshaw_quit (Ping timeout: 246 seconds)
17:31:22  * kevinswiberjoined
17:32:45  * kevinswiberquit (Remote host closed the connection)
17:34:20  * isaacsreviewing multi-context in earnest...
17:35:32  * kevinswiberjoined
17:36:18  <MI6>joyent/libuv: Ben Noordhuis master * f3f23b2 : unix: define _GNU_SOURCE, exposes glibc-isms - http://git.io/cRxegg
17:36:26  <bnoordhuis>trevnorris: ^
17:36:33  <trevnorris>YEAH!!!
17:36:37  <trevnorris>:)
17:36:41  <isaacs>bnoordhuis: so, why "_inl" and not "_impl"
17:36:46  <isaacs>bnoordhuis: i keep reading that as "inline"
17:37:34  <trevnorris>bnoordhuis: also you asked about the FatalError stuff? just curious, or something up?
17:38:05  <bnoordhuis>trevnorris: oh, just wondering why you didn't use __func__?
17:38:28  * trevnorrisoff googling __func__
17:39:14  <bnoordhuis>isaacs: you mean the file name, as in env-inl.h? i copied that from v8
17:39:24  <bnoordhuis>and libuv
17:40:00  <isaacs>oh, fair enough then
17:40:04  <isaacs>yeah, that's how they do it, too
17:40:16  <indutny>tjfontaine: hm… can't start a build from the web interface...
17:40:22  <indutny>tjfontaine: should I update extension?
17:40:36  <tjfontaine>indutny: actually...
17:40:38  <indutny>actually
17:40:45  <indutny>it seems that server is just replying with 500
17:40:46  <tjfontaine>it's a stale api key
17:40:54  <indutny>{"message":"Jenkins status code 401"}
17:40:56  <indutny>ooh
17:41:00  <indutny>how can I renew it?
17:41:14  <trevnorris>bnoordhuis: ah, wtf. that would've been great. I just followed v8 (i.e. they pass the full thing as a string)
17:41:30  <trevnorris>e.g. http://git.io/rSaXgw
17:42:17  <indutny>tjfontaine: ?
17:42:19  <tjfontaine>indutny: fixing
17:42:27  <bnoordhuis>now that i think of it... it's probably because msvc calls it __FUNCTION__ iirc
17:42:55  <bnoordhuis>easy to work around though: #ifdef _WIN32 #define __func__ __FUNCTION__ #endif
17:43:26  <MI6>libuv-master-gyp: #156 UNSTABLE windows-x64 (3/194) windows-ia32 (4/194) smartos-ia32 (2/193) linux-ia32 (1/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/156/
17:43:55  <bnoordhuis>__func__ is a c99-ism and we all know how MS feels about c99
17:44:16  <trevnorris>heh
17:44:40  <isaacs>bnoordhuis: is there any API change in this stuff?
17:45:17  <bnoordhuis>isaacs: on the c++ or js side of things?
17:45:32  <MI6>libuv-master: #217 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/217/
17:47:32  <tjfontaine>blah it won't let me recreate you
17:47:44  <isaacs>bnoordhuis: on the js side of things
17:47:49  <isaacs>bnoordhuis: ie, how would one actually use this?
17:48:53  <bnoordhuis>isaacs: you don't currently, not from js. you can start scripts in separate contexts from the command line
17:49:48  <isaacs>also this bit: + // FIXME(bnoordhuis) This should fetch the Environment from the Context
17:49:51  <isaacs>+ // where the object lives in, which may be different from the _current_
17:49:54  <isaacs>+ // context.
17:50:14  <isaacs>bnoordhuis: it'd be good to actually fix that, or else it seems like a landmine waiting to happen
17:50:53  <bnoordhuis>isaacs: yeah, agreed. only that's not really possible with the current v8 api
17:51:11  * c4miloquit (Remote host closed the connection)
17:51:22  * c4milojoined
17:51:32  <bnoordhuis>there's currently no function or method that tells you what context an object belongs to
17:52:07  <isaacs>hm. ok.
17:52:27  <bnoordhuis>on a different subject, i did some half-hearted attempt at isolate-ifying NODE_SET_METHOD and NODE_SET_PROTOTYPE_METHOD that i'll probably back out
17:52:54  <bnoordhuis>iow, please ignore any NODE_SET_METHOD(isolate, ...) changes
17:53:03  <tjfontaine>indutny: ok try again, your api key should be ok now
17:53:38  <isaacs>k
17:53:52  <isaacs>bnoordhuis: how do you run scripts in separate contexts fro the cli?
17:55:18  * dshaw_joined
17:55:32  <tjfontaine>--context='path/to/script.js arg1 arg2 etc'
17:55:34  <bnoordhuis>isaacs: did you read the PR description? :-)
17:55:36  <tjfontaine>it seems?
17:55:52  <isaacs>oh, no, i just went straight to the code :)
17:56:11  <trevnorris>heh, you weren't kidding about using for (;;)
17:56:59  <isaacs>this is a kinda strange API
17:57:17  <bnoordhuis>it's not final. i just needed something to test with
17:57:29  <indutny>tjfontaine: thanks
17:57:31  <isaacs>bnoordhuis: yeah. so,i take it that's why there's all this tokenize/unescape stuff?
17:57:36  <bnoordhuis>yes
17:57:41  <indutny>tjfontaine: seems to be working!
17:58:00  <tjfontaine>indutny: excellent
18:00:02  * inolenquit (Quit: Leaving.)
18:00:22  <tjfontaine>bbiab, getting some brunch, then to the airport
18:00:40  <isaacs>bnoordhuis: yeah, i understnd the need to have something to test with. but i'm emphatically -1 on this api approach. embedding command lines in command lines is notoriously problematic.
18:00:55  <bnoordhuis>okay. what do you do propose?
18:01:01  * mikealjoined
18:01:02  <bnoordhuis>err, -1 do
18:01:10  <isaacs>yeah, that's where i'm puzzling over.
18:01:51  <isaacs>i mean, if we want to actually have a completely separate argv etc, it almost feels reasonable to mimic the spawn() api
18:02:00  <isaacs>a la isolates
18:02:04  <bnoordhuis>ah, right
18:02:06  <isaacs>however, it's not actually a child process.
18:02:20  <isaacs>and it sort of seems like something that could live happily on require('vm')
18:02:28  <bnoordhuis>so... the reason i did it like this is that creating contexts from js land is problematic when security tokens are involved
18:02:33  <isaacs>right
18:03:00  <isaacs>if you pass in a different security token, then you can't look at the results of the script
18:03:06  <isaacs>or manage who can see what.
18:03:09  <bnoordhuis>well, that
18:03:26  <bnoordhuis>but also, you can't populate the new context with a custom global object, for example
18:03:32  <isaacs>right
18:03:45  <isaacs>it can't look at any objects that you might pass in
18:03:51  <isaacs>which makes it feel more like spawn
18:04:05  <isaacs>even though it's not an actual child process with a separate pid/signals/etc
18:04:19  <bnoordhuis>right
18:04:26  <isaacs>vm.spawn()?
18:05:10  <isaacs>vm.spawn({stuff that will be copied}, [securityToken])?
18:05:24  <isaacs>hm....
18:05:51  <isaacs>i mean, i realize that this is like the most minor surface bit of this change, and it's a very deep change.
18:06:21  <isaacs>most of it looks fine. it's pretty big, so we'll probably find bugs by actually hitting them, but as far as i can tell, the actual mechanics of it are good, and a net improvement all over the codebase.
18:06:27  <isaacs>very much +1 on all that stuff.
18:06:37  * inolenjoined
18:09:44  * inolenquit (Client Quit)
18:09:59  <bnoordhuis>hm, seems i can get the object's context after all. okay, nice, i'll address that FIXME
18:11:36  * mikealquit (Quit: Leaving.)
18:11:41  <trevnorris>bnoordhuis: specific reason to move stuff from node_internal to util? just curious
18:12:14  <bnoordhuis>trevnorris: node_internals.h was getting rather unwieldy
18:13:08  <bnoordhuis>i decided to move stuff rather than tack on more
18:13:31  <bnoordhuis>but i later gutted node_internals.h in master so it's not as dramatic anymore
18:14:39  * mikealjoined
18:21:48  <trevnorris>coolio
18:23:57  <isaacs>bnoordhuis: the dlopen issue, also seems like a landmine
18:24:53  <bnoordhuis>yeah. i'm undecided so far on what to do with it
18:25:58  <bnoordhuis>'first one to load wins' seems easiest
18:26:05  <isaacs>hm.
18:26:11  <bnoordhuis>and then bug add-on authors to make their modules context-aware
18:26:34  <isaacs>that's going to be a problem if you want to have multiple workers doing some stuff with a binary addon
18:26:40  <isaacs>which doesn't seem that strange to want to do
18:26:56  <isaacs>but i guess, yeah, module authors just have to deal with it
18:27:41  <isaacs>it seems like a lot of ExecutionContext can be removed if we have a js interface to this stuff.
18:28:02  <bnoordhuis>it's pretty easy for an add-on author btw, s/he just needs to use the NODE_MODULE_CONTEXT_AWARE macro and be prepared to deal with multiple init calls
18:28:10  <isaacs>eg, what if it looked more like web workers, and less like a whole new process?
18:28:15  <isaacs>true that
18:28:31  <isaacs>ok, dlopen can remain a FIXME, or probably just be fixed with docs.
18:30:12  * c4miloquit (Remote host closed the connection)
18:33:42  <TooTallNate>does node automatically use the dns servers on OSX's Network->Advanced->DNS tab?
18:34:49  <bnoordhuis>TooTallNate: if libc's getaddrinfo() function does
18:35:01  <bnoordhuis>(it should)
18:35:15  <TooTallNate>ya that's what i thought
18:35:17  <TooTallNate>thanks bnoordhuis
18:38:04  <othiym23>bnoordhuis, isaacs: is there a bug or something somewhare that explains the motivation behind multi-context?
18:38:07  * hzquit
18:38:29  <trevnorris>othiym23: github is paying ben to implement it. and it's "more correct" way of doing things.
18:38:34  * AvianFluquit (Remote host closed the connection)
18:38:37  * kazuponquit (Remote host closed the connection)
18:38:40  <trevnorris>bnoordhuis: this will probably sound ridiculous, but would it be possible to create a class that inherits from v8::Object and adds the flags field I'm looking for.
18:39:05  <othiym23>I guess I can wait until the final API for interacting with it lands
18:39:22  <trevnorris>bnoordhuis: and still treat it as a v8::Object, but static_cast and grab the flags I'm looking for?
18:39:47  <othiym23>it looks like a re-emergence of the old isolate stuff, which could be super useful, but I'm confused by the fact that it doesn't have much to do with the contextify stuff Domenic_ was working on
18:40:06  <bnoordhuis>trevnorris: well... not easily
18:40:30  * EhevuTovjoined
18:40:37  <bnoordhuis>othiym23: it's basically the prequel to isolates reloaded
18:40:49  * AvianFlujoined
18:41:11  <trevnorris>bnoordhuis: bummer. it would just be used for the ReqWrap object created on request
18:41:31  <trevnorris>that would make all this soooo much easier.
18:41:51  <bnoordhuis>trevnorris: then why don't you store that information in the ReqWrap?
18:42:06  <bnoordhuis>maybe i'm misunderstanding what you're trying to do
18:42:47  <trevnorris>bnoordhuis: because I need to get the data in MakeCallback, which only passes the object. but, guess I could create a version of MakeCallback that accepts a flag.
18:43:29  <bnoordhuis>othiym23: what Domenic_ was working on is plain contexts, i.e. running code in a sandbox. multi-context is like that but it integrates with the event loop
18:43:42  <Domenic_>i am curious about the connection here too
18:43:48  <bnoordhuis>othiym23: e.g. i/o callbacks know what context they belong to
18:43:59  <othiym23>right, but doesn't that more or less mean that the two together could expose an API a lot like web workers?
18:44:07  <bnoordhuis>yes
18:44:35  <othiym23>that would be sweet
18:44:54  <bnoordhuis>trevnorris: yeah, maybe a ReqWrap::MakeCallback() method that's smart about things
18:44:55  <Domenic_>bnoordhuis: so, they don't know already? e.g. if I do `vm.runInNewContext('fs.readFile("x.txt", function (err, result) { })')` what will happen?
18:45:16  <trevnorris>bnoordhuis: awesome. thanks for the idea.
18:45:43  <bnoordhuis>Domenic_: it works because both contexts share the same security token (or rather, they both don't have one)
18:46:05  <Domenic_>bnoordhuis: hmm ok, so what does the multi-context work do then?
18:46:24  <bnoordhuis>let you set security tokens :)
18:46:56  <bnoordhuis>basically, each context is now a more or less standalone node process
18:47:43  <bnoordhuis>the use case is e.g. embedding node in a browser where each tab runs in a separate context
18:48:32  <MI6>nodejs-master-windows: #316 UNSTABLE windows-x64 (17/643) windows-ia32 (20/643) http://jenkins.nodejs.org/job/nodejs-master-windows/316/
18:50:42  <trevnorris>bnoordhuis: except one context will block the others, right?
18:51:00  * c4milojoined
18:53:25  <bnoordhuis>trevnorris: yeah, there's no pre-emptive scheduling going on
18:53:37  <bnoordhuis>everything still runs in a single thread
19:11:56  * tjholowaychukquit (Quit: Linkinus - http://linkinus.com)
19:12:00  * Apage43part
19:13:07  <othiym23>I am keenly curious to see what GitHub ends up doing with this ;)
19:13:20  * bajtosquit (Quit: bajtos)
19:21:20  <austo>bnoordhuis: in one of your demos, you used a static buffer to handle stream read allocations because they never overlap... is that always true for, say, a tcp stream?
19:23:29  <bnoordhuis>austo: for a single tcp handle, yes, but not when you have multiple
19:24:22  <bnoordhuis>or maybe i should say "not on windows"
19:25:34  <austo>not a problem for the moment :)
19:26:14  <bnoordhuis>trevnorris: i was wrong about the debugger tests, the bug was mine. mea culpa
19:27:33  <trevnorris>bnoordhuis: :)
19:27:55  * dshaw_quit (Quit: Leaving.)
19:28:09  * dshaw_joined
19:28:22  <indutny>bnoordhuis: yt?
19:28:44  <indutny>I've a question for you :)
19:28:52  <indutny>how would you refactor https://github.com/indutny/mine.uv/blob/master/src/anvil.c#L222 if it was your code?
19:29:20  <bnoordhuis>hah
19:29:34  <bnoordhuis>it's an array of array of arrays?
19:30:19  <bnoordhuis>or at least some multi-dimensional data structure?
19:30:41  <indutny>yes
19:30:48  <indutny>three dimensional array
19:30:56  <indutny>this code is so… nested
19:31:16  <indutny>actually, I refactored it a bit
19:31:19  <indutny>please refresh
19:31:24  <bnoordhuis>is there a performance issue or is it an aesthetic thing?
19:31:46  <indutny>oops, forgot to push
19:31:55  <indutny>bnoordhuis: this shit is totally unreadable :)
19:32:00  <indutny>aesthetic
19:32:28  <indutny>mostly :)
19:33:01  <bnoordhuis>well, you could flatten the array
19:33:29  <bnoordhuis>if you reorder your data, you could probably process it in chunks, rather than one at a time
19:33:58  <bnoordhuis>what kind of thing is a mchunks->blocks?
19:34:47  <indutny>one sec
19:35:01  <indutny> mc_block_t blocks[16][16][16];
19:35:07  <indutny>that's mc_chunk_t
19:35:23  <bnoordhuis>wait, let me clone it and ctags it
19:35:35  <bnoordhuis>hey, it's pretty big. what are you storing in there?
19:36:30  <indutny>minecraft blocks
19:36:32  <indutny>its really big
19:36:42  <indutny>but I see no other way of doing it
19:36:52  <indutny>considering that I'll be doing in-memory updates of contents
19:36:59  <indutny>and then periodically saving it to file
19:37:02  <bnoordhuis>right
19:37:52  <bnoordhuis>okay, so you have 4096 blocks in total, right?
19:38:16  <indutny>in one chunk
19:38:21  <indutny>and 16 chunks for one column
19:38:31  <indutny>and 1024 columns per region
19:38:38  <indutny>so
19:38:42  <indutny>a lot of data :)
19:38:44  <bnoordhuis>yeah
19:39:08  <bnoordhuis>you could deconstruct mc_block_t into its individual fields
19:39:18  <bnoordhuis>wait, let me diff that
19:39:44  <indutny>sure
19:39:44  <indutny>thanks
19:40:24  <bnoordhuis>indutny: https://gist.github.com/bnoordhuis/979c930bc82aad3a103b
19:40:41  <bnoordhuis>i.e. you decompose the struct and then process each field individually
19:40:46  <indutny>oh, well
19:40:58  <indutny>while it'll definitely improve parsing
19:41:05  <indutny>lookup will become much less sanier
19:41:15  <bnoordhuis>helps a great deal with run-time performance though
19:41:16  <indutny>saner*
19:41:21  <indutny>why?
19:41:33  <indutny>won't it spread the cache?
19:41:39  <bnoordhuis>on the contrary
19:42:01  <bnoordhuis>just to make sure we're on the same page
19:42:12  <bnoordhuis>you first process all 4096 ids
19:42:20  <indutny>ah
19:42:21  <bnoordhuis>then all 4096 metadata fields and so on
19:42:24  <indutny>hm...
19:42:28  <indutny>interesting
19:42:47  <indutny>but still it'll spread the cache later
19:42:51  <indutny>when reading from it
19:43:01  <indutny>but thanks for the idea
19:43:01  <bnoordhuis>right, that may well be true
19:43:25  <bnoordhuis>still, that's how most games process graphics data so it can't be all bad :)
19:44:30  <bnoordhuis>indutny: one thing you may want to consider is to flatten the array
19:44:49  <indutny>yeah
19:44:54  <bnoordhuis>the way you're iterating over it now, you're jumping all over memory, i think
19:44:58  * bnoordhuislooks more closely
19:45:07  <indutny>I don't really think so, actually
19:45:24  <indutny>it should be quite sequential right now
19:45:24  * st_lukejoined
19:46:55  * julianduquejoined
19:48:15  <bnoordhuis>you sure? y is the inner loop. the way i read it, you're jumping 32 elements at a time
19:48:35  <bnoordhuis>er, not 32 - 256
19:48:39  <indutny>hm...
19:48:48  <indutny>aaah, right
19:48:51  <indutny>I should store it
19:48:53  <indutny>[x][z][y]
19:48:57  <indutny>that's a good tip
19:48:58  <indutny>thanks
19:49:01  <bnoordhuis>np :)
19:49:27  <indutny>I wonder if it'll affect performance :)
19:49:40  <indutny>right now it takes about 300ms to parse one region
19:49:49  <indutny>mostly because of zlib
19:50:01  <bnoordhuis>is it hot code?
19:50:12  <bnoordhuis>in the sense that it gets called often, i mean :)
19:50:44  <isaacs>bnoordhuis: so, what would be the specific blocker to exposing multi-context as vm.spawn()?
19:51:09  <isaacs>bnoordhuis: i'd like to explore what a js binding to this might look like.
19:51:19  <indutny>bnoordhuis: yeah
19:51:30  <bnoordhuis>isaacs: well, the object/function issue with different security tokens
19:51:35  <indutny>I've another idea for improving it
19:51:40  <indutny>zone allocation for nbt parser
19:51:42  <isaacs>bnoordhuis: or at least, if we simply cannot do it from js, a way that doesn't involve parsing command lines twice.
19:51:52  <indutny>but I think it'll not improve things significantly
19:52:20  <bnoordhuis>isaacs: i'm open to suggestions :)
19:52:31  <bnoordhuis>indutny: have you perf'd it yet?
19:52:37  <indutny>nope
19:52:37  <isaacs>bnoordhuis: so, just so that i understand this,
19:52:44  <indutny>still don't have a linux box
19:52:47  <indutny>I mean
19:52:51  <indutny>non-virtualized linux box
19:52:58  <bnoordhuis>ah, so no PMCs. that sucks
19:52:58  <indutny>but I run it through Instruments.app
19:53:03  <isaacs>bnoordhuis: let's say we had something like var something = vm.spawn(someScriptCodes, filename, someGlobals)
19:53:23  <isaacs>er, vm.spawn(someScriptCodes, filename, someGlobals, securityToken)
19:53:28  * AvianFlu_joined
19:53:32  <isaacs>then the problem is that someGlobals are created with a different security token, yes?
19:53:35  <bnoordhuis>yes
19:53:42  <isaacs>ok. so, let's say you can't pass globals in.
19:53:52  <isaacs>vm.spawn(someScriptCodes, filename, securityToken)
19:54:01  <bnoordhuis>yeah, that works
19:54:05  <isaacs>or even: vm.spawn(filename, securityToken) and it reads the filename and runs it.
19:54:18  <isaacs>or vm.spawn(filename, [some, args], securityToken)
19:54:44  <bnoordhuis>i don't know about reading files directly
19:54:59  <isaacs>it'dbe kinda like child_process.fork() i guess
19:55:00  <bnoordhuis>i predict that the first bug report will be "can't pass source directly"
19:55:05  <isaacs>sure.
19:55:21  <isaacs>vm.runInNewEnvironment(src, filename, token)
19:55:45  <bnoordhuis>something like that
19:56:21  * AvianFluquit (Ping timeout: 248 seconds)
19:56:32  <isaacs>that'd be pretty nice.
19:56:59  <isaacs>and one could trivially do the --context='foo.js arg arg' --security-token='deadbeef' if they wanted.
19:58:20  <bnoordhuis>yes. i'm fine with it, seems like an okay api
19:58:50  <isaacs>ok
19:59:06  <isaacs>lemme play with it a little bit more, and i'll have something that's more concrete to pitch.
19:59:29  <isaacs>i'd prefer to at least have an idea of what that'll be before we land this.
19:59:47  <isaacs>it's ok to land the cli parsing mumbo jumbo and then take it out, but i'm hesitant to let it in if we're not sure how long it'll be there.
19:59:54  <isaacs>that's how things get forgotten :)
20:00:43  <isaacs>bnoordhuis: oh, also, i'm seeing this:
20:00:43  <isaacs>$ ./node --context='foo.js one'
20:00:44  <isaacs>> Assertion failed: (loop->watchers[w->fd] == w), function uv__io_stop, file ../deps/uv/src/unix/core.c, line 677.
20:00:47  <isaacs>Abort trap: 6
20:01:02  * bradleymeckquit (Quit: bradleymeck)
20:02:21  * bradleymeckjoined
20:02:47  <bnoordhuis>oh, i guess i should make it so that you can't start an inferior context without also starting the main context
20:03:12  * bradleymeckquit (Client Quit)
20:03:58  * bajtosjoined
20:05:03  <bnoordhuis>seems to work for me though
20:06:47  <isaacs>bnoordhuis: it also fails if i start a main context
20:06:47  <isaacs>$ ./node --context='foo.js one' --context='foo.js two' foo.js main
20:06:48  <isaacs>main 1378238793692
20:06:48  <isaacs>> Assertion failed: (loop->watchers[w->fd] == w), function uv__io_stop, file ../deps/uv/src/unix/core.c, line 677.
20:06:50  <isaacs>Abort trap: 6
20:06:59  <isaacs>https://gist.github.com/isaacs/6428869
20:07:27  <isaacs>bnoordhuis: could be something specific to timers or stdout writing?
20:07:38  <isaacs>i have not dug into it except to complain to the author in #libuv
20:07:39  <isaacs>:)
20:08:18  <bnoordhuis>weird, it works for me on os x
20:08:35  <bnoordhuis>i did fix a bug 30 minutes ago
20:09:01  <bnoordhuis>can you pull/rebuild and retry?
20:09:12  * kazuponjoined
20:10:01  <bnoordhuis>works on linux too btw
20:11:21  * bajtosquit (Ping timeout: 276 seconds)
20:13:18  <isaacs>sure.
20:13:24  <isaacs>pull from your multi-context branch?
20:13:29  <isaacs>bnoordhuis: ^
20:13:51  <isaacs>From git://github.com/bnoordhuis/node * branch multi-context -> FETCH_HEAD
20:13:54  <isaacs>Current branch multi-context is up to date.
20:13:59  <isaacs>bnoordhuis: i'm on 314d6ac578f8b867ec0e4f0e3d720d8b2600a474
20:15:07  <isaacs>just touched all of deps/uv and src/ and rebuilt. same thing
20:15:12  <bnoordhuis>that's the latest one. well, that's weird
20:16:32  <isaacs>weird. running in gdb works fine.
20:16:40  * kazuponquit (Ping timeout: 264 seconds)
20:17:18  <isaacs>with or without the "main" foo.js script
20:18:30  * kevinswiberquit (Remote host closed the connection)
20:20:04  * hzjoined
20:20:05  <isaacs>bnoordhuis: also, this is kinda... wrong. https://gist.github.com/isaacs/6429018
20:20:39  <isaacs>bnoordhuis: i'd expect that a) it should not enter the repl, and b) process.argv should be [foo.js,one]
20:20:46  <isaacs>er, rather [foo.js, main]
20:21:37  * kevinswiberjoined
20:22:24  <isaacs>that's what the blown asserts commented out
20:23:41  <bnoordhuis>well, it's going away anyway, right?
20:24:22  <isaacs>haha, indeed :)
20:24:35  <isaacs>but i'm just trying to kinda mess around with it as it is now
20:25:09  <isaacs>bnoordhuis: so, these separate context scripts, do they run in parallel?
20:25:14  <bnoordhuis>yes
20:25:17  <isaacs>ie, concurrently
20:25:32  <bnoordhuis>oh, you mean in different threads? no
20:25:52  <bnoordhuis>they share the same event loop and everything runs in the same thread, i.e. sequentially
20:25:56  <isaacs>i see.
20:26:03  <isaacs>but if they both do setTimeout, that gets interleaved?
20:26:07  <bnoordhuis>yes
20:26:19  <isaacs>ok, that's what i thought, but i was just trying to kinda play around with how that would work
20:26:41  <isaacs>i think that's best.
20:27:09  <isaacs>i'd like to not invite any coro-type stuff in this. if you want concurrency, use child processes.
20:27:40  <bnoordhuis>how would you implement that anyway?
20:27:56  <isaacs>yah i don't even know
20:28:06  <isaacs>at least, not in a way that's safe and non-brain-inverting
20:28:31  <isaacs>people get excited by concurrency and tend to think it'll solve all their problems for them
20:28:44  <isaacs>in my experience, it's usually a hazardous approach
20:29:02  <isaacs>maybe i'm just not smart enough to write threaded programs well
20:29:39  <bnoordhuis>threads get to be a headache first
20:29:55  <bnoordhuis>as soon as there's more than one lock or semaphore involved, you know you're in for a rough time
20:29:58  <isaacs>yep
20:30:07  <isaacs>i like processes because then the OS handles all that junk for you
20:30:14  <isaacs>nice crisp separation
20:30:15  <bnoordhuis>er, s/first/fast/ - i guess the context made that clear
20:30:28  <isaacs>i figured that your data just got corrupted by multiple threads :)
20:30:49  <isaacs>the human brain is one of the greatest examples of why concurrent computation is so hazardous
20:30:52  <isaacs>we're a mess.
20:31:07  * jmar777quit (Remote host closed the connection)
20:31:17  <isaacs>anyway... so. let's say we do this:
20:31:46  <isaacs>var result = vm.runInNewEnvironment('"foo"', 'filename', { securityToken: 'deadbeef' })
20:32:03  <isaacs>bnoordhuis: what happens if i try to do console.log(result)
20:33:27  <bnoordhuis>depends on what runInNewEnvironment() returns
20:33:28  * st_lukequit (Remote host closed the connection)
20:33:52  <bnoordhuis>a v8::Context is not a value you can return directly to js land
20:34:20  <bnoordhuis>you could make it some kind of proxy that mutates the global object of the context or whatever
20:34:45  <isaacs>ok. right.
20:35:05  <isaacs>i'd espect that result is the completion value of the script, just ilke vm.runInContext
20:35:49  <bnoordhuis>sure, that works
20:36:07  <bnoordhuis>or rather, i can make that work
20:36:14  <isaacs>so, another aproach would be to make this a flag we pass to vm.runInContext
20:36:54  <isaacs>vm.runInContext(src, file, vm.createContext({some:'stuff'}, securityToken), { nodeEnvironment: true })
20:37:46  <isaacs>i mean, the stuff that you did in multi-context is not necessarily tied to securityToken, really, right? it's more about enabling a *node* environment in a separate context.
20:37:51  <bnoordhuis>yes
20:38:01  <bnoordhuis>the security token thing is just icing on the cake
20:38:55  <isaacs>so, what if we put security tokens and/or security callbacks into vm.createContext
20:39:08  <isaacs>where the default is to use the security token of the current context.
20:40:06  <isaacs>var ctx = vm.createContext({some:'stuff'}, {nodeEnvironment: true, securityToken: 'deadbeef', securityCallback: shouldAllow})
20:40:30  <isaacs>so that's kinda like the contextify stuff we have now, except, if it's a different security token, then you cna't actually see the changes?
20:40:33  <isaacs>hmm....
20:43:26  * kazuponjoined
20:44:18  * wolfeidauquit (Remote host closed the connection)
20:44:26  * wolfeidaujoined
20:47:27  * st_lukejoined
20:48:05  * kazuponquit (Ping timeout: 248 seconds)
21:17:25  * sblomquit (Ping timeout: 248 seconds)
21:26:09  * AvianFlu_changed nick to AvianFlu
21:41:27  * c4miloquit (Remote host closed the connection)
21:44:18  * kazuponjoined
21:47:15  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:47:15  * sblomjoined
21:47:59  * EhevuTovquit (Quit: This computer has gone to sleep)
21:48:07  * rendarquit (Quit: Leaving)
21:49:18  * kazuponquit (Ping timeout: 264 seconds)
21:50:35  * EhevuTovjoined
21:52:56  <trevnorris>bnoordhuis: i'm not familiar with the internals of C++ classes, but in req_wrap there's a line that T req_; must be last, but then there're some private members declared underneath.
21:53:07  <trevnorris>so i'll assume those don't count as coming after the "last"
21:54:23  * bnoordhuisquit (Ping timeout: 260 seconds)
21:55:13  * kenperkinsjoined
22:00:51  * tooxiejoined
22:07:51  * kevinswiberquit (Remote host closed the connection)
22:11:32  * AvianFluquit (Remote host closed the connection)
22:37:24  * hzquit
22:41:34  * bradleymeckjoined
22:42:49  * kenperkinsquit (Quit: Computer has gone to sleep.)
22:43:20  <trevnorris>anyone know how to get the ConnectWrap* out of the uv_stream_t* handle in TCPWrap?
22:43:43  * bradleymeckquit (Client Quit)
22:44:07  * kenperkinsjoined
22:44:17  <trevnorris>or basically, is the uv_connect_t* somehow attached to the uv_stream_t*? I can't find it
22:44:50  * kazuponjoined
22:49:02  <tjfontaine>trevnorris: it's not really stored on the tcpwrap, it's kinda ephemeral
22:49:10  * kazuponquit (Ping timeout: 245 seconds)
22:52:33  * jmar777joined
22:54:10  * tooxiequit (Ping timeout: 245 seconds)
22:54:20  <trevnorris><insert expletive here>
22:55:02  <trevnorris>come on. it's taking forever to track down all the ways we queue up async requests
22:56:15  <tjfontaine>trevnorris: it could be changed
22:58:04  <trevnorris>tjfontaine: yeah. i'm just trying to figure out how.
22:58:33  <trevnorris>I mean. for example. if you simply create a server, it doesn't count as an async request, until you run .listen()
22:58:59  <trevnorris>but then if you've passed a default connection listener, then it should fire for that, but also for a listening callback if you've passed that
22:59:31  <trevnorris>tjfontaine: have any words of wisdom here?
22:59:49  <trevnorris>othiym23: ping
23:00:02  <trevnorris>creationix: or you ping too
23:00:38  * bnoordhuisjoined
23:00:50  * jmar777quit (Remote host closed the connection)
23:00:54  <creationix>trevnorris, my basic rule of thumb has been around which libuv functions expect callbacks
23:01:05  <creationix>whoever called those is the responsible party
23:01:58  <trevnorris>bnoordhuis: have 30 sec?
23:02:47  <trevnorris>creationix: sorry, not following how that applies to tracking all queued asynchronous requests. e.g. adding a listener to an event is a callback that can technically throw asynchronously, so it will need to also fire the async listener
23:03:13  * defunctzombiechanged nick to defunctzombie_zz
23:03:15  <creationix>trevnorris, right, it doesn't make sense as the js level.
23:03:48  <creationix>there can be zero JS listeners at the time the C callback is setup, there can be one, but it changes later, etc
23:04:42  <trevnorris>what exactly would be a js listener?
23:04:58  <creationix>I mean like the js function passed to EE.on
23:05:09  * defunctzombie_zzchanged nick to defunctzombie
23:05:15  <creationix>but lower down there is a C callback that libuv calls
23:05:25  <creationix>somewhere in between is where the asyncListener hook needs to go
23:05:33  * bnoordhuisquit (Ping timeout: 276 seconds)
23:05:36  <trevnorris>yeah, that fires a callback, that may fire the event emitter
23:06:01  <creationix>where is this code in node?
23:06:15  <creationix>I know how my various libuv bindings work, but not node itself :/
23:07:14  <trevnorris>ok. so a TCPWrap creates an object. attached to that object is .onconnection, this callback is called from MakeCallback, and MakeCallback is called from a native method passed to libuv
23:07:22  <trevnorris>when a connection is received
23:07:35  * inolenjoined
23:08:00  <trevnorris>but from .onconnection you can fire any number of different event emitters, each with their own set of before/after callbacks
23:08:10  <trevnorris>that are not directly related to the onconnection callback called
23:08:35  <othiym23>trevnorris: I think you've stumbled on why domain.add() exists
23:09:14  <trevnorris>othiym23: i'm not too worried about the js side. it's figuring out how to capture all of the async requests from the native side that's bothering me.
23:09:35  * dshaw_quit (Quit: Leaving.)
23:09:38  <othiym23>it's difficult without some form of signaling to say whether an EE wants its own context or to be opted into another event source's context
23:09:51  <trevnorris>because you have ReqWrap, which is easy as it's only instantiated once it's needed.
23:10:09  <othiym23>right
23:10:15  <trevnorris>but then more difficult ones like HandleWrap which immediately aren't technically async requests, up until they're told to be an async request
23:10:30  * dominictarrquit (Quit: dominictarr)
23:10:43  <trevnorris>e.g. net server called w/ .listen
23:10:57  <othiym23>I think my approach was pretty similar to creationix's -- deal with stuff that touches MakeCallback, and then handle the other incidences on a piecemeal basis
23:11:08  <othiym23>yeah
23:11:29  <othiym23>it seems like you want a context that pre-exists .listen, but you wouldn't want the onAsync handler to fire until .listen is called
23:11:56  <trevnorris>technically I don't care. you're the ones consuming this ;)
23:12:10  <trevnorris>i'm just implementing it because I have the time, and I'm mostly concerned about impact on performance.
23:12:42  <trevnorris>but that being said, I like to do things fully, and it doesn't sit well with me that we don't allow the capture of any async request being fired through libuv
23:13:03  <trevnorris>so imo it should fire, passing the object instance, when an object that _could_ become an async request is instantiated
23:13:08  <creationix>wait, so .onconnection fires more than just connection events?
23:13:25  <creationix>btw, did you see how I monkey-patched these from the outside?
23:13:53  <trevnorris>it's hypothetical, you could. I mean, you're running other people's code. and other people's code can do all sorts of stupid stuff
23:13:56  <trevnorris>and no, I haven't
23:14:05  <creationix>I couldn't reach the good stuff, but this works mostly https://github.com/othiym23/async-listener/blob/master/index.js#L14-L24
23:14:54  <creationix>when the user calls listen, I insert a connection listener at the top of the list that monkey-patches the lower-level .onconnection
23:15:09  <creationix>and when a connection event happens inside that, I monkey-patch the .onread function
23:15:10  <trevnorris>yeah. this is going to be as low as it goes. I have all the performance measures in place so it won't affect core performance if it's not used, and has minimal impact beyond calling the async/before/after callbacks.
23:16:07  <trevnorris>explain your case to me better, I'm creating this so you can capture anything that goes on.
23:16:24  <trevnorris>beyond the logic flow of what node core does
23:17:39  <othiym23>the original use case was to support the setting of values that persist through the entire call chain of e.g. a request, in such a way that each request doesn't overwrite the values of any other request
23:17:57  * sblomquit (Ping timeout: 248 seconds)
23:18:17  <othiym23>this includes any forking of control flow within the request, e.g. using things like async.queue to handle bits of work concurrently
23:18:31  <creationix>so the way I understand the event loop from a JS perspective is that each event starts a new call stack that originates from somewhere inside node's C++ code
23:18:41  <othiym23>so if you change a value in one async.queue callback it doesn't stomp on that value in the other callbacks
23:18:55  <creationix>We need a hook to do things before and after this call stack with context from the previous call stack that made this one possible
23:19:09  <trevnorris>creationix: yes, it all originates from C++, and the call stack you speak of is basically the nextTick queue
23:19:30  <trevnorris>creationix: once that queue is expired (or an error is thrown) it will continue to the next event in the event loop
23:20:16  <creationix>right, it's the parent-child relationship between stacks/events that gets tricky
23:20:26  <trevnorris>well, events are emitted immediately. so technically there's no loss in the stack trace. only reason for those is for error capturing
23:20:31  <creationix>simple cases are things like setTimeout and process.nextTick
23:20:49  <creationix>trevnorris, right, personally I don't care about EE at all, but others may disagree
23:21:00  <creationix>EE is all user-space sugar to me
23:21:20  <trevnorris>well, since this also allows for custom error handling (another requirement) it'll need to work w/ the event emitter
23:21:48  <creationix>not really, EE by default throws the "error" event if there is no listener
23:21:54  <creationix>so the native error handling will still see it
23:21:57  <othiym23>I think (correct me if I'm wrong, Tim) creationix means "event" more generally than "things emitted on EEs"
23:22:06  <trevnorris>ah, ok
23:22:12  <trevnorris>yeah. I mean EventEmitter#emit
23:22:57  <creationix>sorry, I mean things like uv_timer_cb
23:23:04  <creationix>basically all the C callbacks in libuv
23:23:07  <trevnorris>heh, so you're talking way deep down.
23:23:10  <creationix>those are my "event sources"
23:23:16  <creationix>they all eventually surface to JS somewhere
23:23:18  <creationix>and start new stacks
23:23:27  <trevnorris>yes
23:23:34  <trevnorris>and that is first what i'm trying to get at.
23:23:53  <creationix>so to me it's simple. Whoever calls the libuv function that accepts the C callback is the parent stack
23:24:23  <creationix>so in the case of streams emitting connection events, it's the call to listen that is the parent
23:24:56  <creationix>now I understand that domains currently have slightly different semantics and I'm not sure what's best there
23:25:44  <trevnorris>there are two main needs. error handling and stack tracing (going to include the cls stuff there)
23:25:44  <othiym23>I like simple, general, basic solutions
23:25:55  <trevnorris>error handling needs to be done at every callback
23:26:10  <trevnorris>seems the cls stuff only needs to happen at every event "origin" ?
23:26:25  <othiym23>trevnorris: is there a reason why addAsyncListener and _fatalException can't be joined together in some way?
23:27:23  <othiym23>trevnorris: I find it helpful to think of things in terms of long stacktraces -- ultimately you want to be able to trace consequences back to their ultimate origins
23:27:34  <trevnorris>othiym23: they will be, but since each returned object can have it's own error handler, and we will support running the error through multiple handlers, it's slightly compicated.
23:27:46  <creationix>trevnorris, right, whenever someone calls a node API that eventually ends up calling something like uv_listen, I want the asyncListener setup hook called
23:27:47  <othiym23>I understand
23:28:43  <creationix>and then when uv_connection_cb is called for that handle and eventually reaches js, I want the before, error, and after hooks processed
23:29:11  <creationix>now the tricky part is not everything in libuv has unique uv_req_t structs
23:29:12  <othiym23>oh yeah: trevnorris, when do you envision the done() hook will be called?
23:30:15  <trevnorris>othiym23: i might have been a little over zealous with that API, but the idea is it'll recognize when no more async requests could be made (e.g. server is shut down, and there are no more open connections)
23:30:36  <creationix>oh, then I got it wrong in my polyfill
23:30:49  <creationix>I did it as a second pass on the after hook
23:31:02  <othiym23>trevnorris: that would be totally awesome if you were able to make it work, but that sounds like total fucking magic to me ;)
23:31:20  <othiym23>creationix: yeah, I left it because I didn't know what it should do
23:31:33  <trevnorris>othiym23: heh, yeah. the plan from the beginning was to make an API that never requires another API request for this stuff again.
23:31:34  <othiym23>having it be an async listener finalizer seemed not completely implausible
23:31:45  <trevnorris>i mean completely encompassing.
23:31:56  <othiym23>THAT'LL SHOW ME
23:32:04  <trevnorris>heh
23:33:03  <trevnorris>well, you want some magic. i'll give you some magic. and this is all i'm working on right now (besides prepping my slides for nodeconf :)
23:34:19  <othiym23>my regret at not being able to go to Ireland grows by the day
23:34:52  <trevnorris>:(
23:35:54  * mikealquit (Quit: Leaving.)
23:36:52  <othiym23>well, on the flip side, I'm going to be able to ship soon, and that will feel very very good
23:37:06  <creationix>trevnorris, is there a map of all the event sources in node?
23:37:14  <creationix>along with what triggers them (their parents)
23:37:37  * mikealjoined
23:37:56  * c4milojoined
23:38:20  <creationix>I guess for the libuv bits you can just search for all the _cb references in uv.h
23:38:20  <trevnorris>creationix: not really. everything I know has been from looking at source
23:38:30  <othiym23>the map is the territory, zudes
23:38:42  <creationix>but libuv isn't all of node, there is asyc in the zlib bindings and the openssl bindings
23:39:16  <othiym23>creationix: I just grepped for MakeCallback and ReqWrap
23:39:27  <trevnorris>but ReqWrap isn't everything
23:39:50  <trevnorris>HandleWrap will create an object that you tie callbacks to from js (e.g. TCPWrap) that'll be called later
23:40:19  <creationix>right, libuv has uv_handle_t and uv_req_t
23:41:08  <trevnorris>ok, can anyone explain to me what queue.h does?
23:43:02  <creationix>trevnorris, if I was implementing asyncListener in node I would stay out of C++ as much as possible and put code right before C++ is called and right after it leaves C++ back to JS
23:44:49  <othiym23>trevnorris: good question -- nothing in src/ includes it
23:44:57  <trevnorris>creationix: what about when a request object is created that you don't have direct access to from JS (e.g. ReqWrap) i'm using those instances to store the async listeners queue to reduce overhead.
23:45:18  <trevnorris>othiym23: req_wrap.h
23:45:26  * kazuponjoined
23:45:32  <othiym23>whoops on wrong branch, sorry
23:45:45  <creationix>trevnorris, can you access the js callback that will be called when the event happens?
23:45:54  <creationix>maybe instead of wrapping it, you can just attach data to the callback
23:46:56  * jmar777joined
23:46:59  <trevnorris>creationix: the callback is well, a function, and storing unique data for each request would require instantiating a new function every time so each can have it's own data.
23:47:12  <creationix>so it's a shared function then?
23:47:15  <trevnorris>yeah
23:47:17  <creationix>hmm
23:47:27  <trevnorris>if it's not then kiss your performance good bye
23:47:41  <trevnorris>v8 will reoptimize every function instance you create
23:47:47  <othiym23>trevnorris: looks ike Node just borrowed a queue abstract data type from nginx, looking at the history
23:48:28  <creationix>ok, so the function is shared, but the object it's attached to is unique right?
23:48:54  <trevnorris>othiym23: yeah. seems to be a queue for processing all the requests?
23:48:54  <creationix>for .onconnection add a new data property .onconnectionData or something like that
23:49:34  <trevnorris>creationix: you mean on the same object that .onconnection is connected to?
23:49:39  <creationix>trevnorris, right
23:50:17  <creationix>just need something that server.listen can write to and .onconnection can read from
23:50:23  * kazuponquit (Ping timeout: 256 seconds)
23:50:28  <creationix>that is unique for that uv_stream_t instance
23:51:29  <creationix>it's a crying shame V8 isn't better about optimizing closures. They really aren't that different than functions that use "this"
23:51:34  <creationix>they just pull from a different scope
23:52:06  * dshaw_joined
23:52:08  <othiym23>creationix: mraleph does a pretty good job of laying out why it's not that simple on his blog
23:52:42  <creationix>I know, but wasn't it because of some obscure js features, not closures themselves
23:52:47  <creationix>other runtimes have optimized them
23:52:56  <trevnorris>oh, heh, this is great. queue.h is used for every asynchronous request. tls included. that makes my life a lot easier
23:53:06  <creationix>trevnorris, awesome
23:54:09  <trevnorris>creationix: reason I want to do it at the C++ level is because I can set class flags that will tell MakeCallback whether it needs to call an extra set of functions. If I don't then I'd have to use ->Has() or some such, which is just sucky slow
23:54:30  <creationix>I see
23:54:34  <creationix>good luck then
23:54:35  <trevnorris>where as I can just do if (inst->async_flags() & ASYNC_LISTENERS)
23:54:40  <creationix>the C++ side of node scares me
23:54:47  <trevnorris>hehe
23:54:58  <othiym23>it's what makes trevnorris feel alive
23:55:18  <trevnorris>wait until you see my nodeconf slides on all the crap I pull to make it fast ;)
23:56:10  <trevnorris>honestly, i'm surprised anyone can understand what's going that hasn't been in core for a while.
23:57:19  * kazuponjoined
23:57:38  <othiym23>trevnorris: it's taken some grit
23:57:41  <othiym23>but I'm getting there
23:58:11  <trevnorris>once all my slides are done it should explain all the state sharing techniques i'm using to quickly communicate between C++ and JS
23:58:19  <trevnorris>that should help it make mores sense