3 ms·

Wayflan: a from-scratch Wayland client for Common Lisp

118 points by susam 4y ago

ssivark 4y ago
Does this mean we can now have a StumpWM port (or equivalent) for Wayland? Is this already in the works?
- timidger 4y ago
  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
- medo-bear 4y ago
  you might find this interesting https://github.com/stumpwm/mahogany https://github.com/stumpwm/mahogany
  - podiki 4y ago
    Yes, let's get some work on this and then I can finally move to Wayland!
    - headhasthoughts 4y ago
      It's open source. Have you contributed?
      - podiki 4y ago
        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)
  - forgotpwd16 4y ago
    >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?
    - medo-bear 4y ago
      maybe its in their github issues. my guess is to get a working version in optimal time
the_jesus_villa 4y ago
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!
v3ss0n 4y ago
- SanderSantema 4y ago
  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.
- encryptluks2 4y ago
  Rust doesn't make programs bug free or safe.
- Jtsummers 4y ago
  > Seriously, lisp? 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/ http://way-cooler.org/ Some more Rust/Wayland stuff: https://github.com/Smithay/wayland-rs https://github.com/Smithay/wayland-rs
  - Arnavion 4y ago
    Note that Way Cooler switched from Rust to C in 2018, because the developer felt Rust didn't work for them. It's also been archived since 2019. (Also even the Rust version was built on top of wlroots, not a Rust implementation of the protocol like wayland-rs is.) https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html https://way-cooler.org/blog/2020/01/09/way-cooler-post-morte...
MattHood0 4y ago
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?
- Jtsummers 4y ago
  https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format 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.
- spelmachine 4y ago
  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.
  - sgtnoodle 4y ago
    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.

118 points by susam 4y ago

ssivark 4y ago

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

timidger 4y ago
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
medo-bear 4y ago
you might find this interesting https://github.com/stumpwm/mahogany https://github.com/stumpwm/mahogany
- podiki 4y ago
  Yes, let's get some work on this and then I can finally move to Wayland!
  - headhasthoughts 4y ago
    It's open source. Have you contributed?
    - podiki 4y ago
      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)
- forgotpwd16 4y ago
  >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?
  - medo-bear 4y ago
    maybe its in their github issues. my guess is to get a working version in optimal time

the_jesus_villa 4y ago

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!

v3ss0n 4y ago

SanderSantema 4y ago
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.
encryptluks2 4y ago
Rust doesn't make programs bug free or safe.
Jtsummers 4y ago
> Seriously, lisp? 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/ http://way-cooler.org/ Some more Rust/Wayland stuff: https://github.com/Smithay/wayland-rs https://github.com/Smithay/wayland-rs
- Arnavion 4y ago
  Note that Way Cooler switched from Rust to C in 2018, because the developer felt Rust didn't work for them. It's also been archived since 2019. (Also even the Rust version was built on top of wlroots, not a Rust implementation of the protocol like wayland-rs is.) https://way-cooler.org/blog/2020/01/09/way-cooler-post-mortem.html https://way-cooler.org/blog/2020/01/09/way-cooler-post-morte...

MattHood0 4y ago

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?

Jtsummers 4y ago
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format 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.
spelmachine 4y ago
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.
- sgtnoodle 4y ago
  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.