00:03:42  <piscisaureus_>time to go. bye all
00:08:07  * piscisaureus_quit (Ping timeout: 244 seconds)
00:32:32  * AvianFluquit (Quit: Leaving)
00:40:00  * TooTallNatequit (Quit: Leaving...)
00:42:01  <isaacs>igorzi: do you know how to allow inbound connections on an arbitrary port in windows?
00:42:31  <isaacs>igorzi: the server is running, and i can hit it from localhost, but not from outside
00:42:37  <isaacs>i suspect firewall shenanigans
01:17:58  <isaacs>oh, got it figured out
01:34:45  * loladiroquit (Quit: loladiro)
01:39:51  * loladirojoined
01:42:05  * TooTallNatejoined
01:43:44  * abraxasjoined
01:45:11  * loladiroquit (Quit: loladiro)
02:01:11  * loladirojoined
02:14:21  * ericktquit (Quit: erickt)
02:15:25  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:57:22  * abraxasquit (Read error: Connection reset by peer)
02:57:51  * abraxasjoined
03:03:40  <CIA-155>node: isaacs master * r7193767 / (121 files in 13 dirs): upgrade npm to 1.1.23 - http://git.io/tv91EQ
03:03:41  <CIA-155>node: isaacs master * r8a411ba / tools/test.py : Revert "tests: kill process group on failure" - http://git.io/byYfGg
03:07:59  * c4milojoined
03:13:47  * brsonquit (Quit: leaving)
03:39:36  <deoxxa>what's a status of -8 mean for a uv_getaddrinfo callback?
03:40:45  * c4miloquit (Remote host closed the connection)
03:43:18  * abraxasquit (Ping timeout: 252 seconds)
03:48:34  <CIA-155>node: isaacs v0.7.9-release * r782277f / (AUTHORS ChangeLog src/node_version.h): 2012.05.28, Version 0.7.9 (unstable) - http://git.io/pN6RaA
04:01:07  * mjr_joined
04:01:49  * abraxasjoined
04:03:35  * abraxasquit (Read error: Connection reset by peer)
04:04:02  * abraxasjoined
04:08:36  * abraxasquit (Read error: Connection reset by peer)
04:10:13  * abraxas_joined
04:23:52  * demarchiquit (Ping timeout: 252 seconds)
04:35:54  * demarchijoined
04:50:14  * isaacsquit (Remote host closed the connection)
04:51:14  * isaacsjoined
04:52:45  * isaacsquit (Remote host closed the connection)
04:52:49  * isaacs_joined
05:06:42  * loladiropart
05:11:53  * isaacs_quit (Remote host closed the connection)
05:12:48  * isaacsjoined
05:20:09  * isaacsquit (Ping timeout: 246 seconds)
05:47:39  * mikealquit (Quit: Leaving.)
05:48:46  * mikealjoined
06:04:11  * paddybyersjoined
06:24:18  * paddybyersquit (Read error: Connection reset by peer)
06:24:38  * paddybyersjoined
07:03:28  * mmaleckijoined
07:11:47  * indutnyquit (Ping timeout: 245 seconds)
07:11:48  * mrb_bkquit (Ping timeout: 245 seconds)
07:12:06  * rphillipsquit (Ping timeout: 245 seconds)
07:13:52  * mmaleckiquit (Quit: leaving)
07:14:56  * rphillipsjoined
07:28:25  * mrb_bkjoined
07:39:04  * indutnyjoined
07:56:07  * saghuljoined
08:49:48  * rendarjoined
09:20:10  * TheJHjoined
09:35:48  * felixgejoined
09:35:48  * felixgequit (Changing host)
09:35:48  * felixgejoined
10:01:24  * bnoordhuisjoined
10:33:03  * theColejoined
11:09:10  * TheJHquit (Ping timeout: 252 seconds)
11:14:12  <CIA-155>node: Ben Noordhuis master * rfa9aa1c / (lib/net.js test/simple/test-net-server-close.js): net: fix 'close' event emit order - http://git.io/ZPzfYQ
11:17:21  * toothrquit (Ping timeout: 240 seconds)
11:22:38  * toothrjoined
11:25:19  <saghul>bnoordhuis yt?
11:26:00  <bnoordhuis>saghul: ih
11:26:51  <saghul>bnoordhuis quick q: after UV_LEAN_AND_MEAN was removed, will there ever be a way to get a list of handles in a loop or do applications using libuv need to keep it themselves?
11:27:17  <bnoordhuis>saghul: we'll be adding uv_walk() soonish
11:27:29  <saghul>bnoordhuis great! :-)
11:29:53  * rendarquit
11:32:43  * rendarjoined
11:39:53  * TheJHjoined
11:40:54  * abraxas_quit (Remote host closed the connection)
11:41:25  * abraxasjoined
12:03:53  * loladirojoined
12:20:08  * loladiroquit (Quit: loladiro)
12:23:40  * loladirojoined
12:51:41  * theColequit (Quit: theCole)
13:03:03  * loladiroquit (Quit: loladiro)
13:10:43  * abraxasquit (*.net *.split)
13:10:43  * rphillipsquit (*.net *.split)
13:10:43  * mjr_quit (*.net *.split)
13:12:28  * rphillipsjoined
13:16:48  * abraxasjoined
13:16:48  * mjr_joined
13:37:20  <CIA-155>node: Andreas Madsen v0.6 * r2ae9b69 / (lib/fs.js test/simple/test-fs-empty-readStream.js): fs: no end emit after createReadStream.pause() - http://git.io/3JxbvQ
13:40:12  * c4milojoined
13:41:27  * theColejoined
13:44:54  * abraxasquit (Remote host closed the connection)
13:45:28  * abraxasjoined
13:50:01  * abraxasquit (Ping timeout: 252 seconds)
13:51:10  <indutny>bnoordhuis: heya
13:51:18  <bnoordhuis>indutny: hoya
13:51:32  <indutny>bnoordhuis: can I help you fixing problems with uv on sunos?
13:51:42  <bnoordhuis>indutny: what in particular?
13:52:10  <indutny>bnoordhuis: dunno, isaac and bert mentioned them as blockers for my and igorzi's libuv patch going into node's master
13:52:22  <bnoordhuis>oh, that - that's already fixed :)
13:52:35  <indutny>bnoordhuis: cool
13:52:45  <indutny>bnoordhuis: lets update uv in node then
13:52:52  <bnoordhuis>indutny: already done :)
13:52:57  <indutny>huh
13:52:59  <indutny>well
13:53:06  <indutny>you've surprised me :D
13:53:38  <bnoordhuis>or rather, i cherry-picked the commit
13:53:46  <bnoordhuis>node still needs to be updated to the new stdio api
13:54:52  <indutny>bnoordhuis: aaah
13:54:57  <indutny>bnoordhuis: well, so it's broken now?
13:55:03  <indutny>bnoordhuis: I did that update yesterday
13:55:05  <indutny>and opened a PR
13:55:17  <indutny>ah
13:55:22  <indutny>looks like I forgot to open PR
13:56:08  <indutny>bnoordhuis: https://github.com/indutny/node/commit/d98ec48656c36e23398f59e822f1c505fec764b0
13:56:17  <indutny>actually, this one https://github.com/indutny/node/commit/d98ec48656c36e23398f59e822f1c505fec764b0#diff-19
13:56:21  * bnoordhuislooks
13:56:45  <bnoordhuis>make sure to use libuv HEAD
13:56:58  <indutny>bnoordhuis: well, that's yesterday's version
13:57:09  <indutny>bnoordhuis: I'll update it, though node's code shouldn't change much
13:59:05  <bnoordhuis>one comment but otherwise lgtm
13:59:11  <indutny>bnoordhuis: btw, I was always curious, why gyp is ignoring v8 and uv changes
13:59:16  <indutny>and rebuilding just node
13:59:30  <bnoordhuis>it shouldn't... but it sometimes does
13:59:34  <bnoordhuis>not sure why
13:59:40  <bnoordhuis>re PR, i assume it passes all tests?
13:59:44  <indutny>bnoordhuis: why should I memset it?
13:59:57  <indutny>bnoordhuis: just for security?
13:59:59  <bnoordhuis>are you sure you set all fields otherwise?
14:00:05  <indutny>bnoordhuis: well, yes
14:00:16  <indutny>I'm seeting UV_IGNORE
14:00:23  <indutny>and in other cases setting data.stream
14:00:45  <bnoordhuis>indutny: what if the uv_stdio_container_t struct gets extended later on?
14:01:05  <indutny>bnoordhuis: hm
14:01:09  <indutny>bnoordhuis: by whom?
14:01:27  <bnoordhuis>by someone, it doesn't matter
14:02:32  <indutny>ook, I don't get your point, by I'll memset it
14:02:42  <indutny>just for peace
14:03:55  <bnoordhuis>i guess my point is that a memset doesn't cost much and it may help catch bugs later on
14:04:25  <bnoordhuis>tracking down null pointer derefs is a lot easier than tracking down a stray pointer
14:05:05  <indutny>ok
14:05:13  <indutny>bnoordhuis: valgrind to save us all :)
14:05:57  <pfox__>you like valgrind now.
14:12:14  * irajoined
14:15:02  <indutny>bnoordhuis: https://github.com/indutny/node/commit/4c670ff61197eb17a419f8c71282a5550158732a
14:20:05  * felixgequit (Quit: felixge)
14:24:56  <indutny>bnoordhuis: how does it looks?
14:25:26  <bnoordhuis>indutny: lgtm but change the commit log to what's common for libuv upgrades
14:25:51  <indutny>ok
14:25:57  <bnoordhuis>though admittedly igorzi does it like that, too :-)
14:26:13  <bnoordhuis>i prefer 'deps: upgrade libuv to xxx' myself though
14:26:42  <indutny>bnoordhuis: I just did it
14:26:46  <indutny>bnoordhuis: pushing to master?
14:26:51  <bnoordhuis>sure
14:27:32  <CIA-155>node: Fedor Indutny master * r761e0c4 / (16 files in 6 dirs): deps: upgrade libuv to 7556590 - http://git.io/0NDzqA
14:33:18  * piscisaureus_joined
14:43:43  * isaacsjoined
14:47:25  <isaacs>Test, please: http://nodejs.org/dist/v0.7.9/ or 782277f11a753ded831439ed826448c06fc0f356
15:03:08  * felixgejoined
15:03:08  * felixgequit (Changing host)
15:03:08  * felixgejoined
15:04:58  * travis-cijoined
15:04:59  <travis-ci>[travis-ci] indutny/node#3 (feature-uv-update - 4c670ff : Fedor Indutny): The build is still failing.
15:04:59  <travis-ci>[travis-ci] Change view : https://github.com/indutny/node/compare/d98ec48...4c670ff
15:04:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/indutny/node/builds/1465765
15:04:59  * travis-cipart
15:07:28  <isaacs>indutny: can you unhook travis from your private fork?
15:07:51  <isaacs>indutny: or configure the .travis.yml to not do the irc thing?
15:09:23  <indutny>isaacs: ok
15:10:57  <indutny>isaacs: done
15:11:30  <isaacs>thanks :)
15:18:00  * hij1nxjoined
15:25:45  <piscisaureus_>isaacs: why are smartmachines all 32 bits?
15:26:46  <isaacs>piscisaureus_: they're not
15:27:00  <isaacs>piscisaureus_: we have 64bit smartos and linux
15:29:42  <piscisaureus_>isaacs: so why is umcats 32-bit?
15:29:54  <piscisaureus_>[root@6ab92b32-517e-43d1-a27d-564b8922b927 ~]# uname -a
15:29:54  <piscisaureus_>SunOS 6ab92b32-517e-43d1-a27d-564b8922b927.local 5.11 joyent_20120126T071347Z i86pc i386 i86pc Solaris
15:30:26  <isaacs>piscisaureus_: because i provisioned a 32bit machine
15:30:31  <isaacs>piscisaureus_: i can provision a 64bit if you watn
15:30:32  <piscisaureus_>aah ok
15:30:36  <piscisaureus_>not really :-)
15:30:52  <piscisaureus_>so why do you provision a 32-bit machine?
15:31:14  <piscisaureus_>isaacs: that said, I have never seen a 64 bit smartmachine
15:31:56  <isaacs>piscisaureus_: get ready. you're about to :)
15:32:00  <piscisaureus_>isaacs: and the "i have never seen one" -> "doesn't exists" logic is impeccable
15:32:07  <piscisaureus_>*exist
15:36:06  <isaacs>piscisaureus_: ssh root@
15:36:09  <isaacs>piscisaureus_: ssh root@
15:36:20  <isaacs>piscisaureus_: i'm pkgin'ing stuff now
15:36:36  <CIA-155>libuv: Ben Noordhuis master * rec0c7b8 / test/test-loop-handles.c : test: fix double close in test-loop-handles.c - http://git.io/GhMTIA
15:36:37  <CIA-155>libuv: Ben Noordhuis master * r12ee388 / test/test-loop-handles.c : test: clean up test-loop-handles.c - http://git.io/2BFkNQ
15:36:57  <piscisaureus_>isaacs: you sure?
15:36:59  <piscisaureus_>[root@a9c65738-3994-4939-ad4b-9711eeb44457 ~]# uname -a
15:36:59  <piscisaureus_>SunOS a9c65738-3994-4939-ad4b-9711eeb44457.local 5.11 joyent_20120424T232010Z i86pc i386 i86pc Solaris
15:37:10  <indutny>please do not do any commits to master if possible
15:37:14  <indutny>I mean node's master
15:37:19  <bnoordhuis>why not?
15:37:26  <indutny>just finished hard rebase
15:37:32  <indutny>going to open PR for child_process
15:37:39  <indutny>bnoordhuis: do you have anything pending?
15:37:50  * mikealquit (Quit: Leaving.)
15:37:54  <bnoordhuis>the java rewrite. other than that, nothing
15:38:10  <isaacs>piscisaureus_: yeah, that's weird..
15:38:20  <isaacs>piscisaureus_: the image is sdc:sdc:smartos64
15:38:32  <isaacs>piscisaureus_: so if that 64 doesn't mean "64 bit" then i'm confused
15:38:46  <piscisaureus_>maybe it means smartos 6.4 :-)
15:42:08  <indutny>it's obvious
15:42:09  <isaacs>[root@a9c65738-3994-4939-ad4b-9711eeb44457 ~]# isainfo
15:42:09  <isaacs>amd64 i386
15:42:12  <isaacs>piscisaureus_: uname lies :)
15:42:28  <tjfontaine>clearly uname was built only 32bit
15:42:32  <piscisaureus_>ghe
15:42:44  <deoxxa>bad uname. uname is not getting desert tonight.
15:42:47  <piscisaureus_>so that means that prolly everyone will build node 32 bit on sunos
15:43:38  <deoxxa>erm, dessert
15:44:37  <indutny>piscisaureus_: does windows implementation of libuv support stdio > 3 in HEAD?
15:44:46  <piscisaureus_>indutny: no
15:44:48  <piscisaureus_>indutny: working on it
15:44:54  <piscisaureus_>will be done today
15:45:25  * AndreasMadsenjoined
15:54:28  <piscisaureus_>root
15:56:01  * brsonjoined
16:02:48  * loladirojoined
16:06:54  * loladiroquit (Client Quit)
16:12:23  * loladirojoined
16:14:36  * loladiroquit (Client Quit)
16:15:55  * loladirojoined
16:17:03  * travis-cijoined
16:17:03  <travis-ci>[travis-ci] joyent/libuv#336 (master - 12ee388 : Ben Noordhuis): The build passed.
16:17:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/7556590...12ee388
16:17:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1466792
16:17:03  * travis-cipart
16:20:56  <isaacs>piscisaureus_: ok, so, yeah, building node x64 on SmartOS fails.
16:21:13  <isaacs>piscisaureus_: seems a bit complicated. i'm gonna post an issue
16:21:33  * AvianFlujoined
16:22:42  * brsonquit (Ping timeout: 246 seconds)
16:24:11  * brsonjoined
16:38:06  * hij1nxquit (Quit: hij1nx)
16:39:30  * loladiroquit (Quit: loladiro)
16:42:42  * brsonquit (Ping timeout: 252 seconds)
16:43:50  * philipsquit (Excess Flood)
16:45:00  * loladirojoined
16:45:34  * philipsjoined
16:48:11  * paddybyersquit (Quit: paddybyers)
16:52:12  <felixge>FATAL ERROR: v8::Object::SetIndexedPropertiesToExternalArrayData() length exceeds max acceptable value <--- creating a 1 GB buffer?
16:52:35  <felixge>> new Buffer(1024 * 1024 * 1024)
16:52:40  <felixge>seems silly
16:53:05  <tjfontaine>sounds like an OOM?
16:55:08  <felixge>tjfontaine: happens for me on a machine with 8 Gigabyte of memory
16:55:13  <felixge>so I doubt it
16:55:27  <felixge>1 Gigabyte - 1 Byte buffers work
16:55:33  <felixge>so it seems like some silly hardcoded value
16:56:01  <tjfontaine>it could be ulimit or similar operating system heap restriction
16:56:09  <piscisaureus_>hey isaacs
16:56:57  <piscisaureus_>felixge: it could be (likely even) that the length of an external buffer is stored as an SMI
16:58:40  <isaacs>hi
16:59:09  <piscisaureus_>isaacs: When I do 'pkgin in <<something>>' it always tells me there is nothing to do
16:59:35  <isaacs>piscisaureus_: got an example of a <<something>>?
16:59:42  <piscisaureus_>isaacs: nano. gcc47
16:59:44  <isaacs>piscisaureus_: and, is it possible it's laready installed?
16:59:50  <piscisaureus_>isaacs: it's definitely not :-)
17:00:07  <isaacs>piscisaureus_: what do the lines above "nothing to do" say?
17:00:16  <isaacs>[root@a9c65738-3994-4939-ad4b-9711eeb44457 ~]# pkgin in gcc47
17:00:16  <isaacs>gcc47 is not available on the repository
17:00:16  <isaacs>calculating dependencies... done.
17:00:17  <isaacs>nothing to do.
17:00:20  <piscisaureus_>yes, that
17:00:22  <isaacs>gcc47 isn't in the repo
17:00:22  <piscisaureus_>no
17:00:33  <isaacs>pking no has it
17:00:33  <piscisaureus_>without the "not available" line
17:01:03  <isaacs>piscisaureus_: try using `pkgin se` to search for it
17:01:05  <isaacs>see what that says
17:01:08  <piscisaureus_>yes, it's there
17:01:13  <piscisaureus_>both nano and gcc47
17:01:56  <isaacs>piscisaureus_: does it have an = next to it?
17:02:03  <piscisaureus_>nope
17:02:20  <piscisaureus_>isaacs: http://screencast.com/t/b9cvSl7Zez
17:02:37  <isaacs>https://gist.github.com/2829532
17:03:07  <isaacs>piscisaureus_: i dunno
17:03:10  * loladiroquit (Quit: loladiro)
17:03:12  <isaacs>piscisaureus_: maybe ask in #smartos?
17:03:17  <piscisaureus_>good idea
17:03:19  <isaacs>or #joyent
17:03:38  * hij1nxjoined
17:03:49  <isaacs>ok, if there are no objections, i'm gonna unveil 0.7.9
17:04:26  * loladirojoined
17:06:14  <creationix>isaacs, I'm closing my email to focus on work, ping me if I need to comment on https://github.com/joyent/node/issues/3335#issuecomment-5984731
17:06:29  <isaacs>creationix: np, thanks
17:07:57  * theColequit (Quit: theCole)
17:08:05  * avalanch_joined
17:09:10  <CIA-155>node: isaacs master * r782277f / (AUTHORS ChangeLog src/node_version.h): 2012.05.28, Version 0.7.9 (unstable) - http://git.io/pN6RaA
17:09:11  <CIA-155>node: isaacs master * ra9e4028 / (AUTHORS ChangeLog src/node_version.h): Merge branch 'v0.7.9-release' - http://git.io/w4T38Q
17:09:11  <CIA-155>node: isaacs master * rdc8b488 / src/node_version.h : Now working on 0.7.10 - http://git.io/xypqIw
17:11:43  * AvianFlu_joined
17:12:03  * AvianFluquit (Disconnected by services)
17:12:05  * japjjoined
17:12:07  * AvianFlu_changed nick to AvianFlu
17:20:20  * mmaleckijoined
17:25:07  * `3rdEdenjoined
17:30:28  * TooTallNatejoined
17:31:20  * brsonjoined
17:36:33  * hij1nxquit (Quit: hij1nx)
17:37:35  * hij1nxjoined
17:40:59  * paddybyersjoined
17:42:53  <indutny>oh crap
17:43:00  <indutny>isaacs: yt?
17:43:04  <indutny>I just realized one thing
17:43:28  <indutny>isaacs: https://github.com/joyent/node/blob/master/lib/child_process.js#L449
17:43:37  <indutny>isaacs: we're opening 'ipc' only on fd=0
17:43:49  <indutny>I could change it to fd=3
17:43:55  <indutny>but that doesn't make any sense
17:44:19  <piscisaureus_>indutny: y not?
17:44:39  <indutny>piscisaureus_: because we're providing very flexible API that allows user to pass 'ipc' as any stdio
17:44:53  <indutny>like stdio: ['pipe', 'pipe', 'ipc'] or ['pipe', 'ipc', 'pipe']
17:44:58  <indutny>I think we need an env var for it
17:45:08  <indutny>like we're doing in lib/cluster.js
17:45:14  <indutny>NODE_UNIQUE_ID
17:45:20  <indutny>NODE_IPC_FD
17:45:29  <indutny>any ideas?
17:45:31  <piscisaureus_>well we could just do UV_IPC_FDS
17:45:37  <piscisaureus_>well we could just do UV_IPC_FDS=1,34,4
17:45:56  <indutny>please no
17:45:56  <indutny>:D
17:46:02  <piscisaureus_>indutny: but I think on unix it is easy, you can just check whether your socket supports SCM_RIGHTS
17:46:11  <piscisaureus_>this is only a problem on windows
17:46:23  <indutny>piscisaureus_: well, I can't check every fd :D
17:46:40  <piscisaureus_>sure, but but we do guess_handle
17:46:51  * japjquit (Read error: Operation timed out)
17:47:08  <indutny>piscisaureus_: anyway I think it shouldn't be in libuv
17:47:10  <indutny>for two reasons
17:47:12  <piscisaureus_>why not?
17:47:19  <indutny>1) working with string in C is PITA
17:47:54  <indutny>2) in most cases user know which stdio index child process should use for IPC
17:48:21  <isaacs>indutny, piscisaureus_: We only ever have one IPC fd.
17:48:34  <piscisaureus_>oh. why?
17:48:37  <isaacs>i think just NODE_IPC_FD=3 should be fine.
17:48:38  <indutny>isaacs, piscisaureus_: well we don't limit it in uv
17:48:50  <isaacs>piscisaureus_: what's the value of having more than one?
17:49:13  <piscisaureus_>I dunno, what's the value of having more than 3 FDs >:-)
17:49:16  <isaacs>we don't have to limit it in libuv, necessarily, but we ought to limit it in node
17:49:30  <isaacs>piscisaureus_: i mean, you just do child.send() and child.on('message'), right?
17:49:38  <isaacs>piscisaureus_: there's no API to decide which fd to use anyway
17:49:49  <piscisaureus_>isaacs: well, that's in the fork() case
17:50:06  <piscisaureus_>isaacs: if the user sets an explicit ipc fd I dont' think we should do that
17:50:13  <isaacs>piscisaureus_: it's also the spawn(..., { stdio:[-1,-1,-1,'ipc'] }}) case
17:50:14  <piscisaureus_>hmm, well, maybe
17:50:18  <isaacs>piscisaureus_: why not?
17:50:24  <piscisaureus_>yeah
17:50:31  <piscisaureus_>would be cool probably
17:50:35  <isaacs>i mean, this ipc thing really only works if the other end knows what to do with it anyway
17:50:46  <piscisaureus_>well, on unix it's probably more flexible
17:50:53  <isaacs>but people have asked repeatedly for it to be open to stuff other than node.
17:50:54  <indutny>ok
17:50:56  <piscisaureus_>you basically have an unix domain socket if you create an ipc channel
17:50:57  <indutny>so NODE_IPC_FD
17:51:22  <piscisaureus_>but not on windows... the other process can't distinguish an ipc channel from a pipe
17:51:33  <piscisaureus_>if it makes a mistake it will see garbage
17:51:36  <isaacs>piscisaureus_: right, it'll have to know what to do with the env
17:51:50  <isaacs>same as on unix, really
17:52:20  <isaacs>but this way, instead of "a special api for only running node programs", it could be "a special api that node provides, with some sugar for running node programs, but do whatever you want with it"
17:52:24  <indutny>you guys are so clever
17:52:32  <piscisaureus_>yeah, ok
17:52:37  <piscisaureus_>indutny: sarcams?
17:52:41  <piscisaureus_>*sarcasm?
17:52:52  <isaacs>and the forever/coffee/jitsu folks can finally be quiet
17:53:07  <indutny>oh we have NODE_CHANNEL_FD
17:53:18  <indutny>piscisaureus_: nooo
17:53:21  <indutny>marasm
17:53:26  <isaacs>NODE_CHANNEL_FD sounds like it's the right thing for this
17:53:31  <piscisaureus_>ok, fine
17:53:38  <indutny>well, it's equal to 42
17:53:39  <isaacs>NODE_UNIQUE_ID is already used for cluster
17:53:46  <isaacs>indutny: yeah, it should not be = 42
17:53:47  <isaacs>:
17:53:48  <isaacs>:)
17:53:56  <piscisaureus_>indutny: I think NODE_CHANNEL_FD is not actually used
17:53:59  <piscisaureus_>but it could be resurrected
17:54:13  <isaacs>piscisaureus_: no, it was an 0.4-ism, i think
17:54:34  <isaacs>that's why it's set to 42 now
17:54:41  <indutny>yeah
17:54:50  <indutny>I'll resurrect it
18:01:36  <isaacs>piscisaureus_: you wanna discuss listenFD/listenHandle?
18:02:06  <isaacs>piscisaureus_: seems like we can just bless the pipe_wrap workaround
18:02:35  <indutny>piscisaureus_: should I use fd=3 for 'ipc', or wait for your patch first?
18:03:06  <indutny>piscisaureus_: I think I'll use stdin for 'ipc' for now
18:03:41  <tjfontaine>http://gizmodo.com/5913927/adjustable-sliding-lens-glasses-let-you-tweak-your-prescription
18:03:45  <tjfontaine>er
18:03:45  <tjfontaine>ww
18:05:13  <isaacs>indutny: honestly, using stdin for ipc is probably fine. just thinking it'd be nice to allow ipc with a child proc that also reads from stdin
18:05:29  <indutny>isaacs: well, I think that forks should have stdin
18:05:45  <indutny>isaacs: otherwise it's really limiting communication
18:05:55  <isaacs>yeah
18:05:55  <indutny>isaacs: separate utilities needs to be developed
18:06:10  <isaacs>but, i mean, we can put that off if we need to.
18:06:32  <indutny>5
18:06:33  <indutny>4
18:06:33  <indutny>3
18:06:33  <indutny>2
18:06:35  <indutny>1
18:06:44  <indutny>0
18:06:44  <indutny>https://github.com/indutny/node/commit/68e04d4cc900f60efae9fe269871e24aab6081a6
18:06:46  <indutny>:D
18:06:56  <indutny>isaacs: piscisaureus_ bnoordhuis: please review!
18:07:07  <indutny>I did some hard-core rebasing, so please be very careful
18:07:12  <indutny>I might missed something
18:07:19  <indutny>brb
18:07:21  <indutny>need some tea
18:10:44  * AvianFluquit (Remote host closed the connection)
18:12:27  <isaacs>indutny: i wanna update v8 on master. is that going to make your life harder?
18:12:38  * bitprobejoined
18:12:46  <isaacs>there's been a bunch of releases, and i'm hoping that this silly getter bug is fixed
18:14:15  * AvianFlujoined
18:17:19  <indutny>isaacs: well, better get my commit merged before it
18:17:27  <indutny>isaacs: yep, that bug is really silly
18:17:36  <indutny>isaacs: but look, my patch is ready :D
18:17:45  <isaacs>kk
18:19:54  * isaacsreviewin
18:21:36  <isaacs>indutny: it'd be nice to have customFds translate into a stdio setting
18:21:45  <isaacs>indutny: rather than just drop support for it
18:22:08  * loladiroquit (Quit: loladiro)
18:22:32  <isaacs>hahhah :https://github.com/indutny/node/commit/68e04d4cc900f60efae9fe269871e24aab6081a6#L0L671
18:22:36  <isaacs>that error message is so confusing
18:22:48  <isaacs>in the docs we say it's deprecated, then in the error msg we say "not yet" as if it'll show up later.
18:24:49  <indutny>ahhaha
18:25:08  <indutny>yep, very nice
18:35:17  * iraquit (Quit: Textual IRC Client: http://www.textualapp.com/)
18:38:01  * mmalecki_joined
18:40:24  * mmaleckiquit (Ping timeout: 252 seconds)
18:41:20  * mmalecki_quit (Client Quit)
18:41:35  * mmaleckijoined
18:50:20  * pieternjoined
19:04:56  <indutny>isaacs: updated PR
19:05:06  <isaacs>i see :)
19:10:06  * mikealjoined
19:12:51  <indutny>crap, looks like I got sick
19:14:24  <isaacs>indutny: you got sick?
19:14:50  <indutny>well, I dunno how that can be said in english
19:14:57  <indutny>but I'm sick :D
19:15:12  <isaacs>indutny: like you got a cold or something?
19:15:17  <indutny>sort of
19:15:32  <isaacs>indutny: oh no
19:15:42  <isaacs>that's no fun
19:16:24  <isaacs>indutny: patch looks pretty good to me. i'd like to get piscisaureus_ and/or bnoordhuis to sign off on it before merging.
19:16:34  <indutny>yeah, of course
19:16:39  * avalanch_quit (Ping timeout: 246 seconds)
19:16:42  <indutny>I'll be up for few more hours
19:16:56  <isaacs>if you're not feeling well, you should get some rest, man.
19:17:30  <indutny>isaacs: no worries, I'll be anyway up :D
19:17:49  <indutny>isaacs: but thanks for caring about that
19:18:43  * avalanch_joined
19:20:21  * mmaleckiquit (Quit: Lost terminal)
19:20:39  * mmaleckijoined
19:25:03  <felixge>is udp working on 0.6.x ?
19:25:46  * `3rdEdenquit (Quit: Leaving...)
19:27:14  <isaacs>felixge: it should be. 0.6.12 or something added that
19:27:41  <felixge>isaacs: thanks. will debug this further and let you know
19:28:06  <felixge>isaacs: what about renaming bind() to listen() for udp server sockets?
19:28:16  <felixge>just to be in sync with http?
19:28:18  <felixge>and net?
19:28:38  * mmaleckiquit (Quit: Lost terminal)
19:28:57  * mmaleckijoined
19:31:06  <felixge>ah I think I figured it out, seems like my MTU for localhost is < 10 kb
19:33:21  * avalanch_quit (Ping timeout: 245 seconds)
19:35:28  * avalanch_joined
19:36:23  <felixge>next silly udp question: should I expect to see udp messages to be lost on my loopback interface? (When sending 1 Gigabyte chunked as 8kb messages very quickly?)
19:36:43  <felixge>I'd assume to see this on an actual network, but against loopback ?
19:41:12  <isaacs>felixge: that sounds buggy
19:41:57  <felixge>isaacs: let me post my test scripts real quickly
19:42:27  <mjr_>felixge: what OS?
19:42:42  <mjr_>Also: yes
19:43:14  <mjr_>While we are on the subject, you'll probably find that node's UDP is WAY slower than TCP.
19:44:06  <felixge>mjr_: OSX (was going to run the actual performance tests on linux, but tripped over this locally right away)
19:44:10  <felixge>https://gist.github.com/2830262
19:44:21  <felixge>^--- isaacs, mjr_: my test scripts
19:46:01  <felixge>FWIW: also seeing packet loss on Linux (but much less, 938 megabyte come through)
19:46:32  <mjr_>Yeah, it'll drop like crazy on OSX. The kernel happily accepts UDP sends and then drops them.
19:46:59  <indutny>piscisaureus_: nice!
19:47:46  <felixge>when running this test between California and Ireland I'm seeing only 36mb (of 1024) make it through the wire
19:48:01  <felixge>: )
19:48:11  <felixge>so the loopback interface isn't all that bad : )
19:48:43  <felixge>and I'm starting to think that file transfer over udp is a stupid idea as you'll have to go through the same trouble as tcp to ensure delivery, except you'll have to do it in userland
19:48:48  <mjr_>You can sort of tune a sending loop with setTimeout to find out how fast you can really go
19:49:06  <mjr_>File transfer over UDP is a stupid idea.
19:49:10  <mjr_>Fun experiment though.
19:49:23  <tjfontaine>there are lots of apps out there that specialize in it
19:49:37  <felixge>so far the most reliable and fastest file transfer seems to be using lots of parallel tcp connections
19:49:48  <felixge>which is also a hack, but a rather simple one
19:50:27  <felixge>I'm also playing with tcp window scaling to optimize single connection throughput, but I can't get it to go as fast / stable as multiple tcp connections by a long shot
19:50:58  <felixge>mjr_: there are these expensive file transfer thingies that claim to be insanely fast over udp
19:51:09  <mjr_>felixge: window scaling was supposed to solve this, but congestion control in routers evolved faster.
19:51:43  <mjr_>By the design of the TCP Elders, a single TCP with a giant window + selective ACK should beat everybody.
19:51:44  <felixge>(I'm talking about stuff like this which is udp based: http://www.asperasoft.com/en/technology/fasp_versus_FTP_4/fasp_versus_FTP_4 )
19:52:00  <felixge>mjr_: but it seems like it doesn't?
19:52:03  <tjfontaine>http://www.tcnj.edu/~bush/uftp.html http://tsunami-udp.sourceforge.net/
19:52:14  <felixge>tjfontaine: yeah, another one
19:52:27  <tjfontaine>there's two there, those are the ones I remember
19:52:27  <mjr_>Aspera is very cool.
19:52:32  <felixge>actually looked at this a lot and deemed it worthless as it doesn't let you create bindings for it
19:52:52  <felixge>^--- that was at: tjfontaine / tsuanmi
19:52:56  <piscisaureus_>felixge: you can do file transfer over UDP but you'll have to do slow start / window scaling yourself
19:53:01  <felixge>mjr_: you tried aspera ?
19:53:21  <felixge>piscisaureus_: why would I want to do it if creating lots of tcp connections also seems to do the trick?
19:53:32  <mjr_>We looked at Aspera a while ago to see if we could license their stuff for our application to use.
19:53:51  <piscisaureus_>ghe
19:53:53  <felixge>at 100 connections I can transfer 1 Gigabyte from California to Ireland in ~30 seconds which is about as fast / faster as some of the stuff published by
19:53:59  <felixge>published by Aspera
19:54:13  <felixge>mjr_: what was your conclusion?
19:54:33  <piscisaureus_>felixge: you can also just set the max tcp window to a massive value on both ends, and tweak slow start to be very aggressive
19:54:51  <felixge>piscisaureus_: I did set the max tcp windows fairly big (40 megabytes)
19:55:00  <felixge>piscisaureus_: how should I tweak the slow start?
19:55:04  <mjr_>My conclusion is that Aspera is the best way to move files over the Internet.
19:55:11  <piscisaureus_>felixge: on both ends?
19:55:17  <piscisaureus_>felixge: (the tcp window)
19:55:22  <indutny>piscisaureus_: require('child_process').spawn('ls', [], { stdio: ['pipe', 'pipe', 'pipe', 'shnack'] })
19:55:23  <indutny>hahahahaha
19:55:27  <felixge>piscisaureus_: yes
19:55:40  <felixge>piscisaureus_: both fresh linux machines that I set up just for this
19:55:44  * igorziquit (Ping timeout: 245 seconds)
19:55:52  <piscisaureus_>felixge: did it make any difference? Maybe you'd also have to set SO_SNDBUF to a larger value
19:56:02  <piscisaureus_>(not sure, maybe that's automatic) <-- bnoordhuis ?
19:56:09  <felixge>mjr_: so you bought their stuff? Or where there other problems / concerns?
19:56:37  <felixge>piscisaureus_: it made a difference, I saw single connection speeds go from 4 megabytes / sec to ~40
19:56:48  <felixge>but it really varies a lot between every run
19:57:04  <felixge>with multiple connections I'm seeing ~50-70 megabytes / sec very consistently, without any window tuning
19:57:21  <piscisaureus_>felixge: the risk of many connections is the "silly receive window trap"
19:57:25  <felixge>(also after tuning the windows using multiple connections seems to be much slower)
20:00:22  <felixge>piscisaureus_: how do I avoid that?
20:00:27  <piscisaureus_>heh
20:00:29  <piscisaureus_>you can't really
20:00:35  <piscisaureus_>don't open up too many connections
20:00:43  <piscisaureus_>and if you do, make sure the tcp windows aren't too big :-)
20:00:50  <felixge>also, if anybody has good recommendations on stuff to read about tcp/udp I'd be very happy to do so and shut up for a while :)
20:01:04  <piscisaureus_>sounds like an interesting challenge
20:01:05  <felixge>the stuff I found so far is all over the place in terms of quality :)
20:01:11  <piscisaureus_>udp file transfer
20:01:11  <mjr_>felixge: we did not buy Aspera. It's really clever stuff designed to solve a different problem.
20:01:27  <mjr_>We just open a shitload of TCPs.
20:01:49  <felixge>mjr_: by that you mean multiple tcp connections per client?
20:01:58  <felixge>or just that you have shitloads of clients?
20:02:01  <felixge>(I'd guess both?)
20:02:04  <mjr_>Both
20:02:22  <mjr_>Also our server processes talk to each other with lots and lots of TCPs instead of more efficiently multiplexing them somehow.
20:02:52  <felixge>mjr_: seems like a reasonable complexity / performance tradeoff ?
20:03:12  <felixge>I'm thinking about doing a node module as well as a client side one that allows to pipe streams/files over multiple connections
20:03:13  <mjr_>Thanks to HTTPS being so slow tough, I'm trying to figure out how to get our clients back to just a single TLS connection over which requests are multiplexed.
20:03:24  <mjr_>Like SPDY or WS.
20:03:36  <felixge>I see
20:03:58  <felixge>and by https being slow you mean the handshake overhead, or the actual connection after it is established ?
20:04:10  <mjr_>Just the setup overhead.
20:04:23  <mjr_>I can take 1-6 seconds on a mobile phone.
20:04:47  * xaqjoined
20:04:47  <felixge>I see
20:04:58  <felixge>I don't care too much about the initial connection overhead for my use case I think
20:05:45  <felixge>as long as it's not crazy huge, I'm happy to trade off setup overhead in exchange for simple/fast pipes after that
20:05:49  * loladirojoined
20:07:30  <felixge>mjr_ / piscisaureus_ : thanks for your input on this
20:08:53  * AndreasMadsenquit (Remote host closed the connection)
20:09:17  * AndreasMadsenjoined
20:16:04  * AndreasMadsenquit (Remote host closed the connection)
20:16:22  * ibcjoined
20:16:53  <indutny>mjr_: I recommend SPDY
20:17:07  <indutny>mjr_: but setup overhead is really high
20:17:14  <indutny>especially if RTT is big
20:17:24  <mjr_>indutny: yeah, I really like SPDY, but there aren't any good Android/iOS libs for it yet.
20:17:35  <indutny>mjr_: well, you know better
20:17:54  * piscisaureus_quit (Ping timeout: 246 seconds)
20:18:01  <mjr_>Is the setup overhead of SDPY higher than that of HTTPS? I thought it was just one extra round trip.
20:19:32  <ibc>hi, easy question: after I call uv_close() on a uv_tcp_t, could I be sure that I wll NEVER receive a uv_tcp_read_cb() ?
20:20:27  <ibc>(I mean, neither with nread=1 => disconnection)
20:20:34  <indutny>mjr_: well, actually no real setup overhead
20:20:40  <indutny>mjr_: it just sents data
20:20:50  <indutny>mjr_: I was talking about TLS
20:21:07  <indutny>mjr_: because it requires at least 3 ping/pongs
20:21:20  <indutny>which can be about 3 sec if RTT is ~500ms
20:21:45  <indutny>isaacs: bnoordhuis updated https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5
20:21:54  <indutny>ircretary: tell piscisaureus_ about https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5
20:21:54  <ircretary>indutny: I'll be sure to tell piscisaureus_
20:22:09  <mjr_>indutny: yeah, that's why it's such a win to multiplex data over the single TLS, because the setup over mobile networks can be really painful.
20:22:16  * piscisaureus_joined
20:23:02  <piscisaureus_>hmm. I think my udp throughput experiments just blew our office router out
20:23:32  <tjfontaine>that can easily happen
20:24:18  <mmalecki>yeah, that happened with my router once too
20:25:54  <mjr_>You can blow up a lot of NAT routers for a while by just sending UDP packets to more than 64K ports. Most handle this very badly.
20:27:58  * piscisaureus_quit (Ping timeout: 252 seconds)
20:28:41  <felixge>> piscisaureus_ left the chat room. (Ping timeout: 252 seconds)
20:28:44  <felixge>^--- lol
20:29:30  * piscisaureus_joined
20:33:54  * piscisaureus_quit (Ping timeout: 250 seconds)
20:37:48  * piscisaureus_joined
20:40:16  <indutny>piscisaureus_: heya
20:40:45  <indutny>piscisaureus_: https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5
20:45:32  <piscisaureus_>indutny: hey
20:46:00  <piscisaureus_>indutny: you didn't solve the Pipe leak :-)
20:46:19  <indutny>piscisaureus_: really?
20:46:22  <indutny>piscisaureus_: what should I do?
20:46:33  <piscisaureus_>indutny: well, when you throw, destroy all the pipes you created first
20:46:46  <piscisaureus_>indutny: or make another pass where you validate the inpurs
20:46:48  <piscisaureus_>*inputs
20:46:55  <indutny>piscisaureus_: well, I'm .close() them
20:47:04  <piscisaureus_>indutny: where?
20:47:15  <indutny>piscisaureus_: https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5#L0R736
20:47:21  <indutny>https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5#L0R712
20:47:37  <piscisaureus_>indutny: I'm looking at https://github.com/indutny/node/commit/e296ddd9b30f607914927a110521ba9bd18ccac5#L0R713
20:47:57  <indutny>and
20:47:58  <indutny>?
20:48:11  <piscisaureus_>indutny: in case of ['pipe', 'ipc', 'ipc'] the first pipe is not closed right?
20:48:19  <indutny>it should be
20:48:45  <indutny>I'm not creating second one
20:49:00  <piscisaureus_>indutny: yes, but the first *pipe*
20:49:12  <piscisaureus_>so what it will do
20:49:22  <piscisaureus_>'pipe' -> createPipe
20:49:36  <piscisaureus_>'ipc' -> ipc =createPipe(1)
20:49:47  <piscisaureus_>'ipc' -> ipc.close(); throw
20:49:54  <piscisaureus_>first pipe is leaked
20:50:30  <indutny>piscisaureus_: ah, right
20:50:32  <indutny>crap
20:50:43  <piscisaureus_>indutny: maybe just validate all the args first?
20:50:51  <indutny>piscisaureus_: ah, you're right
20:54:15  * felixgequit (Quit: http://www.debuggable.com/)
20:57:10  <indutny>piscisaureus_: https://github.com/indutny/node/commit/434b81926258c90d1714546eeb154271c44cb8fd
20:58:24  * ibcquit (Remote host closed the connection)
20:59:43  <piscisaureus_>indutny: https://github.com/indutny/node/commit/434b81926258c90d1714546eeb154271c44cb8fd#L0R764
20:59:55  <piscisaureus_>indutny: now make that clean up ipc pipes too :-)
21:00:02  <piscisaureus_>indutny: or just make it call cleanup()
21:00:04  <indutny>it cleanups
21:00:09  <indutny>crap
21:00:18  <indutny>my brain is boiling
21:01:13  <indutny>it's closing IPC
21:01:21  <indutny>because IPC is in stdio list
21:01:42  <piscisaureus_>indutny: yes but the type != 'pipe' right ?
21:01:47  <indutny>no
21:01:50  <indutny>it's == 'pipe'
21:02:03  <piscisaureus_>oh, aright
21:02:06  <piscisaureus_>*alright
21:13:27  <indutny>piscisaureus_: so does it looks good to you now?
21:14:25  <piscisaureus_>indutny: it's a big commit... but yeah, I think so
21:14:35  <piscisaureus_>indutny: does it work? :-)
21:14:42  <indutny>piscisaureus_: hahaha
21:14:43  <piscisaureus_>if it passes tests and works then lgtm
21:14:43  <indutny>piscisaureus_: indeed
21:14:55  <indutny>piscisaureus_: yes it works
21:15:01  <indutny>bnoordhuis: wanna sign off?
21:15:01  <isaacs>indutny, piscisaureus_: it'd be nice to get some tests that leverage the new functionality
21:15:07  <isaacs>but if it's backwards-compatible, that's important, too
21:15:14  <indutny>isaacs: I think TooTallNate did some work on that
21:15:27  <indutny>TooTallNate: can you please give me a link to your tests please?
21:17:48  <piscisaureus_>indutny: ok lgtm... it makes me nervous but the only way to find out is land it I guess :-)
21:17:56  <indutny>hahaha
21:18:23  <piscisaureus_>I mean, the tests pass and I couldn't find any issues
21:20:08  <indutny>piscisaureus_: if only I could get TooTallNate's tests
21:20:23  <indutny>piscisaureus_: but I added 'ipc' as fourth stdio and it has worked fine
21:20:42  <indutny>and I've also did some tests within repl
21:20:44  <piscisaureus_>indutny: cool. I'm still trying to get to work in windows
21:21:12  <piscisaureus_>indutny: it worked in an out-of-libuv but my libuv code doesn't work yet
21:21:17  <piscisaureus_>*out-of-libuv test
21:21:30  <indutny>piscisaureus_: some sort of hacks, I guess
21:21:33  <indutny>?
21:21:57  <piscisaureus_>indutny: yeah well, I have to populatre cbReserved2 and lpReserved2
21:22:14  * irajoined
21:22:14  <piscisaureus_>and come up with something that makes the crt pick up the handles without crashing
21:22:21  <indutny>:)
21:22:24  <indutny>nice
21:26:22  <TooTallNate>indutny: i did like 1 quick test
21:26:27  <TooTallNate>not very comphrehensive
21:26:32  <TooTallNate>but let me find it...
21:30:07  * theColejoined
21:38:10  <TooTallNate>indutny: here's the only one I did https://github.com/TooTallNate/node/commit/787a3de033dce1f4a7618d8ac4f02e615730796d
21:38:12  * ira_joined
21:38:15  <TooTallNate>not sure if it's even valid anymore :D
21:38:35  * ira_quit (Client Quit)
21:38:46  <TooTallNate>is uv_async_t a uv_handle ?
21:40:39  * iraquit (Quit: Leaving...)
21:41:28  * irajoined
21:41:54  * loladiroquit (Ping timeout: 246 seconds)
21:42:06  <TooTallNate>bnoordhuis: how am I supposed to uv_unref() now when working with a long-running uv_async_t?
21:42:59  * loladirojoined
21:43:26  <demarchi>bnoordhuis: any news about the call to allow mainloop integration?
21:44:14  * paddybyersquit (Quit: paddybyers)
21:45:58  * hij1nxquit (Read error: Connection reset by peer)
21:54:50  * igorzijoined
22:00:50  * c4miloquit (Remote host closed the connection)
22:01:16  <bnoordhuis>TooTallNate: you unref the handle, not the loop
22:01:22  <bnoordhuis>demarchi: no progress so far :)
22:01:54  <TooTallNate>bnoordhuis: right, was just trying to figure out if uv_async_t is a uv_handle_t instance. i now know that is is :)
22:02:02  * TheJHquit (Ping timeout: 244 seconds)
22:02:45  * piscisaureus_changed nick to piscisaureus
22:03:03  <piscisaureus>demarchi: what do you want to integrate?
22:08:05  <DrPizza>I think the obvious answer is to just get rid of nextTick() entirely.
22:08:11  <DrPizza>That way both sides will be happy
22:08:13  <DrPizza>Or unhappy.
22:08:28  <DrPizza>Either way, there will at least be no winners.
22:10:08  <piscisaureus>Either way, we have to change something
22:10:40  <piscisaureus>attaching event listeners in a nextTick is also kind of insane
22:10:52  <DrPizza>none of it makes any sense to me
22:10:57  <piscisaureus>because in other places we use nextTick to delay emitting an event
22:11:38  <piscisaureus>you know what's insane? ruby
22:11:39  <piscisaureus>https://github.com/joyent/libuv/issues/434
22:12:17  <bnoordhuis>longjmp'ing out of random code... madness
22:12:37  <DrPizza>tempted to reply with "don't use ruby"
22:13:12  <tjfontaine>ruby loves longjmp and forcing pointers to longs
22:13:28  <DrPizza>you can't bind to C libraries and then randomly respond to signals and do longjmps and expect the C library to be "oh hey, no big deal"
22:14:09  <mmalecki>well, cruby is shit anyway
22:14:22  <mmalecki>so go and use some sane implementation, like rubinius
22:18:54  * theColequit (Quit: theCole)
22:20:40  <DrPizza>oh gosh
22:20:44  <DrPizza>you commented and closed it before I did
22:20:48  <DrPizza>I should have refreshed first
22:21:53  <DrPizza>ruby is by idiots, for idiots.
22:22:20  <piscisaureus>well I don't mind people writing libuv bindings for it
22:22:50  <piscisaureus>but yeah that longjmp stuff is ... ehm no words for it
22:23:45  <demarchi>piscisaureus: libuv with ecore
22:24:14  <demarchi>piscisaureus: i had a previous hack: http://git.profusion.mobi/cgit.cgi/lucas/node/log/?h=wip
22:24:32  <DrPizza>oh there are words for it
22:24:33  <DrPizza>"moronic"
22:24:48  <demarchi>piscisaureus: although it works, it's not the desired way to do it
22:25:54  <piscisaureus>demarchi: what is "ecore" ?
22:26:07  <demarchi>piscisaureus: EFL
22:26:25  <demarchi>piscisaureus: http://enlightenment.org/
22:27:08  <piscisaureus>demarchi: does it create it's own epoll fd?
22:27:36  <piscisaureus>demarchi: I think you could use uv_poll for integrating
22:28:22  <piscisaureus>demarchi: but if EFL has it's own epoll fd you could just create an uv_poll object and if it signals, do a nonblocking sweep
22:28:42  <demarchi>piscisaureus: i'd like the other way around
22:28:57  <demarchi>putting libuv's fd inside ecore
22:29:14  * rendarquit
22:29:40  <piscisaureus>well, you can leak the fd out
22:29:53  <piscisaureus>easily, although it's not a public intterface
22:30:00  <demarchi>piscisaureus: that's the function i'm waiting for
22:30:21  <demarchi>piscisaureus: i.e. a "proper way to do it"
22:31:03  <piscisaureus>well, we're not super happy about adding a linux-specific function to it
22:31:17  <piscisaureus>but if you can convince bnoordhuis then maybe :-)
22:31:28  <demarchi>piscisaureus: we could add in a generic way, that's only implemented for linux, no?
22:31:47  <bnoordhuis>piscisaureus: the plan is to add an api for all the unices
22:32:07  <bnoordhuis>kqueue, event ports, epoll, etc. are all backed by a single fd
22:32:22  <bnoordhuis>the problem with kqueue is that you can't always embed one in another
22:32:22  <piscisaureus>I think these loop integration things have to be a little platform specific
22:32:38  <demarchi>bnoordhuis: don't forget the timeout
22:32:42  <DrPizza>this whole "I want to break up long computations into little pieces" thing strikes me as stupid
22:32:45  <DrPizza>am I being stupid here?
22:32:55  <piscisaureus>we could add uv_custom_completion_t too, so people could actually make node-serialport work on windows ;-0
22:32:58  <DrPizza>isn't "splitting up processor time between things" one of the reasons we have threads and operating systems?
22:33:05  <bnoordhuis>demarchi: i won't :)
22:33:10  <piscisaureus>DrPizza: agreed
22:33:16  * bitprobequit (Quit: Computer has gone to sleep.)
22:33:40  <demarchi>bnoordhuis: do you know when will we get this function?
22:33:54  <demarchi>bnoordhuis: i could beta test it on linux :)
22:34:20  <demarchi>bnoordhuis: and then node receives all the power of EFL :-)
22:34:22  <piscisaureus>bnoordhuis: wrt the timeout - we could just uv_get_poll_timeout
22:34:38  <demarchi>bnoordhuis: and users...
22:34:41  <piscisaureus>bnoordhuis: *export* uv_poll_timeout()
22:34:50  <bnoordhuis>demarchi: not sure. it's not much work to add it, just have to ponder the implications some more
22:34:51  <piscisaureus>that should work on all platforms
22:35:02  <bnoordhuis>piscisaureus: yes, that was kind of what i was thinking
22:35:14  <piscisaureus>For windows it would also be nice to add some more stuff
22:35:18  <piscisaureus>as said, uv_custom_completion_t
22:35:25  <piscisaureus>and uv_win_msg_t
22:35:48  <piscisaureus>I think if we do that you can integrate with chromium embedded and qt without busylooping
22:36:04  <piscisaureus>where you means "someone"
22:36:36  <bnoordhuis>that would be nice
22:36:53  <piscisaureus>the problem is, that it's hard :-)
22:37:01  <bnoordhuis>what isn't on windows?
22:37:18  <piscisaureus>bluescreening
22:37:21  <piscisaureus>just call KeBugCheck()
22:39:16  <piscisaureus>DrPizza just did his first post to nodejs-dev
22:39:22  <CIA-155>libuv: Ben Noordhuis master * r58a272e / (6 files in 2 dirs): unix: rework pending handle/req logic - http://git.io/HYVobQ
22:39:26  <DrPizza>long-time listener, first time caller!
22:40:22  <bnoordhuis>now to learn proper netiquette :)
22:40:41  <DrPizza>if it's in HTML it's because other people posted in HTML first
22:40:47  <DrPizza>ditto top-posting
22:40:57  <bnoordhuis>yeah... i've given up battling it
22:41:07  <DrPizza>My Outlook is set to use plain text by default, but if I receive HTML it'll reply in HTML
22:41:08  * travis-cijoined
22:41:08  <travis-ci>[travis-ci] joyent/libuv#337 (master - 58a272e : Ben Noordhuis): The build passed.
22:41:08  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/12ee388...58a272e
22:41:08  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1471156
22:41:08  * travis-cipart
22:48:31  <bnoordhuis>piscisaureus: how far are you with that 'all handles' queue?
22:48:51  <piscisaureus>ehm got distracted
22:48:57  <bnoordhuis>i ask because you've taken my favorite toy (active_handles) away
22:49:15  <bnoordhuis>is your work anywhere i can steal and finish it?
22:49:15  <piscisaureus>bnoordhuis: this week
22:49:49  <piscisaureus>bnoordhuis: not really unless you want to finish the new close logic for windows too
22:50:18  <piscisaureus>bnoordhuis: but in the general case I add uv__handle_register and uv__handle_unregister
22:50:21  <piscisaureus>to uv-common.h
22:50:36  <bnoordhuis>piscisaureus: hrm, okay. is the unix side of things ready? i want to debug some stuff and a handles list would help
22:50:46  <piscisaureus>no
22:50:52  <piscisaureus>didn't even start on the unix side
22:51:50  <bnoordhuis>okay, i'll start working on it
22:51:55  <piscisaureus>bnoordhuis: but if you have a single base constructor for handles this is probably trivial you can probably
22:52:01  <piscisaureus>er, this is trivial to implement
22:52:22  <piscisaureus>bnoordhuis: just make sure to not push internal handles to the list
22:52:36  <piscisaureus>bnoordhuis: I had to add uv_timer_init_internal for that
22:53:06  <piscisaureus>and I was in doublt about the poll handle that's used by cares
22:53:36  <bnoordhuis>can't you set a UV__INTERNAL flag?
22:53:47  <bnoordhuis>that way, uv_walk() can filter it out easily
22:53:58  <piscisaureus>yeah, that would also be okay
22:54:17  <piscisaureus>bnoordhuis: can we do UV__HANDLE_INTERNAL ?
22:54:21  <bnoordhuis>sure
22:54:40  <piscisaureus>bnoordhuis: let's agree on this: unix namespaces it's flag a little more
22:54:54  <piscisaureus>bnoordhuis: windows will change to UV__X instead of UV_X
22:55:30  <bnoordhuis>so that means you want UV__HANDLE_REF and UV__HANDLE_ACTIVE?
22:55:34  <piscisaureus>yes
22:56:10  <bnoordhuis>appeltjem eitje
22:56:17  <piscisaureus>bnoordhuis: also UV__HANDLE_CLOSING and UV__HANDLE_INTERNAL
22:56:27  <piscisaureus>these will be common too
22:59:52  <bnoordhuis>piscisaureus: why is UV_HANDLE_ACTIVE 0x10 and UV__ACTIVE 0x20?
23:00:20  <piscisaureus>bnoordhuis: didn't integrate semantics yet
23:00:27  <bnoordhuis>ah okay
23:00:40  <bnoordhuis>i assume that explains the difference between UV__REF too?
23:00:51  <piscisaureus>umm?
23:01:01  <piscisaureus>I think there is no UV_HANDLE_REF right>
23:01:33  <bnoordhuis>no, but UV__REF is defined both in src/uv-common.h and src/win/internal.h
23:01:55  <piscisaureus>ah, ok
23:02:04  <piscisaureus>the values should be the same :-)
23:02:38  <bnoordhuis>right, they are - it's only the ACTIVE flags that differ
23:02:41  <bnoordhuis>okay, no biggie
23:02:56  <piscisaureus>bnoordhuis: I even reserved a spot for UV_HANDLE_INTERNAL :-)
23:03:07  <loladiro>bnoordhuis: Is reading from a pipe somehow buffered on Mac OS?
23:03:44  <bnoordhuis>loladiro: pipes are always buffered (by the OS). what kind of behavior are you seeing?
23:04:31  <loladiro>I takes 45 secs for the read callback to be called after the process I spawned does the output
23:06:17  <loladiro>bnoordhuis: That is plain libuv BTW, no node.js
23:07:19  <bnoordhuis>loladiro: that shouldn't happen. can you gist your code?
23:08:04  <loladiro>I'll see if I can put together a minimal example.
23:11:09  <piscisaureus>bnoordhuis: you are aware that uv_pipe_open still doesn't set the nonblocking flag, right?
23:12:47  <piscisaureus>http://www.smore.com/clippy-js
23:18:07  <bnoordhuis>piscisaureus: https://github.com/bnoordhuis/libuv/commit/bcd06a6
23:19:01  <bnoordhuis>passes tests on unix, compiles on windows :)
23:19:20  <piscisaureus>bnoordhuis: so you now integrated UV_HANDLE_ACTIVE and UV__ACTIVE
23:19:26  <piscisaureus>bnoordhuis: you should now run the test?
23:19:26  <bnoordhuis>yes
23:19:30  <piscisaureus>s/?/!/
23:19:51  <bnoordhuis>i don't have a windows vm set up here
23:19:57  <piscisaureus>bnoordhuis: I am pretty positive that it's not going to work
23:20:10  <piscisaureus>bnoordhuis: because prepare/idle/check now do this
23:20:34  <piscisaureus>handle->flags |= UV__HANDLE_ACTIVE;
23:20:35  <piscisaureus>uv__handle_start(handle); <-- that's gonna be a no-op, always
23:21:13  <piscisaureus>bnoordhuis: same for timers
23:21:19  <bnoordhuis>so... what did that UV_HANDLE_ACTIVE flag actually do?
23:21:37  <piscisaureus>bnoordhuis: ehm, just store whether a handle was firing callbacks
23:21:54  <piscisaureus>bnoordhuis: at some point it also aliased UV_HANDLE_READING but I think I removed that in all places
23:25:05  <loladiro>bnoordhuis: I think I figured out what the problem was. I had the process handling and the io on different loops in different threads. If I dump everything on the default loop it works fine
23:26:19  <piscisaureus>bnoordhuis: hmm. You have to keep UV__HANDLE_ACTIVE and UV_HANDLE_ACTIVE separate ...
23:26:38  <piscisaureus>bnoordhuis: this won't work until I finish these fixes for UV_HANDLE_CLOSING
23:27:41  <bnoordhuis>piscisaureus: https://github.com/bnoordhuis/libuv/commit/6e79d98
23:28:04  <bnoordhuis>loladiro: right, that makes sense :)
23:28:47  <piscisaureus>bnoordhuis: lgtrm but can you add a comment to src/win/internal.h mentioning the values of UV__HANDLE_ACTIVE/REF
23:30:17  <loladiro>bnoordhuis: Can I safely put TCP I/O on a loop in a different thread?
23:30:39  <piscisaureus>you can, if you're consistent about it
23:30:43  * c4milojoined
23:30:49  <piscisaureus>you can't mix loops / threads
23:31:01  <loladiro>piscisaureus: Yes, I know.
23:31:19  <piscisaureus>but yeah, you can do tcp i/o on any thread
23:31:36  <bnoordhuis>piscisaureus: *sigh* https://github.com/bnoordhuis/libuv/commit/9d26f49
23:31:39  <loladiro>piscisaureus: I'm basically starting a worker thread for every client, and before I had the pipes on the worker thread, which didn't work
23:31:55  <piscisaureus>hmm
23:32:01  <piscisaureus>that doesn't sound very scalable :-)
23:32:09  <bnoordhuis>loladiro: why are you using threads?
23:32:13  <piscisaureus>bnoordhuis: lgtm
23:32:27  <CIA-155>libuv: Ben Noordhuis master * r9d26f49 / (4 files in 3 dirs): unix, windows: rename flags UV__ACTIVE, UV__REF - http://git.io/lxzd4A
23:33:06  <loladiro>bnoordhuis: It's a legacy app that I'm retrofitting. It basically needs a complete rewrite, but I just need to get it working for now
23:34:19  * travis-cijoined
23:34:19  <travis-ci>[travis-ci] joyent/libuv#338 (master - 9d26f49 : Ben Noordhuis): The build passed.
23:34:19  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/58a272e...9d26f49
23:34:19  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1471716
23:34:19  * travis-cipart
23:36:08  <bnoordhuis>loladiro: you can use a uv_async_t to signal the main thread from another thread
23:36:31  <bnoordhuis>but for sanity's sake, you should do all i/o operations within the same thread
23:38:34  <loladiro>bnoordhuis: Ok, you convinced me. I'm ripping the threads out. Let's hope it works
23:50:20  <bnoordhuis>why is everybody so riled up about process.nextTick?
23:51:00  <bnoordhuis>executive summary please, i don't want to read that 45 posts thread
23:52:35  <isaacs>bnoordhuis: we're going to make process.nextTick flush after every v8 invocation in v0.9
23:53:03  <isaacs>bnoordhuis: people are riled up because it's easy to have an opinion, and they're using process.nextTick for cpu-intensive stuff that should really be done in a child proc anyway.
23:53:29  <isaacs>classic bikeshed problem. don't worry about it. the net result is that we're going to do what we're going to do, because it's the right hting to do, and people will deal with it
23:53:45  <isaacs>creationix and mikeal are being nice enough to handle the fallout.