00:00:01  * st_lukequit (Remote host closed the connection)
00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:00:27  * st_lukejoined
00:04:16  * Damn3djoined
00:04:38  * st_lukequit (Ping timeout: 240 seconds)
00:07:47  * calvinfoquit (Quit: Leaving.)
00:09:32  * calvinfojoined
00:21:08  * mikealquit (Quit: Leaving.)
00:21:16  * mikealjoined
00:33:33  * inolenjoined
00:35:25  * inolenquit (Client Quit)
00:35:26  * wolfeidaujoined
00:39:30  * daviddiasquit (Ping timeout: 245 seconds)
00:44:04  * defunctzombie_zzchanged nick to defunctzombie
01:02:25  * defunctzombiechanged nick to defunctzombie_zz
01:04:29  * mcavagequit
01:11:36  * jmar777joined
01:15:33  * octetcloudquit (Ping timeout: 246 seconds)
01:16:05  * jmar777quit (Remote host closed the connection)
01:20:46  * calvinfoquit (Quit: Leaving.)
01:21:01  * jmar777joined
01:22:11  * mikealquit (Quit: Leaving.)
01:22:20  * mikealjoined
01:27:31  * inolenjoined
01:27:31  * inolenquit (Client Quit)
01:28:56  * inolenjoined
01:31:19  * defunctzombie_zzchanged nick to defunctzombie
01:43:05  <piscisaureus>indutny: tcp_close_accept doesn't pass on windows, because you're read_starting from an unconnected stream
01:45:59  <MI6>joyent/libuv: Bert Belder v0.10 * 7b16a3f : windows: avoid assertion failure when pipe server is closed - http://git.io/e_ktRg
01:46:36  <tjfontaine>that's for sam's bug?
01:47:41  * mikealquit (Quit: Leaving.)
01:49:52  <MI6>joyent/libuv: Bert Belder master * 46a0602 : Merge branch 'v0.10' (+4 more commits) - http://git.io/8nDusA
01:49:55  <piscisaureus>yes
01:50:18  <piscisaureus>tjfontaine: I'd have gone through review if there was anyone on the planet that understands that code
01:50:38  <piscisaureus>hopefully alexis at some point :)
01:50:45  <tjfontaine>haha, well it could have had a test and could have referenced the node bug :)
01:51:21  <piscisaureus>let's add the test to node
01:56:35  * c4miloquit (Remote host closed the connection)
01:56:47  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:04:28  <piscisaureus>tjfontaine: actually, no, let me add a test to libuv too
02:04:46  <tjfontaine>ok thanks
02:06:53  * c4milojoined
02:14:41  * inolenquit (Quit: Leaving.)
02:17:45  <piscisaureus>tjfontaine: so apparently somewhere in the past we enabled asserts in the windows release build? Do you know anything about that?
02:18:12  <tjfontaine>yes, because we're supposed to go to an assert/verify pattern
02:18:26  <tjfontaine>but ideally they blow int he same way
02:18:31  <tjfontaine>windows and unix that is
02:18:54  <piscisaureus>tjfontaine: right. I'm afraid there are some slow asserts in uv-win though, atleast iirc
02:19:18  <piscisaureus>but maybe nobody cares
02:19:47  <tjfontaine>well, I dunno, a lot of people develop on windows and deploy elsewhere
02:21:18  * calvinfojoined
02:21:45  <piscisaureus>true thing
02:21:50  <piscisaureus>on linux, most notably :)
02:21:59  <tjfontaine>because who would deploy on osx
02:22:02  <piscisaureus>speaking of which
02:22:14  <piscisaureus>trevnorris: you got any word from your apple friend?
02:22:23  <tjfontaine>which apple friend?
02:23:03  <piscisaureus>dunno, but he's supposed to route the pwrite-threadsafety-issue report to the right person
02:23:14  <tjfontaine>ah and get rid of the big lock
02:23:21  <piscisaureus>yep that's the goal
02:25:41  * calvinfoquit (Ping timeout: 248 seconds)
02:26:04  * inolenjoined
02:32:00  * mikealjoined
02:33:46  * dap_quit (Quit: Leaving.)
02:34:14  * mikealquit (Client Quit)
02:35:57  <MI6>libuv-master-gyp: #355 UNSTABLE windows-x64 (4/201) linux-ia32 (1/202) smartos-ia32 (4/202) smartos-x64 (3/202) windows-ia32 (4/201) http://jenkins.nodejs.org/job/libuv-master-gyp/355/
02:37:59  * brson_joined
02:39:15  * brson_quit (Client Quit)
02:39:28  * brson_joined
02:39:41  <MI6>libuv-v0.10: #141 FAILURE windows (6/190) smartos (2/190) http://jenkins.nodejs.org/job/libuv-v0.10/141/
02:40:57  * brsonquit (Ping timeout: 246 seconds)
02:42:18  <MI6>libuv-v0.10-gyp: #112 UNSTABLE smartos-x64 (2/190) linux-x64 (1/190) windows-x64 (6/190) windows-ia32 (7/190) smartos-ia32 (2/190) linux-ia32 (1/190) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/112/
02:44:07  <MI6>libuv-master: #402 UNSTABLE smartos (3/202) windows (4/201) http://jenkins.nodejs.org/job/libuv-master/402/
02:46:00  * timoxleyjoined
02:55:44  * calvinfojoined
02:58:47  * wolfeidauquit (Remote host closed the connection)
03:00:07  * calvinfoquit (Ping timeout: 250 seconds)
03:03:48  <MI6>joyent/node: Fedor Indutny master * 82098bb : util: introduce CHECK_EQ/CHECK_NE - http://git.io/ELaZvA
03:04:07  <MI6>libuv-node-integration: #360 UNSTABLE linux-ia32 (1/686) smartos-x64 (7/686) smartos-ia32 (6/686) linux-x64 (2/686) http://jenkins.nodejs.org/job/libuv-node-integration/360/
03:04:52  * wolfeidaujoined
03:12:25  * inolenquit (Quit: Leaving.)
03:19:49  <MI6>nodejs-master: #801 UNSTABLE smartos-x64 (8/686) centos-ia32 (3/686) ubuntu-ia32 (2/686) smartos-ia32 (6/686) centos-x64 (1/686) ubuntu-x64 (2/686) http://jenkins.nodejs.org/job/nodejs-master/801/
03:20:22  * TooTallNatejoined
03:23:17  * wolfeidauquit (Remote host closed the connection)
03:23:45  * wolfeidaujoined
03:26:27  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:26:54  * calvinfojoined
03:32:49  * inolenjoined
03:33:29  * stagasjoined
03:40:26  <MI6>joyent/libuv: Bert Belder v0.10 * c66340d : test: add pipe-server-close test (+1 more commits) - http://git.io/yz6OeA
03:41:15  <tjfontaine>piscisaureus: thanks
03:41:44  <piscisaureus>tjfontaine: welcome. Let's hope for a green build, I wasn't able to run the test on mac.
03:42:05  * piscisaureusfires up the altar
03:42:07  * st_lukejoined
03:47:51  <piscisaureus>I guess ben would've disagreed with my strip-trailing-whitespace commit.
03:48:13  <tjfontaine>nah it's fine, we need to get a linter in place for libuv as well
03:48:23  <tjfontaine>the policy we have for one project should apply to both :)
03:48:48  * calvinfoquit (Quit: Leaving.)
03:49:05  <piscisaureus>yeah, I just do that because my strip-whitespace precommit hook does it
03:49:16  <piscisaureus>tjfontaine: the only thing is, do you know of a good C linter?
03:49:37  <tjfontaine>I don't use one, but I'm sure I can get feedback from other folks who use them
03:50:04  * AvianFlujoined
03:50:11  <piscisaureus>libuv code style isn't super consistent because we've shifted a little over time
03:50:44  <tjfontaine>well when we add the linter we can lint at the same time
03:50:49  <piscisaureus>although Ben's style is arguably the most consistent so we should probably just stick to that
03:51:39  <piscisaureus>and src/win/pipe.c is still in dire need of a rewrite
03:51:52  <piscisaureus>it's almost openssl bad
03:52:19  * wolfeidauquit (Remote host closed the connection)
03:52:54  * c4miloquit (Read error: Connection reset by peer)
03:55:03  <piscisaureus>tjfontaine: where was that jsapi design concept that you wrote again?
03:56:08  <tjfontaine>I have scheduled more time to work on it this week, but the start of it is -- github.com/tjfontaine/node-addon-layer
03:56:23  <tjfontaine>there are a few PRs and issues outstanding, and it needs a quick refresh for 0.12
03:56:43  <piscisaureus>tjfontaine: I want to evaluate it and see if it'd work for spidermonkey
03:57:20  <tjfontaine>for the most part I think it should, there's nothing particularly scary about it, the concept to make persistents -> local's needs to be refined, but in jsapi they're basically noops
03:57:35  <tjfontaine>brb taking my contacts out
03:57:50  * c4milojoined
03:59:44  <piscisaureus>tjfontaine: it requires a lot of mallocs... is there no c++ template magic that we could do instead?
04:00:02  <piscisaureus>trading a longer compilation time for a faster runtime
04:04:01  * mikealjoined
04:04:35  <tjfontaine>maybe, when it's been determined it's necessary, ya -- so far that stuff hasn't even registered for the largest consumer of the api
04:04:44  * mikealquit (Client Quit)
04:04:45  * calvinfojoined
04:05:13  <tjfontaine>and they're using it in a high throughput scenario
04:05:49  <tjfontaine>I mean patches are welcome
04:05:51  <tjfontaine>:)
04:06:21  <tjfontaine>there's some pressure to try and get it shipped in 0.12 just so it can be there for people to try and consume, even with the caveat that it may be the only interface with flux before 1.0
04:06:46  <tjfontaine>mostly there will be just api additions though
04:11:13  * timoxleyquit (Remote host closed the connection)
04:13:11  * zhengjoined
04:18:02  * wolfeidaujoined
04:18:55  * abraxasjoined
04:22:58  * dap_joined
04:23:02  * abraxasquit (Ping timeout: 240 seconds)
04:26:29  * jmar777quit (Remote host closed the connection)
04:27:39  * dap_quit (Read error: Connection reset by peer)
04:29:11  * zhengquit (Read error: Connection reset by peer)
04:31:49  * dap_joined
04:38:30  * timoxleyjoined
04:52:08  * calvinfoquit (Quit: Leaving.)
04:53:42  * timoxleyquit (Remote host closed the connection)
05:00:16  * dap_quit (Quit: Leaving.)
05:10:26  * st_lukequit (Remote host closed the connection)
05:19:19  * calvinfojoined
05:23:44  * calvinfoquit (Read error: Connection reset by peer)
05:24:06  * calvinfojoined
05:26:23  * c4miloquit (Remote host closed the connection)
05:26:46  * defunctzombiechanged nick to defunctzombie_zz
05:27:47  * wolfeidauquit (Remote host closed the connection)
05:30:31  * wolfeidaujoined
05:43:56  <trevnorris>piscisaureus: not yet. i'm going to hit him up after the holiday
05:44:19  <piscisaureus>trevnorris: holiday!?
05:44:43  <trevnorris>heh
05:45:19  <piscisaureus>trevnorris: no, but, good! Hopefully it'll work
05:45:56  <trevnorris>confident i'll at least be able to get in contact with him. i know enough people that work there.
05:46:30  <trevnorris>actually, maybe i'll hit up a friend that works on the display kernel drivers and see if he knows anyone else that works on the fs kernel drivers.
05:57:28  <trevnorris>piscisaureus: can you give me a hint where uv__run_idle is defined?
05:58:05  <piscisaureus>trevnorris: unix I suppose/
05:58:20  <piscisaureus>trevnorris: the implementation is in src/loop-watcher.c
05:58:34  <piscisaureus>er, src/unix/loop-watcher.c
05:58:58  <trevnorris>...
05:59:02  <trevnorris>damn all those macros
06:00:22  <trevnorris>think I'll just clang -E all the source and store it somewhere else for grep-ability
06:00:43  <piscisaureus>The pot and the kettle. Have you ever seen the spidermonkey source :-p
06:01:11  <trevnorris>actually, i've actively not gone into that source.
06:01:41  <trevnorris>had to work with it when compiling some custom stuff, but the fact it's all in moz-central makes it a freakin pain
06:02:17  <trevnorris>i'd be way more down for exploring a SM fork of node if its source wasn't so integrated into that one massive repo
06:04:05  <piscisaureus>trevnorris: I hear you, and I'm working on it :)
06:04:15  <trevnorris>heh, good for you :)
06:04:17  <piscisaureus>trevnorris: almost done removing the dependency on nspr
06:04:45  <trevnorris>that's awesomel
06:14:14  <trevnorris>piscisaureus: have a moment for a couple libuv n00b questions?
06:16:52  <piscisaureus>trevnorris: shoot
06:18:21  <trevnorris>piscisaureus: when nothing is going on, does uv_run have a blocking point in the while loop that makes it sit idle, or is the while loop constantly being iterated?
06:18:49  <piscisaureus>trevnorris: it is idle. epoll() or kqueue() or whatever is called with a timeout
06:19:09  <piscisaureus>trevnorris: and that call blocks until either the timeout expires or there are events to report
06:19:32  <piscisaureus>trevnorris: but if there are active uv_idle handles the timeout is zero
06:21:58  <trevnorris>ah ha. thanks. that's the key bit that explains setImmediate. thanks.
06:27:36  * stagasquit (Quit: Bye)
06:36:21  * mikealjoined
06:39:39  * wolfeidauquit (Remote host closed the connection)
06:41:21  <MI6>nodejs-v0.10-windows: #395 UNSTABLE windows-ia32 (11/606) windows-x64 (11/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/395/
06:42:17  * wolfeidaujoined
06:47:51  * AvianFluquit (Remote host closed the connection)
06:51:40  * wolfeidauquit (Remote host closed the connection)
06:55:20  * brson_quit (Quit: leaving)
07:00:40  * jmar777joined
07:01:30  <trevnorris>indutny: hey: "../test/test-tcp-try-write.c:59:12: warning: unused variable 'buf' [-Wunused-variable]"
07:04:39  * jmar777quit (Ping timeout: 240 seconds)
07:15:11  * c4milojoined
07:19:35  * c4miloquit (Ping timeout: 245 seconds)
07:22:54  * bradleymeckjoined
07:25:14  * bradleymeckquit (Client Quit)
07:25:40  * st_lukejoined
07:27:44  * felixgejoined
07:28:40  * saghul_quit (Quit: Konversation terminated!)
07:36:03  * calvinfoquit (Quit: Leaving.)
07:36:14  * saghulquit (Quit: ["Textual IRC Client: www.textualapp.com"])
07:40:37  <indutny>trevnorris: in node?
07:40:44  <trevnorris>indutny: libuv
07:40:47  <indutny>trevnorris: fixed in libuv
07:40:52  <indutny>I think
07:40:56  <trevnorris>ah, wait.
07:41:02  <trevnorris>haven't pulled.
07:41:03  <trevnorris>sorry
07:48:48  <trevnorris>indutny: can you give me a description of what's going on in uv__run_pending() ?
07:51:21  <indutny>trevnorriss: sorry, was afk
07:52:28  <indutny>trevnorris: it's sort of next tick
07:52:33  <indutny>but from POLLOUT/POLLIN events
07:54:02  <trevnorris>indutny: ok, maybe you could help me understand why it's run after uv__run_prepare() when the docs say uv__run_prepare runs "just before the system blocks to wait for completed i/o"
07:54:27  <trevnorris>i.e. uv__run_prepare() should run just before uv__io_poll()
07:55:04  <indutny>honestly saying, idk
07:55:11  <indutny>but I think this is because it is emulating IO
07:55:15  <indutny>IO events
07:55:22  <indutny>and that semantically fits here
07:55:40  <trevnorris>ok cool.
07:56:14  <trevnorris>i'm trying to do a more specific write up of how node utilizes each step in uv_run. i'm getting most of it, but still a few things here and there that elude me
08:04:09  * st_lukequit (Remote host closed the connection)
08:08:14  <trevnorris>man, uv__run_pending i'm not getting. like, why the linked list of uv__io_t on loop->pending_queue, and what callbacks are being called on those?
08:14:21  * daviddiasjoined
08:19:06  * rendarjoined
08:28:35  * daviddiasquit (Ping timeout: 250 seconds)
08:29:13  * wolfeidaujoined
08:41:42  <indutny>trevnorris: use the source :)
08:42:00  <trevnorris>indutny: yeah. got it now. working on uv__run_closing_handles() :)
08:49:33  * rmgquit (Remote host closed the connection)
08:55:27  * Kakerajoined
09:04:02  * c4milojoined
09:08:39  * c4miloquit (Ping timeout: 252 seconds)
09:13:17  <trevnorris>indutny: mind correcting my interpretation of uv_run(): https://gist.github.com/trevnorris/8067133
09:16:21  <indutny>uv__run_idle() ?
09:16:23  <indutny>run active handle
09:16:31  <indutny>I thought it was about uv_idle_t
09:17:02  <indutny>oh
09:17:13  <indutny>you're just doing node-specific description of meaning of those guys
09:17:49  <indutny>well
09:17:50  <indutny>lgtm, generally
09:23:33  <trevnorris>indutny: thanks.
09:24:12  <trevnorris>indutny: btw, do you know off the top of your head if Server#close() runs the callback from uv__run_closing_handles()? that seems like the logical place for it to be executed.
09:28:15  <indutny>hm...
09:28:21  <indutny>yes, i think it does
09:29:42  <trevnorris>thanks
09:39:08  * hzjoined
09:43:45  * hueniverse1joined
09:44:02  * hueniversequit (Ping timeout: 264 seconds)
09:54:04  * hueniversejoined
09:55:54  * hueniverse1quit (Ping timeout: 265 seconds)
10:01:17  <trevnorris>indutny: freak. the close callback is actually pseudo-asynchronous. it's actually just emitted through a nextTick(), so internally he handle hasn't reached uv__run_closing_handles() before the user receives the close callback
10:01:29  <indutny>oh
10:01:33  <trevnorris>*the handle
10:01:35  <indutny>that is quite surprising
10:01:42  <indutny>I thought it is calling .handle.close
10:01:46  <indutny>and doing stuff in callback
10:01:47  <indutny>but
10:01:48  <indutny>whatever
10:02:04  <trevnorris>well. we are calling ._handle.close(), but no callback is passed there.
10:02:58  <indutny>well
10:04:48  * hueniversequit (Read error: Connection reset by peer)
10:05:44  <trevnorris>indutny: ok. so I switched Server#close() in lib/net.js to just pass the cb to ._handle.close() instead. gets called as expected.
10:06:28  <trevnorris>don't understand why we're doing it that way, but whatever
10:07:38  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
10:15:04  * indexzerojoined
10:21:49  * abraxasjoined
10:22:39  <indutny>trevnorris: ok
10:22:41  <indutny>send a PR
10:23:17  <trevnorris>indutny: i tried a quick patch. seems to screw with the cluster/slave process stuff. i'll take a deeper look.
10:24:25  <trevnorris>indutny: also, it might confuse the user because, the execution order of a setTimeout and setImmediate will swap since uv__run_closing_handles() is the last thing to be executed on the event loop.
10:24:40  <trevnorris>(but, I really don't care about that :P )
10:25:24  <trevnorris>indutny: anyways. thanks for helping me understand uv_run better. really clears things up.
10:25:56  <trevnorris>now, just need to write it up in a simple way so the community will stop asking about it all the time.
10:26:15  * abraxasquit (Ping timeout: 245 seconds)
10:26:38  <indutny>oh
10:26:48  <indutny>np
10:27:47  <MI6>joyent/libuv: piscisaureus created branch temp - http://git.io/iztlfw
10:28:23  <trevnorris>tjfontaine: here is a quick thought on nextTick: https://gist.github.com/trevnorris/8067633
10:30:39  <trevnorris>tjfontaine: overall we need to have a discussion on how the eloop is being used. as I've just discussed with indutny, we're doing some stupid stuff like calling the close callback before the handle has actually had a chance to close internally.
10:32:41  <MI6>joyent/libuv: Bert Belder temp * a4660fb : test: make test-pipe-server-close pass on linux - http://git.io/5AA9zQ
10:39:04  <MI6>joyent/libuv: Bert Belder v0.10 * 16c4b21 : test: make test-pipe-server-close pass on linux - http://git.io/9DfyeQ
10:41:19  <indutny>bertje
10:41:22  <indutny>where are ya? :)
10:42:50  * trevnorris&
10:42:50  <LOUDBOT>YOUR MANHOOD WON'T BE INTACT MUCH LONGER IF YOU DON'T START SHOUTING
10:42:57  <MI6>joyent/libuv: Bert Belder master * 140c863 : Merge branch 'v0.10' (+3 more commits) - http://git.io/H_JKtg
10:49:27  <MI6>nodejs-v0.10: #1677 UNSTABLE smartos-ia32 (5/606) osx-ia32 (1/606) linux-ia32 (4/606) osx-x64 (1/606) linux-x64 (5/606) smartos-x64 (6/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1677/
10:52:54  * c4milojoined
10:57:26  * c4miloquit (Ping timeout: 240 seconds)
10:58:17  * piscisaureusjoined
10:58:29  <piscisaureus>indutny: sup?
10:58:42  <indutny>piscisaureus: so about that close-accept test?
10:58:53  <indutny>it is a windows implementation bug, right?
10:58:54  <piscisaureus>indutny: ya
10:58:58  <piscisaureus>indutny: yes
10:59:08  <piscisaureus>indutny: it's fixed now
10:59:21  <indutny>ok, great
10:59:30  <indutny>what about uv_write() right after uv_connect()
10:59:40  <indutny>will you have time to work on queueing them?
10:59:46  <indutny>or should I do it?
11:00:09  <piscisaureus>indutny: not sure, depends on what we prioritize :)
11:00:15  <indutny>haha
11:00:15  <piscisaureus>indutny: if you have time, do it!
11:00:16  <indutny>that's right
11:00:23  <indutny>well, can't say that I have much
11:00:23  <piscisaureus>indutny: I'd be super happy
11:00:33  <indutny>but if you wouldn't do it, I'll eventually fill the gap :)
11:00:40  <piscisaureus>indutny: for the time being I'll have 1-2 days/week for node+libuv max
11:00:48  <indutny>oh, I see
11:00:59  <piscisaureus>indutny: I'm still not happy with uv_try_write btw ...
11:01:03  <piscisaureus>:)
11:01:17  <piscisaureus>but you and saghul are doing a good job nonetheless
11:01:33  <indutny>piscisaureus: heh
11:01:46  <indutny>you'll be happy once you'll see how it fits nicely in node
11:01:55  <indutny>I already used it in bud
11:02:09  <piscisaureus>indutny: only if you make it cross-platform. But even then...
11:02:16  <indutny>well
11:02:21  <piscisaureus>indutny: I want to have thread-safe handles in libuv btw
11:02:26  <piscisaureus>long-term goal so to speak
11:02:41  <indutny>you mean windows handles or uv_handle_t ?
11:03:01  <piscisaureus>So I can do uv_write(handle, stuff, some_other_loop_where_the_callback_happens)
11:03:06  <piscisaureus>indutny: yes
11:03:38  <piscisaureus>indutny: so we can have off-thread streams processing
11:04:08  <piscisaureus>indutny: it lets me do off-thread http parsing for project x
11:05:29  <indutny>hm...
11:05:41  <indutny>hrm
11:05:53  <indutny>I think you just need to
11:06:09  <indutny>uv_handle_transfer(handle, src_loop, dst_loop)
11:06:20  <indutny>not thread-safe version of every method :D
11:06:29  <piscisaureus>indutny: I'm open to all suggestions :)
11:06:34  <indutny>well
11:06:43  <indutny>that will make minimal damage to all users :D
11:06:48  <piscisaureus>indutny: I was thinking of uv_stream_init(x, y, z, UV_HANDLE_THREADSAFE)
11:07:22  <indutny>is there any point in using it from two threads simultaneously?
11:07:34  <indutny>writes won't work well
11:07:41  <indutny>so only if one thread reads and other writes
11:07:43  <indutny>but that smells bad
11:07:57  <piscisaureus>indutny: well, starting the action from thread A and having the callback on thread B seems useful
11:08:08  <indutny>you can already do it :)
11:08:09  <indutny>uv_async_send
11:08:16  <piscisaureus>it's inefficient
11:08:21  <piscisaureus>I can never win from nginx that way
11:08:37  <indutny>hm....
11:08:41  <indutny>does nginx do it?
11:08:52  <piscisaureus>I don't know what nginx does
11:08:57  <piscisaureus>but it has to be faster!
11:09:33  <piscisaureus>indutny: I think cluster is lame, and I just want to build an http load balancer
11:12:22  * janjongboomjoined
11:26:24  * deoxxajoined
11:27:36  <deoxxa>i'm getting a segfault that seems to come from uv_ip4_name on mac with libuv 0.10.18 - have there been any related fixes since that tag?
11:28:12  <deoxxa>strangely, the segfault happens a while after uv_ip4_name is called, but removing it makes it go away
11:28:57  <deoxxa>i'm about to update to 0.10.21 and see if it's still a thing
11:30:05  <piscisaureus>I don't know, but indutny does
11:31:27  <deoxxa>mmm, looks like it's still dying... weird.
11:32:16  <indutny>heya
11:32:29  <indutny>hm...
11:32:41  <indutny>deoxxa: I'm not aware of any fixes, but perhaps there were
11:32:57  <piscisaureus>ok I am going to bed
11:32:58  <indutny>deoxxa: let me know if it doesn't work for you on 0.10.21 too
11:33:03  <piscisaureus>it's 3:30am here
11:33:09  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
11:33:12  <deoxxa>i just tried it with 0.10.21, still crashing
11:33:18  <deoxxa>i'm going to do a debug build and get some stack traces
11:38:06  <deoxxa>indutny: https://gist.github.com/deoxxa/c85c62baeac6013a1e5b
11:39:58  <deoxxa>anything you want me to punch into lldb to poke around?
11:41:58  <indutny>deoxxa: how are you calling it?
11:42:47  <deoxxa>https://gist.github.com/deoxxa/c85c62baeac6013a1e5b#file-mesh-c-L20-L23 << like that
11:43:31  <indutny>oh
11:43:33  <indutny>I guess
11:43:38  <indutny>one sec
11:45:03  <indutny>I think that only sin_addr is filled there
11:45:11  <indutny>or sin6_addr depending on ip version
11:45:17  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:45:23  <indutny>h
11:45:24  <indutny>hm
11:45:26  <indutny>sin_port too
11:45:47  <deoxxa>oh, weird
11:45:58  <deoxxa>it's especially weird because it actually outputs the right value
11:46:09  <indutny>it's quite odd, actually
11:46:20  <indutny>it should be filled properly
11:46:20  <indutny>wtf
11:46:40  <deoxxa>https://gist.github.com/deoxxa/c85c62baeac6013a1e5b#file-lldb-output-L6 << see how it actually does give me back the right ip
11:46:55  <indutny>ah
11:46:56  <indutny>gosh
11:47:00  <indutny>deoxxa: addr is NULL
11:47:00  <deoxxa>it's really strange
11:47:00  <indutny>:D
11:47:03  <deoxxa>oh
11:47:10  <indutny>mesh`on_read(req=0x00007fff5fbff868, nread=0, buf=uv_buf_t at 0x00007fff5fbf7468, addr=0x0000000000000000, flags=0)
11:47:18  <deoxxa>oh my
11:47:20  <deoxxa>der
11:47:26  <deoxxa>thanks :)
11:49:01  <indutny>np
11:49:04  <indutny>you're welcome
11:49:35  <deoxxa>well, i guess the second part to that question is "why is addr null?"
11:49:35  <deoxxa>lol
11:50:55  <deoxxa>and how is it getting the right value...
11:52:02  <indutny>I guess
11:52:05  <indutny>because nread==0
11:52:19  <deoxxa>oh
11:52:20  <deoxxa>jeez
11:52:37  <deoxxa>it must be amateur hour at my place
12:21:43  * janjongboomjoined
12:41:45  * c4milojoined
12:46:09  * c4miloquit (Ping timeout: 240 seconds)
12:50:27  * felixgequit (Quit: felixge)
12:55:18  * rmgjoined
12:56:21  * indexzeroquit (Quit: indexzero)
12:57:23  * deoxxaquit (Quit: Leaving.)
13:00:33  * deoxxajoined
13:01:25  * rmgquit (Ping timeout: 248 seconds)
13:22:11  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:26:41  * brycebarilquit (Ping timeout: 252 seconds)
13:32:27  * felixgejoined
13:39:50  * dqminhquit (Ping timeout: 264 seconds)
13:43:45  * dqminhjoined
13:44:42  * brycebariljoined
13:45:20  * dsantiagoquit (Quit: Computer has gone to sleep.)
13:48:47  * skypjackjoined
13:51:02  * deoxxaquit (Quit: Leaving.)
13:57:35  * deoxxajoined
14:07:19  * m76joined
14:09:13  * kazuponjoined
14:14:12  * zhengjoined
14:20:56  * deoxxaquit (Quit: Leaving.)
14:30:39  * kazuponquit (Remote host closed the connection)
14:30:42  * c4milojoined
14:35:20  * c4miloquit (Ping timeout: 260 seconds)
14:52:57  * zhengquit (Read error: Connection reset by peer)
14:56:39  * AvianFlujoined
15:03:59  <indutny>tjfontaine: hey man!
15:07:23  <tjfontaine>hey fedor
15:17:13  * kazuponjoined
15:21:26  <MI6>nodejs-master: #802 UNSTABLE smartos-x64 (8/686) centos-ia32 (4/686) ubuntu-ia32 (2/686) smartos-ia32 (6/686) osx-ia32 (1/686) centos-x64 (4/686) ubuntu-x64 (1/686) http://jenkins.nodejs.org/job/nodejs-master/802/
15:27:58  * bradleymeckjoined
15:30:47  * hzquit
15:32:24  * defunctzombie_zzchanged nick to defunctzombie
15:45:51  * c4milojoined
15:49:43  <tjfontaine>trevnorris: I commented on the gist
15:52:43  <indutny>tjfontaine: ohai
15:52:47  <indutny>sorry, missed that you was around
15:52:55  <indutny>may I ask you to spawn freebsd server?
16:02:19  * janjongboomjoined
16:08:20  * bradleymeckquit (Quit: bradleymeck)
16:16:04  * calvinfojoined
16:46:39  * calvinfoquit (Quit: Leaving.)
16:50:26  * defunctzombiechanged nick to defunctzombie_zz
16:54:50  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:19:37  * hueniversejoined
17:38:43  * bentkusjoined
17:38:55  <bentkus>indutny!
17:39:04  <indutny>bentkus: Andrius!
17:39:12  <bentkus>who is Igor?
17:39:13  * c4miloquit (Remote host closed the connection)
17:40:09  * niskaquit (Read error: Operation timed out)
17:40:12  * janjongboomjoined
17:40:18  <bentkus>all his branches are a year old and have nothing
17:40:48  * bentkuschanged nick to ToXedVIrus
17:41:00  * niskajoined
17:41:18  * ToXedVIruschanged nick to ToXedVirus
17:41:32  <ToXedVirus>damn it
17:41:34  * ToXedViruschanged nick to bentkus
17:42:34  <bentkus>wrong network
17:45:47  * c4milojoined
17:46:45  <bentkus>cleanup all the branches!
17:46:56  <bentkus>And what is it with people creating topic branches in the main repo
17:55:27  * c4miloquit (Remote host closed the connection)
17:56:24  * c4milojoined
17:59:28  <bentkus>indutny: can you open remove unused tags again?
17:59:39  * kazuponquit (Remote host closed the connection)
17:59:47  <bentkus>ill go through all the branches and tags and comment on them in that issue
18:00:06  <bentkus>all tags seem ok
18:00:15  <bentkus>only versions and always consistent
18:12:03  <indutny>bentkus: ok
18:46:21  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:55:24  * janjongboomjoined
18:57:32  * mikealquit (Quit: Leaving.)
18:57:57  * mikealjoined
19:10:04  * mikealquit (Quit: Leaving.)
19:10:13  * mikealjoined
19:10:35  * kazuponjoined
19:15:14  * kazuponquit (Ping timeout: 264 seconds)
19:17:12  * mikealquit (Quit: Leaving.)
19:18:23  * mikealjoined
19:23:16  * mikealquit (Quit: Leaving.)
19:23:25  * mikealjoined
19:40:11  * janjongboomquit (Read error: Connection reset by peer)
19:40:47  * janjongboomjoined
19:42:29  * Kakeraquit (Ping timeout: 248 seconds)
19:59:00  * calvinfojoined
20:11:35  * mikealquit (Quit: Leaving.)
20:11:42  * felixgequit (Quit: felixge)
20:12:46  * felixgejoined
20:13:03  * defunctzombie_zzchanged nick to defunctzombie
20:16:48  * calvinfoquit (Quit: Leaving.)
20:19:54  * felixgequit (Quit: felixge)
20:20:54  * felixgejoined
20:21:38  * felixgequit (Client Quit)
20:32:06  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:38:46  * rmgjoined
20:43:26  * rmgquit (Ping timeout: 264 seconds)
20:46:42  * c4miloquit (Remote host closed the connection)
20:52:58  * Kakerajoined
20:56:40  * AvianFluquit (Remote host closed the connection)
21:08:50  * brsonjoined
21:32:41  * calvinfojoined
21:35:18  * kenperkinsquit (Read error: Connection reset by peer)
21:37:25  * kenperkinsjoined
21:51:21  * indexzerojoined
21:57:12  * indexzeroquit (Quit: indexzero)
22:07:20  * AvianFlujoined
22:11:51  * AvianFluquit (Ping timeout: 252 seconds)
22:13:31  * rendarquit
22:16:27  * defunctzombiechanged nick to defunctzombie_zz
22:24:41  * m76quit (Read error: Connection reset by peer)
22:33:57  * deoxxajoined
23:13:14  * defunctzombie_zzchanged nick to defunctzombie
23:18:14  * defunctzombiechanged nick to defunctzombie_zz
23:18:18  * hzjoined
23:20:20  * defunctzombie_zzchanged nick to defunctzombie
23:27:48  * hzquit
23:41:03  * brsonquit (Ping timeout: 240 seconds)
23:43:14  * brsonjoined
23:43:53  * Kakeraquit (Ping timeout: 252 seconds)
23:44:14  * skypjackquit (Ping timeout: 250 seconds)
23:44:37  * skypjackjoined
23:56:17  * skypjackquit (Quit: Sto andando via)