Constant "attempt to concatenate a nil value error"

[vendion]

With the latest version of tabnine-nvim I get the following error message whenever I open Neovim:

Error executing vim.schedule lua callback: ...ocal/share/nvim/lazy/tabnine-nvim/lua/tabnine/binary.lua:49: attempt to concatenate a nil value
stack traceback:
        ...ocal/share/nvim/lazy/tabnine-nvim/lua/tabnine/binary.lua:49: in function 'binary_path'
        ...ocal/share/nvim/lazy/tabnine-nvim/lua/tabnine/binary.lua:65: in function 'start'
        ...ocal/share/nvim/lazy/tabnine-nvim/lua/tabnine/binary.lua:114: in function 'request'
        ...ocal/share/nvim/lazy/tabnine-nvim/lua/tabnine/status.lua:19: in function 'cb'
        vim/_editor.lua:263: in function <vim/_editor.lua:262>

Worse is whenever I dismiss this error it comes back up a few seconds later.

[aarondill]

please try running

cd ~/.local/share/nvim/lazy/tabnine-nvim
./dl_binaries.sh

If that doesn't fix the problem, could you share more information about your machine?

[aarondill]

If you try this command, it should output what neovim thinks your system details are.

$ nvim --headless '+lua =vim.inspect(vim.loop.os_uname())' '+qa'

[aarondill]

Inspecting the code, it seems that the arch_and_platform function is the only thing on this line that could return a nil value. I wonder if @vendion is using an unsupported combo (like arm64 linux) or a unix distribution such as freebsd (also unsupported).

[vendion]

Yes, in this case I'm running FreeBSD, but that doesn't justify spamming me with the above error to the point that neovim is unusable. Instead of constantly throwing this error, if the plugin detects the platform is unsupported then it should stop trying to load or error silently rather than having me hit <Enter> multiple times a second.

[vendion]

Now to be fair, FreeBSD does has the ability to run Linux binaries, so it is possible the amd64 Linux binary could work (similar to using wine to run Windows programs on Unix-like OS) but that is a different matter.

My use case isn't that uncommon, as I share all my configs across all my machines via a VCS repo (https://gitlab.com/vendion/dotfiles) which includes FreeBSD machines (amd64) and Linux (amd64, aarch64).

[aarondill]

To be clear, I'm not saying this is intended behavior, I was simply hypothesizing about the cause of the issue

[aarondill]

I wonder if just returning an empty string would even cause any issues...

something like this:

if os_uname.sysname == "Linux" and os_uname.machine == "x86_64" then
   return "x86_64-unknown-linux-musl"
elseif 
   -- ...
else
   return ""
end

the binary would not be found, causing the uv.spawn to return nil, and I think there's enough checks to ensure that doesn't throw an error?

Though in the long term, detecting unsupported configurations is a much better idea.

[hnry047]

same problem

[aarondill]

we were trying to resolve this at #82, but it seemed to stagnate when @amirbilu got busy. i'd appreciate more eyes on that code, or else another (replacement) PR with whatever Amir has in mind