00:00:02  * ircretaryquit (Remote host closed the connection)
00:00:13  * ircretaryjoined
00:08:10  <trevnorris>tjfontaine: mind jumping into #node-core?
00:09:22  <trevnorris>tjfontaine: also test-http-many-keep-alive-connections.js fails for me in v0.10.32
00:09:35  <trevnorris>tjfontaine: where it didn't fail for me in v0.10.31
00:10:05  <trevnorris>tjfontaine: ditto w/ test-net-GH-5504.js
00:10:06  * mikealquit (Quit: Leaving.)
00:10:24  <trevnorris>just FYI
00:14:34  <trevnorris>crap, one of those failures is because of one of my commits.
00:14:48  * dap_quit (Quit: Leaving.)
00:15:40  * abraxasjoined
00:20:38  * abraxasquit (Ping timeout: 272 seconds)
00:22:04  <trevnorris>oy, nm. test-net-GH-5504.js is just failing sporadically.
00:28:11  <cjihrig>trevnorris do you still need anything from me regarding that test?
00:28:42  <trevnorris>cjihrig: nope. that test is just failing sporadically on my box. just happen to fail on your commit when I was bisecting. sorry about that.
00:29:06  <cjihrig>no problem. glad i didn't break anything
00:38:41  * yunongjoined
00:41:55  * sblomquit (Read error: Connection reset by peer)
00:42:55  * jgiquit (Quit: jgi)
00:47:37  * octetcloudquit (Ping timeout: 272 seconds)
00:48:23  * a_lequit (Remote host closed the connection)
00:54:11  * brsonquit (Quit: leaving)
01:05:10  * FROGGS_joined
01:08:37  * FROGGSquit (Ping timeout: 245 seconds)
01:09:51  * a_lejoined
01:11:41  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:12:50  * sh1mmerjoined
01:14:45  * sh1mmerquit (Client Quit)
01:17:04  * sh1mmerjoined
01:17:47  * yunongquit (Ping timeout: 245 seconds)
01:19:19  * sh1mmerquit (Client Quit)
01:22:22  * sh1mmerjoined
01:30:01  * thlorenzjoined
01:31:16  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:31:23  * avalanch_quit (Remote host closed the connection)
01:31:54  * avalanche123joined
01:36:55  * thlorenzquit (Remote host closed the connection)
01:37:29  * thlorenzjoined
01:39:34  * sh1mmerjoined
01:42:09  * thlorenzquit (Ping timeout: 260 seconds)
01:42:51  * avalanche123quit (Remote host closed the connection)
01:51:05  * iarnaquit (Read error: Connection reset by peer)
01:51:34  * iarnajoined
01:51:49  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:51:57  * iarnaquit (Remote host closed the connection)
01:52:08  * iarnajoined
02:04:24  * thlorenzjoined
02:09:10  * kazuponjoined
02:10:58  * kazuponquit (Remote host closed the connection)
02:15:41  * avalanche123joined
02:16:50  * mscdex_joined
02:17:12  * avalanch_joined
02:17:52  * avalanche123quit (Remote host closed the connection)
02:19:25  * iarnaquit (Remote host closed the connection)
02:19:54  * mscdexquit (Ping timeout: 258 seconds)
02:20:20  * paulfryzelquit (Ping timeout: 272 seconds)
02:22:23  * paulfryzeljoined
02:35:09  * mikealjoined
02:38:31  * mscdex_changed nick to mscdex
02:38:55  * mscdexpart ("Leaving")
02:42:34  * octetcloudjoined
02:45:57  * mikealquit (Quit: Leaving.)
02:49:31  * chris_99quit (Ping timeout: 272 seconds)
02:58:07  * avalanch_quit (Remote host closed the connection)
02:58:34  * avalanche123joined
03:00:39  * Left_Turnquit (Remote host closed the connection)
03:01:19  * mikealjoined
03:02:57  * avalanche123quit (Ping timeout: 246 seconds)
03:03:22  * mikealquit (Client Quit)
03:06:27  * petka_quit (Quit: Connection closed for inactivity)
03:08:43  * danlovesproofsquit (Quit: lel sleep yolo)
03:16:38  * mikealjoined
03:33:46  * zz_karupachanged nick to karupa
03:34:33  * thlorenzquit (Remote host closed the connection)
03:35:32  * avalanche123joined
03:52:56  * avalanche123quit (Remote host closed the connection)
03:53:23  * avalanche123joined
03:57:53  * avalanche123quit (Ping timeout: 260 seconds)
04:02:20  * danlovesproofsjoined
04:04:29  * cjihrigquit (Quit: Leaving.)
04:15:24  * mikealquit (Quit: Leaving.)
04:32:25  * dshaw_joined
04:34:38  * avalanche123joined
04:54:58  * danlovesproofsquit (Quit: lel sleep yolo)
04:55:31  * avalanche123quit (Remote host closed the connection)
04:56:04  * avalanche123joined
05:00:12  * avalanche123quit (Ping timeout: 246 seconds)
05:11:27  * octetcloudquit (Quit: WeeChat 1.0)
05:26:01  * dshaw_quit (Quit: Leaving.)
05:34:12  * avalanche123joined
05:35:58  * wolfeidauquit
05:40:58  * FROGGS[mobile]2quit (Remote host closed the connection)
05:41:42  * wolfeidaujoined
05:44:12  * a_lequit (Remote host closed the connection)
05:44:48  * a_lejoined
05:56:37  * a_lequit (Remote host closed the connection)
05:57:14  * a_lejoined
06:01:27  * a_lequit (Ping timeout: 245 seconds)
06:18:10  * abraxasjoined
06:21:23  * FROGGS_quit (Quit: Verlassend)
06:22:40  * abraxasquit (Ping timeout: 250 seconds)
06:44:46  * avalanche123quit (Remote host closed the connection)
06:45:16  * avalanche123joined
06:49:47  * avalanche123quit (Ping timeout: 245 seconds)
06:54:16  * janjongboomjoined
07:05:26  * FROGGSjoined
07:10:38  * avalanche123joined
07:13:46  * avalanche123quit (Remote host closed the connection)
07:14:12  * avalanche123joined
07:18:27  * avalanche123quit (Ping timeout: 246 seconds)
07:24:37  * janjongb_joined
07:26:24  <MI6>joyent/libuv: Zachary Newman v1.x * b7003be : doc: update references to current stable branch - http://git.io/HfH_Fg
07:26:27  * janjongboomquit (Ping timeout: 245 seconds)
07:54:41  <MI6>joyent/node: Julien Gilli v0.12 * 64d6de9 : http: write() after end() emits an error. - http://git.io/l_eCjA
08:19:17  * abraxasjoined
08:23:57  * abraxasquit (Ping timeout: 260 seconds)
08:31:27  * Soarez|afkchanged nick to Soarez
08:38:08  * karupachanged nick to zz_karupa
08:49:09  * abraxasjoined
08:53:39  * abraxasquit (Ping timeout: 244 seconds)
09:04:11  * rendarjoined
09:04:32  <indutny>ohai
09:06:05  * sinclair-workquit (Remote host closed the connection)
09:22:07  <txdv>saghul: why don't we have a UV_SUCCESS?
09:23:17  <saghul>txdv: because it's 0 :-)
09:24:07  <nathan7>success does not exist in the liberal utopian void
09:24:14  <nathan7>you get to figure out what to call it all by yourself
09:27:53  <txdv>#define UV_SAGHUL 0
09:28:28  <saghul>make it random(), for extra fun!
09:33:11  <txdv>https://github.com/joyent/libuv/pull/1492
09:34:09  <txdv>saghul: is there a possibility to create a random number during compliation?
09:34:25  <txdv>or should we define UV_SUCCESS as (random()) ?
09:35:30  <txdv>but you can't use that in an enum
09:39:35  <saghul>banters aside, I don't want to have UV_SUCCESS
09:42:34  * AlexisMochajoined
09:54:11  <MI6>joyent/node: Fedor Indutny v0.12 * 6e08bb9 : crypto: export externals to internal structs - http://git.io/SkrmDg
09:57:13  <nathan7>I'm totally on board with the UV_SAGHUL proposal
10:04:53  <txdv>2 to 1 saghul, you loose
10:05:08  <txdv>if indutny doesn't get on your side in 1 hour, you will have to merge that
10:05:20  <indutny>mm?
10:14:19  <txdv>we thought we need an enum for successful return values
10:14:20  <txdv>for 0
10:14:40  <txdv>https://github.com/joyent/libuv/pull/1492
10:19:29  * seishunjoined
10:23:44  <txdv>saghul: should we run the the write_req cancel callbacks before the connect_cb?
10:25:26  <saghul>txdv: no, after
10:26:29  <txdv>why?
10:27:54  <saghul>because even if connect succeeds writes may fail. write callbacks must come after connect callback
10:32:09  * Left_Turnjoined
10:34:24  * AlexisMochaquit (Ping timeout: 244 seconds)
10:35:38  * iarnajoined
10:47:37  * chris_99joined
10:53:48  * chris_99quit (Remote host closed the connection)
10:58:27  * AndreasMadsenjoined
10:58:44  * a_lejoined
10:59:07  * AndreasMadsenquit (Client Quit)
11:03:51  * a_lequit (Ping timeout: 272 seconds)
11:46:02  <txdv>saghul: need some nitpicking plz
11:46:52  * Soarezchanged nick to Soarez|afk
11:49:40  * mikealjoined
11:54:25  <MI6>joyent/node: Calvin Metcalf v0.10 * c8e0bdd : doc: document _transform callback takes 2 args - http://git.io/Er4G3A
11:54:57  <saghul>txdv: sup
11:57:31  <txdv>added the queue for pipes as well
11:59:41  <saghul>txdv: will check
11:59:57  * AndreasMadsenjoined
12:00:35  * AndreasMadsenquit (Client Quit)
12:01:36  * a_lejoined
12:05:10  <txdv>saghul: i guess we need to make a test for shutdown as wel
12:05:32  <saghul>what needs to be tested?
12:05:54  <txdv>whether shutdown is queued correctly and executed when the tcp/pipe/tty is not yet connected?
12:06:01  * a_lequit (Ping timeout: 258 seconds)
12:06:42  <txdv>if uv_connect;uv_write;uv_shutdown; works without nesting in the callbacks
12:07:56  <saghul>don't we have a test case like that for unix? it not it would be welcome
12:08:55  <txdv>https://github.com/joyent/libuv/blob/v1.x/src/win/stream.c#L195-L197
12:09:14  * jas-quit (Remote host closed the connection)
12:19:35  <txdv>tcp doesn't have a handle private field
12:20:34  <txdv>and there is no such thing as UV_INVALID_HANDLE
12:29:02  <saghul>I know, look at uv_fileno for details
12:34:46  * mikealquit (Quit: Leaving.)
12:36:57  * lance|afkchanged nick to lanceball
12:40:36  <txdv>saghul: ill squash the commits, ok?
12:41:25  <txdv>saghul: why does uv_pipe_connect have no return value
12:41:39  <saghul>txdv: ok
12:43:04  <saghul>txdv: I guess it cannot fail
12:45:17  <txdv>no, it just returns all failure values in the callbacks
12:48:02  <txdv>it literally returns all the error codes which you can return immediately in the callback
12:48:22  <txdv>aren't we supposed to return immediately?
12:48:26  <txdv>EINVAL and shit?
12:49:33  * cjihrigjoined
12:51:12  * abraxasjoined
12:55:11  <saghul>txdv: the (unwritten) rule is: parameter checks return immediately, everything else goes in the callbak
12:55:51  * abraxasquit (Ping timeout: 258 seconds)
12:58:02  * janjongb_quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:58:58  * kenperkinsquit (Quit: Computer has gone to sleep.)
13:00:27  * avalanche123joined
13:00:34  * kenperkinsjoined
13:03:18  * iarnaquit (Remote host closed the connection)
13:05:21  * avalanche123quit (Ping timeout: 260 seconds)
13:12:35  * janjongboomjoined
13:19:34  * mikealjoined
13:20:53  * mikealquit (Client Quit)
13:21:31  <txdv>saghul: tty should be used on 0 and 1?
13:21:34  * cjihrigquit (Quit: Leaving.)
13:21:36  <txdv>i meand stdin and stdout?
13:22:23  <saghul>it could be another fd
13:22:37  <saghul>you could open /dev/tty yourself and pass the fd
13:23:07  <txdv>what is /dev/tty?
13:23:49  <saghul>/dev/tty is the current tty device
13:24:32  <txdv>is there any reason to use it instead of stdout?
13:25:04  <saghul>yes, to the the fds
13:25:09  <saghul>ups
13:25:16  <txdv>to the fds and beyond!
13:25:25  <saghul>to set the fd to use non-blocking writes while not modifying the global stdout fd
13:26:27  <txdv>if i run an app in the terminal and that app spawns another app, that spawned app access /dev/tty, will it print to the terminal?
13:28:29  <saghul>txdv: explanation here: https://github.com/joyent/libuv/blob/master/src/unix/tty.c#L47-L55
13:28:30  * Soarez|afkchanged nick to Soarez
13:30:43  <txdv>what is this, a comment in the source code? how dare you to link me to documentation in the source code[3~
13:31:51  <txdv>a bit of sarcasm refering to all the neggers who couldn't find libuv documentation because it was in uv.h
13:32:34  <saghul>you wanted internals, I gave you internals :-)
13:32:46  <txdv>thats good to know
13:32:53  <txdv>i always did a uv_pipe_open(0)
13:32:59  <txdv>now i see my faulty ways
13:34:15  <saghul>uv_tty_init will do the reopen of /de/tty for you, so you are better off with that
13:35:26  * mikealjoined
13:37:14  <txdv>the void in uv_pipe_connect dates back to ryan https://github.com/joyent/libuv/blame/master/src/unix/pipe.c#L208-L214
13:37:57  <txdv>this must be wrong then, a man who promoted js cant be right
13:38:00  * AlexisMochajoined
13:39:09  * iarnajoined
13:41:33  * iarnaquit (Client Quit)
13:52:20  * cjihrigjoined
13:55:30  * bradleymeckjoined
13:55:54  * kenperkinsquit (Quit: Computer has gone to sleep.)
13:59:33  * cjihrigquit (Ping timeout: 246 seconds)
14:02:38  * a_lejoined
14:06:38  * groundwater_joined
14:06:38  * iamstef_joined
14:06:50  * cjihrigjoined
14:06:54  * iamstefquit (Ping timeout: 272 seconds)
14:06:54  * groundwaterquit (Ping timeout: 272 seconds)
14:07:01  * iamstef_changed nick to iamstef
14:07:04  * groundwater_changed nick to groundwater
14:07:32  * eugeneware____quit (Ping timeout: 272 seconds)
14:07:50  * a_lequit (Ping timeout: 272 seconds)
14:08:43  * eugeneware____joined
14:12:43  * a_lejoined
14:16:17  * kenperkinsjoined
14:16:34  * iarnajoined
14:25:41  * sinclair-workjoined
14:32:22  * FROGGS[mobile]joined
14:32:31  * FROGGSquit (Quit: Verlassend)
14:34:08  * cjihrigquit (Quit: Leaving.)
14:37:35  * KennethWilkejoined
14:38:32  * cjihrigjoined
14:47:48  * iarnaquit (Remote host closed the connection)
14:52:41  * thlorenzjoined
14:55:55  * FROGGSjoined
14:56:00  * thlorenzquit (Remote host closed the connection)
15:06:16  * iarnajoined
15:08:22  * thlorenzjoined
15:10:18  <txdv>saghul: that invalid handle check doesn't work for us
15:10:21  * iarnaquit (Client Quit)
15:10:27  <txdv>it is an invalid handle before it receives the connect callback
15:12:26  * Left_Turnquit (Ping timeout: 272 seconds)
15:17:33  * iarnajoined
15:19:08  <tjfontaine>deps/uv/m4/as_case.m4:21: new blank line at EOF.
15:19:08  <tjfontaine>deps/uv/src/win/util.c:76: trailing whitespace.
15:19:12  <tjfontaine>blah
15:19:23  * iarnaquit (Client Quit)
15:19:35  <MI6>joyent/node: Fedor Indutny merge-review * c5f5d4c : deps: update uv to v1.0.0-rc1 - http://git.io/zlwlkg
15:22:03  <txdv>tjfontaine: the windows code was written by a windows dude
15:22:05  <txdv>what do you expect
15:22:28  <tjfontaine>someone to read the output from git I guess
15:22:51  * thlorenzquit (Remote host closed the connection)
15:23:09  <txdv>blame it, date it, nobody looked back then at it
15:23:28  <brucem>just be happy that no one added random windows line feeds in the middle of a file.
15:23:39  * thlorenzjoined
15:23:43  <txdv>fixing trailing whitespaces pollute the history, though git has a feature which just ignores whitespaces in blame
15:23:54  <tjfontaine>I'm not asking to fix it, I'm just sad
15:24:00  <txdv>new blank line at EOF can be removed easily
15:27:17  <KennethWilke>y'all are brave to suport windows
15:27:30  <tjfontaine>that's one way to put it
15:28:33  <txdv>KennethWilke: you know what my workflow on windows is?
15:28:38  <KennethWilke>reboot?
15:28:41  <KennethWilke>lol
15:28:47  <txdv>msys2 + ssh into a bash console in windows
15:28:55  <txdv>so i can use make, vim, git, tig
15:29:11  <KennethWilke>yeah, i miss X when i try to write code on a windows box though
15:29:15  <txdv>http://is.gd/xCZC5h
15:29:23  <txdv>this is what windows development looks like nowadays
15:29:24  <KennethWilke>middle mouse click and my precious window manager
15:29:31  <KennethWilke>hard to live without
15:30:13  <KennethWilke>hmm, which wm is that one? looks similar to dwm
15:30:20  <txdv>awm
15:30:27  <txdv>awesome window manager
15:31:01  * brsonjoined
15:31:09  <KennethWilke>ah yeah, my colleague has tried to get me to use that one
15:31:11  <KennethWilke>looks nice
15:31:26  <txdv>doesn't matter, its basically the same
15:32:13  <KennethWilke>i have no dock/systray in dwm, and some of the crappy software i have to run for work will silently fail if you don't have a tray for those dock icons
15:32:44  <KennethWilke>i just run tint2 for the duration of running em, which seems sad
15:32:48  <txdv>dwm is pure C?
15:32:54  <KennethWilke>yeah ~2000 lines
15:33:00  <KennethWilke>little over
15:33:03  <txdv>and what about customization?
15:33:15  <txdv>you have to put it in there yourself?
15:33:32  <KennethWilke>yeah, there are a few available patches for quick things
15:33:43  <KennethWilke>but you mostly hack on it for what you want i think
15:34:08  <txdv>sounds like i could like it
15:34:12  <KennethWilke>http://dwm.suckless.org/patches/gridmode
15:34:18  <KennethWilke>this one was a big reason why i stuck with it
15:34:32  <KennethWilke>when i was using cssh and logging into a few dozen web nodes or whatever
15:34:55  <txdv>http://is.gd/rbKPF2
15:34:56  <KennethWilke>combined it fills the screen with evenly laid out shells
15:34:57  <txdv>you mean this?
15:35:11  <KennethWilke>absolutely
15:35:21  <txdv>http://is.gd/532iRi
15:35:50  <txdv>i think all the window managers have that
15:35:59  <txdv>i would add this one to the main source
15:36:08  <txdv>its too useful to keep it as a patch
15:36:11  * iarnajoined
15:36:34  <txdv>"O no, but this will exceed 2k lines and next thing I know I have written an ecams clone"
15:36:37  <KennethWilke>yeah i agree with that, i don't think it's a very active project though
15:37:04  <txdv>all of open source is not
15:37:25  <txdv>look at sagul, he just writes proposals and merges code lately
15:37:32  <KennethWilke>lol
15:37:53  <txdv>i've been lazy on libuv too
15:37:55  <KennethWilke>i just came across libuv yesterday, so still pretty green
15:38:00  * cjihrigquit (Quit: Leaving.)
15:38:03  <txdv>and what do you need it for/
15:38:28  <KennethWilke>i was working on a reverse proxy, first considered using epoll directly, then made a proof of concept with libevent instead not knowing how bad of an idea that was
15:39:20  <txdv>just use nginx
15:39:33  <txdv>if you need a tls terminator, there is bud written with libuv
15:39:46  <KennethWilke>i don't enjoy working on nginx
15:39:53  <KennethWilke>went down that route already too
15:40:01  <txdv>and why is libevent bad?
15:40:14  <KennethWilke>mostly the performance wasn't where i wanted it to be
15:40:35  * cjihrigjoined
15:40:38  <txdv>maybe you have written not very performant code?
15:41:14  <KennethWilke>it's absolutely possible, but it was a light weight concept that used the more efficient bits of libevent i had found
15:41:32  <txdv>so you are going to try libuv now?
15:41:44  <KennethWilke>that's the next plan yeah
15:41:53  <KennethWilke>the api looks solid and reasonable
15:41:58  <txdv>if you run into performance problems or other problems write in this channel, if im around ill help you
15:42:10  * Left_Turnjoined
15:42:10  <KennethWilke>just want to whip up a proof of concept and benchmark it
15:42:19  <KennethWilke>that sounds great, thanks
15:42:56  <KennethWilke>one i get an initial solid prototype, if i do, it'll be released under something BSDish licensed
15:43:24  <KennethWilke>osht, i was supposed to meet with my boss :x
15:43:27  <KennethWilke>got distracted, brb
15:44:06  <KennethWilke>lol nvm that's in an hour
15:45:53  <txdv>i need to learn more about docker
15:46:05  <txdv>so i can test it on various virtual machines
15:46:24  <txdv>does solaris run in docker/
15:46:32  <KennethWilke>i wish they'd get their kernel namespace support in their, they said they'd have that for v1.0 but they didn't
15:46:44  <txdv>kernel namespace support?
15:47:17  <KennethWilke>like kernel level user jailing
15:47:32  <KennethWilke>right now i think root on the container is root on the container host, as far as kernel ops go
15:47:46  <txdv>dafuq
15:47:53  <KennethWilke>as far as solaris i have no clue, i've only used docker on linux
15:48:07  <tjfontaine>zones on solaris are much more like jails on freebsd
15:48:20  <KennethWilke>i'm a total noob when it comes to solaris
15:48:21  <tjfontaine>the root for the zone/container is not the root for the global zone/host
15:49:12  <txdv>so someone in the container gaining access to root can destroy the entire system?
15:49:32  <tjfontaine>which container, a linux namespace container, or a zone?
15:49:38  <KennethWilke>a docker container
15:49:55  <tjfontaine>wasn't there another recent article on this?
15:50:05  <txdv>docker uses linux lxe containers
15:50:11  <txdv>lxc
15:50:15  <tjfontaine>docker uses plain cgroups as I understand it, not lxc
15:50:28  <tjfontaine>in fact there's tension between the lxc and docker groups
15:50:37  * dap_joined
15:50:38  <KennethWilke>yeah they've abandoned lxc for their own libcontainer
15:50:39  <saghul>txdv: will review later tonight, need some fresh air to clear my head first
15:50:49  <txdv>Docker includes the libcontainer library as a reference implementation for containers, and builds on top of libvirt, LXC (Linux containers) and systemd-nspawn, which provide interfaces to the facilities provided by the Linux kernel.[4][5]
15:50:56  <saghul>txdv: and thanks a lot for your work!
15:51:08  <txdv>saghul: that beautiful test i wrote
15:51:18  <KennethWilke>saghul: i updated that issue with my test results for ubuntu/gentoo/freebsd
15:51:57  <saghul>KennethWilke: thanks, i'll also check that
15:52:51  <txdv>do you have an explicit freebssd machine?
15:52:53  * FROGGSquit (Ping timeout: 260 seconds)
15:53:12  <KennethWilke>np, i really like where this lib seems to be going and would like to use the hell out of it and help if i can
15:54:00  <txdv>yeah, sure, we have a lot of windows code which we need to get on parity with the unix code
15:54:11  <txdv>there is a lot of stuff to enjoy fixing
15:57:34  <KennethWilke>lol well i'm totally useless on the windows front
15:57:37  <KennethWilke>:(
15:57:45  <KennethWilke>someday i'd like to know it a lot better
15:58:01  <txdv>yeah, i expected that
15:58:48  <KennethWilke>but i do know how to ensure my files aren't filled with \r when i code on windows
15:58:50  <KennethWilke>:p
16:00:21  <txdv>vim and git in msys2 ensure that it won't going to happen
16:00:41  * jgijoined
16:02:47  * avalanche123joined
16:05:07  <MI6>joyent/node: Fedor Indutny v0.12 * c5f5d4c : deps: update uv to v1.0.0-rc1 - http://git.io/g25kWg
16:05:19  * Damn3dquit (Ping timeout: 272 seconds)
16:05:53  <indutny>нфн
16:05:55  <indutny>yay
16:05:56  <indutny>heya
16:06:10  <indutny>tjfontaine: could you please also land a TLS fix?
16:06:12  <indutny>it is a fix anyway
16:06:19  <indutny>even if it isn't fixing the actual problem for mman yet
16:06:46  <tjfontaine>that upgrade breaks gzip tests on smartos -- inexplicably -- so Im' guessing it's going to be threadpool related or even scarier underlying stream related -- http://jenkins.nodejs.org/job/node-review-unix/DESTCPU=ia32,label=smartos/300/tapTestReport/simple.tap-749/
16:07:22  <tjfontaine>indutny: yes I can, going to do a quick call with jgi first
16:07:35  <indutny>sure
16:07:37  <indutny>thanks
16:07:40  * avalanche123quit (Ping timeout: 250 seconds)
16:09:55  * Damn3djoined
16:11:44  * cjihrigquit (Quit: Leaving.)
16:15:03  * KennethWilkequit (Quit: Leaving)
16:17:59  * Damn3dquit (Ping timeout: 272 seconds)
16:20:08  * KennethWilkejoined
16:20:31  * cjihrigjoined
16:23:22  * Damn3djoined
16:23:28  <tjfontaine>indutny, trevnorris, AlexisMocha: mind if I add jgi and chrisdickinson to the github project so they can triage issues?
16:24:42  <indutny>yep
16:24:44  <indutny>+1
16:25:23  * Ralithquit (Ping timeout: 240 seconds)
16:26:02  <AlexisMocha>sure
16:27:44  * txdvquit (Read error: Connection reset by peer)
16:28:45  * txdvjoined
16:31:25  <txdv>ooo man
16:31:26  <txdv>so beautiful
16:31:31  <txdv>that 2011 abort on everything code
16:32:44  <txdv>grep ERROR_OUTOFMEMORY, -r win/
16:32:49  <txdv>a nice batch of to fix
16:32:54  * a_lequit (Remote host closed the connection)
16:33:31  * a_lejoined
16:34:19  <tjfontaine>indutny, AlexisMocha: thanks
16:34:21  <tjfontaine>chrisdickinson: ping
16:36:35  * jgiquit (Quit: jgi)
16:37:15  * jgijoined
16:37:55  * jgiquit (Client Quit)
16:38:37  <indutny>tjfontaine: v0.11 release today?
16:38:45  <indutny>this would be a good present for us :D
16:38:48  * jgijoined
16:39:54  <tjfontaine>if we can get that zlib issue taken care of, the 0.12 build ended up failing on more than just smartos this time
16:40:14  * jgiquit (Client Quit)
16:40:39  * jgijoined
16:40:42  * thlorenzquit (Remote host closed the connection)
16:43:13  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:43:56  * iarnaquit (Quit: Leaving...)
16:44:45  * iarnajoined
16:47:09  <tjfontaine>othiym23: trying out 2.0.0 on 0.12 branch -- https://gist.github.com/tjfontaine/340a1c7d48376acabf6b
16:47:28  <tjfontaine>othiym23: it may be related to the recent gzip failures/libuv update -- still looking though
16:48:32  <tjfontaine>othiym23: hang on it's a fedor thing :)
16:49:19  <indutny>??
16:49:21  <tjfontaine>indutny: https://gist.github.com/tjfontaine/340a1c7d48376acabf6b
16:49:40  <indutny>oh nice
16:49:42  * thlorenzjoined
16:49:43  * Soarezpart ("Textual IRC Client: www.textualapp.com")
16:49:55  <tjfontaine>indutny: so, 0.11 is now blocked on fixing readdir :)
16:50:31  <indutny>haha
16:51:56  <indutny>I'd say that it looks like a libuv bug at this point
16:52:02  <indutny>tjfontaine: which test is it?
16:52:48  <tjfontaine>indutny: I upgraded npm, but I have a feeling if I revert it will still expose it
16:52:56  <indutny>oh
16:52:59  <indutny>so this is an npm thing
16:53:13  <tjfontaine>well that's how I exposed it
16:53:29  <indutny>interesting
16:53:48  <indutny>I wonder what `req->nbufs` is at that point
16:53:50  * iarnaquit (Quit: Leaving...)
16:54:27  <indutny>tjfontaine: what if I'll send you a patch? :)
16:54:32  <indutny>could you take a look at dbg output?
16:54:43  <indutny>https://gist.github.com/indutny/3ee22d75e3f92eba3e92
16:54:44  <indutny>tjfontaine: ^
16:54:46  <tjfontaine>heh interesting, it *doesn't* fail with npm 1.4.28
16:54:55  <indutny>guess it is racey
16:54:58  <tjfontaine>probably
16:55:00  * chris_99joined
16:55:15  <indutny>windows or unix?
16:55:23  <tjfontaine>unix, osx at this time
16:55:34  <tjfontaine>ah ok -- it does fail on 1.4.28
16:56:21  <indutny>ok, please help me reproducing it
16:56:27  <indutny>help me to reproduce it
16:56:33  <tjfontaine>indutny: readdir 0x0 1
16:56:38  <tjfontaine>npm install hapi
16:56:39  <tjfontaine>:)
16:56:39  <indutny>oook
16:56:46  <indutny>it is very surprising
16:57:07  <indutny>one more patch, please
16:57:07  <indutny> fprintf(stdout, "readdir %p %d %d\n", req->ptr, req->nbufs, req->result);
16:57:11  <indutny>instead of that line
16:58:19  <tjfontaine>indutny: added a comment with the output
16:58:24  <tjfontaine>to the original gist
16:58:28  <indutny>thanks
16:58:37  <indutny>oh gosh
16:58:42  <indutny>this is fucking ridiculous
16:59:49  <indutny>tjfontaine: updated the gist
16:59:53  <indutny>should fix a test, I guess
16:59:57  <indutny>saghul: you around?
17:00:06  <indutny>we need to do a patch release of libuv
17:01:15  <indutny>tjfontaine: does it work this way?
17:01:43  <tjfontaine>nathan7: yup
17:01:47  <tjfontaine>er indutny yuup
17:01:50  <indutny>ook
17:05:40  <nathan7>I was really confused for a moment there
17:05:45  <tjfontaine>:)
17:06:27  <tjfontaine>open request -- we need a test that builds node installs and then attempts to use npm
17:07:31  <indutny>pushing PR
17:07:48  <indutny>we hadn't caught this because of the stack memory initialization :)
17:07:51  <indutny>luckily it was mostly zeroes
17:08:10  <indutny>https://github.com/joyent/libuv/pull/1494
17:08:13  <indutny>cc tjfontaine ^
17:08:20  * janjongboomjoined
17:11:29  * iarnajoined
17:24:51  * iarnaquit (Quit: Leaving...)
17:26:47  * sh1mmerjoined
17:26:54  * avalanche123joined
17:28:35  * avalanche123quit (Remote host closed the connection)
17:29:14  <jgi>tjfontaine: so the zlib test fails when run with the Python tests driver, but doesn’t fail when run standalone
17:29:15  * avalanche123joined
17:29:30  <jgi>tjfontaine: I haven’t had time to know why though, doing that now
17:30:20  * AlexisMochaquit (Ping timeout: 260 seconds)
17:30:25  * Ralithjoined
17:31:48  <tjfontaine>jgi: ok good to know
17:31:53  * sh1mmer_joined
17:33:22  * FROGGSjoined
17:33:29  * rosskjoined
17:34:46  * sh1mmerquit (Ping timeout: 250 seconds)
17:37:16  * iarnajoined
17:37:42  <chrisdickinson>tjfontaine: belated pong!
17:39:23  * qard-appnetapart
17:41:14  <tjfontaine>chrisdickinson: do you have time for a quick call at 11:30?
17:41:21  <chrisdickinson>sure!
17:42:38  <tjfontaine>thanks
17:43:38  * qard-appnetajoined
17:45:10  * bradleymeckquit (Quit: bradleymeck)
17:46:07  * iarnaquit (Quit: Leaving...)
17:52:52  <indutny>saghul: can we do a release with it?
17:53:22  <MI6>joyent/libuv: Fedor Indutny v1.x * 2f54947 : fs: fix readdir on empty directory - http://git.io/0k49MA
17:53:44  * FROGGSpart ("Verlassend")
17:54:05  * sh1mmer_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:57:44  * inolenjoined
17:58:39  * iarnajoined
17:58:49  * AlexisMochajoined
18:02:28  <tjfontaine>jgi: how is it going?
18:02:29  * bradleymeckjoined
18:02:51  <jgi>tjfontaine: still trying to find a minimal repro
18:04:55  * sh1mmerjoined
18:05:48  * iarnaquit (Quit: Leaving...)
18:07:20  <tjfontaine>jgi: lemme know if I can help
18:07:27  <jgi>tjfontaine: sure thank you!
18:17:30  * yunongjoined
18:19:07  * thlorenzquit (Remote host closed the connection)
18:19:43  * thlorenzjoined
18:21:12  * thlorenz_joined
18:21:12  * thlorenzquit (Read error: Connection reset by peer)
18:25:41  * bradleymeckquit (Quit: bradleymeck)
18:33:35  <tjfontaine>chrisdickinson: free for hangouts?
18:33:39  <chrisdickinson>yep!
18:33:54  <tjfontaine>ok relocating
18:36:58  * rosskquit (Ping timeout: 244 seconds)
18:38:28  * rosskjoined
18:43:00  <tjfontaine>chrisdickinson: bah -- google hangouts says it can't connect to server
18:43:05  <chrisdickinson>wuh oh
18:43:23  <tjfontaine>skype as a fallback?
18:43:26  <chrisdickinson>sure
18:43:41  * tjfontaine@ skype
18:44:26  <chrisdickinson>contact request sent!
18:46:01  <othiym23>tjfontaine: npm is getting *really* good at exposing race conditions
18:46:12  <othiym23>tjfontaine: you saw my blog post, right?
18:46:35  <jgi>tjfontaine: so it seems that redirecting stdout and stderr to files make test-zlib.js fail, still investigating why
18:46:49  <othiym23>there's at least one outstanding issue that is yet another race condition deep in the bowels of npm or one of its dependencies that is incredibly hard to replicate
18:47:46  * chris_99quit (Ping timeout: 272 seconds)
18:50:43  * mikealquit (Quit: Leaving.)
18:53:38  * abraxasjoined
18:58:09  * abraxasquit (Ping timeout: 260 seconds)
19:05:48  * rendarquit (Ping timeout: 246 seconds)
19:06:01  * chris_99joined
19:07:46  * yunong_joined
19:08:36  * yunong_quit (Read error: Connection reset by peer)
19:08:51  * yunong_joined
19:09:13  * yunong_quit (Read error: Connection reset by peer)
19:09:32  * yunong_joined
19:09:37  * yunong_quit (Remote host closed the connection)
19:11:31  * yunongquit (Ping timeout: 272 seconds)
19:12:09  * rendarjoined
19:12:49  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:13:12  <jgi>tjfontaine: it seems that this line: https://github.com/joyent/node/blob/v0.12/lib/buffer.js#L69 from this PR: https://github.com/joyent/node/pull/8407 broke the zlib test. I don’t understand why. I can reproduce the issue (and fix it by removing the change) reliably only on SmartOS though. So I’m going to setup a Jenkins job that pulls a branch cut from v0.12 from my personal repo, run the tests on all platforms, make sure the zlib test fails, then apply th
19:13:12  <jgi>“fix”, and make sure the zlib test succeeds.
19:17:25  * yunongjoined
19:19:17  * yunongquit (Remote host closed the connection)
19:19:40  * Damaris_Zulaufjoined
19:19:53  * yunongjoined
19:21:22  * mikealjoined
19:21:46  * sh1mmerjoined
19:24:49  * yunongquit (Ping timeout: 272 seconds)
19:25:18  * chris_99quit (Remote host closed the connection)
19:25:35  <indutny>saghul: release time? :)
19:25:38  * Damaris_Zulaufquit (Remote host closed the connection)
19:26:04  * jcrugzz__changed nick to jcrugzz
19:28:07  * iarnajoined
19:29:27  * stagasjoined
19:33:32  * yunongjoined
19:34:23  * yunongquit (Remote host closed the connection)
19:35:00  * yunongjoined
19:39:27  * yunongquit (Read error: Connection reset by peer)
19:39:33  * yunongjoined
19:41:36  * avalanche123quit (Remote host closed the connection)
19:42:05  * yunongquit (Remote host closed the connection)
19:42:31  * avalanche123joined
19:42:39  * yunongjoined
19:43:28  * rendarquit
19:45:46  * yunong_joined
19:45:49  * yunong_quit (Remote host closed the connection)
19:45:54  * yunongquit (Read error: Connection reset by peer)
19:46:25  * yunongjoined
19:47:10  * thlorenz_quit (Remote host closed the connection)
19:47:45  * thlorenzjoined
19:47:53  * yunongquit (Read error: Connection reset by peer)
19:48:12  * yunongjoined
19:49:14  * thlorenz_joined
19:49:21  * yunongquit (Remote host closed the connection)
19:49:53  * yunongjoined
19:52:09  * thlorenzquit (Ping timeout: 258 seconds)
19:54:02  * yunongquit (Ping timeout: 245 seconds)
19:56:34  * yunongjoined
19:58:07  * yunongquit (Remote host closed the connection)
19:58:40  * yunongjoined
19:59:03  <tjfontaine>jgi: sounds like a gc issue, dangerous
19:59:12  <jgi>tjfontaine: actually
19:59:32  <jgi>tjfontaine: I think we just need to update this test: https://github.com/joyent/node/blob/v0.12/lib/buffer.js#L448 to isNullOrUndefined :)
19:59:48  <jgi>tjfontaine: since we explicitely initialize the parent to null now
20:00:01  <jgi>tjfontaine: testing it on all platforms right now
20:00:03  <tjfontaine>othiym23: I had heard about it, but haven't checked it out yet -- but I know how gratifying and frustrating it can be spending weeks on end on a very small and hard to catch bug
20:00:32  <tjfontaine>jgi: ah, that could very well be, do you have a smaller test case?
20:01:08  <tjfontaine>I mean it's pretty straight forward, but frustrating that the existing test suite didn't catch that in the slice path
20:01:09  <jgi>tjfontaine: yes: node test/simple/test-zlib.js 1>/tmp/foo 2>/tmp/foo-err
20:01:19  <tjfontaine>no, I mean one that uses only the buffer api
20:01:32  <jgi>tjfontaine: no, not yet
20:02:51  * yunongquit (Ping timeout: 246 seconds)
20:02:53  <tjfontaine>I'm not sure I necessarily agree with this implementation in general, my preference would be that a slice's parent isn't the global native parent, but instead always be the current object being sliced -- but whatever
20:04:24  * brsonquit (Ping timeout: 272 seconds)
20:05:14  * yunongjoined
20:05:38  * brsonjoined
20:06:58  <trevnorris>tjfontaine: +1
20:08:18  * yunongquit (Remote host closed the connection)
20:08:21  <tjfontaine>I don't know who or what that breaks, but it makes walking the graph slightly more sane
20:08:51  * yunongjoined
20:09:03  * lanceballchanged nick to lance|afk
20:09:20  <trevnorris>tjfontaine: adding the two others to the project
20:09:26  <tjfontaine>oh ok
20:13:13  * yunongquit (Ping timeout: 245 seconds)
20:14:40  * yunongjoined
20:18:14  <saghul>indutny: pang
20:18:17  <indutny>pong
20:18:20  <indutny>release time? :)
20:18:21  <indutny>haha
20:18:28  <indutny>tjfontaine: you still around?
20:18:49  <saghul>indutny: gutta fix the release tool before hand, and I;m finishing up some migration docs, ming floating the patch?
20:19:16  <indutny>yeah, sounds reasonable then
20:19:18  <a_le>if I want to use getnameinfo for debugging purposes, can I use the regular one, with NI_NUMERICHOST and NUMERICSERV? I am assuming that thanks to those flags it would never block...
20:20:41  <saghul>a_le: yeah, it shouldn't
20:20:55  <a_le>saghul: thanks :)
20:20:57  <tjfontaine>indutny: I'm here
20:21:01  <indutny>tjfontaine: kewl
20:21:04  <indutny>going to float a commit
20:21:08  <indutny>with a libuv fi
20:21:09  <indutny>fix*
20:21:12  <tjfontaine>that seems sad :/
20:21:17  <indutny>mind doing release after that?
20:21:24  <a_le>i am wondering why i get a connection refused to my own listening socket in my test... it used to work... then i ported everything to C++ and it broke
20:21:26  <indutny>tjfontaine: we are on tight schedule :P
20:21:30  <tjfontaine>I can yes
20:21:34  <indutny>ok, great
20:21:42  <a_le>so first thing i'll check that i am not resolving IPv6 while listening on IPv4...
20:21:44  <indutny>fininishing running tests
20:21:49  <indutny>and pushing the commit right after it
20:22:16  <tjfontaine>I still want to do the zlib fix as well -- then we'll be doing a 0.11 release with green builds
20:22:39  <indutny>oh well
20:22:45  <indutny>let's do v0.11 anyway
20:22:51  <indutny>just don't call it RC
20:23:09  <tjfontaine>ok
20:23:12  <indutny>thank you
20:23:19  <MI6>joyent/node: Fedor Indutny v0.12 * 7fd35e6 : uv: apply floating patch 2f54947b - http://git.io/3T38Xg
20:23:22  <indutny>here we go
20:23:29  <indutny>hrm
20:23:34  <indutny>it should have been `deps: ...`
20:23:37  <indutny>nah, whatever
20:24:05  <indutny>tty tomorrow morning
20:24:18  <indutny>I'd be really happy if I'd see a release :D
20:24:25  <indutny>no rush, though
20:24:30  <indutny>:)
20:24:30  <indutny>thank you
20:25:06  <a_le>so is 0.12 next or as I heard, 1.0?
20:25:19  <saghul>nope
20:25:26  <saghul>ups, wrong window!
20:25:54  <tjfontaine>1.0 means somethign special, I'm not sure we can live up to that yet
20:26:05  <tjfontaine>brb
20:30:38  * stagasquit (Ping timeout: 244 seconds)
20:33:54  <a_le>tjfontaine: it's just a few days ago a colleague of mine was saying he saw a 1.0.0-rcSOMETHING coming out... maybe he was delirious...
20:34:05  <tjfontaine>that's libuv
20:34:09  <saghul>a_le: maybe he meant libuv?
20:34:15  <tjfontaine>which is free to move its api in its own direction
20:34:22  <tjfontaine>but different from what node.js has to commit to
20:34:29  <a_le>this is the #libuv channel, right?
20:34:44  <qard-appneta>tjfontaine: Any news on the tracing front? I've been out of the loop for a bit, focused on getting our node support out.
20:34:50  <saghul>but we're all friends here :-)
20:35:04  <tjfontaine>a_le: yes but technically libuv's primary consumer is node.js so most fo the node development happens here
20:35:05  <a_le>so my question was about libuv... is it true that 1.0 is coming out?
20:35:26  <tjfontaine>qard-appneta: progressing, soon after the 0.12 release I'm hoping we can do some better bike shedding
20:35:32  <saghul>a_le: yes
20:35:50  <a_le>btw, can i call uv_getnameinfo and hope it invokes my callback before it returns, if I have the flags that ask for numeric hostname and numeric service?
20:36:08  <tjfontaine>invokes my callback before it returns?
20:36:16  <KennethWilke>regarding the creation of a new project using libuv, what version would be recommended?
20:36:18  * c4milojoined
20:36:19  <tjfontaine>that is a dangerous contract to have and reason about
20:36:24  <qard-appneta>Cool. Our code is open now, and I'll be getting onto longer-running projects soon. :)
20:36:27  <tjfontaine>KennethWilke: the current master
20:36:35  <saghul>a_le: if you pass a callback, it will always be called asynchropnously
20:36:35  <tjfontaine>qard-appneta: excellent work :)
20:36:41  <a_le>tjfontaine: what would be dangerous about that?
20:36:52  <KennethWilke>i was trying to roll with the 1.0.0-rc1 tarball so far
20:37:04  <tjfontaine>a_le: the cb needs to be invoked on the next loop iteration, such that you can process all your events logically
20:37:05  <a_le>by the time i call uv_getnameinfo, i should have everything ready to receive its callback
20:37:09  <qard-appneta>I anyone wants to poke around: https://github.com/appneta/node-traceview
20:37:15  <a_le>tjfontaine: i see...
20:37:17  <saghul>a_le: you can pass NULL as the callback and it will run in "blocking" mode, but with thoise flags it shouldn't block anyway
20:37:35  <a_le>sigh, but i didn't want to waste space/allocations for yet another request handler
20:37:47  <saghul>youc an allocate it on stack
20:37:51  <a_le>saghul: I am glad I asked this stupid question
20:37:59  <saghul>what's wrong with my typing tonight?!
20:38:02  <a_le>saghul: when my function returns, it would be gone...
20:38:17  <saghul>no if you pass NULL as a callback
20:38:18  <a_le>saghul: this NULL trick works for everything?
20:38:25  <a_le>oh!
20:38:29  <a_le>NULL for the callback
20:38:33  <a_le>not NULL for the request
20:38:36  <a_le>I see
20:38:43  <a_le>does it work for everything?
20:38:48  <saghul>a_le: no, for uv_fs_*, uv_getnameinfo and uv_getaddrinfo
20:39:15  <a_le>so the request handle still needs the be passed even if the callback is NULL
20:39:29  <saghul>yes, we attach stuff to it
20:39:35  <a_le>but if the callback is NULL, how do I handle the results?
20:39:46  <a_le>oh from the stuff you attach to the handle?
20:39:52  <saghul>yep
20:39:57  <a_le>where can I find documentation and/or examples about this?
20:40:35  <saghul>a_le: http://docs.libuv.org/en/latest/dns.html
20:40:54  <saghul>damn, looks like we're missing some struct fields docs there :-(
20:41:04  <KennethWilke>:O
20:41:25  <KennethWilke>i've not seen that before, i think that should be in the github readme
20:41:40  <KennethWilke>i found links to examples for old library versions, but that is a very useful link to have
20:41:46  <saghul>KennethWilke: it is, in the v1.x branch
20:41:53  * c4miloquit (Read error: Connection reset by peer)
20:41:57  <saghul>we'll merge into master soon
20:41:59  <KennethWilke>doh!
20:42:02  <KennethWilke>my bad :p
20:42:08  <saghul>no worries!
20:42:09  <tjfontaine>saghul: why dont' you merge more regularly?
20:42:14  * c4milojoined
20:42:24  <saghul>tjfontaine: I wanted to get rc1 out first
20:42:38  <saghul>actually, I'll do that tomorrow
20:42:40  <tjfontaine>chrisdickinson: hey -- can you look at the test failure for test-crypto-domains on 0.12
20:42:42  <saghul>there is no reason not to
20:42:52  <tjfontaine>ya, there's really no reason not to be merging regularly
20:42:57  <tjfontaine>in my esetimation
20:43:01  <tjfontaine>*estimation
20:43:04  <chrisdickinson>sure
20:43:13  <tjfontaine>chrisdickinson: tahnks
20:43:13  <KennethWilke>as long as master is the stable branch
20:43:14  <tjfontaine>*thanks
20:43:17  <a_le>saghul: shall I look at the source code? :D
20:43:20  <tjfontaine>saghul: your typo problems are contagious
20:43:48  <saghul>a_le: sorry man, looks like I lied :-( uv_getaddr|nameinfo allways run async
20:43:59  <saghul>only uv_fs_* accept NULL as a callback
20:44:04  <saghul>tjfontaine: haha
20:44:20  <a_le>saghul: and for me to send a patch I should also fix it for windows?
20:44:26  <tjfontaine>if you want sync versions of those I would advocate using their real counterparts
20:44:40  <a_le>tjfontaine: I see
20:44:57  <saghul>yeah
20:45:02  <tjfontaine>because you're losing a lot of the value in using an abstraction layer
20:45:12  <tjfontaine>especially when those functions are very portable
20:45:24  <a_le>tjfontaine: portability?
20:45:27  <a_le>ok
20:45:34  <tjfontaine>on Vista+ anyway
20:45:42  <tjfontaine>Vista+ is converging on posxi
20:46:04  <saghul>don't look at src/win/getaddrinfo.c though ;-)
20:46:19  <saghul>but yeah, Vista+ is not that painful
20:47:11  <jgi>tjfontaine: https://github.com/misterdjules/node/commit/ca0caaad244e4e5f183f59e1169566daf89fce73 fixes the zlib issue, tests results here: http://jenkins.nodejs.org/job/zlib-repro/3/
20:47:29  <trevnorris>othiym23: the oversight on setting .parent = null; was stupid on my part. i'll be fixing it soon.
20:47:41  <KennethWilke>pardon if this is a silly question, but why is it lib 'uv'?
20:47:47  <tjfontaine>jgi: it's either that or set it to undefined in the constructor
20:47:53  <tjfontaine>don't forget a test case
20:47:55  <KennethWilke>just curious what's behind that name!
20:48:06  <tjfontaine>whomever ends up doing the work
20:48:21  <saghul>KennethWilke: unicorn velociraptor, of course
20:48:31  <KennethWilke>lol
20:48:42  <saghul>magical and fast, what's there not to like? :-)
20:48:51  <tjfontaine>[also, don't forget to run the testsuite before pushing code to the repo]
20:48:57  <KennethWilke>i haven't found the what not to like bit yet :O
20:49:21  <jgi>tjfontaine: would setting parent to undefined enable the optimization that the original commit introduced?
20:49:40  <tjfontaine>jgi: yes, I believe the issue was setting it on the prototype vs in the constructor function
20:49:48  <tjfontaine>not which sentinel was used
20:50:03  <jgi>tjfontaine: ok
20:50:26  * lance|afkchanged nick to lanceball
20:50:38  <KennethWilke>saghul, that reminds me of a comment i've seen in a tool referring to a complex postgres query as a uzi packing raptor
20:50:51  <KennethWilke>nobody wanted to get near it
20:50:53  <jgi>trevnorris: sorry, I didn’t see that you were working on that too
20:51:18  <saghul>KennethWilke: LoL
20:52:51  * AlexisMochaquit (Ping timeout: 244 seconds)
20:53:07  <a_le>does libuv have some magic for creating thread local static variables within a function?
20:53:25  <a_le>(a la C++11 thread_local)
20:53:34  * danlovesproofsjoined
20:57:49  <chrisdickinson>tjfontaine: where are you seeing crypto-domains fail?
20:58:06  <tjfontaine>locally on my mac and in the test suite, when run with the python test runner
20:58:44  * yunong_joined
20:59:01  * thlorenz_quit (Remote host closed the connection)
20:59:36  <chrisdickinson>ah cool, was missing the python test runner step!
20:59:41  <tjfontaine>nod
21:00:17  <tjfontaine>it could be the same buffer bug
21:01:57  <othiym23>trevnorris: setting which .parent to null? I'm lacking context :D
21:02:21  * yunongquit (Ping timeout: 272 seconds)
21:02:38  <tjfontaine>othiym23: think it was a typo, but there was a regression in the recent PR he landed that optimized the buffer constructor
21:02:52  <othiym23>aha, got it
21:02:52  * yunong_quit (Ping timeout: 240 seconds)
21:03:23  * yunongjoined
21:03:32  <chrisdickinson>huh, weird, not failing locally on v0.12/7fd35e6 on osx
21:03:46  * thlorenz_joined
21:04:05  * yunongquit (Remote host closed the connection)
21:04:43  <tjfontaine>chrisdickinson: it's racey
21:04:49  <tjfontaine>happend on my 4th try through
21:05:04  <trevnorris>othiym23: in Buffer#slice() it checks isUndefined(this.parent), but since parent === null that will always fail.
21:05:06  <tjfontaine>chrisdickinson: https://gist.github.com/tjfontaine/6274aa0aad372f6e6ba7
21:06:59  <jgi>trevnorris, othiym23: if you’re working on the zlib regression, or on the buffer.slice() issue, please let me know so that we don’t duplicate work :)
21:07:32  <trevnorris>jgi: i'm not sure if the issue is related to zlib, but this is an issue that i'm working on.
21:07:47  <chrisdickinson>probably not good to have `test-crypto-domain{s,}.js` :|
21:08:07  <trevnorris>the simple fix is very simple, but i'm trying to kill two birds with one stone on this.
21:08:09  <tjfontaine>chrisdickinson: it's ok, I like them being in different files, I thinkt he order of the names is slightlyweird
21:08:15  <jgi>trevnorris: it is related to test/simple/test-zlib.js failing sometimes
21:08:18  * c4miloquit (Read error: Connection reset by peer)
21:08:22  <trevnorris>okay.
21:09:10  <jgi>trevnorris: right, and you know much more about Buffers than I do. I just want to make sure someone takes care of it If I stop working on it.
21:09:32  <trevnorris>jgi: yeah, I'll take care of this. Thanks for brining it to my attention.
21:09:59  <jgi>trevnorris: no problem, thank you
21:11:03  <othiym23>actually, right now I'm making sure that npm 2.0.2 works acceptably on node 0.8
21:11:35  <othiym23>next is looking at master / 0.11 (preferably *after* you guys get the current issues sorted out ;)
21:12:15  <chrisdickinson>ah-ha reproduced
21:12:37  * yunongjoined
21:13:50  <tjfontaine>othiym23: well 0.12 branch, which should be working atm
21:13:59  <tjfontaine>save this buffer issue and whatever the domains+crypto thing is
21:15:19  <othiym23>0.11.13 appears to be working without issue on npm master
21:15:25  <othiym23>tjfontaine: how are you testing npm?
21:16:33  <othiym23>(the most complete test suite is `npm run-script test-all`, which I wouldn't point out except I didn't know about it until I'd been working here a few months)
21:17:26  <tjfontaine>tools/upgrade-npm.sh [not checked in] && configure --prefix=./buildPrefix/ && make && rm -rf buildPrefix tmp && make install && mkdir tmp && PATH=../buildPrefix/bin:$PATH npm install hapi
21:18:02  <tjfontaine>we have this rule in our Makefile
21:18:02  <tjfontaine>test-npm: node
21:18:03  <tjfontaine> ./node deps/npm/test/run.js
21:18:21  <tjfontaine>also
21:18:21  <tjfontaine>test-npm-publish: node
21:18:22  <tjfontaine> npm_package_config_publishtest=true ./node deps/npm/test/run.js
21:18:35  <tjfontaine>if those aren't up to date, let me know
21:18:49  * no9quit (Quit: Number 9 has gone to bake an aphid)
21:20:48  <othiym23>tjfontaine: that only gets the legacy tests; you probably want `npm --prefix=deps/npm run-script test-all` or something like that
21:21:20  <othiym23>most of the new tests go into test/tap, which gets its tests run by `npm run-script test-all` run from within the npm directory
21:22:05  <tjfontaine>will that work with ./node deps/npm/bin/npm?
21:24:06  * yunongquit (Remote host closed the connection)
21:24:19  <tjfontaine>chrisdickinson: i'm seeing that test fail at times on 0.10 as well
21:24:32  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:24:43  * yunongjoined
21:25:31  <tjfontaine>chrisdickinson: I'm actually not going to hold the release up on this failure, since it's happening in 0.10, and seems to be likely some other domains bug
21:25:51  <creationix>I think I found a bug in libuv 1.x branch
21:26:11  <tjfontaine>creationix: what's up?
21:26:22  <creationix>if I reference uv_idle_start anywhere in my C code (not even calling it), then uv_walk gives invalid pointers for my timer handles
21:27:16  <tjfontaine>that sounds suspect
21:27:27  <tjfontaine>like other memory corruption is getting you
21:27:34  <creationix>but my prepare and check handles are walking correctly
21:27:57  <creationix>where should I look for memory corruption?
21:28:11  <chrisdickinson>that crypto domains bug is a bizarre bug, though
21:28:13  <tjfontaine>do you have a small test case?
21:28:15  <creationix>this is linux btw
21:28:17  <tjfontaine>chrisdickinson: definitely
21:28:27  <creationix>tjfontaine: not super small yet, but I could try creating one
21:28:41  <tjfontaine>chrisdickinson: would seem like we some how do *not* have an active domain set when this is called
21:28:53  <tjfontaine>chrisdickinson: or some how later becomes invalid
21:29:05  <creationix>tjfontaine: here is the lua code that gets the invalid handle on walk https://github.com/luvit/luv/blob/uv-update-1.0.0/test-loop.lua#L8-L11
21:29:17  * yunongquit (Ping timeout: 260 seconds)
21:29:28  * yunongjoined
21:29:30  * yunongquit (Remote host closed the connection)
21:29:48  <tjfontaine>creationix: what's the backtrace look like in gdb?
21:30:03  * yunongjoined
21:30:20  <creationix>tjfontaine: there is no crash, but I guess I could manually set a breakpoint on walk’s callback
21:30:42  <tjfontaine>it's always wrong or just becomes wrong?
21:31:01  <tjfontaine>seems liek you should be able to know before and after which pointer you should be starting at
21:31:55  <a_le>FML... Mac OS X only returns IPv6 entries for localhost, even if 127.0.0.1 is in /etc/hosts... I wasted so much time thinking I had introduced a bug in my code...
21:32:15  * sh1mmerjoined
21:32:49  <othiym23>tjfontaine: yes, it should: ./node deps/npm/bin/npm-cli.js --prefix=deps/npm run-script test-all
21:33:11  <othiym23>tjfontaine: I will test and make sure (there probably also needs to be an install step in there)
21:33:34  <tjfontaine>othiym23: mind submitting a PR to v0.10 branch that updates our Makefile to do that?
21:33:44  <tjfontaine>othiym23: can I convince it to output tap as well?
21:34:22  <creationix>tjfontaine: hmm, manually looking at the handle pointer, it looks correct. I guess the bug is in luajit (or how I’m using it)
21:34:24  * yunongquit (Ping timeout: 250 seconds)
21:34:29  <tjfontaine>creationix: ok
21:34:46  <othiym23>tjfontaine: the legacy tests will probably never emit anything except quasi-tap (like they do now)
21:35:00  <creationix>I’m storing a map of C pointers to lua wrappings so that I can lookup my lua userdatas when libuv gives me just a libuv handle pointer
21:35:03  <tjfontaine>ok tap is not a requirement, it would be nice
21:35:10  <othiym23>tjfontaine: the new tests are written with node-tap, so of course they put out real tap
21:35:21  <tjfontaine>othiym23: I'm ok with only caring about the new tests
21:35:28  <tjfontaine>[if you are]
21:35:44  * sh1mmerquit (Client Quit)
21:36:13  <othiym23>tjfontaine: the legacy tests are pretty important for catching weird edge cases, but their strategy for dealing with test failures is to immediately halt and catch fire, which "works" for soe definition of working
21:37:18  * a_lequit
21:37:24  <tjfontaine>othiym23: well I only want to break our tests if we are reasonably sure that we can identify what actually is failing and how to reproduce it -- if we can't reliably do this for old tests I'm not sure it makes sense for us to test them during our integration testing
21:38:00  <othiym23>I'm putting together a PR now
21:38:05  <tjfontaine>thanks
21:40:03  * sh1mmerjoined
21:41:55  * a_lejoined
21:42:53  * sh1mmerquit (Client Quit)
21:42:58  * thlorenz_changed nick to thlorenz
21:44:26  <creationix>tjfontaine: found it, The extra entry in my function table gave just enough GC pressure to trigger a ref bug in my code
21:44:50  <creationix>so lua was letting my userdata go which prevented me from looking it up in the weakmap table
21:44:59  <tjfontaine>right that sounds more like what I was expecting to hear
21:45:38  * sh1mmerjoined
21:47:08  * sh1mmerquit (Client Quit)
21:47:25  * sh1mmerjoined
21:54:40  <jgi>tjfontaine, othiym23: FWIW, i also added npm to the list of apps tested by this Jenkins job: http://jenkins.nodejs.org/job/nodejs-v012-apps/
21:54:54  * yunongjoined
21:56:13  * yunongquit (Remote host closed the connection)
21:56:46  * yunongjoined
22:01:20  * yunongquit (Ping timeout: 258 seconds)
22:05:20  <KennethWilke>after i init a uv_tcp_t, whats the proper way to close and free it?
22:10:22  * brsonquit (Ping timeout: 272 seconds)
22:11:41  * brsonjoined
22:13:43  <KennethWilke>nvm, gotta run, have a good'n!
22:13:47  * KennethWilkequit (Quit: Leaving)
22:15:40  * rmgjoined
22:15:54  * jordan1changed nick to blissdev
22:19:00  * thlorenzquit (Remote host closed the connection)
22:19:00  * rosskquit
22:19:02  * mikeal_joined
22:19:34  * thlorenzjoined
22:19:54  * mikeal_quit (Client Quit)
22:19:57  * mikealquit (Quit: Leaving.)
22:20:22  * mikealjoined
22:23:48  * thlorenzquit (Ping timeout: 250 seconds)
22:24:33  * iarnaquit (Read error: Connection reset by peer)
22:25:02  * iarnajoined
22:26:12  * cjihrigquit (Quit: Leaving.)
22:26:39  <othiym23>my latest build is from 7fd35e6ea43ece7ef40d50820a80d798eceaa362 and it appears to be suuuper busted wrt reading files
22:26:46  * sblomjoined
22:28:18  <othiym23>tjfontaine: https://gist.github.com/othiym23/4948d3fcc0cdce19534b is what I have so far, I'm going to try applying that against v0.10 and see how it goes
22:32:20  <tjfontaine>othiym23: hmm, no way to do this using the binary explicitly?
22:37:00  <othiym23>tjfontaine: not easily, no
22:37:20  <tjfontaine>does it have to do with detecting the installed path of the binary?
22:39:50  <othiym23>I thought it was going to be cleaner with the Makefile, but that actually does not appear to be the case
22:39:56  <othiym23>I was led astray by isaacs
22:39:58  <othiym23>hold on a sec
22:57:00  * cjihrigjoined
22:58:20  * danlovesproofsquit (Quit: lel sleep yolo)
23:00:05  * danlovesproofsjoined
23:03:00  * iarnaquit (Read error: Connection reset by peer)
23:03:28  * iarnajoined
23:04:05  * cjihrigquit (Ping timeout: 260 seconds)
23:04:44  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:06:54  * sh1mmerjoined
23:08:00  * seishunquit (Ping timeout: 246 seconds)
23:31:48  * cjihrigjoined
23:33:37  * rosskjoined
23:34:04  * danlovesproofsquit (Quit: lel quit yolo)
23:35:31  * Ashlee_Ziemejoined
23:36:07  * cjihrigquit (Ping timeout: 244 seconds)
23:39:54  * avalanche123quit (Remote host closed the connection)
23:42:50  * avalanche123joined
23:45:22  * Ashlee_Ziemequit (Ping timeout: 272 seconds)
23:47:12  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:53:38  * sh1mmerjoined
23:57:07  * sh1mmerquit (Client Quit)
23:57:56  * cjihrigjoined
23:59:22  * sh1mmerjoined