00:01 < bridge_> <heinrich5991> the 4€ might be on top of what Learath2 sponsors
00:47 < bridge_> <deen> No, Learath2 just didn't tell me up-to-date costs yet, that was for a small VPS for 1 month
00:47 < bridge_> <deen> but now we have larger and for longer
05:11 < bridge_> <cyberFighter> @ryozuki whats team -1
05:23 < bridge_> <Ewan> im not ryo so idk if i'm not picking up on some injoke but team -1 is not real
05:23 < bridge_> <Ewan> it underflows
05:23 < bridge_> <Ewan> it underflows in the command
05:23 < bridge_> <Ewan> and in practice a team below 0 cannot exist
05:24 < bridge_> <cyberFighter> i saw team -1 in ddstats
05:30 < bridge_> <Ewan> the game handles teams internally with an array
05:30 < bridge_> <Ewan> which can't have negative indices
05:30 < bridge_> <Ewan> inherently
05:30 < bridge_> <Ewan> it might be placeholder or some dumb shit
06:10 < bridge_> <Iza> It’s spectator mode
09:19 < bridge_> <headshotnoby> https://github.com/headshot2017/ddnet-nds
09:20 < bridge_> <headshotnoby> http://github.com/headshot2017/ddnet-nds
09:23 < ws-client> <Jupstar> nice xd what opengl does a NDS even support?
09:26 < bridge_> <Ewan> nintendo ds? none
09:27 < bridge_> <Ewan> this looks like only chat lol
09:30 < ws-client> <Jupstar> with 3ds it could actually work with graphics
09:30 < ws-client> <Jupstar> i guess
09:31 < bridge_> <headshotnoby> none, this is a console only program
09:32 < bridge_> <headshotnoby> the NDS has 2D and 3D hardware, but the latter is nothing like opengl
09:33 < bridge_> <headshotnoby> even though libnds offers an opengl-like syntax for the 3D hardware
09:33 < bridge_> <headshotnoby> none, this is a console-only program
09:33 < ws-client> <Jupstar> NDS was really smth special :D
09:33 < bridge_> <headshotnoby> https://cdn.discordapp.com/attachments/342454474117218334/1131472202106142771/20230720_022109.mp4 a video of it in action
09:34 < ws-client> <Jupstar> cool :D
09:34 < ws-client> <Jupstar> WiFi controller
09:35 < bridge_> <headshotnoby> dswifi 0.4.2
09:45 < bridge_> <Ewan> can we get prediction on bullets/doors/grabbers/freeze things/blaster dudes
09:46 < bridge_> <Ewan> some things maybe hard but like, bullets and doors? how hard could that be?
09:46 < bridge_> <Ewan> i can be seen as inside a bullet but i brush way behind the back of where a bullet just was and i freeze
09:46 < bridge_> <Ewan> it's annoyinh
09:48 < ws-client> <Jupstar> go ahead
09:48 < ws-client> <Jupstar> xd
09:50 < bridge_> <Ewan> im too cave man to do it
09:51 < bridge_> <Ewan> i just complain and hit rock with stixk
09:51 < bridge_> <Ewan> i just complain and hit rock with stick
10:23 < bridge_> <ryozuki> i guess spectator ye, i dont change any data, i just show what master  reports
10:23 < bridge_> <ryozuki> altho i filter (connecting)
10:23 < bridge_> <ryozuki> cuz they are annoying
10:35 < bridge_> <ryozuki> source: <https://github.com/edg-l/ddstats>
10:35 < bridge_> <ryozuki> i didnt really need a backend yet so its just frontend xd
10:35 < bridge_> <ryozuki> AGPL-3 ofc
10:43 < ws-client> <Jupstar> was about to steal it, good that u choose AGPL
10:43 < bridge_> <ryozuki> u can steal it
10:43 < bridge_> <ryozuki> provided u provide the source when u distribute the stolen code
10:43 < bridge_> <ryozuki> isnt it great
10:44 < bridge_> <ryozuki> it allows others to steal from ur steal
10:44 < bridge_> <ryozuki> its epic
10:44 < ws-client> <Jupstar> 0% rust
10:44 < ws-client> <Jupstar> not worth to steal
10:44 < bridge_> <ryozuki> i know :Sadge:
10:44 < bridge_> <ryozuki> but i havent needed  a backend yet
10:44 < bridge_> <ryozuki> as i said xD
10:44 < bridge_> <ryozuki> the web itself queries the master and processes everything on the client
10:45 < bridge_> <ryozuki> unless it does SSR
10:49 < bridge_> <robyt3> ChillerDragon: How to debug the integration test when I just get this output:
10:49 < bridge_> <robyt3> ```
10:49 < bridge_> <robyt3> [*] launch server
10:49 < bridge_> <robyt3> [*] launch client 1
10:49 < bridge_> <robyt3> Terminated
10:49 < bridge_> <robyt3> Terminated
10:49 < bridge_> <robyt3> [*] shutting down server
10:49 < bridge_> <robyt3> [*] shutting down client1
10:49 < bridge_> <robyt3> [*] shutting down client2
10:49 < bridge_> <robyt3> Error: Process completed with exit code 143.
10:49 < bridge_> <robyt3> ```
10:49 < bridge_> <robyt3> Already made some more changes so valgrind/san log files are also printed to the CI, but it seems like the script terminates even sooner.
10:49 < bridge_> <robyt3> Currently trying to get this branch to work: https://github.com/Robyt3/ddnet/tree/Graphics-Buffer-Refactoring
10:50 < bridge_> <robyt3> @jupeyy_keks Somehow integration test with valgrind fails without a useful error message after adding more assertions for graphics buffer allocation, so maybe we actually found some bug.
10:51 < ws-client> <Jupstar> @robyt3 can u indicate where then i can take a look
10:52 < ws-client> <Jupstar> or what command
10:52 < ws-client> <Jupstar> with graphics buffer you mean the command buffer?
10:52 < bridge_> <robyt3> Seems like launching the first client with valgrind should already fails, but then it should call the fail() function in the script to print results anyway
10:53 < bridge_> <robyt3> Yeah, I mean the command buffer. What the commit does: "When memory for a command or data in the command buffer cannot be allocated in `CGraphics_Threaded::AddCmd` and `CGraphics_Threaded::AllocCommandBufferData` the command buffer is cleared so it should always be possible to allocated memory successfully on the second try. Therefore assertions are added and the return values and inconsistent checks of the functions are removed."
10:55 < ws-client> <Jupstar> sounds reasonable
10:55 < ws-client> <Jupstar> and where does it assert in your tests?
10:55 < bridge_> <robyt3> I wish I knew that
10:56 < bridge_> <robyt3> For some reason the log doesn't say more
10:56 < bridge_> <robyt3> It should print the contents of a bunch of files, but it just says "Terminated"
10:57 < ws-client> <Jupstar> doesnt our dbg_assert print smth to stdout first?
10:59 < ws-client> <Jupstar> yeah weird, can't you run valgrind in your VM? is probably easier than using CI for that
10:59 < bridge_> <robyt3> We redirect stdout/stderr to files. Maybe somethings goes wrong between between redirecting and printing, I'll try to just patch that out
10:59 < bridge_> <robyt3> We redirect stdout/stderr to files. Maybe somethings goes wrong between redirecting and printing, I'll try to just patch that out
11:08 < bridge_> <ryozuki> @heinrich5991 https://ddstats.org/
11:08 < bridge_> <ryozuki> i think colors are better now
11:21 < bridge_> <heinrich5991> yes, defintely better now 🙂
11:21 < bridge_> <heinrich5991> why pagination though :p
11:22 < bridge_> <robyt3> @jupeyy_keks Locally it also crashes but there is only one valgrind warning in the client log: `==7110== Warning: set address range perms: large range [0x59c87040, 0x159c8703f) (undefined)`
11:22 < bridge_> <robyt3> Logs in the CI also has this warning before the termination
11:24 < ws-client> <Jupstar> @robyt3 what i dont get is tho: the stuff that uses command buffers are single threaded and probably not related to SDL2 events, why should it only crash under valgrind :D
11:27 < bridge_> <heinrich5991> @ryozuki nit: the unit for kilobytes is "KB" or "KiB", not "kb"
11:27 < bridge_> <heinrich5991> @ryozuki nit: the unit for kilobytes is "kB", "KB" or "KiB", not "kb"
11:27 < bridge_> <ryozuki> i see xd
11:27 < bridge_> <ryozuki> ill edit later
11:28 < bridge_> <ryozuki> perfomance on mobile
11:28 < bridge_> <ryozuki> i also plan on adding filters
11:28 < ws-client> <Jupstar> add virtual table
11:28 < ws-client> <Jupstar> then u dont need pages
11:28 < bridge_> <robyt3> I don't understand why valgrind terminates, it's only a warning and there is no warning-as-errors for valgrind as far as I can tell
11:29 < ws-client> <Jupstar> how do we run valgrind?
11:29 < bridge_> <ryozuki> good idea virtual tables
11:29 < bridge_> <robyt3> `valgrind --tool=memcheck --gen-suppressions=all --suppressions=../memcheck.supp --track-origins=yes`
11:30 < ws-client> <Jupstar> mh my valgrind script at home looks different, but can't tell rn. But yeah should not just crash, u can make valgrind write to a file
11:31 < bridge_> <heinrich5991> someone that's not me disabling clippy lints: https://chromium.googlesource.com/chromiumos/platform/crosvm/+/ed7d455a4364671d8dfaf2d3e65d25128861f650/.cargo/config.toml
11:31 < ws-client> <Jupstar> lmao searching valgrind on discord is not very successful xD all prs include that word
11:32 < bridge_> <ryozuki> looks like they use smth else?
11:33 < bridge_> <ryozuki> whats tools/clippy
11:33 < bridge_> <Jupstar ✪> @robyt3
11:33 < bridge_> <ryozuki> ah u meant lints
11:34 < bridge_> <ryozuki> not clippy itself xd
11:34 < bridge_> <heinrich5991> you don't need to disable clippy, you could just not rnu it ^^
11:34 < bridge_> <heinrich5991> if you don't like it at all
11:34 < bridge_> <heinrich5991> (many of the suggestions on Jupstar's repo were good, not sure if I said that already)
11:35 < bridge_> <ryozuki> wondering about useless transmute
11:35 < ws-client> <Jupstar> which ones @heinrich5991 i found them rather useless
11:36 < ws-client> <Jupstar> well the unwrap_or_else and string stuff maybe
11:36 < bridge_> <heinrich5991> https://github.com/rust-lang/rust-clippy/issues/5343
11:36 < ws-client> <Jupstar> for bit more perf xd
11:36 < bridge_> <heinrich5991> perhaps due to these false-positives @ryozuki
11:37 < bridge_> <ryozuki> i mean a lint is useless if u dont give it value i guess
11:37 < ws-client> <Jupstar> but matches! is defs smth i would not use for a single matche
11:37 < ws-client> <Jupstar> match
11:37 < ws-client> <Jupstar> that looks so ugly xD
11:38 < bridge_> <ryozuki> yeah i guess, works better gor nested matches
11:38 < bridge_> <ryozuki> for
11:38 < bridge_> <heinrich5991> link to the PR again?
11:38 < ws-client> <Jupstar> https://github.com/ddnet/discord-skin-upload-bot/pull/1/files
11:38 < bridge_> <ryozuki> unwrap or else is defs a perf improvement
11:39 < ws-client> <Jupstar> depends
11:39 < ws-client> <Jupstar> if the compiler is too stupid to see it yes
11:39 < ws-client> <Jupstar> i'd mainly use it when the or path is a panic
11:41 < bridge_> <heinrich5991> yes, that one is okay. taking `&str` instead of `&String` is also good. using `'\n'` instead of `"\n"` is also good in `replace`. I personally like `for _ in container.iter()` → `for _ in &container`. removing `clone()` is good
11:41 < bridge_> <heinrich5991> for the rest, leaving it as-is would be fine for me
11:42 < bridge_> <ryozuki> and the const fn
11:42 < ws-client> <Jupstar> i mean most can't hurt so idc
11:43 < ws-client> <Jupstar> but stuff like if let ... vs .is_some  or simiar are always annoying
11:43 < bridge_> <ryozuki> @heinrich5991 u dont agree with using fromstr trait?
11:43 < bridge_> <heinrich5991> not needed for private code, for public code it adds API guarantees so shouldn't be warned about
11:43 < bridge_> <heinrich5991> (the `const fn`)
11:43 < bridge_> <heinrich5991> where do I see that?
11:43 < bridge_> <ryozuki> the same pr
11:43 < bridge_> <ryozuki> he impl to string without the trait
11:44 < ws-client> <Jupstar> impl ToString for SkinToUploadDB {
11:44 < ws-client> <Jupstar> this?
11:44 < bridge_> <ryozuki> y
11:44 < ws-client> <Jupstar> yeah clever that it saw it
11:44 < ws-client> <Jupstar> if this is always good dunno
11:44 < bridge_> <ryozuki> also i always impl copy for enums
11:44 < bridge_> <ryozuki> and whenever i can rlt
11:44 < bridge_> <ryozuki> rly
11:44 < bridge_> <heinrich5991> you said fromstr 😄
11:44 < bridge_> <heinrich5991> couldn't find it
11:44 < bridge_> <ryozuki> ye my bad
11:44 < bridge_> <ryozuki> xd
11:44 < bridge_> <heinrich5991> implementing `ToString` is always wrong, no?
11:44 < bridge_> <heinrich5991> you should implement `Display` instead
11:45 < ws-client> <Jupstar> @ryozuki for such stuff its indeed nice to have a tool. bcs that's pure tryhard to me :D
11:45 < bridge_> <ryozuki> hmm idk actually
11:45 < bridge_> <heinrich5991> then you can also use it in format strings
11:45 < bridge_> <heinrich5991> and you get `ToString` for free
11:45 < bridge_> <ryozuki> true
11:45 < ws-client> <Jupstar> @ryozuki when fix pr
11:45 < bridge_> <ryozuki> the lint just said tostring tho
11:45 < bridge_> <ryozuki> i didnt think about display
11:45 < bridge_> <ryozuki> i rarely impl it xd
11:46 < bridge_> <heinrich5991> I've never implemented `ToString`, but often `Display`
11:46 < bridge_> <Ewan> hi guys
11:46 < bridge_> <Ewan> what talk about
11:46 < bridge_> <heinrich5991> https://doc.rust-lang.org/std/string/trait.ToString.html
11:46 < bridge_> <heinrich5991> > This trait is automatically implemented for any type which implements the Display trait. As such, ToString shouldn’t be implemented directly: Display should be implemented instead, and you get the ToString implementation for free.
11:46 < bridge_> <ryozuki> ye makes sense
11:47 < ws-client> <Jupstar> @heinrich5991 bug report to clippy
11:47 < ws-client> <Jupstar> xd
11:47 < bridge_> <ryozuki> ill keep in mind
11:47 < ws-client> <Jupstar> @ryozuki do u run clippy at save?
11:48 < ws-client> <Jupstar> i really would need it to be conviced by it. i hate when i have to run external tools by hand
11:48 < ws-client> <Jupstar> just to find mostly useless fixes
11:49 < bridge_> <ryozuki> i changed vscode to use clippy ye
11:49 < bridge_> <ryozuki> its a settings
11:49 < ws-client> <Jupstar> ok nice
11:49 < bridge_> <ryozuki> just change check to clippy
11:49 < ws-client> <Jupstar> should try it soon:tm:
11:50 < bridge_> <ryozuki> but default clippy doesnt enable all lints btw
11:50 < ws-client> <Jupstar> when i am finally motivated to fix unused warnings xD
11:50 < ws-client> <Jupstar> i use urs except the documentation one as test
11:50 < ws-client> <Jupstar> and disable the ones i dislike
11:50 < bridge_> <ryozuki> nice
11:50 < bridge_> <heinrich5991> because some have false-positives ^^
11:50 < bridge_> <ryozuki> i disable type complexity and too many args
11:51 < bridge_> <ryozuki> rust types just tend to be complex often xd
11:51 < bridge_> <Ewan> ryo vscoder?
11:51 < ws-client> <Jupstar> when he is alone and nobody watches he uses vscode
11:51 < bridge_> <Ewan> yea
11:51 < bridge_> <Ewan> but the internet sees emacs
11:52 < bridge_> <ryozuki> u got me
11:52 < bridge_> <ryozuki> nah but i use vim sometimes
11:52 < bridge_> <Ewan> im guipilled
11:53 < bridge_> <ryozuki> windowspilled
11:53 < bridge_> <Jupstar ✪> In 20 years I switch to lapce
11:53 < bridge_> <Jupstar ✪> When it's finally stable
11:53 < bridge_> <ryozuki> xd
11:53 < bridge_> <Jupstar ✪> Same with Wayland xdd
11:53 < bridge_> <ryozuki> honestly vscode is rlt good
11:53 < bridge_> <ryozuki> there werent that good editors before
11:53 < bridge_> <ryozuki> atom was a ram hog
11:54 < bridge_> <Ewan> yea nothing universal at least
11:54 < bridge_> <ryozuki> LSP was a game changer
11:54 < bridge_> <Jupstar ✪> Lapce is blazingly fast and that convinces me. But it has no debugger support and I'm no terminal tryharder
11:54 < bridge_> <Ewan> whenever someone in this chat says blazingly fast i take it with extra salt
11:55 < bridge_> <ryozuki> it rly is fast
11:56 < bridge_> <ryozuki> lapce is like vscode but no ks
11:56 < bridge_> <ryozuki> js
11:56 < bridge_> <ryozuki> its all rust
11:56 < ws-client> <Jupstar> yeah and from what i read they embedd plugins as wasm modules into the editor
11:56 < bridge_> <ryozuki> just compsre startup time
11:56 < ws-client> <Jupstar> so they can maybe make the API a bit slimmer
11:57 < bridge_> <ryozuki> the ui needs improvement tho
11:57 < ws-client> <Jupstar> they apparently changed the editor recently
11:57 < ws-client> <Jupstar> to their own
11:57 < bridge_> <Ewan> never heard of lapce
11:57 < bridge_> <Ewan> is it some undoubtedly epic rust thing
11:58 < ws-client> <Jupstar> when i tested it a month ago, what surprised me how fast it could determine the phantom code (e.g. type definitions `: i32`) compared to vscode
11:58 < ws-client> <Jupstar> was basically instant while writing
11:58 < bridge_> <Ewan> what is it
11:58 < ws-client> <Jupstar> https://github.com/lapce/lapce
11:58 < ws-client> <Jupstar> its vscode in rust
12:00 < bridge_> <Ewan> oh awesome
12:00 < bridge_> <robyt3> Even that didn't give any more information before the crash :/ The last line in the log is most likely unrelated warning
12:00 < bridge_> <Ewan> custom ui >_>
12:00 < bridge_> <Ewan> druid needs adoption if it's gonna be any good... maybe this predates it tho
12:01 < bridge_> <Jupstar ✪> Wow. Did u find some valgrind bug lmao
12:01 < bridge_> <Jupstar ✪> It sounds like their VM is crashing
12:03 < bridge_> <Ewan> pretty neat. certainly looks really.... something... at high DPI
12:03 < bridge_> <Ewan> https://cdn.discordapp.com/attachments/293493549758939136/1131526761147015208/image.png
12:03 < bridge_> <Ewan> and the custom window is a big red flag
12:03 < bridge_> <Ewan> use a native window & request custom decorations
12:03 < ws-client> <Jupstar> windows problems
12:03 < bridge_> <Ewan> how
12:03 < ws-client> <Jupstar> bcs for me it works
12:04 < ws-client> <Jupstar> xd
12:04 < bridge_> <Ewan> that's using your brain right there
12:04 < ws-client> <Jupstar> also nobody said that thing is stable lmao
12:05 < bridge_> <ryozuki> ye it needs lot of work
12:05 < bridge_> <Ewan> yea sure
12:06 < bridge_> <Ewan> i wanna use this when it's awesome
12:08 < bridge_> <Ewan> this is it w/o custom title bar
12:08 < bridge_> <Ewan> https://cdn.discordapp.com/attachments/293493549758939136/1131528085733392415/image.png
12:08 < bridge_> <Ewan> i hope they know they can do better than that
12:09 < ws-client> <Jupstar> i hope you join their dev team, that gives me an even better editor ;)
12:09 < bridge_> <Ewan> i wish but idk about the rusts
12:09 < ws-client> <Jupstar> its ez af, starting is the hardest
12:10 < bridge_> <heinrich5991> @ryozuki did you know most distributions of vscode aren't open-source?
12:10 < bridge_> <ryozuki> ye
12:10 < bridge_> <heinrich5991> the arch linux distribution is though
12:10 < bridge_> <ryozuki> i know about vscodium
12:11 < bridge_> <heinrich5991> are you using a closed-source variant? :p
12:11 < bridge_> <ryozuki> sadly im using the original ye
12:11 < ws-client> <Jupstar> i'm using codium
12:11 < bridge_> <ryozuki> i used to have problems woth the extension market thing
12:11 < bridge_> <ryozuki> and i forgot to change back
12:11 < ws-client> <Jupstar> to me a bigger problem is that extensions are not sandboxed
12:11 < bridge_> <heinrich5991> I don't like that people are using proprietrary editors again
12:12 < bridge_> <Ewan> does the acc system work on vscodium? i also remember hearing it was several versions behind
12:12 < ws-client> <Jupstar> why do i want to log into my IDE xd
12:12 < bridge_> <Ewan> sync settings
12:12 < bridge_> <Ewan> it's awesome for my laptop
12:12 < ws-client> <Jupstar> mh ok, i try to not change any settings and instead use workspaces per project
12:13 < bridge_> <Ewan> wild
12:13 < ws-client> <Jupstar> u should try ddnet's vscode workspace xd i never tried it under windows
12:13 < ws-client> <Jupstar> i wonder if it even works
12:13 < bridge_> <Ewan> yeah workspaces are kind of a joke
12:13 < bridge_> <Ewan> i am using real vscodes
12:13 < bridge_> <Ewan> smells like zaza at 4:13 am
12:13 < bridge_> <Ewan> neighbors
12:14 < ws-client> <Jupstar> https://github.com/ddnet/ddnet/blob/master/other/vscode/README.md
12:14 < ws-client> <Jupstar> the requirement list is long xD
12:14 < ws-client> <Jupstar> the workspace directly gives u targets to build with ASAN etc.
12:15 < ws-client> <Jupstar> so it's actually quite nice
12:15 < bridge_> <Ewan> neat. i never use vscode for the cpp
12:15 < bridge_> <Ewan> it doesn't work with my toolchain. i might be able to make it work but qt creator does it so well that i would never want to
12:15 < ws-client> <Jupstar> do what suits you best ;)
12:16 < bridge_> <robyt3> Valgrind segfaults so hard that vgdb can't catch it dying :feelsbadman:
12:16 < bridge_> <Ewan> lol
12:16 < bridge_> <Ewan> ouch
12:17 < ws-client> <Jupstar> looks for bug haunts before reporting xdd maybe redhat has some open
12:17 < ws-client> <Jupstar> look*
12:17 < bridge_> <heinrich5991> haunts?
12:18 < ws-client> <Jupstar> bounties
12:18 < bridge_> <Ewan> hunt
12:19 < bridge_> <Ewan> like the mediocre ketchup
12:23 < bridge_> <chillerdragon> Yeah debugging integration tests is a big pain. I can not give you any nice trix from ma phone. I barley even remember how the whole thing works. If you still haven’t figured it out when I get home I can have a look \:)
12:23 < bridge_> <chillerdragon> (@robyt3)
12:23 < bridge_> <chillerdragon> Is it in the CI only?
12:24 < bridge_> <robyt3> Also crashes in my Ubuntu VM
12:24 < bridge_> <robyt3> But only with Valgrind
12:26 < bridge_> <heinrich5991> @robyt3 after which changes?
12:27 < bridge_> <robyt3> I assume it was https://github.com/ddnet/ddnet/commit/c79fe027528510a7e62cf282af5571fb3a2aace9 from https://github.com/Robyt3/ddnet/tree/Graphics-Buffer-Refactoring
12:28 < bridge_> <heinrich5991> have you tried that the previous commit works?
12:29 < bridge_> <robyt3> No, but good idea, the CI is running to test if it's exactly this commit: https://github.com/Robyt3/ddnet/tree/Graphics-Buffer-Refactoring-2
12:36 < ws-client> <Jupstar> https://github.com/Robyt3/ddnet/commit/e23408f0ea8be8db841f5124a5d9895a67bf7192 very good commit
12:36 < ws-client> <Jupstar> i remember drama with heinrich xDD
12:37 < bridge_> <marmare_314> @robyt3 do you have any suggestions on how to remove the code duplication of the smooth zooming code from https://github.com/ddnet/ddnet/pull/6885.? Making it its own class does not really work since some functions (`ZoomMouseTarget`)  are quite different and need a lot of members of `CEditor`
12:37 < bridge_> <marmare_314> @robyt3 do you have any suggestions on how to remove the code duplication of the smooth zooming code from https://github.com/ddnet/ddnet/pull/6885 ? Making it its own class does not really work since some functions (`ZoomMouseTarget`)  are quite different and need a lot of members of `CEditor`
12:37 < bridge_> <heinrich5991> is `size_t` the right type for the width of a texture? why is it a different type depending on the cpu architecture? maybe `uint32_t` would fit better?
12:38 < ws-client> <Jupstar> well so or so, yes at least an unsigned type. however u32 has a limit of 4GB
12:38 < ws-client> <Jupstar> GPUs indeed support more
12:39 < bridge_> <heinrich5991> you want to be able to load textures with widths larger than 4 billion pixels?
12:39 < bridge_> <heinrich5991> that doesn't make sense to me
12:39 < ws-client> <Jupstar> i want to write software that follows a certain logic
12:39 < ws-client> <Jupstar> does std::vector need size_t?
12:40 < ws-client> <Jupstar> do you want to allocate memory bigger than 4gb in ddnet?
12:40 < bridge_> <heinrich5991> yes. because it's a generic array that should support allocations larger than 4GB on 64 bit systems
12:40 < ws-client> <Jupstar> then i say the same about GPU textures
12:40 < bridge_> <heinrich5991> I don't see why it's beneficial to support different widths on 32 bit vs 64 bit systems
12:41 < bridge_> <heinrich5991> I see why it's useful to support different array lengths on 32 bit vs 64 bit
12:41 < ws-client> <Jupstar> but when u run through a texture u dont have a width of u32
12:41 < ws-client> <Jupstar> u have an index of u32
12:42 < bridge_> <robyt3> You could add a `struct` that contains all the smooth scrolling variables and logic for one axis and then use two objects of those structs for the X and Y axis. Your struct can have a pointer to `CEditor` so it can use the shared editor functions as well
12:42 < bridge_> <robyt3> You could add a `struct` that contains all the smooth zoom variables and logic for one axis and then use two objects of those structs for the X and Y axis. Your struct can have a pointer to `CEditor` so it can use the shared editor functions as well
12:42 < bridge_> <heinrich5991> I don't understand what you mean by this
12:43 < ws-client> <Jupstar> u do width * height
12:43 < bridge_> <heinrich5991> ah
12:43 < bridge_> <heinrich5991> so we're getting bitten by C's implicit conversions
12:43 < bridge_> <heinrich5991> I see
12:44 < bridge_> <heinrich5991> yea, if you want to account for all calculations that you can do with width and height, `size_t` makes sense
12:45 < bridge_> <heinrich5991> still a bit weird to me to use `size_t` for e.g. `SubOffsetX` but I guess it's okay
12:45 < ws-client> <Jupstar> well these kind of offsets are always look from (0, 0)
12:46 < ws-client> <Jupstar> so always positive
12:46 < bridge_> <heinrich5991> yes, `unsigned` makes sense to me
12:46 < bridge_> <heinrich5991> but I like fixed-width integers better
12:46 < bridge_> <heinrich5991> because they don't depend on the CPU architecture you're compiling for
12:47 < bridge_> <robyt3> Looks like the commit I initially expected is not causing the issue
12:47 < ws-client> <Jupstar> yes, that makes sense, i'd always use them for stuff where i dont directly interact with raw memory, i guess
12:50 < ws-client> <Jupstar> @heinrich5991 do you dislike `auto`?
12:51 < bridge_> <heinrich5991> for some reason I like it less in C++ than in rust
12:51 < ws-client> <Jupstar> ok
12:51 < bridge_> <heinrich5991> perhaps due to the automatic type conversions in C++? idk
12:51 < ws-client> <Jupstar> was about to say that i feel like in rust i type types more rarely
12:52 < ws-client> <Jupstar> we could enable a compiler flag to disallow most conversions
12:52 < ws-client> <Jupstar> but is probs lot of work :D
12:52 < ws-client> <Jupstar> (implicit ones)
12:54 < bridge_> <robyt3> Wanna place your bets? Will it be the `size_t` change or the other changes causing Valgrind to crash?
12:54 < ws-client> <Jupstar> https://github.com/Robyt3/ddnet/commit/0be0e2f448c2ca49323ea9adec459f1fb1bf312c
12:54 < ws-client> <Jupstar> this one
12:54 < ws-client> <Jupstar> xd
12:55 < ws-client> <Jupstar> to me none of the changes make sense to me to cause crashes :D
12:56 < bridge_> <heinrich5991> let's do the first one, for fun
12:58 < ws-client> <Jupstar> have u ever tried the changes without valgrind? XD
12:59 < bridge_> <robyt3> yes, the both in the CI and on Ubuntu the integration test worked without Valgrind
12:59 < bridge_> <robyt3> final test is running now, we should have the answer shortly
12:59 < ws-client> <Jupstar> then i'll claim we have a negative width or height somewhere and valgrind tries to allocates huge chunks of memory now
12:59 < ws-client> <Jupstar> (size_t)-1
13:00 < ws-client> <Jupstar> then it simply says nah
13:00 < bridge_> <robyt3> that's my explanation also
13:00 < bridge_> <robyt3> Looks like it's confirmed, the `size_t` change causes the crash
13:01 < bridge_> <robyt3> master with Valgrind works, with just the `size_t` commit it doesn't work
13:02 < bridge_> <robyt3> Guess I'll add asserts for negative width and height everywhere to catch this...
13:03 < ws-client> <Jupstar> is it only at loading?
13:03 < ws-client> <Jupstar> mh ok menu background map... u could disable that
13:03 < bridge_> <heinrich5991> I guess that might be a point in favor of signed integer types in C/C++
13:03 < ws-client> <Jupstar> then u can maybe exclude all buffers
13:04 < ws-client> <Jupstar> a point in favor?
13:04 < ws-client> <Jupstar> that it causes undefined behavior?
13:04 < bridge_> <heinrich5991> no, signed→unsigned is not UB
13:04 < bridge_> <heinrich5991> that this implicit conversion creates integers that the programmer didn't intend to place there
13:04 < ws-client> <Jupstar> yeah but u are clearly not supposed to pass negative values to the functions xD
13:05 < ws-client> <Jupstar> to me this is one of the reasons i dislike google's weird developer guide
13:06 < bridge_> <Ewan> https://cdn.discordapp.com/attachments/293493549758939136/1131542544300380221/image.png
13:06 < bridge_> <Ewan> roby such a potty mouth
13:06 < ws-client> <Jupstar> xD
13:06 < bridge_> <Ewan> what do u normally do about this? surely this isn't the first bot wave
13:06 < bridge_> <ryozuki> does C has isize
13:06 < bridge_> <ryozuki> for pointer offsets
13:06 < ws-client> <Jupstar> it does
13:06 < ws-client> <Jupstar> at least cpp
13:07 < ws-client> <Jupstar> ssize_t
13:07 < ws-client> <Jupstar> i think
13:07 < bridge_> <heinrich5991> first bot wave
13:07 < bridge_> <Ewan> crazy
13:08 < ws-client> <Jupstar> but i think u are supposed to use ptrdiff_t for ptr calc xd
13:20 < ws-client> <Jupstar> @robyt3 ping me when u found smth. i'm really interested what texture ever writes negative values here... the only thing that i could theoretically imagine is the font textures :D
13:20 < ws-client> <Jupstar> maybe the entity numbers
13:20 < ws-client> <Jupstar> but anything else should be handled by the png loader already
13:25 < bridge_> <robyt3> @jupeyy_keks in CopyTextureBufferSub: SrcSubOffsetX is negative or zero
13:25 < ws-client> <Jupstar> who is the caller?
13:25 < bridge_> <robyt3> @jupeyy_keks in CopyTextureFromTextureBufferSub: SrcSubOffsetX is negative or zero
13:25 < bridge_> <robyt3> in CopyTextureFromTextureBufferSub*
13:26 < bridge_> <robyt3> Did get a backtrace yet, guess it just run the headless client with gdb
13:27 < ws-client> <Jupstar> u can also just run the client normally
13:27 < ws-client> <Jupstar> the assert will happen without valgrind
13:27 < ws-client> <Jupstar> so some asset wants to read negative data
13:27 < ws-client> <Jupstar> interesting
13:27 < ws-client> <Jupstar> some sprite to be precise
13:28 < bridge_> <robyt3> It's from skin loading
13:28 < ws-client> <Jupstar> xdd
13:28 < ws-client> <Jupstar> who would have thought
13:29 < bridge_> <robyt3> Looks like a false alarm though
13:29 < bridge_> <robyt3> The assertions was wrong, offset is zero which is allowed
13:29 < ws-client> <Jupstar> ah ok
13:29 < bridge_> <Ewan> wow weird i am getting a graphics related segfault when changing skin loading stuff
13:29 < bridge_> <Ewan> it's kind of a kink in the hose
13:29 < bridge_> <Ewan> of getting this cool async skin thing working
13:30 < ws-client> <Jupstar> did u use mutex?
13:30 < bridge_> <Ewan> ye
13:30 < bridge_> <Ewan> i just meant
13:30 < bridge_> <Ewan> maybe similar to what roby is going thru rn
13:31 < ws-client> <Jupstar> ah, sounded like you use the graphics class from a different thread
13:32 < ws-client> <Jupstar> just watch out to not use graphics functions that use a member state
13:32 < ws-client> <Jupstar> maybe u can make all functions static that you use
13:32 < ws-client> <Jupstar> to be sure no member variable was used
13:33 < bridge_> <robyt3> nevermind, it's actually not even the `size_t` change according to the CI :santatrollet:
13:34 < ws-client> <Jupstar> i tell ya its the name string check xDD
13:34 < ws-client> <Jupstar> strings always evil 😂 
13:36 < bridge_> <_voxeldoesart> robyt3 doesnt do intercourse, he looks at you and finds some random thing about your body that'd odd and then tries to fix it LOL
13:36 < bridge_> <_voxeldoesart> irl bug fixer
13:36 < bridge_> <Ewan> err
13:36 < bridge_> <Ewan> confirm ?
13:53 < bridge_> <ryozuki> strings are not evil in rust
14:04 < bridge_> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1131557238100725881/RDT_20230720_1404125154126828921382081.jpg
14:17 < bridge_> <robyt3> It's the string length check... :nouis:
14:24 < bridge_> <learath2> Me
14:24 < bridge_> <learath2> I've started to write intermediate logic steps aswell to help with this
14:31 < bridge_> <Ewan> Oh my god
14:31 < bridge_> <Ewan> When I do this I try so hard to keep track of what’s going on that I can’t properly form a sentence
14:31 < bridge_> <Ewan> Maybe just make a noise in response
14:31 < bridge_> <Ewan> The focus 🧠
14:33 < bridge_> <Ewan> actually writing UML when I’m spitballing helps too but usually I don’t expect to need it
14:33 < bridge_> <Ewan> then i need it
14:33 < bridge_> <Ewan> the online editors are handy
14:34 < bridge_> <ryozuki> my uml is rust code
14:34 < bridge_> <ryozuki> joke joke
14:34 < bridge_> <ryozuki> i rarely do uml
14:35 < bridge_> <Ewan> Maybe i print out this comic and tap it when someone asks my attention while im braining
14:36 < bridge_> <Ewan> i can’t i think that is “sperg behavior”
14:50 < ws-client> <Jupstar> @robyt3 LOL did u find out why exactly?
14:51 < ws-client> <Jupstar> do we load a lol .png file?
14:51 < ws-client> <Jupstar> doesnt the check need to be <= 3 anyway?
14:59 < bridge_> <matodor> clickbait for accounts system :poggers2:
14:59 < bridge_> <Ewan> it’s real and it’s everywhere and it’s often
15:01 < bridge_> <robyt3> @jupeyy_keks 
15:01 < bridge_> <robyt3> ```py
15:01 < bridge_> <robyt3> image_null = Image("null", "")
15:01 < bridge_> <robyt3> image_particles = Image("particles", "particles.png")
15:01 < bridge_> <robyt3> image_game = Image("game", "game.png")
15:01 < bridge_> <robyt3> ...
15:01 < bridge_> <robyt3> ```
15:01 < bridge_> <robyt3> For whatever reason we have `image_null` that has an empty filename
15:01 < bridge_> <robyt3> It's used in `set_tee = SpriteSet("tee", image_null, 8, 4)`
15:02 < ws-client> <Jupstar> very huge troll
15:03 < ws-client> <Jupstar> and funny that this can kill valgrind xD
18:56 < ChillerDragon> jopsti bringing da trol to serious githubbing
18:58 < bridge_> <ryozuki> chiller bringing da trol to serious bots
18:58 < ChillerDragon> wot bots
18:58 < bridge_> <ryozuki> many xd
18:58 < ChillerDragon> no proof
18:58 < bridge_> <Jupstar ✪> chillerdragon: when fix mouse select
18:58 < ChillerDragon> jopsti
18:58 < bridge_> <Jupstar ✪> chillerdragon: when fix teams
18:58 < ChillerDragon> go bottom left
18:58 < ChillerDragon> click cogwheel
18:58 < bridge_> <Jupstar ✪> lol its a setting
18:58 < ChillerDragon> deactivate emoji_picker
18:58 < bridge_> <Jupstar ✪> to fix selection? XD
18:58 < ChillerDragon> reload page
18:59 < bridge_> <Jupstar ✪> WTF XDD
18:59 < ChillerDragon> xd
18:59 < ChillerDragon> yes
18:59 < ChillerDragon> good "fix"
18:59 < bridge_> <Jupstar ✪> the emoji picker breaks mouse selection
18:59 < bridge_> <Jupstar ✪> epic
18:59 < ChillerDragon> yes
18:59 < ChillerDragon> nobodi oose it ani way
18:59 < bridge_> <Jupstar ✪> i love this page
18:59 < ChillerDragon> kill it with fire
18:59 < bridge_> <Jupstar ✪> burn the fire
18:59 < ChillerDragon> :fire:
19:00 < ws-client> <ChillerDragon> did u try?
19:00 < ws-client> <ChillerDragon> selecting works soo good
19:00 < bridge_> <Jupstar ✪> omg selecting text in a browser works good now
19:00 < bridge_> <Jupstar ✪> omg such an epic feature
19:00 < ws-client> <ChillerDragon> 🚀 
19:01 < ws-client> <ChillerDragon> blazingly customizable chat app
19:02 < bridge_> <Jupstar ✪> epic
19:02 < bridge_> <Jupstar ✪> can it also disable x11?
19:07 < ChillerDragon> axaxaxax
19:17 < bridge_> <_voxeldoesart> only elon musk fans use 🚀 unironically
19:19 < bridge_> <Jupstar ✪> and ppl that want to visit ✪ Jup-Star ✪
19:20 < bridge_> <_voxeldoesart> what is that
19:20 < bridge_> <Jupstar ✪> a star 🌟
19:21 < bridge_> <Jupstar ✪> called Jup
19:21 < bridge_> <_voxeldoesart> thats crazy
19:38 < ChillerDragon> @davide55 still can not join ger10
19:40 < ChillerDragon> :+1: :eye: and :heavy_check_mark: are the only emotes i use unironically
19:40 < ChillerDragon> and ofc :see_no_evil:
19:46 < bridge_> <headshotnoby> xd sure chillerbot.png is lyfe
19:50 < ws-client> <ChillerDragon> <:justatest:572499997178986510> 
21:22 < bridge_> <ryozuki> @jupeyy_keks https://twitter.com/nodesandnoodles/status/1681874450713567234
21:24 < bridge_> <Jupstar ✪> wow looks so real
21:24 < bridge_> <ryozuki> https://twitter.com/cmzw_/status/1682010424177459200
21:24 < bridge_> <ryozuki> blender twitter xd
21:25 < bridge_> <ryozuki> https://twitter.com/vtuberkaibou/status/1681952096416051200
21:25 < bridge_> <ryozuki> procedural stuff is amazing
23:43 < bridge_> <Ewan> https://cdn.discordapp.com/attachments/293493549758939136/1131702875194667078/image.png
23:43 < bridge_> <Ewan> Looks like someone's busy coding on GitHub! 😄👨‍💻