04:48 < bridge> <louis> Is there some MAX_TEAM in network.py?
04:49 < bridge> <louis> Ddrace team vs vanilla team makes no sense.
05:10 < bridge> <totar> why?
05:11 < bridge> <totar> we support 0.6 protocol and ddnet extensions so it makes sense to have both
05:13 < bridge> <totar> also I think you can use cpp enums/defines from network.py
05:13 < bridge> <totar> or some of them
05:16 < bridge> <totar> maybe just the generated ones
05:33 < bridge> <louis> idk its just annoying to have both in the codebase i say drop everything non ddnet :giftee_green:
09:30 < bridge> <byfox> ```
09:30 < bridge> <byfox> byfox@byfox-x99e /m/h/c/C/ddnet-insta-fork (pr_refactor_text)> cat -A src/game/server/instagib/entities/text/text.h | head -5
09:30 < bridge> <byfox> M-oM-;M-?#ifndef GAME_SERVER_INSTAGIB_ENTITIES_TEXT_TEXT_H$
09:30 < bridge> <byfox> #define GAME_SERVER_INSTAGIB_ENTITIES_TEXT_TEXT_H$
09:30 < bridge> <byfox> ```
09:30 < bridge> <byfox> xd
09:39 < ws-client> **<ChillerDragon>** xd
09:39 < bridge> <Assa> gumo ^.^
09:41 < bridge> <byfox> I was trolled by special characters that aren't visible in Idea.
09:41 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1451494755455336530/HpZZzOT.png?ex=69466155&is=69450fd5&hm=f9b2cb860086e5e3f3143bcb2ffa96234c2b11abcf00d8de36bbe40bae6ae88f&
09:41 < bridge> <ryozuki> omg
09:51 < ws-client> **<ChillerDragon>** @learath2 i have new findings. My memory leak is not tied to turning ON massif, heaptrack or tcmalloc. It is about turning OFF asan. As soon as I run a server with asan it leaks memory hm.
09:52 < ws-client> **<ChillerDragon>** any idea what to do here? isn't ddnet also running some servers with asan? Could still be an issue i can fix in my code i assume. But i can not track allocations with asan can i?
09:57 < ws-client> **<ChillerDragon>** hm trying to heaptrack with asan gets stuck on shutdown
10:34 < ws-client> **<ChillerDragon>** how long does it take to register a vanilla teeworlds 0.7 server in the ddnet master?
10:35 < ws-client> **<ChillerDragon>** its online since like a minute and the log says its registered
10:35 < ws-client> **<ChillerDragon>** ah never mind its up
10:35 < ws-client> **<ChillerDragon>** i was just checking my favorites and my favorite was the 0.6 address
10:42 < bridge> <teero777> i just missclicked a 10min minesweeper game...
11:26 < bridge> <learath2> Uh, this is tough, now you need to start understanding how asan works
11:27 < bridge> <learath2> I can't quite imagine it behaving like that, but I am also not completely familiar with asan internals
11:28 < bridge> <0xdeen> no we're not. asan increases memory usage a lot, and I bet there is some memory being lost, if not directly leaked. We restart our servers once a day
11:30 < bridge> <Assa> At least I know a place where the server does UB
11:30 < bridge> <Assa> but I don't know what to do about this
11:38 < bridge> <Assa> ^ closed as duplicate before anyone wonders
13:22 < ws-client> **<ChillerDragon>** lets go new type checker dropped
13:23 < ws-client> **<ChillerDragon>** https://astral.sh/blog/ty
13:27 < bridge> <milkeeycat> I just wanted to write "it says it's extremely fast, is it written in rust at least", it is :pepeW:
13:28 < ws-client> **<ChillerDragon>** yeye 
13:28 < ws-client> **<ChillerDragon>** its the ruff and uv guys doin it
13:28 < ws-client> **<ChillerDragon>** can't wait for them dropping their own python runtime written in rust
13:29 < ws-client> **<ChillerDragon>** @heinrich5991 how does one run the new pyson integration tests? -.-
13:29 < ws-client> **<ChillerDragon>** `2025-12-19 13:27:32 I fifo: can't remove file 'build-san-headless/integration_start_server_azwla_76/server0.fifo'`
13:29 < ws-client> **<ChillerDragon>** `python3 scripts/integration_test.py --keep-tmpdirs build-san-headless/ start_server` this fails on my machine
13:30 < ws-client> **<ChillerDragon>** also can we hide the python trace and show log errors of the client and server instead?
13:37 < bridge> <kebscs> 💀
14:12 < bridge> <ryozuki> https://www.cloudflarestatus.com/
14:14 < ws-client> **<ChillerDragon>** holy shit i was about to bet my live savings on polymarket that cloudflare wasnt gonna outage until 2026
14:19 < bridge> <robyt3> ChillerDragon: running the integration test from the source folder should work (it does locally for me and in the CI). I was already working on showing stdout/err on integration test failures, I can push it later today.
14:36 < ws-client> **<ChillerDragon>** okay nice
14:37 < ws-client> **<ChillerDragon>** but yea idk how to run the new python tests at all
14:37 < ws-client> **<ChillerDragon>** it fails for me on all tests on master
16:53 < bridge> <APFFF> I just finished a map but didnt get any points. commands like /points also dont work. ddnet.org/status/ says the server is up tho
16:57 < bridge> <heinrich5991> sometimes it takes a day to propagate
16:58 < bridge> <APFFF> now I got the points but the map is still unfinished
16:59 < bridge> <heinrich5991> ^ ^^
16:59 < bridge> <APFFF> i thought if it updates, it updates all at once
17:02 < bridge> <heinrich5991> I think the point updating and the ranks are done in separate contexts
17:04 < bridge> <heinrich5991> chillerdragon: please stop telling people not to leave review comments
17:07 < ws-client> **<ChillerDragon>** @heinrich5991 why not?
17:07 < ws-client> **<ChillerDragon>** i think it was a destructive review comment
17:08 < bridge> <heinrich5991> because the job of the reviewer is to look at the broader context and understand it, also leave comments with respect to that
17:08 < ws-client> **<ChillerDragon>** okay sure
17:09 < ws-client> **<ChillerDragon>** but its also the job of the reviewer to not put additional load onto the contributor
17:09 < ws-client> **<ChillerDragon>** otherwise open prs are always work
17:09 < bridge> <heinrich5991> reviewing is more work than making a PR
17:09 < ws-client> **<ChillerDragon>** its not like there was a flaw in the pr
17:09 < ws-client> **<ChillerDragon>** it worked
17:09 < ws-client> **<ChillerDragon>** as is and it was an improvement
17:09 < bridge> <heinrich5991> yes, but it was incomplete
17:09 < ws-client> **<ChillerDragon>** it was complete for me
17:09 < bridge> <heinrich5991> just being an improvement is not enough for a PR to be merged
17:10 < ws-client> **<ChillerDragon>** i looked at one error message on one operating system
17:10 < bridge> <heinrich5991> but it has to be complete for ddnet, not the PR author
17:10 < ws-client> **<ChillerDragon>** could say that its still incomplete that there are still dbg_msgs in other files
17:10 < ws-client> **<ChillerDragon>** if the reviewer wants to widen the scope they can do that in a follow up pr
17:10 < bridge> <heinrich5991> I disagree
17:10 < ws-client> **<ChillerDragon>** i dont like checking out old branches because a reviewer had some idea
17:10 < bridge> <heinrich5991> the PR should stand on its own
17:11 < ws-client> **<ChillerDragon>** it did stand on its own
17:11 < bridge> <heinrich5991> then don't expect your PRs to be merged in all cases
17:11 < bridge> <heinrich5991> if you don't like updating your PRs
17:11 < bridge> <heinrich5991> that's nothing unique to ddnet
17:11 < ws-client> **<ChillerDragon>** updating prs is always bad
17:11 < ws-client> **<ChillerDragon>** it should be avoided if possible
17:11 < ws-client> **<ChillerDragon>** only if there are actual flaws
17:11 < bridge> <heinrich5991> show me an open-source project which handles it that way
17:12 < ws-client> **<ChillerDragon>** https://github.com/ddnet-insta/ddnet-insta/
17:13 < ws-client> **<ChillerDragon>** coming up with tasks for the contributor is what makes contributing to ddnet painful
17:13 < ws-client> **<ChillerDragon>** and it makes changes more risky
17:13 < ws-client> **<ChillerDragon>** it invalidates the contributors testing and previous reviews
17:13 < ws-client> **<ChillerDragon>** and increases the diff
17:14 < bridge> <heinrich5991> yes. sometimes the best change isn't the most minimal diff
17:14 < ws-client> **<ChillerDragon>** yes sometimes
17:14 < ws-client> **<ChillerDragon>** but not always
17:14 < bridge> <heinrich5991> okay
17:14 < ws-client> **<ChillerDragon>** i feel like i can't touch any piece of the code without getting bs about it being legacy code that i have to fix to get a merge
17:14 < bridge> <heinrich5991> if you want to discuss whether reviews are appropriate, please talk to the reviewer directly in the future
17:15 < ws-client> **<ChillerDragon>** i did talk to the reviewer directly
17:15 < bridge> <heinrich5991> instead of telling reviewers not to review your code
17:15 < ws-client> **<ChillerDragon>** or wdym
17:15 < bridge> <heinrich5991> DM
17:15 < ws-client> **<ChillerDragon>** why?
17:15 < ws-client> **<ChillerDragon>** i like things being in the open
17:15 < bridge> <heinrich5991> and I'm telling you to stop telling reviewers not to review
17:15 < bridge> <heinrich5991> in the future
17:15 < bridge> <heinrich5991> in the open
17:16 < ws-client> **<ChillerDragon>** its not about not reviewing
17:16 < bridge> <heinrich5991> the "followup PR" is a red herring btw
17:17 < bridge> <heinrich5991> everything can be done in a "followup PR"
17:17 < ws-client> **<ChillerDragon>** instead of writing a comment one a can do a pr
17:17 < ws-client> **<ChillerDragon>** that would be a much better flow imo
17:17 < bridge> <heinrich5991> it's just trying to absolve yourself of responsibility
17:17 < bridge> <heinrich5991> please just say "I won't do it" instead
17:17 < bridge> <heinrich5991> the other thing is deceiving IMO
17:17 < ws-client> **<ChillerDragon>** deceiving how?
17:17 < bridge> <heinrich5991> anything "can be done in a followup PR"
17:18 < bridge> <heinrich5991> it's not new information
17:18 < bridge> <heinrich5991> you just want to sugarcoat saying "I don't want to do it"
17:18 < ws-client> **<ChillerDragon>** yes i dont want to do it but sometimes i still do it and i think its bad
17:19 < ws-client> **<ChillerDragon>** its also a loophole in the dont merge your own code rule
17:20 < ws-client> **<ChillerDragon>** if the reviewer can send tasks to the contributor and still merge it. That means that the contributor has to work for the reviewer to get a merge and the reviewer can push their own ideas without second approval.
17:20 < bridge> <heinrich5991> I wouldn't exactly say so (since it's still the PR author looking over the changes), but if you want to open that discussion, we can
17:20 < ws-client> **<ChillerDragon>** That of course does not always apply but sometimes
17:20 < ws-client> **<ChillerDragon>** yes i was trying to talk to you about that since a few weeks xd
17:23 < ws-client> **<ChillerDragon>** @learath2 omaagwd vanilla teeworlds also memleaks with asan
17:23 < ws-client> **<ChillerDragon>** can u send pr to asan pls?
17:23 < ws-client> **<ChillerDragon>** xd
17:24 < ws-client> **<ChillerDragon>** so fakin annoying that i cant run servers with asan
17:24 < ws-client> **<ChillerDragon>** bruder was
17:24 < ws-client> **<ChillerDragon>** https://zillyhuhn.com/cs/.5b7cea1c-f7de-4bda-ad5d-d25fa5e1d035.png
17:27 < bridge> <robyt3> I also had some weird error like that in the Windows CI indicating a build target did not exist
17:28 < bridge> <Assa> in some IDEs on windows I need to compile against "testrunner" instead
17:29 < bridge> <robyt3> But testrunner is the executable. `run_tests` should just build testrunner and then run it.
17:36 < ws-client> **<ChillerDragon>** this was ubuntu fancy. I assumed that i messed something up during the merge.
17:36 < ws-client> **<ChillerDragon>** So can we blame this on github?
17:36 < ws-client> **<ChillerDragon>** this feels like it has to be a cmake issue on our side
17:40 < bridge> <Assa> @robyt3 can you add me as a second contact for the unique community, if you not have already done so? At least I can post in the admin chat of unique if there are concerns
17:45 < bridge> <robyt3> Open admin-mail 🙂 Though I suppose another community admin would have to confirm, or is this information on unique's website or servers?
17:49 < ws-client> **<ChillerDragon>** @heinrich5991 is it intentional that all errors of the integration tests seem to be timeout?
17:50 < ws-client> **<ChillerDragon>** i feel like it doesnt show if client or server crashed
17:51 < bridge> <robyt3> I think that's a bug with some systems. I was working on running the integration tests on Windows and macOS in the CI, but some failures to run are apparently not detected as abnormal exits.
17:53 < ws-client> **<ChillerDragon>** worked in the bash version :p 
17:53 < ws-client> **<ChillerDragon>** i find the python one so much harder to reason about
17:53 < ws-client> **<ChillerDragon>** like what the current working directory is and all the oop magic
17:55 < ws-client> **<ChillerDragon>** @robyt3 how is your python trace pr goin?
17:55 < bridge> <robyt3> The smoke test case is simply too large to debug. Not like we should remove it, but we should add multiple smaller tests cases checking individual behaviors.
17:55 < ws-client> **<ChillerDragon>** sounds good yes
17:56 < ws-client> **<ChillerDragon>** but i think more important for now is to improve the error output
17:56 < ws-client> **<ChillerDragon>** even the small tests failing can not be debugged by looking at the error message "timeout"
17:56 < ws-client> **<ChillerDragon>** WOAH
17:57 < bridge> <robyt3> As good as done, just need to fix the new style problems
17:57 < ws-client> **<ChillerDragon>** i rerun the ci of this one
17:57 < ws-client> **<ChillerDragon>** https://zillyhuhn.com/cs/.5b7cea1c-f7de-4bda-ad5d-d25fa5e1d035.png
17:57 < ws-client> **<ChillerDragon>** and second time i passed?????
17:57 < ws-client> **<ChillerDragon>** what can github do that a ninja error like this is shown and hidden again on a pipeline RERUN
17:57 < ws-client> **<ChillerDragon>** ?????????????????????????
17:57 < ws-client> **<ChillerDragon>** time to switch to codeberg xd
17:57 < ws-client> **<ChillerDragon>** @robyt3 epic im ready to review it
17:58 < ws-client> **<ChillerDragon>** is there a chance that our flaky integration tests can be blamed on github?
17:58 < bridge> <robyt3> GitHub CI seems increasingly vibe coded :monkaS:
17:58 < bridge> <robyt3> https://github.com/actions/runner/issues/3792
17:58 < ws-client> **<ChillerDragon>** ye ik the meme :D 
17:59 < ws-client> **<ChillerDragon>** and yet investors are pricing in 5 years of growth because of everyone being so much more productive with AI
18:01 < ws-client> **<ChillerDragon>** integration test keeps a bunch of dirs in my build folder even if i dont pass `--keep-tmpdirs` <:tee_thinking:478629518358085653>
18:01 < ws-client> **<ChillerDragon>** oh wait nice
18:01 < ws-client> **<ChillerDragon>** we got a `raise RuntimeError(f"unclean exit: {self.reason}")`
18:01 < ws-client> **<ChillerDragon>** its actually supported, poggies <:poggers2:1008007455936094328>
18:02 < bridge> <robyt3> It should only keep the folders if the test failed so you can debug it
18:03 < ws-client> **<ChillerDragon>** thanks for trying to fix the lint error but my linter didnt read the comment -.-
18:03 < ws-client> **<ChillerDragon>** https://zillyhuhn.com/cs/.2238b378-838b-403e-896d-12f7358a61d7.png
18:03 < ws-client> **<ChillerDragon>** @robyt3 ah i see thanks
18:08 < bridge> <Assa> thank you from informing me, that the website needs an update xD
18:10 < bridge> <learath2> Are you 100% certain this is leaking until it goes OOM? From everything I know about ASan my brain is shouting at me that this can't happen
18:11 < bridge> <0xdeen> Yeah, it's how asan works
18:11 < bridge> <learath2> Also I'd suggest not running asan in prod, it is quite performant compared to something like valgrind, but it still has very significant overhead
18:11 < bridge> <Assa> python actually has a limit (of 350 or something (:   )
18:12 < bridge> <0xdeen> What size did you set the quarantine_size to? That's at least how much freed objects will be kept around
18:12 < bridge> <learath2> Yes as in you also think it shouldn't just be growing in memory use forever?
18:12 < bridge> <learath2> Yeah the quarantine is the only thing I can think of that would grow, but it should peak, not keep growing in memory use
18:13 < bridge> <0xdeen> It might oom if you don't have enough memory in your system
18:13 < bridge> <Assa> I can't even tell who is the current contact, is is tezcan or timakro 🙈 is this some hidden internal document?
18:13 < bridge> <learath2> but it shouldn't just grow in memory use unboundedly unless you are something extremely weird 😄
18:14 < ws-client> **<ChillerDragon>** @learath2 asan in prod worked totally fine for me so far. There was no noticable performance impact and it caught quite a few programming woopsies.
18:14 < bridge> <robyt3> I think it was timarko, but heinrich did the contacting for the community tokens
18:14 < bridge> <Assa> yes, which I took over, or at least implemented for unique
18:15 < ws-client> **<ChillerDragon>** @learath2 my baseline consumption is 3GB and it used all 7GB available when running with asan until the server went into full denial of service
18:15 < ws-client> **<ChillerDragon>** i can set a quarantine_size uhm idk i just copied what the ddnet readme has
18:15 < bridge> <robyt3> > The AddressSanitizer runtime doesn't release memory back to the OS during execution so that the memory isn't all allocated up front. From the OS's point of view, it may look like there's a memory leak.
18:15 < bridge> <robyt3> https://learn.microsoft.com/en-us/cpp/sanitizers/asan-known-issues?view=msvc-170
18:16 < ws-client> **<ChillerDragon>** sadge
18:16 < bridge> <learath2> So very roughly the shadow memory is 1/8th of the entire address space, and when the OS does allocate those pages it'll never get returned
18:17 < ws-client> **<ChillerDragon>** so if i buy more ram i should reduce the risk of OOM?
18:17 < ws-client> **<ChillerDragon>** not just delay
18:17 < bridge> <learath2> but honestly, it should be consuming 1/8th of what you really use + some overhead for shitty alignment
18:17 < ws-client> **<ChillerDragon>** nah i cant afford more ram :/ 
18:17 < ws-client> **<ChillerDragon>** i just turn asan off i guess
18:17 < ws-client> **<ChillerDragon>** sad
18:18 < bridge> <learath2> did you try with just vanilla ddnet btw?
18:18 < ws-client> **<ChillerDragon>** i tried with ddnet++ and vanilla teeworlds today
18:19 < bridge> <learath2> You can try with a much smaller quarantine I guess
18:19 < ws-client> **<ChillerDragon>** ddnet++ is the biggest bloat crap there is but its still different than ddnet-insta and teeworlds master should be quite pure
18:21 < ws-client> **<ChillerDragon>** `ASAN_OPTIONS=quarantine_size_mb=500` something like this?
18:22 < bridge> <robyt3> The default seems to be 256 only
18:22 < ws-client> **<ChillerDragon>** but default of quarantine_size is -1 xd
18:22 < ws-client> **<ChillerDragon>** that looks like infinite
18:22 < ws-client> **<ChillerDragon>** so i try 100 instead?
18:22 < bridge> <robyt3> https://github.com/google/sanitizers/wiki/addresssanitizerflags
18:22 < ws-client> **<ChillerDragon>** yea lemme try 100
18:22 < ws-client> **<ChillerDragon>** ye im browsing that page rn
18:23 < bridge> <robyt3> quarantine_size is deprecated
18:23 < ws-client> **<ChillerDragon>** ye
18:28 < bridge> <aegisub> "updating prs is always bad" what lol
18:28 < ws-client> **<ChillerDragon>** yes
18:28 < ws-client> **<ChillerDragon>** every change is a risk and annoyance
18:29 < ws-client> **<ChillerDragon>** previous tests and reviews are invalidated
19:08 < bridge> <aegisub> erm
19:08 < bridge> <aegisub> "every change is a risk and annoyance"
19:08 < bridge> <aegisub> well yeah I agree but surely that then includes the initial pull request too right?
19:08 < bridge> <aegisub> so if you're gonna make a change you best make sure it's a good one
20:43 < ws-client> **<ChillerDragon>** nah initial pr is different
20:43 < ws-client> **<ChillerDragon>** the author chose to do what he wanted and when he wanted it
20:43 < ws-client> **<ChillerDragon>** reacting to reviews can come with inconvienient timing and demands the contributor does not agree with
20:44 < ws-client> **<ChillerDragon>** how am i the one being quoted after heinrich dropped "just being an improvement is not enough for a PR to be merged"
21:21 < ChillerDragon> woah that is a long name xd
21:21 < ChillerDragon> ⸻⸻⸻⸻⸻
21:21 < bridge> <alw5> MMMMMMMMMMMMMMM is the longest in length i think
21:22 < bridge> <alw5> since capital M takes up the most space ?
21:22 < ChillerDragon> oh true thats also long
21:22 < ChillerDragon> idk i smh thought this line is longer
21:30 < bridge> <aegisub> initial pr is *exactly the same* except that the responsibilities are flipped
21:31 < bridge> <aegisub> the maintainer chose to do what he wanted and when he wanted it
21:31 < bridge> <aegisub> reacting to pull requests can come with inconvenient timing and demands the maintainer does not agree with
21:33 < bridge> <aegisub> I'm being a bit facetious but what I'm getting at is that if you as a pr author have experienced cases where reviewers asked for changes you don't agree with, you also need to understand that there can be changes that you may pr that a maintainer may not agree with
21:34 < bridge> <aegisub> you can certainly choose definition such that "just being an improvement is not enough for a PR to be merged" comes out as wrong but I do agree with that statement
21:35 < bridge> <aegisub> the point being that "improvement" is hard to qualify because there is never only one axis
21:35 < bridge> <aegisub> an extremely common example is pull requests that fix a problem in one instance when it actually occurs in multiple other instances as well
21:36 < bridge> <aegisub> those may be a strict improvement in the sense that the outside visible behavior works in strictly more cases but the resulting code may be less consistent and hence less maintainable
21:36 < bridge> <aegisub> so it may make sense to require that a pr fixing that problem in one instance fixes it in all instances
21:36 < bridge> <aegisub> </blog>
22:47 < ws-client> **<ChillerDragon>** yes i agree with that actually
22:48 < ws-client> **<ChillerDragon>** but the logger situation already is inconsistent
22:48 < ws-client> **<ChillerDragon>** any diff to update it to new system is good, i like to work in silos looking at the code that i am currently working with
22:48 < ws-client> **<ChillerDragon>** the windows code doesnt even run on my system
22:52 < bridge> <chillerdragon> The bigger the pr the slower the merge and the bigger the conflicts to be maintained
22:52 < bridge> <chillerdragon> Replacing all calls to dbg\_msg is just so much harder to actually get merged
22:53 < bridge> <chillerdragon> He didn’t ask for that but still asked for more
22:53 < bridge> <chillerdragon> I don’t think the amount is obvious here
23:34 < bridge> <robyt3> I think with cleanup like replacing `dbg_msg` calls, commits should change entire files/classes/features. This initially made it inconsistent within `fifo.cpp` and `CFifo`.