08:31 <+ChillerDragon> well deen i guess someone has to prepare something for next advent that looks like aoc but is secretly ddnet issues 08:35 <@deen> Hohoho, please fix bug #1234 09:09 <+ChillerDragon> lmao 10:42 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785803585660125204/unknown.png 10:42 <+bridge> [ddnet] @deen https://github.com/ddnet/ddnet/pull/3387 fixes CI. deletes two tests (EXPECT_STREQs) that were brittle anyway and would have to be kept in sync with the code 10:42 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785803596238159904/unknown.png 10:43 <+bridge> [ddnet] i used the same answer 10:43 <+bridge> [ddnet] `acc=1532` 10:43 <+bridge> [ddnet] oh damn 10:43 <+bridge> [ddnet] you accidentally put `acc=` 10:43 <+bridge> [ddnet] i copied wrong 10:43 <+bridge> [ddnet] thanks to that i wasted 30 mins 10:43 <+bridge> [ddnet] staring at my screen 10:43 <+bridge> [ddnet] oof 10:43 <+bridge> [ddnet] :pepe_straight: 10:45 <+bridge> [ddnet] 10:51 <+bridge> [ddnet] I was trying to implement it in sed, but full programming in sed is more annoying than in perl 10:51 <+bridge> [ddnet] 😄 10:52 <+bridge> [ddnet] How to increment a number for example: https://www.gnu.org/software/sed/manual/sed.html#DOCF9 10:52 <+bridge> [ddnet] ouch 10:54 <+bridge> [ddnet] Will there be a webgl verwion of ddnet ? 10:54 <+bridge> [ddnet] there was one, but it got outdated 10:54 <+bridge> [ddnet] not if nobody works on it 10:54 <+bridge> [ddnet] and the servers don't run with websockets support atm 10:55 <+bridge> [ddnet] @mohsen7s https://github.com/eeeee/ddnet this is it 10:55 <+bridge> [ddnet] if you want to work on it, some people recently got it building again. the coolest thing would be a demo viewer in browser 10:59 <+bridge> [ddnet] @deen lol its 5 years old code 11:08 <+bridge> [ddnet] why do you support CMake 2.8? isn't that heavily deprecated? there's even no official documentation for versions below 3.0 11:10 <+bridge> [ddnet] @Comrade not sure if we actually build with it. but in theory for centos 6&7 11:10 <+bridge> [ddnet] here's the official docs for 2.8.12: https://cmake.org/cmake/help/v2.8.12/cmake.html 11:11 <+bridge> [ddnet] oh, didn't know that 11:11 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785810840560468008/unknown.png 11:12 <+bridge> [ddnet] CMakeLists.txt with more than 2000 lines 😦 11:29 <+bridge> [ddnet] > See older versions below. 11:29 <+bridge> [ddnet] yes, sorry for that 11:29 <+bridge> [ddnet] sorry for the 2000 lines I mean 11:30 <+bridge> [ddnet] i think CMake is like C++ - it's very hard to write clean code in it, especially when you try to maintain compatibility with legacy tools 11:31 <+bridge> [ddnet] but does it really need clean code? it'd be best if you didn't even need to touch it ^^ 11:31 <+bridge> [ddnet] it should be clean, otherwise we can go back to autotools 😄 11:31 <+bridge> [ddnet] no, autotools doesn't work because it has poor windows support 11:32 <+bridge> [ddnet] I didn't choose cmake because it was "clean" or whatever 11:32 <+bridge> [ddnet] but because it was popular and well-supported by tooling 11:32 <+bridge> [ddnet] yes, it's de facto standard build system for C++ 11:34 <+bridge> [ddnet] i think build scripts should be as clean as possible, so anyone can check what it actually does 11:34 <+bridge> [ddnet] with ninja and make you can print out what they actually do I think 11:34 <+bridge> [ddnet] `ninja -v` or `make VERBOSE=1` 11:35 <+bridge> [ddnet] helped me debug issues in the past 11:36 <+bridge> [ddnet] yes, but i mean checking it before actual building 11:36 <+bridge> [ddnet] for example, there are some configuration variables and you need to dig through that huge CMakeLists.txt to see what they do 11:38 <+bridge> [ddnet] hmm. my flippant answer would be: if you want to have configuration options, the cmakelists is going to be long. so why do you want to set options that are not documented in the readme? 11:40 <+bridge> [ddnet] aren't there some useful options that are not documented? 11:41 <+bridge> [ddnet] idk. right now it seems to me that you want conflicting things: a) short cmakelists.txt with b) many options 11:41 <+bridge> [ddnet] i think it's possible to have both 11:41 <+bridge> [ddnet] got an example? 11:41 <+bridge> [ddnet] of a "good" cmakelists? 11:41 <+bridge> [ddnet] if you remove all that code used by legacy version of CMake... 11:43 <+bridge> [ddnet] here's one of mine, but it's Windows-only project, so it's incomparable with DDNet 11:43 <+bridge> [ddnet] https://github.com/ccomrade/c1-launcher/blob/master/CMakeLists.txt 11:44 <+bridge> [ddnet] not sure if it's really a good one 😄 11:44 <+bridge> [ddnet] by my naive counting, this reduces the line count by 54 lines 11:44 <+bridge> [ddnet] dropping support for older cmake 11:44 <+bridge> [ddnet] 2660 → 2606 11:45 <+bridge> [ddnet] let's see 11:46 <+bridge> [ddnet] I removed all if(POLICY) branches that aren't executed and the if statements themselves, plus all if(CMAKE_VERSION) branches that do not match the current version, plus the if statements themselves 11:51 <+bridge> [ddnet] i think if you get rid all those variables holding list of C++ source files, it should reduce line count as well 11:51 <+bridge> [ddnet] in newer CMake you can sources to target on-the-fly with `target_sources` 11:51 <+bridge> [ddnet] in newer CMake you can add sources to target on-the-fly with `target_sources` 11:54 <+bridge> [ddnet] but you're right that line count can't reduced that much because it's just complex project with a lot of things 11:55 <+bridge> [ddnet] it's only the begging of CMakeLists.txt that looks so messy, the rest is quite readable 11:55 <+bridge> [ddnet] it's only the beginning of CMakeLists.txt that looks so messy, the rest is quite readable 11:56 <+bridge> [ddnet] ideally, there should be no functions in CMake, but it's not always possible 12:02 <+bridge> [ddnet] @heinrich5991 what about https://cmake.org/cmake/help/latest/module/FetchContent.html 12:03 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785823757243383838/unknown.png 12:04 <+bridge> [ddnet] that would drop support for debian, unfortunately @Ryozuki 12:04 <+bridge> [ddnet] Debian has CMake 3.13 12:04 <+bridge> [ddnet] https://packages.debian.org/buster/cmake 12:04 <+bridge> [ddnet] oh indeed, wow 12:05 <+bridge> [ddnet] why r we supporting 2.8? 12:06 <+bridge> [ddnet] https://discord.com/channels/252358080522747904/293493549758939136/785810450482724865 12:06 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785824702110105600/unknown.png 12:06 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/2085 12:06 <+bridge> [ddnet] i dont get why we want to support centos-7 12:07 <+bridge> [ddnet] this is a game we are talking about, u should expect to have a updated system 12:07 <+bridge> [ddnet] I guess the question is rather whether the dropped support gives us anything worthwhile in return 12:07 <+bridge> [ddnet] if not, we might as well support it 12:07 <+bridge> [ddnet] why 12:07 <+bridge> [ddnet] its probably only 1 or 2 people 12:07 <+bridge> [ddnet] using that 12:07 <+bridge> [ddnet] or maybe even 0 12:08 <+bridge> [ddnet] it seems CentOS 7 really has only CMake 2.8 12:08 <+bridge> [ddnet] what a shame 12:08 <+bridge> [ddnet] maintainability is a valid concern for dropping old version 12:08 <+bridge> [ddnet] s 12:08 <+bridge> [ddnet] but gaining nothing for dropping support doesn't seem sensible to me 12:08 <+bridge> [ddnet] https://geekylog.com/post/170938902714/install-cmake-3-in-centos-7 12:08 <+bridge> [ddnet] u can install cmake 3 on centos-7 12:09 <+bridge> [ddnet] dropping legacy code is valid reason i think, but it requires additional work 12:09 <+bridge> [ddnet] only if that legacy code is stopping you from doing anything, or being a pain to work with 12:09 <+bridge> [ddnet] https://centos.pkgs.org/7/okey-x86_64/cmake3-3.12.1-2.el7.x86_64.rpm.html 12:09 <+bridge> [ddnet] the pkg is called cmake3 12:09 <+bridge> [ddnet] dropping legacy code for the sake of dropping legacy code doesn't seem valid to me 12:09 <+bridge> [ddnet] @Ryozuki make a new survey which cmake versions are supported where and do a PR 12:10 <+bridge> [ddnet] https://github.com/ddnet/ddnet/pull/2085 12:10 <+bridge> [ddnet] EPEL seems to be some third-party repository 12:10 <+bridge> [ddnet] cmake3-3.17.3-3.el7.x86_64.rpm 12:11 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785825781296791582/unknown.png 12:11 <+bridge> [ddnet] official it says 12:11 <+bridge> [ddnet] > How do I install the extra repositories such as Fedora EPEL repo on a Red Hat Enterprise Linux server version 7.x or CentOS Linux server version 7.x? 12:11 <+bridge> [ddnet] i would say its common to use EPEL 12:11 <+bridge> [ddnet] in centos 12:11 <+bridge> [ddnet] I don't know anyone runnign centos, can't comment 12:11 <+bridge> [ddnet] same 12:11 <+bridge> [ddnet] but i would never run cmake 2.8 12:11 <+bridge> [ddnet] how can you say that it's common then? 12:11 <+bridge> [ddnet] because its what i would do 12:11 <+bridge> [ddnet] common sense 12:12 <+bridge> [ddnet] i always enable backports 12:12 <+bridge> [ddnet] in debian 12:12 <+bridge> [ddnet] I don't 12:17 <+bridge> [ddnet] no wonder companies like Adobe don't want to port their software to Linux when it's such a mess 😄 12:17 <+bridge> [ddnet] but proprietary software is bad anyway 12:36 <+ChillerDragon> +1 12:41 <+bridge> [ddnet] Not like windows is soooo much better. The only thing they do well is keeping forward compatibility 12:43 <+bridge> [ddnet] I have like 5 versions of msvcrt and 5 versions of vcr++. With 4 build configurations, so that's 40 runtimes any piece of code could be running on 12:44 <+ChillerDragon> macos masterrace 12:44 <+ChillerDragon> lul 12:44 <+bridge> [ddnet] The only reason adobe or any other company doesn't port to linux is MONEY. For profit corporations only care about maximizing shareholder profits 12:45 <+ChillerDragon> no adobe is just evil 12:45 <+ChillerDragon> good meme btw https://www.youtube.com/watch?v=158bJFTETRI 12:45 <+ChillerDragon> xd 12:45 <+bridge> [ddnet] yes, it's so sad that money controls everything 12:45 <+ChillerDragon> its only sad if u poor 12:45 <+bridge> [ddnet] 😄 12:46 <+bridge> [ddnet] macOS is indeed pretty good at backwards and forwards compatibility. They really have a great idea there with the has_feature. But the problem there is the framework compatibility shims 12:46 <+bridge> [ddnet] The frameworks behave differently depending on your deployment target 12:46 <+ChillerDragon> well my macbook had many struggles staying compatible with my i mobile devices lol 12:47 <+bridge> [ddnet] maintaining backward compatibility is a nice thing, but it has its drawbacks 12:47 <+bridge> [ddnet] just look at WinAPI 😄 12:47 <+ChillerDragon> just look at 0.6 12:47 <+bridge> [ddnet] https://docs.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-large_integer-r1 😄 12:47 <+bridge> [ddnet] Hard part is forward compatibility anyway 12:48 <+ChillerDragon> isnt rust claiming to have gud forward compability 12:48 <+bridge> [ddnet] Winapi is a sad state of affairs, idk why people enjoy it 12:48 <+ChillerDragon> because it has win in the name 12:48 <+bridge> [ddnet] Like everything about windows at it's core it's actually decent 12:49 <+bridge> [ddnet] E.g. the ntkernel is actually fairly well designed and stable 12:49 <+bridge> [ddnet] that's questionable - using UTF-16 everywhere internally is not so good idea i think 12:50 <+bridge> [ddnet] but it was designed more than 20 years ago, so we can't really blame it for that decision 12:50 <+ChillerDragon> \n\r 12:50 <+bridge> [ddnet] \r\n 😄 12:50 <+ChillerDragon> xd 12:50 <+ChillerDragon> see so complicated 12:50 <+bridge> [ddnet] that's another good example 12:50 <+ChillerDragon> already messed it up 12:50 <+bridge> [ddnet] yes 12:50 <+bridge> [ddnet] I agree a lot of the backwards compat can be dropped 12:51 <+ChillerDragon> only good thing was clippy 12:51 <+bridge> [ddnet] But that will create bugs, which will break the illusion that windows is stable 12:51 <+bridge> [ddnet] So they instead have layers upon layers of compatibility 12:51 <+bridge> [ddnet] Did you know that Windows doesn't actually even use UTF16? 12:52 <+bridge> [ddnet] really? 12:52 <+bridge> [ddnet] :justatest: 12:52 <+bridge> [ddnet] It uses a non compliant mess internally to support their "codepages" 12:53 <+bridge> [ddnet] Whenever I hear the word codepage I feel like we are operating a ww2 submarine 12:53 <+bridge> [ddnet] isn't so called ANSI string using some codepage always converted to UTF-16 when you call some WinAPI function? 12:53 <+bridge> [ddnet] https://devblogs.microsoft.com/commandline/windows-command-line-unicode-and-utf-8-output-text-buffer/ 12:53 <+bridge> [ddnet] 12:53 <+bridge> [ddnet] I think I linked this here before, this explains the history of this mess rather well 12:53 <+bridge> [ddnet] it uses "editions" for that 12:53 <+ChillerDragon> ye 12:54 <+ChillerDragon> that thing 12:54 <+bridge> [ddnet] and modern rust compilers can compile old editions i think 12:54 <+bridge> [ddnet] https://doc.rust-lang.org/edition-guide/editions/index.html 12:54 <+ChillerDragon> sounded cool 12:54 <+bridge> [ddnet] I'm not sure I like either solution for compilers 12:54 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785836806298009640/unknown.png 12:54 <+bridge> [ddnet] @heinrich5991 I still don't get what's up with your alternative fixes for alloc of 0 and why there are so many changes. Couldn 12:55 <+bridge> [ddnet] not sounded, sounds* 12:55 <+ChillerDragon> well i heard it a while ago 12:55 <+bridge> [ddnet] rust can have fast dev thanks to this 12:55 <+bridge> [ddnet] I don't mind letting old code only be compiled by old compilers, but what about compiler bugs? 12:55 <+bridge> [ddnet] @heinrich5991 I still don't get what's up with your alternative fixes for alloc of 0 and why there are so many changes. Couldn't we just keep the old commit and do 12:55 <+bridge> [ddnet] ``` 12:55 <+bridge> [ddnet] --- a/src/game/editor/io.cpp 12:55 <+bridge> [ddnet] +++ b/src/game/editor/io.cpp 12:55 <+bridge> [ddnet] @@ -560,6 +560,10 @@ int CEditorMap::Save(class IStorage *pStorage, const char *pFileName) 12:55 <+bridge> [ddnet] df.AddItem(MAPITEMTYPE_ENVPOINTS, 0, TotalSize, pPoints); 12:55 <+bridge> [ddnet] free(pPoints); 12:55 <+bridge> [ddnet] } 12:55 <+bridge> [ddnet] + else 12:55 <+bridge> [ddnet] + { 12:55 <+bridge> [ddnet] + df.AddItem(MAPITEMTYPE_ENVPOINTS, 0, 0, NULL); 12:55 <+bridge> [ddnet] + } 12:55 <+bridge> [ddnet] 12:55 <+bridge> [ddnet] // finish the data file 12:56 <+bridge> [ddnet] df.Finish(); 12:56 <+bridge> [ddnet] ``` 12:56 <+ChillerDragon> yeee 12:56 <+bridge> [ddnet] a modern rust compiler can compile old editions and maybe even fix bugs 12:56 <+bridge> [ddnet] i dont know much tho 12:56 <+ChillerDragon> sounds fun and all but ``$ [ "${BASH_VERSINFO:-0}" -ge 4 ] && echo "bash supports associative arrays"`` is still supirior ofc 12:56 <+bridge> [ddnet] But that means you need to carry around legacy cruft and even emulate bugs sometimes 12:56 <+bridge> [ddnet] idk 12:56 <+bridge> [ddnet] im sure they have this well thought 12:57 <+ChillerDragon> rust fanboi 12:57 <+bridge> [ddnet] > Just to be clear: most features will be available on all editions. People using any edition of Rust will continue to see improvements as new stable releases are made. In some cases however, mainly when new keywords are added, but sometimes for other reasons, there may be new features that are only available in later editions. You only need to upgrade if you want to take advantage of such features. 12:57 <+bridge> [ddnet] All compilers do it. Clang and gcc need to keep support for almost 2 decades of c and C++ standards 12:57 <+ChillerDragon> @fokkonaut 12:58 <+bridge> [ddnet] Ah Rust seems to gate features, that might be a better compromise 12:59 <+bridge> [ddnet] @Learath2 Windows command line has to deal with those codepages for sure, but when your code calls, for example, CreateFileA, it internally converts your string to UTF-16 and forwards it to CreateFileW that does the actual syscall, so everything is in UTF-16 internally 13:00 <+bridge> [ddnet] Afaik its ucs2 for W too 13:00 <+bridge> [ddnet] well, yes, it's not real UTF-16 probably 😄 13:00 <+bridge> [ddnet] Fixed width 13:00 <+bridge> [ddnet] exactly 13:01 <+bridge> [ddnet] `sizeof (wchar_t)` returns 2 on Windows while it returns 4 everywhere else 😄 13:01 <+bridge> [ddnet] what a mess 13:02 <+bridge> [ddnet] My mantra is, if you are using a wchar, you are probably doing sth wrong 13:02 <+bridge> [ddnet] good mantra 😄 13:02 <+bridge> [ddnet] UTF-8 for the win 13:02 <+bridge> [ddnet] my mantra is dont use windows 13:02 <+bridge> [ddnet] 13:03 <+bridge> [ddnet] If only we could get mainstream adoption of linux :P 13:03 <+bridge> [ddnet] Won't happen without the flatpak bloar gettinf much much more popular 13:03 <+bridge> [ddnet] oh no 😄 13:03 <+bridge> [ddnet] Bloat* 13:04 <+bridge> [ddnet] isn't Flatpak basically reinventing Windows with additional security due to sandboxing? 13:05 <+bridge> [ddnet] Very similar, it packs every dependency though so it's even larger 13:06 <+bridge> [ddnet] Windows apps have to carry most of its dependencies as well 13:06 <+bridge> [ddnet] Critically windows apps dont carry msvcrt 13:07 <+bridge> [ddnet] Flatpaks carry libc iirc 13:08 <+bridge> [ddnet] Oh, btw has anyone seen qubesos? 13:09 <+bridge> [ddnet] Sounds like a great idea if you have a threadripper or a xeon workstation with many cores 13:09 <+bridge> [ddnet] Especially since kvm is blazing fast 13:10 <+bridge> [ddnet] @timakro nice bible u writing there 13:10 <+bridge> [ddnet] 👀 13:10 <+bridge> [ddnet] @Learath2 it does full virtualization, right? 13:11 <+bridge> [ddnet] @Comrade yep, sounds like the best attempt at privacy so far 13:11 <+bridge> [ddnet] i think it's just a waste of performance because containers can do the same with lower performance impact (shared kernel ettc) 13:11 <+bridge> [ddnet] I like apples approach on iOS too, they really know how to do sandboxes well 13:11 <+bridge> [ddnet] i think it's just a waste of performance because containers can do the same with lower performance impact (shared kernel etc) 13:12 <+bridge> [ddnet] Problem with containers is that they are just not as safe 13:12 <+bridge> [ddnet] even full virtualization is not safe 😄 13:12 <+bridge> [ddnet] VM escape is real thing 13:13 <+bridge> [ddnet] but yes, containers are slightly safe always 13:13 <+bridge> [ddnet] Well ofc, but find a bug in kvm and you'll be compromising a whole lot of hosters infrastructures 13:13 <+bridge> [ddnet] *slightly less safe 13:13 <+bridge> [ddnet] Containers are much better nowadays though 13:13 <+bridge> [ddnet] docker and its loads of gb per container 13:14 <+bridge> [ddnet] Docker is fail 😄 13:14 <+bridge> [ddnet] God I hate docker 13:14 <+bridge> [ddnet] systemd-nspawn is the way 13:14 <+bridge> [ddnet] (no flame war today) 😄 13:15 <+bridge> [ddnet] LXC itself is nice, I wish someone else would implement the interface 13:16 <+bridge> [ddnet] When the rust club is here I might as well ask a question. For todays advent puzzle I have a program counter variable `pc` which should probably be of type `usize` because it indexes the vector of instructions and I compare it to the length of the vector of instructions. But I want to add an`i32` to `pc` which can be negative. I don't want to fail silently on conversions, thus I can't use `as`. How should I solve this? I have 2 solutions in 13:16 <+bridge> [ddnet] 1. When adding to `pc` convert `pc` to `i32` first and then the result back to `usize` like this `pc = usize::try_from(i32::try_from(pc).unwrap() + x).unwrap()` 13:16 <+bridge> [ddnet] 2. Make `pc` an `i32` instead and everywhere were I need `usize` write`usize::try_from(pc).unwrap()` 13:16 <+bridge> [ddnet] declare it as i32 13:16 <+bridge> [ddnet] and cast it 13:16 <+bridge> [ddnet] pc as usize 13:16 <+bridge> [ddnet] when indexing 13:16 <+bridge> [ddnet] i do that 13:17 <+bridge> [ddnet] `pc as usize` 13:17 <+bridge> [ddnet] ah 13:17 <+bridge> [ddnet] ah 13:17 <+bridge> [ddnet] u dont want as 13:17 <+bridge> [ddnet] but i think its not a problem in this puzzle 13:18 <+bridge> [ddnet] l 13:18 <+bridge> [ddnet] o 13:18 <+bridge> [ddnet] l 13:18 <+bridge> [ddnet] ? 13:18 <+bridge> [ddnet] lol 13:19 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785842872100192266/unknown.png 13:19 <+bridge> [ddnet] 13:19 <+bridge> [ddnet] yeah whatever I should do that 13:20 <+bridge> [ddnet] but why does rust make the unsafe option the nice and short one to write and for TryInto you even need to import stuff first 13:21 <+bridge> [ddnet] well u need to import that trait 13:22 <+bridge> [ddnet] put it in prelude 13:22 <+bridge> [ddnet] i dont think its common enough 13:28 <+bridge> [ddnet] ``` 13:28 <+bridge> [ddnet] for i in &mut instr { 13:28 <+bridge> [ddnet] if let Instr::ACC(a) = *i { 13:28 <+bridge> [ddnet] *i = Instr::NOP(a); 13:28 <+bridge> [ddnet] } else if let Instr::NOP(a) = *i { 13:28 <+bridge> [ddnet] *i = Instr::ACC(a); 13:28 <+bridge> [ddnet] } 13:28 <+bridge> [ddnet] if let SimResult::Term(acc) = simulate(&instr) { 13:28 <+bridge> [ddnet] println!("Found solution, accumulator is {}", acc); 13:28 <+bridge> [ddnet] } 13:28 <+bridge> [ddnet] } 13:28 <+bridge> [ddnet] ``` 13:28 <+bridge> [ddnet] ``` 13:28 <+bridge> [ddnet] error[E0502]: cannot borrow `instr` as immutable because it is also borrowed as mutable 13:28 <+bridge> [ddnet] --> src/main.rs:62:48 13:28 <+bridge> [ddnet] | 13:28 <+bridge> [ddnet] 56 | for i in &mut instr { 13:28 <+bridge> [ddnet] | ---------- 13:28 <+bridge> [ddnet] | | 13:28 <+bridge> [ddnet] | mutable borrow occurs here 13:28 <+bridge> [ddnet] | mutable borrow later used here 13:28 <+bridge> [ddnet] ... 13:28 <+bridge> [ddnet] 62 | if let SimResult::Term(acc) = simulate(&instr) { 13:28 <+bridge> [ddnet] | ^^^^^^ immutable borrow occurs here 13:28 <+bridge> [ddnet] ``` 13:29 <+bridge> [ddnet] I never really understood why those struct borrow rules. Thread safety I guess, but I have no threads ... 13:29 <+bridge> [ddnet] I never really understood why those strict borrow rules. Thread safety I guess, but I have no threads ... 13:29 <+bridge> [ddnet] wats instr 13:29 <+bridge> [ddnet] a `Vec` 13:30 <+bridge> [ddnet] try instr.iter() 13:30 <+bridge> [ddnet] and put the &mut in the i 13:30 <+bridge> [ddnet] iirc 13:30 <+bridge> [ddnet] ah 13:30 <+bridge> [ddnet] @time 13:30 <+bridge> [ddnet] @timakro iter_mut() 13:31 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785845933366706206/unknown.png 13:31 <+bridge> [ddnet] It's the same 13:31 <+bridge> [ddnet] remove the & 13:31 <+bridge> [ddnet] in the simulate 13:31 <+bridge> [ddnet] hmm 13:31 <+bridge> [ddnet] I want to borrow though 13:31 <+bridge> [ddnet] try it 13:32 <+bridge> [ddnet] It takes &Instr? 13:32 <+bridge> [ddnet] sry 13:32 <+bridge> [ddnet] &Vec 13:32 <+bridge> [ddnet] I can ofc iterate over the indices 13:32 <+bridge> [ddnet] I doubt I'll ever be able to write rust and be sure that it compiles 13:33 <+bridge> [ddnet] It's more like trial and error 13:33 <+bridge> [ddnet] u just dont know well enough how the borrow stuff works 13:33 <+bridge> [ddnet] can u send me the code u have 13:33 <+bridge> [ddnet] I guess spoiled by other languages, I'll never get used to those borrow restrictions 13:34 <+bridge> [ddnet] It's not that I can't make it work, just thinking of the best/idiomatic solution 13:34 <+bridge> [ddnet] well if u dont have the will to do so i guess 13:34 <+bridge> [ddnet] yeah and i want to try to show u 13:36 <+bridge> [ddnet] i guess this is what u want to achieve right 13:36 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785847261376151602/unknown.png 13:36 <+bridge> [ddnet] @Ryozuki https://termbin.com/bj9l 13:43 <+bridge> [ddnet] Ok, I just iterated over the indices now and solved the puzzle 🥳 13:43 <+bridge> [ddnet] But I still want to understand the purpose of the borrow rules. That would be the only way for me to learn them 13:44 <+bridge> [ddnet] I never got behind the purpose really 13:44 <+bridge> [ddnet] @timakro 13:44 <+bridge> [ddnet] https://cdn.discordapp.com/attachments/293493549758939136/785849260594692116/unknown.png 13:44 <+bridge> [ddnet] yeah iterating with indices and using get_mut is the best choice here 13:45 <+bridge> [ddnet] because I need to swap it back later anyways I'm just indexing now 13:46 <+bridge> [ddnet] ``` 13:46 <+bridge> [ddnet] for i in 0..instr.len() { 13:46 <+bridge> [ddnet] if let Instr::JMP(a) = instr[i] { 13:46 <+bridge> [ddnet] instr[i] = Instr::NOP(a); 13:46 <+bridge> [ddnet] } else if let Instr::NOP(a) = instr[i] { 13:46 <+bridge> [ddnet] instr[i] = Instr::JMP(a); 13:46 <+bridge> [ddnet] } 13:46 <+bridge> [ddnet] if let SimResult::Term(acc) = simulate(&instr) { 13:46 <+bridge> [ddnet] println!("Found solution, accumulator is {}", acc); 13:46 <+bridge> [ddnet] } 13:46 <+bridge> [ddnet] if let Instr::JMP(a) = instr[i] { 13:46 <+bridge> [ddnet] instr[i] = Instr::NOP(a); 13:46 <+bridge> [ddnet] } else if let Instr::NOP(a) = instr[i] { 13:46 <+bridge> [ddnet] instr[i] = Instr::JMP(a); 13:46 <+bridge> [ddnet] } 13:46 <+bridge> [ddnet] } 13:46 <+bridge> [ddnet] ``` 13:47 <+bridge> [ddnet] @timakro maybe reading this helps https://rust-unofficial.github.io/too-many-lists/index.html 13:47 <+bridge> [ddnet] idk why i prefer using .get instead of indexing directly 13:48 <+bridge> [ddnet] u can handle the error 13:48 <+bridge> [ddnet] Well, this example from the book really blew my mind 13:48 <+bridge> [ddnet] ``` 13:48 <+bridge> [ddnet] let mut v = vec![1, 2, 3, 4, 5]; 13:48 <+bridge> [ddnet] 13:48 <+bridge> [ddnet] let first = &v[0]; 13:48 <+bridge> [ddnet] 13:48 <+bridge> [ddnet] v.push(6); 13:48 <+bridge> [ddnet] 13:48 <+bridge> [ddnet] println!("The first element is: {}", first); 13:48 <+bridge> [ddnet] ``` 13:48 <+bridge> [ddnet] I was like why doesn't it compile. But the explanation is 13:48 <+bridge> [ddnet] > The code in Listing 8-7 might look like it should work: why should a reference to the first element care about what changes at the end of the vector? This error is due to the way vectors work: adding a new element onto the end of the vector might require allocating new memory and copying the old elements to the new space, if there isn’t enough room to put all the elements next to each other where the vector currently is. In that case, t 13:48 <+bridge> [ddnet] That's awesome. 13:48 <+bridge> [ddnet] 13:48 <+bridge> [ddnet] But in my situation above I don't see a problem. Sure the scope of the loop can mutate the Vector, but it can't do that while the function is running, because well, the function is running 13:49 <+bridge> [ddnet] this is why rust isnt a easy language 13:49 <+bridge> [ddnet] i also fighted against the borrow checker 13:49 <+bridge> [ddnet] xdd 13:49 <+bridge> [ddnet] and sometimes still do 13:49 <+bridge> [ddnet] but i still like it 13:52 <+bridge> [ddnet] https://doc.rust-lang.org/nomicon/hrtb.html 13:52 <+bridge> [ddnet] i once struggled with this xd 14:06 <+bridge> [ddnet] Day 8 was fun 14:07 <+bridge> [ddnet] yeah 14:07 <+bridge> [ddnet] but too simple 14:09 <+bridge> [ddnet] Well last year you expanded quite a bit on your "computer" over the days, I guess it'll be like that again 14:09 <+bridge> [ddnet] well this is not our computer 14:09 <+bridge> [ddnet] its a kid gameboy 14:09 <+bridge> [ddnet] i doubt we will be with the kid longer 14:09 <+bridge> [ddnet] xd 14:09 <+bridge> [ddnet] we might snatch it 😛 14:10 <+bridge> [ddnet] @timakro you can opt into "single threaded, etc." by wrapping your copyable type in a `Cell` 14:10 <+bridge> [ddnet] oh 14:10 <+bridge> [ddnet] I don't quite like my solution today but didn't really feel like cleaning it up 14:10 <+bridge> [ddnet] it has `set` and `get` which only take a constant reference 14:10 <+bridge> [ddnet] i should look more into Cell 14:11 <+bridge> [ddnet] til 14:11 <+bridge> [ddnet] @timakro my diff is very small to the original code, before deen changed it 14:12 <+bridge> [ddnet] Oh btw @heinrich5991 we can build with cmake 2.8 there were two broken things and I fixed them 😛 14:12 <+bridge> [ddnet] oh interesting 14:13 <+bridge> [ddnet] https://github.com/ddnet/ddnet/compare/a4f13ed4a85a4a2b2e901342a9f4341c779e883c%5E...e805e42a9469c4c3bb47f87903d224469db06c85#diff-472b2e75e6cbd3e80ec9ec50e60d8b0dc61c4b9aa81f67ae395cc5d375875a0eR273 14:13 <+bridge> [ddnet] https://github.com/ddnet/ddnet/compare/a4f13ed4a85a4a2b2e901342a9f4341c779e883c%5E...e805e42a9469c4c3bb47f87903d224469db06c85#diff-472b2e75e6cbd3e80ec9ec50e60d8b0dc61c4b9aa81f67ae395cc5d375875a0eR539 14:13 <+bridge> [ddnet] these are the only two lines that I changed 14:13 <+bridge> [ddnet] @heinrich5991 Oh, didn't see that's the point, I agree then 14:13 <+bridge> [ddnet] @heinrich5991 why cell and not refcell? 14:13 <+bridge> [ddnet] @Ryozuki because it plays nicer with copyable types 14:13 <+bridge> [ddnet] no panicking functions 14:13 <+bridge> [ddnet] > Shareable mutable containers exist to permit mutability in a controlled manner, even in the presence of aliasing. Both Cell and RefCell allow doing this in a single-threaded way. However, neither Cell nor RefCell are thread safe (they do not implement Sync). If you need to do aliasing and mutation between multiple threads it is possible to use Mutex, RwLock or atomic types. 14:13 <+bridge> [ddnet] nice 14:14 <+bridge> [ddnet] so this is what cell stuff is for 14:14 <+bridge> [ddnet] very useful 14:14 <+bridge> [ddnet] it's a bit annoying to use, because it doesn't has first-class language support 14:16 <+bridge> [ddnet] btw, you never need `x.iter()` or `x.iter_mut()` in the parameter of a for loop @Ryozuki. use `&x` or `&mut x` instead 14:16 <+bridge> [ddnet] why not 14:16 <+bridge> [ddnet] is there a difference 14:17 <+bridge> [ddnet] no difference, but I think the rust style is using the latter 14:17 <+bridge> [ddnet]