00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:38  * loladiroquit (Quit: loladiro)
00:00:45  * kazuponjoined
00:06:14  * kazuponquit (Ping timeout: 252 seconds)
00:06:58  <gblock>@tjfontaine > 0.6.15 < 0.9
00:08:40  <gblock>@tjfontaine so what we want is to have one get an error if they use > 0.8.x
00:08:43  <gblock>saying not supported
00:08:56  <gblock>instead what is happening, is npm jus serves the previous version that did not have the restriction
00:08:59  * brson_quit (Ping timeout: 252 seconds)
00:09:57  * brsonjoined
00:18:46  * rvaggjoined
00:22:30  <isaacs>gblock: the engines field is strictly advisory now
00:22:53  <gblock>even if we set it as strict?
00:22:56  <isaacs>gblock: this was by massive public demand around the 0.6 time
00:23:02  <isaacs>gblock: "enginesstrict" was never a thing
00:23:21  <gblock>does it not work?
00:23:31  <isaacs>gblock: well, it doesn't NOT work. it does nothing. it never did anything.
00:23:43  <gblock>oh
00:23:43  <isaacs>it's just a field on the json object, like if you wrote "arblegarble":"grableflubr"
00:23:48  <gblock>crap
00:23:48  <gblock>ok
00:23:51  <gblock>that explains it
00:23:54  <gblock>is there any option?
00:23:54  <isaacs>gblock: "engines" will print a warning
00:23:56  <isaacs>but that's it
00:23:56  <gblock>install script?
00:23:59  <gblock>ok
00:24:02  <isaacs>you can use an install script. but... ew.
00:24:07  <isaacs>gblock: what's the actual issue?
00:24:07  <gblock>thank you for clarifying
00:24:11  <gblock>what would you suggest in this case?
00:24:18  <gblock>anyone who installs our modules is borked
00:24:20  <gblock>we want to fix it....
00:24:21  <isaacs>gblock: what's the cost of making the module work on 0.10?
00:24:23  <gblock>but in the time being
00:24:32  <gblock>we don't know yet…we'll know in a week or so
00:24:32  <isaacs>gblock: what's the module? i'll fix it right now.
00:24:39  <gblock>azure
00:24:44  <gblock>and azure-cli
00:24:48  <isaacs>gblock: where's the bug? got a test?
00:25:06  <isaacs>gblock: i don't use azure regularly, not super familiar with it except for a few little demo's a long time ago
00:25:33  <gblock>the cli I can tell you what to do to repro
00:25:36  <gblock>I need to send you a file
00:25:42  * mmaleckichanged nick to mmalecki[zz]
00:25:42  <isaacs>gblock: okie dokie
00:25:45  <isaacs>gblock: i@izs.me
00:25:57  <gblock>thanks isaacs
00:25:59  <isaacs>gblock: or mention @isaacs on an issue in github or whatever.
00:26:05  <isaacs>i'll take a look
00:26:05  <gblock>ok
00:27:06  <gblock>ok so I'll send you repro steps
00:27:12  <gblock>thanks again
00:28:43  * qmx|awaychanged nick to qmx
00:28:48  <ircretary>Can one of the admins verify this patch?
00:29:06  * askabtjoined
00:30:33  <gblock>isaacs: sending you a mail in 2 mins with instructions
00:37:53  <gblock>@isaacs sent!
00:43:37  * loladirojoined
00:48:40  * askabtquit (Ping timeout: 246 seconds)
00:50:30  * loladiroquit (Ping timeout: 264 seconds)
00:51:52  * c4miloquit (Remote host closed the connection)
00:52:53  * c4milojoined
01:02:06  * sgallaghquit (Remote host closed the connection)
01:02:08  * kazuponjoined
01:03:44  * loladirojoined
01:03:59  * askabtjoined
01:06:56  * kazuponquit (Ping timeout: 255 seconds)
01:09:12  * askabtquit (Ping timeout: 264 seconds)
01:13:41  * bnoordhuisquit (Ping timeout: 255 seconds)
01:14:43  <isaacs>gblock: in the short term, you should just add a check in function checkVersion() {
01:14:51  <isaacs>gblock: since yoer' already checking for the version anyway
01:15:16  <tjfontaine>on the plus side people interested have already closed pullreqs
01:15:20  <tjfontaine>:/
01:15:27  <isaacs>nice
01:15:42  <tjfontaine>just depressing on all the emails it spawned
01:29:07  <isaacs>gblock: it's the console.error('call pfx2pem')
01:29:13  <isaacs>gblock: er, it's the pfx2pem stuff
01:30:02  * abraxasjoined
01:33:18  * dapquit (Quit: Leaving.)
01:37:22  <isaacs>gblock: this looks fishy:
01:37:24  <isaacs>cursor.next { element:
01:37:24  <isaacs> { tagClass: 0,
01:37:24  <isaacs> tagConstructed: 1,
01:37:24  <isaacs> tagNumber: 16,
01:37:27  <isaacs> tag: 'UNIVERSAL-constructed-10',
01:37:29  <isaacs> length: 2.0878980696102425e+299,
01:37:32  <isaacs> buffer: <Buffer > },
01:47:11  * gblockquit (Quit: gblock)
01:53:59  * kazuponjoined
01:57:24  * kazuponquit (Remote host closed the connection)
01:59:19  * qmxchanged nick to qmx|away
02:09:58  * indexzerojoined
02:23:14  * wavdedjoined
02:25:16  * loladiroquit (Quit: loladiro)
02:30:57  * gblockjoined
02:34:21  <isaacs>gblock: sent email with more details and debug output
02:34:46  <isaacs>gblock: it's in the guts of the pfx parser. probably some obscure thing it's doing with buffer slicing.
02:35:24  <gblock>ok
02:35:52  <gblock>yes we do have code for that in the cli
02:35:54  <gblock>but not in the sdk
02:35:59  <gblock>which I "think" may also be broken
02:40:19  <gblock>@isaacs thanks for the pointer
02:43:49  * wavdedquit (Quit: Computer has gone to sleep.)
02:45:14  * gblockquit (Quit: gblock)
02:48:29  * askabtjoined
02:49:01  * gblockjoined
02:51:17  * loladirojoined
02:52:33  * gblockquit (Client Quit)
03:05:43  * gblockjoined
03:07:43  * brsonquit (Ping timeout: 264 seconds)
03:13:47  * gblockquit (Quit: gblock)
03:15:57  * gblockjoined
03:28:13  * dominictarrquit (Quit: dominictarr)
03:32:51  * gblockquit (Quit: gblock)
03:34:41  * trevnorrisjoined
03:35:31  * mikealjoined
03:57:34  * brsonjoined
03:58:33  <tjfontaine>freebsd diaf
03:58:35  * kazuponjoined
04:00:01  * kazupon_joined
04:00:05  * kazuponquit (Read error: Connection reset by peer)
04:00:31  * abraxasquit (Remote host closed the connection)
04:21:15  * askabtquit (Ping timeout: 256 seconds)
04:41:52  * c4miloquit (Remote host closed the connection)
04:44:43  * askabtjoined
04:52:04  * askabtquit (Ping timeout: 260 seconds)
04:52:33  * mikealquit (Quit: Leaving.)
04:59:46  * mikealjoined
05:01:02  * dominictarrjoined
05:11:45  * trevnorrisquit (Quit: Leaving)
05:21:22  * abraxasjoined
05:21:46  * perezdquit (Quit: perezd)
05:23:27  * askabtjoined
05:33:40  * wolfeidauquit (Read error: Connection reset by peer)
05:33:56  * wolfeidaujoined
05:38:38  * stagasjoined
05:39:51  * csaohjoined
05:43:16  * csaohquit (Client Quit)
06:07:09  * wolfeidauquit (Remote host closed the connection)
06:08:47  * dominictarrquit (Quit: dominictarr)
06:10:11  * loladiroquit (Quit: loladiro)
06:15:36  * loladirojoined
06:18:30  * brsonquit (Quit: leaving)
06:22:08  * loladiroquit (Ping timeout: 256 seconds)
06:33:54  * askabtquit (Ping timeout: 276 seconds)
06:35:40  * loladirojoined
07:00:15  * stagas_joined
07:01:43  * stagasquit (Ping timeout: 264 seconds)
07:05:36  * stagas_quit (Ping timeout: 264 seconds)
07:05:59  * stagasjoined
07:07:27  * jguerreroquit (Quit: jguerrero)
07:23:43  * loladiroquit (Quit: loladiro)
07:34:32  * `3rdEdenjoined
07:38:27  * defunctzombiechanged nick to defunctzombie_zz
07:38:32  * stagasquit (Read error: Connection reset by peer)
07:38:56  * stagasjoined
07:41:02  * rendarjoined
07:48:29  * dominictarrjoined
07:57:49  * dominictarrquit (Quit: dominictarr)
08:01:33  * dominictarrjoined
08:03:37  <MI6>joyent/libuv: piscisaureus created branch v0.10 - http://git.io/fBKIEA
08:05:59  * dominictarrquit (Client Quit)
08:06:57  * dominictarrjoined
08:08:34  * dominictarrquit (Client Quit)
08:12:51  <MI6>libuv-v0.8: #19 UNSTABLE smartos (7/158) linux (13/158) osx (3/158) http://jenkins.nodejs.org/job/libuv-v0.8/19/
08:13:07  <MI6>libuv-master: #50 UNSTABLE windows (9/184) linux (5/183) smartos (10/183) osx (6/183) http://jenkins.nodejs.org/job/libuv-master/50/
08:14:41  * stagas_joined
08:16:36  * stagasquit (Ping timeout: 256 seconds)
08:16:36  * stagas_changed nick to stagas
08:20:52  * mmalecki[zz]changed nick to mmalecki
08:21:11  * stagasquit (Ping timeout: 255 seconds)
08:22:09  * stagasjoined
08:29:59  * csaohjoined
08:36:17  * stagasquit (Ping timeout: 245 seconds)
08:38:02  * kazupon_quit (Remote host closed the connection)
08:39:19  * kazuponjoined
08:40:27  * dsantiagoquit (Ping timeout: 245 seconds)
08:43:48  * abrahmjoined
09:00:30  * piscisaureus_joined
09:20:11  * dsantiagojoined
09:26:24  * stagasjoined
09:34:49  * kazuponquit (Remote host closed the connection)
09:37:42  * stagas_joined
09:39:48  * stagasquit (Ping timeout: 276 seconds)
09:40:04  * stagasjoined
09:42:29  * stagas_quit (Ping timeout: 240 seconds)
09:45:15  * stagas_joined
09:48:22  * stagasquit (Ping timeout: 246 seconds)
09:48:27  * stagas_changed nick to stagas
09:51:57  * zotjoined
09:54:38  * stagas_joined
09:56:39  * stagasquit (Ping timeout: 245 seconds)
09:56:49  * stagas_changed nick to stagas
10:02:43  * zot1joined
10:05:11  * zotquit (Ping timeout: 252 seconds)
10:05:39  * piscisaureus_quit (Ping timeout: 260 seconds)
10:06:58  * stagas_joined
10:09:03  * stagasquit (Ping timeout: 276 seconds)
10:09:08  * stagas_changed nick to stagas
10:10:23  * abraxasquit (Remote host closed the connection)
10:13:06  * stagas_joined
10:14:36  * stagasquit (Ping timeout: 264 seconds)
10:14:45  * stagas_changed nick to stagas
10:24:01  * Nicholas__joined
10:31:50  * Nicholas__quit (Quit: Leaving)
10:32:56  * stagas_joined
10:34:34  * stagasquit (Ping timeout: 245 seconds)
10:34:36  * stagas_changed nick to stagas
10:37:06  * hzjoined
10:42:22  * csaohquit (Quit: csaoh)
10:44:39  * stagas_joined
10:46:38  * stagas__joined
10:46:39  * stagasquit (Ping timeout: 245 seconds)
10:46:43  * stagas__changed nick to stagas
10:48:12  * hzquit (Ping timeout: 264 seconds)
10:49:31  * stagas_quit (Ping timeout: 260 seconds)
10:55:04  * stagas_joined
10:56:29  * stagasquit (Ping timeout: 240 seconds)
10:56:29  * stagas_changed nick to stagas
11:16:18  * wolfeidaujoined
11:17:00  * wolfeidauquit (Remote host closed the connection)
11:17:21  * wolfeidaujoined
11:17:46  * csaohjoined
11:23:01  * hzjoined
11:24:58  * loladirojoined
11:26:26  <roxlu>hi guys, I want to use the uv_queue_work feature and I was wondering if I can free()/delete a uv_work_t, in the ready callback when I alloc it on the heap?
11:31:42  <indutny>roxlu: yes
11:31:46  <indutny>you can do it
11:32:02  <roxlu>thanks
11:32:40  <roxlu>the more I use libuv the more I like it! it's one of the cleanest libs I've used : )
11:32:58  * stagas_joined
11:34:41  * stagasquit (Ping timeout: 255 seconds)
11:34:53  * stagas_changed nick to stagas
11:37:24  * hzquit (Ping timeout: 264 seconds)
11:45:52  * hzjoined
11:47:19  * bnoordhuisjoined
11:49:48  * hzquit (Disconnected by services)
11:52:37  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 9f714a1 : include: bump UV_VERSION_MINOR Fixes #740. - http://git.io/gcEOaA
11:52:39  * csaohquit (Quit: csaoh)
11:53:28  * hzjoined
11:54:19  <indutny>finally!
11:54:21  <indutny>morning, ben
11:54:33  * stagas_joined
11:55:39  <MI6>joyent/node: Adam Malcontenti-Wilson v0.10 * 028c630 : doc: change dgram to socket for properties of dgram.Socket Fixes #4919. - http://git.io/RTOmDw
11:56:36  * stagasquit (Ping timeout: 264 seconds)
11:56:42  * stagas_changed nick to stagas
11:58:24  * hzquit (Ping timeout: 264 seconds)
11:58:50  * hzjoined
12:04:38  * sgallaghjoined
12:04:42  <bnoordhuis>indutny: morning fedor
12:04:51  <bnoordhuis>check your pm
12:05:20  <indutny>empty?
12:05:33  <indutny>ircretary: notes
12:05:34  <ircretary>indutny: I don't have any notes for you.
12:08:53  <bnoordhuis>github's having its difficult five minutes again?
12:09:27  <saghul>"GitHub.com is currently unavailable due to what appears to be another DDoS attack."
12:09:31  <saghul>sigh
12:09:58  <bnoordhuis>i bet it's the russians
12:10:47  * abraxasjoined
12:10:58  <indutny>that was russian satellite
12:11:44  <indutny>god, who is DDoSing github?
12:11:48  <indutny>that's so odd
12:15:40  * abraxasquit (Ping timeout: 260 seconds)
12:20:27  * csaohjoined
12:26:00  * hzquit (Ping timeout: 264 seconds)
12:27:29  * stagasquit (Ping timeout: 245 seconds)
12:28:55  * c4milojoined
12:33:06  * zot1quit (Ping timeout: 264 seconds)
12:33:15  <roxlu>when I execute: npm link [somemodule], it tries to install a module which I don't want.. I was wondering where the information is stored that retrieves the URL where the module is downloaded from
12:35:05  * loladiroquit (Quit: loladiro)
12:39:12  * qmx|awaychanged nick to qmx
12:39:44  * c4miloquit (Remote host closed the connection)
12:58:36  * hzjoined
13:05:34  * loladirojoined
13:07:26  * zotjoined
13:09:01  * zotquit (Client Quit)
13:09:38  * zotjoined
13:16:11  * bradleymeckjoined
13:16:48  <indutny>and we're up again
13:21:53  * loladiroquit (Quit: loladiro)
13:26:18  * kazuponjoined
13:30:49  * bradleymeckquit (Quit: bradleymeck)
13:37:17  * loladirojoined
13:43:02  * kazuponquit (Remote host closed the connection)
13:43:04  * loladiroquit (Quit: loladiro)
13:46:35  <roxlu>indutny: I'm getting some really wierd results from npm
13:46:51  <roxlu>indutny: do you have sec?
13:50:18  <roxlu>well.. maybe someone else knows a bit how to debug this
13:50:48  <roxlu>I created a local dir for my npm modules (create a .npmrc + added my local bin dir to the PATH evn. variable)
13:51:10  <roxlu>I installed e.g. browserify: npm install -g browserify
13:51:29  <roxlu>and I confirmed it's installed in my ~/node/npm/lib/node_modules dir
13:51:43  <roxlu>now I want to link with it, so I go to my app and do: npm link browserify
13:51:55  <roxlu>which creates the necessary links
13:52:01  <roxlu>all seems fine till now
13:52:21  <roxlu>when I execute browserify I get "bash: /usr/local/bin/browserify: No such file or directory"
13:53:01  <roxlu>which I do: which -a browserify
13:53:16  <roxlu>I get: ~/node/npm/bin/borwserify
13:53:34  * sgallaghquit (Remote host closed the connection)
13:53:35  <`3rdEden>Is there a way to explain this massive slowdown in 0.10 compared to 0.8.22? https://gist.github.com/3rd-Eden/5161444
13:53:36  <roxlu>I can't figure out which is tries to execute /usr/local/bin/browserify
13:55:52  * sgallaghjoined
13:58:10  * c4milojoined
14:02:13  * loladirojoined
14:06:04  * loladiroquit (Client Quit)
14:07:40  * indexzeroquit (Quit: indexzero)
14:08:47  * qmxchanged nick to qmx|afk
14:11:18  * jguerrerojoined
14:25:13  * piscisaureus_joined
14:25:24  <piscisaureus_>bnoordhuis: hey, yt?
14:28:19  <bnoordhuis>piscisaureus_: yep
14:28:30  * sgallaghquit (Remote host closed the connection)
14:28:32  <piscisaureus_>bnoordhuis: how can I tell if there's a lot of kernel lock contention or not?
14:28:44  <bnoordhuis>piscisaureus_: with perf
14:28:49  * sgallaghjoined
14:28:53  * sgallaghquit (Remote host closed the connection)
14:28:59  * qmx|afkchanged nick to qmx
14:29:19  <bnoordhuis>piscisaureus_: more precisely, `perf record` or `perf top`
14:29:26  * mikealquit (Quit: Leaving.)
14:30:09  <bnoordhuis>`3rdEden: you could start by providing some more detail :-/
14:30:23  <bnoordhuis>i'm a man of many talents but mind reading is not one of them
14:30:57  <piscisaureus_>bnoordhuis: I hear body language isn't your strongest point either ben
14:31:25  <piscisaureus_>bnoordhuis: I think lock contention in the cluster send path is a big issie
14:31:31  <piscisaureus_>bnoordhuis: (for udb)
14:31:33  <piscisaureus_>*udp
14:31:33  <bnoordhuis>piscisaureus_: i disagree. i'm very good at telling when the mouth says 'no' but the eyes say 'yes'
14:32:14  <piscisaureus_>bnoordhuis: if I create a separate socket by binding to (10000 + cluster.worker.id) the send throughput goes up by x5
14:32:41  <bnoordhuis>piscisaureus_: that's not too surprising, i gues
14:32:43  <bnoordhuis>*guess
14:33:13  * sgallaghjoined
14:34:12  <`3rdEden>bnoordhuis: I'm still trying to pin point it down, but hashring are crypto heavy, so I'm assuming that changes to crypto API caused this slow down
14:34:55  <bnoordhuis>`3rdEden: have you run `node --prof --log`?
14:35:12  <`3rdEden>bnoordhuis: not yet, I focused on getting it compatible with the current release first
14:35:50  <MI6>joyent/libuv: bnoordhuis created branch improve-uv_guess_handle - http://git.io/rMu5Cw
14:35:52  * bradleymeckjoined
14:35:57  * sgallaghquit (Remote host closed the connection)
14:38:02  <isaacs>good morning
14:38:11  <bnoordhuis>hi isaac
14:39:29  * piscisaureus_quit (Ping timeout: 256 seconds)
14:39:47  <isaacs>`3rdEden: you know, you can keep using the v0.8 crypto api indefinitely
14:39:56  <isaacs>`3rdEden: the only breaking necesary change is that it uses buffers, not strings
14:40:06  * sgallaghjoined
14:40:43  <`3rdEden>isaacs: yes, and I thought that it was actually a benefitial change for my hashring as normally I would have to change the chars back to charCodes and with buffers I have access to the charcodes directly
14:40:52  <`3rdEden>but for some odd reason, it's much slower
14:41:02  <isaacs>`3rdEden: yeah, that is strange, then
14:41:20  <isaacs>`3rdEden: i was just meaning to say, if the slowdown happened when you started using streams, maybe don't.
14:41:27  <isaacs>`3rdEden: but of course, i'd still want to know about it :)
14:41:32  <isaacs>streams *should* be very fast, still
14:41:59  <isaacs>but yeah, if bufffers made it slower, then that's curious.
14:42:27  * kazuponjoined
14:44:36  * zotquit (Ping timeout: 264 seconds)
14:44:49  <indutny>`3rdEden: can I run benchmarks with some simple command?
14:44:58  <indutny>like node ./benchmark :)
14:45:01  <indutny>in hashring
14:45:50  <`3rdEden>indutny: making a smaller test as we speak
14:45:54  * stagasjoined
14:47:02  * piscisaureus_joined
14:47:46  <bnoordhuis>indutny: https://github.com/joyent/node/pull/5013 <- review?
14:50:11  <isaacs>bnoordhuis: https://github.com/isaacs/node/commit/dd2d42008762987c6c06a8ee2bc70c26dca8584a <-- review?
14:50:38  <indutny>lgtm
14:52:40  <`3rdEden>indutny: https://gist.github.com/3rd-Eden/5161444#file-test-js smaller test, same results
14:53:09  <bnoordhuis>indutny: thanks
14:53:37  <bnoordhuis>re merging the open() call, i initially had that in there
14:54:17  <bnoordhuis>i decided against it because createPipe() and createTCP() only create the handle and nothing else
14:54:25  <bnoordhuis>cognitive dissonance and all that
14:54:46  <indutny>ah
14:54:47  <indutny>well
14:54:49  <indutny>ok then
14:54:53  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 7b66ea1 : unix: improve uv_guess_handle() implementation Make it understand FIFOs, - http://git.io/-I3e0g
14:55:54  <MI6>joyent/node: Ben Noordhuis v0.10 * ca5022b : net: improve arbitrary tcp socket support Consider this example: // f (+1 more commits) - http://git.io/6RKHFw
14:56:26  <isaacs>indutny: are you still +1 on https://github.com/isaacs/node/commit/dd2d42008762987c6c06a8ee2bc70c26dca8584a?
14:56:40  <isaacs>indutny: i don't love it, but i don't see any reasonable alternative
15:00:19  <indutny>yes
15:00:21  <indutny>this sounds legit
15:04:19  <isaacs>i'm adding the benchmark script i was using, as well.
15:05:18  <MI6>joyent/node: isaacs v0.10 * d62cf59 : http: Don't hot-path end() for large buffers The benefits of the hot-pat - http://git.io/ArSs5w
15:06:00  <indutny>ok
15:06:10  <indutny>isaacs: we're copying bytes there
15:06:15  <indutny>and also allocating some memory
15:06:25  <indutny>its ok that we may skip this branch on big buffers
15:06:34  <indutny>big buffers is not a hot path
15:06:35  <indutny>:)
15:06:38  * stagasquit (Ping timeout: 255 seconds)
15:06:39  <indutny>s/is/are/
15:07:53  <isaacs>indutny: yeah, that's fine
15:08:03  <isaacs>indutny: the thing that annoys me is that the definition of "big" is rather arbitrary
15:08:24  <isaacs>indutny: it'd be better if that number was somehow determined from some actual property, rather than experimental
15:08:32  <indutny>that always happens when you try to convert human words into machine meaning
15:08:52  <isaacs>indutny: like, if we could know exactly WHEN it is going to be slower, based on when we'll have to do a alloc or copy will be slower, etc.
15:09:14  <isaacs>yeah. probably the algorithmic approach would be more complicated, and nt much better than a number.
15:09:21  <indutny>obviously
15:09:33  <isaacs>but when i see a magic number, i feel like i'm looking into a crystal ball and seeing me in the future pulling my hair out and cursing about it.
15:10:04  * stagasjoined
15:11:53  * stagas_joined
15:11:58  * stagas_quit (Client Quit)
15:12:01  <isaacs>something i've noticed: .0 is effectively "preview release"
15:12:15  <isaacs>i think it's ok to make minor API changes in .1
15:12:19  <isaacs>but we should never tell anyone that.
15:12:20  <isaacs>:)
15:12:50  <isaacs>you can call 0.9.99 a preview release, but still no one will install it.
15:12:58  <isaacs>until it has the actual "stable" flag on it, they're too scared.
15:13:06  <isaacs>so we put that flag on it just a little bit before it's actually true.
15:14:58  * stagasquit (Ping timeout: 240 seconds)
15:17:32  <isaacs>tjfontaine: you know what would rock the hardest? If the jenkins pr bot thingie could check if the user had signed the cLA.
15:17:42  <isaacs>tjfontaine: but i think that's probably out of scope, and something clahub will do eventually anyway.
15:20:28  <indutny>isaacs: so true
15:20:31  <indutny>I seen it with 0.6
15:20:34  <indutny>seen it with 0.8
15:20:38  <indutny>but 0.10 is pretty steady
15:20:40  <indutny>yet
15:20:53  <indutny>nothing that serious as it was in 0.6 or in 0.8
15:21:26  <isaacs>indutny: well, people are actually using it, for some reason.
15:21:29  <isaacs>i'm not sure why, exactly.
15:21:46  <isaacs>but it took like 6 months to get anyone onto 0.6 in a serious way
15:21:56  <bnoordhuis>tjfontaine: can you disable the "Can one of the admins verify this patch?" spam jenkin posts?
15:23:02  <CoverSlide>0.10.0 makes my app freeze, so i'm sticking to 0.8.22 till i have time to figure it out
15:23:50  <isaacs>CoverSlide: REPORT THE ISSUE!
15:23:52  <isaacs>CoverSlide: srsly.
15:24:07  <CoverSlide>need time to collect details
15:24:17  <isaacs>CoverSlide: i will bet you almost anything it's a result of the "streams don't end until they're consumed" issue.
15:24:28  <CoverSlide>that sounds about right
15:24:42  <isaacs>CoverSlide: like, http.request(...).on('response, function(res) { don't do anything with res }).end()
15:24:45  <isaacs>that hangs
15:25:06  <isaacs>but there's no way to change the semantics to what people want, without having that effect
15:26:08  <`3rdEden>bnoordhuis: I added the processed v8 logs to my gist, but I have no clue what to look for
15:28:53  * mikealjoined
15:30:35  <bnoordhuis>`3rdEden: are you using the cluster module or child processes?
15:31:11  <bnoordhuis>2237 ticks, 1798 unaccounted <- way too much unaccounted for
15:33:52  <`3rdEden>bnoordhuis: nope, I do have a small cc++ addon in the hashring so i can do 64bit bit bitshifting but that's it
15:34:15  <indutny>bnoordhuis: do you know any eventemitter libraries for C? :)
15:35:44  <bnoordhuis>indutny: gobject or qt?
15:35:52  <bnoordhuis>though they call it signals and slots
15:36:00  <bnoordhuis>and qt is c++ of course
15:36:14  <bnoordhuis>`3rdEden: if you have a test case i can run myself, i'll look into it
15:36:21  <bnoordhuis>no external deps though
15:37:24  <`3rdEden>bnoordhuis: I have no clue where the major slowdown comes from, so I can't easily create a small test for you
15:39:02  <bnoordhuis>`3rdEden: you're on os x, i assume?
15:39:15  <`3rdEden>bnoordhuis: yep
15:39:30  <bnoordhuis>okay, that means no perf
15:39:41  <bnoordhuis>maybe instruments?
15:40:10  <`3rdEden>I do have intruments
15:41:11  <bnoordhuis>i have no idea how to use instruments but i know it can create pretty profile graphs
15:41:24  <`3rdEden>:P
15:42:39  * defunctzombie_zzchanged nick to defunctzombie
15:43:48  <`3rdEden>bnoordhuis: the curpit is indeed the crypto api
15:44:17  <`3rdEden>crypto.createHash('md5').update(i).digest() -- 329ms on node 0.8.22
15:44:35  <`3rdEden>2291ms on 0.10
15:45:41  * kazuponquit (Remote host closed the connection)
15:46:06  <indutny>bnoordhuis: gobject?
15:46:08  <indutny>interesting
15:47:01  <indutny>meh, its boring
15:47:05  <indutny>its not really an event emitter
15:47:18  <indutny>but rather signalling stuff
15:47:21  <indutny>like one from boost
15:47:28  <`3rdEden>bnoordhuis: do you still need a test for that ;)? a 100k loop for createHash?
15:49:10  <dostoyevsky>It seems that uv_timer_start() is something like a delay function but not a timeout that I could use when waiting e.g. to read data...
15:50:23  <bnoordhuis>`3rdEden: yes, please
15:50:37  <`3rdEden>not sure if trolling ;)
15:50:42  <bnoordhuis>though if that oneliner you posted it is, i can do that myself :)
15:50:50  <bnoordhuis>*is it
15:51:06  <`3rdEden>https://gist.github.com/3rd-Eden/5162516
15:51:09  <`3rdEden>There you go
15:51:13  <bnoordhuis>thanks
15:53:08  <indutny>interesting
15:53:59  * kazuponjoined
15:55:29  <`3rdEden>bnoordhuis: need me to make an issue for it?
15:55:48  * AvianFlujoined
15:56:04  * dapjoined
15:56:07  * mikealquit (Quit: Leaving.)
15:56:26  <indutny>`3rdEden: yeah
15:56:28  <indutny>please open it
15:56:32  <bnoordhuis>`3rdEden: yes, please. i tend to forget things
15:56:51  <indutny>bnoordhuis: I wonder if this is happening because of openssl upgrade
15:57:21  <bnoordhuis>who knows?
15:57:27  <bnoordhuis>(perf)
15:58:07  <dostoyevsky>Ok, seems uv_timer_start() does exactly what I want. I only used the api incorrectly :)
16:00:05  <MI6>nodejs-v0.10: #21 UNSTABLE smartos-x64 (17/560) smartos-ia32 (1/560) windows-ia32 (29/560) windows-x64 (6/560) http://jenkins.nodejs.org/job/nodejs-v0.10/21/
16:00:40  <`3rdEden>Logged as https://github.com/joyent/node/issues/5015
16:01:49  * `3rdEdenchanged nick to `3E|GONE
16:02:00  <MI6>nodejs-pullrequest: #3 UNSTABLE osx-ia32 (4/560) linux-x64 (1/560) linux-ia32 (1/560) osx-x64 (1/560) smartos-x64 (34/560) windows-ia32 (132/560) smartos-ia32 (18/560) windows-x64 (64/560) http://jenkins.nodejs.org/job/nodejs-pullrequest/3/
16:02:01  <MI6>nodejs-pullrequest: #2 UNSTABLE osx-ia32 (2/560) linux-ia32 (4/560) osx-x64 (1/560) smartos-x64 (16/560) windows-ia32 (129/560) smartos-ia32 (23/560) windows-x64 (46/560) http://jenkins.nodejs.org/job/nodejs-pullrequest/2/
16:02:37  <tjfontaine>bnoordhuis: unfortunately for at least how this plugin is designed no, I will look more closely
16:02:48  <tjfontaine>bnoordhuis: for people who are whitelisted the spam doesn't happen
16:05:22  <tjfontaine>it's perfectly within my capacity to write something that does it, you guys just need to tell me how you want it to work
16:07:46  * defunctzombiechanged nick to defunctzombie_zz
16:08:17  * mikealjoined
16:09:19  * mikealquit (Client Quit)
16:09:58  <indutny>bnoordhuis: so it seems that we're loosing time in js
16:10:03  <indutny>because of stream interface
16:10:09  <indutny>wanna see flamegraphs?
16:10:22  <tjfontaine>we're letting time loose?
16:10:45  <isaacs>indutny: yes!
16:11:04  <isaacs>indutny: what's the thing that's slow here? `3rdEden's crypto thing?
16:11:20  <indutny>http://blog.indutny.com/f/crypto-0.8.svg
16:11:23  <indutny>http://blog.indutny.com/f/crypto-master.svg
16:11:25  <indutny>isaacs: hashing
16:11:57  <indutny>so stream construction is much slooower
16:11:58  <MI6>nodejs-v0.10: #22 UNSTABLE smartos-ia32 (2/560) windows-ia32 (4/560) windows-x64 (6/560) http://jenkins.nodejs.org/job/nodejs-v0.10/22/
16:12:01  <indutny>well
16:12:07  <indutny>yeah
16:12:24  <bnoordhuis>tjfontaine: people who are whitelisted? you mean PR submitters or ?
16:12:35  <tjfontaine>bnoordhuis: pr submitters
16:12:41  <bnoordhuis>also, isn't it something you can simply delete from the plugin?
16:12:59  <bnoordhuis>though that's probably annoying to maintain
16:13:39  <tjfontaine>anything is doable, but I suspect soon the requests will be "can it report the test failures, can it report which tests failed, can it ..."
16:14:11  <tjfontaine>https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin are the docs (such as they are) for how the plugin for jenkins work
16:14:47  <bnoordhuis>tjfontaine: that's why we hired you, right? :)
16:14:49  <tjfontaine>anything I do, won't necessarily be inside the jenkins plugin system, but will involve triggering jenkins externally, like I already do for the benchmarking
16:14:56  <tjfontaine>bnoordhuis: pretty sure :)
16:15:07  <indutny>bnoordhuis: you hired tj?
16:15:17  <tjfontaine>bnoordhuis: but if I'm going to be making endless changes to something I'd much prefer it to be javascript and not java :)
16:16:42  * perezdjoined
16:17:25  * perezdquit (Remote host closed the connection)
16:18:06  <bnoordhuis>tjfontaine: speaking for myself, jenkins doesn't have to auto-test the PR
16:18:31  <bnoordhuis>because i always run the tests manually myself before landing a patch
16:19:05  <bnoordhuis>don't know how the others feel about that though
16:20:10  <tjfontaine>I agree that this jenkins-pr plugin is certainly more chatty than I woudl have ever watned
16:20:16  <isaacs>bnoordhuis: it'd be nice to not have to do that when a pr breaks a bunch of stuff, though
16:20:26  <isaacs>but yeah, the spam is kind of annoying.
16:20:29  <tjfontaine>but on the whole I think it's a good thing to inform users and other merge masters of what's going on
16:20:55  <bradleymeck>any chance of getting spawn's uid/gid to use sid strings on windows somehow?
16:21:00  <tjfontaine>I take it the consensus for now is to disable this annoying SoB and find a different mechanism?
16:21:02  <bnoordhuis>i guess i can simply filter out jenkins emails
16:21:07  <isaacs>tjfontaine: yes.
16:21:24  <isaacs>bnoordhuis: i've filtered out the emails already. but it also screws up the views on github, which i use a lot.
16:21:33  <bnoordhuis>bradleymeck: sure, if the price is right
16:21:33  <isaacs>bnoordhuis: it looks like issues have activity that actually don't.
16:21:40  <bnoordhuis>indeed
16:22:05  <bradleymeck>bnoordhuis: i could do the patch I guess but would require a separate options with 2 new ptrs for string based stuff :/
16:22:30  <bradleymeck>bnoordhuis: whats a price at? (really should just setup a bounty board somewhere)
16:22:56  <bnoordhuis>bradleymeck: i kid :) if you open a libuv issue and explain what you want and why, we can look into it
16:23:28  <bradleymeck>still not kidding about a bounty board
16:24:05  <bnoordhuis>well, money is not the prime motivator
16:24:15  <bnoordhuis>but if you want to help, buy a strongloop subscription :)
16:35:00  <Chip_Zero>bnoordhuis: you don't mind if I take that statement out of context and quote it on a nearby Skype channel? ;)
16:35:39  * piscisaureus_quit (Ping timeout: 256 seconds)
16:36:18  <bnoordhuis>heh
16:40:27  <bradleymeck>mainly just want .fork to spawn as a different uid/gid without tragedy
16:44:57  * indexzerojoined
16:49:50  * jguerreroquit (Ping timeout: 260 seconds)
16:50:02  * perezdjoined
17:01:12  * indexzeroquit (Quit: indexzero)
17:03:01  * indexzerojoined
17:08:52  * asdf12joined
17:09:28  * qmxchanged nick to qmx|away
17:09:51  <asdf12>'(libuv) Failed to create kqueue (24)' i get this error printed to stdio, weird that it just prints this?
17:10:00  <asdf12>wouldn't it be better emitted through an error
17:10:17  <tjfontaine>how did you manage that?
17:11:25  <asdf12>it's so weird! haha let me paste a gist
17:11:26  * piscisaureus_joined
17:12:37  <asdf12>https://gist.github.com/lovebear/a95990dbe31af60df4b1
17:12:48  <asdf12>it's random, thats the even weird part
17:13:15  <asdf12>if i run that script 10 times, maybe 7 times it'll show that error
17:13:45  <asdf12>no less than that
17:14:06  * loladirojoined
17:15:50  <asdf12>that error is actually useful to me, it's a lot more telling than ECONNREFUSED
17:16:10  <asdf12>since it's not a connection refusal, but the fd limit is being hit?
17:16:25  <tjfontaine>that should be EMFILE generally
17:16:53  <asdf12>so it's reporting the wrong error? because the error being caught is ECONNREFUSED
17:18:16  <asdf12>updated the gist to show an example output
17:20:08  <tjfontaine>well, one side is complaining (but not reporting) the emfile, the other side already has an fd that tried to conncet, but got refused because of the rlimit
17:20:19  <tjfontaine>if I had to guess what's going on here
17:20:31  <tjfontaine>that libuv failed to create part though, should be setting the errno
17:20:55  <piscisaureus_>that's terrible btw
17:20:55  <tjfontaine>hmm it is
17:21:11  <tjfontaine>I'm not sure what the script is supposed to be testing
17:21:18  <piscisaureus_>uv_accept calls uv__stream_open which calls uv__try_kqueue
17:21:24  <piscisaureus_>that's shit for accept performance
17:21:59  <piscisaureus_>only uv_stream_open (so the public api) should do that
17:22:04  <piscisaureus_>^-- bnoordhuis, indutny
17:22:17  <tjfontaine>piscisaureus_: btw https://github.com/joyent/libuv/pull/739 is ready for further review
17:24:23  <indutny>урь
17:24:25  <indutny>ehm
17:24:26  <indutny>gosh
17:24:32  <indutny>you're right
17:24:36  <piscisaureus_>tjfontaine: why did you make every uv_statbuf_t field 64-bit?
17:24:54  <tjfontaine>piscisaureus_: because bnoordhuis said I could :P
17:25:16  <piscisaureus_>always that ben guy
17:27:57  * zot1joined
17:31:21  <asdf12>should i create an issue?
17:31:32  <asdf12>i would like to track the progress of this bug
17:32:02  <tjfontaine>what are you trying to expose in that script?
17:32:23  <asdf12>tjfontaine: i'm trying to see what type of error gets reported when the fd limit is being hit
17:32:38  <tjfontaine>I see
17:32:40  <asdf12>and ECONNREFUSED is useless
17:32:50  <piscisaureus_>tjfontaine: there's a real error in there and indutny is already writing a fix :)
17:32:57  <piscisaureus_>he just didn't tell us
17:33:00  <tjfontaine>heh
17:40:00  * defunctzombie_zzchanged nick to defunctzombie
17:43:45  * `3E|GONEquit (Remote host closed the connection)
17:47:20  * felixgejoined
17:47:20  * felixgequit (Changing host)
17:47:20  * felixgejoined
17:48:07  * c4miloquit (Remote host closed the connection)
17:55:06  * bajtosjoined
17:56:45  * bradleymeckquit (Quit: bradleymeck)
17:58:54  * `3rdEdenjoined
18:04:29  * csaohquit (Quit: csaoh)
18:09:13  * Raltjoined
18:11:32  * indexzeroquit (Quit: indexzero)
18:16:56  * brsonjoined
18:21:41  * indexzerojoined
18:29:18  * c4milojoined
18:31:42  * bnoordhuisquit (Ping timeout: 245 seconds)
18:33:05  * loladiroquit (Quit: loladiro)
18:36:10  * indexzeroquit (Quit: indexzero)
18:36:43  * sgallagh1joined
18:39:28  * sgallaghquit (Ping timeout: 258 seconds)
18:42:39  * sblomjoined
18:51:15  * bradleymeckjoined
18:52:34  * mikealjoined
19:01:28  * piscisaureus_quit (Ping timeout: 240 seconds)
19:13:13  * Raltquit (Remote host closed the connection)
19:16:43  * zot1quit (Quit: Leaving.)
19:20:51  * indexzerojoined
19:23:14  * zot1joined
19:25:22  * mikealquit (Quit: Leaving.)
19:27:01  * brianc1joined
19:27:31  <brianc1>hello - I am running into a slightly unexpected behavior with domains & was wondering if anyone had time to answer a question
19:27:49  <sblom>We'll help if we can. What are you seeing?
19:28:06  <brianc1>i am following the domain example almost to the letter from the node documentation except I'm using it with express instead of a raw http server
19:28:35  <brianc1>I set up a route that basically does app.get "/", function() { process.nextTick(function() { throw new Error("CRASH" }}}
19:28:45  <brianc1>the domain is attached via middleware before the router
19:28:49  <brianc1>the first time that route is hit
19:28:53  <brianc1>the domain 'error' handler fires
19:29:11  <brianc1>the second time that route is hit the server crashes. neither the server domain nor the domain for that request are handing the error
19:29:39  <brianc1>if I _do not_ do a 'domain.dispose()' in the error event of the request domain then all errors are trapped by the request domain
19:30:05  <brianc1>i hope that makes sense?
19:31:30  <sblom>I'm not our deepest expert on domains. But I think I mostly follow. One question, though.
19:31:45  <sblom>I didn't quite understand where you're using domain.dispose().
19:32:41  <sblom>If you can paste a link to a GIST of a simple repro, I'd be able to follow along directly on my side.
19:32:47  <brianc1>oh something fishy is going on....the domain emitting the error is always the first domain attached.....i wonder if this is user errror....hmmm
19:33:04  <brianc1>but I pretty much followed this example verbatim: http://nodejs.org/api/domain.html#domain_explicit_binding
19:33:24  <brianc1>i'll see if i can create an executable example of wha tI'm seeing
19:37:09  * qmx|awaychanged nick to qmx
19:37:55  * bnoordhuisjoined
19:40:51  <brianc1>okay it's definitely an issue on my side. just tried to create an exampel app and the app works
19:40:52  <brianc1>haha
19:40:53  <brianc1>me = pwnd
19:40:59  <brianc1>i'll report in on what i find
19:41:02  <brianc1>sorry to bother u
19:41:06  * defunctzombiechanged nick to defunctzombie_zz
19:42:50  * bnoordhuisquit (Ping timeout: 256 seconds)
19:49:37  <isaacs>crap, forgot to deprecate domain.dispose() in 0.10
19:49:39  <isaacs>oh well.
19:49:42  <isaacs>0.11 it is.
19:54:47  * Raltjoined
19:55:42  * mikealjoined
19:58:43  * Raltquit (Remote host closed the connection)
19:58:49  * zot1quit (Quit: Leaving.)
20:00:20  <brianc1>okay so don't call it anymore?
20:00:25  <brianc1>just let them die off on their own?
20:04:55  <isaacs>brianc1: well, it's not free()
20:04:59  <isaacs>brianc1: js doesn't ahve any such thing
20:05:14  <isaacs>but it basically walks around witha club, and tries to smash any event emitters that were added to it.
20:05:21  <isaacs>brianc1: and also sets domain._disposed = true
20:05:29  <isaacs>brianc1: which means "Nothing more will happen here"
20:05:42  <isaacs>brianc1: ie, errors will be ignored, nextTicks stifled, setTimeouts squashed, etc.
20:05:45  * mikealquit (Ping timeout: 276 seconds)
20:05:50  <isaacs>it's kind of... awful, actually
20:05:55  <isaacs>not the right way to handle errors.
20:06:03  * loladirojoined
20:06:04  * loladiroquit (Client Quit)
20:06:59  <brianc1>haha understandable
20:07:13  <MI6>joyent/node: koichik v0.10 * 1f53cfd : doc: don't mark fs callbacks as optional Refs #5005, #5008 - http://git.io/sAOybA
20:07:33  * defunctzombie_zzchanged nick to defunctzombie
20:07:57  * bnoordhuisjoined
20:14:15  <asdf12>https://gist.github.com/anonymous/e59d2fc4b4b360fbeb61 why does res.end() have an eventemitter warning?
20:14:38  * TooTallNatejoined
20:15:37  <asdf12>seems like something funky is happening? like it can't adding listeners to the same event of the same instance?
20:15:45  <asdf12>it keeps* not can't
20:18:56  <bnoordhuis>asdf12: ? works for me
20:20:01  <asdf12>oh, sorry, i run that, and then use `ab -n 400 -c 10 http://localhost:3000/`
20:20:02  <brianc1>is there some limit to the number of callbacks a domain can handle? in my app riiiiight before I make a query `process.domain` exists. in the query call back `process.domain` is null....blowing my mind
20:21:15  <asdf12>on OS X 10.8.2, i get a ton of '(libuv) Failed to create kqueue (24)' and eventemitter warnings about res.end()
20:22:27  * `3rdEdenquit (Remote host closed the connection)
20:22:43  * kazuponquit (Remote host closed the connection)
20:24:13  <wolfeidau>asdf12: Are you using the ab bundled with 10.8 or one that works?
20:24:35  <asdf12>i'm using the bundled, broken one
20:25:03  <asdf12>but still curious about res.end eventemitter warnings?
20:25:05  <wolfeidau>asdf12: Build a clean one, you will find it works fine :)
20:26:45  * mikealjoined
20:29:44  <wolfeidau>asdf12: Cant recall exactly what the issue was with the bundled ab was, just remember to use the one installed via homebrew
20:31:58  <wolfeidau>asdf12: ahh localhost resolves to an ipv6 address on OSX 10.8 if you want to use the installed ab try using 127.0.0.1
20:32:55  <asdf12>ah
20:33:04  <asdf12>yes that made the eventmitter warnings disappear it looks like
20:34:12  <asdf12>but that raises the question, does ipv6 make eventemitter act weird?
20:34:41  <asdf12>well not eventemitter, but the socket/http events
20:35:07  <asdf12>though i could probably cry
20:35:15  * SquirrelCZECHjoined
20:35:19  <SquirrelCZECH>hi folks
20:35:22  <asdf12>i wasted an hour trying to figure out why eventemitter was being mean to me
20:35:35  <SquirrelCZECH>what can cause python: src/unix/stream.c:1294: uv__read_start_common: Assertion `((stream)->io_watcher.fd) >= 0' failed.
20:35:37  <SquirrelCZECH>?
20:36:04  * SquirrelCZECHjust installed libuv ... it looks great but that feeling when it got error which is not understable is ... :-/
20:37:12  <SquirrelCZECH>aaah, got the reason! :-)
20:37:14  * Raltjoined
20:37:46  * Raltquit (Remote host closed the connection)
20:40:12  <asdf12>no wait, the eventemitter warnings are coming back
20:40:34  * V1joined
20:40:43  <asdf12>they basically start popping up if i make ab make the http server start to buckle
20:40:52  <asdf12>but i have no listeners for 'end'
20:41:12  * V1changed nick to `3rdEden
20:41:44  <tjfontaine>wtf nodejs jenkins ...
20:45:53  * sgallagh1quit (Remote host closed the connection)
20:47:07  <bnoordhuis>asdf12: indutny is working on fixing those kqueue errors
20:47:31  <bnoordhuis>SquirrelCZECH: when do you get that error?
20:50:21  <MI6>joyent/node: Sami Samhuri master * 5eacdd4 : repl: emit 'reset' event when context is reset Closes #1183. - http://git.io/tUq9Iw
20:51:48  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:53:07  * kazuponjoined
20:53:58  <bnoordhuis>tjfontaine: any luck with the i386 fbsd thing?
20:55:24  <MI6>nodejs-v0.10: #23 FAILURE smartos-ia32 (1/560) http://jenkins.nodejs.org/job/nodejs-v0.10/23/
20:56:10  <tjfontaine>bnoordhuis: well, fbsd9.1 ustack is only giving me 3 unresolved frames, despite rebuilding world and the kernel with debugging
20:56:25  <tjfontaine>bnoordhuis: fbsd10 dtrace core's outright
20:57:43  <tjfontaine>a friend is telling me to use ddb, except that I'm not sure that once I build the kernel with that I'd even know what I'd be looking for
20:58:24  * piscisaureus_joined
20:59:17  * bradleymeckquit (Quit: bradleymeck)
20:59:22  <tjfontaine>also it seems to be in the deserialization of the snapshot
21:02:17  * diakopterjoined
21:02:30  * kazuponquit (Ping timeout: 264 seconds)
21:05:59  <brianc1>i figured out my issue!
21:06:11  <brianc1>the domain was "detached" after a call to the database
21:06:34  <brianc1>so I used `process.domain.intercept`on the callback for the query
21:06:41  <tjfontaine>bnoordhuis: https://gist.github.com/tjfontaine/2b265fee4c4c95061705
21:07:05  <brianc1>but I'm doing callbacks all over the place and this is the only one that "detaches" - is there a rule of thumb for when to use `process.domain.intercept` on a callback?
21:07:09  <indutny>bnoordhuis: what I am working on?
21:07:14  <indutny>performance problems with kqueue hack?
21:08:04  <SquirrelCZECH>bnoordhuis: called pyuv.TCP.start_read() before pyuv.TCP.accept(connection)
21:10:22  <SquirrelCZECH>just got curious
21:10:45  <isaacs>brianc1: you probably want bind, not intercept.
21:10:46  <SquirrelCZECH>are there any problems if I would create .exe file from python source code which uses libuv?
21:10:53  <SquirrelCZECH>but it's maybe more like python question I suppose
21:11:07  <isaacs>brianc1: intercept prevents the cb from even being called if the first arg is error
21:11:35  <isaacs>speaking of domains, i think i've got #2031 worked out.
21:12:43  <brianc1>isaacs: yeah, it's weird i'll gist it maybe it's expected behavior
21:18:42  <saghul>I know you all secretly love python, pyuv 0.10.0 released :-)
21:21:36  <brianc1>isaacs: https://gist.github.com/brianc/5165396
21:22:15  <brianc1>that's a major wtf
21:22:36  <isaacs>brianc1: what language is this? domain.run(λ() {
21:22:46  <brianc1>oh sorry my vim does that
21:22:57  <brianc1>on non-active line it shortens the word "function"
21:23:20  <brianc1>it's javascript!
21:24:13  <isaacs>brianc1: is pg pooling connectinos or something?
21:24:29  <brianc1>yea
21:30:33  <brianc1>is there a reason the callback "leaving" the initial domain and flopping over to a different one?
21:30:36  <brianc1>something I'm doing wrong?
21:31:10  <brianc1>it seems to be sort of non-deterministic, every time I run the script I get different output
21:31:48  * abrenerjoined
21:31:58  * diakopterpart
21:35:20  * bajtosquit (Quit: Leaving)
21:35:22  <brianc1>maybe I have to add the stream connected to the postgres server to the domain?
21:41:09  <brianc1>strange - if I don't use the pooled clients it works as expected....hmmm...
21:41:38  * bradleymeckjoined
21:45:46  <MI6>nodejs-v0.10: #24 UNSTABLE linux-ia32 (1/560) windows-x64 (4/560) windows-ia32 (4/560) smartos-ia32 (1/560) linux-x64 (1/560) http://jenkins.nodejs.org/job/nodejs-v0.10/24/
21:50:06  * `3rdEdenquit (Remote host closed the connection)
21:54:37  * wolfeidauquit (Remote host closed the connection)
21:54:39  <isaacs>brianc1: so, the socket is in whatever domain was active when it was created.
21:54:48  <brianc1>ah
21:54:54  <isaacs>brianc1: that's hwo domains work: they trace the state of an async operation through multiple EE's and hops
21:54:59  <brianc1>right
21:55:01  * dominictarrjoined
21:55:08  <isaacs>brianc1: so, what you'll want to do is explicitly bind the cb functions passing to pg.
21:55:18  <brianc1>can I remove the socket from the domain when return it to the pool?
21:55:24  <isaacs>(this is why we need a core SocketPool client library that works nicely with domains)
21:55:50  <isaacs>brianc1: sure, you can change it around whenever you ilke.
21:55:56  <brianc1>that will work as well?
21:55:57  <isaacs>brianc1: socket.domain = process.domain
21:56:02  <brianc1>awesomeness
21:56:32  <brianc1>so right before releasing client back to pool i can do 'client.connection.socket.domain.remove(client.connection.socket)'?
21:56:35  <asdf12>++++1 on SocketPool lib
21:56:44  <asdf12>i've been trying to write my own all day
21:56:53  <brianc1>pooling is so hard
21:57:02  <brianc1>i've screwed it up multiple times in node postgres. :/
21:57:30  <isaacs>yeah
21:57:44  * rendarquit
21:57:47  <isaacs>and every on-top-of-tcp client library needs to do it.
21:57:55  <isaacs>it's a good candidate for a core implementaiton.
21:58:23  <brianc1>hard to handle error scenarios when connections are sitting idly in the pool
21:58:40  <brianc1>and having to pass around a 'release' function everywhere
21:59:01  <brianc1>anyways - I so happy to figure this out now. was racking my brain on why some of my requests were getting handled in domain error listener and some were not
21:59:03  <brianc1>now i know!
21:59:18  * kazuponjoined
21:59:29  <isaacs>brianc1: also, when you have sockets sitting around, sometimes the servers toss them in the trash bin without telling you
21:59:37  <brianc1>nice!
21:59:39  <isaacs>brianc1: so you have to always be ready for an EPIPE or ECONNRESET
22:00:13  <brianc1>any interest in supporting more than 2 parameter callbacks in domain.intercept?
22:01:04  <brianc1>ie: function something(callback) { callback(null, 'one', 'two') }; domain.intercept(something, (one, two) { console.log(two) }); //undefined
22:01:33  <brianc1>i forgot a keyword there - will gist it
22:01:33  <isaacs>brianc1: not really
22:02:26  <asdf12>i have a question, why can't i do while(some_cond) { var s = new Socket(); ... s.connect(...) } ?
22:02:41  <asdf12>for instance creating a lot of sockets really fast
22:03:40  <piscisaureus_>asdf12P you can
22:03:47  <piscisaureus_>* asdf12
22:03:57  <piscisaureus_>but at some point you're going to run out of file descriptors
22:04:09  * kazuponquit (Ping timeout: 258 seconds)
22:04:17  <asdf12>it looks like it all bottles up
22:05:33  * qmxchanged nick to qmx|away
22:05:53  <asdf12>https://gist.github.com/anonymous/5dd315095a9f06dc98a3
22:06:00  <asdf12>giving that code, nothing happens
22:06:45  <asdf12>well not nothing, i know something is happening, but all the sockets seem tied up
22:08:55  <asdf12>like, well if you modify the code to break the loop eventually, it'll explode
22:09:03  <asdf12>with all the expected output
22:11:19  * wolfeidaujoined
22:14:50  <asdf12>well never mind i guess it's because the current stack can't ever exit
22:15:23  <bnoordhuis>http://code.saghul.net/index.php/2013/03/14/pyuv-0-10-0-relased/
22:15:26  <bnoordhuis>congrats saghul :)
22:15:57  <saghul>bnoordhuis thanks! you guys are awesome, keep up the good work!
22:16:28  <asdf12>which is weird to me because with that code a recursive function will work?
22:16:34  <bnoordhuis>saghul: but where's the hn upvote link?
22:16:36  <asdf12>over a loop
22:16:58  <saghul>bnoordhuis meh ;-)
22:17:07  <bnoordhuis>heh
22:20:13  <isaacs>asdf12: huh?
22:20:35  <isaacs>asdf12: you're never yielding to the event loop to do its thing.
22:20:37  * `3rdEdenjoined
22:23:56  <bnoordhuis>piscisaureus_: ps: https://github.com/joyent/libuv/issues/743
22:25:02  <asdf12>also i think i saw someone mention this or saw an issue? but i'm seeing 'Assertion failed: (uv__stream_fd(stream) >= 0), function uv_shutdown, file ../deps/uv/src/unix/stream.c, line 1084. Abort trap: 6'
22:25:35  <piscisaureus_>bnoordhuis: sup with that?
22:26:17  <isaacs>asdf12: yes, that is fixed in 0.10.1, i believe
22:26:19  <isaacs>and master
22:29:20  * `3rdEdenquit (Ping timeout: 260 seconds)
22:29:24  <bnoordhuis>piscisaureus_: thoughts?
22:29:37  <bnoordhuis>see also the related node issue
22:36:32  * c4miloquit (Remote host closed the connection)
22:41:17  <tjfontaine>bnoordhuis: do you have any particular guidance for further investigating the fbsd issue?
22:42:03  <isaacs>here's another question..
22:42:05  <isaacs>maybe crazy.
22:42:10  <isaacs>how much do we care about freebsd?
22:42:17  <tjfontaine>me, not one iota
22:42:21  <isaacs>i mean, there are a ton of people using node on smartos.
22:42:25  <isaacs>probably even more on linux.
22:42:33  <isaacs>almost everyone has a mac laptop
22:42:42  <isaacs>and there's this windows stuff at msft.
22:42:46  <isaacs>but who's really using freebsd?
22:42:59  <tjfontaine>I was only investigating because bryan wanted to know why it was happening
22:43:16  <isaacs>tjfontaine: yeah, bryan's a "root cause analysis" kinda guy, for sure.
22:43:27  <isaacs>tjfontaine: which is great.
22:43:32  <isaacs>but there's a cost/benefit to consider here, too.
22:43:52  <tjfontaine>I've been workingn on other things, and only coming back to it when it's done compiling etc
22:43:58  <isaacs>if it's 2 days that you could spend making jenkins better, or finding bugs that affect more than one user, then meh.
22:44:00  <tjfontaine>but I'm happy to be done
22:45:07  * indexzeroquit (Quit: indexzero)
22:45:55  <bnoordhuis>tjfontaine: i don't care much for freebsd. if you can get it in a state where v8 doesn't immediately abort on startup, i'm happy
22:46:22  <tjfontaine>ok
22:46:46  <bnoordhuis>i imagine it's a matter of adding an #ifdef __sun around the place where the mmap address is calculated
22:47:16  <tjfontaine>have we had problems anywhere other than fbsd? seems like that's what the ifdef should be :)
22:48:04  <bnoordhuis>well, it's not necessary on i386 linux
22:48:16  <tjfontaine>but ya an ifdef seems like the right answer unless someone with more fbsd skills takes an interest
22:48:23  <bnoordhuis>i've never had complaints about os x either
22:48:26  <bnoordhuis>so i guess it's just sunos
22:49:56  <isaacs>bnoordhuis: no one runs os x in production, anyway.
22:50:03  <tjfontaine>heh
22:50:25  <isaacs>we can create an issue asking for any freebsd person to adopt that system, and make it properly supported.
22:50:44  <isaacs>but otherwise, i think we've got our hands full. we barely manage to keep these 4 running nicely :)
22:53:21  <piscisaureus_>bnoordhuis: re cork/uncork - I don't have a particular opinion. I never really felt the need for it though but if you say people really want/need this I'll take your word for it.
22:53:22  <piscisaureus_>bnoordhuis: also I don't know if it's possible to implement this on windows. However my current understanding is that cork/uncork doesn't imply a semantic change so on platforms that don't support it it could be a no-op. Is that correct?
22:54:18  * zotjoined
22:54:30  * AvianFluquit (Remote host closed the connection)
22:55:06  <isaacs>tjfontaine: sounds good. #ifdef __sun. make it so.
22:55:14  <isaacs>tjfontaine: just let bryan know, also
22:55:16  * zotquit (Client Quit)
22:55:19  <tjfontaine>isaacs: ok
22:55:22  <isaacs>tjfontaine: i mean, I just let bryan know, just now.
22:55:35  <isaacs>not "would you please just let bryan know"
22:55:48  <tjfontaine>oh ok
22:58:35  * defunctzombiechanged nick to defunctzombie_zz
23:00:13  * kazuponjoined
23:03:52  <MI6>joyent/node: isaacs master * c0721bc : repl: Use a domain to catch async errors safely Fix #2031 - http://git.io/_7SqYw
23:04:34  <isaacs>piscisaureus_, sblom: have either of you had a chance to look into our otehr windows test failures on 0.10?
23:04:55  * kazuponquit (Ping timeout: 260 seconds)
23:06:21  <bnoordhuis>piscisaureus_: re cork. yes, it's just a hint from the user to libuv
23:06:46  <bnoordhuis>on unices, i'd simply make it stop write()ing until the user calls uncork
23:06:51  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:06:56  <bnoordhuis>damnit
23:07:03  <bnoordhuis>off he goes :/
23:07:12  * Kakerajoined
23:07:15  <Kakera>what does status
23:07:25  <Kakera>0 mean in the callback to uv_write?
23:07:35  <bnoordhuis>Kakera: 0 == a-okay
23:07:40  <Kakera>ok
23:08:09  <tjfontaine>bnoordhuis: acceptable https://github.com/tjfontaine/node/compare/issue4010
23:08:10  <tjfontaine>?
23:10:53  <bnoordhuis>tjfontaine: you should update the comment
23:11:08  <tjfontaine>I wasn't sure, but I will do so
23:11:38  <bnoordhuis>here is what it looks like in upstream v8:
23:11:38  <bnoordhuis>112 // The range 0x20000000 - 0x60000000 is relatively unpopulated across a
23:11:41  <bnoordhuis>113 // variety of ASLR modes (PAE kernel, NX compat mode, etc) and on macos
23:11:44  <bnoordhuis>114 // 10.6 and 10.7.
23:12:03  <tjfontaine>yes that's in the upper part
23:13:03  <tjfontaine>bnoordhuis: I mean, I've included both comments, by update I was just going to change the else block to only mention illumos
23:13:54  <bnoordhuis>okay, cool
23:17:26  <MI6>nodejs-master: #97 UNSTABLE windows-ia32 (4/562) windows-x64 (4/562) linux-x64 (1/562) osx-x64 (1/562) http://jenkins.nodejs.org/job/nodejs-master/97/
23:19:04  <tjfontaine>bnoordhuis: updated
23:19:07  <MI6>joyent/node: isaacs v0.10 * 3537b57 : test: No need for kicking in streams2 test This was necessary when we we (+1 more commits) - http://git.io/EQ52fQ
23:19:30  * perezdquit (Quit: perezd)
23:19:34  * bradleymeckquit (Quit: bradleymeck)
23:20:21  <bnoordhuis>tjfontaine: lgtm
23:20:33  <bnoordhuis>not upstream it :)
23:20:37  <bnoordhuis>err, now
23:20:43  <tjfontaine>heh
23:21:31  <tjfontaine>what was the nick of the guy taking care of the ascii stuff? maybe we can convince him to land it :P
23:22:01  <tjfontaine>also do you want me to do a pr?
23:22:28  <bnoordhuis>tjfontaine: yes, please. one with a nice commit log
23:22:39  * c4milojoined
23:22:51  <tjfontaine>heh, damn
23:29:36  * hzquit (Ping timeout: 264 seconds)
23:32:17  <MI6>nodejs-v0.10: #25 UNSTABLE smartos-ia32 (1/560) windows-x64 (6/560) osx-ia32 (2/560) windows-ia32 (5/560) http://jenkins.nodejs.org/job/nodejs-v0.10/25/
23:35:48  * hzjoined
23:45:43  * mikealquit (Quit: Leaving.)
23:45:53  * qmx|awaychanged nick to qmx
23:48:02  <MI6>joyent/node: isaacs v0.10 * 14947b6 : stream: Return self from readable.wrap Also, set paused=false *before* c - http://git.io/m44mFA
23:48:51  <isaacs>bnoordhuis, tjfontaine: So is 4010 fixed again?
23:49:03  * dapquit (Quit: Leaving.)
23:49:10  <tjfontaine>4010 was never unfixed, just not for freebsd
23:49:23  <isaacs>oh, ok
23:49:34  <tjfontaine>bnoordhuis: what would you like changed about the commit log, further information in the actual message?
23:49:35  * dapjoined
23:49:44  <isaacs>well, i reopened it. or someone else did, not sure. maybe add "Fix #4010" in your pr commit message :)
23:49:55  <tjfontaine>certainly :)
23:51:00  <bnoordhuis>tjfontaine: yes. a commit log should explain what changed and why
23:52:40  <tjfontaine>yup yup
23:52:42  * dominictarrquit (Quit: dominictarr)