[BUG] Example not working. `nio.uv`

[pysan3]

NeoVim Version

NVIM v0.10.0-dev-2066+g1813661a6
Build type: RelWithDebInfo
LuaJIT 2.1.1703358377
Run "nvim -V1 -v" for more info

Describe the bug Hi, thanks for an interesting plugin.

I think the following code in the README does not work.

If I understand correctly, the return value of nio.uv.fs_open is a single int (what should be file_fd), and does not return the error state.

To Reproduce

local file_path = "README.md"

local open_err, file_fd = nio.uv.fs_open(file_path, "r", 438)

vim.print(open_err) -- 52 (or any other int)
vim.print(file_fd)  -- nil

Am I understanding something wrong?

[rcarriga]

This is because you haven't ran the code in nio.run. The wrap function (which is used for nio.uv) will run the wrapped function without a callback if not run from an async task (logic is here).

So what's actually happening is that vim.loop.fs_open is being called without a callback and so run synchronously.

[pysan3]

Ooh I see. That cleared up a lot of things. Thank you very much.

[pysan3]

BTW, if that's the case, when it is not wrapped, the function type definitions do not match, right? @rcarriga

Does that mean that it is not intended to be run outside of a wrap function? How about just raising an error, or at least printing a warning when not current_non_main_co()?

[rcarriga]

The intention was to allow it to be flexible for using in async functions or outside but I think the default behaviour should raise an error, so I've allowed users to call it from a non-async context with an extra option

[pysan3]

This is a nice idea, and I love that it is true by default.

However, this fix will not solve the problem that the function annotations are not correct. What if we always return a hardcoded nil, <result> when they are called in a non-async environment to make it align with the signatures?

I'd love to hear your opinion @rcarriga .

[rcarriga]

However, this fix will not solve the problem that the function annotations are not correct.

The function can no longer be called from a non-async context which means there's no way to get the previously incorrect return values and so the signature is correct, no?

[pysan3]

Oh that's right. Thanks.