<LarstiQ>
flower_: not beyond which tags have _a_ window
Keeto has joined #river
TheAnachron has joined #river
ninewise has quit [Remote host closed the connection]
ninewise has joined #river
bitblt_ has joined #river
bitblt has quit [Ping timeout: 245 seconds]
bitblt_ is now known as bitblt
<leon-p>
ok, after spending most of yesterday reading up on it, I have come to the conclusion that I strongly dislike lifetimes and non-immediate values in high-level languages :) and also when I can add a finalizer to a GC'd object, but not some sort of copying hook
<ifreund>
leon-p: I don't understand why you would need a copying hook. Unless I'm mistaken GC'd objects are conceptually never copied
<ifreund>
sure the memory might move around, but from the language user's point of view there should only be one object that stays around until there are no references to it
<leon-p>
so I can increase a reference counter. usually they aren't copied, but there are edge cases. you can do it explicitly with (object-copy ...) of course
choucavalier has joined #river
<ifreund>
doing that would create a second, separate object from the perspective of the GC
<choucavalier>
si there a way to match a NULL title?
<ifreund>
the GC and lanuage runtime would know nothing about the copy
<choucavalier>
s/si/is/
<leon-p>
yes indeed, however that object is a container carrying a c-pointer and I try to sync lifetimes with the object it points to so that invalid pointers are impossible
<ifreund>
choucavalier: you can use the empty string
<choucavalier>
error: invalid glob. '*' is only allowed as the first and/or last character
<leon-p>
i.e. what I want to avoid is a situation where I have to pointers in scheme where eq? and eqv? are #f but pointer=? is #t
<choucavalier>
seems to be interpreted as a glob, which is not what i would like :/
<ifreund>
choucavalier: indeed, it seems that I was mistaken
<ifreund>
leon-p: one solution would be to use handles rather than pointers
<choucavalier>
leon-p: thx for lswt and for packaging it in the AUR btw :)
<leon-p>
you're welcome :) but I did not package it, I am too lazy for that
<ifreund>
give scheme a u64 that you can check if the corresponding object is dead and turn into a pointer on the C side
<leon-p>
yeah that is my last resort
<ifreund>
look up generational indexes
<choucavalier>
ifreund: so no solution to match a null title for now then?
<ifreund>
choucavalier: I guess not :/
<leon-p>
but right now, with the knowledge that at least in chicken importet c-pointers are non-immediate objects, I was trying to sync the lifetime of that object with the lifetime of the object the pointer points to
<ifreund>
it probably wouldn't be hard to fix if you wanted to give it a try
<choucavalier>
no worries, i guess i'll ask Zed people to provide an actual title to their windows..
<ifreund>
that would also be ideal
<ifreund>
leon-p: I feel like this must be a solved problem for embeddable languages like lua using their C api
<leon-p>
the ideal solution would be for the references in scheme to refer to something embedded in the struct of the library rather than an object in the GC's pool, but I don't think chicken offers enough control over their GC for that
<ifreund>
generally the C API for embedding gives you much more control than an ffi in the VM
<leon-p>
yeah, I am also thinking about switching to another language that is better for embedding :/
<ifreund>
maybe chibi scheme has a nice API
<ifreund>
I don't know anything about it other than that it's targeted at embedding
<leon-p>
it's on my list :)
<leon-p>
although today is a lab day, not a reading day
<leon-p>
anyway, still thanks for the keyword of generational indeces. it's really hard to look for ressources when you don't know keywords
<leon-p>
when I was searching for lifetime and GC resources yesterday, I was somehow mostly finding plasma physics papers...
<ifreund>
no problem, I've been thinking of using generational indexes as weak references inside river for a while
<ifreund>
it would make certain things less error-prone
pfr has joined #river
pfr has quit [Client Quit]
<leon-p>
looking forward to seeing how that goes :) my formal programming related education is basically just "how to make this simulation go really fast", so all of this pretty new to me. I have a feeling my way of designing programs is way to pointer reliant
flower_ has joined #river
<flower_>
ok, tried the scratchpad
<flower_>
not sure how useful this is next to toggle focus of tag
<flower_>
There can only be one scratchpad, maybe it would be more useful if you could add more, but again not sure how useful that is next to toggle focus of tag
<flower_>
are you guys using tools to show which application is on which tag? Some rofi show windows thing for river?
<Nickli>
scratchpad is effectively a toggle tag
<flower_>
I see
<flower_>
I've used dwm a lot, but completely missed this feature :) Will learn myself using it as it's nice
<flower_>
toggle tag
<ifreund>
leon-p: by the way, are you 100% sure that the deep-copy thing you mentioned actually works on c-pointers and isn't just a runtime error or something?
<ifreund>
If I was designing a language, I would disallow that
<LarstiQ>
pretty sure that works
<LarstiQ>
it's a classical shallow/deep copy of containers
<LarstiQ>
leon-p: pypy also uses handles to deal with cpython c-api emulation which has refcounting and pypy internals which has moving gc (with indeed generations and nurseries)
<ifreund>
LarstiQ: in lua for example, userdata values cannot be created or modified in the lua language, only through the C API
<ifreund>
it is impossible to write a deep copy function in lua that copies a userdata value
<ifreund>
this is the only sensible way to design this kind of FFI in my opinion, so I would be surprised to learn that scheme implementations do not do this
<leon-p>
yes, copying the object that contains the c pointer does work and creates a new separate object, rather than a reference to the original. the pointer is the same though
<leon-p>
another problem is of course if you get the same pointer from two different sources: f.e. you get a *window when a new window arrives, and later another *window when you get the window-interaction event
<ifreund>
leon-p: that sounds like the c pointer value isn't copied though, i.e. finalize will be called only once when both objects containing the c pointer are garbage collected
<leon-p>
eq? #f, eqv? #f, pointer=? #t, to me that means the value is copied
<leon-p>
FWIW I think guiles FFI is a lot better here than chickens: it keeps a list of all foreign pointers and compares new ones against the list to prevent creating two objects holding the same pointer
<leon-p>
you can play around with this in the repl btw: (import (chicken gc)) (import (chicken memory)) (import (chicken memory representation)) (define ptr (allocate 16)) (set-finalizer! ptr free) (define ptr-2 ptr) (define ptr-3 (object-copy ptr))
<leon-p>
call (gc #t) to trigger hard collection with pending finalizers
<ifreund>
I believe you, sounds like chickens C API is insufficient for this use case then though maybe we are holding it wrong
<ifreund>
I think I will personally use either lua or janet for wm logic, haven't decided which yet
<leon-p>
looked at janet briefly again yesterday, but I didn't see the kind of control over the gc I was missing from chicken, so I disimissed it again. might give it another look now that I am no longer married to the idea of syncing lifetimes
<ifreund>
leon-p: in janet, you would define an abstract type using the C API
<ifreund>
it's the same principle as userdata in lua that I described above
<ifreund>
but even more flexible in some ways I think
<ifreund>
the docs aren't terribly great/complete but I'm pretty sure everything is there
<leon-p>
if it gives me a way to create an object that can't copied and where I am in control of the lifetime, it might be exactly what I need
<leon-p>
although generational indeces also look promising
<leon-p>
well, I am not in a rush :)
<LarstiQ>
it looks to me chicken's ffi is lower level to accomodate more different usages and you have to build your own if you are interested in this case
<ifreund>
yeah, generational indexes would probably be the way to go if you want to share the most code possible between supported languages
<ifreund>
every language can handle a foreign integer
<leon-p>
LarstiQ: chickens FFI is basically just "we compile to C anyway, so let's automate type conversion between 'real' C functions and C functions generated from scheme"
<leon-p>
that's also why the FFI doesn't work in the repl, only for compiled code
<LarstiQ>
aha!
<leon-p>
I suppose if you're not exactly dealing with waylands pointer soup, it works reasonably well
<leon-p>
*libwayland
<ifreund>
a data-oriented wayland implementation that uses generational indexes rather than pointer soup would be nice
<ifreund>
but then I would have to rewrite wlroots to be able to actually use it
<ifreund>
and I don't think I have time for that
<leon-p>
for clients alone it would be useful as well, but I too have a life, so I won't be the one writing that one
<leon-p>
ok, generational indeces are painful in C unless you make it inefficient by having a list of void pointers so it can be generic...
elshize has joined #river
deadcade has quit [Read error: Connection reset by peer]
deadcade has joined #river
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
babo67_ has quit [Remote host closed the connection]
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
<ifreund>
not having generics does indeed suck
<leon-p>
going to generational indeces would be a big enough rewrite that I may as well just switch to zig, maybe
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
kraem has quit [Remote host closed the connection]
kraem has joined #river
pfr has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
graves has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
pfr has quit [Remote host closed the connection]
pfr has joined #river
catman has quit [Ping timeout: 265 seconds]
pfr has quit [Remote host closed the connection]
catman has joined #river
<ifreund>
finished up the implementation of the new rwm update sequence design, seems to work great so far :)
<ifreund>
indeed, using this information would not be reliable as it says in that issue
<flower_>
so then it's a design decision to decide whether to expose it (while not reliable 100%) or not I suppose
Guest47 has joined #river
<ifreund>
If people want to use the unreliable information to do stuff like that swallowing hack it's fine by me
<ifreund>
I don't have to deal with the bug reports
<ifreund>
I won't be doing that kind of stuff in my own wm though
<flower_>
I see. You're not afraid that people come up with feature request based on what they want to do with the pids?
Guest47 has quit [Client Quit]
<ifreund>
river will only concern itself with implementing the river window management protocol, its not my problem what window managers choose to do with the information exposed
<ifreund>
the bug reports will go to window managers if their usage of the pid info documented as unreliable in the window management protocol is problematic
<flower_>
Fair enough. You could also say, it's not reliable therefor we don't expose it. No pids no problem.
<ifreund>
well, that's the approach that will get *me* endless feature requests that I can't instantly close as "not my problem"
<ifreund>
also it's perfectly valid for people to use things that aren't 100% reliable for window management policy
<ifreund>
I don't control what people want
<flower_>
fair enough, I was just interested in how you saw this as a project maintainer
<leon-p>
I don't even know what you'd do with the PID, other than maybe try to kill a hanging program or set niceness based on focus 🤷
<leon-p>
ifreund: do you already have a generational indeces abstraction in zig? I was thinking of maybe wrapping multi array list
<leon-p>
I think it should be possible to intercept the child struct and add a generation field automatically
<ifreund>
leon-p: I don't have one handy. I don't think you can use a multi array list as the backing data structure if you need pointer stability for the values stored
<ifreund>
which you might if you are storing pointers to the objects somewhere on the zig/C side, idk
<ifreund>
references/keys should probably be `packed struct(u64) { generation: u32, index: u32 }`
<ifreund>
and the data structure should conceptually store an array of `struct {generation: u32, value: T }`
<ifreund>
if you want pointer stability it would have to be a segmented list rather than an array though for example
<leon-p>
makes sense
<ifreund>
(by segmented list I mean essentially a linked list of pages, like an arena allocator)
<leon-p>
there is a segmented list implementation in zig std, I'll just use that
<ifreund>
I guess "slotmap" may be a standardish name for this thing
<leon-p>
yeah, I already wrote on in C a few hours ago. Just asking if you have a zig version I can borrow :)
<leon-p>
it's fairly straight forward once you get the concept
<ifreund>
cool :)
<ifreund>
leon-p: by the way, are you going to want to send keyboard input to decoration surfaces?
<ifreund>
or is that a cursed thing nobody will actually want me to support
<leon-p>
I don't think I want that, no
<leon-p>
I absolutely do not want to deal with the concept of the decoration of a window being focusable
<ifreund>
well I assume you want to get pointer events, so it will get pointer focus
<leon-p>
true
ninewise has quit [Remote host closed the connection]
<leon-p>
but keyboard not IMO. If someone needs that for some UI, they can create a shell surface over the window
<ifreund>
it wouldn't be technically hard to give it keyboard focus either I don't think, just not sure if there's really a use case
ninewise has joined #river
<leon-p>
no usecase that can't be achieved with just creating a transient shell surface I think
<leon-p>
f.e. hikari has text entry fields in it's window decoration, but I don't see how that can't be replicated with a shell surface
<ifreund>
yeah, it would probably be easy to add later if we change our minds in any caes
<leon-p>
pointer events are relevant though. f.e. people may want to implement "shading" a window by scrolling on its titlebar
<leon-p>
I actually think I don't need pointer stability btw. the user-data of the wayland objects can just be the key. I think I can just assume that the key from an object from a wayland event is always valid and skip the generation checking. Then it's just accessing an array by index, with is really just storing an offset to a known pointer, same thing really
<ifreund>
makes sense
<ifreund>
I now have decoration surfaces implemented in river in theory and now need to write some hacky code in rivercompat to test them
<leon-p>
dam, than I better get to the point where I can draw something
<ifreund>
things could theoretically move pretty fast now if the hard parts really are solved satisfactorily
<leon-p>
sounds good, even if that's bad for my free time :)
br0qn has joined #river
mtm has quit [Ping timeout: 248 seconds]
mtm has joined #river
deadcade has quit [Read error: Connection reset by peer]
deadcade has joined #river
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
elagost has quit [Remote host closed the connection]
elagost has joined #river
Keeto has quit [Ping timeout: 260 seconds]
user21 has joined #river
br0qn has quit [Remote host closed the connection]