Haskell wlroots bindings

bradrn · January 17, 2024, 12:47pm

Not at the moment. Currently, wlhs is highly incomplete, so practically any new bindings you can write would be helpful!

bradrn · January 21, 2024, 2:49am

Somehow, I seem to have suddenly lost the ability to build my own project:

$ cabal build
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] next goal: wlhs-bindings (user goal)
[__0] rejecting: wlhs-bindings-0.1.0 (conflict: pkg-config package
wayland-server-any, not found in the pkg-config database)
[__0] fail (backjumping, conflict set: wlhs-bindings)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: wlhs-bindings

Cabal says that it can’t find wayland-server in the pkg-config database, even though it clearly does exist:

$ pkg-config --modversion wayland-server
1.22.0

Does anyone have any ideas?

geekosaur · January 21, 2024, 3:06am

Did you recently do a system update that updated pkg-config? This may be `pkgconf`-provided `pkg-config` does `--modversion` differently; dependency resolution fails mysteriously · Issue #8923 · haskell/cabal · GitHub, which is fixed in HEAD and should be in 3.10.3.

bradrn · January 21, 2024, 3:31am

Oh, very interesting! But I doubt this is the issue… my pkgconf was last upgraded more than a month ago (December 7, according to pacman).

bradrn · January 23, 2024, 12:26am

I’ve decided to repost this issue on /r/haskell in the hopes of getting any more responses: https://www.reddit.com/r/haskell/comments/19db56s/

bradrn · January 23, 2024, 1:26am

Just had some useful discussion with @angerman on Reddit. This revealed the following useful information from cabal build -v3:

Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --variable pc_path pkg-config
[…omitted…]
Searching for pkg-config in path.
Found pkg-config at /home/bradrn/Documents/wayland/wlhs/pkg-config
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --version
/home/bradrn/Documents/wayland/wlhs/pkg-config is version 2.1.0
Running: /home/bradrn/Documents/wayland/wlhs/pkg-config --list-all
[…omitted…]
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
/home/bradrn/Documents/wayland/wlhs/pkg-config returned ExitFailure 141
Failed to query pkg-config, Cabal will continue without solving for pkg-config
constraints: output of /home/bradrn/Documents/wayland/wlhs/pkg-config:
hGetContents: invalid argument (invalid byte sequence)

So this is weird: hGetContents is reporting an invalid byte sequence, of all things. As an experiment I made a wrapper script which teed the output of pkg-config to a file, then checked the encoding:

$ file pkg-config-out 
pkg-config-out: ISO-8859 text

So pkg-config is outputting text in ISO-8859… which, apparently, hGetContents can’t handle. Resetting the locale to C didn’t help, though.

Upon further investigating the pkg-config output, the following line sticks out to me:

vpl                            Intel® Video Processing Library - Accelerated video decode, encode, and frame processing capabilities o     n Intel® GPUs

Could the ® be the culprit here? What’s more, pacman logs show that libvpl was installed a week ago, so the timing is suspicious. But I don’t know, yet.

bradrn · January 23, 2024, 1:31am

Amazingly enough, this does indeed seem to be the problem! I quickly tried replacing libvpl with onevpl, which was what I had installed a week ago… and which incidentally doesn’t have any ®:

$ pkg-config --list-all | grep vpl
vpl                            oneVPL - oneAPI Video Processing Library

And this was sufficient to get cabal build working again! Then, reinstalling libvpl immediately broke cabal build. So this looks like a Cabal bug, which I will report later today.

geekosaur · January 23, 2024, 1:55am

github.com/haskell/cabal

Cabal 3.10.2.1 cannot parse `pkg-config`: `hGetContents: invalid argument (invalid byte sequence)`

opened 11:19PM - 10 Jan 24 UTC

elldritch

type: bug needs triage

**Describe the bug** Trying to run `cabal build` on https://github.com/fossas…/fossa-cli/tree/64c2f202dc923e3784267cf1d974a952da5baf09 works with Cabal 3.6.2.0, but not with Cabal 3.10.2.1. Here's the error message: ``` $ cabal build --minimize-conflict-set --verbose this build was affected by the following (project) config files: - /home/leo/src/fossa/fossa-cli/cabal.project Running: /home/leo/.ghcup/bin/ghc --print-global-package-db Reading available packages of hackage.haskell.org... Using historical state as of 2024-01-02T10:02:41Z as explicitly requested (via command line / project configuration) index-state(hackage.haskell.org) = 2024-01-02T10:02:41Z (HEAD = 2024-01-10T22:03:12Z) Running: /usr/bin/pkg-config --version Running: /usr/bin/pkg-config --variable pc_path pkg-config Running: /usr/bin/pkg-config --version Running: /usr/bin/pkg-config --list-all Failed to query pkg-config, Cabal will continue without solving for pkg-config constraints: output of /usr/bin/pkg-config: hGetContents: invalid argument (invalid byte sequence) Resolving dependencies... CallStack (from HasCallStack): withMetadata, called at src/Distribution/Simple/Utils.hs:368:14 in Cabal-3.10.2.1-inplace:Distribution.Simple.Utils Error: cabal: Could not resolve dependencies: [__0] trying: spectrometer-0.1.0.0 (user goal) [__1] trying: lzma-0.0.1.0 (dependency of spectrometer) [__2] rejecting: lzma:+pkgconfig (conflict: pkg-config package liblzma>=5.2.2, not found in the pkg-config database) [__2] rejecting: lzma:-pkgconfig (manual flag can only be changed explicitly) [__2] fail (backjumping, conflict set: lzma, lzma:pkgconfig) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: lzma (8), spectrometer (7), lzma:pkgconfig (3) ``` This is strange, because `/usr/bin/pkg-config --list-all` exits zero, and `/usr/bin/pkg-config --modversion liblzma` outputs `5.4.5`. Here are some `pkg-config` outputs: ``` $ /usr/bin/pkg-config --version 2.1.0 $ /usr/bin/pkg-config --variable pc_path pkg-config /usr/lib/pkgconfig:/usr/share/pkgconfig ``` I have also the output of `/usr/bin/pkg-config --list-all`, available here: [pkg-config-list-all.txt](https://github.com/haskell/cabal/files/13895409/pkg-config-list-all.txt). I'm on Arch Linux (which symlinks `pkg-config` to `pkgconf`), and I suspect this may be related to #8930, which also impacts me. I've been having troubles with `pkg-config` in general (see #8495 and #8494) since Cabal 3.8 when the `pkg-config` logic was changed. The commit in this bug report also does not build on Cabal 3.8.1.0 for me, failing with the same error message. **To Reproduce** `cabal build` on https://github.com/fossas/fossa-cli/tree/64c2f202dc923e3784267cf1d974a952da5baf09 using Cabal 3.8.* or 3.10.* reliably reproduces this issue for me, although it may be because of my machine's specific `pkg-config` database. **Expected behavior** I expect the build to succeed building in Cabal 3.10, since it succeeded in Cabal 3.6, and my `pkg-config` database clearly has the required package. **System information** - Operating system: Arch Linux - Cabal: - Tested with and affects: 3.8.1.0, 3.10.2.0, 3.10.2.1 - Tested with and does not affect: 3.6.2.0-p1 - GHC: 9.4.7

juhp · January 23, 2024, 2:19am

I don’t think it’s a good idea to use LANG=C, unless it is UTF-8 (MacOS?)

Does your system support C.utf8?

bradrn · January 23, 2024, 2:23am

Ah, thanks! Glad to see this is already known.

hasufell · January 23, 2024, 3:48am

This is why more of the ecosystem should be mindful about encodings.

E.g. many specifications imply that you don’t need to know the encoding, because the keywords are defined in the ASCII subset or similar.

E.g. if you look at the implementation of pkg-config, you can see that it essentially compares [Word8]:

Now, why Cabal needs to get the parsed content as interpreted unicode is beyond me.

Abab9579 · January 23, 2024, 7:30am

As far as I’ve seen, the two attempts (Onyx and L-as’) have implemented binding to the protocol. My guess is that some of the necessary functionalities would be exposed through there, and wlroots cannot cover all parts. As for me, one motivation was that it automatically provides a few types that would be used.

Well, I guess you’d prefer me not participating here anyway.

bradrn · January 23, 2024, 7:36am

I’m still really confused about what you’re saying. Could you please provide some links to the projects you’re talking about?

Abab9579 · January 23, 2024, 7:44am

For instance, Ongy’s haskell-wayland package has this one:

github.com

Ongy/haskell-wayland/blob/4a8974dcb0adf50b14e822633f7fc84aaa4afa70/Graphics/Wayland/Scanner/Protocol.hs

module Graphics.Wayland.Scanner.Protocol (
  readProtocol, parseFile
  ) where

import Data.Functor
import Data.Maybe
import Data.Char
import Text.XML.Light
import System.Process
import Language.Haskell.TH (mkName)

import Graphics.Wayland.Scanner.Types
import Graphics.Wayland.Scanner.Names

interface  = QName "interface"  Nothing Nothing
request    = QName "request"    Nothing Nothing
event      = QName "event"      Nothing Nothing
enum       = QName "enum"       Nothing Nothing
entry      = QName "entry"      Nothing Nothing
arg        = QName "arg"        Nothing Nothing

This file has been truncated. show original

This scans the protocol and generates FFI bindings for protocol calls.
I believe there is a reason for doing this, but I do not precisely know why.

bradrn · March 17, 2024, 4:26am

I feel it’s time for another update here. Progress has been slow, but steady thanks to @bullishOnFunctional and @anarchymatt.

The following APIs are now implemented, at least in part:

From libwayland: ~~wl_display, wl_list, wl_listener~~
Basic interfaces: ~~wlr_backend, wlr_renderer, wlr_allocator, wlr_output, wlr_seat~~
Compositing: ~~wlr_compositor~~, wlr_subcompositor, wlr_scene
Window management: wlr_xdg_shell
Input: ~~wlr_input_device, wlr_keyboard~~
Pointer: ~~wlr_pointer~~, wlr_cursor, wlr_xcursor_manager
Clipboard: ~~wlr_data_device~~
Logging: ~~wlr_log~~

Plus some others which are important mostly as dependencies for wlr_output and wlr_seat.

One thing I’d like to do now is to try porting over some of the basic parts of the tinywl compositor which comes with wlroots. It could be a little difficult, though, since wlroots makes intensive use of function pointers, which are hard to marshal. I’m sorely tempted to write the relevant C code and include it directly in the low-level bindings, because otherwise it looks like they’re completely unusable.

Iris · May 11, 2024, 3:04am

I feel it’s time for another update here. Progress has been slow, but steady thanks to @bullishOnFunctional and @anarchymatt.

Do you know where this work is taking place? Is there a git repository that one can contribute to, to aid the effort for wlroots bindings?

bradrn · May 11, 2024, 9:06am

We’ve been working on it here: GitHub - bradrn/wlhs: Haskell bindings to wlroots (and libwayland)

anarchymatt · May 11, 2024, 11:08pm

If you need a primer or the README doesn’t explain enough, please feel free to ask us.

thealio · July 24, 2024, 9:36pm

Regarding wlroots bindings
Hyperland is now based on aquamarine instead of wlroots.
Is it convenient thinking about an haskell fork ?

anarchymatt · August 3, 2024, 8:51am

Sorry, we haven’t been working on this. I injured my wrist and have been abstaining from personal projects, and we kind of stalled out on this PR because we weren’t sure what to do about wlroots C headers that seemingly needed to be checked into the project’s source control for it to build.