00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:09:10  * tjholowaychukquit (Quit: Linkinus - http://linkinus.com)
00:09:36  * bnoordhuisjoined
00:12:23  * amartensquit (Quit: Leaving.)
00:14:07  * bnoordhuisquit (Ping timeout: 240 seconds)
00:22:31  * dshaw_joined
00:26:28  * kevinswiberjoined
00:33:43  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:35:51  * julianduquequit (Ping timeout: 245 seconds)
00:37:27  * CoverSlide1quit (Quit: CoverSlide1)
00:39:16  * julianduquejoined
00:46:14  * st_lukequit (Remote host closed the connection)
00:51:20  * dshaw_quit (Quit: Leaving.)
00:55:55  * TooTallNatejoined
01:01:32  * dshaw_joined
01:04:26  * groundwaterquit (Quit: groundwater)
01:05:37  * groundwaterjoined
01:06:59  * dshaw_quit (Quit: Leaving.)
01:13:55  * amartensjoined
01:24:49  * TooTallNatequit (Read error: Connection reset by peer)
01:34:44  * dominictarrquit (Quit: dominictarr)
01:47:23  * dapquit (Quit: Leaving.)
02:02:01  * TooTallNatejoined
02:06:11  * st_lukejoined
02:46:47  * st_lukequit (Remote host closed the connection)
02:49:32  * amartensquit (Quit: Leaving.)
03:01:22  * amartensjoined
03:04:03  * amartensquit (Client Quit)
03:09:51  * defunctzombiechanged nick to defunctzombie_zz
03:10:40  * defunctzombie_zzchanged nick to defunctzombie
03:40:10  * EhevuTovjoined
03:43:15  * jmar777joined
03:50:14  * tjholowaychukjoined
04:01:11  * kevinswiberquit (Remote host closed the connection)
04:04:35  * EhevuTovquit (Quit: This computer has gone to sleep)
04:11:00  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:22:47  * jmar777quit (Remote host closed the connection)
04:35:55  * tjholowaychukquit (Quit: Linkinus - http://linkinus.com)
05:03:11  * amartensjoined
05:13:09  * julianduquequit (Quit: leaving)
05:42:28  * pachetquit (Quit: [ +++ ])
05:59:51  * amartensquit (Quit: Leaving.)
06:08:40  * brsonquit (Quit: leaving)
06:25:27  * rendarjoined
06:42:25  <MI6>nodejs-v0.10-windows: #184 UNSTABLE windows-x64 (7/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/184/
07:01:00  * emilsedgh_quit (Read error: Operation timed out)
07:01:51  * Cr8joined
07:02:46  * nsm_joined
07:03:55  * emilsedghjoined
07:04:38  * brucem_joined
07:09:17  * mralephjoined
07:11:25  * mraleph1quit (*.net *.split)
07:11:26  * brucemquit (*.net *.split)
07:11:26  * nsmquit (*.net *.split)
07:11:26  * Apage43quit (*.net *.split)
07:11:27  * nsm_changed nick to nsm
07:11:27  * Cr8changed nick to Apage43
07:21:06  * defunctzombiechanged nick to defunctzombie_zz
07:28:27  * defunctzombie_zzchanged nick to defunctzombie
07:30:43  * TooTallNatejoined
07:38:09  * defunctzombiechanged nick to defunctzombie_zz
07:43:34  * emilsedghquit (Changing host)
07:43:34  * emilsedghjoined
07:45:36  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
07:50:21  * defunctzombie_zzchanged nick to defunctzombie
08:04:34  * dominictarrjoined
08:09:30  * defunctzombiechanged nick to defunctzombie_zz
08:14:12  * groundwaterquit (Quit: groundwater)
08:15:49  * `3rdEdenchanged nick to `3E|GONE
08:28:30  * tuxie_joined
08:55:38  * hzjoined
08:59:56  * hzquit (Disconnected by services)
09:00:02  * hzjoined
09:36:49  * bnoordhuisjoined
09:55:23  * hzquit
10:05:54  * dominictarrquit (Quit: dominictarr)
10:06:23  * bnoordhuisquit (Ping timeout: 245 seconds)
10:35:48  * dominictarrjoined
10:46:01  <MI6>nodejs-v0.10: #1456 UNSTABLE osx-ia32 (1/598) smartos-x64 (2/598) linux-ia32 (1/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1456/
10:56:47  * rendarquit (Ping timeout: 260 seconds)
10:59:21  * rendarjoined
11:13:00  * bnoordhuisjoined
11:16:43  * Damn3dquit (Ping timeout: 264 seconds)
11:17:13  * bnoordhuisquit (Ping timeout: 245 seconds)
11:19:54  * Damn3djoined
11:50:46  * hzjoined
11:53:39  * bnoordhuisjoined
12:26:46  * ecrjoined
12:27:04  * ecrquit (Client Quit)
12:33:31  * Damn3dquit (Ping timeout: 264 seconds)
12:43:26  * Damn3djoined
13:10:57  * migounettejoined
13:12:56  * migounettequit (Client Quit)
13:54:08  * sindresorhusjoined
13:59:38  * pachetjoined
14:14:39  * kenperkinsjoined
15:05:12  * kenperkinsquit (Quit: Computer has gone to sleep.)
15:17:42  <MI6>nodejs-master: #513 UNSTABLE linux-ia32 (1/642) smartos-x64 (7/642) linux-x64 (2/642) http://jenkins.nodejs.org/job/nodejs-master/513/
15:46:12  * kevinswiberjoined
15:48:40  * hzquit (Disconnected by services)
15:48:44  * hzjoined
15:58:26  * bnoordhuisquit (Ping timeout: 268 seconds)
16:38:51  * defunctzombie_zzchanged nick to defunctzombie
16:42:53  * defunctzombiechanged nick to defunctzombie_zz
16:49:07  * bnoordhuisjoined
16:49:56  * dshaw_joined
16:53:17  * tuxie_quit (Ping timeout: 240 seconds)
16:59:57  * defunctzombie_zzchanged nick to defunctzombie
17:00:55  * kevinswiberquit (Remote host closed the connection)
17:06:30  * kevinswiberjoined
17:08:50  * kevinswiberquit (Remote host closed the connection)
17:21:24  * kevinswiberjoined
17:22:07  * kevinswiberquit (Remote host closed the connection)
17:23:32  <creationix>othiym23, ping
17:24:36  <creationix>trevnorris, ping
17:30:24  <creationix>othiym23, I'm going to implement process.addAsyncListener(onAsync, callbackObject); in cls-glue. That's still the API for what core will do right?
17:37:28  * TooTallNatejoined
17:38:42  <MI6>joyent/node: isaacs v0.10 * 01f3b46 : benchmark: Support passing v8 flags to benchmarks - http://git.io/mCcqzQ
17:40:26  * dshaw_quit (Quit: Leaving.)
17:41:03  * kevinswiberjoined
17:43:17  * mikealjoined
17:46:29  <MI6>nodejs-v0.10: #1457 UNSTABLE smartos-x64 (2/598) http://jenkins.nodejs.org/job/nodejs-v0.10/1457/
17:50:03  <kellabyte>bnoordhuis: I get a segfault after uv_async_send calls my callback, line 164 of async.c = wa->cb(loop, wa, n);
17:50:15  <kellabyte>bnoordhuis: any ideas? my printf in the callback does happen
17:51:12  * kevinswiberquit (Remote host closed the connection)
17:53:58  <MI6>nodejs-v0.10-windows: #185 UNSTABLE windows-x64 (7/598) windows-ia32 (7/598) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/185/
17:54:20  * kevinswiberjoined
17:55:16  <MI6>libuv-master: #210 UNSTABLE windows (3/194) smartos (9/193) http://jenkins.nodejs.org/job/libuv-master/210/
17:56:08  * dominictarrquit (Quit: dominictarr)
17:56:39  * dominictarrjoined
17:58:20  <bnoordhuis>kellabyte: do you have example code?
17:58:41  <bnoordhuis>or code i can look at in general
18:00:13  <kellabyte>bnoordhuis: I can! hold on
18:04:26  * kevinswiberquit (Remote host closed the connection)
18:04:38  <kellabyte>bnoordhuis: lines of interest: https://gist.github.com/kellabyte/6399734#file-http_response_cache-c-L34 and https://gist.github.com/kellabyte/6399734#file-http_response_cache-c-L85
18:07:01  <creationix>trevnorris, othiym23, how does the error hook work with multiple listeners. Does it simply not catch the error if there is at least one error handler?
18:08:51  <MI6>libuv-node-integration: #194 UNSTABLE smartos-x64 (7/642) linux-x64 (2/642) linux-ia32 (1/642) http://jenkins.nodejs.org/job/libuv-node-integration/194/
18:24:43  <bnoordhuis>kellabyte: you need to call uv_async_init() on the thread that the event loop runs in
18:25:59  <kellabyte>bnoordhuis: ah!
18:26:25  <bnoordhuis>kellabyte: if you create the async handle after the event loop is running, well, anything could happen
18:26:39  <bnoordhuis>though probably not much good
18:29:46  <kellabyte>ah ok lemme rework this, I was trying to make a self contained thing
18:30:10  <MI6>joyent/node: isaacs master * cece100 : Merge remote-tracking branch 'ry/v0.10' (+1 more commits) - http://git.io/jbltkA
18:31:03  <isaacs>bnoordhuis: why'd the libuv close/exit stuff get reverted?
18:31:25  <isaacs>bnoordhuis: oh, nvm, just saw the scrollback
18:31:45  <isaacs>bnoordhuis: what's weird is that my test is still passing that those commits fixed...
18:35:48  * groundwaterjoined
18:35:50  * bnoordhuisquit (Ping timeout: 240 seconds)
18:39:15  <MI6>nodejs-master: #514 UNSTABLE linux-ia32 (1/642) smartos-x64 (7/642) linux-x64 (1/642) http://jenkins.nodejs.org/job/nodejs-master/514/
18:45:56  <MI6>nodejs-master-windows: #306 UNSTABLE windows-x64 (15/642) windows-ia32 (16/642) http://jenkins.nodejs.org/job/nodejs-master-windows/306/
18:47:36  * defunctzombiechanged nick to defunctzombie_zz
18:51:30  * kenperkinsjoined
18:51:44  * defunctzombie_zzchanged nick to defunctzombie
18:55:10  * kenperkinsquit (Client Quit)
19:05:23  <MI6>nodejs-master-windows: #307 UNSTABLE windows-x64 (14/642) windows-ia32 (16/642) http://jenkins.nodejs.org/job/nodejs-master-windows/307/
19:07:24  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
19:13:39  <creationix>othiym23, trevnorris here is an example of how CLS would be implemented on top of process.addAsyncListener https://gist.github.com/creationix/d531157ad587a4af9f4e#file-multi-cls-js-L9-L14
19:16:30  * `3E|GONEchanged nick to `3rdEden
19:26:08  * kenperkinsjoined
19:27:42  * kevinswiberjoined
19:30:20  * kenperkinsquit (Client Quit)
19:31:20  * kevinswiberquit (Remote host closed the connection)
19:32:29  * bnoordhuisjoined
19:32:43  * AvianFlujoined
19:44:42  <indutny>bnoordhuis: hey man
19:44:42  <indutny>yt?
19:46:06  <indutny>bnoordhuis: how reliable is uv_cancel() ?
19:46:55  <bnoordhuis>indutny: define 'reliable'?
19:47:00  <indutny>well
19:47:02  <indutny>I've a server
19:47:06  <indutny>and I'm doing following this
19:47:08  <indutny>uv_cancel(req)
19:47:19  <indutny>uv_close(handlle, callback_that_free_structure_containing_req)
19:47:27  <indutny>but it seems that req's callback is invoked with zero status
19:47:36  <indutny>after callback_that_free_structure_containing_req
19:47:49  <bnoordhuis>uv_cancel() only cancels when the req is still in the pending queue
19:48:02  <bnoordhuis>if it's already executing (or has been executed), it won't cancel anything
19:48:25  <bnoordhuis>if it does cancel, it calls your req cb with status=UV_ECANCELED
19:48:41  <indutny>hm...
19:48:52  <kellabyte>bnoordhuis: can you only do one async handle per loop or something? if I comment out this uv_async_init() my http requests work but when I add it they stop
19:49:08  <bnoordhuis>kellabyte: you can have as many async handles as you like
19:49:10  <indutny>bnoordhuis: so after_work will could be executed with non-zero status even if the work was cancelled?
19:49:18  <indutny>how could I figure it out?
19:49:49  <bnoordhuis>indutny: no, if it's been executed, status==0. if it's been cancelled, status=UV_ECANCELED
19:50:03  <bnoordhuis>any other status means somethings badly wrong
19:50:15  <indutny>so...
19:50:26  <kellabyte>bnoordhuis: strange, if I leave the new uv_async_init() in a previous one stops working, if I comment it out, the previous one works
19:50:27  <indutny>after uv_cancel() call it *must* be UV_ECANCELED, right?
19:50:30  <indutny>in any case
19:50:31  <bnoordhuis>no
19:50:53  <bnoordhuis>only _iff_ the req wasn't actually executing
19:51:42  <bnoordhuis>when you create a work req, it first goes into the pending work queue
19:51:44  <indutny>I can't figure it out
19:51:46  <indutny>yeah
19:51:54  <bnoordhuis>that's when you can still cancel it
19:51:59  <indutny>oh gosh
19:52:09  <bnoordhuis>once a worker pops it off the queue, it's no longer cancellable
19:52:13  <indutny>will I get negative result from uv_cancel in such case?
19:52:48  <bnoordhuis>yes, it returns UV_EBUSY
19:52:54  <indutny>interesting
19:53:01  <bnoordhuis>it is, isn't it?
19:53:04  <indutny>ok, I need to consider it :)
19:54:05  <bnoordhuis>kellabyte: what you probably want to do is 1) spawn a worker thread, 2) create the async handle in the worker thread, 3) sync the main thread and the worker thread with e.g. a semaphore, 4) call uv_run() in the worker thread
19:54:34  <indutny>bnoordhuis: another question
19:54:40  <indutny>what does -22 return value mean on linux :)
19:55:06  <indutny>ah, invalid arg
19:55:07  <kellabyte>bnoordhuis: thats a lot of indirection when all I want to do is tell the thread with the event loop to be aware to do something in its TLS, at the end of the day I just want a flag or signal
19:55:11  <indutny>no good
19:55:40  <bnoordhuis>start the dance
19:55:48  <bnoordhuis>(probably from before your time)
19:56:07  <bnoordhuis>kellabyte: that's threads and c for you
19:56:32  <kellabyte>bnoordhuis: I don't get why I need 3 threads to set a flag? thats nuts
19:57:07  <bnoordhuis>kellabyte: well, you want to have worker threads that you can wake up as needed, right?
19:57:16  <kellabyte>no
19:57:30  <bnoordhuis>if you just want them to check a flag, create a timer for each event loop and check the flag in the callback
19:57:59  <bnoordhuis>that's polling which is arguably not a great architecture but it will do in a pinch
19:58:17  <indutny>bnoordhuis: ok, I think I have an idea :)
19:58:23  <bnoordhuis>i should add more commas to my sentences
19:58:44  <bnoordhuis>run-on sentences is one thing but run-on sentences without commas is another thing entirely
19:58:52  <bnoordhuis>^ point in case
19:58:57  <bnoordhuis>indutny: tell me
19:59:01  <indutny>no way
19:59:03  <kellabyte>I have 3 threads that handle HTTP requests, they store a cache each in their TLS, once per second I want to tell each one to flush their cache in the next HTTP request they take, so I created a timer on the main event loop (independant from the 3 request handler loops)
19:59:39  <kellabyte>kellabyte: and in that timer, I send an uv_async_send() to each one
20:00:19  <bnoordhuis>talking to yourself now, kellabyte? :)
20:00:25  <kellabyte>bnoordhuis: oops haha
20:01:18  <bnoordhuis>kellabyte: okay, i guess the pertinent question is: does the main thread need to drive those checks or can the workers take care of it themselves?
20:01:45  <bnoordhuis>when it's the main thread that needs to drive things, you need synchronization and a way to make wake-up calls to threads that are sleeping
20:01:51  <kellabyte>bnoordhuis: depends, what's the cost if I'm on a 32, 64 or 128 core machine?
20:01:52  <bnoordhuis>that's where async handles come in
20:02:15  <bnoordhuis>kellabyte: the cost of what? a wakeup?
20:02:17  * AvianFluquit (Remote host closed the connection)
20:02:18  <kellabyte>yeah, the async handle _works_ except now my http requests fail, so I dunno whats messed up there
20:02:27  <kellabyte>bnoordhuis: of having like 128 timers for each loop
20:02:39  <kellabyte>bnoordhuis: 1 timer sounds better, no?
20:03:00  <bnoordhuis>when you have 128 cores, you'd have 128 threads with one event loop each, right?
20:03:10  <bnoordhuis>i'm getting the hang of commas again
20:03:15  <kellabyte>haha
20:03:31  <kellabyte>bnoordhuis: I'm not sure I want to introduce 128 timer threads though (is that what happens?)
20:03:37  <bnoordhuis>no
20:03:38  * TooTallNatejoined
20:03:45  <bnoordhuis>okay, let's take a step back
20:03:48  <kellabyte>ok :)
20:03:56  <bnoordhuis>there are two approaches to what you want to do
20:04:07  <bnoordhuis>you can either have the main thread wake up workers threads on a need-to basis
20:04:20  <bnoordhuis>or each worker thread can start a timer and do whatever when it fires
20:04:26  <bnoordhuis>agreed?
20:04:30  <kellabyte>yups
20:04:40  <bnoordhuis>okay. then the question is: what approach do you need?
20:04:48  <bnoordhuis>async handles are cheap, timers are even cheaper
20:05:14  <kellabyte>ok, so maybe timers are the way to go then?
20:05:32  <bnoordhuis>probably, maybe. it's your code, your the best judge of that
20:05:58  <kellabyte>ok. I'm still concerned as a learner that my code is wrong somewhere cuz adding this async handle stopped another one from happening
20:06:29  <bnoordhuis>well, okay - i'll suggest that timers are probably a better solution for you
20:06:39  <bnoordhuis>they're easier to implement, less coordination across threads
20:07:00  <kellabyte>ok
20:07:23  <kellabyte>but I still want to learn what I did wrong here, this should work even if I should change it to timers
20:07:58  <bnoordhuis>it's what i said, in the worker thread you need to create the async handle before you call uv_run()
20:08:08  <kellabyte>yeah I did that, and the crash is gone now
20:08:19  <kellabyte>so yay! but now http requests stopped working
20:08:38  <kellabyte>so no more segfault, but the async handle handling the connection accept stopped working
20:08:53  <bnoordhuis>that's when you enter printf debugging mode :)
20:09:25  <bnoordhuis>'the async handle handling the connection accept' <- that's kind of confusing/ambiguous though
20:09:44  <kellabyte>well, I'm doing the multi-accept example you showed me a few weeks ago
20:10:12  <kellabyte>and that stopped working by adding (and fixing with your advice just now) this 2nd async handle on the consumers loop
20:10:52  <kellabyte>but if I comment out this new async init (now called on the consumers thread), it works again
20:11:00  <bnoordhuis>does the async handle fire when the main thread calls uv_async_send()?
20:11:10  <bnoordhuis>does the main thread call uv_async_send() at all?
20:11:52  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
20:12:06  <kellabyte>yeah, the timer on the main thread calls uv_async_send() and my printf in the async handle callback happens
20:12:12  <kellabyte>so with your advice today I did this:
20:12:14  <kellabyte>https://gist.github.com/kellabyte/6399734#file-http_response_cache-c-L33
20:12:28  <kellabyte>which the consumers of the multi-accept which have their own loops call
20:13:27  <kellabyte>bnoordhuis: here's the timer sending uv_async_send() https://gist.github.com/kellabyte/6399734#file-http_response_cache-c-L82
20:13:45  <kellabyte>bnoordhuis: and this printf() happens https://gist.github.com/kellabyte/6399734#file-http_response_cache-c-L40
20:15:12  <bnoordhuis>okay, looks good so far
20:15:18  <bnoordhuis>you say http stopped working?
20:15:31  <bnoordhuis>as in, `curl -v <url>` hangs or ... ?
20:15:38  <kellabyte>yeah it hangs
20:15:47  <bnoordhuis>have you attached a debugger?
20:16:00  <kellabyte>yeah, do you want me to pause during the hang?
20:16:27  <bnoordhuis>yeah, maybe try with only two threads, then attach and inspect the output of `thread apply backtrace full`
20:16:50  <bnoordhuis>are you using mutexes or semaphores anywhere?
20:16:55  <kellabyte>is that a gdb thing?
20:17:17  <kellabyte>there's some semaphores but just the ones from the multi-accept example
20:17:32  <kellabyte>which I think is to time the construction of stuff properly to stage it
20:18:09  <bnoordhuis>yeah, it's a gdb thing
20:18:30  <bnoordhuis>you're not using a - *shiver* - visual debugger, are you?
20:18:33  * mikealquit (Quit: Leaving.)
20:18:45  <kellabyte>I like Xcode, sue me :P
20:18:48  <bnoordhuis>haha
20:19:07  <indutny>oh gosh
20:19:16  <indutny>that minecraft.uv project is going pretty...
20:19:19  <indutny>rough
20:19:33  <indutny>hehe :)
20:19:35  <indutny>but works :)
20:19:40  <kellabyte>I gotta go get ready for my birthday party, I wrote that command down I'll try it when I get back if I can still see the screen clearly :P
20:19:51  <bnoordhuis>have fun kellabyte :)
20:20:05  <bnoordhuis>indutny: minecraft + libuv? neat but... why?
20:20:14  <kellabyte>bnoordhuis: thanks! and thanks so much for the patience and help!
20:20:15  <indutny>fast event-loop server
20:20:29  <kellabyte>have a good day everyone!
20:20:35  <bnoordhuis>you too :)
20:20:57  <indutny>you too
20:21:07  <bnoordhuis>indutny: well, whatever makes you happy :)
20:21:20  <bnoordhuis>isn't there a minecraft server written in node?
20:22:16  <indutny>well
20:22:18  <indutny>who cares
20:22:21  <indutny>its not in C
20:22:22  <indutny>:)
20:23:02  <bnoordhuis>oh? rust?
20:25:18  <indutny>not ready yet
20:25:26  <indutny>to my mind
20:25:31  <bnoordhuis>what? rust?
20:25:38  <bnoordhuis>you're speaking in riddles again, fedor
20:25:46  <bnoordhuis>maybe even enigmas
20:27:12  <indutny>rust
20:27:30  <indutny>I'm afraid of its interoperation with C :)
20:27:39  <indutny>well, libuv particularly
20:27:44  <indutny>so...
20:27:54  <indutny>ok, time to get back to writing it
20:28:02  <bnoordhuis>how so? c interop works pretty well in rust imo
20:28:13  <indutny>meh
20:28:16  <indutny>no arguments
20:28:19  <indutny>just wanted to do it in C
20:28:25  <indutny>without runtime
20:28:26  <indutny>with openssl
20:28:28  <indutny>with zlib
20:28:31  <indutny>linked together
20:28:40  <bnoordhuis>oh ah
20:28:56  <bnoordhuis>when you said 'its not in C', i thought you meant your project was not in c
20:29:03  <indutny>aah
20:29:08  <indutny>that was about minecraft
20:29:27  <indutny>brb
20:37:36  <creationix>I'm looking at the node zlib bindings and I can't figure out where data comes out of zlib
20:37:46  <creationix>I know it's threaded, I've observed that in my programs
20:38:52  <bnoordhuis>creationix: zlib itself is synchronous, you feed it uncompressed data and out comes compressed data (or vice versa)
20:39:10  <creationix>right, but not how it's exposed to node right?
20:39:23  <bnoordhuis>that is, it's not threaded - it's just that node uses threads to prevent the main loop from blocking
20:39:35  <creationix>right zlib itself is sync
20:39:41  <bnoordhuis>exactly
20:39:49  <creationix>as all pure data transforms should be
20:39:50  <creationix> :)
20:40:02  <bnoordhuis>no disagreement from me
20:40:18  <creationix>so where is the .ondata event or whatever?
20:40:38  <creationix>I see where node writes to the C++ bindings https://github.com/joyent/node/blob/master/lib/zlib.js#L460-L469
20:41:24  <bnoordhuis>creationix: grep src/node_zlib.cc for MakeCallback
20:41:58  <bnoordhuis>creationix: it basically calls obj.callback(data) where obj is the context object that was provided by js land
20:42:33  <creationix>so req.callback I just highlighted?
20:43:00  <bnoordhuis>oh, you did. yeah
20:43:38  <creationix>wrapping that is going to be "fun"
20:43:53  <bnoordhuis>for what? luvit?
20:43:56  <creationix>I guess I can toString the function, replace that one line and put it back. It doesn't appear to use any closure data
20:44:09  <creationix>no, for a process.addAsyncListener polyfill
20:44:09  <bnoordhuis>eh?
20:44:19  <creationix>nasty hacky stuff
20:44:21  <bnoordhuis>oh dear
20:44:44  <creationix>or I could just wrapp EventEmitter.prototype.emit
20:44:50  <creationix>but that does terrible things to performance
20:46:16  <creationix>not to mention that replacing the callback in emitter.on breaks things like once and removeListener
20:46:21  <creationix>I'd end up rewriting most of EventEmitter
20:49:19  * AvianFlujoined
20:49:57  <bnoordhuis>creationix: what is the purpose of this addAsyncListener thingy?
20:50:04  <bnoordhuis>is that what you and trevnorris have been working on?
20:50:24  <creationix>yep
20:50:38  <creationix>it a hook to make implementing things like domains and long stack traces easy
20:50:48  <creationix>without all this nasty monkey-patching I'm doing
20:51:06  <creationix>but new-relic wants the polyfill for older versions of node so they can use it today
20:51:12  <indutny>bnoordhuis: back
20:51:18  * pachetquit (Quit: [ +++ ])
20:51:42  <bnoordhuis>creationix: you're working for new relic now?
20:51:49  <creationix>no, just as a contractor
20:51:53  <bnoordhuis>ah okay
20:51:55  <creationix>helping othiym23 out
20:52:07  <bnoordhuis>indutny: wb :)
20:52:48  <indutny>bnoordhuis: so basically this v
20:52:49  <indutny>https://github.com/indutny/mine.uv
20:53:11  <indutny>not the best code that I wrote
20:54:01  <indutny>but whatever
20:54:07  <bnoordhuis>50 commits already? you're going fast, fedor
20:54:50  <bnoordhuis>how long did it take you to write all that?
20:55:03  <bnoordhuis>int main() { <- aw :(
20:55:30  <bnoordhuis>god kills a kitten every time a c programmer forgets to declare main() properly
20:56:12  <indutny>рфрф
20:56:15  <indutny>haha
20:56:16  <indutny>well, its ok
20:56:19  <indutny>its WIP
20:56:23  <indutny>I'll rewrite it
20:56:27  <indutny>and make it read JSON config
20:56:29  <bnoordhuis>the gcc test suite alone is responsible for a massive feline holocaust
20:56:29  <indutny>eventually
20:56:42  <indutny>bnoordhuis: I'm working on it for about 3 days
20:56:54  <bnoordhuis>okay. you did that pretty quick then
20:56:58  <indutny>I think
20:57:20  * piscisaureus_joined
20:57:32  <piscisaureus_>bnoordhuis: al klaar met je belastingaangifte?
20:58:42  <bnoordhuis>piscisaureus_: didn't get email from the belastingdienst this trimester
20:59:29  <piscisaureus_>bnoordhuis: ik bedoel inkomstenbelasting :)
20:59:45  <bnoordhuis>oh dat. nee, nog niet. doet sjoerd
21:00:04  <piscisaureus_>ah. relaxed
21:06:56  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
21:22:22  * brsonjoined
21:23:14  * wolfeidaujoined
21:37:18  * AvianFluquit (Remote host closed the connection)
21:54:46  * dominictarrquit (Ping timeout: 246 seconds)
22:03:20  * dominictarrjoined
22:10:02  * rendarquit (Quit: Leaving)
22:14:03  * mikealjoined
22:19:35  * TooTallNatejoined
22:21:35  * dazldjoined
22:34:45  * piscisaureus_joined
23:04:08  * bnoordhuisquit (Ping timeout: 240 seconds)
23:05:02  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:09:41  * dominictarrquit (Quit: dominictarr)
23:14:10  * hzquit
23:22:10  * brsonquit (Quit: leaving)
23:38:03  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:45:41  * mikealquit (Quit: Leaving.)
23:48:49  * mikealjoined
23:59:52  <MI6>libuv-master-gyp: #150 UNSTABLE windows-x64 (3/194) windows-ia32 (3/194) smartos-ia32 (2/193) smartos-x64 (2/193) http://jenkins.nodejs.org/job/libuv-master-gyp/150/