00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:04:03  * mnunbergjoined
00:08:53  * bnoordhuisquit (Ping timeout: 245 seconds)
00:09:27  <tjholowaychuk>is there a windows reason for not having fs.mktemp?
00:12:41  <MI6>libuv-master-gyp: #144 UNSTABLE windows-x64 (4/194) windows-ia32 (4/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/144/
00:14:12  * contrahaxjoined
00:16:47  * mikealquit (Quit: Leaving.)
00:20:00  * EhevuTovquit (Quit: This computer has gone to sleep)
00:27:45  * kazuponjoined
00:32:06  * kazuponquit (Ping timeout: 245 seconds)
00:32:46  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:37:49  * spionquit (Ping timeout: 246 seconds)
00:47:06  * bradleymeckjoined
00:50:36  * TooTallNatejoined
00:52:40  * AvianFlu_quit (Remote host closed the connection)
00:59:25  * AvianFlujoined
00:59:27  * tjholowaychukquit (Quit: Linkinus - http://linkinus.com)
01:03:22  * bradleymeckquit (Ping timeout: 240 seconds)
01:04:29  * bradleymeckjoined
01:04:41  * bradleymeckquit (Client Quit)
01:07:35  * jmar777joined
01:11:55  * mnunbergquit (Ping timeout: 264 seconds)
01:15:29  * bnoordhuisjoined
01:15:44  * jmar777quit (Remote host closed the connection)
01:16:55  * avalanche123joined
01:17:14  * ecrquit (Quit: ecr)
01:17:52  * avalanche123quit (Read error: Connection reset by peer)
01:20:16  * bnoordhuisquit (Ping timeout: 264 seconds)
01:27:21  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:28:23  * kazuponjoined
01:32:13  * amartensquit (Quit: Leaving.)
01:33:06  * kazuponquit (Ping timeout: 264 seconds)
01:45:51  * pachetquit (Quit: [ +++ ])
01:47:48  * kazuponjoined
01:48:21  * mnunbergjoined
01:48:26  * AvianFluquit (Remote host closed the connection)
01:48:46  * dshaw_quit (Quit: Leaving.)
01:49:37  * Gateway69joined
01:50:07  <Gateway69>hey, not sure if anyone can help but we are seeing a crash in ringbuffer with high concurrency testing on our servers..
01:50:07  <Gateway69>Program terminated with signal 11, Segmentation fault.
01:50:07  <Gateway69>#0 0x00007f29dceb7515 in ringbuffer_ensure_capacity (buffer=0x0, size=32768) at src/ringbuffer.c:62
01:50:08  <Gateway69>62 lcb_size_t new_size = buffer->size << 1;
01:50:17  <Gateway69>any ideas.. hard to track this down
01:52:28  * AvianFlujoined
01:54:24  * kazuponquit (Ping timeout: 256 seconds)
01:55:08  * AvianFluquit (Remote host closed the connection)
01:58:33  <creationix>trevnorris, I should have time to test your branch tomorrow
02:02:24  * mnunbergquit (Ping timeout: 268 seconds)
02:05:07  * mnunbergjoined
02:11:49  * TooTallNatejoined
02:12:55  * julianduquequit (Ping timeout: 260 seconds)
02:15:01  * indexzerojoined
02:15:29  * c4milojoined
02:39:24  * mnunbergquit (Ping timeout: 268 seconds)
02:53:50  * dshaw_joined
02:54:19  * indexzeroquit (Quit: indexzero)
02:58:38  * indexzerojoined
02:59:56  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:04:56  * kazuponjoined
03:06:47  * mnunbergjoined
03:07:39  * c4miloquit (Remote host closed the connection)
03:08:35  * julianduquejoined
03:18:42  * mnunbergquit (Ping timeout: 264 seconds)
03:27:57  * st_lukequit (Remote host closed the connection)
04:00:08  * dapquit (Quit: Leaving.)
04:06:00  * dshaw_quit (Quit: Leaving.)
04:20:30  * wolfeidauquit (Remote host closed the connection)
04:20:51  * wolfeidaujoined
04:40:38  * indexzeroquit (Quit: indexzero)
04:43:50  * amartensjoined
04:44:13  * indexzerojoined
04:45:57  * mnunberg_joined
04:56:57  <isaacs>good evening heroes.
04:58:13  * st_lukejoined
04:58:25  * indexzeroquit (Quit: indexzero)
05:00:35  * indexzerojoined
05:02:09  <MI6>joyent/node: Bert Belder execSync-wip * 289f3e2 : spawn_sync: implement bindings - http://git.io/ZPZNYQ
05:06:07  * indexzeroquit (Quit: indexzero)
05:09:14  * indexzerojoined
05:15:25  * indexzeroquit (Quit: indexzero)
05:19:28  <MI6>joyent/node: Bert Belder execSync-wip * 7b7ec61 : spawn_sync: implement bindings - http://git.io/0l2VtQ
05:28:54  <MI6>joyent/node: Domenic Denicola master * 02fde58 : vm: document vm2's changes. (+1 more commits) - http://git.io/yRP8XA
05:29:25  <isaacs>Domenic_: ^ thanks
05:33:51  <MI6>node-review: #74 UNSTABLE smartos-ia32 (1/641) linux-ia32 (4/641) linux-x64 (2/641) windows-x64 (17/641) smartos-x64 (7/641) centos-ia32 (3/641) centos-x64 (1/641) windows-ia32 (16/641) http://jenkins.nodejs.org/job/node-review/74/
05:42:23  <isaacs>anyone around?
05:42:32  <MI6>nodejs-master: #504 UNSTABLE smartos-x64 (8/645) osx-ia32 (1/645) smartos-ia32 (5/645) osx-x64 (1/645) http://jenkins.nodejs.org/job/nodejs-master/504/
05:52:10  * brsonquit (Ping timeout: 240 seconds)
05:52:45  * brsonjoined
05:53:53  <Domenic_>isaacs: wanted to make sure you saw https://github.com/joyent/node/pull/6121#issuecomment-23468438
05:54:00  <isaacs>Domenic_: yeah, i did
05:54:05  <Domenic_>:)
05:54:09  <isaacs>Domenic_: for stuff like this, i really like it being in JS rather than C++
05:54:24  <isaacs>Domenic_: i've got it working already, just wiating for tests to pass
05:54:31  <isaacs>then rebasing the better repl syntax error detection
05:54:37  <Domenic_>isaacs: yeah, I was thinking about that... would have to re-do Script to no longer be a C++ class
05:54:53  <isaacs>well, just need to move runInContext to _runInContext
05:55:02  <isaacs>and likewise *ThisContext
05:55:28  <isaacs>also.. lemme know what you think of this:
05:55:33  <Domenic_>right, i guess so. seems unfortunate, as it adds a line to all the stack traces.
05:55:50  <isaacs>so, script.runInNewContext(sandbox)
05:55:58  <isaacs>that calls createContext(sandbox)
05:56:07  <isaacs>and then script.runInContext(sandbox), for some resaon, doesn'.
05:56:30  <isaacs>but since it's safe to call createContext(obj) if it's already contextified ,why notjust make them the same function?
05:57:02  <isaacs>hmmm.. yeah, that extra line is a bit unfortunate, huh?
05:57:02  <isaacs>Error: boo! at test.vm:1:7 at ContextifyScript.Script.runInThisContext (vm.js:43:15) at Object.exports.runInThisContext (vm.js:91:17) at Object.<anonymous> (/Users/isaacs/dev/js/node-master/test/message/vm_dont_display_runtime_error.js:37:4)
05:57:15  <isaacs>https://gist.github.com/isaacs/6374651
05:57:48  * st_lukequit (Remote host closed the connection)
05:57:57  <Domenic_>same function, yeah, probably worth doing. the only difference currently is the argument defaulting behavior
05:58:07  <isaacs>right
05:58:18  <isaacs>basically, the only difference is that runInContext is a bit of a dick
05:58:36  <isaacs>i have a hard time justifying that
05:59:24  <Domenic_>yeah maybe just un-document runInContext and then alias it to runInNewContext
06:00:26  <Domenic_>this actually makes vm.createContext almost entirely unnecessary too
06:00:59  <Domenic_>i guess its use case would be to save whatever the contextify overhead is so that the first user doesn't hit it. e.g. if you were runInNewContext'ing every request.
06:01:49  <isaacs>yeah, but with the same context object?
06:02:08  <isaacs>oh, the contextify overhead
06:02:13  <isaacs>it's just the isContext() overhead, though
06:02:19  <isaacs>it still only gets contextified once.
06:02:46  <Domenic_>yup
06:02:58  <Domenic_>but the first user pays that instead of you paying that on server startup
06:03:43  <MI6>nodejs-master-windows: #297 UNSTABLE windows-x64 (17/645) windows-ia32 (18/645) http://jenkins.nodejs.org/job/nodejs-master-windows/297/
06:05:09  <isaacs>Domenic_: well you can still do createContext() explicitly, i guess
06:05:31  <isaacs>Domenic_: it'd be nice to have an ircbot that gave each user their own context.
06:05:41  <isaacs>like a little repl-bot or something
06:05:59  <Domenic_>isaacs: yeah, i was just idly speculating that maybe we could un-document createContext too and slim down the API surface even more
06:06:13  <isaacs>Domenic_: we can't un-document anything
06:06:18  <isaacs>but we can move it to the bottom :)
06:06:22  <Domenic_>lol
06:06:31  <isaacs>hardly anyone reads more than the table of contents anyway
06:07:00  <Domenic_>why not? I thought as long as old code kept working, we could un-document stuff. I dunno why, I guess that made sense in my head?
06:09:51  <isaacs>hahah
06:09:57  * brsonquit (Quit: leaving)
06:10:03  <isaacs>well, it just means explicitly dropping support for it
06:10:05  * mnunberg_quit (Quit: leaving)
06:10:17  <isaacs>some time in the future, someone'll say "it's not even documented! who cares if we break it?!"
06:10:30  <isaacs>and some por schlub won't be able to upgrade from 0.6 to 1.2 because of that
06:12:03  <Domenic_>fair
06:13:19  <isaacs>anyway...
06:13:23  <isaacs>i think i've got it working
06:14:25  * dshaw_joined
06:17:42  <isaacs>actually the extra line in the stack trace isn't all that bad
06:18:09  <isaacs>i mean, you're doing vm.runInContext(...) and then you get that, and also a ContextifyScript.Script.runInContext
06:18:14  <isaacs>and that's actually what's happening anyway
06:20:39  <Domenic_>yeah i guess
06:23:32  <isaacs>oh man... using V8's lexer to catch syntax errors, instead of just evaling and whackamole-ing
06:23:40  <isaacs>Domenic_: this is so nice.
06:23:50  <isaacs>i don't know why i didn't think of doing new Script before
06:23:54  <isaacs>this has always bugged me
06:25:00  <Domenic_>haha :)
06:25:18  <Domenic_>It'll be even nicer once displayErrors gets killed
06:25:46  <MI6>node-review: #75 UNSTABLE osx-ia32 (1/641) windows-x64 (18/641) smartos-x64 (5/641) centos-ia32 (3/641) centos-x64 (1/641) windows-ia32 (17/641) http://jenkins.nodejs.org/job/node-review/75/
06:29:43  <isaacs>yeah, totally
06:29:46  <isaacs>hate that kludge
06:50:46  <MI6>nodejs-v0.10-windows: #182 UNSTABLE windows-x64 (7/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/182/
07:02:55  * kazuponquit (Remote host closed the connection)
07:03:10  * kazuponjoined
07:03:17  <Domenic_>isaacs: I don't get why you are supporting number options. Timeout only existed for like the 0.11.3 to 0.11.6 timeframe.
07:03:40  <isaacs>Domenic_: hm. yeah, i suppose so
07:03:48  * dshaw_quit (Quit: Leaving.)
07:04:21  * dominictarrjoined
07:04:25  <isaacs>it was just easy to do the thing for all the things
07:04:59  <isaacs>Domenic_: what can i say? i have a big heart. i don't like user programs to break, even ones that use undocumented features that were just now introduced in versions no one is using.
07:07:30  <Domenic_>isaacs: but, you could remove 10 lines of code! sigh
07:07:31  <isaacs>Domenic_: well, comment on the pr if you like. i'm off to bed, and might not remember any of this :)
07:07:49  <Domenic_>isaacs: good plan, i should go back to bed too
07:07:57  * isaacs&
07:09:39  * defunctzombie_zzchanged nick to defunctzombie
07:26:10  * rendarjoined
07:28:47  * amartensquit (Quit: Leaving.)
07:31:29  * csaohjoined
07:57:59  * defunctzombiechanged nick to defunctzombie_zz
07:58:48  * LeftWingquit (Remote host closed the connection)
07:59:01  * amartensjoined
08:01:47  * defunctzombie_zzchanged nick to defunctzombie
08:06:06  * amartensquit (Ping timeout: 264 seconds)
08:06:33  * defunctzombiechanged nick to defunctzombie_zz
08:15:00  * julianduquequit (Quit: leaving)
08:20:49  * dominictarrquit (Quit: dominictarr)
08:40:35  * bnoordhuisjoined
08:47:18  * dominictarrjoined
09:03:42  * amartensjoined
09:08:08  * amartensquit (Read error: Operation timed out)
09:11:49  * rendarquit (Read error: Operation timed out)
09:16:26  * defunctzombie_zzchanged nick to defunctzombie
09:23:50  * rendarjoined
09:25:58  * defunctzombiechanged nick to defunctzombie_zz
09:37:36  * hzjoined
09:41:23  * kazuponquit (Remote host closed the connection)
09:46:07  * hzquit (Ping timeout: 264 seconds)
09:46:52  * hzjoined
09:55:08  * JamesS237joined
10:00:57  * rendar_joined
10:01:54  * rendarquit (Ping timeout: 264 seconds)
10:04:04  * amartensjoined
10:05:03  * JamesS237quit (Quit: Page closed)
10:07:11  * abraxasjoined
10:07:43  * rendar_quit (Ping timeout: 264 seconds)
10:08:18  * amartensquit (Ping timeout: 240 seconds)
10:14:17  <abraxas>hi guys, I'm hitting weird assertion errors from libuv in node 0.10 when sending udp
10:14:30  <abraxas>../deps/uv/src/unix/udp.c:267: uv__udp_sendmsg: Assertion `!(&handle->write_queue == (&handle->write_queue)->prev) || !(&handle->write_completed_queue == (&handle->write_completed_queue)->prev)' failed.
10:14:39  <abraxas>is that something that should ever be caused from user land?
10:19:22  * mralephjoined
10:21:29  <bnoordhuis>abraxas: i just commented on the issue
10:21:33  <abraxas>thanks
10:21:39  <bnoordhuis>tl;dr can you get me a backtrace? :)
10:22:29  <abraxas>so, I have this issue in a pretty big app now, triggered by the cluster / graylog combination... I'm gonna try and get the minimal breaking situation and share that and get you your backtrace
10:22:41  <abraxas>(it's pretty late, so hope it won't become tomorrow)
10:22:45  * csaohquit (Quit: csaoh)
10:22:56  <bnoordhuis>well, you could start by turning on core dumps with ulimit -c
10:23:14  <bnoordhuis>the core dump probably contains enough information to get something useful out of
10:23:51  <bnoordhuis>you can load it into gdb with `gdb path/to/node corefile`, then you run the `backtrace full` etc. commands
10:25:04  <abraxas>alright
10:33:41  * bnoordhuisquit (Ping timeout: 248 seconds)
10:40:09  <abraxas>I'm having some trouble on the server this is happening at, so am working the minimal sample in parallel
10:40:23  <abraxas>is it normal that sending dgrams cause a worker to emit "listening"?
10:40:34  <abraxas>(on the cluster)
10:45:30  <abraxas>I do have to say, that graylog implementation is a real piece of ... ontlasting
10:46:06  <MI6>nodejs-v0.10: #1454 UNSTABLE osx-ia32 (1/598) smartos-x64 (3/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1454/
10:52:12  * csaohjoined
10:52:56  <abraxas>sorry, I'm interviewing someone now.. back later if I can
10:55:03  * spionjoined
10:55:58  * rendarjoined
11:04:21  * amartensjoined
11:05:01  * kevinswiberjoined
11:09:06  * amartensquit (Ping timeout: 264 seconds)
11:24:31  * hzquit (Ping timeout: 260 seconds)
11:34:46  * spionquit (Ping timeout: 246 seconds)
11:36:29  * kevinswiberquit (Remote host closed the connection)
11:40:24  * bnoordhuisjoined
11:45:09  * bnoordhuisquit (Ping timeout: 268 seconds)
11:48:12  * bnoordhuisjoined
12:02:22  * EhevuTovjoined
12:04:40  * amartensjoined
12:09:09  * amartensquit (Ping timeout: 248 seconds)
12:24:48  * EhevuTovquit (Quit: This computer has gone to sleep)
12:25:26  * EhevuTovjoined
12:29:35  <MI6>joyent/node: Ben Noordhuis master * a9eb96d : src: remove unused Persistent<FunctionTemplate> (+4 more commits) - http://git.io/oprVDA
12:38:50  <MI6>nodejs-master: #505 UNSTABLE smartos-x64 (7/645) http://jenkins.nodejs.org/job/nodejs-master/505/
12:39:15  <abraxas>back
12:40:31  * EhevuTovquit (Quit: This computer has gone to sleep)
12:41:44  * EhevuTovjoined
12:46:40  <abraxas>bnoordhuis: how do you want it?
12:46:49  <abraxas>full paste in the issue?
12:50:10  <abraxas>pasted it in there, looks very unhealthy :)
12:52:42  <abraxas>enjoy, 10pm here, time to go home. goodnight
12:52:51  <abraxas>weltrusten voor straks
12:53:55  <MI6>nodejs-master-windows: #298 UNSTABLE windows-x64 (16/645) windows-ia32 (16/645) http://jenkins.nodejs.org/job/nodejs-master-windows/298/
12:55:33  * abraxasquit (Remote host closed the connection)
12:58:54  * pachetjoined
12:59:15  * piscisaureus_joined
13:05:03  * amartensjoined
13:09:38  * amartensquit (Ping timeout: 268 seconds)
13:10:39  <bnoordhuis>template <typename TypeName, IntrusiveTreeNode<TypeName> TypeName::* Field>
13:10:40  <bnoordhuis>template <typename Compare>
13:10:40  <bnoordhuis>bool IntrusiveTree<TypeName, Field>::Comparator<Compare>::operator<(
13:10:40  <bnoordhuis> const IntrusiveTreeNode<TypeName>* node) const {
13:10:40  <bnoordhuis> return comp_(container_of(node));
13:10:44  <bnoordhuis>}
13:10:49  <bnoordhuis>^ c++ at its finest!
13:15:17  <MI6>joyent/libuv: piscisaureus created branch bnoordhuis-please-rubberstamp-this - http://git.io/WLHHyw
13:17:09  <MI6>joyent/libuv: Bert Belder bnoordhuis-please-rubberstamp-this * 2e74e2c : windows: make uv_shutdown() for write-only pipes work - http://git.io/VPv_dQ
13:17:33  <piscisaureus_>bnoordhuis: ^ that
13:18:39  <bnoordhuis>piscisaureus_: lgtm, i guess. no idea what it does :)
13:18:57  <MI6>joyent/libuv: Bert Belder master * 2e74e2c : windows: make uv_shutdown() for write-only pipes work - http://git.io/4Uy_3A
13:19:00  <piscisaureus_>bnoordhuis: you don't want to know
13:19:01  <bnoordhuis>btw, have you mailed sjoerd yet?
13:19:07  <piscisaureus_>bnoordhuis: about what?
13:19:22  <bnoordhuis>those questions you had
13:19:26  <piscisaureus_>eh
13:19:35  <piscisaureus_>what were they again?
13:20:02  <piscisaureus_>wasn't there something with the notaris being lazy
13:20:04  <piscisaureus_>?
13:20:13  <MI6>libuv-review: #53 FAILURE smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-review/53/
13:20:30  <piscisaureus_>eh
13:20:34  <bnoordhuis>i don't know, they were your questions :)
13:20:43  <piscisaureus_>hmm
13:21:28  <piscisaureus_>http://www.donaldduck.nl/ext/gfx/content/duckipedia/williewortel/05willie.gif
13:21:50  <MI6>joyent/libuv: Bert Belder v0.10 * 61b20e8 : windows: make uv_shutdown() for write-only pipes work - http://git.io/0dp8mw
13:24:15  <piscisaureus_>bnoordhuis: do you see any reasons not to do a libuv release/upgrade (master) ?
13:25:38  <bnoordhuis>piscisaureus_: no
13:27:04  <piscisaureus_>bnoordhuis: you're not getting mentions for removing a file and then putting it back ben
13:27:10  <piscisaureus_>:)
13:27:50  <piscisaureus_>someone cheating his way up in the shortlog
13:31:28  <MI6>libuv-master: #206 UNSTABLE windows (4/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/206/
13:31:44  * kazuponjoined
13:31:56  <MI6>joyent/libuv: piscisaureus created tag v0.11.11 - http://git.io/4ji5Rg
13:31:59  <MI6>joyent/libuv: Bert Belder master * 90874cc : Now working on v0.11.12 (+1 more commits) - http://git.io/rQtLZQ
13:32:30  <piscisaureus_>+Keno Fischer <kenof@stanford.edu> <kfischer@college.harvard.edu>
13:32:56  <piscisaureus_>loladiro is collecting elite stamps
13:34:11  <piscisaureus_>2013
13:34:14  <piscisaureus_>chrome 29
13:34:16  * mraleph1joined
13:34:28  <piscisaureus_>and still when I click a download link twice the browser downloads it twice
13:34:29  <piscisaureus_>:(
13:34:34  * mralephquit (Read error: Connection reset by peer)
13:34:49  <MI6>libuv-review: #54 UNSTABLE windows-x64 (3/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) linux-ia32 (1/193) http://jenkins.nodejs.org/job/libuv-review/54/
13:36:34  <MI6>libuv-v0.10: #111 UNSTABLE smartos (2/187) windows (3/188) http://jenkins.nodejs.org/job/libuv-v0.10/111/
13:38:10  <MI6>joyent/node: Bert Belder execSync-wip * 540521e : spawn_sync: closes pipes when killing inferior, cleanups (+2 more commits) - http://git.io/fXEklg
13:38:42  <MI6>joyent/node: Bert Belder master * e83a0cd : uv: upgrade to v0.11.11 - http://git.io/mfwKHg
13:39:15  <MI6>joyent/node: Bert Belder execSync-wip * 49d8991 : spawn_sync: closes pipes when killing inferior, cleanups (+1 more commits) - http://git.io/PBnsDQ
13:39:58  <MI6>libuv-v0.10-gyp: #75 UNSTABLE windows-x64 (4/188) smartos-ia32 (2/187) windows-ia32 (5/188) smartos-x64 (2/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/75/
13:41:56  * c4milojoined
13:45:33  * jmar777joined
13:48:33  * kevinswiberjoined
13:48:40  <MI6>libuv-master: #207 UNSTABLE linux (2/193) windows (4/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/207/
13:50:25  <MI6>libuv-master-gyp: #145 UNSTABLE windows-x64 (4/194) windows-ia32 (3/194) smartos-ia32 (3/193) smartos-x64 (4/193) http://jenkins.nodejs.org/job/libuv-master-gyp/145/
13:50:43  <MI6>joyent/node: Bert Belder execSync-wip * a0342fc : spawn_sync: report UV_ENOBUFS when output exceeds maxBuffer - http://git.io/jgkGKw
13:51:50  <MI6>joyent/node: piscisaureus created branch spawnSync-wip - http://git.io/gK49ww
13:52:05  <MI6>libuv-review: #55 UNSTABLE windows-x64 (3/194) linux-x64 (1/193) windows-ia32 (3/194) osx-x64 (1/194) smartos-ia32 (2/193) smartos-x64 (4/193) linux-ia32 (1/193) http://jenkins.nodejs.org/job/libuv-review/55/
13:52:06  <piscisaureus_>DAM
13:52:12  <piscisaureus_>stipid github interface
13:52:31  * Benviejoined
13:56:09  <MI6>libuv-node-integration: #189 UNSTABLE smartos-x64 (7/645) smartos-ia32 (4/645) osx-ia32 (3/645) linux-x64 (1/645) linux-ia32 (1/645) http://jenkins.nodejs.org/job/libuv-node-integration/189/
13:58:29  * piscisaureus_quit (Ping timeout: 248 seconds)
14:01:40  <MI6>nodejs-master: #506 UNSTABLE linux-ia32 (2/645) smartos-x64 (9/645) osx-ia32 (1/645) smartos-ia32 (1/645) osx-x64 (2/645) linux-x64 (4/645) http://jenkins.nodejs.org/job/nodejs-master/506/
14:02:37  * AvianFlujoined
14:03:59  * c4miloquit (Remote host closed the connection)
14:05:25  * amartensjoined
14:05:56  * Benviequit
14:09:45  * amartensquit (Ping timeout: 240 seconds)
14:10:52  <MI6>node-review: #76 UNSTABLE smartos-ia32 (5/645) linux-ia32 (2/645) linux-x64 (3/645) windows-x64 (15/645) smartos-x64 (7/645) osx-x64 (1/645) centos-ia32 (2/645) centos-x64 (3/645) windows-ia32 (17/645) http://jenkins.nodejs.org/job/node-review/76/
14:16:01  * kazuponquit (Remote host closed the connection)
14:17:18  <MI6>libuv-node-integration: #190 UNSTABLE smartos-x64 (1/598) smartos-ia32 (1/598) http://jenkins.nodejs.org/job/libuv-node-integration/190/
14:19:35  * EhevuTovquit (Quit: This computer has gone to sleep)
14:29:30  * Benviejoined
14:29:34  <MI6>nodejs-master-windows: #299 UNSTABLE windows-x64 (17/645) windows-ia32 (16/645) http://jenkins.nodejs.org/job/nodejs-master-windows/299/
14:29:52  <trevnorris>creationix: you mean the async listener branch? not even close to being testable.
14:29:54  * piscisaureus_joined
14:32:57  * mcavagequit (Remote host closed the connection)
14:38:19  <MI6>libuv-node-integration: #191 UNSTABLE smartos-x64 (6/645) linux-x64 (1/645) linux-ia32 (1/645) http://jenkins.nodejs.org/job/libuv-node-integration/191/
14:39:43  * AvianFluquit (Remote host closed the connection)
14:41:25  <MI6>libuv-master-gyp: #146 UNSTABLE windows-x64 (4/194) windows-ia32 (4/194) smartos-ia32 (5/193) smartos-x64 (4/193) osx-x64 (1/194) http://jenkins.nodejs.org/job/libuv-master-gyp/146/
14:41:56  * swajquit (Remote host closed the connection)
14:42:48  * `3rdEdenchanged nick to `3E|BRB
14:42:55  <creationix>trevnorris, anything I can help with?
14:43:39  <trevnorris>creationix: not right now.
14:43:52  <trevnorris>just going to put my ear plugs in and try to crank this out.
14:48:13  <creationix>trevnorris, good luck!
14:48:19  <trevnorris>thanks :)
14:55:11  * julianduquejoined
14:56:52  * piscisaureus_quit (Ping timeout: 264 seconds)
14:59:46  * trevnorris&
14:59:47  <MI6>node-review: #77 UNSTABLE smartos-ia32 (4/645) osx-ia32 (1/645) linux-ia32 (1/645) linux-x64 (1/645) windows-x64 (16/645) smartos-x64 (8/645) osx-x64 (1/645) centos-ia32 (1/645) centos-x64 (3/645) windows-ia32 (17/645) http://jenkins.nodejs.org/job/node-review/77/
15:03:34  * jmar777quit (Remote host closed the connection)
15:05:43  * amartensjoined
15:06:59  * kazuponjoined
15:10:01  * amartensquit (Ping timeout: 245 seconds)
15:11:47  <MI6>libuv-master-gyp: #147 FAILURE windows-x64 (3/194) windows-ia32 (4/194) http://jenkins.nodejs.org/job/libuv-master-gyp/147/
15:13:22  <tjfontaine>fucking, jenkins.
15:15:08  * `3E|BRBchanged nick to `3rdEden
15:17:52  <MI6>nodejs-master: #507 UNSTABLE linux-ia32 (1/645) smartos-x64 (7/645) osx-ia32 (1/645) linux-x64 (2/645) http://jenkins.nodejs.org/job/nodejs-master/507/
15:24:28  * piscisaureus_joined
15:25:57  * bnoordhuisquit (Ping timeout: 248 seconds)
15:29:45  * kazuponquit (Remote host closed the connection)
15:36:31  * csaohquit (Ping timeout: 260 seconds)
15:38:05  * csaohjoined
15:46:42  * dapjoined
15:48:52  * jmar777joined
15:50:07  * AvianFlujoined
15:51:37  * AvianFlu_joined
15:52:39  * LOUDBOTquit (K-Lined)
15:52:39  * ikquit (K-Lined)
15:52:39  * CAPSLOCKBOTquit (K-Lined)
15:53:49  * indexzerojoined
15:53:59  * jmar777quit (Remote host closed the connection)
15:55:38  * groundwaterjoined
15:55:39  * AvianFluquit (Ping timeout: 260 seconds)
15:58:55  * dshaw_joined
16:00:15  * `3rdEdenchanged nick to `3E|FOODING
16:04:30  <isaacs>good morning nodestars
16:05:48  * defunctzombie_zzchanged nick to defunctzombie
16:06:20  * defunctzombiechanged nick to defunctzombie_zz
16:07:09  <tjfontaine>good day
16:07:35  <trevnorris>isaacs, creationix, othiym23: Updated the API: https://github.com/joyent/node/pull/6011
16:07:53  <trevnorris>two main changes are, added a "done" callback which will fire when there are no more possible callbacks to be called
16:08:12  <trevnorris>and the other is to return a unique key that's used to remove from the queue.
16:08:29  <trevnorris>the later is necessary in case I want to use the same async listener, but propagate different domain objects
16:08:46  <trevnorris>the former is helpful in case there's any cleanup I want to perform.
16:09:09  * TooTallNatejoined
16:09:41  * dshaw_quit (Ping timeout: 248 seconds)
16:13:00  * defunctzombie_zzchanged nick to defunctzombie
16:13:24  <creationix>trevnorris, in your API, is the async listener called many times?
16:13:34  <creationix>IE, once for every call to setTimeout
16:13:44  <creationix>and other function calls that setup events
16:14:18  <trevnorris>creationix: the async listener is called whenever something that will require calling a callback is queued
16:14:42  <creationix>perfect
16:15:04  <creationix>though why such a large and powerful API?
16:15:21  <creationix>function(cb) { return newCb; } would be enough right?
16:16:04  <creationix>that function would be called whenever something gets queued and since I can wrap the callback, I can monitor for before, after, arguments, etc
16:16:18  * defunctzombiechanged nick to defunctzombie_zz
16:17:02  <trevnorris>short of it is, this API will accommodate any possible use case of asynchronous events.
16:17:33  <creationix>does it enable anything my proposed simple API doesn't?
16:17:51  <trevnorris>slightly longer, it's possible to have multiple listeners for different reasons, and w/o needing to wrap the actual callback
16:18:45  <creationix>true, but as you said in the pr, that's not needed. It can be easily implemented in userspace
16:19:24  <trevnorris>please speak with isaacs and othiym23 about this. there was a substantial conversation yesterday that brought us to this api
16:20:04  <trevnorris>and your api is incomplete in the case of ReqWrap, where we can't know ahead of time the actual callback that will run
16:20:31  <trevnorris>which would mean you need a callback that runs when it's queued, and a callback that runs when the callback itself should run.
16:20:55  <creationix>what's an example API of this?
16:20:58  <creationix>fs.read?
16:21:18  <trevnorris>anything that requires a ReqWrap, so pretty much anything I/O
16:21:31  <creationix>right, but all I/O in libuv has callbacks
16:22:04  <trevnorris>here's a simple case: https://gist.github.com/trevnorris/6346973
16:22:25  <trevnorris>what happens is that the .oncomplete callback can actually change while the I/O is in transit
16:22:46  <trevnorris>so your originally returned callback is now invalid
16:23:17  <creationix>right, so you would need a level of indirection. Is that too expensive?
16:23:37  <trevnorris>explain indirection
16:24:06  <creationix>have a callback that never changes that then dynamically looks up the current value of .oncomplete and calls it
16:24:23  <creationix>JS<->JS calls are pretty fast I thought
16:24:54  <creationix>I assume that's done in C++ code currently?
16:25:08  <trevnorris>callbacks from I/O are from C++
16:25:18  <trevnorris>so that would require a jump from C++ to JS back to C++
16:25:29  <creationix>no it wouldn't
16:25:42  <creationix>the middle callback could live entirely in js and call js
16:25:47  <creationix>though itself would be called from C++
16:26:18  * dshaw_joined
16:26:28  <trevnorris>let's setp this back.
16:26:32  <trevnorris>*step
16:26:58  <trevnorris>first, if you allow function wrappers, and there are multiple listeners, then that means many listeners == many function wrappers
16:27:13  <trevnorris>and creating a function within a closure for this specific purpose is very expensive
16:27:28  <creationix>many wrappers?
16:27:48  <trevnorris>say I setup two async listeners, each return a wrapped callback.
16:27:49  * amartensjoined
16:28:07  <trevnorris>well the second listener will actually be returning a wrapped callback of the wrapped callback from the first
16:28:13  <creationix>right, double nested
16:28:28  <creationix>so you're saying those closures are slow? has this been tested?
16:28:37  <creationix>I'm curious because I do this all the time
16:28:39  <trevnorris>http://blog.trevnorris.com/2013/08/callbacks-what-i-said-was.html
16:28:58  <trevnorris>skip the preamble
16:29:41  * LeftWingjoined
16:32:58  <trevnorris>creationix: and in this core case, in high I/O scenarios, we're talking about calling up to 100k callbacks/sec.
16:33:40  <trevnorris>creationix: and if each callback needs its own wrapper, that means you're spending a crap load of time in GC cleaning up all instantiated functions.
16:34:54  <creationix>trevnorris, so how do you plan on storing the state then?
16:35:05  <creationix>you still need objects for every request for every hook
16:35:18  <creationix>are objects a lot cheaper than closures?
16:36:08  <trevnorris>a closure is just the function scope, and creating functions within another function scope is expensive. much more so than a simple object.
16:36:18  <creationix>fair enough
16:36:26  <trevnorris>i almost have the tests written up as the model for the API, i'll post those for review in a bit
16:36:29  <creationix>if you're sure this is much cheaper I can live with it
16:37:26  * defunctzombie_zzchanged nick to defunctzombie
16:37:44  <creationix>of course as soon as someone creates new functions inside the asyncListener it's slower than ever
16:38:03  <creationix>I assume you'll be passing the "domain" data to the callbacks so they can be shared functions
16:40:08  * kazuponjoined
16:40:49  * Gateway69part
16:41:13  <trevnorris>yes
16:43:04  * defunctzombiechanged nick to defunctzombie_zz
16:43:46  <creationix>trevnorris, ok, now that I understand why you did the API the way you did, it's great
16:43:55  <creationix>also great articles btw
16:44:02  <trevnorris>thanks :)
16:45:30  * kazuponquit (Ping timeout: 264 seconds)
16:49:41  * AvianFlu_quit (Ping timeout: 248 seconds)
16:51:05  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:51:33  * dominictarrquit (Quit: dominictarr)
16:58:08  * defunctzombie_zzchanged nick to defunctzombie
17:02:47  * indexzeroquit (Quit: indexzero)
17:03:05  * csaohquit (Quit: csaoh)
17:04:54  * brsonjoined
17:06:06  * TooTallNatejoined
17:09:37  * st_lukejoined
17:22:57  * st_lukequit (Remote host closed the connection)
17:23:03  * kevinswiberquit (Remote host closed the connection)
17:23:26  * defunctzombiechanged nick to defunctzombie_zz
17:26:06  * ecrjoined
17:26:49  * `3E|FOODINGchanged nick to `3rdEden
17:29:52  <trevnorris>isaacs, othiym23, creationix: here are unit tests that should all pass once the API is fully implemented: https://github.com/trevnorris/node/commit/f789af8
17:30:10  <trevnorris>(reserve the right to change them a little during the coding process :)
17:32:19  * indexzerojoined
17:36:11  <MI6>joyent/node: Bert Belder execSync-wip * 6971efd : child_process: initial stab at spawnSync binding (+2 more commits) - http://git.io/5HhSsQ
17:37:18  <piscisaureus_>isaacs: hey
17:37:20  <piscisaureus_>yt?
17:37:32  <isaacs>piscisaureus_: on a webinar
17:37:37  <piscisaureus_>ok
17:37:40  <isaacs>piscisaureus_: done in 30 minutes or so
17:38:45  <piscisaureus_>isaacs: ok, kewl. I was just going to say - https://github.com/joyent/node/pull/6148 - it's now 95% there. Lacks tests and execSync/execFileSync.
17:38:45  <piscisaureus_>isaacs: unfortunately I won't have time to work on it until after nodeconf.eu
17:38:45  <piscisaureus_>isaacs: that was all
17:41:10  <MI6>joyent/node: Bert Belder execSync-wip * b7b02a0 : child_process: s/lookupSigno/lookupSignal/ - http://git.io/ehnErg
17:41:53  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:46:31  * mikealjoined
17:47:35  * st_lukejoined
17:47:38  * indexzeroquit (Quit: indexzero)
17:50:54  <trevnorris>msg to all, there's a small flaw in the api. i'm working it out now and will post an update.
17:53:11  * hzjoined
18:01:19  * csaohjoined
18:01:32  * csaohquit (Client Quit)
18:02:11  * csaohjoined
18:03:57  * csaohquit (Client Quit)
18:06:31  * indexzerojoined
18:12:23  * trevnorris&
18:25:07  <MI6>node-review: #79 FAILURE linux-ia32 (3/645) linux-x64 (5/645) windows-x64 (18/645) osx-x64 (1/645) centos-ia32 (1/645) centos-x64 (4/645) windows-ia32 (18/645) http://jenkins.nodejs.org/job/node-review/79/
18:27:30  * isaacsfg
18:27:47  <isaacs>Domenic_: So, part of the reason why this vm stuff sucks is that it's super duper ancient.
18:28:03  <isaacs>Domenic_: like, from before the days when we figured out that doing more in JS was usually a good idea.
18:28:51  <isaacs>Domenic_: if i were to write it today, i'd have a separate class for the JS stuf that's exposed to users, and then have the C++ bits only abort() if they get incorrect errors, and have the C++ binding be a this._binding kind of thing, like how zlib does it
18:29:38  * dshaw_quit (Quit: Leaving.)
18:35:47  * AvianFlujoined
18:39:19  * bnoordhuisjoined
18:39:37  <Domenic_>isaacs: yeah, and I think we could still do that, but we'd want to re-think the current C++ Script entirely like I did with the static methods
18:40:14  <Domenic_>isaacs: e.g. you'd want a binding.makeScript() that you could use inside the JS constructor, or similar
18:43:09  <Domenic_>isaacs: in the end I am not sure it is worth any effort to shift stuff into JS for the sake of shifting it into JS. Especially not half-way.
18:43:11  <MI6>libuv-master: #208 UNSTABLE windows (5/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/208/
18:48:22  * indexzeroquit (Quit: indexzero)
18:51:18  * defunctzombie_zzchanged nick to defunctzombie
18:52:30  * indexzerojoined
18:52:50  <isaacs>eah.
18:52:59  <isaacs>Domenic_: i'm about ready to just say fuckit and leave it as-is.
18:53:11  <isaacs>Domenic_: it already supports filename as a string, the way that you had it.
18:53:21  <tjfontaine>must. stop. fork. bomb'ing. my. laptp.
18:53:32  <isaacs>Domenic_: and as i'm actually looking at restructuring it, it's kind of justa pita
18:53:35  <isaacs>tjfontaine: wht are you doing?
18:53:42  <isaacs>tjfontaine: oh, the image thingie?
18:54:01  <tjfontaine>isaacs: ya, when doing a worker pool, always be sure to add the worker back to the pool if you have logic for spinning up new workers
18:54:05  <isaacs>tjfontaine: can't you just set the process ulimit really low before you start messing with it?
18:54:13  <tjfontaine>I should, yes
18:54:27  <isaacs>tjfontaine: also, have a limit on the number of workers you'll EVER allow to live at once.
18:54:32  <trevnorris>ok, have another solution. going to lunch, then writing it up. I swear, even if I have to lock myself in a closet, i'm going to have this done before the v0.12 release.
18:54:36  <isaacs>tjfontaine: that number should probably not be "Infinity" by default
18:54:39  <tjfontaine>:)
18:56:41  * tjholowaychukjoined
18:57:17  <MI6>libuv-node-integration: #192 UNSTABLE smartos-x64 (7/645) linux-x64 (2/645) linux-ia32 (1/645) http://jenkins.nodejs.org/job/libuv-node-integration/192/
19:04:30  * philipsquit (Read error: Connection reset by peer)
19:05:16  * st_lukequit (Remote host closed the connection)
19:05:30  * philipsjoined
19:06:13  * st_lukejoined
19:07:07  * ecrquit (Ping timeout: 264 seconds)
19:08:36  * st_lukequit (Remote host closed the connection)
19:11:03  * st_lukejoined
19:11:40  * st_lukequit (Remote host closed the connection)
19:19:12  <MI6>node-review: #80 UNSTABLE linux-ia32 (1/645) linux-x64 (1/645) windows-x64 (20/645) smartos-x64 (6/645) centos-ia32 (1/645) centos-x64 (2/645) windows-ia32 (21/645) http://jenkins.nodejs.org/job/node-review/80/
19:22:06  * piscisaureus_joined
19:25:55  * EhevuTovjoined
19:28:54  * st_lukejoined
19:32:39  * bnoordhuisquit (Ping timeout: 260 seconds)
19:43:12  * st_lukequit (Remote host closed the connection)
19:48:23  * dominictarrjoined
19:54:26  <MI6>nodejs-master-windows: #300 UNSTABLE windows-x64 (20/645) windows-ia32 (21/645) http://jenkins.nodejs.org/job/nodejs-master-windows/300/
19:59:01  * st_lukejoined
19:59:22  * ecrjoined
20:01:29  * st_lukequit (Remote host closed the connection)
20:04:04  * st_lukejoined
20:04:19  * `3rdEdenchanged nick to ircb
20:04:31  * ircbchanged nick to `3rdEden
20:10:09  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:15:03  <indutny>hm...
20:15:09  * hzquit
20:16:59  * TooTallNatejoined
20:17:29  * indexzeroquit (Quit: indexzero)
20:18:11  * pachetquit (Quit: [ +++ ])
20:20:26  * indexzerojoined
20:25:17  <trevnorris>anyone around for some api feedback regarding domains?
20:25:42  <isaacs>TooTallNate, Domenic_: I'm thinking that we should get rid of this janky "isSyntaxError" blacklist thingie, and isntead just check for "SyntaxError: Unexpected end of input"
20:25:57  <isaacs>TooTallNate: since that's really the only error that can reasonably be recovered from *anyway*
20:26:13  <Domenic_>isaacs: Seems reasonable, I don't really have an opinion on that part of the code.
20:26:30  <isaacs>ohhh... wait. nvm
20:26:42  <isaacs>ha, nevermind
20:26:48  <isaacs>consider 'function () {}.toString'
20:26:54  <isaacs>then on the next line, you type `()`
20:27:03  <isaacs>now it's a valid program (when wrapped in parens)
20:27:06  <isaacs>ugh. this fucking language.
20:27:22  <Domenic_>:P
20:27:37  <tjfontaine>it's going to be ok isaacs, I promise
20:27:58  <isaacs>haha
20:27:59  * tjholowaychukquit (Read error: Connection reset by peer)
20:28:10  <isaacs>why couldn't ry have stuck with his initial impulse and chosen haskell? srsly.
20:28:30  <isaacs>ok, actually, this is kind of weird... but i might be able to make this work
20:28:45  <isaacs>you see, `function(){}.toString` is invalid without parens, but it IS valid with them
20:28:46  <trevnorris>how about one of my favorites: var a = blah <line 1> (function() { do some stuff}()) <line 2>
20:28:58  <TooTallNate>isaacs: i'm down for some experimenting with that
20:29:03  <isaacs>hmm...
20:29:14  <TooTallNate>isaacs: the isSyntaxError() function is hard to maintain when the damn language keeps adding new SyntaxErrors
20:29:15  <TooTallNate>haha
20:30:04  <isaacs>TooTallNate: exactly!
20:30:16  <Domenic_>can we make a script to generate them from v8's source?
20:30:53  <tjfontaine>that was one thing I was going to suggest, but really I'm feeling like we should tag our repl as abandoned and let someone else maintain it in userland
20:31:20  * st_lukequit (Remote host closed the connection)
20:32:12  <trevnorris>how does d8 do it?
20:34:23  <isaacs>so, this is much more complicated because we do the stupid wrapping in () thing
20:34:42  <isaacs>so that `{ a : 1 }` is not a named numeric expression statement in a block
20:34:53  <isaacs>no other repl does this
20:34:54  <isaacs>afaik
20:35:20  <isaacs>eg, in chrome dev tools:
20:35:20  <isaacs>{ a: 1 }
20:35:21  <isaacs>1
20:35:36  <isaacs>i think we should drop the parens thing
20:35:39  <isaacs>makes this all MUCH easier
20:37:25  <trevnorris>othiym23: you around?
20:39:10  * st_lukejoined
20:40:51  <isaacs>trevnorris: d8 does it by not wrapping things in parens, and only continuing if you have an "unexpected end of input" error, i believ.
20:41:12  <trevnorris>cool.
20:41:41  <trevnorris>they don't have auto complete though :P
20:42:05  * indexzeroquit (Quit: indexzero)
20:43:23  <trevnorris>creationix: how about you?
20:44:55  <trevnorris>or for anyone, the async lister api is completely now completely oblivious to domains. this'll give some cool side effects.
20:45:05  <trevnorris>here's the unit tests, which pretty much show the api: https://github.com/trevnorris/node/blob/286480a
20:45:30  <trevnorris>though, I feel like passing something would be helpful, but can't put my finger on what could be passed.
20:52:40  * piscisaureus_quit (Ping timeout: 264 seconds)
20:55:50  * rendarquit (Ping timeout: 268 seconds)
20:57:01  <creationix>trevnorris, hmm..
20:59:47  <trevnorris>then there'll be process.addDomain/removeDomain() which you pass an object similar to what was returned from the other discussed api.
21:00:05  <trevnorris>i was shoving too much functionality into one thing, and there were too many edge cases.
21:00:59  <creationix>trevnorris, so the test only counts calls to the hook?
21:01:20  <trevnorris>creationix: yeah. i'm creating a separate set of tests for the actual domain implementation
21:02:00  <creationix>so you still have the same events? before, after, error?
21:02:06  <trevnorris>yeah
21:02:36  <trevnorris>except it'll be: process.addDomain({ before: fn, after: fn, error: fn, done: fn });
21:03:02  <creationix>hmm
21:03:23  <creationix>for CLS we need a way to set data on a per hook basis
21:03:49  <trevnorris>how do you mean, per hook?
21:04:00  <creationix>per call to the asyncListener
21:04:20  <trevnorris>oh, and you want the data to persist with just that callback?
21:04:27  <creationix>so if the user calls setTimeout 5 times, I need 5 calls with 5 different data values I can set
21:04:32  <trevnorris>wow, ok
21:04:37  <trevnorris>that's doable
21:05:20  <creationix>mostly we just need to record some program state at the point that the async listener is called and pass that recorded state on to the callbacks when they eventually get called
21:05:38  * defunctzombiechanged nick to defunctzombie_zz
21:05:43  <creationix>actually we don't need to pass data to the callback itself
21:05:49  <creationix>but rather the before and after hooks for the callback
21:06:18  <trevnorris>one sec. they're serving cupcakes!!!
21:06:40  * c4milojoined
21:06:49  <othiym23>trevnorris: I'm here, I just had to get caught up on what I missed
21:07:01  * AvianFluquit (Remote host closed the connection)
21:07:33  <creationix>trevnorris, btw, I'm having fun with mozilla stuff today too https://cloudup.com/cJ0igVDW3yl
21:07:38  <Domenic_>man now i want cupcakes
21:08:50  <trevnorris>creationix: heh, awesome.
21:09:03  <trevnorris>Domenic_: hey, if you're in mountain view, swing by ;)
21:09:22  <Domenic_>trevnorris: :) in NYC, sad to say
21:09:51  * dshaw_joined
21:10:08  <othiym23>trevnorris: which tree should I be looking at right this second?
21:10:26  <othiym23>man, this new keyboard is fucking sweet, but I kinda wish it were lower-profile
21:10:34  <trevnorris>I have https://github.com/joyent/node/pull/6011 updated with my latest rework.
21:10:39  <othiym23>http://www.wasdkeyboards.com/index.php/code-87-key-mechanical-keyboard.html
21:10:39  * dominictarrpart
21:11:21  <trevnorris>... they're sold out.
21:11:27  <othiym23>already?
21:11:30  <othiym23>that didn't take long
21:12:21  <othiym23>trevnorris, creationix: btw I dragooned you guys into a thread on the mailing list today, in a message nobody will read because Gmail totally botched its formatting
21:12:31  <othiym23>lesson learned: don't write email you care about on Gmail for iPad
21:12:34  * c4miloquit (Remote host closed the connection)
21:12:36  <trevnorris>heh
21:12:49  * c4milojoined
21:13:31  <trevnorris>I tried writing a response last night, and right after I submitted it told me the message had been deleted.
21:14:14  <othiym23>I used to hate Mailman, but it's looking better in retrospect
21:14:58  <othiym23>trevnorris: so catch me up, are you thinking about removing the object from the asyncListener contract and using an out-of-band method for dealing with those now?
21:15:01  <trevnorris>to catch you up, it was too much to jam domain functionality into the async listeners.
21:15:16  <othiym23>define "domain functionality"
21:15:47  * bnoordhuisjoined
21:15:50  <trevnorris>the ability to persist a state/domain/context (whatever it's called now) with an asynchronous request.
21:16:23  <trevnorris>so instead i'm going to write a light weight way of simply alerting when something that will require a callback has been called.
21:16:32  <trevnorris>i.e. async listeners
21:17:15  <trevnorris>then I can implement the more complex domains idea we've discussed on top of that by creating a single async listener callback that will be called whenever someone adds a state/domain/context
21:17:45  <othiym23>so the API in the gist is obsolete now?
21:17:53  <creationix>what data will this lightweight hook be given?
21:18:01  <creationix>and it's return value is now ignored right?
21:18:18  <trevnorris>maybe, and undetermined.
21:18:34  <trevnorris>the first step is to get it calling back something when those async requests are made
21:18:57  <trevnorris>the other stuff is trivial to implement in comparison
21:19:41  <trevnorris>and the gist is only sort of obselete
21:20:02  <trevnorris>i need more information on this storing unique data with each call
21:20:35  <creationix>trevnorris, ok, so...
21:20:58  <creationix>I'll use settimeout as an example because it's simple, but the same applies to anything that queues later events
21:21:49  <creationix>suppose I call setTimeout twice at two different times. For each call to setTimeout, I need my asyncListener to be called. I need to look at the current state of the program and pass some data to before and after functions
21:22:09  <creationix>I can share the same before and after functions between all event types
21:22:19  <creationix>but I need unique data for each event
21:22:42  <creationix>so I guess it's just another callback
21:22:53  <trevnorris>ah, ok.
21:22:55  <creationix>before, after, error, done, and setup
21:23:16  <creationix>whatever setup returns needs to be passed to before, after, error, and done
21:23:42  * c4miloquit (Remote host closed the connection)
21:23:51  * c4milojoined
21:24:14  <trevnorris>understand it conceptually. give my brain cells a moment to process the api.
21:24:36  * c4miloquit (Remote host closed the connection)
21:25:14  <othiym23>creationix: doesn't the current version of CLS depend on being able to replace the context object?
21:25:55  * austojoined
21:27:49  <creationix>trevnorris, https://gist.github.com/creationix/33da0230ae46e01c9d7c
21:28:09  <creationix>CLS will need all the event hooks except for "done"
21:30:55  <creationix>othiym23, what do you mean replace the context?
21:31:06  <creationix>"setup" can read the current context
21:31:11  <creationix>"before" can activate it
21:31:16  <creationix>"after" can deactivate it
21:31:28  <othiym23>you right, never mind me
21:32:34  <isaacs>trevnorris: sorry, i was wrong. d8 doesn't buffer *anything*
21:32:35  * CoverSlidejoined
21:32:46  <isaacs>trevnorris: it reads until the eol, and then evals it, and if you get any kind of error, then that's it.
21:32:57  <trevnorris>simple enough, I guess, but bummer
21:33:29  <isaacs>trevnorris: yeah, but it is simpler.
21:33:42  <isaacs>trevnorris: i'm thinking though, we really *only* need the parens for {a:1}
21:33:48  <trevnorris>true
21:33:52  <isaacs>everything other than object literals actually the parens are a problem
21:36:33  * mikealquit (Quit: Leaving.)
21:37:18  * mikealjoined
21:41:31  <creationix>trevnorris, would it be useful for the setup() hook to give me information about the event
21:41:33  <creationix>like event type
21:41:46  <trevnorris>working, sec.
21:41:48  <creationix>("timer", "fs", "fs.open", etc)?
21:41:55  <trevnorris>they're not all events
21:42:40  * defunctzombie_zzchanged nick to defunctzombie
21:42:43  <trevnorris>they're from ReqWrap, Timers, process.nextTick or EventEmitter
21:42:51  <trevnorris>each one is slightly unique
21:43:42  * txdvjoined
21:43:59  <trevnorris>but you have strange things, say, you create a ReqWrap to request I/O from the file system. but that fires an internal .oncomplete callback, and that will fire the user supplied callback.
21:44:33  <trevnorris>but I can't know ahead of time which event emitter callback will fire, so the most I can give you is information about the ReqWrap request
21:45:11  <trevnorris>and even then. the .oncomplete callback could change while the request is in transit, so most I could hand you is the context of the request (the "this")
21:45:30  <trevnorris>but that will be useless for process.nextTick, since it's context-less
21:47:54  <trevnorris>sorry, does that make sense?
21:48:20  <trevnorris>not trying to poop on anyones parade. just brain streaming what i've been thinking about the last 2 weeks.
21:50:08  <othiym23>that makes sense to me
21:50:17  <othiym23>I'd be interested to hear what value creationix thinks the class of event might add
21:51:21  <trevnorris>I was considering passing the context (i.e. "this") to the async listener, because it'd be useful for tracing how often specific things call out asynchronously.
21:51:34  <trevnorris>e.g. dtrace type stuff
21:53:24  <isaacs>omg, there are so many hairy terrible edge cases that removing this kludgey crap fixes.
21:53:27  <isaacs>i keep finding them :)
21:53:38  <trevnorris>go isaacs!
21:55:39  * EhevuTovquit (Quit: This computer has gone to sleep)
21:56:36  * EhevuTovjoined
21:57:24  <tjfontaine>isaacs: in the repl?
21:57:36  <isaacs>tjfontaine: yeah
21:57:53  <isaacs>it prevents potential double-evaling, but i can't seem to figure out a way to show that
22:00:07  <isaacs>aha, here's one:
22:00:08  <isaacs>> x = 1
22:00:09  <isaacs>1
22:00:09  <isaacs>> eval('x++; throw new SyntaxError("e")')
22:00:09  <isaacs>... ^C
22:00:11  <isaacs>> x
22:00:13  <isaacs>3
22:07:36  <trevnorris>creationix, othiym23: brain dump revision: https://gist.github.com/trevnorris/6372405
22:13:38  <othiym23>lookin lookin
22:13:47  <othiym23>whao, this is a me-style wall o text
22:15:13  <othiym23>looks good trevnorris
22:15:20  <othiym23>ship it!
22:15:56  <othiym23>(more realistically, I won't know if this has holes until there's an implementation I can play with, but it looks slightly cleaner than yesterday's revision)
22:20:10  * philipsquit (Changing host)
22:20:10  * philipsjoined
22:22:56  * groundwaterquit (Ping timeout: 245 seconds)
22:25:57  <trevnorris>othiym23: thanks. i'm going to start with just calling the callback on queued async events.
22:26:06  <trevnorris>I can work in the domain object propagation afterwards.
22:26:06  * CoverSlidequit (Quit: leaving)
22:26:18  * CoverSlidejoined
22:27:18  <trevnorris>isaacs: when you're not nipple deep in repl, mind taking a peak at this api: https://gist.github.com/trevnorris/6372405
22:27:23  * pachetjoined
22:27:27  <trevnorris>bnoordhuis: you're alive! how goes things?
22:27:53  <isaacs>trevnorris: i'll take a look later. need to run out ofr a bit
22:27:53  <othiym23>here's the use cases I'm thinking of when evaluating these APIs: 1. long stacktraces, 2. logging, 3. error handling, 4. execution tracing
22:28:17  <trevnorris>isaacs: np, not like i'll have it done today or anything ;)
22:28:46  <othiym23>trevnorris: whatever you finally come up with, I'll probably adapt cls-glue to have an identical API
22:28:52  <isaacs>othiym23: i'd also like to get flamegraphs of the time my program is NOT on CPU, and why
22:28:54  <othiym23>well, either I or creationix will
22:29:17  <isaacs>othiym23: ie, if i'm doing more async operations, which take almost no time on cpu, but still slow things down
22:29:29  <isaacs>i guess that's "execution tracing"
22:29:37  <othiym23>yeah, that's the goal for New Relic as well
22:29:57  <othiym23>we're gonna have to get their incrementally, though, because a lot of things I need to do that right aren't really in place yet
22:30:31  <trevnorris>isaacs: you should be able to filter those, since i'm passing the context you'll be able to do things like if (context instanceof Timers) or whatever
22:30:45  <isaacs>trevnorris: neat
22:31:33  <trevnorris>i had another thought, but it seems sort of insane, but possibly cool.
22:31:57  <othiym23>insanity is my specialty
22:32:00  <othiym23>lay it on me
22:32:02  <trevnorris>i'm going to be returning an identifying object, like timers, and it'd be possible to have an array in there that shows the current queue of all contexts that are waiting for processing
22:33:37  <trevnorris>that even make sense?
22:33:57  <othiym23>it does, but I haven't come up with a use for it y et
22:34:01  <othiym23>not to say there isn't one
22:34:11  <othiym23>there might be an interesting metric lurking in there somewhere
22:34:34  <trevnorris>i was thinking, like if there's an error you could scan through and see what else is waiting to finish.
22:35:48  <trevnorris>then I might be able to do something bat shit crazy like allow you to drop async requests in transit, so the callback won't run.
22:35:54  <trevnorris>ok, getting way way ahead of myself.
22:36:29  <othiym23>it would be great to be able to tell people how "deep" their various processing queues are
22:36:48  <othiym23>right now that information isn't really exposed
22:37:15  <trevnorris>like see a list of all async requests currently in the wild type of thing?
22:37:36  <othiym23>yeah
22:37:53  <othiym23>you can do _getActiveHandles and _getActiveRequests, but not many people know what that's telilng them
22:38:16  <othiym23>and there's no way to get at the depth of the nextTick or setImmediate queues from userland, is there?
22:38:34  <trevnorris>now, i'm designing this to be as performant as Node-ly possible, but still going to be ridiculously expensive.
22:38:40  <trevnorris>and no, that was a design decision.
22:39:17  <othiym23>I think minimizing the closure overhead / GC pressure of creating so many functions is all I can realistically hope for
22:39:26  * groundwaterjoined
22:39:48  <trevnorris>yeah. there'll be just one closure that runs everything.
22:40:00  <othiym23>the alternative is threading all this stuff into the C++ side of things, or instrumenting libuv itself, and that seems like an awful lot of work for what might turn out to be only a marginal improvement in efficiency
22:40:30  <trevnorris>not sure how that could be possible.
22:40:41  <othiym23>it's possible there's a way to abuse DTrace into generating individual request tracing, but if there is, I wasn't able to find it
22:40:53  <trevnorris>tjfontaine could probably help you there
22:41:07  <othiym23>I was thinking about this this morning
22:41:35  <othiym23>what we're really building here is part of a lifting operation, where we're capturing a context without letting the code running in that context know that it's being captured
22:41:47  * bnoordhuisquit (Ping timeout: 260 seconds)
22:42:11  <othiym23>and there's all kinds of CPS transform gubbidge that statically typed functional language compilers use to do this when transpiling to C
22:42:39  <othiym23>but JS's design doesn't really offer much in the way of help
22:59:47  <tjfontaine>ohai
23:00:37  <othiym23>tjfontaine: so if I wanted to trace execution of a continuation chain using DTrace, is there a way I could abuse memory addresses or whatever to do what I wanted?
23:00:54  <tjfontaine>oh man, lets step back a few assumptions
23:01:23  <tjfontaine>can you provide me an example more precisely of what you would want to do?
23:01:27  <othiym23>I sort of halfassed something that could extract traces of individual requests from the output of node --trace-all, but it was based on treating addresses as opaque identifiers, which did not seem at all sane to me
23:01:53  <othiym23>sure, just what I'm doing with CLS, more or less, but from the C++ / D side of things
23:02:25  <tjfontaine>so, with dtrace you can attach at (dtrace) process level variables, or at thread local variables
23:02:38  <tjfontaine>so depending on what you're looking to keep track of, yes it can be done
23:03:02  <tjfontaine>that's basically what happens for most examples you "register interest" and then perform subsequent operations based on that interest
23:03:38  <othiym23>right, but it gets dicey when you're trying to get it to register interest across call / async boundaries
23:04:20  <tjfontaine>so I would say the hardest (but not insurmountable) option, would actually be trying to see where you were about to land from MakeCallback
23:05:19  <othiym23>it would be super rad to be able to profile continuation chains from DTrace and generate aggregate metrics over whole-request timings
23:05:37  <othiym23>I mean, that's more or less what I'm trying to do with the execution tracer for New Relic, only from pure (slow) JS
23:06:13  <othiym23>and trevnorris and I were just discussing how to speed that up, and if you can *do* it at all in DTrace, seems like it'd be the fastest option
23:06:36  <trevnorris>who the fuck broke dns?
23:06:36  <tjfontaine>well, you want to profile how long continuation chains take for a given request?
23:06:41  <trevnorris>node: ../deps/uv/src/uv-common.c:475: int uv__getaddrinfo_translate_error(int): Assertion `!"unknown EAI_* error code"' failed.
23:07:00  * AvianFlujoined
23:07:01  <tjfontaine>trevnorris: how did you manage that?
23:07:07  <trevnorris>i ran make test
23:07:19  <trevnorris>on master
23:07:40  <tjfontaine>this is likely the errno refactor
23:08:08  <othiym23>tjfontaine: ideally what I want is a set of aggregate metrics that break down into little pieces how long each piece of a continuation chain took on average, given certain transactional boundaries to define what the "continuation chain" is in a given case
23:08:39  <trevnorris>tjfontaine: yup. it's from the uv v0.11.11 upgrade
23:09:14  <trevnorris>freakin bert, where is he
23:10:55  <tjfontaine>othiym23: the best way would be to add some more probe points in whatever api lands
23:11:21  <tjfontaine>othiym23: making that work with glue could be done with some helper probes in your glue stack
23:11:39  <othiym23>tjfontaine: I'm just constantly checking with people to make sure I haven't been wasting the last 14 months ;)
23:11:52  <tjfontaine>it may be possible today without modification to node or your CLS stuff, but it would probably be evil
23:12:06  <tjfontaine>othiym23: we should schedule some time to talk about in earnest I think
23:12:18  <tjfontaine>*it in
23:12:28  <othiym23>someday I'm gonna state the problem in such a way that somebody's going to say, "why didn't you just use <magic, yet retrospectively obvious thing>, you dumbass?"
23:12:30  <othiym23>I just know it
23:12:55  <tjfontaine>heh
23:13:14  <othiym23>well, it's kinda a moot point, because I can't commit to DTrace support until it's something that's easily available on AWS, realistically
23:13:33  <tjfontaine>trevnorris: you could also blame the fact that internet is not default in make test
23:13:35  <othiym23>although Joyent and NR are buds, so maybe we can talk about it at the BD level for a post-1.0 spike
23:14:01  <trevnorris>tjfontaine: how do you mean?
23:14:38  <tjfontaine>othiym23: that's part of why I thought that the generic _trace.js points would be helpful, so you could polyfill on [dumber|older] platforms
23:14:40  <trevnorris>ircretary: tell bnoordhuis after uv v0.11.11 upgrade get this for dns tests: uv-common.c:475: int uv__getaddrinfo_translate_error(int): Assertion `!"unknown EAI_* error code"' failed.
23:14:41  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
23:15:43  <tjfontaine>trevnorris: I mean `make test` just does python tools/test.py simple message
23:15:52  <tjfontaine>trevnorris: the error is only shown in python tools/test.py internet
23:16:36  <trevnorris>still not following, shouldn't he have seen the error when running "make test" on his box?
23:16:36  <tjfontaine>because someone for other reasons didn't like that we had a test that needed the internet
23:16:57  <tjfontaine>it doesn't happen here unless I run the internet suite
23:16:57  <tjfontaine>test: all
23:16:57  <tjfontaine> $(PYTHON) tools/test.py --mode=release simple message
23:17:38  * mikealquit (Quit: Leaving.)
23:17:47  <tjfontaine>https://gist.github.com/tjfontaine/6384588
23:17:49  <trevnorris>all I ran was "make test" so that wouldn't have included "internet", right? I didn't even realize those were there
23:18:38  * mikealjoined
23:18:49  <trevnorris>tjfontaine: run ./node test/simple/test-net-dns-error.js
23:18:56  <tjfontaine>trevnorris: you might try and revert https://github.com/joyent/libuv/commit/9d60f1ebda0cdedc67ee439997e60b74a40f2f3f
23:19:14  <tjfontaine>trevnorris: works here
23:19:22  <trevnorris>what OS you using?
23:19:24  <tjfontaine>also not showing up http://jenkins.nodejs.org/job/nodejs-master/lastCompletedBuild/testReport/
23:19:32  <tjfontaine>trevnorris: osx
23:19:53  <tjfontaine>trevnorris: I believe the error is there, just not as easily reproduced in the base as it is for you
23:20:14  <tjfontaine>oh I know what is
23:20:17  <tjfontaine>https://github.com/joyent/libuv/commit/3f2d4d535867a99170b4964f2e3db1ef70968c23
23:20:27  <tjfontaine>that's the commit that's blowing
23:22:30  <tjfontaine>trevnorris: this is probably a legit bug in node that should be handled
23:23:15  <trevnorris>tjfontaine: alright, also that's not the commit. I reverted that and the error still occurs.
23:25:01  <tjfontaine>trevnorris: you sure you got it? the file has changed because of the subsequent commit, if I manually revert the addition in my tree it works
23:25:17  <trevnorris>tjfontaine: i just went in an deleted the line
23:25:39  <trevnorris>i'm talking about 3f2d4
23:26:04  <tjfontaine>me as well, I went it line 150 in deps/uv/src/unix/loop.c and commented it out
23:26:11  <trevnorris>ditto
23:26:11  <tjfontaine>oh
23:26:16  <tjfontaine>we have different asserts blowing
23:26:23  <tjfontaine>cute
23:26:27  <tjfontaine>yours is from ...
23:26:27  <trevnorris>hah, awesome.
23:26:58  <trevnorris>uv-common.c:475
23:27:06  <trevnorris>int uv__getaddrinfo_translate_error(int): Assertion `!"unknown EAI_* error code"' failed.
23:27:32  * mikealquit (Quit: Leaving.)
23:28:23  <trevnorris>that was committed for ever ago in 3ee4d3f1
23:28:44  <trevnorris>ah, in the massive return error codes directly commit
23:28:52  <trevnorris>but no idea why it's blowing now
23:29:28  <tjfontaine>run it in gdb so we can find out which errno it is
23:30:22  <trevnorris>uv__getaddrinfo_translate_error (sys_err=-5)
23:31:30  <trevnorris>so the error code is -5
23:31:37  <trevnorris>there a way to decode that?
23:32:16  <tjfontaine>yes, it's ENODATA, which is right
23:32:44  <trevnorris>hm. well uv__getaddrinfo_translate_error doesn't recognize it
23:33:20  <tjfontaine>can you `dis` that function and gist it?
23:33:33  * groundwaterquit (Quit: groundwater)
23:33:40  <trevnorris>in gdb?
23:33:43  <tjfontaine>yes
23:33:58  <tjfontaine>`disas`
23:34:10  <tjfontaine>if you're in the frame for it
23:34:44  <trevnorris>want the frame for uv__getaddrinfo_work or uv__getaddrinfo_translate_error?
23:34:53  <tjfontaine>translate_error
23:35:01  <tjfontaine>I wanna see which set we're actually comparing against
23:35:14  <tjfontaine>if some how you managed to compile without it being set
23:35:18  <tjfontaine>or if it's a different value
23:35:24  <trevnorris>https://gist.github.com/trevnorris/6384695
23:37:13  <tjfontaine>heh, screw it, put fprintf(stderr, "%d -- %d\n", EAI_NODATA, sys_err); fflush(stderr); in that function
23:38:59  <trevnorris>-3007 -- -5
23:39:13  <tjfontaine>uh, really?
23:39:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:39:22  <tjfontaine>you didn't use UV_EAI_NODATA did you?
23:39:49  <trevnorris>yeah. it said EAI_NODATA was undefined
23:39:54  <trevnorris>so I used UV_*
23:39:56  <tjfontaine>ok that's a valid use case
23:39:58  <tjfontaine>see the defins
23:40:00  <tjfontaine>*defines
23:40:11  <tjfontaine>use EAI_NONAME instead of EAI_NODATA
23:40:27  <tjfontaine>if neither of these are defined, there's a problem.
23:40:38  <trevnorris>-2 -- -5
23:40:44  <trevnorris>that's NONAME
23:41:13  <tjfontaine>ok, so that's quite interesting :)
23:42:29  <trevnorris>ok, what's this line doing:
23:42:30  <trevnorris># if !defined(EAI_NODATA) || EAI_NODATA != EAI_NONAME
23:42:47  <trevnorris>oh, read it wrong
23:43:03  <trevnorris>saw it as EAI_NONAME != EAI_NONAME
23:43:04  <tjfontaine>right, so the question is -- why isn't ENODATA defined for you
23:43:16  <trevnorris>um... good question
23:43:17  <tjfontaine>likely a missing header
23:43:47  <tjfontaine>should be in netdb.h
23:45:34  <trevnorris># ifdef __USE_GNU
23:45:38  <trevnorris># define EAI_NODATA
23:45:49  <trevnorris>erm
23:45:50  <trevnorris># define EAI_NODATA -5
23:46:59  <tjfontaine>right, you might try taking the compile line for that file and then runnign it manually with `gcc -E` or whatever it is that will show you the parsed output
23:47:23  * bnoordhuisjoined
23:48:19  <trevnorris>tjfontaine: so.. __USE_GNU isn't defined
23:48:38  <tjfontaine>lemme check if this is happening on our buidlslave
23:50:42  <tjfontaine>trevnorris: this isn't happening on the build slave, which is 12.04
23:51:07  <tjfontaine>trevnorris: so are you sure you don't have something weird in your CFLAGS/CXXFLAGS or similar?
23:51:09  <trevnorris>i'm on xubuntu 12.10
23:51:40  * bnoordhuisquit (Ping timeout: 245 seconds)
23:51:40  <trevnorris>nope. I just export clang, that's all
23:51:43  <tjfontaine>oh
23:51:49  <tjfontaine>retry with gcc :)
23:51:54  <trevnorris>i'm rebuilding with gcc right now :)
23:51:57  <tjfontaine>it could be clang failing to do include paths right
23:52:07  <tjfontaine>it does a lot of automagic detection
23:52:12  <trevnorris>nope. gcc doesn't have it defined either
23:52:28  <tjfontaine>something is wonky in your env, debootstrap a new one up and see if you can reproduce :)
23:52:42  <trevnorris>ok