14:07 <bw> hmm... what version of zig should i be using for building river? i'm getting this `.zig:68:79: error: root struct of file 'ascii' has no member named 'spaces'`

14:23 <tleydxdy[m]> 0.9.1

14:25 <bw> yeah, i thought i was but i guess not

15:00 <plumeus> It's funny because the River README has the necessary Zig version explicitly stated.

17:08 <leon-p> nice to see that firefox still knows how to have fun: "error marshalling arguments for set_surface (signature o): null value passed for arg 0"

17:08 <leon-p> happens for about 1 out of 20 XDG-popups, like tooltips

17:09 <leon-p> wondering whether river or ff is to blame here

17:26 <ifreund> Hmm, I haven't seen that one yet

17:27 <ifreund> set_surface is an xdg-activation request and that error is from client side libwayland

17:28 <ifreund> firefox is passing a null surface to libwayland's marshalling function. Regardless of what river's doing that is a firefox bug

17:28 <leon-p> I see, I was initially assuming that the warning was about libwayland being unable to marshall something river sent it

17:28 <leon-p> althogh that would be un-marshalling, I guess

17:29 <ifreund> yeah, "demarshalling" is what libwayland calls going from the wire protocol to C API

17:30 <ifreund> and marshalling is the other way around

17:30 <leon-p> since it's xdg-activation specific, I wonder how long firefox keeps around activation tokens and whether it tries to use them multiple times

17:30 <leon-p> debugging firefox is unfortunately not a nice experience

17:31 <ifreund> not at all :/

17:35 <leon-p> xdg-open $URL: no token, firefox $URL: token, but foots URL selector mode, which is configured to just call xdg-open, apparently does provide a token?

17:36 <ifreund> foot probably sets the environment variable when it calls xdg-open

17:36 <ifreund> xdg-open can't do it as it's not a wayland client

17:36 <leon-p> seems to be the wrong part of the stack to get the token, but ok