IRC logs for #openttd on OFTC at 2024-05-02
⏴ go to previous day
00:58:32 *** tokai|noir has joined #openttd
00:58:32 *** ChanServ sets mode: +v tokai|noir
01:05:10 *** tokai has quit IRC (Ping timeout: 480 seconds)
01:46:16 *** Wormnest has quit IRC (Quit: Leaving)
02:19:50 *** gnu_jj_ has joined #openttd
02:23:25 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
02:29:16 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:41:58 <DorpsGek> - Update: Translations from eints (by translators)
06:52:59 *** Ox7C5 has quit IRC (Quit: Lost terminal)
07:12:39 <peter1138> Hmm, do I pull out a Pi 3B to install a 64 bit OS to test...
07:41:38 <_glx_> Cmake logs could be nice too, to know where and how regression fails
08:36:32 <silent_tempest> I need to spend some time writing a PR description but the font picker I've been working is done finally. 🙂
08:40:05 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
08:54:23 <peter1138> Huh, I can't reply to one of the comments...
08:55:05 <LordAro> yeah, it looks duplicated for me
09:07:25 <peter1138> ... how do I reply all in one go?
09:08:52 <Rubidium> peter1138: make a comment somewhere on the "Files changed" page to start a review, then any replies to comments will also end up in the review. Just don't forget to remove the bogus comment before "finalising" the review
09:11:19 <peter1138> I think I've done the comments, the rest are things to do, or duplicates.
09:12:16 <peter1138> I've "unresolved" 2TallTyler's comment about the 64/58/31 constants 🙂
09:13:02 <peter1138> (So that it's visible.)
09:18:50 <peter1138> Although thinking about it, I can just do it here anyway.
10:19:15 <peter1138> Interesting, the original TTD station picker is only 46 pixels high, the everything else is 48.
10:19:51 <peter1138> At some point we went switched to 58 pixels for the station picker.
10:20:16 <peter1138> Which is why things like MB's newstats don't fill the preview area.
10:23:25 <andythenorth> I drew stations once
10:23:41 <peter1138> Yeah, that's the "enourmous" 58 high.
10:24:04 <reldred> andythenorth: you should do that more often, you're good at it
10:24:09 <peter1138> (Weird number, in the code it was 60 pixels but 2 are the bevel...)
10:24:18 <andythenorth> reldred: I get no pleasure from stations
10:24:27 <andythenorth> Industries are my favourite thing to draw
10:24:42 <andythenorth> Boats are the worst, but the boat spec is very simple
10:25:01 <reldred> But we get pleasure from your stations :fingergunsright:
10:37:00 <peter1138> Should make the GUI parts of it smaller 🙂
10:43:39 <LordAro> peter1138: quick link fell apart on my way to work :(
11:04:08 <peter1138> I have a regulatory 45g of muesli. Smol.
11:45:15 <peter1138> Hmm, `std::optional<largestruct>` 'wastes' memory, `std::unique_ptr<largstruct>` makes it non-copyable, and `std::shared_ptr<largestruct>` could work but...
12:01:36 *** Smedles has joined #openttd
12:32:59 <peter1138> For the default specs, increasing from 624 bytes to 24128 is quite a jump. But that's a total, so maybe I worry too much 😄
12:40:22 <LordAro> what is CheckAtomic even used for?
12:40:41 <LordAro> is <atomic> an optional header or something silly?
12:53:28 <LordAro> incidentally i notice it still says c++17, as per my original comment :p
13:04:17 <kuhnovic> Next up: removal of tile_area for even more memory reduction 🙂
13:04:29 <kuhnovic> (in the WaterRegion class)
13:05:13 <peter1138> Is that because it can be derived from the region index?
13:08:09 <kuhnovic> Yes. It's a bit less convenient, but definitely possible
13:08:16 <kuhnovic> And it will make JGR happy
13:08:17 <_jgr_> Yes, the width/height are also always the same for water regions so they don't need to be repeatedly stored
13:08:33 <kuhnovic> I can finally say "I have a patch for that"
13:09:44 <kuhnovic> At a glance it looks an awful lot like what I have. Which makes sense.
13:11:50 <LordAro> what sort of memory reduction are we talking? overall, or just relevant for cache-based stuff?
13:12:10 <LordAro> (i.e. what is the benefit of making this change?)
13:17:01 <peter1138> Drops a WaterRegion from 32 to 24 bytes. There's 1 for each 16x16 area. It's not as significant as the previous change.
13:18:02 <kuhnovic> There are two "previous changes", one by JGR and one by me. The JGR one was very significant, the other not so much, it was more for cache-friendliness
13:19:20 <kuhnovic> Removing tile_area is 524288 bytes saved on a 4K map
13:19:52 <peter1138> Only 2KiB on a normal map 😉
13:20:22 <LordAro> most would not consider 500kB all that much :p
13:22:10 <_jgr_> Perhaps not, but cumulatively all the small overheads can add up to something which isn't small
13:22:32 <peter1138> if (user == LordAro) malloc(524288);
13:30:25 <kuhnovic> And the tile_area isn't really needed either, so we might as well reduce it. It increases the openttd-can-run-a-potato factor too.
14:28:33 <Rubidium> blathijs: are you aware that Debian buildds can't find libcurl / that it's missing a dependency? Also copyright seems to be missing a few folders in 3rdparty
14:33:10 *** gelignite has joined #openttd
14:35:37 <peter1138> Heh, relevant... "Host compiler appears to require libatomic for 64-bit operations, but cannot find it."
14:37:46 <Rubidium> though what's causing 13.4 to succeed and 14.0 to fail building there? Nothing was changed there, besides C++17 -> C++20 (13.4 and 14.0 were built with the same compiler version in Debian)
14:39:02 <Rubidium> oh, and cmake injects an extra -std=c++20 when passing it to the compiler in CheckAtomic... so that got changed
14:43:19 <Rubidium> will the linker go mess up when you say -std=c++20 to the compiler and -std=c++17 to the linker?
14:51:12 <peter1138> I've never tried building 13.4. For me it can't find do 64 bit atomic operations, but I'm running a 32 bit OS, so...
14:54:30 <peter1138> (Uh, on this Raspberry Pi, that is :-))
14:54:43 <silent_tempest> Is running a 32 bit OS in 2024 a cry for help? 😛
14:56:14 <peter1138> ```/usr/bin/c++ -DCHECK_FUNCTION_EXISTS=__atomic_load_8 -std=c++2a -o CMakeFiles/cmTC_34018.dir/CheckFunctionExists.cxx.o -c /tmp/build/CMakeFiles/CheckLibraryExists/CheckFunctionExists.cxx
14:56:14 <peter1138> <command-line>: error: new declaration ‘char __atomic_load_8()’ ambiguates built-in declaration ‘long long unsigned int __atomic_load_8(const volatile void*, int)’ [-fpermissive]```
14:56:42 <peter1138> Nah, it's an old Raspberry Pi, they don't have enough memory to warrant 64bit...
14:57:04 <peter1138> And there was no 64bit Pi OS for a long time.
14:57:22 <alfagamma7> Pi 5 is 64 bit right?
14:57:38 <silent_tempest> Rubidium: Part of me says no? I wouldn't expect the linker to care about the c++ standard. But another part of me says it's c++ so there's always the possibility that it will fuck up. I don't see a standard option listed in the gcc docs...
14:57:43 <alfagamma7> Though lots of people have stated it's too expensive as a SBC
15:07:54 <alfagamma7> I should really start using it
15:08:04 <peter1138> Well that's + than a 3B.
15:08:31 <peter1138> But not much point. I only tried compiling due a bug report this morning.
15:15:02 *** gelignite has quit IRC (Quit: Stay safe!)
15:35:53 <silent_tempest> Rasberry Pi 4 is 32 bit?
15:36:12 <silent_tempest> And cmake is complaining about needed a certain thing for 64 bit builds?
15:36:26 <silent_tempest> It's ignoring the current machine config?
15:36:30 <blathijs> Rubidium: libcurl is on my todo-list, I thought I checked the licensing, but maybe I didn't. THere's also a bugreport about a bit of cmake code from LLVM that needs to be mentioned in copyright, so I'll have to find some time to look more closely anyway.
15:37:05 <peter1138> I was trying to build, for a first time on a 32bit OS on a Raspberry Pi 3B+.
15:37:24 <Rubidium> blathijs: the LLVM thing was upstreamed already
15:37:27 <silent_tempest> I just tried the same on a Rasberry 4 of some type
15:37:49 <silent_tempest> it's an armv71. Which is 32 bit?
15:39:04 <peter1138> Whether it's worth it is another matter.
15:42:47 <peter1138> I need to update this Pi anyway, it's still on 10.x
15:44:34 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
15:45:36 <Rubidium> a fix for the atomic check failing to build is simple... not sure whether it's the best one: adding C to LANGUAGES in CMakeLists.txt
15:47:13 *** kale91 has quit IRC (Quit: User went offline on Discord a while ago)
15:47:26 <Rubidium> though... lets first see whether that links
15:48:19 <Rubidium> lets see how long compilation takes. cmake took a good minute
15:51:20 *** peter1139 has quit IRC (Ping timeout: 480 seconds)
16:01:43 *** peter1139 has joined #openttd
16:05:14 <Rubidium> yeah, this compile's going to take a while. After 15 minutes it just started with the actual compilation instead of generating all the files.
16:14:45 <silent_tempest> That cmake files seems really busted to me
16:30:14 <silent_tempest> Huh it does work if I change the compiler from gcc to clang
16:35:50 *** Smedles has joined #openttd
16:44:06 <truebrain> LordAro: Normally those comments are added to the ticket 😛
18:29:21 <johnfranklin> 0230 AM awake, I found Starbucks raw coffee is too stimulating to drink.
18:40:19 *** Wormnest has joined #openttd
18:55:46 <merni> some people want inter-signal distance to be correlated with train length, others with train movement
18:56:42 <silent_tempest> ladysadieviaGitHub: I feel like this commit was really big but splitiing it also seemed bad.
18:56:47 <merni> johnfranklin: Raw as in without brewing it?
19:00:52 <merni> ladysadieviaGitHub: I can't wait for this
19:01:05 <truebrain> you are looking at it!
19:03:13 <silent_tempest> merni: I'm excited. 🙂 I got a basic version of it working weeks ago it allowed me to make the switch from OG TT to OpenTTD. Lol. I know I missed something dumb but hopefully the review won't take super long and I can add some stuff on top of it.
19:03:50 <silent_tempest> Also holy shit. I can spend hours fine tunning UI code...
19:06:29 <frosch123> truebrain: did you have some thought about showing the old base text for outdated translations? easiest method would be to save the base text in the json instead of the commitid
19:06:51 <truebrain> I do have a thought, just not the time 😛 Will fix this weekend or so 🙂
19:07:30 <frosch123> i have a langfile parser now, which can both read and write
19:07:40 <frosch123> next i want to attach the blame thingie to it
19:07:53 <frosch123> but i wondered whether i should change the json as well
19:08:08 <truebrain> if you don't have to, don't
19:08:15 <truebrain> it shouldn't be impacted in what you are doing
19:09:06 <frosch123> well, i want to touch the import command, so if you also want to touch it :p
19:10:30 <truebrain> I am rather confused in this conversation 😛
19:14:42 <frosch123> question was: are the plans to change the data json to something else? i want to read and write it.
19:17:01 <truebrain> the part that confuses me, that I don't really understand how that matters 😄 Serde reads/writes those JSONs, and it already writes it 😛
19:17:17 <truebrain> but yes, there are plans. I already have some draft code. But that shouldn't stop you from doing whatever you want 😄
19:18:35 <frosch123> i want to use git blame to figure out which translator did changes
19:18:52 <frosch123> for that i need to hook into serde to track line numbers and relate them to git blame
19:19:51 <frosch123> but ok, i will ignore the blame part for now then, and only do a simple export
19:20:16 <truebrain> huh? Why 🙂 Just go for it 😄
19:22:30 <truebrain> like I said, I don't really understand the conversation 😛 I am not scared of some merge conflicts, so don't let that hold you back 🙂
19:26:08 <truebrain> I also looked at storing the date, but I also want to balance file-size; but that will be fine 🙂
19:29:06 <truebrain> owh, and if you touch the blame stuff, maybe check if we can make the parsing unit-testable; I fucked that up totally 😛
19:29:12 <truebrain> (was already happy it worked 😄 )
19:34:33 <frosch123> haha, now we are getting to why i asked :p currently the blame stuff is in the import subpackage, and step by step... i ended up wanting to change everything about it, including the test-ability
19:34:59 <truebrain> still not sure how my changes would impact your wanting to change it 😄
19:35:13 <frosch123> well, you never told me what you want to change
19:38:32 <truebrain> haha 😄 I also don't know yet 😛
19:38:38 <truebrain> so just make it do what you need, I will figure it out 🙂
19:38:53 <truebrain> (now I sound like JGR 😛 )
19:49:40 <truebrain> frosch123: guess mostly what I would like that I can see per line when it was modified, and what that line was 🙂 (based on a `STR_` )
19:50:57 <frosch123> what that line was? you mean what it was before (history), or what the base language was at that time?
19:51:40 <truebrain> you want to integrate blame of different files?
19:56:47 <frosch123> i want something like: (1) method returns annotated file content as tuple `(lineno, commit-hash, raw content)`. (2) langfile parser turns that into `map<stringid,map<case, (commit-hash, text)>>`. (3) correlates base-language with translation and replaces the `commit-hash` of the "langfile changed" with the commit of the "valid base text back then".
19:57:02 <frosch123> parts of this already exist in the import-command, but slightly different
19:57:22 <frosch123> (3) could also directly store the base-text instead of the commit-hash
19:57:36 <frosch123> which i think would not be much larger for the json overall
19:58:03 <frosch123> most base-texts are not that much longer than the commit-hash, and the json-keywords and indenting are even more
19:58:46 <frosch123> anyhow, i will start small, and just finish the export command without blame for now
19:59:29 <truebrain> I would skip (3) if you don't need it
19:59:51 <truebrain> at least, I assume you don't need it for import/export 😛
20:00:27 <frosch123> your import implementation does it
20:00:45 <truebrain> but otherwise it sounds fine
20:48:23 *** Smedles has joined #openttd
20:56:33 <Rubidium> yay... only five hours later the build is done. Adding C to languages does solve the problem with building
20:59:15 *** ufo-pilo- has joined #openttd
21:06:02 *** ufo-piloot_ has quit IRC (Ping timeout: 480 seconds)
21:06:36 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:07:27 *** ufo-piloot_ has joined #openttd
21:09:26 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:11:18 <peter1138> Now just a few hours for the unit tests 🙂
21:21:02 <Rubidium> I aborted when it started building those ;)
21:42:09 <_glx_> hmm why {NUM} for one and {DECIMAL} for the other ?
21:43:42 <peter1138> Oh. Because I initially experimented with showing 1.5x etc.
21:43:48 <peter1138> But then put it back to normal.
21:45:01 <peter1138> It's probably okay as {DECIMAL}, saves having to invalidate all translations if we ever decide to include labels for sub-markers.
21:45:33 <peter1138> 0.5% volume probably isn't needed though.
21:46:12 <peter1138> Although I can't remember why I went with 1x 2x etc for scale originally, when 100%, 200% etc would have worked.
21:46:18 <peter1138> Maybe it was too noisy.
21:48:06 <Rubidium> ... I occasionally have sound at 1% that I still find too loud (or maybe my home's too quiet)
21:49:00 <Rubidium> it's almost like I'd want a logarithmic scale for sound
21:49:17 <truebrain> how to name that .. hmm...
21:49:23 <truebrain> yeah, that sounds excellent 😄
21:49:52 <peter1138> Well the actual range for volume is 0 to 127 for hysterical raisins.
21:50:36 <_glx_> for music it's in the spec
21:51:20 <_glx_> well MIDI stuff is often 0-127
21:51:35 <peter1138> I avoided "dB" originally because, although we do have a bit of scaling going on, it doesn't really match dB.
21:52:00 <peter1138> For MIDI volume, yeah, I guess. We could scale it.
21:52:17 <peter1138> Although with Fluidsynth we could change the volume during mixing.
21:53:02 <peter1138> And yeah, that's the other thing, for sound we could potentially do dB, for music there's no correlation.
21:53:33 <peter1138> I thought that atomic issue was just something I hadn't set up properly on my Pi, seeing as I'd not compiled on it before.
21:55:07 <peter1138> The Pi crashed trying to switch to the 14.0 branch, and git state is in a mess. So maybe I won't bother 🙂
21:55:21 <peter1138> Possibly the SD card is on its way out.
22:14:14 <peter1138> Need to update my Pi to actually compile though, it's got libstdc++ 8.3, which is too old.
22:22:24 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:26:18 <bootmii> 14.1 is definitely happening
22:31:32 <talltyler> Not sure if that’s a question or a statement, but the answer is yes 🙂
22:36:35 <peter1138> If only we'd stop finding more bugs 😄
22:38:40 <michi_cc> And a changelog'd appear 🙂
23:33:13 *** amal[m] has quit IRC (Quit: Client limit exceeded: 20000)
23:41:27 <peter1138> What a world. Using Microsoft packages to install Java 21 on Debian 12...
23:56:43 <silent_tempest> peter1138: Gross
23:59:18 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
