IRC logs for #openttd on OFTC at 2023-05-06
β΄ go to previous day
00:34:36 <petern> 1: + ERROR: Registering two scripts with the same name and version'
00:34:36 <petern> 2: + ERROR: 1: E:\src\OpenTTD\build\ai\regression\main.nut'
00:34:38 <petern> 3: + ERROR: 2: E:\src\OpenTTD\build\ai\regression\main.nut'```
00:43:22 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
00:47:19 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:27:53 *** Wormnest has joined #openttd
02:09:46 *** debdog has quit IRC (Ping timeout: 480 seconds)
02:11:03 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
02:12:24 *** WormnestAndroid has joined #openttd
02:16:29 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:16:30 *** WormnestAndroid has joined #openttd
02:28:12 *** Wormnest has quit IRC (Quit: Leaving)
02:56:43 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:57:38 *** WormnestAndroid has joined #openttd
04:56:30 <Rubidium_> petern: I used log->lines[log->pos] = message.substr(0, message.find_first_of('\n'));
04:57:56 <Rubidium_> but then I changed the input parameter to const std::string &
04:58:08 *** keikoz has quit IRC (Read error: No route to host)
06:25:26 *** HerzogDeXtEr has joined #openttd
07:18:01 *** Flygon has quit IRC (Remote host closed the connection)
07:59:09 *** axet has quit IRC (Quit: Leaving.)
08:31:23 <andythenorth> /me -> compliance time
10:33:26 <petern> Rubidium_: Ah, I already have it hete
10:40:18 <petern> Mine goes further as I got rid of the void pointer.
10:40:39 <Rubidium_> that's even better :)
10:53:56 *** hnOsmium0002 has joined #openttd
10:55:39 *** hnOsmium0001 has quit IRC (Ping timeout: 480 seconds)
11:52:00 <andythenorth> needed more dice
11:58:11 <FLHerne> from reddit: "Hi guys, recently got into this game and I like all the grfs but im really struggling with finding trainsets that aren't exhaustive lists of all engines that ever existed."
11:58:11 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
11:58:28 <FLHerne> I do love reviews by ordinary sane people
11:58:32 <FLHerne> they put things in perspective
11:59:03 *** WormnestAndroid has joined #openttd
12:10:36 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:10:48 <TrueBrain> brrrr, I so dislike "opening quotes" and "closing quotes" ... like, nothing wrong with just quotes
12:10:59 <TrueBrain> wouldn't even know how to write them, and don't want to find out either π
12:11:17 <TrueBrain> I always assumed it was a Microsoft Word thing, as it auto-replaces those things π
12:11:38 <FLHerne> it seems like multiple kinds of license violation
12:12:16 <petern> Perfect line-breaking...
12:12:40 *** WormnestAndroid has joined #openttd
12:12:58 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:13:07 <andythenorth> I looked for a way to report that iOS port to Apple
12:13:12 <andythenorth> but couldn't find one
12:13:52 <TrueBrain> from what I remember, people have tried
12:14:12 *** WormnestAndroid has joined #openttd
12:18:29 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:18:54 *** WormnestAndroid has joined #openttd
12:20:16 <TrueBrain> if only you had access to a substance to fix that issue
12:24:35 *** WormnestAndroid has quit IRC (Remote host closed the connection)
12:24:40 *** WormnestAndroid has joined #openttd
12:34:27 <petern> While that gets destroyed, I need to get acquire bits to make salad π
12:38:42 <petern> Heh, GetLogPointer is somewhat misnamed :p
12:46:11 <TrueBrain> right .. I guess I should give textfile conversion an attempt myself .. I am scared π
12:46:20 <TrueBrain> I hate string manipulation in C++ π So complicated! π
12:47:01 <TrueBrain> it starts with .. how do you fread into a std::string ..
12:47:37 <Rubidium_> no, you don't fread :D
12:47:49 <michi_cc[d]> You use a stream instead π
12:47:58 <TrueBrain> ugh ... even worse! Fine .. do we have an example?
12:49:50 <TrueBrain> yeah, but we can't use a real filepath
12:49:54 <TrueBrain> we ofc have `FioFOpenFile` to use
12:50:20 <TrueBrain> `strgen` is rather the exception there π
12:50:30 <TrueBrain> seems everywhere else in the code we still use `fread` π
12:51:11 <Rubidium_> yeah... strgen is the begin of porting stuff to more C++ file handling
12:51:30 <TrueBrain> we will always have that a file can either be on disk or in a tarfile
12:51:37 <TrueBrain> so we cannot let STL handle the opening of a file π
12:52:23 <TrueBrain> michi_cc[d]: can I use that on a filepointer?
12:55:27 <michi_cc[d]> The whole tar stuff is a bit of an issue I guess. There's is really and standard way to mix stream IO with c-style IO. ifstreams are seekable though, so replicating something should be possible.
12:55:45 <TrueBrain> okay, but a bridge too far for what I try to solve π
12:56:02 <TrueBrain> `this->text = std::string(filesize, '\0');`
12:56:06 <TrueBrain> that "good enough" for now? π
12:56:10 <TrueBrain> or is that too nasty?
12:57:42 <michi_cc[d]> The "proper" solution might be to write a custom `std::basic_streambuf` for TARs, but that really feels like overkill.
13:09:24 <TrueBrain> Rubidium: `StrMakeValid` creates a new std::string, right? So it should be safe to change the first paramter to an string_view, right?
13:10:03 <glx[d]> doesn't it call StrMakeValidInPlace ?
13:10:32 <Rubidium_> TrueBrain: it would
13:10:45 <TrueBrain> good; means I think I somewhat understand it .. π
13:11:04 <TrueBrain> glx[d]: it does, but that function is a bit misnamed now π
13:11:24 <TrueBrain> (the `static` variant, that is .. the old C-style ones are named perfectly fine)
13:15:44 <TrueBrain> lol ... our layouter is still C-style ... I see how these things are total rabbitholes π
13:15:59 <TrueBrain> I was trying to use string_view instead of adding \0 everywhere .. but that is a bit tricky π
13:16:34 <Rubidium_> once it gets to the layouter, hasn't it gone through SetDParamStr/FormatString and friends already?
13:16:47 <TrueBrain> no, this is `GetStringHeight`
13:20:10 <Rubidium_> well... welcome to the rabbit hole
13:20:23 <TrueBrain> yeah .... so let's use some shortcuts to make sure it actually works first π
13:20:36 <Rubidium_> battle you picks wisely
13:21:04 <TrueBrain> we are just not that ready for string_view π
13:21:11 <TrueBrain> `DrawStringMultiLine` is neither π
13:21:24 <TrueBrain> (as .... it calls Layouter)
13:22:06 <Rubidium_> I guess there'll be a whole "can/should this be std::string_view instead of std::string" flurry once C-style strings are gone, as now it's also sometimes easier to just accept std::string instead of std::string_view for functions
13:22:30 <TrueBrain> yeah, but in this case, it was already using a C-style string_view for good reason
13:22:42 <TrueBrain> otherwise it would create all strings again every reflow
13:22:59 <TrueBrain> (for displaying a README, for example)
13:23:15 <TrueBrain> but let's first see how big the issue actually is π
13:32:28 <TrueBrain> I avoided the rabbithole!! π
13:32:45 <TrueBrain> it does consume a bit more memory temporary ..
13:33:38 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
13:33:45 *** WormnestAndroid has joined #openttd
13:35:52 <petern> Hmm, #10771 seems to be NewGRF-config related.
13:36:26 <TallTyler> So I'm trying to fix the engine age bug (it's not a Date, despite what the code says). I want to convert it back to a uint16, but can't figure it out. The game crashes on startup. I can make it a uint32 (which doesn't change the size). What else do I need to turn it back to a uint16?
13:37:39 <petern> Leave it as int32 then you don't need saveload conversion stuff.
13:37:47 <TallTyler> I guess I could just do that
13:38:05 <TallTyler> Seems arbitrary, but so maybe that's inevitable for this decision
13:38:59 <petern> I imagine the saveload conversion stuff does not work from larger to smaller, only smaller to larger.
13:40:04 <TallTyler> Is there a better check than `age != 0xFFFFFFFF`, particularly for a signed int?
13:40:42 <petern> Yes INT32_MAX is the old way but still works fine.
13:40:57 <petern> C++ has numerical limits
13:41:00 <glx[d]> should we ask for a savegame or is it easy enough to reproduce ?
13:42:00 <petern> Going to need a debug build though π
13:42:35 <petern> Actually probably not.
13:43:01 <petern> It's probably the change to std::string for filename in GRFConfig.
13:43:28 <petern> SLE_STR(GRFConfig, filename, SLE_STR, 0x40),
13:43:31 <petern> Should be SSTR I believe.
13:44:18 <glx[d]> so you don't have to switch branch again π
13:45:06 <TrueBrain> so that gives the question: why does it compile? π
13:46:56 <JGR> These macros cannot check that you've done the right thing
13:47:25 <TrueBrain> we do so much validation in them .. can't we add type validation too? π
13:47:52 <JGR> The validation is at run time
13:51:38 <JGR> You could probably do that in the lambda in SLE_GENERAL_NAME with yet more macro parameters
13:53:31 <JGR> For what it's worth I've been bitten by this sort of thing a few times π
13:53:48 <TrueBrain> yeah, we all have π¦ That is why I kinda love static_assert for settings π
13:53:53 <TrueBrain> they do tell me from time to time I am an idiot π
13:54:05 <JGR> Even with type safety, you will still need to check that it works with actual savegames as well anyway though
13:54:59 <petern> Ooh, new unit test, ensure all old savegames load π
13:56:01 <Rubidium_> if the check passes that fast, then that seems like a no-brainer :D Only it should have failed
13:58:12 <TallTyler> Ignore typo, you didn't see anything π
13:58:34 <petern> Heh, and of course 10770 fails due to int/size-t conversion, which is the reason for me to make a PR of it in the first place π
13:59:38 <petern> Maybe I should switch to the WSL build full-time.
14:00:14 <Rubidium_> I wonder how I forgot SLE_STR -> SLE_SSTR... for NewGRFs :(
14:00:36 <petern> You probably expected the compile to fail π
14:01:04 <glx[d]> the only difference between both is `length`
14:01:53 <Rubidium_> no, I knew it doesn't fail to compile. And IIRC I also tested, though... maybe it got lost in rebase/refactoring somewhen.
14:02:28 <petern> Otoh, shows that someone is playing the nightlies π
14:02:46 <Rubidium_> and that without the survey in place!
14:04:06 <TrueBrain> to start another discussion .. `std::string_view` .. to `&` or not to `&`? π
14:04:21 <TrueBrain> to `const` or not to `const`?
14:05:20 <Rubidium_> doesn't matter much if it's not '&'
14:05:28 <TrueBrain> exactly why I ask π
14:05:50 <TrueBrain> an old company of mine had the same conversation about `uint32_t` ..
14:05:59 <Rubidium_> though most of it is const as far as I can see
14:06:06 <Rubidium_> so, if it can be const leave it const I'd guess
14:06:21 <TrueBrain> 56 with, 120 - 56 without const
14:07:02 <TrueBrain> bit of a mixed bag currently ..
14:08:50 <TrueBrain> okay, seems Layouter can become string_view too pretty easily
14:09:02 <TrueBrain> (mainly as everything is nicely a `const char *`, that makes things a lot easier
14:09:06 <petern> There's some juicy mallocs/callocs in there iirc π
14:09:29 <petern> And the confusing array of left-right pairs as separate elements.
14:10:10 <TrueBrain> how cheap is the conversion of `const char *` to `string_view` I now wonder .. hmm
14:10:17 <TrueBrain> I would imagine it is a simple strlen, and that is it
14:11:21 <TrueBrain> makes it a tiny bit easier, as it means I can just do away with the `const char *` variant π
14:11:30 <TrueBrain> let's try .... if you don't hear from me in the next 10 days, I got lost π
14:13:32 <glx[d]> so with every checks being required, auto-merge should be fine I guess
14:16:04 <petern> "PeterN enabled auto-merge (squash)"
14:16:10 <petern> Don't want to forget to squash that one π
14:17:38 <TrueBrain> funny, `std::string_view::const_iterator` is `const char *` π
14:30:07 <glx[d]> reading #10772 description makes me think `MissingGlyphSearcher` is probably more broken than it was now we removed some {TINY_FONT}
14:33:27 <glx[d]> it was already suboptimal for strings drawn via indirection like "{TINY_FONT}{BLACK}{STATION}"
14:34:04 <glx[d]> so I guess it's not worse
14:35:25 <TrueBrain> hihi, the Layouter has a lot of assumptions going on π
14:35:37 <TrueBrain> let's see if we can fix those while we are at it ...
14:39:22 <TrueBrain> lot of unsafe C-style code π
14:44:49 <TrueBrain> hmm .. the Layouter first does UTF-8 decoding before looking for a \n .. and then it dismisses the UTF-8 decoding it did
14:45:05 <TrueBrain> but other parts of the code just scans for a \n, ignoring the UTF-8 decoding
14:45:42 <TrueBrain> but with UTF-8, isn't it just fine to do the latter?
14:45:54 <TrueBrain> multi-chars always have a high-bit set .. right?
14:46:17 <petern> I believe so -- if you run a utf8 sanitize to catch all illegal utf8 sequences, then any '\n' left will be newlines.
14:46:40 <petern> Yes, and alternative representations of the same codepoint are not legal.
14:47:03 <TrueBrain> I don't think it is the job of the Layouter to validate it is a valid utf-8 string π
14:47:07 <TrueBrain> (we check that way earlier already)
14:47:14 <TrueBrain> good; makes this function a lot simpler
14:47:27 <petern> (Unlike newgrf extendedbytes, which is probably fine)
14:47:45 <petern> 00 is the same as FF 00 00 π
14:48:01 <TrueBrain> yeah ... UTF-8 is a bit more clever π
14:53:31 <glx[d]> extendedbyte is clever for asm handling
14:53:59 <TrueBrain> can you guess what I did wrong? π
14:54:38 <glx[d]> or you count the color code
14:54:56 <TrueBrain> it is just funny π
15:02:34 * Rubidium_ needs that feature :D
15:03:06 <TrueBrain> haha, okay, this one is funny .. name a Town `Setfield`, change your language to Arabic, edit the town name, and press left .. when it hits the `i`, the cursor jumps to the first character
15:03:12 <TrueBrain> does the same on Windows as on Linux
15:03:23 <TrueBrain> (and yes, `Setfield` was a random name generated in a game of mine)
15:06:04 <TrueBrain> so we have a function `GetTextCharacterAtPosition` that is only used by MacOS
15:06:09 <TrueBrain> and it is a lot of code throughout our codebase
15:06:15 <TrueBrain> I can't guarantee it still works π
15:08:15 <TrueBrain> I will clean up that PR after dinner; need to make it into nicer commits π
15:18:51 <michi_cc[d]> petern: Now that was a "funny" bug...
15:22:13 *** WormnestAndroid has quit IRC (Remote host closed the connection)
15:22:13 *** WormnestAndroid has joined #openttd
15:24:46 <petern> Hmm, need to figure out how to pass a pool iterator into my scrollbar iterator.
15:33:50 <TrueBrain> michi_cc[d]: Does it also occur on Linux / Mac is now the question π
15:36:59 <michi_cc[d]> TrueBrain: That was a specific problem for Uniscribe. Won't occur on Mac, might occur for Linux if you copied my code too literally.
15:37:33 <TrueBrain> Will check after dinner π
15:38:14 <michi_cc[d]> Basically Uniscribe builds the runs like "68|,|123" (| being separator), and the code failed if the end of a run was exactly the same pixel width as the line width.
15:38:37 <michi_cc[d]> Basically it assumed in this specific case that the end of the run would be a valid breaking point, which is not generally true.
15:38:57 <michi_cc[d]> I've simply changed it to also do line breaking if we exactly hit the line width.
15:40:44 <andythenorth> meh still not loving these dice
15:40:54 <andythenorth> so ... full colour sprites in strings when? π
15:57:34 <TallTyler> Any idea why #6958 is failing only MinGW and why I can't see the 2 annotations in the files tab?
15:58:33 <petern> It's a unit test failure.
15:58:57 <TallTyler> MinGW says it's a regression failure, but none of the other builds agree
15:59:31 <petern> Well that means the unit test failed only on MinGW.
16:00:33 <TallTyler> `(9587 lines were expected but 9596 were found)`
16:00:42 <TallTyler> I don't understand why that would happen or how to diagnose it
16:01:38 <andythenorth> what else could signify 'random colours' besides dice icon?
16:01:43 <andythenorth> the dice icons suck
16:02:49 <petern> Draw the purchase list sprite with multiple colours
16:03:12 <petern> TallTyler: That's not the error, that's the result of the error.
16:03:28 <petern> ```642: - GetQuarterlyExpenses(): 0
16:03:28 <petern> 642: + GetQuarterlyExpenses(): -3333333'```
16:04:42 <TrueBrain> michi_cc[d]: Pretty sure I copied that :p
16:04:47 <petern> Anyway, because it's just one platform doing something different, suggests UB some where.
16:05:37 <Rubidium_> ... and worse, it means desyncs too
16:07:16 <michi_cc[d]> TrueBrain: It also depends on how harfbuzz/ICU builds the runs, so it might or might not be an issue. Reproducing it means trying to get a `.` that is at the end of a string to break by fiddling width window widths until you get the exact pixel width π
16:07:57 <TrueBrain> Yeah ... need to find a good window for that π
16:08:05 <TrueBrain> Not going to wait for bankrupt :p
16:09:20 <michi_cc[d]> In the settings, `Graphics -> Highest resolution sprites to use' has a nice long explanation text.
16:10:07 <michi_cc[d]> For checking numbers, I just manually modified the string π
16:11:52 <andythenorth> petern: like this, but with recolouring in the sprite layers? π
16:14:32 <andythenorth> seems we have a max text offset perhaps
16:15:35 <andythenorth> but less crappy?
16:32:35 <andythenorth> how about an animation cycle, triggered when the row is selected? π
16:33:10 <andythenorth> oh recolour remap an existing cycle? π
16:36:25 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
16:36:27 *** WormnestAndroid has joined #openttd
16:40:47 *** fridaemon has joined #openttd
16:40:47 <fridaemon> andythenorth: From which set are these wagons? I DON'T KNOW them π
16:44:28 *** WormnestAndroid has quit IRC (Ping timeout: 480 seconds)
16:45:04 *** WormnestAndroid has joined #openttd
17:06:22 <TrueBrain> michi_cc[d]: it is even worse on ICU, it repeats the part that should have broken off π
17:09:21 <TrueBrain> okay, something to delve into another time .. that is a bit more tricky π
17:22:05 <andythenorth> this is no better, confusing π
17:24:19 <TrueBrain> ` if (auto match = linecache->find(LineCacheQuery{state, str}); match != linecache->end()) {`
17:24:24 <TrueBrain> why do I still hate statements like that π
17:32:43 <TrueBrain> michi_cc[d]: : do you happen to know .. the MacOS definition of `characterIndexForPoint`, is that actually still needed?
17:33:28 <TrueBrain> it seems unused, but I dn't actually understand that code π
17:34:08 <TrueBrain> all those functions seem unused, so I guess it is something MacOS specific?
17:36:25 <TrueBrain> ah, something to do with `NSTextInputClient`..
17:36:28 *** sittinbythefire has joined #openttd
17:36:28 <sittinbythefire> andythenorth: what about a rainbow-colored shuffle button icon?
17:36:29 <TrueBrain> what a weird syntax this stuff is π
17:36:38 <pickpacket> andythenorth: what do the dice mean?
17:39:37 <michi_cc[d]> TrueBrain: Yes, they aren't unused, but implement the `NSTextInputClient` protocol (i.e. interface) that the OS uses to interface with the IME input system.
17:40:03 <TrueBrain> `GetCharAtPosition` is just a bit problemetic .. the return value is bound to the Layouter `string` variable
17:40:07 <TrueBrain> but this is now implicit
17:40:16 <TrueBrain> (it returns a `const char *`, which is inside `string`)
17:40:29 <TrueBrain> but when converting that to C++ .. you hit a bit of a snag, as you can't just do that π
17:40:48 <TrueBrain> I think returning an index would make more sense
17:41:34 <TrueBrain> ironically, it is fine on Linux / MacOS, as a string_view iterator is just a `const char *`, but not in Windows
17:41:57 <TrueBrain> or ... I can just postpone this issue ... yeah, let's do that!
17:44:11 <michi_cc[d]> It shouldn't be too hard to make `CountUtf16Units` count until an index instead of a char.
17:44:36 <TrueBrain> what I still don't like, is that the index is totally unbound from the string it is the index of
17:44:43 <TrueBrain> just by accident all the way on top level that information is recombined
17:45:22 <TrueBrain> `const char *ch = _focused_window->GetTextCharacterAtPosition(pt);`
17:45:22 <TrueBrain> `return CountUtf16Units(_focused_window->GetFocusedText(), ch);`
17:45:38 <TrueBrain> that is just ... it is weird, and I can't really put my finger on it π
17:53:37 *** gelignite has joined #openttd
17:54:18 <petern> Ah, our pool iterator doesn't support the + operator.
17:58:25 <petern> And the filtered pool iterator has no chance π
17:59:18 <petern> Replace pool with a std container? π
18:01:37 <Rubidium_> time to go for std::view I'd guess
18:03:18 <TrueBrain> ugh, so many (near) full recompiles because you change one header ..
18:08:18 <Rubidium_> that's when you know you're messing with the string stuff
18:08:48 <TrueBrain> I have that all week already, and only now do string stuff .. not sure π
18:09:07 <TrueBrain> it is like .. "you touched <SOMETHING>, let me recompile <EVERYTHING> for you"
18:13:30 <TrueBrain> hard to make sure `string_view` actually works .. as the endless assumption it ends with `\0` isn't valid anymore π
18:14:35 <TrueBrain> STOP MAKING SILLY MISTAKES, ffs π
18:20:41 <andythenorth> sittinbythefire: shuffle icon is not a bad suggestion eh π
18:20:43 <andythenorth> not sure if it works
18:20:59 <andythenorth> but it's less intrusive than the dice, they draw the eye too much
18:22:19 <andythenorth> pickpacket: wagon will have random colour, or random sprites (from a range of options)
18:23:21 <andythenorth> with company colour
18:26:55 <TrueBrain> the longer you look .... right, enough now, let the CI do its thing!
18:29:51 *** ralph[m] has joined #openttd
18:30:01 <petern> So my build on WSL that was working the other day now complains that it can't find E:/src/vcpkg/scripts/buildsystems/vcpkg.cmake...
18:30:43 <TrueBrain> why are you accessing that path from WSL? π
18:30:50 <TrueBrain> hmm ... `ssize_t` doesn't exist on windows?!
18:31:05 <TrueBrain> I guess I need to include some header-file for it ..
18:32:02 <TrueBrain> petern: I don't use any Windows executable to work on WSL. I installed cmake and all build dependencies via my Ubuntu 22.04 installation
18:32:12 <TrueBrain> I don't even use vcpkg
18:32:22 <TrueBrain> I also don't share a working folder with my windows install
18:32:29 <petern> Yes, it somehow followed over from my Windows install.
18:32:32 <TrueBrain> accessing the Windows FS from WSL is not the fastest, and permissions are often annoying
18:32:40 <TrueBrain> so I just `git clone` into my ext4
18:33:08 <TrueBrain> `On Windows, ssize_t is not defined but SSIZE_T is`
18:33:14 <TrueBrain> I don't even ... get out of here
18:33:32 <TrueBrain> it is defined in `src/network/core/os_abstraction.h`
18:33:37 <TrueBrain> `typedef SSIZE_T ssize_t;`
18:33:52 <TrueBrain> so .. am I wrong to use ssize_t? Or shall I move that typedef into stdafx?
18:34:34 <TrueBrain> (I was returning an index inside a string, but it can also return -1 for "not found" .. so normally I would do `size_t`, but .. because of -1, `ssize_t`)
18:35:08 <TrueBrain> I could also go `size_t` and use the npos trick: `size_type(-1)`, which is a very large number π
18:35:38 <TrueBrain> euh, `size_type(-1)` -> `size_t(-1)`
18:36:56 <andythenorth> hmmm define a shuffle sprite glyph?
18:37:28 <petern> Anyway, it's building now π
18:37:31 <Rubidium_> TrueBrain: it should probably be ptrdiff_t
18:38:15 <petern> But is it really dealing with pointers?
18:38:38 <petern> `The type ptrdiff_t is an implementation-deο¬ned signed integer type that can hold the diο¬erence of two subscripts in an array object....` Hmm, I guess.
18:38:50 <TrueBrain> `std::ptrdiff_t acts as the signed counterpart of std::size_t: it can store the size of the array of any type and is, on most platforms, synonymous with std::intptr_t. `
18:39:19 <petern> So many rabbit holes and they're not even ours.
18:39:26 <DorpsGek> - Update: Translations from eints (by translators)
18:39:29 <petern> Oops, accidentally built openttd_test π
18:39:52 <Rubidium_> then building openttd should be relatively fast now
18:40:24 <petern> Okay, with OpenTTD running under WSL, how do I make the pointer not be dumb? I have two...
18:42:14 <petern> Huh, the English (US) description for OpenGFX is much longer than the English (UK) description.
18:43:57 <TrueBrain> yeah, those two cursors are unavoidable, as far as I know
18:44:04 <TrueBrain> WSLg fakes an X11 window
18:44:12 <TrueBrain> but for some reason ... our "hide the cursor" doesn't work
18:44:17 <TrueBrain> fun part is, they can desync
18:44:25 <TrueBrain> so the Windows cursor is on a different location than the OpenTTD one
18:45:33 <andythenorth> ach goes it delete randomised wagons?
18:45:38 <andythenorth> nothing looks good
18:46:48 <TallTyler> Throwing the baby out with the bath water, I think
18:50:42 <andythenorth> it's confusing in the autoreplace UI
18:52:42 <sittinbythefire> andythenorth: is there not one in the music window?
18:52:45 <petern> That was a commit & push from WSL. I'm getting brave π
18:53:00 <petern> Anything in the music Window is probably a bit large π
18:53:15 <TrueBrain> gratz on embracing WSL π
18:53:48 <andythenorth> can I be arsed to learn how to glyph? π
18:56:31 <petern> Whether it will work and look good is another matter.
18:59:19 <andythenorth> doesn't it need multiple sizes and RTL support and stuff?
18:59:28 <andythenorth> it put me off when all that was mentioned
19:00:52 <petern> No, it's just a glyph.
19:01:12 <petern> Draw it at normal font size and the game will scale it up if needed.
19:07:30 <petern> There's a shuffle unicode code point even, so you could use that.
19:11:21 <TrueBrain> 2 approvals, it got to be good!
19:11:56 <Rubidium_> hmm.. must've missed that
19:28:29 <andythenorth> so I need the unicode code point etc?
19:31:01 <petern> If that's the symbol you want π
19:31:38 <petern> Although tbh I'm not sure that works when truetype fonts are in use.
19:31:51 <petern> Only a small range is mapped to sprites, not "anything available"
19:32:10 <petern> Yeah basically this is a bad idea and not worth doing π
19:36:34 <andythenorth> yeah it says only the basic unicode plane
19:36:43 <andythenorth> which is not a thing I encountered before, but seems obvious
19:36:52 <Eddi|zuHause> do truetype fonts fall back to sprite fonts if they don't contain the glyph?
19:37:07 <petern> Not on a per-glyph level, no.
19:37:31 <petern> andythenorth: what says that?
19:37:33 <Eddi|zuHause> how are the custom glyphs special cased then?
19:37:49 <michi_cc[d]> By Unicode range.
19:37:53 <petern> They are mapped to a specific range.
19:38:40 <Eddi|zuHause> yes, so anything in that range will be forced to be sprite font?
19:38:47 <michi_cc[d]> Which is part of the private use area.
19:39:00 <glx[d]> I guess CI won't be faster with #10778
19:39:24 <michi_cc[d]> Eddi|zuHause: Yes
19:39:38 <Rubidium_> glx[d]: why wouldn't it?
19:40:14 <glx[d]> it's wiped on every run
19:40:25 <Rubidium_> the stats I provided are for a full clean rebuild
19:40:41 <petern> And most of the glyphs in that range are the normal ascii characters π
19:41:06 <Rubidium_> there are a few hundred cpp files that all include stdafx and friends; only having to do the validation/parsing once will save a lot there
19:41:27 <Rubidium_> it's not ccache; that would indeed be essentially pointless for the CI
19:41:46 <TrueBrain> can we then move also things like `#include <vector>` to stdafx?
19:41:49 <TrueBrain> curious what the speed is after that π
19:42:15 <Rubidium_> there are some open scope questions in that PR about what to include in it
19:42:29 <TrueBrain> yes, but I am curious what the speed difference is with or without them π
19:42:35 <TrueBrain> just the question isn't enough to produce an answer π
19:45:40 <TrueBrain> can't believe such PR makes compiling ... 30%? faster π 25%? Something like that
19:47:07 <andythenorth> ok so glyph or no glpyh? π
19:49:06 <fridaemon> andythenorth: I play with inflation ON, so I can't update to iron horse 3. I played with obsolete 2.35 version, but when I updated to 2.64, there's inflation cnflict. Don't you have an idea which version is the latest of inflation support and how can I download it?
19:52:21 <TrueBrain> now I am kinda curious about the speed gain of each of those 3 files π
19:52:29 <TrueBrain> useful? Possibly not. Fun? YES! π
19:53:21 <TrueBrain> I wonder if there is some magic breakpoint .. like, if it is included more than N times, it is faster to precompile π
19:53:36 <TrueBrain> and what if you just precompile every header? π
20:01:14 <TrueBrain> and now the question is ... will mingw still hit the 30 minutes compile-time? π
20:01:57 <glx[d]> the PR I'm looking to compare just finished with 34m
20:02:01 <TrueBrain> MacOS goes from 20m to 13m .. that is not bad
20:05:17 <TrueBrain> meh; on my local machine it makes little difference
20:07:45 <andythenorth> fridaemon: sorry don't know π
20:07:49 <andythenorth> inflation is broken
20:08:17 <glx[d]> hmm depending on the run used as reference I see macos going from 12m54s to 13m35s
20:08:49 <TrueBrain> too bad GitHub doesn't show build-times per job π
20:09:28 <glx[d]> and mingw is stuck in linking for 7m now
20:10:08 <TrueBrain> and you are right, MacOS build times are all over the place
20:10:14 <TrueBrain> guess it has to do on what host it is scheduled π
20:10:50 <TrueBrain> similar with some SDL1.2 runs .. some are faster than with that PR .. makes no sense π
20:11:52 <TrueBrain> `user 32m50.890s` before the PR, `user 34m10.489s` after
20:12:48 <TrueBrain> guess it has to do with IO access times π
20:13:31 <glx[d]> mingw doesn't help for that indeed, so many indirection in the API
20:16:32 <glx[d]> ok no gain for x86_64 mingw, 4m less for i686 mingw
20:22:40 <TrueBrain> owh, right, with precompiled headers you don't actually have to include the file yourself anymore .. I remember that from long long long ago
20:22:46 <TrueBrain> that the MSVC people didn't add stdafx, worked for them
20:22:50 <TrueBrain> and than a Linux dude came: IT BROKE
20:22:54 <TrueBrain> was before CIs existed π
20:27:56 <TrueBrain> lol, the precompiled header is 72 MiB on disk here π
20:30:47 *** Wormnest has joined #openttd
20:32:06 <TrueBrain> GCC: 32m. Clang: 16m
20:35:31 <TrueBrain> I wasted so much time by using gcc ... I want those minutes back!
20:36:10 <andythenorth> clang much faster π
20:38:04 <TrueBrain> I don't like weirdness, but GCC11 is weird π
20:38:25 <TrueBrain> Rubidium: what is your GCC?
20:38:27 <andythenorth> `make -j 19 463.27s user 49.79s system 743% cpu 1:09.02 total`
20:38:31 <TrueBrain> didn't mean to assume GCC π
20:38:37 * andythenorth didn't try 10778 yet
20:39:48 <Rubidium_> TrueBrain: gcc version 10.2.1 20210110 (Debian 10.2.1-6)
20:40:39 <TrueBrain> so I wouldn't expect GCC 11 to have no effect ... hmmmm
20:41:34 <Rubidium_> I've got make -j 4 though
20:41:59 <TrueBrain> yeah, me -j9, but I am not looking at the total time, rather the user time π
20:41:59 <andythenorth> lol with 10778 `make -j 19 298.45s user 28.08s system 747% cpu 43.687 total`
20:42:16 <Rubidium_> and ofcourse the pinnacle of modern computing: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
20:42:28 <andythenorth> it's insane that Iron Horse is so slow to compile, when I can compile the whole of OpenTTD in nearly the same time
20:42:46 <TrueBrain> but my suggestion it might be IO related is non-sense, as clang does see a huge speed-up .. let's try GCC 12 ..
20:43:53 <TrueBrain> andythenorth: no, it is insane you can compile OpenTTD in ~1 minute π
20:44:03 <andythenorth> it's only a laptop
20:44:37 <andythenorth> I was playing World of Tanks Blitz at the same time
20:44:54 <andythenorth> hmm wonder if I could teach the Horse graphics processing to use the GPU
20:45:07 <michi_cc[d]> One could get the feeling that Apple is a good CPU maker.
20:45:18 <TrueBrain> get out of here! π
20:47:18 <TrueBrain> okay, with GCC 12 it does go from 32m to 24m
20:47:35 <TrueBrain> so I guess it is just GCC 11 that is an issue here ...
20:48:24 <glx[d]> and mingw uses 12.2 π¦
20:49:43 <TrueBrain> well, I guess, as long as it doesn't make some targets slower, and does make others faster ... we should do it π But this is rather unexpected ..
20:56:32 <TrueBrain> haha, he went for it! π
20:59:22 <TrueBrain> compile goes from 22m to 19m with stdafx.h alone, and to 14m with fmt.h ... fmt is a beast! π
21:02:13 <michi_cc[d]> One could argue if all of the STL headers need to be in stdafx, but some definitely make a lot of sense.
21:03:12 <glx[d]> some are used a lot π
21:03:37 *** axet has quit IRC (Quit: Leaving.)
21:03:38 <Rubidium_> to be honest I think it's a bit overkill, especially as it doesn't significantly help
21:03:58 <Rubidium_> but this was the simplest (the one with least thinking and complexity)
21:04:18 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:04:27 <TrueBrain> MacOS finished in 7 minutes
21:06:46 <TrueBrain> so including the STL does seems to make a difference for clang
21:06:49 <TrueBrain> GCC doesn't give a crap π
21:07:42 <glx[d]> for MSVC including STL doesn't make a huge difference
21:08:13 <glx[d]> but CI timings are not very consistent π
21:09:11 <TrueBrain> on my local machine with clang it also doesn't make a difference .. this feels a bit random π
21:11:14 <glx[d]> maybe I should try to setup clang-cl with CMakePresets.json (I had it CMakeSettings.json)
21:11:55 <TrueBrain> every test I did so far is faster without `strings.h` as precompiled header
21:14:42 <andythenorth> hmm think I do delete Horse random wagons
21:14:48 <andythenorth> there's no way to explain the behaviour
21:15:15 <andythenorth> suffixes in the name text doesn't fit buy menu
21:15:44 <andythenorth> could add colour information to vehicle details, but it will never be seen
21:15:53 <andythenorth> the cargo list will obscure it
21:16:06 <andythenorth> the 'shuffle' icons are ugly and don't explain what's happening
21:16:39 <petern> That cargo list is ... awkward.
21:16:51 <andythenorth> the colour mixing looks quite nice but eh
21:17:12 <andythenorth> I don't think grf is appropriate for implementing this
21:17:43 <petern> It is. Not all random variation is just colour.
21:20:01 <andythenorth> I could try putting small squares of colour in the sprite
21:20:51 <andythenorth> maybe I could name them shorter?
21:21:01 <andythenorth> just "Minerals"? ?
21:21:07 <andythenorth> not "Mineral Wagon"
21:27:37 <TrueBrain> but with the ideal setup, full recompile in < 2 minutes .. that is a huge difference π
21:27:50 <TrueBrain> clang + this PR, from ~5m to <2m .... π
21:30:02 <andythenorth> it's almost like I need 2 lines π
21:31:57 <andythenorth> ok linebreak seems to not be supported in buy menu π
21:32:07 <andythenorth> well, it works, but the text area doesn't expand
21:33:11 <petern> In the extra text or the engine name?
21:35:13 <petern> As STL is a lot of templates it's not surprising it doesn't change much.
21:35:26 <andythenorth> I didn't expect it to work, just an experiment
21:35:27 <petern> It's meant to be an engine name.
21:35:35 <andythenorth> this is the problem
21:35:42 <andythenorth> it's now a name, a size, a colour scheme
21:35:49 <andythenorth> maybe a 'randomised' suffix also
21:37:40 <TrueBrain> petern: fmt is too, but that makes a huge difference π
21:39:18 <andythenorth> sometimes it would be ok to add 'colour scheme' to the extra info maybe
21:39:31 <andythenorth> but other times...somebody added too many cargos π¦
21:46:40 <TrueBrain> tried to see if any of the squirrel header would give a meaningful speed-up, as the script-files are always so slow to compile .. but none gave any meaningful difference
21:59:04 <TrueBrain> lol, mingw build of 45 minutes
21:59:07 <TrueBrain> really, this mingw ... π
22:03:02 *** tokai|noir has joined #openttd
22:03:02 *** ChanServ sets mode: +v tokai|noir
22:09:34 *** tokai has quit IRC (Ping timeout: 480 seconds)
22:31:33 <andythenorth> pff this leaves a large gap for non-random wagons
22:36:54 <andythenorth> what does Train Fever do?
22:37:36 <andythenorth> our buy menu doesn't look like that
22:42:18 <petern> Variants in a side pane?
22:44:26 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:45:16 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:46:24 <andythenorth> the TF one isn't actually nice to look at though? π
22:47:37 *** nielsm has quit IRC (Ping timeout: 480 seconds)
22:51:07 <petern> Seems more like consist templates
22:53:47 <andythenorth> how about extra sprites in the vehicle details window?
22:54:22 <andythenorth> could do like I do in the docs π
22:54:32 <andythenorth> show the candidates for randomisation π
22:54:47 <andythenorth> see also, flags, all that crap
23:08:52 <andythenorth> could do something like this
23:14:15 *** gelignite has quit IRC (Quit: Stay safe!)
23:36:12 <TallTyler> I prefer the icons to the coloured text
23:36:24 <TallTyler> Still not idea though
continue to next day β΅
