00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:09:33  * c4miloquit (Remote host closed the connection)
00:10:00  * c4milojoined
00:12:37  * c4milo_joined
00:12:39  * c4miloquit (Remote host closed the connection)
00:13:22  * trevnorrisquit (Quit: Leaving)
00:24:34  * c4milo_quit (Remote host closed the connection)
00:25:00  * c4milojoined
00:25:27  * c4miloquit (Read error: Connection reset by peer)
00:25:46  * c4milojoined
00:34:36  * paddybyersquit (Ping timeout: 272 seconds)
00:49:21  * loladiroquit (Quit: loladiro)
01:00:35  * mikealquit (Quit: Leaving.)
01:00:41  * defunctzombie_zzchanged nick to defunctzombie
01:05:37  * c4miloquit (Remote host closed the connection)
01:06:03  * c4milojoined
01:10:57  * c4miloquit (Ping timeout: 252 seconds)
01:11:05  * c4milojoined
01:23:34  * kazuponjoined
01:24:41  * dapquit (Quit: Leaving.)
01:37:54  * abraxasjoined
01:42:27  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:49:57  * brsonquit (Ping timeout: 248 seconds)
01:53:39  * c4miloquit (Remote host closed the connection)
01:54:06  * c4milojoined
01:55:51  * kazuponquit (Remote host closed the connection)
01:58:48  * c4miloquit (Ping timeout: 252 seconds)
02:17:39  * bnoordhuisquit (Ping timeout: 256 seconds)
02:22:14  * dominictarrjoined
02:28:24  * ericktjoined
02:37:01  * brsonjoined
02:39:33  * c4milojoined
02:40:04  * kazuponjoined
02:46:15  * kazuponquit (Remote host closed the connection)
02:48:30  * brson_joined
02:49:24  * brsonquit (Ping timeout: 252 seconds)
02:51:19  * hzquit
02:55:20  * c4miloquit (Remote host closed the connection)
02:55:46  * c4milojoined
02:56:39  * c4miloquit (Read error: No route to host)
03:55:39  * mikealjoined
03:57:51  * kazuponjoined
03:59:31  * mikealquit (Client Quit)
04:06:56  * alex_rjoined
04:25:09  <tjfontaine>isaacs: I do wonder when your patience for #5149 will finally wear off
04:26:33  <MI6>joyent/node: Trevor Norris v0.10 * f0b6889 : domain: fix domain callback from MakeCallback Since _tickCallback and _t - http://git.io/xvVohA
04:28:59  * alex_rpart
04:29:53  * benoitcquit (Excess Flood)
04:32:10  * benoitcjoined
04:37:04  <isaacs>tjfontaine: years of wrestling with web browsers taught me interminable patience.
04:37:23  <tjfontaine>heh
04:38:10  * loladirojoined
04:43:14  <MI6>nodejs-v0.10: #74 UNSTABLE linux-x64 (1/568) windows-x64 (5/568) osx-ia32 (3/568) smartos-ia32 (1/568) windows-ia32 (5/568) http://jenkins.nodejs.org/job/nodejs-v0.10/74/
04:43:27  <tjfontaine>hmm
04:44:05  * kazuponquit (Read error: Connection reset by peer)
04:44:16  * kazuponjoined
04:47:01  * c4milojoined
04:50:05  * dominictarrquit (Quit: dominictarr)
04:53:26  * c4miloquit (Remote host closed the connection)
05:10:37  * c4milojoined
05:10:41  * c4miloquit (Remote host closed the connection)
05:20:11  * loladiroquit (Quit: loladiro)
05:24:48  * brson_quit (Ping timeout: 264 seconds)
05:34:45  * benoitcquit (Excess Flood)
05:39:13  * benoitcjoined
05:51:18  * qmxchanged nick to qmx|away
05:51:49  * bradleymeckjoined
05:52:59  * loladirojoined
05:55:10  * wolfeidauquit (Remote host closed the connection)
06:14:17  * loladiroquit (Quit: loladiro)
06:16:27  * trevnorrisjoined
06:35:22  * benoitcquit (Excess Flood)
06:40:43  * benoitcjoined
06:45:27  * mikealjoined
06:49:39  * paddybyersjoined
07:01:56  * wolfeidaujoined
07:19:48  * rendarjoined
07:33:49  * `3rdEdenjoined
07:41:24  * trevnorrisquit (Quit: Leaving)
07:41:31  <MI6>joyent/node: Fedor Indutny v0.10 * 28c6e42 : openssl: disable HEARTBEAT TLS extension Microsoft's IIS doesn't support - http://git.io/pJ8b9Q
07:57:46  <MI6>nodejs-v0.10: #75 UNSTABLE windows-x64 (5/568) osx-ia32 (2/568) smartos-ia32 (1/568) windows-ia32 (4/568) linux-ia32 (1/568) http://jenkins.nodejs.org/job/nodejs-v0.10/75/
08:03:48  * paddybyersquit (Ping timeout: 264 seconds)
08:05:19  * defunctzombiechanged nick to defunctzombie_zz
08:05:34  * bradleymeckquit (Quit: bradleymeck)
08:20:15  <indutny>morning
08:20:19  <indutny>isaacs: yt?
08:20:44  <indutny>anyone? :)
08:20:52  <indutny>with reviewing powers
08:28:28  * paddybyersjoined
08:30:01  * trevnorrisjoined
08:31:03  * csaohjoined
08:41:00  * CoverSlidequit (Ping timeout: 264 seconds)
08:42:13  * CoverSlidejoined
09:09:59  * dominictarrjoined
09:10:05  * dominictarrquit (Client Quit)
09:30:40  <trevnorris>indutny: how's it going?
09:41:07  * stagasquit (Ping timeout: 256 seconds)
09:46:02  <indutny>good
09:47:35  <trevnorris>think I figured out that persistent storage thing. doesn't help much through. https://gist.github.com/trevnorris/5252962
09:47:57  <trevnorris>basically it clears the Object handle the Persistent points to, but the space allocated to the persistent can be reused.
09:48:25  <trevnorris>(the relevant code is in the /* debug */ tags)
09:58:16  * dominictarrjoined
10:04:37  <trevnorris>indutny: also looks like there's some new unstable functionality in 3.17.x that might come in use later on.
10:14:41  * kazuponquit (Remote host closed the connection)
10:14:41  <indutny>what apis?
10:15:24  * philipsquit (Excess Flood)
10:17:05  * philipsjoined
10:20:11  <trevnorris>indutny: freak yeah! you can reuse a persistent: https://gist.github.com/trevnorris/5252962
10:20:40  <trevnorris>line 66, i'm just reassigning the pointer to the old one.
10:21:33  <trevnorris>ah, crap. hold on.
10:21:43  <trevnorris>man, this is what I get for programming until 3:30am...
10:21:55  <indutny>haha
10:23:42  <trevnorris>ok. updated it. still works.
10:23:53  <trevnorris>so you _can_ reuse old handles.
10:26:07  <trevnorris>that is, unless i don't understand why this example actually works (which is entirely possible =)
10:28:26  * philipsquit (Excess Flood)
10:28:53  <trevnorris>well. off to bed. glad there's someone here to my late night ramblings.
10:28:55  * trevnorrisquit (Quit: Leaving)
10:29:06  <indutny>sleep tight
10:29:51  * philipsjoined
10:41:14  * philipsquit (Excess Flood)
10:41:24  * philipsjoined
10:59:28  * philipsquit (Excess Flood)
11:01:10  * philipsjoined
11:09:24  * bnoordhuisjoined
11:09:43  * philipsquit (Excess Flood)
11:11:26  * philipsjoined
11:15:30  * Kakerajoined
11:17:28  * philipsquit (Excess Flood)
11:18:09  * sgallaghjoined
11:19:12  * philipsjoined
11:24:59  * kazuponjoined
11:25:10  * csaohquit (Quit: csaoh)
11:25:16  * philipsquit (Excess Flood)
11:26:13  <bnoordhuis>it pains me that all those tls fixes add more conditionals everywhere
11:26:59  * philipsjoined
11:29:34  * kazuponquit (Ping timeout: 245 seconds)
11:31:04  <bnoordhuis>indutny: while you're at it: https://github.com/joyent/node/issues/5145
11:32:52  <indutny>hey ben
11:32:59  <indutny>I seen it
11:33:09  <indutny>would you mind pulling this in https://github.com/joyent/node/pull/5152 ?
11:33:27  <indutny>v0.8 might be affected, but I doubt so
11:34:06  <indutny>no
11:34:09  <indutny>it doesn't affected
11:34:41  <bnoordhuis>it's not
11:34:45  <bnoordhuis>so i wonder why v0.10 is
11:36:32  <indutny>because I'm calling internallyPendingBytes
11:36:35  <indutny>after clearIn
11:36:39  <indutny>without checking ssl.error
11:37:15  <bnoordhuis>what does v0.8 do differently?
11:37:28  <bnoordhuis>it has internallyPendingBytes checks right?
11:37:31  <indutny>yep
11:37:34  <indutny>but only in clearOut
11:37:42  <indutny>0.8
11:38:15  <MI6>joyent/node: Benjamin Ruston v0.10 * 372911f : doc: addon: fix grammar - http://git.io/CGCt3Q
11:38:28  <bnoordhuis>okay. so why does v0.10 do it in clearIn?
11:38:40  <bnoordhuis>don't say streams2 or i'll cry
11:39:40  <bnoordhuis>^ that patch. fix whitespace errors, reword the commit log and change the author's name
11:39:45  <bnoordhuis>all for a single word fix
11:39:57  * abraxasquit (Remote host closed the connection)
11:40:05  <indutny>:)
11:40:16  <indutny>bnoordhuis: streams2
11:40:26  <indutny>well, its here for performance reasons
11:40:42  <indutny>anyway
11:40:44  <indutny>LGTY?
11:42:06  <bnoordhuis>well... i have a feeling all those tls fixes are bandaid for a deeper problem
11:42:26  <bnoordhuis>i'm trying to figure out what it is
11:45:20  * hzjoined
11:45:29  * defunctzombie_zzchanged nick to defunctzombie
11:45:54  * c4milojoined
11:46:00  * AvianFlujoined
11:46:03  <indutny>wut?
11:47:00  <indutny>I
11:47:07  <indutny>I'm sure its not bandaid
11:47:09  <indutny>its just my mistake
11:47:13  <indutny>but...
11:47:24  <indutny>we could probably do it in another way
11:47:47  <indutny>by calling .onerror instead of setting `error` property
11:47:54  <indutny>but I think it'll complicate a lot of logic
11:48:02  <indutny>or just break things
11:48:11  <indutny>bnoordhuis: so lets just stick with what we've now
11:48:16  <indutny>lgty I guess?
11:48:22  <bnoordhuis>the thing is, most recent bug fixes to tls.js consist of `if (condition) do_this_one_thing();`
11:48:38  <bnoordhuis>and a few lines down there's usually a `if (!condition) do_this_other_thing();`
11:48:45  <indutny>erm...
11:48:51  <bnoordhuis>fixes like that set off my programmer spider sense
11:48:52  <indutny>can you say this about this patch?
11:49:03  <indutny>bnoordhuis: ok, you can recommend anything else?
11:49:38  <bnoordhuis>i would start by identifying what changed between v0.8 and v0.10
11:49:56  <bnoordhuis>then figuring out why it's breaking things that weren't broken before
11:50:24  * csaohjoined
11:50:55  <bnoordhuis>indutny: f.e. 008ab12b7facea8ac4a718894044963e3b4ee901 <- no doubt there is a better solution
11:52:20  <indutny>ah this is fucking weird stuff
11:52:26  <indutny>and the problem is outside tls scope
11:52:33  <indutny>its just net.js hacks and streams2
11:52:41  <indutny>isaacs is already aware of it
11:52:47  <indutny>and we should fix it in 0.12
11:54:27  <MI6>nodejs-v0.10: #76 UNSTABLE linux-x64 (1/568) windows-x64 (5/568) osx-ia32 (3/568) smartos-x64 (1/568) smartos-ia32 (1/568) windows-ia32 (4/568) http://jenkins.nodejs.org/job/nodejs-v0.10/76/
11:57:22  * benoitcquit (Excess Flood)
11:57:48  * benoitcjoined
11:59:02  * roxlujoined
11:59:08  <roxlu>hi guys!
11:59:26  * c4miloquit (Remote host closed the connection)
12:00:35  <indutny>hi roxlu
12:00:39  <indutny>bnoordhuis: so lgty?
12:00:44  <indutny>idk
12:00:53  <indutny>it doesn't look like we should ignore this issue
12:20:51  <bnoordhuis>indutny: you said "its just my mistake". what commit introduced that bug?
12:21:14  <indutny>bnoordhuis: the commit which ported tls to streams2?
12:21:16  <indutny>:)
12:21:55  * stagasjoined
12:25:52  <indutny>ok, considering that I haven't heard any objections
12:25:57  <indutny>its worth pulling into
12:26:26  <bnoordhuis>why did the streams2-ification introduce that bug?
12:26:35  <MI6>joyent/node: Fedor Indutny v0.10 * ae86fa8 : tls: handle errors before calling C++ methods Calling `this.pair.encrypt - http://git.io/VTHyqA
12:26:41  <indutny>bnoordhuis: ^^
12:26:50  <indutny>bnoordhuis: because I've moved code around
12:26:56  <indutny>and added some micro-optimizations for streams2
12:27:06  <indutny>for example that pendingBytes check
12:27:16  <indutny>which was put before the error check
12:27:17  <bnoordhuis>:-/
12:27:30  <indutny>basically, my mistake
12:27:59  <indutny>That's negative thinking, sir
12:28:03  <indutny>new bugs are always introduced
12:29:02  <bnoordhuis>well, i'll grant you that the diffstat with v0.8 is <10 lines added
12:31:28  <indutny>huh?
12:31:31  <indutny>impossible
12:32:16  <indutny> lib/tls.js | 666 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------------------------------------------------------------------------------------------------------
12:32:16  <indutny> 1 file changed, 280 insertions(+), 386 deletions(-)
12:32:20  * c4milojoined
12:32:25  <indutny>git show --stat d59beb9f686578a3c34606cba294df0fb7d844a9
12:32:40  <indutny>well, I can hardly say this is 10 lines added
12:32:42  <bnoordhuis>indutny: try git diff --stat origin/v0.8..HEAD -- lib/tls.js
12:33:01  <indutny>well
12:33:03  <indutny>its not the same
12:33:08  <indutny>there're a lot of removed lines
12:33:14  <indutny>1 file changed, 427 insertions(+), 419 deletions(-)
12:33:22  <indutny>its not like insertions - deletions :)
12:33:48  <bnoordhuis>it was a firmly tongue in cheek comment
12:34:16  <indutny>oh gosh
12:34:21  <indutny>didn't get it, sorry
12:43:29  <MI6>nodejs-v0.10: #77 UNSTABLE windows-x64 (5/569) osx-ia32 (2/569) smartos-ia32 (1/569) windows-ia32 (6/569) linux-ia32 (1/569) http://jenkins.nodejs.org/job/nodejs-v0.10/77/
13:03:32  * qmx|awaychanged nick to qmx
13:07:25  * loladirojoined
13:13:40  * AvianFluquit (Read error: Connection reset by peer)
13:14:15  * AvianFlujoined
13:26:42  * mikealquit (Quit: Leaving.)
13:30:44  * Kakeraquit (Ping timeout: 246 seconds)
13:45:56  * ericktquit (Quit: erickt)
13:51:59  * qmxchanged nick to qmx|afk
14:03:47  * ericktjoined
14:06:23  * Kakerajoined
14:26:46  * c4miloquit (Remote host closed the connection)
14:27:12  * c4milojoined
14:29:00  * AvianFluquit (Read error: Connection reset by peer)
14:29:33  * AvianFlujoined
14:31:48  * c4miloquit (Ping timeout: 245 seconds)
14:32:41  * AvianFluquit (Read error: Connection reset by peer)
14:33:18  * AvianFlujoined
14:33:34  * qmx|afkchanged nick to qmx
14:39:06  * loladiroquit (Quit: loladiro)
14:44:18  * ericktquit (Quit: erickt)
14:50:52  <isaacs>good morning
14:51:07  <isaacs>bnoordhuis, indutny: yes, that fake _handle thing is utter trash.
14:51:23  <isaacs>bnoordhuis: sometimes you can't jump all the way up the mountain at once.
14:54:22  <isaacs>ircretary: tell trevnorris Check this out https://groups.google.com/forum/?hl=en&fromgroups=#!topic/v8-users/6kSAbnUb-rQ
14:54:23  <ircretary>isaacs: I'll be sure to tell trevnorris
14:54:33  <isaacs>also indutny, bnoordhuis: https://groups.google.com/forum/?hl=en&fromgroups=#!topic/v8-users/6kSAbnUb-rQ
14:55:33  * bnoordhuisquit (Ping timeout: 248 seconds)
14:56:24  * c4milojoined
14:58:35  * nsmjoined
15:12:26  * piscisaureus_joined
15:31:16  <isaacs>can one of the admins review this patch? https://github.com/joyent/node/pull/5148
15:34:47  * bnoordhuisjoined
15:39:01  <bnoordhuis>isaacs: interesting (re: v8-users post)
15:39:14  <bnoordhuis>i guess i should subscribe again
15:39:31  <isaacs>:)
15:39:44  <isaacs>i'm subscribed but i dont' ever look in that box.
15:40:01  <isaacs>i just pipe it to a gmail tag so that i can search it if i ever need to find something, since google groups' search is worthless.
15:43:37  * mikealjoined
15:47:31  * mikealquit (Client Quit)
15:48:01  <bnoordhuis>i looked at #5148 but it's all greek to me, frankly
16:02:50  * mikealjoined
16:03:42  <tjfontaine>good day good sirs
16:10:36  <bnoordhuis>sup tj?
16:10:56  <tjfontaine>if I only knew
16:11:24  * dapjoined
16:11:31  <indutny>sup
16:12:53  <tjfontaine>just thinking about #3584
16:15:48  * kazuponjoined
16:17:03  <bnoordhuis>tjfontaine: well, it's documented behavior now
16:17:08  <bnoordhuis>and it works the same on unix
16:17:23  <tjfontaine>stderr not being flushed on windows?
16:17:54  <bnoordhuis>i thought #3584 was about the blocking/non-blocking nature of stdio depending on what kind of object it is?
16:18:13  <tjfontaine>perhaps
16:18:34  * trevnorrisjoined
16:20:35  <bnoordhuis>tjfontaine: i'm intrigued now. what do you think it's about?
16:20:44  <tjfontaine>making my life hell :)
16:20:51  <bnoordhuis>i once did a course in comparative literature so my interest is piqued now
16:21:34  <bnoordhuis>also, interpretive dance. but let's not talk about that now
16:21:43  <tjfontaine>that one is more interesting ot me
16:22:07  <trevnorris>isaacs: that is freakin awesome
16:22:22  <trevnorris>bnoordhuis: it is possible to reuse a persistent handle: https://gist.github.com/trevnorris/5252962
16:22:53  <isaacs>trevnorris: the v8 thing? yeah, i thought you'd be psyched about that.
16:22:58  <isaacs>or at least, interested :)
16:22:58  <bnoordhuis>trevnorris: what line should i look at?
16:23:09  <tjfontaine>anyway I was looking yesterday at test-stream2-stderr-sync on windows, and discussed with isaacs briefly about if it's a bug in when close is raised, or the blocking issue, and then most of the night I was thinking about that as well
16:23:53  <tjfontaine>the 3584 issue anyway I mean
16:23:56  <trevnorris>bnoordhuis: line 64. i'm assigning from a pointer of a previously used persistent.
16:24:06  <trevnorris>isaacs: yeah. I want to give that guy a big hug.
16:24:39  <bnoordhuis>trevnorris: be careful what you ask for, you just might get it
16:24:43  <bnoordhuis>you know he never showers?
16:24:52  <trevnorris>lol
16:25:25  <isaacs>can we just set fire to os x ia32?
16:25:32  <tjfontaine>in which regard?
16:25:47  <bnoordhuis>trevnorris: re your question, you're assigning it the address of a stack variable
16:25:59  <bnoordhuis>trevnorris: ask me what's wrong with that
16:26:09  <trevnorris>what's wrong w/ that?
16:26:16  <bnoordhuis>EVERYTHING
16:26:21  <bnoordhuis>(cue LOUDBOT)
16:26:29  <tjfontaine>LOUDBOT: hello
16:26:42  <bnoordhuis>TWO WORDS?
16:26:49  <bnoordhuis>right
16:26:51  * tjfontaine!
16:27:19  <bnoordhuis>trevnorris: once the function returns, the address is no longer valid
16:27:27  <bnoordhuis>because the stack frame is effectively blown away
16:27:59  <isaacs>tjfontaine: well... either that or make the tests pass on it :)
16:28:06  <bnoordhuis>it's effectively a dangling pointer from then on
16:28:17  <tjfontaine>isaacs: which tests?
16:28:19  <isaacs>tjfontaine: you were talking about using a different compiler so that the writeFloat test doesn't fail?
16:28:51  <tjfontaine>both llvm-g++ and clang++ exhibit the same issue, because I think the signalling decision is made in the optzn pass not the codegen
16:28:56  <trevnorris>bnoordhuis: then why do you think that code works?
16:29:04  <isaacs>tjfontaine: writeFloat, writeDouble fail always
16:29:19  <bnoordhuis>trevnorris: i don't
16:29:28  <isaacs>tjfontaine: ok. then maybe we should just disable those tests on that os/arch
16:29:29  <trevnorris>bnoordhuis: i've compiled and tested it. it works.
16:29:38  <tjfontaine>isaacs: yes, because llvm hasn't had a release with our ( bnoordhuis )fix in it yet
16:29:45  <tjfontaine>isaacs: yes I agree with that
16:30:10  <isaacs>bnoordhuis: objections? you tend to be one of the more "anti-disabling tests" of the bunch
16:30:27  <bnoordhuis>trevnorris: in the wonderful world of c and c++ 'compiled and tested' is not the same thing as 'is correct'
16:30:38  <tjfontaine>of course buffers with nans passed among archs won't be necessarily accurate :)
16:30:38  <bnoordhuis>isaacs: what test are we talking about?
16:30:55  <isaacs>bnoordhuis: this stupid error: http://jenkins.nodejs.org/job/node-pullrequest/DESTCPU=ia32,label=osx/104/tapTestReport/test.tap-540/
16:31:00  <bnoordhuis>oh, the nan bug
16:31:06  <tjfontaine>yes
16:31:08  <isaacs>bnoordhuis: writeFloat/writeDouble failing 100% of the time on ia32 darwin
16:31:11  <isaacs>ok
16:31:22  <trevnorris>bnoordhuis: well, that's a bitch. =P well, there's something I definitely don't understand there.
16:31:33  * c4miloquit (Remote host closed the connection)
16:31:58  <bnoordhuis>tjfontaine, isaacs: we could revert the patch for now. correctness > speed and all that
16:31:59  * c4milojoined
16:32:25  <bnoordhuis>we can also work around it on ia32
16:32:36  <bnoordhuis>nan patterns aren't that hard to recognize
16:32:39  <trevnorris>bnoordhuis: this about the nan thing? we've already discussed it. it fails for every implementation on chrome, firefox, etc.
16:32:45  <bnoordhuis>if there is one, we normalize it
16:33:20  <bnoordhuis>trevnorris: yeah, it's a clang bug, not a node bug
16:33:35  <bnoordhuis>i hate appeasing buggy compilers but if it's a real issue, we can do it
16:33:35  <tjfontaine>*llvm, because llvm-g++ exhibits it as well
16:33:36  <trevnorris>yeah. so we'd agreed it won't be reverted.
16:33:49  <trevnorris>tjfontaine: correct. my bad.
16:33:54  <bnoordhuis>oh, i mean reverting for the next 12 months or so
16:34:04  <bnoordhuis>until everyone upgrades to a version of xcode that doesn't have the bug
16:34:05  <isaacs>i say we just have the test chek that the NaN pattern is one of the two
16:34:07  <isaacs>and accept them both
16:34:10  <isaacs>because whatever.
16:34:33  <tjfontaine>readFloat/Double will do the right thing either way?
16:34:41  <isaacs>well, the behavior won't change.
16:34:51  <isaacs>but the test will accept the current darwin ia32 behavir
16:35:02  <tjfontaine>I'm not entirely clear on the purpose of a signalling nan anyway
16:35:04  <isaacs>and when it upgrades, it'll keep accepting the correct behavior.
16:35:10  * mikealquit (Quit: Leaving.)
16:35:25  <isaacs>it's an edge case very few of our users care about
16:35:30  <tjfontaine>nod
16:35:31  <bnoordhuis>tjfontaine: it's a nan that when referenced triggers a machine exception
16:35:36  <tjfontaine>ah
16:35:38  <isaacs>(evidenced by the profound lack of issues posted about it)
16:35:49  <tjfontaine>well most osx users are 64bit these days anyway
16:35:52  <isaacs>in JS land, NaN is NaN
16:35:57  <isaacs>tjfontaine: true, that also
16:36:19  <tjfontaine>hell 10.8 "won't" run on a !64 machine
16:37:09  * stagasquit (Ping timeout: 252 seconds)
16:37:16  * c4miloquit (Ping timeout: 272 seconds)
16:37:21  <trevnorris>indutny: re: new apis. the RawOperationDescriptor looked interesting.
16:37:24  <tjfontaine>[not that someone couldn't launch 32bit node on purpose, or osx in 32bit mode]
16:39:57  <trevnorris>bnoordhuis: so you should only create pointers to heap variables when it's needed out of scope?
16:41:51  <bnoordhuis>trevnorris: yes. stack variables are demolished when the function returns
16:41:58  * `3rdEdenquit (Remote host closed the connection)
16:42:59  <bnoordhuis>think of it like this
16:43:09  <bnoordhuis>when you call a function, it grabs a bit of stack space for local variables
16:43:16  <bnoordhuis>when you return, that memory is freed
16:43:21  <trevnorris>bnoordhuis: cool. and does my code give away it's a stack variable, or do you just know the v8 internals?
16:43:35  <bnoordhuis>now, when you call another function, it also grabs some memory - the same memory
16:43:44  <bnoordhuis>but it writes something completely different to it
16:43:49  <bnoordhuis>and BAM, dead
16:44:05  <trevnorris>ah, interesting.
16:44:11  <bnoordhuis>trevnorris: i can see it's a stack variable because it's declared as a local in a function :)
16:44:36  <trevnorris>but what about, like, "new char". that allocates a heap variable, right?
16:44:40  <bnoordhuis>yes
16:44:46  <bnoordhuis>new and malloc alloc memory on the heap
16:44:54  <bnoordhuis>i should say "on a heap"
16:45:05  <bnoordhuis>they don't necessarily use the same heap
16:45:17  <trevnorris>if I read the v8 source correctly, Dispose does a "free(this)". does that not imply the Persistent is created on the heap?
16:45:41  <isaacs>trevnorris, tjfontaine, bnoordhuis: first to LGTM this gets a cake: https://gist.github.com/isaacs/5255880
16:45:55  <bnoordhuis>trevnorris: so here is an interesting thing about v8 Handles and Persistents
16:46:04  <bnoordhuis>they're basically raw pointers packaged in a c++ class
16:46:13  <tjfontaine>heh lgtm I can test if you'd like :)
16:46:39  <trevnorris>isaacs: heh, funny that one little byte has caused so much discussion and pain.
16:46:43  <bnoordhuis>trevnorris: the this in free(this) is what the val_ field in the Handle/Persistent points to
16:47:24  <bnoordhuis>but... that val_ field itself is allocated on the stack
16:47:52  <MI6>joyent/node: isaacs v0.10 * 61935bc : test: Accept either kind of NaN A llvm/clang bug on Darwin ia32 makes th - http://git.io/Xdq5-w
16:47:54  <isaacs>tjfontaine: HAHA! FOOLED YOU! THE CAKE IS A LIE!
16:48:02  <trevnorris>but the "this" is allocated on the heap?
16:48:15  <bnoordhuis>in this case, yes
16:48:23  <isaacs>trevnorris: yeah, for reals. of course, the difference between "don't worry about that test, it always fails" and "no tests fail ever" is a huge difference.
16:48:33  <isaacs>the last 1% is the ahrdest.
16:48:47  <tjfontaine>isaacs: oh meme lover that you are
16:50:30  <trevnorris>bnoordhuis: then Persistent::New returns val_, not "this"?
16:51:50  <bnoordhuis>trevnorris: more or less. think of a Persistent as this: struct Persistent { Handle* val_; }
16:52:14  <bnoordhuis>the Persistent is a pointer to the actual Handle
16:52:27  <bnoordhuis>Persistent::New() returns a struct Persistent
16:52:38  <bnoordhuis>when you do pers = Persistent<...>::New(...)
16:53:00  <bnoordhuis>you're assigning one Persistent to another
16:53:17  <bnoordhuis>essentially you're saying `x = 42; y = x;` but with structs
16:53:38  <bnoordhuis>and in case you're wondering, structs have copy semantics
16:53:39  <isaacs>tjfontaine: meme lover?
16:53:48  <isaacs>tjfontaine: perhaps the meme is so in me that i don't even notice it?
16:53:51  <isaacs>oh, the cake thing.
16:53:52  <isaacs>right.
16:54:01  <tjfontaine>:)
16:54:24  <bnoordhuis>trevnorris: are you with me so far? :)
16:55:03  <trevnorris>bnoordhuis: yeah. i completely understand what you're saying. what i'm having a problem with is the code's behavior.
16:55:31  <bnoordhuis>trevnorris: if it works now, that's purely by accident
16:55:42  <trevnorris>bnoordhuis: for example, in the make weak callback I do "p_saved->IsObject()" and the compiler errors with "error: no member named 'IsObject' in 'v8::Persistent<v8::Object>'"
16:56:09  <trevnorris>so that tells me that the pointer p_saved doesn't point to the handle, but to the Persistent struct.
16:56:26  <bnoordhuis>yep
16:56:34  <bnoordhuis>(*p_saved)->IsObject()
16:56:51  <trevnorris>yeah. so then wouldn't the pointer be pointed to a heap variable?
16:57:08  <bnoordhuis>no
16:57:13  <bnoordhuis>p_saved = p_obj
16:57:30  <bnoordhuis>p_obj is a variable that's local to the function
16:57:38  <bnoordhuis>once the function returns, poof, it's gone
16:57:40  <trevnorris>no. it's p_ptr = &p_obj; p_saved = p_ptr.
16:57:49  <bnoordhuis>oh, right, that's what i mean
16:57:59  <bnoordhuis>doesn't change the fact that p_obj is a local variable
17:00:40  <MI6>joyent/libuv: Bert Belder refs/tags/v0.10.2 * 83f40a4 : 2013.03.25, Version 0.10.2 (Stable) This is the first officially version - http://git.io/cEjzYg
17:00:57  <tjfontaine>DUN DUN DUN
17:01:15  <tjfontaine>first officially version.
17:01:16  <trevnorris>bnoordhuis: hm? once a Persistent is created, it will never die until Dispose is called.
17:02:08  <bnoordhuis>trevnorris: you're mixing up the Persistent and the thing it points to
17:02:18  <isaacs>piscisaureus_: just in time! i was just about to start node 0.10.2
17:02:47  <trevnorris>bnoordhuis: that's what I was bashing my head against yesterday. I kept trying to get a pointer to val_. but now I'm getting a pointer to the struct.
17:04:34  * qmxchanged nick to qmx|lunch
17:04:44  <MI6>nodejs-v0.10: #78 UNSTABLE windows-x64 (5/569) smartos-ia32 (1/569) windows-ia32 (4/569) http://jenkins.nodejs.org/job/nodejs-v0.10/78/
17:05:01  <trevnorris>bnoordhuis: sorry, what you explained does make complete sense. just having trouble reconciling it with the code.
17:05:12  <bnoordhuis>trevnorris: okay, let's go over it
17:05:17  * piscisaureus_quit (Ping timeout: 246 seconds)
17:05:22  <bnoordhuis>it's still https://gist.github.com/trevnorris/5252962 right?
17:05:38  <trevnorris>bnoordhuis: yeah
17:05:54  <bnoordhuis>okay
17:06:05  <bnoordhuis>static Persistent<Object>* p_saved <- p_saved is a pointer to a Persistent<Object>
17:06:18  <bnoordhuis>it's initially set to NULL (because it's in the .bss section)
17:06:31  <bnoordhuis>void Alloc(Handle<Object> obj, uint32_t length) {
17:06:31  <bnoordhuis>static Persistent<Object>* p_ptr;
17:06:31  <bnoordhuis>static Persistent<Object> p_obj;
17:06:44  <bnoordhuis>p_obj is a Persistent that's allocated on the stack
17:06:58  <bnoordhuis>more precisely, allocated inside the stack frame that Alloc() allocates when it's called
17:07:11  <ryah>yo what do people use for building static blogs?
17:07:24  <bnoordhuis>jekyll?
17:07:39  <bnoordhuis>trevnorris: p_ptr = &p_obj; <- you're taking the address of p_obj
17:07:52  <bnoordhuis>i.e. an address on the stack
17:08:09  <bnoordhuis> p_saved = p_ptr; <- now you're assigning it to a global variable
17:08:34  <bnoordhuis>image Alloc() returns
17:09:04  <bnoordhuis>you call some function that looks like this -> void foo() { char bigbuf[1024*1024]; memset(buf, -1, sizeof(buf)); }
17:09:31  <bnoordhuis>now when you call Alloc() again, p_saved points to an address on the stack that has been overwritten with -1s
17:09:41  <bnoordhuis>when you try to use it, BAM
17:09:47  * mikealjoined
17:09:52  <bnoordhuis>some would even say: LOUD BAM
17:09:57  <bnoordhuis>c'mon LOUDBOT
17:10:04  <tjfontaine>LOUD BAM
17:10:11  <tjfontaine>clearly he ignores you :)
17:10:26  <bnoordhuis>ignored by bots even
17:10:42  <tjfontaine>this is not your week.
17:10:51  <bnoordhuis>this is not how i imagined what the lifestyle of an OSS developer would be like
17:11:23  <bnoordhuis>trevnorris: are you still with me?
17:11:25  <tjfontaine>ignored by software? that's exactly what I expected
17:11:56  <bnoordhuis>LOUDBOT SPEAK TO ME
17:12:23  <trevnorris>bnoordhuis: refresh the page. I added two asserts in TargetCallback.
17:12:24  <ryah>bnoordhuis: a good inscription for your tombstone
17:12:37  <ryah>"this is not how i imagined what the lifestyle of an OSS developer would be like"
17:12:38  <bnoordhuis>ryah: i'm gonna live forever. fact
17:12:44  <bnoordhuis>but yes
17:13:04  <indutny>compiling v8
17:13:04  <indutny>on laptop
17:13:04  <indutny>without charger
17:13:04  <indutny>I'm in danger?
17:13:23  <trevnorris>bnoordhuis: ok, now it's updated =P
17:13:30  <trevnorris>github doesn't like my back button.
17:13:53  <bnoordhuis>trevnorris: the asserts don't prove anything
17:14:01  <bnoordhuis>you're in UB territory, anything can happen
17:14:28  <indutny>UB = undefined behaviour, right?
17:14:30  <bnoordhuis>yep
17:15:56  <isaacs>heh: https://gist.github.com/dherman/5251949
17:16:19  <trevnorris>bnoordhuis: ok. so is it compiler malfunction that I do what's there, but can't do "p_ptr = &(Persistent<Object>::New(Object::New()))"?
17:16:20  <isaacs>ryah: i use node, actually
17:16:34  <isaacs>ryah: for the static blog i build.
17:16:46  <isaacs>ryah: and rsync, and make just for fun
17:16:54  <trevnorris>because those are basically the same thing, i think.
17:17:04  <bnoordhuis>trevnorris: no, it's a programmer malfunction :)
17:17:09  <trevnorris>lol
17:17:17  <ryah>isaacs: got a project for that?
17:17:32  <isaacs>ryah: no, but i keep meaning to split it out
17:17:35  <bnoordhuis>gcc/g++ try to protect you (when you turn on -Wall -Wextra) but there's only so much they can do
17:17:46  <indutny>trevnorris: you should really keep in mind, that Peristent<...> p is on-stack variable declaration
17:17:50  <isaacs>ryah: i kinda like how the blog engine for blog.nodejs.org works, and it's basically jsut a single script and marked
17:17:55  <indutny>and its not the same as Persistent<...>* p
17:18:03  <ryah>isaacs: isnt it wordpress?
17:18:07  <indutny>which should be explicitely allocated
17:18:11  <indutny>ryah: nope
17:18:17  <isaacs>ryah: nope.
17:18:25  <isaacs>hasn't been for some time, actualy. i got fed up with them a while back.
17:18:32  <ryah>ah, good
17:18:38  <indutny>who needs comments, anyway
17:18:42  <ryah>hate wordpress too
17:18:44  <isaacs>ryah: https://github.com/joyent/node/tree/v0.10/tools/blog
17:19:16  <trevnorris>bnoordhuis: and I really want to emphasis, I don't doubt what you'r saying. just working through my own ignorance in understanding my code.
17:19:17  <bnoordhuis>though real men use sed, date and a makefile
17:19:20  <tjfontaine>if you want comments you can use something like disqus anyway
17:19:22  <isaacs>ryah: yeah, i should definitely split this out and port izs.me to it.
17:19:53  <isaacs>tjfontaine: or you can just fix whatever broken neurosis in yourself it is that makes you think you want comments.
17:19:55  <ryah>i guess ill just use jekyll... kind of annoying
17:19:57  <bnoordhuis>trevnorris: np. you'll get it eventually. i didn't understand everything all at once either
17:20:00  <ryah>but it'll work
17:20:07  <isaacs>ryah: yeah, jekyll is kinda annoying.
17:20:11  <bnoordhuis>it took me at least two minutes, i'm sure
17:20:18  <trevnorris>lol
17:20:19  <tjfontaine>isaacs: I didn't say I wanted them, I'm just saying there is a way to do it :)
17:20:32  <isaacs>ryah: i've gotten close to using it a few times, and it's always just filled me with apathy. i'm a little bit allergic to ruby
17:21:00  <tjfontaine>I have used ikiwiki in the past
17:21:04  <isaacs>ryah: actually, i think i wrote this node-blog-gen thing because i got annoyed trying to figure out hwo to do jekyll
17:21:24  <isaacs>ryah: i figure if a 200 line node script can do it, maybe i don't need to learn a new tool.
17:21:46  <bnoordhuis>trevnorris: what helps is writing some assembly
17:22:16  <bnoordhuis>i learned c64 and 8086 asm before i learned c. it helped quite a bit
17:22:42  <tjfontaine>c64 asm, what a world
17:23:19  <indutny>bnoordhuis: same on my side
17:23:25  <indutny>I learned assembly before C
17:23:30  <indutny>helps a lot
17:23:53  <trevnorris>yeah. unfortunately i'm going from js to c++.
17:24:10  <bnoordhuis>trevnorris: apt-get install nasm
17:24:29  <indutny>bnoordhuis: hehe
17:24:32  <indutny>I've better advice
17:24:54  <bnoordhuis>i admit it's throwing people in the deep end :)
17:25:07  <indutny>wget http://download.intel.com/products/processor/manual/325462.pdf
17:25:18  <indutny>and read until you'll figure out things
17:25:23  <bnoordhuis>i wish i had that back in the day
17:25:27  <indutny>yeah
17:25:28  <indutny>I had one
17:25:30  <indutny>in paper
17:25:58  <bnoordhuis>i mostly figured it out from snippets i downloaded off BBSs
17:26:03  <indutny>not for 64bit processors, though
17:26:03  <indutny>my father's friend was obsessed with finding bugs in CPUs
17:26:04  <indutny>actually, hi found few
17:26:05  <indutny>which was causing reboots (generally)
17:26:19  <indutny>oh, I've missed time of BBSs
17:26:30  <indutny>sadly
17:26:41  <indutny>but I remember times where we was connecting COM-ports to create networks
17:26:41  <bnoordhuis>don't worry, it was mostly crappy
17:26:50  <indutny>that was fun
17:27:14  <trevnorris>heh, after years of working web ux, never thought i'd even consider programming in asm.
17:27:31  <bnoordhuis>indutny: does your father's friend have one or more errata to his name?
17:27:33  <tjfontaine>goodriddance to webui :)
17:27:40  <isaacs>bnoordhuis, trevnorris: Suggestion from rmustacc that we use libumem for the backing slab allocation stuff, and bundle on platforms that lack it natively
17:27:52  <tjfontaine>https://github.com/gburd/libumem
17:27:52  <isaacs>apparently riak does this.
17:27:54  <indutny>bnoordhuis: nope :)
17:28:07  <indutny>isaacs: I'm doing it from other side
17:28:12  <bnoordhuis>ah, too bad. that's something i'd like to accomplish some day
17:28:27  <indutny>isaacs: I would like small buffers to be allocated in v8 heap
17:28:29  <indutny>and managed by it
17:28:35  <indutny>working towards it
17:28:37  <bnoordhuis>isaacs: well... maybe. i benchmarked jemalloc and that other one a while ago and they were quite a bit slower than glibc
17:28:49  * kazuponquit (Remote host closed the connection)
17:28:53  <bnoordhuis>if libumem is significantly better, okay. but otherwise, no
17:28:55  <trevnorris>isaacs: not sure how that's going to help, since the expensive part is knowning when memory is free, but i'll give it a look.
17:29:46  <trevnorris>honestly, compared to the price of paying a Persistent and attaching it to the object, the malloc is a noop.
17:30:48  <indutny>obviously
17:31:04  <bnoordhuis>i like indutny's idea btw (partly because i researched a similar thing myself, of course)
17:31:13  <indutny>bnoordhuis: have you ever got any results?
17:31:19  <indutny>and actually this is your idea
17:31:21  <bnoordhuis>one potential issue is that v8 spaces are limited to 1 GB currently
17:31:35  <isaacs>we definitely need more than 1gb of buffer address space.
17:31:41  <isaacs>er, buffer allocations
17:31:53  <trevnorris>well, allocating large buff's externally is fine.
17:31:56  <bnoordhuis>indutny: oh, that might explain why it seems like such a great idea :)
17:32:00  <trevnorris>it's the many many small allocations that kill us.
17:32:24  <trevnorris>the small ones usually turn over quickly, too.
17:32:25  * bradleymeckjoined
17:33:04  <isaacs>yeah
17:33:14  <isaacs>and our slabs leak like crazy in WS case.
17:33:39  <trevnorris>honestly i'm hoping that post you gave me works out. that would simply life greatly.
17:33:43  * TooTallNatejoined
17:34:20  <tjfontaine>trevnorris: are you engaging on those bugs so your voice is heard?
17:34:39  <bnoordhuis>isaacs: re licenses, IANAL but i think the berne convention covers the case where a file doesn't have license boilerplate
17:34:56  <isaacs>bnoordhuis: are you SURE you're not a lawyer?
17:35:00  <trevnorris>tjfontaine: will in a bit. first still trying to reconcile my code w/ what bnoordhuis explained.
17:35:01  <isaacs>bnoordhuis: you might have forgotten.
17:35:17  <bnoordhuis>isaacs: i still have my immortal soul. i do hang out with lawyers though
17:35:34  <tjfontaine>bnoordhuis: so you're just a few drinks away from signing it over
17:35:36  <isaacs>bnoordhuis: i just get so tired of these conversations where nerds beat their chests and have opinions about things that they have no knowledge of.
17:35:38  <trevnorris>bnoordhuis: and.... there was user error. the logic was bad so it was not being made weak. going to fix that, then hopefully it'll crash in flames.
17:36:06  <isaacs>bnoordhuis: at least we're not discussing trademarks. THAT shit is completely insane.
17:36:13  <bnoordhuis>isaacs: oh, you're absolutely right about that
17:36:25  <bnoordhuis>nerds should stick to what they know
17:36:48  <isaacs>bnoordhuis: and like, there's completely different sorts of insanity that the US follows, vs the other former-british imperial countries, vs france and germany, vs the rest of europe, vs asia.
17:38:15  <bnoordhuis>ah, common law vs civil law
17:38:43  <bnoordhuis>pro tip, if you find yourself among lawyers and need a conversation starter
17:39:02  <tjfontaine>if that's the difference, then louisianna must also be different fromt he rest of the US :)
17:39:02  <bnoordhuis>well, it doesn't matter what you actually say as long as the words 'common' and 'civil' are in there somewhere
17:39:37  <bnoordhuis>tjfontaine: louisiana has civil law?
17:40:00  <tjfontaine>http://en.wikipedia.org/wiki/Law_of_Louisiana
17:40:25  <bnoordhuis>one lives and learns
17:40:28  <tjfontaine>indeed
17:40:38  <bradleymeck>anyone have an example of multiple uv_pipe_t being combined into a single uv_pipe_t in memory (or some multiplexing lib already existing)?
17:41:06  * piscisaureus_joined
17:41:49  <bnoordhuis>bradleymeck: sorry, what?
17:42:02  <isaacs>bnoordhuis: apparently, it's more complicated than even just common-vs-civil
17:42:42  <isaacs>bnoordhuis: in some places, trademark stems from from fraud, and preventing someone from passing themselves off as you. in others, it's based on completely different principles.
17:42:44  <bradleymeck>we are trying to get a tool to aggregate multiple uv_pipe_t (being read only) into a single uv_pipe_t (being consumed by libCURL)
17:42:55  <isaacs>bnoordhuis: makes windows-vs-unix kind of seem trivial by comparison.
17:42:59  <mmalecki>isaacs: I have deemed those problems to be batshit insane and give my lawyer a call every time I have a problem
17:43:09  <isaacs>yep
17:43:16  <bnoordhuis>isaacs: fair point. emacs vs vi however....
17:43:16  * isaacsrecently had a conversation with joyent's general counsel.
17:43:27  <isaacs>the good news is that our trademark policy will get less stupid soon.
17:43:40  <isaacs>the bad news is that it'll take a while to rewrite all that stuff.
17:43:45  <bnoordhuis>bradleymeck: on unices, a uv_pipe_t is just a thinly disguised unix socket
17:43:57  <isaacs>so, please don't make any huge noise about it until there's something to actually make noise about.
17:44:01  <bnoordhuis>bradleymeck: if you want to combine them, just read from them into a memory buffer
17:44:18  <bnoordhuis>bradleymeck: or read from them and write the data to the target socket
17:44:39  <bradleymeck>guess ill just write up the multiplexer then
17:44:47  <bradleymeck>was hoping i could just copy paste
17:45:16  <bnoordhuis>i'm a stickler for pedantry
17:45:26  <bnoordhuis>shouldn't it be called 'demultiplexer'?
17:46:01  <bradleymeck>bnoordhuis: it is combining?
17:46:11  <bradleymeck>demux is separating
17:46:38  <bnoordhuis>i guess it depends from what side you're viewing things
17:47:05  <bnoordhuis>but you mentioned it comes from n data sources and goes to a single curl destination
17:47:12  <bnoordhuis>so i guess multiplexer it is
17:47:41  <bradleymeck>demux once multiplex is done is my plan so yea, if i did it the otherway probably would call it something else
17:54:02  * mikealquit (Quit: Leaving.)
17:54:37  * sblomjoined
17:55:43  <sblom>indutny: re: IIS+TLS, there's an internal thread about this issue presently. I'll include what you've discovered.
17:56:26  <tjfontaine>nice
17:56:35  <indutny>sblom: thanks
17:58:47  <trevnorris>bnoordhuis: but it's cool if use a pointer like that within the same function?
18:01:56  * c4milojoined
18:04:35  <bnoordhuis>trevnorris: yes, provided the pointer and the pointee live in the same scope
18:04:49  <trevnorris>yup. awesome, thanks.
18:09:55  * brsonjoined
18:09:59  <piscisaureus_>bnoordhuis: the libuv tests need to run shorter. They time out all the time on windows
18:10:09  * nsmquit (Quit: nsm)
18:10:11  <tjfontaine>they do?
18:10:11  <trevnorris>bnoordhuis: thanks again. that helped me write an important unit test.
18:10:34  <piscisaureus_>tjfontaine: er, I meant benchmarks
18:10:43  <tjfontaine>oh ok
18:10:44  <piscisaureus_>tjfontaine: maybe the buildbot should also run benchmarks :)
18:10:59  <tjfontaine>heh
18:11:13  <tjfontaine>I have to finish how it does the node benchmarks first :)
18:11:33  <piscisaureus_>tjfontaine: the libuv benchmarks are way easier :)
18:12:11  <trevnorris>isaacs: funny enough. the third bullet point on that post, I made the same change last night to my allocator.
18:12:34  <isaacs>trevnorris: which one?
18:12:51  <trevnorris>returning void and passing the return value as a param.
18:14:08  <trevnorris>before if you did Alloc(5) it would return a new object. but instead I did a js wrapper that creates a new object then passes it like Alloc({}, 5)
18:14:15  <trevnorris>for some reason that performs much better.
18:15:02  <trevnorris>and that way you can use it to create new js data object instances using "Alloc(this, N)"
18:15:38  <isaacs>trevnorris: interesting.
18:16:01  <trevnorris>yeah. so the new Buffer will remove the make fast/slow stuff and just do that.
18:18:35  * dapquit (Quit: Leaving.)
18:19:55  * qmx|lunchchanged nick to qmx
18:21:48  * dapjoined
18:22:12  * dominictarrquit (Quit: dominictarr)
18:26:36  * csaohquit (Quit: csaoh)
18:27:38  * bradleymeckquit (Quit: bradleymeck)
18:29:54  * bradleymeckjoined
18:35:39  <bnoordhuis>piscisaureus_: hm, is that a roundabout way of saying that uv-win should run faster?
18:36:03  <piscisaureus_>bnoordhuis: I heard you wanted to do something ground-breaking again? :-)
18:36:12  <piscisaureus_>I'd say that is a real challenge you found.
18:39:15  * kazuponjoined
18:44:55  * kazuponquit (Ping timeout: 272 seconds)
18:48:31  <trevnorris>alright. opinion posted. hopefully didn't sound like too much an idiot.
18:49:40  <trevnorris>isaacs: whoa. that'll require a bit of refactoring. remove Local entirely? that's intense.
18:51:01  <isaacs>yeah
18:51:43  <trevnorris>heh, that's funny. and no more need to pass the isolate to any Persistent methods.
18:55:46  <trevnorris>bnoordhuis: so what if I did a "Persistent<Object> p_saved[N]", then assigned each of those a Persistent. could those be reused?
18:57:37  <bnoordhuis>trevnorris: you're only reusing the pointer to Handle
18:57:48  <bnoordhuis>iow, no big win
18:57:59  <trevnorris>ah, ok.
18:58:08  <bnoordhuis>Persistent<Object>::New(...) will still do the GlobalizeReference() dance, etc.
18:58:45  <hij1nx>is it possible to hook into the require module?
18:59:13  <hij1nx>sorry, that was not the question i wanted to ask
19:00:06  <hij1nx>is it possible to hook into these arguments somehow? https://github.com/joyent/node/blob/master/lib/module.js#L455
19:00:42  <bnoordhuis>hij1nx: don't think so
19:01:24  <hij1nx>bnoordhuis: the root of what im trying to do is gather stats about bytes read/dispatched from underlying tcp socket
19:01:40  <hij1nx>bnoordhuis: but i have two requirements, one i cant use something like node_pcap
19:02:08  <hij1nx>and second i cant wrap net/http, etc.
19:02:23  <tjfontaine>I presume we're ignoring an binary addin as well?
19:02:29  <tjfontaine>*any
19:02:30  <bnoordhuis>net.Socket#bytesWritten?
19:02:36  <hij1nx>bnoordhuis: https://github.com/hij1nx/netpeek
19:02:46  <hij1nx>^ did this little hack
19:03:02  <hij1nx>which is kind of neat, it does exactly that
19:03:46  <hij1nx>however the problem is that i have no context about what module read/dispatched the bytes
19:04:00  <hij1nx>`process.binding.TCP.prorotype.readStart` fires every time a read happens on a TCP socket.
19:04:07  <bnoordhuis>monkey-patch read() and write() and inspect the stack trace?
19:04:11  <bnoordhuis>rather expensive, of course
19:05:53  <hij1nx>monkey-patching a module means that if `net` module is included later on by another module, the read() and write() will get missed.
19:06:33  <bnoordhuis>no, there's only ever one 'net' instance
19:06:40  <bnoordhuis>unless someone clears require.cache, of course
19:07:04  <hij1nx>yep
19:07:14  <hij1nx>sorry, thats what i meant to say
19:07:26  <isaacs>bbiab
19:07:30  * isaacs&
19:07:31  <bnoordhuis>that's where you as a module author should say "tough cookies, not my problem"
19:07:47  <hij1nx>:)
19:11:30  <hij1nx>ok, maybe i will just patch higher up and say tough cookies. because otherwise its looking quite complicated. thanks!
19:11:54  * piscisaureus_quit (Read error: Connection reset by peer)
19:12:18  * piscisaureus_joined
19:20:53  * bradleymeckquit (Quit: bradleymeck)
19:23:50  * piscisaureus_quit (Ping timeout: 272 seconds)
19:28:13  * bnoordhuisquit (Ping timeout: 240 seconds)
19:28:43  * stagasjoined
19:42:34  * stephankquit (Read error: Operation timed out)
19:47:40  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:48:41  * stagasquit (Quit: ChatZilla 0.9.90-rdmsoft [XULRunner])
19:50:34  <indutny>hoya
19:50:46  <indutny>trevnorris: https://code.google.com/p/v8/issues/detail?id=2590
19:50:49  <indutny>isaacs: ^
19:50:56  <indutny>ircretary: tell bnoordhuis to star https://code.google.com/p/v8/issues/detail?id=2590
19:50:57  <ircretary>indutny: I'll be sure to tell bnoordhuis
19:51:08  <indutny>thanks mraleph
19:51:34  * piscisaureus_joined
19:52:49  <trevnorris>indutny: i'm still not a fan. to replicate a buffer you'd need to "new Uint8Array(new ArrayBuffer(n))". that chews performance.
19:53:14  <trevnorris>and the typed array specification requires that it's zero filled.
19:53:43  * TooTallNatejoined
19:53:46  <trevnorris>that used to be done in node, until it was reverted for poorly affecting instantiation of large buffers.
19:55:17  * benoitcquit (Excess Flood)
19:55:26  <trevnorris>indutny: also it requires that "slice" copy the data, instead of create pointers to it.
19:56:27  <trevnorris>indutny: thoughts?
19:57:23  * stephankjoined
19:58:25  * loladirojoined
19:59:51  * benoitcjoined
20:06:04  <isaacs>indutny: star'ed!!
20:06:10  * benoitcquit (Excess Flood)
20:06:41  * Raynosquit (Ping timeout: 252 seconds)
20:06:52  * sgallaghquit (Remote host closed the connection)
20:08:08  * jez0990quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
20:09:21  * benoitcjoined
20:10:18  <indutny>trevnorris: I think we'll figure out something
20:11:17  <indutny>isaacs: have you seen latest comment?
20:15:14  <hij1nx>ok, maybe i will just patch higher up and say tough cookies. because otherwise its looking quite complicated. thanks!
20:15:25  <hij1nx>oops, sorry, hit the 'up' arrow
20:15:33  <indutny>:)
20:21:10  <trevnorris>indutny: well, i'll impressed if current buffer performance is improved with this. =)
20:21:26  <indutny>yeah, I understand
20:21:33  <indutny>let me think about it for a bit
20:21:40  <indutny>I've just looked at his solution
20:21:52  <trevnorris>i mean. i really like the idea. that removes a lot of code complexity.
20:22:12  <trevnorris>and since they can write with all their internal api magic, who knows what could happen.
20:24:32  <indutny>basically
20:24:38  <indutny>its just mallocs buffers
20:24:57  <trevnorris>it also memsets to 0 right afterwards.
20:25:22  <trevnorris>erm. sorry. thinking out loud.
20:26:06  <indutny>yes
20:26:09  <indutny>I see it
20:26:19  <indutny>I mean, that's not really what I expected to see
20:26:30  <indutny>I need to figure out if it'll be faster
20:26:50  <trevnorris>it's part of the typed array spec. unfortunately can't get around that.
20:26:57  <indutny>well
20:27:00  <indutny>I mean
20:27:04  <indutny>they're invoking weak callbacks
20:27:08  <indutny>and using them
20:27:29  <indutny>ah
20:27:34  <indutny>they're using Persistent
20:27:35  <indutny>whoa
20:27:38  <indutny>fuck it :)
20:28:06  <trevnorris>indutny: well, we can still do buffer pooling like we are now.
20:28:45  <trevnorris>var b = new ArrayBuffer(1024); var c = new Uint32Array(b, 0, 512); var d = new Uint32Array(b, 512)'
20:29:01  <trevnorris>erm that should be Uint8Array
20:29:13  <indutny>no
20:29:14  <indutny>that's bad
20:29:35  <indutny>ok, time to sleep
20:29:43  <trevnorris>sleep tight
20:30:07  <tjfontaine>ya, using typedarrays as defined by the spec for backing node buffers seems unlikely, however
20:30:53  <tjfontaine>it's likely that anyone doing the work will come to the same conclusions that persistent handles are too expensive, and then once that's solved the mallocs will be the expensive part
20:31:03  <trevnorris>tjfontaine: i agree (actually am sure it's impossible) but don't want to rule it out yet.
20:31:14  <trevnorris>tjfontaine: well, don't forget they also are required to memset to 0 after the malloc.
20:31:50  <tjfontaine>right, but ignore the spec portion for now, and agree that there is an abstraction that defines a typedarray that really is nearly equivalent to what a node buffer is
20:32:15  <tjfontaine>a typedarray is a specialization of a node buffer, more or less
20:32:27  <trevnorris>yeah. take a way a few of the spec specifics and they're pretty much the same.
20:33:04  <tjfontaine>so aside from the memset and memcpy's that typedarrays want to do, what would make typedarrays fast for v8, woudl make them fast for node buffers
20:34:06  <trevnorris>whoa, we need to rip out the d8 implementation of typed arrays. it kicks node's ass.
20:34:07  <tjfontaine>from an outside perspective of what you, indutny, and ben have been doing I see two choices
20:35:01  * bnoordhuisjoined
20:35:15  <tjfontaine>1) figure out how to "reuse" a persistent/object-caching after the weak callback has been done, 2) go down a level and implement the right solution in v8 internal semantics
20:35:41  * stagasjoined
20:36:44  <tjfontaine>trevnorris: you're equipped to answer the latest comment on that codesite "What are your issues with persistent handles? What you hope to achieve? Is the allocation speed a problem for you, or retention (dead buffers do not deallocate fast enough)?"
20:37:28  <trevnorris>tjfontaine: i've posted a link to my response on the forum: https://groups.google.com/forum/?hl=en&fromgroups=#!topic/v8-users/6kSAbnUb-rQ
20:37:37  <tjfontaine>nod
20:39:13  * bnoordhuisquit (Ping timeout: 240 seconds)
20:40:02  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
20:55:05  * c4miloquit (Remote host closed the connection)
20:55:33  * c4milojoined
21:00:03  * c4miloquit (Ping timeout: 252 seconds)
21:01:32  * mikealjoined
21:03:09  * `3rdEdenjoined
21:03:11  <trevnorris>ugh. where's bnoordhuis when you need him?
21:03:29  <trevnorris>tjfontaine: here. think this is an ugly, but working, way to reuse persistents: https://gist.github.com/trevnorris/5243611
21:04:52  <trevnorris>ooh. think I have an idea to remove a bunch of MakeWeak's
21:05:13  * wavded__quit (Remote host closed the connection)
21:05:13  * dscapequit (Remote host closed the connection)
21:06:34  <tjfontaine>trevnorris: simply not disposing is kosher enough to let it go back into the wild?
21:06:52  <trevnorris>yeah. a persist hangs around until Dispose is called.
21:07:06  <tjfontaine>but you don't have to markt he object as live again?
21:07:44  <trevnorris>you mean make it weak?
21:07:51  <trevnorris>(again)
21:09:26  <tjfontaine>I mean, it's proper to simply introduce the same object back into the wild after the weak cb has been triggered?
21:09:59  <tjfontaine>there aren't any other internal flags set by the gc that indicate it's already tried to free this object?
21:10:22  <trevnorris>not that I know of. i'm sure indutny or bnoordhius would have something to say.
21:11:45  <trevnorris>funny though. reusing a persistent like this is pretty much a noop compared to the cost of MakeWeak and SetHiddenValue
21:12:05  <tjfontaine>yes, that's the point of caching :)
21:12:48  <trevnorris>how do you mean? the hidden values are set on the js objects themselves, not on the persistents. and when MakeWeak is triggered it has to be set again.
21:13:53  <tjfontaine>oh I thought you were saying your example didn't require makeweak to be set again
21:14:17  <trevnorris>yeah. didn't think so. then it fatally crashed in a ball of flames.
21:14:30  <tjfontaine>right ok yes
21:14:49  <trevnorris>too bad they don't have a MakePersistentlyWeak() =P
21:15:18  <trevnorris>though I wonder what kind of control I'd have if I extended the Persistent class with my own.
21:15:44  <trevnorris>(heh, at this rate i'll never finish the new buffer implementation)
21:16:42  <tjfontaine>I think what you're finding is that this isn't going to be done with the external api, which is great to learn and experience the v8 api, but if it could have been done -- it probably would have been done
21:17:37  <trevnorris>yeah.... but hey. you're right. I understand v8 way better now because of this.
21:18:07  <tjfontaine>absolutely, and now to understand even better you go down a level and muck with the internals to get what you want :P
21:18:48  <trevnorris>heh. that's going to take some time. just looking at the changeset from the mailer I realized how little I know.
21:22:29  * bradleymeckjoined
21:25:18  * c4milojoined
21:26:17  <trevnorris>well bummer. global-handles.cc. has a flag "WEAK" that just needs to be set. if that were exposed i could reset it and not need to call make callback again.
21:26:23  <trevnorris>(at least from my limited understanding)
21:29:07  * dscapejoined
21:30:37  <trevnorris>tjfontaine: now, you'll be my freaking hero if you can find a faster way to do something like SetHiddenValue(). that thing cuts performance in half.
21:31:02  * dominictarrjoined
21:31:30  * Raynos_joined
21:35:55  <tjfontaine>trevnorris: heh, well that will certainly involve some learning
21:36:18  * wavded__joined
21:36:24  <trevnorris>lol. seriously. think i've spent 3 days just figuring out how Persistents work.
21:42:07  * Raynos_changed nick to Raynos
21:48:02  * mikealquit (Quit: Leaving.)
21:49:12  * mikealjoined
21:51:30  <trevnorris>tjfontaine: it's so hard not to continuously optimize. i mean, right now the allocator is running 3314.58 ops/millisecond. i mean. that's ~300 nanoseconds per call.
21:51:43  <trevnorris>*...hard for me not to...
21:52:38  * dominictarrquit (Quit: dominictarr)
21:53:44  <tjfontaine>trevnorris: heh, but if you want to continue to optimize find out why SetHiddenValue is so expensive :P
21:54:03  <trevnorris>ugh. damn you!!!
21:54:16  * trevnorristries to resist the urge to look at v8 source...
21:54:36  <tjfontaine>use the source luke
21:54:41  <trevnorris>eh?
21:54:49  <trevnorris>oh. lol
21:54:56  <tjfontaine>:)
21:55:12  <trevnorris>that has to be on a shirt or something
21:55:26  <tjfontaine>ya, it's an old saying
21:57:18  * rendarquit
22:00:38  * wolfeidauquit (Remote host closed the connection)
22:04:07  * bnoordhuisjoined
22:16:10  * qmxchanged nick to qmx|away
22:17:06  <othiym23>if I want to get a solid understanding of the Node tick cycle (e.g. what is _tickFromSpinner for?), are there any good resources I can look at?
22:17:18  * wolfeidaujoined
22:17:22  <tjfontaine>trevnorris: a user beckons you :)
22:17:41  <trevnorris>lol
22:17:45  <trevnorris>othiym23: yeah, me.
22:17:49  <trevnorris>what can I help you with?
22:17:52  <othiym23>trying to actually wrap my head around the implementation of startup.processNextTick and determined to not let it defeat me this time
22:18:39  <trevnorris>heh. ok. let me go through the basics.
22:19:03  <othiym23>among other things, I'm trying to grok _tickInfoBox, and also trying to figure out how _fatalException works vis a vis the domains uncaughtException hack in 0.8
22:19:17  <trevnorris>process.nextTick adds a callback to the nextTickQueue (an array of functions)
22:19:24  <trevnorris>ah, yeah. _tickInfoBox was my work.
22:19:46  <othiym23>it's a very confusing thing to try to debug ;)
22:20:19  <trevnorris>heh, took me a while to get it myself.
22:20:35  <trevnorris>so look for MakeCallback in src/node.cc
22:21:25  <othiym23>OK, I have all 3 of them in a window
22:22:03  <trevnorris>they call up from top to bottom. so you want the top most.
22:22:16  <othiym23>also: how much of this is going to change in 0.10.2? I've been following the changes you've been making to the domain / non-domain tick callbacks
22:22:20  <othiym23>got it
22:22:48  <othiym23>(the version I'm looking at is on the v0.10.1-release branch)
22:23:19  <trevnorris>now forget the first "if()" that's just lazy loading some necessaries.
22:23:40  <othiym23>right
22:24:00  <trevnorris>now you see "Local<Value> ret = callback->Call()" that calls a js function that was passed in.
22:24:09  <othiym23>so it looks like there's two places FatalException can be called: after the first callback, and then again after the nextTick queue has been run
22:25:10  * AvianFluquit (Remote host closed the connection)
22:25:26  <trevnorris>after the callback has run you see: "if (tick_infobox.length == 0)"
22:25:57  <trevnorris>that checks if any callbacks exist in the nextTickQueue
22:26:23  <trevnorris>tick_infobox is a struck defined on L151-155
22:26:46  <othiym23>still with you
22:26:51  <othiym23>what's the "spinner"?
22:27:02  <trevnorris>we'll get to that.
22:27:10  <trevnorris>then if you look at line 2493 you'll see that I've setup an external data array pointing to the struct.
22:27:38  <trevnorris>the reason for this is because it allows js to access raw memory. which is by far the fastest way for c++ to read in values from js.
22:28:04  <trevnorris>so it's been exposed as an array to process._tickInfoBox
22:28:18  <trevnorris>each array placement is a value in the struct.
22:29:08  <othiym23>right
22:29:14  <trevnorris>then to make sure users can't screw with it afterwards I make a local reference to it in node.js as infoBox
22:29:40  <othiym23>yeah
22:30:29  <othiym23>that part's relatively straightforward, and I think I've sort of worked out how it gets decremented, although I gotta say that style of table-driven control flow may be fast, but it's confusing as hell to step through
22:31:18  <trevnorris>yeah. i realize that. but this change prevents +10k js calls to _tickCallback every second under high load.
22:31:53  <othiym23>yeah, and I appreciate the work you've put into this
22:31:58  <trevnorris>and this sort of thing most often wouldn't be allowed in core, except this is extremely hot code.
22:32:14  <othiym23>it would be awesome to get this all written up somewhere in the source tree, though
22:32:15  <trevnorris>np. performance tuning is my specialty. =)
22:32:53  <trevnorris>what do you mean by "source tree"? like the code itself
22:35:06  <othiym23>I was thinking about the docs folder in the Linux source tree
22:35:31  <othiym23>I mean, it would be awesome to have this on the docs site, but I think the number of ordinary Node users who are going to want to know this stuff is probably vanishingly small
22:36:43  <othiym23>I'm trying to abuse domains (semi-successfully), so I need more detail, and the source is complex enough (what with the way things bounce between node.js and node.cc / node.h) that a breadcrumb trail through the internals and their architecture would be extremely useful
22:37:14  <othiym23>I realize I could probably do something abou this above and beyond complaining about it, but I need to understand it myself first ;)
22:38:49  <trevnorris>if you want throw up an issue about better docs (if one doesn't already exist) and cc me.
22:39:19  <othiym23>sure, that's a good idea
22:40:19  <trevnorris>now _tickFromSpinner gets called off uv_run.
22:40:40  <trevnorris>if you look at deps/uv/src/unix/core.c line 296-328
22:41:27  <othiym23>so that's the hook into the uv's turning of the event loop?
22:41:35  <trevnorris>yeah
22:42:29  <trevnorris>so in src/node.cc L 179-208 you'll see the callback that gets kicked off from uv__run_idle
22:42:40  <trevnorris>bnoordhuis: please make sure I don't make an ass of myself. =)
22:43:24  <trevnorris>so Spin calls _tickFromSpinner, which also enters into the _tickCallback loop.
22:43:39  <othiym23>yeah, so tick_spinner is set to Spin in NeedTickCallback / _needTickCallback, right?
22:43:45  * AvianFlujoined
22:44:23  <trevnorris>yeah. when _needTickCallback() fires it lets node know to go check sys IO.
22:44:41  <trevnorris>then when the _tickCallback even loop breaks the spinner will return.
22:44:53  <trevnorris>breaks as in finishes or errors.
22:45:09  <othiym23>OK, so dox request is filed at https://github.com/joyent/node/issues/5156
22:45:32  <othiym23>OK, that all makes sense
22:45:37  <trevnorris>thx
22:45:40  * `3rdEdenquit (Remote host closed the connection)
22:46:00  <trevnorris>now right now there's also a "maxTickDepth". it makes sure you don't have an infinite recursive nextTick callback loop.
22:46:20  <trevnorris>because that would starve IO, as it would never allow the spinner to return.
22:46:54  <trevnorris>but it will be removed in v0.12 since setImmediate should now be used for that scenario.
22:47:33  <trevnorris>isaacs: re: maxTickDepth, we'll have to think about how to handle domains that call nextTick from an error if they're going to be removed.
22:47:41  * loladiroquit (Quit: loladiro)
22:47:42  <trevnorris>almost had the removed, but that kept failing me.
22:48:09  <trevnorris>wow, me typing fast == really bad grammer
22:48:54  <othiym23>sad to say, I can think of some apps I've worked on that could blow maxTickDepth without recursion
22:49:07  <othiym23>but that's fine, maxTickDepth is configurable, and also those apps were horribly designed anyway
22:49:51  <trevnorris>now, with domains. there are just two extra things to note.
22:51:37  <trevnorris>first you'll want to jump to the latest on v0.10 branch.
22:51:51  <trevnorris>(since there was an unknown bug in v0.10.1)
22:52:42  <trevnorris>process._usingDomains() is called from lib/domains.js to override all the default functionality with domain specific functionality.
22:53:25  <trevnorris>where _usingDomains() is defined in src/node.cc L 902-923
22:55:08  <othiym23>yeah, I saw that change go in
22:55:17  * c4miloquit (Remote host closed the connection)
22:55:44  * c4milojoined
22:55:52  <trevnorris>the only real different between domains and no domains is the former checks if the callback has a domain attached that needs to be entered.
22:57:32  <othiym23>OK
22:57:46  <othiym23>thank you
22:57:50  <trevnorris>yeah. np.
22:58:49  <trevnorris>bnoordhuis: here, reuse of Persistents (only requirement being needing to call MakeWeak, since don't have access to reset the WEAK flag): https://gist.github.com/trevnorris/5243611
23:00:10  * c4miloquit (Ping timeout: 246 seconds)
23:09:58  * bradleymeckquit (Quit: bradleymeck)
23:15:56  * paddybyersquit (Remote host closed the connection)
23:16:11  * paddybyersjoined
23:16:12  * `3rdEdenjoined
23:20:25  * rvaggquit (Ping timeout: 256 seconds)
23:20:25  * CAPSLOCKBOTquit (Ping timeout: 256 seconds)
23:20:54  <bnoordhuis>trevnorris: p_ptr = &p_obj; <- p_obj is still a stack variable
23:21:23  <trevnorris>bnoordhuis: but it is only used inside the Alloc function.
23:21:32  * kuplatup1uquit (Ping timeout: 256 seconds)
23:22:02  <bnoordhuis>trevnorris: p_current_alloc = p_ptr; <- nuh-uh
23:22:07  * chobie1quit (Ping timeout: 256 seconds)
23:22:32  * chobie1joined
23:23:05  <trevnorris>=P
23:23:25  * kuplatupsujoined
23:24:14  <trevnorris>bnoordhuis: ok. the second use in the "if (length <= ALLOC_SIZE)" is crap. but what about the use in the "if (has_free)"?
23:24:50  <trevnorris>because there i'm just trying to point to the p_array storage cell that definitely contains the instantiated Persistent.
23:25:05  <bnoordhuis>trevnorris: that's legal albeit somewhat pointless
23:25:08  * `3rdEdenquit (Ping timeout: 272 seconds)
23:25:15  <trevnorris>why's that?
23:25:30  <bnoordhuis>well, i explained that a Persistent is really a pointer to a Handle in disguise?
23:25:37  * rvaggjoined
23:26:08  <trevnorris>in the "has_free" path you'll notice that i don't create a Persisten::New again.
23:26:50  <TooTallNate>isaacs: so what did we have to do for windows to be a "verified publisher"?
23:27:00  * stagasquit (Read error: Connection reset by peer)
23:27:02  <TooTallNate>in lamens terms :p
23:27:08  <TooTallNate>i've already found http://msdn.microsoft.com/en-us/library/ms537361(v=vs.85).aspx#Obtaining_Certificat
23:27:11  <tjfontaine>we aren't?
23:27:17  <TooTallNate>tjfontaine: we areā€¦ this is for work
23:27:18  * loladirojoined
23:27:20  <tjfontaine>oh
23:27:26  <tjfontaine>"pay" :)
23:27:26  <bnoordhuis>trevnorris: oh right, sorry - i thought you were assigning it without really using it. nvm
23:28:14  <trevnorris>bnoordhuis: ok, so is there still a problem there or did I finally find a legitimate way to reuse a persistent handle?
23:28:24  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 7514149 : darwin: don't select(&exceptfds) in fallback path The exceptfds set is f (+1 more commits) - http://git.io/tMK7dw
23:28:58  <MI6>joyent/node: Ben Noordhuis v0.10 * 982877e : deps: upgrade libuv to 7514149 - http://git.io/gvSLXQ
23:29:07  <bnoordhuis>trevnorris: the if branch seems okay, the else branch is wrong
23:29:58  <trevnorris>eh?
23:30:41  <MI6>libuv-v0.10: #21 UNSTABLE windows (6/187) linux (2/186) osx (2/186) smartos (4/186) http://jenkins.nodejs.org/job/libuv-v0.10/21/
23:33:13  <bnoordhuis>trevnorris: because stack var
23:35:43  <trevnorris>ah ok. yeah, have a fix for that.
23:36:36  <trevnorris>bnoordhuis: though unfortunately it's pretty useless since the WEAK flag is cleared when the callback is called, still incur the overhead of calling MakeWeak again.
23:38:22  <bnoordhuis>yep
23:38:50  <trevnorris>well. at least now I understand how they work. thanks for that. =)
23:42:25  * mikealquit (Quit: Leaving.)
23:44:44  * luxigojoined
23:45:46  <MI6>nodejs-v0.10: #79 UNSTABLE linux-x64 (1/569) windows-x64 (5/569) smartos-ia32 (1/569) windows-ia32 (5/569) http://jenkins.nodejs.org/job/nodejs-v0.10/79/
23:48:05  <trevnorris>bnoordhuis: nice use of the word "elucidating"
23:49:40  * loladiroquit (Quit: loladiro)
23:51:34  * loladirojoined
23:52:42  <isaacs>TooTallNate: i don't actually know what Joyent had to do
23:52:52  <TooTallNate>isaacs: haha, damn, ok
23:53:05  <isaacs>TooTallNate: but i can put you in touch with claudio or somebody over there.
23:53:18  <isaacs>TooTallNate: are you trying to make learnboost a verified kajigger?
23:55:02  <TooTallNate>isaacs: ya, we're gonna be distributing an .exe soon, so we gotta make sure that's all pretty
23:58:44  * Kakeraquit (Ping timeout: 245 seconds)
23:59:02  * brson_joined
23:59:53  <isaacs>i see