00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:13  <euoia>I understood from your previous comment that I ought to instantiate the Stats object in JS (hence ->Call) rather than C++ and ->New
00:02:42  <trevnorris>euoia: ah, yeah. I guess the fastest way to do it would be to create a thin wrapper that is called from C++ that basically just returns "new Stats(...)", but with the number of arguments being passed I think that would actually be slower
00:03:09  <trevnorris>so using the ->NewInstance() from C++, I believe, would be the fastest way to execute that code.
00:03:33  * austoquit (Quit: austo)
00:04:20  <trevnorris>either way, at this point, we're talking about saving ~100 ns/op. so I'd say it's probably not worth the time investigating, unless you want to. :)
00:05:52  <euoia>if I use ->NewInstance I can get rid of createStatsObject in JS completely
00:06:27  * AlexisMochajoined
00:06:40  <euoia>I'll investigate it - I'll also see whether creating the Date object in JS makes any difference - I noticed when I was testing before that v8::Date::New is quite slow
00:07:44  * AvianFluquit (Remote host closed the connection)
00:08:02  <trevnorris>euoia: forgot one thing and updated with a comment in the pr with it
00:08:25  <trevnorris>ooh. yeah. Date::New is going to be much slower in C++
00:08:47  <trevnorris>("much slower" is completely relative here)
00:09:45  <trevnorris>euoia: ah, yeah. didn't notice the createStatsObject(). yeah, go ahead and remove that and just use ->NewInstance on the Stats function.
00:10:05  <tjfontaine>Date::New and new Date will always be "slow" as they result in a gettimeofday call
00:10:07  <euoia>ok... And basically I'll be renaming SetCreateStatsObjectFunction to FSInitialize
00:10:37  <euoia>(and adding the extra bits to it that you suggested)
00:11:15  <euoia>I'll investigate whether any meaningful time saving comes from creating the dates in JS
00:11:29  <trevnorris>euoia: awesome. thanks for doing this work. this should really speed things up.
00:11:46  <euoia>that's okay, it's fun. Thanks for the feedback.
00:12:09  <trevnorris>tjfontaine: there's also the slight extra cost of creating the actual Object in JS vs C++. which has a savings. though i'm interested to see what v3.24 brings to the table in terms of performance.
00:12:15  <trevnorris>euoia: np. anytime
00:12:45  <tjfontaine>the paths that stat()s are used I expect to be noise as compared to time spent getting through the worker queue
00:13:22  <trevnorris>how do you mean?
00:13:34  <tjfontaine>not that I have any problem with this work, it should be done, but I wouldn't obsess over Date
00:14:05  <trevnorris>ah, ok.
00:14:26  <tjfontaine>trevnorris: just that a large proportion of the time will be spent getting queued into and out of the thread pool and doing the actual stat() vs the ultimate time spent creating and passing the stats object
00:14:34  <trevnorris>too bad we can't like get the current time at program startup then use hrtime to resolve the amount of time after that :P
00:14:57  <tjfontaine>and will be difficult to quantify unless you are completely taking a real filesystem out of the mix
00:15:10  <trevnorris>tjfontaine: that might be true after this rework, but right now more than 60% of stat execution time is spent constructing that object in C++
00:15:34  * daviddiasquit (Ping timeout: 245 seconds)
00:16:43  <euoia>trevnorris: just to make sure - you understood that I added the createStatsObject function so that the "new" is in JS and not in C++ - it's preferable to have this bit in C++ (using ->Newinstance)?
00:17:51  * defunctzombie_zzchanged nick to defunctzombie
00:18:15  <trevnorris>euoia: any time savings would be sub 50ns/op, and that doesn't take into consideration the massive number of arguments you're passing. so imo it's not worth the extra code complexity.
00:18:36  <euoia>trevnorris: great, I'll make the refactor we discussed then
00:18:51  <trevnorris>euoia: see, a NewInstance() call is about the same as just ->Call(), and either would have to be made.
00:22:30  * dshaw_quit (Quit: Leaving.)
00:23:22  * wolfeida_joined
00:25:46  * dshaw_joined
00:25:52  <trevnorris>tjfontaine: i'm finishing up the doc changes and tests. though I'm going to wait on cleaning up the commits until after the review.
00:25:57  * jmar777quit (Remote host closed the connection)
00:25:58  * wolfeidauquit (Ping timeout: 240 seconds)
00:26:14  * paulfryz_quit (Remote host closed the connection)
00:30:56  * mcavagejoined
00:32:22  * abraxasjoined
00:34:13  * mcavage_joined
00:34:44  * mcavagequit (Read error: Connection reset by peer)
00:35:48  * mikealquit (Quit: Leaving.)
00:37:05  * abraxasquit (Ping timeout: 252 seconds)
00:41:57  * thlorenzquit (Remote host closed the connection)
00:44:27  * mikealjoined
00:45:51  * WalrusPony1changed nick to WalrusPony
00:48:29  * AlexisMochaquit (Ping timeout: 240 seconds)
00:56:00  * euoiaquit (Ping timeout: 264 seconds)
00:57:08  * paulfryzeljoined
00:59:09  * paulfryz_joined
01:01:29  * paulfryzelquit (Ping timeout: 240 seconds)
01:01:32  * wolfeida_quit (Remote host closed the connection)
01:02:50  * mrhoorayjoined
01:03:29  * paulfryz_quit (Ping timeout: 240 seconds)
01:04:49  * mrhoorayquit (Client Quit)
01:06:35  * defunctzombiechanged nick to defunctzombie_zz
01:09:34  * jmar777joined
01:20:22  * mikealquit (Quit: Leaving.)
01:29:54  * euoiajoined
01:33:47  <trevnorris>tjfontaine: ping
01:35:02  <tjfontaine>pong
01:36:45  <trevnorris>tjfontaine: so, noticed that for some reason fs.write[Sync](fd, msg) only accepts a 'string' for the msg. I find that sort of annoying. mind a PR to change that?
01:37:23  <tjfontaine>sorry missing context
01:38:06  <trevnorris>fs.writeSync(1, new Buffer('hi')) doesn't write anything.
01:39:22  <tjfontaine>you mean you want it to work without passing in offset, lenght, and position?
01:40:16  <tjfontaine>string isn't even publicly documented :)
01:40:39  * kenperkins_quit (Quit: Textual IRC Client: http://www.textualapp.com/)
01:41:21  <tjfontaine>I guess I dont' see much harm at the moment to changinging writeBuffer to knowing how to handle if offset, length, and position are undefined
01:41:44  <trevnorris>tjfontaine: oh, wtf. never noticed in the documentation. there's a usage discrepancy when writing to stdout/stderr
01:41:47  <tjfontaine>it seems like currently it's expecting it to be null if that's the path they wanted
01:41:59  <trevnorris>where in those two cases it only accepts a string
01:42:04  <tjfontaine>you mean stdout.write and stderr.write?
01:42:08  <tjfontaine>which case is that?
01:42:22  <trevnorris>no. fs.writeSync(1, 'hi there\n');
01:42:25  <trevnorris>will write to stdout
01:42:46  <tjfontaine>presuming someone hasn't fs.closeSync(1)'d first
01:42:57  <tjfontaine>and then immediately did fs.openSync()
01:42:59  <trevnorris>you can't close stdout, can you?
01:43:13  <tjfontaine>you cant process.stdout.close() but you can fs.closeSync(1)
01:43:35  <trevnorris>> fs.closeSync(1);
01:43:35  <trevnorris>events.js:82
01:43:35  <trevnorris> throw er; // Unhandled 'error' event
01:43:35  <trevnorris> ^
01:43:35  <trevnorris>Error: write EBADF
01:43:39  <trevnorris>you can't
01:43:49  <tjfontaine>sigh libuv
01:43:54  <tjfontaine>it's a perfectly fine fd to be allowed to close
01:44:05  <tjfontaine>it's the wrong place to enforce it, in libuv
01:44:08  <trevnorris>oh, well. it's not allowed right now. :)
01:44:22  <tjfontaine>it's an anti-pattern
01:44:40  <tjfontaine>anyway the point is, there are lots of places that do close standard in,out,err
01:44:50  <tjfontaine>you shouldn't really rely on them necessarily always being what you think they are
01:44:51  <trevnorris>ok. i don't really care. i just need a way to write to stdout/stderr w/o triggering the async callbacks
01:45:01  <trevnorris>which is either process._rawDebug or this.
01:45:04  <tjfontaine>why?
01:45:39  <trevnorris>users are going to want to log stuff from those callbacks. I do quite often.
01:45:45  * dshaw_quit (Quit: Leaving.)
01:45:48  <tjfontaine>but this is why the caveat exists
01:45:58  <trevnorris>what caveat?
01:46:06  <tjfontaine>performing async activity in this path is explicitly wrong
01:46:21  <tjfontaine>if your intent is to write this to stderr and stdout you should store it in a ring buffer
01:46:34  <tjfontaine>such that it can be done outside of this mechanism
01:47:08  <trevnorris>we now even have execSync. I think logging something out to stdout/stderr in a sync manner is something that should be easily supported.
01:48:05  <tjfontaine>var info = []; tracing.AL(function() { info.push('this happened') }); setInterval(function() { info.forEach(function(i) { console.log(i); }); info = []; }, 1000);
01:49:13  <tjfontaine>the problem is you want to except out stdout and stderr, but in reality it's *any* async operation that is dangerous -- more of these people will want to socket.write() and writestream.write() than they will want to stdout.write
01:49:15  <trevnorris>seriously? if stdout/stderr is considered a normal fd, and we're allowed to writeSync to an fd, then why is this complicated solution necessary?
01:50:03  <othiym23>not that anybody asked, but I'm with trevnorris on this one
01:50:27  <trevnorris>well technically, and stupidly, users could just do fs.writeSync(socket._handle.fd, 'some message'); and it would work the same.
01:50:40  <tjfontaine>not on windows, but that's beside the point
01:50:51  <othiym23>either we have an async-safe logging method exposed for AL dev use, or we just let people use stdout / stderr directly
01:51:05  <tjfontaine>are we having a conversation abotu writeSync being able to support Buffer, or about if we should move process.stdout|stderr.write to something else entirely
01:51:39  <trevnorris>heh, guess it migrated. seems that writeSync doesn't support writing Buffers to stdout/stderr, but don't really care about that.
01:52:09  <tjfontaine>writeSync does, you just need to pass more arguments
01:52:31  <tjfontaine>and I'm +-0 on the change, I can't see the harm in it at the moment
01:52:40  <trevnorris>haha, you're right
01:52:58  * dshaw_joined
01:53:07  <trevnorris>tjfontaine: guess since the arguments are documented as explicit i was expecting it to throw if the arguments were not passed
01:53:34  <trevnorris>tjfontaine: well, right now it's possible for stderr via process._rawDebug(), but i'm not about to tell users to use that.
01:53:53  <tjfontaine>having a sync logging mechanism that is AL safe, is completely doable by those who understand fs.writeSync though, I don't advocate node going any further out of its way to support something beyond that
01:54:04  * dap_quit (Quit: Leaving.)
01:54:38  <tjfontaine>trevnorris: I'm fine with being explicit about the failure for writeBuffer in this case, or supporting the model, it seems sane to write out the whole buffer at the current position
01:54:41  <trevnorris>fine by me. i'm documenting using fs.writeSync() and if they want console type output then pass the message to util.inspect(
01:54:42  <trevnorris>)
01:55:13  <tjfontaine>I would avoid mentioning util.inspect in the create case, because that will definitely it the "it's not safe" part, unless we decouple the create method firing from the constructor
01:55:20  <trevnorris>tjfontaine: oh, I was just confused why an entire string was being written, but the arguments for a Buffer are explicit. that I don't care about.
01:55:52  <trevnorris>dinner bbiab
01:55:54  * trevnorris&
01:55:55  <LOUDBOT>IF YOU CAN DETECT HEAT THROUGH WALLS, SEEK MEDICAL ATTENTION
01:56:43  <othiym23>that's pretty inscrutable, LOUDBOT
01:57:13  <tjfontaine>othiym23: how do you deliver stats currently while avoiding the feedback loop?
01:57:50  * wolfeidaujoined
01:58:26  * dshaw_quit (Quit: Leaving.)
02:00:36  * dshaw_joined
02:00:59  * mikolalysenkoquit (Ping timeout: 240 seconds)
02:04:24  * euoiaquit (Ping timeout: 264 seconds)
02:06:32  <othiym23>tjfontaine: how do you mean?
02:06:49  <othiym23>the only thing happening inside AL is CLS, which doesn't do any action, per se, just propagates state
02:07:23  <othiym23>when things are acting wacky I use the debugger, as was intended by the inscrutable, evanescent autocthonic machine intelligence who rules us all
02:10:10  * indexzerojoined
02:11:10  * dshaw_quit (Quit: Leaving.)
02:17:00  * Ralithquit (Ping timeout: 264 seconds)
02:32:51  * euoiajoined
02:32:53  * mikealjoined
02:33:07  * abraxasjoined
02:33:26  * AWintermanquit (Remote host closed the connection)
02:38:08  * abraxasquit (Ping timeout: 252 seconds)
02:38:15  * abraxasjoined
02:41:50  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:44:43  * Ralithjoined
02:45:05  * kpdeckerquit (Quit: Leaving.)
02:45:11  * indexzeroquit (Quit: indexzero)
02:49:22  * kpdeckerjoined
02:50:11  * mikealquit (Quit: Leaving.)
02:51:31  * abraxasquit (Remote host closed the connection)
02:52:06  * abraxasjoined
02:55:25  * mikolalysenkojoined
02:55:48  * Ralithquit (Read error: Connection reset by peer)
02:56:29  * abraxasquit (Ping timeout: 240 seconds)
02:56:42  * thlorenzjoined
02:58:17  * defunctzombie_zzchanged nick to defunctzombie
03:00:08  * abraxasjoined
03:01:50  <tjfontaine>othiym23: I guess my question is more accurately, how often is the information that was collected phoned home, and do you do anything to squelch out the fact that you may potentially be including yourself in those numbers
03:04:06  <othiym23>tjfontaine: data is sent once a minute, in three different chunks (metrics, errors, slow transaction trace(s)), and all of the metric and tracing work is done in such a way that NR-specific data are confined in supportability metrics
03:04:22  <othiym23>however, there are very few supportability metrics (I think there's only 1 right now)
03:04:25  <othiym23>this is going to change very soon
03:05:00  <othiym23>the work I've been doing to add SSL support is also adding true keep-alive support so that ideally only 1 HTTP / TLS socket will be used for each data submission run
03:05:11  * indexzerojoined
03:05:30  <tjfontaine>right, and you're not doing fine grained resource tracking around a lot of the events that are generated in AL
03:05:33  <othiym23>of course, we do in-memory aggregation for the metrics, so only the slow transaction trace (and potentially errors, although rarely in practice) will use up lots of memory
03:05:38  * indexzeroquit (Client Quit)
03:05:58  <othiym23>no, the events generated within the AL are only kept as byproducts of generating the transaction trace
03:06:15  <othiym23>which is built up from monkeypatched instrumentation for specific modules
03:07:09  <tjfontaine>in your exisitng AL/CLS land, are you operating on _handle or on actual Socket like objects?
03:07:09  <othiym23>if / when bnoordhuis's profiler patch lands, we may leverage that to generate "X-ray sessions" for Node, and there's some other high-frequency sampling we'll probably be doing sooner rather than later
03:07:32  <tjfontaine>do you have any problem with that being landed in a patch release?
03:08:01  <tjfontaine>to me adding instrumentation probes during patch releases is not a very controversial thing
03:08:04  <othiym23>the AL polyfill monkeypatches Socket to make sure that the relevant events are handled properly
03:08:18  <tjfontaine>but you're not storing anything directly on _handle or Socket?
03:08:41  <othiym23>for CLS / New Relic, all we care about is that we can track everything that happens after the HTTP connect, because (for now) it's the new HTTP connection that triggers the creation of a NR transaction trace
03:09:02  * eugenewarejoined
03:09:06  <othiym23>no, all data storage is done within CLS, which depends on AL passing along the storage object
03:09:14  <tjfontaine>nod
03:09:28  <othiym23>so I'm anticipating having to do some significant work if you and trevnorris do switch all that around to be ID-based instead
03:10:11  <othiym23>the lifecycle management aspects of that latter approach concern me a little from a performance point of view, too, because that means I have to listen for object lifecycle events and then do post hoc cleanup on whatever storage object is dealing with the storage
03:10:18  <othiym23>gotta go!
03:10:20  <othiym23>bbiab
03:10:29  <tjfontaine>enjoy
03:11:07  <tjfontaine>but the maintanence cost for Node to manage the whole AL stack is quite expensive
03:11:28  <groundwater>tjfontaine agreed
03:11:37  <groundwater>also we may decide theres a better way
03:11:55  <tjfontaine>and increasingly walking down the path of domains, as being an environment where the semantics and side effects aren't understood until later
03:11:59  * mikealjoined
03:13:15  <tjfontaine>actually/frankly not already having the lifecycle portion seems like a hole anyway, because if we're tracking when allocations happen why aren't we tracking when deallocations happen
03:13:58  <groundwater>would those only fire during/after a GC event?
03:14:28  <tjfontaine>depends on how they were implemented
03:15:06  * abraxasquit (Remote host closed the connection)
03:15:40  * abraxasjoined
03:16:29  * mikealquit (Ping timeout: 241 seconds)
03:18:59  <groundwater>looks like we're punching the ._handle's onread handler
03:19:08  <tjfontaine>during create?
03:19:09  <groundwater>so... yeah, it all comes down to the handle object
03:20:14  <groundwater>on connect
03:20:23  <groundwater>not the listening socket
03:20:36  * abraxasquit (Ping timeout: 264 seconds)
03:20:39  <tjfontaine>k
03:20:41  <groundwater>https://github.com/othiym23/async-listener/blob/master/index.js#L64-L66
03:21:30  <tjfontaine>right so finding the balance of what and where to use certain kinds of AL will be interesting for you, even in this new fangled world
03:22:15  <tjfontaine>frankly in a lot of these places it seems like it would be far easier for node to just provide static probes for you to consume
03:22:37  <tjfontaine>so instead of having to monkey patch _listen2 we fire a probe that says "no really, here's the handle you care about"
03:23:06  <tjfontaine>and we should have that concept at tcp and http layer
03:25:55  <groundwater>so i'm probably agreeing with you, but i'm gonna phrase it differently
03:26:26  <groundwater>i think we should, as close as possible, make visible what node is doing
03:26:42  <groundwater>without interpreting the data too much in core
03:26:46  <groundwater>leave that for user land
03:27:25  <tjfontaine>I would also agree with that
03:27:32  <groundwater>tjfontaine yah if there was an onConnect probe that fired with the handle, that could probably be used to glue some initial state onto the handle
03:29:27  * abraxasjoined
03:30:54  <groundwater>so, looks like we patch the onread function, with a wrapped function which holds the state in a closure
03:30:58  <groundwater>wheeee
03:33:43  * indexzerojoined
03:33:51  * indexzeroquit (Client Quit)
03:40:46  * defunctzombiechanged nick to defunctzombie_zz
03:52:47  * abraxasquit (Remote host closed the connection)
03:53:23  * abraxasjoined
03:55:51  * abraxas_joined
03:56:14  * abraxasquit (Read error: Connection reset by peer)
03:56:20  * defunctzombie_zzchanged nick to defunctzombie
04:04:28  * abraxas_quit (Remote host closed the connection)
04:05:12  * abraxasjoined
04:09:12  * abraxasquit (Ping timeout: 240 seconds)
04:12:28  * mikealjoined
04:17:07  * mikealquit (Ping timeout: 265 seconds)
04:20:19  * jmar777quit (Remote host closed the connection)
04:30:04  * thlorenzquit (Remote host closed the connection)
04:34:22  <othiym23>tjfontaine: I think my position is a little different from groundwater's, just because getting CLS and the NR tracer working was such an unholy pain in the ass that I'm scared that things will change in such a way that I have to go through that whole process again
04:34:35  <othiym23>CLS isn't magic, but it is pretty fragile
04:36:01  * octetcloudquit (Ping timeout: 240 seconds)
04:36:47  <othiym23>selfishly, what we had in 0.11.10 was pretty much ideal for my purposes (setting aside the overhead), because the necessary state was directly attached to the execution context
04:37:02  <othiym23>and it was automatically invoked everywhere it needed to be
04:37:27  <othiym23>so I could just register the CLS listener and leave it on all the time and things just worked
04:38:03  <othiym23>the changes we've been discussing make me nervous, because when the tracer loses data, it's not always visible, and fixing those kinds of bugs is excruciatingly time-consuming and frustrating
04:38:29  <othiym23>like, my darkest fear is that we'll get this new tracing module finished and it'll just straight up break the transaction tracer and then it's another couple months to write a new one
04:38:42  <othiym23>I'm probably carrying around some PTSD related to all this ;)
04:42:17  * mikealjoined
04:43:58  * indexzerojoined
04:55:29  * m76joined
05:02:08  * paulfryzeljoined
05:02:21  * bradleymeckjoined
05:06:14  <bradleymeck>tjfontaine: put up my branch since we talked about bundling earlier https://twitter.com/bradleymeck/status/441006691530727424
05:06:29  * paulfryzelquit (Ping timeout: 240 seconds)
05:06:31  <bradleymeck>its an extraction based one which is diff than what you wanted I think
05:16:55  * Kakerajoined
05:22:22  * euoiaquit (Ping timeout: 265 seconds)
05:24:05  * calvinfoquit (Quit: Leaving.)
05:41:30  * eugenewarequit (Remote host closed the connection)
05:42:04  * eugenewarejoined
05:46:30  * eugenewarequit (Ping timeout: 244 seconds)
06:05:42  * abraxasjoined
06:10:16  * abraxasquit (Ping timeout: 244 seconds)
06:16:01  * mikolalysenkoquit (Ping timeout: 265 seconds)
06:16:55  * abraxasjoined
06:34:39  * abraxasquit (Remote host closed the connection)
06:39:13  * defunctzombiechanged nick to defunctzombie_zz
06:39:30  * wolfeidauquit (Remote host closed the connection)
06:39:52  * brsonjoined
06:42:43  * abraxasjoined
06:42:58  * mikolalysenkojoined
06:45:04  * abraxasquit (Remote host closed the connection)
07:02:35  * Kakeraquit (Read error: Operation timed out)
07:03:54  * paulfryzeljoined
07:05:43  * brson_joined
07:07:28  * bajtosjoined
07:09:12  * brsonquit (Ping timeout: 264 seconds)
07:09:59  * paulfryzelquit (Ping timeout: 240 seconds)
07:24:27  * daviddiasjoined
07:30:48  * txdv_quit (Ping timeout: 264 seconds)
07:42:54  * txdvjoined
08:03:57  * daviddia_joined
08:09:30  * indutny_joined
08:09:36  * rendarjoined
08:11:02  * daviddiasquit (*.net *.split)
08:11:02  * mikolalysenkoquit (*.net *.split)
08:11:05  * indutnyquit (*.net *.split)
08:11:07  * txdvquit (*.net *.split)
08:11:07  * kpdeckerquit (*.net *.split)
08:11:08  * sblomquit (*.net *.split)
08:11:10  * hueniversequit (*.net *.split)
08:11:10  * nsmquit (*.net *.split)
08:13:05  * hzjoined
08:20:44  * raffikiquit (Ping timeout: 265 seconds)
08:25:14  <saghul>good morning folks
08:33:33  * raffikijoined
08:33:50  * cjbquit (Ping timeout: 252 seconds)
08:59:39  * mikolalysenkojoined
09:00:56  * nsmjoined
09:00:57  * hueniversejoined
09:00:57  * sblomjoined
09:00:57  * txdvjoined
09:04:43  * mikolalysenkoquit (Ping timeout: 265 seconds)
09:05:47  * eugenewarejoined
09:12:52  * `3rdEdenjoined
09:13:34  * eugenewarequit (Ping timeout: 240 seconds)
09:14:08  * janjongboomjoined
09:14:09  * `3rdEdenchanged nick to Guest11934
09:14:18  * Guest11934changed nick to V1
09:14:33  * V1changed nick to `3rdEden
09:18:39  * m76quit (Ping timeout: 252 seconds)
09:27:00  <indutny_>morning
09:31:34  * felixgejoined
09:31:34  * felixgequit (Changing host)
09:31:34  * felixgejoined
09:32:29  * sinclair|workjoined
09:43:18  * mikolalysenkojoined
09:45:25  * indexzeroquit (Quit: indexzero)
09:46:02  * karupanerurachanged nick to zz_karupanerura
09:47:46  * guilleiguaranquit (Quit: Connection closed for inactivity)
09:48:21  * mikolalysenkoquit (Ping timeout: 252 seconds)
09:53:50  * mrhoorayjoined
09:57:21  * m76joined
10:07:56  * paulfryzeljoined
10:12:29  * paulfryzelquit (Ping timeout: 240 seconds)
10:26:00  * janjongboomquit (Ping timeout: 264 seconds)
10:29:51  * bajtosquit (Quit: bajtos)
10:31:23  * brson_quit (Quit: leaving)
10:32:42  * mrhoorayquit
10:35:44  * calvinfojoined
10:42:50  * mcavage_quit (Ping timeout: 265 seconds)
10:44:05  * mikolalysenkojoined
10:48:58  * mikolalysenkoquit (Ping timeout: 240 seconds)
10:53:45  * AlexisMochajoined
10:55:00  * calvinfoquit (Quit: Leaving.)
10:56:33  * eugenewarejoined
11:01:41  * eugenewarequit (Ping timeout: 265 seconds)
11:04:04  * daviddia_quit (Remote host closed the connection)
11:08:53  * paulfryzeljoined
11:12:59  * paulfryzelquit (Ping timeout: 240 seconds)
11:27:16  <MI6>joyent/node: Ben Noordhuis v0.10 * bd8a575 : src: add default visibility to NODE_MODULE - http://git.io/2eFY3A
11:35:34  * mcavagejoined
11:35:40  <indutny_>hey hey hey :)
11:44:53  * mikolalysenkojoined
11:49:57  * mikolalysenkoquit (Ping timeout: 252 seconds)
11:50:04  * skebcio_joined
11:51:45  * WalrusPony1joined
11:53:48  * motley_joined
11:54:23  * burlitojoined
11:54:53  * janjongboomjoined
11:55:54  * motleyquit (Ping timeout: 265 seconds)
11:56:13  * WalrusPonyquit (Read error: Connection reset by peer)
11:56:13  * skebcioquit (Quit: No Ping reply in 180 seconds.)
11:56:14  * nifocquit (Ping timeout: 265 seconds)
11:56:14  * rjequit (Ping timeout: 265 seconds)
11:56:48  * burlakquit (Ping timeout: 265 seconds)
11:56:51  * burlitochanged nick to burlak
11:56:52  * nifocjoined
11:56:53  * rjejoined
11:57:05  * motley_changed nick to motley
12:02:13  * bradleymeckquit (Quit: bradleymeck)
12:08:31  * wolfeidaujoined
12:09:29  * paulfryzeljoined
12:13:59  * paulfryzelquit (Ping timeout: 240 seconds)
12:17:06  <indutny_>gosh
12:17:16  <indutny_>some people are just weird
12:21:54  <AlexisMocha>lol
12:23:33  <indutny_>have you seen this https://github.com/joyent/node/issues/7241#issuecomment-36736393 ?
12:23:44  <indutny_>I'm not sure, why he is so angry at me
12:24:01  <indutny_>and it appears that he has registered at github just to open this issue
12:27:23  <AlexisMocha>so rude
12:32:00  * motleyquit (Changing host)
12:32:00  * motleyjoined
12:39:40  <saghul>indutny_: haters gonna hate, just ignore him or you'll end up pissed for now good reason
12:39:50  <indutny_>haha
12:39:53  <indutny_>thanks man
12:45:48  * mikolalysenkojoined
12:50:29  * mikolalysenkoquit (Ping timeout: 240 seconds)
12:56:17  * eugenewarejoined
13:01:13  * eugenewarequit (Ping timeout: 240 seconds)
13:05:36  * daviddiasjoined
13:06:14  * wolfeidauquit (Remote host closed the connection)
13:10:21  * paulfryzeljoined
13:10:30  * wolfeidaujoined
13:14:29  * paulfryzelquit (Ping timeout: 240 seconds)
13:15:47  * jmar777joined
13:21:31  * thlorenzjoined
13:32:42  * sinclair|workquit (Quit: ChatZilla 0.9.90.1 [Firefox 27.0.1/20140212131424])
13:38:10  * jmar777quit (Remote host closed the connection)
13:46:28  * mikolalysenkojoined
13:49:39  * nickleefly___joined
13:50:59  * mikolalysenkoquit (Ping timeout: 240 seconds)
13:56:36  * eugenewarejoined
13:58:53  * nickleefly___part
14:00:14  * euoiajoined
14:01:26  * eugenewarequit (Ping timeout: 252 seconds)
14:03:02  * nickleeflyjoined
14:05:51  * jmar777joined
14:09:41  * WalrusPony1changed nick to WalrusPony
14:11:04  * paulfryzeljoined
14:15:29  * paulfryzelquit (Ping timeout: 240 seconds)
14:15:29  * daviddiasquit
14:18:08  * guybrushquit (Excess Flood)
14:18:15  * guybrushjoined
14:21:18  * daviddiasjoined
14:24:41  * euoiaquit (Ping timeout: 265 seconds)
14:39:58  * euoiajoined
14:46:22  * motleychanged nick to motley_
14:47:01  * motley_changed nick to motley
14:47:09  * mikolalysenkojoined
14:51:03  * guilleiguaranjoined
14:52:06  * mikolalysenkoquit (Ping timeout: 244 seconds)
14:57:47  * euoiaquit (Ping timeout: 244 seconds)
15:07:13  * wolfeidauquit (Ping timeout: 265 seconds)
15:11:43  * paulfryzeljoined
15:13:17  * janjongboomquit (Ping timeout: 244 seconds)
15:14:26  * janjongboomjoined
15:15:59  * paulfryzelquit (Ping timeout: 240 seconds)
15:23:23  * defunctzombie_zzchanged nick to defunctzombie
15:30:08  <tjfontaine>othiym23: ya I can understand entirely your reticence, what keeps me up at night is adding something with significant complexity and overhead and features without a clear consumer, especially if it can be managed external to node
15:30:57  <tjfontaine>othiym23: life cycle management should be relatively easy to add (and should already be there) and easy to fix the scenarios where it's missed
15:31:42  <tjfontaine>othiym23: I just *really* don't want to see us add something that here, right now, we think we want, but then end up not coming close to hitting the need, and being stuck carrying it around for years -- hi domains, cluster!
15:47:54  * mikolalysenkojoined
15:51:10  * xaqjoined
15:51:31  * m76quit (Ping timeout: 244 seconds)
15:52:47  * m76joined
15:52:47  * bradleymeckjoined
15:53:08  * mikolalysenkoquit (Ping timeout: 265 seconds)
15:59:20  * mikealquit (Quit: Leaving.)
16:04:00  * petka_joined
16:05:59  * defunctzombiechanged nick to defunctzombie_zz
16:13:04  * xaqquit (Remote host closed the connection)
16:16:59  * mikealjoined
16:20:27  * paulfryzeljoined
16:22:12  * AvianFlujoined
16:24:40  * TooTallNatejoined
16:24:50  * nickleeflyquit (Quit: Connection closed for inactivity)
16:29:00  * janjongboomquit (Ping timeout: 264 seconds)
16:39:38  * rosskquit (Remote host closed the connection)
16:44:08  * mikealquit (Quit: Leaving.)
16:47:04  * defunctzombie_zzchanged nick to defunctzombie
16:48:42  * mikolalysenkojoined
16:51:25  * AWintermanjoined
16:53:31  * mikolalysenkoquit (Ping timeout: 244 seconds)
16:53:46  * dap_joined
16:56:55  * eugenewarejoined
16:57:57  * calvinfojoined
17:00:58  * eugenewarequit (Ping timeout: 240 seconds)
17:01:22  * Kakerajoined
17:02:52  * mikolalysenkojoined
17:03:17  <tjfontaine>wq
17:06:25  <AvianFlu>q!
17:07:24  <tjfontaine>:)
17:12:13  <tjfontaine>hey voxer metrics!
17:22:31  * daviddia_joined
17:24:58  * daviddiasquit (Ping timeout: 265 seconds)
17:28:51  * daviddiasjoined
17:29:25  * mikealjoined
17:31:26  * janjongboomjoined
17:31:32  * daviddia_quit (Read error: Operation timed out)
17:32:11  * octetcloudjoined
17:33:18  * benviequit (Ping timeout: 244 seconds)
17:36:09  * thlorenzquit (Remote host closed the connection)
17:36:45  * thlorenzjoined
17:36:53  <MI6>joyent/node: Fedor Indutny v0.10 * 5e06ce4 : child_process: fix sending handle twice (+1 more commits) - http://git.io/47ZKSQ
17:37:02  * thlorenzquit (Read error: Connection reset by peer)
17:39:31  * mikealquit (Quit: Leaving.)
17:41:17  * rosskjoined
17:41:22  * mikealjoined
17:42:55  * thlorenzjoined
17:44:21  * brsonjoined
17:45:19  * kpdeckerjoined
17:45:35  <groundwater>othiym23 tjfontaine the way i see it, is that we have something that works, and 0.12 is unlikely to stop it from working
17:46:00  <groundwater>the worst that would happens is we don't switch out the AL polyfil 1-1 with the native implementation
17:46:26  <tjfontaine>and that's exactly the scenario that scares me more about AL being in core at all
17:46:27  <groundwater>but forward-looking, if there is a better path for node tracing, we probably want to be on top of that, rather than behind it
17:46:55  <groundwater>tjfontaine which scenario?
17:47:13  <tjfontaine>having done AL completely in core, and your tracing agent not even using it
17:48:39  <groundwater>so, i think it makes sense to either put it in *exactly* the features we're using, with the aim of a near 1-1 swap
17:49:02  * benviejoined
17:49:04  <groundwater>or to stand back and think hard about what node actually needs
17:49:11  * dshaw_joined
17:49:39  <groundwater>but i would be resistant to implementing anything not in current AL with the idea that it's "for us"
17:50:06  <tjfontaine>is your tracer using the al polyfill right now?
17:50:14  * thlorenzquit (Read error: Connection reset by peer)
17:50:17  <groundwater>yes!
17:50:20  <groundwater>it's in the wild
17:50:36  <tjfontaine>ok
17:50:36  * thlorenzjoined
17:52:57  <indutny_>heya
17:53:06  <groundwater>tjfontaine and currently, the only reason for a native AL is performance
17:53:35  <tjfontaine>the only reason to need it, or the only reason not to use it?
17:54:08  <groundwater>tjfontaine if they were functionally identical, we would use whichever performed better
17:54:55  <tjfontaine>the polyfill is much more surgical in its usage
17:55:38  <tjfontaine>pretty clean and obvious code around what's happening here
17:56:45  <groundwater>so i see two options, (1) a more performant version of current AL
17:57:01  <groundwater>(2) a new api that we may or may not use
17:57:21  * bradleymeckquit (Quit: bradleymeck)
17:57:23  <groundwater>(1) is a short win, and is probably fine
17:57:36  <indutny_>tjfontaine: could you please permanently add me to #node-core?
17:57:40  <groundwater>(2) may hold more long term gains, but is a gamble and requires some extra time investment
17:58:17  <tjfontaine>indutny_: I unban'd you, the problem is you're not identified before trying to join, which I probably blame freenode for, lemme try and change how that's enforced
17:58:25  <indutny_>haha
17:58:26  <indutny_>ok
17:58:29  <indutny_>thanks man
17:59:35  * mikealquit (Quit: Leaving.)
17:59:46  * defunctzombiechanged nick to defunctzombie_zz
18:01:17  * mikealjoined
18:06:49  * indutny_changed nick to indutny
18:06:51  <indutny>oh
18:06:57  <indutny>guess this was it
18:07:04  <indutny>I should register indutny_ too
18:07:04  <indutny>:D
18:08:33  * daviddia_joined
18:09:34  <indutny> 22 74592 bud_trace_handshake:handshake conn from 5.255.232.143:7660 with cipher ECDHE-RSA-AES256-SHA and servername blog.indutny.com
18:09:36  <indutny>ha!
18:09:37  <indutny>:)
18:10:56  <tjfontaine>so that's what you're doing with a translator :P
18:10:59  * daviddiasquit (Ping timeout: 245 seconds)
18:11:03  <indutny>yes
18:11:06  <indutny>btw
18:11:13  <indutny>I don't think that we need those comparisons in node.d
18:11:20  <indutny>I just did it in a different way
18:11:26  <indutny>https://github.com/indutny/bud/blob/master/src/bud.d
18:11:32  <indutny>passing uint64_t instead of char*
18:11:48  <indutny>and assigning them here:
18:11:48  <indutny>https://github.com/indutny/bud/blob/master/src/tracing.c#L17
18:11:57  <indutny>what do you think, should I do the same in node?
18:12:04  <rendar>indutny: written in D languange? awesome
18:12:11  <indutny>rendar: it's for DTrace
18:12:12  <indutny>certainly :)
18:12:15  <rendar>oh :P
18:12:18  <indutny>the rest is in C
18:13:49  <tjfontaine>D existed before digital mars ;)
18:15:40  <indutny>digital mars!
18:15:42  <indutny>oh god
18:16:05  * daviddiasjoined
18:16:22  <indutny>I wonder if there is anyway to copy files between servers without ssh
18:16:27  <indutny>like a simple way
18:16:28  <tjfontaine>nc
18:16:34  <indutny>hm...
18:16:43  <indutny>can it serve files?
18:16:55  <tjfontaine>ya, tar | nc <server>
18:17:00  <tjfontaine>http://toast.djw.org.uk/tarpipe.html
18:17:16  <indutny>no
18:17:16  <tjfontaine>used to do it all the time
18:17:21  <indutny>oh
18:17:26  <indutny>will it eat 300 gb?
18:17:27  <indutny>:)
18:17:34  <tjfontaine>hmm?
18:17:38  <indutny>because ssh feels pretty terrible right now
18:17:53  <tjfontaine>oh oh
18:18:07  <groundwater>nc ftw
18:18:09  <tjfontaine>there's always HPN patches to ssh, btu that doesn't help you right now
18:18:16  <tjfontaine>nc certainly has far less overhead
18:18:25  <tjfontaine>and if you're in a trusted env it makes sense
18:18:32  <indutny>ok
18:18:35  <indutny>one sec
18:18:51  <tjfontaine>using tar as a proxy through it is helpful for identifying what you need
18:18:55  <indutny>the problem is
18:19:02  <indutny>that I have one machine
18:19:06  * daviddia_quit (Ping timeout: 265 seconds)
18:19:07  <tjfontaine>the other solution I would suggest if you want verification of the written file is rsyncd
18:19:08  <indutny>that should download file
18:19:12  <indutny>and it is behind firewall
18:19:18  <tjfontaine>ah nat traversal
18:19:21  <indutny>well
18:19:27  <indutny>sort of
18:19:32  * dshaw_quit (Read error: Connection reset by peer)
18:19:34  * daviddia_joined
18:19:34  <indutny>I think it isn't behind nat
18:19:43  <indutny>but just have all ports disabled on router
18:19:44  <tjfontaine>the place you need th efile is behind a firewall, the place you're serving it from is not though?
18:19:51  <indutny>yes
18:19:59  <indutny>nc -wl 8000 < file ?
18:20:02  <indutny>will that work?
18:20:05  <indutny>and on other machine
18:20:12  * kpdeckerquit (Quit: Leaving.)
18:20:22  <indutny>nc addr 8000 > file ?
18:20:26  * kpdeckerjoined
18:20:26  <tjfontaine>ya you can swap the order of who listens
18:20:27  * dshaw_joined
18:21:07  <indutny>seems to be working
18:21:07  <tjfontaine>checksum it either way
18:21:10  <indutny>yeah
18:21:11  <indutny>will do
18:21:21  <indutny>yeah, it is way faster
18:21:22  <indutny>thank you
18:21:23  <tjfontaine>better throughput?
18:21:24  * daviddiasquit (Ping timeout: 245 seconds)
18:21:25  <tjfontaine>coolio.
18:21:29  <indutny>like 3x times
18:21:32  <tjfontaine>nod
18:21:41  <tjfontaine>crypto costs ;)
18:21:47  <groundwater>i used nc all the time in my sysadmin days
18:21:56  <indutny>I wonder if I could make it report progress
18:21:59  <tjfontaine>indutny: in the future http://www.psc.edu/index.php/hpn-ssh
18:22:06  <tjfontaine>indutny: next time pipe through pv
18:22:07  <groundwater>if you really want to let loose, you can use nc in udp mode!!!!
18:22:11  <indutny>pv?
18:22:23  <tjfontaine>pv will show you transfer rate and amount transferred
18:22:44  <tjfontaine>http://www.ivarch.com/programs/pv.shtml
18:22:57  <indutny>ah
18:23:00  <indutny>should I just pipe it through it?
18:23:21  <tjfontaine>I would, either on receiving or sending (or both)
18:23:29  <tjfontaine>it's just cat | pv | tar
18:23:33  <tjfontaine>you can see the transfer rates
18:23:39  <indutny>ok, great
18:23:56  <groundwater>i think if you're going to cat, you can use pv directly to read the file, then it can show a progress bar
18:24:10  <tjfontaine>yes you can do that as well, it will stat the file
18:24:19  <indutny>I was thinking about using it on downloading side
18:24:20  <indutny>also
18:24:25  <indutny>should I add `-u` to make it use udp?
18:24:37  <groundwater>indutny no, that was a joke
18:24:38  <tjfontaine>I prefer reliable transmission myself ;)
18:24:41  * mikealquit (Read error: Connection reset by peer)
18:25:00  * mikealjoined
18:25:16  <indutny>ok, it isn't much faster
18:25:17  <groundwater>though i *am* curious about the performance/reliability tradeoffs
18:25:18  <indutny>actually
18:25:28  <indutny>I'd even say it is slower...
18:25:29  * eugenewarejoined
18:25:30  <indutny>somehow
18:25:39  <tjfontaine>just using raw netcat you mean?
18:25:48  <indutny>yes
18:25:54  <tjfontaine>interesting
18:25:58  <indutny>yeah
18:26:01  <tjfontaine>I generally do this when transferring
18:26:03  <indutny>it seems to be even slower than rsync
18:26:13  <tjfontaine>rsync -avP --in-place -e 'ssh -c blowfish'
18:26:23  <tjfontaine>maybe it's just --inplace
18:26:24  <indutny>good idea
18:26:24  <indutny>:)
18:26:54  <indutny>yeah
18:26:56  <indutny>it is much faster
18:27:01  <tjfontaine>all depends on what I'm trying to solve for
18:27:08  <tjfontaine>if I care about the contents of the file I use rsync
18:27:08  <indutny>I guess there is some sort of QoS
18:29:02  <indutny>people do recommend bbcp
18:29:06  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:29:20  <indutny>http://www.slac.stanford.edu/~abh/bbcp/
18:30:22  <tjfontaine>I mean, you need to understand what's going wrong
18:31:23  <indutny>well, perhaps it'd be simpler to just wait 3 hours
18:31:36  <indutny>but I'm afraid of copying 150 gb back after it
18:32:04  <tjfontaine>yup
18:32:16  <indutny>anyway
18:32:20  <indutny>I have no other choice right now
18:32:29  <indutny>because I could possibly waste more time investigating this
18:32:29  <indutny>:)
18:32:36  <indutny>and I should do it while other people are sleeping
18:32:46  <tjfontaine>:P
18:43:04  * eugenewarequit (Remote host closed the connection)
18:43:21  * thlorenzquit (Remote host closed the connection)
18:43:36  <othiym23>tjfontaine groundwater: this is indeed where I see the current state of things
18:43:46  <othiym23>good to see that we're all roughly in alignment / at the same level of anxiety about this ;)
18:44:04  * janjongboomjoined
18:44:04  * calvinfoquit (Quit: Leaving.)
18:44:18  <groundwater>tjfontaine othiym23 i am also open to the idea of providing a minimum intersection between the two approaches in core
18:44:25  <groundwater>and filling in the top with user-space
18:45:10  <groundwater>i.e. AL interface can stay the same, and is still a user-space module
18:45:28  <groundwater>but it's lowest bits plug into the 'raw' tracing interface
18:46:08  * eugenewarejoined
18:48:44  * bradleymeckjoined
18:49:05  <othiym23>groundwater tjfontaine to adapt to how things stand right now requires changes both to the polyfill and to CLS
18:49:33  <othiym23>I agree that it would be nice to confine changes to one piece of the stack, and also that it's fine if the AL api lives in userspace
18:49:43  * mikolalysenkoquit (Ping timeout: 252 seconds)
18:50:04  <tjfontaine>ok, I assure you that 1) you won't be made to look like fools, 2) node will be in a good place to support this feature going forward
18:50:08  <othiym23>but unless we revert back to the old API (which I'm not really recommending) there's still nontrivial work to be done in multiple places to keep NR working, if it's to use the mechanism in core
18:51:06  * eugenewarequit (Remote host closed the connection)
18:52:04  <tjfontaine>I'm not advocating around the AL api in general, that part is between you and well basically just you if I change it such that it's not so much a polyfill instead it's the canonical location of where AL actually lives
18:53:24  <groundwater>this is kinda waht i'm picturing right now https://i.cloudup.com/D2n32suGMo-1200x1200.png
18:53:42  <othiym23>I'm only trying to make clear the scope of work around / how much is affected
18:53:53  <tjfontaine>yup
18:54:03  * mikolalysenkojoined
18:55:12  <tjfontaine>groundwater: that seems about right, though I can see CLS actually being a mixture of AL & Probes
18:55:32  <groundwater>amended https://i.cloudup.com/KhKpNh67cG-3000x3000.png
18:56:05  <groundwater>any re-mixing in user space is possible
18:56:09  <tjfontaine>nod
18:57:20  * eugenewarejoined
18:57:47  * gammafjoined
18:57:54  <groundwater>we should call it LLTM
18:58:22  <trevnorris>tjfontaine: had an epiphany in a dream last night. need to get to work, but will greatly reduce the AL code complexity and remove 100-200 LoC
19:00:04  <tjfontaine>trevnorris: by moving a lot of the work out of core?
19:00:20  <trevnorris>by just removing a lot of work
19:01:01  <tjfontaine>what's the time estimate for doing it?
19:01:36  <trevnorris>soon. couple of hours. going to log out here and zone out. i'll jump back on when it's there.
19:01:38  * trevnorris&
19:01:38  <LOUDBOT>JUST WAKIN' UP IN THE MORNING GOTTA THANK GOD
19:02:03  * kpdecker1joined
19:02:36  * kpdeckerquit (Ping timeout: 264 seconds)
19:16:21  * eugenewarequit (Remote host closed the connection)
19:18:35  * eugenewarejoined
19:25:18  * TooTallNatequit (Ping timeout: 240 seconds)
19:25:30  * calvinfojoined
19:34:03  * thlorenzjoined
19:38:50  * eugenewarequit (Remote host closed the connection)
19:39:26  * zotjoined
19:39:29  * eugenewarejoined
19:39:33  * zotpart
19:41:40  * TooTallNatejoined
19:43:33  * eugenewarequit (Remote host closed the connection)
19:48:36  <indutny>tjfontaine: so should I open pr for node.d ?
19:48:42  <indutny>replacing pointers with uint64_t
20:06:53  * gammafquit (Remote host closed the connection)
20:21:53  * wolfeidaujoined
20:30:51  * xaqjoined
20:33:06  * xaqquit (Read error: Connection reset by peer)
20:33:13  * xaq_joined
20:37:17  * xaqjoined
20:37:46  * xaq_quit (Read error: Connection reset by peer)
20:37:58  * mikolalysenkoquit (Ping timeout: 240 seconds)
20:38:18  * jmar777quit (Read error: Connection reset by peer)
20:38:55  * jmar777joined
20:41:35  <tjfontaine>indutny: I am fine with that I think, though I'd want to run it by dap_, he's still finishing up lunch
20:43:51  * xaqquit (Read error: Connection reset by peer)
20:44:21  * xaqjoined
20:45:43  * defunctzombie_zzchanged nick to defunctzombie
20:46:04  * dshaw_quit (Quit: Leaving.)
20:50:08  * dap_1joined
20:51:20  <indutny>tjfontaine: sounds good
20:53:18  * dap_quit (Ping timeout: 265 seconds)
20:53:54  * mikealquit (Quit: Leaving.)
20:54:03  * wolfeidauquit (Ping timeout: 252 seconds)
20:55:02  <tjfontaine>indutny: just file the PR with clear reasons so he knows what he's looking at and why :)
20:56:57  <tjfontaine>https://github.com/joyent/node/issues/2667
21:00:01  * nrajlichjoined
21:00:48  * TooTallNatequit (Read error: Connection reset by peer)
21:17:04  * jmar777quit (Remote host closed the connection)
21:23:39  * jmar777joined
21:26:57  * euoiajoined
21:29:09  * jmar777quit (Remote host closed the connection)
21:34:45  * defunctzombiechanged nick to defunctzombie_zz
21:39:23  * daviddiasjoined
21:39:30  * praktikymjoined
21:41:35  * daviddia_quit (Ping timeout: 264 seconds)
21:50:04  * bradleymeck_joined
21:56:03  * mikealjoined
21:56:22  * bradleymeckquit (Quit: bradleymeck)
21:56:22  * bradleymeck_changed nick to bradleymeck
22:06:14  * xaqquit (Remote host closed the connection)
22:13:34  * bradleymeckquit (Quit: bradleymeck)
22:14:13  * hzquit (Read error: No route to host)
22:15:32  * hzjoined
22:15:59  * Kakeraquit (Ping timeout: 240 seconds)
22:20:20  * wolfeidaujoined
22:28:39  * ryahjoined
22:30:21  <indutny>tjfontaine: you still there?
22:30:40  <indutny>something like this https://github.com/joyent/node/pull/7250
22:30:45  <indutny>if I haven't made typos in node.d
22:31:28  * mikealquit (Quit: Leaving.)
22:31:44  * mikolalysenkojoined
22:31:49  <indutny>apparently I did
22:32:05  * mikealjoined
22:32:40  * rendarquit
22:34:50  * thlorenzquit (Remote host closed the connection)
22:35:33  * wolfeidauquit (Remote host closed the connection)
22:37:55  * eugenewarejoined
22:39:42  <indutny>tjfontaine: pushed fixes, seems to be working
22:53:52  * hzquit
23:03:38  * praktikymquit (Ping timeout: 240 seconds)
23:06:49  * daviddia_joined
23:08:49  * AlexisMochaquit (Read error: Connection reset by peer)
23:09:05  * wolfeidaujoined
23:09:44  * daviddiasquit (Ping timeout: 245 seconds)
23:12:22  * mikealquit (Quit: Leaving.)
23:14:30  <tjfontaine>indutny: ok I'll have dap_1 look into it
23:14:54  <indutny>thanks man
23:26:12  * petka_quit (Quit: Connection closed for inactivity)
23:26:19  * m76quit (Read error: Connection reset by peer)
23:27:30  * octetcloudquit (Quit: WeeChat 0.4.3)
23:30:12  * wolfeida_joined
23:33:13  * wolfeidauquit (Ping timeout: 240 seconds)
23:34:07  * mikealjoined
23:44:01  <othiym23>tjfontaine: was unref only added to CleartextStream in 0.11.x?
23:44:25  * wolfeida_quit (Remote host closed the connection)
23:45:56  * wolfeidaujoined
23:46:53  * wolfeidauquit (Remote host closed the connection)
23:54:43  * wolfeidaujoined
23:55:16  <tjfontaine>othiym23: erm, that's an excellent question
23:56:47  <tjfontaine>othiym23: without looking directly at CleartextStream, TLSSocket inherits from net so it should be safe
23:57:47  <tjfontaine>othiym23: it doesn't look like it no, but should be reasonable straightforward it seems