--- Log opened Thu Mar 28 00:00:35 2013
00:03 <@isaacs> i see
00:03 <@isaacs> bnoordhuis: i though we were upgrading libuv to specific versinos now
00:04 < bnoordhuis> isaacs: i was going to ask about that
00:04 < bnoordhuis> if i fix something in libuv, should i hold off landing it in node until the next release?
00:04 <@isaacs> hm.
00:04 <@isaacs> yeah, you know, i'm kind of torn there.
00:13 <@isaacs> bnoordhuis: on the one hand, it's kind of nice that npm and v8 etc all have a very predictable thing you can point at, and say "that's the version we're using"
00:14 <@isaacs> and now that libuv has those, it kind of seems reaosnable to do the same thing
00:14 <@isaacs> of course, i usually just cut an npm build right before building node, so it's rather arbitrary
00:19 <@TooTallNate> bnoordhuis: if it's not a huge pain it's probably more *proper* to do a quick release each time
00:19 <@TooTallNate> if we wanna strictly follow semver and all that jazz
00:20 < bnoordhuis> TooTallNate: well, i don't really care either way
00:20 < bnoordhuis> i imagine it's inconvenient for users though
00:20 < bnoordhuis> now you can tell them "upgrade to HEAD, it's fixed there"
04:18 -!- mode/#libuv [+o TooTallNate] by ChanServ
04:31 < tjfontaine> I wonder how I convinced it to do this
04:31 < tjfontaine> Error: ld.so.1: node: fatal: /home/jenkins/.jenkins/workspace/downstream-modules/DESTCPU/x64/label/smartos/test_modules/ffi/node_modules/ref/build/Release/binding.node: wrong ELF class: ELFCLASS32
08:45 <@indutny> morning
11:26 -!- Topic for #libuv: And we're going to die at "liberal utopian vacation" day. ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
11:26 -!- Topic set by indutny [indutny@bird.c.ircrelay.com] [Mon Mar 18 17:12:47 2013]
11:26 [Users #libuv]
11:26 [@indutny  ] [ chrisdickinson  ] [ hij1nx      ] [ LOUDBOT      ] [ Ralt     ] [ SomeoneWeird] 
11:26 [@isaacs   ] [ CoverSlide      ] [ ircretary   ] [ MI6          ] [ Raynos   ] [ stephank    ] 
11:26 [@ryah     ] [ creationix      ] [ isaacs_     ] [ mikeal       ] [ rendar   ] [ tellnes     ] 
11:26 [ `3E|BRB  ] [ csaoh           ] [ jez0990     ] [ mmalecki[out]] [ rje      ] [ tjfontaine  ] 
11:26 [ abraxas_ ] [ davisp          ] [ joclek      ] [ mraleph      ] [ roxlu    ] [ toothr      ] 
11:26 [ AvianFlu ] [ defunctzombie_zz] [ joshthecoder] [ niska        ] [ rphillips] [ txdv_       ] 
11:26 [ benoitc  ] [ dpemmons        ] [ Kakera      ] [ othiym23     ] [ russell_h] [ wolfeidau   ] 
11:26 [ brucem   ] [ DrPizza         ] [ karupanerura] [ paddybyers   ] [ rvagg    ] 
11:26 [ chilts   ] [ dsantiago       ] [ kazupon     ] [ philips      ] [ saghul   ] 
11:26 [ Chip_Zero] [ dscape          ] [ KiNgMaR     ] [ pquerna      ] [ skebcio  ] 
11:26 [ chobie1  ] [ einaros_        ] [ kuplatupsu  ] [ qmx|away     ] [ slurp    ] 
11:26 -!- Irssi: #libuv: Total of 62 nicks [3 ops, 0 halfops, 0 voices, 59 normal]
11:26 -!- Channel #libuv created Fri May 13 13:43:45 2011
11:27 -!- mode/#libuv [+o ryah] by ChanServ
11:27 -!- Irssi: Join to #libuv was synced in 29 secs
11:54 -!- mode/#libuv [+o piscisaureus_] by ChanServ
13:03 < MI6> joyent/node: Marcin Kostrzewa master * 1f55704 : util: fix util.inspect() line width calculation  Have the formatter filte - http://git.io/v6XGVA
13:24 < MI6> nodejs-master: #122 UNSTABLE osx-x64 (1/569) linux-x64 (1/569) windows-ia32 (4/569) osx-ia32 (4/569) windows-x64 (5/569) smartos-ia32 (1/569) smartos-x64 (1/569) http://jenkins.nodejs.org/job/nodejs-master/122/
13:26 < MI6> nodejs-review: #1 FAILURE osx-x64 (7/543) smartos-ia32 (6/543) windows-x64 (16/543) osx-ia32 (10/543) linux-ia32 (6/543) linux-x64 (5/543) smartos-x64 (5/543) http://jenkins.nodejs.org/job/nodejs-review/1/
13:41 < MI6> nodejs-review: #2 FAILURE windows-x64 (11/546) osx-ia32 (2/546) linux-x64 (1/546) http://jenkins.nodejs.org/job/nodejs-review/2/
13:43 < bnoordhuis> Chrome OS Laptop (CHROMEOS_LAPTOP) [N/m/y/?] (NEW) <- nice, mainline support for chromeos hw
13:48 <@indutny> bnoordhuis: ?
13:48 <@indutny> where?
13:50 < bnoordhuis> indutny: the linux kernel
13:50 <@indutny> ah, that
13:50 <@indutny> ok
13:56 < MI6> nodejs-review: #3 UNSTABLE windows-ia32 (4/557) windows-x64 (5/557) osx-ia32 (2/557) linux-x64 (1/557) http://jenkins.nodejs.org/job/nodejs-review/3/
14:17 < tjfontaine> hmm wtf was the review branch doing
14:17 < tjfontaine> oh I see, well that's stupid.
14:58 < saghul> wow, mr jerkins is crazy fast with checking pull requests for formatting issues :-O
14:59 < saghul> bnoordhuis a one liner https://github.com/joyent/libuv/pull/756
14:59 -!- mode/#libuv [+o piscisaureus_] by ChanServ
15:04 <@piscisaureus_> hello
15:12 < bnoordhuis> sup bertje?
15:13 < MI6> joyent/libuv: Saúl Ibarra Corretgé v0.10 * a9a23dc : unix: don't clear flags after closing UDP handle - http://git.io/yJag6Q
15:14 < bnoordhuis> saghul: btw, i saw your pyuv udp commits from last night
15:14 <@piscisaureus_> nice: https://github.com/joyent/libuv/pull/756#issuecomment-15592727
15:14 < bnoordhuis> looks like aprime candidate for container_of
15:14 < bnoordhuis> *a prime
15:14 <@piscisaureus_> Will it also check if someone signed the CLA ?
15:14 < bnoordhuis> that'd be sweet
15:14 < saghul> bnoordhuis I know, that's what real men use, right? :-)
15:15 < saghul> I have a major change in the pipeline, it's on the todo list :-) btw, is container_of exposed by libuv?
15:15 <@piscisaureus_> uv_container_of
15:15 < MI6> libuv-v0.10: #22 UNSTABLE windows (7/187) linux (2/186) osx (1/186) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/22/
15:15 <@piscisaureus_> actually, I'd dig that
15:16 < saghul> will do, thanks!
15:19 < bnoordhuis> saghul: you can steal the QUEUE_DATA definition from src/queue.h
15:19 < bnoordhuis> doesn't depend on any headers
15:19 < saghul> sweet
15:39 <@piscisaureus_> Windows is confusing me
15:39 < dostoyevsky> Somehow I am not deleting my timers correctly...
15:49 < MI6> joyent/node: Suwon Chae master * 120e5a2 : os: use %SystemRoot% or %windir% in os.tmpdir()  On Windows, respect the  - http://git.io/cmolKg
15:53 < MI6> joyent/node: bruston v0.10 * e103778 : doc: debugger, dns, http: fix grammar - http://git.io/dqj3Dg
15:54 < bnoordhuis> aww
15:54 < MI6> joyent/node: Benjamin Ruston v0.10 * 024a8b0 : doc: debugger, dns, http: fix grammar - http://git.io/SBKISw
15:59 < tjfontaine> piscisaureus_, bnoordhuis yes it also checks the cla
16:00 <@piscisaureus_> tjfontaine: remind me to buy you a sea of beer if we ever meet
16:00 < tjfontaine> heh sounds good
16:01 < tjfontaine> https://github.com/tjfontaine/jankins/blob/master/pullrequests.js#L70 the start of the checks it does
16:02 <@piscisaureus_> well, it could be that you were a teetotal. In which cae it would be even more fun :-p
16:02 < bnoordhuis> tjfontaine: that's piscisaureus_'s strategy for getting you to buy for the rest of the evening
16:02 < tjfontaine> haha
16:08 < MI6> nodejs-master: #123 UNSTABLE windows-ia32 (6/569) osx-ia32 (2/569) windows-x64 (7/569) http://jenkins.nodejs.org/job/nodejs-master/123/
16:08 <@piscisaureus_> Hey bnoordhuis
16:08 < bnoordhuis> piscisaureus_: ho piscisaureus_
16:08 <@piscisaureus_> Did you configure git to use a specific editor? Or just kept the default?
16:09 < tjfontaine> hmm +1 on the windows failures, lets see what those are
16:09 < bnoordhuis> it uses $EDITOR which is set to the One True Editor on my system
16:09 <@indutny> bnoordhuis: ed?
16:09 -!- mode/#libuv [+o piscisaureus_] by ChanServ
16:09 < bnoordhuis> indutny: i've actually had to use ed in the past
16:09 < tjfontaine> http://jenkins.nodejs.org//job/nodejs-master/123/DESTCPU=x64,label=windows//tapTestReport/test.tap-359/
16:10 <@piscisaureus_> bnoordhuis: what do you get if you do `git config --get core.editor` ?
16:10 < tjfontaine> which I'm guessing is from os.tmpdir
16:10 < bnoordhuis> on a solaris 9 system where vim wouldn't compile and the terminal was fubar'd
16:10 < bnoordhuis> piscisaureus_: vim
16:10 <@piscisaureus_> It's unfortunate that there is no `git run-editor` plumbing
16:10 < bnoordhuis> oh, apparently i actually configured that in $HOME/.gitconfig
16:10 < bnoordhuis> go me
16:10 <@piscisaureus_> scheisse
16:11 < tjfontaine> unconfigured is no output btw
16:11 <@piscisaureus_> ah
16:11 < bnoordhuis> piscisaureus_: GIT_EDITOR=vim
16:11 <@piscisaureus_> meh :(
16:26 < tjfontaine> assert.equal(os.tmpdir(), '/tmpdir');
16:26 < tjfontaine> before tweaking any env vars, is no longer valid on windows
16:26 < Guest93631> good morning
16:26 < Guest93631> ack
16:27 -!- mode/#libuv [+o isaacs] by ChanServ
16:27 <@isaacs> there, that's better.
16:27 < bnoordhuis> tjfontaine: ah, interesting
16:27 < tjfontaine> this is all kinds of borked, the only one that passes is L38
16:27 < bnoordhuis> piscisaureus_: ^
16:28 <@isaacs> tjfontaine, bnoordhuis: Is this the os.tmpdir change that just got sent our way?
16:28 < tjfontaine> yes
16:29 < MI6> nodejs-v0.10: #80 UNSTABLE osx-x64 (1/569) windows-x64 (4/569) smartos-ia32 (1/569) windows-ia32 (4/569) http://jenkins.nodejs.org/job/nodejs-v0.10/80/
16:30 < tjfontaine> the order is wrong in the clause, at least for the test to pass
16:30 < tjfontaine> https://github.com/joyent/node/commit/120e5a24df76deb5019abec9744ace94f0f3746a#L0R46
16:30 < tjfontaine> the test relies on TMPDIR, TMP, TEMP being the order
16:33 < tjfontaine> isaacs: btw don't forget to send me your notes
16:33 < bnoordhuis> isaacs: yes
16:33 < bnoordhuis> oh, tjfontaine already answered
16:34 < tjfontaine> I have a fix that as soon as the build finishes should satisfy the test and thus preserve hwo it used to work
16:34 < csaoh> hello ! i have a question that might be somewhat tricky, but still… does anyone know where the uv_timer_t callback are free when uv_timer_stop is called ?
16:34 < tjfontaine> linking on windows is stupidly slow, at least through vcbuild.bat since it can't assume incrementals
16:35 <@isaacs> yep
16:35 < bnoordhuis> csaoh: come again?
16:35 <@isaacs> tjfontaine: you on jabber?
16:36 < tjfontaine> I should be
16:36 <@isaacs> oh, my joyent login was being slow
16:36 < tjfontaine> I just cycled it
16:37 < csaoh> bnoordhuis: when uv_timer_start is called, there is a callback associated to that timer. is there any place it's deleted or set to null when the timer is stopped ?
16:37 < bnoordhuis> csaoh: you mean the function pointer to the callback? does it matter?
16:38 < csaoh> hm, actually, maybe not… sorry for the stupid question.
16:38 < bnoordhuis> indutny: you should probably merge the patch for #5004
16:38 <@indutny> zero return?
16:39 < bnoordhuis> yes
16:39 <@indutny> I've another idea about it
16:39 <@indutny> what if we'd just report this error?
16:39 <@indutny> as this.pair.ssl.error
16:39 < bnoordhuis> hm. why?
16:39 <@indutny> and all existing logic will be preserved
16:39 <@indutny> well, because it really looks like handling the same thing
16:39 <@indutny> and behaviour in case of zero return is the same too
16:40 < bnoordhuis> is a zero return something the user can reasonably be expected to avoid?
16:40 < bnoordhuis> i'm guessing the answer is no
16:41 <@indutny> surely no
16:41 <@indutny> but its error
16:41 <@indutny> you disagree?
16:42 < bnoordhuis> not really
16:42 < bnoordhuis> but if the user can't avoid it and the connection is dead anyway, there may not be much point in reporting it
16:42 < bnoordhuis> you're thinking of emitting it as a ECONNRESET kind of error or ?
16:43 <@indutny> yes, sort of
16:43 <@indutny> well
16:43 <@indutny> I mean
16:43 <@indutny> yes
16:43 <@indutny> I could do it
16:43 < bnoordhuis> i don't really have a strong opinion
16:44 < bnoordhuis> on this particular subject anyway
16:44 <@indutny> ok
16:45 <@indutny> I'll do ECONNRESET
16:45 < tjfontaine> bnoordhuis, piscisaureus_: https://gist.github.com/tjfontaine/5264773
16:48 < bnoordhuis> tjfontaine: piscisaureus_ should sign off on that
16:48 < bnoordhuis> and maybe run the test suite this time :)
16:48 < tjfontaine> yes, I did :)
16:48 < bnoordhuis> oh, i mean bertje
16:48 < tjfontaine> nod
16:48 < tjfontaine> yes I agree that those who sign off on patches should have run the test suite :P
16:48 <@piscisaureus_> you guys will have to wait a lot more then :)
16:49 <@piscisaureus_> tjfontaine: do you have a real commit for that, instead of a diff?
16:49 < tjfontaine> no I can make one if you'd like
16:49 <@piscisaureus_> tjfontaine: please.
16:49 <@piscisaureus_> You can still gist it but I prefer to run it through git am
16:51 <@piscisaureus_> tjfontaine: the problem of this is of course that now you're assuming windows is in c:\windows
16:51 <@piscisaureus_> oh wait no nvm
16:51  * piscisaureus_ facepalms
16:51 <@piscisaureus_> bnoordhuis: btw - I did run the tests...
16:52 < MI6> nodejs-v0.10: #81 UNSTABLE windows-x64 (5/569) smartos-ia32 (1/569) windows-ia32 (4/569) linux-ia32 (1/569) http://jenkins.nodejs.org/job/nodejs-v0.10/81/
16:53 < tjfontaine> piscisaureus_: https://github.com/tjfontaine/node/compare/osfix
16:53 < tjfontaine> wiat
16:53 < tjfontaine> wait
16:53 <@piscisaureus_> tjfontaine: why is the old order better?
16:54  * bnoordhuis is off to dinner
16:54 < tjfontaine> piscisaureus_: I'm not saying it's better, just that we had an order and were testing for it
16:55 <@piscisaureus_> tjfontaine: ah. The order windows specifies is: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992(v=vs.85).aspx
16:55 < tjfontaine> I force pushed so as not to break unix as well
16:55 < tjfontaine> piscisaureus_: then the proper thing to do would be to write a new test :)
16:56 <@piscisaureus_> Yeah that's probably better
16:57 < dostoyevsky> Is there an easy way to dump uv__timers ?
16:59 <@isaacs> piscisaureus_: what are your thoughts on this? https://gist.github.com/isaacs/5264897
17:00 <@indutny> https://gist.github.com/indutny/77c6145f86f272cf705a
17:00 <@indutny> review anyone?
17:00 <@piscisaureus_> tjfontaine: I will update the patch and the test.
17:00 < tjfontaine> piscisaureus_: ok
17:01 <@piscisaureus_> isaacs: reviewing now
17:01 <@isaacs> piscisaureus_: i just posted this example script to gist, and a bunch of people all immediately responded with how helpful it is.
17:01 <@isaacs> figured it should just go in the docs.
17:02 <@isaacs> rather than always telling people "you can do this" we should probably just tell htem HOW to do it
17:02 <@piscisaureus_> isaacs: so - I though the promise of domains that you could actually automatic cleanup?
17:02 <@indutny> bnoordhuis: review https://gist.github.com/indutny/77c6145f86f272cf705a
17:02 <@piscisaureus_> as long as you're not carrying global state, that is
17:02 <@isaacs> piscisaureus_: in practice, that does not work reliably, and in fact, i'd like to deprecate the whole "dispose()" concept entirely
17:02 <@piscisaureus_> isaacs: I mean, if it doesn't work reliably then we should definitely not pretend it's all great.
17:03 <@isaacs> piscisaureus_: ^ yes, gmta :)
17:03 <@isaacs> piscisaureus_: it's a lovely idea, like socialism.
17:03 <@indutny> brb
17:03 <@isaacs> but if you have a stateful side-effecty language, you can't pretend that you can reliably clean up from arbitrary GOTO jumps into lala land
17:03 <@piscisaureus_> isaacs: ok, so lgtm for now. But dropping dispose() makes me really sad.
17:04 <@piscisaureus_> isaacs: are there any issues about it not working?
17:04 <@piscisaureus_> https://github.com/joyent/node/issues/search?q=domain+dispose
17:08 <@isaacs> piscisaureus_: it's more like there's constant confusion about what it actually does, and whether or not it's required that you call it
17:08 <@isaacs> a lot of people seem to think that it's like a malloc/free kind of situation, and you'll leak resources if you don't dispose the domain
17:08 <@piscisaureus_> isaacs: aah. So we should just document that .dispose() clears up all the resources that are associated with the domain
17:08 <@isaacs> and there's been mailing list threads complaining about how it's impossible to know when you should dispose the domain
17:09 <@isaacs> it actually doesn't, though
17:09 <@isaacs> it just walks around with a rubber mallet trying to smash all the things it knows about, and causes it to stop doing MakeCallback or emitting errors
17:09 <@piscisaureus_> isaacs: It does, right? You just have to add streams etc. explicitly to the domain.
17:09 <@isaacs> well, so, it does 2 things.
17:09 <@piscisaureus_> isaacs: implicit addition seems much nicer if it wasn't so slow
17:10 <@isaacs> 1. Anything explicitly added gets .close() .end() .destroy() .destroySoon(), etc.
17:10 <@isaacs> which is kinda dumb.
17:10 <@isaacs> 2. the _disposed flag gets set, which means that anything in that domain will be noop'ed in MakeCallback and errors will be ignored.
17:10 <@isaacs> in the hopes that it'll kinda... go away.
17:11 <@isaacs> but you will quite easily leak resources.
17:11 <@isaacs> memory, objects, etc.
17:11 <@isaacs> and throwing in some cases, even if you're using domains, can cause quite oddball stuff to happen.
17:11 <@piscisaureus_> well ... you can't leak memory unless your domain created global state that it was supposed to clean up
17:11 <@isaacs> it doesn't have to be global, it only has to be shared.
17:11 <@piscisaureus_> the only thing you can really leak is FDs, sockets etc
17:12 <@piscisaureus_> yes, that
17:12 <@isaacs> in JS, there's no way for you to know who might have a reference to your thing
17:12 <@isaacs> so, let's say, you have a situation where you have some kind of "Agent" that's doing a bad job of pooling sockets.
17:12 <@piscisaureus_> oh. never heard of. :-p
17:12 <@isaacs> sound familiar?
17:12 <@piscisaureus_> what are you talking about  :)
17:12 <@isaacs> so, if you get 5 errors, now it's just hanging there doing nothig.
17:13 <@piscisaureus_> isaacs: yeah. this isn't great I agree
17:13 <@piscisaureus_> The only question left is: what's the purpose of domains at all then, except being an error sink.
17:13 <@piscisaureus_> isaacs: but, ok, lgtm then. Let's atleast not confuse our users.
17:13 <@isaacs> the purpose of domains is to be an error sink
17:14 <@isaacs> that's actually really useful.
17:14 <@isaacs> the problem was that we originally envisioned it as doing the work of process isolation, which is not actually feasible in a stateful, mutable, GC'ed language.
17:14 <@piscisaureus_> yes. So we need better isolation :)
17:14 <@piscisaureus_> yes - that
17:14 <@piscisaureus_> isaacs: ok, go for it
17:15 <@piscisaureus_> And now someone kicks my butt, I'm being thrown out of this building again.
17:15 <@isaacs> aah
17:15 <@isaacs> haha
17:16 <@isaacs> i think "better isolation" will not come with JavaScript.
17:16 <@isaacs> the answer there ought to be OS processes
17:16 <@isaacs> or, perhaps, cheap isolates, but the "cheap" is very important.
17:16 <@isaacs> piscisaureus_: in the short term, it's all about child_process, though
17:22 -!- mode/#libuv [+o TooTallNate] by ChanServ
17:22 < MI6> joyent/node: isaacs v0.10 * 5ae26f3 : doc: Add 'don't ignore errors' section to domain  Also, an example progra - http://git.io/jKVHMw
17:22 < dostoyevsky> uv_timer_start() uses loop->time + timeout
17:22 < dostoyevsky> is this is a bug?
17:23 < dostoyevsky> loop->time might be out of date 
17:23 < dostoyevsky> At least it's in my code
17:23 < tjfontaine> it should be reasonably close, unless you're taking too long in callbacks
17:24 < dostoyevsky> http://ideone.com/j23gRn
17:24 < dostoyevsky> Should I update loop->time somehow after my sleep before I do uv_timer_start?
17:24 < tjfontaine> ya putting a sleep there is a good way to ruin it
17:25 < dostoyevsky> in practice I am just idling in a shell...
17:25 < tjfontaine> trevnorris: we need to convince you to screen+irssi or somethign
17:25 < trevnorris> tjfontaine: why's t that?
17:25 < tjfontaine> dostoyevsky: sleep is one of those blocking things you should be avoiding in your mainloop
17:25 < tjfontaine> trevnorris: because it's the irc way
17:26 < dostoyevsky> tjfontaine: That may not be always possible...
17:26 < tjfontaine> dostoyevsky: things block should be in a uv_queue_work sequence
17:26 < dostoyevsky> I am just looking for a way to update loop->time
17:26 < tjfontaine> *things that block
17:26 < dostoyevsky> tjfontaine: I can't rewrite Ruby...
17:27 <@isaacs> Does anyone have opinions about https://github.com/joyent/node/pull/5148?
17:27 <@isaacs> TooTallNate: especially interested in what you think of that.
17:28 <@TooTallNate> isaacs: oh i'm very +1 for that
17:28 <@isaacs> TooTallNate: basically, it's the "do read(0) automatically when you do on('readable')"
17:28 <@isaacs> but covers more territory that was missed.
17:28 <@isaacs> ok, kewl
17:28 <@TooTallNate> isaacs: oh, i thought we already had that?
17:28 <@isaacs> well... we do, but, you an still miss it
17:28 < dostoyevsky> If I call uv_run(l, UV_RUN_NOWAIT); l->time seems to have been updated...
17:28 <@TooTallNate> ya, missing "readable" events is bad…
17:28 <@isaacs> if something else *already* caused it to get some data added, or if it was already ended, then read(0) won't necessary trigger a 'readable'
17:29 <@isaacs> we should try to guarantee that the first addition of a 'readable' handler will *always* get a readable event, even if it already passed.
17:29 <@isaacs> TooTallNate: another relevant change here is that the *second* addition of a 'readable' handler might still miss it.
17:29 <@isaacs> TooTallNate: basically, if it's *your* stream, you won't miss the data.  that's kind of the pattern that's been emerging.
17:29 <@isaacs> TooTallNate: if you're sharing, well... who knows.
17:29 < dostoyevsky> uv_update_time() seems to be what I want
17:29 <@TooTallNate> isaacs: right, ya that sounds good to me, otherwise is the same as "data"
17:29 <@isaacs> right
17:30 <@TooTallNate> wrt missing it :p
17:30 <@isaacs> yeah
17:30 <@isaacs> you can still miss it if someone else takes it, but i mean, be reasonable people, we can't magically go back in time without buffering everything always forever.
17:30 <@isaacs> k, landing it
17:31 < MI6> joyent/node: isaacs v0.10 * 929e4d9 : stream: Emit readable on ended streams via read(0)  cc: @mjijackson (+1 more commits) - http://git.io/Xb3Rfw
17:32 < tjfontaine> isaacs: btw did you see that the bot is now commenting on new pull requests?
17:34 <@isaacs> ORLY?
17:34 <@isaacs> no, i didn't catch that
17:35 < tjfontaine> https://github.com/joyent/node/pull/5159#issuecomment-15591012 for node
17:35 < tjfontaine> also on libuv https://github.com/joyent/libuv/pull/756#issuecomment-15592727
17:36 < tjfontaine> it checks for the lib/src test/benchmark that you wanted, and also the CLA
17:37 < tjfontaine> and it should only comment if the pullrequest doesn't validate, good pull requests don't get harassed
17:40 < MI6> nodejs-v0.10: #82 UNSTABLE windows-x64 (6/569) smartos-x64 (1/569) smartos-ia32 (1/569) windows-ia32 (4/569) http://jenkins.nodejs.org/job/nodejs-v0.10/82/
17:45 < MI6> joyent/node: wicked v0.10 * 39058be : setTimeout: do not calculate Timeout._when property  Dramatically improve - http://git.io/yC_7mA
17:46 < tjfontaine> wicked?
17:46 <@isaacs> alexy kuperstokh
17:46 <@isaacs> i guess he's wicked :)
17:46 < tjfontaine> heh I guess
17:47 <@indutny> haha
17:47 <@indutny> isaacs: https://github.com/wicked
17:48 <@isaacs> https://github.com/AlexeyKupershtokh/node/commit/63b38760c25f15b65421766fca635543382d1556
17:48 <@isaacs> i guess his git name config is "wicked"?  i don't know
17:48 < tjfontaine> ya, that's git indeed
17:50 -!- mode/#libuv [+o piscisaureus_] by ChanServ
17:50 <@piscisaureus_> back
17:50 <@isaacs> wb
17:52 <@indutny> any objections https://gist.github.com/indutny/77c6145f86f272cf705a
17:52 <@indutny> ?
17:52 <@indutny> will merge in 5 minutes, because ben generally agreed with me on this
17:53 <@isaacs> one sec, reviewing
17:53 <@isaacs> yes, +1 lgtm
17:53 <@indutny> ok
17:53 <@isaacs> DONT WAIT 5 MINUTES THAT IS 5 MINUTES YOU COULD HAVE BEEN NOT WAITING INSTEAD!
17:53 <@indutny> nks
17:54  * isaacs ...? no louds?
17:54 <@indutny> I never actually wait
17:54 <@indutny> :)
17:54 <@indutny> its called multi-tasking
17:54 <@indutny> btw, I've just realized
17:54 <@indutny> how processes and IPC are similar to general relativity theory
17:54 <@isaacs> indutny: can you add a error.sslErrorString = err or something?
17:55 <@isaacs> indutny: it'd be nice for debugging to know that it actually WAS a zero_return rather than an ECONNRESET
17:55 <@indutny> isaacs: I'll create exception
17:55 <@indutny> ah, ok
17:55 <@indutny> ok
17:55 <@isaacs> even if they get handled the same, semantically
17:55 <@indutny> it'll be it
17:55 <@indutny> well
17:55 <@indutny> you want it to be ECONNRESET, but zero_return?
17:55 <@isaacs> er, ZERO_RETURN, whatever.
17:55 <@isaacs> just something so that you can see the actual string that came out of openssl
17:56 <@isaacs> throwing away data sets off my danger sense.
17:56 <@indutny> ok
17:57 < MI6> nodejs-v0.10: #83 UNSTABLE osx-x64 (1/570) windows-x64 (5/570) smartos-ia32 (1/570) windows-ia32 (4/570) linux-ia32 (1/570) http://jenkins.nodejs.org/job/nodejs-v0.10/83/
17:57 <@isaacs> you never know.  just the other day, i tracked down a problem in my code using the new _handle.fd field.
17:58 <@isaacs> i thought it was kind of a weird nice-to-have feature.  now that i have it, i'ts goddamn essential.
17:58 <@indutny> heh
17:59 <@indutny> eird
17:59 <@indutny> weird*
17:59 <@indutny> AssertionError: 12345 == 8068
17:59 <@indutny>     at /Users/indutny/Code/indutny/node/test/simple/test-http-full-response.js:69:12
17:59 <@indutny> isaacs: have you ever seen this ^
17:59 <@indutny> I've got a lot of (node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
17:59 <@isaacs> hmmmm.....
17:59 <@isaacs> no
17:59 <@isaacs> what os?
18:00 <@indutny> isaacs: osx
18:00 <@indutny> isaacs: its happening from lib/http.js:30
18:00 <@indutny> err
18:00 <@indutny> s/30/530
18:00 <@indutny> aah
18:00 <@indutny> apache benchmark
18:01 <@indutny> ok, anyway... listener leak is not a good thing
18:01 <@isaacs> what?
18:01 <@indutny> https://gist.github.com/indutny/77c6145f86f272cf705a
18:01 <@indutny> ZERO_RETURN ^
18:02 <@indutny> isaacs: eventemitter leak is happening when apache benchmark is starting to behave incorrectly on osx
18:02 <@isaacs> oh, ok
18:02 <@isaacs>     // In v0.10 and later, this isn't a problem, since ECONNRESET isn't
18:02 <@isaacs>     // ignored in the first place.  We'll probably emit 'close' on the
18:02 <@isaacs>     // next tick, but just in case it's not coming, set a timeout that
18:02 <@isaacs>     // will emit it for us.
18:02 <@isaacs> indutny: ^??
18:02 <@indutny> idk
18:03 <@isaacs> indutny: it looks like i said that we can just ignore that whole bit of functionality in 0.10
18:03 <@isaacs> indutny: what happens if you yank out that ugly kludge?
18:03 <@indutny> well, it happens
18:03 <@isaacs> right, i mean, remove the .once(), that whole thing
18:03 <@isaacs> that whole path
18:03 <@indutny> I'm not sure that I'll be able to reproduce it
18:03 <@indutny> it wasn't happening like 10-20 times before
18:03 <@indutny> but let me try
18:04 < MI6> joyent/node: Fedor Indutny v0.10 * 4580be0 : tls: handle SSL_ERROR_ZERO_RETURN  see #5004 - http://git.io/Mb93AQ
18:04 <@isaacs> indutny: try this: https://gist.github.com/5265427
18:04 <@isaacs> indutny: does that make the problem go away?
18:05 <@indutny> one sec
18:05 < tjfontaine> TooTallNate: please don't make me get an xp vm :/
18:05 <@TooTallNate> tjfontaine: hahaha
18:05 < trevnorris> indutny: i'm seeing v8 gc hits a wall on external mem allocation, where it exponentially slows down execution.
18:05 <@indutny> can't make it run
18:05 <@TooTallNate> tjfontaine: i'd figure sblom or piscisaureus_ would take a look
18:05 <@TooTallNate> or isaacs maybe :p
18:06 < trevnorris> indutny: know of a way to tell v8, it's ok. just use a little extra memory.
18:06 <@TooTallNate> idk what that error code means though
18:06 < tjfontaine> http://stackoverflow.com/a/10535555 seems helpful
18:06 <@indutny> trevnorris: I don't understand what you are saying in last few days
18:06 <@indutny> I just can't :)
18:06 <@TooTallNate> ughh
18:06 <@TooTallNate> supporting XP is a PITA is seems
18:06 <@indutny> you're somewhere behind my understanding
18:06 <@piscisaureus_> TooTallNate: tjfontaine: ?
18:06 <@indutny> TooTallNate: why XP?
18:06 <@indutny> we should stick to Millenium
18:06 <@indutny> it was the only real WINDOWS
18:07 <@indutny> OH YEAH
18:07 <@TooTallNate> indutny: it reminds me of my childhood :)
18:07 < tjfontaine> piscisaureus_: he's having problems with 0.10.1 on xp
18:07 <@piscisaureus_> aah. ipv6?
18:07 <@TooTallNate> piscisaureus_: https://github.com/joyent/node/issues/5162
18:07 <@indutny> isaacs: I can't run test :(
18:07 <@indutny> isaacs: problem spawning ab - skipping test.
18:07 <@isaacs> indutny: oh, wild
18:07 <@isaacs> that's strange
18:07 <@indutny> so it was like the only time when it was running
18:08 <@indutny> and it gave us this thingy
18:08 <@piscisaureus_> tjfontaine: ah.
18:08 <@indutny> anyway
18:08 <@indutny> lets remove this code
18:08 <@indutny> ah, wait
18:08 <@isaacs> well, not just yet
18:08 <@indutny> no... lets think about it
18:08 <@isaacs> i wanna be careful about it :)
18:08 <@piscisaureus_> tjfontaine: can you try to deselect the 'Event Tracing (ETW)' feature before attempting install?
18:08 <@isaacs> yeah
18:08 < tjfontaine> piscisaureus_: TooTallNate ^
18:08 < trevnorris> indutny: that, or I've just exasperated your patience with all the questions. ;-)
18:09 <@indutny> trevnorris: who knows
18:09 <@indutny> I don't
18:09 <@piscisaureus_> Ah, *tootallnate
18:09 <@indutny> isaacs: it seems to be pretty harmless leak
18:09 <@indutny> since we're using `once` here
18:10 <@TooTallNate> piscisaureus_: new error https://dsz91cxz97a03.cloudfront.net/_eeoFfLMg3.png
18:10 <@TooTallNate> that's with ETW disabled
18:10 <@isaacs> indutny: yeah, probably just need a better guard.
18:10 <@isaacs> indutny: like, guard on teh socket, not on the request object.
18:11 <@piscisaureus_> TooTallNate: huh that's very weird.....
18:11 <@isaacs> indutny: also, need a test that reproduces the EE leak, which probably can happen by just connecting a whole bunch of times, and then killing the socket.
18:11 <@isaacs> indutny: like, conn = net.connect(...);  conn.write(lots of http requests);  conn.on('drain', conn.destroy)
18:11 <@indutny> isaacs:  I can reproduce it :)
18:11 <@isaacs> kk
18:12 <@isaacs> then we should fix it in 0.8, also
18:12 <@indutny> while true; do ./node test/simple/test-http-full-response.js; done
18:12 <@isaacs> indutny: i've been running that since we started talking about it
18:12 <@isaacs> actually, while ./node test/simple/test-http-full-response.js; do true; done; say "Failed"
18:12 <@isaacs> still running
18:12 <@indutny> well it happens on my machine
18:12 <@indutny> eventemitter leak
18:13 <@isaacs> yeah, i mean, we need to reproduce the ee leak deterministically
18:13 <@isaacs> not by running AB in a loop, on your machine, in russia, on a thursday.
18:13 <@isaacs> ;P
18:13 <@indutny> haha :)
18:13 <@indutny> right
18:13 <@indutny> but we need to know what causes it
18:13 <@isaacs> yes
18:13 <@indutny> for now it seems that all that writeRaw are happening from res.end() call
18:14 <@isaacs> i suspect that it's simply a matter of having a bunch of reqests, none of which are responded to yet, adn then killing the socket.
18:14 <@piscisaureus_> TooTallNate: is that box healthy otherwise?
18:14 <@indutny> `res.end(body)`
18:14 <@TooTallNate> piscisaureus_: healthy?
18:14 <@TooTallNate> oh
18:14 <@TooTallNate> ya it's pretty barebones
18:14 <@isaacs> indutny: which could happen if you pipelined a bunch of http reqs and then killed the socket as soon as they were written.
18:14 <@piscisaureus_> ok...
18:14 <@piscisaureus_> TooTallNate: you see, that registry key is something that windows installer adds, and not us.
18:14 <@isaacs> indutny: so then we get a hangup error, but not until nextTick, so there's the timeout thing, and the .once() to kill thetimeout.
18:15 <@TooTallNate> piscisaureus_: is it not an XP thing maybe?
18:15 <@isaacs> starting to sound like that childrens' song about the lady who swallowed a fly
18:15 <@isaacs> then she swallowed a spider to get the fly, and a bird to get the spider, and a cat to get the bird, etc..
18:15 <@indutny> oh god
18:15 <@indutny> that's a thriller
18:15 <@isaacs> yeah
18:15 <@piscisaureus_> TooTallNate: I will check, but I thought they hadn't broken xp compatibility get...
18:15 <@isaacs> goes up to a horse or somethign
18:15 < tjfontaine> isaacs: the song is a perfect analogy for NIH syndrome
18:15 <@TooTallNate> isaacs: i don't know why she swallowed a fly
18:15 <@TooTallNate> perhaps she'll die
18:15 <@isaacs> SUPER MORBID for a kid's song, too, right!?
18:15 <@TooTallNate> ya, hahahah
18:16 <@isaacs> basically i think it's a way to scare your kids into not eating bugs.
18:16 <@isaacs> anyway... running npm tests.  then i'm gonna put it in node, and package up 0.10.2
18:16 <@isaacs> should've done this a while ago, but got distracted by dumb things.
18:16 < tjfontaine> basically all traditional kids songs are morbid or come from very morbid things
18:16 <@TooTallNate> isaacs: can you update node-gyp in npm please?
18:16 <@isaacs> ("a while" = 2 days, i guess)
18:16 <@isaacs> TooTallNate: done, yes.
18:16 < MI6> nodejs-v0.10: #84 UNSTABLE osx-x64 (1/570) windows-x64 (4/570) smartos-ia32 (1/570) windows-ia32 (4/570) http://jenkins.nodejs.org/job/nodejs-v0.10/84/
18:17 <@isaacs> 0.9.3
18:17 <@TooTallNate> awesome
18:20 <@isaacs> the npm tests are such trash.  i sort of hate them a lot.
18:20 <@isaacs> sooooooo slow.
18:22 <@isaacs> omg, every time john roderick goes out in the daytime, it's the most awesome twitter day
18:24 <@indutny> who is he?
18:24 < bnoordhuis> saghul: self->fspoll_h.data = (void *)self;  <- is that still necessary?
18:24 < bnoordhuis> is it used in the weakref code?
18:24 < bnoordhuis> als, superfluous cast :)
18:24 < bnoordhuis> *also
18:25 <@indutny> heh
18:25 <@indutny> I think compiler should throw errors when we're doing superfluous casts
18:27 <@isaacs> indutny: a musician and internet person who very rarely leaves his house, apparently
18:27 <@indutny> good for him :)
18:27 <@indutny> I wouldn't leave my house either
18:27 <@indutny> its just need to eat
18:27 <@indutny> and some other cultural needs
18:27 <@indutny> and banks
18:29 < bnoordhuis> don't you have supermarkets that deliver at your doorstep?
18:31 -!- mode/#libuv [+o bnoordhuis] by ChanServ
18:33 < saghul> bnoordhuis it's needed for walk
18:33 < saghul> but i need to work on that code a bit more :-)
18:33 <@bnoordhuis> noted
18:34 -!- mode/#libuv [-o bnoordhuis] by bnoordhuis
18:34 < MI6> nodejs-v0.10: #85 UNSTABLE windows-x64 (5/570) smartos-ia32 (1/570) windows-ia32 (5/570) http://jenkins.nodejs.org/job/nodejs-v0.10/85/
18:35 <@indutny> bnoordhuis: I've
18:35 <@indutny> bnoordhuis: but they're too close for me
18:35 <@indutny> and delivery isn't free
18:40 < MI6> joyent/node: isaacs v0.10 * dea0634 : npm: Upgrade to v1.2.15 - http://git.io/dI3E6A
18:40 <@isaacs> TooTallNate: ^ gyp update.
18:40 <@TooTallNate> kewl :)
18:43 <@indutny> isaacs: could you wait for a few hours with 0.10.3
18:43 <@indutny> isaacs: I want to fix https://github.com/joyent/node/issues/5145 first
18:44 <@isaacs> 0.10.2
18:44 <@isaacs> and no
18:44 <@isaacs> i'll wait for next week for 0.10.3 :);
18:44 <@indutny> ok :)
18:44 <@isaacs> it'll be quick, though
18:44 <@isaacs> i want to get back on the mondya release schedule
18:44 <@isaacs> so it'll be good to have a nice juicy fix for it :)
18:45 <@indutny> yeah
18:45 <@indutny> well
18:45 <@indutny> I've no objections
18:47 < MI6> joyent/libuv: isaacs created tag node-v0.10.2 - http://git.io/1-0ASg
18:50 < MI6> joyent/node: isaacs created branch v0.10.2-release - http://git.io/s7NoCg
18:50 <@isaacs> review changelog? ^
18:50 <@isaacs> bnoordhuis: we should start doing libuv releases for node import, i think.  having slept on it, i think this is a good idea.
18:50 <@isaacs> bnoordhuis: at least, each node release should be a specific libuv tagged release.
18:51 <@isaacs> bnoordhuis: we can start with node 0.10.3, though.  no rush at the moment.
18:51 <@isaacs> bnoordhuis: how does that strike you?  seem reasonable?
18:51 <@piscisaureus_> isaacs: https://github.com/joyent/libuv/compare/v0.10.2...node-v0.10.2 <-- that's not really what we're supposed to be doing right?
18:51 <@isaacs> piscisaureus_: yeah, yeah...
18:51 <@isaacs> piscisaureus_: see my note there to bnoordhuis ^
18:52 <@isaacs> piscisaureus_: it's not important that node v0.10.2 === libuv v0.10.2
18:52 <@isaacs> in fact, we'll probably get out of sync pretty quick.
18:52 <@isaacs> i expect that libuv will advance faster if we say "every node import from libuv must be a tagged release"
18:52 <@piscisaureus_> isaacs: I totally agree
18:52 <@piscisaureus_> isaacs: the only thing is that in v0.10.2 libuv is not a tagged release
18:52 <@isaacs> but then we can have a changelog bullet like "uv: Upgrade to 0.10.32"
18:52 < bnoordhuis> isaacs: sure
18:53 <@isaacs> let's start this moving forward.
18:53 <@isaacs> the only thing that was kind of confusing the issue was that i was feeling like they should either be in sync, or way out, but not close.  but really, i mean, whatever.  no one cares.
18:53 <@piscisaureus_> isaacs: Let's not keep in sync.
18:54 <@piscisaureus_> isaacs: but... I can make a libuv release for you if you want?
18:54 <@isaacs> piscisaureus_: hrm.  ok, sure.
18:54 <@isaacs> can you land it in v0.10 right now?
18:55 <@isaacs> then i'll just rebase onto that and update the changelog.
18:55 <@piscisaureus_> isaacs: I have to do a release first, but it should take no more than 15 minutes.
18:55 <@isaacs> kk
18:55 <@isaacs> i'll eat some eggs :)
18:55 <@piscisaureus_> isaacs: if it takes longer we can punt on it. Making the process real quick was a goal
18:55 <@isaacs> yeah
18:57 < trevnorris> my allocator is having a strange issue where it executes quickly, until some seemingly random threshold. where it begins to operate really slow.
18:57 <@indutny> isaacs: oh, my name in changelog
18:57 <@indutny> finally
18:57 <@isaacs> indutny: ;P
18:57 <@indutny> my work is worth it
18:58 < trevnorris> for example, a for loop with N iterations, execute in "1183.92 ns/op", but N + 1 iterations executes in "172681.28 ns/op"
18:58 < MI6> nodejs-v0.10: #86 UNSTABLE windows-x64 (4/570) smartos-ia32 (1/570) windows-ia32 (4/570) linux-ia32 (1/570) http://jenkins.nodejs.org/job/nodejs-v0.10/86/
19:01 < bnoordhuis> trevnorris: profile it?
19:01 <@isaacs> this is weird... http://jenkins.nodejs.org//job/nodejs-v0.10/86/DESTCPU=ia32,label=smartos//tapTestReport/test.tap-319/
19:02 <@isaacs> bnoordhuis, trevnorris: I really think it's worth at least taking a serious look at libumem.  it's been around the block quite a bit.  even if we don't actually use it, it's probably worth understanding why they do the things they do.
19:02 < MI6> joyent/libuv: Bert Belder v0.10 * 31ebe23 : 2013.02.04, Version 0.10.3 (Stable)  Changes since version 0.10.2:  * inc - http://git.io/uySG1Q
19:02 < MI6> joyent/libuv: piscisaureus created tag v0.10.3 - http://git.io/Qsjs3w
19:02 < bnoordhuis> isaacs: sure, but show me the numbers first
19:03 <@isaacs> bnoordhuis: you mean, show you that it's faster than what we're doing?
19:03 < bnoordhuis> isaacs: well, yes
19:04 < MI6> joyent/libuv: Bert Belder v0.10 * 9e90cde : Now working on v0.10.4 - http://git.io/PyhjoQ
19:04 < MI6> libuv-v0.10: #23 UNSTABLE windows (6/187) linux (2/186) osx (1/186) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/23/
19:04 <@isaacs> i'll put it on my todo list.  but we should be able to justify why we're NIHing a slab allocator in the first place, i think, when there's already a portable one that's used by illumos and riak, and supported by the same people who are sponsoring node.
19:05 <@isaacs> we should get those numbers, and if using libumem is bad, we should make a big angry noise about it to joyent.
19:05 <@isaacs> and get them to fix it.
19:05 <@TooTallNate> piscisaureus_: so well it's possible that something on this box is screwy, haha
19:06 <@TooTallNate> cause now I can't install any of the node msi's
19:06 <@piscisaureus_> TooTallNate: haha. Maybe attemping to install ETW screwed it up...
19:06 <@piscisaureus_> TooTallNate: better reboot first :)
19:06 <@piscisaureus_> it's xp
19:06 <@TooTallNate> ok
19:06 <@isaacs> piscisaureus_: wanna land it in node v0.10, as well?
19:06 < bnoordhuis> isaacs: it's not that i think that libumem is bad
19:07 <@piscisaureus_> isaacs: Yeah, why not?
19:07 <@piscisaureus_> isaacs: Should I do it or you?
19:07 < MI6> libuv-v0.10: #24 UNSTABLE windows (7/187) linux (2/186) osx (1/186) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/24/
19:07 <@isaacs> piscisaureus_: i mean, do you wnat to do it, or should i?
19:07 <@piscisaureus_> isaacs: I don't care.
19:07 <@isaacs> piscisaureus_: be my guest :);
19:07 < bnoordhuis> it's that it's a general purpuse allocator while what we have is a tailor-made allocator
19:07 <@piscisaureus_> ok
19:07 <@TooTallNate> tailor-made
19:07 <@TooTallNate> that reminded me
19:07 <@TooTallNate> of a very bad tv show
19:08 < bnoordhuis> btw, the reason we have these slab buffers is to avoid creating too many persistent handles
19:09 < bnoordhuis> libumem isn't going to help with that
19:09 < MI6> joyent/node: Bert Belder v0.10 * 1b5ec03 : deps: upgrade libuv to v0.10.3 - http://git.io/PQ4sRw
19:09 < trevnorris> bnoordhuis: do you run perf as root to get past the kptr_restrict error?
19:09 <@piscisaureus_> isaacs: done
19:10 < bnoordhuis> it's a trade-off: the more persistent handles we create, the more precise memory management can be - but the slower it gets
19:10 <@isaacs> right
19:10 <@isaacs> piscisaureus_: thanks!
19:10 < bnoordhuis> trevnorris: no, you can turn it off with sysctl
19:10 <@isaacs> piscisaureus_: should process.versions.uv be reporting 0.10.3, or just 0.10?
19:10 <@isaacs> $ ./node -p process.versions.uv
19:10 <@isaacs> 0.10
19:11 <@piscisaureus_> isaacs: let's do that for v0.10.3 :)
19:11 < trevnorris> bnoordhuis: thanks. google failed me there.
19:11 <@isaacs> kk
19:11 <@piscisaureus_> isaacs: because it requires some changes to the way node picks up the libuv version.
19:11 <@isaacs> right
19:12 < MI6> joyent/node: isaacs v0.10.2-release * 1e0de9c : 2013.03.28, Version 0.10.2 (Stable)  * npm: Upgrade to 1.2.15  * uv: Upgr - http://git.io/65yFmA
19:15 < bnoordhuis> $ out/Release/node -p process.versions.uv
19:15 < bnoordhuis> 0.10.3
19:17 < MI6> joyent/node: bnoordhuis created branch process-versions-uv-review - http://git.io/Tcs7ow
19:17 < bnoordhuis> ^ isaacs, piscisaureus_
19:17 <@piscisaureus_> bnoordhuis: lgtm
19:17 <@piscisaureus_> bnoordhuis: the question is, is this okay for v0.10 ?
19:19 < bnoordhuis> you're afraid it's going to break addons that parse process.versions.uv in their package.json or something like that?
19:19 < trevnorris> bnoordhuis: thanks for the perf reminder. i kinda get tunnel vision when a problem's been bugging me for a while.
19:19 <@piscisaureus_> bnoordhuis: well, I don't really think people look at the version ever
19:20 <@piscisaureus_> bnoordhuis: which is why I wouldn't mind landing it. But in a way it's an api change.
19:20 < trevnorris> bnoordhuis: interesting results. will help. here're them for reference: https://gist.github.com/trevnorris/5265967
19:20 < bnoordhuis> ah well, if it breaks someone's code, s/he gets what s/he deserves for using a sloppy version number parser
19:21 < bnoordhuis> trevnorris: seems you're hitting a major GC run
19:23 <@isaacs> i think it's perfectly safe to update version numbers ina stable branch.
19:23 <@isaacs> we do that all the itme
19:24 <@isaacs> bnoordhuis: wait until after the release, though
19:24 <@isaacs> i mean, you can land now, but it won't go in the release.
19:24 < trevnorris> bnoordhuis: yeah. i'm trying to isolate if there's a something in my code that's triggering it.
19:24 <@isaacs> i already built some of the binaries, it's a pita to do it again :)
19:28 < MI6> nodejs-v0.10: #87 UNSTABLE linux-x64 (1/570) windows-x64 (4/570) smartos-ia32 (1/570) windows-ia32 (4/570) http://jenkins.nodejs.org/job/nodejs-v0.10/87/
19:36 < bnoordhuis> oh sure, i'll just land it in v0.10
19:37 < MI6> joyent/node: Ben Noordhuis v0.10 * 902d6cb : src: tie process.versions.uv to uv_version_string() - http://git.io/mcQejw
19:56 < MI6> nodejs-v0.10: #88 UNSTABLE windows-x64 (4/570) smartos-ia32 (1/570) windows-ia32 (5/570) linux-ia32 (1/570) http://jenkins.nodejs.org/job/nodejs-v0.10/88/
19:56 < trevnorris> bnoordhuis: yeah. so the gc is going nuts. --trace_gc tell me "11002 ms: Mark-sweep 2.0".
19:56 < trevnorris> ok. time to figure out why it's flipping out.
20:03 < trevnorris> bnoordhuis: what was that self referencing struct trick so i don't need to do an alloc for mem, and an alloc for the struct?
20:04 < MI6> joyent/node: isaacs created tag v0.10.2 - http://git.io/MuyK6g
20:06 < bnoordhuis> trevnorris: you mean container_of?
20:10 < MI6> joyent/node: isaacs v0.10 * 708e858 : blog: Post about v0.10.2 (+3 more commits) - http://git.io/4gRISQ
20:15 -!- mode/#libuv [+o piscisaureus_] by ChanServ
20:15 < MI6> joyent/node: isaacs master * 97c70a6 : Merge remote-tracking branch 'ry/v0.10'  Conflicts: 	src/node.cc 	src/nod (+21 more commits) - http://git.io/1H9tPQ
20:20 < trevnorris> bnoordhuis: nm.
20:22 < creationix> isn't there a diagram of the libuv / node event loop somewhere in the wiki?
20:22 < creationix> I can't seem to find it
20:23 < MI6> joyent/node: isaacs master * 9100dd4 : lint  Fixes lint errors introduced in 120e5a24df76deb5019abec9744ace94f0f - http://git.io/2FYp5g
20:30 < MI6> nodejs-v0.10: #89 UNSTABLE windows-x64 (4/570) smartos-x64 (3/570) smartos-ia32 (1/570) windows-ia32 (4/570) linux-ia32 (1/570) http://jenkins.nodejs.org/job/nodejs-v0.10/89/
20:31 < mmalecki> creationix: there was one in issues about process.nextTick
20:31 < mmalecki> creationix: not in the wiki tho, no
20:31 < creationix> that's explains why I can't find it, do you happen to know which issue?
20:31 < tjfontaine> it's probably setImmediate
20:31 < mmalecki> creationix: actually, I need it for my next talk so I'll go ahead and search
20:32 < tjfontaine> creationix: https://github.com/joyent/node/pull/3872#issuecomment-7804775
20:32 < tjfontaine> mmalecki: ^
20:32 < mmalecki> there we go :)
20:32 < creationix> and that diagram is correct right?
20:33 < mmalecki> creationix: it looks correct to me
20:33 < tjfontaine> it was at the time, I am only sketchy to know if any process.nextTick tweaked afterthat, trevnorris woudl be the best to say so
20:33 < creationix> now if only I could make sense of this diagram
20:33 < tjfontaine> I can't think of a reason why it would have changed
20:33 < creationix> the way I understand nextTick is it's run at the end of every js event source
20:34 < creationix> and keeps consuming nextTick callbacks till there are none left
20:34 < trevnorris> creationix: http://logs.nodejs.org/libuv/2013-03-27#22:17:52.557
20:35 < tjfontaine> also potentially helpful in context of https://github.com/joyent/libuv/blob/master/src/unix/core.c#L301-319
20:35 < creationix> trevnorris: would you have time to help  book publisher make sure a diagram they are working on is correct?
20:36 < creationix> I don't think I'm expert enough on the internal details
20:36 <@piscisaureus_> creationix: that diagram is not terribly up to date
20:36 < trevnorris> publisher?
20:36 <@piscisaureus_> and idle is at the wrong place
20:36 < creationix> for the manning book I started, but TJ ended up finishing
20:36 < trevnorris> piscisaureus_: idle is?
20:36 < tjfontaine> piscisaureus_: idle is in the right spot on unix
20:37 <@piscisaureus_> no idle should be run *after* check or closing but before timers
20:38 < trevnorris> eh? am I reading uv_run incorrectly in uv/src/unix/core.c?
20:38 <@piscisaureus_> unix/core may be incorrect :)
20:40 < trevnorris> piscisaureus_: still don't see it. in win/core.c: "uv_update_time(loop); uv_process_timers(loop); if() { uv_idle_invoke(loop); }"
20:41 <@isaacs> ok, 0.11.0 time
20:41 <@indutny> isaacs: finally
20:41 <@isaacs> :D
20:42 <@isaacs> oh, i should eat more first.  this is no good right now...
20:42 <@piscisaureus_> trevnorris: yes, you're right I think.
20:43 <@piscisaureus_> trevnorris: the fact that it's so close to the start of the event loop got me confused. In my mental model "idle" is always last.
20:44 <@piscisaureus_> But heh, it's a loop, you can start anywhere
20:44 < bnoordhuis> unix/core is the source of all that's truthful and just. you know that, bertje
20:44 <@piscisaureus_> bnoordhuis: no. libev is in this case :)
20:44 < MI6> nodejs-master: #124 UNSTABLE windows-ia32 (5/572) osx-ia32 (1/572) windows-x64 (6/572) smartos-ia32 (1/572) smartos-x64 (1/572) http://jenkins.nodejs.org/job/nodejs-master/124/
20:45 <@piscisaureus_> isaacs: v0.11.0 time -> like, can we start on new features now?
20:45 <@isaacs> piscisaureus_: well, i'm gonna do a v0.11.0 releae
20:45 <@isaacs> then we start on new features :)
20:45 <@piscisaureus_> Aah
20:46 <@isaacs> i don't wanna get a dozen things in and then do the first release, like we did for 0.9
20:46 <@isaacs> kinda sucks that way
20:46 <@piscisaureus_> isaacs: ah, right
20:47 < bnoordhuis> but but
20:47 <@indutny> isaacs: tlsnappy time? :)
20:48 <@indutny> muhahaha
20:53 < bnoordhuis> all hail inolen
20:54 < inolen> :) not so sure about that
20:57 < MI6> joyent/node: isaacs created branch v0.11.0-release - http://git.io/oOAcwg
20:57 <@isaacs> changelog comments? ^
20:57 <@isaacs> bnoordhuis, piscisaureus_: any major changes in libuv that you think ought to be highlighted?
20:58 <@piscisaureus_> isaacs: unix, windows: nanosecond resolution for uv_fs_[fl]stat ?
20:58 < trevnorris> v8 you are a whore that bleeds me dry.
20:58 <@piscisaureus_> isaacs: or did that not bubble up to node yet?
20:59 <@isaacs> piscisaureus_: it's in there :)
20:59 <@isaacs> piscisaureus_: in teh changelog i mean, for 0.11
20:59 < bnoordhuis> isaacs: maybe that ngx-queue.h is gone from uv.h now?
21:00 <@isaacs> bnoordhuis: meh.  internal.
21:00 <@isaacs> i don't think people really used that directly anyway
21:00 < bnoordhuis> maybe
21:01 <@isaacs> (should certainly go on uv's changelog, though :)
21:01 < bnoordhuis> it's still in that version of libuv btw
21:01 <@isaacs> ok
21:02 < MI6> nodejs-master: #125 UNSTABLE windows-ia32 (5/572) windows-x64 (6/572) smartos-x64 (2/572) http://jenkins.nodejs.org/job/nodejs-master/125/
21:02 < bnoordhuis> lgtm
21:06 <@isaacs> alright, binaries a-buildin
21:06 -!- mode/#libuv [+o sblom] by ChanServ
21:12 < trevnorris> wtf v8!?! "gc_count=8203 mark_sweep_count=8203 max_gc_pause=11080.7 total_gc_time=46096005.3"
21:13 < bnoordhuis> trevnorris: what are you doing?
21:15 < trevnorris> bnoordhuis: basically "for (var i = 0; i < N; i++) AllocSlow({}, 1024 * 32);"
21:15 < trevnorris> bnoordhuis: the code is https://github.com/trevnorris/node/blob/buffer-buffet/src/node_smalloc.cc
21:16 < trevnorris> it runs 2x's faster than SlowBuffer for sizes like 1024. but at large values of N it completely blows up.
21:19 < trevnorris> and it's at a very very specific value of N. Then at N + 1 it takes over 130x's longer.
21:19 < bnoordhuis> oh? what value of N?
21:20 < bnoordhuis> also, what build? ia32 or x64?
21:20 < tjfontaine> unaligned?
21:21 < trevnorris> ok, when the size allocated is "1024 * 32" then it dies at 64390 iterations.
21:21 < trevnorris> x64
21:21 < trevnorris> tjfontaine: sorry, what?
21:22 < tjfontaine> never mind
21:23 < trevnorris> one thing I have noticed is that v8 won't allow maxresident to exceed around 56MB
21:23 < trevnorris> because if I AdjustAmountOfExternalAllocatedMemory at a value lower than the actual size, then it runs fine.
21:29 < trevnorris> bnoordhuis: if I let the gc run long enough in that state the program crashes with "Command terminated by signal 11"
21:31 < bnoordhuis> ah, a segfault
21:32 < bnoordhuis> that suggests that either v8 is doing something wrong or you are :)
21:33 < trevnorris> heh. i'm trying to run through it using gdb.
21:33 < tjfontaine> https://github.com/joyent/node/pull/5163 if anyone is interested, I'm double checking I didn't break anything on smartos atm
21:34 < tjfontaine> incidentally, https://github.com/davepacheco/nhttpsnoop is indeed a pretty fun little utility
21:35 < trevnorris> bnoordhuis: um. gdb bt looks like this: https://gist.github.com/trevnorris/5266975
21:35 < trevnorris> and they just keep going. it's turtles all the way down.
21:35 < tjfontaine> you made a cycle!
21:36 < tjfontaine> or something
21:36 < bnoordhuis> looks like it
21:36 < trevnorris> wtf. this bt doesn't end. i'm almost at 100k
21:37 < trevnorris> is there a way to jump to the bottom?
21:38 < bnoordhuis> trevnorris: bt -10
21:38 < bnoordhuis> or however many bottom stack frames you want
21:38 < trevnorris> awesome. thanks
21:38 < tjfontaine> does gdb just use more/less or does it have its own pager?
21:39 < trevnorris> so it goes down to #96320. hm. now to figure out how I created a cycle...
21:40 < bnoordhuis> tjfontaine: i think it's built in
21:40 < tjfontaine> k
21:43 < MI6> joyent/node: isaacs v0.10 * f1fa756 : blog: Update linux binary tarball shasums  I just accidentally the binary - http://git.io/uFp8nA
21:49 < trevnorris> wtf...
21:50 < trevnorris> bnoordhuis: ok. so just fixed it. check the following two lines: http://git.io/Mb7ZRA
21:50 < trevnorris> i replaced "Object::New()" with the "obj" that was passed in.
21:50 < trevnorris> and some how that magically fixed the problem.
21:53 < bnoordhuis> odd
21:53 < trevnorris> sort of fixed it. now if the allocation is like ALLOC_SIZE - 1 then it will still die.
21:53 < MI6> joyent/node: isaacs created tag v0.11.0 - http://git.io/ntY5wQ
21:54 < MI6> joyent/node: isaacs master * caacc19 : Merge branch 'v0.11.0-release' (+1 more commits) - http://git.io/2gxivA
21:54 < MI6> joyent/node: isaacs master * 46da8c2 : Now working on 0.11.1 - http://git.io/_pLe-A
21:57 < MI6> joyent/node: isaacs v0.10 * 1d17ced : blog: v0.11.0 release - http://git.io/nagWdg
22:00 < MI6> nodejs-v0.10: #90 UNSTABLE windows-x64 (4/570) osx-ia32 (2/570) smartos-ia32 (1/570) windows-ia32 (4/570) http://jenkins.nodejs.org/job/nodejs-v0.10/90/
22:07 < bnoordhuis> indutny: ping (though i bet you're asleep)
22:14 < bnoordhuis> isaacs: weren't you going to remove NODE_MODULE_CONTEXTS?
22:14 <@isaacs> bnoordhuis: oh, meh.  proably not
22:15 <@isaacs> bnoordhuis: there's no compelling reason to.  it's not hurting anyone.
22:15 <@isaacs> we can deprecate it, i guess.
22:15 < bnoordhuis> seems kind of pointless
22:15 < bnoordhuis> it's the only place we use global.root
22:15 < bnoordhuis> which is another pointless thing
22:15 < bnoordhuis> as is GLOBAL
22:16 < bnoordhuis> i forgot they existed but they're still there
22:16 < tjfontaine> ok #5163 doesn't seem to break smartos
22:16 < trevnorris> bnoordhuis: just backported those changes to v0.10 branch and still blows up.
22:16 < trevnorris> so i'll say it's something w/ my code (though I don't know what)
22:33 < MI6> nodejs-v0.10: #91 UNSTABLE windows-x64 (5/570) osx-ia32 (1/570) smartos-ia32 (1/570) windows-ia32 (5/570) http://jenkins.nodejs.org/job/nodejs-v0.10/91/
22:42 < trevnorris> bnoordhuis: hm. very perplexing. in comparing SlowBuffer to AllocSlow, the later is 2x's faster. but the pooling allocator is all over the place.
22:45 < trevnorris> bnoordhuis: oh shit. I see what it is.
22:46 < trevnorris> I was using GetIndexedPropertiesExternalArrayDataLength to get the length, when I wasn't setting SetIndexedPropertiesToExternalArrayData to the Object::New()
22:46 < trevnorris> so v8 only saw the memory grow indefinitely.
22:48 < trevnorris> bnoordhuis: lol. yup. that fixed it.
22:48 < trevnorris> only took me 4 hours to see that dumb ass mistake.
22:49 < MI6> nodejs-v0.10: #92 UNSTABLE windows-x64 (4/570) smartos-ia32 (1/570) windows-ia32 (6/570) http://jenkins.nodejs.org/job/nodejs-v0.10/92/
22:59 < bnoordhuis> trevnorris: hah :) well, glad you found it
23:00 < trevnorris> bnoordhuis: you still have moments like that, or have you transcended missing the small things?
23:04 < bnoordhuis> trevnorris: doesn't happen often anymore, usually only when i'm tired
23:05 < trevnorris> awesome. there's hope for me yet. =)
23:16 < bnoordhuis> hrm. seems --expose-debug-as is broken in master
23:16 < bnoordhuis> or rather, it works but Debug.setBreakPoint() fails to actually set a breakpoint
23:16 < bnoordhuis> same in v0.10. but v0.8 works :-/
23:50 < MI6> nodejs-master: #126 ABORTED linux-x64 (1/572) windows-ia32 (8/572) windows-x64 (5/572) smartos-ia32 (1/572) smartos-x64 (3/572) http://jenkins.nodejs.org/job/nodejs-master/126/
23:50 < tjfontaine> hmm windows ia32 was hanging
--- Log closed Fri Mar 29 00:00:41 2013