00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:13  <piscisaureus_>hahaha
00:00:44  <piscisaureus_>isaacs: now try this: require('fs').writeFileSync('bla.', 'bla');
00:00:52  <piscisaureus_>and try to delete the file afterwards without node
00:00:55  <piscisaureus_>good luck my friend
00:00:58  <isaacs>hahah
00:01:01  <isaacs>piscisaureus_: nice try!
00:01:07  <isaacs>piscisaureus_: i'm wise to your shenanigans!
00:01:28  <piscisaureus_>I think unlocker solves this problem too btw
00:06:21  * roxluquit (Remote host closed the connection)
00:06:22  * EhevuTov__quit (Quit: Leaving)
00:07:08  <piscisaureus_>ok, tired, gone
00:07:19  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:08:16  <isaacs>g'nite
00:13:26  * indexzeroquit (Quit: indexzero)
00:17:09  <isaacs>sblom: so, speaking of that... do you knwo what this means? https://gist.github.com/4323690
00:17:30  <isaacs>sblom: i also can't delete it i cmd as administrator
00:17:52  <isaacs>sblom: is there a way to figure out what has the file open, and kill it?
00:18:44  <isaacs>(also can't delete in Explorer)
00:19:06  <isaacs>no programs open...
00:19:09  <isaacs>(restarting)
00:20:04  <CoverSlide>i usually install sysinternals on every windows machine i can
00:20:16  <sblom>isaacs: The tool that I usually use to find who has the file open is sysinternals ProcExp.exe
00:20:47  <sblom>http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
00:21:08  <CoverSlide>it's like required
00:21:10  <sblom>isaacs: and then on the Handle menu, you have an option to search for who has a handle open to the file.
00:21:21  <isaacs>i see
00:21:27  <isaacs>i just restarted the vm
00:21:33  <isaacs>that looks like it worked
00:21:40  <sblom>It's like lsof for GUI users. with filesystems that won't let them delete open files.
00:21:55  <isaacs>i try so hard to show respect for windows.
00:22:03  <isaacs>i have mad respect for microsoft.
00:22:12  <isaacs>but like... man... this operating system... i tell ya
00:22:30  <sblom>isaacs: You're not getting me down. There's a bunch of "why can't it just be a normal human being?!" stuff that Windows does. For sure.
00:22:38  <CoverSlide>well there's like a good number of windows 3.1 apps that still run on it
00:22:51  <sblom>CoverSlide: So true
00:22:51  <isaacs>CoverSlide: yeah, i don't think that's worth the cost.
00:23:04  <isaacs>CoverSlide: they should just ship a unix system with vmware for running those things
00:23:12  <CoverSlide>yeah
00:23:16  <isaacs>CoverSlide: those windows 3.1 apps run on OS X also.
00:23:20  <isaacs>we have hardware virtualization now
00:23:22  <CoverSlide>like how they have ntvdm for dos apps
00:23:24  <sblom>isaacs, CoverSlide: See
00:23:25  <isaacs>yeah
00:23:28  <isaacs>it's the future
00:23:31  <sblom>See "Windows XP Mode"
00:23:34  <isaacs>there's no excuse for being like this
00:23:39  <isaacs>exactly
00:25:27  * kazuponjoined
00:28:19  <sblom>isaacs: So looks like ctrpp.exe is, indeed, missing from VS 2010 Express. Two ways to fix this: 1) require anyone who wants to build Node with Perf Ctrs with VS Express to download a recent Windows SDK (which is like a 400MB download) and then change some VS settings, or 2) just check in the generated files and train anyone who changes the Manifest files that they need to check in generated
00:28:19  <sblom>files, too.
00:28:22  <sblom>I'm inclined toward 2.
00:28:58  <sblom>Could add a build step that would check for discrepancies between checked in and generated files during builds by folks who have the full SDK...
00:29:04  <isaacs>sblom: yeah, if #2 will work, then it seems like that's the easier path.
00:29:24  <sblom>That would at least nag, say, me and piscisaureus_ if one of us forgets to update.
00:30:02  * kazuponquit (Ping timeout: 255 seconds)
00:31:11  <isaacs>sure
00:34:03  <sblom>ircretary: tell piscisaureus_ You were totally right. It was, indeed, a VS-Express-can't-build-it kind of thing. I was <blush/> looking at the wrong gist.
00:34:04  <ircretary>sblom: I'll be sure to tell piscisaureus_
00:34:59  <sblom>ircretary: tell piscisaureus_ I'm going to just check in the generated files so that Express users can still build.
00:34:59  <ircretary>sblom: I'll be sure to tell piscisaureus_
00:40:18  * hzquit (Disconnected by services)
00:40:24  * hzjoined
00:47:11  * CoverSlideasks santa for MinGW support
00:49:11  * brson_quit (Quit: leaving)
00:50:59  * loladirojoined
00:54:34  * loladiroquit (Client Quit)
00:58:54  * loladirojoined
01:19:24  * loladiroquit (Quit: loladiro)
01:25:50  * kazuponjoined
01:28:32  * loladirojoined
01:30:48  * kazuponquit (Ping timeout: 272 seconds)
01:32:22  * loladiroquit (Client Quit)
01:38:26  * brsonjoined
01:42:10  * lohkeypart
01:46:32  * loladirojoined
01:46:58  * loladiroquit (Client Quit)
01:53:54  * loladirojoined
01:55:35  * loladiroquit (Client Quit)
01:55:50  * abraxasjoined
02:20:55  * kazuponjoined
02:25:22  * kazuponquit (Ping timeout: 250 seconds)
02:31:53  * dapquit (Quit: Leaving.)
02:40:17  * warzjoined
02:40:17  * warzquit (Changing host)
02:40:17  * warzjoined
02:53:39  * hzquit
02:57:01  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:59:43  * loladirojoined
03:15:48  * mmaleckichanged nick to mmalecki[zzz]
03:25:56  * sblomquit (Ping timeout: 276 seconds)
03:30:09  * kazuponjoined
03:34:10  * abraxasquit (Remote host closed the connection)
03:34:21  * warzquit
03:52:41  * abraxasjoined
03:58:20  * wolfeida_joined
03:58:34  * wolfeidauquit (Ping timeout: 246 seconds)
04:04:26  * abraxasquit (Remote host closed the connection)
04:15:42  * indexzerojoined
04:52:49  * brsonquit (Ping timeout: 246 seconds)
04:59:51  * brsonjoined
05:12:01  * kazuponquit (Remote host closed the connection)
05:23:20  * loladiroquit (Quit: loladiro)
05:23:56  * loladirojoined
05:26:51  * indexzeroquit (Quit: indexzero)
05:32:18  * indexzerojoined
05:50:38  * joshthecoderquit (Quit: Leaving...)
05:56:45  * mikealquit (Quit: Leaving.)
05:57:06  * mikealjoined
05:57:28  * abraxasjoined
06:03:09  * AvianFluquit (Remote host closed the connection)
06:03:28  * Chip_Zeroquit (Ping timeout: 245 seconds)
06:13:25  * bnoordhuisjoined
06:15:56  <bnoordhuis>morning
06:16:54  * wolfeida_quit (Remote host closed the connection)
06:22:50  * kazuponjoined
06:27:42  * kazuponquit (Ping timeout: 264 seconds)
06:45:16  * wolfeidaujoined
06:59:55  * mikealquit (Quit: Leaving.)
07:06:03  * brsonquit (Quit: leaving)
07:06:16  * mikealjoined
07:15:27  * Chip_Zerojoined
07:25:09  * pooyajoined
07:26:32  * kazuponjoined
07:29:13  * kazuponquit (Remote host closed the connection)
07:29:54  * rendarjoined
07:57:12  * pooyaquit (Quit: pooya)
07:57:20  * indexzeroquit (Quit: indexzero)
08:02:36  * indexzerojoined
08:09:30  * Raltquit (Ping timeout: 276 seconds)
08:24:42  * Raltjoined
08:39:46  * kazuponjoined
08:44:32  * kazuponquit (Ping timeout: 250 seconds)
08:53:08  * Raltquit (Ping timeout: 255 seconds)
08:58:37  * mjr_quit (Quit: mjr_)
09:04:54  * Raltjoined
09:28:54  * indexzeroquit (Quit: indexzero)
09:32:56  * indexzerojoined
09:33:02  <indutny>morning
09:34:44  * indexzeroquit (Client Quit)
09:40:31  <indutny>bnoordhuis: so
09:40:33  <indutny>bnoordhuis: yt?
09:40:43  <bnoordhuis>indutny: yep
09:40:57  <indutny>bnoordhuis: ok, so ignoring ENOENT. does it sounds good to you know? :)
09:44:08  <bnoordhuis>indutny: the issue is that a cb closes the watcher for fd x, then reopens it?
09:44:16  <indutny>yes
09:44:16  <bnoordhuis>and sometime later in the for loop, bam
09:44:22  <indutny>yes
09:44:44  <bnoordhuis>okay
09:44:59  <bnoordhuis>how does that affect the epoll and event ports backends?
09:45:18  <indutny>hm...
09:45:20  <indutny>you tell me :)
09:45:31  <indutny>I suppose it affects them too
09:46:10  <indutny>let me see
09:47:19  <indutny>ah... it seems to be unaffected by this...
09:47:29  <indutny>because it removes only if watcher is NULL
09:48:06  <indutny>bnoordhuis: and why isn't it consistent?
09:50:22  <bnoordhuis>indutny: the kqueue backend lazily disables events we've stopped watching by squelching them when they happen
09:50:30  <bnoordhuis>the epoll backend doesn't do that
09:50:36  <bnoordhuis>and neither does the event ports backend iirc
09:50:43  <indutny>ok
09:50:53  <indutny>so this shouldn't be a problem for them then
09:51:00  <bnoordhuis>not now anyway :)
09:51:01  <indutny>I've force pushed it https://github.com/joyent/libuv/pull/656
09:52:04  <bnoordhuis>indutny: so the one question that remains is this
09:52:17  <bnoordhuis>i want to eventually batch up individual disables
09:52:24  <bnoordhuis>how does the ENOENT check affect that?
09:52:37  <indutny>bnoordhuis: well... hm...
09:52:44  <indutny>bnoordhuis: it affects it much
09:52:47  <bnoordhuis>i guess i should consult the freebsd / xnu source
09:52:52  * kazuponjoined
09:52:52  <indutny>indeed
09:52:57  <indutny>let me check
09:53:16  <indutny>it should be applying all changes anyway
09:53:24  <indutny>regardless this error
09:53:32  <indutny>because otherwise it might end half-way
09:53:37  <indutny>which is not really consistent
09:53:47  * kazuponquit (Read error: Connection reset by peer)
09:54:06  * kazuponjoined
09:54:06  <bnoordhuis>right. it's supposed to update the ev->data field, right?
09:54:23  <indutny>aaah
09:54:24  <indutny>now
09:54:27  <indutny>err
09:54:28  <indutny>no
09:54:33  <indutny>it stops applying changes to kqueue
09:54:40  <indutny> while (nchanges > 0 && error == 0) {
09:54:43  <indutny>at least xnu
09:54:47  <bnoordhuis>oh, you mean it backs out
09:54:54  <indutny>not sure what you mean
09:55:02  <bnoordhuis>it aborts halfway
09:55:02  <indutny>but it might stop doing right things
09:55:04  <indutny>yes
09:55:14  <bnoordhuis>anyway, it doesn't matter - i'll worry about it when i cross that bridge
09:55:27  <indutny>I think you should cross it pretty carefully
09:55:40  <indutny>because this error happens pretty often when benchmarking web serevr
09:55:42  <indutny>server*
09:55:53  <bnoordhuis>i may just forego crossing it altogether :)
09:56:00  <bnoordhuis>who cares about os x performance, right?
09:56:14  <bnoordhuis>you're going to say "the people that benchmark on os x"
09:56:30  <bnoordhuis>i have many unkind words to say about people who do that
09:56:44  * kazuponquit (Read error: Connection reset by peer)
09:57:03  <bnoordhuis>i might even get... ironical at them
09:57:07  * kazuponjoined
09:58:23  <bnoordhuis>i kid, i kid. riling up apple fanbois with how bad os x really is, it's one of my favorite pastimes
09:59:03  <bnoordhuis>indutny: go ahead and merge your patch
09:59:07  <indutny>ok
09:59:48  <indutny>one sec
10:01:25  <MI6>joyent/libuv: Fedor Indutny master * b86ed94 : kqueue: ignore ENOENT error File descriptor might be closed during callb - http://git.io/RE4lyQ
10:01:29  <indutny>done
10:03:26  * travis-cijoined
10:03:26  <travis-ci>[travis-ci] joyent/libuv#964 (master - b86ed94 : Fedor Indutny): The build passed.
10:03:26  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/273cecc56ff5...b86ed94940f8
10:03:26  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3718813
10:03:26  * travis-cipart
10:07:52  <indutny>bnoordhuis: wanna update it in node?
10:08:00  <bnoordhuis>why?
10:08:06  <bnoordhuis>oh, because of tlsnappy
10:08:12  <indutny>haha
10:08:21  <indutny>well, that's not that important
10:08:29  <indutny>but would be cool to test it
10:08:42  <bnoordhuis>you know how it works, right?
10:08:59  <indutny>well, remove, copy, commit
10:09:09  <indutny>I can use git archive
10:09:16  <indutny>but meh...
10:09:23  <indutny>or are you talking about anything else?
10:11:39  <bnoordhuis>no, that
10:11:44  <indutny>ok
10:12:09  * felixgejoined
10:12:09  * felixgequit (Changing host)
10:12:09  * felixgejoined
10:12:45  <indutny>bnoordhuis: can you post this line?
10:12:56  <indutny>:)
10:12:59  <bnoordhuis>you mean the git archive thing?
10:13:15  <bnoordhuis>rm -rf deps/uv/ ; (cd ../libuv && git archive --format=tar --prefix=deps/uv/ HEAD) | tar x
10:15:08  <indutny>good
10:15:12  <indutny>bnoordhuis: thank you
10:15:29  <MI6>joyent/node: Fedor Indutny master * ba75452 : deps: upgrade libuv to b86ed94 - http://git.io/fAeLaA
10:15:57  * loladiroquit (Quit: loladiro)
10:17:23  <indutny>oh
10:17:29  <indutny>bert hasn't landed inlined assembly
10:17:32  <indutny>shit came real :)
10:18:24  * loladirojoined
10:20:13  * loladiroquit (Client Quit)
10:20:17  * abraxasquit (Remote host closed the connection)
10:20:56  * abraxasjoined
10:21:24  * abraxasquit (Read error: Connection reset by peer)
10:21:31  * abraxasjoined
10:22:10  * abraxasquit (Remote host closed the connection)
10:29:00  * peterrsjoined
10:30:01  <bnoordhuis>i don't know wtf is up with master but it's bad
10:30:22  <bnoordhuis>this is http_simple bytes/1 with v0.8: 12601.54 reqs/s
10:30:32  <bnoordhuis>and this is master: 2912.51 reqs/s
10:33:00  <bnoordhuis>with streams2 reverted: 3986.75 req/s
10:33:39  * bnoordhuisdoes not want to git bisect this...
10:33:55  <txdv>Who didn't benchmark their commits
10:36:22  <txdv>bnoordhuis: did you see my elaboration about dual stack?
10:36:58  <bnoordhuis>txdv: i saw a github email. haven't read it yet
10:39:32  <txdv>21dec is near
10:39:34  <indutny>huh
10:39:36  <txdv>i want to go under with dual stack
10:39:59  <indutny>bnoordhuis: this might explain shitty performance of tlsnappy on it
10:40:13  <indutny>bnoordhuis: I get only 900 req/sec
10:40:19  <indutny>while I was getting 1200 req/sec on 0.8
10:40:23  <bnoordhuis>indutny: i'm bisecting it
10:40:47  <txdv>please tell us what commit was responsible for this
10:40:50  <bnoordhuis>which is painfully slow work
10:41:03  <txdv>still log(n) steps
10:41:50  <indutny>btw
10:42:08  <indutny>uv__async_io still ocupies 3.7% of time in tlsnappy's master thread
10:46:23  <bnoordhuis>compiling, compiling...
10:46:26  <indutny>hahaha
10:51:01  <bnoordhuis>29d12c7 V8: Upgrade to
10:51:14  <indutny>oh great
10:51:33  <indutny>shit came real
10:51:41  <bnoordhuis>there was a bug a while ago where we accidentally built v8 without optimizations
10:51:46  <bnoordhuis>maybe this is the reprise
10:51:54  <bnoordhuis>okay, time for lunch. biab
10:54:10  <indutny>see ya
10:55:23  * kazupon_joined
10:55:53  * kazuponquit (Read error: Connection reset by peer)
11:16:33  * hzjoined
11:17:34  * felixgequit (Quit: http://www.debuggable.com/)
11:59:15  * kazuponjoined
12:01:41  * kazupon_quit (Ping timeout: 255 seconds)
12:30:23  * kazuponquit (Remote host closed the connection)
12:30:55  * kazuponjoined
12:30:55  * kazuponquit (Read error: Connection reset by peer)
12:38:11  * sgallaghjoined
12:58:51  * felixgejoined
13:06:29  * hzquit (Disconnected by services)
13:06:35  * hzjoined
13:13:46  * mmalecki[zzz]changed nick to mmalecki
13:15:43  * felixgequit (Quit: felixge)
13:15:54  * jmar777joined
13:18:43  * kazuponjoined
13:20:51  * felixgejoined
13:20:51  * felixgequit (Changing host)
13:20:51  * felixgejoined
13:33:18  * kazuponquit (Remote host closed the connection)
13:45:45  * felixgequit (Quit: felixge)
13:46:48  <indutny>back
13:46:58  <bnoordhuis>ditto
13:47:04  * benoitcquit (Excess Flood)
13:47:47  * benoitcjoined
13:49:58  * felixgejoined
13:49:58  * felixgequit (Changing host)
13:49:59  * felixgejoined
13:56:15  <bnoordhuis>turns out it's not 29d12c7, i already fixed that
13:56:21  <bnoordhuis>the search continues :/
13:57:50  <indutny>hehe
13:57:53  <indutny>bisect magic
13:58:07  <bnoordhuis>indutny: завершилась с кодом <- what does that mean?
13:58:15  <indutny>huh?
13:58:18  <indutny>exited with code
13:58:20  <bnoordhuis>ah
13:58:25  <indutny>are you on russian servers?
13:58:29  <indutny>have you hacked us???
13:58:31  <indutny>man
13:58:33  <indutny>you're on my computer
13:58:34  <indutny>wait
13:58:35  <indutny>no
13:58:39  <indutny>my computer is all english
13:58:53  <indutny>bnoordhuis: speak to me!
13:59:06  <bnoordhuis>indutny: i thought i'd do unto the russians what they do unto us
13:59:16  <bnoordhuis>i kid, it's from here -> https://github.com/bnoordhuis/node-iconv/issues/49
14:07:21  <indutny>ok
14:09:10  * kuebkjoined
14:14:55  * sgallaghquit (Remote host closed the connection)
14:16:11  * sgallaghjoined
14:17:40  <bnoordhuis>found the performance regression. it's the tcp backoff patch
14:17:58  <bnoordhuis>it absolutely kills single-process performance
14:18:03  <indutny>great
14:18:04  <bnoordhuis>guess it's revert time :/
14:18:19  <indutny>can you show me the code?
14:18:41  <bnoordhuis>indutny: commit b788c5e
14:19:02  <bnoordhuis>it's easy to verify with `export UV_TCP_SINGLE_ACCEPT=0`
14:23:37  <bnoordhuis>streams2 has a pretty bad impact too, though - 35% drop in reqs/s
14:44:58  * felixgequit (Quit: http://www.debuggable.com/)
14:45:46  <MI6>joyent/libuv: Ben Noordhuis master * dc559a5 : unix: disable relaxed accept() by default Don't use the relaxed accept() - http://git.io/6F2H2Q
14:46:45  <MI6>joyent/node: Ben Noordhuis master * 7b2ef2d : deps: upgrade libuv to dc559a5 - http://git.io/5SqgXg
14:47:20  <bnoordhuis>isaacs: ping
14:47:33  * travis-cijoined
14:47:34  <travis-ci>[travis-ci] joyent/libuv#965 (master - dc559a5 : Ben Noordhuis): The build passed.
14:47:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b86ed94940f8...dc559a5ce69c
14:47:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3722367
14:47:34  * travis-cipart
14:50:25  <bnoordhuis>indutny: have you reviewed that idle gc patch?
14:59:29  * `3rdEdenjoined
15:00:24  <indutny>no?
15:00:26  <indutny>link
15:00:29  <indutny>or it didn't happen
15:01:24  * piscisaureus_joined
15:01:45  <indutny>piscisaureus_: hey bert\
15:01:51  <indutny>drinking tuesday?
15:01:52  * mjr_joined
15:01:52  <piscisaureus_>hey fedir
15:01:59  <piscisaureus_>*fedor
15:02:05  <piscisaureus_>haha
15:02:12  <piscisaureus_>that would've been pretty bad
15:02:17  <piscisaureus_>but I had other stuff to do today
15:03:59  <indutny>ok :)
15:04:09  <indutny>like finally merging inlined assembly for openssl?
15:04:24  <bnoordhuis>indutny: https://github.com/joyent/node/pull/4430
15:04:40  <indutny>ah this
15:04:44  <indutny>idle gc?
15:05:15  <bnoordhuis>yep
15:05:27  <indutny>this is not it
15:05:29  <indutny>but it lgtm
15:05:40  <bnoordhuis>actually, it removes the idle gc thing
15:05:55  <bnoordhuis>and i'm going to preempt the haters by stuffing it in a module
15:06:21  <bnoordhuis>the cherry on top is that it actually works better than the builtin thing
15:06:29  <piscisaureus_>indutny: yes, feeling like it.
15:06:41  <indutny>yeah
15:06:43  <indutny>good good
15:07:41  <bnoordhuis>piscisaureus_: uv_run2
15:08:02  <bnoordhuis>if you don't review it today, i'm blindly merging it :)
15:08:10  <piscisaureus_>bnoordhuis: i did review it!
15:08:19  <piscisaureus_>bnoordhuis: it worked, except for `else:`
15:08:24  <bnoordhuis>ah that
15:08:32  <bnoordhuis>i don't have any emails of that though
15:08:51  <piscisaureus_>bnoordhuis: saghul sent me an email that he couldn't fix it because he was on holiday
15:09:15  <piscisaureus_>bnoordhuis: do you happen to know the PR number from the top of your head?
15:09:31  <MI6>joyent/node: Ben Noordhuis master * 8ccfed2 : node: s/-/_/ in add-on symbol name Replace dashes with underscores. When - http://git.io/6iVVTQ
15:09:33  <bnoordhuis>piscisaureus_: #535
15:09:47  <bnoordhuis>that's admittedly off the top of awesome bar, not my head
15:11:43  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 0820be7 : Implemented uv_run2 Allows for running the event loop in 3 modes: * de - http://git.io/urtUXA
15:11:48  <piscisaureus_>bnoordhuis: ^
15:11:54  <bnoordhuis>very good
15:13:18  <bnoordhuis>indutny: btw, you're right - i linked you to the wrong pr :)
15:13:23  <bnoordhuis>https://github.com/joyent/node/pull/4429 <- remove idle gc
15:13:27  <bnoordhuis>piscisaureus_: ^
15:13:42  <indutny>bnoordhuis: assigning like a boss
15:13:46  * travis-cijoined
15:13:46  <travis-ci>[travis-ci] joyent/libuv#966 (master - 0820be7 : Saúl Ibarra Corretgé): The build passed.
15:13:47  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/dc559a5ce69c...0820be70084a
15:13:47  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3722794
15:13:47  * travis-cipart
15:15:20  <piscisaureus_>bnoordhuis: reviewing, I think it's about time we do this
15:15:25  <piscisaureus_>too late even :-)
15:15:32  <indutny>:)
15:15:34  <indutny>yes
15:15:41  <indutny>we should have been done it after first blog post
15:16:09  <piscisaureus_>bnoordhuis: lgtm.
15:16:14  <bnoordhuis>cool
15:16:54  <MI6>joyent/node: Ben Noordhuis master * d607d85 : node: remove idle gc Remove the idle garbage collector. Its purpose was - http://git.io/YraASg
15:17:33  <mmalecki>bnoordhuis: is this the commit you mentioned?
15:17:46  <bnoordhuis>mmalecki: yes
15:17:56  <bnoordhuis>i mentioned you in the PR :)
15:18:39  <bnoordhuis>indutny, piscisaureus_: btw, https://github.com/bnoordhuis/node-idle-gc <- if you feel like reviewing it, go ahead
15:19:18  <mmalecki>bnoordhuis: should apply to 0.8, right?
15:19:24  <bnoordhuis>mmalecki: the patch? yes
15:20:11  <bnoordhuis>i just pushed a module to npm that requires a version of node that hasn't been released yet. feels good
15:20:32  <indutny>:)
15:20:49  <indutny>isaacs should make all modules incompatible with 0.8
15:20:54  <indutny>or
15:20:59  <indutny>just make npm incompatible with 0.8
15:25:03  <piscisaureus_>bnoordhuis: so re accept backoff
15:25:12  <bnoordhuis>yes. it's making me sad :/
15:25:16  <piscisaureus_>bnoordhuis: I think this is going nowhere...
15:25:44  <piscisaureus_>bnoordhuis: maybe we can have a round robin mode?
15:26:03  <piscisaureus_>bnoordhuis: where the cluster master just accepts all connections and then sends them to all workers
15:26:14  <piscisaureus_>bnoordhuis: it will be slower, but atleast it'll be reliable....
15:26:35  <bnoordhuis>yes. it's the logical next step
15:26:39  <bnoordhuis>but it still makes me sad
15:26:50  <indutny>unfortunatelly this doesn't helps tlsnappy
15:26:54  <indutny>it's still 850rps on 0.10
15:26:58  <indutny>and 1200 on 0.8
15:27:04  <indutny>on my old mbp
15:27:31  <bnoordhuis>indutny: try reverting streams2
15:27:53  <indutny>how is it related?
15:28:04  <bnoordhuis>i did some benchmarks today
15:28:17  <bnoordhuis>with streams2, master is 35% slower
15:28:27  <indutny>oooh
15:28:29  <indutny>interesting
15:28:36  <bnoordhuis>i'm going to ask isaacs to revert it
15:28:54  <bnoordhuis>because it seems unlikely such a performance gap is going to be closed
15:29:41  <indutny>stupid question
15:29:48  <indutny>how to revert merge?
15:29:57  <piscisaureus_>git revert --merge ? :-)
15:30:00  <indutny>git revert -m 1 <commit> ?
15:30:10  <piscisaureus_>yeah
15:31:19  <indutny>no
15:31:21  <indutny>that's not the case
15:31:29  <indutny>h
15:31:34  <indutny>I haven't reverted it...
15:31:35  <indutny>shit
15:32:52  <bnoordhuis>indutny: what commit did you revert?
15:33:46  <indutny>I think I've fixed it
15:33:59  <indutny>ok
15:34:02  <indutny>still the same :)
15:34:13  <indutny>note: I'm on inlined-assembly branch
15:34:21  <indutny>on master it's even more slower
15:34:26  <indutny>(but surprisingly not much)
15:38:21  <indutny>isaacs: yt?
15:40:33  <indutny>bnoordhuis: piscisaureus_: any ideas?
15:40:41  <bnoordhuis>indutny: about what?
15:40:44  <indutny>call-stack profile seems to be pretty usual
15:40:48  <indutny>about performance regression on 0.10
15:40:51  <indutny>in tlsnappy
15:41:00  <indutny>I suppose it's related to openssl
15:41:04  <indutny>well, I'm pretty sure it is
15:41:05  <indutny>:)
15:41:12  <piscisaureus_>indutny: is that with or without inlined asm?
15:41:17  <indutny>with and without
15:41:20  <indutny>pretty the same
15:41:25  <indutny>with slight difference
15:41:37  <piscisaureus_>no I dont know then
15:41:38  <indutny>do you know how to check if inlined assembly actually works?
15:42:33  <indutny>ah wait
15:42:41  <indutny>let me check one thing
15:44:07  * felixgejoined
15:44:07  * felixgequit (Changing host)
15:44:07  * felixgejoined
15:44:16  <indutny>ok, it's 902 with inlined assembly :)
15:44:23  * joshthecoderjoined
16:03:34  * felixgequit (Quit: felixge)
16:03:44  * kuebkpart
16:03:58  * c4milojoined
16:07:12  * `3rdEdenquit (Remote host closed the connection)
16:07:36  * felixgejoined
16:07:36  * felixgequit (Changing host)
16:07:36  * felixgejoined
16:07:43  <isaacs>indutny: pong
16:07:52  <isaacs>Anyone want to proof the blog post on streams2? https://gist.github.com/4329277
16:08:01  <piscisaureus_>bnoordhuis: I still think that the "basic" accept backoff can make a difference in certain scenarios
16:08:10  <piscisaureus_>bnoordhuis: so maybe we can leave that in, but without the nanosleep
16:08:25  <isaacs>It's a pretty short post, followed by the documentation
16:08:25  <indutny>isaacs: a question
16:08:26  <piscisaureus_>bnoordhuis: and, maybe make it configurable from js
16:08:35  <isaacs>yessir
16:08:35  <bnoordhuis>piscisaureus_: well, maybe. but on linux, without the nanosleep, it goes back to wildly uneven distributions
16:08:40  <indutny>isaacs: what do you think about external auth for npm?
16:08:49  <isaacs>how do you mean?
16:08:57  <indutny>isaacs: I mean when using custom registry for npm
16:09:01  <piscisaureus_>bnoordhuis: does the nanosleep pain also happen on linux?
16:09:03  <bnoordhuis>isaacs: have you seen our comments on streams2?
16:09:04  <indutny>isaacs: you have no option to use global auth
16:09:06  <bnoordhuis>piscisaureus_: yes
16:09:11  <piscisaureus_>bnoordhuis: ah.
16:09:13  <indutny>isaacs: and that's pretty bad sometimes
16:09:24  <isaacs>indutny: you mean, use a different auth for different registries?
16:09:31  <isaacs>or use the same auth for all registries (which is what it does)
16:09:32  <indutny>erm
16:09:37  <bnoordhuis>piscisaureus_: it's annoying in that it works great with num_processes > 2
16:09:44  <indutny>I mean using auth from another registry
16:09:46  <indutny>or something like this
16:09:47  <bnoordhuis>piscisaureus_: but it absolutely bombs with num_processes <= 2
16:09:49  <piscisaureus_>bnoordhuis: well, on your machine
16:10:01  <indutny>isaacs: I haven't really designed API for this yet :)
16:10:04  <indutny>isaacs: just sharing thoughts with you
16:10:06  <indutny>you know
16:10:06  <bnoordhuis>piscisaureus_: yes, but also on a couple of other machines i tested on
16:10:26  <piscisaureus_>right
16:10:37  <bnoordhuis>piscisaureus_: but i'm going to think hard and deep about it
16:10:42  <piscisaureus_>haha
16:10:45  <piscisaureus_>as always
16:10:52  <bnoordhuis>someone's gotta do it
16:11:00  <piscisaureus_>bnoordhuis: the round robin thing is sad but atleast it'll be predictable
16:11:07  <bnoordhuis>actually, i thought up a way to fix it in the kernel
16:11:16  <bnoordhuis>but it'll probably cause no end of regressions with other workloads
16:11:37  <piscisaureus_>bnoordhuis: i have so far ignored this issue but actually on windows the cluster stuff also sucks monkey balls
16:11:38  <bnoordhuis>fixing it in user mode is no doubt many, many times simpler
16:11:55  <piscisaureus_>bnoordhuis: it works very well if your server is extremely busy and otherwise it is lame
16:12:01  <isaacs>indutny: what i'd like to do eventually is make all registry-related configs registry-specific
16:12:13  <indutny>isaacs: well, that's good too
16:12:14  <isaacs>indutny: cache, auth, etc.
16:12:20  <indutny>isaacs: yeah, this could be an option
16:12:27  <bnoordhuis>isaacs: so about streams2. piscisaureus_ and i are seeing 35-40% performance drops
16:12:30  <indutny>isaacs: right now you'll get auth errors if you'll use private npm repo
16:12:35  <indutny>isaacs: and have old auth in .npmrc
16:12:41  <isaacs>bnoordhuis: in which benchmark?
16:12:53  <bnoordhuis>isaacs: for example http_simple with -c 10 bytes/1
16:13:02  <piscisaureus_>isaacs: ab -c 100 -t 100 -k
16:13:07  <bnoordhuis>isaacs: though it's possible the effect is less pronounced on os x
16:13:19  <isaacs>ok
16:13:30  <piscisaureus_>the effect with -k probably isn't
16:13:31  <isaacs>i was going to dig into why createPipe() is failing on windows
16:13:54  <isaacs>piscisaureus_: can you look into that, and i'll profile adn dig into http_simple regressions?
16:14:16  <piscisaureus_>isaacs: I don't have time for either of these today, sorry
16:14:25  <isaacs>my benchmarking has been mostly focused on net-pipe. if that's fast, and http_simple is slow, then it's probably a fuckup in http.js
16:14:34  <isaacs>ie, related to streams2, but not essential to it
16:14:57  <isaacs>also, i think that the state objects can get smaller.
16:15:09  <isaacs>we use a few more flags than is probably strictly necessary at this point
16:15:28  <isaacs>piscisaureus_: oh well :)
16:15:53  <isaacs>i'm guessing the Pipe issue is a simple fix, but finding it in that godforsaken os is very difficult
16:16:30  <isaacs>my windows skills are so weak
16:17:17  <bnoordhuis>isaacs: maybe sblom can help?
16:17:29  <isaacs>yeah, i'll ping him when he comes online
16:18:05  <isaacs>ircretary: tell sblom Do you have time today to dig into why createPipe is broken on windows? i'm the one who broke it, but finding the source of the issue on windows is proving difficult for me and my limited skills.
16:18:05  <ircretary>isaacs: I'll be sure to tell sblom
16:18:10  <isaacs>ircretary: thanks
16:18:10  <ircretary>isaacs: You're welcome :)
16:19:10  * felixgequit (Quit: felixge)
16:20:55  <piscisaureus_>isaacs: actually - what's the issue
16:21:33  * felixgejoined
16:21:33  * felixgequit (Changing host)
16:21:33  * felixgejoined
16:23:48  <isaacs>piscisaureus_: well, child process pipes are completely busted.
16:23:59  <piscisaureus_>ah
16:24:04  <isaacs>piscisaureus_: node does createPipe() and gets an object, but it doesn't ever get any data.
16:25:02  <piscisaureus_>isaacs: well
16:25:08  <piscisaureus_>isaacs:
16:25:08  <piscisaureus_>> require('child_process').spawn('cmd', ['/c','dir']).stdout.pipe(process.stdout)
16:25:10  <piscisaureus_>works here
16:25:15  <piscisaureus_>with current node master
16:25:21  <isaacs>hrm. one sec..
16:26:03  <isaacs>https://gist.github.com/4329419
16:26:07  <isaacs>try that ^
16:26:44  <isaacs>you're right, spawning a non-node child proc seems to work, though.
16:27:31  <piscisaureus_>isaacs: looks like stdout is busted
16:27:35  <piscisaureus_>when it is a pipe
16:27:35  <isaacs>so maybe the problem is with stdout rather than pipes
16:27:37  <isaacs>right
16:27:41  <isaacs>works fine in nix, though
16:28:16  <piscisaureus_>although this works -> node -pe "console.log('hello')" | cat
16:28:18  <piscisaureus_>hmm
16:28:27  <piscisaureus_>will take a look
16:28:35  <isaacs>awesome, thanks!
16:29:07  <isaacs>ircretary: tell sblom piscisaureus_ may be looking into this as well. Check the log. stdout is busted when it's a pipe, is the problem.
16:29:07  <ircretary>isaacs: I'll be sure to tell sblom
16:29:39  <piscisaureus_>isaacs: that said, I really don't have much time today...
16:30:01  * tristramjoined
16:30:30  <indutny>a question
16:30:36  <indutny>generic one
16:30:39  <indutny>about http.Agent
16:30:51  <isaacs>bnoordhuis: how's mmap-reloaded coming? what's the state of that? merge-worthy?
16:31:12  <bnoordhuis>isaacs: merge-worthy but i want to do some more research
16:31:14  <indutny>when looking at the code I've noticed that keep-alive requests won't release sockets to agent's pool
16:31:23  <indutny>which results in creating a lot of connections...
16:31:28  <isaacs>bnoordhuis: k, sounds good. thanks. lmk what you find.
16:31:29  <indutny>is it true? or am I missing something?
16:31:31  <indutny>isaacs: ^
16:31:41  <isaacs>indutny: don't know offhand.
16:31:46  <indutny>ok
16:31:48  <isaacs>indutny: but isn't that kind of what keep-alive is?
16:31:51  <indutny>well
16:31:58  <indutny>the thing is that you can't do second request
16:31:58  <isaacs>indutny: like, "use this socket again, don't close it"
16:32:07  <indutny>well, there're no API for that
16:32:09  <isaacs>oh, because it's not releasing it back to the agent.
16:32:19  <isaacs>right
16:32:24  * isaacsis paging that problem in
16:32:29  <isaacs>theer's this "ForeverAgent" thing
16:32:34  <indutny>yes
16:32:40  <isaacs>it's in request, and voxer did some enhancements to it i hink
16:32:46  <isaacs>is that what you're messing with?
16:33:08  <isaacs>the built-in http.Agent re-uses sockets if it can, until nothing needs them, then immediately closes them
16:33:13  <isaacs>the ForeverAgent, doesn't ever close them
16:33:33  <isaacs>what it *ought* to do is ref them when they're in use, and unref them when they aren't.
16:33:34  <mjr_>We are about to roll out a version of foreveragent
16:33:41  <isaacs>mjr_: yeah, mikeal mentioned that
16:33:48  <isaacs>mjr_: said he'd pull it into request when you do
16:35:19  <isaacs>bnoordhuis: do you have time today to write up a quick thing on what's changed in the threadpool? why we got rid of ev/eio?
16:35:39  <bnoordhuis>isaacs: not today, but tomorrow - i'm about to sign off
16:35:47  <isaacs>bnoordhuis: like, imagine someone on the mailing list asked, "How come you got rid of libev and libeio? that sounds stupid."
16:35:58  <isaacs>bnoordhuis: k, have a good night :)
16:36:07  <bnoordhuis>isaacs: you know how i'd respond - "no u r stupid"
16:36:13  <isaacs>bnoordhuis: that's a pretty good response.
16:36:27  <bnoordhuis>it is, isn't it? but i'll write up a blog post
16:36:55  <indutny>I liked libeio
16:36:56  <isaacs>i'm gonna publish the streams2 blog post today
16:36:56  <bnoordhuis>mjr_: o
16:36:57  <indutny>good naming
16:36:59  <bnoordhuis>err
16:37:16  <bnoordhuis>mjr_: you reported an issue a while ago about http.Agent handing out dead connections?
16:37:24  <indutny>isaacs: I think we should eventually handle this keep-alive shit in http module
16:37:29  <mjr_>bnoordhuis: Danny did that work
16:37:31  * mikealquit (Quit: Leaving.)
16:37:32  <indutny>isaacs: or at least set it Connection to close
16:37:45  <isaacs>indutny: yes.
16:37:49  <isaacs>indutny: that is planned for 0.12
16:37:53  <indutny>oooh
16:37:57  <isaacs>indutny: we need to do keepalive properly
16:37:57  <mjr_>I continue to believe that real keepalive should be part of http client.
16:37:58  <indutny>people gonna wait
16:38:02  <indutny>:)
16:38:07  <isaacs>mjr_: ++
16:38:14  <indutny>mjr_: ++
16:38:15  <isaacs>the thing is, we needed ref/unref
16:38:23  <isaacs>and that didn't land until 0.8 (iirc?)
16:38:24  <bnoordhuis>mjr_: internet citizenship. keeping idle connections around is not it
16:38:45  <isaacs>node should do keepalive to match web browsers' behavior
16:38:46  <mjr_>bnoordhuis: not sure I agree. Opening new connections every time is being a bad citizen
16:39:15  <isaacs>the standard for http clients is web browsers, and to a lesser extent (though closer to us) curl
16:39:21  <bnoordhuis>mjr_: keep the request pipeline filled and node'll reuse connections
16:39:27  <isaacs>browsers and curl both do keepalives and use them indefinitely
16:39:31  <bnoordhuis>that said, i can see the case for adding a keepOpen:true flag
16:39:35  <mjr_>bnoordhuis: doesn't work well if you have your workload spread across multiple processes
16:39:37  <mjr_>as you do with node
16:39:39  <isaacs>bnoordhuis: yes, this
16:39:51  <isaacs>bnoordhuis: we should keep some reasonable configurable number of connections open
16:40:01  <isaacs>bnoordhuis: but still close them if that's the *only* thing keeping node open
16:40:10  <bnoordhuis>isaacs: but only as opt-in functionality
16:40:18  <mjr_>I feel like my mind has been melded with isaacs on this issue.
16:40:29  <isaacs>bnoordhuis: it should behave like a web browser does.
16:40:48  <isaacs>bnoordhuis: if you are making repeated (single) requests to a server, it should reuse the same connection.
16:40:54  <isaacs>up to, say, 8 connections per server
16:41:00  <isaacs>(which is what browsers do by default)
16:41:10  <bnoordhuis>isaacs: a server application is not a browser
16:41:14  <isaacs>5 is always the wrong number.
16:41:22  <isaacs>bnoordhuis: but node is often not a server :)
16:41:29  <isaacs>when it's an http client, it should act like an http client.
16:41:29  <mjr_>bnoordhuis: the obvious example for us is consuming Facebook's API
16:41:43  <bnoordhuis>anyway, let's save this conversation for another day
16:41:45  <isaacs>yes.
16:41:50  <mjr_>Every single HTTPS client request we make to Facebook requires a new TLS negotiation
16:41:54  <mjr_>every single damn time
16:41:58  <isaacs>mjr_, bnoordhuis, indutny: So, this is why it's postponed for 0.12
16:42:04  <isaacs>there are other conversations to have today :0
16:42:09  <isaacs>and this one isn't trivial.
16:42:10  <piscisaureus_>bnoordhuis: isaacs: we have unref() bindings now, right?
16:42:15  <isaacs>piscisaureus_: yes.
16:42:17  <piscisaureus_>we can just keep the tcp open
16:42:22  <isaacs>piscisaureus_: so, we have the tools now.
16:42:22  <piscisaureus_>and node will exit anyway
16:42:26  <bnoordhuis>piscisaureus_: i don't think there's one for uv_tcp_t
16:42:41  <piscisaureus_>oh not?
16:42:42  <isaacs>piscisaureus_: mjr_ and indutny can probaly mess around wit hthis in userland, which would be ideal.
16:42:47  <bnoordhuis>streamwraps, i mean
16:42:47  <piscisaureus_>i thought we have streams
16:42:48  <isaacs>bnoordhuis: orly? i thought there was.
16:42:55  <piscisaureus_>I thought so too. lemme look
16:43:08  <bnoordhuis>unless tjfontaine added some while i wasn't looking
16:43:28  <piscisaureus_>yes there is
16:43:35  <indutny>isaacs: we can probably turn off keep-alive by default in 0.10
16:43:38  <indutny>that would be pretty fine
16:43:41  <piscisaureus_>https://github.com/joyent/node/blob/d607d856afc744b1e6bc42cdb9b67b6c4e7e4876/src/tcp_wrap.cc#L85
16:43:48  <indutny>I mean turn it off when using with agent
16:43:54  <piscisaureus_>bnoordhuis: ^
16:44:06  <MI6>joyent/node: isaacs v0.8 * faf9943 : blog: post about streams2 feature - http://git.io/mACOIw
16:44:10  <bnoordhuis>sneaky canadians
16:44:16  <bnoordhuis>(he's from canada, right?)
16:44:17  <isaacs>oh, whoops
16:44:22  <isaacs>force push on v0.8 coming, sorry
16:44:50  <piscisaureus_>isaacs: before that blog post, can we atleast try to fix some of the perf dent
16:45:18  <isaacs>piscisaureus_: i'm going to do that today
16:45:20  <MI6>joyent/node: isaacs v0.8 * 04adf0e : blog: post about streams2 feature - http://git.io/bRhSIg
16:45:21  <indutny>hahaha
16:45:21  <piscisaureus_>isaacs: I mean, I like streams2 but I will not stand behind a node 0.10 that's >35% slower
16:45:26  <isaacs>of course.
16:45:40  <isaacs>piscisaureus_: there are huge obvious problems with http.js
16:45:50  <piscisaureus_>ok
16:45:53  <isaacs>piscisaureus_: i literally just slapped code together (literally slapped!) until it was behaving correctly.
16:46:05  <piscisaureus_>naughty
16:46:13  <isaacs>piscisaureus_: but we shouldn't abandon the feature at this point.
16:46:37  <bnoordhuis>isaacs: how are you going to close the performance gap?
16:46:44  <bnoordhuis>35-40% is pretty steep
16:46:50  <isaacs>bnoordhuis: well, first i'm going to profile it and see what it actually is
16:46:55  <isaacs>bnoordhuis: s/what/where/
16:47:00  <isaacs>bnoordhuis: then i'm going to do programming to it
16:47:14  <piscisaureus_>haha
16:47:16  <isaacs>bnoordhuis: 35-40% means that there's some gigantic holes.
16:47:16  <bnoordhuis>isaacs: programming sometimes helps
16:47:29  <isaacs>bnoordhuis: i'm going to push buttons until the pattern of lights is more to our liking.
16:47:31  <piscisaureus_>un-gramming
16:47:35  <bnoordhuis>but are you sure it's just some oversight and not some fundamental shortcoming?
16:47:47  <isaacs>bnoordhuis: if it was fundamental, then i think that net-pipe would be much worse.
16:47:52  <rendar>bnoordhuis: what is a "relaxed" accept()?
16:47:59  <isaacs>bnoordhuis: and if there is some fundamental shortcoming, it's likely in the implementation, rather than the api
16:48:00  <bnoordhuis>isaacs: okay. surprise me :)
16:48:31  <isaacs>bnoordhuis: but without profiling it, really, no one knows what the problem is, and i can't really speculate.
16:48:38  <isaacs>or rather, i can ONLY speculate :)
16:48:38  <indutny>isaacs: I think that blogging is preliminary at this point
16:48:38  <bnoordhuis>rendar: it is/was a trick to ensure incoming connections are balanced evenly among listening processes
16:48:50  <bnoordhuis>rendar: it turned out it wasn't working so well :/
16:49:00  <rendar>bnoordhuis: oh i see
16:49:01  <piscisaureus_>it works on smartos tho
16:49:02  <indutny>isaacs: I like streams2 pretty much, but if they won't give pretty the same performance
16:49:11  <indutny>I will be against landing them in 0.10
16:49:18  <isaacs>ye of little faith
16:49:44  <bnoordhuis>isaacs: i ran some quick checks. the general impression i got was that streams2 is simply doing more per unit of work
16:49:56  <isaacs>bnoordhuis: yes, it needs some polishing
16:50:12  <isaacs>there's a bit more js in many places, because there needs to be in order to make some of these things configurable.
16:50:17  <isaacs>we can remove some of the configurability of it.
16:50:29  <bnoordhuis>piscisaureus_: ^ i mentioned that, didn't i :)
16:50:33  <isaacs>but you don't optimize the fast things until the slow things are optimized.
16:51:08  <isaacs>this is a feature people actually want.
16:51:19  * mikealjoined
16:51:33  <bnoordhuis>but is it something they need?
16:51:35  <isaacs>it makes node easier, and it's already proven useful.
16:51:41  * bnoordhuistrolls on
16:51:46  <isaacs>it fixes a handful of the most common user wtfs
16:51:56  <bnoordhuis>i was kidding back there
16:51:59  <isaacs>haha
16:51:59  <isaacs>ok
16:52:07  <bnoordhuis>but what are the issues people run into with streams in v0.8?
16:52:21  <bnoordhuis>apart from setEncoding, that's just a wart
16:52:28  <isaacs>bnoordhuis: immediate 'data' events, pause doesn't pause, and implementing streams is extremely difficult to do properly.
16:52:33  * AvianFlujoined
16:52:34  <isaacs>bnoordhuis: those are the biggest ones
16:52:44  <bnoordhuis>i can see the issue with pause
16:52:53  <bnoordhuis>but what's the problem with data events?
16:53:00  <isaacs>bnoordhuis: hyperactive backpressure is solved by the configurable water marks, but we can just rip that shit out
16:53:01  <piscisaureus_>actually that was also the problem that was the easiest to fix :-p
16:53:24  <isaacs>i hear often that it's overly difficult to implement a stream api properly
16:53:33  <isaacs>"Why can't i just define a read method, and YOU do all the fancy crap?"
16:54:00  <bnoordhuis>what fancy crap?
16:54:04  <indutny>because it's slow and complicated :)
16:54:05  <isaacs>and frankly, having written streaming parsers and streaming fs utils, and other things, they're right. it's overly difficult, verging on impossible to not fuck up.
16:54:06  <indutny>haha
16:54:08  <bnoordhuis>back-pressure and such?
16:54:11  <isaacs>bnoordhuis: yes.
16:54:15  * indexzerojoined
16:54:17  <isaacs>bnoordhuis: pause/resume, write queues, etc.
16:54:35  <bnoordhuis>isaacs: isn't that better solved with some (perish the name) AbstractBaseStream class?
16:54:39  <isaacs>bnoordhuis: even in node core, there's the same exact (except subtly *different*) logic in zlib, fs, net, etc.
16:54:48  <isaacs>bnoordhuis: require('stream').Readable
16:54:55  <isaacs>bnoordhuis: AbstractBaseStream class ^
16:55:31  <isaacs>the question is: is that class ideal? is it optimized enough? is it too configurable, and sacrificing performance?
16:55:32  <bnoordhuis>and does that require/merit/warrant rewriting the other core streams?
16:55:34  * hzquit (Disconnected by services)
16:55:37  <isaacs>yes.
16:55:40  * hzjoined
16:55:47  <bnoordhuis>noted. now the arguments please :)
16:55:55  <isaacs>because *we* have a problem with non-DRY code in our streams.
16:56:12  <isaacs>we have (had) the same logic implemented in multiple places, in subtly different ways, and inconsistently.
16:56:23  <bnoordhuis>of all the things that keep me awake at night, that's not one
16:56:29  <isaacs>we call it a "stream api" but really there are like 6 of them
16:56:51  <isaacs>i imagine your daughter keeps you awake most nights ;)
16:56:51  <bnoordhuis>though admittedly it's mostly things like "did i lock the backporch door"
16:56:55  <bnoordhuis>that too :)
16:57:17  <isaacs>i have to commute so that i can run some benchmarks while half-listening to our engineering all-hands
16:57:23  <isaacs>i'll bbiab.
16:57:44  <bnoordhuis>ack. i'm off to dinner
16:57:45  <piscisaureus_>I think it's mostly insomnia after sleeping whole day, bnoordhuis
16:57:53  <isaacs>lulz
16:57:55  <bnoordhuis>piscisaureus_: oh snap!
16:58:28  <bnoordhuis>piscisaureus_: i'd make snide remarks about your contributions to node.js and libuv in recent times but dinner's ready :)
16:58:33  <mjr_>half-listening is really the only way to listen to an all-hands.
16:58:37  <piscisaureus_>hahhaha
16:59:04  <mjr_>I say this as someone who often speaks at / leads all-hands
16:59:06  <piscisaureus_>mjr_: you are completely right but, er, are you not the guy who is supposed to think all-hands is important?
16:59:11  <piscisaureus_>that
16:59:35  <mjr_>But I take it as a challenge to make it interesting enough to be worth paying attention to
16:59:37  <mjr_>But man, it's hard.
17:07:53  <tristram>hi, I'm trying to find out a bug with the zeromq nodejs bindings, and I dug down to libuv (and I'm somewhat lost) :
17:08:34  <tristram>there is a uv_poll_init_socket that sometimes doesn't seem to call the callback
17:08:56  <tristram>https://github.com/JustinTulloss/zeromq.node/blob/master/binding.cc#L272 (line 272 the callback, line 312 where defined)
17:09:43  <tristram>is there some documentation, known things to be careful when using it ?
17:09:50  <piscisaureus_>tristram: is that on unix or windows?
17:10:05  * brsonjoined
17:10:13  <piscisaureus_>tristram: also, you should atleast check the return values from uv_poll_init and uv_poll_start
17:10:27  <piscisaureus_>maybe you are putting an invalid fd in or something, and you are not going to know as it stands
17:10:48  <tristram>they're always returning 0
17:10:57  <tristram>on unix, tcp
17:13:24  * hzquit (Read error: Connection reset by peer)
17:13:45  * dapjoined
17:14:16  * hzjoined
17:14:56  <piscisaureus_>generally you have to be careful not to clobber an uv handle, and to not free it too early
17:15:05  <piscisaureus_>but apparently you never free it and I don't see obvious clobbering
17:15:56  <piscisaureus_>tristram: also, try to build/use it with a debug build of node and libuv
17:16:34  <piscisaureus_>tristram: there are many asserts etc in libuv that will give you a clue if you are doing something wrong
17:16:46  <piscisaureus_>tristram: also, what does "sometimes" mean? Do you have a test case that reproduces this sort of consistently?
17:17:19  <tristram>it's not deterministic
17:18:01  <tristram>I'm originaly using zeromq to communicate between my node app, and my c++ app
17:18:04  * felixgequit (Quit: felixge)
17:18:28  <tristram>out of 1000 requests, about 5 fail (a very simple 'hello' exchange)
17:18:41  * felixgejoined
17:18:41  * felixgequit (Changing host)
17:18:41  * felixgejoined
17:19:02  <tristram>I'll give a try with a debug release of node (even if I'm not the dev of the bindings)
17:23:06  * mjr_quit (Quit: mjr_)
17:27:58  * joshthecoderquit (Quit: Leaving...)
17:51:40  * joshthecoderjoined
17:57:11  * loladirojoined
18:18:03  * `3rdEdenjoined
18:27:49  <tristram>meh, I had no more success to pin down the problem :/ I should give up :)
18:30:05  * felixgequit (Quit: http://www.debuggable.com/)
18:32:54  * brsonquit (Quit: leaving)
18:33:10  * brsonjoined
18:46:47  * bradleymeckjoined
18:49:06  * loladiroquit (Quit: loladiro)
18:50:55  * jmar777quit (Remote host closed the connection)
18:51:31  * jmar777joined
18:51:36  * bradleymeck_joined
18:53:02  * bradleymeckquit (Ping timeout: 252 seconds)
18:53:02  * bradleymeck_changed nick to bradleymeck
18:54:04  * TooTallNatejoined
18:54:14  * `3rdEdenquit (Remote host closed the connection)
18:55:59  * jmar777quit (Ping timeout: 260 seconds)
19:00:08  * loladirojoined
19:00:45  * `3rdEdenjoined
19:08:04  * sgallaghquit (Ping timeout: 252 seconds)
19:10:09  * LOUDBOTquit (Remote host closed the connection)
19:10:17  * LOUDBOTjoined
19:11:33  * LOUDBOTquit (Remote host closed the connection)
19:11:39  * LOUDBOT_joined
19:14:38  * sgallaghjoined
19:18:13  <isaacs>ok. i found the problem with http.js
19:18:20  <isaacs>but the solution will be harder to figure out than the problem :)
19:18:27  <isaacs>switching into old-mode is expensive.
19:19:02  <isaacs>bnoordhuis, piscisaureus_, indutny ^
19:19:32  <isaacs>also, we're spending a lot of time stringifying headers.
19:19:34  <isaacs>that sucks.
19:21:20  * LOUDBOT_quit (Remote host closed the connection)
19:21:26  * LOUDBOTjoined
19:24:33  * loladiroquit (Quit: loladiro)
19:39:25  * loladirojoined
19:45:38  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
19:57:08  <MI6>joyent/node: isaacs master * 43538f4 : benchmark: Add http-flamegraph This is very similar to http.sh, but gene - http://git.io/ycon6A
19:58:15  <isaacs>http://static.izs.me/http-streams2.svg
19:58:18  <isaacs>http://static.izs.me/http-streams1.svg
19:58:25  <isaacs>looks like i'm calling date.now() somewhere i shouldn't be.
19:58:31  <isaacs>(among other fascinating insights here)
20:01:55  <isaacs>that's weird, though, because i don't see where it's calling Date.now...
20:01:59  <isaacs>i think these stacks are lying to me
20:02:46  <piscisaureus_>isaacs: are you concatenating strings before writing them?
20:02:58  <isaacs>brb, lunch
20:03:05  <piscisaureus_>ok
20:03:15  * TooTallNatejoined
20:07:01  * sblomjoined
20:22:14  * mscdexjoined
20:22:21  <mscdex>indutny: ping
20:25:48  * pooyajoined
20:25:52  * mscdexpart ("Leaving")
20:26:30  * bnoordhuisquit (Ping timeout: 264 seconds)
20:42:13  * piscisaureus_quit (Ping timeout: 272 seconds)
20:50:29  * dapquit (Quit: Leaving.)
20:50:55  * dapjoined
20:54:03  * hzquit
20:57:16  * isaacsback
20:57:36  <isaacs>the Date.now is because the DTrace ustack helper is dropping a frame. it's coming from timers.active(this)
21:00:43  * lohkeyjoined
21:04:32  * sgallaghquit (Remote host closed the connection)
21:05:27  <mmalecki>isaacs: streams2 is streams2 or second run of the benchmark?
21:05:38  <mmalecki>probably a stupid question
21:05:53  <isaacs>mmalecki: streams2 is streams2 :)
21:08:23  <mmalecki>isaacs: can you try disabling http timestamp and running those again?
21:08:32  <mmalecki>this is where date.now() might be coming from
21:11:27  <isaacs>mmalecki: no, it's coming from timers.active()
21:11:39  <isaacs>the http Date header doesn't use Date.now()
21:11:48  * felixgejoined
21:11:48  * felixgequit (Changing host)
21:11:49  * felixgejoined
21:11:52  <isaacs>and it's updating only once per second
21:12:59  <isaacs>mmalecki: look for function utcDate()
21:13:05  <isaacs>that's how we get the date value
21:20:05  * piscisaureus_joined
21:20:12  <sblom>isaacs: Got your request for an investigation. I'm pretty swamped right now. I think things'll let up mid-afternoon and I'll check back with you then. I don't _think_ I see evidence that piscisaureus_ dug in on this so far.
21:20:21  <sblom>Speak of the devil...
21:20:42  <piscisaureus_>hello minions
21:20:43  <isaacs>sblom: no worries.
21:20:48  <isaacs>ITS THE PISCISAUREUS!
21:22:35  * rendarquit
21:22:54  <isaacs>piscisaureus_: no, i'm not concatenating strings before sending them
21:23:20  <piscisaureus_>ok good
21:23:47  <piscisaureus_>isaacs: i wonder why so much time is spent in TryFlatten then, I fixed that 9 months ago or so
21:27:13  <isaacs>piscisaureus_: hm
21:27:38  <isaacs>piscisaureus_: i suppose i could "cheat" and optimize our header handling.
21:27:41  <piscisaureus_>isaacs: I don't think this is the reason for the regression tho
21:27:43  <isaacs>but that seems disingenuous
21:27:51  <piscisaureus_>isaacs: cheating is totally allowed
21:28:01  <piscisaureus_>isaacs: faster is faster :-)
21:28:54  <isaacs>so, for the first time ever in my experience with them, the flamegraph profile is not immediately making the problem obvious.
21:28:57  <isaacs>:)
21:29:43  <isaacs>the streams1 and streams2 approaches look almost identical, except that v8::internal::String::WriteToFlatIcEEvPS1 is taking up a bigger proportion of tiem in the streams2 version
21:31:23  <isaacs>also, in both, the two peaks actually are almost identical, except for this _ZN2v88internalL21Builtin_HandleApiCallENS0_12_GLOBAL__N_116BuiltinArgumentsILNS0_21BuiltinExtraArgume fellow
21:31:37  <isaacs>i'm going to try editing that frame out and see what it looks like
21:32:52  <isaacs>piscisaureus_: also, how were you seeing the biggest difference in performance?
21:33:02  <isaacs>piscisaureus_: ie, what args to ab or whatever
21:33:32  <piscisaureus_>isaacs: I didn't try many variations here, but `ab -t 100 -c 100 -k` should give you the picture
21:34:02  <piscisaureus_>I had 40% perf dropoff with that benchmark
21:35:37  <isaacs>k, kewl
21:35:46  <isaacs>i'm seeing a perf drop, but it's kind of variable
21:35:53  <isaacs>didn't try /bytes/1
21:36:09  <isaacs>i think i was doing just /bytes/1024 only
21:38:21  <CoverSlide>you guys do so many benchmarks, it seems your lives would be easier if you had a CI server that ran benchmarks on every commit
21:38:40  <isaacs>CoverSlide: INORITE
21:38:43  <CoverSlide>and could show visible results like http://arewefastyet.com/ does
21:38:55  <isaacs>piscisaureus_: so, for large payloads, it seems mostly equivalent
21:39:10  <isaacs>piscisaureus_: i'm actually seeing that the variability is higher than any difference
21:39:13  * bradleymeckquit (Quit: bradleymeck)
21:39:16  <isaacs>that could be why these flamegraphs are useless.
21:39:50  <isaacs>CoverSlide: i would love benchmarks that were run on every commit, and produced a flamegraph for each one
21:39:55  <isaacs>that'd be so super killer
21:40:01  <piscisaureus_>isaacs: ok, so the problem is mostly in small payloads then. That's useful info.
21:40:28  <CoverSlide>is that something buildbot could do?
21:40:44  <isaacs>yes, indeed.
21:41:06  <tjfontaine>fwiw I am working currently on jenkins
21:41:13  <TooTallNate>buildbot?
21:41:33  <tjfontaine>http://jenkins.atxconsulting.com:8080 it will want you to authorize with github
21:41:42  <CoverSlide>node used to use buildbot iirc, but i think that was killed. buildbot i know is used for chome, and probably v8 as well
21:41:43  * wolfeidauquit (Remote host closed the connection)
21:41:43  * felixgequit (Quit: felixge)
21:41:46  <piscisaureus_>isaacs: how large is large here? With bytes/10000 I am actually still seeing a drop from 9000 to 65000
21:41:49  <piscisaureus_>er *6500
21:43:08  * pooyaquit (Quit: pooya)
21:44:40  <piscisaureus_>isaacs: bytes/100000 goes from 1600 to 1560
21:45:35  <isaacs>piscisaureus_: os?
21:45:41  <piscisaureus_>isaacs: moon magic
21:45:46  <isaacs>ohhh ok
21:46:11  <isaacs>can you find one with a really big diff, and then do that etw/perfctr flamegraph magic on it?
21:46:30  * felixgejoined
21:46:30  * felixgequit (Changing host)
21:46:31  * felixgejoined
21:47:18  <tjfontaine>fwiw test-net-listen-fd0 is a bit of an odd test to get working inside CI, since most CI's pipe in stdin which breaks that test in an interesting way see `echo | make test`
21:47:59  <isaacs>tjfontaine: that seems like a bug in the CI
21:48:09  <tjfontaine>or echo | node test/simple/test-net-listen-fd0
21:48:37  <tjfontaine>isaacs: ya I'm not entirely sure the best way to handle that, for now I just do `make test < /dev/null`
21:48:52  <isaacs>haha, that's clever
21:49:09  <isaacs>tjfontaine: we could probably also run the tests in a child proc that sets up a pipe for stdin
21:50:08  <isaacs>echo | node -e 'var c = require("child_process").spawn(process.execPath, ["test/simple/test-net-listen-fd0.js"],{stdio:["pipe",1,2]})'
21:50:17  <tjfontaine>isaacs: yup that was another alternative I was going to do which may be necessary in the wondows land
21:50:58  <isaacs>haha, "wondows"
21:51:05  <isaacs>i know, prolly a typo, but i like it
21:51:07  <CoverSlide>a fish named wondows?
21:51:25  <tjfontaine>I may stick with it
21:52:47  <isaacs>CoverSlide: yeah, we had a buildbot setup
21:52:49  <isaacs>it was ok
21:53:26  <tjfontaine>one thing I was impressed with in jenkins was delegating authority to github organization
21:53:29  <CoverSlide>the buildbot ui is fugly
21:53:34  * `3rdEdenquit (Quit: zzz)
22:05:02  * brsonquit (Read error: Operation timed out)
22:07:43  * felixgequit (Quit: felixge)
22:08:23  * wolfeidaujoined
22:11:29  <isaacs>ok, sweet
22:11:44  <isaacs>i'm seeing a reduction from ~9-10kq/s down to ~6kq/s
22:13:01  * felixgejoined
22:13:01  * felixgequit (Changing host)
22:13:01  * felixgejoined
22:13:54  <isaacs>arg. i keep clobbering my output before saving it somewhere :)
22:16:43  * warzjoined
22:16:43  * warzquit (Changing host)
22:16:43  * warzjoined
22:17:47  <piscisaureus_>isaacs: so you are probably on slower hardware; the relative drop is the same
22:18:06  <isaacs>yep
22:18:11  <isaacs>piscisaureus_: this is for /bytes/1
22:18:21  <isaacs>so there's a lot more "IncomingMessage" relevance
22:18:28  <isaacs>since there's less time spent just sendin bytes.
22:18:39  <isaacs>makes sense that creating more objects has more of an impact in this case.
22:18:47  <isaacs>http://static.izs.me/http-streams2-small.svg vs http://static.izs.me/http-streams1-small.svg
22:19:15  <isaacs>for some reason, it's dropping a frame where we call Date.now() in timers.active()
22:21:03  <piscisaureus_>hey sblom
22:21:10  <piscisaureus_>where do I get this "xperf" tool
22:21:21  <piscisaureus_>claudio's blog seems to imply that it ships with vs - but it doesn't
22:23:38  <piscisaureus_>also this is where windows really really needs a package manager...
22:28:11  * felixgequit (Quit: felixge)
22:34:10  * brsonjoined
22:35:25  * loladiroquit (Quit: loladiro)
22:35:31  * c4miloquit (Remote host closed the connection)
22:36:12  * brsonquit (Client Quit)
22:36:28  * brsonjoined
22:44:42  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:51:51  * loladirojoined
22:54:31  * warzquit
22:57:18  * piscisaureus_joined
23:03:30  <sblom>piscisaureus_: xperf comes in recent Windows SDKs.
23:03:35  <sblom>Probably Windows 7 and up.
23:04:15  <sblom>There are a few Windows package manager projects that I know of. I think Choclatey is the closest to being useful in this context.
23:04:43  <sblom>I doubt there's an xperf package for it, though.
23:06:14  <sblom>piscisaureus_: http://msdn.microsoft.com/en-us/performance/cc825801.aspx
23:08:55  <piscisaureus_>sblom: thanks
23:09:08  <piscisaureus_>claudio's blog post should probably mention that :-)
23:09:48  * bradleymeckjoined
23:10:02  <sblom>Yeah--will fix that.
23:10:08  <sblom>piscisaureus_ ^
23:10:22  <piscisaureus_>sblom: great!
23:10:30  <sblom>We actually double-checked that it ships with VS. I think we must have some version qualifiers required.
23:10:40  <sblom>Remind me--are you on VS2010 or VS2012 mostly?
23:10:46  <piscisaureus_>2010 ultimate
23:10:50  <sblom>Okay.
23:11:03  <piscisaureus_>should I be using 2012?
23:11:05  <sblom>That helps me narrow down what version qualifiers we need--thanks.
23:11:21  <piscisaureus_>well I suppose that means people need 2012
23:11:26  <sblom>Nah.
23:11:34  <sblom>This is available separately.
23:11:46  <sblom>We just need to find the best download link to include.
23:12:41  <sblom>I hope it's included in VS 2012 Express, but may require Pro (is there even Standard any more?). Marketers make things so complicated.
23:12:54  <piscisaureus_>haha
23:12:58  <sblom>Bottom line is that _anyone_ can download the SDK for free.
23:13:05  <piscisaureus_>yeah
23:13:09  <sblom>Thanks for the feedback.
23:13:32  <piscisaureus_>sblom: np
23:13:38  <piscisaureus_>ok, the devil is going offline again
23:13:45  <piscisaureus_>life is so complicated these days
23:13:48  <isaacs>piscisaureus_: so, i reclaimed ~ half of the speed mostly by removing some asserts and checks, and providing a custom "dump" method on IncomingMessage's
23:13:59  <piscisaureus_>isaacs: well, +1
23:14:07  <isaacs>piscisaureus_: the other obv low-hanging fruit is addHeaderLine
23:14:11  <isaacs>which is just obnoxious
23:14:14  <piscisaureus_>isaacs: so we're now looking at "just" 20% reduction?
23:14:20  <isaacs>hah, yeah
23:14:26  <isaacs>~that
23:14:41  <isaacs>(dump coming)
23:14:42  <piscisaureus_>isaacs: to be honest, I looked into it for half an hour this afternoon
23:14:46  <isaacs>current master:
23:14:48  <isaacs>Requests per second: 5953.56 [#/sec] (mean)
23:14:48  <isaacs>Requests per second: 6320.81 [#/sec] (mean)
23:14:48  <isaacs>Requests per second: 5669.92 [#/sec] (mean)
23:14:48  <isaacs>Requests per second: 6275.58 [#/sec] (mean)
23:14:50  <isaacs>Requests per second: 6464.92 [#/sec] (mean)
23:14:53  <isaacs>Requests per second: 6644.70 [#/sec] (mean)
23:14:55  <isaacs>Requests per second: 6349.81 [#/sec] (mean)
23:14:58  <isaacs>Requests per second: 6656.15 [#/sec] (mean)
23:15:00  <isaacs>streams2-http-speed:
23:15:05  <isaacs>Requests per second: 7845.10 [#/sec] (mean)
23:15:06  <isaacs>Requests per second: 7988.91 [#/sec] (mean)
23:15:06  <isaacs>Requests per second: 7854.21 [#/sec] (mean)
23:15:06  <isaacs>Requests per second: 7757.30 [#/sec] (mean)
23:15:08  <isaacs>Requests per second: 7996.33 [#/sec] (mean)
23:15:11  <isaacs>Requests per second: 8030.32 [#/sec] (mean)
23:15:13  <isaacs>Requests per second: 7649.25 [#/sec] (mean)
23:15:16  <isaacs>Requests per second: 7280.38 [#/sec] (mean)
23:15:18  <isaacs>Requests per second: 6639.70 [#/sec] (mean)
23:15:21  <isaacs>Requests per second: 7696.23 [#/sec] (mean)
23:15:38  <isaacs>and ./node-77ed12f is 9500 +-500
23:16:21  <isaacs>(dump completed)
23:16:33  <isaacs>piscisaureus_: you looked into what, exactly?
23:16:35  <piscisaureus_>isaacs: I think that there is a lot of room for improvement in the http area. V8 seems very busy with optimizing the same closure over and over again, it may be beneficial to use prototype methods
23:17:01  <piscisaureus_>isaacs: this is not specific to master or streams2, the same happens with 0.8
23:17:10  <isaacs>piscisaureus_: yeah, i'm manually binding the readableState.onread() and readableState.onwrite()
23:17:23  <isaacs>piscisaureus_: also, we have a shit ton of closures on the parser object methods
23:17:27  <piscisaureus_>yeah
23:17:38  <isaacs>piscisaureus_: i really am trying hard to avoid a full on http.js rewrite here.
23:17:40  <isaacs>it needs it bad.
23:17:42  <piscisaureus_>isaacs: so the good news is that probably we can make up for the speed loss
23:17:52  <piscisaureus_>isaacs: by fixing unrelated stuff ...
23:17:55  <isaacs>ah
23:17:57  <isaacs>haha
23:18:03  <isaacs>also, we'll be updating v8 soon.
23:18:06  <isaacs>so thatmight make things faster.
23:18:09  <isaacs>and then we can take credit for it.
23:18:14  <piscisaureus_>ghe haha
23:18:18  <piscisaureus_>well don't get your hopes up
23:18:20  <isaacs>"Streams2: Does more work, at twice the speed!"
23:18:40  <isaacs>"Node overclocks your processors for webscale asynchrony!"
23:19:07  <isaacs>but yeah, we need to keep our side of the house cleaner.
23:19:11  <isaacs>for sure
23:19:13  <piscisaureus_>isaacs: historical data shows that v8 upgrades can go both ways
23:19:17  <isaacs>true that
23:19:17  <CoverSlide>are the buffer sizes equal? that might skew performance
23:19:35  <isaacs>CoverSlide: it's apples to apples, yes.
23:19:39  <CoverSlide>ok
23:19:45  <isaacs>CoverSlide: streams2 just does more stuff, is all.
23:19:52  <isaacs>and the code is written to be sensible, not optimized.
23:19:58  <isaacs>so now i'm making it non-sensible so that it goes fast.
23:20:03  <isaacs>it's sad, but it's life.
23:20:05  <CoverSlide>aight
23:20:18  <piscisaureus_>but as I said
23:20:28  <piscisaureus_>sorry for being so node-lazy lately. Have to go
23:20:33  <isaacs>no problem.
23:20:37  <isaacs>piscisaureus_: thanks for your help, have a good night
23:20:39  <piscisaureus_>well it is :-)
23:20:54  * loladiroquit (Quit: loladiro)
23:21:12  <piscisaureus_>but reality is sometimes more complicated
23:21:15  <piscisaureus_>tty soon
23:21:19  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:42:34  * TooTallNatequit (Quit: Computer has gone to sleep.)