12:11 <leon-p> my strategy of stopping to work on a problem for a month to then suddenly find a solution while working on something completely different has succeeded again

12:12 <leon-p> I think I have solved the issue of lifetimes of antares objects. if I implement my idea, it should be impossible to have invalid C pointers in scheme code

12:13 <leon-p> basically, I am introducing ref counting and the lifetime of antares object struct are not an OR of the lifetime of the underlying wayland object and ref > 0

12:14 <leon-p> this works because in chicken scheme I can set a finalizer on arbitrary objects (including pointers) which is called when the object is no longer reachable and swept by the GC, so it can be automatically un-ref'd

12:16 <leon-p> this solves one of the two major icks I have with the projects / codebase in a clean way that should even work well for all scripting languages that have a similar feature

12:27 <LarstiQ> leon-p: does that work with cycles or can those not occur?

12:28 <leon-p> I am not sure I understand what you mean with cycles

12:28 <LarstiQ> because that's certainly an issue with CPython that not everyone takes into account

12:28 <LarstiQ> leon-p: cycles in the object references graph so that they keep each other alive for the reachability check

12:30 <leon-p> all references between atares objects are done in C as C pointers

12:31 <leon-p> all the scripting language ever sees of an antares object is a pointer (how ever it may choose to represent / wrap that)

12:32 <leon-p> I guess you could use the user data pointer to store a reference to GC managed code, but at that point it's really your own fault IMO

12:32 <LarstiQ> right

12:32 <leon-p> s/code/memory

12:33 <leon-p> actually what I am more concerned about is how often the finalizer is called in this snippet: (define a 2)(let ((b a)) ...)

12:46 <leon-p> absolutely no idea how to introspect a garbage collector, however just allocating memory, setting a finalizer that frees it, then copying the pointer before exiting the scope completely , in an infinite loop, does seem to call the finalizer, but does not result in a double free, so I guess it's fine?

12:46 <leon-p> let's just hope that copy wasn't optimized out or something, not sure if the REPL optimized...

12:46 <leon-p> *optimizes

12:57 <leon-p> ok, new rabbit hole: copying semantics...

13:56 <flower_> I don't get Super+Shift+Control in sh init yet

14:34 <leon-p> flower_: what exactly is the issue?

14:38 <flower_> leon-p: I don't see what it does

14:48 <leon-p> So you are pressing the keybind but the action that is configured doesn't work?

14:49 <leon-p> or do you mean you don't understand what a binding in the example init does?

14:49 <leon-p> please be more explicit

15:24 <flower_> I don't understand what it should do exactly

15:27 <flower_> ah it adds the focused window to the other tag

17:28 <flower_> yep, I like how you can toggle focus of a tag, nice work

17:34 <flower_> ok that's also in dwm, I did miss that :)

21:37 <flower_> Do you guys use tools to make visible which applications are active on which tag?