00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:05:34  * loladiroquit (Ping timeout: 256 seconds)
00:08:11  * mralephquit (Ping timeout: 246 seconds)
00:18:36  * dominictarrquit (Quit: dominictarr)
00:20:41  * julianduquejoined
00:26:24  * julianduquequit (Ping timeout: 240 seconds)
00:27:15  * qardquit (Quit: Leaving.)
00:37:47  * mikolalysenkoquit (Quit: Lost terminal)
00:38:22  * dominictarrjoined
00:39:43  * defunctzombie_zzchanged nick to defunctzombie
00:40:46  * mralephjoined
00:41:26  * wavdedjoined
00:41:29  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:44:33  * julianduquejoined
00:48:39  * dominictarrquit (Quit: dominictarr)
00:49:11  * defunctzombiechanged nick to defunctzombie_zz
00:49:31  * amartensquit (Quit: Leaving.)
00:52:58  * dominictarrjoined
00:56:41  * kazuponjoined
07:46:04  * juliangruberjoined
07:57:36  * kazuponquit (Remote host closed the connection)
08:18:30  * amartensjoined
08:24:22  <indutny>hey people
08:26:18  * kazuponjoined
08:29:05  * loladiroquit (Quit: loladiro)
09:19:00  * amartensquit (Quit: Leaving.)
09:52:27  * _appujoined
09:53:48  <_appu>Hey guys, I have a small problem when using QUEUE. See the code http://pastebin.com/B20t73C5
09:54:19  <_appu>when reading values using QUEUE_DATA, it is not printing the proper values. Wondering why..
09:58:14  * timoxleyquit (Ping timeout: 246 seconds)
10:01:31  * kazuponquit (Remote host closed the connection)
10:07:45  * dominictarrquit (Quit: dominictarr)
10:08:22  <indutny>_appu: wq is not what you'ree looking for
10:08:37  <indutny>you should try reading data from QUEUE_HEAD of wq
10:24:15  * bajtosquit (Quit: bajtos)
10:26:17  * abraxasquit (Remote host closed the connection)
10:31:51  * hzjoined
10:34:13  * kazuponjoined
10:37:08  * csaohquit (Quit: csaoh)
10:38:11  * csaohjoined
10:46:37  * mralephjoined
10:46:39  * mraleph1quit (Read error: Connection reset by peer)
10:51:20  * csaohquit (Quit: csaoh)
11:00:26  * csaohjoined
11:04:09  * bnoordhuisjoined
11:17:06  * kazuponquit (Remote host closed the connection)
11:21:40  <bnoordhuis>and now for something completely trivial and obscure: sizeof(long double) == 12 on x86
11:21:54  * `3rdEdenchanged nick to `3E|BRB
11:23:05  * julianduquejoined
11:31:05  <indutny>hahahah
11:31:08  <indutny>80bits
11:31:11  <indutny>yeah, its ok
11:31:35  <indutny>bnoordhuis: there're even oddier sizes
11:31:43  <indutny>160bits
11:32:10  <indutny>ah wait
11:32:11  <indutny>no
11:37:06  <_appu>indutny: thanks. that worked
11:39:38  <indutny>you're welcome
11:53:26  <indutny>bnoordhuis: http://www.raspberrypi.org/archives/4300
11:53:37  <indutny>bnoordhuis: also https://github.com/joyent/node/pull/5784
11:53:44  <indutny>bnoordhuis: and https://github.com/joyent/node/pull/5755
11:53:47  <indutny>review, please?
11:58:44  * kazuponjoined
12:09:37  * _appuquit (Ping timeout: 250 seconds)
12:10:26  <bnoordhuis>indutny: looking
12:13:56  <indutny>thanks
12:16:00  <MI6>joyent/node: Fedor Indutny master * 07fbb43 : tls: export TLSSocket - http://git.io/jEz7Lg
12:16:18  <indutny>bnoordhuis: thanks
12:17:06  <MI6>joyent/node: Fedor Indutny master * c1db1ec : crypto: fix memory leak in LoadPKCS12 - http://git.io/x-vvWQ
12:25:11  * kazuponquit (Remote host closed the connection)
12:27:09  <MI6>nodejs-master: #280 UNSTABLE smartos-ia32 (1/609) osx-x64 (1/609) smartos-x64 (4/609) http://jenkins.nodejs.org/job/nodejs-master/280/
12:34:58  * rendar_joined
12:36:28  * rendarquit (Ping timeout: 246 seconds)
12:38:56  <MI6>nodejs-master-windows: #89 UNSTABLE windows-x64 (16/609) windows-ia32 (16/609) http://jenkins.nodejs.org/job/nodejs-master-windows/89/
12:50:41  * `3E|BRBchanged nick to `3rdEden
12:54:41  * AvianFlujoined
13:02:37  * kazuponjoined
13:08:54  * jmar777joined
13:18:28  * stagasquit (Ping timeout: 252 seconds)
13:30:12  * c4milojoined
13:30:46  * timoxleyjoined
13:35:09  * julianduquequit (Ping timeout: 256 seconds)
13:44:01  * AvianFlu_joined
13:45:58  * AvianFluquit (Ping timeout: 245 seconds)
13:46:56  * c4miloquit (Remote host closed the connection)
13:53:59  * mikealquit (Quit: Leaving.)
13:59:37  * julianduquejoined
14:04:41  * kazuponquit (Remote host closed the connection)
14:25:20  * bajtosjoined
14:35:03  * kazuponjoined
14:39:45  * pachetjoined
14:43:09  * kazuponquit (Ping timeout: 246 seconds)
14:43:15  * dapjoined
14:44:27  * appu_joined
14:45:50  * wolfeidauquit (Read error: Connection refused)
15:03:31  * M28_joined
15:03:47  <M28_>oh I'm surprised this channel exists... good
15:03:50  * M28_changed nick to M28
15:04:20  <M28>could someone clarify for me the args for uv_write?
15:04:48  <M28>the first arg can be any uninitialized uv_write_t*, right?
15:05:30  <M28>for a tcp socket, I just grab the uv_tcp_t* and cast it to a uv_stream_t*
15:05:52  <M28>the third arg are the buffers, fourth the number of buffers and fifth the callback
15:06:03  <M28>but it's giving me an illegal access error
15:06:15  * julianduquequit (Ping timeout: 246 seconds)
15:06:24  <M28>I'm calling uv_write as soon as I get the connect callback
15:06:40  * julianduquejoined
15:08:30  * bnoordhuisquit (Ping timeout: 264 seconds)
15:08:52  <M28>(just highlight me if anyone answers)
15:10:05  * defunctzombie_zzchanged nick to defunctzombie
15:14:24  <tjfontaine>M28: fwiw, it helps if you provide a gist or some other way to review
15:15:29  <M28>here it is
15:15:29  <M28>https://gist.github.com/Matheus28/5919190
15:16:42  * kazuponjoined
15:17:17  <M28>the server receives the message
15:17:19  <tjfontaine>https://gist.github.com/Matheus28/5919190#file-gistfile1-cpp-L28 is what you're asking about?
15:17:30  <M28>yeah
15:18:40  <M28>oh goddamn
15:18:49  <M28>I'm dumb
15:18:57  <M28>uh
15:19:12  <M28>I was passing a literal to that function... and it tried to free it
15:19:35  <M28>I haven't slept in 20 hours, forgive me
15:19:52  <tjfontaine>mk
15:20:19  <tjfontaine>ya that (const uint8_t) isn't going to make you happy :)
15:22:30  <M28>okay, I fixed that and it's still crashing with the same thing, so it's happening before it calls the callback
15:22:53  <M28>https://gist.github.com/Matheus28/5919190
15:22:55  * jmar777quit (Remote host closed the connection)
15:23:29  * jmar777joined
15:26:13  * appu_quit (Quit: appu_)
15:28:12  * jmar777quit (Ping timeout: 256 seconds)
15:28:40  * julianduquequit (Ping timeout: 246 seconds)
15:30:18  * julianduquejoined
15:31:04  <mmalecki>tjfontaine: I made node go ~200 req/s faster I think
15:31:32  <mmalecki>tjfontaine: but need help benchmarking, to make sure it's not It's Fast On My Machine (tm)
15:32:12  <tjfontaine>heh ok
15:32:39  <mmalecki>tjfontaine: it's mmalecki/node, branch prototypes
15:33:03  <mmalecki>I'll be pushing more to test it out on Sockets, but I don't think it'll matter *that* much, sockets are more long-lived
15:33:26  <tjfontaine>interesting
15:34:02  * AvianFlu_changed nick to AvianFlu
15:35:29  * julianduquequit (Ping timeout: 248 seconds)
15:35:49  * roxlupart
15:40:31  * julianduquejoined
15:40:41  <tjfontaine>mmalecki: running benchmark/compare now
15:41:19  <mmalecki>tjfontaine: thank you :-)
15:41:34  * qardjoined
15:41:36  <tjfontaine>:)
15:42:18  <mmalecki>tjfontaine: do I get flowers if I make node faster?
15:42:42  <mmalecki>is that how it works in general?
15:43:34  <tjfontaine>mmalecki: flowers or a bottle of your favorite refreshment
15:44:08  <mmalecki>I'd take Arizona Iced Tea, please.
15:44:13  <tjfontaine>hehe
15:44:14  <mmalecki>you can't get this shit in Poland
15:44:21  * loladirojoined
15:45:05  * AvianFluquit (Remote host closed the connection)
15:46:09  * julianduquequit (Ping timeout: 246 seconds)
15:47:33  * julianduquejoined
15:47:35  <tjfontaine>man I hope I did them in the right order, that would be unfortunate
15:48:50  <mmalecki>yeah, that was my fear as well. I kept track of my git checkouts tho!
15:48:54  <mmalecki>is it any faster for you?
15:49:03  * kazuponquit (Remote host closed the connection)
15:49:39  <tjfontaine>still waiting on it to finish, benchmark/compare.js <one node executable> <another node executable>
15:49:55  <mmalecki>oh, heh. didn't know about this one. let me look
15:50:11  <tjfontaine>I never remember which order so that the percentages end up in + land
15:50:20  <tjfontaine>NODE_BENCH=bench-http node benchmark/compare.js ./node-clean ./node
15:50:24  <tjfontaine>more specifically
15:50:52  * pachetquit (Quit: leaving)
15:54:48  * timoxleyquit (Quit: Computer has gone to sleep.)
15:55:54  * mikealjoined
15:56:10  <kellabyte>does libuv provide any timer like primitive?
15:56:20  <mmalecki>uv_timer, kellabyte
15:56:21  <tjfontaine>indeed it does
15:56:25  <mmalecki>uv_timer_start
15:56:35  <mmalecki>uv_timer_t is the struct
15:56:39  <kellabyte>sweet!
15:56:58  <tjfontaine>utoh
15:56:59  <tjfontaine>trevnorris: "Making 5000 requests to\n 8 threads and 100 connections\n Thread Stats Avg Stdev Max +/- Stdev\n Latency 4803839 384307168 30744573 98.44%\n Req/Sec 0.00 0.00 0.00 100.00%\n 5000 requests in 307445734490.26m, 625.58MB read\nRequests/sec: 0.00\nTransfer/sec: 0.00B\n"
15:57:00  <mmalecki>ke http://nikhilm.github.io/uvbook/utilities.html#timers
15:57:04  <tjfontaine>wrk produced strange output
15:57:07  <tjfontaine>child process exited with code 1
15:57:25  <mmalecki>kellabyte: http://nikhilm.github.io/uvbook/utilities.html#timers
15:57:26  <kellabyte>does uv_timer fire on a new thread or in the eventloop? wondering if I need to lock modified stuff
15:57:45  <mmalecki>tjfontaine: hmm, just a usual benchmark worked for me with this branch
15:57:52  <mmalecki>I'll see what compare returns
15:58:10  <M28>tjfontaine: The problem was that uv_write expects a uv_connect_t, not just any uv_write_t... I wish that was documented somewhere >_>
15:58:28  <tjfontaine>mmalecki: well it was working but then died, that's unfortunate
15:58:28  * Kjerskipart ("Leaving")
15:59:00  <tjfontaine>kellabyte: you can safely assume that you don't have to proxy back to the main thread from uv events
15:59:48  <tjfontaine>M28: erm
16:00:25  <tjfontaine>mmalecki: src/wrk.c:140:13: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'uint64_t' [-Wformat] aha, that's going to be the issue
16:00:35  <tjfontaine>mmalecki: 5000 requests in 307445734490.26m :P
16:00:44  <kellabyte>tjfontaine: ok, so basically I don't have to lock anything then :)
16:00:57  <tjfontaine>kellabyte: if you don't introduce threads in your stuff, no
16:01:42  <mmalecki>tjfontaine: hmm, my output is https://gist.github.com/mmalecki/92c8ab49c146fa2696b5
16:01:59  <mmalecki>tjfontaine: that seems like a bug in wrk or a weird lockup in node?
16:02:07  <tjfontaine>mmalecki: so ya, we may have the order reversed
16:02:17  <tjfontaine>mmalecki: it's a wrk and 64bit bug I'm guessing
16:02:42  <mmalecki>so wait a second, which one should be the master?
16:02:58  <mmalecki>I'm seeing lots of indicators on -
16:03:11  <tjfontaine>right which is why i think we got the wrong order
16:03:41  <mmalecki>those are higher means better, correct?
16:03:58  <tjfontaine>yes
16:04:15  <mmalecki>wait a second, I'm gonna run it on a beefy VM of some sort
16:04:26  <mmalecki>and pass the master in as the second one, correct?
16:04:39  <tjfontaine>yup
16:06:11  * TooTallNatejoined
16:06:56  * timoxleyjoined
16:07:27  <mmalecki>tjfontaine: that's gonna be g3-highcpu-24-smartos, the one with 24 vCPUs
16:07:32  <mmalecki>let's see what happens there :-)
16:07:38  <tjfontaine>:)
16:07:49  <tjfontaine>presuming that's mostly what you care about anyway
16:08:27  <tjfontaine>some of these tests can be very bouncy
16:11:11  * julianduquequit (Ping timeout: 256 seconds)
16:12:56  <mmalecki>gotta love clone times from joyent
16:13:19  <tjfontaine>which clones
16:13:40  <mmalecki>from github
16:14:16  <tjfontaine>oh man, you're trying to troll me aren't you :)
16:14:57  * bnoordhuisjoined
16:15:22  <mmalecki>gmake -j24 <3
16:16:37  <tjfontaine>reminds me, the fbsd slave I tried spin up needs some hacks to handle gmake
16:19:32  <mmalecki>build is broken on smartos
16:19:40  <mmalecki>eh, let me fix that real quick too
16:19:54  * bnoordhuisquit (Ping timeout: 264 seconds)
16:20:50  <tjfontaine>er, broken how?
16:22:40  <mmalecki>it didn't build on master for me
16:22:53  <tjfontaine>gist?
16:22:56  <mmalecki>build when I used --with-dtrace --dest-cpu=x64 tho
16:23:47  <mmalecki>tjfontaine: https://gist.github.com/mmalecki/95a3d02b729c9e721feb
16:24:16  * timoxleyquit (Quit: Computer has gone to sleep.)
16:24:44  <tjfontaine>hrm
16:26:07  * hueniversequit (Quit: Leaving.)
16:29:08  <mmalecki>tjfontaine: so prototypes first and master second?
16:32:55  <tjfontaine>yes
16:35:07  <mmalecki>hmm
16:35:07  <mmalecki>BFD: /root/node/out/Release/obj.target/libuv/deps/uv/src/unix/dtrace.o: warning: sh_link not set for section `.eh_frame'
16:36:04  * loladiroquit (Quit: loladiro)
16:37:14  <tjfontaine>how the devil
16:37:25  <tjfontaine>what platform are you on?
16:40:04  * dominictarrjoined
16:40:51  * bnoordhuisjoined
16:43:11  <tjfontaine>mmalecki: best case scenario there you won't see tick-start/tick-stop probes, worst case you won't see node probes and only the libuv ones
16:46:21  <bnoordhuis>bajtos: ping. any patches i need to review?
16:46:52  <bajtos>bnoordhuis: I am on a call now
16:47:00  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:47:12  <bajtos>bnoordhuis: nothing urgent, just the good old link-local address patch for libuv
16:47:21  <tjfontaine>bnoordhuis: I have a patch I need to clean up and have you review and tell me what I'm doing wrong in my autotools world
16:47:42  <bnoordhuis>tjfontaine: sure :)
16:47:55  <bnoordhuis>bajtos: right. i can do that tonight
16:48:35  <mmalecki>hmm, got stuck for me this time, tjfontaine
16:48:59  <mmalecki>or not?
16:50:38  <mmalecki>tjfontaine: so it's the higher the better, correct? those are req/s?
16:51:00  * csaohquit (Quit: csaoh)
16:51:53  <mmalecki>my thing seems to boost it up by 30 % in some cases but also degrade it by 30 % in others
16:51:57  <mmalecki>rerunning
16:52:16  <tjfontaine>higher numbers are better, that's part of the benchmarking convention isaacs wanted, what the numbers actually *are* is a different story
16:52:56  <mmalecki>tjfontaine: https://gist.github.com/mmalecki/92399e1279b3c8497a80
16:53:12  <mmalecki>ER
16:53:15  <mmalecki>wait, wrong window
16:53:15  <mmalecki>dammit
16:53:29  <tjfontaine>heh
16:53:36  <mmalecki>or not, it's the good one
16:53:46  <tjfontaine>ok, so ya there's a lot of noise
16:54:02  <mmalecki>yeah, I'm honestly not sure what to take from it
16:54:27  <mmalecki>it's almost exclusively fastest in client-request-body.js
16:54:53  <mmalecki>but other ones are a noise
16:55:23  <tjfontaine>client-request-body is where we'd expect the improvement to appear of course
16:55:58  <mmalecki>right, but gotta make sure it doesn't break other cases
16:56:05  <tjfontaine>indeed
16:56:22  <tjfontaine>the numbers in write-end are kinda scary
16:56:49  <tjfontaine>I wonder if there's an order of initialization coming into play
16:57:32  <mmalecki>hmm, I'm wondering what'd happen if I did the same thing to Stream
16:57:46  * hzquit
17:00:52  * TooTallNatejoined
17:05:53  * jmar777joined
17:06:09  * mcavage_quit (Remote host closed the connection)
17:07:49  * loladirojoined
17:11:43  * julianduquejoined
17:11:46  * julianduquequit (Client Quit)
17:15:20  * amartensjoined
17:18:16  <bajtos>bnoordhuis: cool
17:23:21  * brsonjoined
17:29:16  <mmalecki>tjfontaine: lol, yet different results, ugh
17:30:02  <tjfontaine>mmalecki: heh, ya know, <insert comment about benchmarking on vms>
17:30:36  <tjfontaine>I'm not sure what sorts of cpu and io shares you have in your configuration
17:43:07  <tjfontaine>bnoordhuis: https://github.com/tjfontaine/libuv/compare/dtrace-autotools this is what I have at the moment
17:44:52  <bnoordhuis>tjfontaine: the changes to configure.ac should probably go into a separate file m4/dtrace.m4
17:47:08  <tjfontaine>bnoordhuis: ya, I was waiting to talk with you about that, I was more concerned with getting things working appropriately
17:47:24  <tjfontaine>since for now the only feature we detect is dtrace
17:47:59  <bnoordhuis>tjfontaine: i have to compliment you for going the extra mile
17:48:04  <trevnorris>phew. glad that drive is over. I-80 SB out of reno was out from a rock slide. took an extra couple hours to get home.
17:48:21  <bnoordhuis>my quickie patch only adds --enable-dtrace and assumes that dtrace works
17:48:28  <trevnorris>tjfontaine: what is w/ that output?
17:49:00  <tjfontaine>bnoordhuis: well, I knew that *someone* had to have done it, and I wanted to find an appropriately licensed one, then in libmemcached I found a sun public licensed one
17:49:41  <tjfontaine>trevnorris: glad your safe, "5000 requests in 307445734490.26m," I'm guessing is what threw it off :)
17:49:46  <bnoordhuis>CDDL? doesn't that have all kinds of issues?
17:50:14  <tjfontaine>+dnl This file is free software; Sun Microsystems
17:50:14  * AvianFlujoined
17:50:14  <tjfontaine>+dnl gives unlimited permission to copy and/or distribute it,
17:50:15  <tjfontaine>+dnl with or without modifications, as long as this notice is preserved.
17:50:19  <tjfontaine>doesn't look cddl to me
17:52:01  <bnoordhuis>oh okay
17:52:05  <bnoordhuis>never mind then
17:52:44  <tjfontaine>I spent most of my evening looking for that fucker :P
17:54:39  <bnoordhuis>looks okay to me
17:54:46  <bnoordhuis>is there a reason uv-dtrace.h has to be installed?
17:54:59  <tjfontaine>nope
17:56:59  <tjfontaine>does LIBADD make sense there? there has to be a better way to generate the right location for the .o and to include it for linking
17:57:13  * mcavagejoined
17:58:20  <bnoordhuis>tjfontaine: does it work without? i should think that just adding it to _SOURCES should be enough
17:58:39  <tjfontaine>I can add the generated .o to the sources?
17:59:34  <bnoordhuis>no, just the .d
17:59:40  <bnoordhuis>btw, what does this do -> `grep '^pic_object' *.lo | cut -f 2 -d\'`
18:01:14  <tjfontaine>grabs the location of the real .o's so they can be post-processed
18:01:36  <tjfontaine>http://cpansearch.perl.org/src/TIMB/Memcached-libmemcached-0.4406/src/libmemcached/libmemcached/include.am is what I was looking at for inspiration
18:02:22  <bnoordhuis>SUFFIXES+= .d
18:02:27  <tjfontaine>in osx/freebsd land, the headers generate the ASM noops necessary, but on illumos/solaris you have to modify the .o, so we can either explicitly call out the .o's we use, or just run it on all of them
18:02:27  <bnoordhuis>^ good one to add
18:02:38  <tjfontaine>that is in there already
18:03:00  <bnoordhuis>oh ah *blushes*
18:03:18  <tjfontaine>presuming we don't define SUFFIXES anywhere else
18:03:26  <tjfontaine>I got a warning that we hadn't
18:04:17  <bnoordhuis>okay. i commented on that grep line but disregard that
18:04:29  <bnoordhuis>you should prefix it with $(top_srcdir) though
18:05:01  <tjfontaine>k
18:07:31  <trevnorris>bnoordhuis: is it possible to grab one of the existing uv thread handles from node?
18:07:44  <tjfontaine>what are you actually trying to solve? :)
18:08:40  <trevnorris>some dude on SO wants to run something in only one thread.
18:09:03  <trevnorris>but since uv runs multiple he'd like to know if you can grab onto one of those and use it when scheduling work.
18:09:14  <tjfontaine>uv also allows users to create their own thread
18:09:17  <trevnorris>or if it's necessary to spin up a thread.
18:09:36  <trevnorris>yeah. that was the answer I gave him, but I was curious about the other.
18:09:46  <tjfontaine>I would stay out of the existing fs threadpool, unless you're trying to introduce starvation :)
18:10:09  <tjfontaine>I guess the other question is, what's wrong with how uv_queue_work works now
18:10:31  <tjfontaine>or if he just wants to have a spin loop in another thread that uv_async_send's
18:11:42  <trevnorris>tjfontaine: here's the link: http://stackoverflow.com/questions/16407158/
18:12:18  <trevnorris>I usually use SO as a testing ground of how much I actually know. i'm starting to understand uv, but still a ways off. :)
18:13:23  <tjfontaine>if his library is not re-entrant, then he should create his own thread with uv and uv_async_send back to the main thread when needed
18:14:20  <trevnorris>cool. learning more stuff every day. thanks.
18:14:41  <tjfontaine>where "main thread" is "node thread"
18:17:14  <trevnorris>ah, didn't think about that. this is actually the first time I've ever actually had to think about the complexities of threads. :P
18:17:22  <trevnorris>JS has made my life way too fluffy
18:20:38  <trevnorris>tjfontaine: in include/uv.h for uv_async_send it has the comment "libuv is single threaded at the moment.". but it uses multiple threads. what am I missing?
18:21:06  <indutny>bnoordhuis: hey man
18:21:12  <indutny>I think I've some interesting stuff to do
18:21:18  <indutny>what do you think about sendfile in uv?
18:21:20  <tjfontaine>trevnorris: as in, libuv itself is not reentrant, meaning if you want to perform an action on libuv itself you need to get back to the thread that spawned it
18:21:50  * bajtosquit (Quit: bajtos)
18:22:07  <trevnorris>tjfontaine: ah, cool. thanks for taking the time to explain that. :)
18:22:13  <indutny>oh
18:22:15  <indutny>we already have noe
18:22:21  <indutny>s/noe/one/
18:22:48  <bnoordhuis>indutny: yep. you're about 1.5 years too late :)
18:22:54  <indutny>hahahaha
18:22:57  <tjfontaine>trevnorris: the fact that the worker queue, and fs operations can happen in the threadpool is an implementation detail :P
18:23:00  <indutny>will it work with tcp sockets?
18:23:08  <bnoordhuis>yes
18:23:10  <indutny>on windows :)
18:23:16  <bnoordhuis>oh, who knows?
18:23:23  <tjfontaine>good luck with all that.
18:23:25  <indutny>bertje?
18:23:28  <indutny>whatever
18:23:56  <bnoordhuis>bertje probably, yes
18:26:54  <mmalecki>tjfontaine: I'm gonna get a digitalocean vps ._.
18:27:08  <tjfontaine>mmalecki: heh what for?
18:27:16  <mmalecki>tjfontaine: testing
18:27:35  <mmalecki>tjfontaine: VMs render those numbers completely random
18:27:35  <tjfontaine>mmalecki: none of this is hitting the disk, you could just as well get the kvm instance
18:27:44  <tjfontaine>DO is a VM
18:27:52  <mmalecki>tjfontaine: it's a VPS
18:28:04  <mmalecki>well, kind of
18:28:16  <mmalecki>they don't really downscale you and don't mess with bursts
18:28:50  <tjfontaine>right bursting defeats benchmarks
18:30:09  <bnoordhuis>same with Intel(R) Turbo Boost(TM)
18:30:31  <bnoordhuis>that's caused me grief on more than one occasion
18:31:09  <bnoordhuis>you can disable it in your server's BIOS, usually
18:31:27  <bnoordhuis>but try doing that when your server is co-located 100s of miles away
18:31:31  <tjfontaine>hehe
18:31:41  <tjfontaine>ipmi to the rescue?
18:31:59  <bnoordhuis>DC support people to the rescue, actually :)
18:32:28  <bnoordhuis>don't want them slacking off and playing quake all night, right?
18:32:42  <tjfontaine>hehe
18:48:55  <trevnorris>hm. never noticed v8 had --ll_prof (low level linux profiler)
18:53:15  <indutny>bnoordhuis: I think we need node.js fund
18:53:38  <indutny>there're a lot of people wanting me to implement features for money
18:53:45  <indutny>but I don't like freelancing
18:54:11  <tjfontaine>which sorts of features
18:54:30  <tjfontaine>also I thought that's what strongloop was doing, node-code-for-hire
18:55:31  * rnowakjoined
18:56:28  * pachetjoined
18:59:17  <bnoordhuis>indutny, tjfontaine: yep. though we're probably not in the price range that's affordable to individuals, only companies
18:59:25  <tjfontaine>indeed
18:59:29  <tjfontaine>that's what I was going to say
19:00:43  <indutny>obviously
19:00:49  <indutny>I just won't accept such money
19:00:56  <indutny>but it'd be a good fit for us all
19:00:59  <indutny>in case of anything
19:01:08  <mmalecki>indutny: redirect them to me if you feel like it
19:01:10  <indutny>or could be used
19:01:14  <indutny>to sponsor conferences
19:01:22  <indutny>which I kind of like too
19:01:27  <indutny>mmalecki: no way :)
19:01:28  <mmalecki>I'm up for consulting gigs, especially involving node core
19:01:36  <rnowak>Hello, I've tried looking for previous mentions of sctp in the context of libuv, but I've fallen pretty short. Has there been any discussion? Is there any standing on it? Does the project think it has a place in libuv?
19:01:59  <mmalecki>indutny: lol okay
19:02:31  <indutny>rnowak: isn't it possible to do is a third party module?
19:02:44  <indutny>s/is/it/
19:02:58  <indutny>mmalecki: I'm just doing it for free right now
19:03:07  <indutny>but I think node fund could be a cool thing
19:03:13  <indutny>I wonder what isaacs thinks about it
19:03:28  <bnoordhuis>rnowak: sctp? do people actually use that?
19:03:35  <mmalecki>indutny: there are solutions tho
19:03:43  <mmalecki>indutny: like gittip and what not
19:03:50  <rnowak>it very well may be, it is not something I have looked into just yet -- I wanted to see if the project has had any concensus or at least discussions about it
19:03:54  <mmalecki>there's this second one too
19:03:57  <indutny>yeah, gittip might work quite well
19:04:05  <mmalecki>mikeal used it for request
19:04:07  <indutny>considering that it allows people to pledge things constantly
19:04:21  <mmalecki>bountysource
19:04:32  <rnowak>bnoordhuis: some things do, it is an interesting transport, and hopefully its use will expand
19:04:38  <indutny>rnowak: its interesting protocol, but, personally, it seems to be too off-topic for libuv
19:04:40  <mikeal>i need to figure out how to spend that money
19:04:53  <rnowak>indutny: I see
19:05:02  <indutny>mikeal: you may put them in your next conference :)
19:05:04  <bnoordhuis>rnowak: i don't disagree but it's rather niche. no one uses it so nothing supports it so no one uses it
19:05:30  <indutny>or
19:05:34  <indutny>buy cool guitar
19:05:55  <indutny>I'm looking forward for getting my prs p22 once I'll be in USA again
19:06:01  <indutny>its so f%cking awesome
19:06:13  * Luqmanquit (Ping timeout: 248 seconds)
19:06:34  <bnoordhuis>fedor is a guitar nerd, that's so cute :)
19:06:57  <trevnorris>mmalecki: fyi, https://github.com/joyent/node/pull/5720
19:07:13  <indutny>bnoordhuis: yeah
19:07:33  <indutny>and its hard to buy good ones in russia
19:07:38  <rnowak>bnoordhuis: chicken egg kind of thing definitely, but it has its place, especially in internal interconnects
19:07:47  <indutny>there're like tones of shitty ones in malls and music shops
19:07:55  <indutny>mostly made in indonesia
19:08:13  <indutny>so even mexican guitars are in favor here
19:08:23  <rnowak>bnoordhuis: google's quic project had a look at it as well, but it goes against one of their goals, which is to reduce initial latency, so they are toying with UDP -- otherwise, SCTP would be exactly what they'd want
19:08:43  <indutny>I don't really like quic
19:08:58  <indutny>they're reimplementing a lot of stuff just to make it work as they want
19:09:20  <indutny>it'd be better to fix existing standards
19:09:27  <indutny>bnoordhuis: this http://www.prsguitars.com/p22/
19:09:34  <tjfontaine>I remember during the initial spdy leadup they were evaluating sctp
19:09:35  <rnowak>that's not really possible with the millions of devices which would possibly not be able to adapt
19:09:44  <bnoordhuis>rnowak: re sctp, it'd would have to work on all platforms in order for libuv to support it
19:09:59  <indutny>rnowak: well, new versions
19:10:17  <rnowak>SCTP brings much of TCP and UDP together, so there's your new version :)
19:10:22  <rnowak>bnoordhuis: nod
19:10:41  <tjfontaine>rnowak: so basically start getting a WIP PR together, that way you can know just how much time you'll waste :)
19:10:51  <bnoordhuis>indutny: Real Men play the ukelele
19:10:51  <rnowak>bnoordhuis: sctp support in windows is only available as a third party package; would that pose a problem?
19:11:02  <bnoordhuis>rnowak: yes
19:11:11  <indutny>oh yeah
19:11:19  <indutny>you dutch people are so good at jokes
19:11:25  <bnoordhuis>i actually had one for a while, it's pretty fun
19:11:47  <bnoordhuis>but my hands are a bit too big to get decent sound out of it
19:11:59  <tjfontaine>twss
19:12:10  <tjfontaine>or something.
19:12:16  * Luqmanjoined
19:12:26  <bnoordhuis>heh
19:13:36  <bnoordhuis>apropos the ukelele, there's like a million youtube videos of teenage girls doing ukelele covers of pop songs for some reason
19:13:55  <bnoordhuis>the ukelele is the new black, fedor. you heard it here first
19:14:07  <tjfontaine>actually it's the 2011-2012 black :P
19:14:15  <bnoordhuis>aw, really?
19:14:18  <tjfontaine>you're late to the game, and it's too soon to bring it back :)
19:14:25  * bnoordhuismopes
19:16:18  <indutny>:)
19:16:25  <indutny>two fails a day
19:16:29  <tjfontaine>I've never seen an unhappy ben
19:16:31  <indutny>you're getting old
19:16:32  <indutny>:)
19:16:39  <bnoordhuis>what was the other fail?
19:16:47  <bnoordhuis>see, my memory is acting up as well
19:17:33  <indutny>:)
19:21:10  * jmar777quit (Remote host closed the connection)
19:21:47  * jmar777joined
19:25:58  * jmar777quit (Ping timeout: 245 seconds)
19:30:08  * AvianFluquit (Remote host closed the connection)
19:31:14  <trevnorris>bnoordhuis: any luck on the 3.20 upgrade?
19:34:08  <bnoordhuis>trevnorris: it's a _massive_ pain
19:34:28  <bnoordhuis>the v8 people are hereby no longer welcome on my birthday party
19:35:06  <trevnorris>wow. remind me the pain point for the 3.20 upgrade?
19:36:12  <bnoordhuis>persistent no longer inherits from handle
19:36:14  <bnoordhuis>that's the major one
19:36:25  <bnoordhuis>everything else is mostly search and replace
19:36:42  <bnoordhuis>still, there's a lot of it - i'm at 800-ish touched lines and counting
19:36:44  <trevnorris>tjfontaine: here's an http thing for fixing: res.end(str_60k, 'binary'); -> 8500 req/sec. VS res.end(new Buffer(str_60k, 'binary')); -> 12000 req/sec.
19:37:44  <trevnorris>bnoordhuis: ah yeah. I remember wondering how much a pain that would be. since they could be used interchangeably before. yeah. that's going to be painful.
19:38:33  <bnoordhuis>trevnorris: i'm first going to hack it into a working state, then kill off our persistent handles one by one
19:38:59  <bnoordhuis>we've way too many anyway, it's probably having the exact opposite effect than is intended
19:39:39  <trevnorris>how are you going to do that for all the places the Persistent is stored on a class instance (e.g. ObjectWrap)?
19:40:08  <trevnorris>bnoordhuis: and you can remove a couple really quick by reviewing https://github.com/joyent/node/pull/5720 ;)
19:41:40  <trevnorris>bnoordhuis: also sure you saw the mailer, but it was decided that Handle's going to be removed, not Local.
19:42:45  <bnoordhuis>yeah, i saw that
19:46:50  <trevnorris>holy crap. i'm going to make a wiki page how to properly check for a "memory leak"
19:47:06  <tjfontaine>P=NP?
19:47:26  <trevnorris>tjfontaine: can you have jenkins automatically post the link to any issue that has "memory leak" in the title?
19:47:38  <trevnorris>(half kidding)
19:47:44  <tjfontaine>are you looking at the one that says "unbounded memory leak" and then "I cache 200mb in a dictionary"
19:47:57  <trevnorris>yeah.
19:48:00  <tjfontaine>ya.
19:48:13  <trevnorris>but I swear there's at least one of those a week.
19:48:43  <tjfontaine>gotta convince people to use .toString('binary') :P
19:49:56  <trevnorris>lols. actually at that size it'll just use the backing data as an external string. so it still won't enter the v8 heap.
19:50:56  <tjfontaine>really though, just need to convince them that they shouldn't hold on to buffers, a .toString() is perfectly valid if they think they need to hold onto something for later
19:51:25  <bnoordhuis>trevnorris: couple of comments but mostly lgtm, i think
19:53:01  <trevnorris>bnoordhuis: thanks. ooh. like the noreturn thing. will I have to ifdef and exclude that for windows builds? or will it just ignore it.
19:53:26  <trevnorris>tjfontaine: how's that? if the application is crashing then the heap is filling up. if they hold onto too many Buffers then the system will just halt.
19:53:59  <bnoordhuis>trevnorris: __attribute((whatever)) is a gcc/clang-ism so yes, #ifdef it the usual way
19:54:05  <bnoordhuis>*__attribute__
19:54:07  <trevnorris>coolio.
19:54:30  <tjfontaine>trevnorris: in old world, pre your slab removal, they're fighting themselves, it happens still with generic sliced buffers, but still, application code should almost never hold onto a buffer because of the slicing problem
19:55:40  <trevnorris>tjfontaine: oh, yeah. they're probably not copying out the data into another Buffer. so it's retaining the slab. good point.
19:56:20  <tjfontaine>if there's something an application wants to keep around, they should be explicit about it, similar to your "yank" proposal, but still without tying themselves to a Buffer
19:58:03  <trevnorris>bnoordhuis: sorry, not following on the realloc mem leak point.
19:58:53  <bnoordhuis>trevnorris: you're doing p = realloc(p, n); if (n == 0) return;
19:59:16  <bnoordhuis>which looks like a like because p is not necessarily NULL after realloc(p, 0)
19:59:40  <trevnorris>ah. got it. so just explicitly free if nread == 0. thanks.
19:59:51  <trevnorris>and that returning pointer of Handle<> is a cool trick.
20:00:40  <bnoordhuis>trevnorris: btw, If size is zero and ptr is not NULL, a new, minimum sized object is allocated and the original object is freed.
20:01:16  <trevnorris>oooh. that'd be like death from 10,000 cuts. super tiny leak.
20:01:25  <bnoordhuis>yep
20:01:36  <trevnorris>thanks for your wisdom as always. :)
20:01:48  <bnoordhuis>np :)
20:02:12  <indutny>realloc
20:02:16  <indutny>mother of all sins
20:02:35  <trevnorris>eh?
20:02:38  * Luqmanquit (Ping timeout: 245 seconds)
20:08:05  * julianduquejoined
20:12:53  * txdv_joined
20:13:28  * txdvquit (Read error: Connection reset by peer)
20:14:03  <bnoordhuis>apropos nothing, why did streams2 add objectMode?
20:14:39  <tjfontaine>it seems useful for protocol parsers
20:14:54  <bnoordhuis>is it? how?
20:15:22  <tjfontaine>I call read(1) and then only get one fully formed piece of what I'm looking for
20:16:17  <bnoordhuis>hm, okay
20:16:36  <bnoordhuis>i did a talk on streams2 last week and someone asked what the deal was with objectMode
20:16:49  <bnoordhuis>didn't really have a good answer except "it seemed like a good idea at the time"
20:17:03  * pachetquit (Quit: leaving)
20:17:12  <tjfontaine>you can do something similar with .emit('obj') but that doesn't necessarily match the pattern of a consumable
20:17:53  <trevnorris>bnoordhuis: all changes, and a new commit :) https://github.com/trevnorris/node/commit/c4479be
20:19:50  <bnoordhuis>trevnorris: put FatalError in src/node.cc. the idea behind noreturn is that the compiler can optimize the call (doesn't have to reserve stack space for spilled registers, etc.)
20:20:06  <bnoordhuis>but if you put it in a header, it has no choice but to inline it at the call site
20:20:14  <trevnorris>ah ok.
20:20:19  <bnoordhuis>which kind of defeats the purpose because the goal is to reduce code size
20:21:52  * isaacs_mobilejoined
20:22:40  <trevnorris>bnoordhuis: um. so node_internals isn't included in node.cc already. include it?
20:22:57  <bnoordhuis>trevnorris: no need, node.h includes it
20:23:11  <bnoordhuis>we include node_internals.h in a couple of places, i noticed today
20:23:20  <bnoordhuis>but that's superfluous
20:23:46  <trevnorris>bnoordhuis: but under the condition of NODE_WANT_INTERNALS, which could cause the build to break if not defined, right?
20:24:06  <bnoordhuis>trevnorris: yeah, but it's always defined when building node
20:24:14  <trevnorris>ok.
20:24:15  <bnoordhuis>it's set in the gyp file
20:26:57  <trevnorris>bnoordhuis: ok. last dumb question. does the __attribute__ go in .h or .cc?
20:28:57  <trevnorris>nm. found some docs.
20:30:31  * groundwaterquit (Ping timeout: 256 seconds)
20:30:39  <trevnorris>oy. annoying. so I call OnFatalError, which always exists, but clang gives me a warning about not returning. :P
20:31:43  <bnoordhuis>trevnorris: annotate OnFatalError as well
20:31:48  * groundwaterjoined
20:31:57  <trevnorris>cool.
20:36:20  <trevnorris>bnoordhuis: https://github.com/trevnorris/node/commit/89d9717
20:37:54  * txdv_quit (*.net *.split)
20:37:54  * dapquit (*.net *.split)
20:42:05  * txdv_joined
20:42:05  * dapjoined
20:42:21  * isaacs_mobilequit (Remote host closed the connection)
20:43:28  <trevnorris>isaacs: this lgtm. any opposition? https://github.com/joyent/node/pull/5181
20:44:41  * julianduquequit (Ping timeout: 256 seconds)
20:49:50  * Luqman_joined
20:55:27  * Luqman_quit (Quit: leaving)
20:56:14  <trevnorris>bnoordhuis: thanks. for how explicit cpp needs to be, I was confused when it let me place __attribute__ in multiple locations.
20:58:14  <trevnorris>bnoordhuis: those two small things fixed. just in case you wanted to review: https://github.com/trevnorris/node/commit/3b46081
20:58:31  * inolenquit (Quit: Leaving.)
20:58:51  <tjfontaine>bnoordhuis: is there a way to be more explicit about dependencies for run-tests? from a clean build I'm trying make sure it generates uv-dtrace.h if someone `make test/run-tests` or is that niche enough we shouldn't care?
20:59:32  * inolenjoined
20:59:37  <tjfontaine>it certainly does the right thing for `make check`
20:59:43  <isaacs>trevnorris: looking
21:00:50  * mikealquit (Quit: Leaving.)
21:01:01  <isaacs>trevnorris: lgtm
21:01:04  * mikealjoined
21:01:04  <isaacs>land at will
21:03:33  <trevnorris>isaacs: thx.
21:05:18  * piscisaureus_joined
21:05:32  * txdvjoined
21:06:06  * txdv_quit (Ping timeout: 264 seconds)
21:07:06  <tjfontaine>bnoordhuis: https://github.com/tjfontaine/libuv/compare/dtrace-autotools
21:09:26  <bnoordhuis>trevnorris: github is broken, it seems. can't open the page
21:09:40  <piscisaureus_>githubbb
21:10:07  <tjfontaine>etimedout, awesome.
21:10:15  <tjfontaine>trevnorris: you broke github again
21:10:26  <bnoordhuis>too many force-pushes!
21:10:30  <tjfontaine>heh
21:10:40  <piscisaureus_>https://status.github.com/ has nothing
21:10:52  <tjfontaine>status is always 5 mins behind
21:11:41  <tjfontaine>my favorite part is how that destroys our jenkins as well because it uses github for authorization
21:12:06  <tjfontaine>LOUDBOT: so hostile
21:13:25  <tjfontaine>https://twitter.com/githubstatus/status/352534902551482368
21:24:30  <piscisaureus_>isaacs: http://logs.libuv.org/manta/latest
21:30:38  <bnoordhuis>trevnorris: lgtm. does it work? if yes, land it :)
21:30:43  * jmar777joined
21:30:54  <trevnorris>bnoordhuis: awesome. thanks.
21:31:01  * trevnorrisis in a meeting. :P
21:31:22  <bnoordhuis>i'll land it for you. i need to rebase afterwards
21:31:54  * rendar_quit
21:33:26  <trevnorris>bnoordhuis: whatev's. just make sure to squash the last 4 commits together. ;)
21:33:33  <bnoordhuis>last 4? okay
21:34:22  <trevnorris>yeah. the last 3 are just patches for review. so they'll need to be squashed into the 4th.
21:34:54  <trevnorris>bnoordhuis: actually, i'll do it right now. there was a subset of a commit I wanted applied to the first.
21:35:29  <bnoordhuis>yeah, just squashing messes up the logical order
21:35:49  <bnoordhuis>e.g. the change to node.h in commit 2 is then undone in commit 3
21:36:12  <trevnorris>heh, yeah.
21:36:29  <tjfontaine>bnoordhuis: happy with my autotools changes?
21:36:54  * bnoordhuislooks
21:37:24  * jmar777quit (Read error: Connection reset by peer)
21:37:31  * jmar777_joined
21:38:59  <isaacs>piscisaureus_: thanks!
21:42:33  * jmar777_quit (Remote host closed the connection)
21:42:51  <bnoordhuis>tjfontaine: running ./configure again with --disable-dtrace doesn't rebuild
21:43:03  <bnoordhuis>which presumably means it doesn't disable dtrace either
21:43:14  <tjfontaine>hrm ok
21:44:00  <tjfontaine>hmm just worked here
21:44:06  <tjfontaine>oh oh
21:44:15  <tjfontaine>I see, not without a clean in between
21:44:16  <tjfontaine>hm
21:44:57  * jmar777joined
21:45:15  <tjfontaine>hmm
21:45:59  <tjfontaine>well, a make clean doesn't regenerate uv-dtrace, so I guess the issue at hand is that we're not touching anything like a config.h.in pattern normally would
21:46:46  <bnoordhuis>that sounds plausible
21:47:13  * piscisaureus_quit (Ping timeout: 256 seconds)
21:47:31  <tjfontaine>I wonder what the right pattern here would be
21:49:58  <bnoordhuis>eh, i've no real suggestion
21:50:13  <bnoordhuis>i can live with landing it and opening an issue for it
21:50:39  <tjfontaine>ok
21:51:16  <bnoordhuis>probably needs a little dependency tweaking
21:51:28  <bnoordhuis>but, like the girl said, it's no big thing
21:51:34  <tjfontaine>hehe
21:54:21  * wolfeidaujoined
21:54:48  * AvianFlujoined
21:55:41  <bnoordhuis>trevnorris: did you land your stuff?
21:56:18  <trevnorris>bnoordhuis: in a minute. sorry, being really anal about getting the right code snippets in the right commit. :P
21:56:49  <trevnorris>bnoordhuis: do you have something to land?
21:56:56  <tjfontaine>hmm why isn't m4 being included on sunos
21:57:14  <bnoordhuis>trevnorris: no, but i need to rebase this v8 upgrade shite afterwards
21:57:21  <bnoordhuis>else i'm doing work for nothing
21:57:32  <trevnorris>ok. i'll be done in 3.
22:00:01  * jmar777quit (Remote host closed the connection)
22:00:36  * jmar777joined
22:02:03  <bnoordhuis>hey, rust 0.7 got released today
22:04:43  * jmar777quit (Ping timeout: 245 seconds)
22:05:44  <MI6>joyent/node: Trevor Norris master * 278183a : {stream,udp,tls}_wrap: remove unused offset/length (+2 more commits) - http://git.io/PZM7IQ
22:05:44  <trevnorris>bnoordhuis: done
22:06:21  * dapquit (Read error: No route to host)
22:06:34  * dapjoined
22:06:42  <trevnorris>bnoordhuis: have one tiny pr i'm going to pop on.
22:07:36  <MI6>joyent/node: Jeff Barczewski master * 26ca7d7 : stream: objectMode transform should allow falsey values - http://git.io/J3x99Q
22:07:47  <trevnorris>bnoordhuis: thanks for waiting.
22:08:50  * dapquit (Read error: Connection reset by peer)
22:08:59  * dapjoined
22:09:01  <bnoordhuis>cool, thanks
22:09:31  <trevnorris>yeah. and thank you.
22:10:07  <trevnorris>had a dream last night. I submitted a PR and you lgtm'd it w/o a single comment. hopefully that foretells the future. ;)
22:10:18  <tjfontaine>heh
22:10:33  <tjfontaine>simple pleasures
22:10:40  <trevnorris>seriously, right
22:16:50  <trevnorris>bnoordhuis: just wanted to pass this by, but don't think this one will affect your 3.20 upgrade: https://github.com/joyent/node/pull/5747
22:19:05  <MI6>nodejs-master: #281 UNSTABLE linux-x64 (1/609) osx-x64 (1/609) smartos-x64 (9/609) smartos-ia32 (1/609) http://jenkins.nodejs.org/job/nodejs-master/281/
22:22:38  * timoxleyjoined
22:28:07  <trevnorris>tjfontaine: jenkins just under stress? keeps erroring w/ "Error 324 (net::ERR_EMPTY_RESPONSE):" when I try to see the TAP tests.
22:29:35  <trevnorris>isaacs: do you know if it's possible that a user writes a string over a socket, but not all of the string is actually sent?
22:31:00  <tjfontaine>trevnorris: looking
22:31:15  * loladiroquit (Quit: loladiro)
22:31:18  <trevnorris>tjfontaine: thanks :)
22:31:22  <tjfontaine>also define "actually sent"
22:32:12  <mordy_>hrm; what kind of toolchain do i need to build uv on windows? it apparently expects quite a few things in my %path%
22:32:22  <mordy_>i added git; then it wanted python; now it wants msbuild
22:33:02  <mordy_>i also tried to cross compile using --host=i586-mingw32msvc but to no avail
22:33:08  <trevnorris>mordy_: have you already gone over https://github.com/joyent/libuv#build-instructions
22:33:19  <tjfontaine>mordy_: VS >= 2010 (vcexpress works as well)
22:33:35  <tjfontaine>mordy_: master+mingw is broken atm because of the autotools change
22:33:55  <mordy_>ahh ok
22:33:59  <mordy_>i need to open the vs prompt
22:34:25  <tjfontaine>taking jenkins down
22:34:44  <trevnorris>bnoordhuis: the reason I added must_free to ReqWrap is because the same approach can work for writing data over a TCP socket.
22:34:53  <trevnorris>bnoordhuis: and I hope to do that soon.
22:35:00  <mordy_>ok, building now
22:35:42  <mordy_>hrm; i'm impressed. the build seems to be quite fast. what's the magic?
22:36:01  <trevnorris>bnoordhuis: or should that go into each inhereted class (e.g. StreamWrap's WriteWrap)?
22:36:19  * mikealquit (Quit: Leaving.)
22:36:24  <tjfontaine>mordy_: C
22:36:58  <mordy_>the entire build stuff is written in C?
22:37:21  * mordy_isn't familiar with gyp, and only vaguely so about msbuild -- but isn't that what visual studio uses internally?
22:37:53  * brsonquit (Ping timeout: 248 seconds)
22:37:57  <tjfontaine>gyp is python, msbuild is .net, our code is C, building libuv is fast because it's not fancy/abusive c++
22:38:30  <mordy_>it's still way faster than most of my C stuff i've tried to build on windows
22:38:31  * brsonjoined
22:38:42  * mordy_isn't much of a C++ guy
22:39:35  <trevnorris>tjfontaine: fyi when running autogen.sh: "./autogen.sh: 17: [: unexpected operator"
22:41:18  <trevnorris>mordy_: my system can build libuv in 1.56 sec. it's super light weight.
22:41:33  <tjfontaine>trevnorris: I haven't landed anyhting yet, so I didn't break it :P
22:41:54  <tjfontaine>but I'm guessing you might have a broken sh
22:42:47  <trevnorris>tjfontaine: yeah. was just letting you know. it happens in sh and bash (running bash 4.2.37)
22:42:56  * brsonquit (Client Quit)
22:43:01  <tjfontaine>really, hmm that's oddd
22:43:10  * brsonjoined
22:43:22  <tjfontaine>is LIBTOOLIZE set in your env? or something
22:44:02  <tjfontaine>anyway I bet your /bin/sh is dash, and or something
22:44:31  <Raynos>if I wanted to write my own fancy pants tcp / http abstraction on top of process.bindings what would be the best place to find docs for the internal API ?
22:44:54  <tjfontaine>s/fancy pants/destined to break/ :P
22:45:04  <trevnorris>Raynos: the source and headers. :)
22:45:09  <tjfontaine>Raynos: anyway, internal api doesn't really have docs, so use the source luke
22:45:45  <Raynos>tjfontaine: I will write an adapter between my code and process.bindings and put all the back compat / changes hacks there. it will be painful but do-able
22:45:59  <tjfontaine>good luck and god speed
22:46:01  <Raynos>I was hoping there might be something better then the source :(
22:46:27  <tjfontaine>we have isaacs :P
22:46:29  <bnoordhuis>trevnorris: yes
22:46:32  <tjfontaine>he's walking documentation
22:46:45  <trevnorris>Raynos: had to do that when I implemented smalloc, check out commit 8f3f9f7
22:46:45  <Raynos>I'm sure isaacs did blog posts or something about using process.bindings("net") directly
22:46:48  <trevnorris>bnoordhuis: thanks.
22:47:17  <tjfontaine>Raynos: were they of the nature, "we will pummel you with bean bags if you do it"?
22:47:42  <Raynos>tjfontaine: I think they were "look how painful this is. be grateful you can require('net')"
22:48:05  <Raynos>trevnorris: does github have a commit search?
22:48:15  <tjfontaine>yes, ish
22:48:23  <bnoordhuis>tjfontaine, trevnorris: btw, autogen.sh should work with dash. if it doesn't, that's a bug
22:48:34  <trevnorris>Raynos: https://github.com/joyent/node/commit/8f3f9f7
22:48:41  <Raynos>sweet
22:48:55  <trevnorris>bnoordhuis: will do. and thanks.
22:49:31  <trevnorris>tjfontaine: so all the *.o files are automatically dumped in the root of the project. don't think that happened before. do we always have to specify the build directory now?
22:49:45  <tjfontaine>welcome to autotools land
22:50:02  <bnoordhuis>trevnorris: mkdir tmp && cd tmp && ../configure
22:50:09  <tjfontaine>indeed
22:50:45  <trevnorris>bnoordhuis: oh, but it seems I need to run autogen.sh from the project root or it complains.
22:50:51  <trevnorris>but after I can configure. cool
22:51:30  <tjfontaine>bnoordhuis: how do I debug that fact that AC_CONFIG_MACRO_DIR doesn't seem to be enough to include the dtrace.m4 with the versions I have in smartos atm, I have to m4_require which is less than ideal
22:52:04  <tjfontaine>er m4_include
22:52:06  <tjfontaine>anyway
22:56:14  <bnoordhuis>tjfontaine: old version of autoconf/aclocal?
22:56:35  <tjfontaine>they don't seem that old
22:56:36  <tjfontaine>autoconf-2.69 Generates automatic source code configuration scripts
22:56:36  <tjfontaine>automake-1.12.2 GNU Standards-compliant Makefile generator
22:56:50  <bnoordhuis>that's newish enough, yes
22:57:25  <tjfontaine>Makefile.am:195: error: HAVE_DTRACE does not appear in AM_CONDITIONAL
22:57:25  <tjfontaine>Makefile.am:200: error: DTRACE_NEEDS_OBJECTS does not appear in AM_CONDITIONAL
22:58:05  <tjfontaine>which is just frustrating, because of course, they are indeed there
22:59:04  <trevnorris>tjfontaine: ok. so the error goes away if I swap #!/bin/sh with #!/bin/bash
22:59:30  <tjfontaine>trevnorris: right, so for some unknown reason, your sh (presumably actually a symlink to dash) doesn't like that relatively straightforward script
22:59:58  <trevnorris>tjfontaine: yup. you're correct.
23:00:01  <bnoordhuis>tjfontaine: what happens when you add -I m4 to aclocal in autogen.sh
23:00:10  <tjfontaine>bnoordhuis: we'll find out
23:00:51  <tjfontaine>bnoordhuis: yup, and it appears in ./configure --help
23:01:02  <tjfontaine>I'll include that in my changes then
23:01:07  <bnoordhuis>okay, nice
23:01:12  <trevnorris>tjfontaine: ok. strict POSIX uses on =, not ==
23:01:18  <trevnorris>tjfontaine: so it needs to be: if [ "$LIBTOOLIZE" = "" ] && [ "`uname`" = "Darwin" ]
23:01:27  <bnoordhuis>oh, right. silly me
23:01:57  <bnoordhuis>i know that, i've known that for at least a decade and i still keep doing it
23:02:04  <trevnorris>heh
23:02:14  <tjfontaine>posix shmosix
23:02:33  <trevnorris>heh, I love libuv builds from scratch in 1.5 sec.
23:05:09  <MI6>joyent/libuv: Timothy J Fontaine master * 2f3124a : build: add DTrace detection for autotools - http://git.io/3cKTvQ
23:06:32  * mikealjoined
23:07:06  <MI6>nodejs-master: #283 UNSTABLE smartos-ia32 (3/609) linux-x64 (1/609) smartos-x64 (8/609) http://jenkins.nodejs.org/job/nodejs-master/283/
23:07:46  * mcavagequit (Remote host closed the connection)
23:07:47  * dap1joined
23:07:59  <trevnorris>tjfontaine: haven't seen this one fail before, so just want to double check. not life altering this failed? http://jenkins.nodejs.org//job/nodejs-master/281/DESTCPU=x64,label=smartos//tapTestReport/test.tap-534/
23:08:03  * dapquit (Ping timeout: 245 seconds)
23:09:32  <MI6>libuv-master: #142 UNSTABLE windows (4/191) smartos (2/190) http://jenkins.nodejs.org/job/libuv-master/142/
23:09:51  <trevnorris>there. once done i'm just going to start linking every memory leak bug to it: https://github.com/joyent/node/wiki/How-to-Find-Memory-Leaks
23:11:57  <tjfontaine>just start by describing what isn't a leak, and what is really a resource leak :P
23:16:01  <trevnorris>heh, seriously. if core is doing its job correctly then it shouldn't be possible to really leak anything from js.
23:16:14  <tjfontaine>well
23:16:27  * groundwaterquit (Quit: groundwater)
23:16:44  <tjfontaine>can't rule it out, but there are things that certainly appear to the user as a memory leak, when in fact they are under-documented features
23:17:37  <MI6>libuv-master-gyp: #80 UNSTABLE windows-x64 (5/191) smartos-ia32 (3/190) smartos-x64 (2/190) windows-ia32 (4/191) http://jenkins.nodejs.org/job/libuv-master-gyp/80/
23:18:37  <trevnorris>am I missing some configuration for these to fail? https://gist.github.com/trevnorris/5923695
23:19:02  <tjfontaine>this is going to be because you're building out of tree
23:19:31  <trevnorris>out of tree? you mean latest master instead of latest stable?
23:19:47  <tjfontaine>no, as in ../configure && make && make check
23:19:55  <trevnorris>ah, ok.
23:20:00  <tjfontaine>it's looking for things to exist, that don't because you're not in tree
23:20:08  <trevnorris>well bugger.
23:20:13  <tjfontaine>if you/we want that to work, the tests will need some fixup
23:22:26  * groundwaterjoined
23:23:02  * groundwaterquit (Client Quit)
23:23:36  * groundwaterjoined
23:24:04  <MI6>libuv-node-integration: #131 UNSTABLE smartos-x64 (9/609) smartos-ia32 (1/609) http://jenkins.nodejs.org/job/libuv-node-integration/131/
23:31:24  * piscisaureus_joined
23:35:17  <tjfontaine> 30 not ok - test-tls-client-verify.js
23:35:17  <tjfontaine> 3856 ok - test-tls-client-verify.js
23:35:35  <tjfontaine>trevnorris: so it's popular necessarily, but it's not unheard of as well
23:35:47  <tjfontaine>*not popular
23:36:18  <trevnorris>ah, good. thanks :)
23:36:23  * piscisaureus_quit (Ping timeout: 256 seconds)
23:36:44  * inolenquit (Quit: Leaving.)
23:37:04  * inolenjoined
23:38:41  <trevnorris>bnoordhuis: thanks. force pushed (want a full review of that commit again :) https://github.com/trevnorris/node/commit/db1db5b
23:39:57  <TooTallNate>trevnorris: is fs.writeSync meant to be documented twice?
23:41:14  <trevnorris>TooTallNate: did that for consistency, and to show the proper sets of arguments. i'm not a fan of it, but couldn't figure out a better way.
23:41:23  * inolenquit (Ping timeout: 245 seconds)
23:41:30  <TooTallNate>cool
23:41:39  <TooTallNate>i mean we do that in a few other places already right?
23:41:44  <TooTallNate>so it's probably fine
23:42:53  <trevnorris>can someone help me understand how a value is passed as "func", but it's not a variable or anything? https://github.com/trevnorris/node/blob/db1db5b/src/node_file.cc#L238-L253
23:43:29  <trevnorris>it's only used in one location, so I'd like to just drop it in, but can't figure out exactly what's going on: https://github.com/trevnorris/node/blob/db1db5b/src/node_file.cc#L751
23:43:40  <tjfontaine>trevnorris: # means take the name of what was passed in
23:44:03  <TooTallNate>it's a macro
23:44:10  <trevnorris>tjfontaine: got that, but there's the line "new FSReqWrap(#func);", but #func == word
23:44:17  <trevnorris>but word isn't technically defined.
23:45:29  <TooTallNate>trevnorris: what's the word?
23:45:34  <TooTallNate>write?
23:45:43  <trevnorris>yeah
23:45:57  <TooTallNate>well then it is defined, by libc right?
23:46:05  <trevnorris>so expanded it would look like "new FSReqWrap(write);"
23:46:15  <TooTallNate>right
23:46:39  <TooTallNate>so it's passing the function pointer to `write` to the FSReqWrap
23:47:03  <trevnorris>but write isn't defined. at least says clang.
23:47:20  <tjfontaine>missing a stdio include somehow?
23:47:21  <TooTallNate>man 2 write
23:47:31  <TooTallNate>maybe you need #include <unistd.h>
23:48:28  <trevnorris>TooTallNate: but why would it work in the macro?
23:49:03  <MI6>nodejs-v0.10-windows: #96 UNSTABLE windows-x64 (7/593) windows-ia32 (8/593) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/96/
23:49:09  * inolenjoined
23:49:14  <tjfontaine>what exactly were you doing when you got write isn't defined?
23:49:16  <TooTallNate>trevnorris: so ASYNC_FREE_CALL(write) works but invoking write() directly doesn't?
23:49:33  <trevnorris>TooTallNate: well technically I pass it: "new FSReqWrap(write);"
23:49:55  <trevnorris>tjfontaine: just placed the code from the macro where it's used and replaced the variables.
23:50:06  <trevnorris>then I get "error: use of undeclared identifier 'write'"
23:51:13  <tjfontaine>ok
23:51:17  <tjfontaine>this is macro stringification
23:51:28  <tjfontaine>#func turns into "write"
23:51:36  <tjfontaine>http://gcc.gnu.org/onlinedocs/cpp/Stringification.html#Stringification
23:51:45  <trevnorris>*facepalm*
23:51:46  <trevnorris>thanks
23:51:49  <TooTallNate>oh right
23:52:00  <TooTallNate>hahaha that damn macro syntax always confuses me
23:52:14  <TooTallNate>i can never remember #func vs ##func
23:52:18  <tjfontaine>##foo#bar#_#baz
23:52:24  <trevnorris>heh
23:52:29  <TooTallNate>wat
23:52:30  <TooTallNate>hah
23:52:46  <TooTallNate>is _ a valid macro param?
23:53:42  <tjfontaine>I was just banging on the keyboard, but you can use # for concat stuff too
23:53:43  * groundwaterquit (Quit: groundwater)
23:53:46  <mordy_>hrm; does the VS project have a DLL target?
23:53:54  <mordy_>seems to only give me a static .lib
23:54:23  <tjfontaine>library%': 'static_library', # allow override to 'shared_library' for DLL/.so builds
23:54:26  <tjfontaine> 'component%': 'static_library', # NB. these names match with what V8 expects
23:54:41  <tjfontaine>lets see if vcbuild has options for those
23:54:51  <tjfontaine>it does
23:54:56  <mordy_>ahh ok
23:54:57  <tjfontaine>mordy_: vcbuild shared
23:55:46  <trevnorris>tjfontaine: re: if all the data is written question. I just noticed that it returns SYNC_RESULT, and my logic said that if they're not just passing back length then it's possible to not write the entire data to disk.
23:56:58  <mordy_>ahh, vcbuild /?
23:57:21  <tjfontaine>mordy_: slash shouldn't be necessary
23:57:29  <tjfontaine>vcbuild.bat may be