00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:08:00  * stagasquit (Read error: Connection reset by peer)
00:08:32  * stagasjoined
00:29:35  <isaacs>ircretary: Bisect over libuv shows that the problem starts at libuv@1282d64
00:29:35  <ircretary>isaacs: I'm not sure what to do with that command. Ask for help in PM.
00:29:58  <isaacs>ircretary: tell bnoordhuis Bisect over libuv shows that the problem starts at libuv@1282d64
00:29:58  <ircretary>isaacs: I'll be sure to tell bnoordhuis
00:38:24  <isaacs>ok, so, i got stdin working properly in streams2 mode, but not in old-mode.
00:44:00  <deoxxa>it's like watching someone smash my favourite toy in front of me :<
00:44:10  * mikealjoined
00:49:25  <isaacs>deoxxa: lol
00:49:30  <isaacs>deoxxa: you are anti streams2?
00:54:27  <deoxxa>i'm just pretty heavily invested in the old interface is all
00:56:06  <deoxxa>with streams being such a heavily promoted thing in node, it's a bit painful watching it completely change
00:57:41  <deoxxa>i know that's not the way it's seen by the people close to the implementation, and i'm all for lightening the load for you guys, but as a user it makes me worried about adopting any new interfaces (or even old interfaces) in node
00:59:51  <isaacs>deoxxa: well, the old interface will still work
00:59:55  <isaacs>deoxxa: i'm keeping all the same tests.
01:00:09  <isaacs>except that you need to .resume() in a few specific places if you want a stream to ever reach its end
01:00:16  <isaacs>deoxxa: or add a 'data' event listener
01:00:20  <isaacs>but youer' probably doing that already anyway
01:03:22  * jmar777joined
01:13:25  <isaacs>ok, debugger-repl* tests failing, everything else passing (reverted last 2 libuv updates)
01:30:41  * ericktjoined
01:42:51  * dapjoined
01:52:04  * piscisaureus_joined
02:18:42  * piscisaureus_quit (Ping timeout: 250 seconds)
02:30:47  * brsonquit (Quit: leaving)
02:37:50  * kristatequit (Ping timeout: 255 seconds)
02:42:46  * dapquit (Quit: Leaving.)
02:51:38  * ericktquit (Quit: erickt)
02:58:17  * dapjoined
02:58:23  * dapquit (Client Quit)
03:22:53  * jmar777quit (Remote host closed the connection)
03:40:19  * mikealquit (Quit: Leaving.)
04:09:48  * stagasquit (Ping timeout: 264 seconds)
04:32:04  * abraxasquit (Remote host closed the connection)
04:33:15  * stagasjoined
04:36:06  * kristatejoined
05:13:53  * kristate_joined
05:16:00  * kristatequit (Ping timeout: 276 seconds)
05:18:38  * kristatejoined
05:21:05  * kristate_quit (Ping timeout: 256 seconds)
05:27:22  * abraxasjoined
05:28:29  * kristate_joined
05:30:54  * kristatequit (Ping timeout: 244 seconds)
05:31:57  * kristatejoined
05:34:41  * kristate_quit (Ping timeout: 255 seconds)
05:38:54  * kristatequit (Ping timeout: 240 seconds)
05:56:46  * joshthecoderquit (Quit: Leaving...)
06:07:58  * kristatejoined
06:21:40  * loladirojoined
06:37:04  * benoitcquit (Excess Flood)
06:47:27  * benoitcjoined
06:50:33  * felixgejoined
06:51:22  * felixgequit (Client Quit)
07:10:54  * kristatequit (Ping timeout: 240 seconds)
07:25:52  * bnoordhuisjoined
07:43:09  * kristatejoined
08:03:50  <MI6>joyent/node: Ryunosuke SATO master * 0397223 : events: use null assignment instead of deleting property - http://git.io/pfH2bA
08:08:29  * stagasquit (Ping timeout: 244 seconds)
08:12:18  * loladiroquit (Quit: loladiro)
08:27:46  * rendarjoined
08:58:14  * stagasjoined
09:04:49  * abraxasquit (Remote host closed the connection)
09:05:40  * abraxasjoined
09:23:55  * `3rdEdenjoined
10:48:07  * felixgejoined
10:48:07  * felixgequit (Changing host)
10:48:07  * felixgejoined
10:48:30  * abraxasquit (Remote host closed the connection)
11:03:27  * wavdedquit
11:03:27  * wavdedjoined
11:07:48  * piscisaureus_topic: liberal utopian vacation ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
11:10:31  <indutny>hello
11:48:34  <bnoordhuis>sup fedor
11:52:01  <indutny>nothing
11:52:02  <indutny>just hello
11:52:05  <indutny>how are you?
11:53:44  <bnoordhuis>fine, nothing special
11:53:55  <bnoordhuis>fixing all the bugs, same as always
11:58:53  * stagasquit (Read error: Connection reset by peer)
11:59:46  * stagasjoined
12:19:15  <MI6>joyent/node: Ryunosuke SATO master * 0506d29 : events: fix typos in code comment - newListeners -> newListener (+2 more commits) - http://git.io/P5bb_Q
12:23:24  * stagasquit (Read error: Connection timed out)
12:26:45  * stagasjoined
12:31:27  * sgallaghjoined
12:39:18  * felixgequit (Quit: http://www.debuggable.com/)
12:39:41  * mmalecki[away]changed nick to mmalecki
13:29:00  * stephankquit (Ping timeout: 240 seconds)
13:36:35  * jmar777joined
13:41:38  * Raltquit (Read error: Connection reset by peer)
13:59:59  * loladirojoined
14:01:18  * stephankjoined
14:15:16  * kristatequit (Ping timeout: 240 seconds)
14:33:44  <bnoordhuis>$ ping6 ::ffff:127.0.0.1
14:33:44  <bnoordhuis>PING ::ffff:127.0.0.1(::ffff:127.0.0.1) 56 data bytes
14:33:44  <bnoordhuis>ping: sendmsg: Network is unreachable
14:33:49  <bnoordhuis>^ why?
14:41:56  * roxlujoined
14:42:27  <roxlu>hey! how is there a non-blocking uv_run_once ?
14:47:19  <roxlu>.. I meant.. "is there a non-blocking uv_run_once()" ?
14:47:53  <roxlu>I need to call a update() function regurlarly but uv_run_once() is blocking the execution
14:51:06  * piscisaureus_joined
14:52:58  * bradleymeckjoined
14:53:31  <roxlu>someone?
15:02:33  <piscisaureus_>hello
15:02:39  <piscisaureus_>bnoordhuis: you need me to review anything?
15:02:52  <piscisaureus_>bnoordhuis: also, will you join the meeting tonight at 7?
15:02:53  * bradleymeckquit (Quit: bradleymeck)
15:03:10  <roxlu>hey piscisaureus_ I'm trying to figure out how to make uv_run/uv_run_once non-blocking, is that possible?
15:03:55  <piscisaureus_>roxlu: well, there is a patch for it but it is pending review
15:04:23  <piscisaureus_>roxlu: right now you can't really. Although if you create an uv_idle_t which does nothing that uv_run_once will be non-blocking
15:04:30  <piscisaureus_>(so that's the "workaround" for now)
15:04:45  <piscisaureus_>s/that/then/
15:04:53  <roxlu>is there an example of that?
15:05:06  * bradleymeckjoined
15:05:28  <piscisaureus_>not really. but it's not hard
15:05:35  <piscisaureus_>just create an uv_idle_t and start it
15:05:51  <piscisaureus_>and use a callback with an empty function body
15:06:32  <piscisaureus_>roxlu: in fact, depending on your application's setup, I would *use* the uv_run_t
15:06:50  <roxlu>ok, I'm new to both actually :#
15:06:50  <piscisaureus_>roxlu: do everything you would normally do in between uv_run_once calls in the callback
15:07:10  <piscisaureus_>roxlu: I don't have an example for you, and I have no time to write one right now
15:07:44  <piscisaureus_>roxlu: http://nikhilm.github.com/uvbook/utilities.html#idle-watcher-pattern
15:08:08  <roxlu>thanks!
15:23:05  <bnoordhuis>piscisaureus_: yep, i'll be at tonight's meeting
15:23:12  <piscisaureus_>very good
15:23:37  <piscisaureus_>bnoordhuis: so in other news. Do you need me to review anything?
15:23:54  <bnoordhuis>piscisaureus_: did you review saghul's patch?
15:24:06  <piscisaureus_>no
15:24:08  <piscisaureus_>so that :-)
15:24:09  * loladiroquit (Quit: loladiro)
15:27:51  <bnoordhuis>piscisaureus_: on a side note, i want to make uv_run2 the new uv_run
15:28:04  <piscisaureus_>bnoordhuis: no timeout argument?
15:28:15  <piscisaureus_>actually, meh
15:28:19  <piscisaureus_>this seems fine
15:28:26  <piscisaureus_>(uv_run2 I mean)
15:28:30  <bnoordhuis>good
15:28:41  <piscisaureus_>maybe we should use varargs :-p;
15:28:55  <bnoordhuis>you should review the mmap-buffers patch as well
15:29:08  <bnoordhuis>but mostly just to check if it compiles on windows :)
15:29:18  <piscisaureus_>yeah
15:29:19  <piscisaureus_>if (pGetQueuedCompletionStatusEx)
15:29:20  <piscisaureus_> poll = &uv_poll_ex;
15:29:20  <piscisaureus_> else:
15:29:20  <piscisaureus_> poll = &uv_poll;
15:29:29  <piscisaureus_>I have the feeling that saghul is a pythonista
15:29:34  <piscisaureus_>and that he didn't actually test is PR
15:29:39  <piscisaureus_>s/is/his/
15:31:48  <piscisaureus_>bnoordhuis: I want to talk to you about uv_canel
15:31:48  * Raltjoined
15:31:51  <piscisaureus_>*cancel
15:31:57  <bnoordhuis>uv_camel?
15:32:00  <bnoordhuis>oh
15:32:13  <bnoordhuis>speak
15:32:41  <piscisaureus_>so if uv_cancel succeeds then the callback will not be called, will it?
15:33:04  <bnoordhuis>correct
15:33:13  <piscisaureus_>that sucks
15:33:48  <bnoordhuis>the alternative - calling the callback - is worse
15:34:10  <piscisaureus_>it makes this impossible on windows
15:34:33  <bnoordhuis>why?
15:34:44  <mmalecki>what do you guys think about adding a callback which happens when refcount drops to 0 but before the loop exists?
15:34:47  <mmalecki>like, before_exit?
15:35:15  <mmalecki>there's an issue in node which could use that
15:35:32  <piscisaureus_>bnoordhuis: because on windows we have to call CancelIoEx
15:35:58  <piscisaureus_>bnoordhuis: but if you cancel an op with CanceloEx then a packet will still be posted on the IOCP
15:36:13  <piscisaureus_>bnoordhuis: so the user cannot safely reuse the memory after that
15:36:42  <piscisaureus_>mmalecki: I don't see the point
15:36:44  <piscisaureus_>mmalecki: why not
15:36:47  <piscisaureus_>uv_run(loop)
15:36:55  <piscisaureus_>do_exit_stuff();
15:37:03  <bnoordhuis>i think he's talking about node
15:37:14  <piscisaureus_>oh
15:37:17  <piscisaureus_>that'd be fine with me
15:37:18  <bnoordhuis>piscisaureus_: sounds like you need to stop using iocp
15:37:19  <mmalecki>no, uv :)
15:37:32  <piscisaureus_>bnoordhuis: yeah I sent bill a strong-worded letter already
15:37:33  <mmalecki>when doing that in uv, you need to call uv_run twice
15:37:34  * loladirojoined
15:37:43  <mmalecki>(if you want to do asynchronous stuff)
15:37:52  <bnoordhuis>mmalecki: and?
15:37:55  <piscisaureus_>mmalecki: so, is that a problem?
15:37:59  <piscisaureus_>btw
15:38:03  <mmalecki>dunno, feels dirty to me
15:38:15  <piscisaureus_>we should have some sort of function that tells if a loop is alive
15:38:18  <piscisaureus_>you could do
15:38:38  <piscisaureus_>do {
15:38:39  <piscisaureus_> uv_run(loop);
15:38:39  <piscisaureus_> at_exit();
15:38:39  <piscisaureus_>} while (uv_loop_alive(loop));
15:38:42  <bnoordhuis>we have that / will be having that once uv_run2 lands
15:39:31  <bnoordhuis>but in your example, uv_run won't return before all ref'd handles have finished
15:39:48  <piscisaureus_>sure
15:40:03  <piscisaureus_>but at_exit might add some new handles
15:40:08  <piscisaureus_>that's the whole point right?
15:40:22  <bnoordhuis>if at_exit revives the loop, well, that's what uv_run2(UV_RUN_NOBLOCK) is for
15:40:39  <piscisaureus_>heu
15:40:40  <piscisaureus_>?
15:40:50  <piscisaureus_>I don't think so
15:41:07  <bnoordhuis>if it returns 0, i.e. "all done", you can exit\
15:41:16  <bnoordhuis>otherwise, you enter the loop again
15:41:21  <piscisaureus_>ah sure
15:41:22  * loladiroquit (Client Quit)
15:41:26  <piscisaureus_>but why NOBLOCK ?
15:41:42  <bnoordhuis>no particular reason
15:41:51  <bnoordhuis>could've been UV_RUN_ONCE or UV_RUN_DEFAULT
15:42:25  <bnoordhuis>mmalecki: ^
15:42:29  <bnoordhuis>in short, no need for new api
15:42:50  * kristatejoined
15:43:01  <mmalecki>word
15:43:04  <bnoordhuis>now for something completely different
15:43:11  <mmalecki>and what do you think about beforeExit in node?
15:43:17  <bnoordhuis>what are considered local addresses in the ipv6 world?
15:43:30  <mmalecki>::1 iirc
15:43:39  <bnoordhuis>mmalecki: i guess it's useful. ask isaacs, he's got a thing for node
15:43:54  <bnoordhuis>yes, ::1 but there's also the ipv4-to-ipv6 mapping range
15:44:03  <bnoordhuis>plus the link-local range
15:44:16  * joshthecoderjoined
15:55:58  <piscisaureus_>bnoordhuis: so, what about making uv_cancel report UV_ECANCELLED?
15:56:10  <bnoordhuis>piscisaureus_: report to whom/what?
15:58:14  <isaacs>bnoordhuis: did you see the note about b6a3b0a6297ee205aa34d357edd55b79f91cdf09?
15:58:16  <piscisaureus_>bnoordhuis: always call the callback. If cancelling is succesful, call the callback with UV_ECANCELLED asap
15:58:20  <MI6>joyent/libuv: bnoordhuis created branch no-linger - http://git.io/Xyn0qg
15:58:34  <bnoordhuis>^ someone review that please and tell me if it's sane
15:58:50  <piscisaureus_>bnoordhuis: what's the motivation/
15:59:05  <bnoordhuis>piscisaureus_: ephemeral port exhaustion
15:59:24  <bnoordhuis>or rather, performance regressions caused by ephemeral port exhaustion
15:59:34  <bnoordhuis>https://github.com/joyent/libuv/issues/624#issuecomment-11160201
15:59:38  <piscisaureus_>bnoordhuis: the issue with turning off linger is that that the send buffer gets clipped as soon as you call close()
15:59:46  <piscisaureus_>e.g. it would fuck up node's http stuff
15:59:53  <piscisaureus_>because it calls close immediately after the last write()
16:00:06  <bnoordhuis>it calls shutdown() first, doesn' it?
16:00:14  <piscisaureus_>no
16:00:37  <bnoordhuis>why not? shouldn't we fix that?
16:00:46  <piscisaureus_>bnoordhuis: because it saves a syscall :-)
16:00:59  <bnoordhuis>isaacs: saw the note but i wasn't sure what it related to
16:01:22  <piscisaureus_>bnoordhuis: shutdown is unnecessary if you are sure that the other side will/should not send more data
16:01:33  * travis-cijoined
16:01:33  <travis-ci>[travis-ci] joyent/libuv#940 (no-linger - 0e38494 : Ben Noordhuis): The build passed.
16:01:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/commit/0e38494aff2b
16:01:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3594084
16:01:33  * travis-cipart
16:01:57  <piscisaureus_>bnoordhuis: close() will do a graceful close under the hood, *iff* linger is enabled (which is the case by default)
16:02:17  <bnoordhuis>piscisaureus_: not always - that's just how most platforms implement it
16:02:28  <bnoordhuis>and maybe not even always then
16:02:29  <isaacs>bnoordhuis: so, for some reason, that change made a bunch of things break in the streams2-net branch
16:02:38  <piscisaureus_>bnoordhuis: that's the behavior we rely on.
16:02:42  <isaacs>bnoordhuis: when i do a big write, my afterWrite funciton isn't being called.
16:02:46  <piscisaureus_>bnoordhuis: I think it is actually sort of "official"
16:03:26  <bnoordhuis>isaacs: is there a test case i can try?
16:03:37  <piscisaureus_>bnoordhuis: http://pubs.opengroup.org/onlinepubs/009695399/functions/setsockopt.html
16:05:04  <bnoordhuis>piscisaureus_: yes, but - our sockets are non-blocking. i don't think the normal rules apply
16:05:07  <isaacs>bnoordhuis: it breaks test/simple/test-tls-pause.js
16:05:19  * kristatequit (Remote host closed the connection)
16:05:22  <isaacs>bnoordhuis: and makes the benchmark/net-pipe.js throughput drop to 0
16:05:37  <bnoordhuis>isaacs: but only in your streams2 branch?
16:05:52  <piscisaureus_>bnoordhuis: you could add a test for it
16:06:16  <bnoordhuis>piscisaureus_: yes. however, most of the times it'll work like you say
16:06:23  <bnoordhuis>but it's not something we can rely on
16:06:30  <piscisaureus_>bnoordhuis:
16:06:30  <piscisaureus_>1 create a socketpair
16:06:30  <piscisaureus_>2 write data to socket 0, then close it
16:06:30  <piscisaureus_>3 read() on socket 1, see if it comes out
16:06:32  <bnoordhuis>i'm pretty sure linux won't always work like that
16:06:42  <bnoordhuis>even if it does 99% of the time
16:06:43  <piscisaureus_>bnoordhuis: well, node relies heavily on this
16:06:57  <piscisaureus_>bnoordhuis: on windows I had to move mountains to behave the same :-)
16:07:05  <bnoordhuis>that might explain some irreproducible bug reports :)
16:07:11  <MI6>joyent/node: isaacs created branch streams2-stdin-wip - http://git.io/uswGtg
16:07:12  <isaacs>bnoordhuis: in that branch^
16:07:40  <isaacs>bnoordhuis: there's got to be something i'm doing differently, because it works fine in master.
16:07:52  * ericktjoined
16:07:58  <bnoordhuis>let me try it
16:08:36  <isaacs>bnoordhuis: even if i just do `git checkout master -- lib/net.js` then the benchmark flows normally
16:08:58  <isaacs>thanks
16:09:01  <bnoordhuis> that suggests that you're doing something wrong :)
16:09:04  <piscisaureus_>bnoordhuis: http://linux.die.net/man/7/socket
16:09:06  <isaacs>it does!
16:09:07  <bnoordhuis>(i kid, i kid - let me try it)
16:09:12  <isaacs>but i'm not sure what it is
16:09:18  <piscisaureus_>bnoordhuis: if linux does not always do this, it is a bug
16:09:41  <bnoordhuis>piscisaureus_: let's get back to it in a few
16:09:45  <piscisaureus_>kk
16:11:48  <bnoordhuis>isaacs: fwiw
16:11:50  <bnoordhuis>(gdb) call uv__print_handles(0, 0)
16:11:50  <bnoordhuis>[--I] signal 0x127fe58
16:11:50  <bnoordhuis>[-AI] async 0x127fd10
16:11:50  <bnoordhuis>[R--] idle 0x127b620
16:11:52  <bnoordhuis>[-A-] check 0x127b6a0
16:11:55  <bnoordhuis>[---] idle 0x127b700
16:11:57  <bnoordhuis>[-A-] timer 0x127b760
16:12:00  <bnoordhuis>[R--] timer 0x127b4e0
16:12:02  <bnoordhuis>[RA-] tcp 0x12c8700
16:12:05  <bnoordhuis>[---] tty 0x13f9390
16:12:07  <bnoordhuis>[-A-] signal 0x13f94e0
16:12:10  <bnoordhuis>[---] tty 0x13f95a0
16:12:12  <bnoordhuis>[RA-] tcp 0x13f9700
16:12:15  <bnoordhuis>[R--] tcp 0x140d560
16:12:17  <bnoordhuis>R means ref'd, A means active
16:12:20  <bnoordhuis>(and I is internal)
16:12:46  <piscisaureus_>nice
16:12:49  <isaacs>neat
16:13:07  <bnoordhuis>so it looks like there's one tcp connection that somehow hangs
16:13:14  <isaacs>that makes sense.
16:13:26  <isaacs>but why?
16:13:31  <bnoordhuis>good question :)
16:13:44  <isaacs>what i see is, i write(bigBuffer) and never get the writeReq.oncomplete call
16:13:49  <isaacs>even though, on the other end, i'm reading it all in
16:14:08  <isaacs>and it only seems to happen when i'm using pipe(), so it's reading and writing in both directions
16:14:14  <isaacs>socket.pipe(socket)
16:14:55  <isaacs>if i just do: socket.resume(); socket.end(bigBuffer); then it works.
16:15:06  <bnoordhuis>there's no data in the write queue
16:15:14  <isaacs>strange.
16:15:32  * AndreasMadsenjoined
16:15:32  <bnoordhuis>neither in the write_completed_queue
16:15:39  <isaacs>what about when you run test/simple/test-tls-pause.js
16:16:27  <bnoordhuis>that's the one i'm testing now
16:17:36  <isaacs>what's especially strange to me is that master works, and streams2 doesn't, and the problem is triggered by some change in libuv@665a316
16:18:05  * joshthecoderquit (Quit: Leaving...)
16:18:11  <isaacs>i'm not sure what i'm doing differently to trigger it, but it is concerning that someone else using libuv directly will get bit by this.
16:21:01  <bnoordhuis>what's interesting is that 63k buffers work but 64k buffers don't
16:21:16  <bnoordhuis>probably some trivial libuv bug, i'll look into it
16:21:48  <isaacs>bnoordhuis: thanks!
16:22:28  * Raltquit (Ping timeout: 265 seconds)
16:22:41  <isaacs>bnoordhuis: let me know if you make any progress on it, i'd like to release another 0.9 very soon, like tomorrow morning
16:22:45  <isaacs>mornevening
16:22:59  <bnoordhuis>always with the pressure!
16:23:03  <isaacs>:D
16:23:16  * isaacsjust watched "6 Days to Air", a documentary about the making of south park
16:23:19  <isaacs>inspirational.
16:23:28  <isaacs>every software dev should watch it
16:23:33  <isaacs>if only to realize how easy we have it :)
16:25:27  <isaacs>bnoordhuis: if you don't have the fix by tomorrow, we can release with streams2 minus net
16:25:50  <bnoordhuis>6 days? opulent luxury. i'm used to "done by last week"
16:26:16  <AndreasMadsen>hehe
16:26:24  <mmalecki>bnoordhuis: I can relate to this.
16:27:14  <mmalecki>dscape knows how to fix deadline problems tho
16:28:30  <dscape>you mean by putting names of people next to a date
16:28:37  <mmalecki>yup
16:28:47  <mmalecki>and moving the date
16:28:54  <dscape>and then no worrying about it, just scream at people if they fail to either change date or reach it? :P
16:28:59  <isaacs>bnoordhuis: apparently they write, draw, voice, and edit every episode of south park in 1 week
16:30:18  <indutny>haha
16:30:24  <indutny>isaacs: man, we should use their release cycle model
16:32:28  <isaacs>indutny: during the first few releases of a stable branch, we do
16:32:46  * `3rdEdenchanged nick to `3rdEden|FOODING
16:32:52  <isaacs>indutny: but then we usually have tons of relatively fixable bugs coming in
16:32:58  <indutny>ahhaha
16:33:05  <indutny>yes, postponing stuff
16:33:18  <indutny>actually, it's probably good that we hadn't released 0.10 yet
16:33:18  * loladirojoined
16:33:23  * loladiroquit (Client Quit)
16:33:24  <indutny>not every person has moved to 0.8
16:33:33  <piscisaureus_>yeah
16:33:39  <piscisaureus_>our release cycle is too frequent
16:33:43  <indutny>it usually takes about half-year or more to move to another version
16:34:25  <piscisaureus_>being on 0.6 seems pretty shitty now tho
16:34:30  <piscisaureus_>we don't fix bugs in it any more
16:34:44  <indutny>I suggest we should use 6 Uranian weeks release cycle
16:34:47  <piscisaureus_>although "officially" we were going to support it until the end of the year
16:34:55  <indutny>piscisaureus_: the end is soon
16:34:56  <bnoordhuis>piscisaureus_: we do
16:34:57  <indutny>21.12.12
16:35:01  <bnoordhuis>but only critical fixes
16:35:12  <piscisaureus_>what constitutes a critical fix?
16:35:20  <indutny>when everything fails
16:35:25  <indutny>and the office is in flames
16:35:26  <bnoordhuis>a security vulnerability, rm -rf /
16:35:42  <indutny>ahha
16:35:49  <indutny>you know my favorite env variable value?
16:35:54  <indutny>export EDITOR=/usr/bin/rm
16:35:55  <piscisaureus_>bnoordhuis: security vulnerability <-- you always deny those
16:36:05  <bnoordhuis>that's because they're features
16:36:09  <bnoordhuis>for my russian friends
16:36:15  <piscisaureus_>hahaha
16:36:19  * bnoordhuisducks
16:36:21  <indutny>ahahaha
16:38:10  * Raltjoined
16:41:20  <bnoordhuis>write(12, "\27\3\3@\30\205\310\10\352{UF\21\233\313{\231\364\326\215#\200\r\34\261\237J.\212\267*H"..., 65537) = 65537 <- suspicious
16:42:25  <bnoordhuis>indutny: i would like you to fix those debugger tests
16:42:32  <bnoordhuis>either that or i'll remove them
16:42:47  <indutny>I can only agree on the latter one :)
16:42:54  <bnoordhuis>yes? you think they're bad?
16:43:05  <indutny>move them to pummel or anything
16:43:16  <indutny>it's not really the thing you may want to test everytime
16:43:28  <bnoordhuis>i don't mind testing things repeatedly
16:43:36  <bnoordhuis>what i do mind is tests leaving behind stray processes
16:45:01  <indutny>well
16:45:05  <indutny>there was a fix
16:45:09  <indutny>that was killing process group
16:45:59  <piscisaureus_>can we not make a node api that makes processes have their own process group?
16:46:08  <piscisaureus_>I think it would be convenient for many people
16:46:11  <indutny>piscisaureus_: someone needs to kill it
16:46:15  <indutny>piscisaureus_: this group
16:46:19  <indutny>it won't die by itself
16:46:19  <piscisaureus_>ah
16:46:28  <piscisaureus_>well we can add another indirection to the test
16:46:41  <piscisaureus_>e.g. some node process that uses fork() to spawn the actual test
16:47:08  <piscisaureus_>I think having job control for spawn() would be nice
16:51:23  <indutny>yes
16:51:27  <indutny>this is a way to go
16:51:38  <indutny>but if it'll be killed because of timeout - process will still hang
16:51:44  <indutny>python test runner should kill process group
16:52:44  * dapjoined
16:52:48  <isaacs>indutny: i seem to recall that having python kill the process group was kind of awful.
16:53:00  <indutny>yeees
16:53:03  <indutny>but I can't remember why
16:53:03  <isaacs>indutny: because it makes test-mmessage and lint not get run
16:53:04  <indutny>can you?
16:53:12  <isaacs>indutny: it kills the make process.
16:53:43  * felixgejoined
16:53:43  * felixgequit (Changing host)
16:53:43  * felixgejoined
16:53:53  <isaacs>for now, the debugger tests are very helpful to me.
16:54:01  <isaacs>but we should have debugger tests that don't make zombies, ideally
16:54:07  <isaacs>bnoordhuis, indutny ^
16:54:17  <isaacs>i say this because i apparently broke the debugger yesterday :)
16:54:23  <indutny>aha!
16:54:26  <indutny>offender found :)
16:54:28  * joshthecoderjoined
16:54:39  <bnoordhuis>no, those tests have been leaving stray processes behind for a while now
16:54:52  <bnoordhuis>i've been pestering you about for some time as well, fedor
16:54:56  <bnoordhuis>*about it
16:55:13  <isaacs>indutny: only in streams2-net
16:55:19  <isaacs>indutny: and probably because of something i did to stdin
16:56:20  <indutny>ah
16:56:59  <indutny>bnoordhuis: can you take a look at https://github.com/joyent/node/pull/4347
16:57:00  <indutny>please
16:57:52  <bnoordhuis>indutny: executive summary for the workaround please?
16:58:01  <bnoordhuis>like i said, i never understood why mod_ssl does that
16:58:09  <indutny>bnoordhuis: see last comment
16:58:12  <indutny>bnoordhuis: I removed that loop
16:58:19  <indutny>it was some legacy stuff, and you were right
16:58:42  <bnoordhuis>broken openssl version?
16:59:06  <bnoordhuis>did you ask on the mod_ssl mailing list?
16:59:10  <indutny>no
16:59:13  <indutny>I looked at source
16:59:14  * Raltquit (Ping timeout: 240 seconds)
16:59:19  <indutny>there's a state machine
16:59:23  <indutny>but it's pretty simple
16:59:31  <indutny>hm...
16:59:36  <indutny>also this remind me about one thing
16:59:41  <indutny>I probably should call it twice
16:59:50  <indutny>because it sends first and reads on the second call
17:00:13  * bnoordhuisraises a questioning eyebrow
17:01:07  <indutny>you want to know why?
17:01:15  <bnoordhuis>yes
17:01:29  <indutny>one sec
17:01:34  <bnoordhuis>there is no knowledge that is not power, to quote mortal kombat
17:01:56  <indutny>bnoordhuis: https://github.com/joyent/node/blob/master/deps/openssl/openssl/ssl/s3_lib.c#L4092
17:02:06  <bnoordhuis>i can do a passable imitation of the mortal kombat voice btw
17:02:10  <indutny>skip quit shutdown shit
17:02:28  <bnoordhuis>people always change the subject when i mention that :(
17:02:48  <bnoordhuis>okay, what should i be looking at?
17:03:23  <bnoordhuis>the ack from the peer?
17:03:43  <bnoordhuis>or rather, the expected ack from the peer
17:03:47  <indutny>yes, that's what I'm talking about
17:04:09  <bnoordhuis>okay, it kind of makes sense
17:04:12  <bnoordhuis>can you capture it in a test?
17:04:57  * loladirojoined
17:05:31  * loladiroquit (Client Quit)
17:06:43  <bnoordhuis>piscisaureus_: still around?
17:07:20  <indutny>bnoordhuis: I'll try
17:07:29  <bnoordhuis>nice
17:07:37  <piscisaureus_>bnoordhuis: yup
17:07:59  <bnoordhuis>piscisaureus_: re linger and close()
17:08:06  <bnoordhuis>or just close() really
17:08:12  <bnoordhuis>node shouldn't rely on that behavior
17:08:26  * ericktquit (Quit: erickt)
17:08:31  <bnoordhuis>what the linux man page fails to mention is that the rules change when non-blocking sockets are involved
17:08:50  * loladirojoined
17:09:27  <bnoordhuis>and even if linux does the right thing, other platforms don't
17:09:41  <bnoordhuis>(but it doesn't - not always)
17:11:58  * Raltjoined
17:12:24  <bnoordhuis>piscisaureus_: now that i think of it, how does that even work?
17:12:30  * loladiroquit (Client Quit)
17:12:33  <piscisaureus_>bnoordhuis: a sec
17:12:35  <bnoordhuis>uv_close() cancels pending write requests
17:12:54  <bnoordhuis>so it's a tossup what's actually sent out and what's not
17:13:46  <piscisaureus_>bnoordhuis: true. Skype?
17:13:58  <piscisaureus_>bnoordhuis: dat gaat wat sneller
17:14:02  <bnoordhuis>okee :)
17:14:03  <piscisaureus_>bnoordhuis: ik kan je ook bellen :_0
17:14:16  <bnoordhuis>bellen? was dat niet wat mensen in de '90s deden?
17:14:23  <piscisaureus_>haha
17:14:31  <piscisaureus_>get ur ass on skype then
17:14:37  <bnoordhuis>ff macbook opstarten
17:21:10  * loladirojoined
17:21:33  * loladiroquit (Client Quit)
17:28:55  * bradleymeckquit (Quit: bradleymeck)
17:32:48  * loladirojoined
17:33:51  * loladiroquit (Client Quit)
17:35:41  * `3rdEden|FOODINGchanged nick to `3rdEden
17:36:16  * tomshredsjoined
17:57:41  <piscisaureus_>creationix: SL meeting?
18:04:44  <bnoordhuis>creationix: hurry up, we're waiting
18:06:13  * TooTallNatejoined
18:06:14  * Raltquit (Ping timeout: 259 seconds)
18:06:47  * Raltjoined
18:19:56  * bnoordhuisquit (Ping timeout: 252 seconds)
18:31:26  * bradleymeckjoined
18:40:36  <indutny>bnoordhuis: have you figured out what is happening?
18:40:53  <indutny>bradleymeck: (about linger)
18:41:06  <bradleymeck>indutny: ?
18:41:14  <indutny>oh
18:41:17  <indutny>sorry, tab-completion failure
18:52:35  * hzjoined
19:00:24  * jmar777quit (Read error: Connection reset by peer)
19:00:51  * jmar777joined
19:19:30  * brsonjoined
19:21:55  * `3rdEdenquit (Quit: derp)
19:33:06  * `3rdEdenjoined
19:39:23  * jmar777quit (Read error: Connection reset by peer)
19:39:46  * jmar777joined
19:48:18  * jmar777quit (Remote host closed the connection)
19:49:34  * jmar777joined
19:51:03  * tomshredsquit (Quit: Linkinus - http://linkinus.com)
19:58:05  <othiym23>is anyone aware of any recent regressions in SunOS libuv that would cause 'Assertion failed: knp->data_type == KSTAT_DATA_INT32'
19:58:38  <othiym23>I'm getting reports of a crash on SmartOS in a library I wrote that's 100% JavaScript, and I've only heard of it happening there
19:58:58  <othiym23>(don't know what versions of node / what SmartMachine version it is yet)
19:59:02  <indutny>I can look into it today
19:59:36  <othiym23>indutny: dscape is the one seeing the issue, he might be able to hook you up with a heapdump / core file ;)
19:59:48  <othiym23>I don't have a repro case yet
20:00:42  <indutny>ahha
20:01:20  <indutny>dscape: yoyoyo
20:01:21  * loladirojoined
20:01:38  <indutny>dscape: ping me on gtalk
20:01:44  <indutny>or skype
20:10:04  * CAPSLOCKBOTquit (Ping timeout: 246 seconds)
20:10:05  * sj26quit (Ping timeout: 246 seconds)
20:10:33  * bradleymeckquit (Quit: bradleymeck)
20:10:36  * sgallaghquit (Ping timeout: 265 seconds)
20:11:55  * russell_hquit (Ping timeout: 246 seconds)
20:12:31  * russell_hjoined
20:13:17  * mjr_joined
20:13:29  * sj26joined
20:26:25  * bradleymeckjoined
20:28:42  * EhevuTovjoined
20:39:06  * TooTallNatequit (Ping timeout: 264 seconds)
20:40:47  * felixgequit (Quit: felixge)
20:42:11  * TooTallNatejoined
20:46:47  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:04:17  * piscisaureus_joined
21:20:15  * hzquit
21:20:47  * hzjoined
21:23:39  * warzjoined
21:23:40  * warzquit (Changing host)
21:23:40  * warzjoined
21:26:34  * TooTallNatequit (Ping timeout: 240 seconds)
21:27:19  * TooTallNatejoined
21:30:22  * AndreasMadsenquit (Read error: Connection reset by peer)
21:31:00  * AndreasMadsenjoined
21:33:13  * jmar777quit (Remote host closed the connection)
21:38:33  * piscisaureus_changed nick to piscisaureus
21:56:33  * rendarquit
21:57:09  * benoitcquit (Excess Flood)
21:57:11  * bradleymeckquit (Quit: bradleymeck)
22:02:35  * benoitcjoined
22:13:18  * piscisaureusquit (Ping timeout: 264 seconds)
22:16:17  * loladiropart
22:24:00  * `3rdEdenquit (Remote host closed the connection)
22:27:58  * benoitcquit (Excess Flood)
22:33:35  * benoitcjoined
22:41:32  <isaacs>good afternoon heroes
22:41:49  <TooTallNate>isaacs: talking in the 3rd person? :p
22:43:51  <roxlu>someone around who knows a bit about SSL? / openssl? I'm trying to write a https client with libuv
22:51:36  * warzquit
22:53:26  * loladirojoined
22:53:53  * AvianFluquit (Remote host closed the connection)
22:57:13  * loladiroquit (Client Quit)
22:57:19  * AndreasMadsenquit (Remote host closed the connection)
22:57:49  <TooTallNate>roxlu: you probably want indutny
22:59:02  <roxlu>indutny: !!! :)
23:00:06  <creationix>who is probably asleep
23:00:18  <TooTallNate>yes it is very late over there :p
23:00:24  <creationix>though pquerna might be able to help too
23:00:30  <TooTallNate>but you also never know with those guys, haha
23:00:47  <roxlu>indutny is dutch right?
23:00:59  <isaacs>roxlu: no, he's russian
23:01:03  <roxlu>oh
23:01:32  * EhevuTovquit (Quit: This computer has gone to sleep)
23:03:31  <isaacs>wow, i didn't just break the debugger tests, the stdin changes completely broke the debugger.
23:03:38  <isaacs>it halts, but you can't get it to go again
23:10:05  * sblomjoined
23:11:09  * AvianFlujoined
23:24:18  * piscisaureus_joined
23:30:16  * loladirojoined
23:32:58  * benoitcquit (Excess Flood)
23:36:17  * loladiroquit (Quit: loladiro)
23:42:41  <isaacs>fuck yeah.
23:42:42  <isaacs>[02:26|% 100|+ 485|- 0]: Done
23:42:51  <isaacs>streams2, stdin, net, everything.
23:43:06  * benoitcjoined
23:47:54  * loladirojoined