IRC logs for #openttd on OFTC at 2024-11-07
β΄ go to previous day
00:09:37 <_glx_> consist flags vs vehicle flags π
00:19:42 <peter1139> They share the same storage.
00:20:05 <peter1139> They don't in my consist-split patch, which is how I noticed it.
01:24:40 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
02:00:53 *** Wormnest has joined #openttd
02:07:35 *** Flygon has quit IRC (Read error: Connection reset by peer)
02:53:35 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
03:05:11 *** Wormnest has joined #openttd
03:31:23 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** Hirundo has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** Osai has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** Hazzard has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** Yexo has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** V453000 has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** avdg has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** Ammler has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** XeryusTC has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** planetmaker has quit IRC (Ping timeout: 480 seconds)
03:35:58 *** tneo has quit IRC (Ping timeout: 480 seconds)
03:37:08 *** Webster has quit IRC (Ping timeout: 480 seconds)
03:37:48 *** fonsinchen has quit IRC (Ping timeout: 480 seconds)
03:37:48 *** Guest3792 has quit IRC (Ping timeout: 480 seconds)
03:37:48 *** Terkhen has quit IRC (Ping timeout: 480 seconds)
03:37:48 *** SmatZ has quit IRC (Ping timeout: 480 seconds)
03:45:29 *** planetmaker has joined #openttd
03:45:29 *** fonsinchen has joined #openttd
03:45:30 *** ChanServ sets mode: +o planetmaker
03:45:42 *** Hazzard has joined #openttd
03:46:59 *** Hirundo has joined #openttd
03:47:49 *** ^Spike^ has joined #openttd
03:48:16 *** ^Spike^ is now known as Guest8696
03:48:29 *** Terkhen has joined #openttd
03:48:29 *** V453000 has joined #openttd
03:48:29 *** XeryusTC has joined #openttd
03:48:29 *** ChanServ sets mode: +o Terkhen
04:37:13 *** TinoDidriksen has quit IRC (Ping timeout: 480 seconds)
04:43:51 *** TinoDidriksen has joined #openttd
04:44:27 *** TinoDidriksen is now known as Guest8703
04:46:05 <DorpsGek> - Update: Translations from eints (by translators)
05:51:34 *** Flygon has quit IRC (Read error: Connection reset by peer)
06:23:19 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:35:38 *** Guest8703 is now known as TinoDidriksen
08:18:05 *** Extrems has joined #openttd
08:29:35 *** HerzogDeXtEr has joined #openttd
08:47:14 <peter1138> Its not what you think
09:11:05 <mnhebi> Aww you gave me hope we'd get shunting and broken couplers breakdowns!
10:10:49 <peter1139> Well, another set of figures that doesn't add up.
10:29:38 <xarick> is there a Notepad for ubuntu?
10:29:59 <xarick> can i edit files with vscode?
10:31:35 <xarick> "sudo vi /etc/default/grub" gives me a brain aneurysm
10:34:39 <peter1138> More than JGRPP though.
11:12:22 <LordAro> i am very deliberately not going to ask why on earth you would be editing grub
11:14:38 <LordAro> xarick: gedit is also a commonly used "basic" text editor
11:29:40 <peter1138> JGRPP is about half again, less than 6ms average.
11:30:07 <peter1138> We've got the non-flooding now.
11:30:31 <peter1138> My patch is animated-tile changing, but it's not the same as JGRPP.
11:47:10 *** D-HUND is now known as debdog
11:58:44 <peter1138> It doesn't automatically update, but the updates are forced.
11:59:09 <peter1138> It's easier to just use the website. It's the same thing really.
12:07:34 <xarick> where do I see the return value?
12:08:40 <xarick> visual studio shows me the value it returned with
12:08:49 <xarick> but visual code is different...
12:18:54 <peter1138> It hasn't returned yet.
12:26:57 <xarick> well.. nope it returns and doesn't tell me what it did
12:31:42 <xarick> ah, it's 1333703 if I'm understanding this
12:32:04 <xarick> so very different than 7803334803604142689
12:32:16 <xarick> I don't understand why
12:34:14 <merni> how can you compare hash values across different OSs like that
12:35:29 <merni> it might be different even between different runs
13:16:07 *** k-man has quit IRC (Ping timeout: 480 seconds)
13:19:03 <peter1138> More non-code-change merges \o/
13:42:28 <peter1138> Foiled by unit tests.
13:44:26 <xarick> so the hash is exactly the tile index?
13:45:13 <kuhnovic> Depends on the hash function being used
13:45:19 <peter1138> Should I just remove the unit test...
13:56:15 <peter1138> Okay, I removed the unit tests but the unit tester still fails on them.
14:10:20 <xarick> visual studio does a prime number codification thingy of my hash...
14:10:38 <xarick> visual code does just take it
14:20:15 <peter1138> VS Code is just a text editor.
14:20:49 <peter1138> Whatever your compilers are doing is nothing to do with VS Code.
14:21:19 <peter1138> (Visual Studio is also just an editor, with a bundled compiler)
14:21:49 <merni> Plus, looking at exact numerical values of hashes is not very useful and implementation-dependent
14:26:30 *** k-man has quit IRC (Ping timeout: 480 seconds)
14:26:30 *** k-man_ is now known as k-man
14:29:26 <peter1138> There's no reason to believe that "using the same hash value" across platforms will mean that the implementation using that hash will behave the same across platforms.
14:46:54 <peter1138> Under 10 seconds using a std::vector for the list of marks.
14:53:14 *** squirejames has joined #openttd
14:53:14 <squirejames> peter1138: Had to do an uninstall and reinstall of Discord yesterday because it "got stuck" some time ago, and this is on Windows. Discord is really becoming poo
15:01:51 <xarick> nice, we got somewhere at last
15:02:02 <xarick> still using unordered_set
15:02:14 <xarick> with a temp vector for sorting
15:15:32 <xarick> anyone willing to investigate why std::set is slow on windows?
15:18:35 <LordAro> have you tried googling "std::set slow on windows" ?
15:19:57 <exceptik> might also be msvc slow, not just windows slow
15:40:34 <xarick> downloading clang is 2 GB π¦
15:42:43 <truebrain> I am like 90% sure I typed a reply to #12
15:42:48 <truebrain> but ... I don't see it π
15:56:13 <peter1138> Correction, clang does not like msvc parameters.
16:11:03 *** Wormnest has joined #openttd
16:28:20 <exceptik> blaming tools for failures...
16:32:18 <peter1138> JGRPP already replaced the set and list with non-standard structures.
17:05:59 <_glx_> maybe your cmake settings are wrong
17:07:54 <_glx_> and looking at logs it's indeed the reason, ```
17:07:54 <_glx_> 15:48:28:827 1> [CMake] -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang.exe
17:07:54 <_glx_> 15:48:28:900 1> [CMake] -- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/Llvm/x64/bin/clang.exe - broken```
17:08:05 <_glx_> it should use clang-cl.exe
17:09:35 <_glx_> notice how CXX compiler was correct in `15:48:25:594 1> [CMake] -- Check for working CXX compiler: C:/PROGRAM FILES/MICROSOFT VISUAL STUDIO/2022/COMMUNITY/VC/Tools/Llvm/x64/bin/clang-cl.exe - skipped` (skipped means known compiler, not need to check capabilities)
17:14:30 <xarick> okay gonna reinstall clang
17:31:37 <peter1138> It needs to be using `clang-cl.exe`, not `clang.exe`
17:35:10 <xarick> line 276 uses clang-cl.exe
17:35:28 <xarick> line 312 uses clang.exe
17:36:20 <xarick> one is CXX compiler the other is C compiler
17:42:53 <_glx_> I have ``` "cacheVariables": {
17:42:53 <_glx_> "CMAKE_C_COMPILER": "clang-cl.exe",
17:42:53 <_glx_> "CMAKE_CXX_COMPILER": "clang-cl.exe"
17:42:53 <_glx_> ``` in my cmake preset for clang
17:47:29 <xarick> wow, it worked now and i have no idea why
17:48:06 <xarick> it's generating a lot of warnings
17:49:27 <xarick> > E:\OpenTTD Visual Studio\SamuXarick\OpenTTD\out\build\x64-Clang-Release\clang-cl : warning : argument unused during compilation: '/Zc:preprocessor' [-Wunused-command-line-argument]
18:07:38 <_glx_> different implementation for std lib
18:12:23 <xarick> how do i fix the /Zc:preprocessor ?
18:15:47 <_glx_> it doesn't matter, but it should be somwhere in CompileFlags/cmake
18:34:28 <xarick> linux still beating windows
18:46:33 <peter1138> Oh, it doesn't actually match the other graphs despite being flipped. Oh well.
18:47:12 <peter1138> The other graphs start at the left, being even more incomprehensible π
18:48:12 <peter1138> Either way, the correct solution is for all the graphs to use the same logic, not reimplement it.
18:48:34 <LordAro> best file an issue before you forget about it :)
18:49:51 <_jgr_> Newer stuff is on the right in all the graphs
18:50:14 <_jgr_> So the right hand side should have a larger value for t
18:50:55 <_jgr_> Industry production doesn't have a length as it's effectively pre-filled with 0s
18:51:40 <peter1138> I'm referring to this.
18:52:17 <peter1138> It's a bit nonsensical.
18:52:49 <peter1138> Sure, one is economy quarters and one is economy months, so the time period is different as well.
18:54:36 <peter1138> On the top graph, the current data point could be 3, 6, 9, etc.
18:54:48 <peter1138> Once it's filled up the current data point is always 72.
19:48:24 <xarick> intellisense doesn't work for clang?
19:59:22 <_glx_> xarick: It does, but some stuff needs to be set in the preset, will paste when I'm back in front of computer
20:09:46 <_glx_> "microsoft.com/VisualStudioSettings/CMake/1.0": {
20:09:46 <_glx_> "intelliSenseMode": "windows-clang-x64"
20:11:55 <peter1138> Why even have a parameter for it?
20:13:05 <Rubidium> because it's a choice to use it incorrectly!
20:18:15 <peter1138> I wonder if that's replying to me or is about Xarick π
20:48:30 <_glx_> I'm using CMakePresets.json
20:58:03 <xarick> maybe a stupid question: how are std::unordered_set ordered? will push_backs always append to the end? or it is gonna be completely shuffled?
20:59:18 <xarick> guess i'll check myself
21:00:58 *** tokai|noir has joined #openttd
21:00:58 *** ChanServ sets mode: +v tokai|noir
21:02:54 <xarick> oh, it's completely random π¦
21:04:02 <_glx_> it's ordered by the hash
21:04:50 <_glx_> "Internally, the elements are not sorted in any particular order, but organized into buckets. Which bucket an element is placed into depends entirely on the hash of its value. This allows fast access to individual elements, since once a hash is computed, it refers to the exact bucket the element is placed into. "
21:06:23 <_glx_> well there's no real ordering, but hash affects it
21:07:48 *** tokai has quit IRC (Ping timeout: 480 seconds)
21:23:07 <xarick> thinking again... I want a container that keeps items ordered by insertion and with fast finding for items in it. I won't be removing items from it. It's not std::set, and it's not std::unordered_set and it's not std::vector due to being slow at finding
21:28:35 <exceptik> at this point, make your own
21:29:20 <peter1138> Do I just PR at this point to put Xarick's misery to bed?
21:33:23 <andythenorth> or finish my cargo classes docs thing π
21:36:17 <peter1138> Inserting elements into a vector is slow, and yet this is still similar performance to the std::unordered_set version.
21:36:54 <peter1138> Probably the btree thing that JGRPP does is faster but we haven't used those 3rdparty containers.
21:37:42 <xarick> thanks, gonna test it here
21:39:18 <xarick> Copilot came up with this :p
21:42:26 <_glx_> peter1138: it's basically a sorted vector of unique values π
21:43:03 <peter1138> Sorting it means you can do a binary search, which is what std::lower_bound does.
21:43:28 <peter1138> (But it's sorted because it's using std::lower_bound...)
21:43:49 <_glx_> and it's of course faster than using find() on an unsorted vector
21:44:15 <_glx_> unless the value is near the end
21:45:04 <xarick> i've seen it sized 500 at times
21:45:05 <peter1138> If it's near then end then you would have had to search most of the list.
21:46:14 <peter1138> The vector can be static, and then cleared between runs. But I tested that and the difference was inconclusive. Margin-of-error type stuff.
21:48:45 <_glx_> yeah vector allocation is not the slowing part, insertion in middle of vector is costly
21:53:01 <_glx_> and it all depends on the river direction in the end
21:54:31 <peter1138> I'd like to be able to visualise which tiles it is checking in order, but... not yet π
22:00:08 <xarick> wondering if deque could be eliminated, i have a weird plan
22:01:46 <xarick> but maybe the lower_bound won't help
22:02:54 <peter1138> The queue needs it to be unsorted.
22:02:59 <xarick> if the deque doesn't pop the items, it will contain the same stuff as the vector
22:03:05 <peter1138> You can use a vector that only appends, and manually track where you are.
22:03:19 <peter1138> But at that point... that's what a deque does.
22:04:39 <peter1138> Okay one time the insert had to move 9281 items. that's nearly 40KiB.
22:06:19 <peter1138> Still, all within my L1 cache, just about.
22:10:02 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:10:48 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:12:12 <andythenorth> do have an L1 cache?
22:12:18 <andythenorth> maybe I could get a USB-C one?
22:19:13 <xarick> gonna check what times i get there
22:22:40 *** Wormnest has quit IRC (Quit: Leaving)
22:30:26 <peter1138> allegro... what on earth have you done to that poor thing.
22:32:32 <peter1138> One of the optional drivers that was created for 1 weird platform that didn't have SDL support at the time.
22:36:43 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:49:41 <xarick> testing a single deque
23:00:02 <xarick> how do i get the next iterator lower_bound
23:00:23 <xarick> not sure im making myself clear π¦
23:10:09 <xarick> i can't make it happen
23:11:10 <xarick> there is an iterator i want to increment and then there's items being added to the same vector
23:12:08 <xarick> when an item is added, i can't get to the next item π¦
23:13:00 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:24:11 <xarick> i don't think such container exists π¦
23:43:40 <peter1138> If it's a vector you can just use the index instead.
continue to next day β΅