00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:54  * defunctzombiechanged nick to defunctzombie_zz
00:02:09  * bnoordhuisquit (Ping timeout: 248 seconds)
00:03:07  <MI6>libuv-node-integration: #76 UNSTABLE smartos-ia32 (1/588) osx-ia32 (1/588) smartos-x64 (1/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/76/
00:03:44  * mikealjoined
00:05:30  * dominictarrquit (Quit: dominictarr)
00:08:24  * pachetjoined
00:08:50  * sblomjoined
00:09:43  * pachetquit (Client Quit)
00:09:51  * defunctzombie_zzchanged nick to defunctzombie
00:14:51  * piscisaureus_joined
00:16:04  * timoxleyquit (Quit: Computer has gone to sleep.)
00:16:09  * qardquit (Quit: Leaving.)
00:17:35  * piscisaureus_quit (Client Quit)
00:20:52  * dominictarrjoined
00:25:51  * inolenjoined
00:28:47  * mikealquit (Quit: Leaving.)
00:30:37  * amartensquit (Quit: Leaving.)
00:32:27  <tjfontaine>trevnorris: so far tracking 3.19 hasn't been a problem, correct?
00:35:26  * dominictarrquit (Quit: dominictarr)
00:39:41  * qardjoined
00:48:28  * dap1quit (Quit: Leaving.)
00:52:16  * dannycoatesjoined
01:08:34  * bnoordhuisjoined
01:13:25  * bnoordhuisquit (Ping timeout: 276 seconds)
01:14:40  * timoxleyjoined
01:15:32  * hzquit
01:32:38  * inolenquit (Quit: Leaving.)
01:45:11  * defunctzombiechanged nick to defunctzombie_zz
01:46:46  * c4milojoined
02:00:13  * sblomquit (Ping timeout: 276 seconds)
02:09:28  * c4miloquit (Remote host closed the connection)
02:21:31  * inolenjoined
02:30:47  <isaacs>this is my new favorite tumblr: http://nodejsreactions.tumblr.com/
02:49:05  * icarotquit (Read error: Connection reset by peer)
02:49:36  * icarotjoined
02:57:43  * brsonquit (Ping timeout: 260 seconds)
03:06:27  * mikealjoined
03:08:27  * mikealquit (Client Quit)
03:23:51  <tjfontaine>huh I think I can reproduce that eaddrnot bug
03:39:24  * icarotquit (Ping timeout: 256 seconds)
03:39:37  * brsonjoined
03:45:49  * amartensjoined
03:46:05  * amartensquit (Client Quit)
03:55:47  * brsonquit (Ping timeout: 240 seconds)
03:58:05  * brsonjoined
03:59:42  * kazuponjoined
04:00:02  * janderssenjoined
04:01:37  * dsantiagoquit (Quit: Leaving...)
04:02:02  <janderssen>hi, reading the documentation of libuv and the examples, you malloc a uv_tcp_t to pass into uv_read_start, but all the tests and everything seems to not free it (and if I free it, it crashes), so is it fair to say that libuv free's this pointer beneath the scenes ?
04:03:20  <tjfontaine>that wouldn't be fair to say, when you say tests you mean in the tests dir?
04:03:37  <janderssen>Yep
04:03:53  <tjfontaine>most of those don't really malloc, they're stack allocated
04:04:20  <janderssen>give me a sec, Ill point to you a test I was looking at
04:05:20  <janderssen>so in test-ipc.c, ipc_on_connection_tcp_conn, the "conn = malloc(sizeof(*conn))" doesn't get free'd below, is this correct?
04:08:27  * defunctzombie_zzchanged nick to defunctzombie
04:09:06  <janderssen>tjfontaine: also I noticed quite a lot of others do the same in this file, I am probably missing something.
04:11:57  <tjfontaine>janderssen: most of these generally get free'd in their close callback's
04:12:36  <janderssen>tjfontaine: than, Ill continue studying further.
04:13:37  * normanmjoined
04:13:37  <janderssen>tjfontaine: sorry, I meant to say thanks.
04:13:58  <tjfontaine>no problem, but in general you are responsible for allocating and freeing the handles and requests
04:15:04  <janderssen>ok, that sum's up it up fine, I will have to look at what I am doing wrong in my code. Thanx again.
04:18:24  * dsantiagojoined
04:39:45  <trevnorris>tjfontaine: no. hasn't been a problem
04:39:55  <tjfontaine>k
04:40:07  <trevnorris>tjfontaine: everything will be going through a deprecation phase, even the removal of Local<>
04:40:35  <trevnorris>so we'll have ample time to adjust core.
04:40:57  <trevnorris>it's mainly the native module authors that will have a problem upgrading to v0.12
04:41:02  <tjfontaine>trevnorris: I just meant, if you had any inkling that that we may have to rollback off of 3.19
04:41:29  <trevnorris>oh no. 3.19 has had a lot of api changes, but so far has been stable.
04:42:49  <tjfontaine>mmk
04:43:18  <tjfontaine>yang was asking if we needed abort-on-uncaught backported to any other v8 revs
04:44:00  <trevnorris>oh, in case we dropped of 3.19. on we'll be good on 3.19.
04:44:41  <trevnorris>and actually better we move to the new api for v0.12, so module authors don't need to do a bunch for the v1 release.
04:45:12  <tjfontaine>indeed the more churn we can get in before we move to 1.0 the happier everyone will be in the long run
05:26:03  * qardquit (Quit: Leaving.)
05:33:10  * bajtosjoined
05:34:01  <tjfontaine>trevnorris: did you forget the conversations about process.on('beforeExit') today?
05:34:16  <trevnorris>tjfontaine: wasn't listening in.
05:34:20  <tjfontaine>ah ok
05:36:38  * timoxleyquit (Quit: Computer has gone to sleep.)
05:37:19  * Benvie_quit (Ping timeout: 276 seconds)
05:37:59  * Benvie_joined
05:40:33  <trevnorris>tjfontaine: I see why this is necessary, but just feel like a possible world of hurt is hidden in there somewhere.
05:42:01  <tjfontaine>trevnorris: I was about to add a comment, I think the test should also include a scenario where someone explicitly calls process.exit()
05:42:13  <tjfontaine>or a second test, but anyway
05:42:41  <tjfontaine>if process.exit is called, I don't think we should necessarily be allowed to reup the loop, but maybe we should
05:44:53  <trevnorris>well, w/ his pr if you call process.exit() then beforeExit is never emitted
05:45:11  <tjfontaine>right ya, I was just tracing the code
05:48:14  * defunctzombiechanged nick to defunctzombie_zz
05:48:33  <trevnorris>tjfontaine: this is the type of stupidity that I can see coming though: https://gist.github.com/trevnorris/5668211
05:50:18  <tjfontaine>what happens?
05:50:43  <trevnorris>never ending loop
05:51:09  <tjfontaine>because console.log doesn't flush by the end of keepalive?
05:51:47  <tjfontaine>oh because it bounces to the closure
05:51:57  <tjfontaine>ya well, we can't fix stupid
05:52:20  <tjfontaine>for your test, what happens with process.nextTick that doesn't keep it alive either, does it
05:52:53  <trevnorris>yeah. process.nextTick won't keep it alive since it's run in the same event phase of uv_run
05:53:48  <tjfontaine>that should probably be documented, it's cute that setImmediate works, but I guess because it re-registers the uv_check at that point
05:55:06  <tjfontaine>trevnorris: I would update the pr with both those examples and ask for clarification at the very least in the docs about it
05:57:12  <tjfontaine>see you on the morrow
05:57:22  <trevnorris>night
06:10:31  <trevnorris>tjfontaine: wait. process.nextTick does cause beforeExit to fire...
06:12:45  * `3rdEdenjoined
06:15:31  <trevnorris>isaacs: thought nextTick happened at the end of the callback, not on the next round of the event loop.
06:15:53  <trevnorris>isaacs: event loop as in the next round of uv_run
06:27:56  * rendarjoined
06:33:12  * `3rdEdenchanged nick to `3E|BRB
06:34:54  * timoxleyjoined
06:37:58  * brsonquit (Quit: leaving)
06:59:23  * janderssenquit (Ping timeout: 252 seconds)
07:05:55  * cjdquit (Ping timeout: 264 seconds)
07:22:40  * kuebkjoined
07:25:16  * `3E|BRBchanged nick to `3E
07:37:47  * csaohjoined
07:38:40  * `3Equit (Remote host closed the connection)
07:48:22  * dominictarrjoined
07:48:32  * `3Ejoined
07:59:43  <saghul>indutny the osx-select test doesn't compile for me on OSX 10.6 due to the comment synytax
07:59:44  <saghul>test/test-osx-select.c: In function ‘run_test_osx_select’:
07:59:45  <saghul>test/test-osx-select.c:65: error: expected expression before ‘/’ token
08:08:00  * paddybyersjoined
08:08:40  * hzjoined
08:19:08  * paddybyersquit (Ping timeout: 252 seconds)
08:33:21  * paddybyersjoined
08:38:37  * cjdjoined
08:55:54  * hij1nxquit (Ping timeout: 264 seconds)
08:56:55  * hij1nxjoined
08:58:49  * dannycoatesquit (Ping timeout: 276 seconds)
09:00:23  * paddybyersquit (Ping timeout: 252 seconds)
09:03:27  * leonvvjoined
09:11:59  * dscapequit (Ping timeout: 260 seconds)
09:14:11  * `3Equit (Remote host closed the connection)
09:18:10  <indutny>saghul: ouch
09:31:33  * `3rdEdenjoined
09:49:20  * paddybyersjoined
09:54:35  * leonvvquit (Remote host closed the connection)
09:55:56  * paddybyersquit (Ping timeout: 252 seconds)
09:57:07  * udpjoined
10:05:23  * bajtosquit (Quit: bajtos)
10:12:13  * kazupon_joined
10:12:31  * kazuponquit (Read error: Connection reset by peer)
10:15:31  * udp_joined
10:18:29  * udpquit (Ping timeout: 252 seconds)
10:18:30  * udp_changed nick to udp
10:18:54  * kazupon_quit (Remote host closed the connection)
10:23:24  * csaohquit (Quit: csaoh)
10:30:46  * timoxleyquit (Quit: Computer has gone to sleep.)
10:32:33  * csaohjoined
10:43:42  * timoxleyjoined
11:05:44  * udpquit (Quit: udp)
11:12:23  * dscapejoined
11:26:41  * bajtosjoined
11:29:23  * kazuponjoined
11:34:47  * kazuponquit (Ping timeout: 260 seconds)
11:37:21  * udpjoined
11:47:07  * bajtosquit (Quit: bajtos)
11:48:57  * bnoordhuisjoined
12:09:25  * udpquit (Quit: udp)
12:12:06  * paddybyersjoined
12:23:47  * Domenic_quit (Ping timeout: 260 seconds)
12:24:27  * paddybyersquit (Ping timeout: 252 seconds)
12:31:51  * AvianFlujoined
12:39:19  * AvianFluquit
12:39:30  * AvianFlujoined
12:39:50  * AvianFluquit (Client Quit)
12:42:39  * AvianFlujoined
13:12:19  * roxlujoined
13:15:10  * roxluquit (Read error: No route to host)
13:18:18  * piscisaureus_joined
13:19:56  <piscisaureus_>saghul: hey
13:20:06  <saghul>piscisaureus_ hi!
13:20:13  <piscisaureus_>saghul: I saw https://github.com/saghul/libuv/commit/13c108924e6b7e00f0ae73dffc4545c876cafba2 but it scares be a bit
13:20:39  <saghul>why is that?
13:21:18  <piscisaureus_>saghul: so basically you are saying that there should always be atleast one check in between a normal callback and a close callback
13:21:25  <piscisaureus_>if you close that handle in the normal callback?
13:22:03  <piscisaureus_>saghul: well the reason is simple: we're going to do a lot more syscalls now because usually people will close a handle from a callback (I mean, where else you do it?)
13:22:12  <saghul>yep, or generally speaking, if any handle was closed before polling, we should do a zero time poll this time
13:22:25  <piscisaureus_>saghul: well that should already be the case
13:22:59  <saghul>without my change the tests stalls for 100 seconds
13:23:10  <piscisaureus_>saghul: so the effect of this is that we always need to make a poll syscall before we can run a close callback
13:23:25  <piscisaureus_>and to make matters worse, shutdown() is also called from the endgame handler
13:23:40  <saghul>in a way, yes
13:23:43  <piscisaureus_>so in order to send FIN we need to not only call shutdown() but now we need to make another poll syscall
13:23:49  <saghul>hum, I didn't know about shutdown()
13:24:08  <piscisaureus_>well that's all internal to uv-win
13:24:30  <saghul>maybe we can remember that there were engame handles and run them, but not block for io if we ran some?
13:24:48  <piscisaureus_>saghul: well I thought that was already the case (and if not, it is a bug)
13:24:52  <piscisaureus_>let me find the code for you
13:25:03  <saghul>doesn't seem to be the case
13:25:52  <piscisaureus_>saghul: https://github.com/joyent/libuv/blob/master/src/win/core.c#L298
13:26:02  <piscisaureus_>saghul: so the second argument is whether is should block or not
13:26:18  <piscisaureus_>saghul: but if engame_handles != NULL then we shouldn't be blocking
13:26:46  <saghul>piscisaureus_ yeah, now, in the test case I added, endgames will be null, after running the close callback, right?
13:27:04  <saghul>so the poll will be done with timer_handle2 timeout
13:30:23  <piscisaureus_>saghul: right - so what should be a good reason not to block in this case?
13:30:38  <piscisaureus_>saghul: you should also consider that this works with timers but not with tcp handles for example
13:31:00  <piscisaureus_>saghul: because the tcp handle won't be pushed unto the endgame queue until the last write is completed
13:31:09  <piscisaureus_>s/unto/onto/
13:32:36  <piscisaureus_>saghul: so just for clarity - I'm not necessarily against landing your patch (although we should definitely benchmark it - it's not a zero risk change as you and bnoordhuis seem to assume)
13:32:50  <piscisaureus_>saghul: but I would like to understand what the underlying problem is you are trying to solve...
13:33:14  <saghul>piscisaureus_ well, I ran into this because I'm using the event loop as a scheduler, and on unix it worked so I started digging
13:34:22  <saghul>piscisaureus_ i queue all callbacks and run them in a check handle, but in windows, the loop will run close callbacks and them it may block so my scheduling thing is stalled
13:34:39  <saghul>(kind of hard to synthesize in just a few worlds, sorry)
13:34:41  <piscisaureus_>saghul: yes so you are apparently abusing the check handle
13:34:47  <saghul>*words
13:34:49  <piscisaureus_>saghul: maybe we should remove that feature :)
13:34:57  <piscisaureus_>saghul: you really should use an uv_idle_t for this
13:35:12  <piscisaureus_>unfortunately uv_idle is broken on unix the last time I checked
13:35:13  <saghul>piscisaureus_ well, it also behaves different on windows than on unix
13:35:33  <piscisaureus_>yes - the unix implementation is (or atleast used to be) wrong
13:35:51  <saghul>I'm using a handle because it's what runs last
13:36:10  <saghul>so every other handle queues their callbacks, and I process them in order at the end
13:36:26  <saghul>this is what Tulip does and the check handle was my way of emulating that
13:37:00  <piscisaureus_>the correct semantics for uv_idle_t are outlined here : http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#code_ev_idle_code_when_you_ve_got_no
13:37:40  <piscisaureus_>so the rule is:
13:37:40  <piscisaureus_>* uv_idle runs last
13:37:40  <piscisaureus_>* if there are active idle watchers then poll won't block
13:38:35  <saghul>right now we only seem to obey the second rule
13:38:36  <bnoordhuis>that second part works okay, at least :)
13:38:43  <saghul>:-)
13:39:20  <saghul>right now i'm workarounding this by starting an idle handle in the close callback… but i'd rather not do that
13:39:20  <piscisaureus_>which means that you can do something like:
13:39:20  <piscisaureus_>on_event(event):
13:39:20  <piscisaureus_> push_event_to_queue(event)
13:39:20  <piscisaureus_> start_idle_watcher()
13:39:20  <piscisaureus_>on_idle(handle):
13:39:20  <piscisaureus_> proces_event_queue():
13:39:20  <piscisaureus_> stop_idle_watcher()
13:40:21  <piscisaureus_>actually I like the unix semantics a bit better
13:40:28  <saghul>I'm keeping the check handle active all the time, and use an idle handle to control when I explicitly want the loop not to block
13:40:34  <piscisaureus_>just always run uv_idle on every loop iteration
13:40:47  <saghul>great!
13:40:55  <saghul>commit that before you change your mind!
13:41:00  <saghul>:-)
13:41:00  <piscisaureus_>yeah haha
13:41:18  <piscisaureus_>well what we need to do
13:41:26  <piscisaureus_>is figure out whether there are any other users of uv_idle
13:41:36  <piscisaureus_>:_
13:41:46  <piscisaureus_>https://www.google.com/search?q=uv_idle_t&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:nl:official&client=firefox-a#safe=off&client=firefox-a&hs=uPN&rls=org.mozilla:nl%3Aofficial&sclient=psy-ab&q=uv_idle_t&oq=uv_idle_t&gs_l=serp.12...0.0.0.34193.0.0.0.0.0.0.0.0..0.0...0.0...1c..14.psy-ab.ghRgNuIjK6I&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.47008514,d.d2k&fp=183b7b9925a651e5&biw=1920&bih=1081
13:42:00  <saghul>I for one, only use it for preventing the loop from blocking, nothing else
13:42:41  <bnoordhuis>that seems to be the most common use case
13:42:52  <bnoordhuis>node does the same thing
13:43:51  <piscisaureus_>yeah so in a way windows is just a bit more "zealous" when deciding when a loop is idle
13:44:14  <piscisaureus_>because it does another non-blocking poll before deciding the loop is really idle
13:44:23  <piscisaureus_>this is actually quite lame come to think of it
13:44:40  <piscisaureus_>unfortunately uv_idle_t has too many hits on google
13:46:21  <bnoordhuis>i'm the top hit!
13:46:27  <piscisaureus_>https://metacpan.org/source/MLEHMANN/EV-4.03/libev/ev.c#L2126
13:46:37  <saghul>do you think people are relying on those semantics, given that unix doesn't implement them?
13:47:04  <bnoordhuis>people probably depend on the unix semantics
13:47:07  <piscisaureus_>bnoordhuis: for me zocket.sprocket is the top hit
13:47:15  <bnoordhuis>aw, search bubbles:(
13:47:16  * AvianFluquit (Remote host closed the connection)
13:47:35  <piscisaureus_>I agree
13:47:40  <piscisaureus_>ok let's change this
13:48:45  <piscisaureus_>unfortunately "idle" is no longer really accurate
13:48:59  <saghul>yay!
13:49:00  <piscisaureus_>but *shrug* :)
13:49:48  <piscisaureus_>saghul: you were lucky to find me in the mood for "polderen" :)
13:51:55  * pachetjoined
13:52:10  * AvianFlujoined
13:53:54  <piscisaureus_>saghul: bnoordhuis: so what is the right place to invoke uv_idle?
13:54:06  <piscisaureus_>now that we're at it I can move it around and put it where you want
13:54:22  <piscisaureus_>it's currently here -> https://github.com/joyent/libuv/blob/c39648674c404324c276831fc0ec5c99f30b2fb5/src/win/core.c#L288
13:54:27  <saghul>after check?
13:54:38  <piscisaureus_>after timers, before regs
13:54:45  <saghul>ok
13:55:00  <piscisaureus_>s/regs/reqs
13:55:24  <piscisaureus_>saghul: well if you put it after check that you are assuming that poll conceptually comes last in the event loop
13:55:37  <piscisaureus_>(alright - it is a loop, there's not real beginning and end)
13:55:58  <piscisaureus_>so if you want it "last" we should do it before prepare maybe?
13:57:24  <bnoordhuis>unix puts it after times but before check
13:57:30  <bnoordhuis>*timers
13:57:41  <piscisaureus_>bnoordhuis: why do you do run_pending *after* prepare?
13:58:06  <piscisaureus_>bnoordhuis: unix puts it after timers but before prepare?
13:58:22  <bnoordhuis>i mean idle handles
13:58:33  <bnoordhuis>and yes, after timers, before prepare
13:58:45  <piscisaureus_>bnoordhuis: yeah that seems very reasonable to me :)
13:59:00  <piscisaureus_>bnoordhuis: what doesn't is that you run pending after prepare, unless I misinterpret what run_pending does
13:59:04  <bnoordhuis>re: run_pending, it's complicated
13:59:23  <bnoordhuis>that's for i/o handles that have been primed with uv__io_feed()
14:00:39  <bnoordhuis>i guess it should come before prepare
14:00:59  <piscisaureus_>bnoordhuis: yessir, maybe even before idle :)
14:01:43  <piscisaureus_>but I have no strong opinion on the latter, but I do know that only poll should be between prepare and check
14:01:58  <bnoordhuis>the thing is, run_pending is used for i/o handles that have error'd somehow
14:02:07  <bnoordhuis>e.g. uv_pipe_connect() that failed to connect
14:02:58  <bnoordhuis>i'm thinking out aloud if there's situations where running one before the other would create issues
14:03:16  <piscisaureus_>bnoordhuis: well maybe if you do something that fails in a prepare handle?
14:03:35  <piscisaureus_>bnoordhuis: on windows we deal with this by making poll non-blocking when there's anything in the request queue
14:03:53  <piscisaureus_>bnoordhuis: libev stipulates that prepare and check are special and you shouldn't really do any i/o in them
14:04:09  <bnoordhuis>yeah, but no one ever reads the docs
14:04:17  <bnoordhuis>and besides, that's something of an unreasonable limitation
14:04:21  <piscisaureus_>yeah, and i also dislike this restriction
14:04:23  <piscisaureus_>indeed
14:05:01  <piscisaureus_>bnoordhuis: so for uv-win I figured that even if legal it would be very rare so I make poll nonblocking when then happens and process these events in the next round
14:05:12  <piscisaureus_>s/then/that/
14:05:22  <indutny>hello
14:05:25  <bnoordhuis>hm, let me think about it
14:05:43  <bnoordhuis>i was thinking we should move uv_run() to src/uv-common.c
14:05:53  <bnoordhuis>that would force us to make it consistent across platforms
14:05:59  <bnoordhuis>hi fedor
14:06:06  <piscisaureus_>saghul: you want to go home. In half an hour hell will break loose in 020
14:06:28  <indutny>hi ben
14:06:38  <piscisaureus_>bnoordhuis: I agree with the feeling in a way. However I'm afraid that means you have to give way a lot in your implementation
14:06:42  <piscisaureus_>to make room for windows quirks
14:06:59  <bnoordhuis>like what?
14:07:01  <piscisaureus_>and limitations (such as having to delay close callbacks and such)
14:07:17  <bnoordhuis>i'd be okay with that
14:07:28  <bnoordhuis>uv-unix kind of needs that to deal with uv_fs_poll_t handles properly
14:07:34  <piscisaureus_>bnoordhuis: also (soon) running an off-the-main-thread polling mechanism not quite unlike the select thread hack on os x
14:07:43  * kevinswiberjoined
14:07:44  <piscisaureus_>but performance critical (which the select hack isnt really()
14:07:48  * paddybyersjoined
14:08:22  <bnoordhuis>okay. how would that be an obstacle? worst case, you turn the function call into an empty macro on unices
14:09:19  <piscisaureus_>bnoordhuis: well - my implementation lets the other thread put reqs right into the request queue
14:09:48  <saghul>piscisaureus_ i'm safe at home already :-)
14:09:54  <piscisaureus_>saghul: hah! good for you
14:09:59  <piscisaureus_>me too :)
14:10:22  <saghul>gtg now maybe we can discuss the close thing in the ML ?
14:10:28  <bnoordhuis>sure
14:10:33  <piscisaureus_>ok
14:10:41  <piscisaureus_>bnoordhuis: but in general I would say I am for the idea
14:10:49  <bnoordhuis>good
14:10:49  <saghul>ok, i'll send an email later, thanks guys!
14:11:45  <bnoordhuis>there's some other things, like uv_now()
14:11:45  <piscisaureus_>bnoordhuis: I can also do something about windows internals (I mean, the fact that the endgame queue is used for things unrelated to close callbacks is really ungodly)
14:11:55  <bnoordhuis>it's exactly the same in uv-win and uv-unix
14:12:00  <piscisaureus_>bnoordhuis: which is basically the reason we are having this discussion
14:12:10  <bnoordhuis>okay :)
14:12:28  <piscisaureus_>bnoordhuis: yeah uv_now could move to in my book
14:13:15  <piscisaureus_>bnoordhuis: so now you've added a whole new problem to your list
14:13:30  <piscisaureus_>which is defining the interface between the event loop and the platform backend :)
14:13:57  <MI6>joyent/libuv: Ben Noordhuis v0.10 * e0bdb3d : unix, windows: move uv_now() to uv-common.c - http://git.io/JH0jCA
14:14:00  <bnoordhuis>^ done
14:14:11  <bnoordhuis>piscisaureus_: yeah, agreed
14:14:21  <bnoordhuis>i was thinking we could do what libev does
14:14:31  <bnoordhuis>uv-unix currently runs callbacks straight from uv__io_poll()
14:14:42  <bnoordhuis>which is okay (actually it's great for throughput)
14:14:53  <bnoordhuis>but it makes things a little inconsistent
14:15:08  <piscisaureus_>you want to push handles onto a queue and then process a queue?
14:15:12  <bnoordhuis>yeah
14:15:36  <piscisaureus_>bnoordhuis: the conceptual issue is also that on unix you get "handles" from the OS and generate requests from that
14:15:37  <bnoordhuis>that would also let me coalesce read and write events with kqueue
14:16:01  <bnoordhuis>piscisaureus_: i'm not following. requests?
14:16:04  <piscisaureus_>bnoordhuis: on windows we just get requests from the OS and sometimes we marshal those into handle callbacks (like in case of read and accept)
14:16:23  <piscisaureus_>bnoordhuis: epoll gives you FDs right?
14:16:35  <piscisaureus_>bnoordhuis: GetQueuedCompletionStatus gives you uv_req_t's basically
14:16:48  <bnoordhuis>ah, right
14:16:53  <bnoordhuis>yeah, epoll returns fds
14:17:06  <piscisaureus_>so this makes defining a common backend quite hairy :)
14:17:12  <bnoordhuis>which are then correlated with handles through a hash table
14:17:29  <MI6>libuv-v0.10: #82 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/82/
14:17:30  <piscisaureus_>bnoordhuis: huh? what?
14:17:36  <piscisaureus_>bnoordhuis: hash table where?
14:17:38  * bajtosjoined
14:17:41  <bnoordhuis>well, basically it's an array
14:17:48  <bnoordhuis>but the fd is used as the index/key
14:18:01  * saghulquit (Ping timeout: 252 seconds)
14:18:10  <bnoordhuis>the array element is a uv__io_t*
14:18:31  <piscisaureus_>bnoordhuis: you don't you use epoll_event.data ?
14:18:39  <bnoordhuis>i do but only to store the fd
14:18:59  <bnoordhuis>i don't store a pointer because epoll_wait() might generate events for file descriptors we've stopped watching
14:19:11  <piscisaureus_>bnoordhuis: oh haha
14:19:24  <piscisaureus_>bnoordhuis: right - yeah that's the reason windows delays close events
14:19:37  * saghuljoined
14:19:39  <piscisaureus_>bnoordhuis: because the req might reference a handle :)
14:19:54  * Domenic_joined
14:19:59  <bnoordhuis>right :)
14:20:03  <MI6>libuv-v0.10-gyp: #45 UNSTABLE windows-x64 (4/187) windows-ia32 (4/187) smartos-x64 (4/186) smartos-ia32 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/45/
14:20:14  <piscisaureus_>(and also because many internal req's are embedded in a handle so freeing would really screw things up)
14:20:15  <bnoordhuis>back to GetQueuedCompletionStatus()
14:20:28  <bnoordhuis>so you get requests rather than handles
14:20:32  <bnoordhuis>but is that an issue?
14:20:45  <bnoordhuis>essentially what backend_poll() would do, is prime handles that are somehow ready
14:21:20  <piscisaureus_>bnoordhuis: yeah I get what you mean
14:21:45  <piscisaureus_>bnoordhuis: sounds a bit less efficient but it's worth a try
14:22:00  <piscisaureus_>and it's also a near-complete rewrite on my end :(
14:22:04  <bnoordhuis>yeah, that's maybe the one drawback
14:22:08  <bnoordhuis>okay, two drawbacks :)
14:22:39  <bnoordhuis>right now, uv-unix calls epoll_wait() several times if there are ARRAY_SIZE(events) evens ready
14:22:42  <bnoordhuis>*events
14:22:53  <bnoordhuis>which sometimes helps with throughput
14:23:19  <bnoordhuis>on the other hand, it's pretty rare to actually hit that limit
14:23:30  <bnoordhuis>ARRAY_SIZE(events) == 1024 right now
14:24:32  <bnoordhuis>getting back to the overarching topic, i think it's time for libuv2!
14:25:02  * AvianFluquit (Remote host closed the connection)
14:25:26  * paddybyersquit (Ping timeout: 252 seconds)
14:27:16  * kazuponjoined
14:27:55  * saghulquit (Read error: Operation timed out)
14:28:02  <piscisaureus_>bnoordhuis: yes :)
14:28:32  <piscisaureus_>bnoordhuis: I think handle priming would solve a lot of other problems in uv-win though so in that sense I'm not against it
14:28:56  <piscisaureus_>bnoordhuis: as for libuv 2 - I think the core model should be pull-based
14:29:35  <piscisaureus_>e.g. you call some function and it gives you a request or handle that has an event pending.
14:29:49  * groundwaterjoined
14:29:53  <piscisaureus_>the bells-and-whistles event loop should be sugar on top
14:30:44  <piscisaureus_>bnoordhuis: now to find some VCs to pay for that...
14:30:54  <bnoordhuis>piscisaureus_: you mean you keep calling uv_handle_t* uv_pull_event() until it exhausts the queue?
14:31:28  <bnoordhuis>oh VCs, just tell them we're building a twitter, but for pets
14:31:36  * saghuljoined
14:32:12  <bajtos>bnoordhuis: I don't have npm account credentials. I only used fact that you can change avatar image as long as you can receive emails on registered address
14:32:43  <piscisaureus_>bnoordhuis: yes - something like that
14:32:54  <MI6>libuv-node-integration: #77 UNSTABLE smartos-ia32 (1/588) osx-ia32 (1/588) smartos-x64 (3/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/77/
14:34:52  * AvianFlujoined
14:35:55  <MI6>joyent/node: Ben Noordhuis v0.10 * 9826b15 : doc: sending dgram handles only works on unix - http://git.io/-Y29Jg
14:37:24  <bnoordhuis>piscisaureus_: that would make it easy to write chicken scheme bindings. i'm all for it!
14:40:53  <piscisaureus_>bnoordhuis: jsut as a though experiment, we could also do away with handles-that-generate-events completely in the low-level layer
14:41:20  <piscisaureus_>bnoordhuis: basically read and and accept and recv would have to be requests
14:41:46  <piscisaureus_>bnoordhuis: it is something isaacs has asked for and ryah suggested it too when I last met him in person
14:42:05  <bnoordhuis>what's the rationale?
14:42:21  * c4milojoined
14:42:21  <piscisaureus_>well it's more consistent
14:42:39  <bnoordhuis>right, you wouldn't need uv_listen(), uv_read_stop(), etc.
14:42:52  <bnoordhuis>at least, not in their current incarnation
14:42:53  <piscisaureus_>instead of pausing and resuming read you would just "enqueue" a read or accept and when it returns you get data or an fd
14:43:06  <piscisaureus_>although we'd have to think carefully about how alloc_cb fits into the mix
14:44:00  <piscisaureus_>I think realistically you'd want to create a buffer pool and the embedder is responsible for making sure the buffer pool is never completely depleted
14:44:18  <piscisaureus_>and read() and recv() would take buffers from the buffer pool
14:44:45  <piscisaureus_>(IMO if any operating system would decide to do the right thing for once they should pick the same model)
14:46:04  <bnoordhuis>if only windows wasn't completion-based
14:46:10  <bnoordhuis>life would have been so much easier
14:46:39  <piscisaureus_>you should read the document bajtos' pointed out
14:46:41  <piscisaureus_>http://www.facebook.com/l.php?u=https%3A%2F%2Fdocs.google.com%2Fviewer%3Fa%3Dv%26pid%3Dforums%26srcid%3DMDUxODU4OTA1NTU1MzUxODE5MDQBMTA5MDUzNTI5Mzg2ODk0MjY5NjUBYWM5cnR1MEY4Z1FKATQBAXYy%26authuser%3D0&h=dAQFYX4kv
14:46:46  <bnoordhuis>yeah, i've seen it :)
14:46:57  <piscisaureus_>it basically says - linux gets much faster with a completion model
14:47:19  <piscisaureus_>but I'm scared of memory implications in a C10M scenario
14:47:33  <bnoordhuis>right, that's the issue with completion-driven i/o
14:47:34  <MI6>nodejs-v0.10: #218 UNSTABLE osx-x64 (1/588) linux-x64 (1/588) smartos-ia32 (1/588) smartos-x64 (2/588) http://jenkins.nodejs.org/job/nodejs-v0.10/218/
14:47:46  <bnoordhuis>btw, the flexsc paper that paper links to is quite interesting as well
14:47:59  <piscisaureus_>bnoordhuis: so that's why I would separate queuing read from supplying memory to read into
14:49:21  <bnoordhuis>food for thought
14:55:45  <MI6>nodejs-v0.10-windows: #48 UNSTABLE windows-x64 (8/588) windows-ia32 (6/588) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/48/
15:03:42  * kazuponquit (Remote host closed the connection)
15:13:35  * TooTallNatejoined
15:16:01  * hudgfactorjoined
15:16:17  * kuebkquit (Quit: Leaving.)
15:19:29  * AvianFluquit (Remote host closed the connection)
15:23:18  * kazuponjoined
15:23:54  * Somebodyjoined
15:24:33  * Somebodyquit (Remote host closed the connection)
15:26:16  * AvianFlujoined
15:27:31  * hzquit (Ping timeout: 264 seconds)
15:27:55  * leonvvjoined
15:28:19  <saghul>bnoordhuis, piscisaureus_ can either of you guys fix this comment here? https://github.com/joyent/libuv/blob/v0.10/test/test-osx-select.c#L65 creates a compilation problem on OSX 10.6
15:30:18  * piscisaureus_fires up github editor
15:32:28  <MI6>joyent/libuv: Bert Belder v0.10 * 081f701 : test: use c-style comments - http://git.io/0YlGog
15:32:36  <piscisaureus_>yup, that's my github editor
15:33:23  <bnoordhuis>aw
15:33:25  <bnoordhuis>preempted
15:33:30  * bnoordhuisforce-pushes
15:33:37  * bnoordhuisdoesn't really
15:34:19  <bnoordhuis>it's okay, bert can use the commit
15:34:27  <bnoordhuis> git shortlog -ns | head -4
15:34:27  <bnoordhuis> 864 Ben Noordhuis
15:34:27  <bnoordhuis> 576 Bert Belder
15:34:27  <bnoordhuis> 337 Ryan Dahl
15:34:27  <bnoordhuis> 136 Igor Zinkovsky
15:34:39  <bnoordhuis>still a bit of catching up to do, bertje
15:34:48  <MI6>libuv-v0.10: #83 UNSTABLE smartos (2/186) windows (5/187) http://jenkins.nodejs.org/job/libuv-v0.10/83/
15:34:55  * benoitcquit (Changing host)
15:34:55  * benoitcjoined
15:35:08  <saghul>thanks!
15:35:35  <`3rdEden>bnoordhuis: it's not the amount of commits that count but the quality of the commits ;)
15:36:23  * `3rdEdenchanged nick to `3E|BRB
15:37:07  <bnoordhuis>i've heard similar comments in other contexts
15:37:10  <bnoordhuis>something about size
15:39:30  <MI6>libuv-v0.10-gyp: #46 UNSTABLE windows-x64 (4/187) linux-ia32 (3/186) linux-x64 (1/186) windows-ia32 (3/187) smartos-x64 (2/186) smartos-ia32 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/46/
15:46:42  * AvianFluquit (Remote host closed the connection)
15:50:17  <MI6>libuv-node-integration: #78 UNSTABLE smartos-ia32 (1/588) osx-ia32 (1/588) smartos-x64 (3/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/78/
15:51:55  * defunctzombie_zzchanged nick to defunctzombie
15:54:10  * AvianFlujoined
16:01:19  * bnoordhuisquit (Ping timeout: 245 seconds)
16:01:52  * dapjoined
16:14:07  * leonvvquit (Remote host closed the connection)
16:20:49  * `3E|BRBquit (Remote host closed the connection)
16:30:13  * bnoordhuisjoined
16:31:34  * AvianFluquit (Remote host closed the connection)
16:34:25  * TooTallNatequit (Read error: Operation timed out)
16:35:29  * paddybyersjoined
16:42:10  * inolenquit (Quit: Leaving.)
16:48:19  * timoxleyquit (Quit: Computer has gone to sleep.)
16:48:31  * paddybyersquit (Ping timeout: 264 seconds)
16:55:00  * Somebodyjoined
16:56:44  * csaohquit (Quit: csaoh)
16:58:57  * benoitcquit (Excess Flood)
16:59:40  * amartensjoined
17:01:38  * benoitcjoined
17:08:03  * qardjoined
17:11:27  * kazuponquit (Remote host closed the connection)
17:21:36  * defunctzombiechanged nick to defunctzombie_zz
17:23:58  * trapitojoined
17:24:02  <trapito>hi
17:25:30  * Somebodyquit (Remote host closed the connection)
17:25:59  <trapito>anyone available for a quick question regarding shutdown handlers and uv_close? basically i'm calling uv_close from a shutdown handler and would like to know what behavior to expect, however, i wasn't able to find out (didn't got as far as reading the code)
17:26:08  <trapito>didn't get*
17:28:35  * hzjoined
17:28:35  * hzquit (Changing host)
17:28:35  * hzjoined
17:29:31  * AvianFlujoined
17:30:25  <piscisaureus_>trapito: yes you can close from a shutdown handler
17:30:44  <piscisaureus_>trapito: however that means that you won't be able to read any data after that
17:30:55  <trapito>piscisaureus_: and as long as the 2 tcp handles run in the same loop i shouldn't have any problems right?
17:31:31  <piscisaureus_>trapito: well some time passes between the write completing and the other socket reading it
17:31:46  <piscisaureus_>(if I am reading you right and you are creating a loopback connection)
17:32:23  <trapito>not really, i'm listening and bridging data from 2 clients, when one closes the connection i close the connection to the other one
17:33:18  <trapito>so, i guess my main concern is, as long as both clients run in the same loop callbacks should be "serialized" right?
17:35:07  * brsonjoined
17:37:53  * `3rdEdenjoined
17:38:01  * dannycoatesjoined
17:38:04  * inolenjoined
17:38:57  * bajtosquit (Quit: bajtos)
17:41:17  * bajtosjoined
17:47:49  <piscisaureus_>trapito: oh- yes absolutely
17:48:13  <piscisaureus_>callbacks are always made with uv_run immediately underneath and none of your code in between
17:48:36  <piscisaureus_>I guess the only exception is uv_walk but that's kind of obvious if you use it
17:55:42  <trapito>great, thanks piscisaureus_!
17:56:27  <trapito>is there any way for me to read about event loops without actually reading the sources?
17:56:45  <trapito>i'd like to know if extra event loops run as threads for example
17:57:25  <trapito>actually that's a mistranslated expression (for example) =P
18:10:24  * kevinswiberquit (Remote host closed the connection)
18:12:58  <piscisaureus_>trapito: no extra event loops dont implicitly run in a thread.
18:13:21  <piscisaureus_>trapito: but you probably want to create one for it
18:13:50  <piscisaureus_>trapito: http://nikhilm.github.io/uvbook/ might help
18:14:00  <piscisaureus_>isaacs: https://gist.github.com/piscisaureus/5672440 <-- why the if / else ?
18:15:02  <isaacs>piscisaureus_: so that you can drop a node.exe in that same folder, and it'll use that one.
18:15:08  <isaacs>piscisaureus_: i don't remember why this was important once upon a time.
18:15:23  <piscisaureus_>isaacs: sounds kinda nuts :)
18:15:34  <isaacs>piscisaureus_: yeah, i'd be surprised if anyonewas actually using it
18:15:36  <piscisaureus_>isaacs: but even more - if there is node.exe in the current folder then windows will run that anyway
18:15:49  <piscisaureus_>because windows always tries the current dir first
18:15:49  <trapito>great, do you think separating the loops by cilent type would be premature optimization?
18:15:51  <isaacs>piscisaureus_: not the cwd
18:16:02  <isaacs>piscisaureus_: the ./node_modules/.bin folder
18:16:07  <isaacs>piscisaureus_: where the .cmd file is
18:16:14  <piscisaureus_>oh - right I see
18:16:51  <piscisaureus_>isaacs: still it's kind of an odd feater
18:16:53  <piscisaureus_>*feature
18:17:04  <isaacs>yeah
18:17:10  <isaacs>i think it was some kind of azure workaround somethingorother
18:17:12  <piscisaureus_>that I've always overlooked but coming to think of it, doesn't seem to make such sense :)
18:17:34  <piscisaureus_>but awlright if you say so then I guess we can just leave it there
18:17:36  <isaacs>i remember a conversation with ryan and someone about this a while ago
18:17:38  <isaacs>yeah
18:17:42  <isaacs>it's not hurting anyone :)
18:18:00  <piscisaureus_>ok kewl
18:23:55  <trapito>piscisaureus_: please correct me if i'm wrong, but according to the sources, uv_close does actually stop any activity and closes the fd immediately right?
18:31:16  * normanmquit (Quit: Computer has gone to sleep.)
18:32:04  <piscisaureus_>trapito: yes
18:34:40  * defunctzombie_zzchanged nick to defunctzombie
18:35:13  * normanmjoined
18:59:33  <bnoordhuis>trapito: correct
18:59:57  <bnoordhuis>oh, didn't see piscisaureus_ had replied
19:06:16  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/5232bbb <- review?
19:07:47  <saghul>piscisaureus_ did you land the (un)fixed idle handles thing on windows?
19:13:11  * kazuponjoined
19:17:06  <piscisaureus_>saghul: not yet, should I fire up the github editor again
19:18:40  <hudgfactor>bnoordhuis and tjfontaine -- thanks for the help yesterday, I seem to have poll working now and node 0.10 running on QNX.
19:19:25  <bnoordhuis>hudgfactor: sweet. what does `make test` look like?
19:19:41  <bnoordhuis>also, i'm surprised you got node/v8 up and running. what arch is it?
19:20:52  * kazuponquit (Ping timeout: 276 seconds)
19:20:54  * mikealjoined
19:21:14  <hudgfactor>bnoordhuis: I haven't tried, but am pretty sure it won't get very far. To be clear, I didn't do most of the port -- a 0.6 port was here when I started and a half-done 0.8 port was given to me.
19:21:23  <hudgfactor>armv7
19:23:22  <saghul>piscisaureus_ fire it up while it's hot! :-)
19:24:17  <hudgfactor>I've been pushing node here but not really getting much traction. The company is pretty old-school. There's a team at Audi that have benefitted by my port though, and they'll be happy to have a 0.10 that works. Maybe node will be in Audi's in the next few years. :)
19:24:55  * normanmquit (Quit: Computer has gone to sleep.)
19:25:40  * paddybyersjoined
19:26:22  * bajtosquit (Quit: bajtos)
19:27:15  <bnoordhuis>hah, that'd be sweet
19:27:29  <bnoordhuis>what company are you working for, hudgfactor?
19:27:44  <hudgfactor>The company is called QNX as well.
19:27:53  <hudgfactor>QNX is an embedded real-time OS.
19:28:12  <bnoordhuis>ah, didn't know you worked for them
19:28:25  <bnoordhuis>if that was discussed yesterday, i must've missed it
19:28:31  <hudgfactor>Yeah, up in Ottawa. No, didn't mention it.
19:28:46  <hudgfactor>QNX is owned by BlackBerry these days.
19:28:52  <hudgfactor>It's the OS for their new phones.
19:29:39  <bnoordhuis>what hardware do blackberry phones use?
19:29:46  <piscisaureus_>does qnx have anything but select() ?
19:29:49  <hudgfactor>The original node port came from the Torch browser team. They were considering it for a back-end for HTML5-based apps on the phone. In the end they went with a headless Webkit for whatever reason.
19:30:02  <bnoordhuis>or rather, what architectures are you targeting?
19:30:17  * loladirojoined
19:30:54  <hudgfactor>BB10 phones are arm devices. But I actually work for the marketing department of QNX, doing mostly automotive concept demos.
19:31:42  <hudgfactor>We hacked up a Bentley for CES this year. I used Node to do a few things, including getting status and controlling the car (ie. roll the windows up and down) from a web app.
19:31:51  <bnoordhuis>nice
19:32:32  <bnoordhuis>if you send me a bentley, i'll see if i can get node running better on it :)
19:32:43  <piscisaureus_>hudgfactor: http://www.qnx.com/developers/docs/6.3.0SP3/neutrino/lib_ref/i/ionotify.html <-- is that "the" scalable event multiplexer?
19:32:53  <hudgfactor>QNX has another mechanism besides select() but I don't know if it's really meant for this. poll/select are okay as far as I'm concerned because it's not like I'm serving thousands of connections.
19:33:07  <hudgfactor>piscisaureus_: yes, that's the one. I know almost nothing about it though.
19:33:38  <hudgfactor>bnoordhuis: lol, I'll see what I can do. :)
19:35:41  <bnoordhuis>in all seriousness, if you need some help getting the qnx port going, let me know
19:37:14  <hudgfactor>Thanks, that's awesome.
19:37:37  <hudgfactor>Will you be at NodeConf? I did manage to convince QNX to send me to it this year.
19:38:25  <bnoordhuis>not me. most of the other core people will be there though
19:38:40  <piscisaureus_>I will be and so will isaacs
19:38:54  <piscisaureus_>I'm guessing tjfontaine too
19:39:07  <tjfontaine>I will be at nodeconf, yes
19:39:18  <hudgfactor>That's cool, well it's nice to have talked to you guys. I've known a lot of your names for quite a while now. :)
19:40:37  <hudgfactor>If you're interested in that Bentley, here's a video. http://www.youtube.com/watch?v=SSwRsJLSXjY (I'm not in it)
19:40:52  <hudgfactor>kinda long
19:41:19  * paddybyersquit (Ping timeout: 256 seconds)
19:42:47  * brsonquit (Ping timeout: 252 seconds)
19:43:13  <bnoordhuis>piscisaureus_: https://github.com/bnoordhuis/libuv/commit/c0a1206
19:43:27  <bnoordhuis>please test. i didn't
19:45:24  <piscisaureus_>bnoordhuis heh
19:46:43  * kazuponjoined
19:48:08  * defunctzombiechanged nick to defunctzombie_zz
19:48:24  * V1joined
19:50:49  * qard1joined
19:51:10  <bnoordhuis>piscisaureus_: lgty?
19:52:18  * kazuponquit (Ping timeout: 264 seconds)
19:53:27  * V1changed nick to `3E
19:53:50  * loladiro_joined
19:54:02  * loladiroquit (Read error: Operation timed out)
19:54:02  * loladiro_changed nick to loladiro
19:54:40  * groundwaterquit (Ping timeout: 276 seconds)
19:54:41  * `3rdEdenquit (Ping timeout: 276 seconds)
19:54:41  * ircretaryquit (Ping timeout: 276 seconds)
19:54:43  * qardquit (Ping timeout: 276 seconds)
19:58:02  * defunctzombie_zzchanged nick to defunctzombie
20:03:01  * defunctzombiechanged nick to defunctzombie_zz
20:03:35  <piscisaureus_>bnoordhuis: sorry I was afk
20:03:48  <piscisaureus_>bnoordhuis: lgtm but didn't test
20:03:51  <piscisaureus_>let's ask jenkins
20:04:09  * AvianFluquit (Remote host closed the connection)
20:04:18  <tjfontaine>jenkins is a bastard, he rarely gives you the answer you want
20:04:33  <MI6>joyent/libuv: piscisaureus created branch jenkins-please-test-this-for-bnoordhuis - http://git.io/PzrGMw
20:06:48  <tjfontaine>piscisaureus_: I'm not sure what you expected that to do, but I'll make it happen :)
20:08:43  <cjd>=]
20:13:20  <MI6>libuv-review: #1 UNSTABLE windows-x64 (5/188) windows-ia32 (4/188) smartos-ia32 (2/187) smartos-x64 (2/187) http://jenkins.nodejs.org/job/libuv-review/1/
20:13:27  <tjfontaine>piscisaureus_: ^^
20:15:34  * TooTallNatejoined
20:15:44  <bnoordhuis>Assertion failed in test\test-timer.c on line 282: 0 == uv_run(uv_default_loop(), UV_RUN_ONCE) <- aw :(
20:16:25  * AvianFlujoined
20:16:40  * defunctzombie_zzchanged nick to defunctzombie
20:26:08  <MI6>joyent/libuv: Wynn Wilkes v0.10 * b4c658c : darwin: make uv_fs_sendfile() respect length param - http://git.io/z-l9YA
20:28:35  * c4miloquit (Remote host closed the connection)
20:29:01  * c4milojoined
20:30:53  <MI6>libuv-v0.10: #84 UNSTABLE smartos (2/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/84/
20:32:00  <MI6>libuv-v0.10-gyp: #47 UNSTABLE windows-x64 (5/187) windows-ia32 (5/187) smartos-x64 (2/186) smartos-ia32 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/47/
20:33:42  * c4miloquit (Ping timeout: 264 seconds)
20:35:45  <bnoordhuis>tjfontaine, isaacs: any objections to me landing code-cleanup-potpourri?
20:35:59  <tjfontaine>bnoordhuis: I'm all for it
20:36:44  <bnoordhuis>okay then, there she goes
20:37:32  <bnoordhuis>i'll just run debug and release tests one more time, just to be sure :)
20:38:04  <tjfontaine>you can push to a review branch in the joyent/node and we can do a wider test
20:38:10  <piscisaureus_>tjfontaine: so can i now make jenkins do anything by pushing to some branch?
20:38:13  <bnoordhuis>good idea
20:38:43  <MI6>joyent/node: bnoordhuis created branch code-cleanup-potpourri - http://git.io/-2IkVw
20:38:44  <tjfontaine>piscisaureus_: if you're willing to push a button, I will add a plugin to jenkins to match a branch name
20:39:02  <piscisaureus_>tjfontaine: if it isn't too hard
20:39:39  <tjfontaine>bnoordhuis: moment
20:39:43  <tjfontaine>piscisaureus_: ya, it's pretty simple
20:39:58  <piscisaureus_>tjfontaine: so will there be an api for that? :)
20:40:07  <piscisaureus_>tjfontaine: just curious
20:40:16  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:40:36  <isaacs>bnoordhuis: land at will
20:41:21  <isaacs>is there any reason why we even have uv_fs_sendfile?
20:41:28  <isaacs>do any uv-using platforms use it?
20:41:39  <bnoordhuis>isaacs: platforms or projects?
20:41:44  <isaacs>bnoordhuis: whatever.
20:41:48  <bnoordhuis>as to why, well, you know
20:41:49  <tjfontaine>piscisaureus_: http://jenkins.nodejs.org/job/libuv-review/build?delay=0sec is the clicky way, but there's also buildWithParameters where you can pass it as a query string, but I'll just make it automagic, it'll be ready tomorrow
20:41:59  <bnoordhuis>libev had a sendfile thingy so we added it for compat's sake
20:42:04  <isaacs>bnoordhuis: i see.
20:42:29  <isaacs>bnoordhuis: it seems like sendfile is, in practice, awkward at best.
20:42:50  <bnoordhuis>yeah. it has it uses but it's decidedly non-standard and quirky
20:42:58  <isaacs>i'd love to use it in st
20:43:12  <bnoordhuis>st?
20:43:17  <isaacs>but i'm not sure how iwould without giving up caching
20:43:23  <isaacs>bnoordhuis: http://npm.im/st
20:43:46  <bnoordhuis>oh, right
20:43:50  * c4milojoined
20:44:08  <isaacs>bnoordhuis: static file thingie
20:44:13  <bnoordhuis>that's the thing with sendfile, you're putting your faith in your os's disk cache
20:44:19  <isaacs>right
20:44:57  <isaacs>seems like operating systems should implement some thing like sendfile that's not so stupid and quirky
20:45:04  <isaacs>like a low-level kernel pipe
20:45:12  <isaacs>like a low-level kernel stream.pipe() that is
20:45:22  <bnoordhuis>splice() :)
20:45:27  <bnoordhuis>linux-only unfortunately
20:45:31  <isaacs>but generic, not limited to file->socket
20:45:40  <isaacs>also file->file, and socket->socket and socket->file
20:45:42  * brucemquit (Ping timeout: 264 seconds)
20:45:46  <bnoordhuis>yeah, that's splice()
20:45:54  <bnoordhuis>it works with most files
20:45:55  * TooTallNatejoined
20:46:01  <bnoordhuis>sendfile() is actually splice() under the hood
20:46:03  <isaacs>who's working on adding splice to darwin and sunos?
20:46:10  <bnoordhuis>i'm guessing no one
20:46:24  * hudgfactorquit (Quit: hudgfactor)
20:46:32  <bnoordhuis>you could probably interest your co-workers to get it into smartos
20:46:36  <bnoordhuis>but darwin... lost cause
20:46:47  <tjfontaine>noone uses darwin in production anyway :)
20:47:05  <tjfontaine>bnoordhuis: this branch is based on master or v0.10?
20:47:12  <bnoordhuis>tjfontaine: v0.10
20:47:14  * brucemjoined
20:47:16  <tjfontaine>hm ok
20:47:31  <bnoordhuis>i can land it in master, no problem
20:47:40  <tjfontaine>no
20:48:00  <tjfontaine>I'm seeing debugger tests fail on linux, which I'm used to seeing mostly fail on master right now, not v0.10
20:48:10  * kazuponjoined
20:48:31  <bnoordhuis>they regularly fail for me both with master and v0.10
20:48:41  <bnoordhuis>test-debugger-client and friends right?
20:48:55  <MI6>libuv-node-integration: #79 UNSTABLE smartos-ia32 (1/588) osx-ia32 (1/588) smartos-x64 (1/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/79/
20:49:27  <tjfontaine>bnoordhuis: ya, but see they didn't fail in that build right there :)
20:51:53  <tjfontaine>bnoordhuis: http://jenkins.nodejs.org//job/nodejs-review/DESTCPU=ia32,label=linux/lastCompletedBuild//tapTestReport/test.tap-499/
20:52:22  <MI6>joyent/libuv: piscisaureus created branch idle-semantics - http://git.io/R-KFNg
20:52:54  * kazuponquit (Ping timeout: 264 seconds)
20:53:03  <piscisaureus_>bnoordhuis: ^review?
20:53:19  <bnoordhuis>piscisaureus_: one sec, checking tj's failing test
20:53:59  <piscisaureus_>tjfontaine: https://gist.github.com/piscisaureus/5673766
20:54:05  <piscisaureus_>tjfontaine: is what I get
20:54:53  <piscisaureus_>tjfontaine: oh now it works...
20:55:03  <tjfontaine>k
20:55:08  <bnoordhuis>tjfontaine: interesting, it worked monday :)
20:55:13  <tjfontaine>bnoordhuis: :)
20:55:31  * brsonjoined
20:55:38  <bnoordhuis>it's the last patch, the writeQueueSize optimize thingy
20:55:47  <tjfontaine>what style branch names do you want me to key off to trigger?
20:55:59  <tjfontaine>is (review|jenkins) enough?
20:55:59  <bnoordhuis>which i benchmarked at having a +/- 0% performance impact in the grand scheme of things
20:56:03  <bnoordhuis>*as having
20:56:20  <bnoordhuis>tjfontaine: yeah, works for me
20:56:25  <tjfontaine>k
20:57:25  <bnoordhuis>i think i'm going to ditch that writeQueueSize thing. looks like it's not worth it
20:57:41  * c4miloquit (Remote host closed the connection)
20:57:49  <piscisaureus_>tjfontaine: sound good
20:58:06  <tjfontaine>k
20:58:07  <piscisaureus_>tjfontaine: although, really you could just any branch. Not many people create branches here.
20:58:14  <MI6>libuv-review: #2 UNSTABLE windows-x64 (3/189) windows-ia32 (3/189) smartos-ia32 (2/188) smartos-x64 (2/188) http://jenkins.nodejs.org/job/libuv-review/2/
20:58:15  <bnoordhuis>it sometimes seems to give a ~1% speedup but http_simple is so jittery, it's hard to say for sure
20:59:46  <tjfontaine>I wish I could filter branches easier
21:00:53  * paddybyersjoined
21:01:55  <MI6>nodejs-review: #1 UNSTABLE linux-ia32 (6/588) smartos-x64 (4/588) osx-ia32 (1/588) linux-x64 (2/588) smartos-ia32 (2/588) windows-x64 (9/588) windows-ia32 (11/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/nodejs-review/1/
21:02:52  <MI6>libuv-review: #3 UNSTABLE windows-x64 (3/189) windows-ia32 (5/189) smartos-ia32 (2/188) smartos-x64 (2/188) http://jenkins.nodejs.org/job/libuv-review/3/
21:02:58  * c4milojoined
21:04:09  <piscisaureus_>bnoordhuis: test result for idle-semantics patch -> http://jenkins.nodejs.org/job/libuv-review/2/testReport/
21:04:18  <piscisaureus_>bnoordhuis: I can't possibly imagine it not to be correct.
21:05:30  * paddybyersquit (Ping timeout: 264 seconds)
21:07:16  <bnoordhuis>piscisaureus_: looks okay to me
21:07:22  <MI6>libuv-review: #4 UNSTABLE windows-x64 (3/189) windows-ia32 (3/189) smartos-ia32 (2/188) smartos-x64 (2/188) http://jenkins.nodejs.org/job/libuv-review/4/
21:07:50  * isaacsfooding
21:07:52  * isaacs&
21:07:52  <LOUDBOT>I SHALL TELL YOU TO GROW A PAIR
21:08:11  <tjfontaine>LOUDBOT: YOU TELL EM
21:08:11  <LOUDBOT>tjfontaine: AUSTIN POWERS COMES FROM A TIME BEFORE UNIX
21:09:31  <txdv>before 1969?
21:09:48  * `3Equit (Remote host closed the connection)
21:10:20  <MI6>joyent/libuv: Bert Belder master * b5cd78e : test: reflect new idle semantics in test (+1 more commits) - http://git.io/XWTEOA
21:14:38  <MI6>libuv-master: #98 UNSTABLE windows (4/189) smartos (2/188) http://jenkins.nodejs.org/job/libuv-master/98/
21:15:04  * KiNgMaRquit (Ping timeout: 245 seconds)
21:15:16  <MI6>joyent/node: Ben Noordhuis master * 28659ab : Merge remote-tracking branch 'origin/v0.10' (+8 more commits) - http://git.io/0sb8MA
21:15:33  <bnoordhuis>^ the merge breaks simple/test-tls-client-destroy-soon and i don't know why
21:15:52  <bnoordhuis>there was a conflict in lib/tls.js which i resolved
21:16:24  <bnoordhuis>lib/tls.js's diff between v0.10 and master is uninteresting
21:16:29  <MI6>libuv-master-gyp: #37 UNSTABLE smartos-x64 (3/188) windows-ia32 (5/189) smartos-ia32 (2/188) windows-x64 (3/189) http://jenkins.nodejs.org/job/libuv-master-gyp/37/
21:16:39  <bnoordhuis>indutny: around?
21:16:41  <tjfontaine>bnoordhuis: could be that libuv-master needs libuv-v0.10 merged into it
21:17:02  <bnoordhuis>that's possible
21:17:45  * KiNgMaRjoined
21:18:23  <piscisaureus_>bnoordhuis: odd. the test passes here
21:18:31  <piscisaureus_>consistently
21:18:37  <MI6>libuv-master: #99 UNSTABLE windows (4/189) smartos (3/188) http://jenkins.nodejs.org/job/libuv-master/99/
21:19:11  <bnoordhuis>piscisaureus_: after the merge i just did?
21:19:36  <piscisaureus_>bnoordhuis: no
21:20:29  <bnoordhuis>okay. at least it's consistent :)
21:20:44  <piscisaureus_>bnoordhuis: you merged node.
21:21:03  <piscisaureus_>bnoordhuis: I was looking at libuv timer_run_once
21:21:09  * defunctzombiechanged nick to defunctzombie_zz
21:21:17  <trevnorris>bnoordhuis: why is it uv_idle needs to be stopped after receiving a response? I mean, starting it in NeedTickCallback then stopping it in Spin eludes me.
21:21:36  <trevnorris>s/receiving a response/calling the callback
21:22:41  * rendarquit
21:24:14  * KiNgMaRquit (Ping timeout: 245 seconds)
21:25:11  * defunctzombie_zzchanged nick to defunctzombie
21:26:46  * KiNgMaRjoined
21:27:17  * defunctzombiechanged nick to defunctzombie_zz
21:27:22  * defunctzombie_zzchanged nick to defunctzombie
21:27:47  <bnoordhuis>trevnorris: because an active idle watcher stops libuv from sleeping in epoll_wait() / kevent() / etc.
21:28:09  <bnoordhuis>try it, if you don't call uv_idle_stop(), node will start using 100% cpu
21:30:11  <trevnorris>heh, just did. thanks. :)
21:30:38  <MI6>nodejs-master: #236 UNSTABLE smartos-x64 (10/604) smartos-ia32 (7/604) linux-x64 (3/604) osx-x64 (1/604) osx-ia32 (3/604) linux-ia32 (3/604) http://jenkins.nodejs.org/job/nodejs-master/236/
21:30:53  <bnoordhuis>git rerere is the best
21:31:06  <trevnorris>never used it
21:31:17  <MI6>joyent/libuv: Bert Belder jenkins-please-test-this-for-bnoordhuis * 349b322 : test (+1 more commits) - http://git.io/-eYJjw
21:31:38  <bnoordhuis>botched a merge with conflicts, did a git reset --hard to roll back, did the merge again and it remembered all my previous fixups
21:31:45  * bnoordhuishugs rerere
21:32:04  <tjfontaine>heh
21:32:27  <MI6>joyent/libuv: Ben Noordhuis master * 8ef9592 : Merge remote-tracking branch 'origin/v0.10' (+23 more commits) - http://git.io/wmMhJg
21:32:27  <trevnorris>well, that's happened to me more than once. time to go take a look.
21:33:12  <bnoordhuis>trevnorris: git config --global rerere.enabled true
21:33:30  <bnoordhuis>that's all you need really, the defaults work okay
21:33:40  <trevnorris>coolio. done
21:33:48  <MI6>libuv-node-integration: #80 UNSTABLE smartos-ia32 (10/604) osx-ia32 (2/604) smartos-x64 (13/604) linux-x64 (1/604) linux-ia32 (3/604) osx-x64 (3/604) http://jenkins.nodejs.org/job/libuv-node-integration/80/
21:34:19  <bnoordhuis>ah, i thought that was my merge ^
21:34:42  <tjfontaine>happened too quickly for that
21:34:54  <bnoordhuis>yeah, i was kind of surprise
21:34:57  <bnoordhuis>*surprised
21:35:02  <bnoordhuis>with good reason, it turns out
21:35:44  <bnoordhuis>upgrading libuv doesn't fix the failing tls test :(
21:35:49  <tjfontaine>shame
21:37:10  <trevnorris>bnoordhuis: so you think there is a way to remove the "needTickCallback" fron nextTick (e.g. needing to start/stop uv_idle)?
21:37:20  <trevnorris>actually, don't even know if I'm asking the right question
21:38:00  * AvianFluquit (Remote host closed the connection)
21:38:27  <MI6>nodejs-master-windows: #45 UNSTABLE windows-x64 (18/604) windows-ia32 (16/604) http://jenkins.nodejs.org/job/nodejs-master-windows/45/
21:38:40  <MI6>libuv-master-gyp: #38 UNSTABLE smartos-x64 (2/188) windows-ia32 (3/189) smartos-ia32 (3/188) osx-x64 (1/189) windows-x64 (3/189) http://jenkins.nodejs.org/job/libuv-master-gyp/38/
21:39:35  <MI6>libuv-master: #100 UNSTABLE windows (4/189) smartos (2/188) linux (1/188) http://jenkins.nodejs.org/job/libuv-master/100/
21:40:26  * dominictarrquit (Quit: dominictarr)
21:42:05  * dominictarrjoined
21:42:46  <piscisaureus_>tjfontaine: :(
21:42:49  <piscisaureus_>tjfontaine: http://jenkins.nodejs.org/job/libuv-review/6/console
21:43:25  <tjfontaine>looks like a leading ' ' was there?
21:43:59  <tjfontaine>hm
21:44:13  <piscisaureus_>tjfontaine: http://jenkins.nodejs.org/job/libuv-review/7/console maybe more info?
21:44:52  <tjfontaine>this build is working
21:45:05  <tjfontaine>but you broke the build :)
21:45:13  <piscisaureus_>ah
21:45:15  <piscisaureus_>:)
21:45:16  <piscisaureus_>shame
21:45:36  <tjfontaine>:)
21:46:10  <MI6>libuv-review: #7 FAILURE windows-x64 (3/190) windows-ia32 (3/190) http://jenkins.nodejs.org/job/libuv-review/7/
21:46:47  <piscisaureus_>tjfontaine: ah. I wasn't interested in the unix output actually
21:47:30  <indutny>bnoordhuis: yes?
21:47:55  <tjfontaine>piscisaureus_: you can now also see the result in http://jenkins.nodejs.org/job/libuv-pullrequest/125/
21:48:35  <piscisaureus_>tjfontaine: does the pull request bot auto-retest when I update my PR?
21:48:41  <tjfontaine>yes
21:48:49  * kazuponjoined
21:48:52  <tjfontaine>but it doesn't announce here in the channel
21:48:59  <bnoordhuis>indutny: i merged node v0.10 into master and it broke simple/test-tls-client-destroy-soon
21:49:08  <indutny>huh?
21:49:11  <tjfontaine>piscisaureus_: but it will update the github PR page when it's done
21:49:11  <indutny>what's happening?
21:49:20  <MI6>joyent/libuv: Ben Noordhuis jenkins-please-test-this-for-bnoordhuis * a321a4d : unix, windows: run expired timers in UV_RUN_ONCE mode - http://git.io/0Amtcw
21:49:47  <bnoordhuis>indutny: dunno. there was a conflict in lib/tls.js because of 4f14221
21:50:05  <bnoordhuis>but i resolved it and the affected bit is identical to v0.10 now
21:50:39  <indutny>hm...
21:50:42  <indutny>interesting
21:50:58  <bnoordhuis>indutny: https://gist.github.com/bnoordhuis/f842cd0c32da19f9a7bb <- error
21:51:45  <indutny>may be streams2?
21:51:46  <indutny>idk
21:51:51  <indutny>I'll look into it
21:51:59  <indutny>but tls.js seems to be almost identical to v0.10
21:52:03  <indutny>except some logging stuff
21:52:11  <indutny>and session timeout
21:52:47  <indutny>anyway, let me build it and try it myself
21:52:58  <MI6>libuv-node-integration: #81 UNSTABLE smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (11/604) linux-x64 (1/604) linux-ia32 (1/604) osx-x64 (3/604) http://jenkins.nodejs.org/job/libuv-node-integration/81/
21:53:03  <bnoordhuis>yeah, that's the thing - i can't spot any significant difference
21:53:21  * kazuponquit (Ping timeout: 256 seconds)
21:53:30  <indutny>bnoordhuis: I think it might be `prefinish` stream_writable change
21:53:37  <indutny>well
21:53:43  <indutny>all other tests are passing, right?
21:53:54  <bnoordhuis>yep
21:54:08  <bnoordhuis>happens on both darwin and linux btw
21:54:14  <bnoordhuis>and fwiw
21:55:06  <MI6>joyent/libuv: Ben Noordhuis jenkins-please-test-this-for-bnoordhuis * c0a1206 : unix, windows: run expired timers in UV_RUN_ONCE mode - http://git.io/1w8psw
21:57:27  * c4miloquit (Remote host closed the connection)
21:58:06  * pachetquit (Quit: leaving)
21:58:24  <indutny>ah,
21:58:28  <indutny>I think its cork/uncork
21:58:55  <indutny>no
21:58:57  <indutny>it isn't
22:01:36  <indutny>ok, there is a bug...
22:01:40  <indutny>but fixing it doesn't fix problem
22:02:40  <bnoordhuis>haha
22:03:07  <indutny>ok, there're two bugs
22:03:11  <indutny>fixing them both helps a lot
22:03:22  <indutny>isaacs: our optimization didn't work out
22:03:43  <isaacs>indutny: oh?
22:03:46  <isaacs>indutny: writev you mean?
22:03:47  <indutny>yeah
22:03:48  <indutny>no
22:03:49  * isaacsfg
22:03:55  <isaacs>which optimization?
22:03:56  <indutny>latest tls thing
22:04:02  <indutny>process.nextTick removal
22:04:03  <indutny>in my code
22:04:14  <isaacs>indutny: what's the problem?
22:04:16  <indutny>so here is the problem
22:04:28  <indutny>hm...
22:04:34  <indutny>wait, I need some time to fully understand it
22:04:44  <indutny>but the thing is that wrapping it in setImmediate fixes it
22:05:03  <isaacs>indutny: why does setImmediate work but nextTick doesn't?
22:05:08  <indutny>well
22:05:12  <indutny>nextTick works too
22:05:14  <isaacs>indutny: what is the symptom?
22:05:17  <indutny>it doesn't wokr on the same tick
22:05:17  <isaacs>do not use setImmediate.
22:05:23  <indutny>isaacs: connection is closed too early
22:05:30  <indutny>because of finish event
22:05:41  <indutny>and its happening because we're not reading from socket
22:05:45  <indutny>ah
22:05:53  <indutny>I know how to fix it without introducing nextTick
22:07:21  * timoxleyjoined
22:09:24  <trevnorris>isaacs: fyi, i've started working on removal of maxTickDepth
22:09:37  <MI6>libuv-node-integration: #82 UNSTABLE smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (6/604) linux-x64 (2/604) linux-ia32 (3/604) osx-x64 (2/604) http://jenkins.nodejs.org/job/libuv-node-integration/82/
22:09:51  <isaacs>trevnorris: rad
22:09:59  <isaacs>trevnorris: shoudln't be too hard, right?
22:10:06  <isaacs>trevnorris: just let it keep looping forever.
22:10:06  <trevnorris>going back, there are a couple things that seem so painfully obvious, i'm embarrassed I didn't seem it before.
22:10:12  <isaacs>trevnorris: ha
22:10:14  <isaacs>that happens
22:10:16  <isaacs>means you're learning :)
22:10:27  <trevnorris>isaacs: only kicker is if a domain error callback also errors
22:10:40  <trevnorris>still trying to figure out that case
22:11:41  <isaacs>trevnorris: i see
22:13:56  * loladiroquit (Read error: Operation timed out)
22:14:49  <trevnorris>isaacs: thoughts on the last half of my comment here http://git.io/o7TmBA
22:15:04  <MI6>joyent/node: Ben Noordhuis master * c188a75 : buffer: guard against integer overflow (+6 more commits) - http://git.io/asvrbw
22:16:02  <piscisaureus_>bnoordhuis: I couldn't reproduce your timer_run_once failure even once
22:16:08  <piscisaureus_>bnoordhuis: and jenkins couldn't either
22:16:36  <piscisaureus_>(not even when running it in a loop and varying build flags)
22:17:19  <bnoordhuis>piscisaureus_: really? odd, because jenkins was the one who reported it for win x64
22:17:44  <bnoordhuis>and ia32 too, it seems
22:17:44  <bnoordhuis>http://jenkins.nodejs.org//job/libuv-review/1/DESTCPU=ia32,label=windows//tapTestReport/test.tap-79/
22:17:45  <piscisaureus_>bnoordhuis: I know - but then I made it rebuild it a couple times more but it doesn't repeat
22:17:51  <bnoordhuis>weird
22:17:55  <bnoordhuis>should i just land it then?
22:18:03  <piscisaureus_>bnoordhuis: did you see the update_time comment
22:18:11  <piscisaureus_>bnoordhuis: but yeah - just land
22:18:32  <bnoordhuis>ah, i see it now
22:18:45  <bnoordhuis>remove the call to uv_update_time() you say?
22:20:00  <bnoordhuis>but wait, check handles run in between
22:20:16  <bnoordhuis>if one of those callbacks blocks for a while, loop->time would be off
22:20:32  * defunctzombiechanged nick to defunctzombie_zz
22:22:21  * defunctzombie_zzchanged nick to defunctzombie
22:23:28  <indutny>isaacs: I need your advice
22:23:37  <indutny>imagine following situation
22:23:44  <isaacs>indutny: ok
22:23:51  <indutny>stream is piped to net socket
22:24:02  <indutny>piping engine calls ._read() on stream
22:24:07  <isaacs>trevnorris: why would process.on('beforeExit', function() { console.log('foo') }) stay alive forever?
22:24:12  <indutny>and
22:24:17  <indutny>is going to write data into net socket
22:24:21  <indutny>but what happens instead
22:24:27  <indutny>is that sslOutEnd is emitted
22:24:36  <isaacs>indutny: piping engine calls .read() not ._read()
22:24:40  <indutny>and onwrite is called on opposite stream
22:24:42  <isaacs>indutny: Readable machinery calls ._read() if necessary
22:24:42  <indutny>isaacs: right, correct
22:24:43  <indutny>thanks
22:24:44  <isaacs>k
22:24:49  <indutny>and 'finish' happens
22:25:07  <MI6>joyent/libuv: Ben Noordhuis master * 64fdfdd : Merge remote-tracking branch 'origin/v0.10' (+1 more commits) - http://git.io/sB8Y3w
22:25:14  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 0017c55 : unix, windows: run expired timers in run-once mode - http://git.io/jlk7wg
22:25:15  <isaacs>indutny: so, the pair.cleartext.emit('finish'), you mean?
22:25:17  <indutny>before piping engine becomes aware of data returned by .read(), or probably more correct to say, before 'readable' event
22:25:26  <indutny>isaacs: lets skip details :)
22:25:31  <piscisaureus_>bnoordhuis: it wouldn't matter because it would still run the timer
22:25:38  <indutny>so what happens now is that tls destroy socket
22:25:38  <isaacs>indutny: i wanna make sure i know who's emitting finish here.
22:25:42  <indutny>ah
22:25:44  <indutny>yes
22:25:45  <indutny>cleartext
22:25:48  <isaacs>indutny: so, the cleartext.emit('finish')
22:25:50  <indutny>yep
22:25:57  <indutny>and piping stuff is in the middle of piping
22:26:04  <indutny>i.e. it has data to read
22:26:05  <isaacs>indutny: then this makes it say "Ok, everything has been sent"
22:26:08  <indutny>but has no output to write
22:26:12  <indutny>err
22:26:16  <indutny>no output stream to write into
22:26:17  <isaacs>indutny: in that, the pair.encrypted got all the data out of openss.
22:26:19  <isaacs>*openssl
22:26:30  <MI6>nodejs-master: #237 UNSTABLE smartos-x64 (7/604) smartos-ia32 (2/604) linux-x64 (2/604) osx-x64 (1/604) osx-ia32 (1/604) linux-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-master/237/
22:26:31  <indutny>well, that's not exactly true
22:26:42  <indutny>because it just makes sure that ._read() has read all possible data
22:26:44  <indutny>and here comes problem
22:26:47  <piscisaureus_>bnoordhuis: ah shit I know what it is!
22:26:49  <trevnorris>isaacs: it must trigger the ref count somewhere. found it by trying to log something while using the patch.
22:26:54  <piscisaureus_>bnoordhuis: you shouldn't land that on v0.10 ...
22:27:09  <piscisaureus_>bnoordhuis: on windows that won't be reliable
22:27:10  <indutny>isaacs: because it doesn't really mean that it was really *read*
22:27:16  <indutny>isaacs: I wonder if this is a .pipe bug
22:27:32  <MI6>libuv-v0.10: #85 UNSTABLE smartos (2/187) windows (6/188) http://jenkins.nodejs.org/job/libuv-v0.10/85/
22:27:38  <piscisaureus_>bnoordhuis: that's because the poll function in windows doesn't guarantee that the clock actually advances by the block time ...
22:27:49  <piscisaureus_>bnoordhuis: remember that timer-precision hack I landed a couple of weeks ago.
22:27:50  <isaacs>indutny: it probably should not destroy the socket until the *encrypted* side emits finish, no?
22:28:12  <indutny>no
22:28:15  <isaacs>indutny: cleartext.on('finish') should not happen until all the data was read out...
22:28:17  <indutny>that's called half-close
22:28:21  <indutny>isaacs: yes
22:28:26  <indutny>probably yes
22:28:33  <indutny>well
22:28:35  <indutny>definitely yes
22:28:38  <isaacs>but yor'e saying, i'ts been read() from the encrypted side, but not written to the socket?
22:28:45  <isaacs>indutny: ie, not finished writing to the socket?
22:28:49  <indutny>yep
22:28:54  <indutny>probably socket.write() returned false
22:28:55  <isaacs>indutny: then call socket.destroySoon() instead.
22:29:00  <isaacs>indutny: not socket.destroy(*)
22:29:04  <indutny>hm...
22:29:29  <isaacs>trevnorris: then i think the logic in beforeExit is wrong.
22:29:42  <indutny>ok, I get "write after end" now
22:29:42  <indutny>:)
22:29:55  <isaacs>trevnorris: it should be: 1) refcount is zero! 2) emit beforeExit 3) if refcount == 0 still, then actually exit.
22:30:22  <bnoordhuis>piscisaureus_: oh... should i revert it?
22:30:42  <piscisaureus_>bnoordhuis: alternatively you could disable the test on windows in v0.10 only
22:31:02  <bnoordhuis>okay, guess i'll do that
22:31:06  <trevnorris>isaacs: i think it's a similar problem that nextTick triggers the refcount by calling the spinner, even if nothing happens in nextTick
22:31:37  <isaacs>trevnorris: right. but that spinner is going away in 0.12 anyway
22:31:45  <isaacs>trevnorris: and beforeExit won't land in 0.10, so we're good there.
22:31:53  <isaacs>trevnorris: but console.log() should not result in a refcount.
22:31:59  <isaacs>trevnorris: it's synchronous
22:32:14  <trevnorris>isaacs: still not sure how that can be done, but discussion for another time.
22:32:19  <isaacs>:)
22:32:21  <trevnorris>isaacs: give me a minute. i'll trace it out
22:32:26  <isaacs>k
22:32:26  <bnoordhuis>piscisaureus_: i think i'll force-push it away
22:32:30  <bnoordhuis>it's not that important for v0.10
22:32:36  <piscisaureus_>bnoordhuis: okay
22:32:50  <isaacs>also: an explicit call to process.exit() should not emit beforeExit, i think
22:32:58  <isaacs>or if it does, it should just be synthetic
22:33:09  <piscisaureus_>bnoordhuis: we can just comment that users that need this guarantee in v0.10 should float ffe2ef0 and your patch
22:33:10  <isaacs>process.emit('beforeExit'); process.emit('exit'); process._reallyExit()
22:33:23  <piscisaureus_>and they have to swallow an ABI change
22:33:58  <MI6>joyent/libuv: Ben Noordhuis master * f6d8ba3 : unix, windows: run expired timers in run-once mode - http://git.io/HxgmgA
22:34:09  <MI6>joyent/libuv: Wynn Wilkes v0.10 * b4c658c : darwin: make uv_fs_sendfile() respect length param - http://git.io/xJGe3w
22:34:16  <trevnorris>isaacs: both throwing and process.exit() don't trigger beforeExit
22:34:25  <bnoordhuis>piscisaureus_: yeah. i'm guessing there aren't many people that care :)
22:34:32  <tjfontaine>isaacs: just like how process.exit emits 'exit' for that matter
22:34:49  <isaacs>tjfontaine, trevnorris: Yes, exactly
22:34:53  <isaacs>i think it's confusing if beforeExit doesn't emit.
22:35:00  <isaacs>it should emit. but it shouldn't be cancellable.
22:35:06  <MI6>libuv-master: #101 UNSTABLE windows (4/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/101/
22:35:11  <isaacs>or maybe it should not emit, because otherwise it's weird that you can't cancel it...
22:35:15  <tjfontaine>I agree, perhaps with a flag to say "no really, you can't stop me"
22:35:19  <isaacs>whatever. solve it with docs :)
22:35:25  <isaacs>i think not emitting is best.
22:35:28  <tjfontaine>at the very least doc the fuck out of it
22:35:30  <isaacs>"I said exit, you fucker"
22:35:46  <isaacs>it's annoying if you process.exit() and anything other than immediately exiting the process happens.
22:35:48  <tjfontaine>basically just a reiteration for what I said in my comment :)
22:35:58  <isaacs>sure :)
22:36:02  <isaacs>great minds think alike
22:36:05  <tjfontaine>heh
22:36:39  <MI6>libuv-v0.10-gyp: #48 UNSTABLE windows-x64 (4/188) osx-x64 (1/188) windows-ia32 (5/188) smartos-x64 (2/187) smartos-ia32 (2/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/48/
22:36:47  <tjfontaine>also https://github.com/tjfontaine/jankins/commit/29f0ff39f818596d453c02c69fdc01ce1f9970ab
22:36:54  <MI6>libuv-v0.10: #86 UNSTABLE smartos (4/187) windows (5/188) linux (1/187) http://jenkins.nodejs.org/job/libuv-v0.10/86/
22:37:12  <isaacs>tjfontaine ++
22:37:45  <isaacs>trevnorris, tjfontaine: So, beforeExit only if it's actually a graceful close, and possible to do async things.
22:37:54  <isaacs>otherwise the contract is too confusing.
22:38:03  <MI6>libuv-node-integration: #83 FAILURE smartos-ia32 (1/588) osx-ia32 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/83/
22:38:12  <trevnorris>and process.exit() is considered graceful?
22:38:14  <isaacs>If someone wants to prevent throw from exiting, then they can use domains or on('uncaughtException')
22:38:27  <isaacs>if they want to avoid process.exit() then they can use `npm i noexit`
22:38:32  <MI6>nodejs-master-windows: #46 UNSTABLE windows-x64 (20/604) windows-ia32 (17/604) http://jenkins.nodejs.org/job/nodejs-master-windows/46/
22:38:51  <MI6>libuv-master: #102 UNSTABLE windows (4/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/102/
22:38:53  <isaacs>trevnorris: no, process.exit() cancels everything
22:38:58  <trevnorris>ok
22:39:02  <isaacs>trevnorris: "Graceful" = "No more work, no explicit exit"
22:40:14  <tjfontaine>did someone force-push libuv? :P http://jenkins.nodejs.org/job/libuv-node-integration/83/DESTCPU=ia32,label=linux/console
22:40:29  <MI6>joyent/node: Ben Noordhuis master * f58e115 : deps: upgrade libuv to f6d8ba3 - http://git.io/YJvTWQ
22:40:34  <MI6>libuv-master-gyp: #39 FAILURE smartos-x64 (2/189) windows-ia32 (3/190) smartos-ia32 (2/189) linux-x64 (1/189) http://jenkins.nodejs.org/job/libuv-master-gyp/39/
22:40:48  <bnoordhuis>^ there's some patches that depend on a newer libuv
22:41:17  <isaacs>bnoordhuis: tsk tsk!
22:41:25  <tjfontaine>I'm going to have to dig into java and figure out what's going on with those psuedo-failiures
22:41:29  <tjfontaine>*failures
22:41:30  <isaacs>bnoordhuis: you should do a libuv release and upgrade to that
22:42:05  <MI6>libuv-node-integration: #84 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/84/
22:42:25  <isaacs>I'm just thinking... why did we keep the TickSpinner anyway? Why not just fall back to setImmediate?
22:42:32  <MI6>libuv-master: #103 UNSTABLE windows (3/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/103/
22:42:46  <piscisaureus_>bnoordhuis: you know how to do the release? I can do it too
22:42:47  <isaacs>probably was just easier to keep using the thing we already had.
22:44:21  <bnoordhuis>piscisaureus_: i don't have gpg set up on this machine
22:44:36  <piscisaureus_>bnoordhuis: ok, sec
22:44:42  <piscisaureus_>many changes since last v0.11
22:45:04  <bnoordhuis>if you're going to do a release, feel free to force-push my commit away
22:45:19  <tjfontaine>it's nice to see most of our build slave executors full
22:45:53  <piscisaureus_>bnoordhuis: why? is there anything that shouldn't be in there?
22:46:04  <piscisaureus_>bnoordhuis: or you mean the node commit?
22:46:50  <isaacs>please don't force-push. it upsets our robots :)
22:46:53  <MI6>libuv-v0.10-gyp: #49 UNSTABLE windows-x64 (3/187) windows-ia32 (4/187) smartos-x64 (2/186) smartos-ia32 (2/186) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/49/
22:46:56  <MI6>libuv-node-integration: #85 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/85/
22:47:04  <bnoordhuis>piscisaureus_: yeah, i meant the node commit
22:47:13  <bnoordhuis>but if it upsets the bots
22:47:28  <isaacs>robots have no Midi-chlorian, the force is strange and mysterious to them
22:47:39  <bnoordhuis>it's allaying my fears of a robot uprising
22:47:43  <isaacs>hahah
22:47:51  <isaacs>that's why there's no robot jedi
22:48:07  <MI6>libuv-v0.10: #87 UNSTABLE smartos (2/186) windows (3/187) http://jenkins.nodejs.org/job/libuv-v0.10/87/
22:48:58  <isaacs>ok, i've got one hour to carve out http-better agent into an npm module...
22:49:03  <isaacs>0.10.9 tomorrow! :D
22:49:23  <bnoordhuis>ah, sweet. i know a few people that are looking forward to that
22:49:37  * kazuponjoined
22:52:05  <MI6>libuv-master-gyp: #40 UNSTABLE smartos-x64 (2/189) windows-ia32 (4/190) smartos-ia32 (5/189) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/40/
22:55:07  * kazuponquit (Ping timeout: 264 seconds)
22:56:26  <MI6>libuv-master-gyp: #41 UNSTABLE smartos-x64 (2/189) windows-ia32 (3/190) smartos-ia32 (3/189) linux-ia32 (2/189) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/41/
22:57:47  <trevnorris>isaacs: figured out why console.log causes a n infinite loop
22:58:07  <isaacs>trevnorris: o_O?
22:58:08  <isaacs>oh?
22:58:14  <trevnorris>isaacs: because onwrite(stream, er) processes sync requests w/ process.nextTick
22:58:40  <isaacs>yep
22:58:44  <trevnorris>and nextTick calls the spinner, which increases the ref count
22:58:48  <isaacs>i guessed right!
22:58:51  * isaacsgets a gold star
22:58:54  <trevnorris>heh
22:59:06  * AvianFlujoined
22:59:09  <tjfontaine>the guy who wrote it, remembers it!
22:59:15  <trevnorris>lol
22:59:39  <trevnorris>still not sure how I feel about nextTick triggering beforeExit(?) if the next uv_run loop is empty
23:00:28  <trevnorris>guess in my mind nextTick callbacks go somewhere in between sync and async.
23:02:06  <MI6>joyent/libuv: piscisaureus created tag v0.11.4 - http://git.io/v-ga-Q
23:02:08  <MI6>joyent/libuv: Bert Belder master * bec8f3c : Now working on v0.11.5 (+1 more commits) - http://git.io/Al-PJg
23:02:22  <trevnorris>can we all promise no more big buffer changes until after mine are merged. ;-)
23:05:02  * TooTallNatequit (Quit: Computer has gone to sleep.)
23:07:39  <MI6>libuv-node-integration: #86 UNSTABLE smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (7/604) linux-x64 (2/604) linux-ia32 (1/604) osx-x64 (2/604) http://jenkins.nodejs.org/job/libuv-node-integration/86/
23:08:10  <MI6>nodejs-master: #238 UNSTABLE smartos-x64 (10/604) smartos-ia32 (3/604) linux-x64 (3/604) osx-x64 (1/604) osx-ia32 (1/604) linux-ia32 (1/604) http://jenkins.nodejs.org/job/nodejs-master/238/
23:10:05  <MI6>libuv-master: #104 UNSTABLE windows (3/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/104/
23:10:45  <MI6>joyent/node: Bert Belder master * 6b654c0 : uv: upgrade to v0.11.4 - http://git.io/98eUig
23:13:10  <MI6>libuv-review: #8 UNSTABLE windows-x64 (4/190) windows-ia32 (4/190) smartos-ia32 (3/189) smartos-x64 (4/189) http://jenkins.nodejs.org/job/libuv-review/8/
23:14:51  <MI6>libuv-master-gyp: #42 UNSTABLE smartos-x64 (2/189) windows-ia32 (3/190) smartos-ia32 (2/189) linux-ia32 (2/189) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/42/
23:15:07  <MI6>libuv-master: #105 UNSTABLE windows (3/190) smartos (3/189) http://jenkins.nodejs.org/job/libuv-master/105/
23:16:25  <isaacs>tjfontaine: if only that were universally the case.
23:16:30  <isaacs>tjfontaine: i'd have a much easier time fixing bugs in node.
23:16:37  <isaacs>tjfontaine: and especially bugs in npm ;)
23:16:38  <tjfontaine>indeed
23:16:40  <tjfontaine>heh
23:17:53  <tjfontaine>the 3 "w"s "how the fuck, why the fuck, who the fuck", always your own worst enemy
23:19:46  <MI6>nodejs-master-windows: #47 UNSTABLE windows-x64 (18/604) windows-ia32 (14/604) http://jenkins.nodejs.org/job/nodejs-master-windows/47/
23:20:08  <isaacs>tjfontaine: but "how" isn't a "w"
23:20:12  <isaacs>tjfontaine: the fuck?
23:20:21  <isaacs>;)
23:20:23  <tjfontaine>:)
23:20:30  <tjfontaine>select count(*) from pull_requests where pr = '/joyent/node/pull/4964';
23:20:30  <tjfontaine>46
23:20:50  <piscisaureus_>huh
23:20:57  <tjfontaine>since I changed jankins to use a db trevnorris has pushed 46 times to his PR :)
23:21:52  <piscisaureus_>I can totally see why people do startups that do CI
23:21:55  <trevnorris>tjfontaine: lol. yeah. I force push a lot. many of those are rebases of latest master.
23:21:59  <piscisaureus_>jankins is totally not it
23:22:03  <trevnorris>change that big, I like to keep it as up to date as possible
23:22:10  <piscisaureus_>I mean, it works. It's probably better than buildbot
23:22:21  <MI6>libuv-master-gyp: #43 UNSTABLE smartos-x64 (2/189) windows-ia32 (3/190) smartos-ia32 (3/189) linux-x64 (1/189) windows-x64 (3/190) http://jenkins.nodejs.org/job/libuv-master-gyp/43/
23:22:26  <piscisaureus_>but it still needs a full time graduate tjfontaine to keep working
23:22:33  * inolenquit (Quit: Leaving.)
23:22:46  <tjfontaine>most of the time it works
23:23:06  <tjfontaine>I could make it better, but ... fuck, it's java
23:23:10  <piscisaureus_>w.h. gates said the same
23:23:13  <piscisaureus_>about windows me
23:23:16  <tjfontaine>heh
23:23:24  * inolenjoined
23:26:31  <MI6>nodejs-master: #239 UNSTABLE smartos-x64 (9/604) smartos-ia32 (22/604) linux-x64 (3/604) osx-x64 (1/604) osx-ia32 (1/604) linux-ia32 (6/604) http://jenkins.nodejs.org/job/nodejs-master/239/
23:28:53  <MI6>libuv-node-integration: #87 UNSTABLE smartos-ia32 (2/588) osx-ia32 (1/588) smartos-x64 (120/588) linux-x64 (1/588) osx-x64 (1/588) http://jenkins.nodejs.org/job/libuv-node-integration/87/
23:30:12  <tjfontaine>hahah https://github.com/joyent/node/issues/5596 "if streaming is fast, then writeFileSync() should be as well"
23:32:08  * hzquit
23:32:43  <trevnorris>tjfontaine: let me handle that one.
23:32:57  <trevnorris>dude has no idea what's about to happen. ;-)
23:33:07  <tjfontaine>I'm mentioning you, but I can't resist my two cents :)
23:33:14  <trevnorris>lol
23:33:18  <tjfontaine>you can feel free to drop your knowledge on him
23:33:23  * mralephquit (Read error: Operation timed out)
23:40:23  <trapito>is there any way to monitor connections so that i don't end up with a lot of close_wait ones if the other end crashes?
23:41:02  <trapito>i was testing and i did this : listen on the server, connect from python, raise an unhandled exception in python
23:41:12  <MI6>nodejs-master-windows: #48 UNSTABLE windows-x64 (15/604) windows-ia32 (16/604) http://jenkins.nodejs.org/job/nodejs-master-windows/48/
23:45:18  <MI6>libuv-node-integration: #88 UNSTABLE smartos-ia32 (2/604) osx-ia32 (2/604) smartos-x64 (7/604) linux-x64 (1/604) linux-ia32 (1/604) osx-x64 (2/604) http://jenkins.nodejs.org/job/libuv-node-integration/88/
23:47:25  <trapito>nevermind, i'm a dummy =3
23:47:32  <tjfontaine>heh ok
23:50:56  * kazuponjoined
23:52:50  * dominictarrquit (Quit: dominictarr)
23:54:12  <trevnorris>tjfontaine: think we could program in a way to watch PR subject lines, just to let devs know they don't need to open/close every freakin time they need to correct something?
23:54:30  * TooTallNatejoined
23:55:24  <tjfontaine>trevnorris: well I added this today https://github.com/tjfontaine/jankins/commit/29f0ff39f818596d453c02c69fdc01ce1f9970ab
23:55:42  <trevnorris>yes yes yes!
23:55:45  * kazuponquit (Ping timeout: 256 seconds)
23:55:46  <tjfontaine>trevnorris: presuming they read
23:56:08  <trevnorris>can you make that extra large, very bold. mayby use the <blink> tag
23:56:28  <tjfontaine>heh
23:57:29  <tjfontaine>http://modulecounts.com/ clicking on "all time" gives a pretty hilarious graph
23:58:48  <trevnorris>ah, average growth of 75 a day? that's insane