00:00:09  * ircretaryjoined
00:00:33  <tjfontaine>are we having fun yet?
00:01:57  <isaacs>:)
00:01:57  <isaacs>almost
00:04:38  * benoitcquit (Excess Flood)
00:10:46  * benoitcjoined
00:15:09  * indexzerojoined
00:17:13  * loladirojoined
00:21:06  * loladiroquit (Client Quit)
00:35:15  * benoitcquit (Excess Flood)
00:35:18  <tjfontaine>bnoordhuis: heh, nice response on #4884
00:38:33  <bnoordhuis>that guy is such a moron. i wish github issues had a 'ban user' button
00:38:46  * benoitcjoined
00:39:33  <tjfontaine>haha
00:39:46  <isaacs>bnoordhuis: hahah
00:40:33  <isaacs>yeah, it's frustrating when someone cba to try the more recent version of node.
00:40:38  <isaacs>for all he knows, his problem is already fixed.
00:41:55  * brsonquit (Quit: leaving)
00:49:31  * diakopterjoined
00:52:33  <diakopter>hi; my build fails with VS2010 - is this known? https://gist.github.com/diakopter/5079171
00:52:55  <diakopter>(I'm glad to switch compilers if that's necessary)
00:53:23  <isaacs>bnoordhuis: i fixed that writable.end(chunk) 2 times thing
00:55:38  <tjfontaine>isaacs: are you saying that because of #4574?
00:56:16  <isaacs>tjfontaine: no, it's unrelated.
00:56:23  <tjfontaine>k I wasn't sure
00:56:26  <tjfontaine>I mean
00:56:38  <tjfontaine>I know that issue is unrelated, but if that's what was prompting your statement now :)
00:56:43  <isaacs>tjfontaine: just a case i noticed where you've told it to write some bytes, and they don't get written, but also you don't get an error.
00:56:49  <isaacs>i don't recall how i got there, exactly
00:57:12  <isaacs>oh! probably messing around with SimpleProtocol example and trying to figure out why it wasn't working. also led to the writeAfterFIN error message thingie
00:57:22  <tjfontaine>ah
00:59:40  <bnoordhuis>diakopter: https://github.com/joyent/libuv/pull/728 <- does that fix it for you?
00:59:54  <bnoordhuis>isaacs: i was just looking at the PR
00:59:58  * loladirojoined
00:59:59  <isaacs>kewl
01:00:02  * loladiroquit (Client Quit)
01:01:35  <isaacs>so, i am also planning to refactor Writable so that _write gets (chunk, encoding, cb) instead of ([chunk,encoding],cb) or (chunk,cb)
01:01:58  <isaacs>it's angering V8 to be violating its strong type preference.
01:02:22  <tjfontaine>agreed
01:02:41  <isaacs>of course... we'll still have _write being called sometimes with a Buffer and sometimes with a String
01:02:45  <isaacs>as the first arg
01:02:51  <isaacs>but i'm not sure any way around that
01:03:01  <diakopter>bnoordhuis: I'm not sure. I ran vcbuild again, and it finished with no errors.. how do I run some tests?
01:03:26  <tjfontaine>isaacs: in a common pattern that happens?
01:03:50  <diakopter>bnoordhuis: oh, just found the run-tests.exe
01:04:02  <isaacs>tjfontaine: yeah
01:04:08  <isaacs>tjfontaine: any time you do console.log('flurb')
01:04:18  <isaacs>tjfontaine: that's calling Socket.write('flurb')
01:04:28  <isaacs>which in turn will call Socket.write('flurb', 'utf8', cb)
01:04:38  <isaacs>er, Socket._write('flurb', 'utf8', cb)
01:05:19  <tjfontaine>well console log could do the buffer conversion heh
01:05:20  <isaacs>but i'm pretty sure the overhead of variadic _write chunk type will be greater than the overhead of pre-_write buffer-izing
01:05:32  <diakopter>bnoordhuis: I got 5 test failures. should I nopaste the output?
01:05:40  <isaacs>because then we do handle.writeBuffer() or handle.writeUtf8String() etc
01:05:53  <isaacs>so that we don't create a separate buffer for ti
01:05:53  <tjfontaine>nod
01:06:35  * loladirojoined
01:07:33  <diakopter>I updated the above gist.. in case anyone's curious to see the 5 test failures
01:07:57  * loladiroquit (Client Quit)
01:11:12  * loladirojoined
01:14:04  <diakopter>bnoordhuis: thanks for the tip!
01:15:12  * loladiroquit (Client Quit)
01:16:09  * bradleymeckjoined
01:17:13  * loladirojoined
01:20:21  <bnoordhuis>diakopter: the threadpool_cancel_* fail because uv_cancel is only implemented on Unices right now
01:20:43  <bnoordhuis>there should be a 'test' in that sentence
01:21:05  <bnoordhuis>i guess fs_file_loop is supposed to pass
01:21:18  <tjfontaine>complete sentences overrated
01:21:21  <diakopter>bnoordhuis: seems to me those tests should auto-pass on Windows, then
01:21:56  <tjfontaine>diakopter: not implemented failing tests are a reminder
01:23:00  * loladiroquit (Quit: loladiro)
01:23:41  <bnoordhuis>isaacs: the node.js cla is different from libuv's?
01:23:53  <bnoordhuis>i always point people to nodejs.org/cla.html...
01:24:19  <bnoordhuis>are you thinking of http_parser's cla maybe?
01:27:05  <isaacs>oh, maybe
01:27:16  <isaacs>huh. that guy seems to not be on the google doc
01:28:26  <isaacs>ohh, spelled his name differently
01:29:47  <MI6>joyent/node: isaacs master * e428bb7 : cluster: Rename destroy() to kill(signal=SIGTERM) Fix #4133, bringing th (+1 more commits) - http://git.io/5rYi0w
01:30:50  * qmx|awaychanged nick to qmx
01:31:43  * indexzeroquit (Quit: indexzero)
01:32:45  * diakopterpart
01:38:01  * abraxasjoined
01:40:10  * benoitcquit (Excess Flood)
01:40:29  <bnoordhuis>hm, seems linux 3.9-rc1 fixes a denial-of-service for ipv6 where all socket objects end up in the same hash table bucket
01:40:45  <tjfontaine>cute
01:41:25  <bnoordhuis>also explains (or possibly explains) some of the weird ipv6 performance i was seeing
01:41:55  <bnoordhuis>guess i'm forced to upgrade now :)
01:42:33  <bnoordhuis>cherry-picking the patch would probably work as well but where's the fun in that?
01:43:59  <MI6>nodejs-master: #51 FAILURE windows-x64 (11/546) windows-ia32 (11/546) osx-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/51/
01:46:46  * benoitcjoined
02:00:11  * hzquit
02:00:16  <bnoordhuis>another nice denial-of-service: slow start tcp sockets with a zero send congestion window cause an infinite loop in 3.6 and up
02:01:30  <bnoordhuis>reading through recent kernel commits is not good for one's peace of mind
02:05:11  <brucem>bnoordhuis: have to wonder what led to them being found … active attacks, code inspection, fuzz testing somewhere ...
02:05:25  <brucem>bnoordhuis: and who knew about them prior to them being found and just hadn't bothered to disclose.
02:08:47  <bnoordhuis>brucem: i think it's a combination of all three. maybe not attacks but people running into them as bugs
02:11:23  <bnoordhuis>re: fuzz testing, http://codemonkey.org.uk/projects/trinity/ - it's found quite a few bugs so far, including one or two security issues
02:11:36  <bnoordhuis>okay, off to bed. sleep tight all
02:13:05  <isaacs>g'nite bnoordhuis
02:16:01  * bnoordhuisquit (Ping timeout: 248 seconds)
02:24:23  * brsonjoined
02:31:52  * kazuponjoined
02:40:26  * benoitcquit (Excess Flood)
02:42:48  * benoitcjoined
02:43:47  * bradleymeckquit (Quit: bradleymeck)
03:00:25  * abraxasquit (Remote host closed the connection)
03:00:40  * bradleymeckjoined
03:00:55  * kazuponquit (Remote host closed the connection)
03:22:03  * bnoordhuisjoined
03:27:04  * kazuponjoined
03:27:06  * bnoordhuisquit (Ping timeout: 264 seconds)
03:27:55  * bradleymeckquit (Quit: bradleymeck)
03:29:05  * bradleymeckjoined
03:32:09  * bradleymeckquit (Client Quit)
03:33:11  * bradleymeckjoined
03:36:41  * bradleymeckquit (Client Quit)
03:40:51  * benoitcquit (Excess Flood)
03:47:14  * MI6quit (Ping timeout: 252 seconds)
03:48:48  * benoitcjoined
03:52:12  * loladirojoined
03:53:27  * bradleymeckjoined
03:59:53  * bradleymeckquit (Quit: bradleymeck)
04:05:02  * abraxasjoined
04:29:53  * qmxchanged nick to qmx|away
04:37:32  * bradleymeckjoined
04:38:53  * mikealquit (Quit: Leaving.)
04:41:12  * benoitcquit (Excess Flood)
04:42:17  * benoitcjoined
04:44:06  * mikealjoined
04:48:23  * kazuponquit (Remote host closed the connection)
04:50:21  * brsonquit (Quit: leaving)
05:03:32  * mikealquit (Quit: Leaving.)
05:04:20  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
05:09:28  * mikealjoined
05:27:00  * kazuponjoined
05:34:07  <hij1nx>indutny: i realized that i wrote something very similar to what you had done so i scrapped it and just used your module.
05:40:43  * loladiroquit (Quit: loladiro)
05:41:32  * benoitcquit (Excess Flood)
05:45:41  * indexzerojoined
05:45:48  * benoitcjoined
05:50:50  * loladirojoined
05:54:05  <isaacs>wanna see something awesome?
05:54:07  <isaacs>http://static.izs.me/benchmark-write-refactor-vs-0.8.html
05:55:31  <tjfontaine>now you're talking
05:57:01  <isaacs>https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=8
05:57:08  <isaacs>that's benchmark/http.sh results
05:57:15  <isaacs>v0.8 vs my writable-refactor branch
05:57:27  <isaacs>hard to measure on smartos, though.
05:57:31  <isaacs>the variability is much higher.
05:57:38  <isaacs>i think probably just because of the CPU bursty effect
05:57:57  <isaacs>benchmarks really want a sustained guaranteed cpu level
05:58:15  <tjfontaine>indeed
06:10:49  * benoitcquit (Excess Flood)
06:13:05  * MI6joined
06:13:08  <MI6>joyent/node: Rod Vagg v0.8 * a6a1659 : link to LevelUP modules wiki page, not level-hooks - http://git.io/8ut8eg
06:14:47  * benoitcjoined
06:19:27  * wolfeidauquit (Remote host closed the connection)
06:25:19  <MI6>nodejs-master: #52 FAILURE windows-x64 (11/546) linux-ia32 (1/546) windows-ia32 (11/546) osx-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/52/
06:29:19  * loladiroquit (Quit: loladiro)
06:36:14  <MI6>nodejs-v0.8: #20 FAILURE linux-x64 (2/467) osx-ia32 (1/467) smartos-ia32 (1/467) windows-x64 (2/467) windows-ia32 (2/467) osx-x64 (2/467) smartos-x64 (1/467) linux-ia32 (3/467) http://jenkins.nodejs.org/job/nodejs-v0.8/20/
06:42:27  * loladirojoined
06:45:03  * wolfeidaujoined
06:59:48  * Raynosquit (Ping timeout: 252 seconds)
07:12:33  * mikealquit (Quit: Leaving.)
07:20:01  * mikealjoined
07:30:23  * kevireillyquit (Read error: Connection reset by peer)
07:30:38  * rendarjoined
07:30:45  * kevireillyjoined
07:35:27  * kevireillyquit (Ping timeout: 245 seconds)
07:37:48  * kazuponquit (Remote host closed the connection)
07:40:42  * kevireillyjoined
07:54:41  * kevireillyquit (Write error: Connection reset by peer)
07:56:44  * kazuponjoined
08:00:19  * indexzeroquit (Quit: indexzero)
08:09:34  * dominictarrjoined
08:10:38  * dominictarrquit (Remote host closed the connection)
08:11:41  * dominictarrjoined
08:21:25  * indexzerojoined
08:32:54  * bradleymeckquit (Quit: bradleymeck)
08:36:21  * csaohjoined
08:38:49  * bradleymeckjoined
08:52:54  * slaskisjoined
09:07:10  * AvianFluquit (Remote host closed the connection)
09:10:03  * piscisaureus_joined
09:14:48  * `3rdEdenjoined
09:16:28  * kazuponquit (Remote host closed the connection)
09:23:13  * loladiroquit (Quit: loladiro)
09:29:03  * Raynosjoined
09:31:08  * loladirojoined
09:32:45  * loladiroquit (Client Quit)
09:46:50  * kazuponjoined
09:55:57  * csaohquit (Quit: csaoh)
09:56:17  * kazuponquit (Ping timeout: 252 seconds)
09:56:52  * kazuponjoined
10:05:51  * piscisaureus_quit (Ping timeout: 245 seconds)
10:13:51  * dominictarrquit (Quit: dominictarr)
10:14:33  * kazuponquit (Remote host closed the connection)
10:15:18  * kazuponjoined
10:16:56  * piscisaureus_joined
10:25:07  * Kakerajoined
10:26:04  * dominictarrjoined
10:29:27  * csaohjoined
10:29:57  * Kakeraquit (Read error: Connection reset by peer)
10:36:42  * kazuponquit (Remote host closed the connection)
10:57:38  <roxlu>hi guys, when I have a client socket, what's the correct way of disconnecting / cleaning up the connect? (when my app closes)
11:00:25  <roxlu>I mean, when my app closes, I need to wait for the async call to happen; but I actually would need to block my destructor (using c++) till the socket is really disconnected
11:00:26  <indutny>uv_close
11:03:13  <roxlu>indutny: thanks, but how would I handle that in a destructor (or sig callback)
11:03:29  <indutny>oh, there's a simple way
11:03:34  * abraxasquit (Remote host closed the connection)
11:03:35  <indutny>if destructor is called before connection is closed
11:03:44  <indutny>then you'll need to allocate uv_tcp_t
11:03:50  <indutny>and free it in uv_close's callback
11:04:30  <indutny>class MyClass { uv_tcp_t* tcp; MyClass() { tcp = new uv_tcp_t(); } ~MyClass() { uv_close(tcp, deletingFunction) } }
11:04:46  <roxlu>but uv_close is async, right?
11:05:03  <indutny>yes
11:05:11  <indutny>definitely async
11:05:23  <roxlu>so after calling uv_close my MyClass is deallocated
11:05:32  * hzjoined
11:05:54  <roxlu>and wouldn't it result in unexpected behaviour when uv calls my deletingFunction ?
11:05:58  <indutny>no
11:06:07  <indutny>void deletingFunction(uv_handle_t* handle) { delete handle }
11:06:16  <indutny>deletingFunction is a static function
11:06:30  <indutny>not a method
11:06:55  <roxlu>ok, thanks
11:07:24  <roxlu>I probably miss some info about the destruction of an application
11:07:35  <indutny>erm?
11:07:53  <roxlu>I thought that as soon as my d'tor has returned it stops executing anything related to the class
11:08:26  <indutny>to the instance
11:08:28  <indutny>not class itself
11:08:34  <roxlu>yes
11:08:37  <indutny>and static function is a member of class
11:08:41  <indutny>not related to instance at all
11:08:46  <indutny>you can't even use `this` in it
11:08:50  <roxlu>yeah I see that now indeed. thanks a lot
11:08:54  <indutny>np
11:25:59  * tellnesjoined
11:26:30  <roxlu>indutny: I've got my uv_sock_t on the stack and calling uv_close() when it isn't connected yet gives me a assertion failed in src/unix/core.c 140.
11:26:43  <roxlu>Do I first need to check if the sock is actually connected before calling close"
11:28:04  <indutny>looks like you're passing something wrong to it
11:28:08  <indutny>not socket
11:28:13  <indutny>probably it was either already destroyed
11:28:16  <indutny>or deallocated
11:28:27  <indutny>and what's uv_sock_t?
11:28:34  <roxlu>uhh uv_tcp_t
11:28:40  <indutny>ok
11:29:20  <roxlu>This basic client socket wrapper: https://github.com/roxlu/roxlu/blob/master/addons/UV/include/uv/ClientSocket.h
11:29:57  <roxlu>everything works fine but I just want to make sure it shutdowns down nicely when the object gets destructed
11:30:57  <roxlu>so in my d'tor I want to call: uv_close(&sock, NULL); (if a null callback is possible)
11:31:01  <indutny>heh
11:31:04  <indutny>that won't work
11:31:07  <indutny>I told ya
11:31:11  <indutny>allocate uv_tcp_t
11:31:18  <indutny>and destroy it in uv_close's callback
11:31:25  <roxlu>ok so on the stack is not an option
11:31:30  <indutny>definitely not
11:31:39  <roxlu>ok thanks
11:32:24  * csaohquit (Quit: csaoh)
11:37:05  * kazuponjoined
11:39:10  <roxlu>indutny: it gives me this assertion error when uv_tcp_init() hasn't been called and I call uv_close() on the handle. I know this is not also not the way it's supposed to work, but is there a way to check if a uv_tcp_t is initialized so I can check that myself before calling close() ?
11:39:20  <indutny>ah
11:39:24  <indutny>well, you need to call init
11:39:29  <indutny>otherwise it's just a junk
11:39:39  <indutny>chunk of dirty uninitialized memory
11:39:43  <indutny>what else have you expected
11:40:33  <roxlu>I call init, but in my connect() funtion
11:40:43  <roxlu>but I'll move it up to my c'tor
11:40:45  <roxlu>but I'll move it up to my c'tor
11:40:48  <roxlu>oh..
11:40:53  * dominictarrquit (Quit: dominictarr)
11:41:39  * kazuponquit (Ping timeout: 245 seconds)
11:50:08  <roxlu>indutny: I'm curious why libuv is so easy with doing things on the heap? allocating when not really necessary seems like a waste of cpu cycles
11:51:01  <indutny>it's ok to not allocate, but handle should be alive until callback will be invoked
11:51:28  <indutny>and when you're using on-stack variable - function, holding it, returns before callback is invoked
11:51:34  <roxlu>yeah I see what you mean
11:51:35  <indutny>asynchronous model
11:51:42  <indutny>there're no other way to deal with it
11:51:55  <indutny>you either not destroy things until they're finished/closed
11:51:59  <indutny>or allocate them separately
11:52:08  <indutny>depending on what you're doing and how you can do it
11:52:57  <rendar>indutny: thats because the thread in the threadpool can receive a completion with an address of a destroyed object causing segfault?
11:53:08  <indutny>yes, undefined behaviour
11:54:12  <rendar>indutny: what about the user will not destroy the uv_stream_t until on_close() callback is not called?
11:54:24  <indutny>it'll work
11:55:07  <rendar>indutny: so basically if we assure that the uv_stream_t will be alive until on_close(), we don't need that heap allocation, in theory..
11:55:44  * csaohjoined
11:59:09  <indutny>yes
11:59:11  <indutny>not in theory
11:59:22  <indutny>this really works
11:59:29  <rendar>yep
12:03:13  * kazuponjoined
12:08:47  * kazuponquit (Ping timeout: 255 seconds)
12:09:16  * indexzeroquit (Quit: indexzero)
12:30:03  * bnoordhuisjoined
12:37:44  * qmx|awaychanged nick to qmx
12:47:20  * piscisaureus_quit (Ping timeout: 252 seconds)
12:51:23  * piscisaureus_joined
12:56:26  * bradleymeckquit (Quit: bradleymeck)
13:02:54  * piscisaureus_quit (Ping timeout: 245 seconds)
13:04:11  * abraxasjoined
13:06:55  <indutny>bnoordhuis: hey ben
13:07:01  <indutny>what you're up to today
13:08:44  * abraxasquit (Ping timeout: 255 seconds)
13:09:08  <bnoordhuis>indutny: nothing much
13:09:13  <bnoordhuis>you?
13:10:22  <indutny>reading about u-kernels
13:10:33  <indutny>and IA32 details
13:11:08  <indutny>bbiab
13:12:04  * piscisaureus_joined
13:19:22  * piscisaureus_quit (Read error: No route to host)
13:19:44  * piscisaureus_joined
13:31:23  * bnoordhuisquit (Ping timeout: 245 seconds)
13:57:55  * bnoordhuisjoined
14:02:40  <rendar>indutny: what are u-kernels?
14:06:19  * bnoordhuisquit (Ping timeout: 252 seconds)
14:17:15  * kazuponjoined
14:44:50  <indutny>back
14:52:28  * c4milojoined
14:58:12  * bradleymeckjoined
14:58:27  * kazuponquit (Remote host closed the connection)
14:59:09  * bradleymeckquit (Client Quit)
14:59:31  * bnoordhuisjoined
15:00:18  * piscisaureus_quit (Ping timeout: 256 seconds)
15:11:18  * piscisaureus_joined
15:13:53  <bnoordhuis>piscisaureus_: for when you're feeling better, there's a couple of libuv patches you should review
15:14:05  <bnoordhuis>and maybe answer rvagg on the mailing list about that ssize_t thing
15:14:21  <piscisaureus_>bnoordhuis: i know, and i will.
15:15:11  <piscisaureus_>bnoordhuis: re rvagg's question - do you think it could be somehow related to including uv.h in a c++ unit?
15:15:32  <piscisaureus_>that one makes the mind boggle
15:15:39  * bradleymeckjoined
15:15:53  <piscisaureus_>jimmies rustled
15:16:29  <bnoordhuis>i don't know, possibly, who can tell with msvc?
15:21:43  <piscisaureus_>I don't understand why people are reporting that advapi.lib isn't linked
15:21:47  <piscisaureus_>it all builds fine for me
15:22:12  <piscisaureus_>[% 1|+ 3|- 0]: loop_stop
15:22:12  <piscisaureus_>`loop_stop` failed: exit code 3
15:22:12  <piscisaureus_>Output from process `loop_stop`:
15:22:12  <piscisaureus_>Assertion failed in test\test-loop-stop.c on line 65: prepare_called == 3
15:22:22  <piscisaureus_>Someone did not run the tests before landing a patch :-(
15:23:37  <rendar>piscisaureus_: hi, does libuv uses TransmitFile in windows to emulate sendfile() ?
15:24:14  <piscisaureus_>D:\libuv>grep TransmitFile -r src
15:24:16  <piscisaureus_>no
15:24:45  <MI6>joyent/node: Xidorn Quan master * 009ba02 : dns: fix ReferenceError in resolve() error path A typo in the variable n - http://git.io/z3WbFQ
15:25:11  <indutny>piscisaureus_: my irc client replaced your path with something scary
15:25:16  <indutny>C: D: E: F: G:
15:25:22  <indutny>ah, that was D:
15:31:53  <isaacs>so, i got a green benchmark result vs v0.8 last night
15:32:02  <isaacs>http://static.izs.me/benchmark-write-refactor-vs-0.8.html
15:32:12  <indutny>good!
15:32:18  <indutny>was that this data, encoding patch?
15:32:23  <isaacs>yeah
15:32:32  <indutny>so still explicit is better than implicit? :)
15:32:50  <indutny>what has it actually did?
15:32:55  <indutny>s/did/done/
15:34:51  <isaacs>the big diff was that we're passing arguments to _write() that are a bit more consistent
15:35:07  <isaacs>and that the write()/_write()/onwrite() methods are all split up and organized better.
15:35:20  <isaacs>there's still a bit more that can be done in the Readable class, and in Socket
15:35:32  <indutny>great
15:35:44  <isaacs>it's tricky work, though. you have to make a tiny tiny change, run all the tests, make another tiny change, etc.
15:35:49  <isaacs>because it's so easy to screw up
15:36:08  <isaacs>turns out computers do exactly what you tell them, even if you tell htem to do the wrong things in the wrong order.
15:36:13  <isaacs>they're not very bright.
15:36:14  <indutny>I hate heuristics :)
15:36:19  <isaacs>yeah
15:36:34  <indutny>I love determinstics
15:36:35  <indutny>haha
15:36:38  <isaacs>i'm seeing hardly any deopts or bailouts in the net bench scripts now, though
15:36:41  <isaacs>so that's a plus
15:37:11  <indutny>kewl
15:38:19  * mikealquit (Quit: Leaving.)
15:38:43  <isaacs>indutny: how do you feel about hte semantics changes?
15:38:59  <isaacs>indutny: now _transform() doens't get an output function, and _write gets a (usually useless) encoding arg
15:39:10  <indutny>well
15:39:14  <isaacs>but i kind of like how _transform() and _write() suddenly have the same signature
15:39:18  <indutny>last one is not very friendly
15:39:25  <indutny>heh
15:39:47  <isaacs>of course, if you don't do decodeBuffers:false, then _write will always get a buffer, and encoding will always be ''
15:39:55  <indutny>yeah, I understand
15:40:03  * stagasjoined
15:40:13  <isaacs>only for TCP is this an issue, and we could probably do the same for CryptoStreams also, and get some better performance there.
15:40:15  <indutny>so, despite it's friendlessness, it seems ok to me
15:40:26  <MI6>nodejs-master: #53 FAILURE windows-x64 (11/546) windows-ia32 (12/546) osx-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/53/
15:40:29  <saghul>piscisaureus_ re uv_stop, test passes for me :-O
15:41:03  <piscisaureus_>:o
15:41:29  <indutny>D:
15:41:39  <saghul>piscisaureus_ could it be that the loop iterates more times on uv-win?
15:42:03  <piscisaureus_>euh... i didn't look at it yet
15:42:14  <piscisaureus_>possibly, yes
15:42:49  * AvianFlujoined
15:43:01  * bradleymeckquit (Quit: bradleymeck)
15:43:34  <saghul>maybe the test should say >= 2, since the number of iterations is not guaranteed?
15:54:32  <piscisaureus_>brb
15:54:41  <piscisaureus_>bnoordhuis: rvagg was just helped
15:55:21  * kazuponjoined
15:56:19  <MI6>joyent/node: isaacs master * 119cbf4 : stream: Don't require read(0) to emit 'readable' event When a readable l - http://git.io/s1XiFA
15:59:09  * piscisaureus_quit (Ping timeout: 245 seconds)
16:00:39  * kazuponquit (Ping timeout: 252 seconds)
16:02:42  * piscisaureus_joined
16:12:29  <MI6>nodejs-master: #54 FAILURE windows-x64 (11/546) windows-ia32 (11/546) osx-x64 (1/545) http://jenkins.nodejs.org/job/nodejs-master/54/
16:13:36  <isaacs>piscisaureus_: It's super annoying that fs.unlink() fails on read-only files on Windows
16:13:43  <piscisaureus_>muhaha
16:13:48  <piscisaureus_>isaacs: yeah.
16:13:59  <isaacs>piscisaureus_: I think libuv should just chmod regular files before deleting them
16:14:01  <piscisaureus_>isaacs: so ... call bill gates once more?
16:14:07  <piscisaureus_>nah
16:14:10  <isaacs>piscisaureus_: yeah, or that.
16:14:38  <piscisaureus_>isaacs: it'd be weird. The ususal meaning of the +r bit on windows (which is fairly uncommon) means don't modify or delete
16:14:47  <piscisaureus_>I think we should rather not make chmod set the +r bit
16:14:54  <isaacs>ok..
16:14:55  <piscisaureus_>and make it a complete no-op
16:15:02  <isaacs>but doing chmod 0666 on the file before unlinking it work
16:15:28  <piscisaureus_>yes chmod 0666 removes the readonly bit
16:15:54  <piscisaureus_>I agree with you that we should address this but I am not sure if ignoring the +r bit is the way to go
16:16:58  <piscisaureus_>or rather - I'd like to have some more input and not only cater for what is practical for NPM
16:17:15  <bnoordhuis>sounds like it'll confuse windows users
16:17:16  <piscisaureus_>Are there any extremely windows-y folks around?
16:18:40  <bnoordhuis>i bought windows 95. i didn't have a PC at the time but the ads made it sound like you just had to have windows 95
16:18:44  <bnoordhuis>windows-y enough?
16:18:57  <piscisaureus_>bnoordhuis: ok show me your pinball highscore
16:19:43  <bnoordhuis>i play minesweeper at the grandmaster level
16:19:45  <piscisaureus_>which reminds me
16:19:47  <piscisaureus_>http://blogs.msdn.com/b/oldnewthing/archive/2012/12/18/10378851.aspx
16:20:10  <isaacs>piscisaureus_: so, npm is going to work aroudn this, because npm needs to work on 0.8
16:20:13  <isaacs>piscisaureus_: that's not the issue.
16:20:24  <piscisaureus_>isaacs: yes - that's great
16:20:24  <isaacs>piscisaureus_: npm is just the thign that i noticed that hit this. but i think grunt has as well.
16:20:42  <isaacs>piscisaureus_: i removed chmod from rimraf (since it didn't belong there) and a bunch of windows users said it broke their stuff
16:21:06  <isaacs>piscisaureus_: i could just have rimraf do this, of course. chmod non-directory files to remove the +r
16:21:32  <isaacs>but i like how simple rimraf is
16:22:05  <isaacs>piscisaureus_: really, the annoying thing is that git on windows *creates* read-only files in the first place.
16:22:15  <piscisaureus_>Does git do this?
16:22:18  <isaacs>piscisaureus_: yes
16:22:35  <piscisaureus_>god damn
16:22:41  <isaacs>i've been texting linus and telling him to change it, but he doesn't ever answer my texts
16:22:52  <piscisaureus_>yeah
16:23:01  <piscisaureus_>asshole
16:23:02  <isaacs>just sends me something about cats and dogs
16:23:08  <isaacs>at least, that's what I assume C&D stands for
16:23:33  <piscisaureus_>Oh I heard he usually did fishes and unicorns
16:23:57  <bnoordhuis>he's into scuba diving
16:24:05  <isaacs>piscisaureus_: btw: https://docs.google.com/spreadsheet/ccc?key=0AganzoeqkiHddE9uRlA5WS0xSF9NTGN1QS0zZ3FRSWc#gid=8
16:24:08  <bnoordhuis>my uncle is a diving instructor. he went diving with linus once
16:24:44  * TooTallNatejoined
16:24:44  <isaacs>bnoordhuis: care to review? https://github.com/joyent/node/pull/4911
16:24:57  <isaacs>that pull gets us over the finish line, at least on osx
16:25:05  <bnoordhuis>aww, do i have to?
16:25:18  <isaacs>bnoordhuis: you could just say "if tootallnate or indutny +1 it, then lgtm"
16:25:24  <isaacs>bnoordhuis: that's a trick i use a lot.
16:25:37  <bnoordhuis>^ what you said
16:25:49  <TooTallNate>i can take a look
16:25:58  <indutny>if ben or pisci +1 then lgtm
16:27:05  <bnoordhuis>the DAG implies it all depends on nathan now
16:29:04  * mikealjoined
16:30:25  <isaacs>it'd be nice to get a non-core stream freak to look at it as well
16:30:43  <isaacs>Raynos said "Sure, whatever. Don't care" about the API change.
16:30:51  <isaacs>so i guess that's as good as a +1 :)
16:33:02  * `3rdEdenchanged nick to `3E|DINNR
16:39:11  * dapjoined
16:40:47  * qmxchanged nick to qmx|lunch
16:40:59  * qmx|lunchchanged nick to qmx
16:42:34  * piscisaureus_quit (Read error: Connection reset by peer)
16:45:51  * qmxchanged nick to qmx|lunch
16:47:40  * mikealquit (Quit: Leaving.)
16:49:38  * loladirojoined
16:52:50  <isaacs>bnoordhuis: What do you think about https://github.com/joyent/node/pull/4912? It satisfies the requests for a better timeout control on HTTP servers, and provides backwards compatibiltiy, but it does some things that are a bit... weird, I think.
16:54:25  <isaacs>basically, if you set a timeout on the socket, then it's your timeout, and your responsibility. if you don't, we destroy it.
16:54:33  <isaacs>er, if you set a timeout callback
16:54:48  <isaacs>if you just do socket.setTimeout(100), then we'll still destroy it, because no additional callback was added.
16:56:46  * kazuponjoined
17:00:40  <bnoordhuis>guess dap beat me to it
17:05:32  * loladiroquit (Quit: loladiro)
17:06:09  * kazuponquit (Ping timeout: 248 seconds)
17:14:05  * loladirojoined
17:22:17  <tjfontaine>"That means they don't have time to hold your hand, wipe your nose for you when it's runny or your buttocks when you've done a boo-boo"
17:23:12  <MI6>nodejs-master: #55 UNSTABLE windows-x64 (11/546) linux-ia32 (1/546) windows-ia32 (11/546) osx-ia32 (1/546) http://jenkins.nodejs.org/job/nodejs-master/55/
17:32:52  <TooTallNate>tjfontaine: ya i lol'd pretty hard
17:33:15  <tjfontaine>ben's my favorite
17:34:27  <MI6>nodejs-v0.8: #21 FAILURE linux-x64 (2/467) osx-ia32 (3/467) smartos-ia32 (1/467) windows-x64 (2/467) windows-ia32 (2/467) osx-x64 (1/467) smartos-x64 (1/467) linux-ia32 (3/467) http://jenkins.nodejs.org/job/nodejs-v0.8/21/
17:35:08  * loladiroquit (Quit: loladiro)
17:35:20  <tjfontaine>I hate you windows
17:45:42  * bnoordhuisquit (Ping timeout: 264 seconds)
18:02:27  * kazuponjoined
18:05:17  * loladirojoined
18:07:01  * kazuponquit (Ping timeout: 256 seconds)
18:10:46  * benoitcquit (Excess Flood)
18:11:24  * benoitcjoined
18:15:57  <MI6>libuv-master: #26 FAILURE http://jenkins.nodejs.org/job/libuv-master/26/
18:16:02  * trevnorrisjoined
18:16:34  <trevnorris>isaacs: so why was the _events check placed back in emit?
18:17:03  * piscisaureus_joined
18:18:32  <trevnorris>piscisaureus_: seriously?
18:18:41  <piscisaureus_>trevnorris: no shit sherlock
18:19:21  <trevnorris>piscisaureus_: ugh. well, guess it was never "officially" documented that strings had to be passed.
18:19:44  <piscisaureus_>I suppose strings and numbers would be okay in my book
18:19:56  <trevnorris>piscisaureus_, isaacs: well, rather than adding another || is number check. i'd say just remove the thing all together.
18:19:57  <piscisaureus_>(iow, objects /regexes etc -> no!)
18:20:11  <piscisaureus_>maybe just coerce to string
18:20:41  <trevnorris>piscisaureus_: well, i'm fine doing stupid shit like that in addListener because it's not hot. but hell no in emit()
18:20:50  <piscisaureus_>oh actually it's mongoose
18:20:56  <piscisaureus_>stupid mongoose again
18:21:57  <piscisaureus_>https://github.com/mongodb/node-mongodb-native/blob/master/lib/mongodb/connection/base.js#L99
18:23:14  <trevnorris>piscisaureus_: well that's once, not addListener. guess it'd have to be changed in both places.
18:23:41  <piscisaureus_>well - yes, sure. It's the same code basically.
18:23:55  <piscisaureus_>and on() and once() should enforce the same restrictions anyway
18:24:04  <trevnorris>yea
18:24:05  <trevnorris>h
18:24:43  <piscisaureus_>But really
18:25:04  <piscisaureus_>have EventEmitter.prototype.listenersCount()
18:25:10  <piscisaureus_>Please break mongoose :)
18:25:17  <piscisaureus_>My kingdom for it
18:25:43  <trevnorris>yeah, i completely agree. but don't know how much say I have in it. ;-)
18:26:03  <Raynos>Do it
18:26:25  <Raynos>I think mongoose should be broken too.
18:26:32  <tjfontaine>oh right, I still need to do tap output for windows
18:27:12  <trevnorris>tjfontaine: wtf is this "tap" output? it's stupid we need to check if _events exists in every fucking emit()
18:27:29  <tjfontaine>trevnorris: you're mixing responses :)
18:27:39  <tjfontaine>trevnorris: testanything.org
18:28:25  <piscisaureus_>Yes.
18:28:50  <trevnorris>ok, now I'm confused. why are we checking if _events exists in emit()?
18:29:03  * benoitcquit (Excess Flood)
18:29:04  <tjfontaine>piscisaureus_: fwiw I did hit that libuv linking issue on the windows build slave
18:29:24  <piscisaureus_>you mean the lack of advapi and shell32 ?
18:29:44  <tjfontaine>http://jenkins.nodejs.org/job/libuv-master/label=windows/26/console
18:29:48  <piscisaureus_>I wonder if gyp was changed to add those to the exclusion list
18:29:51  <tjfontaine>seems like that
18:30:58  <piscisaureus_>But then, libuv should always use the same version of gyp because it fetches a particular revision w/ svn
18:31:13  <tjfontaine>no master uses git
18:32:01  <piscisaureus_>ah yes
18:32:04  <piscisaureus_>saghul again :-p
18:32:11  <piscisaureus_>(j/k saghul)
18:32:35  <tjfontaine>hehe
18:32:42  <piscisaureus_>I like this theory. /me pounds though the gyp commit log
18:34:17  <tjfontaine>libuv uses stderr for test output doesn't it
18:35:36  * mikealjoined
18:35:54  * benoitcjoined
18:38:04  <MI6>libuv-v0.8: #13 UNSTABLE linux (2/158) osx (2/158) smartos (6/158) http://jenkins.nodejs.org/job/libuv-v0.8/13/
18:39:52  <piscisaureus_>tjfontaine: well... grep printf -r test/runner*
18:40:14  <tjfontaine>it does, it was more of a "you idiot, how did you forget that"
18:40:33  * `3E|DINNRchanged nick to `3rdEden
18:40:42  <piscisaureus_>tjfontaine: seems to do both. I will accept patches that make it consistent. Note that you only have to update runner* because the individual tests are first captured by the runner and then echoed
18:40:58  <piscisaureus_>;-(
18:41:10  <piscisaureus_>https://codereview.chromium.org/12256017
18:42:11  <tjfontaine>ah
18:43:21  * roxluquit (Read error: Connection reset by peer)
18:44:08  * roxlujoined
18:47:18  <MI6>joyent/node: Bert Belder master * 890dc2e : win/msi: make msi build work when spaces are present in the path - http://git.io/JHhpsQ
18:48:34  <tjfontaine>piscisaureus_: can I use getenv("UV_TAP_OUTPUT") on the windows side like I do on the unix side or should I use GetEnvironmentVariableW
18:48:46  * slaskisquit (Quit: slaskis)
18:48:47  <piscisaureus_>tjfontaine: getenv is fine
18:48:52  <tjfontaine>k
18:49:06  * loladiroquit (Quit: loladiro)
18:51:29  * bnoordhuisjoined
18:54:44  <isaacs>trevnorris: you can call _emit before any listeners are added.
18:54:59  <isaacs>trevnorris: and you can call emit('error', er) and have it *throw* before any listeners are added
18:55:23  <isaacs>trevnorris: so we can't just no-op if _events is null, and we certainly can't check _events[type] without a check
18:55:34  <trevnorris>isaacs: the only way to reach that point is to call emit before any listeners are added, and before the emitter has been instantiated. that's why I have the object setting this._events = {} in EventEmitter.
18:55:50  <trevnorris>so we wouldn't have to do that check.
18:55:54  * bnoordhuisquit (Ping timeout: 252 seconds)
18:56:13  <isaacs>trevnorris: righ, but you can emit before EE gets applied
18:56:45  <isaacs>trevnorris: function OldEmitter(n) { if (n < 10) { this.emit('error', Error('n shoudl be at > 10')) } }
18:57:04  <isaacs>trevnorris: util.inherits(OldEmitter, Ee)
18:57:36  <isaacs>trevnorris: we can't break backwards compatibility on that interface. not even a little, not even with good reason.
18:57:53  <isaacs>sucks. i know.
18:57:54  <trevnorris>that's basically saying we allow you to run instance functions w/o first needing to run the constructor. doesn't make api sense, imho.
18:58:02  <isaacs>well.. it's too late to change now.
18:58:09  <trevnorris>ah, backwards compatibility crap. ok
18:58:18  <isaacs>i feel your frustration.
18:58:18  * loladirojoined
18:58:27  <isaacs>it's annoying, because type-checking in emit() is a hot code path
18:58:48  <isaacs>one alternative i actually considered was to set EventEmitter.prototype._events = someKnownObject
18:59:05  <tjfontaine>piscisaureus_: indeed by reverting to before that change I was able to build
18:59:06  <isaacs>then instead of checking if it's undefined/null in on(), we can check if it's the known shared object, and override it
18:59:21  <isaacs>but emit-before-ctor would still work
18:59:27  <MI6>joyent/node: piscisaureus created branch reviewme2 - http://git.io/WOnaAA
18:59:31  <piscisaureus_>tjfontaine: ok. I will land a fix
18:59:49  <piscisaureus_>tjfontaine: the fix is there. I just wanted to know what broke it.
18:59:49  <trevnorris>isaacs: that is not a bad idea. i like it.
19:00:14  <tjfontaine>piscisaureus_: https://github.com/joyent/node/commit/3a387e75369a#L1R829 is that supposed to have a / ?
19:00:20  <isaacs>trevnorris: the string thing is also annoying
19:00:30  <isaacs>piscisaureus_: is mongoose calling emit(nonString), or just on(nonString)?
19:00:50  <trevnorris>isaacs: they're callling .once(nonString)
19:00:55  <isaacs>piscisaureus_: if they're deopt-ing emit(), then at least they should be slapped
19:00:56  <piscisaureus_>isaacs: once(nonString) I believe
19:00:59  <trevnorris>.once(nonString, fn)
19:01:03  <isaacs>sure
19:01:08  <isaacs>so, on(nonString,fn)
19:01:19  <isaacs>how do they fire that event, though?
19:01:22  <isaacs>with 1 or '1'?
19:02:02  <trevnorris>isaacs: well, technically it wouldn't matter because type of type is intentionally not checked in emit().
19:02:16  <isaacs>oh, ok
19:02:17  <trevnorris>and it would be forced to coerce in the call.
19:02:22  <isaacs>ugh
19:02:29  <isaacs>so, my guess is that they ARE deopting emit()
19:02:33  <isaacs>#$@!$!@#$
19:02:40  * qmx|lunchchanged nick to qmx
19:02:41  <isaacs>MON GOOOOOOOOOSSSSSSSE!
19:02:41  <LOUDBOT>WHY THE FUCK ARE YOU STILL USING THE OVERTHRUSTER? YOU SHOULD HAVE UPGRADED TO A HYPERTHRUSTER MONTHS AGO!
19:02:42  <trevnorris>stupid on their part. all that coercion is going to slow them down.
19:02:46  <isaacs>yes
19:02:50  <isaacs>it's going to slow NODE down
19:03:09  * isaacssigh
19:03:17  <isaacs>ok, so, let's remove that chec, i guess
19:03:25  <indutny>fuck backwards-compatibility
19:03:26  <trevnorris>yeah. part of the reason for the additional checks was to let you know if you would call emit() and force a deopt.
19:03:32  <MI6>nodejs-master: #56 UNSTABLE windows-x64 (11/546) linux-x64 (1/546) windows-ia32 (11/546) http://jenkins.nodejs.org/job/nodejs-master/56/
19:03:48  <isaacs>on({toString:'/whatever/'}, fn) .emit(/whatever/)
19:04:02  <indutny>oh gosh
19:04:08  <indutny>is mongoose doing it?
19:04:20  <isaacs>indutny: well, they're doing .once(1, fn)
19:04:32  <isaacs>indutny: and if they are, then someone else is.
19:04:35  <indutny>:)
19:04:53  <isaacs>and as much as it annoys me, i'm not comfortable making breaking changes in this part of node
19:04:57  <isaacs>so, the type check goes.
19:05:00  * isaacs\o/
19:05:03  <isaacs>er, wrong one.
19:05:05  * isaacs/o\
19:05:07  <isaacs>that one
19:05:38  <indutny>D:
19:05:52  <indutny>this one ^
19:06:04  <indutny>\/
19:06:06  <indutny> |
19:06:07  <indutny> |
19:06:15  <indutny> /o\
19:06:23  * mikealquit (Quit: Leaving.)
19:06:24  <indutny>________
19:07:24  <trevnorris>isaacs: can you include this in the commit msg: http://www.ascii-middle-finger.com/
19:08:03  <isaacs>hahah
19:08:25  <isaacs>no no no, frustration stays on irc, doesn't belong in commit messages
19:09:30  <trevnorris>=)
19:14:03  <TooTallNate>lulz, mongoose…
19:14:08  <isaacs>https://github.com/joyent/node/pull/4914
19:14:08  * csaohquit (Quit: csaoh)
19:14:42  <roxlu>when I have 3 variables in a thread to which I want to synchronize (all at different times and with different amounts), is it better to create 4 different mutexes?
19:14:45  <trevnorris>isaacs: you don't need to pre-coerce.
19:14:59  <roxlu>s/4/3
19:15:01  <trevnorris>isaacs: js will automatically do that.
19:15:15  <trevnorris>and that way people who don't do that stupid shit doesn't have to pay the price.
19:15:35  <trevnorris>but the "typeof type === 'string'" checks will all need to be removed.
19:17:47  * loladiroquit (Quit: loladiro)
19:21:10  <MI6>joyent/libuv: Bert Belder master * 1ba5926 : windows: link with advapi32 and shell32 libraries Older versions of GYP - http://git.io/LpVGWw
19:21:21  <piscisaureus_>^-- tjfontaine: your fi
19:21:22  <piscisaureus_>x
19:22:00  <piscisaureus_>isaacs: well it's node-mongodb-native anyway
19:22:09  <piscisaureus_>isaacs: probably file a bug against them?
19:22:17  <tjfontaine>piscisaureus_: thanks
19:22:36  <piscisaureus_>TooTallNate: wait...
19:22:41  <MI6>joyent/libuv: Bert Belder master * ea0796f : windows: link with advapi32 and shell32 libraries Older versions of GYP - http://git.io/LP-V1g
19:22:42  <piscisaureus_>TooTallNate: ^-- there!
19:22:49  <tjfontaine>and me :)
19:22:50  <TooTallNate>nice :)
19:23:11  <piscisaureus_>tjfontaine: you too buddy
19:23:18  <MI6>libuv-master: #27 UNSTABLE osx (1/183) smartos (4/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/27/
19:23:41  * `3rdEdenquit (Quit: brb)
19:23:46  * loladirojoined
19:24:20  <isaacs>trevnorris: is there a diff between pre-coercion and coercing repeatedly?
19:24:34  <isaacs>trevnorris: we have a lot fo events[type] in that function
19:24:37  <tjfontaine>piscisaureus_: so thoughts on me doing _fdopen on process->stdio_out so I can do fgets?
19:24:52  <piscisaureus_>tjfontaine: ehwut
19:24:54  <trevnorris>isaacs: v8 will autodetect if type == number and coerce it. we don't have to.
19:25:06  <isaacs>ok
19:25:25  <MI6>libuv-master: #28 UNSTABLE osx (1/183) smartos (4/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-master/28/
19:25:45  <tjfontaine>piscisaureus_: I'd like to use fgets here https://github.com/joyent/libuv/blob/master/test/runner-win.c#L214 but p->stdio_out is a HANDLE
19:25:53  * brsonjoined
19:26:32  <piscisaureus_>tjfontaine: not fond of it. Also _fdopen won't get you there but _open_osfhandle probably would
19:26:52  <tjfontaine>right http://stackoverflow.com/questions/7369445/is-there-a-windows-equivalent-to-fdopen-for-handles suggests I need to do both
19:27:08  <trevnorris>isaacs: ok, so for the fix up's seems just need to remove the checks. want me to give a quick go at that pre-set obj thing, or you going to do that?
19:27:16  <piscisaureus_>tjfontaine: what's wrong with just ReadFile instead of fgets
19:27:51  <tjfontaine>piscisaureus_: I need to prepend each line with a # for it to comply with TAP
19:28:12  * piscisaureus_sighs
19:28:29  <tjfontaine>otherwise you'll just see that things failed and not why :)
19:28:44  <piscisaureus_>tjfontaine: I think fgets() will read until
19:28:47  <piscisaureus_>\r\n
19:28:52  <tjfontaine>right
19:28:57  <piscisaureus_>so that will probably bite you in different ways
19:29:09  <piscisaureus_>so hmm a sec
19:29:17  <tjfontaine>https://github.com/tjfontaine/libuv/commit/a81bd43014476db18cd486fc3e6d0fa7551e4991 is what I had done before I realized it was a handle
19:29:17  <piscisaureus_>I haven't looked at that code since I wrote it :-p
19:29:20  <tjfontaine>hehe
19:29:50  <tjfontaine>and that's more or less how the unix runner works as well
19:31:24  <piscisaureus_>well yeah I think I wrote that too but it could've been Ryan too
19:31:29  <piscisaureus_>anyway
19:32:03  <piscisaureus_>is it so hard to just scan the buffer for \n and drop an # after that?
19:32:42  * bnoordhuisjoined
19:32:55  <tjfontaine>it's not that it's hard, it's just that fgets does exist
19:33:09  <tjfontaine>I will do it however you'd prefer though
19:34:19  <piscisaureus_>well - I prefer the simplest way to do it
19:34:21  <piscisaureus_>:)
19:35:18  <tjfontaine>simple to me sounds like gimmie a file* and use fgets :)
19:37:04  <piscisaureus_>tjfontaine: so what happens if the line is longer than sizeof(buf) ?
19:37:34  <tjfontaine>truncation, the unix path has a todo about that :)
19:38:59  <tjfontaine>it's my fault the unix path uses fgets
19:41:05  <isaacs>trevnorris: i'm technically not working today. so go nuts on it :)
19:41:24  <trevnorris>isaacs: lol. ok. i'll get the pr setup. =)
19:41:32  <isaacs>thanks
19:41:34  * isaacs&
19:41:34  <LOUDBOT>HELVETICA IS PLAYED OUT.
19:44:05  <trevnorris>piscisaureus_: review: http://git.io/v7VGAQ
19:45:02  * EhevuTovjoined
19:45:29  <piscisaureus_>trevnorris: I see you snuck some secret optimizations in?
19:46:05  <trevnorris>piscisaureus_: oh, sorry. no. those were for code consistency w/ the rest of the lib.
19:46:13  <trevnorris>i'll revert those and push up again.
19:46:22  <piscisaureus_>trevnorris: I don't mind
19:46:24  * EhevuTovquit (Max SendQ exceeded)
19:46:25  <piscisaureus_>if they make things better
19:46:30  <trevnorris>=)
19:46:31  <piscisaureus_>trevnorris: I was going to say lgtm
19:46:57  <piscisaureus_>trevnorris: although It'd be better to make them separate commits
19:47:06  <trevnorris>piscisaureus_: coolio. will do
19:47:09  * EhevuTovjoined
19:47:28  <trevnorris>piscisaureus_: and think I should throw in a test for mongoose's case?
19:47:49  <piscisaureus_>trevnorris: yeah - if we are going t care for it, it'd be good
19:47:57  <trevnorris>i'll throw that in too.
19:50:52  * bradleymeckjoined
19:55:36  <MI6>joyent/node: Ben Noordhuis v0.8 * ecf9f60 : doc: add url.resolve() usage examples Fixes #4913. - http://git.io/pmkP6A
20:02:21  <trevnorris>bnoordhuis: isaacs is out for the day, so he told me to get the PR setup for the mongoose fix.
20:02:45  <trevnorris>piscisaureus_: finished.
20:03:39  * kazuponjoined
20:05:58  <MI6>nodejs-v0.8: #22 FAILURE linux-x64 (3/467) osx-ia32 (2/467) smartos-ia32 (1/467) windows-x64 (2/467) windows-ia32 (2/467) osx-x64 (1/467) smartos-x64 (1/467) linux-ia32 (1/467) http://jenkins.nodejs.org/job/nodejs-v0.8/22/
20:08:02  <piscisaureus_>http://falkvinge.net/2013/03/04/after-being-cut-from-norway-the-pirate-bay-returns-from-north-korea/
20:08:39  * kazuponquit (Ping timeout: 260 seconds)
20:10:23  * slaskisjoined
20:12:11  <piscisaureus_>bnoordhuis: I'd go for trevnorris' patch here.
20:13:52  <MI6>joyent/node: Trevor Norris master * d09ab61 : events: code consistency v8 likes when smaller functions have a single r (+1 more commits) - http://git.io/VaXNUg
20:18:33  <piscisaureus_>ewa
20:18:39  <piscisaureus_>I'm leaving again
20:18:43  <piscisaureus_>Love you and goodbye
20:18:53  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:29:07  <MI6>nodejs-master: #57 UNSTABLE windows-x64 (11/546) windows-ia32 (12/546) osx-x64 (1/546) osx-ia32 (2/546) http://jenkins.nodejs.org/job/nodejs-master/57/
21:04:28  * kazuponjoined
21:04:48  * bnoordhuisquit (Ping timeout: 276 seconds)
21:05:56  * loladiroquit (Quit: loladiro)
21:08:56  * kazuponquit (Ping timeout: 252 seconds)
21:09:45  * loladirojoined
21:10:33  * loladiroquit (Client Quit)
21:11:55  * EhevuTovquit (Quit: This computer has gone to sleep)
21:13:08  * EhevuTovjoined
21:16:43  <MI6>nodejs-v0.8: #23 FAILURE linux-x64 (2/467) osx-ia32 (2/467) smartos-ia32 (1/467) windows-x64 (2/467) windows-ia32 (2/467) osx-x64 (1/467) smartos-x64 (1/467) linux-ia32 (1/467) http://jenkins.nodejs.org/job/nodejs-v0.8/23/
21:37:34  * bnoordhuisjoined
21:40:58  * mikealjoined
21:42:32  * rendarquit
21:43:58  * wolfeidauquit (Remote host closed the connection)
21:48:33  <trevnorris>bnoordhuis: sorry for the newb question, but is there a doc explaining how to get your example on v8 issue 2551 to compile?
21:49:03  <tjfontaine>blah where's sblom
21:49:34  <bnoordhuis>trevnorris: oh, just link it to libv8_{base,nosnapshot}.a
21:49:44  <trevnorris>bnoordhuis: ah, ok. thanks.
21:50:35  * piscisaureus_joined
21:55:32  <bnoordhuis>i wonder if it makes sense when you have a large number of file descriptors to split them over several epoll sets and poll the epoll fds instead
21:55:45  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:56:13  <tjfontaine>is there something in particular you're looking to solve? or just more balancing work
21:56:26  <bnoordhuis>when you stash everything into one big epoll set, every call to epoll_ctl has to grab the epoll mutex
21:57:09  <bnoordhuis>with multiple epoll sets, the locking gets more fine-grained
21:57:24  <bnoordhuis>then again, almost all file descriptors are added from the same thread
21:57:57  <bnoordhuis>so chances of lock contention should be low, at least in user-mode land
21:59:20  <bnoordhuis>tjfontaine: to answer your question more directly, the __spinlock_* functions often pop up when i profile with perf
21:59:31  <tjfontaine>ah
21:59:42  <tjfontaine>were you planning on splitting on work load?
21:59:51  <bnoordhuis>i'm toying with the idea
21:59:55  <tjfontaine>k
22:00:45  <bnoordhuis>guess i'll just have to try and benchmark it
22:01:55  <bnoordhuis>same with kqueue, i suppose, but kqueue-in-kqueue has historically been very buggy
22:02:41  * wolfeidaujoined
22:04:57  * kazuponjoined
22:08:41  * trevnorrisquit (Quit: Leaving)
22:09:26  * kazuponquit (Ping timeout: 252 seconds)
22:12:39  * trevnorrisjoined
22:26:19  * slaskisquit (Quit: slaskis)
22:30:38  * loladirojoined
22:38:47  * qmxchanged nick to qmx|away
22:40:01  <tjfontaine>I want to seriously hurt windows/msbuild/wix right now
22:43:48  * perezdjoined
22:51:13  * sblomjoined
22:57:17  <tjfontaine>sblom: I'm having no luck with this wix issue, I'm fairly sure I'm going crazy, I've even put the run out of proc in the default wix targets, and it's like msbuild is insisting on not agreeing with me
22:58:40  <tjfontaine>trevnorris: so do we want to crank up dur when we're benchmarking?
22:58:59  <tjfontaine>trevnorris: I mean, when I'm collecting stats
22:59:43  <trevnorris>tjfontaine: yes. we also need to run it more than once.
23:00:21  <tjfontaine>trevnorris: what's the ideal pattern here then
23:01:20  <trevnorris>tjfontaine: D == duration; N == number of times to be run. so
23:02:34  * benoitcquit (Excess Flood)
23:02:53  <trevnorris>tjfontaine: D is a random time between [MIN, MAX] (i'd say between 5 to 10 seconds for now) and
23:03:25  <trevnorris>tjfontaine: N is continuously calculated based on the stability of variance over the previous tests.
23:03:33  <trevnorris>(this will sound crazy, but give me a sec to explain it)
23:03:50  <tjfontaine>it doesn't make sense to just have N be some huge number?
23:05:56  * kazuponjoined
23:06:03  <trevnorris>N should be a sample based on the distribution. so we can know the distribution by tracking test stability over time.
23:06:24  <trevnorris>then we set a cap of max N, of which after that many runs if it hasn't stabalized then we know something else is wrong.
23:06:53  <trevnorris>after which we calculate the mean and stdev.
23:07:46  <trevnorris>taking two tests, A and B if each mean falls withing 2 stdev's of the other's mean then there is no detectable regression.
23:09:46  <trevnorris>tjfontaine: is that making sense? i was working on a script that would do these calculations and spit out the results of a single test.
23:10:01  <trevnorris>then it could be stored, and used to detect regression from a previous test.
23:10:05  <tjfontaine>A and B are two different commits?
23:10:09  <trevnorris>yes
23:10:15  * kazuponquit (Ping timeout: 240 seconds)
23:10:22  <tjfontaine>why can't we just churn through all the commits and generate raw data, and do analysis later?
23:11:36  <trevnorris>by raw data, you mean each the mean of each run?
23:11:45  <trevnorris>erm. the time of each run?
23:11:53  <trevnorris>or whatever the output...
23:11:55  * perezdquit (Quit: perezd)
23:11:55  * benoitcjoined
23:12:02  <tjfontaine>net/tcp-raw-pipe.js len=102400 type=utf dur=5: 4.0757
23:12:13  <tjfontaine>right whatever the output
23:12:24  <trevnorris>ok. then just run that N times for a commit and store each run.
23:12:32  <tjfontaine>supposed to be in name: result format, where result > is better
23:13:07  <tjfontaine>right, then you can run all the analysis and pretty graphs you want while it's running through history
23:13:26  * kazuponjoined
23:13:48  <tjfontaine>I just worry about how much state I have to carry along in the CI to do useful regression testing there
23:13:49  <trevnorris>didn't think that was a possible option. if it is possible to run each test N times and just store the data for each run, for each commit, that would be freakin awesome.
23:14:29  <trevnorris>i'd be able to yank that into a script and do all sorts of analysis on it.
23:14:49  <tjfontaine>ya, I'm afraid of the fidelity you lose if we toss the raw data away
23:15:00  <trevnorris>sweet.
23:15:27  <trevnorris>the only thing I'd have to add then is make sure duration is a random interval between [MIN, MAX]
23:15:39  <tjfontaine>random for each run?
23:15:42  <trevnorris>yeah.
23:16:20  <tjfontaine>seems like you're changing too many things at once, why shouldn't the duration be static?
23:16:21  <trevnorris>if we can take a large sample, then having a uniformly random duration between two values is the best way to get results.
23:16:52  <trevnorris>tjfontaine: http://d3s.mff.cuni.cz/publications/download/KaliberaBulejTuma-AutomatedDetection.pdf
23:17:06  <tjfontaine>executive summary? :)
23:17:06  <trevnorris>tjfontaine: don't expect you to read that
23:17:08  <trevnorris>yeah
23:17:13  <trevnorris>heh, here it is.
23:17:20  * hzquit (Disconnected by services)
23:17:23  * hzjoined
23:19:05  * mikealquit (Quit: Leaving.)
23:19:52  <trevnorris>the volatility of a benchmark can be measured by a set random conditions. in most statistics many of the initial states can be controlled, but in computer systems that's more difficult to determine. so introducing random initial states to the tests shouldn't change the overall distribution of the result values.
23:20:17  <tjfontaine>ok
23:20:27  <trevnorris>check out Fig. 1 on page 3.
23:20:48  <trevnorris>that shows how much a benchmark can vary based on initial conditions.
23:21:28  <trevnorris>tjfontaine: i would also say that len should be somewhat random, but we know there are performance regressions and specific points.
23:21:33  <tjfontaine>in the case of a VM though, an initial condition could be just about anything the host or other guests are doing?
23:21:57  <trevnorris>tjfontaine: so if we could determine those points then we'd be able to successfully group the tests to more determinate results.
23:22:10  <tjfontaine>hm ok
23:22:55  <trevnorris>sorry, i don't want to make this crazy complicated.
23:23:01  <tjfontaine>it's not complicated per se
23:23:01  <trevnorris>but i'm afraid i have.
23:23:03  * c4miloquit (Remote host closed the connection)
23:23:37  <trevnorris>ok. imho here's the optimal benchmark scenario:
23:24:19  <tjfontaine>I'm interested in benchmarks, in so far as I like to see the results, it's just hard for me to reason about moving the N and D around and saying you're getting an apples/apples comparison
23:24:35  * perezdjoined
23:25:07  <trevnorris>statistically you can if N is large enough and D is over a uniform distribution.
23:25:58  <tjfontaine>alright, tell me what conditions you want for N and D and I'll collect the data :)
23:26:25  <trevnorris>ok. also there's one more thing, but don't know if it's possible. with this i think we'd be set.
23:26:25  <tjfontaine>and I'll read this paper tonight
23:26:49  <tjfontaine>ok, things are possible, it's a question of probability <-- stats joke right?
23:26:54  <trevnorris>lol
23:27:09  <tjfontaine>:P
23:27:33  <trevnorris>if we could get a list of all tests that will be run, then run them in random order, that would give us a good random distribution of initial conditions.
23:28:39  <tjfontaine>is by category random enough or do we need randomize a particular bench?
23:29:14  <trevnorris>i think by category would be enough.
23:29:19  <tjfontaine>because randomizing order of net/http/fs is trivial, the other just requires more plumbing
23:29:35  <tjfontaine>k
23:29:51  <trevnorris>yeah, whichever is easier.
23:29:53  <tjfontaine>what parameters do you want for D and N
23:32:29  * loladiroquit (Quit: loladiro)
23:33:05  <trevnorris>D = [5, 10] seconds
23:34:24  <trevnorris>N = either take two sets of 25, calculate the mean and stdev. if each mean falls within 2 stdevs of the other's mean then clear. OR 100 runs. ;-)
23:34:54  <tjfontaine>meh, cpu and time are cheap, we'll just do 100 :P
23:35:02  <trevnorris>heh, figured.
23:35:16  <tjfontaine>I mean, it's just more data for you later
23:35:24  <trevnorris>also, some tests are very deterministic. like Buffer operations.
23:35:39  <trevnorris>those don't need to be run near as much.
23:36:01  <tjfontaine>nod
23:36:19  <trevnorris>it's the fs operations that worry me the most. those suckers hate to be benchmarked.
23:36:41  <tjfontaine>yup
23:36:56  <tjfontaine>but there you're also benchmarking underlying fs systems, and the stack below
23:37:08  <tjfontaine>so here's the basic layout of what kind of data you want
23:37:14  <tjfontaine>run 100 times, for each run randomize duration between [5, 10] and randomize order of execution (by individual bench is best, but category ok)
23:37:44  <trevnorris>sounds great.
23:39:27  <tjfontaine>alrighty, the good news is I can get this up and running and churning and then worry about what kind of real storage to use so you can run your analysis
23:39:30  <trevnorris>though I do have a little worry about impact of the current benchmark library. was looking at the irhydra output. it introduces a possibly statistically significant amount of noise in the tests.
23:39:39  <trevnorris>which will make it more difficult to detect regression.
23:39:56  <trevnorris>awesome dude. sounds great.
23:40:11  <tjfontaine>trevnorris: oh, right by the way my plan was to just use the benchmark harness from master
23:40:30  <tjfontaine>I presume significant changes to that will require us rewalking the history to generate better data
23:40:53  <trevnorris>tjfontaine: continue with that. i'm going to give them a review and see if it's anything to worry about. but either way it won't affect what you're doing.
23:41:05  <trevnorris>yeah
23:41:36  <trevnorris>i might say just hit previous tags, then if we find a regression then walk the commits. what do you think?
23:42:22  <tjfontaine>depends on how fast the initial population goes, I have a feeling it we'll be able to regenerate data pretty easily
23:42:32  <trevnorris>ok, cool
23:42:52  <tjfontaine>but hitting tags as a first pass might not be terrible for initial population so people can see the high points
23:44:39  <trevnorris>this solution sounds awesome. having all that data available will really help. and be a lot more statistically sound then many current methods used (e.g. v8)
23:46:06  * perezdquit (Quit: perezd)
23:46:54  <tjfontaine>presuming the commit compiles and runs you'll have data for smartos (zone on joyentcloud), ubuntu (vm on joyentcloud), osx (mbp), and windows 2008 x64 (vm on joyentcloud)
23:49:26  * mikealjoined
23:50:45  <trevnorris>coolio. that's awesome.
23:50:51  <tjfontaine>trevnorris: { commit: 'sha1', results: [{ platform: 'win32', runs: [{duration: 5, testname: result, ...}, ...] }, ...]}
23:51:03  <tjfontaine>sane layout?
23:51:16  <trevnorris>yeah, that's great.
23:56:06  * wolfeidauquit (Read error: Connection reset by peer)
23:56:18  * wolfeidaujoined
23:58:26  * mikealquit (Ping timeout: 255 seconds)
23:59:05  <trevnorris>bnoordhuis: tried not to show my cc newbness, but can you give me an example to compile that file? i'm trying with "clang++ test.cc -I /path/to/v8/include -Xlinker /path/to/libv8_nosnapshot.a -Xlinker /path/to/libv8_base.a"