00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:00:44  * toddaaropart
00:02:07  <MI6>libuv-master-gyp: #142 UNSTABLE windows-x64 (4/194) windows-ia32 (4/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/142/
00:10:48  * ecrquit (Quit: ecr)
00:15:18  * leonvvquit (Read error: Connection reset by peer)
00:29:59  <MI6>joyent/node: isaacs master * ee695e9 : child_process: Avoid extra copy for string stdio (+1 more commits) - http://git.io/EQiCjA
00:33:16  * bnoordhuisjoined
00:36:15  * TooTallNatejoined
00:37:38  * bnoordhuisquit (Ping timeout: 245 seconds)
00:39:36  <MI6>nodejs-master: #494 UNSTABLE smartos-x64 (9/637) smartos-ia32 (3/637) http://jenkins.nodejs.org/job/nodejs-master/494/
00:43:56  * groundwaterquit (Quit: groundwater)
00:52:29  * c4miloquit (Remote host closed the connection)
00:52:41  <MI6>nodejs-master-windows: #286 UNSTABLE windows-x64 (20/637) windows-ia32 (16/637) http://jenkins.nodejs.org/job/nodejs-master-windows/286/
00:57:32  <tjfontaine>isaacs: hmm, that last commit fixes an issue I think
01:00:28  * defunctzombiechanged nick to defunctzombie_zz
01:01:07  * defunctzombie_zzchanged nick to defunctzombie
01:01:58  * austoquit (Quit: Leaving)
01:04:07  * indexzerojoined
01:04:30  * dshaw_quit (Quit: Leaving.)
01:04:51  * kazuponjoined
01:05:36  * dshaw_joined
01:07:37  <MI6>joyent/node: Mathias Buus master * ba72570 : stream: change default hwm for objectMode to 16 - http://git.io/8-ndjg
01:08:15  * EhevuTovquit (Quit: This computer has gone to sleep)
01:08:45  * wavdedjoined
01:09:34  <MI6>joyent/node: isaacs master * ba72f8c : doc: mark repl as stable - http://git.io/oaY5Nw
01:10:49  <hueniverse>is it just me or setTimeout in node 0.11 is ~25ms short?
01:11:09  <hueniverse>300 -> 280, 50 -> 25
01:12:24  <tjfontaine>every, or just the first, and are you comparing against the wallclock?
01:13:50  <othiym23>that's a fast stopwatch finger
01:14:17  <hueniverse>hmm
01:14:18  * c4milojoined
01:14:30  <hueniverse>looks like just the first in the code snippet
01:14:47  <hueniverse>back to the big pile of goo to figure out the crazy timers
01:15:12  <hueniverse>tjfontaine: but why would 0.11 change the first?
01:16:51  <MI6>nodejs-master: #495 FAILURE smartos-x64 (10/637) osx-ia32 (1/637) smartos-ia32 (3/637) http://jenkins.nodejs.org/job/nodejs-master/495/
01:17:00  * indexzeroquit (Quit: indexzero)
01:17:29  * indexzerojoined
01:18:10  <tjfontaine>hueniverse: so, we are now using the hrtime from the uv loop, as compared to do another gettimeofday
01:18:25  <hueniverse>something is broken
01:18:36  <hueniverse>I got a test that sets a timeout before res.end()
01:18:44  <hueniverse>timeout is set to 100ms
01:18:56  <hueniverse>sorry, 50ms
01:19:00  <hueniverse>gets invoked after 2
01:19:12  * kazuponquit (Remote host closed the connection)
01:19:12  <hueniverse>if I wrap the timeout with another for 1ms, it works
01:19:16  <tjfontaine>hueniverse: this is a socket.setTimeout I guess?
01:19:25  <hueniverse>tjfontaine: nope
01:19:43  * kazuponjoined
01:19:49  <othiym23>jenkins, you're drunk
01:20:10  <hueniverse>https://github.com/spumko/hapi/blob/master/test/integration/clientTimeout.js#L98
01:20:11  <tjfontaine>/bin/sh: /bin/sh: cannot execute binary file
01:20:11  <tjfontaine>make[1]: *** [/Volumes/External/jenkins/workspace/nodejs-master/dfdb978f/out/Release/obj.target/openssl/deps/openssl/openssl/crypto/bn/bn_mul.o] Error 126
01:20:14  <tjfontaine>make[1]: *** Waiting for unfinished jobs....
01:20:15  <tjfontaine>what's wrong with my mac
01:20:18  <tjfontaine>hueniverse: looking
01:20:37  <hueniverse>this is a very simple test. We tell the server to timeout client req after 50ms
01:20:46  <hueniverse>then set timeout to 100 before we send res.end()
01:20:51  <hueniverse>works in 0.10
01:20:53  <hueniverse>fails in 0.11
01:21:08  <hueniverse>and the issue boils down to, it's not waiting 100ms
01:21:20  * amartensquit (Quit: Leaving.)
01:21:21  <tjfontaine>hmm
01:22:29  <hueniverse>tjfontaine: biab, but you can see it if you npm install hapi than npm test
01:22:50  <othiym23>hueniverse: make sure mocha isn't doing something terrible and dumb to setTimeout
01:22:59  <othiym23>I see some hinkiness in its source
01:23:10  <othiym23>I do not trust mocha any further than I can throw it when it comes to events and timers
01:25:40  <othiym23>hmmm never mind, looks like it's mostly just trying to keep Sinon from doing terrible and dumb things
01:25:50  <othiym23>back to being Node's fault!
01:26:05  <MI6>nodejs-master: #496 UNSTABLE smartos-x64 (9/637) smartos-ia32 (2/637) http://jenkins.nodejs.org/job/nodejs-master/496/
01:26:37  <tjfontaine>othiym23: I have no problem believing it to be my fault :)
01:27:44  <tjfontaine>LOUDBOT: on point as ever
01:27:52  <othiym23>what it's right there in the right nav bar like it's always been
01:28:03  <othiym23>we have always been at war with Eastasia
01:28:19  <tjfontaine>up and until they promote ssh.github.com
01:30:55  * dshaw_quit (Quit: Leaving.)
01:34:54  <tjfontaine>well that's odd
01:35:00  <tjfontaine>node seems broken
01:35:23  <tjfontaine>/Users/tjfontaine/Development/hapi/node_modules/jade/node_modules/transformers/node_modules/uglify-js/lib/parse.js:53
01:35:26  <tjfontaine>KEYWORDS = makePredicate(KEYWORDS);
01:35:41  <tjfontaine>var KEYWORDS = 'break case catch const continue debugger default delete do else finally for function if in instanceof new return switch throw try typeof var void while with';
01:35:50  <tjfontaine>KEYWORDS = makePredicate(KEYWORDS);
01:36:02  <tjfontaine>is there a semantic change I'm missing with 'use strict';?
01:36:59  <othiym23>some extra keywords are reserved / blacklisted according to ES5 in strict mode
01:37:08  <othiym23>but I think I'm lacking context to understand what you're highlighting there
01:37:32  <tjfontaine>'use strict'; var foo = 'bar'; foo = 'baz';
01:37:35  <tjfontaine>should be fine though?
01:38:05  <othiym23>sure
01:38:11  <othiym23>this is what I'm referring to: http://es5.github.io/#x7.6.1.2
01:38:40  <tjfontaine>this is so weird, simple tests work but it's definitely failingn to parse this
01:39:15  <tjfontaine>and there are like 2341234123 versions of uglify included in this
01:44:04  <othiym23>that's a lot of versions of uglify
01:44:19  <tjfontaine>there were actually 4
01:44:22  <othiym23>what are you getting parse errors on?
01:44:42  * st_lukequit (Remote host closed the connection)
01:44:49  <tjfontaine>what you saw above, it's complaining that it KEYWORDS (and following) weren't definied, despite it showing clearly they were
01:44:53  <tjfontaine>*defined
01:45:30  <tjfontaine>anyway, I patched them all for now, and am looking at hoek and see it's using wall time, will try and make it use hrtime
01:46:03  <tjfontaine>I mean, if we're going to do it ...
01:46:27  <othiym23>I still want to know why gettimeofday / Date.now and hrtime disagree so badly on my machine
01:46:45  <othiym23>said machine is running ntpd slaved to 2 masters, so it's not like it's drifting *that* much
01:46:52  * st_lukejoined
01:47:33  <tjfontaine>define "disagree"
01:47:42  * dapquit (Quit: Leaving.)
01:48:16  <othiym23>https://gist.github.com/othiym23/6179922
01:48:27  <othiym23>it's still pretty much that bad on that particular machine
01:48:46  <othiym23>by which I mean this particular machine
01:48:49  <othiym23>that I'm typing on
01:48:50  <othiym23>right now
01:49:15  <tjfontaine>well, hrtime has nothing to do with the wallclock reall
01:49:16  <tjfontaine>y
01:49:43  * inolenjoined
01:49:59  <tjfontaine>the fact that there's a correlation on some systems is happenstance
01:50:28  <othiym23>yeah, but the hwclock and the tick counter shouldn't be *that* far off each other, should they?
01:50:35  <othiym23>is this some weird power-saving thing?
01:50:41  <tjfontaine>more than likely yes
01:51:07  <othiym23>it's a laptop, so I"m prepared to believe frequency scaling is in the mix somehow, but that's with the APM set for "maximum performance", plugged into the wall
01:51:54  <othiym23>anyway, I love hrtime but I'm not so sure how much I trust it for durations longer than about 10 seconds
01:54:40  * othiym23&
01:56:29  * abraxasjoined
01:58:39  <tjfontaine>hueniverse: I will do further investigation but the first timeout is indeed always wrong
02:01:11  <isaacs>tjfontaine: oh? what issue did it fix?
02:02:46  <isaacs>trevnorris: i'm gonna make pause() and resume() chainable I think
02:03:02  <isaacs>trevnorris: in response to that juliangruber issue about setEncoding
02:06:50  <MI6>nodejs-master-windows: #287 UNSTABLE windows-x64 (20/637) windows-ia32 (18/637) http://jenkins.nodejs.org/job/nodejs-master-windows/287/
02:16:03  * wavdedquit (Quit: Hasta la pasta)
02:17:44  * dshaw_joined
02:18:37  * st_lukequit (Remote host closed the connection)
02:22:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:42:06  * dshaw_quit (Quit: Leaving.)
02:43:45  * dshaw_joined
02:44:27  <isaacs>tjfontaine hueniverse: this timer thing is really interesting.
02:44:54  <isaacs>i can very reliably get process.hrtime() showing that the timers are dinging early. however, Date.now() shows a ms diff of 0 every time
02:48:27  * indexzeroquit (Quit: indexzero)
02:52:34  <MI6>joyent/node: isaacs master * 73d328d : doc: Adjust util stability index to 'API Frozen' - http://git.io/f8Mc9A
02:52:57  <MI6>joyent/node: isaacs v0.10 * 02eb9c8 : doc: Adjust util stability index to 'API Frozen' - http://git.io/Zx0ClQ
02:59:53  * dshaw_quit (Quit: Leaving.)
03:01:05  * dapjoined
03:04:05  * dshaw_joined
03:05:23  <MI6>nodejs-v0.10: #1451 UNSTABLE osx-ia32 (1/598) smartos-ia32 (1/598) osx-x64 (1/598) smartos-x64 (3/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1451/
03:05:57  * AvianFlujoined
03:06:10  <MI6>nodejs-master: #497 UNSTABLE linux-ia32 (4/637) smartos-x64 (10/637) osx-ia32 (1/637) smartos-ia32 (1/637) osx-x64 (1/637) linux-x64 (5/637) http://jenkins.nodejs.org/job/nodejs-master/497/
03:11:53  <tjfontaine>isaacs: pause/resume chain seems fine to me
03:11:59  <tjfontaine>isaacs: the exec one you just closed
03:13:24  * dapquit (Quit: Leaving.)
03:13:31  * c4miloquit (Remote host closed the connection)
03:14:45  <tjfontaine>isaacs: while riding the subway, my gut was telling me that the issue is that we're using the cached libuv loop time, which is 25ms behind, so showing that with hrtime seems straight forward because you're forcing the sysclal
03:14:49  <tjfontaine>*syscall
03:16:09  <tjfontaine>isaacs: you can see that by letting the loop iterate once by wrapping the first timeout in an immediate
03:16:13  * mcavagequit (Remote host closed the connection)
03:16:14  <tjfontaine>or another timer for that matter
03:16:47  <tjfontaine>so whatever the first deviation is, is roughly equivalent to the startup time of node
03:19:08  <tjfontaine>isaacs: https://gist.github.com/tjfontaine/6361795
03:21:17  <tjfontaine>so, the timer is firing at least 50ms later, but the starting timer point is not an extra syscall, it's from when libuv got to us
03:28:11  <mordy__>hrm; what's the equivalent of uv_stop in 0.8?
03:28:17  * mordy__is trying to port to 0.8
03:28:47  <mordy__>or is my only option to not use uv_run_default and run uv_run_once in a loop
03:29:07  <mordy__>i.e. while (dontstop) { uv_run_once(loop); }
03:29:31  <tjfontaine>I'm not going to say that's your only option, but it certainly is an option I can think of off the top of my head :)
03:30:21  * groundwaterjoined
03:30:21  * groundwaterquit (Client Quit)
03:32:14  <tjfontaine>mordy__: that's essentially what uv_run+stop is anyway
03:33:14  <mordy__>ahh
03:33:17  <mordy__>and there's a return value
03:33:30  <mordy__>which i must check to see if the loop still has stuff to do
03:34:07  <tjfontaine>right
03:40:50  * indexzerojoined
03:45:47  <MI6>nodejs-master-windows: #288 UNSTABLE windows-x64 (21/637) windows-ia32 (19/637) http://jenkins.nodejs.org/job/nodejs-master-windows/288/
03:46:52  * TooTallNatejoined
04:03:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:09:01  <mordy__>http://paste.scsys.co.uk/266784 -- hrm, this should cut it
04:09:04  <mordy__>let's see..
04:11:07  <mordy__>ok, fixed the UV stuff
04:11:12  <mordy__>now let's see node
04:20:29  <mordy__>hrm.. 0.8 has Buffer::New(char *, size_t) whereas in 0.10 it's ::New(const char *)
04:20:44  <mordy__>i'm imagining that 0.8 doesn't actually modify anything?
04:20:46  <MI6>nodejs-v0.10-windows: #179 UNSTABLE windows-x64 (7/598) windows-ia32 (8/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/179/
04:21:00  * dshaw_quit (Quit: Leaving.)
04:29:26  * kazuponquit (Remote host closed the connection)
04:43:16  * kazuponjoined
05:05:40  <MI6>nodejs-master-windows: #289 UNSTABLE windows-x64 (20/637) windows-ia32 (18/637) http://jenkins.nodejs.org/job/nodejs-master-windows/289/
05:07:40  <hueniverse>othiym23: we don't use mocha... for many reasons
05:29:35  * indexzeroquit (Quit: indexzero)
05:30:51  * pfox__quit (Remote host closed the connection)
05:31:20  * pfox__joined
05:51:12  * AvianFluquit (Remote host closed the connection)
05:51:41  * AvianFlujoined
05:52:49  <MI6>nodejs-master-windows: #290 UNSTABLE windows-x64 (18/637) windows-ia32 (21/637) http://jenkins.nodejs.org/job/nodejs-master-windows/290/
05:53:26  * indexzerojoined
06:04:46  * indexzeroquit (Quit: indexzero)
06:06:56  * AvianFluquit (Remote host closed the connection)
06:07:25  * AvianFlujoined
06:27:25  * defunctzombiechanged nick to defunctzombie_zz
06:31:24  * defunctzombie_zzchanged nick to defunctzombie
06:45:19  * defunctzombiechanged nick to defunctzombie_zz
06:45:27  * `3E|Zzzchanged nick to `3rdEden
06:46:35  <MI6>nodejs-v0.10-windows: #180 UNSTABLE windows-x64 (7/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/180/
06:50:12  * rvaggchanged nick to Omakase
06:50:37  * Omakasechanged nick to rvagg
06:52:17  * defunctzombie_zzchanged nick to defunctzombie
06:54:25  * brsonquit (Quit: leaving)
06:58:16  * abraxasquit (Remote host closed the connection)
07:01:55  * defunctzombiechanged nick to defunctzombie_zz
07:18:38  * AvianFluquit (Remote host closed the connection)
07:19:10  * wolfeida_quit (Remote host closed the connection)
07:21:58  * dominictarrjoined
07:23:15  * hzjoined
07:32:20  * csaohjoined
07:46:07  * dominictarrquit (Quit: dominictarr)
07:47:20  * julianduquequit (Quit: leaving)
08:08:59  * rendarjoined
08:11:50  * defunctzombie_zzchanged nick to defunctzombie
08:15:02  * dominictarrjoined
08:21:45  * defunctzombiechanged nick to defunctzombie_zz
08:29:45  * Benviejoined
08:31:42  * EhevuTovjoined
09:19:21  * bnoordhuisjoined
09:40:00  * kazuponquit (Remote host closed the connection)
09:44:02  <bnoordhuis>saghul: re: #908, what commit is that?
09:45:33  <saghul>bnoordhuis d48168a
09:46:19  * inolenquit (Quit: Leaving.)
09:47:00  * inolenjoined
09:47:24  <bnoordhuis>saghul: okay, thanks
09:47:33  <bnoordhuis>do older commits work?
09:47:42  <bnoordhuis>err, previous
09:48:57  <saghul>yes, I guess it will work if I revert this one: https://github.com/joyent/libuv/commit/cd2794c01fc84a4118f79e31071cb1bca78918f5
09:50:25  <bnoordhuis>sigh. well, at least it's easy to fix
09:50:39  <bnoordhuis>i'll have a patch in 5 minutes you can try
09:50:59  <saghul>nice! FWIW, abcad99 works
09:51:29  <saghul>I read something about that expression not being really constant, by that's about where my C fu ends
09:54:31  * hueniversequit (Read error: Connection reset by peer)
09:56:10  * hueniversejoined
09:59:30  <MI6>joyent/libuv: bnoordhuis created branch saghul-review-plox - http://git.io/Shz_zw
09:59:47  <bnoordhuis>saghul: ^
10:00:05  <saghul>sweet, testing
10:04:04  <saghul>bnoordhuis works!
10:04:22  <bnoordhuis>nice, thanks
10:04:38  <MI6>joyent/libuv: Ben Noordhuis master * 82f2472 : darwin: fix 10.6 build error in fsevents.c - http://git.io/9r9oAw
10:07:24  <rendar>what is that saghul thing all about?
10:11:48  <bnoordhuis>'that saghul thing'... saghul has feelings too, you know
10:12:24  <bnoordhuis>gcc/clang on 10.6 was complaining about a const int expression not being constant at compile time
10:14:31  <rendar>oh, sorry! saghul is a guy?
10:14:47  <MI6>libuv-review: #51 UNSTABLE windows-x64 (4/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-review/51/
10:14:55  <rendar>bnoordhuis, i see...
10:17:39  * piscisaureus_joined
10:18:38  <MI6>libuv-master-gyp: #143 UNSTABLE windows-x64 (3/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/143/
10:19:02  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/issues/909
10:19:09  <bnoordhuis>also, g'morning :)
10:19:18  <piscisaureus_>good morning ben
10:20:51  <MI6>libuv-master: #204 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/204/
10:21:25  <piscisaureus_>bnoordhuis: yeah I saw it. Unfortunately I won't have time to fix this anytime soon.
10:21:48  <piscisaureus_>well - we could land that patch if the guy signs the cla
10:21:53  <piscisaureus_>(although I have no clue why it works)
10:22:02  <bnoordhuis>hah, that doesn't inspire faith
10:22:08  <piscisaureus_>well
10:22:10  <bnoordhuis>maybe sblom can look at it?
10:22:20  <piscisaureus_>it's more that I have forgotten how that code works
10:22:32  <piscisaureus_>which makes reviewing the patch not easy
10:22:35  * EhevuTovquit (Quit: This computer has gone to sleep)
10:22:52  <piscisaureus_>that code is quite old - it predates libuv - and I wasn't as confident writing c as i am today :)
10:23:07  <bnoordhuis>ah, okay
10:24:43  <bnoordhuis>so, now what? i'd fix it but i don't really have a clue how paths are supposed to work on windows
10:25:50  * csaohquit (Quit: csaoh)
10:26:30  <piscisaureus_>I also see that we strip single quotes - bad
10:26:54  <piscisaureus_>bnoordhuis: well, it works the same as on unix (forget about PATHEXT now)
10:27:04  <MI6>joyent/node: Domenic Denicola master * 9c110d8 : vm: add isContext; prevent double-contextifying (+2 more commits) - http://git.io/MnBdgA
10:27:12  <piscisaureus_>bnoordhuis: except paths are separated by ;
10:27:16  <piscisaureus_>and not :
10:28:00  <piscisaureus_>bnoordhuis: paths in the PATH env var may be quoted but I'm doing that wrong
10:28:24  <piscisaureus_>even more wrong
10:28:25  <piscisaureus_>...
10:28:49  <piscisaureus_>it assumes a single quote ' can also be used but in fact it isn't okay
10:28:56  <bnoordhuis>oh dear
10:29:52  <piscisaureus_>but now I have to figure out what this would do
10:30:07  <piscisaureus_>PATH = c:\windows;"foo"bar";c:\stuff
10:32:09  <piscisaureus_>oh well
10:32:15  <piscisaureus_>it seems that that breaks path parsing completely
10:32:21  <piscisaureus_>in windows itself
10:35:59  * Benviequit (Ping timeout: 260 seconds)
10:37:33  * kazuponjoined
10:37:41  <piscisaureus_>okay, so the rules are
10:38:17  <MI6>joyent/node: Ben Noordhuis master * 29d3624 : crypto: make randomBytes/pbkdf2 cbs domain aware - http://git.io/yl4Vnw
10:38:35  <piscisaureus_>* a path entry may contain quoted parts. Quoted parts are valid even in the middle of a path (e.g. c:\win"downs
10:38:53  <piscisaureus_>e.g. c:\win"dows"\system32 would be perfectly legal
10:39:30  <piscisaureus_>however it may not contain any *empty* quoted parts, eg. c:\""windows is invalid. It interrupts path parsing at that point and further path components are not considered.
10:40:22  <bnoordhuis>is there any logic to that?
10:40:33  <MI6>nodejs-master: #498 UNSTABLE smartos-x64 (8/638) osx-ia32 (1/638) smartos-ia32 (2/638) http://jenkins.nodejs.org/job/nodejs-master/498/
10:40:49  <piscisaureus_>no
10:42:14  <piscisaureus_>also, the last PATH entry may contain an "unbalanced" quote
10:42:20  * csaohjoined
10:42:41  <piscisaureus_>so PATH=c:\windows;"c:\stuff
10:42:44  <piscisaureus_>would be okay
10:43:56  <bnoordhuis>now that you have it all fresh in memory, i move that you go in and fix src/win :)
10:43:58  * csaohquit (Client Quit)
10:44:14  <piscisaureus_>well - I am compelled but I have no time
10:44:43  <piscisaureus_>I have about 11 days to finish execSync, Task and create a presentation about it
10:44:53  <piscisaureus_>not to mention file my tax forms
10:44:55  <MI6>libuv-node-integration: #187 UNSTABLE smartos-x64 (9/637) osx-x64 (2/637) smartos-ia32 (2/637) linux-x64 (5/637) linux-ia32 (1/637) http://jenkins.nodejs.org/job/libuv-node-integration/187/
10:45:06  <piscisaureus_>that includes the weekends
10:45:28  <piscisaureus_>also this is much more work than computing the environmental impact of saghul's patch
10:45:40  <bnoordhuis>piscisaureus_: also, setting up BVs
10:45:51  <piscisaureus_>yes that too
10:45:58  <piscisaureus_>there you go.
10:46:00  <piscisaureus_>all my excuses
10:46:14  <bnoordhuis>i remember you had one or two questions. mail sjoerd, i think he's back from his holiday
10:51:12  <MI6>nodejs-v0.10: #1452 UNSTABLE smartos-ia32 (1/598) osx-x64 (1/598) linux-x64 (1/598) smartos-x64 (1/598) linux-ia32 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1452/
10:52:18  <MI6>nodejs-master: #499 UNSTABLE linux-ia32 (1/639) smartos-x64 (10/639) smartos-ia32 (3/639) linux-x64 (1/639) http://jenkins.nodejs.org/job/nodejs-master/499/
10:56:02  <MI6>nodejs-master-windows: #291 UNSTABLE windows-x64 (20/638) windows-ia32 (26/638) http://jenkins.nodejs.org/job/nodejs-master-windows/291/
10:59:26  * csaohjoined
11:06:10  * leonvvjoined
11:14:10  * piscisaureus_quit (Ping timeout: 245 seconds)
11:45:22  <MI6>nodejs-master-windows: #292 FAILURE windows-ia32 (24/639) http://jenkins.nodejs.org/job/nodejs-master-windows/292/
11:46:53  * kazupon_joined
11:48:05  * piscisaureus_joined
11:48:52  * kazuponquit (Ping timeout: 246 seconds)
12:17:11  * kazuponjoined
12:19:50  * kazupon_quit (Ping timeout: 240 seconds)
12:24:48  <piscisaureus_>hmm why is windowsVerbatimArguments not documented
12:27:01  <piscisaureus_>Also "Example of checking for failed exec:" is out of date :(
12:27:54  <piscisaureus_>"signal String the signal passed to kill the child process, if it was killed by the parent." -> inaccurate.
12:28:14  * kazuponquit (Ping timeout: 240 seconds)
12:48:26  * AvianFlujoined
12:50:11  * pachetjoined
12:57:20  * leonvvquit (Remote host closed the connection)
13:01:53  * piscisaureus_quit (Read error: No route to host)
13:09:02  * bnoordhuisquit (Ping timeout: 240 seconds)
13:18:09  * hzquit (Ping timeout: 276 seconds)
13:22:09  * piscisaureus_joined
13:23:29  * hzjoined
13:35:48  * kazuponjoined
13:40:41  * AvianFluquit (Remote host closed the connection)
13:40:54  * kazuponquit (Ping timeout: 276 seconds)
13:46:45  * c4milojoined
13:54:07  * csaohquit (Quit: csaoh)
13:55:56  * csaohjoined
14:01:27  * jmar777joined
14:27:48  * bnoordhuisjoined
14:30:01  * c4miloquit (Remote host closed the connection)
14:33:15  * AvianFlujoined
14:35:36  * kevinswiberjoined
14:39:35  * c4milojoined
15:05:51  * kazuponjoined
15:06:15  * piscisaureus_quit (Ping timeout: 245 seconds)
15:06:36  * indexzerojoined
15:17:37  <MI6>nodejs-master: #500 UNSTABLE smartos-x64 (8/639) smartos-ia32 (3/639) http://jenkins.nodejs.org/job/nodejs-master/500/
15:18:59  <mordy__>hrm, so we now have 0.8 support
15:19:17  <mordy__>this wasn't very painful. 0.11 fails with a flood of errors relating to Persistent<> handles
15:19:40  <mordy__>there seems to be some kind of #define to be used to enable Persistent<T> : Handle<T>
15:19:54  <mordy__>would it be safe to enable this? or would it break something
15:21:10  * bradleymeckjoined
15:24:34  <bnoordhuis>mordy__: you mean V8_USE_UNSAFE_HANDLES? that's going away
15:25:40  <mordy__>yep :/
15:29:37  * kevinswiberquit (Remote host closed the connection)
15:39:13  * hzquit
15:41:03  * AvianFlu_joined
15:41:12  * AvianFluquit (Disconnected by services)
15:41:16  * AvianFlu_changed nick to AvianFlu
15:53:30  * piscisaureus_joined
16:05:03  * dapjoined
16:08:57  * TooTallNatejoined
16:17:06  * kevinswiberjoined
16:18:47  <piscisaureus_>bnoordhuis: hey
16:18:59  <piscisaureus_>bnoordhuis: do you know if uv_process_kill could ever fail with ESRCH ?
16:20:38  <tjfontaine>mordy__: "safe" in that it will survive the 0.12 release
16:22:34  * bnoordhuisquit (Ping timeout: 246 seconds)
16:22:58  * sblomjoined
16:24:26  <mordy__>tjfontaine: hrm; alright
16:24:33  <mordy__>i'm guessing 0.12 will be around for a while
16:24:41  <mordy__>do yall have any release cycle?
16:24:55  <tjfontaine>if you can avoid using the pattern today your life will be easier later
16:25:41  * c4miloquit (Remote host closed the connection)
16:26:01  <tjfontaine>mordy__: we do have a cycle, we're gearing up for 0.12 "soon", after that it's focus on 1.0
16:26:23  <isaacs>ircretary: tell bnoordhuis Hey, I saw you landed most of https://github.com/joyent/node/pull/6121. Did you want me to review the options arg and doc bits?
16:26:23  <ircretary>isaacs: I'll be sure to tell bnoordhuis
16:26:58  <isaacs>ircretary: tell bnoordhuis Or was there some other reason you wanted to push back on that?
16:26:59  <ircretary>isaacs: I'll be sure to tell bnoordhuis
16:27:36  <tjfontaine>isaacs: did you see my response on the timer issue?
16:27:50  <isaacs>tjfontaine: no, i'll look now
16:27:54  <tjfontaine>k
16:28:39  * amartensjoined
16:32:11  * dominictarrquit (Quit: dominictarr)
16:32:36  * kevinswiberquit (Remote host closed the connection)
16:33:17  * dshaw_joined
16:35:27  * kevinswiberjoined
16:37:19  <mordy__>so what's exactly the deal with the new Persistent<> handles.. let me have a look
16:37:20  <Domenic_>isaacs: the options arg and doc bits are the only relevant parts of that PR, I just put it on top of the PR that bnoordhuis landed.
16:38:12  <tjfontaine>mordy__: Handle is going away, there won't be a commont root between Local and Persistent anymore
16:38:23  <Domenic_>isaacs: I guess making them separate PRs may not have been necessary, but I liked separating the memory-leak stuff from the API-related stuff.
16:38:28  <mordy__>tjfontaine: so i want to change all my code to Local<> too
16:38:35  <tjfontaine>ideally yes
16:38:54  <isaacs>Domenic_: ohh, i see
16:39:08  <tjfontaine>mordy__: in master you'll see PersistentToLocal stuff to handle that transition as well
16:39:20  <mordy__>i wonder if there's some trick to #define Handle "DONT USE THIS"
16:39:32  <mordy__>oh wait, no
16:39:41  <isaacs>Domenic_: can you rebase vm-options-and-docs on top of joyent/master and then `git push origin +vm-options-and-docs`?
16:39:50  <mordy__>do any v8 prototypes still return/accept Handle<> though
16:39:58  <isaacs>Domenic_: then the bottom commits will disappear in github ui
16:40:24  <Domenic_>isaacs: yeah that was my plan for tonight. can do it at work if that'd be helpful.
16:40:27  <isaacs>can someone review this simple and quick regression fix? https://github.com/isaacs/node/commit/fbb963b5d520a70d9c3f2f9ec116d79a0c676f80
16:40:32  <tjfontaine>mordy__: it should be fine even if they do, because Local : Handle
16:40:38  <isaacs>Domenic_: oh, right, this isn't your job. sorry, don't worry, i'll do it :)
16:41:33  <mordy__>it woudl be helpful if v8.h wasn't 4k lines
16:41:40  <tjfontaine>mordy__: ha ha
16:42:31  <mordy__>it's probably one of the worst APIs i've ever seen. the API in itself isn't that bad, but without documentation, the names are so unintuitive
16:43:03  <mordy__>and what's up with the PascalCase
16:44:03  <tjfontaine>isaacs: btw, lgtm
16:44:28  <tjfontaine>maybe time to rethink him :P
16:44:32  <tjfontaine>er ww
16:47:57  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:49:01  * kevinswiberquit (Remote host closed the connection)
16:50:46  <MI6>joyent/node: isaacs v0.10 * fbb963b : stream: check _events before _events.error - http://git.io/1pW5ZQ
16:58:12  <MI6>nodejs-v0.10: #1453 UNSTABLE linux-x64 (2/598) smartos-x64 (2/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1453/
16:59:21  * kevinswiberjoined
16:59:33  * bnoordhuisjoined
16:59:47  * csaohquit (Quit: csaoh)
17:02:30  * TooTallNatejoined
17:03:27  * dominictarrjoined
17:05:16  * Somebodyjoined
17:06:06  <bnoordhuis>isaacs: re: #6121, what i landed was #6117 - seems they overlap a little
17:06:19  <bnoordhuis>Domenic_: ^
17:06:20  <isaacs>bnoordhuis: yeah, Domenic_ pointed that out
17:06:33  <isaacs>bnoordhuis: i'll just review and cherry-pick the last two commits
17:06:36  <bnoordhuis>cool
17:08:53  <trevnorris>isaacs: whatever. after years of web development using jquery i've come to find chainability overrated.
17:09:10  <trevnorris>isaacs: but if it's not returning anything then might as well put it to use
17:09:41  <isaacs>trevnorris: yeah, that's kind of where i'm at, too
17:10:00  <isaacs>trevnorris: it *would* be nice to be able to do var server = net.createServer(fn).listen(PORT);
17:12:24  * defunctzombie_zzchanged nick to defunctzombie
17:13:26  <isaacs>merging v0.10 into master, please don't push anything for a minute
17:14:03  * mikealjoined
17:14:40  * defunctzombiechanged nick to defunctzombie_zz
17:14:50  * defunctzombie_zzchanged nick to defunctzombie
17:17:46  <MI6>joyent/node: isaacs master * 9635861 : Merge remote-tracking branch 'ry/v0.10' (+13 more commits) - http://git.io/XB9HDw
17:21:58  <tjfontaine>isaacs: https://gist.github.com/tjfontaine/6368687
17:22:34  <tjfontaine>I still need to cleanup my test case
17:25:02  <isaacs>tjfontaine: mostly lgtm. should probably cache the `process.binding('uv')`
17:25:07  <isaacs>+test, obv
17:25:16  <tjfontaine>isaacs: isMain will be true multiple times?
17:26:33  <isaacs>tjfontaine: oh, haha, right
17:27:01  <MI6>nodejs-master: #501 UNSTABLE smartos-x64 (9/640) smartos-ia32 (2/640) osx-x64 (1/640) http://jenkins.nodejs.org/job/nodejs-master/501/
17:27:14  <tjfontaine>I didn't want to put my name onto module.js, but I need to be after any fs operations
17:27:18  <tjfontaine>:)
17:27:27  <tjfontaine>now people can blame me :)
17:29:49  <Domenic_>i felt pretty bad touching module.js for the vm stuff, heh
17:29:56  <tjfontaine>inorite?
17:30:14  <tjfontaine>this will likely also fix some of the debugger tests on smartos ...
17:30:17  <tjfontaine>as screwed up as that is
17:31:16  * AvianFluquit (Remote host closed the connection)
17:31:40  * dshaw_quit (Ping timeout: 245 seconds)
17:32:03  <MI6>nodejs-v0.10-windows: #181 UNSTABLE windows-x64 (8/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/181/
17:32:14  * dshaw_joined
17:32:44  <isaacs>tjfontaine: ohh... interesting
17:33:15  <tjfontaine>I'm building now to test, but I'm fairly positive this is the "startup issue" I was debugging
17:33:20  <isaacs>well, "fixes a demonstrable bug that we cannot document our way out of" is a fine reason to touch frozen code.
17:33:31  <isaacs>t's really the ONLY reason to touch frozen code
17:33:47  <tjfontaine>after looking at this again debug node has a delay of 50ms to stabalize
17:33:58  <tjfontaine>well, we're firing early on that all the time
17:34:24  * defunctzombiechanged nick to defunctzombie_zz
17:34:41  * Benviejoined
17:37:07  * AvianFlujoined
17:40:23  * kevinswiberquit (Remote host closed the connection)
17:43:15  * kevinswiberjoined
17:44:12  <isaacs>i see
17:44:16  <isaacs>that kinda makes sense, then
17:44:33  <tjfontaine>it would if I could prove it
17:44:50  <tjfontaine>racey tests are racey.
17:48:08  <isaacs>tjfontaine: well, even if it doesn't fix the racey tests (which, we probably won't know unless we see them not-fail for a few days/weeks) but it does fix the "timers fire early" bug, which can be reproduced now, then great.
17:49:19  <isaacs>tjfontaine: i'm not finding the timer bug, or your comment on it. which one was that?
17:50:15  <isaacs>TooTallNate: let's revisit https://github.com/TooTallNate/node/commit/4095add80ca03d9a016ad0f2ae78b51d2bd253a7 after Domenic_'s 2 vm patches and then my update to catch syntax errors better.
17:50:35  <TooTallNate>isaacs: ya for sure, sounds good
17:50:37  <isaacs>TooTallNate: but i'm adding this to the list to rebase onto that pile so we can treat const's like syntax violations
17:50:54  <isaacs>TooTallNate: i think it might be unnecessary then, since run-time errors will never be treated like syntax continuations
17:50:57  <TooTallNate>isaacs: well, reassignment of consts, specifially ;)
17:50:59  <isaacs>TooTallNate: only parse-time errors are
17:51:01  <isaacs>right
17:51:05  <isaacs>and that'll always happen at run-time
17:51:10  <isaacs>we could land this patch in v0.10, of course.
17:51:14  <tjfontaine>isaacs: there's not a github issue atm, just from here from hueniverse
17:51:22  <isaacs>ahhh
17:51:24  * brsonjoined
17:51:24  <isaacs>ok
17:51:42  <isaacs>that explains it. never attribute to github's crappy search what can be explained by not putting it in github in teh first place.
17:51:46  <tjfontaine>hehe
17:52:01  <tjfontaine>I shouldn't have said "issue" i should have said "irc discussion"
17:55:57  <isaacs>no worries
17:59:52  * Benviequit (Ping timeout: 246 seconds)
18:03:01  * c4milojoined
18:03:32  * jmar777quit (Read error: Connection reset by peer)
18:03:50  * jmar777joined
18:04:00  <tjfontaine>I'm not sure what the goal should be here, I'm within 2ms as opposed to 25ms -- but
18:04:45  <piscisaureus_>https://github.com/piscisaureus/node/commit/a1c93897bd1e1d86436679f8f609d6501a17055c <-- now completely works
18:05:06  <piscisaureus_>next up is to move all spawnSync code to a separate file and revert process_wrap.cc to it's old state
18:05:26  <piscisaureus_>unfortunately my laptop is now out of juice
18:05:58  <isaacs>piscisaureus_: \o/
18:05:59  <isaacs>awesome!
18:09:59  * mikealquit (Quit: Leaving.)
18:10:19  * mikealjoined
18:10:25  * piscisaureus_quit (Ping timeout: 245 seconds)
18:10:40  <isaacs>ok, yoga time, then land the vm stuff from Domenic, fix syntax errors in teh repl, and write a talk for nodeconf eu maybe.
18:10:49  * isaacs&
18:10:54  <hueniverse>tjfontaine: what's the latest on my timer bug?
18:12:04  * kazuponquit (Remote host closed the connection)
18:13:09  <othiym23>hueniverse: what are you using for tests that looks so mocha-like?
18:14:41  <hueniverse>othiym23: lab. wrote it to work with all our 1000+ mocha tests. it is super simple using domains. we had to write it because we had the worse time fighting mocha over our use of domains in hapi.
18:15:11  <othiym23>yeah, I had to do some dumb, Macgyveresque things to test domains-based code in my own tests
18:15:14  <hueniverse>othiym23: also didn't need all the crap for browsers, customization, etc. but also wanted built-in coverage
18:15:56  <othiym23>I'll take a look at it, I've been meaning to get away from Mocha for a while now
18:16:05  <othiym23>and that's easier than moving everything to tap
18:16:10  <hueniverse>othiym23: I am careful not to call it a test framework, only a test tool. we have no intentions of extending its applicability :-)
18:16:23  <hueniverse>but are open to improvements
18:17:00  <hueniverse>esp around how we interact with domains. it is very sensitive to domain bugs (which we find on occasion when our domain fails to trap test exceptions)
18:17:04  <othiym23>all I care about are nested describe / it blocks and an easy way to do both sync and async test cases
18:17:13  <hueniverse>got all that
18:17:17  * dshaw_quit (Quit: Leaving.)
18:17:17  <hueniverse>same as express
18:17:22  <hueniverse>sorry
18:17:25  <hueniverse>same as mocha
18:17:38  * julianduquejoined
18:17:49  <othiym23>as long as it breaks horribly and obviously on domain failures, I'm good with that, because I'm running my tests under 0.6 / 0.8 / 0.10 and need consistent error behavior across all of them
18:17:54  <othiym23>same diff ;)
18:19:01  <hueniverse>well, it uses domains, so you need 0.10...
18:19:13  <Domenic_>hueniverse: in-ter-esting...
18:19:32  <hueniverse>0.8 has the domain nesting bug that caused me a week of grief
18:19:36  <hueniverse>while writing lab
18:19:44  <Domenic_>hueniverse: yes that bug is horrid.
18:20:19  <Domenic_>https://github.com/kriskowal/asap/blob/master/test/domain-implementation.js#L13-L39
18:20:22  <tjfontaine>hueniverse: the latest is, I think I'm going to revert Timer.now() usage, because it's just never going to do what people expect
18:20:31  <tjfontaine>hueniverse: I am going to file the bug now
18:20:42  <hueniverse>Domenic_: I wish I was less lazy about finding bugs when lab pukes.
18:21:20  <hueniverse>tjfontaine: I just expect a 300ms timeout to take, well, 300ms and not 2 :-)
18:21:51  <tjfontaine>hueniverse: right, as of now it's only a problem in two scenarios, 1) first turn of the node event loop, 2) cpu bound application :)
18:22:38  * defunctzombie_zzchanged nick to defunctzombie
18:24:01  <hueniverse>tjfontaine: what's interesting is that setting the 300ms timeout inside a wrapper 0ms timeout works
18:24:50  <tjfontaine>hueniverse: right, so the loop sets the time, then we go to launch your module, which in turn does a bunch of sync fs operations (which take time) so by the time you setTimeout the loop time is stale
18:25:29  <tjfontaine>process.binding('timer_wrap').Timer.now = Date.now; <-- can monkey patch your away from currently
18:25:29  * mcavagejoined
18:28:03  * kevinswiberquit (Remote host closed the connection)
18:29:25  * dapquit (Quit: Leaving.)
18:29:44  * dapjoined
18:30:47  * defunctzombiechanged nick to defunctzombie_zz
18:30:48  <hueniverse>tjfontaine: that works
18:31:24  * isaacbwjoined
18:31:37  <tjfontaine>right, I'm about to make the pull request that does that, but in a nicer monotonic way
18:31:42  <hueniverse>tjfontaine: what's the eta on the next 0.11 release? my goal is to move one server to 0.11 in production as soon as we pass all the hapi tests...
18:31:47  * kevinswiberjoined
18:32:04  <isaacbw>bnoordhuis: I said this in #node.js but it will probably get lost: did you ever end up switching over to passing pointers rather than whole structs?
18:32:36  <tjfontaine>hueniverse: probably tomorrow, if isaacs is cool with that
18:32:45  <trevnorris>isaacs: wtf is _thrid_party_main?
18:32:53  <tjfontaine>haha you just found that one :)
18:32:54  <trevnorris>*_third_party_main
18:33:30  <tjfontaine>trevnorris: did you look at the comment in src/node.js?
18:35:57  <trevnorris>tjfontaine: which one? tracing back through how that was introduced is a pain
18:36:40  <tjfontaine>trevnorris: https://github.com/joyent/node/blob/master/src/node.js#L66-L68
18:37:28  <trevnorris>tjfontaine: ah, comment, not commit
18:37:31  * rendarquit (Ping timeout: 245 seconds)
18:37:52  <trevnorris>tjfontaine: yeah, saw that.it just seems like some seriously legacy stuff that might not need to be in there anymore?
18:38:21  * sblomquit (Ping timeout: 245 seconds)
18:38:58  <MI6>nodejs-master-windows: #293 UNSTABLE windows-x64 (22/640) windows-ia32 (23/640) http://jenkins.nodejs.org/job/nodejs-master-windows/293/
18:39:01  <tjfontaine>trevnorris: I suspect there are silent people out there relying on this, why is it causing you a problem?
18:39:18  <trevnorris>tjfontaine: no problem. i just like to delete code :)
18:40:00  <tjfontaine>hah
18:40:22  <MI6>libuv-master: #205 UNSTABLE linux (1/193) windows (4/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/205/
18:41:53  * piscisaureus_joined
18:42:21  * kazuponjoined
18:42:39  <tjfontaine>isaacbw: btw, the commit hasn't landed for uv, but as of the status call yesterday bnoordhuis was planning on doing it
18:43:02  <trevnorris>bnoordhuis: how's multi-context coming? after using it for a bit you've done a solid job.
18:43:07  <isaacbw>tjfontaine: awesome
18:43:13  <hueniverse>tjfontaine: sweet. thanks.
18:43:58  <bnoordhuis>trevnorris: thanks :)
18:44:19  <bnoordhuis>trevnorris: i took a multi-context break today (mostly)
18:44:28  <bnoordhuis>need to figure out what to add next
18:44:45  <bnoordhuis>if you or anyone else has suggestions for the js api, now is the time to speak up
18:45:08  <tjfontaine>bnoordhuis: thoughts on https://github.com/joyent/node/pull/6147 (cc hueniverse)
18:45:31  <trevnorris>i don't give a crap about js apis. sort of feel those could go in after. the amount of rebasing you're having to do to keep the native code uptodate is sorta ridiculous.
18:46:35  <bnoordhuis>yeah, it's kind of painful. guess i should land it soon
18:46:54  <bnoordhuis>tjfontaine: updating the timestamp is pretty expensive
18:47:05  * defunctzombie_zzchanged nick to defunctzombie
18:47:06  <isaacbw>bnoordhuis: the reason I ask is that I'm planning on writing a binding for common lisp
18:47:26  <bnoordhuis>tjfontaine: particularly on solaris and windows, i think
18:47:34  <isaacbw>I saw your conversation re: cl-async, but it doesn't look like the author is terribly interested in actually switching over to libuv
18:47:35  <trevnorris>i agree. since the js api is additive so it _could_ be done during the v0.13 branch. and it seems like more feature requests don't come until after something is officially committed.
18:47:38  <tjfontaine>in my testing it didn't seem that bad on solaris
18:47:59  <bnoordhuis>isaacbw: i take it the structs are rather awkward to work with?
18:47:59  * dshaw_joined
18:48:13  <trevnorris>we should probably have a PR cleanup. after the v8 upgrade, and now this, they're all pretty much invalid. :P
18:48:48  <bnoordhuis>tjfontaine: when you say 'timers fire early', what exactly happens?
18:48:49  <isaacbw>bnoordhuis: they require a bit of hackiness to work with cffi
18:49:04  <bnoordhuis>tjfontaine: i ask because there's an outstanding libuv issue with timers firing too early
18:49:20  <tjfontaine>bnoordhuis: other fix I did, https://gist.github.com/tjfontaine/6368687
18:49:27  <isaacbw>though as the cl-async guy said, that can be fixed pretty easily with minimal layer written in c
18:49:52  * Somebodyquit (Remote host closed the connection)
18:50:29  <tjfontaine>bnoordhuis: the issue is on load we're using a cached time, but we've done fs.ops that have pushed the time a while later, so you set a timeout on first turn of 50ms, it appears as if it fired 25ms early, but really it was accurate as far as libuv is concerned but not if you're observing externally
18:50:36  <bnoordhuis>tjfontaine: i like the explicit approach better. however, snake_case :)
18:50:38  * kazuponquit (Ping timeout: 240 seconds)
18:51:01  <tjfontaine>bnoordhuis: the explicit case doesn't solve the problem for people who do cpu bound or other sync operations though?
18:51:04  <bnoordhuis>isaacbw: interesting. i'll try to get that struct rework thing done before the next minor libuv release
18:51:23  <bnoordhuis>isaacbw: it's quite a bit of work though (not difficult work, however)
18:52:01  <bnoordhuis>tjfontaine: no, that's true. still, calling clock_gettime() all the time will make me feel sad :(
18:52:55  <tjfontaine>bnoordhuis: it's a damned if we do, damned if we don't sort of thing
18:53:11  <bnoordhuis>yeah, i guess it is
18:53:30  <bnoordhuis>i've toyed around with reading the TSC rather than making a syscall
18:53:43  <bnoordhuis>but the TSC is subject to drift too, of course
18:53:59  <tjfontaine>frustrating
18:54:15  <bnoordhuis>i guess that would only be a real issue when people have event loop ticks that last multiple hours
18:54:18  <bnoordhuis>but still
18:54:25  <isaacbw>bnoordhuis: I imagine an API change like that could get pretty tedious
18:54:51  <bnoordhuis>isaacbw: yeah. it's not very complicated but it requires updating all tests, for example
18:55:00  <bnoordhuis>i just need to draw up the mental strength to go in and do it
18:55:41  <bnoordhuis>trevnorris: re PR cleanup: yes, agreed
18:58:48  <bnoordhuis>Error — Failing tests -- osx-ia32: 1, smartos-ia32: 6, osx-x64: 1, smartos-x64: 201 <- what's up with smartos-x64?
18:58:58  <bnoordhuis>they're all failing with EADDRINUSE
18:59:10  <tjfontaine>is there a libuv-integration test running?
18:59:12  <MI6>libuv-node-integration: #188 UNSTABLE smartos-x64 (11/640) smartos-ia32 (2/640) linux-x64 (6/640) linux-ia32 (1/640) http://jenkins.nodejs.org/job/libuv-node-integration/188/
18:59:21  <tjfontaine>that answers taht
19:01:19  <tjfontaine>hm or
19:01:33  * hzjoined
19:02:01  <tjfontaine>ah yes, good ol hung processes
19:04:47  <bnoordhuis>seems to happen with more PRs
19:04:55  <isaacbw>bnoordhuis: well, I'll be in your debt if/when you do. It would save a lot of work
19:05:05  <isaacbw>*save me :p
19:05:09  * hzquit (Client Quit)
19:05:12  <bnoordhuis>heh :)
19:05:53  * defunctzombiechanged nick to defunctzombie_zz
19:06:31  <trevnorris>hm. tracing every async callback path in core is sort of difficult :P
19:08:31  <tjfontaine>bnoordhuis: yes, there were hung debugger tests
19:08:45  * ecrjoined
19:08:47  * ecrquit (Client Quit)
19:08:55  <tjfontaine>bnoordhuis: from a broken PR build
19:10:24  * ecrjoined
19:11:10  <MI6>joyent/node: Timothy J Fontaine master * 93b0624 : timer_wrap: Timer.now always update loop time - http://git.io/yD8FXQ
19:12:10  <tjfontaine>hueniverse: the fix will be in the next release
19:17:13  * kazuponjoined
19:18:15  * dshaw_quit (Ping timeout: 276 seconds)
19:18:59  * EhevuTovjoined
19:19:02  * AvianFluquit (Remote host closed the connection)
19:20:27  * AvianFlujoined
19:20:52  <MI6>nodejs-master: #502 UNSTABLE smartos-x64 (6/641) osx-ia32 (1/641) http://jenkins.nodejs.org/job/nodejs-master/502/
19:21:47  * kazuponquit (Ping timeout: 260 seconds)
19:33:16  * mikealquit (Quit: Leaving.)
19:33:47  * dshaw_joined
19:34:36  * kevinswiberquit (Remote host closed the connection)
19:34:49  * mikealjoined
19:37:29  * kevinswiberjoined
19:38:03  * dshaw_quit (Ping timeout: 245 seconds)
19:39:42  * indexzeroquit (Quit: indexzero)
19:41:05  <MI6>nodejs-master-windows: #294 UNSTABLE windows-x64 (25/640) windows-ia32 (24/640) http://jenkins.nodejs.org/job/nodejs-master-windows/294/
19:56:16  * dshaw_joined
19:56:48  <hueniverse>One more: console.log(JSON.stringify((new Buffer('text\0!', 'ascii')).toString())); -> 0.10 "text !", 0.11 "text\u0000!" which one is a bug?
19:57:12  <trevnorris>hueniverse: neither
19:57:30  <trevnorris>hueniverse: has to do with the switch to the new v8 WriteOneByte API
19:57:42  <trevnorris>instead of WriteAscii
19:58:28  <trevnorris>i remember this conversation with bnoordhuis, he could give you more specifics
19:58:34  <Domenic_>"text\u0000!" looks more correct, assuming it was JSON.stringify that introduced the escaping
19:58:48  <Domenic_>yeah
19:58:49  <hueniverse>Domenic_: it was
19:59:34  <trevnorris>Buffer#toString() used to use asciiSlice(), which internally v8 changed the API.
19:59:42  <Domenic_>I'd imagine JSON.stringify(string) should equal JSON.stringify((new Buffer(string, 'ascii')).toString()), for ascii strings at least.
20:00:39  <hueniverse>What's the process for these? Basically, I have 0.10 code that works and doesn't under 0.11 but we got all these cases where the answer is 0.11 is right - which is fine - but I bet others will hit them at some point with 0.12
20:02:09  <Domenic_>i guess this seems like a breaking change on the same level as breaking GEM/PUN support. not sure if the maintainers feel like documenting those.
20:02:28  <othiym23>seems like that stuff should go into the release notes
20:03:26  * piscisaureus_quit (Ping timeout: 240 seconds)
20:04:51  <hueniverse>I'm happy to add them somewhere, just need to know where
20:04:56  <bnoordhuis>what blasphemy is this? documenting things?
20:05:07  <bnoordhuis>hueniverse: the wiki is the place for it
20:05:27  <hueniverse>bnoordhuis: care to create a page or guide me where to create it?
20:05:29  <bnoordhuis>don't know if there's a v0.10-to-v0.12 page yet. if there isn't, feel free to create one
20:05:42  <bnoordhuis>hah, okay :) let me look up the previous one
20:05:57  <bnoordhuis>hueniverse: https://github.com/joyent/node/wiki/Api-changes-between-v0.8-and-v0.10
20:06:37  <hueniverse>bnoordhuis: thanks
20:06:51  <hueniverse>should this be caught by domains: https://gist.github.com/hueniverse/5b75f644ff7b24db0ca4
20:07:48  <trevnorris>it's sad, but it's there: https://github.com/joyent/node/wiki/API-changes-between-v0.10-and-v0.12
20:08:43  <trevnorris>hueniverse: is that on master or v0.10?
20:09:04  <hueniverse>v0.11.6
20:09:10  <hueniverse>what do you want me to play with?
20:09:14  <hueniverse>master?
20:09:33  * kevinswiberquit (Remote host closed the connection)
20:09:50  <trevnorris>i dunno. i'm rewriting domains anyways, so who knows if it'll be broken in the near future :P
20:10:31  <Domenic_>that page reminded me how much i can't wait for a working process.nextTick... having to roll our own queue was painful and felt so unnecesary.
20:10:32  <hueniverse>what do you want me to do with these domain fails?
20:10:53  * defunctzombie_zzchanged nick to defunctzombie
20:11:06  <trevnorris>hueniverse: gist a script that causes that, if you can. i'll take a look.
20:16:13  <othiym23>it will be super nice to have a mechanism in place that abstracts the async propagation from the error-handling-y bits
20:16:33  <trevnorris>i'm working on it, i'm working on it ;)
20:16:43  <othiym23>I'm pretty excited for the new implementation of domains, even though I'm gonna have to redo all my error-tracing code yet again
20:17:15  <hueniverse>othiym23: what? you have better things to do?
20:17:49  * kazuponjoined
20:18:07  <othiym23>mmmmmaybe
20:22:10  <trevnorris>bnoordhuis: ping
20:22:37  * kazuponquit (Ping timeout: 268 seconds)
20:25:26  * st_lukejoined
20:28:48  <bnoordhuis>trevnorris: pong
20:29:29  <trevnorris>bnoordhuis: w/ the context changes, i'm assuming that also means not using static variables within a method?
20:29:47  <bnoordhuis>trevnorris: correct
20:29:51  <trevnorris>coolio. thanks.
20:30:25  <trevnorris>bnoordhuis: I just realized that the intick can be completely moved to C++, so i'm just switching it to a private bool in TickInfo
20:30:52  * kellabytejoined
20:32:07  <bnoordhuis>okay
20:33:42  * bradleymeckquit (Quit: bradleymeck)
20:35:43  <trevnorris>bnoordhuis: and from how it looks, you basically baked in isolate support. instead of using node_isolate just need to use env->isolate(), right?
20:36:55  * piscisaureus_joined
20:42:38  * jmar777quit (Remote host closed the connection)
20:45:01  <MI6>nodejs-master-windows: #295 UNSTABLE windows-x64 (19/641) windows-ia32 (23/641) http://jenkins.nodejs.org/job/nodejs-master-windows/295/
20:45:24  * dshaw_quit (Quit: Leaving.)
20:45:52  <bnoordhuis>trevnorris: correct :)
20:46:13  <bnoordhuis>i'm discussing with myself if i'll remove node_isolate altogether
20:46:47  <bnoordhuis>it's quite possible now, only we have almost 1,000 use sites in src/
20:47:54  <trevnorris>bnoordhuis: hah, only that huh? that's intense.
20:49:30  * indexzerojoined
20:58:56  * dshaw_joined
21:10:18  * txdvquit (Ping timeout: 264 seconds)
21:11:49  * inolenquit (Read error: No route to host)
21:11:58  * inolenjoined
21:13:06  * jmar777joined
21:18:23  * kazuponjoined
21:18:40  * jmar777quit (Remote host closed the connection)
21:20:11  <trevnorris>isaacs: ping
21:23:03  * kazuponquit (Ping timeout: 268 seconds)
21:28:43  <trevnorris>othiym23: or you, ping
21:30:31  * jmar777joined
21:32:08  * ecrquit (Quit: ecr)
21:32:35  * ecrjoined
21:32:43  <isaacs>trevnorris: pong
21:33:29  <trevnorris>isaacs: what about: process.asyncListener.{get,set,has,clear}() ?
21:33:56  <trevnorris>isaacs: didn't want to pollute process w/ a bunch of long method names, and needed these internally anyways.
21:34:39  <isaacs>trevnorris: yeah, that's probably fine.
21:34:51  <isaacs>it's kind of a weird api, though, still
21:35:26  <isaacs>trevnorris: i was talking with othiym23 the other day about this, actually. we really need a way to be able to have more than one, without having them impact one anotehr too badly.
21:35:27  <trevnorris>yeah, think the same thing. though right now i'm more concerned about the mechanics. I really don't care if the api changes
21:35:34  <isaacs>trevnorris: sure, of course
21:36:07  <isaacs>trevnorris: but like, if i use module-a that does some asyncListener stuf, and then module-b that also does, and also i'm using domains, it should all be at least *possible* to do transparently, without wrapping and monkeypatching all to hell.
21:36:21  <MI6>joyent/node: Bert Belder master * de7d698 : pipe_wrap: squelch integer type conversion warning - http://git.io/-N3oAA
21:36:43  <isaacs>trevnorris: of course, you CAN do: var cur = asyncListener.get(); asyncListener.add(function() { curr(); myStuff() })
21:36:43  <MI6>joyent/node: Bert Belder execSync-wip * 08356fe : execSync spawnSync WIP - http://git.io/Mnkm7Q
21:37:08  <trevnorris>isaacs: yeah. those are things i'm still working on. right now i'm just getting the simple case to work, but coding with running multiple in mind.
21:37:17  <isaacs>ewl
21:37:21  <isaacs>kewl
21:37:47  <MI6>joyent/node: Bert Belder execSync-wip * 8ffa9e4 : spawn_sync: implement bindings - http://git.io/2Z9BJg
21:38:02  <trevnorris>it's the mechanics that are giving me hell. there are several ways to do it, and each have their ups/downs
21:39:35  <trevnorris>isaacs: so my initial implementation was that you pass the callback to the async listener, where you can wrap the callback and do whatever you want with it.
21:39:44  <piscisaureus_>damm!
21:39:48  <piscisaureus_>forgot to remove the printfs
21:39:58  <trevnorris>quick, force push!
21:40:43  <MI6>joyent/node: Bert Belder execSync-wip * 1826bf4 : spawn_sync: implement bindings - http://git.io/bN3ZVA
21:40:48  <piscisaureus_>trevnorris: there ya go
21:40:48  <trevnorris>isaacs: but with multiple listeners that means the wrapped callback could also be wrapped by another listener.
21:40:55  <trevnorris>piscisaureus_: :))
21:41:04  <isaacs>trevnorris: exactly
21:41:15  <isaacs>trevnorris: so you have to add another closure for each additional listener
21:41:16  <trevnorris>isaacs: exactly as in, that's what should happen?
21:41:26  <isaacs>trevnorris: no, exactly as in "that's why this approach sucks"
21:41:53  <isaacs>monkey-patching before and after functional stuf is great in lisp, but in JS its kinda awful, because that's not as optimized.
21:42:00  <isaacs>js is not FP
21:43:13  <trevnorris>well, then this also bothers the idea of each async listener having its own context.
21:44:02  <trevnorris>right now the domain api does some crazy shit to maintain the "active" context stack.
21:44:17  <trevnorris>but if we have multiple listeners, then each may want to track their own context.
21:45:36  <trevnorris>isaacs: basically, the only way I can think of dealing with all the _possible_ cases users will want this for is to allow the callback to be wrapped.
21:45:43  <MI6>nodejs-master: #503 UNSTABLE linux-ia32 (2/641) smartos-x64 (6/641) osx-x64 (1/641) linux-x64 (3/641) http://jenkins.nodejs.org/job/nodejs-master/503/
21:45:49  * jmar777quit (Remote host closed the connection)
21:46:07  <MI6>joyent/node: Bert Belder execSync-wip * 65d0a25 : spawn_sync: implement bindings - http://git.io/IkKdgg
21:46:09  <trevnorris>oy, this is so freakin abstract.
21:46:12  <isaacs>trevnorris: yeah
21:46:19  <isaacs>trevnorris: so, yes, wrapping the callback is always an option
21:46:26  <isaacs>trevnorris: but the simplest way to handle this is like how EE does it
21:46:41  <isaacs>trevnorris: if you add a listener, and there's already a listener, then we make it an array, and call them in order.
21:46:55  <trevnorris>isaacs: but when does the callback itself get called?
21:47:14  <trevnorris>isaacs: because domain has entry/exit maintanence, so we coudln't just call it once.
21:47:23  <isaacs>trevnorris: aL.add(fn1); aL.add(fn2); setTimeout(fn3)
21:47:32  <isaacs>trevnorris: fn1 and fn2 are not nested domains
21:47:39  <isaacs>trevnorris: they're completely different sorts of things
21:47:49  <isaacs>that presumably dont' know about or interact with one another
21:48:03  <isaacs>ie, fn1 could be the domain async listener, and fn2 could be othiym23's crazy new relic stuff
21:48:10  * bradleymeckjoined
21:48:22  <trevnorris>the actual callback (e.g. oncomplete) can only be run once. where does that run?
21:48:31  <trevnorris>or when
21:48:35  <trevnorris>is a better way to ask
21:49:03  <isaacs>when does it get run now?
21:49:11  <piscisaureus_>ok, this is what I test the execSync-wip branch with: https://gist.github.com/piscisaureus/6371772
21:49:23  <isaacs>basically, right now, you have: asyncListener.add(fn1); setTimeout(fn2)
21:49:24  <piscisaureus_>in case someone wants to try it out.
21:49:33  <piscisaureus_>I'm off to bed now
21:49:40  <isaacs>piscisaureus_: g'nite, i'll take a look at this later
21:49:40  <trevnorris>piscisaureus_: night
21:49:42  <tjfontaine>piscisaureus_: you should test with a build script for node :P
21:49:58  <trevnorris>isaacs: ok, just want to make sure we're on the same page here. an async listener is a callback that will be called when an async event is queued.
21:50:10  <isaacs>righ
21:50:24  <isaacs>trevnorris: so, in this case, fn1 would be called riht away, because fn2 is being queued.
21:50:37  <isaacs>trevnorris: in this case: aL.add(fn1); aL.add(fn2); setTimeout(fn3)
21:50:43  <isaacs>it goes: fn1(); fn2()
21:50:46  * indexzeroquit (Quit: indexzero)
21:50:59  <trevnorris>yeah, that makes sense, but what do we pass to those?
21:51:17  <isaacs>the same args
21:51:43  <isaacs>as if it's like process.emit('asyncThingQueued')
21:51:43  <trevnorris>same args as what?
21:51:50  <isaacs>what are you passing to them now?
21:51:53  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:52:49  <trevnorris>have a few variants that do the same thing, one was it passes an object with {callback: callback, domain: null }
21:52:58  <trevnorris>and you can wrap callback, and set domain
21:53:15  <trevnorris>then that domain will be set as process.domain when the callback is called.
21:54:22  <trevnorris>wrapping had one huge advantage. it made the entire mechanism transparent to core, which meant zero performance hit.
21:54:39  * c4miloquit (Remote host closed the connection)
21:54:59  <trevnorris>isaacs: another issue, if we allow multiple contexts, which one is passed the error? or do we tell all the contexts there was an error?
21:55:37  <trevnorris>isaacs: but in that case, which context tells us the error was properly handled?
21:55:37  * c4milojoined
21:55:44  <isaacs>trevnorris: i guess we'd need some way for a context to --- yeah what you just said
21:55:56  <isaacs>maybe the function return value could be relevant?
21:56:16  <trevnorris>that's an option. but do we listen to fn1 or fn2?
21:58:35  <trevnorris>isaacs: sorry, not trying to be difficult with this. my brain has just been melting figuring a way around all these cases.
21:59:01  <isaacs>trevnorris: i'd say, in a case like that, we call the first one, and if it's not handled , call the next, and so on down the line.
21:59:18  <isaacs>trevnorris: stop at the first one that does return true; or something?
21:59:46  <isaacs>trevnorris: it doesn't have to be the nicest API ever. most people will just use Domains for error handling, and contexts for continuation local storge.
21:59:50  <isaacs>probably using othiym23's module.
22:00:07  <isaacs>but you could also imagine some kind of logging/etc
22:00:18  <isaacs>and it might be a nice place to shove a DTrace probe
22:00:21  <MI6>joyent/node: Bert Belder execSync-wip * f18d2af : spawn_sync: implement bindings - http://git.io/h6fPNA
22:00:34  <isaacs>guess piscisaureus didn't go to bed ;)
22:00:48  <tjfontaine>I don't know how many different things with Context in the subject can we land in one cycle :)
22:01:04  <trevnorris>yeah, that's one reason why I've separated the async listener idea from the domain idea. there may be times when I want to know when an async listener is queued, but no need to track a domain.
22:01:52  <trevnorris>othiym23: where are you!?
22:02:08  <MI6>joyent/node: Bert Belder execSync-wip * 0e7c3f3 : spawn_sync: implement bindings - http://git.io/bwR12w
22:02:55  <trevnorris>isaacs: imho, every context should be alerted that there was an error, but if even one of those says the error was handled then we accept the error was handled.
22:03:05  <isaacs>i guess, yeah
22:03:09  <isaacs>that makes sense
22:03:10  * isaacson a call
22:03:12  * isaacs&
22:03:31  <tjfontaine>heh
22:03:32  <isaacs>back in 30 minutes or so
22:03:37  <trevnorris>coolio
22:03:41  <tjfontaine>LOUDBOT: you're awesome.
22:04:01  <trevnorris>LOUDBOT: HELP ME!!!
22:04:42  <othiym23>sorry d000ds
22:04:43  <tjfontaine>I don't even want to know what the next sentence was
22:04:48  <othiym23>I, like, have a job
22:05:00  <tjfontaine>othiym23: what is this job thing
22:05:24  <othiym23>trevnorris, isaacs: I've spent a lot of time thinking about ways to do this without closures, and I've, as the oldsters say, come a-cropper
22:05:50  <trevnorris>othiym23: guess I'm not old enough :)
22:06:13  <othiym23>I was thinking about this last night, and one thing you *could* do is pass a state object along with the callback as you're evaluating the async listener so different listeners have a clean way to communicate state to each other, but I couldn't come up with a compelling use case fo rit
22:06:52  <othiym23>i.e. I couldn't see how that would obviate the need for me to wrap functions in callbacks
22:07:05  <othiym23>for continuation-local storage, I need to do the exact same thing as domains
22:07:23  <trevnorris>othiym23: let me start from zero, and we'll work though this.
22:07:34  <othiym23>which is enter and exit scopes|contexts|whatever with the callback execution in the middle
22:07:37  <othiym23>sounds good
22:07:48  <othiym23>tjfontaine: it's a way of converting life into money
22:08:04  <trevnorris>othiym23: first are async listeners. basically you tell node you want this listener to be called whenever an async event is being queued up.
22:08:22  <othiym23>yes
22:08:47  * c4miloquit (Remote host closed the connection)
22:09:02  <othiym23>(as a side note, I always figured I'd have to spend a bunch of time with trevnorris working on this thing, I just didn't expect it to take the form of him doing all the actual work ;)
22:09:36  <trevnorris>heh, and I wouldn't have except it concerns core performance ;)
22:09:38  <tjfontaine>othiym23: what is this life of which you speak?
22:10:25  <tjfontaine>also: what is love, baby don't hurt me
22:10:39  <othiym23>tjfontaine: the thing that isn't computers
22:11:01  <trevnorris>othiym23: the use case for that is to wrap the callback, but that's impossible in some cases (e.g. a user can change the oncomplete callback during the I/O, so the callback would change)
22:11:30  <trevnorris>othiym23: so the other option is you set an async listener, and it'll be called when the callback is about to be called.
22:12:12  <othiym23>trevnorris: let me restate that use case in the specific context of continuation-local storage, which is that I need a certain set of state to be available when whatever gets executed asynchronously is actually invoked
22:12:24  * julian_duquejoined
22:12:37  <othiym23>I don't necessarily care that it's the same callback, as long as I have a guarantee that whatever values I've set earlier are available later
22:13:00  * AvianFluquit (Ping timeout: 268 seconds)
22:13:07  <trevnorris>othiym23: that's easy. but how do you get that state?
22:13:47  <othiym23>I'm actually dealing with one of those edge cases right now, which is the incredibly hinky stuff that readables do is messing with EEs after initialization
22:14:29  <othiym23>trevnorris: mechanically, CLS works by entering a context (PLEASE give me a better name), which is then exposed as the active set of state on that namespace, and then you just call namespace.get from user code
22:14:35  * julianduquequit (Ping timeout: 245 seconds)
22:14:40  <othiym23>so like domains, it's not specifically bound to closures
22:15:20  * julian_duquechanged nick to julianduque
22:16:01  <trevnorris>back this up a bit. first, ok let's change the name.
22:16:32  <trevnorris>i've been calling it a domain (not the domain module) but simply a domain that wraps the current state of node.
22:16:37  * bradleymeckquit (Quit: bradleymeck)
22:17:02  <othiym23>I think that's probably how domains got their name in the first place
22:17:03  <trevnorris>but we could call it a frame, or a group, or a whore, I don't care
22:17:11  <othiym23>whoah there
22:17:16  <othiym23>OK
22:17:33  <trevnorris>i figured domain, for backwards compatibility with process.domain
22:17:45  <trevnorris>since the idea of process.domain lives outside of the domain module
22:17:57  <trevnorris>(e.g. you can manually set a process.domain and node will do stuff with it)
22:18:51  <trevnorris>othiym23: ok, so how do you want to enter/expose your domain?
22:19:01  * kazuponjoined
22:19:48  <trevnorris>othiym23: what I was going to do was call async listener when async I/O was initialized, where you can return a domain object that'll persist with the call
22:20:26  <trevnorris>othiym23: then I guess there would be an async executor that would be called right when the async callback is about to be called
22:20:36  <othiym23>maybe that object is just a closure that gets invoked and sets / clears the state
22:20:44  <trevnorris>othiym23: and the context you intially returned from the async listener would be passed as an argument
22:21:00  <othiym23>or yeah, we could have an event that gets fired before the async callback is called that can take that object and do whatever with it
22:21:04  <othiym23>that seems like it'd be slow, though
22:21:58  <trevnorris>no slower than domains are already, actually a little faster maybe (i'm doing some strange shit with state sharing)
22:22:06  <othiym23>trevnorris: the outline you suggest would definitely work for CLS
22:23:02  <trevnorris>othiym23: ok, we're _not_ going to do a process.on('async',...) thing because going through the event emitter will be super painful.
22:23:06  * mikealquit (Quit: Leaving.)
22:23:21  * kazuponquit (Ping timeout: 245 seconds)
22:23:35  <trevnorris>othiym23: but this means we'd need to set two different callback (one that fires when I/O is queued, and the other when I/O is complete)
22:23:47  <othiym23>yeah, I don't care if it's an EE or whatever
22:23:50  * mikealjoined
22:25:46  <trevnorris>hah! I think I figured out a way to do this with one callback. the api is going to be ridiculous, but eh.
22:27:53  <othiym23>trevnorris: https://gist.github.com/othiym23/6372181
22:28:22  <MI6>nodejs-master-windows: #296 UNSTABLE windows-x64 (19/641) windows-ia32 (20/641) http://jenkins.nodejs.org/job/nodejs-master-windows/296/
22:29:52  <MI6>node-review: #72 FAILURE http://jenkins.nodejs.org/job/node-review/72/
22:30:00  <tjfontaine>ignore-able
22:30:15  <trevnorris>othiym23: sec, have another one for you
22:30:57  <trevnorris>othiym23: though, did you catch our conversation about error handling?
22:33:53  <othiym23>some of it?
22:34:02  <othiym23>which bits do you want me to pay the closest attention to?
22:36:01  * defunctzombiechanged nick to defunctzombie_zz
22:36:05  <trevnorris>eh, have something else. so, say before(domain) is called just before the callback. if I can track the domain per async listener that technically means we never need to set process.domain, right?
22:36:37  <trevnorris>(oh and i'm brain streaming right now, so not everything may make sense)
22:40:10  <trevnorris>ok. almost have something usable. sec and i'll post it
22:40:47  * wolfeidaujoined
22:40:52  <othiym23>as I see it, process.domain is there for extensibility purposes, not the core operation of the system
22:53:19  <trevnorris>othiym23: how about this: https://gist.github.com/trevnorris/6372405
22:53:21  <trevnorris>isaacs: ^
22:53:30  <trevnorris>and whoever else wants to give some feedback
22:53:37  <trevnorris>*whomever(?)
22:54:33  <trevnorris>added a comment, refresh
22:57:29  <othiym23>reviewing...
22:59:11  <othiym23>creationix: how does this look to you? ^^
22:59:38  <isaacs>trevnorris: that is a very comprehensive api
23:00:02  * inolenquit (Read error: Connection reset by peer)
23:00:12  <Domenic_>trevnorris: alternate removal APIs for your consideration: `var removalToken = addAsyncListener(...); removeAsyncListener(removalToken)` and `var remover = addAsyncListener(...); remover();`.
23:00:19  <isaacs>trevnorris: s/setAsyncListener/addAsyncListener/ since there can be more than one
23:00:33  * inolenjoined
23:00:36  <isaacs>Domenic_: using the listener as the token is node-like
23:00:38  <trevnorris>isaacs: whoops. typo. that's what it should have been.
23:00:41  <isaacs>kewl
23:01:03  <othiym23>trevnorris: so the only issue there is that it still ends up creating closures
23:01:14  <isaacs>trevnorris: so, when you do setTimeout(fn, 100), myAsyncListener() gets called with what arguments?
23:01:58  <trevnorris>isaacs: erm. none. I can't guarantee the callback all the time (e.g. ReqWrap) or I would pass that.
23:01:59  <isaacs>trevnorris: then, 100ms later, it calls beforeAsync(domain);fn();afterAsync(domain), right?
23:02:12  <isaacs>trevnorris: ok. and the returned object becomes process.domain?
23:03:09  <othiym23>dumb question: what is domain?
23:03:21  * dominictarrquit (Quit: dominictarr)
23:03:31  <trevnorris>isaacs: yes to the first, and it'll call all before's/after's in the order they were queued
23:03:33  <isaacs>othiym23: presumably whatever process.domain was at the time myAsyncListener was called
23:03:35  <trevnorris>FIFO style
23:03:48  <isaacs>trevnorris: before1();before2();fn();after1();after2()
23:03:56  <isaacs>right?
23:03:59  <trevnorris>yeah
23:04:20  <trevnorris>but setting process.domain is useless since we can have several listeners each with their own passed domain.
23:04:42  <othiym23>I would prefer before1();before2();fn();after2();after1()
23:04:43  <trevnorris>e.g. each listener has an attached domain object that only it knows about, that will be passed as the argument
23:05:00  <trevnorris>how about I use Math.random() to decide :P
23:05:05  <trevnorris>i don't care either way
23:05:11  <othiym23>trevnorris: so what initially populates that domain object?
23:05:49  <trevnorris>othiym23: ah, that was supposed to be one of the return items in myAsyncListener, let me update that
23:06:21  <othiym23>i.e. I need to capture some state at the time myAsyncListener is called, and then have access to that state later
23:06:39  <trevnorris>othiym23: refresh the gist
23:06:44  <othiym23>with the proposed API, my only way to do that is by making beforeAsync and afterAsync into closures
23:07:01  <othiym23>ah gotcha, much better
23:07:03  * st_lukequit (Remote host closed the connection)
23:07:35  <trevnorris>still have the problem that I'm not sure what process.domain should be. since we can have multiple domains with multiple listeners.
23:07:36  <isaacs>othiym23: the reason it's not b1,b2,fn,a2,a1 is that they're not nesting shells. 1 and 2 shouldn't even know about one another.
23:07:40  * julianduquequit (Ping timeout: 264 seconds)
23:07:52  <isaacs>othiym23: consider that 1 is your cls thing, and 2 is my logging thing, and 3 is the built-in domains
23:08:04  <isaacs>othiym23: if they care about their order, we're Doing It Wrong
23:08:10  <othiym23>isaacs: I might yet need to have some crosstalk between domains and CLS
23:08:55  <othiym23>sucks, but making CLS behave sensibly even when people are doing moronic things with their exception-handling is less than a requirement but more than a nice to have for New Relic
23:09:12  <trevnorris>othiym23: well, I could make it so process.domain is the last domain to be set. so if you setup a domain, then you can access it via process.domain to get some of your state information. but that seems arbitrary.
23:09:32  <isaacs>othiym23: trevnorris: Oh, I'd assume d tht the "domain" arg WAS the thing returned from myAsyncListener
23:10:07  <othiym23>trevnorris: process.domain should remain specific to require('domain') and keep the same API, I think
23:10:22  <trevnorris>othiym23: that's much easier. we'll do that.
23:10:24  <othiym23>so you can just do if (process.domain) process.domain.emit('error', error)
23:11:17  <trevnorris>isaacs: no need to pass values around unnecessarily I suppose. setting a domain object will make it simpler that way.
23:11:30  <trevnorris>othiym23: ok. i'm cool with that.
23:11:51  * spionjoined
23:12:06  <isaacs>trevnorris: yeah, that's true
23:12:14  * mcculloughseanjoined
23:12:15  * tjholowaychukjoined
23:12:19  <isaacs>tjholowaychuk: welcome
23:12:24  <tjholowaychuk>hey
23:12:27  <trevnorris>so is this api looking complete enough for everyone's needs?
23:12:30  <othiym23>Jesus Christ I'm working in Thunderdome right now
23:12:31  * isaacssummoned him from the twitter
23:12:34  <tjholowaychuk>hahaha
23:12:42  * julianduquejoined
23:12:44  <othiym23>our building is shaking thanks to the 8-foot trench they're cutting in the street outside
23:12:50  <isaacs>tjholowaychuk: https://gist.github.com/trevnorris/6372405 is what trevnorris is working on
23:13:08  <isaacs>tjholowaychuk: othiym23 is building a continuation-local-storage thingie for New Relic, which will use this api hook
23:13:22  <othiym23>tjholowaychuk: and this is the API I'm trying to use Trevor's thing to provide: https://github.com/othiym23/node-continuation-local-storage
23:13:26  <isaacs>tjholowaychuk: then the existing require('domain') can concievably be implemented in userland (but will still remain for bw compatibility)
23:13:39  <tjholowaychuk>right right
23:13:52  <isaacs>the reason that othiym23 can't use domains is that if he did, then using the new relic agent will cause your error handling to be changed.
23:13:57  <isaacs>and maybe you want to just throw and crash
23:13:57  <tjholowaychuk>i need to re-read the domain docs I forget what kind of isolation you can get
23:14:12  <tjholowaychuk>could I say wrap just that one stream (and parents) with a domain?
23:14:29  <isaacs>tjholowaychuk: if you do d.run(function() { create streams and then pipe everybody })
23:14:37  <isaacs>tjholowaychuk: then throws from there will go to the domain
23:14:47  * st_lukejoined
23:14:48  <tjholowaychuk>what about if they were created before-hand but not piped
23:14:50  <othiym23>or just do d.add(stream) to bind a pre-existing stream to a domain
23:15:01  <tjholowaychuk>I basically just want to pass the final stream and deal with error-handling elsewhere
23:15:05  <isaacs>tjholowaychuk: however, if they do stream.emit('blerg', userFunction) then now userFunction is *also* in the domain
23:15:18  <tjholowaychuk>othiym23 ah!
23:15:21  <tjholowaychuk>sounds like that might work then
23:15:25  <tjholowaychuk>oh wait no
23:15:30  <tjholowaychuk>I wont have the references
23:15:35  * st_lukequit (Remote host closed the connection)
23:15:38  <isaacs>tjholowaychuk: you could just do something like this:
23:16:01  <isaacs>function pipeAndPassError(a,b) { a.on('error', b.emit.bind(b, 'error')); a.pipe(b) }
23:16:29  <isaacs>tjholowaychuk: then the last one gets all the errors. of course, if you have an echo server, then you get RangeErrors
23:16:40  <isaacs>special for today! every error is a range error!
23:16:45  <tjholowaychuk>hahahaha
23:17:08  <isaacs>that's why we don't do that by default.
23:17:16  <isaacs>even though it makes pipe chains more verbose.
23:17:24  <tjholowaychuk>yeah I figured there was a reasonable reason
23:17:42  <isaacs>bbiab
23:17:43  * isaacs&
23:18:01  * st_lukejoined
23:18:25  <MI6>node-review: #73 FAILURE windows-x64 (18/641) windows-ia32 (16/641) http://jenkins.nodejs.org/job/node-review/73/
23:19:23  <trevnorris>othiym23: so this api cool w/ you?
23:19:32  * kazuponjoined
23:19:40  <tjfontaine>heh, you can tell what platform bert builds on
23:19:58  * mikealquit (Quit: Leaving.)
23:19:59  <trevnorris>hah
23:20:03  <trevnorris>that's awesome
23:20:47  * mikealjoined
23:24:45  * AvianFlu_joined
23:25:03  <othiym23>trevnorris: yeah, I think so, it feels nice and clean
23:25:25  <trevnorris>coolio.
23:25:41  <othiym23>tervnorris: I've tasked creationix with getting CLS-glue up and running on yr API as soon as you have a semi-stable version of it pushed, so he'll ultimately have concrete feedback for you
23:26:23  <trevnorris>othiym23: heh, ok. i'll try to have something by the end of the week. just remember this also sits on top of bnoordhuis's multi-context branch.
23:26:37  <othiym23>I am keenly aware of that fact, yes
23:27:09  <othiym23>there are now 3 branches on my critical path for this functionality
23:27:12  <othiym23>no pressure or anything
23:27:14  <trevnorris>hah
23:27:38  <trevnorris>well, it's all on the v0.12 roadmap, and I think isaacs is itching to get that out the door.
23:28:14  <othiym23>I will be *very* pleased if we can get addAsyncListener into 0.12
23:28:14  <trevnorris>othiym23: i've updated 6011 with the gist information. going to start implementing it now.
23:28:22  <othiym23>cool
23:28:27  <othiym23>thanks!
23:28:29  <trevnorris>np
23:28:44  * blissdevjoined
23:28:54  <trevnorris>and it will be. this is definitely something we'll want a full stable release of testing with first, before the v1.0 release.
23:29:37  <othiym23>you are far more confident about it making 0.12 than isaacs is ;)
23:30:03  * st_lukequit (Remote host closed the connection)
23:30:44  <trevnorris>heh, well. i've pulled off some serious refactors before. though this is going to be the most difficult.
23:31:02  * kazuponquit (Ping timeout: 256 seconds)
23:31:12  <trevnorris>been working on prototyping this for the last 2 weeks, so have a good idea of how to implement it.
23:31:14  * st_lukejoined
23:31:51  <othiym23>trevnorris: this will work for net.Socket and the crypto functions and everything, no?
23:32:05  <othiym23>that's where a lot of the wiggliness in the current version of cls-glue comes in
23:32:31  <trevnorris>it should cover anything that requires calling a callback in the future.
23:32:54  <othiym23>cool
23:33:43  * mcculloughseanquit (Quit: leaving)
23:43:06  * indexzerojoined
23:54:09  * indexzeroquit (Quit: indexzero)
23:56:57  <trevnorris>alright, need to go lock myself in a room to get this done.
23:56:59  * trevnorris&