00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  <trevnorris>wow. 45 minutes to figure out I typed er.thrownDomain as er.domainThrown :-/
00:00:10  * ircretaryjoined
00:00:16  <tjfontaine>heh
00:00:23  <tjfontaine>whish we had a statically typed language :P
00:01:39  <tjfontaine>https://github.com/tjfontaine/node/compare/v0.10 any problems with me pushing? just tooling changes
00:02:08  <tjfontaine>we're close to fully automatic steps, and we'll just let jenkins do it at that point
00:02:42  <tjfontaine>for now I still like being a human in the loop
00:03:25  * amartensquit (Quit: Leaving.)
00:04:29  <trevnorris>anyone have a moment for a quick review? https://github.com/joyent/node/pull/6096
00:05:53  <isaacs>tjfontaine: it is SO trippy to see @NodeJS tweeting about a release, and i didn't do it.
00:06:18  <isaacs>every time so far, i've had this haunting "wait a second.... did i...? how come I don't... oh, right, tj."
00:06:33  <isaacs>senility's gonna be fun.
00:07:06  <tjfontaine>haha
00:08:13  <MI6>node-review: #69 UNSTABLE osx-x64 (1/597) windows-x64 (8/597) windows-ia32 (8/597) centos-ia32 (2/597) centos-x64 (2/597) smartos-x64 (2/597) linux-ia32 (1/597) http://jenkins.nodejs.org/job/node-review/69/
00:09:27  <MI6>joyent/node: Timothy J Fontaine v0.10 * 3f1dba1 : tools: script release steps after jenkins build (+1 more commits) - http://git.io/TnqVwA
00:09:47  <tjfontaine>and isaacs can hate on my bash "style"
00:10:08  <tjfontaine>in large part it's just your code anyway
00:10:51  * bradleymeckjoined
00:12:05  <isaacs>tjfontaine: hahah, bash has no style, we all know that :)
00:12:32  <tjfontaine>too true :)
00:14:24  <isaacs>tjfontaine: minor nit: it should be using either the node user or the root user for everything on nodejs.org, though
00:14:32  <trevnorris>awesome. hidden functionality for all! yet another way to intercept all errors. ;)
00:14:33  <isaacs>tjfontaine: if you are lucky, you will not be the only one doing builds forever.
00:15:04  <tjfontaine>isaacs: that requires fixing how jenkins communicates with nodejs.org, I wasn't thrilled with the idea of it having access to node@
00:15:28  <isaacs>ahh
00:15:32  <tjfontaine>isaacs: it's a little different if/when we come up with a good solution for storing all the artifacts in manta
00:15:35  * ecr1quit (Quit: ecr1)
00:15:36  <isaacs>tjfontaine: i guess that makes sense.
00:15:40  <isaacs>yeah
00:17:28  <tjfontaine>so I think I know why jenkins has been happy for the past week or so
00:17:36  <tjfontaine>at least as far as the frontend is concerned
00:17:51  <tjfontaine>https://github.com/jenkinsci/tap-plugin/commit/9acbb140d87ce08c93bdb870056428614afe0bbe
00:18:02  <tjfontaine>we were getting DoS'd by a robot
00:18:12  <tjfontaine>because the tap plugin has a security exploit
00:18:25  <MI6>nodejs-v0.10: #1442 UNSTABLE smartos-x64 (2/597) linux-ia32 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1442/
00:19:26  * bnoordhuisquit (Ping timeout: 264 seconds)
00:20:27  * leonvvquit (Remote host closed the connection)
00:20:55  * dominictarrquit (Quit: dominictarr)
00:23:23  <isaacs>tjfontaine: whoa, what?
00:23:24  <isaacs>srsly?
00:25:11  <tjfontaine>isaacs: I haven't confirmed with the author, but that's what it seems like
00:25:33  <isaacs>wild
00:26:34  * trevnorris&
00:26:34  <LOUDBOT>THE INABILITY TO COMPREHEND SIMPLE STATEMENTS WILL ALWAYS BE A BARRIER TO YOUR ACCEPTANCE IN POLITE SOCIETY
00:26:51  <trevnorris>I know LOUDBOT, but you can deal with it.
00:30:27  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:34:38  <isaacs>LOUDBOT: twitlast
00:34:38  <LOUDBOT>http://twitter.com/LOUDBOT/status/370343217616543744 (dirk_frog/##church-of-loudbot)
00:35:48  <MI6>nodejs-v0.10-windows: #169 UNSTABLE windows-ia32 (9/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/169/
00:36:17  * LeftWing__joined
00:36:52  * LeftWingquit (Remote host closed the connection)
00:37:42  <MI6>libuv-master-gyp: #119 FAILURE windows-x64 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/119/
00:37:47  * chrisdickinsonquit (Read error: Operation timed out)
00:39:26  * AvianFluquit (Remote host closed the connection)
00:39:30  * chrisdickinsonjoined
00:39:51  * AvianFlujoined
00:41:02  * stagasquit (Ping timeout: 264 seconds)
00:41:24  * AvianFluquit (Remote host closed the connection)
00:41:52  * AvianFlujoined
00:44:28  * groundwaterquit (Quit: groundwater)
00:45:04  <isaacs>tjfontaine, bnoordhuis, trevnorris: If any of you care to lgtm https://github.com/isaacs/node/commit/0ad3d4b2b631226f64de56ceac459306d401a085 then I'll go ahead and land vm2
00:45:11  <isaacs>i'm going to try to work out how best to write a test for it
00:45:14  <isaacs>it's kind of tricky
00:46:47  * c4milojoined
00:50:15  <tjfontaine>isaacs: your code lgtm, I defer to others on the rest of vm2
00:51:16  <tjfontaine>to do this util.inspect change for buffers means I'll need to implement https://github.com/joyent/node/issues/5822
00:52:26  <isaacs>tjfontaine: the test is esay until it isn't.
00:52:32  <isaacs>tjfontaine: comes down to line-parsing.
00:52:41  <tjfontaine>isaacs: what doesn't these days :)
00:52:49  <isaacs>ohh... wait, i can just do vm direclty.
00:53:09  * TooTallNatejoined
00:53:43  * EhevuTovquit (Quit: This computer has gone to sleep)
00:58:23  <isaacs>tjfontaine: ok, adding a test, and i'm pushing it onto master.
00:59:09  <MI6>joyent/node: isaacs master * eef5527 : vm: Put back display_errors flag (+1 more commits) - http://git.io/c9aYlQ
00:59:19  <isaacs>Domenic_: ^ thanks
00:59:51  <tjfontaine>wee
01:01:27  <tjfontaine>isaacs: do we have a problem with setting a default max bufferLength in util.format?
01:01:40  <isaacs>tjfontaine: meh. i think that's fine
01:01:48  <isaacs>tjfontaine: it should probably be the default Buffer.inspect, right?
01:01:55  * TooTallNatequit (Read error: Connection reset by peer)
01:01:56  <isaacs>tjfontaine: then users can override it however they want.
01:02:23  <isaacs>Buffer.prototype.inspect = function() { return '<' + this.slice(0, 12).toString('hex') + '...>' }
01:02:26  <isaacs>or something
01:02:33  <tjfontaine>I was thinking about actually passing the options to the custom inspect (which we should anyway) and then have Buffer.prototype.inspect do the right thing with respect to it
01:03:10  <isaacs>tjfontaine: oh, ok
01:03:15  <isaacs>yeah, that's fine,too
01:03:33  <isaacs>but i don't think that Buffer.inspect should have any special privileges in that options object
01:03:49  <isaacs>ie, i don't think we should add a "maxBufferLength" option in util.inspect
01:04:02  <tjfontaine>ok, I'll do them as separate things
01:04:22  * abraxasjoined
01:04:26  <isaacs>but really, you never want to see more than the first 20 bytes or so dumped out from console.log
01:04:32  <isaacs>it's pretty uch always terrible
01:04:33  <tjfontaine>right
01:04:42  <isaacs>if you do want that, fine, overwrite the method
01:05:02  <tjfontaine>should I put a require('buffer').inspectLength?
01:05:11  <MI6>nodejs-v0.10-windows: #170 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/170/
01:05:27  <tjfontaine>oh wait
01:05:32  <tjfontaine>we have that already, it's not respected though
01:05:39  <tjfontaine>weee
01:05:41  <tjfontaine>bug fix!
01:05:45  <isaacs>huzzah!
01:07:07  * _andrewclarksonquit (Ping timeout: 250 seconds)
01:07:20  * defunctzombiechanged nick to defunctzombie_zz
01:08:16  <isaacs>also, it sucks that you can't prevent printing the display line for syntax errors without disabling it for runtime errors as well
01:08:20  <isaacs>the vm api kinda sucks
01:08:21  <isaacs>oh well
01:08:35  <isaacs>gotta run to dinner. have fun :)
01:08:54  * mikealquit (Quit: Leaving.)
01:09:23  <tjfontaine>enjoy
01:09:35  <MI6>nodejs-master: #461 UNSTABLE smartos-x64 (202/635) smartos-ia32 (108/635) osx-x64 (32/635) osx-ia32 (7/635) linux-ia32 (1/635) http://jenkins.nodejs.org/job/nodejs-master/461/
01:09:49  <tjfontaine>err
01:10:08  <tjfontaine>ah
01:10:16  <isaacs>wow
01:10:30  <tjfontaine>duplicate tests in flight
01:10:33  <tjfontaine>*jobs
01:10:34  <isaacs>ohh, ok
01:18:56  <tjfontaine>https://github.com/tjfontaine/node/compare/util-fmt-buffer
01:19:12  <othiym23>util-fat-butter
01:19:18  <othiym23>that's the mikeal version of that patch
01:19:59  <tjfontaine>hehe
01:20:09  <othiym23>tjfontaine: lgtm, not that I matter
01:21:22  <tjfontaine>you matter, just not for our policy :P
01:21:30  <othiym23>haha
01:22:23  * defunctzombie_zzchanged nick to defunctzombie
01:24:43  * bradleymeckquit (Quit: bradleymeck)
01:24:59  * bnoordhuisjoined
01:25:05  <tjfontaine>lul https://github.com/joyent/node/pull/6097
01:27:11  <othiym23>nice try, guy
01:27:13  * othiym23&
01:27:14  <LOUDBOT>JUST USE 80 GRAPHICS CARDS FOR YOUR PROCESSOR DUH
01:29:52  * bnoordhuisquit (Ping timeout: 264 seconds)
01:44:43  * inolenquit (Quit: Leaving.)
01:57:07  * jmar777quit (Remote host closed the connection)
02:31:14  * TooTallNatejoined
02:36:19  * defunctzombiechanged nick to defunctzombie_zz
02:36:52  <trevnorris>isaacs: ping
02:50:41  * defunctzombie_zzchanged nick to defunctzombie
02:55:15  <MI6>nodejs-master-windows: #257 UNSTABLE windows-x64 (18/635) windows-ia32 (22/635) http://jenkins.nodejs.org/job/nodejs-master-windows/257/
03:06:55  <mordy__>hrm, rather unrelated to uv, but how does one run node under valgrind?
03:07:06  <mordy__>seems to take about 1 minute to initialize and thereafter is extremely slow
03:41:20  <tjfontaine>mordy__: welcome to valgrind
03:41:37  <mordy__>it's slow for most stuff
03:41:44  <mordy__>but itseems exceptionally slow for node
03:42:18  <mordy__>btw are there any magic compilation options to help debug things like memory corruption?
03:42:36  <mordy__>most things have a special option to disable internal pooling
03:42:51  <tjfontaine>mordy__: personally after using UMEM_DEBUG I'll not likely be going back to valgrind
03:43:01  <mordy__>hrm, what is UMEM_DEBUG
03:43:03  * mordy__searches
03:44:03  <tjfontaine>http://ewaldertl.blogspot.com/2010/05/debugging-memory-problems-on-solaris.html
03:44:16  * st_lukequit (Remote host closed the connection)
03:44:54  <tjfontaine>there's considerably less overhead involved, and is much easier to figure out wtf is going on
03:45:07  <tjfontaine>I'd be surprised if you could notice the overhead in most cases
03:45:24  <mordy__>but then you'd have to use solaris
03:45:25  <tjfontaine>which is not the case with valgrind because of how many evil things it has to do
03:45:38  <mordy__>i once had a VM around
03:45:41  <tjfontaine>mordy__: I use smartos, but yes illumos/sunos
03:45:55  <tjfontaine>mordy__: it's pretty easy to spin up in the joyent public cloud :)
03:46:21  <mordy__>trond (a coworker) uses solaris a lot.. me.. i'm happy with osx, linux and windows
03:46:25  <mordy__>well, not "happy"
03:46:30  <mordy__>but hrm
03:46:41  <mordy__>i will look into how i can use this public cloud thingy
03:47:23  <tjfontaine>you could also get up and into an environment to debug things using `mlogin` for manta
03:47:56  <tjfontaine>per hour it's slightly more expensive than spinning up your own JPC instance, but it's much faster to jump into
03:48:30  * Apage43joined
03:52:35  <MI6>joyent/node: Timothy J Fontaine master * 2769d97 : buffer: adhere to INSPECT_MAX_BYTES - http://git.io/UpHtBw
03:55:33  * kuplatupsuquit (Read error: Operation timed out)
03:55:40  * kuplatupsujoined
03:55:58  * wolfeidauquit (Read error: Connection reset by peer)
03:56:26  * wolfeidaujoined
03:59:29  * kazuponjoined
04:03:03  * brsonquit (Quit: leaving)
04:07:41  <MI6>nodejs-master: #462 UNSTABLE smartos-x64 (206/636) smartos-ia32 (9/636) osx-x64 (6/636) osx-ia32 (5/636) linux-ia32 (5/636) linux-x64 (5/636) http://jenkins.nodejs.org/job/nodejs-master/462/
04:10:34  * c4miloquit (Remote host closed the connection)
04:20:33  * mikealjoined
04:23:34  * kuplatupsuquit (Ping timeout: 246 seconds)
04:23:55  * mordy__quit (Ping timeout: 264 seconds)
04:24:08  * mordy__joined
04:25:23  * kuplatupsujoined
04:33:15  * c4milojoined
04:38:07  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:42:58  * c4miloquit (Remote host closed the connection)
04:44:06  * bradleymeckjoined
04:45:42  <MI6>nodejs-master-windows: #258 UNSTABLE windows-x64 (23/636) windows-ia32 (23/636) http://jenkins.nodejs.org/job/nodejs-master-windows/258/
04:55:27  <tjfontaine>trevnorris: ping
05:02:50  * defunctzombiechanged nick to defunctzombie_zz
05:05:13  <tjfontaine>ircretary: tell trevnorris my inspect commit unfortunately broke test-buffer.js but I think it found a bug with StringSlice https://github.com/tjfontaine/node/compare/buffer-slice-max I should be able to try and slice more, but only get max length
05:05:13  <ircretary>tjfontaine: I'll be sure to tell trevnorris
05:05:16  * AvianFluquit (Ping timeout: 264 seconds)
05:05:29  <tjfontaine>ircretary: tell trevnorris but definitely bad tj.
05:05:29  <ircretary>tjfontaine: I'll be sure to tell trevnorris
05:06:37  * hueniversejoined
05:07:32  * AvianFlujoined
05:11:04  <trevnorris>tjfontaine: sup
05:16:46  <trevnorris>tjfontaine: i'm taking care of it.
05:17:28  <trevnorris>tjfontaine: I should have caught the issue in review. my bad.
05:18:21  <tjfontaine>you don't like my solution?
05:22:20  <trevnorris>tjfontaine: the strictness of the check is a feature, not a bug.
05:22:38  <trevnorris>tjfontaine: it should have been: this.toString('hex', 0, max)...
05:23:23  <trevnorris>I should have caught that in my review. sorry about that.
05:23:31  <tjfontaine>I'm unconvinced, since you do the MIN check in other methods
05:23:42  <tjfontaine>but whatever
05:24:26  <trevnorris>> b.asciiSlice(0, 10);
05:24:30  <trevnorris>RangeError: out of range index
05:24:39  <trevnorris>all slices throw on oob
05:24:49  <tjfontaine>ya, I don't think they should :)
05:25:01  <tjfontaine>that's why I made the change in the macro
05:25:42  <trevnorris>we have toString() as the friendly wrapper
05:27:00  <tjfontaine>I will admit there's a flaw in my use of MIN and lack of full checking, but I still think it's desirable for the API to support values larger than length
05:27:40  <tjfontaine>but I don't care strongly enough to really push the issue, it's just how I would expect things to work based on other .slice()'s in js
05:32:12  <trevnorris>I hate that slice() was made to work like Array#slice(). and I've tried to make the other methods throw if you do
05:32:32  <trevnorris>e.g. fill will throw if negative or over max.
05:33:01  <tjfontaine>then it shouldn't have been named slice :)
05:33:13  <trevnorris>hah, yeah. legacy crap I guess.
05:33:18  <tjfontaine>it's not just Array.prototype.slice that behaves that way though, string does as well
05:35:53  <trevnorris>yeah. the difference is, imho, that those are working within the v8 heap so they offer some protection if you try to access oob.
05:35:54  <trevnorris>after I found a security flaw that allowed a user to pass a negative offset to slice and grab arbitrary memory i've been of the opinion that working with raw memory needs stricter standards.
05:36:24  <trevnorris>and the user needs to know when there's been an attempt to access oob
05:37:32  * defunctzombie_zzchanged nick to defunctzombie
05:37:38  <tjfontaine>"yes" but of course, that's not what happens with (new Buffer(1))[100] :P
05:37:59  <trevnorris>heh.
05:38:21  <tjfontaine>doing the right thing on .write and .read make sense, protecting against wrap arounds from negatives also make sense
05:38:44  <tjfontaine>making a function named like an existing concept behave different, meh
05:38:59  <tjfontaine>but also, just mho
05:39:12  * mikealquit (Quit: Leaving.)
05:39:14  <tjfontaine>like an asshole, everyone has one
05:39:17  <trevnorris>hah
05:39:40  * mikealjoined
05:39:51  <trevnorris>issue with (new Buffer(1))[100] = 10; is that it'll treat the buffer as an Object and allow you to place a value at that index.
05:40:06  <trevnorris>it just won't be written to memory. and yeah. that could be confusing as hell.
05:40:30  <tjfontaine>sure, but you said 'access', which also implies read, so by your desire it shoudl also OOB
05:41:09  <tjfontaine>anyway, we just need to make test-buffer.js pass, so you land what you see fit :P
05:41:37  <tjfontaine>and I'm sorry for not running the test suite, or looking at the jenkins output :)
05:41:49  <trevnorris>eh, happens to all of us :)
05:43:36  <trevnorris>tjfontaine: also, it operates more like DataView:
05:43:41  <trevnorris>> dv.getUint8(10);
05:43:46  <trevnorris>> RangeError: Offset is outside the bounds of the DataView
05:44:24  <trevnorris>it does have the same caveat of working like an Object w/ array indexes. unfortunately not much we can do about that.
05:44:33  <tjfontaine>but .get isn't [] :)
05:44:48  <tjfontaine>it's just one of those things
05:45:36  <trevnorris>basically, imho, using any instance methods to manipulate external memory in any way should always throw on oob.
05:45:44  <trevnorris>and that's how DataView works too
05:46:10  <trevnorris>but since we have the .slice() legacy syntax to support, that's the one fail.
05:46:24  <tjfontaine>I agree in principle, but slicing doesn't imply mutation
05:47:16  <trevnorris>but it does allow raw access to the memory.
05:47:31  <trevnorris>498200b was the fix for the bug
05:47:38  <tjfontaine>I remember, I was here
05:47:51  <trevnorris>wow, seems like an eternity ago.
05:49:14  <trevnorris>ok. last point I have is that any attempt to access external memory should throw oob. dataview does it with their .get*() even though it doesn't imply mutation.
05:49:35  <trevnorris>i'll throw in the fix and we can continue the discussion tomorrow. :)
05:49:52  <trevnorris>but I really need some halo.
05:50:50  <trevnorris>tjfontaine: oh, and thanks for catching my dropping support for INSPECT_MAX_BYTES. don't know why I would have just removed it like that.
05:52:28  <tjfontaine>hehe, it was funny to walk through the steps with isaacs for it, and then make a suggestion, look at the code and go: "WTF ITS ALREADY THERE"
05:54:36  <trevnorris>haha. yeah, sorry for wasting your time on that.
05:54:56  <trevnorris>makes me want to look at the commit log and see if there's some explanation why I would have just removed it all together.
05:55:17  <tjfontaine>you probably intended to put it back, but just forgot
05:55:36  <tjfontaine>there's a "bug" in the way it works on v0.10 anyway
05:56:25  <trevnorris>oh, yeah. that was it. I had to do a massive rebase and I remember some code accidentally getting left out that was picked up in review. guess that wasn't one of them.
05:56:44  <tjfontaine>https://gist.github.com/tjfontaine/6303645
05:57:28  <trevnorris>heh, so it displays max bytes + 1 it looks like
05:57:41  <tjfontaine>yes, and doesn't get the ... calculation right
05:58:17  <trevnorris>well, guess it's not critical or anything. probably been like that for a while and noone's complained.
05:58:27  <tjfontaine>yup
05:58:37  <tjfontaine>it does its job, of not flooding you with a huge buffer
05:58:48  <tjfontaine>50 bytes is arguably too much anyway :)
06:00:00  <trevnorris>thinking about it, I should have realized there was an issue there when in repl I did a Buffer(0x3fffffff) and it crashed node while trying to create the inspect string.
06:00:26  <MI6>joyent/node: Trevor Norris master * fa89cf5 : buffer: fix inspect throw if slice length too long - http://git.io/QXOntg
06:00:28  <tjfontaine>ya, ben had a similar issue which lead me to this
06:01:47  <tjfontaine>anyway, imma sleep, have fun with halo, thanks for your time :)
06:02:02  <trevnorris>and thank you for fixing my stuff :)
06:02:03  <trevnorris>night
06:09:45  <MI6>nodejs-master: #463 UNSTABLE smartos-x64 (202/636) http://jenkins.nodejs.org/job/nodejs-master/463/
06:11:48  * bradleymeckquit (Quit: bradleymeck)
06:17:16  * bajtosjoined
06:25:15  * Somebodyjoined
06:32:35  * julianduquequit (Quit: leaving)
06:36:25  <MI6>nodejs-master-windows: #259 UNSTABLE windows-x64 (18/636) windows-ia32 (21/636) http://jenkins.nodejs.org/job/nodejs-master-windows/259/
06:55:05  <creationix>What does it mean when uv_spawn says "invalid argument" as the error
06:55:16  <creationix>all my values in the options struct look right
06:55:59  <creationix>I think it's related to options.stdio_count because when I set that to 0 it runs the child process, but later segfailts for other reasons (probably my code)
06:56:17  <creationix>but my options.stdio array has 3 items and I would like to have them hooked up
06:56:35  <creationix>(using latest stable libuv)
06:58:22  <creationix>looking at the node code, it sets it to the length of the container array https://github.com/joyent/node/blob/v0.10.17-release/src/process_wrap.cc#L99
06:59:12  <creationix>here is my code https://github.com/creationix/luv/blob/master/luv_functions.c#L1087
07:06:23  <MI6>nodejs-v0.10-windows: #171 UNSTABLE windows-ia32 (8/597) windows-x64 (7/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/171/
07:09:11  * defunctzombiechanged nick to defunctzombie_zz
07:12:30  * rendarjoined
07:29:15  <creationix>ok, looking at the libuv source I think I see the problem
07:29:33  <creationix>hmm, no I don't
07:39:33  <creationix>alright, found the assert I was failing. A more useful error message would have been nice
07:39:34  <creationix>https://github.com/joyent/libuv/blob/master/src/unix/process.c#L201-L202
08:02:58  * dominictarrjoined
08:21:57  * mikealquit (Read error: Connection reset by peer)
08:22:14  * mikealjoined
08:31:48  * mikealquit (Ping timeout: 245 seconds)
08:33:39  * mikealjoined
08:38:03  * mikealquit (Ping timeout: 245 seconds)
08:40:12  * mikealjoined
08:44:05  * mikealquit (Read error: Connection reset by peer)
08:44:24  * mikealjoined
08:46:56  * bnoordhuisjoined
08:47:59  * Somebodyquit (Remote host closed the connection)
08:50:28  * hzjoined
09:33:07  * raffikijoined
09:35:06  <bnoordhuis>who set +r on #node.js?
09:53:35  * leonvvjoined
09:59:42  <indutny>hi
10:00:50  * rendarquit (Ping timeout: 264 seconds)
10:07:02  <bnoordhuis>ho
10:09:51  * kazupon_joined
10:10:07  * kazuponquit (Read error: Connection reset by peer)
10:13:30  * rendarjoined
10:13:56  <indutny>bnoordhuis: sadly tjfontaine released v0.10 yesterday
10:14:03  <indutny>ignoring my pursuations
10:14:06  <trevnorris>bnoordhuis: morning
10:14:18  <indutny>pursuits
10:14:36  <indutny>oh whatever
10:14:44  <indutny>persuasions
10:15:02  <trevnorris>indutny: morning to you too
10:15:28  <indutny>morning :)
10:16:30  * stagasjoined
10:18:22  <bnoordhuis>trevnorris: you're up late, trevor :)
10:18:33  <bnoordhuis>indutny: why sadly?
10:18:58  <trevnorris>bnoordhuis: yup. started on a blog post and turned into a rabbit hole.
10:19:49  <indutny>bnoordhuis: I wanted to get fsevents into
10:19:55  <indutny>and release with that bug fixes
10:20:00  <indutny>s/fixes/fixed
10:20:22  <trevnorris>oy github you dumbass. now to list repos by most forks you need to search for: stars:>1
10:20:57  <trevnorris>oh, and we should have a party or something when we reach 25k stars on github :P
10:21:42  <bnoordhuis>i stopped caring about that
10:21:50  <bnoordhuis>10,000 commits however will be the party of the century
10:22:04  <bnoordhuis>okay, maybe just of the week
10:22:32  <trevnorris>awesome. didn't realize node was that close. ok, sounds good to me.
10:22:47  <bnoordhuis>indutny: i think i would've blocked that. it's a pretty big change, testing it for a few more days would be good
10:23:19  <bnoordhuis>i'm not a big fan of the "if it compiles, ship it" approach
10:23:36  <trevnorris>bnoordhuis: when you have a min, have any opposition to https://github.com/joyent/node/pull/6096 ?
10:24:01  <indutny>bnoordhuis: ook
10:24:45  <bnoordhuis>aw, more code reviews?
10:25:07  <indutny>wtf
10:25:11  <indutny>you just removed all that code? :)
10:25:40  <trevnorris>well, more like relocated it
10:25:58  <indutny>oh, damien katz is unemployed again
10:29:20  * leonvvquit (Remote host closed the connection)
10:33:08  <bnoordhuis>there's something i don't get about how v8 declares V8_EXPORT
10:33:29  <bnoordhuis>it's set to __attribute((visibility("default"))) only when BUILDING_V8_SHARED is set
10:33:47  <bnoordhuis>v8 compiles with -fvisibility-hidden so how come the static library works?
10:33:58  <bnoordhuis>err, -fvisibility=hidden
10:34:38  <bnoordhuis>i'm probably missing something - i just don't know what :)
10:37:03  * abraxasquit (Remote host closed the connection)
10:38:03  <indutny>bnoordhuis: haha :)
10:40:25  * hzquit
10:42:21  * AvianFluquit (Remote host closed the connection)
10:45:14  <MI6>nodejs-v0.10: #1443 UNSTABLE smartos-x64 (2/597) osx-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1443/
10:49:10  * hzjoined
10:49:18  * kazupon_quit (Remote host closed the connection)
10:51:22  * kazuponjoined
10:54:53  * kazuponquit (Remote host closed the connection)
11:00:38  * hzquit
11:04:18  * qmxquit (Ping timeout: 264 seconds)
11:06:36  * qmxjoined
11:17:24  <bnoordhuis>indutny: reviewed the fsevents thing
11:17:31  <indutny>thanks
11:18:18  <bnoordhuis>if you fix the nits, you can land it if you want
11:18:26  <bnoordhuis>which i asssume you do :)
11:19:44  <trevnorris>ok, almost 4:30am. probably need a couple hours of sleep.
11:19:48  <trevnorris>night guys
11:20:10  * trevnorris&
11:20:10  <LOUDBOT>WHAT KIND OF FLOUR DO YOU USE IN SAUSAGE GRAVY
11:20:28  <trevnorris>LOUDBOT: all-purpose flour
11:20:29  <LOUDBOT>trevnorris: BITCHES DON'T KNOW 'BOUT MY KILOCALORIES
11:21:44  <indutny>:)
11:22:47  <bnoordhuis>sleep tight, trevor
11:41:59  * Denmadquit (Quit: ZNC - http://znc.in)
11:53:46  * bajtosquit (Quit: bajtos)
12:01:03  * bajtosjoined
12:04:40  * bradleymeckjoined
12:27:05  <MI6>joyent/libuv: Fedor Indutny master * e0f64a8 : fsevents: use shared FSEventStream - http://git.io/xYPNtg
12:27:13  <indutny>bnoordhuis: thank you
12:30:12  * bnoordhuisquit (Ping timeout: 256 seconds)
12:30:48  * bradleymeckquit (Quit: bradleymeck)
12:32:57  <MI6>libuv-master: #180 UNSTABLE smartos (9/192) windows (4/193) http://jenkins.nodejs.org/job/libuv-master/180/
12:33:25  <MI6>libuv-master-gyp: #120 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/120/
12:35:21  <indutny>ooops
12:35:22  <MI6>joyent/libuv: Fedor Indutny master * cd2794c : fsevents: use shared FSEventStream - http://git.io/vyLY-g
12:35:24  <indutny>fogive me ben
12:37:19  * abraxasjoined
12:41:04  <MI6>libuv-master: #181 UNSTABLE smartos (10/192) osx (1/193) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/181/
12:41:37  * abraxasquit (Ping timeout: 246 seconds)
12:42:56  <MI6>libuv-node-integration: #164 FAILURE smartos-ia32 (196/636) http://jenkins.nodejs.org/job/libuv-node-integration/164/
12:44:54  <MI6>libuv-master-gyp: #121 UNSTABLE windows-x64 (3/193) smartos-ia32 (4/192) smartos-x64 (2/192) windows-ia32 (4/193) http://jenkins.nodejs.org/job/libuv-master-gyp/121/
12:57:32  * AvianFlujoined
13:05:00  <MI6>libuv-node-integration: #165 UNSTABLE smartos-ia32 (196/636) smartos-x64 (9/636) http://jenkins.nodejs.org/job/libuv-node-integration/165/
13:24:38  * rendarquit (Ping timeout: 240 seconds)
13:28:08  * piscisaureus_joined
13:29:16  * bnoordhuisjoined
13:31:57  <piscisaureus_>bnoordhuis: hey
13:32:16  <bnoordhuis>piscisaureus_: ho
13:32:17  <piscisaureus_>bnoordhuis: after you did the errno refactor, did you decide to pass around windows error codes internally
13:32:22  <piscisaureus_>(and translate at the edges?)
13:32:28  <piscisaureus_>or pass around uv error codes?
13:32:39  <bnoordhuis>piscisaureus_: almost exclusively the former
13:32:41  * c4milojoined
13:32:53  <bnoordhuis>there were a few places where that turned out to be inconvenient
13:32:59  <piscisaureus_>hm right
13:33:03  <bnoordhuis>but almost everywhere windows error codes are used internally
13:33:20  <piscisaureus_>I'm fixing a bug in process.h and I get the feeling that it is completely botched at the moment ...
13:33:23  <piscisaureus_>er, process.c
13:33:30  <bnoordhuis>what is?
13:33:58  <piscisaureus_>well, right now uv_spawn on windows will return a windows error code about half the cases
13:34:06  <piscisaureus_>and an uv error code the other half of the cases
13:34:28  * c4miloquit (Remote host closed the connection)
13:34:30  <piscisaureus_>so I did a crappy job reviewing, apparently
13:34:35  <bnoordhuis>:)
13:34:46  <piscisaureus_>and some other guy did a crappy patch L)
13:34:56  <bnoordhuis>at least you can do a good job fixing it
13:35:09  * c4milojoined
13:35:34  <piscisaureus_>I'm considering to abuse the c type system and some sed magic to find all the bugs
13:37:05  * AvianFluquit (Remote host closed the connection)
13:38:01  <bnoordhuis>warning: conversion to '__uint16_t' from 'int' may alter its value [-Wconversion] <- i'm not sure that's a useful warning, gcc...
13:38:18  <bnoordhuis>it's true when int is 16 bits
13:38:49  <bnoordhuis>but it's not like gcc runs on 16 bits architectures
13:38:50  <bnoordhuis>or libuv
13:40:59  <piscisaureus_>bnoordhuis: well - maybe just temporary
13:41:07  <piscisaureus_>struct winerr { DWORD e }
13:41:15  <piscisaureus_>inline xwinerr XGetLastError() {
13:41:15  <piscisaureus_> xwinerr r;
13:41:15  <piscisaureus_> r.e = GetLastError();
13:41:15  <piscisaureus_> return r;
13:41:23  <piscisaureus_>and then some sed crap
13:45:47  <piscisaureus_>bnoordhuis: also, uv_translate_sys_error should probably assert() when you pass in an uv error
13:46:38  <bnoordhuis>piscisaureus_: sure
13:53:19  <piscisaureus_>bnoordhuis: also: uv_dlopen -> returns -1 on failure, or an error value?
13:54:25  <bnoordhuis>piscisaureus_: -1 currently. dlopen() itself doesn't really return an error
13:54:47  <bnoordhuis>i'll probably change that to UV_ENOENT or something
13:57:24  * kellabytejoined
13:57:30  * kellabytequit (Changing host)
13:57:30  * kellabytejoined
13:57:30  * kellabytequit (Changing host)
13:57:30  * kellabytejoined
14:27:10  * jmar777joined
14:28:46  <indutny>bnoordhuis: running tests
14:28:52  <indutny>with backported libuv features
14:29:39  * mikealquit (Quit: Leaving.)
14:32:59  * bajtosquit (Quit: bajtos)
14:34:16  * mikealjoined
14:39:30  * jmar777quit (Read error: Connection reset by peer)
14:39:39  * mikealquit (Quit: Leaving.)
14:39:48  * jmar777joined
14:41:05  <MI6>joyent/libuv: Fedor Indutny v0.10 * 684e212 : fsevents: use shared FSEventStream (+2 more commits) - http://git.io/ZU4IlA
14:41:48  <indutny>bnoordhuis: mind me updating libuv in node.js v0.10?
14:42:01  <indutny>ah, that's not how it work now
14:42:07  <indutny>we need to do a libuv release first
14:42:20  <indutny>bnoordhuis: who is responsible for this?
14:45:03  <tjfontaine>I can do it
14:45:12  <indutny>good
14:45:15  <indutny>tjfontaine: please ;)
14:45:41  <tjfontaine>do you mind if it happens in a couple hours after I get to work? :)
14:46:05  * hzjoined
14:46:22  * AvianFlujoined
14:46:48  <MI6>libuv-v0.10-gyp: #72 UNSTABLE windows-x64 (5/188) windows-ia32 (3/188) smartos-x64 (2/187) smartos-ia32 (2/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/72/
14:46:53  <MI6>libuv-v0.10: #108 UNSTABLE smartos (2/187) windows (4/188) http://jenkins.nodejs.org/job/libuv-v0.10/108/
14:58:07  <MI6>libuv-node-integration: #166 UNSTABLE linux-ia32 (2/597) smartos-x64 (2/597) http://jenkins.nodejs.org/job/libuv-node-integration/166/
15:10:36  <indutny>tjfontaine: sure
15:10:37  <indutny>np
15:17:18  <MI6>nodejs-master: #464 UNSTABLE smartos-x64 (202/636) smartos-ia32 (2/636) osx-ia32 (1/636) linux-ia32 (1/636) http://jenkins.nodejs.org/job/nodejs-master/464/
15:18:54  <mordy__>hrm.. now i'm trying to figure out if there's a handle leak somewhere in my extension
15:19:28  <mordy__>does v8 have a magic option to disable its own heap so stuff can show up in valgrind?
15:21:26  * piscisaureus_quit (Ping timeout: 240 seconds)
15:24:23  <indutny>mordy__: own heap? :)
15:24:31  <indutny>you must be kidding
15:24:56  <indutny>handle leak could it happen if you'll create a lot of handles in a single handlescope
15:25:10  <indutny>and it'll eat all memory and cpu
15:25:18  <indutny>but I suspect you're talking about different thing
15:25:22  <indutny>mordy__: what's happening?
15:25:56  <mordy__>hrm, i'm not sure i'm creating that many handles -- i'd expect it all to be freed once the HandleScope goes out of exit
15:26:08  <mordy__>memory is just growing and growing and growing for each iteration
15:27:07  <mordy__>v8's handle system still has me confused
15:27:35  <mordy__>i'm more familiar with something like foo = get_foo(...); decref(foo);
15:28:20  * bnoordhuisquit (Ping timeout: 245 seconds)
15:28:44  <indutny>mordy__: does handlescope closes?
15:28:49  <indutny>i.e. are you allocating handles in loop?
15:30:32  <mordy__>indutny: i'm getting handles in a loop.. i'm not explicitly calling ::New anywhere though
15:30:50  <mordy__>and right now i have something like: HandleScope scope; for (...) { ... }
15:30:56  * hzquit (Disconnected by services)
15:30:59  <mordy__>or does each iteration need its own HandleScope
15:31:00  * hzjoined
15:31:14  <mordy__>the loop is short lived in any event
15:31:22  * mikealjoined
15:31:34  <mordy__>so it's not an event loop or anything where it's the "effective" bottom frame
15:33:36  * Domenic_quit (Excess Flood)
15:33:54  * Domenic_joined
15:34:05  <indutny>ah
15:34:06  <indutny>ok
15:40:59  * piscisaureus_joined
15:44:23  <mordy__>hrm, the only thing that *could* leak is a Persistent handle, right?
15:47:19  * raffikiquit (Ping timeout: 264 seconds)
15:48:07  <mordy__> tp->payload = Persistent<Object>::New(Object::New());
15:48:23  <mordy__>wonder if there's something wrong with that incantation
15:48:49  * mikealquit (Quit: Leaving.)
15:51:40  * groundwaterjoined
15:54:35  * paulfryzeljoined
15:55:42  <MI6>joyent/libuv: piscisaureus created branch reviewme - http://git.io/cZi-9g
15:55:49  <piscisaureus_>^-- anyone wants to review that?
15:57:43  * rendarjoined
16:01:29  <isaacs>piscisaureus_: nah, i'm sure it's fine
16:01:32  <isaacs>;P
16:01:34  * raffikijoined
16:01:52  <piscisaureus_>Ok, I'll take that as a yes
16:01:57  <piscisaureus_>after all you're a libuv committer
16:02:13  <piscisaureus_>let's make jankins chase it to be sure
16:02:49  <MI6>libuv-review: #39 UNSTABLE smartos-ia32 (8/192) linux-ia32 (6/192) windows-ia32 (6/193) osx-ia32 (6/193) windows-x64 (3/193) smartos-x64 (9/192) linux-x64 (5/192) osx-x64 (3/193) http://jenkins.nodejs.org/job/libuv-review/39/
16:03:25  <isaacs>piscisaureus_: i'm only a libuv committer by virtue of being a joyent admin
16:03:47  <isaacs>piscisaureus_: but, the code looks simple enough, and looks like it does what it says on teh tin
16:03:53  <piscisaureus_>isaacs: shhhh. Don't wake up the dogs.
16:04:18  * c4miloquit (Remote host closed the connection)
16:04:19  <piscisaureus_>:)
16:04:40  <piscisaureus_>oh shit actually
16:04:45  <piscisaureus_>I forgot to update a bunch of tests
16:05:27  * c4milojoined
16:06:40  <isaacs>right, those :)
16:11:47  <MI6>joyent/libuv: Bert Belder reviewme * f1c29a5 : process: make the 'status' parameter for exit_cb an int64_t - http://git.io/fgBy2A
16:14:11  * TooTallNatejoined
16:17:15  <MI6>libuv-review: #40 UNSTABLE smartos-ia32 (4/192) linux-ia32 (2/192) windows-ia32 (3/193) osx-ia32 (6/193) windows-x64 (3/193) smartos-x64 (7/192) linux-x64 (7/192) http://jenkins.nodejs.org/job/libuv-review/40/
16:19:13  * c4miloquit (Remote host closed the connection)
16:27:48  <mordy__>grr.. i have no way to even start figuring out how to debug this
16:29:06  <mordy__>and google is useless since you get a ton of results about leaks in javascript code
16:30:10  * paulfryzelquit (Remote host closed the connection)
16:30:19  <MI6>joyent/libuv: Bert Belder reviewme * 791a3c5 : process: make the 'status' parameter for exit_cb an int64_t - http://git.io/QOXQbw
16:30:46  * paulfryzeljoined
16:33:17  <MI6>joyent/libuv: piscisaureus created branch reviewme-for-comparison - http://git.io/v672OA
16:35:02  * paulfryzelquit (Ping timeout: 240 seconds)
16:35:44  <MI6>libuv-review: #41 UNSTABLE smartos-ia32 (2/192) linux-ia32 (7/192) windows-ia32 (3/193) osx-ia32 (3/193) windows-x64 (3/193) smartos-x64 (6/192) http://jenkins.nodejs.org/job/libuv-review/41/
16:36:31  * bajtosjoined
16:37:57  * abraxasjoined
16:38:51  <tjfontaine>piscisaureus_: could you find some time to comment on #6088 and decide if libuv unix or windows is right on whether to assert or not on a closed uv_async_send :)
16:39:04  * brsonjoined
16:39:19  <piscisaureus_>windows is right
16:39:35  <piscisaureus_>you shouldn't uv_async_send on a uv_async_t handle that might be closing
16:39:41  <piscisaureus_>you are inevitably creating a race condition
16:40:11  <piscisaureus_>if you don't want that to happen, don't close the handle
16:40:23  <piscisaureus_>or make sure to tear down the thread that might cause uv_async_send first
16:40:28  <piscisaureus_>s/cause/call/
16:41:21  <tjfontaine>you don't have to convince me, I agree, it's just that unix lets to go through without much worry :)
16:41:40  * defunctzombie_zzchanged nick to defunctzombie
16:41:44  * TooTallNatequit (Read error: Connection reset by peer)
16:41:47  <piscisaureus_>I don't understand why my patch causes all this trouble in jenkins (http://jenkins.nodejs.org/job/libuv-review/41/)
16:41:53  <piscisaureus_>whereas on my local machine all is fine
16:42:02  <piscisaureus_>on linux, too
16:42:14  * abraxasquit (Ping timeout: 240 seconds)
16:42:46  <tjfontaine>lets see what #42 has to say
16:43:11  * dominictarrquit (Quit: dominictarr)
16:43:34  <tjfontaine>oh reviewme-for-comparison is master?
16:43:49  <MI6>libuv-review: #42 UNSTABLE smartos-ia32 (2/192) windows-ia32 (3/193) windows-x64 (3/193) smartos-x64 (2/192) http://jenkins.nodejs.org/job/libuv-review/42/
16:44:27  <piscisaureus_>tjfontaine: yes
16:44:43  <piscisaureus_>tjfontaine: #41 is my patches
16:44:57  <tjfontaine>#40 was also, right?
16:45:03  <piscisaureus_>yes, but that had actual bugs
16:45:24  <piscisaureus_>and most likely #41 too but I can't figure out what
16:45:33  <piscisaureus_>also it only affects linux somehow
16:46:19  <tjfontaine>I'll kick another build of that branch
16:46:22  <piscisaureus_>cool
16:46:34  <tjfontaine>#43 is building
16:46:36  <piscisaureus_>I have to run. Be back later tonight probably
16:46:38  <piscisaureus_>thanks tjfontaine
16:46:55  <piscisaureus_>I'll keep an eye on it on my phone
16:48:37  * c4milojoined
16:50:38  <mordy__>hrm, how can i print out how much stuff v8 has allocated (either in terms of memory, or better yet, in handles)?
16:50:59  <MI6>libuv-review: #43 UNSTABLE smartos-ia32 (3/192) windows-ia32 (3/193) windows-x64 (3/193) smartos-x64 (2/192) http://jenkins.nodejs.org/job/libuv-review/43/
16:51:31  <tjfontaine>piscisaureus_: looks good, just noise the last time in the CI infra
16:52:01  * piscisaureus_quit (Ping timeout: 256 seconds)
16:54:48  <tjfontaine>mordy__: do you have a test case I can try?
16:56:41  * amartensjoined
16:57:51  <mordy__>tjfontaine: well, i have two git repos and a script to reproduce it; i can't say any of it is minimal though
16:58:39  <tjfontaine>sure, but it is reproducible
16:58:42  <tjfontaine>is it public?
17:02:57  <mordy__>yeah all stuff is public.. just the setup is kinda.. big
17:03:13  <mordy__>there's also a server.. let's see if this works on the "small" version
17:05:43  <mordy__>hrm, it does
17:06:21  <tjfontaine>is that good for your efforts, or would it still be helpful for me to investigate?
17:09:04  <mordy__>i'm making a small shellscript right now to download all the deps
17:09:15  <mordy__>it's an interesting exercise nonethheless
17:10:09  <tjfontaine>k
17:13:09  * jez0990_quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
17:13:59  * jez0990joined
17:14:59  * TooTallNatejoined
17:17:23  <MI6>nodejs-master: #465 UNSTABLE smartos-x64 (202/636) smartos-ia32 (2/636) http://jenkins.nodejs.org/job/nodejs-master/465/
17:17:28  * raffikiquit (Ping timeout: 253 seconds)
17:18:15  <tjfontaine>what the hell.
17:18:44  * ecrjoined
17:20:27  * dominictarrjoined
17:21:30  <indutny>tjfontaine: what's up with release?
17:22:09  <mordy__>oh wow.. this actually seems to work http://paste.scsys.co.uk/266213
17:33:45  <MI6>nodejs-master: #466 UNSTABLE smartos-x64 (7/636) smartos-ia32 (1/636) http://jenkins.nodejs.org/job/nodejs-master/466/
17:51:23  * brsonquit (Ping timeout: 245 seconds)
17:53:46  <MI6>libuv-master: #182 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/182/
17:55:46  <mordy__>hrm; it seems GetPropertyNames() leaks
17:55:57  <mordy__>or at least it seems the heap usage inflates whenever i call that
18:02:04  * brsonjoined
18:05:19  * bnoordhuisjoined
18:05:28  <mordy__>hrm, the further i investigate, the more the leak seems to be in GetPropertyNames
18:06:03  <trevnorris>heh, looks like I pissed a few people off. note to self, don't do a blog post at 4am. :P
18:06:58  <mordy__>yep, the leak is there
18:07:15  <MI6>libuv-node-integration: #167 UNSTABLE smartos-ia32 (2/636) smartos-x64 (8/636) http://jenkins.nodejs.org/job/libuv-node-integration/167/
18:07:48  <mordy__>http://paste.scsys.co.uk/266218
18:08:28  <mordy__>the output is basically stats.used_heap_size() over stats.total_heap_size() where V8::GetHeapStatistics(&stats)
18:12:01  <mordy__>is that the right way to get an object length anyway?
18:12:09  <tjfontaine>8350ec5d 268853 0 <anonymous> (as <anon>)
18:12:12  <tjfontaine>that's a lot of closures
18:14:24  <mordy__>hrm, let's see why
18:14:25  <tjfontaine>mordy__: and a ton of objects being held that are { cas: {} }
18:15:23  <mordy__>hrm; those objects are only created in the callback stage
18:15:32  <mordy__>the Cas object is an ObjectTemplate->NewInstance()
18:15:42  <bnoordhuis>trevnorris: what happened?
18:16:24  <mordy__>maybe it's the actual object itself which is leaking
18:16:56  <mordy__>tjfontaine: curious -- did the sh script work without issue?
18:16:57  <trevnorris>bnoordhuis: i just stayed up too late and got punchy with my wording. now i'm getting flamed for it :)
18:17:36  <tjfontaine>mordy__: mostly, bench2.js needs to be 127.0.0.1, and couchbase has broken dtrace build but I fixed that
18:17:46  <tjfontaine>mordy__: you have a lot of arrays holding the following
18:17:52  <tjfontaine>[
18:17:52  <tjfontaine> {
18:17:52  <tjfontaine> callback: function <anonymous> (as <anon>),
18:17:52  <tjfontaine> domain: null,
18:17:52  <tjfontaine> },
18:18:08  <mordy__>hrm; arrays
18:18:25  <tjfontaine>others holding [ "keybase" ]
18:20:19  * paulfryzeljoined
18:20:26  <tjfontaine>trevnorris: wade into the flame war, you get burned
18:20:52  <trevnorris>tjfontaine: i'm medium rare right now ;)
18:21:02  <trevnorris>but seriously, I knew what I was getting into
18:21:42  * c4milo_joined
18:21:47  * c4miloquit (Read error: Connection reset by peer)
18:22:00  <mordy__>hrmr.. array of [keybase]
18:22:23  * bradleymeckjoined
18:22:27  <tjfontaine>also { value: "valbase******************************" }
18:22:31  <tjfontaine>lots of those objects
18:23:13  <trevnorris>tjfontaine: think the main problem was in my tired state I assumed too much on how people would interpret what I said.
18:23:32  <mordy__>this all points to ResponseInfo.payload not being destroyed; though i've printf'd on ~ResponseInfo and it seems to be doing what it's supposed to
18:23:46  <mordy__>hrm
18:26:15  <tjfontaine>mordy__: the only addition to your script was a: for i in $(seq 1 20); do sleep 3; gcore -o core.$i $NODEPID; done -- then looking at the cores in mdb
18:28:13  <indutny>tjfontaine: ping
18:28:53  <tjfontaine>indutny: we can do the release, I just want to talk to ben about #6088 and if its a fix that maybe goes into libuv 0.10
18:29:00  <tjfontaine>"fix"
18:29:18  <indutny>ah, ok ))
18:29:19  <indutny>thanks
18:29:43  <mordy__>ah hrm
18:30:04  <mordy__>so it seems the payload object is leaking
18:30:11  <mordy__>it's being created with Persistent<Object>::New
18:30:17  <mordy__>do i also need to do a MakeWeak maybe?
18:30:25  <mordy__>considering it's being called from "global scope"
18:30:26  <groundwater>trevnorris: do you mean your callbacks and closures blog?
18:30:28  <tjfontaine>yes, if you're not holding a reference to it on purpose
18:30:30  <mordy__>(called right out of UV)
18:30:59  <tjfontaine>mordy__: does it need to be persistent, is it being sent straight to JS land and you don't need to clean up after it in C++?
18:31:19  <trevnorris>groundwater: heh, yeah. i've had to make 3 updates thus far to say what I thought I was saying.
18:31:44  <tjfontaine>mordy__: if it's really a C++ object that needs dealloc'd destructed, then yes leave it persistent and MakeWeak that delete's this (or use ObjectWrap)
18:31:45  <mordy__>hrm.. indeed. it can be local
18:31:46  <trevnorris>so, note to self, hold on to a blog post for 24 hours before making it public.
18:31:49  <groundwater>trevnorris: not sure which update i read, but i definitely learned from it
18:32:28  <groundwater>i've generally moved away from spawning closures in any sort of time-critical loop, but now there is some data to back it up
18:36:26  <mordy__>tjfontaine: hrm, i seem to have plugged the leak
18:36:35  * jmar777quit (Read error: Connection reset by peer)
18:36:37  <mordy__>so basically i made the ResponseInfo's payload non-persistent
18:36:42  <mordy__>and i gave it its own HandleScope
18:36:54  <mordy__>which seems.. nasty i guess
18:37:07  * jmar777joined
18:37:26  <tjfontaine>mordy__: glad we were able to help
18:40:05  * rendarquit (Ping timeout: 248 seconds)
18:41:12  <mordy__>tjfontaine: i think what's confusing to me now is; Persistent<Object>::New(Object::New()); // it seems the object is kept alive both by the *explicit* persistent reference _and_ the implicit HandleScope
18:41:20  <mordy__>is this correct?
18:44:21  <tjfontaine>once the HandleScope is out of scope the implicit reference should be gone
18:44:23  * LeftWing__changed nick to LeftWing
18:46:08  * hzquit
18:47:23  * bajtosquit (Quit: bajtos)
18:47:41  * EhevuTovjoined
18:49:17  <mordy__>hrm, which doesn't help if your HandleScope is at the bottom of the stack
18:51:08  <mordy__>how would one create a "Detached" handle?
18:51:35  <mordy__>or is this integral to v8 that every handle *must* have a scope
18:52:29  <tjfontaine>what do you want a detached handle to do?
18:58:19  <MI6>nodejs-master-windows: #260 UNSTABLE windows-x64 (15/636) windows-ia32 (18/636) http://jenkins.nodejs.org/job/nodejs-master-windows/260/
18:59:59  <mordy__>tjfontaine: make C++-lang own the handle for a specified duration of time until it's ready to transfer ownership back to js. assuming the handle is created from the outermost scope.. without incurring the overhead of a HandleScope (unless the overhead is trivial?)
19:00:16  <indutny>mordy__: use Persistent
19:00:20  <indutny>and .Dispose() it when done
19:00:34  <indutny>you can keep Persistent<Value> as a member of your class or structure
19:00:42  <indutny>it doesn't need to be inside handlescope
19:01:07  <tjfontaine>what indutny says, but a handlescope overhead isn't that bad, it depends on how hot the path is
19:01:12  <tjfontaine>brb lunch
19:01:15  <mordy__>ok
19:10:47  <bnoordhuis>trevnorris: 'UPDATE2: I fogot' and 'I've update the example' :)
19:12:38  <trevnorris>bnoordhuis: damn you! ;) man I really suck at my own language.
19:13:53  <mordy__>hrm, on that note.. what's the most efficient way of passing an 8 byte opaque value to-from js?
19:14:26  <mordy__>i tried to be clever and make an ObjectTemplate which does SetPointerInInternalField on 64 bit platforms
19:16:48  <bnoordhuis>mordy__: doesn't work, SetPointerInInternalField() needs an aligned pointer
19:17:13  <bnoordhuis>apart from the obvious 32 bits thing, of course
19:17:56  <bnoordhuis>if you need < 2**53 bits, then you could pack it into a double with Number::New() :)
19:18:14  * paulfryzelquit (Ping timeout: 240 seconds)
19:18:15  <mordy__>for 32 bits i just allocated a pointer
19:18:32  <bnoordhuis>kidding aside, you probably either want an External or Object::SetPointerInInternalField()
19:18:53  <mordy__>but, apparently String::NewUndetectable seems quicker
19:19:02  <indutny>I fogot?
19:19:12  <bnoordhuis>i don't know, we don't use that in node
19:19:41  <tjfontaine>oh that's kinda evil
19:19:54  <bnoordhuis>Object::SetIndexedPropertiesToExternalArrayData() works too and is probably faster still
19:20:01  <bnoordhuis>more evil too though
19:23:02  <mordy__>ah hrm
19:24:08  <tjfontaine>External is the API v8 exports for "arbitrarily wrapped data"
19:29:23  <mordy__>hrm; External is the quickest
19:30:04  <groundwater>External is probably friendliest
19:32:31  * paulfryzeljoined
19:33:43  * kevinswiberjoined
19:39:07  <mordy__>hrm, i wonder what sizeof(handle) is. just sizeof(void*) ?
19:39:42  <chrisdickinson>trevnorris: neat blog post, made me go dive in and explore what was going on
19:39:47  <chrisdickinson>also, i think i beat your primes :)
19:39:56  <trevnorris>chrisdickinson: ooh, do tell!
19:40:27  <chrisdickinson>trevnorris: well, one, if you pull genPrimes out of the loop, things move a lot faster. so i did that for both of ours. otherwise it's just some bit-twiddling
19:41:04  <chrisdickinson>https://gist.github.com/chrisdickinson/2d371c365f8bb0d9c9ab
19:41:37  <chrisdickinson>basically relying on (x / 8) === (x >>> 3), (x * 8) === (x << 3), (x % 8) === (x & 7)
19:42:09  <chrisdickinson>so i get to kill two modulos and three divs
19:42:20  <trevnorris>chrisdickinson: poop. seems I didn't explain it well enough in my post that the genPrimes() function itself was the challenge. Not the entire loop n stuff.
19:42:26  <trevnorris>but that trick is awesome
19:42:31  * trevnorrisoff to benchmark
19:43:07  <chrisdickinson>i compared 'em inside of the loop too
19:43:40  <chrisdickinson>trevnorris: not sure if you saw: https://gist.github.com/chrisdickinson/7d344ca7454adfd11a15
19:44:14  <chrisdickinson>(basically, the closure example is slower not because of allocation etc, but because it keeps v8 from inlining -- and that's where the memory usage comes from too!)
19:44:34  <chrisdickinson>(since it can't inline, it has to continue to allocate / run gc on the calls)
19:45:03  <chrisdickinson>ah! i totally flubbed that last bit about moving it out
19:45:15  <chrisdickinson>sorry about that!
19:48:11  <chrisdickinson>(also, i promise i wasn't testing yours with the process.stdout.write bits in there -- i just wanted to verify output after benching.)
19:52:27  <trevnorris>chrisdickinson: ok, those bit shifting tricks really gave it a boost. awesome job.
19:52:35  <chrisdickinson>thanks :)
19:54:43  <chrisdickinson>1 sec, i think i see one more opportunity for a speedup :)
19:59:11  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:00:26  * paulfryzelquit (Remote host closed the connection)
20:00:30  <mordy__>is there some magic compilation flag i can use to avoid all those calls to pthread_getspecific?
20:01:02  * paulfryzeljoined
20:01:32  <tjfontaine>coming from the Isolate::GetCurrent()?
20:03:20  <mordy__>hrm i'm actually not seeing Isolate::GetCurrent in the path
20:03:49  <mordy__>not sure how to make this callgrind graph to text
20:04:49  <mordy__>http://i.imgur.com/eA3pUGB.png
20:05:04  * paulfryzelquit (Ping timeout: 246 seconds)
20:05:22  <mordy__>granted it's only 2% of execution time
20:16:26  * TooTallNatejoined
20:19:07  * julianduquejoined
20:22:34  * ecrquit (Quit: ecr)
20:24:41  * st_lukejoined
20:29:16  * bradleymeckquit (Quit: bradleymeck)
20:31:52  * jmar777quit (Remote host closed the connection)
20:33:17  * ecrjoined
20:33:36  * ecrquit (Client Quit)
20:36:48  * brsonquit (Read error: Connection reset by peer)
20:37:11  * brsonjoined
20:40:57  <bnoordhuis>mordy__: yeah, that's Isolate::GetCurrent()
20:41:15  <bnoordhuis>mordy__: you can't really avoid it, not everything in v8 takes an explicit isolate argument
20:41:33  <bnoordhuis>it's better now than it used to be
20:41:53  <bnoordhuis>when the isolates stuff first landed in v8, it was spending 4-5% of its time in pthread_getspecific()
20:42:50  <trevnorris>isaacs: you around?
20:43:16  * mikealjoined
20:44:14  * brsonquit (Ping timeout: 240 seconds)
20:45:38  * brsonjoined
20:52:07  * mikealquit (Quit: Leaving.)
21:09:39  * jmar777joined
21:17:47  <othiym23>does the HTTP parser enforce a maximum length restriction on queries?
21:18:18  <othiym23>http_parser.c, node_http_parser.cc and v0.10's lib/http.js did not provide me with satisfactory answers
21:20:23  <bnoordhuis>othiym23: no
21:21:29  <othiym23>will it return a 414 if you send it, like, a 512MiB URL?
21:22:00  <ik>it'll send you home with a letter to your parents
21:23:07  <mordy__>if ou want to use the url parser function thingy
21:23:22  <mordy__>those things use uint16_t for offsets
21:23:57  <mordy__>but the parser itself just maintains lexical state
21:24:03  * rendarjoined
21:24:36  * pachetquit (Quit: ;[)
21:28:31  * c4milo_quit (Remote host closed the connection)
21:28:44  * st_lukequit (Remote host closed the connection)
21:33:16  * bnoordhuisquit (Ping timeout: 240 seconds)
21:33:57  * ecrjoined
21:53:17  * st_lukejoined
22:02:08  * jmar777quit (Remote host closed the connection)
22:12:18  * rendarquit
22:15:19  * AvianFluquit (Remote host closed the connection)
22:24:38  <tjfontaine>isaacs: https://github.com/joyent/node/pull/6098 btw
22:28:25  <mordy__>hrm, is there a magic flag to tell node to use RTLD_NOW?
22:30:53  * brsonquit (Ping timeout: 256 seconds)
22:34:47  * kevinswiberquit (Remote host closed the connection)
22:38:30  * Somebodyjoined
22:55:36  <othiym23>gonna be a BAD PERSON
22:55:43  <othiym23>puttin' util._extend RIGHT THERE IN MY CODE
23:10:24  * brsonjoined
23:12:32  * Somebodyquit (Remote host closed the connection)
23:12:52  <mordy__>hrm.. apparently one cannot inherit (in js) from a "native" class?
23:13:19  <tjfontaine>define "native"
23:13:25  <mordy__>ObjectWrap
23:13:35  <mordy__>i found this.. somewhere
23:13:41  <mordy__>http://comments.gmane.org/gmane.comp.lang.javascript.nodejs/18876
23:15:11  <tjfontaine>talk to me about what you're trying to do
23:16:40  <mordy__>tbh my javascript knowledge is rather limited (quite ironic for the stuff i've been working with). i'm trying to provide nice wrappers around *some* of my C++ entry points, while i want some others to be exposed
23:17:08  <mordy__>right now what seems to work is encapsulating the existing object - but this means defining the boilerplate for all the methods which don't really have any javascript-specific logic
23:17:27  <mordy__>btw your help earlier with finding those leaks was much appreciated
23:19:01  <tjfontaine>no problem, so what I think we should talk about is generic design of how this could work, unfortunately often there is an amount of boilerplate that will always need written for a binary addon
23:20:24  <tjfontaine>I'm going to describe what I consider the ideal design of a binary addon interface, there are other ways to achieve this, but these are my opinions
23:21:05  <tjfontaine>so, your main piece is going to be v8::External
23:22:11  <tjfontaine>you have an: Persistent<External> handle = Persistent<External>::New(External::New(library_init()));
23:22:38  <tjfontaine>or maybe instead of library_init() it may be: new CppClass()
23:23:07  * ecrquit (Quit: ecr)
23:23:19  <tjfontaine>you then handle.MakeWeak() and in the callback for that you `delete ptr` or `library_destroy(ptr)`
23:23:48  <tjfontaine>you then pass that handle up to javascript, it's a safe object to pass around, you stick that on your class you have defined in js
23:24:08  <tjfontaine>var MyLibrary = function() { this._handle = bindings.init(); }
23:24:23  <tjfontaine>then, when you want to expose a function you:
23:24:51  <tjfontaine>MyLibrary.prototyp.foo = function(bar) { return bindings.foo(this._handle, bar); };
23:25:41  <tjfontaine>so, when you `new MyLibrary()` in js, it grabs the necessary handle, and then holds a reference -- when that JS object goes out of scope your native side is notified
23:26:47  <tjfontaine>mordy__: does that wall of text make sense?
23:27:53  <mordy__>tjfontaine: it does. i'm looking at what we have right now and comparing it
23:28:29  <tjfontaine>ObjectWrap basically does this same model, but it's kinda hidden inside a world of C++ and v8 ObjectTemplate's
23:28:47  <tjfontaine>and there's no reason to do so much work in C++ when you could do most of it in JS and let the JIT help you
23:29:50  <mordy__>that's another matter of discussion -- which bits are more efficient in C++ and which are better off jit'ed
23:30:14  <tjfontaine>depends on what your library is for
23:30:26  <tjfontaine>more often than not you want to start in the JIT and push out to C++
23:31:28  <tjfontaine>consider, it's very expensive to mutate an object in C++ -- whereas the boundary jump is actually pretty cheap
23:32:16  <tjfontaine>so it's cheaper to call a function in JS to construct an object than it is to construct that object in C++ -- Assuming of course that you're constantly recreating this object in C++ in a hot path
23:33:06  <mordy__>then there's the issue of maintainability.. my goal here over our old api was to have a "single API"
23:34:49  <mordy__>so we have a FunctionTemplate we construct, point it to our ctor, and do stuff there
23:35:17  <tjfontaine>you mean, trying to reuse as much of your existing C++ as possible?
23:35:59  <mordy__>tjfontaine: that, and also not have a hunk of javascript containing complex logic to interact with another complex hunk of C++
23:36:54  * toothrchanged nick to toothrot
23:36:58  <tjfontaine>I don't think your JS should be all that complex, it should just be doing argument validation before actually doing the boundary jump
23:37:29  <tjfontaine>also, I hope your stuff doesn't use C++ exceptions ...
23:37:35  <mordy__>and that's the kinda mentality things get into when the prevailing thought is: "oh, we don't need to make it pretty. it's just a binding"
23:37:39  <mordy__>we used to, but i removed 'em
23:37:46  <tjfontaine>good.
23:38:21  <tjfontaine>it's never going to be pretty because it is a binding, but (imo) you shouldn't be exposing a native function directly to a user, my preference is that it always goes through a JS shim
23:39:00  <mordy__>but we deal a lot with complex types; i.e. it's not just "oh, pass a string and be done with it"
23:39:15  <othiym23>do any of you have a fast way to mimic Sets or object-keyed maps in pure JS?
23:39:25  <othiym23>assume for the sake of discussion that I can't just turn on WeakMaps
23:39:39  <tjfontaine>mordy__: does that mean you're doing marshalling of JS objects to C++ types?
23:40:26  <othiym23>ideally something that's faster than O(n) to check membership
23:40:49  <mordy__>tjfontaine: not marshalling per se. in C land our basic unit of operation is an lcb_<type>_cmd_t where <type> is one of several operations.. i think we have about 6 or 7 of these...
23:41:06  <tjfontaine>othiym23: I've seen some, but nothing I've used enough to suggest
23:41:38  <tjfontaine>mordy__: ok
23:41:49  <mordy__>for efficiency's sake, it's much better to allocate an array of such objects and then pass it to the API
23:41:55  <othiym23>this is one of those rare cases where I miss Ruby's object IDs
23:42:11  <mordy__>to make things more complicated, the API doesn't take an actual structure, it takes an lcb_<type>_cmd_t**
23:42:16  <othiym23>because these are Error objects, I don't want to just hash the properties or whatever, because I don't want to realize the stack until I have to
23:42:34  <tjfontaine>mordy__: actually it sounds like a pretty sane mechanism
23:43:13  <mordy__>why thank you. i was part of the team that designed it
23:44:18  <tjfontaine>so this interface is all C?
23:44:25  <mordy__>yeah. all C
23:44:38  <mordy__>to make things more amusing, we do async I/O with pluggable backends
23:44:42  <mordy__>and we have a uv interface as well
23:44:49  <tjfontaine>tjfontaine.github.io/node-addon-layer
23:45:13  * ecrjoined
23:45:40  <tjfontaine>it's not finished just yet, but you might prefer to look at C instead of C++
23:45:41  * ecrquit (Client Quit)
23:46:49  <TooTallNate>https://cloudup.com/cvWmomB2QGS
23:46:54  <TooTallNate>^ windows installer fail
23:46:56  <TooTallNate>any ideas?
23:47:29  <tjfontaine>ugh
23:47:35  <tjfontaine>what's in eventviewer?
23:48:34  <mordy__>tjfontaine: perhaps in the future (and i much prefer C over C++).. i'm currently going over a refactor of our existing stuff
23:48:35  <TooTallNate>tjfontaine: https://cloudup.com/cIDizGpP813
23:48:49  <TooTallNate>(this is XP obviously)
23:49:03  <mordy__>curious though. does that api just wrap the C++ interface, or does it (or will it) access stuff normally not available to the C API
23:49:24  <tjfontaine>TooTallNate: do you have access to the box, or is this a report from someone else?
23:49:32  <TooTallNate>tjfontaine: it's my VM
23:49:59  * mordy__wonders if california is on fire
23:50:07  <tjfontaine>mordy__: it's a wrapping of the v8 api mostly, aimed at working for v0.8+
23:50:28  <tjfontaine>TooTallNate: hrm, interesting is 0.10.17 the first to fail?
23:50:44  <TooTallNate>tjfontaine: i was on v0.10.1 before, so i'm not really sure
23:50:47  <tjfontaine>TooTallNate: specifically can you go back to say 0.10.0 and see it fail thee?
23:50:50  <tjfontaine>*there
23:51:18  <tjfontaine>TooTallNate: the first release I would have done for that would have been 10.14 I think, so 10.10 should be going back far enough
23:51:27  <TooTallNate>ok i'll try it
23:52:45  * AvianFlujoined
23:53:13  <TooTallNate>tjfontaine: same error with the v0.10.10 msi
23:53:53  <tjfontaine>TooTallNate: ok, at least it's not my WiX version that's causing your troubles
23:54:06  <tjfontaine>TooTallNate: can you fully uninstall node and try again?
23:54:17  <tjfontaine>also "reboot 3 times"
23:54:18  <TooTallNate>tjfontaine: it's in a broken state it seems, it's not even in the Add/Remove list
23:54:18  <tjfontaine>:P
23:54:27  <tjfontaine>TooTallNate: break out the registry cleaner I guess
23:54:31  <MI6>joyent/node: Timothy J Fontaine master * 546ae2e : util: pass opts to custom inspect functions - http://git.io/_XSScg
23:54:43  <isaacs>tjfontaine: minor nit: commit messages should be present-tense
23:54:51  * wolfeidauquit (Remote host closed the connection)
23:55:07  <tjfontaine>isaacs: thanks!
23:55:33  <TooTallNate>tjfontaine: i can't believe i never thought of that actually
23:55:35  <mordy__>hrm, is there much of a difference between
23:55:40  <TooTallNate>tjfontaine: passing the ctx as a second arg
23:55:56  <mordy__>this._handle.whatever and bindings.whatever.handle(..) ?
23:56:02  <TooTallNate>i was imagining a PITA migration for modules that already implement .inspect(), but this is a much better solution
23:56:13  * wolfeidaujoined
23:56:22  <mordy__>err.. bindings.whatever(this._handle,..)
23:56:24  <tjfontaine>TooTallNate: heh, hopefully I didn't berak anyone :P
23:56:51  <TooTallNate>tjfontaine: well the PITA migration was in the case of passing ctx as the *first* argument
23:56:53  <tjfontaine>mordy__: difference from what stand point
23:56:55  <TooTallNate>i.e. breaking backwards compat
23:56:58  <tjfontaine>TooTallNate: right
23:57:27  <TooTallNate>tjfontaine: so you avoided that completely from what it seems to me
23:57:30  <tjfontaine>mordy__: the former requires constructing an object in C++, the later requires storing and passing a wrapped value
23:57:55  <tjfontaine>TooTallNate: ya, it didn't even occur to me to do it any other way :)
23:58:11  <tjfontaine>TooTallNate: I wonder if people even know they get a depth argument as it is anyway
23:58:21  <TooTallNate>tjfontaine: i've never seen anyone utilize it :p
23:58:26  <TooTallNate>i never have at least
23:58:27  <TooTallNate>haha
23:58:28  <tjfontaine>exactly.
23:58:37  <TooTallNate>so maybe it would have been fine :p
23:58:37  <tjfontaine>Buffer.prototype.inspect doesn't either
23:58:38  <TooTallNate>baba
23:58:39  <TooTallNate>haha
23:59:07  <TooTallNate>tjfontaine: AND the .inspect() function wasn't even documented before your commit just now!
23:59:25  <TooTallNate>so we probably could have gotten away with it as the first arg :p but whatev's this is safer in the end
23:59:28  <tjfontaine>yup