00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:02:15  <isaacs>trevnorris: quick review?
00:02:16  <isaacs>https://github.com/isaacs/node/compare/qs-options-object?expand=1
00:03:10  <isaacs>yet again relearning that the correct maximum number of arguments to any function is 2
00:03:20  <trevnorris>heh
00:03:21  <isaacs>almost always
00:04:18  * AvianFluquit (Remote host closed the connection)
00:05:59  <isaacs>oh, probably wanan do the util._extend() trick on that.
00:06:09  <isaacs>so we don't mutate the arg
00:06:11  <trevnorris>isaacs: lgtm, only thing I might say is if they pass a string for seq_ then it's be asinine of them to pass an object as the third argument overriding one of the others, but guess we still need to check for that :-/
00:06:20  <isaacs>yeah
00:06:26  <othiym23>I would be so much happier with the node ecosystem if we'd all never decided to get clever with dynamic overloading / weird variadic argument-passing patterns
00:06:27  <isaacs>because eq was optional also
00:06:30  <isaacs>yeah
00:06:31  <isaacs>srsly
00:06:39  <isaacs>but, well... that ship has sailed.
00:06:40  * AvianFlujoined
00:06:45  <othiym23>yup
00:06:46  <othiym23>just sayin
00:07:37  <trevnorris>alright, out for a bit.
00:07:38  * trevnorris&
00:07:39  <LOUDBOT>I MADE A HAND TURKEY WITH MY DONG
00:07:48  <trevnorris>... wow LOUDBOT
00:07:54  <othiym23>yaaaay
00:08:14  <othiym23>LOLOLOL
00:08:22  <isaacs>LOUDBOT: show othiym23 your soul
00:08:22  <LOUDBOT>isaacs: I'M POKIN THE WOMEN, YO.
00:08:34  <isaacs>LOUDBOT: inappropriate in every situation.
00:08:34  <LOUDBOT>isaacs: I DON'T KNOW. THEY'RE ALREADY DEAD AND SCIENTIFIC ZOMBIE COOTER STUMPS
00:08:38  <isaacs>Good point.
00:09:02  <othiym23>LOUDBOT is at least as sentient and self-aware as 95% of Reddit
00:16:01  <isaacs>LOUDBOT: search reddit
00:16:01  <LOUDBOT>isaacs: <dmd:#mefi> THERE IS ACTUALLY REDDIT GOLD NOW
00:16:06  <isaacs>LOUDBOT: next
00:16:06  <LOUDBOT>isaacs: <BP:#mefi> WHY IS THERE NO CAPS LOCK DAY ON REDDIT
00:16:09  <isaacs>LOUDBOT: next
00:16:09  <LOUDBOT>isaacs: <simcop2387-lap:##turtles> DIGG AND REDDIT ARE ATTEMPTS TO REPLACE SLASHDOT EDITORS WITH A SMALL SHELL SCRIPT
00:16:12  <isaacs>LOUDBOT: next
00:16:12  <LOUDBOT>isaacs: <kulp:#peltkore> I DEMAND STATISTICAL SIGNIFICANCE OR AT LEAST REDDIT REFERENCES
00:16:18  <isaacs>LOUDBOT: twitlast
00:16:18  <LOUDBOT>http://twitter.com/LOUDBOT/status/369613828608102400 (kulp/#peltkore)
00:17:30  * icarotquit (Ping timeout: 245 seconds)
00:20:33  * dshaw_quit (Quit: Leaving.)
00:27:58  <MI6>joyent/node: Raynos master * 6ed861d : events: have events module exports EventEmitter - http://git.io/GK84SA
00:30:22  <isaacs>trevnorris: ok, i got this to happen, FINALLY
00:30:24  <isaacs>=== release test-http-client-agent ===
00:30:24  <isaacs>Path: simple/test-http-client-agent
00:30:24  <isaacs>assert.js:92
00:30:24  <isaacs> throw new assert.AssertionError({
00:30:26  <isaacs> ^
00:30:29  <isaacs>AssertionError: 1 == 2
00:30:32  <isaacs> at Socket.<anonymous> (/Users/isaacs/dev/js/node-master/test/simple/test-http-client-agent.js:56:16)
00:30:35  <isaacs> at Socket.EventEmitter.emit (events.js:125:20)
00:30:37  <isaacs> at TCP.close (net.js:458:12)
00:31:50  <MI6>nodejs-master-windows: #244 UNSTABLE windows-x64 (25/629) windows-ia32 (20/629) http://jenkins.nodejs.org/job/nodejs-master-windows/244/
00:35:53  * paulfryzelquit (Remote host closed the connection)
00:36:20  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:36:23  * amartensquit (Quit: Leaving.)
00:36:30  * paulfryzeljoined
00:37:15  <MI6>nodejs-master: #449 UNSTABLE smartos-x64 (9/629) smartos-ia32 (3/629) osx-x64 (2/629) osx-ia32 (1/629) linux-ia32 (2/629) linux-x64 (2/629) http://jenkins.nodejs.org/job/nodejs-master/449/
00:39:39  * dshaw_joined
00:40:37  * paulfryzelquit (Ping timeout: 248 seconds)
00:40:57  * ecrquit (Quit: ecr)
00:42:18  * dapquit (Quit: Leaving.)
00:43:39  * dshaw_quit (Client Quit)
00:43:48  <MI6>joyent/node: isaacs master * 85d6b78 : test: Remove unnecessary assertion - http://git.io/Qa_zjw
00:52:21  * icarotjoined
00:53:07  <MI6>nodejs-master: #450 UNSTABLE smartos-x64 (10/629) smartos-ia32 (3/629) osx-x64 (1/629) osx-ia32 (1/629) linux-ia32 (1/629) linux-x64 (1/629) http://jenkins.nodejs.org/job/nodejs-master/450/
00:53:38  * groundwaterquit (Quit: groundwater)
00:55:47  * dshaw_joined
00:55:50  * EhevuTovquit (Quit: This computer has gone to sleep)
00:56:04  * sblomquit (Ping timeout: 256 seconds)
00:56:05  <MI6>joyent/node: isaacs v0.10 * 26a8c0c : doc: Minor typos in dgram doc - http://git.io/5vHOLA
01:03:52  <MI6>nodejs-v0.10-windows: #158 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/158/
01:04:19  * dshaw_quit (Quit: Leaving.)
01:05:51  <MI6>libuv-master-gyp: #113 FAILURE windows-x64 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/113/
01:06:31  <MI6>nodejs-v0.10: #1431 UNSTABLE osx-ia32 (1/597) osx-x64 (1/597) linux-ia32 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1431/
01:13:13  <Domenic_>would you lovely gents like vm2 packaged up into one commit, or into the several i've left it in?
01:23:35  * c4miloquit (Remote host closed the connection)
01:26:09  * dshaw_joined
01:27:52  <tjfontaine>isaacs was on triage duty today I see
01:28:33  <tjfontaine>I'm going to try and be on the call tomorrow, at least in textual form from the plane
01:31:09  * c4milojoined
01:36:23  * jmar777joined
01:38:56  * abraxasjoined
01:41:04  * jmar777quit (Remote host closed the connection)
01:41:55  * jmar777joined
01:42:28  * jmar777quit (Remote host closed the connection)
01:43:27  <MI6>nodejs-master-windows: #245 UNSTABLE windows-x64 (18/629) windows-ia32 (22/629) http://jenkins.nodejs.org/job/nodejs-master-windows/245/
01:49:28  * icarotquit (Ping timeout: 260 seconds)
01:52:55  * dshaw_quit (Quit: Leaving.)
02:05:52  * st_lukejoined
02:20:16  * pfox__quit (Ping timeout: 260 seconds)
02:20:53  * amartensjoined
02:33:00  * TooTallNatejoined
02:43:53  * pfox__joined
02:49:46  * mikealjoined
03:02:10  * swajrjoined
03:22:25  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:26:45  * mikealquit (Quit: Leaving.)
03:50:10  * c4miloquit (Remote host closed the connection)
03:54:05  * dominictarrjoined
04:02:55  * inolenquit (Quit: Leaving.)
04:04:03  * dominictarrquit (Quit: dominictarr)
04:06:23  * st_lukequit (Remote host closed the connection)
04:07:03  * amartensquit (Read error: Connection reset by peer)
04:07:35  * indexzeroquit (Quit: indexzero)
04:10:47  * mikealjoined
04:15:56  <MI6>nodejs-v0.10-windows: #159 UNSTABLE windows-ia32 (7/597) windows-x64 (7/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/159/
04:17:40  * amartensjoined
04:20:28  * jmar777joined
04:24:30  * bnoordhuisjoined
04:24:52  * mikealquit (Quit: Leaving.)
04:25:08  * wolfeidauquit (Remote host closed the connection)
04:25:44  <pfox__>bnoordhuis: any ways to do seek, tell or flush on uv fd's ?
04:25:49  <pfox__>via the uv api, that is.
04:28:17  * amartensquit (Quit: Leaving.)
04:30:01  <bnoordhuis>pfox__: seek/tell: no, on purpose. that's hazardous when you have concurrent readers or writers
04:30:29  <bnoordhuis>what would you want to flush on a file descriptor? raw i/o is not buffered
04:31:22  * pfox__nods.
04:32:58  * groundwaterjoined
04:33:58  <brson>bnoordhuis: by concurrent readers do you mean multiple readers accessing the same handle?
04:34:04  <bnoordhuis>brson: yes
04:34:28  <bnoordhuis>that is, assuming pfox__ is talking about the uv_fs_*() family of functions
04:34:40  <brson>and is there any prospect of adding seek/tell? we don't have concurrent readers and writers
04:35:08  <bnoordhuis>the last time someone requested that i told him 'no'
04:35:23  <bnoordhuis>and i'd really rather not add it because people will misuse it
04:36:29  <bnoordhuis>in case you're wondering why in that case we have non-positional write() and read() wrappers, node.js v0.4 compatibility :-/
04:36:51  <brson>how reasonable would it be to access the underlying fd and call seek/tell ourselves?
04:37:04  <pfox__>we have the raw fd..
04:37:21  <bnoordhuis>^ that :)
04:37:31  <pfox__>but i assume that all bets are off after that
04:37:46  <pfox__>we'd probably have to keep state of where the last was to, etc
04:37:58  <pfox__>last seek was to*
04:38:06  <brson>for what purpose?
04:38:09  <bnoordhuis>yeah. and then you might as well use positional reads and writes :)
04:38:27  <brson>ah
04:39:00  <pfox__>true.
04:39:00  <brson>i'm not fully up to speed on non-positional vs positional
04:39:11  <pfox__>uv_fs_write|read has an offset arg
04:39:18  <pfox__>so we could keep the seek offset in FileStream
04:39:21  <pfox__>and use it as the offset
04:40:15  <brson>so uv's default write and read do their own seek based on a provided offset?
04:40:35  * brsonshould really do some research before butting in
04:40:51  <pfox__>brson: no, no. really this was my bad for dragging you in here.
04:41:09  <pfox__>it's more apparent how to proceed
04:41:31  <bnoordhuis>brson: libuv hands it off to the operating system. positional reads/writes are basically wrappers for pread() and pwrite()
04:41:44  * indexzerojoined
04:41:52  <bnoordhuis>with some special love and care on os x where pread() and pwrite() are broken
04:42:28  <brson>i see. was not even aware of pread/write
04:43:10  <bnoordhuis>well, now you know
04:43:18  <bnoordhuis>and like gi joe used to say, knowing is half the battle
04:43:19  <pfox__>woo. FileStream smoke test passes.
04:44:28  <brson>bnoordhuis: thanks
04:45:49  <bnoordhuis>np
04:53:26  * einaros_quit (Remote host closed the connection)
04:54:08  * einarosjoined
04:59:25  <chrisdickinson>isaacs: might be late to the party, but the bug looks to be here: https://github.com/joyent/http-parser/blob/master/http_parser.c#L967
04:59:54  <chrisdickinson>*the invalid-but-accepted "GEM" / "PUN" methods
05:00:25  * Damn3dquit (Ping timeout: 245 seconds)
05:02:10  * Damn3djoined
05:10:07  * mikealjoined
05:16:01  * brsonquit (Quit: leaving)
05:18:59  * jmar777quit (Remote host closed the connection)
05:20:29  * mikealquit (Quit: Leaving.)
05:30:43  <MI6>nodejs-master-windows: #246 UNSTABLE windows-x64 (20/629) windows-ia32 (23/629) http://jenkins.nodejs.org/job/nodejs-master-windows/246/
05:31:23  * mikealjoined
05:32:16  * julianduquequit (Quit: leaving)
05:44:56  * bajtosjoined
05:46:15  * dshaw_joined
05:46:16  * dshaw_quit (Client Quit)
05:52:30  * bajtosquit (Quit: bajtos)
05:59:05  * groundwaterquit (Quit: groundwater)
06:06:05  <trevnorris>isaacs: glad to see you've gotten it to fail.
06:06:08  <trevnorris>bnoordhuis: hey dude
06:07:47  <bnoordhuis>trevnorris: sup trevor?
06:09:01  <trevnorris>bnoordhuis: have a theoretical tcp server example using node.c. when you have time, mind giving some feedback on the api? https://github.com/trevnorris/node.c/blob/master/samples/tcp_simple.c
06:21:02  * porcojoined
06:21:07  * porcopart
06:22:20  * amartensjoined
06:22:23  * amartensquit (Client Quit)
06:25:41  <bnoordhuis>trevnorris: hrm, okay. i'll see what i can do
06:25:58  <bnoordhuis>i have to work my way through 10,000 emails first though :-/
06:26:29  <trevnorris>hah. no worries. nothing serious at all.
06:32:40  * defunctzombie_zzchanged nick to defunctzombie
06:39:58  * kazuponjoined
06:46:56  * dshaw_joined
06:49:48  * philipsquit (Read error: Connection reset by peer)
06:50:46  * philipsjoined
06:51:31  * dshaw_quit (Ping timeout: 264 seconds)
06:53:46  * stagasjoined
06:56:35  <trevnorris>well, see ya in standup tomorrow.
06:56:37  * trevnorris&
06:56:38  <LOUDBOT>ALL THE THINGS SHE SAID ALL THE THINGS SHE SAID RUNNIN THROUGH MY HEAD RUNNIN THROUGH MY HEAD RUNNING THROUGH MY HEAD
07:05:23  <bnoordhuis>tomorrow? today he means
07:53:20  * bnoordhuisquit (Ping timeout: 245 seconds)
08:01:07  * `3rdEdenchanged nick to `3E|AFK
08:02:05  * hzjoined
08:15:22  * dominictarrjoined
08:22:21  * hzquit (Ping timeout: 264 seconds)
08:23:41  * hzjoined
08:41:50  * dominictarrquit (Quit: dominictarr)
08:47:16  * hzquit
08:53:32  <MI6>nodejs-v0.10-windows: #160 UNSTABLE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/160/
09:02:10  * dominictarrjoined
09:03:22  * bnoordhuisjoined
09:04:05  <indutny>bnoordhuis: hoya
09:04:09  <indutny>morning
09:04:54  <MI6>joyent/libuv: Fedor Indutny master * 303ae3b : fsevents: FSEvents is most likely not thread-safe - http://git.io/zlzlIA
09:19:30  <MI6>libuv-master-gyp: #114 UNSTABLE windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (4/193) linux-x64 (1/192) http://jenkins.nodejs.org/job/libuv-master-gyp/114/
09:22:05  <MI6>libuv-master: #174 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/174/
09:28:40  * stagasquit (Read error: Connection reset by peer)
09:35:39  <MI6>libuv-node-integration: #157 UNSTABLE smartos-ia32 (3/629) osx-ia32 (1/629) linux-x64 (1/629) linux-ia32 (1/629) osx-x64 (1/629) smartos-x64 (10/629) http://jenkins.nodejs.org/job/libuv-node-integration/157/
09:43:39  <bnoordhuis>indutny: sup fedor?
09:43:54  <indutny>everything is good
09:44:02  <indutny>I just thought at first that you've reverted my commit
09:44:09  <indutny>but then I realized that I just forgot to push it
09:44:09  <indutny>:)
09:44:14  <bnoordhuis>hah :)
09:46:30  <bnoordhuis>we're on HN btw: https://news.ycombinator.com/item?id=6240437
09:46:45  <indutny>haha
09:46:47  <indutny>yeah, I seen it
09:46:50  <bnoordhuis>i read the comments. bad idea
09:47:05  <bnoordhuis>HN really has detoriated over the years
09:47:13  <bnoordhuis>or at least, the quality of the comments has
09:47:57  <indutny>"I highly recommend to anyone to avoid using Node in production until its developers grow up, and become responsible for a stable API, and not change their minds every 2 months."
09:48:05  <bnoordhuis>yeah
09:48:15  <bnoordhuis>i higly recommend you stfu, HN commenter
09:49:22  <bnoordhuis>or at least know what you're talking about first
09:50:10  <bnoordhuis>ah well, the internet is full of stupid people. HN is probably not much worse than other places
09:50:36  <bnoordhuis>enough griping - what are you working on, fedor?
09:52:30  <indutny>FSEvents
09:55:34  * rendarjoined
09:57:03  <indutny>you?
10:02:42  <bnoordhuis>multi-context again :-/
10:03:16  <bnoordhuis>it's useful work but also pretty mind-numbing
10:13:24  * kazuponquit (Remote host closed the connection)
10:35:23  <indutny>haha
10:35:25  <indutny>yeah
10:42:38  * rendarquit (Ping timeout: 240 seconds)
10:45:14  <MI6>nodejs-v0.10: #1432 UNSTABLE smartos-x64 (1/597) osx-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1432/
10:57:03  * indexzeroquit (Quit: indexzero)
11:08:50  * AvianFluquit (Remote host closed the connection)
11:18:22  * kazuponjoined
11:19:34  * abraxasquit (Remote host closed the connection)
11:22:17  * kazupon_joined
11:22:51  * kazuponquit (Read error: Connection reset by peer)
11:29:08  * defunctzombiechanged nick to defunctzombie_zz
11:39:01  * hzjoined
11:48:00  <indutny>bnoordhuis: do you think its important to get that FSEvents fix into 0.10?
11:48:15  <indutny>I don't really like to preserve ABI with this patch
11:48:24  <indutny>there're a lot of stuff that could be removed from handles
11:48:30  <indutny>and one field that I'll need in uv_loop_t
11:51:00  <bnoordhuis>indutny: the ABI is inviolate so if you want to get it in v0.10, you can't change it
11:51:11  <indutny>yeah, I know
11:51:18  <indutny>that's why I was asking if we want to have this in v0.10
11:51:19  <indutny>:)
11:51:27  <bnoordhuis>well, i personally don't care
11:51:32  <indutny>me neither
11:51:50  <bnoordhuis>i guess you could ask on the issue how much of a blocker it is for people
11:52:04  <bnoordhuis>though it's anybody's guess how much a reliable indicator that is
11:52:07  <bnoordhuis>*of a
11:53:01  <indutny>haha
11:53:27  <indutny>Issue was created 3 months ago
11:53:33  <indutny>I guess if it was a real blocker for someone
11:53:41  <indutny>they found a way to figure it out :)
11:54:35  <bnoordhuis>yeah, good point
11:56:04  <indutny>there's a way to figure it out
11:56:11  <indutny>and I probably like it
11:56:24  <indutny>what do you think about putting custom structure to loop->cf_loop
11:56:40  <indutny>instead of CFRunLoopGetCurrent()
11:56:50  <indutny>this structure will contain current loop
11:58:22  * hzquit (Remote host closed the connection)
11:59:04  * hzjoined
11:59:29  <bnoordhuis>indutny: no strong opinion. i don't object
12:00:29  * kazupon_quit (Remote host closed the connection)
12:02:05  <indutny>ok
12:02:06  <indutny>good
12:04:10  * hzquit (Ping timeout: 245 seconds)
12:07:27  <MI6>joyent/libuv: Ben Noordhuis master * 8531046 : windows: omit stdint.h, fix msvc 2008 build error - http://git.io/VPAjOw
12:07:31  <bnoordhuis>saghul: ^
12:08:14  <saghul>bnoordhuis nice, thanks!
12:09:21  <saghul>bnoordhuis out of curiosity, is uintptr_t same as char* or equivalent?
12:09:26  <bnoordhuis>pretty much
12:09:38  <bnoordhuis>one is a pointer, the other is an unsigned integral
12:09:55  <bnoordhuis>but in pointer arithmetic, they're pretty much the same thing
12:10:04  <saghul>aha
12:11:10  * hzjoined
12:13:24  <MI6>libuv-master: #175 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/175/
12:13:41  <MI6>libuv-master-gyp: #115 UNSTABLE linux-ia32 (1/192) windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (4/193) http://jenkins.nodejs.org/job/libuv-master-gyp/115/
12:15:05  <indutny>btw
12:15:10  <indutny>not really a low hanging fruit
12:15:13  <indutny>but still matters https://github.com/joyent/node/pull/5087
12:15:20  <indutny>bnoordhuis: dualstack
12:15:26  * hzquit (Ping timeout: 240 seconds)
12:20:07  <indutny>bnoordhuis: people still write emails to me regarding this topic
12:20:42  <indutny>bnoordhuis: may be we can opt-out A record selection by introducing some environment variable?
12:22:19  * hzjoined
12:25:28  * AvianFlujoined
12:26:50  <MI6>libuv-node-integration: #158 UNSTABLE smartos-ia32 (3/629) osx-ia32 (1/629) linux-x64 (1/629) linux-ia32 (1/629) osx-x64 (1/629) smartos-x64 (9/629) http://jenkins.nodejs.org/job/libuv-node-integration/158/
12:26:55  * hzquit (Remote host closed the connection)
12:28:31  <saghul>indutny does that implement "happy eyeballs"?
12:28:37  <indutny>nope
12:29:09  <saghul>shouldn't it? :-)
12:29:15  <indutny>probably it should
12:29:22  <indutny>I doubt it'll land easily now :)
12:29:37  <indutny>so it'll be almost rewriting everything
12:31:50  <bnoordhuis>indutny: agreed we could do better there
12:32:02  <bnoordhuis>i'm actually a little surprised on the current ipv6 uptake
12:32:20  <bnoordhuis>it's more than i would've expected it to be
12:32:58  <bnoordhuis>happy eyeballs however is an abomination onto $DEITY
12:34:38  <indutny>bnoordhuis: https://github.com/floatdrop/node/commit/66752db86118cd66954f8002f40d127ae76bc6e8
12:34:41  <indutny>thoughts?
12:35:00  <saghul>bnoordhuis why don't you like happy eyeballs?
12:36:06  * hzjoined
12:36:20  <bnoordhuis>saghul: open two connections to the same host and that the best one may win?
12:36:49  <bnoordhuis>at the very least it's unsociable, opening frivolous connections
12:36:58  <saghul>bnoordhuis heh
12:37:27  <saghul>but it helps if your IPv6 connection is slow (tunneled) for instance, since IPv4 would most likely win there
12:38:08  <bnoordhuis>saghul: yeah. that doesn't make it less of a bandaid though, does it?
12:38:17  <bnoordhuis>indutny: seems acceptable
12:38:50  <saghul>bnoordhuis well, trying to connect to a host in a serial manner would be slower, wouldn't it?
12:38:51  <bnoordhuis>indutny: you'd also have to get that into http/https/tls/udp
12:38:59  <bnoordhuis>saghul: sure
12:39:22  <bnoordhuis>saghul: if people want to go down the happy eyeballs path, i'm not stopping them
12:39:28  <bnoordhuis>but i don't think it should be the default in node
12:39:51  <bnoordhuis>or even opt-in. people can do that with a module if they want to
12:40:02  <saghul>sure
12:40:28  <saghul>but trying just v6 if present would probably break things
12:40:35  <saghul>or make them slow
12:41:07  <saghul>like apt-get, it will use IPv6 if present and I can't override it, even though I know it's tunneled and slow
12:41:41  <bnoordhuis>oh, like that
12:41:53  <bnoordhuis>i think we'll stick with ipv4-by-default for the foreseeable future
12:42:04  <bnoordhuis>it's just that it should be easier to use ipv6 if it's available
12:42:11  * hzquit (Remote host closed the connection)
12:42:15  <saghul>indeed
12:42:44  <bnoordhuis>right now, you have to do the dns query yourself, then call http.request({ host: addr, headers: { 'Host': 'example.com }})
12:42:48  <bnoordhuis>it's a bit of a pain
12:43:05  * hzjoined
12:45:07  <indutny>bnoordhuis: yeah
12:46:43  * AvianFluquit (Remote host closed the connection)
13:01:45  * hzquit (Ping timeout: 268 seconds)
13:06:48  * hzjoined
13:06:53  * c4milojoined
13:10:22  * hzquit (Read error: Connection reset by peer)
13:11:42  * c4miloquit (Ping timeout: 276 seconds)
13:12:03  * hzjoined
13:13:58  * hzquit (Client Quit)
13:15:39  * c4milojoined
13:19:06  * jmar777joined
13:21:30  <bnoordhuis>wow, the nodejs mailing list has almost 12,000 members
13:21:42  <bnoordhuis>libuv only a paltry 127 :)
13:29:24  * bradleymeckjoined
13:32:57  <bnoordhuis>indutny: ping
13:33:01  <indutny>pong
13:33:15  <bnoordhuis>question about tls_wrap
13:33:22  <bnoordhuis>node_crypto too, i guess
13:33:42  <bnoordhuis>for this multi-context thing i need to create a Context::Scope to make sure objects are created in the same context
13:33:51  <bnoordhuis>i don't want to create them all over the place
13:34:03  <indutny>ok
13:34:04  <bnoordhuis>but the tls_wrap kind of weaves in and out of openssl
13:34:05  * Somebodyjoined
13:34:15  <bnoordhuis>so it's kind of hard to determine what the 'bottom' of the stack is
13:34:22  <indutny>heh
13:34:35  <bnoordhuis>does all i/o come from libuv callbacks?
13:34:48  <indutny>IO ?
13:34:48  <indutny>yes
13:34:52  <indutny>libuv is doing all IO
13:35:10  <bnoordhuis>js never feeds openssl data directly?
13:35:19  * Somebodyquit (Remote host closed the connection)
13:35:37  <bnoordhuis>i mean, there's not e.g. a tlssocket.write(data) method hidden somewhere?
13:35:49  <indutny>bnoordhuis: surely there is :)
13:35:49  * leonvvjoined
13:35:54  <indutny>clearIn
13:35:56  <indutny>clearOut
13:36:01  <bnoordhuis>right okay
13:36:05  <bnoordhuis>yeah, that's no issue
13:36:12  <bnoordhuis>i've got all js entry points covered
13:36:30  <bnoordhuis>i guess that just leaves libuv callbacks
13:36:50  <bnoordhuis>i was trying to avoid creating the Context::Scope until it's really necessary
13:37:02  <bnoordhuis>i.e. right before the call into js land or before the first object is created
13:37:16  <bnoordhuis>but i suppose i should opt for robustness first, optimization second
13:39:18  <indutny>yeah
13:39:23  <indutny>sounds reasonable
13:44:24  <indutny>bnoordhuis: is sizeof(uv_sem_t) always equal to sizeof(void*) now?
13:45:26  * bnoordhuisquit (Ping timeout: 240 seconds)
13:50:31  * leonvvquit (Remote host closed the connection)
13:50:36  * AvianFlujoined
13:50:50  <indutny>oh gosh
13:50:53  <indutny>doesn't seem like so
13:52:02  * piscisaureus_joined
13:56:57  <Domenic_>should i squash https://github.com/joyent/node/pull/5918 or do you guys like the multiple commits?
14:00:55  <indutny>цудд
14:00:56  <indutny>well
14:01:03  <indutny>commit message style is a bit unusual
14:01:12  <indutny>mind using something like this: "vm: message"
14:01:41  <indutny>and yeah, some of them definitely should be squashed
14:01:56  <indutny>basically tests should work between any of your commits
14:02:02  <indutny>and hopefully after all your commits :)
14:02:53  <Domenic_>yeah i wanted to determine whether to squash before rewriting commit message
14:03:00  <indutny>ok
14:03:08  <indutny>so you see what I think about it now :D
14:03:11  <indutny>right?
14:04:13  * rendarjoined
14:07:24  * c4miloquit (Remote host closed the connection)
14:10:56  <Domenic_>yeah. i think i'll have to squash everything in to one to follow the tests-should-work-between-commits guideline
14:11:38  <Domenic_>i tried to layer it into separate features but i realized midway through i was running the tests wrong
14:12:00  <Domenic_>and to make them pass i had to make changes that were pretty extensive and not easy to piece back out into the feature commits
14:17:44  * felixgejoined
14:17:44  * felixgequit (Changing host)
14:17:44  * felixgejoined
14:21:14  * pachetjoined
14:30:10  <indutny>tjfontaine: ping
14:30:15  <indutny>tjfontaine: how are you? :)
14:32:26  <piscisaureus_>I must have missed something but...
14:32:52  <piscisaureus_>why is FIXED_ONE_BYTE_STRING better than String::NewSymbol ?
14:33:03  <indutny>hahaha
14:33:07  <indutny>I don't know
14:33:11  <indutny>that's some Ben's magic
14:33:32  <Domenic_>i do not like typing it
14:34:08  * kazuponjoined
14:34:42  * kazuponquit (Read error: Connection reset by peer)
14:35:06  * kazuponjoined
14:39:20  * bradleymeckquit (Quit: bradleymeck)
14:42:01  * stagasjoined
14:45:46  * paulfryzeljoined
14:47:43  * bradleymeckjoined
14:47:59  * bnoordhuisjoined
14:49:29  <bnoordhuis>call in 10?
14:54:00  <bnoordhuis>indutny: re: whether sizeof(uv_sem_t) always == sizeof(void*), no
15:03:05  * bajtosjoined
15:03:22  <bajtos>piscisaureus_: are you around?
15:03:30  <piscisaureus_>bajtos: yes
15:03:58  <bajtos>piscisaureus_: will you join us in our strongnode team meeting? (now)
15:06:08  <bnoordhuis>indutny: if/when you land #6083, please amend the commit log to fix the engrish
15:12:11  * austojoined
15:17:07  <MI6>joyent/node: Gil Pedersen v0.10 * e04c8a8 : fs: use correct self reference for autoClose test - http://git.io/mT2T5A
15:17:22  <MI6>nodejs-v0.10-windows: #161 FAILURE windows-ia32 (8/597) windows-x64 (8/597) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/161/
15:18:23  <bnoordhuis>eh?
15:18:59  <bnoordhuis>ah, jenkins is broken
15:19:36  <MI6>nodejs-master: #451 FAILURE smartos-x64 (12/629) smartos-ia32 (3/629) osx-x64 (1/629) osx-ia32 (2/629) linux-ia32 (1/629) linux-x64 (1/629) http://jenkins.nodejs.org/job/nodejs-master/451/
15:23:46  <MI6>nodejs-v0.10: #1433 FAILURE osx-ia32 (1/597) smartos-x64 (1/597) http://jenkins.nodejs.org/job/nodejs-v0.10/1433/
15:27:59  * piscisaureus_quit (Ping timeout: 259 seconds)
15:30:49  * mikealquit (Quit: Leaving.)
15:33:28  * bnoordhuisquit (Ping timeout: 264 seconds)
15:40:53  * TooTallNatejoined
15:44:28  * sblomjoined
15:44:41  <sblom>I'll be a few minutes late for the call this morning.
15:44:43  * sblomquit (Client Quit)
15:47:13  * c4milojoined
15:53:16  * mikealjoined
15:58:04  * dshaw_joined
15:58:25  * c4miloquit (Remote host closed the connection)
16:00:10  * bnoordhuisjoined
16:00:35  <trevnorris>meeting?
16:00:44  <isaacs>good morning
16:00:44  <bnoordhuis>yep
16:00:48  <bnoordhuis>hey isaac
16:00:54  <isaacs>heading to a room now. no sign of tjfontaine as yet.
16:02:42  <isaacs>https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:04:02  <isaacs>indutny, piscisaureus_, sblom: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:04:03  * bajtosquit (Quit: bajtos)
16:05:13  * dshaw_quit (Read error: Connection reset by peer)
16:05:33  <bnoordhuis>indutny: call
16:05:49  * brsonjoined
16:06:19  * mikealquit (Quit: Leaving.)
16:06:31  * mikealjoined
16:06:56  <isaacs>Domenic_: feel free to join if you wanna chat about VM2 stuff. kinda short notice, i know
16:07:00  <isaacs>Domenic_: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:07:33  * dshaw_joined
16:09:42  * piscisaureus_joined
16:09:58  <trevnorris>piscisaureus_: https://plus.google.com/hangouts/_/5b6b53fce8c09512b15a7e7d5c2fbb51d9557288
16:10:42  * piscisaureus_quit (Read error: Connection reset by peer)
16:17:02  * sblomjoined
16:17:15  * jmar777_joined
16:18:36  * dapjoined
16:19:47  * jmar777quit (Ping timeout: 260 seconds)
16:22:11  * leonvvjoined
16:26:52  * bajtosjoined
16:29:14  <indutny>sorry missed the call
16:30:15  <indutny>bnoordhuis: it seems to be failing on linux
16:30:24  <indutny>is that something that we'll need to look into?
16:30:28  * leonvvquit (Remote host closed the connection)
16:33:00  * kazuponquit (Remote host closed the connection)
16:35:37  <isaacs>sblom: you still doing thursday/friday? piscisaureus_ wants to know
16:36:49  <bnoordhuis>indutny: is the call failing on linux? that'd be odd
16:36:55  <indutny>haha
16:37:17  <indutny>bnoordhuis: hadn't you outgrown such jokes?
16:37:37  <bnoordhuis>not for a long time to come. i'm only getting better at it
16:37:59  <bnoordhuis>i take it you were referring to the ipv6 thing?
16:39:24  * piscisaureus_joined
16:39:41  <piscisaureus_>sblom: which days are you working on node?
16:40:19  <piscisaureus_>(I won't be around for long on thu this week)
16:40:42  <piscisaureus_>but if I need to schedule any time to help/ answer questions on friday, can do
16:43:14  <sblom>piscisaureus_: Thursday and Friday are our Node days again this week.
16:43:38  <sblom>isaacs: /cc ^
16:43:40  <bajtos>isaacs: can you spare few minutes to discuss multi-registry support in npm?
16:44:00  <isaacs>bajtos: yeah, i still have to review that caching client you wrote
16:44:14  <bajtos>isaacs: :)
16:44:28  <bajtos>isaacs: so in the meantime, what shall I work on next?
16:44:50  <bajtos>I can implement more items from TODO.md and integrate the caching client into my spike
16:44:51  <isaacs>bajtos: does that client support tunneling https over http proxies?
16:44:54  * bnoordhuisquit (Ping timeout: 276 seconds)
16:44:55  <isaacs>bajtos: or proxying in general"
16:44:57  <isaacs>?
16:45:03  <bajtos>isaacs: hmm, most likely not
16:45:22  <isaacs>bajtos: that's an important part of getting npm off of the request sugar
16:45:24  <bajtos>I mean it is more or less transparently using core http.request
16:45:34  <isaacs>bajtos: because people depend on using npm over http proxies
16:45:36  * dominictarrquit (Quit: dominictarr)
16:45:56  <Domenic_>i am now at a client site where that is the case. zomg proxies -_-
16:46:02  <isaacs>bajtos: my plan was to abstract out the http.Agent class from node-core master, and then extend that into a new TunnelingAgent module
16:46:26  <isaacs>bajtos: tunneling http over http, or https over https, is pretty straightforward.
16:46:36  <isaacs>bajtos: but doing http over https, or https over http, is much more complicated.
16:46:38  <bajtos>isaacs: does it make sense to implement the tunelling in my caching client then?
16:46:42  <piscisaureus_>sblom: thanks, good to know
16:46:52  <bajtos>isaacs: isn't it better to wait for your implementation? (I don't have an opinion, just asking)
16:46:52  <isaacs>bajtos: no, but it should allow you to specify a particular agent
16:47:22  <isaacs>bajtos: or perhaps do the proxying transparently. i'm not sure.
16:47:30  <isaacs>bajtos: but that means having its own Agent that it uses
16:47:30  <bajtos>isaacs: by tunelling HTTPS over HTTP, you mean CONNECT verb?
16:47:34  <isaacs>bajtos: yeah
16:47:39  <bajtos>isaacs: ok
16:47:55  <bajtos>isaacs: well, I thought it is better to do a vertical solution first
16:48:08  <bajtos>isaacs: to make sure we have the new design in all components first
16:48:31  <isaacs>bajtos: sure, doesn't matter that much, really
16:48:32  <bajtos>isaacs: and then we can expand horizontally by adding support for proxies in caching client, cli for registry management, etc.
16:49:16  <bajtos>bajtos: ok, if the caching client was good enough, what would be the next step?
16:49:22  <isaacs>bajtos: if the caching-client can let you pass in an agent, then tht would be where the Tunneling stuff goes anyway
16:49:38  <bajtos>isaacs: ok, I'll add that option
16:49:56  <isaacs>bajtos: should be pretty easy, if it's just a light wrapper around http.request
16:50:26  <bajtos>so is it time to replace npm's cache.js internals with the caching client? to see what is missing?
16:50:27  <isaacs>bajtos: i'll try to get a start on pulling the agent out today
16:50:41  <isaacs>bajtos: we can't use the caching client in npm until we can have it do proxying
16:51:05  <bajtos>isaacs: sure, but until we have a proxying Agent, I can work on the integration, right?
16:51:18  <isaacs>bajtos: if you want to take a look at it, then that's fine, but there's probaby also changes needed to node-tar for that
16:51:31  <isaacs>bajtos: or at least, just a lot of work to do there throughout npm
16:51:44  * piscisaureus_quit (Ping timeout: 246 seconds)
16:51:47  <isaacs>bajtos: my plan is not simply to replace cache.js, btw.
16:52:04  <bajtos>isaacs: I guess our plans differs a bit :)
16:52:04  <isaacs>it's to replace lib/cache.js, lib/utils/tar.js, and most of lib/install.js
16:52:29  <bajtos>isaacs: I'd like to do a partial improvement, so that npm is ready for adding multi-registry support
16:52:48  <bajtos>isaacs: while it seems to me that you would like to do a big refactor while doing multi-reg support
16:52:58  <isaacs>bajtos: also, you should figure out if strongloop is planning on forking npm at ff06a41
16:53:24  <isaacs>bajtos: if so, make sure to do your work in that fork, so as to not be polluted by the Artistic License 2.0
16:53:30  * c4milojoined
16:54:01  <isaacs>bajtos: yes, i see multi-reg support as one of severals feature that should be trivial to add, but are not, because npm is a mess.
16:54:24  <bajtos>isaacs: I see, thanks for pointing out the license change
16:54:28  <isaacs>bajtos: np
16:54:38  <isaacs>bajtos: it may be tht sl decides it's ok.
16:55:09  <isaacs>bajtos: i am of the opinion that forking is silly, but it's not my call, and i understand that sl has to do what they've gotta do.
16:55:29  <isaacs>bajtos: just make sure to check with issac, bert, etc about that.
16:55:39  <bajtos>isaacs: of course
16:56:02  <isaacs>bajtos: if you fork at ff06a41 and keep using the MIT, then as far as I can, I'll try to take your patches into the mainline project.
16:56:28  <isaacs>bajtos: unless SL sublicenses to GPL or something ;)
16:56:39  <bajtos>isaacs: but the we can't merge your changes into our fork, right?
16:56:45  <isaacs>that would be correct.
16:56:55  <isaacs>not without explicit permission from the author of that patch.
16:58:15  <bajtos>isaacs: ok. I am curious what led you to change the license, but it's probably better to leave that for another day
16:58:39  <bajtos>isaacs: regarding changes to node-tar, lib/install.js and lib/utils/tar.js
16:58:55  <bajtos>isaacs: how can I help there?
16:59:52  <isaacs>bajtos: so, i'd like the npm cli to be mostly a light wrapper around an npm-client lib
17:00:13  <isaacs>bajtos: yeah, i should probably write a blog about the license. it's a long story.
17:00:39  <isaacs>bajtos: the decision has nothing to do with strongloop, but i understand that it does affect them, since they charge a license fee for using npm (among other things)
17:00:45  * groundwaterjoined
17:00:54  <isaacs>and Artistic-2.0 doesn't allow that.
17:01:07  <isaacs>you CAN charge a distribution fee for it.
17:01:24  <isaacs>or charge a licensing fee for everything else, and give npm away for free.
17:02:12  <isaacs>i guess it's not such a long story. the prior license is a modified MIT license, which doesn't allow one to distribute npm, break it, and then send the bug reports my wy.
17:02:15  <isaacs>*way
17:02:22  <isaacs>but, MIT+no-false-attribs is sloppy legally
17:02:40  <isaacs>the language is weird, and there's a lot of loopholes and vague statements.
17:03:19  <isaacs>so i looked around a lot for a license that does what I want, but has actually been tested in court, and Artistic-2.0 is basically the only option. the zlib license is *close*, but not quite there.
17:03:29  * AvianFluquit (Remote host closed the connection)
17:04:08  <bajtos>isaacs: that makes sense
17:04:18  <isaacs>this all started a few years ago with a conflict wiht a certain package management system that was distributing a broken version of npm, and sending me a consistent flow of bug reports that i couldn't fix.
17:04:30  <isaacs>so i told them that they have to either change what they're doing, or own the bugs.
17:04:55  <isaacs>they said, "Well, your license gives us permission to distribute it with changes".
17:05:05  <isaacs>and i was like, "Oh. So it does." and changed the license.
17:05:10  <bajtos>:)
17:06:31  * bradleymeckquit (Quit: bradleymeck)
17:06:55  * c4miloquit (Remote host closed the connection)
17:07:39  <MI6>joyent/node: Vsevolod Strukchinsky master * edd2fcc : net: family option in net.connect - http://git.io/Hph9sg
17:08:03  * felixgequit (Quit: felixge)
17:08:37  <bajtos>isaacs: I guess it's best for me to investigate what the license change means to SL and work on the caching client in the meantime
17:09:11  <isaacs>bajtos: kewl. my hope is that in the long term, the npm license is not an issue for SL.
17:09:29  <isaacs>bajtos: i'll take a look at the caching client today
17:09:41  <bajtos>isaacs: I hope so too.
17:10:00  <bajtos>isaacs: cool, I am looking forward to get your opinion
17:10:04  <isaacs>kk
17:10:09  <indutny>feels good :)
17:10:48  <indutny>isaacs: so you're the proprietary guy here :)
17:10:54  <isaacs>bajtos: is there a rule that all strongloop modules must be called "strong"?
17:11:16  <bajtos>isaacs: yes :) is it an issue?
17:11:23  <isaacs>bajtos: it's just weird
17:11:56  <bajtos>isaacs: it makes the names unnecessarily long, that's true
17:12:25  <isaacs>i guess it's better than picking random names from tv shows, like a certain retailer I know
17:12:30  <isaacs>hueniverse: ^ ;P
17:12:56  <bajtos>isaacs: :-D
17:14:43  <isaacs>bajtos: path: path.resolve(cacheDir, '#body'),
17:14:51  <isaacs>bajtos: it's kind of weird to put # in a filename, no?
17:15:05  <isaacs>bajtos: why not just path.resolve(cacheDir, 'body')?
17:16:00  <bajtos>isaacs: you can get a clash for http://localhost/ and http://localhost/body
17:16:15  <bajtos>isaacs: # is not a part of URL request
17:16:26  <isaacs>hm. i see
17:16:42  <bajtos>isaacs: it's an easy way how to prevent conflicts and keep the path convention simple
17:16:56  <MI6>nodejs-master: #452 UNSTABLE smartos-x64 (8/630) smartos-ia32 (2/630) osx-x64 (1/630) osx-ia32 (1/630) linux-ia32 (2/630) linux-x64 (2/630) http://jenkins.nodejs.org/job/nodejs-master/452/
17:17:15  <isaacs>bajtos: why not just change getCachePathForUrl to return an sha of the url or something?
17:18:13  <bajtos>isaacs: that will make the file structure opaque
17:18:17  <isaacs>bajtos: perhaps something like: url.replace(/[:\/\\]+/g, '_') + sha(url).substr(0, 8)
17:18:34  <isaacs>bajtos: so each url is just one folder deep, and unique
17:18:54  * AvianFlujoined
17:19:19  <bajtos>isaacs: oh, I see. I could do that. can you please comment on the pull request so that I don't forget to make the change?
17:19:23  <isaacs>then you can still tell what you're looking at, because 'http_github_com_isaacs_npm_deadbeef' is pretty easy to understand
17:19:48  <bajtos>isaacs: except auto-completion might not work well, but that's a minor issue
17:19:50  <isaacs>sure, i'm just stream-of-consciousness dumping right now :)
17:19:57  <bajtos>isaacs: :)
17:20:02  <isaacs>bajtos: really you shouldn't probably be looking at these folders directly
17:20:09  <isaacs>they're owned by this module
17:20:11  * dominictarrjoined
17:20:32  * amartensjoined
17:21:29  * julianduquejoined
17:28:14  * mcavagepart
17:34:04  * dshaw_quit (Quit: Leaving.)
17:34:49  * indexzerojoined
17:38:05  * dshaw_joined
17:39:25  <pfox__>question about uv_stat_t: is the st_size field going to be equal to st_blksize / st_blocks ?
17:39:29  <pfox__>or is it always size in bytes?
17:39:30  * indexzeroquit (Ping timeout: 264 seconds)
17:41:57  <MI6>nodejs-master-windows: #247 UNSTABLE windows-x64 (20/630) windows-ia32 (20/630) http://jenkins.nodejs.org/job/nodejs-master-windows/247/
17:43:56  * julianduquequit (Quit: leaving)
17:43:58  * st_lukejoined
17:45:08  * `3E|AFKchanged nick to `3rdEden
17:46:30  * bnoordhuisjoined
17:50:19  <trevnorris>isaacs: um... util.isObject({}) returns {}
17:50:22  <trevnorris>isaacs: is that correct?
17:50:31  <isaacs>trevnorris: hrm. taht seems wrong
17:51:15  <isaacs>trevnorris: yeah, should be return typeof arg === 'object' && !!arg;
17:51:28  <isaacs>trevnorris: or even return typeof arg === 'object' && arg !== null;
17:51:54  <trevnorris>cool. i'll throw that on
17:51:59  * mikealquit (Quit: Leaving.)
17:52:23  <bajtos>isaacs: sorry for not responding, I am sort of finishing my day… let's continue the discussion in github...
17:52:33  <isaacs>bajtos: no problem.
17:52:39  <isaacs>bajtos: i'm gonna play around wiht this and probably send you some pull reqs.
17:53:10  <MI6>libuv-master: #176 UNSTABLE smartos (9/192) windows (3/193) http://jenkins.nodejs.org/job/libuv-master/176/
17:53:22  <bajtos>isaacs: cool. in that case, I'll quickly push the last commit I was working on today
17:53:57  <bnoordhuis>Domenic_: still around?
17:54:06  * indexzerojoined
17:54:08  <bajtos>isaacs: also once we agree the first round of changes are ok, I'll merge the branch into master, to make it easier to play with
17:54:40  <isaacs>bajtos: since no one's using it yet, you may as well merge the impl branch into master already
17:55:15  <bajtos>isaacs: I could, but then it's easier to keep track of the comments in pull requests. especially once you start rewriting the history
17:55:16  <tjfontaine>hello folks
17:55:35  <bajtos>isaacs: anyway, I should really sign off :)
17:56:36  * bajtosquit (Quit: bajtos)
17:59:10  <bnoordhuis>hey tj
17:59:22  <tjfontaine>hey ben
17:59:48  <bnoordhuis>how was your PTO? (you were on PTO right?)
17:59:50  <trevnorris>is test/simple/test-net-connect-options-ipv6.js failing for anyone else?
18:00:04  <tjfontaine>bnoordhuis: indeed, visiting the family
18:00:09  <bnoordhuis>trevnorris: ah, i think that's fedor work
18:00:17  <trevnorris>ok thanks
18:00:43  <bnoordhuis>indutny: ^
18:00:50  <indutny>ok thanks?
18:00:57  <indutny>trevnorris: oh gosh
18:01:03  <indutny>trevnorris: what's up with it?
18:01:18  * taterbasejoined
18:01:21  <trevnorris>indutny: for confirming that my computer wasn't screwy.
18:01:41  <indutny>trevnorris: what happens?
18:01:48  <trevnorris>indutny: it's not uncommon that I forget something in the background that causes tests to fail.
18:02:09  <trevnorris>indutny: Error: getaddrinfo ENOTFOUND
18:02:14  <indutny>shit
18:02:19  <indutny>I'll figure it out soon
18:02:27  <indutny>once I'll finish that fsevents thing
18:02:35  <indutny>sorry
18:02:50  <trevnorris>i'm not worried. :)
18:03:38  * bradleymeckjoined
18:06:47  <MI6>joyent/node: Trevor Norris master * 50cee6e : util: isObject should always return boolean - http://git.io/3h7XfA
18:06:55  <MI6>libuv-node-integration: #159 UNSTABLE smartos-ia32 (2/630) osx-ia32 (1/630) linux-x64 (2/630) linux-ia32 (2/630) osx-x64 (1/630) smartos-x64 (10/630) http://jenkins.nodejs.org/job/libuv-node-integration/159/
18:09:28  <trevnorris>bnoordhuis: when you have a moment, fix for the smalloc thing: https://github.com/joyent/node/pull/6086
18:09:45  <trevnorris>(oh, and might have another small thing in there)
18:12:51  <bnoordhuis>trevnorris: looking
18:12:58  * c4milojoined
18:13:25  <trevnorris>bnoordhuis: force pushing a tiny typo in the example doc, nothing w/ the code itself.
18:14:25  <bnoordhuis>trevnorris: 'The C++ API has been changed to the passed length is the byte size'
18:15:21  <trevnorris>thanks
18:15:56  <MI6>nodejs-master: #453 UNSTABLE smartos-x64 (11/630) smartos-ia32 (3/630) osx-x64 (1/630) osx-ia32 (1/630) linux-ia32 (2/630) linux-x64 (2/630) http://jenkins.nodejs.org/job/nodejs-master/453/
18:16:11  <bnoordhuis>unless it's colloquial american dialect. i was raised on the queen's english, don't you know?
18:16:31  <trevnorris>hah. no it's a typo
18:17:06  <tjfontaine>it's american, WE CAN MAKE IT UP AS WE GO ALONG
18:18:19  <hueniverse>isaacs: watching an hour of ren and stimpy as the prerequisite to any new module to find a good name is the best part of my job!
18:19:10  <trevnorris>alright, off to have lunch w/ some friends at oracle
18:19:12  <bnoordhuis>trevnorris: in https://github.com/trevnorris/node/commit/93b31f8 , what happens when size is e.g. 8 and length = 2**30?
18:19:22  <trevnorris>bnoordhuis: i'll let you know what they say.
18:19:28  <bnoordhuis>oh, have fun - i'll comment on the commit :)
18:21:45  <trevnorris>bnoordhuis: it does assert that if size * length >= length. also it asserts the value isn't > kMaxLength.
18:21:55  <trevnorris>ok, for realzies.
18:21:57  * trevnorris&
18:21:57  <LOUDBOT>WELL YOU JUST HAVE IT ALL DON'T YOU
18:22:10  <trevnorris>LOUDBOT: yes, in fact I do
18:22:10  <LOUDBOT>trevnorris: ATTACK THEM AND MAKE THEM STOP
18:22:15  <chrisdickinson>bnoordhuis: btw, I signed the CLA for http-parser, re: https://github.com/joyent/http-parser/pull/156
18:22:46  <tjfontaine>the v8 commit/revert development pattern is sorta scary
18:26:13  <bnoordhuis>chrisdickinson: yeah, i saw, thanks. i'll probably land the patch tomorrow
18:26:28  <bnoordhuis>that's probably your three am in the morning
18:26:42  <chrisdickinson>ah, cool :) thanks very much!
18:26:53  <bnoordhuis>no, thank you :)
18:32:54  * brsonquit (Ping timeout: 264 seconds)
18:33:07  * brsonjoined
18:36:43  <Domenic_>bnoordhuis: pong
18:37:10  <bnoordhuis>Domenic_: hey. about vm2, where/when does it crash?
18:37:20  <bnoordhuis>i ran the test suite and everything passes on my macbook
18:37:28  <tjfontaine>in the timer watchdog stuff, I thought?
18:37:36  <Domenic_>bnoordhuis: oh great, Windows-only problem I'd guess. Yeah it's in the timeout test
18:37:59  <Domenic_>bnoordhuis: test/simple/test-vm-timeout.js
18:38:10  <bnoordhuis>Domenic_: right. passes for me
18:38:19  <bnoordhuis>let me try my fedora machine
18:38:26  <tjfontaine>you're getting a C++ assert, or a normal windows timeout error?
18:38:29  <Domenic_>bnoordhuis: I wonder if the original timeout patch ever worked on Windows.
18:38:35  <Domenic_>tjfontaine: C++ assert
18:38:46  <Domenic_>Assertion failed: !(handle->flags & UV__HANDLE_CLOSING), file src\win\async.c, line 77
18:38:57  <Domenic_>i guess the win\async.c is a bit of a red flag there
18:39:01  <tjfontaine>Domenic_: can you run it in vs and get a narrower focus?
18:39:14  * defunctzombie_zzchanged nick to defunctzombie
18:39:30  * dshaw_quit (Quit: Leaving.)
18:39:31  <Domenic_>tjfontaine: yes, I did, let me see if I can remember the line that caused it... not at a computer with VS now
18:39:47  <tjfontaine>nod
18:40:03  <tjfontaine>I will start the process of looking myself as well
18:40:35  <bnoordhuis>passes for me on fedora as well
18:40:44  <MI6>nodejs-master-windows: #248 UNSTABLE windows-x64 (20/630) windows-ia32 (22/630) http://jenkins.nodejs.org/job/nodejs-master-windows/248/
18:40:49  <bnoordhuis>i don't know if i'm ready yet to start up a windows vm
18:41:16  <bnoordhuis>but then, when are you ever?
18:41:29  <tjfontaine>never, ever.
18:41:45  <Domenic_>It is caused by https://github.com/joyent/node/blob/master/src/node_watchdog.cc#L70
18:41:57  <Domenic_>So when the watchdog goes out of scope
18:44:11  <bnoordhuis>Domenic_: maybe add a few printf statements to the methods to see what runs in what order
18:44:41  <Domenic_>bnoordhuis: ? isn't the order pretty deterministic? or do you mean which destructor fires first?
18:49:12  <bnoordhuis>Domenic_: yeah, try to figure out the execution flow. e.g. if things aren't being closed twice or something like that
18:49:21  <bnoordhuis>shouldn't really be possible but you never know
18:49:45  <bnoordhuis>oh, pro tip - add fflush(stderr) after every fprintf
18:49:59  <Domenic_>lol
18:50:12  <Domenic_>ok well I'll try. I'm still skeptical this is within my powers though.
18:51:44  * c4miloquit (Remote host closed the connection)
18:53:08  * c4milojoined
18:53:20  * bradleymeckquit (Quit: bradleymeck)
18:53:25  <bnoordhuis>https://news.ycombinator.com/item?id=6243627 <- google interview disaster stories. pretty amusing reads
18:54:48  * indexzeroquit (Quit: indexzero)
18:56:50  <tjfontaine>ok reproduced, Domenic_
18:57:48  * bradleymeckjoined
19:04:24  * c4miloquit (Remote host closed the connection)
19:07:32  * brsonquit (Ping timeout: 246 seconds)
19:09:08  * bradleymeckquit (Quit: bradleymeck)
19:11:08  * c4milojoined
19:16:55  <MI6>nodejs-master-windows: #249 UNSTABLE windows-x64 (19/630) windows-ia32 (20/630) http://jenkins.nodejs.org/job/nodejs-master-windows/249/
19:17:29  * felixgejoined
19:26:16  * indexzerojoined
19:36:34  * EhevuTovjoined
19:36:46  * EhevuTovquit (Remote host closed the connection)
19:37:47  * EhevuTovjoined
19:38:16  * rendarquit (Ping timeout: 268 seconds)
19:39:14  * stagasquit (Ping timeout: 264 seconds)
19:42:19  <bnoordhuis>anyone here use emacs?
19:44:37  <Domenic_>tjfontaine: cool, so at least i'm not crazy. any ideas?
19:47:57  * dshaw_joined
19:51:40  * dshaw_1joined
19:52:14  * dshaw_quit (Ping timeout: 256 seconds)
19:52:36  * dshaw_1quit (Read error: Connection reset by peer)
19:52:41  <tjfontaine>Domenic_: you're not crazy
19:52:46  <tjfontaine>bnoordhuis: no, but why do you ask?
19:54:04  <indutny>people
19:54:08  <indutny>oakland or berkley?
19:54:13  <indutny>berkeley*
19:54:14  <tjfontaine>for what?
19:54:20  <tjfontaine>are you moving here?
19:54:29  <indutny>well, lets say that I might stay here
19:54:32  <indutny>for awhile
19:54:58  <tjfontaine>I think oakland is probably more reasonably priced and well suited for transit, but isaacs certainly has stronger opinions
19:55:27  <indutny>tjfontaine: thanks
19:55:41  * dshaw_joined
19:56:03  * dshaw_quit (Read error: Connection reset by peer)
19:56:19  * dshaw_joined
19:56:58  <tjfontaine>it is so boring waiting on windows rebuilds
19:59:34  <bnoordhuis>tjfontaine: oh, just wondering how people deal with the meta key on os x
20:00:50  * dshaw_quit (Ping timeout: 264 seconds)
20:01:28  * dshaw_joined
20:01:54  * dshaw_quit (Read error: Connection reset by peer)
20:02:27  * dshaw_joined
20:02:29  * dshaw_quit (Write error: Connection reset by peer)
20:02:32  * indexzeroquit (Quit: indexzero)
20:03:09  * mralephquit (Quit: Leaving.)
20:06:11  * indexzerojoined
20:10:38  * dshaw_joined
20:11:50  <indutny>meta key
20:18:03  <tjfontaine>Domenic_, bnoordhuis: Watchdog::Timer fires after Watchdog::Run calls uv_close on the async
20:18:27  <bnoordhuis>tjfontaine: right, that's a bug
20:18:52  <tjfontaine>the timer isn't firing int he first RUN_ONCE, then I guess?
20:19:08  <bnoordhuis>i suppose so
20:19:28  <bnoordhuis>but that makes it odd that it's firing on the second cal
20:19:34  <bnoordhuis>*call
20:19:37  <bnoordhuis>damn keyboard
20:19:49  <bnoordhuis>odd, because by then it's closing
20:19:52  <tjfontaine>my previous "fix" was uv_unref instead of uv_close, now I'm going to do two runs of RUN_ONCE
20:20:42  <bnoordhuis>maybe check if uv_is_closing(timer) == true in the the timer cb
20:21:30  <tjfontaine>seriously, fucking linking on windows man
20:22:08  <tjfontaine>also, dunno if you wanna squash these or not
20:22:08  <tjfontaine>1>g:\scratch\node\deps\uv\src\uv-common.c(476): warning C4715: 'uv__getaddrinfo_translate_error' : not all control paths return a value
20:22:11  <tjfontaine>1>g:\scratch\node\deps\uv\src\win\tcp.c(439): warning C4700: uninitialized local variable 'buf' used
20:22:12  * julianduquejoined
20:23:01  <Domenic_>yeah that uninitialized buf is pretty persistent
20:23:19  <isaacs>indutny: yes, well... berkeley is quite nice. but oakland has some very nice parts as well, and is less full of college kids.
20:23:26  <indutny>:)
20:23:30  <tjfontaine>the second run_once "fixes" it, I'll add the assert for the timer
20:23:30  <indutny>oook
20:23:34  <isaacs>indutny: anything near lake merritt is wondeful
20:23:41  <indutny>thank you
20:24:02  <isaacs>indutny: good neighborhoods: Adams Point, Cleveland Heights, Harrison-Oakland, Grand Lake
20:25:20  <tjfontaine>it's hard for me to see that and not think of http://www.clevelandheights.com/
20:25:21  <bnoordhuis>tjfontaine: i fixed those recently
20:25:32  <tjfontaine>bnoordhuis: ok, so we just need to do a 0.11 release
20:25:38  <tjfontaine>isaacs: shall I do one tomorrow?
20:25:58  <Domenic_>it sounds like we can get vm2 in tonight?
20:27:16  <isaacs>Domenic_: figured out the assert issue?
20:27:25  * isaacshas been mostly offline
20:27:54  <tjfontaine>the watchdog bug?
20:29:09  <tjfontaine>1> Generating code
20:29:15  <trevnorris>bnoordhuis: thanks
20:29:52  <bnoordhuis>trevnorris: for what? i remember nothing
20:29:58  <bnoordhuis>story of my life, really
20:30:05  <trevnorris>bnoordhuis: heh, the review.
20:30:11  <bnoordhuis>oh that, no problem :)
20:34:10  <tjfontaine>the timer flags are 32, and the assert of == true blew, so I guess this run it didn't happen?
20:34:42  <Domenic_>isaacs: yeah tjfontaine seems to have figured out the assert
20:36:34  * jmar777_quit (Remote host closed the connection)
20:37:45  <trevnorris>bnoordhuis: part of the reason their looking at libuv is as a replacement for asio.
20:38:04  <tjfontaine>sblom: ping
20:38:24  <tjfontaine>trevnorris: heh took me a bit, you mean they're, I thought you were saying they had their own libuv :P
20:38:46  <isaacs>bnoordhuis, piscisaureus_, bajtos: How firm is StrongLoop on using Mocha rather than someone less insane?
20:38:49  <trevnorris>tjfontaine: i haz good gramer
20:39:07  <isaacs>s/someone/something/
20:39:12  <bnoordhuis>trevnorris: ah, i can see that. did they mention reasons?
20:39:25  <isaacs>like, say, tap, or tape, or require('assert')
20:39:27  <bnoordhuis>isaacs: dunno, i think bajtos is the one to ask
20:39:31  <isaacs>k
20:39:48  <isaacs>mocha is pretty much everythign that's wrong with test runners.
20:40:04  <bnoordhuis>this is in the context of that npm pull request?
20:40:25  <tjfontaine>Domenic_: if you wanna double check the dirty hack, in watchdog do two uv_run UV_RUN_ONCE calls in succession
20:41:13  <Domenic_>(i like mocha, and think it's very well done.)
20:41:37  <trevnorris>bnoordhuis: hey like how libuv does threads, and how the event loop works. also they prefer C to C++.
20:41:43  * bnoordhuishas never used anything besides require('assert')
20:41:51  <Domenic_>tjfontaine: well OK, will try when back at home at C++-compiling computer. Is that the fix we're going with?
20:41:58  <isaacs>i like test runners where the tests are runnable programs.
20:42:06  <isaacs>Domenic_: mocha tests rely on being run by a particular runner
20:42:13  <Domenic_>isaacs: yes. i see no problem with that.
20:42:14  <isaacs>Domenic_: they'renot just simple programs that either succeed or don't
20:42:19  <tjfontaine>Domenic_: "no", but as a potential solve this in the short term
20:42:30  <bnoordhuis>tjfontaine: you figured it out?
20:42:32  <isaacs>Domenic_: well, if i do `console.error('foo')` in a test, it doesn't show up, for starters.
20:42:37  <tjfontaine>bnoordhuis: no
20:42:39  <isaacs>Domenic_: and i can't just run the program to see that.
20:42:42  <bnoordhuis>tjfontaine: is bert to blame?
20:42:46  <Domenic_>isaacs: i agree that's the most annoying thing about tap. mocha doesn't have that problem.
20:42:47  <trevnorris>bnoordhuis: think the gist of it was, libuv has just enough abstraction, is performant and windows/*nix compatible.
20:42:47  <isaacs>Domenic_: plus, wtf is describe() and it()?
20:42:49  <tjfontaine>bnoordhuis: other than to say, if you run the loop twice things seem sane
20:43:02  <isaacs>Domenic_: what do you mean? tap tests are all just node programs.
20:43:05  <Domenic_>isaacs: i dunno, wtf is process and setTimeout?
20:43:10  <isaacs>Domenic_: whatever you console.error(), it prints out
20:43:14  <Domenic_>isaacs: `tap myTest.js` and console.error fails.
20:43:19  <bnoordhuis>trevnorris: okay, nice. thanks for asking
20:43:40  <isaacs>Domenic_: you can do TAP=1 in the env to just show the plain straight tap output
20:43:51  <trevnorris>bnoordhuis: np. also, found out it's not if they'll be using it but when. they're waiting for oracle's legal team to sign off.
20:43:52  <isaacs>Domenic_: but mocha absolutely does have that problem
20:43:53  <Domenic_>oh great, more global state :P
20:44:02  <isaacs>Domenic_: or you can also just do `node test.js` and it'll print out as you like
20:44:05  <Domenic_>isaacs: that's just not true. mocha does not interfere with console output like tap does.
20:44:11  <tjfontaine>o0
20:44:28  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:44:28  <isaacs>Domenic_: um... i'm writing to stderr in a test here, and mocha's not showing it
20:44:30  <trevnorris>bnoordhuis: unfortunately their product hasn't been announced yet, so can't actually tell you how until it is.
20:44:44  <bnoordhuis>trevnorris: aw
20:45:12  * brsonjoined
20:45:26  <Domenic_>isaacs: gist? works fine on my machine.
20:45:51  <isaacs>Domenic_: oh, it looks like it works if your program doens't crash.
20:46:26  <Domenic_>isaacs: i did `console.error('foo'); throw new Error();` and it still outputted foo.
20:46:59  <bnoordhuis>why wouldn't it?
20:47:14  <Domenic_>because it does the tap thing and traps stderr output
20:47:21  <Domenic_>s/does/might do/
20:47:21  <isaacs>Domenic_: yeh, it doesn't seem to work once a describe() function starts
20:47:49  <isaacs>Domenic_: and when it does, it's all fubar and impossible to read, because it interferes with the pretty unicode and ansi colors.
20:48:05  <MI6>joyent/node: Trevor Norris master * 849cf1a : smalloc: consistent-ify syntax (+2 more commits) - http://git.io/Yaut-g
20:48:07  <Domenic_>isaacs: would love to see a gist. cannot reproduce and have never had such problems on my machine.
20:50:28  * dominictarr_joined
20:50:36  * dominictarrquit (Ping timeout: 276 seconds)
20:50:37  * dominictarr_changed nick to dominictarr
20:51:06  <isaacs>really, the fact that it MUST be run with a specific runner is pretty much the worst thing. the fact that said runner dumps a bunch of unicode and ansi to the terminal just adds insult to injury
20:51:19  <Domenic_>that's just the default runner
20:51:29  <Domenic_>and i still don't understand why having to be run with a specific runner is a problem at all.
20:51:36  <Domenic_>s/default runner/default reporter
20:51:50  <Domenic_>-r tap and the luddites can be happy
20:51:57  <Domenic_>-r nyan and the crazy people can be happy
20:52:02  <Domenic_>a sensible default between those is fine
20:52:10  <isaacs>Domenic_: because it encourages putting too many tests in one file
20:52:20  <isaacs>Domenic_: and it's not at all obvious how to just run one test.
20:52:23  <Domenic_>isaacs: O_o
20:52:37  <Domenic_>how does the runner impact that at *all*
20:52:56  <isaacs>Domenic_: i guess if you're ok with adding node_modules/.bin/ to your PATH, or installing mocha globally, it's fine
20:53:04  <isaacs>Domenic_: but it means that tests are tightly coupled to the runner
20:53:05  <Domenic_>isaacs: or running `npm test`
20:53:16  <isaacs>Domenic_: right, but i frequently one to run only a few tests
20:53:21  <isaacs>or just one
20:53:33  <Domenic_>as opposed to being tightly coupled to their testing library?
20:53:35  * mikealjoined
20:53:36  <isaacs>eg, wth node's tests, you can do `./node testfile.js`
20:53:51  <isaacs>their own testing lib is fine, because they load that. i don't have to load it for them
20:53:52  <bnoordhuis>^ nice for debugging in gdb
20:54:00  <isaacs>bnoordhuis: exactly!
20:54:08  <isaacs>tap tests load their deps
20:54:15  <isaacs>(same with tape, tt, assert, etc.)
20:54:20  <isaacs>mocha tests expect that they're already in the global.
20:54:32  <Domenic_>why is typing node better than typing mocha?
20:54:53  <isaacs>if it was: var m = require('mocha'); m.describe() m.it(), it'd be a different story
20:55:17  <isaacs>Domenic_: because it matches the pattern of running every other kind of program. i can compile 2 different builds of node, and see how thte test differs between them
20:55:21  <Domenic_>i don't think that's really something anyone's against, it's just that nobody really sees any benefit there
20:55:25  <isaacs>Domenic_: i can fire up GDB or MDB against it
20:55:42  <Domenic_>isaacs: why can't you fire up debuggers against mocha? Mocha is after all just a node script.
20:55:44  <tjfontaine>bnoordhuis: what's the purpose of the async send in the current watchdog implementation, seems like it would make sense if we were using UV_RUN_DEFAULT and wanted to signal it to close, but that's not what's even happening
20:55:46  <isaacs>Domenic_: a test runner is only good if you want the high-level overview.
20:55:57  <isaacs>Domenic_: running it with two differen builds of node?
20:56:10  <isaacs>Domenic_: i have to them put them in separate folders, and monkey with my PATH to do that.
20:56:19  <isaacs>Domenic_: i can't just do ./node-my-feature test-file.js
20:56:33  <isaacs>or ../node-master/node test-file.js
20:56:37  <Domenic_>isaacs: ok, so now you have to do ./node /path/to/mocha test-file.js.
20:56:41  <isaacs>vs ../node-v0.8/node test-file.js
20:56:51  <Domenic_>The added inconvenience in that very minority use case is just *not* something mocha's author has optimized for.
20:57:11  <Domenic_>and honestly I don't think it's something they should be optimizing for, given that it's a test framework for normal people.
20:57:29  <MI6>nodejs-master: #454 UNSTABLE smartos-x64 (10/630) smartos-ia32 (3/630) osx-x64 (1/630) osx-ia32 (1/630) linux-ia32 (2/630) linux-x64 (2/630) http://jenkins.nodejs.org/job/nodejs-master/454/
20:58:08  <isaacs>Domenic_: i don't think tap is for abnormal people.
20:58:19  <bnoordhuis>tjfontaine: one of two things is supposed to happen: either the timer fires or the script completes in time and we kill the watchdog (gruesome!)
20:58:22  <isaacs>Domenic_: a test runner should be a very lightweight flow-control and some assertion helpers.
20:58:31  <Domenic_>isaacs: it's pretty crazy, at least for the frontend devs I've tried to introduce it to.
20:58:45  <bnoordhuis>tjfontaine: the async handle is to wake up the watchdog thread once the script completes in the main thread
20:58:55  <isaacs>Domenic_: most frontend devs think testing as such is crazy.
20:59:16  <isaacs>compared with selenium, it's nothing
20:59:39  <isaacs>and really, the basic use-case is more trivial than using mocha. as in, there are fewer moving parts.
21:00:28  <tjfontaine>bnoordhuis: so that we're sure that we're closing things on the right thread, doesn't that mean that Watchdog::Async is executed on the proper thread? shouldn't there be some logic in that method to do something?
21:00:47  <Domenic_>isaacs: perhaps it is more simple. but it is definitely not more easy.
21:00:48  <isaacs>so, from what i can gather: describe(name, function() { preTestStuff(), it(name, fn) is like tap.test(name, fn), and then expect(actualValue).to.equal(expectedValue) is like t.equal(found, wanted)
21:00:52  <isaacs>right?
21:01:08  <isaacs>bbiab
21:01:33  <Domenic_>isaacs: that's about right, although the assertion library is decoupled from the test runner so that expect syntax is just part of the chai library; you can use `require('assert')` if you want instead.
21:01:43  <Domenic_>(another big win for mocha IMO, over things like tap)
21:01:57  <isaacs>Domenic_: you can use assert() in tap, too
21:02:01  <isaacs>throw = test fails
21:02:08  <Domenic_>isaacs: even inside async?
21:02:14  <isaacs>yeah, why wouldn't you?
21:02:18  <isaacs>tap tests are just node programs
21:02:22  <isaacs>you don't even have to use the tap lib
21:02:28  <Domenic_>ah, so it'll stop running the rest of your tests.
21:02:39  <isaacs>no, just that test
21:02:48  <Domenic_>even when async? interesting. domains i guess.
21:02:58  <isaacs>bbiab
21:04:48  <tjfontaine>ok, so the async_send just breaks the uv_run
21:09:58  * dshaw_quit (Quit: Leaving.)
21:10:57  <tjfontaine>boo, uv_print_active_handles isn't available in release :P
21:12:23  <indutny>gosh
21:12:36  <indutny>this FSEvents thing makes me feel dizzy
21:16:20  * pachetquit (Quit: [ +++ ])
21:18:55  <trevnorris>isaacs: ping
21:26:37  <MI6>nodejs-master-windows: #250 UNSTABLE windows-x64 (18/630) windows-ia32 (18/630) http://jenkins.nodejs.org/job/nodejs-master-windows/250/
21:40:01  <tjfontaine>it felt so dirty writing the addon to enable harmony at "runtime"
21:40:33  <trevnorris>tjfontaine: how do you mean?
21:40:52  <tjfontaine>I'ms ure I told ircretary to tell you about it :)
21:40:54  <tjfontaine>https://npmjs.org/package/setflags
21:41:03  * indexzero_joined
21:41:19  <trevnorris>tjfontaine: ooh, cool.
21:41:23  * indexzero_quit (Client Quit)
21:41:36  <tjfontaine>things that enable new tokens require a new context of course
21:41:56  <tjfontaine>but you can enable gc tracing at runtime if you are desparate or whatever
21:42:12  <sblom>tjfontaine: late pong
21:42:18  * trevnorrispart ("Leaving")
21:42:26  * trevnorrisjoined
21:43:07  <tjfontaine>sblom: I'm looking into this bug for vm2, it's an implementation difference for timers on windows vs unix, isaacs mentioned it might be a good candidate for your thur/fri hacking
21:43:26  * taterbasequit (Remote host closed the connection)
21:43:27  * indexzeroquit (Ping timeout: 256 seconds)
21:43:44  <sblom>sounds good to me. do you know the issue number?
21:44:15  <tjfontaine>I don't have a separate issue for it, I am about to double check this happens on master as well just to double check
21:44:27  <sblom>okay--cool.
21:44:55  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-master-windows/250/DESTCPU=ia32,label=windows/tapTestReport/test.tap-600/
21:45:01  <tjfontaine>ya it's happening on master right now as well it seems
21:47:16  <sblom>cool--Jonathan and I will take a look.
21:47:29  <tjfontaine>sblom: I'll drop you the issue with what I've learned
21:48:25  * TooTallNatejoined
21:48:31  * dshaw_joined
21:48:45  <trevnorris>it's really too bad that harmony Map is over 50x's slower than just using normal object properties.
21:49:00  <trevnorris>hopefully that'll speed up.
21:49:20  <trevnorris>i might hate generators, but Map is very useful.
21:52:35  * c4miloquit (Remote host closed the connection)
21:53:19  * TooTallNatequit (Ping timeout: 264 seconds)
21:54:36  <trevnorris>for anyone, not sure what to do with async listeners called from the event emitter. think I should somehow pass the event to the listener?
21:57:26  <tjfontaine>sblom: https://github.com/joyent/node/issues/6088
21:57:48  <tjfontaine>trevnorris: ENEEDMORECONTEXT
21:58:48  <trevnorris>tjfontaine: calls to oncomplete only have context, callback and arguments. but events also have a specific event that triggered the callback. should the async callback be told what event was emitted that lead to that callback being called.
21:59:08  <trevnorris>tjfontaine: oh, you've been gone. even know what I'm talking about w/ async listener?
21:59:45  <tjfontaine>I am assuming node.c but this is why I'm asking for more context :)
21:59:47  <othiym23>trevnorris: my inclination would be to strive for consistency as much as possible
22:00:11  <trevnorris>tjfontaine: no, this is for the low level api to separate domains from core
22:00:31  <trevnorris>othiym23: that's what I'd like. just trying to figure out the best syntax for it.
22:00:38  <othiym23>for most async listeners you just want the opportunity to do something with the continuation / callback (most of the time domains and my thing are going to wrap that callback in a closure to set up a context before the continuation is called)
22:00:48  <othiym23>so I'm not sure the actual event is relevant
22:01:24  <trevnorris>othiym23: ok, that makes sense. now, my gotcha is for errors. they don't have a callback.
22:01:55  <trevnorris>othiym23: so i'm playing w/ the idea of adding process.addErrorListener() like I have process.addAsyncListener(), but that seems bloated.
22:02:11  <othiym23>how would that be different from process._fatalException()?
22:02:26  <othiym23>separating concerns doesn't feel like bloat to me, IMO
22:03:14  <trevnorris>othiym23: thanks for reminding me about process._fatalException. completely forgot about that.
22:03:49  <trevnorris>othiym23: ok, so I'll go w/ adding process.addErrorListener() for now. we can figure out the details later.
22:04:03  <othiym23>cool cool
22:05:25  <tjfontaine>I'm not saying I have a better name, but AsyncListener feels awkward and obtuse to me
22:05:43  <trevnorris>tjfontaine: well, it's not set in stone. just a name I'm using for now.
22:05:44  <othiym23>tjfontaine: welcome to the fun world of trying to name basic abstractions
22:05:57  <othiym23>eventSourceWatcher
22:06:05  <othiym23>stuffDoer
22:06:17  <othiym23>executionScopeWrapperObserverFactory
22:06:24  <trevnorris>haha
22:06:39  <tjfontaine>othiym23: indeed.
22:07:01  <tjfontaine>trevnorris: and I understand, I'm just raising the flag now and not later :)
22:07:01  <trevnorris>othiym23: also fyi, this api works off the listener, not the domain object. so you can actually setup a listener w/o worrying about setting up a domain object and just intercept all callbacks.
22:07:45  <trevnorris>tjfontaine: that's cool. this is a serious abstraction and any feedback is welcome. https://github.com/joyent/node/pull/6011
22:07:49  <othiym23>trevnorris: that's pretty much what creationix's glue code does in its monkeypatchy way
22:08:42  * st_lukequit (Remote host closed the connection)
22:08:53  <trevnorris>othiym23: i'm shooting for an api that all you can use w/o any monkeypatching, etc. if you find that's still necessary let me know and i'll do more work.
22:08:59  <tjfontaine>trevnorris: blah, difficult to work through bceause of the multi-context :)
22:09:10  <tjfontaine>commit at a time I guess :)
22:09:12  * st_lukejoined
22:09:21  <trevnorris>tjfontaine: heh, yeah. have to do it that way for now.
22:09:37  <tjfontaine>I could go to your tree and just exclude it, but meh
22:09:47  <othiym23>trevnorris: as soon as you hit a stopping-off point, let me know and I'll see if I can get CLS up and running with it
22:10:07  <othiym23>since the New Relic agent depends on CLS and the glue layer working, its tests are a pretty good test for CLS as well
22:10:31  <trevnorris>othiym23: will do. i'm just about there. that'll be nice to have such full coverage.
22:12:15  <tjfontaine>the commit messages are hilarious
22:12:18  <othiym23>I'll also be porting over the CLS-glue tests, which are pretty comprehensive for most of the MakeCallback dependents
22:12:33  <othiym23>it just needs cases for zlib and crypto
22:12:33  <trevnorris>:)
22:12:58  <trevnorris>othiym23: that's great. sounds like we'll know pretty immediately whether this'll hold up or not.
22:13:15  <trevnorris>now, these error cases are being a bitch.
22:13:36  <othiym23>in my experience, not breaking error semantics is the hardest part of this stuff
22:13:54  * jmar777joined
22:14:11  <trevnorris>well, the hard part is that it looks for process.domain, and depends on that being an instance of EventEmitter
22:14:35  <tjfontaine>really an instance of duck typing of an eventemitter :P
22:14:43  <trevnorris>but now that listeners don't depend on process.domain i'm not sure how to propagate the errors to the listener
22:14:44  <trevnorris>heh
22:17:46  <trevnorris>othiym23: don't you have a pr to remove domain.dispose() ?
22:18:02  <othiym23>trevnorris: to gut it and deprecate it, yeah
22:18:16  <othiym23>it nerfs all the really bad and crazy stuff it does
22:18:40  <othiym23>https://github.com/joyent/node/pull/5021
22:19:38  * mikealquit (Quit: Leaving.)
22:19:53  * mikealjoined
22:20:28  <othiym23>trevnorris: you're not planning on nuking process.domain, are you?
22:20:43  <tjfontaine>I don't think we can
22:20:50  <trevnorris>othiym23: no, not at all.
22:20:54  <othiym23>cool
22:21:07  <trevnorris>but i'll operate slightly differently.
22:21:25  <trevnorris>basically, there's now a concept of a domain, and the actual domain module.
22:22:02  <trevnorris>the domain concept can be adopted by any module author, and it's supplementary to the async listeners.
22:22:28  <othiym23>what do you mean by "the domain concept can be adopted by any module author"?
22:23:27  <trevnorris>if you set an async listener, that listener will be attached to the async callback scheduled while it's active. and if you set process.domain that'll also propagate, and be passed as an argument to the async listener.
22:24:18  <trevnorris>othiym23: here's how the domain module will work w/ the new syntax: https://github.com/trevnorris/node/blob/0335392/lib/domain.js#L49-L61
22:24:40  <trevnorris>so it'll feel the same as before, but won't rely on any of core internals.
22:25:21  <othiym23>right
22:25:37  <trevnorris>you'll be able to set a single active listener, but swap out the domain object whenever you want. and that object will be attached to the callback.
22:25:52  <othiym23>the thing about CLS is that it's basically taking domains and partitioning the concept into separate namespaces
22:26:08  <othiym23>where domains are a specialized class that deal with error-handling
22:26:11  * felixgequit (Quit: felixge)
22:26:20  <othiym23>wait, back up
22:26:28  <brson>does uv_idle_stop deref the event loop and cause it to exit?
22:26:29  <othiym23>only one async listener can be registered at a time?
22:27:05  <trevnorris>othiym23: for now. it's a shit storm to get multiple, i'm working on the simple case now and plan on adding that in later.
22:28:01  <othiym23>that's a serious restriction
22:28:23  <othiym23>the agent relies upon both domains and CLS namespaces operating simultaneously
22:28:25  <tjfontaine>brson: hrm
22:28:47  <othiym23>because it traces both errors and execution
22:28:49  <tjfontaine>oh
22:29:41  <trevnorris>othiym23: but w/ the new api you won't need the domain module at all since you'll receive all errors and callbacks for execution.
22:29:43  <tjfontaine>brson: heh, that symbol doesn't really even exist on the unix side, does it?
22:30:33  <tjfontaine>hm how does this work
22:31:06  <brson>tjfontaine: loop-watcher.c has a number of macros for this
22:31:26  <othiym23>trevnorris: yeah, but remember that the agent is a component running inside somebody else's application
22:31:40  <othiym23>and they will of course be using domains because I taught everyone that they should be using domains at NodeConf ;)
22:31:51  <tjfontaine>oh god, macros
22:31:53  <trevnorris>hah
22:32:00  <tjfontaine>brson: painful.
22:33:27  <trevnorris>othiym23: let is suffice that having multiple listeners is on the list of todo's, but that seemingly small feature proved more complex then the rest combine, for how it should be implemented.
22:33:45  <tjfontaine>brson: anyway, yes, it appears to be essentially equivalent to a close in that regard, the stop removes the reference that is holding the loop open
22:33:57  <trevnorris>othiym23: so i'm leaving it out until I can get the simple case working, then we can have a big discussion how multiple listeners should operate.
22:34:25  <othiym23>well yeah, I get that, it was something that was super daunting as I was working on my own thing
22:34:31  <brson>tjfontaine: thanks
22:34:33  <othiym23>which is why it was my plan to rebuild domains to run on top of CLS
22:34:52  <trevnorris>yeah, that sounds painful.
22:35:50  * EhevuTovquit (Ping timeout: 245 seconds)
22:37:33  * EhevuTovjoined
22:41:24  <brson>i didn't expect uv_idle_stop to deref the event loop - i expected that while there were any outstanding handles the loop would continue being reffed. in what other situations does the event loop get dereffed with outstanding handles?
22:41:53  <tjfontaine>brson: well, it derefs itself, there isn't a loop ref
22:42:47  * AvianFluquit (Remote host closed the connection)
22:43:26  <indutny>bnoordhuis: almost figured out fsevents thingy :)
22:43:33  <tjfontaine>brson: but if the idle is the only thing
22:43:44  <indutny>I think I should finish it tomorrow
22:43:50  <brson>tjfontaine: i don't think i understand that statement. what does it mean for the idle handle to deref itself? if there isn't a loop ref what mechanism keeps the loop running? this is changing my whole world outlook. how have i written so much uv code without understanding what i'm doing?
22:44:44  <tjfontaine>brson: handles have a reference, and the reference count of the loop is the sum of handles with refs, but there's no reference count just on the loop itself
22:45:33  <tjfontaine>brson: the loop stays running so long as there are active handles with a reference
22:45:54  <tjfontaine>brson: but it's not like there is loop.ref++ loop.ref-- happening
22:45:55  * paulfryzelquit (Remote host closed the connection)
22:46:29  * paulfryzeljoined
22:48:40  <brson>tjfontaine: when the idle ref drops to zero as a result of idle_stop it isn't destroyed yet and I need to call close still. does the ref count increase again as a result of calling close?
22:48:50  <brson>then decrease after the close cb?
22:49:33  <brson>i guess after the close cb the handle is destroyed, so whatever the ref was it must be 0 afterward?
22:50:25  <tjfontaine>for idle_close it's just a wrap around idle_stop, what there really is a linked list of "active"/"ref'd" handles, so long as that list isn't empty the loop stays alive
22:50:45  * paulfryzelquit (Ping timeout: 248 seconds)
22:50:59  <othiym23>trevnorris: fixed typo you found
22:51:01  <tjfontaine>but handle_stop and handle_close remove the item from the active list
22:51:42  <trevnorris>othiym23: cool. I like deleting code, but we'll have to wait for isaacs to approve this one.
22:52:07  <othiym23>oh, I know
22:52:19  <othiym23>I've been bugging him patiently for months now ;)
22:52:23  <brson>tjfontaine: ok, i see. i forgot that close and delete are two diferent operations (I have them conflated in the rust bindings)
22:52:29  <trevnorris>heh, well i'll join in. :)
22:53:40  <brson>tjfontaine: thanks for the clarifications
22:54:44  <tjfontaine>brson: hopefully I didn't muddle it up too much :P
23:00:30  * jmar777quit (Remote host closed the connection)
23:01:29  * ecrjoined
23:05:20  * bnoordhuisquit (Ping timeout: 260 seconds)
23:09:39  * dshaw_quit (Quit: Leaving.)
23:11:04  * dominictarrquit (Quit: dominictarr)
23:12:14  * EhevuTovquit (Quit: This computer has gone to sleep)
23:14:48  * jmar777joined
23:15:52  <trevnorris>tjfontaine: ping
23:16:41  <tjfontaine>pong-ish
23:17:24  <trevnorris>tjfontaine: comment in src/node.js in starup.processAssert that JS2C pre-processes out all asserts and debug for release builds. i'll just assume that's now crap?
23:18:07  <tjfontaine>ya, that is certainly not how it works in todays land
23:18:27  <trevnorris>well, bummer.
23:19:00  * dshaw_joined
23:26:08  * dominictarrjoined
23:27:00  * EhevuTovjoined
23:32:55  * sblomquit (Ping timeout: 264 seconds)
23:43:06  * AvianFlujoined
23:46:36  * jmar777quit (Remote host closed the connection)
23:47:06  * paulfryzeljoined
23:50:51  * austoquit (Quit: Leaving)
23:51:28  * paulfryzelquit (Ping timeout: 264 seconds)
23:55:17  * dshaw_quit (Quit: Leaving.)
23:55:52  * mikealquit (Quit: Leaving.)
23:57:13  * mikealjoined
23:59:08  <MI6>libuv-master-gyp: #116 UNSTABLE linux-ia32 (1/192) windows-x64 (3/193) smartos-ia32 (2/192) smartos-x64 (2/192) windows-ia32 (4/193) http://jenkins.nodejs.org/job/libuv-master-gyp/116/