--- Log opened Thu Apr 18 00:00:42 2013
00:18 < MI6> nodejs-v0.10: #144 FAILURE smartos-x64 (5/578) windows-ia32 (10/578) windows-x64 (9/578) smartos-ia32 (4/578) osx-x64 (1/578) http://jenkins.nodejs.org/job/nodejs-v0.10/144/
00:23 <@piscisaureus_> > var t = 0; setInterval(function(){++t},1); setTimeout(function(){console.log(t)},1000)
00:23 <@piscisaureus_> 127
00:23 <@piscisaureus_> ^-- windows, sigh
00:41 < MI6> libuv-node-integration: #22 FAILURE osx-x64 (1/580) osx-ia32 (2/580) smartos-ia32 (1/580) windows-ia32 (9/580) smartos-x64 (4/580) http://jenkins.nodejs.org/job/libuv-node-integration/22/
01:00 < MI6> joyent/libuv: Bert Belder v0.10 * a396388 : windows: remove superfluous assert statement - http://git.io/RY1fzQ
01:02 < MI6> libuv-v0.10: #40 UNSTABLE osx (1/186) linux (1/186) windows (4/187) smartos (3/186) http://jenkins.nodejs.org/job/libuv-v0.10/40/
01:03 < MI6> joyent/libuv: Bert Belder master * 79f9629 : Merge branch 'v0.10' (+3 more commits) - http://git.io/QNSmnw
01:03 < MI6> joyent/libuv: piscisaureus created branch reviewme - http://git.io/C3Rljg
01:08 < MI6> libuv-master: #77 UNSTABLE osx (4/188) windows (5/189) linux (6/188) smartos (10/188) http://jenkins.nodejs.org/job/libuv-master/77/
01:08 <@indutny> isaacs: yt?
01:19 < MI6> libuv-node-integration: #23 FAILURE smartos-ia32 (1/578) windows-ia32 (9/580) windows-x64 (8/578) smartos-x64 (2/578) linux-ia32 (1/578) http://jenkins.nodejs.org/job/libuv-node-integration/23/
01:27 -!- mode/#libuv [+o piscisaureus_] by ChanServ
01:28 < MI6> libuv-node-integration: #24 FAILURE osx-x64 (1/580) osx-ia32 (2/580) windows-ia32 (9/580) http://jenkins.nodejs.org/job/libuv-node-integration/24/
10:26 < MI6> joyent/node: Ben Noordhuis master * 8e190bf : Merge remote-tracking branch 'origin/v0.10'  Conflicts: 	src/node_os.cc (+11 more commits) - http://git.io/cOsaLQ
10:46 < MI6> nodejs-master: #157 FAILURE osx-ia32 (1/582) windows-ia32 (9/582) osx-x64 (1/582) smartos-x64 (1/582) smartos-ia32 (3/582) http://jenkins.nodejs.org/job/nodejs-master/157/
11:04 < bnoordhuis> hail bajtos
11:04 < bajtos> bnoordhuis: cheers :)
11:05 < bnoordhuis> bajtos: how did your foray into the v8 profiler go?
11:07 < bajtos> bnoordhuis: I'll switch to private
12:02 -!- mode/#libuv [+o piscisaureus_] by ChanServ
12:03 <@piscisaureus_> bnoordhuis: hey, do you mind if I land that timer patch? Let's at least try it out in master for a while, we can revert it before 0.12 if a serious issue comes up.
12:04 <@piscisaureus_> bnoordhuis: I do have other strategies in mind that might work, but I like the simplicity of this approach a lot.
12:04 <@indutny> hey people
12:04 < bnoordhuis> piscisaureus_: well, what i don't like that it cheats
12:04 < bnoordhuis> i mean, it changes loop->time behind the user's back
12:04 < bnoordhuis> how are you supposed to write a program that expects accurate time that way?
12:05 < bnoordhuis> sup fedor?
12:05 <@piscisaureus_> bnoordhuis: well, the time becomes more accurate "on average" because of it
12:05 < bnoordhuis> "on average" :)
12:05 <@piscisaureus_> bnoordhuis: although the worst-case deviation doesn't change
12:05 <@piscisaureus_> bnoordhuis: but if you really need exact times you want to use hrtime
12:06 <@piscisaureus_> bnoordhuis: unfortunately I can't make the loop be driven by hrtime because it has adverse performance impact
12:07 < bnoordhuis> let's wait for sblom, maybe he knows a better solution
13:50 -!- mode/#libuv [+o piscisaureus_] by ChanServ
14:44 <@piscisaureus_> bnoordhuis: yo
14:45 < bnoordhuis> piscisaureus_: olla
14:45 <@piscisaureus_> bnoordhuis: another interview at 5 right?
14:46 < bnoordhuis> yep
14:46 <@piscisaureus_> (the last one for a while or so it seems)
14:46 < bnoordhuis> good
14:46 <@piscisaureus_> bnoordhuis: you got the curriculum for this guy?
14:48 < bnoordhuis> nope
14:48 < bnoordhuis> i asked for it but that recruiter guy never sent it
14:49 < SquirrelCZECH> hmm
14:50 <@piscisaureus_> bnoordhuis: lemme forward it to you
14:52 < bnoordhuis> got it
15:00 -!- mode/#libuv [+o piscisaureus_] by ChanServ
15:02 <@isaacs> good morning
15:13 < bnoordhuis> sup isaac?
15:16 < tjfontaine> yo
15:17 < tjfontaine> sigh windows
15:33 -!- mode/#libuv [+o TooTallNate] by ChanServ
15:43 < tjfontaine> sigh must be something up with github clones
15:48 < SquirrelCZECH> one thing that I hate about #python
15:48 < SquirrelCZECH> mos of them know only twisted
15:48 < SquirrelCZECH> and can't understand when someone choose something different
15:49 < tjfontaine> twisted, the python library that java nerds vomitted up
15:49 < SquirrelCZECH> :D
15:50  * SquirrelCZECH got nothing against twisted, he only hates whene people behaves like there is only one solution
15:51 < tjfontaine> I have things against twisted, wouldn't it be nice if it had sane ipv6 support? (though i don't think Ig et to really make that argument anymore)
15:51 < SquirrelCZECH> :D
15:51 < SquirrelCZECH> nah, I still feel lost in all this encryption stuff
15:52 < SquirrelCZECH> tjfontaine: Reason why I don't feel like using twisted is lack of Python 3 support, which pyuv have
15:52 < tjfontaine> yes well, I suppose py3+twisted is non-trivial work
15:52 < tjfontaine> or rather
15:53 < tjfontaine> a large tedious piece of work
15:53 < SquirrelCZECH> and now it moves to reason: "why I should rebuild it in first place?"
16:13 < tjfontaine> isaacs, TooTallNate: and while resolve certainly has a meaning in node, I sometimes worry people will think it resolves symlinks
16:14 <@isaacs> tjfontaine: yeah
16:14 <@isaacs> tjfontaine: but we already have fs.realpath for that
16:15 <@isaacs> tjfontaine: i think isAbsolute belongs in path, but not isResolved
16:15 <@TooTallNate> isaacs: ya i can't think of when "isResolved()" would be useful
16:15 < tjfontaine> I know, but the callback for realpath is resolvedPath in the docs :)
16:15 <@isaacs> just need a cross-platform version of `if (path.match(/^\//)) { do absolute stuff }`
16:16 <@indutny> hoya
16:16 <@indutny> isaacs: I finally caught you
16:16 <@isaacs> tjfontaine: yeah, because it *resolves* symlinks :)
16:16 <@indutny> have few minutes?
16:16 <@isaacs> indutny: I AM YOURS, SIR
16:16 < tjfontaine> isaacs: heh
16:16 <@isaacs> whassup?
16:16 <@indutny> great
16:16 < tjfontaine> writev!
16:16 < tjfontaine> :P
16:16 <@indutny> .ondata/.onend/.readStart/.readStop
16:16 <@indutny> tjfontaine: and writev
16:17 <@indutny> do we still want to remove them in 0.12?
16:17 < tjfontaine> I forgot about the other one
16:17 <@indutny> if yes - do you have any specific plans, can I hack on it?
16:17 <@isaacs> indutny: you mean, on handle objects?  or on Socket objects?
16:17 <@indutny> both
16:17 <@isaacs> indutny: on socket objects YES PLEASE OMG THAT HACK IS HORRID.
16:17 <@isaacs> indutny: on handles, meh
16:17 <@indutny> ok
16:17 <@indutny> so .ondata/.onend -  yes
16:17 <@indutny> and you don't have any specific plans for it
16:17 <@indutny> ok, good to go then :)
16:17 <@isaacs> indutny: i consider handls internal API, and streams2 kind of works ok with pushy sources anyway
16:18 <@indutny> ok
16:18 <@indutny> what about writev?
16:18 <@isaacs> indutny: i think that this could be a good pass for the first part of http 0.12 refactoring, now that tj's broken up the mega garbage barge of http.js
16:18 <@indutny> haha
16:18 <@isaacs> (ie, change around to not use onend/ondata)
16:18 <@indutny> yeah
16:18 <@indutny> I got it
16:18 <@indutny> ok
16:18 <@isaacs> my plan was to also turn the Parser into something that is less dangerous and leaky
16:19 <@indutny> yeah
16:19 <@indutny> one last thing I wanted you to look into
16:19 <@indutny> is writev
16:19 <@indutny> I've changed it a lot
16:19 <@indutny> and it is less dangerous now
16:19 <@isaacs> it'd be awesome if you could do: var p = new Parser(); socket.pipe(p); p.on('request', function(req) { server.emit('request', req, new Response(req)) })
16:19 <@isaacs> indutny: ok, i'll review that today
16:20 <@indutny> kewl
16:20 <@indutny> we're in one TZ
16:20 <@indutny> almost
16:20 <@isaacs> orly?
16:20 <@indutny> so feel free to ping me through day
16:20 <@isaacs> where are you now?
16:20 <@indutny> yeah
16:20 <@indutny> bahamas
16:20 <@isaacs> (or are you just nocturnal)
16:20 <@indutny> yep
16:20 <@isaacs> oh, kewl, only like 4 hours away :)
16:20 <@indutny> yes
16:20 <@indutny> so, no way you'll escape me :)
16:20 <@indutny> haha
16:21 < tjfontaine> isaacs: btw if a pullrequest was previously built by jenkins, after someone forcepushes it will be resynced, but we only trigger new pull request builds automatically if they're OneOfUs, so others still need someone to push the button the first time
16:22 <@isaacs> ok
16:22 <@isaacs> that's probably a good DoS p[rotection :)
16:22 < tjfontaine> if there are people you want in the whitelist that don't hang out in this room let me know :)
16:22 <@isaacs> tjfontaine: it'd be awesome if there was a "add to oneofus" button there, too
16:22 < tjfontaine> ya that's in my plan as well
16:22 <@isaacs> kewl
16:23 <@isaacs> i can't think of any off the top of my head, but usually i recognize known-good people on github
16:23 < tjfontaine> nod
16:23 <@isaacs> tjfontaine: i'll just ping you in the comments when i see them
16:23 < tjfontaine> yup
16:33 -!- mode/#libuv [+o piscisaureus_] by ChanServ
17:18 < eris0xff> hi
17:19 < eris0xff> I'm integrating a foreign library into libuv and I'm trying to pull strerror for the current loop
17:19 < eris0xff> i can get uv_last_err for the default loop, but I'm trying to determine the current loop.  Any easy way to do this?
17:20 <@indutny> what do you mean by "current" loop?
17:20 < eris0xff> the way some do it in pthread is to do a pthread_setspecific 
17:21 < eris0xff> hehe i knew you'd ask that
17:21 <@indutny> there're no such thing :)
17:21 < eris0xff> I know
17:21 < eris0xff> its all context
17:21 < eris0xff> an I haven't had my coffee yet :-)
17:21 < eris0xff> (sorry head just buried in thousands of lines of code.)
17:22 <@indutny> np
17:22 <@indutny> that happens to all of us
17:23 < eris0xff> So there's a call in this library to pull the current errbuf via strerror(errno).   I can translate that easily enough to uv_last_err(uv_default_loop())
17:23 < eris0xff> But that only works for the default loop obviously.
17:24 <@indutny> well, you should store uv_loop_t somewhere
17:24 < eris0xff> Which I assume is the first loop in the first thread, but I could be wrong.
17:24 < eris0xff> yes
17:24 <@indutny> in your tls or anywhere
17:24 <@indutny> you want uv_thread_getspecific?
17:24 < eris0xff> Which means I need to create a thread-specific storage key
17:24 <@indutny> or what?
17:24 < eris0xff> yes
17:24 <@indutny> I'm not sure if it'll work on windows
17:24 < eris0xff> hmm
17:24 <@indutny> yeah, it might work
17:25 <@indutny> but I don't really know
17:25 < eris0xff> hang on
17:26 < eris0xff> actually it should be loop local storage since you could  have multiple loops in a single thread (though its a little dicey)
17:27 <@indutny> obviously
17:27 <@indutny> but that depends on your needs
17:27 < eris0xff> sure
17:27 < eris0xff> i'd be happy with at least TLS.  I don't don't usually go beyond that
17:28 < MI6> libuv-v0.10: #41 UNSTABLE linux (1/186) osx (2/186) smartos (3/186) windows (4/187) http://jenkins.nodejs.org/job/libuv-v0.10/41/
17:28 < eris0xff> i think LLS would be easier to implement
17:28 < eris0xff> hmm
17:29 < eris0xff> maybe uv_loop_t*thisloop->data
17:31 < eris0xff> hehe that's exactly where it is
17:32 < eris0xff> now i just need to track the current event back to the loop
17:33 -!- mode/#libuv [+o sblom] by ChanServ
17:49 < trevnorris> morning all
17:52 <@indutny> morning
17:53 < MI6> libuv-node-integration: #25 UNSTABLE smartos-ia32 (1/578) linux-ia32 (1/578) smartos-x64 (1/578) windows-x64 (7/578) windows-ia32 (8/578) http://jenkins.nodejs.org/job/libuv-node-integration/25/
18:09 < trevnorris> isaacs: this is funny. Chrome doesn't do proper uint parsing for ArrayBuffer: "new ArrayBuffer(-1)" -> "RangeError: ArrayBuffer size is not a small enough positive integer."
18:09 <@isaacs> ha
18:10 -!- mode/#libuv [+o piscisaureus_] by ChanServ
18:10 <@isaacs> trevnorris: what about if you do some really large negative value?
18:10 <@isaacs> trevnorris: does it wrap back around?
18:10 <@isaacs> no, i guess not
18:10 <@isaacs> any - will be 1...
18:10  * isaacs jsut remembered 2's complement...
18:10 < trevnorris> yup: new ArrayBuffer(-0xffffffff)
18:15 <@indutny> try Infinity
18:15 <@indutny> or NaN
18:15 <@indutny> hehe
18:15 <@indutny> surprisingly they work
18:16 < trevnorris> wtf. oh, it's because Uint32Value() converts them to 0.
18:16 <@indutny> yep
18:24 -!- mode/#libuv [+o sblom] by ChanServ
19:17 < tjfontaine> what a frustratingly lame hack, but at least this works
19:18 -!- mode/#libuv [+o piscisaureus_] by ChanServ
19:36 < tjfontaine> ok I've hacked around the broken testReport nonsense http://jenkins.nodejs.org/job/nodejs-master/lastCompletedBuild/testReport/
19:44 <@piscisaureus_> sblom: what do you think about https://github.com/joyent/libuv/pull/785 ?
19:50 < bnoordhuis> piscisaureus_: opinions on removing src/unix/cygwin.c?
19:50 < bnoordhuis> i'm fairly certain it doesn't actually compile
19:51 <@piscisaureus_> bnoordhuis: *shrug*, how hard would it be to make it compile?
19:51 <@piscisaureus_> if the answer is yes, that file is centuries behind, then drop it for sure.
19:52 < tjfontaine> we certainly don't make an effort to try and keep it in line
19:52 < tjfontaine> do we want jenkins to do mingw builds?
19:53 < bnoordhuis> might be worthwhile, i guess
19:53 < bnoordhuis> the makefile build technically supports mingw
19:53 < bnoordhuis> (gyp however doesn't)
19:53 < tjfontaine> nod
19:54 < tjfontaine> it would need to be a separate job from the standards, but not impossible to do
19:54 < bnoordhuis> if you feel like it. might be a good thing to have
19:55 < bnoordhuis> i never test on mingw and i don't think bert does either
19:55 < tjfontaine> I'll add it to my todo, but not with a high priority
19:59 <@piscisaureus_> tjfontaine: mingw for libuv would be in order, but I'd prefer separate x86 and x64 builds better.
20:00 < MI6> joyent/libuv: Ben Noordhuis master * 7f8130a : unix: remove src/unix/cygwin.c  The cygwin build has been broken for a lo - http://git.io/4NmHHg
20:00 < bnoordhuis> piscisaureus_: how hard would it to build dlls at release time
20:01 < bnoordhuis> *would it be
20:01 < tjfontaine> piscisaureus_: for the existing jobs?
20:01 < tjfontaine> we could make jenkins build and publish jobs after release
20:01 <@piscisaureus_> bnoordhuis: well depends, not for me but for you?
20:01 < tjfontaine> *dll's and .so's and .dylibs
20:02 < bnoordhuis> piscisaureus_: hm. cross-compiling is always hit and miss
20:02 <@piscisaureus_> tjfontaine: I like that idea but you'd need to publish x86 and x64 libs
20:02 <@piscisaureus_> bnoordhuis: no you want to use msvc for that
20:02 < tjfontaine> no problem, we already do that for node
20:02 < tjfontaine> jenkins.nodejs.org/nightlies
20:02 <@piscisaureus_> right, yes, ok
20:02 < MI6> libuv-master: #78 UNSTABLE smartos (3/188) windows (4/189) linux (1/188) osx (2/188) http://jenkins.nodejs.org/job/libuv-master/78/
20:03 < bnoordhuis> we should advertise the nightlies more
20:04 < bnoordhuis> isaacs: ^ maybe something for http://nodejs.org/download/
20:04 <@isaacs> bnoordhuis: i agree
20:05 < tjfontaine> shoudl they be the installers or just the binary tarballs?
20:06 < bnoordhuis> tarballs i guess? you can't sign them right?
20:06 < tjfontaine> depends on how much you trust the jenkins slaves really :)
20:09 < bnoordhuis> hm. they're public facing. i say let's go for tarballs for now
20:09 < tjfontaine> k
20:10 < MI6> joyent/node: bnoordhuis created branch isaacs-review-this - http://git.io/CBkpSw
20:10 < bnoordhuis> ^ needs careful and thorough review
20:11 < tjfontaine> heh
20:12 < tjfontaine> brb food
20:26 < MI6> libuv-node-integration: #26 FAILURE smartos-ia32 (7/582) osx-x64 (1/582) linux-ia32 (1/582) smartos-x64 (4/582) osx-ia32 (1/582) windows-ia32 (9/582) http://jenkins.nodejs.org/job/libuv-node-integration/26/
20:27 < tjfontaine> swear to god, only about 5 plugins for jenkins know how to deal with matrix jobs
20:27 < tjfontaine> what a fucking waste
20:28 <@piscisaureus_> back to buildbot? :)
20:28 < tjfontaine> heh
20:29 < tjfontaine> in my head is a design for a very light weight ci, some weekend I may even get the motivation to do it
20:31 < MI6> nodejs-master: #158 FAILURE windows-ia32 (10/582) linux-ia32 (1/582) smartos-x64 (1/582) smartos-ia32 (1/582) http://jenkins.nodejs.org/job/nodejs-master/158/
20:32 < trevnorris> tjfontaine: just to double check, CI is auto-run for all PR?
20:33 < tjfontaine> trevnorris: CI is auto-run for those in the whitelist (like yourself), and auto-rebuild for all others (things built at least once)
20:33 < trevnorris> ah, cool. and it'll auto detect a force-push and rebuild?
20:34 < tjfontaine> yup, if you have an old req that hasn't been built before it will probably need triggered manually
20:34 < trevnorris> oh no. for some reason just noticed that 4964 was building.
20:34 < tjfontaine> ah, and you had force'd it?
20:34 < trevnorris> like several times a day
20:35 < tjfontaine> sok, won't hurt things too much :)
20:35 < trevnorris> heh
20:39 < trevnorris> it's amazing how a well placed assert can save your ass.
20:41 < trevnorris> in js if you really screw up the app dies. in cc if you really screw up all hell breaks loose. the later is something I'm still getting accustomed to.
20:59 -!- mode/#libuv [+o TooTallNate] by ChanServ
21:08 < trevnorris> TooTallNate: mind looking over the Buffer.alloc() section here: http://git.io/tL4K6A
21:08 < trevnorris> would like your feedback for module developers.
21:09 <@TooTallNate> trevnorris: cool, i'll take a look
21:09 < trevnorris> thx
21:21 < sblom> piscisaureus_: Overall https://github.com/joyent/libuv/pull/785 looks fine to me. I wish computers weren't so awful at dealing with time, but I think the workarounds here seem totally sane.
21:21 < sblom> piscisaures_: Regarding bnoordhuis's favorite line, am I being dumb or would `time.QuadPart = (uint64_t)loop->time` work without bnoordhuis objecting?
21:22 < sblom> (Obviously, bnoordhuis, feel free to tell me I'm being dumb also.)
21:22 < sblom> (May not even need that `uint64_t` cast.)
21:22 <@piscisaureus_> sblom: yay! <-- bnoordhuis, look at that!
21:24 <@piscisaureus_> sblom: you're right, I was coming from `LARGE_INTEGER* time = (LARGE_INTEGER*) &loop->time` but now that I'm no longer loop->time directly I think your solution is better.
21:24 <@piscisaureus_> * no longer modifying loop->time
21:24 < sblom> Cool (and I think I got the cast backward, but I'm glad you caught my meaning).
21:27 < trevnorris> isaacs, and anyone else: buffer creation benchmark. new on left, old on right: https://gist.github.com/trevnorris/5416336
21:28 < trevnorris> though, SlowBuffer is now improperly named...
21:29 < trevnorris> actually, that's just a byproduct of the test, let me run each individually and post those
21:33 <@isaacs> trevnorris: this makes me feel excitement.
21:33 < trevnorris> isaacs: thanks. preliminaries show ~20% increase across most Buffer methods.
21:33 < trevnorris> still have some work to do on the SlabAllocator to gain those improvements, but it'll get there.
21:38 < trevnorris> there are two pieces of architecture i'm not in love w/ though. anyone know if it's possible to turn an existing object into an instance of another?
21:39 <@isaacs> trevnorris: well, there's __proto__
21:40 <@isaacs> trevnorris: but i mean, gross.
21:40 < trevnorris> isaacs: this is for the cc side. also now that I've removed __proto__ from Buffer, i'm going to try to keep it out. =)
21:42 <@piscisaureus_> C:\programming\bcc55\Bin>make
21:42 <@piscisaureus_> MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
21:42 <@isaacs> trevnorris: and also, in es6, you can `delete Object.prototype.__proto__` for safety to remove the footgun
21:42 < trevnorris> ah, whoa.
21:43 <@isaacs> not in V8, but there's a lot of cases where I'd kind of like to do tha
21:43 <@isaacs> t
21:43 < MI6> joyent/libuv: Bert Belder master * ffe2ef0 : windows: deal with the fact that GetTickCount might lag  We use GetQueued - http://git.io/5rHZAQ
21:44 < bnoordhuis> isaacs: http://git.io/CBkpSw
21:46 <@isaacs> bnoordhuis: +1
21:46 < MI6> libuv-master: #79 UNSTABLE smartos (3/188) windows (4/189) linux (2/188) osx (2/188) http://jenkins.nodejs.org/job/libuv-master/79/
21:48 < bnoordhuis> thanks
21:48 < MI6> joyent/node: Ben Noordhuis v0.10 * a835a2f : website: add link to nightlies on download page - http://git.io/msj7Zg
21:50 <@indutny> bnoordhuis: have you already landed cluster?
21:50 <@indutny> patches
21:50 <@indutny> going to take a look at them
21:54 < trevnorris> isaacs: updated: https://gist.github.com/trevnorris/5416336
21:54 < trevnorris> like that there is a more linear degradation as buffer size increases.
21:59 -!- mode/#libuv [+o sblom] by ChanServ
22:09 <@isaacs> indutny: i'm still reviewing
22:09  * isaacs also getting distracted by email backlogs...
22:09 <@isaacs> indutny: but we both should look it over.
22:10 <@indutny> on what?
22:10 <@indutny> isaacs: email backlog?
22:10 <@indutny> or what?
22:10 <@indutny> sorry, I've missed the messages
22:11 < MI6> nodejs-v0.10: #146 UNSTABLE windows-ia32 (7/578) smartos-x64 (1/578) smartos-ia32 (1/578) windows-x64 (10/578) http://jenkins.nodejs.org/job/nodejs-v0.10/146/
22:11 < MI6> libuv-node-integration: #27 FAILURE smartos-ia32 (1/582) osx-x64 (1/582) linux-ia32 (1/582) smartos-x64 (2/582) linux-x64 (1/582) osx-ia32 (1/582) windows-ia32 (9/582) http://jenkins.nodejs.org/job/libuv-node-integration/27/
22:14 <@indutny> isaacs: ?
22:15 <@isaacs> bnoordhu1s: I'm seeing this on 0.10: https://gist.github.com/isaacs/5416645
22:15 <@isaacs> bnoordhu1s: my suspicion is that it's related to 92023b4
22:16 <@isaacs> indutny: i was saying that we should both look over the cluster changes.
22:16 <@indutny> ah
22:16 <@indutny> ok, I'm looking at it
22:16 <@isaacs> indutny: but i keep getting distracted by things
22:16 <@indutny> heh
22:16 <@indutny> yeah, same on my side
22:18 <@isaacs> bnoordhu1s: ah, so, instead of doing the "::" ipv6 style "any address", it's doing the ipv6 mapping of the ipv4 "any address" on my machine, it looks like
22:18 <@isaacs> bnoordhu1s: i think that should be allowed.  if you agree, we can just make the test accept that.
22:19 < bnoordhu1s> ah
22:19 <@indutny> oh, that reminds me about my ipv6 patches
22:20 <@indutny> https://github.com/joyent/node/pull/5087
22:20 <@indutny> what we have ended with about that ^ ?
22:22 <@isaacs> indutny: so, i think the dual-stack listen was basically unanimously decided as a good thing.
22:22 <@isaacs> indutny: for 0.12, obviously
22:22 <@isaacs> indutny: but the dual-stack dns lookup was more complicated.
22:22 <@indutny> ah, right
22:23 <@indutny> ok
22:23 <@indutny> it seems that it needs further investigation/discussion
22:23 <@isaacs> yeah
22:23 <@isaacs> that's what i remember, as well
22:23 <@indutny> don't you mind if I'll put it on v0.12 milestone?
22:23 <@indutny> so we'll be aware of it
22:23 < MI6> joyent/node: Ryan Doenges v0.10 * 6101eb1 : assert: put info in err.message, not err.name  4716dc6 made assert.equal( - http://git.io/BT0V5w
22:25 < bnoordhu1s> indutny: re cluster, can you focus on the big picture things first? :)
22:25 <@indutny> sure
22:25 <@indutny> but that bothers me much
22:26 <@indutny> and its hard to see big things because diff is pretty broad
22:26 < bnoordhu1s> use a side-by-side diff
22:26 < bnoordhu1s> or open the old and new file in your editor
22:26 <@indutny> thank you for advice
22:27 < tjfontaine> haha checkout "octosplit" chrome plugin
22:27 <@indutny> I'm using it ;)
22:27 <@indutny> pretty nice, isn't it
22:28 < tjfontaine> ya it works slightly better
22:28 < tjfontaine> still not entirely all the context I would want
22:30 < MI6> nodejs-v0.10: #147 UNSTABLE windows-ia32 (7/578) linux-ia32 (1/578) smartos-x64 (1/578) smartos-ia32 (1/578) windows-x64 (8/578) http://jenkins.nodejs.org/job/nodejs-v0.10/147/
22:31 < trevnorris> isaacs: i have a ridiculously crazy ass performance tuning idea for buffers, though not sure it would be accepted.
22:32 < trevnorris> remember how we're doing the array thing for the ticker to communicate between cc and js?
22:32 < trevnorris> since node's single threaded it be easy to create a single shared buffer struct that would communicate numeric arguments.
22:33 < trevnorris> i'd do a prototype, if anyone would consider it acceptable in the case that it shows significant performance improvements.
22:34 < tjfontaine> I'm not entirely sure what you mean, I know what you mean by the tickinfo stuff, what would you be communicating back and forth?
22:34 < trevnorris> tjfontaine: to do a Uint32Value() is expensive, but by exposing the memory to js in an external data array
22:34 < trevnorris> it can be wrapped in a struct on the cc side and read in
22:35 < trevnorris> so no argument conversions.
22:35 < trevnorris> and no need for type checking since the data array is always guaranteed to be that type.
22:35 < bnoordhuis> trevnorris: Uint32Value() is only expensive if the argument is not a SMI
22:36 < bnoordhuis> passing arguments in typed arrays would no doubt work
22:36 < bnoordhuis> but i'm kinda sceptical that there are many places where you'll see a noticeable speedup
22:36 < trevnorris> bnoordhuis: that's good to know. haven't done any benchmarking previously to check that.
22:36 < trevnorris> ok, i'll try it out on a couple things and report back. =)
22:37  * isaacs fg, reading trevnorris's idea
22:40 <@isaacs> trevnorris: smells like premature optimization, to me.  my recommendation is to put it in your "crazy ideas" file, and come back to it if you're ever bored ;)
22:41 < trevnorris> isaacs: heh. it'll take me 20 to see if it offers any perf gain. then off to scope out the SlabAllocator!
22:48 < MI6> nodejs-v0.10: #148 UNSTABLE windows-ia32 (7/578) smartos-x64 (2/578) smartos-ia32 (2/578) windows-x64 (7/578) linux-x64 (2/578) http://jenkins.nodejs.org/job/nodejs-v0.10/148/
22:49 -!- mode/#libuv [+o TooTallNate] by ChanServ
22:49 < trevnorris> bnoordhuis: of course, correct as always. ;-)
22:51 < bnoordhuis> no difference? :)
22:51 < trevnorris> nope.
22:52 < trevnorris> all that damn persisting is what kills me.
22:52 < trevnorris> I really wish there was a flag that could be passed to SetIndexedPropertiesToExternalArrayData that said
22:53 < trevnorris> "delete external char on object gc"
22:54 <@indutny> that's possible
22:54 <@indutny> but noone cares :)
22:54  * trevnorris sulks in the corner
22:54 <@indutny> hahaha
22:55 < trevnorris> i mean, not needing to persist, dispose or any of that crap. what a wonderful world it would be.
22:55 <@indutny> well, noone from v8 tea
22:55 <@indutny> v8 soup
22:55 < trevnorris> yeah. maybe if i'm feeling dangerous i'll jump in. though all the gc stuff still confuses the hell outta me
22:56 <@indutny> read books, read code, think
22:57 <@indutny> you'll get into
22:57 <@indutny> that's the only way to get into
22:57 <@indutny> by starting working with code
22:57 <@indutny> bnoordhuis: kill is an alias for destroy
22:57 <@indutny> ooook
22:58 <@indutny> so why the hell is it defined on the top
22:58 <@indutny> and using .destroy()
22:58 <@indutny> which is defined only conditionally
22:58 <@indutny> bnoordhuis: see my point?
22:58 < trevnorris> heh, yeah. now that my cc skills are just above novice the code should make more sense. =)
23:00 < bnoordhuis> indutny: both the worker and the master have a destroy() method
23:00 <@indutny> oh gosh
23:01 <@indutny> makes sense now
23:01 <@indutny> ok, it'd be probably not a bad idea to mention it...
23:01 < bnoordhuis> it's in the documentation, fedor :)
23:02 <@indutny> can't see it
23:02 <@indutny> :)
23:02 < tjfontaine> hmm some env isn't getting passed because NODE_COMMON_PORT is coming up as 12346 :)
23:02 < bnoordhuis>   0 This method is aliased as `worker.destroy()` for backwards                                                                                 
23:02 < bnoordhuis>   1 compatibility. 
23:02 < bnoordhuis> paste fail but you get the idea
23:02 <@indutny> ok
23:02 <@indutny> probably I've downloaded old patch
23:02 <@indutny> no such thing in my branch
23:03 < bnoordhuis> that's from the already existing documentation
23:03 <@indutny> ah
23:04 < bnoordhuis> tjfontaine: are you referring to my cluster PR?
23:04 <@indutny> ok
23:04 < tjfontaine> bnoordhuis: ya
23:04 < bnoordhuis> said documentation could be improved btw
23:04 < tjfontaine> I notice you did just forcepush it though
23:04 < bnoordhuis> but i'll save that for a followup commit
23:04 < tjfontaine> well recently
23:04 < bnoordhuis> yeah, that's true
23:04 < bnoordhuis> and will again in a few seconds
23:05 < bnoordhuis> ah no, i already did - github got its act together
23:05 < tjfontaine> eventual consistency
23:05 < tjfontaine> gotta love it
23:09 < tjfontaine> hmm if there was a consistency lag then it's likely that this error is bogus, but it happened again
23:09 < tjfontaine> #AssertionError: {"addressType":4,"address":"127.0.0.1","port":12346,"fd":"undefined"} deepEqual {"address":"127.0.0.1","port":11400,"addressType":4,"fd":"undefined"}
23:10 < kellabyte> why gyp over cmake? I'm trying to decide what to use so curious :)
23:10 < bnoordhuis> tjfontaine: right. i can reproduce
23:11 < tjfontaine> kellabyte: v8
23:11 < bnoordhuis> kellabyte: they both work okay. cmake's command language is ugly but otoh, you get feature detection
23:11 < kellabyte> tjfontaine: there's no v8 in libuv?
23:12 <@indutny> kellabyte: dependency
23:12 < bnoordhuis> of nodejs
23:12 <@indutny> kellabyte: no v8 in libuv
23:12 < tjfontaine> kellabyte: libuv exists because of nodejs
23:12 < trevnorris> and could we say nodejs exists because of v8?
23:12 <@indutny> kellabyte: gyp is good at managing dependencies
23:12 <@indutny> trevnorris: no
23:12 < trevnorris> i mean, what would have been used instead?
23:13 < bnoordhuis> spidermonkey, presumably
23:13 < tjfontaine> there's also the upstream webkit one
23:13 < bnoordhuis> javascriptcore
23:13 < tjfontaine> right
23:13 < kellabyte> indutny: if it wasn't for v8 would you make the same decision you think?
23:13 < bnoordhuis> hardly anyone uses that though, it seems
23:13 < bnoordhuis> embedders, i mean
23:13 < tjfontaine> indeed
23:13 <@indutny> kellabyte: I think yeah
23:14 <@indutny> kellabyte: I was curious about server-side javascript
23:14 <@indutny> and not about v8 itself
23:14 < tjfontaine> clearly we should have gone with automake
23:14 < trevnorris> ooh. that'd be beastly. love mozilla, but their legacy thing of having everything in mozilla-central is a bitch
23:14 <@indutny> but spidermonkey is awful
23:14 <@indutny> trevnorris: no offence
23:14 <@indutny> its just hard to deal with
23:14 < trevnorris> indutny: none taken. i fully agree.
23:14 <@indutny> I was like touching it a lot when working on couchdb
23:14 < tjfontaine> it's turning more into v8 each release :)
23:15 <@indutny> and that wasn't really pleasant
23:15 < bnoordhuis> mwah, mozilla-central is not the worst thing in the world
23:15 < bnoordhuis> and you can always stick with official releases if that bothers you
23:15 < kellabyte> indutny: understood, just looking for tips from way more experienced people than me since I want to start learning how to make my code easy to build on multiple platforms without hating life :P
23:15 <@indutny> haha
23:15 <@indutny> there're no such way for you
23:15 <@indutny> you can only simplify life for others
23:15 <@indutny> but you'll feel x10 pain
23:16 < kellabyte> indutny: true, but if one was better than the other, good to know that :P
23:16 < bnoordhuis> indutny: i'm working on a spidermonkey port in my off-time btw :)
23:16 < tjfontaine> death to c++?
23:17 <@indutny> bnoordhuis: port to what?
23:17 < bnoordhuis> port of
23:17 < bnoordhuis> nodejs
23:17 <@indutny> nooooooooooooo
23:17 <@indutny> you're my enemy now
23:17 <@indutny> I hate you
23:18 < bnoordhuis> if you already hate me for this
23:18 < bnoordhuis> you'd better not ask your wife where she was last night
23:18  * bnoordhuis ducks
23:18 < bnoordhuis> back on topic, what's so bad about SM?
23:19 < bnoordhuis> err, in this context i should probably have typed "spidermonkey"
23:19 <@indutny> yep
23:19 <@indutny> lets reverse it
23:19 <@indutny> what's so good about it?
23:19 < CoverSlide> S&M is wonderful
23:19 < bnoordhuis> it runs on a lot of platforms
23:20 <@indutny> bnoordhuis: same is v8?
23:20 < bnoordhuis> and architectures
23:20 < bnoordhuis> v8 only runs well on x86 and arm
23:20 <@indutny> well, v8 mostly works on mips
23:20 <@indutny> if patched a bit
23:20 < bnoordhuis> mostly, indeed
23:20 <@indutny> do you need it?
23:20 < bnoordhuis> well
23:20 <@indutny> I believe it'd be really hard to use it here
23:21 < CoverSlide> ok well who the hell runs mips any except rms?
23:21 <@indutny> considering how much memory this devices usually have
23:21 < CoverSlide> *anyway
23:21 < bnoordhuis> i've had quite a few companies contact me because they want to run node on sparc or s390
23:21 < bnoordhuis> and power (aix)
23:21 <@indutny> oh gosh
23:21 <@indutny> so you sold your soul to oracle
23:22 < bnoordhuis> and ibm
23:22 <@indutny> bnoordhuis: ok, cluster LGTM
23:22 <@indutny> if you'll split it in two commits
23:23 <@indutny> anything else I should take a look at?
23:23 < bnoordhuis> hm? what two commits would those be?
23:23 < trevnorris> actually, have a friend working at oracle that is considering switching the project to use libuv.
23:23 <@indutny> bnoordhuis: you've introduced .seq thing
23:23 <@indutny> bnoordhuis: it wasn't present before
23:23 < bnoordhuis> and?
23:23 < bnoordhuis> trevnorris: what's he working on?
23:23 <@indutny> and this doesn't fits "clean up" commit
23:23 <@indutny> its like I'll fix net.js and add a feature at the same time
23:24 <@indutny> seems to be bad idea
23:24 < bnoordhuis> i also sneaked a "DRY" in there :)
23:24 < bnoordhuis> that .seq property is only on internal messages
23:24 <@indutny> and?
23:24 < trevnorris> bnoordhuis: new product set to release. one from the acquisition of DataScalar.
23:24 < bnoordhuis> so it doesn't count
23:24 <@indutny> it counts
23:24 <@indutny> its not cleaning up
23:24 < bnoordhuis> only upward
23:24 <@indutny> ok, I'll remember that
23:24 <@indutny> when you'll say the same to me
23:25 -!- mode/#libuv [+o TooTallNate] by ChanServ
23:25 <@indutny> what about failing tests?
23:25 < bnoordhuis> indutny: i'll reword the commit log to say "rewrite" instead of "cleanup"
23:25 <@indutny> bnoordhuis: compromise :)
23:26 <@indutny> isaacs: writev
23:26 <@indutny> look at it
23:26 < MI6> joyent/node: isaacs master * 0bccb34 : Merge remote-tracking branch 'ry/v0.10' (+2 more commits) - http://git.io/zsCiJg
23:26  * indutny is almost crying
23:26 < trevnorris> bnoordhuis: it's for a new in-memory distributed sql db, or some such.
23:27 < bnoordhuis> ah, i've read about that
23:27 < trevnorris> yeah. he was one of the founders before acquisition.
23:28 <@indutny> bnoordhuis: so what's up with failing CI tests?
23:29 < tjfontaine> the environment isn't being copied down to the child, more or less
23:29 <@indutny> ah
23:29 <@indutny> that's what causes it
23:30 < tjfontaine> the child is expecting 12346, but the master is in the offset position
23:30 < tjfontaine> (so multiple jobs can run in parallel)
23:30 < bnoordhuis> i'm kind of surprised
23:30 < bnoordhuis> i thought workers didn't inherit the env
23:31 < tjfontaine> that would frustrate me, if it were the case, and not just because of CI
23:33 < bnoordhuis> right, the old cluster.js merges process.env with the env the user passes in
23:38 <@indutny> ok guys
23:39 <@indutny> I'm returning back to bad internet
23:39 <@indutny> here are some awful kids that ain't going to shut up anywhere soon
23:39 < trevnorris> bnoordhuis: what's "DeleteSlabAllocator" for? I can't tell where "atexit" is invoked
23:40 < tjfontaine> trevnorris: http://linux.die.net/man/3/atexit
23:40 < trevnorris> ah, ok.
23:41 < trevnorris> so is it a best practice to cleanup resources before the process exits?
23:41 < bnoordhuis> trevnorris: yes and no
23:41 < tjfontaine> mostly to make valgrind happy I'm sure :)
23:41 < bnoordhuis> indeed :)
23:41 < trevnorris> ah, ok.
23:43 < trevnorris> hm. first time diving deep into src/*_wrap. need to brush up on my libuv. :)
23:44 < MI6> nodejs-master: #159 FAILURE windows-ia32 (8/582) linux-ia32 (1/582) smartos-x64 (1/582) smartos-ia32 (1/582) http://jenkins.nodejs.org/job/nodejs-master/159/
23:47 < bnoordhuis> signing off for today. have a good night everyone
23:48 <@indutny> you too man
23:48 <@indutny> sleep tight
23:48 <@indutny> or whatever
23:48 <@indutny> is it morning?
23:48 < trevnorris> night
23:48 <@indutny> ah, its deep night
23:48 <@indutny> stupid TZ difference
23:48 <@indutny> why isn't earth flat
23:49 < kellabyte> because aliens
23:50 <@isaacs> we should definitely do away with time zones, though
23:50 <@isaacs> and this silly 60/60/24 thing
23:50 <@isaacs> just use ksecs and Msecs
23:50 <@indutny> sixty is a cool thing
23:50 <@isaacs> nah
23:50 <@isaacs> it's bullshit
23:50 <@indutny> you can count it on hand
23:50 < trevnorris> anyone know why "args.Holder()" is used in some places instead of "args.This()"?
23:51 <@indutny> that's a good question
23:51 <@isaacs> trevnorris: no idea.
23:51 <@indutny> better use args.This()
23:51 <@indutny> I believe we previously thought that args.Holder() is better one
23:51 < trevnorris> yeah. ok. i'll throw up a quick PR for that.
23:51 <@indutny> but its mostly irrelevant
23:51 <@isaacs> bnoordhuis, indutny: are there things to pull into libuv for master?
23:52 <@indutny> not that I'm aware of
23:57 <@indutny> isaacs: have a couple of minutes?
23:57 <@indutny> I've rebased this https://github.com/joyent/node/pull/5257
23:58 < trevnorris> here ya go: 5334
23:58 < trevnorris> now CI, hurry up and build it!
--- Log closed Fri Apr 19 00:00:48 2013