00:00:03  * ircretaryquit (Remote host closed the connection)
00:00:15  * ircretaryjoined
00:00:44  <jgi>rendar: that’s for node, not libuv
00:00:52  <rendar>jgi, oh ok!
00:01:02  * a_lequit (Remote host closed the connection)
00:20:09  * a_lejoined
00:23:54  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:25:15  * dshaw_joined
00:26:11  * rendarquit (Quit: Leaving)
00:27:46  * thlorenzjoined
00:29:26  <tjfontaine>stdlib needs to die
00:29:31  <tjfontaine>anyway
00:30:03  <tjfontaine>jgi: it feels like it's versioned enough as is, that it at least knows the version it needs for the symbol
00:30:11  * thlorenzquit (Remote host closed the connection)
00:30:31  <tjfontaine>jgi: so our base stdc++ we need is 3.4.15?
00:31:10  <jgi>tjfontaine: yes, but this version is not installed by CentOS stable
00:32:01  <jgi>tjfontaine: sorry, it is not installed by CentOS 6.x apparently
00:32:10  <jgi>tjfontaine: CentOS stable probably means nothing
00:33:16  <jgi>tjfontaine: at least it’s not installed with CentOS 6.5, we’d need to test later versions
00:33:57  * a_lequit (Read error: Connection reset by peer)
00:34:06  * a_lejoined
00:35:32  <jgi>tjfontaine: centos 6.6 also seems to have a libstdc++ that is too old by default
00:40:24  <jgi>tjfontaine: centos 7.x seems fine
00:44:34  * [spoiler]quit (Quit: Leaving)
00:57:18  * dshaw_quit (Quit: Leaving.)
01:00:49  <tjfontaine>jgi: right, I think we just want to find out what the minimum version for each distribution that is
01:00:57  <tjfontaine>jgi: and then we'll publish that information on download.html
01:02:07  <jgi>tjfontaine: sounds good
01:02:33  <tjfontaine>so centos >= 7, ubuntu >= 14.04, rhel >= 7
01:02:36  <tjfontaine>blah blah blah
01:02:48  <tjfontaine>fedoracore 9001
01:04:23  * a_lequit (Remote host closed the connection)
01:04:25  * reqsharkjoined
01:05:57  * a_lejoined
01:08:27  * dshaw_joined
01:09:13  * chris_99quit (Quit: Ex-Chat)
01:15:03  * octetcloudquit (Ping timeout: 264 seconds)
01:15:32  <jgi>tjfontaine: and so porting v0.12 to older versions (Centos 6.x, Ubuntu 12.04, etc.) is left to packagers?
01:18:00  <tjfontaine>jgi: yes
01:18:10  <tjfontaine>jgi: I don't really see another solution
01:20:03  <robertkowalski>i were able to test the rewrite rules by installing a local nginx and messing with my /etc/hosts
01:20:15  <tjfontaine>excellent
01:20:28  <robertkowalski>tjfontaine: sent you a PM
01:20:31  <tjfontaine>looking
01:22:46  <robertkowalski>btw for everyone interested in slicing out a directory from a repo but keeping the history, i did this for the doc-tool:
01:22:57  * andrehjrquit (Quit: Computer has gone to sleep.)
01:23:04  <robertkowalski>git subtree split -P tools/docs -b export-doc-tool-branch
01:23:21  <robertkowalski>then i got just the docs folder in the branch export-doc-tool-branch
01:27:47  * dshaw_quit (Quit: Leaving.)
01:28:09  * abraxas_joined
01:31:07  * thlorenzjoined
01:32:32  * abraxas_quit (Ping timeout: 246 seconds)
01:36:20  * thlorenzquit (Ping timeout: 265 seconds)
01:43:38  * a_lequit (Remote host closed the connection)
01:44:04  * a_lejoined
01:45:03  * abraxas_joined
01:45:16  * a_lequit (Remote host closed the connection)
01:46:27  * a_lejoined
02:09:18  * Fishrock123quit (Quit: Leaving...)
02:10:29  * dap_quit (Quit: Leaving.)
02:11:58  * a_lequit (Ping timeout: 255 seconds)
02:13:17  * thlorenzjoined
02:13:39  * thlorenzquit (Remote host closed the connection)
02:24:39  * Ralithquit (Ping timeout: 264 seconds)
02:39:53  * a3fjoined
02:42:09  * iarnajoined
02:49:30  * Ralithjoined
02:50:54  * a_lejoined
02:56:45  <jgi>signing off, have a good evening everyone
02:57:39  * jgiquit (Quit: jgi)
03:02:03  * AvianFluquit (Quit: Leaving)
03:14:31  * thlorenzjoined
03:15:56  * dshaw_joined
03:18:59  * thlorenzquit (Ping timeout: 245 seconds)
03:31:19  * dshaw_1joined
03:33:14  * dshaw_quit (Ping timeout: 272 seconds)
03:40:28  * brsonquit (Quit: leaving)
03:44:14  * a3fquit (Quit: ChatZilla 0.9.91.1 [Firefox 35.0/20150108202552])
03:59:53  * jreyno40joined
04:06:25  * rmgquit (Remote host closed the connection)
04:10:11  * thlorenzjoined
04:11:08  * Left_Turnquit (Remote host closed the connection)
04:12:07  * thlorenzquit (Read error: Connection reset by peer)
04:12:10  * thlorenz_joined
04:15:50  * thlorenz_quit (Remote host closed the connection)
04:36:52  * dshaw_1quit (Quit: Leaving.)
04:38:03  * dshaw_joined
04:38:16  * dshaw_quit (Client Quit)
04:39:19  * dshaw_joined
04:41:54  * jgijoined
04:54:39  * stagasquit (Ping timeout: 264 seconds)
05:04:22  * dshaw_quit (Quit: Leaving.)
05:06:57  * rmgjoined
05:11:57  * rmgquit (Ping timeout: 245 seconds)
05:28:24  * jgiquit (Quit: jgi)
05:33:57  * jgijoined
05:36:05  * AvianFlujoined
05:44:25  * a_lequit (Read error: Connection reset by peer)
05:44:55  * a_lejoined
05:52:38  * bajtosjoined
06:03:34  * jgiquit (Quit: jgi)
06:19:52  * dshaw_joined
06:22:32  * iarnaquit (Remote host closed the connection)
06:33:20  * iarnajoined
06:37:01  * SplinterOfChaosquit (Ping timeout: 255 seconds)
06:42:15  * ircretaryquit (Ping timeout: 252 seconds)
06:47:24  * reqsharkquit (Quit: Be back later ...)
06:47:51  * reqsharkjoined
06:48:29  * MI6quit (Ping timeout: 252 seconds)
06:49:23  * reqsharkquit (Read error: Connection reset by peer)
06:52:23  * reqsharkjoined
07:16:56  * iarnaquit (Remote host closed the connection)
07:47:47  * AvianFluquit (Ping timeout: 245 seconds)
07:52:28  * roxlujoined
07:57:41  * bajtosquit (Quit: bajtos)
08:20:15  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
08:33:08  * SergeiRNDjoined
08:42:00  * saghul_quit (Quit: leaving)
08:46:31  * saghuljoined
08:46:41  * jreyno40quit (Quit: jreyno40)
08:48:46  * dshaw_quit (Quit: Leaving.)
08:51:33  * roxlujoined
08:54:20  * bajtosjoined
09:30:34  * rendarjoined
09:53:01  * seishunjoined
10:13:00  * andrehjrjoined
10:14:22  * andrehjrquit (Client Quit)
10:17:46  * iarnajoined
10:22:22  * iarnaquit (Ping timeout: 272 seconds)
10:26:01  * bajtosquit (Quit: bajtos)
10:28:09  * abraxas_quit (Remote host closed the connection)
10:31:47  * tarrudajoined
10:34:49  * chris_99joined
10:36:14  * andrehjrjoined
10:43:50  * stagasjoined
10:47:39  * stagasquit (Read error: Connection reset by peer)
10:48:18  * stagasjoined
10:54:49  * SergeiRNDquit (Quit: Leaving.)
11:02:16  * seishunquit (Ping timeout: 272 seconds)
11:10:31  * indexzeroquit
11:10:41  * indexzerojoined
11:12:46  * bajtosjoined
11:20:49  * Left_Turnjoined
11:39:33  * SergeiRNDjoined
11:46:25  * davijoined
11:47:28  * Raynosquit
11:49:24  * tarrudaquit (Ping timeout: 245 seconds)
11:49:40  * Raynosjoined
12:07:15  * a3fjoined
12:16:57  * abraxas_joined
12:22:08  * abraxas_quit (Ping timeout: 264 seconds)
12:22:39  * rmgjoined
12:27:17  * rmgquit (Ping timeout: 252 seconds)
12:34:06  * stagasquit (Ping timeout: 276 seconds)
12:38:58  * tarrudajoined
12:41:28  <tarruda>What are possible causes for processes created by uv_spawn being left in <defunct> state after it exits?
12:51:24  * stagasjoined
13:09:37  * thlorenzjoined
13:10:41  <saghul>tarruda: is it possible that the process you spawned created more child processes which haven't died?
13:10:57  <tarruda>saghul: yes
13:11:01  <tarruda>hmmm
13:11:19  <tarruda>let me check if that is the case, thanks
13:13:34  <tarruda>saghul I dont think this is the case
13:13:42  <tarruda>due to the following facts:
13:13:53  <saghul>hum
13:14:00  * seishunjoined
13:14:19  <tarruda>If the process is started through another process, eg: valgrind or gdb, no defunct process are left
13:14:48  <saghul>this doesn't happen if the process reaps their childern properly, IIRC
13:14:57  <tarruda>if I add a `waitpid` call after the loop has exited(all handles closed + UV_RUN_DEFAULT returned) the defunct process goes away
13:15:31  <saghul>what happens if you create a SIGCHLD handler in libuv and keep it active?
13:16:18  <saghul>you can probably check with ps and see if there are active processes whose parent is the defunkt one
13:17:09  * thlorenzquit (Remote host closed the connection)
13:20:05  <tarruda>ok I just checked with pstree
13:20:10  <tarruda>there are no child processes
13:20:47  <tarruda>btw, here's the code I use to cleanup the child process: https://github.com/neovim/lua-client/blob/master/nvim/loop.c#L138-L157
13:21:13  <tarruda>the UV_RUN_DEFAULT call returns successfully, meaning no handles are active
13:21:24  <tarruda>at that point, the child process is still defunct
13:21:25  <tarruda>but
13:21:46  <tarruda>if I add a `waitpid` call after that
13:21:50  <tarruda>the defunct goes away
13:22:34  <saghul>do you unref the process handle by any chance?
13:23:22  <saghul>ah, I just saw the closing function, it looks ok
13:23:30  <tarruda>is there any way to unref other than calling `uv_unref`?
13:23:38  <saghul>nope
13:23:49  <tarruda>then no, I never unref the process
13:24:45  <saghul>I'm out of ideas, sorry :-/
13:25:01  <saghul>can you reproduce it with a libuv test case?
13:25:06  <tarruda>I will try
13:25:24  <saghul>tarruda: have a look at this: https://github.com/libuv/libuv/issues/154
13:25:29  <saghul>it sounds related
13:26:28  <tarruda>yes, that seems like so
13:26:31  <tarruda>I will try to reproduce
13:26:44  <tarruda>but I once read that a good solution to avoid zombies
13:26:49  <tarruda>is to double fork
13:27:09  <tarruda>if you double fork and exit the first child immediately
13:27:16  <tarruda>waiting for the first child status
13:27:25  <tarruda>there's no way the second child will become a zombie
13:27:50  <tarruda>perhaps that could be implemented by libuv?
13:28:29  <saghul>not sure, but feel free to open an issue or comment on that one!
13:30:22  * thlorenzjoined
13:38:15  * bajtosquit (Quit: bajtos)
13:50:43  * bajtosjoined
13:56:08  * [spoiler]joined
14:06:23  * abraxas_joined
14:10:04  * a_lequit (Read error: Connection reset by peer)
14:10:33  * a_lejoined
14:11:18  * abraxas_quit (Ping timeout: 265 seconds)
14:30:20  <tarruda>saghul: here's a way to reproduce the bug: https://github.com/libuv/libuv/issues/154#issuecomment-71200302
14:32:14  * chris_99quit (Quit: Ex-Chat)
14:34:38  * thlorenzquit (Remote host closed the connection)
14:41:09  * a_lequit (Remote host closed the connection)
14:47:30  * a_lejoined
14:49:45  * bretquit
14:50:01  * bretjoined
14:51:21  * SergeiRNDquit (Quit: Leaving.)
14:52:11  * a_lequit (Read error: Connection reset by peer)
14:53:18  * a_lejoined
15:07:21  * Fishrock123joined
15:07:58  * Guest60556changed nick to bengl
15:09:23  * daviquit (Ping timeout: 240 seconds)
15:16:34  * bajtosquit (Quit: bajtos)
15:21:20  * iarnajoined
15:23:27  * iarnaquit (Read error: Connection reset by peer)
15:23:59  * iarnajoined
15:27:06  * rmgjoined
15:30:31  * andrehjrquit (Quit: Computer has gone to sleep.)
15:31:35  * rmgquit (Ping timeout: 244 seconds)
15:31:54  * tarrudaquit (Ping timeout: 245 seconds)
15:35:29  * thlorenzjoined
15:40:39  * thlorenzquit (Ping timeout: 276 seconds)
15:47:56  * AvianFlujoined
15:51:28  * tarrudajoined
15:55:23  * abraxas_joined
15:59:57  * abraxas_quit (Ping timeout: 252 seconds)
16:01:00  * SplinterOfChaosjoined
16:01:07  * a_lequit (Remote host closed the connection)
16:05:32  * jcrugzzquit
16:05:37  * tarrudaquit (Quit: WeeChat 1.0.1)
16:05:50  * jcrugzzjoined
16:06:08  * booly-yam-1960joined
16:06:09  * booly-yam-1960quit (Remote host closed the connection)
16:07:45  * booly-yam-9623joined
16:09:59  * a_lejoined
16:17:47  * octetcloudjoined
16:24:41  * stagasquit (Ping timeout: 246 seconds)
16:27:17  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:31:56  * AlexisMochaquit (Read error: Connection reset by peer)
16:32:21  * a_lequit (Remote host closed the connection)
16:34:22  * a_lejoined
16:34:47  * brsonjoined
16:35:16  * a_lequit (Remote host closed the connection)
16:35:55  * a_lejoined
16:36:15  * thlorenzjoined
16:41:13  * thlorenzquit (Ping timeout: 245 seconds)
16:46:09  * SergeiRNDjoined
16:58:59  * chris_99joined
17:00:20  * a_lequit (Remote host closed the connection)
17:01:05  * a_lejoined
17:01:12  * rmgjoined
17:02:06  * SergeiRNDquit (Quit: Leaving.)
17:02:22  * dshaw_joined
17:09:42  * AvianFluquit (Ping timeout: 276 seconds)
17:11:59  * dap_joined
17:13:52  * bajtosjoined
17:19:55  * roxlujoined
17:21:52  * jgijoined
17:23:09  * stagasjoined
17:26:38  * Ralithquit (Ping timeout: 245 seconds)
17:28:09  * a_lequit (Remote host closed the connection)
17:28:59  * a_lejoined
17:29:34  * qard_joined
17:34:07  * dshaw_quit (Quit: Leaving.)
17:40:56  * a3fquit (Read error: Connection reset by peer)
17:44:06  * abraxas_joined
17:46:38  * booly-yam-9623quit (Ping timeout: 245 seconds)
17:46:58  * booly-yam-9623_joined
17:47:24  * thlorenzjoined
17:49:08  * abraxas_quit (Ping timeout: 264 seconds)
18:01:29  * AvianFlujoined
18:19:49  * Fishrock123quit (Remote host closed the connection)
18:22:31  * thlorenzquit (Remote host closed the connection)
18:32:09  * Fishrock123joined
18:35:40  * Ralithjoined
18:37:27  * dshaw_joined
18:42:27  <jgi>tjfontaine: regarding the issue with running node v0.12.x linux binaries with older libstdc++, I was able to build a node binary on CentOS 5.7 with gcc and g++ 4.4.7, and this binary works with the libstdc++ that ships with this version of CentOS
18:42:42  <jgi>tjfontaine: here’s my comment to a GH issue about this: https://github.com/joyent/node/issues/9079#issuecomment-71241906
18:43:05  <tjfontaine>looking
18:43:46  <tjfontaine>what
18:44:20  <tjfontaine>jgi: are you sure that is linking to the right patch?
18:44:40  <jgi>tjfontaine: yes
18:45:41  <tjfontaine>our use of the non-templated version of ReqWrap results in us linking against a symbol from a newer glibc?
18:46:24  <jgi>tjfontaine: no, our use of a newer compiler results in us linking against a symbol from a newer glibc
18:46:35  <jgi>tjfontaine: but to be able to build node with an older compiler, we need this patch
18:47:06  <tjfontaine>ok so just a symptom of somethign else entirely -- ok
18:50:19  <tjfontaine>I'm not sure if I was upgrading to a newer gcc/g++ because of current v0.12 or because of the c++ changes in newer v8
18:50:49  * thlorenzjoined
18:51:10  <jgi>tjfontaine: also, building with these olders compilers triggers a lot of additional warnings, and I haven’t had the time to go through all these
18:51:40  <tjfontaine>color me shocked.
18:51:44  <jgi>:)
18:52:07  * dshaw_quit (Quit: Leaving.)
18:52:42  <tjfontaine>[I prefer clang, we could turn on (one day) Werror and all the other fun flags)
18:52:44  <tjfontaine>]
18:55:35  * [spoiler]quit (Quit: I'm running to save my life!)
18:55:39  <tjfontaine>jgi: how does this ever work without those classes actually using the template type?
18:55:53  * [spoiler]joined
18:56:34  <jgi>tjfontaine: that is also what I wondered, but that’s probably because I haven’t been using C++ template everyday for a while now, definitely worth looking into though
18:56:59  <tjfontaine>jgi: I mean this is just pretty scary all the way around
18:57:07  <jgi>tjfontaine: it is
18:59:27  <tjfontaine>0000000100536b20 T __ZN4node10cares_wrap18GetAddrInfoReqWrapC1EPNS_11EnvironmentEN2v85LocalINS4_6ObjectEEE
18:59:30  <tjfontaine>0000000100536afa T __ZN4node10cares_wrap18GetAddrInfoReqWrapC2EPNS_11EnvironmentEN2v85LocalINS4_6ObjectEEE
19:01:53  * [spoiler]quit (Quit: WeeChat 1.1)
19:02:23  * [spoiler]joined
19:02:54  <jgi>tjfontaine: duplicated symbol?
19:03:19  <tjfontaine>I'm just looking at the symbols to figure out wtf is happening here
19:03:55  <tjfontaine>jgi: newer compilers must take the declaration template type and infer it for the actual definition
19:07:01  <tjfontaine>jgi: this is probably just a compiler bug, I don't think this is the reason why we went with newer g++ but in any event I'm glad you found it and that we'll be able to do saner things
19:11:03  * [spoiler]quit (Quit: WeeChat 1.1)
19:11:23  * [spoiler]joined
19:12:43  <jgi>tjfontaine: cool, I’m wondering how the change in toolchain would fit with the current release schedule. I’m primarily concerned by the impact on binary add-ons. Of course it should work fine, but I’d rather have evidence through testing than relying on my intuition
19:13:02  <jgi>tjfontaine: I would also like not to prevent users of 0.10.x running older platforms from running 0.12
19:13:18  <tjfontaine>the latter part is indeed important
19:13:26  <tjfontaine>and I don't expect many problems
19:13:44  <tjfontaine>but -- the fact that this has worked at all (wrt ABI) for node.js has mostly just been pure luck
19:15:07  * dshaw_joined
19:15:22  <jgi>tjfontaine: you mean the fact that binary add-ons worked although node 0.11.x requires a newer libstdc++ has been pure luck?
19:16:19  <tjfontaine>jgi: I mean the fact that binary addons work even though they're not using the same toolchain as what node was built with
19:17:00  <jgi>tjfontaine: ok
19:17:01  <tjfontaine>jgi: we build with g++ 4.8 currently, random user could be on clang bla-di-da -- subtle layout bugs ensue
19:17:07  <tjfontaine>or other g++
19:17:08  <jgi>yep
19:17:12  <tjfontaine>etc etc
19:17:49  <tjfontaine>gcc/g++ try and change in a bw compat way, but that doesn't mean they're forward compatible
19:17:52  <tjfontaine>anyway
19:18:12  <tjfontaine>so ideally we're building with as ancient of a compiler and libc and libstdc++ as we can stomach :<
19:18:29  <tjfontaine>on platforms where libc etc are built with the rest of the OS it's not a problem
19:18:46  <tjfontaine>OSX/AIX/SmartOS/Windows -- you just build on the oldest platform you want to support
19:18:55  <jgi>right
19:19:05  <tjfontaine>Linux/glibc/gcc like to give us all kinds of new and interesting problems
19:19:59  * [spoiler]quit (Quit: WeeChat 1.1)
19:23:16  * [spoiler]joined
19:23:34  * [spoiler]quit (Client Quit)
19:33:09  * abraxas_joined
19:36:33  * booly-yam-9623_quit (K-Lined)
19:37:22  * abraxas_quit (Ping timeout: 240 seconds)
19:45:37  * jgiquit (Quit: jgi)
19:47:15  * jgijoined
19:53:31  * importantshockjoined
20:19:22  * stagasquit (Ping timeout: 244 seconds)
20:21:46  * Tux64changed nick to Tux64_
20:22:28  * Tux64_changed nick to Tux64
20:25:28  * bajtosquit (Quit: bajtos)
20:27:47  * jgiquit (Quit: jgi)
20:47:03  <cjihrig>tjfontaine: ping
20:47:55  * dshaw_quit (Quit: Leaving.)
21:01:23  * dshaw_joined
21:12:17  <tjfontaine>cjihrig: pong
21:12:59  <cjihrig>tjfontaine: what do you want to do about the libuv update in https://github.com/joyent/node/pull/9050
21:13:47  <tjfontaine>I am in agreement with jgi on that ticket -- we're long in the tooth to upgrade libuv at this point
21:14:23  <cjihrig>so 12.1 milestone?
21:15:08  <tjfontaine>I don't think we'll be landing libuv 1.2 in v0.12, it will be in the 0.13 portion -- we historically have pinned to the minor version of the dependency we released with
21:16:11  <tjfontaine>even in libuv v0.10 they added an api/symbol during a patch release that we can't use in node
21:16:48  <cjihrig>ok. want me to add it to the 0.13 milestone?
21:17:21  <cjihrig>or even land it in master
21:17:49  <tjfontaine>cjihrig: yes, comment as such
21:18:16  <tjfontaine>cjihrig: I will do a merge of v0.10 -> v0.12 and then v0.12 -> master -- then it will be free to do the landing of that in master
21:18:17  <cjihrig>thanks!
21:19:30  * jgijoined
21:21:49  * abraxas_joined
21:23:42  <tjfontaine>cjihrig: running my tests for v0.12 and if it passes I'll push the merge, and then merge to master
21:23:54  <cjihrig>tjfontaine: cool
21:26:44  * abraxas_quit (Ping timeout: 272 seconds)
21:27:41  <tjfontaine>how is ts-fs-watch failing ...
21:28:23  <cjihrig>EMFILE?
21:29:00  <tjfontaine>that would be a new manifiestation for me on v0.12
21:29:32  <cjihrig>happens for me pretty regularly on my mac
21:29:42  <tjfontaine>EMFILE on v0.12?
21:29:56  <cjihrig>yea for fs-watch and fs-watch-recursive
21:30:17  <cjihrig>comes and goes depending on how many things i have open :-)
21:30:43  <tjfontaine>well, the manifestation of test-fs-watch failing for me at the moment is a hang
21:31:41  <cjihrig>ah. that's new to me
21:35:49  * dshaw_quit (Quit: Leaving.)
21:36:21  <jgi>tjfontaine, cjihrig: I haven’t seen that too
21:36:41  <tjfontaine>I'm blowing away the directory, re-cloning, and trying again
21:36:43  <tjfontaine>*something* is up
21:38:22  * AvianFluquit (Ping timeout: 255 seconds)
21:44:55  * andrehjrjoined
21:49:46  <saghul>tjfontaine: ohai
21:50:03  * MI6joined
21:50:24  <saghul>may I ask why you don't feel like landing uv 1.2 into node 0.12?
21:50:58  <saghul>we do the semver game now, so the only reason why we bumped the minor is because we added a couple of (minor) features
21:51:24  <saghul>there won't be any more 1.0 or 1.1 releases
21:56:42  <tjfontaine>saghul: this has nothing to do with semver, and everything to do with my ability to have confidence in what we release
21:57:12  <tjfontaine>saghul: we're trying to get v0.12 out in a week -- updating libuv now is the wrong way to feel confident in what we release, unless you know of show stopping bugs in libuv 1.0
21:57:56  <saghul>tjfontaine: not showstopping, but nothing major changed either
21:58:08  <tjfontaine>then even less reason for us to be considering it right now
21:58:12  <saghul>I left a comment on GH, there is regression which got fixed
21:58:20  * iarnaquit (Read error: Connection reset by peer)
21:58:37  <tjfontaine>then I/we will work on getting that back ported to v1.0
21:58:54  <tjfontaine>but increasing entropy doesn't help our goal of getting v0.12
21:58:59  * iarnajoined
21:59:17  <saghul>I'm just trying to help get the best libuv in, don't get me wrong :-)
21:59:53  <tjfontaine>sure, and I understand that -- I love being able to include the latest and greatest things, but for now I think the best thing for Node.js is to include what we know is working right now
22:00:42  <saghul>tjfontaine: I understand
22:01:10  <saghul>tjfontaine: if you are interested in having that issue fixed you can backport https://github.com/libuv/libuv/commit/393c1c59a27591d705648919b2d7fb921cba37bc
22:01:18  <saghul>the patch is really simple
22:01:48  <tjfontaine>this is probably also the issue with the debugger and stderr/stdout
22:02:15  <tjfontaine>or maybe
22:02:25  <saghul>does that use fds which are handed over to node?
22:02:33  <tjfontaine>there's something tweakign the blocking nature of some of our fds once we enable the debugger agent
22:02:44  <tjfontaine>which is a separate uv loop
22:03:15  <saghul>does that use any of the uv_*_open apis?
22:03:25  <saghul>if so, the fd had to be in non-blocking mode
22:03:30  <saghul>now libuv takes care of that
22:04:08  <tjfontaine>hang on looking at somethign from bert atm
22:04:16  <saghul>np
22:14:24  * lanceballchanged nick to lance|afk
22:14:50  * piscisaureusjoined
22:24:17  * importantshockquit (Remote host closed the connection)
22:28:41  <saghul>tjfontaine: gtg, but do ping me if you need anything for the release
22:28:52  <tjfontaine>saghul: thanks
22:31:53  * wolfeidauquit (Remote host closed the connection)
22:59:37  * plumbjoined
22:59:48  <plumb>i'm reading the github book about libuv and would like help to understand how non-blocking is achieved in a single thread main loop
22:59:56  <plumb>if a file is read this must block within the loop
23:00:01  <plumb>would someone explain how this would not block?
23:03:24  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:03:48  <tjfontaine>plumb: on the unicies file io is done in a threadpool, otherwise it uses the event system provided by the OS -- kqueue/event_ports/epoll
23:09:49  <plumb>tjfontaine: and so libuv relies on the OS which itself does use thread pool?
23:10:30  * abraxas_joined
23:10:41  <tjfontaine>plumb: no for files libuv manages its own threadpool (on unix)
23:11:02  <tjfontaine>plumb: for traditional network sockets, it relies on the os and the os doesn't use a thread pool
23:11:32  * iarnaquit (Remote host closed the connection)
23:12:37  * iarnajoined
23:14:40  <plumb>tjfontaine: thank you
23:15:24  * iarnaquit (Read error: Connection reset by peer)
23:15:39  * abraxas_quit (Ping timeout: 264 seconds)
23:15:56  * iarnajoined
23:17:11  <MI6>joyent/node: Timothy J Fontaine v0.10 * 6168fe6 : build: add win32 convenience build rule - http://git.io/4Mpy0g
23:18:59  * wolfeidaujoined
23:20:38  * wolfeidauquit (Remote host closed the connection)
23:21:08  * wolfeidaujoined
23:21:14  <jgi>tjfontaine, plumb: doesn’t libuv use a thread pool for file I/O on Windows too?
23:22:57  * Fishrock123changed nick to Fishrock|foods
23:23:43  * thlorenzquit (Remote host closed the connection)
23:23:44  <piscisaureus>plumb: jgi: libuv uses a thread pool for file i/o on all platforms
23:24:03  * iarnaquit (Remote host closed the connection)
23:24:19  <jgi>piscisaureus: yes, that was my understanding too
23:24:45  <piscisaureus>plumb: jgi: for socket io and some other things no thread pool action is necessary - libuv uses epol/kqueue on unix and i/o completion ports on windows to achieve async i/o
23:24:48  <tjfontaine>jgi: I only was commenting on what I knew for sure
23:25:53  <piscisaureus>plumb: jgi: there are situations in which the operating system (in the broad sense of the word; I'm thinking libaio) might use a thread pool. Libuv doesn't trigger them.
23:27:18  * iarnajoined
23:34:34  <jgi>piscisaureus: thanks for the additional info!
23:37:17  * seishunquit (Ping timeout: 265 seconds)
23:38:32  * seishunjoined
23:38:37  * thlorenzjoined
23:43:08  * thlorenzquit (Ping timeout: 264 seconds)
23:53:46  * iarnaquit (Remote host closed the connection)
23:53:52  * seishunquit (Ping timeout: 240 seconds)