00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:01:58  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:02:05  * hzquit
00:08:27  <othiym23>trevnorris: *I* don't use err.domain, but I do know of people that use it for logging
00:08:35  <othiym23>if isaacs is fine with killing it, I have no complaints
00:08:50  <othiym23>guess whose shit has been on fire all day?
00:09:51  <trevnorris>um. i'm not even sure how to respond to that.
00:13:27  * mikealjoined
00:15:48  <MI6>joyent/node: isaacs v0.10 * b97c28f : http: provide backpressure for pipeline flood (+1 more commits) - http://git.io/9bWuwg
00:16:49  * mikealquit (Client Quit)
00:17:56  * bnoordhuisjoined
00:19:18  * mikealjoined
00:22:44  * bnoordhuisquit (Ping timeout: 268 seconds)
00:25:18  * mikealquit (Quit: Leaving.)
00:26:15  * piscisaureus_joined
00:26:27  <piscisaureus_>ircretary: notes
00:26:59  <MI6>nodejs-v0.10: #1539 UNSTABLE smartos-x64 (5/602) smartos-ia32 (4/602) osx-ia32 (1/602) http://jenkins.nodejs.org/job/nodejs-v0.10/1539/
00:29:50  * Benviejoined
00:30:36  <MI6>nodejs-v0.10-windows: #265 UNSTABLE windows-ia32 (11/602) windows-x64 (10/602) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/265/
00:33:36  * mikealjoined
00:39:57  <trevnorris>ok. so http parser doesn't parse the statusMessage, just the statusCode?
00:40:12  <trevnorris>isaacs: ^ ? is that something that should be added?
00:40:40  <isaacs>trevnorris: oh, you meant for incoming messages?
00:40:46  <isaacs>trevnorris: i thought you meant for outgoing message
00:41:10  <trevnorris>isaacs: yeah. well he's already implemented it, and I asked him to write some tests not realizing there's no way to check on incoming message.
00:41:25  <isaacs>heh
00:41:30  * amartensquit (Quit: Leaving.)
00:41:33  <isaacs>can check by doing net.connect, i guess
00:41:45  <isaacs>i'd be ok with adding to incoming message, but it's not a priority
00:42:12  <trevnorris>coolio. i'll just do it like that
00:42:33  * julianduquejoined
00:44:01  <trevnorris>isaacs: fwiw seems there's already a PR for it (though it'll require cleanup): https://github.com/joyent/http-parser/pull/152
00:44:10  <trevnorris>i'll just manually check it for now
00:57:43  * mikealquit (Quit: Leaving.)
01:00:27  <isaacs>trevnorris: kewl
01:00:51  * mikealjoined
01:01:00  <trevnorris>isaacs: quick review? https://gist.github.com/trevnorris/7017642
01:01:57  <isaacs>trevnorris: the docs should state that if left as "undefined" then the standard message for the statusCode will be used
01:02:05  <trevnorris>isaacs: good point
01:02:15  <isaacs>otherwise it looks like i have to set it
01:02:52  <isaacs>trevnorris: also ServerResponse objects should get this.statusMessage=undefined in the ctor (or the proto)
01:02:56  <isaacs>i forget which one is faster :)
01:03:11  <trevnorris>ah yeah. true.
01:03:46  <isaacs>trevnorris: also, in the test, it's better to wait until on('end') and then just make sure you get exactly the full string you want.
01:03:57  * isaacsis full of bikesheddy opinions right now, apparently
01:04:18  <trevnorris>heh, that's fine. it's not absolutely guaranteed that I get the full response in the first data event
01:04:23  <trevnorris>so good catch
01:04:28  <isaacs>thechances of getting the message split in two chunks, is pretty ridiculously small, though
01:04:41  <isaacs>to localhost? yes, that is virtually guaratneed.
01:04:49  <isaacs>but, officially, it is not guaranteed :)
01:05:04  <tjfontaine>my lo mtu is 10
01:05:14  <trevnorris>heh
01:06:41  * julianduquequit (Ping timeout: 245 seconds)
01:07:00  <trevnorris>ah crap. need to turn off keep alive or the net.connect doesn't register the end event, right?
01:08:24  <isaacs>trevnorris: send connection:close in teh client :)
01:08:55  <isaacs>trevnorris: or you can do `connection:close` header in teh server
01:09:07  <isaacs>trevnorris: res.setHeader('connection', 'close')
01:11:08  <trevnorris>isaacs: ah, need to listen for the 'close' event, not end :P
01:16:58  <trevnorris>isaacs: here, best I got: https://gist.github.com/trevnorris/7017642
01:17:13  <isaacs>trevnorris: really? that's oddball. no 'end' event?
01:17:17  <trevnorris>yeah
01:17:21  <trevnorris>no end event. just close
01:17:27  <isaacs>trevnorris: half-duplex?
01:17:42  <isaacs>trevnorris: what if you do res.connection.destroySoon() on the server?
01:18:44  <isaacs>trevnorris: oh, yeha, you're not doing res.setHeader('connection', 'close')
01:18:50  <isaacs>but why woul dit be getting a close anyway, then?
01:18:55  <isaacs>how can it be closed, but not ended?
01:18:58  <isaacs>that's so weird!!
01:19:05  <trevnorris>isaacs: but i'm sending it in the request
01:19:53  <trevnorris>isaacs: ok. so res.connection.destroySoon does fire the end event.
01:20:21  <isaacs>trevnorris: i get a 'end' event just fine
01:20:48  <isaacs>trevnorris: the assertion blows, obviously
01:21:10  <isaacs>https://gist.github.com/isaacs/7017818
01:21:29  <isaacs>trevnorris: what happens for you?
01:22:35  <trevnorris>isaacs: oh, i'm a dip. i had the assertion in the wrong place so it looked like I wasn't getting the end event. yeah, I am. but is data supposed to be passed to the end event?
01:22:50  <isaacs>no
01:23:18  <trevnorris>ok. one sec.
01:23:24  <isaacs>you do on('data', bufs.push.bind(bufs)); on('end', test)
01:24:27  <trevnorris>isaacs: here we go: https://gist.github.com/trevnorris/7017642
01:24:39  * TooTallNatejoined
01:24:40  <trevnorris>what is bufs.push.bind(bufs)?
01:25:09  <isaacs>trevnorris: on('data', function(chunk) { bufs.push(chunk) })
01:25:33  <isaacs>trevnorris: the 'bind' method of Function objects returns a method that is called in the "this-context" of the first argument to call
01:25:39  * isaacstrololololol
01:25:43  <trevnorris>hah, ok.
01:25:49  * kazuponjoined
01:26:11  <isaacs>[].push.bind(bufs) also works
01:26:23  <isaacs>the client.end() is unnecessary, but otherwise lgtm
01:26:33  * kazuponquit (Remote host closed the connection)
01:26:38  <isaacs>trevnorris: oh wait
01:26:49  <isaacs>trevnorris: this.statusMessage needs to be initialized to undefined
01:27:04  <trevnorris>duh. got caught up on the test.
01:28:17  * kazuponjoined
01:29:10  * kazuponquit (Remote host closed the connection)
01:29:20  * kazuponjoined
01:30:03  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:30:17  <isaacs>kk
01:30:46  * dominictarrquit (Quit: dominictarr)
01:30:49  <trevnorris>isaacs: ok. done. want to see it again?
01:31:30  <isaacs>sure
01:31:32  <isaacs>why not :)
01:31:34  * dominictarrjoined
01:31:37  <trevnorris>https://gist.github.com/trevnorris/7017642
01:31:45  * dominictarrquit (Client Quit)
01:32:07  <isaacs>LGTM
01:32:13  <trevnorris>coolio. thanks.
01:32:18  <isaacs>np
01:32:34  * inolenjoined
01:34:06  * AvianFluquit (Remote host closed the connection)
01:34:07  <trevnorris>heh, one more little change. he used double quotes in the doc entry :P
01:36:43  * EhevuTovquit (Quit: This computer has gone to sleep)
01:37:57  <MI6>joyent/node: Patrik Stutz master * 5491004 : http: add statusMessage - http://git.io/r3OZWQ
01:39:46  * abraxasjoined
01:44:49  * AvianFlujoined
01:45:02  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:50:45  * Benviequit (Ping timeout: 272 seconds)
01:51:07  * brsonquit (Ping timeout: 272 seconds)
01:51:35  * brsonjoined
01:53:45  * amartensjoined
01:53:57  * amartensquit (Client Quit)
02:03:20  <MI6>nodejs-master: #626 UNSTABLE osx-x64 (1/648) smartos-ia32 (7/648) linux-x64 (1/648) smartos-x64 (10/648) osx-ia32 (1/648) http://jenkins.nodejs.org/job/nodejs-master/626/
02:12:23  * AvianFluquit (Remote host closed the connection)
02:16:20  * AvianFlujoined
02:20:41  <MI6>nodejs-master-windows: #419 UNSTABLE windows-x64 (21/648) windows-ia32 (22/648) http://jenkins.nodejs.org/job/nodejs-master-windows/419/
02:21:02  * brsonquit (Ping timeout: 240 seconds)
02:22:20  * defunctzombie_zzchanged nick to defunctzombie
02:25:41  * dominictarrjoined
02:29:14  * c4miloquit (Remote host closed the connection)
02:29:41  * c4milojoined
02:31:11  * indexzerojoined
02:34:42  * c4miloquit (Ping timeout: 268 seconds)
02:35:40  * AvianFluquit (Remote host closed the connection)
02:50:52  * AvianFlujoined
02:53:39  * indexzeroquit (Quit: indexzero)
02:57:08  * qmxquit (Excess Flood)
02:57:28  * qmx_joined
02:58:52  * qmx_changed nick to qmx
03:04:13  * swajquit (Ping timeout: 272 seconds)
03:05:53  * AvianFluquit (Remote host closed the connection)
03:07:26  * dominictarrquit (Quit: dominictarr)
03:21:10  * swajjoined
03:41:57  * Benviejoined
03:46:29  * Benviequit (Ping timeout: 256 seconds)
03:47:21  * kazuponquit (Remote host closed the connection)
03:51:19  * defunctzombiechanged nick to defunctzombie_zz
03:51:58  * defunctzombie_zzchanged nick to defunctzombie
04:17:42  * kazuponjoined
04:27:33  * kazuponquit (Ping timeout: 272 seconds)
04:27:49  * amartensjoined
04:37:55  * defunctzombiechanged nick to defunctzombie_zz
04:40:43  * dominictarrjoined
04:42:31  * dominictarrquit (Client Quit)
04:43:19  * dominictarrjoined
04:46:06  * dominictarrquit (Client Quit)
04:49:19  * dominictarrjoined
05:05:07  * kazuponjoined
05:08:48  * dominictarrquit (Quit: dominictarr)
05:37:54  * paddybyersjoined
05:43:11  * mikealquit (Quit: Leaving.)
05:44:07  * mikealjoined
05:47:43  * mikealquit (Client Quit)
05:53:31  * mikealjoined
06:00:01  * octetcloudquit (Ping timeout: 245 seconds)
06:06:41  * inolenquit (Quit: Leaving.)
06:07:32  * amartensquit (Quit: Leaving.)
06:14:07  * amartensjoined
06:33:11  * rendarjoined
06:43:25  <MI6>nodejs-v0.10-windows: #266 UNSTABLE windows-ia32 (10/602) windows-x64 (10/602) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/266/
06:53:02  * amartensquit (Quit: Leaving.)
07:12:40  * hzjoined
07:23:42  * paddybyersquit (Quit: paddybyers)
07:50:51  * inolenjoined
08:22:15  * paddybyersjoined
08:52:26  <abraxas>that youtube link (topic) cracked me up :)
09:12:44  * bnoordhuisjoined
09:15:39  * kazuponquit (Remote host closed the connection)
09:30:38  <mmalecki>haha, just saw it, hilarious
09:31:01  <mmalecki>bnoordhuis: just finished interviewing for a job in Amsterdam, see you there, hopefully!
09:40:01  * Kakerajoined
09:42:47  * hzquit (Read error: Connection reset by peer)
09:44:01  <bnoordhuis>mmalecki: you did? what company?
09:44:39  <mmalecki>bnoordhuis: vigour.io
09:45:28  <bnoordhuis>hm, don't think i know them. what do they do?
09:45:43  <mmalecki>bnoordhuis: video and mobile stuff with node
09:45:48  <rendar>mmalecki: it seems an interesting company
09:47:45  * mcavagequit (Read error: Connection reset by peer)
09:48:00  * mcavagejoined
09:48:12  <rendar>mmalecki: i've just watched the video, awesome that frames throwing accross screens :)
09:48:16  <mmalecki>rendar: yeah, definitely. demo is certainly nice
09:49:44  <rendar>mmalecki: i guess those little frame-objects have global coordinates in the server, and when are thrown those coordinates are changed, then when the little frame goes inside a new local page, the server updates the page which draws the object with html5..
09:51:09  <mmalecki>heh, I don't actually know how it works yet, but yeah, I'd imagine something like that
09:51:43  <rendar>:)
09:59:43  * hzjoined
10:13:37  * mcavagequit (Ping timeout: 272 seconds)
10:16:55  * mcavagejoined
10:26:00  * hzquit
10:28:50  * bajtosjoined
10:40:22  * AvianFlujoined
10:45:40  * kuebkjoined
10:46:00  <kuebk>hello
10:46:03  <kuebk>how can I fix this
10:46:04  <kuebk>Error: forbidden _npmUser.name must === user.name:
10:46:11  <kuebk>while unpublishing module?
10:46:20  <kuebk>I was able to publish but I'm unable to unpublish
10:48:46  * bajtosquit (Quit: bajtos)
10:53:33  <MI6>nodejs-v0.10: #1540 UNSTABLE smartos-x64 (7/602) smartos-ia32 (8/602) linux-x64 (1/602) linux-ia32 (1/602) osx-x64 (1/602) osx-ia32 (1/602) http://jenkins.nodejs.org/job/nodejs-v0.10/1540/
11:00:21  * hzjoined
11:02:52  <bnoordhuis>mmalecki: are you in amsterdam now?
11:04:40  <mmalecki>bnoordhuis: no, I'm in Poznan, the interview was on Skype
11:08:35  <mmalecki>bnoordhuis: Amsterdam is one of those places I'll definitely visit once someone hires me tho :)
11:14:44  * inolenquit (Quit: Leaving.)
11:17:18  * ibobrikjoined
11:56:24  * abraxasquit (Remote host closed the connection)
12:05:38  * kuebkpart
12:32:58  * inolenjoined
12:37:05  <bnoordhuis>$2 = (v8::internal::OldSpace *) 0x0 <- wut?
13:00:05  <bnoordhuis>weird. only happens when i link to v8::internal::something, even when that's in another compilation unit
13:00:14  <bnoordhuis>spooky action at a distance...
13:01:41  <bnoordhuis>hrm, not even that - it happens when i compile *another* file with -Ideps/v8/src rather -Ideps/v8/include
13:02:07  <bnoordhuis>it doesn't even include anything... i must be overlooking something here
13:04:39  <bnoordhuis>okay, so it does include header files somewhere - and probably the wrong ones
13:05:28  * AvianFluquit (Remote host closed the connection)
13:10:26  * c4milojoined
13:19:23  * inolenquit (Quit: Leaving.)
13:25:43  * c4milo_joined
13:25:57  * dominictarrjoined
13:27:11  * c4miloquit (Read error: No route to host)
13:52:22  * kuebkjoined
13:52:41  * vptrjoined
13:54:41  * AvianFlujoined
13:56:19  * AvianFlu_joined
13:56:24  * AvianFluquit (Disconnected by services)
13:56:25  * AvianFlu_changed nick to AvianFlu
13:57:14  <bnoordhuis>indutny: ping
13:57:52  <bnoordhuis>indutny: does Debugger::EnqueueDebugCommand() in deps/v8/src/debug.cc look safe to you?
13:58:27  <bnoordhuis>you're allowed to call it from another thread. it pushes the command into a lock-protected queue
13:58:51  <bnoordhuis>so far so good but InDebugger() check afterwards is not protected by any memory or compiler barriers
14:00:03  <bnoordhuis>also, isolate->debug() can lazy-load the debugger instance, though that's probably not an issue here
14:08:43  * pachetjoined
14:08:43  * pachetquit (Changing host)
14:08:43  * pachetjoined
14:13:52  * defunctzombie_zzchanged nick to defunctzombie
14:14:57  * c4milo_quit (Remote host closed the connection)
14:15:23  * c4milojoined
14:15:46  <bnoordhuis>okay, filed issue #2936 :)
14:20:21  * c4miloquit (Ping timeout: 272 seconds)
14:48:27  * dshaw_joined
15:01:38  * kuebkpart
15:04:40  * dominictarrquit (Quit: dominictarr)
15:12:24  * dshaw_quit (Quit: Leaving.)
15:13:41  * dominictarrjoined
15:26:22  * mikealquit (Quit: Leaving.)
15:30:18  * defunctzombiechanged nick to defunctzombie_zz
15:30:34  <MI6>nodejs-master: #627 UNSTABLE osx-x64 (2/648) smartos-ia32 (7/648) smartos-x64 (8/648) linux-ia32 (1/648) http://jenkins.nodejs.org/job/nodejs-master/627/
15:35:58  * dominictarrquit (Quit: dominictarr)
15:39:59  * mikealjoined
15:40:23  * AvianFlu_joined
15:40:26  * AvianFluquit (Read error: Connection reset by peer)
15:40:30  * AvianFlu_changed nick to AvianFlu
15:43:23  * Benviejoined
15:44:58  * mikealquit (Quit: Leaving.)
15:45:19  * octetcloudjoined
15:48:43  * philipsquit (Quit: http://ifup.org)
15:51:05  * philipsjoined
16:06:50  * kenperkinsjoined
16:19:25  * bnoordhuisquit (Ping timeout: 272 seconds)
16:20:56  * dshaw_joined
16:21:42  * st_lukejoined
16:22:25  * TooTallNatejoined
16:23:10  * hzquit
16:27:55  * inolenjoined
16:29:58  * sblomjoined
16:30:35  * sblompart
16:30:55  * dap_joined
16:32:53  * dominictarrjoined
16:34:17  <isaacs>ircretary: tell kuebk i missed your message. you can email [email protected], or always just drop a message in irc, and i'll see it when i get back.
16:34:17  <ircretary>isaacs: I'll be sure to tell kuebk
16:35:59  <trevnorris>morning all
16:39:50  * julianduquejoined
16:42:00  <isaacs>g'morning
16:43:26  * amartensjoined
16:45:10  * dap_quit (Quit: Leaving.)
16:47:08  * dominictarrquit (Quit: dominictarr)
16:49:27  * octetcloudquit (Quit: WeeChat 0.4.1)
16:51:52  * julianduquequit (Ping timeout: 246 seconds)
16:53:35  * c4milojoined
16:56:05  * Benvie_joined
16:56:55  * defunctzombie_zzchanged nick to defunctzombie
16:57:34  * inolenquit (Quit: Leaving.)
16:58:07  * Benviequit (Ping timeout: 256 seconds)
16:58:23  * Benviejoined
16:58:45  * octetcloudjoined
17:00:37  * ibobrikquit (Quit: ibobrik)
17:00:41  * Benvie_quit (Ping timeout: 252 seconds)
17:00:52  * brsonjoined
17:02:30  * indexzerojoined
17:03:11  * indexzeroquit (Client Quit)
17:05:10  * c4miloquit (Remote host closed the connection)
17:05:37  * c4milojoined
17:09:19  * dominictarrjoined
17:10:22  * c4miloquit (Ping timeout: 268 seconds)
17:11:41  <tjfontaine>gday
17:12:28  * dominictarrquit (Client Quit)
17:16:03  * Benviequit
17:16:23  * Benviejoined
17:22:48  * indexzerojoined
17:23:29  * mikealjoined
17:23:44  * mikealquit (Client Quit)
17:25:29  * mikealjoined
17:25:37  * wolfeida_joined
17:25:49  * wolfeidauquit (Ping timeout: 246 seconds)
17:26:00  * bnoordhuisjoined
17:27:02  * AvianFluquit (Remote host closed the connection)
17:31:15  * bnoordhuisquit (Ping timeout: 272 seconds)
17:32:00  * AvianFlujoined
17:33:24  * dap_joined
17:33:39  * c4milojoined
17:34:51  * ibobrikjoined
17:44:00  <TooTallNate>tjfontaine: yo yo yo
17:44:21  <tjfontaine>hey
17:46:39  * dominictarrjoined
17:52:20  <othiym23>I'm in the same room as antirez!
17:52:26  <othiym23>it's very exciting
17:52:34  * indexzeroquit (Quit: indexzero)
17:55:14  <MI6>libuv-master: #288 UNSTABLE linux (1/195) windows (3/196) smartos (3/195) http://jenkins.nodejs.org/job/libuv-master/288/
18:00:24  * bnoordhuisjoined
18:01:18  * st_lukequit (Read error: Connection reset by peer)
18:01:29  * st_lukejoined
18:06:26  * jmar777joined
18:07:23  * st_lukequit (Remote host closed the connection)
18:07:51  * st_lukejoined
18:09:12  <MI6>libuv-node-integration: #273 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/273/
18:09:48  * mcavagequit (Remote host closed the connection)
18:10:17  * mcavagejoined
18:11:18  * mcavagequit (Read error: Connection reset by peer)
18:11:19  * mcavage_joined
18:12:36  * mcavage_quit (Remote host closed the connection)
18:12:47  * st_lukequit (Ping timeout: 272 seconds)
18:14:25  * AvianFlu_joined
18:14:25  * AvianFluquit (Disconnected by services)
18:14:40  * AvianFlu_changed nick to AvianFlu
18:14:55  * hzjoined
18:20:12  * dap_quit (Quit: Leaving.)
18:21:04  * dap_joined
18:23:34  * st_lukejoined
18:26:18  * st_lukequit (Remote host closed the connection)
18:46:25  * Ralithjoined
18:46:33  <Ralith>bnoordhuis: you around?
18:48:12  <bnoordhuis>Ralith: yes
18:48:19  <Ralith>\o/
18:48:57  <Ralith>bnoordhuis: ~ a year ago you posted that asynchronous disk IO on linux no longer requires O_DIRECT in all cases; can you clarify/elaborate/link docs?
18:50:13  <bnoordhuis>Ralith: clarify/elaborate, yes - some people from oracle (i believe) posted patches to the LKML that eventually landed
18:50:31  <bnoordhuis>as to linking... i'm not having much luck finding said posts
18:50:53  <Ralith>:/
18:51:04  * st_lukejoined
18:51:22  <Ralith>perhaps a 'git blame' on the relevant bits of the kernel?
18:51:36  * wwicksjoined
18:52:57  <bnoordhuis>Ralith: yeah. fs/aio.c is the file you want
18:53:25  <Ralith>just what I needed, thanks
18:54:01  <bnoordhuis>np
18:55:12  <Ralith>huh, that's got a lot more activity than I expected
18:59:34  * dominictarrquit (Quit: dominictarr)
19:01:55  <Ralith>bnoordhuis: no mention of O_DIRECT in the 2009-10+ range, nor anything else that jumps out at me
19:06:00  <Ralith>(in commit messages, tha tis)
19:06:37  <Ralith>I do see some oracle emails, though
19:07:11  * c4miloquit (Remote host closed the connection)
19:07:37  * c4milojoined
19:07:51  * ibobrikquit (Read error: Connection reset by peer)
19:08:07  <bnoordhuis>Ralith: it was more recent than that, late 2011 or sometime in 2012
19:08:10  * ibobrikjoined
19:09:15  <Ralith>bnoordhuis: + as in 'and later'
19:09:30  <bnoordhuis>ah okay
19:09:43  <Ralith>the oracle patches do report some pretty nice looking improvements, but nothing obviously concerning an expansion of API scope
19:10:03  <bnoordhuis>i'd be surprised if the commit log explicitly mentioned O_DIRECT
19:10:49  <bnoordhuis>probably more along the lines of 'now possible to use the page cache'
19:11:26  <bnoordhuis>admittedly, i can't find the patches either. i thought they landed sometime around 3.4 but i don't see anything relevant
19:11:38  * EhevuTovjoined
19:11:49  <bnoordhuis>i have a notoriously bad memory for dates though
19:12:35  * c4miloquit (Ping timeout: 272 seconds)
19:13:22  <Ralith>only mention of caches I see post-2009 relates to CPU cache friendliness and coherency
19:13:32  * AvianFlu_joined
19:14:29  <Ralith>I suppose I can just try doing aio with a regular FD and see what happens; hard to get that to be as conclusive as I'd like though
19:15:54  <bnoordhuis>it's possible i misremembered the contents of the patch and that it's more a function of the stuff in mm/ than in fs/
19:16:09  <MI6>nodejs-master-windows: #420 UNSTABLE windows-x64 (25/648) windows-ia32 (24/648) http://jenkins.nodejs.org/job/nodejs-master-windows/420/
19:16:18  <bnoordhuis>but why are you so interested in linux aio?
19:16:26  * `3E|GONEquit (Ping timeout: 264 seconds)
19:16:55  * AvianFluquit (Ping timeout: 260 seconds)
19:17:53  <Ralith>hobby interest, mostly, though I work on databases so there's a reasonable chance it'll come up professionally
19:18:35  <Ralith>I've been kind of shocked at how bad aio support is in general, so verifiable improvement there is of interest
19:18:48  <bnoordhuis>right. and yes, it's pretty terrible
19:19:12  <bnoordhuis>but if you work on databases, wouldn't you want to use O_DIRECT always?
19:20:50  <Ralith>I'm honestly not sure. What are the reasons for expecting that to be the case?
19:22:23  <Ralith>(I'd also like to use it in various hobby projects, in which I'd quite like to manage without creating a userspace IO threadpool/scheduler but which aren't likely to actually be terrifyingly performance-sensitive, so it's more of an elegance thing)
19:22:32  <bnoordhuis>well, O_DIRECT exists because of big database vendors
19:23:03  <Ralith>right, I'm aware of that much
19:23:09  <bnoordhuis>the argument is that databases have their own i/o schedulers and disk caches
19:23:21  <bnoordhuis>they don't want the kernel to duplicate that / get in their way
19:23:46  <Ralith>we're building something new from the ground up; if the kernel IO scheduler can be cleanly integrated with, it might make sense to use.
19:23:55  <Ralith>(and cache, and etc)
19:24:09  <bnoordhuis>right. i don't think we're quite there yet
19:24:47  <Ralith>that's a shame
19:24:54  <Ralith>at least it seems like real progress is being made
19:25:14  <bnoordhuis>yeah, but slowly. there doesn't appear to be that much demand for buffered aio
19:26:02  <bnoordhuis>what kind of database are you building?
19:26:09  <Ralith>it seems like there's an immense amount of code that would benefit moderately; libuv itself, for one
19:26:24  <Ralith>http://spacecurve.com/
19:26:26  * Benviequit (Ping timeout: 252 seconds)
19:26:53  <bnoordhuis>ah, interesting
19:27:30  <Ralith>games too; with content streaming becoming such a big thing, IO threadpools are a very common engine component
19:27:46  <Ralith>perhaps not yet a driving concern for the linux kernel I admit
19:28:16  <bnoordhuis>no, indeed
19:28:37  <bnoordhuis>i've been playing around with the idea of writing some patches myself. scratch your own itch and all that
19:28:46  * Ralithnod
19:29:05  <bnoordhuis>but i can't really justify taking two months off or however long it takes
19:31:33  <Ralith>seems like it might be well suited for a bounty program, there being so much code that would benefit significantly yet not enough to justify attacking the problem directly
19:32:13  <bnoordhuis>hrm, yeah. good point. if i ever find myself without a job...
19:32:31  * dap_quit (Quit: Leaving.)
19:33:16  <octetcloud>it seems hugely contentious. seems there are competeing ideas on how to improve, but not enough demand to force one to get merged. the better the solution, the more it seems to cause api changes to echo through the kernel
19:33:41  <octetcloud>"someone else is trying to get aio improvments into mainline" is like a perma topic on lwn.net
19:34:02  <trevnorris>bnoordhuis: thanks for the initial review. :)
19:34:02  <bnoordhuis>yeah, indeed :)
19:34:16  <Ralith>hugely contentious? really?
19:34:26  <bnoordhuis>there's always a lot of resistance from the people with a vested interest in sync aio and/or mm performance
19:34:50  * c4milojoined
19:34:53  <bnoordhuis>there's no hope of getting your patches in if there's the slightest performance regression elsewhere
19:35:11  <bnoordhuis>which makes sense because sync io is the bread and butter of operating systems
19:35:51  <bnoordhuis>that first 'sync aio' should read 'sync io', of course :)
19:36:18  <Ralith>was wondering about that
19:36:56  * c4miloquit (Remote host closed the connection)
19:37:23  * c4milojoined
19:37:36  * EhevuTovquit (Quit: This computer has gone to sleep)
19:38:01  <bnoordhuis>trevnorris: i'm not done yet btw :)
19:38:33  <trevnorris>bnoordhuis: oh I know. only have like 3 comments on the c++ side. knew I wouldn't get away that easy. ;P
19:38:43  * EhevuTovjoined
19:39:12  <octetcloud>Ralith: if you are interested in history, google "site:lwn.net aio" in first couple pages you can find some interesting articles about aio
19:39:17  <Ralith>it surprises me a bit to hear sync IO described as the bread and butter, though; nearly everything these days seems to either use async or suffer from its absence, save trivial command line utils
19:39:21  <Ralith>octetcloud: will do
19:40:58  <bnoordhuis>trevnorris: general observation: you're using lists where you'd probably want a map
19:41:13  <bnoordhuis>trevnorris: am i right in assuming that the queue will usually be (very) short?
19:41:49  <trevnorris>bnoordhuis: yeah. hopefully 2 at the most.
19:42:21  * c4miloquit (Ping timeout: 272 seconds)
19:42:31  <bnoordhuis>okay. you should probably add comments explaining that
19:42:40  <trevnorris>will do.
19:43:01  <bnoordhuis>seeing linear scans over lists makes alarm bells go off in my head. no doubt it's the same for other people
19:43:16  <trevnorris>hah, ok.
19:43:33  <trevnorris>yeah, if they have more than 2 in that list then they're seriously messed up anyways.
19:43:51  <trevnorris>the performance impact from using this feature will way out weight the O(n) scan over the array.
19:44:21  <bnoordhuis>hum, if that's intended as consolance..
19:44:27  <trevnorris>if they set an asyncListener and a before/after callback then they're calling 3 functions for every one we call.
19:44:52  <bnoordhuis>yeah. oh well
19:44:55  <trevnorris>the point of this is to introduce the functionality w/o impacting core performance by it's existence.
19:44:59  <trevnorris>unlike domains did
19:45:44  <bnoordhuis>first we take on domains. next, streams!
19:46:03  <trevnorris>yeah!!!!
19:46:10  <bnoordhuis>i'm only half-joking. it always pains me to see those bogus node vs. go http benchmarks
19:46:11  * `3E|GONEjoined
19:46:12  * `3E|GONEchanged nick to `3rdEden
19:46:19  <bnoordhuis>sometimes node's a little faster, other times go
19:46:23  <trevnorris>all part of a grand plot for the v1.0 release!
19:46:37  <bnoordhuis>it's ridiculous because node should be _destroying_ go
19:46:52  <bnoordhuis>i mean, we should be like 3-5x faster
19:47:18  * indexzerojoined
19:47:25  <trevnorris>sounds like we both have plans for that in v0.13. it'll be interesting to see what we can do.
19:47:27  * julianduquejoined
19:47:32  * hzquit (Disconnected by services)
19:47:36  * hzjoined
19:48:00  <bnoordhuis>well, you've seen what we can do with raw tcp and http_parser bindings
19:48:00  <octetcloud>cluster should be implementable out-of-core, too, its got a few hooks into net and node.js, but not much
19:48:12  <bnoordhuis>oh yeah, i'm all for that
19:48:39  <bnoordhuis>we pulled it into core for what are basically convenience reasons
19:48:51  <bnoordhuis>the out-of-the-box factor, shall we say
19:50:05  <bnoordhuis>trevnorris: so, about http parser performance
19:50:28  <bnoordhuis>one thing i've been thinking is that the current http parser does a lot of work that's subsequently thrown away
19:50:37  <trevnorris>well, i'm interested to see what you guys think about my plan for v0.13. it'll be some serious stuff, but those go guys can go eat shite. :P
19:50:51  <bnoordhuis>when i make a request with curl, it sends like 8-10 http headers
19:50:57  <trevnorris>cool. I haven't looked far into it, but does seem to be a bottleneck.
19:51:30  <bnoordhuis>node duly parses and emits those but most of them are simply ignored by the script
19:51:36  <bnoordhuis>wasteful, is what it is
19:51:42  <trevnorris>yeah. so you thinking a getter/setter approach?
19:51:58  <bnoordhuis>well... lazy parsing is one obvious solution that comes to mind
19:52:20  <trevnorris>sounds like you have another idea in mind.
19:52:33  <bnoordhuis>well, yeah
19:52:42  <bnoordhuis>incompatible with the current api
19:52:42  <trevnorris>coolio. please do tell. :)
19:52:47  <trevnorris>oh. bummer
19:52:54  <bnoordhuis>but what if you could compose your own http parser with a kind of DSL
19:53:07  <bnoordhuis>if you're only interested in, say, the Content-Length and Content-Type header
19:53:23  <bnoordhuis>you'd build a parser that only processes those two headers and skips over the rest
19:53:35  <trevnorris>oh, that's rad.
19:54:13  <trevnorris>well, that be doable if some of my plans are ok'd
19:54:39  <bnoordhuis>what plans in particular?
19:55:05  <trevnorris>take a look at my list of repos for an idea ;) https://github.com/trevnorris?tab=repositories
19:55:29  <trevnorris>basically I think there should be low level js bindings directly into the c++ bindings.
19:55:48  <trevnorris>because almost everything we have js facing in core is covered in sugar
19:56:07  <bnoordhuis>yeah, and sugar is bad for you, everyone knows that
19:56:11  <trevnorris>seriously.
19:56:46  <bnoordhuis>hah, you're squatting module names?
19:56:58  <trevnorris>yeah. did that at like 4am.
19:57:07  <bnoordhuis>haha, evil! :)
19:57:07  <trevnorris>strange things seem like a good idea around then
19:57:23  <trevnorris>so, I'd like to create a set of require('*-wrap') modules that are tightly coupled w/ the c++ counterparts that pretty much our entire api sits on
19:57:55  <trevnorris>it started making more sense while doing the async listeners stuff. like wtf are domains doing so tightly integrated into core.
19:58:28  <bnoordhuis>yeah... domains kind of got slipped in, i think
19:58:39  <trevnorris>and streams are great, but even in the simplest case they make performance difficult.
19:59:06  <trevnorris>and the eventemitter is just freaking evil.
19:59:11  <bnoordhuis>hah, yeah
19:59:24  <bnoordhuis>we can move away from that in core though
19:59:52  <trevnorris>except we "emit()" in like hundreds of places, even for core communication.
20:00:01  <octetcloud>what's so wrong with EE, does v8 hate to optimize it?
20:00:03  <bnoordhuis>yeah, but we can fix that up
20:00:05  <bnoordhuis>octetcloud: yes
20:00:20  <bnoordhuis>it's too polymorphic in any real app to really work for v8
20:01:18  <trevnorris>well, imho I'd like to see something like: var server = new require('tcp-wrap')(); server.connection(fn() { }); server.error(fn() { }); server.listen(8080);
20:01:51  <trevnorris>and that would tie into my plan for tightly coupling the callbacks to the instances themselves.
20:02:01  <trevnorris>instead of needing to access a freakin object property on every MakeCallback
20:03:37  <trevnorris>because server.connection() would tie to a TCPWrap method that sets a Persistent<Function> connection_; that's passed directly to MakeCallback.
20:03:57  <bnoordhuis>oh, i think we can do better
20:04:08  <trevnorris>oooh.
20:04:10  <bnoordhuis>our current apis, both internal and external, are push based
20:04:37  <bnoordhuis>that is, libuv calls a node c++ function. node c++ calls a node js core function and so on
20:04:52  <trevnorris>yeah
20:04:53  * dominictarrjoined
20:04:55  <bnoordhuis>it wouldn't be terribly difficult to rewrite libuv to use a pull-based model
20:05:15  <bnoordhuis>that is, you'd call uv_fetch_events(event_array, num_events, timeout)
20:05:40  <bnoordhuis>and it'd hand you any ready events that you can then process at your leisure
20:06:00  <bnoordhuis>which would let us get rid of the gazillion callbacks into js land
20:06:14  <bnoordhuis>we'd just accumulate them and hand them off to js land in one fell swoop
20:06:23  <trevnorris>seriously. and i'm going to assume that wouldn't affect libuv performance at all?
20:06:38  <bnoordhuis>uv-unix doesn't really care what model you use
20:06:46  <bnoordhuis>uv-win can be made to work with either with some work
20:07:44  <trevnorris>that's a serious change, but the payoff would be dramatic.
20:08:35  <trevnorris>man, the guts of v1.0 aren't going to be anything close to v0.12. :P
20:08:44  <bnoordhuis>heh, indeed :)
20:09:53  <trevnorris>well. this is all awesome stuff. but really need to focus on finishing this freakin patch.
20:15:03  <Ralith>just the other day I was thinking about how nice it'd be for libuv to have an option for that mode of access...
20:15:45  <bnoordhuis>you're not the only one, i get that feature request quite frequently :)
20:15:45  <Ralith>(one of my other projects is a functional programming language wherein it's much easier to integrate select-style calls than callbacks when going over the FFI)
20:16:18  <bnoordhuis>FP you say? can you link me to your project?
20:16:59  <Ralith>to be clear it's not properly *my* project--I'm just a contributor with an eye towards making sure the IO infrastructure comes out right
20:17:02  <Ralith>http://www.idris-lang.org/
20:17:35  <bnoordhuis>ah, idris. yeah, i know of it
20:17:45  <Ralith>most of my work to date has been on integrating with LLVM
20:18:36  * Ralithis always a little surprised by how widespread awareness of idris is, given its early stage
20:19:03  * dap_joined
20:19:10  <bnoordhuis>well, it's mostly because i read LtU a lot :)
20:19:16  <Ralith>heh
20:20:14  <Ralith>right now there's no support at all for creating callbacks C can use; it should be possible to add, but it will require some additional work and place limitations on the RTS
20:21:20  <bnoordhuis>yeah, that's actually one of my motivations for a pull-based model; callback-based mechanism are a pain with almost all ffis
20:21:27  <bnoordhuis>*mechanisms
20:21:34  <Ralith>right
20:21:57  * wwicksquit (Quit: wwicks)
20:22:22  <Ralith>and even in the best case, it's awkward in a functional language where really you want to be doing dispatch from your mainloop into pure (i.e. non-FFI, non side-effecting) code
20:22:57  <Ralith>you can do that with callbacks, of course, but I think it'd require a fair bit of shimming
20:24:05  * hzquit
20:24:50  <Ralith>so is such an interface likely to land in the forseeable future?
20:26:00  <bnoordhuis>sorry, one sec - my kid's awake
20:31:02  * inolenjoined
20:31:57  <bnoordhuis>okay, back
20:32:28  <bnoordhuis>Ralith: foreseeable future... hard to say, it requires a moderate amount of work
20:32:31  * Benviejoined
20:33:28  <bnoordhuis>inolen: you pinged me a few days ago, didn't you?
20:33:30  * inolenquit (Client Quit)
20:33:37  <bnoordhuis>oh, and he's gone again
20:33:48  <Ralith>hm, okay
20:51:33  * mikealquit (Quit: Leaving.)
20:53:02  <trevnorris>bnoordhuis: is there a way to compile node on master w/ i18n support?
20:58:23  * mcavagejoined
21:00:46  * jmar777quit (Remote host closed the connection)
21:01:09  * bnoordhuisquit (Ping timeout: 272 seconds)
21:01:20  * jmar777joined
21:02:22  * AvianFlu_changed nick to AvianFlu
21:05:57  * jmar777quit (Ping timeout: 272 seconds)
21:10:13  * julian_duquejoined
21:10:53  * julianduquequit (Ping timeout: 246 seconds)
21:16:27  * vptrquit (Ping timeout: 272 seconds)
21:16:36  <trevnorris>TooTallNate: ping
21:16:45  <TooTallNate>trevnorris: pong
21:17:08  <trevnorris>TooTallNate: i feel like a moron. how do I pass gyp flags to ./configure?
21:18:39  <trevnorris>TooTallNate: basically I want to set v8_enable_i18n_support: 1
21:18:47  <TooTallNate>trevnorris: we kinda need to add support flags manually
21:18:56  <TooTallNate>trevnorris: so you'd need to edit the configure script
21:18:56  * wwicksjoined
21:18:58  <trevnorris>oh, haha ok.
21:22:08  <trevnorris>TooTallNate: cool. thanks. now, i'm trying to figure out how to get node 0.11 to build with i18n support. I've added the flag manually, and did a bunch of symlinking. bugger.
21:22:15  <trevnorris>anyways. just thinking out loud.
21:23:42  * AvianFluquit (Remote host closed the connection)
21:23:55  <TooTallNate>trevnorris: well we should probably add a --with-i18n flag or something, ya?
21:24:13  <trevnorris>i wish :P
21:24:21  <trevnorris>yeah. we should
21:25:09  * st_lukequit (Remote host closed the connection)
21:25:44  * st_lukejoined
21:26:01  * dshaw_quit (Quit: Leaving.)
21:26:07  * c4milojoined
21:27:15  * c4miloquit (Read error: Connection reset by peer)
21:27:42  * c4milojoined
21:28:19  * dap_quit (Quit: Leaving.)
21:28:44  * c4miloquit (Read error: Connection reset by peer)
21:29:15  * c4milojoined
21:30:16  * c4miloquit (Write error: Connection reset by peer)
21:30:39  * st_lukequit (Ping timeout: 272 seconds)
21:30:47  * c4milojoined
21:31:49  * c4miloquit (Read error: Connection reset by peer)
21:32:15  * c4milojoined
21:32:31  * wwicksquit (Quit: wwicks)
21:32:48  * amartensquit (Quit: Leaving.)
21:33:23  * dap_joined
21:36:07  * st_lukejoined
21:36:22  <trevnorris>freak yeah. finally got Intl in a node build. so freakin strange.
21:37:37  * c4miloquit (Ping timeout: 272 seconds)
21:39:30  * st_luke_joined
21:40:00  * c4milojoined
21:40:47  * st_lukequit (Ping timeout: 272 seconds)
21:41:09  * c4miloquit (Read error: Connection reset by peer)
21:41:38  * c4milojoined
21:42:15  * vptrjoined
21:42:23  * AvianFlujoined
21:42:52  * c4miloquit (Read error: Connection reset by peer)
21:43:08  * c4milojoined
21:44:09  * c4miloquit (Read error: Connection reset by peer)
21:44:35  * st_luke_quit (Ping timeout: 272 seconds)
21:44:39  * c4milojoined
21:45:46  * c4miloquit (Read error: Connection reset by peer)
21:46:10  * c4milojoined
21:47:11  * c4miloquit (Read error: Connection reset by peer)
21:47:42  * c4milojoined
21:48:42  * c4miloquit (Read error: Connection reset by peer)
21:49:13  * c4milojoined
21:50:13  * c4miloquit (Read error: Connection reset by peer)
21:50:25  * vptrquit (Ping timeout: 246 seconds)
21:50:45  * c4milojoined
21:51:43  * c4miloquit (Read error: Connection reset by peer)
21:52:13  * c4milojoined
21:52:41  <TooTallNate>trevnorris: i think you want something like this https://cloudup.com/iLaMNqXM3gM
21:53:16  * c4miloquit (Read error: Connection reset by peer)
21:53:43  * c4milojoined
21:54:09  <trevnorris>TooTallNate: ok, my only thought is that in v8 3.22 there're other options that come with (e.g. use system icu, where is the icu.gyp file, etc) so using that would say we only support one way of including i18n support.
21:54:15  <trevnorris>honestly, I really don't care much.
21:54:26  <trevnorris>i'm just addressing what the community is telling me they're looking for.
21:54:47  * c4miloquit (Read error: Connection reset by peer)
21:55:20  * c4milojoined
21:55:20  * dominictarrquit (Quit: dominictarr)
21:55:22  <TooTallNate>trevnorris: so where is icu.gyp then?
21:55:36  * AvianFluquit (Remote host closed the connection)
21:55:44  <trevnorris>TooTallNate: it's in deps/v8/third_party/icu after you've run make dependencies in the deps/v8 folder
21:55:49  <trevnorris>currently
21:56:00  <TooTallNate>trevnorris: does v8 not normally bundle it?
21:56:08  <TooTallNate>i'm confused why we have to specify where the gyp file is
21:56:18  * c4miloquit (Read error: Connection reset by peer)
21:56:51  * c4milojoined
21:57:26  <trevnorris>TooTallNate: maybe this will help clarify some things? https://github.com/joyent/node/issues/4689#issuecomment-26517580
21:57:49  * c4miloquit (Read error: Connection reset by peer)
21:58:20  * c4milojoined
21:58:22  <trevnorris>honestly I just learned about this stuff 2 days ago accientally when I tried to upgrade node to 3.22
21:58:32  <trevnorris>stuff meaning i18n
21:58:38  * abraxasjoined
21:58:58  <TooTallNate>lol
21:59:03  <TooTallNate>trevnorris: ok makes more sense now
21:59:20  * c4miloquit (Read error: Connection reset by peer)
21:59:23  <TooTallNate>so sounds like the only options really are use the system installed ICU or not
21:59:29  <TooTallNate>or am I missing some other ones?
21:59:37  <trevnorris>no, not that I'm aware of.
21:59:49  <TooTallNate>trevnorris: are we planning on bundling icu?
21:59:50  * c4milojoined
22:00:04  <trevnorris>but everyone says that the 300MB repo that v8 grabs is way bloated. and that the real support is only 2-4MB
22:00:07  <trevnorris>and I sure hope not
22:00:22  <trevnorris>we don't need yet _another_ folder in deps
22:00:27  <TooTallNate>lol
22:00:38  <TooTallNate>well i mean if chrome bundles it then i don't see why we shouldn't
22:00:44  <trevnorris>I was thinking more that we could do the same thing and grab it after the fact if they pass the config flag
22:00:52  * c4miloquit (Read error: Connection reset by peer)
22:00:59  <TooTallNate>do what same thing?
22:01:19  <trevnorris>meaning, it goes out and downloads the package
22:01:24  * c4milojoined
22:02:00  <trevnorris>the stuff in deps are things that are always built with node, but I don't think i18n support should be
22:02:12  <trevnorris>so it shouldn't go in the deps folder, or at least included by default.
22:02:22  * c4miloquit (Read error: Connection reset by peer)
22:02:55  * c4milojoined
22:03:07  * octetcloudquit (Quit: WeeChat 0.4.2)
22:03:35  * abraxasquit (Ping timeout: 272 seconds)
22:03:53  * c4miloquit (Read error: Connection reset by peer)
22:04:25  * c4milojoined
22:05:25  * c4miloquit (Read error: Connection reset by peer)
22:05:53  * rendarquit
22:05:57  * c4milojoined
22:06:55  * c4miloquit (Read error: Connection reset by peer)
22:07:27  * c4milojoined
22:08:16  * octetcloudjoined
22:08:30  * c4miloquit (Read error: Connection reset by peer)
22:08:56  * c4milojoined
22:10:00  * c4miloquit (Read error: Connection reset by peer)
22:10:28  * c4milojoined
22:11:28  * c4miloquit (Read error: Connection reset by peer)
22:11:58  * c4milojoined
22:13:00  * c4miloquit (Read error: Connection reset by peer)
22:13:29  * c4milojoined
22:14:30  * c4miloquit (Read error: Connection reset by peer)
22:15:00  * c4milojoined
22:16:12  * c4miloquit (Read error: Connection reset by peer)
22:16:31  * c4milojoined
22:17:32  * c4miloquit (Read error: Connection reset by peer)
22:18:02  * indexzeroquit (Quit: indexzero)
22:18:02  * c4milojoined
22:19:03  * c4miloquit (Read error: Connection reset by peer)
22:19:35  * c4milojoined
22:20:38  * c4miloquit (Read error: Connection reset by peer)
22:21:05  * c4milojoined
22:22:08  * c4miloquit (Read error: Connection reset by peer)
22:22:35  * c4milojoined
22:23:42  * c4miloquit (Read error: Connection reset by peer)
22:24:07  * c4milojoined
22:25:06  * c4miloquit (Read error: Connection reset by peer)
22:25:36  * c4milojoined
22:26:39  * c4miloquit (Read error: Connection reset by peer)
22:27:10  * c4milojoined
22:28:13  * c4miloquit (Read error: Connection reset by peer)
22:28:40  * c4milojoined
22:29:40  * c4miloquit (Read error: Connection reset by peer)
22:30:10  * c4milojoined
22:30:49  * amartensjoined
22:31:11  * c4miloquit (Read error: Connection reset by peer)
22:31:41  * c4milojoined
22:32:42  * c4miloquit (Read error: Connection reset by peer)
22:33:11  * c4milojoined
22:34:14  * c4miloquit (Read error: Connection reset by peer)
22:34:46  * c4milojoined
22:34:55  * dominictarrjoined
22:35:47  * c4miloquit (Read error: Connection reset by peer)
22:36:14  * c4milojoined
22:37:16  * c4miloquit (Read error: Connection reset by peer)
22:37:46  * c4milojoined
22:38:46  * c4miloquit (Read error: Connection reset by peer)
22:39:19  * c4milojoined
22:39:25  * pachetquit (Quit: leaving)
22:39:43  <Domenic_>It's part of the js engine, it should be included by default
22:39:54  <Domenic_>The intl global is part of the ES spec
22:40:17  * c4miloquit (Read error: Connection reset by peer)
22:40:50  * c4milojoined
22:41:52  * c4miloquit (Read error: Connection reset by peer)
22:42:18  * c4milojoined
22:43:20  * c4miloquit (Read error: Connection reset by peer)
22:43:52  * c4milojoined
22:44:49  <trevnorris>othiym23: ping
22:44:50  * c4miloquit (Read error: Connection reset by peer)
22:45:20  * c4milojoined
22:46:21  * c4miloquit (Read error: Connection reset by peer)
22:46:50  * c4milojoined
22:47:15  * indexzerojoined
22:47:52  * c4miloquit (Read error: Connection reset by peer)
22:48:23  * c4milojoined
22:49:22  * c4miloquit (Read error: Connection reset by peer)
22:49:53  * c4milojoined
22:50:54  * c4miloquit (Read error: Connection reset by peer)
22:51:23  * c4milojoined
22:52:25  * c4miloquit (Read error: Connection reset by peer)
22:52:57  * c4milojoined
22:53:56  * c4miloquit (Read error: Connection reset by peer)
22:54:27  * c4milojoined
22:55:27  * c4miloquit (Read error: Connection reset by peer)
22:55:56  * c4milojoined
22:56:58  * c4miloquit (Read error: Connection reset by peer)
22:57:09  * Kakeraquit (Ping timeout: 272 seconds)
22:57:27  * c4milojoined
22:58:01  * AvianFlujoined
22:58:29  * c4miloquit (Read error: Connection reset by peer)
22:59:01  * c4milojoined
22:59:02  * wolfeida_changed nick to wolfeidau
23:00:05  * c4miloquit (Read error: Connection reset by peer)
23:00:31  * c4milojoined
23:01:36  * c4miloquit (Read error: Connection reset by peer)
23:02:05  * c4milojoined
23:03:04  * c4miloquit (Read error: Connection reset by peer)
23:03:33  * c4milojoined
23:03:39  * dshaw_joined
23:04:19  <othiym23>trevnorris: pong
23:04:33  * c4miloquit (Read error: Connection reset by peer)
23:04:55  * dshaw_quit (Client Quit)
23:05:05  <trevnorris>othiym23: so, right now if there's an unhandled error it throws a TypeError. can you think of any reason people would depend on it being a TypeError and not just an Error?
23:05:06  * c4milojoined
23:05:48  <othiym23>god I hope not
23:06:02  <trevnorris>ok cool.
23:06:04  <othiym23>people who dispatch on error type in JS are bad people
23:06:06  * c4miloquit (Read error: Connection reset by peer)
23:06:09  <trevnorris>heh
23:06:37  * c4milojoined
23:07:04  <trevnorris>othiym23: in a few i'll have another build for you to try.
23:07:32  <othiym23>trevnorris: cool (cc groundwater_)
23:07:37  * c4miloquit (Read error: Connection reset by peer)
23:08:06  * c4milojoined
23:09:06  * c4miloquit (Read error: Connection reset by peer)
23:09:39  * c4milojoined
23:10:37  * c4miloquit (Read error: Connection reset by peer)
23:11:11  * c4milojoined
23:12:09  * c4miloquit (Read error: Connection reset by peer)
23:12:40  * c4milojoined
23:13:25  * indexzeroquit (Quit: indexzero)
23:13:40  * c4miloquit (Read error: Connection reset by peer)
23:14:12  * c4milojoined
23:15:13  * c4miloquit (Read error: Connection reset by peer)
23:15:42  * c4milojoined
23:16:41  * c4miloquit (Read error: Connection reset by peer)
23:17:14  * c4milojoined
23:18:13  * c4miloquit (Read error: Connection reset by peer)
23:18:42  * c4milojoined
23:19:45  * c4miloquit (Read error: Connection reset by peer)
23:20:15  * c4milojoined
23:20:19  <trevnorris>Domenic_: ping
23:21:14  * c4miloquit (Read error: Connection reset by peer)
23:21:45  * c4milojoined
23:21:58  <trevnorris>Domenic_: I summon you from the depths of the cosmos. PING
23:22:22  <tjfontaine>what do you need? :)
23:22:44  <trevnorris>need to talk w/ him about the contextify changes.
23:22:45  * c4miloquit (Read error: Connection reset by peer)
23:22:50  <tjfontaine>what about them?
23:23:17  * c4milojoined
23:23:22  <trevnorris>namely in ContextifyScript he inherits from WeakObject passing args.This() as the Object, which makes it a Persistent, but then never cleans it up.
23:23:44  <trevnorris>and it floats around after the class has been cleaned up
23:23:50  <tjfontaine>I thought he inherited objectwrap and then it got changed to weakobject?
23:24:00  <trevnorris>yeah
23:24:02  <tjfontaine>in the secondary pass, not necessarily by him
23:24:17  <trevnorris>either way, the point is a Persistent is created but never cleaned up.
23:24:17  * c4miloquit (Read error: Connection reset by peer)
23:24:27  * julian_duquequit (Quit: leaving)
23:24:33  <trevnorris>and if I do clean it up then the program segfaults
23:24:43  <tjfontaine>there's no destructor for weak objects that cleans up?
23:24:47  * c4milojoined
23:24:48  <trevnorris>nope
23:24:55  <trevnorris>it's up to the inheriting class to cleanup after themselves.
23:25:02  <tjfontaine>that seems subpar
23:25:19  <tjfontaine>I mean this is c++
23:25:41  <trevnorris>well, it's currently necessary becase there are places where the Persistent is cleaned up before the destructor is run
23:25:48  * c4miloquit (Read error: Connection reset by peer)
23:25:51  <trevnorris>say, for example, if the class were to be reused for another connection
23:26:04  <tjfontaine>I'm not advocating all things need to work like this
23:26:14  <tjfontaine>just that there's still a reason to use objectwrap
23:26:20  * c4milojoined
23:26:26  <trevnorris>anyways, still besides the point.
23:26:45  <tjfontaine>if there's a contextify + weakobject problem, it seems like that was introduced with the weakobject refactor
23:27:16  <tjfontaine>just like what happened with zlib and ref counting
23:27:18  * c4miloquit (Read error: Connection reset by peer)
23:27:47  * AvianFluquit (Remote host closed the connection)
23:27:48  * c4milojoined
23:28:16  * AvianFlujoined
23:28:50  * AvianFlu_joined
23:28:50  * AvianFlu_quit (Remote host closed the connection)
23:28:50  * c4miloquit (Read error: Connection reset by peer)
23:29:07  * Benviequit (Ping timeout: 256 seconds)
23:29:20  * c4milojoined
23:29:27  * AvianFlu_joined
23:30:23  * c4miloquit (Read error: Connection reset by peer)
23:30:53  * c4milojoined
23:31:51  * c4miloquit (Read error: Connection reset by peer)
23:32:22  * c4milojoined
23:32:29  * julianduquejoined
23:32:57  * AvianFluquit (Ping timeout: 252 seconds)
23:33:22  * c4miloquit (Read error: Connection reset by peer)
23:33:52  * c4milojoined
23:34:55  * c4miloquit (Read error: Connection reset by peer)
23:35:27  * c4milojoined
23:36:24  * c4miloquit (Read error: Connection reset by peer)
23:36:57  * c4milojoined
23:37:30  <trevnorris>tjfontaine: except, he never called ObjectWrap::Ref()
23:38:01  * c4miloquit (Read error: Connection reset by peer)
23:38:25  * c4milojoined
23:39:21  * pachetjoined
23:39:30  * c4miloquit (Read error: Connection reset by peer)
23:39:57  * c4milojoined
23:43:42  * c4miloquit (Read error: Connection reset by peer)
23:43:50  * c4milo_joined
23:44:52  * c4milo_quit (Read error: Connection reset by peer)
23:45:22  * c4milojoined
23:46:23  * c4miloquit (Read error: Connection reset by peer)
23:46:54  * c4milojoined
23:47:55  * c4miloquit (Read error: Connection reset by peer)
23:48:24  * c4milojoined
23:49:35  * c4miloquit (Read error: Connection reset by peer)
23:49:56  * c4milojoined
23:50:26  * julianduquequit (Ping timeout: 245 seconds)
23:50:58  * c4miloquit (Read error: Connection reset by peer)
23:51:25  * c4milojoined
23:52:28  * c4miloquit (Read error: Connection reset by peer)
23:53:00  * c4milojoined
23:54:00  * c4miloquit (Read error: Connection reset by peer)
23:54:30  * c4milojoined
23:55:31  * c4miloquit (Read error: Connection reset by peer)
23:56:00  * c4milojoined
23:56:10  * c4miloquit (Remote host closed the connection)