00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:21  * c4miloquit (Remote host closed the connection)
00:00:47  * c4milojoined
00:04:30  * kazuponquit (Ping timeout: 260 seconds)
00:05:40  * c4miloquit (Ping timeout: 260 seconds)
00:09:51  * defunctzombiechanged nick to defunctzombie_zz
00:17:59  * mikealjoined
00:21:05  * mikeal1joined
00:21:18  * mikealquit (Read error: Connection reset by peer)
00:28:54  * wolfeidauquit (Remote host closed the connection)
00:29:12  <isaacs>you know, i just realized, we could totally do an "on error resume next" behavior for error events (not as easily for thrown errors, of course)
00:29:45  <isaacs>in EE.emit(), instead of throwing the error if it's uncaught, we could call `process._fatalException(err)`, and then if that returns false, process.exit(1)
00:35:34  * brsonquit (Quit: leaving)
00:41:56  <isaacs>thought, it's probably stupid to call process._fatalException from not-c++
00:47:22  * wolfeidaujoined
00:50:00  * hzquit (Ping timeout: 264 seconds)
01:00:59  * kazuponjoined
01:04:17  * wolfeidauquit (Remote host closed the connection)
01:05:26  * kazuponquit (Ping timeout: 245 seconds)
01:13:52  * hzjoined
01:18:22  * c4milojoined
01:22:52  <mmalecki>isaacs: ping?
01:22:59  <isaacs>pong
01:23:19  <mmalecki>isaacs: is it possible to monitor `end` event in streams2 without resuming?
01:23:30  <mmalecki>potential usecase being implementing reconnect
01:24:09  <isaacs>you mean, receive the 'end' event, even though no one is consuming the stream?
01:24:17  <isaacs>no
01:24:29  <isaacs>the 'end' event doesn't emit until the stream gets read.
01:24:46  <mmalecki>sorry, but this sucks
01:25:04  <isaacs>why?
01:25:18  <mmalecki>say you have a protocol wrapper with reconnection over a net socket
01:25:27  <mmalecki>if nobody reads data, you can't reconnect
01:25:38  <isaacs>you can still listen for 'close' or whatever
01:25:43  <isaacs>or 'error'
01:26:18  <mmalecki>well, not all streams emit `close`, this should be made more generic imo
01:27:08  <isaacs>net sockets do
01:27:13  <isaacs>that's what you're reconnecting, right?
01:27:33  <isaacs>what would it even mean to have 'end' happen when more data is coming?
01:27:36  <isaacs>it means that it's not really the end!
01:27:55  <mmalecki>I was thinking different event or something
01:27:59  <isaacs>sure
01:28:10  <isaacs>net sockets have '_socketEnd'
01:28:15  <isaacs>which is suppoesd to be internal
01:28:26  <isaacs>that's "EOF was seen on the underlying socket"
01:28:35  <mmalecki>yeah, I saw that
01:28:41  <isaacs>but that's internal
01:28:46  <mmalecki>I was hoping to get that implemented more generically tho
01:28:51  <isaacs>right
01:29:06  <isaacs>like, an event that happens when you do stream.push(null) and set _readableState.ended = true
01:29:21  <mmalecki>yup :)
01:29:35  <isaacs>k, propose something as a feature request.
01:29:48  <isaacs>we can discuss it as new API for 0.12
01:29:50  <mmalecki>sure
01:30:08  * chrisdickinsonquit (Quit: ZNC - http://znc.sourceforge.net)
01:32:24  * chrisdickinsonjoined
01:38:14  * defunctzombie_zzchanged nick to defunctzombie
01:41:29  * stagasjoined
01:48:13  <MI6>joyent/node: Alexey Kupershtokh v0.10 * 9fae4dc : timer: fix off-by-one ms error Fix #5103 - http://git.io/LUdZ6g
01:49:51  <isaacs>always nice to find a forgotten pull req that fixes a new bug 0;
01:49:53  <isaacs>:)
01:50:07  <tjfontaine>heh
01:54:30  * qmx|awaychanged nick to qmx
01:58:46  * brsonjoined
02:01:36  * kazuponjoined
02:06:11  <MI6>nodejs-v0.10: #58 FAILURE osx-x64 (1/565) windows-x64 (4/565) osx-ia32 (2/565) smartos-ia32 (1/565) windows-ia32 (4/565) http://jenkins.nodejs.org/job/nodejs-v0.10/58/
02:06:34  * kazuponquit (Ping timeout: 256 seconds)
02:06:45  <tjfontaine>goddamn java
02:06:54  <tjfontaine>FATAL: null
02:06:55  <tjfontaine>java.lang.NullPointerException
02:12:50  * stagasquit (Ping timeout: 260 seconds)
02:14:57  * bradleymeckjoined
02:30:17  * mikeal1quit (Quit: Leaving.)
02:31:41  * brsonquit (Ping timeout: 245 seconds)
02:33:32  * brsonjoined
02:35:39  * kazuponjoined
02:39:58  * mikealjoined
02:47:05  * indexzerojoined
02:49:54  * bnoordhuisquit (Ping timeout: 264 seconds)
02:56:56  * hzquit
03:06:14  <isaacs>tjfontaine: so, the wireshark output is kind of hard to read..
03:06:22  <isaacs>tjfontaine: because there's so much going on in this test.
03:06:41  <tjfontaine>yes, if you limit the count to 2 or 3 does that help?
03:06:54  <tjfontaine>or do you need more to trigger the failure mode?
03:07:02  <tjfontaine>oh that reminds me
03:07:40  <tjfontaine>not that this test is easier to reproduce, http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=x64,label=osx/lastCompletedBuild//tapTestReport/test.tap-29/
03:07:40  <isaacs>running wiht `tcp.port == 12346 && tcp.flags.fin` in the filter
03:08:07  <isaacs>yeah
03:08:13  <isaacs>i suspect it's related
03:08:22  <isaacs>though, this is x64
03:09:13  * kazuponquit (Remote host closed the connection)
03:09:30  <tjfontaine>ya, though I'm kinda worried it feels like a generic child process problem
03:10:47  <isaacs>well, a generic "sent a port to a child proc" problem, anyway
03:10:55  <tjfontaine>right
03:19:28  * wolfeidaujoined
03:26:52  * c4miloquit (Remote host closed the connection)
03:27:18  * c4milojoined
03:30:57  * wolfeida_joined
03:32:04  * c4miloquit (Ping timeout: 248 seconds)
03:34:09  * wolfeidauquit (Ping timeout: 256 seconds)
03:37:30  * kazuponjoined
03:46:16  * defunctzombiechanged nick to defunctzombie_zz
03:47:46  * qmxchanged nick to qmx|away
03:54:44  * wolfeida_quit (Remote host closed the connection)
04:07:16  * indexzeroquit (Quit: indexzero)
04:31:23  * trevnorrisjoined
04:53:47  * brsonquit (Quit: leaving)
05:46:20  * mikealquit (Quit: Leaving.)
05:46:58  * mikealjoined
06:20:05  * defunctzombie_zzchanged nick to defunctzombie
06:28:15  * bradleymeckquit (Quit: bradleymeck)
06:36:32  * kevireillyquit (Remote host closed the connection)
06:36:41  * defunctzombiechanged nick to defunctzombie_zz
06:36:59  * kevireillyjoined
06:40:50  <trevnorris>ircretary: hi
06:40:50  <ircretary>trevnorris: Hello :)
06:41:05  * bradleymeckjoined
06:43:26  <trevnorris>indutny: um. think I asked ircretary to ask you something when I meant it as a reminder to me to ask you... yeah. it's late.
07:05:15  * wolfeidaujoined
07:19:11  * luxigoquit (Ping timeout: 245 seconds)
07:20:35  * stagasjoined
07:52:06  * bradleymeckquit (Quit: bradleymeck)
08:12:10  * rendarjoined
08:14:58  * trevnorrisquit (Quit: Leaving)
08:36:42  * stagas_joined
08:38:02  * stagasquit (Ping timeout: 258 seconds)
08:38:07  * stagas_changed nick to stagas
08:51:49  * mmaleckichanged nick to mmalecki[zzz]
10:05:21  * `3rdEdenjoined
10:06:11  * Kakerajoined
10:50:08  * hzjoined
11:03:25  * V1joined
11:03:55  * `3rdEdenquit (Disconnected by services)
11:03:56  * V1changed nick to `3rdEden
11:18:20  * wolfeidauquit (Remote host closed the connection)
11:18:52  * wolfeidaujoined
11:53:53  * bnoordhuisjoined
12:26:21  <MI6>joyent/node: Ben Noordhuis v0.10 * 50b6549 : doc: update CONTRIBUTING.md * Latest stable is v0.10 now. * Add example - http://git.io/G4JdrQ
12:26:35  * kevireillyquit (Read error: Connection reset by peer)
12:26:51  * kevireillyjoined
12:29:47  <MI6>joyent/node: Ben Noordhuis v0.10 * 329b538 : doc: update CONTRIBUTING.md * Latest stable is v0.10 now. * Add example - http://git.io/knxYPA
12:29:48  <bnoordhuis>missed a reference to v0.8
12:36:28  * mraleph1quit (Read error: Connection reset by peer)
12:36:32  * mralephjoined
12:39:52  * mralephquit (Client Quit)
12:40:32  * mralephjoined
12:42:49  <MI6>nodejs-v0.10: #59 UNSTABLE osx-x64 (1/565) windows-x64 (6/565) osx-ia32 (2/565) smartos-ia32 (1/565) windows-ia32 (4/565) http://jenkins.nodejs.org/job/nodejs-v0.10/59/
12:59:24  <MI6>nodejs-v0.10: #60 UNSTABLE windows-x64 (5/565) osx-ia32 (2/565) smartos-x64 (1/565) smartos-ia32 (1/565) windows-ia32 (4/565) http://jenkins.nodejs.org/job/nodejs-v0.10/60/
13:01:52  * luxigojoined
13:17:49  * dostoyevskyquit (Quit: leaving)
13:31:47  * dostoyevskyjoined
13:32:36  <dostoyevsky>What should I do if I cannot allocate anymore memory for uv_read?
13:32:52  <dostoyevsky>I get: uv__read: Assertion `buf.len > 0' failed.
13:33:13  <dostoyevsky>I would like the cancel the read and then reconnect to the server..
13:36:04  <cjd>keep a tiny buffer around for just suck an occasion?
13:36:43  <cjd>but indeed you bring up a good point that possibly you would want to kill the read during the allocate callback
13:37:47  <dostoyevsky>cjd: I don't do any allocation there... I just keep a static buffer that has a certain size
13:37:56  <bnoordhuis>dostoyevsky: what cjd said. if you open an issue, maybe we can change it that returning a zero-length buffer disables the read
13:38:08  <dostoyevsky>And it should be enough for most things but if it doesn't I just want to cancel
13:38:35  <bnoordhuis>i'm fine with a change like that but i bet it's hairy on windows
13:38:41  <dostoyevsky>Yeah, I see from the code that there is no way to do what I want right now...
13:49:04  * dominictarrjoined
14:03:45  <MI6>joyent/node: Ben Noordhuis v0.10 * 8632af3 : tools: update gyp to r1601 Among other things, this should make it easie - http://git.io/-Ee7UQ
14:41:59  * qmx|awaychanged nick to qmx
14:42:43  * qmxchanged nick to qmx|away
15:09:39  * bnoordhuisquit (Ping timeout: 256 seconds)
15:13:08  * ericktjoined
15:20:25  * stagas_joined
15:22:00  * stagasquit (Ping timeout: 260 seconds)
15:22:06  * stagas_changed nick to stagas
15:23:45  * `3rdEdenquit (Remote host closed the connection)
15:30:39  * c4milojoined
15:33:10  * c4miloquit (Remote host closed the connection)
15:38:26  * c4milojoined
15:41:35  * CoverSlidequit (Read error: Connection reset by peer)
15:54:21  * `3rdEdenjoined
15:55:17  * AvianFlujoined
16:00:02  * indexzerojoined
16:02:36  * `3rdEdenquit (Ping timeout: 260 seconds)
16:03:19  * defunctzombie_zzchanged nick to defunctzombie
16:15:07  <isaacs>this child-process-fork-getconnections test on mac is really making me a bit insane...
16:15:54  <isaacs>wiresharked it, and a) every packet has a bad checksum and b) there's never a plain old FIN sent, always a FIN/ACK, so why the hell are we reading an EOF??
16:16:16  * bnoordhuisjoined
16:16:32  * mikealquit (Quit: Leaving.)
16:21:05  * bnoordhuisquit (Ping timeout: 258 seconds)
16:22:28  * bradleymeckjoined
16:37:52  * ericktquit (Quit: erickt)
16:42:04  <tjfontaine>isaacs: I would bet that a checksum isn't being done for local traffic, you might as well turn that verification off
16:43:27  <isaacs>ah, yeah
16:43:31  <isaacs>that makes sense
16:43:45  <isaacs>the traffic looks identical in both cases, though
16:44:37  <tjfontaine>a finack means a graceful shutdown of the tcp connection?
16:44:57  <isaacs>it should go, FIN, FIN/ACK, ACK
16:45:08  <isaacs>if it's a graceful shutdown
16:46:29  <tjfontaine>right
16:46:45  * mikealjoined
16:47:37  * hzquit
16:49:03  <isaacs>oh, but we're not doing graceful shutdowns anyway...
16:49:12  <isaacs>we just do socket.destroy() in the child if we get the messag
16:49:24  <isaacs>and the same thing happens if the child crashes, and i'm doing an assert to make sure it's going ok...
16:49:27  <isaacs>alright
16:49:36  <tjfontaine>this random thread agrees with that http://marc.info/?l=linux-netdev&m=134409837229053&w=2
16:49:37  <isaacs>but still, i'm NOT getting a FIN from the client, so why do I get an EOF??
16:50:58  <isaacs>in the application, it does read() and gets 0 bytes, which means "the other side sent a FIN", but that's not actually happening.
16:51:09  <isaacs>again, all signs point towards a bug in the OS X tcp stack
16:51:27  <isaacs>or a bug in my understanding of TCP, which is probably more likely ;)
16:51:33  <isaacs>or in uv or in node
16:52:15  <tjfontaine>heh
16:52:54  <tjfontaine>so you would expect uv/read to report econnreset or einval instead of eof?
16:53:04  * bradleymeckquit (Quit: bradleymeck)
16:57:24  * dominictarrquit (Quit: dominictarr)
16:57:29  <MI6>nodejs-v0.10: #61 ABORTED smartos-ia32 (1/565) linux-ia32 (1/565) http://jenkins.nodejs.org/job/nodejs-v0.10/61/
16:57:50  <tjfontaine>that gyp upgrade isn't behaving well
16:58:50  <isaacs>tjfontaine: well, no, i would expect it to not fall out of the read() loop, because the other side HASN'T sent a fin packet, or closed the connection, or reset.
16:58:51  <tjfontaine>ircretary: tell bnoordhuis the gyp upgrade made windows unhappy http://jenkins.nodejs.org/job/nodejs-v0.10/DESTCPU=ia32,label=windows/61/console and seems to have broken for the osx buildslave, but works fine locally
16:58:51  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
16:59:12  <tjfontaine>isaacs: hm right
17:00:20  <isaacs>we should write our own tcp stack
17:00:20  <tjfontaine>oh the gyp upgrade now expects xcodebuild to be there
17:00:23  <isaacs>in JavaScript
17:00:26  <tjfontaine>NIH ALL THE THINGS
17:00:27  <LOUDBOT>FUCK YOU I WON'T DO IT
17:00:30  <tjfontaine>heh
17:00:37  <isaacs>UDP stack, too
17:01:09  <isaacs>we should just create JavaScript bindings to all the hardware interrupts, and talk directly to the machine
17:01:22  <tjfontaine>nodejs-kernel
17:01:25  <isaacs>operating systems are an antipattern
17:01:40  * dominictarrjoined
17:02:06  <tjfontaine>yup it now uses xcodebuild to detect sdk https://github.com/joyent/node/compare/329b5388ba5a...8632af381e70#L19R226
17:12:38  <MI6>nodejs-v0.10: #62 ABORTED linux-x64 (1/565) smartos-ia32 (1/565) http://jenkins.nodejs.org/job/nodejs-v0.10/62/
17:16:17  <isaacs>so, i think the next step here is to write a standalone C program that does the same thing as this test, and see if we can get it to fail in the same way
17:16:31  <isaacs>then at least, I'll have something to put in a bug report to aapl
17:22:55  * bnoordhuisjoined
17:25:50  * kevireillyquit (Ping timeout: 245 seconds)
17:27:08  * dominictarrquit (Quit: dominictarr)
17:29:03  * dominictarrjoined
17:33:31  * dominictarrquit (Client Quit)
17:35:21  <tjfontaine>isaacs: ya
17:35:29  <tjfontaine>or it could be something else entirely :)
17:40:34  * jez0990quit (Ping timeout: 252 seconds)
17:43:00  * mikealquit (Read error: Connection reset by peer)
17:43:36  * mikealjoined
17:51:23  * c4milo_joined
17:52:27  * AvianFluquit (Remote host closed the connection)
17:55:38  * kazuponquit (Remote host closed the connection)
17:56:32  * bradleymeckjoined
17:58:00  * bradleymeckquit (Client Quit)
17:59:55  * `3rdEdenjoined
18:00:26  * mikealquit (Quit: Leaving.)
18:02:41  * jez0990joined
18:03:08  <dostoyevsky>If I call uv_read_stop and uv_close in alloc_cb when in uv__read and then introduce a termination flag to the loop when "buf.len == 0" would this work as intended?
18:11:53  <dostoyevsky>I'Ve also opened an issue on this: https://github.com/joyent/libuv/issues/752
18:17:14  * bnoordhuisquit (Ping timeout: 252 seconds)
18:25:34  * `3rdEdenquit (Remote host closed the connection)
18:26:09  * kazuponjoined
18:36:36  * mikealjoined
18:56:08  * `3rdEdenjoined
19:00:29  * indexzeroquit (Quit: indexzero)
19:04:11  * `3rdEdenquit (Ping timeout: 245 seconds)
19:13:21  * `3rdEdenjoined
19:18:52  * c4miloquit (Remote host closed the connection)
19:19:18  * c4milojoined
19:19:35  * c4milo_quit (Remote host closed the connection)
19:23:27  * bnoordhuisjoined
19:24:10  * c4miloquit (Ping timeout: 260 seconds)
19:28:07  * c4milojoined
19:28:24  * bnoordhuisquit (Ping timeout: 264 seconds)
19:37:51  * browndavjoined
19:38:51  * c4miloquit (Remote host closed the connection)
19:39:23  <browndav>hi -- I'm working with a simple node.js native module that calls a blocking function (flock, in this case) in a function invoked via uv_queue_work(uv_default_loop(), ...). Do I need to explicitly uf_ref or uv_unref anything, or does uv_queue_work() take care of that?
19:39:45  <browndav>fwiw, there's not anything else long-running that'd require node to stay running
19:40:29  <browndav>thanks in advance if anyone knows off the top of their head
19:41:09  * hzjoined
19:41:14  <browndav>this is for node v0.8.22 and v0.10.1
19:46:02  * brsonjoined
19:48:00  * kazuponquit (Remote host closed the connection)
19:53:11  * bradleymeckjoined
19:54:43  * c4milojoined
19:55:08  * qmx|awaychanged nick to qmx
20:02:50  * cjdquit (Quit: Lost terminal)
20:03:39  * browndavpart
20:17:17  <tjfontaine>bradleymeck: uv_queue_work will handle the reference handling, don't worry about it unless you specifically want the op to not keep the loop open
20:17:50  <bradleymeck>?
20:17:53  <tjfontaine>sorry
20:18:02  <tjfontaine>didn't realize browndav left
20:18:05  <tjfontaine>br<tab> fail
20:18:24  <tjfontaine>bradleymeck: continue about your day :)
20:18:36  * kazuponjoined
20:22:02  <bradleymeck>i wish tab complete would have some check to see who you recently referenced, i do that all the time
20:22:29  <tjfontaine>it generally does, but the part gets in the way
20:22:35  <tjfontaine>at least in irssi anyway
20:23:35  * kazuponquit (Ping timeout: 256 seconds)
20:27:16  <bradleymeck>need to find a better way to get gyp to invoke cmake...
20:27:43  <tjfontaine>you must be in an interesting world
20:28:40  <bradleymeck>https://github.com/bmeck/uvcat , putting curl and libuv together
20:28:51  <bradleymeck>curl's cmake is very angry at gyp
20:29:02  <bradleymeck>been trying to move this damn thing to gyp for 2 days
20:44:37  * qmxchanged nick to qmx|away
20:45:15  * defunctzombiechanged nick to defunctzombie_zz
20:58:38  * c4miloquit (Remote host closed the connection)
21:10:31  * trevnorrisjoined
21:19:20  * kazuponjoined
21:19:28  * defunctzombie_zzchanged nick to defunctzombie
21:21:11  <trevnorris>helloooo out there.
21:23:35  <MI6>joyent/node: isaacs v0.10 * c0d5001 : stream: Fix early end in Writables on zero-length writes Doing this caus - http://git.io/wy6PLg
21:27:47  * bnoordhuisjoined
21:27:47  * kazuponquit (Ping timeout: 252 seconds)
21:31:54  <bnoordhuis>tjfontaine: weird that the new gyp breaks on windows
21:32:26  <bnoordhuis>looks like it's failing to link to gdi32.lib or kernel32.lib
21:33:56  <bnoordhuis>and user32.lib, it seems
21:36:29  <MI6>nodejs-v0.10: #63 ABORTED smartos-ia32 (1/566) http://jenkins.nodejs.org/job/nodejs-v0.10/63/
21:39:45  <tjfontaine>bnoordhuis: this sounds familiar, I think bert might have fixed this already on master
21:41:27  <bnoordhuis>tjfontaine: he did? wasn't that the /SAFESEH thing?
21:42:46  <tjfontaine>well there was something else we hit, that had to do with a gyp version difference, which we weren't seeing on 0.8 but were on master/v0.10 because we nolonger use a specific svn rev but a git checkout
21:43:09  <tjfontaine>oh it was libuv that he fixed it in
21:43:31  <bnoordhuis>right. i remember that one
21:44:54  * hzquit
21:45:44  <bnoordhuis>i guess it's https://codereview.chromium.org/12256017
21:46:12  <bnoordhuis>oh hah, that's the same changeset bert mentions in his libuv commit log
21:46:27  <tjfontaine>heh
21:48:25  <bnoordhuis>tjfontaine: when i create a new branch, jenkins will try and build that, right?
21:48:53  <tjfontaine>no, but I have a job there designed that will prompt you to enter the branch you want to build
21:49:41  <bnoordhuis>sweet
21:50:17  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-oneoff/build
21:51:18  <tjfontaine>I'm pretty sure I could make it so that you could specify a label as well, but for now I think it's still pinned to windows anyway
21:51:33  <trevnorris>bnoordhuis: so it turns out the most expensive operations are creating a Persistent handle and setting it as an internal field.
21:53:39  <trevnorris>those two operations are ~60-70% of execution time for a new buffer.
21:56:09  <isaacs>bnoordhuis: you have a mac laptop these days, right?
21:58:45  <MI6>joyent/node: bnoordhuis created branch fix-windows-build - http://git.io/wVWnCw
21:59:01  <bnoordhuis>isaacs: yep
21:59:08  <isaacs>test/simple/test-child-process-fork-getconnections.js failing on ia32 mac is making me a bit crazy
21:59:16  <bnoordhuis>tjfontaine: where do i start that job?
21:59:25  <bnoordhuis>isaacs: only ia32, not x64?
21:59:27  <isaacs>bnoordhuis: it'd be good if you could take a look at it when you get a chance.
21:59:32  <isaacs>i've only seen it fail on ia32
21:59:34  <isaacs>not on x4
21:59:37  <isaacs>x64
21:59:52  <bnoordhuis>okay. i think i've seen it fail on x64 but i might me misremembering that
21:59:52  <isaacs>and only ~1% of the time, unless you're the jenkins build machine, then ti's close to 100% of the time
22:00:08  <bnoordhuis>i'll look at it tonight or tomorrow
22:00:24  <isaacs>i've got a branch where i've made the test more noisy, fixing-test-child-process-fork-getconnections
22:00:24  <bnoordhuis>trevnorris: what are you referring to?
22:00:26  <tjfontaine>bnoordhuis: the link I pasted above? are you logged in?
22:00:37  <bnoordhuis>oh, you pasted a link
22:00:47  * bnoordhuisblushes
22:00:49  <isaacs>bnoordhuis: afaict, looking at wireshark, we are not sending a FIN from the client. however, the server sees EOF anyway
22:01:12  <bnoordhuis>isaacs: you saw read() return 0 with dtruss or dtrace?
22:01:24  <isaacs>bnoordhuis: dtruss, and also by putting a fprintf in libuv
22:01:29  <bnoordhuis>okay
22:01:29  <trevnorris>bnoordhuis: new allocator i'm working on. thought I was doing awesome and all until i realized v8 was gc-ing the objects immediately because the persistent handles weren't being attached to js objects.
22:01:31  <isaacs>bnoordhuis: but dtruss is dtrace
22:01:31  <tjfontaine>isaacs: is it possible for osx to have a special case for lo such that it doesn't send FIN?
22:01:58  <isaacs>the wireshark output looks identical for success and for failure.
22:02:10  <trevnorris>that operation alone doubled execution time.
22:02:12  <isaacs>but for the failure case, i'd expdect that a FIN was sent TO the 12346 peer
22:02:23  <isaacs>since that's the one getting the EOF
22:02:35  <bnoordhuis>tjfontaine: nice, it just works
22:02:41  * wolfeidauquit (Remote host closed the connection)
22:02:57  <isaacs>if it's an apple error, then we can send it to cupertino, but probably not without a more minimized test case (ie, no uv or node)
22:03:28  <bnoordhuis>an os x kernel bug? unheard of!
22:03:32  <isaacs>hahah
22:03:43  <isaacs>if that's what it is, i'm ok just clubbing the test, or doing whatever hacky workaround we need to do
22:03:53  <isaacs>but we need to establish it's not our problem, first.
22:03:58  <bnoordhuis>yep
22:04:11  <isaacs>you're a bit more familiar with the uv internals in this area, so maybe there's something there you'll see that i missed.
22:04:39  <isaacs>also, it could be somehow related to the same thing that's causing ia32 to fail test-writefloat.js and test-writedouble.js every time
22:05:06  <isaacs>in any event, if we can get our tests green across the board, we can reject pull requests much more efficiently.
22:05:07  <bnoordhuis>trevnorris: re persistent handles, i'm not following. when an object is persistent, it's persistent until you Dispose() it
22:05:17  <bnoordhuis>unless you also MakeWeak() it
22:06:12  <bnoordhuis>but then your callback gets called when it's gc'ed
22:06:52  <trevnorris>each object that you attach data to must have the persistent attached or v8 immediately calls the makeweak callback,
22:06:58  * `3rdEdenquit (Remote host closed the connection)
22:07:42  <bnoordhuis>right. now it makes more sense :)
22:08:30  <dostoyevsky>I kind of like to use libuv with C++11 lambdas
22:09:35  <isaacs>ok, i'm off to run errands and watch Oz
22:09:43  <isaacs>have fun, Node Heroes
22:09:51  <tjfontaine>the great and powerful, or the HBO series? :)
22:09:54  * trevnorrisquit (Quit: Leaving)
22:11:05  <tjfontaine>bnoordhuis: ok that seems to have fixed windows
22:12:34  <tjfontaine>also graphviz-repl is a cute little module
22:13:06  * defunctzombiechanged nick to defunctzombie_zz
22:13:40  * dominictarrjoined
22:15:32  * mikealquit (Quit: Leaving.)
22:16:09  <bnoordhuis>dostoyevsky: you can, can't you?
22:17:07  <MI6>joyent/node: Ben Noordhuis v0.10 * 690a8cc : deps: fix openssl build on windows Commit 8632af3 ("tools: update gyp to - http://git.io/A7RsBA
22:17:51  * wolfeidaujoined
22:17:58  <dostoyevsky>bnoordhuis: I've written a quite nice C++ wrapper based on libuv where I can use lambdas quite nicely. Like server->get("key", [](const char* value) { /* do somethign with value */ })
22:19:29  <dostoyevsky>The only problem is that you need to get the capturing part of the lambda right. Because at the time your lambda is called other variables that you are refering too might be already destroyed, so you need to use the copy & capture correctly. But once you got this, it's very nice. :)
22:21:52  * kazuponjoined
22:23:15  <dostoyevsky>But finding out you are doing it wrong involves quite a lot of debugging and coredumps won't be really helpful at all... There doesn't seem to be much support yet for using lambdas after local variables have been deleted from the stack... That probably needs to change before it will be as nice to use as in JavaScript
22:23:45  <bnoordhuis>isaacs: okay, confirmed. also happens with x64 builds
22:24:23  <bnoordhuis>dostoyevsky: that's the bleeding edge for you, a harsh environment
22:24:50  * rendarquit
22:25:00  <dostoyevsky>bnoordhuis: Do you think so?
22:25:35  <tjfontaine>bnoordhuis: ya I've seen it happen with x64, it's just been easier to reproduce on ia32 (also when underload)
22:26:22  <bnoordhuis>it happens more often with ia32? or is it because of system load?
22:26:28  * kazuponquit (Ping timeout: 248 seconds)
22:27:59  <tjfontaine>without adding load, it was easier to hit with ia32, isaacs then started running things like `make doc` etc in another terminal and was hittig it more often, then once he started to add his debugging to it and running with dtruss -n node he was hitting it nearly every time
22:28:32  <dostoyevsky>What one can do already in C++ right now is something like: ``uv_close(stream, [](uv_handle_t* h) { /* something */ })''
22:28:50  <dostoyevsky>But if you were to support C++ you could make capturing lambdas available
22:29:30  <dostoyevsky>So one could write: ``uv_close(stream, [this](uv_handle_t* h) { this->doSomething() })''
22:30:03  <dostoyevsky>I don't think you would need to change much to get capturing lambdas for C++
22:31:35  <bnoordhuis>dostoyevsky: is that a suggestion for a change in libuv or ?
22:32:12  <dostoyevsky>bnoordhuis: Just an idea. But I am not sure what your plans are for libuv, or whether you consider C++ lambdas interesting at all...
22:32:30  <dostoyevsky>I mean C has a certain simplicity
22:32:58  <dostoyevsky>And C++ is a moving target kind of. ;-)
22:33:20  <dostoyevsky>And you already have the lambda stuff in JavaScript
22:33:39  <bnoordhuis>dostoyevsky: right. libuv is pure c and will remain that way
22:33:47  <bnoordhuis>you're free to add a c++ shim, of course
22:43:16  * dominictarrquit (Quit: dominictarr)
22:43:45  <bnoordhuis>i'm having a complete mind blankout
22:43:57  <bnoordhuis>how do i open a new buffer in vim that's not tied to any file?
22:45:00  <bnoordhuis>:e requires a file name, which is not quite what i want
22:45:25  <tjfontaine>:vnew
22:45:35  <tjfontaine>if you're into split views
22:46:23  <bnoordhuis>i guess that'll do, thanks
22:46:45  * mikealjoined
22:47:02  <bnoordhuis>are my recollections of :bnew the result of fever dreams?
22:48:04  <tjfontaine>heh perhaps
22:51:36  * mikealquit (Ping timeout: 276 seconds)
23:13:09  <bnoordhuis>i think i found at least one core bug thanks to that fork-getconnections test
23:13:12  <bnoordhuis>the parent first sends the child x handles
23:13:16  <bnoordhuis>then it sends the child x 'close socket x' commands
23:13:19  <bnoordhuis>it's interesting that the first command has a raw socket handle attached to it
23:13:38  <bnoordhuis>whereas the other commands don't
23:14:08  <bnoordhuis>[44964] child new fd=22
23:14:08  <bnoordhuis>[44964] child new fd=23
23:14:08  <bnoordhuis>[44964] child close id=0 fd=23
23:14:08  <bnoordhuis>[44963] zero read (fd=14 shadow=-1)
23:14:08  <bnoordhuis>[m] CLIENT: close event
23:14:50  * KiNgMaRquit (Ping timeout: 264 seconds)
23:14:52  * bradleymeck_joined
23:15:00  <bnoordhuis>[44964] child close id=1 fd=<no handle>
23:15:00  <bnoordhuis>the 'new' messages are the parent sending the handles
23:15:00  <bnoordhuis>the first close message has a socket with fd=23 attached that it's already received
23:15:04  <bnoordhuis>the next close message has no handle (and neither do the ones after that)
23:15:04  * isaacs_joined
23:15:10  * bradleymeckquit (Ping timeout: 260 seconds)
23:15:10  * bradleymeck_changed nick to bradleymeck
23:15:47  * einarosquit (Ping timeout: 260 seconds)
23:16:02  * einarosjoined
23:16:42  * KiNgMaRjoined
23:17:16  <tjfontaine>bnoordhuis: this is a cross platform bug?
23:18:18  * mikealjoined
23:19:08  * benoitcquit (Excess Flood)
23:19:13  * chilts_joined
23:20:33  * philipsquit (*.net *.split)
23:20:33  * CAPSLOCKBOTquit (*.net *.split)
23:20:33  * chiltsquit (*.net *.split)
23:20:33  * isaacsquit (*.net *.split)
23:21:37  * philips_joined
23:22:33  * kazuponjoined
23:23:37  * philips_changed nick to philips
23:23:46  * hij1nxquit (Ping timeout: 248 seconds)
23:23:47  * wavded_quit (Ping timeout: 248 seconds)
23:23:56  * Kakeraquit (Ping timeout: 256 seconds)
23:24:14  * hij1nxjoined
23:24:36  * isaacs_changed nick to Guest88068
23:25:17  <bnoordhuis>tjfontaine: i don't think it's the source of the failure on os x
23:25:24  <bnoordhuis>but it is a bug, yes
23:25:51  * benoitcjoined
23:25:53  * eris0xffquit (Ping timeout: 245 seconds)
23:26:45  <bnoordhuis>cross platform even :)
23:27:06  <tjfontaine>ya, I have a feeling that what you're describing is the source of at least one of the windows errors :)
23:29:16  * kazuponquit (Ping timeout: 256 seconds)
23:30:46  <bnoordhuis>it might also explain the failure on os x
23:31:06  <bnoordhuis>i think it's reading more than one message off the socket/pipe
23:31:15  <tjfontaine>ah
23:31:19  <bnoordhuis>but it might not recvmsg all the fds
23:33:35  <MI6>joyent/node: bnoordhuis created branch tjfontaine-review-this - http://git.io/Wge87Q
23:34:29  <bnoordhuis>c'mon MI6
23:34:54  <tjfontaine>hehe, what's mi6 missing?
23:35:20  * chrisdickinsonquit (Ping timeout: 264 seconds)
23:35:26  <bnoordhuis>tjfontaine: https://github.com/joyent/node/compare/v0.10...tjfontaine-review-this
23:35:33  <bnoordhuis>that ^ :)
23:35:42  <tjfontaine>[03-24] 19:33:35 < MI6> joyent/node: bnoordhuis created branch tjfontaine-review-this - http://git.io/Wge87Q
23:35:45  <tjfontaine>that's what that was?
23:36:07  <tjfontaine>anyway, I am testing this change against windows on a hunch :)
23:36:11  <bnoordhuis>00:35:26 < MI6> joyent/node: bnoordhuis created branch tjfontaine-review-this - http://git.io/Wge87Q
23:36:21  <bnoordhuis>for some reason it only showed up for me now
23:36:26  <bnoordhuis>maybe a freenode hiccup
23:36:35  <tjfontaine>oh, TCP, it's hard...
23:36:47  * chrisdickinsonjoined
23:47:58  <tjfontaine>bnoordhuis: hm, well no that didn't solve either of the windows ones I was hoping for unfortunately :) I'll see if I can get the other test to fail
23:51:44  * dostoyev1kyjoined
23:52:06  * Guest88068quit (*.net *.split)
23:52:06  * bnoordhuisquit (*.net *.split)
23:52:06  * dostoyevskyquit (*.net *.split)
23:52:19  * rvaggquit (Ping timeout: 264 seconds)
23:52:37  * isaacsjoined
23:52:46  * rvaggjoined
23:53:00  <tjfontaine>hmm doesn't fix test-child-process-fork-net2.js either unfortunately
23:53:01  * isaacschanged nick to Guest62188
23:57:47  * brsonquit (Remote host closed the connection)
23:57:48  * dscapequit (*.net *.split)
23:57:52  * chilts_quit (*.net *.split)
23:57:53  * othiym23quit (*.net *.split)
23:57:53  * brucemquit (*.net *.split)
23:57:53  * indutnyquit (*.net *.split)