00:16:14  * cremes_joined
00:17:02  * cremesquit (Ping timeout: 256 seconds)
00:17:03  * cremes_changed nick to cremes
00:21:28  * Jacob843quit (Remote host closed the connection)
00:21:50  * Jacob843joined
00:28:44  * cremes_joined
00:29:26  * cremesquit (Ping timeout: 244 seconds)
00:29:27  * cremes_changed nick to cremes
01:02:49  * cremes_joined
01:03:56  * cremesquit (Ping timeout: 265 seconds)
01:03:56  * cremes_changed nick to cremes
01:15:57  * Ruyijoined
01:26:16  * tetoquit (Ping timeout: 244 seconds)
01:26:38  * tetojoined
01:34:37  * daurnimatorquit (Remote host closed the connection)
01:58:33  * Ruyiquit (Ping timeout: 265 seconds)
02:01:15  * Ruyijoined
02:12:12  * daurnimatorjoined
02:17:06  * rmgjoined
02:21:55  * rmgquit (Ping timeout: 260 seconds)
02:44:29  * rmgjoined
02:49:04  * rmgquit (Ping timeout: 258 seconds)
02:57:04  * [spoiler]quit (Ping timeout: 268 seconds)
02:57:19  * zju3joined
02:58:05  * zju_25quit (Ping timeout: 256 seconds)
02:58:14  * zju_x1joined
02:58:41  * zju_xquit (Ping timeout: 260 seconds)
02:58:51  * [spoiler]joined
03:13:13  * lennartclquit (Ping timeout: 244 seconds)
03:15:38  * lennartcljoined
06:31:08  * rendarjoined
06:57:44  <txdv>hexian!
07:29:57  * seishunjoined
08:06:55  * indexzeroquit (Ping timeout: 256 seconds)
08:08:18  * indexzerojoined
08:09:24  * rmgjoined
08:14:20  * rmgquit (Ping timeout: 250 seconds)
08:24:38  * seishunquit (Ping timeout: 245 seconds)
08:36:47  * rmgjoined
08:41:39  * rmgquit (Ping timeout: 265 seconds)
08:46:32  * nathan7quit (Ping timeout: 260 seconds)
08:59:04  * nathan7joined
09:03:55  * rmgjoined
09:08:10  * rmgquit (Ping timeout: 244 seconds)
09:20:36  * sgimenojoined
09:31:00  * rmgjoined
09:35:55  * rmgquit (Ping timeout: 260 seconds)
10:11:25  * zjujoined
10:42:20  * Matthew[m]joined
11:25:08  * thealphanerdquit (Quit: farewell for now)
11:25:38  * thealphanerdjoined
14:23:48  <txdv>HEXIAN!
14:41:51  <txdv>hexian, where are you?!
15:10:20  * rendarquit (Ping timeout: 250 seconds)
15:15:43  * Fishrock123joined
15:24:07  * rendarjoined
16:13:49  * rmgjoined
17:32:22  * seishunjoined
18:32:36  * brsonjoined
18:50:11  * a3fjoined
19:17:11  * Fishrock123quit (Remote host closed the connection)
19:29:45  * Fishrock123joined
19:45:46  * Fishrock123quit (Remote host closed the connection)
20:05:11  * Fishrock123joined
20:15:53  * seishunquit (Ping timeout: 245 seconds)
20:19:17  * seishunjoined
20:31:24  * frerichjoined
20:33:18  <frerich>Hi all! I'm currently toying with libuv (via the Python bindings provided by the 'pyuv' module) and wonder: is it possible to create a named pipe server using libuv to which one can connect using the Windows function 'ConnectNamedPipe'? An initial attempt to do so failed, the 'pending_handle_type()' method on the pipe on which I called listen() returns '0'. :-/
20:33:47  <frerich>...or is it that there is some internal protocol expected which means that one also has to use libuv on the caller side to establish the connection?
20:36:43  <indutny>frerich: I think yes
20:36:52  <indutny>frerich: you are talking about uv_spawn and friend, right?
20:37:04  <indutny>frerich: we are using some sort of protocol to send handles over it
20:37:18  <indutny>frerich: which means that it should be libuv on both ends
20:38:56  <frerich>indutny: Pardon my ignorance, I'm using libuv via a Python binding so I might get the API wrong, but I think the Python code I have is similiar to uv_pipe_init, _bind and then doing _listen and _accept.
20:39:17  <indutny>oh
20:39:39  <indutny>well, that still may use that internal protocol
20:39:40  <indutny>if ipc=1
20:39:42  <frerich>indutny: That's on the server side -- on the client side, I use the Windows call 'ConnectNamedPipe'. I can see that a connection is registered, but I can't seem to read any data in the server which the client sends.
20:39:45  <frerich>Yes, indeed - I use ipc=1.
20:40:09  <indutny>ok
20:40:29  <indutny>https://github.com/libuv/libuv/blob/v1.x/src/win/pipe.c#L68-L77
20:40:42  <indutny>it uses custom protocol for this on Windows
20:40:50  <indutny>I'd recommend using libuv on both ends to manage that pipe
20:42:28  <frerich>Hm...
20:44:07  <indutny>frerich: otherwise you may try using that custom protocol on other end
20:44:22  <indutny>its not too hard but libuv doesn't give a stability guarantee for it
20:44:27  <indutny>and it is not used on unixes
20:44:43  <indutny>way more risky way, in my opinion
20:44:48  <indutny>I wouldn't do it
20:46:06  <frerich>It's certainly more risky, indeed... it's still attractive though in that using libuv on the client side is possible, but not totally trivial: one of the clients is written in Python -- there is a standard Python module available for interfacing with the Win32 API, but the module which wraps libuv requires compilation, so the installation of the Python client is a bid harder since on Windows, you don't usually have a compiler installed...
20:46:42  <frerich>For what it's worth, I started out with doing everything using raw Win32 API, but managing overlapped IO using completion ports on Windows by hand is a bit painful. I hoped I could get away with just letting libuv do it for me. :-]
20:46:54  <indutny>heh
20:47:12  <indutny>Windows is quite compatible to itself, though
20:47:29  <indutny>perhaps distributing your client with a couple of dlls may work?
20:47:34  <indutny>(not sure how it works in python)
20:48:09  <frerich>Yes, I've been considering that as I was writing this... it's a bit annoying because I don't actually need to do a lot via named pipes: I just send over a list of newline-separated file paths and then get back a set of file hashes (which may have been cached).
20:48:22  <frerich>I.e. I don't do anything terribly fancy, no stateful protocol or the like.
20:48:56  <indutny>oh
20:49:03  <indutny>frerich: why do you need it to be in ipc mode then?
20:49:21  <indutny>ipc mode is needed only if you plan to send sockets over it
20:49:23  <indutny>or other handles
20:49:27  <frerich>indutny: Quite frankly, I read that ipc means 'inter process communication' and I thought 'indeed, I have two processes talking, so let's enable this' :-]
20:49:36  <indutny>heh, that's right
20:49:39  <indutny>give it a try without ipc
20:53:51  <frerich>Hmm, same symptom... maybe I'll first do a simpler version using libuv-via-Python on both sides to make sure I can get that to work at all, and then I'll change the client side to see whether I can do it without libuv...
20:55:52  * txdvquit (Ping timeout: 260 seconds)
20:56:33  <frerich>indutny: Thanks for your help :-)
20:56:42  <indutny>np
20:56:43  <indutny>you're welcome
20:57:15  * txdvjoined
21:30:02  <frerich>indutny: Yay, got it working: after cloning the libuv sources and grepping a bit, I saw that it creates named pipes on Windows using the CreateNamedPipe function and passes a special flag which means that the pipe is in 'bytes' mode (as opposed to 'message' mode). I somehow assumed the latter and thus used 'CallNamedPipe', which is documented to fail for pipes in 'bytes' mode. The good thing is that the alternative to CallNamedPipe is to just open the pipe as a
21:30:04  <frerich>:-)
21:30:11  <indutny>aha
21:30:13  <indutny>lovely
21:30:22  <indutny>sorry, I have very little experience in winapi
21:30:56  * rendarquit (Quit: Leaving)
21:31:17  <frerich>indutny: Oddly enough it does not seem to matter whether 'ipc' mode is enabled (this may well be just me not quite grok'ing the Python bindings though).
21:50:53  * seishunquit (Ping timeout: 245 seconds)
22:08:56  * Cannonjoined
22:13:45  * Cannonpart ("I'm Out")
22:55:21  * frerichquit (Ping timeout: 260 seconds)
23:36:14  * a3fquit (Quit: Zzzzz..)
23:40:23  * a3fjoined
23:43:02  * Fishrock123quit (Quit: Leaving...)