IRC logs for #openttd on OFTC at 2023-05-21
⏴ go to previous day
00:14:10 *** Wormnest has joined #openttd
01:06:51 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
01:40:42 *** Wormnest has joined #openttd
02:08:08 *** Wormnest has quit IRC (Quit: Leaving)
02:52:10 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:21:35 *** D-HUND is now known as debdog
06:52:51 *** CK2347 has quit IRC (Quit: User went offline on Discord a while ago)
07:23:28 <TrueBrain> Rubidium_: lol, did not expect that .. but I am also not surprised 😄
07:26:36 <TrueBrain> I even wonder if OSX calls it .. but that code is weird as shit
07:27:47 <TrueBrain> it also has a MakeCrashLog function, but it is not virtual ..
07:28:02 <TrueBrain> it contains mostly the same code, but in a slightly different way
07:30:39 <Rubidium_> oh, that's right... "my" OSX crashlog does call it because I just removed the not-really-special OSX version
07:31:20 <TrueBrain> good; as that is really odd code
07:31:27 <TrueBrain> I am not even sure which code is actually called
07:31:35 <TrueBrain> one of them is shadowed, but which ..
07:31:57 <TrueBrain> I also love they return true/false, but nobody gives a fuck 😄
07:33:38 <TrueBrain> hmmm ... why doesn't the cheat window open on my Windows build ..
07:35:12 <Rubidium_> b0rked hotkeys.cfg?
07:35:47 <TrueBrain> tnx for the reminder that was an option 😄 Fixed!
07:36:47 <TrueBrain> lol, with the MSVC debugger active, you can't get past ALT+0 exception
07:36:52 <TrueBrain> GO INTO THE CRASH HANDLER FFS! 😛
07:39:04 <Rubidium_> continue in the debugger?
07:39:39 <TrueBrain> it is fine, I can run it without the debugger
07:40:00 <TrueBrain> now to figure out how I can add `-dnet=6` in MSVC ... eeeeuuuuuhhhhhhhh
07:41:28 <Rubidium_> debug properties -> command line parameters?
07:41:30 <TrueBrain> ah, found it! W00p! So proud of myself 🙂
07:41:48 <TrueBrain> no, Debug -> Debug and Launch settings
07:41:59 <Rubidium_> (it was a complete guess though)
07:46:18 <TrueBrain> I also don't really understand why Windows has their own code for this stuff, as it is also doing nearly the same .. but what-ever
07:51:16 <Rubidium_> yeah, but not nearly enough to easily change it. Or at least, to easily change it without developing on their platform
07:52:22 <TrueBrain> at least this should fix the current problem
07:52:25 <TrueBrain> the rest is for another day 🙂
07:53:13 <Rubidium_> the most important bit is, I think, that it first gets a log of basic data, then it creates the dmp and then does (potentially more dangerous?) append extra stack trace information before writing the log, savegame and screenshot. Whereas the default one doesn't have that split
07:54:32 <TrueBrain> I mostly think this code became what it is, as most of our developers are on one platform 😄 It is hard to develop things for all 3 at once
07:55:22 <TrueBrain> okay, works on Windows, works on Linux, #10855 .. no clue about OSX 😄
07:55:29 <Rubidium_> so essentially the .dmp has the crash log without stack trace information (because it doesn't need that), whereas the log file gets the stack trace
07:56:13 <TrueBrain> btw, you also joining us the 10/11/17/18th of June?
07:56:17 <Rubidium_> "should be fixed 'soon'"
07:56:37 <TrueBrain> (one of the downsides of Discord <-> IRC bridge, I don't have PMs on IRC :P)
07:57:53 <Rubidium_> can't have you be the only one having gone to all the parties :D
07:58:06 <TrueBrain> hahaha 😄 Now that is a good motivation 😛
08:05:56 <TrueBrain> so far the 10th seems to be in the lead 🙂
08:31:47 <TrueBrain> ugh, more infrastructure issues with IPv6 only ...
08:31:55 <TrueBrain> hmm .. how to fix ... let's think ...
08:32:32 <TrueBrain> an image pull also causes a call to be done based on the response received .. hmmm
09:36:00 <TrueBrain> finally! I managed to work arounds GitHub stupid IPv4-only issue, and I can now fetch images via IPv6 😄
09:37:17 <petern> Custom ipv6/ipv4 bridge? :p
09:37:24 <TrueBrain> yeah, with a tnx to Cloudflare
09:37:38 <TrueBrain> it only was non-trivial because of an authorization header
09:39:22 <TrueBrain> fun fact: GitHub CoPilot wrote the regex .. I never actually checked it is correct 😄
09:39:32 <TrueBrain> looking at it, seems valid enough
09:51:06 <petern> Silly clang/gcc letting me get away with dodgy iterator comparisons :p
09:51:21 <TrueBrain> yeah, MSVC is a bit more picky 😄
10:57:06 *** virtualrandomnumber has joined #openttd
10:57:21 *** virtualrandomnumber has quit IRC ()
14:11:06 <Rubidium_> glx[d]: sadly that doesn't seem to work :(
14:11:43 <glx[d]> hmm locally it does, but I didn't clear the cache
14:11:43 <Rubidium_> well... it does work if your build directory is not empty, but once it is, it doesn't work anymore
14:12:36 <Rubidium_> that's why it failed so horribly everywhere; I changed it and it worked, not thinking that starting from an empty folder would behave any differently... and wrong I was...
14:13:13 <glx[d]> oh it should be marked GENERATED at some point
14:15:06 <glx[d]> hmm but it works for openttd target
14:17:08 <glx[d]> hey I can try the cmake debugger
14:22:06 <glx[d]> "When a generated file created by an add_custom_command() command is explicitly listed as a source file for any target in the same directory scope (which usually means the same CMakeLists.txt file), CMake will automatically create a dependency to make sure the file is generated before building that target."
14:22:15 <glx[d]> that's why it works for openttd targer
14:22:34 <glx[d]> let's see if I can fix that for the other targets
14:23:06 <Rubidium_> then you would assume add_dependencies would add the required things
14:24:04 <Rubidium_> though I guess it needs to mark the generated files as generated somehow, and they're not in the strgen/settingsgen projects
14:24:19 <glx[d]> well "Source file properties are visible only to targets added in the same directory (CMakeLists.txt)."
14:26:22 <Rubidium_> oh... I might have a solution, that many don't like... changing the min version to 3.20
14:26:34 <Rubidium_> "Changed in version 3.20: The GENERATED source file property is now visible in all directories."
14:31:39 <Rubidium_> ah, I found something I think
14:36:46 <TrueBrain> that moment that a flag that is suppose to check for consistency doesn't actually work .. lol
14:37:35 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
14:38:19 <Rubidium_> it solved the issue for most of the failing build platforms... but not for emscripten :(
14:47:10 <glx[d]> but it still needs add_dependencies
14:47:50 <glx[d]> because you want to be sure the files are generated before the tools are built
14:49:58 <glx[d]> so tools_only does weird things
14:50:38 <Rubidium_> not really, it just bails out way way way earlier
14:52:17 <Rubidium_> it's just that all the weird things to get rev.cpp compiled and working are done way later in the process
14:55:29 <glx[d]> hmm TARGET_DIRECTORY is only since 3.18
14:56:18 <Rubidium_> luckily the builds get cancelled
14:57:44 <glx[d]> "if(NOT OPTION_TOOLS_ONLY)" seems useless here
14:58:22 <glx[d]> maybe `if(NOT BINARY_HOST_DIR)` instead
14:59:43 <Rubidium_> well, I literally got no clue... I'm just throwing stuff and see what sticks
15:01:56 <Rubidium_> I've been testing it in the Local Supercluster :D
15:02:37 <Rubidium_> well... things got weird
15:03:04 <glx[d]> but BINARY_HOST_DIR is set so it should not try to set properties
15:04:54 <glx[d]> oh my bad it's HOST_BINARY_DIR
15:06:09 <glx[d]> at least if emscripten pass we are safe for nightlies
15:06:26 <glx[d]> as both windows and osx use the 2 pass build
15:06:43 <Rubidium_> already at build #7294 :(
15:06:55 <TrueBrain> higher higher higher!
15:07:32 <glx[d]> oh dubious ownership when building tools
15:07:33 <Rubidium_> #10k before the party?
15:09:32 <glx[d]> ah no it's find_version which seems to fail for emscripten
15:09:37 <CK2347> Ooh openttd has reached 10k commits already
15:09:43 <glx[d]> -- Version string: --g
15:10:01 <glx[d]> 10k was a very long time ago
15:12:06 <glx[d]> ok at least version was already broken for emscripten CI
15:28:18 <glx[d]> "Before 3.20 the GENERATED property is not global" <-- MSVC uses 3.25 and GENERATED didn't seem global to me
15:31:33 <glx[d]> so with 3.20, GENERATED is global but as we don't set the policy to NEW, it's still not global
15:31:52 <glx[d]> because minimum version is less than 3.20
15:36:30 <Rubidium_> also I'm not fond of anything > 3.18 at the moment as that would require me to switch distro
15:36:59 <TrueBrain> if only there was this way to run things in a simulated way .....
15:37:03 <TrueBrain> I know, let's call them containers!
15:44:07 <Rubidium_> that'd probably cause even longer builds
15:44:35 <TrueBrain> what target is the issue?
15:45:23 <Rubidium_> well... it seems to build fine now, so all our CI targets must be 3.18 or higher
15:45:48 *** gelignite has joined #openttd
15:45:50 <Rubidium_> though our release targets... I've got no clue
15:45:54 <TrueBrain> anyway, if it ever becomes an issue, understand that things like Docker and podman run near native speed-wise
15:46:13 <TrueBrain> on Windows .. with WSL it does too 😛
15:46:39 <TrueBrain> (containers are not virtualized; they run fenced)
15:46:41 <Rubidium_> I understand that they run near native, but... it'll take memory away from the OS and newer software is likely larger software
15:46:56 <TrueBrain> it runs as a native process on your OS
15:47:02 <TrueBrain> so memory-wise there also isn't a real difference 😉
15:47:12 <TrueBrain> diskspace on the other hand ... 😛
15:47:47 *** Wormnest has joined #openttd
15:47:49 <Rubidium_> remember... 10 year old hardware :D
15:48:14 <Rubidium_> though a 4000 series GPU ;)
15:48:22 <TrueBrain> yeah, but that really is not a relevant argument anymore 😛
15:50:40 <glx[d]> it's possible to keep 3.16 as minimum, but that means using `set_source_files_properties(${GENERATED_SOURCE_FILES} PROPERTIES GENERATED TRUE)` in each target CMakeLists.txt
15:52:54 <Rubidium_> what about the alternative... removing the version all together?
15:54:15 <Rubidium_> as arguably nothing is using the version, or someone would have made a ticket for that
15:54:52 <glx[d]> and we don't distribute strgen anymore
15:55:09 <TrueBrain> despite one user asking, over the last 10 years 😛
15:58:28 <TrueBrain> right .. next issue ... cloning from github.com over IPv6 only ... yeah ... that fails too ...
15:58:46 <TrueBrain> fucking tards, with their IPv4-only shit .. ugh .. bit done with it 😦
15:59:34 <TrueBrain> and this is SSH, so I cannot do the Cloudflare trick I am afraid 😦
16:00:00 <TrueBrain> tempted to store the wiki-data and BaNaNaS repo on gitlab instead 😛 Ghehe
16:00:53 <glx[d]> well it could be possible to request the compiled lng file from eints, with a workflow using get source from latest eints push, apply changes, build tools, build langs
16:03:13 <TrueBrain> lol, TransIP, a Dutch provider, offers a proxy for github.com specifically for IPv6-only VMs they host 😛
16:03:51 <TrueBrain> glx[d]: the biggest problem to offer such functionality has always been: for what OpenTTD version?
16:04:01 <TrueBrain> as `lng` files are strongly bound to the OpenTTD client version
16:04:12 <TrueBrain> so these things only end in tears .. better to just not offer it
16:04:16 <glx[d]> I'd say latest nightly
16:04:26 <TrueBrain> so why not just wait till the nightly? 🙂
16:04:37 <TrueBrain> the other road that has been explored, live-feed eints into an OpenTTD client
16:04:47 <TrueBrain> basically moving strgen into the client
16:05:03 <TrueBrain> especially with GameScripts, there isn't really a good reason anymore to precompile language files like that
16:05:10 <TrueBrain> just ship .txt files, and run strgen on first start
16:05:29 <TrueBrain> removes this whole weirdness completely 🙂
16:05:53 <glx[d]> there is a reason, string table
16:07:14 <glx[d]> but a cmake script could generate it
17:47:22 <Rubidium_> is there a way to shoe horn squash #10787? Or does that need amending the commit message?
17:54:30 <glx[d]> just failed to properly write the commit message
17:59:32 <glx[d]> (a forced push should be fine if it's quick enough)
18:05:33 <TrueBrain> And what did we learn today? Don't bypass the branch protections, it rarely is worth it 😉
18:20:38 <TrueBrain> argh, still can't believe github.com is IPv4-only too ... I don't have many ideas how we can work around that .. but enabling IPv4 is just silly expensive for the few calls we make over IPv4 ..
18:23:38 <Rubidium_> can you change the hosts file?
18:24:02 <TrueBrain> I sure can; but that means I need a proxy .. which means yet-another-silly-machine-to-do-a-small-task ..
18:26:49 <Rubidium_> that name server does resolv a IPv6 address for github.com even though the normal ones don't
18:26:52 <TrueBrain> well, resolv isn't the real issue there: using a random 6to4 feels a bit dodgy 😄
18:27:14 <Rubidium_> true... but that's what SSL is for, isn't it?
18:27:33 <TrueBrain> more: what are the odds it remains online?
18:27:35 <Rubidium_> and it could, ofcourse get broken at some point
18:27:45 <TrueBrain> I rather have an infra that is robust 😄
18:30:03 <Rubidium_> level66's first and second level support looks quite loyal to me :D
18:30:21 <Rubidium_> but yeah, it might not be the safest bet
18:30:57 <Rubidium_> on the other hand, your OVH VPSes could burn to a crisp as well :(
18:31:27 <TrueBrain> the world can burn! But it is about taking things in control 🙂
18:32:17 <TrueBrain> I just like simple infrastructure; and this is ruining it!
18:34:59 <TrueBrain> awh, AWS's egress-only gateway doesn't have NAT64 enabled 😛
18:40:48 <DorpsGek> - Update: Translations from eints (by translators)
18:47:22 <Rubidium_> hmm... how to continue eradicating strecpy/seprintf when there are so many open PRs that remove a part of them?
18:48:28 <TrueBrain> bribe people for reviews!
18:52:35 <andythenorth> oh wait, that was just me
18:58:00 <glx[d]> Nml also has a lack of reviewers with rights
19:09:48 <petern> Hmm, how can I make a persistent StringFilter / QueryString?
19:10:09 <petern> I figure QueryString is part of the window/widget system, but StringFilter is the filter itself.
19:11:08 <petern> Maybe I should just use an extra static string...
19:12:34 <petern> Hmm, now even sure how to set an editbox 😄
19:18:32 <petern> Am I missing the methods to preset an editbox/querystring/textbuf?
19:21:26 <Rubidium_> hmm, or not anymore?!?
19:23:46 <Rubidium_> oh, and stuff like GetString(this->editbox.text.buf, str, last_of)
19:24:27 <Rubidium_> (yes, that was not part of #10843 as I wanted to try to avoid conflicting with you)
19:31:23 <TrueBrain> okay, found a way around the github.com IPv4-only issue .. I can also proxy the http like I do for ghcr.io, and change over the SSH to HTTPS for pushing, with a git-credential helper and a GitHub Apps .. bit of work, but that is doable.
19:31:36 <TrueBrain> I do have to (strongly) limit who can use the proxy, as .. having it public might be asking for trouble 😄
19:48:01 *** gelignite has quit IRC (Quit: Stay safe!)
19:56:45 <petern> Hmm, making QueryString static seems to work after all.
20:07:00 <petern> And that'll help the station one when I get around to fixing it 🙂
20:12:08 <glx[d]> now I need to do the annoying changelog update
20:39:44 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:42:25 <Rubidium_> andythenorth: any typo's in that changelog?
21:03:02 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:13:44 <glx[d]> and it worked flawlessly
22:03:49 *** ChanServ sets mode: +v tokai
22:10:27 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
22:13:02 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:14:17 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:47:17 *** _aD has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵