00:00:08  * Guest15578changed nick to indutny
00:17:33  <avih>also, while it could be useful, i'm not strictly interested in making writes to TTY stdout synchronous in the sense that they show up right away. rather, i'm more interested in not having to queue my outputs, since the docs say that writing twice to a n async stream before the callback was invoked leads to unexpected results. So i don't want to do this wait/queue/management myself (eventhough for now i do have reasonably elegant code for it, but i'd have
00:17:34  <avih>preferred to avoid needing to manage it myself)
00:42:32  * nickleeflyquit (Quit: Connection closed for inactivity)
00:46:33  * brsonquit (Ping timeout: 240 seconds)
01:01:02  * happy-dudequit (Quit: Connection closed for inactivity)
01:23:25  * tunniclm_quit (Read error: Connection reset by peer)
01:25:04  * rcyrjoined
01:28:08  * rcyrchanged nick to systemfault
01:49:56  * Ruyijoined
02:16:35  * roxluquit (Ping timeout: 250 seconds)
02:16:43  * roxlujoined
03:21:39  * reqsharkquit (Quit: Be back later ...)
03:47:45  * rmg_joined
03:51:51  * rmg_quit (Ping timeout: 240 seconds)
04:08:15  * rgrinbergquit (Ping timeout: 276 seconds)
04:58:54  * nickleeflyjoined
05:23:27  * systemfaultquit (Quit: Bye!)
05:38:44  * matrixis1changed nick to matrixise
06:23:55  * rmgquit (Remote host closed the connection)
06:24:33  * rmgjoined
06:28:31  * rmgquit (Ping timeout: 240 seconds)
07:02:32  * nickleeflyquit (Quit: Connection closed for inactivity)
07:25:07  * rmgjoined
07:29:49  * rmgquit (Ping timeout: 252 seconds)
08:24:35  * Fishrock123joined
08:50:03  * rmgjoined
08:54:30  * rmgquit (Ping timeout: 246 seconds)
09:00:06  * {slurp-libuv}1joined
09:00:07  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
09:00:18  * rvagg_joined
09:02:28  * Therstri1mjoined
09:04:21  * eugeneware_joined
09:04:38  * Jacob8432joined
09:04:55  * niska`joined
09:08:16  * Jacob843quit (*.net *.split)
09:08:17  * Redaquit (*.net *.split)
09:08:17  * {slurp-libuv}quit (*.net *.split)
09:08:17  * niskaquit (*.net *.split)
09:08:17  * rvaggquit (*.net *.split)
09:08:17  * eugenewarequit (*.net *.split)
09:08:17  * Therstriumquit (*.net *.split)
09:08:45  * rvagg_changed nick to rvagg
09:10:07  * eugeneware_changed nick to eugeneware
09:11:30  * seishunjoined
09:23:37  * rendarjoined
09:24:35  * saghul_joined
09:26:32  * rmgjoined
09:31:12  * rmgquit (Ping timeout: 272 seconds)
09:42:12  * Fishrock123quit (Remote host closed the connection)
10:15:38  * Redajoined
10:15:38  * Redaquit (Changing host)
10:15:38  * Redajoined
10:24:07  * abruanesejoined
10:29:23  * thealphanerdquit (Quit: farewell for now)
10:35:54  * thealphanerdjoined
10:41:55  * Ruyiquit (Read error: Connection reset by peer)
10:42:39  * jan____quit (Ping timeout: 246 seconds)
10:43:48  * jan____joined
10:46:39  * Fishrock123joined
10:51:01  * Fishrockjoined
10:53:32  * Fishrock123quit (Ping timeout: 272 seconds)
11:08:33  * Jacob8432quit (Quit: Leaving)
11:08:35  * Adam__joined
11:09:26  * Jacob843joined
11:10:27  * Haragethquit (Ping timeout: 250 seconds)
11:28:04  * rmgjoined
11:32:32  * rmgquit (Ping timeout: 244 seconds)
11:39:28  * zju3quit (Ping timeout: 264 seconds)
11:58:25  * zju3joined
12:20:47  * rgrinbergjoined
12:41:34  * happy-dudejoined
12:48:43  * ncthom91joined
13:27:57  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:29:33  * rmgjoined
13:34:03  * rmgquit (Ping timeout: 264 seconds)
13:42:29  * jan____quit (Changing host)
13:42:30  * jan____joined
13:48:00  * ncthom91joined
14:03:55  * Fishrockquit (Quit: Leaving...)
14:21:41  * zju_25joined
14:30:14  * rmgjoined
14:35:16  * rmgquit (Ping timeout: 264 seconds)
14:37:18  * rmgjoined
14:42:04  * rmgquit (Ping timeout: 260 seconds)
15:25:32  * zju3quit (Ping timeout: 258 seconds)
15:26:55  * zju3joined
15:34:06  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
15:37:46  * rmgjoined
15:38:17  * saghul_joined
15:43:06  * rmgquit (Ping timeout: 276 seconds)
15:53:08  * seishunquit (Disconnected by services)
15:53:14  * seishunjoined
16:31:04  * brsonjoined
16:31:48  * rmgjoined
16:36:48  * rmgquit (Ping timeout: 272 seconds)
16:44:23  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
17:00:52  * seishunquit (Ping timeout: 272 seconds)
17:04:52  * seishunjoined
17:20:00  * rmgjoined
17:23:22  * grantilajoined
17:23:36  * rmg_joined
17:24:57  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
17:27:10  * ncthom91joined
17:28:44  * rmg_quit (Ping timeout: 272 seconds)
17:31:32  * thneejoined
17:33:46  <saghul>avih: in general, things that inherit from uv_stream_t don't have a blocking API
17:34:05  <saghul>uv_stream_set_blocking is kind of a hack
17:34:32  <saghul>the funny part is that the windows TTY part is actually blocking IIRC, we make it look non-blocking
17:34:56  <saghul>but there is no way to make uv_tty have blocking writes on Windows ATM
17:35:03  <saghul>sorry, uv_pipe that is
17:35:44  <saghul>also, we don't have a uv_stream "subclass" which writes to a file, which means that abstracting everything as you wish is just not possible
17:46:54  * ncthom91quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:25:44  * happy-dudequit (Ping timeout: 272 seconds)
18:26:43  * happy-dudejoined
18:27:14  * qardjoined
18:35:11  * Adam__quit (Remote host closed the connection)
18:37:49  * Haragethjoined
18:48:40  * rmgquit (Remote host closed the connection)
18:49:17  * rmgjoined
18:50:57  * saghul_joined
18:51:32  * Haragethquit (Remote host closed the connection)
18:52:34  * Haragethjoined
18:54:04  * rmgquit (Ping timeout: 260 seconds)
19:17:41  <avih>saghul: thanks. though i think something doesn't add up. stream_set_blocking does succeed for a pipe, but not for a tty, contrary to what you said. see src/win/stream.c - it return EINVAL for anything which is NOT a pipe
19:19:12  <avih>so basically, fs_* API can be blocking with null cb, and pipe can be blocking on win and linux using set_stream_blocking. tty can be made blocking too on linux, but can't (at least API wise) on windows
19:20:01  <avih>which is indeed kinda funny since apparently it's the only thing which is actually inherently blocking :)
19:23:35  <avih>also, so how does node.js make stdout blocking also on windows and also as a TTY? hackery with wait loop?
19:31:18  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:33:08  * tunniclm_joined
19:52:54  * Haragethquit (Remote host closed the connection)
20:00:03  * Haragethjoined
20:02:46  * rendarquit (Ping timeout: 252 seconds)
20:14:07  * Fishrock123joined
20:17:30  * saghul_joined
20:24:42  * Haragethquit (Remote host closed the connection)
20:32:38  * rendarjoined
20:33:53  <saghul>avih: it doesn't make it blocking, that's part of the current problem
20:34:05  <saghul>the general rule is that nothing should block on libuv
20:34:17  <saghul>fs apis do have a blocking counterpart, however
20:34:30  <avih>saghul: oh? so it succeeds, but it may still overwrite the buffer if i didn't wait for the callback?
20:34:51  <saghul>no, write operations will just queue up
20:34:54  <avih>(i.e. stream_set_blocking(..., 1) succeeds, that is)
20:35:21  <saghul>you still need to wait for the callback to be called before being able to reuse the uv_write_t structure
20:35:32  <saghul>that's why that API is wrong
20:36:28  <avih>so bottom line is that with uv_stream_t i must always wait for the callback before pushing more data using a specific handle?
20:36:55  <avih>(sorry.. not sure i got it.. it's confusing to me..)
20:36:59  <saghul>no, you can push as much data as you want, it will be queued up
20:37:19  <saghul>I was referring to your question about overriding buffers, but maybe I got confused :-)
20:37:23  <saghul>what do you want to achieve?
20:37:51  <avih>that i can call write without having to wait for the callback in order to call it again
20:38:14  <saghul>you don't have to wait for it
20:38:25  <avih>on all platforms?
20:38:27  <saghul>just keep calling write, the request will be queued and written in order
20:38:30  <saghul>yes
20:38:43  <avih>oh, ok.
20:38:53  <saghul>when the write actually happens (since it's async) the callback will be called
20:39:11  <avih>so what does the set_blocking do? make it not queued and instead block until it was written out by libuv?
20:39:11  <saghul>so there you can free the resources associated with that particular write (like the buffer)
20:39:19  <saghul>yep
20:39:50  <saghul>but as you saw, it doesn't work for all types of uv_stream across platforms, it's a weak API, stay away from it :-)
20:40:10  <avih>oh, so the callback is mostly for me to know that i can free stuff up?
20:40:30  <saghul>yes, and to let you know that the write happened
20:40:38  <avih>(and to know it was actually written out, if i'm interested in that kind of info)
20:40:47  <avih>right
20:41:21  <avih>i'll go over my code again to see how i'm handling it. thanks.
20:41:37  <saghul>the uv_write_t needs to be allocated on the heap (well, kinda, it has to be valid untill the callback kicks in)
20:41:54  <avih>saghul: one thing though, i think something at the docs confused me about multiple writes before the callback. might be worth clearing it up. sec, let me try finding it
20:41:59  <saghul>so the callback lets you know that you can free that (or reuse it) along with the actual data buffer
20:42:10  <saghul>sure
20:48:12  <avih>saghul: so that's the current uv_write_t doc: "Write request type. Careful attention must be paid when reusing objects of this type. When a stream is in non-blocking mode, write requests sent with uv_write will be queued. Reusing objects at this point is undefined behaviour. It is safe to reuse the uv_write_t object only after the callback passed to uv_write is fired."
20:49:12  <saghul>yep, that was added because some people thought they could allocate a single uv_write_t and reuse it every time they call uv_write
20:49:24  <saghul>(since the write callback is optional)
20:49:42  <saghul>but that's not the case, the uv_write_t can only be reused *after* the callback is called
20:50:35  <avih>not sure if that's the part which confused me, but maybe adding something along the lines of "note that the buffer/uv_write_t object can only be freed/reused after the callback was invoked (in case of non blocking), however, you can still send more write requests before the callback of previous write requests was invoked - as long as you use new buffers/uv_write_t objects for those new requests"
20:51:14  <saghul>care to send a documentation PR?
20:51:28  <avih>does that ^ sound reasonable?
20:51:37  <avih>(with some polishing)
20:51:40  <saghul>interestignly the text you referenced was a recent contribution to help clarify the behavior
20:51:49  <avih>interesting
20:51:50  <saghul>sure
20:52:06  <saghul>maybe that should be added to the description of uv_write(...)
20:52:21  <saghul>instead of the type declaration
20:52:33  <avih>indeed
20:53:02  <avih>yeah, i'll read the stream doc again and try to make it a bit better, and then send a PR
20:53:52  <avih>thanks again for your help
20:55:58  <saghul>no problem, thanks!
20:56:03  <avih>:)
20:58:04  <avih>saghul: also, an abstraction of an always appending stdout, pretty much like printf behaves in C (i.e. doesn't care if it's a pipe, or a >/>> redirect or a TTY) would still be useful IMO ;)
20:59:09  <avih>possibly the same for stdin too
21:10:39  <saghul>I don't disagree :-) But it can be built on top of the current building blocks...
21:21:24  <avih>it can indeed, which i managed, but it still places burder on the lib users compared to how they would use stdin/out in other frameworks IMO
21:21:33  <avih>burden*
21:22:20  <avih>also, you almost can, since to figure out the std handle type you have to use an api which has a "guess" in its name, suggesting it might not be bullet proof
21:24:56  <avih>it would have inspired more confidence is it was s/uv_guess_handle/uv_get_handle_type/
21:27:04  <avih>especially the UV_FILE (redirect) should be treated inherently differently not only init, i.e. their write (for stdout) APIs are quite different
21:27:23  <avih>than for pipe/tty
21:45:38  * Alcestquit (*.net *.split)
21:45:38  * _hayesquit (*.net *.split)
21:45:38  * dainis_quit (*.net *.split)
22:03:04  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
22:07:25  * Fishrock123quit (Quit: Leaving...)
22:23:14  * seishunquit (Ping timeout: 272 seconds)
22:39:41  * grantilaquit (Quit: Leaving.)
22:41:20  * Haragethjoined
23:39:30  * saghul_quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:50:20  * bigkahunaburgerjoined
23:55:22  * brsonquit (Quit: leaving)