00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:01:54  <othiym23>trevnorris: no more detail from node_g
00:02:12  <othiym23>trevnorris: but a bunch of tests that ran before, even if there were failing asserts, are now crashing with SIGSEGV
00:03:32  <tjfontaine>othiym23: oh, 64bit?
00:03:46  <tjfontaine>ya those addrs seem wide enough
00:03:50  <tjfontaine>please try
00:04:19  <tjfontaine>(cd deps/v8; curl https://github.com/v8/v8/commit/435d8aadc3f60fea2aaad23fae3f29e5aeccb907.diff | patch -p1)
00:05:28  <othiym23>will do, chief
00:10:30  <othiym23>tjfontaine: patch applied, ./configure && make && make node_g, still segfaulting
00:10:44  <tjfontaine>awesome.
00:10:51  <tjfontaine>NMF :)
00:11:12  <othiym23>same bt in gdb, too
00:11:18  <othiym23>yeah, that's why I didn't bug you with it in the first place ;)
00:12:18  <tjfontaine>:)
00:12:22  <tjfontaine>hehe I still like to know :P
00:12:33  <tjfontaine>the backtrace was suspicious though
00:13:15  <tjfontaine>could be just an unwrap in trevors logic though
00:13:32  <tjfontaine>clearly something set to null and not being checked if its ok to unwrap it
00:13:59  <tjfontaine>shame you can't see any of the jit frames there
00:14:38  <othiym23>tjfontaine: I updated the gist to be the node_g bt instead
00:14:53  <othiym23>the output's less about Smi stuff and more low-level, but otherwise the same
00:15:11  <othiym23>I'll take a look at it in SmartOS tonight
00:15:54  <tjfontaine>nod, the more I look at it it's probalby just an "uninitialized" value
00:20:21  * defunctzombie_zzchanged nick to defunctzombie
00:28:56  * jmar777joined
00:29:19  * mikealjoined
00:31:55  * M28joined
00:34:18  * mikealquit (Ping timeout: 264 seconds)
00:39:18  * wwicksquit (Quit: wwicks)
00:42:57  * zz_karupanerurachanged nick to karupa64
00:44:38  * karupa64changed nick to karupanerura
00:46:10  * EhevuTovquit (Quit: This computer has gone to sleep)
00:48:45  * TooTallNatejoined
00:50:20  * defunctzombiechanged nick to defunctzombie_zz
00:51:14  * c4milojoined
01:00:26  * dapquit (Quit: Leaving.)
01:14:00  <tjfontaine>sigh
01:14:20  <othiym23>that good?
01:14:23  <tjfontaine>well
01:14:46  <tjfontaine>hit a node bug, not sure how I'm going to reproduce this one :/
01:16:57  <othiym23>I had a couple like that this week
01:17:04  <tjfontaine>basically a node child from .fork() has its parent IPC pipe set into non-blocking mode
01:17:16  <othiym23>I consoled myself by telling myself that once I had a repro case the bugs would be easy to fix
01:17:18  <othiym23>but I was wrong
01:17:32  <tjfontaine>LET US DROWN OUR SORROWS
01:17:32  <LOUDBOT>I THINK I'LL TRY TO FUCK THE DEAF GIRL
01:17:43  <tjfontaine>loudbot is aggressive today
01:17:48  <othiym23>no wonder nexxy doesn't want LOUDBOT in #node.js
01:17:52  <tjfontaine>indeed
01:18:02  <othiym23>LOUDBOT, you're kind of a sexist jerk
01:18:02  <LOUDBOT>othiym23: USING PHP IS LIKE FUCKING AN INFLATABLE DOLL. IT MIGHT GET THE JOB DONE BUT IT'S EMBARRASSING TO WATCH.
01:18:22  <wolfeidau>o that is funny
01:18:44  <tjfontaine>LOUDBOT: TWITLAST
01:18:44  <LOUDBOT>http://twitter.com/LOUDBOT/status/386299380614971392 (apeiron/#dongtown)
01:19:05  <wolfeidau>ROFL
01:19:18  <tjfontaine>LOUDBOT: SEARCH NODE.JS
01:19:19  <LOUDBOT>tjfontaine: <maxogden:#stackvm> POTENTIAL CUSTOMER IN NODE.JS GOGOGOG
01:21:00  * st_lukejoined
01:21:21  <wolfeidau>tjfontaine: so it seems i have a lot of bodies https://gist.github.com/wolfeidau/6834170 starting to get the hang of this!
01:22:13  <tjfontaine>nice, we're going to have a "fix" for the two-byte-string stuff soon
01:24:36  * julianduquequit (Ping timeout: 245 seconds)
01:25:59  * st_lukequit (Remote host closed the connection)
01:29:51  * mikealjoined
01:34:59  <wolfeidau>Yeah so idle process is RSS-TOTALHEAP=STUFF where stuff is currently 104342272
01:39:05  * mikealquit (Quit: Leaving.)
01:46:34  * st_lukejoined
02:05:41  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:13:25  * c4miloquit (Remote host closed the connection)
02:23:55  * st_lukequit (Remote host closed the connection)
02:27:30  * inolenjoined
02:43:53  * kazuponjoined
02:54:27  * amartensquit (Quit: Leaving.)
03:00:59  * karupanerurachanged nick to zz_karupanerura
03:08:19  <trevnorris>othiym23: thanks for the info.
03:08:48  <trevnorris>othiym23: are you using the latest? I do have an unwrap, but immediately check that the return value isn't nil
03:10:05  * zz_karupanerurachanged nick to karupa64
03:11:42  * kazuponquit (Remote host closed the connection)
03:14:35  * karupa64changed nick to zz_karupa64
03:20:05  <othiym23>trevnorris: I did a git fetch --all ; git reset --hard trevor/flippin-tick-thing ; configure ; make ; make node_g
03:20:24  <othiym23>right before I captured that gist
03:20:39  <othiym23>so unless, like, you didn't push some changes, yeah, I have the latest
03:20:52  <othiym23>I'm going to upgrade my SmartOS environment and poke at it a little there
03:23:32  <trevnorris>othiym23: what's bothering me about that stack trace is that a call from a node js function would go to a node c++ method
03:23:41  <trevnorris>othiym23: but I'm not seeing where that's happening
03:23:55  * inolenquit (Quit: Leaving.)
03:24:46  * amartensjoined
03:25:34  <othiym23>trevnorris: that's why I'm going to poke at it with mdb
03:26:06  <othiym23>all I see in thread 1 on that gist is v8 stuff, except for all those JITted stackframes
03:26:45  <othiym23>and I can at least look at the v8::internal::Invoke argument pointers and see where they're pointing a little easier with the mdb node extensions
03:28:49  <othiym23>and maybe the jstack helpers will help me descramble the JIT product
03:31:46  * amartensquit (Ping timeout: 256 seconds)
03:33:51  <trevnorris>tjfontaine: i'm still getting "../src/node_zlib.cc:101: void node::ZCtx::Close(): Assertion `!write_in_progress_ && "write in progress"' failed."
03:36:27  <trevnorris>when installing using npm from master
03:37:49  * zz_karupa64changed nick to karupa64
03:42:01  <trevnorris>othiym23: just downloaded node-newrelic. how do I run the tests?
03:42:10  * Benviejoined
03:54:42  * TooTallNatejoined
03:59:22  <othiym23>trevnorris: start with CONTRIBUTING.md
03:59:34  <othiym23>trevnorris: ask me questions if that's not enough to get you up and running easily
03:59:40  <othiym23>(that will help me improve the docs)
04:00:22  <othiym23>and then to run thet tests, you'll probably want to skip straight to `make integration`
04:00:35  <othiym23>because there are failures in the unit tests that may or may not be your fault
04:01:01  <othiym23>at one point in the not too distant past (i.e. earlier this week), all the tests except one Restify test case were passing
04:01:12  <trevnorris>othiym23: the issue is that master is failing doing npm install
04:01:51  <othiym23>trevnorris: hmm... you could install using 0.11.7?
04:02:12  <trevnorris>i'll try.
04:02:19  <othiym23>I don't know if there have been any breaking ABI changes since then in the add-ons that get installed (which I think are probably just BSON and node-dtrace)
04:02:30  <trevnorris>though fwiw i'd rather do the install using the same commit that i'll be using testing for
04:02:59  <trevnorris>othiym23: you said there are native modules that need to be built?
04:03:42  <othiym23>trevnorris: just used by dependencies for the modules I instrument
04:03:53  <othiym23>the module itself is 100% crisp, pure JavaScript
04:04:27  <othiym23>and I've version-locked bunyan to the last version before it depended on node-dtrace
04:12:52  <trevnorris>othiym23: at the least i'm able to reproduce the segfault.
04:13:55  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:14:00  <othiym23>trevnorris: cool
04:14:48  * Benviequit (Ping timeout: 240 seconds)
04:17:31  * c4milojoined
04:17:41  <trevnorris>othiym23: require('request') is causing the segfault
04:17:49  <trevnorris>it's not even getting to the test.
04:20:02  <othiym23>haha rad
04:20:14  <othiym23>I figured it had to be something super basic like that
04:21:17  <othiym23>all right, I have the latest SmartOS root zone running and am upgrading all my sadly outdated packages
04:25:55  <othiym23>I have to do something really dumb to get my root zone talking to the internet that I always forget
04:26:04  <othiym23>I need to figure out how to make that config sticky
04:27:12  <trevnorris>heh
04:29:24  * amartensjoined
04:30:16  <trevnorris>othiym23: here's the stack for the last call to runAsyncListener before segfaulting: https://gist.github.com/trevnorris/6836690
04:31:28  <trevnorris>othiym23: and here's what may be causing something: var _rb = require('crypto').randomBytes;
04:32:01  <othiym23>I was just gonna ask if it was crypto causing problems
04:32:10  <trevnorris>I changed that class to get access to it's MakeCallback.
04:32:18  <trevnorris>luckily it's easy to trace
04:33:51  * amartensquit (Ping timeout: 260 seconds)
04:33:57  <trevnorris>othiym23: confirmed. crypto.randomBytes(16) causes a segfault
04:34:16  <trevnorris>strange that it wasn't happening before.
04:35:20  <trevnorris>oh, but it's only when an asyncListener is listening
04:38:31  <trevnorris>freak. that's not it either.
04:38:33  <trevnorris>wtf is going on.
04:47:50  <othiym23>all I know is that Comcast is doing an excellent job of throttling my bandwidth to GitHub
04:52:29  <trevnorris>othiym23: found it.
04:53:01  <trevnorris>horrible logic on my part.
04:53:39  <othiym23>what was the issue?
04:54:52  <trevnorris>othiym23: i'm creating a buffer, but accidently free'ing the associated memory.
04:56:03  <othiym23>yep, that'd do it
04:56:47  <trevnorris>ok, give me a minute. i'll have it fixed.
04:57:35  <othiym23>that's cool, still building Node from source under my SmartOS zone
04:57:45  * mikealjoined
04:57:49  <trevnorris>hah, ok.
04:57:50  <othiym23>even with make -j 4 and 4 cores assigned to vmware it takes a little while
04:58:06  * mikealquit (Client Quit)
04:58:09  <trevnorris>but hey, figured this out by using the async listener api. well, and some core hackery.
04:58:36  <othiym23>give a man a fish, and he'll eat for a day
04:58:45  <othiym23>give a man a grenade, and everybody will end up covered in fish guts
04:59:13  <trevnorris>hah, awesome.
05:03:15  * mikealjoined
05:03:15  * austoquit (Read error: Operation timed out)
05:03:34  * austojoined
05:06:17  <trevnorris>good freak, I hate pointers.
05:07:21  * amartensjoined
05:16:21  * wwicksjoined
05:16:31  <trevnorris>othiym23: fixed, pushed.
05:18:04  * c4miloquit (Remote host closed the connection)
05:18:05  <othiym23>cool, I'll check it out soon
05:18:43  <trevnorris>it's really easy to see when i've stayed up too late coding.
05:18:57  <trevnorris>that was horribly newbish of me.
05:28:48  * amartensquit (Quit: Leaving.)
05:29:24  <othiym23>I think there may be something slightly messed up with the domain refactor, too
05:29:33  <othiym23>let me try pulling and rebuilding based on your latest changes, though
05:31:44  <othiym23>trevnorris: fwiw, I don't get the zlib error you've been encountering on either OS X 10.8.5 or SmartOS
05:31:55  <trevnorris>oy,
05:32:09  <trevnorris>i only get it if i'm installing a ton of packages.
05:33:33  <trevnorris>othiym23: also, try clearing your npm cache
05:33:54  <trevnorris>if it's already in your cache then there's no zlib necessary
05:34:15  <trevnorris>othiym23: and it's happening on master, not just my branch
05:34:26  <othiym23>trevnorris: I was starting from a clean cache
05:34:33  <othiym23>and installed ~200 packages
05:34:51  <trevnorris>it's definitely a race condition.
05:35:33  <trevnorris>but yeah. just ran from master and got: ../src/node_zlib.cc:101: void node::ZCtx::Close(): Assertion `!write_in_progress_ && "write in progress"' failed.
05:42:04  <othiym23>trevnorris: I can confirm that that fix works for me
05:42:09  <trevnorris>coolio
05:42:19  <othiym23>there is, however, something broken now in the unit tests that wasn't before
05:42:25  <othiym23>I'll see if I can isolate what's going on
05:42:55  <othiym23>and something's defintely breaking the Redis and Restify instrumentation, but I haven't checked those against master yet
05:44:58  <trevnorris>othiym23: when I ran the restify test against master there were 2 tests failing
05:45:41  <othiym23>OK, good to know
05:45:55  <trevnorris>but that's not to say I don't expect something to be broken. the way I injected adding the listener to a handle is so precarious. it's sort of sad.
05:46:41  <trevnorris>othiym23: like this here: http://git.io/2efU1A
05:47:09  <trevnorris>i've had to trace down where all handles are being created after the js object instantiation and inject code to add the handle manually
05:47:12  <trevnorris>it's been a pain.
05:47:26  <trevnorris>freaking "net"
05:47:32  <trevnorris>why couldn't it just have been tcp and pipe
05:47:42  <trevnorris>combining the two makes it much more painful.
05:53:48  <othiym23>hmm... some of the redist tests are failing in a new way
05:54:42  <trevnorris>heh, awesome.
05:55:56  <othiym23>verifying that my tests work on SmartOS under 0.10.20 before I go to deep with this
05:56:03  <othiym23>also I appear to have a 0.8.14 regression
05:56:06  <othiym23>it's always something
05:56:59  <trevnorris>hah, awesome.
05:57:10  <trevnorris>so, the failures you're having. are they on master or on my branch
05:57:16  <trevnorris>or maybe both
05:57:22  <trevnorris>but in different ways :P
05:59:57  <trevnorris>hah, this pr is definitely my biggest so far. 2200 additions 900 deletions.
06:01:00  * paddybyersjoined
06:03:07  * sindresorhusquit (Ping timeout: 248 seconds)
06:03:33  <othiym23>trevnorris: rebuilding master to check
06:03:47  <othiym23>I should probably keep built versions of both master and your branch somewhere handy
06:04:01  * sindresorhusjoined
06:08:02  <othiym23>restify failures still happen on master
06:08:07  <othiym23>(like you said)
06:09:59  <othiym23>so jade has problems under master
06:10:49  <othiym23>all of the failures that are happening on your branch are happening on master as well, and I can see that the asyncListener polyfill is being used, so I know the right version is running
06:11:14  <othiym23>which is encouraging for you, and a bit of a pain in the ass for me, because some of these failures weren't happening last weekend
06:13:51  <trevnorris>hm. strange.
06:14:45  <trevnorris>well, right now i'm in the process of analyzing every process.nextTick() used in lib/ to see if there's a handle related event that needs to be manually tracked.
06:14:49  <trevnorris>so this might take a while. :P
06:15:13  <trevnorris>othiym23: and I still can't believe you got your polyfill to work so well.
06:15:35  <trevnorris>much of the stuff I injected isn't even exposed to js
06:15:37  <othiym23>it's pretty simple!
06:16:02  <othiym23>it's just not efficient, but so far I haven't really seen the slowdown, but I haven't been doing much in the way of load testing
06:17:37  <othiym23>what's a reliable way to cause a DNS lookup to fail fast?
06:19:46  <trevnorris>dns.lookup('localhost');
06:19:55  <trevnorris>it'll fail with TypeError: Cannot set property 'immediately' of undefined
06:20:12  * rendarjoined
06:21:00  <othiym23>let's just see about that
06:21:11  <othiym23>the test that was failing is no longer failing
06:21:15  <othiym23>I have a racy test yay
06:21:22  <othiym23>not really sure how, what it's doing is simple
06:25:17  <othiym23>I need to figure out what's up with DNS lookup on SmartOS
06:33:33  * vptr1joined
06:34:47  <trevnorris>you know, it's funny. i'm noticing how much synchronous sugar has been layered onto the asynchronous nature of node's internals.
06:34:52  * vptrquit (Read error: Connection reset by peer)
06:35:04  <trevnorris>then it's executed to make it look asynchronous.
06:35:17  * Raynosquit (Ping timeout: 248 seconds)
06:36:43  <othiym23>like what?
06:37:55  <trevnorris>so, when you setup an http server, all the work is done immediately. but to allow you to setup any listeners at the last moment it nextTicks' the fact that the socket has already been acquired for the server.
06:38:21  <trevnorris>or how streams an emitters have nothing asynchronous about them. they just use nextTick as a way to emulate that behavior.
06:38:39  <trevnorris>and when I say asynchronous, I mean like calling out to system I/O and suck.
06:38:42  <trevnorris>*such
06:39:34  <trevnorris>but if a lot of those nextTicks' were removed most of node's api would actually be synchronous, at least with the sugar api on top of the internals.
06:40:26  <trevnorris>but doubt this is making much sense. my clonazepam has kicked in and i'm fading off to wonder land.
06:40:47  * qmxquit (Remote host closed the connection)
06:41:29  <MI6>nodejs-v0.10-windows: #242 UNSTABLE windows-ia32 (8/600) windows-x64 (7/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/242/
06:41:59  <othiym23>no, I've got you
06:42:12  <othiym23>a lot of that sugar is there for consistency
06:42:17  * qmxjoined
06:42:20  <othiym23>I mean, that's why process.nextTick exists in the first place
06:42:57  <trevnorris>yeah. well hopefully in v0.13 isaacs is cool with the changes i'd like to make
06:43:03  <trevnorris>fully backwards compatible of course.
06:43:20  <trevnorris>but truly making a js binding directly to the c++ class counterparts.
06:43:34  <trevnorris>then allowing all the sugar to sit on top of that.
06:57:34  <trevnorris>othiym23: well, good news. just running the listeners, not actually doing anything in them, in the http_simple.js test only tacks on 5-8% perf loss.
06:58:05  * paddybyersquit (Quit: paddybyers)
06:58:51  <othiym23>trevnorris: one of my challenges is coming up with a benchmark that shows how much overhead the Node agent adds to a realistic app
06:59:08  <trevnorris>yeah. true that.
06:59:20  <othiym23>so far, the amount of overhead imposed by the agent appears to be ~1% unless you're doing the kind of tight-loop testing the node benchmarks do
06:59:34  <trevnorris>othiym23: well, give me a "realistic app" and i'll add a long stack trace script that'll allow them to configure how many stacks they want to keep.
07:01:56  <trevnorris>hahaha. that's awesome. just keeping the last stack trace took req/sec from 15000 to 500
07:11:55  <trevnorris>othiym23: well, i'm pretty much useless. thanks for helping me find yet another bug.
07:12:16  <othiym23>sure!
07:12:20  <othiym23>I'll keep poking at it
07:12:23  <trevnorris>thanks.
07:12:27  <othiym23>I think things are looking good!
07:14:38  <trevnorris>that's good to hear.
07:15:21  <trevnorris>this is such a substantial change to go in relatively soon before the v0.12 release. interested to see what isaacs has to say when he finally gets back.
07:15:58  <othiym23>yeah, me too
07:16:28  <othiym23>there's a lot to review in there, it might make sense to break the asyncListener and domain-removal chunks into separate PRs, even if the latter is dependent on the former
07:16:55  <trevnorris>yeah. i've at least broken up the commits that way
07:22:11  * amartensjoined
07:33:53  * paddybyersjoined
07:55:43  * hzjoined
08:01:40  * paddybyersquit (Quit: paddybyers)
08:21:32  * amartensquit (Quit: Leaving.)
08:21:41  * brsonjoined
08:32:30  * brsonquit (Ping timeout: 264 seconds)
08:33:39  * paddybyersjoined
08:36:02  * Raynosjoined
08:46:01  * paddybyersquit (Quit: paddybyers)
10:03:02  * Kakerajoined
10:32:55  * brsonjoined
10:45:37  <MI6>nodejs-v0.10: #1516 UNSTABLE smartos-x64 (2/600) osx-x64 (1/600) osx-ia32 (1/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1516/
10:54:03  * abraxasjoined
10:59:02  * abraxasquit (Ping timeout: 264 seconds)
11:11:58  * kazuponjoined
11:14:30  * brsonquit (Ping timeout: 264 seconds)
11:14:35  * inolenjoined
11:18:13  * kazuponquit (Remote host closed the connection)
11:26:21  * paddybyersjoined
11:32:18  * paddybyersquit (Quit: paddybyers)
11:49:33  * kazuponjoined
12:04:24  * bnoordhuisjoined
12:35:41  * kazuponquit (Remote host closed the connection)
12:46:59  * c4milojoined
12:56:03  <MI6>joyent/node: Ben Noordhuis v0.10 * d97ea06 : doc: add warning to fs.exists() documentation - http://git.io/KnTcxg
13:03:45  <MI6>nodejs-v0.10: #1517 UNSTABLE smartos-x64 (2/600) linux-ia32 (1/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1517/
13:10:01  * c4miloquit (Remote host closed the connection)
13:10:55  <MI6>nodejs-v0.10-windows: #243 UNSTABLE windows-ia32 (7/600) windows-x64 (8/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/243/
13:12:35  * hzquit
13:16:12  * mmaleckiquit (Quit: leaving)
13:16:32  * mmaleckijoined
13:18:56  * bnoordhuisquit (Ping timeout: 245 seconds)
13:22:06  * mmaleckiquit (Quit: leaving)
13:22:17  * mmaleckijoined
13:30:16  * paddybyersjoined
13:40:48  * kazuponjoined
13:41:23  * paddybyersquit (Quit: paddybyers)
14:02:15  * brsonjoined
14:07:34  * brsonquit (Ping timeout: 256 seconds)
14:09:12  * brsonjoined
14:21:29  * inolenquit (Quit: Leaving.)
14:39:48  * brsonquit (Ping timeout: 240 seconds)
15:11:15  * defunctzombie_zzchanged nick to defunctzombie
15:16:56  <MI6>nodejs-master: #594 UNSTABLE smartos-x64 (6/644) osx-ia32 (1/644) http://jenkins.nodejs.org/job/nodejs-master/594/
15:33:24  * paddybyersjoined
15:36:26  * mikealquit (Quit: Leaving.)
15:36:57  * hzjoined
15:43:45  * paddybyersquit (Quit: paddybyers)
15:51:01  * mikealjoined
16:07:25  * mikealquit (Quit: Leaving.)
16:09:34  * bnoordhuisjoined
16:16:40  * vptr1quit (Ping timeout: 260 seconds)
16:18:38  * wwicksquit (Quit: wwicks)
16:20:06  * wwicksjoined
16:22:43  * amartensjoined
16:23:36  * amartensquit (Read error: Connection reset by peer)
16:23:41  * amartens1joined
16:23:45  * amartens1quit (Client Quit)
16:26:24  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 38df93c : unix: revert recent FSEvent changes - http://git.io/jwQflQ
16:27:17  <tjfontaine>sigh
16:28:28  <MI6>libuv-v0.10: #119 UNSTABLE smartos (2/187) windows (4/188) http://jenkins.nodejs.org/job/libuv-v0.10/119/
16:28:51  * wwicksquit (Ping timeout: 240 seconds)
16:29:04  <indutny>bnoordhuis: that was a bit rude
16:29:10  <indutny>lets revert libev removal
16:29:16  <indutny>there was tons bugs since then
16:29:28  <indutny>and people were complaining for a year
16:31:53  <MI6>libuv-v0.10-gyp: #83 FAILURE windows-x64 (4/188) windows-ia32 (4/188) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/83/
16:31:55  <tjfontaine>indutny: re 10.9 though, the laptop I wanted to put it on is doign SOS beeps at me, which apparently means I need to reflash the firmware -- so hopefully this weekend
16:32:08  <indutny>gosh
16:32:15  <tjfontaine>MI6: ya ya, I need to pin the gyp tool, since google hates me
16:32:41  <indutny>tjfontaine: thanks, anyway
16:32:54  <indutny>I'll probably install 10.8 on my wife's MB once it'll be released
16:33:00  <indutny>and should be able to test it more after that
16:33:09  <tjfontaine>indutny: well GM is out, but they do their silly appstore shtick
16:33:20  <indutny>yeah
16:33:24  <tjfontaine>lemme see if there's a standalone download I can get you
16:33:30  <indutny>well, better not :)
16:33:45  <indutny>I don't really want to touch my wife's MB before its out
16:33:47  <indutny>haha
16:33:47  <indutny>:)
16:33:59  <tjfontaine>hehe, well it's gold-master
16:34:43  <indutny>I know I know
16:34:53  <tjfontaine>fuck it, I'll just move my laptop to it, what's the worst that could happen :)
16:35:04  <tjfontaine>I'll leave the build slave for jenkins at 10.8 for now though
16:35:48  <tjfontaine>downloading 5.29GB
16:36:28  * kazuponquit (Remote host closed the connection)
16:36:56  * kazuponjoined
16:37:35  <tjfontaine>thank god we're in the internet world and I can download at home at 3MB/s
16:38:26  <indutny>:)
16:38:33  <indutny>3mb/s ?
16:38:37  <indutny>pretty slow, man
16:38:48  <tjfontaine>not mibs MBs :)
16:38:53  <indutny>well
16:38:58  <indutny>its 5-6 mb/s in moscow
16:39:05  <indutny>and that's cheapest plan
16:39:09  <tjfontaine>sure, I could upgrade, but I'm also somewhat cheap
16:39:10  <tjfontaine>oh
16:39:13  <indutny>:)
16:39:14  <indutny>yeah
16:39:20  <indutny>I'm paying 20$ month
16:39:44  <indutny>per month*
16:39:47  <tjfontaine>lucky.
16:39:51  <indutny>yeah
16:39:58  <MI6>libuv-node-integration: #254 UNSTABLE smartos-x64 (2/600) http://jenkins.nodejs.org/job/libuv-node-integration/254/
16:40:08  <indutny>though, they seem to be blocking some parts of the internet :)
16:40:14  <tjfontaine>haha
16:40:16  <indutny>censorship is gradually rising in russia
16:40:25  <tjfontaine>that's sad
16:41:17  * kazuponquit (Ping timeout: 245 seconds)
16:41:18  <tjfontaine>lets see if can narrow down on this truncation issue on master
16:42:31  <indutny>truncation
16:43:19  <tjfontaine>ya npm is reporting shasum mismatches, and when I look at the tarballs they're truncated
16:43:32  <tjfontaine>that's when zlib isn't destructing too soon
16:44:33  <tjfontaine>Assertion failed: !write_in_progress_ && "write in progress", file ../src/node_zlib.cc, line 101, function Close
16:44:53  <tjfontaine>https://gist.github.com/tjfontaine/6843157
16:46:53  <tjfontaine>which is weird, because it sets write_in_progress_ false when it does the makecallback
16:48:22  * defunctzombiechanged nick to defunctzombie_zz
16:48:24  <indutny>ouch
16:48:50  <tjfontaine>so I'm not even sure if it's supposed to really be reaped here, but that's what's going on
16:51:05  <tjfontaine>especially since it's supposed to not be weak at this point
16:53:51  <tjfontaine>I guess this could be weakobject related
16:59:40  <tjfontaine>welp
16:59:44  <tjfontaine>that seems to be it
17:00:32  <rendar>anyone could help me to understand something in the win/pipe.c code?
17:00:41  <tjfontaine>trevnorris: to work around the zlib issue please `git revert c79d5163e530892c62b08d8b814b588220c26ec8` and see if that helps -- that's going to break your async stuff of course
17:01:09  <tjfontaine>rendar: won't know until I know what you're trying to understand :)
17:01:54  <rendar>tjfontaine: :) well basically i was wondering why RegisterWaitForSingleObject is used there
17:02:03  <rendar>line 1261
17:02:59  <tjfontaine>blah, its commit doesn't really come with a lot of information
17:03:45  <indutny>tjfontaine: well this commit looks ok to me
17:03:50  <indutny>tjfontaine: at least zlib part
17:03:56  <indutny>actually
17:03:57  <indutny>it looks good
17:04:12  <indutny>perhaps there's a bug in weakobject itself
17:04:18  <tjfontaine>yes, that's what I'm asserting
17:04:51  <tjfontaine>it's not actually doing what it says on the box, zlib shouldn't be weak at this point
17:07:56  <tjfontaine>anyway installing mavericks, bbiab
17:27:36  <bnoordhuis>is there a zlib issue?
17:29:36  <tjfontaine>in so far as the zlib context is getting GCd when it's still valid
17:29:51  <tjfontaine>and reverting WeakObject seems to rectify it, I haven't gotten too far into it
17:30:32  <bnoordhuis>oh, i suspect i know what's causing that
17:30:46  <bnoordhuis>let me try a patch real quick
17:31:01  <tjfontaine>the easiest way to reproduce it is to try and npm a bunch of stuff
17:31:19  <tjfontaine>but an --expose-gc shoudl in theory reproduce it I guess
17:34:14  <bnoordhuis>so i'm pretty sure the issue is lack of write refcounting
17:34:31  <bnoordhuis>that is, it calls MakeWeak()/ClearWeak() now rather than Ref()/Unref()
17:34:48  <bnoordhuis>that said, i'm reasonably sure i've spotted an error in the Error method
17:35:34  <bnoordhuis>well, let me check some things before i say more :)
17:36:31  <tjfontaine>I'm gonna shower, the mavericks install is taking longer than I expected, bbiab
17:37:27  * kazuponjoined
17:46:00  * kazuponquit (Ping timeout: 252 seconds)
17:49:05  <bnoordhuis>tjfontaine: https://github.com/bnoordhuis/node/compare/joyent:master...zlib-ref-counting
17:49:37  <bnoordhuis>the way node_zlib.cc deals with write req tracking is kind of crummy
17:49:59  <bnoordhuis>it relies too much on zlib.js not screwing up
17:50:17  <bnoordhuis>i'm also not 100% sure that the cleanup-after-error code in ZCtx::Error() is correct
17:51:38  <indutny>aah
17:51:46  <indutny>I overlooked that ref counting thing, actually
17:51:59  <indutny>bnoordhuis: also if's bodies are on one line in your branch
17:52:08  <indutny>seems that you're out of your style
17:52:18  <bnoordhuis>oh yeah, it's just a quickie patch
17:53:07  <MI6>libuv-master: #270 UNSTABLE windows (3/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/270/
17:54:05  * mikealjoined
18:06:08  <MI6>libuv-node-integration: #255 UNSTABLE smartos-x64 (7/644) smartos-ia32 (1/644) http://jenkins.nodejs.org/job/libuv-node-integration/255/
18:08:56  * mikealquit (Quit: Leaving.)
18:09:58  * mikealjoined
18:11:23  <bnoordhuis>simplified the refcounting thing a little
18:11:50  * kazuponjoined
18:12:42  * AvianFlujoined
18:17:02  * kazuponquit (Ping timeout: 264 seconds)
18:18:13  <MI6>joyent/libuv: Fedor Indutny master * 429bb80 : fsevents: fix clever rescheduling - http://git.io/4Caqdw
18:18:42  <tjfontaine>man, mavericks takes a while to install
18:18:53  <tjfontaine>bnoordhuis: looking
18:19:44  * AvianFluquit (Remote host closed the connection)
18:20:36  <bnoordhuis>tjfontaine: just rolled back to the previous attempt
18:21:13  <bnoordhuis>not that the second attempt is bad but the first one requires less brain power to verify
18:21:45  <bnoordhuis>it's saturday night and on saturday nights, i have a distinct lack of brain power
18:21:53  <tjfontaine>heh
18:22:07  <MI6>libuv-master: #271 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/271/
18:22:19  <trevnorris>hello all
18:22:25  <bnoordhuis>sup trevor?
18:22:26  <tjfontaine>are there other things that use this ref counting mechanism?
18:22:31  <indutny>sup trevor?
18:22:52  <trevnorris>not much. just been cleaning up and trying to harden this AsyncWrap patch.
18:23:08  <trevnorris>how about all you?
18:23:24  <bnoordhuis>tjfontaine: no, zlib was the only one
18:23:43  <MI6>libuv-master-gyp: #210 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/210/
18:23:47  <tjfontaine>k
18:24:14  <trevnorris>tjfontaine: ... reverting that would cause me much pain and anguish
18:24:24  <bnoordhuis>for that matter, i can't really put my finger on it but i'm not convinced node_zlib.cc handles error situations well
18:24:27  <tjfontaine>trevnorris: we're working on it, ben has a fix
18:24:43  <trevnorris>ah good. he always has a fix. :)
18:25:12  <trevnorris>bnoordhuis: oh, wtf. you must fixed that segfault issue at a ridiculous hour. did you get up w/ your kid and decide to fix node while you were up?
18:25:32  <bnoordhuis>trevnorris: something like that :)
18:26:14  <trevnorris>indutny: how's spdy treating you?
18:26:26  <indutny>good, mostly good
18:26:35  <indutny>I've achieved a lot during this and previous week
18:27:43  <trevnorris>coolio.
18:27:57  <tjfontaine>is there a flag/config option for npm to not try and install optional deps?
18:29:11  <indutny>tjfontaine: which reminds me… why isn't npm using spdy? :)
18:29:11  <indutny>haha
18:29:16  <indutny>probably better ask isaacs
18:30:21  <tjfontaine>heh, ya totally not my domain :)
18:31:00  <trevnorris>tjfontaine: well, not getting the segfault, but still getting some strange errors:
18:31:00  <trevnorris>error Error: ENOENT, chmod '/var/projects/tmp/npm-dies/node_modules/newrelic/node_modules/sequelize/examples/MinMax'
18:31:28  <tjfontaine>that could be a packaging thing
18:32:55  <tjfontaine>I'm mostly interested to see if I can hit the shasum/truncation again
18:34:16  <trevnorris>tjfontaine: well, just downloaded newrelic --dev, which is basically the entire npm repo, and no segfault.
18:34:26  <trevnorris>so yeah. i'd say with good confidence that fixed it.
18:34:36  <tjfontaine>bnoordhuis: I haven't been able to hit it again, lgtm so long as we can get a nice test case for it :)
18:34:46  <tjfontaine>I mean it's pretty straight forward
18:34:56  <tjfontaine>trevnorris: itym hoarders :)
18:35:06  <MI6>libuv-node-integration: #256 UNSTABLE smartos-x64 (6/644) http://jenkins.nodejs.org/job/libuv-node-integration/256/
18:35:07  <bnoordhuis>i wouldn't know how to trigger that reliably
18:35:11  <trevnorris>haha
18:36:36  <bnoordhuis>tjfontaine: honestly, i wasn't able to trigger it at all. when you said 'premature gc'ing' i know it had to be that
18:37:34  <tjfontaine>bnoordhuis: nod, I'll try and see if I can get something contrived, if not I'll land it
18:37:49  <tjfontaine>also, the fact that I can extend my laptop display to my tv with airplay is pretty awesome :)
18:37:58  <bnoordhuis>hah :)
18:40:25  <tjfontaine>also independent full screens THANK FUCKING GOD.
18:40:48  <tjfontaine>ok so what was the reason I installed this again? :)
18:43:58  <tjfontaine>oh cute, activity monitor has a new network tab with useful information
18:44:30  <tjfontaine>https://cloudup.com/cO5PtFN8wnA
18:44:53  <MI6>nodejs-master-windows: #389 UNSTABLE windows-x64 (22/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/389/
18:52:45  * defunctzombie_zzchanged nick to defunctzombie
18:56:03  * vptr1joined
19:01:44  * julianduquejoined
19:02:29  * wwicksjoined
19:03:57  <bnoordhuis>nice
19:04:15  <bnoordhuis>one thing i don't like about cloudup though
19:04:23  <bnoordhuis>it's all the javascript
19:04:49  <bnoordhuis>javascript is supposed to run on servers, that's how $DEITY intended it to be
19:05:28  <tjfontaine>heh
19:06:03  <tjfontaine>hmm test/simple/test-https-foafssl.js fails on 10.9
19:07:08  <tjfontaine>odd
19:12:39  * kazuponjoined
19:13:11  * wwicksquit (Quit: wwicks)
19:14:49  * c4milojoined
19:15:14  <tjfontaine>indutny: https://gist.github.com/tjfontaine/7594be6bc86139fafeee
19:15:23  <indutny>thanks
19:15:35  <indutny>does it crash for you?
19:15:46  <tjfontaine>yup
19:16:09  <tjfontaine>test/simple/test-fs-watch or whatever it is
19:16:50  <tjfontaine>I will recompile with debug
19:18:27  * Benviejoined
19:21:41  * kazuponquit (Ping timeout: 245 seconds)
19:23:54  * julianduquequit (Remote host closed the connection)
19:25:07  <tjfontaine>there's not a lot of extra information around this
19:28:34  <tjfontaine>indutny: any extra information I can provide you here?
19:31:52  <tjfontaine>added some lldb output https://gist.github.com/tjfontaine/7594be6bc86139fafeee#file-lldb-txt
19:34:12  <indutny>idk yet
19:37:29  * Benvie_joined
19:39:04  * Benviequit (Ping timeout: 256 seconds)
19:44:00  <rendar>when i/o completes, libuv dereferences a function pointer and call the callback -- one indirection more (e.g. 1 pointer dereferencing more) in the most used callbacks (read/write ones) would slow down things, choking bandwidth? or it won't be a bottleneck usually? i ask that just for curiosity :)
19:44:49  <bnoordhuis>rendar: probably not noticeable
19:44:59  * mralephjoined
19:45:11  <bnoordhuis>rendar: a system call takes microseconds, a pointer indirection nanoseconds
19:45:32  <indutny>tjfontaine: thanks
19:48:21  * wwicksjoined
19:50:52  * paddybyersjoined
19:55:07  <othiym23>tjfontaine: that network pane in Activity Monitor is almost enough to get me to install Mavericks on its own
19:55:38  * defunctzombiechanged nick to defunctzombie_zz
19:55:45  <tjfontaine>othiym23: inorite?
20:04:10  <othiym23>all of New Relic's tests are now passing on 0.11.8-pre / trevnorris/flippin-tick-thing except for something messed up deep in the guts of jade
20:04:27  <othiym23>maybe I will be a friend of FOSS and send jade a PR
20:14:51  * vptr1changed nick to vptr
20:14:57  * vptrquit (Changing host)
20:14:57  * vptrjoined
20:15:05  * TooTallNatejoined
20:17:48  <othiym23>tjfontaine: is there an easy way to use manta to search all of the tarballs for all the packages for something?
20:19:26  * paddybyersquit (Quit: paddybyers)
20:29:14  <rendar>bnoordhuis: i see
20:43:01  * paddybyersjoined
20:45:58  * defunctzombie_zzchanged nick to defunctzombie
21:00:12  <tjfontaine>othiym23: can you rephrase the question?
21:00:22  * ingmar5changed nick to KiNgMaR
21:03:40  * Benvie_quit (Ping timeout: 246 seconds)
21:03:50  * Benviejoined
21:16:07  * paddybyersquit (Quit: paddybyers)
21:17:04  * Benvie_joined
21:17:20  * brsonjoined
21:17:28  * Benviequit (Ping timeout: 240 seconds)
21:18:39  * kazuponjoined
21:23:28  * Kakeraquit (Ping timeout: 240 seconds)
21:23:38  * kazuponquit (Ping timeout: 264 seconds)
21:26:18  <tjfontaine>brb
21:26:22  * c4miloquit (Remote host closed the connection)
21:32:03  * paddybyersjoined
21:34:06  * c4milojoined
21:35:21  * bnoordhuisquit (Ping timeout: 240 seconds)
21:43:05  * Benviejoined
21:44:18  * Benvie_quit (Ping timeout: 256 seconds)
21:44:55  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:47:35  * EhevuTovjoined
21:53:53  * Benvie_joined
21:55:08  * Benviequit (Ping timeout: 240 seconds)
21:58:54  * rendarquit
21:59:29  * defunctzombiechanged nick to defunctzombie_zz
22:00:08  * vptrquit (Ping timeout: 240 seconds)
22:00:16  * EhevuTovquit (Quit: This computer has gone to sleep)
22:01:39  * paddybyersquit (Quit: paddybyers)
22:10:30  <othiym23>tjfontaine: I'm trying to figure out how much module code is still using http.createClient
22:11:46  * jmar777quit (Remote host closed the connection)
22:12:22  * jmar777joined
22:14:40  <tjfontaine>oh so you want to know how many npm modules are using that
22:15:43  <othiym23>yeah
22:15:56  <tjfontaine>it doesn't look like what's currently copied into manta is up to date, but I can work out a sample job for you, if you'd like
22:16:28  * jmar777quit (Ping timeout: 246 seconds)
22:17:16  <othiym23>I was just sort of curious, in the "if I wanted to bend manta to my will, how tough would that be?"
22:17:19  <othiym23>not asking you to do it
22:18:41  <tjfontaine>nod
22:19:20  * kazuponjoined
22:20:33  * brsonquit (Quit: leaving)
22:21:07  * mikealquit (Quit: Leaving.)
22:22:50  <tjfontaine>mfind --type o --name '.tgz$' /NodeCore/public/npm/express/ | head -10 | mjob create -m '(mkdir out; tar xzC out) && find out -name \*.js -exec grep -H createServer {} \+' -r 'sort | uniq -c'
22:22:58  <tjfontaine>othiym23: that's sort of what I was playing around with
22:23:48  <tjfontaine>othiym23: in the map I would probably do some bash variable substitution on $MANTA_INPUT_FILE to get the package and version info, so it lands in the output to the reduce
22:23:49  * kazuponquit (Ping timeout: 246 seconds)
22:25:10  <tjfontaine>looks pretty straight forward as far as jobs go
22:25:59  <tjfontaine>presuming you can make a decent regex to match what you want
22:26:50  * vptrjoined
22:27:45  * inolenjoined
22:28:21  <tjfontaine>could probably change that so it only extracts .js instead of find'ing and then grep -nr's
22:28:52  <tjfontaine>also hope noone is using a coffeescript loader :P
22:28:53  * inolenquit (Read error: Connection reset by peer)
22:29:12  * paddybyersjoined
22:29:37  <tjfontaine>I've wanted to do a replacement codesearch.google.com built on manta for a while
22:31:24  * hzquit
22:32:43  * inolenjoined
22:33:29  * inolenquit (Read error: Connection reset by peer)
22:33:43  * inolenjoined
22:34:48  * vptrquit (Ping timeout: 240 seconds)
22:34:50  * inolenquit (Read error: Connection reset by peer)
22:35:59  * inolenjoined
22:36:00  * inolenquit (Read error: Connection reset by peer)
22:38:17  * inolenjoined
22:38:30  <othiym23>tjfontaine: another fun application for re2!
22:38:57  <othiym23>there are some really great articles about how they did codesearch out there
22:38:59  * inolenquit (Read error: Connection reset by peer)
22:39:19  * mikealjoined
22:39:52  * inolenjoined
22:41:17  <tjfontaine>othiym23: I have a slight twist on how I want to do it for C/C++/ObjC, using libclang you can actually be pretty specific about what it is you're looking for in the AST and so then it can be "easy" to index projects and find virtual stack traces for a given query
22:41:41  * mikealquit (Client Quit)
22:42:03  * inolenquit (Read error: Connection reset by peer)
22:43:06  * inolenjoined
22:45:08  <othiym23>neat!
22:45:11  * inolenquit (Read error: Connection reset by peer)
22:45:23  <tjfontaine>anyway, if/when we get to do a manta hackathon that's one of my ideas
22:46:13  * inolenjoined
22:46:51  * inolenquit (Read error: Connection reset by peer)
22:47:50  * inolenjoined
22:50:23  * TooTallNatejoined
22:53:42  * Benviejoined
22:53:47  * AvianFlujoined
22:54:11  * Benvie_quit (Ping timeout: 245 seconds)
23:08:30  <wolfeidau>tjfontaine: I think i have found the majority of the issues with this leaking code, the fundamental issue here is indeed closures
23:12:46  * mikealjoined
23:19:55  * kazuponjoined
23:21:13  * mikealquit (Ping timeout: 246 seconds)
23:23:05  * c4miloquit (Remote host closed the connection)
23:23:24  <tjfontaine>wolfeidau: but of course
23:23:32  <tjfontaine>wolfeidau: glad you were able to find it
23:23:34  <tjfontaine>at least some of it
23:23:43  * c4milojoined
23:24:37  * kazuponquit (Ping timeout: 256 seconds)
23:25:39  <trevnorris>othiym23: that's good to hear.
23:26:27  <wolfeidau>tjfontaine: Yeah big learning experience for me, this is quite a large code base so MDB is showing was showing me a ton warning signs i really didn't full understand
23:26:27  * AvianFluquit (Ping timeout: 260 seconds)
23:27:04  <trevnorris>othiym23: still have cleanup and tests to write, but good to know it's at least working.
23:27:05  <wolfeidau>tjfontaine: I am drowing in a see of yak's basically
23:28:06  * c4miloquit (Ping timeout: 245 seconds)
23:30:17  * mikealjoined
23:58:45  * Benvie_joined
23:58:51  <MI6>libuv-master-gyp: #211 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/211/
23:58:56  * Benviequit (Ping timeout: 245 seconds)