00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:40  * austoquit (Quit: austo)
00:01:57  <trevnorris>groundwater: anyways. that's about it. follow that? I'm updating the docs w/ more examples
00:02:16  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:03:20  <AlexisMocha>tjfontaine: so between the .CRT$XCU issue and stderr sync you are saying that .CRT$XCU is higher priority? I was hoping to get to a vanity 0 failures result for the result, but I guess that's not going to be the case :(
00:03:50  * euoiaquit (Ping timeout: 264 seconds)
00:03:55  <tjfontaine>erm
00:06:27  <tjfontaine>AlexisMocha: so, I've disabled the gc tests so we shouldn't see them for now, the .CRT$XCU issue is higher priority because at least some binary modules will compile but not run (though it's unclear why) and the stderr sync issue is relatively understood and potentially may require more effort and concept changes than we might get in for 0.12 (that being said, I'm ok with an explicit skip in stderr test)
00:06:49  * johannish_joined
00:06:58  * mikolalysenkojoined
00:07:07  * johannishjoined
00:07:11  * johannish_quit (Client Quit)
00:08:04  * rmgjoined
00:11:27  * andrewrkquit (Quit: Leaving)
00:11:44  * johannishpart
00:12:00  * toothrchanged nick to toothrot
00:14:20  * rmgquit (Remote host closed the connection)
00:15:24  * m76quit (Read error: Connection reset by peer)
00:18:14  <groundwater>trevnorris so, i can subscribe to a subset of async events right?
00:18:23  <trevnorris>groundwater: yes.
00:18:48  <trevnorris>groundwater: where this differs from probes is that the call stack will still be preserved in the background for the entire async chain
00:19:10  * kevinsimperjoined
00:19:13  <trevnorris>groundwater: but the callbacks will only be called for the providers (i.e. subset of async events) that you specified
00:19:29  * Kakeraquit (Ping timeout: 240 seconds)
00:19:36  <groundwater>trevnorris so if i only subscribe to PIPE for example, but the callback chain traverses a TCP event, the continuatino won't be lost?
00:21:03  * paulfryzelquit (Remote host closed the connection)
00:21:11  <trevnorris>groundwater: nope. so say addAL(PIPE, ...); net.createServer(8080, fn() { net.createServer('/some/path', fn() { setTimeout(fn() { net.createServer('/other/path', ...
00:21:26  <trevnorris>groundwater: the callbacks will still be called for every PIPE event in that chain.
00:22:05  <tjfontaine>groundwater: are you asking if tcp shows up in a transaction like: pipe.on('connect', function() { net.connect(, function() { pipe.write() }) }), even though you weren't looking for the TCP create?
00:23:27  * rmgjoined
00:23:41  * mikealquit (Quit: Leaving.)
00:24:18  <groundwater>hmm... i think i confused myself
00:24:30  <tjfontaine>to the code example!
00:24:34  <groundwater>no, i get it now
00:24:55  <groundwater>so, from a tracing perspective, i don't see why i'd ever subscribe to a subset of events
00:25:10  <groundwater>not to say that nobody would
00:25:32  <groundwater>also my coffee is not strong enough, so you may be dealing with sleepy-jacob
00:26:58  * mikealjoined
00:31:30  <tjfontaine>man, pummel tests work as described.
00:32:30  * zz_karupanerurachanged nick to karupanerura
00:32:48  <tjfontaine>well here's a useless test now ...
00:33:10  <tjfontaine>https://github.com/joyent/node/blob/master/test/pummel/test-next-tick-loops-quick.js
00:33:39  <trevnorris>hahaha
00:33:40  <trevnorris>yeah
00:52:05  * euoiajoined
00:53:12  * AvianFluquit (Ping timeout: 240 seconds)
00:54:05  <mmalecki>gah, what sane build system puts a static library in .libs/libuv.a by default?
00:54:12  * kazuponjoined
00:54:38  <tjfontaine>heh, good ol autohell
00:55:24  <mmalecki>could we perhaps use AC_CONFIG_LINKS to link/copy them to libuv.a in the root?
00:56:56  <tjfontaine>probably, PRs are reviewed :)
00:57:05  <tjfontaine>I thought it had a versioned one in the root though?
00:58:50  <mmalecki>nope
00:58:54  <mmalecki>it's .gitignore'd
00:59:08  <tjfontaine>right, I think it's expecting you to use .la by default in other dependent apps ;)
01:00:44  <tjfontaine>mmalecki: to be fair, it's expecting you to `make install`
01:01:05  <mmalecki>tjfontaine: I don't want `make install`. I use libuv as a dependedncy in a project
01:01:15  <mmalecki>so I just want to link it statically
01:01:28  <tjfontaine>right so generally you use ".la" and it expects your parent project to be managed by autohell
01:01:48  <mmalecki>and previously with `make` being libuv's build system, I could just run `make -C` and have it output libuv.a
01:02:08  <tjfontaine>in 0.10 we have non-autoconf, in 0.11 it's autoconf
01:02:12  <tjfontaine>in both you have gyp
01:02:17  <groundwater>trevnorris can't say i'm crazy about having an optional argument at the beginning of the add/create calls
01:02:32  <mmalecki>right, but my projects are way too small for gyp/autohell to be useful
01:02:46  <tjfontaine>nod
01:02:57  <groundwater>trevnorris i hope this is the type of feedback you're looking for, i'm just pointing out potential pain points
01:03:05  <trevnorris>groundwater: i can understand that . does make the API look strange.
01:03:14  <trevnorris>and yeah. that's the type of feedback i'm looking for. :)
01:04:29  <trevnorris>the problem is that the userData argument is a Value (i.e. anything) so there's no way to type distinguish between the two. so it'd require an {create,add}AL(callbacks[, userData[, providers]]); API otherwise
01:04:53  <trevnorris>and you'd have to pass null as the userData if you wanted access to the proviers
01:06:41  <groundwater>trevnorris right now i'm thinking about this from the perspective of someone new, someone who doesn't have the history we have, and am trying to think about path of least resistance
01:07:13  <groundwater>ALs are pretty heavy, and i'm thinking about ways to make the JS api easier to digest
01:07:24  <trevnorris>groundwater: yeah. that's a good perspective to take. the API isn't solidified yet, so go ahead and shoot out ideas. :)
01:07:34  <trevnorris>hehe. is there an "easy" way?
01:08:56  <groundwater>trevnorris i'm also not thinking about it from the perspective of "keeping it in sync" with the NR async-listener
01:09:01  <groundwater>what we have works, and we can always keep using that
01:09:19  <groundwater>what you're working on will hopefully be what node *needs*
01:09:28  <trevnorris>yeah
01:09:29  <groundwater>which ultimiately will probably be what we need too
01:10:12  <groundwater>conceptually, i think the 'probe' model that TJ is talking about is easy to understand, but it might be less useful out of the box
01:10:40  <groundwater>i think the add/create async listener might be easiest to explain as "it's a useful wrapper around sets of probes" even if it's not directly implemented that way
01:11:24  <trevnorris>yeah. that's a simpler way of looking at it. problem is that "probes" have an on/off switch. where AL doesn't
01:11:42  <groundwater>trevnorris that's okay, anyone who wants more granularity can dive into the world of probes
01:12:06  <groundwater>this is more like "if you wanna dive in with 'sane defaults' you should use ALs"
01:12:19  <groundwater>it's a loaded gun, but with the safety switch on
01:12:54  <trevnorris>hehe, funny thing is I always thought of them the other way around. AL allows some ridiculous context manipulation. and many more ways to abuse it. :P
01:14:49  * rosskquit
01:14:55  * calvinfo1quit (Quit: Leaving.)
01:15:11  * calvinfojoined
01:18:36  <groundwater>trevnorris they're both a loaded gun
01:18:49  <groundwater>one is loaded with bees, the other is loaded with a grenade
01:18:52  <trevnorris>heh
01:19:12  <groundwater>maybe substack can draw that illustration
01:19:18  <trevnorris>ok. well I've gotta run. keep shooting stuff out as you see it. and i'll catch up w/ the logs later.
01:19:19  <trevnorris>hahaha
01:19:23  * trevnorris&
01:19:29  <trevnorris>....
01:23:32  * indexzeroquit (Quit: indexzero)
01:23:59  * paulfryzeljoined
01:28:27  * paulfryzelquit (Ping timeout: 272 seconds)
01:38:50  <tjfontaine>trevnorris, groundwater: "useful out of the box" is of course where node finds itself in trouble
01:39:09  <tjfontaine>trevnorris, groundwater: what we need to aim for is "useful abstraction that lets users build what we don't want to maintain"
01:40:03  <tjfontaine>trevnorris, groundwater: a good way to look at it is if this meets the goals of the users who were asking for it, and if not if that requires more complexity, can we constrict on what's in core and let the rest be exposed in a user module
01:40:39  * thlorenzjoined
01:41:14  <tjfontaine>from the tracing probe mechanism we're not prescribing how these are to be used, but taking an existing interface that's already known and understood, and extending it with a consumable js api that matches our existing EE pattern
01:41:48  <tjfontaine>so it's less of a knee jerk reaction when people see it
01:43:33  <mmalecki>hmm, I'm getting a pretty mysterious seg fault with uv_queue_work
01:45:00  <tjfontaine>mmalecki: are you calling it from the main event loop thread?
01:46:07  <mmalecki>yup, I am
01:46:10  <mmalecki>let me share some details
01:46:22  <mmalecki>code is here: https://github.com/mmalecki/uv_netmap/tree/debug
01:46:31  <mmalecki>I was just getting started, this is really minimal
01:46:48  <tjfontaine>work_t is going out of scope
01:47:00  <tjfontaine>*work_req
01:47:37  <tjfontaine>it needs to be malloc'd or static to the translation unit
01:47:49  <mmalecki>ohhh
01:48:13  <mmalecki>hmm, so I need to fix uv book examples :)
01:48:17  <mmalecki>thanks tjfontaine
01:48:22  <tjfontaine>yw
01:49:22  <MI6>joyent/node: Timothy J Fontaine merge-review * 78a854f : test: move pummel/test-fs-largefile to disabled (+3 more commits) - http://git.io/htHekQ
01:54:14  * ik_joined
01:54:14  * ik_quit (Client Quit)
02:02:38  * AWintermanquit (Ping timeout: 264 seconds)
02:02:57  * calvinfo1joined
02:05:15  * calvinfoquit (Ping timeout: 244 seconds)
02:05:42  <groundwater>tjfontaine perhaps you can answer this, can {create/add}AsyncListener be implemented completely on top of tracing probes?
02:06:05  <tjfontaine>groundwater: I guess that depends on what you mean by tracing probes
02:06:25  * mikealquit (Quit: Leaving.)
02:06:46  <tjfontaine>so keep in mind, that the static probes actually have the ability to "fix" the scenario of the disconnect between createServer vs listen
02:06:46  * rmgquit (Read error: Connection reset by peer)
02:07:01  * rmgjoined
02:07:01  <groundwater>tjfontaine right, well ALs suffer from that problem as well
02:07:19  <tjfontaine>no I mean, this can fix that problem, because I can put the probe exactly in the constructor of Server
02:07:21  <groundwater>we typically patch EEs, or bind callbacks in order to recover from that problem
02:07:31  <groundwater>right!
02:07:50  <tjfontaine>AL gives you the information about when the actual binding time happens
02:08:05  <tjfontaine>which can also be very important, but the static probes are far more surgical
02:08:11  <groundwater>tjfontaine are you still doing the onAsync(...) probe idea?
02:08:17  <groundwater>sorry that's waht i was commenting on
02:09:06  <tjfontaine>so, really (I think) what we want is a combination of static probes and a trimmed down AL
02:09:33  <groundwater>tjfontaine yes, sounds reasonable
02:09:54  <groundwater>from a user perspective, ALs could just be probes
02:09:55  <tjfontaine>technically we can iteratively add static probes through patch releases
02:10:52  <tjfontaine>the information gleaned from AW is very important though, and is the only sane way to capture that data
02:11:48  <tjfontaine>I hadn't pursued onAsync because it feels somewhat wrong to expose *both* addAL and that
02:12:32  <groundwater>tjfontaine right, i get it now
02:12:40  <groundwater>sorry had been out of sync
02:15:06  <tjfontaine>also, because there are two schools of thought on how to consume this data, clearly something like what we have in AL and something along the lines of my onAsync idea, it makes me wonder what the minimum common feature set between the two needs to be exposed such that we can vet both ideas external to the core
02:16:30  <groundwater>tjfontaine yes, i like that
02:16:46  <groundwater>i think othiym23 brought up a very good point
02:17:01  <groundwater>without passing an object through from create to before/after, we have a GC problem
02:17:18  <groundwater>seems to me that is part of the 'minimal set'
02:17:26  <tjfontaine>can you expand upon that further?
02:18:16  <groundwater>if we tracked async events by 'id'
02:18:26  <groundwater>and stored associated objects in a global hash, indexed by the id
02:18:41  <groundwater>we don't know when we can GC the item stored in the hash
02:18:54  * loladiroquit (Quit: loladiro)
02:18:59  <tjfontaine>not without a stable notification of delete
02:19:36  <tjfontaine>fwiw, if we were to use a uuid for the handle, passing that back out on destructor is reasonably achievable -- as opposed to giving you back the real object to delete
02:19:42  <groundwater>tjfontaine so thinking back, i think firing the probe with the handle as one of the arguments can side-step the requirement for having an 'id'
02:20:09  <groundwater>that's kind of what we're doing, but not exposing
02:20:12  <tjfontaine>what I'm also somewhat worried about is just how much persistent state this pushes into core, such that we may uninentionally start holding on to things logner than necessary
02:20:40  <tjfontaine>groundwater: passing the handle instead of the id solves most of everything except of being notified when the handle is being deallocated
02:20:48  * rmgquit
02:20:58  <groundwater>tjfontaine if i store my stuff *on* the handle, it shouldn't matter
02:21:19  <tjfontaine>groundwater: sure, but passing the handle doesn't solve the problem of you not wrapping the createServer call
02:21:34  <tjfontaine>groundwater: what we (all) would like is for you to *not* have to monkey patch core
02:22:00  <groundwater>oh, right because the handle is created asynchronously?
02:22:03  <tjfontaine>yes
02:22:26  <groundwater>well isnt' the handle just an object, and the fd is really what happens asyncronously?
02:22:38  <tjfontaine>not exactly (unfortunately)
02:22:40  <groundwater>can we just create the object, and fill in .fd after?
02:24:21  <tjfontaine>can? yes, it's all just software :)
02:24:25  <tjfontaine>but that is a very high touch change
02:24:31  <groundwater>lol
02:24:39  <groundwater>understood
02:24:44  * paulfryzeljoined
02:24:48  <groundwater>i mean the change doesn't *feel* wrong
02:25:31  <groundwater>but i don't have a good feel for how easy/hard the change is
02:29:15  * paulfryzelquit (Ping timeout: 272 seconds)
02:30:06  <groundwater>tjfontaine can you link me to the potential async part of createServer?
02:30:35  <tjfontaine>sure
02:32:11  <tjfontaine>well, ok let me rephase such that you're clear on what we mean by async
02:32:29  <tjfontaine>well what I meant
02:32:32  <tjfontaine>the handle is *never* created until .listen
02:32:57  <tjfontaine>https://github.com/joyent/node/blob/master/lib/net.js#L1045
02:33:14  <tjfontaine>then maintains the logic for when we `new TCP()` or etc
02:34:30  <groundwater>tjfontaine i think right now, a long stack trace with our AL shim will be called on .listen
02:34:36  <tjfontaine>it will, yes
02:34:36  <groundwater>so that is consistent
02:35:00  <tjfontaine>what most people want (at least imo) is to be notified when Server has been instantiated
02:35:50  <groundwater>so not .listen, but 'new Server()'
02:36:17  <tjfontaine>to me that seems like what actually is interesting
02:37:07  <groundwater>so we're (newrelic) definitely not requiring that
02:37:12  <groundwater>not that someone else wouldn't
02:37:35  <tjfontaine>sure, but from an associative point I can see why it would be the spot that makes sense
02:38:22  <tjfontaine>if you're the kind of person looking for "where this server was created" that's the information you want, not when .listen was called -- granted for most people that's only a few lines of difference
02:39:20  <groundwater>well the createServer probe could always return the server object
02:39:31  <groundwater>and i could correlate that to the .listen event
02:39:36  <MI6>joyent/node: Timothy J Fontaine merge-review * de56ffa : test: pummel/*ci-reneg* handle EPIPE (+1 more commits) - http://git.io/riEqUw
02:39:36  <groundwater>in 'userland'
02:47:38  <groundwater>i mean, right now with ALs doesn't it occur on .listen
02:47:44  <groundwater>the onAsync call
02:47:56  <tjfontaine>all these async words
02:48:01  <groundwater>lol
02:48:02  <tjfontaine>yes, al fires in he .listen
02:48:17  <groundwater>so passing the handle is consistent
02:48:22  <groundwater>and firing on .listen
02:48:27  <tjfontaine>yup
02:48:55  <groundwater>all i'm saying is that the 'minimal feature set' might include passing the handle to userland
02:49:00  <groundwater>vs. passing a storage object
02:49:02  <tjfontaine>sure
02:49:55  <tjfontaine>I mean, that's already happening in the implementation as it is in trevors latest changes
02:50:57  <groundwater>is that 'context'?
02:51:06  * jmar777joined
02:51:35  <tjfontaine>yes
02:51:44  <groundwater>what i mean is that passing 'userData' can be done out of core, if you pass the handle to create, along with before/after
02:52:17  <tjfontaine>presuming everyone gets around the 'ick' feeling of storing it on the handle
02:52:38  <groundwater>my understanding is that the return value of create is the 'userData' which, currently implemented, gets attached to the handle object
02:52:59  <groundwater>so it's happening anyways
02:53:09  <groundwater>and if i recall, you said the JIT can't optimize the handle anyways
02:53:39  <tjfontaine>the handle is generally a c++ instantiated object, so there's little to optimize (mostly)
02:54:03  * jmar777quit (Remote host closed the connection)
02:54:06  <groundwater>would *you* let that change through? knowing people would append to the handle
02:54:40  <tjfontaine>name spacing would be important for users attaching to the handle, and they coudln't be angry with us if stomp on their keys ;)
02:55:10  <groundwater>do you want that enforced by convention, or by construction?
02:55:17  <groundwater>i.e. just a line "PREFIX YOUR SHIT"
02:55:28  <tjfontaine>I would want that by convention, ideally
02:55:37  <tjfontaine>it can be expensive to "freeze" or equivalent
02:55:38  <groundwater>because maybe not all AL callbacks want to actually mutate handle
02:56:19  <groundwater>so tell people to prefix their module name, for example
02:56:43  <groundwater>__newrelic_bag_o_fun
02:57:35  <tjfontaine>right
03:01:32  <groundwater>so that's my vote
03:01:38  <groundwater>if we're searching for a minimal feature set
03:01:47  <tjfontaine>ok
03:01:53  * AlexisMochaquit (Ping timeout: 246 seconds)
03:02:04  * paulfryzeljoined
03:06:37  * paulfryzelquit (Ping timeout: 272 seconds)
03:06:55  * brsonquit (Quit: leaving)
03:08:34  * AWintermanjoined
03:08:53  * Ralithquit (Ping timeout: 246 seconds)
03:08:56  * kazuponquit (Remote host closed the connection)
03:14:13  * AWintermanquit (Ping timeout: 272 seconds)
03:33:07  * kevinsimperquit (Remote host closed the connection)
03:34:00  * piscisaureusjoined
03:34:12  * Ralithjoined
03:37:44  * paulfryzeljoined
03:42:35  * andrewrkjoined
03:42:43  * paulfryzelquit (Ping timeout: 272 seconds)
03:51:04  <MI6>joyent/node: Timothy J Fontaine merge-review * 77a6ea0 : tools: wrk update to 5b2fa06 (+1 more commits) - http://git.io/sXYWQQ
03:51:35  * piscisaureusquit (Ping timeout: 246 seconds)
03:57:54  * kazuponjoined
03:59:58  * kazuponquit (Remote host closed the connection)
04:01:13  * kazuponjoined
04:21:00  <MI6>joyent/node: Timothy J Fontaine merge-review * 102399e : wrk: build against our distributed ssl - http://git.io/dABwEw
04:27:06  <MI6>joyent/node: Timothy J Fontaine merge-review * 4bba651 : wrk: build against our distributed ssl - http://git.io/dSAIqw
04:31:08  * euoiaquit (Ping timeout: 246 seconds)
04:31:26  <MI6>joyent/node: Timothy J Fontaine merge-review * f6b5fc1 : wrk: build against our distributed ssl - http://git.io/cRDAtw
04:38:29  * paulfryzeljoined
04:40:17  * loladirojoined
04:40:45  * jmar777joined
04:41:18  * thlorenzquit (Remote host closed the connection)
04:41:53  * thlorenzjoined
04:43:31  * paulfryzelquit (Ping timeout: 272 seconds)
04:46:26  * thlorenzquit (Ping timeout: 264 seconds)
04:48:36  <tjfontaine>I wish I could find a convenient way to serially run phases of a matrix job across a specific axis
04:51:19  * thlorenzjoined
04:53:06  * thlorenzquit (Remote host closed the connection)
04:55:09  <MI6>joyent/node: Timothy J Fontaine merge-review * 1e182e1 : wrk: compile on sunos - http://git.io/dChnWw
05:00:15  <MI6>joyent/node: Timothy J Fontaine merge-review * fd17587 : wrk: compile on sunos - http://git.io/EYVaYg
05:04:44  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:33:58  * kevinsimperjoined
05:38:41  * kevinsimperquit (Ping timeout: 246 seconds)
05:39:09  * paulfryzeljoined
05:42:02  * thlorenzjoined
05:44:19  * paulfryzelquit (Ping timeout: 272 seconds)
05:45:00  * calvinfo1quit (Quit: Leaving.)
05:53:47  <trevnorris>groundwater: yes the userData is attached to the context via ._asyncData. also know that the "context" passed is not the Server() object, but the ._handle object attached to the server instance.
05:54:12  * calvinfojoined
05:54:22  <trevnorris>it directly exposes Node's entrails.
05:57:14  * Hewhokayaksjoined
05:57:23  <trevnorris>groundwater tjfontaine: if you wan to have users maintain a userData state outside of AL, each context can easily be given a uid (already done for AL) and then I can queue a callback passing that uid to the user in the destructor.
05:57:28  <trevnorris>*want
05:58:51  * piscisaureusjoined
06:00:30  * Hewhokayaksquit (Remote host closed the connection)
06:00:32  <trevnorris>groundwater: as tjfontaine said, if a user wants to know when Server() is created, that's a totally different story. Unfortunately that is almost the only case in core code where the C++ class isn't instantiated w/ the JS object.
06:01:18  <trevnorris>groundwater: the only way around it is if we combined PipeWrap and TCPWrap (which, i'm not for). the other case is timers. those little bastards are the bane of my existence.
06:02:34  <trevnorris>groundwater: though I do have to say that I was hit with a bolt of inspiration just before leaving the office, and I now have a way to complete a feature that has been bothering me for weeks.
06:06:09  * kenperkinsjoined
06:10:04  * thlorenzquit (Remote host closed the connection)
06:10:39  * thlorenzjoined
06:13:12  * kenperkinsquit (Quit: Computer has gone to sleep.)
06:15:21  * thlorenzquit (Ping timeout: 272 seconds)
06:27:01  * kenperkinsjoined
06:27:08  * jmar777quit (Remote host closed the connection)
06:33:47  * kazuponquit (Read error: Connection timed out)
06:34:53  * kazuponjoined
06:45:56  * mikealjoined
06:50:30  * dshaw_joined
07:04:06  * Damn3dquit (Ping timeout: 245 seconds)
07:06:56  * petka_joined
07:18:42  * Damn3djoined
07:23:33  * kenperkinsquit (Quit: Computer has gone to sleep.)
07:26:50  * mikolalysenkoquit (Ping timeout: 246 seconds)
07:34:15  * calvinfoquit (Quit: Leaving.)
07:37:46  * guilleiguaranquit (Quit: Connection closed for inactivity)
07:40:31  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
07:40:44  * paulfryzeljoined
07:45:55  * paulfryzelquit (Ping timeout: 272 seconds)
08:00:50  * dshaw_quit (Read error: Connection reset by peer)
08:02:24  * dshaw_joined
08:06:50  * janjongboomjoined
08:11:02  * kevinsimperjoined
08:14:00  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:16:18  * mikolalysenkojoined
08:21:27  * mikolalysenkoquit (Ping timeout: 267 seconds)
08:32:48  * kenperkinsjoined
08:32:52  * kenperkinsquit (Client Quit)
08:41:37  * paulfryzeljoined
08:45:33  * raffikiquit (Remote host closed the connection)
08:46:05  * paulfryzelquit (Ping timeout: 272 seconds)
08:52:34  * dshaw_quit (Quit: Leaving.)
09:05:13  * dshaw_joined
09:12:59  * janjongboomjoined
09:17:05  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 2f58bb6 : unix, windows: map ERANGE errno - http://git.io/beBj4g
09:17:44  * mikolalysenkojoined
09:18:01  <saghul>indutny: morning!
09:18:06  <indutny>morning, man
09:18:11  <indutny>how are you?
09:18:26  <saghul>good, you? btw, great article yesterday ;-)
09:18:40  <saghul>when you can, have a look at this proposal: https://github.com/joyent/libuv/issues/446
09:18:43  <indutny>oh, thank you
09:19:24  <indutny>yeah
09:19:25  <indutny>looks good
09:20:00  <saghul>kewl, I'll work on that tonight then
09:22:26  * mikolalysenkoquit (Ping timeout: 264 seconds)
09:30:12  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:42:18  * paulfryzeljoined
09:44:10  * hzjoined
09:47:31  * paulfryzelquit (Ping timeout: 272 seconds)
09:49:34  * janjongboomjoined
09:50:21  <MI6>joyent/libuv: Saúl Ibarra Corretgé v0.10 * 6f98f4e : unix, windows: map ERANGE errno - http://git.io/wnsdIQ
09:51:30  * Kakerajoined
10:07:59  * `3rdEdenjoined
10:08:23  * `3rdEdenchanged nick to Guest49821
10:08:30  * Guest49821changed nick to V1
10:08:45  * V1changed nick to `3rdEden
10:17:59  * mikolalysenkojoined
10:22:52  * mikolalysenkoquit (Ping timeout: 246 seconds)
10:41:06  * kazupon_joined
10:41:10  * kazuponquit (Read error: Connection reset by peer)
10:49:37  * lgierthjoined
10:57:03  * dshaw_quit (Quit: Leaving.)
11:02:00  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 7ad8f74 : unix, windows: set required size on UV_ENOBUFS - http://git.io/PEHH-g
11:25:07  * dshaw_joined
11:29:12  * dshaw_quit (Ping timeout: 240 seconds)
11:31:57  * daviddiasjoined
11:33:33  * dshaw_joined
11:35:48  * kazupon_quit (Remote host closed the connection)
11:36:14  * kazuponjoined
11:41:02  * kazuponquit (Ping timeout: 264 seconds)
11:42:24  * dshaw_quit (Ping timeout: 240 seconds)
11:52:04  * lgierthquit (Quit: Ex-Chat)
12:17:31  * AlexisMochajoined
12:21:10  * mikolalysenkojoined
12:24:42  * sinclair|workjoined
12:25:46  * mikolalysenkoquit (Ping timeout: 244 seconds)
12:32:44  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:34:43  * sinclair|workquit (Quit: ChatZilla [Firefox 27.0.1/20140212131424])
12:44:48  * paulfryzeljoined
12:49:17  * paulfryzelquit (Ping timeout: 272 seconds)
12:51:01  * janjongboomjoined
12:54:39  * karupanerurachanged nick to zz_karupanerura
13:05:18  * loladiropart
13:14:23  * AlexisMochaquit (Write error: Connection reset by peer)
13:20:01  * janjongboomquit (Ping timeout: 244 seconds)
13:21:03  * janjongboomjoined
13:21:53  * mikolalysenkojoined
13:23:15  * euoiajoined
13:23:15  * thlorenzjoined
13:23:22  <indutny>hey people
13:23:54  * thlorenzquit (Remote host closed the connection)
13:27:14  * mikolalysenkoquit (Ping timeout: 264 seconds)
13:33:19  * rosskjoined
13:45:23  * paulfryzeljoined
13:47:38  * thlorenzjoined
13:47:42  * kenperkinsjoined
13:47:56  * kenperkinsquit (Client Quit)
13:48:11  * euoiaquit (Ping timeout: 272 seconds)
13:50:05  * paulfryzelquit (Ping timeout: 272 seconds)
13:54:59  * guilleiguaranjoined
14:01:04  * euoiajoined
14:15:46  * guybrushquit (Excess Flood)
14:16:12  * guybrushjoined
14:20:02  * janjongboomquit (Ping timeout: 264 seconds)
14:21:36  * janjongboomjoined
14:22:49  * mikolalysenkojoined
14:23:47  * kazuponjoined
14:27:42  * mikolalysenkoquit (Ping timeout: 244 seconds)
14:30:00  * kenperkinsjoined
14:41:18  * kenperkinsquit (Remote host closed the connection)
14:41:56  * kenperkinsjoined
14:42:25  * hz_joined
14:42:29  * hzquit (Disconnected by services)
14:42:30  * hz_changed nick to hz
14:42:54  * thlorenzquit (Remote host closed the connection)
14:43:27  * thlorenzjoined
14:45:42  * kenperkinsquit (Client Quit)
14:46:13  * kazuponquit (Remote host closed the connection)
14:47:50  * thlorenzquit (Ping timeout: 246 seconds)
14:53:27  * kenperkinsjoined
14:53:35  * kevinsimperquit
15:00:36  * austojoined
15:09:48  * kenperkinsquit (Quit: Computer has gone to sleep.)
15:11:00  * kazuponjoined
15:12:03  * thlorenzjoined
15:19:58  * paulfryzeljoined
15:23:29  * mikolalysenkojoined
15:24:20  * m76joined
15:25:30  * AlexisMochajoined
15:26:18  * xaqjoined
15:28:14  * sblom_quit (Ping timeout: 252 seconds)
15:28:15  * sblomjoined
15:28:53  * mikolalysenkoquit (Ping timeout: 272 seconds)
15:29:22  * dap_joined
15:29:30  * mikolalysenkojoined
15:39:23  <AlexisMocha>indutny tjfontaine: I have a question about https://github.com/joyent/node/issues/7116
15:39:29  <indutny>sure
15:39:30  <indutny>shoot
15:50:28  * AvianFlujoined
15:50:53  * janjongboomquit (Ping timeout: 244 seconds)
15:52:08  * janjongboomjoined
15:55:46  * mcavagequit (Read error: Connection reset by peer)
15:55:54  * mcavagejoined
16:01:46  * kazuponquit (Remote host closed the connection)
16:02:13  * kazuponjoined
16:03:12  * kenperkinsjoined
16:05:04  * jmar777joined
16:06:23  * kazuponquit (Ping timeout: 244 seconds)
16:08:23  * dazldquit (Ping timeout: 252 seconds)
16:10:04  * kenperkinsquit (Quit: Computer has gone to sleep.)
16:14:39  * dcrostajoined
16:15:25  * dazldjoined
16:16:47  * kpdeckerquit (Read error: Connection reset by peer)
16:17:15  * kpdeckerjoined
16:18:04  * xaqquit (Remote host closed the connection)
16:30:07  * daviddiasquit (Remote host closed the connection)
16:33:08  <MI6>joyent/node: Mike Pennisi v0.10 * aae51ec : assert: Ensure reflexivity of deepEqual - http://git.io/fDt86g
16:35:38  * xaqjoined
16:40:45  * mikealquit (Read error: Connection reset by peer)
16:43:08  * AWintermanjoined
16:43:52  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:46:11  * petka_quit (Quit: Connection closed for inactivity)
16:46:57  * hzquit
16:48:17  * dap_quit (Quit: Leaving.)
16:51:28  <defunctzombie>Error: read ECONNRESET
16:51:28  <defunctzombie> at errnoException (net.js:901:11)
16:51:28  <defunctzombie> at TCP.onread (net.js:556:19)
16:51:28  <defunctzombie> at fireErrorCallbacks (net.js:440:15)
16:51:28  <defunctzombie> at Socket._destroy (net.js:472:3)
16:51:33  * dap_joined
16:51:41  <defunctzombie>looking for a way to track down that ECONNRESET
16:51:47  <defunctzombie>it bubbles up to the top level of my app
16:51:49  <defunctzombie>and crashes it
16:52:04  <defunctzombie>v0.10.22
16:56:32  <defunctzombie>actually looking for any tips of reproducing ECONNRESET errors
16:56:47  * dubbanjoined
16:59:33  * brsonjoined
17:06:57  * dap_quit (Quit: Leaving.)
17:08:31  <AvianFlu>defunctzombie: well, for starters, that means one of your external TCP connections sent you an RST
17:08:47  <AvianFlu>might mean an external service crashed, or you got a timeout, or somebody tripped over a network cable in a datacenter
17:08:51  <AvianFlu>it's hard to say more without knowing more
17:08:55  <defunctzombie>AvianFlu: sure
17:08:56  <AvianFlu>but look for that kind of thing
17:09:03  <defunctzombie>is there a way to can make a script to send an RST ?
17:09:24  <AvianFlu>yeah, make an external service accept a connection and then like, socket.destroy()
17:09:30  <AvianFlu>or just make it exit
17:09:36  <defunctzombie>will that do it?
17:09:53  <AvianFlu>making the external service exit is probably a pretty good way to send an RST
17:09:54  * dap_joined
17:10:03  <defunctzombie>k.. will try that and see if I can't track down the specific failure location
17:10:07  <AvianFlu>.destroy() might, but there's like 3 ways to end a socket and I haven't tested it
17:10:42  <AvianFlu>you could also use some lower-level language and make your own custom packet, but like ERABBITHOLE
17:10:59  <tjfontaine>AlexisMocha: what's your question? :)
17:11:16  <AlexisMocha>tjfontaine: hi
17:11:18  <AlexisMocha>two questions
17:11:23  <tjfontaine>AlexisMocha: hit me
17:11:37  <indutny>tjfontaine: literally?
17:11:40  <AlexisMocha>why are we using the CRT section in the first place? are we hoping to be able to do this in plain C?
17:11:42  <tjfontaine>indutny: :)
17:12:03  <tjfontaine>AlexisMocha: indeed, we are going to be having a pure C interface in 0.13
17:12:37  * kazuponjoined
17:13:08  <AlexisMocha>ok, second question: are we allowing multiple NODE_MODULE declarations in the same dll?
17:14:13  <indutny>AlexisMocha: I don't see any reason to not allow it
17:14:19  <tjfontaine>AlexisMocha: externally, unclear -- I had talked about it, there's not a clear use case for at the moment, but seems like there should be no reason not to allow it
17:15:15  <tjfontaine>AlexisMocha: question for you, why does this work for node.exe but not binding.node? :)
17:16:06  <AlexisMocha>what do you mean "this work for node.exe"?
17:16:35  <tjfontaine>AlexisMocha: currently, our internal modules are loaded with the CRT$XCU section
17:16:53  <tjfontaine>AlexisMocha: but it's only on the loadable assets that this section is missing
17:17:10  * kazuponquit (Ping timeout: 244 seconds)
17:19:45  * dcrostaquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:20:52  <AlexisMocha>tjfontaine: not sure, maybe it's VS2013?
17:21:11  <tjfontaine>AlexisMocha: we build on 2010
17:21:28  <AlexisMocha>exactly, maybe if we built on 2013 we would have a surprise
17:22:02  <tjfontaine>heh, I think I need to turn up the compiler verbosity -- it seems likely that something we're passing to cl.exe or link.exe is incompatible
17:22:10  <AlexisMocha>anyway, even if we allowed multiple NODE_MODULE in one dll, the module name would have to be unique, correct? If so, I think I know a way to fix thi
17:22:11  <AlexisMocha>s
17:22:37  <tjfontaine>well each module just needs to call node_module_register with a valid structure
17:22:43  <AlexisMocha>the linker is simply optimizing that stuff away because it doesn't think it's referenced
17:23:14  <tjfontaine>right ok
17:23:53  <AlexisMocha>and it's hard to force it to preserve them because they are declared as static
17:24:24  <AlexisMocha>but i think i can use the module name to strigize a unique global per module, and force that to be included
17:24:29  <AlexisMocha>lemme try that
17:27:51  * kenperkinsjoined
17:43:25  * dap_1joined
17:43:25  * dap_quit (Read error: No route to host)
17:49:28  * kenperkinsquit (Quit: Computer has gone to sleep.)
17:51:45  * indexzerojoined
17:54:40  * xaqquit (Remote host closed the connection)
17:58:26  * Ralithquit (Ping timeout: 264 seconds)
18:03:50  <MI6>joyent/node: orangemocha created branch orangemocha-ModuleReg - http://git.io/410ZQQ
18:04:03  * dcrostajoined
18:04:07  * dcrostapart
18:06:59  <tjfontaine>AlexisMocha: hmm, the dllexport alone I take it wasn't enough?
18:07:04  * bajtosjoined
18:07:09  * thlorenzquit (Read error: Connection reset by peer)
18:07:14  <AlexisMocha>needed to be non-static
18:07:29  * thlorenzjoined
18:07:30  <AlexisMocha>and hence have a unique name if we were going to allow multiple ones
18:08:00  <AlexisMocha>tjfontaine: .
18:08:01  <tjfontaine>right
18:08:29  <tjfontaine>AlexisMocha: locally you know about `test-gc` as an argument to vcbuild.bat?
18:09:04  <AlexisMocha>tjfontaine: never heard of it
18:11:40  * AWinterm_joined
18:16:55  * calvinfojoined
18:17:02  <tjfontaine>indutny: https://github.com/joyent/node/compare/master...merge-review
18:17:25  <indutny>ouch
18:18:12  <indutny>tjfontaine: https://github.com/joyent/node/compare/master...merge-review#diff-68a49458f9862e08f0c577c5e81a4c70R96
18:18:26  <indutny>why case 'ECONNRESET' if you are doing assert below?
18:18:52  <indutny>its in many places
18:19:20  <tjfontaine>indutny: it could be just assert(false), but having the name of the code is helpful, in practice it won't be anything other than EPIPE or ECONNRESET (depending on if write or read failed)
18:19:31  <indutny>well
18:19:37  <indutny>I mean you could just remove that `case`
18:19:44  <indutny>and check it in assert
18:19:46  <indutny>that's fine
18:19:48  <tjfontaine>using .equal means I can see the code
18:19:48  <indutny>otherwise LGTM
18:19:57  <indutny>I understand
18:20:04  <indutny>I just stress another point a bit :)
18:20:09  * indexzeroquit (Quit: indexzero)
18:20:10  <tjfontaine>hehe
18:20:33  * AWintermanquit (Write error: Broken pipe)
18:20:57  * guilleiguaranquit (Ping timeout: 279 seconds)
18:22:26  * andrewrkquit (Excess Flood)
18:22:54  * jan____quit (Ping timeout: 983 seconds)
18:23:27  * guilleiguaranjoined
18:23:29  * andrewrkjoined
18:24:16  * jan____-joined
18:24:19  * jan____-changed nick to jan____
18:25:49  * thlorenzquit (Remote host closed the connection)
18:27:03  * TooTallNatejoined
18:27:21  * Ralithjoined
18:32:03  * AlexisMocha_joined
18:34:52  * stagasjoined
18:38:11  * thlorenzjoined
18:44:28  * rosskquit
18:48:11  * daviddiasjoined
18:50:34  * piscisaureusjoined
18:51:28  * dshaw_joined
18:51:31  * kenperkinsjoined
18:52:45  * daviddiasquit (Ping timeout: 244 seconds)
18:55:33  * AlexisMocha_quit (Read error: Connection reset by peer)
18:55:38  * dshaw_quit (Ping timeout: 246 seconds)
18:57:21  * daviddiasjoined
18:59:38  * mikolalysenkoquit (Ping timeout: 264 seconds)
19:00:33  * brsonquit (Quit: leaving)
19:01:13  * brsonjoined
19:02:31  * Raynosquit (Ping timeout: 265 seconds)
19:03:04  * brsonquit (Client Quit)
19:04:04  * mikolalysenkojoined
19:04:20  * Raynos_joined
19:05:35  * paulfryz_joined
19:07:18  * paulfryz_quit (Read error: Connection reset by peer)
19:07:22  * paulfry__joined
19:07:26  * nickleefly___quit (Ping timeout: 245 seconds)
19:07:31  * paulfryzelquit (Read error: Connection reset by peer)
19:09:06  * rphillipsquit (Ping timeout: 245 seconds)
19:09:44  * rphillipsjoined
19:10:21  * Raynos_quit (Ping timeout: 245 seconds)
19:11:29  * nickleefly___joined
19:14:05  * Raynos_joined
19:19:00  <MI6>joyent/node: Alexis Campailla orangemocha-ModuleReg * 1312a7b : windows: fix module registration - http://git.io/IbpHwg
19:27:17  * kenperkinsquit (Quit: Computer has gone to sleep.)
19:28:09  * kenperkinsjoined
19:33:10  <MI6>joyent/node: Timothy J Fontaine merge-review * 6e0837f : test: pummel/net-connect-econnrefused backoff (+7 more commits) - http://git.io/1BdAXg
19:33:58  * m76quit (Read error: Connection reset by peer)
19:48:20  * mikealjoined
19:51:12  * xaqjoined
19:52:53  * indexzerojoined
19:53:14  * indexzeroquit (Client Quit)
19:55:54  * paulfry__quit (Remote host closed the connection)
20:00:27  * dshaw_joined
20:01:38  * xaqquit (Remote host closed the connection)
20:01:43  * prettymuchbrycejoined
20:01:58  * bajtosquit (Quit: bajtos)
20:06:10  * kenperkinsquit (Remote host closed the connection)
20:06:46  * kenperkinsjoined
20:08:24  * Damn3dquit (Ping timeout: 240 seconds)
20:08:32  * bajtosjoined
20:10:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:11:42  * kevinsimperjoined
20:14:59  * Damn3djoined
20:14:59  * Damn3dquit (Changing host)
20:14:59  * Damn3djoined
20:15:48  * m76joined
20:16:20  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:16:52  * dsantiagoquit (Quit: Leaving...)
20:19:14  * dshaw_quit (Quit: Leaving.)
20:21:39  * dshaw_joined
20:21:48  * rosskjoined
20:22:21  * TooTallNatejoined
20:26:34  * paulfryzeljoined
20:37:51  * dsantiagojoined
20:41:35  * bajtosquit (Quit: bajtos)
20:46:40  * daviddiasquit (Remote host closed the connection)
20:48:29  * dshaw_quit (Quit: Leaving.)
20:50:49  * dshaw_joined
20:54:31  * rosskquit (Read error: Connection reset by peer)
20:55:28  * AWintermanjoined
20:56:30  * jmar777_joined
20:59:02  * AWinterm_quit (Ping timeout: 264 seconds)
20:59:12  * jmar777quit (Ping timeout: 240 seconds)
20:59:32  * rosskjoined
21:03:07  * kenperkinsquit (Quit: Computer has gone to sleep.)
21:03:26  * prettymuchbrycequit (Quit: prettymuchbryce)
21:05:36  * daviddiasjoined
21:12:09  * daviddiasquit
21:15:10  * prettymuchbrycejoined
21:15:18  * daviddiasjoined
21:17:45  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
21:20:04  * mikealquit (Quit: Leaving.)
21:24:25  * AWinterm_joined
21:25:08  <MI6>joyent/node: Alexis Campailla merge-review * 2155e3a : windows: fix module registration (+3 more commits) - http://git.io/wWjPGQ
21:25:41  * AWintermanquit (Ping timeout: 244 seconds)
21:25:59  * euoiaquit (Remote host closed the connection)
21:27:08  * mikealjoined
21:28:05  * AWinterm_quit (Remote host closed the connection)
21:28:31  * TooTallNatejoined
21:31:01  <tjfontaine>hmm I had a question for you nate, but I forget now
21:32:32  * hzjoined
21:32:43  * xaqjoined
21:44:19  * dshaw_quit (Quit: Leaving.)
21:44:29  * mikealquit (Quit: Leaving.)
21:45:34  * mikealjoined
21:45:44  <MI6>joyent/node: Alexis Campailla merge-review * b5f9779 : windows: fix module registration (+2 more commits) - http://git.io/btIjmg
21:45:45  * jan____quit (Changing host)
21:45:45  * jan____joined
21:46:11  * saghul_joined
21:48:53  * saghulquit (Ping timeout: 272 seconds)
21:50:02  * mikealquit (Ping timeout: 264 seconds)
21:53:18  * AWintermanjoined
21:53:24  * dshaw_joined
21:54:40  * xaqquit (Remote host closed the connection)
21:57:11  * bajtosjoined
21:58:39  * brsonjoined
22:02:23  <MI6>joyent/node: Alexis Campailla master * b5f9779 : windows: fix module registration (+14 more commits) - http://git.io/Obfj3g
22:04:21  * wolfeidauquit
22:05:17  <tjfontaine>AlexisMocha: thanks, we're down to just those 2 tests on master now, stderr and vm recursion [both of which in the short term I am ok with punting on if we want to get a green board]
22:10:33  * mcavagequit (Remote host closed the connection)
22:10:59  * mcavagejoined
22:11:44  * wolfeidaujoined
22:12:14  <AlexisMocha>tjfontaine: 1) Vm recursion: why don't we land the v8 patch? It works and it can't be worse than an AV.
22:13:00  <tjfontaine>AlexisMocha: floating v8 patches requires consideration, especially since we have a tendency to drop our patches on upgrades :/
22:13:44  <AlexisMocha>tjfontaine: 2) I am working on stderr, but it's likely not going to be a small fix
22:14:02  <tjfontaine>AlexisMocha: I had a feeling
22:14:16  <AlexisMocha>tjfontaine: had some questions about that
22:15:15  <AlexisMocha>i am gathering that there is no way in node to make something synchronous, that is asynchronous at the UV level
22:15:29  * mcavagequit (Ping timeout: 272 seconds)
22:15:31  <tjfontaine>AlexisMocha: right
22:15:36  <tjfontaine>AlexisMocha: well
22:15:54  <AlexisMocha>being mono-threaded
22:16:05  <tjfontaine>AlexisMocha: there are some ways, but there are certainly people who would cringe at the sight of us doing it
22:16:17  <AlexisMocha>do tell
22:16:51  <tjfontaine>I mean to say, if a change is crucial to node but cannot accurately be expressed in a platform neutral way in libuv, it's not out of line for us to include that change only in node
22:17:26  <tjfontaine>it's nice to believe there's a world where we can hide everything under a single interface in libuv, but in practice it's unlikely to ever be the case
22:18:09  <AlexisMocha>what i am saying is, if you only have uv_pipe_write_async, there is no way that you can expose a pipe.writeSync in node
22:18:46  * andrewrkquit (Quit: Leaving)
22:18:49  <tjfontaine>right, and I'm saying that if we need to support this without changing libuv we could grab the osf handle and write in our own way sync
22:19:27  <tjfontaine>if it were crucial to do something and we couldn't immediately get libuv api for it
22:19:35  <AlexisMocha>i see
22:20:06  <AlexisMocha>well, what i am getting at is that i think we should probably add a writeSync method to those streams
22:20:19  <tjfontaine>nod
22:20:20  <AlexisMocha>that people might want to call in a blocking way
22:20:55  <AlexisMocha>console.error(x) { process.stderr.writeSync(x+'\n'); }
22:21:53  <tjfontaine>well, that's what console.error(x) { fs.writeSync(2, ...) } is? :)
22:23:17  <AlexisMocha>you lost me :)
22:23:32  <tjfontaine>heh
22:23:33  <AlexisMocha>we have writeSync for fs but not for pipes or other streams
22:24:19  * andrewrkjoined
22:24:27  <tjfontaine>well, writeSync for fs is special in the unicies, since we're jsut really calling write() on that fd directly, but obviously windows is different
22:24:36  * andrewrkchanged nick to Guest92272
22:27:14  <AlexisMocha>it should be fairly easy to implement a writeSync for pipes on Windows
22:27:23  <AlexisMocha>as a write+wait
22:28:12  <AlexisMocha>and i understand that on unix all pipe writes are sync?
22:30:45  <tjfontaine>stdio is always blocking on unix
22:31:35  <tjfontaine>sorry synchronous, not necessarily blocking
22:31:44  <tjfontaine>;)
22:32:19  <tjfontaine>using pipe's though it's easy to get in a blocked state, especially with a parent that's not reading the child's stdout
22:33:03  <AlexisMocha>right
22:33:51  <AlexisMocha>pipes are async on windows and that's generally preferable
22:34:35  <AlexisMocha>what i am suggesting as the "ideal" state of things is that pipes support async and sync writes, but console methods always use the sync version
22:35:28  <AlexisMocha>console.error(x) { if(process.stderr.writeSync) process.stderr.writeSync(x+'\n'); else process.stderr.write(x+'\n') }
22:35:49  <tjfontaine>well, unfortunately it's not *quite* that simple, because stderr and stdout are actually streams apis
22:35:50  <AlexisMocha>and we implement writeSync for pipes on windows
22:36:20  <tjfontaine>but the premise is the same, we just implement a PipeWriteSync class that has a _write that implements it
22:36:31  <AlexisMocha>right, can't writeSync be a stream method that is not implemented by all streams?
22:36:33  <tjfontaine>and when stdout|stderr are instantiated they do the right one
22:38:07  <AlexisMocha>mmmm... not too sure about making the stdout|stderr streams implicitly sync, that could have negative performance consequences
22:39:05  <AlexisMocha>if someone is calling process.stderr.write, they know they can pass a callback to that
22:39:23  <AlexisMocha>it's console.error() that offers no callback mechanism and it's implicitly expected to be sync
22:39:59  <tjfontaine>well, when we get to the point where we have something to discuss, it's worth exploring those options :)
22:40:58  <AlexisMocha>you want a PR? :)
22:41:13  <tjfontaine>doesn't it need to go through libuv first?
22:41:23  * Raynos_quit (Ping timeout: 246 seconds)
22:41:28  <tjfontaine>I mean I think we definitely want to make sure libuv grows this support
22:41:33  <AlexisMocha>yes, we would need to add a uv_pipe_write_sync on win
22:43:49  * Guest92272changed nick to andrewrk
22:44:10  <AlexisMocha>is it too late for such a change?
22:44:23  * Raynos_joined
22:44:37  <tjfontaine>it's very close to late, what's your estimate on it?
22:44:42  <AlexisMocha>i can possibly implement it in 2 days
22:45:38  <AlexisMocha>1 if i am lucky
22:46:10  <tjfontaine>well, let me put it this way, it's not particularly a fix that I would be looking to hold the release for, but there are still two features that need to land in general so :)
22:47:19  <AlexisMocha>well, i'll give it a shot, if it doesn't make it i am sure the world will still go around
22:47:24  <tjfontaine>yup
22:47:32  * bajtosquit (Quit: bajtos)
22:47:37  <tjfontaine>unfortunately it's been the status quo on windows :/
22:47:45  <tjfontaine>but we have you now!
22:48:27  <AlexisMocha>one more thing
22:48:53  * Raynos_changed nick to Raynos
22:49:11  * euoiajoined
22:49:40  <AlexisMocha>in the issue https://github.com/joyent/node/issues/3584, it seems that there was a fix suggested. was that ever considered?
22:50:26  <tjfontaine>AlexisMocha: bert was working with Henry but wasn't thrilled with his direction, but then henry was gone before they could reach an agreement on the right path
22:50:43  <saghul_>guys, I caught the discussion in the middle, but maybe this is relevant? https://github.com/joyent/libuv/commit/92040eb7123e892261c8da71c3eedb97c00e4b88
22:51:08  <tjfontaine>saghul_: this landed?
22:51:15  <tjfontaine>well righ tI see the tags
22:51:16  <saghul_>yep
22:51:24  <saghul_>however: https://github.com/joyent/libuv/pull/1135
22:51:24  <AlexisMocha>yep, that's the one
22:51:29  <AlexisMocha>plus this in node: https://github.com/MSOpenTech/node/commit/0b3021ed3389436fe399fdbb02b0d65c23150592
22:51:37  <tjfontaine>that doesn't meet all of alexis conerns though, it is only an on/off solution
22:51:55  * dshaw_quit (Quit: Leaving.)
22:52:27  <saghul_>not sure what all his needs are, I picked up half of the conversation, sorry :-)
22:53:24  <tjfontaine>well he only wanted some of the writes to be blocking
22:53:57  <tjfontaine>that assert in unix side is kinda scary
22:53:59  <saghul_>some == "this and that handles"?
22:54:14  <tjfontaine>no, as in the intent for the user from user land
22:54:23  <saghul_>oh
22:54:23  <AlexisMocha>right, that sets the whole stream as either blocking or non-blocking
22:54:42  <tjfontaine>we also need to take care not to call that path on !win32
22:55:00  <saghul_>indeed
22:55:33  <tjfontaine>AlexisMocha: as an interim solution we can make all writes to stdout|stderr be blocking, and then fix that in post 0.12
22:55:57  * rosskquit
22:56:18  <tjfontaine>the node fix from henry is not really how we want to do that
22:57:49  <saghul_>I'll fix the comment, remove the assert (return UV_ENOSYS) and check that the flag is only set for pipe handles on Windows
22:58:02  <saghul_>at least it shouldn't be that scary :-)
22:58:06  <tjfontaine>srsly.
22:58:07  <tjfontaine>:)
22:58:10  * mikolalysenkoquit (Ping timeout: 244 seconds)
23:00:22  * kevinsimperquit (Remote host closed the connection)
23:00:55  <AlexisMocha>tjfontaine: i suppose this would make windows behave like unix
23:01:22  <tjfontaine>right, and then we can later fix the async|sync nature that requires more consideration
23:02:08  * dap_1quit (Quit: Leaving.)
23:02:11  <tjfontaine>I do have questions abotu what it means to allow both sync and async writes, as far as ordering is concerned
23:02:12  <AlexisMocha>okay
23:02:57  <AlexisMocha>you mean in the model i was proposing? it means that a sync is semantically a an asyncWrite followed by a wait
23:03:21  <AlexisMocha>things should get queued properly, but the sync version doesn't return until its request has completed
23:03:37  <tjfontaine>no I mean, if I do: process.stderr.write() and then process.stderr.writeSync() is the first guaranteed (or will it ever) to complete before my Sync call completes
23:03:45  <tjfontaine>ok
23:04:01  <tjfontaine>if making that work doesn't make me feel icky, it certainly seems appropriate
23:04:03  * bajtosjoined
23:04:05  <tjfontaine>:)
23:05:08  <saghul_>tjfontaine AlexisMocha: https://github.com/joyent/libuv/pull/1152
23:05:18  <tjfontaine>I can't figure out why the CLA stuff works sometimes and not other times
23:05:47  <tjfontaine>are these always named pipes?
23:05:56  <tjfontaine>anyway, if that's true that certainly GLTM
23:06:00  <tjfontaine>yoda comment
23:06:01  <tjfontaine>:)
23:06:11  <saghul_>:-)
23:07:44  <saghul_>I'll push it in the morning then, I'm about to go afk
23:07:49  <tjfontaine>saghul_: thanks
23:09:17  <AlexisMocha>yes thanks, I need to get going too. I'll test that change by HenryRawas tomorrow
23:15:02  <TooTallNate>tjfontaine: indutny: if you guys have some downtime: https://github.com/joyent/node/pull/7189
23:15:31  <tjfontaine>ya I looked at it briefly
23:15:35  <tjfontaine>(no such thing as down time)
23:15:55  <tjfontaine>I remember talking with isaacs about the addition of Agent.prototype.request
23:16:51  <tjfontaine>it was a conversation about separation of concerns, if what you want to make sure these set of requests actually happen with this agent, it seems unfortunate that you have to always pass in the agent to every request
23:17:01  <tjfontaine>TooTallNate: at least that's the reason why it was created
23:18:20  <TooTallNate>tjfontaine: it doesn't really make sense to me
23:18:37  <TooTallNate>there's also logic in Agent that should probably be in ClientRequest instead...
23:18:38  <TooTallNate>see https://github.com/TooTallNate/node/commit/e5b912688dd18b6ce36d11022f4038a7810ce173
23:19:10  <TooTallNate>tjfontaine: in any case, no API is breaking, and all the tests are still passing
23:19:24  <TooTallNate>tjfontaine: though we could add util.deprecate on agent.request() and agent.get() if you feel that's necessary
23:19:29  <TooTallNate>i don't really think so...
23:19:40  <tjfontaine>TooTallNate: right I am just trying to explain the justification, there's no need to deprecate Agent.prototype.request, it's new in 0.11
23:20:12  <TooTallNate>tjfontaine: ya gotcha, i'm just saying the justification still doesn't make sense to me :)
23:20:51  * dap_joined
23:21:16  <tjfontaine>TooTallNate: it's a separation of concerns argument, I don't defend the { agent: false } regression, but if I want to associate requests with a specific agent is backwards to have to supply the agent to the requesting mechansim, as opposed to requesting directly on the interface that I intend to keep around
23:21:25  * mcavagejoined
23:22:14  <tjfontaine>and from an implementation detail, in flight requests are indeed stored on that agent
23:22:59  <TooTallNate>tjfontaine: so the reason why i felt this was necessary is because right now, Agent and ClientRequest have a circular dependency on eachotehr
23:23:30  <TooTallNate>in fact, the circular dependency is causing agent.globalAgent to be undefined in the _http_client.js module!
23:23:37  <TooTallNate>which is the root of the cause of the regression
23:23:49  <TooTallNate>i was mostly just trying to remove the circular dependency
23:24:18  <tjfontaine>nod
23:26:25  * mcavagequit (Ping timeout: 272 seconds)
23:26:59  * kpdeckerquit (Quit: Leaving.)
23:42:23  * mikealjoined
23:45:57  * mikealquit (Client Quit)
23:50:50  * austoquit (Quit: austo)
23:52:23  * mikealjoined
23:56:11  * daviddiasquit (Ping timeout: 272 seconds)
23:58:26  * brsonquit (Ping timeout: 264 seconds)
23:59:05  * Kakeraquit (Ping timeout: 246 seconds)
23:59:08  * mikolalysenkojoined
23:59:58  * bajtosquit (Quit: bajtos)