00:10:10  * AvianFlujoined
00:18:07  * dylukesjoined
00:19:29  * orlandovftwquit (Ping timeout: 265 seconds)
00:27:10  * AvianFluquit (Quit: Leaving)
00:30:09  * pfox___quit (Ping timeout: 252 seconds)
00:31:19  * brsonquit (Ping timeout: 272 seconds)
00:31:33  <piscisaureus_>I am leavink.
00:31:39  <piscisaureus_>bye all.
00:31:45  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:47:08  * pfox___joined
00:52:30  * pieternquit (Ping timeout: 276 seconds)
01:18:59  * orlandovftwjoined
01:28:47  * abraxasjoined
01:28:48  * dapquit (Quit: Leaving.)
01:30:58  * igorziquit (Ping timeout: 245 seconds)
01:32:37  * orlandovftwquit (Ping timeout: 248 seconds)
01:40:15  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:59:08  * dvvjoined
03:02:13  * isaacsjoined
03:04:00  * Ariajoined
03:05:55  * Ariaquit (Read error: Connection reset by peer)
03:06:23  * Ariajoined
03:10:30  * benviequit
03:10:57  * benviejoined
03:14:04  * Ariaquit (Read error: Connection reset by peer)
03:15:57  * Ariajoined
03:19:38  * dvvpart
04:10:49  * Ariaquit (Read error: Connection reset by peer)
04:11:24  * Ariajoined
04:17:49  * rphillipsquit (Ping timeout: 246 seconds)
04:19:30  * dylukesquit (Quit: Pipes are broken. Sending packets via Fedex.)
04:20:25  * rphillipsjoined
04:36:30  * Ariaquit (Remote host closed the connection)
05:49:16  * orlandovftwjoined
05:56:14  * pfox___quit (Quit: leaving)
06:44:01  * isaacsquit (Remote host closed the connection)
07:06:40  * paddybyersjoined
07:08:16  * ljacksonquit (Read error: Operation timed out)
07:16:23  * rendarjoined
07:24:37  * ljacksonjoined
07:24:54  * txdvjoined
07:26:02  * txdv_quit (Read error: Operation timed out)
07:36:36  * AvianFlujoined
08:46:43  * orlandovftwquit (Ping timeout: 265 seconds)
10:06:18  * `3rdEdenjoined
10:24:48  * `3rdEdenquit (Quit: Leaving...)
10:39:28  * bnoordhuisjoined
10:57:27  * abraxasquit (Remote host closed the connection)
10:58:00  * abraxasjoined
11:02:32  * abraxasquit (Ping timeout: 260 seconds)
11:16:06  * russell_hquit (Ping timeout: 252 seconds)
11:19:17  * sj26quit (Ping timeout: 248 seconds)
11:24:56  * theColejoined
11:37:25  * russell_hjoined
11:41:02  * sj26joined
11:46:29  * skomskijoined
11:54:00  * `3rdEdenjoined
12:14:20  * theColequit (Quit: theCole)
12:49:24  * `3rdEdenquit (Quit: Leaving...)
13:01:36  * `3rdEdenjoined
13:11:55  * piscisaureus_joined
13:14:03  <piscisaureus_>bnoordhuis: let's do a presentation
13:42:55  * k-s[AWAY]changed nick to k-s
13:53:55  <CIA-99>libuv: Igor Zinkovsky v0.6 * r85d2be4 / (4 files in 2 dirs):
13:53:55  <CIA-99>libuv: windows: return UV_ENOTSOCK when doing uv_pipe_connect to a file
13:53:55  <CIA-99>libuv: Conflicts:
13:53:55  <CIA-99>libuv: src/win/pipe.c - http://git.io/wi9bzQ
13:55:38  * travis-cijoined
13:55:38  <travis-ci>[travis-ci] joyent/libuv#174 (v0.6 - 85d2be4 : Igor Zinkovsky): The build is still failing.
13:55:38  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/9c8f6dd...85d2be4
13:55:38  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1024789
13:55:38  * travis-cipart
13:57:20  <CIA-99>libuv: Igor Zinkovsky v0.6 * r8cbbfbe / test/test-pipe-connect-error.c : test: make pipe_connect_to_file succeed with ECONNREFUSED - http://git.io/NIKD_g
13:59:07  * travis-cijoined
13:59:07  <travis-ci>[travis-ci] joyent/libuv#175 (v0.6 - 8cbbfbe : Igor Zinkovsky): The build is still failing.
13:59:07  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/85d2be4...8cbbfbe
13:59:07  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1024800
13:59:07  * travis-cipart
14:08:03  <piscisaureus_>I am completely lost
14:19:21  <tjfontaine>have you tried hare krishna?
14:20:33  * saghulquit (Quit: [Textual IRC Client: http://www.textualapp.com/])
14:25:05  * `3rdEdenquit (Quit: Leaving...)
14:34:59  * `3rdEdenjoined
14:46:37  <bnoordhuis>piscisaureus_: what about?
14:50:29  <CIA-99>libuv: Bert Belder v0.6 * rcda7a28 / (4 files in 2 dirs): (log message trimmed)
14:50:29  <CIA-99>libuv: Windows: backport pipe-connect-to-file fixes from master
14:50:29  <CIA-99>libuv: Conflicts:
14:50:29  <CIA-99>libuv: src/win/pipe.c
14:50:29  <CIA-99>libuv: commit e53ab6675ba12d97ad6d93c9913a473ba5172617
14:50:29  <CIA-99>libuv: Author: Bert Belder <bertbelder@gmail.com>
14:50:29  <CIA-99>libuv: Date: Fri Mar 9 17:04:03 2012 +0100
14:51:14  * pfox___joined
15:01:11  * travis-cijoined
15:01:11  <travis-ci>[travis-ci] joyent/libuv#176 (v0.6 - cda7a28 : Bert Belder): The build is still failing.
15:01:11  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/8cbbfbe...cda7a28
15:01:11  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1025202
15:01:11  * travis-cipart
15:03:15  * k-schanged nick to k-s[AWAY]
15:03:33  <piscisaureus_>bnoordhuis: just about what we are working on
15:04:01  <bnoordhuis>piscisaureus_: you mean my world of warcraft level?
15:04:22  <bnoordhuis>i kid, i kid - real men play nethack
15:04:35  <bnoordhuis>do you want me to come to the office tomorrow?
15:05:00  <piscisaureus_>bnoordhuis: well I think it would be appreciated
15:05:17  <bnoordhuis>piscisaureus_: sure, np
15:05:40  <bnoordhuis>just make sure the fridge is stocked with something beside heineken or amstel
15:05:41  <piscisaureus_>bnoordhuis: if you can come kind of early then we can draft some slides in the morning\
15:06:05  <bnoordhuis>i'll try to be in before noon
15:06:11  <piscisaureus_>bnoordhuis: ok
15:06:16  <bnoordhuis>grolsch or hertog jan is acceptable btw
15:06:29  <piscisaureus_>bnoordhuis: I hope we can come up with something before the meeting starts
15:06:37  <piscisaureus_>at 4
15:06:47  <bnoordhuis>mwah, shouldn't be a problem, right?
15:06:59  <piscisaureus_>I don't think so either
15:07:04  <bnoordhuis>just don't expect a presentation with fade overs and other nonsense
15:07:27  <bnoordhuis>i could live with some tasteful midi music though
15:07:29  <piscisaureus_>bnoordhuis: http://groups.google.com/group/nodejs/browse_thread/thread/450530b778d9cfe4
15:07:40  <piscisaureus_>bnoordhuis: does that yield ENOTSOCK on unix too?
15:08:00  <piscisaureus_>bnoordhuis: obviously you should not bind twice but ENOTSOCK is typically a node or libuv bug
15:08:01  <bnoordhuis>piscisaureus_: no, EINVAL
15:08:09  * `3rdEdenquit (Quit: preparing for le talk)
15:09:14  <bnoordhuis>piscisaureus_: i'm not sure if it's EINVAL on all unices but it's what linux and freebsd return at least
15:09:34  <piscisaureus_>bnoordhuis: ok, I then I'll need to track down whether that is an uv-win bug
15:09:46  <piscisaureus_>I mean, EINVAL seems likely but ENOTSOCK... not so much
15:09:58  <piscisaureus_>bnoordhuis: tbh it should be EALREADY :-)
15:10:09  <pfox___>is there a policy on the max value that libuv would ever provide for suggested_size in a uv_alloc_cb
15:10:12  <pfox___>?
15:10:33  <piscisaureus_>pfox___: no policy - but it practice it never asks for more than 64k
15:10:48  <bnoordhuis>and that's unlikely to change in the near future
15:10:51  <bnoordhuis>maybe less but not more
15:11:09  <piscisaureus_>pfox___: well it is unlikely
15:11:23  <pfox___>ok. yeah, having a fun issue with ABI passing problems on 32bit loonix between rust and C
15:11:24  <piscisaureus_>pfox___: but you know, you can always give it less than what it suggests
15:11:30  <pfox___>somehow a garbage is coming across
15:11:38  <pfox___>so libuv is asking for a buf of size 12312434345
15:11:53  <piscisaureus_>pfox___: yeah that seems like a little too much
15:12:09  <piscisaureus_>pfox___: typically it would ask for 64k with a few exceptions. But never more atm.
15:12:14  <pfox___>yeah. the best part of doing this work is all the dragon nests im stumbling upon
15:12:51  <pfox___>ill probably put something in place to cap it at 64K. yet, im not enthusiastic that libuv is even getting a uv_buf_t back.
15:13:15  * pfox___restrains himself from complaining about byval returns
15:13:25  <pfox___>:)
15:13:28  <bnoordhuis>hah, what's so bad about that?
15:13:37  <pfox___>it makes interop a bitch
15:13:48  <pfox___>cue creationix's complaints about luajit integration
15:13:55  <bnoordhuis>what kind of abi does rust use?
15:14:15  <bnoordhuis>i think the x86_64 abi makes the caller alloc
15:14:27  <pfox___>well its about per-arch instructions for copying values from the C <-> rust stacks
15:14:34  <pfox___>no. not here.
15:14:39  <pfox___>C and Rust maintain different stacks
15:14:43  <bnoordhuis>ah okay
15:14:50  <pfox___>so we have to copy values across.. you can't pull that trick, here.
15:14:54  <bnoordhuis>well, you wouldn't want it easy, right?
15:14:58  <bnoordhuis>no challenge in easy
15:15:27  <pfox___>such is the price of GLORY
15:16:00  <creationix>pfox___, well, it's not a problem for me unless I want to use luajit ffi
15:16:13  <creationix>the normal C api is fine with byval
15:16:17  * pfox___nods
15:17:34  <pfox___>but, yeah. tl;dr -- this work has exposed a bunch of corner cases for moving data across the two stacks. so workarounds abound.
15:17:51  <pfox___>uv_alloc_cb is the only place that i can't really cheat, because i can't fall back on a pointer.
15:17:57  <CIA-99>node: Bert Belder reviewme * r56a8101 / (deps/uv/src/win/tcp.c deps/uv/src/win/udp.c): Windows: don't report ENOTSOCK when attempting to bind an udp handle twice - http://git.io/0_PxQg
15:18:03  <piscisaureus_>^-- bnoordhuis: review?
15:18:12  <pfox___>but it's going to be addressed soon. so no worries on your end.
15:20:09  <bnoordhuis>piscisaureus_: how does that work?
15:20:25  <piscisaureus_>bnoordhuis: the problem was this
15:20:43  <piscisaureus_>there is lazy handle creation code in uv__bind for udp
15:20:50  <piscisaureus_>bnoordhuis: but we did this
15:21:34  <piscisaureus_>SOCKET sock;
15:21:34  <piscisaureus_>if (!handle->socket) {
15:21:34  <piscisaureus_> sock = socket(...);
15:21:34  <piscisaureus_> handle->socket = sock;
15:21:34  <piscisaureus_>}
15:21:34  <piscisaureus_>bind(sock)
15:21:43  <piscisaureus_>bnoordhuis: see what happens if handle->socket is already set.
15:21:49  <bnoordhuis>oh right
15:21:57  <bnoordhuis>yes, that's an obvious bug :)
15:22:15  <bnoordhuis>with 20/20 hindsight and all that
15:22:52  <piscisaureus_>bnoordhuis: ok so, lgty?
15:23:19  <bnoordhuis>piscisaureus_: yes. but it should go into libuv
15:23:31  <bnoordhuis>or merge in node and apply to libuv
15:23:50  <piscisaureus_>bnoordhuis: also, there will be standup in 20 minutes.
15:24:05  <piscisaureus_>bnoordhuis: oh (facepalm) I though I was working in libuv, forgot I switched to node to debug this :-/
15:24:10  <piscisaureus_>of course it has to go in libuv :-)
15:24:26  <bnoordhuis>piscisaureus_: i'll be there. mees is in bed and i already had dinner
15:29:14  <CIA-99>libuv: Bert Belder master * rcda7a28 / (4 files in 2 dirs): (log message trimmed)
15:29:14  <CIA-99>libuv: Windows: backport pipe-connect-to-file fixes from master
15:29:14  <CIA-99>libuv: Conflicts:
15:29:14  <CIA-99>libuv: src/win/pipe.c
15:29:14  <CIA-99>libuv: commit e53ab6675ba12d97ad6d93c9913a473ba5172617
15:29:14  <CIA-99>libuv: Author: Bert Belder <bertbelder@gmail.com>
15:29:14  <CIA-99>libuv: Date: Fri Mar 9 17:04:03 2012 +0100
15:29:15  <CIA-99>libuv: Bert Belder master * r3506cd1 / (src/win/tcp.c src/win/udp.c): Windows: don't report ENOTSOCK when attempting to bind an udp handle twice - http://git.io/lmTmmA
15:29:16  <CIA-99>libuv: Bert Belder master * rf6df47b / (src/win/tcp.c src/win/udp.c): Merge branch 'v0.6' - http://git.io/birl1A
15:29:16  <CIA-99>libuv: Bert Belder v0.6 * r3506cd1 / (src/win/tcp.c src/win/udp.c): Windows: don't report ENOTSOCK when attempting to bind an udp handle twice - http://git.io/lmTmmA
15:30:00  * pieternjoined
15:31:01  * travis-cijoined
15:31:02  <travis-ci>[travis-ci] joyent/libuv#178 (v0.6 - 3506cd1 : Bert Belder): The build is still failing.
15:31:02  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/cda7a28...3506cd1
15:31:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1025579
15:31:02  * travis-cipart
15:31:11  * travis-cijoined
15:31:12  <travis-ci>[travis-ci] joyent/libuv#177 (master - f6df47b : Bert Belder): The build is still failing.
15:31:12  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f09f7bc...f6df47b
15:31:12  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1025573
15:31:12  * travis-cipart
15:35:23  * travis-cijoined
15:35:24  <travis-ci>[travis-ci] joyent/node#693 (reviewme - 56a8101 : Bert Belder): The build is still failing.
15:35:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/commit/56a8101
15:35:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1025468
15:35:24  * travis-cipart
15:38:56  * orlandovftwjoined
15:44:27  * bnoordhuis_joined
15:46:57  <bnoordhuis>piscisaureus_: has it started yet?
15:47:54  * philipsquit (Excess Flood)
15:49:32  * philipsjoined
15:50:21  <piscisaureus_>bnoordhuis_: it's about to.
15:50:25  * TooTallNatejoined
15:50:44  <piscisaureus_>bnoordhuis: PM
15:52:48  * orlandovftwquit (Quit: leaving)
15:53:13  * igorzijoined
15:55:41  * mmaleckichanged nick to mmalecki[away]
15:59:56  * bnoordhuis_quit (Remote host closed the connection)
16:03:27  <piscisaureus_>bnoordhuis: ok so we have the node status call
16:03:31  <igorzi>call?
16:03:37  <bnoordhuis>what? right now?
16:03:40  <piscisaureus_>isaacs isn't here yet
16:03:44  <piscisaureus_>bnoordhuis: yep
16:03:55  <bnoordhuis>dst is the bane of my existence :/
16:04:15  <piscisaureus_>igorzi: bnoordhuis: TooTallNate: indutny: so I have to reboot my computer right now.
16:04:26  <TooTallNate>are we just waiting on isaacs?
16:04:28  <piscisaureus_>I will be here in 3 minutes
16:04:29  <bnoordhuis>piscisaureus_: it's the blue button
16:04:33  <piscisaureus_>yeah Isaacs should be there
16:05:20  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
16:07:55  * piscisaureus_joined
16:08:25  <piscisaureus_>ok, I'm back
16:08:30  <piscisaureus_>but isaac not here yet?
16:08:33  <igorzi>nope
16:09:06  <TooTallNate>negatory
16:09:13  * isaacsjoined
16:09:25  <piscisaureus_>let's wait until uu:`15
16:09:35  <piscisaureus_>otherwise we'll have to do without him
16:10:27  <bnoordhuis>isaacs: call
16:11:19  <TooTallNate>I'm "TooTallNate" on skype btw
16:11:42  <piscisaureus_>indutny: fedor, what's your skype handle?
16:12:32  <bnoordhuis>piscisaureus_: crazyfedor1987
16:13:02  <piscisaureus_>Ok so there are 3 Fedor Indutny s in skype
16:13:11  <bnoordhuis>fedor's fedor.indutny
16:13:13  <piscisaureus_>and they all live in Omsk :-(
16:13:33  * dshaw_joined
16:14:51  <isaacs>calling, one sec
16:16:58  <piscisaureus_>bnoordhuis: hey
16:17:10  <piscisaureus_>bnoordhuis: pick up
16:22:42  <indutny>bnoordhuis: heya
16:22:55  <bnoordhuis>indutny: hoya, one sec - we'll add you to the call
16:24:51  * dapjoined
16:44:55  * pieternquit (Quit: pietern)
16:59:50  <bnoordhuis>piscisaureus_, igorzi: https://github.com/joyent/node/blob/3e88572/src/node_file.cc#L683
17:00:18  <bnoordhuis>it uses Int32Value() if !defined(_LARGEFILE_SOURCE)
17:00:36  <piscisaureus_>bnoordhuis: so do we compile with LARGEFILE_SOURCE?
17:01:14  <bnoordhuis>piscisaureus_: only on unices
17:01:23  <bnoordhuis>https://github.com/joyent/node/commit/a3e3ad40 <- that's the commit that introduced it btw
17:01:25  <piscisaureus_>bnoordhuis: also, I think that there should be an assert there: assert(sizeof(off_t) >= 64)
17:01:36  <piscisaureus_>bnoordhuis: so we actually catch it if the platform does not support that flag
17:01:39  <bnoordhuis>piscisaureus_: a static assert maybe
17:01:52  <piscisaureus_>oh, right, this is c++ :-)
17:02:09  <bnoordhuis>you can do static asserts in c too
17:02:43  <piscisaureus_>bnoordhuis: don't tell me about those crazy linux kernel macros.
17:02:46  <piscisaureus_>i''ve seen those
17:02:52  <bnoordhuis>awesome, right?
17:02:59  <piscisaureus_>kinda rad yeah
17:03:16  <bnoordhuis>it's a gcc feature but i think it's actually iso-compliant c
17:03:22  <piscisaureus_>isaacs: so one problem that you do not address in your gist is that w
17:03:25  <igorzi>bnoordhuis piscisaureus_: ok, so we'll need to compile with LARGEFILE_SOURCE on windows too then (after adding read64+write64 to libuv)
17:03:41  <piscisaureus_>or use _WIN32 :-)
17:03:44  <bnoordhuis>igorzi: actually, i think that commit should be backed out / amended
17:03:52  <isaacs>"is that w"?
17:04:03  <isaacs>piscisaureus_: was that truncated?
17:04:04  <piscisaureus_>isaacs: sorry, hit enter too early
17:04:07  <isaacs>oh, ok
17:04:25  <piscisaureus_>isaacs: *is that there is no distinction between ipc and non-ipc pipes.
17:04:42  <piscisaureus_>isaacs: in fact, cluster uses ['ipc', 'stream', 'stream']
17:04:52  <isaacs>hm, right.
17:05:07  <isaacs>so let's add 'ipc' which is a createPipe({ipc: true}) or something.
17:05:16  <isaacs>but otherwise, have it be a property of the pipe handle.
17:05:20  <piscisaureus_>isaacs: also I think it would be nicer to just use 'pipe' instead of 'stream'
17:05:45  * isaacspaints his bikeshed in piscisaureus_'s favorite color.
17:05:48  <isaacs>sure
17:05:48  <piscisaureus_>and don't do any magic like "read-only if 0, write-only if 1"
17:05:57  <isaacs>well... we do this now.
17:05:58  <piscisaureus_>isaacs: yeah, sorry about my bikeshedding
17:06:09  <isaacs>hahahah, it's fine, that's what this exercise is for.
17:06:10  <piscisaureus_>isaacs: just make them all duplex. Who cares.
17:06:33  <isaacs>yeah, i guess we just set this in the JS layer now anyway
17:06:52  <isaacs>ok, sure, let's remove that.
17:06:53  <piscisaureus_>or, whatever, if people *really really* want a half duplex stream we can have that as an option for createPipe
17:06:57  <isaacs>sure
17:07:07  <piscisaureus_>but I don't think it ever matters
17:07:21  <isaacs>createPipe({ipc:<boolean, def=false>, readable:<boolean, def=true>, writable:<boolean, def=true>}
17:07:22  <igorzi>bnoordhuis: back out https://github.com/joyent/node/commit/a3e3ad40 ? and just always use IntegerValue instead of Int32Value?
17:11:17  <piscisaureus_>isaacs: yeah that would be nice
17:11:57  * skomskiquit (Remote host closed the connection)
17:11:59  <isaacs>piscisaureus_: so, 'ipc' means we write JSON messages to that channel, or receive them, or both/duplex?
17:12:16  <piscisaureus_>isaacs: no ipc is a more low level thing
17:12:25  <piscisaureus_>isaacs: it means that you can send FDs over them
17:12:29  <piscisaureus_>or whatever, handles
17:12:32  <isaacs>sure.
17:12:40  <isaacs>right, ok. that makes sense.
17:12:48  <bnoordhuis>igorzi: yes. i shouldn't have said "back out", always use IntegerValue() is what i meant
17:13:09  <isaacs>but they're still otherwise just normal duplex stream objects.
17:13:11  <isaacs>piscisaureus_: ^
17:13:18  <piscisaureus_>isaacs: yeah
17:13:18  <igorzi>bnoordhuis: k
17:13:35  <piscisaureus_>igorzi: do we support sending handles in both ways now
17:13:37  <piscisaureus_>?
17:14:28  <igorzi>piscisaureus_: yeah
17:14:53  <igorzi>(you mean from child to parent?)
17:14:57  <piscisaureus_>igorzi: so both ends of the ipc channel have a handle to the other side
17:14:59  <piscisaureus_>igorzi: yeah
17:15:15  <igorzi>piscisaureus_: yeah.. we have a test in libuv that does that
17:15:21  <piscisaureus_>igorzi: ah, cool
17:15:25  <piscisaureus_>igorzi: i didn't even know...
17:15:57  <piscisaureus_>this has mostly been your performance
17:16:17  <isaacs>i see, yeah, we just communicate over fd=0 with child_process.fork()
17:23:08  * mikealjoined
17:24:48  <bnoordhuis>piscisaureus_: does this work in windows? https://gist.github.com/ddfdd701f172dd8af63f
17:24:53  <bnoordhuis>or rather, with msvc?
17:26:50  * pieternjoined
17:31:36  <piscisaureus_>bnoordhuis: I have no idea.
17:31:50  * TooTallNatequit (Quit: Leaving...)
17:34:04  <isaacs>piscisaureus_: edited with your suggestions, thanks: https://gist.github.com/2294039
17:35:12  <piscisaureus_>bnoordhuis: yeah, works. But msvc just has static_assert builtin
17:38:20  <bnoordhuis>okay, noted
17:38:47  * dapquit (Quit: Leaving.)
17:39:42  <piscisaureus_>isaacs: so that gist doesn't document createPipe yet. Also be aware that if you would actually create a pipe that way you have to close (.destroy) one end in the parent process afterwards.
17:39:51  <piscisaureus_>isaacs: but yeah, that looks good to me.
17:40:11  <isaacs>piscisaureus_: line 67-72
17:40:22  <isaacs>piscisaureus_: not super well documented, i agree.
17:40:36  <piscisaureus_>isaacs: ah well of course :/
17:40:49  <isaacs>it's more that the Pipe object is not well documented.
17:40:59  <piscisaureus_>yeah exactly
17:41:04  <isaacs>but i think we ought to promote Pipe to a first-class citizen.
17:41:13  <piscisaureus_>it would be interesting to see what createPipe actually returns
17:41:21  <isaacs>it should return a Pipe object, like it does now.
17:41:33  <isaacs>just, instead of new Pipe(ipc), it would be new Pipe(options)
17:41:46  <piscisaureus_>doesn't it return a pair PipeHandle objects
17:42:30  <piscisaureus_>isaacs: so you would have to
17:42:31  <piscisaureus_>var ends = createPipe();
17:42:31  <piscisaureus_>var parentSocket = net.createConnection({handle: ends[0]})'
17:42:40  <piscisaureus_>isaacs: maybe it would be better to return just a net.Socket
17:43:03  <piscisaureus_>isaacs: the only downside is that by default net.Socket starts reading immediately
17:43:08  <indutny>bnoordhuis: hey! please don't forget to ping once you'll finish that handle refactor
17:43:24  <indutny>bnoordhuis: and if you need any help on that - feel free to ask me, or elevate some tasks to me
17:43:33  <piscisaureus_>so that means that if the user forgets to close the child end immediately after spawn, data would be lost.
17:43:37  <isaacs>piscisaureus_: i'm assuming here that you should not do *anything* with the pipe, probably, except pass it to a child process
17:44:20  * k-s[AWAY]changed nick to k-s
17:44:25  <piscisaureus_>isaacs: ah, right, so, so after you spawned the child process the parent end would be exposed as '.stdin'
17:44:50  <piscisaureus_>isaacs: or - whatever - as stdio[2]
17:45:02  <piscisaureus_>yeah that makes sense
17:46:07  <indutny>bnoordhuis: ok?
17:46:18  <isaacs>piscisaureus_: right.
17:46:30  <isaacs>piscisaureus_: we can work out the implementation details as we build it, and maybe expose some of them.
17:47:15  <isaacs>piscisaureus_: so the high-level thing should Just Work, and then createPipe() is like one level lower, and also pretty simple. anything below that involves RTFC-ing, probably
17:53:45  <isaacs>piscisaureus_: How should it expose child.stdio[n] if you've passed in a server or socket to it?
17:54:12  <isaacs>piscisaureus_: i'm tempted to say anything other than 'pipe' just puts null in the array, and 'pipe' puts a Stream object there for you to consume.
17:58:27  <piscisaureus_>isaacs: so if you want to create a pipe, it's gotta give you two ends
17:59:18  * brsonjoined
18:05:30  <piscisaureus_>isaacs: so the question is how to turn the parent end into a proper net.Socket
18:07:00  <isaacs>piscisaureus_: hm.
18:07:34  <isaacs>piscisaureus_: why wouldn't you just pass the net.Socket into the child, and have child_process.spawn() wrap it in a Pipe?
18:07:39  <isaacs>piscisaureus_: ie, go the other way around.
18:18:31  <piscisaureus_>isaacs: no idea, I think it's fine
18:27:15  <isaacs>piscisaureus_: ok, so, a Pipe has two ends. passing a socket makes spawn() do the createPipe(), setting the handle as the "this side"
18:27:37  <isaacs>piscisaureus_: if you createPipe, and then want to set up a server using one of the handles, then that's fine, but you're now in RTFC territory.
18:27:42  * brsonquit (Quit: leaving)
18:27:51  * brsonjoined
18:37:55  <piscisaureus_>isaacs: you would not be able to set up one side as a server
18:38:17  <piscisaureus_>isaacs: createPipe gives a pair of connected sockets. They cannot double as servers.
18:38:40  * mikealquit (Quit: Leaving.)
18:38:52  <isaacs>piscisaureus_: right. but can you pass one of them in, so that it serves as the filedes to dup2?
18:39:48  <piscisaureus_>isaacs: yeah so the real question is: what does createPipe actually return?
18:39:58  <piscisaureus_>Handles? Or Streams?
18:40:11  <piscisaureus_>or something opaque that can *only* be used by spawn?
18:40:29  <isaacs>what about something not-so-opaque that can primarily be used by spawn?
18:41:44  * mikealjoined
18:41:47  * TooTallNatejoined
18:41:47  <isaacs>piscisaureus_: so, i think what you really want is a Stream, with a handle member.
18:41:53  <isaacs>the handle is used by spawn
18:41:58  <isaacs>but the stream emits data
18:42:09  <piscisaureus_>isaacs: yeah, that's not so nice
18:42:18  <isaacs>because you do something like: var p = createPipe(); spawn(..., { stdio: [p, ...]}), right?
18:42:32  <isaacs>then i want to do stuff on "p", and have it show up on stdin in the child
18:42:43  <piscisaureus_>isaacs: indeed
18:43:09  <isaacs>p.on("data", (d) => console.log("child proc wrote: ", d))
18:59:04  * dshaw_quit (Quit: Leaving.)
19:02:29  <piscisaureus_>isaacs: ah right now I get it.
19:03:16  <piscisaureus_>isaacs: so you want to create a stream that silently carries the other end, and spawn() can get it out.
19:03:29  <isaacs>piscisaureus_: sort of like: p = createPipe(); c = spawn(..., {stdio:[p]}); p === c.stdin
19:03:39  <isaacs>right
19:04:22  <isaacs>piscisaureus_: could even be a hidden field or something, but i generally prefer to not do under-the-table deals like that with v8
19:04:50  <piscisaureus_>isaacs: actually, hmm, that makes createPipe only useful for spawn right?
19:05:00  <piscisaureus_>isaacs: oh wait you might want to send one end over an ipc channel
19:05:10  <piscisaureus_>I dont think we can do that right now btw, at least not on windows
19:07:27  <piscisaureus_>isaacs: so, i don't know, but what about
19:07:27  <piscisaureus_>var [localStream, remoteStream] = createPipe({ paused: true });
19:07:56  <piscisaureus_>c = spawn(..., {stdio: [ 2: remoteStream ]});
19:08:03  <piscisaureus_>remoteStream.destrouy();
19:08:06  <piscisaureus_>localStream.resume()
19:08:29  <piscisaureus_>isaacs: that's kind of tedious but at least it matches the conceptual model that people that want to use this already have
19:12:55  * bradleymeckjoined
19:16:44  <bradleymeck>heya, is there any recent domain's work for node I can look at?
19:17:15  <TooTallNate>is there any reason that OS X 10.5 would be unsupported by node/libuv?
19:17:32  <TooTallNate>first, i was getting an "unknown load command" error
19:17:46  <TooTallNate>then i recompiled with -mmacosx-version-min=10.5
19:17:54  <TooTallNate>and now I'm getting just a "Bus error" when launching
19:19:05  <tjfontaine>TooTallNate: bus error usually means a segfault, is there a core to inspect?
19:19:34  * mikealquit (Quit: Leaving.)
19:19:35  <TooTallNate>tjfontaine: do i have to set ulimit for that or something?
19:19:49  <tjfontaine>ulimit -c unlimited may help
19:20:29  <tjfontaine>TooTallNate: you're compiling on !10.5 and then deploying to 10.5?
19:23:01  <TooTallNate>tjfontaine: indeed
19:23:22  <TooTallNate>tjfontaine: also, this machine doesn't have gdb or anything on it; do i need that for a core dump?
19:23:23  <tjfontaine>TooTallNate: are you doing the lipo stuff as well?
19:23:29  <TooTallNate>cause i don't think it's creating one
19:23:34  <TooTallNate>tjfontaine: no, just i386
19:24:04  <tjfontaine>hrm and it's targetted for i386 and not x86_64? because sigbus can also mean arch mismatch stuff
19:24:17  <tjfontaine>and no gdb isnt' needed to generate the core
19:24:32  <TooTallNate>tjfontaine: well the bin works on lion machines. i don't have snow leopard to test on
19:25:46  <TooTallNate>well, the 'host_arch' is set to x64 when compiling, but the target_arch is ia32. maybe that's a problem
19:25:54  <tjfontaine>TooTallNate: well Lion defaults to 64bit on hardware that supports it, and < Lion you had to hold 64 down while booting to get 64bit support
19:25:55  <TooTallNate>i'm recompiling now with both values set to ia32
19:26:01  <tjfontaine>ok
19:26:52  <TooTallNate>is there a way to force the core to be dumped?
19:27:45  <tjfontaine>TooTallNate: not if the error is happening before the binary can even be executed, what's file report about the binary?
19:28:54  <isaacs>piscisaureus_: that's super tedious, you're right.
19:30:16  <isaacs>bradleymeck: not yet.
19:30:48  <isaacs>bradleymeck: i've got a little bit of a hacky thing started that I did on the plane. it's paused at the moment, i'll be resuming it soon.
19:31:06  <bradleymeck>k, cool.
19:31:27  <isaacs>piscisaureus_: let's not send Pipe objects over the ipc channel if we can't make it work on Windows.
19:31:44  <isaacs>piscisaureus_: though, we should make it work, on widnows and nix
19:31:54  <piscisaureus_>isaacs: well we can *make* it work
19:32:09  <isaacs>piscisaureus_: it's software, right!?
19:32:12  <piscisaureus_>isaacs: I think ben added support for that for unix already, in libuv
19:32:18  <isaacs>piscisaureus_: kewl
19:32:35  <TooTallNate>tjfontaine: ./out/Release/node: Mach-O executable i386
19:32:36  <isaacs>piscisaureus_: var [local,remote] = createPipe() is way too tedious.
19:32:37  <piscisaureus_>isaacs: well when you are dealing with an OS interface it is sometimes a little more difficult.
19:32:52  <piscisaureus_>isaacs: I don't agree, actually
19:32:53  <isaacs>piscisaureus_: true that
19:33:17  <piscisaureus_>isaacs: I would like to make graceful close work for pipes on windows, but unfortunately there is no way it'll ever work :-/
19:33:17  <isaacs>piscisaureus_: what about p = createPipe(), and then the remote is p.remote
19:33:26  <piscisaureus_>isaacs: yeah that we could do.
19:33:45  <isaacs>piscisaureus_: then spawn() could check to see if it's a Pipe, and has a remote, and then do the Right Thing
19:33:48  <piscisaureus_>isaacs: so p.remote is a "handle" and p.local is a "stream" ?
19:33:55  <isaacs>piscisaureus_: p is the "stream"
19:33:58  <tjfontaine>TooTallNate: quite interesting, and what about the static v8 that it's linked against?
19:33:59  <piscisaureus_>ah, right
19:34:05  <piscisaureus_>isaacs: lemme think about that.
19:34:14  <piscisaureus_>isaacs: I think that would be agreeable to me
19:34:18  <piscisaureus_>I have to run now, isaacs
19:34:22  <piscisaureus_>ttyl
19:34:23  <isaacs>piscisaureus_: ok. enjoy your run :)
19:34:42  <piscisaureus_>isaacs: I actually have to run :-)
19:34:53  <piscisaureus_>isaacs: but I was just using that in a proverbial sense like you always do
19:35:00  <piscisaureus_>anyway, bye
19:35:06  * dylukesjoined
19:38:05  * txdv_joined
19:38:50  * txdvquit (Ping timeout: 260 seconds)
19:40:15  * piscisaureus_quit (Ping timeout: 276 seconds)
19:47:26  * txdvjoined
19:47:46  * txdv_quit (Ping timeout: 246 seconds)
19:59:44  * perezdjoined
20:06:22  * mikealjoined
20:08:14  * orlandovftwjoined
20:14:46  * mrb_bkjoined
20:35:19  * piscisaureus_joined
20:36:49  * mikealquit (Quit: Leaving.)
20:48:13  * mikealjoined
21:00:53  * bradleymeckquit (Quit: bradleymeck)
21:13:40  * k-schanged nick to k-s[AWAY]
21:14:37  * dapjoined
21:20:01  * pfox___quit (Ping timeout: 265 seconds)
21:26:34  <TooTallNate>tjfontaine: i got gdb installed on that machine
21:26:36  <TooTallNate>tjfontaine: https://gist.github.com/2314262
21:27:02  <TooTallNate>seems like V8
21:27:08  <TooTallNate>bnoordhuis: ^ any ideas there?
21:33:47  * rendarquit
21:34:16  * bradleymeckjoined
21:59:01  * pfox___joined
22:01:36  * bradleymeckquit (Quit: bradleymeck)
22:16:31  * pfox___quit (Ping timeout: 246 seconds)
22:18:27  * pfox___joined
22:25:21  * pfox___quit (Ping timeout: 276 seconds)
22:26:32  <bnoordhuis>TooTallNate: can you gist the output of `bt full`?
22:27:58  <TooTallNate>bnoordhuis: sure one sec; recompiling as a debug build
22:28:16  <TooTallNate>bnoordhuis: also, using a cross-compiled node from a Lion install, i'm getting Bus Error from uv_exepath()
22:28:31  <TooTallNate>(that's different that the build in the gist above)
22:29:34  <bnoordhuis>only when cross-compiled?
22:29:45  <bnoordhuis>i.e. a native build doesn't have that issue?
22:30:08  <TooTallNate>compiled on 10.5 i get the Bus Error from V8, using one built on Lion I get a Bus Error from uv_exepath()
22:31:09  <bnoordhuis>TooTallNate: libuv on os x calls _NSGetExecutablePath() which is kind of undocumented
22:31:21  <bnoordhuis>that's probably why cross-compiling doesn't work
22:40:09  * sh1mmerjoined
22:43:40  <TooTallNate>ughh... debug build takes forever
22:45:05  <bnoordhuis>yeah... you can speed it up with `make -j <num-cores>`
22:45:19  <bnoordhuis>assuming that macbook has more than one
22:48:59  <TooTallNate>bnoordhuis: here's the one compiled locally https://gist.github.com/1174d72dd705c671d4aa
22:49:25  <TooTallNate>bnoordhuis: on interesting, i used g++-4.2 that time
22:49:34  <TooTallNate>and now am getting the same error as the cross-compiled one
22:50:15  <tjfontaine>right as depending on the version of xcode, clang wasn't being distributed yet, I think llvm-gcc was though
22:50:40  <tjfontaine>TooTallNate: so you're not gettin gthe uv_exepath error anymore?
22:50:42  <TooTallNate>tjfontaine: this machine uses gnu gcc, but 4.0 by default
22:50:59  <TooTallNate>tjfontaine: no, now I *am* getting that error, on both builds
22:51:03  <tjfontaine>ok
22:51:25  <bnoordhuis>TooTallNate: it's a bug in how libuv calls realpath()
22:51:42  <TooTallNate>now we're gettin somewhere :)
22:51:43  <bnoordhuis>we pass NULL as the second argument which works on most all platforms
22:52:07  <bnoordhuis>but the actual behavior is implementation defined, i.e. not-good territory
22:52:07  <tjfontaine>char *realpath(const char * , char * ) __asm("_" "realpath" "$DARWIN_EXTSN"); cute
22:53:21  <TooTallNate>bnoordhuis: so we should be passing a buffer in there instead?
22:53:25  <bnoordhuis>TooTallNate: https://github.com/joyent/libuv/commit/f6c8e78d <- that's the commit that introduced it
22:53:26  <bnoordhuis>yes
22:53:42  <tjfontaine>Setting the _DARWIN_BETTER_REALPATH macro selects the extension variant of realpath(), which uses the $DARWIN_EXTSN suffix. The extended version uses a fast shortcut to determine the current working directory, but this shortcut does not fail if the parent directories are not readable, as is dictated by the standards.
22:54:05  * sh1mmerquit (Quit: sh1mmer)
22:54:22  <tjfontaine>man, platform indepence is hard
22:54:30  <bnoordhuis>oi, tell me about it
22:54:48  <tjfontaine>there's some missing letters in my sentence, but ya
22:55:04  <bnoordhuis>TooTallNate: i suppose i'll revert that commit
22:55:53  <tjfontaine>"(it must refer to a buffer capable of storing at least PATH_MAX characters)" according to man3
22:56:00  <TooTallNate>bnoordhuis: ok cool. how did it leak anyways?
22:56:20  <tjfontaine>wait, then it says "As a permitted extension to the standard, if resolved_name is NULL, memory is allocated for the result-
22:56:24  <tjfontaine> ing absolute pathname, and is returned by realpath()."
22:58:32  <TooTallNate>tjfontaine: i guess Leopard isn't "extended" :p
22:58:52  <bnoordhuis>tjfontaine: yeah, it probably adheres to an older standard
22:58:54  <bnoordhuis>let me dig it up
22:59:11  <bnoordhuis>If resolved_name is a null pointer, the behavior of realpath() is implementation-defined.
22:59:15  <bnoordhuis>http://pubs.opengroup.org/onlinepubs/009604499/functions/realpath.html
22:59:53  <bnoordhuis>contrast with http://pubs.opengroup.org/onlinepubs/9699919799/functions/realpath.html -> If the resolved_name argument is a null pointer, the pointer returned by realpath() can be passed to free().
23:00:13  <tjfontaine>indeed
23:00:38  <tjfontaine>a few years can make a big difference
23:00:49  <bnoordhuis>yep
23:01:00  <bnoordhuis>PATH_MAX is special wtf unto itself btw
23:01:32  <tjfontaine>in my head I just say 255 and curse those who betray me
23:01:43  <bnoordhuis>haha
23:02:14  <bnoordhuis>TooTallNate: actually, i don't see the leak either
23:02:48  <tjfontaine>fullpath should equal path, if I read it right
23:02:56  <bnoordhuis>yep
23:03:58  <CIA-99>libuv: Ben Noordhuis master * r637d976 / src/unix/darwin.c :
23:03:58  <CIA-99>libuv: Revert "Fix memory leak in uv_exepath() on OSX."
23:03:58  <CIA-99>libuv: This reverts commit f6c8e78db973a0f57424dba74c97fdd4d2f910f8.
23:03:58  <CIA-99>libuv: realpath() on OS X 10.5 crashes if resolved_path == NULL. - http://git.io/sPRKHw
23:04:21  <isaacs>bnoordhuis: that's why we implement realpath in JavaScript in node.
23:05:07  <piscisaureus_>umm wut
23:05:35  <piscisaureus_>bnoordhuis: so, iow, realpath() can crash at any time?
23:05:55  * travis-cijoined
23:05:56  <travis-ci>[travis-ci] joyent/libuv#179 (master - 637d976 : Ben Noordhuis): The build is still failing.
23:05:56  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/f6df47b...637d976
23:05:56  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1028337
23:05:56  * travis-cipart
23:05:56  <bnoordhuis>piscisaureus_: only if resolved_name==NULL and your system is old
23:06:08  <tjfontaine>where 2007 is old
23:06:43  <piscisaureus_>bnoordhuis: I don't see the difference
23:07:02  <piscisaureus_>ah, ok
23:07:20  <piscisaureus_>bnoordhuis: it is not impossible to plug the leak right?
23:07:34  <bnoordhuis>piscisaureus_: actually, i don't see a memory leak
23:07:45  <bnoordhuis>i merged that commit as part of a bigger PR
23:07:51  <piscisaureus_>no, me neither actually
23:07:57  <piscisaureus_>let me take a look again :-)
23:09:51  <piscisaureus_>bnoordhuis: I think the reader was just confused because we free(path) here and free(fullpath) there
23:10:02  <bnoordhuis>piscisaureus_: yes, that seems likely
23:10:04  <tjfontaine>I agree, that's what I was going to say
23:12:46  * eli-away_joined
23:12:53  <bnoordhuis>TooTallNate: are you still seeing that segfault in v8?
23:14:45  * eli-awayquit (Ping timeout: 276 seconds)
23:16:57  <igorzi>https://github.com/igorzi/libuv/commit/8142391950f274b26f7e06bc734606cadbb8eacc
23:17:00  <igorzi>piscisaureus_: ^
23:17:09  <igorzi>and https://github.com/igorzi/node/commit/acef98c31c65a9803d37817ccf763eaa1e42d49f
23:17:14  <igorzi>piscisaureus_: ^
23:17:22  <igorzi>and bnoordhuis ^
23:18:27  <igorzi>also, piscisaureus_ & bnoordhuis : how do we go about implementing uv_fs_*64 on unix?
23:19:23  <bnoordhuis>igorzi: as an alias for uv_fs_(read|write)
23:21:03  <igorzi>bnoordhuis: ok
23:21:25  <TooTallNate>bnoordhuis: no, that went away by using gcc 4.2 instead of 4.0
23:22:10  <piscisaureus_>igorzi: st_atime, wow, now that *is* hacky
23:22:24  <bnoordhuis>TooTallNate: curious. then again, the optimizer in 4.0 was rife with bugs. i could tell stories!
23:23:39  <igorzi>piscisaureus_: it's the first field :)
23:24:27  <igorzi>piscisaureus_: i was going to put a union there, but then again.. this stuff will change in v0.8, so probably no point in doing that
23:25:26  <CIA-99>libuv: saghul master * re3468e9 / src/unix/internal.h : unix: add missing function declaration - http://git.io/5g69dA
23:25:27  <CIA-99>libuv: Ben Noordhuis master * r8e6f332 / src/unix/loop.c : unix: fix compiler warning, #include <unistd.h> - http://git.io/CKRWDw
23:25:54  <piscisaureus_>igorzo: ok, fair enough. We have to be serious about getting this in 0.8, then.
23:25:54  <piscisaureus_>igorzi: return x == static_cast<double>(static_cast<int64_t>(x)); <-- I am not convinced. Does that detect double values outside of the "integer precision" range?
23:25:54  <piscisaureus_>igorzi: I think that it would be better to do something like `return x + 13 == static_cast<double>(static_cast<int64_t>(x) + 13);
23:26:19  <piscisaureus_>maybe but braces around the (x + 13)
23:27:01  <bnoordhuis>not necessary, == has lower precedence than x + 13
23:27:04  <igorzi>piscisaureus_: that's not new code
23:27:15  <piscisaureus_>igorzi: ok
23:27:19  <piscisaureus_>bnoordhuis: I am not convinced
23:27:27  * travis-cijoined
23:27:27  <travis-ci>[travis-ci] joyent/libuv#180 (master - 8e6f332 : Ben Noordhuis): The build is still failing.
23:27:27  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/637d976...8e6f332
23:27:27  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1028424
23:27:27  * travis-cipart
23:27:27  * piscisaureus_fires up git blame
23:28:04  <bnoordhuis>piscisaureus_: convinced about what?
23:28:13  <piscisaureus_>bnoordhuis: return x == static_cast<double>(static_cast<int64_t>(x)); <-- I am not convinced. Does that detect double values outside of the "integer precision" range?
23:28:33  <bnoordhuis>piscisaureus_: oh, like that. no, it does not.
23:28:42  <bnoordhuis>well
23:29:18  <bnoordhuis>it's complicated but it's essentially implementation defined
23:30:14  <bnoordhuis>it's probably easier / better to add a 0 >= x >= 2^53-1 check
23:31:15  <piscisaureus_>bnoordhuis: well, then you suddenly make yourself dependent on the platform-specific double implementation
23:31:35  <bnoordhuis>piscisaureus_: no. double is guaranteed to be 64 bits
23:31:45  <piscisaureus_>bnoordhuis: with exponent 2 ?
23:31:48  <bnoordhuis>i should say 'at least 64 bits' :)
23:31:51  <piscisaureus_>er, with root 2 ?
23:32:01  <bnoordhuis>hmm
23:32:07  * bnoordhuisdigs up his copy of the iso standard
23:32:28  <TooTallNate>so this is pretty minor (since no users have complained that I know of) but our .pkg's of node don't work on Leopard
23:32:29  <bnoordhuis>you would normally use <float.h> if you really care about precision
23:32:31  <TooTallNate>we need this: https://github.com/TooTallNate/node/compare/10.5
23:32:57  <piscisaureus_>bnoordhuis: although admittedly, if the double would be bigger than 64 bits, my test would fail to detect the imprecision
23:33:00  <bnoordhuis>TooTallNate: does it break 10.6 or newer?
23:33:22  <bnoordhuis>if not, i'm fine with it
23:33:33  <TooTallNate>nope, maybe a bigger bin. not exactly sure what it chages
23:33:35  <TooTallNate>changes
23:35:35  <tjfontaine>just changes the sdk it links with I'm sure
23:36:03  <piscisaureus_>igorzi: lgtm
23:36:38  <igorzi>piscisaureus_: thx
23:37:06  <igorzi>bnoordhuis: where would be a good place to alias uv_fs_*64 functions in uv-unix?
23:37:14  <bnoordhuis>igorzi: question: why int64_t and not uint64_t?
23:37:22  <bnoordhuis>igorzi: src/unix/fs.c
23:37:47  <bnoordhuis>i can write the patch for it if you want, it's all of five lines of code
23:37:58  <bnoordhuis>(but still +1 commit for me!)
23:40:10  <igorzi>bnoordhuis: off_t is signed int.. so i thought we should go with int64_t
23:40:28  <igorzi>bnoordhuis: but yeah, i guess we could just go with uint64_t instead
23:40:51  <igorzi>bnoordhuis: yep, please create the patch if you're up for it
23:41:33  <bnoordhuis>oh, you're right. it's a signed long long
23:42:14  <bnoordhuis>well, int64_t it is then
23:42:43  <igorzi>bnoordhuis: ok, landing. bnoordhuis: pls land your patch for uv-unix
23:42:49  <TooTallNate>bnoordhuis: so +1 on the 10.5 change?
23:42:54  <bnoordhuis>TooTallNate: yep
23:42:56  <piscisaureus_>bnoordhuis: of course, since seek() also can work with negative values
23:43:11  <CIA-99>libuv: Igor Zinkovsky v0.6 * rea50126 / (include/uv.h src/win/fs.c test/test-fs.c): add 64bit offset fs functions - http://git.io/h-bFfQ
23:43:20  <bnoordhuis>piscisaureus_: yes, it's logical in retrospect
23:43:42  <CIA-99>node: Nathan Rajlich master * rb6d6a54 / common.gypi : build: target OSX 10.5 when building on darwin - http://git.io/E_vcOA
23:44:05  * travis-cijoined
23:44:05  <travis-ci>[travis-ci] joyent/libuv#181 (v0.6 - ea50126 : Igor Zinkovsky): The build is still failing.
23:44:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3506cd1...ea50126
23:44:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1028514
23:44:05  * travis-cipart
23:44:41  <CIA-99>node: Zachary Scott master * rd73b257 / lib/cluster.js : docs: grammar and spelling on lib/cluster.js - http://git.io/iEVKng
23:45:09  <piscisaureus_>bnoordhuis: does unix have something like funlink ?
23:45:17  <piscisaureus_>bnoordhuis: like, unlink an open file?
23:45:30  <piscisaureus_>(I like the name "funlink" :-) )
23:49:05  <CIA-99>libuv: Ben Noordhuis v0.6 * rd68b3d9 / src/unix/fs.c : unix: add uv_fs_read64, uv_fs_write64 and uv_fs_ftruncate64 - http://git.io/GVhV9w
23:49:43  <bnoordhuis>piscisaureus_: not quite. unlinkat() is the nearest thing
23:49:52  <piscisaureus_>hmm
23:50:36  <bnoordhuis>piscisaureus_: why do you ask?
23:50:45  <piscisaureus_>bnoordhuis: just curious
23:50:56  * travis-cijoined
23:50:56  <travis-ci>[travis-ci] joyent/libuv#182 (v0.6 - d68b3d9 : Ben Noordhuis): The build is still failing.
23:50:56  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/ea50126...d68b3d9
23:50:56  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1028559
23:50:56  * travis-cipart
23:51:26  <piscisaureus_>also, I am playing browserquest
23:51:35  <bnoordhuis>hah
23:51:38  <bnoordhuis>how do you like it?
23:52:25  * eli-away_quit (Remote host closed the connection)
23:53:33  * dylukesquit (Quit: Computer has gone to sleep.)
23:54:13  <piscisaureus_>better than I expected
23:54:51  <piscisaureus_>purely professional interest, of course
23:55:06  <bnoordhuis>understood
23:55:12  <TooTallNate>bnoordhuis: thanks again, that fix made Leopard all good again :)
23:55:17  <bnoordhuis>i submitted a pull request to fix some bugs
23:55:25  <bnoordhuis>but i think mozilla already abandoned it
23:55:31  <bnoordhuis>TooTallNate: good :)
23:56:02  <piscisaureus_>why?
23:56:04  <piscisaureus_>it still works
23:56:36  <bnoordhuis>piscisaureus_: not if you try to start your own server
23:56:56  <bnoordhuis>piscisaureus_: https://github.com/mozilla/BrowserQuest/issues/created_by/bnoordhuis?sort=created&direction=desc&state=open&page=1
23:57:32  * travis-cijoined
23:57:32  <travis-ci>[travis-ci] joyent/node#694 (master - b6d6a54 : Nathan Rajlich): The build is still failing.
23:57:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/3e88572...b6d6a54
23:57:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1028523
23:57:32  * travis-cipart
23:57:58  <bnoordhuis>https://github.com/joyent/node/issues/3051 <- windows guys?
23:58:26  <TooTallNate>wow, only 1 failing test :)
23:58:31  <TooTallNate>and it's that 1 sketchy one :)
23:59:20  * dylukesjoined
23:59:25  * dapquit (Quit: Leaving.)
23:59:53  * travis-cijoined
23:59:53  <travis-ci>[travis-ci] joyent/node#695 (master - d73b257 : Zachary Scott): The build is still failing.
23:59:53  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b6d6a54...d73b257
23:59:53  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/1028529
23:59:53  * travis-cipart