Ryan Liptak

Libuv doesn't handle any passing of data, so the coalesced callbacks are reasonable there (the only intention of Libuv's async is just to wake up the loop from any thread)....

> Secondly, since luv_context requires lua_State as an argument this macro can no longer be used to go from a uv_loop_t to a lua_State and is effectively useless. If possible...

Re-opening this in case we want to try to make it possible to get a `lua_State*` from a `uv_loop_t*` again.

Looks like an issue with Lua 5.4. Relevant issues: - https://github.com/luvit/luv/issues/514 - https://github.com/luvit/luv/issues/497 - https://github.com/luvit/luv/pull/515

Unfortunately our Lua 5.4 support is not quite there yet. Looks like the error you're getting is from your Lua lib files not being found when searching for them here:...

Is this still a problem with the latest release?

Seems related to https://github.com/luvit/luv/issues/437

Confirmed that the `uv_buf_t` problem mentioned in the quote above is accurate and reproducible via: ```lua local uv = require('luv') local path = "_test_" local fd = assert(uv.fs_open(path, "w", tonumber("0666",...

Thanks for compiling this, I think it's really worthwhile to address this sort of stuff. Replying to your comment in #393 here RE: `new_udp`/`new_tcp`: The most future proof way to...

Not really an inconsistency, but something I noticed when reading through the new docs: - `uv.new_pipe`'s `ipc` argument should probably be made optional (defaulted to false) rather than required