Just wondering, do you think that the same auto-generated approach would be useful for this project? Or are the downsides significant?
For Vulkan it works because they provide XML files intended to be used for generating bindings. To my knowledge, wlroots has nothing which could be used for that purpose. (It does have some XML files, but theyāre for documentation only and are not sufficient for generating bindings.)
Gotcha. FWIW, I was curious because it looks like there was an attempt of something similar in the waymonad fork linked above.
Iām taking a stab at doing WLR_pointer, on top of Dylanās branch that has Wlr_input_device
1 Like
Just curious, any success with automation?
It doesnāt look like thereās any easy way to do it. I guess weāll just have to bite the bullet and manually write all the instances!
Ah, oh well. I do think Iāll give jinja templating a try this weekendāhopefully that will speed certain parts up, somewhat.
Why not a Haskell templating library? Iād rather not touch Python if I can avoid it.
1 Like
That would no doubt be better for the project. Jinja is just what Iām familiar with and know that I can spin up a quick prototype with. I would definitely like to learn Template Haskell at some point, though!
In case youāre unaware, Template Haskell is something completely different ā itās not a general string templating library, but rather a full-blown macro system for Haskell. Undoubtedly it would be the most principled choice, but it adds a lot of complexity and I havenāt ever used it in the past.
Oh, gotcha. Good to know.
There are two places of interest here:
-
Automated conversion from C headers into some intermediate general format.
People have been trying this forever and the outcome is inevitably trying to generalize C itself. The Vulkan XML directly embeds macros, C bitfields and types like
<type>void</type> * const *because itās a mess either way you do it.There are Haskell libraries that autogenerate from C headers, notably
bindings-GLFW, but they have to stick to weird conventions out of necessity, like prepending garbage to names and exporting functions multiple times in different formats.The correct way to do this would be for each C library to ship an XML with all the function signatures, otherwise I think handrolling just does the job better.
-
Automated conversion from some intermediate general format into Haskell FFI modules.
The generation here is the the easy part, you just get
Data.ByteString.Builderand make a small program that writes files. Iāll inevitably make one like this just because every FFI import currently needs to be defined twice,safeandunsafe, andfreetype2is a rather large library without an XML file.However, I donāt think on a community level an opinionated templating library would be enough. Youād most probably want a holistic well-documented FFI experience, and aside from the community agreeing on the one true raw binding format, it would also include:
-
An extra library like
storable-offsetthat is the only Haskell dependency needed to produce FFI bindings. If the generator is a boot library, this one would be too. Currently I think it would only need one type class for normal struct offsets and one for bitfield offsets. -
Cabal support: FFI libraries as a new type of dependency. This would allow both proper user-side linking (instead of the current mess) and FFI dependency sharing between higher-level libraries.
-
Haddock support: a different way to render FFI functions. C structs are not Haskell datatypes, but I still want them to look accessible instead of being rendered as a bunch of instances. Same way
foreign imports are not regular Haskell functions and I would want that to be clear. -
Hackage support: showing FFI dependencies. Libraries with such dependencies should not be expected to work out of the box. Different languages could also use slightly different webpage styles (e.g. colors), but that would be the gravy on top.
Sounds like an RFC, doesnāt it?
-
6 Likes
@bullishOnFunctional very kindly wrote some Jinja macros to generate the aforementioned Haskell types and instances for structs and enums. Iāve rewritten them in Haskell using ginger, and incorporated them into a custom Setup.hs. Now, any hsc file can make use of these macros! This should help development go a bit quicker for these bindings.
(If you want an example, see the new ServerCore.hsc.)
1 Like
Gah, I have been trying to not use this account where I have been clowning around a lot, but this project is simply too attractive to stay silent. Iād be glad to be of help.
First thing first, I think you guys need to take a look at wayland-protocol. IIRC, Most of wayland functionalities are implemented there. It is a streamlined protocol to access tons of wayland features, including potential future extensions. I think a few of wlrootsā features are also made callable via wayland-protocol as well.
The wayland protocol is fairly straightforward to implement, enough for me to generate a TH code to generate the bindings as well. I suggest to try this way first, because the c header part of the protocol can be volatile. Indeed, most of wlroots bindings should be written manually, but I believe you can still save some effort this way.
Another aspect is client-server separation of wayland, which imo is quite important. Since this might be quite long a story, I would talk about this later if needed.
2 Likes
Iām not sure which wayland-protocol you are referring too. I certainly canāt find a Haskell package of that name. The usual implementation of the Wayland protocol is libwayland, upon which wlroots builds ā therefore, this is the implementation for which we are making bindings as part of this project.
The aforementioned macro system has been merged into master! Now development should go a bit faster, since it will be easier to write bindings to C structs.
Also, while Iām thinking about this, let me provide an update of which APIs have gotten some bindings so far, out of those I previously mentioned:
2 Likes
Iām trying to work my way towards wlr_seat, but Iām still fighting the xkbcommon library for wlr_keyboard. I have keyboard_group done iirc
2 Likes
Greetings, Iāve wanted to ask, whether taskboard will be available in near future? Even I donāt have much experience in Haskell in production, I would help with implementing some things, and in my opinion it will be super helpful for other developers like me. Or maybe it already exists, if so, I would appreciate if some of you will send a link
I donāt understand what youāre asking for here, sorry.
I meant, does board exists like Jira, Trello or GitHub Project for this project? Because, I donāt understand whatās going on here GitHub - bradrn/wlhs: Haskell bindings to wlroots (and libwayland). So thatās why I asked whether board will be available in the near future or it already exists?
English isnāt my native, so mistakes might occur