04:40 <Nulo> I left my computer locked in idle and when I came back river crashed. GDB: https://0x0.st/ooVA.log | Last logs: https://0x0.st/ooVm.log

10:55 <ifreund> Nulo: Thanks, really unfortunate that you don't have wlroots/libwayland debug symbols though...

10:55 <ifreund> Not really much to go on without those sadly

19:08 <Nulo> ifreund: I'm dumb, I do have them: https://0x0.st/ooyx.log

19:12 <tiosgz`> Nulo: they're still missing for wlroots

19:12 <ifreund> i don't know, wlr_signal_emit_safe shows up

19:13 <Nulo> Whoops. I'm not sure what that's about; I installed wlroots-dbg

19:13 <ifreund> Nulo: how comfortable are you with gdb? could you go to the wl_closure_invoke frame and print me something?

19:13 <ifreund> target->interface->name

19:13 <tiosgz`> ifreund: isn't that because it's in the public API?

19:13 <ifreund> in gdb commands that's

19:13 <ifreund> f 11

19:14 <ifreund> p target->interface->name

19:15 <Nulo> > value has been optimized out

19:16 <tiosgz`> "it's in the public API" <-- oh wait it isn't. but it's weird that #8 can't be decoded

19:16 <ifreund> hrm, mabye try object->interface->name in frame 12?

19:16 <ifreund> tiosgz`: probably because it's an indirect call

19:17 <Nulo> ifreund: wl_surface

19:17 <ifreund> alright, let me go see what opcode 6 is...

19:19 <ifreund> looks like that's wl_surface.commit

19:22 <ifreund> so it seems something got destroyed but didn't remove its wl_surface.events.commit listener

19:40 <ifreund> Nulo: I found I a bug that could potentially yield that stack trace and pushed a fix, let me know if it happens again

19:40 <ifreund> did you ever hit https://github.com/riverwm/river/issues/483 again by the way?

20:32 <Nulo> ifreund: I don't think I hit it again

20:56 <ifreund> cool, I think I'll close it then. If it ever happens again we can reopen it of course

21:12 <mon_aaraj> i know this sounds a little choosy but wouldn't it be nice to have first class next/prev tag focusing support rather than having an external py script?

21:12 <mon_aaraj> i mean, you said it yourself, your goal with river is not to get people to glue things together, i think the python script especially is the part that's the most awkward in that regard personally

21:13 <mon_aaraj> i would offer to help implement this, but i have no idea how zig works let alone zig-wayland, but i might be able to monkeypatch enough to make a PR if i am productive enough

21:15 <ifreund> I agree that there should be a better way to get that functionality than a random python script, but I intend to fix that by moving that logic outside of river instead of adding everyone's personal favorite window mangements feature to the wayland server

21:16 <mon_aaraj> yeah, i think that might be a good idea

21:17 <mon_aaraj> what's the specifics of the plan you have in mind?

21:20 <ifreund> there will be a custom river-window-mangament wayland protocol and the window manager will be implemented as a wayland client

21:20 <ifreund> don't expect this to happen in the next few months though, there's a lot of work to do before we get there

21:29 <mon_aaraj> yep, i got that, thank you so much for answering!

21:30 <ifreund> no problem!