00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:08  <MI6>libuv-master-gyp: #157 UNSTABLE windows-x64 (3/194) smartos-ia32 (2/193) windows-ia32 (4/194) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/157/
00:03:06  * kazuponquit (Ping timeout: 264 seconds)
00:07:55  <trevnorris>othiym23, creationix: one more edge case for you. when you create a Buffer from C++ you can pass a callback that'll be called when the weak persistent is cleaned up. that callback doesn't have to reach JS, but it could potentially error. thus loosing you're entire stack trace
00:08:02  <trevnorris>is that something you'd want to capture?
00:08:18  <trevnorris>i mean, are you looking to capture what's wrong w/ node, what's wrong with user's code?
00:08:35  <creationix>user's code I think
00:08:44  <othiym23>more the latter than the former, but remember that New Relic is trying to help people improve their code, which means knowing when Node itself is doing them wrong
00:09:12  <trevnorris>well, node doesn't do that. but a user could. and tracing that back would be near impossible.
00:09:35  * jmar777quit (Remote host closed the connection)
00:09:56  <trevnorris>it's also common for users to call a JS callback, after an asynchronous operation, directly. skipping the entire MakeCallback/domain route
00:10:14  <trevnorris>which means you'd loose absolutely everything
00:10:22  <othiym23>yeah, may the good lord have mercy on their souls
00:10:26  <trevnorris>hah, ok
00:10:47  * EhevuTovquit (Quit: This computer has gone to sleep)
00:10:50  <othiym23>people reaching directly into chest cavities and pumping the system's heart are going to need to be aware that they're operating outside established parameters
00:11:09  <trevnorris>haha ok.
00:11:17  <trevnorris>my thought was by attaching the data directly to the request object, if they did do something that stupid and it failed, at least you'd be able to print the attached object.
00:11:31  <trevnorris>then you could point to the offending code quickly and say FIX THAT!
00:13:48  <othiym23>yeah, that would be nice to have
00:14:00  <othiym23>it seems pretty peripheral to addAsyncListener, though
00:15:07  <trevnorris>except that Node creates a new Object for every asynchronous request, and I can capture that and pass it to the listener, at which time you can attach anything you want.
00:15:26  <trevnorris>that's the way it's currently working.
00:16:35  <othiym23>yeah, and that's appealing, although I'd have to play with it to see how to make it useful
00:16:42  <trevnorris>every async requests needs an object that contains the callback properties of the event. i'm working on capturing all of those and sending them to the async listener.
00:16:46  <othiym23>also need to modify the polyfill to do as much of that as it can
00:22:22  * dshaw_quit (Quit: Leaving.)
00:22:27  * trevnorris&
00:27:43  <Raynos>trevnorris: so fake async apis that just do function set(key, value, cb) { cache[key] = value; cb(null) } are a problem ?
00:28:12  * othiym23shoots Raynos
00:28:24  <othiym23>let it die, man!
00:28:30  <Raynos>that should be caught by domains right ?
00:28:40  <Raynos>especially if you set the cache in a request handler or in a real callback
00:28:58  <Raynos>other then the "you are evil because you call a cb() synchronously" problem which is an aside
00:29:15  <othiym23>domains will catch that just fine, if they're active
00:29:28  <othiym23>we're talking about somebody manually calling the oncomplete function on a Socket, for example
00:29:53  <Raynos>mother of god ._.
00:30:56  <othiym23>yeah, see?
00:31:08  <othiym23>there's no helping those people
00:31:56  <creationix>aww, ben went offline already
00:32:25  <creationix>well it *is* 2:30am there
00:32:42  <creationix>I started a libuv shim to make it not use callbacks https://github.com/creationix/blanket/blob/master/main.c
00:32:57  <creationix>wrapping all the event sources
00:36:30  * defunctzombiechanged nick to defunctzombie_zz
00:38:21  <Raynos>othiym23: `process.domain.exit() && server._connections[0]._handle.onread(-10)` that kind of thing ?
00:44:11  * dshaw_joined
00:47:27  <othiym23>Raynos: owwww yeah that kind of thing
00:47:35  <othiym23>is that actual code from something?
00:47:39  <othiym23>please tell me you made that up
00:47:57  <Raynos>othiym23: I made that up
00:48:02  <othiym23>whew
00:52:17  <tjfontaine> maybe he's lying to you now
00:52:21  <tjfontaine>WE WILL NEVER KNOW
00:53:17  * ecrquit (Quit: ecr)
01:02:36  * kazuponjoined
01:07:16  <TooTallNate>AHHH
01:07:25  * mikealquit (Quit: Leaving.)
01:07:41  * austoquit (Quit: Leaving)
01:09:18  <kellabyte>WHY ARE WE YELLING?
01:10:06  * mikealjoined
01:10:54  <othiym23>oh LOUDBOT, you're so quaint
01:11:10  <othiym23>what's a "call", and who "takes" on in 2013?
01:15:16  * mikealquit (Quit: Leaving.)
01:15:59  * groundwaterquit (Quit: groundwater)
01:19:23  <brucem>othiym23: people who deal with actual money.
01:20:13  * dapquit (Quit: Leaving.)
01:21:54  * defunctzombie_zzchanged nick to defunctzombie
01:22:09  * kazuponquit (Remote host closed the connection)
01:22:13  * dshaw_quit (Quit: Leaving.)
01:23:01  <othiym23>what's "money"
01:23:04  <othiym23>is that like Bitcoins?
01:24:03  <kellabyte>haha
01:25:01  * kazuponjoined
01:39:30  * kevinswiberjoined
01:44:18  * inolenquit (Quit: Leaving.)
01:51:14  * dshaw_joined
01:58:07  * abraxasjoined
02:06:19  * st_lukequit (Remote host closed the connection)
02:14:04  * sblomjoined
02:17:40  * st_lukejoined
02:18:13  * sblomquit (Ping timeout: 248 seconds)
02:18:51  * inolenjoined
02:24:43  * julianduquequit (Remote host closed the connection)
02:25:41  * julianduquejoined
02:35:12  * st_lukequit (Remote host closed the connection)
02:50:36  * dapjoined
02:51:40  * dapquit (Read error: Connection reset by peer)
02:51:40  * dap1joined
02:57:00  * dshaw_quit (Quit: Leaving.)
03:04:55  * c4milo_joined
03:05:49  * c4miloquit (Read error: Connection reset by peer)
03:07:44  * CoverSlidequit (Ping timeout: 256 seconds)
03:18:32  * dshaw_joined
03:25:10  * c4milo_quit (Remote host closed the connection)
03:28:52  * kazuponquit (Remote host closed the connection)
03:29:48  * dshaw_quit (Quit: Leaving.)
03:49:02  * brson_joined
03:52:48  * brsonquit (Ping timeout: 260 seconds)
03:59:13  * kazuponjoined
03:59:42  * rjequit (Excess Flood)
03:59:43  * roxluquit (Ping timeout: 264 seconds)
03:59:49  * roxlu_joined
04:00:08  * kazuponquit (Remote host closed the connection)
04:00:11  * kazupon_joined
04:00:48  * rje_joined
04:12:16  * kazupon_quit (Remote host closed the connection)
04:32:52  * c4milojoined
04:35:37  * st_lukejoined
04:38:54  * dshaw_joined
04:42:02  <othiym23>is there something magical about the process global that prevents one from using Object.defineProperty on it?
04:42:16  <othiym23>...he says right before opening up src/node.js and checking for himself
04:42:38  * kazuponjoined
04:43:39  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:44:14  <tjfontaine>othiym23: seemed to work for me
04:44:28  <othiym23>short answer: probably?
04:45:18  <othiym23>tjfontaine: Object.defineProperty(process, 'hamchunx', {get : function () { return 'verblox'; }}) does not do what I would expect it to
04:45:36  <tjfontaine>I did: Object.defineProperty(process, 'b', { get: function() { return 10; } })
04:45:48  <tjfontaine>> process.b
04:45:48  <tjfontaine>10
04:45:48  <tjfontaine>> process.version
04:45:48  <tjfontaine>'v0.11.7-pre'
04:45:51  <othiym23>in any case, process is constructed on the C++ side and then injected into startup
04:46:09  * kazuponquit (Remote host closed the connection)
04:46:16  * kazuponjoined
04:47:00  <othiym23>la la la never mind I'm a huge idiot
04:47:06  <tjfontaine><3 othiym23
04:47:56  <othiym23>in other news, totally looking forward to Proxies
04:48:05  <othiym23>and WeakMaps
04:48:45  * julianduquequit (Ping timeout: 245 seconds)
04:48:49  <othiym23>thx tjfontaine
04:48:58  <tjfontaine>no no, thank *you*
04:56:45  * julianduquejoined
05:05:51  * kazuponquit (Remote host closed the connection)
05:06:06  * julianduquequit (Quit: leaving)
05:15:40  <hueniverse>tjfontaine: where's my new build :-)
05:16:42  <tjfontaine>hueniverse: scheduled for tomorrow, as well as a new v0.10 :)
05:17:02  <hueniverse>ooh, what's in 0.10?
05:18:01  <tjfontaine>not a lot really
05:18:30  <tjfontaine>https://github.com/joyent/node/commit/a3da3e73121d68615c5408814284d333f38db692 and https://github.com/joyent/node/commit/fbb963b5d520a70d9c3f2f9ec116d79a0c676f80
05:18:41  <tjfontaine>are the points of note
05:19:35  * kevinswiberquit (Remote host closed the connection)
05:24:11  * mikealjoined
05:24:30  * mikealquit (Client Quit)
05:25:40  * dap1quit (Quit: Leaving.)
05:27:27  * mikealjoined
05:46:59  <tjfontaine>hmm, I think I found a memory leak in child_process
06:08:26  * brson_quit (Quit: leaving)
06:13:56  * TooTallNatejoined
06:13:56  * TooTallNatequit (Client Quit)
06:48:32  <MI6>nodejs-v0.10-windows: #190 UNSTABLE windows-ia32 (7/598) windows-x64 (8/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/190/
06:56:39  * txdv_joined
06:57:54  * txdvquit (Quit: No Ping reply in 180 seconds.)
06:59:41  * defunctzombiechanged nick to defunctzombie_zz
07:00:58  * bajtosjoined
07:06:18  * rendarjoined
07:06:33  * st_lukequit (Remote host closed the connection)
07:16:59  * c4miloquit (Remote host closed the connection)
07:20:40  * defunctzombie_zzchanged nick to defunctzombie
07:22:20  * dominictarrjoined
07:28:25  * defunctzombiechanged nick to defunctzombie_zz
07:34:38  * tooxiejoined
07:35:22  * ecrjoined
07:37:21  * bnoordhuisjoined
07:43:18  * csaohjoined
07:54:00  * tooxiequit (Ping timeout: 276 seconds)
08:00:27  <MI6>joyent/node: Ben Noordhuis master * 358c290 : build: remove unused Carbon dependency - http://git.io/aMDWbw
08:00:55  <bnoordhuis>$ otool -L out/Release/node
08:00:56  <bnoordhuis>out/Release/node: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
08:01:05  <bnoordhuis>ryan can be happy now
08:09:36  <MI6>nodejs-master: #524 UNSTABLE osx-ia32 (1/643) linux-x64 (2/643) smartos-x64 (7/643) linux-ia32 (1/643) http://jenkins.nodejs.org/job/nodejs-master/524/
08:19:49  * piscisaureus_joined
08:23:26  <MI6>nodejs-master-windows: #317 UNSTABLE windows-x64 (19/643) windows-ia32 (18/643) http://jenkins.nodejs.org/job/nodejs-master-windows/317/
08:26:09  <MI6>joyent/node: Kyle Robinson Young v0.10 * 9579464 : doc: fix writable.write link - http://git.io/9kRi4Q
08:33:31  <MI6>nodejs-v0.10: #1462 UNSTABLE linux-ia32 (1/598) smartos-x64 (2/598) osx-ia32 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1462/
08:35:09  * st_lukejoined
08:42:31  <MI6>nodejs-v0.10-windows: #191 UNSTABLE windows-ia32 (7/598) windows-x64 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/191/
08:44:53  * dominictarrquit (Quit: dominictarr)
08:52:12  <MI6>joyent/libuv: Brent Cook master * c363cd0 : build: include internal headers in source list (+1 more commits) - http://git.io/duQSbw
08:58:18  <MI6>libuv-master: #219 UNSTABLE windows (3/194) smartos (10/193) http://jenkins.nodejs.org/job/libuv-master/219/
08:58:33  <MI6>libuv-master-gyp: #158 UNSTABLE windows-x64 (3/194) smartos-ia32 (2/193) windows-ia32 (4/194) smartos-x64 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/158/
08:59:58  * dshaw_quit (Quit: Leaving.)
09:00:55  * st_lukequit (Remote host closed the connection)
09:11:01  <saghul>https://github.com/bnoordhuis/libuv/tree/merge-ipv46 <- sweet!
09:11:42  <MI6>libuv-node-integration: #201 UNSTABLE smartos-x64 (7/643) http://jenkins.nodejs.org/job/libuv-node-integration/201/
09:12:16  * tuxie_joined
09:28:05  <bnoordhuis>saghul: are you stalking me?
09:28:25  <bnoordhuis>that's okay, i've always wanted a stalker of my own
09:28:49  <saghul>your libuv fork always contains interesting stuff ;-)
09:30:38  * dshaw_joined
09:32:06  * tuxie_quit (Quit: Kolba)
09:32:26  * tuxie_joined
09:36:34  * dominictarrjoined
09:37:34  * hzjoined
09:40:51  * Domenic_quit (Ping timeout: 245 seconds)
09:41:52  * `3rdEdenquit (Ping timeout: 264 seconds)
09:41:54  * tuxie_quit (Ping timeout: 276 seconds)
09:45:09  * ecrquit (Ping timeout: 276 seconds)
09:56:59  * tuxie_joined
09:57:54  * bajtosquit (Quit: bajtos)
10:17:22  * abraxasquit (Remote host closed the connection)
10:24:20  * stagasjoined
10:26:14  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/pull/917 <- want to review it or ?
10:31:01  * piscisaureus_quit (Ping timeout: 248 seconds)
10:31:14  <bnoordhuis>i'll take that as a no :)
10:38:29  * csaohquit (Quit: csaoh)
10:42:27  * Domenic_joined
10:44:30  * `3rdEdenjoined
10:45:39  <MI6>nodejs-v0.10: #1463 UNSTABLE linux-ia32 (1/598) smartos-x64 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1463/
10:48:52  * bnoordhuisquit (Ping timeout: 256 seconds)
10:59:54  * stagasquit (Quit: Bye)
11:07:10  * csaohjoined
11:10:32  * hzquit
11:18:42  * tuxie_quit (Ping timeout: 264 seconds)
11:24:44  * skebcioquit (Read error: Operation timed out)
11:26:49  * skebciojoined
12:02:35  * tooxiejoined
12:27:29  * st_lukejoined
12:28:30  * hzjoined
12:32:16  * st_lukequit (Ping timeout: 264 seconds)
12:35:51  * bnoordhuisjoined
12:39:59  <MI6>joyent/libuv: Ben Noordhuis master * 08c6dde : include: merge uv_udp_send and uv_udp_send6 (+3 more commits) - http://git.io/tfhv0g
12:42:25  * c4milojoined
12:45:26  <MI6>libuv-master: #220 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/220/
12:45:45  <MI6>joyent/libuv: bnoordhuis created tag v0.11.13 - http://git.io/oLuKAg
12:45:47  <MI6>joyent/libuv: Ben Noordhuis master * 5dad195 : Now working on v0.11.14 (+1 more commits) - http://git.io/1qeckA
12:46:16  <MI6>libuv-master-gyp: #159 UNSTABLE windows-x64 (3/194) smartos-ia32 (2/193) windows-ia32 (3/194) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/159/
12:51:23  <MI6>libuv-master: #221 UNSTABLE windows (4/194) osx (1/194) smartos (11/193) linux (2/193) http://jenkins.nodejs.org/job/libuv-master/221/
12:52:46  <MI6>libuv-node-integration: #202 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/202/
12:53:46  * jmar777joined
12:54:58  <bnoordhuis>libuv-node-integration failure is expected, another api change
12:58:26  <MI6>libuv-review: #60 UNSTABLE linux-x64 (1/193) smartos-ia32 (4/193) osx-ia32 (1/194) smartos-x64 (4/193) windows-ia32 (3/194) linux-ia32 (1/193) windows-x64 (3/194) http://jenkins.nodejs.org/job/libuv-review/60/
12:59:17  * bnoordhuisquit (Ping timeout: 248 seconds)
12:59:49  <MI6>libuv-node-integration: #203 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/203/
13:01:16  <MI6>libuv-master-gyp: #160 UNSTABLE windows-x64 (3/194) smartos-ia32 (2/193) windows-ia32 (3/194) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/160/
13:15:25  * rendarquit (Ping timeout: 245 seconds)
13:16:35  * hzquit
13:24:14  <roxlu_>hi guys, I need to swap endianness from BE->LE; I can use a macro or just reverse the bytes .. does someone knows what would be best (performance wise)
13:39:48  * kevinswiberjoined
14:02:22  * stagasjoined
14:03:17  * bajtosjoined
14:06:11  * bnoordhuisjoined
14:10:50  * bnoordhuisquit (Ping timeout: 245 seconds)
14:22:11  * rendarjoined
14:22:45  * austojoined
14:26:17  * kevinswiberquit (Remote host closed the connection)
14:36:34  * kevinswiberjoined
14:39:10  * bnoordhuisjoined
14:47:39  * hzjoined
14:50:05  * hzquit (Disconnected by services)
14:50:09  * hzjoined
15:05:35  * mikealquit (Quit: Leaving.)
15:15:02  * AvianFlujoined
15:16:18  * mikealjoined
15:17:14  * groundwaterjoined
15:17:29  <MI6>nodejs-master: #525 UNSTABLE linux-x64 (1/643) smartos-x64 (7/643) linux-ia32 (1/643) http://jenkins.nodejs.org/job/nodejs-master/525/
15:19:05  * bradleymeckjoined
15:25:49  * c4miloquit (Remote host closed the connection)
15:26:43  <pfox__>bnoordhuis: hey, are you willing to entertain some questions about the old uv stat API? mostly to help me think-out-loud through an issue im encountering w/ rust bindings..
15:27:16  * bajtosquit (Quit: bajtos)
15:28:55  * c4milojoined
15:36:43  * rendarquit (Ping timeout: 246 seconds)
15:41:07  * c4miloquit (Remote host closed the connection)
15:42:09  * AvianFluquit (Remote host closed the connection)
15:42:35  * defunctzombie_zzchanged nick to defunctzombie
15:43:24  * AvianFlujoined
15:45:43  <bnoordhuis>pfox__: sure. shoot
15:47:00  * rendarjoined
15:47:23  * mikealquit (Quit: Leaving.)
15:59:43  * rendarquit (Read error: Operation timed out)
15:59:53  * bajtosjoined
16:04:13  * kevinswiberquit (Remote host closed the connection)
16:06:51  * dapjoined
16:09:02  * kevinswi_joined
16:10:17  * mcavagejoined
16:10:22  * mcavagequit (Remote host closed the connection)
16:10:29  * mcavagejoined
16:11:37  * c4milojoined
16:20:25  * jmar777quit (Remote host closed the connection)
16:25:27  <pfox__>bnoordhuis: it seems, by all accounts, that im getting back gibberish for the st_mode field in uv_statbuf_t ..
16:25:44  <pfox__>i should be casting req->ptr to uv_statbuf_t*, correct?
16:25:54  <pfox__>in the "old" api, that is..
16:26:06  <pfox__>this is in 64bit ubuntu..
16:26:18  <pfox__>or am i supposed to cast directly to the platform-specific stat type.. ?
16:27:04  <indutny>shit
16:27:15  <indutny>what's up with openssl 1.0.1
16:28:44  <pfox__>looks like the tests are representing it as a stat
16:29:55  <MI6>joyent/node: Ben Noordhuis master * 7494c84 : uv: upgrade to v0.11.13 - http://git.io/Tg0z2g
16:31:16  <bnoordhuis>pfox__: correct. make sure both libuv and rust are compiled with _FILE_OFFSET_BITS=64 and _LARGEFILE_SOURCE
16:31:57  <bnoordhuis>oh, and 'correct' applies to casting to the native struct stat
16:32:59  <bnoordhuis>newer versions of libuv have a uv_stat_t type that is identical across platforms but that probably doesn't apply to you
16:33:04  <pfox__>yeah.
16:33:44  <pfox__>huh. im not sure about the build flags.
16:34:04  <bnoordhuis>pfox__: easy to test. add a printf("%d\n", sizeof(struct stat)) somewhere in rust and in libuv
16:34:18  <bnoordhuis>if they print different values, you're not using the same build flags
16:34:42  <pfox__>should it be that neither of them have the build flag set, or both of them must have it set?
16:34:49  <pfox__>how owuld i know if one or the other doesn't have it set, if the latter?
16:35:19  <bnoordhuis>if, say, rust is compiled with _FILE_OFFSET_BITS=64 and libuv without, the value reported by rust will be > libuv's
16:35:34  <bnoordhuis>oh, and i guess technically speaking you should be using "%zu\n" :)
16:36:31  <bnoordhuis>ideally, both rust and libuv should be compiled with both flags set. you almost never want the old 32 bits struct stat
16:36:48  <bnoordhuis>it's purely for legacy code, really
16:39:04  <MI6>nodejs-master: #526 UNSTABLE smartos-x64 (8/643) http://jenkins.nodejs.org/job/nodejs-master/526/
16:43:03  * kevinswi_quit (Remote host closed the connection)
16:45:05  <bnoordhuis>indutny: what's with openssl?
16:45:14  <indutny>just figured it out :)
16:45:26  <indutny>reason why my test is failing with newer openssl
16:45:39  <bnoordhuis>you're upgrading openssl in node?
16:45:40  <indutny>got to fully debug handshake process in gdb
16:45:42  <indutny>bnoordhuis: no
16:45:45  <bnoordhuis>aw
16:45:50  <indutny>0.9.8e is the one installed on mac
16:45:53  <indutny>1.0.1 is on ubuntu
16:46:05  <indutny>and server-verify test is using `openssl s_client`
16:46:13  <bnoordhuis>we should upgrade openssl in node before v0.12
16:46:19  <indutny>you think so?
16:46:22  <bnoordhuis>i was hoping someone would volunteer *hint* *hint*
16:46:22  <indutny>why?
16:46:38  <bnoordhuis>we haven't really been keeping up with patches, for one
16:48:08  <indutny>btw
16:48:09  <indutny>I think its an openssl bug
16:48:14  <tjfontaine>do we want that for today?
16:48:15  <indutny>interesting
16:48:22  <indutny>tjfontaine: no, go ahead
16:48:24  <indutny>oh
16:48:24  <indutny>wait
16:48:33  <indutny>probably we can incorporate .renegotiate in today's release?
16:48:34  <indutny>of 0.11
16:48:55  <tjfontaine>I'm planning on doing 0.10 first, so there's time for things to shake out on 0.11
16:49:22  <MI6>nodejs-master-windows: #318 UNSTABLE windows-x64 (19/643) windows-ia32 (19/643) http://jenkins.nodejs.org/job/nodejs-master-windows/318/
16:49:36  <indutny>bnoordhuis: please review https://github.com/joyent/node/pull/6114
16:49:52  <indutny>tls-server-verify should be fixed now
16:49:56  <indutny>but I'll run tests just to be sure
16:54:56  <bnoordhuis>sorry, i have emails to answer :-/
16:55:40  <indutny>bnoordhuis: mmaaaaan
16:55:47  <indutny>you're the only chance for it :)
16:55:49  <indutny>to happen
16:55:51  <pfox__>bnoordhuis: my solution is to upgrade libuv :)
16:56:56  * rendarjoined
17:01:27  <indutny>bnoordhuis: yt?
17:10:42  * dominictarrquit (Quit: dominictarr)
17:12:00  * mikealjoined
17:13:22  * dshaw_quit (Quit: Leaving.)
17:16:46  * c4miloquit (Remote host closed the connection)
17:17:18  * csaohquit (Quit: csaoh)
17:19:06  * TooTallNatejoined
17:20:41  <tjfontaine>I'm starting the v0.10 release, anythiing anyone needs to get in?
17:23:43  * c4milojoined
17:23:51  * st_lukejoined
17:24:10  <indutny>nope
17:24:21  <indutny>anyone knows how to make GYP archive all static dependencies?
17:26:17  <tjfontaine>what do you mean, archive?
17:26:41  <indutny>$(AR)
17:26:51  <indutny>lets say I've target "a"
17:26:58  <indutny>which is itself a "static_library"
17:27:05  <indutny>and has a dependency "b"
17:27:09  <indutny>which is a "static_library" too
17:27:18  <indutny>right now, GYP will generate liba.a and libb.a
17:27:26  <indutny>without archiving them together
17:27:48  <tjfontaine>well they're generally thin archives, but ok
17:28:48  <indutny>oooh
17:28:53  <indutny>standalone_static_library
17:30:38  <indutny>hm..
17:30:40  <indutny>doesn't seem to be working
17:31:56  <indutny>on mac
17:31:57  <indutny>shit
17:31:58  <indutny>)
17:31:59  <indutny>:)
17:37:37  * dominictarrjoined
17:39:49  <tjfontaine>isaacs: better wording for your streams fixes? https://gist.github.com/tjfontaine/6440235
17:42:40  * c4miloquit (Remote host closed the connection)
17:47:21  * hzquit
17:48:07  <isaacs>looking
17:48:39  * c4milojoined
17:49:35  <trevnorris>morning
17:49:41  <tjfontaine>g'day
17:49:45  <isaacs>tjfontaine: https://gist.github.com/isaacs/6440327
17:49:54  <isaacs>tjfontaine: the aussie is rubbing off on you
17:49:58  <tjfontaine>heh
17:51:11  <tjfontaine>ok, and with that I will now start the builds
17:51:17  * st_lukequit (Remote host closed the connection)
17:52:00  <trevnorris>othiym23, creationix: double ping
17:52:08  <MI6>joyent/node: tjfontaine created branch v0.10.18-release - http://git.io/mf3X_A
17:52:14  <creationix>trevnorris, sup
17:52:47  <MI6>node-review: #83 ABORTED http://jenkins.nodejs.org/job/node-review/83/
17:53:10  <trevnorris>creationix: recap/clarify - the asyncListener callback was going to be called whenever something was queued that would break the callstack.
17:53:22  <trevnorris>that includes more than just the uv *_cb locations
17:53:51  <MI6>libuv-master: #222 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/222/
17:54:10  <creationix>right, it also needs stuff like zlib streams and some crypto stuff
17:54:10  <trevnorris>bnoordhuis: ping
17:54:11  <creationix>var cnx = navigator.mozMobileConnection;
17:54:11  <creationix>cnx.addEventHandler('ussdreceived', function (evt) {
17:54:11  <creationix> console.log('Network message: ' + evt.data.message);
17:54:11  <creationix>});
17:54:11  <creationix>var MMIRequest = cnx.sendMMI(prompt('Provide a valid MMI'));
17:54:13  <creationix>MMIRequest.onerror = function() {
17:54:15  <creationix> console.log("Mmmh... Something goes wrong.");
17:54:17  <creationix>}
17:54:33  <creationix>that was supposed to be a gist link, not an inline paste!
17:54:39  <trevnorris>hah
17:54:41  <creationix>https://github.com/othiym23/async-listener/blob/master/index.js#L143-L159
17:56:17  <trevnorris>event emitters are emitted synchronously, so the don't break the call stack (even though they are "callbacks").
17:56:34  <trevnorris>so on the js side the only thing that can break the callstack are callbacks to process.nextTick
17:57:11  * st_lukejoined
17:57:12  <trevnorris>well, I guess we could include timers there too
17:58:39  * jmar777joined
17:58:40  <isaacs>trevnorris: yes. MakeCallback, nextTick, and timers
17:59:29  * dshaw_joined
18:00:31  <trevnorris>isaacs: MakeCallback, _tickCallback and Timers (processImmediate, listOnTimeout) are the call sites for before/after and where the error handling should be queued.
18:01:02  <Domenic_>isaacs: I don't really understand this multi-context stuff, at least when you present it from the perspective of the vm module
18:01:10  <trevnorris>isaacs: but async listener is called on ReqWrap/HandleWrap/EventEmitter instantiation.
18:01:38  <isaacs>Domenic_: so, what multi-context would provide is a way to do vm.createContext({stuffffff}, {nodeEnvironment:true})(
18:01:50  <isaacs>Domenic_: so you'd have a separate context that has process, require, etc.
18:02:05  <Domenic_>isaacs: OK, so there are two issues: the security token stuff seems nonsensical, and what does nodeEnvironment: true do, exactly
18:02:06  <isaacs>(or actually, i'm not sure about require())
18:02:23  <trevnorris>actually, scratch EE. itself can't break the call stack. but it's inhereted from wrappers that will
18:02:25  <isaacs>Domenic_: well, we ought to expose the V8 security token stuff.
18:02:37  <isaacs>Domenic_: and doing that in JS is a little bit tricky
18:02:39  <Domenic_>isaacs: let's do nodeEnvironment first, I don't understand either, so one at a time
18:02:58  <Domenic_>is the idea that if someone in a nodeEnvironment context mutates their process global, it doesn't affect the original process global?
18:03:05  <isaacs>Domenic_: bnoordhuis has refactored the node code so that you can have two separate contexts runinng full-on node programs.
18:03:13  <isaacs>Domenic_: yes.
18:03:26  <isaacs>Domenic_: imagine it like a safe vm.createContext({process:process})
18:03:26  <tjfontaine>so many different uses of Context in 0.11 :)
18:03:36  <isaacs>tjfontaine: yeah
18:03:37  <Domenic_>isaacs: ok. so they get their own copies of all the built-in modules etc.
18:03:42  <isaacs>"context" in this context is V8::Context
18:03:47  <isaacs>yes.
18:03:57  <isaacs>their own copies of argv, of env, etc.
18:04:02  <isaacs>well, env is weird
18:04:12  <isaacs>since chnaging it will actually do a setenv and reading it actually does a getenv
18:04:17  <isaacs>and it's all in teh same process
18:04:20  <tjfontaine>and lets wave our hands over what that means for binary addons
18:04:29  <isaacs>right
18:04:39  <isaacs>binary addons will have to do NODE_MODULE_CONTEXT_AWARE() insted of NODE_MODULE
18:05:05  * isaacswavey wavey
18:05:10  * mikealquit (Quit: Leaving.)
18:05:22  <Domenic_>ok. nodeEnvironment, got it.
18:05:28  <Domenic_>so, security token
18:05:39  <isaacs>Domenic_: this is strictly a V8-ism
18:05:43  <Domenic_>the idea is you can run code with different globals but kind of the same global if they share a security token?
18:05:43  <isaacs>which we don't currently expose
18:05:58  <isaacs>Domenic_: you know how you have the same-origin policy in a browser?
18:06:05  <Domenic_>isaacs: sure
18:06:18  <Domenic_>but that's around like what URLs you can fetch
18:06:23  <isaacs>so, you can access document.frames[1].contextIforgetwhatthisisactually.window.someGlobal
18:06:27  <Domenic_>hmm
18:06:32  <isaacs>but only if that frame and your frame are in the same domain
18:07:13  <isaacs>if they're not in teh same domain, then you can only access certain things: location, postMessage, history.go, and a few others.
18:07:28  <Domenic_>i think i see
18:07:35  <isaacs>chrome implements this by using the domain as the security token
18:07:42  <Domenic_>so you don't intrinsically get access to the other context's security tokens
18:07:43  <isaacs>(or some hash of it or whatever, i don't know actually how it's implemented)
18:07:50  <Domenic_>err, misspoke
18:07:54  <isaacs>but it uses the V8::Context setSecurityCallback
18:08:03  <isaacs>nono, every context has a security token
18:08:07  <Domenic_>access to the globals of the other contexts which have your security token
18:08:13  <isaacs>and if they match, you get access to one another
18:08:21  <isaacs>but no, you still need a reference.
18:08:29  <Domenic_>but if someone gives you another context's global, you can only access it iff you have the same security token
18:08:30  <isaacs>the question is whether or not you can actually access that reference.
18:08:34  <isaacs>right
18:09:01  <isaacs>since a token actually doesn't satisfy the granularity of use cases that are needed, it also has setSecurityCallback
18:09:07  <Domenic_>i guess this seems pretty useless when we have an ocap model already?
18:09:31  <Domenic_>i.e. just don't give them the global if you don't want them to access the global
18:10:04  <isaacs>this lets you provide a function which is called when you try to do some stuff
18:10:16  <Domenic_>ok, so effectively it allows you to give them proxy globals
18:10:16  <isaacs>Domenic_: well, i might want you to have access to call a certain function, but not this other function
18:10:26  <isaacs>Domenic_: or, i ight let you access something once, but not more than once.
18:10:36  <isaacs>Domenic_: or, calling a fucntion might disable access to anything else until some future tim
18:10:39  <isaacs>e
18:10:40  <Domenic_>yeah, so this is basically a workaround for not having proxies
18:10:44  <isaacs>kinda
18:10:57  <isaacs>whats "ocap model"?
18:11:05  <Domenic_>object capability model
18:11:09  <isaacs>oh, yeah
18:11:20  <isaacs>it's a finer-grained ocap
18:11:31  <isaacs>"check every time"
18:11:38  * stagas_joined
18:11:55  * stagasquit (Ping timeout: 264 seconds)
18:11:55  * stagas_changed nick to stagas
18:12:00  <Domenic_>right.
18:12:02  <tjfontaine>so probably going to start 0.11 at 1PM Pacific, if you want things in it speak now :)
18:12:08  <Domenic_>but i really think this is inferior at proxies
18:12:15  <Domenic_>i wonder what the interception API looks like
18:12:20  <Domenic_>i am betting like a crippled version of proxies
18:12:30  <Domenic_>(in fact I am pretty sure mozilla implements all this cross-domain stuff with proxies)
18:13:06  <Domenic_>especially direct proxies
18:13:10  <Domenic_>which are just wrappers around existing objects
18:13:16  * kevinswiberjoined
18:13:17  <Domenic_>so even more suitable for this use case
18:13:21  <isaacs>tjfontaine: aboutto land a few things
18:13:43  * brsonjoined
18:13:52  <tjfontaine>isaacs: mk
18:14:37  <MI6>joyent/node: isaacs master * 9ef9a9d : repl: Simplify paren wrap, continuation-detection (+2 more commits) - http://git.io/09VIXw
18:14:57  <isaacs>Domenic_: so, securityCallbaks are probably too tricky
18:15:07  <isaacs>Domenic_: it's also a weird dip into JS from C++ to access a JS object..
18:15:21  <isaacs>Domenic_: doing securityCallbacks in C++ is less crazy
18:18:11  <MI6>joyent/node: isaacs master * 689e5c9 : stream: return this from pause()/resume() (+1 more commits) - http://git.io/5ioVxw
18:20:05  <bnoordhuis>trevnorris: pong
18:20:06  <MI6>joyent/node: isaacs master * 15a5a4a : http: Only send connection:keep-alive if necessary - http://git.io/B9Sh_Q
18:20:39  <isaacs>tjfontaine: full speed ahead!
18:20:39  <Domenic_>isaacs: ok. so the security contexts thing doesn't seem to be solving any problems.
18:20:47  <tjfontaine>:)
18:20:52  <isaacs>Domenic_: well, defense in depth
18:21:29  <Domenic_>isaacs: that's kind of silly. why are you giving them the object if you are just going to defend against them using it? instead, don't give it to them
18:21:30  <trevnorris>bnoordhuis: i'm allowing users to call a callback when something is queued that'll cause a break in the call stack. first I just thought ReqWrap on the C++ side, but then realized there's HandleWrap and some TLS stuff
18:21:30  <isaacs>Domenic_: but i think maybe the takeaway here is to do security contexts and node-environment-contexts as separate things.
18:21:54  <isaacs>Domenic_: there maybe cases where you have a bunch of objects, all with different contexts, and it's easier to manage the tokens than manage the objects.
18:21:54  * defunctzombiechanged nick to defunctzombie_zz
18:22:21  <Domenic_>isaacs: sounds like it'd be a good library to build ;)
18:22:25  <bnoordhuis>trevnorris: em, okay. is that a question or a statement?
18:22:28  <trevnorris>bnoordhuis: so was playing w/ the idea of trying a super simplistic AsyncWrap class that they inherit from as a single point of work. thoughts, or alternatives?
18:22:35  <bnoordhuis>ah
18:22:54  <trevnorris>my hands are cold. makes for slow typing
18:23:02  <isaacs>bnoordhuis: how would you feel about vm.crateContext({global stuffff}, {nodeEnvironment:true})
18:23:10  <isaacs>bnoordhuis: and then we can do security token stuff separately?
18:23:26  <isaacs>bnoordhuis: do you have any insight into whether this will satisfy github's use case?
18:23:27  <Domenic_>in general, same origin protocol is seen as a poor design by many in the ES/DOM space. Not something I'd want to emulate in node unless there's some fundamentally new capability it gives you.
18:23:58  * rje_changed nick to rje
18:24:02  <bnoordhuis>isaacs: i don't think github really cares about the js api, they're working with node on the c++ level only
18:24:04  <tjfontaine>ok, lets see how much my post-build script can break things
18:24:16  <isaacs>bnoordhuis: oh, ok
18:24:27  <isaacs>bnoordhuis: that actually makes things remarkably simple, then
18:24:38  <isaacs>we can basically do whtever sorta fits with how Node users might use it.
18:24:45  <bnoordhuis>indeed :)
18:24:50  <MI6>joyent/node: tjfontaine created tag v0.10.18 - http://git.io/U0KNaw
18:25:03  <bnoordhuis>trevnorris: re AsyncWrap, i'm not sure i follow the use case
18:25:04  <isaacs>bnoordhuis: then, in your opinion as a node user, how do you personally feel about it?
18:25:24  <MI6>joyent/node: Timothy J Fontaine v0.10 * 9c19c1e : blog: Post for v0.10.18 (+3 more commits) - http://git.io/8nqWcw
18:25:29  <isaacs>\o/
18:25:31  <tjfontaine>that's pretty painless
18:25:51  <bnoordhuis>isaacs: seems okay to me. maybe mark it experimental for now so we can roll it back in case it doesn't work out
18:25:55  <othiym23>trevnorris, creationix: seems like you guys are on it, but I'm here now
18:25:56  <isaacs>bnoordhuis: yeah, totally
18:25:57  <bnoordhuis>or roll back, change
18:26:15  <isaacs>bnoordhuis: also, i'ts a bit odd, i think, if it doesn't have require/etc.
18:26:36  <isaacs>bnoordhuis: but that means bootstrapping the module system, and runinng the source as if it's stdin or soething?
18:26:56  <bnoordhuis>yes, something like that
18:27:01  <trevnorris>bnoordhuis: creating an abstracted hook-like api so users can long call stack/domain error handle the crap out of their code w/o affecting basic core performance.
18:27:19  <isaacs>hm. yeah, definitely requires a bit more exploration.
18:27:29  <othiym23>does anybody know how to make GitHub show a comparison view for two arbitrary branches of repos which may themselves be separate forks of the same ancestor?
18:27:35  <trevnorris>bnoordhuis: which means that whenever something occurs that could break the call stack, i'm allowing a callback to be run that'll allow them to capture what's going on.
18:27:47  <MI6>libuv-node-integration: #204 UNSTABLE smartos-ia32 (1/643) linux-ia32 (2/643) osx-ia32 (2/643) smartos-x64 (18/643) http://jenkins.nodejs.org/job/libuv-node-integration/204/
18:27:49  <isaacs>bnoordhuis: if you want to go ahead and land the bulk of the multicontext refactoring, and leave out the cli stuff, then i think that's probably worthwhile, if only to unblcok trevnorris
18:27:54  <trevnorris>bnoordhuis: look at req_wrap here: https://github.com/trevnorris/node/commit/0f1c345
18:28:01  <bnoordhuis>isaacs: yeah, good idea
18:28:06  <isaacs>bnoordhuis: apart from the API surface, it's very non-controversial.
18:28:13  <trevnorris>bnoordhuis: oh, and i'm still getting the two debugger test failures
18:28:13  <tjfontaine>twitterified
18:28:16  <bnoordhuis>isaacs: btw, i'm pretty much fine with whatever js api you come up with
18:28:20  <isaacs>kewl
18:28:31  <bnoordhuis>the important thing for me was to clean up the c++ code base / prep the way for isolates
18:28:35  <isaacs>i think we're getting closer to something that is as un-weird as possible, but it's not quite there yet
18:28:55  <isaacs>bnoordhuis: yeah, totally. it's a vast improvement, i'm really eager to get that in.
18:29:24  <bnoordhuis>trevnorris: i fixed the debugger tests yesterday
18:29:39  <bnoordhuis>maybe you need to rebase?
18:29:46  <isaacs>ok, off to yoga practice. will be back after lunch
18:29:49  * isaacs&
18:29:55  <trevnorris>just rebased your branch on latest master
18:29:57  <tjfontaine>LOUDBOT++
18:30:11  <othiym23>haHA, I am smarter than a non-sentient website: https://github.com/trevnorris/node/compare/bnoordhuis:multi-context...trevnorris:flippin-tick-thing
18:30:24  <trevnorris>(there's another tiny collision on tcp_wrap btw)
18:31:06  <tjfontaine>bnoordhuis: what's the schedule on baby-ben-part-2
18:31:14  <trevnorris>bnoordhuis: now i'm getting "AssertionError: test timed out"
18:31:22  <bnoordhuis>tjfontaine: today is the due day actually
18:31:24  <othiym23>trevnorris: what branch are you basing your changes on? it doesn't seem to be bnoordhuis:multi-context
18:31:30  <tjfontaine>bnoordhuis: I know, that's why I'm curious :)
18:31:34  <MI6>nodejs-master: #527 UNSTABLE osx-x64 (1/644) smartos-ia32 (2/644) osx-ia32 (1/644) smartos-x64 (7/644) http://jenkins.nodejs.org/job/nodejs-master/527/
18:31:58  <bnoordhuis>tjfontaine: yeah, nothing happening so far. the previous one was two weeks overdue so...
18:32:17  <tjfontaine>heh, not in any rush are they :)
18:32:28  <trevnorris>othiym23: it is, but I rebased it on latest master for the libuv upgrade
18:32:29  <bnoordhuis>indeed :)
18:33:59  <bnoordhuis>trevnorris: let me rebase and push
18:34:32  <bnoordhuis>trevnorris: done
18:34:46  <MI6>nodejs-master-windows: #319 UNSTABLE windows-x64 (19/644) windows-ia32 (19/644) http://jenkins.nodejs.org/job/nodejs-master-windows/319/
18:35:06  <trevnorris>bnoordhuis: hah, so it's two _other_ debug tests that are failing w/ the debug fix :P
18:35:07  <bnoordhuis>oh, i get a timeout too now
18:35:23  <trevnorris>those tests are so borked.
18:35:38  <bnoordhuis>hrm, weird though. they were passing yesterday
18:35:52  * kevinswiberquit (Remote host closed the connection)
18:35:54  <tjfontaine>a timeout isn't expected, a message mismatch is
18:36:02  <trevnorris>if you remove your debug fix, they'll probably pass.
18:36:12  <trevnorris>at least they do on mine
18:38:29  * kevinswiberjoined
18:39:30  <bnoordhuis>trevnorris: still failing for me
18:39:36  <trevnorris>oh, strange.
18:39:39  <bnoordhuis>tres weird, it worked yesterday
18:39:52  <trevnorris>have any background node processes?
18:39:53  <bnoordhuis>that's what all programmers say, of course
18:39:57  <bnoordhuis>but this time it's true
18:39:59  <bnoordhuis>no, none
18:40:34  <othiym23>trevnorris, bnoordhuis: thanks for the rebase, it's really nice being able to see just the asyncListener changes in one diff
18:40:56  <bnoordhuis>i'm admittedly not entirely clear on the purpose of that asynclistener thing
18:41:26  <tjfontaine>heh
18:42:03  <othiym23>bnoordhuis: to be awesome
18:42:06  <othiym23>bnoordhuis: to crush code
18:42:24  <othiym23>bnoordhuis: to make my life better
18:42:29  <othiym23>pick one
18:43:41  <creationix>bnoordhuis, long-stack-traces, context-local-storage, domain-style error handline, next-tick, etc...
18:43:49  <creationix>all these things could be easily implemented on top of the asyncListener
18:43:58  <othiym23>trevnorris: is it still your intention to rework domains to use addAsyncListener?
18:44:20  <trevnorris>advantage imo is that they can do all that stuff, but i'm able to implement it in a way that makes it have near-zero impact if not used.
18:44:31  <trevnorris>othiym23: yes. when this is done domains could live in user-land
18:44:52  <othiym23>bnoordhuis: less flippantly, it's a fairly simple way of making it possible to efficiently add to Node core's asynchronous behaviors in pure JS
18:45:11  <creationix>othiym23, I liked your first answer better ;)
18:45:22  <othiym23>creationix: \o/
18:45:49  <trevnorris>bnoordhuis: for me it's important because we can remove the domain specific code, have less performance hit and not hear another ticket about needing this functionality :)
18:46:09  <tjfontaine>there will always be more tickets
18:46:26  <trevnorris>tjfontaine: please, let me live in ignorant bliss just for a moment
18:46:46  <tjfontaine>hehe
18:46:56  <tjfontaine>trevnorris: time to wake up, you'll be late for school
18:46:57  <othiym23>now that I've figured out trevnorris's tragic Achilles heel, I'm going to be filing tickts all day erryday
18:47:09  <trevnorris>AAAAAHHHHHHHHHHH!!!!!!!!!!!!!!!
18:47:10  <tjfontaine>ERRRRYDAY
18:47:17  <bnoordhuis>othiym23: what are 'asynchronous behaviors'?
18:47:35  <MI6>nodejs-v0.10: #1464 UNSTABLE linux-x64 (2/598) smartos-ia32 (7/598) smartos-x64 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1464/
18:47:51  <trevnorris>bnoordhuis: remember the comment in MakeCallback about long stack traces 'n stuff?
18:48:05  <bnoordhuis>is it just a way to run a bunch of observer callbacks before making the actual callback?
18:48:19  <bnoordhuis>trevnorris: i do
18:48:23  <othiym23>bnoordhuis: sorta!
18:48:27  <tjfontaine>asynchronous decorator pattern
18:48:57  <MI6>nodejs-master: #528 UNSTABLE smartos-ia32 (1/644) smartos-x64 (6/644) http://jenkins.nodejs.org/job/nodejs-master/528/
18:49:05  <othiym23>bnoordhuis: but I think of it as being more like AOP or a substrate for a poor dev's applicative functor
18:49:13  <othiym23>gotta get my monadic fix somehow
18:49:50  <bnoordhuis>ah, okay. it's starting to make sense
18:50:56  <MI6>node-review: #84 UNSTABLE windows-ia32 (7/598) osx-ia32 (1/598) centos-x64 (1/598) centos-ia32 (3/598) smartos-ia32 (5/598) windows-x64 (8/598) osx-x64 (1/598) smartos-x64 (5/598) http://jenkins.nodejs.org/job/node-review/84/
18:51:26  <bnoordhuis>tjfontaine: can i land stuff in master now?
18:52:17  <tjfontaine>bnoordhuis: erm, that you want landed for the release today?
18:52:24  <bnoordhuis>ah nvm, it's a trivial thing - i'll save it for later tonight
18:52:31  <tjfontaine>I can branch off now it's no biggie
18:52:38  <tjfontaine>I was just waiting to see if there was anything anyone else needed
18:52:41  <bnoordhuis>just moving some tests around, nothing important
18:52:57  <Domenic_>yeah i love that long stack trace comment!!
18:53:10  <bnoordhuis>i'll go back to answering emails
18:53:11  <trevnorris>oy....
18:55:59  * EhevuTovjoined
19:00:44  * dshaw_quit (Quit: Leaving.)
19:02:41  * ryahjoined
19:04:16  <trevnorris>bnoordhuis: re: AsyncWrap class, i'm adding an int async_flags_ and int async_flags() to HandleWrap/ReqWrap so I can set if any listeners are attached to the object, and passing those to MakeCallback. this way there's near zero cost knowing the state of the callback object. so the idea was instead of adding those fields instead create a super tiny class that those inherit from
19:04:34  <trevnorris>(also, other flags will be included there)
19:05:13  <MI6>nodejs-v0.10-windows: #192 UNSTABLE windows-ia32 (7/598) windows-x64 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/192/
19:06:22  <othiym23>trevnorris: fwiw, I like the sounds of that idea, although I'm not sure I totally have my head wrapped around how it would be used
19:07:13  <othiym23>trevnorris: is the idea that something substitutes AsyncWrap instances for ReqWrap instances when there are async listeners active, and polymorphism takes care of the differences in behavior?
19:08:41  <trevnorris>othiym23: no no. this is just a performance tuning trick. AsyncWrap just has an extra field for flags. These flags are used to determine the "state" of the object.
19:08:56  <trevnorris>othiym23: it could be done by doing a bunch of ->Has() ->Get() ->Is*
19:08:59  <trevnorris>but those are super slow
19:09:27  <trevnorris>this way I can integrate it directly into core w/o any performance loss if they're not being used, and have minimal overhead if they are
19:10:09  * EhevuTovquit (Quit: This computer has gone to sleep)
19:10:32  <othiym23>hmm... I'm not sure how what you're saying and what I'm saying are in conflict?
19:10:55  <trevnorris>there's no substitution or polymorphism
19:11:07  <othiym23>what switches Node between using a ReqWrap and an AsyncWrap?
19:11:08  <bnoordhuis>ryah: have you checked `otool -L path/to/node` recently?
19:11:24  <trevnorris>othiym23: nothing. ReqWrap inherits from AsyncWrap
19:11:26  <ryah>bnoordhuis: i haven't
19:11:39  <ryah>bnoordhuis: v10 or master/
19:11:42  <trevnorris>othiym23: as does HandleWrap/TLSWrap and any other *Wrap that will perform a uv *_cb
19:11:50  <bnoordhuis>ryah: master. i did it all for you
19:12:03  <trevnorris>or in tls's case whatever it uses
19:12:06  <trevnorris>(tls scares me)
19:12:13  <ryah>ryan@yyy-4:~% node -v
19:12:13  <ryah>v0.10.14-pre
19:12:13  <ryah>ryan@yyy-4:~% otool -L `which node`
19:12:13  <ryah>/Users/ryan/local/node/bin/node: /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 155.0.0) /usr/lib/libSystem.B.dylib (compa
19:12:16  <othiym23>trevnorris: ahhhhhhhhh got it -- or at least, now I'm back to wondering why you're not slapping those properties directly on the side of ReqWrap
19:12:27  <othiym23>oh!
19:12:29  <bnoordhuis>ryah: git pull --rebase && ./configure && make
19:12:29  <othiym23>OK
19:12:34  <othiym23>now I'm with you, trevnorris
19:12:37  <trevnorris>:)
19:12:51  <bnoordhuis>(i dropped the carbon dep this morning)
19:12:59  <ryah>oh nice
19:13:02  <bnoordhuis>but note how coreservices, applicationservices and corefoundation are gone
19:13:06  <ryah>does process.title still work?
19:13:09  <bnoordhuis>yep
19:13:13  <ryah>siiiick
19:13:14  * EhevuTovjoined
19:13:20  <ryah>compiling...
19:16:54  * dapquit (Quit: Leaving.)
19:19:46  <ryah>https://gist.github.com/ry/0be07d371c27b41ddbd5
19:19:48  <ryah>wow
19:19:50  <ryah>nice bnoordhuis
19:21:14  <bnoordhuis>thanks :)
19:22:58  <MI6>nodejs-master-windows: #320 UNSTABLE windows-x64 (19/644) windows-ia32 (20/644) http://jenkins.nodejs.org/job/nodejs-master-windows/320/
19:23:05  * hzjoined
19:28:38  * stagasquit (Read error: Connection reset by peer)
19:29:23  <ryah>when is v12 coming out?
19:30:27  * mikealjoined
19:30:54  <trevnorris>I think we're shooting for beginning of 2014
19:31:34  <trevnorris>ah man, everyone else's at lunch.
19:31:37  <othiym23>according to isaacs, end of August, tops
19:31:52  <othiym23>so everybody better get on it
19:33:40  <ryah>beginning of 2014??
19:33:46  <ryah>people....
19:33:48  <trevnorris>;P
19:33:55  <bnoordhuis>i think that was a joke
19:34:09  <bnoordhuis>probably sometime this month? i think we're pretty close by now
19:34:22  <ryah>oh cool
19:37:48  * defunctzombie_zzquit (Ping timeout: 259 seconds)
19:38:52  * blissdevquit (Ping timeout: 268 seconds)
19:40:24  * bajtosquit (Quit: bajtos)
19:41:17  * defunctzombie_zzjoined
19:41:27  * blissdevjoined
19:41:57  <MI6>nodejs-master-windows: #321 UNSTABLE windows-x64 (18/644) windows-ia32 (19/644) http://jenkins.nodejs.org/job/nodejs-master-windows/321/
19:44:56  <mmalecki>hey, I've been browsing node issues looking for something to do and found 2 issues which could be closed, if anyone wants to close, here they are
19:44:59  <mmalecki>https://github.com/joyent/node/issues/5833
19:45:02  <mmalecki>https://github.com/joyent/node/issues/5534
19:47:33  <mikeal>that's gonna break some people's code
19:48:06  <bnoordhuis>is #5833 fixed? i remember a commit but...
19:48:28  <bnoordhuis>trevnorris: ^
19:49:34  <trevnorris>bnoordhuis: oh, great. didn't realize that got merged. coolio
19:50:57  <bnoordhuis>trevnorris: well, i asked because i'm not sure :)
19:51:14  <trevnorris>thanks. just closed it
19:51:27  * ecrjoined
19:51:41  <bnoordhuis>ah, right - saw the email
19:51:50  * brsonquit (Ping timeout: 264 seconds)
19:51:55  <trevnorris>oy, I hate c++ class inheritance. maybe just one time i'll get it right w/o having to spend an hour on google :P
19:53:24  <bnoordhuis>trevnorris: what are you trying to do?
19:54:24  <trevnorris>bnoordhuis: in stead of hunting down all the locations I'll need to add the async_flags stuff. i'm just trying to make an AsyncWrap class that has them on it.
19:54:39  <trevnorris>and make ReqWrap and HandleWrap inherit from it
19:55:53  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:56:27  <bnoordhuis>trevnorris: class ReqWrap : public AsyncWrap { // ?
19:57:10  * AvianFluquit (Remote host closed the connection)
19:57:46  <trevnorris>yeah. think i'm trying to do some stupid stuff by passing arguments to the AsyncWrap constructor
19:57:59  * ryahquit (Quit: Lost terminal)
19:58:06  <trevnorris>but just realized I can't do it there anyways because the object passed might not be set.
19:58:42  <bnoordhuis>trevnorris: ReqWrap and HandleWrap both have constructors that take a Handle<Object>
19:59:05  * dshaw_joined
19:59:11  <trevnorris>bnoordhuis: yeah, that's what I was trying to pass. but ReqWrap has an if (object.IsEmpty()) object = Object::New()
19:59:15  <bnoordhuis>i.e. it's possible to pass the object to AsyncWrap, you just need to call its constructor from the ReqWrap and HandleWrap constructor
19:59:18  * brsonjoined
19:59:24  <trevnorris>which leads me to believe I can't depend on the object being set
19:59:49  <bnoordhuis>hrm, i'm not sure if that's still used. let me check
19:59:55  * julianduquejoined
20:00:38  * ecrquit (Ping timeout: 240 seconds)
20:00:53  * ecrjoined
20:02:04  <bnoordhuis>trevnorris: only by node_file.cc and that's pretty trivial to fix
20:04:27  <trevnorris>bnoordhuis: mind taking a quick peek and telling me how i'm being stupid (it's all over the place in this): https://github.com/trevnorris/node/commit/4ea5487
20:06:28  <trevnorris>here, removed some stuff don't think I needed: https://github.com/trevnorris/node/commit/799ddaa
20:06:56  * AvianFlujoined
20:09:27  <trevnorris>bnoordhuis: wait. nm. I got it.
20:09:43  * st_lukequit (Remote host closed the connection)
20:09:49  <trevnorris>oy. sorry for wasting a few moments of your time :P
20:11:03  <bnoordhuis>trevnorris: commented anyway :)
20:11:09  <tjfontaine>ok
20:11:11  <trevnorris>thanks :)
20:11:15  <tjfontaine>last call for 0.11 pushes
20:11:28  <bnoordhuis>nothing from me
20:11:57  <tjfontaine>trevnorris: anything you have you want in 0.11?
20:12:07  <trevnorris>for this release, not today.
20:12:20  <tjfontaine>ok, changelog time
20:12:32  <trevnorris>bnoordhuis: awesome, thanks for the tips. :)
20:13:32  <bnoordhuis>np
20:13:56  <indutny>bnoordhuis: hey you :)
20:14:00  <bnoordhuis>hey me
20:14:02  <indutny>https://github.com/joyent/node/pull/6114
20:14:08  <indutny>tests are passing
20:14:11  <indutny>mostly
20:14:14  <bnoordhuis>...
20:14:19  <kellabyte>bnoordhuis: not sure if you remember my uv_async issue from friday but I fixed it but not sure why the fix works :P I was missing calling this after the uv_async_init() https://github.com/joyent/libuv/blob/master/test/benchmark-multi-accept.c#L258 what is that for and why is that required?
20:14:48  <indutny>bnoordhuis: I mean
20:14:50  <indutny>please review
20:15:20  <bnoordhuis>kellabyte: it unrefs the handle. when you call uv_run, that handle won't keep the event loop alive
20:15:34  <bnoordhuis>why that fixes things... *shrugs*
20:15:46  <kellabyte>bnoordhuis: why does that code piece do it?
20:15:53  <bnoordhuis>indutny: i'll take a peek
20:15:57  <indutny>thanks
20:16:26  <bnoordhuis>kellabyte: i think i was being lazy
20:16:50  <bnoordhuis>didn't feel like having to close the async handle explicitly
20:17:08  * inolenquit (Quit: Leaving.)
20:17:22  <kellabyte>bnoordhuis: can you explain what you mean by "won't keep the event loop alive"? I'm not sure what that means and what closing an async handle means
20:17:23  * inolenjoined
20:17:29  * dapjoined
20:17:38  <bnoordhuis>kellabyte: okay, the event loop has this concept of a reference count
20:17:48  <bnoordhuis>when you create a new handle, the reference count is incremented
20:17:59  <bnoordhuis>when you close a handle, it gets decremented
20:18:08  * TooTallNatejoined
20:18:14  <bnoordhuis>when you call uv_run(loop, UV_RUN_DEFAULT), it won't return until the refcount is zero
20:18:36  <bnoordhuis>that's normally what you want but sometimes you want a handle not to keep the event loop alive
20:18:51  <bnoordhuis>e.g. in node we have a uv_signal_t handle for catching signals
20:19:04  <bnoordhuis>we always want it active but we don't want it to keep node alive if it's the last handle left
20:19:14  <kellabyte>ah
20:20:10  <kellabyte>ok so that part makes sense, but it doesn't make sense to me why the multi-accept example would want to do that
20:21:01  <bnoordhuis>well, i probably did it so i don't have to uv_close() the async handle
20:21:21  <bnoordhuis>iow, i was being lazy because cleaning up after yourself is the right thing to do, of course
20:21:40  * dapquit (Ping timeout: 245 seconds)
20:21:48  <kellabyte>because if I recall last night get_listen_handle() calls uv_run() but doesn't block
20:22:33  <bnoordhuis>apropos nothing, go to google.com and type 'do a '
20:23:11  <kellabyte>so if it exits the event loop, I'm confused how anything still works and connections get accepted
20:23:37  <bnoordhuis>kellabyte: multi-accept has multiple event loops
20:24:08  <bnoordhuis>i realize you may not be talking about the multi-accept benchmark anymore :)
20:24:25  <kellabyte>bnoordhuis: I'm using it as an example because thats what I used
20:24:30  <kellabyte>and still trying to reason how this works :P
20:24:57  <kellabyte>I think I'm not fully understanding how libuv works under the hood yet which causes a lot of the abstraction confusion
20:25:18  <bnoordhuis>how do you think it works?
20:25:46  <bnoordhuis>'pixies and magic dust' is only half-right btw
20:25:47  <kellabyte>well, I figure threads like IOCP threads are pushing events into the event loop which get run on the single thread pulling from it
20:25:51  <kellabyte>haha
20:25:57  * dshaw_quit (Quit: Leaving.)
20:26:36  <bnoordhuis>what you say is mostly correct on windows, mostly incorrect on unices
20:27:08  * bradleymeckquit (Quit: bradleymeck)
20:28:17  <bnoordhuis>when you say 'single thread', do you mean 'per event loop' or 'per process'?
20:28:33  <kellabyte>per event loop
20:28:36  <kellabyte>is that wrong?
20:29:12  <kellabyte>pretty sure when I added 3 event loops I saw 3 new threads at debug time
20:29:56  <bnoordhuis>no, that's correct. you need to create the threads yourself though, libuv doesn't do it for you
20:30:27  <bnoordhuis>but i'm pretty sure you're doing that, i remember seeing calls to uv_thread_create in your code
20:30:59  <kellabyte>yup
20:31:08  <kellabyte>which is your code :P
20:31:16  <kellabyte>you know your code well sir! lol
20:31:23  <bnoordhuis>hah, okay
20:31:50  * c4miloquit (Remote host closed the connection)
20:32:06  <bnoordhuis>okay, so far, so good. one event loop per thread. from there on, you create handles, call uv_run() and wait for the action to happen
20:32:38  <kellabyte>right, and ref count decides if that thread stops pulling off the event loop when its empty?
20:32:53  * c4milojoined
20:33:43  * jmar777quit (Remote host closed the connection)
20:33:48  <bnoordhuis>there is no 'pulling off' as such
20:33:57  <trevnorris>bnoordhuis: how would _you_ fix the FSReqWrap not passing object issue?
20:34:12  * bradleymeckjoined
20:34:13  <bnoordhuis>you call uv_run(), libuv starts waiting for events, once the refcount drops to zero, it returns
20:35:02  <bnoordhuis>the refcount is purely handle based and only when the handle is actually doing something (reading, writing)
20:35:28  <bnoordhuis>trevnorris: change FSReqWrap so it calls ReqWrap<uv_fs_t>(Object::New())?
20:37:03  <tjfontaine>https://gist.github.com/tjfontaine/6442527 verify please and thank you
20:37:10  <tjfontaine>lemme know if you think I dropped something
20:37:13  <trevnorris>bnoordhuis: heh, ok. for some reason thought that solution was too easy. :)
20:37:52  <tjfontaine>erm the upgrades dont' really come with user names, but anyway
20:38:20  * kevinswiberquit (Read error: Connection reset by peer)
20:38:27  <tjfontaine>git log --first-parent --graph --pretty=format:'%h%d %s (%an)' v$(head -n1 ChangeLog | awk '{ print $3 }')^..HEAD | sort -k 3
20:38:32  <tjfontaine>is the basic list I work from
20:38:46  <bnoordhuis>tjfontaine: maybe mention that unknown command line options are no longer silently ignored
20:38:49  * kevinswiberjoined
20:38:53  <trevnorris>strange. I might be stepping on someone else's memory. I'm getting flag like 53772037
20:38:57  <tjfontaine>bnoordhuis: ok
20:39:19  <bnoordhuis>tjfontaine: and that --max-stack-size got removed
20:39:23  <tjfontaine>bnoordhuis: they throw an error?
20:39:27  <bnoordhuis>though few people care probably
20:39:36  <bnoordhuis>yeah, it prints an error and exits
20:39:49  <bnoordhuis>trevnorris: you probably didn't initialize it
20:40:24  <trevnorris>bnoordhuis: in the constructor first line I have async_flags_ = 0;
20:40:35  <tjfontaine>updated
20:41:24  <bnoordhuis>trevnorris: it's a good habit to initialize with : async_flags_(0)
20:41:35  <trevnorris>cool thanks
20:42:11  <bnoordhuis>tjfontaine: lgtm
20:42:26  <tjfontaine>bnoordhuis: mk
20:43:27  <tjfontaine>s/rewriten/rewritten/ heh
20:43:39  <tjfontaine>I'm not sure if there's more information that should be included about the vm rewrite
20:44:22  <tjfontaine>Domenic_: do you have a good 50~ish character description of the vm rewrite?
20:45:38  <trevnorris>bnoordhuis: sorry, mind taking another quick look? you'll probably catch what I'm doing wrong in a second: https://github.com/trevnorris/node/commit/f60729a
20:46:21  <trevnorris>and sorry, didn't completely understand how you'd use AsyncWrap::has_async_listeners()
20:46:31  * kevinswiberquit (Remote host closed the connection)
20:46:42  <isaacs>aww... a ryah appeared and I missed it :)
20:46:51  <isaacs>ircretary: where's ryah
20:46:51  <ircretary>isaacs: I'm not sure what to do with that command. Ask for help in PM.
20:46:54  <isaacs>ircretary: where is ryah
20:46:55  <ircretary>isaacs: ryah was last seen at 2013-09-04T19:57:59.732Z, quit: Quit: Lost terminal #libuv
20:47:27  <bnoordhuis>trevnorris: rather than exposing the flags field directly, make it accessible only through accessors that get/set a specific flag
20:47:36  <bnoordhuis>iow, data encapsulation
20:47:43  <tjfontaine>isaacs: changelog review please and thank you
20:47:52  <trevnorris>bnoordhuis: ah, coolio.
20:48:14  * dapjoined
20:48:22  <isaacs>tjfontaine: link?
20:48:33  <isaacs>ah, found https://gist.github.com/tjfontaine/6442527
20:48:38  <tjfontaine>aye
20:50:05  <isaacs>hmm... just noticed something odd
20:50:14  <isaacs>if you have a file called --foo.js, node can't run it
20:50:15  <isaacs>because * cli: unknown command line options are errors (Ben Noordhuis)
20:50:49  <isaacs>guess that never worked, thogh
20:51:01  <tjfontaine>because it would pass it along to v8?
20:51:20  <isaacs>v0.10:
20:51:20  <isaacs>$ ./node --asdf.js
20:51:20  <isaacs>Error: unrecognized flag --asdf.js
20:51:20  <isaacs>Try --help for options
20:51:20  <isaacs>>
20:51:32  <isaacs>master:
20:51:33  <isaacs>$ ./node --asdf.js
20:51:33  <isaacs>./node: bad option: --asdf.js
20:51:41  <isaacs>i guess master's behavior is strictly better.
20:51:53  <isaacs>but it'd be nice if -- worked like it does with other unix tools
20:52:29  <tjfontaine>as in passed the following as arguments onto the next thing?
20:53:10  <bnoordhuis>that's reasonably straightforward to implement now, actually
20:53:38  <isaacs>tjfontaine: as in, -- means "no more args coming, everything from here on out are positionals"
20:53:41  <isaacs>no more flags
20:53:47  <isaacs>so ./node -- --asdf.js would run --asdf.js
20:54:06  <isaacs>to create the file, i had to vim -- --asdf.js, so it's reasonable to use the same syntax, i think
20:54:39  <isaacs>anyway, no rush
20:54:46  <isaacs>it's been weird like that forever :)
20:54:51  <tjfontaine>heh
20:55:00  <isaacs>tjfontaine: only minor changes: https://gist.github.com/isaacs/6442715
20:55:09  <isaacs>tjfontaine: expanded two abbreviations. otherwise lgtm
20:55:16  <trevnorris>bnoordhuis: oh shit. I didn't clean up an old declaration of the method in HandleWrap. :P
20:55:20  * rendarquit (Ping timeout: 268 seconds)
20:55:29  <tjfontaine>isaacs: okey dokey
20:57:13  <bnoordhuis>indutny: left some comments
20:57:38  <isaacs>right now, -- stops parsing args *altogether*
20:57:46  <trevnorris>ha ha! this is working out even better than I thought it would.
20:57:50  <isaacs>so `./node -- --asdf.js` drops you into a repl
20:57:56  <trevnorris>bnoordhuis: thanks a lot dude. this is going to rock.
20:58:15  <tjfontaine>isaacs: so when I hit a duplicate author with different emails do I prefer the original?
20:59:27  <isaacs>tjfontaine: yeah, i'd just leave them in the AUTHORS file with the email we already have
20:59:27  <isaacs>tjfontaine: if they want ti chagned, they can send us a patch
20:59:27  <tjfontaine>ok
20:59:27  <trevnorris>do we know it's not two different contributors w/ the same name :P
20:59:27  * dshaw_joined
20:59:48  <tjfontaine>la la la
20:59:57  <tjfontaine>we could probably figure that out based on github id I guess
21:00:04  <tjfontaine>anyway I'm continuing on :)
21:01:09  <isaacs>tjfontaine: it'd be nice if we just listed github accounts in the AUTHORS file and changelog.
21:01:22  <isaacs>but node started before github was nearly as popular as it is now
21:01:39  <MI6>joyent/node: tjfontaine created branch v0.11.7-release - http://git.io/fdhNzA
21:01:47  <tjfontaine>isaacs: indeed
21:01:49  <Domenic_>tjfontaine: vm: rewritten to make changes to globals work, even for async code? maybe?
21:01:55  <tjfontaine>oh man.
21:03:29  <tjfontaine>Domenic_: hm I think I'm going to use that in the email/blog
21:04:20  <MI6>node-review: #85 ABORTED http://jenkins.nodejs.org/job/node-review/85/
21:04:24  <Domenic_>tjfontaine: isaacs may have better ideas. unfortunately gtg right now
21:04:28  <tjfontaine>mk
21:06:06  * hzquit (Ping timeout: 264 seconds)
21:09:57  <trevnorris>indutny: ah, that's why you added HandleWrap::Self(), because you needed the object, which is a protected member.
21:10:25  * tooxiequit (Ping timeout: 245 seconds)
21:12:18  <isaacs>tjfontaine: vm: rewritten to work like you all thought it did
21:12:34  <isaacs>tjfontaine: it's not just async code, but nested globals, as well
21:13:13  <isaacs>tjfontaine: var o = {foo:{bar:'boo'}}; vm.runInNewContext('foo.bar = "baz", o); assert(o.foo.bar === 'baz');
21:13:17  <isaacs>tjfontaine: that would have failed before
21:14:07  <isaacs>oh, no, it wouldn't... different thing
21:16:35  <isaacs>this would fail, though: o = {assert:assert}; o.o = o; vm.runInNewContext('assert(o === this)', o)
21:16:59  <trevnorris>othiym23, creationix: now you can peer into the guts of node: https://github.com/trevnorris/node/commit/86aaa30
21:20:18  <trevnorris>ok, the tls stuff is being a little tricky
21:24:56  <kellabyte>bnoordhuis: sorry got interrupted at my desk, will read up in a bit :P sorry!
21:26:25  <mmalecki>found something interesting about node v0.10 crypto, I think that Sly mentioned it before. in some cases CleartextStream would emit an error which isn't handled by SecurePair
21:26:45  <mmalecki>error looks like: cleartext [Error: 140735274828160:error:0906D06C:PEM routines:PEM_read_bio:no start line:../deps/openssl/openssl/crypto/pem/pem_lib.c:703:Expecting: CERTIFICATE
21:27:37  <mmalecki>it appears to come from SlabBuffer.use and the fn passed to it
21:28:11  * defunctzombie_zzchanged nick to defunctzombie
21:31:26  <trevnorris>tjfontaine: you're familiar w/ setImmediate, have a sec?
21:33:05  <MI6>nodejs-master-windows: #322 UNSTABLE windows-x64 (21/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/322/
21:34:38  <mmalecki>https://gist.github.com/mmalecki/f1ede09f3e5ffc97f969 - here's a stacktrace of a crashing process
21:35:55  * brsonquit (Ping timeout: 264 seconds)
21:37:03  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:41:36  * bradleymeckquit (Quit: bradleymeck)
21:48:24  <trevnorris>wtf: assert(0 && "wtf?");
21:50:36  * saghulquit (Read error: No route to host)
21:51:30  <mmalecki>I created an issue about it: https://github.com/joyent/node/issues/6179
21:51:40  * Damn3dquit (Ping timeout: 245 seconds)
21:52:09  <trevnorris>mmalecki: i'll assume that's v0.10?
21:52:16  <mmalecki>trevnorris: yessir
21:52:32  <trevnorris>thanks
21:52:33  <mmalecki>trevnorris: I have yet to test on v0.11
21:52:56  <trevnorris>i dunno. just wanted to know so I could set the milestone
21:53:12  <trevnorris>and i dunno why I said i dunno
21:55:24  * c4miloquit (Remote host closed the connection)
21:58:41  <tjfontaine>trevnorris: sorry I was away for a bit, am back now to finish up the 0.11 release, what up
21:58:51  <tjfontaine>oh windows is still building
21:59:04  <trevnorris>tjfontaine: eh, nm. for another day.
21:59:15  <tjfontaine>trevnorris: hehe ok, preview of the question?
22:00:15  <trevnorris>tjfontaine: wanted to see if I could handle the asyncListener check from C++ so it could be handled from MakeCallback
22:00:27  <trevnorris>but then I realized that it has it's own processing loop
22:00:40  <trevnorris>so the code has to be injected into the JS side anyways
22:01:12  <trevnorris>now, is there a way to tell C++ to run constructors w/ class inheritance in a specific order?
22:01:14  <tjfontaine>right that's an implementation detail, it could potentially be done from C++
22:01:21  <tjfontaine>trevnorris: yup
22:01:26  <trevnorris>eh, it's faster from js
22:02:01  <trevnorris>oh yey, I need the object created by ObjectWrap to be passed to another constructor.
22:02:13  <trevnorris>if that's possible life will be so awesome.
22:03:41  <tjfontaine>show me what you mean
22:03:46  <isaacs>trevnorris: that's gotta be mine :)
22:04:11  <isaacs>yep
22:04:12  <isaacs>5b8e1dab (Isaac Z. Schlueter 2011-09-06 16:13:05 -0700 234) assert(0 && "wtf?");
22:04:20  <isaacs>also:
22:04:20  <isaacs>5b8e1dab (Isaac Z. Schlueter 2011-09-06 16:13:05 -0700 431) assert(0 && "wtf?");
22:04:37  * saghuljoined
22:05:19  <trevnorris>tjfontaine: https://github.com/trevnorris/node/commit/d370260
22:05:26  <tjfontaine>trevnorris: http://stackoverflow.com/a/4037283
22:05:38  <trevnorris>tjfontaine: so ObjectWrap creates an object, I need that object passed to AsyncWrap
22:06:56  <trevnorris>tjfontaine: thanks. got it working
22:07:08  <trevnorris>just had the wrong order
22:07:51  <tjfontaine>mk :)
22:09:02  <trevnorris>ok, cares_wrap is something strange.
22:12:07  * philipsquit (Ping timeout: 260 seconds)
22:16:30  * c4milojoined
22:17:18  <tjfontaine>here we go, let's try another run at the post-build script this time for unstable
22:18:11  <MI6>joyent/node: tjfontaine created tag v0.11.7 - http://git.io/Qw22_g
22:18:25  <MI6>joyent/node: Timothy J Fontaine master * 5b1a0e6 : Now working on 0.11.8 (+2 more commits) - http://git.io/3I8fDQ
22:19:05  <tjfontaine>hmm
22:21:10  <trevnorris>tjfontaine: ok, so now it seems I have a race condition, that the Object created by ObjectWrap sometimes isn't actually created until after the instantiation of the ZCtx class.
22:21:29  <trevnorris>so my assertion in AsyncWrap sporadically fails
22:23:44  <trevnorris>oh wait. nm.
22:23:51  * TooTallNatejoined
22:23:52  <trevnorris>the entire logic chain is busted.
22:24:00  * bnoordhuisquit (Ping timeout: 240 seconds)
22:24:07  <trevnorris>i'm not even sure how it passed in the first place
22:27:35  <MI6>joyent/node: Timothy J Fontaine v0.10 * 8b05206 : blog: Post for v0.11.7 - http://git.io/3Jveyg
22:35:35  <MI6>joyent/node: Timothy J Fontaine master * 8ee50ce : Merge remote-tracking branch 'upstream/v0.10' (+6 more commits) - http://git.io/83io0w
22:36:41  <MI6>nodejs-master: #529 UNSTABLE osx-x64 (1/644) osx-ia32 (1/644) linux-x64 (1/644) smartos-x64 (7/644) linux-ia32 (1/644) http://jenkins.nodejs.org/job/nodejs-master/529/
22:36:51  * dshaw_quit (Quit: Leaving.)
22:41:24  * brsonjoined
22:46:11  <MI6>nodejs-v0.10: #1465 UNSTABLE smartos-x64 (3/598) osx-x64 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1465/
22:47:16  <MI6>nodejs-master: #530 UNSTABLE smartos-x64 (6/644) http://jenkins.nodejs.org/job/nodejs-master/530/
22:47:22  <MI6>node-review: #86 UNSTABLE windows-ia32 (21/644) centos-x64 (1/644) centos-ia32 (6/644) windows-x64 (20/644) osx-x64 (1/644) smartos-x64 (6/644) http://jenkins.nodejs.org/job/node-review/86/
22:48:05  * dshaw_joined
22:48:46  * AvianFluquit (Remote host closed the connection)
22:50:58  * dominictarrquit (Quit: dominictarr)
22:54:05  <trevnorris>isaacs: ping
22:54:16  <isaacs>pong
22:54:30  <trevnorris>trying out the counters w/ benchmarks:
22:54:38  <trevnorris>fs/readfile.js dur=5 len=1024 concurrent=10: 34288
22:54:42  <trevnorris>COUNTER: 685902
22:55:04  <trevnorris>that is a lot of async events in 5 seconds :)
22:55:17  <tjfontaine>see, and you think our throughput is low
22:55:18  <tjfontaine>:P
22:55:23  <trevnorris>heh
22:57:36  <trevnorris>tjfontaine: my thought is, though, that is a lot of request objects we're instantiating.
22:59:15  <trevnorris>tjfontaine: and I just wonder if there's something we could do to reuse those after a request
22:59:16  * philipsjoined
22:59:18  <tjfontaine>you want a freelist?
22:59:42  <tjfontaine>trevnorris: it's certainly somethign that could be done for 1.0
22:59:53  <trevnorris>cool.
23:00:36  <tjfontaine>it'd be interesting to see at what number of cached objects you actually start to see benefit
23:01:44  <tjfontaine>can also do the unref timers for eventual drain so that they're not always munching memory
23:02:21  <trevnorris>wtf. net/dgram.js len=1 num=100 type=send dur=5
23:02:29  <trevnorris>nextTick: 1596203
23:02:39  <tjfontaine>async dns lookup probably
23:02:55  <trevnorris>but still. 1.5 million in 5 sec.
23:02:59  <tjfontaine>every send requires a lookup if it's using localhost
23:03:05  <trevnorris>ah, ok
23:03:35  <tjfontaine>well, every send requires at least one tick for deferral, either a real dns request will happen, or a nextTick because we know the answer (or it's already an ip)
23:04:51  <trevnorris>this is fun
23:07:51  <isaacs>trevnorris: that's some rad info.
23:07:59  <MI6>nodejs-master-windows: #323 UNSTABLE windows-x64 (22/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/323/
23:08:00  <trevnorris>:)
23:08:10  <trevnorris>honestly i'm surprised how little performance impact it's having
23:08:24  <isaacs>trevnorris: well, nextTick would be worse if it was a real timer
23:08:39  <isaacs>trevnorris: 1.5MM is not that much for a while(true) loop
23:08:47  <trevnorris>hah, ok. true enough
23:08:57  <isaacs>but yeah, still, it's not free.
23:09:04  <isaacs>if you could cut that down, it'd probably go faster.
23:10:09  <trevnorris>isaacs: so have any thoughts on https://github.com/trevnorris/node/blob/d9e573d
23:10:35  <trevnorris>basically anything c++ that will create an asynchronous request will inherit from this.
23:11:00  <trevnorris>and by simply setting flag state we know going into MakeCallback whether we have object properties to check
23:11:58  <trevnorris>so i'm going to do the same thing with before/after, and then we can remove all the domain specific code at essentially zero cost
23:12:58  <trevnorris>and checking if there are async listeners active is also practically zero since it simply sets a bit in external memory (like the tick info box stuff)
23:13:38  <trevnorris>but add to that we pre-send the array that contains the listeners, and persist it so the only cost there is the actual call to js
23:13:45  <isaacs>right
23:14:04  <isaacs>seems like a reasonable thing to try
23:14:07  <isaacs>go for it :)
23:14:10  <trevnorris>:)
23:17:06  <trevnorris>HOOAH for _rawDebug!
23:18:36  <tjfontaine>hueniverse: btw, in case you missed it, you have your v0.11 release with your much awaited timer fix
23:19:09  <isaacs>tjfontaine: yeah, good call omitting that from the ChangeLog ;)
23:19:15  <isaacs>tjfontaine: (rawDebug, i mean)
23:20:20  * amartensjoined
23:22:15  <tjfontaine>isaacs: hehe, noone needs to know :P
23:26:46  * groundwaterquit (Quit: groundwater)
23:28:35  <MI6>nodejs-v0.10-windows: #193 UNSTABLE windows-ia32 (8/598) windows-x64 (6/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/193/
23:30:30  <othiym23>is _rawDebug non-enumerable?
23:41:24  * julianduquequit (Remote host closed the connection)
23:42:07  * julianduquejoined
23:54:54  <MI6>nodejs-master-windows: #324 UNSTABLE windows-x64 (21/644) windows-ia32 (19/644) http://jenkins.nodejs.org/job/nodejs-master-windows/324/
23:56:44  * mikealquit (Quit: Leaving.)
23:59:02  * mikealjoined
23:59:51  <MI6>libuv-master-gyp: #161 UNSTABLE windows-x64 (3/194) smartos-ia32 (2/193) windows-ia32 (3/194) linux-ia32 (1/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/161/