00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:04:56  * chris_99quit (Quit: Ex-Chat)
00:13:43  * jgijoined
00:47:21  <srl295>jgi: ping
00:47:26  <jgi>srl295: pong
00:47:41  <srl295>jgi: hi. now that you own 7676, want me to remove the [ ] checkbox todos that you're already taking care of?
00:48:10  <jgi>srl295: the ones I created other separate issues for?
00:48:16  <srl295>possibly
00:48:39  <jgi>srl295: let me go through the ones that are still unchecked
00:49:04  <srl295>jgi: just two on https://github.com/joyent/node/issues/7676#issuecomment-64704230 i think
00:50:21  <jgi>srl295: thanks! The first one is done with PR https://github.com/joyent/node/pull/8994, and the second one is represented by https://github.com/joyent/node/issues/8996
00:51:17  <jgi>srl295: there’s also this comment: https://github.com/joyent/node/issues/7676#issuecomment-62657598 where it says “make --with-intl= set to icu by default”, I’m not sure what that meant
00:51:48  <srl295>jgi: think it meant 'on'
00:52:07  <srl295>jgi: and, it's going to be for downloads, not for users checking out from the repo ( it's "none" by default)
00:52:37  <jgi>srl295: ok, so that’s covered by https://github.com/joyent/node/pull/8994 too right?
00:54:08  <srl295>jgi: fixed https://github.com/joyent/node/issues/7676#issuecomment-62657598 - it was referring to #8719
00:55:13  <srl295>jgi: updated https://github.com/joyent/node/issues/7676#issuecomment-64704230 to have links to the two tickets
00:55:16  <srl295>issues
00:55:41  <jgi>srl295: thanks!
00:59:22  <piscisaureus>jgi: how far are you guys with merging v0.10
00:59:38  <piscisaureus>jgi: I can't really reconstruct the changes you made to timer
01:00:25  <srl295>jgi: welcome. Removed todos from https://github.com/joyent/node/wiki/Intl did all but timezones.
01:01:54  <jgi>piscisaureus: I’m currently trying to find a way to not have to do it all over from scratch, but haven’t found one yet. If we don’t find a way to reuse the work that has been done, someone will have to do it. It’s a big merge, If I had to do it from scratch it would take a lot of time.
01:02:19  <jgi>piscisaureus: maybe I can help you with that? What change are you trying to reconstruct?
01:02:48  <piscisaureus>jgi: a sec, I'm writing it down
01:03:58  <piscisaureus>jgi: so it seems that Ben did this: https://github.com/iojs/io.js/commit/ebf9f297b30d6cf2e5060da91d63cebbedc448e2
01:05:57  <piscisaureus>jgi: and yours is totally different: https://github.com/iojs/io.js/commits/v1.x/lib/timers.js ...
01:06:02  <piscisaureus>er
01:06:12  <piscisaureus>https://github.com/joyent/node/commits/v0.10/lib/timers.js
01:06:20  <piscisaureus>sorry this is all confusing :)
01:08:15  <piscisaureus>jgi: anyhow you seem to have fixed an issue with .unref() but I don't quite what the issue is
01:08:53  <jgi>piscisaureus: ah ok, the issue was a small typo: https://github.com/joyent/node/commit/78db74dd88bdf4159da4d278e89b0781119633d5#diff-0a5d4868b2b9b17cf9e2c11f1bd1311eR296
01:09:03  * film42424joined
01:09:04  <jgi>piscisaureus: s/repeat/_repeat/
01:11:18  <piscisaureus>jgi: hmm
01:11:46  <piscisaureus>jgi: actually I was interested in trevnorris' https://github.com/joyent/node/commit/0d051238be2e07e671d7d9f4f444e0cc1efadf1b
01:13:31  <piscisaureus>jgi: also https://github.com/joyent/node/commit/934bfe23a16556d05bfb1844ef4d53e8c9887c3d -- was it worth it? Did you get better performance on e.g. http_simple?
01:13:56  * qard_quit (Remote host closed the connection)
01:15:19  * reqshark__joined
01:16:56  <jgi>piscisaureus: I didn’t use http_simple, but ran my own benchmarks. I wrote about my investigations here: https://github.com/joyent/node/wiki/Optimizing-_unrefActive, here: https://github.com/joyent/node/issues/8160#issuecomment-53029880 and here: https://github.com/joyent/node/issues/8160#issuecomment-53107766
01:18:52  * reqshark_quit (Ping timeout: 240 seconds)
01:18:59  <jgi>piscisaureus: these benchmarks use wrk, and I consistently saw a throughput improvement of around 10% with a CPU usage that was dropping from around 10-30% to around 1-4%
01:19:25  <jgi>piscisaureus: but that’s in the ideal scenario of no timeouts
01:19:27  * reqshark__quit (Ping timeout: 245 seconds)
01:20:05  <jgi>piscisaureus: someone on the google group also tested it and seemed to be happy with it: https://groups.google.com/forum/#!topic/nodejs/Uc-0BOCicyU/discussion
01:20:07  <piscisaureus>jgi: I'll try to replicate that. Those numbers would certainly be worth the effort.
01:20:34  <jgi>piscisaureus: if you get different results, please let me know
01:23:04  <jgi>piscisaureus: you will also want to get this change: https://github.com/joyent/node/commit/fd2cb7c611595f1d9095e3087b06939d22238540 if you get https://github.com/joyent/node/commit/934bfe23a16556d05bfb1844ef4d53e8c9887c3d
01:23:44  <piscisaureus>jgi: the weird thing is that the timers linked list structure was optimized to never traverse the list
01:24:10  <piscisaureus>jgi: the principle is described in http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod - section "Wee, just use a double-linked list for your timeouts"
01:24:40  <piscisaureus>we temporarily threw that out in node 0.5 in favor of something much simpler, but it turned out to be too much of a performance loss
01:24:46  <piscisaureus>so the linked list was put back
01:25:06  <piscisaureus>so I wonder where history took the long turn and this suddenly became a bottleneck
01:25:12  <piscisaureus>s/long/wrong/
01:29:00  <jgi>piscisaureus: the section you pointed seems to describes “some kind of timeout with the same timeout value”
01:29:29  <jgi>piscisaureus: If I understand correctly, that doesn’t apply to internal timers
01:29:42  <jgi>piscisaureus: (the timers in the “unrefList” list)
01:30:13  <jgi>piscisaureus: these timers, which can have different timeout values, are stored in the same list
01:30:29  <piscisaureus>Huh. Whay aren't they just separate Timer handles?
01:30:44  <jgi>piscisaureus: what this section describes seems to apply to the other “kind” of timers, stored in “lists”
01:30:52  <piscisaureus>well yes
01:30:54  <piscisaureus>the idea is this
01:31:24  <piscisaureus>"normally" the most efficient you can do is create a libev timer (in our case, a libuv timer, but that's basically the same interface)
01:31:54  <piscisaureus>in c it gets stored in a heap (or an rb tree currently on windows)
01:32:19  <piscisaureus>but if you have a lot of timers that can be inexact
01:32:34  <piscisaureus>but with the same timeout value
01:32:49  <piscisaureus>(in node the use case is primarily http timeout timers)
01:32:56  <piscisaureus>then a linked list is faster
01:38:59  <Aleksander_>I compiled libuv on windows using mingw. During compilation it output two assertion failures, but it did build. When I try to compile with: "gcc -o main main.c libuv/libuv.a", it outputs http://pastebin.com/rFJiea2k
01:42:03  <Aleksander_>Does any of that mean anything to anyone?
01:44:54  * a3fquit (Ping timeout: 244 seconds)
01:45:31  <piscisaureus>Aleksander_: I don't know why, but somehow you're not linking against winsock (-lws2_32)
01:45:59  <piscisaureus>could be a libuv issue; the mingw build is not tested so often (although I recently did with v1.1 and I found no issues)
01:46:15  <piscisaureus>jgi: thanks for the help
01:47:12  <piscisaureus>Aleksander_: actually I would expect more linker errors in that case... WSASend etc
01:47:15  <jgi>piscisaureus: you’re welcome
01:47:49  <Aleksander_>If I add -lws2_32 to the end, I get a few more errors
01:48:07  <jgi>piscisaureus: I’m not sure I understand your question: ”Whay aren't they just separate Timer handles?”
01:48:27  <jgi>piscisaureus: do you mean that we should put internal timers in the same list of lists as the non-internal ones and just unref their handles?
01:48:31  <piscisaureus>jgi: well with timer handle I mean a c++ "TimerWrap"
01:48:59  <piscisaureus>jgi: but I think I kind of deciphered what happened
01:48:59  <jgi>piscisaureus: actually, that wouldn’t work, since there’s only one handle per timeout value
01:49:07  <piscisaureus>jgi: well you can create more
01:49:38  <piscisaureus>jgi: what I'm thinking is that the javascript-only timers should just always be unref'ed
01:49:46  <piscisaureus>they're not public api anyway - only used by http
01:50:10  <piscisaureus>jgi: for user setTimeout and setInterval we can just always create a c++ timer
01:50:13  * Fishrock123quit (Quit: Leaving...)
01:50:34  <piscisaureus>jgi: those are not created super frequently anyway
01:50:38  <piscisaureus>typically :)
01:50:39  <jgi>piscisaureus: by javascript only timers you mean “internal timers” right? Currently they use just one underlying handle that is unrefed as soon as created
01:50:47  <jgi>piscisaureus: (just to make sure we’re on the same page)
01:50:51  <piscisaureus>jgi: yeah that's what I mean
01:51:08  <piscisaureus>jgi: for all the internal timers with the same timeout there is one c++ timer
01:51:39  <Aleksander_>It doesn't throw any errors unless I call uv_loop_init, so that's cool
01:51:40  <jgi>piscisaureus: currently, there’s one c++ timer for all internal timers
01:51:50  <piscisaureus>really
01:51:59  <piscisaureus>oh
01:52:07  <piscisaureus>that doesn't really make much sense
01:52:40  <jgi>piscisaureus: what doesn’t make sense?
01:52:54  <piscisaureus>the c++ to js boundary is a little bit expensive, but not expensive enough to make you do everything in js
01:53:40  <piscisaureus>jgi: ehm - what I mean... I don't think that's an efficient way to implement timers.
01:54:03  <jgi>piscisaureus: my intuition is that we don’t want to create too many C++ timers, not necessarily that we want to avoid crossing the C++/JS boundary
01:54:17  <piscisaureus>c++ timers are really cheap
01:55:36  <piscisaureus>jgi: there is still one c++ timer per list - https://github.com/joyent/node/blob/v0.10/lib/timers.js#L65
01:55:59  <jgi>piscisaureus: yes, that’s for “non-internal” timers
01:56:51  <piscisaureus>jgi: plus it seems that another is created when a user timer is unref'ed - https://github.com/joyent/node/blob/v0.10/lib/timers.js#L313
01:57:15  <jgi>piscisaureus: right
01:57:19  <piscisaureus>jgi: where does the one and only internal timer get created
01:57:20  <piscisaureus>?
01:57:34  <jgi>piscisaureus: https://github.com/joyent/node/blob/v0.10/lib/timers.js#L521
01:58:51  <jgi>piscisaureus: your suggestion in https://github.com/iojs/io.js/issues/268 sounds interesting
01:58:54  * dap_quit (Quit: Leaving.)
02:00:27  <srl295>jgi: added basic content to the wiki. leaving both tickets open because much cleanup is needed.
02:00:55  <srl295>s/much/some/
02:01:20  <srl295>back tomorrow
02:01:26  <jgi>srl295: thanks!
02:01:39  <jgi>srl295: what “both tickets” are you referring to?
02:02:32  <jgi>piscisaureus: keep in mind that when I did this change, I had been working within node’s codebase for only a month, so it’s very likely that we can do better than that.
02:05:56  <piscisaureus>jgi: don't worry, no shame
02:06:16  <jgi>piscisaureus: sure, what I meant is “feel free to question it” :)
02:06:19  * reqshark__joined
02:06:28  * Ralithquit (Ping timeout: 265 seconds)
02:06:37  <piscisaureus>jgi: it just caught me as a surprise that something changed about timers. I clearly hadn't been paying attention.
02:07:59  <piscisaureus>those bugs had to be fixed at the time. And I'm guessing it got us some more testsso it's easier to take another stab at it now.
02:17:22  * russfrankquit (Ping timeout: 245 seconds)
02:18:23  <jgi>piscisaureus: I’m signing off but don’t hesitate to ping me if you have other questions about recent changes
02:18:49  <piscisaureus>jgj: me too! It's almost 3:30am here
02:18:56  <piscisaureus>jgi: have a good one, I'll keep that in mind.
02:18:59  <jgi>piscisaureus: hehe :)
02:19:08  <jgi>piscisaureus: now I feel lazy...
02:19:10  <jgi>;-)
02:19:35  <jgi>piscisaureus: you too
02:19:42  * jgiquit (Quit: jgi)
02:19:52  <piscisaureus>:D
02:22:19  * a_lequit (Read error: Connection reset by peer)
02:22:31  * a_lejoined
02:35:22  * Ralithjoined
02:54:33  * bradleymeckjoined
03:00:49  <Aleksander_>By adding "IPHlpApi.Lib -lpsapi -lws2_32" flags and copying "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib\IPHlpApi.Lib" to the project directory.
03:01:51  * SplinterOfChaosjoined
03:04:15  <Aleksander_>my issue is solved
03:05:54  * reqshark__changed nick to reqshark
03:10:43  * riverjoined
03:11:04  * riverquit (Client Quit)
03:19:51  * dshaw_joined
03:23:04  * brsonquit (Ping timeout: 264 seconds)
03:26:16  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
03:37:51  * AvianFluquit (Ping timeout: 264 seconds)
03:46:47  * rmgquit (Remote host closed the connection)
03:54:39  * Left_Turnquit (Read error: Connection reset by peer)
03:54:50  * iarnaquit (Remote host closed the connection)
04:14:16  * russfrankjoined
04:14:52  * inolenquit (Ping timeout: 245 seconds)
04:23:23  * dshaw_quit (Quit: Leaving.)
04:28:36  * bradleymeckquit (Quit: bradleymeck)
04:28:52  * iarnajoined
04:30:46  * a_lequit (Remote host closed the connection)
04:31:25  * a_lejoined
04:32:19  * a_lequit (Read error: Connection reset by peer)
04:32:24  * a_le_joined
04:47:20  * rmgjoined
04:52:11  * rmgquit (Ping timeout: 252 seconds)
05:10:56  * brsonjoined
05:32:10  * AlexisMochajoined
05:32:26  * AlexisMocha_quit (Ping timeout: 244 seconds)
06:19:48  * bajtosjoined
06:26:54  * seishunjoined
06:33:38  * tarrudajoined
06:43:36  * yorkieneiljoined
06:49:18  * yorkieneilquit (Read error: Connection reset by peer)
06:52:26  <a_le_>hi :)
06:52:44  <a_le_>can I nuke a tcp handle with pending write requests?
06:52:59  <a_le_>(nuke as in uv_close)
06:53:03  * dshaw_joined
07:18:30  * [spoiler]joined
07:31:22  * seishunquit (Ping timeout: 240 seconds)
07:42:07  * octetcloudquit (Ping timeout: 244 seconds)
08:21:35  * dshaw_quit (Quit: Leaving.)
08:28:12  * hueniversejoined
08:45:08  * brsonquit (Quit: leaving)
10:02:26  * bajtosquit (Quit: bajtos)
10:06:00  <jalcine>It's really weird how no one has gotten around to making a decent C++ binding for libuv
10:06:15  <jalcine>like doesn't libv8 use it extensively?
10:11:15  * tarrudaquit (Ping timeout: 265 seconds)
10:13:34  <a_le_>have you looked at uvpp ?
10:15:18  * chris_99joined
10:25:46  * Left_Turnjoined
10:30:20  * tarrudajoined
10:44:25  * saghuljoined
10:53:24  * saghul_joined
11:05:33  * saghul_quit (Quit: Textual IRC Client: www.textualapp.com)
11:13:21  * bajtosjoined
11:14:03  * chris_99quit (Remote host closed the connection)
11:14:41  * warehouse13joined
11:16:15  * Left_Turnquit (Ping timeout: 264 seconds)
11:19:28  * bajtosquit (Quit: bajtos)
11:20:48  * bajtosjoined
11:25:47  * a3fjoined
12:07:28  * rendarjoined
12:16:27  <jalcine>a_le_: yeah, and it covers like 15% of libuv's bindings
12:16:41  <jalcine>it's a "oh, I need just 5 things" kind of project
12:16:58  <jalcine>a_le_: I've reached out to the dev to even consider contributing but no reply
12:17:21  <jalcine>no one gets replies from the maintainer so I'm just going to work on one over the next few weeks
12:19:49  * tarrudaquit (Ping timeout: 245 seconds)
12:22:43  * warehouse13quit (Ping timeout: 265 seconds)
12:40:38  * Left_Turnjoined
12:59:52  <erikj>jalcine: Btw, I was playing around with a uv binding project (https://github.com/erikjohnston/uv11), though its currently very much a first hack (and the cmake files are completely silly)
13:00:36  <jalcine>yup, I've starred your project
13:00:38  <erikj>I was trying to see if I could write one which allowed people to easily extend it to provide any functionality I had forgotten to implement
13:00:42  <erikj>oh, ha, that was you
13:01:55  <jalcine>there's one thing that uvpp did, allowing the base handle and request types to be templates.
13:02:09  <jalcine>it makes sense and is kind of what the docs outlined uv_handle_t and uv_req_t to be
13:02:45  <jalcine>My personal qualm is that there's no async support for it and that guy didn't look like he wanted a PR; just stars so :sparkles:
13:03:51  <erikj>I basically decided there didn't seem much point to write something that was basically a rehash of uvpp.
13:04:50  <erikj>I'm not sure I really see what templates buy you in this instance, as in my one you can still happily wrap any new uv handle type by inheriting from the Handle class
13:05:33  <jalcine>right, also giving you the benefit of a hardened, one purpose class
13:11:21  <erikj>I'm not sure what you mean by hardened there
13:11:33  <jalcine>like a definite model of the handle
13:11:39  <jalcine>sorry, it's too early for me :)
13:15:22  <erikj>Oh, I think I sort of see. Like the fact that it has a single Handle class with all the handle related functions as members?
13:15:26  <erikj>(No worries :)
13:17:13  <a_le_>jalcine, I would always have loved to work on something like that, but time is gonna be very short for me in the next 2-3 months
13:17:24  <a_le_>(it's 5:20 am here and i am still working)
13:17:40  <jalcine>gotcha
13:18:09  <jalcine>I think I can squeeze in time to send a PR for the async side of things
13:18:24  <jalcine>wait no, you got that
13:19:10  <[spoiler]>Random: someone's making libuv bindings for mruby (they're not very quick about it, & it's very experimental)
13:20:02  <[spoiler]>not v. quick, as in, there hasn't been any activity in a while https://github.com/mattn/mruby-uv
13:20:56  * a3fquit (Read error: Connection reset by peer)
13:21:12  <erikj>(As an aside, I found https://www.youtube.com/watch?v=3ZO0V4Prefc quite interesting from a "why do c++ binding project die?" point of view)
13:21:59  <jalcine>woah an hour long video
13:22:09  <jalcine>definitely watching this at lunch
13:22:35  <a_le_>jalcine: which part of the world are you in?
13:22:42  <jalcine>over in New York
13:22:50  <jalcine>-0500
13:26:45  * iarnaquit (Remote host closed the connection)
13:32:18  * jas-joined
13:33:56  * bajtosquit (Quit: bajtos)
13:34:34  * bajtosjoined
13:48:56  * bajtosquit (Quit: bajtos)
14:08:41  * jas-quit (Remote host closed the connection)
14:10:37  * bajtosjoined
14:10:43  * bajtosquit (Client Quit)
14:10:55  * jas-joined
14:13:45  * tarrudajoined
14:14:42  * jas-quit (Client Quit)
14:17:07  * jas-joined
14:23:03  * Fishrock123joined
14:29:14  * [spoiler]changed nick to [_spoiler_]
14:29:40  * [_spoiler_]changed nick to [spoiler]
14:58:17  * film42424quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:21:59  * tarrudaquit (Quit: WeeChat 1.0.1)
15:27:36  * AvianFlujoined
15:29:46  * Damn3dquit (Ping timeout: 265 seconds)
15:36:48  * Damn3djoined
15:53:46  * lanceballchanged nick to lance|afk
16:04:24  * roxlujoined
16:04:37  * bradleymeckjoined
16:05:08  <roxlu>hi guys, with the http_parser, can I feed it data whenever I receive it from my socket? For example when I receive first the headers and after that the body, can I feed the headers first ?
16:06:13  <bradleymeck>roxlu: you mean can you stream it one packet at a time?
16:06:26  <bradleymeck>yes you can do it piece by piece, no need to have the whole thing
16:06:34  <roxlu>bradleymeck ok awesome
16:07:25  <bradleymeck>tough if you are doing file work you may want to stream stuff to disk anyway
16:07:42  <bradleymeck>cause getting incomplete files and saving partially complete stuff is bad
16:09:53  * AvianFluquit (Ping timeout: 265 seconds)
16:19:41  * warehouse13joined
16:21:01  * seishunjoined
16:21:58  * Left_Turnquit (Ping timeout: 265 seconds)
16:23:12  <roxlu>bradleymeck does http_parser assume that the buffer I pass into it is the complete one?
16:23:22  <bradleymeck>define complete
16:23:28  <roxlu>yeah sorry :)
16:24:26  <roxlu>e.g. when I have a socket buffer of 128 bytes, can I receive data from the socket, pass it into the parser, receive a bit more into the same buffer starting writing at position 0, then pass it again into http_parser ?
16:24:45  <roxlu>or should I append the data I receive from the socket to some buffer ?
16:25:20  <roxlu>is that a bit clear?
16:26:17  <bradleymeck>roxlu: you can reuse the same buffer
16:26:24  <roxlu>ok
16:27:38  * iarnajoined
16:31:54  * iarnaquit (Ping timeout: 245 seconds)
16:32:02  <roxlu>somehow http_parser_execute() results in a segfault
16:37:48  <roxlu>Crashes after parsing the HTTP line, I'm adding some printf()s in http_parser_execute.
16:37:55  <roxlu>https://gist.github.com/roxlu/6216c2946b658f50aabe#file-http_parser-c-L701
16:42:21  * bradleymeckquit (Ping timeout: 244 seconds)
16:43:13  * bradleymeckjoined
16:43:25  * bradleymeckquit (Read error: Connection reset by peer)
16:44:02  * bradleymeckjoined
16:46:44  <roxlu>bradleymeck it crashes on this line, https://gist.github.com/roxlu/6216c2946b658f50aabe#file-http_parser-c-L933 .. I probably didn't set a callback (?)
16:48:02  * warehouse13quit (Ping timeout: 244 seconds)
16:48:06  <roxlu>sah yep.. didn't set on_status (though strangely this works with another test where I'm not setting the on_status neither)
16:50:53  * warehouse13joined
16:57:48  * dshaw_joined
16:59:57  * rmgjoined
17:01:06  * octetcloudjoined
17:06:08  * dap_joined
17:19:00  * bradleymeckquit (Quit: bradleymeck)
17:24:06  <rendar>roxlu, what is on_status?
17:24:22  <roxlu>rendar on_status is a member of http_parser_settings
17:28:57  * chris_99joined
17:29:06  <rendar>roxlu, oh, ok
17:31:05  <rendar>roxlu, are you writing that http_parser?
17:31:36  * brsonjoined
17:33:39  <roxlu>no joyent did
17:34:37  <rendar>oh, its that one from joyent, i see
17:39:12  * AvianFlujoined
17:49:34  * bajtosjoined
17:57:23  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:16:35  * AlexisMochaquit (Read error: Connection reset by peer)
18:17:52  * jgijoined
18:21:56  * dshaw_quit (Quit: Leaving.)
18:25:58  * piscisaureusjoined
18:31:21  <jgi>srl295: hi! Just nitpicking, but here: https://github.com/joyent/node/wiki/Intl/_compare/aef5a69%5E...aef5a69#diff-0ebd9cf55f559ccfda08331a2b8e25cbR32 that should read “--with-intl=[small-icu,full-icu]” instead of “--with-intl=full-icu” right?
18:32:14  <jgi>srl295: same here: https://github.com/joyent/node/wiki/Intl/_compare/aef5a69%5E...aef5a69#diff-0ebd9cf55f559ccfda08331a2b8e25cbR40, it should read “vcbuild.bat full-icu|small-icu”
18:37:09  <jgi>srl295: I made the changes, please feel free to revert/correct them if necessary
18:44:10  * iarnajoined
18:48:36  <trevnorris>jgi: know where's tj?
18:48:48  <trevnorris>i'm starting to tell people he was kidnapped by north korea
18:53:09  * roxlujoined
18:57:12  <srl295>jgi: wil look
18:57:14  * jgiquit (Quit: jgi)
18:58:35  * jgijoined
19:01:40  <jgi>trevnorris: from what I’ve heard, he’s busy working outside of the office, so I wouldn’t expect to hear from him until next week
19:02:20  <trevnorris>jgi: other than one more 0.10 to 0.12 merge, 12 is pretty much ready to be released right?
19:02:29  <jgi>trevnorris: that’s my understanding yes
19:02:50  <trevnorris>can we start w/ the merge so everything is ready to be released?
19:04:29  <jgi>trevnorris: yes, we don’t have to wait for TJ to do the merge
19:04:35  <jgi>trevnorris: if we can do it
19:05:06  <jgi>trevnorris: if you have some time to finish it, and if you don’t have to redo it from scratch, then by all means please finish it
19:05:53  <jgi>trevnorris: I was planning to redo it from scratch this afternoon, because If I wanted to rebase merge-review2 on v0.12, I would need to resolve all conflicts over again
19:06:26  <jgi>trevnorris: but if you used http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-rerere.html and you can rebase merge-review2 on top of v0.12 without having to do that, then that would be the best
19:08:18  <jgi>trevnorris: does that make sense?
19:10:59  * bajtosquit (Quit: bajtos)
19:11:55  * brsonquit (Quit: leaving)
19:12:19  <trevnorris>jgi: sure. i already have rerere enabled. just didn't realize it would auto detect the resolving of those issues being that the merge fixes were scattered over several commits.
19:13:38  * bradleymeckjoined
19:14:40  <jgi>trevnorris: I’m not sure I understand what you mean by “merge fixes”. Do you mean the commits c6500a1faa19ebe8de97519b2c89ca37df4d196f, 05a76b46171f348d5ec0d2adeafb2040a57bbc3a and 83219bf94ef3818a9a8e096693ce34fbfb0521ad that were landed after the merge commit itself?
19:14:56  <trevnorris>jgi: pretty much.
19:15:02  <trevnorris>wait
19:16:46  <trevnorris>jgi: i mean that after doing the "git merge" there were several commits made afterwards to fix up things I missed while doing the merge.
19:19:50  <jgi>trevnorris: I don’t think these commits have landed in the merge-review2 branch of joyent/node
19:20:05  <jgi>trevnorris: I landed them on my fork, but not in joyent/node
19:25:07  <jgi>trevnorris: but that’s alright, we now know what these issues are, and we can land these commits after the merge commit lands
19:25:42  <jgi>trevnorris: so I think if you could try to rebase merge-review2 on top of v0.12 and see if you don’t have to resolve the same conflicts again, that would be awesome
19:28:36  * sblomjoined
19:43:37  * octetcloudquit (Ping timeout: 264 seconds)
19:52:32  * stagasjoined
19:59:54  <jgi>trevnorris: going for lunch, but I’ll be back soon
20:10:18  * jgiquit (Quit: jgi)
20:14:53  * DrPizzaquit (Ping timeout: 240 seconds)
20:15:41  * DrPizzajoined
20:16:07  * warehouse13quit (Ping timeout: 245 seconds)
20:16:32  * warehouse13joined
20:19:37  <srl295>jgi yes. (to your earlier Q)
20:22:59  <srl295>jgi: wiki looks good. don't see readme changes
20:30:36  * octetcloudjoined
20:54:41  * jas-quit (Ping timeout: 244 seconds)
21:09:49  <a_le_>can I uv_close() a tcp handle with pending write requests?
21:10:56  * iarnaquit (Read error: Connection reset by peer)
21:11:28  * iarnajoined
21:21:41  * jgijoined
21:29:09  <jgi>trevnorris: I’m back, did you have some time to try a rebase of merge-review2 on top of v0.12 to see if the conflicts resolutions are re-used or if we have to do it from scratch?
21:31:08  * dshaw_joined
21:33:29  <jgi>srl295: what readme changes?
21:33:50  <jgi>srl295: do you mean that we want to keep the Intl Wiki page and the README section about Intl in sync?
21:41:06  <srl295>jgi: I'd think the README should be a summary and the Wiki more detailed?
21:41:19  <srl295>you said: 'jgi: srl295: I made the changes, please feel free to revert/correct them if necessary'
21:41:29  <jgi>srl295: yes, that sounds good (re: README vs Wiki)
21:41:32  * weoxjoined
21:42:07  <weox>libuv do use libeio or libev ? or it is implemented right on top of syscalls ?
21:42:47  <jgi>srl295: yes, I was referring to http://logs.libuv.org/libuv/latest#18:31:21.573 and http://logs.libuv.org/libuv/latest#18:32:14.927
21:42:58  <jgi>srl295: which both refer to the wiki page, not to the readme
21:45:15  <srl295>jgi: ah.. well, the wiki changes look good.
21:45:39  <srl295>sorry, i thought one of them was README.. gues because i recently copied from readme.
21:46:27  <srl295>jgi: If it was wikipedia I would append {{cleanup}} to the wiki page
21:46:51  <jgi>srl295: what does {{cleanup}} do?
21:47:55  <srl295>jgi: just says this needs updating
21:48:41  * brsonjoined
21:49:24  * Ralithquit (Ping timeout: 245 seconds)
21:50:39  <jgi>srl295: ok to close https://github.com/joyent/node/issues/8982?
21:52:49  <srl295>jgi: closed. Thanks, yes that would help. Not everyone deals with this particular kind of crazy :]
21:52:56  <srl295>i mean, explanation helps.
21:54:00  <jgi>srl295: thanks!
21:56:44  * dshaw_quit (Quit: Leaving.)
21:57:25  * hayesquit (Ping timeout: 256 seconds)
22:03:55  * hayesjoined
22:05:33  <srl295>jgi: GH just ate my wiki edits :/
22:06:07  <jgi>srl295: how so?
22:06:17  <jgi>srl295: you “saved” and your changes were gone?
22:06:19  <srl295>jgi: well- browser, rather
22:07:21  * Fishrock123quit (Remote host closed the connection)
22:11:32  * sblomquit (Read error: Connection reset by peer)
22:18:07  <jgi>octetcloud: ping
22:29:03  * weoxpart ("ERC Version 5.3 (IRC client for Emacs)")
22:31:06  * Fishrock123joined
22:41:02  * seishunquit (Read error: Connection reset by peer)
22:50:36  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:02:04  * reqshark_joined
23:02:52  * reqsharkquit (Read error: Connection reset by peer)
23:03:10  * bradleymeckquit (Quit: bradleymeck)
23:05:44  <jgi>trevnorris: ping
23:09:40  * wolfeidauquit (Remote host closed the connection)
23:10:24  * wolfeidaujoined
23:13:12  * Ralithjoined
23:14:49  * wolfeidauquit (Ping timeout: 245 seconds)
23:17:51  <srl295>jgi: ping
23:17:57  <jgi>srl295: pong
23:18:02  <srl295>jgi: major rewrite @ https://github.com/joyent/node/wiki/Intl
23:18:33  <jgi>srl295: great, I’ll take a look at it later, probably on Monday
23:19:43  <srl295>jgi: no problem. I'm going to mark https://github.com/joyent/node/issues/8981 as closed
23:20:23  <jgi>srl295: sounds good
23:20:25  <jgi>srl295: thanks!
23:22:21  <srl295>jgi: ah, https://github.com/joyent/node/issues/8914 is tagged for v0.12 - I can do that one quickly
23:23:11  * rendarquit (Quit: Leaving)
23:23:17  <jgi>srl295: actually the label means it affects 0.12, not that it’s scheduled to land in the version 0.12
23:23:34  <srl295>srl295: ah, ok. Probably some others need 0.12 then
23:23:41  <jgi>srl295: we use milestones for that (albeit not as consistently as we should, but we’re getting better at that)
23:23:52  <srl295>jgi: good to know
23:24:24  <jgi>srl295: still, because it impacts only the build system, I think we could do that whenever we want
23:24:39  <jgi>srl295: so now could be a good time, and when you’re done we can set it to the appropriate milestone
23:33:48  <trevnorris>jgi: pong
23:34:06  * chris_99quit (Quit: Ex-Chat)
23:35:12  <jgi>trevnorris: I wanted to know if you had time to try to see if when rebasing merge-review2 on v0.12, you had to solve the same conflicts over again or if rerere was able to reuse the work you did
23:35:44  <trevnorris>jgi: sorry, haven't touched it yet. i'll try to do some work before i wrap up today.
23:36:04  <jgi>trevnorris: ok, I started doing the merge from scratch, I’ll keep you updated on my progress
23:36:30  <trevnorris>jgi: cool, thanks. let me know if you have any questions.
23:38:05  <srl295>jgi: trevnorris: https://github.com/joyent/node/pull/9004 (and trevnorris also updated the wiki).
23:38:46  <jgi>srl295: cool thanks
23:49:25  * iarnaquit (Remote host closed the connection)