00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:02  <trevnorris>but when I change the api so tls works, everything else breaks.
00:00:07  * ircretaryjoined
00:00:55  <trevnorris>I think there may be a conflict w/ ObjectWrap and Buffer, but they don't explicitly interact.
00:01:08  <trevnorris>the only time node_crypto uses buffers is to return a value.
00:01:40  <kellabyte>piscisaureus_: I'm seeing some really bad latency when I reach 200,000 HTTP requests/second, I'm assuming my code is maybe hitting problems but I thought it was worth asking
00:01:45  <trevnorris>and tls.js just uses the SlabBuffer. Which I took the time to strip out and make sure the error still happens.
00:02:01  <kellabyte>piscisaureus_: I'm not sure what is a realistic ceiling for a single libuv event loop
00:02:21  <piscisaureus_>kellabyte: 200,000 is *a lot*
00:03:17  <piscisaureus_>kellabyte: it's definitely not related to a particular number of threads
00:03:30  <kellabyte>piscisaureus_: its pipelined HTTP, I was getting 65,000/second non-pipelined with HTTP keep-alive
00:04:09  <kellabyte>running against wrk with the following:
00:04:11  <kellabyte>wrk -d10 -c512 -t1 --pipeline
00:04:24  <kellabyte>Requests/sec: 215550.41
00:04:36  <kellabyte>Socket errors: connect 0, read 0, write 0, timeout 812
00:05:05  <kellabyte>this is starting to show some serious problems though here:
00:05:07  <kellabyte>Thread Stats Avg Stdev Max +/- Stdev
00:05:09  <kellabyte> Latency 798.07ms 1.32s 5.38s 86.15%
00:06:11  <piscisaureus_>kellabyte: depending on your test setup / you're saturating your network link?
00:06:52  <kellabyte>piscisaureus_: 20MB transfered in 10 seconds, hmm
00:07:02  <piscisaureus_>kellabyte: ok, no
00:07:57  <kellabyte>piscisaureus_: is it realistic I keep everything on a single thread still at this kind of rate?
00:08:35  <piscisaureus_>kellabyte: well depends how much work you need to do per each request... but probably you'd want to be multithreaded
00:09:52  <kellabyte>piscisaureus_: so far this is just responding with a static response, this is what the web server looks like https://gist.github.com/kellabyte/5383833
00:10:43  <kellabyte>any tips on how I can make that better? :)
00:12:48  <piscisaureus_>kellabyte: I didn't check line for line but in general it looks ok. I think this is unlikely to be the bottleneck once your actual application is bolted on :)
00:12:49  <piscisaureus_>btw
00:12:59  <piscisaureus_>#pragma comment(lib, "Iphlpapi.lib") <-- msvc-ism?
00:13:42  * trevnorrisquit (Quit: Leaving)
00:14:05  <piscisaureus_>also libuv functions like uv_listen and uv_write return a result that you should deal with.
00:14:46  * piscisaureus_goes to bed
00:14:49  <kellabyte>piscisaureus_: I was getting some conflicts, I think you can fix it in the project properties but haven't learned how yet, I'm a C noob so lots of mistakes
00:14:50  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:14:51  * dominictarrquit (Quit: dominictarr)
00:15:04  <kellabyte>ah crap! didn't get a chance to thank them for the feedback :)
00:16:10  <bnoordhuis>kellabyte: he'll see it in the logs tomorrow :)
00:29:32  * dominictarrjoined
00:30:06  * dominictarrquit (Client Quit)
00:47:25  <kellabyte>bnoordhuis: LOL :)
00:47:39  <indutny>bnoordhuis: hola
00:47:50  <kellabyte>super thanks to everyone here for being so welcoming to a noob
00:48:51  <indutny>I wasn't here, but you're welcome anyway
00:49:53  <kellabyte>haha
00:54:26  <kellabyte>I'm new at C or C++ and I have to say, I got super frustrated trying to use some libs or code on windows, libuv was a breeze even though I didn't know what I was doing
00:56:18  <bnoordhuis>indutny: hela
00:56:24  * inolenquit (Quit: Leaving.)
00:56:27  <indutny>bnoordhuis: hela
00:56:32  <indutny>what are we up for?
00:56:35  <indutny>like "we"
00:56:39  <indutny>not "you"
00:56:46  <indutny>is there anything interesting/important around there?
00:56:59  <bnoordhuis>here in gouda?
00:57:16  <indutny>bnoordhuis: lets start with gouda
00:57:21  <bnoordhuis>we have a city centre with a rich history
00:57:23  <indutny>anything important here?
00:57:26  <indutny>aha
00:57:28  <indutny>I knew it
00:57:30  <bnoordhuis>goes all the way back to the 14th century
00:57:35  <indutny>and your cheese is tasty
00:57:39  <bnoordhuis>that too
00:57:46  <indutny>not in russia, though
00:57:58  <indutny>because its almost the same as the "Russian" cheese
00:58:09  <indutny>I think that happens because its made on the same factories
00:58:10  <bnoordhuis>interesting factoid: there aren't actually any cheese factories in gouda
00:58:21  <pquerna>uh huh
00:58:22  <indutny>where is it made?
00:58:23  <bnoordhuis>yeah, probably somewhere in poland
00:58:32  <indutny>god
00:58:34  <pquerna>per-path / filesystem thread pools... .....go.
00:58:38  <indutny>what's up with the world
00:58:43  <indutny>pquerna: ?
00:58:54  <indutny>bnoordhuis: ok, anything about node.js?
00:59:56  <bnoordhuis>not really. there's no node community to speak of here
01:00:05  <indutny>ok what about libuv
01:00:18  <bnoordhuis>no libuv community either
01:00:25  <indutny>ok, so just gouda and cheese
01:00:29  <kellabyte>lol
01:00:31  <bnoordhuis>and lots of canals
01:00:34  <indutny>great
01:00:35  <indutny>oh yeah
01:00:40  <indutny>btw, how are you parking there?
01:00:46  <indutny>its almost indistinguishable at night
01:00:47  <bnoordhuis>very carefully
01:00:48  <pquerna>so i was in a session today about openstack swift.
01:00:54  <pquerna>about doing diskio in eventlet
01:00:56  <pquerna>it was bad
01:00:59  <pquerna>:|
01:01:08  <indutny>I believe you
01:01:15  <indutny>however, I didn't get most of what you've said
01:01:25  <bnoordhuis>the good kind of bad or the bad kind of bad?
01:01:34  <indutny>its like offloading disk IO to threads?
01:02:11  <pquerna>basically, I want to be able to say, for path /x1/ use 10 threads, for /x2/ use 10 threads and for / (anything else) use 4
01:02:15  <pquerna>(or something like that)
01:03:33  <bnoordhuis>why per-path?
01:03:46  * dapquit (Quit: Leaving.)
01:03:56  <pquerna>in the swift use case, they mount single drives in their own path
01:04:03  <pquerna>imagine jbods
01:04:54  <bnoordhuis>ah okay
01:05:14  <pquerna>what they also see
01:05:16  <bnoordhuis>and now you're looking at libuv or is this eventlet only?
01:05:18  <pquerna>is if one disk is going slow
01:05:29  <pquerna>it tends to eat up the thread pool
01:05:54  <pquerna>well, they currently use eventlet, which doesn't do disk io
01:06:01  <pquerna>so, their first impl, is a python-threading impl
01:15:09  * mikealjoined
01:20:16  * mikealquit (Quit: Leaving.)
01:31:51  * AvianFluquit (Read error: Connection reset by peer)
01:32:04  * AvianFlujoined
01:32:30  * bnoordhuisquit (Ping timeout: 276 seconds)
01:34:02  * perezdquit (Quit: perezd)
01:47:59  * abraxasjoined
01:58:29  * inolenjoined
01:59:41  * brsonquit (Quit: leaving)
02:13:25  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:15:16  * mikealjoined
02:37:54  * bnoordhuisjoined
02:42:13  * bnoordhuisquit (Ping timeout: 240 seconds)
02:44:27  * perezdjoined
03:21:52  * brsonjoined
03:23:40  * AvianFluquit (Read error: Connection reset by peer)
03:24:17  * AvianFlujoined
03:25:53  * brsonquit (Ping timeout: 240 seconds)
03:27:06  * brsonjoined
04:16:08  * jmar777quit (Remote host closed the connection)
04:21:00  * mikealquit (Read error: Connection reset by peer)
04:21:34  * wolfeidauquit (Read error: Connection reset by peer)
04:21:50  * wolfeidaujoined
04:37:31  * defunctzombiechanged nick to defunctzombie_zz
04:37:50  * abraxasquit (Remote host closed the connection)
04:39:43  * mikealjoined
04:40:26  * mikealquit (Client Quit)
04:45:42  * mikealjoined
04:46:54  * abraxasjoined
05:25:21  * `3rdEdenjoined
05:30:55  * `3rdEdenquit (Ping timeout: 258 seconds)
05:38:36  * bajtosjoined
05:39:50  * perezdquit (Quit: perezd)
05:43:42  * AvianFluquit (Remote host closed the connection)
06:03:27  * brsonquit (Quit: leaving)
06:04:32  * felixgequit (Quit: felixge)
06:11:43  * brsonjoined
06:35:06  * V1joined
06:35:40  * V1changed nick to `3E
06:35:58  * rendarjoined
06:38:57  * wolfeidauquit (Read error: Connection reset by peer)
06:39:13  * wolfeidaujoined
06:43:09  * wolfeidauquit (Read error: Connection reset by peer)
06:43:15  * wolfeida_joined
06:44:53  * `3rdEdenjoined
07:00:38  * wolfeida_quit (Ping timeout: 255 seconds)
07:06:35  * wolfeidaujoined
07:21:17  * brsonquit (Ping timeout: 252 seconds)
07:30:27  * csaohjoined
07:33:50  * wolfeidauquit (Remote host closed the connection)
07:53:53  * wolfeidaujoined
08:07:53  * benoitcjoined
08:42:51  * felixgejoined
08:44:16  * `3Equit (Remote host closed the connection)
09:12:03  * stagasjoined
09:29:08  * felixgequit (Quit: felixge)
09:33:39  * felixgejoined
10:17:59  * bnoordhuisjoined
10:18:18  <mmalecki>sup bnoordhuis :)
10:24:47  * abraxasquit (Remote host closed the connection)
10:25:36  <bnoordhuis>mmalecki: hey maciej
10:26:34  <mmalecki>bnoordhuis: how's it going?
10:30:20  <bnoordhuis>mmalecki: same old, same old. what about you?
10:30:57  <mmalecki>bnoordhuis: I'm good, same stuff
10:33:16  <mmalecki>bnoordhuis: I thought you could be interested in this thing we released yesterday :) https://github.com/opsmezzo/aeternum
10:35:39  * dominictarrjoined
10:36:56  <bnoordhuis>ah, nice
10:37:07  * csaohquit (Quit: csaoh)
10:38:53  <mmalecki>bnoordhuis: soon enough, we'll be releasing a libuv-based monitoring tool :)
10:56:46  * hzjoined
11:00:18  * csaohjoined
11:10:15  * felixgequit (Quit: felixge)
11:12:47  * dominictarrquit (Quit: dominictarr)
11:17:34  * dominictarrjoined
11:18:04  * dominictarrquit (Client Quit)
11:23:53  * hzquit (Disconnected by services)
11:23:56  * hzjoined
11:40:53  * bnoordhuisquit (Ping timeout: 252 seconds)
11:46:06  <bajtos>could you please review my pull request fixing failing timer-related unit-tests on windows?
11:46:12  <bajtos>https://github.com/joyent/libuv/pull/779
11:52:48  * felixgejoined
11:52:48  * felixgequit (Changing host)
11:52:48  * felixgejoined
11:55:36  * benoitcquit (Excess Flood)
11:57:24  * benoitcjoined
12:07:02  * bnoordhuisjoined
12:12:19  * dominictarrjoined
12:15:22  * bnoordhuisquit (Ping timeout: 256 seconds)
12:52:55  * bnoordhuisjoined
13:08:33  * piscisaureus_joined
13:29:05  * defunctzombie_zzchanged nick to defunctzombie
13:35:53  * bnoordhuisquit (Ping timeout: 240 seconds)
13:38:51  * c4milojoined
13:39:57  * jmar777joined
13:40:13  * bnoordhuisjoined
13:48:56  * dominictarrquit (Quit: dominictarr)
13:53:26  * piscisaureus_quit (Ping timeout: 252 seconds)
13:59:19  * dominictarrjoined
14:05:43  * qmxquit (Excess Flood)
14:08:08  * qmxjoined
14:15:04  * piscisaureus_joined
14:15:08  <bnoordhuis>pushing to github seems kind of flaky today...
14:15:20  <bnoordhuis>getting "ssh_exchange_identification: Connection closed by remote host" a lot
14:21:30  * AvianFlujoined
14:24:37  <piscisaureus_>bnoordhuis: (uint64_t) -1 to get UINT64_MAX ?
14:24:44  <piscisaureus_>bnoordhuis: that was your idea? :-p
14:25:44  <bajtos>piscisaureus_ welcome :)
14:25:53  <piscisaureus_>bajtos: thanks :)
14:26:02  <piscisaureus_>bajtos: welcome to you too
14:27:31  <bnoordhuis>piscisaureus_: yep. perfectly legal
14:27:34  <bnoordhuis>even moral
14:27:47  <piscisaureus_>bnoordhuis: it's two's-complement-normative :)
14:28:05  <bnoordhuis>no, it's according to the spec
14:28:45  <bnoordhuis>that is, (uint64_t) -1 is guaranteed to be equal to UINT64_MAX
14:29:16  <bnoordhuis>but without the hassle of making sure you include the right headers and define the right flags
14:30:53  * trippehjoined
14:31:41  <piscisaureus_>github down?
14:31:45  <MI6>joyent/libuv: Miroslav Bajtoš v0.10 * 09ff510 : windows: make timers handle large timeouts Fixes a bug where timers with - http://git.io/u7SfWg
14:31:48  <piscisaureus_>oh just sow
14:31:50  <piscisaureus_>*slow
14:39:57  <piscisaureus_>bnoordhuis: do you have a sec to deliberate something?
14:45:03  * dominictarrquit (Quit: dominictarr)
14:47:01  <bnoordhuis>piscisaureus_: shoot
14:47:21  <piscisaureus_>bnoordhuis: so you might have seen that the loop_stop test is flaky on windows
14:47:56  <piscisaureus_>bnoordhuis: turns out that the the GetQueuedCompletionStatus[Ex] isn't very exact wrt to the timeout value
14:48:21  <piscisaureus_>so sometimes it returns, but then when libuv processes timers it figures that the first-up timer hasn't expired yet
14:48:28  <piscisaureus_>so it runs another loop iteration
14:49:04  <piscisaureus_>bnoordhuis: do you think this is something I should deal with? I mean, theoretically it could libuv to busyloop for a couple if ms just before a timer expires
14:49:16  <bnoordhuis>you mean it returns prematurely or that it returns sometime between timeout and timeout + extra_time
14:49:33  <piscisaureus_>bnoordhuis: well it returns slightly prematurely
14:50:00  <piscisaureus_>so for example the next timer is due at `loop->time + 5 ms` so we pass 5ms as the timeout value
14:50:00  <bnoordhuis>are we talking microseconds, milliseconds?
14:50:10  <piscisaureus_>but then GetQueuedCompletionStatus returns after 4ms
14:50:13  <bnoordhuis>ah
14:50:21  <piscisaureus_>so it's in the order of milliseconds
14:50:31  <bnoordhuis>check the expired time and call GetQueuedCompletionStatus again with an updated timeout?
14:50:40  <bnoordhuis>that's what i do in uv-unix on EINTRs
14:51:05  <piscisaureus_>well that's effectively what happens, except the loop makes a full iteration
14:51:29  <piscisaureus_>but it makes loop_stop fail because the prepare watchers is called too often
14:51:38  <piscisaureus_>s/watchers/watcher/
14:52:03  <bnoordhuis>where do you call GetQueuedCompletionStatus?
14:52:07  <piscisaureus_>bnoordhuis: I'm more concerned that we might end up busy-looping ov
14:52:19  <piscisaureus_>core.c
14:52:27  <piscisaureus_>there's two backends :)
14:52:37  <bnoordhuis>line 234?
14:52:40  <piscisaureus_>GetQueuedCompletionStatusEx is the one that's commonly used
14:52:53  <piscisaureus_>yeah
14:52:55  <bnoordhuis>okay
14:53:36  <bnoordhuis>so what's stopping you from wrapping that call to GetQueuedCompletionStatus in a loop that checks the expired time?
14:53:43  <piscisaureus_>bnoordhuis: nothing
14:53:53  <bnoordhuis>you're worried the next call to GetQueuedCompletionStatus will return immediately?
14:53:57  <piscisaureus_>bnoordhuis: but timers that expire too early are different from EINTR
14:54:17  <piscisaureus_>yes, it will return immediately, then the timer still isn't due, and we call it again etc
14:54:41  <bnoordhuis>does that actually happen? as in, have you tried it?
14:54:49  <piscisaureus_>bnoordhuis: yes, it does
14:54:53  <bnoordhuis>ah
14:54:55  <bnoordhuis>windows :(
14:55:29  <bnoordhuis>calling Sleep(1) is probably a bad idea, i take it?
14:55:29  <piscisaureus_>bnoordhuis: I'm considering to set some sort of flag if function returns WAIT_TIMEOUT
14:56:07  <piscisaureus_>and then unconditionally expire the first timer when that flag is set (well - if is not more than a couple of ms off)
14:56:46  <bnoordhuis>you mean run the timer too early?
14:56:56  <piscisaureus_>bnoordhuis: slightly too early, yes
14:57:03  <bnoordhuis>that won't do, bertje
14:57:24  <piscisaureus_>we'd probably also have to cheat on uv_now() ...
14:57:30  <piscisaureus_>it's probably more trouble than it's worth
14:57:34  <bnoordhuis>evil
14:58:32  <bnoordhuis>how bad of an idea is it to sleep for a few microseconds then try GetQueuedCompletionStatus again?
14:58:51  <piscisaureus_>well I think Sleep() has the same resolution as GetQueuedCompletionStatus()
15:00:04  <piscisaureus_>the problem is just that the resolution of this timer is ~ 10ms unless some other application is running that makes the scheduler use smaller quantums
15:01:19  <bnoordhuis>ah
15:01:43  <bnoordhuis>in that case i don't know how to best fix it
15:02:20  <piscisaureus_>:'-(
15:02:44  <piscisaureus_>My professional respect for Ben, in a million pieces on the floor. :-p
15:04:42  <SquirrelCZECH>:-)
15:10:24  <MI6>joyent/node: Stanislav Ochotnicky v0.10 * 7592615 : test: preserve process.env after test-init exec When LD_LIBRARY_PATH is (+1 more commits) - http://git.io/vo4BKg
15:10:43  <piscisaureus_>bnoordhuis:
15:10:49  <piscisaureus_>GQCS too fast. uv_now(): 7352810, next timer due: 7352817, difference: 7
15:10:49  <piscisaureus_>3
15:10:49  <piscisaureus_>GQCS too fast. uv_now(): 7353013, next timer due: 7353017, difference: 4
15:10:49  <piscisaureus_>GQCS too fast. uv_now(): 7353216, next timer due: 7353217, difference: 1
15:10:49  <piscisaureus_>GQCS too fast. uv_now(): 7353309, next timer due: 7353317, difference: 8
15:10:50  <piscisaureus_>GQCS too fast. uv_now(): 7353403, next timer due: 7353417, difference: 14
15:10:50  <piscisaureus_>GQCS too fast. uv_now(): 7353512, next timer due: 7353517, difference: 5
15:10:51  <piscisaureus_>GQCS too fast. uv_now(): 7353715, next timer due: 7353717, difference: 2
15:11:23  <bnoordhuis>that's in milliseconds?
15:11:26  <piscisaureus_>yes
15:11:31  <bnoordhuis>that's pretty awful
15:12:52  <piscisaureus_>It is isn't it :)
15:30:19  <MI6>nodejs-v0.10: #137 UNSTABLE smartos-x64 (1/576) windows-ia32 (5/576) linux-x64 (1/576) windows-x64 (5/576) smartos-ia32 (1/576) osx-x64 (1/576) http://jenkins.nodejs.org/job/nodejs-v0.10/137/
15:30:42  * bnoordhuisquit (Ping timeout: 264 seconds)
15:36:18  <piscisaureus_>bnoordhuis: actually it could also be that GetQueuedCompletion is *more* precise than uv_now() ...
15:36:37  <piscisaureus_>so doing some artificial timer resolution enhancements could be worth it, actually
15:37:08  * `3rdEdenquit (Remote host closed the connection)
15:39:28  <piscisaureus_>shit. it seems so.
15:42:36  * bnoordhuisjoined
15:44:20  <piscisaureus_>tjfontaine: why is jenkins not building libuv-v0.10
15:47:36  * hzquit (Ping timeout: 264 seconds)
15:47:53  * bnoordhuisquit (Ping timeout: 240 seconds)
15:53:05  * dominictarrjoined
15:53:45  <tjfontaine>hm?
15:54:24  <tjfontaine>piscisaureus_: has there been anything pushed to it?
15:54:31  <tjfontaine>oh there was today
15:56:20  * piscisaureus_quit (Ping timeout: 252 seconds)
15:57:11  <tjfontaine>ircretary: tell piscisaureus_ according to the logs github never sent the push to notify us of the commit
15:57:12  <ircretary>tjfontaine: I'll be sure to tell piscisaureus_
15:57:36  * bnoordhuisjoined
15:58:02  <tjfontaine>good day ben
15:58:07  <bnoordhuis>morning tj
15:59:21  <tjfontaine>I'll ask the jenkins folk about allocating the tty, but I'm not optimistic that there's a solution already for it
16:01:55  * bajtosquit (Ping timeout: 260 seconds)
16:03:02  <MI6>libuv-v0.10: #37 UNSTABLE osx (1/186) linux (2/186) windows (5/187) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/37/
16:07:21  * piscisaureus_joined
16:08:56  * brsonjoined
16:09:17  * dominictarrquit (Ping timeout: 252 seconds)
16:11:28  * bajtosjoined
16:12:53  * bajtos_joined
16:12:54  * bajtosquit (Read error: Connection reset by peer)
16:14:19  * bajtos_quit (Client Quit)
16:14:43  * bajtosjoined
16:16:13  * dominictarrjoined
16:17:49  * piscisaureus_quit (Read error: Connection reset by peer)
16:20:49  * dapjoined
16:21:35  * piscisaureus_joined
16:21:43  <piscisaureus_>ircretary: notes
16:25:05  <MI6>libuv-node-integration: #20 UNSTABLE smartos-ia32 (1/576) windows-ia32 (5/576) windows-x64 (5/576) smartos-x64 (2/576) http://jenkins.nodejs.org/job/libuv-node-integration/20/
16:30:48  * felixgequit (Quit: felixge)
16:35:26  * bnoordhuisquit (Ping timeout: 245 seconds)
16:44:08  <tjfontaine>ircretary: tell bnoordhuis I changed how we launch the slave on unicies, it fixes linux but smartos still complains
16:44:08  <ircretary>tjfontaine: I'll be sure to tell bnoordhuis
16:49:00  * c4miloquit (Remote host closed the connection)
17:03:28  * bajtosquit (Ping timeout: 245 seconds)
17:04:15  * qmxchanged nick to qmx|lunch
17:06:21  * csaohquit (Quit: csaoh)
17:08:06  * trevnorrisjoined
17:09:23  <trevnorris>another day, another crack at this problem.
17:15:05  * `3rdEdenjoined
17:19:50  * bajtosjoined
17:21:04  * TooTallNatejoined
17:29:05  * piscisaureus_quit (Read error: Connection reset by peer)
17:32:10  * defunctzombiechanged nick to defunctzombie_zz
17:36:35  * c4milojoined
17:36:42  * brsonquit (Ping timeout: 245 seconds)
17:43:13  * brsonjoined
17:50:25  * dapquit (Quit: Leaving.)
17:50:50  * dapjoined
17:58:49  * bajtos_joined
17:59:46  <creationix>does anyone know why node never took advantage of writev
18:00:09  <creationix>lib's stream write accepts a list of buffers, but node's binding only accepts a single buffer
18:00:18  <creationix>s/lib's/libuv's/
18:00:40  * bajtosquit (Read error: Connection reset by peer)
18:01:02  <trevnorris>creationix: think there was some discussion on that. let me grep the logs.
18:01:13  <creationix>I remember ryah was exploring writev to make http faster years ago, but I don't remember why that didn't help
18:02:30  <trevnorris>creationix: https://github.com/joyent/node/pull/5257
18:07:40  * mikealquit (Quit: Leaving.)
18:09:57  * qmx|lunchchanged nick to qmx
18:11:45  * bajtos_quit (Read error: Connection reset by peer)
18:12:04  * bajtosjoined
18:13:33  <tjfontaine>bajtos: did you see that linux is now green post your title fix?
18:13:49  * mikealjoined
18:14:13  * brsonquit (Quit: leaving)
18:14:29  * brsonjoined
18:18:57  <creationix>trevnorris: thanks, so it looks like we're trying to see if it works again
18:21:11  <trevnorris>np
18:21:24  <trevnorris>actually thank indutny. =)
18:24:53  <bajtos>tjfontaine: didn't, it's good news then :)
18:25:49  <tjfontaine>the invalid op on the tty still exists for osx and smartos though
18:28:13  <bajtos>tjfontaine: there are more problems at these platforms - process_title still fails on SmartOs
18:28:41  <bajtos>tjfontaine: btw did you find the reason why builds are not automatically triggered by forcepush?
18:28:45  <tjfontaine>bajtos: because process title is a noop, look at src/unix/sun.c
18:28:59  <tjfontaine>bajtos: ya, that should be fixed as well now
18:29:09  <tjfontaine>if not I can debug further
18:29:31  <bajtos>tjfontaine: in that case we can disable the proces_title unit-test?
18:30:28  <tjfontaine>bajtos: I did some research, that may be the right path, basically there's no consistent way to do it such that all utilities see the same information
18:30:45  <bajtos>tjfontaine: ok, I can do it later
18:31:12  <tjfontaine>I have a ticket open for one of the other smartos issues
18:31:18  <bajtos>tjfontaine: also regarding the tty/pty test on linux - ben would like to have it fixed in build environment and not changing test code (see comment in pull request)
18:31:37  <bajtos>tjfontaine: what's your opinion on that?
18:31:38  <tjfontaine>bajtos: yes I "fixed" it, it's annoying but workable
18:32:01  <tjfontaine>http://jenkins.nodejs.org/job/libuv-pullrequest/label=linux/
18:32:05  <bajtos>ok, so I can revert my changes (rework from tty to pty) then?
18:32:48  * felixgejoined
18:32:57  <tjfontaine>ya, as far as I know I've "fixed" it
18:36:19  <bajtos>tjfontaine well why is libuv-v0.10 failing then? http://jenkins.nodejs.org/job/libuv-v0.10/lastCompletedBuild/label=linux/tapTestReport/
18:36:51  <tjfontaine>I didn't rebuild that after doing the fix
18:37:05  <tjfontaine>I can trigger it though
18:37:10  <bajtos>tjfontaine that would be great
18:37:22  <tjfontaine>in flight
18:40:01  * brsonquit (Quit: leaving)
18:42:25  <MI6>libuv-v0.10: #38 FAILURE osx (2/186) windows (4/187) smartos (3/186) http://jenkins.nodejs.org/job/libuv-v0.10/38/
18:42:51  <tjfontaine>sigh
18:44:57  * brsonjoined
18:46:42  <MI6>libuv-v0.10: #39 UNSTABLE osx (2/186) linux (1/186) windows (5/187) smartos (3/186) http://jenkins.nodejs.org/job/libuv-v0.10/39/
18:48:11  <tjfontaine>bajtos: ^ one failure is the title you fixed
18:52:00  <bajtos>tjfontaine looks good. it's getting late here in Europe, I'll polish my PR tomorrow so that it can be merged
18:53:22  <tjfontaine>k
18:57:27  <bajtos>btw, what's the rule for handling changes that are not implemented for all platforms?
18:57:56  <bajtos>like my other PR, which works on Linux and Windows only: https://github.com/joyent/libuv/pull/744
18:58:26  <bajtos>do we keep the related issue open until all platforms are fixed? or create a new issue for the missing platforms?
19:04:34  <MI6>libuv-node-integration: #21 UNSTABLE smartos-ia32 (1/576) windows-ia32 (5/576) windows-x64 (5/576) smartos-x64 (1/576) http://jenkins.nodejs.org/job/libuv-node-integration/21/
19:13:35  * eris0xffjoined
19:18:44  * brsonquit (Ping timeout: 245 seconds)
19:19:45  * brsonjoined
19:21:41  * `3rdEden_joined
19:22:08  * `3rdEdenquit (Ping timeout: 272 seconds)
19:23:49  * `3rdEden_changed nick to `3rdEden
19:27:44  * AvianFluquit (Remote host closed the connection)
19:51:03  * bajtosquit (Quit: good night)
19:59:24  <creationix>mikeal: so much twitter noise, is there a better place to discuss?
20:05:27  * trippehquit (Ping timeout: 245 seconds)
20:05:38  * inolenquit (Ping timeout: 252 seconds)
20:06:21  * bnoordhuisjoined
20:06:34  * inolenjoined
20:13:09  * AvianFlujoined
20:13:58  <trevnorris>anyone mind helping me weigh in on a buffer api decision?
20:14:36  <trevnorris>whether buffer arguments are coerced or throw is a mixed bag. i'd like to make this consistent.
20:14:57  <mikeal>creationix: sure
20:15:16  <trevnorris>i'd say, throw when arguments are out of range like DataView does, but that would break backwards compatibility.
20:15:21  <mikeal>i think that, rather than middleware, you should build on whatever other patterns you're establishing
20:15:33  <trevnorris>TooTallNate: you'd have some insight. any thoughts on the buffer arguments checks?
20:18:05  * trippehjoined
20:20:50  <eris0xff>hi
20:21:08  <CoverSlide>the thing about middleware is it's simply just a node callback pattern. nothing wrong with that. as long as your modules don't write specifically with express/connect in mind you're fine. my biggest complaint is most of the middleware could be abstracted into a separate module. connect / express should be more like "glue" for those individual components for convenience
20:21:43  <eris0xff>i'm probably too tired right now, but I'm trying to find the docs for the "status" value returned in the write callback
20:22:07  <eris0xff>read through the uv.h include and it's a little vague
20:23:36  * inolenquit (Ping timeout: 264 seconds)
20:24:11  * eris0xff_joined
20:24:24  <eris0xff_>never mind. i think i found it in the test code
20:26:05  * inolenjoined
20:26:18  * eris0xffquit (Ping timeout: 245 seconds)
20:32:53  * inolenquit (Ping timeout: 255 seconds)
20:32:53  * inolen1joined
20:38:54  * jmar777quit (Remote host closed the connection)
20:39:27  <indutny>bnoordhuis: hey man
20:39:30  <indutny>good evening
20:42:45  * isaacsquit (Ping timeout: 248 seconds)
20:42:53  <TooTallNate>trevnorris: i think throwing is better as well… but ask isaacs about the backwards compat factor
20:43:24  * isaacsjoined
20:43:32  <trevnorris>TooTallNate: cool.
20:43:48  * isaacschanged nick to Guest89130
20:44:41  <indutny>I'm going to look into .ondata thing
20:44:45  <indutny>and readStop/readStart
20:44:46  <indutny>and remove it
20:44:49  <indutny>any objections?
20:44:59  <indutny>(like I want to make http fully streams2 in 0.12)
20:45:38  <bnoordhuis>indutny: hey
20:45:44  <indutny>hey man
20:45:48  <indutny>how are you doing?
20:45:55  <bnoordhuis>same old
20:46:13  <trevnorris>TooTallNate: for now i'm going to make them consistently coerce. it's all in a #define so it'll be easy to switch back depending on what isaacs says.
20:46:15  <bnoordhuis>what's this .ondata thing you mention?
20:46:17  <indutny>oh, not great
20:46:31  <indutny>bnoordhuis: right now http.js is fucked
20:46:34  <indutny>a little
20:46:48  <indutny>all this .ondata .onend .readStart .readStop things doesn't fit streams2 much
20:47:00  <indutny>and make all other modules like tls.js clubbered
20:47:14  <indutny>well, .readStart/.readStop is actually net.js thing, but its all connected
20:47:19  <bnoordhuis>clubbered. is that a contraction of cluttered and clobbered?
20:47:27  <indutny>hahaha
20:47:32  <indutny>I wanted to say clobbered
20:47:37  <bnoordhuis>hah, okay
20:47:51  <indutny>ah
20:47:55  <indutny>better cluttered
20:47:56  <indutny>anyway
20:47:59  <indutny>you got it
20:48:51  <TooTallNate>indutny: no objections on my end :)
20:48:55  <indutny>haha
20:49:04  <indutny>well, the only thing that can be hurt by this is performance
20:49:09  <bnoordhuis>i guess you should talk to isaacs, he's planning to rewrite http for v0.12
20:49:10  <indutny>but I'll look closely at it
20:49:23  <indutny>bnoordhuis: ah, ok... is he on txjs?
20:49:27  <bnoordhuis>yeah
20:49:55  <indutny>are they're like sitting at ranchos, drinking beer and fighting with bulls?
20:50:04  <indutny>that's how I imagine texas
20:51:50  <CoverSlide>that is 100% accurate. just ask creationix
20:52:23  <creationix>CoverSlide: let me take a picture of my street to confirm
20:52:44  <indutny>hahaha
20:53:01  <trevnorris>bnoordhuis: mind sharing your thoughts on http://git.io/VRH4_w
20:53:03  <trevnorris>best I can figure is that ClientHelloParser::Write is passing the wrong "session_size" to Buffer::New
20:53:46  <bnoordhuis>trevnorris: that's v8
20:54:01  <bnoordhuis>well, mostly v8
20:54:16  <bnoordhuis>which is kind of worrying actually
20:54:20  <indutny>trevnorris: what do you mean by wrong?
20:54:23  <bnoordhuis>because i've never seen that
20:54:23  <trevnorris>bnoordhuis: well, if I run the same before the changes, those don't pop up.
20:54:28  <bnoordhuis>ah
20:54:37  <indutny>trevnorris: what changes?
20:54:44  <trevnorris>indutny: my buffer changes.
20:54:47  <indutny>ah
20:55:03  <trevnorris>indutny: right now they pass all tests, but the benchmark tls-connect explodes on gc
20:55:20  <indutny>gosh
20:55:23  <indutny>no good
20:55:38  <bnoordhuis>hard to say what goes wrong without looking at the code
20:55:38  <tjfontaine>you mentioned that tls benchmark explodes on master now anyway?
20:55:40  <creationix>CoverSlide: https://twitter.com/creationix/status/324264805189959681
20:55:45  <bnoordhuis>(which i don't have time for right now)
20:55:55  <trevnorris>tjfontaine: well. but for an unrelated reason.
20:56:01  <tjfontaine>right
20:56:06  <tjfontaine>still he should know
20:56:14  <trevnorris>tjfontaine, indutny: this: https://gist.github.com/trevnorris/5390043
20:56:39  <tjfontaine>hmm was it socket closed, that's an interesting case
20:57:07  <trevnorris>bnoordhuis: understand. i'm giving that problem a rest today anyways. been working on it too long.
20:57:15  <indutny>creationix: I can't see any bulls around there
20:57:16  <indutny>:)
20:57:41  <creationix>no, but my neighbor does live in a trailer that's smaller than his red barn and there is horse poop on the road
20:58:00  <indutny>great!
20:58:08  <indutny>I should definitely visit TX
21:02:15  <trevnorris>indutny: mind giving feedback on http://git.io/uEnayw normally I wouldn't care, but it's preventing me to use debug mode on that test.
21:03:25  <indutny>its like
21:03:29  <indutny>something got crappy
21:04:12  <trevnorris>yeah. and since it doesn't happen outside of debug mode, i'm not sure how to judge it.
21:04:26  <indutny>trevnorris: can you add logging
21:04:27  <indutny>?
21:04:46  <indutny>in deps/v8/src/objects-inl.h VerifyApiCallResultType()
21:04:51  <indutny>in if's body
21:05:03  <indutny>just fprintf("%p\n", this)
21:05:06  <indutny>or something like that
21:05:13  <trevnorris>sure. np
21:05:25  <indutny>basically it looks like v8 has run out of memory
21:05:29  <indutny>when it was in API call
21:06:50  <indutny>and also
21:06:53  <indutny>try updating v8 itself
21:07:04  <indutny>it might be some bug that was already fixed
21:07:24  * rendarquit
21:08:30  <trevnorris>indutny: ok. we're on latest release (3.17.16) but i'll throw in bleeding_edge and see what happens.
21:08:55  * jmar777joined
21:11:39  * `3rdEdenquit (Remote host closed the connection)
21:19:12  <MI6>joyent/node: Ben Noordhuis v0.10 * ccd3722 : handle_wrap: fix NULL pointer dereference Fix a NULL pointer dereference - http://git.io/Z37utA
21:19:19  <MI6>joyent/node: Ben Noordhuis v0.8 * 0801a18 : handle_wrap: fix NULL pointer dereference Fix a NULL pointer dereference - http://git.io/l_DRQg
21:19:48  <indutny>nice
21:20:00  <indutny>trevnorris: don't forget about logging
21:20:11  <trevnorris>indutny: will do.
21:20:30  <bnoordhuis>indutny: https://github.com/joyent/node/pull/5312 <- i think that's your cue
21:21:38  <indutny>can't open anything :(
21:21:42  <indutny>internet is awful at bahamas
21:21:52  <indutny>though, ocean is great and there're a lot of fun
21:21:55  <indutny>not sure...
21:22:02  <tjfontaine>and alcohol
21:22:21  <bnoordhuis>pina colada!
21:22:26  <indutny>white russian
21:22:29  <bnoordhuis>indutny: because i'm such a nice guy
21:22:31  <bnoordhuis> When a new TCP stream is established. `socket` is an object of type
21:22:31  <bnoordhuis>- `net.Socket`. Usually users will not want to access this event. The
21:22:31  <indutny>my favourite
21:22:31  <bnoordhuis>- `socket` can also be accessed at `request.connection`.
21:22:31  <bnoordhuis>+ `net.Socket`. Usually users will not want to access this event. In
21:22:33  <bnoordhuis>+ particular, the socket will not emit `readable` events because of how
21:22:36  <bnoordhuis>+ the protocol parser attaches to the socket. The `socket` can also be
21:22:38  <bnoordhuis>+ accessed at `request.connection`.
21:22:45  <indutny>aha
21:22:50  <indutny>this is very cute
21:22:54  <bnoordhuis>i used to drink that in my young urban hipster days
21:23:13  <indutny>bnoordhuis: I'm not really drinking much, it just reminds me about Lebovsky
21:23:30  <tjfontaine>in small quantities coconut is good, but I overindulged when I was younger so I can't take the flavor for long
21:23:57  <indutny>bnoordhuis: generally this changes looks good to me
21:24:06  <indutny>but I feel pain of our users
21:24:14  <indutny>because of this .ondata crap
21:25:03  <bnoordhuis>the feeling goes away, you grow impervious to it
21:25:04  <trevnorris>indutny: wtf. the last address from fprintf is "0x1baddead0baddeaf"
21:25:10  <indutny>ahha
21:25:14  <bnoordhuis>poison!
21:25:20  <indutny>magic bytes
21:25:38  <indutny>that's HandleZapValue
21:26:40  <indutny>trevnorris: its like
21:26:46  <indutny>v8 is accessing closed handlescope
21:26:54  <indutny>or
21:28:15  <indutny>DeferredHandles
21:28:17  <indutny>wtf is this
21:28:19  <indutny>ok anyway
21:28:24  <bnoordhuis>1 file changed, 239 insertions(+), 503 deletions(-)
21:28:28  <bnoordhuis><3
21:28:30  <indutny>bnoordhuis: what's that?
21:28:37  <bnoordhuis>lib/cluster.js
21:28:37  <trevnorris>indutny: in the backtrace, says for V8_Fatal "Contains protection against recursive calls (faults while handling faults)."
21:28:40  <tjfontaine>something got rewritten
21:28:54  <indutny>trevnorris: oh, that's different from previous one
21:29:12  <indutny>can you show me backtrace?
21:29:13  <trevnorris>indutny: ah, maybe that's because of upgrading v8
21:29:13  <indutny>bnoordhuis: finally!
21:29:15  <trevnorris>sure
21:29:21  <indutny>bnoordhuis: that's such a crap
21:29:26  <bnoordhuis>yeah
21:29:29  <indutny>I hope you've figured it out
21:29:32  <tjfontaine>bnoordhuis: speaking of, did you happen to look at https://github.com/tjfontaine/node/compare/http-split
21:29:36  <bnoordhuis>i was going to add round robin
21:29:36  <indutny>Andreas was good at ideas
21:29:40  <indutny>but bad on implementing them
21:29:44  <indutny>sadly
21:29:54  <bnoordhuis>it's a fair bit cleaner now
21:30:00  <indutny>bnoordhuis: and please take a look at my writev patch too :)
21:30:07  <indutny>I believe its ready for prime-time
21:30:21  <trevnorris>indutny: https://gist.github.com/trevnorris/5399818
21:30:24  <bnoordhuis>tjfontaine: 8 changed files with 2,186 additions and 1,955 deletions. :(
21:30:31  <tjfontaine>:P
21:30:43  <trevnorris>indutny: oh, one sec. i'll add the stuff from gdb
21:30:44  <bnoordhuis>i guess you don't hear this often but... it's so big
21:30:49  <tjfontaine>mostly in copyright lines
21:30:52  * bnoordhuisducks
21:30:56  <tjfontaine>heh
21:31:08  <tjfontaine>bnoordhuis: hey at least this time I broke it into steps
21:31:09  <indutny>bnoordhuis: I think he don't hear this often from men
21:31:14  * indutnyducks
21:32:16  <bnoordhuis>+// New Agent code.
21:32:26  <bnoordhuis>ain't that a lie? (by now)
21:32:48  <tjfontaine>I resisted the urge to make cleanups for that sort of thing in this pass
21:33:05  <bnoordhuis>it's moved verbatim, no fixups?
21:33:10  <tjfontaine>that's correct
21:33:23  <tjfontaine>well, moved with enough changes to make it work
21:33:25  <bnoordhuis>okay. i was going to bitch about style but i guess i'll let that pass :)
21:33:28  <tjfontaine>haha
21:33:41  <tjfontaine>there may be some dropped lines between functions or additions
21:33:46  <tjfontaine>but in general it's copy paste
21:34:17  <tjfontaine>this is pass one at just making it managable
21:34:41  <trevnorris>indutny: ok, here's a bunch from gdb: https://gist.github.com/trevnorris/5399818
21:35:50  <trevnorris>indutny: the ASSERT that fails is at the bottom.
21:36:11  <indutny>aha
21:36:17  <indutny>gotcha
21:36:25  <indutny>I think you should fill v8 issue
21:36:35  <indutny>and mention that it meets HandleZap value here
21:36:43  <indutny>this guys are good at triaging such things
21:37:26  <bnoordhuis>tjfontaine: looks pretty uncontroversial to me
21:37:28  <trevnorris>indutny: ok, will do.
21:37:43  <tjfontaine>bnoordhuis: nod, but I think you landed an http.js patch recently that I will need to include
21:37:51  <bnoordhuis>i did?
21:37:56  <tjfontaine>or maybe it's a pullreq
21:38:08  <bnoordhuis>indeed i did
21:38:20  <tjfontaine>ya the url escaping
21:38:29  <bnoordhuis>didn't realize isaac had already landed that
21:39:00  <bnoordhuis>if you merge that back in, i'll land it
21:39:11  <bnoordhuis>or i can do it for you, it's a patchlet really
21:39:28  <indutny>mmalecki: hahaha http://www.explosm.net/comics/3142/
21:39:45  <tjfontaine>I'm curious if a rebase will work
21:40:37  <mmalecki>indutny: I mean, I'm not *that* much of a grammar nazi :)
21:40:44  <indutny>hahahahaha
21:40:50  <bnoordhuis>is jenkins dead? or does it skip PRs that only touch files in doc/ ?
21:41:05  <tjfontaine>bnoordhuis: hm?
21:41:16  <indutny>smartass
21:41:18  <tjfontaine>jenkins doesn't autobuild unless you're one of "us"
21:41:24  <bnoordhuis>https://github.com/joyent/node/pull/5312
21:41:32  <bnoordhuis>that guy is not on the list
21:41:35  <mmalecki>bnoordhuis: jenkins is dead to me
21:41:38  <bnoordhuis>aw
21:41:52  <bnoordhuis>let me get my violin and play a sad song for you
21:42:00  * c4miloquit (Remote host closed the connection)
21:42:11  <tjfontaine>not on what list? the cla? Ryan Graham r.m.graham@gmail.com
21:42:35  <bnoordhuis>oh, what the hell?
21:42:54  <bnoordhuis>ctrl-f didn't find him the first time around
21:42:58  <tjfontaine>jankins and my chrome plugin see him
21:43:19  <bnoordhuis>okay, nvm then :)
21:44:17  <MI6>joyent/node: Ryan Graham v0.10 * b02b93b : doc: note a gotcha with http.Server sockets - http://git.io/Gv3ahA
21:44:32  <saghul>hi guys, i'd like to have a uv_is_refd function to make ref/unref a property in Python land, thoughts?
21:45:11  <tjfontaine>hmm, does it matter since it's idempotent?
21:45:12  <saghul>example: handle.ref = True
21:45:28  <saghul>i can't have setter only properties AFAIK
21:45:44  <saghul>so returning the actual state would be nice
21:46:38  <tjfontaine>but couldn't the consumer just trigger their intent regardless of if it's already been [un]ref'd?
21:46:47  <trevnorris>indutny: thanks for the help. though that probably wouldn't be affecting my "corrupted double-linked list" huh?
21:46:57  <indutny>huuuh?
21:47:21  <indutny>what double-linked list?
21:47:27  <indutny>are you using double-linked list?
21:47:38  <saghul>tjfontaine probably, but it doesn't look good to get None back if you check the property value
21:47:58  <trevnorris>indutny: i'm getting that error w/ the new buffers running the same benchmark.
21:48:06  <tjfontaine>saghul: so you use a property instead of a function for this?
21:48:26  <saghul>tjfontaine I was thinking about it, currently I have the 2 functions
21:48:34  <trevnorris>indutny: here's the valgrind output: https://gist.github.com/trevnorris/5391372
21:48:48  <saghul>if I have uv_is_refd I could write it as a property
21:48:49  <tjfontaine>saghul: couldn't you default to True, and then set it yourself, afaik the core doesnt' do any unref'ing without your knowledge
21:49:03  <tjfontaine>though I guess if the req is complete
21:49:07  <indutny>ah, right right
21:49:29  <indutny>oh gosh
21:49:37  <tjfontaine>saghul: I'm not too fussed, I'll leave it to bnoordhuis :)
21:49:39  <saghul>tjfontaine yes, but I don't want to keep state myself if libuv is already doing it ;-)
21:50:47  <tjfontaine>saghul: do it now, and if libuv gets it -- even better :)
21:51:34  <trevnorris>indutny: is that an "oh gosh, your code is totally screwed"? =)
21:51:49  <indutny>nono
21:51:52  <indutny>let me think about it
21:52:15  <indutny>it might be that you're creating a handle in one handlescope
21:52:18  <indutny>and using it outside it
21:52:24  <indutny>without scope.Close()ing it
21:52:29  <indutny>but... let me recheck it
21:54:02  <saghul>tjfontaine i'll write a patch while HIMYM is downloading :-)
21:54:20  <tjfontaine>hehe
21:54:32  <MI6>nodejs-v0.10: #138 FAILURE smartos-x64 (2/577) windows-ia32 (5/577) linux-x64 (2/577) windows-x64 (8/577) osx-ia32 (1/577) smartos-ia32 (2/577) osx-x64 (2/577) linux-ia32 (1/577) http://jenkins.nodejs.org/job/nodejs-v0.10/138/
21:56:05  <trevnorris>indutny: oh son of a bitch. here's the line that was screwing me: https://github.com/trevnorris/node/blob/buffer-buffet/src/node_smalloc.cc#L295
21:56:17  <indutny>aha
21:56:19  <trevnorris>changed it to a Persistent<>::New() and now it works.
21:56:26  <indutny>obviously
21:56:30  <indutny>ok, that's much better
21:56:38  <indutny>you see! :)
21:56:46  <indutny>my magic has touched you
21:56:50  <indutny>and you was enlightened
21:57:24  <trevnorris>indutny: lol. well I wish your magic was around last friday, before I spent two full days debugging that thing.
21:57:32  <indutny>hahaha
21:57:39  <indutny>you should just print out things more
21:57:51  <indutny>this helps a lot
21:58:40  <trevnorris>hm. tried that. must not have been printing the right thing in the right place.
21:59:16  <trevnorris>think I would have hit that same HandleZap if I had?
22:00:05  <tjfontaine>ok I think I know what's making things angry
22:00:16  <tjfontaine>basically every time we build v0.8 on windows it breaks the shit out of jenkins
22:00:29  <tjfontaine>well every time we test v0.8 on windows
22:00:50  <indutny>trevnorris: yep
22:01:05  <indutny>trevnorris: you should print more
22:01:06  * mikealquit (Quit: Leaving.)
22:01:13  <indutny>but it really depends on situation
22:01:19  <indutny>sometimes you just need to sit and think
22:01:27  * defunctzombie_zzchanged nick to defunctzombie
22:01:58  <trevnorris>i'll keep that in mind. was being too selective about where I was printing.
22:02:34  <indutny>you're welcome
22:02:42  <trevnorris>indutny: well thanks again. that was the last major blocker. just a little more tuning and the new buffers will be ready for a test drive.
22:02:49  <indutny>kewl
22:02:53  <indutny>looking forward for it
22:03:09  <tjfontaine>bnoordhuis: turned out isaacs change was a bit more troublesome to rebase than yours, yours was actually fine because that part hasn't left lib/http.js
22:04:27  <tjfontaine>bnoordhuis: anyway, force-pushed
22:04:38  <MI6>joyent/node: Kelly Gerber v0.10 * 36503b5 : docs: update path.join() example for v0.10 The current example shows the - http://git.io/A13CgQ
22:04:40  <MI6>nodejs-v0.8: #38 ABORTED windows-x64 (5/471) smartos-x64 (2/471) osx-x64 (2/471) smartos-ia32 (2/471) osx-ia32 (3/471) linux-x64 (6/471) linux-ia32 (2/471) http://jenkins.nodejs.org/job/nodejs-v0.8/38/
22:04:46  <indutny>ttyl
22:04:57  <trevnorris>see ya
22:05:39  <MI6>nodejs-v0.10: #139 ABORTED smartos-x64 (3/577) linux-x64 (1/577) windows-x64 (8/577) osx-ia32 (1/577) smartos-ia32 (2/577) osx-x64 (2/577) linux-ia32 (2/577) http://jenkins.nodejs.org/job/nodejs-v0.10/139/
22:07:32  <creationix>I know node doesn't expose an event source hook, but is there a way at the libuv level to hook into every event that's about to be dispatched?
22:07:55  <creationix>ideally I would be able to write a binding that exposes a JS api to insert a frame into the top of every event stack
22:08:37  <trevnorris>creationix: eh? can you explain a little more of what you're looking for.
22:08:48  <bnoordhuis>creationix: there isn't
22:08:55  <creationix>process.on('event', function (type, handlerFn) { var before = Date.now(); handlerFn(); console.log(type, Date.now() - before); })
22:09:05  <MI6>nodejs-v0.10: #140 ABORTED http://jenkins.nodejs.org/job/nodejs-v0.10/140/
22:09:15  <creationix>or I could wrap a try..catch around the handlerFn and implement something like domains
22:09:26  <creationix>the possibilities are endless
22:09:45  <creationix>bnoordhuis: how do domains integrate with this?
22:09:51  <creationix>don't they need something like this?
22:10:06  <bnoordhuis>domains are passive until something breaks
22:10:26  <trevnorris>bnoordhuis: are only callbacks that are fired through the event emitter considered "events"?
22:10:39  <bnoordhuis>they keep track of all handle-backed objects so they always know what needs to be destroyed
22:11:01  <creationix>event emitters are not real event sources, I want to hook into all new js stacks
22:11:12  <bnoordhuis>trevnorris: no, events in this context means any external input, e.g. i/o, timers, etc.
22:11:32  <trevnorris>ah, so basically each step of uv_run i'll take it.
22:11:38  <creationix>bnoordhuis: several events may be processed in a single call to uv_run_once right?
22:11:44  <bnoordhuis>creationix: is this specific to node or ?
22:11:53  <creationix>bnoordhuis: I want to write a node addon
22:11:58  <bnoordhuis>because in that case you could patch MakeCallback()
22:12:13  <creationix>so nothing at the libuv level?
22:12:18  <bnoordhuis>nope
22:12:27  <bnoordhuis>uv_run_once can indeed dispatch multiple events
22:12:49  <bnoordhuis>though it's called uv_run(loop, UV_RUN_ONCE) now
22:12:53  <creationix>I was afraid of that
22:12:59  <creationix>(the nope)
22:13:04  <bnoordhuis>:)
22:13:23  <bnoordhuis>i don't think it would be possible to implement something like that on windows
22:13:33  <creationix>bnoordhuis: indeed, the api change broke my other addon https://github.com/creationix/uvrun/commit/fed9931ed15cf3f42623098b1ac2c5b8eb8201d4
22:13:38  <bnoordhuis>i.e. a UV_RUN_SINGLE_EVENT mode
22:14:16  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:14:31  <bnoordhuis>you could #ifdef on UV_VERSION_MAJOR and UV_VERSION_MINOR
22:14:46  <creationix>good point
22:14:48  <bnoordhuis>saves having to hack your binding.gyp
22:14:50  <creationix>it wasn't my patch
22:15:18  <MI6>joyent/node: Timothy J Fontaine master * 951e0b6 : http: split Client into _http_client.js (+5 more commits) - http://git.io/VMNRwA
22:15:28  * TooTallNatejoined
22:15:29  <tjfontaine>and then the world ended
22:15:36  <bnoordhuis>isaac is going to hate that whenever he's merging v0.10 into master :)
22:15:44  <tjfontaine>hehe
22:16:26  <tjfontaine>hopefully he does that when he's not sitting beside me, or at least that I'm out of throwing range
22:16:45  <bnoordhuis>heh, indeed
22:17:28  <creationix>bnoordhuis: where is MakeCallback?
22:17:36  <tjfontaine>src/node.cc
22:18:13  <trevnorris>bnoordhuis: wtf. not sure when, but "http/cluster.js type=bytes length=102400 c=50" on master runs 880, on latest v0.10 run 2500.
22:18:51  <trevnorris>just fyi. i'm going to look into it.
22:19:33  <tjfontaine>trevnorris: you might want to wait until his rewrite lands, hate to see you spend time working on something he's ripped a crapload out of
22:19:52  <trevnorris>tjfontaine: oh, is this being actively worked on?
22:20:15  <trevnorris>wow, been really out of touch.
22:20:25  <tjfontaine>[04-16] 21:28:23 < bnoordhuis> 1 file changed, 239 insertions(+), 503 deletions(-)
22:20:29  <tjfontaine>earlier
22:20:34  <trevnorris>ah, ok
22:21:08  <tjfontaine>not sayign there won't be a perf problem afterward, but you won't be looking at the same thing
22:21:19  <trevnorris>ok. sounds good.
22:21:36  <creationix>bnoordhuis: I see, though I have no idea how to hook into makecallback from a node addon. you can't monkey-patch C++ like that can you?
22:23:13  <trevnorris>creationix: nope. also MakeCallback is slightly more complicated, since there's actually a MakeDomainCallback w/ the domain logic.
22:23:55  <trevnorris>creationix: though, i can think of a simple-ish abstraction that would allow for someone to pass their own MakeCallback. though that'd be dangerous.
22:24:26  <creationix>in luvit I allowed a call frame to be inserted into all event sources
22:24:31  <bnoordhuis>trevnorris: is v8 compiled with optimizations?
22:24:35  <creationix>of course it's dangeroud, but very powerful too
22:24:38  <creationix>*dangerous
22:24:56  <tjfontaine>oh of course he changed his v8 for the tls thing
22:25:41  <trevnorris>bnoordhuis: should be. you reapplied the patches in 7357bcb72 after the upgrade to 3.17.16
22:26:00  <tjfontaine>trevnorris: weren't you trying bleeding edge for indutny?
22:26:43  <trevnorris>tjfontaine: yeah. just for that test though. since I have it going, want me to run anything else?
22:27:22  <tjfontaine>no I was just curious if maybe that's what you were testing cluster with and that's where the opts were dropped, or if it itself has another perf regress
22:27:48  <bnoordhuis>trevnorris: you need to apply the changes to deps/v8/build/common.gypi in 7357bcb72
22:27:56  <bnoordhuis>otherwise, v8 gets built at -O0
22:28:20  <trevnorris>bnoordhuis: oh, I wasn't running the test on bleeding_edge. that was on latest master.
22:28:27  <bnoordhuis>ah okay
22:28:40  <trevnorris>bnoordhuis: the strange thing was it only slowed down on very large length.
22:28:48  <trevnorris>for length <= 1024 it ran just as fast.
22:29:21  <creationix>hmm, I wonder if there is an easier way to measure number of ticks or the time each one takes to execute
22:29:26  <trevnorris>(vary large as in length == 102400)
22:30:04  <trevnorris>creationix: are you specifically looking for how long a function takes to run?
22:30:46  <tjfontaine>creationix: I added dtrace probes to uv for that
22:30:54  <creationix>for event sources?
22:30:57  <creationix>or all functions
22:31:31  <tjfontaine>for tick-start and tick-end
22:31:36  <creationix>cool
22:31:45  <creationix>does dtrace work on linux yet?
22:32:01  <tjfontaine>for some values of linux, but they would work systemtap
22:32:10  <tjfontaine>*with
22:32:30  <creationix>the dtrace probes work with systemtap?
22:32:33  <tjfontaine>yes
22:32:35  <creationix>that's cool
22:32:39  <creationix>I should learn how to do that
22:32:57  <tjfontaine>wolfeidau has a gist with the branch I updated and how to do it
22:33:07  <creationix>is this hook in node 0.10?
22:33:12  <creationix>s/hook/probe/
22:33:23  <tjfontaine>not at the moment
22:33:41  <wolfeidau>The system tap one is here https://gist.github.com/wolfeidau/5282942
22:33:48  <MI6>nodejs-v0.10: #141 UNSTABLE smartos-x64 (3/577) windows-ia32 (6/577) linux-x64 (2/577) windows-x64 (6/577) osx-ia32 (1/577) smartos-ia32 (5/577) osx-x64 (2/577) linux-ia32 (2/577) http://jenkins.nodejs.org/job/nodejs-v0.10/141/
22:35:06  <wolfeidau>has been very handy so far to peak into node
22:35:29  <creationix>Nice
22:35:59  <creationix>heh, I can't install this on my chromebook
22:36:04  <creationix>I don't have kernel headers
22:36:08  <creationix>I'm in an ubuntu chroot
22:36:25  <tjfontaine>I need to redo my uv-dtrace+node branch, and then fold that into the system tap branch
22:37:49  <creationix>wolfeidau: are the debug symbols required?
22:37:56  <tjfontaine>yes
22:38:18  <creationix>I doubt the stock chromeos kernel has those
22:38:45  <tjfontaine>ya systemtap working on chromeos is probably unlikely
22:38:50  <creationix>oh well
22:38:53  <creationix>I've got other linux boxes
22:40:18  <creationix>thanks for the help guys
22:43:45  <txdv>creationix: why would you expose uv_run and uv_run_once to node?
22:45:35  <tjfontaine>sometimes, especially in gui land, you want to trigger a loop
22:46:06  <txdv>there are no good nodejs bindings for gui libs
22:46:47  <MI6>nodejs-master: #152 FAILURE linux-ia32 (1/580) windows-ia32 (7/580) windows-x64 (6/580) linux-x64 (1/580) http://jenkins.nodejs.org/job/nodejs-master/152/
22:46:53  <tjfontaine>mother
22:47:07  <tjfontaine>fuck you windows, fuck you properly
22:47:26  <txdv>windows just fucked you
22:51:28  <txdv>creationix: i hope you participated in the libgit2 project enough to take onto a full fledged js implemenetation of it
22:51:59  <trevnorris>ah, my day is complete. windows has broken tjfontaine. ;-)
22:52:19  * tjfontainehides in the corner
22:53:55  <wolfeidau>creationix: It is the biggest pig of a thing to get installed, but once it is magic happens :)
22:54:54  <wolfeidau>I have a 13.04 vm which is now snapshotted and backed up and i am not going to install ANYTHING on it cause at the moment it is working fine
22:54:55  <creationix>txdv: I skimmed the libgit2 repo
22:55:06  <creationix>does that count
22:56:11  <txdv>the easiest approach will be to compile it with llvm and to expose a sane js api
22:56:19  <txdv>but that isn't worth 20k
22:56:29  <creationix>txdv: except there is no real fs
22:56:40  <creationix>and the network apis are very restricted
22:57:25  <creationix>txdv: also join #js-git if you want to be involved
22:57:27  <txdv>well, you want to emulate everything on top of buffers and bytearrays anyway if you write a pure js implementation
22:57:44  <creationix>chrisdickinson has done most the work so far
22:58:03  <chrisdickinson>hi hi
22:58:32  <txdv>well, he didn't push anything so I can't see
22:58:43  <creationix>right, my repo is still empty
22:58:46  <creationix>but he has several repos
22:58:50  <creationix>linked in an issue on mine
22:59:24  <chrisdickinson>txdv: https://github.com/chrisdickinson?tab=repositories
22:59:59  <chrisdickinson>also, libgit2 is predicated on the idea that reading will be synchronous
23:00:07  <bnoordhuis>signing off for today. have a good night, guys
23:00:41  <txdv>writing data processing abstractions on top of C is very hard
23:01:01  <txdv>so yeah, no doubt it is
23:01:05  * wolfeidauquit (Remote host closed the connection)
23:01:39  <txdv>we have entire java coder generations fucked up by synchronous api...
23:02:54  <txdv>chrisdickinson looks like if he would put all the repos he wrote into one big one, he might be already halfway there
23:04:23  <txdv>distributing the packer into web workers in order to parralize workload in js will be fun
23:04:33  <chrisdickinson>they're all in small ones so folk can reuse whatever bits they need, hopefully
23:05:02  * trippehquit (Ping timeout: 245 seconds)
23:05:05  * bnoordhuisquit (Ping timeout: 252 seconds)
23:05:20  <txdv>chrisdickinson: that makes sense if you are writing small web apps specialized in one thing
23:05:37  <txdv>but having a few porcelain functions of git won't help the user
23:05:57  <chrisdickinson>yes, there will be larger porcelain modules that tie several together
23:06:07  <chrisdickinson>web workers aren't too much of an issue
23:06:41  <txdv>i hope you will succeed, because I am a git fan and I understand that JS will be the runtime of the future web
23:06:58  <txdv>but I think that writing a pure js implementation will be a big pain in the ass
23:07:32  <txdv>look at libgit2, there are several high skilled developers involved and they are just starting to reach normal git functionality after 2 years
23:12:37  <txdv>maybe cleaning out the libgit2 api, so the functionality needed to parse data didn't depend on sync api
23:14:18  <txdv>I don't know, chrisdickinson you seem like you had more to do with this entire thing, I am just spitting out stuff that I think about this project
23:15:29  <creationix>txdv: I haven't started real work on js-git yet, so I can't comment much on technical specefics
23:15:40  <creationix>but like I said, we have a room at #js-git
23:18:41  * wolfeidaujoined
23:22:53  * trippehjoined
23:36:49  * c4milojoined
23:39:45  <MI6>nodejs-master: #153 UNSTABLE linux-ia32 (1/580) windows-ia32 (7/580) windows-x64 (6/580) http://jenkins.nodejs.org/job/nodejs-master/153/