ifreund changed the topic of #river to: river - a dynamic tiling wayland compositor - https://github.com/ifreund/river - channel logs: https://freenode.irclog.whitequark.org/river/
leon-p has quit [Quit: leaving]
waleee-cl has quit [Quit: Connection closed for inactivity]
gspe has joined #river
yyp has joined #river
yyp has quit [Remote host closed the connection]
yyp has joined #river
yyp has quit [Remote host closed the connection]
yyp has joined #river
maringuu has quit [Ping timeout: 250 seconds]
maringuu has joined #river
<novakane[m]> so how would you implement per tags layout in rivertile? you need to get the focused tags and then add it to layout_demand?
waffle_ethics has quit [Read error: Connection reset by peer]
waffle_ethics has joined #river
yyp has quit [Ping timeout: 260 seconds]
yyp has joined #river
<ifreund> novakane[m]: the currently focused tags of the output are sent as part of the layout_demand already
<ifreund> I don't think upsteam rivertile should do anything with them, but I'd be curious to see what people use the information for
<ifreund> if nobody use that info or the info in the advertise_view events for something I consider worthwhile before river 1.0 i'll probably remove them :P
yyp has quit [Remote host closed the connection]
<novakane[m]> ifreund: yeah I don't intend to change it upstream, I just made a small modified version for me with monocle layout
<novakane[m]> and it make me curious to how per tags layout would works
<ifreund> well, the layout generator would just generate a different layout depending on which tags were focused
<novakane[m]> btw I don't have the code in front of me right now but there is a small typo in an error message near the end, still river_layout_v1
<novakane[m]> ok so you just need river_layout protocol not river-status to get tags info or something like that
yyp has joined #river
<ifreund> fixed the typo, thanks
gspe has quit [Quit: gspe]
gspe has joined #river
leon-p has joined #river
wrkzk[m] is now known as wrkzkdfa[m]
wrkzkdfa[m] has left #river ["User left"]
snakedye has joined #river
<snakedye> novakane[m] my layout generator has per tag layouts. https://gitlab.com/snakedye/kile/-/blob/main/src/client.rs
<snakedye> if you don't mind rust
<novakane[m]> snakedye: nice that's cool, but yeah I'm trash at reading rust though
<ifreund> It's not just you, reading rust sucks
<snakedye> everyone can agree on that
<leon-p> I have never quite got how to write it either...
<novakane[m]> yep it's a great language but I don't thnik I could motivate myself to learn it right
<snakedye> just unwrap every two line
<ifreund> I got pretty decent at writing rust, but I've grown to disagree with it's design
<leon-p> I was actually half way through the rust book. Then I discovered river and never picked it up again :P
<ifreund> I'd take rust over C++, but that's not saying much. I'd take C over either of them
<leon-p> I even _like_ the borrow checker, I just don't get the rest of the language
<snakedye> I feel like the entire lang is based on the borrow checker
<leon-p> Not all of it. It should be totally possible to create a language with a borrow checker that does not have so much hidden control flow.
<leon-p> or in other words: When I don't know if an operation allocates memeory, I get uneasy.
<ifreund> yep, implicit allocation everywhere
<ifreund> OOM handling thrown to the weeds
<leon-p> I also strongly dislike their stance of "Oh an error occured? Let's crash!"
<ifreund> part of that is standard library design, but that's part of language design IMO
<leon-p> You probably shouldn't try to recover from a SEGFAULT, but OOM can be handled. At least gracefully exiting.
<snakedye> Shouldn't errors crash?
<leon-p> depends on what you call an error.
<ifreund> I define errors as bad things that can happen which aren't caused by a bug
<leon-p> even segfaults don't outright crash. A handler in your program is executed. That is usually defined by the libc, but you can totally overwrite it
<ifreund> and they need to be handled more gracefullyt than an abort in perfect software
<leon-p> also, user input should never lead to a crash
<snakedye> If your software is in a situtation you didn't expect and might be doing thing you are not aware, it should imo
<ifreund> a segfault is not an error by my definition, that should never happen in a perfect program and a panic is the right answer
<leon-p> at segfault totally, I was just giving an example of how "crashing" works
<leon-p> snakedye: if you are truly in an unexpected state then sure. But OOM is not an unexpected state
<leon-p> or at least it should not be
<ifreund> yes it's annoying that memory is not infinite and hardware has limitations, but these are facts of programming
<ifreund> software that doesn't recognize this is not perfect
<leon-p> but that is not a rust problem per se. Lot's of C programmers forget to check if {m,c}alloc() returns NULL
<novakane[m]> programm should just download more memory to be perfect :p
<snakedye> just get a turing machine
<leon-p> Nah, instead get our understanding of math to a point that we can mathematically prove programs. :P
<novakane[m]> yeah computer with billion Go of memory sounds better :p
snakedye has quit [Quit: Connection closed]
waleee-cl has joined #river
<leon-p> small correction to what I wrote before: While on Linux you totally can recover from a segfault (allthough you really should not), POSIX states that the behaviour of a process after execution of the segfault signal handler is undefined, so it may not work on other UNIX-oids
snakedye has joined #river
snakedye has quit [Ping timeout: 240 seconds]
gspe has quit [Quit: gspe]
travankor has left #river [#river]
yyp has quit [Remote host closed the connection]
travankor has joined #river
skuzzymiglet has quit [Remote host closed the connection]
skuzzymiglet has joined #river
snakedye has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]