00:00:04  <piscisaureus_>lemme see
00:00:32  <tjfontaine>TooTallNate: https://github.com/tjfontaine/node-vlc/blob/master/examples/vlc.js run as: node vlc.js /dev/null
00:00:59  <bnoordhuis>piscisaureus_: what's that v8.log from that you pasted earlier?
00:01:01  <TooTallNate>woah, vlc, nice :)
00:01:03  * TooTallNatelooking
00:01:17  <tjfontaine>heh, it's young for now :)
00:01:18  <loladiro>piscisaureus_: I had something else implemented that basically just wrapped CreatePipe and pipe2, but that turned out not to be flexible enough
00:01:41  <piscisaureus_>bnoordhuis It seems to log all LoadIC and StoreIC twice, *or* it actually does them twice
00:02:17  <piscisaureus_>loladiro: hmm
00:02:22  <tjfontaine>oh I didn't realize I could DEBUG=ref, lemme see if this verifies my theory
00:02:24  <piscisaureus_>loladiro: how would you suggest use use this
00:03:06  <piscisaureus_>like
00:03:06  <piscisaureus_>stdio_containers[0].flags = UV_DUAL_PIPE
00:03:06  <piscisaureus_>... and then ?
00:03:15  <loladiro>basically, you create an empty uv_dual_pipe_t whenever you need explicit control over the other file end too.
00:03:19  <TooTallNate>tjfontaine: DEBUG=ref*
00:03:23  <loladiro>uv_spawn lazily creates the rest
00:03:26  <TooTallNate>don't forget the * ;)
00:03:32  <TooTallNate>tjfontaine: i'm trying out your example now though
00:04:06  <tjfontaine>TooTallNate: ok
00:04:21  <loladiro>basically it allows reusing the same fds/handles which is something we need for Julia
00:04:58  <piscisaureus_>loladiro: yeah, I know what you need :-)
00:06:01  <piscisaureus_>loladiro: but I was wonderhing how libuv would do the lazy creation of the pipe
00:06:03  <piscisaureus_>like you have
00:06:23  <loladiro>so, for example, you create a uv_dual_pipe_t with UV_STREAM_READ_PIPE and give it an uninitialized pipe. Then you pass that to two calls of uv_spawn, the first one of which initialized the uv_pipe_t and saves the other handle/fd in the uv_dual_pipe_t structure and the second one just reuses that
00:06:25  <piscisaureus_>uv_spawn(yyy); // <-- is the pipe created here
00:06:25  <piscisaureus_>uv_spawn(zzz); // <-- or there
00:06:34  <loladiro>In the first one
00:06:38  <piscisaureus_>ah ok
00:06:42  <loladiro>whenever you use it first
00:06:42  <piscisaureus_>so why can we not have
00:07:43  <piscisaureus_>ah, ok, I see
00:09:53  * c4miloquit (Remote host closed the connection)
00:10:15  <TooTallNate>tjfontaine: do you know which version of VLC I need?
00:10:17  <piscisaureus_>loladiro: so, let's consider
00:10:17  <piscisaureus_>uv_pipe_t pipe1, pipe2
00:10:17  <piscisaureus_>uv_pipe2_init(&pipe1, &pipe2, UV_PIPE_SAFE | UV_PIPE_DUPLEX);
00:10:17  <piscisaureus_>spawn(yyy) // pipe1 as stdout
00:10:17  <piscisaureus_>spawn(zzz) // pipe2 as stdin
00:10:17  <piscisaureus_>...
00:10:25  <piscisaureus_>loladiro: the problem would be closing the pipes, right?
00:10:27  <TooTallNate>tjfontaine: apparently I don't have "libvlc_set_exit_handler" in mine
00:10:42  * c4milojoined
00:11:23  <piscisaureus_>because you have to uv_close, which means you have wait for the close callback before freeing, which mean you can't allocate them on the stack, yadda yadda
00:12:24  <loladiro>you can allocate the uv_dual_pipe_t on the stack. Just no the uninitialized un_pipe_t
00:12:30  <CIA-112>node: isaacs master * r28e851c / (lib/repl.js test/simple/test-repl.js): Warn about running npm in the repl - http://git.io/mhr-mw
00:13:00  <piscisaureus_>loladiro: so, yeah, the downside is that this introduces more api
00:13:13  <piscisaureus_>like, significantly more. A new type, new concepts
00:13:47  <loladiro>yeah, that's the problem
00:13:48  <piscisaureus_>loladiro: so maybe we could do something where you just init two real libuv pipe objects
00:13:51  <tjfontaine>TooTallNate: oh, can you just comment it out?
00:14:01  <piscisaureus_>but we give you some way to free them without using a close callback
00:14:03  <tjfontaine>TooTallNate: I have been testing with 2.0.1 on osx
00:14:14  <TooTallNate>tjfontaine: ya, that's what i've been doing, there's a bunch missing though
00:14:20  * isaacsquit (Remote host closed the connection)
00:14:21  <TooTallNate>i'll update my old add VLC :p
00:14:30  <tjfontaine>heh
00:14:39  * isaacsjoined
00:15:15  * mmaleckijoined
00:15:17  * c4milo_joined
00:15:36  <piscisaureus_>loladiro: what are the `uv_stream_t* pipe` fields for?
00:16:10  <loladiro>piscisaureus_: Sometimes we need to create a real uv_pipe_t (i.e. an overlapped pipe on windows)
00:16:30  <loladiro>I guess it should be uv_pipe_t instead of uv_stream_t
00:16:44  <piscisaureus_>loladiro: aaah
00:17:37  <piscisaureus_>loladiro: so you propose a function that creates an connected pipe with two ends
00:17:59  <piscisaureus_>and for either end you would specify whether you want a raw fd, or a real uv_pipe_t object?
00:18:08  <loladiro>yes
00:18:23  <piscisaureus_>loladiro: do you have an api in mind for this function?
00:18:45  <loladiro>I wanted to have us_spawn to it, but it could be a separate function too
00:19:14  * theColequit (Quit: theCole)
00:19:15  <loladiro>*uv_spawn of course
00:19:16  <piscisaureus_>loladiro: ok, that could be... but if you do that, how would you turn one end into a real uv_pipe_t ?
00:19:28  <piscisaureus_>like, if it is all done by uv_spawn?
00:19:38  * c4miloquit (Remote host closed the connection)
00:19:59  <loladiro>you specify which end needs to be a real pipe and then you can do it with dual_pipe.write.pipe
00:20:27  <piscisaureus_>ah, right
00:21:16  * c4milojoined
00:21:39  <piscisaureus_>lemme think for a sec
00:24:27  <CIA-112>node: isaacs v0.6.19-release * r6cc8ffe / (243 files in 21 dirs): Upgrade npm to 1.1.24 - http://git.io/i-wEYw
00:24:27  <CIA-112>node: isaacs v0.6.19-release * rf077935 / (AUTHORS ChangeLog src/node_version.h): 2012.06.06 Version 0.6.19 (stable) - http://git.io/PkXLFQ
00:24:39  * ArmyOfBrucejoined
00:24:55  <TooTallNate>tjfontaine: i see the problem now :)
00:25:42  <tjfontaine>TooTallNate: my fault? :)
00:26:07  <TooTallNate>no, my fault :D i just added that null-pointer -> JS null functionality the other day
00:26:17  <TooTallNate>need to do a release for `ref`
00:26:18  <TooTallNate>one sec
00:26:22  <tjfontaine>k
00:27:42  <tjfontaine>TooTallNate: and when that's all done you can tell me if I'm crazy for my pull request on ffi :)
00:29:02  <TooTallNate>tjfontaine: ya, so try ref@0.0.17, should work now
00:29:25  <TooTallNate>tjfontaine: and re: pull request. it looks pretty good, but i'm really on the fence due to the fact that i tagged v1.0.0 like a week ago :p
00:29:55  <tjfontaine>hehe
00:31:00  <tjfontaine>excellent, seems fixed now, thanks TooTallNate
00:31:15  * vtjnashjoined
00:31:24  <TooTallNate>tjfontaine: nice! cool project btw. I'll keep my eye on it ;)
00:32:01  <tjfontaine>TooTallNate: heh, I hit one small wart with it, and I'm not sure how I feel about it, libvlc traps signals, so it kinda makes your life uninterruptible
00:33:14  <tjfontaine>TooTallNate: I was more impressed that my ffi generator still worked :)
00:34:46  <TooTallNate>tjfontaine: so what are the implications of that (trapping signals)?
00:35:19  <tjfontaine>well, it'd be nice if you could ^C the son of a bitch :P
00:36:43  <piscisaureus_>loladiro: what about https://gist.github.com/2879135 ?
00:37:03  <isaacs>test, please: http://nodejs.org/dist/v0.6.19/node-v0.6.19-RC0.tar.gz
00:37:04  <piscisaureus_>loladiro: I don't really like the way spawn() interacts with pipes right now
00:38:02  <piscisaureus_>what I don't like about my proposal is uv_pipe_close_sync :-(
00:38:34  <piscisaureus_>c'mon isaacs... I am trying to shift my day/night rythm to normal hours
00:38:40  <piscisaureus_>:-p
00:38:53  <isaacs>piscisaureus_: test tomorrow :)
00:38:58  <piscisaureus_>ok
00:39:01  <piscisaureus_>that's fine
00:39:19  <isaacs>oh, i think there's a v8 update. shoot.
00:39:26  <isaacs>ok, there'll be a RC1 anyway :)
00:39:41  <piscisaureus_>isaacs: you should move to europe. It'd be better if we all live in the same time zone.
00:40:47  <isaacs>piscisaureus_: i think that you're half-right.
00:40:48  <piscisaureus_>isaacs: I hear good stories about Somalia as well. Time zone wise, it's probably close enough
00:41:02  <isaacs>piscisaureus_: you guys should move to California
00:41:10  <isaacs>instead of snow, we have incredible mexican food.
00:41:18  <loladiro>piscisaureus_: Presumably, one couldn't start reading a pipe that was created with PIPE_SPAWN_SAFE, right? I'm wondering whether it's good to use uv_pipe_t to encapsulate both types of pipes
00:41:36  <piscisaureus_>loladiro: yes, that would be possible.
00:41:52  <isaacs>piscisaureus_: besides, igorzi is in US Pacific time. there is just hte problem of indutny.
00:41:55  <piscisaureus_>loladiro: it just wouldn't be optimal from a scalability POV
00:42:00  <isaacs>piscisaureus_: as they say, omsk is a lovely town, but it's a very long walk.
00:42:27  <loladiro>piscisaureus_: Wouldn't it require synchronous reads or something as it's not an overlapped pipe on windows?
00:42:33  <piscisaureus_>isaacs: there's better ways to convince than the californian food
00:42:44  <piscisaureus_>loladiro: yeah, so we'd do it on the thread pool
00:43:07  <loladiro>piscisaureus_: Ah, makes sense. I suppose that would be a good solution then
00:43:10  <piscisaureus_>loladiro: the same as stdin/stdout/stderr is usually handled (because the pipe we'd get from our parent is synchronous too, usually
00:43:10  <isaacs>piscisaureus_: yes, there are better ways.
00:43:18  <isaacs>piscisaureus_: there's also the sunshine.
00:43:27  <AvianFlu>isaacs, two consistent failures for you: https://gist.github.com/4a8d30f67282f9896b02
00:43:44  <piscisaureus_>isaacs: so you are a fan of Drs. P too, now?
00:44:09  <isaacs>Drs. P?
00:44:26  <loladiro>piscisaureus_: That seems like a good solution to me. Do you want to implement that, or do you want me to?
00:44:27  * mikealjoined
00:44:58  <piscisaureus_>loladiro: I don't really have a problem with your api, but I don't like adding functions and types. (and if anything I prefer more functions over more types) :-)
00:45:04  <piscisaureus_>loladiro: do you think you could?
00:45:17  * mikealquit (Client Quit)
00:45:18  <piscisaureus_>loladiro: in that case, I prefer you to do it. But start with one platform
00:45:45  <loladiro>piscisaureus_: Hmm, I could take a shot at it. Would you want the pipes to still be created inside uv_spawn?
00:45:46  <isaacs>oh, wait a second, you already updated v8 to 3.6.6.25
00:45:49  <isaacs>i'm a doof.
00:46:08  <piscisaureus_>loladiro: this is your chance for eternal fame in the libuv commit logs. But beware... we are review nazi's (well, bnoordhuis is)
00:46:19  <piscisaureus_>loladiro: well, just keep that as it is
00:46:54  <piscisaureus_>loladiro: the actual pipe should be created bu uv_pipe_link I think
00:47:01  <piscisaureus_>like, the fds/HANDLEs
00:47:03  <loladiro>That's what I though too
00:47:27  <piscisaureus_>loladiro: if this works out well I might remove the UV_CREATE_PIPE flag even
00:47:32  <piscisaureus_>because I like this api better
00:47:38  <CIA-112>node: isaacs v0.6.19-release * re5d3ea7 / (249 files in 23 dirs): Upgrade npm to 1.1.24 - http://git.io/zwfwbg
00:47:39  <CIA-112>node: isaacs v0.6.19-release * rdebf552 / (AUTHORS ChangeLog src/node_version.h): 2012.06.06 Version 0.6.19 (stable) - http://git.io/Yg_u6Q
00:47:46  <piscisaureus_>except for the uv_pipe_close_sync api but I guess we'll have to live with it
00:48:20  <loladiro>So, if we don't call uv_pipe_link, will the pipe by be created by uv_spawn?
00:48:31  <loladiro>i.e. if the pipe has an invalid file descriptor
00:48:43  * ericktquit (Quit: erickt)
00:48:49  <piscisaureus_>loladiro: well, no, uv_spawn will send you some terrible insults
00:49:01  <piscisaureus_>loladiro: unless (in the current API) UV_CREATE_PIPE is specified
00:49:25  <loladiro>Right, so how would we handle the case where we only need one pipe then
00:49:35  <loladiro>(if we want to get rid of UV_CREATE_PIPE)
00:49:56  <piscisaureus_>isaacs: re: omsk is a nice town but its a long walk" <-- that's what Drs. P said. It sounds better in dutch
00:50:07  <piscisaureus_>loladiro: a sec. /me typing
00:50:11  <loladiro>sure
00:51:55  <loladiro>another thing to consider maybe is the overhead of an extra uv_pipe_t when all you need is a raw fd. I don't know how big uv_pipe_t is atm
00:52:02  <bnoordhuis>also, beware of wolves along the way
00:52:07  <piscisaureus_>loladiro: https://gist.github.com/2879181
00:52:22  <piscisaureus_>loladiro: well, if you stack allocate them then it's probably fine
00:52:42  <piscisaureus_>loladiro: an uv_pipe_t is a couple of 100 bytes but stack space is sort of free
00:52:58  <loladiro>I suppose
00:53:01  <piscisaureus_>at worst, uv_pipe_init memsets the entire thing
00:53:17  <piscisaureus_>loladiro: I know - for a while I was worried about that too
00:54:00  <piscisaureus_>loladiro: but considering that spawn takes like 5 ms or so, I don't think setting a couple of bytes really matters
00:54:29  <loladiro>hmm good point
00:54:41  <piscisaureus_>loladiro: but if you have a better idea for a nice and clean api, then I am still open for it.
00:55:02  <piscisaureus_>loladiro: the alternative would be to just create raw OS handles
00:55:25  <piscisaureus_>and provide an API to turn that into a real libuv pipe
00:55:39  <piscisaureus_>that api exists, btw - uv_pipe_open
00:55:59  <piscisaureus_>the only downside is that it takes an fd which is not ideal on windows, but that is something that could be easily fixed
00:58:08  <loladiro>I'm rather reluctant to create raw fs handles outside of libuv (I have no problem passing them around though)
00:58:17  <loladiro>*fds
00:59:22  <piscisaureus_>yeah
00:59:32  <piscisaureus_>you'd also need uv_close_os_pipe(x)
00:59:34  <piscisaureus_>meh
01:00:38  <loladiro>I'm not sure what the best solution here is
01:02:30  * dapquit (Quit: Leaving.)
01:02:33  * mmalecki_joined
01:03:16  <piscisaureus_>loladiro: in the end it's just a matter of making a decision, and then do it
01:03:28  <piscisaureus_>and then stick to it until you know something better
01:03:51  <piscisaureus_>loladiro: so, were you planning to start working on it anytime soon? Like now, or tomorrow?
01:03:57  <loladiro>yeah
01:04:32  <loladiro>It's one of two things that's missing for libuv in Julia and the second thing kinda depends on this work to be done
01:05:36  * mmaleckiquit (Ping timeout: 256 seconds)
01:06:22  <isaacs>AvianFlu: simple/test-net-pipe-connect-errors fails on Linux in 0.6.18 as well, i'm not too worried about it
01:06:40  <isaacs>i'm also seeing test-dgram-broadcast-multi-process fail on 0.6.18 and 0.6.19 on CentOS
01:06:45  <AvianFlu>those weren't on linux
01:06:49  <AvianFlu>the ones I gisted
01:07:14  <piscisaureus_>loladiro: kewl. I suggest you do it the uv_pipe_link way. Feel free to adapt the api of you see any oversights, but try to keep it simple and consistent :-)
01:07:37  <loladiro>ok. I'll let you know
01:08:04  <isaacs>AvianFlu: oh, really?
01:08:17  <AvianFlu>no, I got a macbook since the last time I ran tests for y'all :D
01:08:25  <isaacs>AvianFlu: oh, that's mac
01:08:28  <isaacs>nice
01:08:28  <AvianFlu>I'm rebooting the linux laptop now
01:08:35  <AvianFlu>but regardless, 0.6.18 seems like it's behaving the same
01:08:40  <isaacs> /Users is the giveaway
01:08:43  <isaacs>instead of /home
01:08:46  <AvianFlu>yeah, generally
01:09:32  <piscisaureus_>loladiro: if you can manage, try to talk me a little earlier. I try to stop working during the night.
01:09:41  <isaacs>AvianFlu: hm, those pass for me on os x
01:09:53  <isaacs>i'm getting 0 failures on mac, actually, which is kind of odd and makes me afraid.
01:10:03  <piscisaureus_>ok, guys, I'm gone
01:10:05  <piscisaureus_>laterr
01:10:14  <AvianFlu>I'm on osx 10.7.4, and those fail the same on 0.6.18 and the 0.6.19 rc
01:10:23  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:10:25  <isaacs>kewl. yeah, it looks pretty good.
01:15:50  <isaacs>[01:15|% 100|+ 349|- 2]: Done
01:15:53  <isaacs>smartos ^
01:16:06  <isaacs>same 2 failures we always say, s/"rename"/"change"/ because apparently i cba to fix that test.
01:17:16  * dshaw_quit (Quit: Leaving.)
01:18:14  * loladiropart
01:18:40  <AvianFlu>isaacs, everything passed on linux except for message/stack_overflow, which isn't news either
01:19:07  <ryah>isaacs: RC0 on x64 linux - [20:30|% 100|+ 762|- 8]: Done
01:20:03  * mmalecki_quit (Quit: leaving)
01:20:57  <isaacs>ryah: wowzers.
01:21:03  <isaacs>ryah: what kind of linux?
01:21:10  <ryah>ubuntu
01:21:20  <isaacs>hm.
01:23:54  <ryah>https://gist.github.com/3a6718b7ad0a0ed1f33e
01:24:03  * dshaw_joined
01:25:32  <isaacs>hm. the debugger stuff is not terribly surprising, but the tls stuff worries me a little bit.
01:26:01  <mjr_>Poor TLS needs a lot of love.
01:27:48  <ryah>test/pummel/test-tls-ci-reneg-attack.js fails always
01:28:10  <ryah>both release and debug
01:28:35  <isaacs>yeah, that's what's worrying
01:28:39  <isaacs>it works on centos.
01:28:46  <isaacs>i'm spinning up an ubuntu drone now
01:29:50  <ryah>% openssl version
01:29:50  <ryah>OpenSSL 1.0.1 14 Mar 2012
01:30:13  <ryah>cutting edge!
01:30:31  <mjr_>woah
01:30:34  <mjr_>So modern.
01:30:54  <ryah>i just run aptitude update all day long now that i have so much free time :)
01:31:27  * isaacscompiling the universe
01:31:29  <mjr_>Hey, we figured out that openssl on our old Linux machines was using some kind of better x86 magic so all crypto operations ran faster there than they do on SmartOS.
01:31:31  <mjr_>sad face
01:31:55  <isaacs>mjr_: yeah, that's something you should get some joyent folks to fix.
01:32:06  <isaacs>mjr_: i think rmustacc was looking into it
01:32:28  <mjr_>Yeah, bmc told me that rmustacc was on it, but I'm not sure what the latest is.
01:32:30  <ryah>mjr_: AES instructions?
01:32:47  <isaacs>ryah: what do you have to apt-get to get openssl?
01:32:48  <mjr_>ryah: it seems to be ALL crypto ops.
01:32:57  <isaacs>ssl? ssl-dev? libssl-dev-headersopen++?
01:32:59  <AvianFlu>isaacs, libssl-dev I think
01:33:10  <mjr_>We use MD5 as part of our hash ring protocol, and MD5 is a lot faster right now on Linux than it is on SmartOS.
01:33:30  <isaacs>sweet, thanks
01:33:57  <mjr_>Anyway, I was surprised that it made such a big difference.
01:34:43  <ryah>mjr_: via openssl?
01:35:12  <mjr_>I can only assume that require("crypto").createHash("md5") uses openssl.
01:35:18  <mjr_>But I haven't verified.
01:35:18  <ryah>yeah
01:35:24  <isaacs>yeah, that would have to be it
01:35:41  <isaacs>mjr_: rm said that he'd verified
01:35:43  <tjfontaine>TooTallNate: does a Buffer.writeArray(type, arr) make sense?
01:36:28  <mjr_>ryah: but it's also the other crypto ops to make HTTPS work. It's just that those are harder to make a standalone load test for.
01:37:46  <TooTallNate>tjfontaine: i'm working on a ref-array module, which will implement C-array logic
01:38:03  <TooTallNate>similar to ref-struct
01:38:25  <tjfontaine>TooTallNate: ok, in the mean time is there a canonical way to do it?
01:38:57  <isaacs>hm
01:38:58  <isaacs>[01:31|% 100|+ 350|- 1]: Done
01:39:18  <isaacs>ryah: ^ that's on Linux 7527bd77-ab3e-474b-ace7-eed6053931e7 3.1.10joyent-ubuntu-10-opt #1 SMP Fri Jan 20 09:55:31 PST 2012 x86_64 GNU/Linux
01:39:21  <TooTallNate>tjfontaine: i mean, just "by hand". that is, create a Buffer instance with `numItems * typeSize` length
01:39:30  <tjfontaine>ok
01:39:31  <TooTallNate>and then write values to them at the correct offset
01:39:44  <TooTallNate>node-ffi actually does that in a couple places
01:39:52  <TooTallNate>cause I didn't want to wait for ref-array :p
01:40:03  <tjfontaine>hehe
01:40:54  * pieternjoined
01:40:55  * pieternquit (Client Quit)
01:44:12  * abraxasjoined
01:50:58  * dshaw_quit (Quit: Leaving.)
01:51:34  <bnoordhuis>isaacs, ryah: https://github.com/joyent/node/issues/3183
01:55:36  <isaacs>bnoordhuis: hooray, you have friends now :)
01:55:39  <isaacs>bnoordhuis: it's not just you
01:55:57  <isaacs>bnoordhuis: it looks like it's accurately detecting the reneg attack, it's just not throwing enough or something?
01:56:05  * vtjnashpart
01:56:09  <AvianFlu>interestingly, I see that failure too, on ubuntu, but not debian
01:57:02  <bnoordhuis>isaacs: i think it's because of a bug in the openssl cli tool
01:57:17  <isaacs>hm.
01:57:36  <isaacs>let's fix the test on v0.8, and call it a new feature.
01:57:40  <bnoordhuis>heh
01:58:12  <bnoordhuis>iirc if you hack the test and make it use s_client 1.0.1, it passes
01:58:19  <isaacs>interesting
01:58:25  <isaacs>anyway, i'm out. have a good night.
01:58:29  <isaacs>0.6.19 tomorrow morning
01:58:32  * ericktjoined
01:58:33  <bnoordhuis>you too, isaac
01:58:37  * isaacsquit (Remote host closed the connection)
02:08:37  * AvianFlupart ("Leaving")
02:10:48  * toothrquit (Read error: Connection reset by peer)
02:13:09  * toothrjoined
02:14:47  * TooTallNatequit (Ping timeout: 252 seconds)
02:27:15  <CIA-112>libuv: Ben Noordhuis master * r6fe7530 / src/uv-common.c : unix, windows: add debug mode handle printer - http://git.io/46OCQQ
02:29:11  * travis-cijoined
02:29:11  <travis-ci>[travis-ci] joyent/libuv#387 (master - 6fe7530 : Ben Noordhuis): The build is still failing.
02:29:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/24f8a53...6fe7530
02:29:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1542415
02:29:11  * travis-cipart
02:32:07  * brsonquit (Quit: leaving)
02:42:16  * loladirojoined
02:54:21  * loladiro_joined
02:54:38  * loladiro_quit (Client Quit)
02:54:47  * loladiro_joined
02:56:39  * loladiroquit (Ping timeout: 260 seconds)
02:57:11  * loladiro_quit (Client Quit)
02:57:20  * loladirojoined
03:04:10  * toothrquit (Read error: Connection reset by peer)
03:04:21  * c4milo__joined
03:04:55  * loladiro_joined
03:05:39  * \toothrotjoined
03:06:08  * saghul_joined
03:06:26  * c4milo___joined
03:06:30  * loladiroquit (Read error: Connection reset by peer)
03:06:30  * c4milo_quit (Read error: Connection reset by peer)
03:06:30  * saghulquit (Ping timeout: 260 seconds)
03:06:31  * c4miloquit (Read error: Connection reset by peer)
03:06:35  * saghul_changed nick to saghul
03:07:29  * \toothrotchanged nick to toothr
03:08:37  * brsonjoined
03:09:30  * c4milo___quit (Remote host closed the connection)
03:14:56  * iraquit (Quit: Leaving...)
03:19:26  * c4milo__quit (Remote host closed the connection)
03:20:06  * mikealjoined
03:21:44  <CIA-112>libuv: Ben Noordhuis master * r649ad50 / (include/uv-private/ev.h src/unix/core.c src/unix/ev/ev.c): unix: fix event loop stall - http://git.io/nuyLYQ
03:22:52  * mikealquit (Client Quit)
03:23:59  * travis-cijoined
03:23:59  <travis-ci>[travis-ci] joyent/libuv#388 (master - 649ad50 : Ben Noordhuis): The build is still failing.
03:23:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/6fe7530...649ad50
03:23:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1542647
03:23:59  * travis-cipart
03:27:38  * loladiro_quit (Remote host closed the connection)
03:32:35  <CIA-112>node: Ben Noordhuis master * r5f41140 / (5 files in 5 dirs): deps: upgrade libuv to 649ad50 - http://git.io/t2pOAg
03:32:36  <CIA-112>node: Joel Brandt master * rb9c5eee / src/node.h : add NODE_EXTERN to node::Start - http://git.io/nD_xPw
04:34:16  * mikealjoined
04:35:43  * mikealquit (Client Quit)
04:41:01  * abraxas_joined
04:41:39  * abraxasquit (Read error: Connection reset by peer)
04:47:34  * abraxas_quit (Remote host closed the connection)
04:48:08  * abraxasjoined
04:54:35  * loladirojoined
04:59:42  * ericktquit (Quit: erickt)
05:00:13  * abraxasquit (Remote host closed the connection)
05:02:01  * isaacsjoined
05:44:59  * dshaw_joined
05:48:15  * paddybyersjoined
06:30:58  * indexzerojoined
06:47:58  * stephankquit (Quit: *Poof!*)
06:49:09  * indexzeroquit (Quit: indexzero)
06:55:23  * rendarjoined
06:57:57  * mikealjoined
06:58:44  * loladiroquit (Ping timeout: 260 seconds)
06:59:00  * paddybyersquit (Quit: paddybyers)
07:00:53  * indexzerojoined
07:15:02  * indexzeroquit (Ping timeout: 244 seconds)
07:19:39  * indexzerojoined
07:24:26  * indexzeroquit (Client Quit)
07:48:33  * brsonquit (Quit: leaving)
08:02:34  * paddybyersjoined
09:00:17  * abraxasjoined
09:13:54  * bbenviejoined
09:14:58  * benviequit (Ping timeout: 245 seconds)
09:38:13  * isaacsquit (Remote host closed the connection)
09:51:27  * avalanche123quit (Ping timeout: 250 seconds)
09:55:16  * dshaw_quit (Quit: Leaving.)
11:03:51  * piscisaureus_joined
11:09:33  * mmaleckijoined
11:36:02  * piscisaureus_quit (Ping timeout: 248 seconds)
11:56:17  * irajoined
11:57:49  * ibcjoined
12:05:39  <ibc>hi, Makefile has these lines commented:
12:05:39  <ibc>#test-%: test/run-tests$(E)
12:05:39  <ibc> # test/run-tests $(@:test-%=%)
12:05:39  <ibc>why? I've descommented and used it to run a single test, it's useful.
12:35:20  * piscisaureus_joined
12:45:20  * mmalecki_joined
12:48:51  * mmaleckiquit (Ping timeout: 256 seconds)
12:50:52  * mmalecki_changed nick to mmalecki
13:13:24  * mmalecki_joined
13:16:44  * mmaleckiquit (Ping timeout: 260 seconds)
13:17:01  * abraxasquit (Remote host closed the connection)
13:17:09  * mmalecki_changed nick to mmalecki
13:18:44  * abraxasjoined
13:19:34  * abraxasquit (Remote host closed the connection)
13:21:49  * abraxasjoined
13:25:12  * abraxasquit (Remote host closed the connection)
13:45:01  * c4milojoined
13:46:18  * dshaw_joined
13:46:29  * mmaleckiquit (Quit: leaving)
13:48:14  * piscisaureus_quit (Ping timeout: 260 seconds)
13:53:20  * piscisaureus_joined
14:00:32  * iraquit (Quit: Leaving...)
14:04:31  * xaqjoined
14:08:30  * piscisaureus_quit (Ping timeout: 265 seconds)
14:35:36  * piscisaureus_joined
15:05:49  * bbenviequit
15:07:08  <bnoordhuis>you know what's odd? fs.symlink('foo', 'bar') works and is synchronous
15:07:28  <bnoordhuis>but then why have fs.symlinkSync?
15:07:29  * TheJHjoined
15:07:50  <bnoordhuis>looks like a bug to me
15:18:34  <creationix>bnoordhuis: are you sure it's sync? I get:
15:18:36  <creationix>fs.symlink("foo", "bar");fs.statSync("bar")
15:18:38  <creationix>Error: ENOENT, no such file or directory 'bar'
15:19:23  <creationix>nevermind
15:19:38  <creationix>it is sync, I just had to use lstat since the symlink was pointing to an invalid path
15:20:14  * ibcquit (Remote host closed the connection)
15:23:47  * dshaw_quit (Quit: Leaving.)
15:24:10  * TheJH_joined
15:27:31  * TheJHquit (Ping timeout: 252 seconds)
15:29:30  * TheJH__joined
15:30:47  * TheJH__changed nick to TheJH
15:31:06  * c4milo_joined
15:33:01  * TheJH_quit (Ping timeout: 252 seconds)
15:33:01  <piscisaureus_>huh
15:33:09  <piscisaureus_>so why is symlink synchronous in the first place?
15:33:48  * c4miloquit (Ping timeout: 260 seconds)
15:39:51  * avalanche123joined
15:49:39  * stephankjoined
15:53:38  * avalanche123quit (Ping timeout: 260 seconds)
15:55:26  * avalanche123joined
15:58:11  * dshaw_joined
16:07:45  <piscisaureus_>windows paths are so terrible
16:08:37  <piscisaureus_>isaacs: I am fixing the fs.exists('file/.') issue, but it requires me pushing path.resolve into libuv
16:08:57  <piscisaureus_>isaacs: super painful...
16:09:29  <piscisaureus_>ircretary: tell isaacs http://piscisaureus.no.de/libuv/2012-06-06#16:08:37.713
16:09:29  <ircretary>piscisaureus_: I'll be sure to tell isaacs
16:11:54  * isaacsjoined
16:12:51  <isaacs>piscisaureus_: feel free to mark that as a v0.9 thing
16:13:10  <piscisaureus_>isaacs: I will if it takes too long
16:13:17  <isaacs>piscisaureus_: it's seriously a very minor issue. afaict, the only real issue is that fs.exists is weird(er)
16:13:32  <isaacs>but i've been anti-path/fs.exists for over a year now
16:13:35  <piscisaureus_>isaacs: there's another issue
16:13:38  <isaacs>if it wasn't so entrenched, i'd cut it
16:13:44  <isaacs>orly?
16:13:45  <piscisaureus_>or rather, an inconsistency
16:13:56  <isaacs>a path inconsistency issue?
16:14:01  <isaacs>oh! lemme guess
16:14:07  <piscisaureus_>isaacs: suppose
16:14:08  <piscisaureus_>mkdir -p a/b
16:14:08  <piscisaureus_>ln -s a/b link
16:14:08  <piscisaureus_>ls link/..
16:14:20  <piscisaureus_>isaacs: which path should that list ?
16:14:24  <isaacs>oh, i was thinking that was a different thing
16:14:25  <isaacs>one sec
16:14:37  <isaacs>that should print out 'b'
16:14:42  <piscisaureus_>yes
16:14:46  <isaacs>since it'd be like ln a/b/..
16:14:47  <piscisaureus_>well, not on windows apparently
16:14:53  <isaacs>what does win do?
16:14:56  <piscisaureus_>windows seems to pre-normalize paths
16:15:06  <isaacs>oh...
16:15:12  <isaacs>so you ln .
16:15:12  <piscisaureus_>lemme try to be sure
16:15:14  <isaacs>er, ls .
16:15:26  <isaacs>yeah, that's a problem
16:15:34  <isaacs>but again, not a HUGE problem.
16:15:43  <isaacs>if it's hard, we can push it till post-v0.8
16:16:04  <piscisaureus_>isaacs: so the thing is, this is also what windows seems to always do
16:16:24  <piscisaureus_>isaacs: so I can change path resolution rules within node, but that might be very surprising for people
16:16:27  * ericktjoined
16:16:35  <piscisaureus_>well, not very, since they'll likely never notice
16:16:53  * creationixis a fan of pushing resolve to libuv, but just because of lazyness
16:17:09  * bulatshakirzyanojoined
16:19:18  <piscisaureus_>ok now it gets *really* weird
16:19:47  <piscisaureus_>windows: readdir \\\\?\\d:\\test\\sym\\link\\.. -> does the same as on unix
16:20:30  <piscisaureus_>readdir \\\\?\\d:\\test\\somedir\\.. -> ENOENT, since paths that start with \\?\ are not supposed to have .. resolved
16:20:33  <piscisaureus_>WTF
16:21:54  <isaacs>i think that history is quite clear on this point: the way that unix does paths is simple and correct, and the way that windows does paths is obtuse and unnecessarily retarded.
16:22:17  <isaacs>"that's how unix works" is always the best approach for path resolution stuff.
16:22:39  <isaacs>if someone's surprised, then they'll quickly come to love it. they'll be more surprised if their windows desktop and their linux server behave differently
16:23:11  <isaacs>windows has many fine features. but the path stuff is insane.
16:28:21  * dapjoined
16:29:08  <indutny>isaacs: not only that stuff
16:29:17  <indutny>isaacs: API is quite wierd too
16:29:20  <indutny>isaacs: and no fork()
16:29:30  <indutny>isaacs: actually, almost everything else is fine to me
16:30:32  <piscisaureus_>the path stuff is absolutely mind boggling
16:30:45  <piscisaureus_>I would say I know a lot about how it works on windows
16:31:07  <piscisaureus_>yet I discover new edge cases every time I have to deal with paths
16:31:39  <indutny>who is doing force pushes to master?
16:31:54  <piscisaureus_>indutny: node or libuv?
16:31:55  <indutny>it's not first time that I can't fast-forward my local repo
16:31:57  <indutny>piscisaureus_: node
16:32:01  <isaacs>indutny: that's weird.
16:32:10  <isaacs>i force-push to vX.Y.Z-release branches
16:32:11  <piscisaureus_>indutny: I don't know. But if you look at the logs, it'll show up easily
16:32:40  <isaacs>indutny: do you have local commits that are not on master?
16:32:48  <indutny>isaacs: well, I'm not sure now
16:32:52  <indutny>I just deleted my local branch
16:33:16  <piscisaureus_>indutny: http://piscisaureus.no.de/libuv/latest#03:32:36.231 was the last push
16:34:02  <piscisaureus_>indutny: but when I get fetch then it doesn't show a forced update
16:34:16  <indutny>hm..
16:34:17  <indutny>ok
16:34:35  <indutny>so ref/unref for process_wrap, right?
16:35:23  <indutny>piscisaureus_: ^
16:35:30  <piscisaureus_>indutny: yep
16:39:02  * mikealquit (Quit: Leaving.)
16:42:47  * mikealjoined
16:46:25  <isaacs>piscisaureus_: btw: https://github.com/isaacs/npm/commit/a41d0c91054cfa896ffb0a5366a30f206cfa2feb
16:46:25  <isaacs>piscisaureus_: i'll get that in for the next release (not 0.6.19)
16:46:45  <piscisaureus_>isaacs: ok
16:46:54  <piscisaureus_>isaacs: I think it was japj complaining about that :-)
16:46:56  <isaacs>speaking of which... test, please: http://nodejs.org/dist/v0.6.19/
16:47:09  <isaacs>ircretary: tell japj Re: Gubblebum font https://github.com/isaacs/npm/commit/a41d0c91054cfa896ffb0a5366a30f206cfa2feb
16:47:09  <ircretary>isaacs: I'll be sure to tell japj
16:47:12  * russfrankquit (Quit: leaving)
16:48:19  * AndreasMadsenjoined
16:48:29  * russfrankjoined
16:52:37  * dshaw_quit (Quit: Leaving.)
16:55:46  * dshaw_joined
16:55:51  * mikealquit (Quit: Leaving.)
16:57:05  <indutny>piscisaureus_: is there any reason for us to do not have: bool uv_is_active(uv_handle_t* handle)
16:57:12  <indutny>ah
16:57:14  <indutny>we have
16:57:15  <indutny>:D
16:57:16  <piscisaureus_>indutny: we have
16:57:25  <piscisaureus_>indutny: but it's int because bool is a c++ type
16:58:07  <indutny>ah well
16:58:14  <indutny>that's not what I actually want
16:58:21  <indutny>uv_is_reffed(...)
16:58:34  <indutny>i.e. the same as uv_is_active but for UV__HANDLE_REF flag
16:59:23  <CIA-112>node: isaacs v0.6 * re5d3ea7 / (249 files in 23 dirs): Upgrade npm to 1.1.24 - http://git.io/zwfwbg
16:59:23  <CIA-112>node: isaacs v0.6 * rdebf552 / (AUTHORS ChangeLog src/node_version.h): 2012.06.06 Version 0.6.19 (stable) - http://git.io/Yg_u6Q
16:59:24  <CIA-112>node: isaacs v0.6 * r79d77cf / (252 files in 25 dirs): Merge branch 'v0.6.19-release' into v0.6 - http://git.io/WsZQmA
16:59:26  <CIA-112>node: isaacs v0.6 * r1285cd9 / src/node_version.h : Now working on 0.6.20 - http://git.io/cfK_NQ
16:59:35  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
17:00:12  <indutny>piscisaureus_: what do you think?
17:00:35  <piscisaureus_>indutny: what do you need it for ?
17:01:28  <indutny>piscisaureus_: well, we have unref_ property for HandleWrap, which is used for active handles list: https://github.com/joyent/node/blob/master/src/node.cc#L1348
17:02:16  <indutny>piscisaureus_: and if I'll add HandleWrap::Ref method - I'll need to track `int ref_count`
17:02:23  <piscisaureus_>indutny: I will look later but I am in a call right now
17:02:39  <piscisaureus_>indutny: it takes some thought which is hard if you're trying to pay attention :-)
17:02:49  <indutny>hahaha
17:03:01  <indutny>looks like I've overlooked this issue anyway
17:03:04  <indutny>so nvm :P
17:03:29  * AndreasMadsenquit (Remote host closed the connection)
17:04:28  * AndreasMadsenjoined
17:08:28  <piscisaureus_>isaacs: release, cool
17:08:51  <piscisaureus_>isaacs: I am still running tests in the background but so far nothing funky showed up
17:08:58  <piscisaureus_>well, nothing unknown
17:09:05  <isaacs>yeah, i just went ahead with it
17:09:11  <isaacs>there's hardly anything new in this release anyway
17:09:16  * irajoined
17:09:23  <isaacs>few relatively minor edge-case bug fixes, and an npm update.
17:09:32  <isaacs>v0.6 is coming in for a landing.
17:10:32  * mikealjoined
17:13:17  * paddybyersquit (Quit: paddybyers)
17:16:27  * AndreasMadsenquit (Remote host closed the connection)
17:17:32  * theColejoined
17:18:37  * ericktquit (Quit: erickt)
17:21:46  <indutny>piscisaureus_: isaacs https://github.com/joyent/node/pull/3381
17:21:49  <indutny>bnoordhuis: ^
17:24:03  <isaacs>indutny: yeeeesssssss
17:24:46  <isaacs>indutny: not a lgtm, just like the feature :)
17:25:21  <isaacs>indutny: can you make a brief note about your child_process changes on https://github.com/joyent/node/wiki/API-changes-between-v0.6-and-v0.8 at some point?
17:25:33  <isaacs>indutny: in the "Added" section
17:26:34  <creationix>why would you unref a child process?
17:26:52  * ericktjoined
17:26:53  <creationix>though I've often wanted to be able to unref a setInterval
17:27:13  <creationix>"do something on an interval, but don't block exit"
17:28:17  <indutny>creationix: that's upcoming :P
17:28:44  <indutny>creationix: child_process.spawn('ping', ['nodejs.org']).unref()
17:31:00  <creationix>multi-process setInterval :P
17:31:19  <indutny>hahahahaha
17:36:18  * TooTallNatejoined
17:36:22  * AvianFlujoined
17:36:49  <indutny>piscisaureus_: creationix: timers can now be ref()/unref()
17:36:56  <indutny>piscisaureus_: what else should be updated?
17:37:01  <creationix>is it exposed to node?
17:37:05  <piscisaureus_>indutny: in node? that'd be cool
17:37:07  <indutny>AvianFlu: btw, https://github.com/joyent/node/pull/3381/files
17:37:15  <indutny>creationix: I think so
17:37:17  <indutny>piscisaureus_: yes
17:37:27  <indutny>that was very simple
17:37:28  <AvianFlu>awesome!
17:37:31  <AvianFlu>indutny, ++
17:37:31  <kohai>indutny has 25 beers
17:37:42  * loladirojoined
17:37:58  <indutny>piscisaureus_: does uv_ref/uv_unref works well with timers/
17:38:03  <indutny>piscisaureus_: cross-platform
17:38:08  <piscisaureus_>yes, why not
17:38:15  <indutny>ok
17:38:28  <indutny>I just heard that you or bnoordhuis was rewriting the
17:38:31  <indutny>s/the/them
17:39:22  * creationixis excited to update libuv into his *uv projects to get the ref refactor
17:39:30  <creationix>I think I'll do candor.io first
17:39:34  <creationix>maybe later this week
17:39:36  <indutny>creationix: haha
17:39:48  <indutny>creationix: well, we definitely need to take care about it in next weeks
17:39:58  <indutny>I'm still trying to make feature-ssa work in my spare time
17:40:01  <creationix>nodeconf ftw!
17:47:41  * mmaleckijoined
17:56:16  * mmaleckiquit (Quit: Reconnecting)
17:56:28  * mmaleckijoined
17:56:40  <isaacs>the tricky thing about ref/unref for timers/intervals in node is that setTimeout(fn, t) only creates a single uv timer for each unique value of t
17:56:59  <isaacs>so we'd have to do a bit of juggling to get that right
17:57:09  <isaacs>(that is, not for v0.8, maybe for later)
17:57:14  <isaacs>unless it's really really
17:57:20  <isaacs>*really easy
17:57:26  <isaacs>indutny, creationix^
18:03:21  * AndreasMadsenjoined
18:04:45  <creationix>isaacs: or we can document this behavior and leave the optimization in?
18:04:54  <piscisaureus_>indutny: I don't think timers are really being rewritten. If timer ref/unref works then that's great
18:05:03  <creationix>oh, you said t, not fn
18:05:09  <indutny>isaacs: hm...
18:05:12  <creationix>hmm, yeah, that could be dangerous
18:05:16  <indutny>that needs to be considered
18:05:25  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:05:33  <isaacs>i mean, we can do all that juggling in javascrit
18:05:42  <isaacs>but it just means it's a bit more involved, that's all
18:05:45  <creationix>right
18:05:54  <indutny>isaacs: well, I can do it
18:05:56  <isaacs>we just need to have one that's ref'ed, and one that is not ref'ed, and then move the cb over.
18:06:02  <indutny>just forgot that we're reusing timer_wraps
18:06:09  <isaacs>so the js timer object is attached to the unrefed timer
18:06:19  <isaacs>too late for that in v0.8
18:06:29  <isaacs>but it's a nice api cleanup we can do for 0.9 :)
18:06:32  <indutny>isaacs: Y R U SO COMPLX
18:06:36  <isaacs>:)
18:06:47  <indutny>ok
18:06:57  <indutny>but we can pull child.ref/unref stuff
18:07:01  <indutny>in 0.8.x
18:07:23  * brsonjoined
18:08:48  * piscisaureus_joined
18:09:33  * mikealquit (Quit: Leaving.)
18:15:07  * AndreasMadsenquit (Remote host closed the connection)
18:18:11  * AndreasMadsenjoined
18:21:27  <TooTallNate>hmmm...
18:21:29  <TooTallNate>> Buffer('hello', 'utf16le').toString('utf16le')
18:21:29  <TooTallNate>'he'
18:21:35  <TooTallNate>^ that doesn't seem right...
18:24:02  <igorzi>isaacs: hey, yt?
18:24:07  <isaacs>hi
18:24:26  <isaacs>indutny: sure, that looks pretty minimal, as long as no one else objects.
18:24:28  <igorzi>isaacs: it's not possible to require modules that are installed with --global, correct?
18:24:36  <isaacs>igorzi: yes, that is the design
18:24:43  <igorzi>isaacs: k, thx
18:24:49  <isaacs>igorzi: of course, you can set NODE_PATH or require('/full/path/to/global/thing')
18:24:57  <isaacs>igorzi: but really... just don't do that :)
18:30:30  <igorzi>isaacs: yep.. --global is just not meant for this.. if you want to require - install locally
18:33:18  * iraquit (Quit: Textual IRC Client: http://www.textualapp.com/)
18:44:12  * mmaleckiquit (Quit: Reconnecting)
18:44:20  * mmalecki_joined
18:47:53  <igorzi>isaacs: how does NODE_PATH work exactly?
18:48:08  <isaacs>igorzi: it's a :-separated set of paths to search for modules, after searching the node_modules folders as it does
18:48:13  <isaacs>igorzi: on windows it's ;-separated
18:48:30  * mmalecki_changed nick to mmalecki
18:48:43  <isaacs>but npm intentionally does not put its global modules in the default NODE_PATH, because you should not be using global modules that way
18:49:08  <igorzi>isaacs: yep, got it
18:53:04  * mmalecki_joined
18:55:59  * ibcjoined
18:56:15  * dshaw_quit (Quit: Leaving.)
18:56:34  * mmaleckiquit (Ping timeout: 265 seconds)
19:01:42  <igorzi>isaacs: what are the common use cases for NODE_PATH?
19:02:13  <isaacs>igorzi: it's just there for legacy purposes
19:02:31  <isaacs>igorzi: but if you were unhappy with localized modules and npm, you could write your own package manager to use it
19:02:53  <igorzi>isaacs: so, it would be an abuse to use it for sharing a module across several aps?
19:05:20  * piscisaureus_quit (Read error: Connection reset by peer)
19:05:43  <mjr_>We still use NODE_PATH, although increasingly I wish we didn't.
19:06:04  * piscisaureus_joined
19:08:37  <isaacs>igorzi: once npm link works in windows, i'd say yes.
19:08:54  <isaacs>igorzi: really,it's better to just create a node_modules folder, and work there.
19:09:24  <isaacs>igorzi: mkdir node_modules; cd node_modules; mkdir my-app; cd my-app; npm init; npm install blerg
19:09:46  <isaacs>but i mean, it's not the worst thing ever.
19:10:00  * `3rdEdenjoined
19:12:24  <bnoordhuis>https://github.com/bnoordhuis/node/commit/c381662 <- review? makes fs.symlink('a', 'b') async
19:12:52  <bnoordhuis>no test, i'm afraid - kind of hard to write for this
19:12:59  * `3rdEdenquit (Client Quit)
19:13:16  <TooTallNate>bnoordhuis: lgtm
19:13:25  <bnoordhuis>thanks
19:14:17  <bnoordhuis>something that kind of bugs me is that if you call the fs.* functions without a callback, they use a no-op function instead
19:14:32  <bnoordhuis>but that no-op function doesn't report errors, it just swallows them
19:15:39  <bnoordhuis>i'm to blame for that btw, i made it like that in 2010, when i didn't know any better :)
19:15:51  <TooTallNate>lol
19:15:59  <CIA-112>node: Ben Noordhuis master * rc381662 / lib/fs.js : fs: make fs.symlink() with no callback async - http://git.io/xtTTyg
19:16:04  <TooTallNate>bnoordhuis: where were do you think errors should go in that case?
19:16:05  * piscisaureus__joined
19:16:32  <bnoordhuis>TooTallNate: good question. simply throw?
19:16:47  <bnoordhuis>that's a rather big change in behavior
19:16:53  <TooTallNate>with domains, we could have a smart default there
19:17:01  * felixgejoined
19:17:02  * felixgequit (Changing host)
19:17:02  * felixgejoined
19:17:06  <TooTallNate>no callback -> throw errors on the current domain
19:17:13  <bnoordhuis>yes, something like that
19:17:23  <TooTallNate>and ya, simply throw otherwise
19:17:45  <TooTallNate>maybe for 0.9 :D
19:17:48  <bnoordhuis>heh, yeah
19:18:58  * piscisaureus_quit (Ping timeout: 260 seconds)
19:25:54  * piscisaureus___joined
19:28:53  * piscisaureus__quit (Ping timeout: 260 seconds)
19:29:27  * mmalecki_changed nick to mmalecki
19:33:50  * theColequit (Quit: theCole)
19:36:26  * loladiro_joined
19:38:03  * ibcquit (Remote host closed the connection)
19:39:23  * loladiroquit (Ping timeout: 260 seconds)
19:39:47  <bnoordhuis>https://github.com/bnoordhuis/node/commit/642b1a5 <- thoughts, opinions?
19:41:51  <TooTallNate>bnoordhuis: well i like the concept :D we shouldn't be leaking internals and confusing users like that, haha
19:42:11  <TooTallNate>the impl looks decent enough; haven't tried it yet though
19:42:27  <bnoordhuis>tests pass
19:42:35  <creationix>what's the performance overhead?
19:42:43  <bnoordhuis>zero, apparently
19:42:59  <bnoordhuis>that is, it's noise in the actually thread pool / syscall overhead
19:43:09  <creationix>fair enough
19:43:17  <bnoordhuis>-actually
19:43:24  <creationix>btw, I always thought it would be cool if event emitters were called in the "this" scope of the emitter
19:43:29  <bnoordhuis>they are
19:43:44  <creationix>since when?
19:43:45  <bnoordhuis>but the things in fs.js are by and large not eventemitters
19:43:58  <creationix>right, in that case a null scope is best
19:44:21  <creationix>though this is "undefined" in strict mode
19:44:27  <creationix>for plain functions
19:44:38  <creationix>having it be global is considered a bad thing
19:44:54  <bnoordhuis>so what should you use instead?
19:45:51  <creationix>can you use "this" instead of "global" on line 251
19:45:51  <creationix>or better, "null"
19:46:07  <bnoordhuis>oh, like that. sure
19:46:28  <creationix>yeah, "null" is best I think
19:46:34  * loladirojoined
19:46:44  <creationix>then non-strict functions will get global and strict functions will get undefined
19:48:06  <bnoordhuis>i assume this === undefined is to catch accidental global assignments?
19:48:30  <creationix>yep
19:48:43  * loladiro_quit (Ping timeout: 260 seconds)
19:48:50  <creationix>I'm sure crockford has some input on what went into strict mode
19:49:06  * igorziquit (Ping timeout: 245 seconds)
19:49:17  <bnoordhuis>TooTallNate: Try changing the String::New("Buffer") part to String::NewSymbol("Buffer"). Idk why, but that fixed some seg faults I was experiencing using similar code. <- that's... odd
19:49:36  <mjr_>isaacs: will --no_idle_notification ever make it into a release?
19:49:40  * mrb_bkquit (Remote host closed the connection)
19:49:44  * indutnyquit (Remote host closed the connection)
19:49:45  * Raynosquit (Read error: Connection reset by peer)
19:50:09  <bnoordhuis>mjr_: 0.8 :)
19:50:15  <isaacs>bnoordhuis: is it there already?
19:50:22  <mjr_>Oh, great.
19:50:35  <isaacs>mjr_: but yes, as bnoordhuis says, this is not a v0.6 feature
19:50:56  <mjr_>That's fine. Just wanted to make sure that went in, because it's very important for us.
19:51:26  <bnoordhuis>creationix, TooTallNate: https://github.com/bnoordhuis/node/commit/463d6ba <- updated
19:51:39  * mmaleckiquit (Quit: Reconnecting)
19:51:42  <bnoordhuis>isaacs: ^ like/dislike
19:52:38  * mmaleckijoined
19:52:38  * mmaleckiquit (Client Quit)
19:52:53  * mmaleckijoined
19:54:12  <isaacs>bnoordhuis: yeah, lgtm
19:54:29  <bnoordhuis>okay, thanks. landing
19:54:32  <isaacs>thanks
19:54:45  <CIA-112>node: Ben Noordhuis master * r463d6ba / (lib/fs.js test/simple/test-fs-stat.js): fs: make callbacks run in global context - http://git.io/vqojew
19:56:11  * mrb_bkjoined
19:57:48  <isaacs>piscisaureus___: on{x} is powered by node?
19:57:57  <piscisaureus___>isaacs: yep
19:58:07  <isaacs>neat. we were wondering that the other day at joyent
19:58:12  <isaacs>makes sense.
19:58:24  <isaacs>it's just using node on the server, or on the device as well?
19:58:27  <piscisaureus___>isaacs: and you were unable to find that out?
19:58:31  <piscisaureus___>isaacs: not on the device
19:58:36  <isaacs>piscisaureus___: well, we didn't look too hard :)
19:58:49  <piscisaureus___>isaacs: just kiddin
19:59:05  <piscisaureus___>isaacs: well it's a good use case for node, pushing stuff to the client
19:59:09  <piscisaureus___>and pushing logs back to the server
19:59:15  <isaacs>yep
19:59:17  <piscisaureus___>and then, back to the user's browser
19:59:18  <isaacs>totally
19:59:24  <isaacs>qv voxer, gather, etc.
19:59:36  <isaacs>it's basically what node is for :)
20:00:28  <piscisaureus___>isaacs: >curl -I https://www.onx.ms/ | grep Powered
20:04:34  <mjr_>We send a Server: header that proudly declares our use of node
20:04:45  <mjr_>curl -s -i https://one.voxer.com/ping
20:05:53  * `3rdEdenjoined
20:05:53  <piscisaureus___>mjr_: very good :-)
20:06:51  <isaacs>heh
20:07:01  <isaacs>i've alwasy stripped off Server headers
20:07:20  <isaacs>bad experience with ASP6 and PHP having easily sniffed vulnerabilities
20:07:39  <piscisaureus___>well, it shouldn't tell the version
20:07:39  <isaacs>res.setHeader('server', 'go fuck yourself')
20:07:51  <isaacs>true that
20:08:01  <piscisaureus___>actually, it's very obvious that onx uses node
20:08:09  <isaacs>the api looks pretty nodey
20:08:14  <mjr_>I just hate the term "powered by"
20:08:26  <piscisaureus___>also there are many headers that reveal the use of anode / farm
20:09:05  <mjr_>Powered by 3.3 volts DC.
20:09:56  <piscisaureus___>ghe
20:10:09  <piscisaureus___>x-powered-by: nukular power
20:10:27  <creationix>I'm either brave or dumb, try curl -I http://howtonode.org/
20:10:32  <mjr_>+1 on that spelling
20:10:41  <creationix>speaking of, I need to upgrade to 0.6.19
20:12:04  <piscisaureus___>C:\Users\Bert Belder>curl -I http://c9.io | grep -i server
20:12:04  <piscisaureus___>X-IDE-Server: fhemuwam.joyent.us:80
20:12:04  <piscisaureus___>server: Apache
20:12:07  <piscisaureus___>the shame
20:12:25  <creationix>how many layers of proxy is there?
20:12:25  <mjr_>How do you live with yourself.
20:12:37  <piscisaureus___>creationix: it's just the wordpress frontend
20:12:41  <creationix>true
20:13:51  <creationix>luvit.io is Server: Luvit :)
20:14:01  <creationix>though you'll get a 404 on HEAD requests because my router sucks
20:14:45  <mjr_>We 404 HEAD as well. HEAD has no value for us, at least right now.
20:15:44  <piscisaureus___>creationix: you wanna have fun? http://hello.piscisaureus.c9.io/
20:18:30  * AndreasMadsenquit (Remote host closed the connection)
20:18:49  * `3rdEdenquit (Quit: Leaving...)
20:23:43  <pquerna>EIO_STACKSIZE, any reason to not drop it down to 64kb?
20:23:58  * mmalecki_joined
20:25:11  <piscisaureus___>pquerna: uv_queue_work ?
20:25:16  <creationix>piscisaureus___: heh, didn't know about X-IDE-Server, that's handy
20:26:07  <piscisaureus___>creationix: oh, I think they added that recently
20:26:11  <piscisaureus___>for debugging etc
20:26:23  <piscisaureus___>so you know which logs to search when something blows up
20:26:43  <creationix>so if I create a repl on some tcp port, it will be available on that IP?
20:26:50  * mmaleckiquit (Ping timeout: 252 seconds)
20:27:02  * TheJHquit (Read error: Operation timed out)
20:28:15  <piscisaureus___>creationix: ehh, you mean on hosted?
20:28:30  <piscisaureus___>creationix: well sure, but you can't spawn and you only have one port
20:28:44  <piscisaureus___>so much for the repl
20:28:52  <pquerna>piscisaureus___: use, it works... as long as the work cb doesn't do something massive on the stack :) ?
20:29:45  * indutnyjoined
20:30:16  * dshaw_joined
20:30:50  <piscisaureus___>pquerna: I see what you mean... but I am afraid of randomly breaking code
20:30:58  <piscisaureus___>pquerna: are you having memory issues?
20:31:03  <pquerna>piscisaureus___: just trying to push memory use down
20:31:21  <pquerna>we are at about 5mb in our luvit-based-agent
20:31:27  <piscisaureus___>pquerna: I mean, if you don't actually *use* more than 64kb stack space it won't be committed either
20:31:33  <bnoordhuis>pquerna: is that actually an issue?
20:31:36  <bnoordhuis>what piscisaureus___ said
20:31:37  <pquerna>killing the eio threads down should get 512kb off ish
20:31:57  <piscisaureus___>maybe we can just reduce initial stack commit
20:32:03  <piscisaureus___>is that possible with pthreads?
20:32:05  <pquerna>no
20:32:11  <pquerna>it can only be done at thread creation time
20:32:16  <piscisaureus___>sure
20:32:31  <piscisaureus___>but we can do that at stack creation time
20:33:34  <bnoordhuis>pquerna: how would smaller stacks help you? it's only virtual memory, not rss
20:33:35  * mmalecki_changed nick to mmalecki
20:33:51  <pquerna>mmm, true
20:34:33  * paddybyersjoined
20:34:47  * perezdjoined
20:35:57  <piscisaureus___>that's what I meant to say
20:36:02  <piscisaureus___>bnoordhuis has the words
20:36:07  <pquerna>:)
20:36:08  <bnoordhuis>and the moves
20:37:02  <piscisaureus___>pquerna: I think you might have more luck tweaking the v8 garbage collector
20:37:16  <bnoordhuis>in luvit?
20:37:23  <piscisaureus___>oh, heh
20:37:43  <pquerna>i'm playing with massif now
20:37:47  <piscisaureus___>yeah, in my mind Cloudkick is still a node company
20:37:56  <pquerna>we use all node server side :)
20:37:56  <piscisaureus___>Unfortunately they were lost to the texans
20:38:28  <bnoordhuis>pquerna: i know a band called massif but that's probably not what you mean
20:38:50  <pquerna>heap profiler in valgrind
20:38:56  <piscisaureus___>massif is part of valgrind, no ?
20:38:58  <bnoordhuis>oh, that massif
20:40:29  <pquerna>like ares_init_options mallocs 76kb, nice.
20:40:56  * Raynosjoined
20:41:40  <bnoordhuis>yes, i've seen that
20:41:44  <pquerna>https://gist.github.com/451b66191183593fbf40
20:41:46  <bnoordhuis>i don't pretend to understand why though
20:42:02  <pquerna>#define ARES_QID_TABLE_SIZE 2048 struct list_node queries_by_qid[ARES_QID_TABLE_SIZE];
20:42:26  <tjfontaine>only 2048 requests are allowed in flight, it's statically allocd
20:42:34  <pquerna>is a decent part of it, ares_channeldata
20:42:39  <pquerna>ares_channeldata is just a beast :-/
20:43:36  <bnoordhuis>right, that's almost 50k on x64
20:44:07  <TooTallNate>bnoordhuis: ya, that String::NewSymbol() thing is weird. First reported to me here: https://github.com/rbranson/node-ffi/issues/48
20:46:15  <bnoordhuis>TooTallNate: Handle<Value> constructorArgs[3] = { slowBuffer->handle_, Integer::New(sz), Integer::New(0) }; <- use Local<Value> constructorArgs[3] there
20:46:37  <bnoordhuis>i fixed a similar issue a while ago in node, where objects weren't properly rooted in a handlescope
20:46:50  <TooTallNate>oh interesting
20:47:00  * mmaleckiquit (Ping timeout: 252 seconds)
20:47:18  <TooTallNate>seems anyone following this thread will run into it :\ http://sambro.is-super-awesome.com/2011/03/03/creating-a-proper-buffer-in-a-node-c-addon/
20:47:27  <bnoordhuis>ah, that guy
20:47:37  <TooTallNate>lol
20:47:43  * mmaleckijoined
20:49:14  * mmaleckiquit (Client Quit)
21:10:13  * igorzijoined
21:12:43  * ibcjoined
21:14:55  * irajoined
21:17:39  * theColejoined
21:30:00  * paddybyersquit (Quit: paddybyers)
21:35:48  * philipsquit (Read error: Operation timed out)
21:36:24  * philipsjoined
21:37:36  * felixgequit (Quit: felixge)
21:37:41  <piscisaureus___>is there something like ragel for regular expressions?
21:37:53  <piscisaureus___>like I give it a regexp, it generates c code?
21:39:22  <isaacs>piscisaureus___: that'd be handy
21:39:37  <piscisaureus___>yeah, very much
21:39:41  <piscisaureus___>v8 has a regexp compiler
21:39:48  <piscisaureus___>now if would generate c instead of assembler :-p
21:45:30  * rendarquit
21:48:41  <bnoordhuis>piscisaureus___: what is ragel if not a regex derived code generator?
21:48:57  <piscisaureus___>sure
21:49:19  <bnoordhuis>i assume you mean regular expressions as in js regexes?
21:49:30  <piscisaureus___>let's say it's just a little too heavyweight for my use case
21:49:36  <piscisaureus___>bnoordhuis: well, just some static regix
21:49:39  <piscisaureus___>*regex
21:49:39  * theColequit (Quit: theCole)
21:51:31  <bnoordhuis>piscisaureus___: when a handle gets closed, how does uv-win make sure that all associated reqs get cleaned up?
21:51:56  <bnoordhuis>for example, when i close a tcp handle
21:52:01  <piscisaureus___>bnoordhuis: let's say I need to convert this to C
21:52:01  <piscisaureus___>/^([\\\/]\?\?[\\\/]+|[\\\/]{2}[?.][\\\/])([a-zA-Z]:|[\\\/]{2}[^\\\/]+[\\\/][^\\\/]+)?([\\\/])?([\s\S]*?)$/
21:52:15  <tjfontaine>linking to libpcre it is!
21:52:17  <bnoordhuis>how does it make sure that all connect/shutdown/write req cbs are run?
21:52:38  <piscisaureus___>bnoordhuis: if you close a socket or handle, all the overlapped reqs are automatically cancelled
21:52:44  <piscisaureus___>and they come back
21:53:06  <bnoordhuis>ah, that's very convenient
21:53:13  <piscisaureus___>bnoordhuis: an libuv just waits until they've all been returned by the iocp before making the close callback
21:53:26  <bnoordhuis>too bad that doesn't work on uv-unix :/
21:53:46  <piscisaureus___>bnoordhuis: I think only uv_shutdown_t doesn't work that way (because it's not overlapped) so I have specific cancellation code in uv_tcp_endgame
21:53:48  * pieternjoined
21:53:57  <piscisaureus___>bnoordhuis: huh? You don't have overlapped operations, right?
21:54:09  <piscisaureus___>bnoordhuis: you can just walk all the pending reqs and make their callbacks
21:54:10  * paddybyersjoined
21:54:10  <bnoordhuis>piscisaureus___: https://github.com/joyent/libuv/pull/449
21:54:39  <bnoordhuis>piscisaureus___: the thing is that i would've liked for this to somehow fall out of the grand design
21:54:48  <piscisaureus___>haha
21:54:58  <piscisaureus___>bnoordhuis: It seems that you should have just one big queue
21:55:20  <ryah>piscisaureus___: do it by hand :)
21:55:20  <piscisaureus___>e.g. uv_write_t, uv_connect_t, uv_shotdown_t are all in some list attached on the handle
21:55:30  <piscisaureus___>ryah: yeah I was doing that :-(
21:55:32  <ryah>(the regex)
21:55:49  <bnoordhuis>piscisaureus___: yeah, i guess that's the best / easiest solution
21:56:05  <piscisaureus___>bnoordhuis: I'd like that as well, so we could even put it in uv.h
21:56:12  <bnoordhuis>cool
21:56:19  <piscisaureus___>bnoordhuis: because to make it queue up writes while connecting we need something like that
21:56:31  <piscisaureus___>because the windows kernel rejects writes when we're still connecting
21:56:44  <piscisaureus___>it's also needed for proper writev support for pipes
21:56:54  <piscisaureus___>(-> supplying > 1 uv_buf_t)
22:02:33  <CIA-112>node: isaacs v0.6 * rf9abf5e / Makefile : build: Prevent duplication of doc/api folder - http://git.io/u5-9hw
22:02:58  <CIA-112>node: isaacs master * rc45522d / Makefile : build: Prevent duplication of doc/api folder - http://git.io/_1sdCw
22:05:59  <piscisaureus___>isaacs: I'm not going to do unix-style symlink resolution. It could be done ... but I think it's not okay to deviate from the path resolution rules that the OS uses
22:06:31  <bnoordhuis>ryah: what've you been up to lately?
22:07:00  <piscisaureus___>Het is Def Rhymz en geen Hennie Huisman
22:07:29  <CIA-112>libuv: Iñaki Baz Castillo master * rb47af98 / (3 files in 2 dirs): test: add tcp 'close on failed connect' test - http://git.io/7hpJSg
22:09:06  <bnoordhuis>http://lwn.net/Articles/500482 <- gentoo x32 release candidate
22:09:09  <bnoordhuis>damn, they fast
22:09:19  <ryah>bnoordhuis: strengthening my substance addictions
22:09:32  <bnoordhuis>want tips?
22:10:06  <bnoordhuis>you know you're a geek when a new kernel abi makes you feel all tingly
22:10:25  <ryah>have children? :)
22:11:14  <ryah>bnoordhuis: how do i set the TIME_WAIT in linux?
22:12:46  <bnoordhuis>ryah: you mean the length of the TIME_WAIT period?
22:13:33  * paddybyersquit (Quit: paddybyers)
22:14:25  <ryah>bnoordhuis: yeah
22:15:33  <tjfontaine>/proc/sys/net/ipv4/tcp_fin_timeout I think
22:16:00  <tjfontaine>or somewhere around there
22:16:13  <bnoordhuis>ryah: sysctl -a | grep tcp_tw_re
22:16:17  <piscisaureus___>I wish it stopped raining
22:16:31  <bnoordhuis>it's not raining here
22:16:34  <bnoordhuis>go gouda
22:16:51  <isaacs>piscisaureus___: that's a fair position i suppose.
22:17:03  <bnoordhuis>ryah: there's also tcp_max_tw_buckets btw
22:17:06  * piscisaureus___changed nick to piscisaureus
22:18:29  <ibc>"Do not be confused by the /proc/sys/net/ipv4/tcp_fin_timeout config item. The FIN TIMEOUT is not the same as the TIMEWAIT length."
22:18:30  <isaacs>*finally* pulled that backwards idiotic logger out of npm and into it's own module.
22:18:52  <isaacs>ryah: still no progress bars. that's not worth how screwey it is to manage.
22:18:59  <tjfontaine>ibc: hey the knob is in there somewhere
22:19:39  <ibc>I found that some time ago in this link, it also explains how to reuse the TIME_WAIT buckets: http://www.stolk.org/debian/timewait.html
22:19:40  * c4milo_quit (Remote host closed the connection)
22:20:03  <piscisaureus>Heh, about tw_buckets: You should not lower this limit artificially. If you start receiving errors indicating this problem in normal operation, you should instead increase this value if your network requires so. This may lead to the requirement of more memory installed in the machine in question.
22:20:08  <bnoordhuis>tinkering with TIME_WAIT durations is not a super great idea btw
22:20:17  * c4milojoined
22:20:40  * isaacsquit (Remote host closed the connection)
22:20:41  <piscisaureus>I think you want tcp_tw_recycle
22:21:20  <piscisaureus>or tcp_tw_reuse
22:21:22  <piscisaureus>ghe
22:23:19  <piscisaureus>tcp_tw_recycle - BOOLEAN
22:23:19  <piscisaureus>Enable fast recycling TIME-WAIT sockets. Default value is 0. It should not be changed without advice/request of technical experts.
22:23:19  <piscisaureus>tcp_tw_reuse - BOOLEAN
22:23:19  <piscisaureus>Allow to reuse TIME-WAIT sockets for new connections when it is safe from protocol viewpoint. Default value is 0. It should not be changed without advice/request of technical experts.
22:23:22  <piscisaureus>very confusing
22:23:52  <bnoordhuis>piscisaureus: what is?
22:24:09  <piscisaureus>well, why is there no way to just lower the TIME_WAIT period :-)
22:24:35  <bnoordhuis>piscisaureus: because it's not that simple :)
22:24:42  <ryah>whatever, what settings do you use for benching http_simple.js ?
22:24:53  * c4miloquit (Ping timeout: 246 seconds)
22:25:08  <ryah>echo "49152 65535" > /proc/sys/net/ipv4/ip_local_port_range
22:25:09  <ryah>echo "2" > /proc/sys/net/ipv4/tcp_fin_timeout
22:25:13  <ryah>^-- seems reasonable
22:25:14  <ryah>?
22:25:46  <bnoordhuis>the only thing i've changed is net.ipv4.ip_local_port_range to 32768-61000
22:26:09  <bnoordhuis>don't remember why i picked 61000 as the upper limit though
22:26:19  <ryah>k
22:29:35  <bnoordhuis>sizeof(ngx_queue_t) = 16 :(
22:29:35  * ibcquit (Remote host closed the connection)
22:29:51  <bnoordhuis>x32 is going to help there though
22:30:22  <bnoordhuis>but i sure would like a fat free-er alternative for x64
22:31:27  <ryah>https://gist.github.com/8013f2fcd3d7f7a4c229 <-- :(
22:32:29  <bnoordhuis>ryah: try bytes/1024 or bigger
22:32:38  <ryah>ok
22:32:40  <bnoordhuis>strings are supposed to be a lot faster now
22:34:01  <piscisaureus>you should try unicode/1024 :-)
22:34:12  <piscisaureus>oh wait that bench isn't in 0.6 I suppose
22:35:16  <bnoordhuis>he's testing 0.7.9 right?
22:35:30  <piscisaureus>bnoordhuis: yeah but there's not much to compare to
22:35:38  <piscisaureus>we should backport unicode/ to b0.6
22:35:40  <bnoordhuis>oh, compared to 0.6.18
22:36:04  <bnoordhuis>piscisaureus: yes, back-port it :)
22:36:09  <ryah>bnoordhuis: updated with 1024 https://gist.github.com/8013f2fcd3d7f7a4c229
22:36:29  <bnoordhuis>that can't be right
22:36:37  <piscisaureus>I wonder how bytes/123 got slower
22:36:47  <bnoordhuis>unless we had a major performance regression in the last 2 or 3 weeks
22:36:50  <piscisaureus>when I was doing the string work it got faster
22:36:53  <piscisaureus>yeah, weird
22:37:15  <bnoordhuis>ryah: open an issue and assign it to me
22:37:48  <bnoordhuis>if it turns out to be a problem with your local setup, i'll have you buying the beers for the foreseeable future though
22:37:50  <ryah>http://arlolra.no.de/bench/ab-hello-world-buffer-1024/#!/master/linux32
22:38:56  <bnoordhuis>Fix #3270 Escape url.parse delims Rather than omitting them. <- wut?
22:39:58  <bnoordhuis>ryah: what happens if you revert 9fc7283a403bb0dec096b76991226cba8e7b73c2 in master?
22:40:51  <ryah>bnoordhuis: https://github.com/joyent/node/issues/3383
22:40:59  <piscisaureus>somewhere in the range of 4099d1eeba...9fc7283a40
22:41:08  <bnoordhuis>ryah: thanks
22:41:08  <piscisaureus>could also be v8 3.11.1
22:41:15  <bnoordhuis>yeah, that wouldn't surprise me
22:41:49  <ryah>reverting that doesn't help
22:42:29  <bnoordhuis>i guess some profiling with gprof/valgrind/v8 is called for
22:42:46  <piscisaureus>what about
22:42:46  <piscisaureus>rm -rf deps/v8 && git checkout 3f3f958c~1 -- deps/v8
22:44:51  <ryah>on the other hand, it's nice to see v0.6.18 running so fast :)
22:44:59  <ryah>8k/sec is pretty good
22:45:25  <ryah>piscisaureus: checking...
22:47:11  <ryah>piscisaureus: yes, that improves it greatly
22:47:29  <ryah>it's now almost on par with v0.6
22:48:15  <bnoordhuis>guess we need to write our own vm...
22:49:58  <ryah>what does v8 3.10 introduce?
22:50:11  <bnoordhuis>piscisaureus: do we or have we ever promised anything about the order req cbs are invoked?
22:50:28  <bnoordhuis>piscisaureus: i.e. connect reqs first, write reqs second, shutdown reqs last?
22:50:32  <piscisaureus>bnoordhuis: no... but it's not really nice to process them out of order
22:50:40  <bnoordhuis>yeah, i kind of agree...
22:50:46  <piscisaureus>bnoordhuis: but windows actually does write reqs out of order
22:50:52  <bnoordhuis>ryah: lots of bugs, mostly
22:50:54  <piscisaureus>pietern did a patch that fixes it at some point
22:51:10  <piscisaureus>but he didn't get the cla through the vmware legal dept I believe
22:51:19  <pietern>:(
22:51:20  <bnoordhuis>i remember that
22:51:25  <bnoordhuis>talk about the devil
22:51:30  <pietern>;)
22:51:38  * ryahaway
22:51:55  <piscisaureus>bnoordhuis: but if you just keep the req queue in order, then it's easy to make the callbacks in order too right?
22:52:20  <bnoordhuis>piscisaureus: oh, sure. i was considering the case of queuing a shutdown req, then one or more write reqs
22:52:33  * isaacs_mobilejoined
22:52:39  <bnoordhuis>i guess people who do that get what they deserve
22:52:40  <piscisaureus>bnoordhuis: well, you should just reject write reqs synchronously when the socket is shut
22:52:49  <piscisaureus>(or shutting)
22:53:32  <bnoordhuis>hrm
22:53:53  <piscisaureus>bnoordhuis: also, it makes more sense to make CBs in the order that requests are queued
22:54:02  <piscisaureus>than to follow connect...write...shut strictly
22:54:14  <bnoordhuis>yeah, i can live with that
22:54:27  <bnoordhuis>but rejecting write reqs seems kind of wrong
22:54:43  <bnoordhuis>though i guess it's a lifecycle issue
22:54:44  <piscisaureus>bnoordhuis: well, otherwise we should fail with UV_ESHUTDOWN
22:54:59  <piscisaureus>bnoordhuis: that's what uv-win does atm anyway
22:55:19  <piscisaureus>bnoordhuis: also, when a write is done before a connect is posted, it is also rejected
22:55:36  <bnoordhuis>uv-unix handles that better :)
22:55:42  <piscisaureus>I don't agree
22:56:00  <bnoordhuis>it's okay to disagree with me
22:56:03  <bnoordhuis>but only when you're wrong
22:56:07  <tjfontaine>heh
22:56:13  <piscisaureus>the abstraction should just be that reqs queued and handled background
22:56:34  <piscisaureus>that doesn't give you a free card to just do stuff in random order
22:57:06  <bnoordhuis>it kind of makes sense though
22:57:13  <bnoordhuis>suppose you're about to make a http request
22:57:23  <bnoordhuis>you already know what you're going to write
22:57:26  * loladiroquit (Ping timeout: 246 seconds)
22:58:28  <piscisaureus>ok, I think I might agree with that
22:58:51  <piscisaureus>bnoordhuis: but I'd like write reqs to return an error status when connect fails
22:59:11  <piscisaureus>basically we should say "hey, we couldn't connect to your host, so we couldn't deliver your data"
22:59:11  <bnoordhuis>that's what happens now (with uv-unix)
22:59:34  <piscisaureus>ok, that's cool
22:59:38  <piscisaureus>but for shutdown
22:59:40  <bnoordhuis>though it's UV_EINTR, not UV_ECONNREFUSED
22:59:48  <piscisaureus>ah, right
22:59:55  <bnoordhuis>UV_EINTR is kind of a lame name...
22:59:57  <piscisaureus>that's debatable, I don't have a strong opinion on the matter
22:59:59  <piscisaureus>yes
23:00:02  <piscisaureus>make it UV_ECANCELLED
23:00:26  <piscisaureus>bnoordhuis: but writing after shutdown should definitely not be allowed
23:00:38  <piscisaureus>if it would, it would basically be a race condition
23:00:54  <bnoordhuis>hrr... there's a posix ECANCELED error code and it's quite unrelated
23:01:15  <bnoordhuis>re write after shutdown, yes, i agree
23:01:16  <piscisaureus>bnoordhuis: whatever
23:01:18  <piscisaureus>EABORTED
23:01:24  <bnoordhuis>ENOCANDO
23:01:41  <bnoordhuis>EIMSORRYDAVE
23:01:47  <piscisaureus>EGFY
23:02:01  <mjr_>I still have a scar from the ECONNABORTED migration disaster.
23:02:14  <piscisaureus>huh, how?
23:02:23  <piscisaureus>oh, that we turn it into ECONNRESET?
23:02:26  <mjr_>So Linux doesn't have that error, but SmartOS does.
23:02:34  <mjr_>And BSD too, I guess.
23:02:38  <piscisaureus>well, I suppose linux has it too
23:02:45  <bnoordhuis>it does
23:02:51  <piscisaureus>but it's reported under different circumstances
23:02:55  <mjr_>Right
23:03:08  <piscisaureus>but I think we turn all ECONNABORTED into ECONNRESET now
23:03:10  * isaacs_mobilequit (Remote host closed the connection)
23:03:29  <mjr_>Anyway, it sucked a lot, because suddenly this new error was showing up, and we couldn't figure out why. It caused a huge cascading failure of the entire operation.
23:03:39  <mjr_>Good story though
23:03:44  <piscisaureus>yeah
23:03:52  <piscisaureus>morale: use linux :-p
23:03:59  <bnoordhuis>we didn't introduce that in a 0.6.x release though, did we?
23:04:17  <bnoordhuis>oh, this is about the move from linux to smartos?
23:04:47  <mjr_>Yeah, Linux doesn't do aborted if the TCP client drops out while still in the server socket accept queue.
23:04:50  <piscisaureus>8409a67 unix: ignore ECONNABORTED errors from accept()
23:05:03  <mjr_>But BSD/Solaris do
23:05:22  <piscisaureus>so I suppose we don't actually always turn ECONNABORTED into ECONNRESET
23:05:23  <mjr_>The real lesson is this: never change operating systems.
23:05:26  <piscisaureus>just in the case of accept)
23:05:36  <bnoordhuis>mjr_: quite right :)
23:05:44  <bnoordhuis>ECONNABORTED is a silly error anyway
23:05:50  <mjr_>I know, kind of pointless.
23:06:17  <piscisaureus>well, I don't agree
23:06:18  <mjr_>However, now that we are all moved over, the DTrace and mdb stuff on SmartOS is truly amazing.
23:06:40  <bnoordhuis>mjr_: just wait until i'm finished with the systemtap integration :)
23:06:46  <bnoordhuis>what are you getting out of mdb though?
23:07:05  <mjr_>mdb is how you get heap inspection from a core dump
23:07:18  <mjr_>Which you can take without killing the process
23:07:29  <bnoordhuis>ah, right. dap wrote that, didn't he?
23:07:35  <mjr_>Yes he did.
23:07:39  * isaacsjoined
23:07:41  <bnoordhuis>yeah, that's a nice feature
23:07:45  <mjr_>With some help, of course.
23:07:55  <bnoordhuis>not sunos-specific though
23:08:09  <mjr_>Happens to only work there right now, for various reasons.
23:08:17  <bnoordhuis>that particular implementation is, of course
23:08:31  <bnoordhuis>but i have a bunch of gdb python scripts that do something similar
23:09:15  <bnoordhuis>which reminds me that we need some kind of heap inspection / snapshotting in node
23:10:00  <piscisaureus>which reminds me that we should add some sort of signal to enable --prof
23:10:24  <bnoordhuis>enabling/disabling the profiler at runtime doesn't work all that great right now
23:10:29  <piscisaureus>bnoordhuis: how so?
23:10:30  <bnoordhuis>hasn't since 0.6.0 really
23:10:38  <bnoordhuis>piscisaureus: well, for one it doesn't work :)
23:10:58  <mjr_>IMO it doesn't even work after you enable it either
23:11:07  <piscisaureus>well
23:11:12  <piscisaureus>the tick processor isn't great
23:11:22  <mjr_>It is better than absolutely nothing, which is the alternative in most places.
23:11:25  <piscisaureus>but in theory the logs have enough information to the same trick as this dtrace thing does
23:11:36  <mjr_>I'm not sure that this is true.
23:11:56  <piscisaureus>mjr_: why not?
23:12:16  <mjr_>I've spent a lot of time with the V8 profiler, and I don't think it collects data when it needs to, like it misses samples or something
23:12:29  <bnoordhuis>that's true
23:12:30  <piscisaureus>mjr_: well, samples missing is sort of expected
23:12:40  <mjr_>Sure, SOME missing samples I'd expect
23:12:42  <piscisaureus>mjr_: but it shouldn't miss code generations / moves
23:12:50  <mjr_>But the data seems completely wrong sometimes.
23:13:04  <mjr_>Like it seems to miss huge chunks of execution time.
23:13:30  <mjr_>I haven't tried on the latest V8, so maybe they've fixed this by now.
23:13:33  <piscisaureus>huge, as in, seconds ?
23:13:53  <mjr_>Yes, huge as in the actual place the program is spending its time often doesn't show up.
23:14:15  <bnoordhuis>i've never seen that happen, i think
23:14:22  <bnoordhuis>on linux, anyway
23:14:42  <mjr_>I've found the results to be so confused that it's simply not worth using. Adding explicit checkpoints and comparing the data later shows very different results.
23:14:45  <mjr_>This was all on Linux.
23:14:47  <piscisaureus>I suppose we could increase the resolution a little
23:14:51  <piscisaureus>when the profiler is running
23:15:17  <mjr_>By explicit checkpoints, I mean having the program do Date.now() a lot and subtract.
23:16:47  <mjr_>I was mostly trying to make node_redis faster, so perhaps the specific workload matters.
23:18:09  <piscisaureus>ok. The rainwash stopped. I am going home.
23:18:23  <piscisaureus>And so are the americans
23:24:34  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:24:37  * mikealjoined
23:34:29  * xaqquit (Remote host closed the connection)
23:36:23  * c4milojoined
23:40:01  * loladirojoined
23:49:37  * travis-cijoined
23:49:38  <travis-ci>[travis-ci] joyent/libuv#389 (master - b47af98 : Iñaki Baz Castillo): The build is still failing.
23:49:38  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/649ad50...b47af98
23:49:38  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1552361
23:49:38  * travis-cipart
23:50:28  * piscisaureus_joined
23:54:36  * mjr_quit (Quit: mjr_)
23:56:29  * isaacsquit (Remote host closed the connection)
23:57:18  * isaacsjoined