00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:11:42  * thlorenzjoined
00:25:10  * rendarquit
00:25:29  * kellabytejoined
00:29:32  * jgiquit (Quit: jgi)
00:32:00  * rmgjoined
00:36:40  * rmgquit (Ping timeout: 256 seconds)
00:37:01  * \toothrotjoined
00:37:19  * toothrotquit (Ping timeout: 245 seconds)
00:42:55  * jgijoined
01:18:05  * AlexisMochaquit (Ping timeout: 252 seconds)
01:21:48  * thlorenzquit (Remote host closed the connection)
01:28:43  * thlorenzjoined
01:29:01  * maxkorpquit (Quit: ZNC - 1.6.0 - http://znc.in)
01:29:58  * \toothrotquit (Ping timeout: 272 seconds)
01:39:22  * toothrotjoined
01:54:08  * thlorenzquit (Remote host closed the connection)
02:05:54  * thlorenzjoined
02:10:43  * thlorenzquit (Remote host closed the connection)
02:13:59  * nickleeflyjoined
02:22:37  * Left_Turnquit (Remote host closed the connection)
02:59:38  * tylerantonquit (Quit: tyleranton)
03:01:44  * jgiquit (Quit: jgi)
03:02:41  * jgijoined
03:03:42  * jgiquit (Client Quit)
03:05:53  * saghulquit (Ping timeout: 250 seconds)
03:06:51  * saghuljoined
03:11:38  * thlorenzjoined
03:16:43  * thlorenzquit (Ping timeout: 265 seconds)
03:17:42  * jgijoined
03:23:24  * jgiquit (Quit: jgi)
03:26:04  * toothrotquit (Ping timeout: 245 seconds)
04:58:20  * saghulquit (Ping timeout: 272 seconds)
04:58:52  * saghuljoined
05:00:43  * thlorenzjoined
05:05:16  * thlorenzquit (Ping timeout: 256 seconds)
05:34:46  * AlexisMochajoined
05:36:58  * rmgjoined
05:41:43  * rmgquit (Ping timeout: 265 seconds)
05:58:34  * seishunjoined
06:16:16  * jgijoined
06:44:23  * kellabytequit (Quit: Connection closed for inactivity)
06:49:30  * thlorenzjoined
06:54:04  * thlorenzquit (Ping timeout: 256 seconds)
07:22:01  * seishunquit (Ping timeout: 264 seconds)
07:26:37  * bajtosjoined
07:27:29  * bajtosquit (Client Quit)
07:27:33  * jgiquit (Quit: jgi)
07:48:09  * jgijoined
07:51:37  * trafalgarxjoined
07:54:29  <trafalgarx>Hi guys. Can i call uv_write many times or need wait for cb and call it sequentially?
07:54:39  <trafalgarx>On TCP connection
07:57:38  * a3fjoined
07:58:27  * jgiquit (Quit: jgi)
08:10:57  * AlexisMochaquit (Ping timeout: 252 seconds)
08:18:32  * thlorenzjoined
08:20:50  * rmgjoined
08:22:05  * AvianFluquit (Ping timeout: 246 seconds)
08:23:05  * thlorenzquit (Ping timeout: 244 seconds)
08:29:44  * SergeiRNDjoined
08:33:54  <saghul>txdv: no and a while ago
08:34:03  <saghul>trafalgarx: you can call it many times
08:37:24  * roxlujoined
08:39:22  <txdv>saghul: i figured it out myself after a while
08:39:37  <txdv>even had that documented in my readme of my bindings
08:39:49  <txdv>but I forgot!
08:41:53  <trafalgarx>saghul: but in this case i got valgrind error, Invalid read of size 8 Address 0x18 is not stack'd, malloc'd or (recently) free'd 1: uv__write in stream.c:828
08:54:49  <saghul>trafalgarx: the memory needs to be valid until the callback kicks
08:55:11  <saghul>and you can't reuse requests until they are finished
08:55:28  <saghul>but you can create new requests and call uv_write many times
09:01:36  * benjamingrjoined
09:02:18  * a3fquit (Ping timeout: 265 seconds)
09:02:40  * a3f_joined
09:04:44  * a3f_changed nick to a3f
09:08:11  <trafalgarx>saghul: this is what I do, but got this error. maybe I have problem in my code. thanks.
09:10:33  * a3fquit (Quit: ChatZilla 0.9.91.1 [Firefox 36.0.4/20150320202338])
09:13:59  * a3fjoined
09:18:35  <txdv>saghul: I don't understand the ffi links
09:19:20  <txdv>saghul: do you think that all error codes between the different systems are equal?
09:19:26  <txdv>like linux, macosx, solaris, bsd?
09:21:16  * a3fpart
09:35:15  <saghul>txdv: the ones defined by POSIX yes, but there are some edge cases IIRC
09:35:18  <saghul>like EHOSTDOWN
09:36:26  <txdv>anyway uv_err_name solves the problem, I didn't notice it exists, thanks saghul
09:38:32  <saghul>you're welcome!
09:40:41  <txdv>lol i actually have that thing already exposed
09:48:04  * Left_Turnjoined
09:48:28  <txdv>stupid me
10:04:24  * thlorenzjoined
10:08:50  * thlorenzquit (Ping timeout: 246 seconds)
10:26:25  * iamarootjoined
10:26:33  <iamaroot>hi guy
10:26:34  <iamaroot>s
10:28:17  <trafalgarx>saghul: is right that write reqs queued? where I can see write requset queue len?
10:29:30  <saghul>trafalgarx: yes, they are queued, you can query the queued bytes like this: http://docs.libuv.org/en/latest/stream.html#c.uv_stream_t.write_queue_size
10:30:40  * Left_Turnquit (Remote host closed the connection)
10:30:57  * rmgquit (Remote host closed the connection)
10:35:40  * iamarootquit (Quit: Page closed)
10:36:12  * Left_Turnjoined
11:00:55  * Mark___joined
11:01:44  <Mark___>hello, I'm back (tjfontain) with more questions about android. I'm sure you're delighted :-)
11:01:55  <Mark___>tjfontaine, even
11:02:58  <Mark___>I was in on Thursday or Friday, my android build was passing OS X flags in an android compile
11:03:09  * wolfeidauquit (Ping timeout: 245 seconds)
11:03:13  <Mark___>so you suggested I try the autotools route
11:03:26  <Mark___>I've done this and can get things compiling
11:03:36  <Mark___>but unfortunately make check does not pass
11:04:12  <Mark___>CC test/test_run_tests-runner-unix.o CCLD test/run-tests test/test-signal-multiple-loops.c:248: error: undefined reference to 'uv__pthread_sigmask' collect2: error: ld returned 1 exit status make[1]: *** [test/run-tests] Error 1 make: *** [check-am] Error 2
11:05:59  <Mark___>I have a test program in iOS (using libuv with libcurl -- works fine on iOS) that I've ported to Android
11:06:32  <Mark___>when I run my test program using this android binary, I don't get any libuv callbacks
11:06:35  * wolfeidaujoined
11:06:38  * a3fjoined
11:06:41  <Mark___>the only functionality that seems to work is the uv idle loop
11:06:54  <Mark___>any ideas what I can do to fix this up?
11:07:01  <Mark___>any ideas appreciated, cheers
11:14:47  * Mark__quit (Quit: Page closed)
11:15:19  <Mark___>nice, chrome opened two windows (I'm still here)
11:26:12  * Mark__joined
11:26:20  * Mark___quit (Quit: Page closed)
11:31:32  * rmgjoined
11:35:32  <trafalgarx>saghul: How do you think, what can be cause of this problem: Address 0x18 is not stack'd, malloc'd or (recently) free'd 1: uv__write в <a href="file:///home/ravone/builds/libuv-1.4.0/src/unix/stream.c:828" >/home/ravone/builds/libuv-1.4.0/src/unix/stream.c:828</a>
11:36:21  * rmgquit (Ping timeout: 250 seconds)
11:41:57  <saghul>trafalgarx: do you have some test code?
11:44:53  * nickleeflyquit (Quit: Connection closed for inactivity)
11:53:13  * thlorenzjoined
11:53:50  * saghulquit (Ping timeout: 246 seconds)
11:55:54  * saghuljoined
11:57:48  * thlorenzquit (Ping timeout: 256 seconds)
12:30:44  * Tux64joined
12:44:06  * toothrotjoined
13:09:03  * thlorenzjoined
13:10:34  * saghulquit (Ping timeout: 264 seconds)
13:13:34  * thlorenzquit (Ping timeout: 264 seconds)
13:15:05  * toothrotquit (Ping timeout: 265 seconds)
13:17:48  * saghuljoined
13:20:51  * rmgjoined
13:22:19  * saghulquit (Ping timeout: 245 seconds)
13:24:02  * saghuljoined
13:25:08  * rmgquit (Ping timeout: 246 seconds)
13:33:47  * thlorenzjoined
13:36:56  * chris_99joined
13:37:41  * thlorenzquit (Remote host closed the connection)
13:55:45  * a3fquit (Quit: My Mac has gone to sleep. ZZZzzz…)
14:02:35  * a3fjoined
14:16:09  * thlorenzjoined
14:16:11  * AvianFlujoined
14:20:35  * Fishrock123joined
14:20:43  * WalrusPonyquit (Read error: Connection reset by peer)
14:24:43  * WalrusPonyjoined
14:30:19  * a3fquit (Quit: My Mac has gone to sleep. ZZZzzz…)
14:48:52  * jgijoined
14:55:17  * rmgjoined
14:59:37  * a3fjoined
15:06:29  * SergeiRNDquit (Quit: Leaving.)
15:08:48  * chris_99quit (Quit: Ex-Chat)
15:18:49  * lanceballchanged nick to lance|afk
15:18:52  * lance|afkchanged nick to lanceball
15:23:32  * jgiquit (Quit: jgi)
15:32:00  * octetcloudjoined
15:47:12  * rendarjoined
16:04:17  <Mark__>anyone built on droid recently? I'm having problems: https://groups.google.com/forum/#!topic/libuv/l0gqS58CErE
16:10:27  * qard_quit (Remote host closed the connection)
16:14:28  * jgijoined
16:18:25  * a3fquit (Quit: My Mac has gone to sleep. ZZZzzz…)
16:30:29  * seishunjoined
16:40:27  * AlexisMochajoined
16:50:11  * kellabytejoined
16:53:52  <MI6>joyent/node: Saúl Ibarra Corretgé refs/tags/jenkins-accept-pull-request-temp * 2e66c50 : watchdog: fix timeout for early polling return - http://git.io/hFhP
16:54:56  <MI6>joyent/node: Saúl Ibarra Corretgé refs/tags/jenkins-accept-commit-temp * a6dda18 : watchdog: fix timeout for early polling return - http://git.io/hFjG
16:55:13  * thlorenzquit (Remote host closed the connection)
17:01:43  * thlorenzjoined
17:03:38  * brsonjoined
17:05:55  * SergeiRNDjoined
17:15:45  * piscisaureusjoined
17:16:07  <piscisaureus>petka__: I can help you make the libuv-win changes if that helps
17:16:20  <petka__>piscisaureus sure
17:16:25  <petka__>btw that handle cast was silly mistake :D
17:16:40  <piscisaureus>petka__: of course I prefer if you do it yourself :)
17:16:41  <petka__>I misremembered how similar code did it before
17:16:56  <petka__>just grepped and they are all calling get_fsfhandle indeed
17:17:06  <petka__>osf*
17:17:08  <piscisaureus>petka__: the fd / handle duality is really annoying
17:17:39  <piscisaureus>petka__: we're also making the assumption that _get_osfhandle(0) == GetStdHandle(STD_INPUT_HANDLE) which should usually be true but it doesn't have to be true...
17:18:15  <petka__>yea
17:18:21  <petka__>there is another constant
17:19:08  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
17:19:23  <petka__>forgot what it was though
17:21:40  <petka__>fs_close is always called with unix-style fd though?
17:21:55  <petka__>at least io.js does just call it like fs_close(1) to close stdout
17:22:18  <petka__>so in this case we could do <= 2 check
17:22:21  * SergeiRNDquit (Quit: Leaving.)
17:24:04  <piscisaureus>petka__: yeah. Disk io uses file descriptors and streams io uses handles. I know, it's inconsistent.
17:25:14  <piscisaureus>petka__: sometimes a stream is also created from a filedescriptor. We really ought to just remember the original fd (and then use _close() to close it).
17:25:48  <petka__>sure
17:25:50  <piscisaureus>petka__: right now we close the handle directly, but the slot in the fd table remains reserved (and now is associated with a closed handle)
17:25:55  <petka__>I don't really mind if you take over btw
17:26:12  <petka__>I forced pushed the <= 2 fix
17:28:27  * inolenjoined
17:29:25  * thlorenzquit (Remote host closed the connection)
17:31:12  * octetcloudquit (Read error: Connection reset by peer)
17:31:40  <petka__>I basically have no idea what I'm doing :)
17:32:39  * octetcloudjoined
17:36:00  * SergeiRNDjoined
17:47:00  * thlorenzjoined
17:49:05  * thlorenzquit (Remote host closed the connection)
17:53:56  * SergeiRNDquit (Quit: Leaving.)
17:58:02  * SergeiRNDjoined
17:58:39  * SergeiRNDquit (Client Quit)
18:05:42  * SergeiRNDjoined
18:10:13  <trafalgarx>saghul: my mistake. I call uv_write from other thread. now I use uv_async_t and GAsyncQueue form GLib for thread communication. thanks. :)
18:15:47  * avalanche123joined
18:20:03  <piscisaureus>trevnorris: just so that I understand your concerns properly - why wouldn't it be possible to clean up c++ resources from a cleanup handler?
18:21:54  * miles1joined
18:22:13  <miles1>could any libuv developer explain to me this statement in the doc?
18:22:16  <miles1>"Using uv_poll_t for any other purpose is not recommended; uv_tcp_t, uv_udp_t, etc. provide an implementation that is faster and more scalable than what can be achieved with uv_poll_t, especially on Windows."
18:22:59  <miles1>how is it slower than uv_udp_t functions? is it because uv_poll_t doesnt use iocp or something?
18:30:02  * octetcloudquit (Ping timeout: 252 seconds)
18:49:14  * thlorenzjoined
18:50:10  * octetcloudjoined
18:50:20  * a3fjoined
19:01:45  * thlorenzquit (Remote host closed the connection)
19:01:50  * SergeiRNDquit (Quit: Leaving.)
19:02:01  * thlorenzjoined
19:04:18  * gnosticationquit (*.net *.split)
19:04:28  * pquernaquit (*.net *.split)
19:04:35  * gnosticationjoined
19:04:37  * pquernajoined
19:10:48  * SergeiRNDjoined
19:13:06  * roxlujoined
19:16:00  * avalanche123quit (Remote host closed the connection)
19:16:29  * avalanche123joined
19:17:14  <MI6>joyent/node: Shigeki Ohtsu v0.10 * 4b69c72 : openssl: fix keypress requirement in apps on win32 (+6 more commits) - http://git.io/hNne
19:22:08  * avalanche123quit (Ping timeout: 246 seconds)
19:27:02  * a3fquit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:29:39  * stagasjoined
19:30:19  * a3fjoined
19:35:56  * lanceballchanged nick to lance|afk
19:37:05  * SergeiRNDquit (Quit: Leaving.)
19:37:25  * chris_99joined
19:44:36  <piscisaureus>miles1: it's slower because because there is a fast mode and a slow mode (slow mode happens when the user has LSPs installed)
19:44:51  <piscisaureus>miles1: slow mode is really slow. It uses 2 threads per socket.
19:45:17  <piscisaureus>miles1: also overlapped mode requires less syscalls.
19:46:52  <txdv>piscisaureus!
19:47:00  <MI6>joyent/node: Saúl Ibarra Corretgé refs/tags/jenkins-accept-commit-temp * 7e9d2f8 : watchdog: fix timeout for early polling return - http://git.io/hN2r
19:47:20  <piscisaureus>txdv!
19:47:22  <piscisaureus>sup?
19:48:34  <txdv>http://logs.nodejs.org/libuv/2015-03-22#23:18:35.695
19:48:49  <txdv>you were doing windows_epoll in 2012
19:49:05  <txdv>someone asked if it where possible implemented something similar to the backend api
19:53:48  * stagasquit (Ping timeout: 256 seconds)
19:54:47  <miles1>piscisaureus: ill ask you then what initially i was looking to do. i want to use libuv (we use it for 'real' udp traffic also) to send icmp packets for diverse network analysis that complements my udp traffic. anyways, point is, how is it possible to use libuv to accomplish such thing so that i dont have to do my own IOCP implementation. can i somewhat send icmp packets with uv_udp_t or im stuck with the uv_poll_t funcs?
19:55:57  <miles1>and if your answer is 'no choice to use uv_poll_t', then, is there a way i can force fast mode or im risking to get something that is ultra slow.
19:56:40  <miles1>anyways, just pointing that out. you guys should have something like uv_raw_t implemented as well for raw sockets, would simplify things considerably for some particular apps.
19:57:41  * lance|afkchanged nick to lanceball
19:57:47  * jgiquit (Quit: jgi)
19:58:53  <piscisaureus>miles1: icmp != udp
19:59:23  <piscisaureus>miles1: you'd have to use SOCK_RAW sockets but windows doesn't allow that
19:59:40  <txdv>only with admin rights
19:59:49  <piscisaureus>not even with admin rights I believe
19:59:57  <piscisaureus>only on windows server I think
20:00:10  <piscisaureus>(so it's basically just an upsell)
20:00:32  <txdv>wtf no pinging on windows
20:00:34  <piscisaureus>miles1: windows has high-level ICMP functions that you can use, but you're on your own a bit - libuv doesn't suppeort those
20:01:00  <piscisaureus>https://msdn.microsoft.com/en-us/library/windows/desktop/aa366050%28v=vs.85%29.aspx
20:01:16  <txdv>miles1: have you tried creating a raw socket and feeding it to libuv?
20:01:27  <txdv>have you tried creating a raw socket and just using it without libuv?
20:02:16  <piscisaureus>miles1: I think for ICMP uv_poll would be fine
20:02:18  <miles1>on any win NT if theres admin rights it's possible to use SOCK_RAW
20:02:34  <miles1>but the user has to be in administrator group
20:03:13  <piscisaureus>miles1: if you create the socket and specify the AFD provider explicity (with the appropriate GUID) then uv_poll will be in fast mode
20:03:20  * SergeiRNDjoined
20:03:24  <miles1>anyways, i ofc know udp != icmp, but i wondered if i could hack around libuv's uv_udp_funcs to attempt sending an icmp using raw sockets
20:03:32  <miles1>using uv_udp_open for example
20:03:46  <miles1>to open a previously sat raw socket
20:03:53  <piscisaureus>https://msdn.microsoft.com/en-us/library/windows/desktop/ms740548%28v=vs.85%29.aspx <-- see "limitations on raw sockets"
20:04:02  <piscisaureus>^miles1 txdv
20:05:03  <trevnorris>piscisaureus: not that it isn't possible, just that we have to be careful. what if we allocate before the callback and then free after the callback? since the exception won't allow control to return to C++ we'd loose the pointer to the allocated resource unless we stored it somewhere.
20:06:30  <piscisaureus>trevnorris: the cleanup would probably have to be async though... possibly nextTick and then destroy the c++ object
20:07:29  <trevnorris>piscisaureus: but you see what I'm saying. there are cases where we malloc(), call a callback then immediately free() afterwards. but if an exception is thrown the ability to clean up that pointer is lost.
20:08:18  <piscisaureus>trevnorris: I do see what you're saying. So in any case it shouldn't work that way :)
20:09:05  <piscisaureus>we would want it to be not brittle
20:10:00  <trevnorris>piscisaureus: sounds good to me. if we can guarantee resource cleanup then i'm cool w/ it
20:10:22  <trevnorris>Domenic: so would your implementation allow something like socket.close().then(...) ?
20:10:32  * SergeiRNDquit (Quit: Leaving.)
20:11:12  <Domenic>trevnorris: I think so, not sure what the context is though
20:11:55  <trevnorris>Domenic: i'm trying to figure out how internal resource cleanup would be handled. i.e. var c = close(); /* some time later */ c.then(...);
20:12:13  <Domenic>ah yeah
20:12:14  <trevnorris>would it have to hang onto the internal resources as long as the Promise is still in scope?
20:12:26  <Domenic>no, the promise is just a signaller
20:12:35  <trevnorris>i.e. we have to depend on the GC to tell us when we can free the underlying class
20:13:43  <trevnorris>okay. so we can immediately free the class, and the remaining JS bits will be cleaned up automatically by GC.
20:14:07  <Domenic>yeah sounds right
20:14:23  * kellabytequit (Quit: Connection closed for inactivity)
20:14:40  <trevnorris>how would you set callbacks for errors, etc?
20:14:53  <trevnorris>only way I can figure is for it to look EE-ish.
20:15:41  <MI6>joyent/node: Saúl Ibarra Corretgé v0.12 * 7e9d2f8 : watchdog: fix timeout for early polling return - http://git.io/hNSG
20:16:15  <Domenic>socket.cancel().catch(e => console.error(e))?
20:17:47  <trevnorris>i mean, say you create a socket and I want to be notified about conneciton/close/error/etc. does the streams API allow me to set those in some uniform way like EE does?
20:18:36  <Domenic>reader.closed.catch(e => console.error(e))
20:19:15  <trevnorris>so it would have reader.closed, reader.connection, etc.
20:19:20  <Domenic>if you ever transition to "closed" state, `closed` promise fulfills. If you transition to "errored" state, it rejects. They are mutually-exlusive at-most-once state transitions, so it works well
20:19:36  <Domenic>Hmm no, you wouldn't distinguish
20:19:41  <Domenic>Or if you did, you would do so with error types
20:20:08  <trevnorris>what about connection? for a socket that's only going to happen once, but not for server.
20:20:20  <Domenic>server isn't a stream though
20:20:46  <trevnorris>ah, true. but then would the server be an EE and the connection would be a stream? so they would use two different API styles?
20:20:53  <Domenic>yeah that seems likely
20:21:04  <Domenic>I mean that's how Node does it right?
20:21:41  <trevnorris>well, except it all uses EE style, so there's not mental context switch about how to set the callbacks.
20:21:49  <trevnorris>e.g. server.on('connection' or socket.on('connection'
20:22:05  <Domenic>Mmm but socket.on('connection') is not used by people who want to consume it as a stream
20:22:36  <trevnorris>not exactly. people want to inject themselves into an http stream by getting the inital tcp connection.
20:22:53  <trevnorris>then then hijack the stream so they can rewrite encrypted headers, etc.
20:23:55  <trevnorris>it's basically a trick to inject a transform stream into the pipe before the data reaches the http header parser.
20:24:01  <Domenic>This is a bit old but it was one idea that one guy had for raw socket APIs on streams http://www.w3.org/2012/sysapps/tcp-udp-sockets/
20:24:34  <Domenic>Example here, not updated to async read() http://www.w3.org/2012/sysapps/tcp-udp-sockets/#interface-tcpsocket
20:26:28  <Domenic>Mapping to net.Socket is not too different, it separates readable and writable sides but otherwise is fairly close
20:29:04  * bradleymeckjoined
20:29:04  * piscisaureusquit (Ping timeout: 255 seconds)
20:29:42  * jgijoined
20:30:25  <Domenic>What is net.Socket bytesRead/bytesWritten used for? Seems trivial to add, but unsure what the use case is.
20:30:40  <trevnorris>it's useful for reporting/stats.
20:30:51  * jgiquit (Client Quit)
20:31:02  * bradleymeckquit (Client Quit)
20:31:17  <Domenic>Yeah but why not put it on every stream ever
20:32:13  * avalanche123joined
20:32:16  <trevnorris>I think it should be. just haven't taken the time to implement it more appropriately. :P
20:32:26  * bradleymeckjoined
20:32:29  <trevnorris>but don't know why it hasn't been done yet.
20:32:49  <Domenic>huh ok
20:34:29  <bradleymeck>whats going on? /me is apparently late for the conversation
20:34:50  <trevnorris>just a conversation about how to extend the Streams API to something like net.Socket()
20:35:59  * jgijoined
20:37:41  <bradleymeck>scrollback caught up
20:39:36  <bradleymeck>curious about the resource cleanup, Domenic is there a .close() for Readables, like if I want to stop tailing a file?
20:40:55  <bradleymeck>also how many of these promises are meant to be used by the end user?
20:41:14  <bradleymeck>it seems like some of these internal slots are promises, do they need to be?
20:50:10  <bradleymeck>Domenic: I hope you can understand how we are very very nervous about this if we don't have any profiling and it lands in canary
20:50:24  <bradleymeck>some things can look good in theory but have a bottleneck that breaks things
20:50:59  <bradleymeck>I'm fine with promises etc. being the thing, but I am very nervous that it will stay slow if there is an unseen performance bottleneck from some workflow
20:51:11  <bradleymeck>also a lot of these mandate the use of promises for internal state
20:51:53  <bradleymeck>once things land in a browser it will be hard to change them and if these problems are hidden that may mean some environments won't adopt them
20:56:36  <tjfontaine>it's not clear to me that Readable should have a notion like close, since there may not be a resource associated with it
20:57:05  <trevnorris>tjfontaine: but what's preventing resources to be associated w/ it?
20:57:10  <bradleymeck>what do you do if there is a resource?
20:57:13  * miles1part
20:57:18  <bradleymeck>its easy to have a noop if there is no resource
20:57:48  <tjfontaine>it's a mechanism of inheritence I think, I've been doing some work .. lemme link it
20:58:08  <tjfontaine>https://github.com/joyent/node/compare/v0.12...tjfontaine:strictee
20:58:26  <tjfontaine>it's kind of amusing to write down how you think events are delviered and in what order for node
20:58:33  <tjfontaine>and then be shocked at how it actually happens
20:58:34  * rendarquit (Ping timeout: 245 seconds)
20:59:02  <tjfontaine>https://github.com/joyent/node/commit/f990f2e6acc3abaf003ac0760e48c78fa7e535d5 <-- legit bug, and I'm not sure that this pattern should have ever existed
20:59:20  <tjfontaine>since it's pretty clear you can re-enter here without .destory being true and have a pretty messed up state machine
21:00:36  <bradleymeck>well you can use a promise to wait on .destroy being true
21:00:43  <bradleymeck>in the case of whatwg style apis
21:02:53  <tjfontaine>destroy and close don't necessasrily make sense to me for plain old readable, but they do for things with resources
21:03:14  * jgiquit (Quit: jgi)
21:03:33  * bradleymeckis confused
21:03:49  <bradleymeck>why would you need one for writable and not readable
21:04:03  <bradleymeck>if you have one for writable you are assuming some cleanup needs to occur
21:04:12  <bradleymeck>same as you don't want to leak a fd if you are done reading it
21:04:30  <tjfontaine>in node we have end and finish, one is for readable one is for writable, but close is fired on something that has a resource (but not necessarily for http readables because of socket reuse)
21:05:00  * rendarjoined
21:05:55  <bradleymeck>as long as I get a way to detect when all things consuming a resource are done idc if its in the standard streams
21:05:57  * tylerantonjoined
21:06:04  <bradleymeck>but either both should expect resource, or both should not
21:06:11  <bradleymeck>resources*
21:09:41  <bradleymeck>though idk how we can do a resource cleanup without gc hooks...
21:10:00  <bradleymeck>at least if it is not on standard streams
21:10:29  <tjfontaine>ya, it's not easy to do without support
21:23:10  * lanceballchanged nick to lance|afk
21:23:42  * jeffreydwalterjoined
21:33:37  * jgijoined
21:49:58  * seishunquit (Ping timeout: 256 seconds)
22:01:18  <octetcloud>@tjfontaine: there is no v0.10.37-branch for v0.10.37
22:01:58  <octetcloud>ah, because its called -release, pls ignore me, sorry
22:04:40  <Domenic>bradleymeck: that's not really how APIs work. You don't get to say that an API cannot ship until it is fully optimized. Instead you look to see if there are fundamental design problems that prohibit an optimized version from existing.
22:04:52  <bradleymeck>I don't want optimized
22:04:54  <bradleymeck>I want profiled
22:05:05  <bradleymeck>to check for bottlenecks that are not visible from API surface
22:05:29  <bradleymeck>there is a difference between shipping before being optimized and shipping without investigating
22:05:37  <Domenic>a given implementation's bottlenecks don't really mean anything with regard to the underlying spec
22:05:51  <bradleymeck>workflows
22:05:59  <Domenic>now you're just saying words
22:06:04  <bradleymeck>workflows may be the problem, I'm not just talking v8 running jit on it
22:06:27  <bradleymeck>if I pipe between 2 streams in node for example it is slower than just raw consuming a single stream
22:06:42  <bradleymeck>this starts to compound, and is a problem with how the APIs hook together
22:07:12  <bradleymeck>I'm just wanting a good profiling to go in before it lands
22:07:27  <bradleymeck>when promises landed they pretty much when to unable to be changed
22:07:55  <bradleymeck>I think the same will happen with streams, but streams are far closer tied to resource consumption and needing to be able to both handle performance and resource cleanup
22:07:58  <tjfontaine>abstractions cost though, I mean there's a lot more happening by definition in a piped stream
22:08:07  <bradleymeck>indeed
22:08:26  <bradleymeck>you just want to be sure you can avoid the costly bits if possible
22:08:49  <bradleymeck>I don't want a repeat where we can't change the spec once it lands
22:08:58  <tjfontaine>it's true that constantly re-evaluating the design through out its creation is a good way to identify if there are unexpected work loads
22:11:38  <trevnorris>tjfontaine: but streams are supposed to be a "low level mechanism" to consume data. and if it goes in then many APIs will rely on it. so if the abstraction has undesirable overhead then it needs to be rethought.
22:11:59  <Domenic>piped streams will be faster since they're designed to allow off-main-thread minimal-copy stuff
22:12:06  <Domenic>this is what i mean by look at the design not the implementation
22:12:52  <trevnorris>Domenic: and i'm curious how that couldn't be possible by a different EE streams impl? that's a goal being designed in, but not inheritly magical to the streams API choice, right?
22:13:23  <Domenic>trevnorris: definitely, yeah, it's orthogonal to EE vs. promises vs. callbacks.
22:13:29  <bradleymeck>Domenic: I'm not talking about you need to be fast, just that no strange points look like they are causing more work than they should
22:13:40  <bradleymeck>just like watching nextTick in crypto is amazingly strange
22:14:10  <Domenic>bradleymeck: well, the spec has no strange points that cause more work than it should. so, you are happy?
22:14:18  <bradleymeck>no
22:14:25  <bradleymeck>cause I have no data, just what it appears
22:15:19  <Domenic>well, i mean, you won't be happy until a completely optimized implementation appears to actually prove to you that what appears to be possible is actually possible.
22:15:22  <bradleymeck>appears to be from the spec*
22:15:30  <Domenic>and again, that's just not a realistic way of evolving software
22:15:32  <bradleymeck>I don't care if it takes minutes to download google.com
22:15:53  <bradleymeck>I don't want to see 1000s of task queues on accident in a profiling benchmark
22:16:03  <bradleymeck>microtasks*
22:16:06  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
22:16:13  <bradleymeck>which I'm fine with it being slow, using memory, and all of this
22:16:38  <bradleymeck>I just want to see it out somewhere, doing something, in some measurable manner, that I can reproduce before it goes into a browser which makes it hard to change
22:17:43  <bradleymeck>slow is fine if people don't see any oddities
22:17:43  <Domenic>I feel like I've already explained why that's not going to happen, and why we've already done a lot in the design. So, I guess there's not much else to say. Sorry to disappoint.
22:17:53  <bradleymeck>sure don't test your stuff
22:18:08  <bradleymeck>lets just land it because its only fully optimized or not...?
22:18:30  <trevnorris>saghul: strange issue. I compiled libuv.a to libnub.a using c89. but now when I'm trying to include libnub.a into my C++ project it's giving me a "previous declaration error" for uv_tty_set_mode(). know how to get around that?
22:18:33  <nathan7>…fyi, this conversation is a complete trainwreck
22:18:48  <bradleymeck>probably
22:20:24  <trevnorris>Domenic: i might be missing something, but I don't get how "stream.writable.closed.then()" is an improvement over "stream.on('close'"
22:20:35  <bradleymeck>Domenic: is there anyone else looking at this spec / someone I can get to help build out a benchmark? even if it ships
22:21:14  <saghul>trevnorris: did you get latest v1.x?
22:21:19  <saghul>we landed a fix for that
22:21:32  <trevnorris>saghul: 1.4.2. should I go off latest v1.x?
22:23:13  <Domenic>trevnorris: one-and-done events, which could succeed xor fail, and which you might want to add a listener for either before or after they happen, are perfect match for promises
22:23:41  <nathan7>Domenic: synchronous inspection would be nice there
22:23:51  <Domenic>nathan7: yeah
22:24:22  <trevnorris>Domenic: sure, but then you have to tack on a different type of API. e.g. what is "server.on('connection'" going to look like, the same?
22:24:45  <Domenic>trevnorris: if something can happen more than once, it *should* be a different type of API than something that can happen once
22:24:58  <nathan7>trevnorris: a server would be a readable stream of connections (;
22:25:10  <Domenic>eeeeeh
22:25:24  <trevnorris>someone will do it. :P
22:26:09  <nathan7>stream it and they will come
22:26:09  <trevnorris>Domenic: sure, but socket.writable.closed.then(), that's pretty freaking long. loose all the characters saved by () => { }. ;)
22:26:38  <saghul>trevnorris: yeah
22:26:47  <trevnorris>Domenic: also, how will a closed server work? it's an event that can only happen once?
22:26:50  <trevnorris>saghul: thanks. will do.
22:26:52  <saghul>trevnorris: are you using a c++ compiler though?
22:27:16  <Domenic>trevnorris: the http://www.w3.org/2012/sysapps/tcp-udp-sockets/#interface-tcpsocket adds some aggregate-level properties, socket.closed.then(...), for telling when both writable and readable side are closed
22:27:45  <trevnorris>saghul: well, am for the C++ part. compiling the libnub.a with clang.
22:27:46  <nathan7>trevnorris: `await socket.writable.closed` in ES7 parlance
22:27:49  <Domenic>trevnorris: yeah I mean nobody has any ambitions of defining a server API outside node but if i were defining one today I'd do .closed.then(...)
22:28:18  <nathan7>do we have any userland prototypes of these cool things?
22:29:19  <saghul>trevnorris: here are the details: https://github.com/libuv/libuv/pull/265 using latest v1.x should do
22:29:27  <trevnorris>saghul: awesome. thanks.
22:30:13  * bradleymeckquit (Quit: bradleymeck)
22:30:36  <trevnorris>Domenic: so the .closed.then() etc. will all create a new Promise when the .then is set?
22:32:18  * toothrotjoined
22:33:17  <MI6>joyent/node: misterdjules created tag v0.10.38 - http://git.io/hAMr
22:33:19  <MI6>joyent/node: Julien Gilli v0.10 * 7edfd5f : Now working on 0.10.39 (+2 more commits) - http://git.io/hAMo
22:33:24  <MI6>joyent/node: misterdjules created branch v0.10.38-release - http://git.io/hAM1
22:35:07  <Domenic>trevnorris: in unoptimized VMs, sure
22:35:20  * bradleymeckjoined
22:36:10  <trevnorris>Domenic: also, I was under the impression that this type of API was to help prevent callback nesting hell, but I haven't seen an example that really displays that. was I under the wrong impression?
22:36:57  <Domenic>trevnorris: it's more about error propagation than preventing callback nesting. there are easy examples showing how it prevents callback nesting but everyone just says "I'll just create named functions" instead
22:37:46  <Domenic>(which of course doesn't work if step 3 depends on step 2 depends on step 1, unless you use state in a common closure or similar. But I digress.)
22:40:53  * danfriedjoined
22:44:51  <trevnorris>saghul: still not working. might be because i'm compiling libnub.a first using clang, then compiling the rest of the application using clang++.
22:45:06  <trevnorris>thanks for the tip though. I should be able to get it from here. :)
22:52:24  <saghul>trevnorris: humm, that's weird, let me know how it goes!
22:56:13  * bradleymeckquit (Quit: bradleymeck)
23:08:23  * thlorenzquit (Remote host closed the connection)
23:10:09  * avalanche123quit (Remote host closed the connection)
23:13:15  * chris_99quit (Quit: Ex-Chat)
23:14:36  * avalanche123joined
23:16:14  * jgiquit (Quit: jgi)
23:20:29  <tjfontaine>copy is rarely (in node.js' case) the expensive part of streams, so it's not really about what thread that happens on
23:29:11  * avalanche123quit (Remote host closed the connection)
23:30:51  <MI6>joyent/node: Michael Dawson refs/tags/jenkins-accept-pull-request-temp * 66379c9 : test: Environment varible to specify directory for pipes (+2 more commits) - http://git.io/hxeS
23:32:41  <MI6>joyent/node: Michael Dawson refs/tags/jenkins-accept-commit-temp * ecdf151 : test: Environment varible to specify directory for pipes (+2 more commits) - http://git.io/hxvR
23:44:00  * avalanche123joined
23:45:58  * danfriedquit (Quit: WeeChat 0.4.2)
23:47:21  * benjamingrquit (Quit: Connection closed for inactivity)
23:56:19  * rendarquit
23:59:16  * avalanche123quit (Remote host closed the connection)