00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:09  * hzquit
00:03:17  <sh1mmer>you know eran right?
00:03:22  <sh1mmer>he's the lead on that
00:05:15  <bnoordhuis>yeah. we clash time from time to time on the bug tracker :)
00:05:40  <sh1mmer>heh
00:11:27  <bnoordhuis>cjd: re that license fixer thingy, i infer you're not a fan of liberal licenses?
00:11:43  <cjd>hah
00:11:54  <sh1mmer>cid you wrote that?
00:11:57  <cjd>every license has it's place
00:12:00  <sh1mmer>the pl script on HN?
00:12:02  <cjd>yeah
00:12:15  <sh1mmer>I have a few half-finished things in that vein
00:12:17  <sh1mmer>it made me happy
00:12:25  <cjd>thx
00:12:38  <cjd>it was a way to poke fun at the BSD/GPL argument
00:12:41  <sh1mmer>GPL is becoming toxic because it's obvious (in the real world) how much corporate supports open source
00:13:02  <cjd>sort of
00:13:05  * defunctzombiechanged nick to defunctzombie_zz
00:13:51  <cjd>if you GPL a project, you hold it back somewhat but you also protect it from getting crap dumped on it until it's enormous bloatware
00:14:05  <sh1mmer>governance I think is a separate issue
00:14:35  <sh1mmer>I like the Node approach
00:14:39  <cjd>and if you have companies committing to your project who are usually at eachother's throats (think Oracle, RedHat and IBM), it's a way to demilitarize the area
00:15:07  <bnoordhuis>cjd: crap dumped on? that's up to the maintainers right?
00:15:55  <sh1mmer>I would say Hadoop became a war zone
00:15:59  <cjd>yeah but when it's really awesome cool crap, it's hard for the maintainers to resist :)
00:16:10  <sh1mmer>Apache Hadoop is a train-wreck and everyone has their own pet distro now
00:16:15  <bnoordhuis>ah, you mean pushovers
00:16:23  <cjd>well no
00:16:32  <sh1mmer>corporate money can be a problem
00:16:38  <sh1mmer>I met that a lot in standards work
00:16:56  <cjd>it's really really hard to say "no" to some cool features because you "don't want to maintain the code"
00:17:01  <sh1mmer>Where the people writing the standards (and getting paid to do so) got forced into pushing a corporate line
00:17:17  <bnoordhuis>i never have a problem with that
00:17:49  <bnoordhuis>i use myself as the measure of things. if i'm unlikely to use it now or in the future, i don't merge it
00:18:14  <cjd>I did a quick check of find/wc line counts in linux repo and freebsd.. 14 million and 27 million
00:18:28  <cjd>it's hard to turn features down
00:18:59  <bnoordhuis>er, the freebsd repo includes the user land
00:19:22  <bnoordhuis>unless you only counted files in sys/
00:19:40  <cjd>nope, I counted everything because IMO that's what the freebsd guys have to maintain
00:20:26  <cjd>kernel space is a huge line in the sand, even glibc is not linux, "mean" licenses help enforce those lines
00:20:34  <cjd>so do "mean" project managers :)
00:21:16  <bnoordhuis>nah, bollocks. it's people, not licenses
00:21:45  <bnoordhuis>and freebsd is a bad example because developing the kernel and user land together is what their philosophy is all about
00:22:40  <cjd>anyway I'm glad libuv has a liberal license so that cjdns can be GPLv3 :)
00:24:16  <sh1mmer>lol
00:34:56  * bradleymeckjoined
00:36:23  * `3rdEdenjoined
00:40:56  * `3rdEdenquit (Ping timeout: 246 seconds)
00:48:39  * bradleymeckquit (Quit: bradleymeck)
00:49:14  * defunctzombie_zzchanged nick to defunctzombie
00:49:54  * c4miloquit (Remote host closed the connection)
00:52:47  * bradleymeckjoined
00:55:42  * defunctzombiechanged nick to defunctzombie_zz
01:10:42  * perezdjoined
01:16:05  * c4milojoined
01:39:04  * porcojoined
01:43:19  * abraxasjoined
01:43:20  * qmx|awaychanged nick to qmx
01:58:22  * bnoordhuisquit (Ping timeout: 245 seconds)
02:05:35  * defunctzombie_zzchanged nick to defunctzombie
02:11:09  * loladiroquit (Quit: loladiro)
02:15:16  * defunctzombiechanged nick to defunctzombie_zz
02:23:30  * loladirojoined
02:26:58  * porcoquit (Quit: Linkinus - http://linkinus.com)
02:32:19  * qmxchanged nick to qmx|away
02:32:31  * sh1mmerquit (Quit: sh1mmer)
02:36:38  * loladiroquit (Quit: loladiro)
02:43:35  * kazuponjoined
02:44:05  * kazuponquit (Remote host closed the connection)
02:44:14  * kazuponjoined
02:50:55  * benoitcquit (Excess Flood)
02:54:54  * benoitcjoined
02:58:12  * abrahmquit (Quit: Leaving)
03:00:08  * abraxasquit (Remote host closed the connection)
03:05:02  * bnoordhuisjoined
03:07:33  * benoitcquit (Excess Flood)
03:10:06  * bnoordhuisquit (Ping timeout: 276 seconds)
03:12:42  <trevnorris>tjfontaine: maybe you can help me out. don't have any experience w/ sunos or dtrace.
03:13:28  <tjfontaine>right, well
03:13:39  <trevnorris>tjfontaine: failure is because V8DBG_CLASS_SEQASCIISTRING__CHARS__CHAR is an unknown variable name. but it's in v8abbr.h, which is included in uv8ustack.c
03:13:40  <tjfontaine>lemme look at that again
03:13:50  <tjfontaine>oh right ok
03:14:14  <tjfontaine>I think this was an issue before, but I'm not sure that it was solved
03:15:27  <trevnorris>hm ok
03:15:47  <trevnorris>i'll look back through the commit logs and see if there was something I missed.
03:16:06  <trevnorris>because when I cherry-pick the commit that should be the fix, there are no changes.
03:16:20  <tjfontaine>well lemme rephrase
03:16:24  * benoitcjoined
03:17:22  <tjfontaine>right before the v8 rollback, I was asked to check to see if the postmortem stuff was working, and indeed it wasn't, for a quite similar error
03:17:35  <trevnorris>ah, ok.
03:17:36  <tjfontaine>but iirc we were on 3.16 then?
03:17:43  <trevnorris>3.15
03:18:06  <trevnorris>we tried 3.16 but that had a serious ascii regression that has been mostly solved in 3.17
03:18:16  <tjfontaine>ok well anyway, the SEQASCIISTRING stuff was involved in the error for postmortem stuff
03:18:28  <trevnorris>ah, ok. so it was never working?
03:18:46  <tjfontaine>well, ustack != postmortem
03:19:10  <tjfontaine>they're related but not entirely the same thing
03:19:33  <tjfontaine>I'll need to actually look and see what's going on with this
03:19:59  <trevnorris>hm
03:22:48  <tjfontaine>in gen-postmortem-metadata.py for instance is: SeqAsciiString, chars, char, kHeaderSize
03:23:54  <tjfontaine>so while this header jazz isn't entirely obvious, I have a feeling it's supposed to be generating that define, and since that doesn't exist anymore in v8 it's not getting defined
03:24:08  <trevnorris>ah, ok
03:24:12  * mikealjoined
03:24:52  * mikealquit (Client Quit)
03:25:15  <trevnorris>well, sort of. to be honest don't even know how to use dtrace.
03:25:25  <tjfontaine>ok see for instance out/Debug/obj/gen/debug-support.cc
03:27:51  * mikealjoined
03:30:23  * kazuponquit (Remote host closed the connection)
03:32:51  <tjfontaine>ok right
03:34:02  <tjfontaine>see also tools/genv8constants.py
03:35:59  <tjfontaine>so V8DBG_CLASS_SEQASCIISTRING__CHARS__CHAR is supposed to be in v8constants.h
03:36:52  <trevnorris>ah ok
03:37:09  <tjfontaine>and that's generated by walking through the things defined in libv8_base.a
03:38:38  <tjfontaine>I will be able to find out more tomorrow, about whether or not simply removing the line from v8abbr is enough, or if there are now other symbols we need to use
03:40:37  <trevnorris>cool. thanks a ton.
03:41:00  <tjfontaine>my pleasure, was the build report from jenkins helpful?
03:41:34  <trevnorris>tjfontaine: very. just being able to see the build output was very useful.
03:41:54  <tjfontaine>excellent
03:42:33  <trevnorris>do you do all the builds with g++?
03:42:37  <tjfontaine>I will probably be letting the pullreq chrome plugin into the wild tomorrow for some feedback, though I dunno if you use FF all things considered
03:43:00  <trevnorris>heh, I work at mozilla. ;-)
03:43:34  <tjfontaine>well windows is msvs, osx is clang, linux and smartos are gcc/g++ right now, though I would like to get clang into the mix there as well
03:43:37  <tjfontaine>right :)
03:44:00  <tjfontaine>it's really just a simple greasemonkey/userscript thing, so trivial for a motivated person to implement there as well
03:44:10  <trevnorris>yeah. there was one edge case where building ia32 with clang exposed a bug in clang.
03:44:19  <trevnorris>though i'd expect that shouldn't happen hardly ever.
03:44:38  <trevnorris>(if ever again)
03:44:41  <tjfontaine>right
03:45:28  <tjfontaine>I've been a huge llvm/clang for a while, I was in the small group who took the time to figure out how to get v8 to compile with it :)
03:45:53  <tjfontaine>back before the c++ compiler was round tripping
03:46:44  <trevnorris>that's awesome.
03:49:31  <trevnorris>so did you work google?
03:50:08  <tjfontaine>nah
03:50:17  <tjfontaine>just an enthusiast
03:53:01  * defunctzombie_zzchanged nick to defunctzombie
03:53:20  <brucem>trevnorris: if you feel that way about clang and work at Mozilla, you obviously don' t work with Alon. :)
03:53:35  * stagas_joined
03:55:02  * perezdquit (Quit: perezd)
03:55:27  <trevnorris>brucem: heh, nope.
03:56:00  * stagasquit (Ping timeout: 258 seconds)
03:56:00  * stagas_changed nick to stagas
03:56:11  <brucem>trevnorris: between him, me and someone else (with me and someone else not @ Mozilla), we're like walking factories for LLVM-related bugs.
03:57:36  <trevnorris>brucem: considering i only started programming c++ 4 months ago, it was just luck i tripped across one (it was bnoordhuis that identified the bug) =)
03:57:48  <tjfontaine>heh, anyone with a significant code base is a factory for llvm bugs :)
04:00:47  * kazuponjoined
04:04:20  * perezdjoined
04:04:20  * perezdquit (Client Quit)
04:08:52  * kazuponquit (Ping timeout: 248 seconds)
04:11:01  * abraxasjoined
04:13:39  * kazuponjoined
04:14:56  * c4miloquit (Remote host closed the connection)
04:17:50  * kazuponquit (Remote host closed the connection)
04:19:51  * abraxasquit (Remote host closed the connection)
04:32:17  * abraxasjoined
04:42:42  * kazuponjoined
05:05:41  * bradleymeckquit (Quit: bradleymeck)
05:09:04  <tjfontaine>what everyone wants to see https://github.com/joyent/node/pull/5055#issuecomment-15039362
05:10:52  <cjd>:D
05:11:15  <cjd>need a PR closer bot which closes if tests fail
05:12:11  <tjfontaine>heh, the existing jenkins pr bot is crap, so I wrote an optin thing for the core devs who are interested
05:12:53  <tjfontaine>basically just a content script plugin that will inject PR build status and test failures onto the PR page
05:14:20  <cjd>jenkins? crap?
05:14:24  * bradleymeckjoined
05:14:36  <cjd>but but but it's java
05:15:08  <tjfontaine>I call my little proxy thing jankins to reflect that :P
05:34:20  <trevnorris>tjfontaine: what do you think about creating an official "include/node.h" the way v8 has?
05:34:55  <trevnorris>i'd like to create one with proper Doxyfile documentation, then use doxygen to build both the v8 and node api docs
05:35:56  <tjfontaine>how would it differ from src/node.h?
05:36:55  <tjfontaine>I mean node itself doesn't have a lot of entry points from C/++ so what little commenting there is would happen there?
05:36:56  <trevnorris>src/node.h would become include/node.h
05:37:01  <trevnorris>at least that is how v8 does it.
05:37:18  <tjfontaine>but it doesn't really need to move does it?
05:37:33  <tjfontaine>I think install does the right thing with it already
05:37:59  <trevnorris>well, guess it doesn't need to move, but there are a lot of nice-ities that need to all be included seperately.
05:38:47  <trevnorris>(e.g. node-internals.h has "Thow*Error", node_buffer has the Buffer interface, node_object_wrap.h has ObjectWrap, etc.)
05:38:50  <tjfontaine>for doxygen'y things I suppose you could provide yet another header that maps things
05:39:20  <trevnorris>part of it would also to have a single location for all the "official" cc interfaces.
05:39:53  <trevnorris>i think those should be under the same api locks as the js api.
05:40:38  <trevnorris>reason i thought of it was because of GH-5042
05:41:18  <tjfontaine>I'm not sure the Throw* stuff should necessarily be exposed, and it's not uncommon for projects (especially c++) to not include all the headers all the time
05:41:38  <tjfontaine>c++ being notoriously slow at the actual preprocessing step
05:42:40  <tjfontaine>trevnorris: I'm not too fussed either way, it's just important that we're aware of what we do and don't want to export to addins etc
05:42:54  <tjfontaine>something we're not so clear on
05:43:54  <trevnorris>so what about a minimum of identifying our official cc api?
05:44:24  <tjfontaine>that is something that should indeed be done
05:44:42  <tjfontaine>I would think it would go hand in hand for guidelines for writing good addins
05:44:48  <trevnorris>nod
05:45:45  <trevnorris>and i don't care whether the api is located in single or multiple files, as long as it's well documented.
05:46:01  <tjfontaine>yup that's my position as well
05:47:30  <trevnorris>tjfontaine: i'm not familiar with how cc projects break up api stuff in header files, but is it uncommon to have internal api declarations in the same headers as public apis?
05:48:09  <tjfontaine>in well behaved projects, yes that's usually not found
05:48:15  <tjfontaine>for instance look at how libuv does it
05:48:46  <tjfontaine>breaks out platform includes, and then platforms further abstract out what's public/internal
05:49:17  <trevnorris>yeah, very similar to how v8 does it.
05:50:00  <tjfontaine>now, compilers have the concept of visibility, so it's not always a problem if done carefully, but if you want to have the least amount of unintended consequences you explicitly mark what you want to let others use
05:50:29  <trevnorris>so i'll defer to all you that actually have cc experience to how break up the headers. =)
05:51:11  <tjfontaine>as it stands right now, you have cases where node itself works great with how the headers are, but then you hit the case where someone somewhere was relying on something you hadn't anticipated
05:51:19  <tjfontaine>ie #5042
05:52:20  <trevnorris>yeah
05:53:29  <tjfontaine>I'm going to be adding more downstream projects that will be built and tested after a branch build completes, that should also include a binary addin, probably at the least ffi since that probably should hit common cases
05:54:07  <trevnorris>so you think this should be a v0.12 milestone?
05:54:52  <tjfontaine>ya, well 1.0 at the latest :P
05:55:07  <trevnorris>heh
06:08:32  * wolfeidauquit (Remote host closed the connection)
06:09:58  * defunctzombiechanged nick to defunctzombie_zz
06:21:54  <trevnorris>tjfontaine: what did you mean by c++ being slow at the preprocessing step?
06:43:15  * `3rdEdenjoined
06:47:59  <tjfontaine>http://stackoverflow.com/a/318440
06:48:33  <tjfontaine>nothing out of the ordinary for compilers, it's just worse for c++
06:48:50  * stagas_joined
06:49:02  * stagasquit (Ping timeout: 252 seconds)
06:49:04  * stagas_changed nick to stagas
06:50:00  <tjfontaine>trevnorris: also of interest to you might be http://llvm.org/devmtg/2012-11/ talk #6 "Modules" by dgregor
06:50:13  <trevnorris>awesome, thanks.
06:51:52  <trevnorris>tjfontaine: in the following, would I need to replace (int*)mem with reinterpret_cast? https://gist.github.com/trevnorris/5183829
06:51:54  <cjd>also C++ is easy to bloat up
06:52:04  <trevnorris>i tried static_cast, but errors
06:52:08  * `3rdEdenquit (Ping timeout: 264 seconds)
06:52:17  <cjd>#include <boost> -> get coffee while compiling
06:53:39  <tjfontaine>trevnorris: o0 what are you trying to do with your little example there?
06:53:58  <trevnorris>write an int value directly to memory
06:57:56  <tjfontaine>ok so your question is what should your casts be in c++
06:58:48  <trevnorris>sure, or if there's a more c++ way.
07:00:11  <tjfontaine>I'm not sure if there is a more c++ way to do what you're doing there, you're being particularly evil and the c++ *_cast<> is kinda meant to protect you from that sort of them
07:00:50  <tjfontaine>http://stackoverflow.com/questions/573294/when-to-use-reinterpret-cast
07:02:00  <tjfontaine>I think with reinterpret you run the danger of it messing with addresses, but I don't remember the rules all that well
07:02:33  <tjfontaine>heh ya that's what the example suggests
07:02:35  <trevnorris>ah, that was the example my friend gave me. just left out the void* part.
07:22:15  <MI6>libuv-pullrequest: #1 FAILURE osx (2/183) smartos (5/183) linux (2/183) http://jenkins.nodejs.org/job/libuv-pullrequest/1/
07:25:52  * rendarjoined
07:26:06  * bradleymeckquit (Quit: bradleymeck)
07:36:01  * `3rdEdenjoined
07:44:59  * stagasquit (Ping timeout: 245 seconds)
07:45:05  * stagas_joined
07:50:15  * stagas_quit (Ping timeout: 276 seconds)
07:54:14  <indutny>morning
08:23:14  * loladirojoined
08:23:25  * `3rdEdenquit (Remote host closed the connection)
08:33:56  * rendarquit
08:34:39  * rendarjoined
08:36:09  * kazuponquit (Remote host closed the connection)
08:42:58  * csaohjoined
08:59:01  * kazuponjoined
09:10:26  <trevnorris>hello
09:10:33  * kazuponquit (Remote host closed the connection)
09:11:50  <trevnorris>indutny: any tips on helping performance on the v8 upgrade? (GH-5049)
09:12:31  <indutny>hoya
09:12:36  <indutny>please remind me about it
09:12:56  <trevnorris>i'm just trying to upgrade v8 to 3.17.11
09:13:30  <trevnorris>utf8 operations are much faster, but unfortunately ascii operations are inversely slower.
09:13:55  <indutny>ok
09:14:05  <trevnorris>and following up on the v8 issue i filed, that's about as fast as ascii's going to get.
09:14:09  <indutny>do you want this to happen in 0.10?
09:14:13  <trevnorris>oh no
09:14:16  <trevnorris>it's for 0.12
09:14:17  <indutny>ah, well
09:14:19  <indutny>I don't mind
09:14:30  <trevnorris>oh, ok.
09:14:45  <indutny>but we'll have enough time before that :)
09:15:05  <indutny>so it might be a good idea to not bother much about it
09:15:14  <indutny>but from another point
09:15:25  <indutny>we should press on v8 team about performance degradations
09:15:33  <indutny>so its good that you're doing it now
09:18:06  <trevnorris>thanks.
09:20:24  * saghuljoined
09:20:43  <trevnorris>mainly i'm working on centralizing memory allocation problem.
09:21:28  <trevnorris>still really bugging that I haven't found a more efficient way to track when chunks are no longer referenced in js.
09:23:58  * `3rdEdenjoined
09:29:37  * csaohquit (Remote host closed the connection)
09:32:38  * csaohjoined
09:33:42  * `3rdEdenquit (Ping timeout: 264 seconds)
09:33:48  * rendarquit
09:40:21  * rendarjoined
09:48:40  <trevnorris>indutny: i need to pass the length of the malloc to the MakeWeak callback. mind telling me if how i'm doing it here is safe/efficient (bottom, in WeakCallback) https://gist.github.com/trevnorris/5186046
09:52:03  <indutny>superfluos conversions
09:52:09  <indutny>just convert it to uint32_t*
09:52:16  <indutny>and use it
09:52:27  <indutny>and delete[] it
09:52:32  <indutny>type doesn't matter here
09:53:44  <trevnorris>so using reinterpret_cast is ok here?
09:54:50  <trevnorris>(just keep hearing about the horrors of misusing that, and all)
09:55:15  <indutny>yeah, it should be ok
09:55:22  <indutny>just know what you're doing
09:55:24  <indutny>and you'll be safe
09:55:45  <trevnorris>oh wait. i'm already passing void* arg.
09:55:54  <trevnorris>*facepalm*
10:05:42  * `3rdEdenjoined
10:06:06  * `3rdEdenchanged nick to Guest65936
10:06:28  * Guest65936changed nick to V1
10:06:39  * V1changed nick to `3rdEden
10:06:55  * kazuponjoined
10:29:08  * mmalecki[zzz]changed nick to mmalecki
10:29:10  <trevnorris>alrighty, new allocation for buffers is almost 4x's faster. and about 10x's more memory efficient.
10:29:19  <trevnorris>now, time for some sleep. almost 4am here. =P
10:29:57  * trevnorrisquit (Quit: Leaving)
10:35:54  <indutny>haha
10:35:56  <indutny>good
10:36:00  <indutny>sleep tight
10:39:26  * abraxasquit (Remote host closed the connection)
10:43:43  * wolfeidaujoined
10:44:15  * kazuponquit (Remote host closed the connection)
10:56:49  * loladiroquit (Quit: loladiro)
11:03:40  * zotjoined
11:04:17  * sgallaghjoined
11:14:17  * piscisaureus_joined
11:19:42  <indutny>hey people
11:19:45  <indutny>piscisaureus_: how are you?
11:20:23  <piscisaureus_>hey fedor
11:20:31  <piscisaureus_>I'm grea / you>
11:20:39  <piscisaureus_>let me do that again
11:20:44  <piscisaureus_>I'm great, you?
11:20:55  <indutny>haha :)
11:20:57  <indutny>fine too
11:21:11  <indutny>I remember some guys was discussing dual stack in libuv there
11:21:20  <indutny>is dual stack tcp possible on windows?
11:21:21  <indutny>on one socket
11:23:13  <indutny>piscisaureus_: ^
11:23:50  <piscisaureus_>indutny: yes
11:23:56  <piscisaureus_>indutny: it's just off by default
11:24:01  <indutny>great
11:24:14  <piscisaureus_>indutny: we're already supporting it for udp but not tcp atm
11:24:28  <indutny>yes, I know about udp
11:24:32  <piscisaureus_>the trick is to turn OFF IPV6_V6ONLY
11:24:34  <indutny>it seems to be working on osx
11:24:36  <indutny>I know
11:24:46  <indutny>not sure about Solaris and BSD
11:25:29  <indutny>so, why I'm talking about this :)
11:26:18  <indutny>I don't like that we're ignoring RFC and sorting results of getaddrinfo()
11:26:23  <indutny>to make ipv4 come first
11:26:25  <indutny>and ipv6 come last
11:26:42  <indutny>I'm working on fix for this
11:26:48  <indutny>and only 4 tests are failing right now
11:26:57  <indutny>but this fix requires dual stack support in libuv
11:27:50  <indutny>piscisaureus_: wanna take a look at WIP?
11:28:23  * sgallaghquit (Remote host closed the connection)
11:29:57  <piscisaureus_>indutny: huh - why you need dualstack support?
11:30:18  <piscisaureus_>indutny: I mean, we don't need that for *outgoing* sockets right? dualstack is for server sockets
11:30:25  <indutny>because otherwise server.listen() won't work
11:30:27  <piscisaureus_>indutny: but yeah point me to the wip, maybe I'll understand
11:30:32  <indutny>I mean server.listen() without arguments
11:30:40  <indutny>if localhost resolves to ::1
11:30:47  <piscisaureus_>ah - right
11:30:52  <indutny>and everything fails miserably
11:31:00  <zot>is there an endorsed way to check if a uv_timer_t is active in a loop?
11:31:23  <indutny>piscisaureus_: I'll run tests once again and will show you what I've now
11:31:30  <piscisaureus_>indutny: the downside is that when you listen on ::1 w/ dualstack, all client IP addresses appear as ipv6
11:31:37  <indutny>yes
11:31:49  <indutny>obviously
11:32:01  <indutny>but there're a lot of problems with ipv6 otherwise
11:32:07  <piscisaureus_>indutny: that's not great...
11:32:22  <indutny>we can translate them to ipv4
11:32:33  <indutny>'::ffff:' => ''
11:32:34  <piscisaureus_>well that'd probably be worse :)
11:32:38  <indutny>or something like that
11:33:16  <piscisaureus_>indutny: also not all systems may have an ipv6 stack
11:33:21  <indutny>yes, I know
11:33:24  <indutny>I'm taking this in account
11:34:21  <indutny>ok, all tests are passing
11:34:53  <indutny>https://github.com/indutny/node/compare/feature-dualstack
11:35:28  <indutny>so, as you can see I've changed tests only slightly
11:35:43  <indutny>so I expect the most of the user code to be working without major changes
11:35:49  <indutny>ok, now its time to test it on ipv4
11:35:50  <indutny>:)
11:35:53  <indutny>machine
11:36:40  <saghul>zot uv_is_active(timer)
11:37:18  <piscisaureus_>hey saghul
11:37:25  <saghul>piscisaureus_ hey
11:37:46  <piscisaureus_>saghul: have you managed to make pyuv the new standard yet?
11:37:56  <piscisaureus_>in python-land
11:38:21  <saghul>piscisaureus_ the standard will be based on python sockets, but the only implementation that proves the point that they are not needed is based on pyuv
11:38:30  <saghul>https://github.com/saghul/rose
11:38:32  <saghul>piscisaureus_ ^
11:38:40  * piscisaureus_changed nick to piscisaureus
11:38:48  <indutny>oh, how cute :)
11:38:49  <indutny>"rose"
11:39:07  <saghul>yeah, the reference implementation is called "tulip"
11:39:17  <saghul>you can tell a Dutch guy wrote it ;-)
11:39:29  <piscisaureus>saghul: are you making a sensible standard, or will it all be based on uv_poll ?
11:39:44  <piscisaureus>::troll_in_cheek::
11:39:51  <saghul>xD
11:39:51  * sgallaghjoined
11:40:08  * hzjoined
11:40:24  <saghul>the "transport" abstraction should not depend on Python sockets (poll is needed for this) so I need to reimplement those
11:40:36  <saghul>for now I'm using poll
11:41:28  * csaohquit (Quit: csaoh)
11:41:46  <saghul>piscisaureus actually, when I pointed out to Guido that I could do TCP and stuff without Python sockets he was happy to see his point validated, that is, tulip's guts can be replaced in a transparent way
11:42:03  <saghul>so yeah, that's coming, I just need some time :-)
11:42:35  <piscisaureus>saghul: so - what exactly is the difference between rose and tulip?
11:42:35  <piscisaureus>saghul: because right now what I understand is that tulip is the reference implementation and rose is the reference implementation.
11:42:37  <piscisaureus>...
11:44:38  * kazuponjoined
11:45:43  <saghul>piscisaureus tulip is the reference implementation. It uses Python sockets, and epoll, ASO. Now, tulip is designed in such a way that the event loop can be set, that's what rose is, a particular eventloop implementation
11:45:58  <piscisaureus>saghul: https://code.google.com/p/tulip/source/browse/tulip/windows_events.py
11:46:16  <piscisaureus>saghul: it seems that tulip somehow replaces the send/receive/accept/connect functions to work with iocp
11:47:07  <saghul>yes, they wrote some wrappers
11:48:00  * hzquit
11:48:02  * csaohjoined
11:49:09  * kazuponquit (Ping timeout: 245 seconds)
11:56:09  <zot>saghul: tnx
11:59:38  <indutny>piscisaureus: it works! :)
11:59:41  <indutny>on smartos with ipv6
11:59:43  <indutny>err
11:59:45  <indutny>s/with/without/
11:59:51  <indutny>and on osx with ipv6
12:02:25  <indutny>yay
12:02:38  <indutny>so, only dualstack in libuv is left
12:06:33  * dominictarrquit (Quit: dominictarr)
12:09:51  * kazuponjoined
12:35:30  <indutny>piscisaureus: you still there?
12:36:53  <indutny>https://github.com/joyent/libuv/pull/749
12:36:58  <indutny>piscisaureus: ^^^^
12:41:11  <indutny>ircretary: tell bnoordhuis about https://github.com/joyent/libuv/pull/749
12:41:11  <ircretary>indutny: I'll be sure to tell bnoordhuis
12:58:59  * qmx|awaychanged nick to qmx
13:00:15  * bnoordhuisjoined
13:01:10  <indutny>bnoordhuis: hey man
13:01:42  <indutny>bnoordhuis: https://github.com/indutny/node/compare/feature-dualstack
13:01:51  <indutny>bnoordhuis: and also https://github.com/joyent/libuv/pull/749
13:02:14  <indutny>bnoordhuis: note that all tests are passing on both boxes: with ipv6 interface and without it.
13:02:30  * kazuponquit (Remote host closed the connection)
13:04:39  <indutny>all this is regarding our previous discussion about order of addresses in getaddrinfo()
13:04:40  <indutny>and RFC
13:28:01  <indutny>ben?
13:33:36  <bnoordhuis>fedor?
13:33:46  <indutny>bnoordhuis: oh, here you are
13:33:54  <indutny>do you have minute to discuss dual stack for tcp?
13:34:15  <bnoordhuis>in a minute maybe. working through my email backlog
13:34:43  <indutny>ok, I see
13:41:03  * zotquit (Quit: Leaving.)
13:42:22  <MI6>joyent/node: Ben Noordhuis v0.10 * 808b7ad : doc: fix broken links in blog footer The blog lives at blog.nodejs.org w - http://git.io/jFKlmg
13:51:55  <bnoordhuis>indutny: okay, dual stack. tell me why i should care
13:52:04  <indutny>because it works :)
13:52:07  <indutny>haha
13:52:12  <indutny>without any significant problem
13:52:23  <indutny>and makes us RFC compatible
13:52:49  <indutny>anything else?
13:53:01  <indutny>ah, I know
13:53:07  <indutny>if not now - then never
13:53:15  * hzjoined
13:53:29  <bnoordhuis>i like never. never lasts a long time
13:53:47  <indutny>never like never
13:53:54  <bnoordhuis>kidding aside, how does this make node better?
13:54:04  <bnoordhuis>i mean real world use cases
13:54:07  * c4milojoined
13:54:15  <indutny>ipv6 enabled by default
13:54:27  <indutny>for both servers
13:54:28  <indutny>and clients
13:55:10  <bnoordhuis>and?
13:55:18  <indutny>and this is good?
13:55:21  <indutny>:)
13:55:27  <indutny>future
13:56:07  * benoitcquit (Excess Flood)
13:56:19  <bnoordhuis>for servers? what if you want the ipv4 version of your server to do something different from the ipv6 version?
13:56:21  <indutny>so, no kidding, right? Why are you against it?
13:56:35  <indutny>bnoordhuis: you should do it explicitly!
13:56:36  <indutny>:)
13:56:43  <bnoordhuis>oh, it's not that i'm against it. i just can't really bring myself to care about it
13:56:43  <indutny>well, its not implemented in my patch yet
13:57:03  <indutny>bnoordhuis: well, there're people who care
13:57:09  <bnoordhuis>who?
13:57:12  <indutny>for example, take Yandex
13:57:20  <indutny>they've a lot of IPv6 infrastructure
13:57:53  <bnoordhuis>i never hear from yandex though, only through you
13:58:14  <bnoordhuis>i'd expect them to be a little more active on the mailing list or the bug tracker if this was such a hot issue for them
13:58:23  <bnoordhuis>anyone else?
13:59:01  <indutny>haha :)
13:59:08  <indutny>that's the problem with russians
13:59:35  <indutny>they're solving problem themselves or finding asking someone who they know
13:59:39  <indutny>anyway
14:00:10  <bnoordhuis>discuss it with bert and isaac
14:00:15  <indutny>what?
14:00:16  <bnoordhuis>if they're okay with it, i'm okay with it
14:00:20  <indutny>dual stack?
14:00:23  <bnoordhuis>yes
14:00:26  <indutny>ok, anyway
14:00:31  <indutny>I think we should add API for libuv
14:00:34  <indutny>for TCP dual stack
14:00:48  <indutny>just because its possible and useful
14:00:55  <indutny>and present for UDP
14:01:09  <bnoordhuis>that was, in hindsight, something of a mistake
14:01:21  <indutny>why?
14:01:33  <bnoordhuis>well, for one, it's not possible to emulate on windows xp
14:01:45  <indutny>brb
14:01:47  <bnoordhuis>emulate/implement
14:02:19  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
14:02:53  * kazuponjoined
14:04:40  * piscisaureus_joined
14:05:01  * benoitcjoined
14:07:22  * kazuponquit (Ping timeout: 240 seconds)
14:09:48  * hzquit (Ping timeout: 264 seconds)
14:22:24  * hzjoined
14:23:25  * jguerrerojoined
14:27:12  * hzquit (Ping timeout: 264 seconds)
14:28:42  * bradleymeckjoined
14:30:17  * piscisaureus_quit (Read error: Connection reset by peer)
14:39:27  * kazuponjoined
14:41:35  * mikealquit (Quit: Leaving.)
14:51:42  * AvianFlujoined
14:56:54  * philipsquit (Ping timeout: 252 seconds)
14:58:13  * qmxchanged nick to qmx|brb
14:58:35  * AvianFluquit
15:07:44  * qmx|brbchanged nick to qmx
15:10:35  * defunctzombie_zzchanged nick to defunctzombie
15:11:56  * philipsjoined
15:14:04  * piscisaureus_joined
15:17:32  * kazuponquit (Remote host closed the connection)
15:25:49  * dapjoined
15:32:17  * benoitcquit (Excess Flood)
15:35:32  * benoitcjoined
15:37:20  * dominictarrjoined
15:46:44  * mikealjoined
15:49:08  <bradleymeck>whats the proper way to include uv in a different gyp file without going so far as to write python wrapper
15:52:24  * kazuponjoined
15:52:29  <bnoordhuis>bradleymeck: define 'include'?
15:52:58  <bradleymeck>bnoordhuis: put it into dependencies, i found a closed issue that solved my problem
15:53:31  <bradleymeck>-Dlibrary=static_library , but that seems a bit odd to need to do
15:55:55  * mikealquit (Quit: Leaving.)
15:56:23  <bnoordhuis>bradleymeck: if you have a common.gypi you can add 'library%': 'static_library' to your variables section
15:58:01  <bnoordhuis>"Sorry, I'm doing this through Github's file editor, which doesn't have syntax checking."
15:58:03  * benoitcquit (Excess Flood)
15:58:04  <bnoordhuis>ffs
15:58:21  <tjfontaine>hahaha
15:58:22  <bnoordhuis>nothing says fuck you like submitting a PR with syntax errors
15:59:22  * hzjoined
15:59:29  <tjfontaine>I made a similar commente
16:04:02  * benoitcjoined
16:07:15  <indutny>back
16:07:23  <indutny>bnoordhuis: we can create two-socket mode for it
16:07:30  <indutny>compatibility mode
16:07:32  <indutny>or rather
16:07:36  <indutny>don't give a fuck about windows xp
16:07:48  <indutny>I'm really afraid of people who're going to use ipv6 on xp
16:08:23  <tjfontaine>i'm really afraid of people
16:08:36  <indutny>I'm really afraid
16:08:47  <bnoordhuis>i'm
16:08:48  <bnoordhuis>i win
16:08:55  <indutny>I
16:09:00  <bnoordhuis>aw
16:09:05  <bnoordhuis>
16:09:07  <bnoordhuis>hah!
16:09:09  <indutny>:)
16:09:14  <indutny>your client sucz
16:09:24  <indutny>so
16:09:28  <indutny>returning back to reality
16:09:32  <indutny>isaacs: yt?
16:09:35  <indutny>morning
16:09:48  <rendar>h! (that sound that preceedes the 'I' pronunciation)
16:09:57  <tjfontaine>he said he would be returning this evening
16:10:05  <indutny>tjfontaine: oh, that
16:10:07  <indutny>ok
16:10:12  <tjfontaine>I don't know if he'll be doing any lurking today though
16:10:26  <indutny>yeah, I see
16:10:40  <indutny>I just need someone to weigh in about ipv6 and getaddrinfo
16:10:44  <indutny>bnoordhuis: right?
16:11:27  <bnoordhuis>right
16:11:46  <tjfontaine>https://dl.dropbox.com/u/35720/jenkins-pulls.png
16:12:06  <indutny>kewl
16:12:40  <tjfontaine>in that view it's actually a button to trigger building the pull request
16:13:14  * hzquit (Read error: Connection reset by peer)
16:14:11  <tjfontaine>I'm really really really annoyed with windows http://jenkins.nodejs.org/job/libuv-pullrequest/label=windows/6/console
16:15:11  <bnoordhuis>tjfontaine: how/why does that happen?
16:15:42  <tjfontaine>well that's an interesting question really
16:16:21  <tjfontaine>I've started just telling jenkins to blow away the workspace before each build, because jenkins jgit crap has a tendency to get very confused with our commit history
16:16:47  <tjfontaine>as far as windows is concerned, I'm guessing it thinks some process is still using that pack
16:17:49  * csaohquit (Read error: Connection reset by peer)
16:21:41  * hzjoined
16:28:45  * AvianFlujoined
16:33:12  * bradleymeckquit (Ping timeout: 264 seconds)
16:34:11  * bradleymeckjoined
16:35:39  * dominictarrquit (Quit: dominictarr)
16:38:36  * defunctzombiechanged nick to defunctzombie_zz
16:41:17  * stagasjoined
16:44:34  * benoitcquit (Excess Flood)
16:44:37  * bradleymeckquit (Quit: bradleymeck)
16:45:32  * benoitcjoined
16:46:11  <indutny>bnoordhuis: so about that 100% CPU OpenSSL issue with ZERO_RETURN
16:46:14  <indutny>any ideas?
16:46:42  <indutny>I can't really imagine any place where it can spin
16:46:51  <indutny>except streams2
16:47:15  <bnoordhuis>streams2 is the source of all bugs. fact
16:47:37  <bnoordhuis>can you reproduce the issue?
16:47:54  <indutny>no
16:48:01  <bnoordhuis>i assumed as much :)
16:48:17  <bnoordhuis>ask the guy that reported it to strace it?
16:48:47  <bnoordhuis>the thing to establish is if it's something at the libuv or the node level
16:49:28  * zotjoined
16:51:01  <indutny>done
16:51:17  <indutny>creationix: nice -> http://www.kickstarter.com/projects/creationix/js-git/posts/430922
16:51:26  <indutny>its like I could spend all money you'll give me :)
16:53:33  <creationix>indutny: exactly
16:53:44  * zotquit (Ping timeout: 255 seconds)
16:56:36  <tjfontaine>piscisaureus_: when you get a chance if you could look at the stat stuff I'd appreciate it
16:57:04  * csaohjoined
16:58:08  <indutny>who
16:58:09  <indutny>a
16:58:11  <indutny>err
16:58:12  <indutny>whoa
16:58:15  <indutny>I can't stand it
16:58:22  <indutny>#node.js is too active for me
16:58:43  <tjfontaine>SnR in #node.js isn't what you'd want
17:00:06  <indutny>is it negative? :)
17:00:12  <indutny>or just NaN
17:06:34  * kazuponquit (Remote host closed the connection)
17:09:34  * benoitcquit (Excess Flood)
17:11:27  <cjd>lol @ libuv == #node.js-dev
17:12:47  * indutnytopic: And we're going to die at "liberal utopian vacation" day. ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
17:14:18  <bnoordhuis>what did i miss?
17:14:45  <indutny>apocalypse
17:15:49  <indutny>bnoordhuis: https://github.com/indutny/node/commit/315bba3b8449a72c6350cb6cf1648278047f1392
17:15:54  <indutny>what do you think about landing this in 0.10?
17:16:08  <indutny>I forgot to reset this.ssl.error in once clause
17:16:21  <indutny>which sometimes results in assertion error (though, I can't reproduce it)
17:16:32  * benoitcjoined
17:17:06  * bradleymeckjoined
17:20:52  * `3rdEdenquit (Remote host closed the connection)
17:26:09  <bnoordhuis>indutny: sorry, afk for a bit
17:30:16  <indutny>ok
17:30:17  <indutny>see ya
17:30:44  * bnoordhuisquit (Ping timeout: 256 seconds)
17:43:56  <tjfontaine>sblm is busy
17:47:56  * `3rdEdenjoined
17:48:20  * `3rdEdenchanged nick to Guest56628
17:48:32  * Guest56628changed nick to V1
17:48:47  * V1changed nick to `3rdEden
17:54:22  * AvianFluquit
17:56:34  * AvianFlujoined
17:59:28  * sblomjoined
18:03:36  * sblompart
18:03:42  * sblomjoined
18:05:22  <tjfontaine>sblom: busy day entering all the failures
18:06:27  <sblom>tjfontaine: I kept losing track of where I was so I figured it was time to get organized.
18:06:33  <tjfontaine>indeed
18:06:58  * kazuponjoined
18:08:42  * qmxchanged nick to qmx|lunch
18:11:34  * kazuponquit (Ping timeout: 256 seconds)
18:12:39  * loladirojoined
18:18:41  * TooTallNatejoined
18:23:26  * `3rdEdenquit (Quit: brb yo.)
18:26:17  <bradleymeck>isaacs: apparently some large allocation vulnerability is what the guy is going on about linked in thing from last year, still trying to get him to cough up cite or ref
18:27:19  <tjfontaine>hm
18:27:45  * mikealjoined
18:30:44  * `3rdEdenjoined
18:30:46  * csaohquit (Quit: csaoh)
18:33:41  * trevnorrisjoined
18:36:22  <trevnorris>ah, feels good to be back from vacation.
18:37:23  * bradleymeckquit (Ping timeout: 252 seconds)
18:38:11  * bradleymeckjoined
18:38:26  * bnoordhuisjoined
18:43:02  * defunctzombie_zzchanged nick to defunctzombie
18:46:42  * bnoordhuisquit (Ping timeout: 245 seconds)
18:50:02  * hzquit
18:52:46  * c4miloquit (Remote host closed the connection)
19:00:22  * bradleymeckquit (Quit: bradleymeck)
19:00:53  * qmx|lunchchanged nick to qmx
19:05:09  * bradleymeckjoined
19:07:56  * kazuponjoined
19:08:20  * c4milojoined
19:12:46  * kazuponquit (Ping timeout: 256 seconds)
19:20:21  * sblomquit (Ping timeout: 240 seconds)
19:20:53  * sblomjoined
19:21:43  <trevnorris>have a friend teaching me how to implement this. anyone think it may be useful in node? http://www.parrot.org/sites/www.parrot.org/files/vmem.pdf
19:24:48  <cjd>v8 is single threaded so it only has to worry much about a single core
19:25:15  <cjd>there are cases where you have multiple threads but not so interesting since they don't do a whole lot of allocation
19:25:39  <cjd>fast garbage collection is super interesting primarily to the V8 guys
19:26:49  <cjd>and ofc memory fragmentation is a unique concern to node whereas chrome wipes the slate more or less every page load and entirely every time you close a tab
19:27:46  <trevnorris>ofc?
19:28:41  <trevnorris>i understand memory fragmentation, but don't know what ofc stands for.
19:29:36  <cjd>"of course"
19:29:47  <trevnorris>ah. heh
19:30:26  <trevnorris>cjd: is it conceivable there could live a memory allocator could live below the v8 layer that it calls to?
19:30:35  * hzjoined
19:33:15  <cjd>what kind of memory would it be for?
19:33:48  <indutny>oh gosh
19:33:52  <indutny>have I missed something?
19:34:03  <cjd>just BSing about memory :)
19:34:10  <indutny>aha
19:34:14  <trevnorris>indutny: well, as you know i got very little sleep last night ;-)
19:34:21  <indutny>basically that means that ircrelay is messing with my history
19:34:25  <indutny>yeah, I know
19:34:37  * mikealquit (Quit: Leaving.)
19:34:40  <trevnorris>so i'm spouting off nonsense about memory allocation
19:34:58  <cjd>Garbage collection is really complicated stuff
19:35:45  <trevnorris>yeah. my problem is being able to know when a js object is no longer reachable/gc'd very cheaply.
19:35:52  <cjd>IMO the fastest way to do it is by statically analyzing code to find pieces which are provably not going to outlast the execution of X function then move them to the stack
19:35:54  <trevnorris>persisting a bunch of handles kicks me in the nuts.
19:36:00  <cjd>yeap
19:36:03  <cjd>GC is hard
19:36:28  <cjd>in terms of raw MB/s, the fastest collector is Sun's big lock collector
19:36:45  <indutny>erm?
19:36:53  <indutny>really?
19:36:59  <cjd>That's my understanding
19:37:13  <indutny>well, I need proof ;)
19:37:14  <cjd>Java... always good on paper
19:37:18  <indutny>aha :)
19:37:31  <cjd>I said "raw MB/s" :)
19:37:35  <trevnorris>well, i've basically replicated what node is doing now with buffer pools http://git.io/3FxwxQ
19:37:46  <cjd>if you have tons of crap to collect and nothing else, use Java
19:37:54  <cjd>and if you use Java, you always have tons of crap :)
19:37:55  <trevnorris>but the problem is that if a chunk of memory is still pointed to by a single js object then the entire thing will stick around.
19:38:31  <trevnorris>that allocator is pretty fast, but has the chance of spewing memory like a sieve.
19:39:37  <cjd>www.cs.purdue.edu/homes/eblanton/publications/schism-pldi10.pdf
19:40:03  <trevnorris>the only way I can't find to know when an allocated chunk is free is to persist it, but that takes +30x's longer.
19:41:31  <cjd>the fijivm guys are using a faster GC but it doesn't have the throughput of OpenJDK's
19:41:53  <cjd>but it doesn't use a big lock so as long as your work is not GC bound, you get more done
19:43:17  <cjd>As I said, my opinion is that you want to do static analisys on code surrounding the memory allocation and try to make assertions about the lifetime of that memory
19:45:27  <trevnorris>um. i'm not trying to write a gc for node. just trying to figure out the fastest way to know when js objects are no longer reachable.
19:46:00  <cjd>well.. that means you're writing a gc for v8 :)
19:46:05  <trevnorris>heh
19:46:23  <cjd>do you work on firefox?
19:46:55  <trevnorris>oh no. i'm actually part of the metrics team (though that may be changing soon)
19:47:31  <cjd>ahh so you're not familiar with libmozalloc
19:47:51  <trevnorris>no no. i'm still getting familiar w/ c++. =P
19:47:56  <cjd>I'm told that I basicly invented libmozalloc in isilation
19:48:00  <cjd>*isolation
19:48:01  <trevnorris>been doing web development for years, and got bored with js
19:48:28  <trevnorris>really?
19:48:42  <cjd>I wrote about 50k lines of C, maybe 100k lines of java, js is my favorite now
19:49:03  <cjd>https://github.com/cjdelisle/cjdns/blob/master/memory/Allocator.h
19:49:16  <cjd>that's how I stay sane when I'm allocating and freeing memory manually
19:49:27  <cjd>if you follow the rules, you never get a dangling pointer
19:50:46  <trevnorris>interesting.
19:50:48  <cjd>* Writer interface which writes data to memory and <-- don't believe everything you read in a comment
19:51:20  <cjd>every function in my codebase takes an allocator if it needs memory
19:51:30  <cjd>I *never* use malloc() (C's version of new)
19:52:06  <cjd>struct Allocator* child = Allocator_child(myAlloc);
19:52:12  <trevnorris>that would work great for me, if using MakeWeak on every handle didn't kill me.
19:52:15  <cjd>potentiallyLeakyFunction(child);
19:52:26  <cjd>Allocator_free(child);
19:52:38  <cjd>potentiallyLeakyFunction -> provablyNonLeakyFunction
19:52:39  <cjd>:)
19:52:46  <SquirrelCZECH>:-)
19:53:05  * bnoordhuisjoined
19:53:21  <cjd>memory leaks are easy to spot, dangling pointers too
19:53:33  <cjd>there's always 1 line which is doing something obviously stupid
19:54:05  <cjd>unlike malloc/free where there's often no one line of code which you can blame for the leak
19:54:37  <trevnorris>um. there's something i'm missing. keeping track of all of v8's handles to memory is what's expensive.
19:54:42  <trevnorris>that's the problem i'm trying to solve right now.
19:54:51  <cjd>yeah, GC is hard :)
19:55:16  <trevnorris>indutny and bnoordhuis had a couple idea, but i only half followed it.
19:55:39  <trevnorris>*ideas
19:55:41  <cjd>you basicly have to tree trace the handles in order to determine what is not reachable and (if you're java) you stop the world to do it
19:56:34  <trevnorris>i had assumed that v8 was already doing all that since it can properly clean up all the unreadable js objects
19:56:40  <trevnorris>and it can do it quite quickly.
19:56:44  <cjd>yeap
19:56:47  <cjd>reasonably so
19:56:59  <trevnorris>but me finding out when that's happened isn't so quick
19:57:32  <cjd>ahh, so you are trying to improve the v8 GC
19:57:42  <trevnorris>if that's what's required
19:58:15  * bnoordhuisquit (Ping timeout: 276 seconds)
19:58:27  <trevnorris>basically i have criteria i want to hit, and whatever that requires i'll figure out how to do.
19:58:55  * dominictarrjoined
19:58:56  * cjdwould not touch a GC engine
19:59:24  <cjd>that's stuff people write their PHD thesus on
19:59:40  <trevnorris>heh
20:00:13  <trevnorris>luckily i have a very small and specific thing i'm looking for.
20:04:56  * mikealjoined
20:05:58  <piscisaureus_>hmm
20:06:08  <piscisaureus_>who added the node-vx.y.z tags to the libuv repo?
20:06:43  <piscisaureus_>I wonder why they don't line up with the vx.y.z (without the node- prefix) commits
20:08:58  * AvianFluquit (Remote host closed the connection)
20:09:01  * kazuponjoined
20:09:57  <trevnorris>indutny: that change you an bn were talking about, is that on the v8 side?
20:10:22  <indutny>yeah
20:10:52  <trevnorris>bugger.
20:12:49  * qmxchanged nick to qmx|coffee
20:13:22  * mikealquit (Ping timeout: 245 seconds)
20:13:38  * kazuponquit (Ping timeout: 252 seconds)
20:15:23  <trevnorris>indutny: and any improvements of the kind i've been looking for will require a change on the v8 side?
20:19:30  <indutny>well, doesn't seem like so
20:19:35  <indutny>you're just using APIs, no?
20:24:54  <trevnorris>indutny: so far. if there's some other crazy trick that gets me what i'm looking for then awesome.
20:25:07  * bnoordhuisjoined
20:31:41  <bnoordhuis>someone filed a bug report today on node 0.5.11-pre :-/
20:31:59  <indutny>good that they've found error
20:32:08  <indutny>I bet we haven't fixed some there
20:32:16  <indutny>bnoordhuis: what was that?
20:34:11  * qmx|coffeechanged nick to qmx
20:34:20  * sgallaghquit (Remote host closed the connection)
20:35:28  <trevnorris>hm. so v8 upgrades pretty often eh?
20:35:48  <tjfontaine>rolling releases
20:40:30  <trevnorris>well, guess i'll need to rename my branch now =P
20:41:18  * mikealjoined
20:41:23  * skebcio_quit (Read error: Connection reset by peer)
20:42:40  <trevnorris>tjfontaine: oh, can you give a one line overview why the build was breaking in sunos?
20:43:11  <tjfontaine>missing symbol, because of the latin-1 refactoring
20:43:22  <tjfontaine>would work if you disable dtrace
20:43:23  <indutny>ah
20:43:26  <indutny>I know what
20:43:31  <indutny>ONECHAR_STRING
20:43:34  <indutny>or something like that
20:43:49  <tjfontaine>ya SEQASCIISTRING__CHARS__CHAR
20:43:52  <indutny>trevnorris: revert two latest commits about dtrace
20:44:00  * skebciojoined
20:44:10  <trevnorris>ok. will do
20:53:39  <trevnorris>indutny: also, have a strange issue where node_isolate is undefined in node_object_wrap.h.
20:54:57  <bnoordhuis>trevnorris: that's because it's not defined in node_internals.h
20:55:24  <bnoordhuis>what do you need it for in node_object_wrap.h?
20:55:32  <trevnorris>bnoordhuis: 3.17 api
20:55:47  <trevnorris>need to pass Isolate to a lot of things now.
20:56:52  <bnoordhuis>you can add an 'extern v8::Isolate* node_isolate;' in there
20:57:09  <trevnorris>awesome. thanks.
20:57:19  <bnoordhuis>though you should probably do that at the function level so it doesn't leak to user code
20:57:35  <trevnorris>hm?
20:58:31  <bnoordhuis>trevnorris: add it inside the functions where it's needed
20:58:48  <trevnorris>bnoordhuis: that's pretty much all of them.
20:59:35  <trevnorris>::Unwrap is the only method that doesn't need it
20:59:40  <bnoordhuis>is that an observation or an implicit counterargument?
20:59:42  * bradleymeckquit (Quit: bradleymeck)
20:59:58  <trevnorris>just and observation.
21:00:35  <trevnorris>don't understand cc compilers well enough to know whether declaring that in every function will impact it in some way.
21:02:34  <bnoordhuis>trevnorris: not at all. it's just a declaration
21:02:50  <trevnorris>cool. so just throw it into all functions that need it? will do.
21:07:32  <trevnorris>awesome. worked great. thanks.
21:09:36  <indutny>saghul: just read about Tulip
21:09:37  <indutny>:)
21:09:39  * kazuponjoined
21:09:41  <indutny>interesting
21:09:43  <indutny>so its new PEP
21:09:51  * txdvquit (Ping timeout: 240 seconds)
21:10:08  <saghul>indutny, it supposed to be the async API to unite them all in Python
21:10:12  <saghul>:-)
21:10:14  <indutny>yes, I see
21:10:37  <saghul>it's Python >= 3.2 so it will take years
21:14:17  * kazuponquit (Ping timeout: 255 seconds)
21:14:56  * txdvjoined
21:15:05  * loladiroquit (Quit: loladiro)
21:18:53  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:20:48  <trevnorris>ah hell, didn't realize i switched over to #node.js. was wondering why it was so noisy.
21:25:13  * loladirojoined
21:31:13  * AvianFlujoined
21:35:42  * wolfeidauquit (Remote host closed the connection)
21:41:05  <trevnorris>with the 3.17 upgrade, assertion tests aren't printing the text that error'd.
21:41:33  <bnoordhuis>trevnorris: that's somewhat expected
21:41:48  <trevnorris>really? was there an api change?
21:42:02  <bnoordhuis>in a sense
21:42:49  <trevnorris>is that something that will need to be fixed, or just a part of upgrading?
21:42:59  <bnoordhuis>part of the upgrade
21:43:08  <trevnorris>cool. i'll update the tests then. thanks.
21:46:17  * indexzerojoined
21:46:47  <trevnorris>bnoordhuis: also seems to give a bigger stack trace or something. "test/message/stack_overflow.js" is showing a bunch more "at ..." lines then before.
21:47:03  <tjfontaine>yay long stack traces
21:49:37  * c4miloquit (Remote host closed the connection)
21:49:53  <trevnorris>though i'm not sure how I feel about going from msgs like "Error: 1 == 2" to "Error"
21:49:55  <bnoordhuis>indeed :) i believe v8's stack walker became a little smarter
21:53:08  * rendarquit
21:53:38  * bradleymeckjoined
21:55:45  <creationix>wait, so node 0.12 won't allow recursive nextTick?
21:57:14  * wolfeidaujoined
21:58:07  <trevnorris>well, it will
21:58:14  <trevnorris>but your I/O will be flooded
21:58:24  <trevnorris>should use setImmediate for that instead.
21:59:16  <trevnorris>basically it won't keep track of the tickDepth and force defer to system I/O after so long.
21:59:54  * loladiroquit (Quit: loladiro)
22:00:29  <creationix>but what non-recursive nextTicks that happen to be inside other nextTick callbacks?
22:01:30  <trevnorris>oh, you misunderstand. nextTick doesn't give a . where the callback comes from.
22:01:56  <trevnorris>what it means is that it won't prevent the user from shooting themselves using an infinitely recursive nextTick callback.
22:02:46  <trevnorris>that actually reminds me, need to throw up that PR
22:03:05  <creationix>I understand how infinite loops are bad and you can shoot yourself
22:03:22  <creationix>but I'm doing something non-bad and my console is flooded with scary warnings
22:03:31  * defunctzombiechanged nick to defunctzombie_zz
22:03:32  <trevnorris>oh, those warnings are going to disappear.
22:03:42  <trevnorris>no check, no warnings.
22:04:08  <trevnorris>it'll be left up to the user to make sure their I/O doesn't get flooded with recursive nextTicks.
22:04:25  <creationix>on a related node, I thought setImmediate was the same thing as nextTick (the new behavior), how is it different
22:04:40  <trevnorris>one sec. there's a cool graphic for this =)
22:06:13  <trevnorris>anyone remember where that cool graphic went showing the uv_run callback loop?
22:06:57  <bnoordhuis>https://github.com/joyent/node/pull/3872#issuecomment-7804775 <- that one?
22:07:08  <trevnorris>yeah, that
22:07:10  <tjfontaine>creationix: each queued item happens on a consequitive tick
22:07:19  <trevnorris>but I swear I saw it get published in an article recently.
22:07:38  <tjfontaine>woah tj spell gud
22:07:50  * tjfontainewalks away
22:07:51  <trevnorris>tjfontaine: we really need to hammer out what a "tick" is.
22:08:14  <trevnorris>because I think the uv_run loop is considered a "tick" but also nextTick is a "tick"
22:08:22  <tjfontaine>trevnorris: in this case one loop iteration :)
22:08:22  * `3rdEdenquit (Remote host closed the connection)
22:08:32  <creationix>so the different is nextTick will keep pulling from the queue till it's empty, but setImmediate will only execute one generation of callbacks?
22:08:54  <tjfontaine>yes, (though nextTick as you have seen from the warnings will yield after N items)
22:09:08  <trevnorris>not in 0.12
22:09:14  <tjfontaine>right
22:09:21  <tjfontaine>as it is right now it yields
22:09:30  <creationix>oh, so it does yield now?
22:09:32  <trevnorris>yeah
22:09:36  <creationix>hmm :(
22:09:44  <creationix>I was hoping we already cracked down on that one
22:09:50  <trevnorris>how do you mean?
22:09:53  <creationix>so if I'm seeing the warning, then it is yielding already?
22:10:01  <trevnorris>no
22:10:09  * indexzeroquit (Quit: indexzero)
22:10:16  * kazuponjoined
22:10:25  <creationix>there is nothing wrong with recursive nextTick unless they are infinite or very long
22:11:05  <trevnorris>the tick warning shows up when nextTick is called from a depth deeper than tickDepth.
22:11:33  <creationix>where "depth" is recursion depth in the callback consumer?
22:11:42  <trevnorris>but it will only yield after all the functions in the nextTickQueue at that tickDepth have run.
22:11:47  <trevnorris>yeah
22:12:10  <creationix>is it super low (like 5)
22:12:22  <trevnorris>1000
22:12:32  <tjfontaine>process.maxTickDepth
22:12:33  <creationix>ok, then if I see the warning, I probably do have a bad loop
22:12:38  <tjfontaine>yes
22:12:42  <tjfontaine>more than likely anyway
22:13:10  <creationix>is there a way to turn it into an exception so I can see where the offending code it
22:13:13  <creationix>*is
22:13:45  <trevnorris>yeah. i think isaacs added something for that because of a similar problem in a test.
22:13:48  <trevnorris>anyone remember?
22:13:59  <tjfontaine>--throw-deprecation
22:15:28  <trevnorris>though even after the warning is removed if you have an infinitely recursive nextTick then the nextTickQueue array will overflow, and it will explode.
22:15:34  * kazuponquit (Ping timeout: 272 seconds)
22:15:58  <tjfontaine>trevnorris: ya but with newer v8 you get better stack traces, instead of range errors
22:16:08  <trevnorris>totally
22:16:42  <trevnorris>though i'm not sure how we're going to handle calling nextTick from a domain error. that will blow everything up w/o a nextTick.
22:16:50  <trevnorris>*nextTick*maxTickDepth
22:17:12  <tjfontaine>cross that bridge when we get to it I suppose
22:17:26  <trevnorris>heh, i'm working on the pr now. =)
22:17:36  <tjfontaine>ah well
22:18:20  <creationix>hmm, no throw
22:18:24  <creationix>I blame mocha though
22:19:09  * c4milojoined
22:19:58  <trevnorris>is isaacs still out?
22:20:05  <tjfontaine>until this evening
22:20:10  <trevnorris>coolio
22:20:13  <tjfontaine>creationix: yes, I've seen similar things from mocha
22:23:39  * qmxchanged nick to qmx|away
22:40:17  <trevnorris>now, if there was just a way to turn a queue from FIFO to LIFO, and not use unshift...
22:40:39  <trevnorris>erm, other way round.
22:40:56  <tjfontaine>that's what the linked list implementation is for? :)
22:42:10  <bradleymeck>is there a simple dynamic pointer array lib somewhere for C (void** pointer with length)? all of my attempts to create one make memcpy angry (unless i pull in string.h which basically gets rid of memory checking).
22:43:17  <trevnorris>tjfontaine: heh, but in js?
22:44:40  <tjfontaine>trevnorris: https://github.com/joyent/node/blob/master/lib/_linklist.js
22:45:36  <trevnorris>suddenly the current implementation doesn't seem so bad
22:48:02  <sblom>trevnorris: isaacs claimed he'd be back on the grid tonight.
22:48:14  <trevnorris>cool
22:48:42  <sblom>(I see now that I was the second answer to that question by, like, a _long_ time.)
22:48:57  <tjfontaine>hehe
22:49:19  <trevnorris>hey, better to get a second answer than none at all :)
22:49:24  <tjfontaine>sblom: btw that debugger race, that sounds quite similar to the case isaacs was hitting when he was fixing the zombie process issue
23:02:09  <trevnorris>argh. sometimes the numbers from the benchmark don't make any freakin sense.
23:03:38  * loladirojoined
23:05:24  * loladiroquit (Client Quit)
23:11:21  * kazuponjoined
23:12:12  <trevnorris>ooya. saved 30ns per nextTick callback. most useless perf improvement to date!
23:13:25  * defunctzombie_zzchanged nick to defunctzombie
23:16:18  * kazuponquit (Ping timeout: 264 seconds)
23:16:48  <cjd>most useless perf improvement to date <-- don't count on it :)
23:16:57  <trevnorris>lol
23:17:16  <tjfontaine>perf/count it's a joke son, laugh
23:17:40  <MI6>joyent/libuv: isaacs refs/tags/node-v0.7.2 * 243cfcd : Merge remote-tracking branch 'ry/v0.6' - http://git.io/yd0mtA
23:18:07  <trevnorris>bnoordhuis: so... test-fs-readfile-error.js is failing because the error stack no longer returns "Error: EISDIR, read"
23:18:15  <tjfontaine>what is it?
23:18:19  <trevnorris>bnoordhuis: that a problem?
23:18:34  * loladirojoined
23:18:36  <trevnorris>you mean, what's the test?
23:18:43  <tjfontaine>no, I mean what's it say now
23:18:48  <trevnorris>Error
23:18:50  <trevnorris>that's all
23:19:14  <tjfontaine>ok well that's not ideal
23:19:49  <trevnorris>ah, got it.
23:20:18  <trevnorris>so in fs.js it's creating the backtrace new Error early then assigning the message later
23:20:34  <trevnorris>but seems that it ignores the .message thing now.
23:20:36  <tjfontaine>and .message is immutable now?
23:21:08  <trevnorris>no idea.
23:21:23  <tjfontaine>pull up the repl and see :)
23:21:29  <trevnorris>nope
23:21:32  <trevnorris>just tried it
23:22:14  <trevnorris>so you can set message, but seems to not care now.
23:22:38  <tjfontaine>well, is `.message` being set or ignored, when you get it back has it changed?
23:23:02  * defunctzombiechanged nick to defunctzombie_zz
23:24:32  <trevnorris>tjfontaine: just tested in repl: "e = new Error; e.message = 'suck'; throw e;"
23:24:34  <trevnorris>nada
23:24:42  * `3rdEdenjoined
23:24:43  <tjfontaine>but what's in e.message now?
23:24:50  <trevnorris>'suck'
23:25:00  <tjfontaine>cute, so is there a new field holding the message?
23:26:07  <trevnorris>oh, son of a bitch. it's not enumerable and isn't being overridden internally.
23:26:39  <trevnorris>'e = new Error('hi'); e.message = 'bye'; throw e'
23:26:45  <trevnorris>> 'Error: hi
23:26:51  <trevnorris>'e.message'
23:26:54  <trevnorris>> 'bye'
23:27:18  <tjfontaine>use util.inspect to see the hidden properties?
23:27:54  <trevnorris>nope. still nothing.
23:29:11  <trevnorris>i'm checking v8 source. give me a few
23:29:15  * brsonjoined
23:30:05  <tjfontaine>util.inspect(e, {showHidden:true}) doesn't give you the infos?
23:31:13  <trevnorris>> util.inspect(e,{showHidden:true});
23:31:20  <trevnorris>> '{ [Error: hi] [stack]: [Getter/Setter], [message]: \'hi\' }'
23:31:26  <trevnorris>> throw e
23:31:33  <trevnorris>Error: suck
23:31:51  <tjfontaine>that was with new Error('suck') I take it?
23:31:55  <trevnorris>yeah
23:32:04  * loladiroquit (Quit: loladiro)
23:32:06  <trevnorris>then afterwards 'e.message = 'hi''
23:32:31  <tjfontaine>I wonder if that's just util.inspect being kind in the [Error: hi] portion, bet it special cases
23:32:35  <trevnorris>oh, dude.
23:32:46  <trevnorris>it's now part of "e.stack"
23:32:52  <trevnorris>it's just a massive message string.
23:33:03  * `3rdEdenquit (Ping timeout: 245 seconds)
23:33:03  <trevnorris>with "Error: suck\n..."
23:33:06  <tjfontaine>e.stack has always been there?
23:33:52  <trevnorris>yeah
23:34:00  <tjfontaine>that was more of a rhetorical question :)
23:34:04  <tjfontaine>I thought you were surprised by it
23:34:28  * loladirojoined
23:34:39  <trevnorris>heh, doing several things at once.
23:35:11  <MI6>joyent/libuv: Bert Belder refs/tags/node-v0.7.3 * 7ab62cf : Merge commit '267e75d' into master - http://git.io/Ukwq5g
23:35:23  <tjfontaine>interestingly formatError in util just calls Error.prototype.toString, so at least the underlying type still knows about .message
23:37:34  * brson_joined
23:37:39  <bnoordhuis>piscisaureus_: what are you doing? adding tags for old releases?
23:38:11  * brsonquit (Ping timeout: 246 seconds)
23:38:18  <piscisaureus_>bnoordhuis: yeah I was testing my release tool and found there was some bs
23:38:28  <piscisaureus_>so now I fixed them all
23:38:39  <piscisaureus_>and actually the tags now actually *match* what was in node :)
23:43:02  <trevnorris>tjfontaine: wtf.
23:43:04  <trevnorris>> var e = new Error; e.stack; e.message = 'hi'; throw e;
23:43:06  <trevnorris>Error
23:43:10  <trevnorris>that's with 3.14
23:43:24  <trevnorris>if you run the .stack getter then it won't use .message.
23:44:06  <piscisaureus_>bnoordhuis: http://twitter.yfrog.com/z/oclzahp
23:44:41  * c4miloquit (Remote host closed the connection)
23:45:18  <tjfontaine>trevnorris: I'm not seeing that on 0.10
23:45:24  <piscisaureus_>The 0.7.[5-9] days were messay
23:45:30  <piscisaureus_>*mesy
23:45:37  <piscisaureus_>C'MON BERT
23:45:58  <tjfontaine>this graph is pretty hilarious at times
23:46:41  <piscisaureus_>You mean, terrible?
23:46:42  <trevnorris>tjfontaine: really? when I run the following from v0.10.0
23:46:43  <trevnorris>> var e = new Error; e.stack; e.message = 'hi'; throw e;
23:46:47  <trevnorris>Error
23:46:50  <trevnorris>no message
23:48:15  <tjfontaine>ahh, ok so fs is getting the stack before setting the message there as well?
23:49:07  <trevnorris>first it "var backtrace = new Error;" then in a return function it "backtrace.message = err.message;"
23:49:21  * c4milojoined
23:49:44  <trevnorris>it's "function rethrow()"
23:49:47  <trevnorris>in lib/fs.js
23:51:16  <tjfontaine>but that's only mucking with things in debug?
23:51:21  <trevnorris>yeah
23:51:57  <trevnorris>but why it does that backtrace thing is beyond me.
23:56:30  * hzquit
23:56:51  * dominictarrquit (Read error: Connection reset by peer)
23:56:52  <trevnorris>so anyone have ideas how to handle the fact that setting ".message" doesn't do anything anymore?
23:57:10  <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
23:57:14  * dominictarrjoined
23:57:35  <trevnorris>but if that was the case, then why in 3.14 does it work until you call the .stack getter?
23:57:53  <tjfontaine>see deps/v8/src/messages.js
23:58:03  <trevnorris>yeah. i'm combing through that now.
23:58:05  <tjfontaine>that's the way it works
23:58:24  <tjfontaine>stack si a OneShotAccessor
23:59:41  <trevnorris>ah, i see now. in captureStackTrace it sets the stack with "%MarkOneShotGetter"
23:59:43  <trevnorris>ok, got it