02:48 <+bridge> [ddnet] @.pet 08:39 <+bridge> [ddnet] I had it on my 10 year old iPhone but I reset it last week \:( still got it on my iPad. It’s really nice that someone went through the trouble of porting it to iOS all those years ago. I fear it is not a community project or open source something that one could revive or manually flash on a iPhone. It felt more like they wanted to make a business out of it. 08:39 <+bridge> [ddnet] (@Kicker) 10:55 <+bridge> [ddnet] Hi from tokyo 10:58 <+bridge> [ddnet] Its 18:58 10:58 <+bridge> [ddnet] Bye sunday 11:06 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1056513170371514398/Screenshot_2022-12-25-19-05-53-368_org.mozilla.firefox.jpg 11:06 <+bridge> [ddnet] Kek 14:54 <+ChillerDragon> deen starring own repos again xd 14:57 <+bridge> [ddnet] chillerdragon: when do you give a teeworlds motivation video for developers 14:57 <+bridge> [ddnet] Easy to misclick, there is no confirmation or anything 15:53 < furo> Hey! The hours played the past 365 days that's seen on player profiles does not seem to add up. Let's say a player plays under one hour each day, their total will still be 0 because it gets rounded down to nearest hour (0) for each date. Also the JSON should probably return in seconds and the field "hours_played_past_365_days" is total playtime and not the past 365 days. 15:54 <+bridge> [ddnet] @deen ^ 16:07 <+bridge> [ddnet] but then **hours**_played_past_365_days is misleading if you send seconds 17:08 <+ChillerDragon> @Jupstar ✪ actually thought about it xd 17:08 <+ChillerDragon> but lazy 17:25 <+bridge> [ddnet] furo: Thanks for report. I fixed the hours_played_past_365_days. It was a conscious decision not to print out the seconds played, but only hours resolution 17:25 <+bridge> [ddnet] Do you have a good use case for wanting seconds? 17:35 <+furo> deen: Well, mainly because that's the way it's stored. And also because it doesn't show any decimals. For example if you take a look at the activity array, it usually says 0 hours played if they play under an hour which is misleading. 18:07 <+bridge> [ddnet] I didn't want this to be too much of a way of stalking people 18:07 <+bridge> [ddnet] so I thought 1 hour accuracy is fine-ish 18:08 <+bridge> [ddnet] If you have a use case for seconds, we can think about it 18:26 <+furo> Fair enough, just a bit weird. I personally don't have any use case, as I have the data parsed locally. 18:31 <+bridge> [ddnet] what about minutes 18:59 <+bridge> [ddnet] @deen yup, i just fetched and same error for #6185 18:59 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/6185 19:10 <+bridge> [ddnet] I see, can reproduce it 19:13 <+bridge> [ddnet] names collision... 19:13 <+bridge> [ddnet] IStorage is a class defined in system headers 19:13 <+bridge> [ddnet] so we might need to use namespace 19:13 <+bridge> [ddnet] Yeah, that's why we use the win32 mean and lean definition 19:13 <+bridge> [ddnet] I'll try to fix it 19:13 <+bridge> [ddnet] define* 19:14 <+bridge> [ddnet] ugly fix, wrap `#include curl` into its own namespace 😄 19:14 <+bridge> [ddnet] probably wont compile anyway 19:18 <+bridge> [ddnet] latest commit fails later 19:18 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1056637084825305189/message.txt 19:30 <+bridge> [ddnet] @heinrich5991 #6188 is not fixed with MinGW64, at least for system.cpp 19:30 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/6188 19:31 <+bridge> [ddnet] cant we use like __mingw_printf or smth 19:31 <+bridge> [ddnet] its kinda ridiculous that this doesnt work lmao 19:32 <+bridge> [ddnet] what's the problem there? 19:33 <+bridge> [ddnet] same warning as for backend_vulkan.cpp, see linked issue #6187 19:33 <+bridge> [ddnet] https://github.com/ddnet/ddnet/issues/6187 19:36 <+bridge> [ddnet] `%I64d` throws no warning on MinGW 19:37 <+bridge> [ddnet] but PRId64 doesn't work? 19:37 <+bridge> [ddnet] @Chairn But I used exactly %I64d for it in https://github.com/ddnet/ddnet/pull/6188/files 19:38 <+bridge> [ddnet] it expands to `%lld` and throws warning: `unknown conversion type character 'l' in format` 19:38 <+bridge> [ddnet] that seems like a bug in mingw 19:38 <+bridge> [ddnet] did you get the latest v ersion of 6188? 19:38 <+bridge> [ddnet] but PRI64d is defined 19:38 <+bridge> [ddnet] i pushed a new one later 19:38 <+bridge> [ddnet] while you redefine it if not defined 19:38 <+bridge> [ddnet] oh 19:38 <+bridge> [ddnet] while you define it if not defined 19:39 <+bridge> [ddnet] not being able to use z is the real bug 19:39 <+bridge> [ddnet] its c++ standard 19:39 <+bridge> [ddnet] link? 19:39 <+bridge> [ddnet] https://en.cppreference.com/w/cpp/io/c/fprintf 19:39 <+bridge> [ddnet] perhaps we need to include ? 19:39 <+bridge> [ddnet] for PRId64 19:39 <+bridge> [ddnet] https://en.cppreference.com/w/cpp/header/cinttypes 19:39 <+bridge> [ddnet] 19:39 <+bridge> [ddnet] already included 19:39 <+bridge> [ddnet] its simply bcs of microsofts stupid own c ansi 19:40 <+bridge> [ddnet] do we use %z or %zd? 19:40 <+bridge> [ddnet] @Chairn try `__mingw_printf` ignore the compile time warning that is unrelated 19:40 <+bridge> [ddnet] and see if it works 19:40 <+bridge> [ddnet] we use %zu 19:40 <+bridge> [ddnet] Well yeah, complain to Microsoft, they explicitly say `z` is not supported: https://learn.microsoft.com/en-us/previous-versions/tcxf1dw6(v=vs.140)?redirectedfrom=MSDN 19:40 <+bridge> [ddnet] zu 19:40 <+bridge> [ddnet] eh. yea, seems to belong to C++11 19:41 <+bridge> [ddnet] why does the microsoft compiler not conform 😦 19:41 <+bridge> [ddnet] legacy reasons xd 19:41 <+bridge> [ddnet] windows is bloat xd 19:41 <+bridge> [ddnet] does it print or format the string? we need format 19:41 <+bridge> [ddnet] guess there are mingw prefixed versions for that too 19:41 <+bridge> [ddnet] we can't use `__mingw_printf` anyway; it's certainly not available when compiling with msvc 19:42 <+bridge> [ddnet] msvc probably checks all types anyway 19:42 <+bridge> [ddnet] so aslong it doesnt crash who cares 19:42 <+bridge> [ddnet] all args* 19:42 <+bridge> [ddnet] and i got this with __mingw_printf `warning: format not a string literal, argument types not checked [-Wformat-nonliteral]` 19:42 <+bridge> [ddnet] wdym "check all args"? 19:42 <+bridge> [ddnet] ah yeah, nvm 19:43 <+bridge> [ddnet] i could imagine it checks if args are available, bcs they know that their anti standard thing causes too many problems 19:43 <+bridge> [ddnet] or: it wouldnt crash just not do the right thing 19:44 <+bridge> [ddnet] i just wonder why they dont fix it for c++ explicitly 19:46 <+bridge> [ddnet] anyway, just use PRId64 and cast to int64_t? 19:46 <+bridge> [ddnet] size_t is not required to be the same as int64_t 19:47 <+bridge> [ddnet] long long <=> long 19:47 <+bridge> [ddnet] it seems msvc can deal with a `size_t` argument to %zu 19:47 <+bridge> [ddnet] uint64_t * 19:47 <+bridge> [ddnet] according to my extensive™ godbolt experiments 19:47 <+bridge> [ddnet] did they fix it or what 19:47 <+bridge> [ddnet] ah 19:47 <+bridge> [ddnet] does it offer old msvc versions? 19:48 <+bridge> [ddnet] i wonder if thats new 19:48 <+bridge> [ddnet] also did u use std::printf (as in c++ version ^^) 19:49 <+bridge> [ddnet] no, I used `printf` 19:49 <+bridge> [ddnet] but I used C++ to compile 19:49 <+bridge> [ddnet] no 19:49 <+bridge> [ddnet] so we can fix it for mingw and call it a day? xd 19:49 <+bridge> [ddnet] yeah, might be cleaner 19:50 <+bridge> [ddnet] can mingw's libc deal with %zu? 19:50 <+bridge> [ddnet] if so, we could simply suppress the warning for mingw and call it a day 19:51 <+bridge> [ddnet] @Chairn did it output smth wrong? 19:51 <+bridge> [ddnet] you mean compiler or runtime? 19:51 <+bridge> [ddnet] runtime 19:51 <+bridge> [ddnet] what should i trigger to see that? 19:51 <+bridge> [ddnet] i dunno where we even still use it tbh 19:51 <+bridge> [ddnet] i saw so many commits removing my usages xD 19:52 <+bridge> [ddnet] "dbg_gfx 4" 19:52 <+bridge> [ddnet] ```cxx 19:52 <+bridge> [ddnet] #include 19:52 <+bridge> [ddnet] int main() { 19:52 <+bridge> [ddnet] printf("%d %d %d %d %d %d %d %d %zx\n", 0, 0, 0, 0, 0, 0, 0, 0, (size_t)0x123456789abcdef0); 19:52 <+bridge> [ddnet] } 19:52 <+bridge> [ddnet] ``` 19:52 <+bridge> [ddnet] try this 19:52 <+bridge> [ddnet] then u should see it 19:53 <+bridge> [ddnet] (I forgot the `return 0;`) 19:54 <+bridge> [ddnet] this fixes system.cpp 19:54 <+bridge> [ddnet] ```c++ 19:54 <+bridge> [ddnet] #ifdef __MINGW32__ 19:54 <+bridge> [ddnet] #undef PRId64 19:54 <+bridge> [ddnet] #define PRId64 "I64d" 19:54 <+bridge> [ddnet] #endif 19:54 <+bridge> [ddnet] ``` 19:55 <+bridge> [ddnet] wtf xd 19:55 <+bridge> [ddnet] all these weird workarounds 19:55 <+bridge> [ddnet] no warning, normal output 19:56 <+bridge> [ddnet] i could swear on wine it didnt work when i tested it once. but if win7 works, i guess its fine 19:56 <+bridge> [ddnet] wait what? something weird 19:57 <+bridge> [ddnet] sample file from heinrich throws no warning, but backend_vulkan does... 19:57 <+bridge> [ddnet] its bcs system.h enables a printf warning 19:57 <+bridge> [ddnet] but maybe gcc is not updated for this yet 19:57 <+bridge> [ddnet] on windows 19:58 <+bridge> [ddnet] I'd say we start ignoring the warning on mingw then? 19:59 <+bridge> [ddnet] that's what i usually do 🙂 20:00 <+bridge> [ddnet] no, I mean suppress the warning 20:00 <+bridge> [ddnet] so that mingw users don't see it 20:04 <+bridge> [ddnet] with a push macro? 20:05 <+bridge> [ddnet] with a `-Wno-warning-name` in CMakeLists.txt 20:05 <+bridge> [ddnet] https://discord.com/channels/252358080522747904/745926398140612678/799049884807987221 20:05 <+bridge> [ddnet] 20:05 <+bridge> [ddnet] here it still printed zu 20:05 <+bridge> [ddnet] around 2 years ago 20:05 <+bridge> [ddnet] or it was a different bug 20:06 <+bridge> [ddnet] hmmmmmm 20:06 <+bridge> [ddnet] weird 20:06 <+bridge> [ddnet] how do you dig up these messages? 66 20:06 <+bridge> [ddnet] how do you dig up these messages? && 20:06 <+bridge> [ddnet] how do you dig up these messages? ^^ 20:06 <+bridge> [ddnet] https://github.com/ddnet/ddnet/blame/c8363bc96fdb5e55b604618ba597a97e70dd40a9/src/engine/client/backend_sdl.cpp 20:06 <+bridge> [ddnet] it used %zu a while ago 20:07 <+bridge> [ddnet] i remember what i saw and try to find it xd 20:07 <+bridge> [ddnet] anyway if it works now then so be it 20:21 <+bridge> [ddnet] that‘s my technique too haha 20:25 <+bridge> [ddnet] looks like PRId64 or PRIu64 are redefined everywhere... 20:26 <+bridge> [ddnet] its overly complicated anyway 20:27 <+bridge> [ddnet] who cares for integer types lol 20:27 <+bridge> [ddnet] just print it 20:27 <+bridge> [ddnet] integer types ≤ 64 bit are represented the same way on 64 bit platforms 20:27 <+bridge> [ddnet] on 32 bit platforms, there's a difference between 32 and 64 bit integers 20:28 <+bridge> [ddnet] streaming is faster anyway than parsing the formats ^^ 20:28 <+bridge> [ddnet] the problem is that system.h is included first, defines its own version, and then it gets erased in following inclusion which includes cinttypes or inttypes.h 20:29 <+bridge> [ddnet] so why is it so 20:29 <+bridge> [ddnet] cant we remove this hack 20:30 <+bridge> [ddnet] there's no header guard in those files, so they can be included multiple times 20:30 <+bridge> [ddnet] any definition in system.h gets erased silently 20:30 <+bridge> [ddnet] system.h should include inttypes.h, probably 20:30 <+bridge> [ddnet] so it won't add this definition 20:30 <+bridge> [ddnet] or the hack could be removed completely, as jupstar says 20:44 <+bridge> [ddnet] @Chairn troll 20:45 <+bridge> [ddnet] at laest, no more warning 🤷‍♂️ 20:45 <+bridge> [ddnet] mute the warning if its wrong 20:46 <+bridge> [ddnet] that's not why warnings exist 20:46 <+bridge> [ddnet] if a warning is incorrect, it should be removed instead of worked-around 20:48 <+bridge> [ddnet] it is not incorrect in MinGW, it warns that the specifier will be printed directly and the remaining arguments are printed incorrectly 20:48 <+bridge> [ddnet] so the code is functionnally incorrect in these cases 20:49 <+bridge> [ddnet] what did we even talk about the last hour xD 20:49 <+bridge> [ddnet] that it works and the warning is incorrect 20:49 <+bridge> [ddnet] that might have been about %zu though 20:50 <+bridge> [ddnet] what is PRId64 defined as in mingw? 20:50 <+bridge> [ddnet] sorry if I asked before, let me scroll up 20:50 <+bridge> [ddnet] lld 20:50 <+bridge> [ddnet] and lld is not supported in mingw? 20:51 <+bridge> [ddnet] but he replaced the %zu 20:52 <+bridge> [ddnet] lld works fine 20:52 <+bridge> [ddnet] zu doesn't? 20:52 <+bridge> [ddnet] anyway, it's just 2 undefines and 2 defines 20:52 <+bridge> [ddnet] zu do'esnt 20:52 <+bridge> [ddnet] it prints zu 20:52 <+bridge> [ddnet] %zu is standard since c99, wtf? 20:53 <+bridge> [ddnet] it's documented as not supported 20:53 <+bridge> [ddnet] https://learn.microsoft.com/en-us/previous-versions/tcxf1dw6(v=vs.140)?redirectedfrom=MSDN 20:54 <+bridge> [ddnet] welcome to the party btw 😉 20:54 <+bridge> [ddnet] then we don't have to define PRId64 for mingw, no? 20:54 <+bridge> [ddnet] it still echoes a warning though 20:55 <+bridge> [ddnet] then this part is broken 20:55 <+bridge> [ddnet] but we shouldn't use %zu apparently 20:56 <+bridge> [ddnet] if it works it works 20:56 <+bridge> [ddnet] if msvc finally complies to standard, thats nice to have 20:57 <+bridge> [ddnet] you can add a check to https://github.com/ddnet/ddnet/blob/ac2246af4591f97ed728b6dadc3cc6c32911bc67/.github/workflows/style.yml to check for %zu 20:57 <+bridge> [ddnet] %zu doesn't work on mingw apparently 20:57 <+bridge> [ddnet] chairn said it does 20:57 <+bridge> [ddnet] so they probs fixed it 20:57 <+bridge> [ddnet] here he said it doesn't 20:57 <+bridge> [ddnet] I bet it's microshit's msvcrt that doesn't support it. Barely compliant bs 20:58 <+bridge> [ddnet] then try `__mingw_` functions 20:58 <+bridge> [ddnet] better than all these weird hacks 20:58 <+bridge> [ddnet] if i build master branch and try `./DDNet "dbg_gfx 4"`, it segfaults due to formatting 20:58 <+bridge> [ddnet] so it's a real problem 20:58 <+bridge> [ddnet] Imagine being a multi billion dollar company and not being able to support a format specifier 20:59 <+bridge> [ddnet] then finally try the mingw variants lol 21:03 <+bridge> [ddnet] crash with dbg_gfx 4 21:03 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/1056663472475230298/message.txt 21:03 <+bridge> [ddnet] which ones? they both crash 21:04 <+bridge> [ddnet] mingw64 and cygwin i think 21:04 <+bridge> [ddnet] weird af 21:04 <+bridge> [ddnet] msvc works, but ur not 21:04 <+bridge> [ddnet] win7 problems 21:04 <+bridge> [ddnet] good that win7 is dead 21:05 <+bridge> [ddnet] msys64 in fact 21:05 <+bridge> [ddnet] it crashes in C:\windows 21:05 <+bridge> [ddnet] mingw64 and cygwin (msys64 in fact) i think 21:05 <+bridge> [ddnet] because stack is corrupted due to wrong format specifier 21:05 <+bridge> [ddnet] but heinrich tested on gotbold 21:05 <+bridge> [ddnet] so just drop win7 😉 21:06 <+bridge> [ddnet] or it just reads too far 21:06 <+bridge> [ddnet] yeah sure, send me new pc 21:06 <+bridge> [ddnet] win10 works fine too 21:06 <+bridge> [ddnet] and linux probably too 21:06 <+bridge> [ddnet] also u a doctor, u can easily get highly paid job lol 21:06 <+bridge> [ddnet] what if i don't want? 21:07 <+bridge> [ddnet] im fine with teaching 21:07 <+bridge> [ddnet] You have to want it 21:07 <+bridge> [ddnet] exactly 21:07 <+bridge> [ddnet] https://tenor.com/bjXbu.gif 21:07 <+bridge> [ddnet] also i guess u arent teaching for free 21:07 <+bridge> [ddnet] yeah, but France doesn't pay well its teachers 21:07 <+bridge> [ddnet] barely 2k/month 21:08 <+bridge> [ddnet] anyway, why do the mingw variants even exists 21:09 <+bridge> [ddnet] https://sourceforge.net/p/mingw-w64/wiki2/gnu%20printf/ 21:09 <+bridge> [ddnet] only for xp stuff 21:09 <+bridge> [ddnet] rip 21:09 <+bridge> [ddnet] imagine a world where we wouldnt need to support windows 21:10 <+bridge> [ddnet] in that world u also would be a well paid teacher probably 21:15 <+bridge> [ddnet] how the hell can there be an error in a line i didn't touch... 21:15 <+bridge> [ddnet] https://github.com/ddnet/ddnet/actions/runs/3777226868/jobs/6420942984 21:16 <+bridge> [ddnet] sort the includes alphabetically 21:16 <+bridge> [ddnet] oh 21:17 <+bridge> [ddnet] hardest thing about our cmake setup xd 21:22 <+bridge> [ddnet] what exactly are the typedefs for int64_t and int64 on mingw? 21:22 <+bridge> [ddnet] are they different? 21:24 <+bridge> [ddnet] mhh but 21:24 <+bridge> [ddnet] https://en.cppreference.com/w/cpp/header/cinttypes 21:25 <+bridge> [ddnet] 21:25 <+bridge> [ddnet] uses the stdint types 21:25 <+bridge> [ddnet] long long 21:25 <+bridge> [ddnet] hard to believe that mingw defined them wrong xD 21:25 <+bridge> [ddnet] they don't 21:25 <+bridge> [ddnet] they use windows defines 21:25 <+bridge> [ddnet] so windows does it wrong 21:25 <+bridge> [ddnet] man this too confusing 21:27 <+bridge> [ddnet] mingw tries to use most of Microsoft header 21:27 <+bridge> [ddnet] what if u add __USE_MINGW_ANSI_STDIO before inttypes.h 21:27 <+bridge> [ddnet] tried it, no success 21:27 <+bridge> [ddnet] in cmake? 21:27 <+bridge> [ddnet] yup 21:27 <+bridge> [ddnet] ok 21:27 <+bridge> [ddnet] mhh 21:28 <+bridge> [ddnet] it is already defined somewhere 21:28 <+bridge> [ddnet] dunno where 21:28 <+bridge> [ddnet] we really need std::format like formatting 21:28 <+bridge> [ddnet] but i dont want to trigger c fanboys 21:29 <+bridge> [ddnet] or streamed 21:29 <+bridge> [ddnet] 21:29 <+bridge> [ddnet] `dbg_msg << "some text" << integer` 21:29 <+bridge> [ddnet] ez 21:30 <+bridge> [ddnet] okay, msys knows lld, but not zu 21:30 <+bridge> [ddnet] this is not very localizable, unfortunately 21:31 <+bridge> [ddnet] yep 21:31 <+bridge> [ddnet] for localizations std::format like 21:31 <+bridge> [ddnet] it is, but you can't change order of words in relation to data 21:31 <+bridge> [ddnet] in both case, you can't change order of data 21:32 <+bridge> [ddnet] you can, with printf and friends 21:32 <+bridge> [ddnet] you can change data with words, but not first %d with second %s for instance 21:32 <+bridge> [ddnet] data is what comes after the format string 21:32 <+bridge> [ddnet] so u fear that ppl might change it in the localization? 21:33 <+bridge> [ddnet] nah, ive never seen it happen 21:33 <+bridge> [ddnet] but it could 21:33 <+bridge> [ddnet] maybe there's some translation where it's reversed and nobody knows 😄 21:33 <+bridge> [ddnet] second %2$s with first %1$d 21:33 <+bridge> [ddnet] not unlikely 😄 21:33 <+bridge> [ddnet] $ symbol? 21:34 <+bridge> [ddnet] oh interesting 21:34 <+bridge> [ddnet] never seen it 21:34 <+bridge> [ddnet] oh lol 21:34 <+bridge> [ddnet] it's a POSIX extension and I made sure that we support it everywhere for translations 21:34 <+bridge> [ddnet] TIL 21:34 <+bridge> [ddnet] I can't find the tests anymore 21:35 <+bridge> [ddnet] do you think MSVC supports it? 21:35 <+bridge> [ddnet] if he wrote tests xd 21:36 <+bridge> [ddnet] I had to change the function I call for MSVC 21:36 <+bridge> [ddnet] now I can't find it anymore 21:36 <+bridge> [ddnet] either I dreamt it or someone changed it back, deleting the tests 21:36 <+bridge> [ddnet] not sure if the test were on DDNet, but they are on upstream 21:37 <+bridge> [ddnet] oh, I only did it in teeworlds? 21:37 <+bridge> [ddnet] no `$` in data/languages 21:37 <+bridge> [ddnet] https://github.com/teeworlds/teeworlds/blob/26d24ec061d44e6084b2d77a9b8a0a48e354eba6/src/test/str.cpp#L85-L104 21:39 <+bridge> [ddnet] time to cherry-pick 😄 23:42 <+bridge> [ddnet] what is the target to only compile and run c++ tests ? 23:43 <+bridge> [ddnet] `run_tests` 23:44 <+bridge> [ddnet] nah, it runs rust tests as well, and those takes age 23:45 <+bridge> [ddnet] We have `run_rust_tests` in the makefile but I don't see a way to only run the non-rust tests 23:45 <+bridge> [ddnet] `testrunner` builds it but doesn't run it, so i guess it's fine for now 23:45 <+bridge> [ddnet] I'll add a target for the C++ tests 23:46 <+bridge> [ddnet] thx 🙂 23:47 <+bridge> [ddnet] do the rust tests take ages to compile or ages to run? 23:49 <+bridge> [ddnet] @Chairn ^ 23:49 <+bridge> [ddnet] both? 23:49 <+bridge> [ddnet] Rust test take around 10 seconds to run, whereas the C++ testrunner takes 2.5 seconds 23:49 <+bridge> [ddnet] ^{@bencie could u ban 69? He's on Multieasy with the name cosmaisy
23:49 <+bridge> [ddnet] ^{U can check him out
23:49 <+bridge> [ddnet] @SuP wrong channel
23:49 <+bridge> [ddnet] ^{huh
23:49 <+bridge> [ddnet] ^{where do i ask
23:49 <+bridge> [ddnet] #reports
23:49 <+bridge> [ddnet] this channel is about development discussion
23:50 <+bridge> [ddnet] (because you likely only have to compile them once)
23:50 <+bridge> [ddnet] ```bash
23:50 <+bridge> [ddnet] $ time ninja run_rust_tests
23:50 <+bridge> [ddnet] real 0m20,192s
23:50 <+bridge> [ddnet] ```
23:50 <+bridge> [ddnet] which file should i touch to trigger compilation?
23:52 <+bridge> [ddnet] hmmm, not sure exactly
23:52 <+bridge> [ddnet] `src/rust-bridge/test/*.rs`
23:52 <+bridge> [ddnet] try `touch src/**/*.rs`
23:52 <+bridge> [ddnet] or that
23:53 <+bridge> [ddnet] ```bash
23:53 <+bridge> [ddnet] $ touch src/rust-bridge/test/*.rs
23:53 <+bridge> [ddnet] $ time ninja run_rust_tests
23:53 <+bridge> [ddnet] real 0m31,674s
23:53 <+bridge> [ddnet] ```
23:53 <+bridge> [ddnet] so 10 secs compilation and 20 secs runtime
23:53 <+bridge> [ddnet] yea, that's a lot
23:54 <+bridge> [ddnet] i7-4700MQ
23:54 <+bridge> [ddnet] i7-8705G for me
23:54 <+bridge> [ddnet] (and 2 seconds for running)
23:55 <+bridge> [ddnet] shouldn't run_tests also depends on run_rust_tests?
23:55 <+bridge> [ddnet] it does
23:55 <+bridge> [ddnet] check a few lines below
23:58 <+bridge> [ddnet] lel, it now runs c++ tests first then rust 😄
23:59 <+bridge> [ddnet] dammit, too slow to bors r+ 😢}}}}