00:21 < bridge> <:v> @chillerdragon http://duneudne.free.fr/MB/index.html
00:21 < bridge> <:v> https://github.com/Shereef/teeworlds/tree/teefoot
00:35 < bridge> <chillerdragon> Yea that’s all linked in the forum post Leo sent me already. I think he is looking for that fun version specifically
00:37 < bridge> <chillerdragon> console with gtk4? :D
00:37 < bridge> <chillerdragon> 
00:37 < bridge> <chillerdragon> Anyways custom clients are against tos
00:38 < bridge> <_voxeldoesart> chillerbot:
00:40 < bridge> <chillerdragon> chillerbot is not a custom discord client
00:40 < bridge> <chillerdragon> It’s a custom irc client
00:42 < bridge> <_voxeldoesart> oh u were talking ab discord
08:47 < bridge> <chillerdragon> Heinrich pr be like 0/7 checklist items done hehe
10:13 < bridge> <ryozuki> done today
10:14 < bridge> <ryozuki> 488ms
10:34 < ChillerDragon> @ryouzki ❤️ 
10:34 < ChillerDragon> best "rust" "coder" eveR!!!!!!
12:38 < bridge> <gaysaks> ку, ты видел зимнюю раздачу rust? я на твиче короч спиздил у типа реф ссылку и хочу заабузить. Если хочешь тож забрать забирай в тг канале @freerustik
12:39 < bridge> <Jupstar ✪> i only understand train station
13:03 < bridge> <Bota> @Discord Mod this russian guy is promoting giveaways in different channels. I just translated it
13:05 < bridge> <Bota> Choo choo
13:12 < bridge> <Ewan> lol
14:05 < bridge> <ryozuki> yes
15:17 < bridge> <ryozuki> @learath2 are u using gentoo
15:18 < bridge> <learath2> Ofc, I am gentoo
15:19 < bridge> <Jupstar ✪> @learath2 
15:19 < bridge> <Jupstar ✪> 
15:19 < bridge> <Jupstar ✪> https://discord.com/channels/252358080522747904/293493549758939136/1176801129363931196
15:19 < bridge> <Jupstar ✪> 
15:19 < bridge> <Jupstar ✪> Not that access is always access by value since it's important that the data type stays small. So index for vec is obv not possible
15:20 < bridge> <Jupstar ✪> Ofc every structure has advantages and disadvantaged
15:20 < bridge> <Jupstar ✪> Ofc every structure has advantages and disadvantages
15:20 < bridge> <Jupstar ✪> And i also don't want to exclude slightly more cache misses
15:20 < bridge> <learath2> heinrich is a classic CS enjoyer. They hate linked lists and gotos
15:21 < bridge> <ryozuki> linked lists are bad 98% of times
15:21 < bridge> <ryozuki> @learath2 u kinda agree right
15:21 < bridge> <ryozuki> i mean
15:21 < bridge> <ryozuki> xd
15:21 < bridge> <ryozuki> they only famous cuz they are used to teach
15:21 < bridge> <learath2> I disagree ofc
15:21 < bridge> <Jupstar ✪> That's also just your opinion because of rust
15:21 < bridge> <ryozuki> not rly, overall
15:22 < bridge> <ryozuki> ```
15:22 < bridge> <ryozuki> Just so we're totally 100% clear: I hate linked lists. With a passion. Linked lists are terrible data structures. Now of course there's several great use cases for a linked list:
15:22 < bridge> <ryozuki> 
15:22 < bridge> <ryozuki>     You want to do a lot of splitting or merging of big lists. A lot.
15:22 < bridge> <ryozuki>     You're doing some awesome lock-free concurrent thing.
15:22 < bridge> <ryozuki>     You're writing a kernel/embedded thing and want to use an intrusive list.
15:22 < bridge> <ryozuki>     You're using a pure functional language and the limited semantics and absence of mutation makes linked lists easier to work with.
15:22 < bridge> <ryozuki>     ... and more!
15:22 < bridge> <ryozuki> 
15:22 < bridge> <ryozuki> But all of these cases are super rare for anyone writing a Rust program. 99% of the time you should just use a Vec (array stack), and 99% of the other 1% of the time you should be using a VecDeque (array deque). These are blatantly superior data structures for most workloads due to less frequent allocation, lower memory overhead, true random access, and cache locality.
15:22 < bridge> <ryozuki> 
15:22 < bridge> <ryozuki> Linked lists are as niche and vague of a data structure as a trie. Few would balk at me claiming a trie is a niche structure that your average programmer could happily never learn in an entire productive career -- and yet linked lists have some bizarre celebrity status. We teach every undergrad how to write a linked list. It's the only niche collection I couldn't kill from std::collections. It's the list in C++!
15:22 < bridge> <ryozuki> 
15:22 < bridge> <ryozuki> We should all as a community say no to linked lists as a "standard" data structure. It's a fine data structure with several great use cases, but those use cases are exceptional, not common.
15:22 < bridge> <ryozuki> 
15:22 < bridge> <ryozuki> Several people apparently read the first paragraph of this PSA and then stop reading. Like, literally they'll try to rebut my argument by listing one of the things in my list of great use cases. The thing right after the first paragraph!
15:23 < bridge> <ryozuki> ```
15:23 < bridge> <learath2> Linked lists are ideal when you need O(1) deletion and don't need indexing. And as Jupman said, if you put them in a contiguous block cache misses aren't an issue anymore
15:23 < bridge> <learath2> Fwiw I was about to write and @ryozuki hates them because he read a blogpost where a classical CS guy said they are bad and it looked reasonable 😄
15:23 < bridge> <ryozuki> no read it and it makes sense in my head
15:23 < bridge> <ryozuki> i read*
15:24 < bridge> <ryozuki> there are facts
15:24 < bridge> <ryozuki> i never said u should never ever use it
15:24 < bridge> <ryozuki> they have their niche use case
15:24 < bridge> <Jupstar ✪> It makes sense for traditional linked lists maybe
15:24 < bridge> <ryozuki> common use case is more suited for a  vec
15:24 < bridge> <ryozuki> > less frequent allocation, lower memory overhead, true random access, and cache locality
15:24 < bridge> <ryozuki> a trie is nice for making merkle trees for example
15:24 < bridge> <ryozuki> hashing in bittorrent
15:25 < bridge> <Jupstar ✪> It's nice to push items to the back, still keep order and have old stuff in front
15:25 < bridge> <Jupstar ✪> There are many use cases
15:25 < bridge> <ryozuki> vecdeque
15:25 < bridge> <ryozuki> growable ring buffer
15:25 < bridge> <learath2> Vecdeques can do that too
15:25 < bridge> <Jupstar ✪> No i mean an existing item
15:26 < bridge> <Jupstar ✪> It's basically on fly sorting, if your sorting parameters changes
15:26 < bridge> <devinci24> Learath how is it O(1) deletion? If you ahve multiple nodes you still need to delete them 1 by 1 no? or am I missing something
15:26 < bridge> <Jupstar ✪> With a call you do xd
15:26 < bridge> <ryozuki> no
15:26 < bridge> <learath2> But iirc they are secretly linked lists. They are implemented as a linked list of vecs so you dont have to resize all the time
15:26 < bridge> <ryozuki> u point prev ptr to next ptr
15:27 < bridge> <devinci24> oh yeah
15:27 < bridge> <ryozuki> its o1
15:27 < bridge> <devinci24> whoops
15:27 < bridge> <ryozuki> a vecdeque is nice for deleting too
15:27 < bridge> <ryozuki> it leaves holes in the ring buffer
15:27 < bridge> <ryozuki> tho
15:27 < bridge> <ryozuki> https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.make_contiguous
15:28 < bridge> <ryozuki> > Rearranges the internal storage of this deque so it is one contiguous slice, which is then returned.
15:28 < bridge> <ryozuki> > 
15:28 < bridge> <ryozuki> > This method does not allocate and does not change the order of the inserted elements. As it returns a mutable slice, this can be used to sort a deque.
15:28 < bridge> <ryozuki> > 
15:28 < bridge> <ryozuki> > Once the internal storage is contiguous, the as_slices and as_mut_slices methods will return the entire contents of the deque in a single slice.
15:28 < bridge> <learath2> Every data structure has it's place. Including linked lists
15:28 < bridge> <Jupstar ✪> Anyway. I wouldn't directly blame the idea of linked lists. But yeah a linked list like you learn in school is probably rarely a good idea
15:28 < bridge> <ryozuki> yeah, its just linked lists are more niche than tries
15:28 < bridge> <ryozuki> but they are mentioned more
15:29 < bridge> <ryozuki> because they used for teaching
15:29 < bridge> <learath2> Actually in C I would argue you should always start with a linked list or an array
15:29 < bridge> <ryozuki> yeah its mostly C to blame
15:29 < bridge> <ryozuki> i agree xd
15:29 < bridge> <ryozuki> > They have O(1) split-append-insert-remove if you have a pointer there
15:29 < bridge> <ryozuki> > 
15:29 < bridge> <ryozuki> > Yep! Although as Bjarne Stroustrup notes this doesn't actually matter if the time it takes to get that pointer completely dwarfs the time it would take to just copy over all the elements in an array (which is really quite fast).
15:29 < bridge> <ryozuki> > 
15:29 < bridge> <ryozuki> > Unless you have a workload that is heavily dominated by splitting and merging costs, the penalty every other operation takes due to caching effects and code complexity will eliminate any theoretical gains.
15:29 < bridge> <ryozuki> > 
15:30 < bridge> <ryozuki> > But yes, if you're profiling your application to spend a lot of time in splitting and merging, you may have gains in a linked list.
15:30 < bridge> <learath2> Just give it a go, benchmark, if it doesnt meet your performance requirements go on and implement a cool space age datastructure
15:30 < bridge> <ryozuki> > Linked lists waste less space
15:30 < bridge> <ryozuki> > 
15:30 < bridge> <ryozuki> > Well, this is complicated. A "standard" array resizing strategy is to grow or shrink so that at most half the array is empty. This is indeed a lot of wasted space. Especially in Rust, we don't automatically shrink collections (it's a waste if you're just going to fill it back up again), so the wastage can approach infinity!
15:31 < bridge> <ryozuki> > 
15:31 < bridge> <ryozuki> > But this is a worst-case scenario. In the best-case, an array stack only has three pointers of overhead for the entire array. Basically no overhead.
15:31 < bridge> <ryozuki> > 
15:31 < bridge> <ryozuki> > Linked lists on the other hand unconditionally waste space per element. A singly-linked list wastes one pointer while a doubly-linked list wastes two. Unlike an array, the relative wasteage is proportional to the size of the element. If you have huge elements this approaches 0 waste. If you have tiny elements (say, bytes), then this can be as much as 16x memory overhead (8x on 32-bit)!
15:31 < bridge> <ryozuki> > 
15:31 < bridge> <ryozuki> > Actually, it's more like 23x (11x on 32-bit) because padding will be added to the byte to align the whole node's size to a pointer.
15:31 < bridge> <ryozuki> > 
15:31 < bridge> <ryozuki> > This is also assuming the best-case for your allocator: that allocating and deallocating nodes is being done densely and you're not losing memory to fragmentation.
15:31 < bridge> <ryozuki> > 
15:31 < bridge> <ryozuki> > But yes, if you have huge elements, can't predict your load, and have a decent allocator, there are memory savings to be had!
15:32 < bridge> <ryozuki> no need to impl, just use vec
15:32 < bridge> <learath2> Bjarne also invented C++. I would take his opinion with a grain of salt
15:32 < bridge> <ryozuki> vec should be the universal default data structure
15:32 < bridge> <ryozuki> and then u go to niches
15:32 < bridge> <ryozuki> unless u need a obvious map
15:32 < bridge> <louis> i  love linked lists and functional programming
15:32 < bridge> <ryozuki> i dont look at names i look at facts
15:32 < bridge> <ryozuki> did u try elixir
15:33 < bridge> <louis> not outside of clash of clans
15:33 < bridge> <ryozuki> xd
15:33 < bridge> <ryozuki> > I use linked lists all the time in <functional language>
15:33 < bridge> <ryozuki> > 
15:33 < bridge> <ryozuki> > Great! Linked lists are super elegant to use in functional languages because you can manipulate them without any mutation, can describe them recursively, and also work with infinite lists due to the magic of laziness.
15:33 < bridge> <ryozuki> > 
15:33 < bridge> <ryozuki> > Specifically, linked lists are nice because they represent an iteration without the need for any mutable state. The next step is just visiting the next sublist.
15:33 < bridge> <ryozuki> > 
15:33 < bridge> <ryozuki> > Rust mostly does this kind of thing with iterators. They can be infinite and you can map, filter, reverse, and concatenate them just like a functional list, and it will all be done just as lazily!
15:33 < bridge> <ryozuki> > 
15:33 < bridge> <ryozuki> > Rust also lets you easily talk about sub-arrays with slices. Your usual head/tail split in a functional language is just slice.split_at_mut(1). For a long time, Rust had an experimental system for pattern matching on slices which was super cool, but the feature was simplified when it was stabilized. Still, basic slice patterns are neat! And of course, slices can be turned into iterators!
15:33 < bridge> <ryozuki> > 
15:34 < bridge> <ryozuki> > But yes, if you're limited to immutable semantics, linked lists can be very nice.
15:34 < bridge> <ryozuki> > 
15:34 < bridge> <ryozuki> > Note that I'm not saying that functional programming is necessarily weak or bad. However it is fundamentally semantically limited: you're largely only allowed to talk about how things are, and not how they should be done. This is actually a feature, because it enables the compiler to do tons of exotic transformations and potentially figure out the best way to do things without you having to worry about it. However this comes at the cost of being 
15:34 < bridge> <ryozuki> > 
15:34 < bridge> <ryozuki> > Even in functional languages, you should endeavour to use the appropriate data structure for the job when you actually need a data structure. Yes, singly-linked lists are your primary tool for control flow, but they're a really poor way to actually store a bunch of data and query it.
15:34 < bridge> <learath2> You need to have absolutely tiny elements and a small array for the shift of all the data to be fast. And you need to have no way to get a pointer to what you want to delete without iterating which is rarely the case
15:35 < bridge> <ryozuki> we should use doubly linked lists with bubble sort
15:35 < bridge> <ryozuki> and add a gc just to make sure
15:35 < bridge> <ryozuki> we dont leak anything
15:35 < bridge> <ryozuki> :gigachad:
15:36 < bridge> <learath2> Only a brain damaged individual would use a linked list for small elements. Assume the worst case for linked lists assume the best case for arrays and yeah arrays handily beat linked lists
15:37 < bridge> <learath2> Did you know arrays have O(1) deletion aswell, you just have to only remove from the very end
15:37 < bridge> <ryozuki> xd actually the snippets are from a FAQ he put answering the questions he got asked
15:37 < bridge> <ryozuki> yeah, common use case
15:37 < bridge> <ryozuki> lifo best
15:38 < bridge> <ryozuki> anyway im not rly disagreeing xd
15:38 < bridge> <learath2> And linked lists have O(1) find as long as the node you are looking for is at the very start
15:39 < bridge> <Jupstar ✪> And linked hashmaps always have O(1)
15:39 < bridge> <Jupstar ✪> Best data structure
15:39 < bridge> <learath2> It's almost as if it's not as simple as "linked list bad"
15:40 < bridge> <learath2> Best data structure is no data structure
15:40 < bridge> <learath2> I just put everything in ram and use memcmp to find it when I need it
15:40 < bridge> <Jupstar ✪> I'm huge raii abuser
15:41 < bridge> <ryozuki> true, its as simple as: "linked lists are **usually** bad"
15:41 < bridge> <Jupstar ✪> I hate languages that don't have it
15:41 < bridge> <Jupstar ✪> Especially pyson
15:42 < bridge> <Jupstar ✪> And i hate that rust has no partial borrowing
15:43 < bridge> <Jupstar ✪> I often catch myself using indices to not fight with borrow checker
15:43 < bridge> <learath2> What is a partial borrow?
15:43 < bridge> <learath2> Oh I see
15:43 < bridge> <learath2> Yeah I needed that a couple times too
15:44 < bridge> <Jupstar ✪> You can probably always design it differently. But sometimes it feels overkill xd
15:44 < bridge> <chillerdragon> jopsti or patiga can you already turn this .demo link in a web viewable clip? i cba to download a demo file https://uploadnow.io/f/4XCWyHC
15:44 < bridge> <learath2> Whenever the borrow checker argues with me I just tell myself I need to change the way I think about it because thousands of people use rust daily with no issue
15:45 < bridge> <ryozuki> good mentality
15:45 < bridge> <ryozuki> it has limited partial borrowing
15:45 < bridge> <ryozuki> but ye
15:45 < bridge> <ryozuki> u can help develop polonius
15:45 < bridge> <ryozuki> and make it come faster
15:45 < bridge> <Jupstar ✪> I'd have nothing against it being more intelligent. But maybe that drastically increases compile time
15:45 < bridge> <Jupstar ✪> So i have no strong opinion
15:46 < bridge> <Jupstar ✪> Ez
15:46 < bridge> <learath2> Then I reminisce over the good old days of C where my compiler wasn't such a drama queen
15:46 < bridge> <chillerdragon> @jsaurusrex: still got matrix? :D
15:46 < bridge> <Jupstar ✪> Per link no. Bcs don't want to fight with cors
15:46 < bridge> <jsaurusrex> yes
15:47 < bridge> <Jupstar ✪> But u can upload it in my demo viewer, which is just ddnet xdd
17:17 < bridge> <jsaurusrex> does anybody know if tuning is saved in demos?
17:30 < bridge> <ryozuki> idk
17:30 < bridge> <ryozuki> i think its on the map
17:49 < bridge> <robyt3> The tunings are stored in demos but the correct tuning is currently not used when the demos are played back (#6138)
17:49 < bridge> <DDNet> https://github.com/ddnet/ddnet/issues/6138
19:59 < bridge> <ryozuki> ChillerDragon
19:59 < bridge> <ryozuki> https://cdn.discordapp.com/attachments/293493549758939136/1181308720802713630/image.png?ex=6580967a&is=656e217a&hm=203b2212c9cb12667dea855cf45e1c03e1a0fe439e9163d80a89bdde86e9a719&
19:59 < bridge> <ryozuki> for some reason the crypto market is rly bullish lately
19:59 < bridge> <ryozuki> this graph is bitcoin
20:47 < bridge> <_voxeldoesart> its gonna crash
22:01 < bridge> <cyberfighter> i just bought more land in the metaverse
22:17 < ChillerDragon> @ryozuki yeye its cycle again and halfing and institutional money flooding in due to spot ETFs being a thing now
22:18 < ChillerDragon> i planned to invest more coin into btc during the bear market but im broke af wat can i do
22:38 < ChillerDragon> halving*
22:38 < bridge> <cyberfighter> ah nice chiller has his max fps set to 666
22:38 < ChillerDragon> ye fuck god
22:39 < bridge> <Jupstar ✪> pls dont fuck me
22:39 < ChillerDragon> satan poggies
22:39 < ChillerDragon> complex jopsti
22:39 < bridge> <Jupstar ✪> :santatrollet: