00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:05:50  * pachetquit (Ping timeout: 240 seconds)
00:11:46  <trevnorris>oy. I dislike 1) that github auto translates #<N> to a bug. and 2) users don't use code comments for their bugs which lead to a bunch of unnecessary links.
00:13:28  * pooyaquit (Ping timeout: 245 seconds)
00:13:35  * piscisaureus_joined
00:13:44  <trevnorris>piscisaureus_: GO TO BED!
00:13:44  * defunctzombie_zzchanged nick to defunctzombie
00:13:50  * piscisaureus_quit (Client Quit)
00:15:52  * amartensjoined
00:18:59  * pooyajoined
00:25:43  <trevnorris>tjfontaine: damn you. now that you're doing releases you've surpassed me in # of commits.
00:26:15  <othiym23>slacker
00:26:49  <trevnorris>hey, just 45 more and i'll have surpassed TooTallNate.
00:27:15  <trevnorris>though, no idea if anyone will pass dahl. dude was way commit happy.
00:31:12  * c4milojoined
00:31:58  * zz_karupanerurachanged nick to karupanerura
00:35:55  * bnoordhuisquit (Remote host closed the connection)
00:37:37  * jmar777joined
00:48:07  * indexzerojoined
00:51:05  <tjfontaine>trevnorris: number of commits is not a measure of anything, so don't worry
00:51:55  <trevnorris>tjfontaine: i know, but I totally kick your ass on LOC changed :P
00:53:32  <othiym23>FIGHT
00:53:34  <othiym23>FIGHT
00:53:52  <othiym23>man, where's LOUDBOT when you need it
00:53:53  <trevnorris>tjfontaine: i was triaging issues and got bored. amazing what can entertain you when doing something that dull.
00:54:01  * mikealquit (Quit: Leaving.)
00:54:02  <trevnorris>YOU NEED AT LEAST TWO WORDS
00:54:03  <LOUDBOT>QUENCH YOUR THIRST FOR BLOOD WITH NEW GOGURT DEMONSPAWN- IT'S EXTREEEEEEME
00:56:13  * sblomjoined
00:57:58  <othiym23>I'm holding tight at 2 commits on core
00:58:27  * c4miloquit (Remote host closed the connection)
00:58:31  <othiym23>don't want to spoil that record
00:58:36  <othiym23>could maybe go up to 3
00:58:41  <othiym23>3 is the magic number, after all
00:59:05  * jmar777quit (Remote host closed the connection)
00:59:25  <tjfontaine>trevnorris: kloc is also not a valid measure of anything
00:59:34  <tjfontaine>trevnorris: as evidenced by 2.5 weeks of work was a one line change
00:59:36  <tjfontaine>:)
00:59:43  * jmar777joined
00:59:54  * pooyaquit (Ping timeout: 240 seconds)
00:59:57  <trevnorris>haha, but people creating infographics don't realize that :P
01:01:04  * sblomquit (Ping timeout: 264 seconds)
01:03:44  * bnoordhuisjoined
01:03:50  * jmar777quit (Ping timeout: 240 seconds)
01:03:52  * pooyajoined
01:05:16  <othiym23>someday I will explain the fun times getting the New Relic for Node infographic ready for public consumption
01:05:24  <othiym23>groundwater_ helped with that a lot as well
01:05:31  <othiym23>infographics...
01:06:20  * skebcioquit (Quit: No Ping reply in 180 seconds.)
01:06:34  * octetcloudquit (Ping timeout: 240 seconds)
01:06:51  <groundwater_>node packaged modules!
01:07:05  <othiym23>if only that had been the worst of it
01:07:54  * bnoordhuisquit (Ping timeout: 240 seconds)
01:08:15  * skebciojoined
01:08:38  <othiym23>tjfontaine: what's the ETA on 0.11.9?
01:12:44  * trevnorris&
01:12:44  <LOUDBOT>MY SHITTING IS ASYNCHRONOUS AND EXTREMELY SCALABLE.
01:13:45  <tjfontaine>othiym23: hopefully soon
01:19:01  * jmar777joined
01:19:28  * bradleymeckjoined
01:19:36  <othiym23>http://zpao.com/posts/do-we-need-node/
01:19:42  <othiym23>the answer is in the question
01:19:45  <othiym23>of course not!
01:30:21  * pooyaquit (Ping timeout: 252 seconds)
01:31:50  * sblomjoined
01:32:35  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:33:13  * pooyajoined
01:44:28  * pooyaquit (Quit: pooya)
01:44:35  * indexzeroquit (Quit: indexzero)
01:48:47  * indexzerojoined
01:53:49  * TooTallNatejoined
01:58:44  * indexzeroquit (Quit: indexzero)
01:59:59  * sindresorhusquit (Ping timeout: 240 seconds)
02:00:19  * sindresorhusjoined
02:05:42  * brsonjoined
02:06:13  * brsonquit (Client Quit)
02:08:08  * inolenquit (Quit: Leaving.)
02:09:59  * TooTallNatequit (Ping timeout: 246 seconds)
02:10:37  * abraxasjoined
02:16:21  * brsonjoined
02:16:39  * TooTallNatejoined
02:20:31  <wolfeidau>tjfontaine: Could that memory leak have affected my stuff if i was opening and closing http connections 100/sec ?
02:20:40  * TooTallNatequit (Read error: Connection reset by peer)
02:21:02  * bradleymeckquit (Quit: bradleymeck)
02:21:20  * mikealjoined
02:21:37  <othiym23>wolfeidau: if I recall correctly, it was the onclose handler, so yes
02:21:46  <wolfeidau>woot!
02:22:29  <wolfeidau>Looking forward to checking this out with my tests on smartos
02:27:25  * mikealquit (Quit: Leaving.)
02:43:19  * sblomquit (Ping timeout: 240 seconds)
02:51:28  * TooTallNatejoined
03:19:30  * dshaw_joined
03:26:05  * brsonquit (Ping timeout: 272 seconds)
03:32:51  * dap_quit (Quit: Leaving.)
03:36:37  <tjfontaine>wolfeidau: I thought I had mentioned that to you, but yes I think it could indeed be very related, lemme look at your cores real quick
03:37:12  <wolfeidau>tjfontaine: that would be awesome I would love to know how you can see it
03:38:01  <tjfontaine>wolfeidau: if you have a core around, do `::umem_cache ! grep 4096`
03:38:26  <wolfeidau>tjfontaine: will do
03:41:33  <tjfontaine>wolfeidau: doesn't look like it
03:41:43  <wolfeidau>intersting
03:42:07  <tjfontaine>wolfeidau: doesn't look like it at first glance, I will look further
03:42:39  <wolfeidau>YOu will be happy to know I found most of the issues in the software i was debugging were bugs, lots of closures and silly anon functions all over the place
03:43:09  <wolfeidau>Memory use was everest now it is pretty much flat
03:43:55  <wolfeidau>mdb was invaluble in finding pretty much all the issues, especially once i started naming everything and watched a few v8 tuning presenations
03:44:40  <wolfeidau>tjfontaine: Many thanks for showing me that, I have managed to pass on the knowledge to a few people so far :)
03:45:25  <skabbes>mdb? can you put a link?
03:45:50  * Raynosquit (Ping timeout: 264 seconds)
03:46:23  <wolfeidau>skabbes: http://dtrace.org/blogs/dap/2011/10/31/nodejs-v8-postmortem-debugging/
03:46:53  <wolfeidau>skabbes: gcore and mdb are tools on smartos that open your eyes to some of the silly things we do in node :)
03:47:25  <skabbes>awesome, sounds like its time to go 100% smart os
03:47:35  <skabbes>i've spent too much time in node-webkit-agent
03:48:44  <wolfeidau>skabbes: yeah once you get the process nailed and a few recipes it is fantastic gives you hints which you can then chase down
03:49:06  <wolfeidau>Also shows you libs that ignore the recommendation of naming closures..
03:49:16  * Raynosjoined
03:49:34  <wolfeidau>I just forked them and tweaked for debugging
03:49:52  <skabbes>anything surprising about well known ones?
03:50:19  <wolfeidau>redis driver needs some love
03:50:46  <wolfeidau>but it does pool connections nicely :P
03:50:50  <skabbes>whoa - that's been one of the best driver's I've used
03:51:19  <skabbes>i guess you don't notice that when you're using an abysmal rabbit-mq driver
03:51:20  <wolfeidau>skabbes: It is a good driver, just uses generic terms for things that are shared by all drivers
03:51:40  <wolfeidau>skabbes: yeah I am using the new incarnation of rabbitmq driver
03:51:41  <skabbes>wolfeidau: ahhh, gotcha
03:51:46  <wolfeidau>Much better
03:52:03  <wolfeidau>When you see 3 versions of Connection and Session
03:52:25  <wolfeidau>You don't have a lot to work with as far as trackign down whos connection or Session :)
03:52:50  <skabbes>gotcha, that's annoying
03:54:50  <wolfeidau>skabbes: example here https://gist.github.com/wolfeidau/6710244#file-mdb-md
03:54:59  <wolfeidau>PacketHeader..
03:55:03  <wolfeidau>whos PacketHeader :)
03:55:12  <wolfeidau>RowDataPacket was a classic
03:55:22  <wolfeidau>Same name in both mysql driver and redis driver
03:56:23  <skabbes>so, to interpret that, you're leaking 2474 RowDataPacket objects?
03:56:30  <skabbes>or at least have that many activated
03:57:25  * skabbesquit (Quit: skabbes)
04:03:50  * inolenjoined
04:07:13  * hueniversequit (Quit: Leaving.)
04:09:36  * pooyajoined
04:12:38  * amartensquit (Quit: Leaving.)
04:23:46  * dshaw_quit (Quit: Leaving.)
04:25:38  * inolenquit (Quit: Leaving.)
04:41:32  * brsonjoined
04:59:43  * defunctzombiechanged nick to defunctzombie_zz
05:06:08  * TooTallNatequit (Quit: Computer has gone to sleep.)
05:11:39  * amartensjoined
05:13:16  * amartensquit (Read error: Connection reset by peer)
05:13:28  * amartensjoined
05:13:59  * jmar777quit (Remote host closed the connection)
05:15:56  * brsonquit (Ping timeout: 272 seconds)
05:23:15  * amartensquit (Ping timeout: 272 seconds)
05:41:10  * sblomjoined
05:45:03  * mikealjoined
05:45:26  * sblomquit (Ping timeout: 240 seconds)
05:49:07  * mikealquit (Client Quit)
05:49:34  * inolenjoined
06:08:20  * mikealjoined
06:13:04  * mikealquit (Ping timeout: 264 seconds)
06:14:52  * mikealjoined
06:19:46  * amartensjoined
06:21:18  * dshaw_joined
06:23:50  * amartensquit (Ping timeout: 240 seconds)
06:52:08  <MI6>nodejs-v0.10-windows: #318 UNSTABLE windows-ia32 (11/604) windows-x64 (10/604) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/318/
07:11:16  * inolenquit (Quit: Leaving.)
07:11:34  * inolenjoined
07:25:39  * felixgejoined
07:25:39  * felixgequit (Changing host)
07:25:39  * felixgejoined
07:35:53  * brsonjoined
07:48:04  * amartensjoined
07:52:29  * inolenquit (Quit: Leaving.)
07:52:43  * amartensquit (Ping timeout: 272 seconds)
07:52:44  * inolenjoined
07:53:27  * brsonquit (Ping timeout: 246 seconds)
08:16:11  * hueniversejoined
08:17:49  * brsonjoined
08:23:43  * rendarjoined
08:24:36  * hzjoined
08:29:07  * inolenquit (Quit: Leaving.)
08:36:51  * pooyaquit (Quit: pooya)
08:41:01  * pooyajoined
08:42:21  * pooyaquit (Client Quit)
08:49:36  * saghuljoined
08:52:04  * dshaw_quit (Ping timeout: 264 seconds)
08:55:29  * dshaw_joined
09:06:11  * deltalucajoined
09:23:36  * dshaw_quit (Quit: Leaving.)
09:23:49  * indexzerojoined
09:53:02  * karupanerurachanged nick to zz_karupanerura
09:54:31  * dshaw_joined
09:59:23  * dshaw_quit (Ping timeout: 272 seconds)
10:06:35  * dsantiagoquit (Quit: Leaving...)
10:12:03  * indutnyquit (Quit: IRCRelay - http://ircrelay.com)
10:37:04  * zz_karupanerurachanged nick to karupanerura
10:38:17  * karupanerurachanged nick to zz_karupanerura
10:47:41  * abraxasquit (Remote host closed the connection)
10:49:40  <MI6>nodejs-v0.10: #1597 UNSTABLE smartos-x64 (5/604) smartos-ia32 (4/604) osx-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1597/
10:50:33  * dshaw_joined
10:55:23  * dshaw_quit (Ping timeout: 272 seconds)
11:05:10  * indutnyjoined
11:08:47  * bnoordhuisjoined
11:21:38  <MI6>joyent/libuv: bnoordhuis created branch unbreak-bsds - http://git.io/4-BBIg
11:23:45  <bnoordhuis>indutny: ^
11:24:13  <indutny>bnoordhuis: huh?
11:24:21  <indutny>oooh
11:24:25  <indutny>we've other bsds
11:24:44  <indutny>bnoordhuis: LGTM, if you're asking :)
11:26:18  <bnoordhuis>i kind of sad yesterday's release is broken on the bsds
11:26:21  <bnoordhuis>*i'm
11:27:21  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 026241c : unix: unbreak bsd build after bbccafb - http://git.io/UDxkPQ
11:28:40  <bnoordhuis>it would be nice to have that freebsd bot back
11:28:58  <bnoordhuis>indutny: btw, why did you put it in darwin.c in the first place?
11:30:59  * indexzeroquit (Quit: indexzero)
11:31:02  <indutny>bnoordhuis: well, I thought that platform code should be there
11:31:14  <indutny>bnoordhuis: we really need bsd.c
11:32:17  <indutny>bnoordhuis: what do you think about it?
11:33:12  <bnoordhuis>meh. the stuff in kqueue.c is not really bsd specific unless you count os x as a bsd (which i don't)
11:37:48  <indutny>:)
11:37:51  <indutny>well
11:37:56  <indutny>platform_ things are bsd
11:38:00  <indutny>but yeah
11:38:06  <indutny>perhaps, you're right
11:38:12  <indutny>bnoordhuis: sorry for not thinking about it
11:38:27  <indutny>I don't really test libuv on bsds often
11:41:22  <rendar>there are many differences between bsd and darwin?
11:43:28  * brsonquit (Ping timeout: 245 seconds)
11:45:46  * piscisaureus_joined
11:51:14  * dshaw_joined
11:54:28  * saghulquit (Ping timeout: 264 seconds)
11:55:39  * dshaw_quit (Ping timeout: 246 seconds)
12:02:08  * dsantiagojoined
12:03:20  <indutny>rendar: hell yeah :)
12:03:43  <rendar>:)
12:03:54  <rendar>indutny, but specific of kqueue or in general?
12:04:01  <indutny>in general
12:04:13  <indutny>and kqueue too
12:05:31  <rendar>why everything must be so hard! :(
12:09:30  <indutny>well
12:09:42  <indutny>that's what you get if you keep mach things and implement BSD APIs on top of it
12:09:53  <rendar>lol, yeah
12:09:57  <rendar>i agree
12:10:03  <rendar>what about mcac
12:10:07  <rendar>ops..sorry
12:10:19  <rendar>what about apple choosen linux for macosx ?
12:12:01  <indutny>linux?
12:12:08  <indutny>I don't think its possible
12:12:16  <indutny>considering all recent iOS integrations and everything
12:12:29  <indutny>well, its possible, but highly unlikable
12:12:32  <indutny>unlikely*
12:12:32  <rendar>no i mean, instead of choosing mach+bsd in the early stage, they choosen linux
12:12:33  <rendar>:)
12:12:33  <indutny>hehe
12:12:48  * Kakerajoined
12:12:50  <indutny>oh well
12:13:07  <rendar>i'm speaking about that possibility, but in the past..now of course its too late :)
12:13:14  <indutny>initial release was 29 years ago
12:13:24  <indutny>not sure when they adopted BSD stuff
12:13:47  <rendar>initial release of macosx? you mean that rapshody thing?
12:14:19  <indutny>oh yeah
12:14:24  <indutny>well, it wasn't really BSD at the time
12:14:36  <rendar>yep, just unix
12:14:36  <rendar>:)
12:15:02  <indutny>bnoordhuis: what's your final word on this https://github.com/joyent/libuv/pull/981/files ?
12:15:21  <rendar>i think it was the OS when steve jobs presented the nextstep computer, that cube where tim berners lee wrote the first http server
12:22:13  <indutny>hehe
12:22:20  <indutny>yeah, I think so too
12:23:04  * saghuljoined
12:25:50  <bnoordhuis>indutny: have you actually tested it this time?
12:26:13  <bnoordhuis>that -UV_EMFILE thing was, well...
12:28:47  <indutny>bnoordhuis: yes
12:28:50  <indutny>oohhhh
12:28:51  <indutny>Assertion failed: (handle_->Get(String::New("error"))->BooleanValue() == false), function ClearError, file ../src/node_crypto.cc, line 982.
12:28:53  <indutny>wtf
12:28:59  <indutny>I think I found a tls bug in v0.10
12:33:22  <indutny>haha
12:33:26  <indutny>I knew no-one expected it there
12:33:39  * piscisaureus_quit (Ping timeout: 252 seconds)
12:34:42  <indutny>I have a fix
12:34:46  <indutny>writing test
12:36:07  * brsonjoined
12:37:23  * piscisaureus_joined
12:52:01  * dshaw_joined
12:53:09  <MI6>joyent/libuv: Ben Noordhuis master * 17711b9 : Merge remote-tracking branch 'origin/v0.10' (+3 more commits) - http://git.io/4nK1uA
12:56:52  * dshaw_quit (Ping timeout: 264 seconds)
12:59:05  <indutny>bnoordhuis: yt?
12:59:22  <indutny>bnoordhuis: https://gist.github.com/indutny/9e082ee7aee5957b75ab quick patch for node v0.10
12:59:48  <piscisaureus_>http://logs.libuv.org/uptime
13:01:18  <MI6>joyent/libuv: Ben Noordhuis master * c2c92fa : build: add test-tcp-close-accept.c to test deps - http://git.io/Im0kiw
13:01:29  <bnoordhuis>indutny: no time, sorry. back in ~2 hours
13:01:35  <indutny>ok
13:01:35  <indutny>np
13:01:49  <indutny>piscisaureus_: mind reviewing that patch?
13:01:53  <indutny>its really simple
13:02:03  <piscisaureus_>which?
13:03:36  <indutny>piscisaureus_: https://gist.github.com/indutny/9e082ee7aee5957b75ab
13:03:59  <piscisaureus_>indutny: well in all honesty i know very little about the tls bindings
13:04:05  <indutny>oh gosh
13:04:06  <indutny>ok
13:04:06  <indutny>:)
13:04:07  <piscisaureus_>indutny: your test case looks good tho
13:04:21  <indutny>well, we're handling this error same way in many places of that file
13:04:22  <indutny>lib/tls.js
13:04:23  <piscisaureus_>indutny: so if it fixes that and introduces no regressions then you can haz my thumbsup
13:04:29  <indutny>great
13:04:32  <indutny>I'll run tests and push it
13:04:33  <indutny>thank you
13:04:47  <piscisaureus_>good
13:04:49  <piscisaureus_>+1
13:05:55  * bnoordhuisquit (Ping timeout: 252 seconds)
13:09:32  <MI6>joyent/node: Fedor Indutny v0.10 * 65b1275 : tls: handle `ssl.start()` errors - http://git.io/LU3yZw
13:09:33  <indutny>tadam
13:20:55  <MI6>nodejs-v0.10: #1598 UNSTABLE smartos-x64 (6/604) smartos-ia32 (4/604) linux-x64 (1/604) linux-ia32 (1/604) osx-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-v0.10/1598/
13:22:06  * stagasjoined
13:24:25  * piscisaureus_quit (Ping timeout: 246 seconds)
13:36:21  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
13:38:22  * piscisaureus_joined
13:51:40  * piscisaureus_quit (Ping timeout: 245 seconds)
13:52:47  * dshaw_joined
13:56:07  * bnoordhuisjoined
13:57:25  * dshaw_quit (Ping timeout: 248 seconds)
14:00:45  * jmar777joined
14:02:12  * saghuljoined
14:03:37  <indutny>bnoordhuis: so you're back
14:03:41  <indutny>bnoordhuis: lets merge that test
14:11:23  <bnoordhuis>indutny: two nits. if you fix those up then lgtm
14:11:29  <indutny>thanks
14:11:58  <indutny>bnoordhuis: "You're evaluating num twice here."
14:12:03  <indutny>bnoordhuis: want me to move to one line?
14:12:06  <indutny>a = b = (num) ?
14:12:08  <indutny>or
14:12:10  <indutny>a = (num)
14:12:12  <indutny>b = a
14:12:34  * hzquit
14:12:50  * piscisaureus_joined
14:16:13  * brsonquit (Ping timeout: 246 seconds)
14:17:05  * piscisaureus_quit (Ping timeout: 245 seconds)
14:19:11  <MI6>joyent/libuv: Fedor Indutny master * 86b5c1e : test: test fsevents error reporting - http://git.io/cr9ElA
14:22:38  <indutny>bnoordhuis: thank you
14:28:53  * bnoordhuisquit (Ping timeout: 248 seconds)
14:32:08  * bnoordhuisjoined
14:34:13  * kevinswiberjoined
14:37:26  * kevinswiberquit (Read error: Connection reset by peer)
14:37:46  * kevinswiberjoined
14:53:28  * dshaw_joined
14:57:52  * dshaw_quit (Ping timeout: 246 seconds)
15:00:03  * defunctzombie_zzchanged nick to defunctzombie
15:06:17  * pachetjoined
15:06:18  * pachetquit (Changing host)
15:06:18  * pachetjoined
15:17:55  <bnoordhuis>cloning chromium is a great way to exercise one's patience
15:18:19  <rendar>bnoordhuis, eheh, i agree :) why are you cloning that?
15:18:22  <bnoordhuis>never mind building it...
15:18:31  <bnoordhuis>to fix google's bugs
15:18:56  <rendar>so it will be a long day
15:18:57  <rendar>:)
15:19:03  <bnoordhuis>i want to get a patch into v8 that makes it use CLOCK_REALTIME_COARSE and CLOCK_MONOTONIC_COARSE when available
15:19:23  <bnoordhuis>and i did - but it got reverted because chromium's seccomp2 sandbox filters the syscalls >:-(
15:19:37  <rendar>oh yeah for that linux bug we discussed the other day? of the vlso memory shared..
15:19:45  <bnoordhuis>yep, that's the one
15:19:54  <rendar>oh
15:20:05  <rendar>it filters all the syscall called by chromium?
15:20:17  <bnoordhuis>yeah, except what's whitelisted
15:20:30  <bnoordhuis>and the whitelist is pretty restrictive
15:20:38  <rendar>hmm
15:20:51  <MI6>nodejs-master: #697 UNSTABLE smartos-ia32 (5/675) smartos-x64 (8/675) http://jenkins.nodejs.org/job/nodejs-master/697/
15:21:01  <bnoordhuis>this v8 patch... man
15:21:13  <bnoordhuis>first they landed my patch but with "fixups" that actually broke it
15:21:29  <rendar>lol..
15:21:30  <bnoordhuis>then it turns out chromium's sandbox is broken...
15:21:36  <bnoordhuis>one thing after another
15:22:04  <rendar>but how the sandbox can watch all the syscalls called? it just puts a system level hook like a sort of rootkit?
15:22:20  <bnoordhuis>pretty much. seccomp2 is itself a syscall of a sorts
15:22:46  <bnoordhuis>once the filter is installed, all system calls are checked
15:23:03  <bnoordhuis>when the filter rejects one, bam, the process gets killed
15:23:27  <bnoordhuis>that filter is a kind of bpf bytecode that's executed in kernel space
15:23:34  <bnoordhuis>bpf = berkely packet filter
15:23:57  <bnoordhuis>only here it doesn't filter network packets but syscall arguments
15:24:12  <bnoordhuis>so now you know :)
15:26:24  <rendar>eheh
15:27:26  <rendar>yeah i remember the bpf, basically that that libpcap uses
15:27:31  <rendar>what*
15:29:05  <rendar>bnoordhuis, so for executing that bytecode in the kernel space, a driver is needed..but chromium install a driver for that seccomp2?!
15:30:12  <bnoordhuis>rendar: it does
15:30:41  <bnoordhuis>it's not a bad thing but it's kind of annoying that i have to do a lot of extra work now to get a simple patch landed in v8
15:32:55  <rendar>i see
15:33:48  * kevinswiberquit (Read error: Connection reset by peer)
15:34:18  * kevinswiberjoined
15:35:29  * bnoordhu1sjoined
15:36:37  * felixgequit (Quit: felixge)
15:39:49  * bnoordhu1squit (Ping timeout: 248 seconds)
15:44:36  * c4milojoined
15:53:02  * inolenjoined
15:54:17  * dshaw_joined
15:58:56  * dshaw_quit (Ping timeout: 244 seconds)
16:05:19  * mikealquit (Quit: Leaving.)
16:06:09  * AvianFlujoined
16:07:48  * AvianFlu_joined
16:10:33  * AvianFluquit (Ping timeout: 245 seconds)
16:13:57  * piscisaureus_joined
16:20:29  <indutny>shit
16:20:33  <indutny>GCD is fucking kidding with me
16:22:15  <rendar>gcd?
16:26:30  <indutny>Grand Central Dispatch
16:26:32  <indutny>but nvm
16:26:34  <indutny>I figured it out
16:26:42  <indutny>it was because of the shared buffer...
16:27:26  <rendar>oh that macosx
16:28:51  * felixgejoined
16:28:51  * felixgequit (Changing host)
16:28:51  * felixgejoined
16:35:56  * AvianFlu_changed nick to AvianFlu
16:36:20  <piscisaureus_>https://twitter.com/search?q=libuv&src=typd
16:36:30  <piscisaureus_>lots of japanese swearing about libuv
16:44:45  <hueniverse>tjfontaine: any idea if the smartos dist was posted?
16:50:04  * abraxasjoined
16:55:04  * abraxasquit (Ping timeout: 264 seconds)
16:55:27  * dshaw_joined
16:59:50  * dshaw_quit (Ping timeout: 240 seconds)
17:03:31  * hueniversequit (Quit: Leaving.)
17:07:02  * kevinswiberquit (Remote host closed the connection)
17:07:38  * kevinswiberjoined
17:11:55  * kevinswiberquit (Ping timeout: 246 seconds)
17:13:20  * inolenquit (Quit: Leaving.)
17:16:26  * wolfeidauquit (Ping timeout: 244 seconds)
17:17:28  * indexzerojoined
17:17:32  * wolfeidaujoined
17:17:39  * mikealjoined
17:19:34  * amartensjoined
17:22:48  <trevnorris>morning
17:25:02  <trevnorris>piscisaureus_: you. me. we need to talk.
17:25:23  <trevnorris>isaacs: i'll need your feedback on https://github.com/joyent/node/pull/6502
17:25:31  <trevnorris>isaacs: it's not complete yet, but the general idea is there.
17:27:12  * dap_joined
17:28:32  * dshaw_joined
17:30:55  * mikealquit (Quit: Leaving.)
17:31:47  * jmar777quit
17:34:32  <trevnorris>tjfontaine: there going to be a v0.11 release by the end of the week?
17:38:03  * dap_1joined
17:38:52  * deltalucaquit (Ping timeout: 264 seconds)
17:38:53  * dap_quit (Ping timeout: 245 seconds)
17:44:14  <trevnorris>bnoordhuis: i'm trying to figure out why read(2) would return a ssize_t. any reason it'd return < 0 ?
17:45:29  <tjfontaine>errors
17:45:39  <tjfontaine>and yes, there should be a v0.11 by EOW
17:45:48  <trevnorris>tjfontaine: cool, thanks :)
17:46:33  <tjfontaine>fwiw: `man 2 read`
17:46:34  <tjfontaine>RETURN VALUES
17:46:34  <tjfontaine> If successful, the number of bytes actually read is returned. Upon reading end-of-file, zero is returned. Otherwise, a -1 is returned and the global variable errno is set to
17:46:34  <LOUDBOT>I DON'T THINK I'VE EVER BEEN SO CERTAIN ABOUT ANYTHING IN MY ENTIRE LIFE
17:46:37  <tjfontaine> indicate the error
17:47:16  <trevnorris>tjfontaine: suck. missed that line. thanks.
17:47:24  <tjfontaine>no problemo
17:48:45  <trevnorris>heh, too bad i'm just getting how this crap works. return -1, please check errno.
17:49:18  <trevnorris>had in my mind how uv does it. returns a -N which directly correlates to the error.
17:49:32  <tjfontaine>uv worked the errno way previously
17:49:48  <trevnorris>did that change to be thread safe?
17:50:19  <tjfontaine>it changed to support multiple loops more effectively, so yes in a way
17:50:25  <trevnorris>ah, ok.
17:54:53  * st_lukejoined
18:03:09  <tjfontaine>in the past 31 days we've had 1 million downloads for source
18:03:19  <tjfontaine>of those 1 million, sorted by userAgent
18:03:28  <tjfontaine> 60026 source node-gyp v0.10.10 (node v0.10.20)
18:03:28  <tjfontaine> 150264 source node-gyp v0.10.10 (node v0.10.21)
18:03:29  <tjfontaine> 530523 source -
18:03:45  <rendar>1M of downloads of the node.js srcs?
18:03:55  <tjfontaine>yes
18:03:58  <rendar>awesome
18:04:13  <rendar>1M/1month is awesome :)
18:08:49  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:09:01  * octetcloudjoined
18:09:06  * octetcloudquit (Client Quit)
18:10:05  <tjfontaine>530K have no user agent, 230K are node-gyp, 160K are Check or Homebrew
18:10:09  * TooTallNatejoined
18:10:18  <tjfontaine>TooTallNate: THANK YOU FOR USER AGENT IN NODE-GYP
18:10:35  <TooTallNate>tjfontaine: :)
18:10:42  <TooTallNate>tjfontaine: you got some interesting data at this point?
18:10:45  <trevnorris>TooTallNate: do you remember the technique bnoordhuis mentioned how to wrap around, say, a uint16?
18:10:46  <tjfontaine>TooTallNate: in the past 31 days we've had 1M downloads for source, of those 230K were identified as node-gyp, 530K were no userAgent
18:11:19  <trevnorris>tjfontaine: do you have the raw log data for those requests?
18:11:55  <TooTallNate>trevnorris: https://github.com/TooTallNate/node-buffer-dataview/blob/master/dataview.js#L190-L191
18:12:13  <rendar>tjfontaine, aren't git clone counted there?
18:12:29  <trevnorris>TooTallNate: awesome. thanks :)
18:14:48  <tjfontaine>trevnorris: I can get some for you
18:15:03  <tjfontaine>trevnorris: I was just running some manta jobs to update my slides
18:15:09  <trevnorris>tjfontaine: yeah, i'd be interested in seeing a random sample of 100 or the like.
18:15:09  <tjfontaine>trevnorris: so most of its in my history
18:15:24  <tjfontaine>wanna see a pretty picture?
18:15:39  <tjfontaine>http://us-east.manta.joyent.com/NodeCore/public/reports/version-downloads-by-date.html?branch=v0.1
18:17:44  <trevnorris>tjfontaine: nice.
18:19:17  <trevnorris>tjfontaine: can you drop the smoothing and show a second line that shows weekly averages centered on current day?
18:19:46  <trevnorris>(sorry, old data visualization habits came rushing back :)
18:19:49  <tjfontaine>as far as raw data you can see http://us-east.manta.joyent.com/NodeCore/public/reports/v0.10-downloads-by-date.txt
18:19:52  <tjfontaine>and
18:19:55  <trevnorris>awesome sauce
18:20:02  <tjfontaine>http://us-east.manta.joyent.com/NodeCore/public/reports/v0.1-downloads-by-date.txt
18:20:09  <tjfontaine>the d3 page just uses those
18:21:32  <trevnorris>coolio. and do you have some of the raw logs? i'd like to see what a random sample of the the header requests look like. just curious.
18:22:05  <trevnorris>tjfontaine: those are pretty cool.
18:22:15  <tjfontaine>they're all in manta, we can talk about that when I get back from the talk
18:22:23  <trevnorris>tjfontaine: if I could get more specific information I could do a time series map sort of like this: http://people.mozilla.org/~tnorris/senate/
18:22:51  <tjfontaine>the job looks like
18:22:53  <tjfontaine>mfind ~~/stor/nginx/access_log | mjob create -ow -s /NodeCore/public/reports/scripts/apache.js -m 'node /assets/NodeCore/public/reports/scripts/apache.js date nodeVersion | grep -v latest | sed -E "s#(v0\.[0-9]+)\.([0-9]+)#\1#"' -s /NodeCore/public/reports/scripts/aggr.js -r 'sort | uniq -c | node /assets/NodeCore/public/reports/scripts/aggr.js | head -n -1 mpipe /NodeCore/public/reports/v0.1-downloads-by-date.txt'
18:23:13  <tjfontaine>trevnorris: I'm not sure how much of that information I want to provide though
18:23:40  <tjfontaine>trevnorris: making graphs to produce for people is one thing, but what raw logs we provide externally needs care
18:23:48  <tjfontaine>anyway bbl
18:23:55  <trevnorris>cool.
18:24:43  <trevnorris>tjfontaine: and had no intention of making raw logs available. more I'm curious what the header requests look like for those w/o a user agent.
18:25:57  * stagasquit (Read error: Connection reset by peer)
18:27:28  <trevnorris>can someone remind me why the Buffer#write{U}Int* methods don't just wrap around values?
18:27:36  <trevnorris>that seems sort of dumb in retrospect.
18:29:17  * bnoordhuisquit (Quit: leaving)
18:29:57  * octetcloudjoined
18:30:15  * bnoordhuisjoined
18:34:40  * indexzeroquit (Ping timeout: 264 seconds)
18:35:27  * sblomjoined
18:36:10  * piscisaureus_joined
18:36:15  <piscisaureus_>trevnorris: about what?
18:36:56  <trevnorris>piscisaureus_: about my EE PR, what you need for tasks, and what else you're missing from AsyncListeners as well.
18:37:24  * indexzerojoined
18:37:33  <piscisaureus_>trevnorris: let me write down how tasks works internally. I bet that'd be useful for octetcloud too
18:37:36  * dshaw_quit (Quit: Leaving.)
18:37:40  * kevinswiberjoined
18:38:10  <trevnorris>piscisaureus_: thanks. I want this to be what you need for tasks, and would at least like to have the API hammered down before the v0.12 release.
18:38:31  <trevnorris>piscisaureus_: dreamed about them last night and think I might have come up w/ a way to improve performance.
18:38:32  <piscisaureus_>Well then I should get going
18:38:36  * c4miloquit (Remote host closed the connection)
18:38:39  <piscisaureus_>oh scary :)
18:38:54  * inolenjoined
18:40:29  <trevnorris>heh, yeah. i'm sure othiym23 and groundwater_ are going to love me. :P
18:41:01  <groundwater_>trevnorris: yay!
18:41:14  <groundwater_>will the EE fix let you remove domains?
18:42:25  * m76joined
18:42:32  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:42:42  <trevnorris>groundwater_: from EE yes. we still have to keep some of it around in timers because they are one of the few things that don't inherit from EE.
18:43:06  <trevnorris>oh wait. nm. there's a way to get around that.
18:43:23  <trevnorris>duh. I already created an api for that reason. wtf. why didn't I remove those :P
18:44:00  * mikealjoined
18:50:36  * dshaw_joined
18:51:21  * abraxasjoined
18:55:45  * abraxasquit (Ping timeout: 240 seconds)
18:57:50  * TooTallNatejoined
18:58:17  <piscisaureus_>trevnorris: btw - I don't think that I will be able to do domains2 without any monkey patching at all at this point. But I'll be happy if I can do it with.
18:59:26  <trevnorris>piscisaureus_: ok, well you just get me that spec and I'll worry about how much can be placed into core. :)
18:59:43  <trevnorris>piscisaureus_: and what we can't get into v0.12 we'll leave on the table during v0.13 development.
19:22:09  <trevnorris>heh, it's sort of sad. I hope no one is using Buffer#toJSON() to actually transmit their buffers. that's going to be so ridiculously slow.
19:27:43  <piscisaureus_>trevnorris: https://gist.github.com/piscisaureus/7454729
19:27:54  <trevnorris>piscisaureus_: thanks.
19:28:00  <piscisaureus_>trevnorris: for a start... I'm sure this will leave you with many questions
19:33:23  <trevnorris>piscisaureus_: imo to make this work as reliably as possible I'd suggest turning each EventEmitter instance within a task to a weak persistent. it's the only sure way to guarantee the EE has been destroyed.
19:34:04  <piscisaureus_>trevnorris: no no we can't do that
19:34:32  <piscisaureus_>trevnorris: we'd start relying on gc timings. Also what if node is 'waiting' for a EE to go away?
19:34:46  <piscisaureus_>trevnorris: ... but v8 doesn't feel inclined to do a gc at the same time? It'd hang
19:34:55  <piscisaureus_>trevnorris: so it has to be reference counted
19:35:22  <piscisaureus_>trevnorris: so I understand that I've now given you the impossible task of coming up with generic hooks that make this possible :)
19:35:56  <trevnorris>piscisaureus_: overall I think it's self torture to make these work w/ EEs.
19:35:58  <piscisaureus_>trevnorris: therefore it's probably better for me to just monkey patch the EE - which will work BUT I'd have to be able to monkey patch the constructor
19:36:04  <piscisaureus_>trevnorris: true
19:36:18  <trevnorris>piscisaureus_: excluding EEs, id' be ablet to make this work for you.
19:36:59  <piscisaureus_>trevnorris: that's cool! So this is why I need to know if a HandlWrap callback is 'final' or not
19:37:26  <piscisaureus_>trevnorris: ... and why I need clearTimeout/clearInterval "hooks"
19:37:28  <trevnorris>a set of timers exists on a given TimerWrap. so it'll be easy to deterministically know when a set of timers has been cleaned up. and I could easily add an "AsyncGroup" idea that, when active, creates a double linked list of all instantiated classes.
19:38:11  <piscisaureus_>trevnorris: since TimerWraps are tucked away so deeply inside node code I don't need much from that
19:38:35  <piscisaureus_>trevnorris: but what I need is for Timout objects (e.g. the userland wrapper) to know when it starts and ends
19:39:01  * bradleymeckjoined
19:39:08  <piscisaureus_>trevnorris: actually TimerWrap objects must not end up in a task (so I had to to do some hacking there too)
19:39:12  <trevnorris>piscisaureus_: the hooks are already there for clear{Timeout,Interval}, for some reason each instantiate a new Timer object which calls the async listener.
19:39:29  <trevnorris>piscisaureus_: what you'd need to know is _what_ it is that's being called.
19:40:07  <trevnorris>piscisaureus_: but I could allow you to receive pre-existing storage values then you'd be able to track when something has completed.
19:40:21  <piscisaureus_>trevnorris: I don't like hooks that require me to do this type of filtering, but I think for practical reasons I need it now indeed
19:40:57  <trevnorris>well, right now it's all or nothing. i've considered being able to pass flags that allow internal filtering of what objects you want the async listener to fire on.
19:41:14  <trevnorris>and I like the idea. just haven't figured out exactly how yet.
19:41:50  <piscisaureus_>trevnorris: actually my current implementation just creates one global async listener
19:41:56  <piscisaureus_>trevnorris: so far it seems to suffice
19:42:14  <piscisaureus_>trevnorris: but I am monkey patching timers.js code to make sure TimerWrap doesn't end up in the task
19:42:47  <piscisaureus_>(timer.js is one of these 'pooling' scenarios where tasks don't transparently just work unfortunately. Http client agent is the other one that occurs in node code)
19:43:36  * indexzeroquit (Quit: indexzero)
19:43:56  <trevnorris>piscisaureus_: fwiw there's a hidden API where set{Timeout,Interval,Immediate} instances have an #addAsyncListener API.
19:44:13  <trevnorris>piscisaureus_: I had to add it to support domain compatibility.
19:44:29  <trevnorris>it's also there for TCPWrap handles (or maybe it's HandleWrap)
19:44:51  <piscisaureus_>trevnorris: what I don't understand is why that is needed though
19:44:53  <trevnorris>i only added it where it was absolutely necessary. but we can play with that if it'd be useful.
19:45:04  <piscisaureus_>trevnorris: can domains not just use one global async listener?
19:45:23  <trevnorris>piscisaureus_: you forget the domain method add(), where you can pass an event emitter.
19:45:47  <trevnorris>and in the case of the net module, the TCP/PipeWrap isn't instantiated until .listen() is called
19:45:54  <piscisaureus_>trevnorris: so couldn't we do Domain.prototype.add = function(x) { x.domain = this }
19:46:26  <trevnorris>piscisaureus_: we still do. but domain attributes are no longer recognized by core.
19:46:37  <trevnorris>all that stuff is just backwards compatibility.
19:46:52  <piscisaureus_>trevnorris: so we'd look at the .domain property in the async listener callback?
19:47:06  <piscisaureus_>Ah crap they're throwing me out of the starbucks
19:47:13  <trevnorris>haha
19:47:21  <piscisaureus_>trevnorris: any final works before I go?
19:47:37  <trevnorris>yeah. but I have to post a code snippet. one sec.
19:48:00  <trevnorris>piscisaureus_: https://github.com/joyent/node/blob/master/lib/_http_client.js#L454-L459
19:48:26  <piscisaureus_>I see
19:48:43  <trevnorris>it's because of EEs abstraction
19:48:43  <piscisaureus_>but instead
19:48:49  <trevnorris>that makes it all a PITA
19:48:51  <piscisaureus_>socket._handle.domain = req.domain ?
19:48:54  <piscisaureus_>ok have to go
19:48:57  <trevnorris>ok.
19:49:08  <piscisaureus_>at broompoint
19:49:14  <trevnorris>haha
19:49:42  <piscisaureus_>I've overstayed my time for 50 minutes
19:53:29  <trevnorris>order another coffee
19:54:43  * piscisaureus_quit (Ping timeout: 272 seconds)
19:55:24  * dshaw_quit (Quit: Leaving.)
19:56:40  * indexzerojoined
20:01:26  * dshaw_joined
20:03:25  * indexzeroquit (Quit: indexzero)
20:08:15  <trevnorris>buf.write() - Returns number of octets written.
20:08:32  <trevnorris>Buffer(3).write('\u0222\u0222') == 2
20:08:37  <trevnorris>oy
20:09:26  <trevnorris>oh, wait. nm.
20:09:53  <trevnorris>the incredible amount of argument parsing in Buffer#write() is so confusing.
20:10:28  * mikealquit (Quit: Leaving.)
20:24:40  * kevinswiberquit (Remote host closed the connection)
20:25:52  * kevinswiberjoined
20:27:39  * c4milojoined
20:32:21  * c4miloquit (Ping timeout: 272 seconds)
20:32:53  * dshaw_quit (Quit: Leaving.)
20:38:28  <indutny>gosh
20:38:32  <indutny>what a stupid unconfigurable
20:38:39  <indutny>http.Server.httpAllowHalfOpen
20:38:43  <indutny>it ends socket...
20:38:56  <indutny>even if it is allowed
20:38:59  <indutny>who did that?
20:39:26  <indutny>https://github.com/joyent/node/blob/master/lib/_http_server.js#L414
20:39:30  <indutny>isaacs: ^^
20:40:38  <indutny>oh
20:40:48  <indutny>perhaps, that's not exactly what I'm experiencing
20:40:53  <indutny>sorry for blaming you
20:50:21  * dshaw_joined
20:50:48  * c4milojoined
20:51:31  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:54:49  * kellabytequit (Quit: Quit)
20:58:29  <indutny>oh gosh
20:58:34  <indutny>you won't believe me what was that :)
20:59:12  <bnoordhuis>the suspense is killing me, fedor!
20:59:35  * kellabytejoined
21:00:27  * st_lukequit (Remote host closed the connection)
21:01:44  <trevnorris>bnoordhuis: someone just asked me about how shmat is exposed in node. i'm not completely sure how to respond.
21:01:59  <indutny>bnoordhuis: haha
21:02:26  <indutny>bnoordhuis: you know 'connection' event handler, right?
21:02:33  <indutny>bnoordhuis: its receiving http.Server as this
21:02:40  <indutny>bnoordhuis: and spdy is sending spdy.Connection as this
21:02:50  <indutny>this is quite a clever hack that I forgot about
21:03:01  <bnoordhuis>trevnorris: slap him repeatedly in the face with the palm of your hand while saying 'no no no'
21:03:11  * c4milo_joined
21:03:19  <trevnorris>hahaha.
21:03:25  <indutny>SHM_....
21:03:37  <bnoordhuis>indutny: ah okay
21:05:06  <trevnorris>indutny: SHM_ ?
21:06:13  * c4miloquit (Ping timeout: 248 seconds)
21:06:27  * indexzerojoined
21:07:36  * indexzeroquit (Client Quit)
21:08:02  <bnoordhuis>fedor's probably thinking of shm_open but shmat is spelled shmat
21:09:22  * mikealjoined
21:11:09  <trevnorris>ok, man. I haven't looked at buffer.js since before the util.is* stuff.
21:11:11  <trevnorris>man that's ugly.
21:13:55  * kevinswi_joined
21:14:16  * kevinswiberquit (Ping timeout: 264 seconds)
21:16:29  * indexzerojoined
21:16:39  <trevnorris>freak I hate dynamic parameters, or whatever the proper term is. e.g. Buffer([number][string])
21:16:39  <trevnorris>but would I expect new Buffer('0xFF') to be interpreted as a number or a string?
21:16:46  <trevnorris>anyone?
21:17:11  <bnoordhuis>string
21:18:14  <trevnorris>yeah. just hate number/string type coercion when both types are allowed. so i'm bitching about it. :P
21:18:44  * dshaw_quit (Quit: Leaving.)
21:18:46  <trevnorris>I have some buffer fixes just about ready. couple things that were overlooked
21:20:21  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:21:25  <trevnorris>mother effin. why do we allow case insensitive encodings in crap like Buffer#write(), but not in Buffer.byteLength()
21:21:28  <trevnorris>so inconsistent.
21:22:00  * trevnorrisjust realizes he forgot his happiness pills. *wanders off*
21:23:33  <trevnorris>bnoordhuis: so anyways. what you been working on?
21:23:41  * saghuljoined
21:24:02  * indexzeroquit (Read error: Connection timed out)
21:24:14  * dshaw_joined
21:26:15  <bnoordhuis>trevnorris: today? gc profiling stuff that i really should finish up
21:26:35  <bnoordhuis>trevnorris: oh, and i'm wrapping up deprecating the debugger. you can be the first to review it!
21:26:42  <trevnorris>FREAK YEAH!
21:26:42  <LOUDBOT>THAT WAS LIKE AESOP'S FABLES FOR FAGGOTS
21:27:56  <trevnorris>now if I can just figure out why Buffer's base64 encoding can't give me the correct length, i'd be really happy
21:28:38  <bnoordhuis>trevnorris: correct length for what input?
21:29:17  <trevnorris>bnoordhuis: in the Buffer() constructor if the input is a string it then does this.length = this.write(...); which is stupid.
21:29:31  <trevnorris>we should know the actual length that needs to be written before it's written
21:29:47  <trevnorris>and there's a test-buffer case that's failing, so i'm trying to figure out why
21:32:19  * indexzerojoined
21:32:40  <trevnorris>bnoordhuis: apparently base64 encoding ignores whitespace. so it automatically removes a bunch of '\n' from the string.
21:32:52  <trevnorris>but it allocates the buffer based on the length of the string.
21:34:29  <bnoordhuis>trevnorris: isn't base64_decoded_size_fast() used for that?
21:36:17  * dshaw_quit (Quit: Leaving.)
21:36:17  <bnoordhuis>because that doesn't take whitespace into account, it just looks at the length of the string
21:37:50  * c4milo_quit (Remote host closed the connection)
21:39:01  <trevnorris>> Buffer.byteLength(Buffer('M\nan').toString('base64'), 'base64') === 4
21:40:46  <trevnorris>oy I don't get base64 encoding.
21:40:47  <trevnorris>> Buffer('Man').toString('base64') == 'TWFu'
21:40:47  <trevnorris>Buffer('M\nan').toString('base64') == 'TQphbg=='
21:41:00  <bnoordhuis>trevnorris: that's because it gives you the byte length when the input is _decoded_ as base64
21:41:35  <bnoordhuis>trevnorris: which is correct because unbase64(base64('M\nan')) == 'M\nan'
21:41:52  * bradleymeckquit (Quit: bradleymeck)
21:42:35  <trevnorris>but then why does it have to change buf.length when the value is written? can't we know beforehand what the exact buffer byte length needs to be?
21:43:32  <trevnorris>this assert is what makes no sense: assert.equal(quote.length, b.length);
21:43:53  <trevnorris>why would we expect the un-base64 string length and the buffer byte length to be equal
21:44:17  <bnoordhuis>trevnorris: not sure i follow. what example in particular are you talking about?
21:44:39  <trevnorris>bnoordhuis: test/simple/test-buffer.js line 404
21:46:22  <bnoordhuis>oh, okay. decoding base64
21:47:07  <trevnorris>i feel like it should be: assert.equal(expected.length, b.length);
21:47:30  <bnoordhuis>quote is an ascii string
21:47:47  <bnoordhuis>so unbase64(base64(quote)).length === quote.length
21:48:10  <bnoordhuis>and because it's ascii, the string length is also the byte length
21:49:26  <trevnorris>ah poop. i read it backwards. ok. that makes sense. but then why doesn't byteLength give the length of the base64 string minus new line characters?
21:49:50  <bnoordhuis>erhw?
21:50:04  <bnoordhuis>byteLength of what?
21:50:14  <trevnorris>so you have expectedWhite, right?
21:50:27  <trevnorris>that length is 277, and the buffer allocated is 277
21:50:54  <trevnorris>but in the Buffer constructor it sets this.length = 269, which is the length of expectedWhite - \n characters
21:51:31  <bnoordhuis>right. i was opposed to that way back when. still think it's a silly idea but that aside
21:51:42  <trevnorris>hah, ok. so we're on the same page.
21:51:48  * indexzeroquit (Quit: indexzero)
21:52:06  <trevnorris>sorry it took me so long to get that across. :P
21:55:57  <trevnorris>bnoordhuis: so, would it be possible to have base64_decoded_size() check for whitespace?
21:57:50  <trevnorris>almost feel like saying, screw it and doing a str.replace(/\s*/g, ''); if encoding is base64
21:58:01  <trevnorris>not like decoding base64 is even close to performant anyways :P
21:58:12  * c4milojoined
21:59:00  <bnoordhuis>trevnorris: that would suck because base64_decoded_size() is O(1) now and that would make it O(n)
21:59:55  <trevnorris>bnoordhuis: well, we're already doing an O(n) because we're reading out the string as utf8. or does v8 do some magic internally to get around that?
22:00:14  * st_lukejoined
22:00:32  <trevnorris>that meaning, checking each character to see if it falls in utf8 two or three byte character space.
22:00:33  <bnoordhuis>if your argument is that O(n) + O(n) is still O(n) then you're in for an earful :)
22:01:14  <trevnorris>haha. no. I plenty background in math. :)
22:01:25  <trevnorris>the point was that performance sucks anyways :P
22:01:37  * TooTallNatejoined
22:01:47  <bnoordhuis>maybe, but that's no reason to make it worse
22:02:19  <trevnorris>yeah yeah. I know. was hoping you'd have some magic sauce to get this working. i mean, you said earlier that you didn't like we rewrite this.length, right?
22:02:38  <bnoordhuis>no, but sometimes it's the lesser of two evils
22:03:31  <trevnorris>but it's so STUPID... :'(
22:03:32  <trevnorris>ok, well, whatever. that should only be the case with base64. i'll just make a note of that and remove my todo to fix. since it looks like that won't happen any time soon.
22:03:38  * piscisaureus_joined
22:03:47  * indexzerojoined
22:04:21  <trevnorris>bnoordhuis: thanks for taking the time to explain that all.
22:04:29  * `3Equit (Quit: Connection closed for inactivity)
22:04:34  <trevnorris>just doing some cleanup to buffer.js (as if there's nothing else I need to be doing right now /s)
22:06:00  <trevnorris>bnoordhuis: hah, how about this. we alloc. take the size after write (since that's alway the correct size) and then realloc to the actual size and make a Buffer from that!
22:06:07  <trevnorris>*malloc
22:06:30  * indexzeroquit (Client Quit)
22:07:30  * trevnorrisfeels anxious awaiting for Dmitry's response about the v8 API.
22:08:21  * mikealquit (Quit: Leaving.)
22:11:32  <trevnorris>piscisaureus_: your cross task event emitter handling is just mind numbing. why would you allow that to happen?
22:12:06  <piscisaureus_>trevnorris: well because in the common case it should behave like EventEmitter now
22:12:08  * m76quit (Read error: Connection reset by peer)
22:12:38  <piscisaureus_>trevnorris: but people will set listeners across tasks occasionally - and then the behaviour needs to be sensible and well-defines
22:12:41  <piscisaureus_>*well-defined
22:12:59  <trevnorris>well-defined: your program explodes in a fire.
22:13:03  <trevnorris>I like that :)
22:13:13  <piscisaureus_>trevnorris: nobody likes that
22:13:20  <trevnorris>ah, I missed the sensible part ;P
22:15:55  <bnoordhuis>trevnorris: that's workable but kind of wasteful when the difference is small
22:16:18  <bnoordhuis>trevnorris: also, does 'realloc' mean realloc(3) in this context?
22:16:21  <piscisaureus_>trevnorris: the bottom line is this
22:16:48  <piscisaureus_>trevnorris: if you decide not to handle errors your task will crash
22:16:57  <trevnorris>bnoordhuis: yeah. like buf.parent i'll just put this on the back burner. hoping one day v8 will remove their ExternalArrayData API and Node will just whither off into history. :P
22:17:14  * kellabytequit (Changing host)
22:17:15  * kellabytejoined
22:17:15  * kellabytequit (Changing host)
22:17:15  * kellabytejoined
22:17:26  <piscisaureus_>trevnorris: like node apps as a whole now, but this lets you make smaller islands in which the same rules apply
22:17:51  <trevnorris>piscisaureus_: handling errors is easy. I thought like the _point_ of a task is that if an error occurs all the resources within a task can be reliably cleaned up.
22:17:53  <trevnorris>yeah.
22:18:40  <piscisaureus_>trevnorris: yes and no. Handling errors right isn't easy even if node cleans up resources.
22:18:49  <piscisaureus_>but it gets a little easier
22:19:11  <bnoordhuis>trevnorris: right. the reason i ask is that realloc(ptr, fewer_bytes) may decide not to realloc at all and just return ptr
22:19:26  <piscisaureus_>trevnorris: but Task even does something sensible if you don't handle errors right :)
22:19:54  <trevnorris>bnoordhuis: really? like if the diff is small enough it'll decide to do nothing?
22:20:02  <bnoordhuis>trevnorris: yep
22:20:18  <trevnorris>bnoordhuis: strange. thanks for the knowledge yet again.
22:20:24  <bnoordhuis>np :)
22:21:10  <trevnorris>ah, man 3 realloc. nice.
22:21:18  <trevnorris>really have to learn to start using those more often.
22:21:34  <trevnorris>piscisaureus_: but isn't "something sensible" sort of arbitrary?
22:21:56  <piscisaureus_>trevnorris: well, yes and no. Isn't everything?
22:22:03  <piscisaureus_>yes and no day
22:22:08  <trevnorris>heh
22:22:41  * mikealjoined
22:23:15  <trevnorris>bnoordhuis: btw, awesome libuv app. once I allow myself some free time away from node i'm going to start studying how to write a full app in libuv.
22:23:50  <trevnorris>piscisaureus_: what I mean is that the list of rules you'd have to define, and the exceptions for each case, is going to be a novel.
22:24:34  * mikealquit (Client Quit)
22:24:43  <piscisaureus_>trevnorris: well - it's a gist
22:24:56  <piscisaureus_>trevnorris: there aren't any exceptions to the rules outlined there
22:25:05  <trevnorris>and, i've determined that micro benchmarks under 5ns are unreliable.
22:25:13  <trevnorris>mraleph would probably smack me right now.
22:25:15  <piscisaureus_>hurray!
22:25:24  <piscisaureus_>give this man a nobel prize
22:25:26  * mikealjoined
22:25:33  <trevnorris>hah
22:26:10  <bnoordhuis>trevnorris: thanks :)
22:26:27  <bnoordhuis>btw, anyone want to review it? (indutny piscisaureus_?)
22:26:54  <bnoordhuis>i was thinking of merging it later this week but getting more eyeballs on it is always a good thing
22:28:06  <trevnorris>bnoordhuis: was thinking for v0.13 I'd really like to move towards allowing (almost) anything with external memory to be passed to, say, fs.write(). e.g. new Buffer(), new ArrayBuffer(), smalloc.alloc(). bnoordhuis: thoughts?
22:28:14  * pooyajoined
22:28:34  <trevnorris>strange, completed your name twice.
22:29:27  <piscisaureus_>bnoordhuis: I won't miss it. I think the other users should realize that it being out of core makes it much easier to iterate and improve.
22:29:48  <piscisaureus_>bnoordhuis: the only question is - how feasible is it to implement debugger in userland as of today
22:30:10  <piscisaureus_>bnoordhuis: I think we'd have to make-public process._debugBreak
22:30:17  <piscisaureus_>(maybe move it to require('debugger') ?)
22:31:09  <piscisaureus_>bnoordhuis: also, now what's going to happen is our changes break the node-debugger module all the time and we won't notice
22:31:12  <piscisaureus_>bnoordhuis ... or?
22:31:22  <bnoordhuis>piscisaureus_: then bajtos can file issues :)
22:31:34  <bnoordhuis>but that's not the case, it's only the debugger repl that gets axed
22:31:40  <piscisaureus_>bnoordhuis: bajtos is not going to work on it right?
22:31:41  <trevnorris>piscisaureus_: ok. i'll start going over your gist and see if there are any gaps I can fill in.
22:31:41  <trevnorris> piscisaureus_: I would still like to add 3 APIs, 1) ability to add/remove async listeners at the c++ level.
22:31:42  <trevnorris>2) allow filtering so the async listener will only trigger for those specific things.
22:31:42  <trevnorris>3) um. brain fart. i'll get back to you on this one.
22:32:06  <bnoordhuis>piscisaureus_: node-inspector and node-webkit-agent just start node with --debug or --debug-brk. as long as that works, everything's okay
22:32:10  <piscisaureus_>4) move EventEmitter constructor code EventEmitter.init. I can do tha t as well
22:32:13  <bnoordhuis>switching machines, biab
22:32:13  <piscisaureus_>bnoordhuis: ah - right - good
22:32:27  <piscisaureus_>bnoordhuis: no actually inspector calls _debugBreak in some cases
22:33:31  * dshaw_joined
22:36:06  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:36:31  * bnoordhuisquit (Ping timeout: 240 seconds)
22:38:22  * bnoordhuisjoined
22:40:01  * piscisaureus_joined
22:40:08  <bnoordhuis>man, spinning rust is so abominably slow once you're used to ssd
22:40:27  <piscisaureus_>bnoordhuis: back to your desktop again are you?
22:40:31  <bnoordhuis>yep
22:40:54  <bnoordhuis>disks may be slow but `make -j8` makes up for that
22:41:12  <piscisaureus_>bnoordhuis: have 16 gigs of ram for cache
22:41:45  <bnoordhuis>$ free -m | grep ^Mem
22:41:46  <bnoordhuis>Mem: 16012 2760 13251 0 204 1409
22:41:48  <bnoordhuis>^ :)
22:42:18  <bnoordhuis>for some reason i also have 20G of swap
22:42:30  <bnoordhuis>which looks like it's never been touched once
22:45:42  <piscisaureus_>anyone seen tjfontaine
22:49:25  <rendar>bnoordhuis, that parallel compiling option is very helpful
22:49:41  <bnoordhuis>rendar: in v8 you mean?
22:49:50  <rendar>-j8
22:49:51  <bnoordhuis>oh, you mean make -j8?
22:49:54  <bnoordhuis>right :)
22:49:56  <rendar>:)
22:50:39  * mikealquit (Quit: Leaving.)
22:50:52  * mikealjoined
22:50:56  * st_lukequit (Remote host closed the connection)
22:51:17  <bnoordhuis>https://codereview.chromium.org/70013002/ - Support for the Linux 'perf report' and 'perf annotate' tools.
22:51:22  <bnoordhuis>nice. do want
22:51:28  * st_lukejoined
22:55:53  * st_lukequit (Ping timeout: 244 seconds)
22:57:42  <trevnorris>bnoordhuis: you opposed to this: https://github.com/joyent/node/pull/6508
23:01:00  * kevinswi_quit (Ping timeout: 246 seconds)
23:03:03  * kevinswiberjoined
23:03:35  * mikealquit (Quit: Leaving.)
23:08:38  * wolfeidauquit (Ping timeout: 240 seconds)
23:10:15  * pachetquit (Quit: leaving)
23:11:18  * wolfeidaujoined
23:11:53  * kevinswiberquit (Remote host closed the connection)
23:12:24  * kevinswiberjoined
23:13:19  <tjfontaine>trevnorris: seems fine really, but separate the doc changes? if something were to go wrong with the commit it would be frustrating to have to do a partial revert
23:13:23  <tjfontaine>piscisaureus_: I'm here
23:13:37  <trevnorris>tjfontaine: got it. i'll split those up
23:14:19  <tjfontaine>trevnorris: just to be slightly more clear, separate the cleanups from the addition and its documentation
23:14:55  <trevnorris>tjfontaine: done
23:15:02  * st_lukejoined
23:15:11  * mikealjoined
23:15:38  <trevnorris>one of my best friends: git checkout -p
23:16:40  * kevinswiberquit (Ping timeout: 245 seconds)
23:16:50  <bnoordhuis>trevnorris: looking
23:17:04  <trevnorris>thanks :)
23:19:38  <bnoordhuis>done
23:19:43  <trevnorris>bnoordhuis: thanks
23:19:56  <trevnorris>bnoordhuis: and thanks for the debug build note. didn't realize that.
23:20:07  <trevnorris>it worked so well otherwise.
23:20:11  <bnoordhuis>hah :)
23:20:21  <trevnorris>new it was cheating, but wanted to shave off those extra 3ns :P
23:22:46  <trevnorris>bnoordhuis: you think they're actually going to get rid of Handle? they removed the UNSAFE whatnot around the class inheritance.
23:23:12  <bnoordhuis>trevnorris: i guess so. Handle is a bit of an anomaly now
23:23:37  <trevnorris>yeah. strange how that suddenly got dropped.
23:24:18  <bnoordhuis>it's possible they copied the concept from JSC without much thought
23:24:48  <bnoordhuis>and then realized that, hm, it's not so great after all
23:25:13  <trevnorris>hehe
23:26:16  <bnoordhuis>that perf patch for v8 is awesome
23:26:24  <bnoordhuis>best of all, it even applies to node master
23:26:45  <bnoordhuis>1.52% node perf-8045.map [.] LazyCompile:*exports._unrefActive timers.js:519
23:26:57  <trevnorris>bnoordhuis: which one? oh, the one you had to build chromium for?
23:27:12  <bnoordhuis>no, this one -> https://codereview.chromium.org/70013002/
23:27:31  <bnoordhuis>the chromium thing is me trying to get v8 to use CLOCK_MONOTONIC_COARSE
23:27:43  <bnoordhuis>which chromium's sandbox blocks
23:27:48  * c4miloquit (Remote host closed the connection)
23:28:46  <trevnorris>wow, that's a pretty sick patch.
23:28:59  <trevnorris>though, to patch perf, don't you have to build your own kernel?
23:30:04  <bnoordhuis>no, it just patches v8
23:30:11  <bnoordhuis>perf has _some_ jit support
23:30:42  <trevnorris>hm. I must be misunderstanding "outputs the files in a new perf format that only works with a patched perf tool"
23:30:58  <bnoordhuis>it's really basic but essentially what you do is dump a map of code events to /tmp/perf-<pid>.map and perf report will load it
23:31:06  <bnoordhuis>oh, that's about the perf cli tool
23:31:27  <bnoordhuis>if you use an up-to-date distro, you probably already have a perf that supports it
23:31:39  * mikealquit (Quit: Leaving.)
23:31:49  <trevnorris>ah cool.
23:31:53  <bnoordhuis>if not, just `make -C tools/perf` from the top-level directory of a linux source tree
23:32:05  <trevnorris>yeah, ever since I updated my kernel i've been playing w/ the new perf options.
23:33:27  <bnoordhuis>so, LazyCompile:*exports._unrefActive timers.js:519 is far and away the most expensive thing in node right now
23:34:14  <bnoordhuis>funny thing, i had a patch like that one sitting in a tree but i never sent it upstream
23:34:24  <bnoordhuis>BECAUSE IT WAS MY SECRET WEAPON
23:34:25  <LOUDBOT>STAY AWAKE THROUGH THE WHOLE GODDAMNED SHOW
23:34:30  <trevnorris>haha
23:34:35  <bnoordhuis>(not really, i just never got around to polishing it up)
23:34:38  <trevnorris>interesting. wonder why that's so expensive
23:34:42  * trevnorrisgoes to look
23:35:10  <trevnorris>bnoordhuis: ok. fixed up. not sure if you want to take another look.
23:35:29  <bnoordhuis>meh. i trust you got it right. and if not, you'll never hear the end of it
23:35:36  <trevnorris>heh. ok
23:36:00  * mikealjoined
23:37:01  <MI6>joyent/node: Trevor Norris master * 26a795b : doc: fix few smalloc entries for proper formatting (+1 more commits) - http://git.io/T7sGuA
23:41:13  * rendarquit (Quit: Leaving)
23:41:53  <trevnorris>bnoordhuis: so I guess that test-debug-signal-cluster.js isn't part of the debugger repl?
23:41:57  * Kakeraquit (Ping timeout: 248 seconds)
23:42:12  <bnoordhuis>trevnorris: sadly, no
23:42:50  <trevnorris>bummer. well. anyways. RIP IT OUT! :)
23:44:06  <tjfontaine>well let's hold a tick on it, I want to think a bit more on it
23:44:11  <tjfontaine>but I hvae a small meeting at the moment
23:44:27  <trevnorris>tjfontaine: is isaacs alive?
23:46:01  <trevnorris>ok. need to go mail a rug. bbiab
23:46:16  <trevnorris>bnoordhuis: thanks for the help. hopefully you'll be asleep soon.
23:46:31  <trevnorris>piscisaureus_: i heard a rumor that you'll be around SF for a while. that true?
23:46:32  <bnoordhuis>np and probably i will :)
23:50:09  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:55:02  * AvianFluquit (Ping timeout: 240 seconds)
23:56:32  * hij1nxquit (Ping timeout: 246 seconds)
23:58:57  * saghuljoined
23:58:57  <MI6>nodejs-master: #698 FAILURE smartos-x64 (9/675) http://jenkins.nodejs.org/job/nodejs-master/698/