00:10:49  <piscisaureus_>woah, cconf! philips++ :-)
00:11:41  <piscisaureus_>philips: who is backing this?
00:12:30  <dylukes>Why are uv_tcp_connect and uv_tcp_connect6 distinct?
00:14:04  <piscisaureus_>dylukes: *shrug* they just are. It's fallout from the fact that we pass sockaddr_in[6] by value.
00:14:20  <dylukes>>_>. That was smart.
00:14:23  <piscisaureus_>it should probably be changed at some point (we take patches)
00:14:35  <dylukes>I'll just switch over res->ai_family for the moment.
00:14:56  <piscisaureus_>dylukes: it's not as if it is really hard to switch between the two
00:15:01  <piscisaureus_>so yeah
00:15:05  <piscisaureus_>that'll do
00:15:26  <dylukes>Hm, it's not shown in the docs... but they return an int...
00:15:42  <dylukes>that couldn't indicate connection success/failure really though
00:15:47  <piscisaureus_>dylukes: they return -1 on failure and 0 on suyccess.
00:15:58  <dylukes>right but the callback isn't called until it's established.
00:16:08  <dylukes>so success can't be guaranteed until you're in the callback and check the status.
00:16:13  <piscisaureus_>dylukes: ah right, well it can fail immediately if for example the socket is fucked, or already connected or something
00:16:28  <dylukes>Oh awesome.
00:16:29  <piscisaureus_>dylukes: so, when it returns 0 it doesn't mean that it will all be well
00:16:33  <dylukes>So there's TWO places I need to check errors :D?
00:16:38  <piscisaureus_>dylukes: yep
00:16:55  <dylukes>I'm just trying to work out how to walk the list asynchronously.
00:17:04  <dylukes>It's going to involve a try_next_ai function and statics, I suppose.
00:17:12  <dylukes>Or I could just pass the state every time and keep it functional.
00:17:23  <piscisaureus_>dylukes: I am not sure if uv_connect will ever fail immediately if your application is bug-free. It probably shouldn't
00:17:38  <piscisaureus_>dylukes: so you could just assert that uv_connect returns 0
00:17:39  <dylukes>Assuming you're application is bug-free is a programmer bug :\.
00:20:25  <dylukes>Okay so if I fudge the ownership a bit this can work.
00:24:36  * orlandovftwquit (Ping timeout: 240 seconds)
00:25:53  * pfox___quit (Ping timeout: 248 seconds)
00:26:08  <dylukes>ohhh lovely...
00:26:30  <dylukes>Does freeing uv_getaddrinfo_t delete the results?
00:26:42  <dylukes>or do I have to free them separately?
00:26:47  <dylukes>(that would be a *good thing* in this case >_<)
00:26:47  <piscisaureus_>dylukes: no, only uv_freeaddrinfo_t does that.
00:26:54  <dylukes>thank goodness.
00:26:56  <dylukes>^^;
00:27:06  <dylukes>I need the addrinfo list to persist for a bit...
00:27:08  <piscisaureus_>uv_freeaddrinfo that would be
00:27:29  <dylukes>I'm sticking the current list head in the connect handle as a baton.
00:27:48  <dylukes>So if the connection fails it just calls a try_next_addr with it, which factors the traversal code out.
00:27:49  <dylukes>basically.
00:28:18  <piscisaureus_>sounds fine.
00:31:12  <piscisaureus_>I am off, bye all
00:35:33  * AvianFlujoined
00:37:48  * benviejoined
00:40:47  * mikealjoined
00:44:33  * piscisaureus_quit (Ping timeout: 248 seconds)
00:44:44  * hij1nxjoined
00:47:54  * perezdquit (Quit: perezd)
00:49:55  * brsonquit (Ping timeout: 244 seconds)
01:05:06  * pieternquit (Read error: Connection reset by peer)
01:05:23  * pieternjoined
01:09:30  * orlandovftwjoined
01:12:19  * indutnychanged nick to indutny_away
01:13:21  * pieternquit (Quit: pietern)
01:14:45  * perezdjoined
01:18:11  <dylukes>eek.
01:18:20  <dylukes>So uh, I'm a little shocked by how bad some of the 4/6 compat stuff is.
01:20:40  <dylukes>Would you guys mind a patch deleting all of the 6 methods?
01:20:55  <dylukes>All of the functions with 4/6 variants can/should be agnostic.
01:21:01  <dylukes>in fact, the implementations are IDENTICAL underneath...
01:21:15  <dylukes>the sockaddr arguments just need to be passed as pointers, not by value.
01:24:28  <TooTallNate>dylukes: probably ask bert or ben tomorrow when they're online
01:24:37  <dylukes>Yeah, it'd be a big breaking patch.
01:24:53  <dylukes>Since every function with a 6 variant would lose the 6 variant, and sockaddr_in[6] params would change to sockaddr *
01:25:32  <dylukes>Basically... there's no point to having different versions. The af_family field in the sockaddr lets you distinguish underneath... not that you have to anyways.
01:25:43  <dylukes>All of the BSD/Winsock code is totally agnostic...
01:25:52  <dylukes>if you use getaddrinfo, you shouldn't even ever have to type a 4 or 6.
01:26:10  <dylukes>TooTallNate: what're they're names on irc?
01:26:14  <TooTallNate>well sounds like you have a pretty good argument on your side ;)
01:26:39  <TooTallNate>dylukes: look for piscisaureus or bnoordhuis
01:26:52  <dylukes>piscisaureus is which one?
01:26:56  <TooTallNate>bert
01:28:01  * dapquit (Quit: Leaving.)
01:28:38  * orlandovftwquit (Ping timeout: 272 seconds)
01:34:05  <dylukes>is libuv used by node yet?
01:34:15  <dylukes>or is it still its own experimental thing?
01:34:39  <TooTallNate>dylukes: node as of v0.6.x uses libuv everywhere
01:34:46  <dylukes>crap.
01:34:52  <dylukes>so... this will break node too ^^.
01:35:05  <TooTallNate>most likely :p
01:35:10  <isaacs>dylukes: yeah.
01:35:48  <dylukes>luckily nodes net library is already 4/6 agnostic.
01:35:55  <dylukes>so the changes on its front should be minimal.
01:36:06  <dylukes>in fact, it's probably going to constitute REMOVING code, not adding it ^^.
01:37:15  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
01:46:15  <creationix>dylukes, I like the change
01:46:22  <creationix>I maintain 3 projects that use libuv
01:46:28  <creationix>writing bindings for 4 and 6 is a pain
01:46:30  <dylukes>It needs to be done...
01:46:40  <dylukes>Yeah, I'm gonna branch and try it out tomorrow.
01:46:53  <dylukes>It's just blatant code duplication.
01:46:55  <dylukes>Literally.
01:47:18  <dylukes>The definitions for uv__tcp_connect and uv__tcp_connect6 actually are *identical* :P
01:47:37  <dylukes>they both just cast the sockaddr_in/6's to what they SHOULD have been originally (struct sockaddr *)
01:48:12  <creationix>so I'll just have to pass in my address by address when I call
01:48:16  <creationix>that's not a big change
01:49:21  <isaacs>dylukes: as long as it's agreeable to piscisaureus and bnoordhuis, it sounds reasonable to me, as long as it's not in the v0.6 branch
01:50:22  <creationix>Isn't node 0.8.0 getting close? I would think now is the ideal time to make these kind of changes in master libuv
01:50:37  <creationix>safe, but API changing cleanups
01:51:56  <dylukes>heh?
01:52:02  <dylukes>why is the v0.6 branch separate from master?
01:52:16  <dylukes>I mean, it has independent changes
01:52:19  <dylukes>seems odd.
01:52:32  <dylukes>oh, a patch got put on both branches.
01:53:24  <creationix>node has strict API and ABI stability within a stable series
01:53:34  <creationix>the libuv abi can't change for the node 0.6.x lifespan
01:53:52  <dylukes>but isn't that why there's a v0.6 branch?
01:54:10  <dylukes>node's external API/ABI shouldn't change at all.
01:54:18  <dylukes>All this is is remapping some internal functions.
01:54:22  <dylukes>and removing redundancy.
01:54:37  <creationix>ask bert or ben
01:54:45  <creationix>they are in Europe
01:54:49  <dylukes>hehe yeah
01:59:53  * mikealquit (Quit: Leaving.)
02:23:40  * mikealjoined
02:35:03  * benviequit
03:10:29  * mikealquit (Quit: Leaving.)
03:13:05  * benviejoined
03:24:17  * dylukesquit (Quit: Pipes are broken. Sending packets via Fedex.)
03:48:09  * pfox___joined
03:55:12  * mikealjoined
04:06:13  * mikealquit (Quit: Leaving.)
04:09:32  * orlandovftwjoined
04:29:14  * Ariajoined
04:38:23  * pfox___quit (Ping timeout: 264 seconds)
04:42:35  * orlandovftwquit (Ping timeout: 264 seconds)
05:00:11  * perezdquit (Read error: Connection reset by peer)
05:00:39  * perezdjoined
05:05:01  * perezdquit (Ping timeout: 246 seconds)
05:15:51  * Ariaquit (Remote host closed the connection)
05:54:08  * perezdjoined
05:55:07  * benviequit (Ping timeout: 260 seconds)
06:09:45  * isaacsquit (Remote host closed the connection)
06:26:52  * paddybyersjoined
06:27:47  * orlandovftwjoined
07:49:27  * orlandovftwquit (Ping timeout: 244 seconds)
07:51:54  * rendarjoined
07:58:05  * stephankquit (Quit: *Poof!*)
08:13:17  * mikealjoined
08:18:54  * mikealquit (Ping timeout: 244 seconds)
08:23:52  * mikealjoined
08:51:00  * kuebkjoined
09:41:32  * paddybyersquit (Quit: paddybyers)
09:47:11  * dshaw_quit (Quit: Leaving.)
09:54:47  * indutny_awayquit (Ping timeout: 250 seconds)
09:59:59  * mikealquit (Ping timeout: 276 seconds)
10:01:05  * indutnyjoined
10:08:36  * rendarquit
10:10:14  * rendarjoined
10:41:30  * mikealjoined
11:13:28  * paddybyersjoined
11:26:32  * wankdankerjoined
12:22:39  * mikealquit (Read error: Connection reset by peer)
12:22:48  * mikealjoined
12:54:45  * indutnyquit (Quit: Leaving.)
12:55:04  * k-schanged nick to k-s[AWAY]
12:55:36  * indutnyjoined
13:21:59  * piscisaureus_joined
13:29:11  * paddybyersquit (Quit: paddybyers)
13:44:10  * bnoordhuisjoined
14:32:44  * k-s[AWAY]changed nick to k-s
14:42:47  <creationix>piscisaureus_, bnoordhuis, any idea what could cause this assertion to fail?
14:42:47  <creationix>canio: src/unix/core.c:237: uv__finish_close: Assertion `!(handle->flags & UV_CLOSED)' failed.
14:43:09  <piscisaureus_>creationix: calling uv_close twice on the same handle
14:43:11  * paddybyersjoined
14:43:29  <creationix>I don't think that's what I'm doing
14:43:37  <creationix>I guess I can log the struct pointer address before calling
14:43:40  <creationix>and look for dupes
14:44:01  <piscisaureus_>creationix: or maybe the pointer just points to an uninitialized handle
14:44:05  <piscisaureus_>or not a handle at all
14:44:24  <creationix>hmm
14:45:40  <creationix>so I call close on two different objects in my app
14:45:44  <creationix>when logginc the C calls I get
14:45:45  <creationix>uv_close(0x7f4629357a76, 0x408784)
14:45:45  <creationix>uv_close(0x7f4629357c54, 0x408784)
14:47:04  <creationix>and if I just do one of the closes, it still breaks. If I do just the other it doesn't
14:47:32  <piscisaureus_>creationix: can you point me to the code?
14:48:12  <creationix>piscisaureus_, at the script level, this is the one causing trouble https://github.com/creationix/candor.io/blob/master/test-timer.can#L30
14:48:35  <creationix>which calls https://github.com/creationix/candor.io/blob/master/src/luv_handle.cc#L25
14:48:58  <creationix>would this happen if the VM moved my uv_timer_t struct?
14:49:04  <piscisaureus_>yes
14:49:12  <piscisaureus_>that would invalidate the pointer right
14:49:25  <piscisaureus_>you can never move libuv structs around
14:49:43  <creationix>I'll bet that's it
14:49:56  <creationix>I found a different bug yesterday where it was moving my structs causing segfaults
14:51:15  <creationix>btw, besides this moving struct issue, it's working quite nicely, the candor syntax is ok. https://github.com/creationix/candor.io/blob/master/net.can#L80-85
14:53:05  <CIA-99>node: Ben Noordhuis v0.6 * rea44d30 / src/node_crypto.cc : crypto: fix compile-time error with openssl <= 0.9.7e - http://git.io/ZeUzuw
14:54:00  * pfox___joined
14:55:41  <pfox___>bnoordhuis: rust-libuv love continues (albeit slowly)
14:55:56  <bnoordhuis>pfox___: good :)
14:56:03  <bnoordhuis>need help / pointers / moral support?
14:56:11  <tjfontaine>beer?
14:56:21  <pfox___>not unless you want to work on the rust<->C ABI bridge :)
14:56:30  <bnoordhuis>eh, i'll settle for beer
14:56:36  <bnoordhuis>part of the moral support
14:56:50  <pfox___>well look me up next time you're in seattle
14:56:50  <tjfontaine>I thought it was liquid courage
14:57:09  * perezdquit (Quit: perezd)
14:57:15  * k-schanged nick to k-s[AWAY]
14:57:20  <bnoordhuis>i hear good things about seattle
14:57:31  <pfox___>they're all lies. it's an intellectual wasteland.
14:57:32  <bnoordhuis>like how they have this big highway that lets you exit the city real quick
14:57:49  <creationix>pfox___, don't temp me, I'm a libuv binding addict
14:58:24  <pfox___>creationix: you could probably do it faster, heh.
14:58:28  <pfox___>i just had a kid
14:58:37  <pfox___>not me, personally.
14:58:43  <tjfontaine>congratulations
14:58:49  <pfox___>anyways.. hell of a time to get involved with library work for a new lang :)
14:58:54  <creationix>mine is due any week now, I understand
14:59:02  <creationix>pfox___, indeed, I'm writing libuv bindings for candor lang
14:59:21  <pfox___>candor? never heard of it..
14:59:22  <creationix>just found a bug where the GC relocated my libuv structs causing all sorts of breakage
14:59:30  <pfox___>wow, that sucks.
14:59:49  <pfox___>yeah.. my main nuisance is passing stuff by-val into C is broken
14:59:54  <pfox___>at least by-val returns from C is fixed, now
14:59:58  <creationix>https://github.com/creationix/candor.io, https://github.com/indutny/candor
15:00:12  <pfox___>i was having to malloc everything in c++ then return void* to rust and pass that back
15:00:23  <pfox___>now i can return the value from C, at least.. but still have to pass a ptr back in :/
15:00:38  <creationix>yeah, libuv's use of structs keeps me from using it in luajit ffi
15:00:40  <pfox___>but this ABI work landed in, like, the last week
15:01:32  <pfox___>anyways.. just got uv_write working .. there's some ugliness.. but that status == 0 in the uv_write_cb was *glorious*
15:01:43  * travis-cijoined
15:01:43  <travis-ci>[travis-ci] joyent/node#629 (v0.6 - ea44d30 : Ben Noordhuis): The build passed.
15:01:43  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/851b397...ea44d30
15:01:43  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/922547
15:01:43  * travis-cipart
15:01:50  <pfox___>translating a rust vector of bytes into an array of uv_buf_t's was.. interesting.
15:02:00  <pfox___>a vector of vectors of bytes, even
15:02:11  <creationix>pfox___, yes, this is my third time to bind libuc to a new platform and uv_write is a milestone
15:02:12  <pfox___>for the uv_buf_t[] arg to uv_write
15:02:25  <pfox___>ah, so then you know my pain.
15:02:31  <creationix>heh, I usually just cheat and pass a single buf
15:02:48  <pfox___>next: alloc_cb (which im concerned about because of aforementioned ABI woes)
15:02:51  <pfox___>and uv_read_start
15:02:54  <pfox___>and its cb
15:03:03  <pfox___>(im working through a tcp request happy path)
15:03:05  <creationix>I don't expose alloc_cb to the vm
15:03:09  <creationix>I just hard-code it to malloc
15:03:15  <pfox___>yeah, i can understand that
15:03:16  <creationix>and then free it in onWrite
15:03:27  <pfox___>but rust *should* have the tools to do it, in theory
15:03:39  <pfox___>on paper it has pretty strong FFI support
15:03:46  <pfox___>but we're getting there, still :)
15:04:08  <creationix>I should look into rust when my experiments are stable enough for someone else to take over
15:04:28  * txdvjoined
15:05:11  * dylukesjoined
15:05:58  <pfox___>it's a neat language, it's really grown on me.
15:06:30  <dylukes>bnoordhuis: piscisaureus_: hey
15:06:32  <creationix>yeah, I learned some about it when I interviewed for the b2g team last fall
15:06:35  <dylukes>I was told I should ask you two about this.
15:06:39  <creationix>rust looks cool
15:06:52  <dylukes>It is cool! :o
15:06:55  <dylukes>So, I was looking through libuv, and I noticed how the 4/6 compat stuff is... broken.
15:07:01  <bnoordhuis>dylukes: ho
15:07:06  <dylukes>You expose two API's, with *identical* implementation underneath.
15:07:13  <dylukes>Would you accept a rather... API breaking patch to fix this?
15:07:19  <bnoordhuis>probably not
15:07:23  <bnoordhuis>what exactly is broken?
15:07:28  <dylukes>okay so, let me give an example
15:07:36  <dylukes>there is uv_tcp_connect and uv_tcp_connect6
15:07:48  <dylukes>the only different is one takes a sockaddr_in6 and the other a sockaddr_in
15:07:52  <dylukes>however, the underlying implementation..
15:07:59  <dylukes>for both... are identical.
15:08:21  <dylukes>They just convert to (sockaddr *) and pass it to the *same connect functions*
15:08:45  <dylukes>Really, there should only be one uv_tcp_connect, which takes a (struct sockaddr *), not a (struct sockaddr_in[6])
15:08:58  <dylukes>Basically, you're exposing two API's for one underlying API.
15:09:02  <creationix>do we have to break API? does plain C allow function overloading
15:09:12  <dylukes>I think you're missing the point. (and no).
15:09:16  <bnoordhuis>creationix: no function overloading in c
15:09:30  <dylukes>let me give an example...
15:09:40  <dylukes>There's no function overloading, but,
15:09:47  <dylukes>the sockaddr set of structures are polymorphic.
15:09:51  <dylukes>They're like uv_request and uv_handle.
15:10:12  <dylukes>They all share the same head (sockaddr) and you can find out if it's a sockaddr_in or sockaddr_in6 or sockaddr_storage from the ai_family field.
15:10:32  <bnoordhuis>dylukes: we did it like that because it's easy to use
15:10:32  <dylukes>Now the problem is, when the user gets a addrinfo from uv_getaddrinf,
15:10:37  <dylukes>yeah, but it's *not*
15:10:43  <dylukes>let me try to explain the issue better
15:10:52  <dylukes>let's say you call uv_getaddrinfo.
15:11:23  <dylukes>now you have a linked lists of addrinfos. For each, you can get the sockaddr.
15:11:29  <dylukes>Now, because there are two functions, I have to do this...
15:11:47  <dylukes>emphasis on line 58
15:11:47  <dylukes>https://gist.github.com/2158903
15:11:59  <dylukes>notice... I'm casting a sockaddr to sockaddr_in or sockaddr_in6...
15:12:06  <dylukes>well guess what both of those functions do underneasth!
15:12:08  <dylukes>They cast it BACK.
15:12:19  <dylukes>In other words, there's *no reason* for these to exist as separate functions.
15:12:55  <dylukes>bnoordhuis: https://github.com/joyent/libuv/blob/master/src/unix/tcp.c#L210
15:12:57  <dylukes>see the problem ;)?
15:13:10  <dylukes>uv__tcp_connect and uv__tcp_connect6 are mightly similar huh :).
15:13:14  <dylukes>mighty*
15:14:39  <bnoordhuis>they are... but i'm still not really convinced it's a problem
15:14:49  <dylukes>Well it's a problem because
15:14:51  <dylukes>1) it's redundant
15:14:53  <dylukes>2) it's a terrible API
15:15:05  <dylukes>3) it's betraying all the work the POSIX and Winsock API's go to to HIDE 4/6 compat from you.
15:15:12  <dylukes>These API's are designed to be agnostic.
15:15:17  <dylukes>And you're just totally blowing it up.
15:15:25  <pfox___>that's a bit hyperbolic
15:15:32  <dylukes>Not to mention, node.js actually exposes only one API (correctly)
15:15:43  <dylukes>meaning in your node implementation you have redudant switching code like I do.
15:15:52  <dylukes>Well, no... there's just zero good reason for these to be separate functions.
15:16:02  <pfox___>perhaps at the time
15:16:08  <dylukes>Uh.. no...
15:16:11  <pfox___>now the "good" reason is the inertia of API
15:16:24  <dylukes>Yes, but I would propose a change for a future stable version.
15:16:43  <tjfontaine>dylukes: you're not exhibiting what I would consider useful contributor feedback, you're being a bit standoffish
15:16:50  <dylukes>I'm sorry. ;__;
15:17:11  <dylukes>But well, what I'd change is, all of the functions with a 6 variant have the 6 variant deleted, and all sockaddr_in/6 can be passed polymorphically as sockaddr * instead.
15:17:26  <dylukes>Amusingly, this doesn't involve adding a single line of code, just deleting lines of code :P.
15:17:43  <bnoordhuis>dylukes: then there's node and all the other projects that use libuv
15:18:02  <creationix>I'm more than willing to change mine for API changes (fwiw)
15:18:08  <dylukes>Right ,I'm aware node requires libuv's API not to change.
15:18:11  <creationix>less API surface to bind is a good thing
15:18:20  <dylukes>But, this would ostensibly be for Node v.7 or v.8
15:18:32  <bnoordhuis>we may reconsider this at some time but not now, there's more important work to do
15:18:39  <dylukes>Well, I'm offering to contribute a patch.
15:19:01  <bnoordhuis>dylukes: libuv is being overhauled quite extensively right now
15:19:15  <dylukes>Then it's probably a pretty good time to get it in, no?
15:19:16  <pfox___>i eagerly await the death of uv_err_t
15:19:18  * perezdjoined
15:19:41  <bnoordhuis>dylukes: it'd probably be broken by the time you finish writing up the PR :)
15:19:56  <dylukes>Nah, I don't think so :).
15:20:01  <dylukes>It only touches maybe 6 or 7 files.
15:20:06  <bnoordhuis>come back in a couple of weeks and we'll discuss it again
15:20:10  <dylukes>If you'd like I'll contribute a patch for node.js to to fix it there.
15:20:26  <dylukes>Again, expect lots of - and no +'s...
15:20:47  <bnoordhuis>we're working towards the 0.8 release
15:20:47  <creationix>is libuv's C API part of node's public API?
15:20:58  <creationix>well, I guess parts are, I know addons use uv_work_t
15:21:07  <bnoordhuis>so that patch has no chance of making it in until the first 0.8 release is done
15:21:08  <dylukes>creationix: No... node's API for the net module only exposes one connect/bind etc.
15:21:13  <dylukes>bnoordhuis: that's fine.
15:21:23  <dylukes>The point is just that it's there when it's time.
15:21:33  <saghul>fwii in pyuv I also hide the 4/6 duality, like node does
15:22:11  <dylukes>Everything I've looked ast does.
15:22:20  <dylukes>Even the C API libuv is built on hides the 4/6 duality!
15:22:28  <dylukes>libuv is the only component exposing it for some reason.
15:22:46  <bnoordhuis>dylukes: i don't disagree with you
15:22:52  <bnoordhuis>but i won't be taking patches right now
15:23:05  <bnoordhuis>like i said, come back in a week or two
15:23:10  <dylukes>I can just write up a patch and post it as an issue, then we can get back to it then maybe?
15:23:14  <bnoordhuis>sure
15:23:36  <creationix>bnoordhuis, wouldn't you want to change APIs before releasing a new ABI for node?
15:23:49  <dylukes>Yeah, that was my thought too :P.
15:24:08  <bnoordhuis>creationix: it would be change for 0.9, not 0.8
15:24:13  <bnoordhuis>*a change
15:24:19  <creationix>ok, so it's too late for 0.8 changes is what you're saying
15:24:22  <bnoordhuis>yes
15:24:26  <creationix>ok, that makes sense
15:24:39  <dylukes>alright, well I'll fork and do my stuff, then put up a pull request I suppose.
15:24:44  <bnoordhuis>cool
15:24:57  <creationix>we got pretty burned changing APIs right before the 0.4 release, I'm glad we're learning
15:25:18  <dylukes>So, out of curiosity, are you planning to merge/rewrite c-ares?
15:25:21  <piscisaureus_>bnoordhuis: connect/connect6 is kind of weird imo.
15:25:29  <bnoordhuis>piscisaureus_: yes
15:25:30  <dylukes>that is, into a complete uv_getaddrinfo, uv_gethostbyname, uv_dns_query, etc or something?
15:25:38  <dylukes>It's just... bad. haha.
15:25:50  <bnoordhuis>dylukes: c-ares?
15:25:52  <dylukes>It's code duplication, unnecessary complexity in the API...
15:25:57  <dylukes>passing structs by value...
15:25:59  <piscisaureus_>bnoordhuis: the question is, do we want uv_tcp_init6 because that means we can get rid of deferred socket creation
15:26:15  <bnoordhuis>piscisaureus_: we do - but not now :)
15:26:26  <bnoordhuis>that refcount refactor is a big enough change for one major release
15:26:40  <creationix>ohh, is there a refcount API now?
15:26:50  <bnoordhuis>dylukes: re passing structs by value: look at the assembly code
15:27:05  <bnoordhuis>creationix: not quite, we're moving to a different model
15:27:07  <dylukes>bnoordhuis: what do you mean?
15:27:16  <bnoordhuis>one that hopefully fixes a lot of edge cases
15:27:26  <dylukes>May I ask what?
15:27:37  <creationix>nice, the refcount system has always been touchy to me
15:27:37  <dylukes>The refcounting used in say, libdispatch or libxpc seems to work pretty well.
15:27:43  <bnoordhuis>dylukes: pass by value on x86 means the caller allocates space on the stack and passes a pointer to the callee
15:27:55  <bnoordhuis>dylukes: iow, it's just syntactic sugar for passing pointers around
15:28:06  <dylukes>bnoordhuis: Right but... it's just an additional possible copy then.
15:28:15  <dylukes>The addrinfo is already allocated on the heap, and you have a pointer to it.
15:28:16  <creationix>bnoordhuis, I will say that it makes ffi harder though
15:28:21  <dylukes>There's no reason to copy it to the stack and pass a new pointer.
15:28:25  <pfox___>creationix++++++++++++++++++++++++++
15:28:25  <kohai>creationix has 5 cherry juices
15:28:42  <bnoordhuis>cherry juice now?
15:28:46  <creationix>:)
15:28:48  <creationix>just for me
15:28:59  <bnoordhuis>aw, that's sweet
15:29:40  <creationix>if it weren't for pass by value, I could write luvit entirely using luajit ffi
15:29:53  <bnoordhuis>creationix: it's convenient when writing tests :)
15:30:06  <bnoordhuis>but in hindsight it wasn't a well thought out design choice
15:30:11  <pfox___>life consists of tradeoffs
15:30:13  <dylukes>Really? How is it more convenient :\?
15:30:18  <dylukes>The only difference is a single *.
15:30:25  <bnoordhuis>dylukes: look at the libuv tests
15:30:35  <pfox___>a big challenge we face, as nerds, is an insistence upon an ultimate, objective "correctness"
15:30:43  <dylukes>You could just alloca and then pass the pointer from that
15:30:45  <bnoordhuis>very true
15:30:48  <pfox___>in conclusion: libuv is a land of contrasts
15:30:50  <bnoordhuis>dylukes: alloca is evil
15:30:51  <dylukes>and it will be operationally identical.
15:30:52  <piscisaureus_>alloca <-- noway
15:31:02  <dylukes>Yes, but so is initializing structs on the stack :|
15:31:10  <dylukes>And if you've malloc'd them, you have a pointer.
15:31:12  * creationixdoesn't even know what alloca is and probably shouldn't find out
15:31:19  <dylukes>creationix: dynamic stack allocation.
15:31:22  <dylukes>it's evil.
15:31:23  <dylukes>;P
15:31:35  <creationix>ohh, that sounds tempting
15:31:39  <creationix>:P
15:32:07  <dylukes>bnoordhuis: I'm not seeing how it makes the tests simpler...
15:32:08  <tjfontaine>until you're on micro threads and imagemagick allocas 10MB
15:32:39  <dylukes>:P
15:35:58  <dylukes>So...
15:36:06  <dylukes>apart from API inertia, is there any motion against this patch?
15:37:12  <tjfontaine>I think the motion is mostly for the patch, just not in the short term
15:37:39  <creationix>is the roadmap for post 0.8 full already
15:37:43  <creationix>or is it pretty open still?
15:38:25  <creationix>I think merging the *4/*6 functions and not using pass-by-value would be valuable API improvements for then
15:38:46  <dylukes>I can probably have the changes done today.
15:39:14  <creationix>it would at least make using libuv easier for me
15:41:46  <dylukes>indeed.
15:41:56  <bnoordhuis>creationix: post 0.8 - the main thing we want to get rid of is deferred creation of sockets
15:42:08  <bnoordhuis>i.e. uv_tcp_init() will create the socket right there and then
15:42:11  <creationix>does that change the API?
15:42:16  <bnoordhuis>yes
15:42:31  <creationix>sounds neat
15:42:47  <bnoordhuis>oh, and i might be phasing out libev altogether on linux
15:42:53  <bnoordhuis>but that's still TBD
15:43:01  <tjfontaine>I had a feeling that would be coming
15:43:05  <creationix>so just use the linux API directly then?
15:43:08  <bnoordhuis>yes
15:43:12  <dylukes>bnoordhuis: I wonder if you could build on libdispatch on OS X.
15:43:23  <dylukes>Considering it's got some pretty hefty low level platform specific optimizations...
15:43:24  <bnoordhuis>dylukes: i don't know it well enough
15:43:24  <creationix>sounds like a lot of work, but potentially very good
15:43:39  <dylukes>mm, it's a bit different than libev. but it's actually a pretty easy API.
15:43:52  <dylukes>All of the object's in it are refcounter, and follow almost the same style as libuv too.
15:43:57  <tjfontaine>I thought libdispatch was the backend of GCD
15:44:02  <dylukes>It is.
15:44:08  <dylukes>I mean, it's synonymous really.
15:44:14  <dylukes>The only difference is it uses _t for the opaque pointer types, and _s for the structures.
15:44:24  <dylukes>To pull off some transparent union polymorphism.
15:44:32  <dylukes>Which is a nice trick.
15:44:47  <dylukes>It's basically a (more) typesafe version of what you guys do with matching structs.
15:45:08  <creationix>dylukes, C or C++ or objC?
15:45:21  <dylukes>C.
15:45:25  <creationix>neat
15:45:40  * dapjoined
15:45:43  <tjfontaine>but you need llvm-gcc or clang because it uses blocks, which more than likely is what the toolchain is atm anyway
15:45:55  <dylukes>You actually don't need blocks.
15:46:06  <dylukes>It can be compiled without blocks enabled.
15:46:29  <dylukes>It actually has facilities for async io (pretty hefty too, even has low/high water marks, block size, etc),
15:46:38  <dylukes>and for sparse mutable buffers, etc.
15:46:47  <dylukes>It's kind of for the same thing as libuv.
15:47:35  <dylukes>Really, it's fast because it has kernel support from xnu... >_>
15:48:58  <creationix>any C experts in here want to help me with double pointers?
15:49:45  <bnoordhuis>creationix: shoot
15:49:46  <creationix>since candor moves my CData around when it GC's I can't store uv structs directly in there, but I can store a pointer to one and malloc it myself
15:50:26  <dylukes>candor?
15:50:31  <creationix>so I have a candor function that basically does malloc(sizeof(uv_timer_t*)) and gives me the void*
15:50:46  <creationix>how do I convert that to a uv_timer_t* and malloc the actual struct myself
15:50:56  <dylukes>That'd give you (tecnically) a uv_timer_t **
15:51:05  <dylukes>You can then do
15:51:10  <creationix>dylukes, https://github.com/creationix/candor.io
15:51:17  <dylukes>*that = malloc(sizeof(uv_timer_t))
15:51:25  <dylukes>Follow the types, young padawan.
15:52:02  <dylukes>uv_timer_t **pp = malloc(sizeof(uv_timer_t*));
15:52:21  <dylukes>*pp = malloc(sizeof(uv_timer_t));
15:52:38  <dylukes>Make sense?
15:52:51  <creationix>right, then `uv_timer_t *p = *pp`
15:52:58  <dylukes>Yes. Bingo.
15:53:11  <creationix>do I have to create the **pp variable
15:53:17  <dylukes>but, remember this might cause you trouble because you have to deallocate both of them...
15:53:19  <creationix>or can I use an expression on the lhs
15:53:44  <dylukes>You can't put a malloc on the lhs :P.
15:53:49  <creationix>well, the uv_timer_t** is managed by the vm, it will free it for me when it get's GCed
15:53:52  <dylukes>And it would be messy and unclear if you could.
15:54:01  <creationix>and I can register a callback to be told when that's about to happen
15:54:06  <creationix>to free my uv_timer)t*
15:54:19  <dylukes>It sounds like you're running a high risk of leaking :P.
15:54:35  <creationix>well, those are the constraints of the vm
15:54:37  <dylukes>pp -> p -> timer right?
15:54:50  <creationix>it moves the memory it manages so I can only store pointers in there
15:54:51  <dylukes>pp is just a pointer on the stack
15:54:56  <dylukes>p is a pointer under GC
15:55:05  <dylukes>timer is a uv_timer_t under manual memory
15:55:11  <creationix>dylukes, right
15:55:17  <dylukes>so the GC will free p, timer will be freed in your callback, yes?
15:55:25  <dylukes>Why not put the uv_timer_t under GC then?
15:55:26  <creationix>right
15:55:31  <creationix>because it moves
15:55:34  <dylukes>Most GC schemes allow you to supply the deleter.
15:55:36  <creationix>and libuv doesn't like that
15:55:40  <dylukes>It moves?
15:55:50  <creationix>yep
15:56:03  <creationix>https://github.com/indutny/candor/issues/13
15:56:29  <dylukes>I see.
15:57:12  <creationix>it doesn't move when I do the same thing in lua
15:57:25  <creationix>so I'm not sure how they preserve it
15:57:39  <creationix>maybe they allocate the managed memory outside the vm heap
15:57:40  <creationix>not sure
15:58:18  * mmalecki[zzz]changed nick to mmalecki
15:58:38  <dylukes>okay... so it seems on windows there's some slight differences between the 4/6 routines.
15:58:42  <dylukes>But nothing major.
15:58:50  <creationix>if anyone has any ideas of how indutny can fix this for me in the vm without causing undue constraints on the vm, I'm all ears
15:59:13  <creationix>otherwise I need to use double pointers and register weak callbacks myself
15:59:38  <creationix>(I'm already using double pointers to get the CData*)
16:00:03  <bnoordhuis>what's wrong with double pointers?
16:00:17  <creationix>more complex code and more overhead
16:00:24  <creationix>that's all
16:00:28  <dylukes>the overhead is barely existant.
16:00:34  <dylukes>Don't worry over that :P.
16:00:41  <dylukes>And, double pointers are pretty common anyways.
16:00:51  <bnoordhuis>having variable sized heap objects makes for a GC that's more complex and has more overhead
16:01:04  <dylukes>But the pointer is fixed size :P.
16:01:10  <dylukes>The struct isn't in the GC.
16:03:21  <creationix>so when libuv has a timer event, it calls my C function and passes in the request or stream struct, that has a ->data pointer to a (Handle<T>) pointer to a (CData*) which has a ->value pointer to my uv_timer_t** which points to my uv_timer_t* which points to the actual uv_timer_t
16:03:53  <dylukes>Hm, so a small issue bnoordhuis
16:04:10  <dylukes>Normally when you have an addrinfo, you get ->ai_addrlen and pass that to bind :\
16:04:33  <dylukes>so, ostensibly uv__tcp_bind should expose that parameter?
16:06:07  <creationix>I guess such pointer chains are common in such dynamic environments
16:08:20  * sh1mmerquit (Quit: sh1mmer)
16:09:04  * isaacsjoined
16:10:12  <creationix>I think I'll make a new struct that contains my uv_timer_t*
16:10:18  <creationix>then I can add other info if I want later on
16:17:56  <dylukes>huh
16:17:59  <dylukes>actually, this is kind of amusing
16:18:07  <dylukes>nevermind.. it can be cleaned up later...
16:18:37  <creationix>in C++, can "new" be used to allocate x void* bytes?
16:18:42  <creationix>or do I have to use malloc
16:18:58  <dylukes>yes, it can.
16:19:00  <dylukes>for arrays.
16:19:04  <dylukes>http://www.cplusplus.com/reference/std/new/operator%20new[]/
16:19:19  <dylukes>oh... for void *... that I don't know.
16:19:26  <dylukes>C++ tries to dodge void * wherever possible.
16:19:27  <kohai>C has 13 beers
16:19:32  <dylukes>dylukes++
16:19:33  <kohai>You can't give karma to yourself!
16:19:34  <dylukes>:<
16:19:40  <dylukes>I didn't want karma, just a beer...
16:20:17  <creationix>void* foo = new void[size];
16:20:26  <creationix>we'll see if that works
16:20:58  <creationix>I guess I can use uint8_t[size] and typecase to void*
16:21:03  <creationix>*typecast
16:22:06  <dylukes>heheh. bnoordhuis, I keep having to police myself to keep myself in your style guidelines :P
16:22:15  <dylukes>I keep typing sockaddr * instead of sockaddr* >.<
16:22:27  <bnoordhuis>dylukes: it's not my style either
16:22:45  <dylukes>Well, the changes are going pretty easily...
16:23:04  <dylukes>In face.. it looks like I may just get rid of the uv_tcp_connect and uv__tcp_connect duality later too.
16:23:12  <dylukes>At the moment the former is just forwarding to the latter.
16:23:13  <bnoordhuis>creationix: new void[size] is bogus
16:23:19  <dylukes>There's no particular reason for them to exist.
16:23:24  <dylukes>creationix: You can't have an array of void.
16:23:26  <dylukes>Just a pointer to void.
16:23:46  <bnoordhuis>creationix: think of it like this, what would sizeof(void) return?
16:24:02  <creationix>right, I know in the gcc extension sizeof(void) is 1 byte
16:24:07  <creationix>but that's non-standard
16:24:15  <bnoordhuis>which is a blasphemy unto the lord
16:24:25  <dylukes>Actually, in C++ sizeof(void) is a compile time error...
16:24:30  <dylukes>In C it's usually 1.
16:24:46  * bnoordhuisis off to dinner
16:24:56  <dylukes>seeya
16:25:00  <creationix>ok, on destructors, if I have two members that are pointers that I allocated with new, do I have to delete them in the destructor, or is that automatic?
16:25:05  * orlandovftwjoined
16:25:25  <creationix>or in other words, is delete recursive
16:25:33  <bnoordhuis>creationix: no
16:25:46  <bnoordhuis>(how could it be?)
16:25:55  * k-s[AWAY]changed nick to k-s
16:25:55  * bnoordhuisis now really off to dinner
16:26:00  <creationix>thanks
16:27:34  <creationix>I think I'll just mix new and malloc
16:27:35  <creationix>https://gist.github.com/a679bfcf94371d1531db
16:27:40  <creationix>it's more straightforward
16:28:04  <creationix>and the reason I'm not doing new uv_handle_t is because it's actually any uv_*_t and I assume they are different sizes
16:28:09  <creationix>so I'm having the user pass in the size
16:28:31  <dylukes>Oh... there's a few warnings I'm getting about stuff being deprecated on OS X 10.8 too.
16:28:35  <dylukes>I can clean those up later too.
16:29:26  <creationix>hmm, I guess I shouldn't delete a non-pointer
16:30:13  <dylukes>creationix: Hey, are you on windows?
16:30:20  <creationix>nope, linux
16:30:22  <creationix>why?
16:30:22  <dylukes>Bah.
16:30:33  <dylukes>Because I only get compile time type checking for the unix stuff.
16:30:36  <dylukes>due to the defines :P.
16:30:41  * mikealquit (Quit: Leaving.)
16:30:50  <creationix>piscisaureus_, usually is though if he has time
16:30:52  <dylukes>I can just use travis.
16:32:09  <dylukes>Anyhow, I've just about got TCP cleaned up.
16:32:42  * mikealjoined
16:34:43  * indutnyquit (Ping timeout: 252 seconds)
16:35:08  <dylukes>Alright!
16:35:13  <dylukes>TCP is 4/6 agnostic on unix platforms.
16:35:16  <dylukes>Moving on to windows...
16:35:26  <dylukes>Well, first I'll clean up UDP here.
16:37:04  <dylukes>Need to make sure I rewrite the documentation too!
16:37:47  * dshaw_joined
16:41:09  * kuebkpart
16:46:44  <dylukes>piscisaureus_: Hey, you around?
16:48:21  <piscisaureus_>dylukes: sup?
16:48:22  * pieternjoined
16:48:38  <dylukes>piscisaureus_: I'm working on that patch, but I don't have a way to test on windows that everything's compiling through.
16:48:43  <dylukes>(I'm on an OS X/Linux dualboot)
16:48:52  <dylukes>What would you recommend?
16:49:47  <dylukes>and on another note, when is UV_HANDLE_IPV6 supposed to be set?
16:49:54  <dylukes>it seems it's only set on Windows UDP ipv6 connections >_>...
16:50:11  * AndreasMadsenjoined
16:50:57  * mmaleckichanged nick to mmalecki[brb]
16:50:57  <AndreasMadsen>When I press docs on nodejs.org it says v0.6.13 but when I go to fs.html it says v0.6.14-pre
16:54:13  <dylukes>>_<
16:54:18  <dylukes>This IOCP stuff is messy, egh.
16:54:52  <dylukes>ahaha, oh wait nevermind, these two functions aren't different at all :P
16:55:28  <isaacs>AndreasMadsen: whoops, i think i regenerated that page for a typo post-0.6.13
16:55:29  <isaacs>one sec
16:57:01  <isaacs>AndreasMadsen: should be fixed.
16:57:12  <AndreasMadsen>isaacs: it is
16:57:17  <isaacs>great :)
16:57:31  <AndreasMadsen>isaacs: not that I care, but I think you do
16:57:49  <isaacs>i do a little, yeah :)
16:57:58  <isaacs>it's a wart.
16:58:29  * dshaw_quit (Quit: Leaving.)
16:58:54  * travis-cijoined
16:58:54  <travis-ci>[travis-ci] DylanLukes/libuv#1 (ipv46agnostic - 15785ee : Dylan Lukes): The build failed.
16:58:54  <travis-ci>[travis-ci] Change view : https://github.com/DylanLukes/libuv/commit/15785ee
16:58:54  <travis-ci>[travis-ci] Build details : http://travis-ci.org/DylanLukes/libuv/builds/923455
16:58:54  * travis-cipart
16:59:18  <dylukes>Oh, I guess that's picking up my fork too :\.
16:59:26  <dylukes>Forgot to fix up the tests too >.<
17:00:03  <AndreasMadsen>isaacs: Oh please don't write word I don't know. I look them up and get stupid picture.
17:00:15  <isaacs>AndreasMadsen: lol
17:00:19  <isaacs>sorry :)
17:00:33  <tjfontaine>haha
17:01:01  <piscisaureus_>dylukes: to test on windows I recomment windows
17:01:09  <dylukes>Great idea.
17:01:10  <dylukes>:)
17:01:13  <piscisaureus_>dylukes: and UV_HANDLE_IPV6 is set for ipv6 sockets
17:01:14  <isaacs>igorzi: i want to fork 0.6.14 today
17:01:35  <isaacs>igorzi: did you have something you needed piscisaureus_ to review? or can i review it?
17:01:37  <isaacs>where's that at?
17:01:40  <dylukes>piscisaureus_: Well... it's not set for any sockets on unic it doesn't seem.
17:03:05  <dylukes>searching unix/tcp.c for UV_HANDLE_IPV6 turns up nothing.
17:04:50  <dylukes>So... from the looks of it you assume IPv6 compatibility for the POSIX socks api, but not for Winsocks?
17:04:53  <dylukes>Is that correct?
17:04:59  <dylukes>(the winsock code has a lot of checks)
17:09:12  <piscisaureus_>dylukes: windows and unix have separate implementations.
17:09:46  <piscisaureus_>dylukes: on windows we set the IPV6 handle so we can remember whether the socket was ipv4 or ipv5
17:09:48  <piscisaureus_>er, 6
17:10:28  <piscisaureus_>dylukes: and it is needed so it needs to stay. On unix it is not needed so we don't use it on unix.
17:11:22  <philips>piscisaureus_: :)
17:11:23  <dylukes>kk cool
17:11:39  <dylukes>windows ia bit harder because I'm kind of guessing about the API, and I don't have a windows dev system set up
17:11:45  <piscisaureus_>philips: ?
17:11:52  <dylukes>I'll set up a virtualbox w/ XP and msvc I suppose.
17:11:58  <piscisaureus_>dylukes: that seems best yeah.
17:12:06  <philips>piscisaureus_: cconf, you mentioned it yesterday but I was away
17:12:14  <piscisaureus_>dylukes: so what are you working on anyway?
17:12:28  <piscisaureus_>philips: ah, right. Yeah that's pretty cool. When is it scheduled?
17:12:46  <dylukes>piscisaureus_: I'm merging all of the 4/6 functions.
17:13:08  <philips>piscisaureus_: Working on that- probably August as three of speakers I want will be in the US for Linux Plumbers and Kernel Summit
17:13:10  <dylukes>And changing all the sockaddr_in/6 parameters to sockaddr * and a socklen_t
17:14:00  <piscisaureus_>dylukes: windows has no socklen_t so you can't use that.
17:14:13  <dylukes>sec
17:17:23  <dylukes>k so...
17:17:34  <dylukes>I thought there was a socklen_t in winsock?
17:18:49  <dylukes>oh, it just uses an int.
17:18:50  <dylukes>okay.
17:18:57  <piscisaureus_>dylukes: could be in ws2tcpip.h
17:19:00  <piscisaureus_>that I am not sure of
17:19:06  <dylukes>Perhaps I should add a uv_socklen_t type?
17:19:15  <dylukes>which is int on windows, and socklen_t on unix?
17:19:37  <piscisaureus_>dylukes: http://msdn.microsoft.com/en-us/library/windows/desktop/ms738531%28v=vs.85%29.aspx seems to suggest that socklen_t is there.
17:19:50  <piscisaureus_>dylukes: so maybe it's better to try with socklen_t anyway
17:19:53  <piscisaureus_>sorry for the confusion
17:19:57  <dylukes>no problem :)
17:20:11  <dylukes>Nonetheless, windows connect/bind uses an int.
17:20:17  <dylukes>and calls it namelen, not addrlen...
17:20:20  <dylukes>winsock is messy :\
17:20:33  <dylukes>Anyhow, I'm just going to get the tests working on unix first
17:20:42  <dylukes>then commit that, then install windows and finish it up there.
17:22:41  <piscisaureus_>philips: you already have a list of speakers you want? that's fast :-)
17:23:18  <philips>piscisaureus_: I started the website so I had something to discuss as I got a core list of speakers/organizers. Then it got picked up by HN and I got swarmed. It was great though :)
17:23:37  <piscisaureus_>ah right
17:24:00  <piscisaureus_>I just happened to see that ryah started following github.com/cconf :-)
17:24:05  <dylukes>See the nice thing is,
17:24:19  <dylukes>since I'm adding a parameter... I get "too few arguments" errors everywhere,
17:24:22  <dylukes>and then I just fix them.
17:24:27  <dylukes>^^.
17:24:33  <dylukes>types <3
17:30:33  * orlandovftwquit (Ping timeout: 252 seconds)
17:31:07  * indutnyjoined
17:31:11  * indutnypart
17:31:15  * indutnyjoined
17:31:18  <dylukes>oh god dammit
17:31:22  <dylukes>even the unit tests have 4/6 variants.
17:31:34  <dylukes>Oh well, those should stay separate.
17:33:54  <dylukes>piscisaureus_: Is there any plan to subdivide the test suite?
17:35:01  <piscisaureus_>dylukes: no. what would there be to subdivide?
17:35:24  <dylukes>nevermind.
17:35:38  <dylukes>Anyways, all of the unit tests currently create a sockaddr_in on the stack and pass that
17:35:48  <dylukes>so I'm changing them all to (struct sockaddr *)&addr
17:36:05  <dylukes>The calls don't require the addresses to stick around later, so even a pointer into the stack should be fine, yes?
17:39:11  <dylukes>Currently I'm just running through these unit tests with some regexes hehe.
17:39:32  <dylukes>(checking each one by hand mind you, just saving myself some typing)
17:42:47  <dylukes>piscisaureus_: so bnoordhuis was saying this sort of big patch wouldn't make it in until 0.9.
17:44:29  * mmalecki[brb]changed nick to mmalecki
17:49:38  * TooTallNatejoined
17:50:12  <piscisaureus_>dylukes: right, I think he's right
17:50:32  <dylukes>As long as it can eventually be useful :P.
17:50:57  <dylukes>I'll try to keep my patch up to date so it can be merged easily when the time comes.
17:51:04  <piscisaureus_>k, cool
17:51:26  <dylukes>I'm chugging through the unit tests fixing them up >.<
17:51:38  <dylukes>Probably another dozen more
17:52:41  <dylukes>the only slight "downside" to the API change is (and this is pretty minor), you have to pass the addrlen down from the top.
17:52:48  <dylukes>so it's an extra parameter.
17:55:02  <dylukes>There are two alternatives...
17:55:29  <dylukes>either require the user to feed in the sizeof the parameter (which is a sockaddr *, but in reality its a in/in6
17:55:38  * hij1nxquit (Quit: hij1nx)
17:55:38  <dylukes>or infer it from the sa_family
17:55:50  <dylukes>the problem with the latter is it will wreak havoc if they pass in a sockaddr_storage.
17:56:00  <dylukes>So the former seems safer to me, just a slight bit more verbose.
18:00:23  * AndreasMadsenquit (Remote host closed the connection)
18:01:58  * dshaw_joined
18:04:47  <dylukes>hrm... on the last test, I hit one catch.
18:05:00  <dylukes>piscisaureus_: It seems I'll also have to change the udp_recv_cb_t.
18:05:27  <dylukes>It needs to pass the addrlen in as well, for uv_udp_send to use.
18:07:07  * dshaw_1joined
18:09:26  * dshaw_quit (Ping timeout: 276 seconds)
18:09:31  <dylukes>heh, that actually was pretty painless.
18:11:00  * isaacsquit (Remote host closed the connection)
18:12:12  * brsonjoined
18:13:00  * travis-cijoined
18:13:00  <travis-ci>[travis-ci] DylanLukes/libuv#2 (ipv46agnostic - 1aefc47 : Dylan Lukes): The build is still failing.
18:13:00  <travis-ci>[travis-ci] Change view : https://github.com/DylanLukes/libuv/compare/15785ee...1aefc47
18:13:00  <travis-ci>[travis-ci] Build details : http://travis-ci.org/DylanLukes/libuv/builds/924012
18:13:00  * travis-cipart
18:18:06  * piscisaureus_quit (Ping timeout: 246 seconds)
18:18:20  * mikealquit (Quit: Leaving.)
18:22:09  * travis-cijoined
18:22:09  <travis-ci>[travis-ci] DylanLukes/libuv#3 (ipv46agnostic - abe8165 : Dylan Lukes): The build is still failing.
18:22:09  <travis-ci>[travis-ci] Change view : https://github.com/DylanLukes/libuv/compare/1aefc47...abe8165
18:22:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/DylanLukes/libuv/builds/924070
18:22:09  * travis-cipart
18:23:26  * orlandovftwjoined
18:23:49  * orlandovftwquit (Client Quit)
18:23:52  <dylukes>So uh... are all these unit tests supposed to be failing right now?
18:24:00  * orlandovftwjoined
18:24:18  <igorzi>bnoordhuis: hey
18:24:31  <igorzi>bnoordhuis: yt?
18:27:22  * sh1mmerjoined
18:27:24  <mmalecki>dylukes: they fail on Linux for various reasons, so answer to your question is "yes". consult with Travis to check which are expected to fail.
18:27:41  <dylukes>travis is running less tests... strangely.
18:28:08  <mmalecki>how come?
18:28:08  <dylukes>I have +114, -16, it has +103, -12
18:28:17  <dylukes>I don't know. I branched just today.
18:28:20  <mmalecki>interesting.
18:28:37  <mmalecki>I will look into it later.
18:28:39  <dylukes>But uh, one of the failing ones is test_udp_send_recv
18:28:44  <dylukes>which really shouldn't be failing for sure
18:30:04  <dylukes>I need to get my changes working in windows as well, then I'll start debugging unit tests...
18:31:48  * AndreasMadsenjoined
18:40:33  * CoverSli1equit (Read error: Connection reset by peer)
18:42:51  <igorzi>bnoordhuis: pls comment on https://github.com/igorzi/node/commit/f8932effcddd1a0ee07e3d3dfd68fcfd1d6824bf#commitcomment-1111378
18:44:54  * mikealjoined
18:50:48  * isaacsjoined
18:50:55  * mikealquit (Quit: Leaving.)
18:51:56  * hij1nxjoined
18:52:24  * AndreasMadsenpart
18:54:32  * hij1nxquit (Remote host closed the connection)
18:59:36  * hij1nxjoined
18:59:57  * mjr_quit (Quit: mjr_)
19:00:14  * mjr_joined
19:01:17  * `3rdEdenjoined
19:03:22  * skomskijoined
19:17:15  * CoverSlidejoined
19:23:08  <dylukes>I'm installing windows on a VM to work on it there to.
19:23:13  <dylukes>s/to/too
19:26:11  * indutnyquit (Read error: Connection timed out)
19:29:27  * indutnyjoined
19:30:54  * igorziquit (Ping timeout: 245 seconds)
19:40:20  * skomskiquit (Quit: skomski)
19:44:42  * dshaw_joined
19:46:35  * dshaw_1quit (Ping timeout: 244 seconds)
19:57:42  <dylukes>Do you guys use mingw for windows?
19:59:45  <pfox___>i don't think its the core build env in windows, but its doable?
19:59:56  <pfox___>it's what rust in windows is built on, so presumably libuv is , as well
20:03:23  <dylukes>er, I mean
20:03:26  <dylukes>what is the core build env? :P
20:03:39  * dylukeshopes he doesn't need visual studio. ugh.
20:04:12  <pfox___>im pretty sure you can dev on mingw
20:04:30  <pfox___>but i believe VS is the primary
20:04:35  * piscisaureus_joined
20:04:40  <pfox___>ill let an experienced windows mount a defense for why this is preferrable
20:04:47  <pfox___>speak of the devil
20:04:58  <pfox___>piscisaureus_: query: why is VS a preferrable build env on windows?
20:05:13  <piscisaureus_>pfox___: because msvc is a better compiler than gcc?
20:05:18  <dylukes>Or rather, what IS the preferable build env?
20:05:18  <pfox___>on windows.
20:05:22  <dylukes>because we can't all afford msvc.
20:05:34  <dylukes>Oh well, I guess there's a free version.
20:05:35  <piscisaureus_>everyone can afford msvc
20:05:45  <piscisaureus_>vs express is free and so is the sdk
20:07:52  <dylukes>Right.
20:08:17  <dylukes>hm
20:08:25  <dylukes>the SDK isn't installed by the MSCV setup...
20:08:45  <piscisaureus_>it is
20:08:52  <dylukes>I'm not seeing it in the list.
20:09:14  <dylukes>Oh, it's been merged with .NET now.
20:09:16  <dylukes>That'd explain it.
20:09:27  <dylukes>I was used to the Platform SDK and .NET framewor being separate... heh.
20:19:27  * `3rdEdenquit (Quit: Leaving...)
20:23:54  <indutny>Assertion failed: (!(handle->flags & UV_CLOSED)), function uv__finish_close, file src/unix/core.c, line 237.
20:23:59  <indutny>why that may happen? ^
20:24:15  <indutny>well, I understand assertion
20:24:20  <indutny>but that handle was just opened
20:24:21  <piscisaureus_>indutny: funny, creationix asked the same today
20:24:28  <indutny>heh
20:24:32  <indutny>that's the same problem
20:24:33  <piscisaureus_>indutny: was init properly initialized?
20:24:41  <indutny>piscisaureus_: let me see
20:24:48  <piscisaureus_>indutny: did candor move the object?
20:24:56  <indutny>piscisaureus_: not anymore
20:25:01  <indutny>it's allocated with 'new'
20:25:28  <piscisaureus_>indutny: is it also initialized with uv_xyz_init?
20:25:42  <indutny>piscisaureus_: yes
20:25:51  <indutny>uv_timer_init
20:26:16  <creationix>the timer object is fine, I don't call close till after it's timeout fires
20:26:34  <creationix>and I have another timer that's repeating and it closes without error
20:26:52  <indutny>aah
20:27:05  <piscisaureus_>let me check uv_unix
20:27:09  <piscisaureus_>indutny: it could also happen if you previously freed another object oo early
20:27:28  <indutny>well
20:27:35  <indutny>you may want to test it with gdb
20:28:09  * indutnychanged nick to indutny_sleeping
20:28:19  <indutny_sleeping>going to sleep now
20:28:21  <indutny_sleeping>ttyl
20:30:08  <isaacs>piscisaureus_: So, libuv is now powering node.js (of course), luvit, candor, and luvmonkey...
20:30:17  <isaacs>piscisaureus_: i think that the next frontier is Algol-68
20:30:36  <piscisaureus_>:-p
20:30:41  <isaacs>piscisaureus_: i'm not joking.
20:30:44  <isaacs>it's a fanTAStic language.
20:30:56  <piscisaureus_>pyuv too btw
20:31:15  <isaacs>nah, python and ruby are lost causes.
20:31:26  * igorzijoined
20:31:30  <pfox___>rust
20:31:32  <isaacs>too much synchronicity in their core stdlibs
20:31:35  <piscisaureus_>candor and luvmonkey are not quite there yet :-)
20:31:36  <isaacs>algol, man
20:31:41  <isaacs>it's great.
20:31:48  <piscisaureus_>isaacs: are you serious?
20:31:50  <igorzi>isaacs: still waiting for bnoordhuis to review https://github.com/igorzi/node/commit/f8932effcddd1a0ee07e3d3dfd68fcfd1d6824bf#commitcomment-1111378
20:31:51  <piscisaureus_>I never looked at it
20:31:59  <piscisaureus_>bnoordhuis: ^
20:32:11  <piscisaureus_>igorzi: how is the connected socket sharing coming along?
20:32:55  <piscisaureus_>isaacs: soon I will write my own language
20:33:00  <piscisaureus_>which will blow algol away
20:33:08  <piscisaureus_>not to mention candor
20:33:08  <isaacs>piscisaureus_: algol-68 is actually really really nice. you should at least take a close look at it.
20:33:18  <isaacs>it got a lot right.
20:33:32  <igorzi>piscisaureus_: should have it ready within next few days (got distracted by another project)
20:33:43  <piscisaureus_>igorzi: ok
20:34:21  <piscisaureus_>isaacs: I will take a look,
20:34:36  <isaacs>piscisaureus_: the frustrating thing is that it was designed before the internet.
20:34:39  <piscisaureus_>isaacs: but I don't think anybody uses algol these days
20:34:54  <isaacs>piscisaureus_: so most of the documentation is in PDFs scanned and held behind closed doors by the ACM and whatnot.
20:35:08  <isaacs>piscisaureus_: that's only because there's no modern implementation!
20:35:18  * isaacssometimes can't tell when he's kidding and when he's serious...
20:35:26  <isaacs>i think i might be only like 25% kidding on this one, though
20:36:03  <piscisaureus_>isaacs: the language tries too hard to look like natural english
20:36:24  <piscisaureus_>isaacs: so instead of `if (date.day == 22)`
20:36:48  <piscisaureus_>they do `if day of date eq 22 then`
20:36:49  <piscisaureus_>or something
20:37:03  <piscisaureus_>isaacs: btw, did you know that there is a german variant of algol btw
20:39:49  <isaacs>i did not know that.
20:40:36  <creationix>piscisaureus_, candor is getting there
20:40:47  <creationix>I just fixed the tcp echo server to not crash under high load
20:41:12  <isaacs>piscisaureus_: you should create a new Algol, though, not Algol-68
20:41:17  * `3rdEdenjoined
20:41:19  <creationix>added an extra layer of pointers so when my cdata moves, my uv structs don't
20:41:22  <isaacs>piscisaureus_: call it Algol-13 or whenever you end up doing it
20:41:55  <isaacs>piscisaureus_: that works on two levels, because it'll be both newer (2013 > 1968) and also slimmed down and re-imagined (since 13 < 68)
20:41:59  <creationix>smalltalk, self, or io might be fun
20:42:10  <piscisaureus_>io is actually pretty neat
20:42:24  <creationix>candor is neat, but there is zero protypal inheritance
20:42:50  <isaacs>http://jmvdveer.home.xs4all.nl/algol68g.pdf
20:42:53  <piscisaureus_>I don't know what I would do with prototypal inheritance
20:43:13  <piscisaureus_>I am try to solve concurrency in a nice way
20:43:14  <creationix>yes, I think I'll try io next instead of ruby
20:43:22  <creationix>I forgot how tidy that one was
20:43:24  <isaacs>bnoordhuis: ping
20:45:27  <isaacs>igorzi: i see, so (looking closely at this patch)...
20:45:52  <isaacs>igorzi: it looks like the issue is that you do write(), write(), write(), queueing them up. then the handle goes away, and we throw at some point in the future.
20:45:58  <creationix>so candor + libuv is candor.io, would io + libuv be io.io ?
20:46:12  <AvianFlu>creationix, e.io.io?
20:46:22  <isaacs>creationix: it'd be uvio
20:46:23  <creationix>io�
20:46:39  <creationix>it supports unicode
20:46:42  <creationix>:)
20:47:39  <creationix>AvianFlu, is that some io joke. I don't actually know the language
20:48:07  <AvianFlu>nah, it was a roundabout attempt at an old mcdonald joke
20:48:13  <creationix>ahh
20:48:13  <AvianFlu>I don't know the language either
20:50:11  <piscisaureus_>I have to go. Unfortunately my language isn't done yet :-p
20:50:25  <isaacs>piscisaureus_: have fun :)
20:52:04  <piscisaureus_>thanks
20:52:08  <igorzi>isaacs: yep, exactly
20:52:33  * indutny_sleepingquit (Read error: Connection timed out)
20:52:46  <isaacs>igorzi: ok. so, i'd say, +1 on bnoordhuis's comments. plus, the cb argument should always go last (not super relevant, since this is an internal function, but consistency etc.)
20:52:49  <igorzi>isaacs: when the handle goes away we also destroy _connectQueue (which we're still iterating it in the loop)
20:53:04  <igorzi>isaacs: did you see my other comment?
20:53:27  <igorzi>isaacs: if we're talking about consistency we should also fire the write callback in case of non-quued writes
20:54:04  <isaacs>igorzi: yes. i see that. (not the comment, github gremlins got that one, i think()
20:54:25  <isaacs>igorzi: but yeah, really, we should only keep iterating as long as teh _handle is ther.
20:55:01  <dylukes>hm.
20:55:11  <dylukes>piscisaureus_: So the only thing I'm actually kind of worried about with this change,
20:55:18  <dylukes>is that uv_udp_recv_cb changes.
20:55:32  <igorzi>isaacs: that part is easy.. the part that we can't seem to agree on is what to do with the callbacks for writes that are queued
20:55:36  <isaacs>igorzi: and yes, we should call the cb if it's provided, even if it's not queued.
20:55:37  <dylukes>And C compilers do a notoriously bad job of typechecking function poiners.
20:55:59  <isaacs>igorzi: but really, no one uses that anyway (since they can't, since it's not consistently applied ;)
20:56:09  * pietern_joined
20:56:47  * pietern_quit (Read error: Connection reset by peer)
20:56:49  * pietern__joined
20:56:49  <isaacs>oh, wait, we do, nevermind
20:56:51  <isaacs> writeReq.oncomplete = afterWrite;
20:56:51  <isaacs> writeReq.cb = cb;
20:56:52  <isaacs>igorzi: ^
20:56:58  <igorzi>isaacs: right
20:57:53  <igorzi>so, in case of non-queued writes if a write fails (status != 0 in afterWrite) we don't fire the write callback
20:57:58  <igorzi>isaacs: ^
20:58:06  * pieternquit (Ping timeout: 240 seconds)
20:58:15  <igorzi>isaacs: we emit the 'error' event on the socket object
20:58:19  <isaacs>right
20:58:42  <isaacs>igorzi: you're taling about this bit?
20:58:44  <isaacs> if (!writeReq) {
20:58:44  <isaacs> this.destroy(errnoException(errno, 'write'));
20:58:45  <isaacs> return false;
20:58:47  <isaacs> }
20:59:08  <igorzi>isaacs: yes
20:59:16  * indutnyjoined
20:59:46  <isaacs>igorzi: so, not to be dense here, just thorough... but why exactly do we *need* to call the cb when it fails?
21:00:33  <isaacs>i mean, it seems straightforward enough that we have to either call the cb(er) all the time on failure, or only call it when it succeeds, but not both.
21:01:12  <piscisaureus_>isaacs:
21:01:12  <piscisaureus_>var pending_writes = 0;
21:01:12  <piscisaureus_>while (1) {
21:01:12  <piscisaureus_> socket.write('foo', function() { pending_writes--; });
21:01:12  <piscisaureus_> pending_writes++;
21:01:13  <piscisaureus_>}
21:01:17  <dylukes>What git line ending mode does libuv recommend piscisaureus_ ?
21:01:24  <piscisaureus_>^-- it must always end up 0
21:01:31  <piscisaureus_>dylukes: unix style
21:01:34  * pietern__quit (Ping timeout: 272 seconds)
21:01:38  <dylukes>So, commit unix style?
21:01:39  <igorzi>bnoordhuis's argument was that we need to call cb to not have resource leaks
21:01:39  <isaacs>ok, kewl.
21:01:44  <piscisaureus_>yes
21:01:47  <dylukes>excellent.
21:02:01  <isaacs>piscisaureus_, igorzi: i lean that way myself. ok. so, we need to call the cb every time.
21:02:14  <piscisaureus_>we must call the cb always unless write() throws
21:02:28  <igorzi>isaacs: so, that's my point.. we also need to fix up the non-queued writes code-path
21:02:39  * pieternjoined
21:02:46  <isaacs>piscisaureus_: we can call self.destroy(er, cb) on that failure. then destroy will emit('error', er) and then call the cb
21:03:18  <piscisaureus_>isaacs: I gotto get out of the train now. sorry.
21:03:25  <isaacs>unless it's extremely obvious that a function was called inappropriately -- wrong args etc -- then we should emit('error') rather than throw
21:04:02  <isaacs>and, actually, there's a lot of cleanup in .destroy() that we're skipping as well.
21:04:03  <isaacs>that's not great.
21:04:44  * CoverSlidequit (Ping timeout: 272 seconds)
21:05:27  <igorzi>isaacs: ok, i'll tweak the patch to fire the write cb on all failure paths
21:06:39  <isaacs>igorzi: it'd be best to funnel everything through .destroy()
21:07:00  <igorzi>isaacs: k
21:07:23  <isaacs>igorzi: oh, i guess it's not that simple, since .destroy() aborts if you'er already destroyed
21:07:36  <isaacs>igorzi: but they should call .destroy() at some point
21:07:41  * piscisaureus_quit (Ping timeout: 246 seconds)
21:07:43  <isaacs>just in case you'er swallowing 'error' events
21:08:11  * perezdquit (Ping timeout: 276 seconds)
21:08:38  <isaacs>igorzi: in other news... i actually just put that fs.rename() kludge into graceful-fs for win32
21:08:56  <isaacs>igorzi: the tar/cache refactoring is coming along, but it's a big risky change. i'd like to not rush it.
21:09:24  <igorzi>isaacs: nice
21:09:26  <isaacs>igorzi: lmk when you're happy with the net write queue thing, and i'll branch v0.6.14-release
21:10:42  <igorzi>isaacs: you also want to change this https://github.com/joyent/node/blob/v0.6/lib/net.js#L453 ? (to emit 'error' rather than throwing)?
21:10:52  <igorzi>isaacs: seems a bit risky for v0.6?
21:11:31  <isaacs>igorzi: yes, emit error rather than throwing.
21:11:38  <isaacs>igorzi: it throws by default if there's no handler anywy.
21:11:42  <isaacs>it's not particularly riky.
21:11:43  <isaacs>*risky
21:11:48  <igorzi>isaacs: k
21:12:45  <isaacs>igorzi: the problem (which would be good to fix in v0.8 if we have cycles for it) is that the http<->net boundary is a bit convoluted, and there are examples that we see in the wild where "impossible" things happen, resulting in throws that restart servers.
21:13:01  <isaacs>error events are catchable
21:13:05  <isaacs>throws are not
21:14:09  <igorzi>isaacs: yep, i'm all for error events.. just was wandering if you wanted to go that route in v0.6
21:14:25  <isaacs>yeah
21:14:31  <isaacs>it's pretty clearly winful in this case, i think
21:18:33  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
21:21:18  <dylukes>Windows is driving me insane..
21:28:23  * rendarquit
21:29:57  * k-schanged nick to k-s[AWAY]
21:31:39  * pfox___quit (Quit: leaving)
21:31:49  <bnoordhuis>igorzi: pong
21:31:59  <bnoordhuis>you want me to review https://github.com/igorzi/node/commit/f8932effcddd1a0ee07e3d3dfd68fcfd1d6824bf#commitcomment-1111378 ?
21:32:32  <igorzi>bnoordhuis: yeah.. see the discussion above too
21:33:19  * perezdjoined
21:38:13  <mjr_>Hey guys, what do you make of this one: https://gist.github.com/e477b14f80f9ecf84624
21:38:39  <mjr_>That process is using 3K out of 10K permitted fds. Nowhere near the limit
21:40:15  <bnoordhuis>igorzi: i've read the discussion but can you please give me the executive summary? :)
21:41:49  <igorzi>bnoordhuis: basically, the question was should we fire the write callback for the 'regular' (non-queued) write.
21:42:02  <igorzi>bnoordhuis: we should
21:42:13  <bnoordhuis>mjr_: odd... is it just process.memoryUsage() that does that?
21:42:17  <igorzi>bnoordhuis: i'm going to add that to the patch
21:42:30  <bnoordhuis>igorzi: oh right, yes we should
21:42:43  <mjr_>bnoordhuis: yes, just process.memoryUsage()
21:42:43  <igorzi>bnoordhuis: i'm also going to change this https://github.com/joyent/node/blob/v0.6/lib/net.js#L453 to emit 'error' event instead of throwing
21:43:24  <bnoordhuis>igorzi: gah, i'm not in favor of that change
21:43:58  <bnoordhuis>mjr_: is this on smartos?
21:44:03  <mjr_>bnoordhuis: it is
21:44:24  <mjr_>Our whole node operation is now finally on Joyent.
21:44:28  <mjr_>The whole damn thing.
21:45:01  <bnoordhuis>congratulations :)
21:45:11  <bnoordhuis>what version of node are you running?
21:45:26  <mjr_>v0.6.12
21:46:07  <mjr_>These processes doing this are in a sad state, large heaps and I can't tell why. GC is on fire.
21:48:20  <mjr_>Check this out
21:48:20  <mjr_>http://ranney.com/hotnode1.svg
21:48:57  <igorzi>bnoordhuis: fight it out with isaacs :)
21:49:24  <bnoordhuis>mjr_: fancy flame graph :)
21:49:38  <bnoordhuis>that error you're seeing might be a misreported errno
21:50:19  <isaacs>bnoordhuis: in this case, it's absolutely right to emit error rather than throwing.
21:50:19  <mjr_>That would make sense. There are plenty of fds available, and dtrace doesn't suggest we are returning EMFILE anywhere
21:50:31  <isaacs>bnoordhuis: a) it's the same most of the time, and b) it happens in the future, uncatchably.
21:50:49  <isaacs>bnoordhuis: there is virtually no benefit to throwing rather than emitting, unless it's a badargs issue.
21:51:17  <bnoordhuis>isaacs: i half-agree, i think the check should be moved from _write() to write()
21:51:38  <isaacs>bnoordhuis: but the problem is that the socket can close while processing the pending write queue.
21:51:40  <bnoordhuis>mjr_: let me run a quick check on a smartos machine
21:52:10  <mjr_>some of our processes work fine for process.memoryUsage()
21:52:28  <isaacs>bnoordhuis: we need to clean up the net-http interface somewhat, and then i think we can be more strict about these.
21:52:39  <isaacs>but for now, it just makes issues harder to handle in the wild.
21:53:31  <ryah>mjr_: might make sense to test a less aggressive GC polling code...
21:54:09  <ryah>there's all this stuff in src/node.cc that tries to notify V8 that we're idle
21:54:19  <mjr_>Sure, but memory usage is the reason I want to ask V8 how big it thinks the heap is.
21:54:20  <ryah>but it's largely unneccessary
21:54:32  * paddybyersquit (Quit: paddybyers)
21:54:34  <dylukes>I'm slowly killing myself
21:54:42  <dylukes>trying to get windows working for this stuff
21:55:09  <ryah>sure would be nice if dtrace could demangle the c++ symbols :(
21:55:16  * paddybyersjoined
21:55:38  <bnoordhuis>waf is so hideously broken with JOBS=16 :(
21:55:41  <dylukes>I have to restart to change the PATH.
21:55:42  <dylukes>What is this.
21:56:04  <mjr_>ryah: mangling sucks, but those flame graphs are pretty great, right?
21:56:39  <ryah>omg they are awesome
21:56:51  <ryah>you can actually see js functions :)
21:57:04  <mjr_>It's amazing how little of the graph is our code.
21:57:06  <ryah>utter magic
21:57:12  <TooTallNate>dylukes: just closing and re-opening the terminal works for me
21:57:19  <mjr_>But our source lines and function names are right there in the stacks. Amazing.
21:57:26  <dylukes>TooTallNate: What version of windows are you on?
21:57:31  <dylukes>That doesn't work on W7 as far as I can tell.
21:58:54  <ryah>mjr_: can i post that on twitter?
21:59:19  <mjr_>sure
21:59:19  <bnoordhuis>mjr_: i'm not able to reproduce it
21:59:30  <mjr_>bnoordhuis: our non-busy processes do not exhibit this behavior
21:59:53  <mjr_>ryah: feel free to also mention it came from us if that's fun for you, otherwise whatever
22:01:59  <bnoordhuis>isaacs: i don't understand what you mean - there is no pending write queue, at least not in node
22:02:11  <bnoordhuis>isaacs: and the one in libuv does The Right Thing(TM)
22:05:15  <bnoordhuis>ryah: run dtrace's output through c++filt
22:05:34  <bnoordhuis>(i assume gcc on smartos comes with c++filt too)
22:05:45  <bnoordhuis>(it does)
22:06:40  <dylukes>Alright yes!!
22:06:44  <dylukes>I have Windows environment set up!
22:06:46  <dylukes>^_^
22:07:04  <dylukes>bnoordhuis: I'm elated. I might have that patch for you tonight or tomorrow!
22:07:09  <mjr_>Pretty happy about this dtrace jsstack + flame graph thing. It's a HUGE piece that's been missing from node.
22:07:32  <mjr_>Now we just need better heap profiling, and we can solve most production problems.
22:08:23  <bnoordhuis>igorzi, isaacs: https://github.com/igorzi/node/commit/f8932effcddd1a0ee07e3d3dfd68fcfd1d6824bf#commitcomment-1121404
22:09:30  <ryah>mjr_: do all your processes look like that?
22:09:35  <mjr_>nope, just the routers
22:09:48  <mjr_>We are rolling a restart right now.
22:10:04  <ryah>are they at 100% cpu?
22:10:07  <mjr_>yes
22:10:19  <ryah>i think we should comment out the idle notification code
22:10:26  <ryah>can probably add an ifdef
22:11:05  * benviejoined
22:11:17  <mjr_>https://gist.github.com/2164999
22:12:05  <mjr_>Also, look at me, I'm using prstat and pgrep like that wasn't a super different and annoying thing to learn.
22:12:43  <ryah>:)
22:13:22  <mjr_>We are really burning up these machines with node though.
22:13:42  <mjr_>If riak wasn't broken again, we'd be doing at least double, maybe 4X the traffic.
22:14:19  <mjr_>We've almost hit 1M sessions/https a few times a week ago, before we went on this datacenter move adventure
22:16:07  <ryah>mjr_: if i add a flag --no-idle-notifications will you try it?
22:16:12  <mjr_>oh sure
22:16:44  <mjr_>We've got nearly 400 router processes alone. We can easily just run one of them with that flag and see what happens.
22:17:06  * Raynosquit (Ping timeout: 240 seconds)
22:17:36  * mrb_bkquit (Ping timeout: 240 seconds)
22:17:57  <isaacs>bnoordhuis: yes, that's correct.
22:18:21  <bnoordhuis>isaacs: hah okay. yes, that throw should go
22:18:32  * coderarityquit (Ping timeout: 252 seconds)
22:20:43  * dshaw_quit (Quit: Leaving.)
22:21:18  <isaacs>bnoordhuis, igorzi: it should probably be a errnoException('ECONNABORTED', 'write'), too
22:22:00  <isaacs>though actually that would perhaps change error handling logic somewhere
22:22:07  <isaacs>better to keep the same error in v0.6
22:23:38  <isaacs>ryah: i'm going to do a v0.6.14 branch this evening. wanna send a patch? ;P
22:24:07  <bnoordhuis>isaacs: make sure he signs the CLA
22:24:10  <mjr_>Oh nice, it'd be great to try that and a memoryUsage fix.
22:24:16  <isaacs>hehe
22:24:28  <isaacs>mjr_: memoryUsage fix?
22:24:41  <mjr_>Bryan promised me that you would put such a fix in 0.6.14
22:24:41  <bnoordhuis>mjr_: i don't quite know what's causing it
22:25:03  <mjr_>I'm working this issue both top-down, and bottom-up.
22:25:07  <isaacs>mjr_: bmc is doing a patch right now for 0.6.14 for the FILE uchar 256 EMFILE problem
22:25:16  <mjr_>Oh, that's the same
22:25:29  <isaacs>oh, ok
22:25:39  <mjr_>Oh, it only kicks in when you get more than 256 fds or something?
22:26:03  <isaacs>yes, 0.6.14 is waiting on that, and igorzi's socket connect queue throw, and i'm just testing a pretty minor npm bugfix release to put in it
22:26:06  <ryah>what's happening with emfile?
22:26:13  <mjr_>Anyway, it causes process.memoryUsage() to fail EMFILE on our busy processes.
22:26:53  * txdvquit (Quit: No Ping reply in 180 seconds.)
22:27:14  * txdvjoined
22:34:07  <dylukes>Argh.
22:34:11  <dylukes>Is anyone on Windows still here?
22:34:16  <dylukes>visual studio decided to stop working.
22:34:17  <dylukes>apparently.
22:35:28  <dylukes>I'm getting MSB8012
22:35:29  <benvie>I am but I try to stay out of VS unless something just won't compile from the command line
22:35:46  * mrb_bkjoined
22:36:20  <benvie>that built targets stuff gets really old after a while
22:36:33  <dylukes>*sigh*
22:36:39  <benvie>that's just a warning no?
22:36:42  <benvie>because it still should work
22:37:01  <dylukes>Yeah, no.
22:37:03  <benvie>if it's failing it might because warn on errors is on
22:37:09  <dylukes>I just get zero warnings or errors.
22:37:11  <benvie>or whatever
22:37:13  <dylukes>When I should be getting ~20.
22:37:20  <CIA-99>node: Lal Jérémy master * ref046bf / test/fixtures/keys/Makefile : test: generate 1024-bit keys, pacify openssl 1.0.1 - http://git.io/SNrO9Q
22:37:23  <dylukes>It just suddenly happened. It was building fine before.
22:37:25  <benvie>warnaing as error
22:37:35  <benvie>yeah there was changes to the build process
22:37:37  <dylukes>It *claims* the build went perfectly,
22:37:41  <dylukes>but I know that's not true.
22:38:13  <dylukes>they show up from the command line build haha
22:38:31  <benvie>my stop stuff working too, not sure what in the build process caused the fail but I know it was because I was using a custom build thing that replaced msbuild
22:38:50  <dylukes>I have no idea.
22:38:57  <dylukes>It literally built one second, and stopped working the next.
22:39:09  <benvie>it has something to do with some changes to specifying the build platform and the target platform that were made in terms of feeding info into gyp
22:39:21  <benvie>oh maybe not that then, I dunno
22:39:23  <dylukes>Warning 1 warning MSB8012: TargetPath(C:\Users\Dylan\Desktop\libuv\Debug\uv.lib) does not match the Library's OutputFile property value (C:\Users\Dylan\Desktop\libuv\Debug\lib\uv.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile). C:\Program Files
22:39:23  <dylukes> (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets 1151
22:39:29  <dylukes>And that's all I see.
22:39:38  <dylukes>It just blindly says "build succeeded" otherwise.
22:39:39  <benvie>I see that error every time
22:39:49  <dylukes>It wasn't there until just now.
22:39:52  <benvie>it lots of projects
22:39:57  <benvie>in
22:40:10  <dylukes>Yeah well, now I can't do anything.
22:40:35  <benvie>http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
22:40:44  <benvie>maybe that will help =/
22:40:58  <benvie>there's a big chunk in there about that error
22:41:21  <dylukes>What perplexes me is how this just showed up out of nowhere.
22:41:33  <dylukes>I was just routinely building, fixing a bug, etc
22:41:45  <benvie>was this in VS or running a build bat?
22:41:58  <benvie>the bat file may have regenerated the project files
22:42:05  <benvie>which happens often enough
22:42:22  <benvie>and that's probably the source of the problem, the project file has some issue
22:42:56  <benvie>which really means gyp was given some wrong input params and generated a faulty project file
22:42:56  * mikealjoined
22:43:02  <ryah>mjr_: https://gist.github.com/2165201
22:43:18  <mikeal>ryan: come to Haus :)
22:43:26  <ryah>mikeal: heading over now
22:43:41  <ryah>mikeal:have you got lunch yet?
22:44:26  <dylukes>benvie: rightb ut... it was working just fine :|
22:44:29  <dylukes>this is in VS
22:44:32  <dylukes>I generated once.
22:44:34  * Raynosjoined
22:44:39  <ryah>mjr_: try that patch and see if it helps the GC issue...
22:44:40  <dylukes>And then it was working just fine, then suddenly stopped working.
22:45:05  <benvie>ah
22:46:09  <dylukes>http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/3c03e730-6a0e-4ee4-a0d6-6a5c3ce4343c
22:46:11  <dylukes>this looks relevant
22:46:19  <igorzi>isaacs bnoordhuis: https://github.com/igorzi/node/commit/50ab22827af246a11c9caec4f72e4aa957bc3ead
22:48:48  <dylukes>what the hell... how it's telling me there are no warnings or errors.
22:48:51  <dylukes>Again, this is untrue.
22:49:05  <isaacs>igorzi: testing.
22:49:54  <dylukes>I am just going to delete this and try again *sigh*
22:50:12  <isaacs>igorzi: passes look-over scrutiny, though. much nicer.
22:51:48  <bnoordhuis>igorzi: re self.errorEmitted: is it because .destroy() is supposed to be idempotent?
22:52:02  <mjr_>Is there ever hope of getrusage being part of libuv?
22:52:30  <bnoordhuis>mjr_: why would you want it?
22:52:33  <igorzi>bnoordhuis: yep
22:52:48  <mjr_>bnoordhuis: because I want to ask my processes how much CPU time they've consumed.
22:53:03  * travis-cijoined
22:53:03  <travis-ci>[travis-ci] joyent/node#630 (master - ef046bf : Lal Jérémy): The build is still failing.
22:53:03  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/feaa8a4...ef046bf
22:53:03  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/925871
22:53:03  * travis-cipart
22:53:12  <bnoordhuis>igorzi: okay, in that case disregard my second comment :)
22:53:13  <mjr_>We already have to ask them about various other application counters and such, including this memoryUsage() thing.
22:54:32  <igorzi>bnoordhuis: k :). the use case is - if you do many queued writes, and if the socket is closed - we probably don't want to emit 'error' on every one of them
22:55:22  * mikealquit (Quit: Leaving.)
22:55:43  * dylukesquit (Quit: Computer has gone to sleep.)
22:55:45  * skomskijoined
22:55:52  <bnoordhuis>igorzi: okay, that makes sense
22:56:03  <mmalecki>+1 on the getrusage thing
22:56:05  <bnoordhuis>igorzi: one thing though, you're changing the function prototype of .destroy()
22:56:13  <bnoordhuis>igorzi: iow, api change
22:56:32  <benvie>dylukes: can't say I blame you and deleting the repo entirely and starting over has fixed my broken stuff on more than one occasion (building node and/or libuv)
22:57:10  <igorzi>bnoordhuis: hmm, how about i create _destroy ?
22:57:13  <bnoordhuis>igorzi: it would be better to move the body of .destroy() into a new method ._destroy() and make .destroy() a stub that calls ._destroy()
22:57:16  <bnoordhuis>igorzi: exactly :)
22:57:18  * mikealjoined
22:57:46  <igorzi>bnoordhuis: ok :)
22:58:08  <bnoordhuis>mjr_: re getrusage... it's very unix-y
22:58:25  <mjr_>bnoordhuis: sure, but there's no Windows version of "how much CPU time have I used?"
22:58:32  * avsejquit (Excess Flood)
22:58:40  <mjr_>That's what I really want to ask.
22:58:55  * avsejjoined
23:00:17  <bnoordhuis>mjr_: what about a small add-on?
23:00:27  <mjr_>oh sure, that's probably what we'll do
23:00:59  <mjr_>But if we have process.memoryUsage() already, it seems like process.CPUUsage() is a natural compliment.
23:02:20  * dylukesjoined
23:02:29  <mmalecki>btw, we should think about unifying APIs. we have getters/setters and functions all over the place. what's the actual convention?
23:03:26  <bnoordhuis>mjr_: process.memoryUsage() was thought up in a time when we were all still young and foolish :)
23:03:29  <bnoordhuis>we're not young anymore
23:03:46  <bnoordhuis>mmalecki: functions, much to my dismay
23:04:37  <mmalecki>bnoordhuis: :(
23:04:49  <mmalecki>bnoordhuis: oh well, we're still foolish, it seems
23:05:00  <bnoordhuis>that was the implied joke, yes :)
23:05:48  <mmalecki>bnoordhuis: it was also related to functions, in this case
23:06:30  <mmalecki>ugh, I have to write an e-mail today :/
23:07:30  <isaacs>igorzi: yeah, bnoordhuis's nit about destroy's signature changing is valid, but it's minor.
23:07:52  <isaacs>igorzi: lgtm once that nit is resolved, though.
23:09:41  <benvie>I'm curious on what you mean mmaelecki, since there's no much difference between an accessor and a function
23:09:57  <mmalecki>benvie: API-wise, there is :)
23:10:19  <TooTallNate>mmalecki: where are you talking about though?
23:10:21  * CoverSlidejoined
23:10:32  <TooTallNate>like `process.stdin` starts off as a getter, for the lazy-loading
23:10:34  <benvie>it's funny because I've end implementing things as functions where before I would have ussed accessors out of complaints
23:10:37  <mmalecki>TooTallNate: process.memoryUsage() vs process.memoryUsage
23:10:57  <benvie>because an accessor isn't usable with functional application without wrapping it
23:10:58  * skomskiquit (Quit: skomski)
23:11:08  <bnoordhuis>process.env vs. process.getpid() for example
23:11:14  * bnoordhuisis responsible for that first one
23:11:15  <TooTallNate>mmalecki: in my book, that should be a function (opinions and all :p)
23:11:38  <TooTallNate>process.env is an interesting one
23:11:46  <TooTallNate>the only proxy object in node, right?
23:12:01  * txdvquit (Ping timeout: 260 seconds)
23:12:04  <TooTallNate>but
23:12:21  <TooTallNate>`process.pid` should exist :p
23:12:21  <benvie>only one I've seen, and it shows up funny too cause its prototype is this weird anonymous thing
23:13:19  <dylukes>this is sort of orthogonal, but
23:13:23  <benvie>process.env.__proto__
23:13:33  <dylukes>the current way uv_tcp_listen() is setup, it only does ipv4...
23:13:38  <dylukes>that's probably not an issue right now
23:13:42  <dylukes>but... just saying.
23:14:46  <benvie>`new process.env.__proto__.constructor` returns a new process.env copy
23:14:52  <mmalecki>we should ask twitter for an opinion!
23:15:00  * mmaleckiducks
23:15:23  <TooTallNate>benvie: haha, thats an interesting find
23:15:42  <benvie>yeah I figured it would crash node or something but it actually works
23:15:48  <TooTallNate>benvie: almost something that child_process should use :D
23:15:50  <benvie>also just called it produces an empt copy
23:15:59  <benvie>so new matters
23:16:27  <benvie>so there's you're empty env object for child processes too =D
23:17:00  <TooTallNate>mmalecki: well what's your opinion?
23:18:13  <mmalecki>TooTallNate: most important thing here is consistency. also, I prefer getters :)
23:18:28  <TooTallNate>it's circumstantial imo
23:18:43  <TooTallNate>if a value isn't gonna change, just use a regular prop
23:18:46  <TooTallNate>i.e. getpid()
23:18:55  <mmalecki>yeah, definitely
23:19:13  <TooTallNate>i only like getters really for the lazy-load case. where the getter is removed after the first call
23:19:20  <benvie>yeah I think that's basically the rule of thumb. If the property doesn't change in the lifetime of its container then make it a property
23:19:50  <benvie>most of the functions in `os` for example can arbitrarily change on each call
23:20:54  <TooTallNate>where are we using getters that aren't lazy-getters?
23:21:01  <dylukes>Getting there...
23:21:05  <TooTallNate>i'm sure there are some
23:21:49  <benvie>if I want to pass a function that has teh task of "return the current value for X" it's not possible to simply use a property
23:21:52  <CIA-99>node: Shigeki Ohtsu master * re1199fa / lib/tls.js : tls: fix CryptoStream.setKeepAlive() - http://git.io/rro28A
23:22:11  <benvie>which is the use case that convinced me accessors need to either come with functional versions in most cases or should just be functions
23:22:22  * travis-cijoined
23:22:22  <travis-ci>[travis-ci] DylanLukes/libuv#4 (ipv46agnostic - d074861 : Dylan Lukes): The build is still failing.
23:22:22  <travis-ci>[travis-ci] Change view : https://github.com/DylanLukes/libuv/compare/abe8165...d074861
23:22:22  <travis-ci>[travis-ci] Build details : http://travis-ci.org/DylanLukes/libuv/builds/926121
23:22:22  * travis-cipart
23:22:54  <mmalecki>also, os.getNetworkInterfaces should be os.networkInterfaces imo
23:22:57  <benvie>I've started actually providing both becaue I like accessors too
23:23:32  <benvie>or using proxies to both provide a functional one and then a proxy wrapped "natural looking" one with stuff as properties
23:23:34  <isaacs>mmalecki: it is in master already, i believe
23:23:52  <mmalecki>isaacs: I'm running master here
23:24:05  <benvie>both currently work
23:24:13  <benvie>the get version a a lazy getter
23:24:18  <isaacs>> require("os").networkInterfaces
23:24:18  <isaacs>[Function]
23:24:18  <benvie>with the deprecation warning
23:24:22  <mmalecki>ah, yeah
23:24:23  <isaacs>mmalecki: yeah, well, that's how we roll :)
23:24:27  * perezdquit (Read error: Connection reset by peer)
23:24:41  <mmalecki>backward compatibility. right.
23:24:42  <isaacs>> os.getNetworkInterfaces()
23:24:42  <isaacs>os.getNetworkInterfaces is deprecated. It is now called `os.networkInterfaces`.
23:24:43  <isaacs>{ lo0:
23:25:28  * perezdjoined
23:25:46  <isaacs>releasing npm 1.1.11
23:25:54  <isaacs>very auspicious version number! lucky!
23:26:00  <benvie>maybe I just like things that hide their internal works, but it's almost like fun to wrap something like the os module in a proxy object that exposes everything as if they were properties
23:26:25  <mmalecki>isaacs: oh, btw, registry replication works even better when I replicate using 1.2
23:26:31  <benvie>but I also see the new for one that doesn't so I'd end up having both
23:26:36  <isaacs>mmalecki: that's not surprising
23:26:40  <isaacs>mmalecki: but it is good news! :)
23:26:46  <mmalecki>couch 1.2 is the best thing since sliced bread, actually
23:27:02  <dylukes>the person who wrote thi...
23:27:15  <dylukes>if (!(handle->flags & UV_HANDLE_BOUND) &&
23:27:15  <dylukes> uv_udp_bind(handle, (struct sockaddr *)&uv_addr_ip6_any_,
23:27:15  <dylukes> sizeof(uv_addr_ip6_any_), 0) < 0) {
23:27:15  <dylukes> return -1;
23:27:15  <dylukes>https://gist.github.com/2165457
23:27:25  <dylukes>ack, sorry
23:27:46  <dylukes>I keep having to switch between ctrl and cmd...
23:28:54  <TooTallNate>isaacs: you should grab the updated node-gyp ;)
23:29:05  <isaacs>d'oh!!
23:29:09  <isaacs>forgot about that.
23:29:16  <isaacs>auspicious version numbers be damned.
23:29:50  <dylukes>Question: Why does Visual studio hate inline typed variables?
23:30:07  <dylukes>struct sockaddr_in addr = uv_ip4_addr("", TEST_PORT);
23:30:09  <dylukes>this is an error.
23:30:10  * mikealquit (Quit: Leaving.)
23:30:10  <dylukes>:|
23:30:26  <isaacs>publishing 1.1.12
23:30:39  <dylukes>doesn't hurt to not declare them inline, but still... what is it? The 1970s?
23:31:50  <benvie>it's state of the art
23:32:18  <dylukes>Visual Studio comes close. The VS debugger? Same. MSVC... not so much.
23:33:06  <benvie>I've heard good things about VS 2011 actually but don't intend to use it and really just hope it makes more things not made for Windows automatically work
23:33:19  <benvie>or whatever the one for windows 8 is called
23:33:24  <benvie>11
23:35:15  <dylukes>:D
23:35:20  <dylukes>+132/-4 tests!
23:35:25  <dylukes>I'll take that as a sign of relative success.
23:35:28  <dylukes>MSVC is great IDE.
23:35:30  <dylukes>Don't get me wrong.
23:35:47  <dylukes>It's probably the best *IDE* out there. (there are better editors, but it's the best IDE).
23:36:33  <dylukes>bnoordhuis: :D
23:36:38  <dylukes>Believe it or not...
23:36:41  <dylukes>It's done!
23:37:15  * travis-cijoined
23:37:15  <travis-ci>[travis-ci] DylanLukes/libuv#5 (ipv46agnostic - 6575c89 : Dylan Lukes): The build is still failing.
23:37:15  <travis-ci>[travis-ci] Change view : https://github.com/DylanLukes/libuv/compare/d074861...6575c89
23:37:15  <travis-ci>[travis-ci] Build details : http://travis-ci.org/DylanLukes/libuv/builds/926204
23:37:15  * travis-cipart
23:37:21  <CIA-99>node: Bryan Cantrill v0.6 * rd125591 / (2 files in 2 dirs): sunos: fix EMFILE on process.memoryUsage() - http://git.io/bf_73A
23:37:35  * travis-cijoined
23:37:35  <travis-ci>[travis-ci] joyent/node#631 (master - e1199fa : Shigeki Ohtsu): The build is still failing.
23:37:35  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/ef046bf...e1199fa
23:37:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/926143
23:37:35  * travis-cipart
23:39:06  <benvie>yeah I actually wouldn't necessarily disagree with that out of hand although my experience with eclipse is better. But I also haven't met and IDE that isn't viscerally slowish nor one that has the syntax highlighting and language parsing customization that I want
23:39:38  <CIA-99>node: isaacs v0.6 * r67f1778 / (126 files in 17 dirs): Upgrade npm to 1.1.12 - http://git.io/uLJeUA
23:39:50  <isaacs>TooTallNate: includes node-gyp 0.3.7 ^
23:40:03  <dylukes>Eclipse is horrible compared to MSVS.
23:40:28  <benvie>specifically it was Aptana's eclipse
23:40:35  <benvie>that I had the best experience
23:41:02  <mmalecki>eclipse is horrible compared to everything. has MSVS changed much since 3 years or so?
23:41:17  * paddybyersquit (Quit: paddybyers)
23:41:17  <dylukes>Eh, 2010 was a pretty big change I think.
23:41:24  <benvie>three years ago 2010 was in beta so
23:41:25  <dylukes>2011 is a huge interface overhaul.
23:41:29  <benvie>if you used 2010 it hasn't =D
23:41:55  <benvie>last time I used vs11 it was the same as 2010 mostly but I'm guessing that changed/
23:42:16  <isaacs>igorzi: ok, just waiting on the last write_cb queue thing
23:42:46  <dylukes>http://www.neowin.net/news/visual-studio-11-gets-new-almost-metro-interface
23:43:09  <dylukes>It's almost Metro... though it looks a lot like Android 4.0
23:43:12  <benvie>ah yes so it changed significantly. I'm guessing it be coming out for windows 7
23:43:19  <benvie>won't be
23:43:42  <mmalecki>you'll need a tablet pc to use it, I assume.
23:43:51  * sh1mmerquit (Quit: sh1mmer)
23:44:09  <benvie>it's for touch development, and I mean using touch to developer and ONLY touch
23:44:09  <mmalecki>(that's how Metro interface looks to me, at least)
23:44:44  <CIA-99>node: isaacs v0.6 * ra7cd76b / (5 files): Remove unused fast-list module from npm - http://git.io/3dkQag
23:44:44  <CIA-99>node: isaacs v0.6 * rd227084 / (5 files in 3 dirs): Upgrade libuv to 8409a67 - http://git.io/2FlajQ
23:44:56  <mmalecki>I actually downloaded the dev preview, but I NOPEd back to my beloved linux after a very short time, so I don't expect anything good from Metro
23:45:07  <benvie>vs11 wasn't usable in Metro and I don't think it'll ever be unless having more than one program open becomes possible. Which will be the same time I actually think about using metro
23:45:12  * travis-cijoined
23:45:12  <travis-ci>[travis-ci] joyent/node#632 (v0.6 - d125591 : Bryan Cantrill): The build passed.
23:45:12  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/ea44d30...d125591
23:45:12  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/926207
23:45:12  * travis-cipart
23:45:59  <benvie>I NOPEd back to Windows 7 which gave you no hope of considering coming from a linux preference
23:46:56  <dylukes>oh snap.
23:46:59  <dylukes>I forgot the benchmarks XD.
23:47:00  <bnoordhuis>isaacs: "That being said, I think node-inspector is not as beneficial as shipping a profiling tool." <- i'm not quite sure how to parse that
23:47:12  <dylukes>bnoordhuis: Ok then! Once I do the benchmarks, this patch will be done :).
23:47:26  <isaacs>bnoordhuis: shipping a profiler is more important than shipping a second debugger client.
23:47:31  <dylukes>Then I just have to keep it up to date with other people's changes in the upstream for a while... any thoughts on when 0.9 will be ready to take the patch?
23:47:37  <bnoordhuis>isaacs: oh right, no disagreement there
23:47:37  <isaacs>bnoordhuis: or is node-inspector also a profiler?
23:47:41  <bnoordhuis>isaacs: yes
23:47:50  * travis-cijoined
23:47:50  <travis-ci>[travis-ci] joyent/node#633 (v0.6 - 67f1778 : isaacs): The build was broken.
23:47:50  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/d125591...67f1778
23:47:50  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/926229
23:47:50  * travis-cipart
23:47:51  <isaacs>bnoordhuis: honestly, i sort of find node-inspector sort of confusing.
23:47:59  <isaacs>the built-in debugger is nice.
23:47:59  <benvie>the profiling api is part of the debugger api
23:48:10  <isaacs>oh, ok. i didn't realize that
23:48:15  <isaacs>i thought it was a separate thing
23:48:22  <bnoordhuis>dylukes: expect at least a couple of weeks
23:48:30  <dylukes>oh wow, that's less then I though :D
23:48:35  <dylukes>I was expect a couple months >.<
23:48:49  <bnoordhuis>dylukes: note my careful use of "at least" :)
23:48:52  <dylukes>heh.
23:48:58  <dylukes>So this definitely can't get in for 0.8?
23:49:03  <bnoordhuis>no
23:49:44  <benvie>I expect some fun new things to be trickling out of the chromium stuff too because the latest canary has a lot of awesome new dev tools
23:50:44  <bnoordhuis>benvie: i confess the only reason i want a profiler in the core is cold calculated self-interest
23:50:48  * avsejquit (Excess Flood)
23:50:50  <benvie>it's one thing to have v8 expose an API and another to have a fully built interface for them
23:50:58  <bnoordhuis>i do a lot of profiling and node-inspector is broken more often than not
23:51:13  <benvie>yeah that's what I was going to say too
23:51:16  <benvie>it's in the API BUT
23:51:22  <benvie>you have to magic it into working too
23:51:25  * avsejjoined
23:51:30  <dylukes>Now, bnoordhuis, realistically, the change is from
23:51:32  <dylukes>uv_udp_bind(handle, addr, 0);
23:51:32  <dylukes>to
23:51:39  <isaacs>bnoordhuis: * 44527e6 deps: upgrade http_parser to joyent/http-parser@b47c44d (Ben Noordhuis)
23:51:46  <dylukes>uv_udp_bind(handle, (struct sockaddr *)addr, sizeof(addr), 0);
23:51:51  <isaacs>bnoordhuis: are you sure that's the right ref? joyent/http-parser@b47c44d?
23:51:56  <igorzi>isaacs: just running tests on the write_cb patch.. once i confirm that there are no issues - i'll land
23:52:08  <dylukes>however, in the case that you're using getaddrinfo (correctly), it's just
23:52:11  <isaacs>igorzi: great
23:52:11  <benvie>I last used node-inspector a couple months ago and as a whole it was...marginally working
23:52:18  <isaacs>bnoordhuis: * b47c44d koichik Fix response body is not read (3 months ago)
23:52:21  <dylukes>uv_udp_bind(handle, ai->addr, ai->addrlen, 0)
23:52:28  <bnoordhuis>isaacs: yes
23:52:30  <mmalecki>!gh joyent/http-parser@b47c44d
23:52:30  <kohai>mmalecki, https://github.com/joyent/http-parser/commit/b47c44d
23:52:32  <dylukes>Seem reasonable?
23:52:49  <bnoordhuis>isaacs: i upgraded the parser in v0.6 from b47c44d^^ to b47c44d
23:53:01  <isaacs>oh, right, duh. v0.6
23:53:02  * travis-cijoined
23:53:02  <travis-ci>[travis-ci] joyent/node#634 (v0.6 - d227084 : isaacs): The build is still failing.
23:53:02  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/67f1778...d227084
23:53:02  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/926261
23:53:02  * travis-cipart
23:53:44  <isaacs>wow, that's super old..
23:53:46  <isaacs>heh
23:53:48  <bnoordhuis>dylukes: the struct sockaddr should be const
23:54:03  <bnoordhuis>dylukes: otherwise i can live with it (probably)
23:54:18  <dylukes>Should it be const?
23:54:30  <dylukes>I don't think so.
23:54:45  <dylukes>bind()/accept()/connect() do not take consts.
23:54:53  <bnoordhuis>do too
23:55:01  <dylukes>No they don't...
23:55:25  <dylukes>Oh weird, it seems to differ by platform.
23:55:30  <dylukes>Let me check the POSIX spec then...
23:55:57  <dylukes>Do you want me to go through every single unit test and include the const in the cast -__-?
23:56:02  <dylukes>Or just put it in the type signature.
23:56:28  <bnoordhuis>dylukes: just the function prototype
23:56:44  <dylukes>can and will do. It's a good idea.
23:57:14  <dylukes>oooh... crap.
23:57:26  <dylukes>I've been writing (struct sockaddr *) everything (note the position of the asterisk).
23:57:51  <dylukes>Well, looks like I'm going to be having fun fixing that now. ^_^