--- Log opened Tue Mar 19 00:00:30 2013
--- Day changed Tue Mar 19 2013
00:00 < trevnorris> so anyone have ideas how to handle the fact that setting ".message" doesn't do anything anymore?
00:00 < tjfontaine> it's not that it doesn't do anything, it does something, the problem is that something is calling stack which only gets formatted once
00:01 < trevnorris> but if that was the case, then why in 3.14 does it work until you call the .stack getter?
00:01 < tjfontaine> see deps/v8/src/messages.js 
00:01 < trevnorris> yeah. i'm combing through that now.
00:01 < tjfontaine> that's the way it works
00:02 < tjfontaine> stack si a OneShotAccessor
00:03 < trevnorris> ah, i see now. in captureStackTrace it sets the stack with "%MarkOneShotGetter"
00:03 < trevnorris> ok, got it
00:04 < tjfontaine> so the question is what's causing it to evaluate `.stack` such that you're losing your .message
00:05 < trevnorris> we're not loosing our .message
00:05 < trevnorris> > var e = new Error('first');
00:05 < trevnorris> > e.message
00:05 < trevnorris> 'first'
00:05 < bnoordhuis> trevnorris: re the backtrace thing, to make debugging easier for users
00:05 < bnoordhuis> it's disabled now though
00:05 < tjfontaine> it's lost in the sense that .stack is already been called and you won't get your custom message
00:05 < bnoordhuis> in v0.10 that is, not in master
00:07 < trevnorris> tjfontaine: yeah. the stack message is being generated only once, when the Error is instantiated. that's what you're saying right?
00:07 < trevnorris> bnoordhuis: hm? like in this specific case, or is there a bigger "backtrace" thing used in node?
00:08 < tjfontaine> `.stack` is being evaluated before `.message =`, but that doesn't seem possible from lib/ so I'm guessing this must be in src/
00:08 < trevnorris> bnoordhuis: i'm not sure why the backtrace thing is even necessary. i changed it to throw in the returned function, not with the backtrace and it gave the same info, plus some.
00:10 < tjfontaine> oh I'll be damned, DEBUG is set in this test :)
00:10 < tjfontaine> things you should look at before trying to find the problem
00:11 < trevnorris> tjfontaine: i'm confused. .stack is evaluated on instantiation.
00:12 < trevnorris> tjfontaine: check this https://gist.github.com/trevnorris/5192265
00:12 < trevnorris> i'd have imagined that the stack trace would have shown 'a' being thrown from blahblah()
00:12 < trevnorris> but it shows it was thrown from where it was instantiated.
00:12 < tjfontaine> yes, that's common way to capture debugging info
00:13 < tjfontaine> which is why that rethrow is there
00:13 < trevnorris> yeah. and like you pointed out. the stack is evaluated with "MarkOneShotGetter" from "captureStackTrace"
00:13 < trevnorris> so the stack will never be reevaluated.
00:14 < tjfontaine> ya, but where is `.stack` being called here? :P
00:15 < trevnorris> hm? in captureStackTrace they're getting the stack with "var stack = %CollectStackTrace(obj..."
00:15 < tjfontaine> no, I mean in fs
00:15 < trevnorris> it's not.
00:16 < tjfontaine> we don't set .message later anywhere else?
00:16 < trevnorris> yeah. we set .message later, but never use .stack.
00:16 < trevnorris> but only in that one spot (realize that's what you were asking)
00:16 < tjfontaine> so where are we using .stack now?
00:16 < tjfontaine> ok
00:16 < trevnorris> we aren't
00:17 < tjfontaine> so v8 just doesn't allow delayed message anymore I guess
00:17 < trevnorris> exactly
00:17 < trevnorris> as of commit 076470e5 (3.16.6)
00:17 < tjfontaine> well if you knew that why did you send me bouncing around on all this :P
00:17 < trevnorris> (well, um. that's from the official git mirror)
00:18 < trevnorris> oh, sorry. i didn't realize that until half way through this myself.
00:18 < trevnorris> then I guess I didn't communicate it :(
00:19 < tjfontaine> what a weird set of osx failures, I've never seen the write's fail like that before http://jenkins.nodejs.org/job/node-pullrequest/66/DESTCPU=ia32,label=osx/tapTestReport/
00:20 < MI6> joyent/libuv: piscisaureus created tag node-v0.5.6 - http://git.io/4RW6tg
00:20 < trevnorris> bnoordhuis: so will it be disabled in master anytime soon? i have a fix for it now.
00:22 < trevnorris> oh wait, nm.
00:27 < trevnorris> tjfontaine: just to confirm this stupidity: http://code.google.com/p/v8/issues/detail?id=2559
00:28 < tjfontaine> right ENOTABUG
00:28 < tjfontaine> so it's just a matter of changing wtf
00:29 < trevnorris> well, either it doesn't show the message, or it doesn't show the correct stack trace.
00:31 < trevnorris> so setting .message later is set in not a few places. anyone have an idea how to deal with this?
00:34 < bnoordhuis> aww. apparently clang doesn't support register void** rbp asm("%rbp");
00:34 < bnoordhuis> at least, not the version that ships with xcode
00:35 < trevnorris> is that 3.2?
00:36 < bnoordhuis> Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
00:36 < bnoordhuis> but no worries, __asm__ __volatile__ ("mov %%rbp, %0" : "=g" (rbp)); works
00:37 < trevnorris> wtf. glad you know that
00:37 < trevnorris> and thanks for the review.
00:38 < bnoordhuis> np
00:38 < tjfontaine> bnoordhuis: two runs in a row your ciphers patch had http://jenkins.nodejs.org/job/node-pullrequest/DESTCPU=ia32,label=osx/lastCompletedBuild/tapTestReport/ added the writefloat writedouble failure, but I'm not sure why
00:38 < bnoordhuis> err?
00:38 < trevnorris> oh,
00:38 < bnoordhuis> that's so unrelated i can't even think of a good analogy
00:38 < trevnorris> yeah. that's a known issue, but nothing to do with the ciphers patch...
00:39 < bnoordhuis> ah, the nan bug?
00:39 < bnoordhuis> tjfontaine: what compiler does it use?
00:48 <@sblom> Feedback on http://github.com/joyent/node/pull/5709 ?
00:49 <@sblom> (Fixes 4 unit tests on my machine--looks like our Jenkins server doesn't see any of these particular failures.)
00:51 <@sblom> Erm, 
00:51 <@sblom> https://github.com/joyent/node/pull/5079
00:51 <@sblom> finger-paste fail.
00:59 < tjfontaine> bnoordhuis: clang
01:00 < tjfontaine> I wonder what's changed such that it starts popping up now? or the test is actually now writing floats and doubles
01:04 < bnoordhuis> tjfontaine: there's a bug in ia32 clang w.r.t. nan handling
01:04 < tjfontaine> right, but why am I just now hitting it on osx?
01:05 < bnoordhuis> i don't know. you tell me :)
01:05 < tjfontaine> hehe
01:05 < tjfontaine> i will whence I return home
01:43 < bnoordhuis> /Users/bnoordhuis/src/v8/tmp/stacktrace(0x10ebff000): Trace(v8::Arguments const&)(0x10ec01570 0x10ec01581)
01:43 < bnoordhuis> /Users/bnoordhuis/src/v8/out/x64.debug/libv8.dylib(0x10ec0a000): v8::internal::MaybeObject* v8::internal::HandleApiCallHelper<false>(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*)(0x10ec82ff0 0x10ec83405)
01:43 < bnoordhuis> /Users/bnoordhuis/src/v8/out/x64.debug/libv8.dylib(0x10ec0a000): v8::internal::Builtin_Impl_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*)(0x10ec82fb0 0x10ec82fe3)
01:44 < bnoordhuis> /Users/bnoordhuis/src/v8/out/x64.debug/libv8.dylib(0x10ec0a000): v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>, v8::internal::Isolate*)(0x10ec7c710 0x10ec7c78c)
01:44 < bnoordhuis> Stub:CEntryStub(0x25834db062a0:0x25834db062ee)
01:44 < bnoordhuis> LazyCompile:~hop(0x25834db2d400:0x25834db2d423)
01:44 < bnoordhuis> LazyCompile:~next(0x25834db2d320:0x25834db2d343)
01:44 < bnoordhuis> ^ my stack walker works :)
01:45 < cjd> that is awesome
01:46 < bnoordhuis> https://gist.github.com/bnoordhuis/5192966 <- gist
01:46 < cjd> there's a gnu thing which does it
01:46 < bnoordhuis> you mean backtrace_symbols()?
01:47 < cjd> maybe
01:47 < cjd> "libunwind" comes vaguely to mind
01:47 < bnoordhuis> oh right, that too
01:47 < bnoordhuis> but neither understands v8 stack frames
01:47 < bnoordhuis> this one does :)
01:47 < cjd> aha
01:48 < cjd> I tried libunwind but scrapped it because it couldn't resolve line numbers and offsets are unfun
01:49 < cjd> esp. when everybody compiles it themselves
01:49 < bnoordhuis> wasn't that due to lack of debug symbols?
01:49 < cjd> I had debug symbols, perhaps I wasn't using the right functions
01:49 < bnoordhuis> i guess that's the next step for my stack walker but that means pulling in libelf and libdw
01:49 < cjd> might look into it again
01:50 < cjd> I haven't had a segfault report in a long time but I get occasional assertion fails
01:50 < bnoordhuis> we get them all the time in node
01:51 < bnoordhuis> mostly due to bad add-ons
01:51 < cjd> /nod
01:51 < bnoordhuis> but people still open issues in the bug tracker :(
01:51 < cjd> yeap
01:51 < bnoordhuis> i'm hoping this will make it easier to weed out bogus bug reports
01:52 < cjd> CLOSED: TAINTED ADDON, NOT GPL <evil grin>
01:52 < bnoordhuis> more like the other way around :)
01:53 < cjd> heh
01:53 < bnoordhuis> okay, time i went to bed. have fun
01:53 < cjd> gn
02:22 < tjfontaine> ircretary: tell bnoordhuis upon reflection on the ride home I know what changed, and it was me :)
02:22 < ircretary> tjfontaine: I'll be sure to tell bnoordhuis
02:39 < cjd> ircretary: tell bnoordhuis maybe useful https://github.com/mirrors/gcc/blob/master/libbacktrace/backtrace.h
02:39 < ircretary> cjd: I'll be sure to tell bnoordhuis
05:22 < trevnorris> ircretary: hi
05:22 < ircretary> trevnorris: Hello :)
05:23 < tjfontaine> I do love node and the module ecosystem at times
05:23 < tjfontaine> being able to server.on('NotFound', function (req, res) { proxy.proxyRequest(req, res); })
05:23 < tjfontaine> it's just so simple
05:27 < trevnorris> with the upgrade to 3.17, module authors will need access to the isolate. you guys think they should just get it via "Isolate* isolate = Isolate::GetCurrent()", or should node_isolate be exposed in node.h?
05:27 < tjfontaine> when you say Isolate::GetCurrent() you mean the v8 getter?
05:28 < tjfontaine> or a new node getter?
05:29 < tjfontaine> I would probably vote for node::GetIsolate() as compared to people having the static node_isolate
05:32 < trevnorris> Isolate::GetCurrent() is a new api which allows you to get the isolate of the current context. and since node only has one isolate, it will always point to node_isolate.
05:32 < trevnorris> (it's new since 3.14, i think...)
05:33 < trevnorris> cool. i'll need to update the docs showing these steps so authors don't get deprecation warnings all over the place.
05:33 < tjfontaine> well
05:34 < tjfontaine> I don't think v8::Isolate::GetCurrent is ideal, I would say node::GetIsolate makes more sense, as generally the compiler would be able to inline the latter
05:39 < tjfontaine> trevnorris: for comparison consider uv_default_loop() vs uv.h expossing default_loop_ptr
05:43 < trevnorris> would it basically be: "Isolate* node::GetIsolate() { return node::node_isolate; }" ?
05:46 < tjfontaine> ya
05:47 < trevnorris> how would we expose that w/o also exposing node::node_isolate?
05:49 < tjfontaine> by not including it in the namespace? or by specifying its visibility
05:50 < tjfontaine> by leaving it in node_internals and having node::GetIsolate in node.h :)
05:52 < trevnorris> oh, so simply including a header doesn't expose everything in the header? i'm such a newb...
05:53 < tjfontaine> well, at the very least if it's in node_internals.h it's less than public and you can change without worrying about who you screw over
05:54 < trevnorris> wait. what? node_object_wrap.h can get access to node::node_isolate by simply including node.h and using "extern v8::Isolate* node_isolate;" (at least that's what bn had me do)
05:56 < trevnorris> ok, i'm not going to worry about it. you c++ experts let me know what the best solution is and i'll just do it. :)
05:59 < trevnorris> tjfontaine: though there's been no consensus on what to do about the Error message thing. any ideas? i mean... we could go so far as to manipulate the stack string for DEBUG outputs, but...
06:02 < tjfontaine> manipulate it how?
06:06 < trevnorris> please don't laugh, but: "var st = err.stack.split('\n'); st[0] = 'Error: ' + err.message; err.stack = st.join('\n');"
06:06 < tjfontaine> stack is immutable
06:06 < tjfontaine> isn't it?
06:07 < trevnorris> > var er = new Error; er.stack = 'hi'; throw er;
06:07 < trevnorris> hi
06:08 < tjfontaine> what an inconsistent api
06:09 < trevnorris> yeah... making life real fun right now.
06:09 < tjfontaine> I woudl imagine that you wouldn't be able to modify the stack in future releases
06:12 < trevnorris> what I don't get is that .stack isn't anywhere in the ecmascript 262 standard I can find.
06:13 < trevnorris> here's the discussion on it's usage: http://mozilla.6506.n7.nabble.com/Error-stack-td106557.html
06:26 < trevnorris> hm. well. didn't think that upgrading v8 would have gotten hung up on something like this.
06:31 < cjd> ahh the benefits of being a BDFL
06:31 < tjfontaine> trevnorris: I wouldn't necessarily call this a hang-up, it's just an annoyance that will have to be accepted or worked around, the hangup would be more on general perf :)
07:01 <@indutny> morning
07:04 < trevnorris> tjfontaine: yeah. guess my ocd is getting the better of me here.
07:04 < trevnorris> but i'll make Errors my bitch https://gist.github.com/trevnorris/5194222
07:07 < trevnorris> one problem. sec.
07:10 < trevnorris> ^ indutny: consider throwing in the above to make debugger error messages work properly? ;-)
07:10 <@indutny> too hacky
07:11 < trevnorris> lol. and so much more.
07:11 < kevireilly> trevnorris: 24 is just setting 23 again
07:11 < trevnorris> no, don't worry. i'd be worried about node if something like that made it in.
07:12 < kevireilly> isn't throwing errors in node a no no?
07:12 < trevnorris> kevireilly: yeah. that's actually an important thing.
07:12 < trevnorris> this specific hack is for the debugger.
07:12 < kevireilly> ah gotcha
07:13 < cjd> need to change the message on an error after it's thrown?
07:13 < trevnorris> cjd: yeah, for proper stack traces.
07:14 < cjd> err
07:14 < trevnorris> check out test-fs-readfile-error.js and fs.js function rethrow().
07:15 < trevnorris> for a better stacktrace when you're returning a function it's better to instantiate the error in the parent.
07:15 < trevnorris> then throw it in the return.
07:15 < trevnorris> otherwise you can't tell where the returned function came from.
07:16 < trevnorris> also w/o the functionality "assert.throws" can fail (since it sets the message later)
07:16 < cjd> I get the idea
07:16 < cjd> throw + rethrow
07:16 < cjd> yeah
07:17 < cjd> perhaps add a C++ tool to rethrow which digs down into the nasties of V8 and doctors up the exception?
07:17 < cjd> because rethrow is always bad but painfully common
07:17 < trevnorris> i dunno. waiting for someone like isaacs or indutny or bnoorduis to give me an idea. i'm all out. =P
07:18 < cjd> hmm
07:18 < trevnorris> *bnoordhuis
07:18 < cjd> do js errors actually work the same as C++ exceptions?
07:18 < cjd> unwinding the stack and dwarf and all that fun
07:18 < kevireilly> trevnorris: new Error('foo').stack gives you the backtrace
07:19 < trevnorris> kevireilly: yeah. and before 3.16.6 if you set the message before calling the .stack getter then it would use the new message in the stack trace.
07:19 < trevnorris> but they took it out.
07:20 < trevnorris> cjd: i dunno.
07:20 < cjd> ahh
07:20 < cjd> so you want partial stack but with altered message
07:20 < cjd> errno
07:20 < cjd> full stack, altered message
07:20 < cjd> there we go
07:20 < trevnorris> yeah.
07:21 < trevnorris> that's what i'm forcing here: https://gist.github.com/trevnorris/5194222
07:21 < cjd> mhm
07:21 < trevnorris> but i'd never want anything like that anywhere.
07:21 < cjd> meh
07:21 < cjd> IMO rigid design patterns do more damage than hacks
07:21 < cjd> *shrug*
07:22 < cjd> well
07:22 < cjd> promiscuity of information does the most damage
07:22 < cjd> so people complain about tabs and spaces while making everything globally reachable and singleton :|
07:23 < cjd> can you throw non-errors? :)
07:24 < trevnorris> http://www.devthought.com/2011/12/22/a-string-is-not-an-error/
07:25 < cjd> throw { stack:...., message:.... };
07:25 < cjd> :)
07:25 < cjd> but yeah, the subtleties would kill you
07:25 < kevireilly> damn there is a way to pass multiple items and i cant remember now
07:25 < cjd> stack is readonly?
07:25 < trevnorris> no
07:26 < cjd> so alter stack instead of message?
07:26 < trevnorris> neither is message. it's just that the stack string is generated at instantiation, but not after that.
07:26 < trevnorris> no slick way to do this. the problem is on v8's side.
07:27 < cjd> catch (e) { e.message = ...; e.stack = e.stack.replace(/old message/, e.message);
07:28 < cjd> somewhat similar to your solution
07:29 < trevnorris> heh. ecmascript 262 15.11.4.4 repeats the same step twice. oops
07:30 < trevnorris> screw it. i've spent too many hours on this stupidity.
07:30 < cjd> is there something wrong w/ changing the stack as a string?
07:30 < cjd> other than uglyness
07:31 < trevnorris> yeah. that wold all work internally and stuff. just stupid that other people who are using that technique will also hit the same problem
07:32 < cjd> yeah, rethrowing is bad
07:32 < cjd> java makes error types immutable for some reason..
07:32 < trevnorris> unfortunately it's the only way to get a decent stack trace sometimes.
07:32 < cjd> somethign about best practice
07:32 < trevnorris> ugh
07:33 < cjd> I'd say change the stack as a string, if someone doesn't like it then it's their problem :)
07:33 < cjd> spending days hacking through assembly generators doesn't put features in the user's hand
07:35 <@indutny> isaacs: evening?
07:43 < trevnorris> ah ha! i see why AssertionError isn't printing the message. think I have a fix for it.
08:48 < trevnorris> why would "assert.equal(Infinity,'')" output 'AssertionError: "Infinity"'? doesn't make sense to me to display non string values as strings in the assertion error msg.
08:49 < trevnorris> especially when "assert.equal(5,'')" outputs "AssertionError: 5"
08:49 <@indutny> I bet it compares either numbers
08:49 <@indutny> or strings
08:49 <@indutny> so that's why you see this error
08:49 < trevnorris> oh, duh.
08:50 <@indutny> assert.equal(Infinity, 'Infinity')
08:50 <@indutny> does not throw ^
08:50 <@indutny> well, its actually doing ==
08:50 <@indutny> nvm
08:51 < trevnorris> yeah. i have a fix for the no messages displayed for assertion testing problem. but those are causing an issue.
08:58 < trevnorris> indutny: you said to revert the last two dtrace commits? one is from you about postmortem stuff, and the other is a bunch of reverts from bn.
09:00 < trevnorris> are those the two i'm supposed to revert?
09:00 <@indutny> yes
09:00 <@indutny> my first
09:00 <@indutny> and ben's second
09:01 < trevnorris> cool.
09:12 < trevnorris> indutny: must be tired. when I run "git revert f80f3c5f" there is no changeset.
09:13 < trevnorris> do I just need to cherry-pick all the commits he reverted?
09:20 < trevnorris> dude. that is a shiz load of changes you had made.
09:43 < trevnorris> indutny: had a discussion earlier w/ tjfontaine. want to know what you think.
09:43 < trevnorris> now that use of Isolates is required, need to update the docs, and users need access to node_isolate.
09:43 < trevnorris> I was thinking they could just "Isolate* isolate = Isolate::Current();" since node only uses one
09:43 < trevnorris> or just expose node::node_isolate.
09:44 <@indutny> both could work
09:44 < trevnorris> tjfontaine was thinking "node::GetIsolate()"
09:44 <@indutny> but Isolate::Current() is a little bit slower
09:44 <@indutny> well
09:44 <@indutny> not a little bit
09:45 < trevnorris> also, not sure when this happened, but you're supposed to adjust AdjustAmountOfExternalAllocatedMemory from the isolate now.
09:46 < trevnorris> ok. so tjfontaine was thinking basically "Isolate* node::GetIsolate() { return node::node_isolate; }"
09:46 < trevnorris> that worth it, or just expose the static
09:47 <@indutny> yep
09:47 <@indutny> better function
09:47 <@indutny> so we can change it later
09:47 <@indutny> without breaking changes
09:48 < trevnorris> cool. i'll throw that in along w/ doc changes.
09:48 <@indutny> ok
09:49 < trevnorris> then need to go through and update everything that can accept an isolate (have only done the ones that threw deprecation warnings)
09:53 < trevnorris> indutny: will I need to use NODE_EXTERN in the declaration?
09:55 <@indutny> I guess so
10:08 < wolfeidau> Has anyone had any luck working out why dtrace is having issues in 0.10 ? 
10:08 <@indutny> huh?
10:08 <@indutny> wolfeidau: what issues?
10:10 < wolfeidau> indutny: Not resolving function names when you use jstat from on a running process, works when the process is spawned by dtrace
10:10 <@indutny> oh
10:11 < wolfeidau> indutny: Just resolves addresses :(
10:11 <@indutny> that's pretty odd
10:11 <@indutny> I use dtrace almost every day
10:11 <@indutny> haven't seen this problem yet
10:11 <@indutny> are you on smartos?
10:11 < wolfeidau> indutny: Yeah latest smartos with 0.10 compiled with dtrace enabled
10:12 < wolfeidau> indutny: I have a gist which illustrates the issue
10:12 <@indutny> ok
10:12 <@indutny> x64 or x86?
10:12 < wolfeidau> https://gist.github.com/wolfeidau/5141024
10:12 <@indutny> err
10:12 <@indutny> 64 or 32bits
10:12 < wolfeidau> 64 bit
10:12 < wolfeidau> I am running in vmware fusion on oSX
10:12 <@indutny> interesting
10:13 <@indutny> what if you'll try 32bit process?
10:13 < wolfeidau> indutny: Do i need to recompile node?
10:13 <@indutny> yes
10:13 < wolfeidau> CFLAG ?
10:13 < LOUDBOT> THINK OF THE ENVIRONMENT BEFORE YOU PRINT THIS CHAT LOG
10:13 <@indutny> its pretty odd that this is happening
10:13 <@indutny> I bet its something with dtrace in your smartos version
10:13 <@indutny> have you tried asking at #smartos?
10:14 <@indutny> or #dtrace
10:14 < wolfeidau> indutny: Could be, yeah didn't get much response
10:14 <@indutny> ah, well
10:15 < wolfeidau> It is anoying that it works when i spawn it from dtrace but not when observed, odd thing is some functions resolve 
10:16 <@indutny> odd, that I can't reproduce it
10:16 <@indutny> let me try it
10:16 <@indutny> just to be sure
10:17 < wolfeidau> indutny: I was getting it to a lesser degree on 0.8.x
10:17 <@indutny> well, its missing some functions periodically
10:17 <@indutny> but not whole stacks
10:17 <@indutny> btw, its quite odd that addresses are that short in your traces
10:18 <@indutny> 0x750c55
10:18 <@indutny>               0x752129
10:18 < wolfeidau> indutny: dtrace -V is dtrace: Sun D 1.11
10:19 < wolfeidau> and uname -a SunOS 8d27df39-18c7-4635-af06-3e6dc73dfa80 5.11 joyent_20130307T214308Z i86pc i386 i86pc Solaris
10:19 < wolfeidau> indutny: I should open a ticket ?
10:20 < wolfeidau> indutny: Very interesting what you say about the addresses
10:20 < wolfeidau> indutny: What should they look like? 
10:23 <@indutny> it looks like 32bit address
10:24 < wolfeidau> indutny: Getting this message as well dtrace: 1 jstack()/ustack() string table overflow
10:24 <@indutny> but it might be just v8's ASLR
10:24 <@indutny> well
10:24 <@indutny> usually they're bigger
10:24 <@indutny> like this 0x1b69ee10618e
10:24 < wolfeidau> aha
10:25 < wolfeidau> indutny: Yeah some traces I get no stacks others i get some
10:26 < wolfeidau> indutny: Sorry no names vs names
10:26 <@indutny> ok
10:26 <@indutny> brb
11:13 -!- mode/#libuv [+o piscisaureus_] by ChanServ
13:56 < creationix> Interesting naming evolution.  setImmediate() executes "after the browser has completed other operations such as events and display updates" while nextTick() executes immediately as soon as the current stack unwinds
13:56 < creationix> but I see node has chosen to implement setImmediate the same way as the browser definition
14:31 -!- mode/#libuv [+o piscisaureus_] by ChanServ
14:38 -!- mode/#libuv [+o piscisaureus_] by ChanServ
15:23 <@isaacs> good morning
15:23 <@isaacs> call in 0:37
15:24 <@indutny> oooh
15:24 <@indutny> call
15:24 <@indutny> isaacs: what do you think about dual stack for tcp
15:24 <@indutny> and making dns.lookup return ipv6 address by default
15:25 <@indutny> (which is how it should be)
15:25 <@indutny> (and it's another way now, because we're reordering getaddrinfo() results)
15:27  * bnoordhuis will be there
15:27 <@indutny> hehe
15:27 <@indutny> isaacs seems to be a little bit away
15:27 <@indutny> isaacs: actually, I've working implementation
15:27 <@indutny> but bnoordhuis thinks that I must get approval from you first
15:27 <@indutny> bnoordhuis: right?
15:28 <@isaacs> hm.  i have no thoughts right away on this.
15:28 < bnoordhuis> not quite. i don't really care one way or the other
15:28 <@isaacs> what would be the effect?
15:28 < bnoordhuis> so i'll let others make the decision
15:29 <@indutny> isaacs: we would be RFC-compatible
15:29 <@indutny> and http.get({ host: 'google.com' })
15:29 <@indutny> will use ipv6 on machines that support it
15:29 <@indutny> also
15:29 <@indutny> http.createServer().listen(3000) would listen on both ipv6 and ipv4 interfaces
15:29 <@isaacs> sounds nice.
15:29 <@indutny> something like this
15:29 <@isaacs> certainly not in 0.10
15:29 <@indutny> yeah, I know
15:37 < saghul> indutny did you plan a way to override it? many people use IPv6 through tunnels so it's a lot slower than v4
15:37 <@indutny> not really
15:37 <@indutny> good point
15:37 <@indutny> I think you can always do dns.lookup(host, 4)
15:37 <@indutny> and use ip directly
15:38 <@indutny> like you should do now with ipv6
15:38 <@indutny> but now we're violating RFC
15:38 <@indutny> and you need a hack to make it work like its specified in spec
15:38 <@indutny> after this commit it'll be in other way around
15:38 <@indutny> https://github.com/indutny/node/compare/feature-dualstack
15:38 <@indutny> isaacs: ^
15:38 < saghul> I know, but RFCs are not like the ten commandments ;-)
15:38 < bnoordhuis> rfcs, smerfcs
15:38 < bnoordhuis> exactly
15:39 <@indutny> well, so what? :)
15:40 <@indutny> this is about being good internet citizens
15:40 <@indutny> my opinion ^
15:41 < saghul> sure, I'm all in for that, I was just pointing out an issue I've seen. IIRC apt can't be told to use IPv4 and I don't want to dist-upgrade through a tunnel
15:41 < saghul> as an example
15:43 < saghul> indutny btw, if you are relying on getaddrinfo and RFC compliance: http://daniel.haxx.se/blog/2012/01/03/getaddrinfo-with-round-robin-dns-and-happy-eyeballs/
15:54 <@indutny> saghul: happy eyeballs :)
15:54 <@indutny> well, we're using getaddrinfo() anyway
15:54 < bnoordhuis> people have in the past suggested node should use the happy eyeballs approach
15:55 < bnoordhuis> i say 'suggested' but 'demanded' is closer to the truth
15:55 <@indutny> well, I'm not ok with x2 fds
15:55 <@indutny> and network pressure
15:55 < bnoordhuis> of course, that gave me a legimitate reason to put them down in no uncertain terms >:-)
15:55 < bnoordhuis> *legitimate
15:55 <@indutny> haha
15:56 < bnoordhuis> typing fast without typos on a macbook keyboard is quite the challenge
15:57 <@indutny> heh
15:57 <@indutny> tell me about that
15:57 <@indutny> I was using hp pavilion before mbp
15:57 <@indutny> with additional column of function keys
15:57 <@indutny> left to the control key
16:00 < tjfontaine> good day good folks
16:00 <@isaacs> buenas dias
16:02 <@isaacs> bnoordhuis: skype
16:02 < bnoordhuis> it's starting up
16:03 -!- mode/#libuv [+o sblom] by ChanServ
16:44 <@indutny> isaacs: piscisaureus_: bnoordhuis: so what about ipv6 first in dns.lookup?
16:45 <@indutny> we'll implement happy eyeballs, or just retry on ipv4
16:45 <@indutny> when connecting
16:45 < tjfontaine> if anything that should be a preference setting, but leaving things as they are right now
16:45 <@indutny> tjfontaine: too complex wording
16:45 <@piscisaureus_> indutny: probably leave .lookup untouched, add another api that returns all results in unfethered order?
16:45 <@indutny> for non-native
16:45 <@indutny> piscisaureus_: well, the problem is that they're using http.request
16:46 < tjfontaine> dns.preferV6 = true;
16:46 <@piscisaureus_> not preferV6 :)
16:46 < tjfontaine> hehe
16:46 <@indutny> haha
16:46 <@indutny> preferV8
16:46 <@piscisaureus_> the current mode is preferV4
16:46 <@piscisaureus_> have an option to not preferV4 but do whatever the OS does
16:46 < tjfontaine> k
16:47 <@indutny> dns.preferV4 = [true]
16:47 <@indutny> anyway
16:47 <@indutny> first half of yandex problem is dual-stack
16:47 <@indutny> and second half is http.request
16:47 <@indutny> solving one of them will not change anything
16:47 <@indutny> for them
16:48 < saghul> it may also be good to add a way to shuffle the results
16:49 <@indutny> like they're now?
16:50 < saghul> I don't know how they are now :-) but if they are yes, there should be a way to get them shuffled
16:50 <@indutny> haha
16:50 <@indutny> oh gosh :)
16:50 <@indutny> so anyway
16:50 < saghul> you opened the can of worms ;-)
16:50 <@indutny> piscisaureus_: can you help me with getting dual-stack API work on windows?
16:51 <@indutny> https://github.com/joyent/libuv/pull/749
16:51 <@indutny> piscisaureus_: ^
16:51 <@indutny> bnoordhuis: what do you think about API?
16:51 <@indutny> should it be dual-stack by default or no?
16:51 <@sblom> isaacs: To double check, did your "I'll look at these two pull requests today" include my unit tests PR or am I cleared to land?
16:51 < bnoordhuis> indutny: node or libuv?
16:51 <@piscisaureus_> indutny: the trick is to use setsockopt to set IPV6_V6ONLY to 0
16:51 <@indutny> bnoordhuis: both
16:51 <@piscisaureus_> then it will enable dualstack
16:51 <@isaacs> sblom: oh, right.  yeah, that lgtm
16:51 <@isaacs> sblom: go for it
16:52 <@indutny> piscisaureus_: so its the same as on unixes?
16:52 <@piscisaureus_> indutny yes, although on unix v6only is default off
16:52 <@piscisaureus_> so you should not need to set anything
16:52 <@indutny> piscisaureus_: erm...
16:52 <@piscisaureus_> I have to run,
16:52 <@indutny> piscisaureus_: so its dual stack on windows now?
16:52 < bnoordhuis> it depends
16:52 <@indutny> bnoordhuis: exactly
16:53 <@piscisaureus_> indutny: you can look at udp.c to see how it's done
16:53 <@piscisaureus_> it's the same for tcp
16:53 < MI6> joyent/node: Scott Blomquist master * a05f973 : test: Misc Windows unit test fixes  Fixes #5071, #5073.  * Normalize capi - http://git.io/TuSBWQ
16:53 <@indutny> ahha
16:53 <@indutny> thanks
16:53 <@piscisaureus_> indutny: but be aware that that function call will always fail on xp (even if ipv6 itself is supported, since 2k3/xp don't support dualstack)
16:53 < bnoordhuis> with the current api, i guess it should default to off iff we pick a default for libuv
16:53 <@indutny> bnoordhuis: signatures will change anyway
16:53 < bnoordhuis> but really, libuv leaves it to the os now and no one is complaining
16:54 <@indutny> so people who're using tcp_bind will need to change their calls
16:54 <@indutny> yeah
16:54 <@indutny> bnoordhuis: what do you think about unix part of my PR?
16:54 < bnoordhuis> well... i don't like that it changes the api/abi
16:54 <@indutny> bnoordhuis: should I use uv_tcp_t->flags?
16:55 < bnoordhuis> i guess i'd opt for a uv_tcp_set_dualstack(uv_tcp_t* handle, int enable) function
16:56 < bnoordhuis> but i haven't thought deeply about it yet :)
16:56 <@indutny> erm
16:56 <@indutny> well
16:56 <@indutny> gosh
16:56 <@indutny> ok
16:56 <@indutny> ah wait no
16:56 <@indutny> it won't work out
16:56 < bnoordhuis> that's what she said
16:56 <@indutny> we need to explicitely enable/disable dual  stack in tcp_bind anyway
16:57 <@indutny> so we'll need to store this flag somewhere
16:57 < bnoordhuis> but she's been living happily in my cellar for the last 20 years now
16:57 < bnoordhuis> for certain definitions of 'happily'
16:57 <@indutny> bnoordhuis: dutch slavery
16:57 < bnoordhuis> it's in the genes. c.f. the 17th century
16:57 < bnoordhuis> what we call our golden age here
16:58 < bnoordhuis> spices and slaves, it's what made us rich
16:58 < bnoordhuis> okay, back on topic
16:58 < bnoordhuis> why won't it work?
16:59 <@indutny> because default behaviour varies
16:59 <@indutny> and setsockopt must be called anyway
16:59 <@indutny> either during init
17:00 <@indutny> and set to, lets say, 0
17:00 <@indutny> or right before bind
17:00 <@indutny> if it looks good to you - then ok
17:00 <@indutny> latter one requires additional field in uv_tcp_s
17:00 <@indutny> for storing status
17:00 < bnoordhuis> status?
17:00 <@indutny> former one requires additional call
17:00 <@indutny> status = dual stack enabled/disabled
17:01 < bnoordhuis> you can use the flags field for that
17:01 <@indutny> ah, ok then
17:02 <@indutny> so uv_tcp_set_dualstack(uv_tcp_t*, int enable), right?
17:02 < bnoordhuis> something like thaat
17:02 < bnoordhuis> *that
17:02 < bnoordhuis> macbook keyboards...
17:02 < bnoordhuis> piscisaureus_: thoughts?
17:02 <@indutny> ok
17:02 <@indutny> I'll fix it in PR
17:02 < tjfontaine> isaacs (and anyone else interested) https://github.com/tjfontaine/chrome-nodeci add that with developer mode enabled, and go to options to add your username and api key
17:02 < tjfontaine> bnoordhuis: you scared him away
17:08 <@isaacs> tjfontaine: how do i install this in chrome?
17:08 < tjfontaine> isaacs: enable developer mode, then add and browse to where you checked it out
17:08 < tjfontaine> "load unpacked extension"
17:09 <@isaacs> hm... how do i get my jenkins api key?
17:10 < tjfontaine> see the link?
17:10 < tjfontaine> jenkins.nodejs.org/me/configure
17:10 <@isaacs> oh, hahah
17:10 <@isaacs> k
17:12 <@isaacs> tjfontaine: THIS IS THE BEST THING EVER OMG THANK YOU
17:12 < tjfontaine> on pulls the status is a button to trigger the build
17:13 < tjfontaine> windows is not included in the pullrequest builder though, because of jenkins use of jgit and its hatred of the refspec
17:18 < MI6> nodejs-master: #101 UNSTABLE osx-x64 (1/563) windows-ia32 (5/563) windows-x64 (5/563) osx-ia32 (2/563) http://jenkins.nodejs.org/job/nodejs-master/101/
17:23 <@isaacs> tjfontaine: it looks like it only works on the first page of pulls
17:24 < tjfontaine> oh probably because of the globbing
17:24 < tjfontaine> or lack there of
17:25 < tjfontaine> isaacs: pushed a fix, pull, and then go to chrome://extensions and reload
17:28 <@isaacs> kewl
17:30 <@isaacs> tjfontaine: so, this might be a bit fiddly, but it'd be awesome if the jenkins bot could post a comment like "Needs tests" if there's a change to {src,lib}/* and no change to test/*
17:31 < tjfontaine> isaacs: sure, I wasn't sure how chatty we wanted things to get, especially considering our adverse reaction to the last thing we had :)
17:32 <@indutny> god damn it
17:32 <@indutny> this is awesome
17:32 <@indutny> what if I'll click the button?
17:32 <@indutny> will it start building?
17:32 <@indutny> should I click only once
17:32 <@indutny> or can I click multiple times :)
17:33 < tjfontaine> indutny: if you don't have your jenkins key nothing will happen, you can click multiple times on the /pulls page and it will queue that job up a bunch :)
17:33 <@indutny> oh I see
17:33 <@indutny> it started
17:34 <@indutny> brb
17:34 < tjfontaine> I also plan on adding optional notifications so you can get the little chrome blups when builds start/finish
17:48 < tjfontaine> isaacs: https://gist.github.com/tjfontaine/623f36cebd6e3bdeec52 plopping in either a github token you already have, or using your username and password, this should update the existing webhook for libuv and node such that we will receive pull request 
17:51 <@isaacs> this is rad.
17:55 < tjfontaine> https://github.com/tjfontaine/jankins is the other piece to this puzzle, which sits on the backend
17:57 < tjfontaine> https://github.com/tjfontaine/jankins/blob/master/jankins.js#L45-47 it doesn't get any easier than that :)
18:35 < bnoordhuis> https://gist.github.com/bnoordhuis/5192966 <- js/c++ backtrace, now with filenames and line/column numbers
18:36 < bnoordhuis> the only thing left is decoding js arguments
18:37 < bnoordhuis> and maybe correlating dwarf debug info to c++ stack frames
18:38 < tjfontaine> heh
18:57 < sblom> Looks like the IRC logger is disconnected again. How does it work? Who should I ping?
18:57 < trevnorris> bnoordhuis: so you don't think a node::GetIsolate() is necessary? Just document for users to use Isolate::GetCurrent()?
18:57 < sblom> (Specifically, logs.libuv.org/libuv/latest looks 6 or 7 hours old, if my time zone math is right.)
19:01 < tjfontaine> trevnorris: his stance is to just use v8::Isolate::GetCurrent as I read it
19:01 < tjfontaine> sblom: [03-19] 08:44:43 -!- slurp [~nodebot@37.153.97.9] has quit [Ping timeout: 245 seconds]
19:01 < tjfontaine> sblom: bert or isaacs can fix it
19:03 -!- mode/#libuv [+o sblom] by ChanServ
19:03 < trevnorris> tjfontaine: cool
19:12 < MI6> joyent/node: Bert Belder v0.10 * 8019800 : Update .mailmap and AUTHORS - http://git.io/Fw_2wg
19:12 -!- mode/#libuv [+o piscisaureus_] by ChanServ
19:12 < bnoordhuis> trevnorris: yes
19:12 <@piscisaureus_> AAAAH
19:12 <@piscisaureus_> slurp is dead
19:12 < trevnorris> righty. then that will just require an update to the docs. will do.
19:13 <@piscisaureus_> test
19:25 <@isaacs> bnoordhuis: neato
19:26 <@isaacs> bnoordhuis: so it's sort of like the mdb ::jsstack and ::jsprint stuff, but in your program?
19:27 <@isaacs> tjfontaine: you in sf today?
19:31 < trevnorris> you guys think there should be a note in the addon docs about the isolate change, or are updated examples enough?
19:49 <@indutny> hoya
20:03 < tjfontaine> isaacs: yes :)
20:08 < trevnorris> bnoordhuis: so basically just replace the "extern Isolate..." with "Isolate.. GetCurrent" in object_wrap?
20:10 < tjfontaine> well within the node api seems like it should use the static
20:10 < tjfontaine> but for what people consume externally (addins) should use the GetCurrent, at least that's what I assume
20:17 < trevnorris> ok. so that means I should still use "extern v8::Isolate* node_isolate;" inside each function that needs it?
20:18 < tjfontaine> no, only once at the top of the file?
20:18 < tjfontaine> maybe c++ scoping is different in this regard
20:20 < trevnorris> tjfontaine: the build fails violently when I do that with a bunch of "src/node_buffer.cc:(.text._ZN4node[...]v]+0x1a): undefined reference..."
20:20 < trevnorris> well, at least i'm feeling violent towards it =P
20:20 < tjfontaine> is this code up somewhere?
20:21 < tjfontaine> or just what you have in your  WIP
20:21 < trevnorris> it's in pr 5077
20:21 < trevnorris> i'm in the middle of a rebase right now, so not completely up-to-date
20:22 < trevnorris> ugh. and fucking github shows the commits out of order when you cherry-pick a commit, then rebase later.
20:23 < trevnorris> tjfontaine: specifically it's this one: http://git.io/5gprFw
20:24 < tjfontaine> trevnorris: if there's not a `using namespace node` or within a `namespace node {}` you'll need to qualify node::node_isolate
20:24 < tjfontaine> hmm it is in a namespace
20:24 < tjfontaine> ugh code in headers, how unpleasant
20:25 < tjfontaine> trevnorris: if you put your extern on line 39?
20:26 < trevnorris> yeah. just tried that. that works.
20:26 < tjfontaine> ok, so do you see why it does work?
20:26 < tjfontaine> vs what you were doing before?
20:27 < trevnorris> i understand namespacing, but not extern.
20:27 < trevnorris> also do we just not worry that users can access it from node.h via "node::node_isolate"?
20:28 < tjfontaine> I mentioned during the call today that we should really have a discussion about what is and isn't going to be a public api for addins
20:29 < trevnorris> sounds good to me.
20:29 < trevnorris> then would we need to do something similar to how v8 namespaced everything off limits in v8::internal?
20:29 < tjfontaine> trevnorris: suffice it to say there are ways to protect/hide it if that's what is wanted
20:29 < trevnorris> ok
20:43 <@piscisaureus_> tjfontaine hey
20:43 < tjfontaine> hey
20:43 <@piscisaureus_> tjfontaine: did you test your nanosecond timer patch on windows?
20:43 <@piscisaureus_> er, *nanosecond stat
20:44 < tjfontaine> yes, but I might have done it wrong?
20:44 <@piscisaureus_> no
20:44 <@piscisaureus_> I had one comment. Otherwise LGTM
20:44 < tjfontaine> ok, when I was doing it the 100s of nanoseconds thing was bothering my head
20:44 < tjfontaine> I was so used to having to / switching around to a * freaked me out :)
20:45 <@piscisaureus_> yes, multiplying by 100 was they way to go :)
20:45 <@piscisaureus_> The only comment I have is that you need to wrap ts in braces, e.g. so make it (ts)
20:45 <@piscisaureus_> because this is a macro
20:45 < tjfontaine> nod
20:45 <@piscisaureus_> After that you can land (if you have commit bits) or I can do it.
20:46 < tjfontaine> you'll have to do it
20:46 <@piscisaureus_> That is - if bnoordhuis signed off the unix parts (it seems he did)
20:48 < tjfontaine> ok I pushed with the update macro
20:53 < MI6> joyent/libuv: Timothy J Fontaine master * 499c797 : unix, windows: nanosecond resolution for uv_fs_[fl]stat  Closes #739. - http://git.io/LEUp3w
20:54 <@piscisaureus_> ^-- tjfontaine: landed
20:54 <@piscisaureus_> thanks!
20:54 < tjfontaine> piscisaureus_: no no, thank you! :)
20:54 <@piscisaureus_> no no, thank you!
20:54 <@piscisaureus_> The fact that I'm slow to review doesn't mean that I don't love it when people improve libuv
20:55 < tjfontaine> so long as that's what I did :)
20:55 < trevnorris> tjfontaine: so is there a way for me to kick off a sunos build on jenkins? in a few should have a fix for the dtrace thing.
20:55 < tjfontaine> trevnorris: have you pushed to your WIP?
20:56 < trevnorris> yeah. but it will fail. was a dumb ass and added my full path to one of the error .out files.
20:56 < trevnorris> so i'm fixing that now.
20:56 < tjfontaine> heh ok
21:02 <@isaacs> did we stop installing header files with `make install`?
21:02 <@indutny> I don't think so
21:03 <@indutny> I'm using multiple installations
21:03 <@isaacs> i didn't either...
21:03 <@indutny> and every works just fine
21:04 <@isaacs> huh.  looks like we don't have them in the downloaded binaries.
21:05 <@indutny> oh gosh
21:05 <@isaacs> $ la x/usr/local/
21:05 <@isaacs> bin/   lib/   share/
21:05 <@isaacs> yep.  we're not installing them
21:05 <@isaacs> that's a bug
21:06 <@isaacs> hard to build addons without node.h!
21:06 <@isaacs> ohhh... wait.
21:06 < tjfontaine> node-gyp solves that
21:06 <@isaacs> no, we have node-gyp doing that.
21:06 < tjfontaine> "solves"
21:06 <@isaacs> right
21:18 < MI6> joyent/libuv: indutny created branch feature-tcp-dualstack - http://git.io/GuxM2Q
21:20 <@indutny> oops
21:20 <@indutny> gosh
21:21 <@indutny> ircretary: tell bnoordhuis about https://github.com/joyent/libuv/pull/749
21:21 < ircretary> indutny: I'll be sure to tell bnoordhuis
21:32 < trevnorris> tjfontaine: pr 5077 is ready for sunos build test
21:33 <@indutny> isaacs: so https://github.com/joyent/libuv/pull/749
21:33 <@indutny> isaacs: and https://github.com/joyent/node/pull/5087
21:33 <@indutny> you can try it out on your pc
21:33 <@indutny> and see how well it works for you ;)
21:33 <@indutny> also, as you can see I've almost not touched any test
22:11 < bnoordhuis> indutny: you don't need to have ircretary remind me of your PRs, i get github emails :)
22:14 < trevnorris> as part of the 3.17 updated i'm committing a change that adds node_isolate to all supported methods.
22:14 < trevnorris> only a few hundered additions so far =P
22:19 < bnoordhuis> trevnorris: there's a commit in the history that does that
22:20 < trevnorris> really?
22:20  * trevnorris goes looking...
22:20 < bnoordhuis> trevnorris: git show 51f6e6a | git apply -R probably
22:20 <@indutny> bnoordhuis: I like annoying you
22:20 <@indutny> through all possible ways
22:20 <@indutny> sad that you don't have jabber account
22:21 <@indutny> at least, I don't know it
22:21 < bnoordhuis> i don't get annoyed easily. i have kids
22:21 < bnoordhuis> not to mention a liberal arts wife
22:22 < trevnorris> bnoordhuis: that has a lot of em. but missing all the "HandleScope scope(node_isolate);" changes.
22:22 < MI6> joyent/libuv: Brian Mazza v0.10 * 77cb29a : unix: make uv_timer_init() initialize repeat  uv_timer_get_repeat() shoul - http://git.io/90Wxjg
22:22 < trevnorris> also the "Local<*>::New(isolate"
22:23 < trevnorris> wait. scratch that last one
22:24 < trevnorris> bnoordhuis: thanks. that saved me a lot of work.
22:24 < bnoordhuis> np
22:31 < tjfontaine> well jankins seems to be pretty good at destroying jenins in someway
22:38 < trevnorris> i love the whole automated building thing, but haven't found it extremely intuitive to navigate.
22:39 < tjfontaine> jenkins is pretty much like democracy in that regard
22:39 < tjfontaine> it sucks, but better than everything else
22:39 < trevnorris> lol
22:43 < bnoordhuis> piscisaureus_: you should schedule a day or two review PRs, there's a ton that are waiting for review by a windows programmer
22:43 < bnoordhuis> *to review
22:43 <@piscisaureus_> bnoordhuis: I was actually planning to
22:43 < bnoordhuis> okay, good
23:00 <@isaacs> piscisaureus_, bnoordhuis: What's the status of uv_cork/uncork?
23:00 < bnoordhuis> isaacs: i have the writev stuff working however...
23:00 < bnoordhuis> it speeds up some benchmarks by 5% and decimates others :/
23:01 < tjfontaine> trevnorris: dtrace: failed to compile script src/v8ustack.d: line 228: failed to resolve V8DBG_SMISHIFTSIZE: Unknown variable name (http://jenkins.nodejs.org/job/node-pullrequest/74/DESTCPU=x64,label=smartos/console)
23:01 < tjfontaine> trevnorris: that's a familiar error as well
23:01 < bnoordhuis> isaacs: related: https://github.com/joyent/libuv/issues/746
23:01 <@isaacs> yeah, i see that
23:02 < bnoordhuis> tl;dr needs further investigation
23:04 < MI6> libuv-master: #57 UNSTABLE osx (2/183) smartos (5/183) windows (5/184) linux (3/183) http://jenkins.nodejs.org/job/libuv-master/57/
23:10 < trevnorris> tjfontaine: =P
23:11 < trevnorris> tjfontaine: why is that error only showing up on sunos?
23:11 < tjfontaine> trevnorris: because that's the only place dtrace ustack is enabled?
23:11 < trevnorris> hm. don't know anything about dtrace. wonder if I can enable it on linux...
23:12 < tjfontaine> trevnorris: indutny should know the solution for this one, I'm pretty sure we hit it before
23:12 < trevnorris> indutny: ^
23:12 <@indutny> trevnorris: no way
23:12 <@indutny> there's dtrace4linux
23:12 <@indutny> but
23:12 <@indutny> no ustack helpers
23:12 < trevnorris> bummer. ok
23:12 < bnoordhuis> don't forget about oracle's unbreakable linux!
23:12 < tjfontaine> there's also systemtap
23:13 < tjfontaine> bnoordhuis: has fooled around with that
23:13 < bnoordhuis> yes. stap is still rather hit and miss
23:13 < bnoordhuis> you'll need a recent kernel and a recent version of the tools
23:14 < bnoordhuis> or install fedora 18, it just works there
23:14 < bnoordhuis> no surprise, of course - the stap guy works for red hat
23:14  * bnoordhuis stops rambling
23:17 <@indutny> it works on fedora?
23:17 <@indutny> ustack helper?
23:18 < bnoordhuis> the systemtap equivalent of it yes
23:18 < trevnorris> bnoordhuis: is "Local<Value>::New(node_isolate, Undefined(node_isolate));" overkill? i see Undefined() w/ and w/o out it
23:19 < bnoordhuis> trevnorris: that's probably because the patch doesn't apply 100% anymore
23:19 < bnoordhuis> Undefined(node_isolate) is preferred
23:20 < trevnorris> yeah. been resolving conflicts. but still way simpler than making all those changes again...
23:20 < trevnorris> you must have some mad sed skillz
23:20 < bnoordhuis> trevnorris: git apply -R -C0 and inspect the diff very carefully afterwards :)
23:20 < tjfontaine> haha
23:32 < MI6> joyent/node: Bert Belder v0.10 * bf83251 : windows: enable watching signals with process.on('SIGXYZ')  This reverts  - http://git.io/QeyYhg
23:39 < bnoordhuis> piscisaureus_: -Timothy J Fontaine <tjfontaine@gmail.com> <- ?
23:39 <@piscisaureus_> bnoordhuis: duplicate
23:39 < bnoordhuis> oh
23:39 < MI6> joyent/node: Iskren Ivov Chernev v0.10 * 2f4a62c : doc: fix streams2 SimpleProtocol example  A non-existing variable `b` was - http://git.io/MtdFMg
23:40 <@piscisaureus_> I tested some libuv release tooling on the node authors and mailmap and this what came out of it :)
23:52 < trevnorris> finally. all entries replaced.
23:52 < trevnorris> bnoordhuis: http://git.io/KaydwQ
23:54 < trevnorris> sob. forgot a few...
--- Log closed Wed Mar 20 00:00:47 2013