00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:05:44  * kenperkinsjoined
00:10:37  * iarnaquit (Ping timeout: 245 seconds)
00:10:54  * sandr8joined
00:11:03  * calvinfoquit (Quit: Leaving.)
00:15:02  * iarnajoined
00:15:07  * sandr8quit (Ping timeout: 244 seconds)
00:15:44  * a_lejoined
00:16:10  * a_lequit (Remote host closed the connection)
00:17:38  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:24:59  * AlexisMochajoined
00:26:46  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
00:28:52  * bradleymeckjoined
00:29:40  * nsmquit (Ping timeout: 260 seconds)
00:30:15  * nsmjoined
00:31:09  * AlexisMochaquit (Ping timeout: 260 seconds)
00:36:09  * a_lejoined
00:36:20  * kenperkinsjoined
00:42:55  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:48:51  * jgiquit (Quit: jgi)
00:51:09  * thlorenzjoined
00:51:19  * kriskowalquit (Quit: kriskowal)
00:51:21  * thlorenzquit (Remote host closed the connection)
00:51:58  * thlorenzjoined
00:52:43  * jgijoined
00:53:09  * Ralithquit (Ping timeout: 246 seconds)
00:54:53  * a_lequit (Remote host closed the connection)
00:55:32  * a_lejoined
00:56:27  * thlorenzquit (Ping timeout: 244 seconds)
01:00:26  * kriskowaljoined
01:01:51  * kriskowalquit (Client Quit)
01:04:17  * kriskowaljoined
01:05:46  * a_lequit (Remote host closed the connection)
01:05:53  * bajtosquit (Quit: bajtos)
01:06:15  * bajtosjoined
01:06:32  * bajtosquit (Client Quit)
01:11:33  * kazuponjoined
01:11:39  * calvinfojoined
01:11:48  * kriskowalquit (Quit: kriskowal)
01:12:58  * FROGGS_joined
01:16:07  * FROGGSquit (Ping timeout: 245 seconds)
01:16:18  * calvinfoquit (Ping timeout: 258 seconds)
01:19:40  * dsantiagojoined
01:24:35  * Ralithjoined
01:28:34  * calvinfojoined
01:28:34  * kenperkinsjoined
01:35:21  * chris_99joined
01:35:40  * jgiquit (Quit: jgi)
01:38:23  * thlorenzjoined
01:40:47  * iarnaquit (Quit: iarna)
01:40:51  * kenperkinsquit (Quit: Computer has gone to sleep.)
01:44:52  * iarnajoined
01:44:52  * thlorenzquit (Remote host closed the connection)
01:45:17  * thlorenzjoined
01:52:11  * kenperkinsjoined
01:53:17  * iarnaquit (Remote host closed the connection)
01:57:17  * avalanche123quit (Remote host closed the connection)
01:57:43  * avalanche123joined
01:58:33  * bajtosjoined
01:58:51  * avalanch_joined
01:59:11  * avalanche123quit (Remote host closed the connection)
02:11:34  * bajtosquit (Quit: bajtos)
02:12:32  * calvinfoquit (Quit: Leaving.)
02:14:56  * avalanch_quit (Remote host closed the connection)
02:15:23  * avalanche123joined
02:18:51  * avalanch_joined
02:19:16  * avalanche123quit (Remote host closed the connection)
02:27:58  * brsonquit (Quit: leaving)
02:33:31  * brsonjoined
02:43:07  * calvinfojoined
02:48:54  * dshaw_joined
02:51:14  * bradleymeckquit (Quit: bradleymeck)
02:55:23  * iarnajoined
02:56:36  * brsonquit (Quit: leaving)
02:57:36  * calvinfoquit (Ping timeout: 260 seconds)
02:58:28  * c4milojoined
03:11:06  * kazuponquit (Remote host closed the connection)
03:13:16  * Left_Turnquit (Remote host closed the connection)
03:15:08  * avalanch_quit (Remote host closed the connection)
03:15:35  * avalanche123joined
03:15:38  * bradleymeckjoined
03:20:19  * avalanche123quit (Ping timeout: 272 seconds)
03:23:20  * avalanche123joined
03:35:43  * avalanche123quit (Remote host closed the connection)
03:36:09  * avalanche123joined
03:38:29  * cjihrigquit (Quit: Leaving.)
03:41:06  * avalanche123quit (Ping timeout: 272 seconds)
03:55:19  * calvinfojoined
03:56:51  * kazuponjoined
03:58:07  * c4miloquit (Remote host closed the connection)
03:59:16  * avalanche123joined
03:59:45  * calvinfoquit (Ping timeout: 260 seconds)
04:00:22  * toothrotquit (Ping timeout: 240 seconds)
04:00:55  * iarnaquit (Remote host closed the connection)
04:06:26  * petka_quit (Quit: Connection closed for inactivity)
04:10:50  * iarnajoined
04:11:18  * iarna_joined
04:12:52  * sandr8joined
04:14:11  * iarnaquit (Client Quit)
04:14:11  * iarna_changed nick to iarna
04:14:29  * iarna_joined
04:15:25  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
04:15:28  * iarna_quit (Client Quit)
04:17:14  * sandr8quit (Ping timeout: 258 seconds)
04:17:16  * inolenquit (Read error: Connection reset by peer)
04:17:20  * inolen1joined
04:18:36  * iarnaquit (Quit: iarna)
04:21:48  * iarna_joined
04:22:06  * inolenjoined
04:22:22  * iarna_changed nick to iarna
04:22:23  * inolen1quit (Ping timeout: 272 seconds)
04:24:11  * iarnaquit (Quit: Leaving...)
04:24:33  * iarnajoined
04:25:54  * iarnaquit (Client Quit)
04:26:15  * iarnajoined
04:26:16  * avalanche123quit (Remote host closed the connection)
04:26:44  * avalanche123joined
04:27:02  * bajtosjoined
04:27:15  * bajtosquit (Client Quit)
04:29:42  * iarnaquit (Remote host closed the connection)
04:30:39  * iarnajoined
04:31:24  * avalanche123quit (Ping timeout: 260 seconds)
04:36:54  * avalanche123joined
04:44:28  * sh1mmerjoined
04:45:56  * iarnaquit (Remote host closed the connection)
04:46:13  * iarnajoined
04:48:02  * avalanche123quit (Remote host closed the connection)
04:48:29  * avalanche123joined
04:50:06  * iarnaquit (Remote host closed the connection)
04:52:54  * avalanche123quit (Ping timeout: 246 seconds)
04:56:21  * calvinfojoined
05:00:50  * calvinfoquit (Ping timeout: 244 seconds)
05:00:52  * avalanche123joined
05:12:54  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:13:25  * sh1mmerjoined
05:15:46  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
05:18:04  * avalanche123quit (Remote host closed the connection)
05:18:31  * avalanche123joined
05:20:48  * bradleymeckquit (Quit: bradleymeck)
05:23:11  * avalanche123quit (Ping timeout: 272 seconds)
05:25:26  * bradleymeckjoined
05:29:07  * inolenquit (Quit: Leaving.)
05:39:22  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
05:43:47  * sh1mmerjoined
05:46:46  * c4milojoined
05:51:42  * c4miloquit (Ping timeout: 272 seconds)
05:51:48  * iarnajoined
05:55:00  * bradleymeckquit (Quit: bradleymeck)
05:57:08  * calvinfojoined
06:01:24  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
06:01:33  * calvinfoquit (Ping timeout: 260 seconds)
06:01:35  * sandr8joined
06:06:50  * sh1mmerjoined
06:08:49  * dshaw_quit (Quit: Leaving.)
06:29:38  * inolenjoined
06:29:38  * inolenquit (Client Quit)
06:34:41  * rendarjoined
06:38:05  * avalanche123joined
06:45:26  * avalanche123quit (Remote host closed the connection)
06:45:53  * avalanche123joined
06:50:33  * avalanche123quit (Ping timeout: 260 seconds)
06:52:03  * iarnaquit (Remote host closed the connection)
06:57:54  * calvinfojoined
07:02:22  * calvinfoquit (Ping timeout: 245 seconds)
07:02:49  * wolfeidauquit (Remote host closed the connection)
07:17:37  * FROGGS_quit (Ping timeout: 260 seconds)
07:29:53  * FROGGS_joined
07:32:11  * wolfeidaujoined
07:35:04  * c4milojoined
07:35:13  <saghul>trevnorris: not too late. but ping txdv first as he started the work.
07:38:39  * janjongboomjoined
07:39:56  * c4miloquit (Ping timeout: 260 seconds)
07:43:35  * chris_99quit (Ping timeout: 244 seconds)
07:47:41  * LeftWingquit (Remote host closed the connection)
07:47:49  * LeftWingjoined
07:51:13  * wolfeidauquit (Remote host closed the connection)
07:58:47  * calvinfojoined
08:03:56  * calvinfoquit (Ping timeout: 272 seconds)
08:24:59  * AlexisMochajoined
08:49:02  * avalanche123joined
08:55:55  * avalanche123quit (Ping timeout: 258 seconds)
08:59:34  * calvinfojoined
09:01:24  * calvinfo1joined
09:01:24  * calvinfoquit (Read error: Connection reset by peer)
09:05:42  * calvinfo1quit (Ping timeout: 245 seconds)
09:23:17  * c4milojoined
09:23:56  * chris_99joined
09:24:49  <chris_99>creationix sorry to bother you just wondering if you could give me a shout when you're about - i'd just like to ask you about threads in luv
09:28:00  * c4miloquit (Ping timeout: 246 seconds)
09:28:06  * petka_joined
09:53:00  * avalanche123joined
09:57:57  * AlexisMochaquit (Ping timeout: 272 seconds)
10:02:42  * calvinfojoined
10:06:57  * calvinfoquit (Ping timeout: 245 seconds)
10:13:53  * avalanche123quit (Ping timeout: 272 seconds)
10:15:05  * AlexisMochajoined
10:25:58  * seishunjoined
10:35:15  * Left_Turnjoined
10:51:18  * AlexisMochaquit (Ping timeout: 258 seconds)
10:51:25  * AlexisMochajoined
10:52:28  * kazuponquit (Remote host closed the connection)
10:52:56  * kazuponjoined
10:53:30  * abraxasquit (Remote host closed the connection)
10:56:20  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:57:20  * kazuponquit (Ping timeout: 260 seconds)
11:03:29  * calvinfojoined
11:07:47  * calvinfoquit (Ping timeout: 245 seconds)
11:08:04  * daviddiasjoined
11:11:39  * c4milojoined
11:16:29  * c4miloquit (Ping timeout: 272 seconds)
11:24:35  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
11:25:00  * daviddiasjoined
11:29:56  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
11:31:30  * toothrotjoined
11:52:13  * janjongboomjoined
12:01:44  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:04:17  * calvinfojoined
12:09:09  * calvinfoquit (Ping timeout: 272 seconds)
12:50:20  * inolenjoined
12:51:06  * cjihrigjoined
12:54:43  * abraxasjoined
12:57:42  * toothrotquit (Ping timeout: 245 seconds)
12:59:35  * abraxasquit (Ping timeout: 272 seconds)
12:59:54  * c4milojoined
13:04:26  * c4miloquit (Ping timeout: 244 seconds)
13:05:07  * calvinfojoined
13:09:33  * calvinfoquit (Ping timeout: 246 seconds)
13:17:19  * cjihrigquit (Quit: Leaving.)
13:46:41  * a_lejoined
13:51:31  * cjihrigjoined
13:52:02  * c4milojoined
13:56:32  * c4miloquit (Ping timeout: 245 seconds)
13:56:48  * brsonjoined
13:57:01  * c4milojoined
14:00:29  * brsonquit (Client Quit)
14:01:37  * WalrusPony1joined
14:03:46  * AlexisMocha_joined
14:05:36  * Ralith_joined
14:05:51  * calvinfojoined
14:09:28  * tellnes_joined
14:10:03  * calvinfoquit (Ping timeout: 244 seconds)
14:10:15  * AlexisMochaquit (*.net *.split)
14:10:15  * FROGGS_quit (*.net *.split)
14:10:15  * Ralithquit (*.net *.split)
14:10:15  * ircretaryquit (*.net *.split)
14:10:15  * brett19quit (*.net *.split)
14:10:15  * jas-quit (*.net *.split)
14:10:15  * MI6quit (*.net *.split)
14:10:16  * tellnesquit (*.net *.split)
14:10:16  * WalrusPonyquit (*.net *.split)
14:10:16  * russfrankquit (*.net *.split)
14:10:16  * tellnes_changed nick to tellnes
14:12:48  * jas-joined
14:16:01  * FROGGS_joined
14:17:27  * russfrankjoined
14:20:16  * Damn3dquit (Ping timeout: 272 seconds)
14:20:43  * brett19joined
14:24:58  * c4miloquit (Remote host closed the connection)
14:26:28  * kenperkinsjoined
14:34:57  * dshaw_joined
14:35:54  * chris_99quit (Remote host closed the connection)
14:38:28  * kenperkinsquit (Remote host closed the connection)
14:57:44  * c4milojoined
15:00:56  * avalanche123joined
15:02:01  * c4milo_joined
15:04:25  * txdv_joined
15:05:47  * tellnesquit (Ping timeout: 260 seconds)
15:05:47  * txdvquit (Ping timeout: 260 seconds)
15:05:47  * c4miloquit (Ping timeout: 260 seconds)
15:06:22  * kenperkinsquit (Remote host closed the connection)
15:06:43  * calvinfojoined
15:07:28  * tellnesjoined
15:08:27  * FROGGS[mobile]joined
15:11:34  * calvinfoquit (Ping timeout: 272 seconds)
15:13:10  * FROGGS_quit (Quit: Verlassend)
15:21:53  * avalanche123quit (Remote host closed the connection)
15:22:00  * bradleymeckjoined
15:22:20  * avalanche123joined
15:23:04  * dshaw_joined
15:26:37  * dshaw_quit (Read error: Connection reset by peer)
15:26:40  * dshaw_1joined
15:27:04  * avalanche123quit (Ping timeout: 260 seconds)
15:29:18  * nathan7_joined
15:29:40  * nathan7_quit (Changing host)
15:29:41  * nathan7_joined
15:29:45  * nathan7quit (Disconnected by services)
15:29:47  * nathan7_changed nick to nahtan7
15:29:49  * nahtan7changed nick to nathan7
15:30:25  * brsonjoined
15:31:13  * brucem_joined
15:31:27  * saapasjoined
15:31:27  * isaacs_joined
15:31:35  * cjbquit (Ping timeout: 250 seconds)
15:31:36  * saapazquit (Ping timeout: 250 seconds)
15:31:36  * kkaefer_quit (Ping timeout: 250 seconds)
15:31:37  * isaacsquit (Ping timeout: 250 seconds)
15:31:37  * lennartclquit (Ping timeout: 250 seconds)
15:31:37  * brucemquit (Ping timeout: 252 seconds)
15:31:37  * LOUDBOTquit (Ping timeout: 252 seconds)
15:31:53  * isaacs_changed nick to Guest99431
15:32:18  * chris_99joined
15:33:08  * kkaeferjoined
15:33:46  * LOUDBOTjoined
15:33:58  * lennartcljoined
15:37:48  * brucem_quit (Changing host)
15:37:48  * brucem_joined
15:37:57  * brucem_changed nick to brucem
15:44:56  * jas-quit (Ping timeout: 258 seconds)
15:46:01  * dainisquit (Ping timeout: 250 seconds)
15:46:02  * guybrushquit (Ping timeout: 250 seconds)
15:46:03  * guybrushjoined
15:47:20  * dainisjoined
15:48:44  * FROGGS[mobile]quit (Ping timeout: 244 seconds)
15:53:43  * jas-joined
15:53:46  * kriskowaljoined
15:57:49  * jgijoined
15:57:49  * FROGGS[mobile]joined
16:01:06  * FROGGSjoined
16:07:32  * calvinfojoined
16:09:51  * dshaw_1quit (Quit: Leaving.)
16:11:59  * calvinfoquit (Ping timeout: 244 seconds)
16:14:25  * iarnajoined
16:17:55  * iarnaquit (Remote host closed the connection)
16:20:10  * iarnajoined
16:30:05  * iarnaquit (Remote host closed the connection)
16:31:10  <trevnorris>saghul: will do
16:36:04  * jreyno40_joined
16:44:22  * inolen1joined
16:45:03  * inolenquit (Ping timeout: 244 seconds)
16:48:53  * Damn3djoined
16:49:48  * kriskowalquit (Quit: kriskowal)
16:58:34  <trevnorris>curse this icu build. why does the build insist on using CC_host and CXX_host?
17:00:30  * calvinfojoined
17:01:39  * a_lequit (Remote host closed the connection)
17:02:25  * a_lejoined
17:05:58  * janjongboomjoined
17:08:44  * benglquit (Ping timeout: 272 seconds)
17:09:40  * janjongboomquit (Client Quit)
17:11:49  * sblomjoined
17:13:54  * dshaw_joined
17:15:02  * avalanche123joined
17:20:42  * FROGGS[mobile]quit (Remote host closed the connection)
17:20:42  * bengljoined
17:22:58  <FROGGS>ohh icu *shudder*
17:27:06  <trevnorris>indexzero: ping
17:27:13  <trevnorris>indexzero: sorry, not you
17:27:15  <trevnorris>indutny: ping
17:27:20  <indutny>pong man
17:27:22  <indutny>hey
17:27:33  <trevnorris>sup. i'm curious about the TODO here: https://github.com/joyent/node/blob/master/lib/dns.js#L31-L52
17:27:45  <trevnorris>why is it necessary ENOTFOUND is kept around?
17:27:56  <indutny>compatibility
17:27:59  <indutny>anyway
17:28:01  <indutny>ask ben :D
17:28:06  <trevnorris>hehe, of course.
17:28:10  * jreyno40_quit (Quit: jreyno40_)
17:28:27  <trevnorris>would be a lot easier if the dude was on some sort of chat...
17:29:07  <indutny>:)
17:29:08  <indutny>yes
17:29:10  <indutny>exactly
17:29:23  <tjfontaine>well
17:29:54  <tjfontaine>I think it would make more sense to attach this real error on the error object, but still keep ENOTFOUND
17:30:08  <indutny>time to upgrade libuv
17:30:09  <indutny>in node
17:30:36  <indutny>tjfontaine: are there any openssl people at joyent? :)
17:30:39  <indutny>by any chance
17:30:52  <trevnorris>tjfontaine: you mean make err.code the actual error, but keep ENOTFOUND in the error message?
17:30:57  <tjfontaine>indutny: somewhat, what's up?
17:31:21  <tjfontaine>trevnorris: well I'm not sure if err.code depends on which one most people are looking at, but one of the properties having the real underlying error
17:31:23  <indutny>tjfontaine: https://github.com/indutny/openssl/compare/feature/async-key-ex-2
17:31:43  <tjfontaine>trevnorris: it's mostly only for lookup and not the c-ares ones anyway
17:32:34  <trevnorris>tjfontaine: okay. not sure what type of solution you're proposing, but i'll worry about it later.
17:33:25  <tjfontaine>trevnorris: like change errno to it
17:33:44  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:34:08  * dshaw_quit (Quit: Leaving.)
17:34:33  <trevnorris>what the. what's supposed to be the difference between err.code and err.errno. they seem redundant.
17:34:41  <trevnorris>well, at least I can't see a reason to have them both.
17:35:28  <tjfontaine>that's hysterical reasons
17:35:49  <tjfontaine>but I think it's fairly reasonable to make .errno be the errno, and code be the human readable thing -- which is similar to what we've discussed before
17:36:44  <trevnorris>then what about err.message. Thought that would be the "human readable" part.
17:36:48  <indutny>saghul: you around?
17:37:40  <tjfontaine>trevnorris: well a message is a sentence, code is a string that's reasonable to understand but programmable, and in this case errno represents the actual underlying system error
17:37:44  <tjfontaine>which is also programmatic
17:37:45  * AlexisMocha_quit (Ping timeout: 244 seconds)
17:38:22  <trevnorris>hehe, that's a lot of options for the user to choose. :P
17:38:43  <tjfontaine>no one should be using message though
17:38:52  <tjfontaine>.code is probably the most predominate
17:39:04  <trevnorris>guess I see err.code as sort of arbitrary. meaning, I don't think we have a node specific list of what "code"s node will return.
17:39:06  <tjfontaine>and .errno is simply more specific in this case, most of the time they're the same
17:39:49  <tjfontaine>we should be very specific about what codes we return though
17:39:57  <trevnorris>mother of......
17:40:18  <trevnorris>anyone have any ideas how to override {CXX,CC}_host for the icu build in https://github.com/joyent/node/pull/7719 ?
17:40:30  <trevnorris>other than setting my environment variables
17:40:51  <trevnorris>(which really shouldn't be necessary)
17:42:32  * iarnajoined
17:44:02  * iarnaquit (Remote host closed the connection)
17:44:14  * AlexisMochajoined
17:44:26  * jreyno40_joined
17:45:48  <indutny>tjfontaine: https://github.com/joyent/node/pull/8409
17:45:58  <indutny>doesn't look like there are any important API changes yet
17:46:02  * sh1mmerjoined
17:46:56  * iarnajoined
17:46:58  <saghul>indutny: pong
17:47:06  <indutny>pang :0
17:47:08  <indutny>figured it out :)
17:47:19  <saghul>it's the magic of calling saghul
17:47:25  <saghul>:-P
17:48:36  * AlexisMochaquit (Ping timeout: 244 seconds)
17:48:42  <trevnorris>saghul: i'm going to hit up txdv about https://github.com/joyent/libuv/pull/1439, but just want to double check that it wouldn't be too late for an ABI change?
17:49:09  <thlorenz>tjfontaine: when you have a chance could you give me a quick note on https://github.com/joyent/node/pull/8386 ? I just wanna make sure I did this as you intended ;)
17:49:10  <saghul>trevnorris: nah, go haead
17:49:21  <tjfontaine>thlorenz: ya, just a moment
17:49:24  <thlorenz>cool
17:49:26  <saghul>trevnorris: I pinged him on your behalf :-) check the issue notes
17:50:46  <saghul>tjfontaine: please comment when you can: https://github.com/joyent/libuv/issues/1431
17:51:23  <saghul>indutny: you too ^
17:51:24  * iarnaquit (Remote host closed the connection)
17:52:14  <tjfontaine>yup
17:52:40  <trevnorris>saghul: noticed. thanks :) I'm going to get started. don't want to wait until he responds just in case it's too late.
17:53:00  <indutny>saghul: oh!
17:54:04  <saghul>trevnorris: I pinged twice, last time a week ago, so I guess it's ok to go ahead
17:54:12  * iarnajoined
17:54:12  <trevnorris>coolio
17:55:31  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:56:08  * sh1mmerjoined
17:56:35  * AlexisMochajoined
17:56:48  * iarnaquit (Remote host closed the connection)
17:58:57  * iarnajoined
17:59:13  * avalanche123quit (Remote host closed the connection)
18:01:15  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:01:44  * dshaw_joined
18:02:45  * sh1mmerjoined
18:03:29  * avalanche123joined
18:03:53  * Ralith_quit (Ping timeout: 240 seconds)
18:04:11  * iarnaquit (Remote host closed the connection)
18:04:31  * iarnajoined
18:05:00  * c4milo_quit (Remote host closed the connection)
18:05:54  * sh1mmerquit (Client Quit)
18:13:29  * calvinfoquit (Quit: Leaving.)
18:15:20  * c4milojoined
18:15:38  <tjfontaine>indutny: re openssl, can you do a write up about the implementation they can read first?
18:16:40  <indutny>tjfontaine: does this work https://github.com/indutny/openssl/compare/feature/async-key-ex-2#diff-4b59eddb1c722b1dc3d17b5f64149e12R688 ?
18:16:46  <indutny>thanks for looking, btw
18:16:47  * sh1mmerjoined
18:19:12  <trevnorris>saghul: getting the following error during build: src\win\tcp.c(1129): warning C4013: 'uv__stream_flush_write_queue' undefined; assuming extern returning int
18:19:24  <trevnorris>assume that could be the cause of the segfault
18:24:54  * c4miloquit (Remote host closed the connection)
18:24:54  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
18:25:17  * sh1mmerjoined
18:28:08  <saghul>trevnorris: humm, let me check
18:28:18  <tjfontaine>indutny: so they're kinda looking for a design doc that has a bit more to it than that, but they're also worried since you're touching the crypto sections that there may be better people to approach about this
18:28:29  * a_lequit (Remote host closed the connection)
18:28:52  <indutny>tjfontaine: em, I'm not sure what kind of design doc they actually expect
18:29:12  <indutny>tjfontaine: it is just a Keyless clone that I wrote weeks ago
18:29:22  <indutny>you heard about Cloudflare's Keyless ?
18:29:31  <indutny>sorry, it probably sounded rood
18:29:33  <indutny>have you heard... ?
18:29:34  <indutny>:)
18:29:53  <indutny>tjfontaine: unfortunately, I have no solution for their worries
18:30:06  * sh1mmerquit (Client Quit)
18:30:10  <saghul>trevnorris: it's defined on stream.c, maybe declare in uv-win.h
18:30:12  * rendarquit (Ping timeout: 245 seconds)
18:30:37  <tjfontaine>sure they're looking for a document that describes "This is the problem, this is my proposed solution, and this is why its useful" -- this will be important when you go to upstream to openssl as well
18:32:09  <trevnorris>saghul: you mean include/uv-win.h (just want to double check)?
18:33:12  <saghul>trevnorris: yep
18:33:25  * sh1mmerjoined
18:33:47  * a_lejoined
18:34:49  <saghul>trevnorris: sorry, it's really src/win/internal.h
18:34:59  <trevnorris>ok
18:37:00  * rendarjoined
18:37:50  * c4milojoined
18:38:13  * a_lequit (Ping timeout: 258 seconds)
18:38:36  <tjfontaine>for repost I did it in the wrong window
18:39:02  <tjfontaine>indutny: I'm having jgi look at that PR, since jenkins is showing the tests failing on smartos that are supposed to be fixed by the libuv upgrade
18:39:12  <indutny>tjfontaine: thanks
18:39:16  <indutny>tjfontaine: https://gist.github.com/indutny/9eea33da117a788a22ee
18:41:09  <indutny>does this thing work as a design document?
18:41:20  * calvinfojoined
18:41:24  <indutny>I think the usefullness is a bit obvious, but I may be wrong
18:42:13  * c4miloquit (Ping timeout: 260 seconds)
18:42:47  * dshaw_quit (Quit: Leaving.)
18:44:45  <trevnorris>saghul: thanks. that took care of the build issues. now working on the failed assertion.
18:45:16  <saghul>trevnorris: the patch didn't really do the actual writes
18:45:30  <saghul>it just marks them as cancelled
18:46:58  <saghul>trevnorris: this needs to be done for all queued requests: https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L841-L873
18:47:38  <indutny>tjfontaine: added rationale, just in case
18:49:06  <trevnorris>saghul: ah, I see. the UV_ECANCELED was just a stub. more or less. wish he had been more specific about the segfault he was getting.
18:49:27  <trevnorris>but I assume the failed assertion wasn't what he was referring to, so i'll move on from there.
18:50:50  <saghul>what needs to happen is: 1, queue write requests when not connected. 2, do the actual writes afterwards
18:51:09  <saghul>after we are connected though, we can just write, windows takes care of the queuing in the kernel
18:52:03  <trevnorris>coolio. thanks.
18:52:10  <trevnorris>we'll see if I can actually pull this off. :P
18:52:37  <saghul>feel free to ask anything if you need to :-)
18:53:34  <trevnorris>thanks, definitely expect that. :)
18:57:47  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:00:53  * a_lejoined
19:05:53  * a_lequit (Ping timeout: 240 seconds)
19:08:57  * avalanche123quit (Remote host closed the connection)
19:10:42  * avalanche123joined
19:10:56  * avalanch_joined
19:10:59  * avalanche123quit (Remote host closed the connection)
19:14:37  * sh1mmerjoined
19:20:47  * iarnaquit (Remote host closed the connection)
19:21:31  <trevnorris>saghul: to double check, it looks like data should be appended to the write_queue in the case that WSASend() failed. but I assume that should only be the case in a specific case.
19:21:42  <trevnorris>like that the connection is still being established.
19:22:03  <trevnorris>ah, duh.
19:22:47  * AlexisMochaquit (Ping timeout: 245 seconds)
19:22:52  <trevnorris>i'm so used to looking at man pages that I forgot that I can google the stupid function and check all return errors. :P
19:26:03  * jreyno40_quit (Quit: jreyno40_)
19:28:55  * Ralithjoined
19:29:15  <saghul>trevnorris: not really, we shouldn't atteempt to WSASend if we are not connected yet
19:29:47  * jreyno40joined
19:30:30  <trevnorris>saghul: then there'd never be a need to queue data after that call. I'm just thinking about https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L841-L873
19:31:00  <saghul>after we are connected yes, we'd never queue data, because the windows kernel does
19:31:27  * piscisaureusjoined
19:31:37  <trevnorris>yeah, but are you saying that uv_tcp-write() will never be called before the connection is established?
19:31:45  <trevnorris>*uv_tcp_write()
19:32:16  <saghul>it will, if you call uv_write before we are connected, which is supported on Unix and what we are trying to fix
19:33:13  <saghul>hum, wait a secx
19:34:05  <saghul>trevnorris: ah, you're right, because UV_HANDLE_WRITABLE won't be set
19:35:13  <saghul>trevnorris: https://github.com/joyent/libuv/blob/master/src/win/stream.c#L129-L131 this will need to be adjusted
19:36:04  <trevnorris>saghul: yeah. right there is when the data should be placed in the write_queue, correct?
19:36:28  <trevnorris>erm.
19:36:52  <trevnorris>well, first need to determine if the connection is still being established.
19:40:24  <saghul>trevnorris: yes. on Unix we save the connect req in the handle, so we are connecting if not NULL
19:40:29  <saghul>not so on Windows...
19:42:24  <trevnorris>just want to check, is it possible to do a uv_write() on an uv_tcp_t before running uv_tcp_init() on it?
19:43:20  <saghul>nope
19:44:19  <trevnorris>so the only time "if (!(handle->flags & UV_HANDLE_WRITABLE))" in uv_write() will fail on windows is that case, because looks like uv_connect_init() is sync.
19:44:33  <trevnorris>well, also if the handle has been closed
19:46:16  <saghul>yeah
19:46:32  <saghul>not sure if we check for that on unix either
19:46:36  <saghul>we should
19:47:49  <piscisaureus>The difference between unix and windows is that on windows uv_write(tcp_handle, ...) will fail if the tcp handle isn't connected
19:48:00  <piscisaureus>on unix you can write if a uv_connect is still in flight
19:48:14  <piscisaureus>(and maybe even between init and connect - I don't recall)
19:48:46  <trevnorris>piscisaureus: so uv_connect_init() doesn't mean the tcp handle is connected?
19:49:32  <piscisaureus>trevnorris: nope - uv_connect just starts the connect asynchronous operation
19:49:53  <piscisaureus>trevnorris: on windows you have to wait until it completes before you can write to a socket
19:50:05  * jgiquit (Quit: jgi)
19:50:43  <trevnorris>piscisaureus: but the handle is set to UV_HANDLE_WRITABLE right after uv_connect_init() in functions like uv_process_tcp_connect_req()
19:51:37  <piscisaureus>trevnorris: yeah, what can I say
19:51:44  <piscisaureus>trevnorris: that may be wrong
19:51:53  <trevnorris>so if I follow the logic correctly, WSASend() can still be reached from, but it might fail because the connection hasn't been made.
19:52:08  <piscisaureus>trevnorris: so uv_process_tcp_connect_req happens when uv_connect returns
19:52:19  <piscisaureus>I mean, when it completes
19:52:24  <piscisaureus>so that makes sense then right
19:52:40  * cjihrigquit (Quit: Leaving.)
19:53:25  <piscisaureus>the uv_process_blabla_req class of functions are called when a packet is received from the completion port. It does some bookkeeping and then calls the user callback (like here https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L1119)
19:53:28  <trevnorris>but why then run uv_connect_init() if the handle if uv_connect() has already returned?
19:53:44  <piscisaureus>uv_connect_init?
19:53:49  <piscisaureus>do you mean uv_connection_init?
19:53:51  <trevnorris>sorry
19:53:55  <trevnorris>uv_connection_init()
19:53:57  <trevnorris>yeah
19:54:23  <piscisaureus>hmm
19:54:32  <saghul>isn't the writable flag set after we are connected?
19:54:48  <piscisaureus>uv_connection_init does some initialization that's shared between different handle types
19:55:20  <piscisaureus>but you could argue it could be called in uv_connect() instead
19:55:26  <piscisaureus>does this cause problems?
19:56:09  <trevnorris>piscisaureus: honestly, i'm just getting a grasp on the logic flow. today is the first day I've really looked at the src/win/ portion of code. :P
19:56:16  <piscisaureus>aah
19:56:17  <piscisaureus>:)
19:56:18  <piscisaureus>https://github.com/joyent/libuv/blob/master/src/win/stream-inl.h#L42-L53
19:56:19  <trevnorris>i'm trying to finish up https://github.com/joyent/libuv/pull/1439
19:56:21  * iarnajoined
19:56:44  <piscisaureus>trevnorris: I think that it would be possible to move the uv_connection_init code to the uv_connect() function call
19:56:57  <piscisaureus>but I don't think that by itself is very useful
19:57:10  <piscisaureus>however what would be useful is if windows would support write-before-connect like unix does
19:57:32  <piscisaureus>haha which is exactly what txdv is up to :)
19:57:38  <trevnorris>heh, yup. :)
19:57:51  <trevnorris>he hasn't responded in a while, and I'd like it to get in for 1.0 release
19:58:01  <trevnorris>so decided to pick it up and see if I couldn't finish it
19:58:37  * sh1mmer_joined
19:58:57  <piscisaureus>Nice!
19:59:11  <piscisaureus>Pipes will be another challenge, but if you could tcp first I'd be very happy
20:00:00  <trevnorris>piscisaureus: so the uv_connect() callback is only run once the connection has been successfully established?
20:00:52  <trevnorris>from what I see, basically uv_tcp_write() should buffer the write if the connection has been initialized but not completed.
20:01:01  <saghul>yep
20:01:18  <trevnorris>and I'm trying to determine if there's a flag that's set, or if I need to check the resulting error from WSASend()
20:01:23  * sh1mmerquit (Ping timeout: 244 seconds)
20:02:09  <trevnorris>the only error that might apply is WSAENOTCONN, but then I'd have to also check if uv_connect() has been run on the handle.
20:02:53  <saghul>if UV_STREAM_WRITABLE is set we are connectd, not otherwise
20:03:05  <saghul>maybe explicitly check if the handle is closed as well
20:04:28  * sh1mmer_changed nick to sh1mmer
20:04:32  * jreyno40quit (Quit: jreyno40)
20:06:20  <trevnorris>saghul: if UV_STREAM_WRITABLE is set then WSASend can run, but if not then how do I check if we're in the act of trying to connect?
20:08:53  <saghul>ah, that. Unix stores the connect req in stream->connect_req while it connects, maybe we can do the same here
20:15:06  * jreyno40_joined
20:15:56  <trevnorris>saghul: honestly I don't care if it's just a flag. just need a way to determine that we're in the middle of making the tcp connection.
20:19:22  * AlexisMochajoined
20:23:28  * cjihrigjoined
20:25:57  * c4milojoined
20:26:57  * cjihrig1joined
20:27:07  * cjihrigquit (Read error: Connection reset by peer)
20:30:53  * c4miloquit (Ping timeout: 260 seconds)
20:37:03  * MI6joined
20:39:33  <tjfontaine>indutny: oh, you didn't update the node_file readdir implementation yet
20:42:45  * iarnaquit (Remote host closed the connection)
20:42:58  * jgijoined
20:43:27  * iarnajoined
20:45:37  <trevnorris>piscisaureus: what is SOCKET_ERROR? it's like this magical thing that is all error codes. e.g. in uv_get_extension_function() there are a dozen error codes that can be returned, but instead of checking if (result > 0) you check if (result = SOCKET_ERROR).
20:45:56  <trevnorris>*if (result == SOCKET_ERROR)
20:49:50  * Guest99431changed nick to isaacs
20:50:22  <trevnorris>saghul / piscisaureus: so in uv_tcp_try_connect() it basically does a WSAIoctl(). and only in the case of UV_SUCCEEDED_WITHOUT_IOCP does it use uv_insert_pending_req().
20:50:22  <trevnorris>Does that mean in the case of UV_SUCCEEDED_WITH_IOCP the connection is made synchronously?
20:50:26  * isaacschanged nick to Guest36988
20:50:54  * thlorenzquit (Remote host closed the connection)
20:50:58  <saghul>trevnorris: yeah, IIRC sometimes it may succeed immediately
20:51:17  <trevnorris>okie dokie. this makes things interesting.
20:51:30  * thlorenzjoined
20:52:03  * c4milojoined
20:53:21  <trevnorris>what the...
20:53:51  <trevnorris>saghul: mind giving me a sanity check. I can see where uv_process_tcp_connect_req() is declared (win/internal.h) and defined (win/tcp.c), but I can't see it being used anywhere...
20:53:52  <indutny>tjfontaine: yep, will do it later
20:55:10  * a_lejoined
20:56:04  * thlorenzquit (Ping timeout: 260 seconds)
20:56:20  <saghul>trevnorris: there is some macro trickery, let me find it
20:56:41  <trevnorris>heh, of course. thanks :)
20:56:58  <saghul>trevnorris: check req-inl.h
20:57:06  <trevnorris>saghul: thanks. will do.
21:03:30  * yunongjoined
21:04:07  * a_lequit (Remote host closed the connection)
21:04:45  * a_lejoined
21:06:28  * bradleymeckquit (Quit: bradleymeck)
21:11:39  * prettyrobotsjoined
21:12:47  * jreyno40_quit (Quit: jreyno40_)
21:17:27  <trevnorris>saghul: dumb question, but sanity check. can you make multiple uv_tcp_connect's with the same uv_tcp_t simultaneously?
21:17:32  * cjihrig1quit (Quit: Leaving.)
21:18:39  <saghul>trevnorris: nope
21:19:39  <trevnorris>saghul: ok, so in uv_tcp_try_connect there's uv_tcp_t handle. and in there it has handle->reqs_pending++. in what case would there ever be more than 1 req_pending?
21:21:40  <trevnorris>guess I'm getting at req_queue will == 1 while the connection is being made, then == 0 when the connection has been made. after that there can be many read/write reqs pending.
21:22:24  <trevnorris>sorry. it'd be easy enough if I just added another field to the struct, but I'd like to avoid that if possible.
21:26:06  <trevnorris>saghul: nm. answered my own question. thanks. :)
21:27:50  * kenperkinsjoined
21:28:28  * lanceballchanged nick to lance|afk
21:29:41  * cjihrigjoined
21:30:28  * toothrotjoined
21:30:46  <trevnorris>saghul / piscisaureus: API question: sometimes connections will be made synchronously. in this case should we still buffer write reqs until the connect cb has run?
21:35:35  * yunongquit
21:36:04  <saghul>trevnorris: i'd say so
21:38:32  <trevnorris>roger that
21:39:51  * cjihrigquit (Quit: Leaving.)
21:41:23  * jreyno40joined
21:54:21  * sblomquit (Read error: Connection reset by peer)
21:58:48  * iarnaquit (Remote host closed the connection)
21:59:05  * brsonquit (Quit: leaving)
22:04:58  * iarnajoined
22:05:27  * sblomjoined
22:06:30  <piscisaureus>trevnorris: hey, sorry, I was out for lunch
22:06:43  <piscisaureus>trevnorris: are there any questions you havent figured out?
22:07:05  <piscisaureus>trevnorris: the connect callback is always made - that's a libuv invariant
22:07:13  <piscisaureus>but it may be with an error code if it failed
22:07:30  <trevnorris>piscisaureus: not so far. had to take a small break to respond to some emails, but mostly just making sure I understand what's going on in the code.
22:07:41  <piscisaureus>trevnorris: SOCKET_ERROR is a windows constant that some APIs return when something failed. It's value is (void*)-1
22:08:01  <trevnorris>ah, cool
22:08:03  * a_lequit (Remote host closed the connection)
22:08:16  * sblomquit (Read error: Connection reset by peer)
22:08:31  <trevnorris>piscisaureus: oh one thing, if WSAIoctl() returns UV_SUCCEEDED_WITH_IOCP, does that mean the connection was made synchronously?
22:08:44  <piscisaureus>trevnorris: when UV_SUCCEEDED_WITHOUT_IOCP then there will be no message to the completion port, so we insert the completion directly into the completed request queue.
22:09:02  * a_lejoined
22:09:08  <piscisaureus>trevnorris: yes, although I don't think connect ever completes synchronously (maybe when connecting to localhost?)
22:09:12  * jreyno40__joined
22:09:26  <piscisaureus>trevnorris: but that's basically a performance trick. You can't rely on it.
22:10:09  <piscisaureus>trevnorris: what you should do is start flushing the write queue in uv_tcp_process_connect_req
22:10:11  * cjihrigjoined
22:10:11  * jreyno40quit (Ping timeout: 258 seconds)
22:10:12  * jreyno40__changed nick to jreyno40
22:10:19  <piscisaureus>trevnorris: (if connect succeeded)
22:11:02  <trevnorris>yeah, so I'll have to check REQ_SUCCESS(req).
22:12:20  <piscisaureus>trevnorris: just insert the logic here -> https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L1112
22:12:35  <piscisaureus>trevnorris: or reswizzle the logic a little bit, otherwise it gets too nested
22:12:59  <trevnorris>piscisaureus: figured I should wait until req->cb() gets called. should I?
22:13:40  <trevnorris>basically just put another if (REQ_SUCCESS(req)) right after req->cb()
22:13:58  <piscisaureus>trevnorris: it doesn't matter I think. But you have to consider the case that the user writes more in the callback, and you want to keep the writes ordered
22:14:28  <piscisaureus>trevnorris: REQ_SUCCESS() checks the status of an OVERLAPPED struct. I wouldn't use that macro. Just check the value of `err`
22:14:47  <piscisaureus>trevnorris: what if REQ_SUCCESS is true but the subsequent setsockopt call failed?
22:14:54  * hueniversejoined
22:15:26  <piscisaureus>trevnorris: in case the connect fails, you can't flush the write queue so you have to make the write callback and tell the user they failed (because the connect they were depending on failed)
22:16:01  <trevnorris>piscisaureus: good points. thanks.
22:16:49  * cjihrigquit (Ping timeout: 260 seconds)
22:17:05  * avalanch_quit (Remote host closed the connection)
22:17:30  <piscisaureus>trevnorris: I will forgive you if you make a small mess of it. In libuv2 we will need a better internal structure to avoid it.
22:17:37  <piscisaureus>I have really itchy fingers :)
22:17:43  <trevnorris>heh
22:18:05  <trevnorris>hm. seems I'll have to change that PR's uv__stream_flush_write_queue(), since it calls the cb synchronously.
22:18:09  * avalanche123joined
22:18:42  * toothrotquit (Ping timeout: 246 seconds)
22:18:58  <trevnorris>piscisaureus: on the unix side all write req callbacks are run in the uv__run_pending() phase. but that doesn't exist on the win side.
22:19:11  <trevnorris>so where should the write req callbacks be queued to run?
22:19:28  <trevnorris>eh, guess that's something I can hunt down myself.
22:20:13  <trevnorris>if I just queue the req then I can do a uv_tcp_write() on the req and the cb will be queued automatically.
22:21:24  <piscisaureus>trevnorris: uv_insert_pending_req
22:21:33  <trevnorris>ah, thanks.
22:21:35  <piscisaureus>trevnorris: windows has something similar but a different name
22:21:53  <trevnorris>yeah, think it's just uv_process_reqs()
22:21:58  <piscisaureus>trevnorris: yes that's the one
22:22:19  <trevnorris>coolio. think I may have everything I need to complete this. well, let's see how it goes. :)
22:22:32  <piscisaureus>trevnorris: in case you are not event going to attempt a write (because connect failed) you can use SET_REQ_ERROR or some other macros to store an error in the OVERLAPPED
22:22:39  * rosskjoined
22:22:59  <trevnorris>okay
22:23:58  <trevnorris>so it'll just queue the callbacks to be called with the connection error?
22:24:09  <trevnorris>how's that work on the unix side?
22:26:08  * a_lequit (Remote host closed the connection)
22:27:33  <piscisaureus>trevnorris: yes, I think. Not sure about unix, it may be just UV_ECANCELED
22:27:36  <piscisaureus>let me look it up
22:29:25  <piscisaureus>trevnorris: oh, actually, unix just keeps the queue when connect fails
22:29:48  <piscisaureus>trevnorris: when the closes the handle they will receive ECANCELED
22:30:09  <trevnorris>ah, ok. so even on a failed connect the user should still run uv_close() on the uv_tcp_t.
22:30:14  <trevnorris>got it
22:30:15  <piscisaureus>trevnorris: yep
22:30:31  <piscisaureus>trevnorris: trevnorris: you could do the same (so in uv_tcp_endgame, check if there are queued writes and cancel them(
22:31:02  <trevnorris>will do
22:31:37  <piscisaureus>trevnorris: I think it's not super complicated and you will be able to figure it out
22:31:56  <trevnorris>sure
22:32:09  <piscisaureus>trevnorris: the only thing is that there are a fair amount of things to consider - like, pipes, and uv_cancel etc
22:32:45  <piscisaureus>because all the existing code assumes that writes are queued by the OS
22:32:58  <trevnorris>ah... ok. i'll keep that in mind.
22:33:43  <piscisaureus>trevnorris: so you may end up needing adding a request flag (UV_WRITE_QUEUED or something) so you can differentiate a userland-queued write from a kernel-queued write
22:34:13  * a_lejoined
22:44:25  * c4milo_joined
22:44:37  * c4miloquit (Read error: Connection reset by peer)
22:44:41  * cjihrigjoined
22:46:40  * seishunquit (Ping timeout: 260 seconds)
22:48:47  * cjihrigquit (Ping timeout: 244 seconds)
22:51:38  * c4milo_quit (Read error: Connection reset by peer)
22:53:36  * a_le_joined
22:53:40  * a_lequit (Ping timeout: 260 seconds)
22:54:05  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
22:55:07  * thlorenzjoined
22:57:48  * sh1mmerjoined
22:59:08  * c4milojoined
22:59:28  * c4miloquit (Remote host closed the connection)
23:01:10  * jreyno40quit (Quit: jreyno40)
23:05:14  * c4milojoined
23:07:10  * jreyno40_joined
23:08:27  * c4miloquit (Read error: Connection reset by peer)
23:09:01  * c4milojoined
23:10:05  * cjihrigjoined
23:10:24  * c4milo_joined
23:11:38  * chris_99quit (Ping timeout: 272 seconds)
23:14:12  * c4miloquit (Ping timeout: 258 seconds)
23:15:18  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:18:30  * sh1mmerjoined
23:20:28  * sh1mmerquit (Client Quit)
23:20:39  * c4milo_quit (Ping timeout: 246 seconds)
23:22:36  * sh1mmerjoined
23:23:38  * rendarquit
23:27:17  * chris_99joined
23:28:52  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:34:09  * kriskowaljoined
23:37:09  * jgiquit (Quit: jgi)
23:45:57  * chris_99quit (Quit: Leaving)
23:47:39  * sh1mmerjoined
23:56:24  <MI6>joyent/node: Andrew Teich v0.12 * d66adf0 : doc: corrected typo in vm docs - http://git.io/ZWa4Vg
23:57:07  * jgijoined