00:01:40  <piscisaureus__>bnoordhuis: apparently my bot was banned from #node.js
00:01:53  <piscisaureus__>but it can't be for too much joins because there are none
00:02:14  <bnoordhuis>odd
00:04:35  <isaacs>piscisaureus__: how did your bot get banned from node.js?
00:05:02  <piscisaureus__>isaacs: http://piscisaureus.no.de/node.js/latest#19:54:22.805
00:07:50  <benvie>are you running it local or on a server?
00:07:53  <piscisaureus__>no
00:07:57  <piscisaureus__>didn't touch it in weeks
00:07:58  <benvie>maybe duplicate credentials or something?
00:08:04  <piscisaureus__>would be weird
00:08:15  <piscisaureus__>what is the irc support channel?
00:08:16  <benvie>or ip whatever
00:09:16  <benvie>I think it's just #freenode
00:09:25  <piscisaureus__>there seems to be a generic ban from 64.30.140.47
00:10:31  <benvie>that's pretty odd
00:10:43  <isaacs>piscisaureus__: it should have access now
00:10:46  <isaacs>can you try rejoining?
00:11:35  <benvie>oh hey dherman is in node
00:11:42  <benvie>based on the log =D
00:13:28  <piscisaureus__>isaacs: what was going on there: http://piscisaureus.no.de/node.js/latest#06:50:23.571
00:14:07  <isaacs>piscisaureus__: that was when ryah +O'ed everyone
00:14:16  <isaacs>piscisaureus__: and everyone started booting and bannign each other randomly
00:14:29  <isaacs>piscisaureus__: apparently someone banned slurp
00:14:39  <isaacs>i can't seem to figure out how to unban it. it says it's not +b now
00:23:06  <benvie>ah yes, that night
00:24:10  <benvie>remarkably civil given the circumstances
00:26:41  <piscisaureus__>ok so slurp is back
00:28:20  <isaacs>sweet
00:29:57  * brsonquit (Read error: Connection reset by peer)
00:30:16  * brsonjoined
00:31:50  <piscisaureus__>Unfortunate though. These idiots called _class_ and _root_ fucked it all up
00:32:09  <piscisaureus__>Now I have no memory of these nice dtrace commands
00:47:45  * dapquit (Quit: Leaving.)
01:08:29  * perezdquit (Quit: perezd)
01:10:18  <coderarity>_seriously_
01:10:21  <coderarity>that's awesome
01:10:32  <coderarity>__justgonnatrythis__
01:10:45  <coderarity>huh, weird
01:16:58  <piscisaureus__>Ah so the failure mode for slurp is -
01:16:58  <piscisaureus__> internet connectivity is lost. Node throws. Auto restart. No internet connectivity, never gets back up.
01:17:21  <piscisaureus__>Sad
01:28:16  <isaacs>piscisaureus__: that's sad indeed
01:28:24  <isaacs>piscisaureus__: i suspect the same thing happens with ircretary from time to time
01:31:06  * abraxasjoined
01:37:43  * brsonquit (Quit: leaving)
01:44:23  * ericktquit (Quit: erickt)
01:52:33  * perezdjoined
02:00:05  * perezd_joined
02:00:57  * perezdquit (Ping timeout: 252 seconds)
02:02:52  * perezdjoined
02:04:51  * perezd_quit (Ping timeout: 244 seconds)
02:08:06  * perezd_joined
02:11:05  * perezdquit (Ping timeout: 260 seconds)
02:11:05  * perezd_changed nick to perezd
02:26:22  * avalanche123quit (Ping timeout: 252 seconds)
02:28:08  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:29:14  * ericktjoined
02:33:15  <CIA-155>node: Ben Noordhuis master * r4359e81 / deps/v8/src/debug-agent.cc :
02:33:15  <CIA-155>node: v8: debug: fix error handling in SendConnectMessage()
02:33:15  <CIA-155>node: The old error handling code checked if the return value of Socket::Send() != 0,
02:33:15  <CIA-155>node: which is wrong because Socket::Send() can write less bytes than requested or
02:33:15  <CIA-155>node: return -1 on error. - http://git.io/YhOcdw
02:33:16  <CIA-155>node: Ben Noordhuis master * rebfb8a5 / deps/v8/src/platform-posix.cc :
02:33:17  <CIA-155>node: v8: posix: handle EINTR in socket functions
02:33:17  <CIA-155>node: The socket functions did not handle EINTR (syscall interrupted by signal) which
02:33:18  <CIA-155>node: tripped up the debug agent. - http://git.io/Y-uyjA
02:33:18  <CIA-155>node: Ben Noordhuis master * r48cdbff / deps/v8/src/platform-posix.cc :
02:33:19  <CIA-155>node: v8: posix: try to send() whole buffer
02:33:19  <CIA-155>node: Retry the send() syscall after a partial write. - http://git.io/V2Li8Q
02:41:27  <bnoordhuis>in case you're wondering -> http://code.google.com/p/v8/issues/detail?id=2098
02:41:40  <bnoordhuis>also this: https://github.com/joyent/node/issues/3167
02:44:01  * ericktquit (Quit: erickt)
02:48:22  <bnoordhuis>xcode is an utter piece of crap, beachballing on me all the time
02:48:42  <bnoordhuis>and people complain about eclipse!
02:49:25  * ericktjoined
02:49:33  * ggreerjoined
02:49:35  <ggreer>...
02:50:47  <bnoordhuis>ggreer: hi. enjoying the view?
02:50:47  <ggreer>so that was bug-inception. bug in gutsy -> bug in whiskey -> bug in node -> bug in v8
02:50:54  <bnoordhuis>yes
02:51:47  <ggreer>I definitely don't want to pass all signals through since, like you said, it would make it impossible to exit the debugger
02:52:50  <ggreer>but right now if you child_process.spawn('node', ['debug', 'blah.js']), when you hit ctrl+c, the debugger exits even if you're in the repl
02:53:34  <ggreer>so it's not handling that correctly, which is annoying
02:54:05  <bnoordhuis>ggreer: if you're in the repl -> if you're _not_ in the repl?
02:54:14  <ggreer>either way
02:54:45  <ggreer>Press Ctrl + C to leave debug repl
02:54:45  <ggreer>^C
02:54:45  <ggreer>program terminated
02:54:48  <ggreer>:/
02:55:16  <bnoordhuis>oh, that might be a platform difference
02:55:25  <ggreer>actually let me double-check this by building a pristine node and stuff
02:55:36  <ggreer>I can probably put together a small failure case
02:57:20  <bnoordhuis>test cases always help :)
02:59:01  <ggreer>macbook air is going to take forever to compile. /me grabs dinner
03:00:46  * c4milo_quit (Ping timeout: 265 seconds)
03:21:46  * perezd_joined
03:22:34  <piscisaureus__>bnoordhuis: hey
03:22:46  <piscisaureus__>bnoordhuis: v8 doesn't take patches like that. You'll have to submit them to rietveld
03:23:11  <bnoordhuis>piscisaureus__: i've submitted a number of patches like that already :)
03:23:20  <piscisaureus__>bnoordhuis: rly?
03:23:23  <bnoordhuis>yep
03:23:24  <piscisaureus__>bnoordhuis: for me that never works
03:23:28  * perezdquit (Ping timeout: 246 seconds)
03:23:29  * perezd_changed nick to perezd
03:23:39  <piscisaureus__>bnoordhuis: probalby because my patches are not trivial :-p
03:24:15  <bnoordhuis>if by that you mean they need real close scrutiny, then yes, i agree :)
03:24:33  <piscisaureus__>lol
03:26:42  <CIA-155>node: Kyle Robinson Young master * rd9bad09 / doc/api/util.markdown : doc: util: add args to format and methods error, puts, print - http://git.io/x6iWoQ
03:27:17  <piscisaureus__>https://github.com/piscisaureus/libuv/blob/poll/src/win/poll.c
03:27:18  <bnoordhuis>hey, that one again? https://github.com/joyent/node/issues/3168
03:27:21  <piscisaureus__>the good news: it works
03:27:26  <bnoordhuis>and the bad news?
03:27:35  <piscisaureus__>the bad news: in fallback mode, it creates up to 2 threads per socket
03:27:57  <bnoordhuis>wow
03:28:19  <piscisaureus__>bla bla bla should
03:28:23  <piscisaureus__>did someone push v8 out
03:28:34  <piscisaureus__>I think I landed a patch for that a week ago
03:29:47  <bnoordhuis>it wfm with master and 0.6
03:30:58  <piscisaureus__>this dude os probably using an old version of node
03:31:23  * isaacsquit (Remote host closed the connection)
03:31:29  <piscisaureus__>ff ter zijde
03:31:33  <piscisaureus__>zijn kop staat me niet aan
03:31:34  <piscisaureus__>https://secure.gravatar.com/avatar/793650b627e1896cebe3ad7c3348046e?s=140&d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png
03:32:13  * isaacsjoined
03:32:14  <bnoordhuis>ah... commit 5d69bbf, landed on april 16
03:35:37  <bnoordhuis>seen google's home page today yet?
03:38:05  <piscisaureus__>.yep
03:38:09  <piscisaureus__>bnoordhuis: ok I am off
03:38:13  <ggreer>https://gist.github.com/2476191
03:38:29  <ggreer>I'll try the same thing on a linux box. that was 0.6.15 on os x 10.7
03:42:26  <ggreer>same behavior on ubuntu 10.04
03:46:57  <bnoordhuis>ggreer: can you post that in the issue? i guess i'll grab a few hours of sleep as well
03:47:03  <ggreer>sure
03:47:05  <ggreer>thanks for your help
03:47:18  <ggreer>this has been an interesting trek into mordor
03:48:59  <piscisaureus__>yeah
03:49:00  <piscisaureus__>off to bed
03:49:06  <piscisaureus__>bnoordhuis: come to the office some day
03:49:20  <bnoordhuis>piscisaureus__: i'll be there tomorrow
03:49:29  <piscisaureus__>bnoordhuis: really?
03:49:33  <piscisaureus__>bnoordhuis: what time?
03:49:43  <bnoordhuis>tomorrow as in wednesday
03:49:49  <piscisaureus__>ghe lol
03:49:51  <piscisaureus__>ok
03:50:07  <bnoordhuis>i'll be there around noon so get up early :)
03:50:11  <bnoordhuis>okay, sleep tight
03:50:56  <piscisaureus__>fuck
03:51:20  <piscisaureus__>bnoordhuis: I wil dismantle my desk so there's nothing for you to stream >:-)
03:51:24  <piscisaureus__>*steal
03:52:03  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:52:17  * bnoordhuisquit (Read error: Operation timed out)
04:45:12  * ericktquit (Quit: erickt)
04:46:15  * isaacsquit (Ping timeout: 260 seconds)
04:59:48  * isaacsjoined
05:38:30  * paddybyersjoined
05:42:57  * isaacsquit (Remote host closed the connection)
06:02:01  * orlandovftwjoined
06:02:40  * orlandovftwquit (Client Quit)
06:18:21  * stephankquit (Quit: *Poof!*)
06:37:23  * rendarjoined
06:39:43  * benviequit (Read error: Operation timed out)
06:39:59  * benviejoined
06:48:28  * benviequit (Remote host closed the connection)
06:48:44  * benviejoined
06:54:55  * benviequit (Remote host closed the connection)
06:55:12  * benviejoined
07:06:10  * mralephjoined
07:06:27  * mralephquit (Remote host closed the connection)
07:40:35  * benviequit
07:41:10  * benviejoined
11:08:54  * paddybyersquit (Ping timeout: 244 seconds)
11:09:13  * paddybyersjoined
11:16:07  * paddybyersquit (Ping timeout: 272 seconds)
12:56:33  * bnoordhuisjoined
13:13:21  <demarchi>bnoordhuis: hey, any news on the mainloop refactor?
13:18:19  <bnoordhuis>demarchi: nearing completion, working on the windows bits
13:28:28  * c4milojoined
13:29:27  <demarchi>bnoordhuis: nice... so the linux part is ready/
13:29:28  <demarchi>?
13:30:45  <bnoordhuis>demarchi: more or less. could use some cleanup but it works and passes all tests (well, except one)
13:36:10  <saghul>bnoordhuis: I had a quick look, does uv_run_once not block if there are no active handles? (after the refractor) I see NOWAIT would be passed to ev_run apparently
13:36:47  <bnoordhuis>saghul: yes. as in, won't block
13:37:17  <saghul>bnoordhuis, zoo neat, can't thank you enough for that :-)
13:37:20  <saghul>*soo
13:37:30  <bnoordhuis>oh, i don't know
13:37:35  <bnoordhuis>buy me 20 beers and we'll call it even
13:38:12  * bnoordhuisis gone shopping
13:38:15  <saghul>heh, next time you come to Amsterdam I'm buying!
13:38:16  <bnoordhuis>because programming is hard
13:38:24  <bnoordhuis>saghul: i'm keeping you to that :)
14:06:40  <demarchi>bnoordhuis: but... did you add the api to get epoll's fd to be managed by another mainloop?
14:16:34  * wankdankerjoined
14:26:34  * ericktjoined
14:40:36  * piscisaureus_joined
14:43:42  * perezd_joined
14:46:13  * perezdquit (Ping timeout: 265 seconds)
14:46:13  * perezd_changed nick to perezd
14:50:14  <piscisaureus_>bnoordhuis: hey, yt?
14:52:46  <bnoordhuis>piscisaureus_: yes
14:52:55  <piscisaureus_>bnoordhuis: can you skype?>
15:02:16  * perezdquit (Read error: Connection reset by peer)
15:02:22  * perezdjoined
15:02:23  * piscisaureus__joined
15:02:52  * piscisaureus_quit (Ping timeout: 256 seconds)
15:08:54  * perezdquit (Ping timeout: 260 seconds)
15:09:38  * isaacsjoined
15:29:40  <bnoordhuis>so the next ubuntu release is called quantal quetzal
15:30:13  <bnoordhuis>i wonder how many misspellings will pop up
15:31:49  <tjfontaine>far too many
15:35:45  <txdv>horny horse
15:37:42  <isaacs>lol
15:38:06  * perezd_joined
15:52:28  * perezd_quit (Quit: perezd_)
15:58:37  <bnoordhuis>demarchi: sorry, missed your comment. no, not yet
15:59:32  * AndreasMadsenjoined
16:00:41  * brsonjoined
16:11:08  * perezdjoined
16:11:26  * dapjoined
16:16:24  * ericktquit (Quit: erickt)
16:19:41  * orlandovftwjoined
16:20:01  * stephankjoined
16:59:29  * isaacsquit (Remote host closed the connection)
17:07:45  * ericktjoined
17:08:28  * avalanche123joined
17:28:25  * `3rdEdenjoined
17:39:21  * avalanche123quit (Quit: Textual IRC Client: http://www.textualapp.com/)
17:40:33  * orlandovftwquit (Ping timeout: 272 seconds)
17:42:36  * avalanche123joined
17:42:49  * `3rdEdenquit (Quit: Leaving...)
17:44:52  * isaacsjoined
17:49:10  * TooTallNatejoined
17:55:49  <igorzi>piscisaureus_: hey
17:56:13  <piscisaureus__>igorzi: hey
17:56:23  <igorzi>piscisaureus_: there's an issue with one of the machines in the test cluster.. our lab guy is taking a look
17:56:32  <piscisaureus__>igorzi: ok... thanks
17:56:46  <piscisaureus__>igorzi: let me know
17:56:57  <igorzi>piscisaureus__: yep.. hopefully it'll be ready later today
17:57:06  <piscisaureus__>igorzi: kewl
17:58:52  * `3rdEdenjoined
18:02:34  * `3rdEdenquit (Client Quit)
18:16:41  * `3rdEdenjoined
18:22:12  <mjr_>bnoordhuis: time for my daily pestering about this TLS bug. Let me know if I can help.
18:27:17  <piscisaureus__>igorzi: bnoordhuis: remember that we did _setMaxSimultaneousAccepts in node windows when running in a cluster setup
18:27:25  <piscisaureus__>it seems that node for unix needs exactly the same hack
18:27:33  <piscisaureus__>we just found out the hard way
18:30:01  <isaacs>piscisaureus__: oh, interesting. is that the source of your cluster-not-balancing thing?
18:30:27  <piscisaureus__>isaacs: yes
18:30:51  <isaacs>piscisaureus__: awesome. sounds like we're due for a 0.6.16 :)
18:31:03  <piscisaureus__>isaacs: well actually we patched it in node 0.4 :-)
18:31:14  <isaacs>oh, you guys are on 0.4??
18:31:22  <piscisaureus__>isaacs: yes, :-(
18:31:24  <isaacs>was there even clusterability back then?
18:31:27  <isaacs>i guess, huh
18:31:29  <isaacs>since you had sendFD
18:31:30  <piscisaureus__>isaacs: will switch in 1 week
18:31:36  <isaacs>awesome.
18:31:44  <piscisaureus__>isaacs: no, the problem is require.paths removal
18:32:04  <piscisaureus__>isaacs: c9 has it's own way of doing node_modules that predates node's way
18:32:23  <piscisaureus__>isaacs: changing that is super invasive
18:33:40  <TooTallNate>anyone wanna review? https://github.com/TooTallNate/node/compare/stdin2
18:34:11  <TooTallNate>^ that fixes `echo "'hello world'" | node -p` not working as expected
18:35:43  * isaacsquit (Ping timeout: 240 seconds)
18:36:46  <ggreer>bnoordhuis: so if I wanted to make sure the node debugger worked properly, I should grab v8, apply your patch to it, and build node with that?
18:36:47  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
18:53:39  * seebeesjoined
18:54:03  <bnoordhuis>ggreer: i landed the v8 patches in node master yesterday
18:54:13  <ggreer>oh, cool
18:57:33  * perezdquit (Quit: perezd)
18:58:39  * orlandovftwjoined
19:03:23  <mjr_>Kind of seems like node's UDP incoming Buffer allocator isn't working right: http://ranney.com/ms2.svg
19:03:43  <mjr_>That's a process at 100% CPU processing about 3,000 UDP packets/sec.
19:03:44  <piscisaureus__>mjr_: 0.6.latest?
19:03:48  <mjr_>Yes
19:03:56  <mjr_>With the no idle patch also
19:04:17  <piscisaureus__>mjr_: there was an issue with the slab allocator, but that was fixed. Maybe it's only in 0.8
19:04:37  <mjr_>Oh yeah, no idle is a huge win that so far I recommend completely, even as the default.
19:04:50  <piscisaureus__>mjr_: no idle at all?
19:05:11  <piscisaureus__>mjr_: yeah, new slab allocator isn't in 0.6
19:05:15  <mjr_>piscisaureus__: yeah, it seems like the slab allocator isn't kicking in, there are perhaps 2 different invocations of Buffer::New for each incoming packet.
19:05:38  <piscisaureus__>mjr_: yeah, in 0.6 the slab allocator doesn't work for UDP
19:05:51  <mjr_>Yes, completely removed the idle GC timer with ryah_'s patch. So far it wins.
19:07:10  <piscisaureus__>3ec84a1 Slab allocator: don't attempt to shrink a non-buffer
19:07:23  <mjr_>But I am sad that the UDP version of my metrics program is much slower than the TCP version of the same.
19:07:40  <mjr_>Perhaps 10X slower.
19:08:49  <piscisaureus__>mjr: you should try to apply:
19:08:50  <piscisaureus__>3ec84a1 Slab allocator: don't attempt to shrink a non-buffer
19:08:50  <piscisaureus__>1ab95a5 udp_wrap: use new slab allocator
19:08:50  <piscisaureus__>08032ef core: add reusable slab allocator
19:08:50  <piscisaureus__>f86359c udp: root JS objects in HandleScope with Local<>
19:08:50  <piscisaureus__>32b2964 udp: remove slab allocator
19:08:59  <piscisaureus__>mjr_: in bottom to top order
19:09:14  <piscisaureus__>lemme try
19:09:22  <mjr_>oh, interesting. So this is a known and handled issue in 0.8
19:09:29  <piscisaureus__>mjr_: yes
19:09:41  <piscisaureus__>mjr_: basically the udp slab allocator is completely nonfunctioning in 0.6
19:09:51  <piscisaureus__>but the patch is pretty invasive so we didn't backport
19:09:54  <mjr_>That lines up with this flame graph.
19:10:26  <bnoordhuis>piscisaureus__, mjr_: the new slab allocator wasn't back-ported to 0.6
19:10:38  <bnoordhuis>oh, piscisaureus__ already said that
19:11:35  <mjr_>1ab95a5 doesn't apply cleanly
19:12:45  <bnoordhuis>mjr_: one sec
19:14:08  <bnoordhuis>oh right, that also fixed the problem of buffers not properly being rooted in a gc scope
19:14:18  <bnoordhuis>yeah, we should back-port that anyway
19:14:51  <mjr_>is that a potential memory leak source?
19:16:26  <piscisaureus__>bnoordhuis: I don't think it is needed
19:16:43  <piscisaureus__>bnoordhuis: try to resolve the conflicts :-)
19:16:44  <bnoordhuis>mjr_: it was manifesting itself as zero-length reads
19:16:53  <mjr_>oh shit, we have that a lot
19:27:03  <piscisaureus__>bnoordhuis: mjr_: it seems that if we want to backport the slab allocator we'd have to go all the way
19:27:12  <piscisaureus__>e.g. also use it for other streams
19:27:34  <piscisaureus__>because 3ec84a1 makes stream_wrap aware of the slab allocator
19:28:23  <piscisaureus__>bnoordhuis: is there nothing better than quilt?
19:28:37  <mjr_>Should i just convert this thing back to TCP, or does this aggressive back port seem like it'll happen?
19:28:39  <piscisaureus__>bnoordhuis: can git not handle this natively. I though this was sort of what git merge does?
19:29:00  <piscisaureus__>mjr_: maybe just run 0.7 :-)
19:29:11  <mjr_>oh man, I want to.
19:29:18  <mjr_>Because emoji will probably work.
19:29:28  <piscisaureus__>mjr_: I think current 0.7 is pretty stable
19:29:29  <mjr_>But dtrace magic almost certainly will not.
19:29:54  <piscisaureus__>mjr_: it may degrade for a while when the refcount refactor lands tho
19:30:42  <piscisaureus__>mjr_: I don't thing we'll backport the udp slab allocator to 0.6 though.
19:30:51  <piscisaureus__>mjr_: not on the official branch that is
19:30:59  <piscisaureus__>It's too risky
19:33:17  <bnoordhuis>well, i'm halfway there
19:33:31  <piscisaureus__>ok, I'll way
19:33:36  <bnoordhuis>some conflicts but manageable
19:38:24  <mjr_>I'm happy to test with real load if you think it might work.
19:38:41  <bnoordhuis>running tests
19:40:37  <mjr_>Sometimes "make test" on node 0.6 locks up my SmartOS machines for about 5 minutes. Kind of a bummer in production.
19:41:21  <mjr_>To hear me complain, you'd think that node didn't work at all.
19:41:22  <piscisaureus__>bnoordhuis: now also port this to libuv: https://github.com/piscisaureus/node/compare/v0.4...v0.4-cluster-starvation :-)
19:41:26  <mjr_>When the opposite is obviously true.
19:41:26  <piscisaureus__>bnoordhuis: otherwise, tomorrow
19:43:20  <bnoordhuis>it's mostly mode=debug that bums me out when running tests, mode=release is pretty fast
19:44:19  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:45:45  <bnoordhuis>mjr_: https://github.com/bnoordhuis/node/compare/v0.6...slab-allocator
19:48:59  <mjr_>Cool, I'll check it out.
19:49:31  * AndreasMadsenquit (Remote host closed the connection)
19:52:53  <bnoordhuis>mjr_: if you can test it under load and report back, that'd be great
19:53:00  <mjr_>on it
19:53:51  <bnoordhuis>$ python tools/test.py --mode=debug,release simple
19:53:51  <bnoordhuis>[10:46|% 100|+ 678|- 0]: Done
19:53:54  <bnoordhuis>so far so good
19:54:21  <mjr_>testing out on my local machine, and then I'll move to SmartOS, and then try on a real live machine.
19:56:45  * mralephjoined
20:00:12  <bnoordhuis>aw, i have one less github follower
20:08:09  <tjfontaine>bnoordhuis: there, I've compensated for the universe
20:08:48  <bnoordhuis>yay, thanks :)
20:13:26  <tjfontaine>glad to be of service when I can
20:18:55  * creationixquit (Quit: ZNC - http://znc.in)
20:18:56  * indutny_zncquit (Quit: ZNC - http://znc.in)
20:22:49  * piscisaureus_joined
20:28:24  * perezdjoined
20:33:05  <TooTallNate>bnoordhuis: could you review when you get a chance? https://github.com/TooTallNate/node/compare/stdin2
20:33:35  <bnoordhuis>TooTallNate: can you tell me what it does in five words or less?
20:34:04  <TooTallNate>makes `echo 'require("locally-installed-package")' | node` work as expected
20:34:28  <TooTallNate>bnoordhuis: also the commit messages have more details
20:36:08  <bnoordhuis>TooTallNate: looks okay to me
20:36:27  <TooTallNate>just ok?
20:36:55  <bnoordhuis>were you hoping for 'great' or 'terrific'? :)
20:37:04  <piscisaureus_>"lotm"
20:37:08  <TooTallNate>haha :p
20:37:13  <TooTallNate>thanks
20:37:53  <CIA-155>node: Nathan Rajlich master * r0b5235e / src/node.js : (log message trimmed)
20:37:53  <CIA-155>node: process: make --eval and reading scripts from stdin act the same
20:37:53  <CIA-155>node: Reusing the same logic for both places for the behavior is consistent.
20:37:53  <CIA-155>node: For example:
20:37:53  <CIA-155>node: $ ./node -p -e "'Hello World'"
20:37:54  <CIA-155>node: Hello World
20:37:54  <CIA-155>node: $ echo "'Hello World'" | ./node -p
20:37:55  <CIA-155>node: Nathan Rajlich master * r6292df6 / src/node.cc : process: comment for consistency - http://git.io/rd6TEg
20:37:56  <CIA-155>node: Nathan Rajlich master * ref3a874 / src/node.cc :
20:37:56  <CIA-155>node: process: set _print_eval even when --eval is not passed
20:37:57  <CIA-155>node: This is for scripts being fed from stdin:
20:37:57  <CIA-155>node: $ echo "{ foo: 'bar' }" | node -p - http://git.io/CKzyBA
20:39:04  <bnoordhuis>piscisaureus_: src/win/pipe.c:164:7: warning: ‘_errno’ redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
20:39:09  <bnoordhuis>should i worry about that?
20:39:13  <piscisaureus_>uhh
20:39:25  <piscisaureus_>we're using that?
20:40:19  <piscisaureus_>bnoordhuis: I think we shouldn't be using that... but we're using an local var named "errno" sometimes
20:40:30  <piscisaureus_>bnoordhuis: did you accidentally remove an `int errno` somewhere?
20:40:35  <bnoordhuis>no, this is with master
20:40:37  <piscisaureus_>(I agree the var should be renamed)
20:40:42  <bnoordhuis>i'll rename it
20:40:55  <piscisaureus_>bnoordhuis: just replace errno by errorno in the entire file
20:40:57  <piscisaureus_>and see what it does
20:41:13  <bnoordhuis>yep
20:41:38  <bnoordhuis>haha, wtf
20:41:38  <bnoordhuis>make: Warning: File `test/test-list.h' has modification time 9.2e+04 s in the future
20:41:56  <piscisaureus_>huh
20:45:55  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/commit/7ae7bb6 <- that look okay to you?
20:54:51  <piscisaureus_>bnoordhuis: lgtm if it works
20:55:24  <bnoordhuis>it compiles, that's good enough right?
20:57:38  * perezdquit (Quit: perezd)
20:58:24  * perezdjoined
21:00:56  * perezdquit (Client Quit)
21:01:27  <CIA-155>libuv: Ben Noordhuis master * r8ff4b1b / src/win/pipe.c : windows: rename local var errno to errorno - http://git.io/8AYbBw
21:01:58  <bnoordhuis>wait, i'll update the commit log
21:02:11  <tjfontaine>bnoordhuis: are you compiling on nfs?
21:02:35  <bnoordhuis>tjfontaine: on sshfs
21:02:47  <tjfontaine>ah, time drifts can make things fun :)
21:03:05  <bnoordhuis>yeah :) a couple of seconds i expect but not that
21:03:08  <tjfontaine>I think that happens especially with fuse and metadata
21:03:23  * travis-cijoined
21:03:23  <travis-ci>[travis-ci] joyent/libuv#218 (master - 8ff4b1b : Ben Noordhuis): The build is still failing.
21:03:23  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/1f001fe...8ff4b1b
21:03:23  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1167244
21:03:23  * travis-cipart
21:03:47  <CIA-155>libuv: Ben Noordhuis master * r84d2f82 / src/win/pipe.c :
21:03:47  <CIA-155>libuv: windows: rename local var errno to errorno
21:03:47  <CIA-155>libuv: Fixes compiler warning: ‘_errno’ redeclared without dllimport attribute:
21:03:47  <CIA-155>libuv: previous dllimport ignored. - http://git.io/U1H1qw
21:05:54  * travis-cijoined
21:05:54  <travis-ci>[travis-ci] joyent/libuv#219 (master - 84d2f82 : Ben Noordhuis): The build is still failing.
21:05:54  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/8ff4b1b...84d2f82
21:05:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1167266
21:05:54  * travis-cipart
21:07:43  * perezdjoined
21:23:31  * orlandovftwquit (Quit: leaving)
21:23:50  * orlandovftwjoined
21:43:02  * isaacsjoined
21:55:24  * brsonquit (Quit: leaving)
21:55:36  * brsonjoined
21:59:56  * stephankquit (Quit: *Poof!*)
22:06:41  * creationixjoined
22:13:07  * mralephquit (Quit: Leaving.)
22:16:14  <creationix>is it just me or has the #node.js room become useless for asking hard questions?
22:16:54  <creationix>(by hard question I mean something *I* still don't know after using node for years)
22:20:28  * rendarquit
22:22:23  <TooTallNate>creationix: i'm interesting in the pipe thing too; i think i've experienced that before but didn't look too deep into it
22:22:53  <TooTallNate>creationix: and ^ probably because there's only a handful of people who actually know the answer to those hard questions :
22:22:53  <TooTallNate>:p
22:23:16  <creationix>I'm so close to having proper stream flow-control in my vfs library
22:23:22  <creationix>but my pipes are breaking everything
22:23:33  <creationix>it just returns true and buffers 40mb of json
22:23:41  <TooTallNate>sounds like a bug :D
22:24:06  <TooTallNate>creationix: but wouldn't it be because stdout is sync now?
22:24:14  <TooTallNate>so... it's always been flushed
22:24:24  <creationix>if it's sync, then wouldn't it block?
22:24:35  <TooTallNate>yes. is it not?
22:25:22  <creationix>my test is I'm streaming 100,000 rows of json tunneled over stdout and then to a http response that's sent to a rate limited curl
22:25:33  <creationix>if I go directly to http and skip the tunnel it works great
22:26:04  <creationix>but when I add the stdout tunnel it sends all 100,000 lines and curl is still chewing on line 1000 or so
22:26:52  <creationix>I've tried the tunnel both over a new raw Pipe and child process (using the bi-directional stdin truck ChildProcess.fowk does)
22:27:04  <creationix>and with a ssh child process tunneling to a remote node process's normal stdout
22:27:51  <creationix>In the local process case, I'm not using the normal stdout, I'm using a repurposes stdin pipe
22:27:55  <creationix>*repurposed
22:28:13  <creationix>in the ssh case there are a lot of layers and it might be buffering elsewhere
22:30:24  <creationix>so the case that does work, I call .pipe(res) on this stream object directly (no tunnel) https://github.com/c9/vfs/blob/master/local/localfs.js#L286-297
22:30:45  <creationix>.pipe will call .pause() and .resume() for me when res.write() return false and res emits drain
22:33:55  <creationix>for tunneled streams, I'm looking at the return value of write on the stdout or stdin stream here: https://github.com/c9/vfs/blob/master/socket/worker.js#L31-39
22:33:58  <creationix>but it's always true!
22:34:24  <creationix>(the return value of remote.send is the return value of .write two layers deeper, I can verify that)
22:34:47  * perezdquit (Quit: perezd)
22:35:30  * perezdjoined
22:55:22  <CIA-155>libuv: Bert Belder poll * r9d0cfdf / test/benchmark-sizes.c : Benchmarks: add size of uv_poll_t to benchmark-sizes (+8 more commits...) - http://git.io/SnXUdw
22:57:30  <CIA-155>libuv: Bert Belder master * r5342bac / include/uv.h : uv.h: make the ssize_t fallback more portable - http://git.io/aq7-og
22:57:30  <CIA-155>libuv: Bert Belder master * r1b6329d / (include/uv-private/uv-win.h src/win/internal.h): Style fixes - http://git.io/gyBnxA
22:57:30  <CIA-155>libuv: Bert Belder master * r42a8669 / src/win/core.c : Windows: set loop counters to zero in uv_loop_init - http://git.io/ta32Jg
22:57:41  * travis-cijoined
22:57:41  <travis-ci>[travis-ci] joyent/libuv#220 (poll - 9d0cfdf : Bert Belder): The build is still failing.
22:57:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c7d43bd...9d0cfdf
22:57:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1168113
22:57:41  * travis-cipart
22:59:00  <piscisaureus_>igorzi: Can you review https://github.com/joyent/libuv/compare/master...poll , as far as possible. I will add a test, too.
22:59:23  * travis-cijoined
22:59:23  <travis-ci>[travis-ci] joyent/libuv#221 (master - 42a8669 : Bert Belder): The build is still failing.
22:59:23  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/84d2f82...42a8669
22:59:23  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1168121
22:59:23  * travis-cipart
23:03:51  <igorzi>piscisaureus_: k
23:04:14  <piscisaureus_>igorzi: take your time, this is hairy
23:04:32  <igorzi>piscisaureus_: still waiting on test cluster, btw
23:04:51  <piscisaureus_>igorzi: yeah, np. I am busy with random stuff anyway
23:05:09  <piscisaureus_>igorzi: thanks btw
23:06:05  <piscisaureus_>creationix: can you give me an executive summary of your problem?
23:08:08  <piscisaureus_>creationix: one thing - pipes are always nonblocking, even stdio pipes
23:08:31  <piscisaureus_>It's inconsistent and I don't like it
23:08:59  <piscisaureus_>I guess we should just have writeSync support for streams
23:09:06  <piscisaureus_>make make console.log use that
23:09:13  <piscisaureus_>^-- bnoordhuis isaacs
23:10:07  <isaacs>piscisaureus_: adding a writeSync method to Stream.prototype is not a good idea.
23:10:10  <TooTallNate>piscisaureus_: in this case he *does* want nonblocking behavior, but isn't getting it apparently
23:10:27  <piscisaureus_>isaacs: ... because?
23:10:51  <piscisaureus_>TooTallNate: yes. I'd much prefer all streams to be nonblocking by default, not have this weird exception
23:11:05  <TooTallNate>sure me too :)
23:11:08  <isaacs>piscisaureus_: because it's increasing a very core API without giving it much thought, just because it's expedient.
23:11:20  <TooTallNate>i think in this case though he's write()ing and it always returns true
23:11:29  <piscisaureus_>This rule
23:11:44  <isaacs>er, not just increasing, but changing
23:12:04  <isaacs>if we're going to add a writeSync method *somewhere*, then that's fine, but it should be internal, and only for these specific cases.
23:12:10  <piscisaureus_>"streams are always nonblocking, except when it's stdio, then it's blocking, except when it's a pipe, then it's nonblocking again"
23:12:32  <piscisaureus_>i mean, what were we using?
23:12:37  <isaacs>is there any way to make stdio *always* blocking, no matter what?
23:12:40  <isaacs>even for pipes?
23:12:49  <piscisaureus_>you mean, is that possible?
23:12:51  <piscisaureus_>sure
23:12:55  <piscisaureus_>is it desirable?
23:12:58  <piscisaureus_>*shrug*
23:13:03  <piscisaureus_>probably not
23:13:23  <TooTallNate>isaacs: wouldn't that be a problem for scripts that want proper flow-control?
23:13:23  <isaacs>i mean, really, the issue is that "Stream" doesn't imply blocking or nonblocking behavior.
23:13:49  <isaacs>but most streams are nonblocking, because there's little benefit to doing io in a blocking manner.
23:13:58  <isaacs>TooTallNate: no, you'd just always return true from write()
23:14:11  <isaacs>TooTallNate: so there'd never be a drain event.
23:14:16  <CIA-155>node: Kyle Robinson Young master * rdf6c12c / doc/api/string_decoder.markdown :
23:14:16  <CIA-155>node: doc: update string_decoder stability index to 3
23:14:16  <CIA-155>node: Ref #3140 - http://git.io/8KMFhA
23:14:18  <TooTallNate>isaacs: ok, well that's apparently what creationix is experiencing now
23:15:18  <piscisaureus_>sounds like a b bb b bbbb b b bug
23:19:43  <isaacs>but yes, "streams are nonblocking except stdio except when it's a pipe" has 1 too many "excepts" in it
23:20:05  <isaacs>making stdio nonblocking is painful, because you lose output when the program ends.
23:20:24  <isaacs>we could make it blocking if we could prevent that, but that seems even more kludgey, and stdio is usually super fast anyway
23:21:01  <isaacs>but i guess if you hook a pipe up to stdio of a child proc, then it could be the handle of a server, and then that kinda breaks the whole "node is evented io" thing
23:21:07  * isaacshmm.
23:22:20  <bnoordhuis>piscisaureus_: https://github.com/cloud9Deploy <- who's that?
23:22:32  <bnoordhuis>creationix: ^ that you
23:23:03  <piscisaureus_>bnoordhuis: no, that's a c9 thing
23:23:25  <piscisaureus_>bnoordhuis: it is a github account that has pubkeys for all the deploy servers
23:23:34  <bnoordhuis>he/she is commenting on our commits :) https://github.com/joyent/node/commit/df6c12c#commitcomment-1252783
23:23:35  <piscisaureus_>bnoordhuis: so the deploy servers can pull from private repos
23:23:50  <piscisaureus_>bnoordhuis: ah, so it was me :-)
23:24:02  <piscisaureus_>bnoordhuis: sorry, I was still logged in as cloud9deploy
23:24:14  <piscisaureus_>had to do something with it this afternoon
23:24:28  <bnoordhuis>hah, okay
23:29:01  <CIA-155>libuv: Ben Noordhuis v0.6 * r06ae804 / src/unix/linux.c :
23:29:01  <CIA-155>libuv: linux: add IN_MOVE_SELF to inotify event mask
23:29:01  <CIA-155>libuv: Partially fixes joyent/node#3172, behavior is now consistent with inotifywait. - http://git.io/eEEPRw
23:30:48  * travis-cijoined
23:30:48  <travis-ci>[travis-ci] joyent/libuv#222 (v0.6 - 06ae804 : Ben Noordhuis): The build is still failing.
23:30:48  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/e6d4bca...06ae804
23:30:48  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1168235
23:30:48  * travis-cipart
23:32:46  <creationix>ok, back
23:33:13  <piscisaureus_>isaacs: yes, making stdio pipes blocking is a really bad idea
23:33:19  <creationix>piscisaureus_, so my problem is write is always returning true
23:33:36  <creationix>I have two cases where I'm seeing this
23:33:49  <creationix>one is writing to node's standard process.stdout
23:34:03  <piscisaureus_>creationix: is process.stdout a pipe in that case?
23:34:15  <creationix>the process is spawned by ssh
23:34:16  <creationix>ssh -C
23:34:23  <creationix>so I guess that's a pipe
23:34:24  <piscisaureus_>creationix: ok, yeah, it should be
23:36:28  <creationix>piscisaureus_, so should it always return true or is that a bug?
23:36:39  <creationix>the other case is I'm writing to stdin, but stdin is a Pipe
23:36:39  <piscisaureus_>creationix: no that's a bug
23:37:02  <creationix>using the same trick as childProcess.fork where I replace the child's stdin with a duplex pipe
23:39:42  <creationix>anyway, I need to go play with my children for a while. Let me know if I should file an issue or something
23:40:29  <piscisaureus_>creationix: https://gist.github.com/2484626
23:40:33  <piscisaureus_>creationix: can you try that?
23:41:26  <piscisaureus_>creationix: sorry, updated
23:41:34  * orlandovftwquit (Ping timeout: 245 seconds)
23:42:50  <piscisaureus_>bnoordhuis, isaacs: what does that test do on unix?
23:42:58  <piscisaureus_>it works on windows (e.g. it doesn't hang)
23:46:01  <isaacs>piscisaureus_: it does hang
23:46:10  <piscisaureus_>ies a bug
23:46:13  <isaacs>piscisaureus_: prints a bunch of Child: process.stdout.write returned true than sits there doing nothing
23:46:28  <piscisaureus_>isaacs: yeah, so probably it's opened blocking
23:46:35  <piscisaureus_>isaacs: that's wrong it seems
23:46:41  <isaacs>yeah
23:46:43  <isaacs>i dunno.
23:46:43  <piscisaureus_>ryah_: here?
23:46:57  <isaacs>ideally, it should not return true if it's actually not flushing, since that's a lie.
23:46:59  <bnoordhuis>piscisaureus_: it prints "Child: process.stdout.write returned true" a whole lot
23:47:23  <piscisaureus_>isaacs: well, if it hangs after a while then the pipe may be blocking
23:47:35  <piscisaureus_>isaacs: if node's memory blows up it's nonblocking but the return value is wrong
23:49:31  <isaacs>memory's pretty stable
23:49:49  <bnoordhuis>the pipe buffer fills up
23:50:05  <bnoordhuis>and it seems to be in blocking mode so eventually the script blocks
23:51:25  <piscisaureus_>ah, right
23:51:31  <piscisaureus_>so it is blocking, hmm
23:51:33  <piscisaureus_>stupid
23:51:37  <piscisaureus_>it's not on windows for sure
23:52:25  <piscisaureus_>wonder if that is something that ryah decided on, because the last thing I remember is that we made this stupid rule outlined above
23:53:58  <bnoordhuis>stdio is supposed to be blocking, right?
23:54:15  <bnoordhuis>no matter what fds 0,1,2 actually refer to
23:54:20  <piscisaureus_>yeah no
23:54:25  <piscisaureus_>I though we had an exception for pipes
23:54:31  <piscisaureus_>*thought
23:54:33  <bnoordhuis>why would we have that?
23:54:43  <piscisaureus_>because otherwise child processes are fucked
23:54:55  <bnoordhuis>how so?
23:55:03  <piscisaureus_>can't use stdout for ipc, since it could block them
23:55:23  <piscisaureus_>if you redirect to a tty or a file, its not so bad
23:55:32  <piscisaureus_>since they never block indefinitely
23:55:55  <piscisaureus_>and having your log stream truncated when node exits is far more painful
23:56:29  <bnoordhuis>doesn't matter, does it? you can still poll the pipe for read/write-ability
23:56:39  <piscisaureus_>bnoordhuis: uhh, how?
23:57:07  <bnoordhuis>put it in the epoll/kqueue/ports fd set
23:57:22  <piscisaureus_>bnoordhuis: so how do you do that in node?
23:57:32  <bnoordhuis>watched fds don't have to be non-blocking for that, you just need to be careful when writing
23:58:31  <bnoordhuis>hmm, i suppose you could hack up a libuv event that says 'hey, you can write exactly x bytes to this here pipe and no more'
23:58:33  <piscisaureus_>bnoordhuis: finish `mything.js`
23:58:33  <piscisaureus_>.// Since process.stdout is blocking, and we don't want process.stdout.write to block our process
23:58:33  <piscisaureus_>.// we're ging to do this:
23:58:33  <piscisaureus_>... <-- fill in here
23:59:00  <bnoordhuis>.// tread very carefully
23:59:22  <piscisaureus_>bnoordhuis: skype
23:59:56  <bnoordhuis>no, not now - mees is finally asleep and i'm just two meters away from her :)