howl
howl copied to clipboard
howl-editor
A custom Howl socket wrapper
Several autocompleters, including the Clojure nrepl one and nimsuggest, require sockets. Right now, that's done by requiring the user to also install luasocket. And luarocks. And a separate Lua.
However, pretty much none of these need any advanced socket functionality. My idea is to have a custom, FFI-based, Posix socket wrapper: howl.socket. It would only implement the most basic functionality needed for the autocompleters.
Self-assigning because I can do this if desired.
I do have plans for supporting proper networking. The current luasocket requirement for the Clojure mode is a kludge, because I really needed it at the time and Howl did not have socket support. But here's what I have envisioned for the future:
A new module/class in howl.io.socket. This needs to work similarly to how howl.io.Process works, with async IO wrapped nicely up using coroutines via the dispatch module to provide a seemingly synchronous interface. It should build on gio instead of POSIX to allow for cross platform support (i.e. Windows). I'm interested in providing a custom luasocket wrapper based on this if possible to ease integration with other code, but that's not the first priority. In addition, but optionally as a later addition we should provide easy HTTP support to enable integration with external services.
So I'm not interested in a POSIX socket wrapper, and anything blocking is out of the question, but if you're interested in starting the work on the above then it would be great!
@nilnor Sounds good! I've never used gio sockets before, but it doesn't look like a crappy API. I'll push the work to a socket branch when I start.
would it be unreasonable to port https://github.com/kernelsauce/turbo/blob/master/turbo/socket_ffi.lua ?
@cinterloper that seems rather basic, but regardless I think that going with the GLib socket functions would be best way forward. We use GLib already for IO, processes, etc. already, and we're using the GLib mainloop to drive the application. So this stuff will integrate seamlessly, while trying to fit in bare FFI sockets in the GLib mainloop will very likely end up being a lot more work.
@refi64 Any news on this? I'm working on an error checker for Haskell and could use proper socket support.
Not quite, I was sort of figuring it was largely superceded by @shalabhc's work on #376 though I'm not sure what's come out of that.
I see. @shalabhc could you comment on this please? Have you looked into the socket support?
@dgaw ah yes - I have some not-working-at-all half finished code from months (years?) ago that I do not intend to work on. I'm going to just attach the files here in case anyone wants to continue or get ideas.
My interest in the socket thing waned after I realized most LSP servers talk on stdio and don't need socket support.
Thanks for the update @shalabhc. I'll have a look at the files.
BTW. I'm using a bash-based socket hack at the moment, which works quite well but obviously is not portable.
Hmm, I might try to find some time to have a look at this. Time is a short as ever, but will let you know. (Edit: Mean LSP support)