00:00:00  <MI6>libuv-master-gyp: #371 UNSTABLE windows-x64 (5/202) smartos-ia32 (3/203) smartos-x64 (3/203) windows-ia32 (4/202) http://jenkins.nodejs.org/job/libuv-master-gyp/371/
00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:02:52  * dap_quit (*.net *.split)
00:02:52  * inolenquit (*.net *.split)
00:02:52  * dsantiagoquit (*.net *.split)
00:02:53  * CAPSLOCKBOTquit (*.net *.split)
00:02:53  * hij1nxquit (*.net *.split)
00:03:51  * LOUDBOTquit (Remote host closed the connection)
00:05:11  * hij1nxjoined
00:05:28  * dsantiagojoined
00:05:29  <trevnorris>tjfontaine: if EEO lands that'll allow me to simplify AL. there's non-trivial logic I hacked in to make AL work as best as possible w/ EE.
00:05:54  <tjfontaine>did you update the PR with it?
00:06:03  <trevnorris>the EEO pr?
00:06:06  <tjfontaine>yes
00:06:15  <tjfontaine>add it as a commit that is?
00:06:41  <trevnorris>nope. the first pr is just to get the functionality in. i'm working on AL right now, but that'll be a different PR.
00:06:43  <tjfontaine>I'm updating my dtrace-demacro branch right now so it's clearer the interface I think we could be aiming for
00:06:51  <trevnorris>i'm trying to keep my pr's under 1000 lines. ;)
00:07:07  <tjfontaine>they feel pretty closely linked though
00:07:17  <trevnorris>not directl
00:07:19  <trevnorris>y
00:07:47  <trevnorris>tjfontaine: w/ your interface, have you considered if a user only wants to track fs.write events, but will they still be able to get a back trace from behind that event?
00:08:14  <trevnorris>poorly put.
00:08:16  <trevnorris>one sec.
00:08:18  <tjfontaine>k thanks :)
00:09:06  <trevnorris>you set a "tracking beacon" onto an async whatnot (e.g. timer), but say you only want to be notified of fs operations...
00:09:37  <trevnorris>you'll still have to internally maintain that "tracking beacon" for every async request then only notify the user when their desired events have been fired.
00:09:40  <trevnorris>follow?
00:09:49  <tjfontaine>right?
00:09:58  <tjfontaine>roughly just like how EEs work today?
00:10:20  <trevnorris>i'm not sure how they'd relate to how EE's work.
00:10:37  <tjfontaine>._events[module][probe](args)
00:10:37  <tjfontaine>?
00:10:59  <tjfontaine>as a first pass the filtering could be done in js
00:11:41  <trevnorris>that doesn't work when you're receiving sockets from TCP requests. those come in straight through libuv
00:12:10  <tjfontaine>huh? we're still firing javascript for async listeners?
00:12:21  <trevnorris>yeah, but most the time it's coming from c++
00:12:25  <tjfontaine>ok?
00:13:43  <trevnorris>pseudo code: trackAsync("fs"); setTimeout(fn() { server.on('data', fn() { fs.stat() }); }); stopTrackingAsync("fs");
00:13:53  <tjfontaine>uh, no
00:14:41  <trevnorris>uh, then what?
00:14:48  <tjfontaine>require('tracing').on('fs', 'write', function(){});
00:15:12  <trevnorris>how do you say you want to stop "tracking" fs" "write" events?
00:15:29  <tjfontaine>.remove('fs', 'write', function(){})?
00:15:51  <tjfontaine>we have a pattern for this today in how we do EEs
00:16:03  <trevnorris>what you're talking about and what AL does are not the same.
00:16:36  * mikolalysenkojoined
00:17:54  <trevnorris>tjfontaine: how does that API allow the user to trace from arbitrary point A until event B is fired?
00:20:51  <tjfontaine>in that pseudo code, how does AL manage to do that?
00:21:16  <trevnorris>the pseudo code was for what I was thinking yours did.
00:21:22  <tjfontaine>no
00:21:54  <tjfontaine>mine takes how (I believe) AL works today, and provides an API that matches what people are used to from node APIs
00:21:59  <tjfontaine>i.e. EEs
00:22:10  * hzquit
00:22:13  <trevnorris>do you have a gist or whatnot that I can look at?
00:22:36  <tjfontaine>so AL just fires create/before/after/error for some .addAsyncListener, as my interpretation was, and then I check the context variable for that state of where it was emitted from
00:22:44  <tjfontaine>stop me if I've misinterpreted what was going on
00:22:58  <tjfontaine>also re: gist
00:22:59  <tjfontaine>[01-07] 00:06:43 <@tjfontaine> I'm updating my dtrace-demacro branch right now so it's clearer the interface I think we could be aiming for
00:23:25  <trevnorris>got that, but didn't know if I could actually go look at your branch
00:24:00  <tjfontaine>it's not ready yet, it's what I started doign
00:24:12  * jirwinjoined
00:24:23  <tjfontaine>have I interpreted how AL works today right?
00:24:43  <trevnorris>on addAsyncListener() it adds a listener to the active listening queue. when an "asynchronous event" (actually async, not EE) is instantiated (e.g. new ReqWrap) the create callbacks in the active queue are fired.
00:24:49  <tjfontaine>so if I did .on('*', '*', function(){}) I would basically be getting everything from AL [minus the ability to return a value from the create cb]
00:25:44  <trevnorris>then it stores all the same callbacks onto the instance so if in the future an async event fires from inside another async event I can load up the same active queue and fire off all the same create callbacks.
00:27:27  <trevnorris>these can be swapped out mid async call, and since AL can be added/removed at any time, each "trace" can have a unique set of create callbacks. depending on how the users sets stuff up.
00:29:23  <trevnorris>so say, for example, AL supported the ability to only fire the create callback for fs write events. i'd still have to load up the active queue onto every async event in the interim so when fs write is called I can have a proper trace of how we arrived there.
00:29:54  * brsonquit (Quit: Lost terminal)
00:30:01  <trevnorris>otherwise all we get is a notification system of when a specific event happens.
00:31:07  * brsonjoined
00:31:42  * zz_karupanerurachanged nick to karupanerura
00:32:34  <trevnorris>tjfontaine: also, each .on() or whatnot would have to return some key so you could remove only a single AL from the active queue. your API shows only a create callback, i assume, and so using the function as the key would work if that's all we were to pass in.
00:33:54  <trevnorris>am I misunderstanding how your implementation works?
00:37:22  * mikealjoined
00:42:21  <groundwater>https://gist.github.com/jacobgroundwater/44f9b0109a06b5d3ca4d
00:42:39  <groundwater>this is my understanding of how AL may be merged into tracing, along with the issue at hand
00:43:37  <trevnorris>groundwater: is the function() { } the unique identifier to remove that specific instance in the future?
00:44:23  <groundwater>trevnorris: i suppose either that, or .on should return a unique identifier
00:44:56  <groundwater>personally, i would return a unique token, however i recognize that's not the EE/node style/interface
00:45:43  <trevnorris>groundwater: but how do you link the "something in here" to the "needs to be available here"?
00:46:02  <trevnorris>you'd need to pass in a unique token to tell tracing that the same data should be avaiable in both places
00:46:10  <groundwater>right, i wasn't trying to solve it in that example, just illustrate the problem
00:46:40  <groundwater>i think some unique token needs to be passed to each create function, and then that same token is reused in before/after/error
00:47:02  <trevnorris>this seems way too verbose.
00:48:01  <trevnorris>groundwater: this requires a lot less code: https://gist.github.com/jacobgroundwater/44f9b0109a06b5d3ca4d#comment-981543
00:48:44  <trevnorris>and since they're all in the same passed object it's a lot less ambiguous what data should be available where.
00:49:53  <groundwater>i'm probably implementation agnostic here, as long as i can utilize async-listener to correlate calls
00:53:57  <groundwater>also, a lot of traces are glued together through event emitters
00:54:13  <groundwater>i think the only things running through async-listeners are timers, process.nextTick, and..
00:54:25  <groundwater>i guess things that go through MakeCallback? is that correct?
00:54:49  <trevnorris>everything that goes through AsyncWrap
00:54:53  <groundwater>what about Socket events?
00:55:01  <trevnorris>which is the base class for HandleWrap, StreamWrap, etc. etc
00:55:06  <groundwater>ahhh
00:55:09  <trevnorris>so, basically everything in node
00:55:16  <groundwater>okay lol
00:55:20  <groundwater>all network stuff
00:55:25  <trevnorris>and fs stuff
00:55:27  <trevnorris>and cares
00:55:37  <trevnorris>and tlx/crypto/...
00:55:39  <trevnorris>*tls
00:55:42  <groundwater>OKAY
00:55:43  <groundwater>haha
00:55:50  <groundwater>jacob -1
00:55:54  <trevnorris>hehe
00:55:55  <groundwater>trevnorris +1
00:57:32  * kazuponjoined
00:57:56  <trevnorris>the c++ side was the easy part. getting it working with our insane EE abstraction still haunts me.
00:57:58  <tjfontaine>ok, so I'm going to get this in further, but basically as far as the nested infrastructure I'm thinking something like: on(module, probe, function(parentId, curId, context) {})
00:58:36  <trevnorris>just please don't tell me those will return event emitters.
00:58:47  <tjfontaine>no, it's EE like, not a real EE
00:59:07  <trevnorris>ok cool
00:59:29  <tjfontaine>so, then if someone wants to stop watching a trace it could construct from the parentId's right?
00:59:53  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:59:53  <groundwater>tjfontaine: i think so
01:00:04  <tjfontaine>that is, their infra could do the lookup necessary, but our code still executes
01:00:14  <groundwater>once there is a v1 i'll give it a try
01:00:15  <trevnorris>what would be the type of parentId?
01:00:24  <tjfontaine>I was assuming uint
01:00:32  <groundwater>sorry i mean a v0.0.0.0.1-alpha
01:00:39  <tjfontaine>atomically updated in AsyncWrap constructor
01:00:57  <tjfontaine>s/atomically/statically/
01:01:53  <trevnorris>every async listener already gets a uid
01:02:03  <tjfontaine>but this isn't for the listener, it's for the AsyncWrap
01:02:11  <tjfontaine>do they already get a uid?
01:02:20  <MI6>joyent/node: isaacs v0.10 * 1be9365 : npm: Upgrade to 1.3.23 - http://git.io/SAU0CA
01:02:22  <trevnorris>yeah. createAsyncWrap().uid === uint
01:02:32  <trevnorris>*createAsyncListener()
01:02:48  <tjfontaine>but a Listener != AsyncWrap?
01:03:18  <trevnorris>AsyncWrap is just a class to funnel async event creation. the listener is the object attached to the AsyncWrap instance
01:04:04  <tjfontaine>ok anyway, so long as we can communicate parent and current I think it's pretty straight forward for consumers to construct the rest
01:04:14  <trevnorris>but, the AsyncWrap instance is actually a TCP instance, or a UDP instance, etc.
01:04:27  <tjfontaine>yes
01:05:37  <trevnorris>tjfontaine: issue. your event tracers are labeled via their js counterparts. but the C++ api doesn't follow that. i.e. there's a lot of code reuse that doesn't have a 1:1 correspondence
01:05:47  <tjfontaine>huh?
01:06:03  * mikolalysenkoquit (Ping timeout: 276 seconds)
01:06:53  <trevnorris>take Server#write. in c++ that fires a writeBuffer, writeAscii, writeHex, etc.
01:07:16  <tjfontaine>those each instantiate a separate AsyncWrap you mean?
01:08:02  <trevnorris>so. Server is an EE, Server#_handle is the AsyncWrap instance.
01:08:18  <tjfontaine>and #write instantiates a WriteReq?
01:08:19  <trevnorris>right now I don't tell the user what's about to happen, just that something's about to happen that will break their stack trace.
01:08:28  * kazuponquit (Remote host closed the connection)
01:08:31  <trevnorris>might
01:08:54  * kazuponjoined
01:09:10  <trevnorris>let me find an example.
01:09:14  <tjfontaine>I mean ultimately when it's out of the streams infra in js and makes it to C++ it should?
01:10:31  <tjfontaine>ultimately DoWrite takes a WriteWrap
01:10:47  <trevnorris>there are certain async operations that don't take a callback, so all that happens is that the data is copied out and passed to libuv, then free'd from the c++ callback.
01:11:12  <trevnorris>sorry, i'm all over the place, like fs operates differently than tcp/pipe/etc.
01:11:49  <tjfontaine>well, they all go through StreamWrap ultimately when there's something to actually be done with a C write()?
01:12:28  <trevnorris>timerwrap, signalwrap and udpwrap go through handlewrap
01:12:36  <trevnorris>not through streamwrap
01:12:40  <tjfontaine>right
01:13:19  * kazuponquit (Ping timeout: 265 seconds)
01:13:27  <tjfontaine>but streamwrap inherits handlewrap?
01:13:34  <tjfontaine>and handlewrap actually matters for open/close?
01:15:02  <trevnorris>yes
01:15:27  <trevnorris>except for ZCtx
01:15:37  <trevnorris>which doesn't inherit from HandleWrap
01:16:08  <tjfontaine>right so the number of specializations is minimal
01:16:23  <trevnorris>yeah. handlewrap covers just about all of them.
01:16:26  <trevnorris>asyncwrap covers them all
01:16:48  <tjfontaine>right but in our descendents we can deliniate what we're firing
01:17:58  <trevnorris>true, but not as they correspond directly to their js api counterparts
01:18:38  <tjfontaine>as reasonably close as it comes though, the context object is still going to be there in the events it can be
01:18:45  <trevnorris>going back again to the Server#close() issue, that happens in a nextTick, and while AsyncWrap can be alerted to when the handle actually closes, it won't be the same time as when the close event is actually emitted
01:18:47  <tjfontaine>before/after/error
01:19:17  * mikealquit (Quit: Leaving.)
01:19:30  <trevnorris>all the places were you say we make a reasonable assumption about what will happen, and fire early, then context won't be loaded.
01:19:39  <MI6>nodejs-v0.10-windows: #421 UNSTABLE windows-x64 (11/608) windows-ia32 (11/608) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/421/
01:19:57  <tjfontaine>can you be more verbose about what you mean?
01:20:06  <tjfontaine>because handle as been set to null already at that point?
01:20:10  <trevnorris>yes
01:20:23  <trevnorris>the handle has been set to null, then the emit happens in a nextTick
01:20:30  <trevnorris>so the context no longer exists at the js level
01:20:49  <trevnorris>it can be recovered from the c++ level since the object isn't actually destroyed until the class is deconstructed
01:21:47  <tjfontaine>so, in translation, your need for libuv fired callbacks wasn't as clear as it could have been until now :)
01:22:25  <trevnorris>heh, yeah. it definitely helps to have things fire when they should. :)
01:23:40  <trevnorris>tjfontaine: also, the net module will give you hell.
01:24:01  <trevnorris>e.g. what if I only want to listen for TCP server creation, not pipes?
01:24:43  <tjfontaine>this goes to the AsyncWrap base class change
01:25:14  <trevnorris>i only got it to work by doing some hackery in the .listen() method.
01:25:28  <trevnorris>i hate it with a passion, but was the only way I could figure out how to get it done.
01:25:37  <trevnorris>if you find a better way, please for the love of good code let me know.
01:25:55  <tjfontaine>so we either have a constructor or AsyncWrap::Create that takes char* module, char* probe -- and then create/before/after/error all fire with those as arguments
01:26:53  <tjfontaine>in the js infrastructure we filter based on that
01:27:55  <trevnorris>issue is that a lot of the callbacks coming through MakeCallback are all just "oncomplete" then the actual "probe" is called from those. so we'd have to refactor a lot of code to make that visible to AsyncWrap
01:28:03  * abraxasjoined
01:28:35  <MI6>nodejs-v0.10: #1697 UNSTABLE linux-x64 (5/608) osx-x64 (1/608) linux-ia32 (6/608) smartos-x64 (12/608) smartos-ia32 (10/608) osx-ia32 (2/608) http://jenkins.nodejs.org/job/nodejs-v0.10/1697/
01:28:35  <tjfontaine>can you give me an example of that? or you mean like timers as an example?
01:29:01  <trevnorris>grep oncomplete lib/net.js
01:29:27  <trevnorris>we just create objects with the same named callback "oncomplete" that all do different things.
01:29:42  <trevnorris>so MakeCallback doesn't actually know what it's calling.
01:32:11  <tjfontaine>most of these come through a HandleWrap/StreamWrap, so we can just set instance variables on those classes, which can then be passed to the WriteWrap or ShutdownWrap
01:32:17  <trevnorris>tjfontaine: or there's "callback" in dns.js
01:32:36  <trevnorris>which also is called through MakeCallback
01:32:49  <trevnorris>the names are pretty much meaningless to let us know what's about to happen
01:32:49  <tjfontaine>right, we can make dns more explicit anyway
01:33:15  <tjfontaine>what do you mean the names are meaningless?
01:34:10  <trevnorris>under the assumption that we know where the call is coming from, then by the name of the symbol for the function that's about to be fired in MakeCallback we could notify
01:34:30  <tjfontaine>hmm?
01:34:56  <trevnorris>how do you plan on firing a "before" callback for a specific event?
01:35:27  <tjfontaine>so, for say: fs:write
01:35:44  <tjfontaine>[but this is generalized really for <streamwrap>:write]
01:36:14  <tjfontaine>StreamWrap descendent class sets _module("fs")
01:36:37  * superjoequit (Ping timeout: 248 seconds)
01:37:02  <tjfontaine>each WriteWrap instantiated after that takes in the constructor the _module as an argument
01:37:11  <tjfontaine>as well as "write"
01:37:27  <tjfontaine>so then when before fires, it can pass _module, _probe to javascript lnad
01:37:28  <tjfontaine>*land
01:39:05  <groundwater>i'm out for now
01:39:06  <trevnorris>i'm still not getting how we determine when, say, an fs,write is triggered.
01:39:07  <tjfontaine>technically WriteWrap could have "write" be a static member since it's already known in advance
01:39:23  <trevnorris>groundwater: see ya
01:39:30  <tjfontaine>trevnorris: we know because WriteWrap transitions the MakeCallback? and they are member variables on that class?
01:40:31  <trevnorris>take fs.write. it has its own writeBuffer implementation apart from StreamWrap::WriteBuffer
01:40:53  <trevnorris>then, if it's an async call, it creates an FSReqWrap, which inherits from ReqWrap
01:40:56  <tjfontaine>but they still have FSWriteWrap?
01:41:00  <tjfontaine>right
01:41:07  <tjfontaine>so we jsut define it in the descendent class?
01:41:17  <tjfontaine>new FSReqWrap(env, "write"
01:41:20  <tjfontaine>it already *has* it
01:41:37  <tjfontaine>we just have to teach it to do somethign with it
01:41:50  <trevnorris>oh.... bloody hell. i see.
01:42:32  * daviddiasjoined
01:42:44  * thlorenzjoined
01:43:11  <tjfontaine>btw I'm goign to send an email out, but everyone seemed ok with thursday at 9am for the weekly meeting
01:43:15  <tjfontaine>9a pst
01:43:19  <trevnorris>coolio.
01:43:23  <trevnorris>alright, i'm out too.
01:43:36  <trevnorris>talk to you in the morning
01:43:37  * trevnorris&
01:43:38  * mikolalysenkojoined
01:43:40  <tjfontaine>k enjoy
01:43:47  <trevnorris>LOUDBOT WHERE ARE YOU????
01:46:11  * kazuponjoined
01:47:02  * daviddiasquit (Ping timeout: 264 seconds)
01:51:14  * dap_1quit (Quit: Leaving.)
01:55:39  * rmgquit (Remote host closed the connection)
02:04:27  * mikealjoined
02:10:16  * mikealquit (Quit: Leaving.)
02:11:51  * mikealjoined
02:15:05  * mikealquit (Client Quit)
02:22:25  * ik_joined
02:22:25  * ik_quit (Client Quit)
02:25:05  * mikealjoined
02:26:10  * rmgjoined
02:32:39  * mikealquit (Quit: Leaving.)
02:35:00  * rmgquit (Ping timeout: 265 seconds)
02:36:02  * kazuponquit (Remote host closed the connection)
02:37:09  * daviddiasjoined
02:38:29  * kazuponjoined
02:38:40  * stagasjoined
02:42:07  * daviddiasquit (Read error: No route to host)
02:42:36  * daviddiasjoined
02:43:37  * c4milojoined
02:46:01  * c4miloquit (Remote host closed the connection)
02:47:02  * daviddiasquit (Ping timeout: 264 seconds)
02:54:11  * c4milojoined
02:57:35  * c4miloquit (Remote host closed the connection)
03:09:15  * kazuponquit (Remote host closed the connection)
03:14:48  * AvianFlujoined
03:18:00  * __rockbot__joined
03:36:12  * CAPSLOCKBOTjoined
03:36:12  * LOUDBOTjoined
03:58:15  * kazuponjoined
04:03:51  * kazuponquit (Ping timeout: 260 seconds)
04:04:24  * brsonquit (Quit: leaving)
04:19:22  * kazuponjoined
04:20:47  * kazuponquit (Read error: Connection reset by peer)
04:21:03  * kazuponjoined
04:30:56  * abraxasquit (Remote host closed the connection)
04:31:18  * daviddiasjoined
04:34:07  * daviddiasquit (Read error: Operation timed out)
04:38:02  * mikolalysenkoquit (Ping timeout: 264 seconds)
04:42:30  * thlorenzquit (Remote host closed the connection)
04:43:05  * thlorenzjoined
04:47:38  * thlorenzquit (Ping timeout: 264 seconds)
04:48:56  * CAPSLOCKBOTquit (Remote host closed the connection)
04:48:56  * LOUDBOTquit (Remote host closed the connection)
04:49:06  <isaacs>trevnorris: ik has been notified of the quietness.
04:49:29  * ikjoined
04:49:31  * LOUDBOTjoined
04:49:31  * CAPSLOCKBOTjoined
04:49:35  * ikpart
04:59:42  * isaacs_mobilejoined
05:01:45  * isaacs_mobilequit (Client Quit)
05:17:45  * mikealjoined
05:20:10  * mikealquit (Client Quit)
05:27:53  * mikealjoined
05:31:57  * lucabjoined
05:34:58  * tjfontai1ejoined
05:36:13  * ircretaryquit (*.net *.split)
05:36:13  * calvinfoquit (*.net *.split)
05:36:14  * trevnorrisquit (*.net *.split)
05:36:26  * trevnorrisjoined
05:36:33  * calvinfojoined
05:38:34  * mikealquit (Quit: Leaving.)
05:39:43  * kaesoquit (*.net *.split)
05:39:43  * tjfontainequit (*.net *.split)
05:39:44  * rchquit (*.net *.split)
05:39:45  * tellnesquit (*.net *.split)
05:39:45  * lucabchanged nick to kaeso
05:41:40  * calvinfoquit (Quit: Leaving.)
05:41:41  * tellnes_joined
05:42:29  * tellnes_quit (Excess Flood)
05:42:32  * ircretaryjoined
05:43:48  * __rockbot__quit (Quit: __rockbot__)
05:44:27  * tellnesjoined
05:47:47  * rchjoined
05:50:56  * tellnes_joined
05:52:17  * tellnesquit (*.net *.split)
05:52:18  * trevnorrisquit (*.net *.split)
05:52:19  * kazuponquit (*.net *.split)
05:52:19  * tellnes_changed nick to tellnes
05:53:35  * kazuponjoined
05:54:09  * trevnorrisjoined
05:59:25  * abraxasjoined
06:02:41  * tjfontai1echanged nick to tjfontaine
06:02:42  * rchquit (Changing host)
06:02:42  * rchjoined
06:02:48  * tjfontainequit (Changing host)
06:02:48  * tjfontainejoined
06:10:55  * m76joined
06:11:38  * AvianFluquit (Ping timeout: 264 seconds)
06:34:33  * indexzerojoined
06:35:59  * octetcloudquit (Ping timeout: 260 seconds)
06:41:29  <MI6>nodejs-v0.10-windows: #422 UNSTABLE windows-x64 (11/608) windows-ia32 (11/608) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/422/
06:45:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
06:49:49  * bajtosjoined
07:01:50  * __rockbot__joined
07:15:29  * mikealjoined
07:15:37  * __rockbot__quit (Quit: __rockbot__)
07:20:14  * daviddiasjoined
07:24:50  * daviddiasquit (Ping timeout: 264 seconds)
07:33:45  * LOUDBOTquit (Ping timeout: 245 seconds)
07:33:45  * CAPSLOCKBOTquit (Ping timeout: 245 seconds)
07:35:44  * LOUDBOTjoined
07:35:49  * CAPSLOCKBOTjoined
07:41:46  * indexzeroquit (Quit: indexzero)
07:50:34  * rendarjoined
08:05:57  * kazuponquit (Ping timeout: 276 seconds)
08:10:05  * AlexisMochajoined
08:11:26  * kazuponjoined
08:14:51  * daviddiasjoined
08:16:24  * calvinfojoined
08:19:26  * daviddiasquit (Ping timeout: 264 seconds)
08:20:18  * daviddiasjoined
08:24:50  * daviddiasquit (Ping timeout: 264 seconds)
08:47:58  * hzjoined
08:49:43  * bajtosquit (Quit: bajtos)
08:55:03  * bajtosjoined
09:05:50  * bajtosquit (Read error: Connection timed out)
09:05:53  <indutny>hey people
09:11:20  * [m76]joined
09:12:14  * m76quit (Ping timeout: 264 seconds)
09:27:07  * calvinfoquit (Quit: Leaving.)
09:29:04  * calvinfojoined
09:31:37  * janjongboomjoined
09:42:42  * calvinfoquit (Quit: Leaving.)
10:11:18  * roxlujoined
10:16:32  * rmgjoined
10:21:25  * rmgquit (Ping timeout: 265 seconds)
10:25:19  <AlexisMocha>hello
10:27:09  <AlexisMocha>any updates on the 0.12 release date?
10:30:34  * daviddiasjoined
10:47:39  * indexzerojoined
10:49:45  * abraxasquit (Remote host closed the connection)
10:55:41  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:04:48  * abraxasjoined
11:06:46  * abraxasquit (Remote host closed the connection)
11:19:16  * [m76]quit (Ping timeout: 260 seconds)
11:32:15  * kazuponquit (Remote host closed the connection)
11:33:39  * m76joined
11:34:47  * daviddiasquit (Remote host closed the connection)
11:35:17  * daviddiasjoined
11:35:42  * janjongboomjoined
11:42:50  * stagasquit (Ping timeout: 264 seconds)
12:21:38  * inolen1quit (Quit: Leaving.)
12:43:44  * kazuponjoined
12:48:42  * kazuponquit (Ping timeout: 276 seconds)
13:00:29  * indexzeroquit (Quit: indexzero)
13:07:49  * abraxasjoined
13:12:45  * abraxasquit (Ping timeout: 276 seconds)
14:03:21  * AvianFlujoined
14:10:45  * mikolalysenkojoined
14:13:50  * hueniversequit (Ping timeout: 245 seconds)
14:27:23  * mikolalysenkoquit (Ping timeout: 260 seconds)
14:35:48  * mikolalysenkojoined
14:42:34  * thlorenzjoined
14:43:00  * daviddiasquit
14:44:21  * mikolalysenkoquit (Ping timeout: 265 seconds)
14:46:44  * daviddiasjoined
14:51:50  * karupanerurachanged nick to zz_karupanerura
15:04:49  * AvianFluquit (Remote host closed the connection)
15:06:45  * pachetjoined
15:15:57  * AvianFlujoined
15:17:16  * AvianFlu_joined
15:18:18  * AvianFluquit (Disconnected by services)
15:18:21  * AvianFlu_changed nick to AvianFlu
15:22:52  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:27:13  * janjongboomjoined
15:30:36  * mikolalysenkojoined
15:38:31  * daviddia_joined
15:40:53  * daviddiasquit (Ping timeout: 248 seconds)
15:44:04  * hzquit
15:45:02  * hzjoined
16:03:16  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:08:13  * mikolalysenkoquit (Ping timeout: 272 seconds)
16:11:24  * mikolalysenkojoined
16:20:47  * rmgjoined
16:23:23  * AvianFluquit (Remote host closed the connection)
16:25:23  * rmgquit (Ping timeout: 252 seconds)
16:43:56  * mcavagejoined
16:45:08  <MI6>nodejs-v0.10: #1698 UNSTABLE linux-x64 (2/608) osx-x64 (1/608) linux-ia32 (3/608) smartos-x64 (8/608) smartos-ia32 (6/608) osx-ia32 (1/608) http://jenkins.nodejs.org/job/nodejs-v0.10/1698/
16:45:17  <trevnorris>morning
16:45:20  <MI6>nodejs-master: #829 UNSTABLE smartos-x64 (6/692) smartos-ia32 (5/692) osx-ia32 (1/692) centos-ia32 (2/692) ubuntu-x64 (2/692) centos-x64 (3/692) http://jenkins.nodejs.org/job/nodejs-master/829/
16:46:08  <tjfontaine>morning
16:46:28  <groundwater>trevnorris tjfontaine morn'
16:49:28  * rmgjoined
17:00:41  * daviddi__joined
17:01:30  <trevnorris>isaacs: ping
17:02:15  * daviddia_quit (Ping timeout: 260 seconds)
17:11:02  * janjongboomjoined
17:11:27  * AvianFlujoined
17:13:39  <isaacs>trevnorris: pong
17:14:29  <trevnorris>isaacs: do you see anything inheretly bad w/ this script: https://gist.github.com/trevnorris/8302731
17:14:36  * AvianFlu_joined
17:14:36  <isaacs>LOUDBOT: welcome back
17:14:37  <LOUDBOT>isaacs: I CAN'T REMEMBER IF I'M GAY OR NOT
17:14:51  <isaacs>LOUDBOT: don't be so binary about it.
17:14:51  <LOUDBOT>isaacs: IS IT NORMAL TO EAT YOUR PERIOD BLOOD
17:14:56  <isaacs>Ok, then.
17:15:04  <tjfontaine>...
17:15:29  * AvianFluquit (Disconnected by services)
17:15:49  * AvianFlu_changed nick to AvianFlu
17:16:06  <isaacs>trevnorris: nothing outright terrible.
17:16:35  <isaacs>trevnorris: it's a bit weird to push more after emitting a 'readable' event already, but meh
17:16:37  <trevnorris>isaacs: that script is blocking the eloop and filling the nextTickQueue. not allowing any of it to be processed. (in v0.10)
17:16:51  <isaacs>trevnorris: yeah, i mean, it's an asshole.
17:17:17  <trevnorris>ok. how would you change it?
17:17:20  <isaacs>trevnorris: this is the problem with synthetic streams: they can be jerks.
17:17:30  <trevnorris>ah, ok.
17:17:33  <isaacs>a stream should be based on some actual amount of data coming from something.
17:17:48  <isaacs>you can make it less bad by generating a big chunk ahead of time that you know will return false from push()
17:18:29  <isaacs>like, this.push(new Buffer(this._readableState.whateverDeterminesThatIForget).fill('hi all'))
17:18:45  <isaacs>then you're just pushing one big thing
17:18:55  <isaacs>it all ends up being in memory anyway
17:19:17  <trevnorris>i'm mainly looking at https://github.com/joyent/node/issues/6065#issuecomment-26612310
17:19:23  <isaacs>it's basically the same as if you did while(socket.write('hi all'));
17:19:25  <trevnorris>which they're complaining about the warning message
17:19:37  <trevnorris>but the minimal case shows that nextTickQueue just isn't allowed to drain.
17:19:44  * TooTallNatejoined
17:20:30  <trevnorris>the "consumer" script is borked because they're not consuming the data
17:20:41  <trevnorris>so of course it's going to get backed up, but I fixed that on my end for testing
17:21:39  <isaacs>trevnorris: so, the _read function passes a size. use that to know how much 'hi all' to send.
17:21:47  <isaacs>it's not the randomness of the bytes that matters, at all. crypto is a red herring.
17:21:54  <isaacs>so, you're correct there :)
17:22:06  <isaacs>I've gotta head to SF.
17:22:12  <trevnorris>fun. see ya later
17:23:48  * hueniversejoined
17:26:30  * sindresorhus_joined
17:28:16  * julian_duquejoined
17:28:38  * c4milojoined
17:28:39  * daviddiasjoined
17:30:11  * swajrjoined
17:30:47  * dap_joined
17:30:50  * daviddi__quit (Ping timeout: 245 seconds)
17:34:20  * sindresorhusquit (Ping timeout: 246 seconds)
17:34:21  * julianduquequit (Ping timeout: 246 seconds)
17:34:21  * sindresorhus_changed nick to sindresorhus
17:34:21  * swajquit (Ping timeout: 246 seconds)
17:35:27  * iamstefquit (Ping timeout: 240 seconds)
17:35:46  * iamstefjoined
17:41:04  * inolenjoined
17:43:42  * inolen1joined
17:43:50  * nickleefly_joined
17:44:13  * calvinfojoined
17:46:34  <trevnorris>tjfontaine: ping
17:47:40  <tjfontaine>pong
17:47:42  * janjongb_joined
17:48:37  <trevnorris>tjfontaine: in this synthetic stream (as isaacs calls it) it has a ._readableState.buffer which is filling up when .push() is used. but when I internally check the buffer.length it's 0.
17:48:46  <trevnorris>so it's like the two are disconnected somehow
17:49:16  <trevnorris>and since internally it sees there's zero buffer length it continues to call nextTick, but the buffer length on the synthetic stream continues to grow
17:49:53  <trevnorris>I can't figure out why the "buffer" array isn't the same for the two.
17:50:52  * nickleeflyquit (Ping timeout: 240 seconds)
17:50:53  * Damn3dquit (Ping timeout: 240 seconds)
17:50:54  * janjongboomquit (Ping timeout: 240 seconds)
17:50:59  * Domenic_quit (Ping timeout: 240 seconds)
17:51:00  * inolenquit (Ping timeout: 240 seconds)
17:51:04  * Damn3djoined
17:51:04  * nickleefly_changed nick to nickleefly
17:51:34  <trevnorris>oh, wait. ok. so the pipe's origin .readableState.buffer is filling.
17:51:44  <trevnorris>they are being written to the dest, but the buffer array isn't ever being cleared.
17:51:48  * Damn3dchanged nick to Guest75589
17:51:52  * Guest75589quit (Changing host)
17:51:53  * Guest75589joined
17:52:04  * Domenic_joined
17:53:38  <MI6>libuv-master: #419 FAILURE windows (4/202) http://jenkins.nodejs.org/job/libuv-master/419/
17:53:58  * brsonjoined
17:54:43  <tjfontaine>I'm not sure at the moment, without context switching into the streams api interface, I can probably in an hour?
17:55:08  <trevnorris>tjfontaine: nm it. just helping talking through it all. :)
17:56:01  * jmar777joined
17:59:04  <trevnorris>wtf. before flowing a pipe _readableState.ranOut must be true, which will allow flow() to run. but ranOut is only set to true when flow() has run.
17:59:14  <trevnorris>so... how is ranOut supposed to be set to true?
18:00:50  * octetcloudjoined
18:03:14  * dap_1joined
18:04:45  * dap_quit (Ping timeout: 252 seconds)
18:05:27  <isaacs>trevnorris: oh, so, when you're piping, then push() doesn't even bother to put it in the readable's array
18:05:38  <isaacs>trevnorris: it skips over that step, and just writes it directly
18:05:46  <isaacs>trevnorris: (iirc)
18:05:54  <isaacs>that might be a stream3 thing, though i'm not sure
18:05:59  <trevnorris>isaacs: except that _readableState.buffer.length continues to grow
18:06:05  <trevnorris>(this is for v0.10)
18:06:05  <isaacs>hrm..
18:06:09  <isaacs>yeah...
18:06:31  <isaacs>i think, if there is a workaround, and the more thorough fix is "use streams3", then that's acceptable.
18:06:38  <isaacs>streams2 have other problems as well.
18:06:56  <trevnorris>can we bring streams3 to v0.10?
18:09:42  * Guest75589quit (Ping timeout: 240 seconds)
18:11:23  <trevnorris>isaacs: yeah. so on v0.10 .pipe is properly sending all the data chunks, but for some reason _readableState.buffer isn't being cleared as they're being written.
18:11:47  * Damn3d_joined
18:11:51  * piscisaureusjoined
18:13:54  <trevnorris>isaacs: ah ha. got it. so it's entering flow() in _stream_readable, but never getting past the while()
18:19:24  * c4milo_joined
18:20:35  * c4miloquit (Ping timeout: 272 seconds)
18:21:00  * dap_1quit (Quit: Leaving.)
18:21:18  <trevnorris>isaacs: so, doRead in Readable#read() is always true, which always calls _read(), which always pushes more data onto the buffer.
18:21:40  * mikolalysenkoquit (Ping timeout: 245 seconds)
18:21:42  <trevnorris>hence, never allowing the while() loop to exit.
18:22:29  * dap_joined
18:24:25  <isaacs>trevnorris: that makes sense.
18:24:48  <trevnorris>doRead is being set to true here: if (state.length - n <= state.highWaterMark)
18:24:57  <isaacs>it's like doing while(process.stderr.write('foo'))
18:25:59  <trevnorris>though. shouldn't state.reading == true?
18:26:06  <trevnorris>that would set doRead = false
18:27:09  <isaacs>trevnorris: no, because the _read() method is returning? hrm. i dunno. it's been a while.
18:27:14  <isaacs>0.10 is already paged out
18:27:19  <trevnorris>heh
18:29:03  <trevnorris>state.reading = false in readableAddChunk(). but why it's being set there, but not in addToFront, i'm not sure. i'll experiment.
18:29:55  <trevnorris>well suck. that didn't work.
18:35:43  <isaacs>trevnorris: you can mostly ignore the addToFront stuff. that's for stream.unshift(), which is a consumer method, unlike stream.push() which is a producer method.
18:35:54  <trevnorris>ok
18:35:55  <isaacs>producer actions affect "Reading" state
18:35:58  <isaacs>consumer actions do not.
18:36:28  <trevnorris>isaacs: ok. I just cant see how to break out of the while loop
18:37:11  <trevnorris>should we limit the amount to be written before breaking the while loop at the HWM?
18:37:34  <isaacs>that'd probably be a good approach
18:37:58  <trevnorris>cool. i'll give it a go.
18:38:02  <isaacs>i mean, basically, there's this optimization your'e seeing, which is a good heuristic if you're not being ridiculous, but people are ridiculous, so it falls over.
18:38:14  <isaacs>srsly, who writes 100TB of crap in a single fast loop?
18:38:14  <trevnorris>haha, yeah. exactly. :)
18:38:19  <isaacs>that's just a jerk move
18:43:08  * janjongb_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:45:11  <trevnorris>ok cool. that breaks out well enough. now. to get flow() to run again afterwards...
18:45:41  * vigithjoined
18:47:32  * inolen1quit (*.net *.split)
18:47:48  <vigith>uv_accept(server, (uv_stream_t *) client);
18:47:53  * inolenjoined
18:48:00  <vigith>now i would like to get the client ip.. how can i do it?
18:48:27  * c4milo_quit (Remote host closed the connection)
18:49:06  * defunctzombie_changed nick to defunctzombie
18:49:06  * defunctzombiequit (Changing host)
18:49:06  * defunctzombiejoined
18:50:21  * thlorenzquit (Remote host closed the connection)
18:51:49  * inolen1joined
18:57:04  * c4milojoined
19:01:18  * inolenquit (Ping timeout: 240 seconds)
19:01:20  * Damn3d_quit (Ping timeout: 240 seconds)
19:01:58  * dap_quit (Quit: Leaving.)
19:02:40  * dap_joined
19:06:13  * daviddiasquit (Remote host closed the connection)
19:06:17  * Damn3djoined
19:07:12  * Damn3dquit (Changing host)
19:07:12  * Damn3djoined
19:08:47  * mikealquit (Quit: Leaving.)
19:10:37  * abraxasjoined
19:14:38  * abraxasquit (Ping timeout: 240 seconds)
19:17:54  * mcavagequit (Remote host closed the connection)
19:31:23  <trevnorris>isaacs: oy... yeah. don't think i'm going to take the time to fix this.
19:31:32  <trevnorris>found a solution, that breaks a dozen other tests..
19:31:33  <trevnorris>.
19:34:58  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:35:15  <MI6>joyent/node: Ben Noordhuis master * f057c70 : build: unconditionally disable -Werror - http://git.io/Qql_Zw
19:35:18  * piscisaureusjoined
19:40:10  <indutny>hey people
19:40:13  <indutny>how are we?
19:40:20  <indutny>vigith: still around?
19:40:44  <indutny>vigith: https://github.com/joyent/libuv/blob/master/include/uv.h#L800
19:41:07  <isaacs>trevnorris: yeah.
19:41:10  <isaacs>trevnorris: i apologize.
19:41:42  <trevnorris>isaacs: ok. well, i'm considering this unsolvable unless we backport streams3.
19:42:08  <trevnorris>issue is that the Writable is only aware of the single buffer that's being written out, so it never detects it has surpassed the HWM
19:42:12  <trevnorris>so it never emits drain
19:42:36  <trevnorris>so the readable will never start reading again (if I break out of the while loop when the actual HWM has been read in)
19:43:39  <isaacs>trevnorris: i see, because the writable is always returning true from write()?
19:43:47  <trevnorris>yeah
19:43:53  * janjongboomjoined
19:44:18  <trevnorris>readable sets an event on the 'drain' event, but it never is fired because as far as the writable is concerned all the data was written out immediately
19:44:36  <trevnorris>but the reable retains that data until after the drain event has fired.
19:45:18  <isaacs>trevnorris: ugh
19:45:31  <isaacs>trevnorris: maybe do a setImmediate to do it, instead fo a nextTick?
19:45:31  <trevnorris>my solution to fix the issue was to break out of the while after reading in HWM bytes, removing state.flowing and changing the nextTick in write() to a setImmediate()
19:45:38  <trevnorris>which allows the eloop to continue
19:45:41  <isaacs>trevnorris: right
19:45:44  <trevnorris>but that caused hell
19:45:50  <isaacs>hm.
19:46:06  <trevnorris>because in some cases data needs to be processed before the eloop continues
19:46:13  <trevnorris>at least, that's what the tests say.
19:47:20  <isaacs>right
19:47:24  * mcavagejoined
19:47:35  <isaacs>well... those tests might be able to be changed.
19:47:50  * mikealjoined
19:47:52  <isaacs>if they're just verifying behavior, but the behavior they're verifying isn't corret, then the test is buggy also.
19:48:14  <trevnorris>ok. i see what you're saying.
19:48:14  <isaacs>or, you could conditionally do The Thing, only when hwm is surpassed by 5x or something
19:48:31  <isaacs>so it's only in cases of egregious dickheadedness
19:48:39  <trevnorris>heh
19:49:18  <trevnorris>i'll take another look later. have more stuff need to do for the v0.12 release
19:49:54  <isaacs>great, that's more important anyway.
19:50:09  <isaacs>trevnorris: one way to Fix All The Bugs in 0.10 is to release 1.0, so that 0.10 is no longer supported :)
19:50:20  <trevnorris>hahah. i like that
19:50:21  <isaacs>trevnorris: releasing 0.12 will Fix All The Bugs in 0.8
19:50:28  <trevnorris>heh
19:50:41  <isaacs>and will even Fix All The Security Bugs in 0.6
19:52:27  <MI6>nodejs-master: #830 UNSTABLE smartos-x64 (5/692) smartos-ia32 (6/692) centos-ia32 (3/692) ubuntu-x64 (1/692) ubuntu-ia32 (1/692) centos-x64 (3/692) http://jenkins.nodejs.org/job/nodejs-master/830/
19:54:06  * thlorenzjoined
19:55:57  * mikealquit (Quit: Leaving.)
19:58:45  * mikealjoined
19:58:49  * m76quit (Read error: Connection reset by peer)
19:58:49  <tjfontaine>something like that
19:59:00  <tjfontaine>speaking of, did everyone get my email last night regarding the call on thursday?
20:02:55  <isaacs>I got it :)
20:03:19  <isaacs>tjfontaine: if you send a new invite, i'll cancel mine, and then you'll be the meeting owner
20:05:02  * superjoejoined
20:13:04  * m76joined
20:14:27  * mikealquit (Quit: Leaving.)
20:14:35  * mikealjoined
20:18:42  * mikealquit (Client Quit)
20:18:52  * mikealjoined
20:18:58  * m76quit (Read error: Connection reset by peer)
20:42:46  * m76joined
20:50:54  <tjfontaine>isaacs: okey dokey
20:52:48  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:06:17  <vigith>indutny: thank you
21:08:11  * stagasjoined
21:09:17  * mikolalysenkojoined
21:09:29  <indutny>vigith: you're welcome
21:17:01  * inolen1quit (Read error: Connection reset by peer)
21:18:00  * inolenjoined
21:24:15  <trevnorris>groundwater: ping
21:24:16  <vigith>i am forking a process every time i get a tcp connection asking to run a command.. is it ok to have both tcp server and the process to be in same default loop? (the result of spawned process is returned to the tcp client)..
21:24:47  <vigith>or am i doing something really stupid? :-)
21:31:35  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:39:52  * jmar777quit (Remote host closed the connection)
21:49:01  <tjfontaine>indutny: anything you need to get into libuv 0.10 before a release?
21:49:13  <indutny>tjfontaine: no
21:49:17  <indutny>green light for you! :)
21:49:20  <tjfontaine>heh ok
21:49:57  * mikolalysenkoquit (Ping timeout: 272 seconds)
21:53:14  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
21:56:06  * TooTallNatejoined
21:57:09  * brsonquit (Quit: Lost terminal)
21:57:42  * brsonjoined
21:57:55  * superjoequit (Quit: Leaving)
22:03:37  <MI6>joyent/libuv: tjfontaine created tag v0.10.22 - http://git.io/EtIxQw
22:03:40  <MI6>joyent/libuv: Timothy J Fontaine v0.10 * 97eda7f : Now working on v0.10.23 (+1 more commits) - http://git.io/U5xzRw
22:05:40  * mikolalysenkojoined
22:06:08  <MI6>joyent/node: Timothy J Fontaine v0.10 * 30b3bc2 : uv: Upgrade to v0.10.22 - http://git.io/S7dAzA
22:08:07  * brsonquit (Ping timeout: 246 seconds)
22:08:25  * daviddiasjoined
22:11:20  * mikolalysenkoquit (Ping timeout: 252 seconds)
22:14:31  * rmgquit (Remote host closed the connection)
22:16:35  <MI6>nodejs-v0.10: #1699 UNSTABLE linux-x64 (4/608) osx-x64 (2/608) linux-ia32 (2/608) smartos-x64 (6/608) smartos-ia32 (7/608) osx-ia32 (1/608) http://jenkins.nodejs.org/job/nodejs-v0.10/1699/
22:26:03  * m76quit (Read error: Connection reset by peer)
22:27:08  <trevnorris>groundwater: ping
22:27:28  <trevnorris>tjfontaine: ping also
22:27:34  <tjfontaine>semi-pong
22:27:43  <trevnorris>heh
22:27:50  <tjfontaine>what's up?
22:28:22  <trevnorris>just want to get your feedback on EEO. i don't think I'll be able to fix all the hapi test fail cases w/o manually listening in on the EE.
22:29:10  <tjfontaine>erm, what's happening with hapi that makes that a requirement? that is to say, how is it they're utilizing domains in such a way that we are currently breaking them?
22:29:13  <trevnorris>AsyncListeners was meant to allow users to see what was happening in core. I got carried away w/ that thinking, well then. we can trace everything, forgetting the _in core_ part.
22:30:02  <trevnorris>the way they're manually using domain.enter/exit to capture stuff in the execution of an EE.
22:30:19  <trevnorris>i might be able to fix this w/ my current rework of AL, but i'm not 100% sure it will
22:30:56  <tjfontaine>why/how is AL breaking that? does that mean that everyone doing enter/exit work in EEs are also broken?
22:31:08  <trevnorris>no. that's the thing I don't get.
22:31:38  <trevnorris>I traced through all of hapi's code and all the proper domains were in place. but for some reason their test still reports the error escaped the domain.
22:32:53  * brsonjoined
22:33:20  <trevnorris>also, i firmly believe that just using simple assert is the best way to go. I had to trace through hapi, request, async, and who known how many other modules before it worked.
22:33:47  <tjfontaine>ok well I'm writing "prose" right now, when I'm done with that I guess I can try and context switch into that, are you still just using their test suite?
22:34:06  <trevnorris>i'm half way between that and the AL rewrite.
22:34:39  * rmgjoined
22:34:50  <tjfontaine>I vote for just continue with the AL rewrite I think
22:35:28  <tjfontaine>I did push an update of my PR that indicates some of what I'm envisioning for a user facing api
22:36:14  <tjfontaine>trevnorris, groundwater: https://github.com/joyent/node/pull/5940/files this only addresses most of the static probes at the moment
22:38:47  <trevnorris>tjfontaine: and will those be a noop if not being listened for?
22:40:52  <tjfontaine>trevnorris: https://github.com/joyent/node/pull/5940/files#diff-d057cd3202b378894d5ae0ba345d537dR31
22:40:52  <tjfontaine>they have thes ame amount of overhead, if not less, since more of the object lookups are happening in the JIT context instead of in C++
22:41:51  <tjfontaine>oh right
22:42:09  <tjfontaine>indutny: yes, just go ahead and update openssl in master, that's fine
22:42:21  <indutny>yay!
22:42:25  <tjfontaine>brb
22:42:51  <indutny>tjfontaine: what about v0.10 ?
22:43:01  <indutny>should we do it there as well?
22:43:06  <indutny>not that I care much
22:43:15  <indutny>but it seems like a security vulnerability :)
22:43:30  <trevnorris>and I thought you were talking more of adding a field like AsyncWrap::AsyncWrap(Environment*, Handle<Object>, char* type)
22:43:40  <trevnorris>erm, char* module
22:43:49  <MI6>joyent/node: Fedor Indutny master * 3905986 : deps: update openssl to 1.0.1f - http://git.io/vjCx0g
22:43:57  <trevnorris>then in AsyncWrap::MakeCallback add char* type
22:45:18  <trevnorris>honestly I'd rather have an enum in AsyncWrap like: enum AsyncModules { TCP = 0, UDP = 1, etc. } then simply add that to a field in the class constructor.
22:46:01  <trevnorris>it'd be wicked fast to check, and using the state sharing technique we'd be able to set flags for what modules we actually want to listen for.
22:47:27  * hzquit
22:56:18  <octetcloud>so, v0.10 cluster bug (not in 0.11)
22:57:13  <octetcloud>if a worker binds on port that's in use... even if that port later becomes free, it can never be listened on again, its always reported as busy, though it no longer is
22:58:41  <octetcloud>looks like its because a handle created for a key is never cleared if the handle had an unrecoverable error. doesn't exist in v0.11
22:59:09  * jmar777joined
22:59:33  * TooTallNatequit (Ping timeout: 252 seconds)
23:06:06  * rendarquit (Quit: Leaving)
23:09:11  <MI6>nodejs-master: #831 UNSTABLE smartos-x64 (4/692) smartos-ia32 (4/692) osx-ia32 (1/692) centos-ia32 (3/692) ubuntu-ia32 (2/692) centos-x64 (4/692) http://jenkins.nodejs.org/job/nodejs-master/831/
23:15:59  * TooTallNatejoined
23:17:34  <tjfontaine>octetcloud: can you file an issue, seems pretty straight forward
23:18:22  <tjfontaine>indutny: ya, I guess since 1.0.1e is in v0.10 we should, it's just that I don't necessarily want to include the -cli build artifact
23:18:47  <tjfontaine>trevnorris: I haven't even come close to doing the AL parts of that, still solidifying how I would expect the user interface to work
23:19:13  <trevnorris>ok
23:19:17  <tjfontaine>trevnorris: enums are nice, but limit us on the 3rd party binary addon front
23:20:11  <trevnorris>tjfontaine: AsyncWrap is for core only. enum'ing what classes wer're allowing to inherit isn't a problem.
23:20:15  <tjfontaine>we could relegate those people to only use the js only style, but that may be limiting for them
23:21:07  <tjfontaine>trevnorris: as a first pass I'd like to experiment with both char* and enum and see what range we're talking for overhead difference when we get there
23:21:24  <tjfontaine>trevnorris: but being able to filter at the C++ layer is definitely the place we want to get to
23:21:33  <tjfontaine>[for those type of events]
23:21:44  * AvianFluquit (Ping timeout: 252 seconds)
23:22:53  <indutny>tjfontaine: yeah
23:23:01  <indutny>I'll try to choose less invasive method for it :)
23:23:07  <tjfontaine>:)
23:26:28  * CoverSlidejoined
23:34:23  * paulfryzeljoined
23:38:36  <octetcloud>@tjfontaine: I'll report, repro is easy. fix, not so sure. listen is done in worker, worker net.js might have to tell cluster.js, which would send a msg to master... lots of work.
23:40:29  <tjfontaine>octetcloud: sorry didn't mean the fix would be straight forward, but that bug itself seemed pretty well understood, at the very least having it in the repo will help others (and us) remember it in the case someone else comes looking for it
23:41:16  * thlorenzquit (Remote host closed the connection)
23:52:11  * mikealquit (Quit: Leaving.)
23:52:14  * pachetquit (Quit: leaving)