00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:00:13  <saghul>when you set on to 1 in simultaneous accepts it uses a single accept
00:00:37  <bnoordhuis>it does. it's silly
00:01:07  <saghul>can it be fixed or are there historical reasons not to do so? ;-)
00:01:31  <bnoordhuis>i don't think there are. node doesn't even use it on unix
00:02:32  <saghul>ok, I'll work on a PR to clarify it a bit and make it behave as the name suggests then :-)
00:03:14  <bnoordhuis>it's just swapping the if/else clauses around right?
00:03:56  <saghul>yes, and the comment
00:04:31  <MI6>libuv-master: #48 UNSTABLE linux (2/183) osx (2/183) smartos (5/183) windows (4/184) http://jenkins.nodejs.org/job/libuv-master/48/
00:05:34  <saghul>I'm off for today, so i'll submit it somewhere tomorrow, if you haven't done it by then ;-)
00:07:13  <MI6>joyent/libuv: bnoordhuis created branch saghul-review-this - http://git.io/H1P-LQ
00:07:18  <bnoordhuis>^ saghul
00:07:51  <bnoordhuis>but yes, i'm signing off too
00:08:34  <saghul>bnoordhuis looks fine :-)
00:08:59  * kazuponjoined
00:12:42  * bnoordhuisquit (Ping timeout: 264 seconds)
00:13:02  * mikeal1quit (Quit: Leaving.)
00:26:38  <othiym23>anyone know what's supposed to happen when a domain error handler throws under 0.10?
00:27:12  <othiym23>I have an error interceptor that wraps calls up in a domain, but then tries to preserve the code's behavior by rethrowing the exception
00:27:51  <othiym23>there doesn't appear to be any way to trap that exception, because uncaughtException handlers don't fire if an exception has already been handled by a domain
00:28:27  * sblomquit
00:28:32  <othiym23>I spose I could call process.emit('uncaughtException', error) directly, but that feels hacky
00:28:50  <othiym23>(which is not to say that the whole thing isn't hacky)
00:30:02  * kazuponquit (Remote host closed the connection)
00:41:27  * dominictarrquit (Quit: dominictarr)
00:46:11  * kazuponjoined
00:52:07  * kazuponquit (Remote host closed the connection)
00:57:52  * dapquit (Quit: Leaving.)
01:18:32  * bnoordhuisjoined
01:23:10  * bnoordhuisquit (Ping timeout: 252 seconds)
01:40:20  * perezdjoined
01:43:27  * abraxasjoined
01:44:53  * abraxasquit (Remote host closed the connection)
01:56:52  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:00:37  * abraxasjoined
02:01:23  * abraxasquit (Remote host closed the connection)
02:07:11  * wavdedjoined
02:12:24  * dominictarrjoined
02:20:56  * kazuponjoined
02:21:15  * AvianFlujoined
02:21:39  * kazuponquit (Remote host closed the connection)
02:22:00  * kazuponjoined
02:51:27  * bradleymeckjoined
02:51:47  * brsonquit (Ping timeout: 255 seconds)
03:07:53  * dominictarrquit (Quit: dominictarr)
03:10:25  * Chip_Zeroquit (Ping timeout: 248 seconds)
03:11:13  * Chip_Zerojoined
03:11:57  * wavdedquit (Quit: Textual IRC Client: www.textualapp.com)
03:33:33  * brsonjoined
03:37:23  * c4miloquit (Remote host closed the connection)
03:41:20  * jguerreroquit (Quit: jguerrero)
03:46:35  * trevnorrisjoined
04:01:59  * abraxasjoined
04:02:39  * benoitcquit (Excess Flood)
04:05:39  * benoitcjoined
04:06:20  * abraxasquit (Ping timeout: 260 seconds)
04:06:40  * abraxasjoined
04:14:50  * creationixjoined
04:35:31  * jguerrerojoined
04:48:01  * dominictarrjoined
04:48:41  * mikealjoined
04:52:54  * mikealquit (Ping timeout: 245 seconds)
04:53:35  * bradleymeckquit (Quit: bradleymeck)
04:53:39  * dominictarrquit (Ping timeout: 260 seconds)
04:53:43  * dominictarr_joined
04:54:48  * mikealjoined
04:55:05  * ryahjoined
05:03:40  * kazuponquit (Read error: Connection reset by peer)
05:03:53  * Chip_Zeroquit (Ping timeout: 245 seconds)
05:04:01  * kazuponjoined
05:46:16  * perezdquit (Quit: perezd)
05:54:32  * benoitcquit (Excess Flood)
05:55:53  * TooTallNatejoined
05:57:13  * TooTallNatequit (Client Quit)
06:01:11  <wolfeidau>Gday has anyone tried using dtrace with node 0.10 having trouble getting it to resolve function names for some reason
06:02:04  <tjfontaine>some function names, or all?
06:03:40  * benoitcjoined
06:04:12  * defunctzombiechanged nick to defunctzombie_zz
06:06:51  <trevnorris>anyone have a sec to review a msg I want to post on a v8 bug? https://gist.github.com/trevnorris/5140676
06:07:28  <trevnorris>i'm trying to demonstrate that Persistent handles and MakeWeak are too expensive for a much simpler use case.
06:07:53  <trevnorris>though I want to make sure my example is sound.
06:13:00  * perezdjoined
06:13:26  * wolfeidauquit (Remote host closed the connection)
06:20:39  * perezdquit (Quit: perezd)
06:29:59  * csaohjoined
06:31:55  * wolfeidaujoined
06:33:46  <wolfeidau>tjfontaine: Sorry all, just getting addresses in the stack traces
06:33:49  * AvianFluquit (Read error: Connection reset by peer)
06:34:18  * AvianFlujoined
06:34:21  <wolfeidau>tjfontaine: GOing to go through the build process and log everything to make sure dtrace got enabled
06:34:34  * csaohquit (Client Quit)
06:45:35  * mmalecki[zzz]changed nick to mmalecki
06:48:12  * defunctzombie_zzchanged nick to defunctzombie
06:50:54  * trevnorrisquit (Quit: Leaving)
06:53:52  <tjfontaine>wolfeidau: what's your invocation mechanism?
06:54:04  <tjfontaine>that is to say
06:54:34  <tjfontaine>are you using something like `dtrace -c` or attaching to something running? and does the process exit before dtrace finishes?
06:55:03  <wolfeidau>tjfontaine: So dtrace probes are configured but jstack isn't giving me names with 0.10 for some reason
06:55:32  <wolfeidau>So running pfexec dtrace –n -l | grep node while a node process is running gives me the correct probes
06:55:46  * defunctzombiechanged nick to defunctzombie_zz
06:56:19  <wolfeidau>There is a note in the old nodejs blog post that it only works with 32 bit nodejs
06:56:59  <wolfeidau>tjfontaine: Going to do a well over due RTFM on jstack before I say anymore
06:57:37  <tjfontaine>that is true, but one of the new things for 0.10 should have been a 64bit dtrace
06:58:11  <tjfontaine>I have recently seen an issue where if I let the process finish before dtrace finished then I would lose translation
06:58:23  <tjfontaine>but that is almost always solved by using `dtrace -c`
06:59:40  <wolfeidau>tjfontaine: Ah will try that as well
06:59:56  <wolfeidau>tjfontaine: Do you normally use a Debug version of node?
07:00:34  <tjfontaine>not usually in the smartos land, it's not as necessary
07:01:00  * Chip_Zerojoined
07:01:38  <wolfeidau>Ah ok thanks for the tips
07:02:19  <tjfontaine>I will be definitely looking into this tomorrow though, so either leave me a note here with what you find, or file an issue
07:03:23  <wolfeidau>tjfontaine: np
07:13:22  * kazuponquit (Read error: Connection reset by peer)
07:13:47  * kazuponjoined
07:36:10  * zotjoined
07:37:39  * brsonquit (Quit: leaving)
07:51:23  * rendarjoined
07:51:40  * `3rdEdenjoined
07:54:43  * indexzerojoined
07:55:22  * `3rdEdenchanged nick to `3E
07:55:52  * `3rdEdenjoined
07:57:19  * philipsquit (Read error: Operation timed out)
07:57:45  * jguerreroquit (Quit: jguerrero)
08:01:00  <wolfeidau>tjfontaine: You were exactly right, running a process via -c captured both native and js function names, doing so via an execname predicate in another terminal dropped ommitted it all https://gist.github.com/wolfeidau/5141024 to see my method
08:06:38  * kazuponquit (Read error: Connection reset by peer)
08:06:51  * kazuponjoined
08:16:17  * philipsjoined
08:30:57  * kevireillyquit (Read error: Connection reset by peer)
08:36:57  * csaohjoined
09:47:32  <zot>so, if working with uv_read_start(…, callback), within the callback, when I get res == −1, I have to call uv_last_error(loop), correct? if so, that means I need to carry my loop pointer all the way through multiple callback layers (via tcp socket connect, then via read_start). is there a simpler way to look for EOF?
09:47:53  <indutny>you can get loop
09:47:54  <indutny>from handle
09:47:56  <indutny>handle->loop
09:48:11  <zot>thanks :)
09:55:31  * Chip_Zeroquit (Changing host)
09:55:31  * Chip_Zerojoined
09:57:13  * kazuponquit (Remote host closed the connection)
10:09:57  * `3rdEdenquit (Remote host closed the connection)
10:23:34  * indexzeroquit (Quit: indexzero)
10:30:48  * stagasquit (Read error: Connection reset by peer)
10:42:29  * indexzerojoined
10:44:48  * abraxasquit (Remote host closed the connection)
10:45:51  * stagasjoined
10:45:54  * abraxasjoined
10:59:54  * hzjoined
11:11:45  * abraxasquit (Remote host closed the connection)
11:14:52  * indexzeroquit (Quit: indexzero)
11:18:46  * dominictarr_quit (Quit: dominictarr_)
11:19:28  * Kakerajoined
11:23:49  * bnoordhuisjoined
11:34:48  * piscisaureusjoined
11:34:58  * piscisaureuschanged nick to piscisaureus_
11:37:20  <indutny>bnoordhuis: hey man
11:37:23  * jez0990_joined
11:37:30  <indutny>https://github.com/joyent/node/pull/4986
11:37:47  <bnoordhuis>yes, i've seen it
11:38:18  <bnoordhuis>or rather, observed its existence
11:38:32  <indutny>time to observe it in upstream ;)
11:39:04  <bnoordhuis>in due time. i still have something like 50 emails to work through
11:43:49  * jez0990quit (*.net *.split)
11:44:26  <MI6>joyent/libuv: Ben Noordhuis master * 905d56c : unix: fix uv_tcp_simultaneous_accepts() logic Inverts the meaning of the - http://git.io/ggjLaA
11:54:42  * dominictarrjoined
11:55:18  * piscisaureus_quit (Ping timeout: 264 seconds)
11:57:30  * stagasquit (Ping timeout: 272 seconds)
11:58:58  <saghul>when is the libuv v0.10 branch scheduled to come out?
12:00:41  <saghul>also, this looked pretty cool: https://github.com/piscisaureus/libuv/compare/master...release is it still the intention to have it?
12:04:30  <rendar>bnoordhuis: interesting, what uv_tcp_simultaneous_accepts enables/disables on unix?
12:06:18  * sgallaghjoined
12:06:25  * stagasjoined
12:07:18  * csaohquit (Quit: csaoh)
12:09:21  <indutny>simultaneous accepts? :)
12:09:31  <rendar>yes
12:09:32  <indutny>haha
12:09:59  * dominictarrquit (Ping timeout: 245 seconds)
12:10:10  <indutny>its enabling small delay after accept() call
12:10:19  <indutny>sometimes it improves tcp connections balancing between forks
12:10:56  <rendar>like while(1) { fd = accept(); ... nanosleep(300); ... }
12:11:09  <rendar>or something
12:13:29  <indutny>yes
12:13:31  <indutny>usleep(1)
12:13:37  <indutny>ah
12:13:37  <indutny> struct timespec timeout = { 0, 1 };
12:13:37  <indutny> nanosleep(&timeout, NULL);
12:13:39  <indutny>this
12:13:59  <rendar>oh, sleep for 1 nanosecond? cool :)
12:14:45  * csaohjoined
12:18:23  <MI6>libuv-master: #49 UNSTABLE linux (2/183) osx (2/183) smartos (4/183) windows (4/184) http://jenkins.nodejs.org/job/libuv-master/49/
12:19:09  * dominictarrjoined
12:22:00  <bnoordhuis>rendar: yes, but see the commit log of https://github.com/joyent/libuv/commit/dc559a5 - it can cause pretty steep performance drops
12:22:19  <bnoordhuis>hence single accept is disabled by default
12:22:35  * piscisaureus_joined
12:23:55  * dominictarrquit (Client Quit)
12:30:19  <zot>i'm debugging a polite close function, meaning that i expect all libuv watchers to be cleared, but it's not happening. any tricks for debugging which ones remain? (i can printf addrs, etc., and track that way, but thought people here might have experience and clever ideas…)
12:31:24  <saghul>zot you can use uv_walk
12:31:41  <zot>can i get type information out of that by chance?
12:31:57  <saghul>zot sure, you get handle structs, so handle->type
12:31:57  <zot>(i haven't used the generic uv_handle_t stuff yet)
12:33:08  <zot>nice
12:33:10  <zot>nice nice nice
12:33:12  <zot>thanks!
12:41:07  <zot>it's been a while since i've read real C macros, so forgive me if i'm blind. is there a way to get a string version of the type name? i see the enum expansion, but no strings.
12:48:23  * bnoordhuisquit (Ping timeout: 252 seconds)
12:57:58  * asdf12quit (Remote host closed the connection)
13:03:18  * stagas_joined
13:04:52  * bnoordhuisjoined
13:05:58  * stagasquit (Ping timeout: 245 seconds)
13:08:40  <bnoordhuis>zot: secret trick, in gdb do `call uv_print_all_handles(0)`
13:09:01  <bnoordhuis>likewise, `call uv_print_active_handles(0)` to print only the active ones
13:09:20  <bnoordhuis>replace 0 with the address of the loop var if it's not the default loop
13:09:21  <zot>bnoordhuis++
13:09:31  <zot>dank je wel!
13:25:56  * qmx|awaychanged nick to qmx
13:31:53  * zot1joined
13:34:35  * zotquit (Ping timeout: 252 seconds)
13:46:46  * `3Equit (Remote host closed the connection)
13:47:41  <zot1>'nuther question. i have a socketpair, being managed across 2 threads, with uv_poll_t watchers. i had hoped that doing a normal close() on one (or both) side, or shutdown() on one, would trigger a normal close that could be handled by the poll read watcher. but it doesn't appear to be the case. suggestions on where i've gone wrong? code can be found here: https://github.com/benfleis/samples/blob/master/libuv/libfriendly/http_io.cc#L317
13:48:11  <zot1>(i've tried a couple combinations of close/shutdown so far… perhaps missed the right one, or more probably misunderstand the semantics of these closures / events)
13:50:50  <bnoordhuis>zot1: what os?
13:51:22  <zot1>darwin
13:51:27  * zot1changed nick to zot
13:51:46  <zot>ultimate will need to run on linux as well
13:51:53  <zot>ultimately, even
13:52:11  <bnoordhuis>check with `dtruss -t kevent` if the event loop wakes up when one end of the socketpair is closed
13:52:27  <bnoordhuis>on linux, you can do `strace -f -e epoll_wait`
13:53:30  <bnoordhuis>not that it helps you now but strace's output is much more readable
13:54:29  <zot>well, i can switch boxes if need be, but then i have to vpn
13:54:46  <zot>is my expectation reasonable? or unknown...
13:55:25  <zot>nope, doesn't look like it hits kqueue
13:55:47  <zot>well, as a shutdown call, anywaiz
13:56:20  <bnoordhuis>zot: shutdown won't do it but close should
13:56:55  <bnoordhuis>or rather, shutdown won't necessarily do it
13:57:21  <zot>even on a socketpair?
13:58:05  <zot>i spose what i mean is that it makes sense on a normal tcp socket, if i understand what shutdown() is really doing
13:59:58  <bnoordhuis>which is? (checking we're talking about the same thing)
14:01:46  * stagas_changed nick to stagas
14:02:12  <zot>ah, i think i misunderstood. shutdown just appears to control the OS socket layer and block there. has nothing to do w/ the other endpoint.
14:02:59  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204])
14:04:30  <bnoordhuis>zot: well, SHUT_RD or SHUT_RDWR wakes up the other end - at least, it does on linux but i'm not sure how portable that is
14:05:02  * AvianFluquit (Remote host closed the connection)
14:06:43  <bnoordhuis>close definitely wakes up the other end though
14:08:13  <zot>yeah, that's what i expected
14:08:19  <zot>and yet, the other end isn't seeing it :/
14:08:51  <zot>a normal uv_poll_t / uv_poll_start should catch closed socket in this case, right?
14:10:22  <bnoordhuis>zot: yes. it calls your poll cb with status=-1
14:10:33  <zot>yep, i think i just found it
14:10:46  <zot>was doing the <0, ==0 check a la read instead of the libuv −1 check
14:35:00  * nsmjoined
14:35:17  * bradleymeckjoined
14:57:00  <zot>next! under what conditions might i expect uv_shutdown(…, cb) to never call into cb()?
14:57:04  <zot>(tcp socket)
14:59:50  <bnoordhuis>zot: when you call exit(0) right after. else it should always fire
15:00:17  <zot>then i'm doing something horribly wrong :/
15:00:29  <zot>it's called. then i sit waiting on pthread_join (or in a sleep loop, either way)
15:01:00  <zot>callback seems not to fire.
15:01:34  <bnoordhuis>zot: example code?
15:01:46  * stagasjoined
15:02:09  <zot>een momentje...
15:02:24  <zot>whoah. curious. it just fired, like 15s later.
15:02:47  <zot>why would it be so slow? this is a localhost tcp connect...
15:04:21  <zot>although only in 1 session (gdb). in the other it's just sitting. so strange. i'll commit and push the code again.
15:05:30  <zot>bnoordhuis: https://github.com/benfleis/samples/blob/master/libuv/libfriendly/http_io.cc#L323
15:06:18  <bnoordhuis>zot: re why so slow, it fires on the next loop tick
15:07:11  <bnoordhuis>so i assume you're doing something that causes the next tick to delay
15:07:15  <zot>the loop is idle in another thread. (yes, it's not thread safe atm.)
15:07:39  <bnoordhuis>oh? you're calling uv_connect from another thread?
15:07:58  <bnoordhuis>s/uv_connect/uv_shutdown/
15:08:08  <zot>yes
15:08:22  <zot>but on the loop being managed by the other thread
15:08:28  <zot>is there goo in the middle that makes this not work?
15:09:26  <bnoordhuis>well...
15:09:38  <bnoordhuis>like i said, the callback is called on the next tick
15:09:51  <zot>ah, so it needs to be awoken
15:09:54  <bnoordhuis>you're calling pthread_join among other things and that blocks until the thread exits
15:09:59  <zot>hrm.
15:10:11  <bnoordhuis>yes. btw, that's what uv_async_t is for, waking up other event loops
15:10:14  <zot>then what i really need to is to get the close() from above working, so that I can call shutdown from that thread like i wanted
15:11:02  <zot>ok, will try with that.
15:11:42  <zot>in theory though, calling close from my main thread on the socketpair should still get through to the io thread as a UV_EOF, without needing async to wake up the loop, correct?
15:17:48  <zot>ok, fixed the tcp watcher problem. now back to the socketpair :)
15:20:03  * jguerrerojoined
15:22:21  * jguerreroquit (Client Quit)
15:27:46  * AvianFlujoined
15:27:57  * jguerrerojoined
15:29:23  * mikealquit (Quit: Leaving.)
15:33:20  * _isaacs_afkchanged nick to isaacs
15:34:37  * AvianFluquit (Read error: Connection reset by peer)
15:34:45  * AvianFlu_joined
15:35:22  <isaacs>call in 0:22 or so
15:35:36  <isaacs>tjfontaine, bnoordhuis, piscisaureus_, sblom, indutny ^
15:35:41  <bnoordhuis>yep
15:35:46  <piscisaureus_>isaacs: noted
15:35:49  <bnoordhuis>zot: close() should wake up the other end, yes
15:35:58  <bnoordhuis>(and does - libuv relies on that internally)
15:36:07  <isaacs>uh oh. skype wants to upgrade.
15:37:18  <zot>perhaps this is better solved tomorrow with a fresh brain. this is going to make me nuts.
15:37:30  <zot>bnoordhuis: you happen to know which internal code relies on that, so i can compare my code to it?
15:37:37  <zot>(i didn't find any socketpairs in the test code)
15:37:48  <bnoordhuis>zot: uv_spawn() for example. though that uses a pipe instead of a socketpair
15:37:51  <bnoordhuis>concept is the same though
15:38:39  * AvianFlu_changed nick to AvianFlu
15:39:54  <bnoordhuis>i don't get annoyed easily but this "EVP_PKEY_get1_RSA:expecting an rsa key" v0.8 error is really starting to piss me off >:(
15:40:33  <bnoordhuis>that error stack clearing patch doesn't fix it, upgrading openssl doesn't fix it but linking to the system openssl does
15:40:36  <bnoordhuis>grr
15:41:01  * mikealjoined
15:42:18  <zot>bnoordhuis: thanks, i'll have a look
15:42:27  * zotquit (Quit: so long and thanks for all the code)
15:52:13  * mmalecki_joined
15:53:46  * CoverSli1ejoined
15:53:51  * defunctzombie_zzquit (Ping timeout: 264 seconds)
15:53:51  * CoverSlidequit (Ping timeout: 264 seconds)
15:54:02  * mmaleckiquit (Read error: Connection reset by peer)
15:54:29  * mmalecki_quit (Client Quit)
15:54:39  * mmaleckijoined
15:55:00  * sgallaghquit (Remote host closed the connection)
15:55:55  * sgallaghjoined
15:57:04  * defunctzombiejoined
15:57:49  <bnoordhuis>piscisaureus_: https://github.com/saghul/pyuv/issues/92#issuecomment-14783510
15:58:03  <piscisaureus_>bnoordhuis: I saw the traffic but I'm too busy
16:01:02  <tjfontaine>er
16:05:07  <ryah>ryan@yyy-3:~% otool -L `which python`
16:05:07  <ryah>/usr/bin/python: /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 741.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
16:05:11  <ryah>ryan@yyy-3:~% otool -L `which node`
16:05:14  <ryah>/usr/local/bin/node:
16:05:16  <ryah> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
16:05:19  <ryah> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.25.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, cu
16:05:24  <ryah>rrent version 53.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 41.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1094.0.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/
16:05:27  * brsonjoined
16:05:31  <ryah> 150.0.0, current version 635.21.0)
16:05:34  <ryah>ryan@yyy-3:~%
16:05:36  <ryah>^-- kind of sad
16:05:56  <ryah>ryan@yyy-3:~% otool -L `which python` | wc -l
16:05:56  <ryah> 3
16:05:56  <ryah>ryan@yyy-3:~% otool -L `which node` | wc -l
16:05:56  <ryah> 10
16:05:57  <ryah>ryan@yyy-3:~%
16:06:01  <ryah>more readable
16:06:04  <brucem>also using Carbon isn't so hot.
16:07:29  <ryah>seems like node shouldn't use /usr/lib/libobjc.A.dylib
16:07:36  <bnoordhuis>hey, you want a working process.title or not?
16:07:46  <ryah>yeah i was just going to say it's probably for process.title :)
16:07:52  <ryah>can't we just figure out what syscall that is?
16:07:57  <ryah>and bypass that shit
16:08:00  <ryah>"just"
16:08:04  <bnoordhuis>i don't think it's a syscall
16:08:04  <ryah>:P
16:08:19  <ryah>it's got to be somehow talking to the kernel
16:08:43  <bnoordhuis>it might be some mach ipc thing
16:08:46  <bnoordhuis>patches welcome :)
16:09:01  * ryahforgot how to program
16:10:24  <ryah>my chrome has a higher version of V8 than Node 10
16:10:47  <ryah>V8 3.15.11.16 <-- chrome 25
16:11:05  <ryah>V8 3.14.5.8 <-- node 10
16:11:35  <bnoordhuis>we downgraded because of performance issues
16:11:55  <bnoordhuis>in particular, v8::String::Utf8Length() has become impossibly slow
16:12:09  <ryah>hm
16:12:26  * c4milojoined
16:12:36  <ryah>and that doesn't effect chrome? :/
16:12:51  <bnoordhuis>ryah: https://code.google.com/p/v8/issues/detail?id=2551
16:12:55  <bnoordhuis>and no, apparently not
16:13:23  <ryah>word
16:15:12  <bnoordhuis>oh, i lie by omission
16:15:12  * defunctzombiequit (Changing host)
16:15:13  * defunctzombiejoined
16:15:39  <bnoordhuis>the v8::String::Utf8Length() regression was in 3.16, 3.15 has gc issues
16:16:09  <bnoordhuis>the memory footprint with 3.15 is generally 2x compared to 3.14
16:17:00  * AvianFluquit (Remote host closed the connection)
16:19:15  <tjfontaine>bnoordhuis: I did do a pass at that uv_stat_t last night, only one failing test because I used the wrong type for a field, but I am skeptical I actually did it right :)
16:19:25  <tjfontaine>but I'll do a pull request and you can laugh
16:21:48  <bnoordhuis>okay, nice
16:21:58  <bnoordhuis>isn't it said that laughter is the best medicine?
16:22:29  * dapjoined
16:23:05  <tjfontaine>the human condition is a hilarious thing
16:25:04  * AvianFlujoined
16:30:39  * mikealquit (Quit: Leaving.)
16:41:35  * perezdjoined
16:45:47  * perezdquit (Ping timeout: 246 seconds)
16:46:39  * perezdjoined
16:48:31  * stephankquit (Quit: *Poof!*)
16:52:45  <indutny>back
16:53:02  * bradleymeckquit (Quit: bradleymeck)
16:53:04  <indutny>could you please let me know about results of standup?
16:53:10  <indutny>isaacs: piscisaureus_: bnoordhuis: ^
16:53:22  <isaacs>indutny: we didn't say too much, actually.
16:53:32  <isaacs>indutny: "w00t, 0.10" and "There are some bugs, we shoudl fix those"
16:53:49  <isaacs>indutny: i'd like to get 0.11 started pretty soon, maybe the first unstable in a few weeks.
16:53:54  <isaacs>or even the end of next week.
16:55:00  <creationix>isaacs: any chance of just removing http from core (making it user-space)
16:55:07  <creationix>or is that complete crazy
16:55:18  <isaacs>creationix: it's completely crazy while it's called "node"
16:55:23  <isaacs>creationix: "no" will do this.
16:55:50  <creationix>heh, as if "node" was already hard enough to google :P
16:57:19  <creationix>s/was/wasn't/
16:59:12  <isaacs>creationix: in all honesty, we'll probably come up wiht a better name by then.
16:59:15  <isaacs>that's like 5 years out, though
16:59:29  <creationix>so there is a serious project to make a minimal version of node then?
16:59:41  <isaacs>s/project/idea in isaac's head/
16:59:41  <isaacs>yes
16:59:45  <isaacs>there's no code yet.
16:59:53  <isaacs>except the code i'm going to steal from node :)
17:00:08  <creationix>cool, let me know when you start working on it
17:00:18  <creationix>I have similar goals
17:00:31  <isaacs>i'm gonna wait for fast good support for ES6 modules before even starting.
17:00:43  <isaacs>and continuables or some other kind of language-level flow-control
17:00:51  <creationix>yeah, that would change things
17:01:00  <isaacs>opens new doors, at least.
17:01:04  <isaacs>not sure if tehre are good things behind them
17:01:11  <isaacs>but we can at least entertain the options
17:01:16  * mikealjoined
17:01:23  * qmxchanged nick to qmx|away
17:01:24  <creationix>my experience with coroutines in lua is, yes they allow faux blocking, but are complex to reason about
17:01:25  <isaacs>the module stuff is actually crucial to what i want to build. node can never adopt ES modules in a serious way.
17:01:28  <isaacs>too disruptive
17:01:30  * bnoordhuisquit (Ping timeout: 272 seconds)
17:01:34  <isaacs>yeah, coro's kinda suck
17:01:36  <isaacs>they're cute.
17:01:39  <isaacs>but annoying at scale.
17:01:46  <isaacs>like teletubbies
17:01:53  <tjfontaine>...
17:02:45  * brsonquit (Ping timeout: 248 seconds)
17:03:31  * brsonjoined
17:04:21  <wolfeidau>tjfontaine: Dug into that issue with dtrace more, with the help of a blog post by indutny managed to get my flamegraphs working using -o and -c flags
17:04:58  <indutny>isaacs: you want to experiment with moving core modules out of the core?
17:05:17  <tjfontaine>wolfeidau: ya, for me when I was hitting this issue before it was happening when I attached dtrace to a running node process, and then that process exited before dtrace finished
17:06:12  <wolfeidau>tjfontaine: I observed something interesting in that area, if the node process exited while the jstack dtrace was running i got one frame with names
17:06:30  <tjfontaine>but only one?
17:06:42  <wolfeidau>tjfontaine: That is with dtrace running in another terminal
17:06:48  <wolfeidau>yeah was wierd
17:07:22  <tjfontaine>when dap has time I'm going to discuss this with him, and see what I can learn to try and figure out what's going on
17:08:23  <wolfeidau>tjfontaine: Having read over presentations about ustack vs jstack i now understand how these differ and what the hell jstack does which is a bonus
17:09:01  <tjfontaine>wolfeidau: ya, jstack is a glorious piece of work
17:09:11  <wolfeidau>tjfontaine: What i find interesting is how the communication between dtrace and this jstack helper could break down
17:09:39  <tjfontaine>ya which is why it's in an area where I have to talk to the people who wrote it :P
17:09:43  <wolfeidau>tjfontaine: Yeah v8ustack.d is a amazing piece of work
17:10:17  * nsmquit (Quit: nsm)
17:10:32  * mikealquit (Ping timeout: 240 seconds)
17:11:11  <wolfeidau>tjfontaine: As it works when dtrace is invoked via -c it has to be something external which is influencing it
17:12:05  <tjfontaine>wolfeidau: it appears as a race condition anyway, it's supposed to be caching the symbol resolutions, so seeing even one frame that works would mean that it's always working
17:13:22  <wolfeidau>tjfontaine: Does this caching occur in node or within the dtrace module?
17:13:53  * piscisaureus_quit (Ping timeout: 245 seconds)
17:14:19  <tjfontaine>wolfeidau: I don't know enough about it, hope to learn more today :)
17:14:27  <wolfeidau>tjfontaine: Cool
17:14:57  <wolfeidau>Are you going to raise a ticket, I would be very interested to follow it
17:15:14  <tjfontaine>wolfeidau: probably, when I do I will let you know
17:15:56  <wolfeidau>Currently running this to get my flamegraphs btw pfexec dtrace -o stacks.out -n 'profile-97/pid == $target && arg1/{@[jstack(100, 8000)] = count(); } tick-20s { exit(0); }' -c "node bench.js"
17:16:29  <wolfeidau>Helps that now understand some of those params
17:16:35  <tjfontaine>:)
17:20:00  <indutny>isaacs: what do you think about https://github.com/joyent/node/pull/4986/files ? :)
17:21:05  <isaacs>indutny: i think excited thoughts. but i won't be able to review this properly until at least tomorrow.
17:21:09  <isaacs>indutny: please don't land until i do.
17:21:13  <indutny>surely
17:21:17  <indutny>I want ben to review it too
17:21:26  <indutny>just thought you might have some further ideas about it
17:24:32  <isaacs>yeah, i'm looking forward to it :)
17:25:23  <creationix>ohh, new crypto
17:25:27  <creationix>super exciting
17:27:48  * bnoordhuisjoined
17:28:15  * stephankjoined
17:28:29  <tjfontaine>bnoordhuis: https://github.com/joyent/libuv/pull/739 is what I was mentioning before
17:30:40  <indutny>bnoordhuis: ben
17:30:45  <indutny>we need to talk
17:31:32  <rendar>bnoordhuis: i see, so by default single accept is 0
17:32:17  <tjfontaine>heh, if we all attack him when he joins, he'll stop joining :P
17:34:40  * benoitcquit (Excess Flood)
17:34:53  <rendar>lol
17:35:18  * benoitcjoined
17:36:09  * bnoordhuisquit (Ping timeout: 256 seconds)
17:37:41  * mikealjoined
17:39:41  * piscisaureus_joined
17:42:23  * mikealquit (Ping timeout: 256 seconds)
17:43:00  * bradleymeckjoined
17:49:14  * TooTallNatejoined
17:55:26  * piscisaureus_quit (Ping timeout: 256 seconds)
17:58:32  * zot1joined
18:02:30  * mikealjoined
18:05:38  * csaohquit (Quit: csaoh)
18:05:39  * perezdquit (Quit: perezd)
18:11:26  * dostoyevskyjoined
18:12:24  <dostoyevsky>How does one usually know if reading has finished when using uv_read_start's callbacks?
18:12:58  * mmaleckichanged nick to mmalecki[away]
18:31:27  * bnoordhuisjoined
18:32:20  * Raltjoined
18:36:38  <indutny>bnoordhuis: ben?
18:36:51  <indutny>dostoyevsky: check status argument
18:36:54  <indutny>in read callback
18:37:32  <indutny>i.e. nread should be < 0
18:37:50  <indutny>and uv_last_error() should be UV_EOF
18:37:53  <dostoyevsky>indutny: hmmm... doesn't help me
18:38:16  <dostoyevsky>The way I do it: I check what I have read so far for completeness
18:38:17  <indutny>erm...
18:38:29  <bnoordhuis>indutny: fedor?
18:38:30  <indutny>are you sure you're ending it on other side?
18:38:33  <dostoyevsky>And then I know whether I need to wait for more reads
18:38:34  <indutny>bnoordhuis: crypto?
18:38:46  <indutny>bnoordhuis: please, https://github.com/joyent/node/pull/4986/files
18:38:53  <indutny>there're multiple commits
18:38:59  <indutny>to make it simplier to review changes
18:39:08  <bnoordhuis>okay, good
18:39:10  <indutny>basically I've moved class declarations to node_crypto.h
18:39:12  <dostoyevsky>indutny: The problem is: If the server side writes a large buffer, you might get more than one call to your on_read handler
18:39:15  <indutny>and improved some code bas
18:39:17  <indutny>s/bas/base
18:39:58  <dostoyevsky>So you need to know when the reads are finished... Unless your server just closes the connection when it's done reading--then one could just check for OEF
18:40:01  <dostoyevsky>EOF
18:40:26  <dostoyevsky>s/done reading/done writing/
18:41:24  <dostoyevsky>Maybe nread == 0 might be an indicator
18:42:39  <dostoyevsky>Could a server do a write() for 0 bytes? And then I could easily know in my readhandler whether the buffer is complete?
18:42:42  * bradleymeckquit (Quit: bradleymeck)
18:45:03  <dostoyevsky>But the way I see it: There is no guarantee how the buffers will be split up after the server wrote them... there might be any kind of buffering before it goes to the client, and a write of 0 bytes will be just ignored. So one can only check what has been read and decide based on that whether one has to wait for more reads before actually using what has been read
18:45:51  <dostoyevsky>Not sure if anyone can understand what I am talking about :)
18:47:02  * zot1quit (Quit: Leaving.)
18:50:07  <tjfontaine>hmm no new test failurse for the libuv-win stat changes, clearly we just don't have enough tests in this area :)
18:55:51  * bradleymeckjoined
18:57:02  * Kakeraquit (Ping timeout: 246 seconds)
18:58:13  * brianc1part
18:59:23  <tjfontaine>bnoordhuis: any problem with me just making them all uint64, is it valid to ever have negative values in those places?
19:02:22  <bnoordhuis>tjfontaine: no and no, i.e. no problem and no, they should never be negative
19:02:45  <tjfontaine>right ok
19:02:48  * Raltquit (Remote host closed the connection)
19:03:03  <bnoordhuis>it's kind of wasteful for fields like uid and gid because they're never > 2^32 but oh well
19:03:15  <tjfontaine>right
19:04:08  <tjfontaine>I am going to add a test as well for at least the unicies to make sure I didn't fubar it all
19:04:35  <bnoordhuis>good idea
19:04:48  <tjfontaine>but it didn't break anything obvious, the fs-poll tests pass still anyway
19:15:03  <indutny>bnoordhuis: what do you think about replacing BIO_free with BIO_free_all
19:15:08  <indutny>everywhere in node_crypto.cc
19:17:01  * stagasquit (Ping timeout: 240 seconds)
19:23:04  * CoverSli1echanged nick to CoverSlide
19:24:40  <creationix>isaacs: would you be willing to speak on a javascript podcast about the node 0.10 release?
19:25:12  <CoverSlide>JSJ?
19:25:16  <creationix>yep
19:25:49  <creationix>I'm out of town this Thursday speaking about node at http://www.chscodeshow.com/
19:26:27  * perezdjoined
19:33:16  <indutny>bnoordhuis: fixed all nits and force pushed https://github.com/joyent/node/pull/4986
19:37:27  * arlolrajoined
19:37:58  <indutny>and force pushed again
19:43:42  <indutny>bnoordhuis: can you please reload page?
19:43:44  <indutny>and add comment again?
19:44:05  <indutny>lines changed and your comment is out of context... a bit
19:46:36  <bnoordhuis>oh, okay
19:49:40  * sgallaghquit (Ping timeout: 248 seconds)
20:00:59  * Raltjoined
20:01:18  * Raltquit (Remote host closed the connection)
20:02:11  <indutny>thanks
20:02:43  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:05:13  * TooTallNatejoined
20:09:23  * txdvquit (Read error: Operation timed out)
20:09:28  <indutny>bnoordhuis: is that all?
20:10:04  <indutny>btw, if we're going to replace int with size_t there
20:10:11  <indutny>we should also replace it everywhere
20:11:19  <bnoordhuis>indutny: hence 'general observation'
20:11:25  <indutny>yeah
20:11:26  * txdvjoined
20:11:29  * dominictarrjoined
20:11:29  <indutny>everything else fixed
20:11:39  <indutny>and if you've finished - I can force pushe it
20:12:53  * stagasjoined
20:18:02  <MI6>joyent/node: Nathan Rajlich master * da8b0ee : console: `console.dir()` bypasses inspect() methods Use the `customInspe - http://git.io/8OJCWw
20:18:37  <MI6>joyent/node: Nathan Rajlich master * 66280de : util: custom `inspect()` method may return an Object This is more like h - http://git.io/HSmybQ
20:19:56  * qmx|awaychanged nick to qmx
20:20:53  <bnoordhuis>indutny: okay, reviewed. mostly LGTM
20:21:00  <indutny>haha
20:21:01  <indutny>ok
20:21:04  <indutny>should I squash it?
20:21:38  <bnoordhuis>i guess so but not in one big commit
20:21:39  <indutny>(and thanks)
20:21:48  <indutny>like split, refactor, and BIO_free_all
20:21:48  <indutny>ok?
20:21:56  <bnoordhuis>the BIO_free_all commit should stay (so i can blame you with git bisect >:))
20:22:03  <indutny>haha
20:22:04  <indutny>:)
20:22:04  <indutny>ok
20:22:12  <bnoordhuis>yeah, split, refactor, BIO_free_all
20:23:02  <bnoordhuis>there are still some style violations in there
20:23:06  <bnoordhuis>but they're not new ones
20:23:39  <MI6>joyent/node: Fedor Indutny master * 68487a7 : crypto: replace BIO_free with BIO_free_all From OpenSSL's documentation: (+3 more commits) - http://git.io/8L20aA
20:23:42  <indutny>done
20:23:51  <indutny>bnoordhuis: yeah, I'll return to them later
20:23:59  <indutny>one by one
20:24:47  <indutny>finally, I've removed some garbage out of it
20:24:48  <indutny>whoa
20:24:58  <indutny>now I can look at it without tears
20:25:30  <indutny>bnoordhuis: what do you think about using google C++ linter?
20:34:21  * Raltjoined
20:35:13  * Raltquit (Remote host closed the connection)
20:38:55  <bnoordhuis>indutny: we already have a `make lint` target, if that's what you're asking
20:39:11  * Kakerajoined
20:40:27  * perezdquit (Quit: perezd)
20:40:32  * bradleymeckquit (Quit: bradleymeck)
20:45:56  <indutny>ah
20:46:00  <indutny>and
20:46:04  <indutny>we're like ignoring it?
20:47:12  <bnoordhuis>yes
20:47:20  <bnoordhuis>i don't agree with a lot of the things it complains about
20:47:33  <bnoordhuis>try it for yourself, you'll see
20:48:58  <indutny>I've tried :)
20:49:03  <indutny>looks mostly good
20:49:16  <indutny>I mean, look at crypto
20:49:21  <indutny>its all anti-lint
20:49:43  <bnoordhuis>it is
20:49:44  <indutny>even with some things that you're not agree with
20:49:49  <indutny>it would be much better
20:50:05  <bnoordhuis>but the thing is, i don't want to clutter up the commit history with massive lint patches
20:50:13  <indutny>yeah, I know
20:50:20  <bnoordhuis>i use `git blame` a lot, lint patches completely destroy that
20:50:42  <indutny>but I already scraped half of it
20:50:45  <indutny>:)
20:51:02  <indutny>why not continue and fix everything else
20:52:38  * mikealquit (Quit: Leaving.)
20:52:52  * mmalecki[away]changed nick to mmalecki
20:55:24  * brianc1joined
20:58:14  * c4miloquit (Remote host closed the connection)
20:59:38  * benoitcquit (Read error: Connection reset by peer)
21:04:58  * c4milojoined
21:07:42  * c4miloquit (Remote host closed the connection)
21:09:49  <isaacs>creationix: sure, that sounds fun. when?
21:10:08  <creationix>isaacs: thursday
21:10:16  <isaacs>creationix: what time?
21:10:24  <creationix>let me find out
21:10:40  * mikealjoined
21:12:31  <creationix>isaacs, it's usually starts around 10am your time
21:12:53  <isaacs>creationix: that's perfect.
21:13:28  <isaacs>creationix: can you send me an invite so that i actually do it?
21:13:47  <creationix>google calendar invite?
21:13:51  <isaacs>ya
21:13:55  <creationix>sure thing
21:13:57  <isaacs>skype, i presume?
21:22:10  <creationix>isaacs: usually
21:24:24  <isaacs>kewl
21:24:33  * isaacsis isaac.schlueter on skype
21:24:36  <isaacs>i think i have you as a contact already
21:25:38  <creationix>isaacs: I sent you an email with details too
21:26:00  <isaacs>kewl
21:26:53  <creationix>it's a shame I won't be here this Thursday to be on the podcast
21:28:01  * perezdjoined
21:29:43  * perezd_joined
21:30:31  * perezdquit (Read error: Operation timed out)
21:30:32  * perezd_changed nick to perezd
21:34:15  * loladirojoined
21:43:26  * benoitcjoined
21:49:25  * wolfeidauquit (Remote host closed the connection)
21:50:22  * rendarquit
21:56:35  * piscisaureus_joined
22:05:53  * wolfeidaujoined
22:13:31  * c4milojoined
22:18:12  <tjfontaine>gdb on osx is so painful
22:18:21  <tjfontaine>I guess I could use lldb for this
22:18:48  * hzquit (Ping timeout: 264 seconds)
22:19:17  * qmxchanged nick to qmx|away
22:21:16  * hzjoined
22:22:36  <tjfontaine>you win lldb, you win, https://gist.github.com/tjfontaine/15d1075821c42fa62d9f
22:25:24  * AvianFluquit (Remote host closed the connection)
22:26:00  * hzquit (Ping timeout: 264 seconds)
22:28:58  * hzjoined
22:31:56  * perezdquit (Quit: perezd)
22:36:58  * TooTallNatequit (Ping timeout: 256 seconds)
22:38:16  * rvaggquit (Excess Flood)
22:38:30  * rvaggjoined
22:39:37  * TooTallNatejoined
22:43:24  * bradleymeckjoined
22:47:33  <tjfontaine>bnoordhuis: so what should these #if's look like for determining what's available?
22:51:11  * TooTallNatequit (Ping timeout: 260 seconds)
22:52:20  * TooTallNatejoined
22:52:36  * mikealquit (Quit: Leaving.)
22:53:37  <MI6>nodejs-master: #92 FAILURE osx-x64 (1/555) windows-ia32 (5/555) windows-x64 (6/555) http://jenkins.nodejs.org/job/nodejs-master/92/
22:54:31  <tjfontaine>wtf osx build slave, why do you hate my freedom
22:55:18  <ryah>is lldb cool? better than gdb?
22:55:34  * arlolraquit (Quit: Linkinus - http://linkinus.com)
22:56:43  * c4miloquit (Remote host closed the connection)
22:57:10  <tjfontaine>ryah: for osx, yes I am impressed, I haven't done much complicated though
22:57:36  * loladiroquit (Quit: loladiro)
22:59:13  <MI6>joyent/node: Nathan Rajlich master * 3288bc9 : doc: fix inpect() -> inspect() typo - http://git.io/8ok5kQ
22:59:34  <tjfontaine>stderr: fatal: pack has 13 unresolved deltas
22:59:46  <tjfontaine>git on osx how are you managing this
23:01:34  * mikealjoined
23:04:27  * perezdjoined
23:06:15  <bnoordhuis>tjfontaine: #if? you mean for the uv_stat_t thing?
23:06:32  <tjfontaine>yes, sorry I should have provided more context
23:06:44  <tjfontaine>I'm having a hard time keeping my letters in the right order while typing today
23:08:06  * loladirojoined
23:08:55  * perezdquit (Ping timeout: 260 seconds)
23:09:26  <bnoordhuis>tjfontaine: the ones in src/fs-poll.c are about as good as it gets
23:09:59  <bnoordhuis>i'm sure solaris has a similar thing but i haven't looked into that yet
23:11:37  <tjfontaine>ok, I'm not really sure it's all that important to get it right on apple anyway
23:11:53  * perezdjoined
23:11:55  <tjfontaine>because the chances that they're using a filesystem that actually reports subsecond granularity ...
23:12:40  <MI6>nodejs-master: #93 FAILURE linux-x64 (1/555) osx-x64 (1/555) windows-ia32 (5/555) windows-x64 (5/555) http://jenkins.nodejs.org/job/nodejs-master/93/
23:15:39  <piscisaureus_>Hello people
23:17:02  <tjfontaine>hello bert
23:19:03  <isaacs>hola
23:22:43  * indexzerojoined
23:38:45  * Nicholas__joined
23:42:09  <isaacs>TooTallNate: this looks rad: https://github.com/joyent/node/pull/4994
23:42:12  * Kakeraquit (Ping timeout: 264 seconds)
23:42:55  <TooTallNate>isaacs: ya dude i was just looking at it
23:43:00  <TooTallNate>with my jaw on the floor
23:43:00  <TooTallNate>hahah
23:46:24  * hzquit (Ping timeout: 264 seconds)
23:46:46  <isaacs>TooTallNate: it'd be nice to get some tests for it, of course.
23:47:20  <TooTallNate>isaacs: i'll note that
23:50:47  * hzjoined
23:52:25  * c4milojoined
23:53:29  * Nicholas__quit (Ping timeout: 246 seconds)
23:57:20  * indexzeroquit (Quit: indexzero)
23:58:23  * bnoordhuisquit (Ping timeout: 260 seconds)