00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:02:29  * cjihrigquit (Quit: Leaving.)
00:04:53  * CoverSlidejoined
00:07:55  * c4milojoined
00:12:49  * c4miloquit (Ping timeout: 272 seconds)
00:15:22  * cjihrigjoined
00:16:59  * a_lequit (Remote host closed the connection)
00:20:50  * dap_quit (Quit: Leaving.)
00:27:15  * EhevuTovquit (Quit: This computer has gone to sleep)
00:34:37  * avalanche123quit (Remote host closed the connection)
00:38:09  * ijrothjoined
00:40:03  * a_lejoined
00:51:00  * kazuponjoined
01:06:38  * kazuponquit (Remote host closed the connection)
01:09:03  * lance|afkchanged nick to lanceball
01:15:10  * brsonquit (Quit: leaving)
01:15:38  * brsonjoined
01:18:18  * kazuponjoined
01:29:13  * octetcloudquit (Ping timeout: 255 seconds)
01:34:27  * ijrothquit (Quit: Leaving.)
01:35:02  * avalanche123joined
01:37:27  * a_lequit (Remote host closed the connection)
01:38:40  * a_lejoined
01:39:42  * avalanche123quit (Ping timeout: 256 seconds)
01:51:03  * a_lequit (Remote host closed the connection)
01:56:52  * c4milojoined
02:00:48  * chris_99quit (Quit: Ex-Chat)
02:01:18  * jgiquit (Quit: jgi)
02:01:22  * pgicxplzsquit (Remote host closed the connection)
02:01:24  * hayesquit (Ping timeout: 258 seconds)
02:01:47  * c4miloquit (Ping timeout: 258 seconds)
02:06:27  * hayesjoined
02:19:01  * chris_99joined
02:26:53  * avalanche123joined
02:29:47  * avalanche123quit (Remote host closed the connection)
02:38:33  * stagasquit (Ping timeout: 260 seconds)
02:46:36  * cjihrigquit (Quit: Leaving.)
02:49:19  * toothrotquit (Ping timeout: 265 seconds)
03:02:35  * avalanche123joined
03:03:33  * chris_99quit (Remote host closed the connection)
03:12:45  * octetcloudjoined
03:14:09  * Fishrock123joined
03:14:59  * rmgquit (Remote host closed the connection)
03:28:11  * petka_quit (Quit: Connection closed for inactivity)
03:37:46  * brsonquit (Ping timeout: 256 seconds)
03:45:49  * c4milojoined
03:46:35  * Fishrock123quit (Quit: Leaving...)
03:48:17  * iarnaquit (Remote host closed the connection)
03:49:06  * kazuponquit (Remote host closed the connection)
03:50:10  * c4miloquit (Ping timeout: 244 seconds)
04:13:49  * avalanche123quit (Remote host closed the connection)
04:15:29  * rmgjoined
04:17:27  * iarnajoined
04:20:18  * rmgquit (Ping timeout: 255 seconds)
04:27:15  * avalanche123joined
04:36:04  * KiNgMaRquit (Ping timeout: 265 seconds)
04:36:46  * KiNgMaRjoined
04:45:07  * kazuponjoined
04:53:26  * kazupon_joined
04:53:33  * avalanche123quit (Remote host closed the connection)
04:55:45  * kazuponquit (Ping timeout: 260 seconds)
05:02:34  * avalanche123joined
05:06:43  * ijrothjoined
05:33:38  * a_lejoined
05:34:43  * c4milojoined
05:38:39  * a_lequit (Remote host closed the connection)
05:39:31  * c4miloquit (Ping timeout: 258 seconds)
05:42:47  * KiNgMaRquit (Ping timeout: 272 seconds)
05:45:24  * KiNgMaRjoined
05:48:03  * octetcloudquit (Ping timeout: 255 seconds)
05:55:15  * ijrothquit (Quit: Leaving.)
06:04:14  * jgijoined
06:04:21  <jgi>indutny: hi
06:04:51  <jgi>indutny: if you have some time, I wrote the results of my investigation regard the “TLS socket not closing” issue here: https://github.com/joyent/node/issues/8615#issuecomment-60713596
06:15:03  * avalanche123quit (Remote host closed the connection)
06:18:10  * avalanche123joined
06:20:46  * jgiquit (Quit: jgi)
06:27:32  * ijrothjoined
06:28:34  * avalanche123quit (Remote host closed the connection)
06:49:02  * iarnaquit (Remote host closed the connection)
06:49:46  * iarnajoined
07:00:37  * SergeiRNDjoined
07:23:29  * c4milojoined
07:26:57  * rendarjoined
07:28:41  * c4miloquit (Ping timeout: 265 seconds)
07:28:56  * avalanche123joined
07:30:59  * stagasjoined
07:33:08  * SergeiRNDquit (Quit: Leaving.)
07:33:30  * avalanche123quit (Ping timeout: 256 seconds)
07:43:57  * Ldxngxjoined
07:44:25  * Ldxngxquit (Client Quit)
07:44:34  * Ldxngxjoined
08:10:09  * avalanche123joined
08:22:52  * stagasquit (Read error: Connection reset by peer)
08:30:47  * avalanche123quit (Remote host closed the connection)
08:33:46  * ijrothquit (Quit: Leaving.)
08:46:09  * SergeiRNDjoined
08:54:41  * janjongboomjoined
08:55:28  * janjongboomquit (Read error: Connection reset by peer)
08:55:33  * janjongb_joined
08:56:59  * janjongb_quit (Read error: Connection reset by peer)
08:57:04  * janjongboomjoined
09:03:18  * janjongb_joined
09:06:46  * janjongboomquit (Ping timeout: 264 seconds)
09:06:47  * janjongb_quit (Client Quit)
09:07:04  * janjongboomjoined
09:12:30  * c4milojoined
09:17:13  * c4miloquit (Ping timeout: 244 seconds)
09:30:46  * janjongboomquit (Ping timeout: 264 seconds)
09:31:38  * janjongboomjoined
09:31:40  * SergeiRND1joined
09:32:17  * SergeiRNDquit (Ping timeout: 264 seconds)
09:42:14  * rmgjoined
09:46:46  * rmgquit (Ping timeout: 258 seconds)
09:54:42  * petka_joined
09:57:46  * SergeiRNDjoined
09:57:47  * SergeiRND1quit (Read error: Connection reset by peer)
10:19:13  * avalanche123joined
10:20:20  * iarnaquit (Remote host closed the connection)
10:22:15  * seishunjoined
10:23:52  * avalanche123quit (Ping timeout: 256 seconds)
10:23:59  * iarnajoined
10:29:19  * chris_99joined
10:34:08  * kazupon_quit (Remote host closed the connection)
10:36:38  * benglquit (Ping timeout: 265 seconds)
10:37:55  * rfquit (Ping timeout: 272 seconds)
10:41:41  * jas-quit (Remote host closed the connection)
10:46:04  * Left_Turnjoined
10:48:35  * bengljoined
10:58:42  * SergeiRNDquit (Quit: Leaving.)
11:01:29  * c4milojoined
11:02:47  * AlexisMochaquit (Ping timeout: 245 seconds)
11:06:34  * c4miloquit (Ping timeout: 256 seconds)
11:08:28  * AlexisMochajoined
11:08:28  * tarrudajoined
11:25:10  <AlexisMocha>tjfontaine: jenkins is down again
11:25:11  <AlexisMocha>An error has occurred: {"code":"ECONNREFUSED","errno":"ECONNREFUSED","syscall":"connect"}
11:25:40  * Dijoined
11:25:54  * SergeiRNDjoined
11:26:47  <AlexisMocha>can you give me access to the machine so I can fix it next time?
11:45:28  <txdv>give me access too
11:48:36  * Left_Turnquit (Ping timeout: 244 seconds)
11:53:00  * Diquit (Quit: Leaving.)
11:56:52  * seishunquit (Ping timeout: 244 seconds)
11:57:41  * Dijoined
11:57:59  * Diquit (Client Quit)
12:00:01  * toothrotjoined
12:08:45  * AlexisMochaquit (Ping timeout: 244 seconds)
12:19:42  * jas-joined
12:25:58  * Dijoined
12:27:52  * cjihrigjoined
12:30:45  * Diquit (Ping timeout: 260 seconds)
12:32:21  * EhevuTovjoined
12:33:20  * AlexisMochajoined
12:34:01  * rfjoined
12:47:24  * Di1joined
12:50:17  * c4milojoined
12:52:41  * toothrotquit (Ping timeout: 260 seconds)
12:56:53  * Di1quit (Ping timeout: 260 seconds)
13:01:02  * Left_Turnjoined
13:12:27  * warehouse13joined
13:15:00  * Left_Turnquit (Ping timeout: 256 seconds)
13:16:37  * cjihrigquit (Quit: Leaving.)
13:17:16  * Dijoined
13:22:05  * Diquit (Ping timeout: 260 seconds)
13:27:30  * SergeiRNDquit (Read error: Connection reset by peer)
13:27:36  * SergeiRND1joined
13:30:08  * iarnaquit (Remote host closed the connection)
13:36:29  * SergeiRND1quit (Ping timeout: 264 seconds)
13:41:51  * SergeiRNDjoined
13:47:01  * cjihrigjoined
14:09:40  * KennethWilkejoined
14:16:41  * SergeiRNDquit (Ping timeout: 264 seconds)
14:17:22  * pgicxplzsjoined
14:19:10  * warehouse13quit (Ping timeout: 255 seconds)
14:20:37  * rmgjoined
14:25:15  * rmgquit (Ping timeout: 256 seconds)
14:30:32  * iarnajoined
14:42:28  * SergeiRNDjoined
14:44:12  * kazuponjoined
14:47:07  * SergeiRND1joined
14:47:17  * SergeiRNDquit (Ping timeout: 264 seconds)
14:47:22  * AlexisMochaquit (Ping timeout: 244 seconds)
14:48:37  * iarnaquit (Ping timeout: 245 seconds)
14:54:30  * AlexisMochajoined
14:54:54  * importantshockjoined
14:58:52  * avalanch_joined
14:59:00  * SergeiRND1quit (Quit: Leaving.)
15:01:39  * a_lejoined
15:03:12  * janjongboomquit (Ping timeout: 245 seconds)
15:04:14  * janjongboomjoined
15:08:01  * cjihrigquit (Quit: Leaving.)
15:11:33  <tjfontaine>AlexisMocha: sad
15:11:42  <tjfontaine>AlexisMocha: how do you break it? :)
15:12:16  <tjfontaine>/opt/local/bin/java: line 6: 50747 Abort (core dumped) /opt/local/java/sun6/bin/java "[email protected]"
15:12:19  <tjfontaine>wow.
15:12:20  <tjfontaine>good work.
15:12:39  * c4miloquit (Remote host closed the connection)
15:13:27  <tjfontaine>AlexisMocha: SEVERE: Couldn't create web hook for repository orangemocha/node. Does the user (from global configuration) have admin rights to the repository?
15:13:48  <AlexisMocha>I try my best :)
15:14:01  <tjfontaine>as I watch the logs go by
15:14:02  <AlexisMocha>it was failing all day yesterday because of out of memory
15:14:24  <tjfontaine>the box has 8gb -- way to be java.
15:14:46  <AlexisMocha>but there's a cmdline flag to start jenkins with
15:14:50  <AlexisMocha>the default is 256mb
15:15:12  <AlexisMocha>unless you specify differently
15:15:14  <tjfontaine>well it's already using 500MB
15:15:40  <tjfontaine>should a CI server really need that much memory I ask
15:17:05  * c4milojoined
15:17:27  <AlexisMocha>maybe.. maybe not.. but it should fail more gracefully
15:17:53  * c4miloquit (Read error: Connection reset by peer)
15:18:05  * c4milojoined
15:20:56  <AlexisMocha>tjfontaine: I added nodejs-jenkins to my repo
15:21:14  <AlexisMocha>which hopefully will fix that SEVERE error
15:23:53  <tjfontaine>sounds about right
15:26:30  <AlexisMocha>tjfontaine: why don't you increase the memory and i re-enable my evil job, and at least we'll know if it was a legit OOM issue
15:28:38  <AlexisMocha>The second is related to PermGen: java.lang.OutOfMemoryError: PermGen space. When you see this, you need to increase the maximum Permanent Generation space, which is used for things like class files and interned strings. You can do this by adding the following to your JVM arguments -XX:MaxPermSize=128m where you replace the number 128 with the new PermGen size in megabytes.
15:29:04  <tjfontaine>is that where it happened or some other more generic memory location?
15:29:25  <AlexisMocha>I saw this yesterday:
15:29:26  <AlexisMocha>FATAL: PermGen space
15:29:26  <AlexisMocha>java.lang.OutOfMemoryError: PermGen space
15:29:29  <tjfontaine>ok
15:29:39  <tjfontaine>what's your suggested value then?
15:29:58  <tjfontaine>well, actually that sounds like it's on the slave side?
15:31:22  <AlexisMocha>no, it's on the master
15:31:33  <chris_99>https://twitter.com/r_netsec
15:31:35  <chris_99>oops
15:31:36  <chris_99>sorry
15:31:37  <tjfontaine>ok what value woudl you prefer then?
15:32:11  <AlexisMocha>you said you have 8gb, make it 1gb
15:32:34  <tjfontaine>jenkins going down
15:33:08  <tjfontaine>coming back up
15:33:41  <tjfontaine>oh, it's asking to create a webhook, tell your job not to manage the webhooks automagically
15:33:56  <AlexisMocha>why is that bad?
15:34:24  <AlexisMocha>like it's prompting you for it??
15:35:15  <tjfontaine>because there's a proxy in front, you want a predictable end point to come through
15:35:28  * cjihrigjoined
15:35:50  <tjfontaine>so these permgen errors are happening on the slaves
15:35:54  <tjfontaine>http://jenkins.nodejs.org/computer/osx-home/log
15:36:39  <tjfontaine>ubuntu 14.04 came back up on its own after I restarted the slave agent
15:37:53  <AlexisMocha>what would be a predictable endpoint? the webhooks should all be under jenkins.nodejs.org
15:38:27  <tjfontaine>it goes to jenkins.nodejs.org/github-webhook
15:38:39  <tjfontaine>joyent/node is already set that way
15:42:48  <AlexisMocha>ok, I copied it and disabled automatic webhooks
15:44:44  <AlexisMocha>so if everything looks good from you end I re-enable my project and push something to my repo
15:45:28  <tjfontaine>I'm still working on bringing all the slaves back to life
15:46:38  <tjfontaine>for some reason all the slaves are flapping
15:47:37  <AlexisMocha>out of mem?
15:47:57  <tjfontaine>no they were more generic errors, they seem to be holidng right now
15:48:04  <tjfontaine>like it was lceaning up old jobs
15:48:47  <AlexisMocha>this thing doesn't seem very robust
15:49:04  <tjfontaine>jenkins?
15:49:07  <AlexisMocha>i spent some time reviewing alternatives
15:49:09  <AlexisMocha>yep
15:49:14  <tjfontaine>no. it's terrible software
15:49:18  <tjfontaine>but buildbot isn't much better
15:49:23  <AlexisMocha>TeamCity looks promising
15:49:55  <tjfontaine>heh
15:50:14  * warehouse13joined
15:50:24  <AlexisMocha>have you tried it?
15:50:30  <tjfontaine>no I haven't
15:50:52  <tjfontaine>what's it use as its base? java as well?
15:51:00  <AlexisMocha>yep, i think it's java
15:51:10  <AlexisMocha>similar architecture to jenkins
15:51:19  <tjfontaine>ya that's what I thought
15:51:21  <AlexisMocha>but probably better quality
15:52:22  * pgicxplzsquit (Ping timeout: 245 seconds)
15:54:36  <AlexisMocha>anyway, i think the absolutely lowest hanging fruit is to implement a job that will take a commit sha1 and a branch as parameter, rebase the commit on the branch, test it, and merge it
15:55:19  <AlexisMocha>automatic testing of PRs is lower priority
15:56:13  <AlexisMocha>because like you said, just because a PR is tested, doesn't mean it has been rebased, or it doesn't mean the tests will pass when it's finally merged
15:56:20  <AlexisMocha>so we need the last gate more than anything
15:56:40  <tjfontaine>yes
15:57:29  * rmgjoined
15:59:52  * avalanch_quit (Remote host closed the connection)
16:00:07  * iarnajoined
16:00:12  * jgijoined
16:00:18  <AlexisMocha>it should be fairly easy to implement starting from the current infrastructure
16:00:51  <jgi>indutny: Hi! I’m back if you have questions regarding https://github.com/joyent/node/issues/8615#issuecomment-60713596
16:00:55  <indutny>hey hey
16:01:04  <indutny>jgi: so why is it using _tls_legacy.js ?
16:01:11  <indutny>your explanation is quite good, but I just can't figure
16:01:18  <indutny>are they calling `createSecurePair`?
16:01:35  <jgi>indutny: let me check
16:04:13  <indutny>also it appears to be working on my mac :D
16:04:14  <indutny>haha
16:04:20  <indutny>let me run more iterations of client
16:04:59  * iarnaquit (Ping timeout: 264 seconds)
16:05:16  <indutny>ok
16:05:18  <indutny>I reproduced it
16:05:23  <jgi>indutny: ok
16:06:11  <indutny>jgi: it doesn't seem that it hits _tls_legacy.js path, though
16:06:38  <indutny>jgi: I think it is using tls_wrap.cc
16:06:44  * seishunjoined
16:07:10  * brsonjoined
16:08:09  <jgi>indutny: yes, I’ve never seen any use of _tls_legacy.js in my investigations so far
16:08:17  <indutny>hm...
16:08:29  <indutny>but you was talking about https://github.com/joyent/node/commit/1e066e4a4a88f97af865d965f104b5fe8136797f, right?
16:08:47  <indutny>ooh, I see tls_wrap.cc changes here too
16:08:50  <jgi>indutny: :)
16:08:53  <indutny>haha
16:09:02  <indutny>sorry, I just seen that it was a merge of v0.10
16:09:36  <jgi>indutny: no problem :)
16:09:45  * brockfredinquit
16:09:46  <indutny>ok, will figure it out today
16:10:37  * cjihrigquit (Quit: Leaving.)
16:13:27  <jgi>indutny: Cool thank you! Have you read my latest comments on the issue? I just want to make sure we don’t duplicate work :)
16:13:47  <indutny>yeah
16:14:30  <jgi>ok all good then :)
16:15:42  * octetcloudjoined
16:16:30  * avalanche123joined
16:17:03  <indutny>jgi: oh
16:17:09  <indutny>I have re-read your comment
16:17:16  <indutny>I guess this that `ws` is broken :)
16:17:22  <indutny>haha
16:17:38  * Fishrock123joined
16:17:46  <jgi>yeah, it seems very dangerous to remove all event handlers
16:18:13  <jgi>I wonder how this has not caused other issues for so long
16:19:16  <indutny>idk
16:19:22  <indutny>perhaps EOF was emitted earlier
16:19:29  <indutny>there is actually one possible problem in tls_wrap.cc
16:19:34  <indutny>that I thought could be causing it
16:19:38  <indutny>but it is in fact not
16:19:45  <indutny>the close_notify thing may not be sent
16:19:53  <indutny>if there is a write in-progress
16:20:26  <indutny>but this doesn't appear to be the case for this ws situation
16:20:31  <indutny>so I believe you in your investigation :D
16:22:08  <jgi>indutny: ok, so does reporting this issue to ws make sense to you?
16:22:10  * avalanche123quit (Remote host closed the connection)
16:22:14  <indutny>jgi: absolutely
16:22:45  <jgi>indutny: alright, I’ll do that and we should also get more feedback from @migounette soon
16:22:52  <jgi>indutny: thanks!
16:22:57  <indutny>thank *you*
16:26:33  * dap_joined
16:28:25  * avalanche123joined
16:30:26  * tarrudaquit (Quit: WeeChat 0.4.2)
16:30:54  * avalanche123quit (Remote host closed the connection)
16:33:50  * ijrothjoined
16:34:40  <indutny>jgi: ok, this shutdown possible problem
16:34:43  <indutny>won't actually happen
16:34:55  <indutny>because we are a calling .shutdown() from 'finish' handler
16:35:08  <indutny>I guess I could just add an assert in tls_wrap.cc
16:35:11  <jgi>indutny: what problem?
16:35:14  <indutny>to ensure that the close_notify is written
16:35:43  <jgi>ah the one you were mentioning before? “indutny: the close_notify thing may not be sent [09:19am] indutny: if there is a write in-progress”?
16:35:51  <indutny>yeah
16:35:53  <jgi>ok
16:36:49  <jgi>indutny: I haven’t read https://www.openssl.org/docs/ssl/SSL_shutdown.html yet, going to do that right now so that I actually know what I’m talking about :)
16:37:01  <indutny>haha
16:37:04  <indutny>ok
16:42:47  * importan_joined
16:42:47  * importantshockquit (Read error: Connection reset by peer)
16:43:16  * chris_99quit (Remote host closed the connection)
16:50:43  * bajtosjoined
16:51:23  * c4miloquit (Remote host closed the connection)
16:51:26  * cjihrigjoined
16:51:47  * Ldxngxquit (Ping timeout: 264 seconds)
16:56:38  * SergeiRNDjoined
16:57:03  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:57:19  * wolfeidau_joined
17:00:22  * wolfeidauquit (Ping timeout: 240 seconds)
17:02:22  * warehouse13quit (Ping timeout: 272 seconds)
17:13:53  * importan_quit (Remote host closed the connection)
17:14:27  * importantshockjoined
17:17:16  * importantshockquit (Remote host closed the connection)
17:17:29  * importantshockjoined
17:25:31  <jgi>indutny: After thinking a bit more about the issue with tjfontaine, it seems that not calling back onread with EOF if a close-notify has already been received could break the state machine. When we call back onread with the “fake” EOF, some of the state does not indicate that we actually received EOF. What do we gain in not calling back onread when an actual EOF was received?
17:26:02  <indutny>we do get consistency
17:26:09  <indutny>two EOFs is kind of weird
17:26:41  <indutny>so what of the state does not indicate that we actually received EOF?
17:27:31  <jgi>indutny: IIRC, self._readableState.length !== 0 here: https://github.com/joyent/node/blob/master/lib/net.js#L540-L543
17:28:11  * petka_quit (Quit: Connection closed for inactivity)
17:29:02  * chris_99joined
17:29:13  <indutny>jgi: this could be true for a regular socket as well
17:29:16  <indutny>if no one is reading from it
17:29:26  * importantshockquit (Remote host closed the connection)
17:29:58  * importantshockjoined
17:34:15  * importantshockquit (Ping timeout: 244 seconds)
17:34:40  * petka_joined
17:35:40  * c4milojoined
17:36:18  * importantshockjoined
17:36:44  * AlexisMochaquit (Ping timeout: 258 seconds)
17:37:39  * EhevuTovquit (Quit: This computer has gone to sleep)
17:39:19  * avalanche123joined
17:41:29  * ijrothquit (Quit: Leaving.)
17:42:03  * kazuponquit (Remote host closed the connection)
17:42:34  * Fishrock123quit (Remote host closed the connection)
17:42:42  <jgi>indutny: ok
17:42:59  <indutny>the fact that there is some data there
17:43:04  <indutny>means only that it wasn't yet read
17:44:57  <jgi>indutny: another interesting idea would be to prevent external modules from accessing internal handlers (which should be really internals). For instance, that would prevent the ws module from messing up with the state machine.
17:45:23  <indutny>you mean that we should not use 'finish' event internally?
17:45:28  <jgi>indutny: for tls sockets, one way to do that would be to not make TLSSocket inherit from net.Socket, and use it as a property instead. What do you think about that?
17:45:39  <indutny>jgi: I disagree
17:46:30  <indutny>I mean, I do see how this will fix the problem
17:46:31  <indutny>but
17:46:34  <indutny>it looks like a hack
17:46:48  <indutny>I really enjoy how we should not re-implement all of net.js stuff
17:46:50  <indutny>in TLSSocket
17:47:02  <indutny>and we did all of this emulation in _tls_legacy.js
17:47:04  <indutny>so
17:47:09  <indutny>moving it away from net.Socket
17:47:14  <indutny>would be a step backwards, IMHO
17:47:33  <jgi>indutny: we would still resuse net.Socket, we would just not expose all of it to the outside
17:48:00  <indutny>haha
17:48:06  <indutny>what's the point, then? :)
17:48:13  <indutny>we don't need all of it internally
17:48:33  <indutny>anyway
17:48:38  <indutny>I think that `ws` is kind of messed up
17:48:52  <jgi>indutny: to avoid letting modules like ws break the state of tls sockets, or at least to make it more explicit when they do so
17:48:52  <indutny>removeAllListeners is generally a bad idea
17:48:56  <indutny>and will break many things
17:49:14  <indutny>it doesn't break the state of tls socket
17:49:17  <indutny>it does break state of any socket
17:49:27  <indutny>I mean
17:49:30  <indutny>we depend on events
17:49:32  <indutny>everywhere
17:49:49  <indutny>if you'll remove all listeners from server
17:49:51  <indutny>it won't work
17:49:58  <indutny>there is nothing special about tls here
17:50:02  <indutny>and so nothing to fix
17:50:23  <indutny>anyway, again
17:50:28  <indutny>this is the state of net.js socket
17:50:32  <indutny>that is broken by ws
17:50:37  * iarnajoined
17:50:40  <indutny>and so it should practically apply to all kinds of sockets
17:50:41  <jgi>indutny: yes, we could also have a way to handle events that is not so easy to break
17:50:47  <indutny>it just could be a race
17:50:56  <indutny>and won't happen most of the time for net.Sockets
17:51:09  <indutny>jgi: right, this may be a way to go
17:51:24  <indutny>but -1 for separation of tls and net.Socket
17:52:35  * a_lechanged nick to a_le_AFK
17:53:22  <indutny>gtg
17:53:41  <jgi>indutny: thanks and see you later!
17:55:44  * c4miloquit (Remote host closed the connection)
17:55:59  <tjfontaine>I don't think all of net.Socket would need to be reimplemented, most of it behaves like a duplex stream
17:56:16  <tjfontaine>the major gain was to do the stream wrap shortcut
17:56:46  <tjfontaine>removeAllListeners should generally be considered safe once we have identified the end of our state machine
17:57:05  <indutny>the end is
17:57:05  <tjfontaine>the problem here is that `finish` generally indicates that it is safe to clean up resources
17:57:09  <indutny>'end' event + 'finished'
17:57:11  <indutny>right?
17:57:13  <indutny>erm
17:57:13  <tjfontaine>end is for readable, finish is for writable
17:57:14  <indutny>'finish'
17:57:20  <indutny>and 'close'
17:57:22  <tjfontaine>close is for the underlying resource
17:57:34  <indutny>'finish' does not identify it :)
17:57:35  <tjfontaine>emitting finish before we've ack'd all written data is a bug
17:57:43  <tjfontaine>(I think(
17:57:45  <tjfontaine>*)
17:57:48  <indutny>hm...
17:57:55  <indutny>yes and no
17:57:59  <indutny>the openssl is kind of blackbox
17:58:04  <indutny>so we can't certainly tell
17:58:10  <indutny>if the data has got through it
17:58:20  <indutny>we just feed data to it
17:58:24  <tjfontaine>indeed
17:58:24  <indutny>and read the data from the other end
17:58:35  <indutny>so there is some behavior difference here
17:59:08  <jgi>also, ws does not wait for the finish event to remove all listeners
17:59:09  <tjfontaine>which is why it's dangerous to have it directly inherit from net.Socket
17:59:16  <tjfontaine>jgi: what event does it use?
17:59:22  <jgi>end, close and error
17:59:35  <tjfontaine>and in this case is it seeing 'end' when it cleans up?
17:59:37  <jgi>if any of them is emitted, then it cleans up resources
17:59:42  <jgi>yes
18:00:05  <indutny>it is not dangerous :)
18:00:10  <indutny>I think it is `ws`
18:00:12  <tjfontaine>but the actual net.Socket portion hasn't finished, this is the synthetic eof?
18:00:14  <indutny>who misbehaves here
18:00:30  <indutny>yes
18:00:32  <indutny>and it is fine
18:00:36  <indutny>the semantics are the same
18:00:41  <indutny>there won't be any data
18:00:45  <tjfontaine>beyond ws I am sure there are a lot of people doing removeAllListeners when end is emitted
18:00:54  <indutny>good luck to them
18:00:56  <indutny>it is like
18:00:58  <tjfontaine>haha
18:01:06  <indutny>closing the socket when writing all data :D
18:01:11  <indutny>without reading the response
18:05:19  <tjfontaine>it is definitely a bug that people are able to mutate the events table for how we're tracking our own state machine, but we can't fix this now
18:05:55  <tjfontaine>at the very least this is a change in behavior from 0.10 to 0.12, and we need to document why it is changing and what that means
18:06:31  * iarnaquit (Remote host closed the connection)
18:06:32  <tjfontaine>though this feels like an unfortunate bw compat change that we can actually attempt to fix
18:06:48  * importantshockquit (Remote host closed the connection)
18:08:00  * importantshockjoined
18:08:12  * importantshockquit (Remote host closed the connection)
18:08:13  * importan_joined
18:10:02  * c4milojoined
18:12:00  * iarnajoined
18:21:51  * Fishrock123joined
18:23:18  * c4miloquit (Remote host closed the connection)
18:27:43  * AlexisMochajoined
18:31:37  * dap_quit (Quit: Leaving.)
18:32:18  * dap_joined
18:37:29  * davijoined
18:39:40  * bajtosquit (Quit: bajtos)
18:40:19  * ijrothjoined
18:45:40  * c4milojoined
18:49:11  * Fishrock123quit (Quit: Leaving...)
18:50:50  * ijrothquit (Quit: Leaving.)
18:51:33  * chris_99quit (Remote host closed the connection)
18:52:29  * chris_99joined
18:52:56  * kazuponjoined
18:55:17  * Left_Turnjoined
18:57:37  * kazuponquit (Ping timeout: 260 seconds)
19:04:17  * avalanche123quit (Remote host closed the connection)
19:10:19  * jgiquit (Quit: jgi)
19:16:01  * rendarquit (Ping timeout: 258 seconds)
19:19:52  * avalanche123joined
19:22:12  * rendarjoined
19:23:38  * ijrothjoined
19:34:01  * ijrothquit (Quit: Leaving.)
19:40:22  * ijrothjoined
19:42:10  * ijrothquit (Client Quit)
19:46:38  * mmaleckiquit (Read error: Connection reset by peer)
19:48:58  * mmaleckijoined
19:52:15  * SergeiRNDquit (Quit: Leaving.)
19:57:00  * avalanche123quit (Remote host closed the connection)
19:57:44  * daviquit (Ping timeout: 245 seconds)
19:58:16  * avalanche123joined
19:58:56  * jas-quit (Remote host closed the connection)
20:01:02  * a_le_AFKchanged nick to a_le
20:14:32  * iarnaquit (Remote host closed the connection)
20:20:54  * jgijoined
20:20:57  * iarnajoined
20:28:12  * AlexisMochaquit (Ping timeout: 272 seconds)
20:30:35  * ijrothjoined
20:33:16  * hayesquit (Ping timeout: 272 seconds)
20:36:10  * ijrothquit (Quit: Leaving.)
20:39:13  * jgiquit (Quit: jgi)
20:39:48  * jgijoined
20:40:04  * hayesjoined
20:43:37  * Ralithquit (Ping timeout: 245 seconds)
20:52:25  * qard-appnetapart
20:52:52  * qard-appnetajoined
20:53:44  * qard-appnetapart
20:53:58  * qard-appnetajoined
21:04:17  * KennethWilkequit (Remote host closed the connection)
21:05:18  <creationix>Does anyone have a clue as to why appveyor hates’s libuv’s colored output on windows?
21:05:57  <creationix>Notice all the �’s in https://ci.appveyor.com/project/creationix/luvit
21:06:25  <creationix>it works fine on real windows
21:09:50  * Ralithjoined
21:10:40  * importan_quit (Remote host closed the connection)
21:11:01  * ijrothjoined
21:11:12  * importantshockjoined
21:14:09  * ijrothquit (Client Quit)
21:15:43  * WalrusPonyquit (Read error: Connection reset by peer)
21:15:52  * importantshockquit (Ping timeout: 255 seconds)
21:15:58  * WalrusPonyjoined
21:19:22  * importantshockjoined
21:21:09  * avalanche123quit (Remote host closed the connection)
21:22:33  * avalanche123joined
21:22:47  * rmgquit (Remote host closed the connection)
21:24:43  * ijrothjoined
21:28:10  * ijrothquit (Client Quit)
21:29:36  * ijrothjoined
21:31:16  * lanceballchanged nick to lance|afk
21:35:33  * ijrothquit (Quit: Leaving.)
21:36:51  * ryancolejoined
21:39:08  * Damn3d_quit (Ping timeout: 272 seconds)
21:44:01  * yunong_quit
21:49:45  <a_le>so, idle callbacks only get invoked when there are no other callbacks to be called, right? what if there are multiple idlers? do the idle callbacks get invoked in a round-robin way, one per idle loop available?
21:50:33  * Damn3djoined
22:02:58  * rmgjoined
22:06:05  * toothrotjoined
22:31:35  * kazuponjoined
22:39:33  * importantshockquit (Remote host closed the connection)
22:42:28  * kazuponquit (Remote host closed the connection)
22:48:37  * cjihrigquit (Quit: Leaving.)
22:52:07  * sblomjoined
22:55:28  * cjihrigjoined
23:08:23  * rendarquit
23:10:38  * importantshockjoined
23:14:49  * importantshockquit (Ping timeout: 245 seconds)
23:20:46  * kazuponjoined
23:23:45  * seishunquit (Ping timeout: 255 seconds)
23:25:11  * kazuponquit (Ping timeout: 258 seconds)
23:31:41  * ijrothjoined
23:35:05  * ijrothquit (Client Quit)
23:35:16  * cjihrigquit (Quit: Leaving.)
23:35:35  * ijrothjoined
23:47:23  * dap_quit (Quit: Leaving.)
23:47:42  * ijrothquit (Quit: Leaving.)
23:50:08  * ijrothjoined
23:50:10  * iarnaquit (Remote host closed the connection)
23:51:57  * ijrothquit (Client Quit)
23:52:28  * ijrothjoined
23:54:43  * ijrothquit (Client Quit)
23:57:47  * iarnajoined
23:57:56  * avalanche123quit (Remote host closed the connection)