00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:32  <trevnorris>isaacs: fwiw looks like part of the package was in deps/v8/src/extensions/i18n/, but that's been moved to a third_party folder which requires a checkout.
00:07:12  * TooTallNatejoined
00:07:19  <trevnorris>TooTallNate: ping!!!
00:07:23  <TooTallNate>trevnorris: pong
00:08:46  <trevnorris>TooTallNate: hey :)
00:08:46  <trevnorris>so, v8 introduced this new icu_gyp_path variable that needs to point to some third_party library. but it can be disabled at compile time. though I can't figure out how to tell it "hey i'm going to disable you at compile time so don't bitch at me during configure"
00:08:46  <trevnorris>for some reason thought you might have an idea what I could do.
00:09:16  <TooTallNate>trevnorris: this is a master branch thing?
00:09:42  <trevnorris>TooTallNate: yeah. I want to try out some new stuff on v8 3.22 and am trying to upgrade
00:10:17  <TooTallNate>trevnorris: what's the error you're seeing?
00:10:18  <trevnorris>and they remove their src/extensions folder that provided some support for i18n
00:11:06  <trevnorris>gyp: Undefined variable icu_gyp_path in .../deps/v8/tools/gyp/v8.gyp while loading dependencies of .../node.gyp while trying to load .../node.gyp
00:12:19  <trevnorris>that variable is in build/standalone.gyi
00:16:20  <TooTallNate>trevnorris: well try adding that "icu_gyp_path" to the variables dir in node.gyp
00:19:00  <trevnorris>TooTallNate: cool, i'll try that. i'm also trying to figure out how to disable it by default. think I found the commit that'll show me how. hopefully it'll stop checking that one.
00:22:34  <trevnorris>TooTallNate: tried it. same complaint.
00:29:18  <trevnorris>TooTallNate: ah, ok. so v8_enable_i18n_support must be 0 and then it shouldn't try to read in that file. but guess I'm not passing it in correctly.
00:29:22  * c4milojoined
00:29:33  <TooTallNate>trevnorris: perhaps try the common.gypi file
00:30:10  <tjfontaine>trevnorris: yes, they're at 3.22 but it's the unstable, I think I don't think they've started 3.23 yet
00:30:44  <trevnorris>tjfontaine: wait. so their even numbered branches are unstable?
00:31:40  <tjfontaine>trevnorris: they don't do numbering like that, it's just what's tracked intheir current chromium usage
00:31:56  <trevnorris>tjfontaine: ah, ok. thanks.
00:32:01  <othiym23>trevnorris: icu is a l10n library, and yes, it's huge
00:34:14  <trevnorris>thanks all. that was a fun investigation.
00:34:20  <othiym23>isaacs: I hope you're further along with your RTConf than I am
00:34:46  <othiym23>isaacs: I have a thesis and a big pile of information that's super interesting to me, but am still working on cramming it in to the correct shape
00:36:59  * c4miloquit (Remote host closed the connection)
00:37:25  * c4milojoined
00:41:01  * c4milo_joined
00:41:02  <isaacs>othiym23: yep. right there with ya
00:42:19  * c4miloquit (Ping timeout: 272 seconds)
00:44:03  * c4milo_quit (Remote host closed the connection)
00:44:31  * c4milojoined
00:45:25  * inolenjoined
00:49:26  * c4miloquit (Ping timeout: 264 seconds)
00:57:00  * wwicksquit (Read error: Connection reset by peer)
00:57:15  * wwicksjoined
01:04:49  * EhevuTovquit (Quit: This computer has gone to sleep)
01:09:33  * julianduquequit (Quit: leaving)
01:28:36  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:31:30  * abraxasjoined
01:34:05  * julianduquejoined
01:38:37  * hueniversequit (Quit: Leaving.)
01:40:12  * TooTallNatejoined
01:43:27  * brsonquit (Ping timeout: 260 seconds)
01:44:06  * st_lukejoined
01:55:09  * dapquit (Quit: Leaving.)
02:19:47  * kazuponjoined
02:21:32  * kazuponquit (Remote host closed the connection)
02:22:36  * kazuponjoined
02:24:18  * kazuponquit (Remote host closed the connection)
02:24:53  * kazuponjoined
02:44:59  * mikealjoined
02:49:46  * defunctzombie_zzchanged nick to defunctzombie
03:00:11  * c4milojoined
03:04:37  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:31:35  * st_lukequit (Remote host closed the connection)
03:32:11  * st_lukejoined
03:36:41  * st_lukequit (Ping timeout: 265 seconds)
03:59:48  * st_lukejoined
04:32:34  * c4miloquit (Read error: Connection reset by peer)
04:33:38  * c4milojoined
04:45:35  * st_lukequit (Remote host closed the connection)
04:57:34  * indexzerojoined
04:57:35  * indexzeroquit (Client Quit)
05:14:34  <indutny>heya
05:19:11  * c4miloquit (Remote host closed the connection)
05:20:12  * julianduquequit (Quit: leaving)
05:36:34  * st_lukejoined
06:08:51  * bajtosjoined
06:23:49  * st_lukequit (Remote host closed the connection)
06:28:00  * defunctzombiechanged nick to defunctzombie_zz
06:30:41  * `3E|SLIDEDECKDUTchanged nick to `3E
06:36:09  * rendarjoined
06:41:19  <MI6>nodejs-v0.10-windows: #260 UNSTABLE windows-ia32 (11/601) windows-x64 (10/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/260/
06:56:39  * bnoordhuisjoined
07:05:25  <rendar>bnoordhuis: good morning :)
07:06:37  <indutny>bnoordhuis: hey
07:08:17  * kenperkinsquit (Ping timeout: 272 seconds)
07:19:08  <bnoordhuis>rendar, indutny: morning
07:19:25  <indutny>how are you?
07:19:30  <bnoordhuis>sleepy
07:19:45  <bnoordhuis>i have this grocery delivery service now
07:19:56  <bnoordhuis>but no one told me they'd be ringing my doorbell at 08.30 am
07:20:21  <indutny>hahaha
07:20:22  <bnoordhuis>these are not times decent people speak of, let alone are awake at
07:20:31  <indutny>we've delivery service in moscow too
07:20:37  <indutny>it has free deliveries from 1am to 5 am
07:20:48  <indutny>never tried it, though
07:21:01  <bnoordhuis>seriously? only free at night?
07:21:13  <indutny>yeah
07:21:35  <indutny>so what about that GH-sec issue?
07:21:44  <bnoordhuis>oh, the pipelining thing
07:21:59  <bnoordhuis>i think tj and isaac are somewhat opposed to disabling pipelining altogether
07:22:17  <bnoordhuis>so rate limiting is probably the next best thing
07:23:14  <bnoordhuis>now that i'm up so early, i might as well write the patch
07:23:34  <indutny>haha
07:29:16  <indutny>so
07:31:29  <indutny>that OSX 10.9 crash is really wierd
07:31:49  <indutny>I still have no access to it
07:32:29  <indutny>but it seems that callback is trying to be invoked after FSEventStream is released
07:33:15  <bnoordhuis>i've no idea what could be causing that
07:33:32  <bnoordhuis>if it's your plain old memory corruption, you'd expect a SIGSEGV, not a SIGBUS
07:34:32  <bnoordhuis>but well, once 10.9 is officially released and all the SF/SV hipsters upgrade, we'll find out soon enough
07:38:27  * mralephquit (Read error: Connection reset by peer)
07:38:28  * mraleph1joined
07:40:17  <indutny>yeah
07:40:47  <indutny>bnoordhuis: its actually a EXC_BAD_ACCESS
07:40:59  <indutny>SIGBUS is a result of it
07:42:50  <bnoordhuis>ah okay
07:43:42  <indutny>actually, I think that it might be a kernel bug
07:43:47  <indutny>well
07:43:50  <indutny>FSEvents bug
07:43:57  <indutny>its not related to kernel at all
07:45:12  <bnoordhuis>bugs in apple software? unheard of!
07:45:35  <bnoordhuis>but what makes you think so?
07:50:47  <indutny>well
07:50:53  <indutny>first of all
07:51:08  <indutny>we seen no such crashes on older versions
07:51:31  <indutny>and its pretty stable on new osx
07:51:50  <indutny>also
07:51:53  <indutny>I like to blame other people
07:52:57  <bnoordhuis>especially apple engineers
07:53:02  <bnoordhuis>they have it coming though
08:04:11  * paddybyersjoined
08:07:06  <wolfeidau>Anyone know if tjfontaine pushed changes relating to the ReadableState issue in tls? I wanted to test it against some stuff i am working on
08:16:09  * hzjoined
08:20:41  <MI6>joyent/node: Ben Noordhuis v0.10 * 9a3a0cc : doc: expand os.loadavg() section - http://git.io/SOs7TA
08:20:57  <bnoordhuis>wolfeidau: don't know, sorry
08:21:23  <bnoordhuis>haven't seen any commits from tj lately though
08:23:15  <wolfeidau>I have been trying to find the issue causing quite pronounced increase in memory when using TLS, and no matter how much i poke and prod the code I can't seem to find any clues
08:23:46  * amartensquit (Quit: Leaving.)
08:31:13  * bajtosquit (Quit: bajtos)
08:31:48  <MI6>nodejs-v0.10: #1534 UNSTABLE smartos-x64 (5/601) smartos-ia32 (4/601) linux-ia32 (1/601) osx-ia32 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1534/
08:35:13  <MI6>nodejs-v0.10-windows: #261 UNSTABLE windows-ia32 (10/601) windows-x64 (9/601) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/261/
08:40:14  <bnoordhuis>executing: git am 6350.patch
08:40:14  <bnoordhuis>Patch format detection failed.
08:40:14  <bnoordhuis>Command exited with non-zero: git am 6350.patch
08:40:25  <bnoordhuis>^ i'm guessing github was down again...
08:45:44  <MI6>joyent/node: Rod Vagg master * 684dd28 : util: format as Error if instanceof Error - http://git.io/EL7DeA
08:48:06  * bajtosjoined
08:55:32  * Kakerajoined
08:55:59  * amartensjoined
08:56:12  <rvagg>
08:58:14  <MI6>nodejs-master: #613 UNSTABLE osx-x64 (1/645) smartos-ia32 (5/645) smartos-x64 (8/645) http://jenkins.nodejs.org/job/nodejs-master/613/
09:01:26  * bnoordhuisquit (Ping timeout: 264 seconds)
09:01:55  * kenperkinsjoined
09:02:38  * amartensquit (Ping timeout: 240 seconds)
09:04:27  <MI6>nodejs-master-windows: #407 UNSTABLE windows-x64 (21/645) windows-ia32 (21/645) http://jenkins.nodejs.org/job/nodejs-master-windows/407/
09:11:33  * bnoordhuisjoined
09:32:33  * abraxas_joined
09:32:50  * wolfeida_joined
09:38:34  * abraxasquit (Read error: Connection reset by peer)
09:38:34  * wolfeidauquit (Read error: Connection reset by peer)
09:38:34  * qmxquit (Ping timeout: 272 seconds)
09:39:43  * qmxjoined
09:41:35  * staropramjoined
09:45:36  * kazuponquit (Remote host closed the connection)
10:09:05  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * 9d44d78 : unix, windows: add uv_fs_event_start/stop functions - http://git.io/Du8cZQ
10:13:01  <MI6>libuv-master: #285 UNSTABLE linux (1/195) windows (4/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/285/
10:14:41  <MI6>libuv-master-gyp: #225 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/225/
10:25:51  <MI6>libuv-node-integration: #270 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/270/
10:27:38  <wolfeida_>rvagg: Nice work mate
10:27:41  * piscisaureus_joined
10:30:47  * inolenquit (Ping timeout: 260 seconds)
10:32:03  * inolenjoined
10:40:48  <rendar>piscisaureus_: hi, yesterday i was reading about uv_read_t, i think its a cool thing, but i didn't get why you were speaking about of a ReadFile of 0 bytes
10:42:22  <piscisaureus_>rendar: on windows things (read and write and accept) happen in the background
10:42:30  <piscisaureus_>rendar: and for read and write you must pass a buffer
10:42:37  <rendar>yeah
10:42:59  <piscisaureus_>rendar: but if you have many open sockets that are all reading, those pre allocated buffers add up quickly
10:43:12  <piscisaureus_>so we pass a 0 byte length buffer (mostly to WSARecv, sometimes to ReadFile)
10:43:33  <piscisaureus_>and then when the 0 bytes read is complete, we get the actual data out with a nonblocking read
10:43:37  <rendar>hmm
10:44:12  <piscisaureus_>this works because 0-byte reads only complete when there's actually something in the kernel buffer
10:44:55  <piscisaureus_>rendar: libuv also has a mode where reading is done the canonical way, but it's currently disabled
10:45:02  <rendar>oh, i think i got that
10:45:19  <piscisaureus_>rendar: because the performance gain was almost unmeasurable
10:45:32  <piscisaureus_>and the memory benefits of 0-reads are obvious
10:45:53  <rendar>piscisaureus_: btw, shouldn't iocp work also with a normal nonblocking (so with a OVERLAPPED) ReadFile() on on_open() and next ReadFile()s on on_read()? isn't this the canonical way?
10:46:56  <rendar>so instead of passing that new OVERLAPPED in on_open() callback, you do a read of 0 bytes, so you will allocate a new OVERLAPED *only* when the client effectively send data, no otherwise..
10:49:00  <rendar>piscisaureus_: so the basic idea is to start a ReadFile of 0 bytes with a static and unique OVERLAPPED structure that doesn't cost more memory, if i got it, and then starting allocating new OVERLAPPEDs only *IF* there is data to read?
10:51:50  <MI6>nodejs-v0.10: #1535 UNSTABLE smartos-x64 (6/601) smartos-ia32 (6/601) linux-ia32 (1/601) http://jenkins.nodejs.org/job/nodejs-v0.10/1535/
10:53:04  <piscisaureus_>rendar: that's effectively what happens, because the OVERLAPPED that we use to do 0-reads is embedded in the uv_tcp_t struct
10:53:08  <piscisaureus_>so it doesn't get allocated
10:53:20  <rendar>i see
10:53:41  <piscisaureus_>rendar: we don't pass an overlapped to nonblocking WSARecv/ReadFile
10:53:48  <rendar>piscisaureus_: so exist one unique OVERLAPPED for new connections, and its shared between all HANDLEs?
10:53:56  <piscisaureus_>rendar: no
10:54:00  <piscisaureus_>rendar: it's per tcp handle
10:54:05  <rendar>oh, i see
10:54:08  <piscisaureus_>rendar: sharing OVERLAPPEDs that way is not allowed
10:54:34  <rendar>yeah because iirc the kernel must copy the OVERLAPPED structure in the non pageable pool of memory, etc..
10:54:35  <piscisaureus_>rendar: there can only be one pending operation per OVERLAPPED
10:54:39  <piscisaureus_>rendar: no
10:54:48  <piscisaureus_>rendar: windows will update fields of the overlapped
10:54:59  <piscisaureus_>while the operation happens
10:55:07  <rendar>yeah, right
10:56:24  * staroprampart ("Leaving")
10:56:31  <rendar>but if on a new connection we have to allocate a uv_tcp_t structure, which in fact contains a OVERLAPPED, is it worth? i mean, if we have to allocate memory for uv_tcp_t+OVERLAPPED, ins't the same of allocating uv_tcp_t (without an OVERLAPPED) and using the canonical way of ReadFile?
10:57:08  <piscisaureus_>rendar: no
10:57:16  <piscisaureus_>rendar: the OVERLAPPED is small, only a handful of bytes
10:57:32  <piscisaureus_>rendar: but the buffer to receive the actual data is ideally ~64 kb
10:57:34  <rendar>oh, ok! now i got the reason!
11:01:23  * abraxas_quit (Remote host closed the connection)
11:01:55  * abraxasjoined
11:02:18  <rendar>piscisaureus_: just for the sake of knowledge, i saw that AIX has iocp apis, and they're very similar to the windows' ones. really? does it uses the same apis of windows?
11:03:11  * bajtosquit (Quit: bajtos)
11:06:08  * abraxasquit (Ping timeout: 240 seconds)
11:23:58  * wolfeida_changed nick to wolfeidau
11:42:05  * inolenquit (Quit: Leaving.)
12:10:22  <bnoordhuis>hah, trying to capture a heap snapshot when v8 is out of memory is not a great idea
12:12:23  <bnoordhuis>25630 retained WriteReqs after ~2s of running... i will go out on a limb and say we can do better
12:17:36  * c4milojoined
12:31:50  * bnoordhuisquit (Ping timeout: 240 seconds)
12:35:03  * bajtosjoined
13:12:40  * bnoordhuisjoined
14:07:22  <MI6>joyent/node: Jason Gerfen master * 7f66e44 : crypto: add SPKAC support - http://git.io/CgY1dQ
14:19:59  <MI6>nodejs-master: #614 UNSTABLE osx-x64 (2/646) smartos-ia32 (7/646) smartos-x64 (9/646) osx-ia32 (1/646) linux-ia32 (1/646) http://jenkins.nodejs.org/job/nodejs-master/614/
14:28:00  <MI6>nodejs-master-windows: #408 UNSTABLE windows-x64 (22/646) windows-ia32 (20/646) http://jenkins.nodejs.org/job/nodejs-master-windows/408/
14:28:23  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
14:30:47  * AvianFlujoined
14:33:55  * inolenjoined
14:34:18  * defunctzombie_zzchanged nick to defunctzombie
14:44:27  * mikealquit (Quit: Leaving.)
14:58:46  * bradleymeckjoined
15:00:57  * amartensjoined
15:05:02  * amartensquit (Ping timeout: 240 seconds)
15:06:18  * mikealjoined
15:20:07  <MI6>nodejs-master: #615 UNSTABLE osx-x64 (1/646) smartos-ia32 (8/646) linux-x64 (1/646) smartos-x64 (8/646) osx-ia32 (1/646) http://jenkins.nodejs.org/job/nodejs-master/615/
15:25:48  * dapjoined
15:40:49  <bnoordhuis>indutny: ping
15:41:27  * indexzerojoined
15:44:47  * dshaw_joined
15:47:36  * kenperkinsjoined
15:51:03  * bradleymeckquit (Quit: bradleymeck)
15:51:49  * amartensjoined
15:52:33  <isaacs>good morning
15:52:38  <isaacs>call in 0:10 or so?
15:54:36  <bnoordhuis>guess so. anything worthwhile to discuss?
15:59:48  <isaacs>yeah!
16:00:02  <isaacs>tjfontaine seems to be here in laptop, but not in his physical form.
16:00:12  * bradleymeckjoined
16:00:20  <isaacs>maybe someone stolehis laptop and put it at his desk to make it look like he's at work today
16:00:57  <bnoordhuis>sounds implausible. bit out of character, right?
16:01:13  <bnoordhuis>do we have a g+ link?
16:03:41  <tjfontaine>I'm an ethereal character
16:03:57  <tjfontaine>https://plus.google.com/hangouts/_/e8121e97c0b096631f4f703d0335f49cce948b4a
16:03:59  <bnoordhuis>http://www.usdebtclock.org/ <- this is strangely mesmerizing
16:04:14  <isaacs>https://plus.google.com/hangouts/_/e8121e97c0b096631f4f703d0335f49cce948b4a
16:05:36  * defunctzombiechanged nick to defunctzombie_zz
16:10:37  * mikealquit (Quit: Leaving.)
16:15:57  * indexzero_joined
16:16:07  * indexzeroquit (Ping timeout: 272 seconds)
16:16:08  * indexzero_changed nick to indexzero
16:28:01  * dshaw_quit (Quit: Leaving.)
16:28:21  * dshaw_joined
16:46:29  * st_lukejoined
16:52:41  * wwicksquit (Quit: wwicks)
16:53:24  * brsonjoined
17:01:26  * octetcloudjoined
17:02:39  * mikealjoined
17:03:25  * dominictarrjoined
17:08:49  * dshaw_quit (Quit: Leaving.)
17:09:34  * TooTallNatejoined
17:10:32  * dshaw_joined
17:17:44  * dominictarrquit (Quit: dominictarr)
17:21:10  * AvianFluquit (Remote host closed the connection)
17:23:40  * bnoordhuisquit (Ping timeout: 265 seconds)
17:28:07  * piscisaureus_quit (Ping timeout: 246 seconds)
17:30:24  * AvianFlujoined
17:32:50  * julianduquejoined
17:32:57  * paulfryzeljoined
17:36:42  * st_lukequit (Read error: Connection reset by peer)
17:36:57  * st_lukejoined
17:45:19  * dominictarrjoined
17:47:14  * st_lukequit (Read error: Connection reset by peer)
17:47:34  * st_lukejoined
17:52:07  * st_lukequit (Ping timeout: 272 seconds)
17:53:09  <MI6>libuv-master: #286 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/286/
17:53:41  * kenperkinsquit (Quit: Computer has gone to sleep.)
17:56:25  * st_lukejoined
18:00:34  <MI6>libuv-node-integration: #271 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/271/
18:13:17  * dapquit (Ping timeout: 272 seconds)
18:13:52  * defunctzombie_zzchanged nick to defunctzombie
18:28:11  * dapjoined
18:29:02  * bnoordhuisjoined
18:31:37  * dapquit (Client Quit)
18:32:46  * st_lukequit (Remote host closed the connection)
18:33:14  * st_lukejoined
18:33:32  * bnoordhuisquit (Ping timeout: 256 seconds)
18:33:59  * c4miloquit (Remote host closed the connection)
18:34:32  * c4milojoined
18:35:07  * dshaw_quit (Quit: Leaving.)
18:37:59  * st_lukequit (Ping timeout: 272 seconds)
18:39:15  * c4miloquit (Ping timeout: 272 seconds)
18:45:26  <MI6>nodejs-master-windows: #409 UNSTABLE windows-x64 (22/646) windows-ia32 (22/646) http://jenkins.nodejs.org/job/nodejs-master-windows/409/
19:03:19  * bajtosquit (Quit: bajtos)
19:05:26  * dominictarrquit (Quit: dominictarr)
19:05:35  * dshaw_joined
19:06:04  * st_lukejoined
19:06:58  * bnoordhuisjoined
19:07:14  * piscisaureus_joined
19:07:17  * dshaw_quit (Read error: Connection reset by peer)
19:07:30  * dshaw_joined
19:11:08  * st_lukequit (Read error: Connection reset by peer)
19:11:34  * st_lukejoined
19:12:24  <MI6>joyent/node: jas- master * f4528a3 : doc: crypto: document SPKAC additions - http://git.io/YKKfdA
19:12:33  * dshaw_quit (Ping timeout: 272 seconds)
19:13:00  <MI6>joyent/node: Jason Gerfen master * aa94450 : doc: crypto: document SPKAC additions - http://git.io/ISVyjQ
19:14:32  <trevnorris>bnoordhuis: just fyi, i did an upgrade to 3.21.17 to test some stuff out. the ArrayBuffer class made a small change.
19:15:01  <trevnorris>now it required Allocate() and AllocateUninitialized()
19:15:56  <bnoordhuis>yeah, that's right. i have a PR somewhere that upgrades v8 with a fixup for htat
19:15:57  <bnoordhuis>*that
19:16:13  <trevnorris>ah, ok :)
19:24:20  <MI6>nodejs-master: #616 UNSTABLE osx-x64 (3/646) smartos-ia32 (7/646) smartos-x64 (8/646) osx-ia32 (1/646) http://jenkins.nodejs.org/job/nodejs-master/616/
19:30:22  <trevnorris>othiym23: ping
19:31:13  <MI6>nodejs-master-windows: #410 UNSTABLE windows-x64 (20/646) windows-ia32 (21/646) http://jenkins.nodejs.org/job/nodejs-master-windows/410/
19:31:39  <trevnorris>groundwater_: ping too
19:35:44  * dshaw_joined
19:36:09  <MI6>nodejs-master: #617 UNSTABLE osx-x64 (1/646) smartos-ia32 (7/646) smartos-x64 (8/646) osx-ia32 (2/646) http://jenkins.nodejs.org/job/nodejs-master/617/
19:39:25  * defunctzombiechanged nick to defunctzombie_zz
19:40:40  * st_lukequit (Remote host closed the connection)
19:41:11  * c4milojoined
19:42:20  * st_lukejoined
19:46:50  * EhevuTovjoined
19:47:12  * st_lukequit (Ping timeout: 256 seconds)
19:50:08  <MI6>nodejs-master-windows: #411 UNSTABLE windows-x64 (22/646) windows-ia32 (21/646) http://jenkins.nodejs.org/job/nodejs-master-windows/411/
19:52:33  * dshaw_quit (Ping timeout: 265 seconds)
20:02:01  <trevnorris>wtf. sometimes I hate modules. just did a --dev install just so I could run the benchmarks and now it's installing like half a gig of deps
20:06:24  * dapjoined
20:06:47  * dominictarrjoined
20:14:04  * piscisaureus_quit (Ping timeout: 260 seconds)
20:19:19  * c4miloquit (Remote host closed the connection)
20:19:53  * c4milojoined
20:20:21  <groundwater_>trevnorris: ACK
20:22:31  * indexzero_joined
20:24:10  * c4miloquit (Ping timeout: 245 seconds)
20:25:26  * indexzeroquit (Ping timeout: 264 seconds)
20:25:27  * indexzero_changed nick to indexzero
20:27:58  <trevnorris>groundwater_: so, was wondering about possibly allowing the override of before/after/error in the return value of the asyncListener.
20:28:31  <trevnorris>groundwater_: but now, can't find a good reason why that'd be useful.
20:29:06  <groundwater_>trevnorris: i'm not sure i'm clear what you mean by override
20:29:54  <trevnorris>so say you do createAsyncListener(function(value) { if (value === true) return { before: fn() { } }; }, {}, true);
20:30:31  <trevnorris>if the return value from asyncListener was an object, and had a before/after/error fields that were functions, then it would overwrite whatever was initially passed to createAsync
20:31:01  <groundwater_>is there a use-case that would require this?
20:31:08  <trevnorris>no idea.
20:31:19  <trevnorris>hence the ping. :)
20:31:41  <groundwater_>heh, no worries
20:32:24  <groundwater_>i would prefer keeping the scope of the return value narrow
20:32:32  <groundwater_>i.e. just the storage object
20:32:51  <trevnorris>coolio
20:33:49  <groundwater_>actually, you could just pass in handlers that "interpreted" the storage object as a before/after/error object and forwarded calls to it
20:37:30  * Benviequit (Ping timeout: 265 seconds)
20:47:17  * dshaw_joined
20:51:32  * dshaw_quit (Ping timeout: 240 seconds)
20:53:24  <trevnorris>bnoordhuis: you know of a good way to generate a performance tree that shows where times went? I used perf -e cycles:u -g, then perf report --sort=dso, and it tells me 60% of execution time is in node, but when I drill down it's so ambiguous.
20:55:38  <bnoordhuis>trevnorris: what do you want to profile? functions?
20:55:52  <groundwater_>trevnorris: i'm working on some tests for async-listener
20:55:53  <groundwater_>https://github.com/jacobgroundwater/node/commit/10dc2da9da312e906d734acf65d4d0c7983e1eee
20:56:17  <groundwater_>for whatever reason, i can't create a PR between my repo and yours on GH
20:56:42  <trevnorris>bnoordhuis: yeah. the execution time for each function is small, so I'm looking for a way to see the bigger picture of how long those are getting called.
20:57:45  <trevnorris>bnoordhuis: honestly, i'm really trying to figure out why perf report --sort=dso is telling me 60% of execution time is spent in node.
20:57:45  <trevnorris>i build a custom data receiver that sits directly on top of pipe_wrap
20:58:00  <trevnorris>and so I want to know where the time is going.
20:58:10  <trevnorris>since time in js is almost next to nothing.
20:58:58  * c4milojoined
20:59:05  <trevnorris>groundwater_: great thanks. i'll talke a look at these a little later. thanks for all the help on this.
21:00:04  <groundwater_>trevnorris: no problem, it's such a subtle area i want to make sure the semantics are as explicit as possible
21:00:56  * c4miloquit (Read error: Connection reset by peer)
21:01:30  * c4milojoined
21:03:10  <bnoordhuis>trevnorris: perf report gives a per-function breakdown by default, right?
21:03:39  <bnoordhuis>i wager you don't want --sort=dso
21:04:04  <trevnorris>well, when I record with -g I can drill down to the by function
21:04:11  <othiym23>trevnorris: I agree with my esteemed colleague groundwater_ on keeping the scope of behavior of the listener returns as narrowly focused as is practicable
21:04:13  * dshaw_joined
21:04:30  <trevnorris>othiym23: agreed. was just brainstorming.
21:04:47  <othiym23>NO DON'T
21:04:48  <LOUDBOT>SO WHY CAN'T I CALL YOUR MOBILE PHONE?!
21:04:50  <othiym23>;)
21:07:01  <trevnorris>bnoordhuis: so, both perf and --prof tell me ~40% is in syscalls and the rest is in node. all percentages in perf report are < 3%, but I think that's because it's not showing like, hey function A called function B so A's time is A + B's time. type breakdown.
21:07:05  <trevnorris>make sense?
21:09:45  <bnoordhuis>ah, you want top-down vs bottom-up graphs
21:09:53  <trevnorris>yeah :)
21:11:10  <bnoordhuis>okay, that's what -g is for
21:11:41  <bnoordhuis>`perf report -g` that is
21:12:16  <bnoordhuis>or -G to invert
21:13:15  <indutny>bnoordhuis: pong
21:13:53  <bnoordhuis>indutny: hey. never mind, we figured it out
21:15:32  <indutny>:)
21:15:33  <indutny>ok
21:15:39  <indutny>I was on the plane
21:15:44  <indutny>so
21:15:46  <indutny>what's up?
21:16:40  <bnoordhuis>indutny: nothing much. just discussing that pipelining thing
21:17:07  <indutny>ok, and what's result of this discussion?
21:17:10  <indutny>what will we do?
21:17:16  <indutny>backpressure pausing?
21:17:21  <indutny>backpressure-driven
21:17:27  <bnoordhuis>the conclusion was that http is hard. then we went shopping
21:17:38  <bnoordhuis>also, that there's actually two issues
21:17:41  <indutny>ah, ok then
21:17:45  <indutny>really?
21:17:51  <indutny>may be PM me?
21:17:58  <bnoordhuis>oh, okay
21:17:59  <indutny>not sure if its good idea to discuss it that openly
21:18:17  <bnoordhuis>well, it's not exactly rocket science but okay
21:18:49  <trevnorris>bnoordhuis: know if there's a trick to get the cumulative time for a match? mainly, I want to find out how much time is spent in v8::internal.
21:20:29  <bnoordhuis>trevnorris: you can maybe do some quick perl/awk magic with `perf report --stdio`
21:20:39  <bnoordhuis>else you'll have to whip up something with `perf script`
21:20:48  <trevnorris>cool. i'll try that out. thanks
21:21:52  * rendarquit
21:21:54  <trevnorris>because it looks like +80% of node execution time is in v8::internal, and maybe that's something I just have to eat.
21:23:37  <indutny>heya
21:23:40  <bnoordhuis>hoya
21:23:48  <indutny>who's going to work on GH-sec issue?
21:23:58  <indutny>isaacs: tjfontaine: let me know if I can help you in any way
21:24:13  <isaacs>indutny: got a fix
21:24:17  <indutny>ok
21:24:20  <indutny>for both cases?
21:24:23  <isaacs>passes the tests, i'm just reading the code now to make sure i like it :)
21:24:56  <isaacs>especially, trying to figure out why the readStop and readStart are required, because they shouldn't be
21:25:56  <bnoordhuis>because else incoming data keeps getting handed off to js land, right?
21:26:25  <bnoordhuis>you want the tcp stack to start sending out 'back off yo' packets
21:26:49  <indutny>haha
21:27:14  <indutny>isaacs: well, because input and output streams are not backpressure-affecting each other
21:27:28  <indutny>isaacs: basically, there're almost independent
21:27:34  <isaacs>yeah
21:29:22  <trevnorris>whoot. got max throughput on pipe_wrap up to 42Gb/s.
21:31:08  * julianduquequit (Ping timeout: 240 seconds)
21:32:16  * wwicksjoined
21:32:28  <trevnorris>bnoordhuis: dude, I love libuv. in all my perf reports I have to scroll like two pages down before I see the first uv_* show up.
21:32:47  <trevnorris>and it's always registered as like < 0.1%
21:35:16  <bnoordhuis>we try, we try :)
21:35:34  <bnoordhuis>admittedly it's the kernel that does most of the heavy lifting
21:35:45  <bnoordhuis>libuv just tickles it in the right way, so to speak
21:36:46  <trevnorris>heh
21:37:31  * c4miloquit (Remote host closed the connection)
21:38:04  * c4milojoined
21:39:37  * bradleymeckquit (Quit: bradleymeck)
21:42:55  * c4miloquit (Ping timeout: 272 seconds)
21:43:41  * st_lukejoined
21:48:22  <trevnorris>so think we agreed to upgrade to 3.21. was there a timeline on that?
21:50:48  <bnoordhuis>trevnorris: i believe as soon as tjfontaine gets v0.11.8 out the door :)
21:50:58  <trevnorris>awesome. tjfontaine hurry!!! ;)
21:51:05  <trevnorris>i want v0.12 out so freakin bad.
21:57:51  * st_lukequit (Read error: Connection reset by peer)
21:58:08  <trevnorris>bnoordhuis: i'm not sure how v8's doing it, but gc times are ~3% total execution time with my direct bindings on top of pipe_wrap.
21:58:08  <trevnorris>but do the same w/ the streams api and it ramps up to +20%
21:58:11  * st_lukejoined
21:58:43  <trevnorris>must be because the incoming buffer's life is only withing the called handlescope, not passed to another function that's called on nextTick or whatever.
21:59:41  * st_lukequit (Read error: Connection reset by peer)
22:00:34  <trevnorris>but i'm pretty happy about this. libuv's pipe_pump1_client reaches 57Gb/s, and the pipe_wrap binding reaches 42Gb/s
22:01:45  * AvianFluquit (Remote host closed the connection)
22:02:56  * Benviejoined
22:04:07  <bnoordhuis>trevnorris: that's because streams create a lot of garbage
22:04:28  <bnoordhuis>also because they consist of many objects with overlapping life cycles
22:04:40  <bnoordhuis>that's always something of a though nut for garbage collectors
22:04:47  <bnoordhuis>er, tough
22:05:06  <trevnorris>bnoordhuis: just fyi, if I change WRITE_BUFFER_SIZE from 8192 to (1024 * 32) pipe_pump goes from 57Gb/s to 62Gb/s
22:05:17  <trevnorris>an, interesting.
22:05:43  <bnoordhuis>trevnorris: oh, yeah, that doesn't surprise me
22:05:54  <trevnorris>so it seems my buffer-dispose module solves a problem that could be avoided.
22:06:04  <trevnorris>cool.
22:06:48  <trevnorris>well, i'm interested in all your feedback for what I have in mind for v0.13.
22:07:04  <trevnorris>can I give you an example, or you off to bed. (man it's killing me today)
22:07:22  <bnoordhuis>shoot
22:07:38  <bnoordhuis>i still have this bowl of cruesli to finish so
22:07:48  <trevnorris>heh, ok. quickly then...
22:09:29  <trevnorris>all classes that make calls to MakeCallback will have a "default" callback as a Persistent<Function> (e.g. Persistent<Function> oncomplete_) that can be set with like require('tcp_wrap').TCPWrap.oncomplete = fn (that's more pseudo code)
22:09:47  <trevnorris>because in the majority of cases we don't change the callback while the request is in transit
22:10:02  <trevnorris>then when it comes back we don't have to access an object property for the callback.
22:11:00  <trevnorris>and, I mean technically if we didn't need the request object to exist in js then we could bypass the entire step of creating the Persistent<Object> all together. (though haven't exactly figured that one out yet)
22:11:02  <bnoordhuis>doesn't really work if you have many overlapping requests, right?
22:12:27  <bnoordhuis>on that note, i've been thinking about how to get rid of persistents and all the mallocs for write reqs
22:12:39  <trevnorris>yeah, because you still instantiate a new ReqWrap, so the data coming in will be unique. and since we have the "context" object stored as a Persistent<Object> anyways it's passed as the "this"
22:12:42  <trevnorris>oh, do tell.
22:13:12  <bnoordhuis>my thinking was that we mmap largish chunks of memory at a fixed address, i.e. mmap(MAP_FIXED)
22:13:27  <bnoordhuis>the kernel assigns the initial address but afterwards we expand it upwards
22:13:58  <bnoordhuis>the pointer to that memory gets assigned to some global object with SetIndexedPropertiesToExternalArrayData()
22:14:27  <bnoordhuis>then instead of req objects, we simply operate on integers that represent offsets in that mapped memory
22:14:49  <trevnorris>hah, loving it.
22:15:01  <bnoordhuis>i.e. our_internal_heap[write_req_1] points to the first byte of the struct that c++ land needs
22:15:15  <bnoordhuis>downside is of course that you can only go up to 1 GB
22:15:35  <bnoordhuis>and that the address space on 32 bits archs is kind of cramped, you may get malloc/mmap failures quicker that way
22:15:58  <bnoordhuis>still, interesting experiment, right?
22:16:08  <trevnorris>heck yeah.
22:16:20  <trevnorris>we should be able to reuse a ReqWrap instance anyways, right?
22:16:43  <bnoordhuis>in most cases, yes
22:16:46  <trevnorris>the lifespan of that is deterministic, so it could be placed in a linked list or what not, and reused.
22:17:46  <bnoordhuis>right, but then you still need to malloc + maintain a persistent + create a wrapper object
22:18:02  <bnoordhuis>er, not malloc
22:18:11  <trevnorris>yeah, I got ya
22:19:02  <bnoordhuis>the wrapper object itself is not something i'm really worried about
22:19:14  <bnoordhuis>but persistents are kind of troublesome, especially weak ones
22:19:57  <trevnorris>seriously.
22:20:44  * hzquit
22:21:09  <trevnorris>bnoordhuis: well, wait. if you assign the memory address to the object via SetIndexed..., then any method calls go into c++ and just get that memory address via GetIndexed..., right?
22:21:24  <trevnorris>so, i'm not sure why that would be limited to 1GB.
22:22:14  <bnoordhuis>trevnorris: what method calls?
22:22:27  <trevnorris>basically, static_cast<ReqWrap*>(args.This()->GetIndexed...())->WriteBuffer();
22:23:16  <bnoordhuis>oh, right. yeah, it's not an issue on the c++ side of things
22:23:34  <bnoordhuis>but it is when you're exposing the memory to js land
22:23:47  <bnoordhuis>which you presumably want so you can expose e.g. integer properties directly
22:24:00  <trevnorris>how do you mean?
22:24:19  <bnoordhuis>i.e. var write_req_size = heap32[offset >> 2]
22:24:38  <bnoordhuis>assuming that the first field of the c++ struct is the write_req_size
22:24:46  <bnoordhuis>just an example, of course
22:25:13  <trevnorris>whoa... didn't get that part of it. so you're talking skipping the initial call into c++ all together?
22:25:28  <bnoordhuis>yeah
22:25:32  <trevnorris>I was thinking you'd still do the TCPWWrap() call to c++ then assign external memory to the object.
22:25:35  <bnoordhuis>we'd be basically managing our own heap
22:26:10  <bnoordhuis>but js and c++ land would have uniform views of the memory
22:26:15  * paddybyersquit (Quit: paddybyers)
22:26:21  <trevnorris>but then, would you have a pool of objects that already have external memory assigned, that would be reused?
22:26:28  <bnoordhuis>and js land only needs to store / deal with integers, not wrapper objects
22:26:43  <bnoordhuis>so there's your answer :)
22:27:23  <trevnorris>then, what, a WriteBuffer would pass a number (i.e. offset) instead of passing an object?
22:27:33  <trevnorris>*would recieve
22:27:38  <trevnorris>that's the offset on the heap?
22:27:58  <bnoordhuis>yep
22:28:02  <trevnorris>...
22:28:25  <trevnorris>dude, this is an entirely different level of performance enhancements.
22:28:26  <bnoordhuis>and because it's memory-mapped, c++ land only needs to wrap* w = (wrap*) heap_ptr + offset
22:28:31  <bnoordhuis>right :)
22:28:49  <bnoordhuis>'tis a bit of work though
22:28:57  <trevnorris>heh, yeah. a little
22:29:42  <trevnorris>so, I haven't benchmarked how fast a Uint32Value() is, but I have been experimenting with writing to external memory just before the c++ method call, then reading out that memory from the c++ side.
22:29:58  <bnoordhuis>and?
22:30:06  <trevnorris>well, pretty freakin fast.
22:30:22  <trevnorris>writing to external memory is sub nanosecond, and so is reading it out.
22:30:54  <trevnorris>an if you're not doing anything with v8 whatever's in c++ the methods seem to optimize much better.
22:31:07  <trevnorris>probably because you skip a bunch of v8::internal calls.
22:31:40  * wwicksquit (Ping timeout: 245 seconds)
22:32:47  <trevnorris>so, it'd be really ugly, but it's be like, heapPointer[kLocation] = heap32[offset >> 2]; then the WriteBuffer call.
22:33:05  <trevnorris>in which it'd be like void* ptr = env()->heap_pointer();
22:33:07  * wwicksjoined
22:33:23  <trevnorris>since the call is synchronous, and currently single threaded, that should be safe, right?
22:33:30  <bnoordhuis>yep
22:33:52  <trevnorris>awesome. :)
22:35:11  <trevnorris>well, have some things to think about and test out.
22:35:34  <trevnorris> but first, need to force myself to finish docs for #6011
22:35:53  <bnoordhuis>good :) then i'll hit the sack. maybe some lightweight reading first
22:36:07  <trevnorris>fun fun, night :)
22:36:42  <bnoordhuis>the original treatise on hindler-milney type inference is quite good, heartily recommended!
22:36:48  <bnoordhuis>okay, sleep tight :)
22:37:34  <trevnorris>hah, yeah. just what I like to read before bed.
22:38:20  * Kakeraquit (Ping timeout: 245 seconds)
22:41:15  * bnoordhuisquit (Ping timeout: 245 seconds)
22:42:40  * wwicksquit (Quit: wwicks)
22:59:23  <MI6>joyent/node: isaacs master * a555992 : Revert "doc: crypto: document SPKAC additions" (+1 more commits) - http://git.io/sKuLXw
23:00:03  <trevnorris>isaacs: why the revert?
23:00:20  <tjfontaine>he's commenting on the issue, but the test only passes on linux
23:00:41  <trevnorris>ah.
23:00:46  <trevnorris>wonder why that is.
23:01:04  <tjfontaine>feel free to investigate :P
23:01:12  <trevnorris>heh
23:03:47  * dshaw_quit (Quit: Leaving.)
23:05:09  * AvianFlujoined
23:05:57  * julianduquejoined
23:07:01  <trevnorris>tjfontaine: looks like it's something silly. the keys are exactly the same, but with the assertion error message cut I can't see the rest.
23:08:20  * Benviequit (Ping timeout: 245 seconds)
23:10:35  <trevnorris>tjfontaine: if I push a branch to joyent/node will it automatically run all tests?
23:11:51  <MI6>nodejs-master: #618 UNSTABLE osx-x64 (1/645) smartos-ia32 (7/645) smartos-x64 (7/645) http://jenkins.nodejs.org/job/nodejs-master/618/
23:12:59  * julianduquequit (Read error: Connection reset by peer)
23:15:32  * wwicksjoined
23:18:43  <MI6>joyent/node: trevnorris created branch pr6330-fix - http://git.io/50USEg
23:19:12  <MI6>nodejs-master-windows: #412 UNSTABLE windows-x64 (21/645) windows-ia32 (21/645) http://jenkins.nodejs.org/job/nodejs-master-windows/412/
23:22:28  * defunctzombie_zzchanged nick to defunctzombie
23:31:06  * c4milojoined
23:34:50  * c4miloquit (Remote host closed the connection)
23:35:09  * c4milojoined
23:39:27  <MI6>node-review: #91 UNSTABLE osx-x64 (3/646) smartos-x64 (9/646) centos-x64 (2/646) windows-x64 (20/646) linux-x64 (1/646) osx-ia32 (1/646) windows-ia32 (23/646) centos-ia32 (2/646) smartos-ia32 (8/646) http://jenkins.nodejs.org/job/node-review/91/
23:53:46  * wwicks_joined
23:53:57  * amartensquit (Quit: Leaving.)
23:55:01  * wwicksquit (Ping timeout: 272 seconds)
23:55:01  * wwicks_changed nick to wwicks
23:58:48  <MI6>libuv-master-gyp: #226 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/226/