Version 0.2.2 or later does not work on Windows

[erw7]

Updated the version to 0.2.3 :py3 print("hello") now causes an error similar to neovim/neovim#7326.
On Windows it seems that connect_read_pipe and connect_write_pipe doesn't support stdin/stdout.

[Shougo]

#294

I know issues on windows has held up this change in the past (#243). We might need to change the asyncio backend on windows. IIRC there is even a libuv based backend, but I don't know it's status. I will look into this tomorrow.

[justinmk]

@erw7 what version of python? Does the issue occur with python 3.6?

[erw7]

This issue occurs in python 3.6.4.

C:\>python -c "import sys;print(sys.version)"
3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)]

[bfredl]

I thought using proactor was enough, but apparently not. The hack fallback is to read from stdin in a separate thread like this https://github.com/vxgmichel/aioconsole/blob/master/aioconsole/stream.py#L66

[shea-parkes]

Just hit this one today as well. Downgrading to v0.2.1 fixed it for me. Would appreciate continued windows support. Thanks!

[bfredl]

It is being worked on: #307

[erw7]

@bfredl Thanks. But, on Windows, add_reader only supports socket handle, so #307 doesn't work.
I tried it, but it got an error as below.

Failed to load python3 host. You can try to see what happened by starting nvim with $NVIM_PYTHON_LOG_FILE set and opening the generated log file. Also, the host stderr is available in messages.
function remote#define#FunctionBootstrap[1]..remote#host#Require[10]..provider#pythonx#Require[13]..provider#Poll, line 4
Vim(if):ch 4 was closed by the client
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
  File "C:\Python36\lib\site-packages\neovim\__init__.py", line 71, in start_host^M
    nvim = Nvim.from_session(session)^M
  File "C:\Python36\lib\site-packages\neovim\api\nvim.py", line 56, in from_session^M
    channel_id, metadata = session.request(b'vim_get_api_info')^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\session.py", line 91, in request^M
    v = self._blocking_request(method, args)^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\session.py", line 169, in _blocking_request^M
    self._enqueue_notification)^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\async_session.py", line 66, in run^M
    self._msgpack_stream.run(self._on_message)^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\msgpack_stream.py", line 44, in run^M
    self.loop.run(self._on_data)^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\event_loop\base.py", line 143, in run^M
    self._run()^M
  File "C:\Python36\lib\site-packages\neovim\msgpack_rpc\event_loop\asyncio.py", line 158, in _run^M
    self._loop.run_forever()^M
  File "C:\Python36\lib\asyncio\base_events.py", line 421, in run_forever^M
    self._run_once()^M
  File "C:\Python36\lib\asyncio\base_events.py", line 1395, in _run_once^M
    event_list = self._selector.select(timeout)^M
  File "C:\Python36\lib\selectors.py", line 323, in select^M
    r, w, _ = self._select(self._readers, self._writers, [], timeout)^M
  File "C:\Python36\lib\selectors.py", line 314, in _select^M
    r, w, x = select.select(r, w, w, timeout)^M
OSError: [WinError 10038] <83>\<83>P<83>b<83>g<88>ȊO<82>̂<e0><82>̂ɑ΂<b5><82>đ<80><8d><ec><82><f0><8e>^Ms<82><b5><82>悤<82>Ƃ<b5><82>܂<b5><82><bd><81>B^M

[bfredl]

Yes, the latest approach uses a thread, working on it right now...

[shea-parkes]

I just read my reply from last night and realized I sounded like an ass. I appreciate all the work you've done on NeoVim. Especially the integration of cmd.exe with the terminal. I'll go make a donation today to make up for it.

And not that this will likely help at this point, but here's the versions I hit this issue with:

Microsoft Windows [Version 10.0.16299.248]
(c) 2017 Microsoft Corporation. All rights reserved.

Python 3.5.4 |Anaconda, Inc.| (default, Nov  8 2017, 14:34:30) [MSC v.1900 64 bi
t (AMD64)]

[bfredl]

@shea-parkes No worries, it is me doing crazy changes without regression testing : P I will look into setup appveyor after fixing this.

[anson2416]

python 3.5 also doesn't work.

$ python -c "import sys;print(sys.version)"
3.5.4 (v3.5.4:3f56838, Aug  8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)]

[bfredl]

I reverted the change for now (partially, nvim.loop is available on POSIX for now).

An alternative might be to have the host connect through $NVIM_LISTEN_ADDRESS on windows. IIUC explicitly connecting to a named pipe should work, it is just adding an existing fd that happens to be a pipe that is broken. It will make the polling a bit more involved though...

[erw7]

Although the fundamental problem is not solved, it closes because it came to work with 0.2.4.

I tried duplicate the file handle with DuplicateHandle like libuv, but it still does not work. I can not understand why it does not work though similar code works in pyuv(libuv).

[bfredl]

I can not understand why it does not work though similar code works in pyuv(libuv).

libuv does one more thing: it checks if the pipe was opened in overlapped mode or not. If the pipe is overlapping, it uses IOCP, but otherwise it spawns a reader thread. But the pipe is opened by libuv on the nvim side, maybe it could be kindly asked to open the client pipe end in overlapped mode?

[bfredl]

Found it: the server pipe should be started in "ipc" mode, enables some other capatibilities also but hopefully not dangerous.

[erw7]

Are you talking about uv_pipe_init of src/nvim/even/process.c process_spawn?

I tried "ipc" mode, but got a lot of errors with functionaltest. If I think about it, it is quite clear. The child process does not use the OVERLAPPED structure to read standard input.

After all, it seems that we can only use the reader thread.

[bfredl]

If mean neovim/neovim#8113 yes failures are expected because I enabled it unconditionally to get a binary I can test. If we take this path it should of course only be activated for rpc jobs.