00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * AvianFlujoined
00:00:10  * ircretaryjoined
00:05:40  * brsonquit (Quit: leaving)
00:07:05  * quijotejoined
00:08:39  * kazuponjoined
00:11:20  * inolenjoined
00:11:44  * quijotequit (Ping timeout: 250 seconds)
00:12:34  * yunongquit (Ping timeout: 244 seconds)
00:13:02  * kazuponquit (Ping timeout: 265 seconds)
00:18:22  * yunongjoined
00:19:26  * Fishrock123joined
00:22:52  * thlorenzjoined
00:40:32  * rendarquit (Quit: Leaving)
00:47:19  * stagasquit (Ping timeout: 252 seconds)
00:53:13  <trevnorris>srl295: no idea how to address vcbuild.bat. possibly piscisaureus would have an idea.
00:54:28  <srl295>trevnorris: ok, thx. Your favorite file in the repo, I'm sure!
00:54:40  <trevnorris>hehe. yeah.
00:57:19  * avalanche123quit (Remote host closed the connection)
01:00:34  * avalanche123joined
01:05:06  * avalanche123quit (Ping timeout: 264 seconds)
01:08:02  * quijotejoined
01:11:01  <MI6>joyent/node: Saúl Ibarra Corretgé v0.12 * 20a7088 : deps: update libuv to 1.0.2 - http://git.io/UrFQeQ
01:12:21  * quijotequit (Ping timeout: 260 seconds)
01:13:30  * kazuponjoined
01:14:00  * hueniversequit (Read error: Connection reset by peer)
01:19:15  * Fishrock123quit (Ping timeout: 265 seconds)
01:28:31  * iarnaquit (Remote host closed the connection)
01:29:01  * iarnajoined
01:33:23  * AlexisMocha_joined
01:33:45  * AlexisMochaquit (Ping timeout: 265 seconds)
01:33:49  * iarnaquit (Ping timeout: 260 seconds)
01:36:12  * kazuponquit (Remote host closed the connection)
01:42:01  <srl295>trevnorris: let me know if you have any idas on https://github.com/srl295/node/pull/12
01:42:29  * kazuponjoined
01:42:43  <srl295>trevnorris: I still have that one and https://github.com/srl295/node/issues/10 to do
02:02:33  * Fishrock123joined
02:02:39  * iarnajoined
02:04:34  * iarnaquit (Read error: Connection reset by peer)
02:05:29  * iarnajoined
02:05:54  <MI6>joyent/node: David Siegel refs/tags/jenkins-accept-pull-request-temp * 5962d4a : Add-on init: Fix mess left after rebase (+16 more commits) - http://git.io/aTWYhA
02:07:35  <MI6>joyent/node: David Siegel refs/tags/jenkins-accept-commit-temp * 9b0e3db : Add-on init: Fix mess left after rebase (+16 more commits) - http://git.io/GaFN-Q
02:08:29  * quijotejoined
02:11:58  <a_le>is there a function to get a string representation of the type of a given handle?
02:13:31  * quijotequit (Ping timeout: 272 seconds)
02:19:56  * jgiquit (Quit: jgi)
02:23:17  * Ralithquit (Ping timeout: 260 seconds)
02:34:28  * Fishrock123quit (Quit: Leaving...)
02:49:31  * AvianFluquit (Quit: Leaving)
02:58:47  * thlorenzquit (Remote host closed the connection)
02:59:02  * thlorenzjoined
02:59:52  * Ralithjoined
03:05:50  * kazuponquit (Remote host closed the connection)
03:07:34  * nickleeflyjoined
03:09:20  * quijotejoined
03:12:07  * kazuponjoined
03:14:09  * quijotequit (Ping timeout: 260 seconds)
03:34:05  * tetsuo__quit (Ping timeout: 264 seconds)
03:38:56  * kazuponquit (Remote host closed the connection)
03:40:10  * tetsuo__joined
03:54:33  * rmgquit (Remote host closed the connection)
03:55:32  * rmgjoined
04:03:43  * AlexisMocha_quit (Ping timeout: 272 seconds)
04:10:03  * quijotejoined
04:14:42  * quijotequit (Ping timeout: 264 seconds)
04:18:25  * kazuponjoined
04:30:14  * sandr8_quit (Remote host closed the connection)
04:32:12  * reqsharkjoined
04:52:27  * sandr8joined
04:52:38  * abraxas_joined
04:57:07  * abraxas_quit (Ping timeout: 255 seconds)
05:10:51  * quijotejoined
05:12:04  * inolenquit (Ping timeout: 256 seconds)
05:15:25  * quijotequit (Ping timeout: 250 seconds)
05:21:57  * tetsuo__quit (Quit: leaving)
05:30:27  * seishunjoined
05:33:23  * thlorenzquit (Remote host closed the connection)
05:35:22  * sandr8quit (Remote host closed the connection)
05:42:53  * ovefjoined
05:47:34  * octetcloudquit (Ping timeout: 250 seconds)
05:50:36  * a_lequit (Ping timeout: 256 seconds)
05:51:51  * a_lejoined
06:11:38  * quijotejoined
06:16:05  * quijotequit (Ping timeout: 244 seconds)
06:34:15  * thlorenzjoined
06:38:49  * thlorenzquit (Ping timeout: 244 seconds)
06:42:24  * inolenjoined
06:42:58  * seishunquit (Ping timeout: 258 seconds)
06:49:48  * sandr8joined
06:50:29  * nickleeflyquit (Quit: Connection closed for inactivity)
06:52:57  * inolenquit (Ping timeout: 240 seconds)
06:54:36  * inolenjoined
06:54:56  * inolenquit (Client Quit)
07:40:34  * quijotejoined
08:08:25  * hueniversejoined
08:11:36  * reqsharkquit (Quit: Be back later ...)
08:23:22  * thlorenzjoined
08:28:10  * thlorenzquit (Ping timeout: 255 seconds)
08:30:37  * abraxas_joined
08:33:06  * rendarjoined
08:35:11  * abraxas_quit (Ping timeout: 250 seconds)
08:48:09  * janjongboomjoined
08:48:28  <saghul|afk>a_le: nope
08:49:30  * saghul|afkchanged nick to saghul
08:52:31  * quijotequit (Ping timeout: 250 seconds)
09:02:26  * dainis-changed nick to dainis
09:13:12  * quijotejoined
09:16:39  * inolenjoined
09:37:01  * tumdedumquit (Ping timeout: 255 seconds)
09:37:42  * tumdedumjoined
09:37:42  * tumdedumquit (Changing host)
09:37:42  * tumdedumjoined
09:45:54  * inolen1joined
09:45:54  * inolenquit (Read error: Connection reset by peer)
09:46:32  * rmgquit (Remote host closed the connection)
09:52:24  * quijotequit (Ping timeout: 250 seconds)
10:02:02  * nickleeflyjoined
10:03:22  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:08:29  * janjongboomjoined
10:09:19  * chris_99joined
10:12:08  * thlorenzjoined
10:16:37  * thlorenzquit (Ping timeout: 240 seconds)
10:20:47  * quijotejoined
10:36:21  * SergeiRNDjoined
10:37:24  * kazuponquit (Remote host closed the connection)
10:45:03  * SergeiRND1joined
10:46:41  * SergeiRNDquit (Ping timeout: 264 seconds)
10:54:50  * AlexisMochajoined
10:56:09  * SergeiRND1quit (Quit: Leaving.)
11:02:45  * SergeiRNDjoined
11:03:29  * rmgjoined
11:07:58  * Left_Turnjoined
11:08:45  * rmgquit (Ping timeout: 260 seconds)
11:10:17  * saapasquit (Ping timeout: 244 seconds)
11:11:58  * saapasjoined
11:27:00  * Alex7Komjoined
11:31:53  * quijotequit (Read error: Connection reset by peer)
11:32:14  * quijotejoined
11:36:50  * quijotequit (Ping timeout: 250 seconds)
11:53:31  * tarrudajoined
11:58:44  * SergeiRNDquit (Quit: Leaving.)
12:00:25  <MI6>joyent/node: Alexis Campailla v0.12 * 8708c7a : test: mark more tests as flaky - http://git.io/CN_M1A
12:01:01  * thlorenzjoined
12:02:41  <MI6>joyent/node: David Siegel refs/tags/jenkins-accept-commit-temp * e8a04f3 : Add-on init: Fix mess left after rebase (+16 more commits) - http://git.io/hoxu8Q
12:08:14  * abraxas_joined
12:12:43  * abraxas_quit (Ping timeout: 255 seconds)
12:14:27  * thlorenzquit (Ping timeout: 250 seconds)
12:27:26  * SergeiRNDjoined
12:33:26  * quijotejoined
12:37:53  * quijotequit (Ping timeout: 260 seconds)
13:00:44  * Alex7Komquit (Read error: Connection reset by peer)
13:00:56  * Alex7Komjoined
13:01:43  * Alex7Komquit (Read error: Connection reset by peer)
13:02:11  * Alex7Komjoined
13:05:21  * iarnaquit (Remote host closed the connection)
13:05:50  * iarnajoined
13:06:52  * Alex7Komquit (Read error: Connection reset by peer)
13:06:57  * Alex7Kom_joined
13:09:29  * chris_99quit (Ping timeout: 250 seconds)
13:10:17  * iarnaquit (Ping timeout: 245 seconds)
13:10:29  * nickleeflyquit (Quit: Connection closed for inactivity)
13:14:57  * chris_99joined
13:30:55  * Alex7Kom_quit (Read error: Connection reset by peer)
13:31:01  * Alex7Komjoined
13:31:48  * lance|afkchanged nick to lanceball
13:34:11  * quijotejoined
13:38:40  * quijotequit (Ping timeout: 256 seconds)
13:41:56  * Alex7Komquit (Read error: Connection reset by peer)
13:42:01  * Alex7Kom_joined
13:59:01  * thlorenzjoined
14:00:43  * quijotejoined
14:00:44  * hollandaisquit (Max SendQ exceeded)
14:02:37  * hollandaisjoined
14:03:52  * thlorenzquit (Ping timeout: 255 seconds)
14:05:23  * quijotequit (Ping timeout: 250 seconds)
14:15:25  * chris_99quit (Ping timeout: 260 seconds)
14:15:25  * Fishrock123joined
14:23:00  * AvianFlujoined
14:39:11  * Alex7Kom_quit (Read error: Connection reset by peer)
14:39:40  * Alex7Komjoined
14:53:37  * tarrudaquit (Ping timeout: 240 seconds)
14:57:56  * Alex7Komquit (Read error: Connection reset by peer)
14:58:22  * Alex7Komjoined
15:00:19  * SergeiRNDquit (Quit: Leaving.)
15:00:48  * Alex7Komquit (Read error: Connection reset by peer)
15:01:18  * Alex7Komjoined
15:01:40  * quijotejoined
15:06:17  * quijotequit (Ping timeout: 260 seconds)
15:17:11  * reqsharkjoined
15:24:39  * KennethWilkejoined
15:29:08  * quijotejoined
15:38:34  * brsonjoined
15:42:07  <AlexisMocha>The Jenkins job to accept pull requests now automatically rewords all commits to include reviewer name and PR url
15:42:10  <AlexisMocha>http://jenkins.nodejs.org/job/node-accept-pull-request/build?delay=0sec
15:42:37  <AlexisMocha>trevnorris, tjfontaine, indutny, jgi, chrisdickinson ^^
15:42:57  <AlexisMocha>Please give it a try! :)
15:44:09  <AlexisMocha>Sample commit: https://github.com/DanielSidhion/node/commit/e8a04f39199a331dd9e48f8c4c0d607d48d9d656
15:46:00  * abraxas_joined
15:47:54  * thlorenzjoined
15:50:06  * abraxas_quit (Ping timeout: 244 seconds)
16:00:26  * thlorenzquit (Ping timeout: 244 seconds)
16:17:31  * avalanche123joined
16:19:00  * avalanche123quit (Remote host closed the connection)
16:21:04  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:22:02  * avalanche123joined
16:25:12  * piscisaureusjoined
16:33:53  * chris_99joined
16:36:27  * bradleymeckjoined
16:42:34  * chris_99quit (Quit: Ex-Chat)
16:42:54  * iarnajoined
16:46:09  * jgijoined
16:46:46  * felixge_____quit (Ping timeout: 265 seconds)
16:46:56  * parshapquit (Ping timeout: 244 seconds)
16:47:52  * eugeneware_quit (Ping timeout: 258 seconds)
16:48:01  * savardcquit (Ping timeout: 260 seconds)
16:48:15  * kellabytequit (Ping timeout: 258 seconds)
16:48:38  * rvaggquit (Ping timeout: 258 seconds)
16:51:50  * thlorenzjoined
16:52:20  * KennethWilkequit (Quit: Leaving)
16:56:50  * thlorenz_joined
16:59:38  * rmgjoined
16:59:46  * octetcloudjoined
17:01:37  * thlorenz_quit (Ping timeout: 244 seconds)
17:02:07  * Fishrock123quit (Remote host closed the connection)
17:03:01  * KennethWilkejoined
17:11:03  <tjfontaine>AlexisMocha, chrisdickinson, trevnorris, indutny, cjihrig, jgi -- free for a call at 10 or 10:30 today?
17:11:19  <jgi>tjfontaine: yep
17:11:20  <indutny>is it in 1 hour?
17:11:30  <cjihrig>yes
17:11:31  <tjfontaine>indutny: yes, sorry, in 1 or 1.5 ~ hour
17:11:48  <indutny>tjfontaine: sorry, but I am not available at this time
17:11:56  <indutny>well
17:12:01  <indutny>guess I won't be able to do it today anyway
17:12:01  <tjfontaine>indutny: what times are you available today?
17:12:17  <indutny>I'm in 15 hours from SF right now :)
17:12:33  <indutny>tjfontaine: what is a topic, anyway?
17:12:37  <tjfontaine>you're +15 from PST?
17:12:43  <tjfontaine>indutny: weekly sync and 0.12
17:12:55  <indutny>tjfontaine: yep
17:13:13  <tjfontaine>we have some people from ibm who want to start participating and then I want to bring cjihrig in as well
17:13:25  <indutny>I see
17:13:35  <indutny>you should not wait for me, guys
17:13:40  <indutny>there is quite bad internet around
17:13:47  <indutny>so I may not hear most of the call anyway
17:13:50  <indutny>:)
17:13:57  <indutny>but I'll happily read the notes
17:13:58  <tjfontaine>ok, there's actually going to be a dial in number if you'd rather just do voice
17:14:04  <tjfontaine>we're also going to record the video
17:14:08  <tjfontaine>since, I guess, people like that
17:14:31  <indutny>hahah
17:14:31  <indutny>nice!
17:14:40  <indutny>I should have better internet next week
17:15:00  <indutny>anyway, going offline for 45 minutes
17:15:09  <indutny>ttyl
17:15:10  <tjfontaine>I'll send out an email then, if you can make it great, if not we'll catch you next time
17:15:34  * quijotequit (Ping timeout: 255 seconds)
17:19:09  * janjongboomjoined
17:21:18  * janjongboomquit (Client Quit)
17:21:42  * avalanche123quit (Remote host closed the connection)
17:23:59  * seishunjoined
17:29:13  * thlorenzquit (Remote host closed the connection)
17:29:48  * thlorenzjoined
17:33:43  * jgiquit (Quit: jgi)
17:40:29  * Fishrock123joined
17:43:02  * chris_99joined
17:43:25  * quijotejoined
17:43:56  * parshapjoined
17:46:07  * avalanche123joined
17:47:41  * bradleymeckquit (Quit: bradleymeck)
17:48:13  * quijotequit (Ping timeout: 260 seconds)
17:48:54  <AlexisMocha>tjfontaine: 10 works for me
17:51:23  <tjfontaine>AlexisMocha: but not :30? did you get my email? :)
17:54:00  * Alex7Komquit (Read error: Connection reset by peer)
17:54:05  * Alex7Kom_joined
17:55:03  * rvaggjoined
17:57:03  * sandr8quit (Remote host closed the connection)
17:58:59  * thlorenzquit (Remote host closed the connection)
18:00:24  * Alex7Kom_quit (Read error: Connection reset by peer)
18:00:27  <MI6>joyent/node: Shigeki Ohtsu merge-review * 116668e : doc: Update LICENSE for zlib 1.2.8 (+3 more commits) - http://git.io/akIiGQ
18:00:30  * Alex7Komjoined
18:01:09  * quijotejoined
18:01:32  * sandr8joined
18:02:16  * sandr8quit (Remote host closed the connection)
18:02:55  <AlexisMocha>tjfontaine: :30 is fine. I just saw your email.
18:02:55  * Alex7Komquit (Read error: Connection reset by peer)
18:03:01  <tjfontaine>AlexisMocha: ok thanks
18:03:15  * Alex7Komjoined
18:03:53  * eugeneware_joined
18:04:03  * sandr8joined
18:04:24  * thlorenzjoined
18:04:25  * kellabytejoined
18:05:02  * felixge_____joined
18:06:34  * avalanche123quit (Remote host closed the connection)
18:09:42  * jgijoined
18:12:27  * janjongboomjoined
18:15:54  * janjongboomquit (Client Quit)
18:17:42  * avalanch_joined
18:18:20  * janjongboomjoined
18:19:54  <chrisdickinson>I can attend for about :30 minutes -- sorry for the late reply
18:20:32  * quijotequit (Ping timeout: 265 seconds)
18:20:59  * janjongboomquit (Client Quit)
18:23:11  * dap_joined
18:27:03  * savardcjoined
18:27:10  <tjfontaine>chrisdickinson: coolio
18:27:21  <tjfontaine>saghul: you guys can't add apis in a patch release
18:27:27  <tjfontaine>saghul: that really doesn't work
18:27:52  <tjfontaine>saghul: people who build node with shared libuv for libuv 0.10 will be broken if node makes use of that api
18:34:14  <tjfontaine>AlexisMocha, trevnorris, indutny: https://bluejeans.com/880821687/
18:34:55  <chrisdickinson>i can always go the wile e. coyote route
18:35:06  <tjfontaine>heh
18:37:06  <tjfontaine>if others want to joint hey can
18:37:11  <tjfontaine>it's a public call that can hold 25
18:38:31  <srl295>tjfontaine: "people from ibm" - any specific? (on another call now)
18:39:13  * Alex7Komquit
18:40:07  <tjfontaine>srl295: james snell
18:40:10  * rmgquit
18:45:49  * avalanch_quit (Remote host closed the connection)
18:46:25  * avalanche123joined
18:46:27  * alexismjoined
18:47:02  <srl295>tjfontaine: thanks
18:53:45  * thlorenzquit (Read error: Connection reset by peer)
18:53:48  * thlorenz_joined
18:54:27  * sandr8quit
18:55:23  <a_le>saghul: so, apparently if i stop a uv_loop and then start it again, I still find my old handles pending on that loop?
18:55:44  <creationix>a_le yep
18:56:01  <creationix>if you want to clean it out, you need to use uv_walk and uv_close
18:56:14  <creationix>but check for already closing handles before calling uv_close
18:56:40  <rendar>so, stopping a uv_loop doesn't mean closing the fd (for epoll, kqueue, etc) but just stopping its reading of those async i/o events..
18:56:50  <a_le>how about requests like a getaddrinfo or a connect?
18:57:02  <a_le>will they still be pending?
18:57:11  <creationix>not sure what to do with them
18:57:50  <creationix>connect will be tied to a handle, but some requests like the fs ones don’t have handles
18:58:09  <a_le>creationix: when i call uv_close as part of uv_walk, do i then need to wait for some more loop iterations? just one more? or how many? and what is the best way to check if a handle is already being closed?
18:58:44  <creationix>I always run a single blocking uv_run after closing everything
18:59:20  <a_le>"connect will be tied to a handle" <--- you mean i will be seeing the corresponding tcp handle while walking the loop?
18:59:22  <creationix>use uv_is_closing to check if it’s closing
18:59:37  <a_le>I can't run a single blocking uv_run after closing...
18:59:56  <creationix>yes, you’ll see the unclosed tcp handle if there is a pending connect
19:00:01  <a_le>but I could keep on checking in a prepare call
19:00:33  <creationix>a_le: you have other stuff keeping the loop blocking?
19:01:05  <a_le>creationix: is it possible that I perform a uv_close on my tcp handle and get the uv_close callback invoked on that handle, yet i find that handle when walking my loop handles?
19:01:41  <creationix>no, once the close callback is called, it’s not in the loop anymore and uv_walk won’t see it
19:02:05  <a_le>can it come back for other reasons? :D
19:02:15  <creationix>btw, uv_prepare doesn’t prevent blocking, use uv_idle if you want to poll for closes
19:02:17  <a_le>I'm being the devil's advocate
19:02:30  <a_le>uv_idle is gonna drive the CPU utilization to 100%
19:02:36  <creationix>right, but close is fast
19:03:15  <a_le>creationix: I am building a layer on top of libuv and i have to provide my own "fini" method that tears down the loop. the fini is asynchronous and will eventually invoke uv_stop on the loop
19:03:17  <creationix>you stop the idle check once you’re done polling and it will go back to blocking mode
19:03:35  <a_le>this is how i have been writing it. now, there might be much better ways
19:04:17  * thlorenz_quit (Read error: Connection reset by peer)
19:04:21  <creationix>so if you want to close all the handles in a loop, a single blocking uv_run is fine after uv_stop, uv_walk ( uv_close)
19:04:29  <creationix>all that will be left in the loop will be closing handles
19:04:31  * thlorenzjoined
19:04:46  <creationix>I do it all the time in my unit tests for luvit
19:04:51  <a_le>ah!
19:05:02  <a_le>right
19:05:14  <a_le>from my callback when i do uv_stop, i can do a uv_run ONCE
19:05:30  <a_le>so, we are sure that a single loop iteration will be enough to close everything?
19:05:34  <tjfontaine>AlexisMocha, trevnorris, cjihrig, chrisdickinson, jgi: thanks
19:05:39  <creationix>well, I don’t know for sure if close callbacks all get called in the first _ONCE loop
19:05:45  <creationix>I’ve been using DEFAULT
19:05:49  <cjihrig>tjfontaine: np. thank you
19:05:50  <tjfontaine>AlexisMocha: want to talk to me about the jenkins stuff, it adds the PR and reviewed by?
19:06:06  <jgi>tjfontaine: thanks :)
19:06:07  <AlexisMocha>tjfontaine: yes it does
19:06:11  <a_le>creationix: when they are all closed the loop with stop by itself?
19:06:13  <creationix>I just know that close callbacks are fast enough I don’t mind blocking on them
19:06:28  <jgi>tjfontaine: sending you a gist for the unref timers test in a couple minutes
19:06:29  <rendar>do you use uv_walk() to walk all the instanced handles and destroy them?
19:06:30  <creationix>yep, uv_run(DEFAULT) unblocks when there are no handles left
19:06:33  <tjfontaine>jgi: thanks
19:06:47  <AlexisMocha>tjfontaine: if you want to know more I can get back on a call for the next 10 minutes
19:06:54  <creationix>rendar: in my system, I cleanup the structs and lua userdatas in uv_close’s callback
19:07:01  <creationix>so close is the same as cleanup for me
19:07:04  <rendar>creationix, i see
19:07:15  <rendar>creationix, but you could use uv_walk() for that right? isn't its purpose?
19:07:29  <tjfontaine>AlexisMocha: ok, skype or google?
19:07:34  <AlexisMocha>tjfontaine: skype
19:07:41  <creationix>yeah, but you don’t ever want to free the structs till after the close callback
19:07:49  <creationix>otherwise they might do things later on and segfault
19:08:22  <creationix>in lua, I do “uv.stop(); uv.walk(uv.close); uv.run()” essentially
19:08:46  <piscisaureus>isaacs: tc call
19:08:48  <creationix>only thing missing there is I add “if uv.is_closing(handle) then uv.close(handle) end” in the walk callback
19:08:55  <a_le>creationix: why do you do uv_stop() at all then?
19:09:06  <a_le>can't you walk while the loop is running?
19:09:19  <creationix>good question
19:10:27  <creationix>in my case, I had an exception during uv.run() which did a long jump and uv_run never got to clean up itself. I was hoping uv.stop helped there, but that’s probably shady
19:17:31  * quijotejoined
19:18:24  <jgi>tjfontaine: waiting for the build to finish on windows…
19:18:45  <jgi>tjfontaine: but here’s the gist: https://gist.github.com/misterdjules/be83fceb59753bf4b8f7
19:19:56  <jgi>tjfontaine: also, this video conference software works much better than hangouts or gotomeeting, thank you for finding that :)
19:20:09  <tjfontaine>jgi: rm found it for me :)
19:20:19  <tjfontaine>https://bluejeans.com/playback/guid/ODgwODIxNjg3OjEzOTgxMC04MjFmNGE0ZC02OWEyLTRmMTMtOTA2NC0yOWIyZmE2MGYyZWE=
19:22:01  * quijotequit (Ping timeout: 260 seconds)
19:22:08  <jgi>tjfontaine: is that a public link? bluejeans asks my login info
19:22:34  <tjfontaine>blah, lemme see if I can toggle make it public
19:22:46  <tjfontaine>https://bluejeans.com/s/7_j@/
19:26:22  * davijoined
19:29:52  <jgi>tjfontaine: alright, the change in the gist I sent you works well on Windows and OS X
19:30:12  <jgi>tjfontaine: I haven’t tested it on other platforms but I don’t see how it could fail
19:30:55  <tjfontaine>jgi: I will do another iteration of merge-review
19:31:05  <jgi>tjfontaine: yep, sounds good
19:37:23  <creationix>is uv_run re-entrant? I mean if I call uv_run while already blocking in another uv_run, will that cause trouble
19:37:43  <creationix>also if I long jump causing uv_run to never return, will that leak or cause issues?
19:37:51  <creationix>(both of these events happen during a callback)
19:38:23  <creationix>in practice, I haven’t seen any issues so far
19:46:17  * daviquit (Ping timeout: 260 seconds)
19:53:36  * janjongboomjoined
19:56:43  * chris_99quit (Ping timeout: 264 seconds)
20:03:16  * chris_99joined
20:16:49  * bradleymeckjoined
20:17:12  * jgiquit (Quit: jgi)
20:18:15  * quijotejoined
20:18:58  * thlorenz_joined
20:21:27  * jgijoined
20:22:49  * quijotequit (Ping timeout: 250 seconds)
20:23:50  * thlorenz_quit (Ping timeout: 256 seconds)
20:30:34  * piscisaureuspart
20:35:58  * janjongboomquit (Read error: No route to host)
20:47:11  * avalanche123quit (Remote host closed the connection)
20:49:24  * jgiquit (Quit: jgi)
21:12:20  * abraxas_joined
21:15:56  * avalanche123joined
21:17:17  * abraxas_quit (Ping timeout: 264 seconds)
21:18:03  * jgijoined
21:18:58  * quijotejoined
21:23:29  * quijotequit (Ping timeout: 258 seconds)
21:27:02  <a_le>creationix: when i close all of the pending handles, can i use NULL as the callback function pointer?
21:27:18  <creationix>yep
21:28:22  <a_le>thanks
21:29:18  <chrisdickinson>tjfontaine: indutny: are we pulling in the openssl 1.0.1i tarball into the deps/openssl/openssl dir, or are we getting openssl from a different source?
21:30:03  <tjfontaine>chrisdickinson: the path is to upgrade openssl in v0.10, since they're at the same version, and then the merge from v0.10 into v0.12 upgrades it there
21:30:10  <tjfontaine>chrisdickinson: we talked about that some on the call
21:30:15  * thlorenzquit (Remote host closed the connection)
21:30:22  <chrisdickinson>ah, i meant "what source are we pulling openssl from"
21:30:37  <tjfontaine>oh, well, we try and grab right from upstream
21:30:39  <chrisdickinson>(i'm working on the floating patch queue stuff)
21:30:53  <tjfontaine>right, man I can't wait to have taht :)
21:31:04  * thlorenzjoined
21:31:32  <chrisdickinson>cool -- just wanted to double check that we weren't pulling from chrome or some other source that already had gyp files
21:31:40  <tjfontaine>well
21:31:44  <tjfontaine>no not exactly
21:32:06  <tjfontaine>https://github.com/gypified this was an effort once upon a time
21:32:26  <tjfontaine>frankly, I'd just as soon cease depending on gyp for our dependencies
21:32:44  <tjfontaine>it shouldn't be our responsibility to maintain the build systems for all of them, it just causes extra noise
21:33:02  <tjfontaine>and opens us up to making mistakes
21:44:37  <jgi>tjfontaine: speaking of releases, what do we want to do regarding this issue: https://github.com/joyent/node/issues/8460?
21:45:09  <chrisdickinson>hm, it seems like the openssl tarball symlinks a ton of files which we currently solve with relative `#include`s.
21:47:29  <jgi>srl295: what branch from your repo should I track if I want to stay up to date with your ICU changes, srl-v0.12-FixToolsetAgain?
22:04:05  <tjfontaine>jgi: that will be fixed with a clean build, it'll be fine
22:04:48  <jgi>tjfontaine: do you mean we’ll do another build of 0.11.14 for win x64 and re-upload the files?
22:05:07  <tjfontaine>I think we'd just do a clean build of v0.11.15
22:08:30  * piscisaureus_joined
22:11:01  * iamstefquit (Ping timeout: 258 seconds)
22:11:27  * iamstefjoined
22:12:07  <jgi>tjfontaine: ok, I’m fine with that, can I close these issues saying that 0.11.15 will supersede 0.11.14 soon?
22:12:29  * seishunquit (Ping timeout: 264 seconds)
22:12:58  <tjfontaine>nod
22:14:48  <srl295>jgi: a sec
22:17:21  <srl295>jgi: srl-v0.12-FixToolsetAgain is a "side" one to try and fix https://github.com/srl295/node/pull/12 .. I would say the autoicu ( which is https://github.com/joyent/node/pull/8719 ) is the best "main" one to follow
22:18:01  <jgi>srl295: ok, thanks!
22:19:30  <srl295>jgi: also looking at https://github.com/srl295/node/issues/10 but it will probably be done on the same autoicu branch
22:19:47  * quijotejoined
22:21:18  <jgi>srl295: ok
22:24:14  * quijotequit (Ping timeout: 250 seconds)
22:29:12  <tjfontaine>AlexisMocha: ping, you should have ssh access to the jenkins master and slaves now
22:29:36  <tjfontaine>cjihrig: can you pm your ssh pubkey?
22:29:56  <cjihrig>tjfontaine: sure one sec
22:30:25  <tjfontaine>thanks
22:31:11  * thlorenz_joined
22:32:14  <srl295>jgi: any comments on these?
22:32:42  * rendarquit (Quit: Leaving)
22:32:49  <srl295>jgi: Oh, duh, sorry, just realized you opened #12. I was looking for you on irc before.
22:33:17  <jgi>srl295: not for now, I’m working on including the full ICU data for the OS X installer, so I’m getting familiar with the ICU specific code/build system
22:33:35  * bradleymeckquit (Quit: bradleymeck)
22:33:54  <jgi>srl295: I initially thought that we just wanted to ship only the binaries with the embedded small ICU data, but we actually want to ship the full ICU data with the installers
22:34:06  <jgi>srl295: so I’m going to ask questions pretty soon :)
22:34:10  <srl295>jgi: great. One thing to note is that with full-icu there's no opportunity to side-load an additional (replacement) .dat. ICYMI https://github.com/srl295/node/issues/8 for reducing full-icu's size
22:35:07  <srl295>jgi: Somehow I missed checking your whois before, sorry
22:35:13  <jgi>srl295: no problem :)
22:35:31  * thlorenz_quit (Ping timeout: 255 seconds)
22:38:31  <jgi>srl295: I think the idea for installers is to build the binaries with —with-intl=small-icu, and to store the .dat file in $PREFIX/share/node/i18n, and set this as the default value for “icu_data_dir” in node.cc at built time, how does that sound?
22:39:05  <srl295>jgi: there's an env var for that..
22:39:32  <srl295>jgi: https://github.com/joyent/node/wiki/Intl#using-the-small-build NODE_ICU_DATA
22:40:39  <srl295>jgi: btw if you are on a mac, take a look at /usr/share/icu if you want to be in good company
22:40:43  <jgi>srl295: then we would need to set this env var in the user’s profile right?
22:41:42  <srl295>jgi: hm. i suppose we could bake the value in somehow. Would need to decide what happens, what if the file doesn't exist, etc
22:42:11  <tjfontaine>so, want a separate env flag from $ICU_DATA
22:42:12  <tjfontaine>?
22:42:28  <tjfontaine>seems like we should -DICU_DATA_DIR=$PREFIX/share/node/icu
22:42:37  <tjfontaine>or $PREFIX/share/icu
22:42:58  <jgi>tjfontaine: that’s what I was thinking about yest
22:43:00  <jgi>yes
22:43:07  <tjfontaine>and then let $ICU_DATA override it like libicu already knows how to do
22:43:24  <jgi>yes
22:43:31  <tjfontaine>mk
22:43:33  <srl295>tjfontaine: jgi: ICU already will react to -DICU_DATA_DIR but in a different way. Should be -DNODE_ICU_DATA_DIR or something
22:43:51  <tjfontaine>srl295: no, I think we want to effect icu in that way
22:43:57  <tjfontaine>that's kinda my point
22:44:29  <tjfontaine>if I am a Debian, and I ./configure --prefix=/usr, it should JustWork right?
22:44:36  <cjihrig>tjfontaine: the discussion we had about strict argument checking for timers… did you see the comments there?
22:44:57  <tjfontaine>cjihrig: I haven't checked back in on the subsequent conversation, want to catch me up?
22:45:17  <jgi>srl295, tjfontaine: ah OK, i hadn’t seen that ICU_DATA_DIR is already used by icu itself
22:45:31  <srl295>tjfontaine: need to configure ICU a little differently to do it that way. u_setDataDirectory() doesn't override "built in" data.
22:45:58  <srl295>jgi: tjfontaine you are on to something there, though. But probably need the node_i18n.cc I added to NOT also call u_setDataDirectory() if it is already set by -DICU_DATA_DIR
22:46:11  <cjihrig>tjfontaine: ben pointed out that changes like that to setTimeout() could completely break code that is run in both the client and server
22:46:46  <tjfontaine>srl295: right, so I woudl advocate that node never needs to call u_setDataDirectory (unless we had some [and it's less likely to be able to work] JS api for manipulating it)
22:47:03  <tjfontaine>srl295: so, barring that, I think we just make icu work like it already wants to, but we juts provide some sane defaults
22:47:20  <tjfontaine>srl295: so right, not calling u_setDataDirectory by default
22:47:58  <tjfontaine>cjihrig: you mean isomorphic code, that is shipped to the browser as well as what's run in Node.js?
22:48:09  <srl295>tjfontaine: right, right. Agree on the principle here. it's a slight delta on how 'small-icu' works at this moment- it always calls setCommonData() because the "embedded" data is stub (i.e. empty)
22:48:51  <tjfontaine>srl295: right ok, so that principle is what I think we should be aiming for, so I hope you, jgi, and trevnorris can find the path there :)
22:48:59  <cjihrig>tjfontaine: yes
22:49:56  <tjfontaine>cjihrig: the changes to `setTimeout` proper, as opposed to the work that happens on `socket.setTimeout`
22:50:15  <cjihrig>tjfontaine: yes, setTimeout() proper
22:50:44  <srl295>tjfontaine: jgi: trevnorris: so NODE_ICU_DATA_DIR might be a better option ( or could be a config opt..) , meaning if defined, u_setDataDirectory(that) is called instead of any other mechanism. Should it disable the --with-icu-dir= parameter?
22:51:07  <tjfontaine>cjihrig: I agree that we have to make `global.setTimeout` work like what people expect in the browser, but we can validate and coerce at that level, but `socket.setTimeout` can have the real validatioin
22:52:45  <srl295>tjfontaine: jgi: trevnorris: Kind of wonder if this should be a differnet config option.. dont' even bother building the "small" data into ICU at all, just stubdata and expect the .dat file to be as specified. Keep the --with-icu-data= parameter in that case, as an override
22:52:48  <jgi>srl295: what does —with-icu-dir do? I can’t find it anywhere
22:53:13  <srl295>jgi: sorry.. --icu-data-dir - as in https://github.com/joyent/node/wiki/Intl#using-the-small-build
22:53:21  <tjfontaine>srl295: we could totally have: ./configure --icu-data-dir=SOMETHINGELSE, and use that for -DICU_DATA_DIR -- the question is what circumstance are we trying to handle that we must call u_setDataDirectory
22:53:40  <srl295>tjfontaine: testing prior to 'make install'?
22:54:03  <tjfontaine>srl295: it may be that's what we want by default, where we do u_setDataDirectory(path.join('..', '..', execPath, 'share', 'icu'))
22:54:24  <tjfontaine>srl295: it probably doesn't take kindly to relative paths, does it?
22:54:28  <srl295>tjfontaine: also, the .gyp in that case shouldn't try to build any ICU data at all.
22:54:31  <cjihrig>tjfontaine: ok. global.setTimeout() already does a good job. just worried about having inconsistent APIs for different types of timers
22:55:11  <srl295>tjfontaine: It'll take relative paths. It's just mmap()ing the thing. Historical note: we did this 'get data from shared libs' stuff just to make the system loader find our data. It even used the Windows registry during certain periods of its history. End note.
22:55:57  <tjfontaine>cjihrig: might I just say that `global.setTimeout` accepting strings is f'n crazy.
22:57:02  <cjihrig>yea. and coercion is done with multiplication… but i can see the case for making it behave like the browser
22:57:30  <tjfontaine>cjihrig: I just mean today, in browsers, I think that is crazy.
22:57:36  <tjfontaine>but fine whatever, that's what we have to support
22:57:50  <tjfontaine>for *our* apis we can actually be sane
22:58:04  <cjihrig>ok. that's what i'll do
22:58:12  <cjihrig>thanks
22:58:32  <jgi>cjihrig: thanks, and sorry for the back and forth on this issue! :)
22:59:02  * AlexisMochaquit (Ping timeout: 245 seconds)
22:59:10  <cjihrig>jgi: no problem :-)
23:00:09  * thlorenzquit (Remote host closed the connection)
23:00:35  * thlorenzjoined
23:00:37  * quijotejoined
23:02:16  * quijotequit (Read error: Connection reset by peer)
23:02:25  * quijote_joined
23:04:21  * octetcloudquit (Ping timeout: 272 seconds)
23:04:28  <jgi>srl295, tjfontaine, trevnorris: so to summarize the discussion about ICU: we’re saying that we want to let icu itself handle where the ICU data is located, but there could still be a need for node to call u_setDataDirectory for testing purposes?
23:05:49  <srl295>jgi: we can still have the --icu-data-dir parameter to node, but unless that is used, no u_setDataDirectory is called.
23:06:54  * quijote_quit (Ping timeout: 244 seconds)
23:07:40  <srl295>jgi: tjfontaine: opened https://github.com/srl295/node/issues/13 against myself
23:08:02  <jgi>srl295: what about “need to configure ICU a little differently to do it that way. u_setDataDirectory() doesn't override "built in" data.”? what is “built-in data” in this context?
23:08:33  <jgi>srl295: ok, read #13 and I think it answers this question
23:08:44  <jgi>small-icu will just stub the data, and that can be overriden
23:08:46  <jgi>right?
23:09:41  <srl295>jgi: "stub" here means the data symbol comes from http://source.icu-project.org/repos/icu/icu/trunk/source/stubdata/stubdata.c which is an empty array
23:10:12  <srl295>jgi: "small-icu" links with stub, but then calls setCommonData(ENGLISH_ONLY_STUFF) from node's main()
23:11:03  <srl295>jgi: so what I was saying is if there's a data path at build time, we should just link ICU with stub and be done with it (unless an override parameter is given at runtime)
23:11:14  <tjfontaine>cjihrig: I am just depressed right now looking at how `setTimeout` works in the browsers.
23:11:37  <jgi>srl295: ok, that sounds good
23:11:48  <cjihrig>tjfontaine: but…. javascript!
23:15:14  <srl295>jgi: are you testing your srl295/node#12 ( arch ) PR on OSX? It looks like it changes the HOST tooling to 386 also, not just TARGET. Not sure it's my bug or some bug in gyp or its node configuration
23:16:01  <srl295>jgi: tjfontaine: at least some heart-warming responses on the gyp ML https://groups.google.com/forum/#!topic/gyp-developer/NrFzsJd2l78 [or not]
23:17:07  <jgi>srl295: I wanted to have a solid plan and a first pass for shipping ICU data with the installers first, and then have another look at it
23:17:20  * thlorenz_joined
23:17:33  * thlorenzquit (Read error: Connection reset by peer)
23:21:21  * chris_99quit (Quit: Ex-Chat)
23:21:21  <srl295>jgi: good deal.
23:24:00  * KennethWilkequit (Quit: Leaving)
23:28:07  <jgi>srl295: however, if you’re already working on https://github.com/srl295/node/issues/13, the best way I can help is by working on fixing the “toolset” issue right?
23:28:40  <jgi>srl295: if you’re not working on #13, then maybe I can take it?
23:29:49  * c4milojoined
23:30:00  <tjfontaine>srl295: buildsystems suck and are hard, gyp really seems to go out of its way to make life more obscure than it needs to be :)
23:32:07  * bradleymeckjoined
23:32:41  <srl295>tjfontaine: it's already driven me to cmake :]
23:32:53  <tjfontaine>srl295: and *that* is saying something, right?
23:33:02  <srl295>yep!
23:33:36  <tjfontaine>anyway, as with all things google, it's really not about being concerned with how to interoperate best in the existing ecosystem
23:33:50  <srl295>ICU maintains msvc project files + Makefiles. future is cmake https://ssl.icu-project.org/trac/ticket/7747 wihch can even make ninja. Ninja is kind of the consolation for working w/ gyp here :)
23:34:13  <tjfontaine>it's like making ninja and gn to make compiles faster, and ignoring doing real work on existing compilers and linkers
23:34:58  <tjfontaine>to be fair there is a group working on llvm/clang, but it's not as serious of an effort to make everyones life better
23:35:08  <tjfontaine>srl295: gyp can make cmake, what isn't that enoguh for you?!
23:35:38  <srl295>tjfontaine: no further comment.. but yeah, gn is not an existing-ecosystem kind of thing
23:35:45  <srl295>tjfontaine: aaaaaaaargh!
23:36:09  <tjfontaine>Node's perpensity to statically link the world also makes this hard, because it promotes the idea that it's ok to rip out someone elses build system in favor of shiny thing
23:36:44  <tjfontaine>really, there's little reason to change how v8, c-ares, zlib knew how to build themselves
23:37:05  <srl295>tjfontaine: doesn't sound like v8 is planning on changing soon
23:37:08  <tjfontaine>a makefile and msvc project file for node in that light would have been fairly trivial
23:37:13  <tjfontaine>srl295: from gyp to gn?
23:37:39  <srl295>tjfontaine: jochen said gn is there just to support chromium for now
23:37:57  <tjfontaine>as was gyp when things were still scons :)
23:38:19  <srl295>I asked becuase the trunk v8 gn has NO provision for the kind of icu customization I'm doing in node
23:39:01  <tjfontaine>that's because all of that customization and work will have to be sourced from the community, because v8 doesn't really consider itself a project that's consumed by people other than chromium
23:39:15  * tjfontainefinshes rant
23:39:19  <srl295>tjfontaine: which is unfortunate.
23:39:52  * AvianFluquit (Ping timeout: 245 seconds)
23:40:39  <jgi>srl295: what’s the best way for me to help? Working on https://github.com/srl295/node/issues/13 if you haven’t already started, or investigating the “toolset” issue?
23:40:58  <srl295>tjfontaine: anwyays, once the 0.12 exercise is over I'll need to talk to the v8 i18n folk(s) a bit more
23:41:17  <tjfontaine>srl295: what do you suppose their intentions are?
23:41:35  <srl295>tjfontaine: on build or on i18n? On i18n I haven't talked recently.
23:41:39  <tjfontaine>Node also has the upcoming/outstanding task of internationalizing all of our errors
23:41:41  <srl295>jgi: right. I haven't started 13, and the toolset is a bit stuck. I'm trying to finish srl295#10
23:41:49  <jgi>srl295: ok
23:41:59  <srl295>tjfontaine: cool.. I know this library…
23:42:05  <tjfontaine>:P
23:44:43  <tjfontaine>srl295: so there's the default language that Node's text is in, let's assume for now it will always be English since that's what it exists today, there's the concept of localizing errors based on where the node binary is executing, but then what the programmer may want to deliver to the client -- so many moving pieces
23:45:37  <tjfontaine>historically I've been displeased with how gettext (doesn't) handle this
23:45:54  <srl295>tjfontaine: yes and their 'client' is a RESTful API client that is talking to THEIR client who is in some other language altogether.
23:46:13  <tjfontaine>precisely.
23:47:51  <srl295>tjfontaine: it's like currency. You don't just ship around 20.00 as a value. 20 what? Euros? Yen? Simoleons? etc. Needs to be tagged. To my thinking, best practice is that errors are an error code and a dictionary of stuff. Kind of like Java exceptions can be.
23:50:24  <tjfontaine>ya but we want to move to this path where errors wrap their underlying error, so there's actually a stack that must be localized, it's not insurmountable, just want to make sure we have a best practice for people, and where feasible an api
23:53:25  * AvianFlujoined
23:53:54  <srl295>tjfontaine: ideally, it's an ecmascript level best practice right?
23:54:28  <tjfontaine>I am not trying to move mountains with talking to a standards body, but I think it's best-practice/common-sense for the rest of us :)
23:55:03  <srl295>tjfontaine: well - a JS-level common practice of some sort. [back in a few]
23:56:31  * toothrotjoined