00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:43  * philipsquit (Ping timeout: 264 seconds)
00:01:54  * dostoyev1kyquit (Quit: leaving)
00:02:43  * dscapejoined
00:02:53  * dpemmonsquit (Excess Flood)
00:03:10  * dpemmonsjoined
00:03:57  * chiltsjoined
00:03:58  * othiym23joined
00:03:58  * indutnyjoined
00:03:58  * brucemjoined
00:04:02  * bnoordhuisjoined
00:07:27  <tjfontaine>having fun enjoying the netsplits?
00:08:39  <tjfontaine>bnoordhuis: the other failure I was hoping that fix might solve was test-child-process-fork-net2.js but no such luck on that one either
00:08:53  * othiym23quit (Ping timeout: 272 seconds)
00:10:41  <bnoordhuis>so i never realized it
00:10:50  <bnoordhuis>but the way we send over handles in node is wrong
00:11:05  <tjfontaine>how wrong is wrong?
00:11:22  <bnoordhuis>so wrong it breaks every ~1000 runs :)
00:11:25  * defunctzombie_zzchanged nick to defunctzombie
00:11:28  <tjfontaine>:)
00:11:38  <bnoordhuis>you need a dedicated channel where you send over fds with a one-byte payload
00:11:58  <bnoordhuis>and the other end reads one-byte messages
00:12:21  <bnoordhuis>what we do now is send a json message + fd
00:12:36  <bnoordhuis>the issue is that multiple json messages can queue up
00:12:49  <bnoordhuis>when the reader reads, it reads them all - but receives only the first fd
00:13:45  * defunctzombiechanged nick to defunctzombie_zz
00:13:57  * indutnyquit (Ping timeout: 272 seconds)
00:14:20  * indutnyjoined
00:14:24  <tjfontaine>and things queue up more reliably when they're observed/under-load?
00:14:47  * toothrotquit (Ping timeout: 240 seconds)
00:15:18  * brucemquit (Ping timeout: 272 seconds)
00:15:19  * othiym23joined
00:15:22  <bnoordhuis>tjfontaine: yes, seems that way
00:15:40  <bnoordhuis>it happens when the reader gets backlogged, then catches up
00:16:10  * toothrjoined
00:16:11  <bnoordhuis>i guess a strategically placed sleep(1) would have the same effect
00:16:11  <tjfontaine>so will you keep the json channel as a notification channel and then read off the fds from the handle channel?
00:16:29  <bnoordhuis>not sure yet. i'll have to think it over
00:16:39  * toothrchanged nick to toothrot
00:16:40  <tjfontaine>k
00:17:00  * brucem_joined
00:17:11  <bnoordhuis>maybe i can do some cleverness in libuv like recvmsg() a single byte first
00:17:19  <bnoordhuis>then if there's no fd, read the rest
00:17:27  <bnoordhuis>but that's not entirely fool-proof
00:17:43  <bnoordhuis>also, slow
00:18:40  * philipsjoined
00:21:22  * benoitcquit (Excess Flood)
00:22:28  * benoitcjoined
00:22:58  * bnoordhuisquit (*.net *.split)
00:24:16  * stagasquit (*.net *.split)
00:24:16  * stephankquit (*.net *.split)
00:24:16  * DrPizzaquit (*.net *.split)
00:25:19  * kazuponjoined
00:30:51  * skebcio_joined
00:31:03  * DrPizzajoined
00:31:03  * stephankjoined
00:31:06  * kazuponquit (Ping timeout: 276 seconds)
00:31:44  * benoitcquit (Ping timeout: 245 seconds)
00:41:36  * DrPizzaquit (Ping timeout: 264 seconds)
00:41:36  * DrPizzajoined
00:41:44  * indutnytopic: And we're going to die at "liberal utopian vacation" day. ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
00:45:25  * stagasjoined
00:45:25  * rphillipsjoined
00:45:25  * benoitcjoined
00:45:25  * bnoordhuisjoined
00:45:25  * defunctzombie_zzjoined
00:45:25  * DrPizzajoined
00:45:25  * stephankjoined
00:45:25  * skebcio_joined
00:45:25  * philipsjoined
00:45:25  * brucem_joined
00:45:25  * toothrotjoined
00:45:25  * othiym23joined
00:45:25  * chiltsjoined
00:45:25  * dscapejoined
00:45:25  * ircretaryjoined
00:45:25  * rvaggjoined
00:45:25  * Guest62188joined
00:45:25  * chrisdickinsonjoined
00:45:25  * hij1nxjoined
00:45:25  * mikealjoined
00:45:25  * KiNgMaRjoined
00:45:25  * einarosjoined
00:45:25  * bradleymeckjoined
00:45:25  * wolfeidaujoined
00:45:25  * jez0990joined
00:45:25  * luxigojoined
00:45:25  * mralephjoined
00:45:25  * russell_hjoined
00:45:25  * creationixjoined
00:45:25  * txdvjoined
00:45:25  * kuplatupsujoined
00:45:25  * dsantiagojoined
00:45:25  * LOUDBOTjoined
00:45:25  * davispjoined
00:45:25  * saghuljoined
00:45:25  * Raltjoined
00:45:25  * niska`joined
00:45:25  * mmalecki[zzz]joined
00:45:25  * Chip_Zerojoined
00:45:25  * ryahjoined
00:45:25  * qmx|awayjoined
00:45:25  * Raynosjoined
00:45:25  * tellnesjoined
00:45:25  * tjfontainejoined
00:45:25  * pquernajoined
00:45:25  * chobiejoined
00:45:25  * rjejoined
00:45:25  * joclekjoined
00:46:23  * indutnyquit (Ping timeout: 258 seconds)
00:46:55  * brsonjoined
00:47:57  * joshthecoderjoined
00:49:25  * indutnyjoined
00:50:28  * indutnychanged nick to 65MAAQJJ5
00:50:29  * indutnyjoined
00:50:29  * indutnyquit (Changing host)
00:50:29  * indutnyjoined
00:50:32  * indutnyquit (Ping timeout: 258 seconds)
00:51:08  * saghulquit (Ping timeout: 264 seconds)
01:00:59  * AvianFlujoined
01:07:47  * russell_hquit (Ping timeout: 258 seconds)
01:09:39  * russell_hjoined
01:15:32  * dscapequit (Ping timeout: 264 seconds)
01:17:28  * qmx|awaychanged nick to qmx
01:19:34  * wavded_joined
01:20:20  * dscapejoined
01:31:34  * kazuponjoined
01:31:38  * benoitcquit (Excess Flood)
01:31:43  * 65MAAQJJ5quit (*.net *.split)
01:31:43  * joshthecoderquit (*.net *.split)
01:31:43  * chiltsquit (*.net *.split)
01:31:45  * joshthecoderjoined
01:31:46  * kazuponquit (Ping timeout: 252 seconds)
01:32:21  * benoitcjoined
01:33:38  * dscapequit (*.net *.split)
01:34:03  * indutnyjoined
01:34:51  * chiltsjoined
01:38:40  * abraxasjoined
01:40:51  * wavded__joined
01:40:53  * chiltsquit (Ping timeout: 256 seconds)
01:41:05  * wavded_quit (Ping timeout: 256 seconds)
01:41:07  * stagasquit (Ping timeout: 240 seconds)
01:41:07  * joshthecoderquit (Ping timeout: 240 seconds)
01:41:25  * stagasjoined
01:49:56  * benoitcquit (Excess Flood)
01:49:59  * chiltsjoined
01:50:01  * benoitcjoined
01:50:03  * abraxasquit (Remote host closed the connection)
01:50:18  * joshthecoderjoined
02:00:13  * qmxchanged nick to qmx|away
02:00:14  * bnoordhuisquit (Ping timeout: 256 seconds)
02:00:45  * benoitcquit (Ping timeout: 264 seconds)
02:00:47  * benoitcjoined
02:09:38  * russell_hquit (Excess Flood)
02:09:42  * stagas_joined
02:09:42  * stagasquit (Ping timeout: 276 seconds)
02:09:42  * stagas_changed nick to stagas
02:09:43  * chiltsquit (Ping timeout: 258 seconds)
02:09:44  * brucem_changed nick to brucem
02:10:59  * russell_hjoined
02:13:52  * chiltsjoined
02:33:51  * abraxasjoined
02:33:51  * chiltsquit (Remote host closed the connection)
02:34:31  * brsonquit (Quit: leaving)
02:34:33  * indutnyquit (Ping timeout: 256 seconds)
02:34:42  * abraxas_joined
02:34:44  * benoitcquit (Excess Flood)
02:34:46  * c4milojoined
02:34:53  * russell_hquit (*.net *.split)
02:35:05  * abraxasquit (Ping timeout: 252 seconds)
02:35:24  * kazuponjoined
02:36:32  * abraxas_quit (Remote host closed the connection)
02:36:42  * chiltsjoined
02:36:51  * indutnyjoined
02:45:39  * russell_hjoined
02:46:41  * benoitcjoined
02:48:18  * chobiequit (Ping timeout: 256 seconds)
02:48:36  * chobiejoined
02:48:36  * chiltsquit (Ping timeout: 252 seconds)
02:48:37  * chiltsjoined
03:05:02  * indutnyquit (Read error: Connection reset by peer)
03:05:14  * indutnyjoined
03:06:40  * abraxasjoined
03:06:42  * benoitcquit (Read error: Connection reset by peer)
03:06:42  * indutnyquit (Changing host)
03:06:42  * indutnyjoined
03:06:42  * benoitc_joined
03:06:42  * benoitc_changed nick to benoitc
03:06:42  * chobiequit (Ping timeout: 256 seconds)
03:06:43  * chobiejoined
03:11:52  * c4miloquit (Remote host closed the connection)
03:12:09  * bradleymeckquit (Quit: bradleymeck)
03:12:17  * c4milojoined
03:16:48  * c4miloquit (Ping timeout: 245 seconds)
03:29:50  * c4milojoined
03:31:25  * benoitcquit (Excess Flood)
03:36:31  <indutny>hoya
03:39:01  * dscapejoined
03:41:37  * c4miloquit (Remote host closed the connection)
03:42:03  * c4milojoined
03:42:52  * benoitcjoined
03:44:43  <stagas>indutny: this timezone is a bit quiet
03:44:48  <indutny>heh
03:45:09  * kazuponquit (Remote host closed the connection)
03:46:28  * c4miloquit (Ping timeout: 256 seconds)
03:48:25  * c4milojoined
03:48:25  * c4miloquit (Remote host closed the connection)
03:48:53  * c4milojoined
03:53:34  * c4miloquit (Ping timeout: 256 seconds)
03:55:27  * kazuponjoined
04:05:22  * brsonjoined
04:09:48  * brsonquit (Ping timeout: 256 seconds)
04:10:45  * kazuponquit (Remote host closed the connection)
04:11:38  * brsonjoined
04:12:08  * abraxasquit (Remote host closed the connection)
04:19:07  * bradleymeckjoined
04:26:38  <MI6>nodejs-v0.10: #64 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/64/
04:30:11  * AvianFluquit (Read error: Connection reset by peer)
04:30:38  * defunctzombie_zzchanged nick to defunctzombie
04:30:47  * AvianFlujoined
04:31:21  * defunctzombiequit (Changing host)
04:31:21  * defunctzombiejoined
04:31:45  * benoitcquit (Excess Flood)
04:35:52  * benoitcjoined
04:41:08  * kazuponjoined
04:48:41  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
04:49:09  * kazuponquit (Ping timeout: 245 seconds)
04:52:13  * abraxasjoined
05:09:43  * dominictarrjoined
05:12:06  * AvianFluquit (Remote host closed the connection)
05:32:09  * benoitcquit (Excess Flood)
05:33:23  * benoitcjoined
05:40:19  * ingmar5joined
05:40:25  * wolfeidauquit (Read error: Connection reset by peer)
05:40:42  * wolfeidaujoined
05:42:51  * jez0990_joined
05:43:23  * txdv_joined
05:43:41  * mikealquit (Quit: Leaving.)
05:46:21  * KiNgMaRquit (Ping timeout: 245 seconds)
05:46:22  * jez0990quit (Ping timeout: 245 seconds)
05:46:24  * txdvquit (Ping timeout: 245 seconds)
05:46:24  * kazuponjoined
05:46:25  * rjequit (Ping timeout: 245 seconds)
05:46:26  * tellnesquit (Ping timeout: 245 seconds)
05:46:27  * tellnes_joined
05:46:27  * tellnes_changed nick to tellnes
05:48:22  * rje_joined
05:51:23  * kazuponquit (Ping timeout: 256 seconds)
06:03:35  * wolfeidauquit (Remote host closed the connection)
06:18:18  * mikealjoined
06:24:51  * mikeal1joined
06:25:00  * wolfeidaujoined
06:25:08  * mikealquit (Ping timeout: 256 seconds)
06:32:29  * benoitcquit (Excess Flood)
06:34:03  * kazuponjoined
06:36:43  * brsonquit (Quit: leaving)
06:42:24  * benoitcjoined
07:18:31  * mmalecki[zzz]changed nick to mmalecki
07:31:22  * `3rdEdenjoined
07:32:52  * benoitcquit (Excess Flood)
07:34:54  * benoitcjoined
07:47:58  * dominictarrquit (Read error: Connection reset by peer)
07:48:02  * dominictarr_joined
07:55:09  * `3rdEden_joined
07:55:37  * `3rdEden_changed nick to `3E
07:57:00  * `3rdEdenquit (Remote host closed the connection)
08:05:07  * saghuljoined
08:11:49  * defunctzombiechanged nick to defunctzombie_zz
08:19:11  * rendarjoined
08:31:17  * abraxas_joined
08:33:01  * csaohjoined
08:34:24  * benoitcquit (Excess Flood)
08:35:45  * `3rdEden_joined
08:35:57  * `3rdEden_changed nick to `3rdEden
08:36:03  * `3Equit (Disconnected by services)
08:36:10  * abraxasquit (Ping timeout: 245 seconds)
08:38:40  * jez0990joined
08:39:34  * rje_quit (Ping timeout: 264 seconds)
08:39:56  * rjejoined
08:39:59  * wolfeidauquit (Ping timeout: 248 seconds)
08:40:03  * dominictarr_quit (*.net *.split)
08:40:05  * chobiequit (*.net *.split)
08:40:08  * wolfeidaujoined
08:40:26  * dominictarrjoined
08:42:32  * jez0990_quit (Ping timeout: 256 seconds)
08:42:39  * bradleymeckquit (*.net *.split)
08:44:20  * chobie1joined
08:44:21  * ingmar5quit (Excess Flood)
08:44:24  * benoitcjoined
08:44:37  * KiNgMaRjoined
08:57:05  * chobie1quit (*.net *.split)
08:57:27  * chobie1joined
09:07:33  * V1joined
09:10:15  * V1quit (Disconnected by services)
09:11:46  * benoitcquit (Excess Flood)
09:19:09  * dominictarr_joined
09:19:18  * dominictarrquit (Read error: Connection reset by peer)
09:19:19  * dominictarr_changed nick to dominictarr
09:19:54  * benoitcjoined
09:29:12  * dominictarr_joined
09:31:30  * dominictarrquit (Ping timeout: 252 seconds)
09:31:30  * dominictarr_changed nick to dominictarr
09:54:12  * dominictarrquit (Quit: dominictarr)
10:22:57  * benoitcquit (Excess Flood)
10:27:13  * qmx|awaychanged nick to qmx
10:31:25  * benoitcjoined
10:36:59  * kazuponquit (Remote host closed the connection)
10:48:00  * kazuponjoined
10:53:31  * Kakerajoined
11:07:52  * stagasjoined
11:13:11  * dominictarrjoined
11:19:27  * stagasquit (Ping timeout: 260 seconds)
11:20:51  * stagasjoined
11:22:02  * stagasquit (Read error: Connection reset by peer)
11:22:39  * sgallaghjoined
11:22:51  * stagasjoined
12:02:09  * stagas_joined
12:04:05  * stagasquit (Ping timeout: 256 seconds)
12:04:19  * stagas_changed nick to stagas
12:05:38  * benoitcquit (Excess Flood)
12:06:56  * benoitcjoined
12:07:48  * bnoordhuisjoined
12:14:29  <bnoordhuis>morning
12:20:08  * stagas_joined
12:22:06  * stagasquit (Ping timeout: 245 seconds)
12:22:18  * stagas_changed nick to stagas
12:22:42  <indutny>evening
12:28:58  * kazuponquit (Remote host closed the connection)
12:29:01  <MI6>joyent/node: Ben Noordhuis v0.10 * 44843a6 : child_process: fix sending utf-8 to child process In process#send() and (+1 more commits) - http://git.io/o12PCg
12:30:30  * abraxas_quit (Remote host closed the connection)
12:38:31  * stagas_joined
12:39:26  <MI6>joyent/node: Ben Noordhuis v0.8 * 84bb0ec : child_process: fix sending utf-8 to child process In process#send() and - http://git.io/H6XTzg
12:40:16  * stagasquit (Ping timeout: 256 seconds)
12:40:26  * stagas_changed nick to stagas
12:45:24  * bradleymeckjoined
12:46:10  * hzjoined
12:55:13  <MI6>joyent/node: Mathias Bynens v0.10 * 488b74d : doc: mention `process.*.isTTY` under `process` - http://git.io/pd34mQ
13:27:34  * piscisaureus_joined
13:39:24  * kazuponjoined
13:44:05  * kazuponquit (Ping timeout: 252 seconds)
13:44:28  * c4milojoined
13:49:22  <piscisaureus_>hey bnoordhuis
13:50:48  <MI6>joyent/libuv: piscisaureus created branch version - http://git.io/6kfO7Q
13:51:23  <bnoordhuis>ho piscisaureus_
13:51:52  <MI6>joyent/libuv: Bert Belder version * eb40c44 : Prepare for release versioning - http://git.io/B1Ie4g
13:51:55  <piscisaureus_>bnoordhuis: can you sign that off? ^
13:53:10  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/commit/eb40c44e6aa746d9c5f64d108f2738b497a2c20c <- that one?
13:53:19  <bnoordhuis>btw, you were on HN today
13:53:32  <piscisaureus_>Yeah I don't know why all these commits are shown. That one indeed
13:53:40  <piscisaureus_>bnoordhuis: I saw. With my centuries old gist
13:53:47  <bnoordhuis>a sure sign that standards are dropping everywhere :)
13:53:56  <piscisaureus_>actually it's still at #4
13:56:16  <piscisaureus_>bnoordhuis: also this versioning patch -- should that go into 0.10 as well?
13:57:12  * sgallaghquit (Ping timeout: 260 seconds)
13:57:18  <indutny>bnoordhuis: so you were on HN?
13:57:19  <indutny>where?
13:57:37  <bradleymeck>need to figure out non-sucky way to test against windows for node apps
13:58:01  <bradleymeck>wrong channel...
13:58:28  * stagasquit (Ping timeout: 256 seconds)
14:00:22  * benoitcquit (Excess Flood)
14:01:28  <bnoordhuis>sorry, back - had to watch uki with my offspring
14:01:51  <bnoordhuis>indutny: no, not me - bert: https://news.ycombinator.com/item?id=5435968
14:02:08  <indutny>oh gosh :)
14:03:07  <indutny>lovely
14:08:27  * benoitcjoined
14:09:30  <piscisaureus_>bnoordhuis: the version.c thing was your only comment?
14:12:55  <bnoordhuis>yep, otherwise lgtm
14:12:57  <bnoordhuis>okay, biab
14:15:52  * AvianFlujoined
14:17:26  * bnoordhuisquit (Ping timeout: 256 seconds)
14:23:07  * `3rdEdenchanged nick to `3E|BRB
14:24:59  * kazuponjoined
14:27:34  * mikeal1quit (Quit: Leaving.)
14:33:47  * `3E|BRBchanged nick to `3rdEden
14:35:55  * nsmjoined
14:41:38  * c4miloquit (Remote host closed the connection)
14:41:51  <MI6>joyent/libuv: Bert Belder version * d5f8c1a : Now working on v0.10.3 (+3 more commits) - http://git.io/7400Zg
14:42:06  * sgallaghjoined
14:42:06  * c4milojoined
14:46:38  * c4miloquit (Ping timeout: 256 seconds)
14:46:55  * sgallaghquit (Ping timeout: 256 seconds)
14:47:40  * sgallaghjoined
15:02:59  * c4milojoined
15:10:35  * benoitcquit (Excess Flood)
15:10:35  * mikealjoined
15:10:58  * benoitc_joined
15:11:07  * benoitc_changed nick to benoitc
15:12:48  * bnoordhuisjoined
15:24:11  <piscisaureus_>hey bnoordhuis, ^-- ?
15:29:13  <bnoordhuis>piscisaureus_: yes?
15:29:24  <piscisaureus_>bnoordhuis: do it? release libuv v0.10.3?
15:29:39  <piscisaureus_>Once I do this there is no way back :)
15:30:04  <bnoordhuis>is the idea to release in tandem with node?
15:30:12  <piscisaureus_>bnoordhuis: no
15:30:22  <bnoordhuis>ah no
15:30:30  * ircretaryquit (Remote host closed the connection)
15:30:37  <bnoordhuis>i saw it in the commit log :)
15:30:37  * ircretaryjoined
15:30:45  <piscisaureus_>good
15:30:55  <Guest62188>libuv doesn't have to be released in tandem with node
15:31:11  <Guest62188>(looks like it's already a version ahead, actually ;)
15:31:11  <piscisaureus_>Hi Guest62188 aka IZS
15:31:15  <Guest62188>whaa
15:31:21  <Guest62188>why i'm not nicked!?
15:31:24  * Guest62188changed nick to isaacs
15:31:38  <bnoordhuis>piscisaureus_: lgtm. do it
15:31:38  <isaacs>there we go
15:31:53  * creationixlooked for the node 0.10.2 release assuming it was out because of the uv version
15:32:13  <piscisaureus_>isaacs: yes, the libuv version will be ahead. I just thought it'd be confusing to release 0.10.0 or 0.10.1 since there is also a "libuv version that's in node 0.101"
15:32:24  <isaacs>yeah, makes sense
15:32:30  <piscisaureus_>isaacs: but yeah they will start getting out of sync
15:32:36  <isaacs>that's fine
15:32:48  <isaacs>you could also start at a different number.
15:32:51  <piscisaureus_>ok, pushing it then
15:32:52  <isaacs>just to b e extra fun :)
15:33:04  <piscisaureus_>isaacs: we could do 4-digit
15:33:08  <isaacs>hahah
15:33:15  <piscisaureus_>I actually considered that
15:33:17  <bnoordhuis>v9001
15:33:19  <isaacs>or bump the minor for every feature addition
15:33:41  <isaacs>and the patch version for every release, and the major for every breaking change.
15:33:45  <piscisaureus_>well I'd bump the 3rd for that and bump the 4th only for patch releases
15:33:47  <isaacs>classic semver style
15:33:58  <bradleymeck>is uv_work always in a new thread
15:34:08  <piscisaureus_>let's not start doing that yet
15:34:52  <bradleymeck>going to just guess so
15:35:22  <bnoordhuis>bradleymeck: new? no
15:35:40  <bnoordhuis>the work_cb is executed in a thread in the thread pool
15:36:09  <bnoordhuis>if you want a new thread, use uv_thread_create
15:36:25  <MI6>joyent/libuv: Bert Belder v0.10 * d5f8c1a : Now working on v0.10.3 (+3 more commits) - http://git.io/e24sXw
15:36:27  <MI6>joyent/libuv: piscisaureus created tag v0.10.3 - http://git.io/Qsjs3w
15:37:29  <MI6>joyent/libuv: piscisaureus created tag v0.10.2 - http://git.io/fVKqkA
15:52:19  * mikealquit (Quit: Leaving.)
15:53:30  * defunctzombie_zzchanged nick to defunctzombie
15:54:14  <MI6>nodejs-v0.10: #65 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/65/
15:56:31  <indutny>bnoordhuis: hoya
15:56:31  <indutny>what do you think about https://github.com/indutny/node/commit/964fe02
15:58:02  <MI6>libuv-v0.10: #19 UNSTABLE windows (6/187) linux (3/186) osx (1/186) smartos (5/186) http://jenkins.nodejs.org/job/libuv-v0.10/19/
15:58:29  <isaacs>indutny: should zero return be like ECONNRESET?
15:58:37  <indutny>yeah, exactly
15:58:54  <indutny>that's what will happen after my patch
15:59:43  <isaacs>indutny: what error gets emitted here?
15:59:54  <indutny>ssl.error() emits ECONNRESET
16:00:02  <indutny>if there're no actual error
16:00:08  <indutny>and zero return doesn't set any error code
16:00:17  <isaacs>i see
16:00:19  <isaacs>kewl
16:00:26  <isaacs>seems reasonable to me. add a test, etc.
16:00:42  <indutny>oh, right
16:00:47  <indutny>yeah, I'll figure it out tomorrow
16:01:15  <tjfontaine>hmm I didn't see anything get pushed to v0.8, did I miss that, or has jenkins just gone crazy?
16:01:29  <bnoordhuis>indutny: it doesn't look very elegant but oh well
16:01:40  <bnoordhuis>tjfontaine: i pushed a commit this afternoon
16:01:44  <indutny>bnoordhuis: you don't have better ideas, right?
16:01:45  <indutny>;)
16:01:45  <tjfontaine>ok
16:06:24  * kazuponquit (Remote host closed the connection)
16:07:13  <isaacs>bnoordhuis: it sounds like you figured out the test failure that was making me go crazy?
16:07:37  <isaacs>test-child-process-fork-getconnections
16:08:01  <tjfontaine>potentially all the spurious unix test-child/cluster failures
16:08:03  * sblomjoined
16:09:40  <indutny>heh
16:09:42  <indutny>bnoordhuis: ++
16:09:49  <indutny>so its basically IPC problem
16:09:51  * bradleymeckquit (Quit: bradleymeck)
16:10:07  <indutny>and sockets are merged together on some OSes?
16:10:44  <bnoordhuis>yes
16:11:22  <bnoordhuis>not sure yet how to best fix it
16:13:15  <MI6>nodejs-v0.8: #34 UNSTABLE osx-ia32 (1/469) osx-x64 (1/469) smartos-x64 (2/469) windows-ia32 (4/469) windows-x64 (3/469) linux-ia32 (2/469) smartos-ia32 (3/469) linux-x64 (2/469) http://jenkins.nodejs.org/job/nodejs-v0.8/34/
16:13:51  <indutny>bnoordhuis: well, just read it properly
16:14:00  <indutny>ahhh... we don't support this in APIs
16:17:33  * dapjoined
16:22:36  <bnoordhuis>indutny: indeed
16:22:49  <indutny>yeah, need to think about it
16:22:56  <indutny>wanna discuss it tomorrow?
16:23:02  <indutny>I'm flying back to Moscow
16:23:09  <indutny>and should have more time to think about things
16:23:23  <indutny>(finally finished my income declaration)
16:23:45  <bnoordhuis>sure
16:24:10  <indutny>and re ciphers stuff in node_crypto.cc
16:24:18  <indutny>if isaacs won't review it, I'll do it tomorrow too
16:25:17  <isaacs>indutny: i'll weigh in, but i like you and ben to review each others' C++. you're more opinionated there than i am.
16:25:27  <indutny>k
16:25:47  <isaacs>what's the pull req?
16:26:50  <MI6>nodejs-v0.10: #66 ABORTED windows-x64 (4/567) smartos-ia32 (1/567) windows-ia32 (5/567) http://jenkins.nodejs.org/job/nodejs-v0.10/66/
16:31:21  * mikealjoined
16:36:51  * kazuponjoined
16:40:16  * `3rdEdenchanged nick to `3E|DINNER
16:45:04  * kazuponquit (Ping timeout: 256 seconds)
16:48:57  <MI6>nodejs-v0.10: #67 ABORTED windows-x64 (6/567) smartos-ia32 (1/567) windows-ia32 (6/567) http://jenkins.nodejs.org/job/nodejs-v0.10/67/
16:50:48  * dapquit (Quit: Leaving.)
17:01:41  <indutny>isaacs: https://github.com/joyent/node/pull/5078/files
17:01:46  * trevnorrisjoined
17:02:26  * mikealquit (Quit: Leaving.)
17:02:59  * qmxchanged nick to qmx|lunch
17:04:47  <trevnorris>indutny: plausibility estimate: make Object::GetIdentityHash() return a unique value, then create a Isolate::HasIdentityHash() to see if the object still exists?
17:07:43  * rjequit (Ping timeout: 264 seconds)
17:10:28  <indutny>trevnorris: erm?
17:10:50  <indutny>thats not that simple
17:10:57  <indutny>you want unmanagable object to be managable :)
17:11:04  <indutny>that has its own overhead
17:11:30  <indutny>but surely its possible
17:12:00  <trevnorris>ok. i'll give short go at it.
17:12:01  * rjejoined
17:12:02  <indutny>I was a little bit distracted
17:12:05  <indutny>at weekend
17:12:30  <trevnorris>i'm hoping that it'll be a lot less expensive then the whole persistent/makeweak/setinternalfield thing.
17:12:31  <indutny>will have a lot of time this week
17:14:22  <trevnorris>awesome. i've gotten the minimal external memory implementation done, just to find out that it accounts for 90% of buffer instantiation time.
17:14:30  * benoitcquit (Excess Flood)
17:15:47  <isaacs>bnoordhuis: what if we made our IPC do a round-trip whenever it sends a socket?
17:16:15  <isaacs>bnoordhuis: so, if we send a socket, we wait for the child to respond with something like {NODE_INTERNAL_MESSAGE:"got fd"}
17:16:20  <isaacs>bnoordhuis: or something
17:16:30  <isaacs>i guess that won't work if we're sendmsg'ing to a non-node programm.
17:16:42  <bnoordhuis>it won't work with node programs either :)
17:16:56  <bnoordhuis>the issue is that there may be several pending fds, each with their own message
17:16:57  <indutny>heh
17:17:19  <bnoordhuis>node/libuv calls recvmsg() and receives just one fd but all the messages
17:17:23  <isaacs>right, i'm saying, we back those up on the sender
17:17:28  * benoitcjoined
17:17:33  <isaacs>we dont' actually send the message until we have confirmation that the fd was received.
17:17:34  <bnoordhuis>oh, queue them up
17:17:36  <indutny>isaacs: its just a bug
17:17:37  <isaacs>right
17:17:42  <indutny>isaacs: in libuv
17:17:45  <indutny>honestly
17:17:50  <indutny>I disagree with fixing it at node level
17:17:55  <isaacs>ok
17:18:03  <indutny>like, yes - its possible
17:18:09  <indutny>but no - we should fix it anyway in uv
17:18:13  <isaacs>well, fine, do that in uv
17:18:18  <bnoordhuis>it's not really a bug in libuv
17:18:22  <isaacs>whatever.
17:18:23  <bnoordhuis>libuv is just doing what it's told
17:18:35  <isaacs>but it sounds like it's basically a shortcoming of sendmsg/recvmsg
17:18:35  <indutny>bnoordhuis: well, discarding data is not really gentle ;)
17:18:53  <isaacs>do we have some way of knowing when the fd/message has been consumed?
17:18:54  <bnoordhuis>there's no discarding taking place
17:19:05  <bnoordhuis>it's that fds end up with the wrong messages
17:19:12  <bnoordhuis>where 'message' is the json string that node sends
17:19:12  <indutny>bnoordhuis: aaaah
17:19:16  <indutny>aaaaaaaaah
17:19:25  <indutny>well isaacs might be right then
17:19:41  <bnoordhuis>yeah, so queuing is one of the things i considered
17:19:48  <isaacs>right, so we do send('foo', 8) send('bar', 9) send('baz', 10)
17:19:51  <bnoordhuis>but it would be nice to fix it in a more general sense
17:19:56  <indutny>ok ,time to sleep
17:19:58  <indutny>ttyl guys
17:19:58  <isaacs>the client then receives ('foobarbaz', 8)
17:20:01  <bnoordhuis>because if node hits this issue, other libuv users will too
17:20:04  <bnoordhuis>sleep tight fedor
17:20:08  <isaacs>and then the next message gets (whatever, 9)
17:20:14  <isaacs>g'nite indutny
17:20:22  <isaacs>bnoordhuis: am i groking this correctly?
17:20:33  <bnoordhuis>isaacs: yep
17:20:42  <isaacs>right
17:20:54  <isaacs>so, we could queue it up in libuv, if we have some way of knowing when the message was received.
17:21:04  <isaacs>honestly, that does sound like a nicer solution.
17:21:25  <bnoordhuis>yeah, only libuv doesn't know when the other end reads the message
17:21:39  <bnoordhuis>unless you implement an ad-hoc rpc protocol on top of unix sockets
17:21:52  <bnoordhuis>but i really, really don't want to do that
17:22:38  * piscisaureus_quit (Ping timeout: 245 seconds)
17:22:42  <isaacs>right
17:23:15  <isaacs>we *could* handle this at the node level, fo course, but like you say, other libuv users will hit this.
17:26:10  <bnoordhuis>yep. it's not a very pressing issue, fortunately
17:26:22  <bnoordhuis>this bug has been around since libuv's inception and no one's complained yet
17:26:34  <isaacs>true
17:26:40  <bnoordhuis>probably because it Just Works(TM) on the operating systems that matter
17:27:00  <isaacs>but... either we need to fix this in node, or decide we won't fix it, and make allowances in the tests that are failing because of it.
17:27:21  <MI6>nodejs-v0.10: #68 UNSTABLE osx-x64 (1/567) windows-x64 (5/567) osx-ia32 (2/567) smartos-x64 (1/567) smartos-ia32 (1/567) windows-ia32 (4/567) http://jenkins.nodejs.org/job/nodejs-v0.10/68/
17:27:23  * TooTallNatejoined
17:27:24  <isaacs>i suspect it Just Works because it's a very rare situation that you're sendign a zillion messages in a row with FDs attached, outisde of tests.
17:27:42  <bnoordhuis>well, linux doesn't merge SCM_RIGHTS messages
17:27:52  <isaacs>mostly, you create 8 workers, and send each one a FD, and that's the end of it
17:27:55  * dapjoined
17:28:01  <isaacs>oic
17:28:04  <isaacs>does smartos?
17:28:11  <bnoordhuis>i don't know. maybe dap knows :)
17:28:11  <isaacs>because i've never seen this there, either
17:28:19  <dap>uh oh. what might I know?
17:28:32  <isaacs>dap: we have a test that fails like <1% of the time on Mac
17:28:42  <isaacs>dap: but enough to be annoying (and about 100% of the time on the jenkins build slave)
17:28:56  <isaacs>dap: we send a message with an fd to a child. 12 in a row, in fact.
17:29:01  <bnoordhuis>dap: when you sendmsg() on a unix socket, say you send two messages, each with a file descriptor attached
17:29:05  <isaacs>dap: what happens is that the messages get merged
17:29:18  <isaacs>send('foo', 8); send('bar', 9)
17:29:24  * bnoordhuissteps back
17:29:25  <isaacs>in the receiver: you receive ('foobar', 8)
17:29:28  * sblomquit (Ping timeout: 256 seconds)
17:29:32  <isaacs>dap: and then the next message gets ('whatever', 9)
17:29:36  <isaacs>and the logic is all fubar.
17:29:40  <dap>oh, interesting.
17:29:50  <isaacs>i've *only* seen this failure on os x
17:29:59  <isaacs>and it's a very weird edge case desert island kind of oddball thing
17:30:08  <dap>I assume it's not 'whatever', but ''?
17:30:21  <isaacs>well, if you sent another IPC message, it'd be that message
17:30:30  <isaacs>it gets out of sync
17:30:33  <dap>Ah, right.
17:30:37  <isaacs>so, it could be literally anything
17:30:46  <dap>I imagine this is allowed, but I don't know if we do it.
17:30:51  <dap>"we" being smartos
17:30:54  <isaacs>of course :)
17:31:03  * isaacsis Node. bnoordhuis is libuv. dap is smartos.
17:31:10  <dap>That said, the APUE section on this has an example that implements a little protocol for dealing with this.
17:31:16  <bnoordhuis>i'm also linux!
17:31:20  <tjfontaine>having not seen it in the builds, I would suspect smartos doesn't
17:31:23  <isaacs>bnoordhuis: yes :)
17:31:48  <isaacs>if os x does it, i'm guessing freebsd probably does as well.
17:31:54  <isaacs>(not that we care THAT much)
17:32:10  <dap>Does Linux definitely not do it?
17:32:18  <Ralt>bnoordhuis: news: I've switched from awesome wm to xmonad and I like it
17:32:21  <dap>Not having seen it != can't happen :)
17:32:32  <tjfontaine>certainly
17:32:38  <bnoordhuis>dap: no. if you sendmsg() two SCM_RIGHTS messages, the receiver reads two separate messages
17:32:47  <bnoordhuis>i can point you to the relevant code if you want
17:32:48  * mikealjoined
17:33:10  <bnoordhuis>Ralt: isn't xmonad something only hipsters use?
17:33:22  <dap>bnoordhuis: Cool. No need; was just wondering if someone had checked the code.
17:33:38  <Ralt>it's actually quite similar to awesome wm. I've found it easier/more satisfying though.
17:34:19  <bnoordhuis>Ralt: how so? not saying that awesome is the final stage in the evolution of WMs though
17:34:21  <Ralt>it might be because I'm more experience with tiling wms though
17:34:27  <Ralt>experienced*
17:34:36  <Ralt>I find the config easier
17:34:42  <Ralt>awesome's rc.lua is a PITA to maintain
17:34:53  <Ralt>the equivalent in xmonad is quite small and easy to maintain
17:35:04  <Ralt>also easier to understand
17:35:26  <Ralt>the keyboard shortcuts are kind of the same though
17:35:34  <bnoordhuis>don't know about easier but i agree the lua config in awesome is a pain
17:35:47  * wavdedjoined
17:36:25  <Ralt>overall, the UI feels more responsive
17:36:34  <Ralt>might be because of other things though
17:36:49  <Ralt>like me starting to use urxvtd instead of spawning a new urxvt every time...
17:37:36  <Ralt>it essentially comes down to how easy you can maintain the config file after all
17:37:38  * c4miloquit (Remote host closed the connection)
17:38:04  * c4milojoined
17:42:08  * kazuponjoined
17:42:52  * c4miloquit (Ping timeout: 256 seconds)
17:45:12  <MI6>joyent/node: Ben Noordhuis v0.10 * cfd0dca : crypto: make getCiphers() return non-SSL ciphers Commit f53441a added cr - http://git.io/iFiHww
17:46:29  * sblomjoined
17:47:09  * kazuponquit (Ping timeout: 276 seconds)
17:49:47  <isaacs>bnoordhuis, TooTallNate: Looks like node-weak is busted on 0.10?
17:50:05  <isaacs>https://gist.github.com/5239099
17:50:24  <TooTallNate>isaacs: oh, bnoordhuis did a patch
17:50:38  <TooTallNate>one sec
17:50:40  <isaacs>needs a npm publish?
17:52:53  <bnoordhuis>TooTallNate: i did. i posted a /cc on the commit
17:53:01  <bnoordhuis>seems no one reads my emails :(
17:53:12  <TooTallNate>bnoordhuis: no i saw it haha
17:53:24  * TooTallNatejust got back from hawaii
17:53:30  <tjfontaine>bnoordhuis thinks his the kid in the class that noone will call on?
17:53:30  <bnoordhuis>nice
17:53:36  <TooTallNate>https://github.com/joyent/node/commit/dc29d64983f16fae79a9e293dbd3106bf69171db
17:53:52  <bnoordhuis>tjfontaine: i don't get invited to any birthday parties either :(
17:54:13  <tjfontaine>nobody likes you, everybody hates you, guess you should go eat worms
17:54:15  <tjfontaine>:)
17:54:27  <bnoordhuis>that's probably because i drink the keg dry before others get a chance
17:56:04  <bnoordhuis>talking about...
17:56:13  * bnoordhuisheads off to the fridge
17:57:20  <TooTallNate>isaacs: ok, so it's master that's broken, not v0.10.x
17:57:32  <TooTallNate>i'm gonna #if it
17:57:35  <isaacs>hrm.. orly?
17:57:57  <isaacs>TooTallNate: i'm seeing it fail on v0.10.2-pre
17:58:03  <trevnorris>indutny: while instantiation might be faster, the trade off is node would have to loop though tracked handles and clean them up if no longer exists.
17:58:09  <isaacs>full npm output: https://gist.github.com/5239176
17:58:13  <trevnorris>in the end you t hink that would save time?
17:59:35  <tjfontaine>jesus linking on windows ...
17:59:39  <TooTallNate>isaacs: did we update v8 in that time?
17:59:52  <TooTallNate>the v0.10.1 tag doesn't have those functions
18:00:07  <tjfontaine>there was only that CVE fix to v8 afaik
18:00:29  <isaacs>TooTallNate: nope
18:00:32  * bnoordhuisquit (Ping timeout: 256 seconds)
18:00:41  <isaacs>TooTallNate: v8: '3.14.5.8',
18:02:17  <MI6>nodejs-v0.10: #69 UNSTABLE windows-x64 (5/567) osx-ia32 (2/567) smartos-x64 (1/567) smartos-ia32 (1/567) windows-ia32 (4/567) http://jenkins.nodejs.org/job/nodejs-v0.10/69/
18:02:31  * brsonjoined
18:06:36  <TooTallNate>isaacs: idk, cmd F the word "aligned" https://github.com/joyent/node/blob/v0.10/deps/v8/include/v8.h
18:06:39  * dominictarrquit (Quit: dominictarr)
18:06:44  <TooTallNate>it's only there twice in comments
18:06:52  <TooTallNate>master branch the function is there though
18:07:11  <TooTallNate>isaacs: if it's -pre, then you're specifying "nodedir" right?
18:07:19  <isaacs>TooTallNate: ohhhhhhh
18:07:20  <isaacs>right
18:07:22  <TooTallNate>or it's in your npm config
18:07:32  <TooTallNate>and your node checkout is probably master branch :D
18:07:51  <isaacs>TooTallNate: that was the issue. thanks :)
18:07:54  <isaacs>yeah, it's in my npm conf
18:08:37  <TooTallNate>ok that helps me know which version to check
18:09:21  * csaohquit (Quit: csaoh)
18:18:40  <TooTallNate>isaacs: ok node-weak v0.2.2 supports v0.11 now
18:21:58  <isaacs>awesome! thanks
18:23:06  * piscisaureus_joined
18:23:44  * benoitcquit (Excess Flood)
18:27:26  * `3E|DINNERchanged nick to `3rdEden
18:30:28  * benoitcjoined
18:31:48  <tjfontaine>piscisaureus_: thoughts on why uv_tcp_duplicate_socket would be returning -1 for test-cluster-bind-twice-v2.js
18:33:08  * c4milojoined
18:33:45  <tjfontaine>hmm seems its hitting if (listen(handle->socket, SOMAXCONN) == SOCKET_ERROR) {
18:36:39  * qmx|lunchchanged nick to qmx
18:37:10  <piscisaureus_>tjfontaine: on windows, a socket needs to be connect(ed|ing) or a server if you want to dup it
18:37:52  <trevnorris>isaacs: there won't be a need for SlowBuffer's with this change. should I keep the name around for compatibility?
18:39:18  <isaacs>trevnorris: sure.
18:39:25  <isaacs>trevnorris: global.SlowBuffer = global.Buffer
18:39:50  <trevnorris>isaacs: ok. and should I just set a recursive for "this.parent = this"?
18:39:53  <isaacs>we can remove it from the documentation, maybe do a util.deprecate or something
18:40:12  <isaacs>global.SlowBuffer = util.deprecate(global.Buffer, 'blah blah message message')
18:40:21  <trevnorris>ah, interesting. ok.
18:42:13  <tjfontaine>piscisaureus_: this is failing before the actual duplication, when it's trying to listen(), and it returns wsaeinval
18:42:45  * kazuponjoined
18:42:53  * nsmquit (Quit: nsm)
18:43:11  <piscisaureus_>tjfontaine: are you sure that the listen() call fails? Isn't it the (if flags & UV_HANDLE_BOUND) branch that's being taken?
18:43:40  <tjfontaine>yes, so sayeth my printf, I have one in both branches
18:43:47  <trevnorris>isaacs: and wasn't there a consensus that _charsWritten could be removed?
18:43:54  <tjfontaine>I was expecting the bound to catch it
18:43:57  <piscisaureus_>tjfontaine: that's very odd...
18:44:06  <tjfontaine>yes
18:44:11  <piscisaureus_>tjfontaine: does handle->socket have an actual value?
18:44:16  <piscisaureus_>or is it -1 ?
18:44:26  <isaacs>trevnorris: yeah, remove in master.
18:44:29  <tjfontaine>lemme check, *argh* more linking :)
18:44:31  <trevnorris>=))
18:44:36  <isaacs>i gotta run to class. be back in a few hours.
18:44:44  <tjfontaine>piscisaureus_: unless you can tell me how to convince vs to attach to these grandchildren?
18:45:01  <piscisaureus_>tjfontaine: you can, but not automatically...
18:45:11  <tjfontaine>just put a sleep and try and catch it?
18:45:19  <piscisaureus_>so you'd have to be very quick :-)
18:45:20  <piscisaureus_>yeah
18:45:45  <tjfontaine>lame, I'll stick with printf for now until I have enough information to make you interested :)
18:48:02  <tjfontaine>piscisaureus_: socket has a value, this time it's 704
18:48:56  * kazuponquit (Ping timeout: 255 seconds)
18:51:50  <piscisaureus_>tjfontaine: hmmmm....
18:52:17  <tjfontaine>is there a way I can get info with process explorer about that socket?
18:52:26  * luxigoquit (Read error: Connection reset by peer)
18:53:15  <piscisaureus_>tjfontaine: euh, probably...
18:53:46  <tjfontaine>would such information be useful?
18:55:36  <piscisaureus_>tjfontaine: no :)
18:55:58  <piscisaureus_>tjfontaine: what type of socket is being shared in that test?
18:56:04  <piscisaureus_>a server socket or a connected socket?
18:56:17  <tjfontaine>a server socket
18:56:32  <piscisaureus_>Hmm. so a second listen() call shouldn't fail
18:56:55  <tjfontaine>well, it should fail, just not where it is
18:57:02  <tjfontaine>but it should fail with EADDRINUSE
18:57:19  <piscisaureus_>tjfontaine: well if the socket is shared then no, the second listen() call should just succeed
18:57:51  <piscisaureus_>Although I seem to remember that there was some sort of oddness going on w/ listen and child processes
18:58:04  <piscisaureus_>Actually a procmon dump might be useful
18:58:04  <tjfontaine>piscisaureus_: https://github.com/joyent/node/blob/master/test/simple/test-cluster-bind-twice-v2.js#L29-33
18:58:38  <tjfontaine>hm
19:01:04  <piscisaureus_>tjfontaine: so you are saying worker 2 does this?
19:01:14  <piscisaureus_>tjfontaine: return wsaeinval I mean
19:01:32  <piscisaureus_>but really it should fail with eaddrinuse?
19:01:44  <trevnorris>anyone mind popping pr 5137 on?
19:01:44  * sblomquit (Ping timeout: 276 seconds)
19:01:53  <tjfontaine>piscisaureus_: yes, https://github.com/joyent/node/issues/4966
19:01:54  <tjfontaine>brb lunch
19:02:10  <piscisaureus_>tjfontaine: sorry for all the dumb questions :-)
19:02:15  <piscisaureus_>tjfontaine: enjoy your lunch
19:06:37  * bnoordhuisjoined
19:06:48  * brsonquit (Ping timeout: 245 seconds)
19:07:43  * brsonjoined
19:11:19  * bnoordhuisquit (Ping timeout: 264 seconds)
19:16:37  * sblomjoined
19:21:58  * defunctzombiechanged nick to defunctzombie_zz
19:30:55  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:40:14  <tjfontaine>ircretary: tell piscisaureus_ well, I think technically it's in master2 when it's prepping to send to worker2, but I'm about to add some PID tracing to make me feel better about that
19:40:15  <ircretary>tjfontaine: I'll be sure to tell piscisaureus_
19:45:16  * `3rdEdenquit (Remote host closed the connection)
19:45:18  * kazuponjoined
19:49:48  * kazuponquit (Ping timeout: 256 seconds)
19:51:52  * `3rdEdenjoined
19:52:02  * benoitcquit (Excess Flood)
19:52:58  * benoitcjoined
20:04:59  <tjfontaine>ircretary: tell piscisaureus_ yes, this is indeed happening in master2
20:05:00  <ircretary>tjfontaine: I'll be sure to tell piscisaureus_
20:17:29  * AvianFluquit (Remote host closed the connection)
20:21:40  * bajtosjoined
20:22:19  * bajtosquit (Client Quit)
20:25:07  <tjfontaine>ircretary: tell piscisaureus_ aha, handle->bind_error is 10048 which is eaddrinuse, so the question is how we got to here without throwing for that
20:25:07  <ircretary>tjfontaine: I'll be sure to tell piscisaureus_
20:28:11  * sblomquit (Ping timeout: 276 seconds)
20:45:34  * CAPSLOCKBOTjoined
20:45:55  * kazuponjoined
20:50:55  * kazuponquit (Ping timeout: 264 seconds)
20:52:21  * benoitcquit (Excess Flood)
20:54:58  * benoitcjoined
20:55:42  <trevnorris>freakin v8 memory leak. if you set a hidden value to a weak persistent then remove it later gc won't detect it needs to be cleaned up.
20:56:15  * mikealquit (Quit: Leaving.)
21:01:01  * sgallaghquit (Remote host closed the connection)
21:01:24  * sblomjoined
21:01:56  <tjfontaine>sblom: so I "figured out" 4966/5068
21:05:27  <saghul>ircretary tell piscisaureus uv.h:236: warning: type qualifiers ignored on function return type
21:05:28  <ircretary>saghul: I'll be sure to tell piscisaureus
21:05:56  * sblomquit (Ping timeout: 256 seconds)
21:14:12  * AvianFlujoined
21:27:22  * wolfeidauquit (Remote host closed the connection)
21:29:57  * sblomjoined
21:33:03  * defunctzombie_zzchanged nick to defunctzombie
21:33:11  * wavdedquit (Quit: Hasta la pasta)
21:44:45  * wolfeidaujoined
21:46:37  * piscisaureus_joined
21:46:45  * piscisaureus_quit (Client Quit)
21:47:03  * kazuponjoined
21:48:23  * bnoordhuisjoined
21:49:33  * rendarquit
21:51:39  * kazuponquit (Ping timeout: 245 seconds)
21:52:51  <tjfontaine>bnoordhuis: does uv_write2 of a tcp socket trigger the parent to do the bind/listen? or is that done in the child?
21:56:27  <trevnorris>bnoordhuis: will valgrind always show memory leaks, or can it miss some?
21:56:57  <tjfontaine>depends on what you mean by leak :)
21:57:39  <tjfontaine>chances are a v8 object appears referenced enough that valgrind doesn't see it as a leak
21:58:24  <trevnorris>tjfontaine: here's the minimal case of what my allocator does: https://gist.github.com/trevnorris/5241186
21:58:49  <trevnorris>tjfontaine: but the problem is when I do this in node, the WeakCallback is never called, so memory just continues to accumulate.....
22:00:12  <tjfontaine>but this works in your standalone?
22:00:18  <trevnorris>yeah
22:00:24  * c4miloquit (Remote host closed the connection)
22:00:30  <tjfontaine>is it passing up through to js?
22:00:42  <trevnorris>in node yes. but not in my test case.
22:00:49  * c4milojoined
22:00:58  <tjfontaine>right, that's what I mean, in js
22:01:20  <tjfontaine>so something is still holding a reference to it?
22:02:18  <bnoordhuis>tjfontaine: re uv_write2, it only sends over handles/fds. the bind/listen steps are all done by either the sender or the receiver
22:02:24  <tjfontaine>in your test you're only using one reference?
22:02:25  <trevnorris>nope. it's essentially "var obj = {}; for (var i = 0; i < 1e6; i++) alloc(obj, 1024);"
22:02:36  <tjfontaine>interesting
22:02:39  <bnoordhuis>in node's case it sends over a socket that's bound and listening
22:03:04  <tjfontaine>bnoordhuis: ok, well the bind/listen happens before the uv_write2 call generally, right?
22:03:11  <bnoordhuis>yes
22:03:22  <tjfontaine>bnoordhuis: how is it that eaddrinuse is caught in the child then for unix?
22:03:32  <bnoordhuis>because magic
22:03:41  <bnoordhuis>okay, not really
22:03:44  <tjfontaine>because that shit never worked on windows ...
22:04:14  <bnoordhuis>the master doesn't check if bind() failed or not, it just sends over the socket
22:04:38  <bnoordhuis>the worker then checks with getsockname() if the socket is bound to the right port
22:04:52  * sblomquit (Ping timeout: 256 seconds)
22:05:00  <tjfontaine>ok that explains an error if I avoid the listen() on the windows side
22:05:13  * c4miloquit (Ping timeout: 240 seconds)
22:05:21  <tjfontaine>net.js:1049
22:05:24  <tjfontaine> if (port && handle.getsockname && port != handle.getsockname().port) {
22:05:40  <tjfontaine>getsockname() is returning null
22:06:46  <bnoordhuis>when the socket isn't bound?
22:06:46  <tjfontaine>which I think only happens (iirc from my last trip down this path) if the handle isn't set
22:08:11  <MI6>joyent/node: Ben Noordhuis tjfontaine-review-this * 9352c19 : child_process: don't emit same handle twice It's possible to read multip - http://git.io/A4N3aw
22:08:23  <bnoordhuis>^ tjfontaine thoughts? do i hear LGTM?
22:10:05  <tjfontaine>weird set of commits that github is showing
22:10:22  <tjfontaine>some of those already landed iirc
22:10:33  <bnoordhuis>yeah, i rebased and force-pushed it
22:10:54  <bnoordhuis>curious
22:11:09  <bnoordhuis>it's this one: https://github.com/joyent/node/commit/9352c1988574cbbc8649115007200315d8f79578
22:11:18  <tjfontaine>ya it LGTM otherwise
22:11:54  <tjfontaine>lemme rebuild jenkins with it
22:12:25  <MI6>joyent/node: Ben Noordhuis v0.10 * 9352c19 : child_process: don't emit same handle twice It's possible to read multip - http://git.io/N_W9Kw
22:12:41  <tjfontaine>or I will just that process happen now :)
22:13:01  <bnoordhuis>:)
22:13:22  <trevnorris>bnoordhuis: so no way of removing _charsWritten? it's a bitch that so many buffer methods need to call to a js object every time they run.
22:13:23  <tjfontaine>so this eaddrinuse in the child just plain never worked for windows
22:17:16  <bnoordhuis>trevnorris: not in v0.12 anyway. we can deprecate it though
22:17:22  <bnoordhuis>should have done that for v0.10, really :(
22:17:43  <tjfontaine>wave your hands and say that we did
22:17:44  <tjfontaine>:P
22:17:50  <trevnorris>bummer. oh well. deprecate in 0.12 and remove by v1? i'd be cool w/ that.
22:18:17  * qmxchanged nick to qmx|away
22:19:07  <trevnorris>if I drop offline in a few minutes it's because I smashed my laptop.
22:19:16  <tjfontaine>heh
22:19:35  <trevnorris>in hour 3 and i still can't tell if this memory leak is from my code or from v8.
22:21:19  <bnoordhuis>trevnorris: re valgrind, it only catches malloc/new memory leaks
22:21:38  <bnoordhuis>if you implement a fancy allocator on top of that, you need to tell valgrind about it
22:22:14  <trevnorris>bnoordhuis: ok. so memory is "leaking" only because the external mem i'm allocating isn't being cleaned up.
22:22:28  <trevnorris>but that's because the MakeWeakCallback from the persistent isn't being called.
22:22:36  <trevnorris>so guess it's not really a "memory leak"
22:25:16  <bnoordhuis>well, if the weak callback is never called, i'd call that a memory leak
22:25:29  <bnoordhuis>if it's because the process is exiting, then okay
22:28:13  <trevnorris>my minimal case doesn't leak. my node case through js leaks. so now to use my node case in cc.
22:29:27  <MI6>nodejs-v0.10: #70 UNSTABLE osx-x64 (1/567) windows-x64 (4/567) osx-ia32 (2/567) smartos-ia32 (1/567) windows-ia32 (4/567) linux-ia32 (1/567) http://jenkins.nodejs.org/job/nodejs-v0.10/70/
22:30:24  <tjfontaine>bnoordhuis: heh, it just wants to taunt you http://jenkins.nodejs.org//job/nodejs-v0.10/70/DESTCPU=x64,label=osx//tapTestReport/test.tap-27/
22:30:56  <bnoordhuis>hah
22:46:15  * sblomjoined
22:48:08  * kazuponjoined
22:48:18  <trevnorris>ugh. got it. and hate myself for it...
22:48:32  <tjfontaine>that's the way it usually goes
22:49:26  * benoitcquit (Excess Flood)
22:50:00  * benoitcjoined
22:52:41  * kazuponquit (Ping timeout: 246 seconds)
22:58:16  * `3rdEdenquit (Quit: gnite)
23:00:12  * Kakeraquit (Ping timeout: 256 seconds)
23:04:30  * mikealjoined
23:14:00  <isaacs>uh oh... writing a history of the fall of commonjs in a github issue comment..
23:14:06  * isaacsis going to get some email
23:14:19  <tjfontaine>hehe, I was curious if you'd even bother to respond to that
23:15:17  <bnoordhuis>so this fork-getconnections test failure on os x
23:15:25  <bnoordhuis>i was reading the xnu source earlier tonight
23:15:37  <tjfontaine>oh you poor child
23:15:47  <bnoordhuis>i'm not 100% sure but it looks like it does the same thing linux does, i.e. separate SCM_RIGHTS messages
23:15:54  * benoitcquit (Excess Flood)
23:16:31  <tjfontaine>so then what's happening?
23:16:36  <bnoordhuis>good question
23:16:58  <bnoordhuis>more shotgun debugging is in order, i'm afraid
23:19:07  <tjfontaine>https://github.com/tjfontaine/node/compare/tapname someone want to apply that to master and v0.10?
23:20:38  <trevnorris>ha ha! the same fucking memory leak is in node!
23:20:51  <tjfontaine>hm?
23:21:07  <trevnorris>"var bb = new Buffer(1024); for (var i = 0; i < 1e6; i++) Buffer.call(bb, 1024); "
23:21:13  <trevnorris>(0avgtext+0avgdata 198980maxresident)k
23:22:14  <MI6>joyent/node: Timothy J Fontaine v0.10 * fb6dd0c : test: test name is the last elem, not second When a test requires node t - http://git.io/HlHg0w
23:22:46  <tjfontaine>bnoordhuis: thanks
23:23:09  <trevnorris>(please ignore my last two posts)
23:23:17  * trevnorrismutes for remainder of day
23:24:30  <bnoordhuis>merging in master. waiting for the build to finish
23:25:30  * benoitcjoined
23:28:06  <MI6>joyent/node: Ben Noordhuis master * 1a65154 : Merge remote-tracking branch 'origin/v0.10' Conflicts: deps/v8/src/obje (+17 more commits) - http://git.io/by0nWA
23:37:14  <tjfontaine>ut oh
23:38:01  <tjfontaine>hmm odd
23:38:04  <tjfontaine>http://jenkins.nodejs.org//job/nodejs-v0.10/DESTCPU=x64,label=osx/lastCompletedBuild//tapTestReport/test.tap-358/
23:39:40  <trevnorris>tjfontaine: what caused that?
23:40:05  <tjfontaine>I'm not sure
23:40:20  <trevnorris>sorry. i mean what commit did that run against?
23:40:39  * bradleymeckjoined
23:40:57  <tjfontaine>trevnorris: well, all that changed in that particular case was my tap output stuff, but it's likely that the test itself is sensitive to load in general
23:41:15  <MI6>nodejs-v0.10: #71 UNSTABLE osx-x64 (1/567) windows-x64 (4/567) osx-ia32 (2/567) smartos-x64 (4/567) smartos-ia32 (4/567) windows-ia32 (4/567) http://jenkins.nodejs.org/job/nodejs-v0.10/71/
23:41:19  <tjfontaine>I'll see if it's reproducible, but I doubt it
23:41:27  <trevnorris>tjfontaine: i think there's a test that's supposed to output like that.
23:41:38  <trevnorris>it just makes sure the maxTickDepth is working.
23:41:50  <tjfontaine>trevnorris: sure, but the starvation shouldn't happen
23:41:59  <trevnorris>oh, missed the last line.
23:42:27  <tjfontaine>looking at the test, yes it's quite sensitive to load
23:42:40  <tjfontaine> if (now - start > 100) {
23:42:40  <tjfontaine> throw new Error('The timer is starving');
23:43:11  <tjfontaine>I'm going to chalk that up to a fluke since at the time 4 builds were happening at the time
23:43:24  <tjfontaine>redundant clauses
23:44:15  <MI6>nodejs-master: #116 FAILURE linux-ia32 (1/569) osx-ia32 (2/569) windows-x64 (4/569) smartos-ia32 (1/569) http://jenkins.nodejs.org/job/nodejs-master/116/
23:44:35  <tjfontaine>rebuilding master as I was in the workspace for ia32 which is why it failed
23:48:44  * kazuponjoined
23:53:09  * kazuponquit (Ping timeout: 248 seconds)
23:57:05  * AvianFluquit (Remote host closed the connection)