00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:23  <thlorenz>wondering if these assumptions regarding tryrdlock and trywrtlock are correct: https://github.com/thlorenz/libuv-dox/blob/master/examples/10-locks-try/main.c#L24
00:03:42  <thlorenz>I couldn't find any samples anywhere (including tests) where these functions are used
00:04:36  <felicity>Ralith: hey, so FIONREAD push was rejected because it apparently was tested before and ends up being much slower.
00:04:51  <felicity>(unsurprising, really, as a syscall is probably much slower than a malloc with a modern libc)
00:05:22  <Ralith>felicity: aw. Oh well, at least I learned a few things.
00:09:29  * kazuponjoined
00:09:34  <felicity>in other news, my server has been up for 12 hours and hasn't crashed, yay.
00:14:09  * kazuponquit (Ping timeout: 252 seconds)
00:24:28  * kenperkinsquit (Quit: Computer has gone to sleep.)
00:33:40  * brsonjoined
01:10:29  * kazuponjoined
01:11:21  * thlorenzquit (Remote host closed the connection)
01:16:29  * brsonquit (Ping timeout: 252 seconds)
01:17:02  * kazuponquit (Ping timeout: 252 seconds)
01:20:37  * c4milojoined
01:22:55  * brsonjoined
01:25:01  <Ralith>if I enqueue multiple writes to a single TCP stream, they won't interfere with eachother, right?
01:27:39  <felicity>no, they will be written in the order you call uv_write
01:28:22  <Ralith>awesome
01:41:34  * calvinfoquit (Quit: Leaving.)
01:58:25  * c4miloquit (Remote host closed the connection)
02:10:34  * mikealjoined
02:13:07  * kazuponjoined
02:17:28  * kenperkinsjoined
02:20:04  * mikealquit (Quit: Leaving.)
02:21:45  * mikealjoined
02:26:26  * calvinfojoined
02:27:21  * calvinfo1joined
02:27:22  * calvinfoquit (Read error: Connection reset by peer)
02:28:16  * calvinfojoined
02:28:17  * calvinfo1quit (Read error: Connection reset by peer)
02:29:05  * calvinfoquit (Read error: Connection reset by peer)
02:29:12  * calvinfojoined
02:33:37  * calvinfoquit (Ping timeout: 246 seconds)
02:39:20  * mikealquit (Quit: Leaving.)
02:46:19  * kazuponquit (Ping timeout: 252 seconds)
02:46:27  * mikealjoined
02:53:27  * mikealquit (Quit: Leaving.)
03:07:02  * calvinfojoined
03:12:35  * c4milojoined
03:41:44  * calvinfoquit (Quit: Leaving.)
03:43:04  * kazuponjoined
03:47:55  * kazuponquit (Ping timeout: 260 seconds)
03:55:47  * zz_karupanerurachanged nick to karupanerura
03:57:05  * defunctzombiechanged nick to defunctzombie_zz
04:01:34  * defunctzombie_zzchanged nick to defunctzombie
04:03:48  * thlorenzjoined
04:21:17  * oremorequit (Ping timeout: 252 seconds)
04:33:28  * c4miloquit (Remote host closed the connection)
04:42:16  * calvinfojoined
04:42:59  * calvinfoquit (Read error: Connection reset by peer)
04:43:11  * calvinfojoined
04:43:54  * calvinfoquit (Read error: Connection reset by peer)
04:44:00  * kazuponjoined
04:44:10  * calvinfojoined
04:45:04  * calvinfo1joined
04:45:04  * calvinfoquit (Read error: Connection reset by peer)
04:45:58  * calvinfojoined
04:45:58  * calvinfo1quit (Read error: Connection reset by peer)
04:46:57  * calvinfo1joined
04:46:57  * calvinfoquit (Read error: Connection reset by peer)
04:47:53  * calvinfojoined
04:47:54  * calvinfo1quit (Read error: Connection reset by peer)
04:48:37  * calvinfoquit (Read error: Connection reset by peer)
04:48:48  * calvinfojoined
04:49:44  * calvinfo1joined
04:49:45  * calvinfoquit (Read error: Connection reset by peer)
04:50:47  * kazuponquit (Ping timeout: 265 seconds)
04:54:17  * calvinfo1quit (Ping timeout: 252 seconds)
04:55:45  * calvinfojoined
04:57:12  * calvinfopart
05:14:03  * kazuponjoined
05:23:07  * thlorenzquit (Remote host closed the connection)
05:29:01  * brsonquit (Quit: leaving)
05:55:19  * kazuponquit (Remote host closed the connection)
06:08:39  * m76joined
06:56:04  * kazuponjoined
07:01:07  * kazuponquit (Ping timeout: 260 seconds)
07:31:23  * hueniversejoined
07:45:39  * kazuponjoined
07:47:17  * kazupon_joined
07:50:01  * kazuponquit (Ping timeout: 246 seconds)
07:51:35  * calvinfojoined
07:51:41  * calvinfoquit (Client Quit)
07:58:48  * rendarjoined
08:13:22  * mikealjoined
08:36:06  * AvianFluquit (Remote host closed the connection)
08:39:45  * bajtosjoined
09:11:02  * hzjoined
09:42:30  * inolenquit (Quit: Leaving.)
10:15:07  * bajtosquit (Quit: bajtos)
10:16:35  * kazupon_quit (Read error: Connection reset by peer)
11:03:52  * daviddiasjoined
11:03:53  * daviddiasquit (Remote host closed the connection)
11:04:52  * daviddiasjoined
11:10:05  * janjongboomjoined
12:05:07  * sindresorhus_joined
12:05:16  * tito_joined
12:05:32  * julian_duquejoined
12:05:33  * julian_duquequit (Changing host)
12:05:33  * julian_duquejoined
12:05:42  * tjfontai1ejoined
12:06:36  * titoquit (Ping timeout: 272 seconds)
12:06:37  * brett19quit (Ping timeout: 272 seconds)
12:06:37  * julianduquequit (Ping timeout: 272 seconds)
12:06:38  * tjfontainequit (Ping timeout: 272 seconds)
12:06:38  * sindresorhusquit (Ping timeout: 272 seconds)
12:06:40  * brett19joined
12:06:44  * sindresorhus_changed nick to sindresorhus
12:11:04  * kazuponjoined
12:30:22  * kazuponquit (Remote host closed the connection)
12:51:55  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:55:17  * karupanerurachanged nick to zz_karupanerura
13:31:05  * kazuponjoined
13:36:15  * kazuponquit (Ping timeout: 272 seconds)
14:29:55  * thlorenzjoined
14:31:44  * m76quit (Read error: Connection reset by peer)
14:32:03  * abraxasjoined
14:37:03  * abraxasquit (Ping timeout: 260 seconds)
14:41:04  * petka_joined
14:41:43  <petka_>I have some perf improvements to url module, they're pretty substantial. Would you be interested?
14:44:16  <mmalecki>petka_: yes (not a core committer, but performance improvements are always welcome_
14:44:24  <mmalecki>petka_: create a pull request on joyent/node
14:44:48  * petka_quit (*.net *.split)
14:50:14  * petka_joined
15:11:18  * kazuponjoined
15:14:23  * kazuponquit (Read error: Connection reset by peer)
15:14:42  * kazuponjoined
15:23:47  <felicity>can i uv_timer_start() a timer that's already been started to change its timeout?
15:42:01  * kazuponquit (Remote host closed the connection)
15:42:08  * kazuponjoined
16:18:13  * AvianFlujoined
16:32:50  * mikealquit (Quit: Leaving.)
16:48:31  * hzquit
16:57:15  * m76joined
17:09:35  * hzjoined
17:11:44  * mikealjoined
17:20:25  * txdvquit (Ping timeout: 245 seconds)
17:20:49  * st_lukejoined
17:21:33  * st_lukequit (Remote host closed the connection)
17:21:59  * st_lukejoined
17:22:46  * octetcloudjoined
17:28:13  * TooTallNatejoined
17:30:12  * tito_changed nick to tito
17:30:12  * titoquit (Changing host)
17:30:13  * titojoined
17:32:40  * julian_duquechanged nick to julianduque
17:41:49  * mikealquit (Quit: Leaving.)
17:55:15  * calvinfojoined
17:58:14  * thlorenz_joined
17:59:34  * thlorenzquit (Ping timeout: 265 seconds)
18:00:03  * mikealjoined
18:01:32  * mikealquit (Client Quit)
18:05:00  * tjfontai1echanged nick to tjfontaine
18:05:05  * tjfontainequit (Changing host)
18:05:05  * tjfontainejoined
18:08:39  * hzquit
18:22:24  * inolenjoined
18:22:36  <MI6>libuv-master-gyp: #362 FAILURE windows-x64 (6/202) osx-x64 (1/204) http://jenkins.nodejs.org/job/libuv-master-gyp/362/
18:25:06  <MI6>libuv-master: #409 FAILURE windows (5/202) linux (5/203) http://jenkins.nodejs.org/job/libuv-master/409/
18:26:39  * sashkotjoined
18:27:35  * sashkotquit (Remote host closed the connection)
18:27:47  <MI6>nodejs-master: #807 UNSTABLE smartos-x64 (11/687) smartos-ia32 (10/687) osx-ia32 (1/687) osx-x64 (1/687) centos-ia32 (4/687) ubuntu-ia32 (2/687) centos-x64 (1/687) http://jenkins.nodejs.org/job/nodejs-master/807/
18:28:32  <MI6>nodejs-v0.10: #1681 UNSTABLE linux-x64 (3/606) osx-x64 (1/606) linux-ia32 (4/606) smartos-x64 (10/606) smartos-ia32 (10/606) osx-ia32 (2/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1681/
18:41:19  <tjfontaine>indutny: you want a new v0.8? o0
18:42:24  <MI6>libuv-master: #410 UNSTABLE windows (6/202) osx (12/204) smartos (6/203) http://jenkins.nodejs.org/job/libuv-master/410/
18:43:30  * mikealjoined
18:52:48  * txdvjoined
18:54:09  <indutny>tjfontaine: well yeah
18:54:14  <indutny>you seen that PR, right?
18:54:20  <indutny>tls is a bit borked on it sometimes
18:55:11  * stagasjoined
18:55:19  <indutny>gosh, my inbox is totally blown
18:55:19  <indutny>:D
18:55:21  <indutny>haha
18:55:29  <indutny>new year preparations taking too much time
18:56:45  <tjfontaine>I totally fucked off for christmas, sorry to leave you in the lurch :)
18:56:51  <indutny>haha
18:56:53  <indutny>well
18:56:56  <indutny>it wasn't only me
18:56:57  <indutny>but yeah
18:56:58  <indutny>np
19:01:14  * kuplatup1uchanged nick to kuplatupsu
19:02:48  <txdv>what is going on here
19:03:12  <hueniverse>tjfontaine: did you go anywhere?
19:07:28  * kazuponquit (Remote host closed the connection)
19:24:08  <trevnorris>hello all
19:24:25  <trevnorris>nice to be back after a long holiday
19:24:37  <trevnorris>othiym23, groundwater: pings
19:30:46  <txdv>good
19:31:04  <txdv>are you going through some issues?
19:31:18  <trevnorris>indutny: if you want me to take a look at something, feel free to assign it to me. easiest way to track that way.
19:31:38  <trevnorris>txdv: was out of town for a week, and have a baby on the way next month. so been busy :)
19:33:44  <trevnorris>tjfontaine: ping
19:33:52  <tjfontaine>yes, assigning issues to people and also leaving a comment about the re-assignment is the absolute right way
19:33:58  <hueniverse>trevnorris: welcome back
19:34:10  <hueniverse>trevnorris: master fails HARD on hapi tests. all domains
19:34:20  <trevnorris>hueniverse: yeah. been working on that over my break.
19:35:17  <trevnorris>hueniverse: came to the sad realization that domains must be tightly coupled to the EE (as much as I wanted to abstract that) so i'm creating a similar type API for EE
19:36:20  <trevnorris>tjfontaine: would you be opposed if we started using the "signed-off" message in commits from non-core member contributions?
19:37:22  <tjfontaine>trevnorris: I'm not opposed to that, I am actually thinking of writing a script that lives in tools/ that we hook up in as a git alias that does the right things for us, but yes i similarly want to know who commited this :)
19:38:01  <MI6>libuv-node-integration: #365 UNSTABLE linux-x64 (1/687) smartos-ia32 (11/687) osx-x64 (1/687) linux-ia32 (1/687) smartos-x64 (8/687) http://jenkins.nodejs.org/job/libuv-node-integration/365/
19:38:20  * kazuponjoined
19:38:20  * thlorenz_quit (Remote host closed the connection)
19:38:29  <trevnorris>tjfontaine: that's easy enough to get w/ git log --pretty=fuller, but it's just easier to see via the signed-off msg.
19:39:28  <tjfontaine>yes but I mean I want this script for other things as well
19:39:31  <tjfontaine>to preflight things
19:40:24  <tjfontaine>like no really, you *have* to run the tests before you can commit this PR, and does the name actually adhere to our Real Name semantics, and also add the name to AUTHORS if it wasn't already
19:42:58  * kazuponquit (Ping timeout: 246 seconds)
19:45:35  <indutny>trevnorris: sure
19:45:37  <indutny>thank you
19:45:57  <MI6>joyent/node: Yorkie master * 8d3bc88 : querystring: remove `name` from `stringify()` - http://git.io/kAPUBA
19:48:00  <trevnorris>hueniverse: your tests have too many dependencies to be included in core, but i'm going to start using those in my personal testing, and replicating what tests I can.
19:48:23  <indutny>yay!
19:48:35  <hueniverse>trevnorris: I can try isolate the main issue
19:49:16  <hueniverse>trevnorris: those tests are the main decision point for WM to deploy any new version of node
19:49:21  <trevnorris>hueniverse: if you want to take a look, feel free. but i'm in the middle of making some substantial changes.
19:49:49  <trevnorris>hueniverse: yeah. my plan is to have all those passing before v0.12 release.
19:49:53  <MI6>joyent/node: Dav Glass v0.10 * 34b9280 : doc: Fix missing backtick in debugger doc - http://git.io/mxZFRg
19:50:34  <hueniverse>trevnorris: I'm in the middle of hapi 2.0 work but I want to get that synced with 0.12
19:53:03  * pachetjoined
19:53:06  * pachetquit (Changing host)
19:53:06  * pachetjoined
19:53:07  <tjfontaine>indutny: please dont' commit Yorkie without fixing the commit to proper realname, thanks
19:53:14  <tjfontaine>oh
19:53:16  <tjfontaine>that was trevnorris
19:53:19  <tjfontaine>bad trevnorris
19:53:25  <tjfontaine>indutny: sorry :)
19:54:10  <tjfontaine>AlexisMocha: sure, I get that they're insensitive on input, I was just curious if there was a way we could guarantee the result of an api call's casing (i.e. convince it such that windows itself only returns lower case)
19:54:26  <trevnorris>tjfontaine: ugh. so annoying. still the last commit. force push the fix?
19:54:54  <trevnorris>tjfontaine: crap. his email isn't even correct. wtf.
19:56:31  <tjfontaine>no force pushing, either :)
19:57:11  <tjfontaine>it's just something we need to get better at
19:58:42  <tjfontaine>[hence the desire for me to write my script]
19:59:56  <trevnorris>tjfontaine: would the script just verify the committer against the list of signed cla's?
20:05:57  <AlexisMocha>tjfontaine: from what I understand support is very limited. On certain versions of Windows, you can open a file with specific casing using CreateFile and passing FILE_FLAG_POSIX_SEMANTICS
20:06:43  <MI6>nodejs-v0.10-windows: #406 UNSTABLE windows-x64 (12/606) windows-ia32 (12/606) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/406/
20:07:08  <AlexisMocha>tjfontaine: but I think that's about the only thing you can do
20:08:53  * `3rdEdenchanged nick to `3E|GONE
20:13:18  <MI6>nodejs-master: #808 UNSTABLE smartos-x64 (9/687) smartos-ia32 (8/687) osx-ia32 (2/687) centos-ia32 (1/687) ubuntu-x64 (1/687) ubuntu-ia32 (1/687) centos-x64 (2/687) http://jenkins.nodejs.org/job/nodejs-master/808/
20:14:17  <tjfontaine>trevnorris: that would be one of the things
20:15:22  <tjfontaine>AlexisMocha: I see, ok then waiting to hear feedback from izs re the module stuff, but we should see if there's a bit more consistent way for us to perform this sort of operation across multiple portions of our code base, because `path` module in general should be more robust abotu this
20:25:22  <trevnorris>bbiab. going to pick up my car from the shop.
20:25:23  * trevnorris&
20:26:14  <MI6>nodejs-v0.10: #1682 UNSTABLE linux-x64 (3/606) osx-x64 (1/606) linux-ia32 (1/606) smartos-x64 (8/606) smartos-ia32 (7/606) osx-ia32 (1/606) http://jenkins.nodejs.org/job/nodejs-v0.10/1682/
20:35:13  * abraxasjoined
20:36:14  * pachetquit (Quit: leaving)
20:39:20  * kazuponjoined
20:39:40  * abraxasquit (Ping timeout: 246 seconds)
20:44:19  * kazuponquit (Ping timeout: 260 seconds)
20:46:21  <txdv>isn't displaying the total amount of tests for each platform kinda redundant?
20:49:14  * thlorenzjoined
21:08:38  <txdv>because it is always the same number?
21:18:24  <othiym23>trevnorris: pong
21:37:43  * hzjoined
21:40:17  * kazuponjoined
21:45:27  * kazuponquit (Ping timeout: 260 seconds)
21:50:13  * indexzerojoined
21:50:25  * m76quit (Read error: Connection reset by peer)
21:51:50  * rendarquit
22:11:22  <trevnorris>othiym23: i'm rewriting https://github.com/joyent/node/pull/6502 and it will serve as a platform for how I redo the internals of async listener. are you thinking of shimming 6502 for backwards compatibility?
22:12:08  * daviddiasquit (Ping timeout: 252 seconds)
22:16:47  * mikealquit (Quit: Leaving.)
22:17:19  <othiym23>trevnorris: I will probably put together a polyfill at the same time I update async-listener to match your changes
22:17:29  <trevnorris>cool
22:17:40  <othiym23>trevnorris: I still haven't decided whether I'm going to rework CLS to use it in favor of emitter-listener
22:18:02  <othiym23>I will probably let the benchmarks decide once the polyfill is complete
22:18:36  <AlexisMocha>Hmmm.. I need some help understanding a bug around the http client
22:18:48  <trevnorris>that's fine. i'm not all bent about using this api. it's mainly so I can fix all the edge cases around async listener and domains.
22:18:55  <trevnorris>AlexisMocha: what's up?
22:18:58  * vptrjoined
22:20:41  <AlexisMocha>function parserOnBody(b, start, len) if the return of stream.push is false, we pause the socket
22:21:42  <AlexisMocha>in this unite test (test-http-get-pipeline-problem) this is happening because the readable state is past the highwatermark
22:22:07  <AlexisMocha>however i don't see where we would resume it (and i am not sure why we would pause it in the first place)
22:23:20  <AlexisMocha>in the end, by the time the client gets an EOF, the socket is still paused and this causes things to fail
22:23:29  <trevnorris>AlexisMocha: reference commit 085dd30e
22:23:49  * stagasquit (Ping timeout: 272 seconds)
22:24:23  <trevnorris>AlexisMocha: there was a trivial ddos where if you opened up a tcp stream to an http client and just piped http requests w/o ever actually accepting the response then the server would die
22:31:02  <AlexisMocha>I am very new with this code and I don't quite understand its intricacies, so please bear with me...
22:31:24  <AlexisMocha>it looks like we restart the socket after the message is completed
22:31:39  <AlexisMocha>but what if the message isn't completed? who is going to restart the socket?
22:33:25  <tjfontaine>it's not a DDoS it was a DoS
22:34:37  <AlexisMocha>So I wonder if the problems lies in:
22:34:56  <tjfontaine>AlexisMocha: so basically, we are pausing when we reach HWM, and then the streams infrastructure will trigger a resume in the normal _read mechansim
22:36:06  <AlexisMocha>Mmmm, ok, then I am missing where that second part will happen
22:36:10  <AlexisMocha>or is supposed to happen
22:36:17  <tjfontaine>AlexisMocha: what you're probably seeing is, we've paused the parser and the reading, but we are blowing the assert because we've received another data packet after that
22:36:22  <tjfontaine>s/packet/callback/
22:36:52  <tjfontaine>AlexisMocha: socketOnDrain
22:36:54  <AlexisMocha>we receive another data chunk after that, and then we get the EOF
22:38:14  <AlexisMocha>socketOnDrain isn't that on the write side?
22:38:51  <trevnorris>tjfontaine: no it was a ddddddddddddddddddddddddddos :P
22:38:55  <tjfontaine>trevnorris: heh
22:40:44  <tjfontaine>AlexisMocha: yes, we've reached the high water mark to *write* to the client, so we've paused the parser and socket's *read*, when we get drain on the writing to the client we resume
22:41:18  * kazuponjoined
22:42:33  <AlexisMocha>ah, ok
22:43:03  <AlexisMocha>but if before we resume we get an EOF, we barf
22:43:24  <AlexisMocha>apparently
22:44:41  <tjfontaine>well, I dunno, what exactly is the flow you're seeing? are you sure you're not getting the EOF because we've failed in some other way?
22:45:08  * st_lukequit (Ping timeout: 245 seconds)
22:46:45  <AlexisMocha>well, i am not 100% sure but what i am seeing is that if we get an EOF and there was some data in the buffer and the socket is not flowing, we never bother resuming it, and eventually we end up with an error 'stream.push() after EOF'
22:47:42  <tjfontaine>interesting, is it possible we're not actually ever pausing the socket?
22:48:09  * kazuponquit (Ping timeout: 272 seconds)
22:48:25  <tjfontaine>or rather, can you clarify which streams have data in the buffer, and which stream is getting the EOFs
22:48:32  <AlexisMocha>NET 149620: onread -4095 (EOF)
22:48:33  <tjfontaine>i.e. differentiate client and server sides
22:48:49  <AlexisMocha> self.emit('_socketEnd');
22:48:51  <AlexisMocha>all on the client
22:49:54  <AlexisMocha>onSocketEnd does this._readableState.ended = true; and calls destroySoon
22:50:17  <trevnorris>AlexisMocha: just fyi, i'm also seeing strange memory retention as reported in https://github.com/joyent/node/issues/6719
22:50:58  <tjfontaine>I'm not sure that's related
22:51:08  <trevnorris>neither am i :)
22:51:10  <AlexisMocha>destroySoon: if (this.writable) this.end();
22:52:52  <AlexisMocha>which in turn calls destroy, which in turn closes the handle, and we finish here:
22:52:56  <AlexisMocha> Error: stream.push() after EOF
22:52:56  <AlexisMocha> at readableAddChunk (_stream_readable.js:149:15)
22:52:56  <AlexisMocha> at IncomingMessage.Readable.push (_stream_readable.js:129:10)
22:52:56  <AlexisMocha> at HTTPParser.parserOnBody (_http_common.js:132:22)
22:52:57  <AlexisMocha> at Socket.socketOnData (_http_client.js:277:20)
22:52:57  <AlexisMocha> at Socket.EventEmitter.emit (events.js:101:17)
22:52:57  <AlexisMocha> at Socket.Readable.read (_stream_readable.js:373:10)
22:52:57  <AlexisMocha> at Socket.socketCloseListener (_http_client.js:196:10)
22:52:58  <AlexisMocha> at Socket.EventEmitter.emit (events.js:123:20)
22:52:58  <AlexisMocha> at TCP.close (net.js:486:12)
22:53:30  <tjfontaine>and what's in the actual data buffer when we throw?
22:53:56  <AlexisMocha>more valid data, the server was sending a large image, the socket got paused because it went past the high watermark
22:54:19  <AlexisMocha>and it seems that once we get EOF on a paused socket that has some data in the buffer, we deterministically proceed to crash
22:54:28  <tjfontaine>right, so the question is why we signal the EOF sooner on windows than we do on unix
22:55:32  <AlexisMocha>is that the questin? :)
22:55:53  <tjfontaine>heh, well the test is working great on unix ;)
22:56:17  <trevnorris>indexzero: just noticed, i'm getting a bunch of "warning: argument unused during compilation" when compiling openssl
22:56:31  <indexzero>trevnorris: I think you meant indutny
22:56:33  <tjfontaine>you mean indutny
22:56:38  <trevnorris>:P
22:56:54  <indexzero>**in [tab] strikes again**
22:57:01  <trevnorris>indutny: just noticed, i'm getting a bunch of "warning: argument unused during compilation" when compiling openssl
22:57:15  <tjfontaine>AlexisMocha: please file an issue describing what you've learned and what we've discussed so far about that test, and assign it to me, please and thank you
22:58:03  <tjfontaine>AlexisMocha: as I don't want you to spin too long on that, unless you want to continue learning more and more about node+streams and the differences between windows and unix semantics :)
22:58:32  <tjfontaine>AlexisMocha: I do expect though, that whatever the subtle difference here is, we're seeing other bugs pop up (or be hidden) by this
22:59:33  <AlexisMocha>yeah, that sounds good. I have been spending two days on this already and it seems that i might have barely scratched the surface
22:59:43  <MI6>joyent/node: pflannery master * 7ced966 : timers: setImmediate v8 optimization fix - http://git.io/ZNLQ1A
22:59:47  <tjfontaine>trevnorris: ...
22:59:53  <trevnorris>damn it...
23:00:14  <tjfontaine>:)
23:00:17  <trevnorris>why the hell is it doing this?
23:00:31  <tjfontaine>because people have not properly done their `git config`'s
23:00:52  <tjfontaine>in this case
23:01:00  <tjfontaine>it's because the code was submitted with githubs shitty editor
23:01:04  <tjfontaine>From: pflannery <pflannery@users.noreply.github.com>
23:01:11  <trevnorris>you're kidding.... oy.
23:01:27  <tjfontaine>I may add a check to jankins that tells people to fuck right off if they've done that
23:01:56  <trevnorris>seriously. and his github account doesn't have an actual name or email to link back. so we'd depend on what's in the cla.
23:02:45  * brsonjoined
23:03:18  <tjfontaine>ya, we need to slow down on the PRs commits, it's not a race, and there's nothing urgent about them :)
23:03:29  <trevnorris>tjfontaine: wtf. everything in his repos are done through the github editor.
23:04:58  <tjfontaine>trevnorris: right so ... we need to 1) teach the user, 2) take time to verify the patch before pushing it :P
23:05:01  <trevnorris>tjfontaine: do you know of an easy way to change the authors name/email w/o having to manually edit the patch?
23:05:17  <tjfontaine>you can `git commit --ammend --author`
23:05:21  <tjfontaine>*amend
23:06:16  * wolfeidauquit (Read error: Connection reset by peer)
23:06:49  <trevnorris>sorry, doesn't work.
23:07:53  * wolfeidaujoined
23:07:56  <tjfontaine>yes it does: `git commit --amend --author="TJ Fontaine <tjfontaine@gmail.com>"
23:07:57  <trevnorris>tjfontaine: a wait. forgot you need --author="First Last <email>" (the email part)
23:08:04  <trevnorris>thanks
23:08:30  <trevnorris>tjfontaine: so, there a way I can get access to the cla?
23:08:36  <trevnorris>or, at least see who's signed it?
23:08:42  <tjfontaine>yes, I will get you access
23:09:03  <trevnorris>thanks, freak. I wish we could even have the cla contributors submit their gpg keys for verification.
23:09:51  <tjfontaine>we still can
23:09:54  <tjfontaine>but
23:10:11  <trevnorris>hah! fedor did the same in 95ee84fa :P
23:10:12  <tjfontaine>keep in mind, that if we add that as an enforcement mechanism we can't fixup commit messages or authors
23:10:21  <trevnorris>true.
23:10:55  <trevnorris>well, i'm starting to use the signed off thing so everyone can know when I've submitted a crappy patch :)
23:16:42  <trevnorris>unless there's an issue, i'm merging https://github.com/joyent/node/pull/6781
23:18:43  <tjfontaine>I've already done it
23:19:21  <trevnorris>thanks. github didn't refresh like it should have :P
23:19:58  <MI6>nodejs-master: #809 UNSTABLE smartos-x64 (8/687) smartos-ia32 (6/687) osx-ia32 (1/687) osx-x64 (1/687) centos-ia32 (2/687) ubuntu-x64 (1/687) ubuntu-ia32 (2/687) centos-x64 (2/687) http://jenkins.nodejs.org/job/nodejs-master/809/
23:20:53  <trevnorris>groundwater: you around?
23:21:45  * hzquit
23:21:58  <trevnorris>othiym23: so, the ee observer stuff is working well. seeing awesome performance so far. kicker is that I haven't build in a mechanism to allow for the observer to propagate when more are created from a callback.
23:22:29  <trevnorris>othiym23: saving that for the end. feel like trying to address that issue too early in async listeners is what lead to some issues in my implementation.
23:22:46  <petka_>I have some perf improvements to url module, they're pretty substantial. Would you be interested?
23:23:02  <trevnorris>petka_: post a pr and we'll take it from there :)
23:23:10  <trevnorris>petka_: as long as they don't change the existing api
23:23:28  <tjfontaine>petka_: that depends on what that means, post the PR but make sure they come with real world test cases or clear benchmarks that are representative
23:23:28  <othiym23>trevnorris: yeah, one of the key design decisions I made with emitter-listener was to force the developer to explicitly bind an EE into a context
23:23:30  <petka_>it's a full rewrite (same api and semantics of course) so not sure if it can just be a simple pull request
23:23:47  <othiym23>trevnorris: it works pretty well for domains, but but only because errors already disrupt control flow
23:23:50  <petka_>it's 25x faster in node.js benchmarks
23:23:58  <othiym23>don't ask me to explain that -- I think it might only make sense inside my head ;)
23:23:58  <tjfontaine>petka_: what is faster
23:24:10  <petka_>the url module I rewrote
23:24:24  <tjfontaine>petka_: an existing benchmark gets faster
23:24:26  <tjfontaine>?
23:24:29  <petka_>but you don't get that kind of improvement from simple changes.. so it's a full rewrite
23:24:37  <petka_>yes, the one in benchmark folder
23:24:58  <petka_>https://github.com/joyent/node/blob/master/benchmark/misc/url.js
23:25:18  <petka_>I maintain the module here and here are the results from running that benchmark https://github.com/petkaantonov/urlparser/blob/master/README.md
23:25:47  <tjfontaine>what are you doing that requires an uber fast url parser?
23:26:31  * hzjoined
23:26:31  <petka_>well right now url.parse is huge bottleneck anywhere you use it
23:26:37  <tjfontaine>petka_: it's a very dangerous part of the code to change, and needs to make sure it passes all our existing tests, and at the same time comes with more -- and there needs to be a clear reason why it's imperative that it be faster in core, vs what you can provide externally
23:26:44  <petka_>for example in tech empower benchmarks nodejs gets from 20k to 30k request per second
23:26:54  <petka_>and that's a benchmark using databases http requests and templating
23:27:08  <tjfontaine>in a real world application though, most time is not spent on that
23:27:48  <petka_>even in a slow application where throughput is only 4300 RPS, current urlparser brings that down to 3700
23:28:51  * kuebkjoined
23:30:17  <tjfontaine>petka_: you can file the PR, but it needs to be passing our existing tests, come with a bunch more, and have a clear win for core vs people adopting it from npm today
23:31:03  <petka_>since it's a rewrite I thought we should work on it first before making all or nothing PR
23:31:12  <petka_>and it does pass all node.js tests
23:31:23  <inolen>petka_: PR's aren't all or nothing
23:31:35  <inolen>you can append commits, rebase existing ones, etc.
23:34:08  <trevnorris>petka_: if you've already done the work just throw up the PR and we can take it from there. :)
23:34:50  <tjfontaine>I'm just saying, it's not really affecting node today in production, it's not likely to make it in for v0.12 :P
23:34:57  <petka_>the work doesn't directly integrate... there is a build step for example
23:35:58  <trevnorris>i'm just saying a PR will explain a lot more than chatting about it in irc :)
23:36:25  <tjfontaine>trevnorris: the code exists today if youw ant to look at it, it works today as a drop in module from npm
23:36:52  <trevnorris>ah, cool. what's the module name?
23:37:06  <tjfontaine>https://github.com/petkaantonov/urlparser/blob/master/src/urlparser.js
23:37:38  <petka_>npm install fast-url-parser
23:37:59  <petka_>and I didn't think a PR that rewrites so much code would be accepted
23:38:12  <tjfontaine>they can be
23:39:02  <petka_>well you need to run the AST passes script to even convert it to usable source
23:39:40  <petka_>it's pretty ugly macro system
23:40:06  <trevnorris>othiym23: is groundwater on vacation?
23:40:24  <tjfontaine>petka_: ya, that seems like a very low percentage probability to be included in the next (few) minors of node -- I would suggest youkeep it an external module for now
23:40:34  <othiym23>nah, he's just floating around in space somewhere in the New Relic office
23:42:17  <othiym23>tjfontaine: why don't you trust Node's tests? ;)
23:42:39  <tjfontaine>othiym23: :0
23:42:40  <tjfontaine>er
23:42:41  <tjfontaine>othiym23: :)
23:43:54  * kazuponjoined
23:45:32  <AlexisMocha>tjfontaine: https://github.com/joyent/node/issues/6784 not sure how to assign it
23:45:46  <tjfontaine>AlexisMocha: probably can't because of github
23:45:49  <tjfontaine>AlexisMocha: I'll take care of it
23:46:00  <AlexisMocha>tjfontaine: thanks!
23:46:42  <tjfontaine>AlexisMocha: what's the MTU by default for loopback on windows?
23:47:16  <tjfontaine>AlexisMocha: I wonder if we're just sending this all in one packet on unicies, and multiple on windows
23:48:15  * kazuponquit (Ping timeout: 240 seconds)
23:53:45  * kuebkquit
23:55:26  <MI6>joyent/node: Fedor Indutny v0.10 * cb5da7b : deps: update gyp to 828ce09 - http://git.io/FYXTRw
23:55:41  * mikealjoined
23:56:21  <MI6>joyent/node: Timothy J Fontaine master * 3dcb71f : Merge remote-tracking branch 'upstream/v0.10' (+5 more commits) - http://git.io/KCzUSw
23:56:57  * mikealquit (Client Quit)
23:57:34  <petka_>tjfontaine: why is that? There is no other single change that would give as massive boost to overall performance
23:57:46  <AlexisMocha>tjfontaine: apprently 2^32 on the loopback interface
23:58:00  <tjfontaine>petka_: it's not overall performance, because url.parse is only used in two places in node
23:58:16  <tjfontaine>AlexisMocha: hm ok thanks
23:58:25  <petka_>but in practice it's used by any web server, no?
23:58:38  <tjfontaine>is it?
23:58:40  <petka_>should they find out about 3rd party module that I wrote in 3 days
23:58:50  <petka_>or trust that the node core is as fast as it can be
23:59:04  <tjfontaine>there's more to life than being fast as possible
23:59:09  <tjfontaine>we also want to be stable and correct
23:59:35  <petka_>oh I don't mean to rush it of course :)
23:59:41  <tjfontaine>at the moment it's not clear to me that rewriting the url parser really provides users such a massive boost to accept the risk that a ground up rewrite entails
23:59:56  <petka_>because if you even look at the micro perf that does nothing but parse urls