00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:02:42  * kevinswiberquit (Remote host closed the connection)
00:03:04  <trevnorris>see ya.
00:03:07  <trevnorris>bnoordhuis: shouldn't you be in bed?
00:03:52  * brsonjoined
00:04:45  * AvianFluquit (Remote host closed the connection)
00:07:28  * Benvie_joined
00:07:49  <tjfontaine>oh man, running the test suite in debug mode on windows is pure noise
00:08:44  <bnoordhuis>trevnorris: yeah... but i'm nearly done with my 6502 cpu emulator
00:10:41  <tjfontaine>https://github.com/tjfontaine/node/compare/joyent:v0.10...fix-64bit-ascii lgty?
00:14:25  <bnoordhuis>tjfontaine: #if defined(...)
00:14:33  <tjfontaine>ok
00:14:45  <tjfontaine>for both symbols?
00:14:48  <bnoordhuis>yes
00:15:02  <tjfontaine>k
00:17:06  <tjfontaine>ok force pushed
00:17:14  <tjfontaine>presume it's safe to commit then?
00:17:30  <bnoordhuis>sure
00:17:39  <tjfontaine>mk, thanks
00:17:53  <MI6>joyent/node: Timothy J Fontaine v0.10 * a2c4ca0 : string_bytes: properly detect 64bit - http://git.io/y3NpMw
00:18:53  <bnoordhuis>interesting factoid, trying to divide by 3 on a cpu that has no DIV instruction requires between 1 and 8 shift/plus/and iterations
00:19:05  <tjfontaine>heh
00:23:32  * qardquit (Quit: Leaving.)
00:32:21  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:34:56  * papertigersquit (Quit: papertigers)
00:36:22  <MI6>nodejs-v0.10-windows: #85 UNSTABLE windows-ia32 (7/592) windows-x64 (7/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/85/
00:50:50  * kazuponjoined
00:51:34  * TooTallNatejoined
00:54:26  * defunctzombiechanged nick to defunctzombie_zz
00:55:46  * kazuponquit (Ping timeout: 270 seconds)
01:00:19  <isaacs>How would you all feel if we moved libuv and node to bitbucket?
01:00:55  <tjfontaine>well, mostly I don't care
01:00:58  <tjfontaine>but
01:01:05  <tjfontaine>I suspect that threat alone would garner some attention
01:01:44  <tjfontaine>enough for them to want to have a sit down
01:07:19  <MI6>nodejs-v0.10: #256 UNSTABLE smartos-ia32 (1/592) smartos-x64 (3/592) http://jenkins.nodejs.org/job/nodejs-v0.10/256/
01:08:18  <TooTallNate>isaacs: really?
01:08:32  <isaacs>TooTallNate: yes, not joking.
01:08:41  <isaacs>TooTallNate: it'd be a huge change.
01:08:50  <isaacs>just, assuming that everything actually worked, how would yo ufeel about it?
01:08:51  <TooTallNate>isaacs: what's the motivation? (sorry if i missed it already)
01:09:02  <isaacs>we could still automatically pipe stuff to github.
01:09:09  <isaacs>it'd be several months to move.
01:09:13  <isaacs>TooTallNate: just wondering.
01:09:29  <TooTallNate>i mean i've never used bitbucket
01:09:36  <TooTallNate>so "Why?" comes to mind...
01:09:43  <tjfontaine>for the most part you'd not really see a difference
01:09:56  <isaacs>TooTallNate: well...
01:10:09  <isaacs>i haven't been super happy with the support we've gotten from github
01:10:17  <tjfontaine>[lack of] support
01:10:19  <isaacs>i'm wondering if atlasian would be easier to deal with
01:10:29  <isaacs>re CLAs, issues/pull request features, etc.
01:10:50  <isaacs>a nonstop train of UI "enhancements" that make it pretier and less useful
01:11:01  <TooTallNate>haha, well ya that i can agree with
01:11:23  <isaacs>and i mean, whatever, we're not github's 99% use case.
01:11:26  <isaacs>i can get the need to focus.
01:11:43  <tjfontaine>who is the 99% use case?
01:11:46  <isaacs>node is one of a few dozen projects with tons and tons of activity, a big team, etc.
01:11:56  <tjfontaine>the unsupported-ware distributed?
01:11:58  <isaacs>the 99% use case is a rubygem or an npm package or a single java class.
01:12:07  <tjfontaine>nod
01:12:11  <TooTallNate>we're one of GH's bigger projects... i'd hope they take us seriously with usability suggestions
01:12:17  <isaacs>or, a frontend utility
01:12:43  <isaacs>TooTallNate: let's just say, i'm not so sure that most people at github do.
01:13:00  <isaacs>TooTallNate: have you seen https://github.com/isaacs/github/issues ?
01:13:08  <tjfontaine>issues/6
01:13:11  <tjfontaine>in particular
01:13:18  * bnoordhuisquit (Ping timeout: 264 seconds)
01:13:43  <TooTallNate>isaacs: i've seen the repo, not looked at the issue contents yet
01:13:47  * TooTallNatepeeking now
01:13:55  <tjfontaine>isaacs: I'd hope that we could at least turn this into a conversation to start with them
01:14:02  <TooTallNate>isaacs: tjfontaine hahaha, i like #6
01:14:04  <TooTallNate>inception
01:14:16  <isaacs>tjfontaine: sure.
01:14:23  <isaacs>it'd take months to actually do anyway
01:14:26  <tjfontaine>right
01:14:48  <isaacs>our most active github user at the moment is bnoordhuis
01:14:58  <isaacs>so if he was strongly opposed, i'd probably not bother.
01:15:04  <tjfontaine>aside from an outright move, my other suggestions is to be passive agressive
01:15:15  <isaacs>tjfontaine: i've been trying agressive aggressive
01:15:26  <isaacs>tjfontaine: also, i had a meeting today with one of their UX research people
01:15:38  <tjfontaine>nod, I thought about making @GHIssues that just starts tweeting this out
01:16:02  <isaacs>hahha
01:16:27  <isaacs>it could tweet stuff like "Please make all suggestions in private. In fact, don't even tell us. Write them in your journal"
01:16:44  <isaacs>that's not nice, though
01:17:09  <isaacs>the advantage of taking the high road is that you can still respect yourself and be friends with the humans later.s
01:17:23  <isaacs>but i'd totally follow that twitter account, and probably laugh at the stuff it posts.
01:24:59  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:26:05  * kevinswiberjoined
01:29:03  * dapquit (Quit: Leaving.)
01:31:29  * kevinswiberquit (Remote host closed the connection)
01:32:20  * c4miloquit (Remote host closed the connection)
01:34:54  * c4milojoined
01:36:49  * abraxasjoined
01:49:28  * pachetjoined
01:50:08  * kazuponjoined
01:54:43  * amartensjoined
01:55:48  * kazuponquit (Ping timeout: 260 seconds)
02:00:55  * AvianFlujoined
02:02:08  * loladirojoined
02:04:21  * defunctzombie_zzchanged nick to defunctzombie
02:05:18  * qardjoined
02:09:57  * pachetquit (Quit: leaving)
02:11:26  * loladiroquit (Quit: loladiro)
02:14:06  * kevinswiberjoined
02:14:11  * defunctzombiechanged nick to defunctzombie_zz
02:14:28  * loladirojoined
02:19:19  * bnoordhuisjoined
02:19:28  * qardquit (Quit: Leaving.)
02:23:24  * bnoordhuisquit (Ping timeout: 240 seconds)
02:25:12  * dapjoined
02:32:54  * dapquit (Quit: Leaving.)
02:38:12  * TooTallNatejoined
02:44:47  * dapjoined
02:45:31  * timoxleyquit (Ping timeout: 264 seconds)
02:46:20  * brsonquit (Quit: leaving)
03:04:29  * sakkakujoined
03:09:24  * c4miloquit (Read error: Connection reset by peer)
03:09:47  * c4milojoined
03:54:48  * c4miloquit (Remote host closed the connection)
03:56:12  * kazuponjoined
04:01:40  * sakkakuquit (Remote host closed the connection)
04:02:08  <tjfontaine>isaacs: :)
04:21:54  * loladiro_joined
04:22:04  * loladiroquit (Read error: Connection reset by peer)
04:22:04  * loladiro_changed nick to loladiro
04:28:04  * kevinswiberquit (Remote host closed the connection)
04:33:28  * philipsjoined
04:45:57  * sblomquit (Ping timeout: 246 seconds)
04:52:58  * paddybyersjoined
04:54:06  * Sid_quit (Quit: Page closed)
04:56:24  * kevinswiberjoined
05:04:36  * paddybyersquit (Ping timeout: 268 seconds)
05:05:08  * st_lukejoined
05:07:26  * kevinswiberquit (Remote host closed the connection)
05:10:43  * groundwaterquit (Ping timeout: 264 seconds)
05:14:03  * groundwaterjoined
05:22:43  * AvianFluquit (Ping timeout: 264 seconds)
05:42:44  * wolfeidauquit (Remote host closed the connection)
05:42:57  * paddybyersjoined
05:49:16  * wolfeidaujoined
06:18:50  * csaohjoined
06:24:12  * csaohquit (Quit: csaoh)
06:24:52  * loladiroquit (Quit: loladiro)
06:36:03  * bajtosjoined
06:45:20  * dapquit (Quit: Leaving.)
06:47:26  * rendarjoined
06:54:47  * stagasjoined
06:55:39  * `3E|ZZZchanged nick to `3rdEden
06:57:21  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
07:00:17  * paddybyersquit (Ping timeout: 248 seconds)
07:07:26  * Benviequit (Ping timeout: 256 seconds)
07:07:48  * st_lukequit (Remote host closed the connection)
07:07:49  * Benviejoined
07:23:57  * bajtosquit (Quit: bajtos)
07:32:12  * bajtosjoined
07:34:27  * groundwaterquit (Ping timeout: 268 seconds)
07:34:52  * amartensquit (Quit: Leaving.)
07:35:10  * csaohjoined
07:36:56  * groundwaterjoined
07:40:13  * Benviequit (Remote host closed the connection)
07:40:30  * Benviejoined
07:42:30  * sblomjoined
07:44:05  * bajtos_joined
07:45:23  * bajtosquit (Ping timeout: 240 seconds)
07:45:24  * bajtos_changed nick to bajtos
07:46:41  * sblomquit (Ping timeout: 248 seconds)
07:55:35  * bajtosquit (Quit: bajtos)
08:05:15  * amartensjoined
08:07:44  * paddybyersjoined
08:12:31  * amartensquit (Ping timeout: 264 seconds)
08:12:56  * greg__joined
08:39:48  * greg__quit (Quit: Page closed)
08:45:34  * bajtosjoined
08:53:00  * bnoordhuisjoined
09:00:23  * wolfeidauquit (Ping timeout: 245 seconds)
09:09:49  * amartensjoined
09:14:09  * amartensquit (Ping timeout: 248 seconds)
09:20:31  * bajtosquit (Quit: bajtos)
09:27:09  * bajtosjoined
09:41:29  * stagasquit (Ping timeout: 268 seconds)
09:49:00  * bajtosquit (Quit: bajtos)
10:02:54  * bajtosjoined
10:10:09  * amartensjoined
10:10:50  * bajtosquit (Quit: bajtos)
10:14:40  * amartensquit (Ping timeout: 260 seconds)
10:16:03  * wolfeidaujoined
10:29:01  * kazuponquit (Remote host closed the connection)
10:32:59  * csaohquit (Quit: csaoh)
10:33:54  * groundwaterquit (Ping timeout: 240 seconds)
10:36:23  * groundwaterjoined
10:49:49  * piscisaureus_joined
10:50:35  * csaohjoined
10:52:24  * bajtosjoined
10:56:31  <bnoordhuis>https://github.com/bnoordhuis/v8/commit/59a409b <- div-by-3 in js never was so fast!
10:56:55  <mmalecki>bnoordhuis: nice trick
10:57:00  <bnoordhuis>isn't it?
10:57:12  <mmalecki>bnoordhuis: gotta put that on my div-by-3-as-a-service server ;)
10:57:12  <bnoordhuis>needs to be generalized to more than just div-by-3, of course
11:03:38  <piscisaureus_>bnoordhuis: is it so slow currently?
11:04:45  <piscisaureus_>bnoordhuis: also, doesn't this truncate bits?
11:05:11  <piscisaureus_>bnoordhuis: it looks like this only works for values < 2^24
11:06:53  <bnoordhuis>piscisaureus_: v8 generates idiv instructions
11:06:59  <bnoordhuis>mul + shr is 5-10x faster
11:07:52  <bnoordhuis>it works for 32 bits values btw
11:09:50  <piscisaureus_>bnoordhuis: if the initial mul overflows, then where do the "overflowed" bits end up?
11:10:28  * amartensjoined
11:11:02  <bnoordhuis>piscisaureus_: rax is a 64 bits register, remember. its initial value is < 2^32 so multiplying by 0x55555556 fits easily
11:11:24  <piscisaureus_>ah shit this is x64 only
11:11:32  <bnoordhuis>right :)
11:11:37  <piscisaureus_>bnoordhuis: btw I always thought x * 3 == (x << 1 + x) was the fastest trick
11:11:51  <piscisaureus_>hmm that's for multiplication
11:11:55  <piscisaureus_>ignore me now
11:11:58  <bnoordhuis>haha
11:12:35  <bnoordhuis>i guess the mul+shr trick could be extended to ia32
11:12:47  <bnoordhuis>the result ends up in edx:eax
11:14:27  * timoxleyjoined
11:15:15  * amartensquit (Ping timeout: 256 seconds)
11:15:22  <bnoordhuis>and now for something completely different, the build is broken on os x
11:15:31  <bnoordhuis>../../deps/v8/include/v8.h: In function ‘char* node::Buffer::Data(v8::Handle<v8::Value>)’:
11:15:34  <bnoordhuis>../../deps/v8/include/v8.h:900: error: ‘class v8::Data’ is not a function,
11:15:36  <bnoordhuis>../../src/node_buffer.h:38: error: conflict with ‘char* node::Buffer::Data(v8::Handle<v8::Object>)’
11:15:39  <bnoordhuis>../../src/node_buffer.cc:94: error: in call to ‘Data’
11:16:33  <bnoordhuis>though i wager it's more a gcc 4.2 bug
11:21:02  * kazuponjoined
11:23:58  <MI6>joyent/node: Ben Noordhuis master * 157d2bc : buffer: fix gcc 4.2 build breakage (+1 more commits) - http://git.io/CDRJdw
11:25:50  * kazuponquit (Read error: Connection reset by peer)
11:26:17  * kazuponjoined
11:26:21  <MI6>joyent/node: Mathias Bynens master * 972465a : doc: improve punycode.js documentation - http://git.io/_-KjVw
11:35:34  * groundwaterquit (Ping timeout: 268 seconds)
11:35:47  * bnoordhuisquit (Ping timeout: 246 seconds)
11:37:15  * groundwaterjoined
11:37:35  <MI6>nodejs-master: #269 UNSTABLE smartos-x64 (7/604) linux-ia32 (1/604) smartos-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-master/269/
11:41:02  * csaohquit (Quit: csaoh)
11:44:33  * csaohjoined
11:50:33  <MI6>nodejs-master: #270 UNSTABLE smartos-x64 (6/604) smartos-ia32 (3/604) http://jenkins.nodejs.org/job/nodejs-master/270/
11:50:41  * abraxasquit (Remote host closed the connection)
11:51:05  <MI6>nodejs-master-windows: #78 UNSTABLE windows-x64 (20/604) windows-ia32 (19/604) http://jenkins.nodejs.org/job/nodejs-master-windows/78/
12:09:31  * piscisaureus_quit (Ping timeout: 264 seconds)
12:10:49  * amartensjoined
12:13:11  * piscisaureus_joined
12:15:31  * amartensquit (Ping timeout: 260 seconds)
12:15:32  * paddybyersquit (Ping timeout: 260 seconds)
12:16:51  * kazuponquit (Remote host closed the connection)
12:17:44  <MI6>nodejs-master-windows: #79 UNSTABLE windows-x64 (24/604) windows-ia32 (20/604) http://jenkins.nodejs.org/job/nodejs-master-windows/79/
12:28:15  * st_lukejoined
12:28:37  <mmalecki>piscisaureus_: hey. remember that bug in http-proxy where it'd spawn hundreds of TIME_WAIT sockets?
12:32:41  <piscisaureus_>mmalecki: I think it was FIN_WAIT ?
12:32:51  <piscisaureus_>mmalecki: TIME_WAIT sockets are unavoidable.
12:33:30  <mmalecki>piscisaureus_: FIN_WAIT_2, right. I'm actually almost sure that TIME_WAIT is caused by some problem in node. we're getting tons of them even after we reduced the timeout to 8 seconds
12:33:36  <piscisaureus_>mmalecki: if "your side" of the connection initiates a connection close then that socket WILL end up in TIME_WAIT state
12:33:53  * groundwaterquit (Ping timeout: 240 seconds)
12:34:01  <piscisaureus_>mmalecki: so in general you'd fix this by specifying your protocol such that the client closes and not the server
12:34:45  <piscisaureus_>mmalecki: however, if you're writing a proxy server then the server pretends to be a client for the real server
12:34:59  <piscisaureus_>mmalecki: so there's basically nothing you can do
12:36:02  <mmalecki>well, I tried fine tuning those damn smartos options with no luck. I'm almost sure there has to be a bug somewhere in node which prevents sockets for being closed correctly.
12:36:36  <piscisaureus_>mmalecki: if there was it would be stuck in CLOSE_WAIT
12:36:46  * groundwaterjoined
12:37:09  <piscisaureus_>mmalecki: which actually got fixed recently
12:37:33  <piscisaureus_>(well - a bug where CLOSE_WAIT sockets happened under particular circumstances)
12:37:51  <piscisaureus_>mmalecki: but if I may suggest...
12:38:35  <piscisaureus_>mmalecki: try avoiding .end() on a connection. If you are sure that the remote end will hang up soon, then just stop write()ing
12:39:06  <piscisaureus_>mmalecki: and set a timer of a couple of seconds, e.g. if you expect that the remote end is going to hang up but it doesn't you can end() it anyway
12:39:25  <mmalecki>hmm, this might be hard to predict
12:39:42  <piscisaureus_>or just .destroySoon() if you don't expect any more data
12:40:07  <piscisaureus_>mmalecki: but otherwise you will have to fiddle with tcp stack options
12:40:28  <piscisaureus_>I think we do set SO_REUSEADDR right?
12:40:41  <piscisaureus_>TIME_WAIT sockets should be not much of a problem
12:40:52  <mmalecki>yeah, I was just going to ask if we do set it
12:41:02  <mmalecki>I was almost sure it's in uv, but grepping now
12:41:16  <mmalecki>yeah
12:41:53  <mmalecki>I think I'll try fiddling with SO_REUSEPORT too
12:43:58  <mmalecki>I found an interesting paper about this, actually: http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/
12:46:32  * sakkakujoined
12:47:48  <piscisaureus_>mmalecki: is this for http-proxy?
12:48:23  * timoxleyquit (Quit: Computer has gone to sleep.)
12:48:25  <mmalecki>piscisaureus_: yeah. I'm battling with our balancers right now. they are on ~200 TIME_WAIT sockets and it's messing them up.
12:48:36  <piscisaureus_>200 only?
12:48:59  <mmalecki>let me `wc -l` that.
12:49:41  <mmalecki>482. wow.
12:49:51  <piscisaureus_>mmalecki: shrug.
12:49:59  <piscisaureus_>should not be a big deal
12:50:06  <piscisaureus_>mmalecki: but no this isn't a node bug
12:50:24  <piscisaureus_>mmalecki: what you could try is change the way you make http requests to the backend
12:50:32  <mmalecki>yeah, that seems normal, but somehow it is a big deal
12:51:02  * sakkakuquit (Ping timeout: 256 seconds)
12:52:21  <piscisaureus_>I think nodejitsu pays you to figure this shit out :)
12:53:29  <mmalecki>oh, they do. I'm just not really sure if this is normal.
12:53:48  <mmalecki>I'm gonna go through this code and try to reproduce with none-node servers
12:53:52  * loladirojoined
12:57:04  * inolen1quit (Ping timeout: 260 seconds)
12:59:28  * inolenjoined
12:59:51  * loladiroquit (Quit: loladiro)
13:10:50  * AvianFlujoined
13:11:08  * amartensjoined
13:12:35  * bnoordhuisjoined
13:16:07  * amartensquit (Ping timeout: 264 seconds)
13:27:19  * kazuponjoined
13:33:06  * kazuponquit (Ping timeout: 264 seconds)
13:38:31  * paddybyersjoined
13:40:04  * st_lukequit (Remote host closed the connection)
13:40:33  * kevinswiberjoined
13:43:13  * groundwaterquit (Ping timeout: 268 seconds)
13:44:59  <indutny>bnoordhuis: hey man
13:46:08  * groundwaterjoined
13:48:31  <indutny>yt?
13:51:04  <bnoordhuis>indutny: sup fedor?
13:51:13  <indutny>bnoordhuis: I just wanted to ask you
13:51:16  <indutny>a unix specialist
13:51:24  <indutny>wtf is with sysconf's paramters?
13:51:32  <indutny>there're so many of them in header
13:51:38  <indutny>and only few actually documented in man page
13:51:58  <bnoordhuis>basic job security, fedor
13:52:26  <indutny>well, are they working?
13:52:36  <indutny>or is it about your job security? :)
13:53:00  <bnoordhuis>what unix are we talking about btw?
13:54:18  <indutny>well
13:54:21  <indutny>lets say POSIX.2
13:54:22  <indutny>libc
13:54:29  <indutny>and linux
13:54:50  <bnoordhuis>the linux man page for sysconf() is pretty complete, isn't it?
13:55:18  <indutny>really?
13:55:19  <indutny> _SC_NL_SETMAX,
13:55:20  <LOUDBOT>IT WAS A REGULATION DATE THAT ENDED IN REGULATION DISAPPOINTMENT
13:55:21  <indutny>what's that?
13:55:43  <indutny>or _SC_PIPE
13:56:00  <indutny>nvm, better answer what's that _SC_THREAD_ROBUST_PRIO_INHERIT
13:56:25  <bnoordhuis>ah, that's a robust mutexes thing
13:56:31  <indutny>yeah
13:56:36  <indutny>it seems to be linux-only thing
13:56:36  <indutny>right?
13:56:51  <bnoordhuis>yep
13:56:56  <indutny>I'm just trying to figure out what values are shared between all implementations
13:57:06  <indutny>and really having a hard time here
13:57:12  <bnoordhuis>google 'sysconf opengroup' :)
13:57:18  <indutny>because of all BSD4.2 BSD4.4 POSIX1.b POSIX2 things
13:57:22  <indutny>and Suse
13:57:30  <indutny>so only those?
13:57:32  <indutny>at opengroup?
13:57:42  <bnoordhuis>yeah, that's what everyone implements
13:57:44  <indutny>oh crap
13:57:48  <indutny>there're a lot of them
13:57:48  <bnoordhuis>at least posix 2001
13:58:04  <bnoordhuis>*the posix 2001 version
13:58:36  <indutny>ok, now to figure out
13:58:42  <indutny>which are posix88
13:58:42  <indutny>:)
13:58:45  <bnoordhuis>hah
13:58:52  <bnoordhuis>there was no posix back then
13:59:01  <indutny>you think so?
13:59:17  <indutny>EEE Std 1003.1-1988
13:59:22  <indutny>IEEE Std 1003.1-1988
13:59:50  <indutny>well, this particular spec didn't contain sysconf
13:59:54  <indutny>probably...
13:59:59  <bnoordhuis>yeah, but posix.1 is so basic, you can't really do anything with it
14:00:09  <indutny>bnoordhuis: well yes
14:00:17  <indutny>I'm just adding this constants to rust headers
14:00:31  <indutny>and they've this stupid separation by posix88, posix01, etc groups
14:00:32  <bnoordhuis>it wasn't until 1994ish that it actually got usable
14:00:55  <bnoordhuis>for real? that's kind fo amusing :)
14:01:17  <bnoordhuis>tell them to stop worrying and learn to love posix 2001
14:02:01  <bnoordhuis>i mean, they support fewer platforms than we do, right?
14:02:31  <bnoordhuis>and all platforms libuv/node runs support posix 2001
14:02:34  <bnoordhuis>by and large, anyway
14:02:43  * papertigersjoined
14:02:47  <bnoordhuis>and excepting windows, of course
14:03:40  <indutny>:)
14:03:44  <indutny>surely yes
14:03:49  <indutny>that's just for classification
14:04:12  <indutny>I'm trying to contribute mman bindings for rust
14:04:20  <indutny>and just thought that it'd be cool to know page size as well
14:04:22  <indutny>and then...
14:04:23  <indutny>blah
14:04:27  <indutny>there're tons of _SC_* guys
14:04:40  <indutny>I especially love linux headers here
14:04:45  <bnoordhuis>yeah, but you probably only care about a few
14:04:45  <indutny>because they're not even defines here
14:04:51  <indutny>right
14:05:03  <bnoordhuis>at what header are you looking?
14:05:24  <bnoordhuis>the linux/glibc convention is to enum + define
14:05:38  <bnoordhuis>the enum because it makes for nice symbolic names in the debugger
14:05:48  <bnoordhuis>and the define so you can do feature detection easily
14:06:09  * papertigers_joined
14:06:56  <indutny>ok, I've counted them
14:07:03  <indutny>there're 215 different values
14:07:07  <indutny>for linux
14:07:07  <indutny>:)
14:07:32  * papertigersquit (Ping timeout: 256 seconds)
14:07:34  * papertigers_changed nick to papertigers
14:10:43  <indutny>this standards
14:10:44  <indutny>they're
14:10:45  <indutny>so fucked
14:10:57  <bnoordhuis>how so?
14:10:58  <indutny>why isn't posix specifying values for those confs
14:11:05  <bnoordhuis>why should it?
14:11:14  <indutny>its pretty nice that they start from 1 in BSD systems
14:11:17  <indutny>and from 0 in linux
14:11:18  <indutny>:)
14:11:28  * amartensjoined
14:11:33  <indutny>bnoordhuis: at least for this
14:11:50  <bnoordhuis>posix is about source compatibility, not binary compatibility
14:13:36  * st_lukejoined
14:15:45  * amartensquit (Ping timeout: 246 seconds)
14:19:16  <piscisaureus_>bnoordhuis: weird question maybe but - when does v8 actually do an int div?
14:25:02  * sakkakujoined
14:25:05  * pachetjoined
14:26:35  * sakkakuquit (Remote host closed the connection)
14:27:11  * sakkakujoined
14:27:28  <indutny>bnoordhuis: do you have freebsd at hand?
14:27:45  <indutny>ah, nvm
14:27:48  <indutny>found this header online
14:29:01  * sakkaku_joined
14:29:06  * sakkaku_quit (Remote host closed the connection)
14:29:31  <indutny>no
14:29:36  <indutny>I can't find it...
14:29:54  <indutny>bnoordhuis: if you have a freebsd machine - can you please gist header file containing _SC_PAGESIZE and friends
14:31:12  <indutny>nvm
14:31:14  <indutny>found it :_)
14:31:16  <indutny>now for real
14:31:17  <indutny>http://www.freebsd.org/cgi/cvsweb.cgi/src/include/unistd.h?rev=1.106;content-type=text%2Fplain
14:31:37  <indutny>oh and they finally have a good mapping
14:31:40  <indutny>year - value
14:32:34  * sakkakuquit (Ping timeout: 252 seconds)
14:37:25  * loladirojoined
14:42:12  <indutny>oh god
14:42:13  <indutny>I did it
14:42:54  * groundwaterquit (Ping timeout: 240 seconds)
14:43:03  * c4milojoined
14:46:15  * groundwaterjoined
15:11:49  * amartensjoined
15:15:56  * amartensquit (Ping timeout: 246 seconds)
15:21:00  * hzjoined
15:31:05  * perezdquit (Quit: perezd)
15:37:55  * groundwaterquit (Ping timeout: 268 seconds)
15:38:59  * bnoordhuisquit (Ping timeout: 260 seconds)
15:40:04  * groundwaterjoined
15:45:34  * kevinswiberquit (Remote host closed the connection)
15:51:28  * defunctzombie_zzchanged nick to defunctzombie
15:56:02  * groundwaterquit (Ping timeout: 240 seconds)
15:58:34  * groundwaterjoined
16:01:54  * amartensjoined
16:12:28  * loladiroquit (Quit: loladiro)
16:14:12  * dapjoined
16:15:31  * bnoordhuisjoined
16:23:55  * bajtosquit (Quit: bajtos)
16:26:16  * kazuponjoined
16:29:25  * loladirojoined
16:42:22  * csaohquit (Quit: csaoh)
16:42:32  * hzquit
16:49:54  * bnoordhuisquit (Ping timeout: 264 seconds)
17:03:13  <indutny>isaacs: hoi
17:03:16  <indutny>you there?
17:08:49  * HenryRjoined
17:09:55  <HenryR>piscisaureus_: Hi. Did you get a chance to review the PR?
17:12:30  * brsonjoined
17:13:24  * AvianFluquit (Remote host closed the connection)
17:13:29  <piscisaureus_>HenryR: yes I can live with it.
17:13:37  <piscisaureus_>HenryR: btw - /* TODO: track this malloc and free after request completes */ - that's not a todo
17:14:39  <piscisaureus_>HenryR: https://github.com/MSOpenTech/libuv/blob/67e4d2505d0dcf1f95f6d73d854c3f58cc8dba36/src/win/pipe.c#L1519 <-- the req is freed there
17:14:55  * kazuponquit (Remote host closed the connection)
17:15:14  <piscisaureus_>HenryR: there?
17:15:38  <HenryR>yes. You want me to remove that comment?
17:17:23  * TooTallNatejoined
17:18:51  * perezdjoined
17:20:15  <piscisaureus_>HenryR: do you still have push access?
17:20:21  * sblomjoined
17:20:23  <piscisaureus_>HenryR: that commit needs to go indeed.
17:20:30  <piscisaureus_>er, line
17:20:30  <piscisaureus_>...
17:20:44  <HenryR>piscisaureus_: No. Not to joyent.
17:21:00  <piscisaureus_>ok
17:21:57  <piscisaureus_>HenryR: I am going to land on master first. We can backport to v0.10 after the fix for node has also landed
17:22:33  <HenryR>piscisaureus_: OK. I will update the PR soon.
17:22:48  <piscisaureus_>HenryR: I can just remove the line, it's probably easier
17:22:49  <piscisaureus_>sec
17:26:54  <MI6>joyent/libuv: Henry Rawas master * 98f67e5 : windows: Enable blocking pipe for stdio. - http://git.io/6GgAmQ
17:27:02  <piscisaureus_>crap
17:27:05  * sblomquit (Ping timeout: 252 seconds)
17:27:22  <MI6>joyent/libuv: Ben Noordhuis master * b1d390e : windows: don't use uppercase in include filename - http://git.io/5Zz9jg
17:28:23  <HenryR>piscisaureus_: Why crap?
17:28:41  <piscisaureus_>I forgot to update the commit message
17:28:49  <piscisaureus_>so I'll reland in a minue
17:29:06  <tjfontaine>force pushes make the jenkins sad
17:32:15  <MI6>joyent/libuv: Henry Rawas master * 92040eb : stream: add an API to make streams do blocking writes - http://git.io/tH1MHA
17:32:19  <MI6>libuv-master: #124 UNSTABLE windows (3/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/124/
17:32:28  <piscisaureus_>tjfontaine: what happens to it
17:32:31  <piscisaureus_>HenryR: landed
17:32:47  <tjfontaine>piscisaureus_: it queues jobs and then when they run the sha isn't there any more
17:33:03  <tjfontaine>so big red FAILs appear
17:33:03  <HenryR>piscisaureus_: Great. Thanks. Any ETA for when the whole thing gets to 0.10?
17:34:01  <piscisaureus_>HenryR: I can do it any minute but I prefer to only do this once the API is actually used in node and it actually fixes the problem :)
17:34:35  <piscisaureus_>HenryR: that'll give me some more confidence that it's actually stable and working
17:34:52  <MI6>libuv-master-gyp: #61 UNSTABLE smartos-x64 (2/189) smartos-ia32 (2/189) windows-ia32 (3/190) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/61/
17:34:53  <piscisaureus_>HenryR: many people use node these days. I'd rather not introduce bugs on a stable branch .
17:34:54  <HenryR>piscisaureus_: Sure. But someone will ask when they will have it in 0.10. I just wondered if it will be 1 week or 1 month.
17:35:38  <tjfontaine>can they have it all in 0.10?
17:36:11  * qardjoined
17:36:23  <piscisaureus_>HenryR: so - that depends on when we can land a patch in node. It's that moment + 1.5 week.
17:36:46  <tjfontaine>we're allowed to add apis in stables?
17:36:59  <piscisaureus_>no actually not
17:37:03  <MI6>libuv-master: #125 UNSTABLE windows (4/190) smartos (4/189) linux (1/189) http://jenkins.nodejs.org/job/libuv-master/125/
17:37:27  <piscisaureus_>tjfontaine: but this won't change the ABI. It's just adding another symbol.
17:37:41  <piscisaureus_>tjfontaine: to combat a serious problem
17:37:51  <tjfontaine>I'm just trying to figure out where the line is
17:38:18  <tjfontaine>we've been pretty hard nosed in the past about when we can add a new api in a stable
17:38:58  * hzjoined
17:41:10  <MI6>libuv-master-gyp: #62 UNSTABLE smartos-x64 (2/189) smartos-ia32 (2/189) windows-ia32 (4/190) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/62/
17:41:15  * bajtosjoined
17:41:53  * c4miloquit (Remote host closed the connection)
17:42:17  <indutny>isaacs: yt?
17:51:58  * timoxleyjoined
17:52:57  * indexzerojoined
17:54:13  <MI6>libuv-node-integration: #117 UNSTABLE smartos-ia32 (3/604) linux-x64 (1/604) smartos-x64 (4/604) http://jenkins.nodejs.org/job/libuv-node-integration/117/
17:56:32  <trevnorris>morning
17:57:04  <tjfontaine>good day
17:59:11  * perezdquit (Quit: perezd)
17:59:30  * HenryRquit
18:04:02  <trevnorris>isaacs: re transition to bitbucket. i hate JIRA. one more time, I really really hate JIRA
18:04:23  <tjfontaine>so does isaacs for that matte
18:04:23  <tjfontaine>r
18:04:32  <trevnorris>i'm fine w/ their hosting, but I feel like the code hosting solution and the issue tracker solution don't have to be on the same domain.
18:04:33  <trevnorris>heh. ok
18:04:42  <tjfontaine>so it should signal just how much isaacs is frustrated with github atm
18:04:55  <trevnorris>lol. noted
18:04:55  <piscisaureus_>tjfontaine: wut? moving to bitbucker?
18:05:17  <tjfontaine>piscisaureus_: yesterday isaacs asked for general reaction to a possible move to bitbucket
18:05:28  <piscisaureus_>oh I missed that
18:05:36  <tjfontaine>it was probably after your bed time
18:06:22  <tjfontaine>I'm not particularly a fan of bitbucket, but I'm also not fussed, I'd rather use the threat as a means for github to have a real sit down with us and talk about the things their popular repositories need
18:06:53  <trevnorris>couldn't we move issue tracking elsewhere?
18:07:00  <isaacs>good morning
18:07:00  <trevnorris>that's my biggest complaint.
18:07:03  <isaacs>trevnorris: yeah, me too
18:07:03  <trevnorris>morning
18:07:10  * mikealjoined
18:07:14  <isaacs>indutny: pong
18:07:15  * Benviequit
18:07:19  <indutny>so
18:07:22  <indutny>isaacs: how are you doing? :)
18:07:32  <isaacs>pretty good
18:07:37  <isaacs>been busy with npm updates.
18:07:39  <tjfontaine>trevnorris: issue tracking/pull requests kinda go hand in hand of course, it's nice to have good integration at that level
18:07:48  <indutny>isaacs: ok, about npm
18:07:49  <isaacs>feels good, but i have to get back to node soon
18:08:08  <indutny>is your solution about private_users db opensource?
18:08:16  <indutny>err
18:08:22  <indutny>public_users
18:08:31  <isaacs>indutny: i dont' think it is
18:08:49  <isaacs>indutny: i need to clean it up a bit, like, create a new git repo that doesn't have paswords in the history
18:08:58  <indutny>ah
18:08:59  <isaacs>and make it more configurable
18:09:02  <indutny>well
18:09:04  <trevnorris>tjfontaine: agreed. but I'd have to assume there're other solutions that integrate w/ github hosting
18:09:08  <indutny>I'd be really glad if you'll share it with me
18:09:12  <indutny>privately or whatever
18:09:22  <indutny>if its possible
18:09:41  <tjfontaine>trevnorris: where "github hosting" is really just .git
18:10:03  * Benviejoined
18:10:30  <trevnorris>tjfontaine: well, they also have the forking mechanism, and the wiki. also their useless but cool Pulse thing.
18:10:59  <indutny>isaacs: I've figured out everything except replicating it without salts
18:11:01  <indutny>and passwords
18:11:12  <trevnorris>tjfontaine: i mean, fogbugz integrates really well. but for the price they better fly out and give me a foot massage every day.
18:11:21  <indutny>and I can definitely do it myself, but just curious if its something that you may want share with me
18:12:00  <isaacs>indutny: i'll push something today
18:12:07  <indutny>ok, that's great
18:12:09  <isaacs>indutny: just need to rm -rf .git and then git init
18:12:14  <indutny>is it like patch to couchdb?
18:12:17  <isaacs>no
18:12:19  <isaacs>it's just a follow script
18:12:20  <indutny>or just custom replicator?
18:12:22  <indutny>ah
18:12:23  <isaacs>yeah
18:12:26  <indutny>that's what I thought
18:12:28  <indutny>great!
18:12:29  <isaacs>you can actually look at the code now
18:12:31  <tjfontaine>trevnorris: you'll have to explain to me how you define "integrate"
18:12:36  <isaacs>indutny: ssh node@nodejs.org
18:12:42  <isaacs>indutny: it's in the `npm-users-db` folder
18:12:50  <isaacs>er, wrong server
18:12:55  <isaacs>indutny: ssh node@npmjs.org
18:13:01  <isaacs>indutny: i think your key works
18:13:06  <isaacs>indutny: if not, your key works as root
18:13:07  <indutny>don't tell me I have access to it
18:13:11  <isaacs>indutny: yeah
18:13:14  <indutny>oh god
18:13:15  <indutny>I've
18:13:16  <isaacs>NodeCore, baby
18:13:22  <indutny>:)
18:13:32  <indutny>ouch
18:13:35  <indutny>pretty big thing
18:13:40  <isaacs>yeah, and ugly!
18:13:49  <isaacs>it's a total "get er done" script
18:13:55  <isaacs>not very pretty or modular or anything
18:14:02  <indutny>:)
18:14:10  <indutny>I think I have another solution for this problem
18:14:14  <isaacs>ok
18:14:15  <indutny>I'll patch couchdb itself
18:14:19  <isaacs>hhahaha
18:14:23  <isaacs>that's bigger and uglier, i'll bet :)
18:14:29  <indutny>not really bigger
18:14:37  <indutny>they already have engine for mapping documents
18:14:44  <indutny>and doing it for _replicator and _users database
18:14:45  <indutny>so...
18:14:50  <indutny>I guess it might work
18:14:59  <isaacs>indutny: yeah, yo'ud have to make it allowed to GET a /_users doc that isn't yours, but have it know what to filter out
18:15:02  <MI6>libuv-node-integration: #118 UNSTABLE smartos-ia32 (2/604) linux-ia32 (1/604) smartos-x64 (5/604) http://jenkins.nodejs.org/job/libuv-node-integration/118/
18:15:02  <indutny>but in any case I'll probably stick to your solution
18:15:05  <indutny>isaacs: yep
18:15:08  <isaacs>indutny: instead of passing a 404
18:15:17  <indutny>I've already figured it out :)
18:15:19  <indutny>but thanks
18:15:20  <isaacs>indutny: you'll meet with resistance pushing upstream
18:15:26  <indutny>nooo
18:15:28  <indutny>no way :)
18:15:30  <indutny>that's proprietary
18:15:41  <isaacs>indutny: also, note that the vhost needs to point to /registry/_design/ghost instead of /registry/_design/app
18:15:47  <indutny>yeah
18:15:48  <isaacs>indutny: for your registry
18:15:50  <indutny>I've figured out that too
18:15:56  <isaacs>kewl
18:15:58  <indutny>I'm running for quite long time now
18:16:07  <indutny>but that's first time I've met npm owner add problem
18:16:17  <isaacs>does voxer have their own registry?
18:16:31  <indutny>nope, that's some legacy from my previous jobs
18:16:36  <indutny>helping out yandex with old stuff
18:16:48  <isaacs>ah, gotcha
18:17:05  <trevnorris>tjfontaine: similar functionality as github. milestones, integration w/ commits and issue tracking, etc.
18:17:14  <indutny>isaacs: thank you!
18:17:34  <isaacs>np
18:17:58  * perezdjoined
18:18:12  <tjfontaine>trevnorris: I understand the basics of an issue tracker, I'm interested to know what "integration" you would need with github
18:19:17  <tjfontaine>trevnorris: I presume you mean closing via post commit hooks, which is a pretty trivial feature
18:20:41  * sblomjoined
18:21:00  <trevnorris>tjfontaine: honestly I wouldn't want much. track PR's against issues (except allow explicit linking), close PR's, also I like how you only need to type part of the hash to link to a commit.
18:21:11  <trevnorris>but that last one's fluff
18:21:14  <tjfontaine>trevnorris: so you would expect PRs to stay on the github side
18:22:29  <trevnorris>tjfontaine: honestly I wouldn't care if we used "git format-patch" and sent it on a mailing list, but I think the community would work best keeping PR's on github
18:22:59  <tjfontaine>the community does best without change
18:23:25  <trevnorris>true
18:23:40  <trevnorris>heh, 157d2bc was unexpected.
18:23:41  <tjfontaine>but the community will survive even if we dont' use github
18:23:42  <isaacs>it's not a firm plan
18:24:04  * c4milojoined
18:24:28  <trevnorris>isaacs: I really don't care. I have the same username already registered on bitbucket.
18:24:42  <trevnorris>that's really all I'd care about :P
18:25:23  * kazuponjoined
18:25:39  * sblomquit (Ping timeout: 268 seconds)
18:30:32  * kazuponquit (Ping timeout: 246 seconds)
18:32:09  <isaacs>revyeah
18:32:11  <isaacs>trevnorris: yeah
18:32:25  <isaacs>^ tab complete mixups make me realize how little i actually can type
18:32:51  <tjfontaine>heh
18:40:32  * timoxleyquit (Quit: Computer has gone to sleep.)
18:41:03  * sblomjoined
18:42:08  <indutny>isaacs: btw, you might like my solution as well ;)
18:42:11  <indutny>with patched couchdb
18:42:22  <isaacs>rly
18:42:23  <indutny>this way you'll be able to use just replication
18:42:29  <isaacs>indutny: talk to jason smith about it
18:42:30  <indutny>without running any external stuff
18:42:39  <indutny>ok :)
18:44:47  * bnoordhuisjoined
18:45:48  * sblomquit (Ping timeout: 267 seconds)
18:47:55  * c4miloquit (Remote host closed the connection)
18:48:00  * bnoordhuisquit (Read error: Operation timed out)
18:50:32  <trevnorris>isaacs: reason why StringBytes::Encode returns <Value> instead of <String>?
18:50:40  <trevnorris>tjfontaine: figure out the win x64 ascii thing?
18:52:26  <tjfontaine>trevnorris: it landed last night, just changed how we detect x64
18:52:43  <trevnorris>tjfontaine: coolio. love those strange bugs. :P
18:52:53  <tjfontaine>painful.
18:53:04  * AvianFlujoined
18:53:18  <isaacs>trevnorris: because you can encode as "buffer"
18:53:27  <isaacs>trevnorris: i don't know, i'm guessing
18:53:30  <isaacs>did i win the prize?
18:53:38  <trevnorris>isaacs: ah, duh.
18:53:45  <trevnorris>isaacs: thanks. totally missed that. :)
18:55:14  <trevnorris>man. ben's style corrected so much of my code feel like he's in my head while reviewing this pr.
18:57:20  <isaacs>haha
18:59:37  <indutny>isaacs: here it goes https://gist.github.com/indutny/9bd93eb6e091943dae7c
18:59:54  <indutny>40 lines instead of a lot of stuff
19:00:17  <trevnorris>lunch
19:00:19  * trevnorris&
19:00:20  <LOUDBOT>I FIGURED THAT IS WHAT YOU MEANT, AFTER THE FACT. BUT YOU LIED TO ME!
19:00:41  <trevnorris>I WOULD NEVER LIE TO YOU LOUDBOT!
19:00:42  <LOUDBOT>NOT EVERYTHING NEEDS TO USE JSON, SON!
19:01:34  <isaacs>indutny: so that just shows the id, revs, and _deleted?
19:01:39  <isaacs>indutny: what about all the other stuff on the user doc?
19:01:40  <indutny>yes
19:01:46  <indutny>do you need anything else?
19:01:47  <isaacs>indutny: what abut "email" or "fullName"
19:01:49  <isaacs>yes, i need all of it
19:01:52  <indutny>ah
19:01:52  <isaacs>except the private stuff
19:01:55  <indutny>all except salt
19:01:59  <indutny>and hash
19:02:00  <indutny>gosh :(
19:02:13  <isaacs>indutny: salt, hash, bcrypt, iterations, and "x-csrf-token"
19:02:32  <indutny>wow
19:02:36  <indutny>oook
19:02:39  <isaacs>indutny: otherwise i can't look up your email address to add you as a maintainer
19:03:18  <indutny>yeah
19:03:21  <indutny>just figured that out :)
19:19:05  * bajtosquit (Quit: bajtos)
19:25:10  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:26:51  * bnoordhuisjoined
19:28:12  * c4milojoined
19:36:06  * perezdquit (Quit: perezd)
19:36:29  <indutny>isaacs: https://gist.github.com/indutny/9bd93eb6e091943dae7c
19:36:31  <indutny>figured it out
19:36:39  <indutny>with a bit erlang pain
19:36:47  <indutny>:)
19:38:55  * piscisaureus_quit (Read error: Connection reset by peer)
19:45:00  * st_lukequit (Remote host closed the connection)
19:54:28  * TooTallNatejoined
20:00:15  * sblomjoined
20:05:26  * bajtosjoined
20:08:22  <tjfontaine>isaacs: man your communication on isaacs/github#42 is depressing
20:09:54  * bajtosquit (Client Quit)
20:10:18  * AvianFluquit (Read error: Connection reset by peer)
20:10:57  * AvianFlujoined
20:19:49  <isaacs>yeah
20:19:51  <isaacs>for real
20:24:10  * sblom_joined
20:25:44  * sblomquit (Ping timeout: 255 seconds)
20:29:16  * trevnorrisfg
20:30:38  <bnoordhuis>quiet everyone, trevor's back
20:30:51  <tjfontaine>oh stop talking about him
20:30:52  <trevnorris>wha? what'd I miss?!?
20:31:10  <tjfontaine>everything that happened when slurp had died
20:31:14  <tjfontaine>:P
20:31:41  <trevnorris>heh, good thing I have that persistent connection you kept bugging me about ;)
20:31:48  <tjfontaine>:)
20:31:52  <trevnorris>anyone for quick review? 5604
20:32:56  <trevnorris>bnoordhuis: gave that three rounds of syntax changes, so hopefully I covered anything you would've mentioned. :)
20:33:22  <bnoordhuis>trevnorris: always have the lowest barrier to entry when you want a review
20:33:41  <bnoordhuis>that is, paste a link so i don't have to look up the issue by hand :)
20:33:45  * groundwaterquit (Ping timeout: 246 seconds)
20:33:50  <trevnorris>lol, ok. https://github.com/joyent/node/pull/5604
20:34:13  <bnoordhuis>ah, the spkac thing? why the interest?
20:35:03  <trevnorris>not sure why I started reviewing it. but now that I've put him through so much figured might as well wrap it up.
20:36:13  * groundwaterjoined
20:36:32  <bnoordhuis>looking
20:37:05  <trevnorris>man, how had I not used curl ... | git am before. way easier than adding a remote repo.
20:38:25  <isaacs>TooTallNate: Hey, can you git push to node-gyp?
20:38:30  <isaacs>TooTallNate: i have a patch for you
20:38:40  <TooTallNate>isaacs: ya sure
20:38:43  <isaacs>TooTallNate: i see that 0.10.0 is on npm, but git says 0.9.something
20:39:29  <TooTallNate>isaacs: fixed!
20:39:45  <TooTallNate>oh no, still not :\
20:40:40  <TooTallNate>isaacs: oh wait, ya should be good to go now
20:41:40  <isaacs>k
20:41:43  <isaacs>got it
20:44:09  <isaacs>TooTallNate: ack, wait don't merge that yet
20:44:53  <TooTallNate>ok :)
20:45:15  <isaacs>TooTallNate: 61c4f592642646a5043e5033c95ab7573b8a44fb is good
20:45:40  <isaacs>TooTallNate: not sure if you like to have the updates to use semver2 be a separate commit or not
20:45:47  <isaacs>but they're breaking changes, so i just included it
20:45:59  * piscisaureus_joined
20:45:59  <TooTallNate>ya that's fine with me
20:46:06  <TooTallNate>i don't even remember what i usually do :p
20:46:19  * perezdjoined
20:48:38  <TooTallNate>isaacs: merged, and published v0.10.1 for you
20:49:20  <TooTallNate>isaacs: much cleaner code now too :)
20:49:28  <TooTallNate>using semver, i mean
20:49:31  <isaacs>yeah
20:49:50  <isaacs>it's using an actual SemVer class now
20:49:58  * sblomjoined
20:50:06  <TooTallNate>oh nice
20:50:16  <isaacs>you can actually use the parsed version like that, too: var v = semver.parse(versionStr); if (v.gt('0.2.3')) ...
20:50:30  <isaacs>instead of semver.gt(v, '0.2.3')
20:51:36  <TooTallNate>instance methods ftw!
20:51:38  * sblom_quit (Ping timeout: 246 seconds)
20:51:58  <TooTallNate>isaacs: thats good too because i would always fuck up the order of the static version :p
20:52:14  <isaacs>yeah
20:52:34  <isaacs>or var r = semver.Range('>2.1.3 <6.5.3'); if (r.test(version)) { ... }
20:52:44  * paddybyersquit (Ping timeout: 255 seconds)
20:53:27  * hzquit
20:55:33  <tjfontaine>cute
20:56:56  <indutny>yikes
20:57:03  <indutny>after hours of messing with this fucking erlang thing
20:57:06  <indutny>I got it running again :P
20:57:15  <indutny>hopefuly it'll work fine
20:57:27  <bnoordhuis>erlang? do tell
20:59:22  <isaacs>indutny: you know, what would be really best is if there didn't have to be a public_users at all
20:59:34  <isaacs>indutny: just have that logic there to hide the security stuff when viewiing the doc in _users
20:59:39  <isaacs>indutny: rather than sending a 404
21:05:02  * defunctzombiechanged nick to defunctzombie_zz
21:06:20  * pachetquit (Quit: leaving)
21:09:21  <trevnorris>bnoordhuis: are declared, but un-assigned, variables guaranteed to be NULL until they've been assigned something? or do you explicitly have to .. = NULL;
21:12:55  <indutny>isaacs: yes
21:12:56  <indutny>I agree
21:13:06  <indutny>I can do it as well
21:13:13  <isaacs>indutny: also, it should be a config
21:13:20  <isaacs>indutny: and should be sent upstream
21:13:23  <indutny>haha
21:13:33  <isaacs>and should be how it's always worked in the first place.
21:13:35  <isaacs>;)
21:13:44  * isaacsheading out to tacos
21:14:29  <bnoordhuis>trevnorris: variables with static storage (static, global)=yes. automatic storage=no
21:14:42  <trevnorris>cool. thanks.
21:23:21  <bnoordhuis>https://github.com/joyent/node/pull/5726 - review anyone? it's a oneliner and it has a funny commit log
21:23:31  <bnoordhuis>trevnorris: ^ that's how you reel in reviewers
21:23:54  * piscisaureus_quit (Ping timeout: 240 seconds)
21:24:19  <trevnorris>heh
21:24:29  <trevnorris>bnoordhuis: lgtm. and to be honest I like the commit msg
21:24:49  <bnoordhuis>okay, i'll leave it like that :)
21:25:49  <MI6>joyent/node: Ben Noordhuis master * b255f4c : child_process: emit 'disconnect' asynchronously - http://git.io/Gx_msA
21:26:26  <trevnorris>bnoordhuis: have any initial thoughts on https://github.com/joyent/node/pull/5720
21:26:51  <trevnorris>(not urgent, just curious)
21:28:58  <indutny>isaacs: yes! https://gist.github.com/indutny/5826819
21:31:03  <bnoordhuis>trevnorris: my precious slab allocator? :(
21:32:05  * c4miloquit (Remote host closed the connection)
21:33:09  <trevnorris>bnoordhuis: i'm sorry dude. :(
21:33:59  <indutny>isaacs: yt?
21:34:02  <indutny>or still at taco shop
21:34:20  <tjfontaine>https://github.com/tjfontaine/node/compare/joyent:v0.10...http-client-request if anyone cares to review
21:36:45  <bnoordhuis>trevnorris: return uv_buf_init(new char[suggested_size], suggested_size) <- that means it always news a 64k chunk
21:37:57  <trevnorris>bnoordhuis: yeah. but slaballocator needs to assign several object properties. the perf hit cancels each other out.
21:38:22  <trevnorris>bnoordhuis: even under heavy load perf still shows that around 5-10% total usage.
21:38:55  * paddybyersjoined
21:40:22  * rendarquit
21:40:25  <trevnorris>bnoordhuis: w/ those changes there's only ~5% hit for requests under 1KB. after that it's comparable.
21:40:30  <bnoordhuis>trevnorris: on what os have you benchmarked that?
21:40:38  <trevnorris>linux :)
21:41:13  <bnoordhuis>hrm, i'm hard-pressed to believe there's no noticeable impact
21:41:31  <trevnorris>sec. i'll throw up the numbers.
21:43:22  <trevnorris>bnoordhuis: the kicker is if you use the new buffer.dispose() directly on the buffer object after the operation's complete there's a massive gain.
21:43:55  <trevnorris>i wouldn't worried about the slab allocator as much except I couldn't get .dispose() to work w/ it around.
21:48:04  * piscisaureus_joined
21:49:18  <trevnorris>bnoordhuis: some simple values: https://gist.github.com/trevnorris/5827001
21:49:42  <trevnorris>bnoordhuis: generating more now. at least on my system there's a small hit, but not as much as you'd think.
21:51:09  <trevnorris>oh, and ignore values that are drastically different.
21:51:29  <trevnorris>ooh, you just gave me a perf improvement idea. :)
21:52:15  <bnoordhuis>trevnorris: perf as in the tool?
21:52:32  <trevnorris>bnoordhuis: yeah. I wanted to see how much a hit malloc was costing so I used perf.
21:52:44  <trevnorris>bnoordhuis: though I probably didn't use all the right options. :P
21:54:23  <trevnorris>bnoordhuis: oh, sorry. no last comment as in perf -> performance.
21:54:45  <trevnorris>sorry, really suck at reading comments and coding simultaneously.
21:55:38  * defunctzombie_zzchanged nick to defunctzombie
21:55:47  * AvianFluquit (Read error: Connection reset by peer)
21:55:58  <indutny>ircretary: tell isaacs that I did it… but it won't work for /-/users, because it would be too complex to implement. Considering that its used only for autocompletion, I can only suggest you to remove it ;)
21:55:58  <ircretary>indutny: I'll be sure to tell isaacs
21:56:21  * AvianFlujoined
21:56:46  <indutny>ttyl
21:56:47  * indutny&
21:56:47  <LOUDBOT>WELL ALRIGHT THEN I GUESS I WILL.
21:56:55  <tjfontaine>heh
21:57:00  <bnoordhuis>trevnorris: what kind of linux system is that? spec-wise, i mean?
21:57:28  <MI6>nodejs-master: #271 UNSTABLE smartos-x64 (9/604) linux-ia32 (4/604) osx-x64 (2/604) osx-ia32 (3/604) smartos-ia32 (4/604) linux-x64 (3/604) http://jenkins.nodejs.org/job/nodejs-master/271/
21:58:47  <trevnorris>bnoordhuis: i7-2860QM, 8gb ram
21:59:02  <bnoordhuis>okay, thanks
21:59:05  <trevnorris>yup
21:59:31  <trevnorris>oh, and PC3-10600 1333MHz DDR3
21:59:54  * piscisaureus_quit (Read error: Connection reset by peer)
22:00:33  * piscisaureus_joined
22:02:37  * mikolalysenkojoined
22:04:33  <mikolalysenko>hi, I heard rumors there was going to be a rewrite of buffers in the next iteration of node?
22:05:01  <tjfontaine>"rewrite" there's a signficant refactor that has landed in master branch
22:05:08  <mikolalysenko>hmm
22:05:26  <MI6>nodejs-master-windows: #80 UNSTABLE windows-x64 (23/604) windows-ia32 (19/604) http://jenkins.nodejs.org/job/nodejs-master-windows/80/
22:05:36  <mikolalysenko>then it may be too late, but I was going to offer a humble suggestion which was to remove the array accessors from the buffer class
22:05:53  <mikolalysenko>since having them there makes it impossible to wrap efficiently in a browser environment
22:06:04  <bnoordhuis>array accessors? you mean buf[i]?
22:06:07  <mikolalysenko>yeah
22:06:12  <mikolalysenko>use buf.get() / buf.set()
22:06:28  <bnoordhuis>actually, it's .get and .set that are deprecated :)
22:06:33  <mikolalysenko>since js has no operator overloading, they are not easily implementable in that environment
22:06:41  <mikolalysenko>:(
22:07:01  <Raynos>:( * 2
22:07:06  <mikolalysenko>it also kind of undermines the whole point of using js which was to have code that works the same in both the server and the browser
22:07:33  <tjfontaine>this is for your benefit, you should use typed arrays at that point
22:07:35  <mikolalysenko>however if you have modules that use magical v8 specific stuff that you can't wrap in native js, then I don't see how you can share the code between the two environments
22:07:39  <bnoordhuis>you can probably mock up something with arrays (typed or not)
22:07:41  <tjfontaine>the semantics are different enough that you shouldn't conflate them
22:07:45  <mikolalysenko>well, I agree with this point
22:07:51  <mikolalysenko>I think typedarrays are better
22:07:59  <mikolalysenko>but some code still uses buffers for whatever reason
22:07:59  <tjfontaine>I don't, but for codesharing, ok
22:08:01  <trevnorris>eh. if Buffers were to act like anything, they'd act like a Uint8Array, which do have array accessort.
22:08:09  <trevnorris>s/accessort/accessors
22:08:15  <mikolalysenko>yeah, but they have other stuff that typedarrays don't have
22:08:17  <mikolalysenko>like slice for example
22:08:31  <mikolalysenko>and typedarrays have subarray that buffers don't have
22:08:38  <trevnorris>...
22:09:00  <tjfontaine>bnoordhuis: any complaints against that dtrace change?
22:09:07  <trevnorris>mikolalysenko: http://slid.es/trevnorris/buffer-bending
22:09:12  <bnoordhuis>tjfontaine: haven't looked yet
22:09:15  <tjfontaine>mk
22:09:45  <bnoordhuis>but give me a sec
22:10:12  <mikolalysenko>trevnorris: I'm not arguing against having buffers, just saying that the api should be changed to something that is consistent/implementable in native js
22:10:25  <bnoordhuis>tjfontaine: maybe expand in the commit log on what it fixes
22:10:33  <tjfontaine>alrighty
22:10:41  <trevnorris>mikolalysenko: how is having array accessors not any of those?
22:11:05  <mikolalysenko>trevnorris: because js has no way to implement those short of adding stuff to a typed array
22:11:10  <mikolalysenko>and then you can't implement slice correctly
22:11:14  <bnoordhuis>mikolalysenko: it's not going to happen. too much existing code
22:11:16  <mikolalysenko>or other features
22:11:21  <tjfontaine>I think the ship has pretty well sailed on that because of legacy use
22:11:22  <mikolalysenko>:(
22:11:28  <mikolalysenko>yeah, that sucks then
22:11:35  <mikolalysenko>ok, figured I'd try
22:11:47  <tjfontaine>thanks, have another free spin
22:11:47  <indutny>ohai
22:11:51  <indutny>are you urkainian?
22:11:57  <indutny>mikolalysenko: ^
22:11:59  <indutny>just curious
22:12:06  <mikolalysenko>parents are, I grew up in the us
22:12:14  <mikolalysenko>or my dad more specifically
22:12:16  <indutny>ah, nice!
22:12:28  <indutny>you've my respect, man
22:12:39  <mikolalysenko>because I have a ukrainian dad?
22:12:45  <mikolalysenko>that is a strange standard for respect...
22:12:47  <indutny>just kidding
22:13:18  <trevnorris>bnoordhuis: is there any way to resize buf.base w/o a potential memcpy? leaving upwards of 64KB hanging out there kinda sucks. (hence I get your use of the slab allocator ;)
22:13:52  <mikolalysenko>also I just paged through those slides and regardind typed arrays there are some issues with the way they are protrayed in those slides
22:13:54  * piscisaureus_quit (Ping timeout: 240 seconds)
22:14:04  <bnoordhuis>trevnorris: yeah. use malloc/realloc/free :)
22:14:05  <mikolalysenko>it is true that allocating them is slow, but you can do simple things like pool and reuse them
22:14:15  <trevnorris>bnoordhuis: ok. if that's what's needed then I will :)
22:15:02  <trevnorris>mikolalysenko: pooling is already done, which means it's still going to be much faster. and you can't "reuse" them the way you think. the pooling only works because we can get around setting a Persistent/MakeWeak on every object that has data
22:15:11  <trevnorris>by setting the object property on the allocated object back to the parent.
22:15:32  <mikolalysenko>well, you pool the typedarray instance that is created in js
22:15:51  * perezdquit (Quit: perezd)
22:16:13  <mikolalysenko>once a typedarray object is allocated there isn't much overhead to using it at run time, but this is a user issue not a node thing
22:16:31  <mikolalysenko>also I see no reason why the implementation of typedarrays can't improve in the future
22:16:44  <bnoordhuis>well, it needs to happen first...
22:16:48  <trevnorris>mikolalysenko: what you're missing is that even w/ pooling we have to create many many new buffers for I/O heavy applications
22:16:54  <bnoordhuis>the typed arrays implementation that ships with node is only so-so
22:17:10  <bnoordhuis>the experimental implementation in v8 still needs a fair bit of work
22:17:17  <trevnorris>mikolalysenko: it can't. they need to zero fill the memory before handing it off.
22:17:19  <bnoordhuis>for one, it doesn't implement DataView
22:17:38  <trevnorris>bnoordhuis: I built a custom v8 removing the memset, and instantiation for size 0xffff was 5x's faster.
22:17:40  <bnoordhuis>they're probably also going to make some awkward changes from a performance perspective to be able to support neutering
22:17:43  <mikolalysenko>trevnorris: there are user space solutions to the zero fill and initialization problems though
22:17:58  <mikolalysenko>like you can cache the typedarrays in javascript, not in the system
22:18:07  <mikolalysenko>*err node internals
22:18:32  <trevnorris>erm. ok. you implement it and we'll do benchmark comparisons. :)
22:18:43  <mikolalysenko>done: https://github.com/mikolalysenko/typedarray-cache-experiment
22:18:57  <mikolalysenko>I don't have a comparison for buffers yet, but it would be easy to add it
22:20:49  <mikolalysenko>if initializing typedarrays is so bad, you could get around it by creating an internal method that just allocates them quickly without initializing them
22:21:03  <mikolalysenko>that would be easy to shim on a browser too, much more so than buffers are right now
22:21:48  <bnoordhuis>^ this is a somewhat pointless discussion, i'm afraid, because buffers aren't going away anytime soon
22:21:59  <trevnorris>i don't get this cross js stuff. there's a small subset of js that is cross compatible, and if you want it that way then use the subset.
22:22:12  <mikolalysenko>bnoordhuis: yeah, but I think that at least their use should be discouraged
22:23:24  <bnoordhuis>that's rather hard to do when just about everything in node returns a buffer...
22:23:30  <mikolalysenko>yeah :(
22:23:56  <mikolalysenko>but it is a bit crazy that everything uses buffers, since the whole selling point for using js was that you could share code between your server and browser
22:24:07  <mikolalysenko>and I understand the historical reasons for creating buffers, and they were sound
22:24:24  <mikolalysenko>but today typedarrays seem to me like they are a better option
22:24:54  <bnoordhuis>except for that pesky little backwards compatibility thing
22:25:02  <mikolalysenko>bnoordhuis: absolutely agree
22:25:30  <bnoordhuis>maybe in node 2.0 :)
22:25:32  <mikolalysenko>but I think that going forward it is worth thinking about how to move away from them
22:25:38  <mikolalysenko>haha, yeah right :P
22:26:10  <mikolalysenko>anyway, the only reason I even bothered to show up was that Raynos mentioned to me that there was a buffer rewrite, so I figured that if they were up for discussion then that I would try to add my 2cents
22:26:33  <bnoordhuis>noted but it's not something we can act on
22:26:43  <mikolalysenko>yeah, I totally understand
22:26:54  * paddybyersquit (Ping timeout: 240 seconds)
22:27:11  <mikolalysenko>do you guys know if there will be plans to support typedarrays and buffers more inclusively moving forward?
22:27:29  <mikolalysenko>so that at least for non-legacy code we have the option of building more portable stuff
22:28:41  <bnoordhuis>mikolalysenko: well... yes but then again maybe no
22:28:58  <bnoordhuis>we ship our own typed arrays implementation right now
22:29:05  <bnoordhuis>and that's great because it's malleable
22:29:21  <bnoordhuis>but eventually i want to move over to v8's native implementation
22:29:49  <bnoordhuis>which unfortunately is a little less flexible from a c++ api perspective
22:29:56  <mikolalysenko>maybe buffers could get a secret toUint8Array() method that converts them to a typedarray?
22:30:08  <bnoordhuis>it's probably going to be something like that, yes
22:30:25  <trevnorris>that's doable.
22:30:28  <mikolalysenko>ok, cool
22:30:42  <mikolalysenko>it would also be pretty easy to wrap on a browser
22:30:59  <trevnorris>but also that'd be easy to do in user-land
22:31:05  <mikolalysenko>yeah
22:31:08  <trevnorris>not that it _couldn't_ end up in core
22:31:18  <mikolalysenko>but the advantage to doing it in core is that you could share memory
22:31:18  <trevnorris>but if you want it any time in the near future, best done there for now
22:31:21  <mikolalysenko>so avoid a copy
22:31:29  <trevnorris>you can do that in user-land
22:31:34  <mikolalysenko>really?
22:31:59  <trevnorris>ok. sort of. i'm working on a patch that would make that do-able
22:32:09  <trevnorris>for the copy, yes. that can be done right now.
22:33:16  <trevnorris>bnoordhuis: so it's fine to realloc if I switch up to use malloc/free?
22:33:21  <trevnorris>(just want to double check)
22:33:32  * papertigersquit (Quit: papertigers)
22:35:05  <isaacs>ircretary: tell piscisaureus Can you remove this file from the IRC logs? http://logs.nodejs.org/nodejitsu/2013-05-20 Asking for a friend.
22:35:05  <ircretary>isaacs: I'll be sure to tell piscisaureus
22:35:09  * perezdjoined
22:35:28  <trevnorris>mikolalysenko: actually, using the original mem is do-able right now.
22:35:30  <isaacs>ircretary: thanks
22:35:30  <ircretary>isaacs: You're welcome :)
22:35:41  <bnoordhuis>trevnorris: yes. make sure you do proper NULL checks though
22:36:07  <trevnorris>bnoordhuis: you mean after every malloc? (not sure of all the proper conventions)
22:36:36  <trevnorris>ok, yeah. see that in the docs.
22:36:57  <trevnorris>so if malloc returns NULL, do I just attempt to malloc again? no idea how to handle that...
22:37:10  <bnoordhuis>trevnorris: if malloc returns NULL, you're dead
22:37:23  <trevnorris>ah, ok.
22:37:31  <bnoordhuis>well, node would be. i'd just call FatalException()
22:38:03  <trevnorris>thanks. (would have used abort)
22:38:14  <bnoordhuis>maybe not FatalException(). you'll probably have to add a FatalError() function
22:38:26  <bnoordhuis>abort() works as well but it's not so nice from an end user perspective
22:38:35  <bnoordhuis>it doesn't tell you why the process aborted
22:39:01  <trevnorris>could I fprintf beforehand and just print a message?
22:39:14  <trevnorris>though on fatal error is nice because you can hook into that from v8
22:39:24  <bnoordhuis>both would work
22:39:29  <trevnorris>ok :)
22:39:37  <bnoordhuis>btw, malloc and realloc have a peculiarity
22:39:57  <bnoordhuis>if size or new_size is 0, it's implementation-dependent if the return value is NULL
22:40:17  <trevnorris>oy. so I'll need to check both. thanks.
22:40:18  * mikealquit (Quit: Leaving.)
22:40:22  <bnoordhuis>i mention it because most man pages don't :)
22:40:42  <trevnorris>you seriously are the fountain of all c knowledge. thanks.
22:41:24  <trevnorris>bnoordhuis: so if size == 0 and return is NULL, do I still die or just continue?
22:45:35  <trevnorris>bnoordhuis: thanks a bunch. one of the huge improvements is that we can propagate the encoding all the way down and then create (external) strings directly.
22:48:46  * defunctzombiechanged nick to defunctzombie_zz
22:56:31  * c4milojoined
22:57:13  <bnoordhuis>trevnorris: well, if size=0 you don't really have to alloc anything. you wouldn't ever write to it anyway
22:57:24  <trevnorris>good point.
22:58:01  <trevnorris>so it seems while you can hood fatal errors in v8, they don't expose a way to throw one. just exceptions, but those won't happen since wouldn't be revisiting js.
22:58:58  <trevnorris>bugger. why couldn't they expose FatalProcessOutOfMemory
23:01:10  * indexzeroquit (Quit: indexzero)
23:01:36  <trevnorris>oh, wait. i'm a dork. it just calls OnFatalError in node.cc
23:06:32  * mikolalysenkoquit (Ping timeout: 260 seconds)
23:10:58  * AvianFluquit (Read error: Connection reset by peer)
23:11:21  * AvianFlujoined
23:20:23  * groundwaterquit (Ping timeout: 246 seconds)
23:24:12  * groundwaterjoined
23:24:39  * loladiroquit (Quit: loladiro)
23:32:47  <trevnorris>bnoordhuis: will uv_alloc_cb every pass a suggested size of 0?
23:32:58  * piscisaureus_joined
23:33:43  <tjfontaine>trevnorris: right now it's always 64k, but if it were to ever pass less I can't imagine it would send 0, but be defensive regardless
23:34:23  <trevnorris>tjfontaine: hm. but then what do I pass if size is 0, NULL?
23:35:17  <tjfontaine>I'd probably say assert, because that shit aint right, alloc of 0 doesn't make sense :P
23:35:33  <tjfontaine>you should ask piscisaureus_ though
23:35:46  <trevnorris>piscisaureus_: you asleep yet?
23:35:47  <trevnorris>probably
23:36:06  <piscisaureus_>trevnorris: no I am walking on my gums
23:36:10  <trevnorris>heh
23:36:18  <piscisaureus_>(freely translating a dutch proverb)
23:36:31  <piscisaureus_>writing down this great domains idea I have :)
23:36:37  <tjfontaine>oh boy
23:36:39  <trevnorris>lol
23:37:05  <trevnorris>piscisaureus_: i'm wondering if suggested_size on uv_alloc_cb would ever be 0
23:37:25  <trevnorris>like, should I bother writing checks for that
23:37:26  <piscisaureus_>trevnorris: yes that can happen but only on error
23:37:39  <tjfontaine>oh right I remember that conversation now
23:37:45  <trevnorris>ok. assert(suggested_size > 0) would work.
23:37:46  <piscisaureus_>trevnorris: i think in v0.10 more often than in master
23:37:57  <piscisaureus_>because bnoordhuis converted
23:38:51  <trevnorris>piscisaureus_: so it's a type of error where everything explodes in a fireball, or can it be recovered?
23:39:02  <piscisaureus_>trevnorris: no it can happen on EOF too
23:39:22  <trevnorris>ah, bugger. then do you just pass NULL to uv_buf_init?
23:39:36  <piscisaureus_>trevnorris: windows, and later versions of unix, do, indeed
23:39:43  <piscisaureus_>but I can't guarantee that it always works :)
23:40:00  <piscisaureus_>the libuv api doesn't anyway
23:40:15  <tjfontaine>he's only working in the master world, afaik
23:40:25  <trevnorris>heh, well I figured something like that must happen since there're buf.base != NULL checks in the on read callback
23:40:27  <piscisaureus_>trevnorris: however nobody is stopping from allocating 1 byte if libuv asks for 0
23:40:31  <tjfontaine>trevnorris: this is the slab allocator removal?
23:40:45  * AvianFluquit (Read error: Connection reset by peer)
23:40:50  <trevnorris>tjfontaine: yeah.
23:41:11  <trevnorris>I want to use realloc, so need to switch smalloc to use malloc/free
23:41:14  <tjfontaine>nod
23:41:24  * AvianFlujoined
23:41:36  <trevnorris>and bnoordhuis let me know malloc(0) impl varies by system(OS?).
23:41:52  <tjfontaine>by libc implementation
23:41:57  <trevnorris>ah, ok
23:42:15  <tjfontaine>or just about anyone who wants to write their own for that matter
23:43:58  * groundwaterquit (Ping timeout: 252 seconds)
23:45:46  <trevnorris>here's the change work in progress: https://github.com/trevnorris/node/commit/3923dd1
23:46:42  <tjfontaine>don't we alreayd have a fatal error handler?
23:46:53  <tjfontaine>oh I see
23:46:53  <trevnorris>we have a fatal error callback
23:46:58  <trevnorris>that v8 calls
23:47:01  <tjfontaine>right you want to trigger one
23:47:03  <trevnorris>yeah
23:47:12  <trevnorris>and v8 doesn't give direct access to do that
23:47:55  <tjfontaine>there's probably a v8 first class error for the memory case? chances are we'd hit the v8 heap before this one
23:47:58  * groundwaterjoined
23:48:16  <trevnorris>probably, but i'm just doing as i'm told. :)
23:52:16  * groundwaterquit (Ping timeout: 240 seconds)
23:55:16  * groundwaterjoined