00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:07:24  <mordy_>hrm, another question. do i need to uv_close a uv_async_t?
00:08:35  <bnoordhuis>mordy_: yes
00:08:54  <bnoordhuis>just make sure the other thread isn't using it anymore
00:10:55  <mordy_>bnoordhuis: hrm, just making sure. i can use uv_async if i only want to have a function called once the event loop regains control?
00:11:05  <mordy_>i see a lot of words abotu threads in the header
00:11:48  <bnoordhuis>mordy_: uv_async is for when you have another thread (or maybe a signal handler) that does whatever
00:12:25  <bnoordhuis>and you want the thread to be able to wake up the main thread from uv_run
00:13:09  <bnoordhuis>common usage looks something like this: uv_async_init(...); pthread_create(...); uv_run(...)
00:13:15  <mordy_>ahhh
00:13:27  <mordy_>no, i need something more like ev_feed
00:13:48  * mikealquit (Quit: Leaving.)
00:13:51  <bnoordhuis>you want to artificially make a handle 'ready'?
00:15:37  <mordy_>yes. more specifically, i have an error handler which needs to be invoked (this is passed into me as a callback), and i want to only invoke the callback when the user doesn't have control of the event loop
00:16:34  <mordy_>i guess i can use prepare/check for this, but then it gets complicated
00:17:18  <bnoordhuis>hm, not sure i'm following
00:17:52  <bnoordhuis>you have a callback but you only want to call (have it called?) when inside uv_run?
00:18:00  <mordy_>yes
00:18:19  * st_lukequit (Remote host closed the connection)
00:18:33  <bnoordhuis>when exactly should it get called? what's stopping you from calling it whenever?
00:18:39  <bnoordhuis>(trying to understand the issue)
00:20:57  <mordy_>bnoordhuis: the library i'm using has a distinct guarantee that its own callbacks are only invoked when the user does not have control of its event loop (i.e. it has specific wrappers for starting and stopping the event loop)...
00:21:22  <mordy_>and basically it can't invoke its callbacks (which the user defines for it) unless the 'start' function has been called
00:21:48  * kazuponjoined
00:21:50  <mordy_>now if i call that library's callback, it might invoke the user's callback, etc. etc.
00:22:31  <mordy_>and then nasty things can happen, for example the library freeing something from within the callback while it is still in scope in the user code
00:22:49  <mordy_>i'm dealing with like four layers here, so i can elaborate more if needed
00:23:02  <bnoordhuis>i... think i follow :)
00:23:21  <bnoordhuis>you basically want to run on a fresh stack each time?
00:23:26  <mordy_>exactly
00:23:35  <bnoordhuis>you probably want an idle handle
00:23:48  <bnoordhuis>that defers the action to the next tick of the event loop
00:24:01  <bnoordhuis>with the guarantee that the loop won't block in epoll_wait/kevent/etc.
00:24:57  <bnoordhuis>idle handle == uv_idle_t in case there's any confusion
00:26:05  * kazuponquit (Ping timeout: 252 seconds)
00:26:19  <mordy_>ok, let's tryt his
00:26:20  <mordy_>this
00:28:47  <isaacs>bnoordhuis: hey, this bug 5504
00:28:52  <isaacs>bnoordhuis: where hte EOF busy-loops
00:29:00  <isaacs>bnoordhuis: were you able to reproduce this on linux? i can't seem to.
00:29:06  <isaacs>bnoordhuis: using the test case posted in the comments.
00:30:33  * st_lukejoined
00:32:00  <bnoordhuis>isaacs: no, it never triggers for me
00:32:10  <bnoordhuis>but the strace log the guy posted looks legitimate
00:33:28  <tjfontaine>do we know which kernel he's on? the default centos version?
00:33:42  <bnoordhuis>2.6.18 iirc
00:33:49  <bnoordhuis>but let me check that
00:34:45  <bnoordhuis>CentOS 6.3, kernel version 2.6.32-279.14.1.el6.x86_64
00:34:55  * AvianFlujoined
00:35:01  <bnoordhuis>that's like modern, by centos standards
00:35:06  <tjfontaine>right
00:35:13  <isaacs>Linux 7527bd77-ab3e-474b-ace7-eed6053931e7 3.1.10joyent-ubuntu-10-opt #1 SMP Fri Jan 20 09:55:31 PST 2012 x86_64 GNU/Linux
00:36:12  <bnoordhuis>btw, https://github.com/joyent/node/issues/5108#issuecomment-16960802
00:36:28  <bnoordhuis>the fact that he hits the assertion means node doesn't close the handle
00:36:38  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:37:54  * timoxleyjoined
00:41:36  <isaacs>bnoordhuis: if this is in fact a bug in Node's js layer, and not in libuv, then why the OS/kernel specificity?
00:41:45  <isaacs>bnoordhuis: that seems odd to me
00:42:48  <bnoordhuis>isaacs: i don't know, maybe it's just coincidence
00:43:01  <bnoordhuis>at least one guy reported the same issue but on debian
00:43:04  <isaacs>right
00:43:08  <isaacs>but i can't reproduce it on debian
00:43:13  <isaacs>or on smartos, or osx
00:43:14  <tjfontaine>which could just as easily had an ancient kernel
00:43:17  <isaacs>right
00:43:26  <isaacs>it sounds like a "old linux kernel" bug
00:43:37  <isaacs>not necessarily a specific distro or whatever.
00:43:56  <bnoordhuis>could be
00:44:08  <bnoordhuis>hm, debian 6... that's also 2.6.32 iirc
00:45:29  <bnoordhuis>still, could be coincidence - and there's that assertion that got hit
00:45:51  <bnoordhuis>even if there is a kernel bug, there's still a bug in node as well :)
00:46:10  <tjfontaine>well, it's certainly somethign easier to trip on older kernels
00:46:33  <tjfontaine>I'd also be curious to know if they are tripping on bare metal or under virtualization
00:46:59  <bnoordhuis>both, according to #5108. there are mentions of both bare metal and openvz
00:47:22  * piscisaureus_quit (Ping timeout: 276 seconds)
00:47:26  <tjfontaine>well, openvz is close enough to bare metal for this case, certainly no xen/kvm/vmware in the mix
00:47:29  <bnoordhuis>openvz is not hardware virtualization however
00:48:02  <bnoordhuis>it's more like lxc or solaris zones
00:48:50  <tjfontaine>right so it's possible that such a rare bug is even harder to hit in [para]virtualization
00:49:45  <bnoordhuis>that's quite possible, yes
00:50:14  * dshaw_quit (Quit: Leaving.)
00:51:15  * TooTallNatejoined
00:58:48  * amartensquit (Quit: Leaving.)
00:59:31  * st_lukequit (Remote host closed the connection)
01:04:02  * st_lukejoined
01:05:36  * bnoordhuisquit (Read error: Operation timed out)
01:05:45  <isaacs>Well, this is pretty weird...
01:06:04  <isaacs>if the server writes a really big buffer, then a node client sends it an ECONNRESET
01:06:12  <isaacs>even if ou don't destroy from the client
01:13:56  * indexzerojoined
01:15:19  <isaacs>ircretary: tell bnoordhuis Check this out: https://github.com/joyent/node/issues/5542
01:15:20  <ircretary>isaacs: I'll be sure to tell bnoordhuis
01:16:07  * inolenquit (Quit: Leaving.)
01:21:52  * skebcioquit (Read error: Operation timed out)
01:22:09  * kazuponjoined
01:25:28  * TooTallNatequit (Read error: Connection reset by peer)
01:25:34  * dap1quit (Quit: Leaving.)
01:26:16  * indexzeroquit (Quit: indexzero)
01:27:06  * kazuponquit (Ping timeout: 240 seconds)
01:31:11  * skebciojoined
01:32:54  * indexzerojoined
01:39:55  * stagasquit (Remote host closed the connection)
01:47:04  * indexzeroquit (Quit: indexzero)
01:54:00  * piscisaureus_joined
01:59:30  * defunctzombie_zzchanged nick to defunctzombie
01:59:55  * piscisaureus_quit (Ping timeout: 264 seconds)
02:09:52  * st_lukequit (Remote host closed the connection)
02:12:55  * skebcio_joined
02:12:59  * skebcioquit (Read error: Connection reset by peer)
02:13:56  * bnoordhuisjoined
02:16:44  * indexzerojoined
02:17:34  * dannycoateschanged nick to dannycoates|afk
02:18:28  * skebcio_quit (Ping timeout: 240 seconds)
02:18:47  * bnoordhuisquit (Ping timeout: 260 seconds)
02:20:49  * defunctzombiechanged nick to defunctzombie_zz
02:21:44  * skebciojoined
02:21:58  * indexzeroquit (Quit: indexzero)
02:22:48  * indexzerojoined
02:23:16  * dannycoates|afkquit (Remote host closed the connection)
02:25:02  * defunctzombie_zzchanged nick to defunctzombie
02:26:01  * AvianFluquit (Remote host closed the connection)
02:26:59  * indexzeroquit (Client Quit)
02:32:41  * brsonquit (Quit: leaving)
02:33:38  * amartensjoined
02:33:55  * TooTallNatejoined
02:35:21  * defunctzombiechanged nick to defunctzombie_zz
02:38:23  * amartensquit (Ping timeout: 260 seconds)
02:50:07  * inolenjoined
02:52:26  * loladirojoined
02:52:51  * loladiroquit (Client Quit)
02:55:45  * kazuponjoined
03:00:55  * kazuponquit (Ping timeout: 252 seconds)
03:14:56  * wmiljoined
03:17:25  * loladirojoined
03:27:13  * AvianFlujoined
03:28:31  * st_lukejoined
03:33:59  * amartensjoined
03:38:09  * amartensquit (Ping timeout: 248 seconds)
03:38:24  * timoxleyquit (Quit: Computer has gone to sleep.)
03:43:21  * loladiroquit (Quit: loladiro)
03:45:06  * wmilquit (Remote host closed the connection)
03:47:11  * brsonjoined
03:54:58  * kazuponjoined
03:55:17  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:56:06  * indexzerojoined
04:11:04  * wmiljoined
04:18:55  * st_lukequit (Remote host closed the connection)
04:20:27  * indexzeroquit (Quit: indexzero)
04:22:15  * wmilquit (Remote host closed the connection)
04:23:06  * timoxleyjoined
04:24:06  * indexzerojoined
04:24:58  * timoxleyquit (Read error: Connection reset by peer)
04:29:51  * amartensjoined
04:32:47  * normanmjoined
04:34:33  * indexzeroquit (Quit: indexzero)
04:36:53  * brsonquit (Ping timeout: 248 seconds)
04:38:24  * timoxleyjoined
04:38:52  * brsonjoined
04:45:19  * benoitcquit (Ping timeout: 260 seconds)
04:49:55  * timoxleyquit (Read error: Connection reset by peer)
04:50:33  * AvianFluquit (Remote host closed the connection)
04:52:55  * timoxleyjoined
04:58:30  * wmiljoined
05:00:48  * wmilquit (Remote host closed the connection)
05:03:20  * timoxleyquit (Read error: Connection reset by peer)
05:06:37  * timoxleyjoined
05:09:20  * indexzerojoined
05:11:23  * timoxleyquit (Read error: Connection reset by peer)
05:12:17  * indexzeroquit (Client Quit)
05:16:52  * TooTallNatejoined
05:21:17  * timoxleyjoined
05:27:21  * st_lukejoined
05:27:38  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:37:27  * AvianFlujoined
05:47:18  * TooTallNatejoined
05:48:35  * TooTallNatequit (Client Quit)
05:53:28  * bajtosjoined
05:57:35  * mikealjoined
05:57:35  * mikealquit (Client Quit)
06:00:10  * mikealjoined
06:07:10  * st_lukequit (Remote host closed the connection)
06:34:26  * rendarjoined
06:59:11  * amartensquit (Quit: Leaving.)
06:59:11  * `3rdEdenjoined
07:26:31  * timoxleyquit (Quit: Computer has gone to sleep.)
07:26:44  * juliangruberquit (Read error: Operation timed out)
07:28:28  * juliangruberjoined
07:37:09  * brsonquit (Quit: leaving)
07:39:54  * loladirojoined
07:40:29  * paddybyersjoined
07:56:19  * txdvquit (Ping timeout: 264 seconds)
08:01:38  * benoitcjoined
08:17:00  * stagasjoined
08:29:53  * dominictarrjoined
08:47:05  * piscisaureus_joined
08:47:20  * hzjoined
08:57:36  * dominictarrquit (Quit: dominictarr)
09:04:38  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
09:19:21  * kazuponquit (Remote host closed the connection)
09:22:48  * kazuponjoined
09:24:58  * jez0990_changed nick to jez0990
09:26:38  * kazuponquit (Remote host closed the connection)
09:31:29  * piscisaureus_joined
09:32:22  * txdvjoined
10:00:13  * bajtosquit (Quit: bajtos)
10:21:39  * kazuponjoined
10:29:43  * kazuponquit (Ping timeout: 240 seconds)
10:40:13  * kazuponjoined
10:41:04  * dominictarrjoined
10:42:21  * bnoordhuisjoined
10:49:15  * dominictarrquit (Quit: dominictarr)
10:49:48  * dominictarrjoined
11:21:52  * dominictarrquit (Quit: dominictarr)
11:22:06  * dominictarrjoined
11:22:06  * dominictarrquit (Client Quit)
11:31:05  * stagasquit (Read error: Connection reset by peer)
11:40:38  * timoxleyjoined
12:00:50  * bajtosjoined
12:15:07  <saghul>hi! I noticed the error handling in case a stream is not bound is a bit inconsistent: on write EBADF is returned, but read_start or shutdown assert, would a PR failing gracefully be ok?
12:15:15  <saghul>bnoordhuis piscisaureus_ ^
12:15:31  <saghul>(I only checked unix)
12:20:46  <bnoordhuis>saghul: not bound? you mean not connected?
12:21:17  <saghul>bnoordhuis it doesn't have a fd yet, so not connected, not listening, not anything
12:22:20  <bnoordhuis>i lean more towards making uv_write() assert in that case
12:22:34  <bnoordhuis>because it's obviously an application bug
12:23:56  <saghul>I know, but this means the application need to keep some state in order to give an error to the user, aborting is a bit abrupt
12:24:19  <saghul>in pyuv I can convert errors to exceptions, but asserts kind of kill me
12:24:54  <bnoordhuis>well, that's the idea :)
12:26:33  <saghul>well, and what happens in release mode?
12:28:20  <saghul>let me change the question :-) what is the policy regarding asserts in libuv? what errors should assert and which should return -1 and set the error in the loop?
12:28:44  <bnoordhuis>saghul: runtime errors should (and do) set an error
12:28:55  <bnoordhuis>application bugs should, in general, assert
12:31:27  <saghul>I see. In python aborting is not usually nice, but I guess it have to live with that
12:32:45  * kazuponquit (Remote host closed the connection)
12:33:03  <bnoordhuis>saghul: you can track the state and intercept the call to uv_write() in your bindings
12:33:19  <bnoordhuis>but i'm not telling you anything you didn't already know, i bet :)
12:33:27  <saghul>bnoordhuis :-)
12:33:38  <piscisaureus_>bnoordhuis: I would say in the particular case, ENOTCONN
12:33:51  <piscisaureus_>it's a bit of *shrug* though
12:34:55  <piscisaureus_>bnoordhuis: The problem with asserting in these cases is that you can't really offer low-level bindings for libuv if it is that zealous
12:35:15  <piscisaureus_>bnoordhuis: because the bindings
12:35:19  <piscisaureus_>er
12:35:44  <piscisaureus_>because "user" the bindings might do stupid things but the assert error doesn
12:35:51  <piscisaureus_>'t make sense to him/her
12:35:58  <txdv>https://code.google.com/p/v8/source/browse/branches/3.0/src/api.cc#1294
12:36:40  <saghul>reading the Doom 3 code review post eh ;-)
12:36:44  <saghul>piscisaureus_ exactly!
12:36:59  <txdv>yeah
12:37:25  <txdv>he bashed v8 code so I found it funny
12:43:43  * hzquit (Ping timeout: 264 seconds)
12:46:51  * loladiro_joined
12:48:02  * loladiroquit (Ping timeout: 256 seconds)
12:50:15  * loladirojoined
12:51:17  * loladiro_quit (Ping timeout: 248 seconds)
12:55:14  * dominictarrjoined
13:05:20  * timoxleyquit (Quit: Computer has gone to sleep.)
13:08:16  * loladiroquit (Read error: Connection reset by peer)
13:09:06  * loladirojoined
13:09:18  * hzjoined
13:09:19  * hzquit (Changing host)
13:09:19  * hzjoined
13:11:10  * c4milojoined
13:14:01  * AvianFluquit (Remote host closed the connection)
13:16:09  * AvianFlujoined
13:30:16  * pachetjoined
13:30:16  * pachetquit (Changing host)
13:30:16  * pachetjoined
13:32:04  * loladiro_joined
13:33:25  * loladiroquit (Ping timeout: 248 seconds)
13:33:25  * loladiro_changed nick to loladiro
13:40:47  * hz_joined
13:40:47  * hz_quit (Changing host)
13:40:47  * hz_joined
13:40:47  * hzquit (Disconnected by services)
13:40:52  * hz_changed nick to hz
13:41:01  * dominictarrquit (Quit: dominictarr)
13:43:12  * kazuponjoined
13:45:26  <bnoordhuis>txdv: what am i looking at? or rather, what's the context?
13:45:42  <txdv>that c++ can make your eyes bleed
13:45:52  <txdv>that is what the author of the doom3 review said about this code
13:46:30  <bnoordhuis>guess he's never taken a look at just about any boost code
13:47:01  <txdv>What is the goal of boost?
13:47:22  <txdv>creating an abstraction of everything known to humanity?
13:48:08  <bnoordhuis>purportedly it's to make life easier for c++ programmers
13:48:09  <pachet>the goal is to boost
13:48:10  <pachet>all the things
13:48:49  * kazuponquit (Ping timeout: 252 seconds)
13:52:12  * loladiro_joined
13:53:12  * bnoordhuisquit (Ping timeout: 256 seconds)
13:55:28  * loladiroquit (Ping timeout: 256 seconds)
13:55:28  * loladiro_changed nick to loladiro
14:02:37  * kevinswiberjoined
14:05:47  <saghul>LoL http://www.cdecl.org/?utm_source=buffer&utm_medium=twitter&utm_campaign=Buffer&utm_content=buffera00a8
14:10:40  * loladiro_joined
14:12:04  * loladiroquit (Ping timeout: 276 seconds)
14:17:25  * loladiro_quit (Ping timeout: 252 seconds)
14:20:46  <txdv>Can I cancel a connection request?
14:29:17  <saghul>txdv IIRC no, only getaddrinfo, fs and work request are cancelable atm
14:29:23  <saghul>*requests
14:29:50  <txdv>so no timeout for connection?
14:31:25  * AvianFluquit (Remote host closed the connection)
14:32:11  * loladirojoined
14:36:34  * loladiroquit (Client Quit)
14:36:53  * loladirojoined
14:39:11  <saghul>txdv since you can't really reuse a handle once you have failed to connect you can uv_close() it on timeout and create a new one
14:40:00  <saghul>txdv: https://groups.google.com/d/msg/libuv/MdU5m_xk3qo/xT6D3TFswWkJ
14:43:23  <txdv>saghul: i just figured out that I can simulate blocking connect calls and stuff
14:44:03  <saghul>by await-ing the connect callback?
14:44:42  <txdv>running the event loop with run_once until the callback is called
14:45:09  <saghul>aha
14:45:47  * loladiro_joined
14:46:12  <txdv>now i am like implementing all blocking C# interfaces
14:46:31  * loladiroquit (Ping timeout: 276 seconds)
14:46:31  * loladiro_changed nick to loladiro
14:50:45  * dapjoined
14:52:07  <isaacs>good morning
14:56:12  * bnoordhuisjoined
14:58:45  <saghul>txdv that's what I did here: https://github.com/saghul/evergreen but using coroutines to 'wait' for callbacks
15:02:13  * bajtosquit (Quit: bajtos)
15:06:49  * defunctzombie_zzchanged nick to defunctzombie
15:11:27  * groundwaterjoined
15:14:03  <isaacs>bnoordhuis: ping
15:14:17  <isaacs>bnoordhuis: so, this "large write reset" thing is really weird
15:14:24  <isaacs>bnoordhuis: if the other side is going away withotu closing the connection... why?
15:14:35  <isaacs>bnoordhuis: i mean, the other side is node. i didn't call socket.destroy. so... wtf?
15:15:19  <bnoordhuis>isaacs: pong
15:15:32  <bnoordhuis>there might be something wrong with the test
15:15:45  <bnoordhuis>it sometimes hangs, at other times it fails with that ECONNRESET error
15:16:29  <isaacs>bnoordhuis: hanging is correct behavior.
15:16:40  <isaacs>bnoordhuis: because i've taken out the bits where i was actually doing asserts and such
15:16:43  <isaacs>and closing the server
15:16:59  <isaacs>bnoordhuis: i get ECONNRESET every time
15:17:09  <isaacs>but i'm definitely NOT ever explicitly trying to close the socket from the client side.
15:17:10  <bnoordhuis>on what os are you testing it?
15:17:12  <isaacs>os x
15:17:17  <isaacs>but same behavior on ubuntu
15:17:28  * mikealquit (Quit: Leaving.)
15:17:31  <bnoordhuis>try running it through `strace -f`
15:17:46  <bnoordhuis>that makes it hang for me about once every 3, 4 runs
15:18:13  <isaacs>huh
15:18:40  <bnoordhuis>back in a bit, pizza's ready :)
15:18:43  <isaacs>bnoordhuis: so, question remains... how come the socket is getting closed?
15:18:46  <isaacs>ah, enjoy :)
15:19:38  <txdv>saghul: yeah, I did it with coroutines too
15:19:48  <txdv>but
15:19:59  <txdv>i mean you can just keep spinning the event loop while waiting for an event
15:20:11  <txdv>it will handle all the other stuff events derived from the event loop
15:20:23  <txdv>but will basically block the real thread until it is done
15:21:32  <isaacs>bnoordhuis: same behavior on smartos
15:21:37  <isaacs>bnoordhuis: and strace-f has no change for me.
15:21:51  <isaacs>bnoordhuis: I think this is a bug in the client, dropping the connection when it should not
15:22:26  <mordy_>another sanity check here. none of uv's callbacks (i.e. for read, write, etc.) will ever be invoked until after control is returned to uv_run, right?
15:22:51  <piscisaureus_>mordy_: yes
15:25:56  * defunctzombiechanged nick to defunctzombie_zz
15:28:56  * dapquit (Quit: Leaving.)
15:31:57  <isaacs>this is so bizarre..
15:33:07  * timoxleyjoined
15:34:28  <isaacs>ohhhh.... the client socket isn't keeping the event loop open.
15:35:08  <isaacs>well that's strange.
15:36:18  <isaacs>BUT! the client *definitely* is in process._getActiveHandles
15:36:20  * travis-cijoined
15:36:20  <travis-ci>[travis-ci] wwwouter/node#6 (master - b09fccc : wwwouter): The build is still failing.
15:36:20  <travis-ci>[travis-ci] Change view : https://github.com/wwwouter/node/compare/c1ed72d5d8c1...b09fccc0cdef
15:36:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/wwwouter/node/builds/7466024
15:36:20  * travis-cipart
15:36:29  <isaacs>bnoordhuis, piscisaureus_: I don't see how this can not be a bug.
15:36:37  <isaacs>i'll write a sipmler test for it.
15:37:02  * stagasjoined
15:38:12  * kazuponjoined
15:48:26  * txdvquit (Ping timeout: 252 seconds)
15:49:58  <isaacs>https://gist.github.com/isaacs/5644453
15:54:08  * mikealjoined
15:56:35  <isaacs>ugh, who's travis-ci is that?
15:58:17  <MI6>joyent/node: isaacs master * 9c7078c : Remove .travis.yml file. - http://git.io/Pmzl8g
15:58:35  * `3rdEdenquit (Remote host closed the connection)
16:00:11  <isaacs>problem solved!
16:00:11  <isaacs>16:00 -ChanServ(ChanServ@services.)- AKICK list for #libuv:
16:00:11  <isaacs>16:00 -ChanServ(ChanServ@services.)- 1: travis-ci!*@* (too noisy) [setter: isaacs, modified: 12 seconds]
16:00:13  <isaacs>16:00 -ChanServ(ChanServ@services.)- Total of 1 entry in #libuv's AKICK list.
16:00:19  * c4miloquit (Remote host closed the connection)
16:00:24  <isaacs><3 travis, but man... there's just no reason for that.
16:00:31  <isaacs>node will never ever pass tests on travis
16:00:39  <isaacs>and we have MI6 and Jankins already.
16:03:02  * leonvvjoined
16:04:59  <mordy_>is it safe to call uv_read_stop twice on the same handle?
16:05:35  * defunctzombie_zzchanged nick to defunctzombie
16:06:50  <mordy_>also, i'm assuming uv_poll just uses select() on windows, right?
16:08:51  <MI6>nodejs-master: #234 UNSTABLE smartos-x64 (5/600) smartos-ia32 (2/600) http://jenkins.nodejs.org/job/nodejs-master/234/
16:09:04  * dapjoined
16:09:18  * TooTallNatejoined
16:12:04  <piscisaureus_>mordy_: yes twice is safe
16:12:38  * defunctzombiechanged nick to defunctzombie_zz
16:12:39  <piscisaureus_>mordy_: re select - sometimes, but most of the times it uses something more scalable
16:13:14  * qardjoined
16:14:43  <isaacs>piscisaureus_: so, just to sanity check... if a socket isn't reading, and isn't writing, but it's connected, it should hold the event loop open, right?
16:14:55  <piscisaureus_>isaacs: no
16:14:57  <isaacs>piscisaureus_: or does there have to be an active read or write?
16:15:13  <piscisaureus_>isaacs: well yes. but sockets usually have an active read or write
16:15:17  <isaacs>even if it's in _getActiveHandles?
16:15:27  <isaacs>piscisaureus_: well... what if it doesn't :)
16:16:00  <isaacs>socket.pause(); setTimeout(function() { socket.resume() }).unref();
16:16:04  <isaacs>^ closes node
16:16:20  <isaacs>very surprising
16:16:21  <piscisaureus_>isaacs: well so the libuv will exit if there is never any callback that could be happening.
16:16:34  <leonvv>Does anyone have a libuv tutorial, which is not outdated ?
16:16:45  <mordy_>hrm, another question (so many questions) - pending read/write callbacks on a uv_close(stream) will get invoked before the close callback, right?
16:16:45  <isaacs>i've gotta run. i'll be back in a few hours, and then nodeup.
16:16:50  <bnoordhuis>leonvv: most of what's i uvbook is still accurate
16:16:53  <bnoordhuis>*in
16:16:57  <isaacs>piscisaureus_: this seems strange to me, though
16:16:58  <isaacs>bnoordhuis: ^
16:17:00  <piscisaureus_>isaacs: not surprising. If you pause a socket it will generate no more events.
16:17:19  <bnoordhuis>mordy_: yes, with status=-1 and error=UV_CANCELLED
16:17:21  <piscisaureus_>isaacs: only the timer will generate events but you've unref'ed it
16:17:26  <isaacs>piscisaureus_: right, but i might want to pass it to some other thing
16:17:39  <piscisaureus_>then why do you unref the timer for god's sake?
16:17:42  <bnoordhuis>haha
16:17:46  <isaacs>piscisaureus_: haha
16:17:59  <isaacs>piscisaureus_: it's a minified example of what i was doing
16:18:10  <isaacs>i was reading only part of the sent message, and then seeing the abrupt close.
16:18:31  <isaacs>and the server gets an ECONNRESET
16:18:35  <piscisaureus_>isaacs: well then you found a very tedious way of doing it wrong and reduced it to an easy case :-p
16:18:53  * isaacslate
16:18:59  <piscisaureus_>isaacs: full code?
16:18:59  <isaacs>we can discuss in a few hours, or another time, i guess.
16:19:05  <piscisaureus_>isaacs: gist me
16:19:11  <isaacs>pisc #5542
16:19:18  <isaacs>piscisaureus_: #5542 issue
16:19:20  <piscisaureus_>isaacs thanks
16:19:21  <piscisaureus_>go@
16:19:23  <piscisaureus_>run!!
16:19:24  * isaacs&
16:19:32  * defunctzombie_zzchanged nick to defunctzombie
16:20:42  <leonvv>bnoordhuis: thanks !
16:21:14  * kazuponquit (Remote host closed the connection)
16:25:00  <MI6>nodejs-master-windows: #43 UNSTABLE windows-x64 (15/600) windows-ia32 (16/600) http://jenkins.nodejs.org/job/nodejs-master-windows/43/
16:32:16  <mordy_>hrm. the read callback doesn't seem to ever get invoked once uv_close is called
16:32:51  <bnoordhuis>mordy_: oh sorry, i may have misread your question
16:33:11  * dannycoates|afkjoined
16:33:18  <bnoordhuis>mordy_: pending requests have their callbacks invoked, e.g. connect/write/shutdown
16:33:40  <bnoordhuis>but reading from a socket is not request based
16:33:44  <mordy_>but handle-level requests do not.. ahh
16:33:53  <trevnorris>you guys know how to do the equivalant of charCodeAt() in cc?
16:34:01  <bnoordhuis>trevnorris: on what?
16:36:34  <trevnorris>bnoordhuis: a string. basically right now fill pulls the char code then passes that to slowbuffer fill
16:37:12  <trevnorris>so \u0567 fills the buffer as 0x67
16:37:43  <bnoordhuis>trevnorris: c string or Handle<String>?
16:37:46  <piscisaureus_>ircretary: tell isaacs It Is Not A Bug
16:37:46  <ircretary>piscisaureus_: I'll be sure to tell isaacs
16:37:53  <trevnorris>bnoordhuis: but the new implementation on my buffer branch does a
16:37:57  <trevnorris>(Handle<String>)
16:38:07  <trevnorris>String::AsciiValue at(args[0])
16:38:19  <trevnorris>int value = (at*)[0];
16:38:31  <trevnorris>which would fill the buffer with 0xd5 instead
16:38:54  * timoxleyquit (Quit: Computer has gone to sleep.)
16:38:58  <bnoordhuis>that's because you're using AsciiValue
16:39:22  <mordy_>is there a simple way to determine if i have a read request active? or do i have to track this in my own code
16:39:26  <bnoordhuis>the bytes in the string will all be <=127
16:39:54  <bnoordhuis>there's Utf8Value but then you'll need to decode the utf-8 sequence
16:40:04  * kazuponjoined
16:40:22  <bnoordhuis>mordy_: well, if you call uv_read_start(), you're reading
16:40:36  <bnoordhuis>in that respect you need to keep track of it yourself
16:41:29  <trevnorris>bnoordhuis: right now fill doesn't check if the value's within 127, so in this case it'll do memset(<data>, 1383, <length>)
16:41:48  * leonvvquit (Remote host closed the connection)
16:42:07  * mikealquit (Quit: Leaving.)
16:43:10  <bnoordhuis>trevnorris: what i mean is that String::AsciiValue(s) converts s to a string that's all ascii
16:43:26  <bnoordhuis>i.e. if it contains non-ascii sequences, those will be brutally trimmed
16:43:43  * defunctzombiechanged nick to defunctzombie_zz
16:44:32  <tjfontaine>without remorse
16:44:40  <trevnorris>String::Utf8Value(s) returns the same value in this case (0xd5)
16:45:28  <trevnorris>hm. ok, right now writing a value over 127 isn't defined in the docs
16:45:57  <trevnorris>so is there a bigger solution to this problem?
16:46:19  <bnoordhuis>bigger or better?
16:46:41  <trevnorris>better
16:46:52  <tjfontaine>what about a bigger *and* better solution?
16:47:23  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:47:32  <bnoordhuis>bigger isn't that hard, it's always possible to write more code to solve the same problem
16:47:39  <bnoordhuis>ask any java enterprise programmer
16:47:44  <trevnorris>lol
16:48:34  <bnoordhuis>okay, let's recap: you have a Handle<String> and you want the char code of the first character. right?
16:48:35  <tjfontaine>FactoryReactorAbstractFinal
16:49:57  <trevnorris>bnoordhuis: well, guess that leads me back to if we care. if the user types in buf.fill('է') it can't write in that value anyways.
16:50:09  <trevnorris>so should we properly define overflow behavior?
16:50:56  * inolenquit (Quit: Leaving.)
16:51:04  * Raynosquit (Ping timeout: 246 seconds)
16:52:18  <bnoordhuis>trevnorris: just wrap around i guess?
16:52:37  <bnoordhuis>> var b = Buffer(4); b.fill('է'); b.toString()
16:52:37  <bnoordhuis>'gggg'
16:52:46  <bnoordhuis>kind of odd how that works...
16:52:59  <trevnorris>it's because they're passing a value larger than 127 to memset
16:53:14  <trevnorris>so I guess memset just wraps it around
16:53:33  <bnoordhuis>yeah, but 1383 & 255 == 103
16:54:31  <trevnorris>well. that's right.
16:54:37  <trevnorris>'g'.charCodeAt(0) == 103
16:55:17  <piscisaureus_>why does it even take a character? :-/
16:55:26  <piscisaureus_>what if you pass in 2?
16:56:21  <trevnorris>i dunno. all the docs say is "Fills the buffer with the specified value"
16:56:32  <bnoordhuis>it considers just the first character
16:56:33  <trevnorris>that leaves a lot of room for interpretation
16:56:47  <bnoordhuis>it calls Int32Value() internally
16:57:03  <bnoordhuis>which is weird as well, why Int32Value() rather than Uint32Value()
16:57:11  <bnoordhuis>maybe that code predates Uint32Value()
16:59:13  <trevnorris>bnoordhuis: i think it's because the memset docs say the second argument is an "int"
17:00:26  <piscisaureus_>bnoordhuis: trevnorris:
17:00:27  <piscisaureus_>> Buffer.prototype.fill = function(s) { var src = new Buffer('' + s); for (var i = 0; i < this.length; i++) this[i] = src[i % src.length]; }
17:00:27  <piscisaureus_>[Function]
17:00:27  <piscisaureus_>> var buf = new Buffer(100);
17:00:27  <piscisaureus_>undefined
17:00:27  <piscisaureus_>> buf.fill('bla')
17:00:27  <piscisaureus_>undefined
17:00:27  <piscisaureus_>> buf.toString()
17:00:28  <piscisaureus_>'blablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablablab'
17:00:28  <piscisaureus_>>
17:01:08  <piscisaureus_>I think that still matches what the docs say
17:01:49  <trevnorris>piscisaureus_: you'll have to throw in a case that calls memset if a number is passed, at the least
17:01:58  <trevnorris>or filling a large buffer will take too long
17:02:10  * amartensjoined
17:02:13  <piscisaureus_>haha
17:02:17  <piscisaureus_>I was also a bit kidding
17:02:22  <trevnorris>ah. heh.
17:02:25  <piscisaureus_>but sure
17:02:31  <trevnorris>sorry, only got 4 hours of sleep last night.
17:03:21  * TooTallNatejoined
17:03:49  <trevnorris>ok. so seems there are a couple solutions. since this is way more philosophical than I thought it'd be, just going to leave it alone for now
17:18:55  * AvianFlujoined
17:28:35  <trevnorris>piscisaureus_: though I sorta like that idea. is there a way to rapidly duplicate a char* to some other memory?
17:28:54  * mikealjoined
17:29:39  <bnoordhuis>trevnorris: memcpy? or am i misunderstanding you?
17:30:44  <trevnorris>bnoordhuis: sorta. you'd have to for loop the memcpy to get a char* into another char* multiple times though, right?
17:32:00  <bnoordhuis>err... yes. i'm admittedly not sure what you're getting at
17:32:40  <trevnorris>how piscisaureus_ did the buf.fill('bla')
17:32:49  <trevnorris>buf.toString() = 'blabla...'
17:33:15  <trevnorris>couldn't we just take String::Utf8Value and duplicate the memory across the buffer?
17:33:16  * dapquit (Quit: Leaving.)
17:33:29  <bnoordhuis>oh, like that
17:33:32  * leonvvjoined
17:33:36  <bnoordhuis>yeah, you'd have to memcpy it repeatedly
17:34:09  <trevnorris>ok
17:34:23  <trevnorris>cool. i'm going to write up a quick something. see how this goes :)
17:34:41  <piscisaureus_>trevnorris: I think it's possible to make the js code quite performant though
17:34:56  <piscisaureus_>maybe with some small tweaks
17:37:27  <trevnorris>for sure.
17:40:06  * pachetquit (Read error: Operation timed out)
17:41:37  * inolenjoined
17:51:21  * brsonjoined
18:01:18  * `3rdEdenjoined
18:03:43  <trevnorris>bnoordhuis: this is what I was thinking of: https://github.com/trevnorris/node/commit/029f64c
18:08:31  * mjr__joined
18:09:46  * leonvvquit (Remote host closed the connection)
18:10:27  * mjr__quit (Client Quit)
18:10:49  * mjr__joined
18:18:09  <piscisaureus_>« The solution was: (Node leaving the cleartext socket open on error) »
18:18:09  <piscisaureus_>tls.on('clientError', function(e,p) {
18:18:09  <piscisaureus_> p.cleartext.socket.destroy();
18:18:09  <piscisaureus_> p.destroy();
18:18:09  <piscisaureus_>});
18:21:44  <mjr__>the oft-misunderstood "clientError" event.
18:24:07  * Raynosjoined
18:26:32  * loladiro_joined
18:27:29  * dapjoined
18:28:18  <bnoordhuis>how can tar not be installed on this fedora system?!
18:29:27  * loladiroquit (Ping timeout: 260 seconds)
18:29:28  * loladiro_changed nick to loladiro
18:31:50  <piscisaureus_>mjr__: you got me there. You have any idea why that is as it is?
18:35:00  <piscisaureus_>bnoordhuis: do you? ^
18:38:01  * pachetjoined
18:40:27  <mjr__>I don't know why you need it here. I just know that lots of people get confused by the clientError event.
18:41:11  <tjfontaine>I would suppose that because the client may choose to renegotiate without closing the connection
18:47:45  <isaacs>piscisaureus_: if ref'ed socket handles don't keep the event loop open, then what's the point of socket.unref()?
18:48:54  <piscisaureus_>isaacs: not keeping the loop alive over a socket that is active/connected (such as the connection to a logging backend. Or a built-in repl that people can telnet)
18:49:06  <piscisaureus_>isaacs: imagine a loop with just one socket.
18:49:21  <isaacs>you mean, so that we can shut down the process even if there IS a read happening?
18:49:22  <bnoordhuis>piscisaureus_: what is?
18:49:34  <piscisaureus_>the socket is bound. It's not connecting nor listening nor reading not writing nor ending
18:49:53  <isaacs>right
18:49:54  <piscisaureus_>isaacs: what will happen in that loop
18:49:58  <isaacs>so in that case, the loop has no work to do
18:50:05  <piscisaureus_>isaacs: btw - so yes that's the use case of unref
18:50:09  <isaacs>ok
18:50:21  <piscisaureus_>isaacs: yes, no work to do. Will it ever have work todo - no. It's just a hang
18:50:24  <isaacs>hm. seems like we could have done http keepalive a long time ago, though :)
18:50:34  <piscisaureus_>isaacs: this was the issue we had in 0.6
18:50:45  <piscisaureus_>so we did all this hairy ref() / unref() in the binding layer
18:50:45  <bnoordhuis>you speak of evil things, isaacs
18:51:16  <tjfontaine>we could have keepalive in 0.8, but timers don't have their unref exposed until 0.10
18:51:19  <isaacs>bnoordhuis: i am Neutral. I speak of evil as often as good, and regard both as arbitrary distinctions from reality, which is neither.
18:51:25  <piscisaureus_>isaacs: so in 0.8 we had refcount refactor, after which the loop will always exit if there is no more work ongoing and nothing going to happen
18:51:33  <isaacs>tjfontaine: oic, right, the timer.
18:51:39  <piscisaureus_>isaacs: and unref() just takes some handles out if the equation
18:51:45  <isaacs>ok
18:52:15  <isaacs>so, this is an edge case that probably no one will hit anyway. just got excited thinking it might be a clue to #5504
18:52:23  <piscisaureus_>isaacs: so that's why I say - unref'ing a timer is probably a bad idea.
18:52:41  <piscisaureus_>because it might exit node. If refcount semantics were as you propose, node would lock up.
18:52:46  * normanmquit (Quit: Computer has gone to sleep.)
18:52:47  <piscisaureus_>neither of them is really worse
18:52:51  <isaacs>piscisaureus_: well, it's important if you want to make sure that something else happens, withotu impacting whether it sticks around
18:53:11  <isaacs>piscisaureus_: or if you want to firebomb the process if something doesn't happen within a second, withtout staying open for a second, etc.
18:53:23  <isaacs>testing for graceful closes, etc.
18:54:12  <piscisaureus_>isaacs: well that's what you got here.
18:54:21  <isaacs>yeah, i get it now
18:54:32  <isaacs>i agree, this is correct.
18:54:37  <piscisaureus_>isaacs: you paused a socket for half a second without staying open for half a second
18:55:07  <isaacs>so... why is it busylooping on Linux when you write something big, and then destroy on the client, rather than raising an ECONNRESET or EPIPE in the server?
18:55:10  <isaacs>that's the real question.
18:55:30  <isaacs>second: why are sockets not getting properly cleaned up when end() is called
18:56:12  <isaacs>both appear to be easily reproduced on every system that i don't have access to :)
18:56:16  <piscisaureus_>bnoordhuis: isaacs: so could it be that tls.clientError doesn't close the socket under some circumstances
18:56:28  <bnoordhuis>that's what it looks like, yes
18:56:42  <isaacs>piscisaureus_: but both issues are reported for non-tls connections.
18:56:48  <isaacs>piscisaureus_: one for http, the other for tcp
18:57:10  <piscisaureus_>is that supposed to be the case? I TLS api is a dark mystery to me.
18:57:22  <isaacs>piscisaureus_: if it is, it's a separate thing
18:57:22  <bnoordhuis>i had someone add an assert to stream.c that checks if the read_cb stops the handle and it didn't
18:57:37  <bnoordhuis>but that was with http, like isaacs said
18:57:45  <isaacs>yeah, tls is not a factor here.
18:57:49  <isaacs>i'm sure it has its own other bugs.
19:02:19  <bnoordhuis>um
19:02:31  <bnoordhuis>i just pushed two libuv changes that work fine on linux
19:02:42  <bnoordhuis>but they make tons of node tests fail on os x
19:02:55  <bnoordhuis>Assertion failed: (!uv__is_active(handle)), function uv__finish_close, file ../../deps/uv/src/unix/core.c, line 165.
19:02:55  <tjfontaine>is github failing us?
19:03:13  <bnoordhuis>looks like it, MI6 is awfully quiet
19:04:22  <tjfontaine>All job queues are currently backed up due to some increased load on our databases.
19:04:29  <tjfontaine>WTB GITHUB
19:04:34  <tjfontaine>brb lunch
19:04:39  <bnoordhuis>[03:52|% 100|+ 527|- 45]: Done <- ouch
19:10:23  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 4146805 : unix: turn off POLLOUT after stream connect (+1 more commits) - http://git.io/zSPlSg
19:12:54  <MI6>libuv-v0.10: #72 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/72/
19:13:35  * paddybyersquit (Ping timeout: 252 seconds)
19:16:09  * st_lukejoined
19:16:32  * kazuponquit (Remote host closed the connection)
19:17:09  <trevnorris>isaacs: have a date for the next v0.11 release?
19:17:36  <MI6>libuv-v0.10-gyp: #36 UNSTABLE smartos-x64 (2/186) windows-x64 (4/187) smartos-ia32 (2/186) linux-ia32 (1/186) windows-ia32 (4/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/36/
19:20:38  <isaacs>trevnorris: monday?
19:21:16  <bnoordhuis>isaacs: were you planning to do a release tonight?
19:21:22  <trevnorris>isaacs: coolio. think we could get to the buffer patch by the next?
19:21:24  <isaacs>bnoordhuis: yessir
19:21:25  <isaacs>0.10.8
19:21:31  * isaacsnodeup-ing
19:21:37  <bnoordhuis>then i guess i should revert the second-to-last libuv patch for now
19:28:21  <MI6>joyent/libuv: Ben Noordhuis v0.10 * fe7b154 : Revert "unix: fix stream refcounting buglet" - http://git.io/FMJbnA
19:28:22  <piscisaureus_>bnoordhuis: hey, can you take a look at https://gist.github.com/piscisaureus/88e0415b06332e5f16ff ?
19:28:53  <bnoordhuis>piscisaureus_: i can. i have. it's rather dull black on white
19:29:17  <piscisaureus_>bnoordhuis: heh
19:29:23  <piscisaureus_>bnoordhuis: what am I doing wrong
19:29:34  <piscisaureus_>bnoordhuis: node asserts in its js guts (v0.10.7)
19:30:05  <piscisaureus_>bnoordhuis: looks like a DOS risk to me
19:30:40  * stephankquit (Write error: Broken pipe)
19:32:01  <bnoordhuis>ah, i think i know what that is...
19:32:22  * paddybyersjoined
19:32:53  <bnoordhuis>uint8_t data_[18432] <- that
19:33:25  <bnoordhuis>indutny wrote this ClientHello parser
19:33:48  <bnoordhuis>looks like it didn't expect that buffer to ever fill up
19:34:11  <piscisaureus_>bnoordhuis pm
19:35:22  <MI6>libuv-v0.10-gyp: #37 UNSTABLE smartos-x64 (2/186) osx-x64 (1/187) windows-x64 (4/187) smartos-ia32 (2/186) windows-ia32 (5/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/37/
19:36:49  <MI6>libuv-v0.10: #73 UNSTABLE smartos (2/186) windows (3/187) linux (1/186) http://jenkins.nodejs.org/job/libuv-v0.10/73/
19:37:13  <MI6>libuv-node-integration: #67 UNSTABLE linux-ia32 (44/586) smartos-ia32 (45/586) osx-x64 (46/586) osx-ia32 (46/586) linux-x64 (45/586) smartos-x64 (48/586) http://jenkins.nodejs.org/job/libuv-node-integration/67/
19:37:22  * loladiro_joined
19:39:04  * loladiroquit (Ping timeout: 246 seconds)
19:39:05  * loladiro_changed nick to loladiro
19:46:43  * bnoordhuisquit (Ping timeout: 264 seconds)
19:51:19  <MI6>libuv-node-integration: #68 UNSTABLE linux-ia32 (1/586) smartos-ia32 (2/586) osx-x64 (2/586) osx-ia32 (2/586) linux-x64 (1/586) smartos-x64 (3/586) http://jenkins.nodejs.org/job/libuv-node-integration/68/
19:51:57  <indutny>heya
19:52:20  <indutny>piscisaureus_: what's up with clienthello parser?
19:52:48  <trevnorris>is there anywhere in node where we'll bubble the error from a users callback?
19:54:29  <trevnorris>just looking at 5513, and seems there's misunderstanding in the line "like all other async methods"
20:00:00  * kevinswiberquit (Remote host closed the connection)
20:02:24  <tjfontaine>trevnorris: I'm not sure what you mean
20:02:43  <tjfontaine>if you throw in a callback, it would show up on the containers .on('error')?
20:03:11  <trevnorris>tjfontaine: honestly, not completely sure either. check the issue. i'm responding to it now.
20:03:43  * loladiroquit (Ping timeout: 259 seconds)
20:05:07  <tjfontaine>oh I see
20:05:43  * kevinswiberjoined
20:06:26  <tjfontaine>I'm not sure if that's behavior we can change
20:06:46  <tjfontaine>but I understand the desire at leaset
20:07:13  <tjfontaine>*least
20:09:25  <trevnorris>but that location doesn't make sense. it's the listening callback, that's called once when the server is listening for connections.
20:09:39  <trevnorris>not for when connections are actually accepted.
20:10:16  * paddybyersquit (Ping timeout: 260 seconds)
20:10:29  <tjfontaine>the `throw` there is a red herring, the issue is because port 80 requires elevated privileges
20:11:29  <trevnorris>how do you mean?
20:12:41  <tjfontaine>net.createServer().listen(80, function (err) { //noerr }).on('error', function (err) {//err})
20:13:21  * stephankjoined
20:15:31  <tjfontaine>so the reason it doesn't go to listen, is we say that will only fire if the listen was successful, and it goes to error because we didn't
20:15:35  <tjfontaine>*because it wasn't
20:15:40  <trevnorris>tjfontaine: if you throw an error from the connection callback it doesn't reach the error callback.
20:16:02  <trevnorris>ah, wait. i'm completely misunderstanding this
20:16:23  <tjfontaine>so there are two things, 1) the listen issue, 2) he wants a wider change
20:16:23  <trevnorris>ok. i'm a sleep deprived dork. understand now.
20:16:28  * loladirojoined
20:16:45  <tjfontaine>which kinda goes back to the whole where should we handle things
20:16:53  <trevnorris>i thought he was asking for all errors thrown from inside the connection callback to be sent to the listener callback.
20:17:08  * kazuponjoined
20:17:23  <tjfontaine>right, no, he just means that if there is an error for .listen() and he passed that a cb, that's where he expects the error to be sent
20:17:54  <trevnorris>that make sense.
20:18:52  <tjfontaine>but in general he's concerned by an inconsistency in where errors are delivered, which almost leads us back to the throw/no-throw conversation
20:18:58  <trevnorris>well, since it's optional. seems about the same idea as "var s = net.createServer(); s.on('connection', function() { //on_con });"
20:19:18  <trevnorris>"s.listen(<port>)"
20:19:27  <tjfontaine>well, .listen(80, .., cb); is equivalent to .once('listening', cb)
20:19:35  <tjfontaine>in neither case will that get an Error
20:20:13  <trevnorris>well yeah. and more than just equivalent, that's pretty much the code line for line. :)
20:20:23  <tjfontaine>:)
20:22:13  <tjfontaine>I think it's safe to say in core that if it inherits from EventEmitter it generally will emit('error') and not pass cb(err)
20:22:25  <trevnorris>my mind is overly simplistic, but i'm not seeing how this leads back to the throw/no-throw argument.
20:22:32  <trevnorris>honestly what he's requesting make sense.
20:22:38  <tjfontaine>trevnorris: it's an expections game really
20:22:42  <tjfontaine>*expectations
20:22:46  <tjfontaine>man I'm awesome at typing today
20:24:17  <trevnorris>hm. ok. i can understand that.
20:24:42  <tjfontaine>so, basically that code throw's beceause there's no .on('error')
20:25:07  <trevnorris>seems to be difference in internal workings though. i mean, passing the error to the listener callback seems to make sense looking at callbacks like fs.stat()
20:25:13  <tjfontaine>and the question is "why are you writing code that doesn't handle errors" and his response will be "Because I epxect the error to be passed to the callback"
20:25:32  <tjfontaine>trevnorris: right, I think the fundamental differentiator here is if the thing inherits EE
20:25:36  * kazuponquit (Ping timeout: 252 seconds)
20:26:02  <trevnorris>yeah. and that's more difficult to get across. since the syntax for each is similar.
20:26:12  <trevnorris>but that does make sense.
20:26:43  <tjfontaine>so the question is, if we make the change to deliver to the cb, what about all those people expecting to see it in on('error')
20:27:17  <tjfontaine>do we deliver it twice? if so, then the case of 'error' not having a listener will still throw unless we special case
20:27:32  <trevnorris>easy. can do both. it's similar for this: "var s = net.createServer(function() { console.log('cb 1'); }); s.on('connection', function() { console.log('cb 2'); });
20:27:46  <tjfontaine>see my caveat
20:28:53  <trevnorris>well, i'm still not seeing how stuff like that isn't already possible. for example:
20:29:43  <trevnorris>var s = net.createServer(fn() {}); s.on('error', fn() { console.log('error 1'); }); s.on('error', fn() { console.log('error 2'); s.listen(<impossible_port>);"
20:29:54  <trevnorris>both error callbacks will fire.
20:30:24  <tjfontaine>right, but he wants the case of *not* having to define an .on('error')
20:31:07  * loladiroquit (Ping timeout: 264 seconds)
20:31:33  <tjfontaine>and we only want the missing error handler to throw in this case if there's not a listen cb, listening event, or error handler
20:31:49  <trevnorris>well, wouldn't it be possible to just add like: "if (callback) this.on('error', callback)" to .listen()?
20:31:54  <tjfontaine>but missing error handler code throws in lib/events.js not in what inherits EE
20:32:10  <tjfontaine>trevnorris: but then that catches all the other errors that happen
20:32:24  <tjfontaine>where does econnreset or epipe go
20:33:15  <trevnorris>sorry. this is getting confusing for me. i feel like he just wants us to place the syntactic sugar of doing the .on('error',...) for him if he passes the listener callback.
20:33:34  <trevnorris>here, i'm much better w/ code. give me a min
20:33:42  <tjfontaine>ok
20:35:42  * kevinswiberquit (Remote host closed the connection)
20:49:28  * paddybyersjoined
20:52:54  <trevnorris>tjfontaine: https://gist.github.com/trevnorris/5646425
20:53:00  * bnoordhuisjoined
20:53:13  <trevnorris>all but one test passes (test-net-listen-error)
20:53:43  <trevnorris>don't get me wrong, that's horrible code, but it gets done what he's looking for.
20:53:52  <tjfontaine>ya, it feels really icky
20:53:57  * paddybyersquit (Ping timeout: 248 seconds)
20:54:53  <tjfontaine>also means we have to implement some kind of similar pattern for any other place
20:55:25  <trevnorris>yeah. the can of worms a patch like this would open is not something i'd want to deal with.
20:55:57  <tjfontaine>right, so while I'm not necessarily the authority on this, I don't think the pattern of .emit('error') can change at this point
20:56:13  <tjfontaine>or if it does, it needs to happen for .12
20:56:33  <trevnorris>isaacs: hope you don't do much work from internet cafes: http://www.siliconvalley.com/latest-headlines/ci_23005292/oakley-moves-ban-internet-cafes-permanently
20:57:09  <trevnorris>tjfontaine: well, it's not that the pattern would change. more like extended. but yeah. all this needs to be hammered out before v0.12
20:57:23  <trevnorris>also I doubt isaacs would allow this in anyways.
20:57:51  <tjfontaine>trevnorris: I actually think sending the errors twice is a really bad pattern, because you have to make sure you're only handling it once
20:57:56  <tjfontaine>"twice"
20:58:08  <trevnorris>well, that's something we can currently do. so that'll need fixing.
20:58:55  <tjfontaine>in general I agree that "the thing that caused the error should receive the error notification" that way your .on('error') can be less of a giant switch that tries to figure out which part went wrong
21:00:32  <trevnorris>yeah
21:00:46  <tjfontaine>also, oakley appears to be quite a ways away from oakland :)
21:00:55  <trevnorris>ah lol
21:01:07  <trevnorris>too bad you can't open a private ticket. i'd like to have a discussion about this, but every time something is brought up about error handling
21:01:12  <trevnorris>the community goes nuts
21:01:17  <trevnorris>well, part of them anyways
21:01:22  <tjfontaine>:)
21:01:38  <tjfontaine>you can talk to `3rdEden in here :)
21:02:04  <trevnorris>heh
21:02:11  <`3rdEden>What i do
21:02:42  <tjfontaine>we were just discussing your 'pass errors to cbs instead of emit(error)' issue
21:02:54  <trevnorris>5513
21:03:03  <isaacs>trevnorris: wtf?
21:03:28  <trevnorris>isaacs: yeah. and at least Ohio has taken care of those horrible things: http://arstechnica.com/tech-policy/2013/05/ohio-bans-those-dangerous-dens-of-iniquity-internet-cafes/
21:03:47  <tjfontaine>you should see the glut of internet gambling places in ohio though
21:03:49  <tjfontaine>it's really bad.
21:04:26  <trevnorris>`3rdEden: there does seem to be problems w/ error handling (e.g. tjfontaine doesn't like how you can attach two callbacks to an error event)
21:04:37  * st_lukequit (Remote host closed the connection)
21:04:52  <trevnorris>but it's a sensitive topic that seems to bring out the worst in people.
21:05:05  <isaacs>trevnorris: oakley != oaklan
21:05:06  <isaacs>d
21:05:07  <tjfontaine>well it's not that, so much as, to maintain backward compatibility we have to pass and emit, and then do something evil to not throw
21:05:14  <tjfontaine>isaacs: ya I mentioned that to him :)
21:05:21  <trevnorris>isaacs: heh, yeah. missed that at first. :)
21:06:01  <isaacs>ah, error handling.
21:06:02  <isaacs>crap
21:06:07  <tjfontaine>:)
21:06:09  * dominictarrjoined
21:06:40  <isaacs>`3rdEden: i'd rather not do this.
21:06:42  <`3rdEden>Well, yes that sucks
21:06:46  <isaacs>`3rdEden: here's why:
21:06:48  <isaacs>it's not a bad idea.
21:06:55  <isaacs>but how do i know that the error is going to be handled?
21:07:04  <isaacs>`3rdEden: most code will *not* handle the error.
21:07:20  <isaacs>so do we send it to the cb, and *also* emit error?
21:07:30  <tjfontaine>you'd have to for backward compatibility
21:07:42  <isaacs>also, the current contract is that the listen() cb means "You are now successfully listening"
21:07:49  <`3rdEden>Yes that's a good point
21:07:51  <isaacs>yes, it's a departure from other cb-taking node methods
21:07:56  <isaacs>(ie, write(chuk,encoding,cb)
21:07:58  <trevnorris>well, should we allow more than one error callback to be called? seems that could be bad too
21:08:07  <isaacs>but... this is what we have now.
21:08:35  <isaacs>so, if we pass teh error to listen(cb), then we're a) changing an existing contract, b) still having to emit('error', er) just in case anyway.
21:08:47  <`3rdEden>If you have to maintain full backwards compatiblity and have that test fail then this feature would be impossible to implement
21:08:56  <`3rdEden>simple as that
21:08:59  <isaacs>yeah
21:09:02  <isaacs>i'm sorry.
21:09:03  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:09:06  <indutny>bnoordhuis: please review https://github.com/joyent/node/pull/5552
21:09:10  <trevnorris>isaacs: it's ugly, but this gets the job done: https://gist.github.com/trevnorris/5646425
21:09:17  <isaacs>`3rdEden: your suggestion is good, but it's too late.
21:09:20  <`3rdEden>isaacs: I'll solve it userland somehow
21:09:26  <isaacs>`3rdEden: ok :)
21:09:43  <`3rdEden>require('better-node') ;)
21:10:02  <isaacs>trevnorris: well, no, that still leaves open the idea of server.listen(80, function() { everything worked! })
21:10:14  <isaacs>trevnorris: so now i try to connect, and get ECONNREFUSED
21:11:00  <isaacs>so then what? sniff cb.length? ugh. no.
21:11:03  <trevnorris>isaacs: so the issue seems to be more for backwards compatibility, since users may not be expecting their error to be handled.
21:11:09  <isaacs>right
21:11:12  <trevnorris>ah, ok.
21:11:15  <isaacs>it hides the error.
21:11:21  * trevnorrisreceives enlightenment
21:11:24  <isaacs>:)
21:12:13  <`3rdEden>well cb.length could be sniffed with trevnorris's patch
21:12:21  <trevnorris>heh
21:12:31  <trevnorris>that would make a horrible patch even worse.
21:12:35  <`3rdEden>if self._listening_error && self._listening_error.length ;$
21:12:43  <trevnorris>lol
21:13:01  <`3rdEden>That would make pass the tests and give the desired behavior
21:13:23  <isaacs>`3rdEden: every time you read function.length, I kill a kitten.
21:13:31  <isaacs>`3rdEden: please don't make me kill again.
21:13:34  <`3rdEden>And tbh, i've seen more horrible code in node then that ;)
21:13:52  * mikealquit (Quit: Leaving.)
21:13:58  <trevnorris>isaacs: thoughts on https://github.com/trevnorris/node/commit/1f93bed
21:14:59  * normanmjoined
21:15:05  <isaacs>trevnorris: other tests pass?
21:15:09  <trevnorris>yeah
21:15:30  <trevnorris>right now it's sitting on my buffer patch, since i couldn't replicate charCodeAt in cc
21:15:38  <trevnorris>so I decided to make fill work this way instead :)
21:16:16  <trevnorris>(or at least, didn't want to take the time to replicate charCodeAt)
21:17:34  <isaacs>seems fine to me
21:17:45  <trevnorris>coolio. i'll leave it on the commit stack.
21:20:57  * isaacssigh
21:21:01  <isaacs>#5504 will stay open for now
21:21:06  <isaacs>need to get 0.10.8 out
21:21:07  <`3rdEden>isaacs: Anyways, see what you want to do with the feature request. It's implementable without breaking backwards compatible ;P
21:21:45  <isaacs>`3rdEden: it's not implementable without breaking semantics.
21:21:51  <isaacs>`3rdEden: and i'm not going to add a function.length sniff.
21:21:59  <isaacs>`3rdEden: that is universally stupid, i'm sorry.
21:22:09  * kazuponjoined
21:23:13  <`3rdEden>isaacs: okay :p
21:23:17  <piscisaureus_>indutny: now you are assuming that in the second write it can be completed at once
21:23:28  <indutny>yes it can
21:23:32  <indutny>:)
21:23:40  <indutny>it can't only in one case
21:23:50  <indutny>asynchronous SSL backend, which we ain't using
21:23:54  <indutny>ask bnoordhuis
21:24:06  * st_lukejoined
21:24:34  <piscisaureus_>what if the second _write fails?
21:26:41  <indutny>apocalypse
21:26:42  * kazuponquit (Ping timeout: 240 seconds)
21:26:52  <indutny>that's impossible
21:26:59  <indutny>ah
21:27:01  <piscisaureus_>I mean, IOW
21:27:04  <piscisaureus_>it's not possible to do
21:27:05  <indutny>IOW?
21:27:15  <indutny>https://en.wikipedia.org/wiki/Isle_of_Wight
21:28:10  <piscisaureus_>while (written < data.length) {
21:28:10  <piscisaureus_> this.pair..ssl.clearIn()
21:28:10  <piscisaureus_> if (failed) { handle() } etc
21:28:10  <piscisaureus_>}
21:28:27  <piscisaureus_>^-- indutny that pattern is not useful here?
21:28:38  <indutny>ah
21:28:41  <tjfontaine>iow -- in other words
21:28:42  <indutny>no, not really
21:28:53  <indutny>there's only one retry
21:29:05  <indutny>and it is here because of ClientHello parser
21:29:16  <piscisaureus_>yes but errors from the retru aren't handled :)
21:30:00  <indutny>they're
21:30:03  <indutny>its just partial write
21:30:10  <indutny>that couldn't happen on second retry
21:30:15  <indutny>and thus we're just asserting
21:31:30  <bnoordhuis>indutny: the assert happens because the write fills up the data_ chunk in ClientHelloParser, which is 18k
21:31:40  <indutny>yes
21:31:44  <indutny>have you seen my patch?
21:31:54  <bnoordhuis>no. i don't looking at other people's code
21:31:56  <bnoordhuis>my own is bad enough
21:32:15  <bnoordhuis>(okay, okay - i'll review it)
21:33:22  <indutny>:)
21:33:25  <indutny>thanks
21:33:29  * rendarquit
21:34:17  <bnoordhuis>indutny: okay, so what's stopping data_ from filling up a second time?
21:34:25  <indutny>its turned off
21:34:27  <indutny>after first time
21:34:31  <indutny>the ClientHello parser
21:34:43  <indutny>also
21:34:44  <indutny>it works
21:34:52  <MI6>joyent/node: Nathan Zadoks v0.10 * a40133d : http: remove bodyHead from 'upgrade' events - http://git.io/DbEBig
21:36:49  <bnoordhuis>indutny: that reminds me, the ClientHelloParser is embedded in Connection
21:37:00  <indutny>… yes?
21:37:13  <bnoordhuis>which means there's 18k memory sitting unused after the handshake
21:37:17  <bnoordhuis>that makes me sad :(
21:37:20  <indutny>ah
21:37:24  <indutny>yikes
21:37:25  * `3rdEdenquit (Remote host closed the connection)
21:37:30  <indutny>that's nothing
21:37:33  <indutny>comparing to bio ring
21:37:35  <indutny>:D
21:38:33  <MI6>joyent/libuv: isaacs created tag v0.10.8 - http://git.io/l7VgUg
21:38:35  <MI6>joyent/libuv: isaacs v0.10 * 7d5024e : Now working on v0.10.9 (+1 more commits) - http://git.io/Yiwd8g
21:38:37  <isaacs>pushing libuv release
21:39:03  <bnoordhuis>indutny: i guess we should look into that before the next v0.10 release
21:39:11  <indutny>surely yes
21:39:14  <bnoordhuis>people are complaining tls uses a lot of memory
21:39:14  <indutny>when is it?
21:39:31  <bnoordhuis>and while it's partially openssl's fault, node can probably do better as well
21:39:47  <tjfontaine>0.10.8 is right now, so no earlier than next week I guess
21:39:49  <isaacs>bnoordhuis: well, before the next one after this one :)
21:39:50  <bnoordhuis>next release is in two weeks, i think? not counting tonight's that is
21:39:54  <isaacs>right
21:39:59  <isaacs>bnoordhuis: we have no strict schedule
21:40:08  <isaacs>bnoordhuis: i just try to get them out often enough that they're not horrible
21:40:21  <pachet>like children
21:40:32  <bnoordhuis>:)
21:40:57  <indutny>:)
21:41:56  <MI6>joyent/node: isaacs v0.10 * 074e823 : npm: Upgrade to 1.2.23 (+1 more commits) - http://git.io/1PJUdw
21:42:20  <trevnorris>bnoordhuis: are you talking about 5520
21:45:08  <MI6>libuv-v0.10-gyp: #38 FAILURE smartos-x64 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/38/
21:45:32  <bnoordhuis>isn't a40133d ("remove bodyHead") an api change?
21:45:38  <tjfontaine>fucking jenkins
21:45:39  <MI6>joyent/node: isaacs created branch v0.10.8-release - http://git.io/05BvQA
21:45:45  <isaacs>bnoordhuis: the PAI doesn't actually change
21:45:53  <isaacs>bnoordhuis: we pass an empty Buffer to the function
21:46:01  <bnoordhuis>ah okay
21:46:07  <MI6>nodejs-v0.10: #210 UNSTABLE osx-x64 (1/586) osx-ia32 (1/586) smartos-x64 (2/586) http://jenkins.nodejs.org/job/nodejs-v0.10/210/
21:46:08  <isaacs>bnoordhuis: so we just pretend that it always happened to line up perfectly :)
21:46:25  <bnoordhuis>trevnorris: yeah, #5520 is part of it
21:46:36  <MI6>libuv-v0.10: #74 FAILURE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/74/
21:48:43  * stagasquit (Read error: Connection reset by peer)
21:49:07  * qardquit (Quit: Leaving.)
21:56:58  <MI6>nodejs-v0.10-windows: #39 UNSTABLE windows-ia32 (8/586) windows-x64 (8/586) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/39/
21:58:14  * pachetquit (Quit: leaving)
22:04:10  <MI6>joyent/node: Fedor Indutny v0.10 * f7ff8b4 : tls: retry writing after hello parse error - http://git.io/ylgFTQ
22:04:17  <indutny>oh
22:04:17  <indutny>hm
22:04:30  <indutny>that wasn't me
22:04:35  <isaacs>:)
22:04:37  <MI6>joyent/node: isaacs v0.10.8-release * f63612d : 2013.05.24, Version 0.10.8 (Stable) - http://git.io/QGAqxA
22:04:42  <isaacs>at least, it fixes a DOS
22:05:46  <MI6>nodejs-v0.10: #211 UNSTABLE linux-x64 (1/586) osx-x64 (1/586) osx-ia32 (2/586) smartos-x64 (4/586) smartos-ia32 (5/586) linux-ia32 (1/586) http://jenkins.nodejs.org/job/nodejs-v0.10/211/
22:06:23  <MI6>joyent/node: isaacs v0.10 * 179aa0a : doc: Minor fixup in http doc re bodyHead - http://git.io/UJNK9g
22:06:42  <MI6>joyent/node: isaacs v0.10.8-release * 30d9e9f : 2013.05.24, Version 0.10.8 (Stable) - http://git.io/iDrJcw
22:06:49  * normanmquit (Quit: Computer has gone to sleep.)
22:08:28  * `3rdEdenjoined
22:10:39  <isaacs>bnoordhuis, indutny, piscisaureus_: If you guys want to tweat the TLS fix approach further, that's fine by me.
22:10:54  <isaacs>just want to get this build out, and it's a serious failure to have lying around.
22:13:59  * dominictarrquit (Quit: dominictarr)
22:16:40  <MI6>nodejs-v0.10-windows: #40 UNSTABLE windows-ia32 (8/586) windows-x64 (9/586) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/40/
22:16:46  * mjr__quit (Quit: mjr__)
22:17:19  * `3rdEdenquit (Ping timeout: 264 seconds)
22:19:26  <piscisaureus_>isaacs: kewl
22:21:41  <MI6>nodejs-v0.10: #212 UNSTABLE linux-x64 (1/587) osx-x64 (2/587) osx-ia32 (3/587) smartos-x64 (5/587) smartos-ia32 (3/587) linux-ia32 (3/587) http://jenkins.nodejs.org/job/nodejs-v0.10/212/
22:21:57  <tjfontaine>sigh I thought what I was doing would apply to v0.10
22:22:58  * kazuponjoined
22:24:21  <isaacs>tjfontaine: oh?
22:24:26  <isaacs>tjfontaine: pull req that i missed?
22:24:39  <isaacs>tjfontaine: we can have a build next week
22:25:29  <tjfontaine>no no
22:26:15  <tjfontaine>just what I had been doing on the test fixes I thought would apply relatively cleanly to v0.10
22:27:25  * kazuponquit (Ping timeout: 246 seconds)
22:28:14  <isaacs>ahh
22:30:49  * dshaw_joined
22:37:22  <MI6>nodejs-v0.10-windows: #41 UNSTABLE windows-ia32 (9/587) windows-x64 (8/587) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/41/
22:37:40  <isaacs>finally, uploading windows binaries
22:38:27  <tjfontaine>heh
22:43:49  <MI6>joyent/node: isaacs created tag v0.10.8 - http://git.io/7Ke2RA
22:46:13  <MI6>joyent/node: isaacs v0.10 * f904d61 : blog: Post for v0.10.8 (+3 more commits) - http://git.io/hNmsNQ
22:57:36  <MI6>nodejs-v0.10: #213 UNSTABLE linux-x64 (1/587) osx-x64 (2/587) osx-ia32 (3/587) smartos-x64 (4/587) smartos-ia32 (4/587) linux-ia32 (1/587) http://jenkins.nodejs.org/job/nodejs-v0.10/213/
23:04:19  * isaacsgotta run out for a big
23:04:20  <isaacs>*bit
23:04:22  * isaacs&
23:04:54  * mikealjoined
23:05:39  <MI6>nodejs-v0.10-windows: #42 UNSTABLE windows-ia32 (8/587) windows-x64 (8/587) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/42/
23:05:47  <tjfontaine>LOUDBOT: shame on you
23:05:48  <LOUDBOT>tjfontaine: WHITNEY'S DEAD? DO ALL THE DRUGS!
23:14:19  * dshaw_quit (Quit: Leaving.)
23:15:45  * dshaw_joined
23:17:16  <bnoordhuis>so... i observe that node often closes tcp handles before the shutdown req is finished
23:17:32  <bnoordhuis>that's okay but for some reason it only seems to happen on os x, not linux
23:17:45  <bnoordhuis>not sure what to make of that
23:18:05  <tjfontaine>would that manifest itself at times as a rst to the other side of the connection?
23:19:10  <bnoordhuis>hm no, don't think so - the shutdown(2) syscall itself has been issued, it's just that the shutdown req hasn't run to completion yet
23:19:18  <bnoordhuis>iow, its cb hasn't been called yet
23:19:35  <tjfontaine>right
23:22:10  <bnoordhuis>ah... guess it happens on linux as well - but only in debug builds
23:22:28  <bnoordhuis>ergo, it's probably some timing issue
23:22:54  <bnoordhuis>seeing that os x is slow as molasses, it's probably more visible there
23:23:43  * kazuponjoined
23:23:47  <tjfontaine>right
23:28:31  * kazuponquit (Ping timeout: 252 seconds)
23:37:58  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 636a13b : unix: fix stream refcounting buglet - http://git.io/n06Yfw
23:39:32  <tjfontaine>this is the one before that made node tests unhappy?
23:40:18  <MI6>libuv-v0.10: #75 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/75/
23:40:32  * kazuponjoined
23:44:54  <MI6>libuv-v0.10-gyp: #39 UNSTABLE smartos-x64 (2/186) osx-ia32 (1/187) windows-x64 (3/187) smartos-ia32 (2/186) linux-ia32 (3/186) windows-ia32 (3/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/39/
23:45:05  * hueniversequit (Read error: Connection reset by peer)
23:49:55  * kazuponquit (Remote host closed the connection)
23:56:09  <MI6>libuv-node-integration: #69 UNSTABLE linux-ia32 (1/587) smartos-ia32 (3/587) osx-x64 (3/587) osx-ia32 (3/587) linux-x64 (2/587) smartos-x64 (4/587) http://jenkins.nodejs.org/job/libuv-node-integration/69/
23:57:23  <tjfontaine>bnoordhuis: hmm that seems to break test-stdout-close-catch
23:57:39  <tjfontaine># node: ../deps/uv/src/unix/stream.c:731: uv__write: Assertion `stream->write_queue_size == 0' failed.
23:57:42  <tjfontaine># Aborted (core dumped)