00:00:04  * xaqquit (Remote host closed the connection)
00:01:18  * xaqjoined
00:02:47  <loladiro>piscisaureus_: Are there any tests that are known/suppose to fail under windows, just so that I don't go off hunting ghosts?
00:03:52  <piscisaureus_>loladiro: I don't think so, but I can run the tests for ya
00:04:05  <piscisaureus_>I mean, I can run them now and see what it says :-)
00:04:58  <piscisaureus_>hmm, tcp_shutdown_after_write just failed on me
00:05:26  <loladiro>failed for me too
00:05:54  <piscisaureus_>the only one tho... the rest seems to work
00:06:26  * xaqquit (Remote host closed the connection)
00:06:34  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:07:51  <piscisaureus_>bnoordhuis: hey
00:08:13  <piscisaureus_>bnoordhuis: if you do a connect and then start reading before the connect completes
00:08:31  <piscisaureus_>bnoordhuis: ... and subsequently, the connect fails... should the read cb be called with an error status?
00:09:36  <bnoordhuis>piscisaureus_: i'd say no
00:10:19  <piscisaureus_>bnoordhuis: that's not very nice eh... i'd consider it good practice that we notify the user when we implicitly stop reading
00:11:29  <bnoordhuis>piscisaureus_: the user is the one that set it up like that, he can take care of himself
00:11:47  <bnoordhuis>besides, uv_read_cb takes a buf argument. what are you going to pass in?
00:12:17  <piscisaureus_>bnoordhuis: ok.. does the READING flag persist after a connect failure?
00:15:09  <piscisaureus_>bnoordhuis: I woudl suppose so, right?
00:15:24  <piscisaureus_>if we're not going to notify the user that it stopped
00:18:59  <bnoordhuis>yes
00:31:29  * mjr_joined
00:31:47  <piscisaureus_>why is nothing ever easy
00:31:49  <piscisaureus_>:-(
00:33:53  <bnoordhuis>piscisaureus_: what's the issue?
00:34:08  <piscisaureus_>uv-win state management
00:34:21  <piscisaureus_>this reading before connecting thing fucks it up
00:34:41  <piscisaureus_>bnoordhuis: should it be possible to do do:
00:34:49  <piscisaureus_>uv_read_start(x)
00:34:51  * mikealquit (Quit: Leaving.)
00:34:52  <piscisaureus_>uv_connect(x)
00:34:54  <piscisaureus_>?
00:35:22  <bnoordhuis>piscisaureus_: if it's too much hassle, we can just disallow it
00:35:37  <piscisaureus_>bnoordhuis: well, I think so
00:35:54  <bnoordhuis>write before connect is a nice to have, read before connect not so much
00:36:08  <piscisaureus_>bnoordhuis: one issue is that we don't really know if it's going to be a server or a connection
00:36:26  <piscisaureus_>maybe we could
00:36:41  <piscisaureus_>but it requires some reorganizations in the uv-win code
00:36:42  <piscisaureus_>and tests
00:36:52  <bnoordhuis>well, if people queue up write reqs on a server handle, they get what they deserve
00:37:20  <piscisaureus_>bnoordhuis: well, but I like it to be slightly predicable
00:37:25  <piscisaureus_>bnoordhuis: I mean, for me
00:37:33  <bnoordhuis>predictable in what sense?
00:37:37  <piscisaureus_>e.g. a failing syscall, an assertion
00:37:57  <piscisaureus_>if I can sort of see the code path that leads to failure in my head that's okay
00:38:09  * mikealjoined
00:38:20  <piscisaureus_>bnoordhuis: but when server state gets clobbered by connection state (because they are in an union) things really get messy
00:38:43  <bnoordhuis>piscisaureus_: in that case we can simply disallow it
00:39:16  <piscisaureus_>I will think about it
00:39:24  <bnoordhuis>that write-before-connect thing is a nice to have, allows for minor optimizations, etc. but that's all it is
00:39:24  <piscisaureus_>there must be ways
00:39:36  <piscisaureus_>bnoordhuis: yeah, I am all in for optimizations
00:39:45  <piscisaureus_>bnoordhuis: it would be nice to have a spec or something
00:40:01  <piscisaureus_>e.g. you can now read before connect, or between connect and connect_cb
00:40:07  <piscisaureus_>(what happens when connect fails)
00:40:30  <bnoordhuis>it's still reading, user will have to call uv_read_stop
00:40:46  <piscisaureus_>and we can now write before connect, or before connect_cb ...
00:40:53  <piscisaureus_>what happens if the user never calls connect
00:41:02  <piscisaureus_>the req is cancelled by closing the socket?
00:41:05  <bnoordhuis>silly user, don't do that
00:41:16  <bnoordhuis>and yes, its cb runs when the handle is closed
00:41:39  <piscisaureus_>bnoordhuis: what happens if the user calls uv_write and then calls uv_listen ?
00:41:48  <piscisaureus_>does it cancel the write reqs and start listening?
00:41:54  <piscisaureus_>does it implicitly stop reading?
00:41:58  <bnoordhuis>neither
00:42:15  <piscisaureus_>does uv_listen return failure?
00:42:38  <bnoordhuis>on uv-unix it will try to write the data and fail
00:42:44  <bnoordhuis>listen will still work though
00:42:59  <bnoordhuis>seems sensible enough to me
00:43:01  <piscisaureus_>bnoordhuis: ok... so if you call write and then listen, the write reqs will be cancelled ?
00:43:10  <bnoordhuis>yes
00:43:20  <piscisaureus_>and read is not implicitly stopped?
00:43:24  <bnoordhuis>no
00:43:30  <piscisaureus_>I suppose that makes sense
00:43:54  <piscisaureus_>what happens if the user listen()s and then calls shutdown?
00:44:08  <piscisaureus_>right now, on windows, that fails synchronously with UV_ENOTCONN
00:44:18  <bnoordhuis>i think uv-unix does something similar
00:44:24  <bnoordhuis>if it doesn't, it should
00:44:57  <bnoordhuis>oh, it sets UV_EINVAL
00:44:59  <bnoordhuis>close
00:46:27  <piscisaureus_>right
00:46:40  <piscisaureus_>what happens if the user is listening and then calls uv_connect?
00:46:50  <piscisaureus_>oh nvm
00:47:51  <piscisaureus_>that should probably fail asynchronously with WSAEINVAL
00:47:54  <piscisaureus_>er, UV_EINVAL
00:48:15  <piscisaureus_>bnoordhuis: ok final one... what if a socket is connecting / connected and the user calls listen() ?
00:48:26  <piscisaureus_>bnoordhuis: do we make listen() fail synchronously?
00:50:15  <CIA-112>libuv: Ben Noordhuis master * r23b4e38 / src/unix/stream.c : unix: make uv_shutdown() return UV_ENOTCONN - http://git.io/TpzMRg
00:50:59  <bnoordhuis>piscisaureus_: hm, good one
00:51:42  <bnoordhuis>piscisaureus_: i guess it should fail synchronously with UV_EINVAL
00:52:09  * travis-cijoined
00:52:10  <travis-ci>[travis-ci] joyent/libuv#393 (master - 23b4e38 : Ben Noordhuis): The build passed.
00:52:10  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/dea4594...23b4e38
00:52:10  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1563261
00:52:10  * travis-cipart
00:55:23  <piscisaureus_>ok
00:55:25  <piscisaureus_>bnoordhuis: kew;
00:55:39  <CIA-112>node: isaacs master * r46b09e4 / (192 files in 15 dirs): Roll V8 back to 3.10.8.13 - http://git.io/ay-o_A
00:55:39  <CIA-112>node: isaacs master * r43ff46b / deps/v8/build/common.gypi : v8: Floating patches - http://git.io/r3uscA
00:55:39  <CIA-112>node: Ben Noordhuis master * r1fb9cfc / deps/v8/src/debug-agent.cc : v8: debug: fix error handling in SendConnectMessage() - http://git.io/_fYXyw
00:55:39  <CIA-112>node: Bert Belder master * rbd33fea / deps/v8/build/common.gypi : Unbreak the Windows build - http://git.io/U94Lhw
00:55:40  <CIA-112>node: isaacs master * r0435f9b / deps/v8/build/common.gypi : v8: Don't use 'echo -n' in configure script - http://git.io/2W9OzQ
00:55:51  <CIA-112>node: Robert Mustacchi master * rf624413 / common.gypi : x64 target should always pass -m64 - http://git.io/vVVLig
00:55:58  <piscisaureus_>bnoordhuis: so finally I have a request ... can you not enable tests that rely on these features before I at least started implementing them ?
00:56:22  <bnoordhuis>piscisaureus_: hah, think of them as gentle reminders :)
00:56:36  <piscisaureus_>bnoordhuis: well, it was already confusing loladiro
00:56:44  <piscisaureus_>bnoordhuis: rather just turn them off
00:56:44  <bnoordhuis>are there any tests in particular you have in mind?
00:56:47  <piscisaureus_>tcp_shutdown_after_write
00:56:58  <piscisaureus_>it does read_start before the connected callback
00:57:06  <bnoordhuis>oh, like that
00:57:14  <piscisaureus_>that's how I got started :-)
00:57:17  <bnoordhuis>that might actually be a bug in the test
00:57:25  <bnoordhuis>i think ibc submitted that one
01:05:09  <piscisaureus_>bnoordhuis: I suggest we do these refactors in the 0.9 timeline
01:05:37  <bnoordhuis>piscisaureus_: agreed
01:13:02  <CIA-112>libuv: Bert Belder master * rb5a15f5 / test/test-tcp-shutdown-after-write.c : test: fix test-tcp-shutdown-after-write bug - http://git.io/3wMpOw
01:13:12  <piscisaureus_>^-- fixed
01:14:07  <piscisaureus_>bnoordhuis: I also think that, if we are going to do this, uv_write, uv_shutdown, uv_connect should have no synchronous failure modes (e.g. they should return void)
01:14:16  <piscisaureus_>bnoordhuis: I am doubtful about uv_listen
01:14:50  <bnoordhuis>piscisaureus_: i half-agree but what if someone calls uv_write when the handle is closed or closing?
01:15:11  <piscisaureus_>hmm, that's a difficult one
01:15:15  * travis-cijoined
01:15:15  <travis-ci>[travis-ci] joyent/libuv#394 (master - b5a15f5 : Bert Belder): The build passed.
01:15:16  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/23b4e38...b5a15f5
01:15:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1563359
01:15:16  * travis-cipart
01:16:03  <piscisaureus_>bnoordhuis: right. What should we do. We could return an error code.
01:16:12  <piscisaureus_>I think uv-win asserts if you do that atm
01:16:39  <piscisaureus_>but I agree that that is questionable, esp. when the handle is closing
01:17:04  <bnoordhuis>good to know the socratic method still works :)
01:17:55  <piscisaureus_>bnoordhuis: we should write this stuff down
01:18:02  <piscisaureus_>bnoordhuis: are you coming to the office tomorrow?
01:18:42  <bnoordhuis>piscisaureus_: maybe, depends. mees is sick and karlijn is only feeling so so
01:19:13  <piscisaureus_>bnoordhuis: your family seem to be quite fragile
01:19:38  <piscisaureus_>bnoordhuis: in percents, what do you think the likelihood is?
01:19:50  <bnoordhuis>piscisaureus_: well, it's what you can expect with babies
01:20:11  <bnoordhuis>karlijn is no baby, of course, just doesn't have the killer autoimmune system i have
01:20:22  <bnoordhuis>re at the office tomorrow, say 50/50
01:20:26  <piscisaureus_>ok
01:20:32  <piscisaureus_>I'll see you around
01:20:34  <piscisaureus_>:-)
01:20:47  <piscisaureus_>I am going home now, so I can make it at the office at 12 or so
01:20:54  <piscisaureus_>we'll have plenty of time
01:20:57  <bnoordhuis>you're still at c9?
01:21:01  <piscisaureus_>yeah
01:21:05  <bnoordhuis>insane
01:21:18  <piscisaureus_>went for beers with Matt, then returned to do some work
01:21:22  <piscisaureus_>well yeah I only started at 3 or so
01:21:27  <bnoordhuis>heh, okay
01:21:52  <piscisaureus_>I mean, it's a 5 minute walk to my bedroom
01:22:26  <piscisaureus_>in 2 years it will always be a 5 minute walk to my bedroom
01:22:44  <bnoordhuis>that's a cryptic statement...
01:23:07  <piscisaureus_>although I won't have to cross the streets to get there
01:23:50  * iraquit (Quit: Textual IRC Client: http://www.textualapp.com/)
01:24:06  <piscisaureus_>bnoordhuis: ok. see you tomorrow
01:24:08  <piscisaureus_>later
01:24:23  <bnoordhuis>sleep tight, bertje
01:24:41  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:26:32  * abraxasjoined
01:29:53  * brsonquit (Read error: Connection reset by peer)
01:30:43  * brsonjoined
01:31:00  * abraxasquit (Remote host closed the connection)
01:38:41  * pieternquit (Quit: pietern)
01:38:50  * abraxasjoined
01:38:51  * ericktquit (Quit: erickt)
01:41:40  <tjfontaine>damnit where's nate
01:43:22  <AvianFlu>HE'S JUST TOO DAMN TALL
01:44:58  <tjfontaine>indeed
01:44:59  * piscisaureus_joined
01:46:37  * isaacsquit (Remote host closed the connection)
01:52:27  * mikealquit (Quit: Leaving.)
01:54:33  <loladiro>piscisaureus_: I've run into the first conceptual problem with the proposed pipe API. Before, if a pipe was used for IPC, the pid was saved by the parent pipe, however, since we're not passing the parent pipe to uv_spawn anymore, that's not possible. What should I do?
01:54:49  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:05:32  * bnoordhuisquit (Ping timeout: 252 seconds)
02:20:48  * irajoined
02:50:03  * brsonquit (Ping timeout: 245 seconds)
03:11:43  * iraquit (Quit: Computer has gone to sleep.)
03:17:53  * brsonjoined
03:25:22  * bulatshakirzyanojoined
03:32:03  * loladiro_joined
03:34:32  * loladiroquit (Ping timeout: 246 seconds)
04:02:51  * c4miloquit (Remote host closed the connection)
04:10:43  * hij1nxjoined
05:07:53  * felixgejoined
05:07:53  * felixgequit (Changing host)
05:07:53  * felixgejoined
05:25:50  * loladiro_quit (Ping timeout: 246 seconds)
05:32:16  * theColejoined
05:33:21  * loladirojoined
05:35:20  * c4milojoined
05:49:14  * hij1nxquit (Quit: hij1nx)
05:59:56  * igorziquit (Ping timeout: 245 seconds)
06:10:02  * paddybyersjoined
06:26:10  * c4miloquit (Remote host closed the connection)
06:29:43  * mmaleckijoined
06:31:38  * loladiroquit (Ping timeout: 246 seconds)
06:40:26  * mmaleckiquit (Quit: Reconnecting)
06:40:33  * mmalecki_joined
06:44:16  * AvianFluquit (Quit: This computer has gone to sleep)
06:52:46  * stephankquit (Quit: *Poof!*)
07:04:23  * rendarjoined
07:27:13  * mmaleckijoined
07:30:14  * mmalecki_quit (Ping timeout: 256 seconds)
07:31:56  * mmaleckiquit (Ping timeout: 256 seconds)
07:50:04  * felixgequit (Read error: Connection reset by peer)
07:51:02  * felixgejoined
07:51:02  * felixgequit (Changing host)
07:51:02  * felixgejoined
07:53:16  * theColequit (Quit: theCole)
07:57:46  * mikealjoined
08:05:42  * mmaleckijoined
08:06:41  * mmaleckiquit (Client Quit)
08:06:52  * mmaleckijoined
08:07:55  * mmaleckiquit (Client Quit)
08:08:08  * mmaleckijoined
08:12:30  * mmaleckiquit (Client Quit)
08:16:49  * mmaleckijoined
08:23:36  * mmalecki_joined
08:23:46  * mmaleckiquit (Quit: Reconnecting)
08:32:19  * mmalecki_quit (Ping timeout: 260 seconds)
09:17:29  * felixge_joined
09:17:30  * felixge_quit (Changing host)
09:17:30  * felixge_joined
09:19:39  * felixgequit (Ping timeout: 265 seconds)
09:19:39  * felixge_changed nick to felixge
09:22:23  * DrPizzaquit (Ping timeout: 260 seconds)
09:22:41  * brsonquit (Quit: leaving)
09:22:48  * DrPizzajoined
09:26:11  * creationixquit (Ping timeout: 260 seconds)
09:31:26  * ljacksonquit (Ping timeout: 260 seconds)
09:35:11  * creationixjoined
09:45:13  * ljacksonjoined
10:17:28  * hij1nxjoined
10:40:10  * mmaleckijoined
10:42:00  * felixgequit (Quit: felixge)
10:43:05  * abraxasquit (Remote host closed the connection)
10:43:31  * felixgejoined
10:43:31  * felixgequit (Changing host)
10:43:31  * felixgejoined
10:53:19  * irajoined
10:56:03  * mmaleckiquit (Quit: Reconnecting)
10:56:16  * mmaleckijoined
11:05:43  * hij1nxquit (Quit: hij1nx)
11:53:31  * piscisaureus_joined
12:17:28  * mmaleckiquit (Quit: leaving)
12:21:11  * c4milojoined
12:22:29  * AndreasMadsenjoined
12:35:18  * piscisaureus__joined
12:37:54  * piscisaureus_quit (Ping timeout: 260 seconds)
12:40:57  * hij1nxjoined
12:44:03  * theColejoined
12:50:43  * hij1nxquit (Quit: hij1nx)
12:54:36  * hij1nxjoined
13:03:48  * theColequit (Quit: theCole)
13:18:40  * c4milo_joined
13:22:27  * c4miloquit (Ping timeout: 245 seconds)
13:39:47  * mmaleckijoined
13:50:34  * madsonjoined
13:53:07  * AndreasMadsenquit (Read error: Connection reset by peer)
13:53:18  * chiltsquit (Ping timeout: 244 seconds)
13:53:49  * einarosquit (Ping timeout: 244 seconds)
13:54:26  * chiltsjoined
13:54:37  * einarosjoined
13:59:06  * bnoordhuisjoined
13:59:29  <bnoordhuis>piscisaureus__: company meeting now?
14:19:39  * ericktjoined
14:32:50  <piscisaureus__>bnoordhuis: at 5 I thnk
14:33:01  <bnoordhuis>ah, okay
14:38:49  * TheJHjoined
14:42:14  * ericktquit (Ping timeout: 272 seconds)
14:48:40  * xaqjoined
14:50:26  * xaqquit (Read error: Connection reset by peer)
14:50:54  * xaqjoined
14:52:29  * xaqquit (Read error: Connection reset by peer)
14:53:00  * xaqjoined
14:53:37  <bnoordhuis>piscisaureus__: https://github.com/joyent/node/issues/3390
14:54:12  <piscisaureus__>bnoordhuis: node --debug <pid>
14:54:28  <piscisaureus__>bnoordhuis: I will write it down
14:54:28  <bnoordhuis>piscisaureus__: tell him
14:54:29  * xaqquit (Read error: Connection reset by peer)
14:54:31  <bnoordhuis>good :)
14:55:02  * xaqjoined
14:55:30  <piscisaureus__>hmm
14:55:35  <piscisaureus__>I don't remember it, exactly
14:55:43  <piscisaureus__>:-(
14:56:37  * xaqquit (Read error: Connection reset by peer)
14:57:22  * xaqjoined
14:57:30  <piscisaureus__>ah
14:57:32  <piscisaureus__>node debug -p
14:58:35  * xaqquit (Read error: Connection reset by peer)
14:59:06  * xaqjoined
15:00:22  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:00:43  * xaqquit (Read error: Connection reset by peer)
15:01:02  * xaqjoined
15:02:33  <bnoordhuis>i can see you, bertje
15:02:35  * xaqquit (Read error: Connection reset by peer)
15:02:36  <bnoordhuis>hip t-shirt
15:02:52  * piscisaureus_joined
15:03:04  * xaqjoined
15:03:05  <piscisaureus_>bnoordhuis: the company meeting is on google plus
15:03:10  <bnoordhuis>yep, i'm there
15:03:12  <bnoordhuis>i can see you
15:03:26  <bnoordhuis>well okay, i see the slides now
15:04:54  <piscisaureus_>kewl
15:13:55  * ericktjoined
15:18:45  <indutny>heya
15:18:51  <indutny>libuv villians
15:18:58  <indutny>how will we conquer world today?
15:25:20  * c4milo_quit (Remote host closed the connection)
15:25:21  * felixgequit (Quit: felixge)
15:31:37  <bnoordhuis>indutny: today we will try gentle persuasion
15:31:45  <bnoordhuis>if that doesn't work, brutal violence
15:32:06  <bnoordhuis>anyway, is there anything you're working on or want to work on?
15:36:57  <indutny>bnoordhuis: well, I'm not really working on anything
15:38:16  <indutny>bnoordhuis: but I want to help :)
15:38:31  <bnoordhuis>indutny: good. there are a couple of semi-critical 0.8 bugs left
15:39:17  <bnoordhuis>indutny: https://github.com/joyent/node/issues?milestone=10&state=open
15:39:51  <bnoordhuis>indutny: feel like finishing the c-ares upgrade in libuv and node?
15:40:02  <indutny>bnoordhuis: this - https://github.com/joyent/node/issues/3170 ?
15:40:18  <bnoordhuis>yeah, that's part of it
15:40:28  <bnoordhuis>but first c-ares need to get upgraded in libuv
15:40:36  <bnoordhuis>i did most of the work already but it's not quite working on windows
15:40:54  <indutny>I don't have any windows machine atm
15:41:37  <bnoordhuis>ah, too bad
15:41:50  <bnoordhuis>no vm either?
15:42:08  <indutny>I don't have licensed copy
15:42:10  <indutny>:)
15:42:25  <indutny>and can't install pirate one on a corporate notebook
15:42:31  <bnoordhuis>right
15:43:05  <bnoordhuis>okay, in that case just sift to the bugs and pick the ones you think are interesting
15:43:10  * loladirojoined
15:43:13  <indutny>ok
15:43:18  <bnoordhuis>there's a crypto bug that'd be nice to have fixed
15:43:32  <bnoordhuis>https://github.com/joyent/node/issues/3372
15:44:26  <indutny>yeah, will look
15:44:50  <indutny>reassigned it to me
15:51:01  * bnoordhuisis off to do the groceries
15:52:19  * iraquit (Quit: Computer has gone to sleep.)
15:54:23  * piscisaureus_off too
15:58:09  * AvianFlujoined
15:58:39  * piscisaureus_quit (Ping timeout: 246 seconds)
16:12:05  * ericktquit (Quit: erickt)
16:26:03  * perezdjoined
16:36:47  * ericktjoined
16:45:00  * ibcjoined
16:46:00  * stephankjoined
16:46:12  <ibc>hi, one a TCP connection is established and EOF is received frmo the peer, I want to call uv_shutdown to allow pending write reqs to terminate. However, once the peer has sent me EOF, is it possible that the read_cb() is called again (i.e. with ECONNRESET)?
16:48:54  <ibc>s/one a TCP.../once a TCP.../
16:53:00  <bnoordhuis>ibc: off the top of my head, your read_cb won't get called again after EOF
16:53:21  <bnoordhuis>the callbacks of queued write reqs will fire when you close the handle btw
16:53:31  <ibc>I hope :) anyhow perhaps I could call to uv_read_stop() to ensure?
16:53:40  <bnoordhuis>yes, that would certainly work
16:53:51  <ibc>ok, thanks a lot
16:54:45  <mmalecki>hey, we're seeing an interesting http issue on our production servers
16:54:51  <mmalecki>actually, more of a stream issue
16:55:27  <mmalecki>https://gist.github.com/55ed1ccbc95f1e08e7aa
16:55:28  <saghul>bnoordhuis what's missing for the c-ares upgrade?
16:55:49  <saghul>when I did it back in the day, it did work on windows, though i'm not sure if all 32/64bit things where ok
16:55:50  <mmalecki>I know that the stream we're piping to *has* a .destroy method
16:56:42  <bnoordhuis>saghul: i don't quite remember but piscisaureus complained that test-gethostbyname.c was failing or hanging
16:56:56  <bnoordhuis>saghul: if you want to pick up the slack, by all means do :)
16:57:23  <saghul>bnoordhuis windows is not my usual environment, but i'll see what I can do :-)
16:57:28  <bnoordhuis>thanks
16:57:47  <mmalecki>maybe we should do dest.destroy && dest.destroy()?
16:58:17  <saghul>your work is here, right? https://github.com/bnoordhuis/libuv/tree/cares-1.8.0
16:58:49  <bnoordhuis>saghul: yes, that's the one
16:59:29  * dshaw_joined
16:59:59  * madsonquit (Remote host closed the connection)
17:00:11  <bnoordhuis>mmalecki: i don't know, that error message seems to indicate that whatever you're piping to does not have a .destroy method
17:00:36  <mmalecki>bnoordhuis: it does have it tho, I put in some debugging
17:00:45  <mmalecki>we're piping to an http request
17:00:58  <bnoordhuis>request or response?
17:01:17  <mmalecki>http.request() result :)
17:01:21  * igorzijoined
17:01:23  <bnoordhuis>ah okay
17:01:24  <mmalecki>I'm bad with these names
17:01:45  <bnoordhuis>if you have a test case, i can look into it
17:02:29  <bnoordhuis>if it turns out to be a bug in your code however, you are morally obliged to send me a sixpack of the best local beer
17:02:31  <mmalecki>we're having a hard time reproducing it :)
17:02:56  <mmalecki>it happens when you abort an incoming request
17:03:17  <mmalecki>which is piped to a http.request()
17:05:15  <bnoordhuis>seems like that should be relatively straightforward to 'test case'-ify
17:05:27  <AvianFlu>it's been very sporadic
17:05:52  <AvianFlu>the same tarball upload can trigger it at one point, and then work the next 30 times
17:06:38  <bnoordhuis>maybe add some logging code right before the offending line in stream.js?
17:07:02  <bnoordhuis>it would be interesting to know what kind of object it is and why it's lacking that .destroy method
17:07:19  <mmalecki>will do
17:07:55  <mmalecki>I'm really happy my dotfiles are on this server :D
17:09:45  * japjjoined
17:10:15  * ericktquit (Quit: erickt)
17:13:36  <mmalecki>some debugging added, hopefully we'll have something useful soon
17:13:49  * irajoined
17:18:40  * ericktjoined
17:31:50  * igorzi_joined
17:33:16  * igorziquit (Ping timeout: 245 seconds)
17:34:35  <japj>ah, it seems node.js master v8 build is broken again on windows
17:36:27  * loladiroquit (Read error: Connection reset by peer)
17:37:35  * loladirojoined
17:38:40  * AndreasMadsenjoined
17:39:28  * ibcquit (Remote host closed the connection)
17:40:25  * hij1nxquit (Quit: hij1nx)
17:40:28  * mmaleckiquit (Quit: leaving)
17:40:41  * mikealquit (Quit: Leaving.)
17:41:05  * mikealjoined
17:59:08  * brsonjoined
18:01:06  * theColejoined
18:02:49  <saghul>what's the difference between running a test with "run-tests foo" and "run-tests foo foo" ?
18:09:28  * piscisaureus_joined
18:14:36  * theColequit (Quit: theCole)
18:16:37  * isaacsjoined
18:17:59  * txdvquit (Read error: Connection reset by peer)
18:21:21  * txdvjoined
18:21:57  * mikealquit (Quit: Leaving.)
18:23:30  * hij1nxjoined
18:26:48  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:27:41  * pieternjoined
18:28:26  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
18:32:25  * piscisaureus_joined
18:40:52  <japj>piscisaureus_: it seems node master v8 is failing build again after switch to 3.10
18:46:11  <isaacs>japj: hey
18:46:17  <isaacs>that's probably my fault.
18:46:39  <isaacs>japj: i merged piscisaureus_'s un-breaking fix on top of it, are you getting the same failure as before?
18:47:09  * mikealjoined
18:48:09  <piscisaureus_>isaacs: it could be that that fix was 3.11 specific
18:48:11  <piscisaureus_>lemme try without
18:49:19  <isaacs>kewl. i'm pulling it into my windows vm, as well.
18:49:32  * isaacsreally wants `make remote-test`
18:50:30  <piscisaureus_>yeah, reverting that fixes it.
18:50:37  <CIA-112>node: Bert Belder master * r5046f85 / deps/v8/build/common.gypi : Revert "Unbreak the Windows build" - http://git.io/31482w
18:50:49  <isaacs>sweet, thanks, piscisaureus_
18:51:02  <isaacs>my windows machine isn't even done cloning
18:51:51  * perezdquit (Read error: Connection reset by peer)
18:52:08  * perezdjoined
18:57:32  * mmaleckijoined
19:00:34  <isaacs>piscisaureus_: can anything be done about this?
19:00:35  <isaacs> 'C:\Users\Isaac' is not recognized as an internal or external command,
19:00:35  <isaacs> operable program or batch file.
19:00:36  <isaacs>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(1
19:00:38  <isaacs>51,5): error MSB6006: "cmd.exe" exited with code 1. [C:\Users\Isaac Schlueter\n
19:00:40  <isaacs>ode\deps\v8\tools\gyp\v8_snapshot.vcxproj]
19:00:42  <isaacs>C:\Users\Isaac Schlueter\node>
19:00:54  <isaacs>piscisaureus_: seems pretty common to have ' ' in paths in windows home dirs
19:01:05  <piscisaureus_>yeah, it can probably be fixed
19:01:36  <piscisaureus_>lemme try
19:01:44  * piscisaureus_compiles v8 once more
19:02:10  <japj>hmm.. so Isaac is not an internal or external command?? how odd ;)
19:03:22  <piscisaureus_>weird
19:03:22  <piscisaureus_>C:\Users\Bert Belder\>Isaac
19:03:23  <piscisaureus_>At your service, sir.
19:03:23  <piscisaureus_>C:\Users\Bert Belder\>
19:03:27  * japjis ironing and watching web rebel videos at the same time
19:05:24  <japj>(the joys of filling my new clothing closet with a backlog of washed clothes, no more piling up somewhere in the room I guess)
19:11:20  * dshaw_quit (Quit: Leaving.)
19:11:48  <piscisaureus_>isaacs: we'll have to patch gyp to make that work
19:12:15  <piscisaureus_>isaacs: (or python :-p)
19:12:32  <loladiro>piscisaureus_: Should I just plainly read/write the pid in uv_read_start or does it need some kind of IPC protocol header or something
19:12:34  <piscisaureus_>If they had this written gyp in node, this wouldn't have happened
19:13:00  <piscisaureus_>loladiro: well, I think just a raw pid would suffice for now
19:13:15  <piscisaureus_>loladiro: you just have to be careful to write it only once, before anything else
19:13:30  <piscisaureus_>and also to expect it only once
19:13:32  <japj>piscisaureus_: sounds like a bootstrap issue, build v8 with node that uses v8 ;)
19:13:42  <loladiro>piscisaureus_: Can uv_read_start be called more than once?
19:13:54  <piscisaureus_>umm, not atm I thin
19:13:55  <piscisaureus_>k
19:14:02  <piscisaureus_>but that's sorta lame
19:14:24  <piscisaureus_>loladiro: you could jus set handle->flags & UV_HANDLE_PID_WRITTEN :-)
19:14:41  <loladiro>that's what I was gonna suggest next ;)
19:15:10  <piscisaureus_>loladiro: btw - I can take a look at your patches like this, but we can't land them
19:15:17  <piscisaureus_>because they deviate a lot from our coding conventions
19:15:35  <loladiro>sure. That's all I wanted
19:15:40  * brsonquit (Ping timeout: 246 seconds)
19:15:49  <loladiro>is the coding convention written down somewhere?
19:16:04  <piscisaureus_>not really, but generally we follow the v8 c++ style guide
19:16:10  <piscisaureus_>and sometimes we're inconsistent, too :-)
19:16:19  <piscisaureus_>but I'd say: use two-space indent
19:16:25  <piscisaureus_>don't exceed 80 lines
19:16:29  <piscisaureus_>er, 80 columns
19:16:39  <piscisaureus_>and put spaces between variable names and operators
19:17:01  <loladiro>ok
19:17:15  <loladiro>I'll reformat once we figure the functional details out
19:17:16  <piscisaureus_>loladiro: the other stuff is just nitpicking
19:17:18  <piscisaureus_>yeah
19:17:38  * mmalecki_joined
19:17:51  <loladiro>ok. So how do I handle the reading of the pid? Do I somehow need to inject a readcb or something?
19:18:00  <piscisaureus_>loladiro: yes
19:18:04  <loladiro>ok
19:18:23  <piscisaureus_>so you can probably just use handle->read_req for that, as long as you store somewhere that this is not an user request
19:18:38  <piscisaureus_>but rather reading of the pid
19:18:43  <loladiro>I can just check the flag
19:18:54  <piscisaureus_>yeah, that works
19:19:54  <piscisaureus_>loladiro: are you mostly an unix dev or a windows dev?
19:20:11  <loladiro>piscisaureus_: both. I'll do whatever needs to be done
19:20:24  <loladiro>Atm I'm mostly windows though
19:20:34  <loladiro>as there's so many other people on the team who are unix only
19:21:22  * mmaleckiquit (Ping timeout: 252 seconds)
19:22:13  * mmalecki_changed nick to mmalecki
19:22:37  * brsonjoined
19:22:59  * felixgejoined
19:22:59  * felixgequit (Changing host)
19:22:59  * felixgejoined
19:23:44  <piscisaureus_>loladiro: ah, that explains why you did so much on the windows side of things :-)
19:24:28  <loladiro>piscisaureus_: I figured that would be the more difficult implementation. Also, Julia already works on unix, so windows is my primary target right now
19:24:41  <piscisaureus_>:-)
19:24:45  <piscisaureus_>makes sense
19:24:50  <loladiro>I'm developing on a macbook running mac/windows/ubuntu in parallel
19:25:02  <loladiro>I can just swipe between them
19:30:37  <loladiro>piscisaureus_: If I write the pid all at once and then read only the 4 bytes that make up the pid, is it possible that I'm not getting all of the pid (i.e. that it's split up into two seperate callbacks)?
19:31:28  <tjfontaine>arg, how do I convince node-gyp to stop trying to use the damn downloaded headers
19:33:12  <piscisaureus_>loladiro: ehm, well, that'll likely never happen
19:33:26  <piscisaureus_>I guess for the sake if correctness we should handle the case
19:33:53  <piscisaureus_>loladiro: but, no, I don't think that could happen, and I don't mind if you don't handle the case
19:34:25  <loladiro>piscisaureus_: Ok, then I won't.
19:35:01  <piscisaureus_>loladiro: I can see one issue. If the user does a write request before it received the remote pid, we have problem
19:35:11  <piscisaureus_>we'd have to stash the write req somewhere and process it later
19:35:42  <loladiro>so if the user calls uv_write before uv_read_start?
19:35:45  <piscisaureus_>yeah
19:36:08  <japj>loladiro: there is an option to node-gyp called --nodedir
19:36:18  <piscisaureus_>also, we'd have to send the pid ourselves then first, because the remote end is going to asssume that the first thing it receives is the pid
19:36:36  <piscisaureus_>but I suppose that's easier to implement
19:36:40  <loladiro>so how about I also add some logic to uv_write that injects a write request
19:36:41  <japj>loladiro: you can specify to a locally build version of nodejs (i.e. a git directory with build results)
19:36:42  <tjfontaine>japj: I think you meant me
19:36:53  <japj>tjfontaine: ah, sry ;)
19:37:02  <piscisaureus_>loladiro: I am going offline for a short while... gotta get food before the shops close
19:37:11  <loladiro>piscisaureus_: ok
19:37:12  <piscisaureus_>loladiro: i'll be back later tho
19:37:21  <japj>tjfontaine: anyway --nodedir should work in a recent version of node-gyp (I added that recently)
19:39:11  <tjfontaine>japj: why didn't you add it to the --help :)
19:40:52  <japj>tjfontaine: ah, apparently there is no --help for commands, that's not good
19:41:40  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:43:57  <japj>tjfontaine: --nodedir should work for the configure step, if it doesn't do what you need let me know
19:44:41  <tjfontaine>japj: it was more frustrating that it jsut didn't do the right thing, I think it should be able to figure out what's going on especially if it's a debug build
19:45:03  <tjfontaine>japj: I'm beyond that part now and am working on debugging this though, thanks
20:07:54  * AndreasMadsenquit (Remote host closed the connection)
20:14:23  * piscisaureus_joined
20:16:09  <piscisaureus_>http://blogs.msdn.com/b/visualstudio/archive/2012/06/08/visual-studio-express-2012-for-windows-desktop.aspx
20:17:58  <creationix>piscisaureus_: how hard would it be to modify libuv to not be callback based and instead expose the root iterator?
20:18:23  <piscisaureus_>creationix: umm, I think, hard
20:18:44  <tjfontaine>what problem are you trying to solve that you need that?
20:19:00  <piscisaureus_>creationix: to be honest, I don't think that'll ever hapen
20:19:02  <creationix>I know I'd lose a ton of sugar, but could I do something like (while (event = getEvent()) translated to C
20:19:18  * mikealquit (Quit: Leaving.)
20:19:23  <creationix>I'm just curious, the "problem" is to remove callbacks
20:19:47  <creationix>in SDL I don't need callbacks, I just poll for events in a loop select style
20:20:17  <piscisaureus_>creationix: well mostly there's code that does stuff like
20:20:17  <piscisaureus_>while (read(...) >= 0) handle->read_cb(yyy)
20:20:47  <creationix>but libuv multiplexes several event sources right?
20:20:52  * mikealjoined
20:20:57  <piscisaureus_>creationix: yes
20:20:59  <creationix>I'm not clear on how that section works
20:21:05  <piscisaureus_>but that's highly platform dependent
20:21:25  <creationix>I see, so it would be a lot of work to provide a platform-independent master select loop
20:21:33  <piscisaureus_>well on unix it multiplexes signals + fds + a timeout
20:21:48  <piscisaureus_>on windows it multiplexes iocp packets, fd signals, event firing
20:22:04  <piscisaureus_>soon it will multiplex getmessage too, and APCs
20:22:17  <piscisaureus_>creationix: yes
20:22:48  <creationix>well, even if I had such a select loop, most code would just switch over the types and call callbacks in the user's code
20:22:53  <creationix>the events need to be routed somehow
20:23:59  <piscisaureus_>creationix: the problem is that the "events" that libuv multiplexes are not really the events that are exposed to the end user
20:24:10  <piscisaureus_>that's like it's entire purpose
20:24:21  <piscisaureus_>different OSes have different event models
20:24:31  <piscisaureus_>but libuv provides the user with a consistent one
20:24:46  <creationix>right, but you could smooth over the OS differences with a select style interface
20:24:55  <creationix>I'm just trying to imagine if that's a good idea at all
20:25:22  <piscisaureus_>creationix: what do you mean with a "select style" interface ?
20:25:23  * felixgequit (Quit: felixge)
20:25:46  <piscisaureus_>look, I'm not saying it's impossible ... it is very likely to be possible
20:25:58  <creationix>I mean a blocking call uv_get_event() that returns when there is the next event
20:26:02  <piscisaureus_>but it'll basically mean that we'd have to rewrite libuv
20:26:07  <creationix>then my app will be the event loop and I'll route everything myself
20:26:13  <piscisaureus_>and I am totally not feeling for that :-)
20:26:27  <creationix>would it be faster for simple things?
20:26:36  <creationix>where I could route using a switch instead of callbacks?
20:26:57  * indexzerojoined
20:29:53  <creationix>I guess I could always layer such an API on top to get a feel for it. It wouldn't be as fast as bare metal, but should be enough to experiment
20:30:20  * piscisaureus_quit (Read error: Connection reset by peer)
20:30:57  * piscisaureus_joined
20:31:55  <piscisaureus_>creationix: that could work
20:31:59  <piscisaureus_>layer it on top
20:32:20  <creationix>piscisaureus_: I'm just asking because of something Mike Pall said
20:32:33  <creationix>he thinks callbacks are the wrong way to do this
20:32:34  <piscisaureus_>creationix: but for us - it'd mean that we'd have to rewrite libuv from something that is more or less imperatively programmed, to a giant state machine
20:32:48  <creationix>he says we should use "iterators"
20:33:09  <piscisaureus_>who is Mike Pall ?
20:33:16  <pquerna>wrote luajit
20:34:16  <piscisaureus_>tell him to submit patches
20:34:22  <indutny>piscisaureus_: ++
20:34:58  <creationix>lol
20:35:11  <piscisaureus_>of coursem nobody is stoppying anyone from forking libuv :-)
20:35:12  <creationix>that would be like a pull request to rewrite your node library in coffeescript
20:35:29  <creationix>I'm just trying to understand what he meant and why he's against callbacks
20:35:34  <creationix>I know they make ffi painful
20:35:36  <isaacs>creationix: i think "we'd have to rewrite libuv to not use callbacks" is a boiling-the-ocean approach.
20:35:40  * mmaleckiquit (Quit: Reconnecting)
20:35:40  <creationix>but other than that, are they bad?
20:35:42  * mmalecki_joined
20:36:10  <creationix>isaacs: indeed, callbacks are kinda central to node and by extension libuv
20:36:16  <piscisaureus_>not really I think
20:36:38  <piscisaureus_>you couldn't design an OS around callbacks - you'd want to use GetEvent() etc indeed
20:37:01  <piscisaureus_>but no, why would callbacks be bad?
20:37:08  <creationix>but wouldn't you use callbacks at some layer by the time you reached the application level?
20:37:22  <creationix>I can't imagine using a state machine for a 300k-line business app
20:37:42  <piscisaureus_>at the application layer, callbacks are awesome right?
20:37:55  <creationix>I like 'em, but I don't know any better
20:38:03  <loladiro>piscisaureus_: To go back to the pid ipc. How about injecting an extra write to the first call to uv_write
20:38:28  * mmalecki_quit (Client Quit)
20:38:40  <piscisaureus_>loladiro: that would work. But that means that if the other end wants to send you something before you have something to say, you have a deadlock
20:38:45  * mmaleckijoined
20:38:55  <piscisaureus_>so unless you have a solution for that, actually that doesn't work :-)
20:39:12  <creationix>piscisaureus_: thanks. If it was trivial, I would play with it, but I don't want to rewrite libuv
20:39:51  <loladiro>piscisaureus_: Well, I guess we'll have to add to both uv_read_start and uv_write then?
20:40:06  <piscisaureus_>loladiro: yes
20:40:26  <piscisaureus_>loladiro: whenever the process starts using the thing, we have to make sure the pid is out
20:40:40  <piscisaureus_>unfortunately we can't do it immediately when the handle is created
20:40:46  <isaacs>igorzi_: ping
20:40:50  <piscisaureus_>because that would mean we'd send a process it's own pid
20:41:10  <loladiro>piscisaureus_: How does uv_write save buffers that are not currently processed (i.e. bufs[i] where i>0). I can't seem to figure it out from the code in uv_write
20:41:26  <isaacs>igorzi_: fs.symlink() on windows is giving me a UNKNOWN error. seems like a permission thing, works for administrator
20:41:27  <piscisaureus_>loladiro: well, in fact pipes don't support that atm
20:41:42  <piscisaureus_>loladiro: that is, we offically support it but it doesn't work ;-)
20:42:07  <loladiro>aha. That makes more sense. Shouldn't there be a note somewhere ;)
20:42:24  <piscisaureus_>loladiro: I know how to do it though - but that's a refactor we will make in the 0.9 timeline (the one that Ben and I were discussing yesterday)
20:43:10  <piscisaureus_>loladiro: ^-- That's not very clear probably. I meant: we are going to release node 0.8 first
20:43:17  <loladiro>piscisaureus_: Hmm. How would I inject an extra write then?
20:43:50  <piscisaureus_>loladiro: well, you need a req for it, that's the major problem
20:44:12  <loladiro>ah, so that what you meant to use read_req for
20:44:23  <piscisaureus_>loladiro: injecting another write (supposing that the ipc pipe is using IOCP, which should always be the case) is just a matter of
20:44:34  <piscisaureus_>WriteFile(xxx, yyy, &req->overlapped)
20:44:50  <piscisaureus_>loladiro: well I think you should use read_req to read the pid
20:45:01  <piscisaureus_>lemme see if we have some spare room
20:45:19  <loladiro>can't we just directly read it into the pid field?
20:45:40  <piscisaureus_>loladiro: yes, we can
20:45:49  <piscisaureus_>loladiro: but you need a req field to do the read in the background
20:46:02  <piscisaureus_>because if the other process takes it's time, then the ReadFile call will block
20:46:15  <piscisaureus_>until the pid arrives
20:46:33  <piscisaureus_>loladiro: although - hmm
20:46:39  <piscisaureus_>loladiro: I suppose it could work
20:46:41  <loladiro>hmm. It seems this is more complicated then I though. Would you mind taking a shot at implementing it? I don't wanna mess up
20:47:21  <piscisaureus_>loladiro: lemme see
20:48:12  * ryahjoined
20:52:06  <piscisaureus_>loladiro: ok, I'll take a stab at it. But I want to finish my "current" project first
20:52:29  <piscisaureus_>loladiro: I think we'd be best off if the IPC pipe framing gets reorganized a little
20:53:37  * indexzeroquit (Quit: indexzero)
20:54:05  <loladiro>piscisaureus_: Ok. sounds good. I won't have too much time today and tomorrow anyway as I'm moving to back to Europe on Sunday for three months and I haven't packed yet ;)
20:54:26  <piscisaureus_>loladiro: ah, good :-) We can mee
20:54:52  <piscisaureus_>loladiro: we can talk a little earlier than 4am then :-p
20:55:05  <loladiro>piscisaureus_: indeed.
20:55:12  <piscisaureus_>loladiro: where are you heading, btw
20:55:26  <loladiro>piscisaureus_: home to Germany for the summer
20:55:54  <piscisaureus_>loladiro: right. Are you in the US for your study?
20:56:01  <piscisaureus_>or work?
20:56:06  <loladiro>piscisaureus_: study
21:17:28  <pietern>haha
21:17:45  <pietern>was looking for latest guidelines for c addons
21:17:52  <pietern>but as I was reading this page http://nodejs.org/api/addons.html
21:18:02  <pietern>I found it pointed me to https://github.com/pietern/hiredis-node
21:18:10  <pietern>loop detection kicking in
21:18:15  * dshaw_joined
21:21:53  <mjr_>pietern: you are the reference implementation
21:22:20  <pietern>mjr_: I was wondering about bypassing the net module, and hooking directly into uv for hiredis
21:22:41  <pietern>theoretically that should approach redis-benchmark speeds
21:23:01  <AvianFlu>piscisaureus_: https://github.com/AvianFlu/node/compare/detached when you get a minute
21:23:07  <AvianFlu>isaacs too ^^
21:24:24  <mjr_>pietern: yeah, you ought to get some speedup there. Have you run flame graphs against multi_bench lately? I'm not sure that it spends too much time in net.
21:25:08  <pietern>mjr_: there's also a new parser that I want to give a spin
21:25:14  <pietern>so just exploratory hacking ;)
21:25:29  <pietern>in any case it cuts down on memcpy's and malloc's
21:26:38  <creationix>has anyone tried libuv on iOS?
21:26:42  <creationix>embedding it in an app
21:27:55  <piscisaureus_>AvianFlu: I don't think child processes have to be auto unref'ed when detached is specified
21:28:23  <piscisaureus_>AvianFlu: if the user wants that, he could just do it himslef
21:28:42  * loladiro_joined
21:28:55  <AvianFlu>piscisaureus_, I figured you were gonna say that :D
21:28:56  <piscisaureus_>AvianFlu: also, the best test approach would be imho to see if the child process still lives after the parent exits
21:29:10  <piscisaureus_>AvianFlu: well, it's looking good now innit? :-)
21:29:16  <AvianFlu>haha yeah
21:29:43  <piscisaureus_>AvianFlu: now you can do more stuff like, "if I crash, my child processes should stay alive"
21:29:53  <AvianFlu>yeah, makes sense
21:31:10  * loladiroquit (Ping timeout: 256 seconds)
21:34:17  <isaacs>AvianFlu: i agree with piscisaureus_
21:34:43  <isaacs>AvianFlu: no auto-unref, and maybe add test/fixtures/parent-process-notpersistent.js that spawns detached and then immediately exits.
21:34:51  <isaacs>test/fixtures/deadbeat.js
21:34:51  <piscisaureus_>you're supposed to :-p
21:35:42  <AvianFlu>lol, deadbeat
21:36:18  <AvianFlu>I'll be back with some changes in a bit
21:36:34  * japjquit (Remote host closed the connection)
21:37:00  <igorzi_>isaacs: hey
21:37:07  <igorzi_>isaacs: are you passing in 'junction'?
21:38:12  <isaacs>igorzi_: no, i'm passing in 'dir'
21:38:20  <isaacs>igorzi_: but there were other problems. i've got it working now as admin
21:38:23  <isaacs>but not as a normal user
21:38:36  <igorzi_>isaacs: for non-admin you must pass in 'junction'
21:38:50  <isaacs>i see.
21:38:54  <isaacs>ok, lemme try it that way
21:39:01  <igorzi_>isaacs: (it's not automatic)
21:39:21  <isaacs>igorzi_: didn't we used to expose the system errno for fs stuff at some point? it's really painful to get code=UNKNOWN
21:39:24  <isaacs>totally not helpful
21:40:06  <igorzi_>isaacs: it think we did in the past.. piscisaureus_, do you know?
21:40:58  <piscisaureus_>igorzi_: I think there is a libuv patch pending review
21:41:35  <piscisaureus_>igorzi_: uv_err_t._sys_errno has the system errno but it's not exposed in node
21:42:45  * loladiro_quit (Ping timeout: 260 seconds)
21:43:35  <isaacs>AvianFlu: kewl. otherwise, it looks good.
21:48:14  <isaacs>igorzi_:
21:48:16  <isaacs>C:\Users\Isaac Schlueter\semver>npm link
21:48:16  <isaacs>npm WARN linkPkg C:\Users\Isaac Schlueter\semver
21:48:16  <isaacs>npm WARN link fs.symlink("C:\\Users\\Isaac Schlueter\\semver", "C:\\Users\\Isaac
21:48:18  <isaacs> Schlueter\\AppData\\Roaming\\npm\\node_modules\\semver")
21:48:20  <isaacs>C:\Users\Isaac Schlueter\AppData\Roaming\npm\semver -> C:\Users\Isaac Schlueter\
21:48:22  <isaacs>AppData\Roaming\npm\node_modules\semver\bin\semver
21:48:24  <isaacs>../AppData/Roaming/npm/node_modules/semver -> C:\Users\Isaac Schlueter\semver
21:48:26  <isaacs>igorzi_: that is, it worked
21:48:37  <isaacs>igorzi_: a bit lame that it must be absolute, but i guess that's not so terrible.
21:48:45  <igorzi_>isaacs: sweet
21:49:17  <igorzi_>isaacs: yep.. the absolute path requirement is unfortunate
21:49:20  * loladirojoined
21:49:40  <isaacs>it just means you can't move them around, but i mean, no one really does that anyway
21:49:44  * mmaleckiquit (Ping timeout: 260 seconds)
21:51:14  <piscisaureus_>isaacs: well, I think that for this purpose you actually *want* the symlink to be absolute
21:51:57  <piscisaureus_>isaacs: because otherwise you can't move either of them around
21:52:19  <piscisaureus_>isaacs: relative symlinks only play out nicely when you expect that the source and the target are going to be moved together
21:52:31  <isaacs>piscisaureus_: yes, so, for linking bins, that makes sense.
21:52:40  <isaacs>piscisaureus_: but we don't actually symlink bins on windows anyway
21:52:40  <piscisaureus_>isaacs: yes
21:52:52  <piscisaureus_>isaacs: but you can't create junctions to files, anyway
21:52:59  <isaacs>and, the logic only relativizes it if the rel path is shorter than the absolute path, which it usually isn't for unix global links
21:53:42  <piscisaureus_>that sound like a funny heuristic to me
21:54:59  <isaacs>piscisaureus_: it's more about readability than portability
21:55:24  <isaacs>cd /some/really/long/path; link a b; expect a -> ./b, not a -> /some/really/long/path/b
21:55:35  <isaacs>er, link b a
21:55:45  <isaacs>silly backwards symlink argument semantics
21:56:22  * mmaleckijoined
22:05:45  * dshaw_quit (Quit: Leaving.)
22:21:40  * mralephjoined
22:24:12  <isaacs>hm, seems like the new symlink stuff is not understood by realpath... https://gist.github.com/2898421
22:24:16  * isaacson it
22:24:47  <isaacs>hahaha
22:24:49  <isaacs>if (isWindows) {
22:24:49  <isaacs> // Node doesn't support symlinks / lstat on windows. Hence realpath is just
22:24:49  <isaacs> // the same as path.resolve that fails if the path doesn't exists.
22:24:51  <isaacs> // windows version
22:24:54  <isaacs>(from fs.realpath)
22:25:54  * TheJHquit (Ping timeout: 260 seconds)