00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:19:42  <bnoordhuis>i did a good deed today. i fixed the v8 build on openbsd
00:19:53  <bnoordhuis>all three openbsd users rejoice
00:28:39  * st_lukejoined
00:32:32  * paulfryzelquit (Remote host closed the connection)
00:38:32  * jmar777quit (Remote host closed the connection)
00:38:48  * st_luke_joined
00:41:50  * st_lukequit (Ping timeout: 240 seconds)
00:47:31  <MI6>joyent/libuv: Ben Noordhuis master * 35ea88c : build: disable parallel automake tests (+4 more commits) - http://git.io/8bMRUA
00:53:54  <MI6>joyent/node: Ben Noordhuis master * 222e523 : v8: fix openbsd build - http://git.io/C_hG4g
00:55:07  <bnoordhuis>fyi, compiling on openbsd involves installing gcc and g++ 4.7, then running `./configure && gmake CC=egcc CXX=eg++ LINK=g++`
00:55:11  <bnoordhuis>simple, right?
00:55:29  <tjfontaine>ya I saw the v8 mailing list :)
01:00:19  * defunctzombie_zzchanged nick to defunctzombie
01:02:15  * kazuponjoined
01:13:55  * stagasjoined
01:15:42  * paulfryzeljoined
01:31:24  * stagasquit (Ping timeout: 256 seconds)
01:32:49  * kazuponquit (Remote host closed the connection)
01:38:01  * abraxasjoined
01:41:27  <MI6>nodejs-master-windows: #165 FAILURE windows-x64 (19/618) windows-ia32 (20/618) http://jenkins.nodejs.org/job/nodejs-master-windows/165/
01:45:10  * bnoordhuisquit (Ping timeout: 256 seconds)
01:51:46  * kazuponjoined
01:53:27  * kazuponquit (Remote host closed the connection)
01:56:05  * kazuponjoined
01:56:55  * `3rdEdenjoined
01:57:35  * Raynosjoined
02:02:35  * st_lukejoined
02:02:41  * st_lukequit (Remote host closed the connection)
02:08:33  * AvianFluquit (Remote host closed the connection)
02:09:02  * AvianFlujoined
02:48:53  * brsonquit (Ping timeout: 245 seconds)
02:50:56  * brsonjoined
02:52:45  <MI6>libuv-master-gyp: #86 FAILURE smartos-x64 (2/191) smartos-ia32 (2/191) http://jenkins.nodejs.org/job/libuv-master-gyp/86/
02:53:42  <tjfontaine>ircretary: tell bnoordhuis test-ip6-addr.obj : error LNK2001: unresolved external symbol _snprintf [g:\jenkins\workspace\libuv-master-gyp\eec653f3\run-tests.vcxproj]
02:53:42  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
03:22:48  * kazuponquit (Remote host closed the connection)
03:50:59  * c4milojoined
04:15:28  * niskaquit (Ping timeout: 240 seconds)
04:22:24  * c4miloquit (Remote host closed the connection)
04:22:57  * c4milojoined
04:27:39  * c4miloquit (Ping timeout: 276 seconds)
04:38:42  * dshaw_joined
04:39:01  * niskajoined
05:00:24  * brson_joined
05:02:29  * brsonquit (Ping timeout: 248 seconds)
05:25:19  * paulfryzelquit (Remote host closed the connection)
05:35:48  * kazuponjoined
05:38:54  * paddybyersjoined
05:55:49  * paulfryzeljoined
06:04:43  * paulfryzelquit (Ping timeout: 264 seconds)
06:06:45  * emilsedghquit (Ping timeout: 264 seconds)
06:26:13  * defunctzombiechanged nick to defunctzombie_zz
06:31:17  * groundwaterquit (Quit: groundwater)
06:36:51  * defunctzombie_zzchanged nick to defunctzombie
06:39:28  * Benvie_quit (Ping timeout: 264 seconds)
06:51:08  * hzjoined
07:00:59  * paulfryzeljoined
07:01:35  * rendarjoined
07:09:42  * paulfryzelquit (Ping timeout: 256 seconds)
07:15:00  * brson_quit (Quit: leaving)
07:15:36  * hzquit
07:17:55  * paddybyersquit (Ping timeout: 264 seconds)
07:31:05  * csaohjoined
07:32:48  <indutny>hohoho
07:41:17  * defunctzombiechanged nick to defunctzombie_zz
07:49:14  * st_luke_quit (Remote host closed the connection)
07:57:01  * roxlupart
08:04:18  * paddybyersjoined
08:11:19  * paddybyersquit (Ping timeout: 264 seconds)
08:39:28  * felixgejoined
09:04:23  * mraleph1quit (Read error: Connection reset by peer)
09:04:24  * mralephjoined
09:06:08  * csaohquit (Quit: csaoh)
09:06:21  * paulfryzeljoined
09:08:18  * dshaw_quit (Quit: Leaving.)
09:10:33  * paulfryzelquit (Ping timeout: 245 seconds)
09:12:54  * hzjoined
09:15:22  * csaohjoined
09:18:26  * emilsedghjoined
09:27:19  * abraxasquit (Remote host closed the connection)
09:38:42  * dshaw_joined
09:39:30  * bnoordhuisjoined
09:40:12  * dshaw_1joined
09:40:26  * dshaw_quit (Read error: Connection reset by peer)
09:46:03  * kazuponquit (Remote host closed the connection)
09:48:05  * kazuponjoined
09:50:04  * emilsedghquit (Changing host)
09:50:04  * emilsedghjoined
09:50:54  * dshaw_1quit (Ping timeout: 264 seconds)
09:56:06  * hzquit
10:02:02  * kazuponquit (Remote host closed the connection)
10:07:00  * paulfryzeljoined
10:11:30  * paulfryzelquit (Ping timeout: 276 seconds)
10:19:15  * stagasjoined
10:26:48  <MI6>joyent/node: Sam Roberts v0.10 * 6a7be99 : doc: fs.open, fix flag/mode confusion, etc. - http://git.io/xlq3ww
10:35:13  <MI6>nodejs-v0.10: #1402 UNSTABLE osx-ia32 (1/593) linux-x64 (4/593) smartos-x64 (2/593) http://jenkins.nodejs.org/job/nodejs-v0.10/1402/
10:40:16  * AvianFluquit (Remote host closed the connection)
10:42:59  <MI6>nodejs-v0.10-windows: #132 UNSTABLE windows-ia32 (9/593) windows-x64 (9/593) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/132/
10:43:49  * csaohquit (Quit: csaoh)
10:45:05  * AvianFlujoined
10:47:41  * dshaw_joined
10:51:00  * csaohjoined
10:51:48  * dshaw_quit (Ping timeout: 245 seconds)
11:07:30  * paulfryzeljoined
11:11:48  * paulfryzelquit (Ping timeout: 245 seconds)
11:11:56  <MI6>joyent/node: Forrest L Norvell v0.10 * 231092d : doc: document domain.enter() and domain.exit() - http://git.io/Nt75Zw
11:19:44  <MI6>nodejs-v0.10: #1403 UNSTABLE smartos-x64 (1/593) linux-ia32 (10/593) http://jenkins.nodejs.org/job/nodejs-v0.10/1403/
11:27:06  <MI6>nodejs-v0.10-windows: #133 UNSTABLE windows-ia32 (9/593) windows-x64 (10/593) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/133/
11:31:07  * dominictarrjoined
11:31:54  <MI6>joyent/libuv: Ben Noordhuis master * 553f8ef : test: add windows-only snprintf() function - http://git.io/Zcjowg
11:31:56  <bnoordhuis>tjfontaine: ^
11:34:12  <MI6>libuv-v0.8: #24 UNSTABLE smartos (3/158) linux (3/158) osx (2/158) http://jenkins.nodejs.org/job/libuv-v0.8/24/
11:39:20  <MI6>libuv-v0.10-gyp: #68 FAILURE windows-x64 (3/188) smartos-ia32 (2/187) windows-ia32 (3/188) smartos-x64 (2/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/68/
11:40:05  <MI6>libuv-master: #149 FAILURE http://jenkins.nodejs.org/job/libuv-master/149/
11:43:29  <MI6>libuv-master-gyp: #87 FAILURE smartos-ia32 (3/191) smartos-x64 (2/191) http://jenkins.nodejs.org/job/libuv-master-gyp/87/
12:08:09  * paulfryzeljoined
12:09:24  * dominictarrquit (Quit: dominictarr)
12:11:11  <bnoordhuis>don't tell me i broke it again...
12:12:52  * paulfryzelquit (Ping timeout: 256 seconds)
12:14:23  <MI6>joyent/libuv: Ben Noordhuis master * fd08290 : test: add windows-only snprintf() function - http://git.io/Nw3UvQ
12:14:49  <bnoordhuis>hm, seems part jenkins fail, part msvc fail
12:18:28  * stagasquit (Ping timeout: 245 seconds)
12:21:29  * pachetjoined
12:24:41  * hzjoined
12:25:21  * hzquit (Client Quit)
12:25:38  * hzjoined
12:28:59  * Raltquit (Ping timeout: 246 seconds)
12:29:16  * dominictarrjoined
12:30:01  * Raltjoined
12:31:16  * dominictarrquit (Client Quit)
12:48:28  * dshaw_joined
12:53:19  * dshaw_quit (Ping timeout: 264 seconds)
12:57:04  * saghuljoined
12:59:33  * bnoordhuisquit (Ping timeout: 264 seconds)
13:02:58  * dominictarrjoined
13:04:08  * dominictarrquit (Client Quit)
13:08:38  * paulfryzeljoined
13:12:55  * paulfryzelquit (Ping timeout: 245 seconds)
13:22:47  * st_lukejoined
13:26:05  * jmar777joined
13:27:03  * jmar777quit (Remote host closed the connection)
13:38:28  * bajtosjoined
13:51:06  * AvianFluquit (Remote host closed the connection)
14:03:45  * jmar777joined
14:13:59  * paulfryzeljoined
14:27:47  * st_lukequit (Remote host closed the connection)
14:37:57  * roxlujoined
14:37:59  <roxlu>hey
14:38:19  <roxlu>someone familiar with this uv.h erorr: https://gist.github.com/roxlu/969b04e9e996778fad44 ?
14:38:58  * AvianFlujoined
14:46:48  * st_lukejoined
14:48:02  * jmar777quit (Read error: Connection reset by peer)
14:48:33  * jmar777joined
14:51:02  * st_lukequit (Ping timeout: 240 seconds)
14:51:25  * st_lukejoined
14:51:46  * stagasjoined
14:55:26  * st_lukequit (Ping timeout: 240 seconds)
14:58:34  * kazuponjoined
15:04:01  * st_lukejoined
15:04:21  * st_lukequit (Read error: Connection reset by peer)
15:07:21  * julianduquejoined
15:15:27  <indutny>hoya
15:16:17  * bradleymeckjoined
15:19:23  <tjfontaine>wtg java! https://gist.github.com/tjfontaine/6156737
15:20:37  <MI6>libuv-master: #150 FAILURE windows (4/192) http://jenkins.nodejs.org/job/libuv-master/150/
15:20:50  <MI6>libuv-node-integration: #138 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/138/
15:20:56  <roxlu>hey indutny !
15:21:00  <indutny>hoya
15:21:02  <roxlu>hehe
15:21:39  <roxlu>indutny: do you have an idea what this might cause: https://gist.github.com/roxlu/969b04e9e996778fad44
15:21:51  <roxlu>it's a msvc2012 error I get
15:22:00  <indutny>struct {} <- without semicolon?
15:22:01  <indutny>or probably class
15:22:04  <indutny>ah wait
15:22:20  <roxlu>it's in uv.h somewhere
15:22:30  <MI6>libuv-master-gyp: #88 UNSTABLE smartos-ia32 (2/191) windows-ia32 (3/192) smartos-x64 (2/191) windows-x64 (3/192) linux-ia32 (1/191) http://jenkins.nodejs.org/job/libuv-master-gyp/88/
15:22:36  <roxlu>it looks like an #include uv.h, w/o extern "C"
15:23:57  * st_lukejoined
15:24:21  <indutny>roxlu: what are you doing?
15:24:29  <indutny>are you linking it yourself?
15:24:53  <roxlu>I've compiled libuv as a static lib and linking against that one
15:25:07  <roxlu>I've got a MSVC2012 project file in which I set the libuv.lib as input lib
15:25:40  * groundwaterjoined
15:26:47  * st_luke_joined
15:27:38  * st_luke_quit (Read error: Connection reset by peer)
15:28:14  * st_lukequit (Ping timeout: 240 seconds)
15:29:47  <roxlu>hmm I fixed it by make #include <uv.h> the very first line in my main.cpp
15:29:56  * st_lukejoined
15:34:12  * st_luke_joined
15:34:14  * st_lukequit (Ping timeout: 240 seconds)
15:36:58  <roxlu>indutny: it would be nice to have some checks in uv.h when some other defines have been set already and give an error
15:37:03  <roxlu>as this is typical win problem
15:38:16  * st_lukejoined
15:38:38  * st_luke_quit (Ping timeout: 240 seconds)
15:39:17  * st_luke_joined
15:42:06  * bnoordhuisjoined
15:42:14  * st_lukequit (Ping timeout: 240 seconds)
15:43:26  * st_luke_quit (Ping timeout: 240 seconds)
15:45:15  * st_lukejoined
15:50:04  * st_lukequit (Ping timeout: 256 seconds)
15:50:15  * bajtosquit (Quit: bajtos)
15:51:48  <indutny>roxlu: heh
15:51:53  <indutny>yes, its tipical on windows
15:52:11  <indutny>bnoordhuis: hey man
15:57:11  <MI6>libuv-v0.10: #104 FAILURE windows (4/188) linux (1/187) http://jenkins.nodejs.org/job/libuv-v0.10/104/
15:57:16  * dapjoined
15:59:23  * dominictarrjoined
16:01:26  * wavdedjoined
16:04:46  <isaacs>good morning
16:05:01  <Domenic_>good morning
16:05:10  * dominictarrquit (Quit: dominictarr)
16:06:06  <Domenic_>isaacs: quick question about vm2. should we maintain backward compatibility and keep conflating contexts and global objects? or should we do like contextify and say a context has a global object?
16:06:34  <indutny>morning
16:06:34  <isaacs>Domenic_: backwards compatibility would be best.
16:06:50  * c4milojoined
16:07:13  <Domenic_>isaacs: ok. shouldn't be too hard. will store hidden reference to context on the global object, then whenever people pass in the global object to the C++ we just retrieve the context from the global via this hidden property and use it like normal.
16:07:36  <isaacs>Domenic_: i think the best way would be to work like a reference to a window object.
16:07:54  <isaacs>Domenic_: ie, if the other realm makes a change to it, there it is
16:08:08  <isaacs>Domenic_: it should be like shared access to the global obj
16:08:15  <Domenic_>isaacs: sure that already works though, it's just whether you get back the context or the global from vm.createContext
16:08:30  <isaacs>Domenic_: if we MUST break bw compatibility, then let's create a whole new API for it, and deprecate the janky one we have now.
16:08:48  <Domenic_>there's definitely no MUST here.
16:09:05  <isaacs>oic, it could give you the global, but when you do script.runInContext(tehGlobal) it looks up the hidden context obj, and uses that?
16:09:12  <Domenic_>yeah
16:09:40  <Domenic_>so when you do var context = vm.createContext(global), context === global
16:10:06  <Domenic_>in contextify it's context.getGlobal() === global
16:10:10  <bnoordhuis>indutny: sup fedor?
16:10:12  <Domenic_>there's also context.run()
16:10:17  <indutny>lets review my thing! :)
16:10:56  <bnoordhuis>indutny: which one?
16:11:00  <isaacs>Domenic_: yeah. and those leak IN the context itself.
16:11:05  <isaacs>Domenic_: at least, last i checked
16:11:11  <indutny>https://github.com/joyent/node/pull/5987#issuecomment-22104054
16:11:13  <indutny>bnoordhuis: ^
16:11:50  * dominictarrjoined
16:11:55  <Domenic_>isaacs: that was actually not an inherent feature of contextify, just part of it's JS API. See https://github.com/brianmcd/contextify/blob/master/lib/contextify.js
16:12:31  <isaacs>Domenic_: ok
16:13:00  <Domenic_>i think this hidden reference thing will work pretty well though.
16:13:10  <isaacs>Domenic_: istr it did stuff like var obj = contextify.createContext({assert:assert}); obj.run('assert(typeof run === "undefined")') would fail
16:13:46  <Domenic_>isaacs: I think that was true for contextify({ assert: assert }) but this contextify.createContext thing is new and does not have that problem.
16:14:00  <isaacs>Domenic_: ahhh
16:14:01  <isaacs>ok
16:14:38  <isaacs>Domenic_: so, basically, in that isue ("vm module is incorrect"), I wrote a bunch of assertions that i think it has to pass.
16:15:07  <isaacs>Domenic_: i won't say taht passing those means it's guaranteed i'm going to lgtm it, but i definitely won't lgtm it *unless* it passes those :)
16:15:26  <Domenic_>isaacs: ah ok, i guess i hadn't reviewed those in too long. "A context should be indistinguishable from the object it's based on." is #1, hehe
16:15:41  <Domenic_>It's conceptually annoying that the global and context are conflated, but oh well.
16:15:50  <bnoordhuis>indutny: thanks. will check in a sec. sorry if that rhymes
16:16:08  <indutny>bnoordhuis: its ok, I like that you're doing it this way
16:16:19  <bnoordhuis>well played, sir :)
16:16:26  <indutny>no matter how rhyme, I still enjoy your style
16:16:30  <indutny>s/how/how you/
16:16:33  <indutny>;)
16:16:56  <isaacs>Domenic_: yeah, but keeping them separated is confusing if you don't have a rather deep understanding of the language.
16:17:12  <isaacs>Domenic_: most people jsut wanna say "run with this sandbox of references available"
16:17:24  * bajtosjoined
16:17:25  <isaacs>Domenic_: though... it really sucks that you can climb up the prototype out of the box.
16:17:47  <isaacs>Domenic_: we should eventually implement the V8 security token whatever thingies, if those still exist
16:18:26  <MI6>joyent/node: mstarzinger@chromium.org v0.10 * 6b92a71 : v8: back-port fix for CVE-2013-2882 - http://git.io/mEmPqw
16:20:16  * jmar777quit (Remote host closed the connection)
16:22:16  <Domenic_>isaacs: honestly I'd rather have vm.createContext not return anything, so it's clear it's a mutator that does something magic to the sandbox. but this is all in the realm of "if we could start over" land, anyway.
16:22:53  <isaacs>Domenic_: so... if you want to create a completely new API from whole cloth, then that's not out of hte question.
16:22:59  <isaacs>Domenic_: but don't get too excited.
16:23:11  <isaacs>Domenic_: that's also a lot more work, and it'll have to be MUCH better to justify
16:23:25  <isaacs>Domenic_: and the old API will have ot live in the corner forever.
16:23:49  <Domenic_>isaacs: meh, yeah, not really worth it. there's no real new capabilities it would introduce to justify that, just better API design.
16:23:52  <isaacs>Domenic_: what i kind of always imagined was that you'd create a Script object, and then that'd be the house for all the stuff.
16:24:06  <isaacs>Domenic_: so you could compile a script, assign a global, etc.
16:24:14  <isaacs>Domenic_: or even like, model the V8 api for doing this
16:24:25  * jmar777joined
16:24:27  <isaacs>Domenic_: so basically, i'td be like a V8 binding to V8 :)
16:24:39  <ircretary>Yo, Dawg.
16:24:48  <isaacs>ircretary: Exactly.
16:24:49  <ircretary>isaacs: I'm not sure what to do with that command. Ask for help in PM.
16:26:38  <isaacs>var v8 = require('v8'); var ctx = v8.createContext(); var glb = ctx.getGlobal(); etc.
16:27:13  <isaacs>the vm module is *almost* there, but frustratingly full of impedance mismatches.
16:27:20  <isaacs>Domenic_: i don't konw, i'm babbling, don't listen to me.
16:27:58  <Domenic_>isaacs: haha, i mean, could be fun. just a bit far from where the conversation is now i guess, so not sure what's going on.
16:28:13  <isaacs>eah
16:28:26  <isaacs>Domenic_: fuckit, do what you'er doing. you're on a good path, it seems like.
16:28:58  <isaacs>Domenic_: my main beef with the VM module is that it's not close enough to V8 to say "Learn V8! It works like that!" and it's not close enough to the browser to behave that way
16:29:00  <MI6>nodejs-v0.10: #1404 UNSTABLE osx-ia32 (1/593) linux-x64 (2/593) http://jenkins.nodejs.org/job/nodejs-v0.10/1404/
16:29:21  <isaacs>Domenic_: and you kinda need to know a lot about how the language works to use it, but also then learn how it's actually completely different form how the language works
16:29:37  <isaacs>Domenic_: and then this oddball "copy back to the context object global thing after running"? ew.
16:29:48  <Domenic_>isaacs: well, that last will be gone, hooray
16:30:04  <isaacs>Domenic_: vm.runInContext('a.b=1', {a:{b:0}}); assert.equal(a.b, 1) // fail
16:30:20  <isaacs>gotta run.
16:30:27  <Domenic_>i think the problem with it after my current work will just be that it has a large surface area full of API that you mostly don't care about.
16:30:31  <isaacs>i'll be back in a few hours, for my bug triage day
16:32:51  <bnoordhuis>https://github.com/v8/v8/commit/0141953 <- "introduce eternal handles"
16:33:04  <bnoordhuis>sounds exotic and mysterious, doesn't it?
16:35:56  <mmalecki>bnoordhuis: eternal handles are the new $ENTITY I'm going to pray to
16:40:24  * c4miloquit (Remote host closed the connection)
16:40:43  <isaacs>i would guess that eternal handles never get gc'ed?
16:40:53  <isaacs>that could be good for some of our current Persistents
16:41:07  <isaacs>especially symbols and the like
16:41:30  * isaacs&
16:41:31  <LOUDBOT>DIRK GENTLY AND THE HOLISTIC OFFSHORE PROGRAMMING SWEATSHOP
16:41:39  <mmalecki>how do I build node with v8's define declared?
16:43:17  * bnoordhuisquit (Ping timeout: 248 seconds)
16:47:38  * piscisaureus_joined
16:47:55  <mmalecki>ah, there's a ./configure option for that, nvm
16:49:44  * sblomjoined
16:51:40  * julianduquequit (Ping timeout: 245 seconds)
16:54:07  * dominictarrquit (Quit: dominictarr)
16:55:40  * csaohquit (Quit: csaoh)
16:56:59  * dshaw_joined
16:59:11  <MI6>nodejs-v0.10-windows: #134 UNSTABLE windows-ia32 (10/593) windows-x64 (9/593) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/134/
17:04:23  * mikealjoined
17:06:37  * defunctzombie_zzchanged nick to defunctzombie
17:07:13  * TooTallNatejoined
17:12:13  * hzquit
17:18:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:21:43  * austojoined
17:26:34  <pfox__>is there any discussion/documentation about transitioning handles to different loops in the same process? i gather that it's not really possible, ootb. currently if there's anyone doing anything like it, though.
17:26:52  <pfox__>s/currently/curious/
17:32:51  * bradleymeckquit (Quit: bradleymeck)
17:35:40  <indutny>ben
17:35:44  <indutny>where are thou?
17:41:02  * kazuponquit (Remote host closed the connection)
17:41:36  * felixgequit (Quit: felixge)
17:45:10  * AvianFluquit (Remote host closed the connection)
17:46:45  * pachetquit (Quit: leaving)
17:49:34  * bnoordhuisjoined
17:53:53  * bnoordhuisquit (Ping timeout: 245 seconds)
17:57:47  * dshaw_quit (Quit: Leaving.)
18:05:07  * st_lukejoined
18:07:10  * AvianFlujoined
18:11:55  * dominictarrjoined
18:20:57  * c4milojoined
18:21:14  * brsonjoined
18:21:33  * c4milo_joined
18:25:09  * c4miloquit (Ping timeout: 248 seconds)
18:28:58  * bajtosquit (Quit: bajtos)
18:30:21  * dshaw_joined
18:30:47  * defunctzombiequit (Ping timeout: 264 seconds)
18:34:35  * dshaw_quit (Ping timeout: 245 seconds)
18:36:31  * defunctzombie_zzjoined
18:36:55  * defunctzombie_zzchanged nick to defunctzombie
18:37:13  * defunctzombiequit (Changing host)
18:37:14  * defunctzombiejoined
18:42:12  * dshaw_joined
18:44:34  <indutny>ben ben
18:44:45  <indutny>isaacs: hi
18:44:51  <indutny>have I resolved this issue with npm publish?
18:44:55  <indutny>segfault in bio.cc
18:46:01  * dshaw_1joined
18:46:32  * dshaw_quit (Read error: Connection reset by peer)
18:47:48  * stagas_joined
18:48:37  * stagasquit (Ping timeout: 248 seconds)
18:48:44  * stagas_changed nick to stagas
18:51:29  * kazuponjoined
18:52:58  * mikealquit (Quit: Leaving.)
18:54:13  * mikealjoined
18:54:38  * pachetjoined
18:56:28  * bajtosjoined
18:56:46  * kazuponquit (Ping timeout: 246 seconds)
18:58:02  * bajtosquit (Client Quit)
19:03:00  <isaacs>indutny: checking now
19:06:52  <indutny>thanks
19:06:52  <indutny>:)
19:12:05  * c4milo_quit (Remote host closed the connection)
19:12:39  * c4milojoined
19:12:43  <isaacs>indutny: seems to work now :)
19:12:45  <isaacs>indutny: thanks!
19:13:06  * bnoordhuisjoined
19:13:28  <indutny>you're welcome :)
19:13:50  <indutny>bnoordhuis: ben, ben, ben
19:13:54  <indutny>where are you?
19:15:46  * mikealquit (Quit: Leaving.)
19:17:19  * c4miloquit (Ping timeout: 268 seconds)
19:20:14  <bnoordhuis>indutny: i'm here and yes, i will look at your pr
19:21:18  * dominictarrquit (Quit: dominictarr)
19:21:39  <bnoordhuis>also, it seems i broke the libuv build with older automake versions...
19:22:05  <bnoordhuis>fix something so it works with a newer version and you break something else with an older version. you just can't win
19:26:28  <indutny>haha
19:28:43  * sblomquit (Ping timeout: 264 seconds)
19:33:44  * DrPizzaquit (Quit: alice.)
19:33:44  <isaacs>bnoordhuis: trivial fix: https://gist.github.com/isaacs/6158784
19:33:49  <isaacs>bnoordhuis: lgty?
19:33:55  * DrPizzajoined
19:37:42  * DrPizzaquit (Client Quit)
19:37:59  * DrPizzajoined
19:39:34  <bnoordhuis>isaacs: yep, lgtm
19:39:42  <isaacs>kk
19:39:51  <isaacs>i'm fixing up koichik's test so that it doens't require internet, as well
19:42:38  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:46:56  <isaacs>bnoordhuis: there is actually a very interesting bug that i've discovered with koichik's patch. https requests aren't using the https.globalAgent!
19:49:17  <isaacs>bnoordhuis: oh, nevermind. i was reading the test wrong :)
19:53:45  <MI6>joyent/node: Koichi Kobayashi master * 72ad2c9 : https: fix default port (+1 more commits) - http://git.io/mRR8iQ
19:54:01  * mikealjoined
19:55:38  * c4milojoined
19:55:40  <MI6>joyent/node: isaacs master * f4b1e00 : test: Move test-http-default-port from disabled to simple - http://git.io/_FRIVg
20:01:48  * indexzerojoined
20:03:20  <MI6>nodejs-master: #369 UNSTABLE smartos-ia32 (2/618) smartos-x64 (9/618) osx-x64 (1/618) linux-x64 (1/618) http://jenkins.nodejs.org/job/nodejs-master/369/
20:03:47  * mikeal1joined
20:03:50  * mikealquit (Read error: Connection reset by peer)
20:06:28  * wavdedquit (Ping timeout: 260 seconds)
20:07:14  * c4miloquit (Remote host closed the connection)
20:08:35  * wavdedjoined
20:12:44  <MI6>nodejs-master: #370 UNSTABLE smartos-ia32 (2/619) smartos-x64 (9/619) osx-x64 (1/619) http://jenkins.nodejs.org/job/nodejs-master/370/
20:15:15  <bnoordhuis>indutny: reviewed
20:15:20  <indutny>bnoordhuis: thank you!
20:15:27  <indutny>I'll fix everything and update PR tomorrow
20:15:40  <indutny>fighting with pretty obscure spdy bug right now
20:15:57  <bnoordhuis>btw, did you get around to investigating https://github.com/joyent/node/issues/4917 ?
20:16:05  <bnoordhuis>if not, i'll try to look at it tomorro
20:16:11  <bnoordhuis>*tomorrow. fscking mac keyboard
20:16:17  <indutny>ah, not really
20:16:17  <indutny>sorry
20:16:23  <bnoordhuis>okay, no problem
20:18:35  * TooTallNatejoined
20:19:11  * julianduquejoined
20:19:55  <bnoordhuis>isaacs: btw, about making things more approachable to potential contributors
20:20:03  <bnoordhuis>the rust project has this: https://github.com/mozilla/rust/issues?labels=E-easy&page=1&state=open
20:20:20  <bnoordhuis>an issue tag for, well, easy issues. maybe we can steal that
20:20:42  <bnoordhuis>of course, someone needs to go through all the issues and tag them
20:22:08  * dshaw_1quit (Quit: Leaving.)
20:22:40  <tjfontaine>https://github.com/joyent/node/issues?labels=http%2Ceasy&page=1&state=closed
20:22:47  <tjfontaine>heh we had it once upon a time :)
20:24:03  <MI6>nodejs-master-windows: #166 UNSTABLE windows-x64 (21/618) windows-ia32 (21/618) http://jenkins.nodejs.org/job/nodejs-master-windows/166/
20:27:44  <isaacs>bnoordhuis: yeah, we've tried that.
20:27:51  <isaacs>bnoordhuis: the problem is, by the time you know it's easy, you usaully know the fix.
20:29:10  * mikeal1quit (Quit: Leaving.)
20:33:20  <isaacs>trevnorris: don't forget to come to SF tonight
20:37:11  * jmar777quit (Remote host closed the connection)
20:37:32  * sblomjoined
20:37:50  * jmar777joined
20:39:27  * mikealjoined
20:41:53  * jmar777quit (Ping timeout: 240 seconds)
20:42:17  * dshaw_joined
20:46:35  <pfox__>i asked this earlier, didn't get a response: i was curious what documentation/discussion there is on being able to transition handles (or their underlying state) to different loops in the same process? i gather it isn't supported OOTB.. jsut curious if its something anyone is dealing with..
20:47:45  <MI6>nodejs-master-windows: #167 UNSTABLE windows-x64 (19/619) windows-ia32 (22/619) http://jenkins.nodejs.org/job/nodejs-master-windows/167/
20:48:48  <isaacs>bnoordhuis: CDDL is MIT-compatible
20:49:15  <isaacs>bnoordhuis: but we have to disclose it, include copyright statement, not use the trademark, and not try to sue the creators for patent infringemnet.
20:49:50  * brsonquit (Ping timeout: 240 seconds)
20:51:34  <bnoordhuis>pfox__: the only support currently is sending handles over a pipe
20:51:49  * brsonjoined
20:51:49  <bnoordhuis>pfox__: it's not great but the upside is you get cross-process support for free
20:53:05  * dshaw_quit (Quit: Leaving.)
20:54:14  * dshaw_joined
20:56:37  <pfox__>bnoordhuis: are there specific api calls for this particular case?
20:56:52  <MI6>joyent/node: isaacs v0.10 * 366baed : doc: Update LICENSE for npm's Artistic 2.0 - http://git.io/DGc5Uw
20:58:44  <bnoordhuis>pfox__: no, just uv_write2()
20:58:52  <bnoordhuis>i hate that name btw
20:59:30  <tjfontaine>uv_write_maybe_has_pipes() :)
21:00:38  <pfox__>bnoordhuis: no worries. thanks for taking the time to humor me. ok.. so im looking at uv.h .. so uv_pipe_init has the int ipc argument to indicate if handles will be sent across it..
21:00:46  <pfox__>does that only work cross-process, though?
21:01:29  <pfox__>im just wanting to do some discovery for rust, where we have this limitation where IO is chained to a given thread/scheduler it was created on, because that's where the loop is
21:01:59  <pfox__>just wanting to wrap my brain around what the libuv-side of the problem would be to allow transitioning IO primitives to other schedulers/loops within a process
21:04:19  <MI6>nodejs-v0.10: #1405 UNSTABLE smartos-x64 (1/593) http://jenkins.nodejs.org/job/nodejs-v0.10/1405/
21:07:11  <isaacs>tjfontaine: go ahead and land with the standard boilerplate.
21:07:23  <tjfontaine>isaacs: nod
21:07:34  <tjfontaine>isaacs: v0.11 tomorrow as well?
21:07:46  <isaacs>yes, good call
21:07:58  <tjfontaine>thank god the bart strike didn't happen.
21:08:07  <tjfontaine>or jerry brown anyway
21:08:34  <tjfontaine>LOUDBOT: CAN'T WE ALL JUST GET ALONG?
21:08:35  <LOUDBOT>tjfontaine: YOU KNOW I LIKE IT FAST AND HARD
21:13:43  <bnoordhuis>pfox__: it works cross-process and in-process. it basically does sendmsg/recvmsg with a SCM_RIGHTS message (on unix)
21:14:11  <MI6>nodejs-v0.10-windows: #135 UNSTABLE windows-ia32 (9/593) windows-x64 (9/593) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/135/
21:20:12  * dshaw_quit (Quit: Leaving.)
21:20:28  <MI6>joyent/node: Timothy J Fontaine master * e851fef : build: embed the mdb_v8.so into the binary - http://git.io/7Ou1tg
21:20:47  * dshaw_joined
21:23:33  * c4milojoined
21:27:46  <othiym23>tjfontaine: does node-jenkins need a swift kick or something?
21:27:58  <othiym23>it's still trying to decide if my PR is mergeable
21:28:18  <tjfontaine>othiym23: which pr?
21:29:11  <othiym23>tjfontaine: https://github.com/joyent/node/pull/5990
21:29:34  <tjfontaine>rebuilding now
21:29:41  <MI6>nodejs-master: #371 FAILURE smartos-x64 (10/619) http://jenkins.nodejs.org/job/nodejs-master/371/
21:29:53  <othiym23>don't worry, it's not going to land anytime soon, but it's been pending for about a day now ;)
21:30:20  <tjfontaine>jenkins was unhappy over the weekend
21:30:27  <tjfontaine>I. hate. jenkins. and. java.
21:31:26  <MI6>joyent/libuv: bnoordhuis created branch fix-autotools-build - http://git.io/Ww01xQ
21:32:24  <bnoordhuis>man, autotools...
21:33:09  * hzjoined
21:33:26  <tjfontaine>bnoordhuis: there's no winning the buildsystem game
21:34:00  <bnoordhuis>tjfontaine: what would happen when i opened a pull request that adds a test that sets up, say, a telnet server on a public address?
21:34:46  <bnoordhuis>and yes, the build tools game reminds me of that old movie, wargames
21:34:53  <bnoordhuis>the only way to win is not to play
21:36:13  <tjfontaine>bnoordhuis: only PRs submitted by people in a whitelist are generally built by default, unless someone previously triggered a build of that PR which case all subsequent pushes should retrigger, but if someone does something bad in the PR and we let it go through the buildsystem -- potentially game over
21:36:27  <bnoordhuis>ah, okay
21:37:00  <tjfontaine>up and until we have nicer image based slave deployment
21:38:50  <MI6>joyent/node: Timothy J Fontaine master * 032373d : build: fix ia32 sunos, elfwrap only needs -64 - http://git.io/2lnRrQ
21:39:02  <MI6>libuv-review: #32 FAILURE smartos-ia32 (3/191) windows-x64 (3/192) linux-x64 (1/191) smartos-x64 (2/191) osx-x64 (1/192) freebsd-x64 (4/191) windows-ia32 (4/192) http://jenkins.nodejs.org/job/libuv-review/32/
21:39:32  <tjfontaine>wtf jenkins, wtf really.
21:39:37  * c4miloquit (Remote host closed the connection)
21:40:04  <tjfontaine>the frontend just completely locks up for no good reason
21:40:14  <bnoordhuis>/usr/include/machine/segments.h:96: error: width of 'sd_hibase' exceeds its type
21:40:14  <bnoordhuis>/usr/include/machine/segments.h:114: error: width of 'gd_hioffset' exceeds its type
21:40:17  <bnoordhuis>/usr/include/machine/segments.h:184: error: width of 'rd_base' exceeds its type
21:40:27  <bnoordhuis>that's the 32/64 bits header mismatch, iirc?
21:40:34  <tjfontaine>yup
21:40:41  <tjfontaine>I can disable fbsd
21:41:12  <bnoordhuis>it doesn't bother me. would be nice to fix though
21:41:27  <tjfontaine>what would the proper fix be for that?
21:41:28  <bnoordhuis>at least fbsd amd64 works
21:41:35  <bnoordhuis>ehm... /me thinks
21:41:50  <bnoordhuis>can i log into that machine?
21:42:02  <tjfontaine>yes, 72.2.115.5
21:42:05  <tjfontaine>root@
21:42:11  * Damn3dquit (Ping timeout: 264 seconds)
21:42:13  <bnoordhuis>okay, let me check me a few things
21:43:53  <bnoordhuis>ah, u_int64_t sd_hibase:40 __packed;
21:44:08  <MI6>nodejs-master-windows: #168 UNSTABLE windows-x64 (16/619) windows-ia32 (23/619) http://jenkins.nodejs.org/job/nodejs-master-windows/168/
21:44:09  <bnoordhuis>they're using bit fields and the total width > 64 bits
21:44:33  <bnoordhuis>maybe not a 32/64 bits then
21:44:48  * Damn3djoined
21:46:35  * austoquit (Remote host closed the connection)
21:47:46  * `3rdEdenchanged nick to `3E|Zzz
21:49:08  * wavdedquit (Quit: Hasta la pasta)
21:49:14  <tjfontaine>hrm
21:49:22  <MI6>nodejs-master: #372 UNSTABLE smartos-ia32 (2/619) smartos-x64 (8/619) osx-ia32 (1/619) http://jenkins.nodejs.org/job/nodejs-master/372/
21:52:20  * brsonquit (Quit: leaving)
21:52:21  * felixgejoined
21:59:05  <trevnorris>hello hello
21:59:22  <trevnorris>isaacs: no worries. i'm in the moz sf office now
22:00:24  * brsonjoined
22:01:26  <trevnorris>bnoordhuis: don't know why, but just noticed that the bufer.write* methods throw if the value to write is too large, instead of just wrapping around. that seems sort of broken to me. thoughts?
22:01:59  <bnoordhuis>tjfontaine: found it. it's a gcc 4.2 bug. nothing we can do about that
22:02:10  <tjfontaine>bnoordhuis: shall I change that system to clang?
22:02:22  <bnoordhuis>tjfontaine: worth a try
22:02:28  <tjfontaine>ok, I'll queue that for tomorrow
22:02:32  * Somebody_joined
22:02:36  <tjfontaine>something to do during meetings
22:02:45  <bnoordhuis>let me try a quick compile with clang
22:03:45  * dominictarrjoined
22:04:13  <bnoordhuis>/usr/include/machine/segments.h:96:12: error: size of bit-field 'sd_hibase' (40 bits) exceeds size of its type (32 bits) u_int64_t sd_hibase:40 __packed;/* segment base address (msb) */
22:04:24  <bnoordhuis>at least clang gives a prettier message. it even does colors
22:04:41  <tjfontaine>I prefer clang in just about every scenario
22:05:03  <bnoordhuis>well, gcc still tends to produce tighter code
22:05:26  <bnoordhuis>and gcc 4.8 prints purdy error messages too now
22:05:35  <MI6>nodejs-master-windows: #169 UNSTABLE windows-x64 (20/619) windows-ia32 (19/619) http://jenkins.nodejs.org/job/nodejs-master-windows/169/
22:05:43  <tjfontaine>ya, it's nice to actually have someone motivating gcc to work on useful things :)
22:08:54  <bnoordhuis>it's curious that both clang and gcc error out
22:09:28  <bnoordhuis>i wrote a trivial test case that creates a uint64_t x:48 __attribute((packed)) bitfield
22:09:44  <bnoordhuis>with -m32 it compiles on other systems but not that fbsd system
22:11:26  <trevnorris>tjfontaine: you going tonight?
22:11:49  <tjfontaine>yup
22:12:13  <trevnorris>public transit or vehicular transport?
22:12:35  <tjfontaine>trevnorris: feets of strength, it's only a couple blocks from work I think
22:13:10  * paulfryzelquit (Remote host closed the connection)
22:13:23  <tjfontaine>I wish I could figure out with new google maps how to do map-linking
22:13:49  * rendarquit
22:14:19  <bnoordhuis>"A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed int, unsigned int, or some other implementation-defined type."
22:14:32  <bnoordhuis>meh, guess fbsd gcc and clang are borderline correct here
22:14:53  <trevnorris>i hate the new maps. i could drop by on the way there, but there's a js error that won't bring up the distance :-/
22:15:28  <bnoordhuis>tjfontaine: guess the easiest way to fix it is to spin up a 32 bits fbsd instance
22:15:54  * c4milojoined
22:16:51  <tjfontaine>trevnorris: http://goo.gl/xUA34g
22:17:00  <tjfontaine>bnoordhuis: and compile on that?
22:18:00  * pachetquit (Quit: leaving)
22:18:31  <bnoordhuis>tjfontaine: yep
22:18:42  <tjfontaine>bnoordhuis: ok
22:19:28  <tjfontaine>for now it's been removed from the -review, since jenkins doesn't have a good way to split builds for a matrix config
22:19:39  <tjfontaine>well it does, but it is easy for me to fuck up right now :)
22:20:03  <trevnorris>tjfontaine: when you leaving? i'll meet you on the corner of pine and front
22:20:45  <MI6>joyent/libuv: Ben Noordhuis master * a97685e : build: add automake serial-tests version check - http://git.io/Zqrlwg
22:21:01  <tjfontaine>trevnorris: probably 6:45
22:21:25  <trevnorris>tjfontaine: coolio. if you're going the route you linked I'll meet you en route.
22:21:47  <tjfontaine>sure, I'll pm you my number in case you need it
22:22:04  <bnoordhuis>have fun tonight, guys. see you tomorrow
22:22:14  <tjfontaine>bnoordhuis: enjoy
22:23:01  * AvianFluquit (Remote host closed the connection)
22:26:02  <MI6>libuv-master-gyp: #89 UNSTABLE smartos-x64 (2/191) smartos-ia32 (2/191) windows-ia32 (3/192) windows-x64 (3/192) http://jenkins.nodejs.org/job/libuv-master-gyp/89/
22:26:25  <MI6>libuv-master: #151 FAILURE windows (3/192) http://jenkins.nodejs.org/job/libuv-master/151/
22:26:44  * bnoordhuisquit (Ping timeout: 256 seconds)
22:27:11  <tjfontaine>heh, he broke smartos than ran away :P
22:30:00  * c4miloquit (Remote host closed the connection)
22:36:47  <trevnorris>tjfontaine: api question. so ArrayBuffer::Neuter immediately zeros out all children, where the Buffer#dispose i'm working on waits until all children are already disposed. which you think is the mejor api?
22:39:15  <tjfontaine>trevnorris: heh, my ideal world is actually neither :P what I'd like is for the children to be a weakmap, and when it's finally empty then you get to actually do the dispose
22:41:02  <tjfontaine>trevnorris: hm, the first one requires us to keep actual track of the children, whereas your ref count version allows us to keep count
22:41:26  * AvianFlujoined
22:41:34  <tjfontaine>trevnorris: is my assumption there correct?
22:43:06  * bradleymeckjoined
22:43:55  * dominictarrquit (Quit: dominictarr)
22:44:07  <trevnorris>tjfontaine: yeah. and ah crap. the ref count thing won't work because if the child is cleaned up by gc then the ref count won't decrement :P
22:44:30  <tjfontaine>it's not that it won't work, it just won't get disposed before the C++ weakcb fires
22:44:46  <trevnorris>yeah, basically.
22:44:56  <tjfontaine>so the gain you're hoping for is thwarted by one person .slice()'ing and not letting it go
22:45:03  <trevnorris>yup
22:45:04  <tjfontaine>[which is basically what happens anyway]
22:45:35  <tjfontaine>personally I think it's impolite for someone else to free that memory if someone thinks (wrongly or not) that they may want to use it later
22:45:40  <trevnorris>the main use case is for when data comes in from say a tcp request, and we just need to write it to disk or pipe is somewhere.
22:45:50  <trevnorris>that way we can immediately clean it up.
22:46:00  <tjfontaine>ya, so long as you have a well behaved application you can release pressure from the gc
22:46:03  <trevnorris>initial perf tests show a 20% in throughput
22:46:07  <trevnorris>exactly
22:46:14  <tjfontaine>I GetIt(tm)
22:46:32  <tjfontaine>but, all it takes is one stream pass through to hold on longer than you want it to
22:46:34  <trevnorris>it's for the more high performance needs, like walmart (if I understand walmart's needs...)
22:46:53  <trevnorris>how do you mean?
22:47:37  <tjfontaine>assume you use a module for protocol parsing, or progress bar, and it does something "wrong" with the buffer as its passing through (waiting for a _flush or whatever)
22:47:46  <tjfontaine>[well a slice]
22:47:47  * dshaw_quit (Read error: Connection reset by peer)
22:48:11  <tjfontaine>and you signal your intent later to .dispose() that passthrough you're .pipe'ing through has fucked you :)
22:48:59  * AvianFlu_joined
22:49:15  * c4milojoined
22:49:19  <trevnorris>the first case would have prematurely released your data, the later would just have left it to gc
22:49:32  <tjfontaine>yes
22:49:54  * bradleymeckquit (Quit: bradleymeck)
22:50:00  * AvianFlu_quit (Remote host closed the connection)
22:50:30  <trevnorris>oy, then it starts to get complicated with things like an "i'm active" flag that'll be toggled when it's passed though a stream or what not.
22:50:53  <tjfontaine>right, so, for well behaved stacks, this works out really good for them
22:51:29  <tjfontaine>presuming they own the whole stack and/or know exactly how each module uses any buffers they pass to/thru
22:51:48  <tjfontaine>in the worst case, it behaves exactly as it does today
22:52:14  <trevnorris>yeah
22:52:38  * AvianFluquit (Ping timeout: 240 seconds)
22:52:43  <tjfontaine>but it only takes 1 slice that isn't also .dispose()'d for you to lose
22:53:03  <trevnorris>well, loose as in be back where you were.
22:53:14  <tjfontaine>lose any benefit from the api
22:53:20  <trevnorris>yeah
22:53:43  <tjfontaine>anyway, I'm much happier with the way it works now considering it won't dispose if there are "active" slices
22:53:55  <trevnorris>cool.
22:54:08  <tjfontaine>is ArrayBuffer.neuter a first class js method?
22:54:13  <trevnorris>nope
22:54:22  <tjfontaine>k
22:54:29  <trevnorris>that'd be nice though
22:55:29  <trevnorris>on the side, a module of TooTallNate gave me an idea. it's costly to constantly get the c++ instance of whatever (e.g. TCPWrap) from the js object.
22:55:48  <tjfontaine>to get _handle?
22:56:02  <trevnorris>no, the Unwrap<T>
22:56:07  <tjfontaine>oh ok
22:56:14  <trevnorris>_handle is the Persistent<T> of the js object
22:56:16  <trevnorris>other way around
22:56:29  <tjfontaine>I wasn't sure where we were talking
22:56:52  <trevnorris>so the crazy idea is what if we just wrote the memory address of the class instance to the object
22:57:02  <trevnorris>it's a lot faster to attach external memory
22:57:17  <trevnorris>and reading out that is practically a noop compared to reading out a js object's properties
22:57:29  <tjfontaine>you mean an External?
22:57:57  <trevnorris>TooTallNate: what's your module that will return the memory address of a c++ class?
22:58:02  <tjfontaine>ref
22:58:07  <trevnorris>ah, ok.
22:58:13  <TooTallNate>trevnorris: ref does it
22:58:20  <TooTallNate>adds Buffer#address()
22:58:28  <TooTallNate>damnit tj :p
22:58:31  <tjfontaine>:P
22:58:36  <TooTallNate>always beating me
22:58:51  <trevnorris>so, you could ->SetIndexedPropertiesToExternalArrayData(size_t, ..., 0);
22:59:01  <trevnorris>so it'd be safe and untouchable from js
22:59:12  <tjfontaine>isn't that basically what an External is?
22:59:15  <trevnorris>but then you could get the actual memory address via GetIndexedPropertiesExternalArrayData
22:59:32  <trevnorris>but you have to attach an external like a normal js object property
22:59:37  <trevnorris>which is what's most expensive
22:59:58  <tjfontaine>well you can just pull it off in js, and pass it down
23:00:57  <trevnorris>problem is the transversal after an async request (e.g. ConnectWrap in tcp_wrap)
23:01:10  <trevnorris>coming from c++ you'd have to go out to js to get it back.
23:01:31  <trevnorris>wait... going backwards here.
23:03:21  <othiym23>point of fact: I don't have a CS degree
23:03:31  <tjfontaine>thanks for lagging out freenode.
23:03:45  <othiym23>something my dad likes to remind me of on a frequent basis, as he footed the bill for the five years I spent in school without a degre
23:03:47  <othiym23>e
23:03:54  <tjfontaine>othiym23++
23:04:06  <tjfontaine>trevnorris: I'd be interested to see the numbers
23:04:10  * MI6quit (Ping timeout: 245 seconds)
23:04:20  * MI6joined
23:04:41  <trevnorris>othiym23: haha, well we can start a club. though I only made it 2 years
23:05:24  * sblomquit (Ping timeout: 240 seconds)
23:05:26  * st_lukequit (Remote host closed the connection)
23:05:37  <trevnorris>tjfontaine: think it'd make the most difference in crypto. other than that it's mainly used with OnConnection.
23:05:52  <trevnorris>and i'm pretty sure that's not the bottleneck with http incoming requests.
23:05:58  <TooTallNate>trevnorris: othiym23 and me only 1 year!
23:06:11  <trevnorris>hah
23:08:36  * Somebody_quit (Remote host closed the connection)
23:12:39  * st_lukejoined
23:13:57  <trevnorris>othiym23: think I understand what you're getting at. if I can in one sentence, you want to keep track of the call stack call stack through all async requests. that about sum it up?
23:23:47  * paulfryzeljoined
23:25:23  * c4miloquit (Remote host closed the connection)
23:28:21  * paulfryzelquit (Ping timeout: 256 seconds)
23:29:06  * indexzeroquit (Quit: indexzero)
23:29:58  <trevnorris>tjfontaine: there're things that'll run async in the background w/o you knowing them, and that don't have a callback when they're done writing. like writing to a file stream.
23:30:21  <trevnorris>tjfontaine: problem w/ that is if they dispose in the middle of the threaded operation they're screwed.
23:30:43  <tjfontaine>i feel like I fell into an out of context conversation
23:30:57  <tjfontaine>so
23:31:06  <tjfontaine>fs.write(foo); foo.dispose();
23:31:15  <tjfontaine>where that writereq hasn't yet finished?
23:31:22  <trevnorris>and say foo is like 1GB so it's going to take a while.
23:31:28  * sblomjoined
23:31:49  <trevnorris>it's being written in a separate thread, while at the same time you run .dispose() it's going to free the memory in the middle of writing
23:32:08  <tjfontaine>ya, since we don't copy across calls there it could be a race, we could do an implicit splice/dispose along those paths
23:32:50  <trevnorris>ah, nice possible solution.
23:40:16  <othiym23>trevnorris: something like that, but more I want the context that comes with it so I can attach data to it and fetch it later
23:40:50  <othiym23>I want request-specific data that isn't tied to an object
23:41:28  <othiym23>what I *really* want are Reader, Writer and State monads, but Node isnt' going to magically turn into Haskell
23:41:51  <tjfontaine>*magic*
23:44:55  <trevnorris>simple enough in concept I guess, but can't imagine how that'd be done w/o adding a crap ton of internal work that'll make things slow. not saying it can't be done, just not easily apparent.
23:46:43  <trevnorris>i mean, there's all ready too much going on with async requests. have to instantiate a c++ class, create a persistent instance of the object, set some object properties, then dereference it all on the return
23:47:17  * felixgequit (Quit: felixge)
23:47:28  <othiym23>really all my current proposal is is a generalized version of domains
23:47:53  <othiym23>and the only way it's more costly than domains is in the need to capture a set of contexts at asynchronous boundaries rather than one
23:48:21  <othiym23>I'm going to try to get the MakeCallback changes in over the next few days, and then it may take me a little longer to rework domains to run atop this
23:48:45  <othiym23>but it's always been important to me that this take advantage of all the performance-tuning work you put into domains in 0.10
23:48:47  <mikeal>wasn't that where we started?
23:49:09  <mikeal>when isaacs took over the domains stuff i think he was trying to get it in MakeCallback
23:49:11  <othiym23>and to not change the API or properties used by domains
23:49:18  <othiym23>mikeal: domains is, this new thing isn't
23:49:20  <mikeal>and said something along the lines of "touching that in any way destroys performance"
23:49:24  <othiym23>domains are?
23:51:17  <trevnorris>mikeal: it was moved back to c++. the js implementation was too slow. then I spent 2 weeks performance tuning the whole thing.
23:51:42  <mikeal>wow, didn't know that
23:51:56  <othiym23>trevnorris: this is that thing I was talking to you about at the Mozilla meetup ;)
23:52:03  <othiym23>it clearly hasn't gotten any easier to explain
23:52:11  <trevnorris>hah, no it hasn't.
23:53:03  <trevnorris>othiym23: and it's not going to get any easier. you read my post about people complaining about the perf hit after loading the domain module, but it's like they don't realize that's how it was before :P
23:53:31  <othiym23>yeah, well, to me that's just a challenge to make domains (or the mechanism they're based on) faster
23:53:52  <mikeal>forrest likes challenges :)
23:53:58  <othiym23>because I *want* people using domains in performance-critical code, because error-handling in Node without it is kind of a disaster
23:54:28  <othiym23>mikeal: I'm really lazy once you get to know me
23:54:30  <mikeal>i challenge you to make my talk for NodeConf.eu for me. and… go!
23:54:46  * defunctzombiechanged nick to defunctzombie_zz
23:55:03  <mikeal>laziness is a virtue, it keeps you from spending time on cleverness
23:55:23  <othiym23>I expend most of my cleverness trying to find new ways to be lazy
23:55:38  <othiym23>maaan, I am sooo bummed I can't do nodeconf.eu
23:55:54  <othiym23>missing JSConf and NodeConf.eu are going to be my two big regrets for the year for sure
23:56:04  <trevnorris>hehe, you're a funny one. domains in performance-critical code. if you manage all the features you want and have it perform within the margin of error i'll bow down to you ;)
23:56:22  <othiym23>but I gotta ship this thing before my bosses shove me in a cannon and fire me out of it in the direction of Oakland
23:57:41  <tjfontaine>how do you guys do this on python and ruby?
23:57:45  <isaacs>othiym23, trevnorris: I am also in the "5 years, no degree" club
23:57:54  <isaacs>othiym23: but i split the bill with the state of Connecticut
23:58:08  <othiym23>tjfontaine: simple, we don't handle asynchronous execution in them
23:58:20  <tjfontaine>othiym23: right, ok
23:58:27  <mikeal>i have yet to be in a scenario where performance is more critical than stability
23:58:33  <othiym23>tjfontaine: and when we do (e.g. for Twisted and Tornado), we cheat and wrap the futures they use so we have control over the context
23:59:09  <othiym23>trevnorris: depends on your definition of performance-critical, I guess -- I've never even benchmarked the beta build of the agent, and while there's use cases where it's not appropriate (e.g. Voxer), I've never had a beta tester complain about the overhead it imposes
23:59:12  <mikeal>yeah, but then all kinds of aweful things happen when people use threads in libraries you call out to that you didn't know about
23:59:37  <tjfontaine>there's Performance, and then "performance"