00:01:54  * mikealjoined
00:01:57  <perezd>do I need to actually free Persistent values?
00:02:04  <perezd>or are they freed automatically now
00:09:58  <piscisaureus_>perezd: you must free them
00:10:12  <perezd>piscisaureus_: how do you do that properly? just calling free?
00:11:04  <TooTallNate>handle.Dispose() and handle.Clear() do it for me
00:11:05  <TooTallNate>https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc#L163-164
00:11:13  <TooTallNate>not really sure of the differences to be honest
00:11:29  <TooTallNate>perezd: ^
00:11:43  <piscisaureus_>perezd:
00:11:43  <piscisaureus_>Persistent<Object> p = Persistent::New(o);
00:11:43  <piscisaureus_>o.Dispose()
00:12:11  <perezd>closing scope on handle clears handle objects then?
00:12:33  <piscisaureus_>perezd: closing scope disposes Local handles
00:12:39  <perezd>okay makes sense
00:14:12  <piscisaureus_>I am leaving btw.
00:14:24  <TooTallNate>piscisaureus_: have a good one
00:14:33  <piscisaureus_>thanks
00:14:40  <piscisaureus_>that'll work
00:14:55  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:15:12  * felixgequit (Quit: felixge)
00:17:45  * orlandovftwquit (Ping timeout: 244 seconds)
00:27:12  * bnoordhuisjoined
00:45:15  * c4miloquit (Ping timeout: 250 seconds)
00:50:44  <bnoordhuis>TooTallNate: ping
00:50:51  <tjfontaine>utoh
00:50:53  <TooTallNate>bnoordhuis: pong
00:50:56  <bnoordhuis>hey
00:51:08  <bnoordhuis>https://github.com/joyent/node/issues/3148 <- what's your opinion on that?
00:51:27  <bnoordhuis>it's not quite a bug, just something that most people won't expect
00:51:37  <bnoordhuis>actually... there is a bug but it's not what the reporter thinks :)
00:51:57  <bnoordhuis>the isIP() function doesn't allow dotted hex notation
00:51:58  <TooTallNate>bnoordhuis: you mean radix 10 is what most people would expect?
00:52:05  <TooTallNate>i would agree :p
00:52:18  <bnoordhuis>yes. otoh, it's all according to spec...
00:52:39  <TooTallNate>in the past (url.parse()) we've fallen back on what web browsers do
00:53:04  <bnoordhuis>true. and web browsers support all kinds of funky notation
00:53:10  <tjfontaine>btw, isIP('') doesn't exactly perform the way I would expect :)
00:53:13  <isaacs>ipv6 is so terrible
00:54:27  <TooTallNate>bnoordhuis: `ping` for example allows octets
00:54:38  * mikealquit (Quit: Leaving.)
00:54:47  <TooTallNate>(darwin ping at least)
00:54:50  <bnoordhuis>TooTallNate: yes. it's a function of inet_ntop()
00:55:23  <TooTallNate>bnoordhuis: if you want a personal opinion i'd say use radix 10 there
00:55:57  <TooTallNate>i don't know of anybody who'se ever cared about 0x8.0x8.0x8.0x8 :p
00:56:08  * isaacsquit (Remote host closed the connection)
00:56:16  <bnoordhuis>there are a lot of noisy, drunk people in front of my house...
00:56:20  * bnoordhuisgets the bb gun
00:56:37  * dapquit (Quit: Leaving.)
00:57:00  <bnoordhuis>i think they're idling in #libuv because the moment i said that, they moved on
00:57:12  <bnoordhuis>TooTallNate: yeah, i think i agree
00:57:40  <tjfontaine>hah
01:00:48  * mikealjoined
01:10:21  * c4milojoined
01:10:54  <TooTallNate>bnoordhuis: do you know what the actual problem that guy is reporting is?
01:11:14  <TooTallNate>it made sense to be a parseInt error, but apparently its something else
01:11:50  <bnoordhuis>TooTallNate: isIP() accepts the address because it's numeric, tcp_wrap.cc then parses the 025 as 21 decimal
01:12:07  <bnoordhuis>so his script is not connecting to the address he thinks it is
01:13:02  <TooTallNate>bnoordhuis: what does the ip parsing in c-land?
01:13:12  <bnoordhuis>TooTallNate: inet_ntop()
01:13:29  * seebeespart
01:13:38  <TooTallNate>oh i see
01:35:21  * isaacsjoined
01:39:30  * isaacsquit (Remote host closed the connection)
01:40:25  <mjr_>bnoordhuis: we are running your slab allocator branch on one machine. So far so good.
01:41:03  <bnoordhuis>mjr_: no more zero reads? do you know if it's faster?
01:41:40  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
01:43:29  * brsonquit (Quit: leaving)
01:44:03  <mjr_>no more 0 reads, but I can't tell if it's faster.
01:44:11  <mjr_>It seems perhaps no faster, although I'm really surprised by that
01:44:31  * abraxasjoined
01:44:53  <mjr_>The flame graph looks way better though, like most of the time is spent in my code now.
01:45:18  <mjr_>But I was expecting drastically less CPU time to be consumed, and I don't see that, so a mystery still exists.
01:45:30  <bnoordhuis>mjr_: okay, good. :-) re: faster: i'm having a hard time outcompeting libc
01:45:39  <bnoordhuis>memory usage / fragmentation should be more stable though
01:46:25  <mjr_>back in a while
01:46:27  * mjr_quit (Quit: mjr_)
01:47:05  * ericktquit (Ping timeout: 252 seconds)
01:50:19  * irajoined
01:57:11  * mikealquit (Quit: Leaving.)
02:14:22  * perezdquit (Quit: perezd)
03:13:28  * bnoordhuisquit (Ping timeout: 248 seconds)
03:15:00  * c4miloquit (Ping timeout: 260 seconds)
03:55:29  * perezdjoined
03:56:20  * mjr_joined
04:18:30  * iraquit (Quit: Leaving...)
04:48:41  * bulatshakirzyanojoined
04:48:58  * bulatshakirzyanochanged nick to avalanche123|h
05:08:04  * c4milojoined
05:24:55  * perezdquit (Quit: perezd)
05:44:52  * ericktjoined
05:51:00  * paddybyersjoined
06:02:11  * mikealjoined
06:18:18  * ericktquit (Quit: erickt)
06:20:38  * AvianFluquit (Ping timeout: 250 seconds)
06:56:40  * c4miloquit (Ping timeout: 265 seconds)
07:11:49  * rendarjoined
07:16:40  * paddybyersquit (Quit: paddybyers)
07:18:32  * AvianFlujoined
07:50:39  <mmalecki[ft]>wtf https://twitter.com/#!/nodeconf/status/195627209082413056
07:54:44  <mmalecki[ft]>(no, really. someone knows what's going on?)
07:55:03  * paddybyersjoined
08:15:20  * orlandovftwjoined
09:23:46  * benviejoined
10:24:58  * bnoordhuisjoined
11:20:13  * orlandovftwquit (Quit: leaving)
12:00:11  * abraxasquit (Remote host closed the connection)
12:00:42  * abraxasjoined
12:05:13  * abraxasquit (Ping timeout: 240 seconds)
12:44:22  * theColejoined
12:49:48  * c4milojoined
12:57:31  * paddybyerspart
13:29:06  * irajoined
13:32:53  * theColequit (Quit: theCole)
13:35:09  <mmalecki[ft]>bnoordhuis: hey
13:35:44  <mmalecki[ft]>bnoordhuis: maybe you know what's going on? https://twitter.com/nodeconf/status/195627209082413056
13:38:49  <mmalecki[ft]>bnoordhuis: also, does util.inspect need backward compatibility
13:38:51  <mmalecki[ft]>?
13:41:28  <mmalecki[ft]>oh... it's "locked"
13:41:40  <mmalecki[ft]>shitty API is a serious bug, actually
13:50:07  <bnoordhuis>mmalecki[ft]: ho
13:51:00  <bnoordhuis>re that twitter message, there'll be awards at nodeconf
13:51:14  <bnoordhuis>exterminator is one of the categories
13:54:12  <mmalecki[ft]>ok, so I guess I should buy a ticket :)
13:56:08  * paddybyersjoined
13:59:46  * piscisaureus_joined
14:08:03  <piscisaureus_>creationix: bnoordhuis: I need your opinion.
14:08:14  <creationix>piscisaureus_, what's up
14:08:23  <piscisaureus_>creationix: bnoordhuis: if people try to do setsid/setuid on windows, should we throw an error, of fail silently?
14:08:45  <bnoordhuis>piscisaureus_: explicit > implicit
14:08:52  <creationix>probably throw error since they most likely do this for security reasons
14:08:58  <piscisaureus_>yeah, ok
14:09:00  <creationix>silent security holes are very bad
14:09:03  <piscisaureus_>I agree
14:11:42  <creationix>mikeal, Nodie nominations were community provided or did you propose them?
14:11:48  <creationix>great idea btw
14:13:44  * isaacsjoined
14:15:45  <creationix>morning isaacs :)
14:25:36  <isaacs>g'mroning
14:30:01  <piscisaureus_>I don't really think anyone other than bnoordhuis really qualifies for the exterminator award
14:30:38  <piscisaureus_>(not to disregard tootallnate or indutny of course)
14:31:05  <mmalecki[ft]>is it for the node core or whole community?
14:31:22  <piscisaureus_>that's also an interesting question of course
14:31:29  <mmalecki[ft]>because if it's for the core, I'm very surprised
14:32:02  <isaacs>mmalecki[ft]: it's gotta be for the whole community
14:32:18  <isaacs>also, how can nodejitsu (the company) be up for an award...
14:32:26  <isaacs>should be a diff category or something
14:32:47  <isaacs>though, the fact that it takes a whole company to rival marco or me is pretty badass, i must say ;)
14:33:20  <mmalecki[ft]>isaacs: I mean, the company thing is kinda sane for me
14:33:20  <isaacs>piscisaureus_: so, uid/gid in spawn for 0.6.
14:33:51  <isaacs>mmalecki[ft]: should've been something like, "company that uses node the awesomest" or something, and have nodejitsu, voxer, and joyent there or somethign
14:33:59  <isaacs>maybe msft or others
14:34:05  <isaacs>cloud9
14:34:06  <isaacs>et.
14:34:22  <isaacs>piscisaureus_: you'd said we could do a spawn2 for 0.6?
14:34:39  <piscisaureus_>isaacs: I am already working on it.
14:34:48  <bnoordhuis>https://github.com/bnoordhuis/node/compare/issue3180 <- handle walker (more or less). opinions?
14:35:09  <isaacs>piscisaureus_: oh, awesome :)
14:35:19  <bnoordhuis>adds a process._getActiveHandles() function that returns an array of (surprise surprise) active handles
14:36:09  <mmalecki[ft]>isaacs: can't a company do community service?
14:36:11  <piscisaureus_>bnoordhuis: need timers and child processes too
14:36:14  <bnoordhuis>it's not complete btw (missing child_process) for example
14:36:22  <bnoordhuis>piscisaureus_: hah, right
14:36:23  <isaacs>bnoordhuis: we need to call out igor's queue in the license, i think
14:36:34  <bnoordhuis>isaacs: sure
14:36:35  <piscisaureus_>yes, but that's fine
14:37:42  <isaacs>bnoordhuis: also, this is only for handles, yes? do you think it's worthwhile to have req's exposed in this way as well?
14:38:14  <isaacs>ie, fs.open('file that the os decides should take 3 hours to open', function () { why isn't my program exiting? })
14:38:48  <bnoordhuis>isaacs: yeah, i suppose that could happen. it's trivial to add
14:39:16  <bnoordhuis>how do people feel about the general approach?
14:39:22  <isaacs>i think it's nice. very simple.
14:39:32  <tjfontaine>+1
14:40:50  <bnoordhuis>cool. piscisaureus_?
14:40:59  <isaacs>igor's code is always so beautiful.
14:41:08  <isaacs>we should just port nginx as a module.
14:41:10  <isaacs>;P
14:41:31  <piscisaureus_>bnoordhuis: +1
14:41:32  <isaacs>not for any purpose, i mean, we already have good http and stuff. just to look at it.
14:41:39  <piscisaureus_>not sure about reqs tho - but whatever
14:42:10  <isaacs>piscisaureus_: it gets important if you end up in pathological situations where you're writing to a fs.writeStream, and not listening to the return to do backpressure.
14:42:20  <piscisaureus_>isaacs: yeah, ok
14:42:25  <isaacs>piscisaureus_: then you have lots of writes backed up, and when you think you should exit, it takes a second or more.
14:42:33  <piscisaureus_>if it's not too costly
14:42:35  <isaacs>which isn't a big deal, unless you're expecting to restart a server or something very soon.
14:42:47  <bnoordhuis>two pointers, 16 bytes on x64
14:42:49  <isaacs>but yeah, reqs are less important.
14:44:48  <isaacs>piscisaureus_: what do you think of the uid/gid patch on master?
14:44:53  <isaacs>piscisaureus_: shall i squash and push?
14:45:09  <isaacs>piscisaureus_: or are you doing stuff with it on v0.6 and gonna merge in?
14:45:29  <piscisaureus_>isaacs: I think I prefer to merge from 0.6
14:45:35  <piscisaureus_>isaacs: also, I like it to be flags
14:46:18  <piscisaureus_>isaacs: just hold on a sec...
14:46:45  <isaacs>piscisaureus_: kewl
14:59:24  <CIA-155>node: isaacs v0.6 * r76de7c0 / (doc/index.html doc/pipe.css): Add customary 'fork me on github' banner to website - http://git.io/iDHNIw
15:02:47  <piscisaureus_>can we somehow test uid/gid ?
15:04:50  <bnoordhuis>piscisaureus_: not really
15:05:05  <isaacs>piscisaureus_: only as root
15:05:20  <piscisaureus_>isaacs: maywe we can assert that at least something is attempted
15:05:25  <isaacs>piscisaureus_: you can test that it'll throw if you're not root :)
15:05:26  <piscisaureus_>isaacs: I think that'll work in node
15:05:49  <piscisaureus_>isaacs: making it throw is not easy
15:06:04  <piscisaureus_>isaacs: I'd like to do that at some point - but at the moment we write errors to stderr
15:06:11  <piscisaureus_>isaacs: except on windows btw
15:06:16  <isaacs>piscisaureus_: well, the setuid should return non-zero if you're not root
15:06:26  <piscisaureus_>isaacs: I know, but this happens in the forked process
15:06:30  <isaacs>right
15:06:31  <bnoordhuis>piscisaureus_: you could test setuid(getuid()) but that's kind of pointless
15:06:41  <isaacs>but then the forked process returns -127
15:06:45  <piscisaureus_>true
15:06:46  <tjfontaine>root or CAP_SETUID on linux
15:06:51  <piscisaureus_>and you have no clue why
15:06:52  <isaacs>piscisaureus_: so, it's easy to test in node
15:06:55  <piscisaureus_>isaacs: this is fixable
15:07:14  <piscisaureus_>but it's out of scope for this quick setuid/setgid fix
15:07:25  <piscisaureus_>bnoordhuis:
15:07:27  <isaacs>piscisaureus_: we could make it exit with different error codes for each failure, but i thought -127 is sort of a customary exit for "the child process failed to run properly"
15:07:37  <tjfontaine>it should return EPERM isn't that mapped?
15:07:40  <piscisaureus_>isaacs: well, we can just make the main process wait for the fork
15:07:49  <bnoordhuis>EPERM is mapped
15:07:59  <piscisaureus_>isaacs: actually we already do I think - there just needs to be some plumbing to report what actually went wrong
15:08:05  <isaacs>tjfontaine: the child proc gets an EPERM from setgid/setuid, but the parent just gets -127 from the fork()
15:08:19  <tjfontaine>oh of course
15:08:41  <isaacs>piscisaureus_: we expose the process exit code if it actually was run, but chdir/setuid/setgid/env etc all return -127 when they fail
15:08:52  <piscisaureus_>bnoordhuis:
15:08:52  <piscisaureus_>uv.a(core.o): In function `uv_close':
15:08:52  <piscisaureus_>/home/bert/libuv/src/unix/core.c:66: multiple definition of `uv_close'
15:08:52  <piscisaureus_>uv.a(uv-unix.o):/home/bert/libuv/uv-unix.c:129: first defined here
15:08:56  <piscisaureus_>bnoordhuis: huh
15:09:12  <isaacs>i mean, i'm not strongly in favor of keeping that, necessarily
15:09:28  <bnoordhuis>piscisaureus_: how/where/what?
15:09:29  <isaacs>it's just the way it's alwasy been in node
15:09:42  <piscisaureus_>bnoordhuis: build the 0.6 branch of libuv on linux
15:09:55  <piscisaureus_>isaacs: yeah. Can't we change that
15:10:02  <piscisaureus_>isaacs: I don't like it
15:10:25  <piscisaureus_>isaacs: we can also make it fail loudly when you try to spawn an nonexisting binary (e.g. execve fails)
15:10:28  <bnoordhuis>piscisaureus_: wfm
15:10:42  <piscisaureus_>isaacs: I think that the return -127 was just a stopgap solution
15:11:02  <bnoordhuis>piscisaureus_: btw, libuv/uv-unix.c?
15:11:18  <bnoordhuis>i think you should do a `git clean -dfx` :)
15:11:29  <piscisaureus_>bnoordhuis: weird
15:11:39  <piscisaureus_>bnoordhuis: this is a fresh vm and a fresh checkout :-)
15:11:58  <bnoordhuis>weird indeed. uv-unix.c is ancient history
15:12:39  <isaacs>piscisaureus_: can we just pick other codes to use?
15:12:50  <isaacs>piscisaureus_: i mean, somethign that isn't already mapped to something else
15:13:12  <piscisaureus_>isaacs: I don't understand your question
15:13:40  <isaacs>i mean, instead of failing with -127 on all of them, fail with -127 on one, -128 on another, etc.
15:14:12  <piscisaureus_>isaacs: well what we could do is slightly more complex
15:14:13  <isaacs>the tricky thing will be if there's some system where like ECONNABORTED is -129, then you'll get really confused about what kinds of connections your child proc was trying to make :)
15:14:36  <piscisaureus_>isaacs: well the exit status of a process != an errno
15:14:45  <piscisaureus_>isaacs: it is just the number that the process wishes to return
15:14:51  <isaacs>yeah
15:15:02  <isaacs>so the proc could lie about it anyway
15:15:12  <piscisaureus_>isaacs: so what we can do is create a pipe, set one end to CLOEXEC and try to spawn
15:15:20  <piscisaureus_>if an error happens we write it to the pipe
15:15:30  <piscisaureus_>isaacs: so the master process reads the pipe
15:15:42  <piscisaureus_>isaacs: if nothing appears on it, the spawn worked
15:15:56  <piscisaureus_>isaacs: if something does appear, that was the error
15:15:58  <piscisaureus_>easy
15:16:18  <piscisaureus_>(actually both ends should be cloexec)
15:16:26  * ericktjoined
15:16:52  <isaacs>k
15:17:05  <piscisaureus_>but nevermind - focus
15:17:07  <isaacs>yes.
15:17:12  <isaacs>i wanna drop v0.6.16 today
15:17:21  <piscisaureus_>isaacs: almost there
15:17:24  <piscisaureus_>bnoordhuis:
15:17:25  <isaacs>awesome :)
15:17:26  <piscisaureus_>test/test-get-memory.c:29:3: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘uint64_t’ [-Wformat]
15:17:27  <piscisaureus_>test/test-get-memory.c:29:3: warning: format ‘%llu’ expects argument of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’ [-Wformat]
15:17:33  <piscisaureus_>^-- this keeps popping up tho
15:20:01  <bnoordhuis>yeah... printing large integers is one of the bigger fails in the c spec
15:20:24  <bnoordhuis>biab, dinner
15:24:27  * AndreasMadsenjoined
15:25:59  * creationixquit (Quit: ZNC - http://znc.in)
15:41:13  <piscisaureus_>[% 100|+ 106|- 12]: Done.
15:41:14  <piscisaureus_>make: *** [test] Error 12
15:41:18  <piscisaureus_>meh, libuv on unix
15:41:21  <piscisaureus_>(v0.6)
15:43:33  * avalanche123|hquit (Ping timeout: 245 seconds)
15:45:11  <CIA-155>libuv: Bert Belder reviewme * rc42ba10 / (6 files in 5 dirs): Temporary API to support spawn with uid and gid options (+7 more commits...) - http://git.io/AkOFIQ
15:45:16  <piscisaureus_>^-- isaacs : review?
15:46:07  <piscisaureus_>isaacs: btw - if you add a test to libuv you have to add it to test-list.h
15:46:12  <piscisaureus_>or it will never be executed
15:47:03  * travis-cijoined
15:47:04  <travis-ci>[travis-ci] joyent/libuv#225 (reviewme - c42ba10 : Bert Belder): The build is still failing.
15:47:04  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f9fcaf5...c42ba10
15:47:04  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1191357
15:47:04  * travis-cipart
15:47:31  * theColejoined
15:48:05  <isaacs>piscisaureus_: good to know. i was wondering why it was passing when i wasn't root ;)
15:48:37  <piscisaureus_>isaacs: you can run an individual test with "run-tests <test-name>"
15:48:45  <piscisaureus_>isaacs: if the test isn't registered it wil tell you
15:50:11  <piscisaureus_>isaacs: I also think that #ifdef setuid doesn't work
15:50:18  <piscisaureus_>isaacs: because that's not a preprocessor symbol
15:52:53  <isaacs>k
15:53:47  <isaacs>i like the flags approach. lgtm.
16:02:44  * theCole_joined
16:04:47  * theColequit (Ping timeout: 246 seconds)
16:05:59  * mikealquit (Quit: Leaving.)
16:24:00  <CIA-155>libuv: Bert Belder reviewme * r56c6793 / (src/unix/process.c test/test-list.h test/test-spawn.c): Test for setuid/setgid - http://git.io/afVm-w
16:24:50  * travis-cijoined
16:24:50  <travis-ci>[travis-ci] joyent/libuv#226 (reviewme - 56c6793 : Bert Belder): The build is still failing.
16:24:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c42ba10...56c6793
16:24:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1191744
16:24:50  * travis-cipart
16:25:46  * orlandovftwjoined
16:30:45  <isaacs>piscisaureus_: https://github.com/joyent/libuv/commit/56c6793d19128d0cdaf50b5081c04a769e32afc5#L0R287
16:30:49  <isaacs>piscisaureus_: shouldn't it be checking the flags?
16:31:23  <piscisaureus_>isaacs: oh that's a rogue commit
16:31:33  <isaacs>pesky rogues.
16:31:36  <piscisaureus_>isaacs: nvm - I will ask for review when it works
16:31:37  <isaacs>always stealin my coppers.
16:31:54  <piscisaureus_>isaacs: I landed your commit to grab the test.
16:31:59  <isaacs>ah, kewl
16:32:00  <piscisaureus_>isaacs: forgot to undo the changes to process.c
16:32:14  <piscisaureus_>isaacs: btw - the test didn't even compile :p
16:32:35  <isaacs>really?
16:32:44  <isaacs>oh, probably because i ifdef'd it out :)
16:32:46  <piscisaureus_>isaacs: you did this
16:32:50  <piscisaureus_>yes
16:32:51  <piscisaureus_>also
16:33:07  <piscisaureus_>struct passwd *pwd;
16:33:07  <piscisaureus_>x = pwd.uid
16:33:11  <piscisaureus_>the dot has to be a ->
16:35:25  <isaacs>right
16:35:43  <isaacs>well, the patch got you to do it better, so it had the intended effect, i guess :)
16:38:44  * mmalecki[ft]changed nick to mmalecki
16:41:55  <CIA-155>libuv: Bert Belder reviewme * r8106ff4 / (test/test-list.h test/test-spawn.c): Test for setuid/setgid - http://git.io/lCehrg
16:44:36  <piscisaureus_>^-- isaacs: updated. Passes on linux and windows
16:44:48  <piscisaureus_>can you try on macos?
16:45:08  * travis-cijoined
16:45:09  <travis-ci>[travis-ci] joyent/libuv#227 (reviewme - 8106ff4 : Bert Belder): The build is still failing.
16:45:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/56c6793...8106ff4
16:45:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1191893
16:45:09  * travis-cipart
16:46:58  <isaacs>piscisaureus_: testing
16:47:37  <piscisaureus_>isaacs: btw - try to run the tests with sudo
16:47:48  <piscisaureus_>otherwise the setuid test will be skipped
16:47:51  <isaacs>yeah, i saw that
16:47:56  * benviequit
16:47:56  <piscisaureus_>it seems nice to actually run it at least once ;-)
16:47:59  <isaacs>i'm testing as user first, to make sure it didn't break anything else
16:48:09  <isaacs>or at least, nothing that wasn't already broken
16:49:44  <isaacs>fs_chown should check for root-ness
16:50:09  <isaacs>[% 0|+ 88|- 14]: fs_chown
16:50:09  <isaacs>`fs_chown` failed: exit code 6
16:50:09  <isaacs>Output from process `fs_chown`:
16:50:10  <isaacs>Assertion failed in test/test-fs.c on line 194: req->result == -1
16:50:12  <isaacs>as root
16:50:19  <isaacs>also:
16:50:21  <isaacs>[% 0|+ 77|- 12]: spawn_setuid_fails
16:50:21  <isaacs>`spawn_setuid_fails` failed: exit code 6
16:50:21  <isaacs>Output from process `spawn_setuid_fails`:
16:50:23  <isaacs>exit_cb
16:50:25  <isaacs>Assertion failed in test/test-spawn.c on line 63: exit_status == 127
16:50:27  <isaacs>=============================================================
16:50:29  <isaacs>[% 0|+ 77|- 13]: spawn_setgid_fails
16:50:31  <isaacs>`spawn_setgid_fails` failed: exit code 6
16:50:33  <isaacs>Output from process `spawn_setgid_fails`:
16:50:35  <isaacs>exit_cb
16:50:37  <isaacs>Assertion failed in test/test-spawn.c on line 63: exit_status == 127
16:50:39  <isaacs>=============================================================
16:50:41  <isaacs>which actually looks expected? since it ought to work, so the failure test fails?
16:50:58  <piscisaureus_>isaacs: no
16:51:08  <piscisaureus_>isaacs: it tries to setsid(-42424242)
16:51:12  <piscisaureus_>er, setgid
16:51:18  <isaacs>hm. right
16:51:20  <piscisaureus_>isaacs: so apparently that works, on mac?
16:51:27  <isaacs>i.. guess so?
16:51:39  <isaacs>or it's skipping it or something
16:51:49  <piscisaureus_>yeah that could also be the case
16:51:50  <isaacs>but it does indeed fail properly as non-root
16:52:45  <piscisaureus_>isaacs: can you try to fix it? I have no mac os on this box ...
16:53:08  <piscisaureus_>isaacs: maybe detect root and setsid to nobody before attempting spawn
16:53:11  <piscisaureus_>then it should fail :-)
16:54:06  <isaacs>https://gist.github.com/2510764
16:54:27  <isaacs>yep.
16:54:30  <isaacs>os x allows this.
16:54:32  <isaacs>i guess.
16:54:35  <piscisaureus_>omfg
16:56:12  <isaacs>that's not what the man page says it does, though
16:56:17  <isaacs>also:
16:56:18  <isaacs>$ id -- -424242
16:56:18  <isaacs>id: -424242: no such user
16:56:30  <isaacs>so, id is getting an enoent there
16:56:33  <tjfontaine>there's another 42 there I think
16:56:43  <tjfontaine>but smae result either way
16:56:54  <isaacs>tjfontaine: yeah
16:57:42  <ggreer>does ps show that it's running as user... whatever?
16:58:00  <tjfontaine>ya that's what I was going to ask, bsd may allow you to make users on the fly
16:58:17  <isaacs>getuid shows -424242 as the uid
16:58:24  <piscisaureus_>hehe
16:58:40  <piscisaureus_>isaacs: according to the bsd man pages setuid can only fail with EPERM if you are not root
16:58:48  <piscisaureus_>so I think it follows the spec
16:59:22  <tjfontaine>einval doesn't necessarily imply undefined user I guess
16:59:46  <piscisaureus_>isaacs: ok. just reset to nobody if the user is root, before trying spawn
17:00:20  <isaacs>hm
17:00:23  <isaacs>it says that it'll fail with einval
17:00:25  <isaacs> [EINVAL] The value of the {group,user} ID argument is invalid and is not supported by the implementation.
17:00:53  * mikealjoined
17:01:21  <piscisaureus_>isaacs: ah, right, I was looking at setgid
17:02:02  <piscisaureus_>isaacs: http://www.unix.com/man-page/FreeBSD/2/setuid/
17:02:26  <isaacs>piscisaureus_: darwin !== freebsd
17:02:43  <tjfontaine>ps aux | grep a.out
17:02:44  <tjfontaine>4252543054 13739 96.6 0.0 2426592 364 s005 R+ 1:01PM 0:06.84 ./a.out
17:02:58  <tjfontaine>well that uid is certainly not root
17:04:52  <isaacs>piscisaureus_: (the second = is relevant there. it is == freebsd.)
17:05:57  <piscisaureus_>isaacs: ok so what should I do, or are you going to do a patch
17:06:26  <mmalecki>isaacs: detached spawn thing will go into 0.8, right?
17:06:54  <isaacs>piscisaureus_: so, i think maybe the right thing to do here is just be ok with the fact that os x lets you setuid to random uids that don't exist on the system.
17:07:09  <isaacs>piscisaureus_: and skip that test if uid == 0 && DARWIN or something
17:07:46  <tjfontaine>well I think we want to check getcap on linux
17:08:33  <isaacs>smartos is the same as linux
17:08:37  <isaacs>in this case
17:08:43  <isaacs>so darwin's the only odd duck
17:09:04  <isaacs>and probably freebsd, i'd guess, though we don't officially support it anyway, i don't think
17:12:47  <isaacs>piscisaureus_: does that sound reasonable?
17:12:49  <AndreasMadsen>mmalecki: I just asked AvianFlu today, he says it will land in 0.8 but not before the stdio refactor has been made.
17:13:15  <AvianFlu>I, of course, am a lesser authority on such things than those to which the question was addressed
17:14:19  <AndreasMadsen>AvianFlu: of course, but isaacs is a busy man
17:14:33  <isaacs>detached processes would be nice, yes
17:14:39  <isaacs>BY THE WAY!
17:14:43  <isaacs>FC is slipping about a week.
17:14:49  <AvianFlu>FC?
17:14:49  <isaacs>so we're not quite out of time yet :)
17:14:54  <isaacs>feature cutoff
17:14:58  <AvianFlu>oh, gotcha
17:14:59  <isaacs>feature complete
17:15:08  <AvianFlu>so many acronyms, so little time
17:15:31  <isaacs>i've been hesitant to announce a release date until we can declare feature complete.
17:15:35  <AvianFlu>it's been a busy few weeks for me, isaacs, but I'm definitely down to help out with the stdio refactor still, if help is needed
17:15:38  <isaacs>as it stands, there's still stuff to get done.
17:15:41  <AvianFlu>isaacs, seems prudent
17:15:51  <isaacs>but, my goal is to get v0.8.0 out June 1
17:16:03  <isaacs>maybe a few weeklies before NodeConf
17:16:23  <mmalecki>isaacs: util.inspect with options object instead of 4 params, how does it sound?
17:17:03  <isaacs>mmalecki: v0.9
17:17:22  <isaacs>mmalecki: all this "We need to clean up the API and change some shit to be nicer and prettier and more organized" = v0.9
17:17:35  <mmalecki>isaacs: ok, I'll just open a pull request
17:17:37  <isaacs>mmalecki: the focus will be API sanity there.
17:18:10  <isaacs>mmalecki: btw, i'm not saying "yes, that will go in v0.9". i'm saying, "we should discuss that once we get v0.8 out, and fork 0.9, because that's where it would go, if we do it"
17:18:31  <piscisaureus_>hi jan here, i'm taking over from bert.
17:18:40  <piscisaureus_>do we have an async printf in libuv?
17:18:44  <piscisaureus_>cause it might block
17:20:31  * TooTallNatejoined
17:20:32  <AndreasMadsen>isaacs: will process.send be async in node 0.8?
17:20:55  <isaacs>AndreasMadsen: is it now?
17:20:58  <isaacs>(in master)
17:21:50  <AndreasMadsen>isaacs: old issue, I havn't checked recently: https://github.com/joyent/node/issues/2598
17:23:07  <AndreasMadsen>isaacs: nop, still fails
17:23:39  <igorzi>piscisaureus_: hey
17:24:59  <igorzi>piscisaureus_: when you do console.log('bla'); and then process.exit().. and node's stdout is a pipe.. there's a race and stdout doesn't always get written
17:25:23  <igorzi>piscisaureus_: because we write to the pipe on a threadpool
17:26:13  * orlandovftwquit (Ping timeout: 260 seconds)
17:26:23  <AndreasMadsen>isaacs: UDP using process.send would also be nice, since it would allow UDP support in cluster.
17:26:54  <isaacs>AndreasMadsen: yeah, it'd be nice, but not for v0.8
17:27:11  <isaacs>AndreasMadsen: and, unless it's easy (which it might be after stdio refactoring), send is going to stay sync, probably, as well.
17:27:44  <isaacs>AndreasMadsen: it's painful sometimes, but you have to draw a line at some point, or else it'll never goout.
17:27:47  <isaacs>*never go out
17:28:25  <AndreasMadsen>isaacs: true, ben was just assigned to the UDP support, so I assumed it would be in node 0.8.
17:28:43  <AndreasMadsen>^ https://github.com/joyent/node/issues/2194
17:29:14  <isaacs>AndreasMadsen: https://github.com/joyent/node/issues?milestone=10&state=open
17:29:19  <isaacs>AndreasMadsen: that's v0.8 remaining issues
17:30:37  <AndreasMadsen>isaacs: thanks. I hope the improved process.send will be on that list too. (https://github.com/joyent/node/pull/2772)
17:31:05  <bnoordhuis>AndreasMadsen: i believe the blocker for #2194 is that it's not so easy to implement on windows
17:31:24  <bnoordhuis>it would require a fair amount of rework in libuv at any rate
17:32:04  <isaacs>AndreasMadsen: oh, whoops, there's a comment from me from 12 days ago saying i'd review it tomorrow.
17:32:09  * isaacsoff to review it now...
17:32:29  <AndreasMadsen>bnoordhuis: I can perfectly live without it, but the amount of mails I get about that makes me sad :(
17:33:39  <AndreasMadsen>isaacs: I'm only so big a pain because I know appreciate it.
17:35:00  * mikealquit (Quit: Leaving.)
17:37:10  * benviejoined
17:37:20  <isaacs>AndreasMadsen: tell them that i said we can't have async process.send until it makes bnoordhuis happy.
17:37:35  * brsonjoined
17:38:47  <AndreasMadsen>isaacs: process.send is only killing me, it is the UDP support there is the reason behind so many mails.
17:38:58  <isaacs>AndreasMadsen: same answer :)
17:39:09  <isaacs>AndreasMadsen: not until it makes bnoordhuis happy
17:39:21  <AndreasMadsen>:D
17:39:40  <bnoordhuis>i can be bribed with beer
17:40:17  <isaacs>I didn't say drunk. I said happy.
17:40:33  <AndreasMadsen>bnoordhuis: any paypal account I can link to?
17:40:36  <isaacs>If all people had to do was get you drunk to get features into node, it'd be php i no time.
17:42:25  <isaacs>AndreasMadsen: there's a "useing" in there. should be "using"
17:42:36  * dapjoined
17:43:07  * mikealjoined
17:43:09  <piscisaureus_>igorzi: hey
17:43:26  <piscisaureus_>igorzi: we just figured out that a pipe stdout on unix is also blocking
17:43:33  <piscisaureus_>igorzi: yeah, there's an issue here
17:43:54  * AndreasMadseneating
17:44:05  <piscisaureus_>igorzi: the problem is that if node spawns node and there's a pipe in between, you want stdout to be async
17:44:31  <piscisaureus_>because when node pauses the child_process' stdout then the child process might block indefinitely at process.stdout.write
17:44:42  <piscisaureus_>igorzi: so if you have a great idea what to do here, please tell me :-)
17:44:50  <piscisaureus_>igorzi: btw, you are experiencing this issue?
17:46:47  * mikealquit (Client Quit)
17:52:04  <piscisaureus_>isaacs: is the option called `sid` or `setsid` in nide?
17:52:05  <piscisaureus_>*node
17:52:11  <piscisaureus_>I could not find it
17:52:36  <isaacs>uid
17:52:47  <isaacs>uid is an int that sets the uid
17:52:58  <isaacs>setsid is/was a boolean that tells it to set a new session id
17:53:08  <piscisaureus_>isaacs: we want that back as well?
17:53:23  <isaacs>piscisaureus_: sure
17:53:26  <piscisaureus_>isaacs: I think I am leaving it out... it should be put back in 0.8 as part of the daemonization stuff
17:53:38  <isaacs>oh, yeah, for 0.6, no
17:53:46  <isaacs>for 0.8 it should be back if it's not too hard
17:53:50  <AvianFlu>it was a dummy option in 0.6 (setsid)
17:56:03  <isaacs>AvianFlu: yeah, it didn't actually do anything.
17:56:08  <isaacs>i thought it did in 0.4
17:56:26  <AvianFlu>it did in 0.4
17:56:40  <AvianFlu>but in 0.6, it wasn't in libuv, and the option only existed in js
17:56:54  <AvianFlu>vestigial would be a good word for it
17:57:28  <AvianFlu>setsid() is needed for the unix end of the daemonization stuff, but I'd be more in favor of a less-unixy name for the option (like detached)
17:58:02  <piscisaureus_>yeah
17:58:04  <piscisaureus_>later
17:58:08  <piscisaureus_>I am under time pressure
17:58:12  <piscisaureus_>I have to go in 1 hour
18:00:02  <mjr_>bnoordhuis: bad news on the slab allocator fix. There's a leak somewhere.
18:00:09  <bnoordhuis>mjr_: oh?
18:00:10  <mjr_>https://skitch.com/mranney/8sc96/circonus-view-graph
18:00:37  <mjr_>The purple line there is the machine with the patch, and the other 20 or so lines on top of each other are v0.6 with just no idle.
18:00:47  <mjr_>29 other machines I guess.
18:01:38  <tjfontaine>how many servers have the gc idle patch?
18:02:37  * ericktquit (Quit: erickt)
18:03:04  <bnoordhuis>back to the drawing board, i guess...
18:04:52  <mjr_>tjfontaine: all servers in production have the GC idle patch. It is an unqualified success.
18:04:59  <tjfontaine>ok
18:09:16  * ericktjoined
18:13:44  <igorzi>piscisaureus_: yeah we're running into this
18:13:47  <piscisaureus_>AvianFlu: agreed that setsid is not a proper name
18:14:24  <igorzi>piscisaureus_: maybe there should be a way to flush stdout (or timeout) before process.exit ?
18:14:35  <igorzi>piscisaureus_: i guess we can do fs.write(1)
18:14:52  <piscisaureus_>igorzi: yeah that would work too I think
18:15:18  <piscisaureus_>igorzi: I don't have much time now to discuss this...
18:15:31  <igorzi>piscisaureus_: k, no problem.. thx
18:15:57  <piscisaureus_>igorzi: nobody really knows what to deal with it; creationix ran into the same problem but the other way round (his problem was that on unix stdout *is* blocking)
18:16:19  * pfox___joined
18:16:25  * orlandovftwjoined
18:16:39  <pfox___>hey.. so.. uv_loop_refcount() .. i see the admonition in uv.h against treating it as public API
18:16:53  <pfox___>is it going anywhere, mid/long-term?
18:17:10  * theCole_quit (Quit: theCole_)
18:17:54  <bnoordhuis>pfox___: it's already removed in the refcount branch
18:18:15  <pfox___>ok.
18:18:23  <pfox___>so..
18:18:46  <pfox___>how do downstream users observe the loop's state in terms of what would be required to forcefully tear it down?
18:18:59  <pfox___>like a refcount.. handles for the loop, etc
18:19:14  * CoverSlidequit (Read error: Connection reset by peer)
18:19:48  <pfox___>im in a situation where, in order to make libuv jive w/ rust's task-based idiom.. i have to create an async handle that users can use to poke the loop from other threads
18:20:18  <pfox___>and since libuv has platform inconsistent behavior for how a uv_unref()'d async handle that has had async_send() called against behaves, once uv_run() is called.. i can't unref that handle
18:20:27  <AndreasMadsen>isaacs: :(, that was my the weekly spell focus some weeks ago - will fix.
18:20:59  <pfox___>so i have no know, when the process is ready to exit (everything that isn't libuv's thread, that is), whether libuv will exit if i unref the async handle in question
18:21:15  <pfox___>before, i intended to just assert uv_loop_refcount(loop_ptr) == 0
18:21:44  <pfox___>because rolling my own refcount scheme just because of this implementation kind of sucks.
18:22:12  <pfox___>so, yeah. that's my situation. any thoughts or insights would be appreciated.
18:22:30  * mmaleckichanged nick to mmalecki[party]
18:23:32  * creationixjoined
18:24:44  <piscisaureus_>pfox___: I don't understand it... do you know when you won't need the loop any more?
18:24:56  <pfox___>piscisaureus_: yes.
18:25:08  <pfox___>at the runtime level
18:25:10  <piscisaureus_>pfox___: so why not send an uv_async_send to that loop
18:25:49  <pfox___>i don't understand
18:26:01  <piscisaureus_>and in the async callback unref the async handle
18:26:11  <pfox___>unref'ing the async handle isn't the issue
18:26:26  <pfox___>it's how can i know whether or not uv_run() will return after i do uv_close()
18:26:41  <pfox___>because if i just go on uv_close() it and the loop hangs, then the process hangs
18:26:57  <pfox___>id rather just force a segfault if the loop isn't going to exit
18:27:41  <brson>it's just for a sanity check
18:27:45  <piscisaureus_>pfox___: ah right. I suppose that should be possible.
18:27:54  * mjr_quit (Remote host closed the connection)
18:28:06  <CIA-155>node: Marcel Laverdet master * r7063575 / src/node_script.cc :
18:28:06  <CIA-155>node: Cleanup vm module memory leakage
18:28:06  <CIA-155>node: There are some paths here that led to dangling contexts. By being
18:28:06  <CIA-155>node: smarter with handle management we can get rid of all the cleanup code
18:28:06  <CIA-155>node: and fix those issues. - http://git.io/bCmcZw
18:28:07  <piscisaureus_>pfox___: maybe we can have some sort of API for that
18:28:10  * mjr_joined
18:28:40  <piscisaureus_>pfox___: but you should know that after the refcount refactor is done, loop hangs are history
18:29:03  <pfox___>how so?
18:29:22  <bnoordhuis>mjr_: do you have any idea what could cause that leak? i'm running some benchmarks but memory usage is all very stable
18:29:29  <piscisaureus_>pfox___: well, because the loop will always exit when there's nothing more to do
18:29:43  <mjr_>bnoordhuis: I do not, but this is a very aggressive stress test application.
18:29:52  <pfox___>really. hm.
18:29:54  <mjr_>It processes 3K packets / sec in normal operation.
18:29:56  <piscisaureus_>pfox___: please post an issue.
18:30:09  <piscisaureus_>pfox___: I am a little too busy right now but I agree that sanity checks are sane :-)
18:30:25  <piscisaureus_>pfox___: maybe comment on the refcount refactor issue
18:30:37  <pfox___>how is the overall API affected by the refcount refactor?
18:30:52  <pfox___>because "just exit when there's no work" is kind of.. i dunno. different?
18:30:57  <piscisaureus_>pfox___: yes
18:31:04  <pfox___>so what use is a uv_async_t*?
18:31:05  <piscisaureus_>pfox___: look up the issue in the issue tracker
18:31:26  <piscisaureus_>pfox___: ah, uv_async_t will keep the loop alive
18:31:28  <pfox___>whats the ticket #?
18:32:01  <piscisaureus_>pfox___: github has good search.
18:32:02  <piscisaureus_>https://github.com/joyent/libuv/issues/347
18:32:15  <pfox___>ty
18:32:57  <pfox___>ok. uv_async_t is always active
18:33:02  <pfox___>so my use case won't change
18:34:08  <pfox___>so is uv_close() optional, now?
18:34:20  <piscisaureus_>pfox___: no
18:34:24  <bnoordhuis>mjr_: https://github.com/bnoordhuis/node/compare/slab-allocator%5E%5E...slab-allocator <- quick sanity check, can you test that with e.g. `node --expose-gc benchmark/http_simple_auto.js -q -t 30 -c 100 bytes/1024`?
18:34:28  <piscisaureus_>pfox___: sorry. I am too busy. I am going to ignore you now
18:34:35  <piscisaureus_>pfox___: ping me later
18:34:44  <bnoordhuis>mjr_: it assumes ab is installed and dumps some memory stats at the end
18:35:08  <bnoordhuis>pfox___: he's such a charming fella, isn't he, our piscisaureus_? :)
18:35:15  <mjr_>bnoordhuis: so you mean do expose-gc with my program?
18:35:46  <pfox___>im used to dealing with aspies, its alright
18:35:46  <bnoordhuis>mjr_: no, just node (the version that contains the slab allocator)
18:36:51  <mjr_>Sure, I reverted that machine already, but I can rebuild and try that.
18:38:18  <bnoordhuis>mjr_: i want to make sure you're seeing roughly the same numbers that i'm seeing
18:39:34  <piscisaureus_>pfox___: that is kinda unwarranted...
18:40:37  <CIA-155>node: Ben Noordhuis master * r4e84dfa / benchmark/http_simple_auto.js : bench: run GC and dump stats if --expose-gc is set - http://git.io/8laj9Q
18:40:46  <pfox___>piscisaureus_: in all honesty, you are a very casually disrespectful person. i don't take it personal, but it does make it difficult to interact with you.
18:40:56  <pfox___>but, i apologize for my words. it was unwarranted.
18:40:57  * mikealjoined
18:41:28  <bnoordhuis>pfox___: keep in mind he's dutch
18:41:34  <pfox___>and not a "i'm sorry you're offended" non-apology., either
18:42:05  <bnoordhuis>bluntness is considered a virtue here
18:42:24  <pfox___>noted.
18:42:28  <pfox___>yay me, caused a scene.
18:42:54  <bnoordhuis>oh, that's nothing
18:43:00  <bnoordhuis>you should see me when i'm idling in #php
18:43:31  <bnoordhuis>pfox___: re refcount refactor, the idea is that handles that are not actually doing anything don't keep the event loop alive
18:44:21  <bnoordhuis>turns out reffing at handle creation and unreffing at close wasn't such a hot idea, caused a lot of bugs
18:44:57  <pfox___>interesting.
18:45:00  <CIA-155>libuv: Bert Belder reviewme * rf6a8957 / (test/test-list.h test/test-spawn.c): Test for setuid/setgid - http://git.io/EZ4o9g
18:45:02  <bnoordhuis>uv_async_t is something of an odd duck though, it's always active
18:46:47  * travis-cijoined
18:46:48  <travis-ci>[travis-ci] joyent/libuv#228 (reviewme - f6a8957 : Bert Belder): The build is still failing.
18:46:48  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/8106ff4...f6a8957
18:46:48  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1192677
18:46:48  * travis-cipart
18:47:38  <CIA-155>libuv: Bert Belder reviewme * r9ea9862 / (test/test-list.h test/test-spawn.c): Test for setuid/setgid - http://git.io/klA6Jg
18:47:57  <pfox___>yeah.. like i said.. our use case doesn't change, which is good (i guess?)
18:48:22  <pfox___>whats the timeframe for landing this? node 0.9?
18:48:34  <bnoordhuis>pfox___: it's scheduled to go into 0.8
18:48:46  <pfox___>so soon.
18:48:54  <pfox___>ok. yeah.. our branch in rust is pretty old.
18:49:24  * travis-cijoined
18:49:24  <travis-ci>[travis-ci] joyent/libuv#229 (reviewme - 9ea9862 : Bert Belder): The build is still failing.
18:49:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f6a8957...9ea9862
18:49:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1192693
18:49:24  * travis-cipart
18:50:40  <piscisaureus_>isaacs: can you try if the latest reviemwe branch passes the setgid-fails test on mac
18:50:48  <piscisaureus_>isaacs: (when run as sudo)
18:50:55  <piscisaureus_>isaacs: I'd like to drop this and then finish the node stuff.
18:54:46  <bnoordhuis>mjr_: ran some more tests, i can't reproduce anything that's remotely close to what you're seeing
18:56:01  <mjr_>In a meeting, but I'll get back to it.
18:56:05  <tjfontaine>bnoordhuis: could be an artifact of the backport? or you were testing on the backport?
18:56:20  <mjr_>bnoordhuis: it made all of our processes leak, it seems.
18:56:32  <isaacs>piscisaureus_: running tests as sudo now...
18:57:16  <bnoordhuis>tjfontaine: yes, testing the backport
18:58:25  <pfox___>https://github.com/joyent/libuv/issues/391
18:59:36  * felixgejoined
18:59:36  * felixgequit (Changing host)
18:59:37  * felixgejoined
19:04:20  <isaacs>piscisaureus_:
19:04:22  <isaacs>[% 0|+ 80|- 12]: spawn_setuid_setgid
19:04:22  <isaacs>`spawn_setuid_setgid` failed: exit code 6
19:04:22  <isaacs>Output from process `spawn_setuid_setgid`:
19:04:24  <isaacs>Assertion failed in test/test-spawn.c on line 519: pw == NULL
19:04:26  <isaacs>=============================================================
19:04:32  <piscisaureus_>ah crap
19:04:33  <isaacs>piscisaureus_: otherwise looks the same as v0.6
19:04:38  <piscisaureus_>isaacs: that's the only one?
19:04:46  <piscisaureus_>isaacs: I think I made a type in an assert :-)
19:05:04  <isaacs> pw = getpwnam("nobody");
19:05:04  <isaacs> ASSERT(pw == NULL);
19:05:09  <isaacs>yeah, certainly looks like a typo :)
19:05:24  <piscisaureus_>isaacs: ok, so I will change that and land on 0.6
19:05:34  <piscisaureus_>isaacs: I am pretty positive that it is correct otherwise
19:06:15  <isaacs>yeah, lgtm
19:06:18  <isaacs>thanks
19:06:32  <CIA-155>libuv: Bert Belder v0.6 * rc42ba10 / (6 files in 5 dirs): Temporary API to support spawn with uid and gid options - http://git.io/AkOFIQ
19:06:32  <CIA-155>libuv: Bert Belder v0.6 * r66647bf / (test/test-list.h test/test-spawn.c): Test for setuid/setgid - http://git.io/5c4Exg
19:08:17  * travis-cijoined
19:08:17  <travis-ci>[travis-ci] joyent/libuv#230 (v0.6 - 66647bf : Bert Belder): The build is still failing.
19:08:17  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/06ae804...66647bf
19:08:17  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1192892
19:08:17  * travis-cipart
19:12:40  * felixgequit (Quit: felixge)
19:13:48  * theColejoined
19:22:47  * `3rdEdenjoined
19:25:14  <CIA-155>libuv: Bert Belder v0.6 * raea5db5 / src/win/error.c : Windows: add mappings for UV_ENOENT - http://git.io/W1CjJA
19:26:57  * travis-cijoined
19:26:57  <travis-ci>[travis-ci] joyent/libuv#231 (v0.6 - aea5db5 : Bert Belder): The build is still failing.
19:26:57  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/66647bf...aea5db5
19:26:57  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1192957
19:26:57  * travis-cipart
19:29:08  <CIA-155>node: Bert Belder v0.6 * r9e5216f / (15 files in 7 dirs): uv: upgrade to aea5db5da1 - http://git.io/VNpxUQ
19:29:26  <piscisaureus_>crap
19:29:29  <piscisaureus_>force push coming up
19:29:53  <CIA-155>node: Bert Belder v0.6 * re221cd4 / (14 files in 6 dirs): uv: upgrade to aea5db5da1 - http://git.io/TK7Fxg
19:31:21  * mmalecki[party]changed nick to mmalecki
19:37:32  * theColequit (Quit: theCole)
19:47:39  * theColejoined
19:59:37  <CIA-155>libuv: Bert Belder v0.6 * rd41cc91 / (src/win/process.c test/test-spawn.c): Windows: uv_spawn2 reports the wrong error when setuid/setgid is specified - http://git.io/xeVBZg
20:01:08  <ira>Can I drop master libuv into node 0.6.15 without issue, for testing?
20:01:21  * travis-cijoined
20:01:21  <travis-ci>[travis-ci] joyent/libuv#232 (v0.6 - d41cc91 : Bert Belder): The build is still failing.
20:01:21  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/aea5db5...d41cc91
20:01:21  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1193139
20:01:21  * travis-cipart
20:01:28  <ira>Or is there another branch etc, I should use?
20:01:47  <CIA-155>node: Bert Belder v0.6 * r0b75eee / (deps/uv/src/win/process.c deps/uv/test/test-spawn.c): uv: upgrade to d41cc9118d - http://git.io/EXraPw
20:04:08  <isaacs>ira: i'd expect a lot of failure if you do that
20:04:16  <isaacs>ira: libuv master goes with node master
20:04:22  <isaacs>ira: libuv v0.6 goes with node v0.6
20:04:55  <ira>For contribution, either is accepable?
20:06:16  <isaacs>ira: sure, but just know that contributing to v0.6 means it'll only be in v0.6 :)
20:06:22  <isaacs>ira: we do usually pull into master
20:06:58  <CIA-155>node: Bert Belder v0.6 * r51e66ec / common.gypi :
20:06:58  <CIA-155>node: Windows: turn off /Gm
20:06:58  <CIA-155>node: Otherwise multicode compile doesn't work. - http://git.io/Fxt82A
20:07:00  <isaacs>ira: contributing to master => only for node v0.7+
20:10:30  <ira>Ok, that makes sense. If you need a 0.7 version ping me. I'd like it in both.
20:10:41  <ira>(Once I have it up.)
20:14:05  <CIA-155>node: Bert Belder reviewme * r55e4d54 / (lib/child_process.js src/process_wrap.cc): Child process: support the `gid` and `uid` options (+172 more commits...) - http://git.io/nMKCZQ
20:14:29  <piscisaureus_>isaacs: bnoordhuis: can you review https://github.com/joyent/node/commit/55e4d54927536e6f796de87c0ab266a74b9e1c81 ?
20:14:42  <piscisaureus_>isaacs: bnoordhuis: unfortunately I have no time to write a test now - but there are tests in libuv
20:16:32  <isaacs>reading
20:16:33  <bnoordhuis>piscisaureus_: i'll write a test if you finish the refcount refactor <3
20:16:43  <piscisaureus_>bnoordhuis: hahaha
20:16:47  <piscisaureus_>bnoordhuis: ga buiten spelen
20:16:53  <bnoordhuis>haha
20:18:25  <bnoordhuis>mjr_: is your application a http server, client, something else?
20:19:09  <mjr_>bnoordhuis: well, since I'm doing UDP, it's not exactly a web server. :)
20:19:24  <mjr_>It's a metrics collection and aggregation framework.
20:20:06  <bnoordhuis>oh right, one more benchmark i need to write
20:20:35  <bnoordhuis>i'm stress-testing the slab allocator with http traffic
20:20:56  <bnoordhuis>i might be persuaded to believe that node's http client either leaks or hits a GC worst case
20:21:03  <isaacs>piscisaureus_: testing
20:21:08  <mjr_>bnoordhuis: but another server I have that also leaked is HTTP.
20:21:28  <mjr_>bnoordhuis: oh, here's something similar about both of them though, they each manage a pool of Buffer objects explicitly.
20:21:57  <mjr_>Other HTTP servers with the same node executable didn't have the same bloat, but perhaps I didn't wait long enough.
20:21:58  <bnoordhuis>mjr_: interesting. how and what exactly do they manage?
20:24:21  <mjr_>Let me find some code
20:24:38  <mjr_>manage is a strong word.
20:24:48  <mjr_>They each explicitly allocate Buffer objects to work with.
20:25:08  <mjr_>The metrics process needs a Buffer to write into because its doing a UDP protocol
20:25:22  <txdv>between alloc_cb and the callback of a calback, is there the possibility that alloc_cb for another event will be called inbetween?
20:25:40  <bnoordhuis>txdv: no
20:26:05  <mjr_>bnoordhuis: but the other process keeps 4K buffers in memory while a file is being uploaded, then writes those to disk when the buffer fills up.
20:26:43  <txdv>so I can go with the one buffer for the entire loop except if I want to use some data in it, like if I want to send it to another socket - ill have to copy from it, right?
20:27:38  <bnoordhuis>mjr_: so there's potentially more involved than just network i/o?
20:27:59  <bnoordhuis>txdv: yes, that's correct
20:28:31  <bnoordhuis>txdv: git grep slab test - we use the same technique in a lot of our tests
20:28:35  <mjr_>Yeah, all of these processes do some kind of logic. The ones that bloated though are both calling new Buffer() at some point, although that could be nothing.
20:29:20  <bnoordhuis>mjr_: you don't happen to have some simple test case i can run, right?
20:30:06  <mjr_>I have a test driver, but it doesn't exhibit the problem.
20:30:12  <mjr_>Tricky
20:32:25  * AndreasMadsenquit (Remote host closed the connection)
20:32:34  * AndreasMadsenjoined
20:33:13  * AndreasMadsenquit (Remote host closed the connection)
20:33:20  * AndreasMadsenjoined
20:36:42  * AndreasMadsenquit (Remote host closed the connection)
20:36:48  * AndreasMadsenjoined
20:37:37  * AndreasMadsenquit (Remote host closed the connection)
20:37:43  * AndreasMadsenjoined
20:38:25  * AndreasMadsenquit (Remote host closed the connection)
20:38:30  * AndreasMadsenjoined
20:39:57  * ericktquit (Quit: erickt)
20:41:15  <CIA-155>node: Bert Belder v0.6 * r55e4d54 / (lib/child_process.js src/process_wrap.cc): Child process: support the `gid` and `uid` options - http://git.io/nMKCZQ
20:41:33  * AndreasMadsenquit (Remote host closed the connection)
20:41:38  * AndreasMadsenjoined
20:42:30  <isaacs>piscisaureus_: thanks!
20:47:27  <isaacs>ok, anything else to go into 0.6.16?
20:48:06  <piscisaureus_>nonblocking stdout pipes :-p
20:48:27  <ira>Nah, I need a code review for fs.watch stuff, but I don't think you'll want it that quick ;)
20:48:43  * AndreasMadsenquit (Remote host closed the connection)
20:48:49  * AndreasMadsenjoined
20:51:01  * AndreasMadsenquit (Remote host closed the connection)
20:51:11  * AndreasMadsenjoined
20:56:28  * AndreasMadsenquit (Remote host closed the connection)
20:56:45  <isaacs>piscisaureus_: i don't think that can be in 0.6
20:56:51  <isaacs>even though it would be nice :)
20:57:02  <piscisaureus_>isaacs: well.. the feature is questionable
20:57:14  <piscisaureus_>isaacs: but now we have platform incompatibilities
20:57:33  <isaacs>piscisaureus_: for stability's sake, we must keep them!
20:58:37  <ira>piscisaureus_: Only long enough, so mission critical applications depend on them. No longer.
20:59:14  * loladirojoined
21:01:52  <piscisaureus_>Ok. I'm gone.
21:01:57  * piscisaureus_changed nick to pisc_away
21:05:12  * irachanged nick to ira_away
21:10:56  * mmaleckichanged nick to mmalecki[zzz]
21:13:05  <CIA-155>node: Ben Noordhuis master * r12a90e9 / benchmark/http_bench.js :
21:13:05  <CIA-155>node: bench: add continuous stress test
21:13:05  <CIA-155>node: Useful in tracking down or at least demonstrating memory leaks. - http://git.io/OAMA5w
21:13:34  <bnoordhuis>it would seem http.request() leaks
21:19:25  * c4miloquit (Ping timeout: 246 seconds)
21:31:11  * mikealquit (Quit: Leaving.)
21:33:33  * mikealjoined
21:34:08  <CIA-155>node: isaacs v0.6.16-release * r33df812 / (AUTHORS ChangeLog src/node_version.h): (log message trimmed)
21:34:08  <CIA-155>node: 2012.04.27 Version 0.6.16 (stable)
21:34:08  <CIA-155>node: * Upgrade V8 to 3.6.6.25
21:34:08  <CIA-155>node: * Windows: add mappings for UV_ENOENT (Bert Belder)
21:34:08  <CIA-155>node: * linux: add IN_MOVE_SELF to inotify event mask (Ben Noordhuis)
21:34:09  <CIA-155>node: * unix: call pipe handle connection cb on accept() error (Ben Noordhuis)
21:34:10  <CIA-155>node: * unix: handle EWOULDBLOCK (Ben Noordhuis)
21:38:37  * `3rdEdenquit (Quit: Leaving...)
21:40:09  <mjr_>http.request leaks? Holy shit.
21:40:16  <mjr_>That's our bread and butter.
21:40:52  * `3rdEdenjoined
21:41:08  <isaacs>bnoordhuis: interesting. could be a source of mjr_'s issues, i'd suspect.
21:41:40  * pfox___quit (Ping timeout: 244 seconds)
21:41:50  <mjr_>So Brendan has looked around at some of our core files and seen lots of copies of HTTP headers in there, way more than make sense, as if they are leaking.
21:42:38  <bnoordhuis>mjr_: each parser (each connection) has a kind of headers cache, that's probably what he was seeing
21:42:39  * theColequit (Quit: theCole)
21:44:26  <mjr_>But the strings were duplicated like 100K times
21:45:02  * theColejoined
21:45:57  <bnoordhuis>mjr_: v8::String::New() makes a copy from the strings in the headers cache
21:46:10  <bnoordhuis>if you have a big heap, you'll see them a lot
21:46:27  <bnoordhuis>avoiding the copy is a future optimization point
21:46:38  <bnoordhuis>*makes a copy of
21:47:19  <mjr_>https://gist.github.com/2513563
21:47:31  <mjr_>1.1M instances of Connection: keep-alive
21:48:10  <mjr_>But yeah, clearly some duplication is expected. That's why they call it "garbage" collection, after all.
21:53:08  * theColequit (Quit: theCole)
21:54:47  <isaacs>bnoordhuis: see any issues on linux?
21:55:43  <bnoordhuis>isaacs: `make test` is at 90% with no failures right now
21:55:48  <isaacs>kewl
21:56:04  <bnoordhuis>the moment i typed that pummel/test-timers failed :/
21:56:10  * loladiroquit (Ping timeout: 246 seconds)
21:56:34  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
21:57:04  <bnoordhuis>you know, i guess it would make sense to turn the most common http headers into Persistent strings
21:57:27  <txdv>bnoordhuis: how about node, how does handle the buffer for each socket? does it allocate a buffer for each socket?
21:57:52  <bnoordhuis>txdv: no, it uses a slab allocator... for better or worse
21:57:58  <txdv>worse?
21:58:19  <isaacs>bnoordhuis: yes, i agree. it would be good to have persistents for Connection and osme other common ones
21:58:46  <bnoordhuis>tx well, it seems something is leaking memory and it might be the slab allocator
21:58:59  * pfox___joined
21:59:02  <mjr_>txdv: it does have a buffer per socket, but there's a pool of buffers that node manages.
21:59:26  <txdv>damn smart node
22:02:28  <bnoordhuis>pummel/test-keep-alive, pummel/test-regress-GH-892 and pummel/test-tls-ci-reneg-attack failed too
22:04:09  * ira_awaychanged nick to ira
22:04:29  * ericktjoined
22:04:41  <bnoordhuis>pummel/test-tls-ci-reneg-attack also consistently fails in isolation
22:06:59  <bnoordhuis>also consistently fails with the v0.6 branch
22:07:47  <isaacs>bnoordhuis: has it ever worked in v0.6?
22:08:01  <bnoordhuis>i don't know but it also fails with master...
22:08:12  <bnoordhuis>seems we have a regression
22:08:42  <isaacs>wonderful
22:09:01  <bnoordhuis>does `python tools/test.py --mode=debug,release pummel/test-tls-ci-reneg-attack` pass for you?
22:09:35  <isaacs>yep
22:09:43  <bnoordhuis>sigh
22:09:49  * bnoordhuisgets his debugger
22:10:13  * avalanche123quit (Ping timeout: 240 seconds)
22:11:37  * pfox___quit (Ping timeout: 256 seconds)
22:11:45  <bnoordhuis>ah, the test failing with master may have something to do with my outdated openssl binary
22:12:03  * avalanche123joined
22:12:41  <isaacs>bnoordhuis: just pushed an -RC1
22:12:56  <isaacs>bnoordhuis: but only for upgrading npm, nothing relevant.
22:13:12  <CIA-155>node: isaacs v0.6.16-release * r9cfa9bb / (125 files in 18 dirs): Upgrade npm to 1.1.18 - http://git.io/DZggBg
22:13:14  <CIA-155>node: isaacs v0.6.16-release * r0a5c7f6 / (AUTHORS ChangeLog src/node_version.h): (log message trimmed)
22:13:14  <CIA-155>node: 2012.04.27 Version 0.6.16 (stable)
22:13:14  <CIA-155>node: * Upgrade V8 to 3.6.6.25
22:13:14  <CIA-155>node: * Upgrade npm to 1.1.18
22:13:14  <CIA-155>node: * Windows: add mappings for UV_ENOENT (Bert Belder)
22:13:14  <CIA-155>node: * linux: add IN_MOVE_SELF to inotify event mask (Ben Noordhuis)
22:13:15  <CIA-155>node: * unix: call pipe handle connection cb on accept() error (Ben Noordhuis)
22:13:24  * pfox___joined
22:14:39  <bnoordhuis>okay, it must be something external
22:15:00  <bnoordhuis>3415427 was the commit that introduced the test, it was working then but now when i check out 3415427, the test fails
22:17:08  <isaacs>bnoordhuis: hm.
22:17:13  <isaacs>bnoordhuis: yeah, it works for me
22:17:59  <bnoordhuis>let me do a full recompile of the tree just in case
22:18:14  <bnoordhuis>but if it still fails, let's consider it a local issue and move on
22:23:58  <bnoordhuis>still failing
22:25:45  <isaacs>yep.
22:25:49  <isaacs>works for me
22:25:53  <isaacs>on several different machine
22:25:54  <isaacs>*s
22:25:55  <txdv>what happens if I dont call uv_accept in the listen_cb?
22:27:32  <txdv>will it just turn the connection down or what?
22:28:16  <bnoordhuis>txdv: no, it'll stop accept()ing new connections until you call uv_accept
22:28:38  <bnoordhuis>that should probably read "until you *do* call uv_accept"
22:28:40  <txdv>so im always forced to accept
22:28:45  <bnoordhuis>no
22:28:57  <bnoordhuis>you could set a timer and accept the connection when it expires
22:30:45  <txdv>but this functionality is not present in node.js
22:31:35  <bnoordhuis>txdv: no. node always calls uv_accept()
22:31:50  <bnoordhuis>which, as we recently discovered, may not always be a good idea
22:32:03  <bnoordhuis>it affects the load balancing fairness of the cluster module
22:32:35  <txdv>I could accept on a different loop
22:32:36  <txdv>hmm
22:32:49  <txdv>but there is no uv_dontaccept
22:33:21  <bnoordhuis>txdv: no, because there is no way to do that
22:33:48  <txdv>So, I can accept on another loop or I can delay it with a timer for example
22:34:03  <bnoordhuis>you cannot accept on another loop
22:34:15  <bnoordhuis>but you can delay accepting it
22:34:42  <txdv>so if I create a tcp handle on another loop and use it to accept, it will fail
22:35:05  * pfox___quit (Ping timeout: 260 seconds)
22:35:13  <txdv>not much that uv_accept is good for
22:35:37  <txdv>well, 2 loops are 2 different threads, doesn't make even sense, im stupid
22:38:31  <txdv>i want RunOnceNonblocking
22:38:32  <txdv>:(
22:39:33  <bnoordhuis>you just may get it
22:41:50  * mikealquit (Quit: Leaving.)
22:41:50  <isaacs>bnoordhuis: ok, it's a bit late for a release... and friday.
22:41:55  <isaacs>considering dropping this thing monday morning
22:42:03  <bnoordhuis>sure
22:42:04  <isaacs>bnoordhuis: but it looks good otherwise, afaict
22:42:17  <bnoordhuis>monday is queensday here though so bert and i probably won't be around
22:42:30  <isaacs>no worrie
22:42:57  <isaacs>i owe you all a status update email as well
22:43:44  * pisc_awaychanged nick to piscisaureus
22:43:45  <piscisaureus>back
22:43:48  <piscisaureus>any questions
22:44:36  <isaacs>piscisaureus: 0.6.16. lgty?
22:44:47  <isaacs>http://nodejs.org/dist/v0.6.16/node-v0.6.16-RC1.tar.gz
22:44:57  <isaacs>http://nodejs.org/dist/v0.6.16/blog.html
22:45:13  <piscisaureus>isaacs: let me try that
22:45:37  <isaacs>piscisaureus: or the v0.6.16-release branch
22:45:45  <piscisaureus>yeah, that's what I am using :-)
22:46:37  <bnoordhuis>test: cluster: add worker death event test (Ben Noordhuis) <- that hardly bears mentioning :)
22:46:50  <piscisaureus>don't check return value of unsetenv (Ben Noordhuis)
22:46:56  <piscisaureus>now that :-)
22:47:20  * mikealjoined
22:47:28  <bnoordhuis>it's to please the freebsd crowd
22:47:42  <piscisaureus>why?
22:47:50  <piscisaureus>they make unsetenv() fail ??
22:48:38  <isaacs>oh, missed the test thing. yes, that should not be there
22:48:54  <bnoordhuis>piscisaureus: no. it means node compiles on freebsd again
22:49:14  * isaacsshrugs. actually, whatever. there's not a lot of stuff in the changelog this time anyway
22:49:31  <bnoordhuis>no, just bits (pun intended) and pieces
22:50:41  <piscisaureus>we should also port the cluster fix to 0.6
22:50:43  <piscisaureus>at some point
22:51:01  <bnoordhuis>what cluster fix? the load balancing thing?
22:51:11  <piscisaureus>yeha
22:51:13  <piscisaureus>yeah
22:51:34  <bnoordhuis>yeehaa
22:51:44  <piscisaureus>yahoo
22:51:55  * pfox___joined
22:51:58  <piscisaureus>test-net-write-slow keeps failing for me
22:58:53  <piscisaureus>[09:55|% 100|+ 339|- 5]: Done
23:00:02  <piscisaureus>failures:
23:00:02  <piscisaureus>- test-signal-handler
23:00:02  <piscisaureus>- test-net-write-slow
23:00:02  <piscisaureus>- test-net-pipe-connect-errors
23:00:02  <piscisaureus>- test-http-get-pipeline-problem
23:00:03  <piscisaureus>- test-fs-realpath
23:00:06  <piscisaureus>Oh I should run test-all
23:05:39  * pfox___quit (Ping timeout: 252 seconds)
23:07:10  <piscisaureus>isaacs: in 0.8 I definitely want 0 failures ....
23:07:22  <piscisaureus>isaacs: but otherwise, 0.6.16 lgtm
23:07:29  <isaacs>piscisaureus: kewl :)
23:07:35  <isaacs>i also want 0 failures in 0.8
23:07:38  <isaacs>we're getting close
23:12:54  * mikealquit (Quit: Leaving.)
23:13:29  <txdv>bnoordhuis: i was just thinking while I took a walk outside
23:13:40  <txdv>uv_async + RunOnce = RunOnceNonblocking
23:14:05  <piscisaureus>bnoordhuis: to continue, the barter, let's say I do the refcount refactor and you start on the stdio stuff
23:15:18  <bnoordhuis>piscisaureus: what needs to happen?
23:15:46  <bnoordhuis>txdv: we'll probably add a uv_run_nowait() function or something sometime in the future
23:16:18  <txdv>the libev impl of that is easy
23:16:32  * c4milojoined
23:17:12  <piscisaureus>bnoordhuis: https://github.com/joyent/node/issues/3065
23:18:36  <bnoordhuis>piscisaureus: right, stdio + spawn
23:18:37  <bnoordhuis>can do
23:18:50  <piscisaureus>bnoordhuis: kewl
23:19:04  <piscisaureus>bnoordhuis: if you make a reasonable api for it I can probably do the windows side for you
23:19:11  <piscisaureus>bnoordhuis: a libuv api I mean
23:19:21  <bnoordhuis>sounds like a plan
23:19:25  <piscisaureus>probably take an array of uv_child_fd_t
23:22:21  <piscisaureus>struct uv_child_fd_s {
23:22:21  <piscisaureus> unsigned int flags; // EXISTING_FD | EXISTING_STREAM | IPC
23:22:21  <piscisaureus> union {
23:22:21  <piscisaureus> int existing_fd;
23:22:21  <piscisaureus> HANDLE existing_handle;
23:22:22  <piscisaureus> uv_stream_t* existing_stream;
23:22:22  <piscisaureus> uv_stream_t* new_stream;
23:22:23  <piscisaureus> }
23:22:23  <piscisaureus>}
23:22:24  <piscisaureus>something like that
23:24:41  * mikealjoined
23:42:27  <piscisaureus>bah
23:42:36  <piscisaureus>It is no longer possible to merge 0.6 into master for libuv
23:42:44  <piscisaureus>bnoordhuis: what happened to linux.c ?
23:43:01  <bnoordhuis>piscisaureus: it became src/unix/linux/core.c
23:43:27  <bnoordhuis>i split off the inotify code into a separate file, it was becoming unwieldy
23:43:28  <piscisaureus>bnoordhuis: hmm. git is not detecting the move
23:44:11  <bnoordhuis>piscisaureus: what are you trying to do?
23:44:21  <piscisaureus>bnoordhuis: merge the 0.6 branch into master
23:44:28  <piscisaureus>because there are fixes in 0.6 that are not in master
23:44:42  <bnoordhuis>right. it was properly `git mv`d
23:44:52  <piscisaureus>git move does not exist, unfortunately
23:44:58  <piscisaureus>git does not track that
23:45:28  <bnoordhuis>piscisaureus: git-mv - Move or rename a file, a directory, or a symlink
23:45:30  <tjfontaine>it knows about moves, just not how to merge subsequent changes to moved files :)
23:45:37  <piscisaureus>no
23:45:44  <piscisaureus>it does not track moves at all
23:45:58  <bnoordhuis>it tracks the hash
23:45:59  <tjfontaine>it can "detect" them in branch history
23:46:06  <piscisaureus>that's true
23:46:14  <piscisaureus>but if you also change the file it has to do some search
23:46:30  <piscisaureus>which often does not work
23:46:56  <bnoordhuis>i can do the merge if you want
23:47:01  <bnoordhuis>i know what moved where
23:47:32  <piscisaureus>bnoordhuis: you'll run into issues with src/win/fs.c
23:47:39  <piscisaureus>we should merge in steps :-)
23:53:12  <txdv>directory tracking with inotify?
23:56:31  <bnoordhuis>txdv: what about it?
23:58:36  <txdv>awesome