<ifreund>
pretty out of date wlroots version now though
talismanick has quit [Read error: Connection reset by peer]
notzmv has quit [Ping timeout: 260 seconds]
talismanick has joined #river
notzmv has joined #river
notzmv has quit [Ping timeout: 265 seconds]
larstiq has joined #river
<larstiq>
would a rwm fuzzer that randomly mutates windows and minimizes crashses be feasible to write?
<leon-p>
LarstiQ: to test the WM? sure, that wouldn't be too hard. but at least in my case also not too useful (yet?) since all errors I've had sofar are non-deterministic
<larstiq>
there might still be a class of errors that can also be found in a deterministic way I suppose?
<larstiq>
but yeah no idea how much large a fraction
<larstiq>
trying to learn pysat first though :)
notzmv has joined #river
fitrh has joined #river
fitrh has quit [Ping timeout: 252 seconds]
mtm has quit [Ping timeout: 252 seconds]
mtm has joined #river
<leon-p>
huh, disabling guiles garbage collector seems to "solve" the issue. Let's hope it just swipes one of the callbacks or anything in the scheme code and doesn't somehow think it can modify memory that belongs to antares or libwayland...
Guest3434 is now known as JetpackJackson
fitrh has joined #river
<ifreund>
larstiq: sure, an rwm window manager that Fuzzes river would be cool
<ifreund>
it would be a bit limited without instrumentation of the river binary though
<larstiq>
ifreund: what kind of instrumentation are you thinking of?
<ifreund>
and one would probably also need to generate virtual input events and whatnot
<ifreund>
its a big project, but it would be quite handy if someone could figure out how to make it work
<leon-p>
a simpler start may to write a fuzzer which pretends to be a wayland client and sends river weird / unusual behaviour
<leon-p>
got it, no more crashes!
<leon-p>
the garbage collector lost track of the callbacks and sweeped them
<leon-p>
defining them as toplevel constants rather than inlined lambdas in the antares-get-context call fixed that
fitrh has quit [Read error: Connection reset by peer]
<leon-p>
now I'll bind river_seat and see if I can get rudimentary window management working
catman has quit [Quit: WeeChat 4.5.1]
catman has joined #river
<ifreund>
nice :)
elshize has joined #river
Keeto has joined #river
Keeto has quit [Client Quit]
<leon-p>
I wonder if the pointer-activity event should be something you opt into
<leon-p>
since it's not actually send yet, I am not sure what the performance looks like, but I am not happy thinking about a high-refresh mouse with whatever amount of GHz is fashionable right now waking up a scheme event handler on every update...
<ifreund>
yeah, I don't like that event's existence
<ifreund>
If we can come up with a better way to make focus-follows-cursor always possile I'd love to drop it
<ifreund>
maybe it's ok to only send it once at the start of a pointer motion though
<leon-p>
since that's the only (known) use-case, maybe we can make it more explicit? Like pointer-activiy on non-focused / obstructed window
<ifreund>
and not send it again until there is some other input that is not a pointer motion, and then another pointer motion
<leon-p>
oh, that sounds good
<ifreund>
(this was my vague idea when I switched to a more abstract pointer_activity from a concrete absolute pointer position)
<leon-p>
we could do it (or (once per window the mouse moves over) (once per 1 second)) or something like that
<ifreund>
we already have pointer_enter_window/pointer_leave_window as well
<leon-p>
true
<leon-p>
so apparently with the geiser package for emacs I can attach a repl to a running antares instance, adding hooks / rewriting logic without having to re-start the WM and introspect all variables live
<leon-p>
which in turn also means I technically have IPC already