00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:43:36  * defunctzombiechanged nick to defunctzombie_zz
00:46:31  * stagasquit (Ping timeout: 246 seconds)
00:59:09  * defunctzombie_zzchanged nick to defunctzombie
01:03:21  * kazuponjoined
01:03:26  * groundwaterquit (Ping timeout: 240 seconds)
01:06:32  * kazuponquit (Remote host closed the connection)
01:24:32  * groundwaterjoined
01:32:01  * kellabytequit (Ping timeout: 246 seconds)
01:39:48  * bnoordhuisquit (Ping timeout: 256 seconds)
01:45:58  * brsonquit (Ping timeout: 268 seconds)
01:59:25  * groundwaterquit (Quit: groundwater)
02:11:21  * kellabytejoined
02:18:13  * defunctzombiechanged nick to defunctzombie_zz
02:22:19  * defunctzombie_zzchanged nick to defunctzombie
02:24:29  * kellabytequit (Changing host)
02:24:29  * kellabytejoined
02:42:39  * wolfeidauquit (Remote host closed the connection)
02:43:06  * wolfeidaujoined
02:45:42  * bnoordhuisjoined
02:47:05  * wolfeidauquit (Remote host closed the connection)
02:47:12  * wolfeidaujoined
02:50:00  * bnoordhuisquit (Ping timeout: 245 seconds)
02:53:46  * brsonjoined
02:54:20  * indexzerojoined
02:54:20  * indexzeroquit (Client Quit)
03:05:21  * groundwaterjoined
03:12:42  * c4milojoined
03:12:51  * brsonquit (Quit: leaving)
03:45:00  * inolenquit (Quit: Leaving.)
03:48:55  * inolenjoined
04:13:40  * c4miloquit (Remote host closed the connection)
04:19:10  * Raynosquit (Ping timeout: 245 seconds)
04:19:36  * `3rdEdenquit (Ping timeout: 256 seconds)
04:20:19  * Domenic_quit (Ping timeout: 264 seconds)
04:51:02  * defunctzombiechanged nick to defunctzombie_zz
04:59:13  * mikealquit (Quit: Leaving.)
05:05:34  * mikealjoined
05:20:32  * mjr__quit (Quit: mjr__)
06:06:31  * `3E|Zzzjoined
06:18:07  * Domenic_joined
06:20:37  * Raynosjoined
06:36:20  * `3E|Zzzchanged nick to `3rdEden
06:36:49  * `3rdEdenchanged nick to Guest5099
06:36:55  * Guest5099changed nick to V1
06:37:12  * V1changed nick to `3rdEden
06:53:06  <MI6>nodejs-v0.10-windows: #155 UNSTABLE windows-ia32 (9/597) windows-x64 (9/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/155/
06:54:19  * bajtosjoined
07:03:35  * groundwaterquit (Quit: groundwater)
07:12:50  <indutny>morning
07:51:46  * defunctzombie_zzchanged nick to defunctzombie
07:54:48  * stagasjoined
08:16:37  * hzjoined
08:29:02  * Benviequit (Ping timeout: 240 seconds)
08:52:41  * dominictarrjoined
09:07:17  * bnoordhuisjoined
09:21:19  * dominictarrquit (Read error: Connection reset by peer)
09:21:32  * dominictarrjoined
09:25:43  * hzquit (Ping timeout: 260 seconds)
09:35:59  * dominictarrquit (Ping timeout: 260 seconds)
09:38:20  * dominictarrjoined
09:51:46  <indutny>hoya
09:56:49  * bajtosquit (Quit: bajtos)
09:57:55  <bnoordhuis>oh god, it's fedor
09:58:05  * bnoordhuisruns away from the keyboard
09:59:18  <indutny>hahaha
09:59:26  <indutny>well, that's your choice
09:59:29  <mmalecki>sup bnoordhuis, indutny
09:59:34  <indutny>I just figured out that dns is a hard business
09:59:38  <indutny>so many tricks
09:59:45  <indutny>I'm figuring out details for almost 2 days
10:02:30  <mmalecki>heh, I'd be interested in reading a blog post about this
10:02:33  * bnoordhuisquit (Ping timeout: 256 seconds)
10:03:02  <indutny>and he just left
10:03:17  <mmalecki>he'll come back, they always do
10:05:52  * abraxasquit (Remote host closed the connection)
10:45:18  <MI6>nodejs-v0.10: #1425 UNSTABLE osx-ia32 (1/597) smartos-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1425/
10:47:12  * bajtosjoined
10:54:35  * bajtosquit (Ping timeout: 245 seconds)
10:55:27  * rendarjoined
10:56:20  * bnoordhuisjoined
11:00:01  * defunctzombiechanged nick to defunctzombie_zz
11:28:33  <MI6>joyent/libuv: Ben Noordhuis master * 12bad62 : darwin: fix ios compiler warning (+1 more commits) - http://git.io/8EIubg
11:34:33  <MI6>libuv-master: #171 UNSTABLE smartos (9/192) windows (4/193) http://jenkins.nodejs.org/job/libuv-master/171/
11:34:45  <indutny>bnoordhuis: I know you're here :)
11:34:46  <MI6>libuv-master-gyp: #111 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (4/193) http://jenkins.nodejs.org/job/libuv-master-gyp/111/
11:44:42  <bnoordhuis>indutny: i got forced back
11:44:48  <indutny>haha
11:44:49  <indutny>ok
11:44:55  <bnoordhuis>what's up, fedor?
11:48:04  <MI6>libuv-node-integration: #154 UNSTABLE smartos-ia32 (3/628) osx-ia32 (1/628) linux-x64 (2/628) linux-ia32 (2/628) osx-x64 (1/628) smartos-x64 (9/628) http://jenkins.nodejs.org/job/libuv-node-integration/154/
11:48:57  * hzjoined
11:57:52  * bajtosjoined
12:31:43  * bnoordhuisquit (Ping timeout: 264 seconds)
12:32:08  * bradleymeckjoined
12:41:18  * bnoordhuisjoined
12:45:07  * c4milojoined
12:53:38  * c4miloquit (Remote host closed the connection)
12:56:23  * jmar777joined
13:05:18  * bnoordhuisquit (Ping timeout: 264 seconds)
13:07:22  * jmar777quit (Read error: Connection reset by peer)
13:07:47  * jmar777joined
13:17:07  * ik_joined
13:17:34  * isaacs_joined
13:17:58  * isaacs_changed nick to Guest10523
13:18:17  * Ralt_joined
13:18:52  * ikquit (Disconnected by services)
13:18:56  * ik_changed nick to ik
13:22:06  * Raltquit (*.net *.split)
13:22:07  * isaacsquit (*.net *.split)
13:31:45  * c4milojoined
13:43:53  * hzquit
13:44:35  * `3rdEdenchanged nick to `3E|BRB
13:44:48  * ikquit (Changing host)
13:44:48  * ikjoined
13:45:49  * rendarquit (Ping timeout: 256 seconds)
14:23:47  * bnoordhuisjoined
14:27:12  * indexzerojoined
14:36:38  * indexzeroquit (Quit: indexzero)
14:36:50  <bnoordhuis>trevnorris: re smalloc::Alloc(), the header and arguably the function name should convey that you transfer ownership of the memory
14:36:59  <bnoordhuis>trevnorris: and that it's freed with free(), not delete[]
14:37:39  * indexzerojoined
14:37:46  * c4miloquit (Remote host closed the connection)
14:43:09  <MI6>joyent/node: Ben Noordhuis master * 3e25ed9 : src: move includes inside include guard - http://git.io/gIs_Tg
14:45:01  * `3E|BRBchanged nick to `3rdEden
14:45:14  * c4milojoined
14:46:27  * jmar777quit (Read error: Connection reset by peer)
14:46:55  * jmar777joined
14:49:01  * rendarjoined
14:51:03  <bnoordhuis>indutny: ping
14:52:35  <MI6>nodejs-master: #440 UNSTABLE smartos-x64 (11/628) smartos-ia32 (4/628) osx-x64 (2/628) osx-ia32 (1/628) linux-ia32 (2/628) linux-x64 (3/628) http://jenkins.nodejs.org/job/nodejs-master/440/
14:53:51  * julianduquejoined
14:55:24  * AvianFlujoined
15:02:56  * bajtosquit (Quit: bajtos)
15:13:21  * paulfryzeljoined
15:15:30  * paulfryz_joined
15:15:33  * austojoined
15:17:00  <MI6>nodejs-master: #441 UNSTABLE smartos-x64 (10/628) smartos-ia32 (1/628) osx-x64 (1/628) osx-ia32 (1/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/441/
15:17:44  <MI6>nodejs-master-windows: #237 UNSTABLE windows-x64 (19/628) windows-ia32 (21/628) http://jenkins.nodejs.org/job/nodejs-master-windows/237/
15:17:53  * AvianFlu_joined
15:18:59  * paulfryzelquit (Ping timeout: 260 seconds)
15:19:04  * AvianFluquit (Read error: Connection reset by peer)
15:22:33  <austo>When moving an addon to v0.12, where's the best place to look for api change documentation? V8?
15:23:11  <bnoordhuis>austo: yes
15:23:45  <bnoordhuis>austo: when reading v8.h, pretend !defined(V8_USE_UNSAFE_HANDLES) - that's what node compiles with
15:26:01  <austo>bnoordhuis: cool, thanks. the binding in my project is pretty thin, so I was hoping to upgrade, compile and see what breaks. I haven't looked at v8.h since the change.
15:26:52  <bnoordhuis>austo: https://github.com/joyent/node/commit/110a9cd <- i've outlined the major changes in the commit log
15:27:08  <bnoordhuis>you can disregard the part about Cached<T>, that's internal and on its way out anyway
15:28:45  * piscisaureus_joined
15:32:31  * julianduquequit (Ping timeout: 246 seconds)
15:41:34  <austo>bnoordhuis: awesome. that and v8.h should have me in pretty good standing.
15:48:39  * mikealquit (Quit: Leaving.)
15:53:25  * bajtosjoined
15:54:56  <MI6>joyent/node: Fedor Indutny master * b9a0eb0 : tls, crypto: deduplicate code - http://git.io/7_TMaQ
16:02:01  * Guest10523changed nick to isaacs
16:04:02  <MI6>nodejs-master: #442 UNSTABLE smartos-x64 (9/628) smartos-ia32 (3/628) osx-x64 (2/628) osx-ia32 (1/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/442/
16:04:22  * amartensjoined
16:06:26  * TooTallNatejoined
16:09:50  * leonvvjoined
16:11:02  <isaacs>indutny, bnoordhuis: care to review a quick fix for stream error handling? https://github.com/joyent/node/pull/6075
16:15:37  * bradleymeckquit (Quit: bradleymeck)
16:17:20  <indutny>bnoordhuis: thanks
16:23:19  * dapjoined
16:23:22  * groundwaterjoined
16:23:50  <bnoordhuis>indutny: i think i found a bug though (but after landing it, isn't it always like that?)
16:23:56  <indutny>haha
16:24:02  <indutny>bnoordhuis: what's up?
16:24:10  <bnoordhuis>indutny: the Connection constructor sets ssl_ to NULL but that's one of its own fields
16:24:14  <bnoordhuis>*not one
16:24:22  <indutny>oh
16:24:27  <indutny>gosh
16:24:59  <bnoordhuis>isaacs: i'm a bit strapped for time at the moment. maybe later tonight
16:25:37  <isaacs>bnoordhuis: sure. in short, it's doing some awful hack to ensure that the stream.pipe() onerror->unpipe() handler is added before any userland error event handlers.
16:25:38  * Benviejoined
16:25:48  <indutny>isaacs: LGTM
16:25:50  <isaacs>bnoordhuis: so that if you add a .once(), we don't throw, but if you remove your handler prior to the event emitting, we DO throw.
16:26:01  <isaacs>indutny: thanks.
16:26:08  <indutny>that's a bit ugly, though
16:26:12  <indutny>but I see why its necessary :)
16:27:04  <MI6>joyent/node: isaacs v0.10 * 5458079 : stream: Throw on 'error' if listeners removed - http://git.io/qTVy7Q
16:28:42  * mcavagejoined
16:31:34  <MI6>nodejs-master-windows: #238 UNSTABLE windows-x64 (20/628) windows-ia32 (22/628) http://jenkins.nodejs.org/job/nodejs-master-windows/238/
16:34:11  <indutny>trevnorris: lint 2dd4a745
16:34:21  <indutny>make jslint
16:34:26  <MI6>nodejs-v0.10: #1426 UNSTABLE smartos-x64 (4/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1426/
16:35:45  <indutny>bnoordhuis: have a sec?
16:35:49  <indutny>bnoordhuis: fix for ssl_ thing https://gist.github.com/indutny/c8ee782774d8c54f46b0
16:36:01  <indutny>all tests are passing
16:36:04  <indutny>cpplint too
16:36:25  <bnoordhuis>even the style thing trevor introduced in node_buffer.cc?
16:36:42  <indutny>well
16:36:48  <indutny>it does seem to ignore it
16:36:57  <indutny>however jslint don't like his style in lib/buffer.js
16:37:28  * bradleymeckjoined
16:37:30  <indutny>bnoordhuis: if this patch lgty
16:37:34  <indutny>I'll push it
16:37:35  <bnoordhuis>patch lgtm. btw, this is why you should use : foo_(0), bar_(NULL) assignment
16:37:43  <indutny>hehe
16:37:45  <indutny>ok ok
16:37:57  <indutny>that was some very old code
16:37:59  <MI6>joyent/node: Fedor Indutny master * 306f863 : crypto: don't touch ssl_ in Connection - http://git.io/dSpgcg
16:38:07  <bnoordhuis>okay, afk for the next two hours
16:38:10  <indutny>and I remember that at those times we didn't care much about it
16:38:12  <indutny>bnoordhuis: thank you again
16:38:15  <bnoordhuis>np
16:40:51  <isaacs>indutny: if jslint complains, you can always do `make jslintfix` to fix it
16:41:07  <indutny>oh really?
16:41:13  <isaacs>well, not "always", but usually. sometimes the way the computer fixes it is not exactly sane.
16:41:16  <indutny>haha
16:41:41  <MI6>joyent/node: Fedor Indutny master * b80d11d : buffer: lint - http://git.io/wkWnQg
16:41:45  <isaacs>that python script has some funny ideas about indentation. "wanted one of (2,4,16,27) but got 6"
16:41:51  <indutny>isaacs: let it be
16:42:09  <indutny>heh
16:42:13  <indutny>it depends on context
16:42:16  <indutny>probably its right
16:42:23  * pfox___quit (Ping timeout: 246 seconds)
16:42:41  <isaacs>usually one of them is just weird and makes no sense
16:42:47  <isaacs>bbiab
16:43:09  * pfox__joined
16:43:13  * bnoordhuisquit (Ping timeout: 268 seconds)
16:46:12  * bradleymeckquit (Quit: bradleymeck)
16:46:47  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:47:02  <MI6>nodejs-master: #443 UNSTABLE smartos-x64 (9/628) smartos-ia32 (3/628) osx-x64 (2/628) osx-ia32 (1/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/443/
16:48:02  * bradleymeckjoined
16:48:40  * leonvvquit (Remote host closed the connection)
16:55:58  <MI6>nodejs-master: #444 UNSTABLE smartos-x64 (9/628) smartos-ia32 (2/628) osx-x64 (2/628) osx-ia32 (2/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/444/
16:56:00  * bnoordhuisjoined
16:57:04  * dapquit (Quit: Leaving.)
16:59:47  <MI6>nodejs-v0.10-windows: #156 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/156/
17:00:59  * AvianFlu_quit (Remote host closed the connection)
17:01:19  * c4miloquit (Remote host closed the connection)
17:03:28  * TooTallNatejoined
17:04:06  * test_joined
17:04:17  <test_>piscisaureus_: ping. don't we have a call?
17:04:23  * test_changed nick to bnoordhuis_
17:04:47  * mikealjoined
17:05:14  * mikealquit (Client Quit)
17:05:28  * amartensquit (Quit: Leaving.)
17:09:10  * brsonjoined
17:10:06  * mikealjoined
17:19:26  <indutny>test? :)
17:28:26  * AvianFlujoined
17:30:18  * c4milojoined
17:33:23  * dapjoined
17:33:24  * amartensjoined
17:33:40  <MI6>nodejs-master-windows: #239 UNSTABLE windows-x64 (20/628) windows-ia32 (18/628) http://jenkins.nodejs.org/job/nodejs-master-windows/239/
17:45:01  * defunctzombie_zzchanged nick to defunctzombie
18:00:59  <trevnorris>morning
18:01:07  <trevnorris>man, have a few messages to catch up on
18:02:28  <trevnorris>bnoordhuis: whoops. used to cpplint and jslint running for me, and forget they don't if a test fails.
18:02:40  <trevnorris>bnoordhuis: committed that when the http client agent test was failing. my bad
18:02:44  * dominictarrquit (Quit: dominictarr)
18:06:35  <trevnorris>bnoordhuis: and will do. i'll update the docs in smalloc.h with those two items.
18:08:09  <trevnorris>indutny: thanks. forgot to run it manually if a test fails.
18:11:31  <trevnorris>TooTallNate: ping
18:11:42  <TooTallNate>trevnorris: pong
18:12:10  <trevnorris>TooTallNate: so the issue is that the compiler is removing the template function in the header.
18:12:39  <trevnorris>TooTallNate: and i'm not quite sure how to tell it to stop removing the stupid thing
18:12:59  <TooTallNate>hahah
18:13:03  <TooTallNate>i mean... that's a good question
18:13:08  <TooTallNate>i don't really have any advice
18:13:24  <TooTallNate>maybe a dummy function in the .cc file that uses the template function?
18:13:50  <trevnorris>well, it's like it's compiling the module before checking how it's used, because if I include the header directly (not via node.gyp) then it works.
18:14:06  <trevnorris>so i think it's a gyp option that i must be missing
18:16:43  * rendarquit (Ping timeout: 264 seconds)
18:17:05  <MI6>joyent/node: Trevor Norris master * f97a126 : buffer: lint - http://git.io/5zvjJA
18:18:02  <trevnorris>TooTallNate: thanks for the help thus far. gyp is actually pretty cool once you figure out all the options.
18:18:43  <TooTallNate>trevnorris: ya... it's lame when you run into snags like this, but eventually things get figured out :p
18:20:30  * ecrjoined
18:26:23  <MI6>nodejs-master: #445 UNSTABLE smartos-x64 (9/628) smartos-ia32 (3/628) osx-x64 (1/628) osx-ia32 (1/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/445/
18:26:41  <MI6>nodejs-master-windows: #240 UNSTABLE windows-x64 (21/628) windows-ia32 (25/628) http://jenkins.nodejs.org/job/nodejs-master-windows/240/
18:27:00  * bradleymeckquit (Quit: bradleymeck)
18:32:34  <MI6>libuv-master: #172 UNSTABLE smartos (10/192) windows (4/193) http://jenkins.nodejs.org/job/libuv-master/172/
18:46:07  <MI6>libuv-node-integration: #155 UNSTABLE smartos-ia32 (4/628) osx-ia32 (2/628) linux-x64 (2/628) linux-ia32 (2/628) osx-x64 (1/628) smartos-x64 (11/628) http://jenkins.nodejs.org/job/libuv-node-integration/155/
18:55:30  * bnoordhuis_quit (Quit: Lost terminal)
18:57:05  <bnoordhuis>and back
18:57:15  * bajtosquit (Quit: bajtos)
19:19:58  <isaacs>wb
19:20:27  <bnoordhuis>ty :)
19:21:07  <pfox__>bnoordhuis: confirm/deny: libuv on windows ignores/drop the `mode` param to uv_fs_open .. ?
19:21:20  <pfox__>seemed that it maps the `flags` param to windows-aprop stuff
19:21:20  <pfox__>but disregards mode.
19:21:32  <pfox__>based on the src..
19:25:48  <bnoordhuis>pfox__: confirm. iirc the reason it does that is that there's no good direct mapping from unix perms to windows acls
19:26:12  <pfox__>yeah.
19:26:14  <pfox__>gotcha, thanks.
19:26:20  <pfox__>just working through the mappings on our end.
19:28:53  <bnoordhuis>i guess we should document that in the header
19:29:15  <bnoordhuis>piscisaureus_: ^
19:31:11  * paulfryzeljoined
19:34:35  * paulfryz_quit (Ping timeout: 245 seconds)
19:39:30  <MI6>nodejs-master-windows: #241 UNSTABLE windows-x64 (24/628) windows-ia32 (23/628) http://jenkins.nodejs.org/job/nodejs-master-windows/241/
19:44:25  * icarotjoined
19:46:35  * julianduquejoined
19:58:05  <indutny>bnoordhuis: I think I found a solution for FSEvents 451 listener problem
19:59:36  <indutny>bnoordhuis: though I'd be glad if you'll pull my first fix for it
19:59:49  * paulfryz_joined
19:59:54  <indutny>bnoordhuis: https://github.com/joyent/libuv/pull/880
19:59:56  <indutny>piscisaureus_: hey
20:00:07  <indutny>piscisaureus_: btw, has this patch fixed the problem for ruben?
20:02:45  * paulfryzelquit (Ping timeout: 248 seconds)
20:05:36  <bnoordhuis>indutny: i don't know, i haven't talked to ruben
20:05:39  <bnoordhuis>piscisaureus_: you know?
20:05:51  <indutny>bnoordhuis: anyway, that PR makes sense for me
20:06:04  <indutny>not sure what I was thinking about when I called FSEvents API from different threads
20:17:25  * bradleymeckjoined
20:18:20  <indutny>bnoordhuis: thanks
20:18:54  <indutny>bnoordhuis: basically, my idea to fix 451 stream problem consists of recreating FSEventStream
20:19:01  <indutny>with larger amount of paths
20:19:08  <indutny>instead of creating new FSEventStream for every path
20:19:25  <indutny>it seems that this 451 limitation applies only to streams and not directories/files themselves
20:20:09  <bnoordhuis>have you been able to reproduce it?
20:20:33  <bnoordhuis>i ask because i couldn't
20:20:41  * dominictarrjoined
20:22:13  <indutny>bnoordhuis: yepp
20:22:18  <indutny>bnoordhuis: try watching more than 451 file
20:22:21  <indutny>with fs.watch()
20:22:54  <indutny>like this `var i=0;while(i++ < 451)require('fs').watch('./',function(){})`
20:23:21  <indutny>node -pe "var i=0;while(i++ < 451)require('fs').watch('./',function(){})"
20:23:28  <indutny>bnoordhuis: does it fails for you?
20:27:56  <bnoordhuis>let me try
20:28:25  <bnoordhuis>indutny: no
20:28:33  <indutny>what if you'll try bigger number?
20:28:34  <indutny>1024
20:28:46  <indutny>are you on osx?
20:28:51  <bnoordhuis>yes
20:29:07  <indutny>odd
20:29:10  <indutny>what version?
20:29:21  <indutny>mine is 10.8.4
20:29:28  <bnoordhuis>Darwin hermes.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
20:29:36  <bnoordhuis>what's that? 10.8.4?
20:29:42  <bnoordhuis>yeah
20:29:43  <indutny>hahaha
20:29:51  <indutny>never look at uname -a on osx
20:30:01  <indutny>Darwin indutny-osx.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
20:30:14  <indutny>bnoordhuis: so what about bigger numbers?
20:30:17  <bnoordhuis>i feel so connected!
20:30:18  <indutny>1024, 4096
20:30:22  <bnoordhuis>with 1024 i get an EMFILE error
20:30:25  <indutny>oh
20:30:31  <bnoordhuis>with ulimit -n 1024 btw
20:30:31  <indutny>ulimit -n to the rescue
20:30:40  <indutny>no surprise
20:30:45  <indutny>3 fds for stdio
20:30:51  <bnoordhuis>oh right, i see it with i=1000
20:30:56  <indutny>ok good
20:30:57  <indutny>:)
20:31:07  <indutny>so, I propose
20:31:12  <indutny>instead of creating stream for each handle
20:31:20  <indutny>having one shared stream for all handles
20:31:28  <indutny>and add paths to it
20:31:33  <indutny>well, there're no API for it
20:31:42  <indutny>but we can create new one and destroy old one
20:32:05  <bnoordhuis>like that bird from mythology classes
20:32:35  <bnoordhuis>only it was the other way around - it first destroyed itself before rising from the ashes again
20:32:44  <bnoordhuis>so, a bad comparison
20:32:55  <bnoordhuis>i never was all that great at comparative literature
20:33:05  <bnoordhuis>indutny: okay, sounds good
20:33:07  <indutny>yeah, I see
20:33:10  <indutny>bnoordhuis: cool
20:33:16  <indutny>bnoordhuis: I'll look into it ASAP
20:33:24  <indutny>probably tomorrow
20:33:30  <indutny>well, not really ASAP
20:33:33  <bnoordhuis>oh, no rush - it doesn't really bother me
20:34:50  * piscisaureus_quit (Ping timeout: 256 seconds)
20:38:06  * jmar777quit (Remote host closed the connection)
20:40:26  <MI6>joyent/libuv: Ben Noordhuis master * 602b1c6 : unix, windows: fix ipv6 link-local address parsing (+1 more commits) - http://git.io/BbD4pQ
20:43:19  <MI6>nodejs-master-windows: #242 UNSTABLE windows-x64 (25/628) windows-ia32 (24/628) http://jenkins.nodejs.org/job/nodejs-master-windows/242/
20:48:54  <MI6>libuv-master-gyp: #112 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (5/193) http://jenkins.nodejs.org/job/libuv-master-gyp/112/
20:51:33  <hueniverse>"/src/tcp_wrap.cc:368: static void node::TCPWrap::Connect(const v8::FunctionCallbackInfo<v8::Value>&): Assertion `args[2]->Uint32Value()' failed." -- HUH?
20:51:36  <MI6>libuv-master: #173 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/173/
20:53:11  <bnoordhuis>hueniverse: where/when do you get that?
20:53:25  <hueniverse>running npm test on hapi master
20:53:34  <hueniverse>I just installed 11.5 and tried it :-)
20:53:38  <bnoordhuis>ah okay
20:53:57  <hueniverse>was just surprised to see such a console printout
20:54:10  <bnoordhuis>that assertion means the port number to connect() is not an uint
20:54:16  <bnoordhuis>probably because it's < 0
20:54:36  <bnoordhuis>if you have a test case of some sorts, please open an issue
20:54:42  <hueniverse>yep
20:54:48  <hueniverse>I will isolate it
20:55:09  <hueniverse>currently failing about 20 tests out of 700
20:55:14  <hueniverse>which all work find in 0.10
20:55:23  <hueniverse>so I'll be breaking it down
20:55:37  <hueniverse>we want to deploy *one* 0.11 server to production
20:55:45  <hueniverse>as soon as we can pass all tests
20:56:00  <bnoordhuis>is that the only assert you hit?
20:56:15  <bnoordhuis>let me rephrase that as: what failures are you seeing?
20:56:29  <hueniverse>well, its the first I hit... then the test barfs
20:56:33  <hueniverse>:-)
20:56:55  <bnoordhuis>ah right
20:56:56  <hueniverse>which API is this from:
20:56:57  <hueniverse>write(string, encoding, offset, length) is deprecated. Use write(string, offset, length, encoding) instead.
20:57:15  <bnoordhuis>fs.write()
20:57:24  <hueniverse>k
20:57:44  <bnoordhuis>oh wait no, buffer.write()
20:57:57  <hueniverse>k
20:58:15  <hueniverse>is the new style compatible with 0.10?
20:58:34  <bnoordhuis>yeah. the old style has been old for a long time now, i think
20:59:06  <bnoordhuis>trevnorris: have you run any benchmarks lately?
20:59:19  <bnoordhuis>trevnorris: in some ways we're doing better than v0.10, in some ways worse
20:59:19  <trevnorris>bnoordhuis: all the time. on anything specific?
20:59:24  <trevnorris>true
20:59:44  <bnoordhuis>i think we need to spend some time and love on lib/*http*.js and lib/net.js
20:59:54  <bnoordhuis>there are functions deopting that shouldn't be deopting
21:00:04  <bnoordhuis>others that we could probably get v8 to inline with a little love and care
21:00:18  <bnoordhuis>oh, and EventEmitter#emit() is causing massive deopts all the time
21:00:28  <bnoordhuis>but that in itself is not new
21:00:30  * rendarjoined
21:01:06  <trevnorris>think the same. after your multi-context i'll land the new userland domain api then i'll be able to devote time to that
21:01:06  <bnoordhuis>just throwing it out there :) if you have suggestions, love to hear them
21:01:17  <bnoordhuis>right. sounds like a plan
21:01:21  <trevnorris>the event emitter's a pain because of the .call() .apply() situation
21:01:26  <trevnorris>nothing can be done about that
21:01:45  <bnoordhuis>hrm, maybe
21:01:57  <trevnorris>imho we shouldn't need to pass the "this" context to the event function, but seems that is just common practice nowadays
21:02:26  <bnoordhuis>it's conceivable that splitting up emit() into smaller helper functions could ease some of the pain
21:02:42  <bnoordhuis>then at least it won't be deopting the entire method, just the helper
21:03:17  <bnoordhuis>unless the helper is inlined, of course
21:03:28  <bnoordhuis>but stopping v8 from inlining something isn't terribly complicated :)
21:03:45  <trevnorris>hah, sure. just add a massive comment :P
21:04:44  * Alderjoined
21:04:48  <bnoordhuis>apropos, seen this? https://news.ycombinator.com/item?id=6237120
21:05:12  * Alderpart ("Closing Window")
21:05:35  <trevnorris>read a little of that, really nothing surprising for me. what'd you thing?
21:05:37  <trevnorris>*think
21:06:18  <bnoordhuis>i saw it coming, he was pretty upset
21:06:45  <bnoordhuis>i don't know, evolve or die, you know? the changes are mostly for the better
21:07:32  <trevnorris>yeah. i'm not sure why people need documentation for v8::internal anyways. imho there're enough tools out there to figure out what's going on w/o them.
21:09:19  <bnoordhuis>i guess some internals documentation wouldn't hurt if you want to attract contributors
21:09:37  <bnoordhuis>as it is, v8 is pretty much impenetrable unless you spend weeks on getting to know it
21:09:44  <MI6>libuv-node-integration: #156 UNSTABLE smartos-ia32 (3/628) osx-ia32 (1/628) linux-x64 (2/628) linux-ia32 (2/628) osx-x64 (1/628) smartos-x64 (11/628) http://jenkins.nodejs.org/job/libuv-node-integration/156/
21:09:58  <bnoordhuis>actually, that's the high barrier to entry i'm always complaining about we're missing :)
21:10:05  <trevnorris>haha
21:11:10  <trevnorris>imho it requires more than some documentation to simplify that. unless you understand fundamentals of more complex stuff like how gc works a few header docs won't do you much good.
21:12:42  <bnoordhuis>no, i guess that's true
21:13:30  <bnoordhuis>but taking myself as an example, i have a pretty solid CS background and it still took me quite some time to get up to speed
21:13:52  <trevnorris>hah, then the majority of us don't stand a chance. :P
21:14:30  <bnoordhuis>well, i guess my point is that an INTERNALS file with a few pointers could get people up and running faster
21:14:46  <bnoordhuis>like 'function y in file z is the main GC entry point', that kind of thing
21:14:57  <trevnorris>gotcha. that would be helpful.
21:15:02  <bnoordhuis>if you don't know the v8 code base, you can easily search for y for an hour
21:15:12  <trevnorris>yeah, been there.
21:15:37  <bnoordhuis>having said that, i'm not going to write it :)
21:16:03  <trevnorris>their class inheritance hierarchy is nuts. spent part of a day tracking something down. was like 7 inheritance levels deep.
21:16:15  <bnoordhuis>oh? what was it?
21:16:22  <trevnorris>yeah
21:16:30  <trevnorris>let me find my notes, sec.
21:17:54  <MI6>joyent/node: isaacs master * fe0f12b : Merge remote-tracking branch 'ry/v0.10' (+1 more commits) - http://git.io/RHIUQw
21:18:48  <trevnorris>bnoordhuis: here's the hierarchy: https://gist.github.com/trevnorris/6274297
21:20:10  <bnoordhuis>hah, okay
21:21:16  <trevnorris>one reason why I don't like OOP, is because it feels like people go wild with it. imho v8 is a prime example.
21:22:43  <rendar>bnoordhuis: hi, for that discussion of yesterday i just learnt (it seems) that if you use edge triggering or oneshot with epoll() it won't wake up all threads waiting on the same epoll fd, but will act more like iocp, what you think?
21:22:47  <bnoordhuis>it's a pretty logical inheritance chain though, imo
21:23:20  <bnoordhuis>rendar: what should i think about what?
21:23:48  <rendar>bnoordhuis, well yesterday we were saying that multithreading with edge triggering is a *no way* :)
21:24:21  <bnoordhuis>oh, from a scalability point of view
21:24:29  <rendar>yeah
21:24:42  <bnoordhuis>but that's mostly when sharing the epoll fd across threads
21:25:05  <bnoordhuis>if you add enough threads, kernel-side contention for that fd eventually becomes a bottleneck
21:25:15  <rendar>i see
21:25:21  <rendar>so would be better creating N epoll fds
21:25:34  <bnoordhuis>in general, yes
21:25:46  <rendar>interesting
21:25:53  <bnoordhuis>but as with all performance related advice: benchmark it, don't take my word for it :)
21:26:12  <rendar>yeah i'll do some tests, i'll show you results if you want :)
21:26:34  <bnoordhuis>sure, with pleasure
21:27:07  <MI6>nodejs-master: #446 UNSTABLE smartos-x64 (10/628) smartos-ia32 (5/628) osx-x64 (3/628) osx-ia32 (2/628) linux-ia32 (2/628) linux-x64 (2/628) http://jenkins.nodejs.org/job/nodejs-master/446/
21:27:32  <rendar>well, for other facilities like kqueue which doesn't support ET or oneshot, the only way to operate with multithreading is creating N kqueue fds? but iirc, kqueue does support oneshot..but i guess there will be the same problem of too much kernel-side contention also there
21:28:00  <bnoordhuis>if you use oneshot mode, you have to rearm the fd all the time
21:28:14  <rendar>yeah
21:28:14  <bnoordhuis>i've never tested it but i doubt you'll gain much that way
21:28:36  <rendar>but if i don't use oneshot, all threads will be woken up (kqueue)
21:28:51  <bnoordhuis>yep. that's level-triggered mode for you
21:29:11  <rendar>so the one-shot is a sort of edge triggering, we could say
21:29:21  <bnoordhuis>yeah
21:29:33  <bnoordhuis>remember when i said that kqueue support ET but not really?
21:29:40  <bnoordhuis>that's what i was referring to
21:29:41  <rendar>yeah now i see that :)
21:31:04  <trevnorris>bnoordhuis: whoa, overall i'm getting your env*.h, but some things are evading me.
21:31:06  <rendar>bnoordhuis: the problem is that if you use callbacks like libuv, you *must* use the oneshot, or you'll receive sporious notifications that you don't want, right?
21:31:49  <bnoordhuis>rendar: well, you don't if you stick to the 'one kqueue per thread' model
21:32:06  <bnoordhuis>but with multiple thread, yes, that becomes an issue
21:32:07  <rendar>hmm
21:32:16  <bnoordhuis>trevnorris: what is it / are they?
21:34:16  <trevnorris>bnoordhuis: it's the DomainFlag class in env.h line 281
21:35:06  <trevnorris>bnoordhuis: I want to add a field to the flags to track something else, so do I need to change the enum Fields so kCount = 1?
21:35:37  <bnoordhuis>trevnorris: no. just keep kCount as the last field
21:35:50  <bnoordhuis>or is that kFieldCount
21:35:57  <trevnorris>it's kFieldCount
21:36:06  <trevnorris>ah, wait. I see.
21:36:19  <trevnorris>genius dude, I see what you did
21:36:27  <bnoordhuis>:)
21:36:36  * stagasquit (Ping timeout: 256 seconds)
21:36:43  * stagas_joined
21:36:50  * stagas_changed nick to stagas
21:37:26  <rendar>need to sleep, bye guys ;)
21:37:31  * rendarquit
21:37:49  <bnoordhuis>yeah, i should too
21:37:58  <trevnorris>night
21:38:09  <bnoordhuis>you too, trevor
21:38:46  * c4miloquit (Remote host closed the connection)
21:42:51  * bnoordhuisquit (Ping timeout: 276 seconds)
21:46:13  * toothrotquit (Ping timeout: 248 seconds)
21:49:08  * defunctzombiechanged nick to defunctzombie_zz
21:52:27  * toothrjoined
21:56:11  * EhevuTovjoined
21:57:44  * bradleymeckquit (Quit: bradleymeck)
22:21:03  * AvianFluquit (Remote host closed the connection)
22:21:51  * sblomjoined
22:22:55  * dshaw_joined
22:23:59  <MI6>nodejs-master-windows: #243 UNSTABLE windows-x64 (20/628) windows-ia32 (27/628) http://jenkins.nodejs.org/job/nodejs-master-windows/243/
22:27:18  * austoquit (Quit: Leaving)
22:31:59  * stagas_joined
22:33:57  * stagasquit (Ping timeout: 256 seconds)
22:34:08  * stagas_changed nick to stagas
22:39:33  * stagasquit (Ping timeout: 248 seconds)
22:45:52  <MI6>joyent/node: Eivind Uggedal v0.10 * 732f8b9 : doc: add missing word in Transform stream intro - http://git.io/iv6L_A
22:46:02  * c4milojoined
22:48:18  * paulfryz_quit (Read error: Connection reset by peer)
22:48:35  * bnoordhuisjoined
22:48:53  * paulfryzeljoined
22:49:23  * mralephquit (Read error: Connection reset by peer)
22:49:35  * mralephjoined
22:53:03  <MI6>nodejs-v0.10: #1427 UNSTABLE osx-ia32 (1/597) smartos-x64 (2/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1427/
22:53:13  * bnoordhuisquit (Ping timeout: 256 seconds)
22:53:24  <MI6>joyent/node: Edward Hutchins v0.10 * 31a27ca : Added documentation for process.execArgv - http://git.io/bUXphw
22:58:21  * brsonquit (Ping timeout: 264 seconds)
22:58:47  * brsonjoined
22:59:04  * akyjoined
23:00:35  <MI6>nodejs-v0.10: #1428 UNSTABLE smartos-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1428/
23:01:45  * mikealquit (Quit: Leaving.)
23:07:59  <MI6>joyent/node: James Halliday master * 5555318 : http: removed headers stay removed - http://git.io/vaPaVw
23:08:08  <trevnorris>isaacs: ping
23:08:16  <isaacs>trevnorris: pong
23:09:31  <trevnorris>isaacs: the domain change has a side-effect. the concept/usage of process.domain needs to live on, regardless whether they load the domain module for backwards compatibility.
23:09:45  <trevnorris>isaacs: e.g. it's hard coded into the EventEmitter and other places.
23:09:48  <isaacs>right
23:10:16  <trevnorris>isaacs: so basically process.domain represents an object that will persist with the async callback, and will be passed to the listener at execution time.
23:10:19  <MI6>joyent/node: ChrisWren v0.10 * 2385fbb : doc: fixed syntax error in stream.Transform - http://git.io/Ve21Cw
23:10:51  <isaacs>correct.
23:10:52  <trevnorris>isaacs: i'm just afraid that'll lead to confusion, that we have a "domain" module, but there's also a more generic concept of a domain wrapper
23:10:59  <isaacs>hm.
23:11:14  <isaacs>well, you also have require('domain').current (which == process.domain)
23:11:41  <trevnorris>sorry, not following
23:14:06  * dominictarrquit (Quit: dominictarr)
23:14:19  <isaacs>i mean... process.domain will stil lbe the current domain object, correct?
23:14:26  <isaacs>i'm not seeing what the confusion is
23:14:31  * isaacsmaybe is confused
23:15:00  * brsonquit (Remote host closed the connection)
23:15:14  * brsonjoined
23:15:47  <trevnorris>it won't. it's completely uncoupled. you just set an object on process.domain, and pass a callback to process.setAsyncListner() and it'll call that callback and pass the async callback, list of arguments and the "domain" object when the async callback needs to run.
23:16:00  <trevnorris>here, I have some code. that'll help.
23:18:51  * c4miloquit (Remote host closed the connection)
23:20:02  * c4milojoined
23:20:31  <MI6>nodejs-v0.10: #1429 UNSTABLE osx-ia32 (1/597) smartos-x64 (2/597) osx-x64 (1/597) linux-ia32 (2/597) smartos-ia32 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1429/
23:20:58  <trevnorris>isaacs: https://github.com/joyent/node/pull/6011/files#L0R44
23:21:17  <MI6>nodejs-master: #447 UNSTABLE smartos-x64 (9/629) smartos-ia32 (3/629) osx-x64 (4/629) osx-ia32 (4/629) linux-ia32 (4/629) linux-x64 (3/629) http://jenkins.nodejs.org/job/nodejs-master/447/
23:21:36  <trevnorris>isaacs: domainListener() will be called in place of any async callback. i've already done a mock on master doing this and it works.
23:22:03  <trevnorris>isaacs: it allows fully decoupling the two while still offering the same functionality, and should be what othiym23 and others are looking for
23:22:22  <isaacs>reading your codes
23:23:01  <trevnorris>isaacs: and fyi, that's now on top of ben's multi-context branch
23:23:13  <trevnorris>so his commit is also piled in there
23:23:44  <isaacs>right
23:23:49  <isaacs>i see some of ben's codes in here.
23:24:18  <trevnorris>heh, 98% of those 3500 lines of code changes are his.
23:24:29  <trevnorris>oh duh, just should have linked my commit :/
23:24:47  <trevnorris>https://github.com/trevnorris/node/commit/0335392
23:25:46  * akyquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
23:26:39  * AvianFlujoined
23:30:02  <isaacs>oh, ok
23:30:13  <isaacs>i was kinda liking reviewing it
23:30:15  <isaacs>but next time :)
23:30:36  <isaacs>ok... so. what's teh confusion?
23:30:39  <isaacs>i'm still not getting it
23:34:05  <trevnorris>isaacs: the more i'm explaining it the less confusing it's sounding, but the idea was users can use "domains" w/o needing to use the domain module.
23:34:07  <MI6>joyent/node: Duan Yao v0.10 * 9456cf8 : doc: Add callback parameter to dgram socket.bind() - http://git.io/TR1_eQ
23:34:38  <isaacs>trevnorris: ohh, i see
23:34:49  <isaacs>trevnorris: so.. you could just do process.domain.enter() randomly?
23:34:59  <isaacs>trevnorris: how would it look to "use domains" without loading the domain module?
23:35:05  <isaacs>(that's not necessarily a bad thing, mind you)
23:35:30  <trevnorris>best example is how the domain module will be using it:
23:35:42  <trevnorris>it creates an instance of Domain and assigns it to process.domain
23:35:53  <trevnorris>then adds a callback to process.asyncListener()
23:36:18  <trevnorris>then the callback passed will receive the actuall callback that needs to be called along with any arguments that need to be passed and the Domain instance
23:36:19  <MI6>nodejs-v0.10-windows: #157 UNSTABLE windows-ia32 (7/597) windows-x64 (9/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/157/
23:37:02  <trevnorris>but see, technically you don't even need to assign something to process.domain, if all you want to do is intercept all async callbacks
23:37:08  <trevnorris>you assign a listener
23:38:44  <trevnorris>so, when you set an async listener any callback queued via an event, req_wrap, etc, will call the listener instead. instead of the actual callback.
23:40:47  <isaacs>rght
23:40:59  <isaacs>so that's what you'd use to implement continuation-local-storage or domains or whatever you want
23:41:02  <isaacs>thats the hook
23:41:05  <trevnorris>exactly
23:41:20  <MI6>nodejs-v0.10: #1430 UNSTABLE osx-ia32 (1/597) smartos-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1430/
23:43:38  <othiym23>trevnorris: do you have a diff URL that only has your stuff and not bnoordhuis's?
23:44:10  <othiym23>I'm probably too tired today to accurately gauge whether this would work for my needs or not, but I'm trying to keep up with this discussion at least
23:44:12  <trevnorris>othiym23: best I can do is for you to look at each commit. and it's not all there. i'm working through it now.
23:44:12  <MI6>joyent/node: Matthew Aynalem master * c171c49 : fixes #6031 spelling errors - http://git.io/BESziA
23:44:54  <othiym23>kk
23:45:05  <othiym23>just keeping a fire lit to make sure I get what I need in core ASAP ;)
23:45:17  <trevnorris>othiym23: and hopefully it's everything you need. the entire asynchronous callback system wraps around this giving you full control :)
23:45:23  <othiym23>the less time node-continuation-local-storage-glue is necessary, the happier I'll be
23:45:34  <trevnorris>since it's so invasive I'm waiting for the multi-context patch from ben first
23:45:54  <othiym23>yeah, I've seen the discussion between you two
23:46:07  * othiym23sits in the shadows... watching
23:46:15  <trevnorris>cool, and since i'm actively working on his branch it should be gtg the moment his patch lands
23:46:18  <trevnorris>heh
23:48:01  <othiym23>trevnorris: assuming it's built on top of process.addAsyncListener and has the same kind of opt-in loading semantics as domains, how would you feel about having a continuation-local storage module in core?
23:48:25  <othiym23>core still feels like the right place to put this feature, although with addAsyncListener there's nothing stopping it from being a 3rd party module
23:48:41  <othiym23>feature / technology / functionality
23:48:55  <trevnorris>othiym23: since even the domain module itself will be able to live in userland, any additions won't affect core performance. so I don't care really.
23:49:21  <othiym23>(o_o)-b indifference is exactly what I'm looking for
23:49:23  <trevnorris>othiym23: basically if it can be added w/o needing to change any existing core files (adding new files is fine) then i'm fine w/ it
23:49:46  <trevnorris>othiym23: if it can't be, then my implementation is incomplete and needs to be fixed.
23:50:42  <isaacs>trevnorris: i'm going to land this: https://github.com/joyent/node/pull/5464/files
23:51:08  <isaacs>trevnorris: so that'll blerg your patch a little
23:51:11  <isaacs>trevnorris: but not too bad
23:51:21  <trevnorris>isaacs: hardly at all. most that code disappears anyways :P
23:51:58  <trevnorris>well, except the var EventEmitter = require('events'); part
23:52:36  <trevnorris>isaacs: so yeah, no worries. that's a super minor fix compared to rebasing off multi-context :)
23:53:11  <MI6>nodejs-master: #448 UNSTABLE smartos-x64 (10/629) smartos-ia32 (2/629) osx-x64 (1/629) osx-ia32 (2/629) linux-ia32 (2/629) linux-x64 (2/629) http://jenkins.nodejs.org/job/nodejs-master/448/
23:54:56  * AvianFluquit (Read error: Connection reset by peer)
23:59:36  * AvianFlujoined