00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  <MI6>libuv-master-gyp: #191 FAILURE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (4/195) linux-x64 (1/194) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/191/
00:00:09  * ircretaryjoined
00:00:25  * dshaw_quit (Ping timeout: 245 seconds)
00:23:58  * Raltquit (*.net *.split)
00:23:59  * creationixquit (*.net *.split)
00:23:59  * Damn3dquit (*.net *.split)
00:23:59  * chobie4quit (*.net *.split)
00:33:18  * Damn3djoined
00:35:08  * hzquit
00:46:24  * AvianFluquit (Read error: Connection reset by peer)
00:47:02  * AvianFlujoined
00:55:36  * dshaw_joined
01:05:16  * dshaw_quit (Ping timeout: 264 seconds)
01:50:54  * amartensjoined
01:55:27  * amartensquit (Ping timeout: 260 seconds)
01:55:49  * bradleymeckjoined
02:01:15  * dshaw_joined
02:06:14  * dshaw_quit (Ping timeout: 264 seconds)
02:16:30  * AvianFluquit (Read error: Connection reset by peer)
02:17:12  * AvianFlujoined
02:17:28  * Raltjoined
02:17:28  * creationixjoined
02:23:16  <othiym23>this has been my most Node-free weekend in months, and it feels both good and like I need to get my ass back in gear
02:23:23  <othiym23>so I guess it's served its weekendy puprose
02:23:39  <tjfontaine>well rested?
02:24:00  <othiym23>almost!
02:24:17  <tjfontaine>:)
02:25:07  <othiym23>so I'm blathering on a Node ticket (#6254) about how evaluating modules inside vm contexts isn't gonna happen because it's slow and I was curious if I was talking a big load of BS
02:25:32  <tjfontaine>no that's still true, and probably especially more so in vm2 at the moment
02:25:52  <othiym23>(leaving aside, for the time being, that what the OP is asking for is not as hugely disruptive as it would actually be)
02:26:29  <tjfontaine>it's a slightly interesting idea
02:27:32  <othiym23>it is, and maybe I'd be more sympathetic to it if I weren't so entrenched in the node worldview, but a module closure's a not equalling global.a just doesn't feel like an actuall issue to me
02:27:47  <othiym23>nor does exposing __dirname__ et al via arguments
02:28:12  <othiym23>not to mention that every NOde module I write starts with 'use strict', so I never even see arguments.callee
02:28:42  <othiym23>if I can do all the crazy shit I do without it, I submit it's probably not necessary except for things you shouldn't be doing anyway, but I'm not the lord of npm
02:29:51  <othiym23>tjfontaine: how would mutual requre() work if the modules were weing evaluated inside contexts? would nothing change?
02:30:34  <othiym23>seems like the current implementation depends on each module having its own isolated (closure) scope, with global being a universal escape hatch
02:31:23  <tjfontaine>maybe I'm confused, are we talking about something like NODE_MODULE_CONTEXTS
02:31:25  <othiym23>so you'd have to evaluate each module in its own context, passing the shared global to each of them, which seems semantically different from how it works now
02:31:53  <othiym23>it's not really clear to me what the OP wants, except for the runtime to work more like the REPL
02:32:03  <tjfontaine>right, that's what it sounds like as well
02:33:10  <othiym23>and the node REPL doesn't really strike me as being much like, say, a scheme REPL, where you're more or less guaranteed to have the REPL and runtime behavior kept identical
02:33:38  <othiym23>node's REPL doesn't have subcontexts for dealing with errors, for instance
02:35:01  * TooTallNatejoined
02:35:07  * TooTallNatequit (Client Quit)
02:39:21  * chobie4joined
02:47:54  * jmar777quit (Remote host closed the connection)
02:51:19  * amartensjoined
02:55:39  * amartensquit (Ping timeout: 260 seconds)
03:01:56  * dshaw_joined
03:06:23  * dshaw_quit (Ping timeout: 260 seconds)
03:17:18  * AvianFluquit (Read error: Connection reset by peer)
03:17:59  * AvianFlujoined
03:34:42  * julianduquejoined
03:51:36  * amartensjoined
03:55:57  * amartensquit (Ping timeout: 256 seconds)
04:02:49  * dshaw_joined
04:06:45  * dshaw_1joined
04:07:36  * dshaw_quit (Ping timeout: 276 seconds)
04:19:42  * mikealquit (Quit: Leaving.)
04:25:48  * mikealjoined
04:32:49  * mikealquit (Quit: Leaving.)
04:45:01  * dominictarrjoined
04:51:54  * amartensjoined
04:56:23  * amartensquit (Ping timeout: 245 seconds)
04:58:38  * julianduquequit (Quit: leaving)
05:17:39  * AvianFluquit (Remote host closed the connection)
05:22:53  * AvianFlujoined
05:23:20  * bradleymeckquit (Quit: bradleymeck)
05:37:19  * AvianFluquit (Remote host closed the connection)
05:52:14  * amartensjoined
05:56:43  * amartensquit (Ping timeout: 260 seconds)
06:03:00  * bajtosjoined
06:22:59  * c4miloquit (Remote host closed the connection)
06:30:10  * dominictarrquit (Quit: dominictarr)
06:45:01  <MI6>nodejs-v0.10-windows: #222 UNSTABLE windows-ia32 (9/600) windows-x64 (8/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/222/
06:48:26  * hzjoined
06:50:22  * dshaw_1quit (Quit: Leaving.)
06:51:12  * dshaw_joined
06:52:34  * amartensjoined
06:56:02  * dshaw_quit (Ping timeout: 264 seconds)
06:56:41  * amartensquit (Ping timeout: 245 seconds)
07:16:38  * defunctzombiechanged nick to defunctzombie_zz
07:24:03  * dshaw_joined
07:25:19  * dshaw_quit (Read error: Connection reset by peer)
07:25:26  * dshaw_joined
07:52:56  * amartensjoined
07:57:02  * amartensquit (Ping timeout: 240 seconds)
07:59:57  * hueniversequit (Quit: Leaving.)
08:11:26  * dominictarrjoined
08:20:51  * dominictarrquit (Quit: dominictarr)
08:43:17  * dominictarrjoined
08:46:56  * bnoordhuisjoined
08:50:19  * tooxiejoined
08:50:59  * rendarjoined
08:53:15  * amartensjoined
08:57:44  * amartensquit (Ping timeout: 256 seconds)
09:18:55  <MI6>joyent/libuv: Bert Belder master * eba3cbb : Update readme - http://git.io/tVd9IA
09:21:28  * piscisaureus_joined
09:22:02  <piscisaureus_>bnoordhuis: you signed it off
09:22:12  <piscisaureus_>bnoordhuis: but I think this commit log is totally fine
09:23:05  <piscisaureus_>bnoordhuis: but feel free to make use of the 5 minute rule
09:23:33  <MI6>libuv-master-gyp: #192 FAILURE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (3/195) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/192/
09:31:38  <saghul>when is the 0.12 window closing? I wanted to try and get something for 0.12 but I'm not sure I'll have the time...
09:35:14  * dshaw_quit (Quit: Leaving.)
09:38:13  <MI6>joyent/libuv: Bert Belder master * 581e8c9 : doc: update readme - http://git.io/ZfB6BQ
09:38:17  <bnoordhuis>bam!
09:38:24  <bnoordhuis>saghul: what are you working on?
09:38:47  <saghul>I wanted to have uv_fsevent and uv_fspoll have the same API
09:38:53  <saghul>so uv_fsevent_start / stop
09:39:01  <bnoordhuis>ah, okay
09:39:20  <bnoordhuis>i was thinking of starting the unofficial code freeze this week, actually :)
09:39:39  <bnoordhuis>a lot depends on the releasability of node though. i'm not sure if we're there yet
09:39:47  <saghul>ok, I'll try to get it bay the end of the week then :-)
09:39:51  <saghul>*by
09:42:49  <MI6>libuv-master-gyp: #193 FAILURE windows-x64 (3/195) smartos-ia32 (2/194) windows-ia32 (3/195) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/193/
09:47:29  <bnoordhuis>ah, jenkins is broken again...
09:48:37  <piscisaureus_>bnoordhuis: uv_fs_truncate lgtm if it works
09:48:52  <piscisaureus_>bnoordhuis: +1 for doing the windows stuff. Did you actually test it?
09:49:18  <piscisaureus_>bnoordhuis: or are you using the "hope" strategy?
09:52:59  * bnoordhuisquit (Ping timeout: 248 seconds)
09:53:33  * amartensjoined
09:58:36  * amartensquit (Ping timeout: 276 seconds)
10:03:20  * Kakerajoined
10:06:01  * dshaw_joined
10:07:45  * dshaw_1joined
10:07:45  * dshaw_quit (Read error: Connection reset by peer)
10:11:14  * bajtosquit (Quit: bajtos)
10:12:32  * dshaw_1quit (Ping timeout: 256 seconds)
10:23:02  <indutny>ohai
10:23:04  <indutny>howdy?
10:37:50  * dshaw_joined
10:47:00  * dshaw_quit (Ping timeout: 252 seconds)
10:53:55  * amartensjoined
10:59:03  * amartensquit (Ping timeout: 276 seconds)
11:14:41  * `3Echanged nick to `3E|BRB
11:51:58  * julianduquejoined
11:54:14  * amartensjoined
11:58:31  * amartensquit (Ping timeout: 246 seconds)
12:01:18  * julianduquequit (Quit: leaving)
12:12:09  * felixgejoined
12:12:09  * felixgequit (Changing host)
12:12:09  * felixgejoined
12:28:46  * bnoordhuisjoined
12:28:58  <bnoordhuis>and back
12:32:19  <bnoordhuis>hrm, is github.com:443 down?
12:32:41  <bnoordhuis>oh, not just website apparently
12:37:21  <bnoordhuis>and back again
12:37:27  <MI6>joyent/node: Ben Noordhuis master * 75ea566 : src: fix v8 PRNG entropy seeding - http://git.io/ZPfCgQ
12:39:56  * `3E|BRBchanged nick to `3rdEden
12:41:31  * Kakeraquit (Ping timeout: 248 seconds)
12:47:07  <MI6>nodejs-master: #569 FAILURE smartos-ia32 (1/641) smartos-x64 (5/641) http://jenkins.nodejs.org/job/nodejs-master/569/
12:50:15  * Kakerajoined
12:54:33  * amartensjoined
12:59:02  * bnoordhuisquit (Ping timeout: 264 seconds)
12:59:20  * amartensquit (Read error: Operation timed out)
12:59:34  <MI6>nodejs-master-windows: #363 UNSTABLE windows-x64 (20/641) windows-ia32 (21/641) http://jenkins.nodejs.org/job/nodejs-master-windows/363/
13:21:15  * jmar777joined
13:27:30  * bajtosjoined
13:28:04  * piscisaureus_quit (Ping timeout: 264 seconds)
13:44:36  * dshaw_joined
13:45:09  * bnoordhuisjoined
13:47:24  <bajtos>bnoordhuis: is there a way how to run require('net') from a script injected via V8 debugger? (This means the script is not running inside a require() wrapper that exposes a local variable called require.)
13:47:51  <bajtos>I was thinking about `global.module.require`, but will is `global.module` always defined?
13:48:43  <bnoordhuis>bajtos: no. neither is global
13:48:45  * dshaw_quit (Ping timeout: 245 seconds)
13:49:04  <bajtos>bnoordhuis: Hmm, that's bad.
13:49:27  <bajtos>bnoordhuis: What's my goal: we want to instrument console.log, so that it sends a copy of all log messages to Node Inspector backend
13:49:54  <bnoordhuis>bajtos: it depends on where exactly you inject the script
13:49:59  <bajtos>bnoordhuis: To do that, we need to inject the instrumenting code to the running process using V8 debugger protocol
13:50:03  <bnoordhuis>as a wise man once said, context is everything
13:50:11  <bajtos>bnoordhuis: yes, of course
13:50:31  <bajtos>bnoordhuis: so the current approach is to inject an artificial breakpoint and inject the instrumenting code when the breakpoint is hit
13:50:41  * piscisaureus_joined
13:50:47  <bajtos>bnoordhuis: which seem like unnecessary complication to me.
13:51:16  <bnoordhuis>bajtos: what would you propose? the thing with 'global' is that it may be shadowed by a local variable with the same name
13:51:18  <bajtos>bnoordhuis: Is there a good reason why require() and/or Module() and/or NativeModule() is not exposed as a global variable?
13:51:57  <bnoordhuis>require is a function that's passed to a module, i.e. it's for all practical purposes a local var
13:52:01  <bajtos>bnoordhuis: well, if there is always one implementation of require() used in node, then shadowing is not a big problem, right?
13:52:25  <bajtos>bnoordhuis: even if it was, you can always workaround by calling explicitly `global.require`, right?
13:52:26  <bnoordhuis>no, what i mean is this -> (function() { var global = { foo: 42 }; ... })()
13:52:46  <bnoordhuis>if you inject your code inside that function, it'll pick up the wrong global
13:52:58  <bajtos>oh. bugger
13:54:36  <bajtos>well
13:54:53  * amartensjoined
13:55:03  <bajtos>if I execute the injected code in the global context (i.e. not in the scope of a particular call frame)
13:55:44  <bajtos>then the global variables (incl. global itself) cannot be shadowed, is that assumption correct?
13:56:52  <bnoordhuis>bajtos: yes, that's correct. someone could've monkey-patched or stamped on it, of course
13:57:17  <bajtos>bnoordhuis: yes, but that's an acceptable risk
13:58:14  <bajtos>bnoordhuis: so here is my proposal: expose require() on the global object (in addition to the local variable passed into required() scripts)
13:58:33  <bajtos>btw this seems what's happening now when you require a script
13:58:39  <bnoordhuis>bajtos: not necessary, it's already there. try this: node -p 'global.module.require("net")'
13:59:02  * amartensquit (Ping timeout: 240 seconds)
14:00:12  <bajtos>bnoordhuis: that's because the code behind '-p' is run from a module
14:00:40  <bajtos>see lib/module.js: ~407: sandbox.require = require
14:00:49  <bajtos>sandbox.module = self
14:01:01  <bajtos>and for the root module (few lines below)
14:01:06  <bajtos>global.module = self
14:01:09  <bnoordhuis>oh, you mean it's not defined when run as a script
14:01:28  <bajtos>yes, when I run an arbitrary script via V8 debugger API inside the node process
14:02:06  <bajtos>bnoordhuis: it's the request 'evaluate' to be more specific
14:02:53  <bnoordhuis>bajtos: don't tell anyone but you can force that with `NODE_MODULE_CONTEXTS=1 node script.js`
14:03:24  <bajtos>bnoordhuis: well, I don't want to tell people to use that thing when they want to debug using Node Inspector
14:03:36  <bnoordhuis>i'm not against exposing the module object per se but...
14:04:48  <bajtos>bnoordhuis: I didn't realise the code I pointed to was wrapped by NODE_MODULE_CONTEXTS, hmm.
14:06:52  <bajtos>bnoordhuis: well, if there isn't an acceptable way how to expose the module object then we will have to use the workaround where console.log triggers a breakpoint so that we can run the injection from inside a module context
14:07:56  <bnoordhuis>the thing with exposing the module object is: what module object exactly?
14:08:18  <bnoordhuis>btw, what's the downside of a console.log breakpoint? seems reasonably elegant to me
14:09:41  <bajtos>bnoordhuis: what to expose - require() is good enough for me. Alternative: expose the main module of the process, e.g. via 'global.process.main' or 'global.process.mainModule'?
14:10:21  <bajtos>bnoordhuis: downside of breakpoint is that you have to watch for this breakpoint in the node inspector, inject the source then, plus you want to remove the breakpoint so that it is not hit anymore
14:10:46  <bnoordhuis>and? i don't see an issue with that
14:11:06  <bnoordhuis>if that's all it takes, then there's no need to change node
14:11:26  <bajtos>bnoordhuis: and I don't know an exact location of the breakpoint, which makes things harder
14:11:41  <bajtos>bnoordhuis: oh
14:11:55  <bajtos>bnoordhuis: so we can actually inject the code when any breakpoint was triggered
14:12:29  <bnoordhuis>yes, exactly
14:12:35  <bajtos>bnoordhuis: btw here is the pull request that started my thinking about the problem: https://github.com/node-inspector/node-inspector/pull/219
14:13:15  <bajtos>bnoordhuis: and since the breakpoint is set via 'debugger;' statement, we can replace the 'debugger;' version of console.log with the version that reports logs to Node Inspector.
14:13:22  <bajtos>bnoordhuis: ok, I agree that's not a bad solution
14:13:33  <bajtos>bnoordhuis: thanks!
14:13:35  <bnoordhuis>nice :)
14:19:59  * c4milojoined
14:23:15  <bnoordhuis>piscisaureus_: hubertus, what are you working on?
14:32:24  * dshaw_joined
14:34:30  * c4miloquit (Remote host closed the connection)
14:35:36  <piscisaureus_>bnoordhuis: I'm cornering the harkonnen harvester
14:36:01  <piscisaureus_>bnoordhuis: you?
14:36:03  * dshaw_quit (Read error: Operation timed out)
14:36:20  * dominictarrquit (Quit: dominictarr)
14:36:45  <piscisaureus_>bnoordhuis: did you see my text about r+ open mode and uv_fs_truncate?
14:47:19  * AvianFlujoined
14:49:54  * bnoordhuisquit (Ping timeout: 264 seconds)
14:54:43  * kenperkinsjoined
14:55:11  * amartensjoined
14:57:00  * c4milojoined
14:59:18  * amartensquit (Ping timeout: 245 seconds)
14:59:47  * julianduquejoined
15:05:18  * bradleymeckjoined
15:18:22  <MI6>nodejs-master: #570 FAILURE smartos-ia32 (1/641) smartos-x64 (6/641) http://jenkins.nodejs.org/job/nodejs-master/570/
15:19:15  * tooxiequit (Ping timeout: 252 seconds)
15:20:02  * tooxiejoined
15:31:30  * dominictarrjoined
15:31:41  * piscisaureus_quit (Ping timeout: 245 seconds)
15:32:16  * bajtosquit (Quit: bajtos)
15:34:50  * `3rdEdenchanged nick to `3E|FOOD
15:37:29  * julianduquequit (Quit: leaving)
15:39:27  * piscisaureus_joined
15:47:59  * mikealjoined
15:56:21  * bnoordhuisjoined
15:57:14  * amartensjoined
16:00:11  * bajtosjoined
16:00:33  * bnoordhuisquit (Ping timeout: 245 seconds)
16:08:27  * mikealquit (Quit: Leaving.)
16:14:11  * bnoordhuisjoined
16:14:30  * bradleymeckquit (Quit: bradleymeck)
16:21:26  * groundwaterquit (Quit: groundwater)
16:21:40  <tjfontaine>looks like indutny's vm2 v8 fix landed upstream
16:22:26  <indutny>not really
16:22:34  <tjfontaine>oh?
16:22:35  <indutny>but I'm testing upstream fixes
16:22:40  <tjfontaine>k
16:22:42  <indutny>they've alternative fix https://chromiumcodereview.appspot.com/23533012
16:22:48  <indutny>which is better
16:23:23  * tooxiequit (Ping timeout: 248 seconds)
16:24:11  <indutny>yeah, it works
16:24:42  <tjfontaine>right, good
16:24:55  <tjfontaine>and the conversation looked like it got backported?
16:26:30  <indutny>https://github.com/joyent/node/pull/6257
16:26:36  <indutny>yep
16:26:41  <indutny>I updated to official upstream
16:26:44  <indutny>lets wait for tests
16:27:20  <tjfontaine>I just kicked off a bunch of builds because the osx slave kicked a drive over night, so it may take a bit to build that pr
16:28:04  * bnoordhuisquit (Ping timeout: 264 seconds)
16:28:25  * bradleymeckjoined
16:28:40  <indutny>tjfontaine: ah, I guess I can run osx tests myself
16:28:59  <indutny>tjfontaine: though, my chromium is broken right now
16:29:02  <tjfontaine>hehe
16:29:05  <tjfontaine>it will catch up
16:29:08  <indutny>tjfontaine: and I don't see any results
16:29:42  * dapjoined
16:29:45  <indutny>ok, its there http://jenkins.nodejs.org/job/node-pullrequest/1221/
16:33:55  * inolenquit (Quit: Leaving.)
16:34:38  * Benviejoined
16:41:18  <indutny>tjfontaine: seems to be hanging, no http://jenkins.nodejs.org/job/node-pullrequest/1221/
16:41:19  <indutny>?
16:43:17  <tjfontaine>looking into it, moment
16:45:53  <tjfontaine>Sep 23, 2013 9:45:36 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run
16:45:56  <tjfontaine>SEVERE: I/O error in channel channel
16:45:59  <tjfontaine>java.io.IOException: Unexpected termination of the channel
16:46:01  <tjfontaine>I hate this thing so much
16:46:04  <tjfontaine> at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
16:46:07  <tjfontaine>Caused by: java.io.EOFException
16:47:13  <tjfontaine>indutny: ok forward progress being made
16:49:18  <indutny>tjfontainethanks
16:50:37  * bradleymeckquit (Quit: bradleymeck)
16:52:11  <MI6>libuv-master-gyp: #194 FAILURE windows-x64 (4/195) smartos-ia32 (5/194) windows-ia32 (3/195) linux-ia32 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/194/
16:53:53  <MI6>libuv-master: #254 FAILURE windows (4/195) osx (1/195) http://jenkins.nodejs.org/job/libuv-master/254/
16:54:20  <tjfontaine>sigh
16:54:20  <MI6>nodejs-master: #571 UNSTABLE smartos-ia32 (3/641) osx-ia32 (2/641) linux-x64 (2/641) smartos-x64 (7/641) linux-ia32 (2/641) http://jenkins.nodejs.org/job/nodejs-master/571/
16:55:45  <MI6>joyent/node: Fedor Indutny master * 970bdcc : deps: update v8 to - http://git.io/4H8M-g
16:57:58  <MI6>nodejs-v0.10: #1496 UNSTABLE linux-ia32 (1/600) linux-x64 (1/600) smartos-ia32 (3/600) smartos-x64 (4/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1496/
16:58:29  <indutny>tjfontaine: thanks :)
16:59:17  <indutny>ok, inbox 8 now :)
16:59:22  <indutny>gosh
16:59:22  * chrisdickinsonquit (Quit: ZNC - http://znc.in)
17:00:24  * chrisdickinsonjoined
17:01:39  * AvianFluquit (Remote host closed the connection)
17:05:52  <MI6>nodejs-master: #572 UNSTABLE osx-x64 (2/641) smartos-ia32 (1/641) smartos-x64 (6/641) http://jenkins.nodejs.org/job/nodejs-master/572/
17:10:35  * TooTallNatejoined
17:12:26  * brsonjoined
17:13:12  * AvianFlujoined
17:21:38  * inolenjoined
17:22:09  * `3E|FOODchanged nick to `3rdEden
17:23:03  <piscisaureus_>bnoordhuis: when are you coming to 020? thursday?
17:26:01  * mikealjoined
17:27:09  * groundwaterjoined
17:28:14  <MI6>nodejs-master-windows: #364 UNSTABLE windows-x64 (22/641) windows-ia32 (24/641) http://jenkins.nodejs.org/job/nodejs-master-windows/364/
17:41:05  * sblomjoined
17:44:01  * TooTallNatequit (Quit: Computer has gone to sleep.)
17:45:35  <indutny>yay
17:45:37  <indutny>Inbox 7
17:48:45  * felixgequit (Quit: felixge)
17:51:53  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:52:49  <trevnorris>ah, missed bert
17:52:52  <trevnorris>morning all
17:53:52  <tjfontaine>gday
17:54:06  <tjfontaine>what is the status of asyncListener, are you just in need of review?
17:54:19  <MI6>libuv-master: #255 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/255/
17:54:39  * defunctzombie_zzchanged nick to defunctzombie
17:57:49  <trevnorris>tjfontaine: status is slightly complex. asyncListener is working well for HandleWrap and ReqWrap, but because of the heavy use of ObjectWrap in crypto and TLSWrap I've been yet unable to integrate it there.
17:58:05  <trevnorris>tjfontaine: also, i'm still working on seperating domains from core using asyncListener.
17:58:22  <trevnorris>though I guess that isn't completely necessary before the preliminary patch is accepted.
17:59:23  <tjfontaine>right, it would be helpful if we can start to getting it into an integration point, with a helpful and useful state that isn't necessarily entirely what we want
17:59:40  * jmar777quit (Remote host closed the connection)
18:00:14  <trevnorris>tjfontaine: ok. i'll create a integratable state that'll work, but will need additional patches to complete the functionality requirements. sound alright?
18:00:20  * bnoordhuisjoined
18:00:25  * creationixquit (Ping timeout: 246 seconds)
18:02:34  <tjfontaine>trevnorris: yup, sounds pretty reasonable, then tomorrow at the call we can sollicit some more feedback for you
18:02:42  <trevnorris>sounds good.
18:03:49  * bradleymeckjoined
18:03:50  <tjfontaine>for what you're doing this is working, moving forward you will just have more subsystems that appear in the asyncListener path?
18:04:19  * creationixjoined
18:04:49  <tjfontaine>trevnorris: are there any indications that the external api for this will need to change to accomodate the additions you still need to do?
18:05:33  * c4miloquit (Remote host closed the connection)
18:06:19  <trevnorris>tjfontaine: if there are any API differences they'll be additions. the API should be stable when this is merged.
18:06:50  <tjfontaine>nod
18:07:33  <MI6>libuv-node-integration: #237 UNSTABLE smartos-x64 (5/641) http://jenkins.nodejs.org/job/libuv-node-integration/237/
18:11:20  * TooTallNatejoined
18:17:53  * bajtosquit (Quit: bajtos)
18:19:43  <trevnorris>bnoordhuis: ping
18:20:16  <trevnorris>bnoordhuis: nm
18:21:31  <trevnorris>tjfontaine: the issue is the patch can't be merged until domains work on top of asynclisteners, because they have their own makecallback implementation that isn't directly domain compatible.
18:21:41  <trevnorris>*one issue
18:21:49  <tjfontaine>ok, and that can't happen until the other parts are done?
18:22:29  <trevnorris>no. they're separate issues. problem i'm having with domains is their support of the events module.
18:23:11  <trevnorris>eventemitter is sync, but this api was only meant to detect async "events"
18:23:53  <trevnorris>basically, domains cheated at listening for async events because of our internal architecture of inheriting EventEmitter on top of every *Wrap
18:24:34  <trevnorris>this api is going below that though, so it's being difficult to detect async errors that've been emitted synchronously.
18:25:09  <othiym23>sounds like whatever you come up with is going to require me to adapt the New Relic error tracer some
18:25:19  <othiym23>which is fine, it abuses implementation details as is
18:25:25  <trevnorris>heh
18:25:39  <othiym23>I'll just start the 0.11 / 0.12 upgrade on that this week, which I was planning on doing anyway
18:26:08  <indutny>Inbox 6 thanks to bnoordhuis
18:28:56  <bnoordhuis>indutny: np :)
18:45:08  <trevnorris>othiym23: there was one more tiny addition to the API
18:46:17  <othiym23>trevnorris: what's the change?
18:47:43  <trevnorris>othiym23: you can now pre-define the "domain" object with createAsyncListener, so nothing has to be returned from the callback listener.
18:48:08  <othiym23>ah, handy
18:48:14  <othiym23>is that another function?
18:48:25  <trevnorris>you mean createAsyncListener?
18:48:35  <othiym23>no, to return the object
18:48:50  <othiym23>or will it be cloned, or reused across requests, or...?
18:52:18  <trevnorris>if you don't return a domain then it'll just re-use the previous one if there was one.
18:55:25  <tjfontaine>are github emails being ridiculously out of sync for anyone else?
18:57:42  <trevnorris>man, what a strange error:
18:57:44  <trevnorris>TypeError: Converting circular structure to JSON
19:01:46  <tjfontaine>tsk tsk
19:03:29  <indutny>bnoordhuis: btw, what do you think about nested tls sockets
19:03:33  <indutny>i.e. tls in tls
19:03:38  <indutny>I'm going to start working on it soon
19:03:53  <indutny>and would be cool to hear your opinion about this "feature" ahead of it
19:04:27  <bnoordhuis>indutny: nested tls? to what purpose?
19:04:29  <indutny>basically, it would be based on changing Callbacks interface
19:04:43  <indutny>bnoordhuis: its used in wild life by real people /cc TooTallNate
19:04:57  <bnoordhuis>okay. but what for?
19:05:19  <TooTallNate>lol, we've had this convo already
19:05:30  <bnoordhuis>tunneling tls over tls?
19:05:49  <TooTallNate>bnoordhuis: use case is connecting to a proxy server over TLS, where the proxy server is proxying a TLS endpoint for the client
19:06:01  <indutny>bnoordhuis: yes
19:06:02  <TooTallNate>bnoordhuis: the proxy itself doesn't use TLS, since then it would see the clear-text of the client
19:06:06  <indutny>bnoordhuis: well, I'll do it
19:06:13  <indutny>bnoordhuis: I'm just asking if you're ok with it
19:06:16  <indutny>to not do it in vain
19:06:17  <indutny>:)
19:06:30  <TooTallNate>but instead, the client initiates TLS to the end server over the connected TLS socket to the proxy server
19:06:53  <TooTallNate>confusing I know :p but the big thing in my mind is that it's been working up til v0.11
19:07:06  <bnoordhuis>okay
19:07:14  <tjfontaine>so this is a regression in 0.11?
19:09:01  * sblomquit (Ping timeout: 246 seconds)
19:09:55  * jmar777joined
19:11:11  <indutny>tjfontaine: yes
19:13:52  <tjfontaine>ok, is there an issue already tracking it?
19:15:29  <TooTallNate>tjfontaine: https://mc.a8c.com/proxy-pac.php
19:15:31  <TooTallNate>whoops
19:15:37  <TooTallNate>tjfontaine: https://github.com/joyent/node/issues/6204
19:15:59  <tjfontaine>TooTallNate: ok thanks, some how I missed this one
19:28:52  <MI6>nodejs-master-windows: #365 UNSTABLE windows-x64 (23/641) windows-ia32 (26/641) http://jenkins.nodejs.org/job/nodejs-master-windows/365/
19:37:47  * EhevuTovjoined
19:38:33  <indutny>bnoordhuis: do you have a minute?
19:43:07  <trevnorris>well poop. it's going to be impossible to completely remove domains from core. the event emitter constructor needs to be aware of the active domain
19:43:15  <trevnorris>though, that's about it.
19:57:07  * hzquit
19:59:14  <bnoordhuis>indutny: shoot
19:59:28  <indutny>trying to figure out how to "hook" shared library
19:59:39  <indutny>odd, but LD_PRELOAD doesn't seem to be working for me
19:59:40  <indutny>for some reason
20:00:18  <indutny>bnoordhuis: so, basically
20:00:23  <indutny>I'm compiling a.c
20:00:29  <indutny>with definition of `malloc`
20:00:35  <indutny>and -shared gcc flag
20:00:40  <indutny>then doing this
20:00:48  <indutny>LD_PRELOAD=./a.so ./b
20:00:55  <indutny>and it isn't getting called
20:01:03  <bnoordhuis>what does a.c look like?
20:01:39  <indutny>bnoordhuis: https://gist.github.com/indutny/e4b35bc682541a72ea21
20:02:11  <indutny>bnoordhuis: if I'll compile b with -la
20:02:14  <indutny>bnoordhuis: it'll work
20:03:26  <othiym23>trevnorris: the best thing about domains is that they do what they're supposed to do, the vast majority of the time
20:03:27  <indutny>and I'm doing it on osx
20:03:39  <othiym23>the implementation is sort of a mess because of that
20:03:42  <indutny>aaah
20:03:48  <indutny>there's no such thing on osx :)
20:03:57  <indutny>gosh
20:03:57  <indutny>DYLD_INSERT_LIBRARIES
20:04:04  <trevnorris>othiym23: the fact that every event emitter instantiation has to suffer by checking domains.active really sucks.
20:04:11  <bnoordhuis>indutny: btw, you can drop the 'extern'
20:04:16  <indutny>yeah
20:04:16  <indutny>thanks
20:04:36  <trevnorris>othiym23: especially since hooking into the event emitter was a hack to listen for the "async events"
20:04:45  <bnoordhuis>indutny: you figured out yourself but np :)
20:05:27  <othiym23>trevnorris: from the point of view of complexity and performance, I totally see where you're coming from
20:05:49  <othiym23>trevnorris: having EEs implicitly bound into the domains where they're created makes domains usable, though
20:06:57  <trevnorris>othiym23: you only think so. I've remove the domain check from the EE#emit() and still have most tests passing. the ones that aren't don't seem related.
20:07:00  <indutny>bnoordhuis: nah, it doesn't work anyway
20:07:02  <indutny>wtf
20:08:02  <trevnorris>othiym23: it's this use case that really sucks, and shouln't be allowed imo: http://git.io/0RgQBA
20:08:02  <indutny>haha
20:08:23  <trevnorris>othiym23: since the setTimeout is the actual async event that's throwing. the event emitter is just sugar to run a callback system.
20:08:35  <trevnorris>it doesn't actually break the call stack
20:09:13  <trevnorris>i have everything else passing w/o needing to check for domain specifics in emit()
20:09:53  <othiym23>the test coverage around domains is not awesome, but I would expect that test to pass, and is a proxy for real-world code where EEs cross domains
20:11:27  <indutny>foh
20:11:27  <indutny>DYLD_FORCE_FLAT_NAMESPACE
20:11:29  <indutny>gosh
20:15:33  <indutny>bnoordhuis: another question :)
20:15:38  <indutny>bnoordhuis: you still there?
20:16:58  <bnoordhuis>indutny: yep
20:17:10  <indutny>bnoordhuis: do you know any way to insert function into shared library
20:17:21  <indutny>bnoordhuis: i.e. I've a shared library that expects symbol in another library to be present
20:17:24  <indutny>bnoordhuis: but it isn't
20:17:31  <indutny>bnoordhuis: and I want to inject stub to emulate it
20:17:43  <indutny>I was hoping that nmedit will help me
20:17:51  <bnoordhuis>indutny: edit and recompile?
20:17:56  <indutny>bnoordhuis: I don't have sources
20:18:12  <bnoordhuis>ah okay
20:18:26  <bnoordhuis>overloading with LD_PRELOAD should work, with some caveats
20:19:12  <bnoordhuis>but... i'm not sure if what you're trying to do is a great solution
20:19:21  <bnoordhuis>i mean, why is that symbol missing in the first place?
20:19:43  <indutny>no it won't
20:19:47  <indutny>I mean
20:19:50  <indutny>its not in flat namespace
20:19:56  <indutny>and if I force it into it - it fails
20:20:08  <indutny>bnoordhuis: that framework is compiled for older mac osx version
20:20:16  <indutny>bnoordhuis: and one symbol was removed during osx upgrade :)
20:20:59  <bnoordhuis>sorry, don't know how flat/non-flat namespaces are implemented
20:21:13  <indutny>yeah, me neither
20:21:22  <indutny>it seems to be a black magic
20:32:31  * AvianFlu_joined
20:32:31  * AvianFluquit (Disconnected by services)
20:32:39  * AvianFlu_changed nick to AvianFlu
20:36:37  * bradleymeckquit (Quit: bradleymeck)
20:37:06  * bradleymeckjoined
20:54:57  * c4milojoined
20:57:44  * `3rdEdenchanged nick to `3E|ZZZ
20:58:12  * felixgejoined
20:58:15  * felixgequit (Client Quit)
21:05:49  <trevnorris>othiym23: ping
21:06:34  * felixgejoined
21:06:38  <othiym23>trevnorris: yo
21:06:54  <trevnorris>othiym23: help me understand test-domain-dispose.js
21:07:03  <trevnorris>othiym23: why shouldn't the setTimeout run?
21:07:59  <othiym23>it should run
21:08:17  <trevnorris>then why is there a message that says "This should not happen." ?
21:08:18  <othiym23>and it shoudl bump caught
21:08:28  <othiym23>wait, looking at wrong part of file
21:08:33  <othiym23>what line?
21:08:38  <trevnorris>46
21:08:46  <trevnorris>whoops
21:08:53  <trevnorris>sorry meant test-domain-exit-dispose
21:09:05  <othiym23>ah, hold on, gotta reload
21:10:10  <othiym23>trevnorris: I think my nerfing of domain.dispose overlooked this file, and the fact that the test wasn't failing on master isn't super reassuring
21:10:52  <trevnorris>hah
21:11:18  <tjfontaine>that's what we like to hear
21:11:33  <trevnorris>othiym23: when you nerfed dispose, did you get it in all the locations, like timers and such?
21:11:38  <othiym23>lemme look at master's version of domain.dispose again to make sure I'm not forgetting something
21:12:09  <othiym23>trevnorris: I only nerfed Domain.prototype.dispose, I left alone the bits that set disposed to true and check it
21:12:20  <othiym23>I assumed those were necessary for regular domain system functioning
21:12:42  <trevnorris>so then the callback shouldn't run, since timers check for _disposed
21:13:54  <othiym23>this bit of domains behavior is all isaacs
21:14:44  <trevnorris>ok, thanks.
21:14:45  <othiym23>I could make some guesses about what the rationale is, but I gotta say that behavior doesn't really make a whole lot of sense to em, except as a way to prevent a big cavalcade of errors once you've already started the process of shutting down after an error
21:15:28  <trevnorris>except his comment in code of: XXX This is a bit stupid. We should probably get rid of domain.dispose() altogether. It's almost always a terrible idea. --isaacs
21:15:29  <trevnorris>:P
21:16:05  <othiym23>yeah
21:16:36  <othiym23>my question is how much people rely on that (hint: some probably do, a *lot* of people are not cool with the idea of domains being a better shutdown mechanism rather than error-recovery tool)
21:17:05  <trevnorris>heh, yeah.
21:18:41  <trevnorris>well, I feel like nerfing that test :P
21:18:43  <tjfontaine>TooTallNate: just verifying this LGTY https://github.com/joyent/node/pull/5509
21:19:09  <trevnorris>mainly because I won't be able to accomplish that w/o re-adding all the domain code to timers.
21:20:01  <trevnorris>othiym23: you think it should be a necessary part of the api to allow prevention of callback execution?
21:23:37  * rendarquit
21:24:10  <othiym23>trevnorris: inasmuch as I'd like to see error-handling in Node move in a crash-only direction, I'm fine with letting the errors pile up, but I don't feel like that's my judgment to make :/
21:27:29  * amartens1joined
21:27:35  * bradleymeckquit (Quit: bradleymeck)
21:29:41  * amartensquit (Ping timeout: 248 seconds)
21:30:26  * julianduquejoined
21:33:07  * bnoordhuisquit (Ping timeout: 260 seconds)
21:42:22  * TooTallNatequit (Ping timeout: 240 seconds)
21:46:33  * sblomjoined
21:46:40  * felixgequit (Quit: felixge)
21:46:47  * TooTallNatejoined
21:48:48  <trevnorris>tjfontaine: ping
21:48:52  <tjfontaine>pong
21:49:56  <trevnorris>tjfontaine: would it be difficult for test/message to display the diff, instead of the entire file?
21:50:32  <tjfontaine>hm I thought it did
21:50:50  * c4miloquit (Remote host closed the connection)
21:51:10  <tjfontaine>trevnorris: which test?
21:51:59  <trevnorris>tjfontaine: ah, I see it. the .out file was so long it filled the screen. but when I scroll up it shows the diff.
21:52:10  <tjfontaine>nod
21:52:29  <tjfontaine>should have line/expect/actual fields
21:54:18  <trevnorris>wtf. this is strange. from stdin_messages.js w/ the patch it replaces process._tickCallback with Pipe._tickCallback.
21:54:25  <trevnorris>i'm not even sure how that's possible.
22:03:38  <trevnorris>othiym23: so, only have test-domain-http-server and a few repl tests not passing. finally.
22:07:22  <othiym23>awesome
22:07:33  <othiym23>this is with domains mostly decoupled from the rest of the code?
22:08:23  <trevnorris>othiym23: mostly. I can't completely decouple domains from events. the two cases of event instantiation and emitting 'error' need to check for domain properties.
22:08:37  <trevnorris>but at least core no longer uses enter/exit
22:09:54  <othiym23>yay for fewer closures in core!
22:10:02  * sblomquit
22:10:33  <trevnorris>:)
22:13:24  * st_lukejoined
22:15:21  <tjfontaine>how did my python install on this mac get so screwed
22:15:55  <wolfeidau>TooTallNate: I can see why you leave your compiler suite alone when targeting the raspberry pi, finally got it working on debian mainly due to the older GLIBC used in that OS
22:16:09  * Kakeraquit (Ping timeout: 252 seconds)
22:16:23  <tjfontaine>lul
22:33:03  <saghul>tell piscisaureus_ if uv_want_endgame is called for a handle, is the endgame run unfit uv__handle_close is called?
22:33:11  <saghul>ircretary tell piscisaureus_ if uv_want_endgame is called for a handle, is the endgame run unfit uv__handle_close is called?
22:33:11  <ircretary>saghul: I'll be sure to tell piscisaureus_
22:33:15  <saghul>ircretary thanks
22:33:16  <ircretary>saghul: You're welcome :)
22:33:45  * AvianFluquit (Ping timeout: 252 seconds)
22:35:04  * st_lukequit (Remote host closed the connection)
22:39:25  * bnoordhuisjoined
22:39:51  <trevnorris>othiym23: have to tell you, i'm really wanting to get this patch done so I can start working on https://github.com/joyent/node/issues/6252
22:40:07  <othiym23>trevnorris: I'm not the boss of [email protected]
22:40:14  <othiym23>s/@/!/
22:40:37  <trevnorris>othiym23: hehe. yeah, but now that I've started, like hell I'm going to give this up. :)
22:42:15  <trevnorris>othiym23: besides, it's allowing me a fair amount of cleanup that'll help with those perf enhancements.
22:42:24  <othiym23>good!
22:43:46  * bnoordhuisquit (Ping timeout: 245 seconds)
22:45:16  * st_lukejoined
22:53:05  * blissdev|zzzchanged nick to blissdev
23:08:10  * c4milojoined
23:12:50  * dominictarrquit (Quit: dominictarr)
23:21:10  * TooTallNatequit (Read error: No route to host)
23:32:34  * TooTallNatejoined
23:55:54  <trevnorris>whoa LOUDBOT
23:56:02  * jmar777quit (Ping timeout: 246 seconds)
23:56:30  <tjfontaine>trevnorris: well are you gonna show him?
23:56:38  <trevnorris>..........
23:56:42  <tjfontaine>heh
23:57:25  <trevnorris>ok. so I can remove domains from everything except lib/events.js
23:58:02  <trevnorris>it's so freakishly tightly coupled. which sucks because emit() is one of the top 3 hottest code paths.
23:59:54  <MI6>libuv-master-gyp: #195 UNSTABLE windows-x64 (4/195) smartos-ia32 (2/194) windows-ia32 (3/195) smartos-x64 (2/194) http://jenkins.nodejs.org/job/libuv-master-gyp/195/