00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:06  * stagasquit (Read error: Connection reset by peer)
00:00:08  * ircretaryjoined
00:01:15  <isaacs>trevnorris: pong
00:03:11  * amartensquit (Quit: Leaving.)
00:09:47  * qardquit (Quit: Leaving.)
00:13:25  * wavdedjoined
00:21:20  <isaacs>trevnorris, bnoordhuis: Why macroify the type checks?
00:27:35  * wavdedquit (Ping timeout: 260 seconds)
00:28:11  <isaacs>trevnorris: that is, what's the motivation for doing it this way rather than just using the builtin coercing functions. Is it better in some way?
00:28:51  <tjfontaine>I think they just want to consolidate the core way of doing it, so we're a bit more explicit
00:30:22  <isaacs>yeah.
00:30:24  <isaacs>anyway, i gotta run
00:30:51  <tjfontaine>are you still in jail?
00:32:01  * wavdedjoined
00:32:36  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:35:34  * M28joined
00:36:34  * wavdedquit (Ping timeout: 256 seconds)
00:37:39  * kazuponjoined
00:37:53  * abraxasjoined
00:39:07  * wavdedjoined
00:44:46  * wavdedquit (Quit: Nighty night)
00:47:02  * AvianFlu_joined
00:47:35  * AvianFlu_quit (Remote host closed the connection)
00:47:35  * AvianFluquit (Read error: Connection reset by peer)
00:48:04  * AvianFlujoined
00:55:57  * wavdedjoined
00:56:51  * kazuponquit (Remote host closed the connection)
00:57:03  * mikealquit (Quit: Leaving.)
00:57:37  * mikealjoined
00:57:43  <Domenic_>i assume the macro-ification is for perf benefits over doing `require("util").isArray` or whatevs
00:59:08  * AvianFluquit (Remote host closed the connection)
00:59:36  * AvianFlujoined
01:01:25  * c4milojoined
01:05:40  * AvianFluquit (Ping timeout: 276 seconds)
01:06:20  * kazuponjoined
01:14:10  * mikealquit (Quit: Leaving.)
01:14:28  * mikealjoined
01:19:07  * dshaw_quit (Quit: Leaving.)
01:19:18  * kazuponquit (Remote host closed the connection)
01:24:32  * dapquit (Quit: Leaving.)
01:34:49  * mikealquit (Quit: Leaving.)
01:37:50  * dshaw_joined
01:50:43  * indexzerojoined
01:58:26  * indexzeroquit (Quit: indexzero)
02:07:57  * mikealjoined
02:12:54  * pachetquit (Ping timeout: 256 seconds)
02:17:15  * indexzerojoined
02:24:48  * defunctzombiechanged nick to defunctzombie_zz
02:26:22  * amartensjoined
02:26:35  * amartensquit (Client Quit)
02:29:48  * kazuponjoined
02:35:32  * kazuponquit (Ping timeout: 268 seconds)
02:46:12  * mikealquit (Quit: Leaving.)
02:56:41  * TooTallNatejoined
02:59:18  * mikealjoined
02:59:32  * mikealquit (Client Quit)
03:10:26  * groundwaterquit (Quit: groundwater)
03:14:45  * dshaw_quit (Quit: Leaving.)
03:16:33  * kazuponjoined
03:17:27  * groundwaterjoined
03:24:01  * kazupon_joined
03:24:38  * kazuponquit (Ping timeout: 240 seconds)
03:33:08  * c4miloquit (Remote host closed the connection)
03:33:34  * c4milojoined
03:34:33  * pachetjoined
03:34:43  * pachetquit (Client Quit)
03:38:04  * c4miloquit (Ping timeout: 256 seconds)
03:39:01  * kazupon_quit (Remote host closed the connection)
03:39:53  * kazuponjoined
03:44:37  * kazuponquit (Remote host closed the connection)
03:44:48  * st_lukejoined
03:49:33  * mikealjoined
03:50:23  * indexzeroquit (Quit: indexzero)
03:51:50  * mikealquit (Client Quit)
03:58:21  * indexzerojoined
03:59:54  * kazuponjoined
04:14:00  * groundwaterquit (Quit: groundwater)
04:24:52  * bradleymeckjoined
04:24:58  * mikealjoined
04:26:43  * mikealquit (Client Quit)
04:32:35  * bajtosjoined
04:41:02  * wavdedquit (Quit: Hasta la pasta)
04:42:09  * julianduquequit (Ping timeout: 264 seconds)
04:51:50  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:52:03  * TooTallNatejoined
04:52:05  * TooTallNatequit (Client Quit)
04:55:26  * c4milojoined
05:00:57  * kazupon_joined
05:01:07  * kazuponquit (Read error: Connection reset by peer)
05:09:44  * indexzeroquit (Quit: indexzero)
05:18:26  * dominictarrjoined
05:21:17  * rjequit (Quit: Leaving...)
05:25:39  * defunctzombie_zzchanged nick to defunctzombie
05:27:30  * st_lukequit (Remote host closed the connection)
05:38:33  * TooTallNatejoined
05:43:45  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:44:41  * bradleymeck_joined
05:46:20  * bradleymeckquit (Ping timeout: 260 seconds)
05:46:20  * bradleymeck_changed nick to bradleymeck
05:48:28  * rjejoined
05:57:14  * rjequit (Quit: Leaving...)
06:00:20  * rjejoined
06:01:27  * hueniversejoined
06:01:38  * st_lukejoined
06:03:33  * dominictarrquit (Quit: dominictarr)
06:08:38  * mikealjoined
06:11:43  * kazupon_quit (Remote host closed the connection)
06:18:58  * kazuponjoined
06:19:30  * paddybyersjoined
06:27:08  * csaohjoined
06:30:39  * kazuponquit (Remote host closed the connection)
06:31:34  * csaohquit (Client Quit)
06:33:46  * kazuponjoined
06:43:40  * mikealquit (Quit: Leaving.)
07:10:20  * qardjoined
07:12:24  * qardquit (Client Quit)
07:13:51  * mikealjoined
07:17:31  * qardjoined
07:22:45  * qmxquit (Ping timeout: 248 seconds)
07:24:31  * qardquit (Quit: Leaving.)
07:24:37  * paddybyersquit (Ping timeout: 276 seconds)
07:25:27  * `3E|ZZZchanged nick to `3E
07:25:36  * qmxjoined
07:25:36  * qmxquit (Changing host)
07:25:36  * qmxjoined
07:26:06  * csaohjoined
07:28:01  * rendarjoined
07:32:30  * hzjoined
07:38:47  * c4miloquit (Remote host closed the connection)
07:39:15  * c4milojoined
07:43:28  * c4miloquit (Ping timeout: 245 seconds)
07:48:07  * qmxquit (Ping timeout: 260 seconds)
07:50:05  * qmxjoined
08:00:00  * rendarquit (Ping timeout: 246 seconds)
08:06:08  <roxlu__>hey!
08:10:11  * kazuponquit (Read error: Connection reset by peer)
08:10:24  <roxlu__>I'm implementing pipes and I got a silly situation where I close the pipe (uv_close) but I can still write to the connected 'clients' (?)
08:10:35  * kazuponjoined
08:15:21  * rendarjoined
08:38:48  * defunctzombiechanged nick to defunctzombie_zz
08:44:42  * perezdquit (Quit: perezd)
08:49:23  * roxlu__quit (Quit: leaving)
08:49:31  * roxlujoined
08:50:35  * paddybyersjoined
09:08:43  * bnoordhuisjoined
09:15:48  <MI6>joyent/libuv: mscdex master * c63cdc8 : src: remove unused variables - http://git.io/5Y8CZg
09:25:58  <bnoordhuis>sigh
09:26:04  <MI6>joyent/libuv: Ben Noordhuis master * 4ce3a31 : test: fix signed/unsigned comparison warnings (+1 more commits) - http://git.io/4Yjv_g
09:50:09  * kazuponquit (Remote host closed the connection)
10:13:00  <MI6>joyent/libuv: Timothy J Fontaine master * b13941c : build: dtrace shouldn't break out of tree builds - http://git.io/nq-oew
10:24:29  * dominictarrjoined
10:25:47  * bajtosquit (Quit: bajtos)
10:30:11  * abraxasquit (Remote host closed the connection)
10:31:54  * dominictarrquit (Quit: dominictarr)
10:38:13  * csaohquit (Quit: csaoh)
10:41:07  * piscisaureus_joined
10:44:00  * kazuponjoined
10:57:24  <indutny>hoya
10:57:30  <indutny>bnoordhuis: how are you?
10:58:23  <indutny>bnoordhuis: there's still one thing that I'd like you to look at https://github.com/joyent/node/pull/5882
10:58:25  <indutny>please
11:13:40  * qmxquit (Ping timeout: 256 seconds)
11:14:25  * qmxjoined
11:15:14  <MI6>joyent/libuv: Ben Noordhuis master * 977e833 : build: add mingw makefile (+1 more commits) - http://git.io/fp-Cyg
11:16:58  <bnoordhuis>indutny: i'll probably get around to it today
11:17:05  <indutny>ok, cool
11:17:07  <indutny>thank you
11:17:14  <indutny>bnoordhuis: anything I could help you with?
11:18:45  * csaohjoined
11:25:44  <bnoordhuis>indutny: um, anything particular you had in mind?
11:25:52  <bnoordhuis>i'm just going through pull requests and issues
11:25:58  <indutny>ah, not really
11:26:03  <indutny>probably I'll look at that threadpool thingy
11:26:11  <bnoordhuis>yeah, that'd be good
11:29:45  * mikealquit (Ping timeout: 240 seconds)
11:35:48  * piscisaureus_quit (Read error: Operation timed out)
11:51:29  <MI6>joyent/libuv: Brian White master * e3a657c : unix, windows: add MAC to uv_interface_addresses() - http://git.io/kCymPQ
11:54:01  <indutny>oh how I hate perl
11:55:34  * st_lukequit (Remote host closed the connection)
12:01:02  <bnoordhuis>indutny: how so?
12:01:58  <indutny>do you really need comment on that? :)
12:11:57  <indutny>brb
12:13:43  * kazuponquit (Remote host closed the connection)
12:26:46  * mikealjoined
12:31:01  * mikealquit (Ping timeout: 248 seconds)
12:50:52  <roxlu>does libuv have cross platform signal handlers, like SIGINT ?
12:54:37  * felixgejoined
12:54:37  * felixgequit (Changing host)
12:54:37  * felixgejoined
12:55:34  * jmar777joined
12:56:14  <indutny>bnoordhuis: thougths http://www.wolfssl.com/yaSSL/Products.html ?
12:58:34  <indutny>thoughts*
13:01:00  <bnoordhuis>indutny: not really. why do you ask?
13:01:11  <indutny>actually
13:01:17  <indutny>I want to write my own SSL implementation
13:01:21  * piscisaureus_joined
13:01:28  <indutny>but more I want to move to something saner than openssl
13:01:45  * dominictarrjoined
13:01:53  * bajtosjoined
13:03:01  <bnoordhuis>indutny: what about the actual crypto? are you going to write that from scratch?
13:03:09  <indutny>yeah, probably
13:03:23  <indutny>eventually
13:03:23  <bnoordhuis>brave
13:03:29  <bnoordhuis>and probably foolish - but brave :)
13:03:34  <indutny>there's not much crypto in SSL
13:03:43  <indutny>and it can support limited number of ciphers
13:03:56  <indutny>AES-SHA1
13:04:01  <indutny>or RC4-MD5
13:04:03  <bnoordhuis>MD5-NULL!
13:04:06  <indutny>haha
13:04:19  <indutny>yes, that's the most simpliest
13:04:28  <bnoordhuis>what about ECDH ciphers?
13:04:47  <indutny>eventually too
13:04:54  <indutny>ok, whatever
13:04:56  <indutny>I'll use openssl
13:04:59  <indutny>for encryption/hashing
13:05:01  <bnoordhuis>sensible :)
13:05:11  <indutny>and do CBC and stream-ciphering myself
13:05:43  <bnoordhuis>cbc? isn't that frowned on these days?
13:06:16  <indutny>well, yes
13:06:21  <indutny>but it should be supported anyway
13:06:25  <indutny>and also its not that bad
13:06:31  <indutny>if you have different IV for each frame
13:06:44  <indutny>and work properly with padding
13:09:40  <bajtos>hey guys, I am wondering if you could help me with my TLS benchmark https://github.com/strongloop/strong-cluster-tls-store/tree/benchmark/benchmark
13:10:21  <bajtos>when I run a single scenario (set of options), then I can get up to 1400 conn/sec.
13:10:37  <bajtos>but when I run multiple scenarios one after another, the performance significantly drops
13:11:06  <bajtos>even when running the same scenario multiple times, there can be ~30% drop in the number of connections opened per second
13:11:41  <bnoordhuis>bajtos: what cipher are you using? try MD5-NULL first to exclude cpu overhead
13:11:47  <bajtos>have you encountered any similar problem? how to best approach troubleshooting?
13:11:56  <bajtos>ciphers do not matter
13:12:01  <bnoordhuis>the reason i mention that is that intel cpus have this turboboost feature
13:12:12  <bajtos>oh, bugger
13:12:15  <bnoordhuis>where cores overclock until they get too hot, then they clock back
13:12:31  <bnoordhuis>makes it kind of hard to do reliable benchmarks :)
13:12:38  <bnoordhuis>you can usually disable it in the bios btw
13:12:59  <bnoordhuis>same for hyperthreading, you probably want to disable that when benchmarking
13:13:12  <bajtos>that sounds perfectly reasonable :)
13:13:50  <bajtos>it was driving me crazy, since it was enough to wait like 10-20 seconds before running the benchmark again to get the same perf.
13:14:01  <bajtos>in which case, I am going to reboot now :-D
13:14:05  <bnoordhuis>heh :)
13:16:39  <bajtos>hmm, not so quickly, apparently Mac don't have BIOS to change that settings
13:17:21  <indutny>hahaha
13:17:28  <indutny>just forget about benchmarking on mac
13:17:28  <bnoordhuis>oh, i don't know how that works on macbooks
13:17:43  <bnoordhuis>btw, you're not benchmarking in a vm, are you?
13:17:58  <bnoordhuis>because that's close to pointless
13:18:00  <bajtos>bnoordhuis: of course not!
13:18:05  <bnoordhuis>okay, good :)
13:18:12  <bajtos>bnoordhuis: unless OS X is one big VM
13:18:37  <bnoordhuis>well... os x is certainly one big something - but not a vm, no
13:18:43  <bajtos>:-D
13:19:01  <bnoordhuis>okay, afk - biab
13:23:39  * bnoordhuisquit (Ping timeout: 268 seconds)
13:24:12  * kazuponjoined
13:27:03  * mikealjoined
13:29:33  * kazuponquit (Ping timeout: 264 seconds)
13:29:57  * indexzerojoined
13:31:08  * mikealquit (Ping timeout: 241 seconds)
13:32:20  * dominictarrquit (Quit: dominictarr)
13:50:36  * bradleymeckquit (Quit: bradleymeck)
13:51:05  * perezdjoined
13:51:27  <bajtos>indutny: fedor, could you perhaps run the benchmark for me on your machine?
13:51:33  <indutny>I'm on mac too
13:51:43  <indutny>but if you want - I can do it
13:52:01  <indutny>also, if you're benchmarking ssl - please wait a bit
13:52:03  <bajtos>well if mac is useless for bechmarks, then it isn't going to help - or is it?
13:52:17  <indutny>I'm working on one patch that should speed up it a bit
13:52:51  <bajtos>indutny: I am actually benchmarking the difference made by that two patches you wrote for my bugs and also for cluster-messaging based TLS session store for cluster
13:53:21  <bajtos>indutny: so the absolute speed of TLS is not so much of my concern, I am interested in difference in speed in different configurations
13:56:06  <indutny>aah
13:56:09  <indutny>well, ok
13:56:15  <indutny>benchmarking on osx is not really useful
13:56:22  <indutny>you better ask bnoordhuis to do it
13:56:26  <indutny>he has big desktop box
13:57:03  <bajtos>yes, I know. he was doing his best to discourage me from buying MBP as my work laptop
13:57:10  <bajtos>so how do you benchmark then?
13:57:25  <bajtos>reboot into linux?
14:00:30  <indutny>bajtos: I only have windows in bootcamp
14:00:42  <indutny>and benchmarking tls on remote servers
14:00:43  <indutny>sometimes
14:05:24  <indutny>also
14:05:29  <indutny>you can try running it for a longer time
14:05:32  <indutny>like one minute
14:05:33  <indutny>or more
14:06:01  <bajtos>I have also added a delay between the runs, but that didn't help much.
14:06:14  <bajtos>I will try to turn off HT first and see what the numbers are
14:06:28  <bajtos>(you have to install xcode to do that, OMG)
14:08:00  * piscisaureus_quit (Ping timeout: 260 seconds)
14:14:31  * c4milojoined
14:15:48  * bnoordhuisjoined
14:18:32  * pachetjoined
14:18:32  * pachetquit (Changing host)
14:18:32  * pachetjoined
14:21:00  <bajtos>bnoordhuis: welcome back, I have few more questions if you have time to talk now?
14:21:20  <bnoordhuis>bajtos: shoot
14:21:46  <bajtos>the first thing is disabling tls session tickets extension in v0.10 when running in a cluster
14:22:16  <bnoordhuis>go on
14:22:19  <bajtos>since we can't get it to work correctly, it seems like a good idea to disable it
14:22:44  <bajtos>so I wanted to know your opinion, whether it's something we can get into v0.10
14:23:24  <bajtos>I didn't checked the code yet, but I am expecting that when we create TLS server in a cluster worker, we will tell openssl to disable session tickets
14:24:10  <bajtos>but now that I think about it, since the cluster in v0.10 is not RR, most requests end up in few workers only
14:24:29  <bnoordhuis>yep
14:24:52  <bajtos>so many connections will still reuse session, because they end up on the same worker
14:25:20  <bajtos>so disabling the extension will probably degrade the performance.
14:25:21  <bajtos>hmm
14:27:25  * mikealjoined
14:28:53  <bajtos>ok, I'll try to fix my machine first so that the benchmarks are more reliable and then I'll see whether extra `resumeSession` calls are such a problem.
14:29:10  <bajtos>bnoordhuis: the second question is a longer one
14:29:22  <bajtos>bnoordhuis: do you know Timeline tab in Chrome's Developer Tools?
14:31:08  <bajtos>bnoordhuis: https://developers.google.com/chrome-developer-tools/docs/timeline -> section About nested events
14:32:19  * mikealquit (Ping timeout: 276 seconds)
14:34:01  <bajtos>bnoordhuis: I was thinking that if we could instrument node/libuv to report event-loop events with info about which callback scheduled the async request, then Timeline could nicely visualise long-stack for us
14:34:57  <bajtos>bnoordhuis: and it shouldn't be a big performance problem, since you can turn on and off the collection of timeline events in the UI
14:38:49  <bnoordhuis>bajtos: "instrument node/libuv to report event-loop events with info about which callback scheduled the async request
14:38:56  <bnoordhuis>how would that work?
14:39:14  <bajtos>that's what I am not sure about :)
14:39:39  <bnoordhuis>let's start with what your definition of 'async request' is
14:40:27  <bajtos>so let's say your http request handler calls net.connect (to keep it simple)
14:41:09  <bnoordhuis>okay. what info would you want to retain?
14:41:14  * kazuponjoined
14:41:39  <bajtos>there should be a Timeline event saying in this tick, http request handler callback was running, and it scheduled net.connect. when net.connect calls the callback, you will have a link to the http request handler callback that is a parent of this
14:41:54  <bajtos>I guess it is very similar to Bert's tasks
14:42:15  <bajtos>which might mean we won't be able to properly visualise until tasks are implemented
14:42:21  <bnoordhuis>bajtos: you want to capture a stack trace or ?
14:42:44  <bajtos>bajtos: yes, stack trace is a good start
14:42:55  <MI6>joyent/node: Fedor Indutny master * 508a6c2 : openssl: use asm for sha, md5, rmd - http://git.io/Qnnw6w
14:43:04  <bnoordhuis>stack traces a re pretty expensive though, both time and memory wise
14:43:07  <bnoordhuis>*are
14:43:20  <bnoordhuis>rule of thumb is ~1 kb per trace
14:43:55  <bnoordhuis>time-wise it's O(n) where n is the number of captured frames
14:43:56  <bajtos>bnoordhuis: I know, but you are already running in a debugger and you have explicitly ask for this in the UI
14:44:06  <bajtos>*have asked
14:44:08  <bnoordhuis>ah, okay - it's an opt-in thing
14:44:26  <bajtos>there is a button in the UI and it's disabled by default
14:44:56  <bnoordhuis>i guess the first question is: how would you tell node to start collecting that data?
14:45:19  <bnoordhuis>i mean, what happens when you click that button?
14:45:34  * c4miloquit (Remote host closed the connection)
14:45:37  <bajtos>I have this evil plan in my head: since you can eval() code using V8 debugger protocol, node-inspector can inject anything into the running process
14:45:56  <bajtos>bnoordhuis: this mechanism can be used for other purposes as well
14:46:01  * c4milojoined
14:46:27  <bnoordhuis>okay, so you send a string like "process._captureAllTheStackTraces()" and eval that?
14:46:38  <bajtos>bnoordhuis: yes, that's the idea
14:47:07  <bnoordhuis>workable
14:47:09  <bajtos>bnoordhuis: I'll probably have to inject a client that will send Timeline events from the debugged process to the node-inspector process
14:47:39  <bnoordhuis>that was my next question - how does the data get from node to the debug client?
14:48:55  <bajtos>either node process starts a server for the debug client to connect to; or it opens a (websocket) connection to the debug client (this is probably better & safer)
14:49:03  <bajtos>by safer I mean more secure
14:50:12  <bnoordhuis>is security important / relevant here? you're already injecting arbitrary code, right? :)
14:50:15  <bajtos>since debug client (node inspector) and the debugged process run on the same machine, we can eval "require('/path/to/inspector/instrumentation/timeline.js').connectTo(inspectorPort)"
14:50:23  * c4miloquit (Ping timeout: 240 seconds)
14:50:39  <bajtos>probably not, but we don't have to make things even worse :)
14:51:14  <bnoordhuis>doesn't the v8 debugger protocol let you send over data?
14:51:29  <bnoordhuis>is node-inspector using the v8 debugger protocol?
14:51:34  <bajtos>yes and yes
14:51:56  <bnoordhuis>okay. so can't you use that rather than a new socket/websocket?
14:52:23  <bajtos>I could, but then it will have to be implemented in noe
14:52:26  <bajtos>* node
14:52:42  <bajtos>while if you inject a new socket, it can be done in user-land
14:53:09  <bnoordhuis>ah, because you can inject code that loads the appropriate module. okay
14:53:40  <bnoordhuis>that'll break if the user manages to botch the module system though
14:53:46  <bajtos>I've got this idea as we were talking: perhaps I can do a proof-of-concept entirely in userland? I can use the same mechanism that long stack trace modules are using, right?
14:53:53  <bnoordhuis>yes
14:54:12  <bnoordhuis>one thing though, where are you going to get the reference to require() from? it's not a global
14:54:27  <bajtos>and then if this thing turns out to be useful, we can find out ways how to get it into node core. plus I will have much better understanding of the problem domain by that time
14:54:37  <bajtos>I guess it's all I need for now
14:54:43  <bajtos>on that topic
14:54:46  <bnoordhuis>okay :)
14:54:55  <bajtos>and the last question before our hangout starts
14:55:11  <bajtos>V8 api change in v0.11 broke v8-profiler (again)
14:55:45  <bnoordhuis>i weep with you
14:56:04  <bajtos>IMO we should really expose V8 profiler API in node, so there is no need for an extra module
14:56:43  <bajtos>Do you remember as we were discussing extension of V8 debugger API to include V8 profiler stuff? So I don't mean to do that now
14:57:16  <bajtos>Just to add a new node.js core module, let's say 'profiler', and move the methods from v8-profiler module there
14:57:54  <isaacs>good morning heroes
14:58:01  * julianduquejoined
14:58:11  <bajtos>bnoordhuis: that way you will always have the right profiler for the version of node you are running on
14:59:44  <bnoordhuis>bajtos: well, up to a point. the profiler api has changed in incompatible ways in the past, having a core module won't avoid that
14:59:56  <bnoordhuis>morning isaac
15:00:32  <bajtos>bajtos: but then updating the node profiler api will become a part of V8 upgrade, not a job for module maintainers
15:00:43  <bajtos>ehm, talking to myself
15:01:20  <bajtos>bnoordhuis: btw is it possible to detect V8/node version in a native module and use the correct V8 methods via #ifdefs?
15:01:31  * mikealjoined
15:03:47  * mikealquit (Client Quit)
15:04:37  <bajtos>bnoordhuis: hangout call?
15:15:14  <bnoordhuis>bajtos: node_version.h contains macros you can test against
15:16:38  <bajtos>ok, that at least means we can support multiple node versions with a single module
15:16:51  <bnoordhuis>yep
15:17:12  <bajtos>bnoordhuis: if I understand it correctly, you would rather keep the profiler API in a user-land module, right?
15:18:23  <bnoordhuis>bajtos: well, not necessarily. it's just that bringing it into the core may not be the panacea you think it is
15:19:00  <bnoordhuis>bajtos: what profiler api in particular would you want to see in core?
15:19:08  * julianduquequit (Ping timeout: 246 seconds)
15:19:19  * mikealjoined
15:19:50  <bajtos>bnoordhuis: I didn't look at details, we could begin with the API of v8-profiler: https://github.com/c4milo/v8-profiler
15:20:30  <isaacs>trevnorris: What's teh difference between Number.isNaN and global.isNaN?
15:20:47  <trevnorris>isaacs: Number.isNaN doesn't coerce to number before checking
15:20:51  <isaacs>right
15:20:59  <isaacs>trevnorris: so, it's just `(arg !== arg)`
15:21:03  <trevnorris>same with Number.isFinite
15:21:42  <trevnorris>isaacs: well, we use isNaN in core, so type coercion must happen. hence the trick I used of !(arg >= arg)
15:21:54  <isaacs>trevnorris: i see
15:22:04  <isaacs>so, effectively, +arg !== +arg
15:22:12  <isaacs>but why not just use isNaN, then?
15:22:22  <isaacs>that is, there's already a nice greppable thing we're already using
15:22:31  <isaacs>for !~~(+arg) crap, sure
15:22:34  <isaacs>totally makes sense
15:22:37  <trevnorris>basically. i'm going to generate the assembly from the several checks to demonstrate the difference.
15:23:26  <isaacs>if isNaN generates worse assembly than (!(arg>=arg)) then I'd consider that a v8 bug
15:23:45  <trevnorris>heh, well isNaN is a function call so it won't be inlined as well.
15:24:20  <isaacs>also a v8 bug. those functions should be extremely hot and inlineable.
15:24:23  <bnoordhuis>technically, isNaN can be inlined by v8
15:24:36  <bnoordhuis>but i've never gotten a handle on v8's inlining heuristics
15:24:58  <isaacs>bnoordhuis: yeah, they're a bit crazy, and the comments in the code assume you've read lots of scholarly articles about VMs
15:25:07  <bajtos>bnoordhuis: I have to go. I'll talk to you later if I get to do the update of v8-profiler for v0.11
15:25:18  <bnoordhuis>bajtos: okay. bon appetite
15:25:32  <isaacs>which is fair, i guess, i mean, the comments in http.js assume you've read the http spec
15:26:11  <bnoordhuis>isaacs: oh, sure. but what i mean is that there's like a 1,000 factors that influence whether or not v8 inlines a function
15:26:37  <bnoordhuis>it's neigh impossible to keep them all in your head
15:26:58  * bajtosquit (Quit: bajtos)
15:27:19  <trevnorris>heh, my favorite is the function body can't contain more than 600 characters, including comments :P
15:27:57  <bnoordhuis>is that one still in there?
15:28:23  <trevnorris>yup
15:29:19  * AvianFlujoined
15:29:38  * defunctzombie_zzchanged nick to defunctzombie
15:30:01  * jmar777_joined
15:30:21  * austojoined
15:30:47  * mikealquit (Quit: Leaving.)
15:32:00  * jmar777quit (Read error: Connection reset by peer)
15:33:58  <isaacs>yeah
15:42:03  <isaacs>bnoordhuis, trevnorris: The reason i'm raising the macros as an issue is that reading NUMBER_IS_NAN is kind of jarring in JS code, and stands out as magical.
15:42:39  <isaacs>it's not a HUGE cost, obviously, and if it's that or a bunch of +~~!~~+ garbage, then ok, worth it
15:42:58  <isaacs>but if we're just mapping NUMBER_IS_FINITE() to isFinite(), then it seems silly
15:43:28  * mikealjoined
15:43:50  <trevnorris>bnoordhuis: on the side, we can't be using NUMBER_IS_NAN/_IS_FINITE. core depends on type check coercion.
15:44:05  <bnoordhuis>oh, i'm not married to NUMBER_IS_NAN and NUMBER_IS_FINITE - they were just the lowest-hanging fruit
15:44:57  <bnoordhuis>TO_INT32() and friends however...
15:45:36  * c4milojoined
15:45:56  * mcavagejoined
15:47:31  <isaacs>right
15:47:43  <isaacs>that stuff is clearly MORE jarring than the macro
15:48:57  <bnoordhuis>the introduction of macros is part of a greater scheme btw
15:49:07  <isaacs>where are you going with it?
15:49:33  <bnoordhuis>i want to remove a fair number of persistent strings by introducing `const kHandleWrapCloseCallbackIndex = 0` macros
15:49:51  <bnoordhuis>i.e. use numeric indices rather than strings for callback dispatch
15:51:09  <bnoordhuis>iow, you'd do `sock._handle[kHandleWrapCloseCallbackIndex] = cb` rather than sock._handle.onclose = cb`
15:51:14  <bnoordhuis>faster, less persistents, win all around
15:51:30  <bnoordhuis>though i'll probably make it a little less wordy
15:52:25  <bnoordhuis>okay, dinner - biab
15:52:42  <trevnorris>I updated https://github.com/joyent/node/pull/5898 with the assembly output of the two tests.
15:52:47  <isaacs>bnoordhuis: that sounds like a good idea
15:53:10  <isaacs>bnoordhuis: (i mean, the sock._handle[close] idea, but dinner is probably a good idea, too)
15:54:20  <isaacs>trevnorris: Object.is(+arg, NaN) would avoid the double-eval
15:54:58  <trevnorris>isaacs: interesting. i'll run that now.
15:55:26  * indexzeroquit (Quit: indexzero)
15:56:24  * AvianFluquit (Remote host closed the connection)
15:56:36  <isaacs>trevnorris: but, really... i mean.. what's the point? isNaN is plenty readable, and I'm willing to bet quite a lot that it's not a significant performance hit
15:56:53  * bnoordhuisquit (Ping timeout: 240 seconds)
15:56:58  <isaacs>there's some saying about polishing the doorknobs on the titanic or something
15:58:04  <trevnorris>isaacs: honestly I was always just looking for consistency in our checks and coercions. ben threw up the macros yesterday afternoon.
15:58:31  <trevnorris>so guess I figured, since they did get implemented might as well make them really good.
15:58:55  <isaacs>yeah. your heart's in the right place :) i'm not convinced that isNaN and isFinite should be macroed away. IS_UINT32() and friends, that makes sense.
15:59:13  <isaacs>trevnorris: wanna take a look at this? https://github.com/joyent/node/pull/5899
16:00:24  <isaacs>trevnorris: it's sort of the spirit of the bug fix in 0.10 that added the state.calledRead flag so that you could pipe zero-length http requests if you'd never consumed them
16:00:38  <trevnorris>the macros weren't my idea. I like the consistency they provide, but there's something weird about replacing js code at compile time. for me at least.
16:00:42  <trevnorris>and sure, be happy to.
16:00:45  <isaacs>but it's more thorough: even if you HAVE called read, but you haven't called read ENOUGH, it won't emit end.
16:01:10  <isaacs>trevnorris: true story: the `debug()` functions used to be macros that were removed in non-debug builds.
16:01:33  <trevnorris>hah. awesome.
16:03:54  <trevnorris>isaacs:updated with object.is() output. wow, not pretty.
16:04:03  <isaacs>trevnorris: hahahah
16:04:10  <isaacs>trevnorris: i'll bet. that function is pretty fancy :)
16:06:16  <roxlu>I'm using uv_pipe_bind(&pipe, "encoder.sock"), but the file which is created is called: "encoder.s", everything file I try with a length bigger then 9 is cut off ..
16:06:34  <roxlu>someone who has any clue what that could be ?
16:12:59  * groundwaterjoined
16:13:10  * isaacs&
16:17:28  <trevnorris>isaacs: lgtm
16:17:29  <roxlu>wierd... it looks like it had to do with available memory (?)
16:17:48  * TooTallNatejoined
16:18:05  * dapjoined
16:19:34  <trevnorris>roxlu: strange one.
16:19:47  <roxlu>trevnorris: hmm actually it's not sovled yet
16:20:03  <roxlu>it's super strange indeed
16:25:49  * mikealquit (Quit: Leaving.)
16:27:53  * AvianFlujoined
16:29:58  <roxlu>Whebn I do: uv_pipe_bind(&pipe, "encoder.sock");, I get this file: srwxr-xr-x 1 roxlu staff 0B Jul 25 18:24 encoder.s
16:32:58  * TooTallNatequit (Ping timeout: 246 seconds)
16:36:06  * rendarquit (Ping timeout: 256 seconds)
16:37:38  * dominictarrjoined
16:38:19  * mikealjoined
16:39:23  <tjfontaine>ok I guess it's v0.10.14 time
16:40:04  * dshaw_joined
16:40:36  * perezdquit (Quit: perezd)
16:41:00  * mcavagequit (Remote host closed the connection)
16:41:20  * perezdjoined
16:41:50  * dominictarrquit (Ping timeout: 240 seconds)
16:42:02  * perezdquit (Client Quit)
16:42:33  * csaohquit (Quit: csaoh)
16:43:56  * mikealquit (Quit: Leaving.)
16:44:15  <trevnorris>tjfontaine: fun. as for me, time for a nap.
16:44:31  <tjfontaine>trevnorris: have you been up all night?
16:44:48  <trevnorris>tjfontaine: yeah. up till 4am working on the node.c api.
16:44:55  <tjfontaine>hehe
16:45:01  <tjfontaine>getting anywhere fun?
16:45:18  * TooTallNatejoined
16:45:45  <tjfontaine>hmm no ben, and isaacs is away, I wonder if I should brave a libuv release on my own, or if I should wait
16:46:54  <tjfontaine>ircretary: tell bnoordhuis won't have to float the v8 patch for long https://code.google.com/p/v8/source/detail?r=15870
16:46:55  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
16:47:27  * TooTallNatequit (Client Quit)
16:49:23  <trevnorris>tjfontaine: nice.
16:52:00  <tjfontaine>not like I did anything but it should make v8 upgraders happy :)
16:54:42  <trevnorris>tjfontaine: hey, submitting a patch to v8 looks daunting enough for someone who hasn't done it.
16:54:49  <trevnorris>think there was a day even ben was cursing about it.
16:55:37  <tjfontaine>I was dreading it because of that reason
16:55:41  <tjfontaine>ultimately I had 0 problems
16:55:46  <trevnorris>cool.
16:55:47  <tjfontaine>it was about as easy as it could get
16:56:08  <tjfontaine>commit my stuff on a branch, git cl upload, go to website and fill in some extra information, hit publish+mail
16:56:16  * brsonjoined
16:56:25  <tjfontaine>in fact, it's how I wish GH PRs worked :)
16:56:30  * qardjoined
16:56:35  * brsonquit (Client Quit)
16:56:51  <trevnorris>haven't used svn in years. that seems painful enough. :P
16:57:22  * dominictarrjoined
16:57:31  <tjfontaine>I used git
16:57:34  <tjfontaine>no need for svn
16:58:03  <trevnorris>awesome.
16:58:16  * hzquit
16:58:51  * trevnorris&
17:02:56  * bnoordhuisjoined
17:03:22  * TooTallNatejoined
17:06:10  <tjfontaine>bnoordhuis: I presume we need a new libuv release for the chown fix?
17:06:44  <tjfontaine>isaacs wants me to do a v0.10.14 release today, and I've yet to do a libuv release
17:07:02  * amartensjoined
17:07:57  * bnoordhuisquit (Ping timeout: 264 seconds)
17:07:58  * dominictarrquit (Quit: dominictarr)
17:11:31  * mcavagejoined
17:19:54  * mcavagequit (Ping timeout: 264 seconds)
17:26:46  * bnoordhuisjoined
17:26:57  <bnoordhuis>back!
17:27:06  <bnoordhuis>tjfontaine: yes, you should do a libuv release
17:27:10  <tjfontaine>wb bnoordhuis!
17:27:11  <bnoordhuis>or i can do it for you if you want
17:27:25  <tjfontaine>bnoordhuis: well, I can do it if you want to walk me through it
17:27:38  <bnoordhuis>also, nice that the mmap patch landed
17:27:48  <tjfontaine>ya, one less thing to worry about
17:27:55  <bnoordhuis>it's easy, clone the libuv-release-tool repo and run release.js
17:28:11  * c4miloquit (Remote host closed the connection)
17:28:15  <tjfontaine>from the v0.10 branch?
17:28:37  * c4milojoined
17:29:08  <bnoordhuis>yep
17:29:26  * indexzerojoined
17:29:54  <bnoordhuis>i'll merge v0.10 into master afterwards, no doubt there'll be conflicts
17:30:07  <tjfontaine>I remove the "now working on" part of the changelog?
17:30:34  * mikealjoined
17:31:01  * c4miloquit (Read error: No route to host)
17:31:20  <bnoordhuis>tjfontaine: that's the second commit, right? i just leave that in
17:31:24  * c4milojoined
17:31:55  <tjfontaine>hmm can I teach the tool to use a different gpg key?
17:33:01  <bnoordhuis>ah, that i don't know
17:33:04  <bnoordhuis>lemme check
17:33:33  * rendarjoined
17:33:41  <tjfontaine>gitClient.tag([releaseTag, '-as'], message, nextOrRetry);
17:33:47  <tjfontaine>hmm maybe there's a git config I can set
17:34:30  <tjfontaine>git config --global user.signingkey
17:34:59  <bnoordhuis>git - it slices, it dices
17:36:13  <tjfontaine>ah, it used the origin for the push
17:36:57  <MI6>joyent/libuv: tjfontaine created tag v0.10.13 - http://git.io/SQ57Bg
17:37:22  <MI6>joyent/libuv: Timothy J Fontaine v0.10 * 2744e1e : Now working on v0.10.14 (+1 more commits) - http://git.io/G_6GCQ
17:49:13  * mikealquit (Quit: Leaving.)
17:49:46  <MI6>joyent/node: Timothy J Fontaine v0.10 * 5c81f41 : uv: Upgrade to v0.10.13 - http://git.io/Jzq-tQ
17:50:20  * mikealjoined
17:51:40  <MI6>joyent/node: tjfontaine created branch v0.10.14-release - http://git.io/jWdw8g
17:54:36  <MI6>libuv-review: #27 FAILURE windows-ia32 (5/188) smartos-x64 (2/187) windows-x64 (4/188) smartos-ia32 (2/187) http://jenkins.nodejs.org/job/libuv-review/27/
18:00:40  * kazuponquit (Remote host closed the connection)
18:01:50  <tjfontaine>https://gist.github.com/tjfontaine/6082209 everyone ok with this change log?
18:01:52  * mcavagejoined
18:02:39  <bnoordhuis>yep
18:03:21  <MI6>joyent/libuv: Ben Noordhuis master * 3d4099e : Merge remote-tracking branch 'origin/v0.10' (+5 more commits) - http://git.io/feoHCA
18:03:34  <tjfontaine>ok running tests
18:07:47  * c4miloquit (Remote host closed the connection)
18:08:14  * c4milojoined
18:08:43  * c4miloquit (Read error: Connection reset by peer)
18:08:57  * c4milojoined
18:13:07  * pachetquit (Quit: leaving)
18:19:21  * dominictarrjoined
18:22:16  * dominictarrquit (Client Quit)
18:23:54  <roxlu>where is uv_last_error ?
18:27:45  <bnoordhuis>roxlu: gone
18:27:54  <roxlu>I c :)
18:28:04  <bnoordhuis>uv functions now return errors directly
18:28:14  <bnoordhuis>ditto for callbacks, they receive the error directly
18:28:16  <roxlu>so basically when r != 0, I can use uv_strerror() ?
18:28:22  <bnoordhuis>when r < 0
18:28:25  <bnoordhuis>or nread < 0
18:28:30  <bnoordhuis>you get the idea
18:28:53  * mordy__part
18:28:57  <roxlu>hmm uv_getaddrinfo is supposed to return 0 on success right?
18:30:41  * mcavagequit (Remote host closed the connection)
18:30:55  * c4miloquit (Remote host closed the connection)
18:31:10  <bnoordhuis>roxlu: correct
18:31:15  <isaacs>tjfontaine: hola! yes, let's do that :)
18:31:22  * c4milojoined
18:31:31  <tjfontaine>isaacs: I'm about to push the button on building the binaries :)
18:31:40  <isaacs>tjfontaine: w00T!!
18:31:40  <roxlu>hehe I'm confused .. so r = 0 is "true", and r < 0 false?
18:31:55  <bnoordhuis>roxlu: 0 == success, < 0 == error
18:32:04  <roxlu>ok
18:32:12  * mcavagejoined
18:32:47  * felixgequit (Read error: Connection reset by peer)
18:32:58  * mcavagequit (Remote host closed the connection)
18:36:43  * c4miloquit (Ping timeout: 276 seconds)
18:37:05  <trevnorris>isaacs: so if I call socket.write(data); socket.end(); will prevent future incoming connections, but still try to flush the data before fully closing?
18:37:31  <tjfontaine>you mean listener.end()?
18:38:44  <trevnorris>oh wait, yeah I see it.
18:38:54  <trevnorris>tjfontaine: thanks. really need to go take that nap.
18:39:14  <tjfontaine>hehe
18:39:17  <tjfontaine>I thought you had :)
18:40:22  <trevnorris>yeah... lay down, get an idea, back to the laptop. :P
18:45:33  * c4milojoined
18:47:14  <tjfontaine>oh I forgot a step.
18:49:38  <MI6>joyent/node: Timothy J Fontaine v0.10.14-release * fdf57f8 : 2013.07.25, Version 0.10.14 (Stable) - http://git.io/B43yKg
18:50:03  <tjfontaine>make sure you do things in the right order.
18:52:54  * mikealquit (Read error: Connection reset by peer)
18:52:55  * mikeal1joined
18:53:39  * mikeal1quit (Client Quit)
18:56:58  * c4miloquit (Remote host closed the connection)
18:57:24  * c4milojoined
18:57:46  * c4miloquit (Read error: Connection reset by peer)
18:58:10  * c4milojoined
19:00:57  <isaacs>tjfontaine: have you seen this? looks kinda neat: https://github.com/rvagg/nan
19:01:56  <tjfontaine>isaacs: yes
19:02:25  <tjfontaine>isaacs: https://groups.google.com/d/msg/nodejs/XaZo6NhfGT0/Iu8kCNT3nT4J
19:02:40  <isaacs>oh, right, we have a mailing list
19:02:42  <isaacs>forgot about that
19:02:44  <tjfontaine>heh
19:04:17  <isaacs>tjfontaine: i've been thinking about what you mentioned, and i think it's kind of a pita that you can't depend on your deps having been unpacked already before your install script runs
19:04:43  <isaacs>in the past, this wasn't an issue, because you never have binary addons with deps, really
19:04:50  <isaacs>or at least, binary addons with compilation deps
19:05:18  <isaacs>but it's annoying to have to bundle node-addon-layer or nan in your source, rather than just listing it as a npm de
19:05:21  <isaacs>p
19:05:26  <tjfontaine>yes
19:05:32  <tjfontaine>most of the time it works for me, in my testing
19:09:14  * c4miloquit (Remote host closed the connection)
19:09:40  * c4milojoined
19:14:36  * c4miloquit (Ping timeout: 256 seconds)
19:15:08  * c4milojoined
19:15:25  * mikealjoined
19:17:46  * joshthecoderquit (*.net *.split)
19:17:47  * niskaquit (*.net *.split)
19:17:47  * rvaggquit (*.net *.split)
19:17:48  * othiym23quit (*.net *.split)
19:17:48  * chobie4quit (*.net *.split)
19:18:20  * indexzeroquit (Quit: indexzero)
19:18:42  * joshthecoderjoined
19:18:42  * niskajoined
19:18:42  * rvaggjoined
19:18:42  * othiym23joined
19:18:42  * chobie4joined
19:20:23  * philipsquit (*.net *.split)
19:21:16  * philipsjoined
19:23:23  <isaacs>tjfontaine: yeah, but it definitely WONT work some of the time, in weirdo non-deterministic ways
19:23:37  <isaacs>tjfontaine: especially, if the node-addon-layer module is not cached, but the module depending on it IS cached
19:23:52  * rendarquit (*.net *.split)
19:23:52  * bnoordhuisquit (*.net *.split)
19:23:53  * dshaw_quit (*.net *.split)
19:23:53  * dapquit (*.net *.split)
19:23:53  * swajrquit (*.net *.split)
19:23:53  * jez0990quit (*.net *.split)
19:23:55  * DrPizzaquit (*.net *.split)
19:29:47  * swajjoined
19:29:58  * bnoordhuisjoined
19:31:27  * amartensquit (Quit: Leaving.)
19:31:30  * kazuponjoined
19:31:32  * mraleph1quit (Quit: Leaving.)
19:31:41  * mralephjoined
19:32:19  * pachetjoined
19:35:13  * rendarjoined
19:35:13  * dshaw_joined
19:35:13  * dapjoined
19:35:13  * jez0990joined
19:35:13  * DrPizzajoined
19:36:09  * c4miloquit (Remote host closed the connection)
19:36:36  * c4milojoined
19:40:06  <isaacs>trevnorris, bnoordhuis: also, why is the IS_BUFFER macro using instanceof rather than Buffer.isBuffer()? Why not just use Buffer.isBuffer() instead of a macro for that?
19:40:26  * kazuponquit (Ping timeout: 268 seconds)
19:41:21  <bnoordhuis>isaacs: because Buffer.isBuffer() was using an instanceof check
19:41:35  <isaacs>bnoordhuis: heh
19:41:39  <isaacs>fair enough i guess
19:41:43  * c4miloquit (Ping timeout: 276 seconds)
19:41:43  <isaacs>but then why not just use that?
19:42:12  <bnoordhuis>you mean why not use Buffer.isBuffer()? instanceof checks get optimized better
19:42:23  <isaacs>right
19:42:23  <bnoordhuis>i know, i know, micro-optimizations
19:42:45  <isaacs>it's a micro-optimization at the expense of code readability. macros are magical and scary.
19:42:58  <isaacs>if they replace something that is hideously verbose, or unreadable, i mean, ok.
19:43:27  <bnoordhuis>i don't know about magical, it's plain text substitution
19:44:21  <bnoordhuis>oh, in case you're wondering, the reason i added IS_BUFFER() was that in some places we called Buffer.isBuffer(), in other places we did instanceof checks
19:44:28  <bnoordhuis>this way it's nicely harmonized
19:44:42  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:48:32  * TooTallNatejoined
19:59:04  * mikealquit (Quit: Leaving.)
20:01:47  * amartensjoined
20:04:58  <isaacs>bnoordhuis: at least, doing it the SAME way is worthwhile
20:05:13  <isaacs>bnoordhuis: it's not as magical as CPP macros, of course.
20:05:33  <isaacs>bnoordhuis: but it does take us down a disturbing road away from plain ol' js
20:05:52  <isaacs>bnoordhuis: down that path lies coffee-script and streamline and iced pleasegodkillmenow
20:06:09  <isaacs>bnoordhuis: paved with good intentions and all that :)
20:10:26  <Domenic_>you guys should add a macro to make the callbacks easier
20:10:38  * amartensquit (Ping timeout: 240 seconds)
20:10:43  <isaacs>Domenic_: demerit.
20:10:51  <tjfontaine>we need hygenic macros
20:10:53  <tjfontaine>and monads
20:10:59  * c4milojoined
20:11:10  <isaacs>tjfontaine: so, how many steps is it to make a build these days?
20:11:26  <tjfontaine>I've done abotu 4 right now
20:11:33  <tjfontaine>it could easily be less
20:11:39  <tjfontaine>I just have been preoccupied
20:11:42  <bnoordhuis>tjfontaine: i know you're kidding but agreed on the hygienic macros
20:11:56  <tjfontaine>bnoordhuis: I'm only 50% joking
20:15:01  <MI6>joyent/node: isaacs master * 993bb93 : streams: Don't emit 'end' until read() past EOF - http://git.io/MYBdFQ
20:15:12  * dshaw_quit (Quit: Leaving.)
20:15:52  <isaacs>i really think we ought to just have util.isBlah() and util.toBlerg() rather than macros
20:16:03  <isaacs>and if V8 creates crappy asm for that, then bug the v8 team to fix that
20:19:23  <trevnorris>since the functions these checks will be going into are almost always larger than 600 characters (i.e. can't be inlined) the amount of time we're saving from a single check couldn't be measured by a benchmark.
20:20:38  * amartensjoined
20:21:07  <trevnorris>i mean, I prefer !(arg >= arg) over isNaN() but unless the function it contains is inline-able you're not going to measure any performance gains.
20:22:08  <isaacs>trevnorris: but the util functions would be inlineable
20:22:33  <isaacs>you're right, though, if anyone can show any relevant perf improvements from this, they're probably using node for the wrong sort of problems.
20:22:34  <bnoordhuis>isaacs: they're also monkeypatchable by users, which macros are not
20:22:38  * mikealjoined
20:22:42  <isaacs>bnoordhuis: yeah
20:22:47  <isaacs>bnoordhuis: so what?
20:22:48  <trevnorris>isaacs: yeah, those would be.
20:23:06  <bnoordhuis>isaacs: so macros are more robust at no cost
20:23:12  <bnoordhuis>win all around
20:23:20  <isaacs>bnoordhuis: there's a cost in complexity
20:23:49  <isaacs>bnoordhuis: users can monkey patch global.isNaN also, or var undefined=10
20:23:54  <isaacs>bnoordhuis: who cares?
20:24:34  <isaacs>bnoordhuis: it adds a conceptual step between reading the code, and what actually gets run.
20:25:05  <isaacs>bnoordhuis: that's one of the reasons why we removed the macros we had once upon a time (or at least, the reason i argued for it)
20:25:16  <bnoordhuis>eh, if someone can't deal with that, he has no reason hacking on node core in the first place
20:25:26  <isaacs>bnoordhuis: that's neckbeardism
20:25:56  <bnoordhuis>i don't mind raising the barrier to entry a little if that means less crappy pull requests to review
20:26:01  <bnoordhuis>that aside
20:26:12  <isaacs>bnoordhuis: we should work on making node more accessible, not dismissing potential contributors as too noobish
20:26:29  <isaacs>bnoordhuis: what we'll get is people confused that TO_NUMBER doesn't work in their code.
20:28:33  <isaacs>we should be lowering the barrier to entry, and making node easier to understand, so that we get more GOOD pull requests.
20:28:47  <bnoordhuis>yeah, only it doesn't work that way, does it?
20:29:03  <isaacs>it does.
20:29:13  <isaacs>i mean, if you get more pull reqs period, you get more crappy ones.
20:29:27  <isaacs>most people are crappy programmers.
20:29:30  <isaacs>including us :)
20:29:43  <isaacs>bnoordhuis: you and i have probably put more bugs into node than almost anyone else :)
20:30:20  <bnoordhuis>if you look at pull requests that target the js vs the c or c++ parts of node, the js pull requests are generally of a decidedly lower quality
20:31:01  <bnoordhuis>which is to be expected because the js side is a lot more approachable (also, there are probably more js programmers out there)
20:31:23  <isaacs>bnoordhuis: well, there are also way more of them
20:31:30  <bnoordhuis>which is why i like high barriers because life's too short to sift through crappy pull request after crappy pull request
20:31:36  <isaacs>bnoordhuis: this is the price of success.
20:31:42  <bnoordhuis>i don't know
20:31:52  <bnoordhuis>i used to work on apache (the httpd)
20:32:04  <bnoordhuis>which is more successful than node in just about every way
20:32:21  * jmar777_quit (Remote host closed the connection)
20:32:23  <isaacs>httpd is a different sort of program.
20:32:29  <isaacs>most people who use httpd don't write modules for it
20:33:25  <isaacs>look, bottom line, "Making it harder for people to understand so that our pull reqs come from smarter people" is not a strategy this project is going to take.
20:33:56  * c4miloquit (Remote host closed the connection)
20:34:14  <isaacs>adding extra build steps so that our functions can't be overridden is silly.
20:34:21  <bnoordhuis>okay, if you're volunteering to deal with the low quality pull requests that flow from that
20:34:22  <tjfontaine>http://nodejs.org/dist/v0.10.14/ before I go much further, everything looks good?
20:34:22  * c4milojoined
20:34:38  <isaacs>bnoordhuis: i'm not volunteering to deal with them, and neither are you. both of us are doing this because we get paid to.
20:34:43  <bnoordhuis>because i'm pretty much through with that, it takes too much time and it's not rewarding in the slightest
20:35:05  <creationix>is lchmodSync supposed to exist on Linux?
20:35:11  <creationix>My node doesn't have it
20:35:14  <isaacs>creationix: no.
20:35:15  <bnoordhuis>creationix: no, it's a darwinism
20:35:20  <isaacs>well, bsd-ism
20:35:44  <creationix>hmm, othiym23 is using it in some unit tests. I guess I can wrap that in a try..catch?
20:36:02  <isaacs>bnoordhuis: anyway, yes, i hear you. you are frustrated dealing with crappy pull requests and uninformed issues. you've also been bearing most of the weight of that job, and it's not particularly rewarding.
20:36:16  * c4miloquit (Read error: No route to host)
20:36:16  <isaacs>bnoordhuis: i don't think that adding macros will fix that problem. that's a separate issue.
20:36:22  * c4milo_joined
20:36:38  * kazuponjoined
20:36:51  <bnoordhuis>sure. but saying that macros are bad because they make the source harder to understand is something i don't agree with
20:37:10  <bnoordhuis>i mean, they may make it a little harder but that's not a reason not to add them
20:37:13  <isaacs>bnoordhuis: they don't make the source MUCH harder to understand. they make it ANY harder to understand, and i'm not sold that it's worth the effort.
20:37:24  <isaacs>i think it is a reason not to add them.
20:37:39  <bnoordhuis>...
20:38:08  <isaacs>i can see the reason to use someFunction(arg) rather than !!+(arg)
20:38:12  <isaacs>or ~~arg
20:38:34  <isaacs>but i think that's what the util module is for. that's why we have it.
20:38:59  <othiym23>TIL that the contents of require('fs') vary from platform to platform
20:39:18  <othiym23>are there any other instances of that happening aside from fs.lchmodSync?
20:39:37  <bnoordhuis>no. lchmod was an oversight
20:39:38  <isaacs>othiym23: graceful-fs patches those differences up.
20:39:48  <othiym23>ah, I see the documentation now
20:39:57  * othiym23shakes his fist at graceful-fs
20:40:01  <isaacs>bnoordhuis: lchmod is important for being able to make symlinks to executables on os x
20:40:15  <isaacs>iirc
20:40:38  <tjfontaine>hearing no objection, I will continue down my release path :)
20:40:50  <isaacs>tjfontaine: go for it :)
20:40:54  <othiym23>I may just yoink that particular polyfill for my tests tho; seems the fastest path through since I'm only using lchmodSync in tests
20:41:09  * kazuponquit (Ping timeout: 248 seconds)
20:41:14  <bnoordhuis>isaacs: back to the macros, your obstructionism is the kind of shit that makes me not want work on node
20:41:28  <bnoordhuis>the node code base should be technically great, not cater to lesser programmers
20:42:06  <isaacs>bnoordhuis: this isn't obstructionism.
20:42:11  <bnoordhuis>open source is great but apache, linux, etc. didn't become great by dumbing things down
20:42:20  <isaacs>bnoordhuis: i'm not suggesting we make the code base worse.
20:42:35  <bnoordhuis>not worse but also not better
20:42:36  <isaacs>in fact, i think macros in this case are just unnecessary microoptimization
20:42:48  <isaacs>i don't see the benefit over using plain js functions
20:43:03  <othiym23>not that anybody asked my opinion, my only real problem with doing the tests as macros is that what you see in the source tree is going to be different than what you see in the debugger
20:43:25  <isaacs>othiym23: yes, that's basically my point. the code running is not the same as the code that you're typing.
20:43:38  <bnoordhuis>that's only an issue for people that debug node core
20:43:52  <bnoordhuis>of which there probably aren't that many
20:44:17  * mikealquit (Quit: Leaving.)
20:44:43  <isaacs>bnoordhuis: everyone running node in production ends up debugging node core in some fashion at some point.
20:45:01  <isaacs>bnoordhuis: they might not be sending us patches or reading pull reqs daily
20:45:09  <isaacs>but there's more than you think
20:45:27  * pachetquit (Quit: leaving)
20:45:44  * pachetjoined
20:45:45  <bnoordhuis>okay, maybe
20:45:56  <bnoordhuis>but then any major change to node core makes life for those people harder
20:45:58  <othiym23>bnoordhuis: I spend a very large chunk of my time living in the core code in the debugger, and I think anybody writing their own control flow modules will end up in the same boat
20:46:04  <bnoordhuis>streams2 must've been hell for them
20:46:12  <isaacs>bnoordhuis: yeah, for some of them it was.
20:46:24  <othiym23>I don't think it's a huge deal, because it won't take that long to figure out what's going on
20:46:28  <isaacs>bnoordhuis: that's why i've spent a lot of time figuring out how to make things better in 0.12
20:46:55  <bnoordhuis>well, fwiw, i work on node core and i still don't really understand how the new streams work internally
20:46:56  <isaacs>bnoordhuis: i'm not saying "no changes ever"
20:46:56  <othiym23>but it should FOR SURE be documented somewhere prominent that macro expansion is happening on lib/ if you decide to do that
20:47:07  <isaacs>bnoordhuis: you could read the docs. they explain it pretty well.
20:47:30  <bnoordhuis>i've read the docs. i mean how the stuff in lib/_stream_*.js ties everything together
20:47:36  <bnoordhuis>well whatever, water under the bridge
20:48:21  <isaacs>bnoordhuis: fwiw, the code in master is a bit simpler.
20:48:26  <mmalecki>isaacs: I've been debugging node core in production few times and macros never occured to me as "hard"
20:48:45  <mmalecki>they are a part of the language node is written in
20:48:54  <mmalecki>I think it's sane to use them
20:48:56  <isaacs>mmalecki: talking about macros in the js
20:49:00  <isaacs>mmalecki: not in C
20:49:36  <mmalecki>oh, welp, gotta go back a little more in my scrollback :-)
20:51:27  <MI6>joyent/node: tjfontaine created tag v0.10.14 - http://git.io/e31g0g
20:52:29  <trevnorris>ooh, my new phone case came. going to go have a pizza and throw my phone around a bit to test it out.
20:52:31  * trevnorris&
20:53:53  * c4milo_quit (Remote host closed the connection)
20:54:19  * c4milojoined
20:55:21  <MI6>joyent/node: Timothy J Fontaine v0.10 * 0256edc : blog: Post for v0.10.14 (+3 more commits) - http://git.io/eNB3Pg
20:58:52  * c4miloquit (Ping timeout: 256 seconds)
21:00:48  * c4milojoined
21:03:22  <isaacs>tjfontaine:
21:03:23  <isaacs>20:56 < defunctzombie> isaacs: what versions of libc do you build node against?
21:03:23  <isaacs>20:56 < defunctzombie> seems to want >= 2.14?
21:03:23  <isaacs>21:00 < defunctzombie> isaacs: yep, installing latest node binary on debian stable does not work :)
21:03:26  <isaacs>21:00 < defunctzombie> node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by node)
21:03:27  <defunctzombie>tjfontaine: isaacs told me to bug you about the latest build not working on debian stable
21:03:29  <isaacs>21:00 < defunctzombie> node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by node)
21:03:32  <isaacs>21:01 < isaacs> defunctzombie: yeah, i guess
21:03:35  <isaacs>21:01 < defunctzombie> any reason that changed from before?
21:03:37  <isaacs>21:01 < defunctzombie> I had 0.10.12 installed without issue
21:03:40  <isaacs>21:04 < defunctzombie> isaacs: and any way to get that fixed?
21:03:45  <isaacs>defunctzombie: just pasted our conv from #stackvm
21:03:50  <defunctzombie>I see that :)
21:04:19  <tjfontaine>right ok, so I can re-rebuild on a much older version of linux that would make the centos people happy as well
21:04:55  <defunctzombie>tjfontaine: yea, probably a good idea
21:05:04  <tjfontaine>it's ubuntu 12.04 iirc
21:05:08  <defunctzombie>tjfontaine: otherwise all the binaries won;t be usable
21:05:19  <defunctzombie>for us on "stable" systems hahaha
21:05:31  <defunctzombie>compiled software FTW!
21:05:35  <tjfontaine>we all have different definitions of what that means, but yes, glibc is a pain in the ass
21:09:55  <defunctzombie>yes we do
21:10:06  <defunctzombie>and we all know that I am right! :D
21:10:27  <defunctzombie>tjfontaine: on what machines do you build this stuff on?
21:10:44  <defunctzombie>you could use digitalocean to spin up a box and break it down quickly for build
21:10:58  <tjfontaine>defunctzombie: joyent is a hosting company, DO won't be necessary :)
21:11:03  <tjfontaine>is glibc 2.10 old enough?
21:11:04  <defunctzombie>:)
21:11:09  <tjfontaine>what's on centos-ancient?
21:11:48  <bnoordhuis>tjfontaine: we can fix that in node itself with a bit of hacking
21:11:51  * defunctzombielooking for a package.debian.org equivalent for centos
21:12:09  <defunctzombie>2.10 should be old enough
21:12:10  <tjfontaine>centos-5 has 2.5
21:12:14  <defunctzombie>wut
21:12:19  <defunctzombie>wow
21:12:25  <tjfontaine>http://lists.centos.org/pipermail/centos-announce/2013-May/019769.html
21:12:27  <bnoordhuis>just need to define asm aliases for the functions that link to 2.14/2.15
21:13:10  <tjfontaine>bnoordhuis: ya, but that's a lot of effort, isn't it easier for me to just change what I build releases on?
21:13:37  <bnoordhuis>sure, that works too
21:13:49  <tjfontaine>how far back do we want to go? should we care about centos5?
21:13:57  <bnoordhuis>it's just that you have to remember to keep building on old systems
21:14:05  <tjfontaine>bnoordhuis: it's all done in jenkins, it aint no thing
21:14:15  <bnoordhuis>fwiw, libuv supports glibc 2.3 and up
21:14:25  <bnoordhuis>2.3.3, really
21:14:40  <tjfontaine>lemme see how old I can get in the JPC
21:15:28  <tjfontaine>we have centos 5.7 it seems, if we want to go earlier it will need to be a custom image, which isn't out of the question
21:16:04  <isaacs>tjfontaine: why would it have worked with 10.12, though?
21:16:18  <tjfontaine>isaacs: you built on ubuntu.nodejs.org I built on the jenkins slave
21:16:19  <isaacs>tjfontaine: that's teh last one i did, and it was on ubuntu.nodejs.org
21:16:23  <isaacs>tjfontaine: ohhh, right
21:16:25  <isaacs>ok
21:16:31  <isaacs>yeah, that zone is a bit older.
21:16:36  <tjfontaine>ya, it's 10.04
21:17:04  <tjfontaine>but there were people in #node.js after last release complaining about centos5 not working either
21:17:16  <bnoordhuis>tjfontaine: out of curiosity, what does `objdump -T out/Release/node | grep GLIBC_2 | grep -v 'GLIBC_2.[23]'` print?
21:17:21  <tjfontaine>so I am going to provision one of those and build on it for now
21:17:23  <tjfontaine>bnoordhuis: moment
21:18:00  <tjfontaine>on an old build I have
21:18:00  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __open64_2
21:18:00  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __pread64_chk
21:18:00  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __isoc99_sscanf
21:18:00  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __stack_chk_fail
21:18:02  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __read_chk
21:18:05  <tjfontaine>but that's 10.04
21:18:32  <bnoordhuis>interesting, i only have memcpy and __isoc99_scanf
21:18:46  <bnoordhuis>well okay, nvm then
21:19:42  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __open64_2
21:19:42  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __pread64_chk
21:19:42  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy
21:19:42  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.7 __isoc99_sscanf
21:19:42  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __stack_chk_fail
21:19:44  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.15 __fdelt_chk
21:19:47  <tjfontaine>0000000000000000 DF *UND* 0000000000000000 GLIBC_2.4 __read_chk
21:19:49  <tjfontaine>on the 12.04 system
21:21:37  <tjfontaine>do we still need the old centos-6 image? (isaacs)
21:22:06  <isaacs>tjfontaine: i haven't used it in forever.
21:22:21  <tjfontaine>isaacs: ok
21:22:21  <isaacs>tjfontaine: but every once in a while, there's some kind of centos-only bug, and it's handy
21:22:34  <tjfontaine>well I'm going to replace it with a 5.7 :)
21:22:36  <MI6>joyent/node: Ben Noordhuis v0.10 * 0de5b83 : doc: document tls.Server 'secureProtocol' option - http://git.io/joizgA
21:33:25  * julianduquejoined
21:34:36  <defunctzombie>isaacs: http://blog.nodejs.org/ maybe mention that build will be updated?
21:35:02  <isaacs>tjfontaine: ^
21:35:33  <tjfontaine>mmk
21:35:43  * rendarquit
21:35:45  <isaacs>there's no need to mention that it will be updated, i don't think
21:36:01  <isaacs>but if you push a new binary, then the shasum has to be fixed on the blog, and in the SHASUMS* files
21:36:19  <tjfontaine>ok, I was already planning on all of that
21:36:25  <defunctzombie>cool
21:36:48  <defunctzombie>sneak it in under the radar!
21:37:18  * kazuponjoined
21:40:58  <isaacs>yeah, no reason to raise alarms over this.
21:41:10  <isaacs>nothing serious. if you don't already bump into it, you don't care.
21:42:06  * kazuponquit (Ping timeout: 264 seconds)
21:51:05  <defunctzombie>tjfontaine: ping me when the new builds go up and I can install and debian stable and report back
21:51:20  <tjfontaine>defunctzombie: mk
21:51:30  <tjfontaine>thanks for reporting it
21:52:48  <defunctzombie>np
22:03:34  <tjfontaine>welp
22:03:41  <tjfontaine>looks like we'll have v0.10.15 sooner than later
22:03:58  <tjfontaine>isaacs: https://github.com/joyent/node/issues/5904
22:04:21  <tjfontaine>and bnoordhuis I guess
22:04:42  <isaacs>yeah, that's weird...
22:04:45  <isaacs>ohh.....
22:04:55  <isaacs>because fs.chown(-2) probably?
22:05:14  <tjfontaine>is that npm/graceful-fs is doing?
22:05:17  <tjfontaine>*what
22:05:29  <tjfontaine>or a side effect of my build?
22:05:39  <defunctzombie>hahaha
22:05:42  <defunctzombie>I love updating software
22:05:49  * `3Echanged nick to `3E|AFQZZ
22:05:51  <defunctzombie>always leads to a pleasant experience :)
22:06:28  <isaacs>i don't know ,it works fine over here.
22:07:26  <tjfontaine>isaacs: not at least built from what I made with the .pkg, which as you recall does whine during build about the -2 issue
22:07:47  <tjfontaine>or packagemaker whines
22:07:58  <isaacs>yep ed80638
22:08:49  <tjfontaine>also fucking git-scm.org
22:08:55  <tjfontaine>or .com
22:10:17  <isaacs>ok, reproducing
22:10:24  * mikealjoined
22:11:53  <isaacs>$ sudo -u nobody node -p 'process.getuid()'
22:11:54  <isaacs>-2
22:12:16  <isaacs>bnoordhuis: ping
22:13:45  <tjfontaine>I know the fix
22:13:59  <tjfontaine>GetUid and GetGid in node.cc need to be Integer::NewFromUnsigned()
22:16:07  * TooTallNatequit (Ping timeout: 256 seconds)
22:16:37  <othiym23>that's my fault originally, I think
22:16:50  <bnoordhuis>isaacs: https://github.com/joyent/node/issues/5904
22:16:59  * jmar777joined
22:17:04  <bnoordhuis>oh, you've seen it
22:17:07  <tjfontaine>yes, nobody is -2 on osx
22:17:22  <bnoordhuis>yeah, in /etc/passwd
22:17:23  <isaacs>bnoordhuis: yeah, -2 is a valid uid on osx
22:17:33  <othiym23>or at least I reported that node was incorrectly barfing on being fed the output of "id -u nobody", which is the unsigned cast of signed -2
22:17:34  <bnoordhuis>well... yes and no
22:17:40  <othiym23>why Darwin does this, I donut know
22:17:50  <bnoordhuis>they're stored as negative numbers in /etc/passwd
22:17:53  <isaacs>that is, it casts unsigned and gets $bignumber
22:17:55  <bnoordhuis>but uid_t and gid_t are unsigned
22:18:01  <isaacs>bnoordhuis: but process.getuid() reports -2
22:18:14  <tjfontaine>because it's Integer::New not NewFromUnsigned
22:18:17  <othiym23>yeah, but uid_t is still unsigned int, so everything reports it as 4294967294
22:18:26  <bnoordhuis>ah, then process.getuid() needs fixing
22:18:31  <isaacs>yep
22:18:33  <isaacs>asap :)
22:18:34  <bnoordhuis>process.getgid() too, no doubt
22:19:11  * austoquit (Remote host closed the connection)
22:19:33  * TooTallNatejoined
22:19:38  <bnoordhuis>curious... nobody is -2:-2 according to /etc/passwd
22:19:58  <bnoordhuis>oh wait, nvm
22:20:02  <othiym23>bnoordhuis: "id -g nobody" => 4294967294 as well
22:20:53  <isaacs>$ sudo -u nobody node -p '[process.getuid(),process.getgid()]'
22:20:54  <isaacs>[ -2, -2 ]
22:21:53  <bnoordhuis>$ sudo -u nobody out/Release/node -p 'process.getuid()'
22:21:53  <bnoordhuis>4294967294
22:22:05  <bnoordhuis>ah
22:22:13  <bnoordhuis>it works okay in master, not in v0.10
22:22:35  <bnoordhuis>i guess that's one more reason args.GetReturnValue().Set() is a good thing
22:22:59  <tjfontaine>meh, overloading magic, it was an accident :)
22:23:52  * qmxquit (Ping timeout: 256 seconds)
22:23:57  <isaacs>in the meantime, i can make a patch for npm to cast negative uids to overflow
22:24:00  <isaacs>but... ugh
22:24:10  <isaacs>people can't install it once they're broken, so we have to release a 0.10.15 anyway
22:24:13  <tjfontaine>doesn't matter, they can't install it
22:24:15  <isaacs>right
22:24:33  <tjfontaine>well, at least not without manual hackery
22:26:31  * qmxjoined
22:28:27  * st_lukejoined
22:28:31  <defunctzombie>the issues roll in pretty fast for new releases
22:28:34  <defunctzombie>quite impressive
22:29:42  <tjfontaine>ya, our users are quite good at early adoption
22:29:42  * st_lukequit (Read error: Connection reset by peer)
22:29:47  * pachetquit (Quit: leaving)
22:31:03  * indexzerojoined
22:31:16  <MI6>joyent/node: bnoordhuis created branch fix-getuid-review - http://git.io/GpgynA
22:31:23  <bnoordhuis>tjfontaine, isaacs: ^
22:31:35  <bnoordhuis>it was using int. int!
22:33:09  <tjfontaine>lgtm, I wonder if there's a way to test reliably
22:33:39  <isaacs>tjfontaine: not without elevated privs
22:34:05  <tjfontaine>8~nod
22:34:06  <tjfontaine>*nod
22:34:09  * saghul_joined
22:34:20  <MI6>joyent/node: Ben Noordhuis v0.10 * 015ec05 : src: fix process.getuid() return value - http://git.io/Ytf3XQ
22:34:22  * mburns_joined
22:34:23  * pfox___joined
22:34:25  <isaacs>but i'll test locally
22:34:28  <isaacs>oh, or that
22:34:29  <isaacs>:0
22:34:30  * saghulquit (Ping timeout: 248 seconds)
22:34:30  * Chip_Zeroquit (Ping timeout: 248 seconds)
22:34:30  * saghul_changed nick to saghul
22:34:31  * dscapequit (Ping timeout: 248 seconds)
22:34:31  * pquernaquit (Ping timeout: 248 seconds)
22:34:32  * mburnsquit (Ping timeout: 248 seconds)
22:34:32  * pfox__quit (Ping timeout: 248 seconds)
22:34:34  * pquerna_joined
22:34:43  * pquerna_quit (Changing host)
22:34:43  * pquerna_joined
22:34:45  * pquerna_changed nick to pquerna
22:34:57  * dshaw_joined
22:37:49  * kazuponjoined
22:39:12  <bnoordhuis>okay, signing off. have a great evening, folks
22:39:49  * mburns_changed nick to mburns
22:41:02  <tjfontaine>gnight bnoordhuis
22:41:17  <tjfontaine>isaacs: I'll do some more testing, and then start the new release
22:42:14  * kazuponquit (Ping timeout: 240 seconds)
22:43:16  <isaacs>well, it fixes npm, so that's nice
22:43:57  * bnoordhuisquit (Ping timeout: 264 seconds)
22:53:27  * c4miloquit (Remote host closed the connection)
22:53:54  * c4milojoined
22:58:40  * c4miloquit (Ping timeout: 276 seconds)
23:01:13  * st_lukejoined
23:07:03  * st_lukequit (Read error: Connection reset by peer)
23:07:42  * c4milojoined
23:18:05  <MI6>joyent/node: Dav Glass master * 7d654be : doc: Fix missing backtick in debugger doc - http://git.io/Ptv0IQ
23:18:45  <tjfontaine>isaacs: anything else you want to get in v0.10 :)
23:18:57  <isaacs>tjfontaine: nah, go for it :)
23:19:05  <tjfontaine>ROUND 2
23:19:08  <tjfontaine>FIGHT.
23:20:46  * c4miloquit (Remote host closed the connection)
23:21:12  * c4milojoined
23:23:42  <isaacs>tjfontaine: is there a tarball we can point chrislea at ahead of the binaries finishing, or is it all one thing?
23:24:26  <tjfontaine>I can copy it into place before the rest is done
23:24:57  <isaacs>tjfontaine: that'd be awesome
23:25:24  <tjfontaine>ok, is he on irc?
23:25:54  * c4miloquit (Ping timeout: 264 seconds)
23:26:45  <MI6>joyent/node: tjfontaine created branch v0.10.15-release - http://git.io/W4jicQ
23:31:23  * Damn3dquit (Ping timeout: 264 seconds)
23:38:27  * Damn3djoined
23:38:31  * kazuponjoined
23:41:32  <rvagg>any chance of getting this doc change in to 0.10.15? https://github.com/joyent/node/pull/5809
23:43:21  * kazuponquit (Ping timeout: 264 seconds)
23:43:24  <tjfontaine>unfortunately no :/ I forgot about it I'm sorry
23:43:33  <tjfontaine>but at this rate in 4 hours I'll be doing it all over again
23:46:14  * saghulquit (Ping timeout: 240 seconds)
23:46:54  * philips_joined
23:48:06  <tjfontaine>defunctzombie: http://nodejs.org/dist/v0.10.15/ I put those binary tarballs in there early for you to try
23:49:06  * saghuljoined
23:50:25  * bnoordhuisjoined
23:51:32  <defunctzombie>tjfontaine: nice
23:51:39  <defunctzombie>lemme give them a go
23:52:55  <defunctzombie>tjfontaine: so far so good, installed fine and node --version reports 0.10.15
23:53:05  <tjfontaine>excellent.
23:53:19  <tjfontaine>it now appears to work back to glibc 2.4
23:53:37  <tjfontaine>so not as old as we can get, but pretty fucking old
23:54:01  * jmar777quit (Remote host closed the connection)
23:54:50  <defunctzombie>that is quite old
23:55:16  <tjfontaine>it's as old as I care to really support for now
23:55:18  * bnoordhuisquit (Ping timeout: 264 seconds)
23:58:07  <MI6>joyent/node: tjfontaine created tag v0.10.15 - http://git.io/uU9vtA