00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:44  * mikolalysenkoquit (Ping timeout: 255 seconds)
00:07:10  * loladiroquit (Quit: loladiro)
00:08:08  * loladirojoined
00:14:05  * icarotjoined
00:30:19  * perezdjoined
00:32:23  * defunctzombiechanged nick to defunctzombie_zz
00:37:38  * loladiroquit (Quit: loladiro)
00:41:49  * brsonjoined
00:45:59  * amartensjoined
00:56:47  * kellabytejoined
00:58:30  * loladirojoined
01:06:00  * defunctzombie_zzchanged nick to defunctzombie
01:06:48  * icarotquit (Remote host closed the connection)
01:07:29  * mikolalysenkojoined
01:12:05  * mikolalysenkoquit (Ping timeout: 246 seconds)
01:28:24  * abraxasjoined
01:39:11  * perezdquit (Quit: perezd)
01:41:39  * c4milojoined
01:50:39  * icarotjoined
01:51:09  * trapitojoined
01:51:32  <trapito>Ahoy!
02:10:40  * brsonquit (Ping timeout: 256 seconds)
02:11:27  * amartensquit (Quit: Leaving.)
02:14:50  * TooTallNatejoined
02:16:34  * perezdjoined
02:22:15  * defunctzombiechanged nick to defunctzombie_zz
02:24:21  * mikealjoined
02:24:30  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:34:58  * groundwaterjoined
02:41:48  * amartensjoined
02:43:55  * mikolalysenkojoined
02:50:04  * amartensquit (Ping timeout: 246 seconds)
03:00:17  * icarotquit (Ping timeout: 248 seconds)
03:06:28  * timoxleyjoined
03:09:32  * dapquit (Read error: Connection reset by peer)
03:10:06  * dapjoined
03:21:24  * perezdquit (Quit: perezd)
03:34:19  * dapquit (Quit: Leaving.)
03:46:22  * amartensjoined
03:50:57  * amartensquit (Ping timeout: 248 seconds)
04:02:34  * defunctzombie_zzchanged nick to defunctzombie
04:05:22  * timoxleyquit (Quit: Computer has gone to sleep.)
04:29:16  * defunctzombiechanged nick to defunctzombie_zz
04:36:55  * c4miloquit (Remote host closed the connection)
04:46:43  * amartensjoined
04:51:11  * amartensquit (Ping timeout: 246 seconds)
04:57:15  * amartensjoined
04:58:55  * arlolrajoined
05:04:19  * timoxleyjoined
05:16:46  * icarotjoined
05:22:18  * arlolraquit (Quit: Leaving...)
05:29:55  * icarotquit (Ping timeout: 264 seconds)
05:37:07  * mikolalysenkoquit (Ping timeout: 264 seconds)
06:04:51  * loladiroquit (Quit: loladiro)
06:14:45  * mikealquit (Quit: Leaving.)
06:15:30  * mikealjoined
06:43:03  * mikolalysenkojoined
06:47:38  * mikolalysenkoquit (Ping timeout: 255 seconds)
07:07:28  * hzjoined
07:14:06  * bajtosjoined
07:25:15  * `3Echanged nick to `3rdEden
07:43:16  * rendarjoined
08:02:50  * amartensquit (Quit: Leaving.)
08:13:16  * timoxleyquit (Quit: Computer has gone to sleep.)
08:17:24  * bnoordhuisjoined
08:19:07  <bnoordhuis>morning
08:21:07  <bajtos>bnoordhuis: good morning
08:21:33  <bajtos>have you had a chance to look at node pr 5713?
08:22:07  <bnoordhuis>bajtos: chance? yes. done so. no
08:22:23  * trapitoquit (Remote host closed the connection)
08:22:26  <bnoordhuis>bajtos: can you give me the executive summary?
08:22:30  <bajtos>sure
08:22:52  <bajtos>SetVerbose does two things - reports uncaught exception to debugger and logs a message
08:23:21  <bajtos>to log a message, V8 calls embedder's callback or prints to stdout if there is no callback registeed
08:23:47  <bajtos>*registered
08:24:08  <bajtos>node does not register any callbacks
08:24:38  <bajtos>so my dilemma is how to approach this
08:25:29  <bajtos>I can ignore all messages from V8, since it seems like there are only two kinds of them: uncaught exception and syntax error in debug-debugger.js, mirror-debugger.js & friends
08:26:10  <bajtos>or I can rewrite node.js exception handling so that uncaught exceptions are logged via OnMessage callback
08:27:00  <bnoordhuis>OnMessage?
08:27:04  <bajtos>or I can modify V8 to allow OnMessage callback to detect what kind of message it is and throw away "uncaught_exception" message
08:27:13  <bnoordhuis>do you mean the listener that you add with V8::AddMessageListener?
08:27:23  <bajtos>yes
08:27:46  <bajtos>I implemented the third option in commit 84f19c50
08:28:28  <bajtos>I don't now how likely is V8 to accept this change
08:29:37  <bajtos>plus I am little bit worried that we might miss a case where the exception is logged via ReportException, in which case it won't be logged at all
08:30:24  <bajtos>I am leaning towards rewriting node.js exception handling, but that might break backwards compatibility in the sense that a different output will be reported
08:30:49  <bnoordhuis>yeah. that's not ideal
08:31:38  <bajtos>But then… is it necessary to have so many different code paths for reporting exception?
08:32:17  <bajtos>There is ReportException() with show_line true/false, then there is FatalException()
08:32:29  <bnoordhuis>you can pretty much ignore ReportException
08:32:49  <bnoordhuis>it's only used for what amounts to fatal errors
08:33:08  <bnoordhuis>same for FatalException obviously :)
08:33:17  <bajtos>that's the thing which puzzles me :-)
08:33:32  <bnoordhuis>FatalException is an api function that calls ReportException (which is internal)
08:34:09  <bajtos>ouch.
08:34:40  <bajtos>So reporting uncaught exceptions from V8::AddMessageListener callback will also break API compatibility
08:34:49  * timoxleyjoined
08:35:18  <bajtos>since users should use TryCatch.SetVerbose(true) instead of calling FatalException(TryCatch)
08:36:51  <bajtos>However. If native modules want to support "break on uncaught exception", then they have to call SetVerbose anyway
08:37:32  <bnoordhuis>*affirmative nod*
08:41:13  <bajtos>how about this solution? https://gist.github.com/bajtos/9ba2ebfd44ec7232ea75
08:43:32  <bnoordhuis>bajtos: i really, really don't want to expand the c++ api
08:43:40  <bnoordhuis>if anything, i want it to get smaller over time
08:44:02  <bnoordhuis>documenting the SetVerbose thing in addons.markdown is fine however
08:44:44  <bajtos>in that case if you use both SetVerbose and FatalException, your exception will be logged twice
08:45:07  <bajtos>if that's an acceptable price to pay for smaller API, then ok
08:47:33  <bnoordhuis>bajtos: if TryCatch had a IsVerbose() method, you could avoid that, right?
08:47:48  <bajtos>you know what? if native module authors were using NodeTryCatch already, then we won't have to think so hard about backward compatibility - we could simple change implementation (internals) and all modules will work without change. having our own API objects instead of exposing V8 API has some benefits.
08:47:57  <bajtos>bnoordhuis: I am not sure
08:48:17  <bajtos>bnoordhuis: since TryCatch is converted to a Message before it is sent to our handler
08:48:52  <bnoordhuis>handler? i was talking about FatalException
08:49:02  <bajtos>oh, I see your point
08:49:09  <bajtos>yeah, that's a good idea
08:50:51  <bajtos>adding IsVerbose() should be simple enough to have it accepted to V8 or added to our patch we are applying to V8
08:53:09  <bnoordhuis>bajtos: upstream always!
08:53:19  <bnoordhuis>if v8 rejects it, i probably will too
08:53:38  <bajtos>hmm, ok
08:53:55  <bajtos>I found one more problem
08:55:29  <bajtos>I am not sure I we can call "_fatalException" event handler from AddMessageListener callback(), most likely we will have to do it in FatalException
08:56:09  <bajtos>in which case we will report exception even if "_fatalException" handler returned true :(
08:58:27  <bnoordhuis>i think that should be safe
08:58:29  <bnoordhuis>but let me check
09:00:42  <bnoordhuis>yeah, looks like it should be okay
09:01:31  <bajtos>cool.
09:01:46  <bnoordhuis>amusingly, any exceptions your listener throws, v8 stops from propagating :)
09:01:47  <bajtos>except we can't access TryCatch from AddMessageListener
09:02:20  <bajtos>I am taking it back
09:02:51  <bajtos>we need to access TryCatch from FatalException() which is called *after* AddMessageListener callback, so that should be fine
09:02:59  <bajtos>one more question
09:03:05  <bnoordhuis>one more answer
09:03:07  <bajtos>:)
09:03:09  * amartensjoined
09:03:36  <bajtos>from what I was able to find, ReportException() is called directly from Load(process_l)
09:04:19  <bajtos>is there a reason why this code cannot call FatalException instead? (i.e. why it is bypassing "_fatalException" handler)
09:04:42  <bnoordhuis>because there's no going forward when Load() fails
09:05:13  <bnoordhuis>FatalException is (since v0.10) only conditionally fatal
09:05:43  <bajtos>ok, that makes sense
09:06:04  <bnoordhuis>there's also the chicken/egg problemn: if Load() fails, the process object is probably in an undefined state
09:06:09  <bajtos>do I understand it correctly, that FatalException is basically a wrapper around ReportException that adds
09:06:16  <bajtos>"_fatalException" handler logic
09:06:23  <bajtos>?
09:06:31  <bnoordhuis>yes. and exits if _fatalException doesn't handle it
09:06:55  <bajtos>ok
09:07:22  * amartensquit (Ping timeout: 246 seconds)
09:09:12  <bajtos>in that case I should call V8::AddMessageListener only after Load has finished (or modify AddMessageListener callback so that it does not call _fatalException handler if we are not loaded yet - perhaps via a global flag?)
09:09:48  <bajtos>anyway, I think I should have all information I need now
09:10:47  <bajtos>bnoordhuis: thanks for your help :)
09:11:02  <bnoordhuis>np :)
09:19:12  <MI6>joyent/node: Ben Noordhuis v0.10 * 3fac415 : doc: fs: synchronize watchFile/unwatchFile warning - http://git.io/6vOvAA
09:31:17  <MI6>nodejs-v0.10: #257 UNSTABLE osx-x64 (1/592) smartos-ia32 (1/592) osx-ia32 (1/592) smartos-x64 (2/592) http://jenkins.nodejs.org/job/nodejs-v0.10/257/
09:47:40  <MI6>nodejs-v0.10-windows: #86 UNSTABLE windows-x64 (8/592) windows-ia32 (7/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/86/
10:03:26  * amartensjoined
10:08:05  * amartensquit (Ping timeout: 256 seconds)
10:23:57  * abraxasquit (Remote host closed the connection)
10:49:19  * timoxleyquit (Ping timeout: 276 seconds)
11:03:48  * amartensjoined
11:06:46  * st_lukejoined
11:08:06  * amartensquit (Ping timeout: 246 seconds)
11:15:15  * st_lukequit (Remote host closed the connection)
11:45:23  <bnoordhuis>thoughts on adding better sprintf functionality to core?
11:45:53  <bnoordhuis>util.format() doesn't quite cut it but i'd rather not change it this late in the game
11:46:07  <mmalecki>bnoordhuis: hey, how does https://github.com/mmalecki/node/compare/0.10-no-idle-gc cut if for a 'remove idle GC on 0.8'?
11:46:25  <bnoordhuis>mmalecki: wut?
11:46:48  <mmalecki>bnoordhuis: I backported your patch since it never made it to 0.8
11:47:00  <mmalecki>and yeah, I can't use the switch
11:47:23  <bnoordhuis>i'm still not sure what the question is :)
11:47:57  <mmalecki>bnoordhuis: ot
11:47:59  <mmalecki>er
11:48:12  * timoxleyjoined
11:48:12  <mmalecki>it's a backport of your patch to remove idle GC on 0.10
11:48:14  <mmalecki>to 0.8
11:48:23  <mmalecki>so I'm wondering if I did it right :-)
11:48:29  <bnoordhuis>ah okay
11:48:35  <bnoordhuis>does it compile?
11:48:43  <mmalecki>it does indeed happen to compile
11:48:54  <bnoordhuis>does it crash within seconds?
11:48:56  <mmalecki>what's even funnier, it's running on one of our frontend balancers
11:49:07  <bnoordhuis>i'll take that as a no :)
11:49:10  <indutny>probably its working then?
11:49:11  <indutny>:)
11:49:11  <bnoordhuis>then you probably did it right
11:49:13  <mmalecki>but I'm wondering how bad this'll turn out to be after few hours
11:49:42  <bnoordhuis>well, the gc in v0.8 is a little less advanced than the one in v0.10
11:49:58  <bnoordhuis>but no doubt you monitor request latency and memory usage
11:50:15  <mmalecki>oh, we even monitor GC latency. I got nervous when it reached 3 s
11:50:27  <bnoordhuis>3 seconds for one gc run?
11:50:31  <mmalecki>yeah
11:50:39  <bnoordhuis>that's extremely bad
11:50:42  <mmalecki>and like 1 GB of memory
11:50:44  <mmalecki>isn't it?
11:50:53  <bnoordhuis>what the...
11:50:57  <mmalecki>I'm trying to see if removing idle GC fixes it at all
11:51:05  <bnoordhuis>right
11:51:08  <bnoordhuis>btw https://github.com/bnoordhuis/node-idle-gc
11:51:11  <mmalecki>but I'm mostly just guessing anyway
11:51:12  <bnoordhuis>that's the idle gc done right
11:51:19  <mmalecki>oh yeah, I saw this one
11:51:26  <mmalecki>I think I'll actually add it next
11:51:53  <bnoordhuis>have you read the README?
11:52:11  <bnoordhuis>for once i got to use a futurama quote in an appropriate context :)
11:52:25  <mmalecki>hahahah
11:52:36  <mmalecki>that always feels good, doesn't it?
11:52:47  <mmalecki>btw, I'm going to be in Amsterdam this or next weekend
11:52:55  <mmalecki>prepare your liver
11:53:29  <bnoordhuis>hah, okay
11:54:16  <`3rdEden>mmalecki: why do you back port it? Why not just use the command line flag?
11:54:50  <mmalecki>`3rdEden: forever. it's actually easier to backport than fix forever.
11:55:07  * mmaleckiis a lazy asshole
11:55:24  <bnoordhuis>oh, i don't know about 'lazy'
11:55:37  <`3rdEden>I thought they ran on aeternum ;p
11:56:06  <mmalecki>`3rdEden: nah, aeternum is slaves only. it's a bit too bare for balancers
11:56:24  <`3rdEden>mmalecki: ok, makes sense
11:56:29  <mmalecki>bnoordhuis: I wonder about that sometimes too ;)
12:03:01  <mmalecki>bnoordhuis: looks like it works. not too many gc's happening at all. thanks for giving it a look.
12:04:05  * amartensjoined
12:05:15  <bnoordhuis>mmalecki: no problem
12:09:09  * amartensquit (Ping timeout: 268 seconds)
12:10:00  <mmalecki>gc: 28706043 ns, that's actually getting really weird
12:32:10  <bnoordhuis>mmalecki: that's 28 ms. that's not too bad, is it?
12:32:52  <bnoordhuis>i mean, it's not great either but at least it's not 3s
12:33:42  <mmalecki>bnoordhuis: I meant it's weird that it's so much faster
13:04:28  * amartensjoined
13:08:51  * kenperkinsquit (Quit: Textual IRC Client: http://www.textualapp.com/)
13:08:51  * amartensquit (Ping timeout: 246 seconds)
13:11:47  * kenperkinsjoined
13:24:54  * c4milojoined
13:41:44  * mikolalysenkojoined
13:42:01  * c4miloquit (Remote host closed the connection)
14:04:44  * amartensjoined
14:09:24  * amartensquit (Ping timeout: 268 seconds)
14:16:34  * groundwaterquit (Quit: groundwater)
14:23:27  * papertigersjoined
14:27:36  * c4milojoined
14:29:01  * defunctzombie_zzchanged nick to defunctzombie
14:36:57  * icarotjoined
15:05:09  * amartensjoined
15:09:21  * amartensquit (Ping timeout: 248 seconds)
15:16:53  * mikealquit (Quit: Leaving.)
15:25:14  * defunctzombiechanged nick to defunctzombie_zz
15:33:40  * groundwaterjoined
15:39:10  * loladirojoined
15:50:21  * bajtosquit (Quit: bajtos)
16:02:37  <isaacs>So, this bug where http emits 'finish' before it's actually finished..
16:02:42  <isaacs>this is an OLD bug.
16:02:52  <isaacs>and i'm not sure how we never caught it before.
16:03:07  <isaacs>(re #5712)
16:03:23  <isaacs>i have a fix, but it breaks a bunch of tests, in a way that makes me think my fix is clearly wrong.
16:04:38  * bajtosjoined
16:05:38  * amartensjoined
16:09:04  <bnoordhuis>laibach. greatest band ever? you decide
16:09:45  <bnoordhuis>isaacs: define 'old'? old as in weeks or months or old as in bert's sense of humor?
16:10:19  <isaacs>bnoordhuis: somewhere between the two
16:10:22  <isaacs>bnoordhuis: at least since 0.6
16:10:34  <isaacs>bnoordhuis: we've always documented that 'finish' means "completely done, you can destroy now without losing data"
16:10:53  <isaacs>bnoordhuis: and we have tests that verify that SOME data was passed through, but not that ALL of it is
16:10:54  * bajtosquit (Ping timeout: 240 seconds)
16:11:00  <isaacs>actually, we didn't document 'finish' prior to 0.10
16:11:08  <isaacs>but people USED it that way, and our code seems to think that's how it works
16:11:30  <isaacs>(insofar as our code seems to think, but i guess node's http layer is not so thoughtful, really ;)
16:12:18  <bnoordhuis>hm, okay
16:12:38  <bnoordhuis>is it harmful to node core? or does it only affect user code
16:14:36  <isaacs>res.write(lotsOfData); res.end(); res.on('finish', res.destroy); <-- will not ever send the full response.
16:15:05  <isaacs>kind of just comes back to the old "http isn't actually compliant streams2-style streams" issue, i guess
16:15:13  <isaacs>(old as in, "since 0.10")
16:16:58  <bnoordhuis>i guess that qualifies as 'bad' :)
16:22:12  * qardjoined
16:23:49  * dapjoined
16:24:32  * hueniversequit (Read error: Connection reset by peer)
16:25:26  <isaacs>ohhh... i figured out what was wrong with my fix.
16:25:33  <isaacs>sometimes the 'close' comes instead of 'drain'
16:25:41  <isaacs>so i was never calling _finish in those cases.
16:25:51  <isaacs>k, i'll clean up this patch, and it'll work as documented.
16:29:21  <tjfontaine>isaacs: that sounds like what I was working on in the tls 0.10 client
16:30:07  <isaacs>kewl
16:30:29  <isaacs>first, though, time for yoga practice.
16:30:32  * isaacs&
16:30:42  <isaacs>whoa, loudbot, nsfw, dude!
16:31:22  <bnoordhuis>you mean that's not water cooler talk in the states?
16:32:02  <isaacs>tjfontaine: - With Mark, TJ and others, debugged muntar ECONNRESETs; determined that
16:32:05  <isaacs> these were due to node 0.10.x behavior; TJ developed a fix
16:32:08  <tjfontaine>er
16:32:13  <isaacs>tjfontaine: what was the 0.10.x behavior you fixed?
16:32:15  <isaacs>just curiousl
16:32:22  * dominictarrquit (Quit: dominictarr)
16:32:32  <tjfontaine>isaacs: tls client was waiting for end and finish, but finish had already fired
16:32:37  <isaacs>tjfontaine: (could ask in scrum@ of course, but seems relevant here)
16:32:41  <isaacs>tjfontaine: ahhh..
16:32:42  <isaacs>yeah
16:32:42  <tjfontaine>https://gist.github.com/tjfontaine/7ab373992c16cbe8b4cc
16:32:50  <isaacs>that's definitely related to this http issue, then, i think
16:33:02  <isaacs>because we assume that 'finish' will come AFTER the response is flushed out
16:33:06  <isaacs>which is generally always post-END
16:33:19  <tjfontaine>right
16:33:27  <isaacs>ok, heading out. i'll be back in a few hours.
16:34:05  * hueniversejoined
16:35:41  * st_lukejoined
16:38:09  * bajtosjoined
16:38:31  <bajtos>bnoordhuis: but feel free to look at the changes, any suggestions for improvement are welcome
16:40:01  * bnoordhuisquit (Ping timeout: 248 seconds)
16:43:36  * dominictarrjoined
16:44:24  * bajtosquit (Ping timeout: 240 seconds)
16:45:03  * defunctzombie_zzchanged nick to defunctzombie
16:45:38  * loladiroquit (Quit: loladiro)
16:53:55  * icarotquit (Ping timeout: 264 seconds)
16:55:23  * c4miloquit (Remote host closed the connection)
16:55:35  * dominictarrquit (Quit: dominictarr)
16:56:51  * bnoordhuisjoined
17:02:38  * AvianFluquit (Remote host closed the connection)
17:04:42  * loladirojoined
17:07:18  * mikealjoined
17:14:00  <mmalecki>bnoordhuis: surprisingly, turning idle GC off seemed to help
17:14:07  * brsonjoined
17:18:35  * dannycoatesjoined
17:24:56  <bnoordhuis>mmalecki: yeah, that doesn't surprise me
17:32:56  * inolenquit (Quit: Leaving.)
17:37:19  * amartens1joined
17:37:54  * dominictarrjoined
17:40:06  * amartensquit (Ping timeout: 246 seconds)
17:41:31  * TooTallNatejoined
17:47:22  * st_lukequit (Remote host closed the connection)
17:49:28  * inolenjoined
17:52:02  * bnoordhuisquit (Ping timeout: 246 seconds)
17:52:30  * defunctzombiechanged nick to defunctzombie_zz
17:57:00  * mikolalysenkoquit (Ping timeout: 256 seconds)
17:58:59  * loladiroquit (Ping timeout: 256 seconds)
18:00:42  * loladirojoined
18:01:09  * sblomjoined
18:01:52  * bnoordhuisjoined
18:04:09  * AvianFlujoined
18:17:58  * sblomquit (Ping timeout: 256 seconds)
18:22:35  * timoxleyquit (Quit: Computer has gone to sleep.)
18:22:52  <bnoordhuis>tjfontaine: ping
18:23:43  <tjfontaine>pong
18:24:05  * saghulquit (Ping timeout: 268 seconds)
18:24:14  * c4milojoined
18:24:23  <tjfontaine>bnoordhuis: pong
18:24:53  <bnoordhuis>tjfontaine: sup tj? what's the status on that mmap patch?
18:25:06  <bnoordhuis>the correct answer is 'merged upstream'
18:25:19  <tjfontaine>heh, then I only have incorrect answers at the moment
18:25:36  <bnoordhuis>have you opened a CR?
18:25:38  <tjfontaine>I'm trying to work on a test case for this silly tls bug, and/or http bug depending on how you look at it
18:26:14  <tjfontaine>no, I need to do their gerrit/reitveld/reviewboard steps, whichever one that is
18:26:19  * sblomjoined
18:28:17  <bnoordhuis>well, okay. when will you do it?
18:28:50  <tjfontaine>hopefully before nodeconf, we also have fbsd in the jpc now, so I can probably keep an eye on regressions there as well
18:29:38  * brsonquit (Ping timeout: 255 seconds)
18:29:59  <bnoordhuis>jpc?
18:30:15  <tjfontaine>joyent public cloud
18:30:46  <bnoordhuis>ah, nice
18:38:00  * leonvvjoined
18:38:22  <tjfontaine>of course my trivial test case works
18:39:36  <tjfontaine>oh well, maybe it didn't
18:40:59  * saghuljoined
18:41:37  * sblomquit (Ping timeout: 248 seconds)
18:43:45  * mralephpart
18:44:55  * sblomjoined
18:44:56  * mikolalysenkojoined
18:46:00  <tjfontaine>well this certainly exercises a different kind of bug
18:46:01  <tjfontaine>(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.
18:46:04  <tjfontaine>RangeError: Maximum call stack size exceeded
18:47:22  <tjfontaine>by george, I think I got it
18:54:23  * saghulquit (Ping timeout: 255 seconds)
18:55:56  * sblomquit (Ping timeout: 256 seconds)
18:56:24  * mikolalysenkoquit (Ping timeout: 246 seconds)
19:01:17  * sblomjoined
19:03:11  * defunctzombie_zzchanged nick to defunctzombie
19:08:51  * brsonjoined
19:13:00  * defunctzombiechanged nick to defunctzombie_zz
19:22:31  * c4miloquit (Remote host closed the connection)
19:25:51  <indutny>tjfontaine: fbsd?
19:25:55  <indutny>in joyent cloud
19:26:01  <indutny>is it available to everyone?
19:27:19  <indutny>oh right
19:27:26  <indutny>gosh, that's totally awesome
19:29:22  * leonvvquit (Remote host closed the connection)
19:31:45  <loladiro>bnoordhuis: Do you have time to discuss libuv's fs functionality? It currently being so separate from the rest of the library seems really unfortunate. I would implement something, but I figured I'd get your ideas first.
19:32:30  <bnoordhuis>loladiro: shoot
19:33:19  <bnoordhuis>i had the awesome idea to use nan tagging to store pointers in js numbers
19:33:24  <bnoordhuis>but v8 is eating my nans :(
19:33:25  <bnoordhuis>> var b = Buffer(8); b.fill(0xFF); b[6] = 0xF8; b[7] = 0x7F; var f = b.readDoubleLE(0); b.writeDoubleLE(f, 0); b
19:33:28  <bnoordhuis><Buffer 00 00 00 00 00 00 f8 7f>
19:33:53  <bnoordhuis>i kind of knew it normalizes them. i'm still sad though :(
19:36:33  <bnoordhuis>indutny: you talk to the v8 people regularly right?
19:37:01  <bnoordhuis>do you know why they don't store doubles unboxed on x64?
19:37:42  <bnoordhuis>it seems like an obvious optimization but there's probably a reason for it
19:38:14  <loladiro>bnoordhuis: Alright, the main thing I really want is not having to worry about what kind of underlying I/O I'm using and just being able to call uv_write on everything (rather than checking and sometimes using uv_fs_write with an entirely different callback interface, etc.). Of course files are not streams, so I'm not sure how to properly integrate that with the uv_read mechanism. I also noticed that uv.h contains reference to a uv_file_t type
19:38:15  <loladiro>be implemented in the future. What was the thinking on that?
19:38:46  <bnoordhuis>loladiro: uv_file_t is just a typedef for either HANDLE or int, nothing more
19:39:16  <loladiro>I was referring to this comment:
19:39:18  <loladiro>"* uv_stream_t is the parent class of uv_tcp_t, uv_pipe_t, uv_tty_t, and
19:39:18  <loladiro> * soon uv_file_t."
19:39:26  <loladiro>I know about the uv_file typedef
19:39:31  <bnoordhuis>oh, that. that was wishful thinking from bert :)
19:40:06  <loladiro>Figured ;). What was the reason this was never really tackled?
19:40:57  <bnoordhuis>well, on-disk files and non-files are pretty disparate, both in libuv and in operating systems
19:41:26  <bnoordhuis>the idea of making uv_write() your one-stop solution to everything i/o-based is kind of appealing
19:41:42  <bnoordhuis>however, streams don't support positional writes, to name something
19:42:36  <bnoordhuis>you could maybe concoct an uv_lseek() function but...
19:46:13  <loladiro>hmm
19:49:59  <loladiro>I don't actually know if that would be such a bad idea
19:50:58  <loladiro>Or a separate uv_write and uv_pwrite that at least use the same callback
19:51:31  <bnoordhuis>loladiro: well, it's something we can consider
19:51:49  <bnoordhuis>maybe open an issue to kickstart the discussion
19:52:52  * defunctzombie_zzchanged nick to defunctzombie
19:53:02  <loladiro>bnoordhuis: Alright, will do.
19:55:11  * saghuljoined
19:55:33  * mikolalysenkojoined
20:00:36  * c4milojoined
20:00:57  * st_lukejoined
20:11:17  <tjfontaine>isaacs: when you're around can you talk to me about #5712 and its relation to the tls bug I was chasing yesterday
20:13:50  <isaacs>tjfontaine: i'm back
20:14:07  <tjfontaine>ok, so
20:14:27  <tjfontaine>the real fix to my issue should be the fix in the http layer, right?
20:15:16  * mikolalysenkoquit (Ping timeout: 256 seconds)
20:15:22  <tjfontaine>or should the tls client also guard against this case?
20:16:46  <isaacs>i think 'finish' should mean "ended and flushed"
20:16:51  <isaacs>ended, flushed, drained, all done
20:18:26  * defunctzombiechanged nick to defunctzombie_zz
20:19:39  <isaacs>tjfontaine: so, i wonder if there IS a case where an http 'end' might still happen post-'finish'
20:20:35  <isaacs>tjfontaine: that was the nut of the bug you were seeing, right?
20:20:54  <tjfontaine>in this case what is happening is a PUT that returns 404, connection:close, finish has fired, but by the time tls gets to the shutdown it still thinks it's waiting to hear that finish and then only sees an end
20:21:10  * mikealquit (Quit: Leaving.)
20:21:38  <tjfontaine>but I'm having a hell of a time reproducing it standalone
20:24:50  * bnoordhuisquit (Ping timeout: 255 seconds)
20:25:58  * mikolalysenkojoined
20:26:57  <isaacs>i see
20:27:13  <isaacs>there probably still ought to be a guard in tls.js
20:27:25  <isaacs>but i think i could probably make that happne
20:27:26  <isaacs>one sec
20:27:42  <tjfontaine>which happen?
20:48:05  <isaacs>tjfontaine: the tls stuff
20:48:43  <tjfontaine>the guard like I did in https://gist.github.com/tjfontaine/7ab373992c16cbe8b4cc or the test case for it?
20:49:02  <isaacs>tjfontaine: a reproducible test case.
20:49:04  <tjfontaine>ok
20:49:08  <isaacs>tjfontaine: actually, my fix for finish busts this...
20:49:19  <isaacs>tjfontaine: arguably, in a way that is not bad.
20:49:28  <isaacs>but, there's a client-side issue here as well.
20:49:50  <isaacs>if you PUT, and try to upload a lot of data, and the server, without reading all the data, sends a 404 with connection:close
20:49:54  <isaacs>your write will fail.
20:49:57  <isaacs>with EPIPE
20:50:03  <isaacs>because the server destroys the connection
20:51:15  <tjfontaine>I was working on the client side, with an agent it tries to reuse the connection and you generally get a RESET because the (non-default) agent dispatches it again
20:51:50  * c4miloquit (Remote host closed the connection)
20:52:01  <isaacs>right
20:52:09  <isaacs>i'm not sure what the right answer is in this case.
20:52:20  <isaacs>where the write() buffer is all full and waiting, and you get a close from the server
20:52:28  <isaacs>it seems like it's the server's prerogative to not read() the request body
20:53:14  <tjfontaine>right
20:55:16  <isaacs>but it also seems like, if the client sees a connection:close, and then a response, it should give up or something
20:55:19  <isaacs>i don't know
20:55:33  * `3rdEdenchanged nick to `3E|Zz
20:56:09  <tjfontaine>well the client was trying to close, but it was stuck in established waiting for a world that would never come
20:56:20  <tjfontaine>I dunno
20:57:46  <isaacs>right
20:58:16  <isaacs>tjfontaine: can you see if this fixes your tls issue? https://github.com/joyent/node/pull/5739
20:58:28  <isaacs>oh, wait, that's 0.10, not 0.8, huh?
20:58:39  <tjfontaine>no this is 0.10 client that I was debugging
20:58:58  * mikealjoined
20:59:01  <isaacs>kewl
20:59:20  <tjfontaine>conversation partitioning
20:59:23  <isaacs>tjfontaine: let's keep this here, i'm getting confused :)
20:59:35  * isaacssends some carrier pigeons to FiDi...
20:59:39  <tjfontaine>anyway I have to run to that meeting with max, but I will try as soon as that's done
20:59:44  * isaacsand a telegraph to Alameda
20:59:47  <isaacs>right
20:59:56  <isaacs>thanks, lmk if that fixes the thing youer' seeing. i'll try to repro
21:01:01  <isaacs>tjfontaine: and actually, i take back what I said about the EPIPE thing. the client should raise an error, because the write() failed.
21:01:06  <isaacs>so EPIPE is completely appropriate here.
21:01:25  <isaacs>if you're uploading a bug body, clearly you don't expect to be shut down
21:03:48  * mikealquit (Ping timeout: 268 seconds)
21:08:57  <isaacs>s/bug/big/
21:09:11  <tjfontaine>well we get a reset because the fd is still there, and the server says "hey wtf I already told you to close"
21:14:54  * papertigersquit (Quit: papertigers)
21:22:22  <mmalecki>who'd I ask for help if I wanted to add a dtrace probe to node?
21:29:14  * mikealjoined
21:39:07  * rendarquit
21:54:07  * groundwaterquit (Quit: groundwater)
21:56:09  * icarotjoined
22:07:03  * groundwaterjoined
22:08:50  * loladiroquit (Quit: loladiro)
22:10:23  * groundwaterquit (Client Quit)
22:13:52  * hzquit
22:18:09  * mikolalysenkoquit (Ping timeout: 248 seconds)
22:19:53  * groundwaterjoined
22:23:02  * loladirojoined
22:32:41  <tjfontaine>mmalecki: me I guess
22:35:12  * mikealquit (Quit: Leaving.)
22:35:59  * mikealjoined
22:37:46  * c4milojoined
22:40:15  <tjfontaine>isaacs: no, that change didn't fix the ECONNRESET I was seeing
22:40:42  * dominictarrquit (Quit: dominictarr)
22:58:58  * mikolalysenkojoined
23:11:14  * mikealquit (Quit: Leaving.)
23:13:35  * sblomquit (Ping timeout: 255 seconds)
23:17:36  <mmalecki>tjfontaine: so how'd I go about adding a host field to the probe?
23:17:43  <mmalecki>like req.headers.host?
23:18:36  * timoxleyjoined
23:20:16  <tjfontaine>mmalecki: looking in the v0.10 source tree you would add that field to the struct and the translator in src/node_dtrace.h and src/node.d
23:20:51  <tjfontaine>mmalecki: then in src/node_dtrace.cc in HTTP_SERVER* you'll want to fill that field in
23:21:02  <tjfontaine>the macros generally
23:21:56  <tjfontaine>to be done nicely we'll want an SLURP_HTTP_CONNECTION that uses SLURP_CONNECTION but adds that field
23:22:10  <tjfontaine>presuming this is on the http server side of the probes?
23:22:17  * loladiroquit (Quit: loladiro)
23:22:44  <mmalecki>yup, server side
23:22:54  <mmalecki>okay, will give it a try, thanks
23:23:01  <mmalecki>(assuming that you guys want such a thing)
23:23:12  <tjfontaine>ok, because there are some outstanding bugs in the http client stuff
23:23:43  <tjfontaine>mmalecki: it seems useful to me, but also something that probably could be instrumented with dtrace-provider
23:24:42  <tjfontaine>because the builtin http server doesn't really care much about vhost style operations
23:28:25  * mikealjoined
23:31:19  * c4milo_joined
23:31:59  * c4milo_quit (Remote host closed the connection)
23:32:10  * dannycoatesquit (Remote host closed the connection)
23:32:16  * c4milo_joined
23:39:21  * c4milo_quit (Remote host closed the connection)
23:50:57  * loladirojoined
23:51:12  * groundwaterquit (Quit: groundwater)
23:52:55  <isaacs>tjfontaine: that's too bad
23:53:50  <tjfontaine>indeed
23:53:55  <isaacs>tjfontaine: doing the same test from my GH-5712 branch with https also fails.
23:53:58  <isaacs>times out
23:54:26  <tjfontaine>can you add a debug line abovee the waiting fn to see if it's also stuck there for you?
23:54:26  <isaacs>tjfontaine: what was the guard that you put in tls.js?
23:54:32  <tjfontaine>https://gist.github.com/tjfontaine/7ab373992c16cbe8b4cc
23:55:35  <isaacs>tjfontaine: nope.
23:55:41  <isaacs>has no effect
23:57:09  <tjfontaine>is this._finished false there?
23:58:01  <isaacs>tjfontaine: the res.finish never emits
23:58:18  <tjfontaine>right, so before your patch finish had already emit'd
23:58:30  <tjfontaine>and now it's stuck in never land
23:59:05  <tjfontaine>this particular failure case feels related to specifically the tls client