Honestly, I've always preferred other Lisps (specifically Racket and Clojure). But among desserts, flan has a special place in my heart. I don't let myself indulge these days but thanks to the delectable drawing in this article, I might go get some this evening!
>This branch contains a version of Mahogany using a backend written in C. The old version written entirely in Common Lisp can be found in the full-cl-old branch.
I've done a little (very little) on Stump/contrib and it is on my list to look into. But I know nothing of Wayland (internals especially) and would prefer something that is at least a little usable to hack on while using it. I don't think this is far along, based on the readme at least. I'm also worried if I start down this path I won't (want to) do anything else at my computer besides work on that, so much do I love Lisp-y things :)
Have you? (I've taken your comment in good faith and ask you the same in return)
This is a client library only (at least according to the title). There would need to be an equivalent server library implementation, not to mention all of the necessary non Wayland protocol code (libinput, drm, etc). Still the easiest means to port StumpWM would be to use c bindings for wlroots
Very cool! I like that the author chose socket-based communication over a C FFI, which I assume might lead to better reliability and a cleaner API on the Lisp side. Are there any disadvantages to sockets vs. FFI? Any additional, perceivable latency?
I chose to use FFI for sockets so that I can have access to sendmsg(), which lets me send file descriptors on the same message as mundane I/O. It also comes with a small bonus that I get to use scatter/gather arrays to move I/O around, which means less byte-shifting when having to deal with incomplete messages.
I'm not sure I understand your question between sockets vs. FFI. Anything not built on FFI would have to come from an impl extension (or a compatibility layer, which would still have to be built on-top of the former two). AFAIK not even SBCL's sb-posix send fd's across -- they still list sendmsg() in a TODO.
As for latency, I haven't benchmarked performance yet. I want to write a collection of desktop apps driving Wayflan to make sure the API is solid, before I do any benchmarking. However, I know one possible advantage over C's libwayland. Libwayland stores a message signature as a string, which runs through an "interpreter" to learn how to decode a message. Wayflan expands a message signature into a function directly via a couple layers of macros.
If the client and server are doing blocking recvs or spinning CPU cores, then it's probably 5-10uS of latency. If they're doing something fancier like select/poll/epoll, it could be more like 50-100uS of latency. A direct function call would presumably be significantly less than 1uS, although it really depends on what the function is doing.
Wayland clients already communicate with the compositor via sockets. This is no different, the main thing will be being able to produce a Lisp-centric API rather than directly using the existing libwayland-client or another library's API.
Are you suggesting this person should’ve spent their time working on reimplementing wayland in rust instead? If so I suggest you drop all the projects you’re currently working on and do the same.
Sure, why not? This is a Wayland client, not the server (aka, compositor). But there's little technical reason not to make the compositor in Lisp either, other than the time commitment. If you want Rust clients and compositors, they do exist. If you don't know how to find them, here's one that turned up on Google: http://way-cooler.org/
