00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:14  <tjfontaine>ill-defined and ill-conceived? :)
00:00:27  <bnoordhuis>probably :) it's a hobby project
00:01:49  <tjfontaine>wc -l lib/_http_*
00:01:50  <tjfontaine> 156 lib/_http_agent.js
00:01:50  <tjfontaine> 548 lib/_http_client.js
00:01:50  <tjfontaine> 231 lib/_http_common.js
00:01:52  <tjfontaine> 176 lib/_http_incoming.js
00:01:55  <tjfontaine> 645 lib/_http_outgoing.js
00:01:57  <tjfontaine> 458 lib/_http_server.js
00:02:00  <tjfontaine> 2214 total
00:02:09  * loladiroquit (Quit: loladiro)
00:02:29  * brsonquit (Quit: leaving)
00:02:47  * brsonjoined
00:04:12  * loladirojoined
00:06:50  <isaacs>mmalecki: 100% fine with this, in master.
00:09:42  * eris0xffjoined
00:17:17  <mmalecki>isaacs: the verifyError thing?
00:18:06  <tjfontaine>that's how I interpreted it
00:18:17  <isaacs>mmalecki: yes
00:19:36  <isaacs>tjfontaine: that's pretty slick
00:20:00  <tjfontaine>dunno if it's of any use
00:20:23  <isaacs>tjfontaine: don't worry about mucking up blame.
00:20:28  <isaacs>tjfontaine: you'll just be blamed for http :)
00:20:39  <isaacs>tjfontaine: but yes, internal modules are cached
00:21:13  <tjfontaine>ok, I need to actually see if it is slower, or if I was just freaking out while watching it
00:22:00  * indexzeroquit (Quit: indexzero)
00:22:03  <eris0xff>bnoordhuis: just after I do a uv_accept I need to initialize my session data structure and associate it with the new client socket (uv_tcp_t) so I can pull it up later. Is there an accepted way to bind these?
00:23:07  <eris0xff>I didnt see an unused field in uv_tcp_t
00:23:16  <eris0xff>maybe i missed it
00:27:36  * trevnorrisquit (Quit: Leaving)
00:38:31  <bnoordhuis>eris0xff: there's the data field
00:38:39  <eris0xff>cool.
00:38:46  <eris0xff>didn't know if that was reserved for something else
00:38:51  <bnoordhuis>you can also embed the uv_tcp_t in a struct of your own and use container_of to look it up
00:40:57  <eris0xff>so if I attach my session pointer to "void *data" in uv_tcp_t then it won't be overwritten by lib routines
00:44:19  * bnoordhuisquit (Ping timeout: 264 seconds)
01:01:44  * brsonquit (Quit: leaving)
01:02:00  * brsonjoined
01:13:05  * dapquit (Quit: Leaving.)
01:29:56  * inolenquit (Quit: Leaving.)
01:36:59  * abraxasjoined
02:03:13  * brsonquit (Ping timeout: 240 seconds)
02:06:18  * inolenjoined
02:17:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:34:25  * loladiroquit (Quit: loladiro)
02:40:10  * inolenquit (Ping timeout: 256 seconds)
02:40:37  * inolenjoined
02:49:39  * inolenquit (Ping timeout: 256 seconds)
02:50:50  * inolenjoined
02:55:49  * kevireillyquit (Remote host closed the connection)
02:56:02  * kevireillyjoined
02:56:44  * loladirojoined
03:15:31  * TooTallNatejoined
03:58:44  * dominictarrjoined
03:59:49  * dominictarrquit (Client Quit)
04:25:47  * mmaleckichanged nick to mmalecki[zzz]
04:29:56  * abraxasquit (Remote host closed the connection)
04:35:13  * AvianFluquit (Remote host closed the connection)
04:36:58  * abraxasjoined
04:50:18  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:18:06  * brsonjoined
05:28:28  * dpemmonsquit (Ping timeout: 245 seconds)
05:32:48  * dpemmonsjoined
05:52:58  * kevireillypart ("Bye!")
06:05:27  * defunctzombiechanged nick to defunctzombie_zz
06:28:34  * trevnorrisjoined
06:30:42  * `3rdEdenjoined
06:36:15  * kuplatup1uchanged nick to kuplatupsu
06:39:29  * rendarjoined
06:50:25  * loladiroquit (Quit: loladiro)
06:57:15  * felixgequit (Quit: felixge)
07:07:28  * paddybyersquit (Read error: Connection reset by peer)
07:07:34  * paddybyers_joined
07:38:19  * loladirojoined
07:43:54  * mmalecki[zzz]changed nick to mmalecki
07:53:24  * hzjoined
08:01:07  * defunctzombie_zzchanged nick to defunctzombie
08:02:19  * brsonquit (Ping timeout: 264 seconds)
08:04:59  * loladiroquit (Quit: loladiro)
08:45:45  * trevnorrisquit (Quit: Leaving)
08:49:09  * dominictarrjoined
09:15:27  * stagasjoined
09:22:52  * dominictarrquit (Quit: dominictarr)
09:33:00  * dominictarrjoined
09:40:21  * piscisaureus_joined
09:47:27  * abraxasquit (Ping timeout: 260 seconds)
09:50:28  * abraxasjoined
09:56:39  * abraxasquit (Ping timeout: 245 seconds)
09:57:07  * abraxasjoined
09:59:51  * csaohquit (Quit: csaoh)
10:02:30  * bnoordhuisjoined
10:03:17  * mmaleckichanged nick to mmalecki[out]
10:07:40  * csaohjoined
10:08:07  * dominictarrquit (Quit: dominictarr)
10:16:13  <piscisaureus_>bnoordhuis: bennetje
10:20:06  * csaohquit (Quit: csaoh)
10:24:15  * csaohjoined
10:35:56  <bnoordhuis>piscisaureus_: bertje
10:36:06  * piscisaureus_changed nick to piscisaureus
10:36:16  <piscisaureus>bnoordhuis: coming to 020 today?
10:36:32  <bnoordhuis>i must be. it's in my calendar
10:36:45  <piscisaureus>calendar life
10:36:56  <piscisaureus>saghul: you still in for today?
10:37:49  <saghul>piscisaureus sure!
10:41:02  <piscisaureus>saghul: let's exchange phone numbers
10:41:26  <piscisaureus>in private :)
10:42:07  <saghul>;-)
11:03:53  * piscisaureusquit (Read error: No route to host)
11:09:29  * abraxasquit (Remote host closed the connection)
11:09:52  <MI6>joyent/node: Trevor Norris master * f83afd3 : src: get rid of compiler warning Removed the following compiler warning (+4 more commits) - http://git.io/3kIxcQ
11:10:35  * abraxasjoined
11:11:58  * abraxasquit (Remote host closed the connection)
11:22:32  * safdasjoined
11:26:54  <MI6>nodejs-master: #146 UNSTABLE windows-x64 (6/575) linux-x64 (1/575) windows-ia32 (7/575) smartos-ia32 (3/575) smartos-x64 (3/575) http://jenkins.nodejs.org/job/nodejs-master/146/
11:33:25  * sgallaghjoined
11:43:31  <MI6>joyent/node: Ben Noordhuis v0.10 * dbbfbe7 : cluster: fix O(n*m) scan of cmd string Don't scan the whole string for a - http://git.io/5FRgfw
11:44:43  <bnoordhuis>^ that should have been caught during review :-/
11:46:05  <bnoordhuis>hm, according to git grep, that's not the only place where we're doing that...
11:46:32  * mmalecki[out]changed nick to mmalecki
11:47:11  * mikealjoined
11:50:51  * `3rdEdenquit (Remote host closed the connection)
11:54:47  <MI6>joyent/node: Ben Noordhuis v0.10 * 212eb8a : child_process: fix O(n*m) scan of cmd string Don't scan the whole string - http://git.io/FxRHMQ
11:55:02  * `3rdEdenjoined
11:59:43  * piscisaureus_joined
11:59:52  <piscisaureus_>back
12:00:50  <MI6>nodejs-v0.10: #128 UNSTABLE windows-x64 (7/575) windows-ia32 (5/575) http://jenkins.nodejs.org/job/nodejs-v0.10/128/
12:03:43  <csaoh>hello ! I don't know if this is an appropriate place for this question, since it's about http-parser but i guess i can give it a try… i'm trying to use a php port of http_parser_execute, and I realized I couldn't parse headers from a request unless it's been completely sent. For instance, if I send a request with Content-Length set to 5096, but with only 4096 bytes in the body (assuming the rest will be sent later), is there a w
12:03:43  <csaoh>to parse the headers anyway ?
12:04:36  * hzquit
12:12:35  <bnoordhuis>csaoh: well, the headers will have been parsed. http-parser doesn't buffer anything, it emits parsed header names/values immediately
12:12:45  <bnoordhuis>it's probably the php port that is holding them back
12:13:05  <csaoh>that must be it then, since i don't get any results unless all of the data is here
12:13:06  <csaoh>thanks
12:17:46  <MI6>nodejs-v0.10: #129 UNSTABLE windows-x64 (5/575) windows-ia32 (6/575) http://jenkins.nodejs.org/job/nodejs-v0.10/129/
12:39:32  * aledbfjoined
12:43:32  * bnoordhuisquit (Ping timeout: 252 seconds)
12:49:12  * AvianFlujoined
12:52:27  * mikealquit (Read error: Connection reset by peer)
12:52:36  * mikeal1joined
12:52:54  * bnoordhuisjoined
12:53:52  * mikeal1quit (Client Quit)
12:55:55  * c4milojoined
12:59:31  * mmaleckiquit (Quit: leaving)
12:59:53  * aledbfquit (Quit: aledbf)
13:00:13  * aledbfjoined
13:17:36  <piscisaureus_>bnoordhuis: when are you taking the train?
13:33:21  <bnoordhuis>piscisaureus_: five-ish
13:33:41  <bnoordhuis>i'll be in 020 around 1800, i think
13:35:00  <bnoordhuis>want to meet up in that pub near the train station?
13:35:14  * inolenquit (Ping timeout: 256 seconds)
13:35:55  * inolenjoined
13:40:42  <bnoordhuis>also, http://www.nrc.nl/carriere/2013/04/11/zweedse-lingerieverkoopsters-hoeven-hun-cupmaat-niet-op-naamplaatje/
13:40:51  <bnoordhuis>my first 'wat?' moment of the day
13:41:20  <bnoordhuis>'wat?' both in dutch and english
13:45:03  * safdasquit (Ping timeout: 245 seconds)
13:59:26  <saghul>bnoordhuis are you riving at CS station?
14:04:59  <bnoordhuis>saghul: yep
14:05:35  <saghul>bnoordhuis I also need to go there to take the tram, what time does your train arrive?
14:06:38  <bnoordhuis>saghul: 17.52 if ns.nl is to be believed
14:07:28  <saghul>bnoordhuis ok, lets meet outside of the main entrance, then we go get the tram to meet bert
14:07:41  * aledbfquit (Ping timeout: 255 seconds)
14:08:33  <bnoordhuis>saghul: yeah, but where is bert?
14:08:42  <bnoordhuis>piscisaureus_: wake up!
14:08:53  <piscisaureus_>hello
14:08:54  <piscisaureus_>I'm here
14:09:08  <bnoordhuis>piscisaureus_: what's the plan?
14:09:20  <piscisaureus_>bnoordhuis: The plan was to go to brecht.
14:09:29  <bnoordhuis>brecht?
14:09:40  <piscisaureus_>bnoordhuis: but if you and saghul are both at CS then maybe it's easier if I come your way :)
14:09:52  <bnoordhuis>agreed :)
14:09:59  <saghul>heh
14:10:29  <bnoordhuis>saghul: there's this okay pub near CS. i'll walk you there. bert knows where it is
14:10:43  <piscisaureus_>bnoordhuis: which one? dwaze zaken?
14:10:51  <saghul>bnoordhuis ack
14:10:57  <bnoordhuis>the one in the white building, near the road
14:11:03  <piscisaureus_>yeah that's dwaze zaken
14:11:06  <piscisaureus_>ok how late?
14:11:10  <bnoordhuis>six-ish?
14:11:21  <piscisaureus_>ok
14:11:33  <bnoordhuis>as long as there's beer, i don't mind if you're a little late
14:14:15  * aledbfjoined
14:14:18  * stagasquit (Read error: Connection reset by peer)
14:17:01  * bnoordhuisquit (*.net *.split)
14:17:01  * sgallaghquit (*.net *.split)
14:17:01  * txdvquit (*.net *.split)
14:17:01  * wolfeidauquit (*.net *.split)
14:17:01  * dscapequit (*.net *.split)
14:19:01  * bnoordhuisjoined
14:19:01  * sgallaghjoined
14:19:01  * txdvjoined
14:19:01  * wolfeidaujoined
14:19:01  * dscapejoined
14:20:25  * c4miloquit (Remote host closed the connection)
14:24:33  <bnoordhuis>saghul: did you get my last message?
14:24:46  <bnoordhuis>("what last message?")
14:24:52  <saghul>yep, 17:52
14:25:04  <saghul>main entrance, right?
14:25:13  <bnoordhuis>yes, but
14:25:16  <bnoordhuis>saghul: we can meet up in dwaze zaken. saves having to wait outside in the rain
14:25:20  <bnoordhuis>^ that last message :)
14:25:36  <saghul>sure
14:25:43  * saghulchecks map
14:27:56  <bnoordhuis>okay, i'm off. bert has my number if you need it (i always forget mine)
14:32:36  * bnoordhuisquit (Ping timeout: 256 seconds)
14:55:35  * `3rdEdenchanged nick to `3E|GONER
15:22:29  * erickt_joined
15:22:30  * erickt_quit (Client Quit)
15:32:18  <isaacs>good morning
15:32:34  <isaacs>about to start v0.10.4
15:46:24  * dominictarrjoined
15:47:26  * `3E|GONERquit (Remote host closed the connection)
15:48:16  <piscisaureus_>isaacs: should I make a libuv release?
15:48:29  <piscisaureus_>there's a bunch of patches applied
15:48:45  <piscisaureus_>isaacs: you can also practice it yourself if you want to
15:48:54  <piscisaureus_>(but that means you'll have to write the changelog)
15:49:00  <isaacs>piscisaureus_: yes! are you free fora few minutes to show me how to do it?
15:49:09  <piscisaureus_>isaacs: only a few minuts. But let's go!
15:49:18  <isaacs>great!
15:49:43  <piscisaureus_>isaacs: ok, you'll need an up-to-date libuv clone that has all the tags
15:49:46  <piscisaureus_>isaacs: also clone https://github.com/piscisaureus/libuv-release-tool
15:50:10  <piscisaureus_>isaacs: in the libuv clone, check out the v0.10 branch
15:50:24  <isaacs>k
15:50:55  <piscisaureus_>isaacs: tell me when you have that
15:51:04  <isaacs>have that
15:51:10  <piscisaureus_>isaacs: ok.
15:51:57  <piscisaureus_>isaacs: ok. go to the libuv tool dir and run './release.js --dir=/path/to/libuv'
15:52:04  <piscisaureus_>and be sure that you checkout out v0.10 :)
15:52:27  <isaacs>cool! it did stuff
15:52:28  <isaacs>https://gist.github.com/5364568
15:53:01  <isaacs>looks like it removed one of mscdex's email addresses?
15:53:33  <isaacs>oh, no, it just added a new line
15:54:22  <piscisaureus_>isaacs: that looks good, probably mscdex shows up as "mscdex <mscdex@mscdex.net>" in the git log
15:54:25  <piscisaureus_>isaacs: so it fixed that
15:54:43  <isaacs>k
15:54:54  <isaacs>--continue?
15:54:59  <piscisaureus_>isaacs: so just --continue yeah
15:55:14  <isaacs>hmm... i think my git is not gitty enough
15:55:15  <isaacs>https://gist.github.com/5364600
15:55:25  <piscisaureus_>it's too old ...
15:55:32  <isaacs>$ git --version
15:55:32  <isaacs>git version 1.7.5.4
15:55:39  <isaacs>uh oh
15:55:55  <isaacs>installing 1.8.2 now
15:55:59  <piscisaureus_>isaacs: kewl
15:56:02  <piscisaureus_>isaacs: it aborted...
15:56:20  <piscisaureus_>isaacs: you probably have to git reset --hard libuv before trying again
15:56:26  <isaacs>kk
15:56:29  <piscisaureus_>(aborting doesn't roll back the git tree state)
15:57:11  <isaacs>dude...
15:57:13  <isaacs>this is nice!
15:57:32  <isaacs>https://gist.github.com/5364627
15:57:48  <piscisaureus_>isaacs: yup, you can edit stuff in there
15:57:52  <isaacs>remove the "now working" bit, i take it?
15:58:03  <piscisaureus_>oh, that should have been filtered out, weird that it didn't happen
15:58:07  <piscisaureus_>isaacs: but yeah it has to go
15:58:44  <isaacs>you can probably omit the "Changes since version 0.10.3:
15:58:47  <isaacs>kind of implied
15:59:04  <piscisaureus_>isaacs: well, yeah, just stick to the template :)
15:59:19  <isaacs>kk
15:59:29  <isaacs>look good? https://gist.github.com/5364645
15:59:31  <piscisaureus_>isaacs: I'm considering making it more aware of merges
15:59:56  <piscisaureus_>isaacs: it's acceptable and I am in a hurry, so just push on with it :)
16:00:02  <isaacs>kk
16:00:31  <piscisaureus_>isaacs: I think myself I would redact it a little more because often these commit messages are not very meaningful for a bystander
16:00:35  <isaacs>* 5ed1d02 isaacs (HEAD, v0.10) Now working on v0.10.5 (18 seconds ago)
16:00:35  <isaacs>* 85827e2 isaacs (v0.10.4) 2013.04.12, Version 0.10.4 (Stable) (22 seconds ago
16:00:52  <isaacs>pushing!
16:01:04  <MI6>joyent/libuv: isaacs created tag v0.10.4 - http://git.io/bzEOXg
16:01:05  <isaacs>kapow
16:01:06  <MI6>joyent/libuv: isaacs v0.10 * 5ed1d02 : Now working on v0.10.5 (+1 more commits) - http://git.io/jaiDtQ
16:01:08  <isaacs>that was easy
16:01:10  * TooTallNatejoined
16:01:20  <isaacs>let's stop releasing binaries. they're too much trouble.
16:01:29  <tjfontaine>amen.
16:01:30  <piscisaureus_>isaacs: didn't upload the tarball though...
16:01:30  <isaacs>and the website. just redirect to the github download page.
16:01:37  <isaacs>right! where do i send that?
16:01:54  <piscisaureus_>isaacs: well it should be automatic (it should say "...uploadTarBall")
16:02:16  <piscisaureus_>isaacs: but I think you don't have your ssh key installed where it should be
16:02:25  <piscisaureus_>isaacs: I can fix this up manually though, don't worry for now
16:02:40  <isaacs>https://gist.github.com/5364666
16:02:56  <isaacs>i don't see it trying any tarball stuff
16:03:07  <isaacs>my ssh key is on the agent, should work fine
16:03:08  <MI6>libuv-v0.10: #33 FAILURE smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/33/
16:03:17  <piscisaureus_>isaacs: after review you --continue'd right? Or it wouldn't have uploaded the tag
16:03:22  <piscisaureus_>what did it print then?
16:03:28  <isaacs>ohhhh...
16:03:30  <isaacs>i pushed the tag myself
16:03:32  <isaacs>i didn't --continue again
16:03:32  <piscisaureus_>aah
16:03:34  <isaacs>thought it was done
16:03:38  <piscisaureus_>just run --continue once more :)
16:03:40  <isaacs>k, i'll kill hte tag and --continue it
16:03:57  <piscisaureus_>isaacs: well don't delete the local tag, just remove the upstream one
16:04:02  <tjfontaine>er did someone abort a build, or did windows decide to do that for me
16:04:13  <isaacs>right
16:04:17  <isaacs>we're done!
16:04:34  <piscisaureus_>isaacs: yup, it's there: http://libuv.org/dist/
16:04:44  <isaacs>i <3 that website, btw.
16:04:45  <isaacs>http://libuv.org/
16:04:53  <isaacs>so clean! such wonderful use of white space!
16:05:12  <piscisaureus_>isaacs: but, nice automation eh? :)
16:05:17  <isaacs>yah, i like it
16:05:21  <isaacs>we need to do that for node.
16:05:35  <isaacs>but it has to build binaries on all the different os's
16:05:59  <piscisaureus_>good luck with that :)
16:06:08  <piscisaureus_>I have to run now, Ben and saghul are probably waiting for me
16:06:14  <piscisaureus_>isaacs: have a good night
16:06:24  <isaacs>thanks!!
16:06:43  <MI6>libuv-v0.10: #34 UNSTABLE smartos (4/186) linux (2/186) osx (2/186) windows (7/187) http://jenkins.nodejs.org/job/libuv-v0.10/34/
16:07:36  <MI6>joyent/node: isaacs v0.10 * e5fdc4d : uv: Upgrade to v0.10.4 - http://git.io/YuACfA
16:07:53  * bradleymeckjoined
16:11:04  * piscisaureus_quit (Ping timeout: 256 seconds)
16:15:56  * paddybyers_quit (Ping timeout: 255 seconds)
16:18:08  <MI6>joyent/node: isaacs v0.10 * 1ccae9c : npm: Upgrade to 1.2.18 - http://git.io/jIBOog
16:25:24  * brsonjoined
16:27:23  <MI6>nodejs-v0.10: #130 UNSTABLE osx-x64 (1/575) linux-x64 (2/575) smartos-x64 (43/575) windows-x64 (65/575) windows-ia32 (5/575) http://jenkins.nodejs.org/job/nodejs-v0.10/130/
16:27:53  <isaacs>whoa...
16:27:56  <MI6>libuv-node-integration: #15 UNSTABLE smartos-x64 (1/575) smartos-ia32 (54/575) linux-ia32 (1/575) windows-ia32 (73/575) osx-ia32 (1/575) linux-x64 (1/575) windows-x64 (5/575) http://jenkins.nodejs.org/job/libuv-node-integration/15/
16:28:00  <isaacs>43 failures on smartos?
16:29:35  <isaacs>tjfontaine: weird, getting ADDRINUSE on that one
16:29:54  <tjfontaine>are you also building on samrtos-drone at the moment?
16:30:00  <isaacs>no
16:30:08  <isaacs>but i was about to start :)
16:31:36  <tjfontaine>windows also had a lot of failures
16:31:57  <tjfontaine>so two jobs running at once it would seem, probably a collision with the libuv-node-integration job --- though it shouldn't have
16:33:20  * benoitcquit (Excess Flood)
16:34:12  * indexzerojoined
16:34:52  <tjfontaine>oh damn
16:36:07  * stagasjoined
16:37:47  * paddybyersjoined
16:38:26  <isaacs>hm
16:38:28  <isaacs>that makes sense
16:38:34  <isaacs>ok, i'm moving forward with the build
16:38:52  * dominictarrquit (Quit: dominictarr)
16:39:00  <tjfontaine>btw scrum
16:39:30  <MI6>joyent/node: isaacs created branch v0.10.4-release - http://git.io/7O5nXw
16:41:57  * benoitcjoined
16:43:46  * inolenquit (Quit: Leaving.)
16:44:29  <MI6>nodejs-v0.10: #131 UNSTABLE linux-x64 (1/575) windows-x64 (5/575) windows-ia32 (5/575) http://jenkins.nodejs.org/job/nodejs-v0.10/131/
16:55:57  * dominictarrjoined
17:00:26  * csaohquit (Quit: csaoh)
17:09:32  * loladirojoined
17:23:02  * indexzeroquit (Quit: indexzero)
17:25:14  * trevnorrisjoined
17:26:43  <trevnorris>good morning-ish
17:27:51  * inolenjoined
17:28:11  * `3rdEdenjoined
17:34:38  * eris0xffquit (Ping timeout: 245 seconds)
17:37:09  <trevnorris>TooTallNate, tjfontaine: api architecture question: say I have "Alloc(char* data, uint32_t length)" that will use the data passed, is it overkill to create "Alloc(const char* data, uint32_t length)" that will copy the data?
17:40:18  <tjfontaine>hmm can you overload with const semantics?
17:40:24  <trevnorris>yeah.
17:40:41  <trevnorris>apperently. it compiles and works. =)
17:41:04  <TooTallNate>i was wondering the same thing haha
17:41:12  <tjfontaine>I'm not sure which you would get
17:41:25  <TooTallNate>trevnorris: i would ask one of the C guys like ben or bert if that's conventional in C or not
17:41:39  <tjfontaine>if you pass plain old char* to const char* I would presume adding constyness is ok
17:42:01  <tjfontaine>but in the case where you have two signatures in c++ I would expect you get the one that matches your type the most
17:42:08  <trevnorris>TooTallNate: good idea.
17:42:12  <TooTallNate>trevnorris: personally i'd probably just do a Copy(const char* data, uint32_t length) function instead
17:42:18  <TooTallNate>more explicit that way
17:42:24  <tjfontaine>yes, explicit > implicit in this case
17:42:35  <trevnorris>ah yeah. good old rule.
17:51:52  <trevnorris>TooTallNate: just about to wrap up the api for the allocator. when I'm done mind giving feedback on the usefulness for module creators?
17:52:27  <TooTallNate>trevnorris: ya for sure
17:52:52  <TooTallNate>trevnorris: are all existing native modules going to break basically?
17:53:07  <isaacs>making tests one more time
17:53:32  <isaacs>then 10.4
17:53:47  <isaacs>it's amazing how people have switched to saying "version 10" in conversation
17:53:49  <isaacs>i hear it a lot now
17:53:51  <trevnorris>isaacs: so can't throw in one more little itty bitty commit?
17:53:55  <isaacs>nope
17:53:58  <isaacs>10.5!!
17:54:16  <trevnorris>isaacs: that's cool. it just gets rid of a compiler warning. nothing big.
17:54:17  <isaacs>there will be another next week (or maybe early the week after, TxJS)
17:54:19  <isaacs>k
17:54:28  <isaacs>binaries are already built and uploaded.
17:55:03  <trevnorris>TooTallNate: I think I'll be able to replicate all current Buffer functionality. going for full backwards compatibility.
17:55:42  <TooTallNate>trevnorris: sounds good
18:01:12  <MI6>joyent/node: isaacs created tag v0.10.4 - http://git.io/OCGCbQ
18:06:36  <MI6>joyent/node: isaacs v0.10 * 22c7d13 : lint (+1 more commits) - http://git.io/JYeYtg
18:07:20  <MI6>joyent/node: isaacs v0.10 * 440bc06 : Now working on v0.10.5 (+2 more commits) - http://git.io/z8OeXA
18:10:38  * hzjoined
18:19:03  * hzquit (Disconnected by services)
18:19:06  * hzjoined
18:19:18  * qmxchanged nick to qmx|lunch
18:19:41  <trevnorris>TooTallNate: here's the branch w/ the basics: https://github.com/trevnorris/node/compare/buffer-buffet-revamp
18:19:59  <TooTallNate>trevnorris: what's buffet?
18:20:15  <trevnorris>the cc api is in node_smalloc.h, and you can see examples of the js api in test-smalloc.js
18:20:30  <trevnorris>TooTallNate: http://en.wikipedia.org/wiki/Buffet
18:20:49  <TooTallNate>oh right
18:20:49  <TooTallNate>hahah
18:20:55  <trevnorris>strange branch names are one of my few creative outlets. ;-)
18:21:05  <TooTallNate>haha
18:24:22  <MI6>nodejs-v0.10: #132 UNSTABLE osx-x64 (1/575) windows-x64 (5/575) windows-ia32 (7/575) http://jenkins.nodejs.org/job/nodejs-v0.10/132/
18:26:37  * joshthecoderquit (Excess Flood)
18:26:43  * joshthecoderjoined
18:28:29  * loladiroquit (Quit: loladiro)
18:34:11  * dapjoined
18:58:34  * luigyquit (Ping timeout: 246 seconds)
19:04:16  * luigyjoined
19:11:47  * luigyquit (Read error: Operation timed out)
19:13:21  * hzquit (Disconnected by services)
19:13:24  * hzjoined
19:23:53  * benoitcquit (Excess Flood)
19:27:57  <isaacs>trevnorris, tjfontaine, TooTallNate: Any of you gentleman have a time for a streams2 puzzle?
19:28:10  <trevnorris>isaacs: sure. what's up?
19:28:12  <isaacs>I figured out the problem, but kind of chewing on a few potential solutions.
19:28:13  * stagasquit (Read error: Connection reset by peer)
19:28:19  <isaacs>so, we have this thing, Readable.unshift()
19:28:33  <isaacs>for cases when you're optimistically parsing, and then pull off more than you meant to, and want to put some back.
19:28:43  <isaacs>a la http->websocket interface
19:29:15  <isaacs>also, in Readable._read(), it's expected that the stream Author calls push(chunk) to mark that they're not reading any more.
19:29:57  <isaacs>however, if you're the one *consuming* the stream, then you call unshift(chunk), that *also* unsets the "reading" flag, and causes colliding _reads, which fucks up in the case of async fs ops, and other things
19:30:27  * benoitcjoined
19:30:32  <isaacs>one potential solution is for unshift() to *not* set reading=false
19:30:37  * yawntchanged nick to PKTDev`
19:30:49  * PKTDev`changed nick to yawnt
19:30:52  <isaacs>of course, then it should be noted that stream *Authors* always have to call push(), and that *Consumers* call unshift()
19:31:22  <isaacs>problem 2: what happens if you're doing this optimistic parsing, and the EOF chunk has been seen?
19:31:34  <isaacs>ie, can you read() -> emit('end') -> unshift(somePart)
19:32:23  <isaacs>then what...?
19:32:34  <isaacs>emit('readable') again, pretend that didn't happen?
19:34:42  <trevnorris>heh, give me a few to wrap my head around that.
19:34:46  <isaacs>kk :)
19:36:32  * luigyjoined
19:39:10  <trevnorris>isaacs: too lazy to look at the source right now. does .unshift() copy the data or use the original?
19:39:31  <isaacs>uses the original, but of course, what you end up read()ing may be a copy
19:39:53  <isaacs>unless you happen to read() the exact size of the unshifted chunk
19:39:53  <trevnorris>oh, i'm just thinking about the potential memory leak scenarios using .slice w/ .unshift()
19:40:01  <isaacs>sure.
19:40:06  <isaacs>forget about New Buffers for now :)
19:40:14  <trevnorris>lol, ok.
19:40:25  <isaacs>actually, we should trade problems every so often, i think.
19:40:36  <isaacs>i used to work on a team where we did that. it was a very good practice.
19:40:53  <isaacs>keeps your brain flexible
19:41:06  <trevnorris>sounds good to me. been staring at buffers for weeks.
19:41:18  <isaacs>so... i think i have a solution that will work
19:41:32  <isaacs>but it requires changing the semantics of unshift() so that it doesn't mark the end of a _read()
19:41:44  <isaacs>and so that it can "push back" an already-emitted end event
19:43:28  <trevnorris>what do you mean by "push back"?
19:45:11  <isaacs>ok, so...
19:45:16  <isaacs>let's say the file is 256 bytes
19:45:43  <isaacs>var buf = fs.read(); buf.length === 256, 'end' is emitted
19:45:56  <isaacs>(fs == file stream)
19:46:12  <isaacs>stream.unshift('didnt parse this bit')
19:48:16  <trevnorris>hm. technically it's possible to unshift anything, right?
19:48:39  <isaacs>yes
19:49:16  <isaacs>trevnorris: https://gist.github.com/5366610
19:50:29  <trevnorris>what about if a user does an async .unshift()? it'd be impossible to reliably only emit "end" once.
19:50:59  <isaacs>exactly
19:51:14  <isaacs>pushing null causes a 'readable' to be emitted
19:51:24  <isaacs>then read() gets whatever's left
19:51:30  <isaacs>and *also* triggers an 'end' event
19:51:43  <isaacs>unshifting then puts some more into the buffer
19:51:55  <isaacs>and *another* 'end' happens when that chunk is consumed
19:52:15  <isaacs>but, if i'm doing this because i'm a parser, and then i'm going to hand the stream off to you, then that's actually what i want.
19:52:23  <isaacs>becasue otherwise you wno't see the 'end' event
19:53:06  <trevnorris>what about the issue in your gist, where you call "w.end()" on the writable stream? how could a user tell when they could call writable.end()?
19:54:01  * piscisaureus_joined
19:55:23  * bradleymeckquit (Quit: bradleymeck)
19:57:04  <isaacs>right
19:57:18  <isaacs>because if you do w.write() after w.end() then it is fucked.
19:59:59  <isaacs>so... unshift() after the 'end' event should be verboten...
20:00:17  * qmx|lunchchanged nick to qmx
20:01:16  <isaacs>that's easy enough to detect.
20:01:16  <tjfontaine>windows, please tell me why your build is failing *grr*
20:01:38  <isaacs>trevnorris: and, looks like we nexTTick the actual emission of the event anyway, so we can just add a check there to make sure that the length is still 0
20:02:19  * piscisaureus_quit (Ping timeout: 264 seconds)
20:03:20  <trevnorris>isaacs: what will happen if you wrap your r.unshift() in setImmediate, 'end' would still be emitted and the length == 0, right?
20:03:38  <isaacs>trevnorris: correct
20:03:41  <isaacs>then your unshift() is a problem.
20:03:55  <isaacs>it's like, when you read(), NOW is the only time that you're allowed to put any of that back in
20:03:59  <isaacs>otherwise it might be too late.
20:04:06  <isaacs>you have this run-to-completion only
20:04:45  <trevnorris>so technically if a user has an unshift() anywhere the writable stream could last the entirety of app run time.
20:05:03  <trevnorris>it almost seems if a user uses unshift() they have to be responsible to emit end.
20:05:09  <isaacs>well, sure, i mean, if you have a readable that doesn't end, then it's the same thing
20:05:23  <isaacs>no, that's too easily fucked up
20:05:26  <trevnorris>yeah
20:06:41  <trevnorris>ok, so run your solution past me again?
20:07:10  <trevnorris>emitting 'end' more than once seems fine. unless the user does some cleanup in the callback that removes the ability to use the stream again.
20:07:27  <isaacs>actually, i think emitting end more than once is terrible.
20:07:35  * jhlkfasjoined
20:07:37  <trevnorris>ah, ok.
20:07:42  <trevnorris>misunderstood
20:07:52  <isaacs>no, you understood correctly, but then i changed my mind :)
20:07:57  <trevnorris>oh. lol
20:07:58  <isaacs>you convinced me
20:08:00  <isaacs>so
20:08:11  <isaacs>we move the endEmitted flag into the nextTick where emit('end') actually happens
20:08:33  <isaacs>when you read() and get data, you have one chance to unshift() some of it back if you didn't consume it.
20:08:43  <isaacs>this cannot be deferred, or else you'll fuck the 'end' event
20:09:05  <trevnorris>sounds good. that one constraint makes things a lot simpler.
20:10:31  <isaacs>yeah
20:10:33  <isaacs>that's easy to document
20:10:39  <isaacs>and it makes the test pass nicely :)
20:10:57  <isaacs>i get a bunch of orderly "asdf" strings each prefixed by "1234" and then one last "1234" at the very end.
20:14:55  * loladirojoined
20:20:03  * jhlkfasquit (Ping timeout: 245 seconds)
20:25:22  * rasmuslnjoined
20:26:42  * rasmuslnpart
20:28:04  * rasmuslnjoined
20:31:56  * rasmuslnpart
20:32:21  <MI6>libuv-master: #74 UNSTABLE linux (2/187) smartos (4/187) windows (6/188) osx (1/187) http://jenkins.nodejs.org/job/libuv-master/74/
20:33:48  * `3rdEdenquit (Remote host closed the connection)
20:40:06  * hzquit
20:41:56  * rendarquit
20:49:17  <MI6>libuv-node-integration: #16 UNSTABLE windows-ia32 (8/575) osx-ia32 (1/575) osx-x64 (1/575) linux-x64 (1/575) windows-x64 (6/575) http://jenkins.nodejs.org/job/libuv-node-integration/16/
20:59:08  * loladiroquit (Quit: loladiro)
21:05:44  * loladirojoined
21:12:37  * luigyquit (Ping timeout: 248 seconds)
21:19:24  * luigyjoined
21:26:54  <tjfontaine>ok I was just overly sensitive, my http.js split doesn't have an appreciable effect on test execution time
21:38:55  <trevnorris>isaacs: can you recap the decision on passing errors to an async callback? i have so many discussions on this in my head I can't tell them apart.
21:51:27  <isaacs>trevnorris: i think that the current thinking is: TRESUR errors get thrown now, everything else passed to cb, emit('error') should not ever be nextTick'ed
21:51:30  <isaacs>except in the ctor
21:51:44  <isaacs>(and really, if you're emitting error in the ctor, then wth, srsly)
21:51:49  <isaacs>since that hsould really be a TRESUR
21:52:59  <trevnorris>cool. thanks
21:53:23  <isaacs>np
21:53:33  <isaacs>edge cases are handled case-by-case
21:53:57  <isaacs>\0 in fs paths is passed to callback. buffer indexes out of range, or <0, are thrown
21:54:24  <trevnorris>makes sense.
21:54:26  <isaacs>*in general*, if the error relates to a specific object, it's probably better to emit than throw.
22:25:35  <trevnorris>isaacs: well poop. so i implemented buffer pools w/ the new allocator just for kicks, and they're 50% faster for small buffers (< 1000 bytes).
22:25:41  <trevnorris>but w/o the pooling they're 30% slower.
22:27:07  <isaacs>trevnorris: https://github.com/joyent/node/pull/5280
22:32:39  <trevnorris>isaacs: like it. and like the explicit errors. definitely help devs figure out what's going on.
22:32:59  * bnoordhuisjoined
22:41:15  <trevnorris>bnoordhuis: api question. is it bad practice to overload a function like "Fn(char* data)" and "Fn(const char* data)"?
22:41:39  <trevnorris>(first would use the original data, and the second would copy the data.
22:42:53  <bnoordhuis>trevnorris: that won't work in most cases
22:43:11  <bnoordhuis>unless Fn() is a const method, i think
22:43:38  <bnoordhuis>but to answer your question, no, that's not great api design :)
22:44:15  <trevnorris>heh, ok.
22:44:44  * loladiroquit (Quit: loladiro)
22:46:20  <trevnorris>bnoordhuis: one more q. for kicks I reimplemented buffer pools using the new allocator, and thy're ~50% faster. problem is the pooling is why I started this to begin w/.
22:46:38  <trevnorris>initially you think just use the pools, then work out the other later?
22:50:26  <isaacs>trevnorris: 50% faster pools sounds great :)
22:50:33  * brsonquit (Remote host closed the connection)
22:50:35  <isaacs>trevnorris: but yeah, it doesn't solve the root problem you were going after.
22:50:39  * stagasjoined
22:51:19  <trevnorris>isaacs: cool. and at the >1024*8 size, it's about 3x's faster.
22:51:41  <trevnorris>guess for initial implementation i'll just get the general architecture down, and worry about the root problem later.
22:51:57  <trevnorris>this is getting complicated very fast.
22:52:04  * aledbfquit (Read error: Operation timed out)
22:52:18  <isaacs>trevnorris: also, without some kind of pooling, we have that problem bert was talking about re our libuv interaction
22:52:30  <isaacs>trevnorris: also, without some kind of pooling, we have that problem piscisaureus was talking about re our libuv interaction
22:52:38  <isaacs>(repeated for the benefit of his ircretary logging)
22:52:44  <trevnorris>heh, ok.
22:52:50  <trevnorris>can you refresh my memory
22:53:26  <isaacs>so, when we call into libuv, we do something like: uv_blerg(buffer, bufferLength, on_blerg_cb)
22:53:54  <isaacs>then it calls on_blerg_cb(howManyBytes)
22:54:00  <isaacs>which is <= bufferLength
22:54:40  <isaacs>so: if we have a pool, then it's great, because we can just slice off that bit, increment the counter, decrement the available space, and reuse most of it
22:54:56  <isaacs>if we don't, then even a 10-byte chunk requires 64kb of space
22:55:24  <trevnorris>that's handled by the SlabAllocator, right?
22:56:08  <tjfontaine>right the Shrink interaction
22:56:31  <trevnorris>yeah. there are several things I want to try w/ that.
22:57:21  <trevnorris>for example, you can create just allocated memory very very fast (non buffer), then create a buffer from a slice of it later.
22:57:49  <tjfontaine>isaacs: did you recently force push 5280?
22:58:09  <isaacs>tjfontaine: i did amend the commit message, yes
22:58:22  <isaacs>tjfontaine: does that break something, because it's a pull req?
22:58:50  <tjfontaine>I was just curious why the CI status stuff dropped off, and why the build was going again
23:01:39  <isaacs>ah, kewl
23:01:50  <isaacs>bnoordhuis: wanna review this? https://github.com/joyent/node/pull/5280
23:02:27  <trevnorris>TooTallNate: think I figured out a way to get rid of the instanceof check in Buffer. (emphasis on _think_)
23:03:57  <isaacs>TooTallNate: or you can review it as well: https://github.com/joyent/node/pull/5280
23:04:12  <isaacs>trevnorris already granted the basic sanity check, but it's good to have more eyes on streams changes
23:04:48  <trevnorris>isaacs: uh, with any change to streams, i'd hope so. imho that's the most complex code in node.
23:05:16  <trevnorris>the api is fleshing out really well, but this transition period has been a trip.
23:07:04  <isaacs>yeah
23:09:01  <isaacs>huh. making https time out.
23:09:04  <isaacs>hooray tests!
23:09:27  <tjfontaine>heh
23:13:09  * bnoordhuisquit (Ping timeout: 248 seconds)
23:13:10  <isaacs>tjfontaine: force push
23:14:10  * abraxasjoined
23:15:22  * loladirojoined
23:15:33  <tjfontaine>aborted the other, its output is kinda hilarious :)
23:18:05  <trevnorris>isaacs: may be too much, but implementation would be trivial. add the ability to callback a js object from a MakeWeakCallback?
23:18:15  <trevnorris>*js function
23:18:31  * abraxasquit (Ping timeout: 260 seconds)
23:18:47  <isaacs>trevnorris: like the weak module does?
23:19:44  <trevnorris>isaacs: yeah, but much simpler.
23:21:09  * loladiroquit (Quit: loladiro)
23:22:31  <trevnorris>isaacs: the extent would be "alloc(n, fn)". node-weak has a lot more niceties.
23:22:45  <isaacs>true that
23:23:15  <tjfontaine>there https://github.com/tjfontaine/node/compare/http-split now with logical steps
23:25:49  <isaacs>tjfontaine: the goal should probably be to remove most of that stuff in _http_common.js out of there
23:26:02  <isaacs>tjfontaine: eg, client and server should each have their own parser pool
23:26:21  <isaacs>but, that's phase 2 :)
23:26:26  <tjfontaine>heh
23:26:43  <tjfontaine>shall I make a pull req for this?
23:28:03  <tjfontaine>god such inconsistent commit messages
23:28:49  * bnoordhuisjoined
23:29:05  * c4milojoined
23:29:20  <tjfontaine>isaacs: blah, we're going to need to re-test 5280, osx build slave was misbheaving
23:29:28  <isaacs>k
23:29:37  <tjfontaine> Error — Failing tests -- osx-ia32: 178, osx-x64: 179
23:29:39  <isaacs>well, it passes on os x on my machine :)
23:29:57  <tjfontaine>I mean, it was clearly a build problem it would have been green otherwise :)
23:30:54  <isaacs>k
23:33:52  * loladirojoined
23:34:21  * piscisaureus_joined
23:38:58  <bnoordhuis>back, sorry. had to clean up some kid vomit
23:39:05  <bnoordhuis>life of a parent eh?
23:39:26  <bnoordhuis>trevnorris: what was the question?
23:40:12  <trevnorris>um. my last was about adding the ability to call a js function from MakeWeakCallback (but far simpler than node-weak)
23:40:27  <trevnorris>(i seem to have a lot of questions, so it's hard to say =)
23:40:48  <trevnorris>bnoordhuis: oh, it was about buffer pools
23:41:02  <bnoordhuis>oh right, i see it in the logs now
23:41:34  <bnoordhuis>uhm, so what's the question exactly? :)
23:41:38  <isaacs>bnoordhuis: yikes.
23:43:43  <trevnorris>bnoordhuis: about how to segment the changes. e.g. the new pools are a lot faster, but doesn't solve my intended issue. so should I hold off or create a PR and work out the rest later?
23:44:22  <bnoordhuis>trevnorris: i'm generally in favor of atomic commits
23:44:39  <bnoordhuis>if this is an atomic change (and an improvement), by all means PR it
23:45:26  <trevnorris>ok. i'll PR the first round of changes w/ the plan to continue working on memory leak issue.
23:52:13  * dominictarrquit (Quit: dominictarr)
23:53:41  * piscisaureus_quit (Ping timeout: 248 seconds)
23:55:15  <indutny>evening guys :)
23:56:22  <isaacs>good evening, indutny
23:56:31  <indutny>isaacs: how are you doing?
23:56:42  <isaacs>indutny: pretty good
23:56:49  <isaacs>indutny: wanna review a streams change?
23:56:53  <indutny>sure