@equalsraf
equalsraf
... even if packages for lua and all deps(mpack, bitop, lpeg) are installed. This seems to be a problem with the lua binary name in OpenBSD its called lua51, lua52, luajit51 - instead of the expected lua5.1 or just lua.
The workaround for this is to specify the binary
TLDR; it did not work, apparently the major blocker is libuv support
Haiku already has some deps, lets use its packages. But for libvterm, etc we need to use third-party
mkdir .deps
cd .deps
equalsraf
/ windows-nvim-build.md
[WIP]
In Windows we build using the toolchain provided by MSYS2 - the resulting binaries DO NOT link against the MSYS2 runtime.
Start by installing the necessary dependencies
CMake has two generatores using Make for windows.
MinGW Makefiles expects to run from the cmd shell (uses mingw32-make)
equalsraf
/ neovim_system_string.md
Vim's system('string') interface is not always straightforward in Windows,
its behaviour can be downright unexpected involves an intricate set of options. Its primary purpose its to execute
a command in the shell (see &shell) in simple terms we can think that calling system('some command') is equivalent
to spawning a process with the following arguments
[&shell, &shellcmdflag, 'some command']
and sometimes this might be true but it also might not. Consider the following examples (I'm running in gVim 7.4/Windows 8)
I thought this was fixed earlier, but the following fails to execute if shell=cmd.exe
:echo system('cd /d "c:\Windows"')Take the following script
os_can_exe() used by executable() actually checks PATHEXT. Behaviour in Vim is:
executable('no_such_file') returns 0
executable('file') returns 1 if file.bat,file.exe,etc exist ($PATHEXT)
executable('file.bat')returns 1
executable('file.exe')returns 1
This could lead to the misconception that, for example, executable("file.bat") being 1 implies that system(["file.bat"]) is expected to succeed, which is not true. But this is an issue with system([]) in windows and not with executable(). The notion of executable in Windows is fundamentaly a shell concept, because unlike UNIX there no notion of shebang and permission bits, that allows execution of non binary files.
equalsraf
/ appveyor_poke.py
| #!/usr/bin/python3 | |
| # | |
| # Little script to check if Appveyor is stuck | |
| # | |
| # The return code is (2) if the build is considered stuck, (0) if not | |
| # stuck, and (1) for other errors | |
| import json | |
| import sys | |
| import requests |
TLDR; no, libuv doesn't work in Cygwin just yet, see at the bottom.
I tested using the master branch (9d3449852bd35c9283948186d0259c1bf73b8579 or later)
I installed the following in the cygwin setup
Check the pull request for the changes and the main issue for discussion. If you run into trouble check the Known Errors section at the end, or drop me a comment.