00:03:31  * AvianFlu_quit (Ping timeout: 255 seconds)
00:03:59  * mikealjoined
00:04:25  * AvianFlu_joined
00:04:55  * dapjoined
00:05:07  * AvianFlu_changed nick to AvianFlu
00:06:26  <ryah>have i mentioned that i hate computers?
00:06:30  <ryah>sigh
00:06:41  <sh1mmer>don't we all
00:09:39  <ryah>we can fix messages by having a fs.BlockingWriteStream
00:10:44  <ryah>^-- bnoordhuis does this sound okay to you?
00:11:03  <bnoordhuis>ryah: sounds java-y
00:11:18  <ryah>fs.SyncWriteStream...
00:11:20  <ryah>whatever
00:11:27  <bnoordhuis>hrm, i suppose so
00:11:31  <ryah>for process.stderr and process.stdout
00:11:45  <piscisaureus_>ryah: how will that hook into libuv
00:12:05  <ryah>piscisaureus_: it will use fs.writeSync
00:12:30  <piscisaureus_>ryah: will not work when node is spawned by another node process
00:12:49  <ryah>yeah - for pipes the output streams will still be non-blocking
00:13:07  <piscisaureus_>ryah: test-message uses pipes right?
00:13:22  <ryah>no, i believe it uses files
00:14:17  <ryah>yeah it uses a tmpfile
00:14:45  <piscisaureus_>oh okay good
00:15:33  <piscisaureus_>ideally we would have a mechanism to properly flush stderr
00:17:00  <ryah>https://github.com/joyent/node/blob/143aeb9ea716b1af0baeb700903961612b457143/tools/test.py#L508-524
00:19:44  <sh1mmer>anyone care if I close all the cygwin bugs?
00:20:11  <piscisaureus_>nope
00:22:50  <bnoordhuis>https://github.com/bnoordhuis/node/compare/http-abort <- quick review anyone?
00:27:37  <ryah>bnoordhuis: one sec
00:29:16  <ryah>bnoordhuis: LGTM
00:29:23  <bnoordhuis>ryah: cool, thanks
00:29:28  <igorzi>https://github.com/igorzi/node/commit/f3984abb02571292d5a5de98516cc6e820e0461d
00:29:53  <igorzi>someone review pls --^
00:29:58  <igorzi>(process.kill)
00:30:17  <ryah>igorzi: okay - one sec
00:30:29  <CIA-95>node: Ben Noordhuis master * r359a65a / (lib/http.js test/simple/test-http-abort-before-end.js):
00:30:29  <CIA-95>node: http: emit Error object after .abort()
00:30:29  <CIA-95>node: It was emitting the net.Socket object due to misuse of the arguments object.
00:30:29  <CIA-95>node: Fixes #1399. - http://git.io/Udsl3A
00:32:54  <ryah>igorzi: LGTM
00:33:30  <igorzi>ryah: thx
00:34:51  <CIA-95>node: Igor Zinkovsky master * r24a69d2 / (4 files in 2 dirs): process.kill to use uv_kill - http://git.io/S2cmqw
00:50:39  * kuebkquit
00:51:51  * ericktquit (Quit: erickt)
00:59:15  * sh1mmerquit (Quit: sh1mmer)
01:04:36  <igorzi>ryah: what is process.uptime() meant to return? node uptime? or system uptime?
01:07:33  <bnoordhuis>bleh, i broke the freebsd build
01:08:48  <bnoordhuis>igorzi: system uptime
01:09:33  <igorzi>aha, so the docs are wrong? - http://nodejs.org/docs/v0.5.10/api/process.html#process.uptime
01:10:11  * wankdanker1joined
01:12:49  <igorzi>also, this test seems to indicate that it expects process.uptime() to be node uptime
01:12:56  <igorzi>bnoordhuis: --^
01:13:05  <igorzi>https://github.com/joyent/node/blob/master/test/pummel/test-process-uptime.js
01:15:08  <bnoordhuis>igorzi: just checked, process.uptime() calls Platform::GetUptime() and that returns the system uptime
01:15:27  <bnoordhuis>so the docs are wrong and that test is simply odd :)
01:15:55  <bnoordhuis>oh wait, i take that back
01:16:05  <bnoordhuis>double Platform::prog_start_time = Platform::GetUptime();
01:16:07  <bnoordhuis>*sigh*
01:16:39  <piscisaureus_>bnoordhuis: is fprintf from a signal handler?
01:17:01  <bnoordhuis>piscisaureus_: you mean is it allowed?
01:17:02  <igorzi>bnoordhuis: :). but the fact that this test exists means that assert.ok(process.uptime() <= 2) works on some platforms?
01:17:18  <piscisaureus_>bnoordhuis: yes, I forgot the `allowed` part
01:17:38  <bnoordhuis>igorzi: yes
01:17:50  <bnoordhuis>piscisaureus: no, it's not allowed - write(2) is though
01:18:33  <bnoordhuis>piscisaureus_: `man 7 signal` has a list of signal-safe functions
01:18:40  <piscisaureus_>bnoordhuis: https://github.com/joyent/node/blob/master/src/node.cc#L2327
01:19:48  <bnoordhuis>piscisaureus_: yeah, that's bad
01:20:54  <igorzi>bnoordhuis: actually, Platform::GetUptime() -> return GetUptimeImpl() - prog_start_time;
01:21:11  <igorzi>bnoordhuis: so it seems that the docs are right then
01:21:15  <bnoordhuis>igorzi: yes
01:22:05  <igorzi>ah, the issue is that we don't do "double Platform::prog_start_time = Platform::GetUptime();" on windows
01:23:26  * wankdanker1quit (Read error: Connection reset by peer)
01:23:30  * wankdanker2joined
01:23:59  * wankdanker2quit (Client Quit)
01:28:31  * brsonquit (Quit: leaving)
01:28:38  <CIA-95>node: Igor Zinkovsky master * r434ccd2 / src/platform_win32.cc : fix process.uptime() on windows - http://git.io/xoL75g
01:29:47  * dapquit (Quit: Leaving.)
01:38:11  * AvianFluquit (Quit: Leaving)
01:41:14  <CIA-95>libuv: Ben Noordhuis master * r77a2477 / src/unix/core.c : unix: add EAI_NODATA #ifdef guard, freebsd doesn't have it - http://git.io/wo7-yA
02:02:02  <piscisaureus_>node.js:201
02:02:02  <piscisaureus_> throw e; // process.nextTick error, or 'error' event on first tick
02:02:02  <piscisaureus_> ^
02:02:02  <piscisaureus_>TypeError: Object function statPath(path) {
02:02:02  <piscisaureus_> var fs = NativeModule.require('fs');
02:02:02  <piscisaureus_> try {
02:02:02  <piscisaureus_> return fs.statSync(path);
02:02:03  <piscisaureus_> } catch (ex) {}
02:02:03  <piscisaureus_> return false;
02:02:04  <piscisaureus_>} has no method 'isDirectory'
02:02:04  <piscisaureus_> at tryFile (module.js:139:23)
02:02:05  <piscisaureus_> at Function._findPath (module.js:180:18)
02:02:05  <piscisaureus_> at Function._resolveFilename (module.js:332:25)
02:02:06  <piscisaureus_> at Function._load (module.js:279:25)
02:04:57  <piscisaureus_>^-- ryah: is the stats object supposed to have an isDirectory *function*?
02:05:18  * mikealquit (Quit: Leaving.)
02:07:26  <piscisaureus_>hmm. looks like it.
02:12:11  <CIA-95>libuv: Igor Zinkovsky master * r0fb3769 / (src/win/fs-event.c test/test-fs-event.c test/test-list.h): windows: don't emit fs-event callback after uv_fs_event handle is closed - http://git.io/Gaklgw
02:14:18  <bnoordhuis>piscisaureus_: do a make distclean, i fixed that bug this afternoon
02:14:41  <bnoordhuis>by rolling back v8 btw
02:14:57  <piscisaureus_>kthnx
02:15:07  <piscisaureus_>seems that v8 is a little fucked up atm
02:15:10  <bnoordhuis>yeah
02:15:24  <bnoordhuis>let's switch to luajit
02:15:39  <bnoordhuis>i think i saw a js2lua script somewhere
02:16:08  <piscisaureus_>it probably doesn't work
02:16:20  <piscisaureus_>I'm going to sue apple btw
02:16:36  <bnoordhuis>why?
02:16:52  <bnoordhuis>i mean, i can think of a 1000 reasons
02:16:54  <piscisaureus_>Working with a macbook on the lap is srsly bad for the reproductive organs
02:17:04  <piscisaureus_>much worse than my hp laptop to be precise
02:17:10  <bnoordhuis>oh, i don't think you have worry about that
02:17:13  <bnoordhuis>*to worry
02:17:14  <piscisaureus_>this thing is literally roasting my balls
02:17:37  <bnoordhuis>hmm, roasted nuts
02:17:45  * bnoordhuisgoes off to the kitchen
02:26:48  <CIA-95>node: Ben Noordhuis master * r818f0cb / deps/v8/src/platform-freebsd.cc : v8: fix freebsd build, implement VirtualMemory class - http://git.io/yuq_hw
02:26:48  <CIA-95>node: Ben Noordhuis master * r52eaac4 / (4 files in 3 dirs): uv: upgrade to 0fb3769 - http://git.io/8vDHxA
02:35:03  <piscisaureus_>\o/ this strategy at least works
02:46:59  <CIA-95>node: Bert Belder debugProcess * r72c736d / (src/node.cc test/simple/test-debugger-client.js): process._debugProcess - http://git.io/NZqwNQ
02:49:10  <piscisaureus_>igorzi: it's work in progress, but do you think this solution is somewhat sensible: https://github.com/joyent/node/blob/72c736d031a87163636b2a75574603c47b6c575a/src/node.cc#L2227-2334 ?
02:49:32  * pfox___joined
03:12:59  <bnoordhuis>[17:18|% 100|+ 606|- 18]: Done <- freebsd - could be worse, could be better
03:13:04  * bnoordhuisis off to bed
03:17:17  * bnoordhuisquit (Ping timeout: 240 seconds)
03:41:41  * wankdanker_joined
03:46:56  * sh1mmerjoined
04:49:49  * igorzi_joined
04:52:42  <igorzi_>piscisaureus_: yeah, that looks sensible.i was thinking that to avoid the possible rebasing issue, node could create named shared mem, and write the virtual address of EnableDebugThreadProc there.
04:53:15  <igorzi_>(the name would be based on pid)
04:54:03  <igorzi_>then the debugger would get the address of EnableDebugThreadProc from shared mem, and use it for CreateRemoteThread
05:10:09  * sh1mmerquit (Read error: Connection timed out)
05:10:59  * wankdanker_quit (Read error: Connection reset by peer)
05:11:09  * sh1mmerjoined
05:27:22  * rmustaccpart
05:30:29  * sh1mmerquit (Read error: Connection timed out)
05:31:11  * sh1mmerjoined
05:40:05  * sh1mmerquit (Read error: Operation timed out)
05:41:17  * sh1mmerjoined
05:46:48  * igorzi_quit (Quit: Page closed)
06:03:58  * sh1mmerquit (Read error: Connection timed out)
06:04:20  * arlolrajoined
06:05:26  * sh1mmerjoined
06:10:51  <arlolra>is it correct / intuitive that if i symlink a file and then run it, node will search up the tree from the original file, and not the symlinked location, when searching for node_modules?
06:14:22  <raggi>IMO, no
06:14:56  <raggi>that means checking stat and readlink
06:16:50  * mikealjoined
06:23:35  <arlolra>thanks raggi
06:24:04  * sh1mmerquit (Read error: Connection timed out)
06:25:31  * sh1mmerjoined
06:39:52  * indutnyquit (Ping timeout: 244 seconds)
06:41:31  * arlolrapart ("Linkinus - http://linkinus.com")
06:50:27  * sh1mmerquit (Read error: Connection timed out)
06:51:34  * sh1mmerjoined
07:00:32  * indutnyjoined
07:00:45  * mikealquit (Quit: Leaving.)
07:05:47  * AvianFlujoined
07:06:30  * felixgejoined
07:11:35  * sh1mmerquit (Read error: Connection timed out)
07:13:42  * sh1mmerjoined
07:31:05  * sh1mmerquit (Read error: Connection timed out)
07:31:47  * sh1mmerjoined
07:39:41  * sh1mmerquit (Read error: Operation timed out)
07:41:51  * sh1mmerjoined
07:55:54  * sh1mmerquit (Quit: sh1mmer)
07:58:46  * bnoordhuisjoined
07:59:37  <bnoordhuis>piscisaureus: feature request: can you make your irc log bot send a daily digest?
08:03:51  <felixge>btw. I created a ticket for that EPIPE bug from last night: https://github.com/joyent/node/issues/1998
08:04:11  <felixge>couldn't figure out why close(0) fucks things up so badly
08:05:14  <felixge>I kind of assume that the 0 file descriptor will be re-assigned after being freed
08:05:46  <bnoordhuis>you should ask marc lehmann, he has an opinion on closing fd 0
08:07:51  <felixge>bnoordhuis: as in: don't do it?
08:08:10  <bnoordhuis>felixge: yeah - check the libev mailing list if you're interested
08:08:32  <bnoordhuis>it's the thread i started earlier this week
08:09:38  <felixge>trying to find it
08:09:41  <felixge>ah ok
08:16:37  <felixge>lol
08:16:41  <felixge>fun thread
08:17:28  <bnoordhuis>and you know that SOB eventually did fix it? he just didn't come out and say it
08:18:03  <felixge>SOB ?
08:18:19  <felixge>oh
08:18:32  <felixge>haha
08:18:47  <felixge>well, so my bug is probably tied to this libev bug?
08:20:39  <bnoordhuis>oh, not necessarily
08:20:47  <bnoordhuis>did you per chance strace it?
08:21:24  <bnoordhuis>by the way, you know we're probably not going to put out 0.4 releases any more, right?
08:21:43  <felixge>bnoordhuis: I didn't know that
08:22:10  <felixge>so no point in reporting fixing 0.4 bugs?
08:22:23  <felixge>reporting/fixing
08:22:58  <bnoordhuis>felixge: well... i kinda think we may need to extend support for 0.4 a little longer
08:23:16  <bnoordhuis>people won't be switching to 0.6 right away and there are some pretty bad bugs in 0.4 still
08:23:26  <felixge>yeah
08:23:36  <bnoordhuis>let's discuss it with ryah today
08:23:36  <felixge>this one can be worked around
08:23:43  <felixge>I'm doing process.stdin.destroy = function() {}
08:23:49  <felixge>which is a little silly, but works
09:47:56  <CIA-95>node: Ben Noordhuis master * r11d68eb / lib/fs.js :
09:47:57  <CIA-95>node: fs: make mkdir() default to 0777 permissions
09:47:57  <CIA-95>node: Fixes #1999. - http://git.io/cbMwhA
10:11:03  <indutny>bnoordhuis: ping
10:11:23  <bnoordhuis>indutny: pong
10:11:32  <bnoordhuis>you're going to ask about your pull reqs right?
10:11:36  <indutny>yep
10:11:58  <bnoordhuis>yeah, sorry - i hadn't exactly forgotten about them, just haven't gotten around to it
10:15:26  <indutny>ah, np
10:15:30  <indutny>just reminding
11:09:49  <CIA-95>node: koichik master * ra6dbe0f / doc/api/fs.markdown : docs: make fs.mkdir()'s mode argument an option. - http://git.io/Y5z2KQ
11:19:34  * felixgequit (Quit: felixge)
11:20:06  <piscisaureus_>bnoordhuis: are you serious about the daily digest?
11:20:08  <CIA-95>libuv: Carter Allen master * r1393ee7 / common.gypi : build: remove hard-coded GCC_VERSION setting (OS X/XCode) - http://git.io/yf_1YA
11:20:46  <piscisaureus_>bnoordhuis: I want to add a feature to link to a specific message
11:20:50  <piscisaureus_>and searching
11:20:56  <bnoordhuis>piscisaureus_: do i ever joke?
11:20:59  <piscisaureus_>but I never considered daily digest
11:21:43  <bnoordhuis>so... just got up?
11:21:54  <piscisaureus_>bnoordhuis: yeah
11:21:57  <bnoordhuis>hah
11:22:02  <piscisaureus_>I am going to walk to the office in 5 minutes
11:22:11  <piscisaureus_>I got up an hour ago or so actually
11:22:29  <bnoordhuis>yeah, that sounds like you
11:24:05  <bnoordhuis>indutny: i want to punt on merging #208
11:24:39  <indutny>bnoordhuis: cool
11:24:42  <piscisaureus_>bnoordhuis: it also sounds like you :-)
11:24:58  * piscisaureus_changed nick to bn00rdhuis
11:25:06  <bnoordhuis>piscisaureus_: actually, i've been awake since 11 PM :/
11:25:15  <bn00rdhuis>that's just a coincidence
11:25:28  <bnoordhuis>no, SF fscked up my day/night cycle
11:25:37  <bnoordhuis>indutny: let me explain
11:25:50  <bn00rdhuis>bnoordhuis is not mergin 208
11:25:57  <bn00rdhuis>not now
11:26:05  <indutny>ah
11:26:07  <indutny>not cool
11:26:08  <indutny>:D
11:26:17  <bnoordhuis>i told you to use mutexes around the title getters and setters
11:26:26  <bnoordhuis>which is fine for node
11:27:00  <bnoordhuis>but there's a problem when other projects use libuv, call setproctitle in one thread and call fork() in another
11:27:36  <bnoordhuis>the child process will have its locks in an inconsistent state because the lock is owned by a thread that no longer exists...
11:27:49  <indutny>bnoordhuis: oh, not good
11:27:56  <bnoordhuis>no
11:28:06  <bnoordhuis>and my bad, i hadn't thought of that when we last discussed it
11:28:14  * bn00rdhuischanged nick to piscisaureus_
11:28:17  <bnoordhuis>sorry about that
11:28:23  <piscisaureus_>so, just add a lock around fork :-)
11:28:26  <indutny>bnoordhuis: np
11:28:28  <indutny>hahaha
11:28:38  <piscisaureus_>bnoordhuis: we had it coming anyway
11:29:43  <bnoordhuis>piscisaureus_: that's what she said
11:29:48  <bnoordhuis>okay, off to lunch
11:30:06  <bnoordhuis>want to do a beer this week? i still owe you a few
11:39:08  * wankdanker_joined
11:53:40  * piscisaureus_quit (Ping timeout: 258 seconds)
11:58:11  * piscisaureus_joined
11:59:11  * felixgejoined
11:59:11  * felixgequit (Changing host)
11:59:12  * felixgejoined
12:00:51  * wankdanker_quit (Remote host closed the connection)
12:02:23  * piscisaureus_quit (Ping timeout: 248 seconds)
12:33:24  * piscisaureus_joined
12:33:47  <piscisaureus_>bnoordhuis: this week is not going to work. Next week +1
13:09:05  <piscisaureus_>indutny: yt?
13:09:08  <indutny>piscisaureus_: yep
13:09:18  <indutny>wassup?
13:09:22  <piscisaureus_>indutny: how can I connect the node debugger to an existing node process
13:09:34  <indutny>piscisaureus_: node debug -p pid probably
13:10:15  <piscisaureus_>ah, okay
13:13:04  <indutny>piscisaureus_: is it working? :D
13:13:12  <piscisaureus_>indutny: no
13:13:42  <piscisaureus_>indutny: the problem is that the "signal" that gets sent to the other process actually runs in another thread
13:13:50  <piscisaureus_>indutny: so v8 never really breaks
13:14:40  <piscisaureus_>also, I have serious doubts about how the debug signal is handled
13:15:18  <piscisaureus_>I don't think v8 really gives us the guarantee that Debug::EnableAgent is async signal-safe
13:15:28  <indutny>piscisaureus_: v8 will not break
13:15:34  <indutny>until event loop will reach some js code
13:15:43  <piscisaureus_>indutny: I know
13:15:50  <piscisaureus_>indutny: but it doesn't break after that either
13:15:56  <indutny>strange, as it works for me
13:16:10  <piscisaureus_>indutny: `node debug a.js` works for me
13:16:20  <indutny>piscisaureus_: `node debug -p 123`
13:16:23  * piscisaureus_quit (Read error: Connection reset by peer)
13:16:25  <indutny>works fine for me too
13:16:34  <indutny>when debugging some simple http server
13:16:35  * piscisaureus_joined
13:16:49  <piscisaureus_>indutny: sorry, my IM client crashed
13:17:00  <indutny>piscisaureus_: indutny> works fine for me too
13:17:00  <indutny> [19:16:33] <indutny> when debugging some simple http server
13:17:07  <indutny>brb
13:19:52  <indutny>piscisaureus_: so what's broken for you?
13:20:02  <indutny>can you fill issue with some stdout logs?
13:20:31  <piscisaureus_>indutny: when attach the debugger to a running program it doesn't break (on windows)
13:20:40  <indutny>piscisaureus_: on windows?
13:20:51  <indutny>is that program reporting anything?
13:21:00  <indutny>like Hit SIGUSR1 - starting debugger agent.
13:21:09  <piscisaureus_>indutny: I have a program that prints a counter every 100 ms
13:21:54  <indutny>piscisaureus_: Hit SIGUSR1 - starting debugger agent. ?
13:22:13  <piscisaureus_>indutny: well, it shows "hit CTRL+BREAK", but yeah
13:22:20  <indutny>piscisaureus_: that's odd
13:22:24  <piscisaureus_>indutny: but then the counters keep coming
13:22:33  <indutny>let me test it
13:22:34  <indutny>again
13:22:41  <piscisaureus_>indutny: I think that this is due to the fact that the "signal" handler runs in another thread
13:25:29  <indutny>piscisaureus_: dunno, I'll test it on windows
13:25:52  <piscisaureus_>indutny: did you find any documentation on the v8 debugger?
13:26:07  <indutny>piscisaureus_: I patched it so I merely know how it works
13:26:31  <piscisaureus_>indutny: what would happen if you call Debugger::DebugBreak from another thread
13:26:47  <piscisaureus_>would it patch the stack limit in the right spot?
13:26:52  <indutny>it should flood current isolate() with OneShotHandlers
13:27:05  <indutny>that shouldn't matter
13:28:37  <piscisaureus_>indutny: and the debugger agent... on what thread is that supposed to run?
13:31:20  <piscisaureus_>indutny: nothing gets patched, i'm sure
13:31:38  <indutny>it should patch default isolate
13:31:41  <indutny>as I know
13:31:44  <piscisaureus_>indutny: it only sets the stack limit
13:31:50  <piscisaureus_>well, that's what happens
13:32:00  <piscisaureus_>I believe you when you say that is what should happen :-)
13:32:50  <piscisaureus_>indutny: the other thing I am worried about is the async safety of starting the debugger agent.
13:33:19  <indutny>hm...
13:33:25  <indutny>we need mraleph :D
13:33:59  <piscisaureus_>yes
13:34:08  <indutny>piscisaureus_: https://github.com/v8/v8/blob/master/src/api.cc#L5335
13:34:38  <piscisaureus_>indutny: yes, I know that :-)_
13:34:58  <indutny>:)
13:35:14  <piscisaureus_>indutny: that function does not put any OneShotHandlers in place
13:35:16  <piscisaureus_>for me
13:35:26  <indutny>and that's quite odd
13:35:30  <indutny>brb
13:36:04  <indutny>piscisaureus_: I sent mraleph a message
13:41:23  <piscisaureus_>indutny: at the very least I can tell that the current isolate is thread-local
13:41:36  <piscisaureus_>so it won't work from another thread
13:45:43  <indutny>hm....
13:49:17  * mralephjoined
13:50:18  * mralephappears in the puff of smoke
13:51:12  <piscisaureus_>mraleph: wow, how did you do that
13:51:23  <mraleph>:-)
13:51:30  <piscisaureus_>mraleph: how are doing btw?
13:51:50  <mraleph>I am doing great, and you?
13:52:10  <piscisaureus_>I'm fine. Thanks. I am living in amsterdam for a while, I like that.
13:52:31  <mraleph>magic mushrooms are great indeed :-)
13:53:08  <mraleph>I should come have a beer with you there someday
13:53:27  <piscisaureus_>mraleph: yeah. come on over here!
13:53:38  <piscisaureus_>mraleph: srsly
13:53:44  <piscisaureus_>mraleph: my question is about the debugger
13:54:35  <piscisaureus_>mraleph: right now, node calls Debugger:DebugBreak and Debugger::EnableAgent from the signal handler
13:55:01  <piscisaureus_>mraleph: (1) is EnableAgent async safe? Or are we not really supposed to be doing that?
13:55:44  <mraleph>oh you ask difficult questions :-)
13:55:51  <mraleph>let me take a look
13:56:42  <piscisaureus_>mraleph: (2) can I also invoke DebugBreak from another thread? (since windows has no signals). It does not work for me atm because DebugBreak fetches the default isolate from TLS which does not point to the isolate we care about. But suppose we would pass an isolate explicitly, would that work?
13:58:00  <piscisaureus_>mraleph: I kind of suppose that there is some way of interrupting a running v8 isolate on windows
14:04:48  <mraleph>piscisaureus_: it uses Isolate::Current so well you need to ensure that you are calling it from the thread that has a proper current isolate.
14:04:55  <mraleph>otherwise it should be fine
14:06:03  <mraleph>yes DebugBreak should be invocable from the another thread.
14:08:44  <piscisaureus_>mraleph: so can I set the current isolate of a thread somehow?
14:08:56  <mraleph>isolate->Enter
14:11:24  <piscisaureus_>mraleph: so that's one problem solved :-) thanks
14:11:37  <piscisaureus_>mraleph: now about the EnableAgent stuff
14:12:24  <mraleph>that was about EnableAgent
14:12:38  <mraleph>DebugBreak is callable from any other thread
14:12:47  <mraleph>and it accepts isolate as an argument
14:12:56  <piscisaureus_>aah ok
14:13:12  <piscisaureus_>mraleph: so if EnableAgent is called from a short-lived thread it's no problem
14:13:29  <piscisaureus_>the actual cargo like reading messages etc will be done from another thread?
14:13:50  <piscisaureus_>s/from/in/
14:15:28  <mraleph>Debugger agent is a separate thread
14:15:34  <piscisaureus_>hmm
14:15:54  <piscisaureus_>mraleph: that basically makes EnableAgent async unsafe
14:16:03  <piscisaureus_>since it'll have to pthread_create or something
14:16:31  <mraleph>I dunno what you mean by async safe but it should be safe to start an agent even if you don't own exclusive access to isolate.
14:16:59  <piscisaureus_>mraleph: I mean, we start it from a signal handler (on linux etc)
14:17:15  <mraleph>yeah, it should work in most cases.
14:17:25  <piscisaureus_>:-)
14:17:53  <indutny>:D
14:17:59  <indutny>piscisaureus_: it was working for me on windows
14:18:02  <indutny>I'm pretty sure
14:18:14  <indutny>mraleph: but debugger is quite... em... you know, buggyu
14:18:23  <indutny>it's not even always connecting
14:18:28  <mraleph>well. what can I say
14:18:32  <mraleph>patches are welcome
14:18:36  <indutny>:)
14:19:39  <piscisaureus_>mraleph: btw our office wants a dart board
14:19:51  <piscisaureus_>does google ship dart boards already?
14:22:52  <mraleph>:-)
14:23:44  <piscisaureus_>mraleph: seriously. you guys have made this joke for over a year now :-)
14:26:24  * mafintoshjoined
14:28:31  <mraleph>piscisaureus: ^^^ you should ask mafintosh for dart boards ^^^
14:28:41  <mraleph>piscisaureus_: ^^^ :-)
14:29:39  <piscisaureus_>mafintosh?
14:30:16  <mafintosh>yes?
14:30:21  <mraleph>argh
14:30:26  <mraleph>I am going crazy
14:30:51  <piscisaureus_>mafintosh, can we have a dart board?
14:30:53  <mraleph>that would be munificent
14:31:11  <mraleph>I am mixing people in my mind.
14:31:23  <mraleph>like a cocktail
14:31:34  <piscisaureus_>mraleph: I totally lost it
14:31:47  <piscisaureus_>mraleph: what's going on
14:32:31  <mraleph>piscisaureus_: munificent is Bob Nystrom's nickname, he is on dart team.
14:32:44  <piscisaureus_>aah
14:33:02  <mraleph>piscisaureus_: munificent looks almost as mafintosh; especially after the day of C++ programming.
14:33:25  <piscisaureus_>does he have his keyboard printed on his forehead? :-)
14:33:27  <mraleph>(I mean to words look similar :-))
14:33:49  <piscisaureus_>lol
14:33:50  <piscisaureus_>omg
14:33:51  <mraleph>s/to/two/
14:34:02  <piscisaureus_>mraleph: you should take a break I think
14:34:05  <mafintosh>you're on a roll
14:34:09  <mafintosh>:)
14:34:19  <mraleph>back to C++
14:46:14  <mafintosh>Is it on purpose that timeouts on sockets in v.5.10 occur even though you are writing at a regular interval, e.g. 1sec (but not reading anything) ?
14:47:10  <piscisaureus_>not that I know
14:47:15  <piscisaureus_>what kind of timeout?
14:48:01  <mafintosh>just a regular socket timeout
14:48:13  <mafintosh>let me upload a gist to show what I mean...
14:49:03  <mafintosh>https://gist.github.com/1336685
14:49:39  <mafintosh>in v.4.12 this socket would stay alive - in v.5.10 it closes after 10 sec (the specified timeout)
14:52:37  <piscisaureus_>mafintosh: yeah, looks that a `timers.active(self)` statement was omitted
14:52:50  <piscisaureus_>in socket.write
14:52:55  <piscisaureus_>Maybe it was on purpose
14:53:09  * isaacsjoined
14:53:54  <mafintosh>arh - yes just saw that myself also. seems to be this commit: https://github.com/joyent/node/blob/be0bb2dc136ca20b44da81cded790417cbd1cfd2/lib/net.js
14:54:25  <piscisaureus_>mafintosh: yeah, that's just a rename commit where net.js got replaced by net_uv.js
14:55:34  <mafintosh>the problem is that this makes streaming back large files from an http server hard as the connection times out even though it's very active :/
14:56:29  <piscisaureus_>mafintosh: https://github.com/joyent/node/issues/2002
14:59:26  <mafintosh>piscisaureus_ thanks - should probably just have opened that myself :)
15:29:03  <piscisaureus_>mraleph: sadly, Debugger::DebugBreak(theisolate) doesn't do anything
15:29:22  <mraleph>hmm.
15:29:39  <mraleph>if you debugger is enabled it should do something :-)
15:29:51  <mraleph>if it is not I don't think it will do anything.
15:31:50  <piscisaureus_>mraleph: we started the debugger with Debugger::EnableAgent
15:32:17  <mraleph>well then DebugBreak should request a break.
15:32:30  <mraleph>I think :-)
15:32:45  <mraleph>I am not into debugger myself.
15:33:13  <piscisaureus_>hmm
15:33:14  <piscisaureus_>okay
15:33:19  <piscisaureus_>mraleph: thnx anyway
15:34:01  <mraleph>how do you determine that nothing happens?
15:34:33  <piscisaureus_>mraleph: well my script runs `setInterval(function() { console.log(++i); }, 100)`
15:34:38  <piscisaureus_>mraleph: and it keeps going
15:34:50  <piscisaureus_>unlike on linux
15:35:16  <piscisaureus_>the only difference is that on windows the DebugBreak is called from a thread and on linux it's called from a signal handler
15:37:37  <mraleph>hmm.
15:37:49  <mraleph>do you pass the right isolate into the DebugBreak?
15:38:02  <mraleph>you can actually pass nothing if you have only one isolate
15:38:12  <mraleph>(default one)
15:38:13  <piscisaureus_>mraleph: we have only one
15:38:16  <mraleph>ok
15:38:26  <mraleph>that's pretty spooky
15:38:29  <mraleph>might be a bug
15:38:56  <piscisaureus_>mraleph: also, I tried picking up the isolate with
15:38:56  <piscisaureus_>Isolate* the_isolate = Isolate::Current(); <-- on the main thread
15:39:11  <piscisaureus_>and passing that, but that didn't make any difference
15:40:36  <mraleph>very strange.
15:41:09  <piscisaureus_>I am going to try invoke the debugger from the main thread
15:41:12  <piscisaureus_>see if that works
15:41:16  <mraleph>yeah.
15:42:25  <mraleph>try putting break point into v8::internal::Execution::DebugBreakHelper to see if it ever goes there.
15:42:52  <mraleph>and what happens there.
15:43:04  <mraleph>afk brb
15:44:29  <piscisaureus_>mraleph: it never gets there
15:45:10  <piscisaureus_>mraleph: I added an idle watcher that calls DebugBreak
15:45:17  <piscisaureus_>on the main thread
15:45:19  <piscisaureus_>that does work
15:47:31  * dapjoined
16:01:56  * piscisaureus_part
16:32:55  <mraleph>wierd stuff
16:36:40  * sh1mmerjoined
17:05:27  * AvianFluquit (Quit: Leaving)
17:07:34  * sh1mmerquit (Read error: Connection timed out)
17:08:43  * sh1mmerjoined
17:11:26  * ericktjoined
17:14:19  * brsonjoined
17:14:40  * sh1mmerquit (Quit: sh1mmer)
17:19:15  <ryah>hello
17:19:45  <ryah>bnoordhuis, felixge: we can do another v0.4 release
17:19:49  <ryah>but after v0.6.0
17:19:58  <bnoordhuis>hey ryah
17:20:00  <bnoordhuis>sure, no rush
17:20:13  <felixge>cool
17:20:25  <ryah>should we down grade V8 for v0.6 ?
17:21:22  <ryah>i'd rather keep v0.6 stuck to either 3.7 or 3.6 but i dont want to upgrade between them
17:21:41  <ryah>are we hitting bugs in 3.7 ?
17:22:59  <bnoordhuis>ryah: yes, check the commit log of edea4122b1c725a9f7873c02fe04100995472ddc
17:23:23  <bnoordhuis>i'd link you to it but big commits on github tend to freeze my browser
17:24:23  <ryah>bnoordhuis: okay let's go down to 3.6
17:24:31  <ryah>or?
17:24:45  <bnoordhuis>3.7.0 seems stable-ish
17:24:48  <bnoordhuis>but it's your call
17:24:52  <ryah>mraleph: yt?
17:25:22  <mraleph>yes
17:26:37  <ryah>mraleph: we're releasing v0.6 tomorrow. we need to choose either V8 3.7 or 3.6
17:27:04  <mraleph>I would recommend 3.6
17:27:09  <ryah>thank you.
17:27:11  <ryah>down we go.
17:29:28  <bnoordhuis>a "that's what she said" joke is appropriate here
17:29:29  <mraleph>but I should add that I am not aware of any bugs in 3.7, you should report them if you experienced something.
17:29:56  <mraleph>I am aware of a couple of things but they are in 3.6 as well.
17:29:56  <bnoordhuis>mraleph: will do, but the one big bug i ran into is kind of hard to reproduce or observe
17:30:06  <ryah>mraleph: we're going to be moving to a tighter release cycle - so we should see node 0.8 by january
17:30:13  <mraleph>ok
17:30:29  <mraleph>actually it's not simply ok, it's cool :-)
17:31:10  <mraleph>with a tight cycle like that 3.6 is the best bet.
17:31:39  <ryah>yep
17:32:32  <mraleph>ryah: also I need to say a couple of things to you via some kind of voice channel, skype, gtalk or something similar. not written media.
17:32:47  <mraleph>it's actually not a couple of things, but just a one thing :-)
17:33:17  <ryah>mraleph: heh - sounds enticing. now? skype?
17:34:14  <mraleph>unfortunately I can't use skype from here (and I am not sure it will work from home because my ISP at home is borked atm). It's not urgent though.
17:34:49  <ryah>mraleph: you can give me a call +1-415-400-0615
17:35:39  * piscisaureus_joined
17:36:25  <ryah>you guys should listen to Tomasz's podcast
17:36:34  <ryah>http://www.developerfusion.com/media/132116/tomasz-janczuk-builds-web-apps-with-nodejs/
17:37:20  <mraleph>ryah: ok, let me try to dial you.
17:37:33  <igorzi>piscisaureus_: are there any tests in node that depend on this: https://github.com/joyent/libuv/blob/master/src/win/process.c#L1006-1014 ?
17:37:58  <piscisaureus_>igorzi: eh, I'm not sure
17:38:14  <piscisaureus_>igorzi: you should try it
17:38:32  <piscisaureus_>igorzi: it makes it behave more similar to unix though
17:39:26  <igorzi>piscisaureus_: yeah, i tried it it works. i just want to see a test that shows what the expected behavior is (it's kind of strange that spawn doesn't throw if it fails)
17:40:59  <mraleph>ryah: did it go through?
17:41:25  <ryah>mraleph: did you just call? yes - but i could only hear myself
17:41:31  <mraleph>haha
17:41:35  <mraleph>the same on my end.
17:42:05  <mraleph>it was nice talking to myself. let me try through other phone.
17:42:11  * ericktquit (Quit: erickt)
17:45:34  <mraleph>ok this time it worked as expected :-)
17:45:43  <CIA-95>node: Ryan Dahl master * r0e9c1ca / (308 files in 24 dirs): Downgrade V8 to 3.6.4 - http://git.io/gqgoWQ
17:46:33  <CIA-95>node: Ryan Dahl master * r2dd68af / deps/v8/SConstruct : Remove -Werror from V8 build - http://git.io/tWpq5A
17:49:20  <bnoordhuis>piscisaureus igorzi ryah: call in 10?
17:49:30  <piscisaureus_>I'm fine
17:49:54  * ericktjoined
17:49:59  <ryah>yes
17:50:34  <igorzi>yep
17:51:30  <ryah>https://github.com/joyent/node/pull/2001/files <-- this looks like a good test
17:51:36  <ryah>but is failing
17:51:37  <ryah>im going to merge
17:54:24  <CIA-95>node: Maciej MaƂecki master * r481c175 / test/simple/test-net-pipe-connect-errors.js :
17:54:24  <CIA-95>node: test error codes related to pipes
17:54:24  <CIA-95>node: This tests passes on node v0.4, but fails on node v0.5. v0.5 seems to
17:54:24  <CIA-95>node: generally lack error codes for various error events related to UNIX
17:54:24  <CIA-95>node: pipes.
17:54:25  <CIA-95>node: Fixes #2001 - http://git.io/YvdixA
18:04:20  * kuebk^joined
18:05:53  <piscisaureus_>ryah: call?
18:07:31  <piscisaureus_>igorzi: call
18:07:48  <igorzi>yeah, you can't reach me again?
18:08:40  * sh1mmerjoined
18:09:41  <ryah>igorzi: crashed?
18:10:16  <igorzi>ryah: no :). does it show that i'm offline?
18:10:32  * AvianFlujoined
18:10:35  <ryah>igorzi: yes
18:11:39  <ryah>igorzi: try restarting skype
18:12:18  <ryah>igorzi: what's your land line number? we'll call you
18:16:35  * sh1mmerquit (Quit: sh1mmer)
18:17:22  <CIA-95>node: Ben Noordhuis master * r9c11e8a / (lib/net.js test/simple/test-pipe-address.js): net: implement Server.prototype.address() for pipes - http://git.io/Vdhlcw
18:21:00  * sh1mmerjoined
18:21:33  * felixgequit (Quit: felixge)
18:24:20  * pfox___quit (Quit: leaving)
18:25:08  * ericktquit (Quit: erickt)
18:45:59  <bnoordhuis>[15:58|% 100|+ 616|- 12]: Done <- linux
18:46:29  * AvianFluquit (Ping timeout: 260 seconds)
18:49:55  * AvianFlujoined
18:54:49  * sh1mmerquit (Quit: sh1mmer)
18:55:14  * AvianFluquit (Read error: Operation timed out)
18:58:26  <ryah>so many fails
19:02:53  * isaacsquit (Quit: isaacs)
19:03:45  <piscisaureus_>mraleph: yt?
19:05:01  <mraleph>yep
19:05:19  <piscisaureus_>mraleph: could it be that the stack limit is a per-thread value
19:05:21  <piscisaureus_>?
19:05:43  <mraleph>it is perisolate value.
19:05:43  <piscisaureus_>mraleph: that would mean that calling DebugBreak from another thread would not affect the main thread in any way
19:05:58  <mraleph>it should affect it
19:06:13  <mraleph>the whole interruption mechanism is designed to work from another thread.
19:06:24  <piscisaureus_>mraleph: the weird thing is that when I call debugbreak from the main thread then it works
19:06:35  <piscisaureus_>but when I step through it the execution flow is exactly the same
19:06:46  <mraleph>yeah. this is very strange. but I can't see where it goes balistic.
19:06:49  <piscisaureus_>and the isolate is also the same
19:07:01  <piscisaureus_>(i compared the pointer values)
19:07:04  <mraleph>I need to dig into it with the debugger.
19:08:32  * AvianFlujoined
19:12:49  <piscisaureus_>https://github.com/joyent/node/blob/master/deps/v8/src/execution.cc#L443-447
19:12:50  <piscisaureus_>https://github.com/joyent/node/blob/master/deps/v8/src/execution.cc#L50-57
19:12:50  <piscisaureus_>mraleph: ^-- what's that about then?
19:13:45  <mraleph>what do you mean?
19:13:58  <piscisaureus_>mraleph: why is it called thread_local_?
19:14:15  <mraleph>historical reasons I would say :-)
19:14:37  <mraleph>btw.
19:15:09  <mraleph>maybe you are so lucky that every time you call DebugBreak it's in the postpone interrupts scope.
19:15:19  <mraleph>(e.g. inside GC)
19:19:05  <piscisaureus_>mraleph: then what? would it just ignore my DebugBreak call?
19:23:26  <mraleph>yep
19:23:27  <mraleph>:-)
19:23:31  <piscisaureus_>mraleph: what c++ function would be called when v8 is interupted?
19:23:57  <mraleph>DebugBreakHelper
19:37:23  <CIA-95>node: Ryan Dahl master * r4a8088a / (lib/net.js test/pummel/test-net-timeout2.js):
19:37:23  <CIA-95>node: Socket.write should reset timeout timer.
19:37:23  <CIA-95>node: Fixes #2002. - http://git.io/AGw19w
19:45:29  <piscisaureus_>mraleph: it seems that DebugBreakHelper is hit
19:45:32  <piscisaureus_>mraleph: so that's good
20:00:55  * isaacsjoined
20:07:41  * bnoordhuisquit (Ping timeout: 240 seconds)
20:10:41  <ryah>indutny: test-debugger-repl still timing out all the time
20:11:16  <ryah>indutny: btw the test runner has a timeout - you shouldn't need to include it in the test
20:11:29  <indutny>ryah: will it kill all node instances?
20:13:32  * ericktjoined
20:20:59  * isaacsquit (Read error: Connection reset by peer)
20:21:03  * isaacs_joined
20:21:28  <ryah>indutny: mm - it will kill the process it started
20:27:45  <isaacs_>how would you all feel about a Buffer.flatten(buf1, buf2, ...) method?
20:28:14  <isaacs_>i find myself doing this a lot, where i collect up an array of chunks, and then need to smoosh them all into a single big buffer.
20:28:48  * isaacs_changed nick to isaacs
20:28:54  <kuebk^>sounds good for me
20:29:08  <ryah>piscisaureus_: please review https://gist.github.com/1337693
20:32:55  <piscisaureus_>ryah: no rocket science. lgtm
20:33:47  <ryah>thanks
20:37:39  <CIA-95>node: Ryan Dahl master * ra936768 / (doc/api/process.markdown lib/fs.js src/node.js):
20:37:39  <CIA-95>node: stdout and stderr are blocking when referring to regular files
20:37:39  <CIA-95>node: Fixes message tests. - http://git.io/moo_Mg
20:43:50  <ryah>=== release test-debugger-repl ===
20:43:50  <ryah>Path: simple/test-debugger-repl
20:43:50  <ryah>Error: timeout!
20:43:50  <ryah>Command: out/Release/node /Users/ryan/projects/node/test/simple/test-debugger-repl.js
20:43:54  <ryah> :<
20:51:20  <indutny>sorry
20:51:22  <indutny>I was afk :)
20:53:20  <indutny>building master
20:53:24  <indutny>ryah: ^
20:53:28  <ryah>thanks
20:54:01  <indutny>[email protected]:~/Code/indutny/node > tools/test.py simple/test-debugger-repl
20:54:02  <indutny>[00:00|% 100|+ 1|- 0]: Done
20:54:07  <indutny>probably I'm missing something
20:54:10  <indutny>hm...
20:54:29  <indutny>oh I see now
20:54:37  <indutny>that's a race condition in v8
20:54:54  <indutny>lets just disable that test for now
20:55:23  <indutny>I'll investigate what's causing that problem a bit later
20:55:24  <ryah>why
20:55:37  <igorzi>ryah piscisaureus_: the changes i made to uv_kill+uv_process_kill (to only terminate process on SIGKILL and SIGTERM) broke https://github.com/joyent/node/blob/master/test/simple/test-sigint-infinite-loop.js on windows
20:55:40  <indutny>because as I can see problems comes from v8 side
20:55:56  <igorzi>what are the semantics of SIGINT? do we want to terminate on SIGINT as well?
20:56:03  <indutny>mraleph: yt?
20:56:07  <ryah>indutny: i prefer to continue to be annoyed at it :)
20:56:14  <indutny>ryah: haha :) ok
20:56:43  <piscisaureus_>igorzi: sigint is normally raised by the user pressing ctrl+c
20:56:58  <piscisaureus_>igorzi: yeah, I think we should kill on sigint as well
20:57:25  <ryah>nod
20:58:27  <igorzi>ok
20:59:32  <indutny>ryah: as you can see: https://github.com/joyent/node/blob/master/test/fixtures/breakpoints.js#L2 I'm already doing some hacks to get v8 break somewhere
20:59:52  <indutny>cc mraleph ^
21:03:48  <ryah>it's nice to have stdout be sync now
21:04:03  <ryah>doesnt' fuck up dtrace
21:04:09  <CIA-95>libuv: Igor Zinkovsky master * ree8a681 / src/win/process.c : windows: uv_kill and uv_process_kill to terminate the process on SIGINT - http://git.io/EYgn-g
21:08:38  <indutny>ryah: I investigated - it breaks on step out
21:08:50  <indutny>ryah: sometimes v8 steps too far from running code
21:10:42  <indutny>ryah: https://github.com/joyent/node/pull/2005
21:10:44  <ryah>indutny: ok
21:11:07  * isaacsquit (Read error: Connection reset by peer)
21:11:11  * isaacs_joined
21:11:56  <CIA-95>node: Fedor Indutny master * rb904a07 / test/simple/test-debugger-repl.js : report debugger's test errors - http://git.io/u4XHkA
21:27:51  * isaacs_changed nick to isaacs
21:35:35  <igorzi>ryah: is simple/test-regress-GH-1531.js passing on unix?
21:46:15  <piscisaureus_>indutny: yt?
21:57:35  <ryah>igorzi: yes
22:06:36  * AvianFlu_joined
22:08:11  * AvianFluquit (Disconnected by services)
22:08:14  * AvianFlu_changed nick to AvianFlu
22:14:39  <indutny>piscisaureus_: yep
22:14:47  <indutny>piscisaureus_: wassup?
22:22:19  <ryah>our compile time is horrible...
22:22:34  <ryah>i cant wait to be rid of waf
22:23:06  <piscisaureus_>indutny: why does the debugger issue a continue command straight after connecting?
22:23:31  <piscisaureus_>indutny: also, why is there no command to interrupt to program other than setting a breakpoint?
22:25:14  * felixgejoined
22:25:14  * felixgequit (Changing host)
22:25:14  * felixgejoined
22:33:07  * kuebk^quit
22:34:15  * felixgequit (Quit: felixge)
22:39:24  <pquerna>is VS express enough to use GYP?
22:40:28  <ryah>pquerna: yes
22:41:15  * isaacsquit (Read error: Connection reset by peer)
22:41:30  * isaacsjoined
22:47:53  <CIA-95>libuv: Ryan Dahl master * r0698e3f / (4 files in 3 dirs): Fix UNIX pipe connect error reporting, add test - http://git.io/dEbATQ
22:51:49  * ericktquit (Ping timeout: 258 seconds)
22:52:02  <ryah>^-- hopefully that works on windows
22:52:13  <ryah>i didn't test but it should
22:54:39  * mralephquit (Quit: Leaving)
22:57:17  <indutny>piscisaureus_: sorry, I'm sleeping right now
22:57:25  <indutny>don't you mind if we'll talk later
22:57:30  <indutny>anyway, ttyl :D
23:10:50  * mafintoshquit (Ping timeout: 244 seconds)
23:13:32  <CIA-95>libuv: Ryan Dahl master * r147487a / src/unix/error.c : UNIX: Error map ENOTSOCK - http://git.io/Bn7Bzg
23:22:04  <ryah>[% 0|+ 83|- 2]: fs_event_no_callback_on_close
23:22:04  <ryah>`fs_event_no_callback_on_close` failed: exit code 6
23:22:04  <ryah>Output from process `fs_event_no_callback_on_close`:
23:22:05  <ryah>Assertion failed: (revents == EV_LIBUV_KQUEUE_HACK), function uv__fs_event, file src/unix/kqueue.c, line 58.
23:22:08  <ryah>:/
23:23:30  <CIA-95>libuv: Ryan Dahl master * r681bd29 / (7 files in 5 dirs):
23:23:30  <CIA-95>libuv: UV_EACCESS -> UV_EACCES
23:23:30  <CIA-95>libuv: In order to match existing Node API. See
23:23:30  <CIA-95>libuv: https://github.com/joyent/node/pull/2001 - http://git.io/W3Kpdg
23:30:41  <CIA-95>libuv: Ryan Dahl master * r9c7ed0d / src/uv-common.c : One more EACCESS -> EACCES - http://git.io/baq6QA
23:35:31  <CIA-95>node: Ryan Dahl master * rcf78d04 / (13 files in 6 dirs):
23:35:31  <CIA-95>node: Upgrade libuv to 9c7ed0d
23:35:31  <CIA-95>node: Fixes test-net-pipe-connect-errors.js on UNIX.
23:35:31  <CIA-95>node: See #2001. - http://git.io/kGpKcQ
23:36:31  <ryah>^-- whew.
23:36:43  * wankdanker_joined
23:50:06  * AvianFlu_joined
23:51:22  * AvianFluquit (Disconnected by services)
23:51:53  * AvianFlu_changed nick to AvianFlu
23:57:13  * AvianFluquit (Ping timeout: 255 seconds)