00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:04:17  * paulfryzelquit (Remote host closed the connection)
00:04:56  * paulfryzeljoined
00:09:13  * paulfryzelquit (Ping timeout: 252 seconds)
00:17:28  <groundwater>tjfontaine trevnorris ACK
00:17:47  <trevnorris>groundwater: sec. think I have something figured out.
00:18:05  <trevnorris>now, for the horror of running the tests after a massive change...
00:24:11  <trevnorris>groundwater: here's my current insanity: https://github.com/trevnorris/node/compare/al-fix-storage
00:24:27  <trevnorris>if you want to take a look, and try to understand wtf i'm trying to do.
00:24:35  <trevnorris>(not so sure myself :P
00:24:54  <groundwater>trevnorris can you summarize this?
00:25:06  <trevnorris>groundwater: um..... yeah. give me 5 minutes.
00:25:57  * AvianFlujoined
00:25:57  <groundwater>tjfontaine: compiling now
00:26:25  * AvianFluquit (Read error: Connection reset by peer)
00:26:43  * c4miloquit (Remote host closed the connection)
00:26:45  <tjfontaine>groundwater: heh, it's still not perfect, but it's describing the API in my head
00:26:57  * AvianFlujoined
00:27:24  <trevnorris>groundwater: each AsyncListener creates a new instance, each w/ their own uid. so every context now stores its own array of the asyncQueue as it was attached at the time the async event was created.
00:27:51  <trevnorris>groundwater: but also there's the asyncStorage array which uses the uid to store the storage from the create callback in case it was different
00:28:27  <trevnorris>that way we can always use the same AsyncListener instance, by separating the storage from the instance.
00:28:31  <tjfontaine>would it make the code lighter for you if we did the (parentId, thisId) mechanism instead?
00:28:41  <tjfontaine>instead of having to manage the storage yourself?
00:29:00  <trevnorris>there's also _asyncFlags which stores the flags of what callbacks are available to run.
00:29:46  <trevnorris>tjfontaine: tell you the truth, i still don't get the parentId, thisId thing. is parentId the Id of the context that called the "thisId" ?
00:30:16  <tjfontaine>obj.uid == thisId, parentId is one level up (if it exists)
00:30:36  <trevnorris>already done
00:30:51  <trevnorris>i store the current executing context (i.e. parent) when the "before" runs
00:30:59  <tjfontaine>right I know that logic exists today, I'm just wondering if the lift and maint required on the storage portions is necessary for core
00:31:00  <trevnorris>then unload it when the "after" runs
00:31:03  <tjfontaine>or if it's somethign consumers should be doing
00:32:06  <groundwater>tjfontaine how do i register a callback for a probe? require('tracing').on?
00:32:09  <trevnorris>since you can createAsyncListener() and it returns a single object you can add/remove at will. the storage portion needs to be separated from it, but also tied to the context for which it is running
00:32:49  <trevnorris>so to do that outside of core the user would have to create a table of sorts to maintain that relationship, but then gc wouldn't allow for cleanup of any of the contexts.
00:32:52  <tjfontaine>groundwater: right now it's require('tracing').register, but the interface is brittle and there's no on() at the moment, though you probably have the chops to implement it yourself if you decided to
00:33:38  <tjfontaine>trevnorris: I'm just wondering if we need to store the context, vs keep track of our context, our id, and our parent's id
00:34:26  <trevnorris>i think we're confusing terms.
00:34:45  <trevnorris>other than the context that is currently executing callbacks, i'm not tracking anything else.
00:34:54  <trevnorris> /callbacks/context/
00:35:05  <trevnorris>wait. nm. it was right.
00:35:18  <tjfontaine>how many levels deep do we keep at any time?
00:35:47  <trevnorris>N
00:36:10  <trevnorris>well, we don't "keep" anything
00:36:13  <trevnorris>that's up to the user.
00:36:35  <trevnorris>we just attach the "parentId" (if you will) to every anonymous callback.
00:36:53  <trevnorris>so if the user wants, they could write code that traces back to the beginning of script execution.
00:37:19  <tjfontaine>ok, I'll check that part out more closely as I try and get them into terms of this new api
00:37:33  <trevnorris>tjfontaine: like this: https://github.com/AndreasMadsen/trace
00:37:44  <trevnorris>he uses the AL API to create an infinitely long stack trace.
00:37:51  <trevnorris>but AL doesn't do any of that itself.
00:41:17  * kazuponjoined
00:51:30  * zz_karupanerurachanged nick to karupanerura
00:55:01  <tjfontaine>groundwater: I updated to include a simple on/removeListener example, and here's a simple test script https://gist.github.com/tjfontaine/8309764
00:58:52  <trevnorris>ok. except for timers, i pretty much have it working. freaking timers.
01:07:55  <trevnorris>groundwater: sorry, this is probably about to get a lot slower before it gets faster. :P
01:08:04  <trevnorris>but, all in good time. :)
01:08:22  <groundwater>trevnorris: heh!
01:08:27  <groundwater>NO PROBLEM
01:08:28  <LOUDBOT>YOU CLIMB ROPES LIKE OLD PEOPLE FUCK
01:08:53  <trevnorris>LOUDBOT: jokes on you. I can't climb a rope at all.
01:08:54  <LOUDBOT>trevnorris: YA BETTA CHECK YOURSELF BEFORE YOU WRECK YOURSELF
01:09:01  <trevnorris>... wait... um.
01:12:00  <trevnorris>tjfontaine: ok. i'll concede. the debugger repl has proven useful this last week. but console.log() is for Real Men
01:12:08  <trevnorris>wait... um Real People
01:12:43  <trevnorris>or um... Real Humans
01:12:46  <tjfontaine>if you say so, I probably wouldn't use the repl either :)
01:12:59  <trevnorris>heh
01:13:20  <groundwater>tjfontaine: success https://gist.github.com/tjfontaine/8309764
01:13:23  <tjfontaine>I'm excited to get dtrace|etw provider into core though, it means a lot of awesome things
01:14:01  <tjfontaine>sweet
01:15:48  * mcavagequit (Remote host closed the connection)
01:16:19  * octetcloudquit (Ping timeout: 252 seconds)
01:19:19  * isaacs_mobilejoined
01:21:29  <trevnorris>HAHAHAHAH ALL TESTS PASSS!!!!
01:21:30  <LOUDBOT>ALL RIGHT LISTEN UP COCKGOBBLER
01:24:55  * isaacs_mobilequit (Remote host closed the connection)
01:24:59  * kazuponquit (Remote host closed the connection)
01:28:48  <trevnorris>groundwater: strange. there's zero slow down from the previous implementation. would not have expected that. at all.
01:28:57  * kazuponjoined
01:29:45  <trevnorris>ok. so maybe like 2-3%, but still in the margin of error.
01:33:12  * dap_quit (Quit: Leaving.)
01:35:03  * mikealjoined
01:36:06  * paulfryzeljoined
01:37:41  * abraxasjoined
01:40:14  * paulfryzelquit (Ping timeout: 240 seconds)
01:43:06  <trevnorris>tjfontaine: all tests are passing here: https://github.com/joyent/node/pull/6820
01:43:18  <trevnorris>though I"m going to throw up the branch on core so windows can run its thing
01:43:19  <tjfontaine>all hapi tests/
01:43:26  <trevnorris>oooh. no no no .
01:43:28  <trevnorris>all core tests.
01:43:32  <tjfontaine>k
01:43:51  <tjfontaine>btw why `new Array()`?
01:43:53  <trevnorris>dude, hapi is seriously one mother of a beast. i'm going to need hueniverse's help to track down wtf is going on there.
01:44:12  <trevnorris>faster that way for sparse arrays
01:44:35  <tjfontaine>oh because uid's won't be sequential
01:44:39  <trevnorris>yup
01:44:47  <tjfontaine>could use a comment block there for that, please and thank you :)
01:45:08  * rmgquit (Remote host closed the connection)
01:45:09  <tjfontaine>otherwise someone might come along later and not know why and fuck us :)
01:45:22  <trevnorris>true true. comming
01:45:24  <trevnorris>min
01:45:26  <trevnorris>lkdflsajflaskdjf
01:45:27  <tjfontaine>take your time
01:46:17  * thlorenzjoined
01:46:35  <tjfontaine>trevnorris: also, we when you get some rest from today, we could use a BigTheory comment block (somewhere) that describes the pieces of this
01:47:43  <trevnorris>tjfontaine: ah, think I know what you mean. ok.
01:48:50  * c4milojoined
01:50:17  <MI6>joyent/node: trevnorris created branch al-fix-storage - http://git.io/go8-3w
01:53:03  * c4miloquit (Ping timeout: 240 seconds)
02:04:18  <vigith>can i wrap client uv_tcp_t into a different structure and use container_of(...) trick to get the wrapper struct in read_cb ?
02:04:38  <vigith>whenever i do it.. i am seeing a difference of 24 bytes in the wrapper address
02:04:49  <tjfontaine>vigith: that's the pattern often used in node
02:05:21  <vigith>is there any reason i am seeing the address of wrapper offsetted a little bit
02:06:23  <tjfontaine>difficult to say, easier if you can show code in a repo or gist
02:07:30  <vigith>tjfontaine: http://pastebin.com/AcJ0iXCP
02:13:51  * daviddiasquit (Remote host closed the connection)
02:14:34  * daviddiasjoined
02:15:49  * rmgjoined
02:15:58  <vigith>i tried couple of times.. i think there is something wrong the way i wrap it.. or type cast it
02:16:27  <vigith>any help would be great.. i have been banging my head for a while :-)
02:16:55  <tjfontaine>I'm kinda neck deep in something else right now, but as soon as I can context switch out I will devote some cycles to it
02:17:37  <trevnorris>tjfontaine: after I've pushed a branch, will it be built under node-review in jenkins?
02:17:41  * mikealquit (Quit: Leaving.)
02:17:57  <trevnorris>pushed a branch to joyent/node that is
02:18:38  * daviddiasquit (Ping timeout: 240 seconds)
02:19:02  <tjfontaine>yes
02:19:50  <vigith>thank you
02:23:31  <trevnorris>indutny: i think the openssl upgrade might have done something not nice to the hapi tests
02:23:33  <trevnorris>i'm going to check
02:25:26  * rmgquit (Ping timeout: 240 seconds)
02:26:25  * mcavagejoined
02:27:07  <trevnorris>indutny: nm.
02:31:07  * mcavagequit (Ping timeout: 252 seconds)
02:31:28  <trevnorris>hueniverse: yeah. starting tomorrow or whatever. i'm going to need your help determining what's going on w/ all these tests.
02:33:50  <hueniverse>trevnorris: I should be around
02:34:14  <trevnorris>hueniverse: i had to check out v1.20.0
02:34:30  <trevnorris>latest master kept giving me some object method not found error
02:34:51  * wavdedjoined
02:34:54  <trevnorris>tjfontaine: this is one reason why I need EEO: https://github.com/joyent/node/blob/master/lib/domain.js#L169-L174
02:35:28  <trevnorris>tjfontaine: i'm depending on obscure functionality to get net working because it doesn't instantiate itself until .listen()
02:35:37  <hueniverse>trevnorris: I'll look later tonight
02:35:48  <tjfontaine>in lots of cases the handle wont' be created on instantiation
02:36:24  <trevnorris>yeah.... trust me. I found that out.
02:36:43  <trevnorris>hueniverse: fwiw, i'm working from this patch: https://github.com/joyent/node/pull/6820
02:36:50  * paulfryzeljoined
02:36:57  <tjfontaine>I'm not opposed to EEO, I just want to make sure it's absolutely necessary, and that for now the things that have already landed are in a good shape [if the only way to get that to be the case is with EEO then that's what it has to be]
02:37:09  <trevnorris>still a lot of failures, but not near as violent as current master
02:37:20  <trevnorris>tjfontaine: if we can get AL working w/ domains then i'm all for it.
02:37:42  <trevnorris>hueniverse: though, one strange thing is that the test runner just up and quits w/o any information about what happened.
02:37:55  <trevnorris>anyways. i'm out.
02:37:59  * trevnorris&
02:37:59  <LOUDBOT>HONEYBUNNY BE COOL BABY
02:38:00  <hueniverse>trevnorris: if domains are fucked, everything is fucked
02:38:27  <tjfontaine>no doubt
02:38:32  <trevnorris>hueniverse: too bad domains were never properly implemented to begin w/. so we're stuck getting this insane backwards compatibility working.
02:39:20  <hueniverse>trevnorris: I say fuck backwards comp. it is clearly marked as 2
02:39:20  * mikealjoined
02:39:51  <trevnorris>true that
02:39:54  <trevnorris>:)
02:40:00  <hueniverse>trevnorris: I am not kidding. domains still have weird issues. if you can do a better job with a good API, I say do it!
02:40:25  <trevnorris>hueniverse: dink around w/ the AL api. there's a lot it can do for you.
02:40:38  <hueniverse>trevnorris: https://github.com/spumko/hapi/issues/1299
02:40:51  <hueniverse>trevnorris: I am willing to bet that's a node domains bug
02:41:02  * paulfryzelquit (Ping timeout: 240 seconds)
02:41:40  <hueniverse>trevnorris: I looked at it last night but had to give up at 2am and go to sleep
02:41:42  <trevnorris>thanks. that's a mostly minimal case that I can work w/
02:41:58  <hueniverse>trevnorris: that's 0.10
02:42:06  <trevnorris>ok
02:42:35  <trevnorris>don't you have to add the error event before calling .run() ?
02:43:04  <hueniverse>trevnorris: it appears not :-)
02:43:17  <hueniverse>trevnorris: doesn't matter I think
02:43:27  <hueniverse>trevnorris: inject is after multiple nextTicks
02:43:51  <trevnorris>ah, i see.
02:43:54  <trevnorris>ok. well. for tomorrow.
02:43:58  <trevnorris>night
02:58:44  * daviddiasjoined
03:00:10  <thlorenz>I'm wondering if it's possible to pipe a file into a tcp stream using uv_pipe_init and uv_pipe_open?
03:00:48  <thlorenz>trying to pass tcp->accepted_fd to pipe open, but that is 0 -- any examples out there?
03:03:02  * daviddiasquit (Ping timeout: 240 seconds)
03:03:55  <thlorenz>actually sorry it's -1
03:15:28  <thlorenz>read starting the file pipe now and just writing to the response on each read_cb, hope that's the way to do it
03:21:59  * M28joined
03:28:54  * kazuponquit (Remote host closed the connection)
03:34:16  * pquernaquit (Remote host closed the connection)
03:34:29  * pquernajoined
03:34:29  * pquernaquit (Changing host)
03:34:29  * pquernajoined
03:34:50  * kellabytequit (Remote host closed the connection)
03:37:15  * c4milojoined
03:37:38  * paulfryzeljoined
03:38:36  * wavdedquit (Quit: Hasta la pasta)
03:41:53  * paulfryzelquit (Ping timeout: 252 seconds)
03:42:07  * c4miloquit (Ping timeout: 260 seconds)
03:47:51  * calvinfoquit (Quit: Leaving.)
03:47:54  * jmar777quit (Remote host closed the connection)
03:58:42  * thlorenzquit (Remote host closed the connection)
03:59:16  * thlorenzjoined
03:59:36  * kazuponjoined
04:01:37  * kazupon_joined
04:01:51  * kazuponquit (Read error: Connection reset by peer)
04:02:30  * daviddiasjoined
04:03:46  * thlorenzquit (Ping timeout: 265 seconds)
04:05:08  * mikealquit (Quit: Leaving.)
04:06:38  * kazupon_quit (Ping timeout: 252 seconds)
04:07:34  * daviddiasquit (Ping timeout: 246 seconds)
04:08:36  * daviddiasjoined
04:12:44  * mikealjoined
04:13:03  * daviddiasquit (Ping timeout: 240 seconds)
04:17:38  * c4milojoined
04:26:54  * kazuponjoined
04:32:52  * kellabytejoined
04:33:04  * kellabytequit (Changing host)
04:33:04  * kellabytejoined
04:33:04  * kellabytequit (Changing host)
04:33:04  * kellabytejoined
04:36:14  * stagasquit (Ping timeout: 240 seconds)
04:38:27  * paulfryzeljoined
04:42:38  * paulfryzelquit (Ping timeout: 240 seconds)
04:51:25  * M28quit (Read error: Connection reset by peer)
04:51:54  * M28joined
04:53:10  * mikealquit (Quit: Leaving.)
04:57:57  * ik_joined
04:58:30  * ik_changed nick to ik
04:59:13  * ikpart
05:03:45  * Guest71961quit (Ping timeout: 245 seconds)
05:08:19  * burlakjoined
05:08:29  * burlakchanged nick to Guest14905
05:18:33  * indexzerojoined
05:25:18  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:33:21  * stagasjoined
05:37:23  * c4miloquit (Remote host closed the connection)
05:37:43  * brsonquit (Quit: leaving)
05:38:00  * brsonjoined
05:39:10  * paulfryzeljoined
05:42:06  * m76joined
05:43:37  * paulfryzelquit (Ping timeout: 252 seconds)
06:06:17  * Damn3dquit (Ping timeout: 240 seconds)
06:13:44  * m76quit (Read error: Connection reset by peer)
06:27:36  * m76joined
06:29:06  * m76quit (Client Quit)
06:33:57  * mikealjoined
06:40:00  * paulfryzeljoined
06:44:14  * paulfryzelquit (Ping timeout: 240 seconds)
06:47:22  * julian_duquechanged nick to julianduque
06:59:38  * janjongboomjoined
07:02:52  * Damn3djoined
07:02:52  * Damn3dquit (Changing host)
07:02:52  * Damn3djoined
07:03:20  * brsonquit (Quit: leaving)
07:08:03  * c4milojoined
07:12:43  * c4miloquit (Ping timeout: 252 seconds)
07:18:22  * AvianFluquit (Remote host closed the connection)
07:18:33  * mikealquit (Quit: Leaving.)
07:33:47  * hzjoined
07:35:08  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:40:40  * paulfryzeljoined
07:45:02  * paulfryzelquit (Ping timeout: 240 seconds)
07:47:05  * mikealjoined
07:51:25  * murukeshjoined
07:54:07  * mikealquit (Ping timeout: 260 seconds)
08:27:25  * murukeshquit (Quit: murukesh)
08:29:27  * m76joined
08:32:45  * rendarjoined
08:38:18  * mikealjoined
08:49:00  * janjongboomjoined
08:56:40  * c4milojoined
09:00:52  * c4miloquit (Ping timeout: 246 seconds)
09:38:06  * karupanerurachanged nick to zz_karupanerura
09:54:23  * kazuponquit (Remote host closed the connection)
10:01:03  * janjongboomquit (Ping timeout: 240 seconds)
10:01:56  * janjongboomjoined
10:12:17  <mmalecki>indutny: so dht.js totally works
10:12:34  <mmalecki>indutny: I don't think I'm going to be using it for my service discovery stuff tho
10:12:43  <mmalecki>indutny: bootstrapping sparse networks is too slow for me
10:14:31  <mmalecki>indutny: I *think* I'll go with multicast UDP since it's perfect for my challange
10:14:46  <mmalecki>indutny: (finding an authorative service registry)
10:15:19  <indutny>:)
10:15:22  <indutny>ok
10:15:27  <indutny>thank you for letting me know
10:15:53  <mmalecki>yeah, thanks for that module!
10:16:18  <indutny>np :)
10:29:29  * m76quit (Read error: Connection reset by peer)
10:40:07  * abraxasquit (Remote host closed the connection)
10:40:16  * indexzeroquit (Quit: indexzero)
10:44:54  * c4milojoined
10:48:14  <MI6>nodejs-v0.10: #1700 UNSTABLE linux-x64 (1/608) osx-x64 (1/608) linux-ia32 (1/608) smartos-x64 (7/608) smartos-ia32 (6/608) osx-ia32 (1/608) http://jenkins.nodejs.org/job/nodejs-v0.10/1700/
10:49:22  * c4miloquit (Ping timeout: 246 seconds)
11:00:53  * dcrostajoined
11:10:19  * stagasquit (Ping timeout: 252 seconds)
11:24:01  * indexzerojoined
11:43:35  * daviddiasjoined
12:02:55  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:06:40  * janjongboomjoined
12:22:59  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:27:54  * rmgjoined
12:32:49  * rmgquit (Ping timeout: 252 seconds)
12:33:26  * c4milojoined
12:38:30  * c4miloquit (Ping timeout: 265 seconds)
12:40:48  * abraxasjoined
12:45:34  * abraxasquit (Ping timeout: 246 seconds)
12:53:50  * c4milojoined
13:05:26  * janjongboomjoined
13:06:11  * piscisaureusjoined
13:07:14  * dcrostaquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
13:12:36  * jmar777joined
13:20:50  * thlorenzjoined
13:26:28  * jmar777quit (Remote host closed the connection)
13:32:39  * jmar777joined
13:44:10  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:45:16  * paulfryzeljoined
13:47:12  * AvianFlujoined
13:49:26  * paulfryzelquit (Ping timeout: 240 seconds)
13:55:36  * janjongboomjoined
13:58:47  * c4miloquit
13:59:04  * c4milojoined
14:10:40  * hzquit
14:11:51  * daviddiasquit (Ping timeout: 240 seconds)
14:14:34  * dcrosta_joined
14:18:37  * daviddiasjoined
14:19:47  * paulfryzeljoined
14:25:16  * m76joined
14:40:21  * Damn3dquit (*.net *.split)
14:43:05  * Damn3djoined
14:46:50  * AvianFluquit (Ping timeout: 252 seconds)
14:57:42  * indexzeroquit (Quit: indexzero)
15:07:16  * pachetjoined
15:07:16  * pachetquit (Changing host)
15:07:16  * pachetjoined
15:07:41  * jmar777quit (Remote host closed the connection)
15:15:06  * piscisaureusquit (Read error: Operation timed out)
15:16:36  * brsonjoined
15:20:58  <MI6>nodejs-master: #832 UNSTABLE smartos-x64 (5/692) smartos-ia32 (5/692) osx-ia32 (1/692) centos-ia32 (1/692) ubuntu-x64 (1/692) centos-x64 (2/692) http://jenkins.nodejs.org/job/nodejs-master/832/
15:22:59  * bajtosjoined
15:24:46  * pachet_joined
15:27:32  * pachetquit (Ping timeout: 252 seconds)
15:30:40  * jmar777joined
15:50:10  * daviddiasquit (Read error: Connection reset by peer)
15:50:33  * daviddiasjoined
16:04:30  * AvianFlujoined
16:15:52  * mcavagejoined
16:16:43  * mikolalysenkojoined
16:36:06  * mcavagequit (Remote host closed the connection)
16:36:15  * mcavagejoined
16:37:19  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:42:27  * daviddiasquit (Remote host closed the connection)
16:42:56  * daviddiasjoined
16:45:05  * daviddia_joined
16:45:08  * daviddia_quit (Remote host closed the connection)
16:45:38  * daviddia_joined
16:45:42  * octetcloudjoined
16:47:12  * daviddiasquit (Ping timeout: 245 seconds)
16:49:06  * pachet_changed nick to pachet
16:49:16  * pachetquit (Changing host)
16:49:16  * pachetjoined
16:49:58  * hzjoined
16:51:32  * cjbquit (Remote host closed the connection)
16:59:07  * dap_joined
17:06:09  * piscisaureusjoined
17:17:10  * janjongboomjoined
17:22:36  <mmalecki>piscisaureus: the beer is tomorrow, correct?
17:23:11  <mmalecki>(just making sure since I had it in calendar on Wed, but the original idea was Thu)
17:23:11  <piscisaureus>mmalecki: yup, fine with me. In utrecht though :/
17:23:28  <mmalecki>piscisaureus: yeah, well! it's not that far tho
17:23:29  <piscisaureus>yeah I have it thursday
17:24:30  <piscisaureus>mmalecki: still infinite times further than amsterdam haha
17:24:58  <mmalecki>piscisaureus: haha, yeah
17:25:18  <piscisaureus>020 next time
17:25:47  <mmalecki>yeah, that'd be awesome. so many cool bars here
17:25:58  <mmalecki>I did some bar tourism recently
17:26:59  <piscisaureus>haha. Did you manage to get out of the leidscheplein zone already?
17:31:01  <mmalecki>piscisaureus: yeah, I did! I explored the red light district for two days
17:31:43  <piscisaureus>mmalecki: tourist! :)
17:31:54  <piscisaureus>mmalecki: had fun with all the drunk englishmen?
17:32:06  <mmalecki>yeah, but there are a couple of nice places around
17:32:19  <mmalecki>didn't meet any, somehow!
17:32:40  <piscisaureus>mmalecki: which places?
17:32:56  <mmalecki>cafe cuba, one spanish restaurant which name I forgot
17:33:11  <mmalecki>and Bird, that thai restaurant
17:33:16  <mmalecki>(in China Town)
17:33:38  <piscisaureus>mmalecki: yeah nieuwmarkt is okay
17:37:05  * rmgjoined
17:51:54  * c4miloquit
17:52:14  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:59:53  * mikolalysenkoquit (Ping timeout: 272 seconds)
18:03:30  <MI6>libuv-v0.10-gyp: #115 FAILURE windows-ia32 (6/191) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/115/
18:07:59  * thlorenzquit (Remote host closed the connection)
18:08:37  <MI6>libuv-master-gyp: #372 FAILURE http://jenkins.nodejs.org/job/libuv-master-gyp/372/
18:08:40  <MI6>libuv-master: #420 FAILURE linux (1/203) http://jenkins.nodejs.org/job/libuv-master/420/
18:08:49  <MI6>node-review: #141 FAILURE http://jenkins.nodejs.org/job/node-review/141/
18:11:08  <MI6>libuv-v0.10: #145 FAILURE smartos (2/191) windows (8/191) http://jenkins.nodejs.org/job/libuv-v0.10/145/
18:11:14  <MI6>libuv-review: #110 FAILURE http://jenkins.nodejs.org/job/libuv-review/110/
18:11:23  * TooTallNatejoined
18:12:29  * c4milojoined
18:17:55  * calvinfojoined
18:19:36  <MI6>nodejs-v0.10-windows: #423 UNSTABLE windows-x64 (10/608) windows-ia32 (12/608) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/423/
18:23:31  * hzquit
18:27:28  * hzjoined
18:37:35  <groundwater>trevnorris: SYN
18:38:09  <tjfontaine>indutny: ut oh
18:38:31  <indutny>hey man
18:38:34  <indutny>sup?
18:38:40  <tjfontaine>we may have broken windows :)
18:38:42  <tjfontaine>verifying
18:38:50  <MI6>nodejs-v0.10-windows: #424 FAILURE windows-x64 (13/608) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/424/
18:39:14  <tjfontaine>not that one
18:39:37  <tjfontaine>indutny: http://jenkins.nodejs.org/job/nodejs-master-windows/DESTCPU=ia32,label=windows-jpc/620/console g:\jenkins\workspace\nodejs-master-windows\22874dd8\deps\openssl\asm\x86-win32-masm\x86cpuid.asm(33): error A2085: instruction or register not accepted in current CPU mode [g:\jenkins\workspace\nodejs-master-windows\22874dd8\deps\openssl\openssl.vcxproj]
18:39:46  <indutny>oh gosh
18:39:57  <indutny>that's quite odd
18:40:01  <tjfontaine>indeed
18:40:02  <indutny>let me check what changed in there
18:40:16  <indutny>I thought build bot was ok with it?
18:41:00  <tjfontaine>http://jenkins.nodejs.org/job/node-build-windows-azure/1852/ happens on both VS 2010, VS 2012 32bit -- I thought so too, but apparently what I thought was the node-review that went through was a different branch
18:41:29  <indutny>interestingly enoguh
18:41:31  <indutny>enough*
18:41:33  <tjfontaine>indeed
18:41:34  <indutny>it happens on "cpuid" line
18:41:42  <indutny>oh btw
18:41:45  <tjfontaine>line before?
18:41:45  <indutny>I won't join you guys tomorrow
18:41:52  <indutny>will be at airport gate
18:41:54  <indutny>sorry
18:41:56  <tjfontaine>sad, anythign you need to follow up wiht?
18:42:06  <tjfontaine>*anything, *with
18:42:09  <indutny>two things
18:42:18  <indutny>https://github.com/joyent/node/issues/2598#issuecomment-28282993
18:42:20  <indutny>https://github.com/joyent/node/pull/6442#issuecomment-30037254
18:42:30  <indutny>otherwise only tons of issues in my inbox
18:42:56  <tjfontaine>the first one I did land the documentation update, did you want to make it actually async?
18:43:04  <indutny>yep
18:43:10  <indutny>I'll make it async
18:43:12  * AvianFluquit (Remote host closed the connection)
18:43:15  <indutny>up to some limit
18:43:28  <indutny>i.e. if other process is not receiving messages
18:43:38  <indutny>and uv has > 32 queued messages
18:43:39  <tjfontaine>we already have ACKs built into the protocol?
18:43:40  <indutny>it'll block
18:43:45  <indutny>yes, we have
18:43:52  <indutny>but the problem is that it is using memory
18:43:56  <indutny>to buffer stuff
18:44:20  <tjfontaine>shouldn't it use the streams api then? and communicate the back pressure?
18:44:34  <indutny>perhaps, but it all happens on C level
18:44:46  <tjfontaine>the ACKs are in the node api though
18:44:47  <indutny>and should be same for direct libuv users
18:44:49  <indutny>yep
18:45:35  <tjfontaine>I guess first thigns first is to see the implementation land in libuv
18:45:54  <tjfontaine>right concatenated gzips, I meant to review this thanks for reminding me
18:46:20  <indutny>well
18:46:25  <indutny>it isn't totally what I want
18:46:36  <indutny>it should be more explicit about what it does
18:46:45  <indutny>but I still have no idea how to express this in terms of stream API
18:46:57  <indutny>i.e. transform stream could not end until all data is "transformed"
18:47:24  <indutny>and what it really needs to do is to emit "end" and tell user that there is still some data to process if he/she wants to
18:47:45  <tjfontaine>we're specifically talking about the gzip form of the transform, right? as deflate itself doesn't have this same concept
18:47:56  * mikealquit (Quit: Leaving.)
18:48:00  <indutny>hm...
18:48:12  <indutny>so it is totally normal to have two gzip streams in one file?
18:48:16  <tjfontaine>gzip is able to do this because it encodes in the header the information
18:48:16  <tjfontaine>yes
18:48:23  <indutny>hm...
18:48:28  <tjfontaine>cat gz1 gz2 gz3 > gz
18:48:31  <tjfontaine>quite normal
18:48:32  <indutny>perhaps, it should be fine to just read them
18:48:37  <indutny>as one stream
18:48:38  <indutny>ok
18:48:41  <tjfontaine>ya
18:49:00  <tjfontaine>the parallel gzip/bzip stuff all works on this concept
18:49:19  <tjfontaine>they split incoming streams into multiple pieces, shunt to separate threads, and recombine in order on the outbound
18:49:46  <indutny>ok
18:49:50  * AvianFlujoined
18:50:03  <MI6>node-review: #142 FAILURE linux-x64 (70/692) osx-ia32 (1/692) windows-x64 (21/692) centos-x64 (69/692) linux-ia32 (1/692) centos-ia32 (1/692) smartos-ia32 (5/692) smartos-x64 (4/692) http://jenkins.nodejs.org/job/node-review/142/
18:50:56  <tjfontaine>blah, I hate our test suites, I think I'm going to switch back to one suite in flight at a time
18:51:12  <indutny>:)
18:51:19  <indutny>I think I figured out assembly problem
18:51:26  <indutny>somehow it switched to 486 mode
18:51:27  <indutny>from 686
18:51:32  <tjfontaine>oops :)
18:51:34  <indutny>going to check what happened there
18:51:34  <indutny>yeah
18:52:14  * rainabba_part
18:52:20  <indutny>and everywhere
18:52:20  <indutny>gosh
18:54:08  <indutny>yeah, found it
18:54:14  <tjfontaine>excellent
18:55:33  * paulfryzelquit (Read error: Connection reset by peer)
18:55:36  <indutny>how should we test it?
18:55:41  <indutny>will patch suffice?
18:55:54  <tjfontaine>gist it?
18:56:14  * paulfryzeljoined
18:56:15  <tjfontaine>I mean you can push to feature branch again if you'd like
18:57:55  * piscisaureusquit (Ping timeout: 265 seconds)
18:58:17  <indutny>tjfontaine: https://gist.github.com/indutny/26a8c19066cdf8633d85
18:58:18  <indutny>gist
19:01:36  <tjfontaine>ya ok, did you get that by re-running config?
19:02:37  <indutny>yep
19:02:39  <indutny>not really config
19:03:00  <tjfontaine>I mean I certainly see that as a diff between the branchs
19:03:03  <tjfontaine>*branches
19:03:19  <tjfontaine>can you push that to a feature branch just be safe?
19:04:52  <indutny>ok
19:06:19  <MI6>joyent/node: indutny created branch fix/openssl-woes-on-win32 - http://git.io/marEEg
19:06:20  <indutny>done ^
19:06:23  * mikealjoined
19:07:11  <tjfontaine>thanks
19:07:17  * mikealquit (Client Quit)
19:07:40  <tjfontaine>http://jenkins.nodejs.org/job/node-review/143/DESTCPU=ia32,label=windows/console the build we're concerned with
19:08:50  <tjfontaine>indutny: didn't seem to do it
19:09:17  <indutny>may I ask you to check contents of g:\jenkins\workspace\node-review\eec653f3\deps\openssl\asm\x86-win32-masm\x86cpuid.asm
19:09:23  <tjfontaine>thoguh ...
19:09:44  <tjfontaine>right it's missing a piece here
19:10:00  <indutny>bad build?
19:10:22  <tjfontaine>it didn't checkout the right branch
19:10:22  <tjfontaine>moment
19:10:26  <indutny>also
19:10:28  <indutny>yeah
19:10:29  <indutny>bad commit
19:18:23  <MI6>joyent/node: Fedor Indutny v0.8 * 10b6156 : tls: fix pool usage race - http://git.io/LF_bUQ
19:20:19  * indexzerojoined
19:24:57  <MI6>nodejs-v0.8: #61 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.8/61/
19:31:24  <MI6>node-review: #143 FAILURE linux-x64 (67/692) windows-x64 (19/692) centos-x64 (82/692) centos-ia32 (2/692) smartos-ia32 (5/692) smartos-x64 (5/692) http://jenkins.nodejs.org/job/node-review/143/
19:34:56  * bajtosquit (Quit: bajtos)
19:37:10  <indutny>hm...
19:37:31  <indutny>buildbot dead
19:37:37  <indutny>long live buildbot
19:37:42  <tjfontaine>hehe
19:37:44  <tjfontaine>it's ok
19:37:46  <tjfontaine>http://jenkins.nodejs.org/job/node-review/DESTCPU=ia32,label=windows/145/console
19:37:50  <tjfontaine>is the fixed build
19:37:51  <tjfontaine>looks good
19:39:18  <MI6>joyent/node: Lorenz Leutgeb v0.10 * fc7e217 : doc: fix typo in cluster page - http://git.io/eYyXTA
19:39:44  <indutny>good!
19:39:52  <indutny>tjfontaine: should I land it?
19:39:58  <tjfontaine>yes please
19:40:06  <indutny>ok
19:40:32  <MI6>joyent/node: Fedor Indutny master * 4800310 : deps: fix openssl assembly error on ia32 win32 - http://git.io/zP-0YQ
19:40:47  <indutny>ok, now it is time to do it in v0.10
19:41:15  <indutny>tjfontaine: mind if I'll include asm updates from master?
19:42:01  <indutny>seems to be a bit dangerous
19:42:14  <indutny>ok, I'll try to do it in a more clean way
19:42:15  <tjfontaine>ya I'd prefer not to
19:42:17  <tjfontaine>thanks
19:42:32  <indutny>np
19:46:24  <indutny>ok, doing a build and running tests
19:46:27  <indutny>then pushing to a feature branch
19:46:47  <tjfontaine>excellent
19:47:54  * dap_quit (Quit: Leaving.)
19:48:24  * dap_joined
19:50:51  <MI6>joyent/node: indutny created branch feature/openssl-1.0.1f-in-v.08 - http://git.io/myLSWQ
19:50:52  <indutny>here it goes ^
19:50:58  <indutny>tjfontaine: please let me know if it works
19:53:12  <tjfontaine>oh in 0.8?
19:53:19  <tjfontaine>I thought we were going for 0.10
19:54:32  <indutny>oh
19:54:35  <indutny>actually it is v0.10
19:54:39  <tjfontaine>ok
19:54:48  <indutny>I just jumped through v0.8, v0.10, v0.11 a couple of times
19:54:55  <indutny>sorry
19:55:00  <indutny>tjfontaine: what about https://github.com/joyent/node/pull/6806 ?
19:55:00  * bajtosjoined
19:56:49  <MI6>nodejs-v0.10: #1701 UNSTABLE linux-x64 (5/608) osx-x64 (7/608) linux-ia32 (6/608) smartos-x64 (8/608) smartos-ia32 (5/608) osx-ia32 (3/608) http://jenkins.nodejs.org/job/nodejs-v0.10/1701/
19:57:14  <MI6>nodejs-v0.10-windows: #425 FAILURE windows-x64 (14/608) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/425/
19:57:19  <tjfontaine>indutny: looks right to me
19:57:51  <indutny>right or *good* ? :)
19:58:08  <tjfontaine>finishing up, I think it's going to be fine
19:59:14  * bajtosquit (Read error: Operation timed out)
19:59:16  <tjfontaine>indutny: lgtm
19:59:58  <indutny>ok
19:59:59  <indutny>thanks
20:00:49  <MI6>joyent/node: Fedor Indutny master * 730e511 : child_process: better error reporting for exec - http://git.io/cEHJKw
20:01:42  <MI6>node-review: #145 UNSTABLE linux-x64 (4/692) osx-ia32 (2/692) windows-x64 (19/692) centos-x64 (2/692) linux-ia32 (5/692) windows-ia32 (22/692) centos-ia32 (3/692) smartos-ia32 (8/692) smartos-x64 (6/692) osx-x64 (1/692) http://jenkins.nodejs.org/job/node-review/145/
20:10:41  * thlorenzjoined
20:11:59  <indutny>tjfontaine: so what about openssl in v0.10?
20:12:02  <indutny>is buildbot fine with it?
20:12:28  <tjfontaine>still building at the moment
20:14:07  <indutny>ok
20:14:56  <MI6>nodejs-master: #833 UNSTABLE smartos-x64 (7/692) smartos-ia32 (5/692) osx-ia32 (2/692) osx-x64 (1/692) centos-ia32 (7/692) ubuntu-x64 (3/692) centos-x64 (3/692) http://jenkins.nodejs.org/job/nodejs-master/833/
20:16:39  * othiym23quit (Ping timeout: 252 seconds)
20:21:03  * daviddia_quit (Ping timeout: 252 seconds)
20:21:22  * mikealjoined
20:21:51  * thlorenzquit (Remote host closed the connection)
20:22:21  * thlorenzjoined
20:22:39  * othiym23joined
20:23:09  * stagasjoined
20:23:11  * mikealquit (Client Quit)
20:33:54  * kazuponjoined
20:34:01  <tjfontaine>MASM : fatal error A1000: cannot open file : g:\jenkins\workspace\node-review\1d92f228\deps\openssl\openssl\crypto\bn\asm\x86_64-win32-masm.asm [g:\jenkins\workspace\node-review\1d92f228\deps\openssl\openssl.vcxproj]
20:34:05  <tjfontaine>g:\jenkins\workspace\node-review\1d92f228\deps\openssl\openssl.targets(28,5): error MSB3721: The command "call ml64.exe "/Zi" "/Fo" "Release\obj\openssl\x86_64-win32-masm.obj" "/c" "g:\jenkins\workspace\node-review\1d92f228\deps\openssl\openssl\crypto\bn\asm\x86_64-win32-masm.asm"" exited with code 1. [g:\jenkins\workspace\node-review\1d92f228\deps\openssl\openssl.vcxproj]
20:34:10  <tjfontaine>indutny: ^
20:34:17  <indutny>oh gosh
20:34:44  <indutny>I wonder why it expects it at all
20:35:20  <indutny>let me grep
20:35:34  <indutny>oh
20:35:38  <indutny>it is in gyp
20:36:00  <M28>is uv_hrtime bugged in windows...? it's precision is 1 second in my machine
20:36:03  <M28>its*
20:36:47  <indutny>tjfontaine: oh, I see
20:36:48  <indutny>one sec
20:36:54  <indutny>tjfontaine: any other errors?
20:37:23  <MI6>joyent/node: Fedor Indutny feature/openssl-1.0.1f-in-v.08 * e40b521 : return back missing file - http://git.io/LqPYPQ
20:40:31  <tjfontaine>non so far
20:40:45  <MI6>node-review: #148 FAILURE linux-x64 (3/608) osx-ia32 (1/608) centos-x64 (3/608) linux-ia32 (3/608) windows-ia32 (11/608) centos-ia32 (5/608) smartos-ia32 (7/608) smartos-x64 (7/608) osx-x64 (2/608) http://jenkins.nodejs.org/job/node-review/148/
20:40:52  <tjfontaine>that's the previous one
20:41:16  <indutny>ok
20:41:19  <tjfontaine>http://jenkins.nodejs.org/job/node-review/149/ is the current one
20:42:04  <indutny>thanks
20:44:17  <indutny>seems to be buildings
20:44:19  <indutny>building*
20:44:23  <indutny>let's wait for tests
20:49:11  * daviddiasjoined
20:56:21  <MI6>nodejs-master: #834 UNSTABLE smartos-x64 (10/692) smartos-ia32 (7/692) osx-ia32 (1/692) centos-ia32 (3/692) ubuntu-x64 (4/692) ubuntu-ia32 (2/692) centos-x64 (5/692) http://jenkins.nodejs.org/job/nodejs-master/834/
20:57:19  * piscisaureusjoined
21:01:58  * indexzeroquit (Quit: indexzero)
21:03:45  * indexzerojoined
21:05:45  <indutny>yay
21:05:47  <indutny>tjfontaine: looks good
21:05:57  <indutny>http://jenkins.nodejs.org/job/node-review/149/
21:06:18  <indutny>all tests failures seems to be unrelated
21:08:00  <indutny>tjfontaine: LGTY?
21:10:08  <indutny>also https://github.com/joyent/node/pull/6826
21:10:13  <indutny>very simple PR
21:10:16  <indutny>obvious bug
21:10:21  * kazuponquit (Remote host closed the connection)
21:10:49  * kazuponjoined
21:11:13  * kazuponquit (Read error: Connection reset by peer)
21:11:31  * kazuponjoined
21:12:14  <tjfontaine>indutny: ya land the 6826
21:12:20  <indutny>thanks
21:12:33  <MI6>joyent/node: Fedor Indutny master * 0afdfae : configure: always set `arm_float_abi` - http://git.io/zGpY9Q
21:12:51  * m76quit (Read error: Connection reset by peer)
21:13:02  * indexzeroquit (Quit: indexzero)
21:17:00  * Ralithjoined
21:17:11  <indutny>tjfontaine: what about openssl?
21:17:51  <Ralith>How efficient are timers? Is it sane to use them continuously on the tens-of-ms scale?
21:18:27  <Ralith>(only one timer ever active, but frequently having timeouts on that order or even less)
21:18:28  <indutny>Ralith: a good question, actually
21:18:39  <indutny>but the answer depends on how you are using them
21:18:42  <indutny>you can have tons of them
21:18:47  <indutny>without any overhead
21:18:47  <indutny>but
21:19:06  <indutny>if you'll malloc each of them - you may find it faster to use one timer and do some twiddling with it
21:19:20  * trevnorr1sjoined
21:19:22  <indutny>Ralith: they're organized as a RB-tree internally
21:19:32  <Ralith>I'm already only using one timer, since my use case is naturally serial
21:19:39  <indutny>ok
21:19:49  <indutny>Ralith: have I answered your question, anyway?
21:19:51  * mikealjoined
21:20:00  <Ralith>I don't think so
21:20:15  <Ralith>my question is really, is it reasonable to use timers on that timescale?
21:20:32  <Ralith>is setup and activation of them cheap?
21:20:33  <indutny>oh
21:20:33  <indutny>sorry
21:21:02  * trevnorr1squit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
21:21:17  <indutny>Ralith: I think timeout is in milliseconds https://github.com/joyent/libuv/blob/master/include/uv.h#L1327
21:21:24  <indutny>Ralith: so tens-of-ms won't work anyway
21:21:25  <Ralith>I know its *units* are in milliseconds
21:21:29  <Ralith>huh?
21:21:33  <Ralith>why not?
21:21:36  <indutny>1/10 ?
21:21:38  <indutny>haha
21:21:43  <indutny>I think I didn't get it, sorry
21:21:44  <Ralith>tens of, not tenths of.
21:21:54  * indutnyis non-native speaker
21:21:58  <indutny>ok, whatever
21:22:01  <indutny>this seems to be fine
21:22:28  <indutny>it is significantly faster than 1ms to spawn it
21:22:37  <indutny>can't tell you exact number
21:22:40  <Ralith>as in "can I regularly schedule timers for ~10ms from now without the scheduling and firing of them consuming a significant proportion of my time"
21:22:44  <indutny>but it should be in order of microseconds
21:22:54  <Ralith>okay, that's reassuring
21:23:01  <indutny>yeah
21:23:05  * mikealquit (Client Quit)
21:23:08  <indutny>but it depends on you too
21:23:16  <indutny>if you do a lot of work in callbacks
21:23:16  <Ralith>?
21:23:17  <indutny>;)
21:23:20  <Ralith>oh, yeah
21:23:23  <Ralith>but that's my problem
21:23:36  <Ralith>I can use a dedicated thread if it becomes an issue
21:23:41  <indutny>ok
21:23:50  <indutny>great
21:24:06  <Ralith>to elaborate, I'm implementing a session and reliability layer on top of UDP, and I need to schedule retransmissions on the order of network round trip time for potentially large numbers of clients over a single socket
21:24:40  <Ralith>I'm doing this by maintaining a single timer for 'next transmit'
21:24:44  * piscisaureusquit (Ping timeout: 252 seconds)
21:25:56  <indutny>gotcha
21:26:48  <MI6>node-review: #149 UNSTABLE linux-x64 (3/608) osx-ia32 (1/608) windows-x64 (13/608) linux-ia32 (6/608) windows-ia32 (14/608) smartos-ia32 (6/608) smartos-x64 (10/608) osx-x64 (3/608) http://jenkins.nodejs.org/job/node-review/149/
21:26:51  <Ralith>for LANs, this interval could be as small as 1ms (though I think I'll probably clamp it at or above there, since my application doesn't benefit from latencies that low)
21:30:04  * mikealjoined
21:34:29  * paulfryzelquit (Read error: Connection reset by peer)
21:35:05  * paulfryzeljoined
21:35:27  <indutny>Ralith: I see
21:35:47  <indutny>we should merge more PRs https://github.com/joyent/node/pulse/monthly
21:36:07  <indutny>the issue count seems to be fine
21:36:14  <indutny>if we will continue at this rate
21:36:26  <tjfontaine>7meh
21:37:02  <indutny>haha, not exactly my feelings
21:37:32  <tjfontaine>we shouldn't be afraid of issue counts generally
21:37:35  <tjfontaine>or burn down rates
21:42:31  <indutny>perhaps
21:42:32  <indutny>but
21:42:45  <indutny>it would be simpler if all they won't sit in my inbox :D
21:46:09  * calvinfopart
21:48:54  <MI6>nodejs-master: #835 UNSTABLE smartos-x64 (9/692) smartos-ia32 (8/692) osx-ia32 (1/692) centos-ia32 (3/692) ubuntu-x64 (2/692) ubuntu-ia32 (1/692) centos-x64 (1/692) http://jenkins.nodejs.org/job/nodejs-master/835/
21:49:08  * daviddia_joined
21:52:48  * daviddiasquit (Ping timeout: 252 seconds)
21:54:03  * daviddia_quit (Ping timeout: 260 seconds)
21:54:48  * daviddia_joined
21:59:20  * octetcloudquit (Quit: WeeChat 0.4.2)
21:59:52  * octetcloudjoined
22:00:20  * Ralithquit (Ping timeout: 246 seconds)
22:01:52  * kazuponquit (Remote host closed the connection)
22:01:52  <tjfontaine>indutny: I have another PR for you to do :)
22:02:06  <tjfontaine>I'd file it but github's down
22:03:05  * dcrosta_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:03:27  * kazuponjoined
22:03:39  * dcrosta_joined
22:08:03  * kazuponquit (Ping timeout: 259 seconds)
22:13:33  <indutny>tjfontaine: sure
22:13:37  <indutny>tjfontaine: use email :D
22:13:43  * roxluquit (Read error: Operation timed out)
22:13:50  * roxlujoined
22:14:23  <tjfontaine>haha
22:15:03  <tjfontaine>indutny: well, we should have net.connect({localPort:})
22:15:31  <indutny>haha
22:15:46  <tjfontaine>we have localAddress
22:16:06  <tjfontaine>it's silly not support setting the port as well
22:16:07  <indutny>what's localPort stands for?
22:16:25  <tjfontaine>indutny: just like localAddress you can set your outbound port, along with your address
22:16:38  <tjfontaine>in the bind
22:16:43  <indutny>oh
22:16:53  <indutny>never used it :)
22:16:55  <tjfontaine>[would be better named bindAddress and bindPort but history]
22:17:59  * Enthralledjoined
22:19:17  * rmgquit (Remote host closed the connection)
22:24:03  * julianduquequit (Quit: leaving)
22:24:12  * julianduquejoined
22:26:56  * Ralithjoined
22:27:47  * rendarquit (Quit: Leaving)
22:37:08  * jmar777quit (Remote host closed the connection)
22:53:54  * rmgjoined
23:02:39  * rmgquit (Ping timeout: 252 seconds)
23:05:34  * Enthralledpart ("Leaving")
23:07:08  <hueniverse>any idea why node-heapdump only creates one dump when calling writeSnapshot() twice?
23:07:32  <tjfontaine>probably best to ask ben I guess, since I haven't integrated that into core (yet) ;)
23:07:58  * daviddia_quit (Remote host closed the connection)
23:08:29  * daviddiasjoined
23:08:30  <tjfontaine>hueniverse: has the first not completed yet?
23:08:43  * paulfryzelquit (Remote host closed the connection)
23:10:11  <hueniverse>tjfontaine: that was is.
23:10:12  <hueniverse>it
23:10:24  <tjfontaine>k
23:10:44  <tjfontaine>it's pretty dangerous to be doing from in process anyway
23:13:06  * daviddiasquit (Ping timeout: 252 seconds)
23:14:56  * c4milo_joined
23:16:58  * c4miloquit (Ping timeout: 252 seconds)
23:17:22  * rmgjoined
23:18:17  * paulfryzeljoined
23:22:31  * dcrosta_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:23:28  * thlorenzquit (Remote host closed the connection)
23:26:58  * thlorenz_joined
23:29:11  * rmgquit (Remote host closed the connection)
23:29:51  * indexzerojoined
23:34:15  * pachetquit (Quit: leaving)
23:37:12  * jmar777joined
23:39:35  * paulfryzelquit (Remote host closed the connection)
23:40:31  * thlorenz_quit (Ping timeout: 260 seconds)
23:41:47  * hzquit
23:59:50  * rmgjoined