--- Log opened Mon Jun 17 00:00:40 2013
00:56 <@isaacs> good afternoon, heroes
00:56 <@tjfontaine> good day good sir
00:57 <@tjfontaine> I followed up on your excellent response in isaacs/github#6
01:27 <@tjfontaine> isaacs: uh, define "shippable" because it was pushed this morning
01:41 <@isaacs> tjfontaine: hahah
01:42 <@isaacs> tjfontaine: well... we can't ship 0.12
01:42 <@tjfontaine> nod
01:42 <@isaacs> linkedin is the greatest.  i put in my profile that i've been a core contributer to Node.js for 28 years, so it told me I might know http://www.linkedin.com/in/ryankdahl
01:43 <@tjfontaine> hah
01:45 <@isaacs> tjfontaine: good response :)
01:45 <@isaacs> tjfontaine: ++
01:46 <@tjfontaine> heh, ya
01:46 <@tjfontaine> let there be no excuse
01:47 <@tjfontaine> isaacs: thoughts on doing something like github.com/tjfontaine/node-nf for `node -pe`?
01:48 <@isaacs> tjfontaine: i htink this sort of screams "userland"
01:49 <@isaacs> tjfontaine: but, i think nf should have the same argument syntax as node
01:49 <@tjfontaine> ok, I will keep this then, I don't really want to get too involved with it of course, because pretty soon it's just an awk replacement or people should be writing a script on their own
01:50 <@isaacs> tjfontaine: ie, nf -e '__line.replace(/foo/,  "baz")'  or nf apache.js
01:51 <@isaacs> tjfontaine: just personal preference, though
01:51 <@tjfontaine> as in always assume -p to tbe the case?
01:51 <@isaacs> tjfontaine: yeah
01:51 <@isaacs> why would you use nf if not for -p?
01:52 <@tjfontaine> you wouldn't, it was just to match the node arguments
01:52 <@tjfontaine> or perl really
01:52 <@tjfontaine> but ya if this wouldn't be in core then defaults should be reevaluated
01:57 <@MI6> joyent/node: isaacs master * 0a4260c : doc: Correct TLS deprecation notices - http://git.io/Xr5IOA
01:58 <@isaacs> tjfontaine: care to review? https://github.com/isaacs/node/commit/69662121e0821fe16f109ce77eb1150f6ced69d5
01:59 <@tjfontaine> loking
01:59 <@tjfontaine> +o
02:02 <@tjfontaine> isaacs: lgtm
02:06 <@isaacs> kewl
02:07 <@MI6> joyent/node: isaacs v0.10 * 3c7945b : net: Do not destroy socket mid-write - http://git.io/wzByxA
02:07 <@MI6> nodejs-master-windows: #65 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/65/
02:08 <@MI6> nodejs-master: #257 UNSTABLE linux-ia32 (1/600) smartos-ia32 (1/600) smartos-x64 (5/600) linux-x64 (1/600) http://jenkins.nodejs.org/job/nodejs-master/257/
02:13 <@isaacs> Looks like the tls hello parser test is failing on sunos x86 and x64 pretty regularly
02:13 <@isaacs> tjfontaine: have you seen that?
02:14 <@isaacs> the debugger stuff is failing on x64, also
02:14 <@isaacs> and the tap output is super mysterious
02:14 <@isaacs> just: not ok 536 - test-tls-hello-parser-failure.js
02:14 <@tjfontaine> yes, parser test is regularly failing, and that means timeout
02:14 <@tjfontaine> the debugger tests are the line flushing issue with repl
02:15 <@isaacs> kk
02:17 <@tjfontaine> the tls stuff utterly borked the build on windows, that will be the first thing on monday unless someone gets to it before me
02:18 < mmalecki> do you really hate yourself enough to start Monday with fixing a windows bug?
02:18 <@tjfontaine> mmalecki: that's rhetorical right?
02:19 < mmalecki> tjfontaine: it indeed is :)
02:19 <@tjfontaine> I looked at some of the numbers, there are a decent amount of people downloading our .msi's regularly :/
02:19 < udp> most effective way to diagnose windows bugs - wine + valgrind
02:19 <@tjfontaine> and what appears to be an increasing trend, though we'll know more going forward
02:19 <@MI6> nodejs-v0.10: #250 UNSTABLE osx-x64 (1/592) smartos-x64 (2/592) smartos-ia32 (1/592) linux-x64 (2/592) http://jenkins.nodejs.org/job/nodejs-v0.10/250/
02:20 <@tjfontaine> udp: please tell me you haven't worked under such circumstances?
02:20 < udp> yep I have - you get debugging symbols for winapi plus all the benefits of valgrind
02:21 < udp> I mean it does sound horrible
02:21 < mmalecki> it's either genius or crazy
02:21 <@tjfontaine> it must have been particularly painful situation that vs.net couldn't solve
02:22 < udp> well valgrind does a lot of stuff that VS does not
02:22 <@tjfontaine> does wine map the allocators to libc mallocs?
02:23 < mmalecki> hmm, if uv_connect fails, do I need to uv_close the handle?
02:23 < udp> afaik wine doesn't have its own pool for allocations
02:26 -!- mode/#libuv [+o MI6] by ChanServ
02:26 <@MI6> nodejs-v0.10-windows: #78 UNSTABLE windows-ia32 (9/592) windows-x64 (9/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/78/
02:26 <@tjfontaine> bad bad freenode
02:27 <@tjfontaine> mmalecki: fwiw that piklu character has been trolling pretty regularly this weekend :)
02:28 < mmalecki> oh :) ? I've been doing actual work this weekend, didn't notice
02:28 <@tjfontaine> he claims to have knowledge of an unreleased nginx 0day, but meh
02:30 < mmalecki> leveldb hosting? this makes 0 to very little sense
02:30 < mmalecki> well, whatever
02:30 < mmalecki> hosting DBs is a crazy business anyway.
02:33 < mmalecki> yeah, looks like I need to uv_close the handle, even if uv_connect failed. makes sense I guess. moar crazy callbacks.
02:33  * mmalecki wants C with closures
02:33 <@tjfontaine>  heh
02:34 <@tjfontaine> mmalecki: http://porkrind.org/missives/closures-in-straight-c/ :P
02:35 < mmalecki> tjfontaine: yeah, that's what I'm doing now :-). passing callbacks in those "cookies"
02:35 <@tjfontaine> heh
05:59 -!- mode/#libuv [+o TooTallNate] by ChanServ
06:31 -!- mode/#libuv [+o TooTallNate] by ChanServ
08:23 <@indutny> heya
11:01 <@indutny> bnoordhuis: hey ben
11:04 < bnoordhuis> indutny: ho fedor
11:05 <@indutny> how are you doing?
11:06 < bnoordhuis> i'm okay. you?
11:07 <@indutny> good too
11:07 <@indutny> just finished The night of the rabbit
11:07 <@indutny> pretty nice game
11:08 < bnoordhuis> google tells me it's a point & click adventure?
11:09 <@indutny> yes
11:09 <@indutny> indeed
11:09 < bnoordhuis> with mice, it seems
11:09 <@indutny> a beautiful one
11:09 <@indutny> bnoordhuis: not necessary, you can probably emulate it with your keyboard
11:09 <@indutny> you're engineer anyway
11:09 < bnoordhuis> was that a joke?
11:10 < bnoordhuis> if yes: well played, sir
11:10 <@indutny> you now I'm no kid
11:10 <@indutny> heh
11:10 <@indutny> whatever
11:11 <@indutny> looking forward for your tls session API reviewal
11:11 < bnoordhuis> i was just looking at it
11:11 <@indutny> it seems to be working, but we seem to care about security too
11:12 < bnoordhuis> meh, i practice klingon security
11:12 <@indutny> kill everyone?
11:12 < bnoordhuis> indeed. anyone who dares breach it, i eviscerate with my bat'leth
11:13 < bnoordhuis> it's a low-tech solution. i like low-tech solutions
11:13 < bnoordhuis> they still work when civilization falls
11:14 <@indutny> :)
11:14 <@indutny> are you still playing civilization?
11:15 < bnoordhuis> no, haven't played that in ages
11:15 < bnoordhuis> btw, ../../src/tls_wrap.cc:717:29: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
11:19 <@indutny> sure
11:19 <@indutny> fixed
11:19 <@indutny> anything else?
11:23 < bnoordhuis> i thought you were going to remove the ClientHello parser?
11:24 <@indutny> yes
11:24 <@indutny> ah
11:24 <@indutny> I see your point
11:24 <@indutny> you mean legacy code?
11:24 < bnoordhuis> well, you mentioned removing it last week
11:25 <@indutny> yeah, but isaacs said that we can't do it
11:25 <@indutny> compatibility
11:25 < bnoordhuis> why not? the parser is an implementation detail
11:25 <@indutny> also     Stability: 3 - Stable
11:25 <@indutny> bnoordhuis: its APIs are not
11:25 < bnoordhuis> do we expose that? where and why?
11:28 <@indutny> for asynchronous session sharing between processes
11:28 <@indutny> see doc update in my patch
11:28 <@indutny> here I am reverting doc removal that was done in tls-wrap patch
11:30 < bnoordhuis> hrm, but that's possible with vanilla openssl too, right?
11:31 <@indutny> no
11:31 <@indutny> not asynchronously
11:31 <@indutny> see, I can't load it from some external storage
11:31 <@indutny> the whole thing is
11:31 <@indutny> that its mostly useless
11:31 <@indutny> since the most of the browsers are using tls session tickets anyway
11:32 <@indutny> that's why I thought about removing it
11:33 < bnoordhuis> ah, okay
11:34 <@indutny> also, I'll probably make this optional now
11:35 <@indutny> I don't like that it goes to js-land at every request, even if there're no handlers for this events
11:35 <@indutny> meh
11:35 <@indutny> its too complicated
11:36 < bnoordhuis> is onclienthello ever appropriate for non-servers?
11:37 <@indutny> well, that's handled
11:37 <@indutny> see _tls_wrap.js code
11:37 <@indutny> its set only for servers
11:37 < bnoordhuis> okay
11:38 < bnoordhuis> i ask because onclienthello() checks that this.server !== false
11:38 < bnoordhuis> i mean, the logic is okay
11:39 < bnoordhuis> but i was wondering if it's possible to short-circuit even more
11:42 <@indutny> bnoordhuis: probably yes
11:42 <@indutny> but if I'd start doing this
11:42 <@indutny> I'll look at SNI first
11:43 <@indutny> its really borked atm
11:43 <@indutny> it should not require going into js-land
11:43 <@indutny> at least in the most of the times
11:43 <@indutny> also, if we're going to keep clienthello parser - it needs to be aware of SNI too
11:43 <@indutny> and allow us asynchronous certificate loading
11:52 < bnoordhuis> indutny: reviewed. pretty much LGTM
11:52 <@indutny> ok
11:52 <@indutny> please wait for a bit
11:52 <@indutny> thank you
11:52 <@indutny> I'm adding some laziness to it
11:52 <@indutny> I don't like that its calling js-land unconditionally
11:56 <@indutny> ok, running tests
11:58 <@indutny> bnoordhuis: basically, I did following thing
11:58 <@indutny> I've added a note for those event listeners: newSesssion, resumeSession
11:58 <@indutny> "they'll take effect only for connections established after adding those listeners"
11:59 <@indutny> and thus I can just check them at TLSSocket initialization
12:00 <@indutny> bnoordhuis: what do you think?
12:03 <@indutny> bnoordhuis: btw, force pushed https://github.com/joyent/node/pull/5709/files
12:06 -!- mode/#libuv [+o piscisaureus_] by ChanServ
12:06 <@piscisaureus_> bnoordhuis: lgtm
12:07 <@piscisaureus_> shit indutny beat me
12:07 <@indutny> haha :)
12:07 <@indutny> sorry
12:15 < bnoordhuis> indutny: biab, i'm off to the supermarket
12:22 <@indutny> ok
13:26 <@MI6> joyent/node: Ben Noordhuis v0.10 * 41fc46e : v8: add setVariableValue debugger command - http://git.io/ovZSiA
13:31 <@indutny> bnoordhuis: and you're back
13:32 < txdv> http://pastebin.com/mVPxrtHq
13:32 < txdv> can I open this type of socket with libuv?
13:33 < bnoordhuis> indutny: i am
13:33 <@indutny> bnoordhuis: so what do you think about my _small_ changes
13:34 < bnoordhuis> txdv: uv_pipe_open() or uv_poll_*()?
13:34 < bnoordhuis> indutny: i'll take a look
13:34 < txdv> I want to open the name
13:34 < txdv> lxc-monitor
13:34 < txdv> not the fd
13:36 < bnoordhuis> txdv: oh, like that. it's not officially supported but opening the socket yourself and passing it to uv_udp_open() will probably work
13:38 <@MI6> nodejs-v0.10: #251 UNSTABLE smartos-x64 (2/592) smartos-ia32 (1/592) osx-ia32 (2/592) http://jenkins.nodejs.org/job/nodejs-v0.10/251/
13:40 < bnoordhuis> indutny: lgtm
13:44 <@MI6> nodejs-v0.10-windows: #79 UNSTABLE windows-ia32 (7/592) windows-x64 (8/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/79/
13:50 <@MI6> joyent/node: Fedor Indutny master * 212e9cd : tls: session API returns - http://git.io/wW37_g
13:50 <@indutny> yikes!
13:50 <@indutny> bnoordhuis: thank you
13:51 < bnoordhuis> np
13:56 <@MI6> joyent/node: yuanchuan v0.10 * 73b4113 : readline: make `ctrl + L` clear the screen - http://git.io/y8tOQw
13:56 < bnoordhuis> tjfontaine: re: v8 mmap patch, status?
13:58 <@MI6> joyent/node: Yuan Chuan v0.10 * 18574bf : readline: make `ctrl + L` clear the screen - http://git.io/8vyfmA
14:02 <@MI6> nodejs-master-windows: #66 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/66/
14:03 <@MI6> nodejs-master: #258 UNSTABLE osx-x64 (1/601) osx-ia32 (1/601) linux-ia32 (1/601) smartos-ia32 (1/601) smartos-x64 (7/601) http://jenkins.nodejs.org/job/nodejs-master/258/
14:15 <@MI6> nodejs-v0.10: #252 UNSTABLE smartos-x64 (2/592) smartos-ia32 (1/592) http://jenkins.nodejs.org/job/nodejs-v0.10/252/
14:17 <@isaacs> indutny: so, what's the plan for TLS sessions?
14:17 <@indutny> hoya
14:17 <@indutny> already did it
14:17 <@isaacs> oh, ok
14:17 <@indutny> the plan is to remove legacy code
14:17 <@isaacs> same api?
14:17 <@indutny> yep
14:17 <@indutny> with one small restriction
14:17 <@isaacs> what's that?
14:17 <@indutny> (because of performance reasons)
14:18 <@indutny> adding listeners for `newSession`, `resumeSession` will have effect only on connections established after adding those listeners
14:18 <@indutny> so… like if you'll add `newSession` listener right after client connected - it won't be called
14:19 <@indutny> note that this listener is added to server object.
14:19 <@indutny> that's really good thing for performance, considering that there're no such listeners in 99% of time
14:19 <@indutny> isaacs: should be ok for all existing use cases
14:20 <@indutny> adding them from request listener or anywhere else doesn't make any sense
14:20 <@indutny> and… if anyone will complain - I'll figure out how to make it work for them
14:20 <@indutny> but I bet noone will ever notice it
14:21 <@MI6> joyent/node: Krzysztof Chrapka master * ffcd8b9 : readline: strip ctrl chars for prompt width calc - http://git.io/8gCQBw
14:21 <@MI6> nodejs-v0.10-windows: #80 UNSTABLE windows-ia32 (7/592) windows-x64 (8/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/80/
14:28 <@isaacs> indutny: that's probably fine, then
14:28 <@isaacs> thanks
14:28 <@indutny> you're welcome
14:28 <@indutny> I'll continue improving this shit
14:29 <@indutny> its finally a good time to sort out all the crap that was left here
14:33 <@MI6> nodejs-v0.10: #253 UNSTABLE smartos-x64 (5/592) smartos-ia32 (4/592) osx-ia32 (2/592) http://jenkins.nodejs.org/job/nodejs-v0.10/253/
14:35 <@MI6> nodejs-master: #259 UNSTABLE osx-ia32 (1/601) smartos-ia32 (3/601) smartos-x64 (6/601) http://jenkins.nodejs.org/job/nodejs-master/259/
14:35 <@isaacs> awesome :)
14:36 <@MI6> nodejs-master-windows: #67 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/67/
14:44 <@MI6> nodejs-v0.10-windows: #81 UNSTABLE windows-ia32 (8/592) windows-x64 (9/592) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/81/
15:07 <@MI6> joyent/libuv: Linus Mårtensson master * ff3ee84 : build: set OS=="android" for android builds - http://git.io/3k69Aw
15:12 <@MI6> libuv-master: #122 UNSTABLE windows (3/190) smartos (2/189) linux (1/189) http://jenkins.nodejs.org/job/libuv-master/122/
15:13 <@MI6> libuv-master-gyp: #59 UNSTABLE windows-x64 (3/190) smartos-ia32 (2/189) windows-ia32 (3/190) smartos-x64 (2/189) http://jenkins.nodejs.org/job/libuv-master-gyp/59/
15:24 <@MI6> joyent/node: Linus Mårtensson master * 5e4e8ec : build: add android support - http://git.io/I-2VmQ
15:32 <@MI6> libuv-node-integration: #112 UNSTABLE smartos-x64 (8/601) linux-x64 (36/601) smartos-ia32 (8/601) linux-ia32 (34/601) http://jenkins.nodejs.org/job/libuv-node-integration/112/
15:35 <@MI6> nodejs-master-windows: #68 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/68/
15:38 <@MI6> nodejs-master: #260 UNSTABLE osx-ia32 (2/601) linux-ia32 (1/601) smartos-ia32 (1/601) smartos-x64 (18/601) http://jenkins.nodejs.org/job/nodejs-master/260/
15:52 <@tjfontaine> sigh no one has fixed windows yet
15:59 <@isaacs> tjfontaine: what's broken about windows?
15:59 <@tjfontaine> the build
15:59 <@tjfontaine> post tls_wrap landing
16:05 -!- mode/#libuv [+o TooTallNate] by ChanServ
16:11 <@isaacs> ahh
16:11 <@tjfontaine> I guess I should actually re-enable windows in the pull request builder since windows in the CI mostly behaves now
16:13 <@isaacs> so, it kinda sucks that 0.10.11 has this GH-5688 bug
16:13 <@isaacs> wish we'd found that earlier
16:13 <@isaacs> one of those head-slappers.  i really ought to have seen it earlier.
16:13 <@tjfontaine> the writable truncation?
16:14 <@tjfontaine> ya
16:14 <@isaacs> as soon as i saw the issue, i thought "oh, fuck, right..."
16:14 <@isaacs> yeah
16:14 <@isaacs> so, i'm tempted to just do a 0.10.12 today
16:14 <@isaacs> hot on the heels
16:14 <@tjfontaine> nod
16:26 -!- mode/#libuv [+o piscisaureus_] by ChanServ
16:36 <@TooTallNate> trevnorris: cbuffer looks sweet dude
16:44  * isaacs yoga practice
16:44  * isaacs &
16:44 < LOUDBOT> THAT JUST MEANS YOU SUFFER FROM TOURETTES
16:54 < trevnorris> morning
17:00 -!- mode/#libuv [+o TooTallNate] by ChanServ
17:05 < trevnorris> TooTallNate: thanks. it's in need of some cleanup though.
17:15 < trevnorris> github is on crack. it placed several of ben's comments in the middle of sections they don't belong.
17:15 <@tjfontaine> heh
17:27 <@indutny> hoho
17:27 <@indutny> evening
17:28 <@tjfontaine> I'm re-rebuilding to verify, but indutny any problem with this? https://github.com/tjfontaine/node/compare/windows-build-fix
17:32 < trevnorris> bnoordhuis: is there any internal difference between ->ToObject and .As<Object>()?
17:34 <@indutny> no problems if it works
17:34 <@indutny> trevnorris: there should be
17:34 <@indutny> .As<Object>() is just a cast
17:34 <@indutny> and ToObject() is a runtime call
17:34 <@indutny> with checks and everything
17:34 < trevnorris> ah, ok.
17:35 < trevnorris> ths
17:35 < trevnorris> s/ths/thx
17:41 <@indutny> np
17:41 <@indutny> you're welcome
17:41 <@indutny> you can always find appropriate code in deps/v8/src/api.cc
17:42 <@indutny> and sometimes in deps/v8/include/v8.h
17:42 <@tjfontaine> indutny: ok I shall push then
17:43 <@indutny> yep
17:44 < trevnorris> indutny: ah ok. so api.cc is the implementation file for the public facing api?
17:44 <@indutny> yes
17:44 < trevnorris> cool. thanks again :)
17:44 <@indutny> you're welcome
17:45 <@MI6> joyent/node: Timothy J Fontaine master * c0281f1 : build: fix include order for building on windows - http://git.io/phru_w
17:52 < trevnorris> bnoordhuis: almost done. just curious about "return static_cast<size_t>(-1)". that's a legitimate way to check?
17:53 <@indutny> what's that?
17:53 <@indutny> MAX_UINT?
17:54 < trevnorris> indutny: http://git.io/mgwG_g
17:54 < trevnorris> basically I was throwing from a function called by other functions.
17:55 < trevnorris> guess i'm just used to that from js
17:56 < trevnorris> i was trying to get around needing to check the return value
17:58 <@indutny> aaah
17:58 <@indutny> I see what ben meant
17:58 <@indutny> returning odd-ball
17:59 <@indutny> though, I don't like this methods
17:59 < trevnorris> how's that?
18:01 <@indutny> call me old-school
18:01 <@indutny> but I better return status
18:01 <@indutny> and change argument
18:02 <@indutny> like `void my_method(int* result) { *result = 1; }
18:02 < trevnorris> oy. as you can see getting around checking the value is half the code. needing to check the return value was what I was trying to get around. oh well.
18:03 -!- mode/#libuv [+o TooTallNate] by ChanServ
18:05 < bnoordhuis> trevnorris: that was just a suggestion
18:05 <@indutny> bnoordhuis: meh
18:05 < bnoordhuis> in-band errors are something to frown on, really
18:05 <@indutny> static_cast<size_t>(E * 1024)
18:05 <@indutny> and check it
18:05 <@indutny> no way someone can return such odd value
18:06 < bnoordhuis> ^ don't listen to this guy
18:06 <@indutny> ^
18:07 < trevnorris> lol
18:07 < bnoordhuis> sorry, was in a conference call. back now
18:07 < trevnorris> well, i'm not about to argue w/ you two about my cc.
18:08 < bnoordhuis> trevnorris: something like indutny proposes could work: bool foo(type* out)
18:08 < bnoordhuis> e.g. bool ParseArrayIndex(size_t* index)
18:09 < trevnorris> ah yeah. in v8/src/d8-posix.cc they do something similar.
18:09 <@MI6> nodejs-master: #261 UNSTABLE linux-ia32 (1/601) smartos-ia32 (4/601) smartos-x64 (9/601) linux-x64 (2/601) http://jenkins.nodejs.org/job/nodejs-master/261/
18:09 < trevnorris> but they set the Exception in the called function as well, then return false.
18:10 < trevnorris> ooh, ok. this'll work.
18:10 < bnoordhuis> trevnorris: for bonus points, annotate it with __attribute__((warn_unused_result)) when gcc
18:12 < trevnorris> ah, interesting. I like it.
18:12 < bnoordhuis> trevnorris: btw, scheduling an exception is not something i'm a fan of
18:13 < bnoordhuis> that's policy rather than mechanism
18:13 < bnoordhuis> throwing exceptions should be done as close to the "edge" as possible
18:13 < bnoordhuis> where "edge" is the js/c++ boundary
18:13 < bnoordhuis> even better if you move it over the edge, into js land
18:15 < trevnorris> some of the methods on Buffer.prototype point directly to cc methods, but i'll do that when I can.
18:19 <@indutny> bnoordhuis: gcc specifix annotation, nice tip! ;)
18:19 <@indutny> is it patch for v8?
18:23 < bnoordhuis> indutny: no, it's something we can do in node
18:24 <@indutny> yep
18:24 <@indutny> we need macro for this
18:24 <@indutny> MUST_USE_RESULT
18:24 <@indutny> no gcc specific shit
18:24 <@indutny> agree?
18:24 < bnoordhuis> yeah, sure
18:24 <@indutny> another question
18:24 <@indutny> do we really need it? :)
18:24 <@indutny> are there enough functions that it needs to be applied to?
18:26 < bnoordhuis> wrong question
18:26 < bnoordhuis> the right question is: will it help catch bugs?
18:29 <@indutny> bnoordhuis: ok
18:29 <@indutny> bnoordhuis: generally I agree with this
18:29 <@indutny> ok, back to civ IV
18:29 < bnoordhuis> priorities. fedor has them :)
18:42 -!- mode/#libuv [+o TooTallNate] by ChanServ
18:47 <@TooTallNate> just got a report for
18:47 <@TooTallNate> "Error: connect Unknown system errno 64"
18:47 <@TooTallNate> darwin ^
18:47 <@TooTallNate>  /cc bnoordhuis 
18:48 <@tjfontaine> that's another network one
18:48 <@TooTallNate> yup
18:48 <@tjfontaine> probably a broken route or vpn issue
18:48 <@TooTallNate> just checking if there's a mapping we can add or whatever
18:49 < bnoordhuis> TooTallNate: that's EHOSTDOWN
18:49 <@TooTallNate> bnoordhuis: are we mapping it already (it was from node v0.10.2, so it's possible it's old)
18:49 <@tjfontaine> I don't think we have a UV_HOSTDOWN?
18:55 < bnoordhuis> TooTallNate, tjfontaine: no, there's no mapping for it right now
19:13 <@tjfontaine> sigh http://jenkins.nodejs.org/job/nodejs-master-windows/69/DESTCPU=ia32,label=windows/console
19:18 <@MI6> nodejs-master-windows: #69 ABORTED windows-ia32 (119/601) windows-x64 (124/601) http://jenkins.nodejs.org/job/nodejs-master-windows/69/
19:25 <@indutny> ttyl
19:25 < trevnorris> seeya
19:32  * isaacs fg
19:33 < trevnorris> bnoordhuis: thx for the review. pushed. think the only thing i'll need your eyes on again is ParseArrayIndex exception stuff.
19:33 <@MI6> joyent/libuv: Ben Noordhuis master * b1d390e : windows: don't use uppercase in include filename - http://git.io/9C5mCA
19:40 <@MI6> libuv-master-gyp: #60 UNSTABLE windows-x64 (5/190) smartos-ia32 (2/189) windows-ia32 (3/190) smartos-x64 (2/189) http://jenkins.nodejs.org/job/libuv-master-gyp/60/
19:42 <@MI6> libuv-master: #123 UNSTABLE windows (3/190) smartos (2/189) http://jenkins.nodejs.org/job/libuv-master/123/
19:53 < trevnorris> isaacs: oh, so close. maybe it'll land today! \o/
20:07 <@isaacs> trevnorris: kewl!
20:09 <@TooTallNate> trevnorris: so excited!
20:18 < trevnorris> TooTallNate: say I create a Persistent<> for a Local<>. I can't seem to figure out how to retrieve the that Persistent<> later (e.g. after it's been passed back/forth to js. know if there's a way?
20:19 < bnoordhuis> trevnorris: no
20:19 <@TooTallNate> trevnorris: ya, unfortunately i've resorted to keeping a weak map in C++ land for that :(
20:19 < trevnorris> bummer. :-/
20:21 <@MI6> libuv-node-integration: #113 UNSTABLE smartos-x64 (6/601) linux-x64 (32/601) smartos-ia32 (6/601) linux-ia32 (33/601) http://jenkins.nodejs.org/job/libuv-node-integration/113/
20:21 < trevnorris> bugger.
20:23 < trevnorris> TooTallNate: so w/ the patch there's no way to retrieve the Persistent created. would it be enough if I just returned?
20:24 <@TooTallNate> trevnorris: from what?
20:24 <@TooTallNate> Buffer.alloc()?
20:24 <@TooTallNate> trevnorris: p.s. a Function object bufferified is fucking awesome looking :p
20:24 <@TooTallNate> r.e. your slides from the other day
20:24 < trevnorris> lol. thanks.
20:24 < trevnorris> from the Buffer instance. Buffer::New() returns Local<Object>
20:25 < trevnorris> and to save the performance I don't attach the persistent internally (e.g. hidden value or what not)
20:25 < trevnorris> so if there's no way to retrieve a persistent that's been created for a Local<> then right now there's no way to retrieve the Persistent at all.
20:28 < trevnorris> TooTallNate: lemme make a small change and see how much it hurts.
20:29 < bnoordhuis> sigh. `yum provides whatever` always wants to download half the internet
20:29 <@TooTallNate> trevnorris: i don't think that's too much of a problem IMO, unless i'm missing something...
20:29 <@TooTallNate> trevnorris: i mean i could always create a new Persistent over the Local IFF i need that 
20:29 < bnoordhuis> good thing this server only has a handful of repos configured
20:30 < trevnorris> TooTallNate: well if that's the case then I'll not worry about it. :)
20:31 < trevnorris> bnoordhuis: so if you're cool w/ the new way of handling errors then this might just land
20:31 < trevnorris> (sorry, it's just hard to contain the excitement)
20:33 < bnoordhuis> trevnorris: you force-pushed your changes, i assume?
20:33 < trevnorris> bnoordhuis: yeah
20:33 < trevnorris> i'm probably up to 200 by now :P
20:33  * vandenoever is playing with libuv, making a c++ wrapper
20:33 < trevnorris> tjfontaine could verity that.
20:33 < bnoordhuis> makes it hard to see what you changed after the last review round
20:33 < vandenoever> c++11 in fact
20:34 < trevnorris> ah, sorry
20:34 < bnoordhuis> well, i can probably work some `git diff` magic
20:34 < bnoordhuis> provided the old patchset is still in my reflog
20:36 < trevnorris> TooTallNate: yeah, so a single SetHiddenValue more than doubles buffer instantiation. :P
20:36 <@tjfontaine> who what where when
20:36 < trevnorris> oh, was just joking about how many times i've forced pushed to that branch.
20:37 < trevnorris> tjfontaine: is jenkins taking a nap? it's been determining my merge status for over an hour now.
20:38 <@tjfontaine> trevnorris: actually this is more fall out from tls_wrap landing
20:38 < trevnorris> ah, ok.
20:39 <@tjfontaine> one of the tests is failing in a way that you need to attach to clear a buffer or something to let it continue on
20:39 < trevnorris> TooTallNate: it was too advanced for my talk but using Buffer.alloc() on a function to cross communicate status flags between js/cc has been a fun experiment.
20:40 <@TooTallNate> trevnorris: hahaha
20:40 <@TooTallNate> trevnorris: but so can i call a C++ equivalent of Buffer.alloc() and pass it an existing pointer?
20:41 < trevnorris> TooTallNate: Buffer.alloc() is just a js safe equivalent of smalloc::Alloc()
20:41 < trevnorris> so, yes.
20:42 <@TooTallNate> trevnorris: like i wanna, for example, associate ("alloc", but not really :p) a C function pointer, to a JS Function object
20:42 <@TooTallNate> trevnorris: is that possible with the new API?
20:43 < trevnorris> TooTallNate: um. technically yes, but not in a way that won't cause your app to explode. :P
20:43 < trevnorris> TooTallNate: all alloc's use SetIndexed... on the object passed, so they're exposed as an array index on the js side.
20:44 < trevnorris> and if you pass a void*, it can technically be attached, but as soon as someone tries to access it via fn[n] in js it's going to explode.
20:47 <@TooTallNate> trevnorris: i mean the .length would be 0
20:47 < trevnorris> .length would be undefined. Buffer instantiation is what actually sets the length.
20:48 < trevnorris> all alloc does is attach memory
20:50 <@tjfontaine> trevnorris: I pulled windows back out of pull requests until I can give windows-master some love
20:50 < trevnorris> heh, ok.
20:54 <@tjfontaine> set should_throw or something?
21:03 < bnoordhuis> trevnorris: see comments
21:03 < trevnorris> bnoordhuis: already working on 'em. :)
21:04 < trevnorris> bnoordhuis: though i'm not sure how to handle the return error/undefined thing.
21:04 < bnoordhuis> most of it is pretty minor except for the ThrowRangeError thing
21:04 < bnoordhuis> trevnorris: it depends on the call site
21:04 < bnoordhuis> if you have a function/method that returns Local<Value> or Handle<Value>
21:04 < bnoordhuis> you can `return ThrowRangeError("BAM");`
21:05 < bnoordhuis> for things that return e.g. Handle<Object>, well...
21:05 < bnoordhuis> in some cases you could probably call ThrowRangeError() and `return Handle<Object>();`
21:05 < bnoordhuis> that'll return an empty Handle
21:06 < bnoordhuis> it's up to the caller to check retval.IsEmpty(), of course
21:08 < trevnorris> ah, ok. i see
21:09 < trevnorris> bnoordhuis: wait. wtf. those should be asserts anyways right? i mean none of the cases where it returns <Object> are called from js anyways.
21:10  * trevnorris tries to remember what he was thinking. coming up blank.
21:11 < bnoordhuis> trevnorris: if it's a clear bug that <some condition that should not fail>, then yes, assert :)
21:12 <@MI6> joyent/node: Sam Roberts master * 226a20d : doc: call console module 'console' not 'stdio' - http://git.io/1s90fQ
21:12 < trevnorris> bnoordhuis: awesome. thanks again. just about done w/ those.
21:33 <@MI6> joyent/node: Ben Noordhuis master * b916525 : src: clean up `using` directives - http://git.io/Q0GKUQ
21:42 <@MI6> nodejs-master: #262 UNSTABLE osx-ia32 (2/601) smartos-ia32 (3/601) smartos-x64 (8/601) http://jenkins.nodejs.org/job/nodejs-master/262/
21:48 < bnoordhuis> signing off. have a good night, people
21:48 < trevnorris> bnoordhuis: night. w/ those changes look good to you?
21:49 < bnoordhuis> what changes?
21:49 < bnoordhuis> ah, i see
21:49 < bnoordhuis> you force-pushed again, didn't you? :)
21:49 < trevnorris> heh, yeah. :)
21:50 < trevnorris> just 20 secs ago.
21:50 < bnoordhuis> okay, i'll look at it tomorrow
21:50 < bnoordhuis> it's too big for a quick scan
21:50 < bnoordhuis> sleep tight!
21:50 < trevnorris> night
21:52 < trevnorris> damn. so close. except for the throw to assert, the other few were cosmetic.
21:58 < trevnorris> well, I could pull an indutny and just push it. ;)
21:58 <@tjfontaine> glutton for punishment
21:59 < trevnorris> who, him or me?
21:59 <@tjfontaine> you ;)
21:59 < trevnorris> ah, come on. the tls changes had more fallout then these will. :)
21:59 <@tjfontaine> I'm skeptical :)
22:00 <@tjfontaine> not that I don't want the changes to happen
22:00 <@tjfontaine> but as with everything, few people follow bleeding edge :/
22:01 < trevnorris> oh, the repercussions for upgrading from 0.10 to 0.12 will not be trivial, for sure.
22:02 < trevnorris> but if jenkins gives me a green then i'm pushing!
22:02 < trevnorris> though that's just about impossible. :P
22:08 <@tjfontaine> let me enable windows, then nothing gets merged :P
22:12 < trevnorris> oh, man...
22:13 <@MI6> nodejs-master: #263 UNSTABLE osx-ia32 (1/601) smartos-ia32 (4/601) smartos-x64 (6/601) http://jenkins.nodejs.org/job/nodejs-master/263/
22:14 -!- mode/#libuv [+o piscisaureus_] by ChanServ
22:15 <@MI6> nodejs-master-windows: #70 UNSTABLE windows-ia32 (122/601) windows-x64 (123/601) http://jenkins.nodejs.org/job/nodejs-master-windows/70/
22:17 -!- mode/#libuv [+o TooTallNate] by ChanServ
22:17 <@tjfontaine> ok, test-child-process-detached seems to be whats hanging in the windows build for now
22:17 <@tjfontaine> but stream wrap is generally unhappy as well
22:18 <@tjfontaine> one for trevnorris, http://jenkins.nodejs.org//job/nodejs-master-windows/70/DESTCPU=x64,label=windows//tapTestReport/test.tap-5/
22:19 < trevnorris> wtf
22:20 < vandenoever> once i've called uv_tcp_init, but not yet uv_accept, how do get the uv_tcp_t out of the loop?
22:20 <@tjfontaine> uv_close?
22:21 < vandenoever> also with the same tcp_t?
22:21 <@tjfontaine> I'm confused what you mean, what do you mean "out of the loop" you want the incoming connection?
22:22 < trevnorris> tjfontaine: that was also failing in /69/
22:22 <@tjfontaine> trevnorris: I'm not saying it's new :)
22:22 < trevnorris> :P
22:22 < trevnorris> well, is there any way we can determine when that started failing?
22:23 <@tjfontaine> "yes" though I wouldn't worry about that just yet
22:23 <@tjfontaine> this stream_wrap failure is worse
22:23 < trevnorris> link?
22:23 <@tjfontaine> we're hitting an assert http://jenkins.nodejs.org//job/nodejs-master-windows/70/DESTCPU=x64,label=windows//tapTestReport/test.tap-10/
22:24 <@tjfontaine> but I need to rebuild and see which handle we're failing on, but I'm guessing this is a pipe issue
22:24 < trevnorris> tjfontaine: every time, or sporadically?
22:24 <@tjfontaine> windows-ia32 (122/601) windows-x64 (123/601)
22:24 <@tjfontaine> 122 and 123 failures
22:24 < trevnorris> lol
22:24 <@tjfontaine> should be closer to 8 or 10 failures :)
22:25 < trevnorris> tjfontaine: but that has nothing to do w/ my buffer changes, right?
22:26 <@tjfontaine> trevnorris: nothing to do with you, all to do with tls_wrap (stream_wrap refactor)
22:26 < trevnorris> ah ok
22:27 < vandenoever> tjfontaine: what i mean is that i want to call uv_loop_delete
22:27 <@tjfontaine> vandenoever: on the listener socket?
22:28 < vandenoever> no, after all connections are closed
22:28 <@tjfontaine> uv_close it is
22:28 < vandenoever> that is, in on_connected, i run uv_tcp_init, then find out that i have to quit
22:30 < vandenoever> i'm calling uv_close, which has a problem 
22:35 <@tjfontaine> ya, ok this is totally a pipe issue in master-windows
22:44 -!- mode/#libuv [+o piscisaureus_] by ChanServ
22:48 <@tjfontaine> hey there piscisaureus_ 
22:48 <@piscisaureus_> hey ther tjfontaine
22:48 <@tjfontaine> how goes?
22:49 <@piscisaureus_> you really want to know? :)
22:49 <@piscisaureus_> I have a headache
22:49 <@piscisaureus_> otherwise, I'm great
22:49 <@tjfontaine> a headache or a migraine?
22:50 <@piscisaureus_> tjfontaine: well migraine is pretty serious right? This isn't I hope. I might be just tired.
22:50 <@piscisaureus_> but how are you?
22:50 <@tjfontaine> they can be yes, but yes hopefully sleep or some fluids will help you
22:50 <@piscisaureus_> Prepared your nodeconf slide deck yet?
22:50 <@tjfontaine> I luckily don't have any talks to give :)
22:50 <@tjfontaine> but I was just in a prep meeting for one
22:51 <@piscisaureus_> ah cool
22:51 <@tjfontaine> and for now I'm trying fix the 110 new test failures on windows :)
22:51 <@piscisaureus_> are you going to do a dance with the joyent staff
22:51 <@piscisaureus_> that would be nice
22:51 <@piscisaureus_> tjfontaine: eh?
22:51 <@tjfontaine> I am not sure anyone would want to see me dance
22:51 <@piscisaureus_> tjfontaine: what happened
22:52 <@tjfontaine> piscisaureus_: the stream wrap refactor seems to not be allocating buffers for pipes on windows, or maybe did the sync pipe 
22:52 <@tjfontaine> that didn't land yet though did it?
22:52 <@piscisaureus_> this is why I'd love to have a great ci dashboard?
22:52 <@piscisaureus_> :)
22:52 <@piscisaureus_> let me see
22:52 <@tjfontaine> heh ya ya, I'm almost done
22:53 <@tjfontaine> assert in stream_wrap.cc:208
22:53 <@tjfontaine> I'm still compiling atm
22:53 <@tjfontaine> but echo | node -pe 'process.stdin.resume()' 
22:53 <@tjfontaine> is all you need to do to trigger it
22:53 < vandenoever> activity here is great, i'm wondering if libuv is supposed to be used outside of node
22:54 <@tjfontaine> it is, and people do use it
22:54 <@tjfontaine> vandenoever: piscisaureus_ can field your questions better than I can right now
22:55 < vandenoever> tjfontaine: i'm using libuv to make nice c++11 wrapper around for other uses
22:56 <@tjfontaine> is your code available somewhere so it's easy to refer to it explicitly when you have questions
22:56 <@piscisaureus_> tjfontaine: there's no assert there? https://github.com/joyent/node/blob/master/src/stream_wrap.cc
22:56 < vandenoever> but it's not too easy unf., which is understandable given the emphasis on performance 
22:57 < vandenoever> tjfontaine: not yet, but it can be
22:57 <@tjfontaine> hrm # Assertion failed: buf.base != NULL, file src\stream_wrap.cc, line 208
22:58 < vandenoever> ah, so node has a c++ wrapper for libuv, but it's internal so far
22:58 < vandenoever> or is that simple a part of v8?
22:58 <@piscisaureus_> vandenoever: it's a v8 api wrapper
22:59 < vandenoever> http://paste.kde.org/776498/
22:59 <@piscisaureus_> vandenoever: libuv was written mainly for node. But nowadays some other projects use it and we try to not make them hate us
22:59 <@piscisaureus_> (luvit, pyuv. rust, julialang)
22:59 < vandenoever> piscisaureus_: good attitude :-D
22:59 <@tjfontaine> piscisaureus_: sorry https://github.com/joyent/node/blob/master/src/stream_wrap.cc#L203
22:59 <@tjfontaine> 3's 8's meh
22:59 <@tjfontaine> :)
23:00 < vandenoever> the paste is very much a work in progress
23:00 <@piscisaureus_> tjfontaine: that assert is wrong. looking at the rest of the code
23:00 < vandenoever> trying to use raii pattern to get elegant c++ api
23:01 < vandenoever> http://paste.kde.org/776504/ for c++ hightlighting
23:01 <@piscisaureus_> tjfontaine: yes, drop the assert, this can happen in linux too
23:01 <@piscisaureus_> (although more rare)
23:02 <@piscisaureus_> tjfontaine: the assert is just bogus, someone probably forgot to remove it.
23:02 <@tjfontaine> piscisaureus_: 
23:02 <@tjfontaine> er ok
23:02 <@piscisaureus_> emptyness?
23:02 <@tjfontaine> distracted at work
23:04 <@tjfontaine> piscisaureus_: so what's the rare case that this happens on unix, I'm confused I was assuming that OnReadCommon happened after an alloc_cb triggered
23:04 <@piscisaureus_> tjfontaine: not on case of an error
23:04 <@tjfontaine> ah ok
23:05 <@piscisaureus_> piscisaureus_: bnoordhuis also said he was going to change the api at some point
23:06 <@tjfontaine> shoudl the check be that if nread > 0 assert that the buffer has been allocated or is it really not worth guarding against?
23:06 <@piscisaureus_> ^-- tjfontaine; that was for you
23:06 <@piscisaureus_> where he would not guarantee to always return a buffer, not realizing that this guarantee was never there
23:06 <@piscisaureus_> anyway
23:06 <@piscisaureus_> tjfontaine: anyway, https://github.com/joyent/node/blob/b9165252e3a9115fe991042b75caa08c0993e347/src/stream_wrap.cc#L610
23:06 <@piscisaureus_> is where we're dealing with that situatiokn
23:07 <@tjfontaine> but we may get here from tls_wrap?
23:07 <@tjfontaine> which iirc overrides StreamWrap::DoRead
23:07 <@piscisaureus_> yeah let me fire up Visual Studio to check that
23:09 <@tjfontaine> ok OnReadCommon should happen before TLSWrap::DoRead so ya ok this probably doesn't need to be here
23:10 <@tjfontaine> there is a small discrepency in how they react in the error case, but whatever
23:11 <@piscisaureus_> tjfontaine: dunno, doesn't look like tlswrap overwrites DoRead ....
23:11 <@piscisaureus_> s/overwrites/overrides/
23:12 <@piscisaureus_> tjfontaine: nevermind - it does override it
23:12 <@piscisaureus_> but it doesn't look at the buf at all
23:12 <@tjfontaine> right because it's going to use the BIO
23:15 <@tjfontaine> anyway I'll drop the assert, thanks for looking into it with me
23:16 <@MI6> joyent/node: Bert Belder master * 1bf6d78 : stream_wrap: remove bogus assert - http://git.io/4cWKfw
23:16 <@piscisaureus_> tjfontaine: ^
23:16 <@tjfontaine> thanks :)
23:24 <@piscisaureus_> g'nite i'm off again
23:25 <@tjfontaine> night
23:25 <@piscisaureus_> tjfontaine: btw - I'm wondering how hard it would be to set up some sort of mongo database that caches jenkins output
23:25 <@piscisaureus_> tjfontaine: and have it index on sha
23:26 <@tjfontaine> piscisaureus_: yes, except that's not how jenkins+github works right now
23:26 <@tjfontaine> piscisaureus_: well, it's on the merge sha not necessarily by commit, but yes I get your point
23:26 <@tjfontaine> I have stuff I'm working on that should make you happy
23:26 <@piscisaureus_> tjfontaine: cool
23:27 <@piscisaureus_> tjfontaine: what is it?
23:27 <@tjfontaine> piscisaureus_: the dashboard that you want, plus stuff to go and do backfill on it
23:27 <@piscisaureus_> tjfontaine: cool!!
23:27 <@piscisaureus_> tjfontaine: are you building it yourself or did you find some other project?
23:28 <@tjfontaine> mostly myself, nothing I've found in jenkins world to match
23:31 <@piscisaureus_> tjfontaine: nice. don't forget to use angularjs but do it different that I did.
23:31 <@piscisaureus_> tjfontaine: also http://build.chromium.org/p/client.v8/console looks much better (for inspiration) but we don't have 70 builds being tests. That's why I invented this test-grouping thing.
23:31 <@piscisaureus_> s/being tests/being tested/
23:31 <@tjfontaine> nod
23:31 <@tjfontaine> if people want it pretty though they will need to style it :P
23:31 <@piscisaureus_> good!
23:32 <@tjfontaine> but ya
23:47 <@MI6> nodejs-master: #264 UNSTABLE smartos-ia32 (3/601) smartos-x64 (5/601) http://jenkins.nodejs.org/job/nodejs-master/264/
23:48 <@MI6> nodejs-master-windows: #71 FAILURE windows-ia32 (121/601) windows-x64 (125/601) http://jenkins.nodejs.org/job/nodejs-master-windows/71/
23:48 <@tjfontaine> sigh
23:52 < trevnorris> tjfontaine: though 72 should show the improvement
23:54 -!- mode/#libuv [+o sblom] by ChanServ
23:54 <@tjfontaine> Cannot delete workspace: java.io.IOException: Remote call on windows failed
23:54 <@tjfontaine> ERROR: Cannot delete workspace: java.io.IOException: Remote call on windows failed
23:54 <@tjfontaine> trevnorris: wishful thinking on your part :P
23:54 <@tjfontaine> trevnorris: it was the normal race condition because it was leaving child processes behind
23:55 <@tjfontaine> 73 should be better
23:56 <@tjfontaine> sblom: ooc is there a way (job ojects aside) that a parent process can be notified of pids of child processes created?
23:56 <@tjfontaine> not of immediate children, but of grand children
--- Log closed Tue Jun 18 00:00:45 2013