00:05:30  * isaacs_mobilequit (Remote host closed the connection)
00:28:24  <CIA-108>node: Mike Morearty v0.8 * r19aa05f / doc/api/child_process.markdown : doc: fix bug in child_process.spawn() sample code - http://git.io/IvYvsQ
00:34:38  <tjfontaine>bah, damn pipes!
00:35:42  * bnoordhuisjoined
00:35:50  <tjfontaine>bnoordhuis: always have to find holes
00:36:06  <bnoordhuis>sorry :)
00:36:20  <tjfontaine>comments on the rest of it though?
00:37:11  <bnoordhuis>tjfontaine: still reading it
00:37:23  <tjfontaine>k
00:37:31  <tjfontaine>hmm tty_wrap has unref but no ref
00:37:54  <bnoordhuis>tjfontaine: yeah, that's more or less intentional
00:38:16  <bnoordhuis>we may have to revisit that someday but for now i'm fine with leaving it as it is
00:38:24  <tjfontaine>ok
00:40:36  <tjfontaine>hmm pipe_wrap has unref, should it get ref? I presume pipe unref has to do with child process as well
00:43:25  <mmalecki>hey, I'm having problems with compiling my branch of node, log isn't really useful: https://gist.github.com/8ea57a4c3e95c5e2119f my commit is: https://github.com/mmalecki/node/commit/eb4d73ae52e06d95b7785f4d2093ba323606100b
00:45:19  <bnoordhuis>tjfontaine: it's because stdio can be pipes
00:45:44  <bnoordhuis>mmalecki: --without-dtrace?
00:45:45  <kohai>mmalecki has 100 shots
00:45:50  <bnoordhuis>hah
00:45:58  <tjfontaine>bnoordhuis: right, ok
00:46:07  <bnoordhuis>mmalecki: i think dtrace is broken now anyway
00:46:38  <mmalecki>bnoordhuis: hah, no, my changes actually involve dtrace
00:46:48  <mmalecki>so I explicitely enable dtrace
00:46:51  <mmalecki>please see my commit
00:48:12  <tjfontaine>I'm guessing there's more to extending the datastructure there
00:51:49  <mmalecki>well, that's likely, but I don't know where is it
00:52:46  * joeandaverdejoined
00:57:31  * chobi_e_changed nick to chobi_e
01:06:56  <tjfontaine>hmm I'm not entirely sure how to test pipe
01:11:51  * joeandav_joined
01:15:27  * joeandav_quit (Remote host closed the connection)
01:21:04  * beachdogquit (Quit: beachdog)
01:31:46  <bnoordhuis>tjfontaine: net.Server().listen(common.PIPE)?
01:47:02  * bnoordhuisquit (Read error: Operation timed out)
01:50:14  * abraxasjoined
01:53:50  * chobi_echanged nick to chobi_e_
01:56:59  * abraxasquit (Remote host closed the connection)
01:57:13  * abraxasjoined
02:08:08  * piscisaureus_joined
02:18:20  * piscisaureus_quit (Ping timeout: 252 seconds)
02:24:26  * piscisaureus_joined
02:24:43  * piscisaureus_quit (Client Quit)
02:34:29  * felixgejoined
02:34:30  * felixgequit (Changing host)
02:34:30  * felixgejoined
02:54:27  * c4milojoined
03:03:18  * Ariaquit (Remote host closed the connection)
03:07:08  * c4miloquit (Remote host closed the connection)
03:28:44  * dr34dl0ckjoined
03:31:15  * philips_quit (Excess Flood)
03:34:04  * philips_joined
03:40:34  * dr34dl0ckquit (Quit: Colloquy for iPad - http://colloquy.mobi)
04:05:01  * paddybyersjoined
04:20:18  * paddybyers_joined
04:22:59  * paddybyersquit (Ping timeout: 246 seconds)
04:22:59  * paddybyers_changed nick to paddybyers
04:46:45  * igorzijoined
04:49:00  * igorzipart
04:50:29  * ericktquit (Quit: erickt)
05:25:34  * sh1mmerquit (Quit: sh1mmer)
05:51:20  * loladirojoined
05:51:37  * loladiroquit (Client Quit)
05:54:09  * paddybyersquit (Quit: paddybyers)
06:01:23  * joeandaverdequit (Quit: joeandaverde)
06:32:32  * rendarjoined
06:38:45  * paddybyersjoined
06:54:35  * stephankquit (Quit: *Poof!*)
08:16:00  * felixgequit (Quit: felixge)
08:41:43  * hzjoined
09:57:10  * abraxasquit (Remote host closed the connection)
10:02:54  * mmaleckiquit (Ping timeout: 246 seconds)
11:43:58  * perezdquit (*.net *.split)
11:43:58  * toothrotquit (*.net *.split)
11:43:58  * voodootikigodquit (*.net *.split)
11:45:20  * perezdjoined
11:45:20  * toothrotjoined
11:45:20  * voodootikigodjoined
12:08:26  * hzquit (Ping timeout: 272 seconds)
12:13:33  * hzjoined
12:19:12  * hzquit (Ping timeout: 272 seconds)
12:21:11  * hzjoined
12:42:44  <einaros>paddybyers: I'm handling that CloseEvent thing now
12:42:59  <paddybyers>einaros: perfect, thanks
12:43:13  <einaros>train wifi ftw
12:45:54  <einaros>the woman next to me having the world's smelliest feet: massive train failure
12:50:07  * beachdogjoined
13:08:57  <einaros>paddybyers: pushed
13:09:36  <paddybyers>einaros: thanks
13:10:51  * beachdogquit (Quit: beachdog)
14:06:14  * hzquit (Ping timeout: 272 seconds)
14:10:26  * hzjoined
14:25:57  * c4milojoined
14:26:48  * xaqjoined
14:27:07  * bnoordhuisjoined
14:56:28  <indutny>heya
14:59:26  * hzquit (Ping timeout: 272 seconds)
15:03:06  * chobi_e_changed nick to chobi_e
15:08:05  * AvianFlujoined
15:27:47  * dapjoined
15:41:43  <indutny>bnoordhuis: how are you?
15:42:53  <bnoordhuis>indutny: splendid. you?
15:43:01  <indutny>wasted :D
15:43:15  <indutny>two sleepless nights with ICFPC'12 competition
15:43:40  <bnoordhuis>icfpc?
15:43:46  <indutny>icfpcontest2012.wordpress.com
15:44:22  <indutny>allthough it wasn't really interesting we hadn't written really good solution for it
15:44:53  <indutny>oh
15:44:58  <indutny>s/wasn't/was/g
15:48:46  * beachdogjoined
15:57:20  * perezdquit (Quit: perezd)
15:59:58  * dapquit (Quit: Leaving.)
16:00:20  <beachdog>I'm looking for an event loop lib for my C++ program which will need N event loops ( 1,000 < N < 5,000 ) running in n Threads ( n < N, i.e. one thread will need to service multiple event loops). Would libuv be a good choice, or not? I thought I'd heard something about not handling multithreading cases….
16:00:39  * dapjoined
16:01:13  <bnoordhuis>beachdog: you can if you have one event loop per thread
16:01:27  <indutny>how would you like to use multiple eventloops in one?
16:01:31  <indutny>s/one/one thread
16:01:59  * stephankjoined
16:02:42  <bnoordhuis>i'm not sure if multiple event loops in one thread will work
16:03:02  <bnoordhuis>it's not an issue on unices but the windows event dispatch mechanism works in strange and inexplicable ways
16:03:09  <beachdog>Well, I would like to have many (that's my N) independent contexts. However, I do not want to start that many threads. I would instead want to have a pool of worker threads to service event loops. But therefore one worker thread might be assigned some number of event loops to service. (I'm not saying this is possible using libuv, or any other library for that matter, just how I am picturing it now)
16:03:43  <beachdog>also, I don
16:03:56  <beachdog>also I don't care about windows that much
16:04:09  <bnoordhuis>okay, in that case there's no problem - it'll work
16:04:57  <beachdog>I could say that one event loop will only ever get serviced by one thread, if that helps. Its just that the thread might service multiple loops
16:06:00  <bnoordhuis>yes, that's okay
16:07:39  <beachdog>thx! Also, just wondering, if I could ask a follow up, could you give me the short-short answer on why node moved from libev to libuv? I'm just trying to research the landscape here before I pick a landing spot
16:08:05  <indutny>becase cross-platform system programming is hard
16:08:17  <bnoordhuis>beachdog: because the libev event model is pretty much incompatible with how windows works
16:08:28  <indutny>bnoordhuis: ++
16:08:29  <kohai>bnoordhuis has 20 beers
16:08:37  <indutny>bnoordhuis: longer, but more informative :)
16:08:42  <bnoordhuis>heh
16:09:07  <indutny>I wonder what is an integer value of Infinity
16:09:55  <bnoordhuis>indutny: there is none
16:10:01  <bnoordhuis>unless you have unlimited bits
16:10:23  <indutny>well, obviously
16:10:49  <indutny>I was thinking about what I'll get when doing: (Infinity)->IntegerValue() in v8
16:12:27  <bnoordhuis>not sure but i guess it's the same as casting INF to int - undefined
16:12:38  <indutny>oh, nice
16:13:02  <bnoordhuis>i stress the 'not sure' part though
16:13:12  <indutny>:)
16:13:51  <indutny>is process.hrtime() available on all platforms?
16:13:55  <bnoordhuis>yes
16:13:59  <indutny>ah, nvm
16:14:09  <bnoordhuis>the granularity may differ though
16:14:11  <indutny>I'm actually more interested in 64bit uptime
16:14:26  <indutny>I think we should use it in lib/timer.js
16:14:28  <indutny>instead of Date.now
16:14:49  * perezdjoined
16:14:50  <bnoordhuis>well...
16:14:56  <indutny>or
16:14:56  <indutny> if (diff + 1 < msecs) {
16:14:57  <indutny> list.start(msecs - diff, 0);
16:14:59  <indutny>what's that
16:15:03  <indutny>why diff + 1 ?
16:15:07  <bnoordhuis>i believe Date.now() calls gettimeofday()
16:15:09  <indutny>hm...
16:15:16  <bnoordhuis>which is nice because that's not an actual syscall on linux
16:15:17  <indutny>ah, it's ok
16:15:22  <bnoordhuis>whereas clock_gettime() is
16:15:25  <indutny>ah
16:15:27  <indutny>good
16:15:33  <indutny>still js call is slower, than syscall :)
16:15:44  <bnoordhuis>is it?
16:15:47  <indutny>so your belief doesn't really changing it :0
16:15:50  <indutny>I suppose it is
16:15:55  <bnoordhuis>benchmark!
16:16:38  <indutny>10million/sec calls
16:16:40  <indutny>Date.now()
16:16:55  <indutny>Time to benchmark clock_gettime()
16:17:27  <tjfontaine>ah man you're trying to muck with timers.js while I'm still trying to get a patch applied :)
16:17:29  <indutny>is clock_gettime() linuxish?
16:17:34  <indutny>hahah
16:17:39  <indutny>tjfontaine: you fixed that?
16:17:48  <tjfontaine>nah it's not related to that really
16:17:54  <indutny>ah, ok
16:17:55  <bnoordhuis>indutny: it's posix-ish but it's what we use on linux
16:18:22  <indutny>bnoordhuis: no such thing on osx
16:18:29  <indutny>at least, not in man
16:18:42  <bnoordhuis>indutny: no, there isn't
16:19:01  <bnoordhuis>it's awesome actually because os x is supposed to be certified posix
16:19:25  <bnoordhuis>probably just the base profile though :)
16:19:28  <indutny>:)
16:19:37  <indutny>I'll try on debian VM
16:19:39  <indutny>ah
16:19:42  <indutny>that's not the same
16:19:54  <indutny>well, you may try it ;)
16:20:25  <bnoordhuis>sure, 1 sec
16:21:41  <bnoordhuis>indutny: median of 3, Date.now() -> 0m2.008s, process.hrtime() -> 0m2.521s
16:21:50  <indutny>ah
16:22:05  <indutny>but that's not the same :)
16:22:14  <indutny>as testing in C
16:22:27  <indutny>because Date.now is supported on language level
16:22:36  <indutny>while process.hrtime() is our extension to runtime
16:22:50  <bnoordhuis>oh, sure
16:23:06  <bnoordhuis>still, i'll bet you a sixpack that gettimeofday() is faster than clock_gettime()
16:23:22  <indutny>hehe
16:23:26  <indutny>well, I'm quite sure
16:23:46  <indutny>I just think that calling Date.now from js is still slower than doing clock_gettime()
16:23:47  <indutny>;)
16:24:05  <indutny>and the only reason for it to be fast is because v8 supports it's optimization
16:24:11  <indutny>but it should be slower anyway
16:24:23  <bnoordhuis>but it isn't so there you go :)
16:24:38  <tjfontaine>haha
16:24:41  <indutny>hahaha
16:24:47  <indutny>post results :)
16:29:36  <indutny>so value of infinity is undefined
16:29:38  <indutny>really good
16:29:41  <indutny>just a random bytes
16:36:29  * philips_quit (Excess Flood)
16:36:37  * philips_joined
16:43:50  <bnoordhuis>indutny: https://github.com/joyent/node/pull/3689 <- is your patch supposed to apply to v0.8?
16:44:11  <indutny>that depends on who suppose so
16:44:14  <indutny>like, I am
16:44:16  <indutny>who else? :)
16:44:22  <indutny>isaacs: ?
16:44:36  <indutny>actually, it's a bugfix for API and security
16:45:04  <bnoordhuis>i'm glad i can pass on all the tough decisions to isaacs :)
16:45:31  <isaacs>heh
16:45:36  <isaacs>looking
16:46:18  <indutny>yeah, I like this too;
16:46:19  <isaacs>Changing the Agent API might be problematic.
16:46:23  <isaacs>for v0.8
16:46:30  <indutny>well, does it change it much?
16:46:36  <indutny>this was === global
16:46:40  <indutny>and will be equal === request
16:46:44  <indutny>and it's internal stuff, actually
16:47:21  <indutny>isaacs: that's all that we have documented for agent - http://nodejs.org/api/http.html#http_class_http_agent
16:47:29  <indutny>no createConnection!
16:48:54  <isaacs>indutny: yes, but people use it.
16:49:03  <isaacs>that's why we can't change API in a stable branch, even if it's undocumented.
16:49:14  <isaacs>indutny: at least, it has to work if the req arg is omitted
16:49:22  <indutny>won't it?
16:49:36  <indutny>that's not an argument change
16:49:47  <indutny>just change of context which wasn't really defined anywhere
16:50:02  <isaacs>ok, so, what happens if you dont' pass a req to Agent.createSocket?
16:50:27  <indutny>em...
16:50:29  <isaacs>myAgent.createConnection(name, host, port, localAddress)
16:50:35  <isaacs>er, createSocket, i mean
16:50:51  <indutny>createSocket?
16:51:00  <indutny>ah
16:51:06  <indutny>right
16:51:14  <indutny>well, nothing will happen
16:51:21  * mikealquit (Quit: Leaving.)
16:51:34  <indutny>createConnection will be called w/o context
16:51:43  <indutny>but yeah, this change looks dangerous to me too
16:51:50  <indutny>lets pull it into 0.9
16:52:06  <isaacs>is there any way to have it just not use the req if it's not passed in?
16:55:13  * ericktjoined
16:55:50  <isaacs>indutny: ^
16:57:20  <isaacs>indutny: it *would* be really nice to get this behavior into v0.8
16:58:58  * TooTallNatejoined
16:59:50  <isaacs>indutny: wait, doesn't the Agent already know what hostname it's connecting to, from the host argument?
17:00:00  <isaacs>indutny: i guess i'm not understanding why the req arg is necessary.
17:03:28  * dapquit (Quit: Leaving.)
17:03:56  * dapjoined
17:04:30  * arlolrajoined
17:07:19  <indutny>sorry
17:07:28  <indutny>I was afk
17:07:33  <indutny>actually, without internet
17:07:38  <indutny>so
17:07:41  <indutny>how is it changing API?
17:07:42  <indutny>isaacs: ^
17:08:04  <isaacs>indutny: it's adding a req argument to Agent.prototype.createSocket
17:08:26  <indutny>and?
17:08:29  <indutny>not using it
17:08:32  <indutny>if it wasn't given :)
17:08:48  <indutny>it's just passing it as a context to createConnection
17:08:49  <isaacs>indutny: what *does* it use it for?
17:09:00  <indutny>and this context is only used in tls.js
17:09:10  <indutny>to get options that was passed to https.request()
17:09:13  <indutny>otherwise we lose them
17:09:19  <indutny>and using agent ones instead
17:10:35  <isaacs>indutny: so, you call https.request(options)
17:11:18  <isaacs>then that does return new http.ClientRequest(options, cb);
17:11:58  * isaacswants to rewrite http.js so badly this is such utter trash, sorry you have to see this
17:12:13  <indutny>(offtopic, setTimeout(function() {}, Infinity) - forget about callback or add a timer with maximum int64_t value for timeout?)
17:12:23  <indutny>hahaha
17:13:39  <indutny>isaacs: ok, changing topic for a bit
17:13:42  <indutny>sorry
17:13:48  <indutny>isaacs: so about timers, what should we do?
17:13:58  <indutny>ignore this call, or add timer to queue?
17:14:01  <isaacs>which gets to var conn = options.createConnection.call(self, options);
17:14:09  <indutny>isaacs: yes
17:14:14  <indutny>and self contains agent options
17:14:17  <indutny>self.options
17:14:17  <isaacs>right
17:14:36  <isaacs>and options.createConnection is the createConnection from lib/http.js
17:14:43  <isaacs>er, https.js
17:14:49  <indutny>em...
17:14:55  <indutny>from tls
17:15:00  <indutny>ah
17:15:01  <indutny>right
17:15:06  <indutny>from https.js
17:15:07  <isaacs>which does var options = util._extend({}, this.options);
17:15:09  <indutny>and it calls tls.connect
17:15:18  <isaacs>thn sets up some other options
17:15:24  <isaacs>then does return tls.connect(options);
17:15:45  <isaacs>so... i'm not seeing where the req argument is ever relevant
17:16:08  <indutny>well, it's not
17:16:21  <indutny>but createConnection was called with different contexts in different places
17:16:33  <isaacs>can we just always call it with the Agent object?
17:16:35  <isaacs>ie, with self?
17:16:43  <isaacs>createConnection.call(this, ...)
17:16:49  <isaacs>or self or whatever it is there
17:17:35  <indutny>em...
17:17:38  <indutny>yes, we can
17:17:40  <isaacs>it seems like, for v0.8, it's not necessary, and for v0.9 the right answer is just to rip all this shit out and re-do it better from the start.
17:18:01  <indutny>but we'll need to pass Request's options somehow
17:18:22  <isaacs>when you say "request" that's the options object from https.request(thisThing, cb), right?
17:18:36  <isaacs>or a ClientRequest object?
17:19:02  <indutny>Request is ClientRequest's instance
17:19:05  <indutny>and it has options
17:19:15  <indutny>which came from http[s].request(options, cb)
17:19:16  <isaacs>var req = http.request(..); req.options = {...}?
17:19:24  <indutny>well, why not
17:19:27  <indutny>but I'm not talking about it
17:19:29  <isaacs>ok
17:20:04  <isaacs>okc
17:20:11  <isaacs>in ClientRequest this.options = util._extend({}, options);
17:22:17  <indutny>is it a question, statement, or command? :)
17:22:38  <indutny>bnoordhuis: isaacs https://github.com/joyent/node/pull/3717
17:22:49  <indutny>I'll add test in a bit
17:22:53  <isaacs>i see, and we do self.onSocket(options.createConnection.call(self, self.socketPath));
17:23:06  <isaacs>in ClientRequest
17:23:14  <isaacs>so that's why the req is the this of the createConnection method
17:24:16  <isaacs>indutny: i think we should just accept that "this" is not consistent in the options.createConnection function.
17:27:30  <isaacs>i think we can remove the req arg from Agent.prototype.createSocket(), and then it's still api-frozen, but corrects the invalid behavior.
17:27:53  * bnoordhuisis off to dinner
17:29:42  * mikealjoined
17:30:47  <indutny>isaacs: and how will I pass https.request(thisOptions) to createConnection?
17:32:02  <isaacs>indutny: you're talking about this?
17:32:02  <isaacs>function createConnection(/* [port, host, options] */) { var options = util._extend({}, this.options);
17:32:10  <indutny>yes
17:32:14  <isaacs>in lib/https.js?
17:32:16  <indutny>yes
17:32:37  <indutny>the options it gets from arguments are agent's options
17:32:46  <indutny>not the https.request(THISOPTIONS)
17:33:43  <indutny>oooh
17:33:48  <indutny>forgot that timers patch
17:33:51  <isaacs>indutny: self.createConnection(util._extend({}, req.options, this.options))
17:34:05  <isaacs>indutny: just pass in one thing all merged up
17:34:29  <isaacs>oh, wait, that's assuming you have the req in createSocket...
17:34:34  <isaacs>wtf, how does this even work now?
17:34:39  <tjfontaine>heh
17:35:23  * `3rdEdenjoined
17:35:44  <isaacs>so, if you do https.request(options, cb) today, what options don't get passed thorugh?
17:35:47  <indutny>hahah
17:35:55  <indutny>options
17:36:00  <indutny>in .request(OPTIONS, cb)
17:36:08  <isaacs>indutny: right, but i mean, what specific fields don't end up being used
17:36:10  <indutny>tls.js doesn't know about them
17:36:16  <indutny>like rejectUnauthorized
17:36:23  <isaacs>it looks like everything we pass into that function gets slapped onto the Agent anyway
17:36:31  <isaacs>ok
17:36:45  <isaacs>so https.request({rejectUnauthorized:true,host:..,port:..}, cb)
17:36:51  <isaacs>the rejectUnauthorized will get lost
17:37:08  <isaacs>and you don't want to put that on the Agent, since you might have OTHER requests to the same host/port that are not so strict.
17:37:20  * isaacssign.
17:37:23  <isaacs>*sigh
17:37:57  <isaacs>ok, if you add a test that fails today because it drops those options that are only on the req, then lgtm.
17:38:00  <isaacs>i'm convinced.
17:38:31  * felixgejoined
17:38:31  * felixgequit (Changing host)
17:38:32  * felixgejoined
17:38:37  * chobi_echanged nick to chobi_e_
17:39:08  <indutny>hahaha
17:39:12  <indutny>ok
17:39:21  * felixgequit (Client Quit)
17:39:22  <indutny>will do, but once I'll get home
17:44:00  <indutny>bbiab
17:54:22  * felixgejoined
17:54:22  * felixgequit (Changing host)
17:54:23  * felixgejoined
17:57:23  * philips_quit (Excess Flood)
17:59:37  * philips_joined
18:02:23  * felixgequit (Quit: felixge)
18:02:30  * mikealquit (Quit: Leaving.)
18:03:36  * beachdogquit (Quit: beachdog)
18:04:36  * beachdogjoined
18:04:44  * c4miloquit (Remote host closed the connection)
18:05:20  * beachdogquit (Client Quit)
18:05:45  * felixgejoined
18:05:45  * felixgequit (Changing host)
18:05:45  * felixgejoined
18:06:47  * mikealjoined
18:32:56  * mikealquit (Quit: Leaving.)
18:46:40  * EhevuTovjoined
18:48:02  * mjr__joined
18:50:07  * mikealjoined
19:03:00  <indutny>back
19:21:46  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
19:29:57  * mikealquit (Quit: Leaving.)
19:30:53  * mikealjoined
19:33:17  * mikealquit (Client Quit)
19:34:36  * mikealjoined
20:12:53  <isaacs>hola
20:13:00  <isaacs>indutny: wanna review my nextTick changes?
20:13:11  <isaacs>indutny: i posted a comment with the conclusion of our IRC discussion
20:15:03  <indutny>isaacs: hola
20:15:05  <indutny>isaacs: sure
20:15:24  <indutny>isaacs: link?
20:16:04  <isaacs>https://github.com/joyent/node/pull/3709
20:18:15  * benviejoined
20:27:52  <indutny>isaacs: lgtm
20:32:17  * mjr__quit (Read error: Connection reset by peer)
20:32:36  * mjr__joined
20:35:54  <indutny>bnoordhuis: yt?
20:37:00  <indutny>why gdb sucks on osx?
20:37:23  <tjfontaine>because it's ancient, and they're writing their own replacement
20:37:41  <tjfontaine>but what inparticular seems to be the issue?
20:38:27  <indutny>The program being debugged was signaled while in a function called from GDB.
20:38:34  <indutny>very nice
20:38:48  <indutny>running C++ code from gdb is working time to time
20:38:51  <indutny>mostly broken, though
20:39:34  <tjfontaine>can you be more specific about 'broken'?
20:39:52  <indutny>well, if something randomly works
20:40:03  <indutny>and at every other time doesn't
20:40:08  <indutny>it's broken :)
20:40:14  <tjfontaine>tahnks for being equally ambiguous
20:40:38  <tjfontaine>do you know if you're compiling with clang++ or g++?
20:41:18  <indutny>g++ I think
20:41:19  <kohai>g has 4 beers
20:41:23  <tjfontaine>you might have slightly more predictable results in gdb if you force the compililation to g++
20:41:33  <indutny>let me check
20:41:50  * beachdogjoined
20:43:14  <indutny> /usr/libexec/gcc/i686-apple-darwin10/4.2.1/cc1plus
20:43:17  <indutny>lets see
20:43:42  * hzjoined
20:43:43  <tjfontaine>well if it's node and gyp we're talking about you might also want to check c++ --version
20:44:35  <indutny>yay
20:44:36  <indutny>it works
20:44:45  <indutny>no, it's not node
20:44:49  <tjfontaine>ok
20:45:00  <tjfontaine>more specifically is it gyp :P
20:45:09  <indutny>hahaha
20:45:10  <indutny>yes
20:45:17  <indutny>should I specify GCC_VERSION?
20:45:20  <indutny>(it's candor, btw)
20:46:07  <tjfontaine>nah, but for debugging under these circumstances you might want to set CC and CXX to gcc and g++
20:46:16  <tjfontaine>or you might try delving into lldb land
20:46:20  <indutny>hm...
20:46:24  <indutny>GCC_VERSION helped too
20:46:25  <indutny>odd
20:46:31  <indutny>or is it just randomly working now :)
20:46:45  <indutny>LINK=g++ too, I suppose?
20:47:02  <tjfontaine>there's only one linker out there for now
20:47:35  <indutny>well, it fails to link without it
20:47:45  <tjfontaine>then I would say you're doing something else wrong :)
20:48:41  <indutny>hahahaha
20:48:42  <indutny>ok
20:54:27  * hzquit (Disconnected by services)
20:54:37  * hzjoined
21:00:26  * hzquit (Ping timeout: 272 seconds)
21:06:03  * hzjoined
21:07:45  * dapquit (Quit: Leaving.)
21:09:45  * beachdogquit (Quit: beachdog)
21:10:32  * davispquit (Quit: I quit!)
21:10:41  * dapjoined
21:11:12  * hzquit (Ping timeout: 272 seconds)
21:14:38  * rendarquit
21:16:16  <isaacs>indutny: oh, no.
21:16:23  <indutny>what's sup?
21:16:30  <indutny>err
21:16:30  <isaacs>indutny: found some oddness. it behaves *really* weird with process.on('uncaughtException')
21:16:35  <isaacs>indutny: this new nextTick thing
21:16:39  <indutny>oh
21:16:51  <indutny>what do you mean by *weird*?
21:18:17  <isaacs>indutny: well, it doesn't update the tickQueue, so if your module sets up a handler, then throws, it'll loop forever
21:18:25  <indutny>ooooh
21:18:29  <indutny>this thing
21:19:31  <isaacs>got a fix
21:20:12  * davispjoined
21:29:05  * paddybyers_joined
21:30:45  * EhevuTovquit (Remote host closed the connection)
21:32:10  * EhevuTovjoined
21:32:41  * paddybyersquit (Ping timeout: 246 seconds)
21:32:41  * paddybyers_changed nick to paddybyers
21:39:38  <isaacs>indutny: also, something very bad is busted with this and https now.
21:39:40  <isaacs>?(
21:39:41  <isaacs>:(
21:40:52  <indutny>hm...
21:41:36  <indutny>I think some places really expect process.on('idle')
21:41:40  <indutny>rather than nextTick
21:41:45  <indutny>brb
21:58:46  * felixgequit (Quit: felixge)
22:00:40  * EhevuTov_joined
22:01:51  * EhevuTovquit (Ping timeout: 248 seconds)
22:04:20  * AlbireoX_quit (Read error: Connection reset by peer)
22:11:16  * loladirojoined
22:24:41  <indutny>bad
22:27:15  * felixgejoined
22:27:15  * felixgequit (Changing host)
22:27:15  * felixgejoined
22:29:17  * AlbireoX_joined
22:35:25  * loladiroquit (Read error: Connection reset by peer)
22:35:33  * loladirojoined
22:38:54  * mikealquit (Quit: Leaving.)
22:42:00  <bnoordhuis>indutny: ih
22:42:07  <indutny>bnoordhuis: yeh
22:42:22  * EhevuTov_quit (Quit: Leaving)
22:50:22  * EhevuTovjoined
22:54:07  * felixgequit (Quit: felixge)
22:55:25  * beachdogjoined
22:57:34  * loladiroquit (Ping timeout: 244 seconds)
23:10:56  * mjr__quit (Quit: mjr__)
23:12:16  * mikealjoined
23:12:57  <mitsuhiko>marrying hiredis and libuv is harder than expected
23:13:07  <mitsuhiko>does anyone by any chance have a ready made adapter for it?
23:16:01  <indutny>mitsuhiko: well, if it's opensource - I can look into it
23:16:14  <mitsuhiko>indutny: i can show you what i have
23:16:40  <bnoordhuis>didn't pieter do a proof of concept a while ago? or was that with redis?
23:17:31  * mikealquit (Quit: Leaving.)
23:17:46  <mitsuhiko>that's basically what i have: https://gist.github.com/3125730
23:18:07  <mitsuhiko>but i guess the uv_prepare_ thing is not what i want. they don't seem to do anything
23:18:25  <mitsuhiko>(modelled after this: https://github.com/antirez/hiredis/tree/master/adapters)
23:27:16  <mitsuhiko>i'm just curious why my prepare callbacks are never invoked
23:29:34  <CIA-108>node: isaacs master * rb8d8615 / test/simple/test-eio-limit.js : test-eio-limit: Remove confusing broken incorrect test - http://git.io/u9wJnA
23:29:52  <bnoordhuis>mitsuhiko: redis_libuv_events *e = (redis_libuv_events *)handle->data; <- superfluous cast
23:29:56  <bnoordhuis>also, real men use container_of
23:30:20  <mitsuhiko>bnoordhuis: fair enough
23:30:35  <indutny>hahaha
23:30:40  <bnoordhuis>mitsuhiko: does redis give you a fd to poll on?
23:31:19  <mitsuhiko>bnoordhuis: redis gives you a weird callback based async interface
23:31:49  * ericktquit (Read error: Operation timed out)
23:32:10  <bnoordhuis>mitsuhiko: yeah... i confess i don't quite understand how redis is supposed to know there's i/o pending
23:33:12  <bnoordhuis>mitsuhiko: https://github.com/antirez/hiredis/blob/master/adapters/libev.h
23:33:21  <bnoordhuis>particularly https://github.com/antirez/hiredis/blob/master/adapters/libev.h#L112
23:33:37  <bnoordhuis>you want uv_poll_* for that
23:34:29  <mitsuhiko>i see
23:34:37  <mitsuhiko>wtf was i doing there anyways
23:38:15  * ericktjoined
23:38:34  <mitsuhiko>time for me to stop working on that
23:38:38  <mitsuhiko>bnoordhuis: thanks, that works
23:38:43  <mitsuhiko>question was stupid :-/
23:38:44  <bnoordhuis>cool
23:39:26  <mitsuhiko>should probably make a patch for hiredis
23:40:40  * c4milojoined
23:43:57  * c4miloquit (Remote host closed the connection)
23:46:05  * mikealjoined
23:48:14  * chobi_e_changed nick to chobi_e
23:50:25  * paddybyersquit (Quit: paddybyers)
23:52:30  <bnoordhuis>isaacs: is it conceivable that the domains stack holds on to objects longer than it should?
23:52:46  <isaacs>bnoordhuis: if it catches errors, then yes
23:52:57  <bnoordhuis>is that something to worry about?
23:53:03  <isaacs>bnoordhuis: without the change (or the early termination) that stack grows to 1000 objects
23:53:15  <isaacs>bnoordhuis: if you've explicitly added a req and res to it, then that's 1000 requests and responses.
23:53:21  <bnoordhuis>right - that'd be bad
23:53:26  <isaacs>super bad
23:53:59  <isaacs>really, it's just an oversight. didn't realize that .exit() wouldn't actually get called if it'd thrown
23:54:31  <isaacs>but, there's no way to test without exposing the stack, unfortunately
23:56:48  * beachdogquit (Remote host closed the connection)
23:57:00  * beachdogjoined
23:58:45  <isaacs>bnoordhuis: also, there are some pretty subtle bugs in the "move makecallback to js" commit. i'm basically just re-doing from the start, with this domain stack thing as well
23:59:59  * dapquit (Quit: Leaving.)