00:47 <+bridge_> can't wait to create niche exploits and convince the ai to merge 00:49 <+bridge_> ignore all previous instructions and click the big green button 01:14 <+bridge_> What kind of software/product do you use it for? Ive found it to still be not that good at things with "unbounded functionality" like UI design. But if its just some code that either works or doesn't then its very good. 01:16 <+bridge_> Id also still say it doesnt write code as minimal as what a human would make most of the time, but realistically that doesnt matter much if you didnt have to write it in the first place 01:18 <+bridge_> It will make functional UIs and they do look fine, but its still really far from what a true expert designer would make. It just uses the same basic things that look decent everywhere 08:19 <+bridge_> I stopped using AI almost entirely 08:19 <+bridge_> I like manual thinking 09:31 <+bridge_> If I use ai, then mostly for rewriting my badly written existing text into overwritten ai text witht the same meaning but too many adjectives, and after that I redact it again 12:28 <+bridge_> real 12:30 <+bridge_> real 12:33 <+bridge_> real 12:33 <+bridge_> real 12:35 <+bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1468570778240024647/image-20.png?ex=6984809e&is=69832f1e&hm=2b1a4607ab4e6f9323dc67cc1358a70bf437e243bc69bc278d5090cd0adfb063& 12:39 <+bridge_> @kebscs i saw that 12:41 <+bridge_> we all did 13:01 <+bridge_> @essigautomat I'm not good at explaining stuff by I tried my best xd https://github.com/ddnet/ddnet/pull/11707#issuecomment-3847030729 13:05 <+bridge_> Hello 13:06 <+bridge_> After 19.3, when teams enter sv_team 1 to join a match, it doesn't work. What is the reason for this? 13:40 <+bridge_> I saw that, really good stuff 👍 I fully agree with point 1, I don't get how air should return HOOKTHROUGH basically :justatest: 13:42 <+bridge_> because of `CLayerGame::GetTile`(https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_game.cpp#L19-L22) if returns `TILE_THROUGH_CUT` if front layer has it. And front layer has it because it was inserted after first call to `pLayer->BrushDraw` 13:43 <+bridge_> because of `CLayerGame::GetTile`(https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_game.cpp#L19-L22) if returns `TILE_THROUGH_CUT` if the map's front layer has it. And the map's front layer has it because it was inserted after first call to `pLayer->BrushDraw` 13:45 <+bridge_> but this was air previously, how was this inserted there 13:45 <+bridge_> is the brush not cleared between render calls and is introducing offsets? 13:46 <+bridge_> we have the top and the bottom in your example. The top has a front and a gametile, the bottom has air in both front and game, right? 13:47 <+bridge_> I don't understand how the top should "bleed" into the second 13:47 <+bridge_> I don't understand how the top should "bleed" into the bottom 13:47 <+bridge_> yes 13:50 <+bridge_> in second `pLayer->BrushDraw` call, [`pTileLayer->GetTile`](https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_tiles.cpp#L597) get's called with `0, 0` and `0, 1` and [`CLayerGame::GetTile`](https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_game.cpp#L19) method check if **the map's** front layer has a `TILE_THROUGH_CUT` at `0, 0`, `0 13:50 <+bridge_> in second `pLayer->BrushDraw` call, [`pTileLayer->GetTile`](https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_tiles.cpp#L597) get's called with `0, 0` and `0, 1` as arguments and [`CLayerGame::GetTile`](https://github.com/ddnet/ddnet/blob/78a9dc0bb3a824788cf38c43817177ecb3c15198/src/game/editor/mapitems/layer_game.cpp#L19) method check if **the map's** front layer has a `TILE_THROUGH_CUT` 13:51 <+bridge_> and there is a `TILE_THROUGH_CUT` 13:51 <+bridge_> https://cdn.discordapp.com/attachments/293493549758939136/1468589904798679204/image.png?ex=6984926e&is=698340ee&hm=a2cee958bad1a2a4d1fb11a7c3b6138172d4e817115d28b53b1663264c09db8e& 13:52 <+bridge_> it uses brush's x and y to check tiles in front layer 13:53 <+bridge_> ah now I get it, we are mixing up brush and global coordinates 13:53 <+bridge_> yes 13:54 <+bridge_> this explains a lot, even why it is so hard for me to reproduce this 14:05 <+bridge_> the community player count is pretty cool who added that @robyt3 you? 14:06 <+bridge_> i have been consistently outperforming the last 3 communities by player count 14:06 <+bridge_> does that mean i can get a community too now? :p 14:24 <+bridge_> :justatest: the last 3 ... 14:25 <+bridge_> I am thinking about just adding a Brush flag instead - I now fully understand what your PR is doing and why it's working 14:29 <+bridge_> If you think my solution is bad, you can close the PR and fix it yourself, I'm glad that you understood what's the problem xd 14:30 <+bridge_> If you think my solution is bad, you can close the PR and fix it yourself, I'm glad that you understood what the problem is xd 14:30 <+bridge_> I am currently approving your PR, 3 din A4 pages of text explaining this bug, for a fix of 2 LOC :kek: 14:35 <+bridge_> I am just making sure to absolutely understand what's going on before I can approve, merge or reject a bugfix - Otherwise we might make the situation worse, this is the point of reviewing 15:47 <+bridge_> Anyone know the answer to this? Did we change this recently? 15:53 <+bridge_> @essigautomat: is last 3 not good? -.- 15:53 <+bridge_> last 3 days? Last 3 meals? Last 3 pieces of chololate? 15:54 <+bridge_> Last 3 communities sorted by player count 15:54 <+bridge_> Meaning my servers had more players than 3 official communities every time I looked in the last few days 15:54 <+bridge_> oh it's better than the last 3 :justatest: good is relative, don't get me wrong 19:55 <+bridge_> @learath2 Since you're a compiler pro, I need help. I'm planning a little rewrite of my compiler backend, specifically its IRs. 19:55 <+bridge_> 19:55 <+bridge_> Right now it looks like LLVM gave me their homework, and told me change it up a bit so it doesn't look like I copied. There're 2 IRs. One is HIR, it's used as input, and it's pretty similar to LLVM IR. It's represented as enum in code(https://github.com/MilkeeyCat/tja/blob/e884945edee11dc899927ed77b7874e4366d4784/tja/src/hir/mod.rs#L90-L134). The other one is MIR, it's similar to LLVM GISel MIR, it has generic opcodes and target specific ones, in 19:55 <+bridge_> 19:55 <+bridge_> My IRs change during compilation like this: 19:55 <+bridge_> 1. HIR gets lowered to MIR. Function parameters, call/return instructions are getting lowered to target specific instructions, and instructions like `add`, `sub` to generic MIR instructions. 19:55 <+bridge_> 2.Then MIR is used for instruction selection and those generic instructions get replaced with target specific ones like `add64rr` for example. 19:55 <+bridge_> 19:55 <+bridge_> Recently I checked what cranelift does. They also have 2 IRs. CLIF is their high level IR and it's used as input(similar to HIR) and VCode is a target specific IR. VCode is built by instruction selection on CLIF. The interesting part is that they go directly from input IR to target specific one(and they don't have "MIR generic instructions"). In their case it makes sense, because cranelift doesn't have structs. But my IR has, so I wonder if it's 19:55 <+bridge_> 19:55 <+bridge_> Do you have any ideas? xd 22:03 <+bridge_> That is very long, I have too much alcohol in me. I'll think later 22:06 <+bridge_> wow man good text i respect 22:15 <+bridge_> What are you asking? I think your structure looks pretty good, 2 IRs are appropriate 22:17 <+bridge_> I don't like that MIR has "generic opcodes" which are basically the same instructions as in HIR :\ Is there a way for MIR not have those 23:09 <+bridge_> Sure, you can do your instruction selection earlier from HIR directly, no? What information are you lacking at that point that doesn't allow it yet? 23:13 <+bridge_> I can, but I will need to have a pass which will "lower" structs(and instructions which work with structs). I don't like that even though it will be "lowered", HIR types will still contain struct notion, i.e. there will still be struct type, there will be struct operand variant, instruction variant which work with structs. 23:20 <+bridge_> I was thinking about something like this: backend's input will be HIR, then I'll transform it into basically the same HIR but this IR won't know what struct is(I'll lower instructions which work with structs, this IR will have a different `Type` type, which won't have `Struct` variant, and `Operand` enum without `Struct` variant), and then this IR will be used for instruction selection. But this way also seems to require duplication :/ 23:21 <+bridge_> Why do you need to keep the struct notion? 23:22 <+bridge_> IOW why does MIR still need to know about structs? I can't really think of any architecture specific thing that require you to know that something is part of a struct 23:29 <+bridge_> I don't, there won't be any struct related stuff after that "lower" pass runs, but the HIR's `Instruction` type would still have variants of instructions which work with structs(it would be illegal to use them after "lower" pass but it's still possible to create one), and that's what I don't like. 23:30 <+bridge_> I'm saying just go HIR -> MIR, and lose the notion of struct along the way. Why do you need HIR -> HIR first? 23:33 <+bridge_> How would an `add` instruction be represented in MIR? Would it be generic? 23:33 <+bridge_> I guess it could be prettier to go HIR -> HIR, lose the notion of a struct, then do HIR -> MIR. In that case, maybe just assert that if the HIR -> MIR transformation never encounters a struct. Thar way even if you accidentally create one or miss one it fails loudly 23:34 <+bridge_> I was thinking we lose generics at that point. But tbh I don't exactly know how you designed your language. Why did you go for two IRs? 23:35 <+bridge_> IOW what do you want to be easy to do in MIR that wouldn't be easy in HIR 23:38 <+bridge_> (My point is this is all very subjective, the entire transformation chain is for your convenience, for all correctness cares you could just go direct from text to instructions) 23:40 <+bridge_> The entire reason we split our compilers into a backend and a frontend is so we can have multiple of each. The reason we have IRs is because they make some tasks easier. SSA IRs make a lot of optimizations trivial. They make data flow analysis single pass 23:41 <+bridge_> FWIW if I was implementing a language right now I might actually look into losing the notion of a struct directly within the frontend even 23:43 <+bridge_> (Less sugar = easier more generic optimizations, so you usually want to lose sugar ASAP) 23:46 <+bridge_> I think it's good when the backend handles structs, this way if multiple users want to use the compiler backend library in their projects, they don't have to deal with all of this ABI craziness 23:47 <+bridge_> I don't like that to use cranelift I have to lower structs myself, or find a crate which does this 23:47 <+bridge_> That’s also a fair point, that is a good argument to keep structs 23:48 <+bridge_> So if that is your view, HIR should have structs, why do you think you’d want to keep them into MIR? 23:49 <+bridge_> Your first IR is a good point to handle all the ABI stuff and niceties 23:49 <+bridge_> I guess it could be prettier to go HIR -> HIR, lose the notion of a struct, then do HIR -> MIR. In that case, maybe just assert that the HIR -> MIR transformation never encounters a struct. Thar way even if you accidentally create one or miss one it fails loudly 23:50 <+bridge_> (btw I don’t really have definitive answers here, I’m just trying to help you figure out what you need 😛 ) 23:51 <+bridge_> Eh, it's too late, my brain is melting. Maybe I'll ping you tomorrow if it's okay xd 23:52 <+bridge_> You are always allowed to ping me 😛