00:08:09  * hij1nxjoined
00:14:37  * loladirojoined
00:15:08  * paddybyersquit (Quit: paddybyers)
00:26:36  <loladiro>bnoordhuis: Can I get your opinion on libuv #400? It's blocking the Julia build on CentOS right now
00:27:09  <bnoordhuis>loladiro: i am actually commenting on it right now :)
00:27:19  <bnoordhuis>loladiro: https://github.com/joyent/libuv/issues/400#issuecomment-5451549
00:27:23  <loladiro>even better ;)
00:30:21  <bnoordhuis>loladiro: if you can verify the patch, i'll commit it
00:30:39  <mjr_>isaacs: so far so good on the men leak patch: https://skitch.com/mranney/8ag9u/circonus-view-graph
00:31:13  <loladiro>bnoordhuis: I don't have access to a CentOS machine right now, but I'll ask the person who originally reported it to me via email to try it
00:31:28  <isaacs>mjr_: that is the best news i've heard all day
00:31:29  <bnoordhuis>loladiro: okay, thanks
00:31:31  <mjr_>isaacs: traffic is going up, but memory usage is holding steady, so far.
00:31:32  <isaacs>mjr_: well, second best.
00:31:39  <mjr_>What's the first best?
00:31:44  <bnoordhuis>mjr_: that's a pretty big difference
00:31:44  <isaacs>mjr_: but only because i found out i'm going to thailand in february
00:31:50  <mjr_>Oh nice.
00:31:56  <isaacs>yeah.
00:31:59  <isaacs>it's gonna be sweeet
00:32:11  <mjr_>We are having a Voxer node summit in Kauai right now.
00:32:44  <mjr_>Never been to Thailand though, sounds awesome from what I hear.
00:35:48  <mjr_>isaacs: behold the garbage collector working properly: https://skitch.com/mranney/8a8y8/circonus-view-graph
00:36:05  <mjr_>Each data point on the graph is 2 seconds.
00:39:14  <mjr_>If you guys have a brilliant and simple solution for https://github.com/joyent/node/issues/3176 that would make us all very happy.
00:45:05  <bnoordhuis>mjr_: no brilliant solutions, sorry :/
00:45:15  <mjr_>Damn.
00:45:20  <bnoordhuis>i've been wrecking my brain trying to come up with a reasonable explanation for that
00:45:25  <bnoordhuis>no luck so far
00:45:29  <mjr_>I'm starting to think that it is an effect of some other badness, not a cause.
00:45:33  <bnoordhuis>yeah
00:45:43  <bnoordhuis>does that application use child processes or stdio?
00:46:04  <mjr_>But it always correlates with when we get those parse errors, whatever those are.
00:46:46  <bnoordhuis>mjr_: parse errors as in 'cannot call method execute of object null'?
00:47:00  <mjr_>We get a parse error, then we dump the connection, then later badness happen.
00:47:37  <mjr_>No, parse error like new Error("Parse Error") from somewhere
00:47:47  <mjr_>Presumably from http_parser.
00:48:12  <mjr_>That's why 2997 is so interesting.
00:48:14  <bnoordhuis>can you define 'dump connection'? is that req.end(), req.socket.destroy(), something else?
00:48:34  <mjr_>Because the other guy notices that same parse error related to this parser null thing.
00:48:43  <mjr_>Let me get very precise about what we do, checking the source
00:49:01  <bnoordhuis>great :)
00:51:01  * dap1quit (Quit: Leaving.)
00:52:27  <CIA-155>node: Yoshihiro Kikuchi master * ree2291e / test/simple/test-domain-multi.js : test: add a child domain explicitly - http://git.io/T3q6pg
00:52:47  <mjr_>bnoordhuis: this is a sequence of events that often errors with EBADF
00:53:24  <isaacs>mjr_: i cannot stress enough how hopeful i am about this memleak bug is fixed. if it is indeed fixed, this is a great example of the sort of thing that takes a village.
00:53:59  <mjr_>A -> B GET 1, B -> C GET 1, B catches error event, B -> A HTTP 500, sometime later B gets EBADF
00:54:42  <mjr_>So B is kind of a proxy for A in this case, and sometimes B gets a "parse error" error event.
00:55:03  <mjr_>But it could be that the same thing that causes B to get the parse error is the same thing that is responsible for the EBADF
00:56:41  <mjr_>isaacs: and it also took the community to invent something colossally complicated like nuclear energy in order for the village to figure it out.
00:56:57  * mmaleckichanged nick to mmalecki[zzz]
00:57:29  <isaacs>mjr_: indeed!
00:57:36  <mjr_>nuclear energy == v8.so for mdb and jstack for dtrace.
00:57:59  <isaacs>mjr_: well... in this case, the nuclear reactor has a big warning that says "DO NOT DRINK" and we drink the shit out of it.
00:58:20  <isaacs>mjr_: meaning: in a garbage collected language, keeping a list of objects that you reuse repeatedly is a HUGE nono
00:58:36  <isaacs>especially if those objects have references to other objects that you DO need to have cleaned up
00:58:57  <isaacs>we've eaten a LOT of bugs for the performance increase we get from reusing http parsers.
00:59:03  <mjr_>Sure, but as a result of this never ending quest for performance, we are going to end up with a dynamic language operating environment that is both faster and more observable than anything that's ever been.
00:59:12  <isaacs>true
01:01:04  <bnoordhuis>mjr_: do A, B and C anything else besides making and/or receiving http requests?
01:01:10  <bnoordhuis>*do anything else
01:01:33  <mjr_>bnoordhuis: oh my yes. They run our application with various processing, state, and other complicated things.
01:02:13  <mjr_>B is kind of special though, because it opens files on disk. It's the only process we have that deals with the filesystem.
01:02:24  <mjr_>And it's also the only one that ever gets these EBADF errors.
01:02:48  <bnoordhuis>correlation is not causation of course but that seems like a clue
01:03:13  <mjr_>Yeah, it does seem relevant that this thing deals with files, but it might be completely unrelated.
01:03:23  * skmpyquit (Quit: leaving)
01:03:49  <bnoordhuis>mjr_: does B use fs.open(), fs.read(), etc. or something higher-level like fs.createReadStream()?
01:03:56  <mjr_>let me check
01:04:27  * hij1nxquit (Quit: hij1nx)
01:04:42  <benvie>on this note, WeakMap is one of those things that would probably not hurt to have turned on before it's an officially blessed v8 path
01:04:53  <mjr_>fs.createWriteStream, fs.createReadStream, and fs.unlink.
01:05:46  <bnoordhuis>there was a bug in createReadStream a while ago...
01:05:46  <mjr_>bnoordhuis: on startup it also does a few sync fs operations like mkdirSync, readdirSync, and unlinkSync.
01:06:02  <bnoordhuis>mjr_: anything that operates on file descriptors directly?
01:06:27  <mjr_>oh god no
01:06:32  <mjr_>That would be insane.
01:06:40  <bnoordhuis>okay, good :)
01:07:13  <bnoordhuis>hmm, the fs operations may be a red herring then
01:07:24  <mjr_>You can debate whether we are still insane because we built this huge thing out of a relatively unproven thing like node.js, plus we keep updating node to the latest v0.6 whenever it changes, but that's another discussion.
01:07:27  * bnoordhuischecks the code anyway
01:08:55  <benvie>seems to be different prices to pay, with how fast node has moved you're paying a different kind of price to not keep up
01:09:46  * orlandovftwquit (Ping timeout: 248 seconds)
01:09:49  <benvie>(moved in the good way)
01:10:01  <tjfontaine>mjr_: what kind of backend filesystem? anything more exotic than a native fs and/or block device?
01:10:07  <piscisaureus>close/closeSync seems to be the biggest risk here :-)
01:10:29  <piscisaureus>bnoordhuis: see, that's why this was a bad idea from the start :-)
01:11:08  * brsonquit (Read error: Operation timed out)
01:13:07  <mjr_>tjfontaine: the filesystem is ZFS from Joyent on SmartOS. The files are written in order with a writeStream and read, potentially multiple times from the beginning with a readStream.
01:13:26  <tjfontaine>k
01:14:11  <mjr_>benvie: yeah, but I figured that if we tracked the latest node versions that the node developers would be happier to look at bugs. :)
01:14:48  <bnoordhuis>i guess there's a potential for a double close(fd) if you call Readstream.destroy() twice
01:14:56  <mjr_>oh
01:15:03  <mjr_>we might do something like that
01:15:24  <bnoordhuis>that would be bad :)
01:15:30  <piscisaureus>bnoordhuis: that would be a very serious bug...
01:16:30  <mjr_>So we try to not double destroy:
01:16:31  <mjr_>https://gist.github.com/2572830
01:16:32  * dshaw_quit (Quit: Leaving.)
01:16:35  <piscisaureus>bnoordhuis: ugh... it is possible...
01:16:40  <bnoordhuis>yeah
01:17:05  <bnoordhuis>i'll write a patch
01:17:48  <mjr_>So there are often multiple read streams going against the same file, and they get destroyed independently, but we should never re-destroy the same stream.
01:17:57  <bnoordhuis>mjr_: okay, that looks like it should be safe
01:18:09  <mjr_>Unless that readable doesn't get set, but I thought it did.
01:19:01  <bnoordhuis>it does
01:20:42  <benvie>thing about node is that it's really stable even in dev versions, it can just also have some crazy ass deopimzation that no one catches for a bit. But it's still basically stable, escept for when it closed every fucking 5 minutes with no error during isolates
01:21:13  <piscisaureus>benvie: well I remember the 0.5 branch as well :-)
01:21:23  <piscisaureus>benvie: that was potentially worse
01:21:39  <benvie>yeah but you kind of could expect it to just not work and be happy when it did
01:22:03  <piscisaureus>I think 0.7 is pretty solid atm, sure
01:22:08  <benvie>oh joyous, is this really working on windows?! natively?!
01:22:42  <pfox___>i really am sad about isolates
01:22:47  <pfox___>it's too bad what happened, there.
01:23:05  <benvie>i was convinced for a few days I had unlocked the key to crashing the shit out of node and v8 24/7 and was trying to figure out where this gift came from
01:23:37  <piscisaureus>pfox___: you are sad that isolates are gone?
01:23:41  <benvie>I do know it's something i was doing with vm, cause it still occasionally happens
01:23:48  <benvie>just not like with isolates
01:23:50  <pfox___>piscisaureus: well im not a node dev, per se.
01:24:08  <pfox___>putting aside the drama of backing the change out (of which there was none, granted)
01:24:22  <pfox___>it just sucks to say "hey everyone, we're gonna do <this thing>!" to applause.
01:24:32  <pfox___>but, it wasn't my problem
01:24:40  <piscisaureus>yeah, that sucked
01:24:54  <piscisaureus>that's called "fail fast"
01:24:55  <pfox___>ive some success with running JS VMs across multiple threads
01:24:57  <piscisaureus>:-p
01:24:58  <benvie>but vm is well known to bne the thing that finds whatever is the weakest part at any given point and silently probes it for weaknesses, like it's sentient and trying to escape
01:25:02  <pfox___>but 1) is was spidermonkey
01:25:18  <pfox___>2) it was JSRuntime* per-thread, which is the heaviest, but safest, way to go
01:25:45  <pfox___>there are compartments in 1.8.5, but i about as much luck with that piece of API as node did w/ V8 isolates
01:25:47  <benvie>in terms of actual functionality, vm is probably node's weakest link too though so
01:26:25  <benvie>it's simple, mostly uses v8 apis, and that's still not easy to do right (the whole vm thing)
01:26:50  <mjr_>bnoordhuis: it looks like we do get EBADF more often on disk ops than on network ops, and on disk opts, its mostly close
01:26:50  <mjr_>https://gist.github.com/2572870
01:26:56  <pfox___>anyways, yes. hooray for failing fast.
01:27:09  <benvie>talking to the guys over at jsapi, the amount of just raw anger I hear about trying to support
01:27:12  <pfox___>woo!
01:27:45  <benvie>but mozilla is in a much more painful spot with xpcom and all that than v8 is
01:27:51  <mjr_>bnoordhuis: again though, this could be an effect and not a cause. But we seem to run into trouble on disk closes for whatever reason.
01:28:08  <bnoordhuis>mjr_: yeah. strong indicator though
01:28:22  <bnoordhuis>i'll prod at ReadStream and WriteStream some more
01:29:00  <pfox___>piscisaureus: if you're interested, following up our convo yesterday
01:29:01  <pfox___>https://github.com/olsonjeffery/rust/blob/hl_tcp/src/libstd/net_tcp.rs#L396
01:29:14  <pfox___>this is the API i ended up producing for a "high-level" tcp request API in rust
01:29:38  <pfox___>first draft. but it works.. it's sorta libuv'ish
01:30:01  <benvie>do not see the thread people see that
01:30:07  <benvie>let the thread people
01:30:23  <benvie>I think we just need a better way to represent indenting is all =D
01:30:26  <piscisaureus>pfox___: I have to get used to rust I think...
01:30:33  <pfox___>piscisaureus: yeah. it's fun!
01:30:38  <pfox___>alt = pattern matching structure
01:31:08  <bnoordhuis>piscisaureus: rust is nice
01:31:24  <piscisaureus>bnoordhuis: can you read this -> https://github.com/olsonjeffery/rust/blob/hl_tcp/src/libstd/net_tcp.rs#L396
01:31:54  <bnoordhuis>piscisaureus: yeah. i prefer my code a little flatter though :)
01:33:10  <benvie>thankfully it's not using the 6 space indenting I've seen on a lot of the mozilla umbrella code, though that has lessened recently
01:33:23  <piscisaureus>pfox___: does rust use coros?
01:33:48  <bnoordhuis>benvie: 6 spaces? that's just wrong
01:33:52  <benvie>yeah
01:34:04  <piscisaureus>Yeah I prefer 7 too
01:34:04  <benvie>and it is wrong
01:34:27  <bnoordhuis>i had a co-worker who persistently used 3 spaces
01:34:44  <bnoordhuis>which was extremely annoying because the convention was 4 spaces
01:35:01  <bnoordhuis>but he kept on doing it, no matter how often you talked to him about it
01:35:22  <bnoordhuis>i kind of understand now why companies have no love for older programmers...
01:35:23  <benvie>see I hate the 6 spaces, but I converted my stuff before I submitted it
01:35:41  <benvie>so that's a choice to be a hater
01:35:59  * abraxasjoined
01:36:00  <benvie>or inability to not be
01:38:42  <benvie>I try not to blame oldness because suddenly old awesome 70 year old guys pop whenever I do that
01:39:14  <bnoordhuis>mjr_: do you have full stack traces for the errors in https://gist.github.com/2572870 ?
01:39:35  <mjr_>sure, need to do some hardcore grep action though.
01:39:38  * isaacsquit (Remote host closed the connection)
01:39:59  <bnoordhuis>'EAGAIN, read' for example is something i wouldn't expect
01:40:21  <mjr_>also, ENOENT is a pretty big fail.
01:40:53  <bnoordhuis>how so? if there's no file, there's no file
01:41:12  <mjr_>well sure, but there should be a file. We just put one there.
01:41:45  <mjr_>ENOENT doesn't happen often enough to worry about, but it's very unexpected for me.
01:41:58  * hij1nxjoined
01:43:08  * pfox___quit (Read error: Operation timed out)
01:43:14  <bnoordhuis>mjr_: put one with createWriteStream() or?
01:43:16  <mjr_>hmm, no stack traces, but there are some interesting correlations
01:43:29  <mjr_>https://gist.github.com/2572947
01:43:53  <mjr_>It's almost always after we close then re-open a file.
01:44:10  <bnoordhuis>yeah
01:44:56  <mjr_>So A was uploading file to B, then gets stuck. Later, A uploads again, and B calls destroy on the older, stuck upload request.
01:45:10  <mjr_>B also closes the disk file, then re-opens it
01:45:17  * theColejoined
01:46:15  <mjr_>Need to step away for a bit, but I'll be back on later.
01:46:45  <bnoordhuis>thanks for the help so far, mjr_
01:46:50  <CIA-155>libuv: Bert Belder master * r7d45cca / src/win/internal.h : Windows: we're out of handle flags - arrange them more efficiently - http://git.io/RSUwMw
01:46:51  <CIA-155>libuv: Bert Belder poll * rabeedb5 / (test/test-list.h uv.gyp test/test-poll.c): Test: add tests for uv_poll - http://git.io/cdf_sQ
01:46:53  <CIA-155>libuv: Bert Belder master * r19aca7a / (4 files in 2 dirs): Windows: add uv_msafd_poll, to support overlapped socket polling - http://git.io/_PnD9w
01:46:54  <CIA-155>libuv: Bert Belder poll * r0a9e1ce / test/benchmark-sizes.c : Benchmarks: add size of uv_poll_t to benchmark-sizes - http://git.io/8oyB3g
01:46:55  <CIA-155>libuv: Bert Belder master * r9f0dc26 / (src/win/winapi.c src/win/winapi.h): Windows: fetch pointer for CancelIoEx on startup - http://git.io/3E84MA
01:46:56  <CIA-155>libuv: Bert Belder poll * raae0e6b / include/uv.h : Api for polling external sockets - http://git.io/UvcnrA
01:46:57  <CIA-155>libuv: Bert Belder poll * r9c97764 / (7 files in 3 dirs): Windows: uv_poll_t support - http://git.io/nWPNIQ
01:46:59  <CIA-155>libuv: Bert Belder poll * rf45b80a / src/win/poll.c : Windows: uv_poll improvements - http://git.io/OvaEZg
02:02:50  <piscisaureus>Now I am out of my confort zone
02:02:55  <piscisaureus>vi, bah
02:08:53  * mikealquit (Quit: Leaving.)
02:09:27  * brsonjoined
02:09:34  * bulatshakirzyanojoined
02:13:18  * brsonquit (Client Quit)
02:15:23  <piscisaureus>bnoordhuisL I am going to bed.
02:15:38  <piscisaureus>I cannot stomach vi at the moment
02:15:47  <piscisaureus>later all
02:17:19  * orlandovftwjoined
02:17:21  <bnoordhuis>hah
02:17:24  <bnoordhuis>sleep tight, bertje
02:21:01  * TooTallNatequit (Ping timeout: 244 seconds)
02:22:56  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:26:15  * pfox___joined
02:28:02  * mjr_quit (Quit: mjr_)
02:33:11  * seebeesjoined
02:34:27  * hij1nxquit (Quit: hij1nx)
02:42:51  * mikealjoined
02:52:08  * orlandovftwquit (Ping timeout: 255 seconds)
02:52:31  * orlandovftwjoined
02:55:07  * mikealquit (Quit: Leaving.)
02:55:12  * iraquit (Quit: Computer has gone to sleep.)
02:56:17  * theColequit (Quit: theCole)
02:57:28  * isaacsjoined
03:06:51  * loladiroquit (Quit: loladiro)
03:27:53  * orlandovftwquit (Ping timeout: 265 seconds)
03:37:43  * loladirojoined
03:38:41  * bnoordhuisquit (Ping timeout: 245 seconds)
03:40:31  * TooTallNatejoined
03:42:04  * TooTallNatequit (Client Quit)
04:08:45  * mikealjoined
04:11:42  * loladiroquit (Quit: loladiro)
04:19:51  * isaacsquit (Remote host closed the connection)
04:45:49  * hij1nxjoined
04:47:43  * isaacsjoined
04:52:04  * isaacsquit (Remote host closed the connection)
04:53:34  * avalanche123quit (Ping timeout: 245 seconds)
04:53:35  * bulatshakirzyanochanged nick to avalanche123
04:58:31  * avalanch_joined
05:06:34  * avalanche123quit (Quit: Computer has gone to sleep.)
05:06:34  * avalanch_changed nick to avalanche123
05:30:30  <indutny>anyone around?
05:30:37  <indutny>(core devs)
05:32:57  * avsej_quit (Excess Flood)
05:33:16  * avsejjoined
05:39:25  * hij1nxquit (Quit: hij1nx)
05:51:48  * orlandovftwjoined
05:55:40  * pfox___quit (Quit: leaving)
06:02:43  * paddybyersjoined
06:10:45  * paddybyersquit (Ping timeout: 240 seconds)
06:12:34  * hij1nxjoined
06:40:01  * isaacsjoined
06:42:10  * stephankquit (Quit: *Poof!*)
06:49:00  * rendarjoined
07:17:50  * hij1nxquit (Quit: hij1nx)
07:42:46  * avalanch_joined
07:43:56  * avalanche123quit (Ping timeout: 244 seconds)
07:43:56  * avalanch_changed nick to avalanche123
07:46:01  * skomskijoined
07:56:50  * skomskiquit (Quit: skomski)
07:57:15  * theColejoined
08:13:59  * paddybyers_joined
08:39:35  <indutny>isaacs: hey man
08:39:57  <indutny>isaacs: can you please review this: https://github.com/joyent/node/issues/3203#issuecomment-5454429 ?
08:40:07  <indutny>isaacs: it's very concise and won't take much time
08:42:18  <isaacs>indutny: seems fine to me. test?
08:42:27  <indutny>isaacs: k, sounds good
08:47:40  * isaacsquit (Remote host closed the connection)
08:49:14  <CIA-155>node: Fedor Indutny master * rc3898f3 / (3 files in 3 dirs):
08:49:14  <CIA-155>node: debugger: support mirroring Date objects
08:49:14  <CIA-155>node: * fixes #3203 - http://git.io/Zhdn2A
10:09:24  * orlandovftwquit (Ping timeout: 246 seconds)
10:14:58  * mmalecki[zzz]changed nick to mmalecki
10:27:56  * theColequit (Quit: theCole)
11:11:02  * abraxasquit (Remote host closed the connection)
11:11:35  * abraxasjoined
11:16:17  * abraxasquit (Ping timeout: 244 seconds)
11:26:34  * irajoined
11:59:16  * txdv_changed nick to txv
12:02:40  * txvchanged nick to txdv
12:16:14  * theColejoined
12:28:59  * TheJHjoined
12:29:03  * theColequit (Ping timeout: 246 seconds)
12:33:13  * loladirojoined
12:35:25  * c4milojoined
13:01:57  * paddybyers_quit (Ping timeout: 246 seconds)
13:22:29  * piscisaureus_joined
13:24:41  * mmaleckichanged nick to mmalecki[away]
13:55:35  * skomskijoined
13:55:53  * skomskiquit (Remote host closed the connection)
13:58:09  * piscisaureus__joined
13:58:58  * piscisaureus_quit (Ping timeout: 252 seconds)
14:37:05  * c4miloquit (Read error: Connection reset by peer)
14:37:47  * c4milojoined
14:50:23  <txdv>undefined reference to `lstat64', what lib?
14:58:52  * bnoordhuisjoined
14:59:03  <indutny>txdv: huh?
14:59:06  <indutny>bnoordhuis: hey man
14:59:14  <indutny>bnoordhuis: good evening
14:59:34  <bnoordhuis>indutny: good afternoon :)
14:59:58  <indutny>bnoordhuis: how's ya doing?
15:00:14  <bnoordhuis>indutny: fine, thanks. you?
15:00:18  <indutny>bnoordhuis: fine too
15:00:41  <indutny>bnoordhuis: looking for some uv/node issue to work on ;)
15:01:21  <txdv>nevermind, I got it working another way and i'm don't even care why ld fails to look up that function
15:01:23  <bnoordhuis>indutny: if you're feeling masochistic, you can do the windows side of the refcount refactor
15:01:34  <indutny>bnoordhuis: hahaha
15:01:40  <indutny>bnoordhuis: I don't have any win machine atm
15:02:30  <tjfontaine>bnoordhuis has been desperately passing the buck on that one
15:02:49  <bnoordhuis>without much luck so far :/
15:03:29  <tjfontaine>sad it is
15:07:44  <indutny>so no uv issues around
15:07:48  <indutny>it's 100% perfect
15:07:54  <indutny>and ponies are jumping around it's repo
15:08:48  <indutny>:D
15:10:41  <bnoordhuis>'tis true, libuv has no major issues right now
15:10:43  <bnoordhuis>node otoh...
15:11:22  * isaacs_mobilejoined
15:15:21  <indutny>bnoordhuis: and what are node's ones?
15:15:48  <bnoordhuis>indutny: two of the major ones are memory/object leaks in the http client and crashes on (at least) sunos when tls is involved
15:21:36  * isaacs_mobilequit (Remote host closed the connection)
15:26:38  * isaacsjoined
15:43:54  <CIA-155>libuv: Ben Noordhuis master * r1ebe14e / src/unix/process.c :
15:43:54  <CIA-155>libuv: linux: fix build error with old kernel headers
15:43:54  <CIA-155>libuv: O_CLOEXEC was introduced in linux 2.6.23, don't assume it's available.
15:43:54  <CIA-155>libuv: Fixes #400. - http://git.io/PKCaHA
15:45:45  * travis-cijoined
15:45:45  <travis-ci>[travis-ci] joyent/libuv#250 (master - 1ebe14e : Ben Noordhuis): The build is still failing.
15:45:45  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/19aca7a...1ebe14e
15:45:45  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1227729
15:45:45  * travis-cipart
15:47:40  * c4milochanged nick to c4milo|lunch
15:48:44  * loladiroquit (Read error: Connection reset by peer)
15:48:48  * loladiro_joined
15:49:12  <isaacs>Good morning
15:50:33  <indutny>morning
15:51:41  * piscisaureus___joined
15:51:54  * piscisaureus__quit (Ping timeout: 245 seconds)
15:52:03  * piscisaureus___changed nick to piscisaureus_
15:57:08  * piscisaureus__joined
15:58:23  * piscisaureus_quit (Ping timeout: 252 seconds)
16:05:15  <bnoordhuis>https://github.com/bnoordhuis/node/commit/8802196 <- review anyone?
16:05:28  <bnoordhuis>quoting the commit log: Share AddressToJS() function between tcp_wrap.cc and udp_wrap.cc.
16:07:30  <bnoordhuis>the review window is closing in 30, 29, 28...
16:09:23  <tjfontaine>uv_inet_ntop doesn't necessarily need to be in its own switch
16:10:05  * c4milo|lunchchanged nick to c4milo
16:10:32  <bnoordhuis>oh, that's not new. i guess it could be changed but it doesn't bother me
16:10:48  <tjfontaine>I know, I was just pointing it out
16:11:36  <bnoordhuis>also, it'd get tricky if sa_family was not in (AF_INET, AF_INET6)
16:13:05  <bnoordhuis>okay, thanks for the feedback. i'll just push it :)
16:13:23  <tjfontaine>heh no problemo :)
16:13:24  <CIA-155>node: Ben Noordhuis master * r8802196 / (src/tcp_wrap.cc src/udp_wrap.cc):
16:13:24  <CIA-155>node: tcp, udp: share sockaddr-to-object function
16:13:24  <CIA-155>node: Share AddressToJS() function between tcp_wrap.cc and udp_wrap.cc. - http://git.io/EaBNNA
16:18:15  <isaacs>bnoordhuis: yeah, lgtm
16:23:26  * orlandovftwjoined
16:24:31  * mmalecki[away]changed nick to mmalecki
16:29:31  * bnoordhuisis off to dinner
16:29:38  * dapjoined
16:35:43  * c4miloquit (Ping timeout: 265 seconds)
16:43:06  * mikealquit (Quit: Leaving.)
16:44:24  * mikealjoined
16:50:45  * dapquit (Quit: Leaving.)
17:06:11  * pieternjoined
17:08:40  * elijah-mbpquit (Remote host closed the connection)
17:10:27  * ericktjoined
17:10:59  * elijah-mbpjoined
17:12:31  * saghulquit (Remote host closed the connection)
17:18:24  * stephankjoined
17:20:56  * hij1nxjoined
17:29:58  * elijah-mbpquit (Remote host closed the connection)
17:30:16  * hij1nxquit (Quit: hij1nx)
17:31:07  * elijah-mbpjoined
17:33:18  * orlandovftwquit (Ping timeout: 272 seconds)
17:36:40  <CIA-155>libuv: Bert Belder poll * r1688f51 / (6 files): Unix: namespace stream handle flags - http://git.io/tKi-0w
17:37:09  <piscisaureus__>^--bnoordhuis: opinion?
17:37:24  * travis-cijoined
17:37:24  <travis-ci>[travis-ci] joyent/libuv#251 (poll - 1688f51 : Bert Belder): The build is still failing.
17:37:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f45b80a...1688f51
17:37:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1228639
17:37:24  * travis-cipart
17:41:03  * hij1nxjoined
18:01:19  * TooTallNatejoined
18:02:23  * c4milojoined
18:09:18  * brsonjoined
18:11:15  <isaacs>bnoordhuis, piscisaureus__: Is there ever a case where you do socket.setTimeout(msecs), and if there's a timeout, you *don't* want to destroy the socket?
18:12:09  * orlandovftwjoined
18:18:46  * loladiro_quit (Quit: loladiro_)
18:25:34  <isaacs>bnoordhuis, piscisaureus__: Alternatively, if there is such a case in raw TCP, is there ever a case in HTTP where you don't want to .destroy() the request if it times out?
18:28:56  <isaacs>it looks like we do a socket.destroy() on timeouts in the server, but if you setTimeout on the client, we don't, and then it leaks.
18:30:42  * skomskijoined
18:34:14  * mikealquit (Quit: Leaving.)
18:34:33  * pfox___joined
18:48:00  * hij1nxquit (Quit: hij1nx)
18:48:59  * dapjoined
18:49:52  * mikealjoined
18:50:20  * `3rdEdenjoined
18:54:43  * loladirojoined
18:56:06  <TooTallNate>isaacs: getting lots of "Error: socket hang up" with npm today :\
18:56:33  <isaacs>TooTallNate: yeah, me too
19:00:18  <TooTallNate>well at least it's not just me
19:02:12  * skomskiquit (Remote host closed the connection)
19:06:18  * hij1nxjoined
19:21:11  <CIA-155>node: isaacs http-memleak * rc9be1d5 / lib/http.js : http client: Destroy on timeout - http://git.io/G_xZvA
19:22:29  <isaacs>bnoordhuis, piscisaureus__, TooTallNate: review, please? https://github.com/joyent/node/commits/http-memleak
19:22:33  <isaacs>top 3 commits
19:22:48  <isaacs>i don't have a test yet that doesn't depend on node-weak and --expose-gc
19:22:57  <isaacs>maybe we should have a separate of gc tests?
19:27:49  * mjr_joined
19:33:41  <pfox___>so are there any accessibly examples out there of doing ssl over a uv_tcp_t* ?
19:33:46  <pfox___>accessible, even
19:33:55  <pfox___>or should i dive into the node codebase..?
19:37:23  * isaacs_mobilejoined
19:43:53  <piscisaureus__>pfox___: none that I am aware of. Node supports tls but the glueing happens all in javascript (and I am very much not an ssl expert)
19:43:58  * iraquit (Quit: Textual IRC Client: http://www.textualapp.com/)
19:45:11  <pfox___>im just curious how you guys are tackling it, as i think its something we'll have to do w/ in rust
19:45:18  <pfox___>if i want to ship anything vaguely useful in the stdlib
19:45:26  <pfox___>ssl is pretty pervasive, these days.
19:45:34  <pfox___>for web stuff, i mean
19:45:54  <pfox___>s/if i want/if we want/
19:46:14  <pfox___>im just curious, mostly, what the impl looks like, so i can discuss that with other folks on the rust team
19:46:25  <mjr_>node memleak test results: https://skitch.com/mranney/8aqy8/circonus-view-worksheet
19:46:47  <tjfontaine>pretty convincing
19:47:06  * isaacs_mobilequit (Remote host closed the connection)
19:47:13  * AvianFlu_joined
19:47:16  * AvianFluquit (Ping timeout: 244 seconds)
19:47:38  * mikealquit (Quit: Leaving.)
19:47:48  <piscisaureus__>pfox___: it's there -> https://github.com/joyent/node/blob/master/lib/tls.js
19:48:03  <pfox___>ty
19:49:08  <piscisaureus__>pfox___: and here -> https://github.com/joyent/node/blob/master/src/node_crypto.cc
19:49:19  <piscisaureus__>pfox___: but the second one are basically just bindings
19:49:35  <pfox___>and libssl is the underlying lib?
19:49:42  <piscisaureus__>pfox___: openssl, yeah
19:49:54  <pfox___>yes. my bad.
19:50:00  <piscisaureus__>pfox___: I suppose you want to use something mozilla-y
19:50:12  <pfox___>like libuv, you mean? :P
19:50:38  <piscisaureus__>pfox___: well I suppose you'd have used nspr if it was reasonably up to date :-)
19:50:43  <pfox___>really, i don't know. im just collecting info so i can talk to someone about whether they want to take a dep or have a crate in cargo or what.
19:51:05  <pfox___>true. its probably already in nspr, huh.
19:51:25  <piscisaureus__>pfox___: well openssl is quite terrible, unlike libuv. There is really no reason to use it.
19:51:48  <tjfontaine>openssl is bad, and gnutls is damn right frustrating
19:52:07  * mjr_quit (Quit: mjr_)
19:52:36  <piscisaureus__>gnutls was mostly a no-go because of GPL
19:52:42  <tjfontaine>indeed
19:52:51  * `3rdEdenquit (Quit: Leaving...)
19:55:20  * isaacsquit (Remote host closed the connection)
19:56:53  * isaacsjoined
19:57:15  * isaacsquit (Remote host closed the connection)
19:57:41  <pfox___>oh, there's plenty of ssl libraries
19:57:49  <pfox___>they're just all dual-license gplv2/commercial!
19:58:18  <tjfontaine>not many have received the wide testing that openssl and gnutls have
20:01:01  <dap>bnoordhuis: have you been able to build master on smartos recently?
20:13:59  * mjr_joined
20:16:07  * isaacs_mobilejoined
20:16:32  * isaacs_mobilequit (Client Quit)
20:21:04  * mikealjoined
20:23:02  * hij1nxquit (Quit: hij1nx)
20:24:36  * isaacsjoined
20:35:03  * hij1nxjoined
20:41:20  * loladiropart
20:46:51  * hij1nxquit (Quit: hij1nx)
20:53:51  * loladirojoined
20:58:34  * ericktquit (Ping timeout: 244 seconds)
20:59:29  <bnoordhuis>dap: yes, for certain values of recently. what's up?
21:03:44  * ericktjoined
21:07:56  * mikealquit (Quit: Leaving.)
21:08:03  <isaacs>bnoordhuis: can you review the http-memleak branch?
21:08:11  <isaacs>bnoordhuis: i'd like to get 0.6.17 out tomorrow wiht some of these.
21:08:20  <bnoordhuis>isaacs: sure, give me a sec
21:08:38  <isaacs>bnoordhuis: voxer and jitsu are testing in production, too, so we should get more feedback soon
21:09:18  <mjr_>We are pushing it out now across the cluster.
21:09:37  * mikealjoined
21:14:52  <txdv>can 2 seperate pipes listen on one file name?
21:14:59  <bnoordhuis>isaacs: can you review https://github.com/bnoordhuis/node/commit/4efc4c69 ?
21:15:06  <bnoordhuis>txdv: yes
21:15:25  <tjfontaine>that libuv test seems wrong then :)
21:15:27  <bnoordhuis>txdv: or wait, listen as in accept or connect to?
21:15:57  <txdv>http://is.gd/jpB7xB
21:16:25  <bnoordhuis>txdv: p2 will fail
21:17:41  <bnoordhuis>piscisaureus__: you around?
21:17:45  <piscisaureus__>bnoordhuis: yeah
21:19:11  <bnoordhuis>piscisaureus__: what's the weather like in 020? we're having some pretty awesome thunderstorms here
21:19:22  <bnoordhuis>piscisaureus__: also, what are you working on? :)
21:19:22  <piscisaureus__>bnoordhuis: slightly rainy
21:19:23  <piscisaureus__>that's all
21:19:30  <piscisaureus__>bnoordhuis: I am doing uv_poll for unix
21:19:32  <piscisaureus__>almost done
21:19:35  <bnoordhuis>okay, cool
21:20:12  <piscisaureus__>bnoordhuis: I am having some collisions between UV_READABLE and the unix internal api
21:20:19  <piscisaureus__>bnoordhuis: what do you think about:
21:20:22  <piscisaureus__>[19:36] <CIA-155> libuv: Bert Belder poll * r1688f51 / (6 files): Unix: namespace stream handle flags - http://git.io/tKi-0w
21:20:46  * mikealquit (Quit: Leaving.)
21:20:53  * isaacsquit (Remote host closed the connection)
21:22:44  <bnoordhuis>piscisaureus__: well... what does your UV_READABLE do?
21:23:04  <piscisaureus__>bnoordhuis: its public api... sets the interest set for a poll watcher.
21:23:06  <piscisaureus__>{
21:24:40  <bnoordhuis>oh okay. i guess i can live with the change
21:25:01  <bnoordhuis>the convention in uv-unix is to use double underscores for internal names
21:25:11  <bnoordhuis>but for some reason we don't do that for handle flags
21:25:18  <bnoordhuis>so yeah, fine
21:25:22  <piscisaureus__>bnoordhuis: yeah, maybe we should
21:25:27  <piscisaureus__>bnoordhuis: kewl
21:25:45  <piscisaureus__>bnoordhuis: in uv_unix, how/when etc are endgames called?
21:25:59  <bnoordhuis>language lawyers will point out that the c spec reserves identifiers containing double underscores
21:26:00  <bnoordhuis>but meh
21:26:11  <bnoordhuis>piscisaureus__: in uv__finish_close()
21:26:35  <piscisaureus__>bnoordhuis: I am lazy... how do I register my handle for processing by finish_close?
21:26:56  <bnoordhuis>piscisaureus__: look at uv_close() in src/unix/core.c
21:27:00  <piscisaureus__>ok
21:27:10  <bnoordhuis>it starts an idle watcher in the current implementation
21:27:19  <bnoordhuis>the refcount refactor branch uses a linked list
21:27:21  <piscisaureus__>hmm
21:27:28  <piscisaureus__>an idle watcher is not so nice..
21:27:31  <bnoordhuis>no
21:27:37  <piscisaureus__>can cause memory leaks on busy servers :-)
21:27:45  <bnoordhuis>i blame ryah_
21:28:07  <bnoordhuis>anyway, it's going away - but uv__finish_close() will stay
21:28:13  <piscisaureus__>ok, cool
21:32:08  * pfox___quit (Quit: leaving)
21:32:11  <bnoordhuis>mjr_: did you also roll out the bug fix from 3176?
21:32:20  <mjr_>Not yet.
21:32:31  <bnoordhuis>okay
21:32:36  <mjr_>Soon though.
21:32:56  * rendarquit
21:34:33  * avalanche123quit (Ping timeout: 260 seconds)
21:35:54  * avalanche123joined
21:40:44  <txdv>It doesn't throw an error, and the second listener is always prefered
21:41:17  * mralephjoined
21:43:09  <txdv>ill have to test it on play libuv
21:44:47  <mjr_>So the memleak branch seems to have fixed one of our memory leaks, but not all. The process that handles HTTPS termination appears to still be growing.
21:45:34  <bnoordhuis>mjr_: how does that application work?
21:45:54  <mjr_>bnoordhuis: I think the TLS issue is still a big concern. https://skitch.com/mranney/8axr9/circonus-edit-graph
21:46:26  <bnoordhuis>is the big drop at the end a restart?
21:46:30  <mjr_>bnoordhuis: yes
21:46:36  <bnoordhuis>okay
21:46:44  <piscisaureus__>bnoordhuis: why do all handles have an fd on unix?
21:46:50  <mjr_>It uses way more heap outside of the V8 heap, so that's gotta be openssl.
21:46:56  <bnoordhuis>piscisaureus__: yes, it's silly
21:47:01  <piscisaureus__>bnoordhuis: it seems to me that should be exclusively for streams and udps
21:47:22  <bnoordhuis>mjr_: what version of openssl is it linked against?
21:48:06  <mjr_>https://gist.github.com/2580772
21:49:31  <bnoordhuis>mjr_: oh right, there's your problem. SSL_MODE_RELEASE_BUFFERS needs openssl >= 1.0.0a
21:50:07  <bnoordhuis>that doesn't mean it should leak but it will use a lot more memory
21:50:12  <mjr_>I see.
21:50:23  <mjr_>Well, let's let it simmer for a while and see if it settles out somewhere or still leaks.
22:02:45  * hij1nxjoined
22:03:24  <piscisaureus__>bnoordhuis: can you help me out
22:03:25  <piscisaureus__>bnoordhuis: https://gist.github.com/2580892
22:03:25  <piscisaureus__>bnoordhuis: ^-- doesn't really look related to my poll stuf...
22:03:32  * ericktquit (Quit: erickt)
22:04:05  <mmalecki>we'll probably need a bit more time to find out if this leaks less, but memory usage looks lower on this load balancer
22:04:10  * pfox___joined
22:05:02  <bnoordhuis>Disavow all knowledge, and break the references to the variables trapped by closures and on the socket object. <- wasn't garbage collection going to free us from that? :-/
22:05:51  <bnoordhuis>piscisaureus__: don't run make test. build with gyp, then out/Debug/run-tests
22:06:15  <piscisaureus__>ach so
22:06:18  <bnoordhuis>if you want `make test` to work, you should probably do a `git clean -dfx` first
22:08:34  * avalanche123quit (Quit: Computer has gone to sleep.)
22:08:39  <piscisaureus__>hmm
22:08:50  <piscisaureus__>scheisse
22:09:02  <piscisaureus__>I forgot to add poll.c before git clean
22:09:05  * piscisaureus__cries
22:11:34  * bnoordhuishands piscisaureus__ a tissue
22:11:47  <piscisaureus__>thanks
22:11:50  <piscisaureus__>this is really safd
22:11:54  <piscisaureus__>it is really gone :-(
22:12:07  <bnoordhuis>piscisaureus__: you don't have it open in your editor?
22:12:19  <piscisaureus__>no
22:12:22  <bnoordhuis>damn
22:12:59  <piscisaureus__>Maybe I can forcefully shutdown my vm and grep through the virtual hd
22:13:05  <piscisaureus__>that sounds like it might work
22:13:47  * saghuljoined
22:13:52  <bnoordhuis>worth a try
22:16:48  * hij1nxquit (Quit: hij1nx)
22:23:54  <dap>bnoordhuis: I'm getting this on master: https://gist.github.com/6bf7c4ce1f90daf28858
22:24:04  * ericktjoined
22:24:06  <dap>not latest 0.7 release though
22:24:24  <piscisaureus__>Binary file Snapshots\{a24e078e-5434-4384-ac09-f8e772998da1}.vdi matches
22:24:30  <piscisaureus__>now that is useful -(
22:26:02  * TheJHquit (Ping timeout: 248 seconds)
22:38:59  * mikealjoined
22:39:35  <bnoordhuis>dap: does it work with c21c51a^ ?
22:40:08  <dap>I'll tell you in a couple minutes :)
22:40:28  <bnoordhuis>i haven't seen that myself btw, and i think i last tested the sunos build last week
22:40:31  <txdv>are zou german piscisaureus___
22:40:36  <txdv>are zou german piscisaureus__?
22:40:42  <bnoordhuis>oh, it's on
22:40:42  <piscisaureus__>txdv: NEIN
22:40:46  <txdv>NINE NINE NINE
22:41:38  * mjr_quit (Quit: mjr_)
22:42:04  <dap>bnoordhuis: that commit looks fine
22:42:20  <bnoordhuis>dap: and c21c51a itself?
22:42:36  <bnoordhuis>no.de is so slow sometimes...
22:43:35  <mmalecki>bnoordhuis: well, use nodejitsu ;)
22:43:51  * hij1nxjoined
22:44:01  <txdv>damn thats a short site link
22:44:12  <bnoordhuis>mmalecki: i will if you give me a machine with 32 cores and 8 gb of memory :)
22:44:39  <dap>bnoordhuis: that fails. that's the broken one.
22:45:50  <mmalecki>bnoordhuis: haha, we'll see :)
22:45:53  * pfox___quit (Quit: leaving)
22:47:38  * avalanche123joined
22:47:54  * avalanche123quit (Client Quit)
22:48:03  <bnoordhuis>dap: okay, i can fix that
22:48:56  <bnoordhuis>dap: btw, what version of g++ are you compiling with?
22:49:29  <dap>bnoordhuis: 4.5.2
22:49:45  <bnoordhuis>okay, thanks
22:49:55  <dap>thank you!
22:51:39  <bnoordhuis>man, compiler bugs - you just can't win
22:52:05  <bnoordhuis>compile with -fno-strict-aliasing on platform A and it crashes with runtime errors, compile without on platform B and it crashes at startup
22:52:54  * isaacsjoined
22:54:25  <isaacs>bnoordhuis: 4efc4c69 lgtm
22:55:18  <bnoordhuis>isaacs: thanks
22:58:45  <CIA-155>node: Ben Noordhuis master * r6b426a2 / deps/v8/build/common.gypi :
22:58:45  <CIA-155>node: Revert "v8: fix "pure virtual method called" runtime error"
22:58:45  <CIA-155>node: It makes mksnapshot die with a segmentation fault on sunos with gcc 4.5.2.
22:58:45  <CIA-155>node: This reverts commit c21c51a6fce878a4625c30032e669660ce6cbcaf. - http://git.io/Djvcxg
22:58:47  * mmaleckichanged nick to mmalecki[zzz]
22:58:49  <bnoordhuis>dap: ^
22:59:20  <dap>bnoordhuis: thanks!
23:06:52  <CIA-155>node: Ben Noordhuis v0.6 * r47d6a94 / (lib/fs.js test/simple/test-fs-stream-double-close.js):
23:06:52  <CIA-155>node: fs: fix ReadStream / WriteStream double close bug
23:06:52  <CIA-155>node: * Calling fs.ReadStream.destroy() or fs.WriteStream.destroy() twice would close
23:06:52  <CIA-155>node: the file descriptor twice. That's bad because the file descriptor may have
23:06:52  <CIA-155>node: been repurposed in the mean time.
23:06:52  <CIA-155>node: * A bad value check in fs.ReadStream.prototype.destroy() would prevent a stream
23:06:53  <CIA-155>node: created with fs.createReadStream({fd:0}) from getting closed. - http://git.io/w-OU3Q
23:17:32  <bnoordhuis>https://github.com/bnoordhuis/node/commit/4e290e4 <- review anyone?
23:24:33  <piscisaureus__>bnoordhuis: I do not understand unix :-(
23:24:48  <piscisaureus__>bnoordhuis: I set the socket to nonblocking, but the socket blocks on recv() nonetheless :-(
23:24:56  <bnoordhuis>piscisaureus__: those who don't understand unix are doomed to reinvent it
23:25:05  <bnoordhuis>poorly, in all likelihood
23:25:13  <bnoordhuis>piscisaureus__: show me the codez
23:25:45  <bnoordhuis>i have this friend in academics who consistently refers to code as 'codes'. very weird habit
23:26:12  <piscisaureus__>int flags = fcntl(sock, F_GETFL, 0);
23:26:12  <piscisaureus__> ASSERT(flags >= 0);
23:26:12  <piscisaureus__> r = fcntl(sock, F_SETFL, flags | O_NONBLOCK);
23:26:12  <piscisaureus__> ASSERT(flags >= 0);
23:26:31  <piscisaureus__>---
23:26:48  <piscisaureus__>r = recv(context->sock, buffer, sizeof buffer, 0);
23:26:50  <piscisaureus__>^-- blocks
23:26:58  <bnoordhuis>why assert twice that flags >= 0?
23:27:07  <piscisaureus__>because it is a test
23:27:18  <piscisaureus__>and fcntl could fail :-0
23:27:51  <bnoordhuis>yeah, but you're checking it twice. it looks like the second one should be ASSERT(r == 0)
23:28:12  <piscisaureus__>hmm
23:28:12  <piscisaureus__>lol
23:28:25  <piscisaureus__>I think that code is never called
23:28:31  <piscisaureus__>but that means that on windows it's also never called
23:28:37  <piscisaureus__>but on windows it works nonetheless
23:28:48  <bnoordhuis>piscisaureus__: you can pass MSG_DONTWAIT to recv
23:28:55  <bnoordhuis>but why are you not using uv__nonblock?
23:29:15  <piscisaureus__>bnoordhuis: becuz thiz iz a test
23:29:17  <piscisaureus__>for uv_poll
23:29:22  <piscisaureus__>yeah this work
23:29:23  <piscisaureus__>s
23:29:34  <piscisaureus__>bnoordhuis: ghe. sorry for the confusion
23:29:55  <bnoordhuis>heh, okay
23:33:07  <piscisaureus__>kinda weird tho
23:33:21  <piscisaureus__>apparently the windows kernel makes your socket nonblocking if you try to poll it
23:34:19  <bnoordhuis>seems convenient
23:34:46  <bnoordhuis>it more or less works like that on unices too
23:34:59  <bnoordhuis>your sockets don't have to be in non-blocking mode for them to be part of a pollset
23:35:08  <piscisaureus__>sure
23:35:12  <bnoordhuis>it's only when reading and writing that O_NONBLOCK becomes important
23:35:13  <piscisaureus__>but then the socket can still block or read/write
23:35:19  <bnoordhuis>exactly
23:35:24  <piscisaureus__>but on windows, that changes
23:37:46  <bnoordhuis>piscisaureus__: up for a trip to lisbon?
23:38:00  <piscisaureus__>bnoordhuis: depends when
23:38:02  <bnoordhuis>september 28 and 29
23:38:28  <piscisaureus__>bnoordhuis: why? are they trying to make you talk?
23:38:36  <piscisaureus__>bnoordhuis: why not do it for once? :-)
23:38:45  <bnoordhuis>piscisaureus__: and you, check your inbox
23:38:47  <piscisaureus__>but yeah lisbon seems okay
23:39:27  <bnoordhuis>i wasn't joking about it being the pickpocket capital of the world, it's awful
23:39:54  <piscisaureus__>bnoordhuis: ok yeah I guess either of us can do it
23:40:21  <bnoordhuis>i'm not sure if lieke's asking one of us to go or both
23:40:43  <piscisaureus__>let's ask tomorrow
23:40:46  <piscisaureus__>I don't know either
23:40:56  <bnoordhuis>okay, let's
23:41:15  <txdv>talk on what?
23:41:43  <bnoordhuis>txdv: this newfangled javascript language, apparently
23:42:59  <txdv>node.js made javascript suck less
23:43:36  * brsonquit (Remote host closed the connection)
23:43:50  * brsonjoined
23:43:53  <bnoordhuis>well, i wouldn't say that
23:44:19  <bnoordhuis>it's the first server-side javascript that got some real traction
23:44:23  * mralephquit (Quit: Leaving.)
23:44:45  <bnoordhuis>but javascript is just as bad (or good) as it's always been
23:45:09  <txdv>having a nice an easy way to script in the command line with javascript made javascript suck less for more
23:45:11  <txdv>for me
23:46:55  * mikealquit (Quit: Leaving.)
23:47:15  <txdv>I mean, it has even ncurses bindings now
23:47:25  <txdv>at least node.js has
23:47:59  <txdv>im one of those dudes who loves ncurses apps
23:51:45  <piscisaureus__>bnoordhuis: you were ok with the flags patch?
23:52:09  * hij1nxquit (Quit: hij1nx)
23:52:24  <bnoordhuis>piscisaureus__: only if you review this commit -> https://github.com/bnoordhuis/node/commit/4e290e4
23:52:42  <piscisaureus__>bnoordhuis: ok, let's do a review exchange
23:52:58  <bnoordhuis>i'll lgtm your patch if you lgtm mine :)
23:53:21  <CIA-155>libuv: Bert Belder poll * r7e8ab52 / (6 files in 3 dirs): Unix: implement uv_poll (+6 more commits...) - http://git.io/kuxRwQ
23:53:30  <piscisaureus__>bnoordhuis: it's a lot of commits but you only need to review a couple. I will send a PR to make it easy
23:53:49  <bnoordhuis>good idea
23:55:33  * travis-cijoined
23:55:34  <travis-ci>[travis-ci] joyent/libuv#252 (poll - 7e8ab52 : Bert Belder): The build is still failing.
23:55:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/1688f51...7e8ab52
23:55:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1232159
23:55:34  * travis-cipart
23:56:15  <piscisaureus__>unix was so easy
23:56:28  <piscisaureus__>bnoordhuis: https://github.com/joyent/libuv/pull/401
23:56:31  <piscisaureus__>bnoordhuis: looking at yours