00:48 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404234986642604092/image.png?ex=689a733e&is=689921be&hm=e5af4dc66e679fecd4eb6ca3da42e574473b1dbc92e8f4475f2f91b26747c5a2& 00:48 < bridge> infinity commits?? 00:52 < bridge> @qxdfox makea townhall post for emojis, ill f3 >< 01:06 < bridge> if ddnet wont we can always add it to tclient :p 02:43 < bridge> lmao, I've seen infinity files changed before too 02:43 < bridge> idk what makes it do that 02:43 < bridge> javascript moment 02:44 < bridge> maybe IfFinite used to detect infinity which would also detect NaN from Number(undefined) 02:45 < bridge> maybe ifFinite used to detect infinity which would also detect NaN from undefined 02:45 < bridge> maybe ifFinite used to detect infinity which would also detect NaN/undefined 02:45 < bridge> maybe ifFinite used to detect infinity which would also detect NaN/undefined/null 02:45 < bridge> from db or request timeout 02:45 < bridge> it eventually did resolve to 0.... github gets very confused when its just image changes 02:46 < bridge> it eventually did resolve to 0.... github gets very confused when its just image changes, atleast sometimes 02:46 < bridge> it eventually did resolve to 0.... github gets very confused when its just image changes, atleast sometimes 02:46 < bridge> it eventually did resolve to 0.... github gets very confused when its just image changes, sometimes 04:37 < bridge> <.thedominator> Please guys fix your broken anti cheat i got banned twice because of false positives 08:38 < bridge> @.thedominator: on which server? I did not know ddnet has auto bans 08:55 < bridge> gumo ^.^ 09:25 < bridge> vac has been added to ddnet 09:26 < bridge> Which maintainer besides robyt can I summon to look over some of my PRs? Ryo is taking a break, heinrich is invisible, hmm @learath2 ? I also have some small ones left :justatest: 09:27 < bridge> I can take a look, but aren't you working on rendering stuff? Jupsti would probably be the best person for those, no? 09:30 < bridge> yes, but only because it's related to rendering doesn't mean others can't review it. Some of my PRs are almost trivial 😄 09:31 < bridge> #10625 is fully ignored but should be easy to review 09:31 < bridge> https://github.com/ddnet/ddnet/pull/10625 09:33 < bridge> Also I wanted to give Jupey a break after that 1000 lines PR 09:40 < bridge> And #10629 is another easy to review candidate, just some moved around code, but I must admit the github file-changed-view looks worse than it is 09:40 < bridge> https://github.com/ddnet/ddnet/pull/10629 12:59 < bridge> D: 13:17 < bridge> finally 13:21 < bridge> rip 14:28 < bridge> @learath2 i forgot i probs need some kind of crt0 to initialize static data right? i was all morning trying to debut why i get a page fault and i think itd cuz that lol 14:29 < bridge> Yes, there is a part that needs to happen pre-main 14:29 < bridge> i get a page fault the moment i tried to use a global static allocator in a user program 14:29 < bridge> so i Guess ye 14:30 < bridge> the method doesnt even get called 14:30 < bridge> and the address is 0x0 14:30 < bridge> (iirc need to recheck) 14:30 < bridge> Hm, idk how does the call happen? Do you have a got/plt set up even? 14:30 < bridge> what is plt 14:30 < bridge> xD 14:31 < bridge> Procedure linking table. It's what allows dynamic linking 14:31 < bridge> hm no, do i need that for static programs with no deps? 14:31 < bridge> Why is 0x0 being called is the question, no? 14:32 < bridge> ah the method being called is through a rust trait 14:32 < bridge> i guess it used s vtable 14:32 < bridge> i guess it uses vtable 14:34 < bridge> You shouldn't need a plt then. But you still need the GOT if the binary is position independent. How far have you implemented elf loading? 14:34 < bridge> what is GOT? Im loading elf programs with pic/pie, i simply add a base address to all pt load segments 14:35 < bridge> (that are pie) 14:35 < bridge> i wonder if i need tls 14:35 < bridge> so many stuff 14:36 < bridge> Ok, lets stop guessing. Just check why 0x0 is being called and where that address comes from 14:36 < bridge> It should be obvious in the disassembly of what you are trying to run 14:36 < bridge> where source 14:37 < bridge> ye im at wc planting s tree when i get to pc i recheck de address 14:37 < bridge> :justatest: 14:37 < bridge> I would also try running a very simple C application instead, with `_start` instead of `main` 14:38 < bridge> oh my rust program also used start 14:38 < bridge> i probs need some crt0 crti anyway 14:41 < bridge> You shouldn't need it really, it mostly just sets up argc and argv and initializes static stuff 14:43 < bridge> Anyway looking at the disassembly should help. For PIC you need to set up GOT too, that'd be what I suspect 14:43 < bridge> > initializes static stuff 14:43 < bridge> i think this is the key thi 14:46 < bridge> It also sets up TLS and stuff too. But if all you want is to run something, I'd first start with just a no PIC no libc C program 14:47 < bridge> i know i can run stuff already 14:47 < bridge> its that when i call for example String::new() and push, after setting up the global allocator (which is a static) it crashes 14:49 < bridge> ``` 14:49 < bridge> EXCEPTION: general_protection_fault (segfault?) CHECK: (error: 0) 14:49 < bridge> InterruptStackFrame { 14:49 < bridge> instruction_pointer: VirtAddr( 14:49 < bridge> 0x401378, 14:49 < bridge> ), 14:49 < bridge> code_segment: SegmentSelector { 14:49 < bridge> index: 4, 14:49 < bridge> rpl: Ring3, 14:49 < bridge> }, 14:49 < bridge> cpu_flags: RFlags( 14:49 < bridge> RESUME_FLAG | INTERRUPT_FLAG | 0x2, 14:49 < bridge> ), 14:49 < bridge> stack_pointer: VirtAddr( 14:49 < bridge> 0x7fffffffefb7, 14:49 < bridge> ), 14:49 < bridge> stack_segment: SegmentSelector { 14:49 < bridge> index: 3, 14:49 < bridge> rpl: Ring3, 14:49 < bridge> }, 14:49 < bridge> } 14:49 < bridge> ``` 14:49 < bridge> calling alloc::alloc directly works 14:49 < bridge> its why i dont get it 14:51 < bridge> ```rust 14:51 < bridge> // this faults 14:51 < bridge> unsafe { 14:51 < bridge> let mut x = String::new(); 14:51 < bridge> x.push_str("a"); 14:51 < bridge> black_box(x); 14:51 < bridge> } 14:51 < bridge> 14:51 < bridge> // this works 14:51 < bridge> unsafe { 14:51 < bridge> let mut ptr = black_box(alloc::alloc::alloc(Layout:🆕:())); 14:51 < bridge> *ptr = 4; 14:51 < bridge> black_box(ptr); 14:51 < bridge> 14:51 < bridge> syscalls::exit(0); 14:51 < bridge> } 14:51 < bridge> ``` 14:53 < bridge> ``` 14:53 < bridge> SYSCALL: id=12 rdi=0x0 rsi=0x8 rdx=0x8 r10=0x0 r8=0x0 r9=0x0 14:53 < bridge> SYSCALL: sys_brk: addr=0x0 14:53 < bridge> SYSCALL: sys_brk: new_break=0x0, current_break=0x414000, heap_break=0x414000 14:53 < bridge> SYSCALL: sys_brk: returning current break 14:53 < bridge> SYSCALL: Handler returning 0x414000 14:53 < bridge> SYSCALL: id=12 rdi=0x414008 rsi=0x414000 rdx=0x414008 r10=0x0 r8=0x0 r9=0x0 14:53 < bridge> SYSCALL: sys_brk: addr=0x414008 14:53 < bridge> SYSCALL: sys_brk: new_break=0x414008, current_break=0x414000, heap_break=0x414000 14:53 < bridge> sys_brk: Expanding heap from 0x414000 to 0x414008 (size: 8 bytes) 14:53 < bridge> SYSCALL: Handler returning 0x0 14:53 < bridge> SYSCALL: id=60 rdi=0x0 rsi=0x414000 rdx=0x414008 r10=0x0 r8=0x0 r9=0x0 14:53 < bridge> SYSCALL: sys_exit: code=0 14:53 < bridge> SYSCALL: sys_exit: Switching page table to kernel = 0x101000 14:53 < bridge> SCHED: marking process ProcessId(0) as exited with code 0 14:53 < bridge> SYSCALL: sys_exit: Process cleanup complete, halting for interrupts. 14:53 < bridge> ``` 14:53 < bridge> this is for the bottom case which works, yes im using brk or now 14:53 < bridge> Hm, idk enough about rust internals to know how `String::new` allocates memory 14:53 < bridge> ``` 14:53 < bridge> SYSCALL: id=12 rdi=0x0 rsi=0xf rdx=0xf r10=0x0 r8=0x0 r9=0x0 14:53 < bridge> SYSCALL: sys_brk: addr=0x0 14:53 < bridge> SYSCALL: sys_brk: new_break=0x0, current_break=0x416000, heap_break=0x416000 14:53 < bridge> SYSCALL: sys_brk: returning current break 14:54 < bridge> SYSCALL: Handler returning 0x416000 14:54 < bridge> SYSCALL: id=12 rdi=0x416008 rsi=0x416000 rdx=0x416008 r10=0x0 r8=0x0 r9=0x0 14:54 < bridge> SYSCALL: sys_brk: addr=0x416008 14:54 < bridge> SYSCALL: sys_brk: new_break=0x416008, current_break=0x416000, heap_break=0x416000 14:54 < bridge> sys_brk: Expanding heap from 0x416000 to 0x416008 (size: 8 bytes) 14:54 < bridge> SYSCALL: Handler returning 0x0 14:54 < bridge> 14:54 < bridge> 14:54 < bridge> KERNEL PANIC: panicked at src/interrupts/idt.rs:49:5: 14:54 < bridge> EXCEPTION: general_protection_fault (segfault?) CHECK: (error: 0) 14:54 < bridge> ``` 14:54 < bridge> string case xd 14:54 < bridge> But there probably is a crt0 someone already wrote, maybe try to link that in to test? 14:54 < bridge> If it fixes the issue, then you know what was wrong 14:54 < bridge> new doesnt alloc, push does tho 15:41 < bridge> ok i think i wont focus on this stuff for now and ill avoid rust alloc 15:42 < bridge> i dont understand yet what i need and i want to focus on the kernel xD 15:42 < bridge> i could write rust programs without using alloc but thats like using C :d 16:17 < bridge> BOO 16:21 < bridge> @learath2 omg, u were right! i fixed the relocations GOT and it works now 16:21 < bridge> this is cuz im stupid and started with pic overcomplicating my life lmao 16:22 < bridge> but well now it works with pic 16:22 < bridge> pic pie whathever 16:22 < bridge> Yeah, that's why I wanted you to check non-PIC code first just in case 😄 16:23 < bridge> when will you release a new version of the kernel? 16:23 < bridge> i want to run some programs lol 16:23 < bridge> finally i can use alloc from user 16:24 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404470408232570910/image.png?ex=689b4e7f&is=6899fcff&hm=121b29a5dd0821e2032d1d9ac0c2ad39b38b0f6054d8cdca34bd17502feb06e0& 16:24 < bridge> soon, currently programs are included statically into the kernel binary, cuz i have no filesystem 16:24 < bridge> ill do filesystem next 16:25 < bridge> okay but what is `puts`? 16:26 < bridge> dont u know C? 16:26 < bridge> ```rust 16:26 < bridge> use crate::syscalls; 16:27 < bridge> 16:27 < bridge> pub const STDOUT_FD: u64 = 1; 16:27 < bridge> 16:27 < bridge> #[inline] 16:27 < bridge> pub fn puts(text: &str) { 16:27 < bridge> unsafe { 16:27 < bridge> syscalls::write(STDOUT_FD, text.as_ptr(), text.len() as u64); 16:27 < bridge> } 16:27 < bridge> } 16:27 < bridge> ``` 16:27 < bridge> kinda wanted to make my own elibc 16:27 < bridge> u dont know hwo happy i am to have fixed this, its been bothering me for 2 days 16:28 < bridge> so many moving parts, and i was missing a stupid elf thing lmao 16:29 < bridge> glad to have helped in some way 16:29 < bridge> needed to handle R_X86_64_RELATIVE 16:30 < bridge> i need lot of stuff still to have a useful kernel, filesystem, then figure out how to setup argv argc for programs etc 16:31 < bridge> and more syscalls, i only have write, exit, brk 16:32 < bridge> @learath2 can you do [this]() please ? 16:32 < bridge> I want to clean up my backlog 😄 16:37 < bridge> why not give assa maintainer 16:39 < bridge> I don't know if I should be a maintainer, do I need to do more then just reviews, press the merge button and label issues? 16:39 < bridge> I guess #4523 still needs a fix somehow, I'm unsure whether it gets better than this 16:39 < bridge> https://github.com/ddnet/ddnet/issues/4523 16:40 < bridge> Thankfully it only affects the specific case of very fast significantly direction altering bounces 16:40 < bridge> this is also "server" and "fix-changes-physics" 16:40 < bridge> it doesn't if affects every case where a player hits a solid as well :justatest: 16:41 < bridge> just to a lesser degree 16:41 < bridge> At significant speed, and the reflection angle is smaller, so the direction change is less significant 16:41 < bridge> less significant is still an issue 16:41 < bridge> With high speed bounces it would cause absurd behaviour, like hitting a freeze that you bounced under 😄 16:42 < bridge> To be honest, the entire way tile collisions are handled in ddnet is just bizarre 16:42 < bridge> you call it bizarre, I call it _wrong_ 16:43 < bridge> MoveBox should be returning a vector of all tiles hit along the move 16:43 < bridge> It is wrong 16:43 < bridge> Holy shit no 16:43 < bridge> Wrong but has to be supported forever 16:44 < bridge> move box should call the function of a tile when it is hit directly once 16:44 < bridge> otherwise you get things like speedups beeing applied post tick 16:44 < bridge> @totar may you help this lost sould 16:44 < bridge> @totar may you help this lost soul 16:44 < bridge> You could elaborate on what's wrong with that instead of talking shit 16:44 < bridge> ^^^ 16:45 < bridge> imagine you hit a stopper before the finish line in a subtick 16:45 < bridge> apply stopper, then apply finish line? 16:45 < bridge> Why wouldn't you be able to do that with the vector of tiles you get? Just handle them in-order 16:46 < bridge> because they may affect your move box position 16:46 < bridge> Oh you want those to apply within the tick too, yeah no, that would be breaking faar too much 16:46 < bridge> Though I guess if we are breaking everything, might aswell break that too, so maybe? 16:46 < bridge> I'd like to, but ofc this is not backwards compat 16:47 < bridge> here is the discussion about a possible physics fix https://github.com/ddnet/ddnet/issues/10221 16:48 < bridge> maybe I should rename it to "add physics editions every 15 years or so" 16:48 < bridge> Anyway, the history with `GetMapIndices` is that it was someones attempt at fixing tile skips, back when no one really cared at all about "correctness" 16:48 < bridge> The simplifying assumption that was made is that a tick is short enough that any movement within it can be approximated as a linear move 16:49 < bridge> yeah and bouncyness breaks that assumption 16:50 < bridge> And the fix would be to keep track of where you were moved during `MoveBox` so that fix is about as good as you can get 16:52 < bridge> I agree 16:53 < bridge> it's the "easiest fix" without breaking everything 16:53 < bridge> (I would expect this to only have effect on replies for maps where you have bounciness or very high speed, the assumption that movement is linear within a tick is not that broken, maybe we can throw tees at walls at different angles and measure the amount of non-linearity) 16:53 < bridge> but is still a physics change changing how tiles are applied 16:54 < bridge> this may break some demos, records, playbacks, invalidate leaderboards? 16:58 < bridge> Yeah, I guess it's best not to mess with it I guess. We should get physics editions before fixing this 16:58 < bridge> I added a comment, I could only fix bouncyness with this PR 16:59 < bridge> like only add a position, if the elasticity is > 0 16:59 < bridge> and have old behavior still for normal solids 16:59 < bridge> That's a better compromise, bounciness is new enough that there probably aren't many instances of extremely high speed bounces off of walls 17:00 < bridge> very botched PR 😄 17:09 < bridge> Guess I am working on the recorder tiles next 17:10 < bridge> Guess I am working on the recorder tiles next ^^ 17:10 < bridge> @louis.place what is your plan with the targets? :3 I know you are still waiting for more sounds, but you still have some issues open in your PR 17:18 < bridge> how do you get the time between frames but taking into account demo slowdown/pause and video recording 17:28 < bridge> Idk i guess ill do sounds and particles when i am feeling up to it 17:29 < bridge> and fix the other comments 17:40 < bridge> intratick prolly? interpolate between ticks 17:44 < bridge> now i can recover from segfaults in user programs yay 17:44 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404490675457888357/image.png?ex=689b615f&is=689a0fdf&hm=630ad1f772d5ef133fee95de9485fd551c39fb39e03c5a1f7c90f3799f96c346& 17:45 < bridge> Awesome 17:46 < bridge> How do you want to add a filesystem? 17:46 < bridge> even better 17:46 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404491142808211487/image.png?ex=689b61ce&is=689a104e&hm=ef2aa2ef627d7e5692ae149146369a14bb5122d10bf525aec27276fa9ed0ceb2& 17:46 < bridge> ill probs first do a ram filesystem like a simple Vec, then fat16 17:46 < bridge> or fat32 17:46 < bridge> cuz i heard its simple 17:47 < bridge> Okay 17:47 < bridge> A custom FS could be interesting 17:47 < bridge> true 17:47 < bridge> but i dont even know internals of current filesystems 17:47 < bridge> Maybe something a bit crazy, like a filesystems without a traditional directory structure 17:47 < bridge> i guess i can infer it from syscalls 17:48 < bridge> yeah i definitly want to become unique at some point, but since im learning mostly rn i stick to standards 17:54 < bridge> You can make per program permissions 17:54 < bridge> The way permissions work on linux is a bit dumb 17:55 < bridge> yes its literally a BIT dumb 17:55 < bridge> Well i mean 17:56 < bridge> Idk why someone thought setting permissions with 3 digits which are then interpreted in binary is a good idea 17:57 < bridge> At least there is the alternative way 17:57 < bridge> Which is a more sane 17:58 < bridge> But most importantly i want more control than running a program as a specific user 17:59 < bridge> Usually i want programs to access like 1 directory 17:59 < bridge> yeah it would be nice 18:00 < bridge> Why doesn't linux implement that? 18:00 < bridge> Seems fairly simple 18:02 < bridge> there is AppArmor 18:18 < bridge> AoeTW tf 18:18 < bridge> Bro copied my name 18:28 < bridge> good idea i guess 18:36 < bridge> tw standing for the winner obviously, the 2 letters at the end of your namea re nothing but unique 18:37 < bridge> SbbTW ? 😄 18:37 < bridge> Solly bun bun TW? 18:37 < bridge> bun bun is just my ign x-x 18:38 < bridge> bun bun give me gum gum? :justatest: 18:39 < bridge> 🔫🔫 18:39 < bridge> ? 18:43 < bridge> Reitw invented that postfix 18:44 < bridge> ReiTW still stands for ReiTeeWars 18:45 < bridge> But you'll never see a Chinese with that postfix😬 18:46 < bridge> @essigautomat you need some geopolitical education it seems 18:46 < bridge> Tw stands for Taiwan 18:46 < bridge> I know a lot but I can't know all 18:46 < bridge> ah then you don't say anything anymore 18:46 < bridge> ah then you don't need to say anything anymore 18:46 < bridge> :deen_star: 18:47 < bridge> You could probably go direct to fat32, it's not too bad 18:48 < bridge> so chinese are mad if I host a teeworlds related .tw domain? man 18:51 < bridge> Linux does implement this in the form of chroots 18:52 < bridge> @jupeyy_keks can you take a look at some of my prs? pretty please? 18:52 < bridge> :owo: 18:52 < bridge> 👉 👈 18:53 < bridge> 👉 👈. 18:53 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404508135875674233/image.png?ex=689b71a2&is=689a2022&hm=8d3abe2a941bbdbdfcbe430822f84adff9f51a91bab1ffac9aaadfb04363bb26& 18:54 < bridge> 🦶 👟 18:54 < bridge> 🦶 👟. 18:54 < bridge> It's just a compact way to display the permissions. You need to remember that originally only nerds used linux and they had no trouble reading octal 18:54 < bridge> xD 18:55 < bridge> Not really, no time til end of year 18:55 < bridge> Except their code change is less than 20 LOC 18:56 < bridge> 33 - 16 is less than 20 :justatest: 18:56 < bridge> #10625 18:56 < bridge> https://github.com/ddnet/ddnet/pull/10625 19:05 < bridge> Ok you used your review token for this week 19:08 < bridge> the only difference is that you round instead of floor and ceil 19:08 < bridge> It's much closer to the map format 19:08 < bridge> which uses x,y,w,h too, you just magically always increase the w & h 19:08 < bridge> like I need to go from floating point world to integer world 19:08 < bridge> u need to do that anyway 19:09 < bridge> the clipping rect is in pixels of the monitor monitors 19:09 < bridge> yeah to the next pixel, because we're on a subpixel 19:09 < bridge> No you might increase the whole clip rect by a pixel 19:10 < bridge> e.g. if x is 0.9 you'd just floor it 19:10 < bridge> Even tho the pixel is most likely no visible 19:10 < bridge> the old way of clipping was off by more than 1 pixel btw 19:10 < bridge> this is also the old behavior 19:10 < bridge> i am not saying old behavior is good 19:10 < bridge> I mean I can switch ceil & floor to rounding 19:11 < bridge> That is still not correct 19:11 < bridge> why not? 19:11 < bridge> I am not just rounding, I am checking whether moving from sub pixel to normal pixel would move the clip rect left or right 19:12 < bridge> I am calculating right and bottom too and if we round that, we should go to the same value since both are only offset by screen x and screen y 19:12 < bridge> will do then 19:13 < bridge> Is clip w & h a integer? 19:13 < bridge> yes 19:13 < bridge> But no 19:13 < bridge> The rendering itself is not in pixels 19:13 < bridge> A width of 10 could still mean 12.5 pixels 19:14 < bridge> 0.9 + 0.5 => u will round down 19:14 < bridge> or let's say 12.4 pixels xd 19:15 < bridge> I see it like that, I have 4 flooating point coordinates and move them to the nearest 4 integer coordinates 19:15 < bridge> I don't see what's wrong with this approach 19:15 < bridge> I don't see what's wrong with this approach (assuming I round and not floor / ceil) 19:15 < bridge> @learath2 is libm portable? do u think it would be hard to include it 19:15 < bridge> Well hard to say if it _is_ wrong. But it feels wrong to me, bcs in a bad case the clip rect might be smaller than intended 19:16 < bridge> what value does an accurate width/height provide here? 19:16 < bridge> and in another bad case it's bigger than intended 19:16 < bridge> that's the issue with clipping in pixel sizes 19:16 < bridge> But in terms of pixels it might look better 19:16 < bridge> that's why I opted to use floor and ceil, so it always expands and it never cuts off too much 19:17 < bridge> Ok but anyway, if, then use round 19:17 < bridge> ceil & floor feels defs wrong 19:17 < bridge> Wym by include it? As in just link to some implementation of it? 19:17 < bridge> well idk, rigt now the only aproach would be to include it in tree and statically link it, because i have no filesystem nor can load .so files yet 19:17 < bridge> i guess i should simply not do this now 19:18 < bridge> and do it later when i have fs 19:18 < bridge> Libm is usually written in very unportable code. Using assembly trickery to make it faster. So not very portable at all 19:18 < bridge> is loading dynamic libraries hard? xD 19:18 < bridge> portable as in dependency wise i guess 19:18 < bridge> i only have x86_64 19:19 < bridge> @essigautomat ping me when you changed it, then I merge 19:19 < bridge> ok portable as in statically linking it 19:19 < bridge> xd 19:19 < bridge> nvm i wont touch it yet 19:19 < bridge> Then your merge token is consumed too 19:19 < bridge> I'll test it before, gimme a sec 19:19 < bridge> Yes, that is where things get rather annoying. I would recommend against that 19:20 < bridge> thank god rust is all static 19:20 < bridge> :owo: 19:21 < bridge> If I recall correctly, libm is dependency free, so you can just compile one for x86_64 out of glibc and link to that statically 19:21 < bridge> btw i had to fix a rly intricate bug 19:21 < bridge> the syscall rax value was returning wrong 19:22 < bridge> and what would u guess was the issue 19:22 < bridge> skill issue? 19:22 < bridge> yeah 19:22 < bridge> the timer interrupt was restoring rax wrongly lmao 19:23 < bridge> i should write tests 19:23 < bridge> but idk hwo to test kernel 19:23 < bridge> That sounds rather annoying to debug 19:23 < bridge> yea 19:25 < bridge> Testing a kernel is tricky. You usually want a userland testing suite so you can blackbox test it 19:26 < bridge> userland u mean qemu with the kernel or a program inside the kernel 19:27 < bridge> A program running within your kernel, so it can verify the kernel contracts 19:27 < bridge> I think rounding is even better ✅ 19:27 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1404516547334242454/screenshot_2025-08-11_19-26-53.png?ex=689b7977&is=689a27f7&hm=59f4b51c9cf6b21e9178d8351b0db697e1384913b655c0baf3999c9a48316ec1& 19:27 < bridge> makes sense 19:27 < bridge> For other things you can have traditional unit tests too 19:28 < bridge> Like the elf loader can be tested by hooking/mocking the memory writes. 19:28 < bridge> @jupeyy_keks it's ready, thank you ❤️ the clipping before was off by more than 1 pixel and it was really annoying me 20:08 < bridge> chroot is too powerful for simple use cases i think 20:09 < bridge> also wikipedia claims it's not secure on most systems 20:10 < bridge> which is weird because why wouldn't it be secure 20:10 < bridge> well 20:11 < bridge> root can still do anything 20:11 < bridge> and what is that 20:12 < bridge> for example `chmod u+x script.sh` 20:12 < bridge> that just changes the bits 20:12 < bridge> there is this whole other syntax 20:13 < bridge> but i don't have to think about what each bit does 20:31 < bridge> @robyt3 any idea why I don't see any benefits in setup time ony system? 🫣 20:32 < bridge> Maybe different compiler/settings 20:33 < bridge> @robyt3 any idea why I don't see any benefits in setup time on my system? 🫣 20:33 < bridge> hmm okay 20:33 < bridge> yeah MSVC 20:34 < bridge> I also used MSVC for profiling though 20:41 < bridge> can i completely disable prediction server-side? 20:41 < bridge> can i completely disable prediction from the server-side? 20:46 < bridge> you can send vanilla game info flags i guess 20:48 < bridge>