15:33:16  * bajtosjoined
15:51:51  * piscisaureus_quit (Ping timeout: 240 seconds)
15:59:10  * brsonquit (Ping timeout: 245 seconds)
16:00:04  * kazuponjoined
16:03:29  * wavdedjoined
16:04:46  * brsonjoined
16:07:51  * kazuponquit (Remote host closed the connection)
16:13:07  * xakajoined
16:18:04  <wavded>How does a non-Node child process use the IPC channel setup by libuv? Are there any examples out there? I was able to get it working in C by directly referencing the file descriptor (using recv() and send()) but...
16:18:32  * groundwaterjoined
16:24:16  * bajtosquit (Quit: bajtos)
16:25:36  * hzquit
16:27:42  * amartensjoined
16:30:02  * ecrjoined
16:34:02  * zotpart
16:37:51  * kevinswiberjoined
16:38:12  * kazuponjoined
16:42:46  <bnoordhuis>wavded: on unices, it's just one half of a socketpair(AF_UNIX) pair. on windows, it's complicated
16:42:50  * csaohquit (Quit: csaoh)
16:47:30  * kazuponquit (Ping timeout: 245 seconds)
16:59:39  <wavded>bnoordhuis: socketpair(AF_UNIX, SOCK_STREAM, 0, sockets) seems to create two channels (4 and 5), was expecting it to recognize 3 (since that was the "ipc" channel set on stdio for the parent)
16:59:52  * jmar777quit (Read error: Connection reset by peer)
17:00:17  * jmar777joined
17:01:13  * TooTallNatejoined
17:01:52  * AvianFluquit (Remote host closed the connection)
17:05:22  * bajtosjoined
17:10:06  * bnoordhuisquit (Ping timeout: 264 seconds)
17:11:40  * bajtosquit (Ping timeout: 245 seconds)
17:12:13  * AvianFlujoined
17:12:45  * wwicksjoined
17:16:58  <indutny>hey people
17:18:11  <trevnorris>indutny: sup
17:18:40  <indutny>good
17:18:42  <indutny>how are you?
17:18:56  <trevnorris>not bad. getting ready to fly back tomorrow morning
17:20:55  <indutny>kewl
17:21:55  * AvianFluquit (Remote host closed the connection)
17:23:08  <othiym23>trevnorris: how'd your talk go?
17:25:26  <trevnorris>othiym23: think it went well. my slides are on http://trevnorris.github.io/nodeconf.eu
17:25:32  <trevnorris>they recorded all of them
17:25:41  <trevnorris>so guess I can go back and cringe watching myself
17:26:00  <othiym23>noooo don't do it
17:26:10  <othiym23>I never watch my own presentations
17:26:29  <othiym23>due to the "who is that asshole?" effect
17:26:37  <othiym23>although I probably should, if only to get better
17:28:12  <TooTallNate>indutny: hey
17:28:17  <indutny>hi
17:28:42  <trevnorris>heh, yeah.
17:28:50  <TooTallNate>indutny: did you see https://github.com/joyent/node/issues/6204 ?
17:28:57  <indutny>yes, I did
17:29:12  <indutny>I'll look into it
17:29:20  <indutny>doing some important stuff for voxer right now
17:29:33  <TooTallNate>cool, sounds good, thanks man
17:29:37  * bnoordhuisjoined
17:35:48  * tuxie_joined
17:36:09  <bnoordhuis>wavded: a socketpair is basically a pipe, only the file descriptors are bidirectional rather than unidirectional
17:36:45  <bnoordhuis>node hands off one to the child and keeps the other
17:40:32  <wavded>bnoordhuis: gotcha, thx! i was confused thinking the child had something to do with socketpair, but that's already setup
17:41:55  * st_lukejoined
17:42:29  * indexzerojoined
17:43:35  * kazuponjoined
17:48:46  * kazuponquit (Ping timeout: 256 seconds)
17:50:28  * bnoordhuisquit (Ping timeout: 256 seconds)
17:53:42  <MI6>libuv-master: #236 UNSTABLE windows (4/195) smartos (10/194) http://jenkins.nodejs.org/job/libuv-master/236/
18:05:12  * tuxie_quit (Ping timeout: 256 seconds)
18:06:58  <MI6>libuv-node-integration: #221 UNSTABLE smartos-ia32 (1/639) linux-ia32 (1/639) smartos-x64 (5/639) http://jenkins.nodejs.org/job/libuv-node-integration/221/
18:07:58  * bajtosjoined
18:23:30  * pfox__quit (Ping timeout: 264 seconds)
18:24:28  * indexzeroquit (Quit: indexzero)
18:25:36  <othiym23>trevnorris: those slides are rad, love all the perf numbers
18:32:16  * AvianFlujoined
18:33:27  * qardjoined
18:37:04  * AvianFluquit (Ping timeout: 264 seconds)
18:37:27  * bnoordhuisjoined
18:38:02  * bajtosquit (Quit: bajtos)
18:40:30  * bajtosjoined
18:45:07  * kazuponjoined
18:45:17  <MI6>nodejs-master-windows: #343 UNSTABLE windows-x64 (20/639) windows-ia32 (20/639) http://jenkins.nodejs.org/job/nodejs-master-windows/343/
18:50:11  * kazuponquit (Ping timeout: 268 seconds)
19:03:42  * EhevuTovjoined
19:08:45  * groundwaterquit (Ping timeout: 245 seconds)
19:13:50  * st_lukequit (Remote host closed the connection)
19:17:04  * indexzerojoined
19:18:32  * hzjoined
19:30:22  * kevinswiberquit (Remote host closed the connection)
19:31:08  * AvianFlujoined
19:36:12  * AvianFluquit (Remote host closed the connection)
19:36:14  * bajtosquit (Quit: bajtos)
19:42:58  * groundwaterjoined
19:44:21  * defunctzombie_zzchanged nick to defunctzombie
19:45:40  * kazuponjoined
19:49:27  <indutny>TooTallNate: figured out source of the problem
19:49:30  <indutny>TooTallNate: working on the fix
19:49:37  <TooTallNate>indutny: awesome!
19:49:47  <TooTallNate>indutny: is the segfault a symptom of the same issue?
19:50:01  <indutny>well, perhaps yes
19:50:11  <indutny>I'm thinking about the best way to fix it
19:50:17  <indutny>honestly, it should not really work
19:50:21  <indutny>at all :)
19:50:33  <indutny>but I'd like to work it out anyway
19:50:37  * kazuponquit (Ping timeout: 268 seconds)
19:53:47  * kevinswiberjoined
19:55:29  <TooTallNate>indutny: why should it not work?
19:55:39  <indutny>well, because its not supported :)
19:55:46  <indutny>it was supposed to be a one-way ticket
19:55:52  <indutny>creating TLS socket from TCP one
19:56:10  <indutny>i.e. you can't make it work as a TCP one after it
19:56:20  <indutny>and I'm not even talking about creating another TLS socket from it
19:56:54  <TooTallNate>i don't really get what you mean
19:57:05  <indutny>well, its a low-level twerking in the core
19:57:14  <indutny>and in v0.11
19:57:28  <indutny>we've moved all that stuff into C++
19:57:40  * st_lukejoined
19:57:47  <indutny>i.e. TCP read callbacks are happening in C++
19:57:56  <indutny>and reads are happening right into OpenSSL's buffers
19:58:24  <MI6>joyent/libuv: bnoordhuis created branch jenkins-review - http://git.io/gPrqRg
19:58:47  <TooTallNate>indutny: so is the problem that openssl doesn't like trying to encrypt from its own buffers?
19:58:56  <indutny>wait
19:59:01  <indutny>oh gosh
19:59:10  <indutny>don't tell me its an encryption inside of the encryption
19:59:26  <indutny>I just figured that out
19:59:27  <bnoordhuis>that's like double rot13. double the security!
19:59:34  <indutny>oh god
20:00:11  <indutny>bnoordhuis: do we really want to support it?
20:00:22  <indutny>I need your opinion on it
20:00:33  * wavdedquit (Quit: Hasta la pasta)
20:01:56  <saghul>encript-ception
20:02:59  * julianduquejoined
20:03:11  <MI6>libuv-review: #68 FAILURE linux-x64 (1/194) smartos-ia32 (2/194) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-review/68/
20:04:33  <bnoordhuis>indutny: what? double rot13? you can't create a secure webapp without it
20:04:42  <indutny>gosh
20:04:47  <indutny>don't do it again:)
20:04:50  <bnoordhuis>haha
20:04:59  <indutny>some of your jokes are getting quite old
20:05:06  <indutny>and that is optimistic
20:05:09  <indutny>sentence
20:05:12  <bnoordhuis>the strength is in repetition
20:05:12  <indutny>:)
20:05:27  <bnoordhuis>also, if double rot13 ever gets broken, we'll switch to quadruple rot13
20:05:47  <bnoordhuis>okay, back on topic - do we want to support what?
20:05:59  <indutny>wrapping TLSSocket in TLSSocket
20:06:00  <indutny>i.e.
20:06:06  <indutny>making TLSSocket running inside TLSSocket
20:06:11  <indutny>not upon TCP
20:06:20  <indutny>sounds possible, but a bit ...
20:06:22  <indutny>complicated
20:06:30  <indutny>considering that we're just replacing callbacks on socket right now
20:06:41  <indutny>I mean, I can do it for sure
20:06:47  <indutny>but at what price :)
20:06:55  <indutny>storing reference to previous wrapper
20:07:03  <bnoordhuis>does that work in v0.10?
20:07:17  <bnoordhuis>i assume this is in the context of TooTallNate's test case, right?
20:07:55  <indutny>yes, it does
20:08:02  <indutny>bnoordhuis: yes, exactly that test case
20:08:27  <bnoordhuis>it seems kind of pointless. is there a legitimate use case?
20:09:33  <MI6>joyent/libuv: Ben Noordhuis jenkins-review * 05822a5 : unix: wrap long lines at 80 columns (+1 more commits) - http://git.io/8R6tVQ
20:09:43  * mpotrajoined
20:09:50  <indutny>TooTallNate: ?
20:09:56  <indutny>TooTallNate: is there any real use case for it?
20:10:29  <TooTallNate>indutny: i'm connecting to a proxy server over TLS, which in turn connects to another TLS server (*not* over tls though)
20:10:45  <indutny>hm...
20:10:52  <TooTallNate>indutny: the end client is the one supposed to do the TLS to the destination server
20:10:53  <indutny>wait, that's not what your example does
20:11:03  <indutny>you're creating tls connection
20:11:12  <indutny>and then asking another tls connection to reuse socket
20:11:18  <mpotra>hello everyone. Does anyone have any idea why I get node: symbol lookup error: /code/itmr/trunk/src/iwatch/build/Release/iwatch.node: undefined symbol: uv_poll_init in my nodejs (v0.11.7 / centos 6 64bit) C++ addon?
20:11:51  <indutny>TooTallNate: right?
20:12:20  <TooTallNate>indutny: no, not reuse, initiate an enitrely new TLS session
20:12:24  <TooTallNate>over the existing TLS socket
20:12:28  <TooTallNate>so it's 2 layers of TLS
20:12:29  <indutny>inside another TLS session
20:12:32  <TooTallNate>on the client
20:12:35  <indutny>yeah, that's what I was talking about
20:12:42  <indutny>its a bit complicated to implement
20:12:47  <indutny>do you really need it?
20:12:49  <bnoordhuis>mpotra: hrm, that should work. is there a uv_poll_init symbol in the node binary?
20:12:55  <TooTallNate>indutny: it worked before
20:13:01  <indutny>mpotra: nm node | grep uv_poll_init
20:13:04  <indutny>TooTallNate: yeah, but its faster now
20:13:12  <indutny>TooTallNate: though, with some sacrifices
20:13:17  <indutny>TooTallNate: like compatibility
20:13:20  <indutny>;)
20:13:21  <TooTallNate>:\
20:13:28  <indutny>I don't mean its impossible
20:13:42  <TooTallNate>indutny: at this point it's a regression though
20:13:48  <TooTallNate>people don't like regressions
20:13:48  <bnoordhuis>mpotra: btw, `nm path/to/node | grep uv_poll_init` will tell you
20:13:52  <indutny>TooTallNate: I can make it not crash
20:14:01  <bnoordhuis>oh, indutny already said that
20:14:06  <indutny>TooTallNate: and if its justified - I'll implement layering
20:14:10  <MI6>libuv-review: #69 UNSTABLE linux-x64 (9/194) smartos-ia32 (2/194) smartos-x64 (2/194) windows-ia32 (3/195) linux-ia32 (9/194) windows-x64 (3/195) http://jenkins.nodejs.org/job/libuv-review/69/
20:14:21  <TooTallNate>indutny: my use case is proxy servers...
20:14:33  <TooTallNate>indutny: i'll let you decide if that's worth it or not ;)
20:14:36  <indutny>why do you need to encrypt it twice? :)
20:14:47  <indutny>and not open another tls connection
20:14:55  <indutny>from proxying server
20:14:58  <indutny>err
20:15:01  <indutny>from proxy server
20:15:07  <TooTallNate>indutny: cause then the proxy server see's the clear-text data of the client
20:15:07  <indutny>that's what people usually do
20:15:09  <TooTallNate>which is bad
20:15:14  <indutny>TooTallNate: oh god
20:15:36  <indutny>TooTallNate: ok, I'll try to figure it out
20:15:54  <TooTallNate>indutny: :) thanks
20:15:58  <mpotra>bnoordhuis indutny: apparently in the build from the latest src (v0.11.7) there isn't, only 00000000006e3380 T uv_poll_init_socket
20:16:03  <TooTallNate>indutny: i'll owe you a beer next time we meet ;)
20:16:12  <indutny>TooTallNate: haha, you already owe me some beers
20:16:16  <MI6>joyent/libuv: Ben Noordhuis master * 05822a5 : unix: wrap long lines at 80 columns (+1 more commits) - http://git.io/j6PVvQ
20:16:16  <TooTallNate>i know :p
20:16:20  <indutny>and I'll probably give all mine to bnoordhuis
20:16:26  <TooTallNate>hahahah
20:16:30  <TooTallNate>indutny: vodka?
20:16:51  <bnoordhuis>mpotra: hrm, that's weird. how did you configure/build it?
20:16:51  <indutny>well, not really :)
20:17:28  <bnoordhuis>mpotra: for comparison, my HEAD-of-master build has both uv_poll_init and uv_poll_init_socket in the text section
20:17:29  <mpotra>bnoordhuis: git clone / checkout v0.11.7 / ./configure && make && make install
20:18:09  <bnoordhuis>mpotra: what do g++ -v and ld -v print?
20:18:36  <mpotra>ld -v GNU ld version 2.20.51.0.2-5.36.el6 20100205
20:18:50  <mpotra>Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enab
20:19:19  <mpotra> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
20:19:30  <bnoordhuis>okay, that's not terribly old
20:19:52  <bnoordhuis>can you try `node-gyp --nodedir /path/to/0.11 rebuild?`
20:20:11  <bnoordhuis>oh, and maybe do a `git clean -dfx` first
20:20:38  <mpotra>I already did node-gyp install to get the latest node src, and I always node-gyp rebuild
20:21:32  <mpotra>bnoordhuis: ok, I'll just rebuild node and check again if uv_poll_init is missing
20:21:49  <MI6>libuv-master: #237 UNSTABLE windows (4/195) smartos (9/194) http://jenkins.nodejs.org/job/libuv-master/237/
20:22:16  <bnoordhuis>mpotra: the --nodedir switch is make sure it rebuilds against your local copy
20:22:46  <MI6>libuv-master-gyp: #175 UNSTABLE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (3/195) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/175/
20:34:55  * jmar777quit (Remote host closed the connection)
20:35:04  <MI6>libuv-node-integration: #222 UNSTABLE smartos-ia32 (1/639) smartos-x64 (6/639) linux-x64 (1/639) http://jenkins.nodejs.org/job/libuv-node-integration/222/
20:45:13  <mpotra>bnoordhuis: clean it up and rebuilt node v0.11.7
20:45:24  <mpotra>again no uv_poll_init symbol
20:46:01  <mpotra>only uv_poll_init_socket
20:46:15  * kazuponjoined
20:50:55  * kazuponquit (Ping timeout: 260 seconds)
20:52:56  * groundwaterquit (Quit: groundwater)
20:53:04  <qard>Anyone with a deep understanding of the domains internals know what differences there are in rethrowing from a domain error event handler? Like this; https://gist.github.com/Qard/6b485f7c83f8cad57f46
20:53:46  <bnoordhuis>mpotra: weird. what happens when you add `__attribute__((visibility("default"))) void* x = (void*) uv_poll_init` at the top of src/node_main.cc, right below the #include "node.h"?
20:54:19  <bnoordhuis>i suspect your compiler or linker is stripping code it considers dead
21:02:50  * hzquit
21:15:55  <mpotra>bnoordhuis: just tried it, still didn't work
21:16:11  <mpotra>furthermore, I looked for the other uv_poll symbols
21:16:30  <mpotra>and only uv_poll_init_socket and uv_poll_start are present
21:24:12  <bnoordhuis>mpotra: what does `nm out/Release/node | grep -E ' uv_' | wc -l` print?
21:24:51  <mpotra>bnoordhuis: 261
21:27:25  <bnoordhuis>mpotra: you're missing a lot of symbols. there should be over 300
21:27:45  <bnoordhuis>do you have CFLAGS or CXXFLAGS set in your environment?
21:28:10  <bnoordhuis>also, can you print the output of `ldd out/Release/node`?
21:28:38  <mpotra>no CFLAGS / CXXFLAGS set in the env
21:29:00  <mpotra>I also build v0.10.6 with prefix
21:29:23  <mpotra>sorry, I meant v0.10.18
21:29:30  <mpotra>and that one has it
21:29:52  <bnoordhuis>okay. what does ldd print?
21:29:58  <mpotra>linux-vdso.so.1 => (0x00007fffbefcc000) libdl.so.2 => /lib64/libdl.so.2 (0x00000033d7e00000) librt.so.1 => /lib64/librt.so.1 (0x00000033d9600000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000033da600000) libm.so.6 => /lib64/libm.so.6 (0x00000033d8600000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000033da200000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000033d8a00000)
21:30:09  <bnoordhuis>looks okay
21:30:48  <bnoordhuis>can you try this? delete out/Release/obj/src, then make V=1 and gist the output?
21:31:05  <bnoordhuis>i'd like to see what flags are being passed to your compiler and linker
21:31:14  <mpotra>sure, just a sec
21:31:28  * tuxie_joined
21:33:39  <mpotra>hmm, there's only 'gen' dir in out/Release/obj ?
21:34:14  * xakaquit
21:34:34  <bnoordhuis>oh, right. i use ninja to build, not make
21:34:48  <mpotra>out/Release/obj.target/node/src ?
21:34:53  <bnoordhuis>yes, that's the one
21:37:37  <mpotra>here it is https://gist.github.com/mpotra/6530123
21:39:07  <bnoordhuis>mpotra: i bet that if you remove -Wl,--gc-sections, it'll work
21:39:25  <bnoordhuis>you can run make with `make LINK=that_really_long_line_at_the_bottom`
21:39:46  <bnoordhuis>rm out/Release/node first, else it won't do anything of course :)
21:41:26  * austoquit (Quit: Leaving)
21:46:54  * kazuponjoined
21:51:16  * kazuponquit (Ping timeout: 245 seconds)
21:57:54  <mpotra>still waiting for it to compile. wouldn't it also work if I were to empty the 'ldflags': [ '-Wl, --gc-sections'] property in common.gypi ?
22:00:59  <othiym23>qard: throwing from the domain error handler is going to result in Bad Things
22:01:07  * CoverSlidejoined
22:01:18  <othiym23>qard: and it will do different Bad Things in 0.8 and 0.10 (and probably 0.12)
22:01:30  * Kakeraquit (Ping timeout: 256 seconds)
22:03:14  * kevinswiberquit (Remote host closed the connection)
22:05:03  * tuxie_quit (Ping timeout: 276 seconds)
22:05:41  <othiym23>qard: under 0.10, what it *looks* li8ke is happening is that the original Error that triggered the domain causes the app to crash
22:05:42  * kazuponjoined
22:05:58  <othiym23>i.e. the thing thrown from the domain handler gets swallowed
22:09:02  <qard>The intended behaviour is for it to behave like the domain wasn't there. So NOT preventing process death or anything.
22:09:28  <mpotra>bnoordhuis: you were right. it worked, 309 symbols now including uv_poll_init
22:09:51  <qard>Looks like connect has an annoying try/catch that intercepts non-async stuff before it can hit the domain though. :(
22:10:35  <mpotra>bnoordhuis: many thanks! If you ever pass through Cluj-Napoca, Romania, I'll repay you for your time with a six pack of beer...or just send it to you on Christmas :-D
22:11:49  <bnoordhuis>mpotra: no problem, glad it works now :)
22:16:03  * EhevuTovquit (Quit: This computer has gone to sleep)
22:17:33  * bradleymeckquit (Quit: bradleymeck)
22:22:48  * wolfeidaujoined
22:27:53  * CoverSlidequit (Quit: Lost terminal)
22:29:45  <othiym23>qard: app.use(function (req, res, next) { var d = d.create(); d.on('error', next); d.run(next); });
22:30:02  <othiym23>oops *var d = domain.create()
22:30:59  <othiym23>put that at the head of your middleware chain, put the default error handler or your own at the tail, that'll deal with connect's domain-wrapping
22:45:02  * EhevuTovjoined
22:58:58  * mpotraquit
22:59:46  * defunctzombiechanged nick to defunctzombie_zz
22:59:58  * c4miloquit (Remote host closed the connection)
23:01:00  * defunctzombie_zzchanged nick to defunctzombie
23:04:00  * kazuponquit (Remote host closed the connection)
23:09:14  * defunctzombiechanged nick to defunctzombie_zz
23:12:19  * kazuponjoined
23:27:32  * kevinswiberjoined
23:28:20  * c4milojoined
23:29:12  * c4miloquit (Remote host closed the connection)
23:29:20  * c4milojoined
23:30:25  * inolenquit (Ping timeout: 240 seconds)
23:33:49  * inolenjoined
23:56:17  * xakajoined
23:59:16  * ecrquit (Quit: ecr)
23:59:52  <MI6>libuv-master-gyp: #176 UNSTABLE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (4/195) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/176/