00:00:02  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:02:56  <tjfontaine>rvagg: gimmie some time today, and I'll sort out the async docs
00:03:22  * AvianFluquit (Ping timeout: 246 seconds)
00:03:32  <MI6>libuv-master-gyp: #308 UNSTABLE smartos-ia32 (5/198) windows-x64 (6/197) smartos-x64 (5/198) windows-ia32 (5/197) http://jenkins.nodejs.org/job/libuv-master-gyp/308/
00:21:41  * st_lukequit (Remote host closed the connection)
00:22:33  <tjfontaine>ircretary: tell st_luke fwiw passive aggressive comments on github issues aren't particularly helpful
00:22:34  <ircretary>tjfontaine: I'll be sure to tell st_luke
00:24:57  * vptrquit (Quit: WeeChat 0.3.5)
00:28:50  * paulfryzelquit (Read error: Connection reset by peer)
00:29:18  * paulfryzeljoined
00:31:31  * c4miloquit (Remote host closed the connection)
00:31:56  <piscisaureus_>tjfontaine is mad
00:32:25  <tjfontaine>not mad, just that github issues is really not a place to be passive agressive, community or core members alike
00:33:38  <piscisaureus_>impossible to disagree with
00:33:48  <piscisaureus_>too bad. I was in for some Good Trolling
00:33:53  <tjfontaine>heh
00:36:56  <trevnorris>i'm getting bored looking for this. can someone point me to where/how writev is automatically used by http?
00:37:42  <piscisaureus_>tjfontaine: did you invite alexis for your meeting tomorrow?
00:37:51  <piscisaureus_>(aka orangemocha)
00:37:58  * paulfryzelquit (Read error: Connection reset by peer)
00:38:03  <piscisaureus_>s/your/our/
00:38:29  * paulfryzeljoined
00:38:31  <tjfontaine>for the node call? I think the calendar invite is still isaacs' so I think he'll have to add him
00:38:40  <tjfontaine>but I will try it
00:38:43  <piscisaureus_>isaacs: ^
00:38:44  <trevnorris>eh, nm. found it.
00:39:10  <trevnorris>so... what happens if I write out multiple chunks, but don't set the chunked encoding header?
00:39:12  <piscisaureus_>tjfontaine: alternatively we can create another hangout on the spot. It seems more important to give him a headsup
00:39:18  <tjfontaine>trevnorris: cork/uncork
00:39:19  <piscisaureus_>where him == alexis
00:39:25  <tjfontaine>piscisaureus_: indeed
00:39:30  <trevnorris>differently as far as the client is concerned?
00:39:35  <tjfontaine>looks like I can add him
00:40:02  <trevnorris>tjfontaine: oh, btw. I won't be there tomorrow morning. my status report is that i'm sleep deprived... and i've been working on async listener.
00:40:22  <trevnorris>trying to have it rewritten before the next v0.11 release (when's that going to be?)
00:42:59  <tjfontaine>trevnorris: well that would be on the call wouldn't it? I think we're still shooting for the same time frame as last, we're looking to get sapwnSync in to freeze
00:43:29  <tjfontaine>trevnorris: lets get some benchmarks that you want to care about (that don't have a bunch of node process restarts themselves)
00:44:04  <trevnorris>i'm confused by what's in the parenthesis.
00:44:48  * paulfryzelquit (Remote host closed the connection)
00:45:16  <tjfontaine>trevnorris: I just want a simpler interface to do automatic benchmarking that are easy to track with dtrace
00:45:20  <tjfontaine>trevnorris: or prof
00:45:26  <tjfontaine>which generally are easier to attach with pid
00:46:26  <trevnorris>yeah. honestly I really don't care about the benchmarks that much right now. been doing this so much that I know where we're spewing performance like an elephant with diarrhea.
00:47:18  * defunctzombie_zzchanged nick to defunctzombie
00:47:47  <tjfontaine>sure, I know, but I'd like to use the prebuilt binaries to do easier regression testing, and to make it automagic for us to just turn it on and walk away for a weekend
00:48:37  <tjfontaine>piscisaureus_: he's on the invite, so hopefully he'll be able to join, I'm not sure what his travel plans were
00:48:54  <trevnorris>cool. to be useful i'd like to get some actual real world benchmarks. like, simulate a user on a website that it has to keep track of.
00:49:18  <tjfontaine>well, sure that always sounds great -- find that and let me know :P
00:49:25  <trevnorris>i've already found an embarrassingly bad performance poop in expressjs+jade
00:49:51  <trevnorris>i want to talk to the walmart dudes and see what they do.
00:50:42  <trevnorris>i've been working on scripts that can generate fake user data and insert it into some location of your choice.
00:51:07  <tjfontaine>walmart is useful, they record and replay data, that's not that difficult to do, but requires buyin from someone
00:51:20  <trevnorris>then create a set of pages and use an algorithm that calculates random walks across the site, have the site track users via cookies or what not.
00:51:22  <trevnorris>true
00:51:41  <trevnorris>but like, http_simple is fun and all but pretty useless
00:52:12  <trevnorris>we don't have any tests that test what happens when N users stay connected taking random routes through source.
00:52:26  <tjfontaine>trevnorris: but you have to consider that real perf requires the latencies to match
00:52:56  <tjfontaine>but yes we need better benchmarks :)
00:53:02  <trevnorris>yeah, of course. "performance" it technically in the eye of the user :)
00:54:20  <trevnorris>but regardless, there's a crap ton of stuff I'd like to do but we need to have a serious conversation about it.
00:54:30  <tjfontaine>yes.
00:54:35  <trevnorris>more precisely, what the team is willing we do with core.
00:54:43  <tjfontaine>well
00:54:45  <tjfontaine>yes
00:54:53  <tjfontaine>it would be nice if you were going ot be on the call tomorrow
00:54:54  <tjfontaine>:)
00:55:32  <trevnorris>yeah, sorry.
00:55:44  <trevnorris>trust me when I say that right now that's what I'd rather be doing.
00:55:50  <tjfontaine>yup, that's fine, it happens
00:56:05  <tjfontaine>I would like to try and schedule a time for all the core team to meet in SF
00:56:10  <tjfontaine>sblom said he woudl even fly down
00:56:34  <trevnorris>sounds good. ben will still probably be remote. and I still haven't met fedor
00:57:20  <tjfontaine>ya, it may not happen as soon as I wanted (like in a week or two) but it will be likely ASAFP where we can get our schedules to work
00:58:35  <trevnorris>well. who's going to be at node summit?
00:58:44  <othiym23>trevnorris: I will!
00:58:48  <othiym23>not that I count
00:58:50  <trevnorris>heh
00:59:01  <trevnorris>yeah, aren't you giving a talk or something?
00:59:31  <groundwater>trevnorris: we should talk benchmarking one day
00:59:50  <trevnorris>sure. whatev's
00:59:50  <tjfontaine>trevnorris: it's not really convenient to do at the summit, but there will be a lot of us
01:00:04  <groundwater>i've got a suite running for the newrelic agent, but i'd like to talk about ways to find more relevant and interesting benchmarks
01:00:12  <trevnorris>eh, we'll just ditch during othiym23's talk. ;)
01:00:29  <othiym23>but... I...
01:00:29  <tjfontaine>heh
01:00:33  <groundwater>i'm stealing all the good ideas from brendan's book
01:00:42  <othiym23>that's OK, my talk is targeted at managerial types
01:00:45  <trevnorris>groundwater: coolio. just benchmark all the stuff and figure out what it means later :P
01:00:53  <trevnorris>ooooh. shouldn't have told me that
01:00:58  * trevnorrismakes a note
01:01:08  <groundwater>trevnorris: ha, no it's too easy to get lots down the rabbit hole
01:01:58  * abraxasjoined
01:02:00  <octetcloud>fwiw, I'm virtually certain Bert will be at node-summit, and I know he'll be in SF that week
01:02:14  <trevnorris>groundwater: to be honest it's more important to correctly interpret the results. then you'll automatically know where your benchmarks are lacking.
01:03:13  <groundwater>right now i use high-level benchmarks to indicate performance, and low-level benchmarks to isolate problems found by the high-level tests
01:03:14  <othiym23>trevnorris: we're putting a lot of work into interpreting the data we're getting back
01:03:24  <groundwater>which reminds me, i need to run them over master soon
01:03:29  <othiym23>we've learned a lot, although nothing super actionable so far
01:03:54  <groundwater>we have t-shirts downstairs that say "data nerd" so we're living up to the image
01:03:57  <othiym23>just that CLS is slow as shit when it's on the hottest possible path being run in a tight looop
01:04:05  <trevnorris>haha
01:04:11  <tjfontaine>are you tracking gc-start and gc-done as well?
01:04:16  <tjfontaine>or rather
01:04:19  <tjfontaine>how tight is that loop?
01:04:29  <groundwater>tjfontaine: basically 100% cpu
01:04:37  <groundwater>i just did a sub-second CPU heat map today
01:04:49  <groundwater>no GC events yet, that's a really good idea though
01:05:00  <tjfontaine>only if you're actually yielding time for it :)
01:05:11  <othiym23>yeah, I have concerns over the added GC pressure from CLS
01:05:35  <othiym23>tjfontaine: we're using setImmediate for most of our looping
01:05:41  <othiym23>that should yield to GC, no?
01:05:50  <tjfontaine>yup
01:05:57  <groundwater>when i start profiling memory i'm going to be a lot more sensitive to GC
01:05:58  <trevnorris>i've become a hater of profiling the last two days. ran --prof twice over the same benchmark. first time told me 88% of time was spent in syscalls. second time 18% was in syscalls.
01:06:02  * abraxasquit (Ping timeout: 240 seconds)
01:06:19  <trevnorris>now I only trust counter. perf probe has been my best friend the last two days.
01:06:24  <piscisaureus_>Hello
01:06:25  <groundwater>the benchmarks we've been running are pretty consistent
01:06:29  <tjfontaine>trevnorris: fwiw, you really don't want in-process profiling for this.
01:06:46  <groundwater>tho i'm running dtrace/smartos, and i heard the guys who run that show are pretty smart
01:06:54  <trevnorris>tjfontaine: you mean using --prof?
01:07:00  <tjfontaine>trevnorris: also, being a koolaid drinker, you really want dtrace
01:07:13  <trevnorris>heh. then make it usable on linux :P
01:07:20  <tjfontaine>trevnorris: --prof or anything that sits in the process you're trying to monitor
01:07:43  <tjfontaine>trevnorris: I'm not sure why you're allergic, it's really not that different or difficult, and you can have as much space as you want in the JPC, just tell me
01:07:56  * kazuponquit (Remote host closed the connection)
01:08:16  <trevnorris>tjfontaine: honestly I've been caring a lot less about time spent and more concerned about the raw call counts. I'm finding those much more reliable.
01:08:32  <othiym23>and if you're a real badass, you can even get it running on your laptop under vmware or VirtualBox
01:08:34  <tjfontaine>only because those are the only reliable tools you have on your platform :P
01:08:41  <trevnorris>haha
01:08:44  <tjfontaine>anyway, brb quick meeting
01:08:45  * othiym23blows imaginary dust off his fingernails
01:10:17  <trevnorris>yeah, except the nvidia drivers on my laptop don't allow the bios visualization whatnot to be enabled.
01:10:18  * AvianFlujoined
01:10:30  <trevnorris>took me a week to figure out there was a bug in the nvidia drivers for my model of laptop
01:11:37  * octetcloudquit (Ping timeout: 272 seconds)
01:12:16  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:13:12  * c4milojoined
01:14:13  * mmaleckiquit (Ping timeout: 248 seconds)
01:15:19  * AvianFluquit (Ping timeout: 272 seconds)
01:18:39  * groundwaterquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:35:34  <trevnorris>WTF!!!
01:36:09  <tjfontaine>ftw!
01:36:23  <trevnorris>can someone tell me why in http doing a write() then end() on the same amount of data drop the req/sec from 18k to 800?
01:36:39  <trevnorris>(instead of doing an end() on it all at once)
01:36:58  <tjfontaine>it could be an error in the chunk/unchunk logic
01:36:59  * abraxasjoined
01:37:02  <tjfontaine>er
01:37:07  <tjfontaine>cork/uncork
01:37:14  <trevnorris>tjfontaine: writev wasn't implemented until v0.11 right?
01:37:20  <tjfontaine>that's correct.
01:37:26  <trevnorris>ok. this is happening in v010
01:37:53  * AvianFlujoined
01:37:56  <tjfontaine>well, that's because each results in a writereq?
01:38:10  <tjfontaine>but I guess i need to see the code to really understand what you're saying
01:38:25  <tjfontaine>it may be 3 depending on the header situation
01:38:50  <trevnorris>i've tried w/ and w/o chunked encoding
01:39:13  <trevnorris>i've basically just taken the hello world and done the write('hello '); end('world!')
01:39:40  <trevnorris>perf stat:
01:39:41  <trevnorris>9414.346816 task-clock (msec) # 0.171 CPUs utilized
01:39:52  <trevnorris>5,874,279,719 stalled-cycles-frontend # 76.60% frontend cycles idle
01:40:02  <trevnorris>4,003,790,973 instructions # 0.52 insns per cycle
01:40:19  <tjfontaine>those numbers are particularly useless to me :P
01:40:40  <tjfontaine>show me the scripts so I can make a flamegraph or something
01:40:45  <trevnorris>it's saying that average CPU utilization during the test was 10%
01:40:54  <trevnorris>node/benchmark/http_simple.js
01:41:02  <tjfontaine>from v0.10?
01:41:19  <trevnorris>the script on master works w/ v0.10
01:41:50  <tjfontaine>this is my point, which one are you using, I am not sure if there are changes, let alone if my changes will match yours :)
01:42:05  <tjfontaine>so lets just start from the same page so I know we're testing the same thing
01:43:18  * st_lukejoined
01:43:19  <trevnorris>tjfontaine: diff between http_simple on master and v0.10 branch is nil
01:43:26  <tjfontaine>ok, what's your diff of it
01:44:18  <trevnorris>tjfontaine: git show origin/v0.10:benchmark/http_simple.js | diff benchmark/http_simple.js -
01:44:23  <trevnorris>and output is nothing
01:44:36  <tjfontaine>indutny: v0.8 is stable ont he walmart memory leak, no backport necessary
01:44:48  <tjfontaine>trevnorris: you said you had changed something: [11-26] 01:39:13 < trevnorris> i've basically just taken the hello world and done the write('hello '); end('world!')
01:45:35  * jmar777joined
01:50:13  * dshaw_quit (Quit: Leaving.)
02:00:26  * kevinswiberjoined
02:03:46  * stagasjoined
02:03:46  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:13:18  * mikealquit (Quit: Leaving.)
02:16:23  * st_lukequit (Remote host closed the connection)
02:16:33  * paulfryzeljoined
02:20:58  * paulfryzelquit (Ping timeout: 245 seconds)
02:21:11  * dshaw_joined
02:24:18  * wolfeidauquit (Ping timeout: 245 seconds)
02:26:39  * kevinswiberquit (Remote host closed the connection)
02:26:44  * defunctzombiechanged nick to defunctzombie_zz
02:26:51  * c4miloquit (Read error: Connection reset by peer)
02:27:05  * c4milo_joined
02:31:03  * c4milojoined
02:32:09  * c4miloquit (Read error: Connection reset by peer)
02:32:22  * c4milojoined
02:33:20  * c4miloquit (Remote host closed the connection)
02:34:14  * c4milo_quit (Ping timeout: 246 seconds)
02:36:23  * dshaw_quit (Ping timeout: 272 seconds)
02:49:26  * inolenquit (Quit: Leaving.)
02:49:48  <trevnorris>tjfontaine: yeah. take the hello world on nodejs.org and split res.end('Hello World\n'); to res.write('Hello '); res.end('World\n');
02:50:48  <trevnorris>tjfontaine: I benchmarked each with: wrk -t 4 -c 32 -d 10 ''
02:51:56  <trevnorris>tjfontaine: using 0.10.22 for res.end('Hello World\n'): ~20k req/sec. for the other: ~800 req/sec
02:53:01  * groundwaterjoined
02:55:22  * jmar777quit (Remote host closed the connection)
03:00:28  <trevnorris>tjfontaine: I've been able to reproduce it using the raw TCP bindings: http://git.io/5-EYLw
03:00:40  <trevnorris>so it doesn't have to do with http at all
03:01:24  * wolfeidaujoined
03:02:25  <tjfontaine>this is testing on v0.10?
03:05:22  <trevnorris>tjfontaine: that's on master. I forgot how to use the raw tcp bindings in v0.10
03:05:45  <trevnorris>tjfontaine: but the resulting metrics of the test are the exact same as the others.
03:11:45  * jmar777joined
03:17:18  * paulfryzeljoined
03:19:54  <trevnorris>tjfontaine: so I took that and added a counter to each request and printed the order in which each was processed: http://git.io/0rHC8g
03:20:12  <trevnorris>they seem strangely blocking in nature
03:21:48  * paulfryzelquit (Ping timeout: 245 seconds)
03:31:30  * inolenjoined
03:32:11  * jmar777quit (Remote host closed the connection)
03:32:40  * dshaw_joined
03:35:27  * octetcloudjoined
03:37:49  * dshaw_quit (Ping timeout: 272 seconds)
03:43:34  * kazuponjoined
03:52:27  * AvianFluquit (Read error: Connection reset by peer)
03:53:57  * dshaw_joined
03:58:20  * dshaw_quit (Ping timeout: 245 seconds)
04:01:40  <trevnorris>tjfontaine: if you open my tmux on smartos.nodejs.org you'll see the tests right there. on smartos it runs > 6x slower sending the message in two parts.
04:04:05  * mikealjoined
04:04:57  * rmgjoined
04:11:24  * rmgquit (Quit: rmg)
04:12:48  * rmgjoined
04:17:06  * m76joined
04:18:02  * paulfryzeljoined
04:21:38  * abraxasquit (Remote host closed the connection)
04:22:13  * paulfryzelquit (Ping timeout: 245 seconds)
04:24:12  * wolfeidauquit (Remote host closed the connection)
04:29:25  * mikealquit (Quit: Leaving.)
04:45:39  * AvianFlujoined
04:54:47  * dshaw_joined
04:59:17  * dshaw_quit (Ping timeout: 248 seconds)
05:00:44  * defunctzombie_zzchanged nick to defunctzombie
05:04:33  * kazupon_joined
05:04:36  * kazuponquit (Read error: Connection reset by peer)
05:08:24  * kazuponjoined
05:09:26  * abraxasjoined
05:09:37  * kazupon_quit (Ping timeout: 246 seconds)
05:14:52  * swajquit (Ping timeout: 246 seconds)
05:15:41  * swajjoined
05:18:48  * paulfryzeljoined
05:22:26  * defunctzombiechanged nick to defunctzombie_zz
05:23:03  * paulfryzelquit (Ping timeout: 245 seconds)
05:33:34  * mikealjoined
05:35:32  * mikealquit (Client Quit)
05:35:43  * AvianFluquit (Remote host closed the connection)
05:35:57  * kazuponquit (Read error: Connection reset by peer)
05:36:15  * kazuponjoined
05:44:29  * wolfeidaujoined
05:46:49  * mikealjoined
05:51:03  * mikealquit (Ping timeout: 246 seconds)
05:55:16  * dshaw_joined
05:58:34  * mikealjoined
06:06:17  * hueniversejoined
06:06:41  * hueniversepart
06:12:28  * groundwaterquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
06:18:29  * wolfeidauquit (Remote host closed the connection)
06:19:35  * paulfryzeljoined
06:23:53  * paulfryzelquit (Ping timeout: 245 seconds)
06:35:44  * dshaw_quit (Quit: Leaving.)
06:41:45  <MI6>nodejs-v0.10-windows: #340 UNSTABLE windows-ia32 (10/604) windows-x64 (11/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/340/
06:55:09  * stagasquit (Ping timeout: 272 seconds)
07:11:36  * bajtosjoined
07:20:21  * paulfryzeljoined
07:22:08  * dshaw_joined
07:24:43  * paulfryzelquit (Ping timeout: 245 seconds)
07:29:04  * rmgquit
07:30:41  * octetcloudquit (Ping timeout: 246 seconds)
07:34:01  * stagasjoined
07:57:33  * rendarjoined
08:03:49  * stagasquit (Ping timeout: 272 seconds)
08:21:07  * paulfryzeljoined
08:25:33  * paulfryzelquit (Ping timeout: 245 seconds)
08:45:26  * hzjoined
08:59:18  * bradleymeckquit (Quit: bradleymeck)
09:07:35  * mcavage_joined
09:07:36  * mcavagequit (Read error: Connection reset by peer)
09:10:18  <indutny>heya
09:21:53  * paulfryzeljoined
09:26:23  * paulfryzelquit (Ping timeout: 245 seconds)
09:27:12  <MI6>joyent/libuv: Fedor Indutny master * bf5038d : fsevents: fix subfolder check - http://git.io/Rtielw
09:28:47  * m76quit (Read error: Connection reset by peer)
09:48:31  * kellabytequit (Remote host closed the connection)
09:51:11  * inolenquit (Quit: Leaving.)
09:54:44  * dshaw_quit (Quit: Leaving.)
10:19:16  * kazuponquit (Remote host closed the connection)
10:19:44  * kazuponjoined
10:21:49  * inolenjoined
10:22:35  * paulfryzeljoined
10:23:31  * inolen1joined
10:23:44  * inolenquit (Read error: Connection reset by peer)
10:24:48  * kazuponquit (Ping timeout: 272 seconds)
10:27:13  * paulfryzelquit (Ping timeout: 245 seconds)
10:27:55  * inolen1quit (Ping timeout: 245 seconds)
10:28:20  <rvagg>guys, does anyone have a good handle on NamedPropertyQuery and IndexedPropertyQuery in v8::ObjectTemplate?
10:29:04  <rvagg>I know they can be used to influence hasOwnProperty() but what else? they an return DontEnum, ReadOnly, etc. yet they don't seem to impact Object.getOwnPropertyDescriptor(obj, prop)
10:30:38  <rvagg>google is useless on this, Node core uses them for process.env but the tests don't shed much light on what else they might do, v8 tests don't shed any light that I can discover...
10:32:36  * mmaleckijoined
10:35:07  * mmaleckiquit (Client Quit)
10:35:18  * mmaleckijoined
10:48:08  * bajtosquit (Quit: bajtos)
10:48:27  * dshaw_joined
10:55:47  <MI6>nodejs-v0.10: #1621 UNSTABLE smartos-x64 (6/604) smartos-ia32 (7/604) linux-x64 (1/604) linux-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1621/
10:56:42  * wolfeidaujoined
11:04:37  * m76joined
11:07:13  * dshaw_quit (Ping timeout: 272 seconds)
11:23:25  * paulfryzeljoined
11:24:14  * inolenjoined
11:27:38  * paulfryzelquit (Ping timeout: 245 seconds)
11:28:25  * inolenquit (Read error: Operation timed out)
11:28:51  * abraxasquit (Remote host closed the connection)
11:38:15  * bajtosjoined
11:39:51  * kazuponjoined
11:41:39  * `3E|Zzchanged nick to `3E
11:48:22  * bnoordhuisjoined
11:56:28  <mmalecki>getting an interesting assertion error on 0.11 with npm, assertion failed here: https://github.com/joyent/node/blob/master/lib/_http_client.js#L270
12:01:58  * dshaw_joined
12:06:15  * dshaw_quit (Ping timeout: 245 seconds)
12:08:08  * kazuponquit (Remote host closed the connection)
12:12:02  <indutny>bnoordhuis: hello man
12:12:13  <indutny>mmalecki: if you wish - you could debug it :)
12:12:21  <indutny>mmalecki: that error bothers me as well
12:14:43  <indutny>bnoordhuis: yt?
12:24:11  * paulfryzeljoined
12:24:58  * inolenjoined
12:28:28  * paulfryzelquit (Ping timeout: 245 seconds)
12:28:47  * kazuponjoined
12:29:55  * inolenquit (Ping timeout: 272 seconds)
12:31:11  <bnoordhuis>indutny: what's up
12:31:15  <indutny>heya
12:31:29  <indutny>do you know if it should be ok to set IP_PKTINFO on ipv6 dual-stack socket?
12:31:37  <bnoordhuis>it only works for ipv4
12:31:38  <indutny>from all docs I found it seems that answer is yes
12:31:42  <indutny>bnoordhuis: well
12:31:51  <indutny>IPV6_RECVPKTINFO will return only incoming ipv6 addresses
12:31:56  <indutny>that's per spec
12:31:59  <indutny>and happens in reality
12:32:35  <indutny>bnoordhuis: do you know any other way to receive IP_PKTINFO on ipv6 socket?
12:33:20  <bnoordhuis>depends on whether you mean on linux or in general
12:34:14  <indutny>haha
12:34:24  <indutny>lets talk about linux for now
12:36:43  <bnoordhuis>well, IPV6_DSTOPTS maybe
12:36:58  <bnoordhuis>it may even be portable
12:37:51  <bnoordhuis>that said, it seems like a lot of work just to avoid having to bind to multiple interfaces explicitly
12:38:07  <bnoordhuis>it'd require an api change, for one
12:40:56  <indutny>well
12:40:59  <indutny>ok
12:41:04  <indutny>I can make it not change API
12:41:13  <indutny>but that will require an additional field on handle
12:42:58  <bnoordhuis>meh. like i said, i don't really see the need
12:43:28  <bnoordhuis>what makes you so eager to add it?
12:45:11  <indutny>actually
12:45:13  <indutny>nothing
12:45:18  <indutny>but its quite simple to add
12:46:03  <bnoordhuis>not _that_ simple. for one, IP_PKTINFO isn't portable
12:46:21  <bnoordhuis>it's a linux flag. os x supports it as well but i don't know since when
12:46:36  <mmalecki>indutny: will do. bored at work.
12:46:45  <mmalecki>ENTERTAIN ME
12:46:50  <mmalecki>hmmm!
12:46:54  <mmalecki>thanks LOUDBOT!
12:49:05  <indutny>bnoordhuis: it supports it
12:49:08  <indutny>bnoordhuis: since 10.6
12:51:58  * dshaw_joined
12:55:29  <bnoordhuis>indutny: that leaves the bsds and solaris
12:55:38  <indutny>well
12:55:43  <indutny>I give up :)
12:55:48  <indutny>don't want to waste my time on it
12:55:52  <indutny>but I sent a preliminary patch to user
12:56:14  <bnoordhuis>mmalecki: how's the new job?
12:56:43  * dshaw_quit (Ping timeout: 265 seconds)
12:56:48  <mmalecki>bnoordhuis: it's awesome! I really love it. building an awesome deployment architecture :-)
12:57:21  <mmalecki>bnoordhuis: (I'm also starting my own thing on the side)
12:58:27  <bnoordhuis>what thing is that?
12:58:54  <mmalecki>bnoordhuis: gonna PM :)
13:00:23  <indutny>haha
13:05:24  <bnoordhuis>indutny: "I guess it should be closed" -> eh?
13:05:35  <indutny>bnoordhuis: well you put "fixes #.." in commit log
13:05:38  <indutny>instead of "fix #..."
13:05:49  <indutny>and issue wasn't closed
13:06:03  <indutny>yeah, my comment was kind of awkward
13:06:09  <indutny>is that commit in master on v0.10?
13:06:45  <mmalecki>indutny: both close issues, it's just that github disregards any commits not on main branch
13:07:20  <mmalecki>so pushing to 0.10 won't close issues
13:07:50  <bnoordhuis>indutny: i haven't pushed anything yet, only opened the PR :)
13:08:15  <bnoordhuis>indutny: https://github.com/joyent/node/pull/6584
13:13:17  <indutny>oh
13:19:04  * Chip_Zeroquit (Ping timeout: 264 seconds)
13:20:01  * Chip_Zerojoined