00:11:00  * kazuponquit (Ping timeout: 248 seconds)
00:14:14  * AvianFluquit (Remote host closed the connection)
00:17:26  * jmar777quit (Remote host closed the connection)
00:18:00  * jmar777joined
00:20:45  <piscisaureus_>hey sblom
00:20:51  <piscisaureus_>how is it going?
00:21:34  <piscisaureus_>sblom: do you manage to find your way around the source code?
00:21:58  * jmar777quit (Ping timeout: 240 seconds)
00:28:34  * bradleymeckjoined
00:30:29  * erickt_quit (Quit: erickt_)
00:31:35  * AvianFlujoined
00:37:22  * kazuponjoined
00:42:17  <piscisaureus_>c'mon MI6
00:42:24  * AvianFluquit (Remote host closed the connection)
00:42:28  <MI6>joyent/node: Bert Belder reviewme * f729b53 : repl: call resume() after setRawMode() Solves #4178, but does not fix th (+371 more commits) - http://git.io/kNcIlA
00:42:32  <piscisaureus_>^-- TooTallNate: review ?
00:43:03  <piscisaureus_>TooTallNate: it's about https://github.com/joyent/node/commit/reviewme only :-)
00:43:32  <piscisaureus_>er, fuk
00:43:43  <TooTallNate>piscisaureus_: i mean.. i don't really have windows 8 to test with yet
00:44:19  <piscisaureus_>merge fuckup
00:44:23  <MI6>joyent/node: Bert Belder reviewme * 6822488 : repl: call resume() after setRawMode() Solves #4178, but does not fix th - http://git.io/mrFXfQ
00:44:39  <piscisaureus_>TooTallNate: well, you know the readline code very well. You need to tell me if there are conceptual issues.
00:44:48  <piscisaureus_>TooTallNate: I will tell you that it fixes windows8
00:44:51  <piscisaureus_>"fixes"
00:44:55  <TooTallNate>ok
00:48:39  <TooTallNate>piscisaureus_: lgtm
00:49:29  * kazuponquit (Read error: Connection reset by peer)
00:49:49  * kazuponjoined
00:53:04  <MI6>joyent/node: Bert Belder master * 6822488 : repl: call resume() after setRawMode() Solves #4178, but does not fix th - http://git.io/pOWeAw
00:54:54  <piscisaureus_>bnoordhuis: +1 for reopening /dev/tty, but how's that for pipe stdios ?
00:55:06  <piscisaureus_>it seems that reopening isn't possible then
00:55:10  <bnoordhuis>piscisaureus_: that's where the isatty() call comes in :)
00:55:36  <piscisaureus_>bnoordhuis: so how do we deal with pipes?
00:55:55  <MI6>joyent/node: Bert Belder v0.8 * f34f1e3 : repl: call resume() after setRawMode() Solves #4178, but does not fix th - http://git.io/w9Je2g
00:56:04  <piscisaureus_>bnoordhuis: always use the thread pool for stdio pipes?
00:56:17  * dapquit (Quit: Leaving.)
00:56:34  <piscisaureus_>except - maybe - when the master and child are both node
00:56:45  <bnoordhuis>piscisaureus_: i'd have to check if ioctl(pipefd[0], FIONBIO) affects the other end of the pipe
00:56:52  <bnoordhuis>but i don't think it does
00:56:57  <piscisaureus_>bnoordhuis: huh
00:57:05  <piscisaureus_>bnoordhuis: so this is fd-type specific?
00:57:42  <piscisaureus_>bnoordhuis: also - for mac, solaris?
00:58:34  <bnoordhuis>piscisaureus_: so the idea is to reopen the fd only if it's a tty
00:58:58  <bnoordhuis>i.e. if (isatty(fd)) dup2(open("/dev/tty", O_RDWR), fd);
00:59:09  <piscisaureus_>bnoordhuis: as I said - that's okay with me
00:59:16  <bnoordhuis>if fd 1 is a pipe or a file redirect, nothing happens
00:59:32  <piscisaureus_>bnoordhuis: I'm just curious how you're going to deal with pipes, because they should have the same issue I think :-)
00:59:44  <bnoordhuis>i'd have to check but a pipe is really two fds
01:00:02  <piscisaureus_>bnoordhuis: true - but you can specify stdio:"inherit"
01:00:15  <piscisaureus_>bnoordhuis: in which case the child really inherits a dup of the parent's fd
01:00:31  <bnoordhuis>ah, like that
01:00:33  <bnoordhuis>silly us
01:01:07  <piscisaureus_>bnoordhuis: so that's why I was suggesting you could do all stdio pipe reads in the thread pool
01:01:13  <piscisaureus_>and never switch to fionbio
01:01:29  <bnoordhuis>eh, sometime in the future maybe
01:01:33  * kazuponquit (Remote host closed the connection)
01:01:38  <bnoordhuis>let's start with opening /dev/tty first
01:01:43  <piscisaureus_>alright
01:01:48  <piscisaureus_>i will sign it off
01:01:53  <piscisaureus_>but first I am going to take a nap
01:01:56  <piscisaureus_>and mraleph is, too
01:04:28  * sh1mmerquit (Quit: sh1mmer)
01:16:29  * piscisaureus_quit (Read error: Connection reset by peer)
01:16:49  * piscisaureus_joined
01:17:11  <piscisaureus_>in this state if disrepair
01:17:13  <piscisaureus_>goodby
01:17:15  <piscisaureus_>e
01:17:17  * piscisaureus_quit (Client Quit)
01:21:31  * perezdquit (Quit: perezd)
01:22:03  * loladirojoined
01:24:18  * bradleymeckquit (Quit: bradleymeck)
01:24:46  * c4milojoined
01:25:40  <bnoordhuis>pummel/test-dh-regr is broken, it seems
01:26:02  <bnoordhuis>as is pummel/test-crypto-dh
01:26:16  <tjfontaine>the crypto-buffers change?
01:26:25  <bnoordhuis>that seems likely :)
01:26:28  <tjfontaine>:)
01:29:03  * c4miloquit (Ping timeout: 244 seconds)
01:29:59  * lohkeyjoined
01:30:47  <bnoordhuis>okay, off to bed
01:30:49  <bnoordhuis>sleep tight everyone
01:30:55  * kazuponjoined
01:32:32  * bnoordhuisquit (Read error: No route to host)
01:35:12  * EhevuTovquit (Quit: This computer has gone to sleep)
01:36:51  * lohkeyquit (Quit: lohkey)
01:37:37  * bradleymeckjoined
01:45:39  * piscisaureus_joined
01:48:37  * perezdjoined
01:51:37  * jmar777joined
01:54:53  * ericktquit (Quit: erickt)
01:54:53  * bradleymeckquit (Quit: bradleymeck)
01:56:31  * loladiroquit (Quit: loladiro)
02:00:05  * jmar777quit (Remote host closed the connection)
02:00:40  * jmar777joined
02:01:04  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
02:04:42  * jmar777quit (Ping timeout: 244 seconds)
02:05:54  * toothrotquit (Ping timeout: 260 seconds)
02:09:39  * toothrjoined
02:38:26  * TheJHquit (Ping timeout: 255 seconds)
02:56:45  * brsonquit (Quit: leaving)
03:00:33  * kazuponquit (Remote host closed the connection)
03:01:11  * kazuponjoined
03:03:08  * lohkeyjoined
03:05:55  * kazuponquit (Remote host closed the connection)
03:12:23  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:29:47  * joshthecoderjoined
03:36:19  * kazuponjoined
03:45:24  * kazuponquit (Ping timeout: 248 seconds)
03:50:40  * CoverSlidequit (Ping timeout: 245 seconds)
03:53:26  * kazuponjoined
04:11:01  * brsonjoined
04:11:05  * kazuponquit (Remote host closed the connection)
04:12:24  * joshthecoderquit (Quit: Leaving...)
04:15:23  * brsonquit (Client Quit)
04:15:31  * brsonjoined
04:17:21  * CoverSlidejoined
04:23:52  * kazuponjoined
04:30:42  * AvianFlujoined
04:32:16  * lohkeyquit (Quit: lohkey)
04:38:31  * loladirojoined
04:45:11  * kazuponquit (Remote host closed the connection)
04:50:00  * matthieujoined
04:50:58  <matthieu>hi, I have an issue with an add-on I've written for node.js that under some very specific condition causes a spawned process to crash
04:51:32  <matthieu>error is: ../deps/uv/src/uv-common.h:101: uv__req_unregister: Assertion `uv__has_active_reqs(loop)' failed.
04:51:45  <matthieu>addon is at https://github.com/matthieu/node-gc/blob/master/nodegc.cc
04:52:10  <matthieu>any help would be greatly appreciated, I'm stumped
04:53:02  * kazuponjoined
04:57:34  * c4milojoined
05:01:55  * c4miloquit (Ping timeout: 244 seconds)
05:16:57  * stagasjoined
05:22:24  * AvianFluquit (Remote host closed the connection)
05:24:25  * paddybyersjoined
06:00:06  * benoitcquit (Excess Flood)
06:05:13  * benoitcjoined
06:08:39  * matthieupart
06:27:05  * stagas_joined
06:30:27  * stagasquit (Ping timeout: 260 seconds)
06:30:30  * stagas_changed nick to stagas
06:45:21  * rendarjoined
06:47:56  * loladiroquit (Quit: loladiro)
06:53:21  * davispquit (Ping timeout: 244 seconds)
06:56:32  * davispjoined
06:56:32  * davispquit (Excess Flood)
06:57:01  * davispjoined
06:57:02  * davispquit (Excess Flood)
06:59:31  * davispjoined
06:59:32  * davispquit (Excess Flood)
07:01:31  * davisp-joined
07:03:19  * benoitcquit (Excess Flood)
07:05:00  * brsonquit (Ping timeout: 276 seconds)
07:10:43  * benoitcjoined
07:16:28  * perezdquit (Quit: perezd)
07:19:43  * davisp-quit (Changing host)
07:19:43  * davisp-joined
07:19:57  * davisp-changed nick to davisp
08:11:55  * mmalecki[off]changed nick to mmalecki
08:19:39  * hzjoined
08:40:26  * janjongboomjoined
09:27:13  <saghul>indutny hey
09:27:17  <saghul>indutny any idea? https://github.com/joyent/libuv/issues/603
09:31:00  <indutny>hey
09:31:31  <indutny>em...
09:31:34  <indutny>is handle correct?
09:31:42  <indutny>hm...
09:31:44  <indutny>oh
09:31:46  <indutny>I've an idea
09:31:52  <indutny>but it's really odd
09:32:02  <indutny>are you freeing handle in uv_close() ?
09:32:09  <saghul>yes
09:33:41  <indutny>so... I think what's really happening here is that handle is still in buffer
09:33:52  <indutny>I mean pipe's buffer
09:34:02  <saghul>aha, but it's memory was freed
09:35:14  <saghul>for some reason I can't catch it with the libuv test suite
09:35:39  <saghul>only with the pyuv one, I guess the overhead of the Python VM helps reproduce it or something
09:43:52  <indutny>yeah
09:44:01  <indutny>are you willing to test one assumption?
09:44:15  <indutny>saghul: ^
09:44:44  <saghul>indutny sure, let me know what I can try
09:44:48  <indutny>ok
09:45:32  <indutny>can you set `loop->async_sweep_needed=1;` here https://github.com/joyent/libuv/blob/master/src/unix/async.c#L109
09:45:45  <indutny>`handle->loop->async_sweep_needed=1;`
09:45:56  <indutny>also
09:46:14  <indutny>another probable case is that you was calling uv_async_send after free
09:46:25  <indutny>and it was working because pipe_fd was still here
09:46:45  <indutny>would be good if you will check both
09:46:52  <indutny>you can use valgrind for latter one
09:50:39  <saghul>ok, let me try those
09:52:44  <saghul>I don't think I was calling uv_async_send after free, because I delete the reference to the Python object so it would blow up
09:52:53  <saghul>let me try the sweep thing
09:53:18  <indutny>ok
09:53:24  <indutny>it's just odd that you're experiencing it...
09:53:28  <indutny>because you should not
09:53:55  <indutny>btw, on what OS you are?
09:55:50  <saghul>I'm on Linux
09:56:32  <saghul>doh, it coredumped in the same place
09:58:28  <indutny>after sweep?
09:58:32  <saghul>yep
09:58:39  <saghul>it also crashes on OSX
09:58:45  <indutny>odd...
09:58:54  <indutny>can you call uv_async_io manually from uv__async_close?
09:59:30  <saghul>after setting the sweep?
09:59:46  <indutny>wel... doesn't matter
09:59:49  <indutny>you can remove sweep now
09:59:52  <indutny>oh
09:59:55  <indutny>btw, probably I can do it myself
09:59:59  <indutny>how can I reproduce it?
10:00:16  <saghul>well, I just run the pyuv test suite twice in a row
10:00:23  <saghul>and the second time it just happens
10:00:34  <saghul>don't bother, I can test it for you
10:01:12  <saghul>when I call uv_async_io, what should I set for events? 1?
10:02:30  <indutny>wait a minute
10:02:32  <indutny>I've another idea
10:02:48  <indutny>can you call uv_close() right after uv_async_send()
10:02:55  <indutny>or before it's callback is executed?
10:03:12  <indutny>you can check this by doing: assert(handle->pending == 0); in uv__async_close
10:03:52  <indutny>but this can probably happen only if they're both called from main thread
10:05:33  <saghul>I set the sweep flag, then called the io function and doesn't seem to crash
10:05:46  <saghul>I'll remove that and add the assert
10:07:12  <saghul>that assert was triggered immediately
10:07:23  <indutny>yay
10:07:25  <indutny>kewl
10:07:33  <indutny>are you calling uv_async_send() from event-loop's thread?
10:07:34  <indutny>saghul: ^
10:08:02  <saghul>niope, different thread
10:09:54  <saghul>AFAIS the pending flag is set to 0 on ASYNC_CB, but if closed it it would remain to 1
10:10:11  <saghul>even though, I close the handle in the async callback
10:11:20  * c4milojoined
10:14:40  <indutny>saghul: interesting
10:14:53  <indutny>I'm trying to reproduce it mentally
10:15:02  <saghul>xD
10:15:27  <indutny>so uv__async_io() helped, right?
10:15:32  * c4miloquit (Ping timeout: 244 seconds)
10:15:42  <saghul>yes
10:15:51  <saghul>but I also set the async_sweep to 1
10:15:58  <saghul>let me test without that
10:16:41  <indutny>ok
10:18:26  <saghul>ok, that worked
10:18:57  <saghul>I just added this on uv__async_close: uv__async_io(handle->loop, &handle->loop->async_watcher, 1)
10:20:00  <saghul>does it make any sense to you? :-)
10:20:03  <saghul>indutny ^
10:20:39  <indutny>yeah
10:20:41  <indutny>it makes sense
10:21:16  <saghul>cool!
10:21:31  <indutny>so handle's pointer is indeed in pipe's buffer
10:21:33  <indutny>interesting
10:22:53  * stagasquit (Read error: Connection reset by peer)
10:23:23  <mmalecki>indutny: looks like I published some of your patches yesterday :D
10:23:25  * stagasjoined
10:23:31  <indutny>haha
10:23:33  <indutny>yeah
10:23:37  <indutny>for http-proxy
10:49:21  <indutny>saghul: python test_async.py ?
10:49:32  <indutny>should I use some specific branch?
10:49:44  <saghul>you can pull master
10:49:50  <saghul>the run the whole test suite like this
10:49:55  <saghul>nosetests -v -w tests
10:50:13  <indutny>pip install nosetests, right?
10:50:23  <saghul>it should fail the 2nd or 3rd time you run it
10:50:24  <saghul>yes
10:50:30  <saghul>nop, pip install nose
10:50:44  <indutny>oh, ok
10:51:40  <indutny>No module named unittest2)
10:51:50  <indutny>pip install ?
10:51:58  <indutny>yeah, helped
10:53:24  <indutny>malloc: *** error for object 0x101951508: incorrect checksum for freed object - object was probably modified after being freed.
10:53:25  <indutny>*** set a breakpoint in malloc_error_break to debug
10:53:29  <indutny>at FSTest
10:53:33  <indutny>Fstat
10:55:54  <indutny>test_gc (test_gc.GCTest) ...
10:55:54  <indutny>Program received signal EXC_BAD_ACCESS, Could not access memory.
10:55:54  <indutny>Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000020
10:55:55  <indutny>saghul: ^
10:56:02  <indutny>are you sure you ain't doing something wrong
10:56:07  <indutny>#0 0x00000001000b0baa in PyObject_GC_Track ()
10:56:07  <indutny>#1 0x00000001000b14d9 in initgc ()
10:56:07  <indutny>#2 0x0000000100089197 in PyEval_EvalFrameEx ()
10:56:07  <indutny>#3 0x00000001000892f1 in PyEval_EvalFrameEx ()
10:56:12  <indutny>this is where it happens
10:56:29  <indutny>I'm getting random errors every other time
10:56:35  <saghul>ein?! I'm not seeing that
10:57:18  <indutny>well, looks like it's still related to uv__async_io
10:57:21  <saghul>all tests have been passing for me
10:57:59  <indutny>well, I see random errors on osx
10:58:05  <saghul>I guess you are running the system python, right?
10:58:05  <indutny>some of them a related to uv_work_t
10:58:08  <indutny>yeah
10:58:35  <saghul>ok, I'll test with that one later then. I use a custom built one, because the one that ships with OSX don't have debug symbols
10:58:50  <saghul>from 2.6.1 to 2.6.8 there is a long way :-S
10:59:19  <indutny>ah
10:59:26  <indutny>well, what I can really see here
10:59:42  <indutny>uv__async_io reads some incorrect pointer from pipe buffer
11:00:00  <saghul>about the threadpool thing, did you get this? https://github.com/joyent/libuv/issues/580
11:00:33  <indutny>nope, I'm not receiving uv's notifications
11:00:47  <indutny>interesting
11:00:53  <indutny>it seems to be related to async
11:00:54  * kazuponquit (Remote host closed the connection)
11:01:43  <saghul>right, the threadpool uses async, so things could go weird in many directions I guess
11:03:13  <indutny>indeed
11:10:52  * AvianFlujoined
11:26:12  * piscisaureus_joined
11:32:00  * piscisaureus_quit (Read error: Connection reset by peer)
11:32:24  * piscisaureus_joined
11:47:22  <indutny>piscisaureus_: ohai
11:49:38  <indutny>piscisaureus_: I think I got your concept
11:54:35  * c4milojoined
11:55:38  <piscisaureus_>indutny: very good sir :-)
11:55:48  <indutny>piscisaureus_: indeed, sir
11:56:03  <piscisaureus_>indutny: something may be more difficult because signal.c doesn't deal with EAGAIN
11:56:11  <piscisaureus_>indutny: but I think it is solvable.
11:56:16  <indutny>what do you mean?
11:56:49  <piscisaureus_>indutny: just try it :-)
11:57:43  <indutny>ok :)
11:58:05  <indutny>tests are passing
11:58:30  <indutny>it should be spinning in case of EAGAIN
11:58:38  <indutny>if there're some data
11:58:42  <indutny>err
11:58:43  <indutny>there's
11:58:52  * c4miloquit (Ping timeout: 244 seconds)
11:59:12  <indutny>async8 benchmark is passing too
11:59:13  <indutny>saghul: yt?
11:59:26  <saghul>indutny yep
12:00:34  <indutny>can you please try this patch
12:00:46  <indutny>saghul: https://github.com/indutny/libuv/commit/9e8cbfd16bc63103227a13391224f26b5e7bd6a1.patch
12:01:09  <indutny>piscisaureus_: bertje, review please ^
12:04:37  <saghul>indutny hum, not it consistently crashes in the first run
12:04:47  <indutny>ahm?
12:04:56  <indutny>it crashes, or it's not?
12:04:57  <saghul>LoL, now it didn't
12:05:24  <indutny>well
12:05:25  <saghul>yeah, same crash still
12:05:43  <indutny>saghul: can you gdb into uv__async_close
12:05:52  <indutny>and print handle->pending
12:06:52  <piscisaureus_>indutny: so what if the second write() succeeds ?
12:07:00  <indutny>oooh
12:07:02  <indutny>that EAGAIN
12:07:04  <indutny>oh
12:07:20  <piscisaureus_>indutny: or what if the pipe is drained immediately after you set pending=1
12:07:31  <piscisaureus_>indutny: ... but before you write for the first time
12:07:37  <indutny>and so what?
12:07:38  <piscisaureus_>indutny: still *boom*
12:07:45  <indutny>that means that someone has send signal
12:07:47  <indutny>and closed handle
12:07:51  <piscisaureus_>no I mean
12:07:53  <indutny>at the same time, isn't it?
12:08:16  <piscisaureus_>indutny: yeah that would probably be a bug anyway
12:08:24  <piscisaureus_>hmm
12:08:34  <indutny>so...
12:08:36  <indutny>hm...
12:08:45  <indutny>interesting
12:08:57  * abraxasquit (Remote host closed the connection)
12:09:02  <indutny>EAGAIN is indeed not really straightforward
12:09:02  <piscisaureus_>think about this
12:09:12  <piscisaureus_>indutny: you can also just write a null pointer
12:09:21  <piscisaureus_>indutny: and always do a full sweep if you see a null pointer
12:09:22  <indutny>piscisaureus_: or...
12:09:31  <indutny>piscisaureus_: I've another idea
12:09:39  <indutny>but null pointer will definitely work, yeah
12:09:42  <piscisaureus_>time travel
12:11:14  <indutny>yes, I could use quantum effects in CPU
12:11:22  <indutny>or hack branch prediction
12:11:43  * kazuponjoined
12:12:06  <saghul>indutny pending is 1
12:12:08  <saghul>and Assertion failed: (!(handle->flags & UV_CLOSED)), function uv__make_close_pending, file src/unix/core.c, line 144.
12:12:20  <indutny>wow
12:12:39  <indutny>piscisaureus_: can handle be UV_CLOSING and UV_CLOSED at the same time?
12:12:52  <indutny>ah
12:12:53  <indutny>yea
12:13:08  * abraxasjoined
12:14:30  * bnoordhuisjoined
12:15:33  <indutny>saghul: https://github.com/indutny/libuv/commit/1bca78f.patch
12:15:38  <indutny>saghul: please try this
12:16:11  <indutny>bnoordhuis: hey ben
12:16:18  <saghul>indutny on it
12:16:21  <bnoordhuis>indutny: ho fiodor
12:16:42  <indutny>bnoordhuis: how are you doing today?
12:16:42  <piscisaureus_>ah ben is here
12:16:52  <piscisaureus_>bnoordhuis: i have another question for you
12:16:58  <bnoordhuis>indutny: i'm fine, thanks :)
12:17:00  <piscisaureus_>bnoordhuis: what are you doing today and this week ?
12:17:09  <bnoordhuis>piscisaureus_: preferably as little as possible
12:17:19  <indutny>bnoordhuis: are you on vacation?
12:17:21  * kazuponquit (Ping timeout: 264 seconds)
12:17:39  <piscisaureus_>bnoordhuis: can you make something up then? That I can mention in the standup.
12:17:39  <bnoordhuis>indutny: no. i just feel like slacking off
12:17:55  * abraxasquit (Ping timeout: 252 seconds)
12:18:04  <bnoordhuis>piscisaureus_: working on removing libev, doing some experimenting with atomic ops in libuv, fixing bugs
12:18:17  <piscisaureus_>bnoordhuis: so when can we expect uv-atomics.h ?
12:18:21  * piscisaureus_drools
12:18:37  <bnoordhuis>piscisaureus_: i guess the question is what architectures we want to support
12:18:51  <bnoordhuis>x86/x64 obviously, probably arm. what about mips?
12:19:14  <piscisaureus_>bnoordhuis: i don't care about mips. just assert(0 && "we take patches")
12:19:19  <bnoordhuis>heh
12:19:26  <piscisaureus_>bnoordhuis: can mips do atomics anyway?
12:19:29  <bnoordhuis>yes
12:19:42  <piscisaureus_>bnoordhuis: we can always have a sucky fallback
12:19:53  <bnoordhuis>it has a compare-and-swap instruction and you can use that to implement most atomic ops
12:19:59  <bnoordhuis>not very efficiently but still
12:20:03  <saghul>indutny no joy
12:20:12  <piscisaureus_>bnoordhuis: who cares.
12:20:26  <piscisaureus_>bnoordhuis: I doubt that we can have 100% coverage for everything
12:20:28  * jmar777joined
12:20:30  <bnoordhuis>piscisaureus_: well, there's this one other guy besides me that runs node on mips :)
12:20:30  <indutny>saghul: still the same?
12:20:44  <saghul>yep
12:20:48  <piscisaureus_>bnoordhuis: you run mips?
12:20:58  <bnoordhuis>piscisaureus_: occasionally
12:21:03  <indutny>bnoordhuis: what atomics do you want to implement?
12:21:04  <bnoordhuis>that is, i occasionally test node on mips
12:21:14  <indutny>bnoordhuis: on wi-fi router I guess?
12:21:18  <bnoordhuis>indutny: yes
12:21:28  <bnoordhuis>indutny: re atomics, this: http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins
12:21:28  <indutny>otherwise it would be scary
12:21:35  <indutny>ah, so all those
12:21:59  <saghul>indutny in case it helps: https://gist.github.com/3945767
12:21:59  <indutny>it seems to be a lot for separating this code in another library
12:22:02  <indutny>libuatomic
12:22:02  <piscisaureus_>bnoordhuis: do we really care about acquire, release semantics and those things
12:22:06  <bnoordhuis>piscisaureus_: yes
12:22:06  <piscisaureus_>they should all just be full barriers
12:22:14  <bnoordhuis>and no, not full barriers :)
12:22:16  <piscisaureus_>we are not targeting itanium are we
12:22:20  <indutny>saghul: p *h ?
12:22:40  <bnoordhuis>piscisaureus_: btw, on x86, you can do away with nearly all barriers
12:23:09  <indutny>no itanium, please
12:23:09  <bnoordhuis>piscisaureus_: even in sequentially consistent mode, if you use lock xchg in one or two places
12:23:38  <saghul>indutny https://gist.github.com/3945767 updated
12:23:53  <saghul>indutny WTF is that thing in the async_cb?
12:23:58  <indutny>well
12:24:02  <indutny>type = UV_CHECK
12:24:07  <indutny>so it's just a junk
12:24:26  <saghul>looks so
12:24:30  <piscisaureus_>bnoordhuis: lock xchg acts as a full barrier right?
12:24:39  <bnoordhuis>piscisaureus_: yes, it's a synchronization point
12:25:10  <indutny>oh
12:25:11  <indutny>nice
12:25:17  <bnoordhuis>saghul: i think i know what's causing that crash
12:25:23  <indutny>bnoordhuis: what?
12:25:34  <bnoordhuis>indutny: your patch writes a pointer to a pipe
12:25:39  <indutny>haha
12:25:42  <indutny>sure
12:25:42  <bnoordhuis>but what if the handle gets closed in the mean time?
12:25:58  <indutny>well, that's a bug in client's code
12:26:03  <bnoordhuis>i'd intended to bring that up but by then bert had already merged it :/
12:26:14  <indutny>concurrent uv_close() and uv_async_send()
12:26:18  <indutny>hahaha
12:26:20  <indutny>piscisaureus_: ++
12:26:20  <kohai>piscisaureus_ has 18 beers
12:26:28  <indutny>bnoordhuis: I'm trying to address some races here https://github.com/indutny/libuv/commit/1bca78f.patch
12:26:35  <indutny>mostly pointed out by bertje
12:27:01  <indutny>basically, what if uv_close() is called after uv_async_send() pending should be 1
12:27:11  <indutny>otherwise no data can be in pipe
12:27:14  <indutny>oh
12:27:16  <indutny>wait
12:27:17  <piscisaureus_>ok, guys I am going to be afk for half an hour
12:27:22  <piscisaureus_>when I am back I am at the office
12:27:27  <piscisaureus_>\o
12:27:29  <indutny>pending could be reset by full sweep
12:27:32  <indutny>\k
12:27:42  <indutny>\e\s\c\a\p\i\n\g
12:28:22  <indutny>saghul: can you check if sweep flag is ever set?
12:28:39  <saghul>indutny let me check
12:28:50  <indutny>breakpoint in uv__async_io
12:28:57  <indutny>where if (sweep_flag) { do sweep }
12:29:02  <indutny>s/where/at
12:31:28  <saghul>I just added a printf, poor mans debug
12:31:36  <saghul>and doesn't get set apparently
12:33:58  <saghul>yeah, I haven't seen that flag set even once
12:34:50  <indutny>hm...
12:34:51  <indutny>interesting
12:36:10  <saghul>lunch, brb
12:39:09  * Raynosquit (Remote host closed the connection)
12:39:09  * dscapequit (Remote host closed the connection)
12:39:09  * indutnyquit (Remote host closed the connection)
12:43:43  * sgallaghjoined
12:44:54  <sgallagh>bnoordhuis: What are the chances that someone could review the pending pull request https://github.com/joyent/libuv/pull/428 from avalance123? I'd like to see that land so I can send patches to support it in Node.JS proper
12:45:17  <sgallagh>I don't have a strong enough background in the build system to confidently review it myself
12:46:09  <bnoordhuis>sgallagh: that PR doesn't apply any more, i'm afraid
12:46:10  <bnoordhuis>i have a patch pending that adds shared object support
12:46:26  <sgallagh>bnoordhuis: Ah ok. Cool.
12:46:31  <bnoordhuis>but it depends on removing libev first :)
12:46:40  * sgallaghnods
12:46:56  <bnoordhuis>sgallagh: btw, can you sign the cla? i'd like to land your http_parser patch
12:47:23  <sgallagh>bnoordhuis: I'm currently stuck in limbo on that as Legal reviews it. Hopefully in the next couple days. Sorry about that.
12:47:29  <bnoordhuis>oh, no problem
12:48:32  <sgallagh>If I were contributing as just an end-user, I'd be fine with it. But since I'm doing this in my Red Hat role, I need to make sure there aren't any "gotchas" there.
12:50:04  <sgallagh>bnoordhuis: But anyway, thanks for the review and the willingness to include it. I'm looking forward to getting this into Fedora soon :)
12:50:54  <bnoordhuis>sgallagh: sweet :)
12:50:56  * indutnyjoined
12:51:01  <indutny>sorry
12:51:04  <indutny>irccloud problems
12:51:23  <indutny>saghul: I need to look into other stuff for some time...
12:51:32  <indutny>bnoordhuis: probably for now it would be better to just revert that commit
12:51:48  <saghul>indutny no problem, thanks for the help!
12:51:50  <bnoordhuis>indutny: i'll do that
12:54:11  <bnoordhuis>https://github.com/bnoordhuis/libuv/compare/reopen-tty <- review anyone?
12:55:18  * kazuponjoined
12:59:43  * dscapejoined
13:00:40  <MI6>joyent/libuv: Ben Noordhuis master * b7f38b1 : Revert "unix: avoid iterating over all async handles" This reverts commi - http://git.io/n8We_A
13:01:09  * AvianFluquit (Remote host closed the connection)
13:01:15  * Raynosjoined
13:02:36  * travis-cijoined
13:02:36  <travis-ci>[travis-ci] joyent/libuv#819 (master - b7f38b1 : Ben Noordhuis): The build passed.
13:02:36  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/61ecb3415d0d...b7f38b1e5384
13:02:36  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2914008
13:02:36  * travis-cipart
13:04:46  <bnoordhuis>indutny: maybe it's easiest to create a pipe/socketpair for every async handle
13:05:20  <bnoordhuis>kind of wasteful in that it requires lots of file descriptors if you have lots of async handles
13:05:24  <bnoordhuis>but file descriptors are cheap
13:07:48  * loladirojoined
13:09:18  <sgallagh>bnoordhuis: File descriptors aren't always cheap
13:09:35  <sgallagh>On many Linux systems, you are given 1024 per process to work with.
13:09:45  <bnoordhuis>sgallagh: yes, but that's what `ulimit -n` is for :)
13:10:09  <sgallagh>bnoordhuis: What I mean is that this is the hard limit unless you are root
13:10:32  <sgallagh>(And even then, you have to worry about "capabilities", which even root may be restricted from)
13:10:52  * loladiroquit (Client Quit)
13:11:56  <sgallagh>Too many FDs bit me hard with the SSSD project a while ago
13:12:50  <bnoordhuis>sgallagh: node is for building networked applications. in general, people are aware they need to up the nofile limit if they want to serve lots of requests concurrently
13:13:08  <bnoordhuis>it's probably different for sssd
13:13:28  <sgallagh>Sure, but it's never a good idea to waste file descriptors for internal tasks that could be used for external ones
13:13:53  <sgallagh>SSSD's job was to handle network-based authentication (replacement for nss_ldap/pam_ldap/pam_krb5)
13:14:28  <sgallagh>And it had to handle incoming local socket requests from every process on the system (possibly as many as three per process)
13:14:52  <bnoordhuis>sgallagh: right. these async handles are not internal things though, they're for inter-thread communication, e.g. for people that write native add-ons
13:14:55  <sgallagh>So on really heavily-loaded systems, we were in trouble
13:15:03  <sgallagh>ok
13:15:47  <sgallagh>bnoordhuis: Anyway, my main point here was going to be: "use as few as possible and try to close idle ones"
13:16:01  <bnoordhuis>oh right, no objection there
13:16:16  <bnoordhuis>fortunately, i can push that responsibility to the libuv users :)
13:19:00  <piscisaureus_>bnoordhuis: I disagree with opening a pipe for every async
13:19:16  <bnoordhuis>piscisaureus_: it's fine to disagree with me
13:19:19  <bnoordhuis>but only when you're wrong
13:19:19  <piscisaureus_>bnoordhuis: if indutny can't fix it, I will
13:19:29  <bnoordhuis>but what's your beef with it?
13:19:52  <piscisaureus_>bnoordhuis: well, the default fd limit on mac for example
13:19:57  <piscisaureus_>some tests already fail
13:20:00  <bnoordhuis>yes, silly os x
13:20:08  <piscisaureus_>bnoordhuis: and for node users it's fine to up ulimit
13:20:09  <indutny>huh?
13:20:12  <indutny>ah
13:20:15  <indutny>osx openssl
13:20:17  <indutny>that thing?
13:20:23  <bnoordhuis>it's only an issue when people create a lot of async handles
13:20:41  <bnoordhuis>but i can't think of many plausible scenarios where you'd do that
13:20:42  <piscisaureus_>bnoordhuis: but for other situations (and for embedded nodes like in mapbox) that's not very userfriendly
13:22:01  * TheJHjoined
13:34:44  <bnoordhuis>piscisaureus_: want to review https://github.com/bnoordhuis/libuv/compare/reopen-tty ?
13:34:52  <bnoordhuis>or you, indutny
13:36:50  * bnoordhu1sjoined
13:36:57  * c4milojoined
13:38:16  * c4miloquit (Read error: Operation timed out)
13:39:03  <MI6>joyent/node: Ben Noordhuis master * 8ac017e : test: fix pummel/test-crypto-dh, pummel/test-dh-regr Forgotten in the sw - http://git.io/3kCxAQ
13:43:20  <MI6>joyent/libuv: Ben Noordhuis master * 31f9fbc : unix: reopen tty as /dev/tty Reopen the file descriptor when it refers t - http://git.io/kGuD6A
13:43:36  <piscisaureus_>bnoordhuis: not waiting for review any more?
13:43:44  <bnoordhuis> piscisaureus_ it took to long
13:43:46  <bnoordhuis>*too
13:44:21  <bnoordhuis>it works on linux, os x and sunos
13:44:26  <bnoordhuis>i am as surprised as you are
13:44:49  <bnoordhuis>admittedly i skipped freebsd and netbsd
13:45:06  * travis-cijoined
13:45:06  <travis-ci>[travis-ci] joyent/libuv#820 (master - 31f9fbc : Ben Noordhuis): The build passed.
13:45:06  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b7f38b1e5384...31f9fbce6321
13:45:06  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2914542
13:45:06  * travis-cipart
13:45:30  <piscisaureus_>bnoordhuis: HUH -> https://github.com/bnoordhuis/libuv/blob/66e924418865854b25448a59e8629bb0b6d57278/src/unix/tty.c#L63-66
13:45:39  <piscisaureus_>bnoordhuis: of course not !
13:45:48  <bnoordhuis>hmm?
13:46:29  <piscisaureus_>bnoordhu1s: or - maybe you're right
13:46:44  <piscisaureus_>bnoordhuis: you mean that close() happened before open('/dev/tty') ?
13:46:51  <bnoordhuis>piscisaureus_: yes
13:47:01  <piscisaureus_>hmmm
13:47:40  <piscisaureus_>bnoordhuis: I am not sure I agree with this solution tho
13:47:45  <bnoordhuis>how so?
13:47:47  <piscisaureus_>bnoordhuis: I think you should just keep the old fd around
13:48:05  <bnoordhuis>piscisaureus_: why?
13:48:06  <piscisaureus_>bnoordhuis: if you make a child process inherit from process.stdin, it will still inherit the nonblocking fd
13:48:26  <bnoordhuis>yes, but i don't see how that can be fixed
13:48:34  <bnoordhuis>i mean, that's already broken
13:49:05  <bnoordhuis>i guess in some cases we can reopen /dev/tty *again*, right before the execve
13:49:14  <bnoordhuis>and put it in blocking mode again
13:49:19  <piscisaureus_>ghe
13:49:32  <piscisaureus_>stupid unix
13:49:41  <bnoordhuis>but that's a separate issue from what this commit is trying to address
13:49:54  <bnoordhuis>which is making `node | cat` work
13:50:01  <bnoordhuis>which is a silly thing but anyway
13:50:49  <piscisaureus_>ok, back to libuv chores
13:57:32  * bnoordhu1squit (Ping timeout: 244 seconds)
13:59:07  * bnoordhu1sjoined
14:06:25  <piscisaureus_>ok now I am really going to the office
14:06:35  <piscisaureus_>see if janjongboom bought some beer already
14:06:45  <janjongboom>nope
14:06:53  <janjongboom>esther has ordered 3 crates
14:06:57  <janjongboom>but will be here only tomorrow
14:07:20  <piscisaureus_>ah
14:07:24  <piscisaureus_>sadfae
14:07:27  <piscisaureus_>*sadface
14:13:00  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
14:16:42  * c4milojoined
14:19:36  <saghul>bnoordhuis yt?
14:20:11  <saghul>I have a weird case which I think libuv handles wrong: lets say I start 2 prepare handles
14:20:28  <saghul>then on the callback for the first, I close the second
14:21:00  * c4miloquit (Ping timeout: 252 seconds)
14:21:23  <saghul>since we are iterating the prepare_handles queue already, won't that prepare callback get called, even if we closed it?
14:21:41  <saghul>I can write a C test case
14:22:44  * pquernaquit (Ping timeout: 248 seconds)
14:23:57  * pquernajoined
14:26:16  * ericktjoined
14:28:15  * loladirojoined
14:28:16  * AvianFlujoined
14:29:02  <bnoordhuis>saghul: ih now
14:29:14  <saghul>hum, maybe not, I need to dig deeper
14:29:32  * piscisaureus_joined
14:31:00  <bnoordhuis>saghul: if you close the prepare handle, it gets removed from the prepare handles queue
14:31:14  <bnoordhuis>that is, the prepare cb won't get called
14:31:27  <saghul>can that be problematic if we are in the process of iterating that queue?
14:32:11  <saghul>I think the Python gc if fucking with me. I close handles if objects are gc'd, that is probably messing something up
14:32:25  * hzquit (Read error: Connection reset by peer)
14:32:30  <saghul>I'll let you know if it's an issue on libuv
14:32:59  <bnoordhuis>saghul: no, the queue is resilient to modification
14:33:02  * bnoordhu1squit (Ping timeout: 260 seconds)
14:33:14  <saghul>bnoordhuis ok, thanks!
14:41:06  * hzjoined
14:57:02  <piscisaureus_>I kinda regret sharing uv__handle_start with unix
14:57:39  * dapjoined
14:58:52  <bnoordhuis>because now you have to live up to its greatness?
14:59:06  * bnoordhu1sjoined
14:59:11  <piscisaureus_>no, because I can't reason what will happen to uv-unix when I change it
14:59:13  <tjfontaine>he's cloning!
14:59:29  <piscisaureus_>tjfontaine?
14:59:32  <bnoordhuis>no, me
14:59:35  <tjfontaine>right
14:59:37  <bnoordhuis>for reasons i don't fully comprehend
14:59:38  * erickt_joined
14:59:50  * bnoordhuislooks at his macbook
14:59:54  * loladiroquit (Quit: loladiro)
14:59:58  <tjfontaine>tis another irssi session
15:00:02  <piscisaureus_>bnoordhuis: we are also in the half shared state
15:00:26  <piscisaureus_>bnoordhuis: uv-unix is like a girlfriend that wasn't want to go all the way
15:00:46  * bnoordhu1squit (Client Quit)
15:00:58  <bnoordhuis>so it was the bloody macbook >:(
15:01:22  <tjfontaine>piscisaureus_: but she'll at least cuddle with you, and doesn't mind being seen with you in public
15:01:40  <bnoordhuis>she also feels better than you but that's life
15:09:38  * ericktquit (Quit: erickt)
15:09:38  * erickt_changed nick to erickt
15:09:57  <piscisaureus_>bnoordhuis: does uv-unix ever call uv__handle_start on a closing handle?
15:10:07  <piscisaureus_>bnoordhuis: I want to assert when that happens
15:10:07  <bnoordhuis>piscisaureus_: no
15:10:55  <bnoordhuis>picking up mees, biab
15:11:12  <piscisaureus_>sjoer
15:11:17  * hzquit (Read error: Connection reset by peer)
15:12:04  * hzjoined
15:17:47  * indexzerojoined
15:22:28  <MI6>joyent/libuv: piscisaureus created branch reftest - http://git.io/fF9FRQ
15:26:58  <piscisaureus_>seems to work on linux too
15:27:24  <piscisaureus_>bnoordhuis: review https://github.com/joyent/libuv/commit/87dc44425ec9 ?
15:31:24  * indexzeroquit (Quit: indexzero)
15:31:54  * AvianFluquit (Remote host closed the connection)
15:32:01  * pquernaquit (Changing host)
15:32:01  * pquernajoined
15:47:54  * bradleymeckjoined
15:48:37  * perezdjoined
15:51:56  * kazuponquit (Remote host closed the connection)
15:55:30  * c4milojoined
16:04:07  * `3rdEdenjoined
16:06:09  * mikealjoined
16:09:34  * mmaleckiquit (*.net *.split)
16:09:34  * rphillipsquit (*.net *.split)
16:09:45  * mmaleckijoined
16:11:35  * mikealquit (Quit: Leaving.)
16:12:43  * rphillipsjoined
16:15:47  <isaacs>man. i have no taste for devops.
16:16:08  <isaacs>back to releasing 0.9.3...
16:22:11  <piscisaureus_>bnoordhuis: udp_timed_pummel calls uv_udp_send on closing udp handles
16:22:19  <piscisaureus_>bnoordhuis: that's not good
16:23:22  <MI6>joyent/node: isaacs v0.9.3-release * 1ed4c67 : 2012.10.24, Version 0.9.3 (Unstable) * V8: Upgrade to 3.13.7.4 * crypto (+1 more commits) - http://git.io/kw1Zeg
16:24:25  * mikealjoined
16:24:28  * janjongboomquit (Quit: janjongboom)
16:25:58  <isaacs>simple/test-http-client-timeout-with-data failing on linux
16:26:04  * bradleymeckquit (Quit: bradleymeck)
16:26:29  <isaacs>AssertionError: 0 == 1
16:35:41  * mikealquit (Quit: Leaving.)
16:38:28  <isaacs>otherwise looking good
16:40:07  <isaacs>hm. seems like just a little bit of a race condition.
16:40:12  <isaacs>increasing the diff makes it pass.
16:40:23  <isaacs>10ms vs 20ms is too close, it looks like. i'm ok with it.
16:42:15  * MI6quit (Ping timeout: 246 seconds)
16:46:14  <tjfontaine>hmm interesting node-irc bug there
16:46:36  * MI6joined
16:47:31  * piscisaureus__joined
16:48:03  * piscisaureus_quit (Read error: Connection reset by peer)
16:49:25  <isaacs>tjfontaine: oh?
16:49:44  <tjfontaine>isaacs: ya, it knew it got disconnected from freenode but didn't try and reconnect
16:50:02  <isaacs>tjfontaine: yeah. i've seen that in ircretary as well.
16:50:06  <mmalecki>tjfontaine: yeah, that happens
16:50:10  <isaacs>never bothered to dig into it though. just log in and restart it
16:50:14  <mmalecki>I'm writinng IRC2
16:50:23  <mmalecki>which fixes those problems
16:50:24  <tjfontaine>good, I'm an irc snob I'll snark at you along the way :)
16:50:28  <mmalecki>also, nicer API
16:50:39  <mmalecki>tjfontaine: lovely :)
16:50:50  <tjfontaine>mmalecki: please make sure to include sane ssl exceptions and allow for client certificates :)
16:51:03  * mikealjoined
16:51:34  <mmalecki>tjfontaine: sure
16:51:49  <tjfontaine>I won't snark really, I'll try and be helpful :)
16:51:54  * joshthecoderjoined
16:52:12  <mmalecki>tjfontaine: tjfontaine is your github username?
16:52:16  <tjfontaine>mmalecki: yup
16:52:36  <mmalecki>there you go. feel free to add any remarks/issues
16:53:44  <piscisaureus__>the libuv benchmarks suck
16:53:49  <piscisaureus__>bnoordhuis: I am going to disable many
16:54:01  <piscisaureus__>bnoordhuis: i hate having to wait half an hour for them to run.
16:54:03  <mmalecki>funniest part of the codebase is bin/build where I fetch RFC and generate a JSON file based on it
16:54:04  <isaacs>mmalecki: can you name it something other than "irc2"?
16:54:10  <piscisaureus__>it should be under 5 minutes
16:54:17  <mmalecki>isaacs: sure can
16:54:20  <mmalecki>isaacs: why tho?
16:54:26  <tjfontaine>irc2 is a thing :P
16:54:30  <isaacs>mmalecki: because putting version numbers IN the package name is such an antipattern
16:54:42  <isaacs>like iTerm2 !== iTerm version 2
16:54:47  <mmalecki>oh okay
16:54:55  <mmalecki>yeah, I see where you're going
16:55:11  <isaacs>mmalecki: or oauth2 in python, which is not an oauth2 client, nor version 2 of oauth, but a rewrite of the oauth (v1) lib
16:55:16  <mmalecki>ircretary: tell avianflu to come up with a silly name for my irc module
16:55:17  <ircretary>mmalecki: I'll be sure to tell avianflu
16:55:35  <mmalecki>isaacs: yeah, I found that *very* confusing
16:55:40  <isaacs>mmalecki: you could call it eyearesee
16:55:54  <isaacs>mmalecki: but then it's not pronouncable :)
16:55:55  <mmalecki>hahahahahahah
16:56:23  <isaacs>like my emcee module that i never realized was confusing until we discussed it on nodeup
16:56:53  * ericktquit (Quit: erickt)
16:57:21  <mmalecki>lol
16:58:30  <tjfontaine>the command parser is cute
16:59:09  <mmalecki>tjfontaine: heh
16:59:12  <philips_>bnoordhuis: what do you mean by a pipe server? https://github.com/luvit/luvit/pull/355#issuecomment-9737519
17:02:20  * kazuponjoined
17:05:54  * TooTallNatejoined
17:08:12  * kazuponquit (Ping timeout: 276 seconds)
17:08:24  <isaacs>alright, pushign live.
17:08:53  <MI6>joyent/node: isaacs created tag v0.9.3 - http://git.io/e2V7mg
17:09:43  * jmar777quit (Remote host closed the connection)
17:10:16  <MI6>joyent/node: isaacs v0.8 * 82a72e9 : blog: Post for v0.9.3 release - http://git.io/xcZAvA
17:10:18  * jmar777joined
17:10:19  <mmalecki>"we'll do it LIVE" - not a thing you want to hear from your devops team
17:10:24  <CoverSlide>fuck it, we'll do it live!
17:10:35  <tjfontaine>good ol papa bear
17:10:43  <CoverSlide>http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CCcQtwIwAQ&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DPFp-EyNSX1Q&ei=ySCIUPDjNcO1iwLCw4AQ&usg=AFQjCNE0Nad13LrMS5JlnERrbi7Wyq7UMw
17:10:49  <CoverSlide>grr fucking google
17:11:53  <MI6>joyent/node: isaacs master * 9b3f635 : Merge branch 'v0.9.3-release' (+2 more commits) - http://git.io/g_OMOQ
17:12:18  <MI6>joyent/node: isaacs master * 78dbb15 : Now working on v0.9.4 - http://git.io/sOraeg
17:14:33  * jmar777quit (Ping timeout: 244 seconds)
17:15:35  <isaacs>mmalecki: does your irc lib use callbacks?
17:15:39  <isaacs>mmalecki: you could call it ircb
17:15:44  <mmalecki>isaacs: it does
17:15:49  <mmalecki>lolk
17:15:55  <isaacs>mmalecki: then it's like "irc2", except without being confusing
17:16:09  <isaacs>mmalecki: or you could call it jsd
17:16:22  <isaacs>mmalecki: which is like (i+1)(r+1)(c+1)
17:16:26  <mmalecki>hahahahaha
17:16:39  <isaacs>mmalecki: and also easier to type
17:16:41  <isaacs>than irc
17:16:52  <isaacs>that doesn't matter, of course.
17:16:57  <isaacs>but it's a slight plus :)
17:17:11  <mmalecki>yeah, I'll pick one of those
17:17:23  <mmalecki>I need to finish actual code first XD
17:18:01  <mmalecki>it's kinda finished but needs tests, nicer APIs and such
17:18:15  <mmalecki>tjfontaine: oh, how do you like the api?
17:21:28  * joshthecoderquit (Quit: Leaving...)
17:33:47  * jmar777joined
17:34:59  <CoverSlide>jsd sounds like a js library for handling photoshop files
17:35:05  <CoverSlide>or a js daemon
17:40:19  <TooTallNate>isaacs: did you get my note about _flush() on Writable streams?
17:40:32  <TooTallNate>isaacs: or, what would be the best way to go about that?
17:40:56  <isaacs>TooTallNate: um... i don't know.
17:41:01  <isaacs>TooTallNate: what was your note?
17:41:12  <TooTallNate>just that I need that functionality :p
17:41:17  <isaacs>20:51 #libuv: <@TooTallNate> isaacs: zoo?@? i need _flush on Writable...
17:41:19  <isaacs>i see
17:41:42  <TooTallNate>isaacs: context: https://github.com/TooTallNate/node-speaker
17:41:55  <isaacs>TooTallNate: what would _flush() do on a Writable?
17:42:04  <isaacs>TooTallNate: why not just set the lowWaterMark to 0?
17:42:32  * loladirojoined
17:42:37  <TooTallNate>isaacs: in this case, i need to know when the stream is "done", so that I can call "flush" on the audio backend, and the free memory
17:42:44  <tjfontaine>mmalecki: I like the basic premise, the join will need to support keys as well, but it doesn't make me want to hurt myself like the others I've seen
17:43:35  <TooTallNate>isaacs: btw, here's a node.js mp3 player in 9 lines of code :) https://gist.github.com/3947591
17:43:48  <isaacs>TooTallNate: listen to the "finish" event?
17:43:52  * EhevuTovjoined
17:44:00  <tjfontaine>mmalecki: how do you feel about a default emit of a command if the base doesn't parse the command?
17:44:19  <TooTallNate>isaacs: ya ok, i think that'll work
17:44:46  <isaacs>TooTallNate: "finish" emits when you've called end(), and the buffer has empteid.
17:45:09  <isaacs>TooTallNate: so that'd be your signal to do some lowlevel "Hey, guys, srsly, do it now" call, and maybe eventually do some kind of "close" thing
17:45:45  <TooTallNate>isaacs: is that what we're doing for fs.WriteStreams?
17:46:11  * mikealquit (Quit: Leaving.)
17:48:25  <isaacs>TooTallNate: hm... not sure
17:48:33  <isaacs>TooTallNate: i think it just checks in the _write cb to see if it's ended or not
17:48:47  * brsonjoined
17:48:49  <isaacs>TooTallNate: but we don't do like an fdatasync or anythign
17:49:08  * mikealjoined
17:50:32  <tjfontaine>mmalecki: I also worry that you'll miss messages if you have an incomplete chunk in _onData, normally with the 512 speed at which packets flow it's not a big deal, but ocassionally you can hit an ircd that will send partials
17:54:01  * ericktjoined
17:54:10  * stagasquit (Ping timeout: 260 seconds)
17:54:37  * joshthecoderjoined
17:54:45  <mmalecki>tjfontaine: emit is a good idea
17:55:05  <mmalecki>also, yeah, will work on joining packets
17:55:54  <TooTallNate>isaacs: does destory() get called by Writable or is that part of fs?
17:56:01  <TooTallNate>destroy() that is
17:56:10  * dapquit (Quit: Leaving.)
17:56:11  <isaacs>TooTallNate: destroy() and close() are app-specific
17:56:16  <isaacs>TooTallNate: they're not part of the official api
17:56:19  <TooTallNate>ok
17:56:27  * piscisaureus_joined
17:56:35  * piscisaureus__quit (Read error: Connection reset by peer)
18:10:27  * EhevuTov_joined
18:13:09  * EhevuTovquit (Ping timeout: 240 seconds)
18:14:05  * mikealquit (Quit: Leaving.)
18:21:09  <piscisaureus_>bnoordhuis: review https://github.com/joyent/libuv/commit/87dc44425ec9 ?
18:22:40  * EhevuTov__joined
18:23:48  <isaacs>piscisaureus_: Hey, how are things going?
18:24:04  * mikealjoined
18:24:06  <piscisaureus_>isaacs: good.
18:24:24  <piscisaureus_>isaacs: ah well that was very private :-)
18:24:28  * EhevuTov_quit (Ping timeout: 252 seconds)
18:32:38  <isaacs>piscisaureus_: looking over this 0.9 milestone in github...
18:32:47  <isaacs>piscisaureus_: it's making me laugh how optimistic i was.
18:32:53  <isaacs>it's adorable!
18:33:00  <piscisaureus_>hahaa
18:33:05  <piscisaureus_>it would be very well achievable
18:33:10  <isaacs>like a little kid who thinks that they can write a letter to the president to get a pony made of candy canes!
18:33:14  <piscisaureus_>if we didn't get new bug reports in the meantime
18:33:48  * isaacsaway
18:45:04  * EhevuTov__quit (Read error: Connection reset by peer)
18:46:02  * EhevuTovjoined
18:48:09  <piscisaureus_>ircretary: tell bnoordhuis review https://github.com/joyent/libuv/commit/87dc44425ec9 pls
18:48:10  <ircretary>piscisaureus_: I'll be sure to tell bnoordhuis
18:51:02  * `3rdEdenquit (Remote host closed the connection)
18:51:32  * loladiroquit (Quit: loladiro)
18:55:06  * mikealquit (Quit: Leaving.)
18:59:44  * loladirojoined
19:01:40  * `3rdEdenjoined
19:06:10  * loladiroquit (Quit: loladiro)
19:07:53  * AvianFlujoined
19:08:27  <piscisaureus_>sblom: hi
19:09:32  * mikealjoined
19:10:03  * mikealquit (Client Quit)
19:10:24  * loladirojoined
19:10:39  * txdvquit (Ping timeout: 240 seconds)
19:11:40  * loladiroquit (Read error: Connection reset by peer)
19:11:46  * loladiro_joined
19:14:17  * sblom_joined
19:14:35  * sblomquit
19:14:40  * sblom_changed nick to sblom
19:16:12  * txdvjoined
19:16:29  * loladiro_quit (Ping timeout: 260 seconds)
19:17:53  <sblom>hi
19:18:29  <sblom>goal for this week: keep my irc window less buried. :)
19:18:38  <piscisaureus_>sblom: haha
19:18:44  <piscisaureus_>sblom: or get a better client :-)
19:18:58  <piscisaureus_>one that beeps/does a dance when we mention you :-)
19:19:01  <piscisaureus_>sblom: so, what's up?
19:19:45  <sblom>Mostly just getting the hang of node development on Windows.
19:20:55  <sblom>When running the tests, I notice about 15 fail. Wanted to make sure my failure list looks like what we'd expect and that I'm not missing some pre-reqs or anything.
19:21:13  <piscisaureus_>sblom: yeah, master is not quite good atm.
19:21:24  <piscisaureus_>sblom: can you share the output?
19:21:32  <piscisaureus_>sblom: then I can tell if you are missing something
19:21:59  <sblom>Also, do we have any customary place for dropping developer getting started howtos? I'd be happy to write up my experience to speed others along.
19:22:08  <sblom>I notice the github wiki.
19:22:12  <sblom>Seems like that might be a good place.
19:22:14  <piscisaureus_>I think that could be a good place
19:22:18  <sblom>Cool.
19:22:33  <piscisaureus_>sblom: there is not that much to know tho
19:22:37  <sblom>I'll give you a pastebin of my output in a few minutes.
19:22:43  <piscisaureus_>ok, cool
19:22:45  <sblom>Agreed--it's not hard.
19:22:46  <kohai>Agreed has -1 beer
19:27:06  <piscisaureus_>sblom: btw - are you running test or test-all ?
19:28:40  <sblom>piscisaureus_: plain test
19:29:20  * `3rdEdenquit (Remote host closed the connection)
19:29:23  <piscisaureus_>isaacs: are you sure you reapplied all v8 patches?
19:30:35  * pfox__quit (Ping timeout: 246 seconds)
19:31:48  <MI6>joyent/node: Bert Belder master * fa94f0f : v8: don't show performance warnings when compiling with msvc Patch sent - http://git.io/bFbCqw
19:36:43  * loladirojoined
19:37:46  <MI6>joyent/libuv: Bert Belder reftest * 4c3c8c9 : windows: closing handles should always keep the loop alive This makes th (+2 more commits) - http://git.io/ImN-gw
19:38:18  <MI6>joyent/libuv: Bert Belder master * 0dbab84 : benchmark: async_pummel should not call uv_async_send on closed handle T (+1 more commits) - http://git.io/_2Pciw
19:38:21  <MI6>joyent/libuv: Bert Belder reftest * 096307f : windows: closing handles should always keep the loop alive This makes th - http://git.io/8gc21A
19:39:46  <piscisaureus_>sblom: normal "test" is failing 4 for me
19:40:33  <tjfontaine>piscisaureus_: do you have an example openssl symbol that wasn't previously exported?
19:40:57  <piscisaureus_>tjfontaine: everything camellia for example
19:41:00  <piscisaureus_>CMLL_*
19:41:11  <piscisaureus_>(I will disable that again later btw)
19:41:15  <tjfontaine>nod
19:41:24  <piscisaureus_>CMML_* btw :-)
19:42:06  <sblom>piscisaureus_: cool. I've pulled, built, and am running from the top.
19:42:26  <piscisaureus_>tjfontaine: Camellia_cbc_encrypt;
19:42:27  <sblom>piscisaureus_: I'm up to 8 failures at 91%. So it'll be interesting to compare notes once this is done.
19:42:36  * `3rdEdenjoined
19:45:29  <sblom>piscisaureus_: http://pastebin.com/E3Ghhkcu
19:46:45  <sblom>piscisaureus_: Most suspicious failure category to me looks like some SSL client config problems.
19:47:10  <sblom>piscisaureus_: the others look pretty sane to me.
19:47:32  * paddybyersquit (Read error: Connection reset by peer)
19:47:44  * paddybyersjoined
19:52:41  * V1joined
19:53:41  * `3rdEdenquit (Ping timeout: 244 seconds)
19:55:41  <piscisaureus_>sblom: btw - you don't need cygwin
19:55:46  * V1changed nick to `3rdEden
19:56:45  <piscisaureus_>sblom: ok - the readlink test fails because you're not running as admin
19:56:55  <piscisaureus_>sblom: so the test cannot create symlinks
19:57:02  * jmar777quit (Remote host closed the connection)
19:57:56  <piscisaureus_>sblom: I suspect that the ssl failures are due to the fact that openssl.exe that you're using can't find some certificates, maybe because it's the cygwin version of openssl
19:58:38  <tjfontaine>piscisaureus_: fwiw your openssl-exports seems to work now without modification on osx, I'm going to clean and rebuild to verify though
19:58:50  <piscisaureus_>tjfontaine: cool
19:59:30  * `3rdEdenquit (Remote host closed the connection)
19:59:56  <piscisaureus_>sblom: the failures I'm seeing are these -> https://gist.github.com/3948442
20:01:33  <piscisaureus_>sblom: test-debugger-client, test-debugger-repl and test-listen-fd-ebadf seem genuine.
20:01:33  <piscisaureus_>test-tls-session-cache fails because my openssl version doesn't understand the '-no_ticket' option
20:04:16  * paddybyers_joined
20:06:05  * paddybyersquit (Ping timeout: 244 seconds)
20:06:05  * paddybyers_changed nick to paddybyers
20:06:19  <tjfontaine>piscisaureus_: yes, osx linker seems to already re-export openssl at least the symbols show up in nm and ffi doesn't complain about dlysm'ing them
20:06:40  <piscisaureus_>tjfontaine: and is it only openssl or does it re-export everything?
20:06:51  <tjfontaine>piscisaureus_: I have a feeling it's everything it static links
20:06:56  * jmar777joined
20:07:24  <piscisaureus_>tjfontaine: so - nothing to be done?
20:07:28  <piscisaureus_>nice :-)
20:07:38  * c4miloquit (Ping timeout: 244 seconds)
20:07:38  <tjfontaine>000000010004fa80 T _uv__pipe_close
20:07:46  <piscisaureus_>uhh
20:07:55  <piscisaureus_>does it not support symbol hiding at all?
20:08:05  <tjfontaine>it probably does, and we're just not doing it :)
20:10:11  <piscisaureus_>tjfontaine: does it support -fvisibility=hidden ?
20:10:28  * EhevuTovquit (Quit: This computer has gone to sleep)
20:10:54  * c4milojoined
20:11:13  <tjfontaine>piscisaureus_: clang appears to, probably gcc 4.2 as well
20:11:27  <piscisaureus_>tjfontaine: I think it is supported from gcc 4.0 and up
20:11:32  <piscisaureus_>I just don't know about clang
20:12:13  <tjfontaine>piscisaureus_: yes it seems to support it
20:12:32  <piscisaureus_>tjfontaine: still, it's strange
20:12:44  <piscisaureus_>tjfontaine: apparently the linker doesn't remove unused symbols then
20:13:07  <piscisaureus_>tjfontaine: otherwise openssl functions that are not used by node should not end up in the binary
20:14:39  <tjfontaine>nod
20:19:01  <piscisaureus_>tjfontaine: does it also export SSL_connect ?
20:20:12  <tjfontaine>currentnm ~/.node/bin/node | grep -i SSL_Connect
20:20:13  <tjfontaine>00000001000782ac T _SSL_connect
20:20:29  <tjfontaine>ignore the errant current at the start
20:20:33  <piscisaureus_>ya
20:20:37  <piscisaureus_>ok it seems so then
20:21:11  <tjfontaine>for what its worth the binary release doesn't have it
20:21:23  * dapjoined
20:21:32  <tjfontaine>oh wait yes it idoes
20:21:49  <tjfontaine>nm $(which node) | grep -i ssl_connect
20:21:50  <tjfontaine>00000001000701b3 T _SSL_connect
20:22:18  <piscisaureus_>ok, guys
20:22:22  <piscisaureus_>I am heading out early today
20:22:27  <piscisaureus_>"early" as in 10.20
20:22:42  <piscisaureus_>sblom: tomorrow I will be back here :-) Save your questions, or bug bnoordhuis when he comes back
20:23:50  <indutny>piscisaureus_: I'm going to look into osx openssl export problems tonight
20:23:55  <indutny>piscisaureus_: is it still relevant?
20:24:16  <sblom>piscisaureus_: great. thanks for your help.
20:24:32  * indexzerojoined
20:25:38  <piscisaureus_>indutny: ask tjfontaine. He said that everything works
20:25:46  <indutny>tjfontaine: oh, really?
20:25:56  <indutny>so I've only async stuff to look into
20:26:47  <tjfontaine>indutny: it works because the osx linker doesn't seem to strip anything
20:26:53  <indutny>ah
20:26:58  <indutny>what about gcc?
20:27:08  <indutny>it still works as on linuxes, right?
20:27:11  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:27:18  <tjfontaine>no, it's still an apple linker
20:27:24  <indutny>ah
20:27:24  <tjfontaine>but feel free to try it out
20:27:26  <indutny>ok
20:28:28  <tjfontaine>-fvisibility=hidden isn't quite the simple answer either
20:28:54  <tjfontaine>because it breaks binary addons
20:28:54  <tjfontaine>dyld: lazy symbol binding failed: Symbol not found: __ZN2v811HandleScopeC1Ev
20:29:52  <txdv>RIP IT OUT
20:30:15  * joshthecoderquit (Quit: Leaving...)
20:32:18  * paddybyersquit (Ping timeout: 240 seconds)
20:36:39  <indutny>heh
20:39:24  * piscisaureus_joined
20:39:36  <tjfontaine>-Wl,-x and -Wl,-exported_symbols_list with a modified structure starts to get in the right way
20:39:54  <tjfontaine>but still strips out all the important c++ v8 work
20:41:26  * jmar777quit (Remote host closed the connection)
20:44:07  * mikealjoined
20:48:10  * mikealquit (Client Quit)
20:49:23  * kuebk^joined
20:49:35  <kuebk^>hi
20:50:06  <kuebk^>has anyone experienced v8::String::Utf8Value::length() returning not correct length?
20:52:35  * loladiroquit (Quit: loladiro)
20:54:42  * c4miloquit (Read error: No route to host)
20:54:48  * c4milojoined
20:55:44  * kazuponjoined
20:55:53  * `3rdEdenjoined
20:58:27  * paddybyersjoined
20:59:19  * loladirojoined
21:00:56  * kazuponquit (Ping timeout: 255 seconds)
21:03:53  <indutny>kuebk^: that depends on what you're expecting by correct length :)
21:05:42  <kuebk^>total bytes of characters, right?
21:06:43  <bnoordhuis>$ du -sh chromium/
21:06:44  <bnoordhuis>11G chromium/
21:06:52  <bnoordhuis>that's a clean checkout...
21:07:11  <bnoordhuis>good thing chromium is a lightweight browser...
21:07:37  <kuebk^>indutny but that doesnt really matter
21:07:43  <saghul>bnoordhuis about those prepares, I think I found a weird bug (test case included) https://github.com/joyent/libuv/issues/605
21:07:50  * TooTallNatequit (Ping timeout: 246 seconds)
21:07:54  <bnoordhuis>saghul: i'll have a look
21:08:01  <saghul>kewl
21:08:43  <indutny>kuebk^: bytes or characters?
21:09:03  <indutny>kuebk^: I think it should return the latter one
21:09:13  <indutny>bnoordhuis: :)
21:09:16  <kuebk^>total number of characters
21:09:17  <indutny>bnoordhuis: I got used to it
21:09:17  <kuebk^>sorry
21:09:24  <kuebk^>that's what I meant
21:09:24  <indutny>bnoordhuis: gclient sync and everything
21:09:30  <indutny>kuebk^: hm... odd
21:09:34  <kuebk^>but that's not the point
21:09:42  <indutny>kuebk^: on what string does it fail?
21:09:51  <indutny>bnoordhuis: are you using svn or git?
21:09:54  <kuebk^>let me run gdb
21:09:55  <indutny>bnoordhuis: for chromium
21:09:59  <bnoordhuis>indutny: git svn clone -rHEAD
21:10:06  <indutny>bnoordhuis: ah
21:10:17  <indutny>bnoordhuis: and is it workging? :)
21:10:22  <tjfontaine>git gc --agressive [and pray you have enough memory]
21:10:36  <tjfontaine>+g
21:10:37  <bnoordhuis>indutny: haven't tried to build it yet. actually, i just wanted to steal some code
21:10:42  <indutny>bnoordhuis: oh
21:10:46  <indutny>ok, then
21:10:51  <indutny>because it has a lot of dependencies
21:11:15  * TooTallNatejoined
21:11:46  * jmar777joined
21:13:08  <tjfontaine>so someone should probably add 'DEAD_CODE_STRIPPING': 'YES', to xcode_settings in common.gypi, that nukes 1.5M of binary size :P
21:13:54  * rendarquit
21:15:07  <bnoordhuis>tjfontaine: for node?
21:15:11  <tjfontaine>bnoordhuis: ya
21:15:14  <bnoordhuis>do native add-ons still work?
21:15:37  <tjfontaine>they did, lemme double check, it doesn't strip much for symbols I mean all of openssl and uv are still there
21:15:51  <bnoordhuis>i thought the thing with -dead_strip is that you need to be extra careful to keep all symbols around
21:16:01  <tjfontaine>possibly
21:17:17  <tjfontaine>sigh
21:19:01  * loladiroquit (Quit: loladiro)
21:19:54  <bnoordhuis>tjfontaine: no luck?
21:20:19  <tjfontaine>bnoordhuis: no, I'm trying with PRESERVE_DEAD_CODE_INITS_AND_TERMS turned on though
21:20:50  <tjfontaine>because module loading was broken
21:21:21  <tjfontaine>I didn't check to see if it was just otool missing symbols or what though
21:21:40  <bnoordhuis>tjfontaine: does PRESERVE_DEAD_CODE_INITS_AND_TERMS actually do anything?
21:21:44  <tjfontaine>bnoordhuis: did you know that the osx linker just reexports everything regardless?
21:21:48  <tjfontaine>bnoordhuis: we're going to find out :)
21:22:16  <tjfontaine>bnoordhuis: at least when it comes to static libraries
21:23:48  * c4milo_joined
21:23:49  * c4miloquit (Read error: Connection reset by peer)
21:24:32  * indexzeroquit (Quit: indexzero)
21:25:01  <tjfontaine>bnoordhuis: so ya, long story short preserve_dead_code... doesn't help, but we are definitely re-exporting just about every symbol in libuv and openssl
21:25:21  * c4milo_quit (Read error: Connection reset by peer)
21:25:29  * c4milojoined
21:25:48  <bnoordhuis>tjfontaine: is that good or bad?
21:26:03  * c4milo_joined
21:26:04  * c4miloquit (Read error: No route to host)
21:26:22  <tjfontaine>bnoordhuis: I guess that depends on your stand point, from the making "openssl-exports" branch work world there's nothing more that needs to be done
21:26:42  <bnoordhuis>tjfontaine: btw: perl -ne 'print "$1\n" while /\b([A-Z_]{2,})\b/g' tools/gyp/pylib/gyp/xcode_emulation.py | sort | uniq -c
21:26:50  <bnoordhuis>i don't think gyp understands PRESERVE_DEAD_CODE_INITS_AND_TERMS
21:27:08  <tjfontaine>bnoordhuis: from the we're shipping a binary that is about 2M larger than it necessarily needs to be (or 4MB since we do 386 and x64)
21:27:33  <tjfontaine>ugh why can't it just let it pass through :P
21:28:11  <tjfontaine>I could add it as a -Wl option
21:28:26  <tjfontaine>if there was an option for it
21:29:14  <tjfontaine>-no_dead_strip_inits_and_terms
21:30:27  * joshthecoderjoined
21:30:44  <bnoordhuis>tjfontaine: might make a nice gyp patch
21:30:54  * loladirojoined
21:31:04  <bnoordhuis>though maybe gyp does indeed pass it through, i haven't tried
21:31:25  <tjfontaine>bnoordhuis: indeed, though if I start to go down that path I'll also fix the fact that we can't build fat binaries in one pass
21:31:43  <tjfontaine>just haven't had the motivation thus far to do that
21:37:19  <isaacs>piscisaureus_: yeah, i'm sure.
21:37:21  <isaacs>piscisaureus_: why, what's missing?
21:37:58  <piscisaureus_>isaacs: https://github.com/joyent/node/commit/fa94f0fe8338fcd7832a1146a4d847b27dea9a55
21:38:04  <piscisaureus_>isaacs: ^-- was missing
21:38:14  <piscisaureus_>isaacs: I'm not here btw.
21:38:19  <isaacs>piscisaureus_: v0.8 or master?
21:38:20  <isaacs>oh, ok
21:38:23  <isaacs>have fun in your absence :)
21:38:24  <piscisaureus_>maaaster
21:39:31  <isaacs>hm. weir
21:39:32  <isaacs>d
21:40:09  <isaacs>piscisaureus_: looks like that was dropped off a few V8 upgrades ago
21:40:17  <piscisaureus_>ah ok
21:40:23  <isaacs>piscisaureus_: i usually just gather up the patches between the last update and this one
21:40:39  <isaacs>piscisaureus_: should probably go back to running a diff and applying it
21:41:00  <isaacs>(ie, diff deps/v8 against the pristine copy)
21:41:24  <piscisaureus_>isaacs: whatever works for you :-)
21:41:32  <piscisaureus_>isaacs: I actually prefer landing all patches individually
21:41:41  <piscisaureus_>isaacs: as long as you do it carefully :-)
21:41:50  <piscisaureus_>ok, I'm really not here. Take care guys.
21:41:57  <isaacs>i apply individually then commit at once.
21:42:01  <isaacs>ok, cheers, later, piscisaureus_
21:45:19  * hzquit (Disconnected by services)
21:45:23  * hzjoined
21:50:40  * loladiroquit (Quit: loladiro)
21:51:03  * AvianFlu_joined
21:52:07  * AvianFluquit (Disconnected by services)
21:52:10  * AvianFlu_changed nick to AvianFlu
21:55:22  * jmar777quit (Remote host closed the connection)
21:57:49  * jmar777joined
21:58:02  * loladirojoined
21:58:21  * stagasjoined
21:58:50  * loladiroquit (Client Quit)
22:08:08  * bnoordhuisquit (Ping timeout: 272 seconds)
22:11:02  * AvianFluquit (Remote host closed the connection)
22:17:59  * kuebk^quit
22:18:52  * `3rdEdenquit (Remote host closed the connection)
22:19:21  * bnoordhuisjoined
22:19:28  * `3rdEdenjoined
22:22:59  * jmar777quit (Remote host closed the connection)
22:33:35  * hzquit
22:35:09  * stagasquit (Ping timeout: 240 seconds)
22:38:14  * `3rdEdenquit (Remote host closed the connection)
22:48:36  * c4milo_quit (Remote host closed the connection)
22:48:52  <bnoordhuis>isaacs: are you planning to release a new v0.8 this week?
22:49:05  * kazuponjoined
22:51:10  <mmalecki>bnoordhuis: did that v8 patch go into v0.8?
22:51:15  <bnoordhuis>mmalecki: yes
22:51:23  <mmalecki>great, thanks
22:51:55  * `3rdEdenjoined
22:53:50  * loladirojoined
22:54:10  * kazuponquit (Ping timeout: 240 seconds)
23:00:21  * benoitcquit (Excess Flood)
23:06:55  * piscisaureus_quit (Ping timeout: 244 seconds)
23:08:21  * benoitcjoined
23:14:20  * `3rdEdenquit (Remote host closed the connection)
23:16:17  <isaacs>bnoordhuis: yeah, let's do a v0.8 tomorrow
23:16:44  * paddybyersquit (Ping timeout: 244 seconds)
23:16:47  <isaacs>there's about 3 inches of commits since 0.8.12, so it's about time
23:24:27  * wankdankerjoined
23:40:36  * kuplatup1uquit (Ping timeout: 272 seconds)
23:40:43  * kuplatupsujoined