00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:00:11  * Damn3dquit (Ping timeout: 265 seconds)
00:01:44  * ijrothquit (Client Quit)
00:03:48  * iarnaquit (Read error: Connection reset by peer)
00:03:57  * Fishrock123quit (Remote host closed the connection)
00:04:57  * Damn3djoined
00:04:57  * Damn3dquit (Changing host)
00:04:57  * Damn3djoined
00:06:13  * ijrothjoined
00:08:03  * iarnajoined
00:14:02  * ijrothquit (Quit: Leaving.)
00:17:37  * ijrothjoined
00:39:17  * iarnaquit (Read error: Connection reset by peer)
00:39:46  * iarnajoined
00:39:54  <jgi>indutny: hi!
00:39:58  <jgi>indutny: are you around?
00:43:25  * iarnaquit (Read error: Connection reset by peer)
00:43:54  * iarnajoined
00:46:45  * c4milojoined
00:46:54  * octetcloudquit (Ping timeout: 256 seconds)
00:47:17  * ijrothquit (Quit: Leaving.)
00:52:03  * c4miloquit (Ping timeout: 272 seconds)
00:53:17  * dshaw_quit (Quit: Leaving.)
00:59:10  <indutny>jgi: heya
00:59:11  <indutny>kind of
00:59:20  <jgi>indutny: ok :)
00:59:32  <indutny>what's up?
01:00:23  <jgi>indutny: I just wanted to have one last look at https://github.com/joyent/node/issues/8615, and I was wondering why we wanted to emit ‘end’ when we get a SSL shutdown from the other end
01:00:39  <indutny>ok
01:00:41  <indutny>we emit 'end'
01:00:48  <indutny>because there won't be any new data from other side
01:00:57  <indutny>this is kind of what this is event is for here :)
01:01:45  <jgi>indutny: isn’t it possible that we get more data from the other side? Could the SSL session be done and the socket would still be open and data could be sent through it?
01:01:55  <indutny>nope
01:02:02  <indutny>this is impossible
01:02:05  * iarnaquit (Read error: Connection reset by peer)
01:02:11  <indutny>this is always the last packet in the session
01:02:15  <jgi>ok
01:02:34  * iarnajoined
01:05:14  * Fishrock123joined
01:07:40  * Ralithquit (Ping timeout: 250 seconds)
01:09:34  * Fishrock123quit (Ping timeout: 256 seconds)
01:12:33  * kazuponjoined
01:13:42  <jgi>indutny: so the goal of the change in tls_wrap to emit UV_EOF when we get the SSL shutdown is to get the ‘end’ event if we don’t read from the socket?
01:14:10  <indutny>you won't get 'end' event if you are not reading from socket
01:14:17  <indutny>this is not how _stream_readable.js works
01:14:29  <indutny>but the goal is to mark the end of the readable data
01:20:21  * nickleeflyquit (Quit: Connection closed for inactivity)
01:22:22  * kazuponquit (Remote host closed the connection)
01:23:29  <jgi>indutny: ok so tls.connect always triggers a read?
01:23:37  <indutny>em
01:23:42  <indutny>only on encrypted side :)
01:23:50  <indutny>not on the cleartext one
01:23:54  <jgi>ok
01:25:40  * stagasquit (Ping timeout: 265 seconds)
01:28:51  <jgi>indutny: how can we get an ‘end’ event in this case: https://github.com/joyent/node/blob/master/test/simple/test-tls-close-notify.js without “manually” triggering a read?
01:28:57  <jgi>indutny: or am I missing something?
01:29:20  <indutny>hm...
01:29:23  <indutny>good question, actually
01:29:33  <indutny>we should not
01:30:07  * dap_quit (Quit: Leaving.)
01:33:05  * Ralithjoined
01:37:18  <jgi>indutny: the way TLSSocket inherit from net.Socket, wouldn’t an end ‘event’ be emitted on the TLSSocket (the clear text side) when an ‘end’ event is emitted on the net.Socket (the encrypted side)?
01:37:50  <indutny>it will be
01:37:55  <indutny>and this is correct, afaik
01:38:03  <indutny>this is not graceful close
01:38:09  <indutny>but still
01:38:14  <indutny>means that there won't be any data
01:38:38  <jgi>right, then if an SSL_Shutdown is sent on the socket, the end event will be emitted on the “cleartext” side, right?
01:38:47  <jgi>even if we don’t read from the cleartext side
01:40:11  <jgi>if that’s true, my impression is that even though we try to make TLSSocket behave like a stream, it doesn’t because we can get an end event without reading from it
01:40:42  * kazuponjoined
01:43:01  <jgi>indutny: does it make sense?
01:43:28  <indutny>hm... sorry, it is hard to tell right now
01:43:34  <indutny>I need to investigate it a bit
01:43:39  <jgi>indutny: ok no problem :)
01:43:42  <indutny>and I am currently on a different thing
01:43:43  <indutny>:)
01:43:50  <indutny>so thing is
01:43:53  <indutny>that the encrypted side
01:43:59  <indutny>is detached from the stream interface
01:44:12  <indutny>and UV_EOF from encrypted is propagated manually to cleartext
01:44:30  <indutny>in a same way as with received close_notify
01:44:32  <indutny>so
01:44:37  <indutny>ideally, if I did no mistakes
01:44:42  <indutny>it should have correct stream behavior
01:44:48  <indutny>and conceptually it seem to be right
01:45:06  <indutny>the fact that the 'end' is emitted, is probably because we are triggering the first read on a client socket
01:45:17  <indutny>using .read(0)
01:45:30  <indutny>and on server socket too
01:45:33  <indutny>line 272
01:46:07  <jgi>indutny: which file?
01:46:12  <indutny>_tls_wrap.js
01:46:16  * rmgquit (Remote host closed the connection)
01:49:45  * ijrothjoined
02:03:08  * avalanche123quit (Remote host closed the connection)
02:06:34  <jgi>indutny: I have to go, thank you for your time and your clarifications :)
02:06:39  <indutny>np
02:06:42  <indutny>you are welcome :)
02:07:00  <jgi>have a good day or night!
02:07:07  * jgiquit (Quit: jgi)
02:16:57  * brsonquit (Quit: leaving)
02:17:23  * brsonjoined
02:25:02  * a_lequit (Remote host closed the connection)
02:25:47  * c4milojoined
02:35:55  * c4miloquit (Remote host closed the connection)
02:37:17  * cosnisjoined
02:37:31  * Fishrock123joined
02:40:15  * cosnisquit (Client Quit)
02:50:39  * brsonquit (Quit: leaving)
02:50:54  * brsonjoined
02:52:24  * dshaw_joined
02:56:20  * ijrothquit (Quit: Leaving.)
03:03:31  * avalanche123joined
03:03:41  * ijrothjoined
03:08:08  * avalanche123quit (Ping timeout: 265 seconds)
03:13:27  * ijrothquit (Quit: Leaving.)
03:16:04  * iarnaquit (Remote host closed the connection)
03:16:59  * iarnajoined
03:18:58  * iarnaquit (Remote host closed the connection)
03:34:47  * rmgjoined
03:37:06  * kazuponquit (Remote host closed the connection)
03:39:53  * rmgquit (Ping timeout: 272 seconds)
03:47:22  * toothrotquit (Ping timeout: 245 seconds)
03:49:58  * petka_quit (Quit: Connection closed for inactivity)
03:51:33  * warehouse13quit (Read error: Connection reset by peer)
03:56:15  * ijrothjoined
03:57:09  * ijrothquit (Client Quit)
04:01:52  * Fishrock123quit (Quit: Leaving...)
04:02:09  * a_lejoined
04:08:15  * avalanche123joined
04:11:51  * iarnajoined
04:19:21  * avalanche123quit (Remote host closed the connection)
04:23:22  * davijoined
04:23:22  * daviquit (Changing host)
04:23:22  * davijoined
04:24:21  * c4milojoined
04:28:19  * avalanche123joined
04:29:12  * a_lequit (Remote host closed the connection)
04:29:13  * c4miloquit (Ping timeout: 255 seconds)
04:29:47  * a_lejoined
04:37:38  * kazuponjoined
04:42:19  * kazuponquit (Ping timeout: 245 seconds)
04:43:30  * kazuponjoined
04:49:52  * avalanche123quit (Remote host closed the connection)
04:54:17  * iarnaquit (Remote host closed the connection)
04:55:33  * iarnajoined
05:10:14  * dsantiagoquit (Ping timeout: 245 seconds)
05:12:13  * dsantiagojoined
05:28:16  * a_le_joined
05:30:29  * a_lequit (Ping timeout: 264 seconds)
05:36:50  * daviquit (Remote host closed the connection)
05:54:19  * kakaouettejoined
05:56:39  * avalanche123joined
05:57:38  * kakaouettequit (Remote host closed the connection)
06:08:55  * avalanche123quit (Remote host closed the connection)
06:13:30  * c4milojoined
06:18:12  * c4miloquit (Ping timeout: 245 seconds)
06:19:42  * rendarjoined
06:20:44  * cosnisjoined
06:25:07  * rmgjoined
06:29:31  * rmgquit (Ping timeout: 258 seconds)
06:51:53  * bhughesquit (Ping timeout: 260 seconds)
06:51:53  * bhughes_joined
06:52:25  * bhughes_changed nick to bhughes
06:54:21  * ijrothjoined
07:00:42  * AlexisMochaquit (Ping timeout: 245 seconds)
07:04:48  * iarnaquit (Remote host closed the connection)
07:05:28  * kazuponquit (Remote host closed the connection)
07:06:26  * kazuponjoined
07:09:16  * avalanche123joined
07:13:35  * avalanche123quit (Ping timeout: 244 seconds)
07:14:15  * iarnajoined
07:19:44  * iarnaquit (Remote host closed the connection)
07:20:17  * brsonquit (Quit: leaving)
07:20:49  * iarnajoined
07:29:31  * bajtosjoined
07:33:51  * dshaw_quit (Quit: Leaving.)
07:36:37  * stagasjoined
07:43:18  * Ldxngxjoined
07:43:32  * Ldxngxquit (Client Quit)
07:43:42  * Ldxngxjoined
07:49:41  * janjongboomjoined
07:49:52  * piscisaureusjoined
07:58:45  * kazuponquit (Remote host closed the connection)
08:02:22  * c4milojoined
08:02:37  * iarnaquit (Read error: Connection reset by peer)
08:03:02  * iarnajoined
08:06:53  * c4miloquit (Ping timeout: 240 seconds)
08:35:54  * cosnisquit (Ping timeout: 255 seconds)
08:39:29  * cosnisjoined
08:39:39  * cosnisquit (Max SendQ exceeded)
08:41:36  * cosnisjoined
08:46:00  * ijrothquit (Quit: Leaving.)
08:48:02  * cosnisquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
08:52:03  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:11:08  * seishunjoined
09:19:21  * bhughesquit (Ping timeout: 260 seconds)
09:22:59  * janjongboomjoined
09:23:00  * janjongboomquit (Client Quit)
09:24:19  * janjongboomjoined
09:33:17  * seishunquit (Remote host closed the connection)
09:39:57  * seishunjoined
09:51:12  * c4milojoined
09:56:07  * c4miloquit (Ping timeout: 244 seconds)
10:03:57  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
10:21:49  * janjongboomjoined
10:24:04  * petka_joined
10:33:45  * Left_Turnjoined
10:38:36  * iarnaquit (Remote host closed the connection)
10:39:10  * iarnajoined
10:43:21  * iarnaquit (Ping timeout: 244 seconds)
10:47:27  * avalanche123joined
10:51:57  * avalanche123quit (Ping timeout: 245 seconds)
11:09:59  * AlexisMochajoined
11:11:49  * bajtosquit (Quit: bajtos)
11:17:47  * Left_Turnquit (Ping timeout: 272 seconds)
11:33:49  * kazuponjoined
11:39:48  * iarnajoined
11:40:11  * c4milojoined
11:42:02  * bajtosjoined
11:45:00  * c4miloquit (Ping timeout: 258 seconds)
11:51:07  * iarnaquit (Ping timeout: 255 seconds)
11:51:32  * jas-quit (Remote host closed the connection)
12:06:04  * kazuponquit (Remote host closed the connection)
12:17:28  * chris_99joined
12:18:12  * AlexisMochaquit (Ping timeout: 244 seconds)
12:21:51  * chris_99quit (Remote host closed the connection)
12:25:26  * Left_Turnjoined
12:28:07  * chris_99joined
12:29:09  * skebciojoined
12:50:42  * kazuponjoined
13:05:28  * bajtosquit (Quit: bajtos)
13:20:03  * M28quit (Read error: Connection reset by peer)
13:20:09  * M28_joined
13:29:05  * c4milojoined
13:31:24  * lance|afkchanged nick to lanceball
13:33:36  * c4miloquit (Ping timeout: 256 seconds)
13:35:30  * iarnajoined
13:36:42  * Fishrock123joined
13:40:01  * iarnaquit (Ping timeout: 255 seconds)
14:36:40  * stagasquit (Ping timeout: 272 seconds)
14:36:54  * iarnajoined
14:42:03  * iarnaquit (Ping timeout: 244 seconds)
14:47:27  * a_le_quit (Remote host closed the connection)
14:48:01  * kenperkinsjoined
14:48:03  * a_lejoined
14:52:01  * tixzjoined
14:52:22  * tixzpart
14:52:44  * a_lequit (Ping timeout: 256 seconds)
14:54:16  * M28_changed nick to M28
14:57:02  * a_lejoined
15:02:00  * AlexisMochajoined
15:14:24  * M28quit (Read error: Connection reset by peer)
15:15:16  * M28joined
15:15:50  * cjbquit (Remote host closed the connection)
15:16:07  <creationix>indutny: would you happen to know why I can’t use req->ptr in uv_fs_t to store my read buffer for uv_fs_read?
15:16:46  <creationix>Currently I create a new void* pointer in my custom struct that lives in req->data. https://github.com/luvit/luv/blob/3e955aac7dc42b362a3034ff4482b33af9312769/src/fs.c#L269-L270
15:16:50  <indutny>I think `req->ptr` could be used only for storing results
15:16:51  * cjbjoined
15:16:52  <indutny>erm
15:16:54  <indutny>loading results
15:17:02  <indutny>so req->ptr
15:17:04  <indutny>req->result
15:17:08  <indutny>are all parts of return value
15:17:23  <indutny>you only have req->data pointer for your own needs, afaik
15:17:50  <creationix>that’s a shame.
15:17:55  * c4milojoined
15:18:15  <creationix>I used to use it for this purpose back in libuv 0.10.x
15:18:24  <creationix>but the new code writes over my pointer now
15:19:03  <creationix>even better would be if as part of the result was it put the read buffer in req->ptr for read operations
15:19:10  <creationix>since it’s a common need to free the pointer onread
15:19:33  <creationix>it already has the pointer in uv_but_t’s base member
15:19:45  <creationix>*uv_buf_t
15:22:20  <indutny>well
15:22:26  <indutny>we have only one place like that
15:22:31  <indutny>and it is alloc_cb/read_cb
15:22:38  <indutny>all other places are either managing memory themselves
15:22:39  * c4miloquit (Ping timeout: 244 seconds)
15:22:40  <indutny>or relying on you
15:22:46  * bhughesjoined
15:22:51  <indutny>it is better than non-similar behavior
15:24:44  * bajtosjoined
15:25:04  <creationix>I’m fine with managing the buffer myself. I prefer that actually. I just want it to give me back the pointer after it’s done so I can continue managing it
15:25:24  <creationix>that’s the only place in all of libuv that I have to store a buffer pointer in my custom place
15:28:19  * importantshockjoined
15:32:42  * importantshockquit (Ping timeout: 258 seconds)
15:37:43  * inolenquit (Quit: Leaving.)
15:41:20  <indutny>creationix: you could still use req->data, right?
15:43:13  <creationix>I am. But req->data already has my custom struct in it for maanaging vm stuff
15:43:30  <creationix>I ended up adding a void* to to my req->data and storing the pointer at req->data->data
15:43:44  <creationix>just seems wasteful when libuv already has the pointer in buf.base
15:43:56  <creationix>and it’s not using req->ptr for anything in that response
15:44:24  <creationix>it would make sense for the result of a fs_read to contain a pointer to the data buffer
15:47:40  <indutny>well, it doesn't make any sense for me API-wise
15:47:49  * inolenjoined
15:47:52  <indutny>ah, wait
15:47:59  <indutny>I just got what you are talking about
15:50:22  * AlexisMochaquit (Ping timeout: 250 seconds)
15:50:23  <creationix>indutny: am I wrong to want this? I’m all for uniform APIs and this is the *only* place in my code where I have to externally track this kind of data pointer.
15:50:49  <creationix>it makes all my uv reqs need one extra pointer just to support uv_fs_read (that or complicate my code and have a special container type for just that one call)
15:52:21  * inolenquit (Ping timeout: 265 seconds)
15:52:36  <creationix>also unrelated, but I see 1.x was merged into master 11 days ago, but I never saw an announcement for 1.x’s release. Is it not done yet?
15:53:47  <indutny>creationix: I think we could make you have some `req->buf` or something like that
15:53:56  <indutny>creationix: we only have some RCs yet, afaik
15:54:13  <creationix>yeah, rc3 was the last I saw, then it was merged to master
15:54:17  <creationix>I guess that means it’s close
15:55:54  <indutny>creationix: I think we have `req->bufs`
15:57:17  <creationix>not in the public API
15:57:55  <creationix>result is a ssize_t, ptr is a void*, and statbuf is a uv_stat_t. That’s all the result fields I believe
15:58:00  <indutny>yeah
15:58:09  <indutny>it is present on both windows/unix
15:58:16  <indutny>could you please file an issue for this?
15:58:29  <creationix>so what does req->bufs contain?
15:59:33  <creationix>also fwiw, uv_read (the stream version) does hand back a uv_buf_t containing the buffer I allocated so there is some precedent there
16:02:11  <rendar>indutny: req->buf would enable one buffer for each request?
16:02:23  * a_lequit (Remote host closed the connection)
16:03:00  * a_lejoined
16:03:09  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:03:29  * a_lequit (Read error: Connection reset by peer)
16:05:30  * janjongboomjoined
16:06:05  * rmgjoined
16:07:04  <creationix>indutny: https://github.com/joyent/libuv/issues/1557
16:07:20  <indutny>rendar: req->bufs
16:07:22  <creationix>I’m not entirely sure what the best solution is since in the general case there can be more than one buffer
16:07:30  <indutny>it contains array of buffers
16:07:36  <indutny>obviously :)
16:07:37  <rendar>indutny: i see
16:07:50  <creationix>I guess exposing bufs as public might help, especially if you also exposed nbufs (assuming there is such a member as well)
16:08:00  <indutny>yeah
16:08:04  <indutny>there is one
16:08:09  <rendar>indutny: hmm array? maybe linked lists would work better for buffers?
16:08:20  <indutny>rendar: nope, it is array
16:08:25  <rendar>ok
16:08:26  <creationix>I’m always a fan of null terminated arrays
16:08:26  <indutny>this is how we handle it internally
16:08:53  <creationix>but arrays with known lengths works too
16:12:19  <rendar>i was refering to a struct like: | prev | next | ... buffer ... |
16:13:34  * avalanche123joined
16:13:59  <creationix>rendar: yeah, I think linked list is overkill and uses too much ram
16:14:17  <creationix>this API lives in some pretty tight loops
16:15:48  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:18:18  * avalanche123quit (Ping timeout: 256 seconds)
16:20:54  <rendar>creationix: i see
16:21:51  <rendar>creationix: but for example you can have an intrusive linked list, so you have a chunk of memory which is the buffer, less size of 2 pointers
16:25:29  * octetcloudjoined
16:25:29  * octetcloudquit (Client Quit)
16:26:17  * octetcloudjoined
16:27:11  * octetcloudquit (Client Quit)
16:28:46  * Ralithquit (Ping timeout: 272 seconds)
16:32:38  <creationix>rphillips: I think cmake is faster than gyp
16:32:46  * a_lejoined
16:33:10  * imzyxwvujoined
16:33:12  <creationix>oops, wrong channel
16:34:18  <rphillips>i agree
16:34:56  <creationix>but yeah, luvi seems to build much faster than legacy luvit on travis
16:35:55  <imzyxwvu>did you meant me joined a wrong channel?
16:40:07  <imzyxwvu>I want to do udp recvfrom with libuv to receive a packet from a specified peer. Please tell me how to. Thanks.
16:40:27  * dap_joined
16:43:51  <creationix>imzyxwvu: no, you’re welcome here. My previous comment was meant for the #luvit channel
16:45:37  * dshaw_joined
16:46:35  <imzyxwvu>creationix: I see, and it doesn't matter
16:48:04  * bajtosquit (Quit: bajtos)
16:48:48  <creationix>imzyxwvu: you’ve seen the new libuv docs site right? http://docs.libuv.org/en/latest/udp.html
16:48:59  <creationix>it helped me a lot understand enough to write my new udp bindings
16:50:47  <imzyxwvu>A server will send a packet to my computer and I can receive with LuaSocket's receivefrom. But with libuv, I didn't found any way to specify the peer address.
16:51:35  * Drajwerjoined
16:52:01  <creationix>imzyxwvu: maybe filter by address in the on_recv_cb?
16:52:59  <imzyxwvu>I created a UDP handle and immedately called uv_udp_recv_start. I didn't got any thing with on_recv_cb.
16:53:30  <creationix>do you need to bind to a specefic port to hear the messages? By default it will pick a random port if you don’t bind first
16:54:52  <imzyxwvu>I don't need to bind a port. I need to specify the remote address by a parameter of recvfrom.
16:56:53  <creationix>hmm, in the recvfrom system call, you specify the source address, but not in libuv
16:57:44  * stagasjoined
16:59:08  <imzyxwvu>thanks. I will look for a libuv way to do that.
16:59:18  * imzyxwvupart
16:59:42  <creationix>and he’s gone. I was going to link to the dhcp example in http://nikhilm.github.io/uvbook/networking.html
17:00:53  * imzyxwvujoined
17:01:28  <creationix>imzyxwvu: checkout http://nikhilm.github.io/uvbook/networking.html for some more udp examples (It’s the older interface, but not too different)
17:03:15  <Drajwer>how can I execute function from event loop? is uv_async_t good to do it?
17:03:32  <Drajwer>in boost.asio I have something like io_service.post([]() { });
17:03:51  <imzyxwvu>creationix: It seems not to be what I need currently because it binded the broadcast address. Also thanks.
17:04:30  * Ralithjoined
17:05:13  <Drajwer>or do something like `process.nextTick` from nodejs?
17:08:11  <imzyxwvu>Drajwer: uv_run(UV_RUN_ONCE); does the event polling for just one time. UV_IDLE is also a good choosen.
17:09:37  * jgijoined
17:09:46  * a_lequit (Remote host closed the connection)
17:10:22  * a_lejoined
17:11:01  <Drajwer>imzyxwvu: what do you mean?
17:11:21  * bajtosjoined
17:11:41  <imzyxwvu>Drajwer: Do you want to execute a function each time libuv does the event polling?
17:12:09  <Drajwer>hmm not exacly
17:12:19  <Drajwer>I want to wake up the event loop
17:12:21  <Drajwer>with my function to be called
17:15:47  <imzyxwvu>Drajwer: I don't exactly know want you meant. uv_run wakes up the event loop, and then your function should be called immediatly?
17:16:06  * AlexisMochajoined
17:18:22  <Drajwer>imzyxwvu: but uv_run blocks?
17:18:54  <imzyxwvu>uv_run(UV_RUN_NOWAIT) doesn't block.
17:19:09  <Drajwer>ok
17:21:19  <Drajwer>hmm so how I should queue my function to be executed after event loop is waked up?
17:21:39  <Drajwer>and is it really safe to call uv_run(UV_RUN_NOWAIT) from the same thread that executes uv_run(UV_RUN_DEFAULT) ?
17:21:52  * piscisaureusquit (Ping timeout: 255 seconds)
17:23:43  * octetcloudjoined
17:24:06  <creationix>Drajwer: I call nested uv_run all the time. It’s been safe in my usage
17:24:13  <creationix>the inner one just blocks the outer one
17:24:33  * octetcloudquit (Client Quit)
17:24:34  <Drajwer>cool
17:25:08  <creationix>though I don’t do that in a tight loop, mostly to wait for unit tests to complete before starting the next
17:25:52  * a_lequit (Read error: Connection reset by peer)
17:26:18  * a_lejoined
17:26:19  <Drajwer>and btw
17:26:57  <Drajwer>uv handles should be valid as long as the event loop is valid?
17:27:33  <imzyxwvu>Drajwer: uv_run should be not called in different threads, I think.
17:27:36  <creationix>assuming they aren’t closed
17:27:47  <creationix>imzyxwvu: correct, not for the same loop
17:27:48  * octetcloudjoined
17:28:17  * c4milojoined
17:28:21  * c4miloquit (Remote host closed the connection)
17:31:43  * kazuponquit (Remote host closed the connection)
17:43:50  * lanceballchanged nick to lance|afk
17:44:49  * a_lequit (Read error: Connection reset by peer)
17:45:08  * a_lejoined
18:03:21  * lance|afkchanged nick to lanceball
18:08:02  * rendar_joined
18:09:11  * iarnajoined
18:11:20  * chris_99quit (Remote host closed the connection)
18:11:50  * rendarquit (Ping timeout: 256 seconds)
18:12:09  * chris_99joined
18:13:37  * iarnaquit (Ping timeout: 255 seconds)
18:24:12  <tjfontaine>AlexisMocha: having fun
18:24:36  <AlexisMocha>tjfontaine: yep!
18:24:44  <tjfontaine>:)
18:25:07  <AlexisMocha>i should be able to deliver something early next week
18:25:13  <tjfontaine>k
18:25:49  <AlexisMocha>tjfontaine: while i have you here...
18:26:10  <AlexisMocha>the job i am building needs to push some temporary state to the origin repo
18:26:26  <AlexisMocha>do you have any issue on whether it's a branch or a tag that will get updated?
18:27:14  * cndquit (Quit: Connection closed for inactivity)
18:28:03  <tjfontaine>a branch I would prefer, what's the temporary state does it need?
18:28:15  <tjfontaine>can you explain further?
18:29:10  * iarnajoined
18:29:39  <AlexisMocha>i have a subproject that's encapsulating the merge/rebase logic, because I don't want to repeat that everywhere.
18:29:57  <tjfontaine>ok
18:30:08  <AlexisMocha>So the objective is to push a commit to origin, and pass the commit hash to the subprojects which are going to test it
18:30:25  <AlexisMocha>but there's no way to push a detached commit, so I need to push some ref
18:30:30  <AlexisMocha>either a tag or a branch
18:30:42  <tjfontaine>you'll end up force pushing the branch constantly, right?
18:30:47  <tjfontaine>or uniq branch?
18:30:59  <AlexisMocha>it can be done either way
18:31:09  <tjfontaine>if it's going to be forcing I would rather a tag
18:31:12  <AlexisMocha>i'd rather force push, so that if a job gets killed we don't end up with dangling branches
18:31:35  <tjfontaine>I just wonder what happens if its racey?
18:31:53  <AlexisMocha>so if someone else fetches --tags and then pushes --tags and in the meantime the tag has been updated, will it fail?
18:31:55  <tjfontaine>if a slaves executors are full, and a new job comes in
18:31:58  * jgiquit (Quit: jgi)
18:32:24  * jgijoined
18:32:29  <AlexisMocha>like i said, the ref is only used to push the commit. then we pass the commit hash to the slaves, not the ref
18:33:08  <AlexisMocha>in fact we could delete the ref immediately
18:33:25  <AlexisMocha>maybe i'll do that
18:34:03  <tjfontaine>ok
18:34:05  * ijrothjoined
18:34:28  * kriskowalquit (Quit: kriskowal)
18:38:51  * janjongboomjoined
18:39:13  * kriskowaljoined
18:46:24  * chris_99quit (Quit: Ex-Chat)
18:48:33  * yunongjoined
19:02:29  * kriskowalquit (Quit: kriskowal)
19:03:48  * avalanche123joined
19:06:56  * bajtosquit (Quit: bajtos)
19:13:27  * piscisaureusjoined
19:20:52  * jgiquit (Quit: jgi)
19:22:24  * jgijoined
19:22:36  * jgiquit (Client Quit)
19:23:22  * c4milojoined
19:25:31  * kenperkinsquit (Remote host closed the connection)
19:25:32  * brsonjoined
19:29:40  * avalanche123quit (Remote host closed the connection)
19:29:46  * brsonquit (Client Quit)
19:29:55  * brsonjoined
19:33:31  * avalanche123joined
19:37:57  * lanceballchanged nick to lance|afk
19:39:29  * dshaw_quit (Quit: Leaving.)
19:40:31  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
19:45:42  * piscisaureusquit (Ping timeout: 258 seconds)
19:52:56  * jgijoined
19:55:14  * kriskowaljoined
19:59:05  * chris_99joined
20:00:32  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
20:05:54  * avalanche123quit (Remote host closed the connection)
20:09:22  * avalanche123joined
20:10:00  * a_lequit (Remote host closed the connection)
20:10:38  * a_lejoined
20:10:46  * a_lequit (Remote host closed the connection)
20:11:28  * a_lejoined
20:11:30  * avalanche123quit (Remote host closed the connection)
20:12:57  * avalanche123joined
20:20:15  * jgiquit (Quit: jgi)
20:25:03  * iarnaquit (Remote host closed the connection)
20:29:57  * iarnajoined
20:32:43  * avalanche123quit (Remote host closed the connection)
20:34:42  * a_lequit (Remote host closed the connection)
20:35:35  * avalanche123joined
20:37:03  * a_lejoined
20:37:52  * avalanche123quit (Remote host closed the connection)
20:38:03  * avalanche123joined
20:46:54  * importantshockjoined
20:51:30  * jgijoined
20:57:51  * Fishrock123quit (Remote host closed the connection)
21:02:02  * jgiquit (Quit: jgi)
21:02:15  * kenperkinsjoined
21:03:33  * jgijoined
21:05:02  * iarnaquit (Remote host closed the connection)
21:13:08  <chrisdickinson>made a thing for community bug triage for node, for those interested: https://nodebug.me/
21:16:37  <jgi>chrisdickinson: just tried it, I think it’s great! Thank you very much!
21:16:46  <chrisdickinson>thanks!
21:16:48  * a_lequit (Remote host closed the connection)
21:17:37  * avalanche123quit (Remote host closed the connection)
21:18:32  * avalanche123joined
21:19:15  <jgi>chrisdickinson: and it looks great :)
21:20:02  <creationix>chrisdickinson: I did one, it was fun
21:21:07  * importantshockquit (Remote host closed the connection)
21:21:41  * importantshockjoined
21:25:09  * Fishrock123joined
21:25:24  * hueniversequit (Ping timeout: 255 seconds)
21:26:20  * importantshockquit (Ping timeout: 265 seconds)
21:26:48  * rmgquit (Remote host closed the connection)
21:34:35  <chrisdickinson>thanks :D
21:38:32  * kriskowalquit (Quit: kriskowal)
21:40:40  * a_lejoined
21:40:58  * kriskowaljoined
21:45:50  <tjfontaine>chrisdickinson: cute
21:49:09  <tjfontaine>chrisdickinson: where does the data go? :)
21:49:18  <chrisdickinson>right now, into postgres
21:49:24  <tjfontaine>I mean who consumes it?
21:49:25  <chrisdickinson>the goal is to put up a public api
21:49:27  <chrisdickinson>right now, me
21:49:36  <tjfontaine>k well I closed an issue thanks to it ;)
21:49:47  <tjfontaine>I've been begging for this for a while, thanks for solving it
21:49:53  <chrisdickinson>no problem!
21:50:02  <chrisdickinson>already 21 or so responses
21:50:21  <chrisdickinson>it'll grab multiple responses per issue, too.
21:50:30  <seishun>got my own PR on the first try
21:50:42  <chrisdickinson>haha
21:50:58  <tjfontaine>ready for @nodejs to retweet it?
21:51:10  <tjfontaine>or would you rather me hold off?
21:51:17  <chrisdickinson>seems to be holding up thus far
21:51:19  <chrisdickinson>so, sure!
21:51:24  * chrisdickinsoncrosses fingers
21:51:54  <chrisdickinson>thanks!
21:54:49  <tjfontaine>rut roh :)
21:58:39  * c4miloquit (Remote host closed the connection)
21:59:25  * AvianFlujoined
21:59:48  <chrisdickinson>hm, odd
22:01:10  * rmgjoined
22:01:19  * piscisaureusjoined
22:07:43  * ijrothquit (Quit: Leaving.)
22:11:51  * octetcloudquit (Ping timeout: 244 seconds)
22:14:58  <chrisdickinson>found one issue!
22:17:26  <tjfontaine>:)
22:22:41  <chrisdickinson>fixed one issue.
22:22:56  <chrisdickinson>i was too generous with the "NOT NULL"'s :)
22:25:37  * AvianFluquit (Ping timeout: 255 seconds)
22:26:58  * avalanche123quit (Remote host closed the connection)
22:29:09  * avalanche123joined
22:34:10  <qard-appneta>I triaged a bunch of issues. Pretty handy little tool. :)
22:35:09  <qard-appneta>I always wished github had some feature to suggest labels to add to issues.
22:35:16  <qard-appneta>That'd be super handy for triaging.
22:36:00  <qard-appneta>Or report an issue as a duplicate and/or irrelevant.
22:39:20  <seishun>I'm not sure how useful the user-provided triages are going to be though
22:44:47  <qard-appneta>For many issues, the answers aren't really obvious. But there are certainly many duplicates and old, no longer relevant, issues.
22:45:21  * dshaw_joined
22:46:52  * Fishrock123quit (Remote host closed the connection)
22:49:27  * kriskowalquit (Quit: kriskowal)
22:57:45  <tjfontaine>I got one that was 3 years old on 0.6
22:57:53  <tjfontaine>well actually 0.5.6
22:58:23  * AlexisMochaquit (Ping timeout: 240 seconds)
22:59:22  <qard-appneta>The oldest issue is 4 years old today, and has several duplicates since. https://github.com/joyent/node/issues/388
22:59:31  <qard-appneta>oldest open issue
23:00:10  <tjfontaine>taht's because it's got the wrong name
23:00:13  <tjfontaine>it's actually scandir
23:00:15  <tjfontaine>self: demerit
23:00:17  * a_lequit (Remote host closed the connection)
23:02:29  <qard-appneta>If you follow the references, there's a whole deep rabbit hole of them.
23:02:31  * chris_99quit (Ping timeout: 265 seconds)
23:02:47  <qard-appneta>A bunch seem to be closed already, but not all.
23:03:51  * chris_99joined
23:04:42  <tjfontaine>linked it with jgi's pr
23:09:39  <chrisdickinson>tjfontaine: oh, maybe also of note, this can accept multiple repos to select bugs from
23:09:55  <tjfontaine>sounds good, add libuv?
23:10:12  * toothrotjoined
23:11:04  * seishunquit (Ping timeout: 255 seconds)
23:11:59  <tjfontaine>chrisdickinson: I would be tickled pink if this knew who owners/collaborators were, and allowed me to keep state on triaged or not (by an owner)
23:12:15  <tjfontaine>I can give you a list a mile long of why we need this to be better than github
23:13:21  <qard-appneta>Github issues are kind of awful. I could rant about it for hours. >.>
23:13:54  <tjfontaine>me as well
23:13:56  <tjfontaine>self: demerit
23:14:42  * c4milojoined
23:14:43  <qard-appneta>Well...awful is maybe a strong word, but there's certainly a lot of missed potential.
23:15:11  <tjfontaine>they don't care about us, we should just accept it
23:15:22  <chrisdickinson>maybe of note: it uses different credentials to talk to github than it does to register users; it would be relatively easy to get it to the point that we could allow for community-contributed labels, etc
23:16:12  <tjfontaine>sure, for now I just want to fill the gaps for us :)
23:17:18  <chrisdickinson>i'm going to wait over the weekend for libuv,
23:17:21  <chrisdickinson>i'd like to hone the questions a bit
23:17:54  <tjfontaine>squirtinly
23:24:00  * wolfeidauquit (Remote host closed the connection)
23:30:23  * importantshockjoined
23:35:06  * rendar_quit
23:36:27  * importantshockquit (Remote host closed the connection)
23:37:01  * importantshockjoined
23:37:02  * dshaw_quit (Quit: Leaving.)
23:41:14  * importantshockquit (Ping timeout: 244 seconds)
23:46:26  * stagasquit (Ping timeout: 264 seconds)
23:52:55  * a_lejoined
23:54:11  * iarnajoined
23:56:21  * kriskowaljoined
23:57:57  * iarnaquit (Remote host closed the connection)
23:58:34  * c4miloquit (Remote host closed the connection)
23:59:28  * kriskowalquit (Client Quit)