IRC logs for #openttd on OFTC at 2026-11-03
⏴ go to previous day
00:01:16 <peter1138> Yeah, `OverflowSafeInt32 a{0}; a = UINT32_MAX; CHECK(a == INT32_MAX);` fails too. Yum.
00:06:40 <will_marshall_> canonical solution
00:06:53 <peter1138> Oh never mind, I thought it was in RC1, but it's not.
00:07:35 <peter1138> My "don't merge anything" trick paid off I guess.
00:07:59 <peter1138> Well, so far. Plenty of other things could go wrong :D
00:09:52 <peter1138> I suppose I better test it ;)
00:10:11 *** WormnestAndroid has quit IRC (Quit: Quit)
00:10:19 <peter1138> Just, all that wrangling of overflowsafe_type.hpp upsets a lot of files.
00:10:29 *** WormnestAndroid has joined #openttd
00:11:08 <peter1138> This is train game anyway.
00:12:18 <peter1138> I'm still wondering what parts of the game processing would actually be suitable for doing on a GPU.
00:14:30 *** andythenorth_ has quit IRC (Quit: Connection closed for inactivity)
00:14:40 <will_marshall_> depends on if you have to pay for sending data over the bus or not
00:17:22 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
00:19:54 <peter1138> Whatever it is, there's a lot of game logic that has to be adapted to run on a GPU. And you know what that means.
00:20:25 <peter1138> Time for more Doom.
00:37:19 *** WormnestAndroid has joined #openttd
02:07:56 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:16:21 *** WormnestAndroid has joined #openttd
02:36:37 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
02:39:48 *** WormnestAndroid has joined #openttd
03:00:56 <kaibaneddy> peter1138: Don't they
03:01:02 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:03:02 *** WormnestAndroid has joined #openttd
03:12:08 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:17:37 *** WormnestAndroid has joined #openttd
03:32:34 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:40:40 *** WormnestAndroid has joined #openttd
03:40:42 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
03:50:52 *** WormnestAndroid has joined #openttd
04:30:48 *** Philemon has joined #openttd
04:34:17 *** Phileman has quit IRC (Ping timeout: 480 seconds)
05:01:45 *** tokai|noir has joined #openttd
05:01:45 *** ChanServ sets mode: +v tokai|noir
05:08:42 *** tokai has quit IRC (Ping timeout: 480 seconds)
07:48:34 <peter1138> Annoyingly this is turning into a bigger change :(
07:53:56 <LordAro> yeah, you did that in the past and then removed it?
07:54:02 <LordAro> github's outdated diff has confussled me
07:54:43 <LordAro> well, i'll leave the comment there for you to respond to anyway :p
07:56:47 *** Flygon has quit IRC (Read error: Connection reset by peer)
07:58:03 <peter1138> Anyway, my issue now is that all those free operators I removed were actually necessary, not for compilation but for correct operation.
07:58:39 <peter1138> That to me is a smell, it should fail to compile in that case.
08:02:11 <LordAro> definite oddities going on
08:02:44 <peter1138> The culprit is the operator T(), which allows implicit conversion to a non-overflowsafe type. I may then end up doing calculations, and then becuase you can implicitly convert back to overflowsafeint, it looks like it was safe but it's not.
08:04:31 <peter1138> This is partly caused by changing OverflowSafeInt(int) to OverflowSafeInt(std::integral auto). Trying to fix one thing made it fragile elsewhere.
08:06:15 <peter1138> Originally all I wanted to do was replace the C-casts :-)
08:07:49 <peter1138> This is an existing case of smell... `EnforcePrecondition(false, (int64_t)money <= UINT32_MAX);`
08:09:42 <peter1138> Why would you need to cast Money to int64_t to compare it? Because the existing code silently converts UINT32_MAX to a signed -1
08:12:43 <peter1138> `return BigMulS(dist * time_factor * num_pieces, cs->current_payment, 21)`
08:13:30 <peter1138> This is fun. It's one of the last remaining uses of the old-school BigMulS stuff, which is designed to allow multiplying to 32-bit values and shift it, to avoid overflowing.
08:14:31 <peter1138> cs->current_payment is Money, and that get implicitly converted to int32_t in the function call. This is doing the opposite of overflow protection.
08:15:24 <peter1138> Of course, cs->current_payment is never likely to be more than 2^31.
08:16:00 <peter1138> My current thinking is to go really pedantic, like we did for StrongTypes (which originally also allowed implicit conversion)
08:16:52 <peter1138> Remove operator T(), and indivudlaly fix every case that no longer compiles.
08:16:55 <peter1138> Hence... much bigger.
08:17:53 <peter1138> Also spell individually properly.
08:23:34 <peter1138> When Generative AI is involved, disclose its use, but do not discuss its merits or morals (including using reactions).
08:23:45 <peter1138> Well. oops, I didn't meant to paste that.
08:24:49 <peter1138> 🥫 of 🪱 is what I wanted :)
08:29:29 <peter1138> Maybe I can do "std::integral as long as it's smaller than T (and excluding unsigned-T)"
08:32:01 <peter1138> Hmm, concepts can't appear in a class, therefore I can have a concept that depends on T
08:36:31 <rito12_13> > error: implicit instantiation of undefined template 'std::char_traits<unsigned char>'
08:45:05 <peter1138> > The Clang Language Server server crashed 5 times in the last 3 minutes.
08:52:23 <peter1138> Okay, I can replace ClampTo with a custom function that only allows safe conversions.
08:53:01 <peter1138> Means even more changes :o
08:53:35 <peter1138> auto value = ParseInteger<uint64_t>(*str, 10, true); Money money = *value / GetCurrency().rate;
08:54:41 <peter1138> What was it doing? uint64_t / int64_t? or (int64_t)uint64_t / int64_t?
08:55:19 <peter1138> economy.cpp:354 is amusing.
08:55:21 <LordAro> there are well defined rules for integer promotion
08:55:27 <LordAro> but don't ask me what they are or where to find them
08:55:47 <will_marshall_> Those rules only exist to make CS students' lives miserable on rote exams.
08:56:02 <peter1138> Yeah, I got it wrong.
08:56:17 <peter1138> What was it doing? uint64_t / Money? or (Money)uint64_t / Money?
08:57:13 <peter1138> Of course division can't overflow anyway, but if it's converting uint64_t to int64_t that can end up with something else. It's not hugely problematic, but neither is it "OverflowSafe"
08:57:42 *** nanapipirara has joined #openttd
08:57:43 <peter1138> /* Not too drastically though, because it could overflow */
08:57:49 <peter1138> Company::Get(old_owner)->money = UINT64_MAX >> 2; // jackpot ;p
08:58:12 <peter1138> The choice of UINT64_MAX >> 2 is awkward.
08:58:19 *** nanapipirara has quit IRC (Remote host closed the connection)
09:07:29 *** MinchinWeb[m] has quit IRC (Ping timeout: 480 seconds)
09:07:45 *** MinchinWeb[m] has joined #openttd
09:16:11 <peter1138> constexpr T ClampTo(std::integral auto value)
09:16:11 <peter1138> (sizeof(T) >= sizeof(value) && std::numeric_limits<T>::is_signed == std::numeric_limits<decltype(value)>::is_signed) ||
09:16:14 <peter1138> (sizeof(T) > sizeof(value) && std::numeric_limits<T>::is_signed));
09:16:17 <peter1138> return static_cast<T>(value);
09:16:37 <peter1138> This abomination means we accept any integral type, and the throw an assert if it's not convertible.
09:16:53 <peter1138> Eh, not convertiable without clamping.
09:17:34 <peter1138> My existing change implicitly clamps which may hide bugs?
09:43:56 <LordAro> looks sort of half minified
09:44:56 *** reldred has joined #openttd
09:44:56 <reldred> "Yeah, I'd keep that to myself if I were you." yeah that's basically been my view of it
09:44:57 <peter1138> I imagine it's likely the models were fed minified code as training data.
09:45:07 <reldred> says more about the person than the technology
09:45:19 <will_marshall_> claude doesn't forget a break; every once in a while though.
09:46:26 <reldred> honestly I know the technology isn't going anywhere, but I have a shit-list of companies I want to see go bust and CEO's I want to see homeless before I even give it any serious thought
09:46:39 <LordAro> vast majority of LLM generated code I've seen (of all languages) is overly verbose, not minified
09:47:07 <reldred> yeah likewise, I've seen some disgusting examples but eh.
09:47:10 <LordAro> reldred: but equally there's some people that don't deserve the RAM they have
09:47:30 <will_marshall_> That's been my experience. Trying to explain self-documenting code to software that's designed to meet a line of code KPI.
09:47:32 <LordAro> (this includes Mr Altman, ofc)
09:48:21 <reldred> I've been playing with some ML/neural network type stuff in Darktable recently.
09:48:33 <reldred> God Nvidia have made a mess of cuda on linux
09:48:48 <reldred> how do these people live like this
09:48:57 <reldred> I understand it now but damn
09:50:55 <will_marshall_> Linus was right about Nvidia a looong time ago 🙂
09:51:22 <reldred> I need to do some more print tests though to see whether the upscaling juice is worth the squeeze. Do some 1:1px crops of native res upscaled using standard algos and then with the silly neural network upscaling
09:53:14 <reldred> that said the new camera will be fifty megapixies
09:54:17 <will_marshall_> 50 million nano-imps.
09:54:18 <reldred> 27" on the long edge without upscaling
09:56:18 <reldred> I still haven't put toobs on my bicycle
09:56:27 <reldred> but it has been quite wet
10:02:19 <peter1138> Oh my, OverflowSafeInt flat out breaks if you want an unsigned underlying type.
10:03:00 <reldred> watcha wrenchin on peter?
10:04:45 <peter1138> An `OverflowSafeInt<uint32_t>` throws a warning if you compare it with `0`
10:05:15 <peter1138> This first time I've seen Clang warn about unsigned vs signed comparision.
10:05:29 <will_marshall_> Correct but annoying? `0U` better.
10:05:48 <peter1138> (-Wsign-compare is in the compile flags since forever)
10:06:11 <peter1138> will_marshall_, with the current OverflowSafeInt, there's no unsigned comparison opereator.
10:07:01 <will_marshall_> Such real programming.
10:07:49 <peter1138> Rust wouldn't have these problems.
10:10:16 <will_marshall_> Rust code is bug-free because nobody ever executes it.
10:10:44 <LordAro> just incorrect usages of wrapping_add & saturating_add & unchecked_add
10:12:33 <LordAro> and checked_add & strict_add & checked_add_signed & strict_add_signed & overflowing_add & carrying_add
10:17:12 <peter1138> Hmm, I guess I should check my rewritten version to see if that behaves better with unsigned.
10:22:53 <peter1138> Well, at least will_marshall_'s suggestion of 0U works with the rewrite.
10:26:39 <will_marshall_> I shouldn't be so harsh on Rust it's probably a good language and I'd force myself to learn it if I was likely to pivot to being a serious systems programmer in the future, but I bet learning it is unforgiving when the defaults are so very strict.
10:27:18 <LordAro> definitely a steep learning curve
10:31:37 <peter1138> > Rust's syntax is similar to that of C and C++
10:31:50 <will_marshall_> "it has braces, therefore c"
10:32:24 <LordAro> i mean, it doesn't have begin/end
10:32:43 <peter1138> > Multiple let expressions can define multiple variables with the same name, known as variable shadowing.
10:33:17 <LordAro> oddly useful at times
10:33:41 <LordAro> but i probably would avoid it in production code
10:34:56 <peter1138> > let new_x: i32 = if x % 2 == 0 { x / 2 } else { 3 * x + 1 };
10:35:47 <LordAro> if expressions (and everything else being an expression) is quite neat
10:49:37 <masteroktagon> peter1138: actually I find it looks very similar to JS (have never programmed JS myself though)
10:50:26 <peter1138> It's a bit of mix, and manages to look like a mismash of symbols to me :)
10:50:42 <peter1138> Hmm, should OverflowSafeInt<int64_t> + OverflowSafeInt<int32_t> be allowed?
10:51:09 <masteroktagon> peter1138: in c++ yes
10:51:18 <masteroktagon> we auto type casting
10:52:57 <masteroktagon> also you should add some shortcuts for writing OverflowSafeInt<int32_t> & co with `using`. maybe sth like `safe32_t`?
10:53:26 <peter1138> OverflowSafeInt32 is our "shortcut"
10:53:38 <peter1138> User-defined types shouldn't use the `_t` suffix.
10:53:54 <masteroktagon> _t looks terrible anyways
10:54:19 <masteroktagon> why cant it be like `uint32`
10:57:45 <masteroktagon> Probably going to switch from LALRPOP for NML2 to Pest since error reporting in LALRPOP is a pain.
10:58:07 <peter1138> Hmm, `constexpr OverflowSafeInt(ConvertibleThroughBase auto value) : m_value(ClampTo<T>(value.base())) {}` should be able to handle any OverflowSafeInt conversion (although that will silently clamp it), but would allow other ConvertibleThroughBase types too.
10:58:48 <masteroktagon> LordAro: sadly for loops cannot be made into an expression for ... reasons
11:00:01 <LordAro> not really sure how that would work
11:00:33 <peter1138> C#'s IEnumerable is quite handy but also can be a foot-gun.
11:10:34 <masteroktagon> LordAro: me neither but would be neat wouldn't it
11:12:38 <peter1138> Alright: Is implicit clamping okay or a bug? The current PR does it, but thinking further I think it's a bug.
11:13:36 <LordAro> in what sense? isn't implicit clamping the whole point of the type?
11:13:47 <peter1138> LordAro, implicit clamping during type conversion.
11:14:36 <peter1138> e.g. `OverflowSafeInt32 a = UINT32_MAX`
11:15:35 <LordAro> yeah, if it can be determined at compile time that a constant overflows the type, yeah, it should probably be an error
11:16:00 <LordAro> i can't think of any good reason why you'd be assigning a large constant to a smaller type
11:16:25 <peter1138> Usually accidentally.
11:28:26 <peter1138> Hmm, oh, it's >> 2, not >> 1 :)
12:12:32 <DorpsGek> - Update: Translations from eints (by translators)
12:29:54 <peter1138> Then the mammoth task of Doxygenising it :)
12:41:42 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
12:53:46 *** WormnestAndroid has joined #openttd
13:01:54 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:02:03 *** WormnestAndroid has joined #openttd
13:07:44 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:17:36 *** ialokin has quit IRC (Ping timeout: 480 seconds)
13:19:08 *** LordAro has joined #openttd
13:31:54 *** WormnestAndroid has joined #openttd
13:32:58 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
13:35:05 *** WormnestAndroid has joined #openttd
13:47:50 *** lunax has quit IRC (Quit: Change da world… my final message. Goodb ye)
13:51:29 <peter1138> > For anyone who is unable to attend in person the [funeral] service will also be live streamed.
13:58:37 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
14:50:52 *** WormnestAndroid has joined #openttd
14:55:40 *** WormnestAndroid has quit IRC (Read error: Connection reset by peer)
15:28:15 <LordAro> review request: "Straight-forward name change on makefile for this MR! I've reviewed [colleague]'s changes which are the meat of the MR, but slipped in change to the demo code at the same time to show off new capabilities due to these changes"
15:28:35 <LordAro> at least 3 of which should've been caught by the prior two reviews
16:05:10 <peter1138> Just a technical test of including settings in the new-game window.
16:06:25 <peter1138> Ignore everything about the design. It all works as a subclassed window, a bit like the picker windows.
16:07:50 <peter1138> Likely better to just have a button to open the game options window :)
16:08:32 <_zephyris> I think it might be a _bit_ big... 😉
16:09:10 <LordAro> maybe with tabs instead?
16:10:00 <kuhnovic> Peter bought an ultrawide
16:23:48 *** SigHunter has quit IRC (Remote host closed the connection)
16:24:21 <peter1138> > <@peter1138> Ignore everything about the design.
16:24:45 <peter1138> Yes, tabs, with AI, Game Script, NewGRF, etc.
16:25:07 <peter1138> But. Now that I've fiddled with this, the sub-classing windows stuff is a bit, uh, fragile.
16:25:54 <peter1138> Hmm, maybe if it's a member instead of a sub-class.
16:36:52 <peter1138> Oh, then it doesn't have access to window stuff :/
16:37:51 <peter1138> Turns out virtual classes for window event handling is kinda bad :)
18:03:22 *** aperezdc has quit IRC (Ping timeout: 480 seconds)
19:16:16 <peter1138> Power blip. My UPS upstairs did not survive. My Pi (doing IRC) did.
19:58:09 *** aperezdc has joined #openttd
20:21:44 <andythenorth> does it have a big capacitor in it?
20:22:11 <_zephyris> Low power draw and big capacitors in USB transformers/power supplies
20:22:52 <peter1138> Well, my sound is no longer working :/
20:23:03 <andythenorth> is this the same phenomenon as the wall bricks where the light stays on after you unplug them?
20:25:21 <andythenorth> peter1138 years ago I made these horros
20:35:14 <_zephyris> Probably, anything with a step down transformer, rectifier and smoother most likely has a chunky capacitor for the smoothing.
20:37:18 <peter1138> Well, something is fried, either hw or sw.
20:44:04 *** SigHunter has joined #openttd
22:24:48 <peter1138> Needs a constructor that accepts int to be able to detect narrowing of constants. But then it also accepts non-constant ints :o
22:54:55 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:28:16 *** lunax has quit IRC (Remote host closed the connection)
continue to next day ⏵
