00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:01:41  * winterMa_quit (Remote host closed the connection)
00:08:18  * hzjoined
00:11:45  * bradleymeckquit (Quit: bradleymeck)
00:18:46  * TooTallNatequit (Quit: Computer has gone to sleep.)
00:24:11  * paulfryzeljoined
00:28:29  * paulfryzelquit (Ping timeout: 240 seconds)
00:32:51  * zz_karupanerurachanged nick to karupanerura
00:38:36  <trevnorris>tjfontaine: ping
00:39:57  * dshaw_quit (Read error: Connection reset by peer)
00:42:43  * dshaw_joined
00:45:24  <tjfontaine>trevnorris: pong
00:46:36  <trevnorris>tjfontaine: just fyi, i'm seeing some funny perf behavior if I do an net.connect() then use the returned fd in fs.writeSync(). it's an order of magnitude faster in some cases.
00:47:15  <trevnorris>anyways. the AL patch is about ready, and anyone can start reviewing it whenever. anything you need reviewed?
00:47:32  <tjfontaine>can you be more specific?
00:48:00  <tjfontaine>I'm not really surprised that it is faster because it's a direct write() call, but potentially blocking
00:48:20  <tjfontaine>so on localhost it's probably always fine
00:51:18  * daviddiasquit (Remote host closed the connection)
00:52:44  * daviddia_joined
00:52:45  <trevnorris>the strange thing i'm seeing is that the server is receiving a single large chunk, instead of a bunch of little chunks. ah, that's probably because i've blocked receiving anything until 64KB has been written.
00:54:06  * dshaw_quit (Quit: Leaving.)
00:54:51  <tjfontaine>keep in mind that writeSync() on an fd that is not currently writable could result in uber blocking
00:56:21  * qardquit (Remote host closed the connection)
00:57:54  * brsonquit (Read error: Operation timed out)
01:00:01  <trevnorris>heh, true. will it eventually error and return?
01:00:53  <tjfontaine>well it would EAGAIN generally, but in a writeSync case you're going to get that as an exception
01:00:57  <tjfontaine>or EWOULDBLOCK
01:01:12  * hzquit
01:02:08  * abraxasjoined
01:02:30  <MI6>joyent/node: Timothy J Fontaine master * e2fcfea : src: update from uv_read2_start removal (+2 more commits) - http://git.io/6Xn6rg
01:06:41  * abraxasquit (Ping timeout: 244 seconds)
01:10:25  * kpdeckerquit (Quit: Leaving.)
01:12:18  <MI6>joyent/node: Bryan Cantrill merge-review * 206e814 : mdb_v8: update to latest version (+33 more commits) - http://git.io/2xwmZQ
01:18:23  * daviddia_quit (Remote host closed the connection)
01:18:59  * daviddiasjoined
01:20:54  * daviddia_joined
01:22:33  * inolenquit (Quit: Leaving.)
01:23:17  * inolenjoined
01:23:33  * daviddiasquit (Ping timeout: 264 seconds)
01:23:59  * inolenquit (Read error: No route to host)
01:24:15  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
01:24:18  * inolenjoined
01:24:42  * dshaw_joined
01:24:59  * benviequit (Ping timeout: 240 seconds)
01:25:04  * paulfryzeljoined
01:25:27  * daviddia_quit (Ping timeout: 252 seconds)
01:26:31  * dshaw_1joined
01:28:29  * m76quit (Read error: Connection reset by peer)
01:29:13  * dshaw_quit (Ping timeout: 265 seconds)
01:29:21  * paulfryzelquit (Read error: Connection reset by peer)
01:29:41  * paulfryzeljoined
01:30:57  * dshaw_1quit (Ping timeout: 252 seconds)
01:33:59  * paulfryzelquit (Ping timeout: 240 seconds)
01:34:01  * dap_quit (Quit: Leaving.)
01:38:17  * seldoquit (Remote host closed the connection)
01:38:27  * AvianFlujoined
01:39:56  <MI6>joyent/node: Timothy J Fontaine merge-review * 16a907a : test: mdb test load the version we compile - http://git.io/N4GlzQ
01:43:25  * abraxasjoined
01:46:26  <trevnorris>tjfontaine: so i'm experimenting on closing connections on errors and seeing if it'll recover memory. but even though i'm destroying the connection on the client and server side, i'm still running out of ports.
01:46:45  <trevnorris>tjfontaine: know of a way around this to force the ports to be immediately available after .destroy() has run?
01:47:20  <tjfontaine>you mean you keep hitting your ephemeral port limit because everything is in TIME_WAIT?
01:50:52  * mikolalysenkojoined
01:54:38  * dshaw_joined
02:02:59  * jmar777joined
02:03:15  * calvinfoquit (Quit: Leaving.)
02:03:35  * kpdeckerjoined
02:05:12  * jmar777quit (Remote host closed the connection)
02:05:28  * dshaw_quit (Ping timeout: 265 seconds)
02:08:24  * dap_joined
02:08:33  * dap_quit (Client Quit)
02:09:19  * rmg_quit (Remote host closed the connection)
02:19:29  * mikolalysenkoquit (Ping timeout: 240 seconds)
02:21:15  * AvianFlu_joined
02:23:24  * AvianFluquit (Disconnected by services)
02:23:30  * AvianFlu_changed nick to AvianFlu
02:24:47  * calvinfojoined
02:29:51  * jmar777joined
02:34:28  * mikolalysenkojoined
02:39:58  * rmgjoined
02:48:29  * rmgquit (Ping timeout: 265 seconds)
02:49:19  * AvianFluquit (Remote host closed the connection)
02:59:52  * euoiajoined
03:00:46  * AvianFlujoined
03:10:50  * bradleymeckjoined
03:21:35  * hueniverse1joined
03:24:25  * hueniversequit (Ping timeout: 240 seconds)
03:35:22  * kpdeckerquit (Quit: Leaving.)
03:35:29  * euoiaquit (Ping timeout: 240 seconds)
03:40:15  * AvianFluquit (Remote host closed the connection)
03:43:09  * benviejoined
03:49:59  * kpdeckerjoined
03:53:35  * xaqquit (Remote host closed the connection)
03:54:44  * jmar777quit (Remote host closed the connection)
04:01:30  * calvinfoquit (Quit: Leaving.)
04:05:38  * mikolalysenkoquit (Ping timeout: 240 seconds)
04:06:35  * mikealjoined
04:13:53  * xaqjoined
04:15:18  * benviequit (Ping timeout: 240 seconds)
04:18:22  * xaqquit (Ping timeout: 244 seconds)
04:22:43  * bradleymeckquit (Quit: Bye)
04:23:32  * bradleymeckjoined
04:29:02  <bradleymeck>been so long since I compiled on windows...
05:02:28  * rmgjoined
05:06:58  * rmgquit (Ping timeout: 240 seconds)
05:08:23  <bradleymeck>how do I pass arguments to configure on windows?
05:18:15  * daviddiasjoined
05:23:23  * calvinfojoined
05:26:58  * daviddiasquit (Read error: No route to host)
05:41:58  <tjfontaine>bradleymeck: not very easily at the moment, I'm going to refactor the build system after we get out of 0.12 hell
05:42:48  * nickleeflyjoined
06:05:24  * calvinfoquit (Quit: Leaving.)
06:10:03  * quijotejoined
06:17:24  <othiym23>trevnorris: if you're stuck in TIME_WAIT after hitting the ephemeral port limit, there's a sysctl to drop the wait time
06:18:35  <othiym23>trevnorris: http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/ has a good overview of the deets for Linux
06:28:00  <bradleymeck>tjfontaine: figured it out
06:28:35  * quijotequit (Quit: quijote)
06:41:35  * calvinfojoined
06:47:23  * m76joined
06:49:58  * bradleymeckquit (Quit: bradleymeck)
06:52:33  * bradleymeckjoined
06:56:39  * calvinfoquit (Read error: Connection reset by peer)
06:58:09  * calvinfojoined
06:59:00  * quijotejoined
07:03:58  * quijotequit (Ping timeout: 240 seconds)
07:20:33  * petka_joined
07:28:00  * calvinfoquit (Quit: Leaving.)
07:31:44  * calvinfojoined
07:38:33  <trevnorris>tjfontaine: yeah. netstat -nap shows they're all in TIME_WAIT even if I .end() and .destroy() the connections.
07:40:59  <indutny>try destroySoon()
07:41:00  <indutny>heya
07:41:10  <indutny>also
07:41:16  <indutny>it may be that other side hasn't shutdown them properly
07:41:22  <indutny>if this is the case
07:41:28  <indutny>there is no way, but sysctl to solve this
07:41:30  <indutny>brb
07:50:59  * janjongboomjoined
07:53:18  * calvinfoquit (Quit: Leaving.)
08:01:14  * quijotejoined
08:01:34  * rendarjoined
08:05:58  * quijotequit (Ping timeout: 240 seconds)
08:11:29  * m76quit (Ping timeout: 252 seconds)
08:31:03  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:33:54  * janjongboomjoined
08:57:46  * janjongboomquit (Ping timeout: 265 seconds)
09:02:42  * quijotejoined
09:05:34  * rmgjoined
09:07:18  * quijotequit (Ping timeout: 240 seconds)
09:09:59  * rmgquit (Ping timeout: 240 seconds)
09:11:06  * hzjoined
09:18:21  * janjongboomjoined
09:29:37  * bajtosjoined
09:36:10  * petka_quit (Quit: Connection closed for inactivity)
09:39:06  * m76joined
09:40:00  <trevnorris>indutny: it worked to set sysctl -w net.ipv4.tcp_fin_timeout=1 and space my requests far enough apart that i wouldn't run out of ports in 1 sec.
09:40:12  <indutny>heh
09:40:23  <indutny>you could also try adding SO_LINGER setsockopt
09:40:30  <indutny>what are you doing anyway?
09:42:14  * janjongboomquit (Ping timeout: 265 seconds)
09:42:28  * paulfryzeljoined
09:42:32  <trevnorris>i'm testing error handling in async listener. I made the modification to the writereq object so the instance doing the write is attached to the object. then in the connection callback i'm writing some data then throwing.
09:42:54  * janjongboomjoined
09:42:55  <trevnorris>indutny: then in the error i'm destroying the socket, and on the server for the on close event i'm also cleaning up
09:43:10  <trevnorris>want to see if there is any memory leaks if I just let that run for a while.
09:43:12  <indutny>oh, I see
09:43:45  <trevnorris>anyways. off to bed. i'm going to let this run overnight and see what happens. night
09:43:47  * trevnorris&
09:43:47  <LOUDBOT>I DESPISE WHO YOU ARE AT A CELLULAR LEVEL
09:44:02  <indutny>:)
09:44:04  <indutny>sleep tight
09:46:29  * paulfryzelquit (Ping timeout: 240 seconds)
10:03:26  * quijotejoined
10:07:44  * guilleiguaranquit (Quit: Connection closed for inactivity)
10:07:58  * quijotequit (Ping timeout: 240 seconds)
10:33:57  * quijotejoined
10:43:13  * paulfryzeljoined
10:47:29  * paulfryzelquit (Ping timeout: 240 seconds)
10:55:03  * quijotequit (Quit: quijote)
10:57:32  * AlexisMochajoined
11:04:36  * bajtosquit (Quit: bajtos)
11:17:37  * abraxasquit (Remote host closed the connection)
11:18:14  * abraxasjoined
11:22:56  * abraxasquit (Ping timeout: 252 seconds)
11:42:02  * bajtosjoined
11:54:11  * quijotejoined
11:58:38  * quijotequit (Ping timeout: 240 seconds)
12:07:51  * rmgjoined
12:13:02  * rmgquit (Ping timeout: 265 seconds)
12:14:11  * daviddiasjoined
12:27:29  * inolenquit (Ping timeout: 240 seconds)
12:32:22  * m76quit (Ping timeout: 265 seconds)
12:40:44  * bajtosquit (Quit: bajtos)
12:52:05  * AvianFlujoined
12:53:34  * m76joined
12:54:59  * quijotejoined
12:57:41  * karupanerurachanged nick to zz_karupanerura
12:59:46  * quijotequit (Ping timeout: 252 seconds)
13:01:04  * txdvquit (Read error: Connection reset by peer)
13:01:18  * txdvjoined
13:03:06  * jmar777joined
13:03:17  * jmar777quit (Remote host closed the connection)
13:18:47  * abraxasjoined
13:23:27  * abraxasquit (Ping timeout: 244 seconds)
13:27:54  * melioidjoined
13:30:17  * euoiajoined
13:34:41  * jmar777joined
13:45:28  * paulfryzeljoined
13:49:29  * paulfryzelquit (Ping timeout: 240 seconds)
13:55:43  * quijotejoined
13:59:58  * quijotequit (Ping timeout: 240 seconds)
14:11:52  * guilleiguaranjoined
14:12:45  * janjongboomquit (Ping timeout: 264 seconds)
14:13:20  * daviddiasquit (Remote host closed the connection)
14:18:51  * daviddiasjoined
14:19:10  * guybrushquit (Excess Flood)
14:19:18  * guybrushjoined
14:21:44  * daviddiasquit (Remote host closed the connection)
14:28:16  * AvianFluquit (Remote host closed the connection)
14:39:26  * bajtosjoined
14:39:58  * bajtosquit (Remote host closed the connection)
14:40:18  * bajtosjoined
14:46:08  * paulfryzeljoined
14:48:39  * inolenjoined
14:49:18  * mikealquit (Quit: Leaving.)
14:56:30  * quijotejoined
15:01:21  * quijotequit (Ping timeout: 252 seconds)
15:10:22  * rmgjoined
15:13:27  * mikolalysenkojoined
15:14:34  * dschatzbergjoined
15:15:04  * rmgquit (Ping timeout: 244 seconds)
15:16:11  <dschatzberg>hi all, trying to understand the semantics of idle watchers, if I have an active idle watcher does this mean the event loop will not block and will repeatedly call my idle handler as long as no other events are found?
15:19:09  <saghul>yes, but also even if there are other events
15:19:40  * abraxasjoined
15:19:41  <dschatzberg>so how is it different from prepare or check?
15:19:42  <saghul>it will be called once per loop iteration, and prevent the loop from blocking for i/o (it will do a 0 timeout poll)
15:19:59  <saghul>prepare and check don't prevent the loop from blocking for i/o
15:20:09  <dschatzberg>I see
15:21:03  <dschatzberg>hmm it seems odd to call it idle when it runs when there are other events
15:22:09  <saghul>the name is kind of a heritage from the libev days
15:22:38  * AvianFlujoined
15:23:27  * AvianFlu_joined
15:23:59  * abraxasquit (Ping timeout: 240 seconds)
15:24:50  <dschatzberg>saghul: looking through the source I don't see how it prevents blocking, In unix/core.c timeout is 0 as long as UV_RUN_NOWAIT is not passed
15:25:24  <saghul>dschatzberg: check uv__backend_timeout
15:25:42  <saghul>it will return 0
15:26:56  * AvianFluquit (Ping timeout: 244 seconds)
15:27:10  <dschatzberg>ah thanks
15:27:27  <saghul>np :-)
15:29:38  * mikolalysenkoquit (Ping timeout: 240 seconds)
15:32:39  * AvianFlu_changed nick to AvianFlu
15:39:31  * quijotejoined
15:39:49  * dschatzbergpart ("Leaving")
15:42:26  * daviddiasjoined
15:42:48  * bradleymeck_joined
15:43:29  * mikolalysenkojoined
16:02:50  * jmar777quit (Read error: Connection reset by peer)
16:03:21  * jmar777joined
16:05:25  <tjfontaine>morning folks
16:13:45  * winterManjoined
16:16:11  * rmgjoined
16:17:44  * bajtosquit (Quit: bajtos)
16:20:49  <tjfontaine>saghul: I thought status was included so we could support cancel notifications?
16:21:05  <saghul>tjfontaine: those will never be cancelled
16:21:14  <saghul>they are started or stopped
16:21:34  <saghul>requests still have their statuses
16:26:31  * quijotequit (Quit: quijote)
16:35:35  * dap_joined
16:38:20  * paulfryzelquit (Remote host closed the connection)
16:38:59  * paulfryzeljoined
16:43:18  * paulfryzelquit (Ping timeout: 240 seconds)
16:48:04  * paulfryzeljoined
16:51:22  * bajtosjoined
16:51:41  * quijotejoined
16:51:49  * calvinfojoined
16:57:38  * mikolalysenkoquit (Ping timeout: 240 seconds)
17:04:13  * rosskjoined
17:07:21  * benviejoined
17:07:37  * sblom_quit (Read error: Connection reset by peer)
17:09:14  * mikealjoined
17:11:01  * Kakerajoined
17:14:31  * kenperkinsjoined
17:16:19  * dap_quit (Quit: Leaving.)
17:18:01  * benviequit (Ping timeout: 244 seconds)
17:18:02  * AlexisMochaquit (Ping timeout: 265 seconds)
17:20:34  * benviejoined
17:20:45  * abraxasjoined
17:20:54  * dap_joined
17:22:07  * benvie_joined
17:22:53  * hz_joined
17:22:57  * hzquit (Disconnected by services)
17:22:58  * hz_changed nick to hz
17:23:50  * calvinfoquit (Ping timeout: 265 seconds)
17:25:02  * benviequit (Ping timeout: 256 seconds)
17:25:30  * abraxasquit (Ping timeout: 252 seconds)
17:28:52  * mikolalysenkojoined
17:31:48  * sblomjoined
17:45:59  * calvinfojoined
17:49:00  * dap_quit (Quit: Leaving.)
17:49:38  * dap_joined
18:03:21  * winterManquit (Quit: Leaving...)
18:06:47  * TooTallNatejoined
18:07:08  * dshaw_joined
18:11:30  * AlexisMochajoined
18:14:15  * TooTallNatequit (Read error: Connection reset by peer)
18:14:36  <AlexisMocha>howdy
18:14:46  * TooTallNatejoined
18:27:14  * brsonjoined
18:28:21  <tjfontaine>heya AlexisMocha
18:29:07  <indutny>hey people
18:29:08  <indutny>how are you?
18:29:23  <tjfontaine>hey fedor, how are you?
18:29:30  <indutny>good
18:29:31  <tjfontaine>I'm about to start the node v0.11 release
18:29:37  <indutny>oh
18:29:38  <tjfontaine>do we want to land 3.24?
18:29:42  <tjfontaine>did they get back to you?
18:29:48  <indutny>yes, but we haven't finished this yet
18:29:51  <tjfontaine>ok
18:29:56  <tjfontaine>we can do another
18:29:58  <indutny>yeah
18:30:03  <indutny>could you please do libuv releases?
18:30:11  <indutny>for both v0.10 and v0.11
18:30:30  <indutny>I have a fix for fs events on osx
18:30:34  <indutny>that got landed in v0.10
18:30:45  <indutny>would be cool to have it in next node release
18:30:50  <indutny>oh
18:30:52  <indutny>you already did ti
18:30:54  <indutny>it
18:31:00  <tjfontaine>:)
18:31:02  <indutny>ok then :P
18:32:26  <AlexisMocha>at the cost of sounding stupid, I am still confused by the release numbers. v0.11 now and v0.12 in a couple of weeks?
18:32:43  <indutny>haha
18:32:49  <indutny>I'm confused too
18:34:25  <AlexisMocha>really? :) I was hoping someone would have an explanation
18:36:09  <indutny>haha
18:36:17  <indutny>odd numbers are unstable releases
18:36:21  <indutny>even numbers are stable
18:36:28  <indutny>eventually v0.11 becomes v0.12
18:36:32  <indutny>and v0.13 is started
18:36:37  <indutny>where all new features are implemented
18:36:43  <indutny>and v0.12 gets only bugfixes since then
18:39:19  * brsonquit (Quit: leaving)
18:39:34  * brsonjoined
18:45:58  <trevnorris>othiym23: thanks for the tip. that solved it for me.
18:46:24  <tjfontaine>you really want to be gracefully shutting down sockets (generally)
18:46:48  <trevnorris>that directed at me?
18:47:24  <tjfontaine>yup, TIME_WAIT generally means the fin/ack sequence wasn't yet finished
18:47:43  <trevnorris>sure. I just wanted to run an accelerated test.
18:47:44  <AlexisMocha>indutny: thank you
18:47:45  <tjfontaine>unless you're trying to see how it's behaving under EMFILE conditions
18:48:32  <trevnorris>basically I just setup an http server and on connection wrote some data then threw. wanted to see if I could recover the resources w/o a leak
18:48:43  <indutny>AlexisMocha: np
18:48:45  <indutny>you are welcome
18:49:06  <trevnorris>took a slight patch to core, but was able to cleanup successfully after 1.5 million thrown connections w/o any sign of memory leak.
18:49:28  <tjfontaine>that's a bold claim
18:50:02  <trevnorris>well, granted it was a very simple script. I sure if I introduced something like express the results would be very different.
18:51:09  <tjfontaine>can you define what you mean as "memory leak"?
18:52:21  * m76quit (Ping timeout: 264 seconds)
18:52:23  <trevnorris>having the destructor not clean up any resources in flight, or unintentional memory (i.e. Buffer) retention
18:54:15  <trevnorris>tjfontaine: here's the test and the diff I needed to add to core: https://gist.github.com/trevnorris/9492508
18:56:05  <tjfontaine>"resources in flight"
18:56:53  <trevnorris>yeah. you do a res.write(<string>) it has to copy out the memory to a char* and attach it to the writereq.
18:57:44  <trevnorris>iirc it bypasses the creation of a buffer in that case, so wanted to make sure that memory would be free'd properly.
18:57:49  <tjfontaine>sure, but that's only one small tiny portion of resources that are bound in node
18:58:10  <tjfontaine>the harder problem is to quantify what that means in terms of connection pooling for database connectors
18:59:19  <trevnorris>that's a totally different problem. all the test was aimed at was if memory usage would continue to grow if I destroyed connections that threw then continued execution as usual.
18:59:21  * quijotequit (Quit: quijote)
18:59:56  <tjfontaine>sure, but that's the problem people actually have a harder time with, and why things like domains exist :/
19:00:21  <trevnorris>baby steps dude. ;)
19:07:18  * daviddiasquit (Remote host closed the connection)
19:09:37  * quijotejoined
19:12:40  * m76joined
19:15:46  * kinibojoined
19:20:26  * qardjoined
19:20:34  * calvinfo1joined
19:21:39  * abraxasjoined
19:22:57  * calvinfoquit (Ping timeout: 264 seconds)
19:24:02  * kiniboquit (Remote host closed the connection)
19:25:59  * abraxasquit (Ping timeout: 240 seconds)
19:30:36  * maiklwrjoined
19:38:53  * octetcloudjoined
19:41:39  * quijotequit (Quit: quijote)
19:42:09  * maiklwrquit (Remote host closed the connection)
19:44:31  * xaqjoined
19:56:00  * octetcloudquit (Quit: WeeChat 0.4.3)
19:58:12  * dshaw_quit (Quit: Leaving.)
20:03:38  * dshaw_joined
20:08:07  * dshaw_quit (Client Quit)
20:09:38  * benvie_quit (Ping timeout: 240 seconds)
20:12:03  * quijotejoined
20:14:46  <bradleymeck_>was there ever any info released on the desires for bundled modules? or still being discussed? kinda running out of things here, windows support on my branch should land tonight, but stil
20:14:57  <bradleymeck_>still* wondering about extracting / binary modules
20:16:52  * quijotequit (Ping timeout: 265 seconds)
20:19:32  * Kakeraquit (Read error: Connection reset by peer)
20:20:04  * Kakerajoined
20:20:20  * jmar777quit (Remote host closed the connection)
20:21:05  * winterManjoined
20:22:14  * winterManpart
20:25:36  * benviejoined
20:25:37  * Kakeraquit (Ping timeout: 240 seconds)
20:27:57  <MI6>joyent/node: Bryan Cantrill master * e496707 : mdb_v8: update to latest version - http://git.io/d4n6rg
20:28:21  * mikolalysenkoquit (Ping timeout: 264 seconds)
20:28:36  * benvie_joined
20:29:52  * dreveljoined
20:30:09  * benviequit (Ping timeout: 264 seconds)
20:31:26  * mikolalysenkojoined
20:42:01  * drevelquit (Remote host closed the connection)
20:45:56  * bajtosquit (Quit: bajtos)
20:50:52  <MI6>joyent/node: tjfontaine created branch v0.11.12-release - http://git.io/K1lyLA
20:52:00  * nrajlichjoined
20:52:03  <isaacs>tjfontaine: 0.11.12-release sounds ominously like it's a 0.12 release
20:52:51  <tjfontaine>next release is 0.11.12.13
20:53:56  <tjfontaine>this may be a false start on the release anyway according to the windows test results
20:54:49  * TooTallNatequit (Ping timeout: 240 seconds)
20:55:34  * eugenewarejoined
20:56:12  * mikealquit (Quit: Leaving.)
20:56:59  * dshaw_joined
21:01:25  <tjfontaine>who wants to see an awesome node/libuv + windows bug?
21:01:29  * dshaw_quit (Ping timeout: 240 seconds)
21:01:33  <tjfontaine>https://www.dropbox.com/s/bj3cvasp3hifgp3/Screenshot%202014-03-11%2013.59.40.png
21:01:37  <tjfontaine>I need to reinstall cloudup
21:02:02  <trevnorris>tjfontaine: wtf is going on there?
21:02:26  <tjfontaine>a null is appended and we're interpreting it directly
21:02:35  <trevnorris>haha. awesome.
21:05:58  <tjfontaine>https://github.com/joyent/libuv/blob/master/src/win/util.c#L184-L193
21:06:09  <tjfontaine>it's likely going to be that which is the offending code
21:06:32  <tjfontaine>AlexisMocha: ping
21:12:31  * brson_joined
21:12:50  * quijotejoined
21:17:39  <tjfontaine>saghul: ping
21:17:46  * quijotequit (Ping timeout: 265 seconds)
21:22:30  * abraxasjoined
21:23:19  * guybrush_joined
21:26:50  * rmgquit (Remote host closed the connection)
21:27:26  * abraxasquit (Ping timeout: 265 seconds)
21:27:57  * KiNgMaRquit (Ping timeout: 245 seconds)
21:27:57  * guybrushquit (Ping timeout: 245 seconds)
21:28:00  * titoquit (Ping timeout: 245 seconds)
21:28:00  * LeftWingquit (Ping timeout: 245 seconds)
21:28:04  * Damn3dquit (Ping timeout: 245 seconds)
21:28:05  * creationixquit (Ping timeout: 245 seconds)
21:28:06  * kuplatupsuquit (Ping timeout: 245 seconds)
21:28:22  * titojoined
21:28:38  * daviddiasjoined
21:28:49  * creationixjoined
21:28:52  * LeftWingjoined
21:29:36  * KiNgMaRjoined
21:32:58  * mikolalysenkoquit (*.net *.split)
21:33:00  * AvianFluquit (*.net *.split)
21:33:01  * euoiaquit (*.net *.split)
21:33:01  * txdvquit (*.net *.split)
21:33:02  * kpdeckerquit (*.net *.split)
21:33:02  * ircretaryquit (*.net *.split)
21:33:04  * sinclair|workquit (*.net *.split)
21:33:05  * parshapquit (*.net *.split)
21:33:05  * prettyrobotsquit (*.net *.split)
21:33:06  * tumdedumquit (*.net *.split)
21:33:07  * MI6quit (*.net *.split)
21:33:07  * jirwinquit (*.net *.split)
21:33:07  * brett19quit (*.net *.split)
21:33:08  * saghulquit (*.net *.split)
21:35:36  <tjfontaine>DAMN YOU NETSPLITS
21:35:37  <LOUDBOT>I LOVE BIG GOVERNMENT. AND SO DO YOU
21:37:59  * daviddiasquit
21:38:01  * ircretaryjoined
21:38:03  * MI6joined
21:38:10  * mikolalysenkojoined
21:38:15  * kpdeckerjoined
21:38:15  * dshaw_joined
21:38:15  * brett19joined
21:38:28  * AvianFlujoined
21:38:28  * jirwinjoined
21:38:34  * parshapjoined
21:38:35  * saghuljoined
21:38:53  * sinclair|workjoined
21:39:03  * eugenewarequit (*.net *.split)
21:39:03  * nrajlichquit (*.net *.split)
21:39:03  * benvie_quit (*.net *.split)
21:39:04  * xaqquit (*.net *.split)
21:39:04  * calvinfo1quit (*.net *.split)
21:39:04  * m76quit (*.net *.split)
21:39:04  * brsonquit (*.net *.split)
21:39:05  * paulfryzelquit (*.net *.split)
21:39:06  * rendarquit (*.net *.split)
21:39:13  * bradleymeck_quit (*.net *.split)
21:39:15  * c0a8quit (*.net *.split)
21:39:15  * Raynosquit (*.net *.split)
21:39:15  * Domenic_quit (*.net *.split)
21:39:16  * wolfeidauquit (*.net *.split)
21:39:17  * SquirrelCZECHquit (*.net *.split)
21:39:17  * dsantiagoquit (*.net *.split)
21:39:23  * `3rdEdenquit (*.net *.split)
21:39:24  * nsmquit (*.net *.split)
21:39:27  <tjfontaine>saghul: hey that change you just made to uv_cwd on master
21:39:57  <saghul>tjfontaine: yes, apply that one plus this: https://gist.github.com/saghul/9495346
21:40:01  * prettyrobotsjoined
21:40:20  <saghul>tjfontaine: not sure if you read earlier, something happened to this 90s tech
21:40:41  * bradleymeckchanged nick to 7JTAAKJ2H
21:41:12  * euoiajoined
21:41:12  * kuplatupsujoined
21:41:12  * Damn3djoined
21:41:12  * bradleymeckjoined
21:41:12  * c0a8joined
21:41:12  * Raynosjoined
21:41:12  * Domenic_joined
21:41:12  * wolfeidaujoined
21:41:12  * SquirrelCZECHjoined
21:41:12  * dsantiagojoined
21:41:12  * `3rdEdenjoined
21:41:12  * nsmjoined
21:41:56  * Damn3dquit (Changing host)
21:41:56  * Damn3djoined
21:42:01  * prettyrobotschanged nick to Guest13645
21:42:19  <tjfontaine>saghul: right that's what I was going to suggest, based on what I was reading, that the windows multibyte included the null character
21:42:45  <saghul>tjfontaine: all similar APIs include it and it's part of the returned len
21:42:53  <tjfontaine>my point is this
21:43:04  <tjfontaine>current state of libuv 0.11.22 -- unix does not include the \0 and windows does
21:43:08  <tjfontaine>is that assumption right?
21:43:14  <tjfontaine>r assessment
21:43:15  <tjfontaine>*or
21:43:19  <saghul>yes
21:43:21  * txdvjoined
21:43:25  <saghul>well, wait
21:43:31  <saghul>the \0 is there
21:43:40  <saghul>but the retuned len didn't count it
21:43:42  <saghul>it does now
21:43:42  <tjfontaine>it is there, btu the size does not count it
21:43:43  <tjfontaine>right
21:43:53  <tjfontaine>I want to work around this for now and finish my release
21:43:59  <tjfontaine>and avoid another libuv release
21:44:06  <tjfontaine>just for today
21:44:07  <saghul>so, take the libuv patch I pushed and the gist and you're good to go
21:44:14  <saghul>oh, as you with :-)
21:44:18  <tjfontaine>:)
21:44:20  <saghul>*wish
21:45:10  * m76joined
21:45:14  * xaqjoined
21:45:31  * eugenewarejoined
21:47:31  * Kakerajoined
21:51:16  <tjfontaine>sigh is github still down?
21:52:03  <indutny>saghul: so
21:52:04  <indutny>github is down
21:52:06  <indutny>let me comment here
21:52:08  <indutny>:P
21:52:17  <indutny>do you think that we should handle this case?
21:52:27  <indutny>I don't see any actual reasons for us to not do
21:52:28  <indutny>but anyway
21:52:43  <indutny>there is some tricky stuff to get through
21:52:46  <indutny>like fd invalidation
21:52:48  <indutny>and the rest
21:53:28  * eugenewarequit (Remote host closed the connection)
21:54:02  * eugenewarejoined
21:54:21  <saghul>indutny: that's what I was wondering
21:54:28  <indutny>yeah
21:54:32  <saghul>we could remove the fd from the epoll I guess
21:54:43  <indutny>why not do it via API interface?
21:54:46  <saghul>but what if evil Eve had closed the epoll fd itself?
21:54:47  <indutny>uv_close() and rest
21:55:02  <saghul>well, closing the handle can be a bit rough
21:55:16  <saghul>TBH I haven't thought about how to warn the user
21:55:16  * rmgjoined
21:55:22  * 7JTAAKJ2Hquit (Quit: 7JTAAKJ2H)
21:55:32  <saghul>first I was thinking on how to avoid the abort()
21:55:38  <indutny>well
21:55:40  <indutny>this is fine
21:55:43  <indutny>perhaps
21:55:50  <indutny>you give away a fd
21:55:52  <indutny>to the libuv
21:56:03  <indutny>and from now on - it works with it
21:56:10  <indutny>closing it without letting uv know
21:56:12  <indutny>is just incorrect
21:56:29  * daviddiasjoined
21:56:31  <saghul>of course
21:56:48  <saghul>but abort()-ing is not good either IMHO
21:57:25  <indutny>why not?
21:57:32  <indutny>it is definitely unexpected
21:58:19  * eugenewarequit (Ping timeout: 245 seconds)
21:58:33  <saghul>yes, but look at the user report, it happened because of garbage collection, kinda hard to track down in a bigger app maybe
21:59:10  <indutny>hm...
21:59:11  <saghul>we may not have another choice, but I wanted to explore if there was a possibility not to do so and just fail gracefully
21:59:14  <indutny>incorrectapp design?
22:01:31  * calvinfojoined
22:03:19  <tjfontaine>fuck I just want to push this change and finish this fucking release
22:03:25  <tjfontaine>DAMN YOU GITHUB AND INTERWEBS
22:03:25  <LOUDBOT>HE JUST CRIES ALL THE TIME… I MEAN, DO THEY HAVE OFF SWITCHES?
22:05:45  <tjfontaine>LOUDBOT: TWITLAST
22:05:45  <LOUDBOT>http://twitter.com/LOUDBOT/status/443508099312136193 (Krinkle/#stackvm)
22:07:56  <MI6>joyent/node: Timothy J Fontaine v0.11.12-release * 7d6b8db : src: accommodate uv_cwd including null on win32 - http://git.io/wUebmw
22:12:50  * janjongboomjoined
22:13:37  * quijotejoined
22:14:41  * m76quit (Read error: Connection reset by peer)
22:16:21  * Kakeraquit (Ping timeout: 264 seconds)
22:18:01  * quijotequit (Ping timeout: 246 seconds)
22:28:20  * mikolalysenkoquit (Ping timeout: 265 seconds)
22:33:42  * paulfryzeljoined
22:34:15  * paulfryzelquit (Read error: Connection reset by peer)
22:34:42  * paulfryzeljoined
22:41:00  * daviddiasquit (Remote host closed the connection)
22:41:13  * daviddiasjoined
22:54:02  * mikolalysenkojoined
22:57:12  <trevnorris>I am really starting to hate process.nextTick(). it's making proper async propagation impossible.
22:59:43  * paulfryzelquit (Remote host closed the connection)
23:00:28  * paulfryzeljoined
23:08:04  * tumdedumjoined
23:09:50  * eugenewarejoined
23:10:25  * euoiaquit (Ping timeout: 240 seconds)
23:13:10  * xaqquit (Remote host closed the connection)
23:14:15  * AvianFluquit (Ping timeout: 265 seconds)
23:14:21  * quijotejoined
23:15:40  <bradleymeck>trevnorris: ironically I was thinking the same about sync operations
23:18:44  * quijotequit (Ping timeout: 252 seconds)
23:18:59  <trevnorris>bradleymeck: um, was that for tjfontaine ?
23:19:09  <trevnorris>or am I just brain dead?
23:19:25  <bradleymeck>no that was about process.nextTick
23:19:45  <bradleymeck>had some issues with modifying require() when streams are nextTick'd
23:21:09  * jmar777joined
23:23:25  * abraxasjoined
23:27:40  * abraxasquit (Ping timeout: 246 seconds)
23:32:11  * paulfryzelquit (Remote host closed the connection)
23:33:33  <trevnorris>bradleymeck: ah, yeah. nextTick is the ultimate way to loose the caller's context. Especially with AsyncListeners, because it doesn't directly link back to the "provider" type (e.g. TCP/PIPE/TIMER/etc.)
23:37:46  * euoiajoined
23:47:31  * bradleymeckquit (Quit: bradleymeck)
23:49:02  * bradleymeckjoined
23:50:24  * bradleymeckquit (Client Quit)
23:52:04  * mikolalysenkoquit (Ping timeout: 245 seconds)