00:22 < ws-client> @ryozuki yes mestalin had another name: xush 00:25 < bridge> meskalin? 00:25 < bridge> 👀 00:26 < bridge> botox? 00:26 < ws-client> https://zillyhuhn.com/cs/.1743031577.png 00:26 < bridge> wait what??? 00:26 < bridge> why is freezehammer being removed 00:26 < ws-client> ddnet is no fun zone 00:27 < bridge> b-but 00:27 < ws-client> admins abused it to cheat shorter freeze times 00:27 < bridge> what? 00:27 < ws-client> jk 00:27 < bridge> lets remove invinsible 00:27 < bridge> aswell then ): 00:27 < ws-client> we never had that 00:27 < bridge> let's remove admins 00:27 < bridge> 👀 00:27 < bridge> f3 00:28 < ws-client> yes admins are the worst 00:28 < bridge> got 'em 00:29 < bridge> @chillerdragon btw uhmm 00:29 < bridge> with ddnet-insta you cant control much about ammo even with grenade 00:29 < bridge> i cant figure out how to make greande regen instantly or have infinate ammo 00:29 < bridge> and all the other weapons dont get any args 00:29 < bridge> also shouldnt they be tunes 00:29 < bridge> now ban them, admins! attack! 00:29 < bridge> :kek: 00:30 < bridge> gn8 02:31 < bridge> in demos, is g_Config.m_ClDummy always 0? 11:21 < bridge> @learath2 any clue why my macos build fails to compile 11:21 < bridge> on stuff like the std 11:21 < bridge> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk/usr/include/c++/v1/cmath:597:15 11:24 < bridge> ``` 11:24 < bridge> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.2.sdk/usr/include/c++/v1/cwctype:59:5: error: tried including but didn't find libc++'s header. This usually means that your header search paths are not configured properly. The header search paths should contain the C++ Standard Library headers before any C Standard Library, and you are probably 11:24 < bridge> 59 | # error tried including but didn't find libc++'s header. \ 11:24 < bridge> | ^ 11:24 < bridge> ``` 11:24 < bridge> i hate macos 11:28 < bridge> wtf 11:28 < bridge> `sudo xcode-select -s /Library/Developer/CommandLineTools` 11:28 < bridge> fixed it 11:37 < bridge> @jupeyy_keks i got this idk why 11:37 < bridge> 11:37 < bridge> ``` 11:37 < bridge> 2025-03-27 11:36:31 I vulkan: no compatible driver found. Vulkan 1.1 is required. 11:37 < bridge> 2025-03-27 11:36:31 I vulkan: vulkan warning: Creating instance failed. 11:37 < bridge> 2025-03-27 11:36:31 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:37 < bridge> 2025-03-27 11:36:31 I gfx: Created OpenGL 3.0 context. 11:37 < bridge> 2025-03-27 11:36:32 I gfx: unable to create graphic context: Failed creating OpenGL context at version requested 11:37 < bridge> 2025-03-27 11:36:32 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:37 < bridge> 2025-03-27 11:36:32 I gfx: Created OpenGL 2.1 context. 11:37 < bridge> 2025-03-27 11:36:32 I opengl: Vendor string: Apple 11:37 < bridge> 2025-03-27 11:36:32 I opengl: Version string: 2.1 Metal - 89.3 11:37 < bridge> 2025-03-27 11:36:32 I gfx: GPU vendor: Apple 11:37 < bridge> 2025-03-27 11:36:32 I gfx: GPU renderer: Apple M3 Pro 11:37 < bridge> 2025-03-27 11:36:32 I gfx: GPU version: 2.1 Metal - 89.3 11:38 < bridge> ``` 11:38 < bridge> i got the red popup saying failed 11:38 < bridge> @jupeyy_keks i got this idk why 11:38 < bridge> 11:38 < bridge> ``` 11:38 < bridge> 2025-03-27 11:37:54 I gfx: Created Vulkan 1.1 context. 11:38 < bridge> 2025-03-27 11:36:31 I vulkan: no compatible driver found. Vulkan 1.1 is required. 11:38 < bridge> 2025-03-27 11:36:31 I vulkan: vulkan warning: Creating instance failed. 11:38 < bridge> 2025-03-27 11:36:31 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:38 < bridge> 2025-03-27 11:36:31 I gfx: Created OpenGL 3.0 context. 11:38 < bridge> 2025-03-27 11:36:32 I gfx: unable to create graphic context: Failed creating OpenGL context at version requested 11:38 < bridge> 2025-03-27 11:36:32 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:38 < bridge> 2025-03-27 11:36:32 I gfx: Created OpenGL 2.1 context. 11:38 < bridge> 2025-03-27 11:36:32 I opengl: Vendor string: Apple 11:38 < bridge> 2025-03-27 11:36:32 I opengl: Version string: 2.1 Metal - 89.3 11:38 < bridge> 2025-03-27 11:36:32 I gfx: GPU vendor: Apple 11:38 < bridge> 2025-03-27 11:36:32 I gfx: GPU renderer: Apple M3 Pro 11:38 < bridge> 2025-03-27 11:36:32 I gfx: GPU version: 2.1 Metal - 89.3 11:38 < bridge> ``` 11:39 < bridge> i got the red popup saying failed 11:39 < bridge> MoltenVK installed? 11:39 < bridge> let me see 11:39 < bridge> When we met, it stilled worked, you even showed me the bug XD 11:39 < bridge> Warning: molten-vk 1.2.11 is already installed and up-to-date. 11:39 < bridge> To reinstall 1.2.11, run: 11:39 < bridge> brew reinstall molten-vk 11:39 < bridge> yeah xd, im using last commit now 11:39 < bridge> u told me to test hidpi 11:39 < bridge> yeah, shouldn't have messed with your moltenvk setup.. weird 😄 11:39 < bridge> cmake -DVULKAN=ON -G Ninja .. 11:39 < bridge> looks correct to me 11:40 < bridge> reinstalling molten 11:40 < bridge> -- * Vulkan found 11:40 < bridge> -- Building vulkan shaders 11:40 < bridge> /Users/edgarluque/Documents/misc/ddnet/data/shader/vulkan/quad.vert 11:40 < bridge> -- Finished building vulkan shaders 11:41 < bridge> it also can build the shaders 11:41 < bridge> -- Building vulkan shaders 11:41 < bridge> /Users/edgar/Documents/misc/ddnet/data/shader/vulkan/quad.vert 11:41 < bridge> -- Finished building vulkan shaders 11:41 < bridge> @jupeyy_keks one weird thing 11:41 < bridge> after the build 11:41 < bridge> ld: warning: ignoring duplicate libraries: '-lvulkan' 11:41 < bridge> 😮 11:41 < bridge> [324/324] Linking CXX executable DDNet 11:41 < bridge> ld: warning: ignoring duplicate libraries: '-lvulkan' 11:42 < bridge> Can you lookup where brew installs the package files to? 11:42 < bridge> It should have installed a json file somewhere 11:42 < bridge> ❯ ls /opt/homebrew/opt/molten-vk 11:42 < bridge> Frameworks LICENSE bin include libexec 11:42 < bridge> INSTALL_RECEIPT.json README.md etc lib sbom.spdx.json 11:43 < bridge> the etc 11:43 < bridge> might be interesting 11:43 < bridge> ❯ ls /opt/homebrew/opt/molten-vk/etc/vulkan 11:43 < bridge> icd.d 11:43 < bridge> yes 11:43 < bridge> ❯ ls /opt/homebrew/opt/molten-vk/etc/vulkan/icd.d 11:43 < bridge> MoltenVK_icd.json 11:43 < bridge> inside icd it should be 11:43 < bridge> try to start ddnet with 11:43 < bridge> 11:43 < bridge> ``` 11:43 < bridge> VK_ICD_FILENAMES=/opt/homebrew/opt/molten-vk/etc/vulkan/icd.d/MoltenVK_icd.json ./DDNet 11:43 < bridge> ``` 11:43 < bridge> ❯ cat /opt/homebrew/opt/molten-vk/etc/vulkan/icd.d/MoltenVK_icd.json 11:43 < bridge> { 11:43 < bridge> "file_format_version" : "1.0.0", 11:43 < bridge> "ICD": { 11:43 < bridge> "library_path": "../../../lib/libMoltenVK.dylib", 11:43 < bridge> "api_version" : "1.2.0", 11:44 < bridge> "is_portability_driver" : true 11:44 < bridge> } 11:44 < bridge> } 11:44 < bridge> 2025-03-27 11:44:13 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:44 < bridge> 2025-03-27 11:44:13 I gfx: Created Vulkan 1.1 context. 11:44 < bridge> 2025-03-27 11:44:13 I vulkan: no compatible driver found. Vulkan 1.1 is required. 11:44 < bridge> 2025-03-27 11:44:13 I vulkan: vulkan warning: Creating instance failed. 11:44 < bridge> 2025-03-27 11:44:13 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:44 < bridge> 2025-03-27 11:44:13 I gfx: Created OpenGL 3.0 context. 11:44 < bridge> 2025-03-27 11:44:13 I gfx: unable to create graphic context: Failed creating OpenGL context at version requested 11:44 < bridge> 2025-03-27 11:44:13 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:44 < bridge> 2025-03-27 11:44:13 I gfx: Created OpenGL 2.1 context. 11:44 < bridge> 2025-03-27 11:44:13 I opengl: Vendor string: Apple 11:44 < bridge> 2025-03-27 11:44:13 I opengl: Version string: 2.1 Metal - 89.3 11:44 < bridge> 2025-03-27 11:44:13 I gfx: GPU vendor: Apple 11:44 < bridge> 2025-03-27 11:44:13 I gfx: GPU renderer: Apple M3 Pro 11:44 < bridge> 2025-03-27 11:44:13 I gfx: GPU version: 2.1 Metal - 89.3 11:44 < bridge> 2025-03-27 11:44:13 I sound: sound init successful using audio driver 'coreaudio' 11:44 < bridge> 2025-03-27 11:44:13 I textrender: Freetype version 2.13.3 (compiled = 2.13.3) 11:45 < bridge> 2025-03-27 11:44:13 I joystick: 0 joystick(s) found 11:45 < bridge> 2025-03-27 11:44:13 E serverbrowser: invalid address (ServerIndex=0, TypeIndex=6, AddressIndex=6) 11:45 < bridge> 2025-03-27 11:44:13 E serverbrowser: invalid address (ServerIndex=0, TypeIndex=8, AddressIndex=8) 11:45 < bridge> 2025-03-27 11:44:13 I gfx: unable to get display mode: displayIndex must be in the range 0 - 0 11:45 < bridge> 2025-03-27 11:44:13 I gfx: unable to get display mode: displayIndex must be in the range 0 - 0 11:45 < bridge> 2025-03-27 11:44:14 I http: task done: https://master1.ddnet.org/ddnet/15/servers.json 11:45 < bridge> 2025-03-27 11:44:14 I client: version 19.2 on macos arm64 11:45 < bridge> 2025-03-27 11:44:14 I client: git revision hash: 44f7db9c9872eed7 11:45 < bridge> 2025-03-27 11:44:14 W client: Warning: Could not initialize Vulkan: Creating instance failed. Could not initialize the given graphics backend, reverting to the default backend now. 11:45 < bridge> nope 11:45 < bridge> ok weird 11:45 < bridge> dunno what's broken :/ 11:45 < bridge> idk :d 11:45 < bridge> mac sux 11:45 < bridge> But thanks for testing xd 11:45 < bridge> :13 I sdl: SDL version 2.30.5 (compiled = 2.0.20) 11:45 < bridge> could this have. smth? 11:45 < bridge> i mean you could try to copy `libMoltenVK.dylib` to `libvulkan.dylib` directly next to the binary or smth 11:46 < bridge> 😮 i dunno, we use the SDL vulkan loader but with a custom path i think 11:46 < bridge> do you have: 11:46 < bridge> brew install vulkan-loader 11:46 < bridge> installed? 11:46 < bridge> ==> Downloading https://formulae.brew.sh/api/cask.jws.json 11:46 < bridge> Warning: vulkan-loader 1.4.311 is already installed and up-to-date. 11:46 < bridge> To reinstall 1.4.311, run: 11:46 < bridge> brew reinstall vulkan-loader 11:48 < bridge> This is what deen did for ddnet-rs 11:48 < bridge> That's also why I want a static build of moltenvk. 11:48 < bridge> 11:48 < bridge> Because it sucks to deal with such issues xD 11:51 < bridge> @ryozuki But if you have time, just download and exec this: 11:51 < bridge> 11:51 < bridge> 11:51 < bridge> or if you prefer to build from src 11:51 < bridge> 11:51 < bridge> i'd be interested in that too. 12:07 < bridge> Why can `m_pSkinInfo` be nullptr anyway, seems like we'd rather want a differenciaction between `FallbackToDefault` and `FullyLoaded` 12:21 < bridge> @learath2 is it had to make a c compiler? 12:21 < bridge> since im into compilers maybe ill do it 12:21 < bridge> i think a C compiler without preprocessor is somewhat a doable project in short time 12:22 < bridge> ok the include is preprocessor 12:22 < bridge> hmm idk what would be the hard part 12:22 < bridge> maybe im confusing with c++ since there is no templates it should be easy to do? 12:23 < bridge> Mh, not particularly (barring optimizations). C is fairly simple to parse/lex and also translates fairly naturally to assemblies 12:23 < bridge> maybe the hardest part would be making it compliant fully or smth 12:23 < bridge> As with all compilers hard part is imo optimizations 12:23 < bridge> and the static analysis for -W flags 12:23 < bridge> yeah but llvm does it for me kek 12:23 < bridge> someday ill make my own backend 12:24 < bridge> but that requires lot of time 12:24 < bridge> just for 1 arch 12:24 < bridge> Yeah you could make mistakes here with this, lots of tiny details with C 12:24 < bridge> i guess its also a good way to learn more about c 12:25 < bridge> This is also not that easy indeed, but iirc not required 12:25 < bridge> https://github.com/mortdeus/legacy-cc/tree/master/last1120c 12:25 < bridge> first compiler C code 12:25 < bridge> from 1972 12:26 < bridge> ```c 12:26 < bridge> main(argc, argv) 12:26 < bridge> int argv[]; { 12:26 < bridge> extern init, flush; 12:26 < bridge> extern extdef, eof, open, creat; 12:26 < bridge> extern fout, fin, error, exit, nerror, tmpfil; 12:26 < bridge> ``` 12:26 < bridge> weird syntax 12:27 < bridge> Oh yeah, early C looks weeeird 12:28 < bridge> u know the requirement to declare variables at start of function 12:28 < bridge> aligns a lot with how assembly works 12:28 < bridge> its like u dont have to do a prepass on the function to allocate stack space for variables 12:28 < bridge> u can do it in a single pass 12:28 < bridge> since u know vars are declared first 12:28 < bridge> I would guess that's probbaly why it was a requirement 12:28 < bridge> also llvm has a pass to put all allocas at start 12:29 < bridge> C was really designed in a way that makes the compilers job easy 12:29 < bridge> well it not like itsh ard to find variables used 12:29 < bridge> u just need a extra pass 12:29 < bridge> single pas. compilers are cool tho 12:29 < bridge> like turbopascal 12:30 < bridge> Declaration syntax following use is also very handy, you can use the same machinery to determine types and evaluate expressions 12:30 < bridge> can u give a example of what u mean? 12:31 < bridge> Well with the computers of the day I'd guess the extra pass is far slower than what we now experience 12:31 < bridge> probs 12:32 < bridge> the preprocessor is a pass too, but it makes it so the compile phase doesnt need to do a extra pass to resolve imports 12:32 < bridge> also forward declarations are made to avoid the extra pass too 12:33 < bridge> For a C declaration, you can take the stuff after the type and it's exactly the same syntax as how you'd use that variable in code. That means evaluating a declaration requires no special parsing, you just skip the type and evaluate the expression 12:33 < bridge> its probs also cheaper to use the preprocessor for resolving imports since u dont need to traverse the ast its just text replacement 12:33 < bridge> i would say C was made to be easily compiled indeed 12:34 < bridge> ah ic 12:35 < bridge> altho idk if the C grammar is context free 12:35 < bridge> probs not 12:35 < bridge> if its llk i think its linear parse time guaranteed 12:35 < bridge> I can't really know what they were thinking at the time, but that'd be my guess too 12:35 < bridge> or lalr 12:36 < bridge> Eeeeeh, I can only think of typedefs not being context free 12:37 < bridge> So I guess yeah you are right 12:39 < bridge> `x * y;` this is also not very context free 12:40 < bridge> Hm, it should be. That's always an arithmetic expression 12:40 < bridge> char *foo; 12:41 < bridge> i think a contex free grammar can have x * y and char * foo if they are separated by the = 12:41 < bridge> I see what you mean but that's not enough to make it not context free. It's always either a declaration or an arithmetic expression, but you'll know that as soon as you parse x. UNLESS typedefs are allowed 12:41 < bridge> lhs and rhs 12:44 < bridge> I can't really think of anything but typedefs introducing syntax rules at compile time. But I'm also very sleepy soo I might be missing something 12:46 < bridge> (The preprocessor on the other hand is obviously not context free at all) 14:20 < bridge> @milkeeycat daily lang dev update: got generic parameter type inference, no more ::<> on fn calls 14:20 < bridge> ```rust 14:20 < bridge> mod test { 14:20 < bridge> 14:20 < bridge> 14:20 < bridge> fn hello(x: u64) -> T { 14:20 < bridge> return x as T; 14:20 < bridge> } 14:20 < bridge> 14:20 < bridge> fn main() -> u32 { 14:20 < bridge> let ex: u64 = 2; 14:20 < bridge> let result: u32 = hello(ex); 14:20 < bridge> 14:20 < bridge> return result; 14:20 < bridge> } 14:20 < bridge> } 14:20 < bridge> ``` 14:20 < bridge> new color scheme in discord is so meh 14:20 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1354807374069764108/image.png?ex=67e6a231&is=67e550b1&hm=e24ff63dcbb4357ea2806abdd1a1ad6f73241ef953560fa30ec342add752feeb& 14:21 < bridge> epyc 14:21 < bridge> well this example is wrong cuz i dont have inference for return type generics 14:21 < bridge> its this 14:21 < bridge> ```rust 14:21 < bridge> mod test { 14:21 < bridge> fn hello(x: T) -> u32 { 14:21 < bridge> return x as u32; 14:21 < bridge> } 14:21 < bridge> 14:21 < bridge> fn main() -> u32 { 14:21 < bridge> 14:21 < bridge> let ex: u64 = 2; 14:21 < bridge> let result: u32 = hello(ex); 14:21 < bridge> 14:21 < bridge> return result; 14:21 < bridge> } 14:21 < bridge> } 14:21 < bridge> ``` 14:21 < bridge> xd 14:21 < bridge> infering the return type is a bit more complex :d 14:21 < bridge> is it possible to pass user defined types yet? 14:22 < bridge> iirc I wanted to do something like `func::()` and it didn't work 14:22 < bridge> ii got a nice error for the previous example tho 14:22 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1354807909149704424/imagen.png?ex=67e6a2b0&is=67e55130&hm=e77d75bb49699852cee189cb1b153588d2a4f01d5fb8a818c15d56fedc39f2ce& 14:23 < bridge> hm odd 14:23 < bridge> odd mine looks ok 14:23 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1354808026594541668/imagen.png?ex=67e6a2cc&is=67e5514c&hm=1f934d2b5f5c64028558eec7ef2f73598e74f3b13e02d78b17d9b185ddc2da0e& 14:23 < bridge> use this theme 14:23 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1354808114310025266/imagen.png?ex=67e6a2e1&is=67e55161&hm=25a1453f5d0e07419a995b361d6ef961b5484718d67d22a0ebbe38e40bdb6733& 14:24 < bridge> send example code xd 14:24 < bridge> i prefer 2nd one 😬 14:25 < bridge> ah, the type was in a module 14:25 < bridge> ```rust 14:25 < bridge> mod test { 14:25 < bridge> 14:25 < bridge> struct Test { 14:25 < bridge> a: u32 14:25 < bridge> } 14:25 < bridge> 14:25 < bridge> fn hello(x: T) -> u32 { 14:25 < bridge> return x.a; 14:25 < bridge> } 14:25 < bridge> 14:25 < bridge> fn main() -> u32 { 14:25 < bridge> let ex: Test = Test { 14:25 < bridge> a: 2 14:26 < bridge> }; 14:26 < bridge> // let result: u32 = hello::(ex); 14:26 < bridge> let result: u32 = hello(ex); 14:26 < bridge> 14:26 < bridge> return result; 14:26 < bridge> } 14:26 < bridge> } 14:26 < bridge> ``` 14:26 < bridge> works for me 14:26 < bridge> ic, submodule or like at same level? 14:26 < bridge> change 14:26 < bridge> ```rust 14:26 < bridge> struct Test { 14:26 < bridge> a: u32 14:26 < bridge> } 14:26 < bridge> ``` 14:26 < bridge> to 14:26 < bridge> ```rust 14:26 < bridge> mod test { 14:26 < bridge> struct Test { 14:26 < bridge> a: u32 14:26 < bridge> } 14:26 < bridge> } 14:26 < bridge> ``` 14:28 < bridge> ```rust 14:28 < bridge> mod test { 14:28 < bridge> import a.{Test}; 14:28 < bridge> 14:28 < bridge> mod a { 14:28 < bridge> struct Test { 14:28 < bridge> a: u32 14:28 < bridge> } 14:28 < bridge> } 14:28 < bridge> 14:28 < bridge> 14:28 < bridge> fn hello(x: T) -> u32 { 14:28 < bridge> return x.a; 14:28 < bridge> } 14:28 < bridge> 14:28 < bridge> fn main() -> u32 { 14:28 < bridge> let ex: Test = a::Test { 14:28 < bridge> a: 2 14:28 < bridge> }; 14:28 < bridge> // let result: u32 = hello::(ex); 14:28 < bridge> let result: u32 = hello(ex); 14:28 < bridge> 14:28 < bridge> return result; 14:29 < bridge> } 14:29 < bridge> } 14:29 < bridge> ``` 14:29 < bridge> this works 14:29 < bridge> but i found the issue 14:29 < bridge> i think using a type with path on the lhs of a let doesnt resolve the type if u use a full path 14:29 < bridge> a::Test before the = doesnt work 14:29 < bridge> can you do `let result: u32 = hello::(ex);`? 14:43 < bridge> rust pros i have a question, is it possible to make rust show error if `n` is used after dropping `ctx` 😬 ? 14:43 < bridge> ```rust 14:43 < bridge> use bumpalo::Bump; 14:43 < bridge> 14:43 < bridge> struct Context<'a> { 14:43 < bridge> allocator: &'a Bump, 14:43 < bridge> } 14:43 < bridge> 14:43 < bridge> impl<'a> Context<'a> { 14:43 < bridge> pub fn new() -> Context<'a> { 14:43 < bridge> Self { 14:43 < bridge> allocator: Box::leak(Box::new(Bump::new())), 14:43 < bridge> } 14:43 < bridge> } 14:43 < bridge> 14:43 < bridge> pub fn alloc_i32(&mut self) -> &'a i32 { 14:43 < bridge>