08:30 <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?

12:21 <ifreund> novakane[m]: the currently focused tags of the output are sent as part of the layout_demand already

12:22 <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

12:23 <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

12:37 <novakane[m]> ifreund: yeah I don't intend to change it upstream, I just made a small modified version for me with monocle layout

12:38 <novakane[m]> and it make me curious to how per tags layout would works

12:38 <ifreund> well, the layout generator would just generate a different layout depending on which tags were focused

12:40 <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

12:40 <novakane[m]> ok so you just need river_layout protocol not river-status to get tags info or something like that

12:49 <ifreund> fixed the typo, thanks

15:43 <snakedye> novakane[m] my layout generator has per tag layouts. https://gitlab.com/snakedye/kile/-/blob/main/src/client.rs

15:49 <snakedye> if you don't mind rust

15:51 <novakane[m]> snakedye: nice that's cool, but yeah I'm trash at reading rust though

15:51 <ifreund> It's not just you, reading rust sucks

15:52 <snakedye> everyone can agree on that

15:54 <leon-p> I have never quite got how to write it either...

15:56 <novakane[m]> yep it's a great language but I don't thnik I could motivate myself to learn it right

15:56 <snakedye> just unwrap every two line

15:56 <ifreund> I got pretty decent at writing rust, but I've grown to disagree with it's design

15:57 <leon-p> I was actually half way through the rust book. Then I discovered river and never picked it up again :P

15:57 <ifreund> I'd take rust over C++, but that's not saying much. I'd take C over either of them

15:57 <leon-p> I even _like_ the borrow checker, I just don't get the rest of the language

15:58 <snakedye> I feel like the entire lang is based on the borrow checker

15:59 <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.

16:00 <leon-p> or in other words: When I don't know if an operation allocates memeory, I get uneasy.

16:00 <ifreund> yep, implicit allocation everywhere

16:01 <ifreund> OOM handling thrown to the weeds

16:01 <leon-p> I also strongly dislike their stance of "Oh an error occured? Let's crash!"

16:01 <ifreund> part of that is standard library design, but that's part of language design IMO

16:03 <leon-p> You probably shouldn't try to recover from a SEGFAULT, but OOM can be handled. At least gracefully exiting.

16:03 <snakedye> Shouldn't errors crash?

16:03 <leon-p> depends on what you call an error.

16:04 <ifreund> I define errors as bad things that can happen which aren't caused by a bug

16:04 <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

16:04 <ifreund> and they need to be handled more gracefullyt than an abort in perfect software

16:04 <leon-p> also, user input should never lead to a crash

16:05 <snakedye> If your software is in a situtation you didn't expect and might be doing thing you are not aware, it should imo

16:05 <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

16:05 <leon-p> at segfault totally, I was just giving an example of how "crashing" works

16:06 <leon-p> snakedye: if you are truly in an unexpected state then sure. But OOM is not an unexpected state

16:06 <leon-p> or at least it should not be

16:07 <ifreund> yes it's annoying that memory is not infinite and hardware has limitations, but these are facts of programming

16:07 <ifreund> software that doesn't recognize this is not perfect

16:07 <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

16:08 <novakane[m]> programm should just download more memory to be perfect :p

16:08 <snakedye> just get a turing machine

16:10 <leon-p> Nah, instead get our understanding of math to a point that we can mathematically prove programs. :P

16:15 <novakane[m]> yeah computer with billion Go of memory sounds better :p

17:14 <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