00:00:26  <bnoordhuis>tjfontaine: yeah. bug report handling always seems to end up with me
00:00:35  <bnoordhuis>it's not a glamorous job but someone's gotta do it
00:00:54  <tjfontaine>heh
00:01:14  <tjfontaine>well I'm not convinced its a github error they all say updated 2 hours ago in my view
00:04:39  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:05:02  * pooyaquit (Quit: pooya)
00:05:20  * stagasquit (Read error: Connection reset by peer)
00:11:11  * TooTallNatejoined
00:11:40  * dapquit (Quit: Leaving.)
00:24:29  <tjfontaine>is mingw a supported build platform now that there is proper win32 support?
00:24:49  <TooTallNate>tjfontaine: gyp doesn't support it
00:24:59  <tjfontaine>ok fair enough
00:25:43  * dshaw_quit (Quit: Leaving.)
00:28:18  * bnoordhuisquit (Ping timeout: 240 seconds)
00:28:54  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:46:46  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:46:55  * xaqquit (Remote host closed the connection)
00:48:05  * TooTallNatejoined
00:48:58  * TheJHquit (Ping timeout: 240 seconds)
00:59:25  * chobi_e_changed nick to chobi_e
01:02:05  * ggreerquit (Excess Flood)
01:02:37  * AngryParsleyjoined
01:02:40  * AngryParsleyquit (Changing host)
01:02:40  * AngryParsleyjoined
01:03:07  <felixge>TooTallNate: got face recognition to work!
01:03:09  * AngryParsleyquit (Excess Flood)
01:04:07  <TooTallNate>felixge: wow dude, awesome
01:04:14  <TooTallNate>i should just order mine now
01:04:23  <TooTallNate>so i'm not tempted to pay for overnight shipping in a couple weeks :D
01:04:44  * chobi_echanged nick to chobi_e_
01:05:01  <TooTallNate>felixge: great looking module btw
01:05:06  <TooTallNate>does it depend on ffmpeg?
01:05:20  * ggreerjoined
01:06:03  <felixge>TooTallNate: no, but you need ffmpeg if you want access to the video stream
01:06:10  <felixge>which right now I'm exposing as pngs … :)
01:06:21  <TooTallNate>what's the input source?
01:06:42  <TooTallNate>what kind of video data i mean
01:13:21  <felixge>h264
01:13:34  <felixge>with some weird modifications they did
01:13:41  <felixge>but ffmpeg just swallows that as warnings
01:13:42  <felixge>:)
01:18:07  <felixge>alright sleep
01:20:24  <TooTallNate>felixge: sleep well
01:21:19  * felixgequit (Quit: felixge)
01:21:35  * abraxasjoined
01:22:26  * felixgejoined
01:22:36  * felixgequit (Client Quit)
01:53:55  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:14:31  * piscisaureus_joined
02:14:37  * piscisaureus_quit (Client Quit)
02:32:29  * joe__quit (Quit: This computer has gone to sleep)
02:55:05  * piscisaureus_joined
02:55:08  * piscisaureus_quit (Client Quit)
03:05:58  * ericktquit (Quit: erickt)
03:08:40  * c4milojoined
03:13:33  * c4miloquit (Remote host closed the connection)
03:14:16  * piscisaureus_joined
03:14:21  * ericktjoined
03:14:21  * piscisaureus_quit (Remote host closed the connection)
03:14:43  * c4milojoined
03:16:08  * lohkeypart
03:17:18  * erickt_joined
03:20:47  * ericktquit (Ping timeout: 264 seconds)
03:20:55  * brsonquit (Read error: Operation timed out)
03:23:27  * erickt_quit (Ping timeout: 246 seconds)
03:37:12  * pooyajoined
03:45:53  * pooyaquit (Quit: pooya)
03:47:34  * mordy___joined
04:05:27  * piscisaureus_joined
04:05:33  * piscisaureus_quit (Client Quit)
04:22:56  * beachdogquit (Quit: beachdog)
04:24:10  * brsonjoined
04:28:24  <isaacs>ircretary: tell bnoordhuis NODE_MODULE_VERSION commits lgtm. thanks.
04:28:24  <ircretary>isaacs: I'll be sure to tell bnoordhuis
04:28:56  * pooyajoined
04:36:14  * ericktjoined
04:38:15  * EhevuTovjoined
04:40:49  * blackorzarquit (Read error: Connection reset by peer)
04:53:12  <isaacs>ircretary: tell piscisaureus_ Buffering some data internally is not so bad. if libuv can only do a socket.read(cb) method, then we can buffer a bit in js-land pretty easily. That's not really as nice, but we have to do it for fs streams anyway.
04:53:12  <ircretary>isaacs: I'll be sure to tell piscisaureus_
04:54:02  <isaacs>ircretary: tell piscisaureus_ but yes, it is exactly the unix model all over again. unix is the right model here ;)
04:54:03  <ircretary>isaacs: I'll be sure to tell piscisaureus_
04:55:31  * pooyaquit (Quit: pooya)
04:56:35  * joe__joined
05:04:47  * c4miloquit (Remote host closed the connection)
05:17:26  * c4milojoined
05:24:11  * AvianFluquit (Quit: Leaving)
05:27:32  * c4miloquit (Remote host closed the connection)
05:37:37  * joe__quit (Quit: This computer has gone to sleep)
05:41:37  * blackorzarjoined
05:57:19  * lohkeyjoined
06:26:16  * felixgejoined
06:26:16  * felixgequit (Changing host)
06:26:17  * felixgejoined
06:30:24  * lohkeyquit (Quit: lohkey)
06:51:43  * ericktquit (Quit: erickt)
06:55:58  * charliesomejoined
06:59:49  * rendarjoined
06:59:51  * stephankquit (Quit: *Poof!*)
07:09:48  * EhevuTovquit (Quit: This computer has gone to sleep)
07:14:30  * rendarquit
07:16:22  * rendarjoined
07:17:43  * paddybyersjoined
07:27:29  * brsonquit (Remote host closed the connection)
07:28:56  * `3rdEdenjoined
08:36:26  * felixge_joined
08:36:26  * felixge_quit (Changing host)
08:36:26  * felixge_joined
08:37:47  * felixge_quit (Client Quit)
08:38:19  * hzjoined
08:40:18  * felixgequit (Ping timeout: 240 seconds)
08:43:47  * AlbireoXchanged nick to AlbireoX`Away
08:54:58  * felixgejoined
08:54:59  * felixgequit (Changing host)
08:54:59  * felixgejoined
08:55:38  * felixgequit (Client Quit)
09:03:42  * dshaw_joined
09:32:48  * hzquit (Disconnected by services)
09:32:50  * felixgejoined
09:32:51  * hzjoined
09:41:00  * felixgequit (Quit: http://www.debuggable.com/)
09:41:56  * paddybyers_joined
09:44:21  * paddybyersquit (Ping timeout: 272 seconds)
09:44:22  * paddybyers_changed nick to paddybyers
09:50:38  * blackorzarquit (Remote host closed the connection)
09:53:23  * TheJHjoined
10:08:28  * saghuljoined
10:10:51  * saghulquit (Client Quit)
10:11:18  * beachdogjoined
10:11:19  * hzquit
10:11:39  * hzjoined
10:12:04  * saghuljoined
10:12:21  * beachdogquit (Client Quit)
10:12:46  * beachdogjoined
10:15:16  * hzquit (Read error: Connection reset by peer)
10:16:28  * hzjoined
10:23:40  * beachdogquit (Remote host closed the connection)
10:26:24  * mmaleckijoined
11:01:41  * micheiljoined
11:38:44  * `3rdEdenquit (Quit: Leaving...)
11:40:12  * bnoordhuisjoined
12:05:39  * `3rdEdenjoined
12:05:53  * abraxasquit (Remote host closed the connection)
12:06:42  * abraxasjoined
12:25:24  * mmaleckiquit (Read error: Connection reset by peer)
12:27:33  <indutny>bnoordhuis: hey man
12:27:39  <bnoordhuis>indutny: ho man
12:27:48  <indutny>bnoordhuis: so linger stuff is really complicated
12:27:53  <indutny>therefore I'm asking
12:27:55  <indutny>do we need it? :D
12:28:12  <indutny>btw, do you feel interest in programming audio on linux?
12:28:41  <bnoordhuis>indutny: programming audio on linux? why do you ask?
12:28:50  <indutny>bnoordhuis: I'm doing VoIP for node.js
12:28:55  <indutny>and have working audio bindings for osx
12:29:17  * mmaleckijoined
12:30:04  <bnoordhuis>indutny: i've done a lot of alsa programming in the past
12:30:17  <bnoordhuis>which heartily convinced me that alsa is the worst api ever
12:30:35  <indutny>hahaha
12:30:42  <indutny>you hadn't worked with CoreAudio
12:30:47  <indutny>though they all are the worst
12:31:28  <bnoordhuis>re linger - yes, i think we're going to need it
12:31:36  <bnoordhuis>the FIN_WAIT2 issue is a real problem
12:31:59  <bnoordhuis>but maybe we can cheat and simply always set it
12:33:24  <indutny>bnoordhuis: that won't work
12:33:29  <indutny>it really does broke some clients
12:33:38  <indutny>so I think we should have an option for it in node
12:33:47  <indutny>like .forceDestroy()
12:33:49  <bnoordhuis>hrm, too bad - albeit not too surprising
12:33:58  <indutny>and people who is experiencing problems may choose to use it
12:34:18  <indutny>in case of positive linger timeout
12:34:30  <indutny>as I understand - we should do it in other thread
12:35:15  <bnoordhuis>that probably won't work either for two reasons
12:35:21  <bnoordhuis>a) it's hideously expensive
12:35:35  <indutny>race conditions?
12:35:35  <bnoordhuis>b) uv_close guarantees that file descriptor backed handles close synchronously
12:35:44  <indutny>yeah, ok
12:35:58  <indutny>well, let's not allow setting linger then
12:36:02  <indutny>just enable/disable linger=0
12:36:19  <bnoordhuis>that's probably best
12:36:36  <bnoordhuis>but let it simmer for now, maybe one of us thinks up a brilliant solution yet
12:36:49  <indutny>ok
12:39:33  <indutny>so, about async session storage
12:39:55  <bnoordhuis>yes?
12:39:58  <indutny>bnoordhuis: I've just fixed that deoptimization
12:40:02  <indutny>any other objections?
12:40:24  <bnoordhuis>indutny: i only reviewed half of it last night
12:40:28  <indutny>ok
12:40:39  <indutny>just ping me when you'll finish then
12:42:32  <bnoordhuis>will do
12:45:26  <CIA-108>libuv: Ben Noordhuis master * r9f59e8e / include/uv.h : include: update uv_close documentation - http://git.io/LSlYPQ
12:47:16  * travis-cijoined
12:47:16  <travis-ci>[travis-ci] joyent/libuv#499 (master - 9f59e8e : Ben Noordhuis): The build is still failing.
12:47:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ad382bcac0d0...9f59e8e38c2f
12:47:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1969046
12:47:16  * travis-cipart
12:47:42  <indutny>bnoordhuis: what about async_t ?
12:47:50  <indutny>does it callback called with err=-1 too?
12:48:05  * hzquit (Disconnected by services)
12:48:08  * hzjoined
12:48:11  <bnoordhuis>indutny: no
12:48:53  <bnoordhuis>indutny: but uv_async_t never has any reqs associated with it
12:49:08  <bnoordhuis>indutny: that comment is only relevant for uv_tcp_t, uv_udp_t, etc.
12:49:11  * c4milojoined
12:54:34  * c4miloquit (Remote host closed the connection)
12:55:59  <bnoordhuis>where is that bert belder guy when you need him? >:(
13:01:32  * `3rdEdenquit (Quit: Leaving...)
13:01:39  * hzquit
13:04:15  * `3rdEdenjoined
13:18:09  <CIA-108>libuv: Ben Noordhuis master * rcf05c5f / (8 files in 4 dirs): Raise UV_ECANCELED on premature close. - http://git.io/4Tq5aw
13:20:03  * travis-cijoined
13:20:03  <travis-ci>[travis-ci] joyent/libuv#500 (master - cf05c5f : Ben Noordhuis): The build is still failing.
13:20:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/9f59e8e38c2f...cf05c5f0d6af
13:20:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1969261
13:20:03  * travis-cipart
13:31:15  * AvianFlujoined
13:38:57  <tjfontaine>bnoordhuis: alsa is terrible, but there's always jack :)
13:40:15  <bnoordhuis>tjfontaine: yeah. pulseaudio isn't bad either from what i've seen of it
13:40:26  <tjfontaine>indeed
13:42:59  * mmaleckiquit (Ping timeout: 264 seconds)
13:53:37  * piscisaureusjoined
13:53:48  <piscisaureus>bnoordhuis: sup?
13:54:16  * bnoordhuislooks up
13:54:18  <bnoordhuis>the ceiling?
13:55:38  <bnoordhuis>piscisaureus: so what have you been up to?
13:55:56  <piscisaureus>bnoordhuis: I would have told you yesterday at the meeting
13:56:20  <piscisaureus>bnoordhuis: but nothing, really. OSCON. Fixing the proxy. Transferring stuff to my new macbook.
13:56:48  <piscisaureus>What does one use to write C on a mac?
13:56:53  <piscisaureus>I can't vim
13:57:00  <piscisaureus>And xcode sucks monkey balls
13:57:11  <tjfontaine>why can't you vim? also TextMate
13:57:21  <piscisaureus>so I was trying eclipse but the eclipse cdt generator in gyp is not very good
13:57:43  <tjfontaine>oh man eclipse, *shudder*
13:58:00  <bnoordhuis>piscisaureus: ed!
13:58:04  <piscisaureus>It's not quite as good as visual studio
13:58:06  <tjfontaine>heh
13:58:13  <indutny>haha
13:58:14  <piscisaureus>bnoordhuis: I can do edlin but not ed
13:58:16  <tjfontaine>piscisaureus: that's an understatement of the week
13:58:21  <indutny>piscisaureus: sublime?
13:58:37  <indutny>piscisaureus: I actually fell pretty comfortable with iTerm2+vim
13:58:40  <bnoordhuis>eclipse is pretty good for navigating source, better than the cscope plugin for vim
13:58:50  <indutny>bnoordhuis: oh man, why do you need it?
13:58:51  <piscisaureus>that's what I need it for
13:58:57  <indutny>errr
13:59:03  <indutny>you guys speaking about nasty things!
13:59:04  <tjfontaine>oh
13:59:11  <piscisaureus>I can do without auto complete but I just want to hit f12 and jump to a definition
13:59:25  <piscisaureus>for just editing text sublime is pretty much unbeatable
13:59:49  <piscisaureus>(unless you're an emacs priest or a vim jedi)
14:01:00  <tjfontaine>I guess there's always qtcreator
14:01:13  <bnoordhuis>i never got around to writing much in emacs but it's pretty good for playing tetris
14:01:24  <mitsuhiko>piscisaureus: c on the mac? vim or kill yourself really
14:02:28  <mitsuhiko>(well, or any other text editor)
14:03:15  <tjfontaine>lets see what the gyp xcodeproj looks like for node
14:05:24  <CIA-108>libuv: Ben Noordhuis master * r9123482 / include/uv.h : include: update confusing uv_write comment - http://git.io/RrxAog
14:07:17  * travis-cijoined
14:07:17  <travis-ci>[travis-ci] joyent/libuv#501 (master - 9123482 : Ben Noordhuis): The build is still failing.
14:07:17  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/cf05c5f0d6af...912348261e68
14:07:17  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1969589
14:07:17  * travis-cipart
14:09:05  <piscisaureus>isaacs' readable streams proposal is really not going to work on windows
14:09:21  <piscisaureus>can't we just do reading in a way similar to writing?
14:09:37  <piscisaureus>stream.read(function(err, buffer) {
14:13:45  * c4milojoined
14:13:51  <piscisaureus>it also maps much more cleanly onto the libuv api
14:14:45  <piscisaureus>we could just add uv_read(stream, req, (optional) alloc_cb, (optional) buf, read_cb)
14:43:38  <piscisaureus>ircretary: tell isaacs that ^
14:43:38  <ircretary>piscisaureus: I'll be sure to tell isaacs
14:44:00  <piscisaureus>Eclipse's C analysis is pretty good
14:44:12  <piscisaureus>Almost on par with vc
14:44:25  <piscisaureus>I can't build from eclipse but that's just a minor chore.
14:46:25  <tjfontaine>hmm xcode isn't building the intermediate files
14:48:57  <piscisaureus>hmm
14:49:10  <piscisaureus>what if you use —without-snapshot?
14:49:22  <piscisaureus>or does that also not work?
14:49:44  <tjfontaine>haven't tried that yet, I shall
14:50:12  <tjfontaine>but I have little hope for the node-natives.h
14:50:18  <piscisaureus>oh, right
14:50:25  <piscisaureus>Huh, that's lame
14:50:35  <piscisaureus>I thought gyp could make anything work
14:50:50  <tjfontaine>me too, it could be it's just not fully fleshed out for xcode
14:51:25  * blackorzarjoined
14:52:13  <piscisaureus>For me, xcode complains about the compiler being unsupported
14:52:30  <tjfontaine>you need to comment out the GCC version in common.gypi
14:52:49  <tjfontaine>everything compiles in clang, so I'm not sure why that was ever there
14:53:50  <piscisaureus>bnoordhuis: ^— you know that?
14:55:56  * charliesomequit (Quit: Textual IRC Client: www.textualapp.com)
15:03:22  <tjfontaine>that's one of those few settings that actually only applies to generating xcode projects and not osx-makefile
15:07:53  * piscisaureus_joined
15:30:04  <isaacs>piscisaureus: hey
15:30:36  <piscisaureus>isaacs: yo
15:30:37  <isaacs>piscisaureus: if libuv has that API, then we could map to the read()-->(null|data) pretty easily
15:30:43  <isaacs>piscisaureus: by just buffering one chunk
15:31:01  <piscisaureus>isaacs: sure… that would work
15:31:19  <isaacs>but still... why not just do that one-chunk buffering internally, since it's only necessary on windows?
15:32:15  <piscisaureus>isaacs: well… the API would get really clunky, since we have to keep this alloc_cb
15:32:23  * xaqjoined
15:32:34  <piscisaureus>isaacs: otherwise this "internal buffering" will add an extra copy for all data
15:32:41  <isaacs>right
15:33:06  <piscisaureus>isaacs: but really, why are we not just doing stream.read(function(err, data) {
15:33:07  <isaacs>so, like, for fs streams, we'll have to keep some kind of buffering window anyway
15:33:17  <piscisaureus>isaacs: that seems much more consistent anyway
15:33:21  <isaacs>piscisaureus: because that does not make it easy to consume just n bytes
15:33:40  <piscisaureus>isaacs: well, it does if you add a "length" argument :-)
15:33:44  <isaacs>piscisaureus: and it's unnecessarily complicated in unix
15:35:13  <isaacs>and it's harder to implement in userland streams properly
15:35:49  <isaacs>but i'll test that assumption. maybe it's not so bad. it's hard to just go on intuitions without seeing the API in action a little bit.
15:36:42  <isaacs>for fs streams, it'd be simpler logic, but probably not ideal performance, assuming that you have the memory to spare, since we do a single big read in the background, and then just slice you off the bits you ask for
15:43:50  <indutny>btw
15:43:57  <indutny>are we reusing deallocated buffers?
15:44:31  <indutny>looks like no
15:44:41  <indutny>but probably that's ok
15:44:51  * stephankjoined
15:48:23  <isaacs>piscisaureus: so, in the read(n, cb) model, there's really no need for a 'readable' event, then
15:49:13  <isaacs>you just read() and it gets back to you later.
15:50:27  * dshaw_quit (Quit: Leaving.)
15:50:38  <indutny>btw, I've just created joyent smartmachine
15:52:13  <indutny>isaacs: can I provision machine without apache and etc? :)
15:59:35  * dapjoined
16:00:57  <isaacs>indutny: yeah, just use the plain old smartos image, not smartos-plus or whatever.
16:01:05  <isaacs>indutny: you can also pkgin uninstall whatever
16:02:04  * chobi_e_changed nick to chobi_e
16:13:33  * chobi_echanged nick to chobi_e_
16:22:06  <isaacs>piscisaureus: what happens if you call stream.read(cb) and it ends before the read() comes back?
16:22:13  <isaacs>piscisaureus: interface-wise?
16:22:54  <isaacs>say, there's no data available, and we haven't received the end yet. you call read(cb), and then we get the end.
16:22:58  <isaacs>does the cb() get called with null?
16:25:42  <isaacs>or does it just go off into the ether?
16:26:40  <piscisaureus>isaacs: you'd get null for a buffer
16:26:50  <isaacs>hm... ok.
16:27:08  <isaacs>so stream.read(cb) has to assign an 'end' cb as well?
16:27:26  <piscisaureus>isaacs: ah, so you want to bolt it onto the current api?
16:27:39  <piscisaureus>isaacs: in libuv, "end" is also reported to the read callback
16:27:42  <isaacs>piscisaureus: yes, i need to be able to shim it in both directions.
16:27:58  <piscisaureus>isaacs: because that's how it works in c. If you get an EOF then read() returns 0
16:28:21  <isaacs>piscisaureus: part of the requirement of a solution here is that we make it interoperate with existing stream programs.
16:28:53  <piscisaureus>isaacs: we can bolt the current system pretty easily onto this read() thing
16:29:05  <piscisaureus>isaacs: and the read thing is not hard to do in libuv
16:29:15  <piscisaureus>plus it would work nicely with files being made streams
16:29:29  <isaacs>well, i'm not so sure it'd be any better, actually.
16:29:39  <isaacs>because we still probably want to buffer a lot for fs read streams.
16:29:54  <isaacs>if you're doing fstream.read(1) over and over again, we don't want to make each one of those have to hit the disk.
16:30:16  <isaacs>(or the fs subsystem, which is only the actual disk every 4096 bytes or whatever)
16:30:19  <piscisaureus>haha, yeah that won't happen anyway
16:30:24  <piscisaureus>but it'd be very slow
16:30:35  <piscisaureus>because of the thread pool synchronization overhead
16:30:38  <isaacs>right
16:30:50  <isaacs>we want to read in 16kb or something to memory, then feed you that.
16:30:54  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:31:06  <tjfontaine>he didn't like you conversation :)
16:31:20  <isaacs>so doing read() --> data|null is actually pretty easy, and read(cb) gets a little more complicated in this case.
16:31:27  <isaacs>since we have it in memory already
16:31:44  <isaacs>and we can fetch another block whenever the buffer is smaller than the specified size.
16:31:45  <tjfontaine>isaacs: you might want to wait until he rejoins
16:31:54  <isaacs>oh, i ignore /joins and /parts.
16:32:00  <isaacs>should probably turn that off in here.
16:32:06  <piscisaureus>I'm still here
16:32:12  <tjfontaine>ack, duplicates
16:32:54  <isaacs>the many faces and phases of the mysterious bert belder.
16:33:01  <isaacs>so many dino fish
16:33:12  * joeandaverdejoined
16:35:59  <piscisaureus>isaacs: so what I don't like about the readable event is that it's not so much of an improvement
16:36:28  <isaacs>howso?
16:36:44  <isaacs>(or, "improvement over what?")
16:36:47  <piscisaureus>isaacs: wel, you still get an event, you just respond slightly differently
16:37:31  <piscisaureus>isaacs: because it doesn't give you the data,but you have to call some function to get it ...
16:37:43  <isaacs>right
16:37:57  <isaacs>that's important.
16:38:13  <isaacs>there are 2 problems that it addresses, which are chewing on me daily:
16:38:33  <isaacs>1. it's extremely difficult to only consume *some* of the bytes in a stream, and leave the rest for later.
16:38:57  <isaacs>2. if you don't assign a listener right away, you lose data.
16:38:57  <piscisaureus>yes. so stream.read(cb, bytes) solves that, too :-)
16:39:02  <piscisaureus>ditto
16:39:06  * ericktjoined
16:39:11  <isaacs>right, but it's a bit weird.
16:39:24  <piscisaureus>why?
16:39:24  <isaacs>now we have two event-queue dips in pipe, instead of one
16:39:30  <creationix>isaacs, so you want read(bytes, callback) and not call the callback till you have that many bytes?
16:39:36  <isaacs>and, we have this end thing
16:39:42  <isaacs>creationix: no, the bytes are a maximum
16:39:47  <piscisaureus>creationix: no, that's what I want :-)
16:40:00  <creationix>for parsing protocols it's great
16:40:03  <isaacs>creationix: i want read(n) ===> buffer of no more than n bytes, or null
16:40:10  <creationix>read 4 bytes, get length header, read n bytes, parse message
16:40:16  <isaacs>creationix: right
16:40:16  <piscisaureus>creationix: what isaacs want is a nonblocking read() function and an event when data is available
16:40:32  <isaacs>i want epoll/read(2)/EWOULDBLOCK, but in js
16:40:48  <creationix>so just add a non-blocking flag
16:41:41  <creationix>hmm, but it's not the same thing at all
16:41:58  <creationix>for protocol parsing I want exactly n bytes
16:42:00  <creationix>it's higher level
16:42:04  <creationix>I want packets re-combined
16:42:33  <isaacs>creationix: that's easy to layer on top of this.
16:43:31  <creationix>true
16:43:39  <isaacs>on top of either one, really
16:43:54  <creationix>read up-to 4 bytes, call callback on first data
16:44:01  <creationix>then if it's just 3, read again asking for 1
16:44:39  <creationix>and much easier to implement to. It's low-level
16:44:53  <creationix>what about buffering data if read hasn't been called yet?
16:45:01  * dshaw_joined
16:45:10  <isaacs>creationix: that's just the thing, i want the data to not even be read into libuv until you call read()
16:45:22  <creationix>ok, now that's cool
16:45:31  <creationix>I approve
16:45:32  <isaacs>at least, for sockets
16:45:42  <isaacs>so the OS does the backpressure, instead of dealing with pause/resume bullshit
16:45:52  <creationix>what about syntethetic streams?
16:45:55  <isaacs>*some* userland streams will have to maintain some kind of buffer, yes.
16:46:04  <creationix>ok, so they just emulate the behavior
16:46:04  <isaacs>but we should provide adapters in both directions.
16:46:07  <creationix>that shouldn't be too hard
16:47:44  <isaacs>creationix: no, it's not too hard: https://github.com/isaacs/readable-stream
16:48:03  * creationixshould read the actual proposal
16:49:55  <creationix>isaacs, so youre read function is blocking?
16:50:04  <creationix>or will it usually have 0 bytes on the first call?
16:50:26  <isaacs>creationix: well, it's "blocking" in the sense that it returns immediately wiht a result.
16:50:39  <isaacs>creationix: but it should return null if there are not bytes that can be immediately returned.
16:51:01  <isaacs>it's like setting the NONBLOCK flag on a socket
16:51:05  <creationix>right, but if getting the data from the OS or whatever is slow, you'll have to return a 0-byte buffer and then emit ready when there is more
16:51:22  <isaacs>creationix: if you don't have data, then you return null
16:51:35  <creationix>sure, null is better than empty buffer
16:51:37  <creationix>but same problem
16:52:05  <creationix>I guess what this gives over a read callback is I know if there was data waiting or not
16:52:41  <creationix>I can think of many synthetic sources where the data is fetched lazily and will always have nothing on the first call
16:52:43  <isaacs>and if you don't know, you can just start reading until you hit hull
16:52:45  <isaacs>*null
16:53:07  <isaacs>creationix: sure, but it's a question of how lazily
16:53:38  <isaacs>eg, a fs read stream could start right away, but something else where reads are much more expensive (and might not be performed at all) could just start the first time you call stream.read()
16:53:41  <piscisaureus>meh, I am actually getting less convinced that this solves any real problems ...
16:53:57  <creationix>piscisaureus, compared to 0.x.8 streams?
16:53:57  <piscisaureus>except maybe the fact that people want to read data in small chunks
16:54:07  <piscisaureus>creationix: yeah
16:54:09  <creationix>buffering, pause, resume are all nightmares
16:54:22  <creationix>isaac's proposal or callback based are both way better
16:54:22  <isaacs>piscisaureus: the problem it solves is pause behavior, which is very difficult to get right
16:54:58  <isaacs>i mean, if you're doing hello world, or downloading a file, it's about the same.
16:55:02  <creationix>isaacs, so my initial thought was .read(numBytes, callback(data) {})
16:55:07  <isaacs>except that this way, pipe() is like 10 lines instead of 80
16:55:11  <creationix>and if there is no data, don't call the callback right away
16:55:15  <creationix>only call with no data on end
16:55:22  <creationix>or callback(err, data)
16:55:26  <creationix>so errors can be handled too
16:55:33  <isaacs>creationix: right, but what if there are only ever 5 bytes, and you do read(10, cb)?
16:55:34  <creationix>(non event emitter version)
16:55:34  <piscisaureus>yeah
16:55:43  <creationix>isaacs, right, the num is the max
16:55:46  <creationix>call on the first event
16:55:48  <isaacs>creationix: k
16:56:04  <piscisaureus>creationix: I was also thinking about that api… seems more consistent to me
16:56:07  * `3rdEdenquit (Quit: Leaving...)
16:56:11  <creationix>building a version that waits for n bytes or times out should be on top
16:56:15  <piscisaureus>we should say numbytes is the max, or maybe make that optional
16:56:26  <isaacs>piscisaureus: yes, it should be optional, and a maximum
16:56:33  <creationix>agreed
16:56:34  <isaacs>if i'ts 0 or undefined, then you just read as many as you have.
16:56:36  <creationix>max or optional
16:56:41  <creationix>or Infinity
16:56:46  <creationix>JS is so cool ;)
16:56:47  <isaacs>sure, whatever.
16:56:55  <creationix>what about read(callback)
16:57:06  <isaacs><=0 || > max || isNaN()
16:57:11  <piscisaureus>isaacs: well in that case the max is undefined, but it's obviously implementation dependent. Right now the actual max chunk size is 64k
16:57:14  <creationix>or are we trying to avoid optional arguments before the callback
16:57:19  <piscisaureus>(for tcp streams)
16:57:36  <isaacs>piscisaureus: sure, the point is, it should be up to the stream to say "This is what i have, and you said you want it, so here you go"
16:57:46  <isaacs>piscisaureus: it should not wait around for that much, or give you more than that.
16:57:51  <piscisaureus>no, sure
16:57:56  <isaacs>and the max should be optional and default to Infinity
16:57:56  <creationix>read([byteLimit], callback)
16:57:59  <isaacs>yep
16:58:09  <isaacs>the debate is not over byteLimit behavior that we all agree on :)
16:58:11  <creationix>that's the most elegant API for callback based
16:58:16  <isaacs>creationix: yes.
16:58:25  <creationix>and callback would be (err, data)?
16:58:27  <isaacs>the debate right now is over read(n, cb) or read(n)/on('readable')
16:58:44  <creationix>are there other events besides error, readable, and end
16:58:49  <isaacs>creationix: i guess. though that's a bit odd. wouldn't you want errors to just emit an error event on the stream?
16:58:51  <creationix>because that's all the callback can handle
16:59:14  <creationix>isaacs, what about be callback based at the core, but make it easy to wrap in a full emitter
16:59:23  <creationix>callbacks would be easier to implement I think
16:59:46  <piscisaureus>I think errors emitted on a stream is sort of the way we do it so we'd have to stick to it
16:59:48  <creationix>people like to extend streams and add custom events
16:59:53  <piscisaureus>but I like passing errors to callbacks much better
17:00:05  <joeandaverde>creationix: I'm trying my hand at a JS http parser. How's yours going?
17:00:15  <creationix>joeandaverde, haven't had much time
17:00:30  <joeandaverde>creationix: i see you've been busy in many other repos
17:00:36  <isaacs>piscisaureus: right, so, the symmetry to fs.read() is kind of lost, actually
17:00:37  <joeandaverde>creationix: is that your job or fun?
17:01:01  <creationix>joeandaverde, well, it's more piscisaureus, isaacs, and bnoordhuis job
17:01:06  <creationix>but I do work with piscisaureus and bnoordhuis
17:01:09  <isaacs>piscisaureus: if we do s.read(n, function(data) {})
17:01:45  <piscisaureus>isaacs: so s.read(n, function(err, data) { ?
17:01:47  <isaacs>s.read(n, (data) => {})
17:01:49  <isaacs>;)
17:01:53  <piscisaureus>haha
17:02:02  <isaacs>piscisaureus: but why pass the err to the read cb? why not just emit it?
17:02:25  <isaacs>read errors are basically teh only reason you'd ever emit an error on a readable stream
17:02:55  <piscisaureus>isaacs: right…. that's why they might just as well be passed to the read() function :-)
17:03:08  <piscisaureus>isaacs: it makes it much more obvious ...
17:03:13  <isaacs>then do we still emit 'error'?
17:03:15  <creationix>I think if you use events, isaacs proposal is best
17:03:22  <creationix>either use pure callback or pure events
17:03:23  <creationix>no mixing
17:03:40  <isaacs>yeah, this is kind of confusing.
17:03:49  <joeandaverde>check it out. this is a picture from a recent meetup of @nodekc. It's a group I started in Kansas City to do fun node talks. You may recognize some of the faces in the photo. http://www.bizjournals.com/kansascity/print-edition/2012/07/27/kansas-city-tech-group-works-to-create.html
17:03:58  <creationix>but what about using pure callback at the core but wrapping in events for the official stream implementation
17:04:07  <isaacs>i mean, there's no reason why libuv can't give us some "lowlevel socket" interface that does read(cb)
17:04:13  <isaacs>and then in JS we wrap it.
17:04:13  <creationix>so one way to make a readable stream would be to supply it a callback-based read function
17:04:25  <creationix>isaacs, exactly
17:04:32  <piscisaureus>isaacs: yeah, libuv can do that easily
17:04:33  <creationix>I think for the public Stream interface, events is best
17:04:34  <joeandaverde>i'm the fat guy with his back to the camera
17:04:51  <isaacs>but it feels a bit silly, since we'd be converting it in unix from the 'readable' pattern to the read(cb) pattern, then back to the 'readable' pattern.
17:04:57  <piscisaureus>isaacs: providing a "readable" event in libuv however is hairy on this particular platform, if we care about performance
17:05:23  <isaacs>grr. windows.
17:05:28  <isaacs>THIS IS WHY WE CANT HAVE NICE THINGS.
17:05:41  <piscisaureus>this is why libev couldn't be ported to windows :-)
17:05:42  <creationix>so the one thing that read(cb) can't do is poll for no data and return immedietly
17:05:49  <creationix>is that valuable
17:05:51  * brsonjoined
17:06:08  <piscisaureus>you can write your own wrapper for that :-p
17:06:26  <creationix>true
17:06:33  <piscisaureus>pretty easily even
17:06:38  <creationix>the read in the event emitter would just return whatever was last called back
17:06:42  <isaacs>the sucky thing, though, is that we're back to the "buffer it all in js, and manage pausing"
17:06:53  <creationix>isaacs, how so?
17:07:19  * TooTallNatejoined
17:07:28  <isaacs>creationix: well, if libuv does read(cb), and node does on('readable'), then in js, we have to keep some buffer, and re-fill it when it gets low.
17:07:45  * creationixgoes off to prototype, code is best for thinking clearly
17:07:47  <piscisaureus>isaacs: yes
17:08:04  <creationix>isaacs, no, if the callback gets called before read returns we can detect that
17:08:05  <creationix>and return it
17:08:13  <creationix>we'd only buffer one chunk at most
17:08:30  <creationix>is one too much?
17:08:38  <piscisaureus>and read() could return a slice of that buffer
17:08:43  <isaacs>creationix: well, memory is pretty cheap
17:08:45  <piscisaureus>you have to buffer anyway
17:08:57  <isaacs>and i already did this for my FSReadable class.
17:09:01  <piscisaureus>reading 4 bytes at a time is pretty stupid
17:09:03  <isaacs>the logic is not particualrly tricky
17:09:07  <piscisaureus>if you make a syscall for it every time\
17:09:16  <isaacs>yeah, that's a good point.
17:09:39  <isaacs>the real question is about the responsiveness of your backpressure.
17:09:42  <creationix>ok, so for performance, we read in full chunks
17:09:47  <creationix>but the user can read slices
17:09:59  <isaacs>ie, there's information there: i've only consumed n bytes, and that sort of pushes back on the upstream sender
17:10:10  <isaacs>but we can blur that a little of course. everyone actually does.
17:10:26  <isaacs>i mean, there's a thousand little hardware buffers between my keyboard and your screen right now.
17:10:32  <isaacs>probably more than that :)
17:10:40  <creationix>internet!
17:11:02  <isaacs>piscisaureus: how would you feel about read(cb) in libuv, and on('readable') in node?
17:11:20  <creationix>so libuv would handle the buffering?
17:11:27  <isaacs>creationix: no, lib/net.js would
17:11:31  <creationix>could a node user configure the chunk size, the low-water mark?
17:11:36  <isaacs>creationix: yeah
17:11:44  <isaacs>which is something that mjr has been asking for forever.
17:12:20  <creationix>ok, so the libuv interface would be just read(cb) not read([maxBytes], callback) ?
17:12:28  <isaacs>piscisaureus: ^?
17:12:36  <creationix>and a SlowBuffer in the callback
17:13:02  <isaacs>creationix: well, i mean, we'd do some kind of slab allocator deal like we do already.
17:13:02  * arlolrajoined
17:13:05  <creationix>where would be configure the chunk-size and low-water mark
17:13:06  <piscisaureus>isaacs: the libuv interface would get max bytes
17:13:51  <piscisaureus>isaacs: in fact libuv can already do that, but it's not obvious and an abuse of the api
17:13:59  * saghul_joined
17:14:11  <creationix>piscisaureus, for streams?
17:14:28  <creationix>you're right, it's not obvious
17:15:10  <piscisaureus>creationix: just alloc a small uv_buf_t in alloc_cb :-_)
17:15:15  <piscisaureus>but the api should be nicer
17:15:48  <creationix>piscisaureus, ok, sure, but what about auto-pausing
17:15:57  <creationix>not emit events till I call read
17:16:03  <isaacs>piscisaureus: so, it seems like we kind of have some agreement here.
17:16:36  * `3rdEdenjoined
17:16:52  <isaacs>libuv, and in tern node's (TCP|Pipe)_Wrap, implements read(n, cb)
17:17:13  <isaacs>then net.Socket et al implement on('readable') on top of that with configurable buffering.
17:17:31  <piscisaureus>hmm
17:17:32  <piscisaureus>haha
17:17:46  <piscisaureus>I am still not super convinced about on('readable')
17:18:05  <isaacs>well, it should be called on('data') but that ship sailed a lotng time aago
17:18:16  <creationix>readable is like "drain" on writable streams
17:18:21  <isaacs>yeah
17:18:31  <isaacs>there's kind of a nice symmetry to it
17:18:55  <isaacs>read() --> data or null; write() --> false or not-false
17:19:08  <isaacs>on('readable', readMore); on('drain', writeMore)
17:19:12  <creationix>what about the simple case where people want to just buffer their http body and json.parse it
17:19:23  <creationix>currently it's about 10 lines with a data listener and an end listener
17:19:35  * `3rdEdenquit (Client Quit)
17:20:47  <isaacs>creationix: body = ''; res.on('readable', function () { var chunk; while (null !== (chunk = res.read()) body += chunk }); res.on('end', function () { JSON.parse(body) })
17:21:33  <isaacs>(not unicode safe^)
17:21:38  <isaacs>but still, pretty easy
17:21:49  <isaacs>also, you probably don't even need the loop
17:21:55  <isaacs>since read() will tend to return the whole thing
17:22:24  <isaacs>but we may want to optimize it to prevent having to call Buffer.concat() in some cases, since that's potentially a copy
17:22:33  <creationix>hmm, so read could return data two times in a row?
17:22:41  <isaacs>creationix: yes.
17:22:43  <creationix>that should be defined one way or the other
17:22:52  <isaacs>or it should be explicitly undefined :)
17:23:19  <creationix>well, I mean we should tell people if it's a posibility
17:23:30  <isaacs>like, let's say you get a chunk from libuv, then you read not a full chunk, but enough to get below the low-water mark.
17:23:33  <creationix>I don't want code that "usually" works right
17:23:34  <isaacs>so we fetch another chunk from libuv
17:23:43  <isaacs>then you have two chunks sitting in the buffer.
17:23:57  <isaacs>say, one is 100 bytes, and the other is 1024
17:24:14  <isaacs>if you do read(<=100) it's easy, just slice off (or return) the first buffer.
17:24:30  <creationix>I think node should concat them for you
17:24:33  <isaacs>if you do read(200), though, or read(Infinity), then what?
17:24:35  <isaacs>concat them?
17:24:38  <creationix>or is that too expensive
17:24:44  <isaacs>well, it's more expensive than not doing it :)
17:25:01  <isaacs>maybe read() should just return the first 100 byte buffer, then read() again should return the 1024 byte buffer.
17:25:10  <creationix>I mean, if I want 200 bytes, I'm going to concat them anyway most likely
17:25:29  <creationix>unless I'm feeding it to a streaming parser and I happen to know the message is exactly 200 bytes
17:26:07  <creationix>yes, when in doubt do less, I agree
17:26:13  <creationix>but we don't want to make this too painful to use
17:26:53  <isaacs>maybe we should say that read() will give you whatever is most convenient, but read(1000) will try very hard to get the first 1000 bytes if it has them?
17:27:02  <isaacs>or is that too iffy?
17:27:32  <creationix>if there is any chance the user needs a while loop, then they need a while loop
17:27:43  <creationix>edge cases are annoying like that
17:28:22  <creationix>how about combine them if the user asks for a length
17:28:23  <piscisaureus>isaacs: so when coroutines happen, how are we going to bolt it onto that
17:28:30  <isaacs>lol
17:28:40  <creationix>hey, I have coroutines
17:28:43  <creationix>I use libuv
17:29:06  <piscisaureus>creationix: how do you do read() with coros?
17:29:37  <creationix>https://github.com/luvit/luvit/blob/master/examples/fs-coroutines.lua#L18-23
17:30:35  <creationix>this would be the same, except no offset
17:30:42  <piscisaureus>creationix: so what's the api you expose for reading with coros.
17:31:01  <creationix>it's the normal fs.read(fd, offset, maxBytes, callback)
17:31:13  <creationix>but I suspend the thread on call and resume when callback is called
17:31:22  <creationix>the wrap() function at the top does that
17:32:17  * c4miloquit (Remote host closed the connection)
17:33:05  <creationix>js won't have multiple return values though
17:33:15  <creationix>but it might get destructuring about the same time generators land in v8
17:33:58  * wavdedjoined
17:34:13  <creationix>anyway, I see coroutines as suger, the base is all callback based
17:34:21  <creationix>node should probably stay callback-based as well when generators land
17:34:43  * mmaleckijoined
17:34:45  * c4milojoined
17:34:48  <creationix>full coro based APIs are very different
17:34:52  <creationix>see copas for an example
17:37:49  <isaacs>we can look at how coros and generators can be used for this later.
17:37:59  <creationix>yep
17:38:10  <isaacs>i don't think any of ths on(readable) or read(cb) stuff actually makes that any harder or easier
17:38:31  <isaacs>it *might* make it more easy to do read(cb) as if it was a blocking read that returns null or a buffer
17:38:40  <isaacs>but that's a bigass tbd
17:40:08  * isaacstopic: Libert. Unit. Velocit. http://piscisaureus.no.de/libuv/latest
17:45:55  * AvianFluquit (Quit: Leaving)
17:46:48  * mikealquit (Quit: Leaving.)
17:47:42  * AvianFlujoined
17:48:04  * ericktquit (Quit: erickt)
17:51:23  <piscisaureus>https://gist.github.com/3189343 <— isaacs, it's very easy to shim this api anyway. Why would we need to change libuv at all?
17:53:45  <indutny>piscisaureus: ++
17:53:46  <kohai>piscisaureus has 4 beers
17:54:17  <indutny>I love libuv's APIs
17:54:25  <indutny>mostly
17:54:51  * AlbireoX`Awaychanged nick to AlbireoX
17:56:11  * dshaw_quit (Quit: Leaving.)
17:56:38  * lohkeyjoined
17:57:47  <indutny>wow
17:57:51  <indutny>node segfaulted on smartos
17:57:53  <indutny>0.9.1
17:58:01  <indutny>how can I read core dumps there?
17:58:09  <indutny>isaacs: ^
17:58:38  <mmalecki>indutny: ulimit -c unlimited, it should be dumped to the current directory
17:59:06  <indutny>oh, ulimit fixed things
17:59:16  <indutny>haha
17:59:17  <indutny>no
17:59:21  <indutny>that's just ulimit
17:59:24  <indutny>well, I see core file
17:59:31  <indutny>but how can I get stacktrace from it?
18:00:07  <mmalecki>indutny: you have to use mdb
18:00:09  <tjfontaine>mdb or something
18:00:16  <tjfontaine>bizzaro land :)
18:00:17  <indutny>ok
18:00:20  <indutny>I'll figure out
18:00:21  <indutny>thanks
18:00:43  <tjfontaine>dap linked before an mdb for gdb'rs cheat sheet not long ago
18:00:45  <mmalecki>indutny: actually, `mdb <core-file>` should work
18:01:23  * piscisaureus_joined
18:02:14  <dap>Indutny: we do also have gdb in pkgsrc, I believe. The blog post is: https://blogs.oracle.com/eschrock/entry/gdb_to_mdb
18:02:17  <indutny>uv__fs_event_read+0x2d()
18:02:17  <indutny>ev_invoke_pending+0x8b()
18:02:17  <indutny>uv__run+0x85()
18:02:17  <indutny>uv_run+0x18()
18:02:17  <indutny>_ZN4node5StartEiPPc+0x196()
18:02:17  <indutny>_start+0x6c()
18:02:31  <indutny>well, I would like to learn how to use mdb anyway :P
18:02:39  <dap>Cool.
18:03:04  <piscisaureus>bnoordhuis: hey, yt?
18:03:05  <indutny>so how can I get the reason of segfault?
18:03:25  <dap>::status
18:03:27  <bnoordhuis>piscisaureus: ih
18:03:39  <indutny>oh, great
18:03:41  <indutny>dap: thank you
18:04:19  <indutny>dap: and what should I load to get line numbers in stack trace?
18:04:38  <piscisaureus>bnoordhuis: does SO_RCVLOWAT affect when epoll() says when a socket is readable?
18:04:53  <dap>indutny: I don't know what issue you're looking at, but bcantrill root caused https://github.com/joyent/node/issues/3768 this morning, which has also been known to produce memory corruption and therefore SIGSEGV.
18:04:54  <CIA-108>node: Trent Mick v0.8 * rf70b138 / node.gyp : always link sunos builds with libumem - http://git.io/Eq0AKA
18:05:04  <dap>indutny: you want JS info, or C info?
18:05:26  <dap>indutny: MDB doesn't have any source information for C. For JS, you want "::load v8" and then "::jsstack"
18:05:32  <indutny>dap: C
18:05:35  <bnoordhuis>piscisaureus: in non-blocking mode? don't think so
18:05:37  <indutny>oh
18:05:39  <indutny>ok
18:05:52  <piscisaureus>bnoordhuis: hmm, sad :-)
18:05:56  <bnoordhuis>why?
18:06:17  <piscisaureus>bnoordhuis: well, I noticed something funny
18:06:45  <piscisaureus>bnoordhuis: I was using node as a fancy netcat, over wifi first at 18 MB/s and later over gbit ethernet at 80 MB/s
18:06:55  <piscisaureus>bnoordhuis: but node always uses about the same amount of memory
18:07:03  <piscisaureus>bnoordhuis: er, CPU (!!)
18:07:40  <bnoordhuis>is that good or bad?
18:07:45  <piscisaureus>bnoordhuis: which is probably because when the data rate is lower it reads more often in smaller chunks so effectively it becomes less efficient
18:07:57  <piscisaureus>(so in that regard, node is very scalable :-p)
18:08:13  * ericktjoined
18:08:15  <piscisaureus>bnoordhuis: but for many purposes it would be good to set a low water mark
18:08:25  <isaacs>indutny: yes, mdb is your friend
18:08:33  <indutny>https://github.com/joyent/node/issues/3783
18:08:34  <indutny>isaacs: ^
18:08:37  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:09:30  <bnoordhuis>piscisaureus: btw, did a quick kernel source grep. i get the impression that SO_RCVLOWAT doesn't actually do anything
18:10:26  <isaacs>well, that's bizarre.
18:10:41  * piscisaureus_joined
18:10:50  <tjfontaine>indutny: it happens on any npm install?
18:10:50  <bnoordhuis>same for SO_SNDLOWAT
18:10:51  * EhevuTovjoined
18:11:24  <isaacs>indutny: do you have the package.json file available that you were npm-installing?
18:13:22  <indutny>isaacs: yes, I'll share project with you
18:13:25  <indutny>tjfontaine: yes
18:13:28  <indutny>oh, no
18:13:31  <indutny>only one time
18:14:03  * micheilquit (Quit: micheil)
18:14:41  <piscisaureus>bnoordhuis: that would be very surprising to me
18:16:22  <bnoordhuis>piscisaureus: oh wait, i take that back - the missing link is in include/
18:16:40  <tjfontaine>https://github.com/search?q=SO_RCVLOWAT+repo%3Amirrors%2Flinux-2.6&repo=&langOverride=&start_value=1&type=Code&language=C
18:17:13  <bnoordhuis>piscisaureus: but i was right about it not doing anything in non-blocking mode
18:17:21  * mikealjoined
18:17:25  <bnoordhuis>or in poll-with-epoll mode for that matter
18:17:25  <tjfontaine>that is depressingly not as nice as codesearch.google.com
18:17:35  <piscisaureus>bnoordhuis: lame
18:17:36  <bnoordhuis>yeah, i miss codesearch :(
18:17:52  <piscisaureus>google code search, yeah why did they drop that
18:18:00  <piscisaureus>bnoordhuis: I think github has it tho
18:18:11  <indutny>isaacs: added you to the repo
18:18:30  <bnoordhuis>piscisaureus: github search can't hold a candle to codesearch
18:20:22  <isaacs>indutny: works for me
18:20:29  <indutny>odd
18:20:34  <indutny>are you using node 0.9.1-pre?
18:20:51  <indutny>btw, it worked when I run npm install second time
18:21:18  <isaacs>indutny: i'm on e2c556fde02ef104b3482813b6b0503fd9329ef4
18:21:28  <indutny>I'm on HEAD
18:21:31  <isaacs>yeah
18:21:37  <indutny>dunno exact commit
18:21:45  <indutny>actually, I'm too excited to test anything
18:21:49  <indutny>deploying vock server atm
18:21:55  <indutny>IT WORKS!!
18:21:55  <isaacs>* e2c556f Fedor Indutny (HEAD, origin/master, origin/HEAD, master) server: fix error (9 minutes ago)
18:21:57  <indutny>laggy, but works
18:22:05  <indutny>yes
18:22:10  <isaacs>indutny: btw, you can log in as root on 165.225.128.184
18:22:15  <isaacs>that's where i was testing it
18:22:22  * beachdogjoined
18:22:27  <indutny>ok
18:23:01  <joeandaverde>creationix: Do you also use chrome canary?
18:23:06  * dominictarrjoined
18:23:32  * beachdogquit (Client Quit)
18:24:09  <isaacs>ok, i'm going to make the Readable class have a way to plug in a generic _read(n, cb) thing, and support buffer size and low water mark setting.
18:24:20  <joeandaverde>creationix: On the MBP retina i'm getting a strange fluttering of the rendered page. It happens when i scroll and even move my mouse anywhere.
18:24:21  * beachdogjoined
18:24:56  <isaacs>piscisaureus: how hard would it be to implement read(n, cb) in libuv? in terms of days/weeks of work, etc.?
18:25:02  <isaacs>any rough guess?
18:27:30  * c4miloquit (Remote host closed the connection)
18:28:31  * c4milojoined
18:28:51  * arlolraquit (Quit: Linkinus - http://linkinus.com)
18:30:08  <piscisaureus>isaacs: *shrug*, not much I suppose
18:30:30  <piscisaureus>isaacs: it'd be uv_read_start, basically, but without queuing a new read after reading
18:30:54  <isaacs>does uv_read_start let you set the size to read?
18:30:56  <isaacs>i guess so
18:31:00  <isaacs>since you pass in a buffer?
18:31:04  <piscisaureus>you'd have to ask bnoordhuis for the unix details, but I think we would have to remove the socket fd from the poll set after a read returns. Which is also not that hard.
18:31:26  <isaacs>kewl, I'll post an issue.
18:31:33  <piscisaureus>isaacs: you don't pass in a buffer - but you can control it from the alloc cb
18:31:39  <piscisaureus>isaacs: that is kind of hacky though
18:31:40  <isaacs>oh, ok
18:31:43  <isaacs>yeah
18:32:00  <isaacs>i'll happily leave it up to you guys how to make the C api as nice as possible.
18:32:06  <creationix>sorry, on a call
18:32:58  <piscisaureus>uv_read(uv_handle_t*, uv_req_t*, size_t n, uv_alloc_cb on_alloc, uv_read_cb on_read)
18:33:03  <piscisaureus>^— indutny ?
18:33:11  <piscisaureus>^— other libuv users?
18:33:43  * dshaw_joined
18:37:12  <isaacs>https://github.com/joyent/libuv/issues/505
18:39:17  <isaacs>oh, check this out: http://nikhilm.github.com/uvbook/
18:41:50  <bnoordhuis>nice, isn't it?
18:42:32  <bnoordhuis>the bit about libuv being an abstraction over iocp and libev is kind of dated
18:43:00  <isaacs>heh, true
18:43:18  <isaacs>libuv talks directly to kqueue and friends now, right?
18:44:02  <bnoordhuis>well, almost - once i have multi-loop signal handling going, libev is gone
18:45:08  <piscisaureus>isaacs: was already there: https://github.com/joyent/libuv/issues/495
18:45:37  <isaacs>oh, lol
18:45:38  <isaacs>k
18:45:42  <isaacs>i'll merge :)
18:45:56  <isaacs>oh, you already merged.
18:45:58  <isaacs>hahah
18:46:24  <isaacs>parallelism is hard!
18:48:29  <CIA-108>node: Joe Andaverde master * r20e12e4 / (3 files in 3 dirs): events: make .listeners() return a copy - http://git.io/CKiynQ
18:49:26  <tjfontaine>trying to debug what seem to be travis only failures are hard
18:50:49  <bnoordhuis>yes. and annoying
18:57:24  <indutny>TooTallNate: hey
18:57:32  <TooTallNate>indutny: hey
18:57:32  <indutny>can node-gyp put .node file in build/Debug ?
18:57:41  <indutny>how can I figure that out?
18:57:44  <TooTallNate>indutny: ya, node-gyp rebuild --debug
18:57:49  <indutny>what file should I require
18:58:01  <TooTallNate>indutny: well, you can use node-bindings for that
18:58:14  <indutny>node bindings?
18:58:14  <TooTallNate>indutny: https://github.com/TooTallNate/node-bindings
18:58:21  <indutny>oh
18:58:33  <TooTallNate>it's not a perfect solution but it gets the job done
18:58:34  <indutny>ok
18:58:36  <indutny>that's very nice
18:58:38  <indutny>thanks
18:58:38  <TooTallNate>and it's only load-time so who cares
18:58:49  <TooTallNate>boot-up time that is
18:58:53  <TooTallNate>indutny: np :)
18:59:04  <TooTallNate>indutny: did you see my response to your github issue?
18:59:09  <indutny>yes
18:59:11  <indutny>sorry, still busy
18:59:18  <TooTallNate>cool, no prob, me too :)
19:02:22  <mordy___>hi, while trying to debug an issue of a socket hanging around the event loop after a failed connect, i realized that the uv-provided libev callback for connect does not call ev_io_stop.. must i manually call ev_read_stop to remove the socket from libev?
19:02:42  <mordy___>err.. uv_read_stop
19:03:00  <bnoordhuis>mordy___: more details please?
19:03:40  <piscisaureus>I wonder where all this interest in libuv comes from, suddenly
19:03:45  <piscisaureus>but a libuv book, that's pretty awesome :-)
19:04:05  <piscisaureus>the docs that we should have written but never did
19:04:20  <bnoordhuis>mordy___: at a guess, are you forgetting to close the handle?
19:04:25  <joeandaverde>well, the header file had a good level of detail.
19:04:27  <bnoordhuis>piscisaureus: the beauty of open source
19:04:46  <piscisaureus>yeah, it's making me happy :-)
19:04:48  <mordy___>d'oh
19:04:51  <mordy___>yes, i was
19:05:15  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:05:56  <mordy___>but that makes me wonder.. i don't see any fd leaks and i'm seeing 'close' showing up in strace as well..
19:06:37  <bnoordhuis>mordy___: same fd that did the connect()?
19:08:59  * piscisaureus_joined
19:09:32  <mordy___>yep, gonna see what's calling close here in a sec
19:10:34  <mordy___>as for my using libuv, i'm doing some plumbing so a C library can be wrapped in node and use its event loop
19:10:55  * piscisaureus__joined
19:11:03  <tjfontaine>he's multiplying
19:11:05  * piscisaureus__quit (Client Quit)
19:14:11  * piscisaureus_quit (Ping timeout: 255 seconds)
19:15:05  * piscisaureus_joined
19:15:10  * piscisaureus_quit (Remote host closed the connection)
19:15:44  * piscisaureus_joined
19:19:52  * mikealquit (Quit: Leaving.)
19:21:01  <ryah>piscisaureus_: re on('readable') i thought you do zero reads in iocp?
19:21:22  <piscisaureus>ryah: as a stopgap, measure, I do
19:21:43  <ryah>i guess once you're readable, you loop trying to do real reads
19:21:51  <piscisaureus>ryah: but it doesn't work for e.g. pipes (in fact it does, but it has problems, and I'll have to revisit that)
19:22:33  <piscisaureus>ryah: I sort of like to keep the api a bit flexible and not tie it to one particular (and hacky) implementation
19:23:36  <piscisaureus>ryah: I remember that we discussed read_start vs read. But I never realized that you wanted this thing where you get an event when data is available.
19:24:26  <ryah>piscisaureus: no, that was a separate idea
19:24:40  <ryah>after seeing dart's stream api
19:24:54  <ryah>so what about overlapped uv_read()
19:25:32  <piscisaureus>ryah: are you very much into
19:25:35  <piscisaureus>er
19:25:50  <piscisaureus>ryah: dart has onData and readInto
19:26:10  <piscisaureus>ryah: readInto looks like "overlapped read" and onData looks like the unix model
19:26:30  <piscisaureus>ryah: I am +1 with overlapped uv_read, although we have to figure out a nice api for it
19:26:57  <piscisaureus>ryah: it would be nice to keep this "late" allocation with alloc_cb around
19:27:23  <piscisaureus>atleast optionally
19:27:39  <piscisaureus>the Dart guys have looked closedly at node and learned from it :-)
19:28:23  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:28:29  <piscisaureus>^— I am not gone :-)
19:28:30  * paddybyersquit (Quit: paddybyers)
19:31:23  <ryah>uv_read() could still have a late alloc
19:31:35  <ryah>we dont want to tie up a buffer for that whole time
19:32:25  <piscisaureus>exactly
19:32:42  <piscisaureus>I have to run
19:32:54  <piscisaureus>ryah: comment @ https://github.com/joyent/libuv/issues/505 if you have ideas / comments
19:33:20  * piscisaureus_joined
19:34:13  * piscisaureusquit (Quit: Leaving.)
19:34:51  <indutny>isaacs: yt?
19:35:32  <indutny>how can I restart services on smartos?
19:35:35  <indutny>like restart redis
19:37:37  * `3rdEdenjoined
19:37:59  * piscisaureus_quit (Client Quit)
19:38:58  <mmalecki>indutny: use svcadm
19:39:10  <mmalecki>svcadm restart <thing>
19:39:34  <indutny>yeah
19:39:37  <indutny>thanks
19:39:41  <indutny>https://github.com/indutny/vock
19:39:44  <indutny>so we're there %
19:39:46  <mmalecki>woot
19:39:48  <indutny>^^
19:40:12  <indutny>npm install -g vock
19:40:16  <indutny>anyone wants to test?
19:43:18  <ryah>http://nikhilm.github.com/uvbook <-- did you see this?
19:43:26  <indutny>yes
19:43:28  * hzjoined
19:43:35  <indutny>ryah: want to vock with me?
19:43:37  <indutny>ryah: are you on osx?
19:43:53  <ryah>vock?
19:44:03  <indutny>ryah: npm install -g vock if you're on os
19:44:06  <indutny>s/os/osx
19:44:10  <indutny>VoIP on node.js
19:44:11  <ryah>sorry, im on linux
19:44:56  <indutny>ok, np
19:50:17  <saghul_>indutny what do you use for signaling?
19:50:31  <indutny>signaling?
19:51:15  <saghul_>yes, XMPP, SIP, custom?
19:51:34  <indutny>custom
19:51:36  <indutny>msgpack
19:51:42  <indutny>w/o encryption so far
19:51:47  <indutny>and w/o many features
19:51:59  <indutny>but yay, it's VoIP + javascript
19:52:13  <creationix>indutny, make a linux version!
19:52:16  * mikealjoined
19:52:21  <creationix>'cause you like pain
19:52:26  <indutny>creationix: hahaha
19:52:29  <saghul_>nice
19:52:32  <indutny>creationix: I don't have any linux machine atm
19:52:46  <indutny>only if bnoordhuis will help me :D
19:52:53  <saghul_>i'm a voip guy myself, that's why i asked ;-)
19:52:57  <creationix>any machine is a linux machine
19:52:59  <indutny>saghul_: oh, nice!
19:53:02  <indutny>creationix: hahaha
19:53:08  <indutny>creationix: I can't install pulse audio on osx
19:53:09  <indutny>I suppose
19:53:28  <tjfontaine>jack is cross platform
19:53:34  <indutny>hm...
19:53:51  <indutny>is jack the thing that is installed by default on ubuntu?
19:54:07  <tjfontaine>no that's pulseaudio more than likely
19:54:20  <tjfontaine>jack is the low latency audio kit
19:54:36  <indutny>tjfontaine: well, probably I'll use jack too
19:54:41  <indutny>since I'm using AudioUnits on OSX
19:54:44  <indutny>for low latency stuff
19:54:59  <tjfontaine>ya it just wraps AU stuff on OSX
19:55:02  <indutny>so, does anyone wants to vock with me?
19:55:14  <indutny>tjfontaine: heh, my regrets to it's authors
19:55:20  <indutny>AU is a bunch of junk
19:55:22  <tjfontaine>heh
19:55:30  <indutny>well, it's good
19:55:34  <indutny>but documentation sucks
19:55:50  <indutny>I figured out most of the things by trying different combinations of configurations
19:57:43  * beachdogquit (Remote host closed the connection)
19:59:05  * `3rdEdenquit (Quit: trololol)
20:03:52  * mikealquit (Quit: Leaving.)
20:13:24  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:15:19  * beachdogjoined
20:19:04  * loladirojoined
20:19:12  * loladiropart
20:19:27  * mmaleckiquit (Ping timeout: 255 seconds)
20:29:08  * saghul_quit (Quit: Computer has gone to sleep.)
20:29:43  * TooTallNatejoined
20:30:14  * mikealjoined
20:33:06  * joeandaverdequit (Quit: Leaving)
20:40:23  * c4miloquit (Remote host closed the connection)
20:55:10  * joe__joined
20:59:10  * EhevuTovquit (Quit: This computer has gone to sleep)
21:00:04  * stagasjoined
21:08:26  * loladirojoined
21:08:26  * loladiroquit (Client Quit)
21:11:56  * arlolrajoined
21:14:39  * bnoordhuisquit (Ping timeout: 252 seconds)
21:32:33  * hzquit (Disconnected by services)
21:32:36  * hzjoined
21:33:09  * mikealquit (Quit: Leaving.)
21:34:30  * piscisaureus_joined
21:37:38  * paddybyersjoined
21:43:03  * hzquit
21:43:27  * piscisaureujoined
21:43:52  * paddybyersquit (Quit: paddybyers)
21:47:15  * piscisaureuquit (Client Quit)
21:48:27  <piscisaureus_>I'm not here
21:48:33  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:51:56  * EhevuTovjoined
22:08:50  * rendarquit
22:14:16  * EhevuTov_joined
22:17:25  * EhevuTovquit (Ping timeout: 250 seconds)
22:30:10  * EhevuTov__joined
22:33:16  * EhevuTov_quit (Ping timeout: 246 seconds)
22:41:35  * EhevuTovjoined
22:45:22  * EhevuTov__quit (Ping timeout: 264 seconds)
22:46:18  * joe__changed nick to joeandaverde
23:07:31  * mikealjoined
23:14:29  * hij1nxjoined
23:22:39  * EhevuTov_joined
23:25:33  * EhevuTovquit (Ping timeout: 252 seconds)
23:26:11  * hij1nxquit (Ping timeout: 264 seconds)
23:27:37  * xaqquit (Remote host closed the connection)
23:28:03  * xaqjoined
23:28:08  * mikealquit (Quit: Leaving.)
23:28:56  * mikealjoined
23:30:45  * stagasquit (Quit: ChatZilla 0.9.88-rdmsoft [XULRunner 1.9.0.17/2009122204])
23:37:51  * dshaw_quit (Quit: Leaving.)
23:42:53  * paddybyersjoined
23:46:20  * xaq_joined
23:46:25  * xaq_quit (Remote host closed the connection)
23:47:48  * paddybyersquit (Quit: paddybyers)
23:49:16  * xaqquit (Ping timeout: 250 seconds)