00:02:17  * loladiroquit (Ping timeout: 248 seconds)
00:14:24  * indexzeroquit (Quit: indexzero)
00:28:51  * felixgequit (Quit: felixge)
00:33:38  * paddybyersquit (Read error: Network is unreachable)
00:33:53  * paddybyersjoined
00:54:53  * ericktquit (Quit: erickt)
00:56:16  * c4milojoined
01:05:17  * deoxxachanged nick to doexxa
01:06:12  * paddybyersquit (Quit: paddybyers)
01:08:22  <doexxa>so i take it the gyp file for libuv is stable and recommended for use?
01:12:08  <mitsuhiko>i noticed that a uv_close as part of the shutdown often no longer happens
01:12:28  <mitsuhiko>what i think happens is that the refcount drops to zero and the looping stops
01:13:51  <mitsuhiko>any idea how i can deal with that?
01:13:59  <mitsuhiko>(i would prefer my callbacks to still be callde)
01:20:23  * mikealquit (Quit: Leaving.)
01:20:37  * mikealjoined
01:36:46  * abraxasjoined
01:47:53  * theColequit (Quit: theCole)
01:51:29  * theColejoined
01:51:51  * theColequit (Client Quit)
02:35:52  * mikealquit (Quit: Leaving.)
02:44:20  * c4miloquit (Remote host closed the connection)
02:44:40  * mikealjoined
03:07:59  * indexzerojoined
03:25:14  * Ariaquit (Remote host closed the connection)
03:50:06  * indexzeroquit (Quit: indexzero)
03:51:30  * mmaleckiquit (Ping timeout: 240 seconds)
03:54:03  * lohkeyjoined
04:01:49  * AvianFluquit (Quit: Leaving)
04:33:26  * pfox___quit (Remote host closed the connection)
04:37:52  * beachdogquit (Quit: beachdog)
04:44:23  * lohkeyquit (Quit: lohkey)
04:45:27  * pfox__joined
04:46:27  * pfox__quit (Client Quit)
04:55:08  * dshaw_joined
06:24:21  * rendarjoined
06:26:17  * felixgejoined
06:26:17  * felixgequit (Changing host)
06:26:17  * felixgejoined
06:54:13  * stephankquit (Quit: *Poof!*)
07:33:45  * hzjoined
07:40:51  * `3rdEdenjoined
08:03:29  * paddybyersjoined
08:09:16  * mikealquit (Quit: Leaving.)
08:09:35  * charliesomejoined
08:09:46  * theColejoined
08:10:16  * ryahjoined
08:13:28  * mikealjoined
08:17:20  * loladirojoined
08:22:53  * loladiroquit (Quit: loladiro)
08:26:11  * paddybyersquit (Quit: paddybyers)
08:28:35  * loladirojoined
08:30:27  * V1joined
08:30:56  * `3rdEdenquit (Read error: Connection reset by peer)
08:32:51  * theColequit (Quit: theCole)
08:32:58  * loladiroquit (Client Quit)
08:36:54  * V1changed nick to `3rdEden
08:37:58  * TheJHjoined
08:42:07  * piscisaureus_joined
08:58:38  <piscisaureus_>hello
09:06:03  <mitsuhiko>hey
09:06:46  <mitsuhiko>valgrind debugging is quite hard with libuv :(
09:06:59  <mitsuhiko>looks like my uv_close callbacks are not executed on loop shutdown
09:07:30  <mitsuhiko>are there any common workarounds for that
09:07:31  <mitsuhiko>+?
09:12:32  * hzquit (Ping timeout: 272 seconds)
09:17:44  <mitsuhiko>i wonder if that is related to this: https://github.com/joyent/libuv/issues/347
09:21:00  <piscisaureus_>mitsuhiko: that's correct
09:21:18  <piscisaureus_>mitsuhiko: it should make the close callbacks if you called uv_close
09:21:56  <piscisaureus_>mitsuhiko: what you can do is call uv_close for all remaining handles after uv_run returns
09:22:01  <piscisaureus_>and then call uv_run again
09:23:55  * theColejoined
09:23:58  <mitsuhiko>indeed. i can just do that
09:25:09  <mitsuhiko>actually not really
09:25:36  <mitsuhiko>but that's my fault anyways. shutdown order is undefined right now and i need to have one thing shut down later
09:25:45  * mmaleckijoined
09:28:42  <CIA-108>node: koichik reviewme * rbc30c90 / doc/api/cluster.markdown : doc: remove duplicate section (+31 more commits...) - http://git.io/Ou4ToA
09:30:41  <CIA-108>node: Bert Belder reviewme * r9174e0c / (lib/fs.js test/simple/test-regress-GH-3739.js): windows: correctly prep long path for fs.exists(Sync) - http://git.io/VlmcJw
09:30:42  <piscisaureus_>^-- review anyone?
09:37:54  <CIA-108>node: Brian White v0.8 * re06b5d7 / lib/http.js : http: remove duplicate assignments - http://git.io/i4nUYQ
09:38:55  <piscisaureus_>mitsuhiko: well, you can just repeat that trick twice :-)
09:39:04  <mitsuhiko>piscisaureus_: yes :)
09:57:22  <mitsuhiko>piscisaureus_: i have one remainining problem but i am not sure if i can solve it with libuv or if i need to work around it
09:57:35  <mitsuhiko>basically i have a connection to redis and n other connections to clients. when a client disconnects it notifies redis
09:57:44  <piscisaureus_>yes
09:57:56  <mitsuhiko>if all shuts down -> loop ends -> client tells redis -> last ~n disconnecting clients never get response from redis
09:58:08  <mitsuhiko>uv_ref on the redis handle is not doing much
10:00:57  <piscisaureus_>I think you just need to keep a reference count
10:01:18  <piscisaureus_>decrement the count when a client disconnects, and when the counter hits zero close the redis connection
10:01:53  <mitsuhiko>i was hoping i could just uv_ref the redis handle :)
10:04:25  <piscisaureus_>mitsuhiko: you can uv_unref it
10:04:30  <piscisaureus_>mitsuhiko: that also works
10:05:11  * felixgequit (Ping timeout: 264 seconds)
10:05:11  <piscisaureus_>mitsuhiko: I think you are confused... uv_ref is the default state, uv_unref makes something not keep the loop alive
10:05:44  <mitsuhiko>piscisaureus_: shouldn't ref -> refcnt++ and unref -> refcnt--?
10:06:27  <piscisaureus_>mitsuhiko: read that issue you posted earlier to understand what it does
10:06:55  <mitsuhiko>oh
10:07:17  <mitsuhiko>so i need to count myself then
10:08:22  <mitsuhiko>piscisaureus_: just to confirm: does that mean the refcount is [0, 1] and nothing else?
10:09:29  <indutny>рш
10:09:31  <indutny>hi
10:18:32  <mitsuhiko>piscisaureus_: what did you mean by i can uv_unref it?
10:21:17  <ArmyOfBruce>Does anyone do a more Go-like thing on top of libuv? Or most people sticking with callbacks?
10:24:00  * TheJHquit (Read error: Operation timed out)
10:26:19  <mitsuhiko>ArmyOfBruce: what is a "go like thing"?
10:27:06  <ArmyOfBruce>mitsuhiko: coroutine style code.
10:27:23  <mitsuhiko>ArmyOfBruce: i figured as much. but what do you mean with that
10:27:28  <mitsuhiko>if someone wrote a programming language?
10:27:50  <mitsuhiko>for c there is not much you can do unless you start destroying sanity with setjmp
10:28:00  <ArmyOfBruce>mitsuhiko: well, I'm thinking about re-doing the I/O libraries in a language with libuv.
10:28:26  <mitsuhiko>ArmyOfBruce: node.js, potentially rust
10:28:37  <mitsuhiko>node however is still callback based
10:28:58  <ArmyOfBruce>I haven't looked at I/O in Rust, I guess.
10:29:17  <mitsuhiko>ArmyOfBruce: as far as i know it's not at all impressive yet
10:29:27  <mitsuhiko>it's the part i have not looked into much at all yet
10:29:39  <rendar>mitsuhiko: potentially rust? what means?
10:29:58  <mitsuhiko>rendar: from the language design, rust could be amazing for async things :)
10:30:13  <rendar>hm i see :) better than js?
10:30:29  <mitsuhiko>js is not good for async
10:30:41  <mitsuhiko>at least not better than $language
10:30:45  <rendar>why? isn't js most callback based?
10:30:58  <mitsuhiko>rendar: so is c++, python, ruby, php etc.
10:31:06  <mitsuhiko>js by itself is not callback based, node js libraries are
10:31:10  <ArmyOfBruce>mitsuhiko: ahh, I work with opendylan.org ... I'm suggesting that we / they drop a lot of compat and move into a more modern world, wrt threading, I/O, etc.
10:31:20  <rendar>hm, i see, so what offers rust so good for async?
10:31:40  <mitsuhiko>rendar: a language design that supports it
10:31:58  <rendar>ok
10:32:12  <ArmyOfBruce>rendar: there's a lot of nice stuff in Rust for async / concurrent things ... they designed to handle that well. :)
10:32:13  <mitsuhiko>it has tasks, the notion of memory ownership and lifetimes, language designed from scratch etc.
10:34:04  <mitsuhiko>ArmyOfBruce: it's the first language in a long time which i am really looking forward to :)
10:34:31  <ArmyOfBruce>mitsuhiko: it is nice ... just wish it were further along :)
10:34:52  <ArmyOfBruce>must run for a while ... nanny leaving for the day.
10:39:07  * AndreasMadsenjoined
10:51:23  <piscisaureus_>mitsuhiko: yes, refcount = [0, 1]
10:52:17  <mitsuhiko>piscisaureus_: so my naive "fix" (which obviously does not work) was refcount ++ in the send and refcount -- in the receive. So I guess i can't do that with uv board tools?
10:52:42  <piscisaureus_>mitsuhiko: indeed
10:59:45  * hzjoined
11:21:05  <rendar>can rust be bound to C easily?
11:23:44  * hzquit (Disconnected by services)
11:23:45  <CIA-108>node: Peter Rybin v0.8 * r688859a / src/node.cc : debugger: wake up the event loop when a debugger command is dispatched - http://git.io/Wr7J1A
11:23:47  * hzjoined
11:26:20  * hzquit (Remote host closed the connection)
11:29:10  * hzjoined
11:33:40  * c4milojoined
11:37:06  * c4miloquit (Remote host closed the connection)
11:39:49  <mitsuhiko>rendar: yes
11:43:18  * AndreasMadsenquit (Read error: Connection reset by peer)
11:43:32  * AndreasMadsenjoined
11:44:43  * felixgejoined
11:44:43  * felixgequit (Changing host)
11:44:43  * felixgejoined
11:50:12  <piscisaureus_>indutny: hey, yt?
11:50:34  <indutny>piscisaureus_: hey man
11:50:35  <indutny>almost
11:50:42  <indutny>well, yes
11:50:47  <piscisaureus_>indutny: so what part is not there yet?
11:50:55  <piscisaureus_>indutny: can you review this? https://github.com/joyent/node/commit/9174e0cb3581fa4f21cd52db46d51845d0413951
11:51:04  <indutny>I can, but would I?
11:51:36  <indutny>:)
11:51:38  <indutny>I would
11:51:39  <piscisaureus_>indutny: yeah, I cannot answer that question :-)
11:51:44  <piscisaureus_>can you?
11:51:45  * hzquit (Read error: Connection reset by peer)
11:51:48  <indutny>yes, I can
11:51:50  <indutny>one minute
11:51:52  <piscisaureus_>Ok, can you?
11:52:08  <indutny>piscisaureus_: reprise?
11:52:21  <piscisaureus_>:-p
11:52:31  <indutny>piscisaureus_: btw, just wondering
11:52:38  <piscisaureus_>indutny: shoot
11:52:43  <indutny>do you know anyone who has experience in CoreAudio stuff?
11:52:48  <indutny>especially AudioUnits
11:52:54  <indutny>I'm totally f*cked up with that
11:52:56  <piscisaureus_>no, not really
11:52:58  <indutny>ok
11:52:59  <piscisaureus_>really not even
11:53:01  <indutny>just saying
11:53:13  * hzjoined
11:53:36  <piscisaureus_>indutny: I am sure you can just read up on that shit and get it working
11:53:44  <piscisaureus_>but why do you care about CoreAudio?
11:54:12  <piscisaureus_>indutny: <-- https://developer.apple.com/library/mac/#documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/Introduction/Introduction.html
11:54:24  <indutny>thanks man
11:54:27  <indutny>I read that twice
11:54:37  <indutny>the thing is that I need to do one thing
11:54:46  <indutny>which even has an example in apple's documentation
11:54:51  <indutny>but it doesn't work for me
11:55:05  <indutny>(at least not inside my app, going to build plain example)
11:55:09  <indutny>piscisaureus_: so, about your patch
11:55:13  <piscisaureus_>yes
11:55:18  <piscisaureus_>my patch \o/
11:55:29  <indutny>piscisaureus_: basically, you just wrapped path with _makeLong in places where it wasn't wrapped yet
11:55:30  <indutny>right/
11:55:34  <piscisaureus_>yes
11:55:36  <indutny>ok
11:55:37  <indutny>lgtm
11:55:37  <indutny>:D
11:55:39  <piscisaureus_>:-)
11:55:44  <piscisaureus_>I expected as much
11:55:49  <piscisaureus_>but we have to stick to the rules
11:55:53  <indutny>yeah
11:55:55  <indutny>rules are good
11:56:05  <indutny>have you seen my RST patch for libuv?
11:56:24  <indutny>piscisaureus_: https://github.com/joyent/libuv/pull/498
11:56:47  <indutny>Does windows has the same problem?
11:57:05  <piscisaureus_>indutny: the same "problem" yeah
11:57:12  <indutny>well, not a problem
11:57:13  <piscisaureus_>indutny: this is just part of the tcp protocol
11:57:15  <indutny>but a protocol itself
11:57:16  <indutny>:D
11:57:17  <indutny>yeah
11:57:35  <CIA-108>node: Bert Belder v0.8 * r43a0c88 / (lib/fs.js test/simple/test-regress-GH-3739.js): windows: correctly prep long path for fs.exists(Sync) - http://git.io/UKI2qg
11:58:45  <piscisaureus_>indutny: if a tcp client doesn't send a FIN then after a while the server will just time out tho
11:59:05  <piscisaureus_>indutny: why exactly do you need that, unless you really *want* to send a RST packet?
11:59:34  <piscisaureus_>indutny: btw, you should really call that api uv_tcp_set_linger
11:59:41  <piscisaureus_>because that is how people know that option :-)
11:59:42  <mitsuhiko>piscisaureus_: i think i will just add a dummy handle for the duration of the callback
11:59:51  <mitsuhiko>can a timer do that?
12:00:11  * TheJHjoined
12:00:12  <piscisaureus_>ehhh
12:00:15  <mitsuhiko>:D
12:00:19  <piscisaureus_>mitsuhiko: what do you mean?
12:00:40  <piscisaureus_>mitsuhiko: and why would you do X for the duration of a callback? That makes very little sense
12:00:53  <mitsuhiko>piscisaureus_: basically when i send a request to redis i don't want the refcount of the loop to drop
12:00:57  <mitsuhiko>piscisaureus_: idle :)
12:01:01  <mitsuhiko>waiting for the redis response
12:01:13  <piscisaureus_>mitsuhiko: don't do a idle, it will make your loop spin
12:01:18  <indutny>piscisaureus_: yes, set_linger is better
12:01:28  <mitsuhiko>piscisaureus_: it's supposed to wait for the redis response
12:01:32  <indutny>piscisaureus_: well, there's an issue for node
12:01:36  <piscisaureus_>mitsuhiko: just uv_ref the thing when you make a request to redis, then unref when it comes back
12:01:44  <mitsuhiko>piscisaureus_: but it is already ref
12:01:45  <indutny>user is complaining about a lot of FIN_WAIT2 connections
12:01:46  <piscisaureus_>indutny: what issue is that
12:01:59  <indutny>btw, Apple's example does work
12:02:02  <indutny>crap
12:02:04  <piscisaureus_>mitsuhiko: yeah, that's why you need to implement your own refcount I think
12:02:06  <indutny>what am I doing wrong
12:02:18  <piscisaureus_>indutny: init the library first? :-)
12:02:21  <indutny>haha
12:02:27  <mitsuhiko>piscisaureus_: unfortunately easier said than done
12:02:29  <indutny>piscisaureus_: https://github.com/joyent/node/issues/3613
12:05:44  <mitsuhiko>piscisaureus_: can i dump the refcount of the loop somehow?
12:06:24  <piscisaureus_>mitsuhiko: uv_walk.
12:06:37  <mitsuhiko><3
12:10:31  * TheJHquit (*.net *.split)
12:10:31  * rendarquit (*.net *.split)
12:10:31  * dshaw_quit (*.net *.split)
12:10:32  * toothrotquit (*.net *.split)
12:10:32  * einarosquit (*.net *.split)
12:10:32  * voodootikigodquit (*.net *.split)
12:11:03  * TheJHjoined
12:11:03  * rendarjoined
12:11:03  * dshaw_joined
12:11:03  * toothrotjoined
12:11:03  * einarosjoined
12:11:03  * voodootikigodjoined
12:11:17  * rendarquit (Max SendQ exceeded)
12:11:17  * TheJHquit (Max SendQ exceeded)
12:11:55  * TheJHjoined
12:16:41  * rendarjoined
12:17:20  <piscisaureus_>indutny: I am +1 for uv_tcp_set_linger but I am not sure that it is what we need to fix this node issue
12:18:02  <piscisaureus_>indutny: if you disable linger and then close then the tcp stack might discard data from the kernel send buffer ....
12:20:58  <mitsuhiko>piscisaureus_: situations like this make me appreciate threads
12:21:05  <mitsuhiko>pthread_join :P
12:21:41  <piscisaureus_>mitsuhiko: use threads when you want threads
12:21:52  <mitsuhiko>i was joking :)
12:22:28  <mitsuhiko>but libuv's shutdown support could need some love
12:22:28  * TheJHquit (*.net *.split)
12:22:29  * dshaw_quit (*.net *.split)
12:22:29  * toothrotquit (*.net *.split)
12:22:29  * einarosquit (*.net *.split)
12:22:29  * voodootikigodquit (*.net *.split)
12:22:36  <indutny>piscisaureus_: it'll discard
12:23:19  * TheJHjoined
12:23:20  * dshaw_joined
12:23:20  * toothrotjoined
12:23:20  * einarosjoined
12:23:20  * voodootikigodjoined
12:23:32  <piscisaureus_>indutny: that's not really nice unless you really don't care about delivering all the data
12:23:41  <indutny>piscisaureus_: well, that's it
12:23:46  <indutny>piscisaureus_: actually
12:23:57  <indutny>in almost every case - it'll deliver it
12:24:05  <indutny>because .write() is async in node
12:24:13  <indutny>but
12:24:23  <indutny>if packet will be lost and other side will ask to send it again - no way
12:24:27  <indutny>:P
12:24:55  <piscisaureus_>indutny: not really. write() will drop it into the kernel send buffer
12:25:12  <indutny>well, yes
12:25:13  <piscisaureus_>indutny: buf if you turn off linger and then close() the socket the kernel send buffer is deleted
12:25:20  <indutny>I understand
12:25:30  <indutny>key point: "in most of the cases"
12:36:50  * philips_quit (Excess Flood)
12:38:18  * philips_joined
12:42:54  <piscisaureus_>indutny: I think people should just set the linger to a shorter time if they are concerned about this attack
12:43:00  <indutny>no
12:43:03  <indutny>that works in other way
12:43:09  <indutny>non-zero linger and zero linger
12:43:32  <piscisaureus_>indutny: oh wait nonzero linger means that close() blocks right?
12:43:32  <piscisaureus_>hmm
12:43:39  <indutny>yes
12:43:43  <indutny>and behaviour is different
12:44:38  <piscisaureus_>in that case people should do something like
12:44:41  <piscisaureus_>socket.end()
12:44:53  <piscisaureus_>setTimeout(function() { socket.forceClose() }, 1000)
12:45:33  <piscisaureus_>indutny: but I think that this pattern:
12:45:33  <piscisaureus_>linger_off()
12:45:33  <piscisaureus_>write(sock, "bla")
12:45:33  <piscisaureus_>close(sock)
12:45:41  <piscisaureus_>will almost certainly discard data
12:45:44  <piscisaureus_>indutny: ^--
12:46:03  <piscisaureus_>unless people also disable nagle
12:46:05  <indutny>well, the thing is
12:46:09  <indutny>if linger is disabled
12:46:13  <indutny>and it's diabled by default
12:46:18  <indutny>calling close() should discard data too
12:46:23  <piscisaureus_>no
12:46:26  <indutny>the only real difference is that RST packet will be sent
12:46:29  <indutny>no? read source
12:46:32  <indutny>that's how it works
12:46:37  <piscisaureus_>the default mode is that close() doesn't discard data
12:46:43  <indutny>nono
12:46:47  <mitsuhiko>FIGHT
12:46:48  <indutny>default mode is to discard data
12:46:54  <indutny>that's why linger was introduced
12:46:54  <piscisaureus_>it may discard data, but only after 60 s or so
12:47:06  <indutny>it allows close() to wait for acceptance
12:47:12  <indutny>and send all remaining data
12:48:01  <piscisaureus_>indutny: there are a couple of modes:
12:48:04  <piscisaureus_>* linger off
12:48:10  <piscisaureus_>* linger on, in the background (timeout 0)
12:48:19  <piscisaureus_>* linger on, foreground (timeout > 0)
12:48:22  <indutny>huh
12:48:26  <indutny>where have you read this?
12:48:28  <piscisaureus_>indutny: the default mode is linger on, background
12:48:41  <piscisaureus_>indutny: I just know, but I think man 7 socket will tell you too :-)
12:49:13  <indutny>SO_LINGER controls the action taken when unsent messages are queued on socket and a close(2) is performed. If the socket promises reliable delivery of data and SO_LINGER is
12:49:13  <indutny> set, the system will block the process on the close attempt until it is able to transmit the data or until it decides it is unable to deliver the information (a timeout period,
12:49:13  <indutny> termed the linger interval, is specified in the setsockopt() call when SO_LINGER is requested). If SO_LINGER is disabled and a close is issued, the system will process the
12:49:13  <indutny> close in a manner that allows the process to continue as quickly as possible.
12:49:59  <indutny>so basically, last sentence states that it'll do it in any way :P
12:50:05  <indutny>without guarantee
12:50:10  <indutny>though it may work in some cases
12:50:48  <piscisaureus_>indutny: so the thing is, in the default mode close() doesn't discard
12:51:02  <piscisaureus_>indutny: but if it is unable to deliver data, it will after some timeout
12:51:21  <piscisaureus_>indutny: but if you completely turn it off, it will immediately discard everything
12:51:33  <indutny>oh, ok
12:51:35  <indutny>I trust you
12:51:50  <mitsuhiko>piscisaureus_: manual refcounting works. not very nice though, had to wrap all redis calls :(
12:51:54  <piscisaureus_>indutny: that's why destroySoon() works for http in node :-)
12:52:26  <indutny>:)
12:52:32  * chobi_e_changed nick to chobi_e
12:52:42  <piscisaureus_>mitsuhiko: yeah, well, this case is too specific to fix in libuv
12:53:09  <mitsuhiko>piscisaureus_: do you think? i mean, that problem comes up with any more involved loop shutdown
12:53:27  <mitsuhiko>(eg: on disconnect do io operation)
12:54:51  <piscisaureus_>indutny: this has all the info -> http://msdn.microsoft.com/en-us/library/windows/desktop/ms738547%28v=vs.85%29.aspx
12:54:51  <piscisaureus_>indutny: that page is correct (note that windows actually does not implement it correctly, but that's another issue)
12:55:33  <indutny>piscisaureus_: oooh
12:56:17  <indutny>ok
12:56:23  <indutny>how that audio stuff works?!
12:56:27  <indutny>I'm just trying to record some sound
12:58:46  <piscisaureus_>mitsuhiko: loop shutdown could use some love, sure. But what you want - a connection only keeps the loop alive when a particular condition is true - something you need to implement yourself
13:02:19  <piscisaureus_>mitsuhiko: close callbacks should be made before the loop exits - if that doesn't work then that's a bug
13:02:34  <piscisaureus_>mitsuhiko: but only if you called uv_close
13:04:34  * chobi_echanged nick to chobi_e_
13:07:26  <mitsuhiko>piscisaureus_: i call uv_close
13:07:47  <piscisaureus_>mitsuhiko: ok, report that as a bug, them
13:07:49  <piscisaureus_>*then
13:08:10  <piscisaureus_>mitsuhiko: as a workaround, you could uv_ref() just before calling uv_close, maybe that's going wrong somehow
13:08:35  <mitsuhiko>piscisaureus_: i will try to make a testcase later
13:08:39  <piscisaureus_>cool
13:10:30  <indutny>ooooh
13:10:37  <indutny>looks like I got it
13:10:48  <indutny>I was asking AudioUnit to emit data in specific format
13:10:54  <indutny>but it was unable to do that
13:11:08  <indutny>and wasn't returning any error
13:11:12  <indutny>crap, how is that possible
13:11:43  <mitsuhiko>piscisaureus_: i wonder if it's because the redis connection is a uv_poll_t
13:12:05  <piscisaureus_>mitsuhiko: why do you do that, anyway?
13:12:13  <mitsuhiko>piscisaureus_: having a uv_poll_t?
13:12:31  <piscisaureus_>mitsuhiko: yeah. You can just uv_write() redis commands right? Or are you using a library?
13:12:49  <mitsuhiko>piscisaureus_: i'm using hiredis and the async shim
13:13:02  <piscisaureus_>right, ok.
13:13:06  <piscisaureus_>I don't know that, then
13:13:21  <mitsuhiko>it looked easier to start with, maybe it was not the best decision
13:13:25  <piscisaureus_>It's surprising to me that uv_poll would need to be unref'ed at all
13:13:45  <mitsuhiko>piscisaureus_: i never unref it, but i uv_close it
13:13:52  <piscisaureus_>oh
13:14:07  <mitsuhiko>i tried to ref it though to extend its lifetime
13:14:25  <piscisaureus_>that doesn't work
13:14:37  <piscisaureus_>uv_close() just closes it
13:14:42  <mitsuhiko>yeah, that much was obvious :)
13:14:48  <piscisaureus_>that never worked btw
13:15:31  <mitsuhiko>it should not get to to that close in the first place
13:15:53  <mitsuhiko>what happens is that i start the server, it connects to redis, gets clients etc. when the server shuts down it disconnects all clients and writes something to redis
13:15:57  <mitsuhiko>*then* the redis connection closes
13:16:25  <mitsuhiko>so i was expecting uv_run to block until the only remaining thing in there was my redis connection
13:16:32  <mitsuhiko>but as it turns out, uv_run aborts early
13:17:35  <piscisaureus_>have to run, bbl
13:17:37  <mitsuhiko>i will look further into that to find out what's really happening here
13:17:48  <piscisaureus_>good
13:20:05  <mitsuhiko>unrelated: does anyone know which side is at fault if os x decides to no longer accept tcp connections to my thing after ~5000 requests?
13:20:10  <mitsuhiko>i already raised the port range
13:37:49  * dshaw_quit (Quit: Leaving.)
13:38:02  * dshaw_joined
13:44:04  * c4milojoined
13:49:01  * AvianFlujoined
13:50:06  * `3rdEdenquit (Quit: rebooting)
13:53:52  * `3rdEdenjoined
13:58:52  * chobi_e_changed nick to chobi_e
14:13:41  * hzquit
14:15:53  * chobi_echanged nick to chobi_e_
14:35:09  * EhevuTovjoined
14:36:07  <piscisaureus_>Hmm, cloud9 is also seeing a lot of close_wait / fin_wait2 sockets
14:36:16  <piscisaureus_>I think we are leaking sockets, or libuv is
14:39:24  <indutny>well
14:39:55  <indutny>piscisaureus_: http://www.moko.ru/doc/apache/misc/fin_wait_2.html
14:40:12  <indutny>basically, what OS is c9 using?
14:41:12  <piscisaureus_>linux
14:41:47  * chobi_e_changed nick to chobi_e
14:41:58  <indutny>ok, that's nice
14:42:01  <indutny>what kernel version
14:42:26  <piscisaureus_>Ubuntu 12.04 LTS (GNU/Linux 3.2.0-23-virtual x86_64)
14:42:52  <indutny>oh, quite new
14:43:32  <indutny>the thing is
14:44:05  * cryogenjoined
14:44:23  <indutny>something is happening here
14:44:31  <indutny>and it involves black TCP magic
14:45:13  <indutny>I'm quite sure that close() was called on every connection
14:45:15  <piscisaureus_>it's weird
14:45:19  <indutny>since we're using .destroySoon() for TCP
14:45:23  <piscisaureus_>maybe we are just not doing that
14:45:29  <indutny>em...
14:45:30  <piscisaureus_>since this is a websocket proxy
14:45:35  <indutny>why is in FIN_WAIT2 state?
14:45:39  <indutny>oh
14:45:42  <indutny>websocket proxy
14:45:47  <indutny>is it opensource?
14:45:49  <piscisaureus_>maybe we just forgot to close() it :-)
14:45:50  <piscisaureus_>no
14:46:19  <cryogen>howdys folk, i'm having an issue where when i do uv_close(), there are pending_write_reqs so my close_cb is never called
14:46:21  <indutny>well, it's the only real way
14:46:30  <indutny>piscisaureus_: ^^
14:46:35  <indutny>pending write reqs
14:47:36  <piscisaureus_>indutny: yeah, I think the sockets may not be closed. If I look at them with `netstat -ae` they all have an associated inode
14:47:42  <piscisaureus_>so prolly they're still open
14:48:42  <indutny>oh, great
14:49:00  <indutny>well, if uv_close was called - they should be definitely closed
14:49:06  <piscisaureus_>yeah
14:49:14  <indutny>that means the bug is node.js
14:49:16  <indutny>if it's present
14:50:04  * ericktjoined
14:51:11  <indutny>we can try adding dtrace probe into HandleWrap::Close
14:51:29  <indutny>and we should already have a probe for incoming connection
14:53:21  <piscisaureus_>indutny: well, it could be that we are creating persistent connections
14:53:29  <piscisaureus_>indutny: with allowHalfOpen: true
14:53:36  <piscisaureus_>but no 'end' handler or something
14:53:43  <piscisaureus_>where we == cloud9
14:54:52  <piscisaureus_>indutny: dtrace doesn't really work any more since we're now on linux
14:55:05  <indutny>well, yes
14:55:09  <indutny>but voxer is on smartos :P
14:56:26  * hzjoined
14:58:07  <mmalecki>indutny: well, we're too
14:58:18  <indutny>are we experiencing that problems?
14:58:48  <mmalecki>kind-if-ish. ask AvianFlu for details - some connections are not getting closed when they should be
14:58:58  <mmalecki>I didn't really look tho, I was hangover when email came
15:03:45  <indutny>ok
15:05:03  <mmalecki>actually, now that I read the convo, we're dealing with websocket proxy too
15:07:18  <indutny>well, indeed
15:08:14  <mmalecki>indutny: sec, I'll fwd you the mail
15:09:55  <mmalecki>piscisaureus_: hey, what's your email? thought I'd share that one with you too
15:10:00  * TheJHquit (Ping timeout: 240 seconds)
15:12:18  * charliesomequit (Quit: Textual IRC Client: www.textualapp.com)
15:18:33  * dapjoined
15:19:03  <piscisaureus_>mmalecki: bert@c9.io
15:19:25  <piscisaureus_>mmalecki: or bertbelder@gmail.com
15:20:36  <mmalecki>piscisaureus_: thanks. are you guys using node-http-proxy, per chance?
15:20:48  <piscisaureus_>mmalecki: yeah, but it's heavily modified
15:20:58  <piscisaureus_>I don't know if it comes with ws builtin
15:21:13  <mmalecki>piscisaureus_: can you push some changes somewhere?
15:21:29  <mmalecki>we think that we might know the reason for http-proxy leaking sockets like that
15:21:35  <piscisaureus_>mmalecki: maybe, depends
15:21:39  <piscisaureus_>mmalecki: do you have a patch?
15:22:44  <mmalecki>piscisaureus_: yeah, sec, looking
15:25:38  <mmalecki>piscisaureus_, indutny: sent
15:26:27  * theColequit (Quit: theCole)
15:27:27  <mmalecki>piscisaureus_: I think that this might work https://gist.github.com/20e92ded767c2cce3886
15:27:46  <indutny>oh, very rough :P
15:28:03  <indutny>but that's error handling - then ok
15:28:53  <cryogen>im having an issue with uv_close not calling my callback, but it doesn't happen all the time so it seems a bit like a race, it's probably something i'm doing wrong but i'm not really sure what
15:29:08  <cryogen>from what i can tell it seems to be something to do with doing writes inside my read callback
15:31:38  * xaqjoined
15:31:53  <mmalecki>piscisaureus_: we'll be rolling this to load balancers as soon as we deal with DNS problems
15:31:57  <piscisaureus_>cryogen: writing from a read callback is fine.
15:32:13  <piscisaureus_>cryogen: sounds like you are clobbering memory
15:35:53  <cryogen>that is plausible, from the debugging i've done, the code to decrement pending_write_reqs/call the write callback sometimes isn't called
15:37:14  * pfox__joined
15:48:20  * ericktquit (Quit: erickt)
16:03:43  * mmaleckichanged nick to mmalecki[out]
16:04:43  <cryogen>piscisaureus_: turns out you cant reuse the same request for multiple writes, so i think that definitely falls under the category of "doing it wrong"
16:04:47  <cryogen>sorry to bother :)
16:07:49  * theColejoined
16:08:18  * EhevuTovquit (Quit: This computer has gone to sleep)
16:09:43  <tjfontaine>piscisaureus_: now that you're back from oscon ben was waiting on you to review this https://github.com/joyent/node/pull/3707
16:14:22  * xaqquit (Read error: Connection reset by peer)
16:14:59  * xaqjoined
16:20:24  * ericktjoined
16:25:40  <piscisaureus_>tjfontaine: does clearTimeout still work with unref'ed timers?
16:25:55  <piscisaureus_>tjfontaine: also, are setInterval's also unref-able?
16:26:38  <tjfontaine>piscisaureus_: intervals are just timer_wrap's so they get unref/ref from the native layer, and yes see the check in clearTimeout if it's an instance of Timeout
16:28:37  <piscisaureus_>tjfontaine: oh, right - setInterval doesn't use the linked list
16:29:55  <piscisaureus_>yeah lgtm
16:30:35  <tjfontaine>ok I think isaacs is all that's left then
16:31:30  <piscisaureus_>nah, enough reviews :-)
16:31:34  <tjfontaine>hehe ok
16:32:43  <CIA-108>node: Timothy J Fontaine master * r19d43f8 / (4 files): export HandleWrap Unref Ref in tcp/udp/timer/pipe - http://git.io/-yzlXg
16:32:44  <CIA-108>node: Timothy J Fontaine master * r2637b5c / (lib/dgram.js lib/net.js): ref/unref for net.Socket net.Server dgram.Socket - http://git.io/Rp2EEg
16:32:44  <CIA-108>node: Timothy J Fontaine master * rcd6122e / lib/timers.js : add ref/unref to setTimeout timers - http://git.io/p_RUAw
16:32:44  <CIA-108>node: Timothy J Fontaine master * rbdd1a74 / (3 files): add docs for socket/server/timer unref and ref - http://git.io/dkBYNw
16:32:44  <CIA-108>node: Timothy J Fontaine master * r77945d7 / (5 files): add unref/ref tests for socket/server/timers - http://git.io/ZYDisQ
16:33:02  <tjfontaine>yay!
16:33:12  <tjfontaine>thanks piscisaureus_
16:35:43  <CIA-108>node: Bert Belder master * rfebffc1 / (5 files in 4 dirs): Merge branch 'v0.8' (+12 more commits...) - http://git.io/11-A6w
16:35:57  <indutny>wo
16:35:58  <indutny>w
16:41:32  * c4milo_joined
16:41:35  <piscisaureus_>`3rdEden: is observe.it now canned?
16:41:37  * c4miloquit (Ping timeout: 260 seconds)
16:41:47  <piscisaureus_>`3rdEden: or are you jitsu-ing part time?
16:42:03  <`3rdEden>piscisaureus_ nope, I still had a regular day job when working on observe.it
16:42:18  <`3rdEden>so that job just changed to nodejitsu
16:42:22  <piscisaureus_>ah, right
16:42:28  <piscisaureus_>makes sense :-)
16:42:33  <`3rdEden>observe.it is still work in progress (slow, but still progress)
16:42:54  <piscisaureus_>`3rdEden: do you think it will get there?
16:43:00  <`3rdEden>observe.it would be ideal for eating my own dog food at nodejitsu, once i host it there
16:43:22  <`3rdEden>piscisaureus_ the biggest problem is the real-time part
16:43:50  <`3rdEden>it doesn't scale as well as it should and it doesn't work in most enterprise envs
16:43:52  * avalanche123joined
16:43:53  <piscisaureus_>`3rdEden: why? I though you were a socket.io expert
16:44:03  <piscisaureus_>yeah, that is something we noticed as well :-)
16:44:04  <`3rdEden>piscisaureus_ socket.io isn't for each usecase
16:44:31  <einaros>:O
16:44:44  <`3rdEden>einaros :o
16:44:52  <`3rdEden>yes I said that out loud.
16:45:00  <piscisaureus_>:0
16:45:08  <einaros>oh, I was just yawning :P
16:45:13  <`3rdEden>=p
16:46:09  <`3rdEden>piscisaureus_ what i need a real-time connection tied to real-time event processing
16:47:10  <`3rdEden>and in addition to that it should actually work for enterprise users
16:48:07  <piscisaureus_>Yeah, I suppose that was sort of your target audience
16:48:30  <einaros>that's where the cash is at
16:49:17  <`3rdEden>piscisaureus_ isn't cloud9 hitting tons of firewall issues btw?
16:49:21  <piscisaureus_>yes
16:49:31  <piscisaureus_>it's terrible
16:49:50  <piscisaureus_>until recently we had websockets disabled completely and now we're trying to turn it back on
16:49:57  <piscisaureus_>but there's always another problem with them
16:50:34  <`3rdEden>Yep
16:50:54  <piscisaureus_>supposedly socket.io 1.0 would be better in that regard
16:51:10  <`3rdEden>well atleast you guys are already running on a secure connection, so that does help
16:51:14  <einaros>better/saner
16:51:26  <piscisaureus_>`3rdEden: well, that has been only for a week or so :-)
16:51:34  <`3rdEden>oh :p
16:51:54  <piscisaureus_>`3rdEden: that was also a big source of problems. When people use a 3g connection telco's like fiddling with your html etc
16:52:13  <`3rdEden>yes, it's cached by providers
16:52:16  <`3rdEden>good stuff
16:52:17  <piscisaureus_>not only that
16:52:20  <piscisaureus_>they minify
16:52:22  <piscisaureus_>in broken ways
16:52:22  * chobi_echanged nick to chobi_e_
16:52:29  * dshaw_quit (Quit: Leaving.)
16:52:31  <`3rdEden>oh yeh that also does suck
16:52:42  <einaros>awesome
16:52:53  <indutny>encrypt all the stuff
16:53:07  <piscisaureus_>yes, that seems to be the only relief
16:53:08  <einaros>I sure am glad I don't develop web stuff for the masses
16:54:08  * dshaw_joined
16:56:59  <`3rdEden>Well luckly we have indentified most of the issues surrounding websockets by now and we can finally start building propper solutions around those issues
16:57:14  <piscisaureus_>yeah
16:57:24  <piscisaureus_>also toss out the flash and the forever iframe cruft
16:57:29  <piscisaureus_>I've never seen it working
16:57:43  <`3rdEden>forever iframe only works on IE piscisaureus_
16:57:54  <`3rdEden>and that's probably not your primary browser ;)
16:58:15  <piscisaureus_>why care?
16:58:20  <piscisaureus_>xhr polling also works right?
16:58:25  <piscisaureus_>maybe not in IE6
16:58:27  <`3rdEden>because it's faster and more effecient than polling
16:59:14  <`3rdEden>but the transports list of socket.io should always depend on your use-case
17:00:32  * lohkeyjoined
17:04:24  <einaros>the whole flashsocket thing is nasty. perhaps required nastiness in some cases, but nasty nonetheless.
17:05:46  <mitsuhiko>what browser needs the flashsocket anyways
17:06:07  <einaros>internut explohrur
17:06:36  <einaros>and opera, since they are being awkward and lazy
17:06:49  <tjfontaine>whatever happened to facebook buying them
17:07:02  <mitsuhiko>einaros: nobody cares about opera
17:07:17  <mitsuhiko>and internet explorer does fine with having a http connection open that streams stuff in
17:08:12  <einaros>streaming makes error handling difficult
17:09:05  <`3rdEden>einaros sure, the whole flash socket needs to have an overhaul and actually use proper flash instead of some crappy file that emulates a websocket interface + framing
17:09:30  <`3rdEden>it's tomuch pointless overhead.. Just use a plain flash socket and connect net.Server and your done =/
17:11:51  <einaros>I, for one, will never do that overhaul :p
17:13:18  <einaros>flash was dead to me in 2008
17:14:08  <`3rdEden>einaros I might, when someone comes knocking at my door with a huge sack of dollar bills
17:16:02  <einaros>kickstarter!
17:16:33  <einaros>I'm sure it'll make you all of $17
17:16:59  * EhevuTovjoined
17:17:27  <tjfontaine>I think he just wants to go to the strip club
17:18:11  <einaros>strippers dig flash like there's no tomorrow
17:18:29  <einaros>male strippers, I might add
17:18:45  <isaacs>piscisaureus_: So, what would it take to get process.emit('idle') to work, you think?
17:19:19  <isaacs>piscisaureus_: also, we should add process.emit('beforeExit'), which would emit when the event loop is empty, but before it's been shut down
17:19:38  * TooTallNatejoined
17:20:56  * ericktquit (Quit: erickt)
17:25:24  <tjfontaine>isaacs: how would beforeExit be used? would it allow you to add more events and eventually have the callback hit again?
17:26:39  <piscisaureus_>isaacs: beforeExit would be good I suppose
17:27:10  <piscisaureus_>isaacs: 'idle' -> we need something like that, but you should be aware that that would be a "magic" watcher like on('SIGINT')
17:27:18  <piscisaureus_>e.g. attaching a handler has side effects
17:32:14  <isaacs>i think that's fine
17:32:26  <isaacs>you mean, like, the event won't fire unless you've attached listeners?
17:32:34  <isaacs>and it'll make under-the-hood jiggery pokery happen?
17:32:56  <isaacs>tjfontaine: yes.
17:33:33  <isaacs>tjfontaine: like window.onbeforeunload
17:33:47  <isaacs>if you prevent the unload, then the user stays there, and eventually it might fire again
17:34:05  <isaacs>this is actually really nice, if you have workers consuming a queue
17:34:13  * felixgequit (Quit: felixge)
17:35:08  <isaacs>you can handle spikes by spinning up more workers, and mark the extras as temporary. the temp workers can check for new work in process.on('beforeExit'), and if there's nothing to do, just die naturally.
17:36:09  <isaacs>or other use cases, as well, like deleting temp files and such
17:36:28  <isaacs>yes, you can do that with fs.*Sync methods, but you can't make a network request then
17:52:07  * ericktjoined
17:53:34  <tjfontaine>nod
18:02:34  * TheJHjoined
18:07:01  * dshaw_quit (Quit: Leaving.)
18:13:30  <piscisaureus_>isaacs: so why hAVE IDLE BE AN EVENT AND NOT A METHOD LIKE NEXTtICK?
18:13:59  <piscisaureus_>er, that's what you get for typing while looking at another page --^
18:18:34  * hzquit (Disconnected by services)
18:18:37  * hzjoined
18:21:33  <mitsuhiko>what happend with loudbot :(
18:22:53  * mikealquit (Quit: Leaving.)
18:28:05  * mikealjoined
18:36:33  <isaacs>piscisaureus_: heh
18:37:01  <isaacs>piscisaureus_: so you'd do: process.idle(funciton () { doSomeWork() })
18:37:14  <isaacs>piscisaureus_: i think because you typically have something that needs to get repeated.
18:37:30  <isaacs>a method is kind of lame for this (as evidenced by how lame it is using nextTick for this)
18:37:40  <isaacs>if you DO want it to happen once, you can do process.once('idle', doStuff)
18:38:02  <isaacs>but i guess if there's underlying magic, then a method is a little bit better, since you only have to fire when it's absolutely necessary
18:38:37  <isaacs>mitsuhiko: i think loudbot got kicked at some point because we could not use the louds responsibly
18:39:19  * xaqquit (Read error: Connection reset by peer)
18:39:57  * xaqjoined
18:46:25  <TooTallNate>isaacs: nopt is messing with me
18:46:56  <TooTallNate>$ node-gyp rebuild --with-jpeg --with-gif
18:47:13  <TooTallNate>^ that gets interpreted as { 'with-jpeg': '--with-gif' } :(
18:48:24  * theColequit (Quit: theCole)
18:52:39  * blackorzarjoined
18:53:48  <indutny>where is ben?
18:54:52  <TooTallNate>i'll open an issue
18:56:46  <indutny>about ben?
18:59:35  <TooTallNate>yup
18:59:43  <TooTallNate>jk :p
19:02:01  * lohkey_joined
19:03:07  <TooTallNate>isaacs: re: nopt https://github.com/isaacs/nopt/issues/16
19:05:32  * lohkeyquit (Ping timeout: 276 seconds)
19:05:32  * lohkey_changed nick to lohkey
19:11:34  * Skomskijoined
19:12:39  * Skomskiquit (Client Quit)
19:13:17  * Skomskijoined
19:14:46  * Skomskiquit (Client Quit)
19:14:55  <TooTallNate>piscisaureus_: what's that program on windows to check linker status?
19:15:03  <TooTallNate>like missing dll's
19:15:23  <piscisaureus_>TooTallNate: http://www.dependencywalker.com/
19:15:30  <isaacs>TooTallNate: commented
19:16:11  * `3rdEdenquit (Quit: brb, switching to laptop)
19:16:12  <piscisaureus_>isaacs: the magic is, that if you have an idle callback the loop will spin instead of putting the process to sleep
19:16:31  <piscisaureus_>I think ben has a day off today
19:16:41  <isaacs>piscisaureus_: process.idle(cb) is fine, i guess
19:16:53  <piscisaureus_>isaacs: I am in doubt too :-)
19:17:02  <piscisaureus_>isaacs: I don't like process.idle either ...
19:17:06  <isaacs>piscisaureus_: i mean, it is sort of like "do this once you're idle", rather than "let me know every time you're idle"
19:17:15  <piscisaureus_>I was just wondering what your motivations were...
19:17:21  <piscisaureus_>yeah
19:17:35  <isaacs>piscisaureus_: i want something to give people when i take away their nextTick-as-idle-work-scheduler use-case.
19:17:48  <isaacs>piscisaureus_: so that we can get rid of tickDepth eventually
19:17:53  <piscisaureus_>isaacs: yes!!
19:18:01  <isaacs>i think 0.9 is too soon to make nextTick starve the loop indefinitely.
19:18:05  <piscisaureus_>isaacs: we should do away with tickDepth before 0.10 :-)
19:18:30  <piscisaureus_>isaacs: or - keep it, but print a warning instead
19:18:37  <isaacs>well, i'm thinking, we should make it fixed at 1000, and have it print a warn whenever it hits, but still behave the way it does now.
19:19:00  <isaacs>so programs relying on non-starvation will get weirdly slow, and show warnings about how to fix it, but not break completely
19:19:10  <isaacs>then in 0.11, we remove it entirely
19:20:06  <piscisaureus_>I have to run
19:20:11  <isaacs>ok, have fun
19:20:26  <piscisaureus_>I didn't say "I have to fun"
19:20:30  <tjfontaine>heh
19:20:34  <piscisaureus_>although that would be fine too
19:20:38  <isaacs>hahah
19:20:46  <isaacs>well, i wish you the best on your boring running, then
19:21:40  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:25:42  * c4milo_quit (Remote host closed the connection)
19:26:47  * c4milojoined
19:35:37  * `3rdEdenjoined
19:40:47  <mitsuhiko>isaacs: sad :-(
19:54:30  * hzquit
19:57:42  * piscisaureus_joined
20:08:46  * avalanche123quit (Ping timeout: 255 seconds)
20:11:43  * avalanche123joined
20:28:00  * piscisaureus_quit (Ping timeout: 240 seconds)
20:30:24  * xaqquit (Read error: Connection reset by peer)
20:30:58  * xaqjoined
20:35:01  * mmalecki[out]changed nick to mmalecki
20:35:11  * xaqquit (Read error: Connection reset by peer)
20:37:19  * xaqjoined
20:37:59  * AndreasMadsenquit (Remote host closed the connection)
20:38:16  * `3rdEdenquit (Quit: Going to bed, gnite)
21:00:25  * xaqquit (Read error: Connection reset by peer)
21:00:29  * felixgejoined
21:00:58  * xaqjoined
21:05:05  * lohkeyquit (Quit: lohkey)
21:06:00  * lohkeyjoined
21:07:09  * c4miloquit (Remote host closed the connection)
21:34:34  * AvianFluchanged nick to Away-vianFlu
21:34:43  * pooyajoined
21:44:58  * cryogenquit (Quit: leaving)
22:01:30  * TheJHquit (Ping timeout: 252 seconds)
22:03:51  * felixgequit (Quit: felixge)
22:11:50  * lohkeyquit (Remote host closed the connection)
22:11:59  * lohkeyjoined
22:20:07  * avalanche123quit (Ping timeout: 248 seconds)
22:21:22  * hzjoined
22:22:02  * avalanche123joined
22:27:57  * rendarquit
22:28:15  * philips_quit (Excess Flood)
22:28:21  * philips_joined
22:33:04  * hzquit (Ping timeout: 272 seconds)
22:42:13  * philips_quit (Excess Flood)
22:42:21  * philips_joined
22:49:01  <pooya>anyone familiar with ev-emul.h here? @isaacs ?
22:54:11  <isaacs>pooya: what's up?
22:54:30  <isaacs>pooya: that was bnoordhuis's doing, but i was the one who complained until he wrote it :)
22:55:05  <isaacs>TooTallNate: Is it possible to use require('readline') and not echo the output as the user types?
22:55:58  <pooya>yeah, i noticed him (mostly) and you working on the file
22:56:10  <pooya>well, to me it looks like this hack is actually not working https://github.com/joyent/node/blob/master/src/ev-emul.h#L215
22:56:24  <pooya>for node-zookeeper
22:56:40  <pooya>i think it is supposed to restart timer with a new value
22:56:42  <TooTallNate>isaacs: hmm, no i don't think so
22:57:02  <TooTallNate>isaacs: that's basically just setRawMode(true) and listening for "data" events
22:57:15  <isaacs>right, except it's a little different..
22:57:24  <isaacs>since "data" events are not specific.
22:57:28  <TooTallNate>isaacs: you might be able to hack it by forcing "terminal: false" and then calling setRawMode(true) manually afterwards
22:57:36  <isaacs>you actually need to listen for data events, then split on \n, then maybe echo the rest.
23:00:42  <TooTallNate>isaacs: my hack idea didn't work :p what's wrong with your read module?
23:01:01  <isaacs>TooTallNate: my read module is bullshit. it neds to die :)
23:01:22  <isaacs>TooTallNate: more specifically, it needs to be a light wrapper around require('readline')
23:01:32  <isaacs>can i set the output stream to something other than stdout, adn have it just go nowhere?
23:01:52  <TooTallNate>ya you could try that
23:02:16  <isaacs>oh, no, because i need it to write the prompt
23:03:20  <TooTallNate>ya i guess now that you mention it, there's no way built-in to node to read a password prompt
23:08:11  <pooya>aha, found it. libuv says "Note that if the repeat value is set from a timer * callback it does not immediately take effect."
23:09:09  <isaacs>TooTallNate: i guess i could just write a pass-through stream that has a mute button
23:09:13  * xaqquit (Remote host closed the connection)
23:09:16  <isaacs>that'd be pretty easy, actually
23:09:18  * theColejoined
23:10:31  * theColequit (Client Quit)
23:11:07  * Away-vianFluchanged nick to AvianFlu
23:12:40  * theColejoined
23:12:56  * c4milojoined
23:29:52  * TooTallNatequit (Ping timeout: 252 seconds)
23:32:17  * TooTallNatejoined
23:34:47  * c4miloquit (Remote host closed the connection)
23:44:58  * chobi_e_changed nick to chobi_e
23:50:18  * chobi_echanged nick to chobi_e_
23:57:05  * c4milojoined