02:13 <+bridge_> [ddnet] <emy> oi
02:15 <+bridge_> [ddnet] <emy> não tem nenhum br não
02:16 <+bridge_> [ddnet] <emy> :tee_thinking:
02:17 <+bridge_> [ddnet] <lynn> :tee_thinking:
06:35 <+bridge_> [ddnet] <ᶰ°Konͧsti> Where to find the .teeworlds thing on windows
06:57 <+bridge_> [ddnet] <louis> go windows search bottom left
06:57 <+bridge_> [ddnet] <louis> type in %appdata%
06:57 <+bridge_> [ddnet] <louis> then Teeworlds
08:37 <+bridge_> [ddnet] <lynn> yay haiku support
13:22 <+bridge_> [freenode] <chillerdragon[m]> i wish there was a more obvious word to describe the .teeworlds thing :D
13:37 <+bridge_> [ddnet] <Jupstar ✪> Config directory
13:45 <+bridge_> [ddnet] <TsFreddie> ~~cd~~
14:11 <+bridge_> [ddnet] <Ryozuki> https://ash.ms/2019-10-02/retro-website-launch/
14:11 <+bridge_> [ddnet] <Ryozuki> holy shit
14:24 <+bridge_> [freenode] <AlwaysLivid> I was on here around October the 3rd, according to my logs. The Haiku port is very close to being complete, but I literally have no idea how to resolve the last (hopefully) outstanding issue.
15:24 <+bridge_> [ddnet] <deen> what is it?
15:38 <+bridge_> [freenode] <AlwaysLivid> Dunno, some lvalue/rvalue thing, seems to be a bug on the operating system-level.
15:39 <+bridge_> [ddnet] <deen> sounds like a debugger might help
15:41 <+bridge_> [freenode] <AlwaysLivid> I just got word that it builds...
15:46 <+bridge_> [freenode] <AlwaysLivid> It may be building on 32-bit and working, but it doesn't on 64-bit because of a for i loop utilizing a long long variable under src/game/client/components/chat.cpp
16:02 <+bridge_> [freenode] <AlwaysLivid> Teeworlds builds successfully on Haiku (although it shows a black screen right now, which is being discussed as we speak), but I'm not sure what's happening here.
16:08 <+bridge_> [ddnet] <deen> maybe just make it an int64 or something like that
16:12 <+bridge_> [freenode] <AlwaysLivid> That should probably work. Should I make it an int64 on Haiku only, or should that affect all platforms?
16:12 <+bridge_> [ddnet] <heinrich5991> all platforms
16:12 <+bridge_> [ddnet] <heinrich5991> the fewer #ifdef HAIKU the better
16:12 <+bridge_> [freenode] <AlwaysLivid> seems fair!
16:12 <+bridge_> [freenode] <AlwaysLivid> Thanks for that.
16:14 <+bridge_> [freenode] <AlwaysLivid> Oh, I see why the variable is `long long`.
16:14 <+bridge_> [freenode] <AlwaysLivid> m_aLastSoundPlayed[CHAT_NUM] is defined as `int64`.
17:24 <+bridge_> [freenode] <chillerdragon[m]> @Jupstar ✪ yea true that term is there but it doesnt seem well established i feel like the average tw player does not know what a Config Directory is even tho he knows %APPDATA%\Teeworlds
18:24 <+bridge_> [ddnet] <Learath2> Of course our diskcache on ddnet.tw is pickled with python2
18:24 <+bridge_> [ddnet] <Learath2> because for once if something worked on the first try we'd have to deal with the 4 horseman of the apocalypse
18:29 <+bridge_> [ddnet] <Learath2> and ofc there is no asyncpg for python2.7
18:30 <+bridge_> [ddnet] <Learath2> @jao please tell me how you got this thing to work with a cache with entries pickled in py2?
18:31 <+bridge_> [ddnet] <Learath2> I'll patch diskcache to load with a different encoding...
18:38 <+bridge_> [ddnet] <jao> maybe i used py2 😄
18:39 <+bridge_> [ddnet] <jao> don’t remember
18:40 <+bridge_> [ddnet] <Learath2> there is no asyncpg for py3, how would you even use it
18:40 <+bridge_> [ddnet] <Learath2> man why did we use python for implementing anything 😦 I wish we did the infrastructure for ddnet in nim or sth else that is not python
18:41 <+bridge_> [ddnet] <jao> does the file have asyncpg?
18:41 <+bridge_> [ddnet] <jao> the file that doesnt work is separate from the normal bot
18:43 <+bridge_> [ddnet] <Learath2> ah, you changed it so you insert it to the db somewhere else I guess
18:46 <+bridge_> [ddnet] <Learath2> man I wasted 4 days on this and I still didn't even reproduce the damn bug
18:46 <+bridge_> [ddnet] <Learath2> I'm just hitting python with a hammer until it works
18:48 <+bridge_> [ddnet] <jao> did i try the file i sent u?
18:49 <+bridge_> [ddnet] <jao> its not the one on github
18:50 <+bridge_> [ddnet] <Learath2> yeah, I'm using that, with python2 it loads the cache just fine but I get a `TypeError: 'Player' object is not iterable`
18:56 <+bridge_> [ddnet] <Learath2> Finally...
18:56 <+bridge_> [ddnet] <Learath2> god
18:56 <+bridge_> [ddnet] <Learath2> now it won't happen on my computer because I have 32g of ram
18:57 <+bridge_> [ddnet] <Learath2> as expected works perfectly fine on my computer...
19:05 <+bridge_> [ddnet] <Learath2> okay I can get it to run out of memory with `ulimit -Sv 200000` I think we should just run this on a server with more memory, but I'll try to see what can be done
19:06 <+bridge_> [ddnet] <Learath2> can't even debug it with a ulimit that low because python2 is as production ready as my toy language
19:10 <+bridge_> [ddnet] <Learath2> @jao okay, try `json.dump(out, f)` instead of `f.write(json.dumps(out))`
19:10 <+bridge_> [ddnet] <Learath2> that lets me execute this with 250M of memory
19:52 <+bridge_> [freenode] <AlwaysLivid> Question: Does m_LastChatSend (in chat.cpp) stand for Unix time?
19:54 <+bridge_> [ddnet] <deen> ticks since map load
19:56 <+bridge_> [freenode] <AlwaysLivid> ... Hm. I get that I'll sound stingy, but could 32 bits work rather than 64?
19:58 <+bridge_> [ddnet] <jao> @Learath2 it works :poggers:
19:59 <+bridge_> [ddnet] <Learath2> @jao I can give you one more optimization that would cut another 200M
19:59 <+bridge_> [ddnet] <Learath2> just so we have some more headroom
19:59 <+bridge_> [ddnet] <jao> which?
19:59 <+bridge_> [ddnet] <Learath2> use a chunked download for the cache file into a file https://gist.github.com/Learath2/4093e09d079210b8f677e41ace8a5659
20:00 <+bridge_> [ddnet] <Learath2> that instead of just doing resp = requests.get
20:01 <+bridge_> [ddnet] <jao's hairy kebab> does "download skins" work for skins i manually add to folder outside from database ?
20:01 <+bridge_> [ddnet] <Learath2> there is a lot more that can be done btw, I just hope this is enough, but we can also delete `data` early (I think a gc.collect() is needed afterwards)
20:01 <+bridge_> [ddnet] <Learath2> @yāccreフレシュマイボイ no, download skins only gets skins from the database
20:03 <+bridge_> [ddnet] <Learath2> oh btw I made cute graphs
20:03 <+bridge_> [ddnet] <Learath2> This was the initial memory usage
20:03 <+bridge_> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/833402478645084212/i.png
20:04 <+bridge_> [ddnet] <Learath2> this is after chunked downloads
20:04 <+bridge_> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/833402533883019264/f.png
20:04 <+bridge_> [ddnet] <Learath2> this is with streaming the json dump
20:04 <+bridge_> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/833402607485190144/fj.png
20:04 <+bridge_> [ddnet] <Learath2> and this is a failed attempt at early del, I think this didn't work because I didn't gc.collect()
20:04 <+bridge_> [ddnet] <Learath2> https://cdn.discordapp.com/attachments/293493549758939136/833402710740435004/fje.png
20:05 <+bridge_> [ddnet] <jao> i tried that too
20:05 <+bridge_> [ddnet] <Learath2> you delete way too late though we are technically done with data after the first loop
20:06 <+bridge_> [ddnet] <Learath2> then you can iterate `out['players'].keys()` instead
20:08 <+bridge_> [ddnet] <Learath2> In hindsight I should have fixed the y axis of these plots so the reduction was more obvious...
20:08 <+bridge_> [ddnet] <Learath2> you live and you learn
20:09 <+bridge_> [ddnet] <Learath2> maybe plot them all on the same graph even...
20:16 <+bridge_> [ddnet] <Learath2> fwiw with both files predownloaded I could run it within 250M, this plot is with unlimited memory so aggressive GC never really kicked in
20:20 <+bridge_> [ddnet] <Learath2> @deen btw if you weren't going to cache them at all, why did you download skins into config_directory? We could have downloaded them to some temporary storage
20:24 <+bridge_> [freenode] <chillerdragon[m]> AlwaysLivid:  so you want to run ddnet on a system without 64 bit variables? I assume the chat thing will be your least problematic code. int64 is all over the place. I think the team masks depend on 64 bits for 64 players. But there are also win32 builds arent there? So it should work somehow but idk
20:25 <+bridge_> [freenode] <AlwaysLivid> no, the system has full support for 64 bit variables.
20:25 <+bridge_> [freenode] <AlwaysLivid> it's unix-like, even supertuxkart can run on it for example
20:26 <+bridge_> [freenode] <AlwaysLivid> it's the "storing 32-bit integers in 64-bit variables because this is an array" thing that I'm worried about considering that `long long` seems to be out of the question for the time being, so I'm cutting edges.
20:28 <+bridge_> [freenode] <AlwaysLivid> nobody has any idea why the operating system's definitions that ddnet manually defines for two variables aren't, like, working as it should, and i can't seem to be able to easily reproduce this in order to file a bug report on the system and leave the codebase here unaffected
20:36 <+bridge_> [ddnet] <Jupstar ✪> isnt it just bcs int64 can e.g. be defined as signed long, while long long is a complete different type
20:36 <+bridge_> [ddnet] <Jupstar ✪> imo chat.cpp should just be updated to use "auto" or int64 directly
20:36 <+bridge_> [ddnet] <Jupstar ✪> (even if both are 64bit)
20:44 <+bridge_> [ddnet] <Jupstar ✪> also ddnet should get away from system.h as much as possible and use c standard really
21:27 <+bridge_> [freenode] <AlwaysLivid> ddnet is fine for using long long
21:29 <+bridge_> [ddnet] <Panos (AlwaysLivid)> it's just that one of the systems that i'm trying to get ddnet to work on seem to not deal with it very nicely (which is weird, because i can name other examples where it does)
21:33 <+bridge_> [ddnet] <Jupstar ✪> well thought bcs u said lvalue and rvalue
21:33 <+bridge_> [ddnet] <Jupstar ✪> sounded like bcs of type mismatch
21:33 <+bridge_> [ddnet] <Jupstar ✪> i still think it shouldnt use int64, since that define exists in some header
21:33 <+bridge_> [ddnet] <Panos (AlwaysLivid)> if it works fine on other systems and it doesn't on haiku
21:33 <+bridge_> [ddnet] <Panos (AlwaysLivid)> then it's likely on haiku
21:33 <+bridge_> [ddnet] <Panos (AlwaysLivid)> but the weird thing is that the exact opposite scenario could also apply
21:34 <+bridge_> [ddnet] <Panos (AlwaysLivid)> if `long long` has worked with other ported software but it hasn't with haiku, it could be because of ddnet
21:39 <+bridge_> [ddnet] <Chairn> I prefer int64 as it's more human readable if stdint is included ^^
21:42 <+bridge_> [ddnet] <Jupstar ✪> int64_t
21:42 <+bridge_> [ddnet] <Jupstar ✪> is just as good imo xd
21:43 <+bridge_> [ddnet] <Chairn> yeah, i meant int64_t
21:43 <+bridge_> [ddnet] <Chairn> i always use stdint in all my code file so that i never do stupid mistakes with wrongly sized integers
21:46 <+bridge_> [ddnet] <Jupstar ✪> yeah i prefer it too 😄
21:55 <+bridge_> [ddnet] <Learath2> pt
21:56 <+bridge_> [ddnet] <Learath2> it's actually not best practice to use fixed-width integers if you don't need them
22:18 <+bridge_> [ddnet] <Jupstar ✪> its the most defined behaviour so why not
22:20 <+bridge_> [ddnet] <Chairn> i don't get why? The size is given by the programmer for a specific purpose, so it better not be smaller than expected
22:27 <+bridge_> [ddnet] <Ryozuki> he is a c programmer he loves undefined behaviour
22:27 <+bridge_> [ddnet] <Ryozuki> :PES_SusThink:
22:30 <+bridge_> [ddnet] <Jupstar ✪> i mean for like simple returns or stuff it really doesnt matter
22:30 <+bridge_> [ddnet] <Jupstar ✪> but for memory layout i prefer defined behaviour
22:32 <+bridge_> [ddnet] <Ryozuki> https://www.news18.com/news/tech/new-zero-day-vulnerability-found-in-google-chrome-microsoft-edge-how-to-protect-yourself-3642407.html
22:33 <+bridge_> [ddnet] <Learath2> The compiler knows better, just chose a type with bounds guarantees that suits your needs
22:34 <+bridge_> [ddnet] <Ryozuki> @Learath2 i found something u will love, if u havent seen it yet https://suckless.org/sucks/systemd/
22:34 <+bridge_> [ddnet] <Learath2> If you actually want more arguments about it ask on ##C in freenode
22:34 <+bridge_> [ddnet] <Ryozuki> lol im never gonna ask smth there
22:34 <+bridge_> [ddnet] <Ryozuki> idk why i get a feeling if u ask anything there a bunch of elitists will crucify u
22:35 <+bridge_> [ddnet] <Learath2> Yeah I know this
22:35 <+bridge_> [ddnet] <Learath2> If you want a decent read about systemd https://blog.darknedgy.net/technology/2020/05/02/0/ is very nice
22:35 <+bridge_> [ddnet] <Ryozuki> darknedgy
22:35 <+bridge_> [ddnet] <Ryozuki> :monkalaugh:
22:35 <+bridge_> [ddnet] <Learath2> very well researched
22:50 <+bridge_> [ddnet] <heinrich5991> @Learath2 I think for software correctness, it's best to choose fixed-size types
22:54 <+bridge_> [ddnet] <Learath2> depends on your goals
22:54 <+bridge_> [ddnet] <Learath2> if you need it to be a certain size, sure
22:54 <+bridge_> [ddnet] <Learath2> but usually you care about the bounds of an integer
22:57 <+bridge_> [ddnet] <heinrich5991> do we agree that C's int/long/short are the worst of all worlds?
22:58 <+bridge_> [ddnet] <heinrich5991> useless type width bounds that aren't actually used as such in practice
23:22 <+bridge_> [ddnet] <Chairn> for OS stuff, i guess C's default types are better, for all other stuff, intx_t seems better
23:28 <+bridge_> [ddnet] <heinrich5991> how do C types help for OS stuff?
23:29 <+bridge_> [ddnet] <heinrich5991> int isn't the architecture's native type. you'd probably want a register sized int for that