00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:14:33  * thlorenzjoined
00:16:23  * mrhoorayjoined
00:18:53  * Kakeraquit (Ping timeout: 268 seconds)
00:20:51  * kpdeckerjoined
00:21:38  * mrhoorayquit
00:27:29  * paulfryzelquit (Remote host closed the connection)
00:28:06  * paulfryzeljoined
00:32:32  * paulfryzelquit (Ping timeout: 246 seconds)
00:39:19  * sh1mmerjoined
00:46:10  * petka_quit (Quit: Connection closed for inactivity)
00:47:21  * dap_quit (Quit: Leaving.)
01:14:20  * sh1mmerquit (Quit: sh1mmer)
01:15:14  * sh1mmerjoined
01:17:36  * indexzeroquit (Quit: indexzero)
01:17:53  * sh1mmerquit (Client Quit)
01:22:49  * sh1mmerjoined
01:26:24  * tjkrusinskijoined
01:28:30  * sh1mmerquit (Quit: sh1mmer)
01:29:42  * sh1mmerjoined
01:32:42  * jmar777joined
01:38:40  * hzquit
01:39:31  * sh1mmerquit (Quit: sh1mmer)
01:42:08  * sh1mmerjoined
01:51:47  * hzjoined
02:02:50  * tjkrusinskiquit (Ping timeout: 246 seconds)
02:08:14  * seldoquit (Remote host closed the connection)
02:14:10  * sh1mmerquit (Quit: sh1mmer)
02:14:57  * sh1mmerjoined
02:17:27  * tjkrusinskijoined
02:21:58  * tjkrusinskiquit (Ping timeout: 240 seconds)
02:29:59  * tjkrusinskijoined
02:30:22  * sh1mmerquit (Quit: sh1mmer)
02:31:57  * sh1mmerjoined
02:33:00  * indexzerojoined
02:33:32  * rosskquit
02:34:20  * tjkrusinskiquit (Ping timeout: 252 seconds)
02:34:33  * rmgquit (Remote host closed the connection)
02:34:33  * benviequit (Ping timeout: 268 seconds)
02:39:28  * kpdeckerquit (Quit: Leaving.)
02:42:56  * benviejoined
02:45:12  * hzquit
02:48:41  * paulfryzeljoined
02:52:53  * paulfryzelquit (Ping timeout: 246 seconds)
02:57:35  * stagasquit (Ping timeout: 265 seconds)
02:57:40  * indexzeroquit (Quit: indexzero)
03:05:15  * rmgjoined
03:06:05  * sh1mmerquit (Quit: sh1mmer)
03:07:40  * sh1mmerjoined
03:16:18  * rmgquit (Ping timeout: 240 seconds)
03:28:25  * paulfryzeljoined
03:28:39  * thlorenzquit (Remote host closed the connection)
03:29:13  * thlorenzjoined
03:29:20  * perezdjoined
03:30:08  * tjkrusinskijoined
03:32:47  * paulfryzelquit (Ping timeout: 246 seconds)
03:34:07  * thlorenzquit (Ping timeout: 264 seconds)
03:34:58  * julianduquequit (Quit: Lost terminal)
03:35:00  * tjkrusinskiquit (Ping timeout: 252 seconds)
03:35:39  * julianduquejoined
03:38:04  * indexzerojoined
03:38:56  * sh1mmerquit (Quit: sh1mmer)
03:41:21  * jmar777quit (Remote host closed the connection)
03:56:10  * sh1mmerjoined
04:02:39  * sh1mmerquit (Quit: sh1mmer)
04:06:27  * sh1mmerjoined
04:08:24  * perldorkjoined
04:11:16  * perldorkquit (Remote host closed the connection)
04:16:18  * kellabytequit (Ping timeout: 240 seconds)
04:17:01  * jmar777joined
04:29:10  * paulfryzeljoined
04:30:43  * kellabytejoined
04:30:53  * tjkrusinskijoined
04:30:57  * paulfryz_joined
04:33:18  * paulfryzelquit (Ping timeout: 240 seconds)
04:33:31  * TooTallNatejoined
04:35:26  * paulfryz_quit (Ping timeout: 246 seconds)
04:35:26  * tjkrusinskiquit (Ping timeout: 246 seconds)
04:41:39  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:53:09  * TooTallNatejoined
04:58:26  * mikolalysenkoquit (Ping timeout: 252 seconds)
05:04:54  * sh1mmerquit (Quit: sh1mmer)
05:06:09  * jmar777quit (Remote host closed the connection)
05:07:39  * sh1mmerjoined
05:26:12  * sh1mmerquit (Quit: sh1mmer)
05:27:21  * mikealjoined
05:28:55  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
05:31:38  * tjkrusinskijoined
05:37:29  * tjkrusinskiquit (Ping timeout: 252 seconds)
05:54:50  * mikolalysenkojoined
06:00:02  * mikolalysenkoquit (Ping timeout: 252 seconds)
06:02:35  * janjongboomjoined
06:16:13  * hueniversequit (Read error: Connection reset by peer)
06:16:56  * hueniversejoined
06:32:28  * paulfryzeljoined
06:34:18  * tjkrusinskijoined
06:36:53  * paulfryzelquit (Ping timeout: 246 seconds)
06:38:38  * tjkrusinskiquit (Ping timeout: 240 seconds)
06:39:38  * mikolalysenkojoined
06:40:35  * indexzeroquit (Quit: indexzero)
06:40:39  * quijotejoined
06:44:23  * m76joined
06:44:55  * mikolalysenkoquit (Ping timeout: 268 seconds)
06:45:06  * rmgjoined
06:46:22  * bradleymeck_joined
06:49:20  * rmgquit (Ping timeout: 252 seconds)
07:13:22  * sinclair|workjoined
07:15:08  * bajtosjoined
07:25:15  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:31:16  * bradleymeckquit (Quit: bradleymeck)
07:31:16  * bradleymeck_changed nick to bradleymeck
07:33:14  * paulfryzeljoined
07:37:26  * paulfryzelquit (Ping timeout: 246 seconds)
07:42:33  * [m76]joined
07:42:44  * [m76]quit (Client Quit)
07:42:53  * m76quit (Ping timeout: 268 seconds)
07:43:04  * m76joined
07:46:32  * kevinsimperjoined
08:00:06  * quijotequit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:00:22  * bajtosquit (Quit: bajtos)
08:30:43  * janjongboomjoined
08:33:55  * paulfryzeljoined
08:38:20  * paulfryzelquit (Ping timeout: 246 seconds)
09:13:44  * petka_joined
09:16:13  * perezdquit (Quit: perezd)
09:21:04  * bradleymeckquit (Quit: bradleymeck)
09:22:19  * bradleymeckjoined
09:33:58  * janjongboomquit (Ping timeout: 240 seconds)
09:34:47  * paulfryzeljoined
09:36:18  * janjongboomjoined
09:39:15  * paulfryzelquit (Ping timeout: 265 seconds)
10:00:10  * Kakerajoined
10:04:08  * hzjoined
10:21:35  * bradleymeckquit (Quit: bradleymeck)
10:22:36  * cphooverjoined
10:22:37  * stagasjoined
10:34:02  * cphooverquit (Quit: Leaving.)
10:34:19  * cphooverjoined
10:35:32  * paulfryzeljoined
10:36:55  * kevinsimperquit (Remote host closed the connection)
10:38:29  * cphooverquit (Ping timeout: 240 seconds)
10:39:47  * paulfryzelquit (Ping timeout: 246 seconds)
10:42:57  * stagasquit (Ping timeout: 268 seconds)
10:57:51  * kellabytequit (Changing host)
10:57:51  * kellabytejoined
10:57:51  * kellabytequit (Changing host)
10:57:51  * kellabytejoined
11:04:11  * Kakeraquit (Ping timeout: 252 seconds)
11:05:11  * kevinsimperjoined
11:24:52  * m76quit (Read error: Connection reset by peer)
11:36:17  * paulfryzeljoined
11:40:41  * paulfryzelquit (Ping timeout: 246 seconds)
12:09:51  * sinclair|workquit (Quit: ChatZilla [Firefox 27.0.1/20140212131424])
12:16:47  * cphooverjoined
12:20:59  * cphooverquit (Ping timeout: 240 seconds)
12:27:02  * cphooverjoined
12:37:00  * paulfryzeljoined
12:38:37  * quijote_joined
12:41:35  * paulfryzelquit (Ping timeout: 246 seconds)
12:42:24  * quijote_quit (Read error: Operation timed out)
12:45:40  * tjkrusinskijoined
13:07:11  * thlorenzjoined
13:07:59  * thlorenz_joined
13:08:06  * thlorenz_quit (Remote host closed the connection)
13:08:41  * thlorenz_joined
13:12:11  * thlorenzquit (Ping timeout: 268 seconds)
13:12:27  * paulfryzeljoined
13:13:05  * thlorenz_quit (Ping timeout: 246 seconds)
13:14:00  * Kakerajoined
13:14:50  * seldojoined
13:15:29  * thlorenzjoined
13:17:49  * seldoquit (Remote host closed the connection)
13:39:09  * AvianFlujoined
13:40:44  * jmar777joined
13:42:09  * thlorenzquit (Remote host closed the connection)
13:42:18  * bajtosjoined
13:44:35  * mikolalysenkojoined
13:57:50  * AvianFluquit (Remote host closed the connection)
13:58:20  * AvianFlujoined
14:05:26  * m76joined
14:11:46  * thlorenzjoined
14:12:56  * bajtosquit (Quit: bajtos)
14:13:08  * paulfryzelquit (Remote host closed the connection)
14:16:05  * bajtosjoined
14:19:12  * bajtos_joined
14:20:13  * bajtosquit (Read error: Operation timed out)
14:20:14  * bajtos_changed nick to bajtos
14:24:23  * tjkrusinskiquit (Ping timeout: 252 seconds)
14:26:13  * eddybjoined
14:26:28  <eddyb>is it intentional that uv_write takes an int instead of size_t?
14:26:38  * jmar777quit (Remote host closed the connection)
14:26:48  <eddyb>it causes an issue with buffers over 2GB
14:27:25  <eddyb>I'm not sure if we (Rust) should fix in the libuv wrapper, or send a patch upstream
14:31:01  <eddyb>hang on, our usage seems completely crazy
14:32:24  <eddyb>or we could be using an old libuv
14:34:05  * bajtosquit (Ping timeout: 265 seconds)
14:35:44  * bajtosjoined
14:37:56  * bajtosquit (Client Quit)
14:38:35  * paulfryzeljoined
14:41:37  * mikealquit (Quit: Leaving.)
14:43:02  * paulfryzelquit (Ping timeout: 246 seconds)
14:43:14  <saghul>the int is the size of the uv_buf_t array
14:43:23  <saghul>eddyb: ^
14:43:49  <eddyb>saghul: yeah, I figured and then realized we're using uv_fs_write and not uv_write
14:44:35  <saghul>latest libuv accepts a list of uv_buf_t, just like uv_write
14:45:00  <saghul>eddyb: updating would probably be best
14:45:22  <saghul>note: some tweaks will be needed as some apis have changed a bit
14:45:26  * bajtosjoined
14:47:36  <eddyb>https://github.com/rust-lang/libuv/blob/800b56fe6af21ffd8e56aee8cf12dd758f5bbdf1/include/uv.h#L1736-L1737
14:48:06  <eddyb>vs https://github.com/joyent/libuv/blob/master/include/uv.h#L1802-L1803
14:50:31  <eddyb>uvll::uv_write(req.handle, self.handle, [slice_to_uv_buf(buf)],
14:51:05  <eddyb>saghul: oh, it seems our current use of uv_write is not broken, and we have the wrappers for buffers, so the upgrade shouldn't be too hard
14:52:04  <eddyb>saghul: any chance you know whether 2GB writes via uv_fs_write work now?
14:52:38  <saghul>eddyb: why did they fail before?
14:53:01  <eddyb>it just truncates at MAX_INT
14:53:27  <saghul>ah
14:54:48  <eddyb>aww we have two unmerged commits on top of libuv https://github.com/rust-lang/libuv/commits/800b56fe6af21ffd8e56aee8cf12dd758f5bbdf1
14:55:56  * jmar777joined
14:56:06  <saghul>eddyb: those last 2?
14:56:28  <eddyb>the Feb 17 ones
14:56:54  * cphooverpart
14:57:09  <saghul>https://github.com/rust-lang/libuv/commit/800b56fe6af21ffd8e56aee8cf12dd758f5bbdf1 and https://github.com/rust-lang/libuv/commit/a91b91b1ae298c128f61daed7e1590526237f005
14:57:12  <saghul>?
14:57:15  * paulfryzeljoined
14:57:22  <eddyb>yupp
14:57:36  <saghul>are there PRs about those?
14:57:48  <eddyb>that's what I wanted to check but github confused me :/
14:58:05  <saghul>I don't think there are open PRs with those changes
14:58:43  <eddyb>https://github.com/joyent/libuv/commits/master/src/win/process.c okay, wasn't fixed in the meanwhile
15:00:04  <eddyb>saghul: they look simple enough though... I feel like I could just cherry-pick each of them on top of libuv master
15:00:36  <saghul>eddyb: yep, open a couple of PRs so we can have a look
15:00:56  <eddyb>okay, I was slacking on the Rust compiler anyways :P
15:02:02  <saghul>:-)
15:02:13  <saghul>I think we may have a problem on uv_fs_write
15:02:14  <eddyb>wow, no rebase failures, this is too simple
15:02:48  <saghul>if you send 2 buffers of INT_MAX size, when we store the amount of written data it would overflow, I think
15:05:35  <eddyb>saghul: wait, this has the "PATH on windows" commit https://github.com/joyent/libuv/issues/909
15:06:30  <saghul>oh
15:08:07  <eddyb>okay, let's just cherry pick the other one
15:09:58  * mikolalysenkoquit (Ping timeout: 268 seconds)
15:11:18  <saghul>eddyb: add a note on the other issue ;-)
15:11:38  <eddyb>hmm?
15:11:46  * tfogaljoined
15:12:17  <saghul>a "bump", hopefully bert catches it and we can apply the patch
15:12:46  <tfogal>seems simpler for me to just join here. so the newer libuv uses an array for the writes?
15:12:51  <saghul>my windows-fu is not very strong ;-)
15:13:07  <saghul>tfogal: yep
15:13:18  <tfogal>saghul: but it's still using an int or unsigned int for the size?
15:13:46  <eddyb>tfogal: always been size_t, sounds like the issue is internally, actually :/
15:13:48  <saghul>tfogal: each buffer stores the size as size_t
15:14:00  <eddyb>saghul: but the reason it hasn't been fixed yet is that the provided patch is a hack, AFAICT
15:14:27  <tfogal>wait, so I'm confused. if this is using a size_t, what's the issue?
15:14:28  <saghul>the reason for uv_buf_t being like that is so that we can cast it to iovec
15:15:28  * mikolalysenkojoined
15:15:37  <saghul>tfogal: I guess if you have a file larges than SIZE_MAX you'll need to use multiple buffers.
15:16:38  <saghul>*larger
15:19:23  <tfogal>saghul: sorry, I guess I'm obtuse today. It appears to be a void* or char* buffer with a size_t length, from my cursory glance at the source. so if one passes a (e.g.) 3Gb buffer with the appropriate size, all should be well, no?
15:19:55  <saghul>tfogal: yep
15:20:22  <tfogal>saghul: soo the problem is how rust is *using* libuv, not a problem in libuv itself?
15:20:45  <tfogal>maybe i should've directed that at eddyb
15:20:52  <eddyb>saghul's affirmative answer would contradict that
15:21:15  <eddyb>*unless* a bug was fixed in the past couple months
15:22:24  <saghul>eddyb: this used to be the function before: https://github.com/joyent/libuv/blob/v0.10/include/uv.h#L1574
15:22:31  <saghul>what was the problem with it?
15:22:59  <saghul>the new one takes a list of buffers instead
15:23:11  <eddyb>the API was fine
15:23:16  <eddyb>saghul: but do the internals work?
15:23:35  <eddyb>did they not work and now they do?
15:24:23  <saghul>https://github.com/joyent/libuv/blob/v0.10/src/unix/fs.c#L482
15:24:34  <tfogal>eddyb: it seems to me like the 'as i32' in rust seems more likely to be the culprit, no?
15:24:37  <saghul>it's basically a single call to write()
15:24:47  <eddyb>tfogal: that's not uv_fs_write but uv_write
15:24:52  <eddyb>tfogal: and it's the number of buffers
15:25:04  <saghul>I don't see how it would fail there
15:25:05  <tfogal>eddyb: aahhh, ahh, okay, my b.
15:26:31  <eddyb>saghul: good enough? https://github.com/joyent/libuv/pull/1214/files
15:26:47  <eddyb>wait, no, that's a hack as well. crap
15:27:03  <eddyb>*sigh* it explains why those two weren't ever upstreamed
15:27:18  <saghul>well, at least we can comment on how to properly fix it
15:27:23  <saghul>no worries :-)
15:27:35  <eddyb>saghul: good thing it's not my patch :D:D
15:27:42  <saghul>heh!
15:32:29  <eddyb>saghul: the function that constructs a buf_t takes uint instead of size_t, maybe that's relevant?
15:32:47  * kevinsimperquit (Remote host closed the connection)
15:33:47  <saghul>eddyb: on windows len is ULONG, not sure if that could be the reason for it
15:35:27  <eddyb>saghul: tfogal has the issue on linux AFAIK
15:42:24  <tfogal>on linux, unsigned int is definitely 4 bytes (even 64bit linux). So this does seem like a problem.. but my grep of rust suggests we aren't actually using uv_buf_init to construct the buffer.
15:42:48  <tfogal>So perhaps a problem, but I'm not sure it's *this* problem.
15:42:58  <tfogal>unless i'm missing something
15:44:47  <saghul>maybe you where assigning the value to buf->len, having the value > SIZE_MAX?
15:49:08  <tfogal>saghul: SIZE_MAX is 18446744073709551615UL on my system. my write is smaller than that...
15:49:54  <saghul>hum, then I have no idea :-/ is there any test case for that?
15:51:18  * mikealjoined
15:52:19  <tfogal>i don't see one, at a quick glance... but I didn't know what libuv was until today ;-). I could probably hack one into test-fs.c, let me give it a shot...
15:53:50  <saghul>kewl :-)
15:55:41  * mikealquit (Ping timeout: 252 seconds)
16:02:29  * andrewrkquit (Ping timeout: 240 seconds)
16:10:59  * dsantiagoquit (Ping timeout: 240 seconds)
16:14:07  <tfogal>saghul: https://gist.github.com/tfogal/9765258. And it does indeed fail, at the 'result == sz' assertion line.
16:14:26  <tfogal>that said, i may have written the test wrong, you tell me :-)
16:15:06  * dap_joined
16:19:42  * kpdeckerjoined
16:23:42  <saghul>tfogal: test looks good
16:23:57  <saghul>I just ran it and it would only write 2147479552 bytes
16:24:11  <tfogal>exactly the size of my file when i hit the bug in rust :-)
16:25:00  <saghul>apparently that's MAX_INT
16:25:15  <tfogal>makes sense, if this is indeed a truncation issue
16:25:39  <saghul>hum
16:25:58  <saghul>"The number of bytes written may be less than count if, for example, there is insufficient space on the underlying physical medium, or the RLIMIT_FSIZE resource limit is encountered"
16:26:59  * bradleymeckjoined
16:27:09  <saghul>or it could have been interrupted
16:27:18  <saghul>aka EINTR
16:27:29  <tfogal>yeah, true
16:27:30  <saghul>we only check for that if r== -1
16:27:53  <tfogal>certainly an EINTR errno should be restarted, but for me it is always the same size
16:27:58  <saghul>not sure if we should take care of it or let the user adjust the offset and retry
16:28:05  <saghul>let me check a thing
16:29:19  * motleyquit (Remote host closed the connection)
16:37:45  <saghul>I suspect write is getting interrupted
16:42:35  <saghul>tfogal: can you pl open an issue for this?
16:47:54  * jmar777quit (Remote host closed the connection)
16:49:08  * thlorenzquit (Remote host closed the connection)
16:51:38  * thlorenzjoined
16:51:53  * mikealjoined
16:52:27  * rmgjoined
16:54:24  * cphooverjoined
16:54:28  * thlorenzquit (Remote host closed the connection)
16:56:11  * mikealquit (Ping timeout: 252 seconds)
16:57:05  * rmgquit (Ping timeout: 246 seconds)
17:00:08  <tfogal>saghul: sure thing
17:00:50  * sblomquit (Read error: Connection reset by peer)
17:03:16  <saghul>thanks!
17:04:52  * sh1mmerjoined
17:07:23  * rosskjoined
17:12:56  * rmgjoined
17:16:16  * sblomjoined
17:20:56  * benviequit (Ping timeout: 252 seconds)
17:22:56  * bajtosquit (Quit: bajtos)
17:24:14  <tfogal>saghul: https://github.com/joyent/libuv/issues/1215
17:25:28  * thlorenzjoined
17:25:58  * dap_quit (Quit: Leaving.)
17:27:05  * seldojoined
17:29:44  * thlorenzquit (Ping timeout: 252 seconds)
17:31:21  * sh1mmerquit (Quit: sh1mmer)
17:31:31  * benviejoined
17:33:52  * AvianFluquit (Remote host closed the connection)
17:34:06  * sh1mmerjoined
17:34:22  * AvianFlujoined
17:35:04  * dap_joined
17:35:24  * sh1mmerquit (Client Quit)
17:35:41  * sh1mmerjoined
17:38:41  * AvianFluquit (Ping timeout: 252 seconds)
17:38:58  * thlorenzjoined
17:40:51  * mikealjoined
17:46:24  * bajtosjoined
17:52:48  <trevnorris>groundwater: ping
17:55:11  <groundwater>trevnorris: ahoy!
17:55:19  * jmar777joined
17:56:08  <trevnorris>groundwater: the only reason I can think of that error happening is somehow a listener is being added during the execution of one of the create/before/after callbacks.
17:56:21  <trevnorris>groundwater: though i'm still not completelly sure how that's possible.
17:56:30  <trevnorris>this bug is really perplexing
17:57:10  <groundwater>trevnorris: do you have some code i can play around with?
17:57:19  <groundwater>i can try hacking on it a bit today
17:57:40  <trevnorris>the one I'm running is test/bind-emitter.tap.js
17:58:04  <trevnorris>groundwater: at the top just change t.plan(12) to t.plan(2) then comment out all but the first two tests.
17:58:07  * Kakeraquit (Ping timeout: 264 seconds)
17:58:07  <groundwater>trevnorris: okay, i'll pull your latest changes and try to debug it a bit today
17:58:19  <groundwater>thanks for hunting this down!
17:59:05  <trevnorris>groundwater: if you process._rawDebug() from the create/before/after callbacks you'll see how many times they execute (when running only one of the two tests)
17:59:23  * jmar777quit (Ping timeout: 246 seconds)
17:59:57  <trevnorris>groundwater: this might have to do w/ the change that each async path is independent, and there're several things queued up in nextTick()
18:00:15  <trevnorris>i don't know. i'll get this stupid thing figured out if it kills me.
18:00:32  <groundwater>trevnorris: i hope it doesn't come to that
18:00:34  <groundwater>=]
18:00:46  <trevnorris>heh, neither do i
18:01:38  <trevnorris>tjfontaine: ping
18:02:01  <trevnorris>tjfontaine: nm.
18:02:40  * rmgquit (Remote host closed the connection)
18:03:27  * jmar777joined
18:06:47  * kevinsimperjoined
18:09:26  * rmgjoined
18:14:36  <groundwater>unrelated to async-listener, but an annoying bug we're experiencing with our own module, can anyone help me figure out why this code path might get executed
18:14:37  <groundwater>https://github.com/joyent/node/blob/v0.10.26/lib/http.js#L1518-L1524
18:14:55  <groundwater>we switched to a custom http agent https://www.npmjs.org/package/yakaa
18:15:43  <groundwater>and we're seeing this error
18:15:43  <groundwater>Error: socket hang up
18:15:43  <groundwater> at createHangUpError (http.js:1472:15)
18:15:43  <groundwater> at CleartextStream.socketCloseListener (http.js:1522:23)
18:15:43  <groundwater> at CleartextStream.EventEmitter.emit (events.js:117:20)
18:15:44  <groundwater> at tls.js:696:10
18:17:00  * AvianFlujoined
18:19:00  <indutny>isaacs: hey man
18:21:30  <tjfontaine>groundwater: nice
18:21:59  <tjfontaine>groundwater: are you catching that error and handling it?
18:22:48  <groundwater>tjfontaine: yes
18:23:36  <groundwater>But it seems to happen a lot
18:24:16  <tjfontaine>_hadError there feels backwards
18:24:28  <tjfontaine>oh I see
18:25:04  <tjfontaine>so this is basically emitting an error *after* close?
18:27:15  <tjfontaine>seems like that req.emit('close') should definitely be happening below that if block
18:30:22  <groundwater>tjfontaine: if this is a bug, I'd be happy to try to generate a repro case, but I don't quite get why it's happening in the first place
18:30:33  * brsonjoined
18:30:52  <groundwater>req.res must be undefined or null
18:33:06  <tjfontaine>this is most likely to be a bug in legacy tls layer, which indutny might be able to help with if you get a repro case
18:33:39  <tjfontaine>however, that code you linked raises another bug -- which is the fact that *I* think the contract from node is that after you see a 'close' you cease to receive further events on that stream
18:34:27  <indutny>hey hey
18:34:38  <indutny>tjfontaine: where are we with v0.12 ?:)
18:35:22  <tjfontaine>indutny: we want to get trevor to squash his commits so we can land that, and then quickly follow up with my commits
18:35:28  <indutny>trevnorris: ?
18:35:54  <tjfontaine>I have been looking at a startup time issue for node -- at least for sunos
18:36:12  <trevnorris>indutny: ? ?
18:36:25  <tjfontaine>node::Init should actually be using uv_hrtime instead of uv_uptime (especially since that's only second precision on darwin and bsd's)
18:36:42  <indutny>trevnorris: ? ? ?
18:36:43  <indutny>:)
18:36:55  <indutny>trevnorris: "<@tjfontaine> indutny: we want to get trevor to squash his commits so we can land that, and then quickly follow up with my commits"
18:37:04  <indutny>this is the only thing left before v0.12
18:37:14  <trevnorris>indutny: yeah. i'm working on it now.
18:37:28  <indutny>ok, thank you :)
18:37:43  <trevnorris>np :)
18:46:02  <trevnorris>indutny: mind upgrading v8 to 3.24.40?
18:46:10  <indutny>heeeeh
18:46:13  <indutny>it is complicated
18:46:18  <indutny>current version is latest
18:46:19  <indutny>I think
18:46:43  <indutny>
18:46:49  <indutny>but we could do it before v0.12
18:46:58  <indutny>trevnorris: ^
18:47:13  <trevnorris>indutny: i don't quite get it. but there is a 3.24.40 tag
18:47:17  <indutny>I know
18:47:22  <indutny>they borked versions
18:47:24  <indutny>and tags
18:47:45  <tjfontaine>they had broken tooling when they tried to branch off 3.25
18:47:52  <indutny>trevnorris: https://github.com/v8/v8/blob/3.24/src/version.cc#L34
18:48:10  <trevnorris>wtf. all I know is I really want mraleph's patch in so we can use irhydra2 in v0.12
18:48:24  <tjfontaine>bbiab, lunch
18:48:31  <indutny>trevnorris: it should work fine
18:48:36  <indutny>isn't it?
18:48:49  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:49:27  * janjongboomjoined
18:50:44  <trevnorris>indutny: we need >= 3.24.39
18:50:50  <trevnorris>and we're at 3.24.35
18:50:54  <indutny>it doesn't contain latest fixes
18:51:04  <indutny>it would be a big pain to patch it later
18:51:11  <indutny>I'd rather backport irhydra changes
18:51:21  <trevnorris>ok, if we can do that then i'm cool.
18:51:33  <trevnorris>well. lunch. be back soon
18:51:37  * trevnorris&
18:52:32  * Kakerajoined
19:09:19  * kpdeckerquit (Quit: Leaving.)
19:10:03  * jmar777quit (Remote host closed the connection)
19:15:17  * mikealquit (Quit: Leaving.)
19:19:12  <MI6>joyent/node: Nathan Rajlich master * 9f23fe1 : http: use defaultAgent.protocol in protocol check - http://git.io/lxdOEg
19:21:54  * tjkrusinskijoined
19:27:09  <indutny>isaacs: what's your PGP pubkey?
19:27:11  <indutny>do you have one?
19:27:29  <indutny>everyone: this is mine, just in case http://pgp.mit.edu/pks/lookup?op=get&search=0xFB0E1095B1797999
19:28:23  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:37:07  * brunklejoined
19:39:24  * roxlujoined
19:41:23  * jmar777joined
19:42:40  <mmalecki>indutny: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xB0A78B0A6C481CF6 :)
19:42:43  * mcavagejoined
19:42:45  <mmalecki>indutny: easy to search it
19:42:50  <indutny>oh, right
19:43:43  <indutny>thanks
19:43:46  <indutny>mmalecki: what's yours?
19:44:19  * bajtosquit (Quit: bajtos)
19:44:29  <mmalecki>indutny: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x78CF7B9FDF57A3D2
19:44:44  <indutny>great :)
19:44:44  <indutny>thanks
19:44:50  <mmalecki>:)
19:56:28  <isaacs>tjfontaine: hey, what's the status on getting npm 1.4.6 in there?
19:56:48  <isaacs>indutny: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xB0A78B0A6C481CF6
19:56:56  <indutny>already done :)
19:56:57  <indutny>thanks man
19:57:02  <isaacs>indutny: np
19:57:13  <indutny>isaacs: wanted to ask you about npm
19:57:17  <isaacs>indutny: or just look at any of my many signed tagged commits :)
19:57:18  <indutny>have you seen my tweets today?
19:57:45  <isaacs>indutny: yeah, signing stuff is on our near-term roadmap
19:57:54  <indutny>oh, goodness!
19:58:01  <indutny>will main npm accept signed packages?
19:58:07  <indutny>from unauthorized users?
19:58:12  <isaacs>indutny: i have a signed offer letter from someone who will be responsible for implementing thi
19:58:15  <isaacs>s
19:58:15  <indutny>or from users publishing on behalf of others?
19:58:21  <isaacs>indutny: it is not fully designed.
19:58:26  <isaacs>indutny: but yes, that would be a nice to have, for sure
19:58:39  <isaacs>indutny: if you sign the package, then presumably, you're ok with it being published, on your behalf
19:58:39  <indutny>that's my main point about it :)
19:58:43  <indutny>yeah
19:58:51  <indutny>I'd like to have a couple of replicas
19:58:57  <isaacs>indutny: and then, you coudl publish to multiple different places
19:58:58  <indutny>and be able to publish stuff to them
19:59:00  <indutny>while npm is down
19:59:04  <isaacs>and we don't need to have a single write-master point of failure, either
19:59:06  <indutny>and they will sync up
19:59:09  <indutny>yeah
19:59:10  <indutny>indeed
19:59:10  <tjfontaine>isaacs: we can upgrade 1.4.x roughly at will -- I am just looking to get notifications before they land and what the change log is
19:59:19  <isaacs>tjfontaine: that's fair
19:59:26  <isaacs>ok, lemme write this url patch for you. one sec
19:59:33  <tjfontaine>thanks
20:00:16  * eddybpart ("Konversation terminated!")
20:04:59  <MI6>joyent/node: Nathan Rajlich master * 69b8279 : doc: remove `agent.request()` call in example - http://git.io/ks6AAA
20:05:25  * AlexisMocha_joined
20:05:40  * brunklequit (Quit: brunkle)
20:05:51  * AlexisMochaquit (Read error: Operation timed out)
20:06:20  * brunklejoined
20:07:42  * mikealjoined
20:08:24  <tjfontaine>indutny: on our inbound tcp connections we do not set nodelay, but we do by default on our outbound connections -- do you think that's a bug?
20:08:40  <tjfontaine>indutny: or at least something we should more clearly document?
20:10:54  <groundwater>trevnorris: https://gist.github.com/groundwater/1450a0d1e92d197cbcd5
20:11:02  <tjfontaine>also uv__time_forward on windows is creepy
20:14:43  * janjongboomjoined
20:19:07  <indutny>tjfontaine: seems to be a bug
20:19:17  <indutny>uv__time__forward? :)
20:19:34  <tjfontaine>it's something weird to do with uv_poll for windows
20:22:06  <tjfontaine>process.uptime is perhaps one of our more useless "features" :)
20:23:44  <indutny>:)
20:24:01  <indutny>sometimes it gives you what you have just expected
20:24:15  <indutny>oh, btw
20:24:29  <indutny>tjfontaine: have you managed to get anywhere with certs for nodejs.org ?
20:24:39  <tjfontaine>the implementation of uv_uptime on sunos is expensive as hell -- so I'm making it use uv_now instead (since that's already monotonic and set at initialization of the loop)
20:24:57  <tjfontaine>indutny: lemme follow up with the guy who does our certs
20:25:03  <indutny>ok, thanks
20:25:12  <indutny>it would be cool to do v0.12 release via https :D
20:25:13  <indutny>haha
20:25:22  <indutny>though, I don't really wish to delay it even more
20:25:23  <indutny>because of this
20:25:31  <tjfontaine>because making sure no one MITMs a tarball download is important?
20:25:44  <indutny>haha
20:25:52  <tjfontaine>tls of course does nothing for these people to ensure that the tarball is actually valid -- can we all agree on that?
20:25:53  <indutny>at least signature
20:25:58  <indutny>on website
20:26:06  <tjfontaine>why does the transport matter for the file
20:26:11  <tjfontaine>the file is signed, that is important
20:26:21  <tjfontaine>how the file is transferred has little to do with the integrity of that signature
20:26:34  <tjfontaine>we need to *not* sell people snakeoil
20:26:46  <indutny>wait
20:26:56  <indutny>what about .tar.gz
20:27:04  <tjfontaine>the tar.gz is nothing wihtout the shasum verification
20:27:06  <indutny>the only way to verify sources is to check their signature
20:27:11  <tjfontaine>and the shasum verification is what is signed
20:27:18  <indutny>ah, I se
20:27:20  <indutny>see
20:27:23  <tjfontaine>https/tls only talks about how you transfer the file, not the disposition of the file itself
20:27:46  <indutny>ok, you are right
20:27:52  <indutny>still I can't see how it'll harm anyone
20:27:53  <othiym23>as long as the shasum is attested, sure, that's fine
20:28:06  <othiym23>but the attestation of the signature is the tricky part
20:28:10  <indutny>indeed
20:28:18  <tjfontaine>keybase.io
20:28:23  <othiym23>especially when you're doing that via an automated agent for packaging or w/e
20:28:24  <indutny>https for all transfers would be just fine
20:28:45  <tjfontaine>https://gist.github.com/tjfontaine/9512993
20:28:51  <tjfontaine>if you want ot verifiy *my* signature
20:28:57  <tjfontaine>and that page is delivered over https
20:28:59  <tjfontaine>but again
20:29:10  <tjfontaine>the data you are verifying is what matters, not how it's transferred to you
20:29:18  * c4milojoined
20:29:32  <othiym23>tjfontaine: sure, no argument there
20:29:33  <indutny>yes, I agree
20:29:59  <othiym23>but the chain of verification has to terminate with a trustworthy source of truth, preferably in a form that's machine-friendly
20:30:00  <indutny>oh, btw
20:30:04  <indutny>do you have an invite to keybase? :)
20:30:05  <othiym23>SSL is a not-bad way to do that
20:30:06  <indutny>may I ask one?
20:30:10  <tjfontaine>indutny: sure, email?
20:30:14  <indutny>fedor@indutny.com
20:30:29  <indutny>thanks
20:30:31  <tjfontaine>sent
20:30:49  <indutny>yep, got it
20:30:50  <indutny>thank you
20:31:36  * SquirrelCZECHquit (Read error: Connection reset by peer)
20:32:09  <roxlu>indutny: talking about SSL :) have you ever created your own bio_method_st struct to handle read/writes ?
20:32:16  <indutny>yes
20:32:20  <indutny>we have one in node v0.11
20:32:26  <tjfontaine>https://gist.github.com/tjfontaine/9770725
20:32:45  <tjfontaine>on the plus side you actually get subsecond precision ...
20:32:47  <roxlu>oh aweome :) maybe you can help me understand it a bit :# I can't find any documentation on it.
20:33:16  * roxluwon't interrupt tjfontaine ^.^
20:33:34  <tjfontaine>it's ok
20:33:36  <indutny>hm...
20:33:37  <roxlu>thanks
20:33:41  <indutny>tjfontaine: I wonder if there are any caveats
20:33:51  * andrewrkjoined
20:33:54  <tjfontaine>it's now a float instead of an integer (casting is easy)
20:34:01  <tjfontaine>that's only used for process.uptime()
20:34:16  <indutny>I mean replacing uv_uptime
20:34:19  <indutny>with uv_now()
20:34:45  <tjfontaine>there is one difference, and that's the fact that on linux uptime uses BOOTTIME as opposed to MONOTONIC
20:34:50  <tjfontaine>(if available)
20:34:59  <roxlu>indutny: I want to handle my own buffers with openssl. I want to use a bio_method_st as tit seems like a cleaner solution than memory bios. I'm only wondering how to handle the handshake as some parts don't need to encrypt data and some do.
20:35:03  <tjfontaine>so the value is different if you are suspending in the meantime
20:35:21  <indutny>roxlu: just give a try to our thing :)
20:35:25  <tjfontaine>-- but who is using node in a desktop application taht's trying to use process.uptime as opposed to os.uptime
20:35:26  <indutny>you'll figure out most of it soon
20:35:54  <tjfontaine>on the other hand, node initialization process is always doing this extra syscall to get the current time -- when the loop already has it
20:35:56  <roxlu>indutny: in what file is it used?
20:36:55  <indutny>node_cryptio_bio.cc
20:37:00  <indutny>and used in tls_wrap.cc
20:37:05  <indutny>tjfontaine: hm...
20:37:32  <indutny>tjfontaine: does uv_uptime() account suspended time?
20:37:45  <roxlu>thanks indutny
20:38:24  <tjfontaine>indutny: depends on the platform, on linux > 2.6.39 and if available -- yes it does account for suspended time
20:38:33  * SquirrelCZECHjoined
20:38:51  <indutny>ok, I guess I object this patch then :P
20:38:58  <tjfontaine>it's really unclear though who is using process.uptime() to reflect that information as well, it's meant to track the process's uptime not the system
20:39:01  <tjfontaine>os.uptime is unchanged
20:39:24  <indutny>oh
20:39:27  <indutny>hm...
20:39:34  <tjfontaine>uv_uptime is still used for os.uptime
20:39:37  <indutny>I guess this is mostly using for monitoring purposes
20:39:43  <indutny>I mean
20:39:46  <tjfontaine>this is just to avoid yet another series of syscalls during process startup
20:39:47  <indutny>used by people
20:39:55  <indutny>ok, if you are confident with it
20:39:58  <indutny>perhaps it is worth it
20:40:11  <roxlu>indutny: damn, where did you find all info about how to use openSSL like this?
20:40:21  <tjfontaine>I am goign to get some dtrace to show what's up with it -- but it's a pretty easy win for everyone on startup
20:40:22  <indutny>roxlu: from BIO_s_mem sources
20:40:35  <roxlu>hehe : )
20:40:45  <roxlu>so basically reverse engineere
20:40:47  <roxlu>+d
20:40:50  <indutny>tjfontaine: how would you import pgp key into keybase?
20:41:07  <tjfontaine>I only did pubkey not privkey fwiw
20:41:11  <tjfontaine>they have an example listed there
20:41:23  <indutny>ok, I'll figure out
20:41:23  <indutny>thanks
20:41:32  <indutny>s/pgp/gpg/ :)
20:42:55  <roxlu>indutny: If I'm correct, the client sends a "Client Hello" to kick off the handshake for TLS. The server then needs to send back the ciphers/certificate and server done right?
20:44:26  * emeryquit (Read error: Connection reset by peer)
20:44:30  <indutny>almost
20:44:35  <indutny>there is one additional hop
20:45:32  * tjkrusinskiquit (Ping timeout: 252 seconds)
20:46:31  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:47:22  <roxlu>ah I see, so after the server sends back "ServerHello, Certificate, ServerHelloDone", the client sends "ClientKeyExchange, ChangeCipherSpec, Finishes" .. then again the server: "ChangeCipherSpec,Finished"
20:47:23  * AvianFluquit (Remote host closed the connection)
20:47:48  * mcavagequit (Remote host closed the connection)
20:47:51  <mmalecki>tjfontaine: as to process.uptime(), I use it for monitoring purposes, it's pretty useful
20:47:52  * AvianFlujoined
20:48:25  * mcavagejoined
20:50:20  <indutny>roxlu: yes
20:50:22  <indutny>exactly :)
20:50:52  <roxlu>I thought that openssl would handle all that stuff
20:51:37  <indutny>it would
20:51:51  <indutny>it is just using buffer
20:52:00  <indutny>to let you write all this stuff to the socket
20:52:43  * AvianFluquit (Ping timeout: 264 seconds)
21:00:04  * SquirrelCZECHquit (Read error: Connection reset by peer)
21:06:16  * trevnorrisfg
21:14:42  * mikealquit (Quit: Leaving.)
21:15:33  * mikealjoined
21:16:23  <roxlu>indutny: I've privmsg you
21:16:47  * mikolalysenkoquit (Ping timeout: 246 seconds)
21:17:23  * mikealquit (Client Quit)
21:17:32  * mikealjoined
21:18:09  <tjfontaine>mmalecki: yes I get the purpose of process.uptime, I do not get the purpose of using BOOTTIME for that
21:18:18  <tjfontaine>mmalecki: which is what my change influences
21:18:44  * mikealquit (Client Quit)
21:18:51  <tjfontaine>mmalecki: in practice monotonic generally does reflect boottime as well -- the caveat being if you're in an environment where you're allowing the machine to suspend
21:19:43  <mmalecki>tjfontaine: right, but at the point of machine becoming inaccessible (i.e. ceasing to report) I just shoot it in the head, so that's not a problem for me
21:19:55  <mmalecki>tjfontaine: but I understand your concern
21:20:10  * brunklequit (Quit: brunkle)
21:20:24  <tjfontaine>I'm goign to dtrace how long it takes for node to run Init() today in v0.10, and how long it takes after my change
21:20:37  <tjfontaine>if bcantrill was right, it should be reasonably dramatic
21:20:49  <mmalecki>tjfontaine: link me to your commit?
21:20:57  <tjfontaine>and I am the last person to question bryan
21:20:58  <tjfontaine>https://gist.github.com/tjfontaine/9770725
21:21:25  <mmalecki>heh, lower level would be emailing it to me ;)
21:21:49  <tjfontaine>curl https://gist.githubusercontent.com/tjfontaine/9770725/raw/61c4ec1d525c8a76b9ee58375fc2e1b72946a524/node-init.diff | git apply
21:21:52  <tjfontaine>:P
21:23:18  * mikealjoined
21:25:06  <mmalecki>tjfontaine: curious as to what you come up with in benchmarks
21:25:18  <mmalecki>tjfontaine: might be OS-dependant too
21:25:45  <tjfontaine>it is certainly os dependent, but at the very least *every* os is saving at least one syscall on node init
21:25:59  * TooTallNatejoined
21:26:08  <mmalecki>tjfontaine: heh, I can save you 2 on node init right now
21:26:22  <mmalecki>(if this code is still there, let me see)
21:27:03  <mmalecki>well, one: https://github.com/joyent/node/blob/master/lib/module.js#L511
21:27:22  <tjfontaine>ya well that's a different story :)
21:27:28  <mmalecki>ya :)
21:27:38  <mmalecki>but yeah, please bench this
21:27:56  <mmalecki>I'm still curious about the amount of gettimeofday calls node makes
21:28:03  <tjfontaine>working on it, because of the way it works I am adding some static probes to existing node-v0.10
21:28:15  <tjfontaine>mmalecki: most of that is fixed in v0.11 (with hrtimes instead) ;)
21:28:47  * bradleymeckquit (Quit: bradleymeck)
21:28:59  <mmalecki>sweet :)
21:29:13  <tjfontaine>gettimeofday for timers is completely broken
21:29:21  <tjfontaine>hasn't anyone heard of ntp?
21:29:42  <mmalecki>I find google's solution for that neat
21:31:27  * bradleymeckjoined
21:31:34  * brunklejoined
21:32:50  <tjfontaine>https://gist.github.com/tjfontaine/9771851
21:32:55  <tjfontaine>existing node v0.10 on sunos
21:32:57  * SquirrelCZECHjoined
21:33:11  <tjfontaine>that's with an sdt probe around Init();
21:33:20  <tjfontaine>now I will apply my change
21:34:22  * SquirrelCZECHquit (Read error: Connection reset by peer)
21:34:51  <tjfontaine>mmalecki: https://gist.github.com/tjfontaine/9771851 updated, only one outlier -- in nanoseconds
21:35:22  * SquirrelCZECHjoined
21:35:58  <mmalecki>google esentially skewes their clock on purpose to avoid worse clock skewing
21:36:04  <mmalecki>can't find a paper on that now tho
21:38:30  <mmalecki>tjfontaine: holy crap, nice gain!
21:38:36  * janjongboomjoined
21:39:06  <mmalecki>janjongboom: still alive, it's been 8 h here
21:39:17  <janjongboom>mmalecki: lol
21:39:21  <tjfontaine>mmalecki: yup -- this is a considerable improvement for speed of light jobs
21:39:46  <mmalecki>tjfontaine: want me to optimize that silly double getenv() btw?
21:39:59  * emeryjoined
21:40:19  <tjfontaine>mmalecki: certainly, easy win there as well
21:40:35  <tjfontaine>indutny: did you see that gist above?
21:40:55  <mmalecki>ah, `git pull` over middle-of-nowhere-internet
21:41:48  * tjkrusinskijoined
21:44:30  <trevnorris>tjfontaine: had lunch w/ eran. he's going to start testing AL. the case where they're removed in the middle of an execution chain is one of the features he needs
21:44:43  <trevnorris>and has been trying to emulate w/ domains, but said it's a pain to get correct.
21:46:12  <trevnorris>groundwater: yeah. i got there too. problem i'm having is trying to figure out how the AL is added in such a way that's allowing the after to run
21:46:35  * tjkrusinskiquit (Ping timeout: 252 seconds)
21:46:44  <groundwater>trevnorris: i think it's a new AL every time createNamespace is called
21:47:17  <groundwater>so i don't think it's a problem related to re-using ALs
21:47:28  <tjfontaine>you can begin testing it -- but it's not something that's going to make it as a first class feature in 0.12
21:48:06  <trevnorris>groundwater: so, it must be adding an AL to the same "async context" in the middle of being executed.
21:48:40  <groundwater>https://gist.github.com/groundwater/1450a0d1e92d197cbcd5#file-context-js-L153-L177
21:48:57  <groundwater>that should be a fresh AL
21:49:14  <trevnorris>tjfontaine: is any of tracing going to make it in the initial 0.12 release?
21:49:22  <tjfontaine>not as a public api -- no
21:49:26  <tjfontaine>that was the grand compromise
21:49:36  <groundwater>i mean, that's fine by me, i can still consume the private API
21:49:45  <groundwater>not like i don't talk to ya'll daily
21:50:09  <tjfontaine>lib/tracing.js in my commits was removed -- in favor of hiding things behind process.binding()
21:50:21  <tjfontaine>all of lib/tracing.js was put into joyent/node-tracing
21:51:01  <trevnorris>groundwater: yeah, that is a fresh AL. it's not a problem with AL reuse. it's a problem of creating and adding a new AL to the same activeContext in the middle of evaluating the callbacks.
21:51:32  <tjfontaine>this includes v8 and user defined tracing
21:52:14  <groundwater>trevnorris: okay, do you need some more tests from me, or do you have an idea?
21:52:33  <groundwater>i gotta go back to hunting ClearTextStream problems
21:52:37  * cphooverquit (Quit: Leaving.)
21:54:07  <trevnorris>groundwater: yeah. see, previously I did a bunch of work around making it possible to add/remove AL in the middle of resolving a before/after, but that lead to edge cases hard to resolve. looks like this issue has to do w/ that
21:57:53  * thlorenzquit (Remote host closed the connection)
21:58:28  * thlorenzjoined
22:03:05  * thlorenzquit (Ping timeout: 252 seconds)
22:04:52  * jmar777quit (Remote host closed the connection)
22:08:51  * jmar777joined
22:11:25  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
22:14:05  * WalrusPony1changed nick to WalrusPony
22:15:05  * dsantiagojoined
22:19:02  * AvianFlujoined
22:33:47  * mikealquit (Quit: Leaving.)
22:34:44  * mikealjoined
22:40:31  <othiym23>Domenic_: troll
22:40:45  <Domenic_>othiym23: so excited
22:41:02  <Domenic_>weak maps are gonna be good times
22:41:50  <othiym23>I have a baaaad feeling about this, but the V8 team's gonna do what they're gonna do
22:42:41  <othiym23>Domenic_: do you know what version of V8 those changes are going to be incorporated in / have been incorporated in?
22:44:57  <Domenic_>3.25.24
22:45:17  <othiym23>Domenic_: ah, then it's not going to be in Node 0.12 unless something magical happens
22:45:32  <Domenic_>oh node is lagging v8 again? :(
22:45:34  <othiym23>0.12's shipping with 3.24.35 or 3.24.40
22:45:47  <Domenic_>ughh
22:45:48  <othiym23>3.25 is the unstable line of development, no?
22:45:58  <Domenic_>oh i don't know
22:46:03  <Domenic_>does v8 use even-odd too?
22:46:07  <othiym23>yeah, I think so
22:46:21  <othiym23>indutny or trevnorris know for sure
22:48:47  <Domenic_>sigh
22:49:05  <Domenic_>i guess i can hope for a v8 upgrade in the 0.12 timeframe...
22:49:29  <othiym23>c'mon, dude, that's a terribad idea
22:49:48  <othiym23>having the language semantics change in the middle of a stable release series just seems nuts to me, operationally speaking
22:56:35  * bradleymeckquit (Quit: bradleymeck)
22:58:47  <Domenic_>additive changes seem fine to me
22:59:01  <othiym23>new globals, though?
22:59:14  <Domenic_>sure, what's the problem
22:59:21  <Domenic_>we already did that with typed arrays
22:59:38  <tjfontaine>3.25 is development branch -- node never tracks that
22:59:39  <tjfontaine>never will
22:59:41  <Domenic_>Object.is, Math.etcetcetc
22:59:47  <tjfontaine>getting ahead of TypedArrays was a mistake
23:03:25  <tjfontaine>mmalecki: I've updated the gist to include further probes to be able to track time to "javascript" i.e. ready
23:03:51  <tjfontaine>mmalecki: in the grand scheme of things Init() itself is pretty much noise once v8 starts warming up
23:04:55  <tjfontaine>mmalecki: in general we are still coming in between 8 and 16 ms of ready time
23:08:49  <mmalecki>tjfontaine: https://github.com/joyent/node/pull/7357 btw
23:08:56  <tjfontaine>thanks
23:08:58  <mmalecki>tjfontaine: sweet, looking
23:09:03  <mmalecki>been on a beer run
23:09:17  <mmalecki>it's surprisingly hard to explain what chocolate is to thai people
23:10:23  <othiym23>"food white people eat when they're sad"
23:10:51  <mmalecki>hey, I'm not sad!
23:11:10  <mmalecki>welp, who am I kidding. wouldn't be buying beer and chocolate otherwise
23:11:40  <trevnorris>groundwater: just fixed the issue where you couldn't console.log or whatnot from inside a before/after/create callback
23:11:52  <trevnorris>can't believe I didn't see it before.
23:14:33  * benviequit (Ping timeout: 252 seconds)
23:15:28  * bradleymeckjoined
23:16:43  <bradleymeck>tjfontaine any idea what to do when needing to require outside the archive with bundler? @see grunt
23:17:18  <bradleymeck>we originally talked about limiting archives to only require inside themselves
23:17:33  <tjfontaine>bradleymeck: can you be more specific?
23:18:01  <tjfontaine>bradleymeck: there are basically two things modules should be doing -- require() or require.createResourceStream()
23:18:18  <bradleymeck>grunt and a few other tools use require to load tasks ala makefiles
23:18:36  <tjfontaine>and they're using full path to require?
23:18:51  <tjfontaine>require full path can continue to work, but relative paths must be local to archive
23:19:21  <bradleymeck>full path based on cwd. we can do the full vs relative
23:19:28  <mmalecki>tjfontaine: btw, the jenkins bot is yours? it keeps telling me that I didn't sign CLA
23:19:30  <isaacs>tjfontaine: emailed patch re url stuff
23:19:35  <trevnorris>tjfontaine: ok, wait. so tracing will be external or hidden?
23:19:37  <tjfontaine>mmalecki: google docs hates me
23:19:51  <bradleymeck>we also have readResourseSync
23:20:05  <mmalecki>tjfontaine: heh, how so?
23:20:09  <tjfontaine>trevnorris: tracing will not be included in 0.12, require('tracing') will fail unless they've added tracing as dependency
23:20:23  <tjfontaine>mmalecki: it works out of band, but in context of github push it's failing -- so it's wtfy
23:20:32  <mmalecki>tjfontaine: lots of stuff fails due to ł in my name btw
23:20:33  <trevnorris>tjfontaine: now do you mean in 0.12.x or juts the initial 0.12 release?
23:20:40  <tjfontaine>forever of 0.12
23:20:58  <tjfontaine>so we can iterate on the public api and understand the features better
23:21:15  <tjfontaine>once we have the public tracing module understood, we can then include it back into core
23:21:25  <trevnorris>i feel like the idea of "experimental" api is sort of lost.
23:21:33  <trevnorris>it's like, introduce API and API is locked
23:21:44  <mmalecki>trevnorris++
23:21:56  <tjfontaine>which is absolutely why core is not going to be including AL as public api for 0.12 (or v8 or user defined tracing)
23:21:58  <mmalecki>^ why I'm opposed to introducing new modules to API
23:22:26  <tjfontaine>because we have no idea who, what, or how people will use this
23:22:29  * cphooverjoined
23:22:40  <tjfontaine>we know what NR originally asked for, and we know something about what we have today
23:22:47  <tjfontaine>it's unclear if we've met the goals for anyone
23:22:53  <trevnorris>but that's what i'm saying. why do we rank any of our API's as anything but at least stable if once we introduce them we basically force backwards compatibility from that day forward
23:22:58  <mmalecki>tjfontaine: also, what's the email I signed up with? this commit is me@mmalecki.com, I have a feeling that I might've signed up with a different one
23:22:58  <tjfontaine>the grand compromise from the summit was to just punt on the whole thing
23:23:39  <tjfontaine>I'm not sure what the conversation you're trying to have is right now
23:24:07  <trevnorris>just that putting "1 - Experimental" on an API page is useless
23:24:22  <tjfontaine>yes -- which is why it was a mistake, because we couldn't live up to anything for it
23:24:23  <trevnorris>because the point of "Experimental" is that it may change at any time
23:24:28  <tjfontaine>the problem for AL is much harder than that
23:24:55  <tjfontaine>the feature creep of the ask has been so great -- it's beyond experimental, so far as to be "I don't know what this thing is for"
23:25:00  <tjfontaine>is it for transactional tracing
23:25:02  <tjfontaine>is it for error handling
23:25:03  * benviejoined
23:25:05  <tjfontaine>can it do either
23:25:38  <tjfontaine>in the meantime a year has passed since 0.10
23:25:38  <trevnorris>honestly I don't think so. speaking w/ eran today his ask is for all the features that NR had no use for
23:26:00  <tjfontaine>this is part of the problem, that's not the way features can be added into node
23:26:01  <trevnorris>the only feature in there right now that no one has asked for is the ability to filter callbacks based on provider
23:26:14  <trevnorris>but it could be for NR?
23:26:15  <tjfontaine>we need to work as a team on what a feature means, define its scope, figure out the milestones we want to achieve
23:26:37  <tjfontaine>the filtering providers was an ask because the assumption for why it wasn't working for NR was the sheer influx of callbacks happening
23:26:40  <trevnorris>i'm sorry that I didn't well define this from day one, but it has been well defined from the first day I started working on it
23:26:41  <othiym23>tjfontaine: cosigned
23:26:46  <tjfontaine>without any qualitative analysis about that
23:26:58  <tjfontaine>because we missed working in lockstep with NR on making sure we were meeting the feature request
23:27:01  <trevnorris>except for the provider thing, which I introduced after your thing with probes
23:27:25  <tjfontaine>I'm not trying to lay blame, I'm trying to identify where we are today, and how we can fix things going forward
23:27:41  <tjfontaine>part of the summit was to come to a compromise about how we can all work towards gettting 0.12 out
23:28:05  <tjfontaine>the last two major features were AL and tracing, the compromise was to not include either as public api, and iterate on that separate to core
23:28:08  <trevnorris>ok, just for the record all the "features" that AL has were part of my initial plan the day I started working on this. except for providers.
23:28:31  <tjfontaine>noted, but we're beyond that now though
23:28:53  <tjfontaine>we need to get to feature freeze, and burn through the last remaining regressions, so we can start working on 0.12+
23:29:13  <tjfontaine>wherein we can crisply identify the features we want to see included in that release
23:30:06  * kevinsimperquit (Remote host closed the connection)
23:33:55  <trevnorris>tjfontaine: does this include reverting the process.AL api ?
23:34:09  <tjfontaine>have you looked at al-external?
23:34:55  <trevnorris>no. i've been nose down trying to clean up AL commits
23:35:41  <trevnorris>is it a pr?
23:36:21  <tjfontaine>no because it depends on your work, but https://github.com/tjfontaine/node/compare/al-external is that, the removal commit is https://github.com/tjfontaine/node/commit/11e6e61324441aea8647cdf8ef3200df1692aabc
23:39:52  <trevnorris>tjfontaine: what's up w/ the addition of AsyncWrap::Call() and the check if Undefined?
23:40:21  <tjfontaine>because the JS portions won't be there when the process starts up
23:40:55  <tjfontaine>those will only be there if someone has exercised process.binding('async_listener') path
23:41:03  <trevnorris>yeah, so the Environment will have set all the flags to 0, which will evaluate to false. did you run into a case where that happened?
23:41:10  <trevnorris>ok
23:41:36  <tjfontaine>no, but defense in depth, they're all inlined and relatively cheap checks compared to how v8 stores those
23:42:12  * c4miloquit (Remote host closed the connection)
23:42:26  <trevnorris>tjfontaine: one last request. if we're not going to upgrade past v8, I want to backport mraleph's patches so we can use node w/ irhydra2
23:42:50  <tjfontaine>we may do that, but I'm not sure that will land for 0.12 -- ideally we want to be as clean as possible
23:43:03  <tjfontaine>if we can convince v8 to backport it, then that'd be great
23:43:34  <trevnorris>i'm still confused why there's a 3.24.40 and such tags, but they're not on the 3.24 branch
23:43:40  <trevnorris>the comment indutny pointed out didn't make sense
23:43:41  <trevnorris>to me
23:43:49  <tjfontaine>because their release tooling was broken when they were trying to branch off 3.25
23:44:20  <trevnorris>ok, so why does that prevent us from upgrading to the next 3.24 release?
23:44:48  <tjfontaine>nothing prevents us from upgrading to the next release, they're only in their minors though 3.24.40 doesn't exist
23:45:27  <trevnorris>sorry, "they're only in their minors" ?
23:46:25  <tjfontaine>3.24.x is locked, we the minor rev is 24, so only new releases will be patches, and of those they're at .35
23:47:22  <tjfontaine>the most recent commit on the 3.24 branch as an example
23:47:23  <tjfontaine>https://github.com/v8/v8/commit/078f32a20d37d3fecb2910c0b64d59ac7dc6884f
23:47:39  <tjfontaine>the build number is 35, that won't be changing in the future
23:47:45  <tjfontaine>only their patch level will
23:48:02  <tjfontaine>so 3.24.35 is the version that node v0.12 will be releasing with
23:49:07  <tjfontaine>the fact that a tag for 3.24.40 exists, is related teh fact that their tooling was broken whent hey branched off 3.25 development
23:50:32  <trevnorris>so you're saying that 3.24.40 was actually supposed to be on the 3.25 branch?
23:50:56  <tjfontaine>yes
23:51:32  <trevnorris>damn it. leaving out slava's irhydra patch is a huge hit for doing analysis on node. i'd like it there for the initial v0.12 release.
23:52:45  <tjfontaine>well, analysis of javascript performance, most peoples applications are not cpu bound or stuck in the hell of the jit optimizing
23:52:50  <tjfontaine>more often they're blocked on IO
23:53:02  <tjfontaine>which is why node is so powerful
23:53:34  <othiym23>having IRHydra available is invaluable when you run into a situation where it's necessary
23:53:44  <trevnorris>you'd be surprised. i'm starting to see a lot of enterprise uses that are CPU bound because of the time taken for template rendering
23:54:15  <bradleymeck>tjfontaine im going to assume 0.12+ release wont be quite as long as this one
23:54:30  <tjfontaine>bradleymeck: no, because we'll actually know what it is we actually want to do in it
23:54:50  <tjfontaine>so we can know it's actually ready to branch and shi
23:54:50  <tjfontaine>p
23:55:37  <trevnorris>should have just left off the p. could have gone either way ;)
23:55:59  <tjfontaine>irhydra still requires people to run node in a different disposition to get something valuable out of it -- for enterprise companies that are complaining about a node restart effecting uptime -- seems like they want a different tool that can do this analysis in production
23:56:28  <trevnorris>oh, btw. I have moz work week next week. which means meetings 8 hours a day for the entire week. i'm hoping most of them will still allow me to work and not involve me much
23:56:50  <tjfontaine>regarding brendan being your new boss?
23:57:07  <trevnorris>hehe. still am surprised he got ceo. but it's cool.
23:57:21  <trevnorris>no. each team has a work week twice a year where everyone flies in to meet in person
23:57:33  <trevnorris>and have meetings about what'll be happening for the next 6 months
23:57:34  <tjfontaine>oh all hands
23:57:38  <trevnorris>yeah. that
23:59:04  * jmar777quit (Remote host closed the connection)
23:59:05  <trevnorris>tjfontaine: when I did some work at <undisclosed large enterprise> their issue w/ template rendering times was huge, and it was the actual code path that was the issue. independent whether it was running in production
23:59:31  <tjfontaine>sure, and they were also a very specialized case for how they were wanting to achieve it