00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:02  <isaacs>trevnorris: dunno
00:00:08  * ircretaryjoined
00:00:15  <trevnorris>isaacs: docs don't mention it, oh well
00:00:22  <isaacs>trevnorris: probably vestigial
00:00:26  <isaacs>trevnorris: you can lop it off
00:00:47  <trevnorris>ooh, cool word
00:00:51  <tjfontaine>its poor tail :/
00:01:02  <isaacs>yeah, "lop" is one of my favorites
00:01:04  <isaacs>;)
00:01:15  <trevnorris>hah
00:02:24  * st_lukequit (Remote host closed the connection)
00:02:54  <MI6>libuv-master-gyp: #95 UNSTABLE windows-x64 (3/192) smartos-ia32 (4/191) smartos-x64 (2/191) windows-ia32 (4/192) osx-x64 (1/192) linux-ia32 (2/191) http://jenkins.nodejs.org/job/libuv-master-gyp/95/
00:02:58  <isaacs>omg, OutgoingMessage is such a fucking nightmare.
00:03:04  <isaacs>it seems so simple at first :)
00:03:34  <othiym23>it does?
00:03:48  <isaacs>yah, i mean, what's teh big deal?
00:03:55  <othiym23>anytime I run into IncomingMessage or OutgoingMessage in the debugger, I know I'm in for a head-scraching time
00:03:57  <isaacs>chunked encoding is pretty easy
00:04:08  <isaacs>you just have to juggle some headers, and then write them first.
00:04:16  <isaacs>but then like, end() has to send the trailers first..
00:04:21  <othiym23>heh heh
00:04:22  <othiym23>heh
00:04:26  <isaacs>and cb's have to be managed.
00:04:28  <isaacs>ugh
00:04:37  <tjfontaine>are you making it a transform?
00:05:04  <isaacs>tjfontaine: yeah... i'm not sure about that
00:05:04  <tjfontaine>when you suggested it it seemed like a reasonable pattern
00:05:04  <othiym23>yeah, someday I need to add end-user monitoring to the New Relic agent, which basically involves jamming bits of JavaScript and HTML into HTML pages as they go out
00:05:09  <isaacs>tjfontaine: yeah
00:05:16  <isaacs>tjfontaine: i might, just because it'd be a lot simpler to do
00:05:27  <tjfontaine>nod
00:05:29  <isaacs>tjfontaine: but, here's the rub:
00:05:36  <othiym23>the other language agents at New Relic do it transparently (without the user modifying their templates), but every time I think about how to do that in Node I break out in hives
00:05:38  <isaacs>you don't know how to pipe() it to the socket, until the headers are set!
00:05:47  <tjfontaine>blarg
00:06:00  <isaacs>tjfontaine: because, it *shouldn't8 close teh socket on end(), unless connection:close was set, or unless connection:keep-alive is for some reason impossible.
00:06:24  <tjfontaine>right
00:06:45  <tjfontaine>CURSE YOU HTTP
00:06:45  <LOUDBOT>THE COX WHO FAILED TO NOTICE THE BUMP
00:06:47  <isaacs>tjfontaine: and also, that'd basically mean a huge(r) amount of code to move around in Agent and ClientRequest
00:06:52  <tjfontaine>right
00:07:08  <tjfontaine>LOUDBOT: SEARCH HTTP
00:07:08  <LOUDBOT>tjfontaine: <HighBit:##turtles> SYNTAX ERROR: UNEXPECTED END OF FILE HTTP://TINYURL.COM/BASHCAPS
00:07:12  <MI6>nodejs-master: #397 UNSTABLE smartos-ia32 (2/622) smartos-x64 (10/622) linux-ia32 (2/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/397/
00:10:29  <isaacs>the frustrating thing is that, once i get this actually working, i'm pretty sure it's going to be measurably faster.
00:10:37  <isaacs>but right now, the engine is in pieces in the garage.
00:10:49  <tjfontaine>right
00:10:57  <tjfontaine>rebuilding the carb
00:11:19  <tjfontaine>or the crankshaft, if we want to be all v8 about it
00:15:13  <isaacs>hahah
00:15:21  <isaacs>tjfontaine: you know much more about cars than me;
00:15:37  <isaacs>tjfontaine: "engines are sometimes taken apart in garages" is about as far as i go
00:15:42  <tjfontaine>:)
00:17:33  <tjfontaine>isaacs: my dad was a mechanic for 25 years of his life, and his dad owned dealerships etc etc
00:18:17  <tjfontaine>in highschool I tried to do college prep *and* auto mechanic vocational program, but that was frowned upon
00:18:42  * dshaw_joined
00:26:01  * EhevuTov_quit (Quit: This computer has gone to sleep)
00:29:58  * wolfeidaujoined
00:30:38  * amartensquit (Quit: Leaving.)
00:32:40  * wolfeidauquit (Remote host closed the connection)
00:32:46  <isaacs>so, i'm thinking that _flush(cb) should really be on Writable rather than on Transform
00:32:56  <isaacs>that's really what i'm trying to get at with OutgoingMessage.
00:33:13  <tjfontaine>hm right
00:34:15  <MI6>nodejs-master-windows: #197 UNSTABLE windows-x64 (25/622) windows-ia32 (23/622) http://jenkins.nodejs.org/job/nodejs-master-windows/197/
00:35:22  * dshaw_quit (Quit: Leaving.)
00:35:37  <isaacs>also, i'm reading the existing code, and i don't see where you'd ever have a case where this.socket._httpMessage !== this
00:35:45  <isaacs>there's code there to support it
00:36:05  <isaacs>but we dont' actually create the OutgoingMessage and assign it to a socket until we're actually parsing it
00:36:07  * jmar777joined
00:39:15  * AvianFlujoined
00:40:06  * wolfeidaujoined
00:40:11  <isaacs>in other words, this causes zero tests to fail: https://gist.github.com/isaacs/6198463
00:40:40  <isaacs>i think that's a result of the pipelining handling code that *used* to exist in the http.Client implementation
00:40:55  <tjfontaine>right, I was going to say, it probably existed for *some* reason :)
00:44:12  <isaacs>oh, noo... i think if ound it
00:55:14  * dapquit (Quit: Leaving.)
00:57:13  * wolfeidauquit (Ping timeout: 246 seconds)
00:57:54  * kenperkinsjoined
00:58:38  <isaacs>aha, yeah, found it
01:05:18  * sblomquit (Ping timeout: 264 seconds)
01:05:39  <isaacs>tjfontaine: but yeah, most of the places we test for socket._httpMessage == this are completely irrelevant
01:06:07  * wolfeidaujoined
01:09:29  * bradleymeckjoined
01:18:57  * kenperkinsquit (Quit: Computer has gone to sleep.)
01:24:43  * indexzerojoined
01:25:51  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:34:20  * wolfeidauquit (Remote host closed the connection)
01:57:40  * dshaw_joined
02:00:25  * jmar777quit (Remote host closed the connection)
02:13:30  * dshaw_quit (Ping timeout: 256 seconds)
02:19:41  * dshaw_joined
02:20:56  * dshaw_quit (Read error: Connection reset by peer)
02:21:05  * dshaw_joined
02:25:54  * dshaw_quit (Ping timeout: 264 seconds)
02:25:56  * brsonquit (Ping timeout: 260 seconds)
02:27:30  * brsonjoined
02:41:10  * EhevuTovjoined
02:54:48  <austo>tjfontaine: how about pure reads, like for config objects?
03:11:02  * brsonquit (Quit: leaving)
03:11:35  * brsonjoined
03:17:26  <tjfontaine>austo: reads are also relatively expensive, but not quite as bad as sets, Get on an array is cheaper than Get on an object
03:21:31  * dshaw_joined
03:25:43  * dshaw_quit (Ping timeout: 240 seconds)
03:28:13  * kenperkinsjoined
03:29:49  * inolenjoined
03:36:41  <austo>tjfontaine: good to know. I'm using objects in a few places to avoid writing a js shim, but I'll have another look. thanks.
03:37:02  <tjfontaine>you shouldn't be afraid of the js shim, it's generally the right thing to do
03:37:22  <tjfontaine>do most of your argument checking and validation where the JIT is still of use to you
03:39:18  <austo>then pass everything clean and safe to c++ land?
03:39:50  <tjfontaine>mostly, you shoudl do some light verification that arguments are of the proper type, but the complicated stuff should be done in JS
03:40:05  <tjfontaine>but those should be ASSERTs
03:40:36  <austo>yeah, I've seen that pattern in the node source
03:41:31  * EhevuTovquit (Quit: This computer has gone to sleep)
03:44:12  * wolfeidaujoined
03:46:12  * wolfeidauquit (Read error: Connection reset by peer)
03:49:39  * wolfeidaujoined
03:49:53  * c4milojoined
03:51:31  * brsonquit (Ping timeout: 246 seconds)
03:53:27  * brsonjoined
03:56:13  * austoquit (Remote host closed the connection)
04:00:38  * brsonquit (Ping timeout: 240 seconds)
04:01:21  * dshaw_joined
04:02:43  * brsonjoined
04:02:51  * dshaw_1joined
04:03:01  * dshaw_quit (Read error: Connection reset by peer)
04:04:01  * wolfeidauquit (Remote host closed the connection)
04:04:51  * c4miloquit (Remote host closed the connection)
04:07:05  * dshaw_1quit (Ping timeout: 240 seconds)
04:08:05  * brsonquit (Ping timeout: 248 seconds)
04:08:33  * brsonjoined
04:09:11  * c4milojoined
04:17:04  * dshaw_joined
04:17:54  * kenperkinsquit (Quit: Computer has gone to sleep.)
04:18:26  * dshaw_quit (Read error: Connection reset by peer)
04:18:32  * dshaw_joined
04:21:13  * bradleymeckquit (Quit: bradleymeck)
04:23:48  * dshaw_quit (Ping timeout: 276 seconds)
04:33:26  * stagasjoined
04:39:12  * brsonquit (Quit: leaving)
04:44:01  * dshaw_joined
04:48:06  * julianduquequit (Ping timeout: 264 seconds)
04:59:17  * AvianFlu_joined
05:01:30  * AvianFluquit (Remote host closed the connection)
05:02:32  * abraxasjoined
05:03:02  * inolenquit (Quit: Leaving.)
05:06:46  * abraxasquit (Ping timeout: 240 seconds)
05:32:07  * stagasquit (Ping timeout: 240 seconds)
05:40:21  * stagasjoined
05:46:05  * stagasquit (Read error: Connection reset by peer)
05:46:50  * stagasjoined
05:47:38  * stagasquit (Read error: Connection reset by peer)
05:48:26  * stagasjoined
05:48:34  * AvianFlu_quit (Remote host closed the connection)
05:50:09  * c4miloquit (Remote host closed the connection)
05:51:23  * groundwaterjoined
05:54:02  * dshaw_quit (Quit: Leaving.)
06:08:39  * indexzeroquit (Quit: indexzero)
06:09:20  * paddybyersjoined
06:18:41  * dshaw_joined
06:20:44  * groundwaterquit (Quit: groundwater)
06:25:39  * felixgejoined
06:26:13  * indexzerojoined
06:26:27  * brsonjoined
06:30:29  * dshaw_quit (Quit: Leaving.)
06:35:52  * paddybyersquit (Ping timeout: 264 seconds)
06:40:04  * wolfeidaujoined
06:43:42  * mikealjoined
06:44:09  * mikealquit (Client Quit)
06:44:39  <MI6>nodejs-v0.10-windows: #138 UNSTABLE windows-ia32 (7/594) windows-x64 (7/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/138/
06:44:42  * mikealjoined
06:46:45  * felixgequit (Quit: felixge)
07:01:27  * rendarjoined
07:04:44  * mikealquit (Quit: Leaving.)
07:12:54  * EhevuTovjoined
07:15:42  * hzjoined
07:24:23  * wolfeidauquit (Read error: Connection reset by peer)
07:24:38  * wolfeidaujoined
07:27:59  * wolfeida_joined
07:29:50  * wolfeidauquit (Ping timeout: 240 seconds)
07:31:33  * M28quit (Read error: Connection reset by peer)
07:32:31  * wolfeida_quit (Ping timeout: 240 seconds)
07:32:54  * M28joined
07:34:54  * mikealjoined
07:39:31  * indexzeroquit (Quit: indexzero)
07:42:02  * wolfeidaujoined
07:57:10  * wolfeidauquit (Remote host closed the connection)
08:19:57  * EhevuTovquit (Quit: Leaving)
08:22:24  * brsonquit (Quit: leaving)
08:22:38  * brsonjoined
08:29:24  * txdvjoined
08:41:04  * wolfeidaujoined
08:57:17  * brsonquit (Quit: leaving)
09:03:07  * abraxasjoined
09:07:40  * abraxasquit (Ping timeout: 264 seconds)
09:18:23  * kazuponjoined
09:28:07  * EhevuTovjoined
09:48:00  * wolfeidauquit (Remote host closed the connection)
09:52:41  * wolfeidaujoined
10:03:36  * piscisaureus_joined
10:17:01  * wolfeidauquit (Remote host closed the connection)
10:17:56  * bnoordhuisjoined
10:20:06  * EhevuTovquit (Quit: This computer has gone to sleep)
10:23:23  * wolfeidaujoined
10:27:07  * defunctzombiechanged nick to defunctzombie_zz
10:46:26  <MI6>nodejs-v0.10: #1408 UNSTABLE linux-x64 (2/594) smartos-x64 (1/594) http://jenkins.nodejs.org/job/nodejs-v0.10/1408/
10:56:24  <indutny>hello
10:56:30  * dominictarrjoined
11:07:34  * wolfeidauquit (Remote host closed the connection)
11:15:40  <MI6>joyent/node: Ben Noordhuis master * c75251c : build: don't auto-destroy existing configuration - http://git.io/C8EVpQ
11:15:55  <bnoordhuis>^ that's a long-standing grievance of mine
11:16:00  <bnoordhuis>indutny: sup fedor?
11:16:07  <indutny>nothing
11:16:10  <indutny>just hanging around
11:16:42  * wolfeidaujoined
11:16:47  * kazuponquit (Remote host closed the connection)
11:18:36  <MI6>joyent/node: Ben Noordhuis master * d046e9d : build: make ninja build respect V= - http://git.io/9OcdOA
11:20:38  <indutny>oh, finally
11:24:27  * kazuponjoined
11:25:22  <MI6>nodejs-master: #398 UNSTABLE smartos-ia32 (2/622) smartos-x64 (10/622) linux-ia32 (2/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/398/
11:25:57  * piscisaureus_quit (Read error: No route to host)
11:26:38  * piscisaureus_joined
11:27:06  * wolfeidauquit (Remote host closed the connection)
11:34:59  <MI6>nodejs-master: #399 UNSTABLE smartos-ia32 (2/622) smartos-x64 (8/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (2/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/399/
11:38:24  <MI6>nodejs-master-windows: #198 UNSTABLE windows-x64 (17/622) windows-ia32 (20/622) http://jenkins.nodejs.org/job/nodejs-master-windows/198/
11:39:33  <MI6>joyent/node: Ben Noordhuis master * ab2a668 : configure: order configure switches alphabetically - http://git.io/CgstLg
11:41:38  <MI6>joyent/node: Ben Noordhuis master * 52e47b2 : configure: order configure switches alphabetically - http://git.io/ux79mw
11:41:41  <piscisaureus_>nuttig
11:41:46  <piscisaureus_>o wacht
11:41:54  <bnoordhuis>piscisaureus_: it is
11:42:25  <bnoordhuis>talking about 'nuttig', what have you been up to?
11:43:00  <piscisaureus_>console.error("(node) warning: emitting Resource event '%s' from an unrelated task. You shouldn't do that.", type);
11:44:33  <bnoordhuis>sounds interesting
11:44:34  <bnoordhuis>(not)
11:44:48  <bnoordhuis>in all seriousness, what is it and what's it for?
11:45:30  <piscisaureus_>Resource is the non-evil variation of EventEmitter
11:45:45  <piscisaureus_>however you are no longer supposed to do crazy shit like this
11:45:56  <piscisaureus_>process.stdin.emit('keypress', bla)
11:46:44  <piscisaureus_>because that breaks assumptions (destroyed streams don't emit events, for one)
11:47:00  <piscisaureus_>and, even worse
11:47:30  <piscisaureus_>otherStream.emit('error', new Error('This error really has nothing to do with otherStream but this code was written by a moron.')
11:47:37  <piscisaureus_>);
11:48:23  <bnoordhuis>to start a bikeshed, why call it Resource?
11:48:28  <bnoordhuis>pretty generic name innit?
11:48:48  <MI6>nodejs-master: #400 UNSTABLE smartos-ia32 (3/622) smartos-x64 (10/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (2/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/400/
11:48:49  <piscisaureus_>Because that's the abstraction.
11:48:58  * mikealquit (Ping timeout: 240 seconds)
11:49:34  <piscisaureus_>It's a "thing" that emits events and/or that you can make requests to, which has a beginning and an end
11:49:50  <piscisaureus_>like a file descriptor, a stream, a process
11:50:06  <piscisaureus_>think of it as a uv_handle
11:50:24  <piscisaureus_>but you could roll your own (e.g. a connection pool, a parser object)
11:50:59  <piscisaureus_>The naming can be debated though
11:57:40  * kazuponquit (Remote host closed the connection)
11:58:57  <MI6>nodejs-master: #401 UNSTABLE smartos-ia32 (3/622) smartos-x64 (10/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/401/
12:01:11  <MI6>nodejs-master-windows: #199 UNSTABLE windows-x64 (17/622) windows-ia32 (19/622) http://jenkins.nodejs.org/job/nodejs-master-windows/199/
12:01:27  <piscisaureus_>Do people chain .on() calls in practice?
12:02:06  * dominictarrquit (Quit: dominictarr)
12:02:24  <piscisaureus_>Also, from the docs: "Adds a one time listener for the event. This listener is invoked only the next time the event is fired, after which it is removed."
12:02:28  <piscisaureus_>wrong!
12:02:35  <piscisaureus_>it is removed before it is invoked
12:05:55  * paddybyersjoined
12:06:41  <piscisaureus_>ok, out for lunch. bbl
12:06:52  <piscisaureus_>bnoordhuis: hou het rustug he :)
12:10:46  * paddybyersquit (Ping timeout: 256 seconds)
12:14:08  * mikealjoined
12:18:33  <bnoordhuis>ja jij ook he? :)
12:19:04  * mikealquit (Ping timeout: 264 seconds)
12:19:50  * piscisaureus_quit (Ping timeout: 256 seconds)
12:23:17  <MI6>nodejs-master-windows: #200 UNSTABLE windows-x64 (20/622) windows-ia32 (20/622) http://jenkins.nodejs.org/job/nodejs-master-windows/200/
12:23:19  * bnoordhuisquit (Ping timeout: 264 seconds)
12:29:40  * hzquit
12:39:13  * dominictarrjoined
12:42:21  * heftigjoined
12:43:33  * hueniverse1joined
12:44:08  * txdv_joined
12:50:47  * dominictarrquit (Ping timeout: 260 seconds)
12:50:56  * hueniversequit (Ping timeout: 246 seconds)
12:50:57  * txdvquit (Ping timeout: 246 seconds)
12:55:21  * rendarquit (Ping timeout: 276 seconds)
13:04:23  * bradleymeckjoined
13:08:07  * kazuponjoined
13:13:54  * kazuponquit (Ping timeout: 264 seconds)
13:15:00  * mikealjoined
13:19:20  * mikealquit (Ping timeout: 256 seconds)
13:19:50  * jmar777joined
13:21:38  * bnoordhuisjoined
13:27:49  <MI6>joyent/node: Ben Noordhuis master * c937f5b : build: fix up style issues in configure script - http://git.io/xau6BA
13:29:17  * heftigpart ("Fare ye well")
13:37:06  <MI6>nodejs-master: #402 UNSTABLE smartos-ia32 (2/622) smartos-x64 (9/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (2/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/402/
13:47:36  <MI6>nodejs-master-windows: #201 UNSTABLE windows-x64 (18/622) windows-ia32 (18/622) http://jenkins.nodejs.org/job/nodejs-master-windows/201/
13:51:18  * hzjoined
14:04:38  * piscisaureus_joined
14:05:02  <bnoordhuis>piscisaureus_: have you upgraded yet? vim 7.4 is out
14:05:06  <bnoordhuis>i'm so excited!
14:05:19  * rendarjoined
14:06:16  <piscisaureus_>bnoordhuis: let me guess. They added :jfu8si3 to combile search and replace with capitalization?
14:06:43  <piscisaureus_>turn everything into iNVERSE cAMEL cASE?
14:09:38  <bnoordhuis>that, and the syntax highlighter is now less likely to crap out on big files / long lines
14:10:13  <bnoordhuis>'combile' is an amusing typo
14:10:23  <bnoordhuis>combile: to combine in a bile-inducing way
14:15:27  * mikealjoined
14:19:43  * mikealquit (Ping timeout: 240 seconds)
14:23:59  * AvianFlujoined
14:26:41  <MI6>joyent/node: Ben Noordhuis master * 39aa894 : build: disable SSLv2 by default - http://git.io/N_tMHg
14:36:00  <MI6>nodejs-master: #403 UNSTABLE smartos-ia32 (3/622) smartos-x64 (9/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/403/
14:36:41  <MI6>joyent/node: Ben Noordhuis master * a20d565 : v8: fix openbsd build (+1 more commits) - http://git.io/vNfp9Q
14:36:47  <bnoordhuis>eternal handles, yay!
14:37:11  <bnoordhuis>you may have to do a `make distclean && ./configure && make` after upgrading
14:37:45  * bnoordhuissteps back from the keyboard
14:42:04  * bnoordhuisquit (Ping timeout: 241 seconds)
14:44:12  * kazuponjoined
14:46:05  <MI6>nodejs-master: #404 UNSTABLE smartos-ia32 (4/622) smartos-x64 (10/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/404/
14:46:29  <MI6>nodejs-master-windows: #202 UNSTABLE windows-x64 (20/622) windows-ia32 (21/622) http://jenkins.nodejs.org/job/nodejs-master-windows/202/
14:54:10  * AvianFluquit (Remote host closed the connection)
14:55:06  * AvianFlujoined
14:59:26  * felixgejoined
14:59:39  * bnoordhuisjoined
15:04:03  * txdv_quit (Ping timeout: 276 seconds)
15:06:50  <MI6>nodejs-master-windows: #203 UNSTABLE windows-x64 (19/622) windows-ia32 (19/622) http://jenkins.nodejs.org/job/nodejs-master-windows/203/
15:07:54  * txdvjoined
15:13:16  * paddybyersjoined
15:16:00  * mikealjoined
15:16:57  <MI6>nodejs-master: #405 UNSTABLE smartos-ia32 (3/622) smartos-x64 (10/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/405/
15:20:55  * mikealquit (Ping timeout: 264 seconds)
15:29:39  * kenperkinsjoined
15:30:27  * c4milojoined
15:36:56  * paddybyersquit (Ping timeout: 260 seconds)
15:43:33  * bnoordhuisquit (Ping timeout: 248 seconds)
15:49:35  * dominictarrjoined
15:55:35  * piscisaureus_quit (Ping timeout: 260 seconds)
16:10:39  * c4miloquit (Remote host closed the connection)
16:10:48  * bradleymeckquit (Quit: bradleymeck)
16:13:46  * jmar777quit (Remote host closed the connection)
16:16:22  * hzquit (Remote host closed the connection)
16:16:42  * hzjoined
16:16:45  * mikealjoined
16:21:13  * c4milojoined
16:28:51  * groundwaterjoined
16:29:08  * hzquit (Remote host closed the connection)
16:30:08  * hzjoined
16:37:10  <isaacs>ircretary: tell piscisaureus_ Yes, people chain on() calls in practice.
16:37:10  <ircretary>isaacs: I'll be sure to tell piscisaureus_
16:38:53  <isaacs>Hm. Writable streams need a way to know when they're writing the last chunk.
16:39:14  * groundwaterquit (Quit: groundwater)
16:43:34  * mikealquit (Quit: Leaving.)
16:46:34  * dominictarrquit (Quit: dominictarr)
16:47:38  * felixgequit (Quit: felixge)
16:48:20  * c4miloquit (Remote host closed the connection)
16:49:54  * bnoordhuisjoined
16:53:55  * hzquit (Ping timeout: 264 seconds)
16:54:07  * bnoordhuisquit (Ping timeout: 246 seconds)
16:56:24  * groundwaterjoined
17:10:27  * kazuponquit (Remote host closed the connection)
17:10:29  * c4milojoined
17:15:00  * toothrchanged nick to toothrot
17:21:18  * defunctzombie_zzchanged nick to defunctzombie
17:21:43  * groundwaterquit (Quit: groundwater)
17:22:27  * Somebodyjoined
17:25:55  * kazuponjoined
17:44:31  * mikealjoined
17:49:06  * indexzerojoined
17:53:34  <MI6>libuv-master: #156 FAILURE windows (4/192) http://jenkins.nodejs.org/job/libuv-master/156/
18:04:39  * mikealquit (Quit: Leaving.)
18:04:54  * mikealjoined
18:07:29  * kazuponquit (Remote host closed the connection)
18:11:12  * udpjoined
18:29:27  * mikealquit (Quit: Leaving.)
18:31:05  * mikealjoined
18:32:08  * mikealquit (Client Quit)
18:35:11  * stagasquit (Ping timeout: 241 seconds)
18:36:40  * stagasjoined
18:41:07  * stagasquit (Remote host closed the connection)
18:41:35  * stagasjoined
18:45:49  <MI6>nodejs-master-windows: #204 UNSTABLE windows-x64 (21/622) windows-ia32 (18/622) http://jenkins.nodejs.org/job/nodejs-master-windows/204/
18:53:26  * Somebodyquit (Remote host closed the connection)
19:02:21  * mikealjoined
19:10:06  * bnoordhuisjoined
19:17:55  * kazuponjoined
19:22:14  * kazuponquit (Ping timeout: 240 seconds)
19:23:42  * kazuponjoined
19:25:52  * piscisaureus_joined
19:28:53  * mikealquit (Quit: Leaving.)
19:29:30  * kazuponquit (Ping timeout: 264 seconds)
19:34:02  * dominictarrjoined
19:36:05  <kellabyte>bnoordhuis: what the heck does this mean? I'm getting a broken pipe in libuv https://gist.github.com/kellabyte/6201825/raw/cd96404cece462ec07437ffce3e6035c5b78c54b/sigpipe.txt
19:39:23  <bnoordhuis>kellabyte: welcome to the wonderful world of unix signals!
19:40:01  <bnoordhuis>kellabyte: it's easy to fix, just install a SIG_IGN SIGPIPE handler with sigaction()
19:41:42  <kellabyte>bnoordhuis: yeah, so in my C lib that uses libuv I had signal(SIGPIPE, SIG_IGN); which works in C apps using it
19:41:58  <kellabyte>bnoordhuis: but when a C++ app uses my C lib (that uses libuv) it seems to sigpipe again
19:43:39  <bnoordhuis>kellabyte: then it's either not installing the SIG_IGN handler or something else is resetting it to SIG_DFL again
19:44:03  <kellabyte>hrm
19:44:05  <bnoordhuis>btw, sigaction > signal
19:44:16  <kellabyte>so sigaction is better?
19:44:20  <bnoordhuis>yeah
19:44:42  <bnoordhuis>the semantics of using sigaction() and signal() in the same program is only weakly defined on unices
19:44:53  <bnoordhuis>and signal() is considered effectively deprecated
19:44:57  <bnoordhuis>ergo, sigaction() is better
19:45:19  <kellabyte>I wish I didn't have to care about this lol
19:45:28  <bnoordhuis>maybe i should say 'superseded' rather than 'deprecated', it's not like it's ever going away
19:45:51  <bnoordhuis>in 500 years, we'll be flying spaceships to faraway galaxies
19:46:04  <bnoordhuis>and still we'll have to worry about the interaction of sigaction() and signal()
19:46:12  <bnoordhuis>i'll leave you with that thought
19:46:14  * dominictarrquit (Ping timeout: 240 seconds)
19:47:42  <kellabyte>lol
19:47:58  <kellabyte>erm still seems to happen
19:48:13  <bnoordhuis>kellabyte: in gdb, you mean?
19:48:25  <kellabyte>yeah
19:48:40  <bnoordhuis>'help handle' - gdb by default stops on signals
19:48:58  <bnoordhuis>it doesn't actually mean something's wrong
19:49:01  <kellabyte>oh
19:50:36  <kellabyte>bnoordhuis: is this the proper way to ignore it using sigaction? https://github.com/ErikDubbelboer/libuv-lua-http-server/blob/master/main.c#L426
19:52:19  <bnoordhuis>kellabyte: yeah. sigfillset(&sa.sa_mask) is kind of pointless when you're ignoring the signal anyway but it doesn't harm either
19:53:33  <kellabyte>ok, I was trying to track down why this app fails on linux but works fine on osx, I saw that and started chasing it
19:53:43  <kellabyte>so that's a gdb thing, gotcha, thanks :)
19:54:09  <mordy__>signal(SIGPIPE, SIG_IGN) is one of the annoying boilerplate stuff an application must do
19:54:34  <mordy__>and while almost nobody wants SIGPIPE, it's bad practice for a library to secretly manipulate signal handlers
19:55:33  * piscisaureus_quit (Ping timeout: 240 seconds)
19:56:27  <mordy__>though you normally don't get SIGPIPE with nonblocking I/O
19:56:42  <mordy__>(i guess it's theoretically possible?
19:56:47  <kellabyte>mordy__: I can reproduce it really easily
19:57:17  <kellabyte>point Wrk at it and a few seconds after the benchmark finishes, sigpipe
19:58:07  <mordy__>hrm
19:58:31  <mordy__>so my event loop is seemingly stuck somewhere.. is there something i can call/inspect from within gdb to figure out what's happening?
19:58:31  <bnoordhuis>mordy__: it's possible to suppress SIGPIPE
19:58:48  <bnoordhuis>with sendmsg(), to be precise
19:59:00  <bnoordhuis>but sendmsg() is usually a lot slower than write()
19:59:05  <bnoordhuis>hence libuv doesn't use it
19:59:07  <mordy__>MSG_NOSIGNAL
19:59:10  <bnoordhuis>yep
19:59:35  <mordy__>but sendmsg is the only way to send iov buffers
19:59:50  <bnoordhuis>mordy__: as to your question, you can call uv__print_handles() in gdb, it prints out the current handles
19:59:59  <mordy__>ah hrm
20:00:02  * mordy__tries that
20:00:17  <bnoordhuis>yeah. we only use sendmsg() when a) sending file descriptors, or b) sending multiple buffers at once
20:00:18  <mordy__>bnoordhuis: that makes me wonder.. in our library we're using sendmsg with an iov[2]
20:00:28  <mordy__>would individual writes be quicker?
20:00:32  <bnoordhuis>probably
20:00:35  <bnoordhuis>depends on the platform
20:00:43  <mordy__>hrm, i should try that
20:00:57  <kellabyte>glad my pain helped someone :P
20:00:59  <bnoordhuis>when i last benchmarked it on linux, for example, the cutoff point was around 8 iovecs
20:01:12  <mordy__>that may explain why UV has been quicker here
20:01:23  <bnoordhuis>size of the data also matters, of course
20:02:06  <bnoordhuis>if you're sending two iovecs that point to lots of data, the cost of copying the iovecs dwarves in comparison to everything else
20:02:07  <mordy__>bnoordhuis: i'd imagine that once the buffers get big enough the overhead would cease to be in the sendmsg/write and start to be in the actual copying
20:02:15  <bnoordhuis>exactly :)
20:02:55  <bnoordhuis>btw, you can trace write() vs. sendmsg() with a tool like perf
20:03:19  <mordy__>let me see what we do in windows...
20:03:20  <bnoordhuis>it's interesting to see that both are wrappers around the same machinery, but the sendmsg() code path is slightly longer
20:03:24  * piscisaureus_joined
20:03:46  <bnoordhuis>also, sendmsg() has to inspect the msghdr, of course
20:04:03  <mordy__>ahh i was gonna mention that
20:04:15  <mordy__>which contains a lot of crap folks don't normally use
20:04:21  <bnoordhuis>yep
20:04:44  <mordy__>windows sorta does it right
20:05:10  <mordy__>WSASend lets you pass WSABUF structures directly
20:06:05  <bnoordhuis>oh? it's like a sendmsg() that takes iovecs rather than a msghdr?
20:06:11  <mordy__>yes
20:06:27  <bnoordhuis>can you tell i'm a windows newb? it's a good thing we have piscisaureus_ :)
20:06:48  <mordy__>WSASend(sock, buffers, nbuffers, &nsent, flags, overlapped, something_else)
20:06:53  <mordy__>i'm not sure what the last param is
20:07:12  <piscisaureus_>APC calback
20:07:18  <piscisaureus_>ok, i'm outta here
20:07:23  * piscisaureus_quit (Client Quit)
20:10:32  <mordy__>hrm; http://paste.scsys.co.uk/265359
20:10:42  <mordy__>now i need to figure out what all those letters mean
20:11:59  * udpquit (Quit: udp)
20:12:10  <bnoordhuis>mordy__: R=ref'd, A=active, I=internal (i.e. not created by you)
20:14:05  <mordy__>and 'R' means keeping the event loop alive?
20:14:14  <bnoordhuis>yep
20:18:43  <mordy__>hrrm.. so let me get this clear.. i don't care about 'I', 'R' means something that isn't doing I/O but isn't close,d and 'A' means waiting for I/O
20:19:14  <bnoordhuis>yes, no and no
20:19:35  <bnoordhuis>well, the third one could be either yes or no, depending on how you look at it
20:20:04  <bnoordhuis>R means 'the event loop won't quit as long as this handle is open'
20:20:24  <bnoordhuis>I/O isn't necessarily involved, c.f. timers and check/prepare handles
20:20:56  <bnoordhuis>oh, i should've added 'when the handle is active'
20:21:02  <bnoordhuis>because that's what A means, of course :)
20:21:19  <bnoordhuis>is that still making sense?
20:22:51  <bnoordhuis>you can unref a handle with uv_unref(), in which case it won't stop the event loop from exiting, even when it's active
20:24:27  <mordy__>hrm... i'm still trying to figure out what 'R-' is vs 'RA'. what would be the point of a handle keeping the event loop alive if it doesn't have any registered events? (timer expiration, check/prepare, socket i/o, or otherwise)
20:25:41  <bnoordhuis>sorry, i didn't put that clearly
20:26:04  <bnoordhuis>R means 'keeps the event loop alive when _active_' (what A stands for)
20:26:08  * c4miloquit (Remote host closed the connection)
20:26:31  <mordy__>AHA
20:26:49  <bnoordhuis>just R- means ref'd but not currently active. if that's the last handle, the event loop would exit
20:30:38  <mordy__>hrm; does 'tcp' here mean connect and reads? or does it also imply writes? (though i think that's a different handle)
20:32:02  <bnoordhuis>mordy__: both
20:32:04  <bnoordhuis>trevnorris: ping
20:33:38  * EhevuTovjoined
20:37:30  <mordy__>hrm, i wonder what to make of this thing http://paste.scsys.co.uk/265360
20:38:42  <mordy__>judging by the prev and next pointers, it seems this is the only item in the list
20:42:45  <bnoordhuis>mordy__: what prev/next pointers? the handle_queue's or the io_watcher's pending_queue/watcher_queue?
20:43:56  * joshthecoderquit (Quit: IRCRelay - http://ircrelay.com)
20:44:08  * joshthecoderjoined
20:44:15  <mordy__>the latter; the handle itself is 0x7d8e08
20:44:44  <mordy__>hrm, i wonder what the watcher_queue is
20:46:00  <mordy__>hrm wait
20:46:15  <mordy__>watcher_queue->next/prev point to the structure's ->data field
20:46:55  <bnoordhuis>the watcher_queue is what libuv uses when it needs to update the event mask with epoll_ctl() before calling epoll_wait()
20:46:57  <mordy__>oh no, not ->data
20:47:06  <bnoordhuis>iow, you probably shouldn't worry about it :)
20:47:33  <mordy__>and what's the handle queue?
20:48:39  <bnoordhuis>mordy__: the list of all open handles, active or not
20:48:51  <bnoordhuis>mordy__: when you call uv__print_handles(), that's the list it walks
20:51:21  <mordy__>[R--] tcp 0x7d8e08
20:52:21  <mordy__>so that says it's not active. the internal fd field also says that there's no FD
20:52:28  <mordy__>let me see if i'm out of FDs actually..
20:52:35  <mordy__>since this only seems to happen well into my test run
20:52:49  <mordy__>maybe ENFILE or something
20:53:34  <mordy__>hrm.. indeed
20:53:35  <mordy__>ENFILE
20:54:07  <mordy__>and i apparently have a ton of these active: unit-test 26705 mnunberg 930r FIFO 0,8 0t0 69081478 pipe
20:58:08  * c4milojoined
21:00:04  <mordy__>i know i'm calling uv_loop_delete on the loop
21:01:57  * mordy__really needs a portable way of specifying 'checkreturn' or similar
21:04:30  * mikealjoined
21:06:04  * mikealquit (Client Quit)
21:08:27  <bnoordhuis>../../src/pipe_wrap.cc:126: error: invalid use of member (did you forget the ‘&’ ?)
21:08:30  <bnoordhuis>../../src/pipe_wrap.cc:126: error: base operand of ‘->’ is not a pointer
21:08:35  <bnoordhuis>sometimes c++ is so fscking stupid
21:09:04  <bnoordhuis>that's basically ptr->foo().bar() where foo() returns a Foo&
21:12:28  <kellabyte>bnoordhuis: that multi-accept test really hurts my head. any chance some day that could become a simpler concept? lol
21:13:50  <mordy__>i think it's about time the world move from TCP to something designed for scalability
21:13:54  <mordy__>TCP sucks
21:19:45  * stagasquit (Ping timeout: 276 seconds)
21:22:37  * groundwaterjoined
21:29:23  <bnoordhuis>kellabyte: what part (or parts) are unclear?
21:29:36  <bnoordhuis>i admit it's a somewhat complex benchmark, as benchmarks go :)
21:29:56  <kellabyte>bnoordhuis: there's just so much callbacks, having trouble keeping track of what I need to do this on the server side
21:31:46  <bnoordhuis>kellabyte: you want to share handles across threads, right?
21:34:22  <kellabyte>bnoordhuis: I think so, right now all the http parsing is happening on the 1 thread
21:34:56  <bnoordhuis>kellabyte: okay. we went over the basic steps iirc but just in case
21:35:06  <bnoordhuis>you start a pipe server
21:35:34  <bnoordhuis>then you want to spin up your worker threads and have them connect to the pipe server
21:36:27  <bnoordhuis>in the same thread as the pipe server, you start your tcp server
21:36:43  <bnoordhuis>when a connection comes in, you accept it and send it to one of the workers with uv_write2()
21:37:22  <bnoordhuis>the workers should wait for incoming data with uv_read2_start()
21:37:39  <bnoordhuis>when you send over a handle, the worker's read2_cb gets invoked
21:37:59  <bnoordhuis>third argument is the handle type (should always be UV_TCP in your case)
21:38:38  <bnoordhuis>call uv_accept() to accept the new handle
21:38:48  <bnoordhuis>that's about it, really
21:39:00  <kellabyte>ah, then from there on I can do reads on the socket?
21:39:07  <bnoordhuis>yep
21:39:27  * groundwaterquit (Quit: groundwater)
21:39:33  <kellabyte>I can write the response from that thread too?
21:39:53  <bnoordhuis>well, your workers eac have their own event loop
21:39:55  <bnoordhuis>*each
21:40:04  <bnoordhuis>they should create it with uv_loop_new()
21:40:25  * groundwaterjoined
21:40:30  <kellabyte>ok, so as soon as the hand off has been done by the pipe, you're basically good to go with anything?
21:40:43  <bnoordhuis>yeah
21:40:56  <bnoordhuis>the handle that's received by the worker becomes part of the worker's event loop
21:41:14  <bnoordhuis>let me check one thing though
21:43:39  <bnoordhuis>yeah, works the same on windows
21:44:01  <bnoordhuis>just make sure you create your pipe handles with uv_pipe_init(loop, handle, 1 /* ipc-enabled */)
21:44:05  <bnoordhuis>kellabyte: ^
21:46:03  <bnoordhuis>we could perhaps make things a little easier for in-process handle sharing
21:46:04  <kellabyte>bnoordhuis: like here? https://github.com/joyent/libuv/blob/master/test/benchmark-multi-accept.c#L119
21:46:11  <kellabyte>bnoordhuis: that would totally rock :)
21:46:23  <bnoordhuis>then again, the upside is that this way you get multi-process support almost for free
21:46:41  <bnoordhuis>kellabyte: yep, like that
21:46:50  <kellabyte>bnoordhuis: it would be cool if there was a construct just to make this simpler IMO
21:47:00  <kellabyte>bnoordhuis: like you can still do it the manual way if you need more control
21:49:09  <bnoordhuis>yeah, i don't entirely disagree
21:49:20  <bnoordhuis>you can file a feature request if you like
21:49:52  <bnoordhuis>that said, it's not something we need ourselves so don't expect it to get implemented right away :)
21:50:49  <kellabyte>no problem, if you think filing a feature request will help I can do that!
21:52:08  <kellabyte>I'll give that approach a try though in a few hours when I get back from elysium
21:52:48  <mordy__>hrrm.. uv_timer_start(timer, callback, 0, 0) -- i'd expect that to fire pretty much when control is returned back to the loop
21:53:36  <bnoordhuis>mordy__: what happens?
21:53:53  <bnoordhuis>oh, you mean when you return from a callback?
21:54:34  <mordy__>yep. but considering i'm being ENFILE'd here, i guess things are subject to breakage
21:55:16  <mordy__>well.. nothing happens.. guess i should check the return from uv_timer_start
21:55:22  <mordy__>see if it returns anything meaningful
21:56:51  <bnoordhuis>mordy__: timers don't run until the next tick of the event loop
21:57:20  <bnoordhuis>i.e. if you start a zero timeout timer from a check callback, you can still expect i/o callbacks first before the timer fires
21:58:25  <mordy__>bnoordhuis: but this isn't true for uv_idle, is it?
21:58:48  <mordy__>let me try wiht an 'idle'
21:59:58  <bnoordhuis>mordy__: idle callbacks run after timers (but before check, i/o and prepare callbacks)
22:00:24  <bnoordhuis>oh, when i said 'check callback' back there, i meant 'prepare callback'
22:00:38  <bnoordhuis>the one that runs _before_ polling for new i/o
22:03:20  <mordy__>any idea about those pipes though?
22:03:27  <mordy__>that's what's causing the ENFILE
22:03:43  <bnoordhuis>ENFILE or EMFILE?
22:03:59  <bnoordhuis>ENFILE means you're hitting the system-wide file descriptor limit
22:04:33  <mordy__>oh right, EMFILE
22:04:50  <mordy__>i don't know the exact errno offhand; but i gleaned that's what was happening from lsof
22:05:37  <bnoordhuis>mordy__: try stracing it, that should give you some insight
22:06:05  <bnoordhuis>i mean, insight into whether you're actually hitting the fd limit
22:07:24  * indexzeroquit (Quit: indexzero)
22:07:34  <mordy__>socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = -1 EMFILE (Too many open files)
22:07:38  <mordy__>:)
22:07:43  <bnoordhuis>yep, okay
22:07:58  <bnoordhuis>the simple answer is 'raise ulimit -n'
22:08:06  <bnoordhuis>libuv has some EMFILE/ENFILE protection built in btw
22:08:10  <mordy__>bnoordhuis: well, i've actually lowered it because there's an fd leak
22:08:23  <mordy__>so i'm lowering it so i don't need to wait a million years before it hits :)
22:08:49  <bnoordhuis>it stashes away a fd and when it hits the limit when accepting new connections, it closes the fd, accepts the connection and immediately closes it
22:09:12  <bnoordhuis>but that's only when accepting connection so consider the above a fyi :)
22:09:36  <mordy__>yeah; i'm a client application - the most sockets i'd expect to have open is about 50-100
22:09:37  <bnoordhuis>if you hit EMFILE anywhere else, it's game over. libuv will return an error and that's that
22:10:12  <mordy__>my fd table is flooded with pipes
22:10:19  <mordy__>i just don't know where they're coming from
22:11:37  <mordy__>oddly enough, strace -e socket,pipe,socketpair isn't showing anything interesting
22:12:25  <mordy__>but i know the sockets are being cleaned up properly
22:12:25  <MI6>joyent/node: Ben Noordhuis master * 2b5b37a : stream_wrap: use v8::Integer::NewFromUnsigned() - http://git.io/BLhwYg
22:12:58  <mordy__>i wish strace had a feature to say "tell me when something opens an fd"
22:13:03  <mordy__>(maybe it does, let me read the docs..)
22:13:13  <bnoordhuis>mordy__: is your program using threads? in that case you want to add -f (trace children)
22:13:40  <mordy__>bnoordhuis: thankfully no, and certainly no -- one of the children is java :)
22:16:35  <mordy__>pipe2([80, 81], O_CLOEXEC) = 0
22:16:57  <mordy__>hrm, i wonder if gdb can break.. but no, there's some crap about it not being able to break on syscalls.. it needs some other voodo
22:17:00  * mordy__tries
22:17:14  <bnoordhuis>mordy__: you can break on the glibc wrapper
22:17:33  <bnoordhuis>though with pipe2 you probably need to break on syscall()
22:17:48  <bnoordhuis>(libuv has a few syscall wrappers of its own)
22:18:06  * mikealjoined
22:18:31  <bnoordhuis>mordy__: or try setting a breakpoint on uv__pipe2
22:18:43  <bnoordhuis>that's the pipe2 syscall wrapper
22:20:32  <mordy__>http://paste.scsys.co.uk/265361
22:20:38  * mordy__should've compiled with -g
22:21:00  * wolfeidaujoined
22:21:44  <MI6>nodejs-master: #406 UNSTABLE smartos-ia32 (2/622) smartos-x64 (10/622) linux-ia32 (1/622) osx-x64 (1/622) osx-ia32 (1/622) linux-x64 (2/622) http://jenkins.nodejs.org/job/nodejs-master/406/
22:22:10  <mordy__>i *am* calling uv_loop_delete when done (and i have a printf right before i call it, so i *know* it's actually being called..)
22:22:32  <bnoordhuis>mordy__: is that the only stack trace?
22:22:40  <mordy__>that's the first one i get
22:22:56  <bnoordhuis>c :)
22:23:28  <mordy__>bleh.. let me compile with -g
22:23:35  <mordy__>i have the source for everything
22:23:46  * c4miloquit (Remote host closed the connection)
22:24:41  <mordy__>maybe i'm missing out some proper linker flags, too
22:25:01  <mordy__>as i've had to compile with make CFLAGS+=-fPIC ...
22:25:12  <mordy__>to get a static lib to embed in my own so
22:28:17  <mordy__>http://paste.scsys.co.uk/265362
22:28:37  <mordy__>there's probably a clever way to tell gdb "print backtrace here and continue"
22:30:14  <mordy__>let me see what ldd says
22:30:19  <mordy__>this might be an issue on my part
22:32:02  <mordy__>hrm wait
22:32:09  <mordy__>the two first backtraces are nearly identical
22:32:13  * wolfeidauquit (Remote host closed the connection)
22:32:18  <mordy__>with the exception that the second one doesn't go through pthread_once !?
22:35:13  <MI6>nodejs-master-windows: #205 UNSTABLE windows-x64 (19/622) windows-ia32 (19/622) http://jenkins.nodejs.org/job/nodejs-master-windows/205/
22:35:29  <mordy__>hrm no, wait.. this makes little sense
22:35:31  <mordy__>let me see unix.c
22:35:37  <mordy__>err.. signla.c
22:35:49  * rendarquit
22:35:50  * mikealquit (Quit: Leaving.)
22:38:33  <mordy__>bnoordhuis: ahh i see what's happening
22:38:45  <mordy__>this is technically your bug though a minor one
22:39:11  <mordy__>because the library is created via dlopen and unloaded via dlclose, the global init stuff is executed multiple times during an application run
22:40:54  <mordy__>why don't you use stuff like __attribute__((constructor)) and whatever's equivalent on other platforms?
22:42:07  * indexzerojoined
22:42:07  <bnoordhuis>mordy__: you mean it keeps creating the signal pipe again and again?
22:42:17  <mordy__>yep
22:42:28  <mordy__>bnoordhuis: which is normal. the problem is that it's not closing it on unload
22:42:39  <bnoordhuis>right
22:42:49  <mordy__>patch time?
22:42:54  <bnoordhuis>yeah :)
22:43:04  <bnoordhuis>or you can file an issue if you want
22:43:30  <mordy__>hrm, i remember the last patch i submitted i had to do some kind of CLA and i forgot about it and stuff
22:43:35  <bnoordhuis>should be trivial to fix but i'll need to go over the code to check for unforeseen consequences
22:43:37  <mordy__>do i need to fax something over or something?
22:43:47  <bnoordhuis>no, you can just sign the web form
22:43:50  <mordy__>oh ok
22:43:59  <bnoordhuis>http://nodejs.org/cla.html <- that one
22:44:32  <bnoordhuis>you will be signing away your firstborn
22:44:41  <bnoordhuis>but don't let that worry you, you can always make more
22:45:34  <bnoordhuis>(i kid, kid. the only thing it says is that you have the legal authority to submit the patch)
22:45:46  <mordy__>we have CLAs for our own projects i believe
22:46:18  <bnoordhuis>yeah. most projects have these days
22:46:55  <bnoordhuis>it bothers me a little that we have one
22:47:01  <bnoordhuis>but well, what can you do?
22:48:26  <mordy__>luckily most of the legal stuff doesn't get in the way of my doing software.. effectively for me it effectively means "As long as it's MIT/Apache licensed, we're good" -- though i do need to ask for approval whenever including/depending on some other project
22:49:10  <mordy__>hrm, i think one of my colleagues already has a contribution to libuv
22:49:26  <mordy__>oh wait, it wasn't libuv, it was http-parser
23:03:03  * wolfeidaujoined
23:05:18  * AvianFluquit (Remote host closed the connection)
23:14:43  * EhevuTovquit (Quit: This computer has gone to sleep)
23:16:31  * jmar777joined
23:24:06  * groundwaterquit (Quit: groundwater)
23:26:11  <mordy__>hrm there. that fixes it, i think
23:33:40  * wolfeida_joined
23:34:14  * wolfeidauquit (Ping timeout: 240 seconds)
23:35:28  <bnoordhuis>http://showterm.io/ - looks sweet
23:36:29  * c4milojoined
23:38:55  * wolfeida_quit (Ping timeout: 264 seconds)
23:40:14  * amartensjoined
23:41:53  <mordy__>hrm; is there a way to get the actual FD (API-wise)
23:42:02  <mordy__>would be nice to be able ot set socket options etc.
23:42:28  <mordy__>though it's understandable why that functionality would be opaque.. ahh i see you already have a nagle on/off API
23:45:01  * felixgejoined
23:46:34  * wolfeidaujoined
23:48:12  * amartensquit (Quit: Leaving.)
23:52:04  * wolfeidauquit (Ping timeout: 264 seconds)
23:55:55  * wolfeidaujoined
23:57:49  * felixgequit (Quit: felixge)