01:38 < bridge> lerato 04:37 < bridge> 5 am, im finally done with 1st site in my life 04:37 < bridge> hope last 04:37 < bridge> rate pls 04:37 < bridge> https://stormaxs.github.io/StA-site/ 05:33 < bridge> <_voxeldoesart> wait what 05:33 < bridge> <_voxeldoesart> LERP tee animation? 05:33 < bridge> <_voxeldoesart> what does that mea 05:35 < bridge> <_voxeldoesart> also @stormaxd is it alright that i give out thoughts about this client? 05:36 < bridge> Linear interpolation 05:36 < bridge> Ofc, go for it 05:37 < bridge> <_voxeldoesart> on 2560x1440 the buttons arent centered LOL 05:37 < bridge> <_voxeldoesart> https://cdn.discordapp.com/attachments/293493549758939136/1186527605508284461/image.png?ex=659392f1&is=65811df1&hm=43cf6054bc6a56f729dfb86d4b6f55dabd3a46b1d1b49d2c92fd176c14724c4e& 05:37 < bridge> I fixed it already 05:37 < bridge> Someone reported me when i released it last time 05:38 < bridge> Cause im planning to done with stat page and only then make a new release 09:06 < bridge> The logo is missing an "r" 09:07 < bridge> STA CLIENTR 09:07 < bridge> troll 09:09 < bridge> Trollr 09:09 < bridge> Star client?:poggers2: 09:10 < bridge> 😏 09:10 < bridge> Also add ✪ 09:10 < bridge> I can't 09:11 < bridge> I haven't sleep almost 2 night 09:11 < bridge> Let me 09:11 < bridge> Sleep :pepeLost: 09:11 < bridge> Ok, you can sleep for 10 minutes 09:12 < bridge> :Deadge: 09:12 < bridge> :blushWokege: 09:14 < bridge> how dare he 09:14 < bridge> stop sleeping - go work 09:14 < bridge> alr alr 09:15 < bridge> 1 buf fix 10:13 < bridge> Rust needs a 'inline lifetime, that makes sure a reference is only valid for a single expression. Would be cool and useful 10:15 < bridge> i mean cant u do that with a block {} 10:16 < bridge> ```rust 10:16 < bridge> let b = 2; 10:16 < bridge> { 10:16 < bridge> let b = &b; 10:16 < bridge> } 10:16 < bridge> ``` 10:16 < bridge> use shadowing to achieve it 10:16 < bridge> idk 10:16 < bridge> I mean e.g. if i return a mut ref from function call 10:16 < bridge> That you can't truly borrow this result 10:16 < bridge> @jupeyy_keks there is something called fnonce 10:16 < bridge> https://doc.rust-lang.org/std/ops/trait.FnOnce.html 10:16 < bridge> Instances of FnOnce can be called, but might not be callable multiple times. Because of this, if the only thing known about a type is that it implements FnOnce, it can only be called once. 10:17 < bridge> idk how u could achieve that u want xd 10:17 < bridge> but if u can only use the ref inside a fnonce 10:17 < bridge> maybe its possible 10:17 < bridge> Well what i actually want is to return a Ref<'inline, T> 10:17 < bridge> Xd 10:17 < bridge> xd 10:18 < bridge> OnceCell? 10:18 < bridge> ah no this is to write 10:18 < bridge> idk 10:18 < bridge> Yeah dunno. 2024 edition clearly needs a new rfc 😬 10:18 < bridge> well u should explain ur use case in depth 10:20 < bridge> Yeah i want to return a borrow_mut. 10:20 < bridge> But this is unsafe, in logic sense, in combination with rc because you could end up borrow twice. But if the borrow would end every line+ i have a strict hierarchy of my types => safe af 10:21 < bridge> Rn i am emulating with by not allowing public types and rewrite the public interface with a proc macro 10:22 < bridge> Works well, but more hidden logic xdd 10:23 < bridge> With some inline lifetime i could use deref trait 10:23 < bridge> Would be clean af 10:25 < bridge> deref should only be used by smart pointers btw 10:25 < bridge> > Implementing Deref for smart pointers makes accessing the data behind them convenient, which is why they implement Deref. On the other hand, the rules regarding Deref and DerefMut were designed specifically to accommodate smart pointers. Because of this, Deref should only be implemented for smart pointers to avoid confusion. 10:25 < bridge> > 10:25 < bridge> > For similar reasons, this trait should never fail. Failure during dereferencing can be extremely confusing when Deref is invoked implicitly. 10:25 < bridge> > 10:26 < bridge> > Violating these requirements is a logic error. The behavior resulting from a logic error is not specified, but users of the trait must ensure that such logic errors do not result in undefined behavior. This means that unsafe code must not rely on the correctness of this method. 10:26 < bridge> Well mine would be smart wrapper 10:37 < bridge> the doc was recently updated btw: 10:37 < bridge> https://github.com/rust-lang/rust/commit/58645e06d9121ae37654b812d14041d0229d49c3 10:39 < bridge> so no smart-pointer 10:39 < bridge> 10:39 < bridge> it must be fail safe, the wrapper type should not have API collisions 10:39 < bridge> also should not != must not 😉 10:42 < bridge> With some inline lifetime i could use deref trait (the inline lifetime also needs other requirements, but too much to list them) 10:43 < bridge> With some inline lifetime i could use deref trait (the inline lifetime also needs other requirements, but too much to list them, e.g. no inline lifetimes twice, or specific evaluation order of calls etc. xd) 10:43 < bridge> Can't you take the mut borrow out of the rc? 10:44 < bridge> what do you mean? 10:44 < bridge> the whole Rc> would be wrapped in a smart wrapper 10:45 < bridge> so u can never acess the refcell interface directly 10:46 < bridge> Yes that's sort of what I meant 10:46 < bridge> i mean i didnt 100% think though the best solution, but i think it would have potential xdd 10:46 < bridge> i mean i didnt 100% think through the best solution, but i think it would have potential xdd 10:47 < bridge> Or whatever function is returning the mut borrow would take the rc in exchange 10:47 < bridge> but i can clone Rcs 10:48 < bridge> But the refcell wont allow a second mut borrow and enforce it at runtime 10:48 < bridge> yes that's exactly what i dislike xD 10:48 < bridge> at runtime xD 10:48 < bridge> Ah you want to avoid the refcell? 10:49 < bridge> i want to avoid lifetime (rc) but also the problem of calling borrow_mut twice (refcell) 10:49 < bridge> i have a solution for this, it's just not nicest to use, bcs it requires adding proc macros to many types.. so it's also not enforced in that sense anyway 10:50 < bridge> the 'inline would also not enforce it, but it would make my solution more elegant xD 10:51 < bridge> e.g. if you never have cycling refs (not even with Weak) ,also not by passing Rcs around, you should™️ never have problems and still have the benefits of Rc 10:52 < bridge> oh and hierarchically it is not allowed to have the same Rc on a child component if the parent has it already 10:52 < bridge> Well idk your specifics but there isn't much harm in a refcell if that's the only way to ensure safety that's the only way to do it. It's just 1 branch 10:53 < bridge> you are right and if you have a private field that is a refcell it's relatively safe 10:53 < bridge> i also try to do it, if i use it. 10:53 < bridge> 10:53 < bridge> i guess i am in adventurer mode rn xd 10:56 < bridge> the only problem is smth like this: 10:56 < bridge> 10:56 < bridge> ```rs 10:56 < bridge> struct A { r: Rc<...> } 10:56 < bridge> struct B { r: Rc<..>, a: A } // same rc as above 10:56 < bridge> 10:56 < bridge> impl A { fn func() {r.borrow_mut().dosmth}} 10:56 < bridge> impl B { fn func() {let borrowered = r.borrow_mut(); 10:56 < bridge> a.func(); // panic bcs and b will borrow_mut 10:56 < bridge> }} 10:56 < bridge> 10:56 < bridge> 10:56 < bridge> let b = B::...; 10:56 < bridge> b.func(); 10:56 < bridge> ``` 10:56 < bridge> the 'inline lifetime could also also disallow being passed to a function etc. 10:57 < bridge> well as said it only works under certain conditions, but it defs help to fuck up less in my case without having to have so many proc macros 10:57 < bridge> the only problem is smth like this: 10:57 < bridge> 10:57 < bridge> ```rs 10:58 < bridge> struct A { r: Rc<...> } 10:58 < bridge> struct B { r: Rc<..>, a: A } // same rc as above 10:58 < bridge> 10:58 < bridge> impl A { fn func() {r.borrow_mut().dosmth}} 10:58 < bridge> impl B { fn func() {let borrowered = r.borrow_mut(); 10:58 < bridge> a.func(); // panic bcs a and b will borrow_mut at same time 10:58 < bridge> }} 10:58 < bridge> 10:58 < bridge> 10:58 < bridge> let b = B::...; 10:58 < bridge> b.func(); 10:58 < bridge> ``` 11:01 < bridge> now i am motivated to write test cases for my macro to find some of its limitations 11:01 < bridge> 11:01 < bridge> thanks for movation 😏 11:13 < bridge> Yeah this is suboptimal calling the functions while holding a borrow leading to a panic is bizarre feeling 11:14 < bridge> its enforcing the borrow checker at runtime 11:14 < bridge> I'm more curious as to how you'd allow this pattern 11:15 < bridge> whats the pattern i didnt read i was trying to fix my lalrpop pascal parser :/ 11:15 < bridge> > "array" "[" > "]" "of" => ast::Type::Array { 11:15 < bridge> > index, 11:15 < bridge> > component: Box::new(c), 11:15 < bridge> > packed: p.is_some(), 11:15 < bridge> > }, 11:15 < bridge> > and looking at a token `Eof` we can reduce to a `CommaNoTrailing<"identifier">` but we can also reduce to a `SemiColonNoTrailing` 11:15 < bridge> im dying 11:16 < bridge> Technically while `a.func()` is happening you are already holding a mut ref outside it so it panics, but technically it's sane. The second mut borrow is the only one in scope 11:16 < bridge> Like a two phase borrow 11:17 < bridge> You can get rid of the refcell too. I'm just curious how a seasoned rust veteran would structure it 11:19 < bridge> @jupeyy_keks is this components and cgameclient btw? 11:19 < bridge> That's the sort of relationship those have 11:19 < bridge> well you can do lot of stuff without Rc. sadly this can always increase complexity, by a lot, bcs u need to pass so much stuff around. 11:19 < bridge> 11:19 < bridge> Generally i think this isn't even bad, it's just that i want to have some modules be very easy to use 11:20 < bridge> generally u want to structure ur code to avoud refcells at all 11:20 < bridge> for me it's more the interaction with the graphics component by two or more components 11:20 < bridge> and still you use all these fancy libs that have a slim api. bcs they internally have Rc or Arcs 11:21 < bridge> this code doesnt make sense, where do u get r in the B impl block 11:21 < bridge> as said, it's a matter of simplicity 11:21 < bridge> Yep that works too. So I guess the proper solution is for the components to not hold a ref to the graphics component 11:21 < bridge> what libs 11:21 < bridge> it's pseudo code 11:21 < bridge> i dunno, like 90% of the libs allow me to clone their instance of whatever 11:22 < bridge> ??? 11:22 < bridge> Yeah libs wrap their contexts in arcs 11:22 < bridge> i hate arguments like that, u cant argue cuz its so vague 11:22 < bridge> if you have a tokio runtime, u can just clone it and it's the same instance 11:22 < bridge> 11:22 < bridge> if you clone some sound lib, you can clone the runtime and it will just work 11:22 < bridge> Anyway, why are you arguing? RefCell bad has nothing to do with Arc bad 11:23 < bridge> yeah arc is kinda the way to share refs between threads 11:23 < bridge> well Arc has the exact same problem xD 11:23 < bridge> they want to allow send 11:23 < bridge> They don't require runtime borrow checking 11:23 < bridge> true, it's even worse there 11:23 < bridge> dead lock 11:23 < bridge> well thats what uget when dealing with MT 11:23 < bridge> but a arc alone wont deadlock u 11:23 < bridge> its when u use a lock 11:24 < bridge> consider refcell like a single thread lock 11:24 < bridge> yeah, but u cannot use arc and then write an API xd 11:24 < bridge> 11:24 < bridge> is that a read-only API or what? XD 11:24 < bridge> but ucant block xd 11:24 < bridge> Anyway can we not drift away? How would one solve this? Just establish a hierarchy so you only pass a reference down instead of keeping an Rc everywhere? 11:24 < bridge> btw 11:25 < bridge> u have try_borrow 11:25 < bridge> iirc 11:25 < bridge> u can borrow from the rc on a upper level and pass a plain ref down 11:25 < bridge> i mean B can read the rc of A. and if the borrow_mut would be guaranteed inline, without side effects, it would not compile 11:25 < bridge> so yes, that is kinda my plan 11:26 < bridge> my problem isn't so much about that you have to redsign this call a bit. 11:26 < bridge> 11:26 < bridge> it can simply happen without you noticing it 11:26 < bridge> that's what i dislike about it 11:27 < bridge> Yeah, so I guess just don't have multiple references, pass it down instead 11:28 < bridge> s\/references/Rcs/ 11:28 < bridge> yep, but for the graphic instance it would suck to always pass it around. 11:28 < bridge> 11:28 < bridge> and i have a usecase where i potentially allow borrowing parts of the graphics api. so if 2 comps have the graphics cloned, this is problem xdd 11:29 < bridge> ```rust 11:29 < bridge> use std::{cell::RefCell, rc::Rc}; 11:29 < bridge> 11:29 < bridge> struct A { 11:29 < bridge> r: Rc>, 11:29 < bridge> } 11:29 < bridge> 11:29 < bridge> struct B { 11:29 < bridge> r: Rc>, 11:29 < bridge> a: A, 11:29 < bridge> } 11:29 < bridge> 11:29 < bridge> impl A { 11:29 < bridge> pub fn funca(&self) { 11:29 < bridge> let _ = self.r.borrow_mut(); 11:29 < bridge> } 11:29 < bridge> } 11:29 < bridge> 11:29 < bridge> impl B { 11:29 < bridge> pub fn funcb(&self) { 11:29 < bridge> let borrowed = self.r.borrow_mut(); 11:29 < bridge> self.a.funca(); 11:29 < bridge> } 11:29 < bridge> } 11:29 < bridge> 11:29 < bridge> fn main() { 11:29 < bridge> let r: Rc> = Default::default(); 11:29 < bridge> let x = B { 11:29 < bridge> r: r.clone(), 11:29 < bridge> a: A { r }, 11:30 < bridge> }; 11:30 < bridge> ok so this is the code 11:30 < bridge> it panics on borrow mut 11:30 < bridge> thanks for taking the time 11:30 < bridge> sadly i dont have much time tho 11:30 < bridge> i gotta go to office 11:30 < bridge> and i need to cook my meal 11:30 < bridge> XD 11:30 < bridge> gl 11:30 < bridge> Just bite the unsafepill 11:30 < bridge> Who cares what the borrowchecker thinks. Who is he anyway 11:30 < bridge> xdd 11:31 < bridge> well i'd already be happy to make it harder to fuck up xD 11:34 < bridge> Survival of the fittest 11:34 < bridge> true, but if i am an overpowered cyborg, i've higher chances 😬 11:35 < bridge> so i tune myself 11:41 < bridge> You know what would be cool? Some sort of "call stack local" variable 11:41 < bridge> That way any frame that comes after a frame that mutably borrows something can share that borrow 11:45 < bridge> ```rust 11:45 < bridge> use std::{cell::RefCell, rc::Rc}; 11:45 < bridge> 11:45 < bridge> struct A { 11:45 < bridge> } 11:45 < bridge> 11:45 < bridge> struct B { 11:45 < bridge> r: Rc>, 11:45 < bridge> a: A, 11:45 < bridge> } 11:45 < bridge> 11:45 < bridge> impl A { 11:45 < bridge> pub fn funca(&self, r: &mut String) { 11:45 < bridge> r.push('a'); 11:45 < bridge> } 11:45 < bridge> } 11:45 < bridge> 11:45 < bridge> impl B { 11:45 < bridge> pub fn funcb(&self) { 11:45 < bridge> let mut borrowed = self.r.borrow_mut(); 11:45 < bridge> self.a.funca(&mut borrowed); 11:45 < bridge> } 11:45 < bridge> } 11:45 < bridge> 11:45 < bridge> fn main() { 11:45 < bridge> let r: Rc> = Default::default(); 11:45 < bridge> let x = B { 11:45 < bridge> r: r.clone(), 11:45 < bridge> a: A{}, 11:45 < bridge> }; 11:45 < bridge> 11:46 < bridge> btw this is how i would do it 11:46 < bridge> A simplydoesnt need to hold r 11:46 < bridge> simply pass the mut ref when it needs on the fn 11:46 < bridge> it compiles 11:46 < bridge> now i go to work 11:47 < bridge> this is why u can usually avoid refcells 11:47 < bridge> on the second u dont need refcell for B either 11:47 < bridge> they make life easier on some places and in some are needed ye 11:48 < bridge> Makes sense for this specific tiny example, but I think the point is that there are many `A`s that maybe nested far deeper in hierarchy than in here 11:48 < bridge> its hard to say without seeing the whole picture 11:48 < bridge> And B may not even be the one that's directly holding A 11:48 < bridge> Think `CComponent` and `CGraphics` 11:49 < bridge> u have to structure things in rust like u would in rust 11:49 < bridge> not like in java 11:50 < bridge> this is why i find bevy amazing 11:50 < bridge> bevy way is the way 11:50 < bridge> i think its sensible to say, its better to have functions accept references to the objects u need and use them there instead of holding stuff in ur structs 11:51 < bridge> limit the scope of ur references as much as possible 11:51 < bridge> idk 11:51 < bridge> and how is it doing it? 11:51 < bridge> the ECS 11:51 < bridge> But ECS hardly applies to this situation 11:52 < bridge> xd 11:52 < bridge> is his design optimal in the first place 11:52 < bridge> Well I guess entities could have a sprite component, which the gfx can call render on with a reference to gfx 11:53 < bridge> https://docs.rs/bevy_ecs/latest/bevy_ecs/ 11:53 < bridge> i started with passing everything around. 11:53 < bridge> 11:53 < bridge> My point stands: it's simplicity vs compile time checks 11:53 < bridge> design is not just passing all around 11:54 < bridge> if you want automatic cleanup of resources on drop, you need a rc of that part of the graphics lib 11:54 < bridge> but how u structure all ur code idk 11:54 < bridge> else u need destroy manually 11:54 < bridge> yes, that's why i tryhard about this problem to not fuck up 11:55 < bridge> designing things like this is part of the hard problems in programming 11:55 < bridge> the other is MT 11:55 < bridge> :owo: 11:56 < bridge> i defs find my current solution MUCH easier to use, and for an end user easier to not fuck up 11:56 < bridge> 11:56 < bridge> 11:56 < bridge> but it 11:56 < bridge> 1. makes the graphics comp harder to implement 11:56 < bridge> 2. it still has some _smaller_ holes for potential panics, which is dislike 11:56 < bridge> You know where it isn't hard? C 11:56 < bridge> No refcells, no Rcs, no borrowchecking. Just don't forget to free stuff bozo :gigachad3: 11:57 < bridge> 😏 11:57 < bridge> let's _upgrade_ to c 11:57 < bridge> lots of segfaults 11:58 < bridge> also he wants to abuse RAII 11:58 < bridge> if he did manual freeing of resources he could just use a storage 11:58 < bridge> RAII is for weak lazy men. Jupstar is big strong man 11:58 < bridge> and it would be simple 11:58 < bridge> in rust too 11:58 < bridge> honestly i would probs go for some kind of storage 11:59 < bridge> ecs kinda does that 12:00 < bridge> then the `key`/`index` to that storage can be invalid 12:00 < bridge> i prefer the "if it exists, it must exist" philosophy :brownbear: 12:01 < bridge> i prefer the "if it can exists, it must exist" philosophy :brownbear: 12:01 < bridge> Q: Can't you make sure by some other means that all components die before the gfx one instead of an Rc? Isn't there a hierarchical owner of the gfx component that when dead it doesnt even make sense for the gfx component to live on? 12:02 < bridge> so you want me to use a ptr? 😄 12:02 < bridge> I fail to see why one might want the components to be able to keep the gfx component alive if the client itself is gone e.g. 12:03 < bridge> it don't want or need this actually 12:03 < bridge> it's simply that resources hold a ref to the graphics comp for automatic cleanup, and i don't want to pass aroud graphics component every time 12:04 < bridge> i introduced a concept of graphics programs, which should work as if it itself is a graphics implementation 12:04 < bridge> e.g. the map rendering is not part of the graphics component anymore. 12:04 < bridge> 12:04 < bridge> engine & game are 100% split 12:04 < bridge> Ah, hm that is actually a rather annoying steucture indeed 12:05 < bridge> Too much thinking for me. I have a bag to pack, cya'll 12:05 < bridge> maybe u could a way would be to have a struct wrapping the gfx with interior mutability and then u pass the outer struct by a plain non mut reference 12:05 < bridge> rust will make sure the struct outlives conponents holding a ref to that struct 12:06 < bridge> components just need to hold a ref 12:06 < bridge> not a mut ref 12:06 < bridge> aka use interior mutability but hiding the rc in a struct u share by ref 12:07 < bridge> hmm 12:07 < bridge> xd 12:07 < bridge> ok idk 12:07 < bridge> u then expose the gfx methods via &self 12:07 < bridge> or whathever 12:07 < bridge> xd 12:07 < bridge> that's indeed what it does, no refcell is public 12:08 < bridge> ur code was public 12:08 < bridge> in 99% it just works. but sometimes gfx internal components talk to each other. 12:08 < bridge> 12:08 < bridge> Additionally i have at least one hole where i either pass a closure (harder to use) or have to make sure the graphics api is not in use already 12:09 < bridge> well it's very outdated. currently i code so much shit xD 12:09 < bridge> 12:09 < bridge> can't show this trash 12:12 < bridge> https://austral-lang.org/ 12:12 < bridge> Austral is a new systems programming language. It uses linear types to provide memory safety and capability-secure code, and is designed to be simple enough to be understood by a single person, with a focus on readability, maintainbility, and modularity 12:12 < bridge> syntax is odd tho 12:12 < bridge> ada like 12:17 < bridge> Is there the concept of a call stack local variable in any language? 12:17 < bridge> please invent one, i want to test it 😄 12:18 < bridge> I will craft a language one day. Even if it won't be used by anyone I want to experiment 12:19 < bridge> what's a call-stack local variable? 12:20 < bridge> you mean a global variable? visible to the call stack? 12:20 < bridge> thread-local variable maybe? 12:22 < bridge> my company wants to make a lang 12:22 < bridge> based on rust safety with go simplicity 12:23 < bridge> inspired by the lang i sent 12:23 < bridge> linear types 12:23 < bridge> arent variables stored in the stack anyway 12:23 < bridge> or register when possible 12:24 < bridge> A global variable of sorts that would lie in some higher stack frame. Maybe like an `export` of sorts. With visibility only within that chain of calls until the function who initially exported it returns 12:24 < bridge> Like passing it down all the way but more ergonomic 12:33 < bridge> that's the solution: no stack, no call frames => no problems 12:34 < bridge> put everything in one big function xdd 12:37 < bridge> how can a company just afford to make a lang 12:37 < bridge> our company doesn't even want us to make our own playercontroller 12:41 < bridge> that doesn't sound like a problem of money 12:45 < bridge>