00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:06  * mikealjoined
00:00:07  * ircretaryjoined
00:23:59  * dominictarrquit (Quit: dominictarr)
00:25:54  * wolfeida_joined
00:25:58  * wolfeidauquit (Read error: Connection reset by peer)
00:31:02  * brsonjoined
00:34:11  * kuplatupsuquit (Ping timeout: 245 seconds)
00:35:00  * kuplatupsujoined
01:08:53  * luxigoquit (Ping timeout: 252 seconds)
01:11:01  * luxigojoined
01:16:50  * jmar777quit (Remote host closed the connection)
01:17:25  * jmar777joined
01:19:12  * qmxquit (Excess Flood)
01:20:05  * qmxjoined
01:22:00  * jmar777quit (Ping timeout: 256 seconds)
01:27:01  * c4miloquit (Remote host closed the connection)
01:31:59  * c4milojoined
01:32:11  * luxigoquit (Remote host closed the connection)
01:36:48  * wolfeida_quit (Read error: Connection reset by peer)
01:37:05  * wolfeidaujoined
01:38:11  * abraxasjoined
01:38:34  * defunctzombiechanged nick to defunctzombie_zz
01:43:39  * perezdquit (Quit: perezd)
01:48:21  * qmxquit (Excess Flood)
01:52:39  * qmxjoined
01:56:01  * c4miloquit (Remote host closed the connection)
02:09:50  * defunctzombie_zzchanged nick to defunctzombie
02:48:48  * defunctzombiechanged nick to defunctzombie_zz
03:10:35  * brsonquit (Quit: leaving)
03:38:29  * kazuponjoined
03:41:49  * kazuponquit (Remote host closed the connection)
03:42:07  * kazuponjoined
04:09:13  * pooyajoined
04:13:27  * abraxasquit (Remote host closed the connection)
04:23:42  * AvianFlujoined
04:28:50  * kazupon_joined
04:29:38  * kazuponquit (Ping timeout: 252 seconds)
04:30:56  * pooyaquit (Quit: pooya)
04:54:21  * bnoordhuisjoined
04:59:00  * kazupon_quit (Read error: Operation timed out)
04:59:28  * kazuponjoined
05:07:41  * kazuponquit (Ping timeout: 255 seconds)
05:09:51  * abraxasjoined
05:15:35  * kazuponjoined
05:17:41  * mikealquit (Quit: Leaving.)
05:31:59  * mikealjoined
05:40:21  * AvianFluquit (Remote host closed the connection)
05:47:51  * mikealquit (Quit: Leaving.)
05:53:58  * mikealjoined
05:54:30  * mikealquit (Client Quit)
05:59:28  * kazuponquit (Remote host closed the connection)
06:00:33  * kazuponjoined
06:04:41  * wolfeidauquit (Read error: Connection reset by peer)
06:04:56  * wolfeidaujoined
06:08:50  * dominictarrjoined
06:11:35  * kazuponquit (Read error: Connection reset by peer)
06:11:41  * mikealjoined
06:11:57  * kazuponjoined
06:12:14  * `3rdEdenjoined
06:12:32  * kazupon_joined
06:15:12  * kazupon__joined
06:15:32  * kazuponquit (Read error: Connection reset by peer)
06:17:56  * kazupon_quit (Ping timeout: 245 seconds)
06:27:55  * rendarjoined
06:31:48  <MI6>joyent/libuv: Ben Noordhuis v0.10 * cd10637 : linux: don't use fopen() in uv_resident_set_memory() RSS is a reflection (+1 more commits) - http://git.io/a40WUQ
06:39:00  * bajtosjoined
06:39:02  <MI6>libuv-master-gyp: #17 UNSTABLE smartos-ia32 (3/188) windows-x64 (4/189) windows-ia32 (4/189) osx-x64 (1/188) smartos-x64 (3/188) http://jenkins.nodejs.org/job/libuv-master-gyp/17/
06:41:04  <MI6>libuv-v0.10: #42 UNSTABLE linux (1/186) osx (1/186) smartos (3/186) windows (6/187) http://jenkins.nodejs.org/job/libuv-v0.10/42/
06:41:07  <MI6>libuv-v0.10-gyp: #4 UNSTABLE windows-x64 (5/187) smartos-x64 (3/186) osx-ia32 (1/186) smartos-ia32 (3/186) windows-ia32 (5/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/4/
06:48:29  * `3rdEdenquit (Quit: GTG, my talk begins in 30/40 min)
06:57:09  * wolfeidauquit (Remote host closed the connection)
06:59:28  <MI6>libuv-node-integration: #30 UNSTABLE smartos-ia32 (1/579) smartos-x64 (1/579) windows-x64 (8/579) windows-ia32 (7/579) http://jenkins.nodejs.org/job/libuv-node-integration/30/
07:04:35  * hzjoined
07:13:38  * wolfeidaujoined
07:15:28  * dominictarrquit (Quit: dominictarr)
07:30:15  * dominictarrjoined
07:32:14  * bnoordhuisquit (Ping timeout: 252 seconds)
07:33:22  * csaohjoined
07:33:34  * bnoordhuisjoined
08:07:08  * stagasjoined
08:29:58  * saghul_joined
08:30:14  * saghul_quit (Client Quit)
08:30:49  * saghulquit (Quit: ["Textual IRC Client: www.textualapp.com"])
08:31:50  * saghuljoined
08:33:14  * `3rdEdenjoined
08:41:13  * benoitcquit (Excess Flood)
08:46:31  * benoitcjoined
08:50:58  * `3rdEdenquit (Remote host closed the connection)
09:01:54  * csaohquit (Quit: csaoh)
09:21:12  * hzquit (Ping timeout: 264 seconds)
09:22:14  * dominictarrquit (Quit: dominictarr)
09:26:30  * stagasquit (Ping timeout: 264 seconds)
09:29:33  * hzjoined
09:31:41  * bnoordhuisquit (Ping timeout: 256 seconds)
09:32:18  * bajtos_joined
09:32:41  * bajtosquit (Read error: Connection reset by peer)
09:32:41  * bajtos_quit (Read error: Connection reset by peer)
09:32:58  * bajtosjoined
09:34:24  * hzquit (Ping timeout: 264 seconds)
09:55:57  * csaohjoined
09:57:57  * bnoordhuisjoined
09:58:55  <bnoordhuis>bajtos: how are you managing?
09:59:05  <bnoordhuis>i ask because i'll be away for the next hour or two
09:59:15  <bnoordhuis>if you have questions, the time is now :)
10:01:40  * dominictarrjoined
10:11:21  <creationix>I'm having trouble understanding how to write to process.binding('tcp_wrap').TCP instances
10:11:42  <creationix>it seems to always call .oncomplete sync
10:11:51  <roxlu>hi guys!
10:12:17  <creationix>but after a while, it sends a -1 status because of EAGAIN
10:13:18  <creationix>looking at node's source code, it doesn't seem to do anything special other than convert the -1 status code into a proper error object
10:14:02  <roxlu>I've got a uv_tcp_t which connects to a server, but when the server is down calling uv_run crashes with this backtrace: https://gist.github.com/roxlu/70998af3afa0c7efabe3
10:15:31  * bnoordhuisquit (Ping timeout: 260 seconds)
10:15:39  * bajtosquit (Remote host closed the connection)
10:15:39  <creationix>roxlu: weird, I've never seen that
10:18:04  <roxlu>I'm curious what might cause this.
10:19:01  <saghul>roxlu did you call uv_start_read?
10:19:40  <roxlu>saghul: uv_read_start() yes
10:19:59  <roxlu>(well, I only call it, after it connects)
10:20:03  <saghul>when you get a failure, are you calling uv_read_stop or uv_close?
10:20:18  * abraxasquit (Remote host closed the connection)
10:21:14  <roxlu>saghul: I only call uv_close() when it was connected
10:21:36  <roxlu>I try to connect, when it can't connect I start a timer
10:21:53  <roxlu>when the timers 'fires', I try to reconnect, and call uv_tcp_init() again
10:21:58  <saghul>and you call start_read after connect succeeds, right?
10:22:06  <roxlu>yes
10:22:36  <roxlu>saghul: I was testing what happens when the server is down and it can't connect (so in this situation start_read isn't called)
10:22:50  <saghul>I see
10:46:27  * csaohquit (Quit: csaoh)
10:53:32  <roxlu>saghul: I think I found something. I'm starting a timer which start the whole "connect" sequence (resolve host, connect, set read/write handlers)
10:53:45  <roxlu>when it can't connect the timer is restarted again
10:54:02  <roxlu>but.. I was also calling the "connect()" function from some other point, resetting the uv_tcp_t
10:54:28  <saghul>oh, that doesn't sound too good indeed
10:54:55  <roxlu>saghul: I think I need to stop/unset the current time
10:56:31  <roxlu>saghul: .. which fails when the timer hasn't been set yet : )
11:02:25  * csaohjoined
11:02:40  * csaohquit (Client Quit)
11:04:38  * kazupon__quit (Remote host closed the connection)
11:16:02  <roxlu>is there a way to get the status of a timer?
11:16:56  * csaohjoined
11:19:42  * bnoordhuisjoined
11:24:39  * sgallaghjoined
11:33:36  * sgallaghquit (Remote host closed the connection)
11:51:40  * sgallaghjoined
11:52:54  * `3rdEdenjoined
11:58:14  <saghul>roxlu you can do uv_is_active(timer)
12:10:45  <bnoordhuis>creationix: those oncomplete callbacks are async
12:15:20  * kazuponjoined
12:16:34  * `3rdEdenquit (Remote host closed the connection)
12:19:54  * kazuponquit (Ping timeout: 256 seconds)
12:24:32  * `3rdEdenjoined
12:30:58  * `3rdEdenquit (Remote host closed the connection)
12:36:06  * AvianFlujoined
12:48:54  * jmar777joined
12:59:24  <bnoordhuis>http://www.globalrichlist.com/ <- that website makes me feel good about myself
12:59:46  <bnoordhuis>"You’re in the top 0.05% richest people in the world by income."
13:00:08  <bnoordhuis>only 3.5 million people before me!
13:00:36  * defunctzombie_zzchanged nick to defunctzombie
13:03:05  <mmalecki>bnoordhuis: nice. I'm 0.08 %, apparently
13:03:27  <mmalecki>bnoordhuis: doesn't this Monday sound like a good Monday to chill out and go out? we make so much money anyway.
13:04:59  <bnoordhuis>yeah. weather is nice too
13:20:59  <kellabyte>its raining dolla bills yall
13:26:27  <kellabyte>bnoordhuis: if http parsing is behind the I/O rate, the parser since it's on the event loop isn't stopping the I/O threads from receiving and putting new requests in the event loop right?
13:29:17  <bnoordhuis>kellabyte: well, yes and no. if the http parser takes a long time, it blocks everything that runs on that thread
13:29:42  * kevinswiberjoined
13:29:50  <bnoordhuis>if by i/o threads you mean the file i/o threads, that's correct, those will continue to queue and dequeue work requests
13:30:21  <kellabyte>bnoordhuis: yeah thats what I meant
13:31:38  * qmxquit (Excess Flood)
13:32:03  <kellabyte>bnoordhuis: I did some benchmarking and its not extensive yet but hinted that http_parser is causing some instruction starvation so wanted to make sure it wasn't holding I/O back, but it is probably holding back the response rate
13:33:25  <bnoordhuis>kellabyte: that sounds plausible. in simple benchmarks, http_parser_execute usually dominates
13:33:51  <kellabyte>bnoordhuis: if I wanted to use more cores to handle http_parser, what would be best? putting requests in additional event loops?
13:34:20  <bnoordhuis>kellabyte: yes
13:34:38  <bnoordhuis>you can share a socket between multiple threads/processes
13:35:12  <kellabyte>bnoordhuis: ah sweet, is there a way to inspect the event loop length? so I can try and keep like say 4 pretty even
13:35:16  * qmxjoined
13:35:38  <bnoordhuis>kellabyte: what's your definition of an 'event loop length'?
13:35:58  <bnoordhuis>btw, test/benchmark-multi-accept.c shows how you can share handles across threads
13:36:16  <bnoordhuis>the same technique applies to sharing handles cross-process
13:36:35  <kellabyte>bnoordhuis: I dunno :P but one thread may get behind another if its requests take longer to process, so I don't want to just do 1 here, 1 there type of distribution
13:37:30  <bnoordhuis>kellabyte: you have to track that yourself. you can e.g. stop listening in one process/thread when it has |n| more active connections than the other threads
13:37:55  <bnoordhuis>libuv itself doesn't provide that kind of high-level abstractions but all the primitives are there
13:38:11  <bnoordhuis>e.g. message passing between processes, mutexes for thread synchronization, etc
13:38:14  <kellabyte>bnoordhuis: ok cool. I thought if the event loop had a count or something I would just give it to the shortest event loop
13:46:39  * c4milojoined
13:46:43  * kazuponjoined
14:09:19  * kazuponquit (Remote host closed the connection)
14:13:31  * kevinswiberquit (Remote host closed the connection)
14:27:35  * bajtosjoined
14:29:19  * kevinswiberjoined
14:44:19  * mikealquit (Quit: Leaving.)
14:48:28  * sgallaghquit (Remote host closed the connection)
14:49:43  * kazuponjoined
14:53:35  * piscisaureus_joined
14:55:02  <bajtos>bnoordhuis: ping
14:55:14  <piscisaureus_>hey bajtos
14:55:16  <piscisaureus_>how are you doing?
14:55:35  <bajtos>piscisaureus_: pretty well
14:55:45  <bajtos>probably better than you ;-)
14:55:53  <piscisaureus_>bajtos: i sure hope so for you :)
14:56:05  <bnoordhuis>bajtos: what's up?
14:56:35  <bajtos>bnoordhuis: well I am fixing the findings from your code review
14:56:51  <bnoordhuis>very good
14:56:55  <bajtos>and I am not sure if I should change also runner-win.c
14:57:21  <bajtos>I guess that piscisaureus_ has more commits there, so his opinion overrules yours? :)
14:57:36  <bajtos>piscisaureus_: we are talking about this PR: https://github.com/joyent/libuv/pull/786
14:57:38  <piscisaureus_>bajtos: what is it about
14:57:39  <piscisaureus_>ah
14:57:40  <bnoordhuis>`git shortlog -ns` says no
14:58:01  <bnoordhuis>(the only metric that counts)
14:58:07  <piscisaureus_>waaa
14:59:18  * sgallaghjoined
15:01:02  <bajtos>ok :-D
15:04:23  * hzjoined
15:04:24  <piscisaureus_>felixge: hey
15:04:59  <piscisaureus_>felixge: are you coming to <s>queensday</s>kingsday again in Amsterdam?
15:06:41  <bajtos>bnoordhuis: I fixed all findings, could you please review if the code is ok now?
15:07:42  <bnoordhuis>bajtos: sure, but not now. it's dinner time around here
15:08:01  <bajtos>bnoordhuis: no problem, whenever you have time.
15:12:15  * kazuponquit (Remote host closed the connection)
15:14:14  * bnoordhuisquit (Ping timeout: 252 seconds)
15:19:38  * kazuponjoined
15:19:52  * defunctzombiechanged nick to defunctzombie_zz
15:24:35  <isaacs>ircretary: tell bnoordhuis I'm about ready to add whatever gross kludges are necessary to stop this "cannot call method destroy() of undefined" error
15:24:36  <ircretary>isaacs: I'll be sure to tell bnoordhuis
15:28:55  * bajtosquit (Remote host closed the connection)
15:39:25  * AvianFluquit (Read error: Connection reset by peer)
15:40:01  * AvianFlujoined
15:48:15  * kevinswiberquit (Remote host closed the connection)
15:49:33  * bnoordhuisjoined
15:51:42  * bajtosjoined
15:52:14  * mikealjoined
15:56:40  <MI6>joyent/node: isaacs v0.10 * 1d794ec : test:+fix+dgram-bind-default-address+on+osx Allow+the+IPv4-mapped-as-IPv - http://git.io/wL_x6Q
15:57:09  * mikealquit (Quit: Leaving.)
15:57:19  <isaacs>ircretary: tell bnoordhuis nevermind, turned out not to be kludgey at all, really. perfectly valid bug.
15:57:20  <ircretary>isaacs: I'll be sure to tell bnoordhuis
15:58:21  * bnoordhuisquit (Ping timeout: 256 seconds)
15:59:29  <tjfontaine>you scared him off
15:59:46  <tjfontaine>isaacs: just realized the dates on your scrum last week were off
15:59:56  <isaacs>oh, wut?
16:00:10  <tjfontaine>19th was friday
16:00:17  <isaacs>lol
16:00:29  <isaacs>i had 2 16's in there
16:00:38  <tjfontaine>indeed
16:01:05  <tjfontaine>I'm interested to see how scrum works from the plane
16:02:18  <isaacs>oh, right, you're on a plane :)
16:02:18  * sgallaghquit (Remote host closed the connection)
16:02:22  <isaacs>feel free to just send me updates if you'd like
16:02:37  <isaacs>i can be scrumptious today
16:02:44  <tjfontaine>hah
16:02:54  <tjfontaine>ok
16:04:05  * bnoordhuisjoined
16:07:28  * pooyajoined
16:08:23  * sgallaghjoined
16:08:23  * sgallaghquit (Remote host closed the connection)
16:09:04  * sgallaghjoined
16:09:07  * sgallaghquit (Remote host closed the connection)
16:09:23  * sgallaghjoined
16:12:31  * trevnorrisjoined
16:13:17  <trevnorris>morning
16:13:43  <tjfontaine>morn
16:14:47  <trevnorris>so clang 3.3 is coming out soon I believe.
16:15:35  * sgallaghquit (Remote host closed the connection)
16:16:36  <tjfontaine>I have no problem believing that, but haven't been paying attention to the channel close enough to verify a date
16:17:32  <MI6>nodejs-v0.10: #154 UNSTABLE windows-ia32 (8/579) linux-ia32 (2/579) smartos-x64 (3/579) smartos-ia32 (4/579) windows-x64 (7/579) http://jenkins.nodejs.org/job/nodejs-v0.10/154/
16:19:54  <tjfontaine>hmm too many failures on smartos
16:20:19  <tjfontaine>http://jenkins.nodejs.org//job/nodejs-v0.10/154/DESTCPU=ia32,label=smartos//tapTestReport/test.tap-360/
16:20:27  * dapjoined
16:23:04  <tjfontaine>rebuild scheduled
16:25:53  * sgallaghjoined
16:31:43  <bnoordhuis>morning guys
16:32:01  <tjfontaine>morning
16:32:14  <bnoordhuis>how was the visit to your mom, tj?
16:32:24  <tjfontaine>quick, but good
16:32:38  <tjfontaine>the airlines tried their best to ruin my day today
16:32:54  <kellabyte>tjfontaine: ouch
16:33:18  <tjfontaine>I only had 30 mins to make my connection, and my flight was delayed 20mins in the air
16:33:33  <tjfontaine>lucky for me my flight to sfo was 45 mins late
16:36:07  * kevinswiberjoined
16:37:37  * gblockjoined
16:38:04  <gblock>Hello folks. Quick and easy question.
16:38:17  <gblock>Callbacks in node, should err be undefined or null if there is no error?
16:38:31  <kellabyte>gblock: hey!
16:38:38  <gblock>hey kelly
16:38:50  <bnoordhuis>gblock: null
16:38:57  <gblock>Callback question is because I am seeing inconcistencies
16:38:58  <gblock>ok
16:39:13  <tjfontaine>falsey :)
16:39:17  <bnoordhuis>it's not critical but most code in node passes null
16:39:47  <gblock>lol
16:40:31  * kevinswiberquit (Remote host closed the connection)
16:41:04  <gblock>@bnoordhuis have you released any updated guidance on this?
16:41:20  <gblock>@bnoordhuis because a ton of folks out there just right code that checks if err is undefined.
16:41:25  <MI6>nodejs-v0.10: #155 UNSTABLE windows-ia32 (6/579) smartos-x64 (1/579) smartos-ia32 (1/579) windows-x64 (6/579) http://jenkins.nodejs.org/job/nodejs-v0.10/155/
16:41:28  <gblock>sorry right == write
16:42:18  <bnoordhuis>gblock: as in `if (err === undefined)`?
16:42:28  <gblock>yup
16:42:32  <bnoordhuis>== or ===?
16:42:35  <tjfontaine>those people suck
16:42:49  <isaacs>gblock: anything falsey is fine.
16:42:55  * inolenquit (Quit: Leaving.)
16:43:01  <isaacs>gblock: use `if (!err) { ... }`
16:43:13  <gblock>@isaacs that's what I always use
16:43:28  <isaacs>gblock: actually, even: `if (!err || !(err instanceof Error))` is as loose as you can be.
16:43:39  <isaacs>if someone is passing non-Errors as err firstargs, then they are incorrect in a deep way
16:44:02  <isaacs>but, in practice, falsey is enouhg
16:44:37  <isaacs>gblock: if thye check for `err === undefined` they'll run into trouble VERY quickly using almost any node APIs
16:44:48  <isaacs>gblock: i think it's hard to make that kind of mistake for very long;
16:45:20  <gblock>@isaacs good point
16:45:38  <gblock>@isaacs so if (!err) as opposed to if (err) ?
16:45:45  <isaacs>$ node -e "require('fs').readFile('README.md', function(er) { if (er !== undefined) console.log('ERROR', er) })"
16:45:47  <gblock>@isaacs I usually use if (err)
16:45:48  <isaacs>ERROR null
16:45:54  <isaacs>gblock: well, that depends.
16:46:10  <isaacs>gblock: if (!err) would precede code that runs if there is not an error. if (err) would precede code that runs if there is an error.
16:46:48  * mikealjoined
16:49:02  <gblock>@isaacs ok, but there is no fundamental problem with if (err)
16:49:37  <gblock>@isaacs in my code I usually have the code branch IF there is an error, otherwise it continues
16:50:46  * kevinswiberjoined
16:50:54  <isaacs>bnoordhuis: 78c5de598bb6ebd68d8d93fabdcebdca1f024580 breaks os.type() on sunos
16:51:03  <gblock>@isaacs thanks for the clarification
16:51:22  <isaacs>bnoordhuis: i don't see why, but we're raising an EBADF on that function now
16:54:13  <MI6>joyent/node: isaacs v0.10 * 01e2920 : http:+Don't+try+to+destroy+nonexistent+sockets Fixes+#3740 In+the+case+ - http://git.io/dlcpSw
16:55:41  <trevnorris>bnoordhuis: "make test-valgrind" spews output on master. anything to worry about?
16:57:04  <MI6>joyent/node: isaacs v0.8 * 4dc5b13 : http:+Don't+try+to+destroy+nonexistent+sockets Fixes+#3740 In+the+case+ - http://git.io/nG4nAA
17:00:02  * `3rdEdenjoined
17:00:47  * qmxchanged nick to qmx|lunch
17:03:55  * csaohquit (Quit: csaoh)
17:04:26  <isaacs>bnoordhuis: ah.. looks like sunos just always raises EBADF there... peraps that's why we were ignoring it in the first place.
17:06:03  * mikealquit (Quit: Leaving.)
17:07:45  * TooTallNatejoined
17:08:02  * brsonjoined
17:13:07  <MI6>nodejs-v0.10: #156 UNSTABLE windows-ia32 (7/580) smartos-x64 (1/580) smartos-ia32 (1/580) windows-x64 (7/580) http://jenkins.nodejs.org/job/nodejs-v0.10/156/
17:13:12  <isaacs>bnoordhuis: nope, actually, it's not EBADF at all. just that uname() can return any non-negative int as a success value.
17:19:30  * `3rdEdenquit (Remote host closed the connection)
17:19:44  * mikealjoined
17:25:02  * kevinswiberquit (Read error: Connection reset by peer)
17:25:50  <MI6>nodejs-v0.8: #41 UNSTABLE smartos-ia32 (3/472) osx-x64 (1/472) linux-x64 (2/472) smartos-x64 (1/472) osx-ia32 (1/472) linux-ia32 (1/472) http://jenkins.nodejs.org/job/nodejs-v0.8/41/
17:25:56  * kevinswiberjoined
17:29:21  * inolenjoined
17:32:43  <trevnorris>piscisaureus_: libuv "make bench" has 8 failures. those known?
17:32:59  <piscisaureus_>trevnorris: depends. they
17:33:31  <piscisaureus_>trevnorris: some time out on windows because someone (**) always adds tests that take minutes on windows
17:33:42  <piscisaureus_>trevnorris: however there should not be any real failures
17:33:45  <trevnorris>piscisaureus_: nope. all asserts failing.
17:33:50  <piscisaureus_>oh
17:34:05  <trevnorris>one sec. i'll gist it.
17:35:59  * kuplatupsuquit (Read error: Operation timed out)
17:36:07  * kuplatupsujoined
17:36:23  * kevinswiberquit (Remote host closed the connection)
17:36:36  <piscisaureus_>trevnorris: ah multi-accept is also failing for me
17:38:22  <trevnorris>piscisaureus_: ok cool. not just me then. =)
17:38:26  <MI6>joyent/node: isaacs master * 025f913 : http:+Don't+try+to+destroy+nonexistent+sockets Fixes+#3740 In+the+case+ - http://git.io/sOEoDQ
17:38:44  <piscisaureus_>trevnorris: it's only multi-accept for you? also which platform is this?
17:39:18  <trevnorris>piscisaureus_: yeah. linux x64. i'll build for ia32 and test that.
17:41:02  * qmx|lunchchanged nick to qmx
17:41:41  * brsonquit (Ping timeout: 245 seconds)
17:42:46  * brsonjoined
17:48:37  <isaacs>indutny: so, i've been agonizing over this streams api change for writev
17:48:51  <indutny>:)
17:48:54  <indutny>and what you come to?
17:48:57  <isaacs>indutny: cork/uncork sucks.
17:49:00  <indutny>hahahaha
17:49:02  <isaacs>indutny: and bulk(writer) sucks
17:49:05  <isaacs>they both suck a lot.
17:49:05  <indutny>great
17:49:18  <isaacs>i mean, really really a lot
17:49:47  <isaacs>here's why: both add yet another function that doesn't look particularly "streamy", but which extension classes have to be careful not to clobber.
17:50:19  <trevnorris>piscisaureus_: you also getting "Assertion failed in test/benchmark-udp-pummel.c on line 194"?
17:50:26  <isaacs>also: _writev([chunks],[encodings],cb) seems wonky. i'd prefer _writev([{chunk,encoding}], cb)
17:50:29  <isaacs>but whatever.
17:50:47  <piscisaureus_>trevnorris: no. I do get a couple of timeous though
17:50:51  <piscisaureus_>*timeouts
17:50:54  <trevnorris>hm.
17:50:55  <isaacs>indutny: parallel arrays are kind of weird.
17:50:58  <indutny>oook
17:51:00  <indutny>that's not a problem
17:51:03  <isaacs>indutny: right.
17:51:05  <indutny>so what can we do in terms of API
17:51:06  <indutny>?
17:51:08  <isaacs>indutny: don't go rewriting everything right now :)
17:51:29  <isaacs>indutny: the implementation is ok, i mean, it's well written and goes pretty fast, and we can tweak that later.
17:51:35  <isaacs>getting the API right is harder.
17:51:58  <isaacs>indutny: what if we just had a Writable.prototype.writev(chunks, encodings, callback)
17:52:12  <indutny>sure
17:52:18  <indutny>I like it
17:52:24  <isaacs>it's not quite as magical, sort of simpler.
17:52:26  <indutny>and it seems that its what I've proposed at first time :)
17:52:29  <indutny>haha
17:52:29  <isaacs>hahahah
17:52:50  <isaacs>so you need to know your chunks and encodings up front, and write them all at once.
17:52:58  <isaacs>and it'll just dump them into the buffer, and then call clearBuffer()
17:53:31  <isaacs>and, if you have a _writev() defined, it'll use that every time it calls clearBuffer, whether via writev() or not, and if you don't, i'tll always just do _write() over and over again
17:54:02  <isaacs>this way, all streams have a Writable.writev method, and all streams can benefit even if you're just writing fast rather than using Writable.writev
17:54:23  <isaacs>still has the parallel array smell, but i think maybe we can live with that.
17:54:30  <isaacs>might be a good idea to bikeshed on the mailing list, also.
17:54:33  <isaacs>painful as that will be.
17:56:10  <isaacs>indutny: what do you think about that?
17:56:35  <indutny>yeah
17:56:38  <isaacs>indutny: i brought up the question to a few people, and suggestions ranged from awful to terrible, but i think we'd be best to have a bit of input on this.
17:56:42  <indutny>I like it
17:56:43  <trevnorris>piscisaureus_: here's some of the output: https://gist.github.com/trevnorris/5437098
17:56:49  <isaacs>even if we end up doing what no one says they want :)
17:57:37  <MI6>nodejs-master: #167 UNSTABLE windows-ia32 (8/583) smartos-x64 (4/583) smartos-ia32 (1/583) windows-x64 (8/583) http://jenkins.nodejs.org/job/nodejs-master/167/
17:58:14  <indutny>haha
17:58:17  <indutny>ok, sure
17:58:21  <indutny>I'll implement it later today
17:59:22  <isaacs>indutny: kewl. i'll send a message to the mailing list and try to get some ideas floating around
17:59:42  <indutny>ok
18:00:11  <isaacs>tjfontaine: i was totally already in the middle of fixing this when you sent me your scrum
18:00:16  <isaacs>tjfontaine: or at least, when i saw it :)
18:01:04  <MI6>joyent/node: isaacs v0.10 * c777473 : os:+Fix+uname()+error+handling+on+sunos The+uname+function+can+return+an - http://git.io/8CSC9w
18:01:45  * isaacs&
18:01:45  <LOUDBOT>IT IS THE MANDRY OF T
18:04:01  <piscisaureus_>trevnorris: those udp failures are probably because you hit the fd limit
18:04:08  <trevnorris>ah, ok.
18:04:08  <piscisaureus_>trevnorris: the others I have seen as well
18:04:29  * CoverSli1echanged nick to CoverSlide
18:10:17  * dominictarrquit (Quit: dominictarr)
18:21:25  <trevnorris>for anyone. TCPWrap::Initialize runs HandleWrap::Initialize, then StreamWrap::Initialize. even though the later also runs the former.
18:21:42  <trevnorris>so HandleWrap::Initialize runs twice?
18:22:34  <MI6>nodejs-v0.10: #157 UNSTABLE windows-ia32 (7/580) windows-x64 (8/580) http://jenkins.nodejs.org/job/nodejs-v0.10/157/
18:24:14  <bnoordhuis>trevnorris: doesn't matter right now, HandleWrap::Initialize() is a no-op
18:24:28  <trevnorris>bnoordhuis: kk
18:28:20  <tjfontaine>isaacs: :)
18:37:17  * pooyaquit (Quit: pooya)
18:38:56  <trevnorris>bnoordhuis: how about StreapWrap::StreamWrap has stream->data = this, and HandleWrap::HandleWrap has h->data = this. that redundant?
18:40:43  <bnoordhuis>trevnorris: yes but not fatally so
18:40:54  <trevnorris>ok. just want to make sure i'm not missing something. =)
18:47:18  <MI6>libuv-master-gyp: #18 ABORTED smartos-ia32 (3/188) http://jenkins.nodejs.org/job/libuv-master-gyp/18/
18:52:04  <benoitc>hi all
18:52:21  <MI6>libuv-master-gyp: #19 UNSTABLE smartos-ia32 (3/188) windows-x64 (5/189) windows-ia32 (5/189) smartos-x64 (3/188) http://jenkins.nodejs.org/job/libuv-master-gyp/19/
18:53:08  <tjfontaine>piscisaureus_: have you ever seen this test fail before? http://jenkins.nodejs.org//job/libuv-master-gyp/lastCompletedBuild/DESTCPU=ia32,label=windows//tapTestReport/test.tap-20/
18:53:29  <benoitc>does uv_spawn need to be run in the main thread ?
18:54:11  <tjfontaine>everything that's not uv_async needs to be run in the main thread?
18:55:01  * brsonquit (Ping timeout: 248 seconds)
18:57:11  * brsonjoined
19:01:32  * gblock_joined
19:02:26  * gblockquit (Ping timeout: 272 seconds)
19:02:26  * gblock_changed nick to gblock
19:02:33  * stagasjoined
19:04:13  <piscisaureus_>bnoordhuis: meh. github doesn't line-wrap
19:04:24  * dominictarrjoined
19:05:34  * stagas_joined
19:05:57  <bnoordhuis>benoitc: uv_spawn() works with loops that are not uv_default_loop()
19:06:06  * stagasquit (Client Quit)
19:06:10  * stagas_changed nick to stagas
19:06:10  <bnoordhuis>the 'only the main loop' thing was a libev limitation
19:06:34  <benoitc>ahhhh good to know
19:06:37  <benoitc>thanks
19:19:52  * mjr__joined
19:20:21  * bajtosquit (Remote host closed the connection)
19:32:02  * kazuponquit (Remote host closed the connection)
19:32:11  * bnoordhuisquit (Ping timeout: 252 seconds)
19:35:06  <trevnorris>do you only have to free uv_buf_t buf.base? (e.g. don't have to do anything with "buf")
19:40:35  * sblomjoined
19:43:26  <indutny>isaacs: gosh
19:43:31  <indutny>this stuff complicates http.js a lot
19:43:35  <indutny>stream.writev()
19:43:55  <indutny>may be we can introduce at least internal ._cork/._uncork?
19:54:13  * indexzerojoined
19:58:01  <trevnorris>not horrible for my first attempt at removing the slab allocator: https://gist.github.com/trevnorris/5437947
19:58:08  <trevnorris>still have a few things up my sleeve.
19:58:38  <tjfontaine>how are you handling the shrinking portion?
19:59:02  <trevnorris>tjfontaine: no shrinking. every read is a new buffer.
19:59:18  <trevnorris>that's why the really low "length" are much worse.
20:00:12  * eris0xffjoined
20:00:13  <tjfontaine>trevnorris: so what does memory usage look like during this? consider libuv may initially ask for 64k but then only use 1k?
20:01:32  <trevnorris>tjfontaine: for "http/cluster.js type=bytes length=4 c=50", exact same as master.
20:01:55  <trevnorris>because each alloc is it's own buffer, gc will clean the entire thing up when complete.
20:02:17  <tjfontaine>right but if things are held for a period it's potentially holding considerably more?
20:02:30  <trevnorris>hm. yeah. that's true.
20:03:06  <trevnorris>i'm going to replace slaballocator w/ the new buffer slice. it's a shiz ton faster, and achieves the same thing.
20:03:14  <trevnorris>see how that goes.
20:04:47  <trevnorris>but first. my mouth is on fire from these samosas. need a drink
20:04:58  <tjfontaine>haha
20:08:54  <eris0xff>hey guys: i'm working on a server using libuv that accepts open/close, read/write, rm, stat and cd requests asynchronously. i'm working on a clean way to respond to them: I'm thinking that uv_work request would be a good general way to handle them
20:09:00  <trevnorris>tjfontaine: oh, and about hanging onto a piece of memory for a while. that memory leak will happen anyways since a single small chunk will keep the entire thing alive.
20:09:01  <eris0xff>is that the accepted apttern
20:09:03  <eris0xff>?
20:09:28  <tjfontaine>trevnorris: the whole slab yes, but you have enough knowledge in the same tick to keep your slab allocations low
20:09:43  <eris0xff>but maybe that's overkill:
20:09:50  <trevnorris>hm. interesting point.
20:11:00  <tjfontaine>trevnorris: I'm not saying the slab is perfect, but this is something you'll need to take into account, there is realloc but that can be expensive
20:11:19  <tjfontaine>trevnorris: I don't have any numbers on it, but that's what you're good at :)
20:12:53  * Benvie_joined
20:13:32  <trevnorris>heh, thanks.
20:14:26  <trevnorris>eris0xff: work me through a bit of this. you'll be passing a callback to each of those operations, correct?
20:18:21  <eris0xff>correct. it's almost a 1:1 translation. the client says "write this data on this file handle and let me know when you're done". i decode the requests and dispatch it. ideally each dispatch has a generic callback which generates a response over the same stream as the request (uv_write)
20:18:34  <eris0xff>or close or whatever
20:19:17  <eris0xff>so I'm wondering if a generic callback mechanism exists in libuv (uv_work apparently)
20:19:55  <trevnorris>eris0xff: you talking about something like http://nikhilm.github.io/uvbook/threads.html#libuv-work-queue
20:20:51  <eris0xff>so the rough response callback structure looks like: dispatch work request -> dispatch response write
20:21:03  <eris0xff>(yes re work queue)
20:21:56  <eris0xff>some of the callbacks have direct mappings to uv_write or uv_read, but some are not easy to quantify (like cd etc)
20:23:35  <eris0xff>i'm afraid the most efficient answer is "do a uv_ callback that is the closest to the request type"
20:24:00  <eris0xff>if there isn't one, use work queue
20:24:58  <eris0xff>(was looking for a semi-elegant, accept request type t, build type t iorequest, dispatch type t iorequest, send response)
20:25:20  <eris0xff>i guess I'll just do a switch / case
20:26:08  <eris0xff>code getting tricky *all* of it is async, all event driven. :-)
20:26:19  <eris0xff>that's what makes it fun and useful
20:29:04  <trevnorris>eris0xff: so you're talking about these callbacks? https://github.com/joyent/libuv/blob/master/include/uv.h#L342-L358
20:32:20  * kazuponjoined
20:34:46  <eris0xff>hmm
20:36:03  <trevnorris>guess what I was getting at is each is going to expect a specific type of callback (e.g. uv_fs_cb)
20:36:26  <trevnorris>so doing know if there's a "generic callback" callback. but again, i'm a total libuv newb.
20:37:42  * bnoordhuisjoined
20:38:28  <eris0xff>interesting question: the requests i'm receiving over the net are very similar to the ones in uv_fs_type. I perform them async and write a result response back to the requester. so I guess i just needed to clarify to myself. I receive a request via the network stream (uv_read_start, uv_write) and perform the op as a local system operation
20:39:40  * jmar777quit (Remote host closed the connection)
20:39:46  <eris0xff>(uv_fs_open, uv_fs_close etc)
20:40:13  * jmar777joined
20:40:26  * kazuponquit (Ping timeout: 245 seconds)
20:41:01  <eris0xff>so trevnorris, the answer is that it has to be custom for each type of operation.
20:41:06  <eris0xff>but the pattern is the same
20:41:32  <trevnorris>cool. sounds good to me.
20:42:06  * bnoordhuisquit (Ping timeout: 245 seconds)
20:43:06  <eris0xff>an ascii diagram of the stream looks like: incoming request callback->decode->dispatch op callback->dispatch response callback (looks nice and neat that way. don't look at the code :-)
20:43:25  <trevnorris>lol
20:44:07  <eris0xff>I need a clean co-routine/iterator lib in C to deal with callback hell
20:44:21  * jmar777quit (Ping timeout: 248 seconds)
20:46:18  <trevnorris>well, all the uv_*_cb use pretty much the same args, except the first is a specific uv_*_t.
20:47:10  <trevnorris>since uv_handle_t is the abstract class of all the others, wonder if you could create a small set of callbacks that call a single sort of:
20:48:38  <trevnorris>(*uv_generic_cb)(uv_handle_t*, int, int, cb_type)
20:49:46  <trevnorris>don't know if that would even help, but it's the best i've got. :)
20:50:23  * rendarquit
20:53:11  * pooyajoined
21:03:46  <eris0xff>trevnorris: you might be able to, but whether it's worth the work is anyone's guess
21:04:36  <eris0xff>right
21:05:16  <eris0xff>i haven't dug through the sources yet. i suppose there's a private generic io callback interface i could access that would look a whole lot like a uv_work_t
21:05:44  <eris0xff>i figure it out tonight
21:06:23  <indutny>hohoho
21:07:35  <eris0xff>problem is I'm rewriting a lib that isn't callback based into one that is. basically involves unrolling a lot of sequential code and tying it back together with the relatively long lived request objects
21:27:39  <trevnorris>tjfontaine: one of the advantages to the new approach is that a buffer isn't created until the callback is called.
21:27:54  <trevnorris>which removes a buffer instantiation for all EOF/errors
21:28:31  <tjfontaine>the alloc_cb isn't triggered regardless?
21:29:08  <trevnorris>tjfontaine: it's triggered every time, but it just malloc's. i tie that data to a buffer right before it's returned.
21:29:18  <trevnorris>but only if data will be returned.
21:29:51  <tjfontaine>sure but the malloc happens, the only time the malloc would happen on the slab buffer is if it fell on the slab already being full?
21:30:18  <trevnorris>true. but malloc is much less expensive then SetHiddenValue or Persistent::New()
21:31:50  * gblockquit (Ping timeout: 256 seconds)
21:32:19  <trevnorris>and every Shrink() does a SetHiddenValue().
21:33:27  <isaacs>indutny: it complicates http.js now?
21:33:32  <isaacs>indutny: er, how?
21:33:46  <isaacs>indutny: if it complicates http.js, then it's probably not a good api :)
21:33:54  <indutny>because http.js is fucking awesome
21:33:58  <indutny>and does some internal buffering
21:33:59  <isaacs>indutny: hahahaha
21:34:00  <indutny>in ._send
21:34:20  <indutny>and in order to make it work I needs to change all the path from ._send() to actual socket.writev() call
21:34:26  <indutny>and this is fucking retarded
21:34:34  <isaacs>indutny: yeah...
21:34:38  <indutny>and with cork/uncork streams are doing this for me
21:34:53  <isaacs>why is http.js doing its own buffering... just for requests that don't have a socket yet?
21:34:58  <indutny>yes
21:35:08  <indutny>how is it even possible :)
21:35:13  <indutny>to have request without socket
21:35:20  <indutny>it could be not connected yet
21:35:28  <isaacs>indutny: var req = http.request(...); req.write('ok'); req.end()
21:35:32  <indutny>I know I know
21:36:15  <isaacs>indutny: it'd be better to just not have that _send bs.
21:36:47  <isaacs>Writable is already caching shit
21:37:36  * kazuponjoined
21:39:20  <indutny>ye
21:39:29  <indutny>we can just call .cork()
21:39:33  <indutny>and .uncork() it on connection ;)
21:40:08  <isaacs>oic.
21:40:10  <isaacs>right
21:40:14  <isaacs>and then get rid of _send()
21:40:18  <isaacs>you see, cork was a good idea! :)
21:40:24  <indutny>:)
21:40:27  <indutny>haha
21:42:59  <isaacs>indutny: couldn't we also do something like: _write = function(..) { if (!this.socket) { this.once('socket',do the write); return false } ... }`
21:44:04  <isaacs>but i guess that gets complicated, huh...
21:45:12  * kazuponquit (Ping timeout: 264 seconds)
21:45:14  <isaacs>indutny: ok, keep exploring cork()/uncork()
21:45:21  <mjr__>cork should be a giant perf win for chunked responses, I would guess.
21:45:26  <isaacs>let's pretend that's the pitch
21:45:34  <isaacs>mjr__: yeah, there's a few API ideas on the table atm
21:45:45  <isaacs>mjr__: the goal is proper writev, finally
21:45:53  <isaacs>after almost 3 years since ry proposed it
21:47:22  * wolfeidauquit (Remote host closed the connection)
21:52:34  * c4miloquit (Remote host closed the connection)
21:55:00  <indutny>:)
21:56:43  <trevnorris>isaacs: so they're a hack that will noticeably speed up the code, but it's ugly as monk fish.
21:57:02  <isaacs>trevnorris: what are a hack?
21:57:08  <isaacs>trevnorris: cork/uncork?
21:58:02  <trevnorris>isaacs: no. it's for making a super cheap slice of a buffer out of an existing object.
21:58:30  <trevnorris>isaacs: the hack looks like-ish : "existing_obj.__proto__ = Buffer.prototype"
21:59:28  <isaacs>ok..
21:59:33  <isaacs>i'd like to not rely on __proto__
21:59:49  <isaacs>but what does that give us?
22:00:14  <trevnorris>me neither. the issue arose from needing to create a buffer instance using an existing char* in cc.
22:00:26  <isaacs>ic
22:00:57  <trevnorris>the char* needs to be tied to an object, so right now I'm returning an unallocated buffer, then allocating to it afterwards.
22:01:36  <trevnorris>but the real advantage would be creating a buffer from a slice, since the js specific method could do all the assigning and such.
22:02:02  <trevnorris>i'll create a benchmark demo and let you decide from the results.
22:02:19  <isaacs>kewl
22:02:23  <isaacs>i've gotta relocate, bbiab
22:07:26  <trevnorris>tjfontaine, TooTallNate: api question. Buffer::New(const char* data, size_t length) copies the data. but I want to make pretty much the same for using the original data.
22:07:51  <trevnorris>would swapping the arguments to ::New(size_t length, char* data) be too ambiguous?
22:08:22  <TooTallNate>trevnorris: ya, i wouldn't like that so muchj
22:08:26  <tjfontaine>what's wrong with a ::Copy?
22:08:33  <TooTallNate>trevnorris: or ::Use()? :D
22:08:39  <tjfontaine>right
22:08:52  <trevnorris>tjfontaine: renaming the old would break backwards compatibility.
22:09:12  <trevnorris>ok. so just extend it. I like ::Use().
22:09:13  <trevnorris>works for me.
22:09:25  <TooTallNate>cool :)
22:09:44  * wolfeidaujoined
22:09:47  * wolfeidauquit (Remote host closed the connection)
22:09:57  * wolfeidaujoined
22:10:05  <trevnorris>thx both. just saved me 30 mins of head scratching.
22:17:02  * dscape_quit (*.net *.split)
22:17:02  * joclekquit (*.net *.split)
22:18:01  * dscape_joined
22:18:01  * joclekjoined
22:18:53  <trevnorris>mother effing. include/v8.h is screwed up or something. doxygen output keeps linking incorrectly. but it worked in 3.17.16
22:20:50  <trevnorris>TooTallNate, tjfontaine: last api-ish question. there a general preference between size_t and uint32_t?
22:20:58  * gblockjoined
22:21:07  <trevnorris>i started using the later since use Uint32Value() on passed arguments.
22:22:18  <TooTallNate>trevnorris: i think on 64-bit, size_t is 64-bit
22:22:19  * indexzeroquit (Quit: indexzero)
22:22:20  <tjfontaine>for expressing what? if I'm expressing the size/length of something I generally prefer size_t
22:22:40  <tjfontaine>which as TooTallNate points out, differs based on platform
22:23:31  <trevnorris>ok so "size_t val = args[0]->Uint32Value();" is nothing bad or whatnot?
22:24:41  <trevnorris>was using uint32_t since that's as large a reliable integer can be passed from js, so didn't need a larger value.
22:25:23  <tjfontaine>if you do maths on it though it would be better to use a size_t for it
22:26:05  <trevnorris>noted. thanks.
22:31:48  * gblockpart
22:32:56  * kazuponjoined
22:39:10  * c4milojoined
22:40:04  * kazuponquit (Remote host closed the connection)
22:44:37  * indexzerojoined
22:58:19  * wolfeidauquit (Read error: Connection reset by peer)
22:58:43  * wolfeidaujoined
23:01:54  * saghulquit (Ping timeout: 264 seconds)
23:11:55  * dscape_quit (*.net *.split)
23:11:55  * joclekquit (*.net *.split)
23:12:40  * dscape_joined
23:12:40  * joclekjoined
23:13:25  * kenperkinsjoined
23:13:34  <kenperkins>indutny around?
23:15:26  * defunctzombie_zzchanged nick to defunctzombie
23:31:48  * stagasquit (Read error: Connection reset by peer)
23:34:20  * indexzeroquit (Quit: indexzero)
23:40:28  * kazuponjoined
23:45:11  * kazuponquit (Ping timeout: 252 seconds)
23:55:41  <tjfontaine>I need to rerun this, most of net and http have incosequential differences with osx+libumem but checkout out http-cluster bench with it https://gist.github.com/tjfontaine/5439628