00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:06:23  * mikealquit (Quit: Leaving.)
00:20:06  * loladirojoined
00:21:06  * mralephquit (Ping timeout: 264 seconds)
00:28:51  * bradleymeckquit (Quit: bradleymeck)
00:31:23  * bradleymeckjoined
00:36:35  * mikealjoined
00:37:54  * bradleymeckquit (Quit: bradleymeck)
00:50:34  * dscapequit (Excess Flood)
00:50:53  * dscapejoined
00:57:09  * loladiroquit (Quit: loladiro)
00:58:21  * piscisaureus_joined
00:58:36  * loladirojoined
00:59:36  * piscisaureus_quit (Client Quit)
01:06:23  * philips_quit (Excess Flood)
01:09:41  * Benviequit
01:10:33  * philips_joined
01:18:28  * TooTallNatejoined
01:25:39  * jmar777joined
01:44:04  * lohkeypart
01:44:28  * lohkey_joined
01:44:28  * lohkey_quit (Client Quit)
01:47:45  * abraxasjoined
01:53:28  * jmar777quit (Remote host closed the connection)
01:56:52  <wolfeidau>Gday having issues with a native module, can't require('netif') when it is installed via npm for some reason, any ideas?
01:57:11  <wolfeidau>It is just a module with one method
01:59:49  <chilts>did it compile fine on install?
01:59:53  <chilts>want me to try it?
02:00:06  <chilts>heh, I was thinking this was the other channel :)
02:01:42  * indexzeroquit (Quit: indexzero)
02:15:40  * joshthecoderquit (Quit: Leaving...)
02:15:56  * c4milojoined
02:17:20  * indexzerojoined
02:18:43  <wolfeidau>Sorry just learnt about bindings...
02:25:26  <mmalecki>wolfeidau: #node.js channel might be better for you then
02:26:13  <wolfeidau>mmalecki: Yeah cheers
02:26:44  <wolfeidau>Thought it was a little off topic after posting it here
02:38:04  * indexzeroquit (Quit: indexzero)
02:44:35  * indexzerojoined
02:57:01  * mmaleckichanged nick to mmalecki[zzz]
03:01:44  * dapquit (Quit: Leaving.)
03:07:01  * brsonquit (Ping timeout: 246 seconds)
03:08:05  * joshthecoderjoined
03:29:52  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:36:44  * sblomquit (Ping timeout: 276 seconds)
03:41:36  * brsonjoined
03:59:24  * abraxasquit (Remote host closed the connection)
04:01:37  * dr34dl0ckjoined
04:06:37  * kazuponjoined
04:09:36  * loladiroquit (Quit: loladiro)
04:12:47  * dr34dl0ckquit (Quit: Colloquy for iPad - http://colloquy.mobi)
04:17:49  * loladirojoined
04:30:04  * abraxasjoined
05:13:43  * loladiroquit (Quit: loladiro)
05:27:38  * bradleymeckjoined
05:47:38  * abraxasquit (Remote host closed the connection)
06:02:08  * loladirojoined
06:16:04  * wolfeidauquit (Remote host closed the connection)
06:16:29  * felixgejoined
06:16:29  * felixgequit (Changing host)
06:16:30  * felixgejoined
06:26:27  * pooyajoined
06:35:18  * joshthecoderquit (Quit: Leaving...)
06:35:33  * pooyaquit (Quit: pooya)
06:47:46  * felixgequit (Quit: felixge)
06:49:40  * brsonquit (Quit: leaving)
06:50:46  * felixgejoined
06:50:47  * felixgequit (Changing host)
06:50:47  * felixgejoined
07:01:37  * `3rdEdenjoined
07:02:10  * abraxasjoined
07:09:34  * loladiroquit (Quit: loladiro)
07:19:16  * rendarjoined
07:36:44  * abraxasquit (Remote host closed the connection)
08:03:27  * AvianFluquit (Remote host closed the connection)
08:09:20  * rendarquit
08:10:30  * rendarjoined
08:16:56  * abraxasjoined
08:17:24  * wolfeidaujoined
08:22:55  * bradleymeckquit (Quit: bradleymeck)
08:24:17  * felixgequit (Quit: felixge)
08:30:18  * felixgejoined
08:31:36  * felixgequit (Client Quit)
08:41:22  * bradleymeckjoined
08:44:21  * indexzeroquit (Quit: indexzero)
08:48:18  * indexzerojoined
09:08:50  * kazuponquit (Remote host closed the connection)
09:59:07  * indexzeroquit (Quit: indexzero)
10:10:47  * bnoordhuisjoined
10:17:10  <MI6>joyent/node: Timothy J Fontaine master * 14ed173 : test: add TAP output to the test runner - http://git.io/tqlCqQ
10:18:30  <indutny>bnoordhuis: so...
10:18:32  <indutny>why TAP? :)
10:18:48  <bnoordhuis>indutny: because there's a lot of tools that know tap, probably
10:19:03  <bnoordhuis>tjfontaine is working on setting up CI, if i'm not mistaken
10:23:46  <indutny>aah
10:23:47  <indutny>ok
10:29:30  * loladirojoined
10:31:47  * loladiroquit (Client Quit)
10:41:48  <yawnt>hey i was trying to pass an error to the callback
10:42:15  <yawnt>but using Handle<Value> err = Exception::Error(String::New("err")) fails with invalid conversion from ‘v8::Value*’ to ‘v8::Primitive*’
10:42:18  <yawnt>any idea why?
10:44:39  * abraxasquit (Remote host closed the connection)
10:46:36  <bnoordhuis>yawnt: does Local<Value> err = ... work?
10:47:31  <yawnt>no
10:48:26  <bnoordhuis>then you should probably post some full code :)
10:49:48  <yawnt>https://gist.github.com/28b56bf1a7b1aa2f3a26
10:49:51  <yawnt>sorry :P
10:50:07  <yawnt>value is the result to a call to msgget()
10:50:36  <indutny>ah
10:50:41  <indutny>I think you should not use ternary here
10:50:55  <indutny>yawnt: split it into if
10:50:59  <yawnt>i did notice that without the ternary it works
10:51:04  <yawnt>why is that?
10:51:21  <indutny>well, I suppose because right and left side of ternary have different types
10:51:27  <indutny>bnoordhuis: please weigh in
10:51:32  <indutny>i'm getting out of answers here
10:52:06  <bnoordhuis>yes, different types
10:52:11  <bnoordhuis>Null() returns a Primitive
10:52:23  <bnoordhuis>*Handle<Primitive>
10:52:44  <yawnt>ah that's why
10:52:48  <yawnt>it compiles now
10:52:50  <yawnt>thanks!
10:52:53  <indutny>yw
11:02:14  <rendar>question, the uv_read, be it async or sync, in both cases put forward the current position (that one got by lseek()) of the file (a seekable stream) ?
11:07:17  <yawnt>fyi, Local<Value>::New(Null()) worked as well
11:07:21  <yawnt>:)
11:08:28  <bnoordhuis>rendar: depends. if you do a positional read, i.e. specify the offset, it uses pread()
11:08:38  <bnoordhuis>pread doesn't touch the file position
11:09:13  <bnoordhuis>rendar: btw, uv_read or uv_fs_read?
11:09:24  <bnoordhuis>i assumed you meant the latter
11:11:43  <rendar>yeah
11:11:44  <rendar>uv_fs_read
11:12:36  <rendar>bnoordhuis: i thought uv_read could be used as a general read, then it dispatched to the various uv_*_read() checking the type of the stream..
11:13:08  <bnoordhuis>rendar: not quite. it only works for uv_pipe_t, uv_tcp_t and uv_tty_t
11:13:32  <rendar>got it
11:15:13  <rendar>bnoordhuis: the thing is, in some platform (e.g. Windows) if i perform an async read (or write) with a seekable stream, say for example with ReadFile, the position pointer is not touched. So i guess libuv have to change this behavior manually, changing that pointer with the apis
11:16:39  <bnoordhuis>rendar: that's possible
11:17:21  <rendar>bnoordhuis: yeah, but i don't see anything similar in 'fs__read'
11:17:43  <bnoordhuis>in src/unix/fs.c or src/win/fs.c?
11:17:53  <rendar>src/win/fs.c
11:18:26  <bnoordhuis>piscisaureus is the one to ask about that
11:18:39  <rendar>thanks
11:18:40  <rendar>:)
11:33:35  <bnoordhuis>http_simple, buffer/1 with keep-alive on. before: 25.10 req/s, after: 14175.07 req/s
11:33:51  <bnoordhuis>it's not every day you implement a 565x speedup :)
11:36:44  <rendar>cool! :)
11:37:00  <rendar>bnoordhuis: this enormous speed up is due of keep-alive on ?
11:37:25  <bnoordhuis>rendar: no, it's because failed to pack the http headers and the response body into a single tcp packet
11:37:41  <rendar>oh
11:37:44  <bnoordhuis>if you send a string as a response it basically does response = headers + body
11:37:58  <bnoordhuis>but with a buffer as the body you get write(headers); write(body)
11:38:01  <rendar>bnoordhuis: yeah, a typical http thing
11:41:13  <rendar>bnoordhuis: but that write(headrs); write(body); is intented to writing into a buffer or into the socket?
11:41:57  <bnoordhuis>rendar: it writes to the socket. it's technically possible for both writes to end up in the same packet
11:42:06  <bnoordhuis>but in practice it never seems to happen, at least not on localhost
11:42:29  <rendar>hmm i see
11:43:02  <rendar>bnoordhuis: so 2 or more write() can be packed into a single tcp packet, but how? with some ioctl? it seems an OS thing :)
11:43:27  <bnoordhuis>rendar: oh, sorry. i was referring to net.Socket.write() back there
11:43:39  <rendar>oh i see
11:43:53  <bnoordhuis>which passes it off to libuv. libuv then does the actual write(2) or writev(2) syscall
11:44:01  <rendar>yeah
11:44:14  <rendar>well, in which cases writev is preferred?
11:44:38  <bnoordhuis>if you have gather/scatter i/o
11:44:51  <bnoordhuis>i.e. several buffers in disjointed places that all should be written out
11:45:09  <bnoordhuis>libuv prefers write() because it's usually slightly faster than writev()
11:45:24  <bnoordhuis>but there's still some room for improvement here, i think
11:45:27  <rendar>yes i know that, but i mean, in which cases libuv selected the gather/scatter i/o? or is the user that tells libuv to do that?
11:45:34  <bnoordhuis>yes, the user
11:45:38  <rendar>got it
11:45:44  <bnoordhuis>when you call uv_write() with bufs > 1
11:46:19  <bnoordhuis>but we should maybe optimize that and coalesce two uv_write() calls with bufs==1 into a single writev() instead of two write() syscalls
11:46:24  <rendar>i see
11:47:29  <rendar>bnoordhuis: you mean with a timer, which if expired and no other us_write has been called calls write(), instead calls writev() ?
11:48:03  <bnoordhuis>rendar: possibly but not necessarily
11:48:18  <bnoordhuis>a libuv stream handle has a list of pending writes
11:48:37  <bnoordhuis>if length(list) > 1, it could coalesce the entries
11:48:45  <bnoordhuis>but that takes some reshuffling
11:49:36  <rendar>i see
11:50:13  <bnoordhuis>in case you're wondering, it's the write_queue fields in include/uv-private/uv-unix.h
11:50:22  <rendar>bnoordhuis: so when you actually call uv_write, it simply append a packet into that stream handle's list?!
11:50:28  <bnoordhuis>yes
11:50:33  <rendar>oh, got it!
11:50:53  <bnoordhuis>it tries to write it out immediately but if that's not possible, it goes into the queue
11:51:22  <rendar>i see
11:51:32  <rendar>it not possible = another async i/o is pending?
11:52:08  <bnoordhuis>rendar: no, because the kernel's send buffer is full
11:52:14  <bnoordhuis>i.e. write() returns EAGAIN
11:52:19  <rendar>bnoordhuis: oh i see
11:52:39  <rendar>so if write()==EAGAIN -> put into the list
11:52:58  <bnoordhuis>yep
11:53:09  <bnoordhuis>or if there are already write reqs in the list
11:53:15  <rendar>i'm reading the src, but what is that stuff starting with ngx_* ?
11:53:16  <bnoordhuis>because you've got to send them out in order
11:53:28  <bnoordhuis>it's the queue implementation we stole from nginx
11:53:29  <rendar>yeah of course
11:53:43  <rendar>i see
11:53:53  <rendar>bnoordhuis: of course that is a interlocked list, i guess
11:53:53  <bnoordhuis>though nginx's is heavily inspired by the queue implementations from the linux and freebsd kernel sources
11:54:02  <bnoordhuis>it's an intrusive data structure
11:54:14  <bnoordhuis>i.e. you embed the ngx_queue_t in your own structs
11:54:16  <rendar>mm i see
11:54:30  <rendar>like a linked intrusive list
11:54:33  <bnoordhuis>yes
11:54:40  <rendar>yeah cool
11:54:43  <bnoordhuis>that's one benefit c has over c++
11:54:55  <bnoordhuis>intrusive data structures are technically illegal in c++
11:55:11  <bnoordhuis>though we still use them in node.js - don't tell anyone :)
11:55:24  <rendar>well, i've done an intrusive list and hash map time ago, basically your class should inherit from an hook class, for intrusive stuff :)
11:55:32  <rendar>bnoordhuis: ehehe
11:56:12  <rendar>bnoordhuis: like: struct IOReq : public IntrusiveListHook { stuf... };
11:56:31  <bnoordhuis>^ that's only legal if neither class/struct has virtual members
11:57:04  <rendar>well, there is a trick also for virtual members
11:57:12  <bnoordhuis>err, i'm assuming you do pointer arithmetic to look up the embedding class
11:57:20  <bnoordhuis>if not, disregard what i said :)
11:57:25  <rendar>it is used in boost's intrusive_list iirc, i will check
11:57:37  <rendar>bnoordhuis: oh yeah
11:57:45  <rendar>bnoordhuis: if you do pointer arithmetic it would be cumbersome
11:58:19  <bnoordhuis>yes, and dangerous - the c++ spec doesn't make guarantees about how or where the vtable pointer is laid out
11:58:34  <rendar>exactly
11:59:05  <rendar>with that intrusive structure you could use member function to manage it, you don't need pointer math anymore
12:00:05  <bnoordhuis>rendar: i'm thinking of something like this -> class foo { struct intrusive_list list; };
12:00:24  <rendar>btw this is an interesting point i wish to discuss: when libuv completed async i/o with the threadpool, is the threadpool itself that run the callback, or it just queue it to the caller thread?
12:00:28  <bnoordhuis>then you do foo* p = container_of(list_ptr, class foo, list)
12:00:38  <rendar>bnoordhuis: yeah right
12:01:09  <bnoordhuis>rendar: the callback gets run on the thread that called the uv_fs function
12:01:19  <rendar>i see
12:01:39  <rendar>so libuv ensures that every callback will be called from one thread
12:01:43  <bnoordhuis>yes
12:01:45  <rendar>always the same
12:02:03  <bnoordhuis>think of the uv_fs stuff as a thin shim over uv_queue_work
12:02:14  <rendar>bnoordhuis: yeah
12:02:24  <bnoordhuis>the work_cb gets called from the threadpool, the after_work_cb gets called from the original thread
12:03:07  <rendar>i see
12:03:24  <rendar>bnoordhuis: do you think it would be dangerous call the callback from the threadpool?
12:03:41  <bnoordhuis>rendar: in general or in the particular case of uv_fs_*?
12:03:50  <rendar>i mean in general
12:04:08  <bnoordhuis>not if your data structures are protected by locks
12:04:43  <rendar>bnoordhuis: your data structures = data used inside the callback scope?
12:05:04  <bnoordhuis>rendar: i mean data structures that are shared by both threads
12:05:25  <bnoordhuis>in general your callback will want to do something with the result
12:05:35  <bnoordhuis>that usually involves updating some state or whatever
12:05:47  <rendar>yeah
12:05:49  <bnoordhuis>if that state is accessed by multiple threads, you need proper locking
12:05:55  <rendar>i see
12:08:14  <rendar>bnoordhuis: but i think this arises a problem: what about if i have 2 async i/o pending R1 and R2 requests, (assuming the callback is runned by the threadpool) and they are passed to the thread pool to threads T1 (for R1) and T2 (for R2) but for the unpredictable scheduling of the OS, T2 is runned _before_ T1, even if the i/o request R1 happened _before_ R2? shouldn't that mess things up?
12:09:40  <bnoordhuis>rendar: why would that be an issue?
12:10:08  <bnoordhuis>if you want them run in order, you shouldn't start the second req until the first one has completed
12:10:42  <rendar>bnoordhuis: hmmm right, so basically you call other i/o operations directly form the callback
12:10:49  <bnoordhuis>yep
12:11:18  <rendar>yeah right, that absoltely makes sense
12:12:32  <bnoordhuis>mmalecki[zzz]: ping
12:34:05  * sgallaghjoined
13:09:29  * bradleymeckquit (Quit: bradleymeck)
13:15:55  <bnoordhuis>bleh, why is ab so shitty?
13:21:23  <bnoordhuis>ab -k with a server that responds with Connection: keep-alive, Transfer-Encoding: chunked hangs ab :/
13:21:59  * bnoordhuisgoes off to write a libuv+http_parser ab replacement
13:57:17  * loladirojoined
14:08:55  <indutny>hahaha
14:08:59  <indutny>bnoordhuis: finally
14:09:03  <indutny>I was waiting for it for ages
14:09:29  <bnoordhuis>i've been thinking about it for a while now
14:09:37  <indutny>and?
14:09:43  <bnoordhuis>today ab finally pissed me off one time too many
14:09:47  <indutny>haha
14:09:52  <indutny>well, I was thinking about it many times
14:10:00  <indutny>considering that siege is completely impredictable
14:10:13  <bnoordhuis>yeah, and not that useful for what i need
14:10:18  <indutny>indeed
14:10:20  <mmalecki[zzz]>bnoordhuis: pong
14:10:24  <indutny>bnoordhuis: if it'll support tls
14:10:27  <bnoordhuis>siege is probably okay if you want to simulate a user
14:10:29  <indutny>bnoordhuis: I would be really pleased
14:10:34  * mmalecki[zzz]changed nick to mmalecki
14:10:35  <bnoordhuis>i'll see what i can do
14:10:37  <indutny>bnoordhuis: simulate user - sounds quite vague
14:10:50  <bnoordhuis>indutny: i.e. a user clicking around on a website
14:10:50  <indutny>bnoordhuis: though, benchmarking tls is as hard as writing fast tls server
14:10:58  <indutny>bnoordhuis: it's still pretty vague :)
14:11:16  <bnoordhuis>mmalecki: pong yourself. i may have a performance patch that's worth testing
14:11:22  <indutny>haha
14:11:39  <indutny>pong yourself
14:11:43  <indutny>you know how is it called
14:11:48  <indutny>icmp spoofing
14:13:24  <bnoordhuis>mmalecki: https://github.com/bnoordhuis/node/compare/joyent:v0.8...bnoordhuis:http-pack-buffer <- but don't deploy right away :)
14:13:36  <bnoordhuis>do you guys do res.end(buf) somewhere?
14:13:46  <bnoordhuis>note buf, not string
14:14:10  <bnoordhuis>indutny: maybe interesting for you too
14:14:29  <indutny>yes it is
14:14:35  <mmalecki>bnoordhuis: unlikely that we do
14:14:37  <indutny>what is performance improvement?
14:15:02  <bnoordhuis>indutny: oh, a measly 750x
14:15:33  <bnoordhuis>indutny: on my system, i went from 250 req/s to nearly 20k req/s :)
14:15:41  <bnoordhuis>err, 25 req/s
14:16:12  <mmalecki>bnoordhuis: that patch, I call that cheating ;)
14:16:25  <bnoordhuis>you say that as if it's a bad thing :)
14:16:57  <bnoordhuis>the intriguing thing is it's been like that since at least 0.6.0 and no one's complained
14:35:31  <MI6>joyent/libuv: Vlad Tudose master * 4b115f8 : build: build libuv.a and libuv.so in different dirs Fixes #659. (+1 more commits) - http://git.io/GkPxmA
14:37:15  * travis-cijoined
14:37:15  <travis-ci>[travis-ci] joyent/libuv#969 (master - 4b115f8 : Vlad Tudose): The build passed.
14:37:15  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/0820be70084a...4b115f89bf54
14:37:15  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/3740049
14:37:15  * travis-cipart
14:49:59  * piscisaureus_joined
14:51:55  <piscisaureus_>rendar: why do you need to change the file position?
14:58:00  * indexzerojoined
15:11:26  * kazuponjoined
15:13:14  <indutny>piscisaureus_: bertje
15:13:15  <indutny>piscisaureus_: please land inlined assembly
15:13:18  <indutny>piscisaureus_: it's time
15:13:42  <indutny>piscisaureus_: and drunk wednesday is not a reason to not do it
15:23:44  * joshthecoderjoined
15:33:38  * kazuponquit (Remote host closed the connection)
15:37:49  * warzjoined
15:37:49  * warzquit (Changing host)
15:37:49  * warzjoined
15:45:10  <isaacs>good morning
15:45:30  <indutny>morning
15:46:53  <isaacs>bnoordhuis: re the pummel tests, one is trivial but the other... is not.
15:47:16  <bnoordhuis>morning isaacs
15:47:17  <isaacs>bnoordhuis: test/pummel/test-net-write-callbacks.js is triky
15:47:21  <bnoordhuis>what's the issue?
15:47:26  <isaacs>bnoordhuis: getting a stack overflow
15:47:41  <isaacs>streams2 is using recursion for something that was done with a loop before.
15:47:44  <isaacs>so i need to fix that
15:48:01  <bnoordhuis>you could add tail recursion to v8 :)
15:48:04  <isaacs>hahaha
15:48:07  <isaacs>that'd be nice :)
15:48:22  * kazuponjoined
15:48:28  <tjfontaine>bnoordhuis: $20 and a case of beer for you when it's done
15:48:30  <isaacs>i tried using nextTick, but it's *crazy* slow in this case, and gives me thousands of warnings.
15:48:31  * kazuponquit (Remote host closed the connection)
15:48:40  <isaacs>needs a more involved refactor
15:48:48  * mmaleckichanged nick to mmalecki[out]
15:49:06  <bnoordhuis>tjfontaine: i may prostitute my art but at least i'm not cheap
15:49:17  <indutny>bnoordhuis: 25$?
15:49:32  <bnoordhuis>indutny: what's that in real money?
15:49:39  <indutny>yes
15:51:13  <bnoordhuis>indutny, tjfontaine: in case you're wondering, c9 is effectively bankrupt. the days of free node.js sponsorship are over
15:51:29  <indutny>bnoordhuis: ok ok
15:51:31  <indutny>bnoordhuis: 30$
15:51:42  <indutny>you made me cry
15:51:50  <indutny>but that's the final price
15:52:03  <indutny>bnoordhuis: btw, I'm still receiving tons of email from c9
15:52:09  <indutny>bnoordhuis: so I know
15:52:15  <bnoordhuis>me too. it'll pass
15:53:15  <indutny>I don't understand benchmarking
15:53:15  <indutny>seriously
15:53:16  <indutny>I don't get it
15:53:34  <bnoordhuis>i have a t-shirt, 'ask me about benchmarking'
15:53:34  <indutny>especially for multi-threaded apps
15:53:35  <piscisaureus_>so people, in case you were wondering, c9.io is not going away or anything.
15:53:57  <tjfontaine>hrm
15:54:55  <indutny>piscisaureus_: bnoordhuis: why are you guys discussing it there? :)
15:55:07  <bnoordhuis>indutny: because knowing is half the battle
15:55:15  <bnoordhuis>indutny: so what's your benchmarking issue?
15:55:20  <indutny>bnoordhuis: tlsnappy
15:55:26  <indutny>bnoordhuis: I can't figure out what has changed
15:55:32  <indutny>and why performance degraded in 0.10
15:55:37  * sgallaghquit (Remote host closed the connection)
15:55:38  <indutny>I mean 0.9.4-pre
15:55:52  <indutny>I suppose event-loop
15:55:56  <indutny>is much more busy
15:56:05  <indutny>and slow at dispatching sockets to threads
15:56:08  * sgallaghjoined
15:56:12  <indutny>because threads are doing relatively the same work
15:56:12  <bnoordhuis>indutny: run perf and compare the logs, it's got a diff mode
15:56:19  <indutny>I can't run
15:56:20  <indutny>it
15:56:23  <indutny>well
15:56:25  <indutny>I'll try again
15:56:35  <indutny>but last time I was seeing some wierd VM-specific stuff
15:56:41  <indutny>you should remember it
15:56:44  <bnoordhuis>then don't run it in a vm :)
15:56:49  <indutny>hahah
15:57:02  <indutny>then buy me a notebook
15:57:10  <indutny>oh, that's not hipster
15:57:15  <indutny>I should name it laptop
15:57:21  <indutny>ok
15:57:22  <bnoordhuis>do it in the cloud
15:57:24  <indutny>shower time
15:57:29  <indutny>bnoordhuis: meh, cloud is so hipster
15:57:38  <bnoordhuis>it sounds dirty too, phrased like that
15:57:42  <bnoordhuis>"do it in the cloud"
16:01:01  <isaacs>bnoordhuis: this recursion/iteration thing is most likely also responsible for some lost performance
16:01:04  <isaacs>so that's good
16:01:34  <isaacs>i was able to reclaim about 40% of our lost 40% last night
16:01:42  <isaacs>the rest will be a bit more difficult.
16:02:03  <bnoordhuis>a wise man once said "the first 90% is easy"
16:02:08  <bnoordhuis>"it's the other 90%"
16:02:21  * dapjoined
16:03:27  <bnoordhuis>okay, biab
16:04:18  <isaacs>yeah, no shit on that one
16:14:24  <indutny>:)
16:14:26  <indutny>ttyl
16:14:37  <piscisaureus_>indutny: working on asm stuff
16:14:46  <indutny>piscisaureus_: oh my goodness!
16:14:49  <indutny>piscisaureus_: thank you :)
16:18:17  * `3rdEdenquit (Remote host closed the connection)
16:19:10  <sgallagh>bnoordhuis, isaacs: BTW, I meant to tell you guys: Node.js was officially accepted into the Fedora Project this week. I'll be working on npm in the new year.
16:27:49  <piscisaureus_>sgallagh: yay! :-)
16:28:17  <piscisaureus_>indutny: ok, aesni fails to compile without our openssl hacks. that's the last thing I need to sort out
16:29:03  * indexzerochanged nick to indexzero[brb
16:29:18  * indexzero[brbchanged nick to indexzero[brb-co
16:29:27  * indexzero[brb-cochanged nick to indexzero[brb]
16:37:35  <isaacs>piscisaureus_: i think this recursion/iteration thing may also be contributing heavily to the http slowdown
16:44:06  * mikealquit (Quit: Leaving.)
16:46:38  <isaacs>you know what would be awesome? `make test-just-the-failing-ones`
17:00:54  <tjfontaine>after playing yesterday, I'm fairly positive the test harness needs to be revamped :)
17:02:13  * AvianFlujoined
17:04:50  * indexzero[brb]changed nick to indexzero
17:05:01  * benoitcquit (Ping timeout: 245 seconds)
17:07:14  <isaacs>bnoordhuis: review? https://github.com/isaacs/node/compare/streams2-pummelfix
17:08:40  * benoitcjoined
17:10:35  <isaacs>sgallagh: that's great news!
17:10:46  <isaacs>sgallagh: so, of course, the big question...
17:10:50  <isaacs>sgallagh: is it caled "node"?
17:11:08  <isaacs>sgallagh: or at least, does `yum install nodejs` create a binary called "node"?
17:11:59  <sgallagh>isaacs: 'yum install nodejs' creates /usr/bin/node
17:12:35  <sgallagh>The 'node' ham-radio folks agreed to change their binary name
17:12:47  <sgallagh>On Fedora, at least. I don't pretend to speak for other distros
17:13:58  <sgallagh>isaacs: My next tasks are npm and trying to figure out if I can backport to RHEL 6 without SPDY patches in openssl
17:16:08  * joshthecoderquit (Quit: Leaving...)
17:30:57  <isaacs>sgallagh: \o/
17:31:04  <isaacs>sgallagh: npm doesn't use spdy at all
17:31:15  <isaacs>sgallagh: so it should* work fine
17:31:23  <isaacs>* should = "most dangerous warning sign"
17:31:29  * loladiroquit (Quit: loladiro)
17:31:44  <sgallagh>isaacs: Sorry, I shouldn't have put that in the same sentence
17:32:07  <sgallagh>I was talking about Node support for SPDY, and the npm stuff was separate
17:34:37  <tjfontaine>not sure why failures don't report appropriately on this view http://jenkins.atxconsulting.com:8080/job/nodejs-master/lastCompletedBuild/testReport/
17:45:30  * mikealjoined
17:55:03  <isaacs>indutny, bnoordhuis, piscisaureus_: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=0
17:55:29  <isaacs>for some reason that is unclear to me at the moment, smartos is getting like 500q/s against http_simple.js
17:55:32  * TooTallNatejoined
17:55:41  <isaacs>which is just... idon't even know what to make of that, really
17:55:47  <isaacs>yesterday it was way different
17:55:50  <isaacs>like, many thousands
17:58:22  * loladirojoined
18:03:05  * sblomjoined
18:04:11  * bentkusjoined
18:04:28  <bentkus>bnoordhuis: found the commit which made libuv http benchmarks slow?
18:05:28  * dapquit (Quit: Leaving.)
18:05:30  * `3rdEdenjoined
18:06:21  <piscisaureus_>isaacs: I have no access to that file..
18:06:24  <isaacs>oh... hrm
18:06:30  <piscisaureus_>isaacs: requested it.
18:07:05  <isaacs>piscisaureus_: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc
18:07:09  <isaacs>i just made it public-view
18:07:17  <isaacs>something's fuxored with ab on smartosdrone
18:07:24  <isaacs>so i'm trying to figure that out
18:07:39  <isaacs>but on osx, i've gotten the regression down to ~4%
18:07:53  * stagasquit (Ping timeout: 244 seconds)
18:07:59  <isaacs>piscisaureus_: the *fascinating* thing is that the std deviation in the results is also way lower, though
18:08:09  <isaacs>piscisaureus_: so, it's slightly slower, but much smoother.
18:08:32  <piscisaureus_>isaacs: so there is one thing about your benchmarks... how did you run them? did you alternate between streams1 or streams2
18:08:45  <piscisaureus_>or do all stream1 first, then all streams2
18:08:46  <piscisaureus_>?
18:08:52  <isaacs>piscisaureus_: all 1 first, then all 2
18:08:58  <isaacs>but i can alternate them quite easily
18:09:11  <piscisaureus_>well
18:09:20  <piscisaureus_>I wonder why the first one is an outlier
18:09:27  <isaacs>piscisaureus_: the first one is warming up teh vm
18:09:33  <isaacs>piscisaureus_: that's the first 10s of the server's life
18:09:43  <isaacs>piscisaureus_: all the numbers are a single node server.
18:09:50  <piscisaureus_>it could be that in subsequent benchmarks, ephemeral ports cause the benchmark to throttle
18:09:52  <isaacs>(ie, all the numbers in teh column)
18:10:09  <isaacs>piscisaureus_: it shouldnt'
18:10:10  <isaacs>sudo sysctl -w net.inet.ip.portrange.first=12000
18:10:10  <isaacs>sudo sysctl -w net.inet.tcp.msl=1000
18:10:10  <isaacs>sudo sysctl -w kern.maxfiles=1000000 kern.maxfilesperproc=1000000
18:10:18  * TooTallNatequit (Ping timeout: 264 seconds)
18:10:24  <piscisaureus_>isaacs: that's FD limit, not ephemeral ports
18:10:37  <piscisaureus_>isaacs: there's nothing you can do about ephemeral ports running out
18:10:39  <isaacs>oh, ok
18:10:40  <isaacs>right
18:10:55  <piscisaureus_>isaacs: so it could be interesting to try the benchmark 3 times
18:11:09  <piscisaureus_>isaacs: but with a significant time (e.g. minutes) between them
18:11:16  <piscisaureus_>and see if the numbers are consistently higher
18:11:24  <piscisaureus_>isaacs: also, is this with or without keepalive?
18:11:32  <isaacs>hmm.... without, i believe
18:11:46  <piscisaureus_>isaacs: right, so the ephemeral port issue is vulnerable
18:11:53  <isaacs>i'll run again with -
18:11:55  <isaacs>-k
18:12:04  <piscisaureus_>isaacs: sorry, I know this always takes a lot of time.
18:12:05  <isaacs>there was a few minutes between the runs
18:12:09  <isaacs>nono, it's good stuff
18:12:09  <piscisaureus_>ok, that's good
18:12:12  <isaacs>thanksf or the the feedback
18:12:25  <piscisaureus_>it'd be nice to have CI for this :-)
18:12:35  <isaacs>i added teh %-age change for all the individual runs
18:12:49  <isaacs>the first one is 11% fewer q/s, but then it regains a bit later.
18:12:57  <isaacs>so, yes, EP throttling is entirely possible.
18:13:30  <isaacs>if the streams2 speed is a bit slower, then that could also explain the lower st dev in that case.
18:13:39  <isaacs>because it doesn't hit the EP boundary as soon
18:14:01  * TooTallNatejoined
18:14:25  <bentkus>hello
18:14:27  <piscisaureus_>isaacs: also, the numbers are not that high in general. Is this on an air?
18:14:34  <isaacs>piscisaureus_: it's on my mbp
18:14:38  <piscisaureus_>hmm
18:14:40  <isaacs>which is a few years old at this point
18:14:43  <piscisaureus_>ah ok
18:14:53  <isaacs>these numbers are pretty much waht i expect.
18:14:59  <piscisaureus_>i was going to say, I easily hit 8000 r/s on my (pretty fast) mbp
18:15:02  <piscisaureus_>ok
18:15:05  <piscisaureus_>then it's good :-)
18:15:15  <piscisaureus_>(and for me that's on windows even)
18:15:16  <isaacs>really, using ab for this is always kind of shitty
18:15:21  <piscisaureus_>yeah
18:15:32  <piscisaureus_>isaacs: there still is this msft test cluster :-0
18:15:37  <piscisaureus_>isaacs: it has linux machines too
18:19:39  <isaacs>eah
18:21:44  <isaacs>so, ran the streams1 with keepalive
18:22:03  <isaacs>now waiting a bit before running the streams2 bench
18:26:44  * bentkusquit (Ping timeout: 252 seconds)
18:28:37  <isaacs>piscisaureus_: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc
18:28:42  <isaacs>piscisaureus_: much more what i was expecting.
18:28:45  * isaacssigh
18:28:59  <isaacs>but still, from 40% to 20%, that's pretty winful.
18:29:15  <piscisaureus_>isaacs: yeah, good job!
18:29:41  <piscisaureus_>isaacs: so the first 20% took you a day. I expect everything else to be fixed by tomorrow :-p
18:29:46  <isaacs>piscisaureus_: probably
18:29:55  <piscisaureus_>isaacs: nice :-)
18:30:02  <isaacs>so, i think we should go ahead and release 0.9.4 and spend the next month on performance.
18:30:13  <piscisaureus_>sure
18:30:18  <isaacs>node has a long and glorious history of perf regressions in unstable branches.
18:30:23  <isaacs>we always make it back at the last minute.
18:31:26  <isaacs>between the header string handling stuff, and some more streams2 optimizations, and the work on the libuv thread pool, i think we can certainly out-perform 0.8 by the end of january
18:39:06  <bnoordhuis>isaacs: re streams2-pummelfix, lgtm i guess
18:39:14  <bnoordhuis>i'm not really qualified to review it :)
18:39:25  <isaacs>bnoordhuis: get qualified, man!
18:39:32  * isaacsis going to start teaching streams2 seminars
18:39:54  <isaacs>bnoordhuis: for the low low price of US$1000, you TOO can be Streams 2 Certified!
18:40:06  * loladiroquit (Quit: loladiro)
18:40:24  <isaacs>actually, tha'ts a great business model for Node.
18:40:29  <bnoordhuis>i'll wait for the webinar
18:40:48  <isaacs>we should start training Node Certified Engineers and give them certificates and people will list NCE on their resume
18:41:05  <bnoordhuis>isaacs: what's sync mode?
18:41:16  <isaacs>bnoordhuis: sync mode is when _write(chunk,cb) calls cb() right away
18:41:20  <isaacs>bnoordhuis: ie, in the same tick
18:41:24  <bnoordhuis>ah
18:41:28  <isaacs>yes, this is terrible.
18:41:44  <isaacs>however, sometimes a lowlevel right really is done synchronously, and you have more work to do, and may as well do it right now
18:41:51  <isaacs>important especially for stdout/err
18:42:00  <bnoordhuis>what about call stack depth?
18:42:14  <isaacs>and for badly crafted userland streams, or crypto transform streams
18:42:23  <isaacs>so, the call stack depth was the problem that broke pummel
18:42:32  <isaacs>if you let it go past the timeout, eventually it crashes with a RangeError
18:42:42  <isaacs>the fix here is to use a loop instead of recursion for that.
18:42:49  <isaacs>(well, it recurses *once*, but that's fine)
18:42:56  <bnoordhuis>okay, but what about other streams?
18:43:09  <bnoordhuis>calling things on the same tick is opening the door for loops
18:43:20  <bnoordhuis>as in, too deep recursion
18:44:38  <bnoordhuis>it might be okay if it's only done for internal things
18:45:02  <bnoordhuis>but not with user callbacks
18:45:04  <isaacs>bnoordhuis: actually, i specifically made net and crypto do the horrible thing we probably don't want users to do, in order to make sure that the Writable class can handle it properly.
18:45:21  <isaacs>the cb provided to the xposed write() method is *never* called in the same tick
18:45:27  <bnoordhuis>ok
18:45:31  <isaacs>if we're sync, then that gets nexTtick'd
18:45:54  <isaacs>but the callback *we* provide *to* the user, if the *user* calls it immediately, well, we need to deal with that.
18:46:00  <isaacs>we can't expect that users will deal with it if *we* do that, though
18:46:18  <isaacs>loose in what you absorb, strict in what you secrete.
18:46:26  <isaacs>or something like that
18:49:33  * loladirojoined
18:54:07  * dapjoined
18:55:41  <MI6>joyent/node: isaacs master * 9f4c098 : streams2: Process write buffer in a loop, not recursively This fixes pum (+3 more commits) - http://git.io/L-wuBQ
18:56:30  * loladiroquit (Quit: loladiro)
18:59:04  <MI6>joyent/node: piscisaureus created branch openssl-asm2 - http://git.io/medDwA
18:59:23  <piscisaureus_>indutny: what do you think of that: --^
19:03:25  <creationix>bnoordhuis, are you using luvit for anything?
19:03:33  <creationix>I keep seeing you review pull requests
19:03:55  <bnoordhuis>creationix: not really but i have a soft spot for it
19:04:01  <creationix>cool, thanks
19:05:51  <piscisaureus_>haha
19:06:35  <piscisaureus_>I have to say, compiling on smartosdrone is a nice experience :-)
19:08:05  <piscisaureus_>sorry, I know I have asked this many times before
19:08:21  <piscisaureus_>but what again was the chant to build x64 on smartos? <-- TooTallNate isaacs
19:08:47  <TooTallNate>piscisaureus_: --dest-cpu=x64 ?
19:09:04  <piscisaureus_>I recall it was some env var
19:09:35  * bentkusjoined
19:10:10  <bentkus>hey piscisaureus_, did you see that I gathered all the info about dual stacking in one issue?
19:10:33  <piscisaureus_>ehm, no, but i can look
19:12:34  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:13:21  <bentkus>piscisaureus_: https://github.com/joyent/libuv/issues/635
19:13:52  * TooTallNatejoined
19:15:26  <piscisaureus_>ok, i've seen it
19:15:55  * bradleymeckjoined
19:16:57  * lohkeyjoined
19:22:09  <piscisaureus_>fuck
19:22:18  <piscisaureus_>make[1]: *** No rule to make target `/root/bert/out/Release/obj.target/openssl/deps/openssl/openssl/crypto/bf/bf_enc.copenssl/crypto/cast/c_enc.o', needed by `/root/bert/out/Release/obj.target/deps/openssl/libopenssl.a'. Stop.
19:22:38  <bentkus>who responsible for dis
19:23:43  <bentkus>bnoordhuis: did you find that commit which made the benchmarks slower?\
19:23:53  <bnoordhuis>bentkus: yep. it was me
19:23:59  <bentkus>what commit
19:24:22  <TooTallNate>piscisaureus_: looks like a space is missing in there
19:24:27  <piscisaureus_>yes
19:24:33  <TooTallNate>strange…
19:24:37  <bnoordhuis>bentkus: be2a217. the 'rethink relaxed accept() approach'
19:24:38  <piscisaureus_>TooTallNate: no, I did it myself
19:24:44  <TooTallNate>oh, haha
19:24:50  <TooTallNate>missing comma?
19:42:36  <bnoordhuis>okay, quality family time
19:42:40  <bnoordhuis>see you tomorrow guys
19:45:06  <TooTallNate>bnoordhuis: enjoy
19:46:35  <piscisaureus_>CRAP
19:46:43  <piscisaureus_>forgot another asm source :-(
19:46:47  * piscisaureus_cries
19:47:34  * brsonjoined
19:47:36  * bnoordhuisquit (Ping timeout: 264 seconds)
20:04:09  <MI6>joyent/node: Bert Belder openssl-asm2 * c77724f : openssl: enable optimized asm code on x86 and x64 (+2 more commits) - http://git.io/Nl5nFA
20:05:03  <piscisaureus_>yay
20:05:10  <piscisaureus_>smartos works :-)
20:19:11  <piscisaureus_>yay, linux works too. Only mac left
20:19:31  <piscisaureus_>gt reboot for that
20:22:14  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:34:35  * pooyajoined
20:42:24  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:46:13  * TooTallNatejoined
20:54:23  <creationix>so is "node-v0.8.15" the latest stable tag for libuv?
20:54:37  <creationix>were there no libuv changes for node 0.8.16?
20:55:42  * wolfeidauquit (Remote host closed the connection)
20:55:44  * bradleymeckquit (Quit: bradleymeck)
20:56:08  <TooTallNate>creationix: i find that unlikely
20:56:20  <TooTallNate>creationix: more likely somebody hasn't pushed the libuv tag yet
20:56:26  <creationix>I'm thinking so
20:58:36  <creationix>looks like 49977386e93dcdf7c0f0044a491c98d551f61db4 was the last commit in the 0.8 branch
21:00:58  * sgallaghquit (Ping timeout: 265 seconds)
21:17:32  * wolfeidaujoined
21:24:03  * TooTallNatequit (Ping timeout: 260 seconds)
21:24:49  * piscisaureus_joined
21:25:46  * TooTallNatejoined
21:26:20  <piscisaureus_>back
21:41:05  * lohkeypart
21:41:28  * lohkey_joined
21:41:28  * lohkey_quit (Client Quit)
22:03:05  * rendarquit
22:12:52  * AndreasMadsenjoined
22:14:47  * bentkusquit (Quit: Lost terminal)
22:15:50  * loladirojoined
22:19:15  * bentkusjoined
22:22:41  * pooyaquit (Quit: pooya)
22:32:57  * loladiroquit (Quit: loladiro)
22:42:49  * loladirojoined
22:45:17  * wolfeidauquit (Remote host closed the connection)
22:45:59  * c4miloquit (Remote host closed the connection)
22:47:44  * isaacsback
22:58:03  * warzquit
23:04:03  <TooTallNate>piscisaureus_: isaacs: i think creationix wanted someone to push a v0.8.16 libuv tag
23:05:29  * indexzeroquit (Quit: indexzero)
23:08:25  <creationix>yes please
23:08:41  * TooTallNatedoesn't have libuv commits
23:12:52  * `3rdEdenquit (Quit: zzzzz)
23:13:37  <isaacs>creationix: it's the same as 0.8.15
23:13:41  <isaacs>creationix: but sure
23:14:13  <MI6>joyent/libuv: isaacs created tag node-v0.8.16 - http://git.io/LWCj3g
23:14:50  <creationix>cool, I wasn't sure if it was the same
23:14:52  <creationix>thanks
23:24:14  * AndreasMadsenquit (Remote host closed the connection)
23:26:34  <bentkus>Hello mister anderson
23:27:05  * indexzerojoined
23:32:11  <isaacs>mbalho: Anyone interested in some reviewing? https://github.com/isaacs/node/compare/streams2-http-speedup
23:32:19  <isaacs>er, not intended for mbalho only
23:32:38  <isaacs>piscisaureus_, indutny, bnoordhuis, TooTallNate ^
23:35:22  <TooTallNate>isaacs: what's NB: ?
23:35:28  <isaacs>TooTallNate: Nota Bene.
23:35:34  <isaacs>literally, "note well"
23:35:41  <TooTallNate>ahhh
23:35:41  <isaacs>"take note of", "be advised", etc.
23:36:33  <isaacs>i guess that's confusing to people who didn't waste years learning latin in high school and doing liberal arts in college
23:39:31  <isaacs>TooTallNate: fixed.
23:39:58  <TooTallNate>isaacs: haha, i kinda liked it :p
23:40:25  <TooTallNate>isaacs: i'm not too up-to-speed on the perf issues… piscisaureus_ should probably take a look
23:40:50  <isaacs>yes.
23:41:01  <isaacs>LOOK AT THIS FLAMEGRAPH BECAUSE IT IS AWESOME!
23:41:01  <isaacs>http://static.izs.me/http-speedup-2012-12-19.svg
23:41:01  <LOUDBOT>FOR MY NEXT TRICK, EVERYBODY GIVE ME YOUR WALLETS
23:43:26  <bentkus>CHUCK TESTA
23:43:26  <LOUDBOT>WE'RE ALL WRONG ABOUT EVERYTHING
23:57:16  * brson_joined