02:49 <+bridge> <alw5> welcome to the internet
02:57 <+bridge> <gorp_tw> ddnet is so cool
02:57 <+bridge> <gorp_tw> i was like damn i wish i could reset search with a bind
02:58 <+bridge> <gorp_tw> br_search_string ""
02:58 <+bridge> <gorp_tw> already exists amazing
03:35 <+bridge> <totar> you can predict which of these exist because anything that gets saved after closing the game has to go in a config
03:35 <+bridge> <gorp_tw> ye so like anything ive made non-default
03:35 <+bridge> <gorp_tw> does it prune settings that are explicit defaults? probably not right
03:36 <+bridge> <gorp_tw> cus then migration from defaults messes up those users
11:22 <+bridge> <qetoast> I actually spotted what you meant now I'm pretty sure I fixed it now
12:37 <+bridge> <Assa> lets cancel @gorp_tw for beeing such a hater! /s
12:38 <+bridge> <Assa> @l._ouis monthly reminder about the eyes thing :justatest:
13:35 <+bridge> <kaffeine0> https://github.com/ddnet/ddnet/pull/7253 (reply to the q about `cl_sub_tick_aiming`)
14:32 <+bridge> <milkeeycat> @learath2  I'm still not done with IR refactor :pepeW: It's decided that I'll have HIR and gMIR/MIR. But another thing is that I wanted to use 
14:32 <+bridge> <milkeeycat> enums for MIR:
14:32 <+bridge> <milkeeycat> ```rust
14:32 <+bridge> <milkeeycat> enum GenericInstruction<I: TargetInstruction> {
14:32 <+bridge> <milkeeycat>     Add(AddInstr),
14:32 <+bridge> <milkeeycat>     Sub(AddInstr),
14:32 <+bridge> <milkeeycat>     Target(I),
14:32 <+bridge> <milkeeycat> }
14:32 <+bridge> <milkeeycat> ```
14:32 <+bridge> <milkeeycat> 
14:32 <+bridge> <milkeeycat> I thought it'd be weird to use 1 enum type, since some passes could transform instructions and they wouldn't be present in the IR but would still be present in the enum type. So I played with an idea of having enum type per "stage", for example `GenericInstruction` has many generic instructions, and `GenericAfterIsel` would have only a few generic instruction variants(and function which would store those instructions be generic).
14:32 <+bridge> <milkeeycat> I tried to make this work, but after a few days of trying to make it compile and constantly having 200+ errors I gave up, the code looks ass with generics everywhere, instructions would have to me mapped form enum A to enum B :\ 
14:32 <+bridge> <milkeeycat> 
14:32 <+bridge> <milkeeycat> I'm fine with not using enums but I have one thing I don't like about the IR I have now(https://github.com/MilkeeyCat/tja/blob/5f54924385ddce959744a9c14c65db21f79610c7/tja/src/mir/instruction.rs#L16-L24), it takes multiple elements in `operands` vector to make a valid amd64 address operand(each part of an address is a separate `Operand`). It should be possible to use `operands: Vec<Box<dyn Operand>>`
14:32 <+bridge> <milkeeycat> and have `Amd64Address` struct instead, but is dynamic dispatch a good idea? :\
14:32 <+bridge> <milkeeycat> 
14:32 <+bridge> <milkeeycat> How would you design an IR to be able to represent generic and target specific instructions(and operands)(and in rust btw). Do you think dynamic dispatch could be a good solution?
14:41 <+bridge> <milkeeycat> @learath2  I'm still not done with IR refactor :pepeW: It's decided that I'll have HIR and gMIR/MIR. But another thing is that I wanted to use 
14:41 <+bridge> <milkeeycat> enums for MIR:
14:41 <+bridge> <milkeeycat> ```rust
14:41 <+bridge> <milkeeycat> enum GenericInstruction<I: TargetInstruction> {
14:41 <+bridge> <milkeeycat>     Add(AddInstr),
14:41 <+bridge> <milkeeycat>     Sub(SubInstr),
14:41 <+bridge> <milkeeycat>     Target(I),
14:41 <+bridge> <milkeeycat> }
14:41 <+bridge> <milkeeycat> ```
14:41 <+bridge> <milkeeycat> 
14:41 <+bridge> <milkeeycat> I thought it'd be weird to use 1 enum type, since some passes could transform instructions and they wouldn't be present in the IR but would still be present in the enum type. So I played with an idea of having enum type per "stage", for example `GenericInstruction` has many generic instructions, and `GenericAfterIsel` would have only a few generic instruction variants(and function which would store those instructions be generic).
14:41 <+bridge> <milkeeycat> I tried to make this work, but after a few days of trying to make it compile and constantly having 200+ errors I gave up, the code looks ass with generics everywhere, instructions would have to me mapped form enum A to enum B :\ 
14:41 <+bridge> <milkeeycat> 
14:41 <+bridge> <milkeeycat> I'm fine with not using enums but I have one thing I don't like about the IR I have now(https://github.com/MilkeeyCat/tja/blob/5f54924385ddce959744a9c14c65db21f79610c7/tja/src/mir/instruction.rs#L16-L24), it takes multiple elements in `operands` vector to make a valid amd64 address operand(each part of an address is a separate `Operand`). It should be possible to use `operands: Vec<Box<dyn Operand>>`
14:42 <+bridge> <milkeeycat> and have `Amd64Address` struct instead, but is dynamic dispatch a good idea? :\
14:42 <+bridge> <milkeeycat> 
14:42 <+bridge> <milkeeycat> How would you design an IR to be able to represent generic and target specific instructions(and operands)(and in rust btw). Do you think dynamic dispatch could be a good solution?
14:42 <+bridge> <milkeeycat> @learath2  I'm still not done with IR refactor :pepeW: It's decided that I'll have HIR and gMIR/MIR. But another thing is that I wanted to use 
14:42 <+bridge> <milkeeycat> enums for MIR:
14:42 <+bridge> <milkeeycat> ```rust
14:42 <+bridge> <milkeeycat> enum GenericInstruction<I: TargetInstruction> {
14:42 <+bridge> <milkeeycat>     Add(AddInstr),
14:42 <+bridge> <milkeeycat>     Sub(SubInstr),
14:42 <+bridge> <milkeeycat>     Target(I),
14:42 <+bridge> <milkeeycat> }
14:42 <+bridge> <milkeeycat> ```
14:42 <+bridge> <milkeeycat> 
14:42 <+bridge> <milkeeycat> I thought it'd be weird to use 1 enum type, since some passes could transform instructions and they wouldn't be present in the IR but would still be present in the enum type. So I played with an idea of having enum type per "stage", for example `GenericInstruction` has many generic instructions, and `GenericAfterIsel` would have only a few generic instruction variants(and function which would store those instructions be generic).
14:42 <+bridge> <milkeeycat> I tried to make this work, but after a few days of trying to make it compile and constantly having 200+ errors I gave up, the code looks ass with generics everywhere, instructions would have to me mapped form enum A to enum B :\ 
14:42 <+bridge> <milkeeycat> 
14:42 <+bridge> <milkeeycat> I'm fine with not using enums but I have one thing I don't like about the IR I have now(https://github.com/MilkeeyCat/tja/blob/5f54924385ddce959744a9c14c65db21f79610c7/tja/src/mir/instruction.rs#L16-L24), it takes multiple elements in `operands` vector to make a valid amd64 address operand(each part of an address is a separate `Operand`). It should be possible to use `operands: Vec<Box<dyn Operand>>`
14:42 <+bridge> <milkeeycat> and have `Amd64Address` struct instead, but is dynamic dispatch a good idea? :\
15:00 <+bridge> <learath2> You are really scraping at the very edges of my compiler theory and rust knowledge here 😄
15:01 <+bridge> <learath2> To start with, why is an `Amd64Address` even taking "operands". Instructions take operands, not addresses
15:03 <+bridge> <milkeeycat> nono, I meant that right now 1 `Amd64Address` operand is represented as 4 `Operands`
15:06 <+bridge> <milkeeycat> if i have mov from register to memory instruction, operands look like this `[Operand::Register(..), Operand::Register(..), Operand::Register(..), Operand::Immediate(..), Operand::Immediate(..)]` where first register operand is.. the instruction's first operand, and `Operand::Register(..), Operand::Register(..), Operand::Immediate(..), Operand::Immediate(..)` represent base, index, scale and displacement
15:06 <+bridge> <milkeeycat> if i have mov from register to memory instruction, operands look like this `[Operand::Register(..), Operand::Register(..), Operand::Register(..), Operand::Immediate(..), Operand::Immediate(..)]` where first register operand is.. the instruction's first operand, and `Operand::Register(..), Operand::Register(..), Operand::Immediate(..), Operand::Immediate(..)` represent base, index, scale and displacement.
15:08 <+bridge> <milkeeycat> if i have mov from register to memory instruction, operands look like this `[Operand::Register(..), Operand::Register(..), Operand::Register(..), Operand::Immediate(..), Operand::Immediate(..)]` where first register operand is.. the instruction's first operand, and last 4 operands represent base, index, scale and displacement.
15:08 <+bridge> <milkeeycat> nono, I meant that right now 1 `Amd64Address` operand is represented as 4 `Operand`s
15:17 <+bridge> <learath2> I see, I guess I don't see much of a way to avoid the dynamic dispatch there, perhaps you could hide it within a `Operand::TargetAddress()` so only that variant needs to incur a dyn dispatch
15:20 <+bridge> <milkeeycat> I guess, using `dyn Instruction` instead is also an option.
15:20 <+bridge> <milkeeycat> I yoinked this idea from LLVM btw
15:22 <+bridge> <milkeeycat> Which way would you choose? Dynamic dispatch yay or nay?
15:23 <+bridge> <learath2> What is the other option again?
15:23 <+bridge> <milkeeycat> Live with this xd
15:24 <+bridge> <milkeeycat> 1. `dyn Instruction`
15:24 <+bridge> <milkeeycat> 2. `dyn Operand`
15:24 <+bridge> <milkeeycat> 3. keep https://discord.com/channels/252358080522747904/293493549758939136/1478393081635016715
15:28 <+bridge> <milkeeycat> or maybe you'd do it somehow else
15:33 <+bridge> <learath2> I guess keeping it is also an option, it is kinda ugly though
15:33 <+bridge> <learath2> I vote you keep it, it works
15:36 <+bridge> <milkeeycat> I have utils which take a vec of operands and gimme me proper type, and turn this proper type into a vec of operands(for example https://github.com/MilkeeyCat/tja/blob/5f54924385ddce959744a9c14c65db21f79610c7/tja/src/targets/amd64/address_mode.rs#L15-L78), so it's not thaaaat bad
15:36 <+bridge> <milkeeycat> thanks for making the decision xd
16:20 <+bridge> <milkeeycat> @ryozuki can you ask your clanker how to improve the code? xd
16:22 <+bridge> <ryozuki> do u have arepo
16:22 <+bridge> <ryozuki> ah u linked it
16:22 <+bridge> <ryozuki> i should read
16:24 <+bridge> <ryozuki> give me a sec
16:26 <+bridge> <ryozuki> Good question. I've now read through your IR design — the flat Operand vector, the Opcode as usize with generic/target ranges, the OperandInfo trait, and the AddressMode being splayed across 4 consecutive slots. Here's my take:
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   Dynamic dispatch: I'd avoid it
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   Vec<Box<dyn Operand>> sounds nice in theory but is painful in Rust for this use case:
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   - No pattern matching on trait objects. You'd need Any-based downcasting everywhere, which is verbose and fragile.
16:26 <+bridge> <ryozuki>   - Clone is hard — Clone is not object-safe, so you need dyn_clone or manual machinery.
16:26 <+bridge> <ryozuki>   - Register iteration for regalloc — every dyn Operand impl needs a method to yield its registers. Doable but boilerplate-heavy, and you lose the ability to just match on an operand and directly grab registers.
16:26 <+bridge> <ryozuki>   - Heap alloc per operand + vtable indirection. Not catastrophic but unnecessary.
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   You'd end up fighting Rust's type system more than solving your actual problem.
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   Generics for the instruction type: also avoid
16:26 <+bridge> <ryozuki> 
16:26 <+bridge> <ryozuki>   You already discovered this. The "generics infection" is real — every function touching an instruction becomes generic, and mapping enum variants across stages is painful. LLVM avoids this entirely by using a single MachineInstr type across all phases.
16:27 <+bridge> <ryozuki> 
16:27 <+bridge> <ryozuki>   What I'd actually recommend
16:27 <+bridge> <ryozuki> 
16:27 <+bridge> <ryozuki>   Your core problem is narrow: address modes don't have first-class representation in the operand enum. The simplest fix is to add one:
16:27 <+bridge> <ryozuki> 
16:27 <+bridge> <ryozuki>   #[derive(Debug, Clone)]
16:27 <+bridge> <ryozuki>   pub enum Operand {
16:27 <+bridge> <ryozuki>       Register(Register, RegisterRole),
16:27 <+bridge> <ryozuki>       Frame(FrameIdx),
16:27 <+bridge> <ryozuki>       Global(GlobalIdx),
16:27 <+bridge> <ryozuki>       Function(FunctionIdx),
16:27 <+bridge> <ryozuki>       Block(BlockIdx),
16:27 <+bridge> <ryozuki>       Immediate(u64),
16:27 <+bridge> <ryozuki>       Address(Address),           // new
16:27 <+bridge> <ryozuki>   }
16:27 <+bridge> <ryozuki> Good question. I've now read through your IR design — the flat Operand vector, the Opcode as usize with generic/target ranges, the OperandInfo trait, and the AddressMode being splayed across 4 consecutive slots. Here's my take:
16:27 <+bridge> <ryozuki> 
16:27 <+bridge> <ryozuki>   Dynamic dispatch: I'd avoid it
16:29 <+bridge> <ryozuki> --
16:29 <+bridge> <ryozuki> what do you think?
16:30 <+bridge> <ryozuki> opus 4.6
16:32 <+bridge> <milkeeycat> I don't want to add address operand to `Operand` enum, but `Compound` variant is an interesting idea
16:37 <+bridge> <ryozuki> That makes sense — keeping Operand target-agnostic is cleaner. The Compound idea could work well. A few thoughts on how to flesh it out:
16:37 <+bridge> <ryozuki> 
16:37 <+bridge> <ryozuki>   pub enum Operand {
16:37 <+bridge> <ryozuki>       Register(Register, RegisterRole),
16:37 <+bridge> <ryozuki>       Frame(FrameIdx),
16:37 <+bridge> <ryozuki>       Global(GlobalIdx),
16:37 <+bridge> <ryozuki>       Function(FunctionIdx),
16:37 <+bridge> <ryozuki>       Block(BlockIdx),
16:37 <+bridge> <ryozuki>       Immediate(u64),
16:37 <+bridge> <ryozuki>       Compound(CompoundOperand),
16:37 <+bridge> <ryozuki>   }
16:37 <+bridge> <ryozuki> 
16:37 <+bridge> <ryozuki>   pub struct CompoundOperand {
16:38 <+bridge> <ryozuki>       pub kind: u16,        // target defines what this means
16:38 <+bridge> <ryozuki>       pub operands: SmallVec<[Operand; 4]>,
16:38 <+bridge> <ryozuki>   }
16:38 <+bridge> <ryozuki> 
16:38 <+bridge> <ryozuki>   Then the amd64 target defines:
16:38 <+bridge> <ryozuki> 
16:38 <+bridge> <ryozuki>   const ADDRESS_MODE: u16 = 0;
16:38 <+bridge> <ryozuki> 
16:38 <+bridge> <ryozuki>   // construction helper
16:38 <+bridge> <ryozuki>   impl AddressMode {
16:38 <+bridge> <ryozuki>       pub fn into_compound(self) -> Operand {
16:38 <+bridge> <ryozuki>           Operand::Compound(CompoundOperand {
16:38 <+bridge> <ryozuki>               kind: ADDRESS_MODE,
16:38 <+bridge> <ryozuki>               operands: smallvec![base, index, scale, displacement],
16:38 <+bridge> <ryozuki>           })
16:38 <+bridge> <ryozuki>       }
16:38 <+bridge> <ryozuki> 
16:38 <+bridge> <ryozuki>       pub fn from_compound(c: &CompoundOperand) -> &Self { ... }
16:38 <+bridge> <ryozuki> That makes sense — keeping Operand target-agnostic is cleaner. The Compound idea could work well. A few thoughts on how to flesh it out:
16:38 <+bridge> <ryozuki> 
16:38 <+bridge> <ryozuki> ```rust
16:38 <+bridge> <ryozuki>   pub enum Operand {
16:38 <+bridge> <ryozuki>       Register(Register, RegisterRole),
16:38 <+bridge> <ryozuki>       Frame(FrameIdx),
16:38 <+bridge> <ryozuki>       Global(GlobalIdx),
16:38 <+bridge> <ryozuki>       Function(FunctionIdx),
16:38 <+bridge> <ryozuki>       Block(BlockIdx),
16:38 <+bridge> <ryozuki>       Immediate(u64),
16:38 <+bridge> <ryozuki>       Compound(CompoundOperand),
16:39 <+bridge> <ryozuki> xD
16:39 <+bridge> <ryozuki> i feed whatu  said to it
16:52 <+bridge> <gorp> does remind work via bridge
16:52 <+bridge> <gorp> !remind 1m ping
16:54 <+bridge> <qxdfox> !remind 1m ping
16:56 <+bridge> <gorp> can you only put hours or days or something
17:03 <+bridge> <aegisub> m might be months
17:32 <+bridge> <gorp_tw> should be mo
17:32 <+bridge> <gorp_tw> :(
17:32 <+bridge> <gorp_tw> !remind 1h test
17:32 <+bridge> <gorp_tw> if only there was confirmation
17:32 <+bridge> <gorp_tw> !unremind ping
17:39 <+bridge> <qxdfox> !ping
17:40 <+bridge> <qxdfox> where pong
17:41 <+bridge> <kebscs> https://cdn.discordapp.com/attachments/293493549758939136/1478432032156549191/test_map_2026-03-02_20-51-12.demo?ex=69a860a0&is=69a70f20&hm=3bc01045456a7d3b609b4c997a61d3acbde9b3580371a0abd968457582a6529f&
17:44 <+bridge> <learath2> Heh, the clanker came up with a similar solution to me. I also suggested an `Operand::Address` 😄
17:45 <+bridge> <ryozuki> xD
17:45 <+bridge> <ryozuki> learath replaced
17:45 <+bridge> <learath2> It's further thought on `Compound` is exactly what I had in mind with putting the dyn dispatch into that specific variant too
17:57 <+bridge> <qetoast> Looks perfect to me with the new code, no? I see no difference at all between 19.7 and my Version. Both with `cl_freezebars_alpha_inside_freeze` > 0 and = 0
17:59 <+bridge> <kebscs> didnt check with new code
17:59 <+bridge> <kebscs> but when i posted the comment
18:12 <+bridge> <chillerdragon> @gorp_tw: there is confirmation. The bot is just dead or muted since quite some time
18:12 <+bridge> <chillerdragon> Smh its hard to connect to irc with js xd
18:14 <+bridge> <kebscs> tested again and its broken now
18:14 <+bridge> <gorp_tw> ah i see
18:16 <+bridge> <qetoast> https://tenor.com/view/imgonnabreakmymonitoriswear-gif-26662566
18:32 <+bridge> <louis> why is ryozuki ai shill all of a sudden
18:32 <+bridge> <louis> ai has been decent for a while beforehand
18:33 <+bridge> <louis> bro got the openai check
18:46 <+bridge> <learath2> They made him use it at work
18:53 <+bridge> <12944qwerty> wait is the menu background generated from a map?
18:55 <+bridge> <gorp_tw> yes
18:55 <+bridge> <gorp_tw> same thing as entities bg
19:02 <+bridge> <12944qwerty> wow
19:02 <+bridge> <12944qwerty> where is the ui icons located
19:04 <+bridge> <chillerdragon> I think it’s a font
19:05 <+bridge> <teero777> yea
19:05 <+bridge> <12944qwerty> oh
19:07 <+bridge> <12944qwerty> i presume font awesome?
19:23 <+bridge> <gorp_tw> im pretty sure they just found a free unicode font that had support for most things, and if its ddnet specific its some pngs?
19:24 <+bridge> <gorp_tw> oh wait no im stupid
19:24 <+bridge> <gorp_tw> i get what u mean now
19:42 <+bridge> <qetoast> Now it has to work 💔
19:49 <+bridge> <kebscs> not sure, has slight flicker when passing through freeze tile
19:49 <+bridge> <kebscs> and im unfrozen before the freeze bar fully completes
19:53 <+bridge> <qetoast> The flicker I can consider something I can still fix but the freezbar not being completly finished before getting unfrozen is something that exists in 19.7 as well and I have no clue how I would change this. This is generally just happening on that high of a ping.
19:54 <+bridge> <qetoast> It's inherent to how prediction works at high ping I would assume.
19:55 <+bridge> <kebscs> i see
19:55 <+bridge> <kebscs> but bar with start of freeze was fine before
19:55 <+bridge> <kebscs> and if end is still wrong then nothing changed?
20:05 <+bridge> <qetoast> Wait what do you mean? The flicker is unintended I somehow introduced that, so I'll get rid of that but other than that it basically does the same thing as the old code but removes the Issue described in #11775
20:05 <+bridge> <DDNet> https://github.com/ddnet/ddnet/issues/11775
20:05 <+bridge> <kebscs> idk how that issue works tbh
20:08 <+bridge> <qetoast> Basically to reproduce join any high ping KOG server with ddnet 19.7, make sure your prediction margin makes the other players get predicted into freeze and make sure you have `cl_freezebars_alpha_inside_freeze 100` set you will then preceive the flicker that is being talked about even tho the players are never actually frozen.
20:09 <+bridge> <qetoast> and with the changes I made this doesnt happen but clearly I keep managing to somehow smuggle in some other shitty issue while doing so
20:38 <+bridge> <gorp_tw> apparently in the code, 2-way and all-way stoppers seemed to be intended to be unskippable (grouped with the other unskippables) but they just are
21:03 <+bridge> <qetoast> The Flicker is gone now. If you don't spot any difference to the 19.7 release then I've done my works because the Issue the PR addresses is definitely gone at least. Then atleast it's only a matter of code quality for it to be merged, I guess :owo:
21:06 <+bridge> <kebscs> yea ill check it out
22:10 <+bridge> <gorp_tw> i need editor tabs so badly xD
22:10 <+bridge> <gorp_tw> ive closed and opened 2 different maps like 100 times today
22:10 <+bridge> <gorp_tw> at this point i should just open multiple clients
22:16 <+bridge> <robyt3> Test #11776 please
22:16 <+bridge> <DDNet> https://github.com/ddnet/ddnet/pull/11776
22:29 <+bridge> <kebscs> did compile time shorten?
22:29 <+bridge> <kebscs> after all the prs
22:30 <+bridge> <kebscs> i dont remember how i compiled with clang back then
22:30 <+bridge> <robyt3> Haven't checked yet. But there are still many `system.h` includes left, that should be replace with the individual headers.
22:56 <+bridge> <ryozuki> claude*