Wayflan: a from-scratch Wayland client for Common Lisp | Hacker News Reader

Wayflan: a from-scratch Wayland client for Common Lisp

sr.ht

118 pointssusam17 comments

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!

Does this mean we can now have a StumpWM port (or equivalent) for Wayland? Is this already in the works?

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

you might find this interesting

https://github.com/stumpwm/mahogany

Yes, let's get some work on this and then I can finally move to Wayland!

It's open source. Have you contributed?

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 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.

Why the change?

maybe its in their github issues. my guess is to get a working version in optimal time

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?

https://wayland.freedesktop.org/docs/html/ch04.html#sect-Pro...

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.

Hi! I'm the author of Wayflan.

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.

Reply on news.ycombinator.com