00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:06  <trevnorris>tjfontaine: heh, thanks for the clarification.
00:00:08  * ircretaryjoined
00:00:32  <tjfontaine>heh
00:01:10  * c4miloquit (Remote host closed the connection)
00:02:04  * c4milojoined
00:14:49  * qard1quit (Quit: Leaving.)
00:15:06  * kazuponjoined
00:17:07  <trevnorris>dammit. I can't inherit from TCPWrap, and I can't find a way to get access to the protected members "object()" and "persistent()"
00:17:13  <trevnorris>freakin class inheritance.
00:22:08  * TooTallNatejoined
00:24:05  <isaacs>oh, man, this bug wth EMFILE and ulimit -n is just fucking amazeballs
00:24:44  <isaacs>so, for some silly reason, `npm outdated` is adding tarballs to the cache instead fo just reading the metadata like a gentleman. whatever.
00:24:48  <isaacs>but, what happens is this:
00:25:08  <isaacs>it tries to fetch, let's say, 500 tarballs, at once
00:25:17  <isaacs>for each one of those, what it's going to do then is write them to disk
00:25:51  <isaacs>then, for each one of the ones written to disk, it opens them, and pipes them through the parser, creating files and dirs and such
00:26:36  <isaacs>but, somehow, i'm ending up in a situation where it can't open the next file to write to it, until some other tarball closes, and we end up with a loop in the queue
00:27:04  * this_is_bertjoined
00:28:18  <tjfontaine>this_is_bert: I don't believe you
00:28:32  <tjfontaine>isaacs: ugh.
00:28:42  <tjfontaine>LeftWing: also see, amazeballs is the word of the day.
00:29:02  <isaacs>was something else amazeballs?
00:29:26  <LeftWing>hahaha
00:29:27  <tjfontaine>isaacs: well, the &1 issue was the first node issue with amazeballs, and then he used it aloud in the office
00:31:20  <isaacs>oh, right
00:32:49  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:35:33  * bradleymeckjoined
00:35:46  <isaacs>it'd be nice if there was a mode to open(2) that would say "If you get an EMFILE, just try again once something closes. take all the time you need"
00:37:43  <LeftWing>What, blocking open(2)?
00:38:23  <LeftWing>The application should really just manage the number of fds it uses.
00:39:48  * julianduquequit (Quit: leaving)
00:40:37  * loladirojoined
00:47:34  * kazuponquit (Remote host closed the connection)
00:48:01  * kazuponjoined
00:52:23  * kazuponquit (Ping timeout: 240 seconds)
00:57:37  <this_is_bert>gyp is so amazing
00:57:51  <this_is_bert>I thought I'd try eclipse output for a change and it works
00:57:52  <tjfontaine>I don't believe you
00:57:57  <tjfontaine>oh
00:58:05  <tjfontaine>right that part works fine, it also works with xcode :P
00:58:25  <tjfontaine>anyway, /me goes home
00:58:27  <this_is_bert>I know but I xcode drives me nuts
00:58:30  <this_is_bert>and yes go!
01:08:23  * brsonquit (Ping timeout: 240 seconds)
01:13:15  * this_is_bertquit (Quit: Page closed)
01:27:56  * abraxasjoined
01:30:48  * defunctzombie_zzchanged nick to defunctzombie
02:06:52  * kazuponjoined
02:34:13  * wavdedjoined
02:36:37  * trevnorris_joined
02:36:42  * groundwa_joined
02:37:35  * txdvjoined
02:38:31  * kenperkins_joined
02:38:38  * isaacs_joined
02:39:11  * isaacs_changed nick to Guest87102
02:43:45  * trevnorrisquit (*.net *.split)
02:43:45  * groundwaterquit (*.net *.split)
02:43:45  * txdv_quit (*.net *.split)
02:43:45  * isaacsquit (*.net *.split)
02:43:46  * kenperkinsquit (*.net *.split)
02:43:46  * Denmadquit (*.net *.split)
02:43:50  * trevnorris_changed nick to trevnorris
02:51:16  * c4milo_joined
02:52:13  * TooTallNatejoined
02:52:28  * c4milo_quit (Read error: Connection reset by peer)
02:53:09  * c4milo_joined
02:54:23  * c4miloquit (Ping timeout: 240 seconds)
02:55:14  * c4milo_quit (Read error: Connection reset by peer)
02:55:24  * c4milojoined
02:56:53  * c4miloquit (Read error: Connection reset by peer)
02:57:10  * c4milojoined
02:58:11  * c4miloquit (Read error: Connection reset by peer)
03:00:40  * c4milojoined
03:07:14  * c4milo_joined
03:09:25  * defunctzombiechanged nick to defunctzombie_zz
03:09:27  * Denmadjoined
03:10:55  * c4miloquit (Ping timeout: 260 seconds)
03:37:54  * c4milo_quit (Remote host closed the connection)
03:44:08  * loladiroquit (Quit: loladiro)
04:00:58  <ik_>DAYCHANGE!
04:01:24  * hzquit (Read error: Connection reset by peer)
04:01:37  * hzjoined
04:02:29  * abraxasquit (Remote host closed the connection)
04:26:30  * bradleymeckquit (Quit: bradleymeck)
04:30:18  * wavdedquit (Quit: Hasta la pasta)
04:34:15  * bradleymeckjoined
04:41:57  * hzquit
04:42:10  * loladirojoined
04:42:32  * mcavagequit (Remote host closed the connection)
04:45:05  * bradleymeckquit (Quit: bradleymeck)
04:55:12  * st_lukejoined
04:58:47  * loladiro_joined
05:01:23  * loladiroquit (Ping timeout: 240 seconds)
05:01:25  * loladiro_changed nick to loladiro
05:12:07  * abraxasjoined
05:18:19  * Guest87102changed nick to isaacs
05:23:53  * rendarjoined
05:30:13  * st_lukequit (Remote host closed the connection)
05:35:19  * hueniversequit (Ping timeout: 246 seconds)
05:38:07  * hueniversejoined
05:43:10  * mcavagejoined
05:45:48  * paddybyersjoined
05:45:56  * mcavagequit (Read error: Connection reset by peer)
05:46:07  * mcavagejoined
05:48:57  <isaacs>Hm. ok, so the problem I'm facing is that npm uses a lockfile to prevent opening the same file multiple times in some case.
05:49:43  <isaacs>but, if you try to do 128 things, and your ulimit is 128, then now you have taken up all the slots, and all your attempts to do whatever the thing was that the lockfile was locking, will fail.
05:49:51  * isaacssign
05:49:54  * isaacssigh
05:50:00  * loladiroquit (Ping timeout: 246 seconds)
05:50:35  * mcavagequit (Ping timeout: 245 seconds)
05:51:01  <isaacs>which wouldn't be much of a problem, of course, except that graceful-fs is setting up a retry queue for EMFILE error handling.
05:59:30  <trevnorris>isaacs: so, since we already support it, think we should throw in latin1 to our supported character encodings?
06:03:03  * bajtosjoined
06:08:24  <trevnorris>indutny: you around?
06:09:23  <trevnorris>isaacs, indutny: fyi. in 4488a69 looks like net.Server deprecated some properties in v0.9. That mean we can remove them in master?
06:10:04  * TooTallNatequit (Quit: Computer has gone to sleep.)
06:13:19  * toothrotquit (Ping timeout: 252 seconds)
06:14:52  * kazuponquit (Remote host closed the connection)
06:15:19  * kazuponjoined
06:17:52  * toothrjoined
06:19:43  * kazuponquit (Ping timeout: 245 seconds)
06:20:23  <isaacs>trevnorris: meh
06:20:36  <isaacs>trevnorris: only if they're actually in the way for some reason.
06:21:13  <trevnorris>isaacs: you mean for the removal? honestly it's just ugly. Doing a Object.defineProperty on every server instantiation
06:22:13  <isaacs>trevnorris: meh. we don't instantiate THAT many servers.
06:22:25  <isaacs>trevnorris: what is that, like 10 defineProperty calls at most, ever?
06:23:05  * kazuponjoined
06:23:06  <isaacs>trevnorris: compared with someone complaining that they have to update all sorts of code in random modules in production to upgrade to 0.12, i think that's worth it.
06:23:31  <trevnorris>isaacs: more about not feeling icky when I look at the code ;) also there's just some other code cleanup stuff like not using arguments[].
06:23:56  <isaacs>trevnorris: that icky feeling is karma
06:24:05  <isaacs>trevnorris: it is inescapable :)
06:24:10  <trevnorris>hah
06:24:11  <isaacs>trevnorris: i feel the same way about sys vs util
06:24:27  <isaacs>trevnorris: purity and an empty sack is worth the sack
06:24:59  <trevnorris>isaacs: mother. I didn't even realize sys was still around :P
06:25:54  <isaacs>oh, man, this lockfile bug is kind of killing me
06:26:02  <isaacs>i've made a terrible mistake
06:26:09  <trevnorris>still at it?
06:26:31  <isaacs>yeah
06:26:33  <isaacs>it's tricky
06:27:31  <trevnorris>i've only partially been following what's going on. have a ticket open or something?
06:29:14  <isaacs>nah
06:29:17  <isaacs>well, a few
06:29:22  <isaacs>people talking about getting EMFILE errors
06:29:56  <isaacs>what happens is that npm uses a lockfile in the cache to prevent it from trying to unpack the same file in multiple processes
06:30:21  <isaacs>add to this that graceful-fs will queue up on EMFILE errors
06:30:29  <isaacs>if your ulimit is 128, say
06:30:37  <isaacs>and you try to do 200 operations
06:30:46  <isaacs>you'll open up 128 lock files
06:30:57  <isaacs>the other 72 lockfiles will get EMFILE, and queue up
06:31:07  <isaacs>then you'll try to do 128 actual file ops
06:31:11  <isaacs>and those will also queue up
06:31:20  <trevnorris>...
06:31:23  <isaacs>but you never give up the lock until the operation finishes
06:31:28  <isaacs>but it can't proceed
06:31:51  <trevnorris>wow, quite the issue. ulimit of 128?
06:32:43  <isaacs>or whatever
06:32:48  <isaacs>say its 256
06:32:53  <isaacs>but you try to do 500 things
06:32:55  <isaacs>still gonna fail
06:33:01  <trevnorris>yeah.
06:33:06  <isaacs>ock up and never proceed
06:33:16  <isaacs>i need to close the lockfile, but just not delete it
06:33:19  <isaacs>derp
06:35:11  <trevnorris>well. on a less painful note, i've resorted to working with a zero length return http server to figure out the rewrite https://gist.github.com/trevnorris/5972854
06:35:20  <trevnorris>there's so many layers going on I get lost
06:39:22  <isaacs>nice
06:45:58  <trevnorris>isaacs: so getting the EMFILE is fine, since they're queue up for later. but why would the first set of file ops also queue up?
06:52:45  <isaacs>trevnorris: but that's fine, because then those fds will close, and their actual operations will proceed
06:52:58  <isaacs>the open() call just creates the file, and then lockfile closes
06:53:10  <isaacs>now the file exists, so another call to open(path, 'wx') will fail
06:53:27  <isaacs>becuse the file already exists, so exclusivity can't be guaranteed
06:55:16  * defunctzombie_zzchanged nick to defunctzombie
06:57:32  <trevnorris>hm.
06:57:48  * M28quit (Read error: Connection reset by peer)
07:05:27  * defunctzombiechanged nick to defunctzombie_zz
07:14:31  <trevnorris>wtf!? error: no member named 'Use' in namespace 'node::Buffer'
07:18:53  <isaacs>ircretary: tell TooTallNate I just pushed a very minor change to node-gyp, to use graceful-fs 2.0. works around this awful EMFILE bug.
07:18:53  <ircretary>isaacs: I'll be sure to tell tootallnate
07:20:24  <trevnorris>how is it I can't use node::Buffer::Use in this freakin module? oy.
07:30:27  <trevnorris>oh, hell. i must be tired...
07:34:01  * juliangruber_changed nick to juliangruber
07:47:25  * mcavagejoined
07:51:46  * mcavagequit (Ping timeout: 240 seconds)
07:56:09  * bajtosquit (Quit: bajtos)
07:58:37  * bajtosjoined
08:07:13  * kazuponquit (Ping timeout: 245 seconds)
08:12:28  * kazuponjoined
08:12:35  * stagasjoined
08:12:51  * M28joined
08:15:50  * txdv_joined
08:16:25  * txdvquit (Ping timeout: 245 seconds)
08:36:06  * jameshowejoined
08:37:12  <jameshowe>morining tjfontaine
08:46:49  <jameshowe>and trevnorris
08:46:58  <jameshowe>if you're not actually asleep
08:47:10  <trevnorris>just about off to bed.
08:47:46  * mcavagejoined
08:47:50  <jameshowe>ah, West Coast?
08:48:27  <trevnorris>yup
08:48:54  <jameshowe>I won't keep you
08:49:09  <trevnorris>oh, no worries. completely self inflicted :)
08:52:37  * mcavagequit (Ping timeout: 276 seconds)
08:53:11  <trevnorris>jameshowe: real quick. landed a patch on v0.10 branch today that fixes the MakeCallback no domains problem.
08:53:28  <trevnorris>jameshowe: so on latest your code should work with domains just fine
08:53:38  <jameshowe>thanks, I'll have a go
08:54:16  <trevnorris>np
08:57:37  <trevnorris>alright. getting crossed eyed. http will have to wait.
08:57:38  * trevnorris&
09:32:15  * bajtosquit (Quit: bajtos)
09:35:53  * bnoordhuisjoined
09:47:04  * bajtosjoined
09:47:43  <bajtos>bnoordhuis: ping
09:53:53  * dominictarrquit (Quit: dominictarr)
10:01:49  * kazuponquit (Remote host closed the connection)
10:02:19  * kazuponjoined
10:06:32  * kazuponquit (Ping timeout: 246 seconds)
10:55:13  * abraxasquit (Remote host closed the connection)
11:05:03  * kazuponjoined
11:33:53  * piscisaureus_joined
11:35:13  * csaohjoined
11:35:33  * hzjoined
11:42:01  * bajtosquit (Quit: bajtos)
11:51:23  * stagasquit (Ping timeout: 240 seconds)
11:53:46  <rvagg>guys, I'm using uv_poll* on a socket, but i have no idea how to detect a socket close, suggestions?
11:54:34  <piscisaureus_>you can't detect a socket FD being closed in a reliable manner. You can detect FIN and errors though.
11:55:22  <rvagg>pointers on doing that?
12:01:20  <bnoordhuis>rvagg: read from or write to the socket. you'll get ECONNRESET or whatever if the connection's been severed
12:03:51  <rvagg>mm, that's my concern, if I'm only reacting to polling and there's no events because it's been closed then it could be left open indefinitely because I have no reason to read or write to it
12:04:20  <rvagg>guess i need to figure out some kind of ping mechanism that fits with the protocol I'm working with
12:04:27  <rvagg>thanks guys, helpful as usual
12:05:57  <piscisaureus_>rvagg: on both unix and windows you shouldn't poll on a socket that *may* be closed
12:06:02  <piscisaureus_>for different reasons
12:06:29  <piscisaureus_>rvagg: unix *might* fail with EBADF but worse, the fd could be reused and you end up polling the wrong socket
12:06:57  <rvagg>piscisaureus_: but what kind of socket might not be closed?
12:07:12  <piscisaureus_>rvagg: well - all sockets can be closed
12:07:36  <piscisaureus_>rvagg: so you just have to make sure to call uv_poll_stop before calling close() or closesocket()
12:08:07  <piscisaureus_>rvagg: if the other end sends a FIN packet the fd itself stays open.
12:09:06  <rvagg>piscisaureus_: ok, I'll do some more research on that, thanks
12:09:49  <piscisaureus_>rvagg: I know it's a bit unfortunate. However I don't know of any library that can deal with sockets being closed under their feet reliably. Definitely not libev or libevent.
12:15:34  <bnoordhuis>piscisaureus_, rvagg: could it be you guys are talking about a different kind of close? i think what rvagg means is how to detect if a connection has been closed by the other end?
12:16:35  <rvagg>bnoordhuis, piscisaureus_: yeah, I have control over my end, I can stop the polling before I close, but I'm concerned about the client ending prematurely without saying it'll do so
12:16:56  <piscisaureus_>rvagg: well in that case you'll find out when you try to read or write
12:17:17  <piscisaureus_>rvagg: if read() returns 0 then the other end did a graceful (half-)close
12:18:22  <piscisaureus_>rvagg: if read() or write() or shutdown() fails with ECONNRESET or ECONNABORTED you know the socket broke and you can only just stop polling and close the fd
12:22:27  <MI61>joyent/node: Ben Noordhuis master * 6acde21 : src: remove unnecessary calls to Local<T>::New() (+2 more commits) - http://git.io/vAtpLg
12:25:31  <bnoordhuis>piscisaureus_: "To enable parallel builds, please add the /m switch". i thought vcbuild.bat does that?
12:25:56  <piscisaureus_>bnoordhuis: yeah, I don't know what's up with that. This happens occasionally for me as well
12:26:10  <piscisaureus_>bnoordhuis: I sure do know we enable it.
12:26:31  <piscisaureus_>bnoordhuis: as a quick fix you could just add the /m to vcbuild.bat and call it a day?
12:27:25  <bnoordhuis>piscisaureus_: msbuild node.sln /m /t:%target% /p:Configuration=%config% /clp:NoSummary;NoItemAndPropertyList;Verbosity=minimal /nologo
12:27:30  <bnoordhuis>it's already there?
12:27:55  <piscisaureus_>the msvc team must have a bugtracker somewhere
12:28:04  * kazuponquit (Remote host closed the connection)
12:28:11  <piscisaureus_>bnoordhuis: possibly just /m isn't enough - let me take a quick look
12:28:25  <piscisaureus_>bnoordhuis: which windows / vs / sdk version is this?
12:29:26  <bnoordhuis>windows 7, msvs 2012
12:29:31  <bnoordhuis>don't know about the sdk
12:29:45  <piscisaureus_>ah vs2012 could be it
12:30:09  <piscisaureus_>if you have VS ultimate/pro installed you're probably not building with the sdk
12:30:45  <bnoordhuis>you know, it might have actually been doing a parallel build
12:31:01  <bnoordhuis>it finished in like two minutes
12:31:41  <piscisaureus_>ok cool
12:31:48  <bnoordhuis>also, the windows build is broken
12:32:01  <bnoordhuis>but i'm working on that
12:32:41  <piscisaureus_>nice
12:32:43  <piscisaureus_>is it because of v8?
12:33:10  <bnoordhuis>not exactly. some of the changes i made to node after the upgrade
12:33:18  <bnoordhuis>the linker complains it can't find some symbols
12:33:50  <bnoordhuis>https://github.com/joyent/node/issues/5810
12:34:34  <MI61>nodejs-master: #300 UNSTABLE smartos-x64 (7/610) linux-x64 (1/610) osx-ia32 (1/610) linux-ia32 (1/610) osx-x64 (1/610) http://jenkins.nodejs.org/job/nodejs-master/300/
12:41:37  * bradleymeckjoined
12:49:10  * mcavagejoined
12:49:35  <MI61>nodejs-master-windows: #107 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/107/
12:53:25  * mcavagequit (Ping timeout: 248 seconds)
12:58:58  * jez0990quit (Quit: No Ping reply in 180 seconds.)
12:59:49  * bajtosjoined
13:00:16  * jez0990joined
13:00:52  * c4milojoined
13:02:16  * kazuponjoined
13:07:16  * AvianFluquit (Read error: Connection reset by peer)
13:08:08  * AvianFlujoined
13:13:52  <bnoordhuis>"The input line is too long. The syntax of the command is incorrect."
13:14:09  <bnoordhuis>seriously, why does vcbuild start throwing this error all of a sudden?
13:14:53  * bradleymeckquit (Quit: bradleymeck)
22:15:52  <trevnorris>i was thinking I'd just overwrite the DoRead callback, which i've managed to do, but then I need to buffer the incoming data until all the headers are recieved.
22:17:00  <trevnorris>not sure of the best way to buffer N requests until they're all received.
22:17:33  <bnoordhuis>tjfontaine: yeah, i guess so. Date.now() and Timer.now() have identical gc behaviour so yeah
22:17:45  <bnoordhuis>trevnorris: sure
22:17:47  <tjfontaine>bnoordhuis: sigh.
22:18:01  <tjfontaine>trevnorris: javascript certainly makes that logic a lot easier doesn't it? :)
22:18:08  <bnoordhuis>we'll have to switch to spidermonkey, it uses nan tagging!
22:18:17  <tjfontaine>heh
22:18:51  <bnoordhuis>trevnorris: btw, why does spidermonkey call it 'nun boxing'? i don't think any nuns agreed to that
22:19:03  <tjfontaine>nuns are feisty.
22:19:09  <trevnorris>tjfontaine: yes, but as a massive cost. I wrote a zero return minimal http server directly in tcp. it does more than double the requests https://gist.github.com/trevnorris/5972854
22:19:36  <tjfontaine>bnoordhuis: http://www.amazon.com/The-Fighting-Nun-Boxing-Sister/dp/B0006GK8E6/ :P
22:19:49  <tjfontaine>trevnorris: if you move it all to the kernel it gets even faster!
22:19:52  <trevnorris>bnoordhuis: um... yeah. one of those legacy things I guess.
22:20:03  <trevnorris>tjfontaine: :P
22:21:14  <trevnorris>tjfontaine: i'm willing to do whatever is needed to improve performance, and leave it up to y'all to determine whether it's usable or not :)
22:21:47  <trevnorris>bnoordhuis: so from the mailing list it sounds like using reinterpret_cast in a Persistent is perfectly safe, and almost recommended, if it's not weak.
22:21:52  <trevnorris>seems strange, but whatever.
22:22:35  <bnoordhuis>trevnorris: git pull --rebase && git log :)
22:22:38  <tjfontaine>trevnorris: there are problems with our http, to be sure, but fewer of the complaints of throughput speed vs the fact that we just have regular old bad problems, the initial req/sec test only matters on the hype card everyone distributes
22:22:54  <bnoordhuis>tjfontaine: re http://www.amazon.com/The-Fighting-Nun-Boxing-Sister/dp/B0006GK8E6/ - interesting...
22:23:01  * c4miloquit (Remote host closed the connection)
22:23:02  <tjfontaine>bnoordhuis: how can you not love that? :)
22:23:54  <trevnorris>bnoordhuis: eh, what's that for?
22:24:17  * wolfeida_changed nick to wolfeidau
22:24:35  <bnoordhuis>trevnorris: re #5828, with a low --max_old_space_size you don't hit an out of memory error?
22:25:10  <trevnorris>bnoordhuis: no. I believe it's external memory that's building, so it wouldn't cause that to occur.
22:25:34  <trevnorris>bnoordhuis: i've bisected the fix on master to your 3.20 upgrade.
22:25:44  <trevnorris>but who knows what's going on there.
22:25:59  <bnoordhuis>that's me, fixing all the bugs - even if i don't know it
22:26:05  <trevnorris>lol
22:26:14  <trevnorris>what I don't understand is why it doesn't happen with wrk
22:26:17  <trevnorris>but does with ab
22:26:31  <bnoordhuis>is that the ab that ships with os x?
22:26:36  <tjfontaine>he uses linux
22:26:49  <tjfontaine>leenucks
22:27:00  <bnoordhuis>ah okay
22:27:04  <bnoordhuis>what does ab -V print?
22:27:20  <trevnorris>2.3
22:27:49  <bnoordhuis>okay, that's new enough. shouldn't be a problem then
22:27:55  <bnoordhuis>what switches do you pass to ab?
22:28:10  <trevnorris>-c 4 -n 5000000
22:28:43  <bnoordhuis>right. wrk uses keep-alive by default, ab doesn't
22:29:47  <trevnorris>cool. running ab -k now. see if that does it
22:35:47  <trevnorris>bnoordhuis: even with -k and max old/new = 16 rss grew to over 36 in a couple minutes
22:37:24  <bnoordhuis>that's not so shocking, is it?
22:38:47  <trevnorris>since wrk doesn't exceed 17, ever, but ab has linear growth running (for the 10 minutes I left it running) to me seems something is going on
22:39:36  <bnoordhuis>ah, is that what you mean
22:39:49  <bnoordhuis>it could be a bug in the http module
22:40:38  * `3rdEdenchanged nick to `3E|GONE
22:40:46  <bnoordhuis>let me try it myself
22:40:51  <trevnorris>cool
22:41:11  <trevnorris>* bnoordhuis off to fix all the issues
22:44:57  <bnoordhuis>well, i can confirm that master is pretty stable
22:45:15  <bnoordhuis>maxes out at 44.75 MB here with --max_old_space_size=16
22:45:24  <bnoordhuis>pmap output is also stable
22:47:11  <bnoordhuis>the numbers from v0.10 don't look shocking so far
22:48:38  * paddybyersquit (Ping timeout: 240 seconds)
22:49:07  <trevnorris>bnoordhuis: interesting. on master with --max_{old,new}_space_size=16 never got over 22 MB for me, but on v0.10 climbed past 60 MB
22:51:01  <bnoordhuis>i don't know, i'm not seeing that
22:51:38  <bnoordhuis>it's pretty stable. the only thing is that v8 occasionally allocs some memory for its internal structures
22:51:53  <bnoordhuis>that's probably the optimizer at work
22:52:14  <trevnorris>hm. i'm still running it now. hasn't topped out yet. i'll let it run until it doees.
22:55:26  <bnoordhuis>https://gist.github.com/paulmillr/2657075/ <- i'm on the list!
22:56:34  <tjfontaine>isaacs is #34
22:57:18  <tjfontaine>isnane.
22:57:22  <tjfontaine>bnoordhuis: congrats
22:57:49  <bnoordhuis>why, thanks :)
23:00:25  <isaacs>tjfontaine: yes, i turned 34 a few days ago, actually
23:00:33  <isaacs>oh, heh, that's a different thing
23:00:47  * loladiroquit (Quit: loladiro)
23:01:35  <tjfontaine>isaacs: you have reached singularity
23:01:40  <isaacs>haha
23:01:43  * c4milojoined
23:01:58  * loladirojoined
23:02:00  * loladiroquit (Client Quit)
23:05:13  <trevnorris>bnoordhuis: 80 MB and still climbing
23:06:10  <trevnorris>taking forever though. on the order of 512 KB / minute
23:07:23  <tjfontaine>bnoordhuis: https://github.com/tjfontaine/node/compare/setimmediate-queue
23:08:34  <isaacs>ok, npm is now super EMFILE resilient, and `man 5 package.json` works
23:08:44  <tjfontaine>isaacs++
23:08:46  <isaacs>i cannot tell you how happy it makes me to have man pages in the proper sections.
23:08:53  <isaacs>it makes me unreasonably happy.
23:14:32  <tjfontaine>isaacs: would you also care to review that branch
23:14:41  <tjfontaine>isaacs: that's what we talked about in person yesterday
23:14:42  <tjfontaine>er
23:14:44  <tjfontaine>tuesday
23:14:47  <tjfontaine>wtf day is it
23:15:23  <isaacs>tjfontaine: which one are you?
23:15:52  <isaacs>ah, yes, i recall this
23:15:54  <isaacs>reading now
23:16:19  <tjfontaine>the timers.js change is ben's, but it's exactly what I was planning on doing, I just added the test and the docs
23:19:06  <isaacs>tjfontaine: atualy, gotta run out. i'll mess with this when i get bak
23:19:14  <tjfontaine>isaacs: enjoy!
23:28:17  * dominictarrquit (Quit: dominictarr)
23:35:26  <trevnorris>bnoordhuis: ok. up to 135 MB
23:35:34  <tjfontaine>C is for cookie just came on my rdio
23:35:38  <tjfontaine>awesome.
23:41:48  * defunctzombie_zzchanged nick to defunctzombie
23:55:09  * defunctzombiechanged nick to defunctzombie_zz
23:55:31  * bnoordhuisquit (Ping timeout: 260 seconds)