IRC logs for #openttd on OFTC at 2023-07-07
⏴ go to previous day
01:57:58 *** Wormnest has quit IRC (Quit: Leaving)
02:25:41 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:16:25 *** tokai|noir has joined #openttd
04:16:25 *** ChanServ sets mode: +v tokai|noir
04:23:22 *** tokai has quit IRC (Ping timeout: 480 seconds)
04:29:33 *** D-HUND is now known as debdog
08:24:44 <truebrain> 10 hours of silence .. it finally happened ...
08:25:00 <truebrain> nobody cares anymore 😛
08:38:07 <pickpacket> we’ll soon see the downloads plummet
08:38:21 <pickpacket> tomorrow they’ll be down to zero and stay that way forever
08:40:50 <andythenorth> I have left already
09:06:19 <truebrain> I hate stupid validations
09:06:59 <FLHerne> ########################
09:10:17 <truebrain> you leaked your password mate
09:10:22 <truebrain> guess you should change it now 😛
09:10:36 <truebrain> also, weird password, all the same key .. don't do that 🙂
09:26:56 <FLHerne> no, that's just the revised version of the hunter2 scheme
09:27:12 <FLHerne> it's a much more complex password, but it looks like ##### to you
12:38:12 <truebrain> once again a PR I cannot really test .. hmmm
12:38:34 <truebrain> either I make a dummy commit to add workflow-dispatch, so I can test
12:38:42 <truebrain> or I just merge this and fix any issue that comes out afterwards 😛
12:38:51 <truebrain> so either it is always 2 commits, or possibly 1 😄
12:39:27 <truebrain> well, maybe _glx_ can give it a looksy, and we just go for the 1-commit approach 🙂
12:40:11 <_glx_> I can try to spot mistakes
12:46:47 <_glx_> and of course I noticed something on 3rd read
12:49:03 <truebrain> and yet you missed the mistake 😛
12:49:54 <truebrain> so still 2 commits 😄
12:52:57 <truebrain> and now I could test it, and I can tell you it works 🙂
13:01:09 <truebrain> hmm, for some reason things are missing their health-checks pretty frequently .. which is causing restarts of the services ..
13:01:13 <truebrain> not sure what that is about yet ..
13:10:36 <truebrain> but first, let's address the preview, and where it is published .. I have all the pieces, let's slamp it together!
13:14:28 <_glx_> oh of course the folder
13:14:42 <truebrain> yeah, I copied it from the website .. and I knew I had to change it .. I didn't 😛
13:15:08 <_glx_> similar to "preview_" in all other PRs
13:17:55 <truebrain> hmmm .. if I migrate previews to CF, it will not have a pretty URL anymore .. that is to say, it will be something like pr1234.openttd-preview.pages.dev
13:18:25 <truebrain> the View Deployment button will bring you to the right URL, ofc
13:20:07 <truebrain> owh, but I can add a Cloudflare Worker for that, to make that look pretty .. yeah, that will work fine 🙂
13:24:09 <truebrain> what will be a consequence, that all current preview will no longer work, and PRs will need to rebase .. but I guess we can manage that
13:24:29 <truebrain> although we have 39 (!) PRs open with the preview label
13:24:36 <truebrain> someone is slapping that on those PRs like they are cookies 😄
13:24:39 <truebrain> (it is fine really)
13:25:46 <_glx_> with recent OOM in CI previews will be a pain
13:26:02 <truebrain> something to figure out for sure
13:43:15 <truebrain> I really need to figure out a way to test this before I merge this .. which most likely means finding a way to get the secrets on my fork 🙂
13:43:51 <truebrain> but, that is something to take care of another time 🙂 At least this workflow is much easier to follow 😄
13:43:54 <_glx_> hmm maybe we could try `--oom-kill-disable`
13:44:11 <truebrain> or we look into why emscripten uses so much memory, and see if we can fix that a bit 🙂
13:45:16 <truebrain> _glx_: as we don't use `-m`, that is a bit odd, honestly
13:45:20 <truebrain> it will kill something else
13:46:01 <truebrain> these runners have 7GB of RAM .. so it is just a bit odd
13:47:21 <_glx_> oh CI does a debug build IIRC
13:47:45 <truebrain> well, I would expect it to do a debug build 😛
13:49:02 <_glx_> preview had no OOM issue as far as I can see, but it does a release build
13:49:20 <truebrain> yeah, but that is a weird reason to make the CI do release builds 🙂
13:49:30 <truebrain> I rather have we spend some time looking into why it actually uses so much memory
13:50:26 <truebrain> someone making an educated guess, as it doesn't seem to change anything for that user
13:50:29 <truebrain> but that is what we need to figure out
13:50:36 <truebrain> or are there other things
13:51:23 <_glx_> IIRC we use debug builds for CI because it's faster (yeah MSVC I'm looking to you)
13:51:34 <truebrain> also make a balance between errors we get
13:52:02 <_glx_> but a debug build for emscripten might not be needed
13:52:17 <truebrain> yeah, but you are not actually fixing anything by saying: owh, now we don't run out of OOM
13:52:27 <truebrain> because a release might also be affected, just might take a few weeks longer before we hit it
13:52:35 <truebrain> it is much more useful to understand why it is doing this
13:52:39 <truebrain> as we might be doing something stupid here
13:53:56 <truebrain> especially as we really should use RelWithDebInfo for our previews
13:56:25 <truebrain> in general, we should have `WASM_BIGINT` enabled, but for completely different reasons 😛
13:57:07 <truebrain> but yeah, looking a bit further what is going on really helps with emscripten .. as it is a maze of weird settings and options, where you have to guess what is doing what
13:57:34 <truebrain> it really is a project that was build one block at the time .. and now looking back you go: what the actual fuck have we build! 😛
14:03:15 <Eddi|zuHause> my firefox is broken and i don't have time to fix it right now...
15:17:07 *** HerzogDeXtEr has joined #openttd
15:41:44 *** merni has quit IRC (Quit: User went offline on Discord a while ago)
16:01:32 <_glx_> that change feels wrong
16:05:29 <LordAro> _glx_: unnecessary at best
16:08:30 <_glx_> for me, with the reference, pixel contains the value, so ++ don't go to the next value, but I may be wrong
16:08:52 <jfs> the ++ line is removed entirely
16:10:11 <jfs> those are incrementing the pointed-to value, not the pointer
16:10:37 <jfs> no uh, ignore me I've been away from C++ for too long or something
16:11:24 <locosage> it's probably faster to add to the pointer than recalculate it every loop though
16:14:10 *** Wormnest has joined #openttd
16:16:12 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
16:47:13 <LordAro> well now it's definitely definitely wrong
16:47:46 <LordAro> i guess that was unnecessary
17:06:26 <_glx_> debug build locally (OOM killed)
17:06:45 <_glx_> that's without any extra flags
17:07:59 <_glx_> retrying with WASM_BIGINT
18:41:22 <DorpsGek> - Update: Translations from eints (by translators)
19:03:22 <truebrain> That is a long time for memory pressure .. I hope that isn't all due to that one call 😄
19:10:15 <truebrain> Don't remember linking took that long for me .. wow .. 50% of the time ..
19:10:40 <_glx_> at first I retried with just modifying CMakelists.txt and not deleting the build dir, it linked fine and without memory spike, then I cleaned build and rerun (still waiting)
19:11:30 <_glx_> before I was doing release builds, linking was faster
19:11:34 <truebrain> What I know now and didn't know then, is that WASM has all these extensions, like int64 .. most browsers support that fine, but as it is an extension, emscripten makes it optional
19:12:05 <truebrain> And as we heavily depend on int64 .. it helps to have that on 😄
19:12:38 <_glx_> ah 97% (waypoint_gui.o)
19:17:20 <truebrain> funny how that works out
19:17:21 <truebrain> also a lot quicker?
19:18:16 <_glx_> yeah linking step was faster too
19:18:45 <_glx_> hmm I should check the output still runs 😉
19:18:48 <truebrain> you make a new PR out of it?
19:20:01 <_glx_> for now I included it in the other PR
19:20:14 <truebrain> okay, let me rephrase: please make a new PR out of it 🙂 It deserves its own reasining
19:20:17 <truebrain> for future reference 🙂
19:20:47 <_glx_> yeah yeah, but as #11109 needed 3 tries to pass CI it's a good test
19:22:12 <_glx_> I guess it was luck if we didn't trigger OOM more often
19:22:42 <_glx_> and activating json support for real just passed the limit
19:23:01 <truebrain> and I am pretty sure this makes everything run a tiny bit faster too 🙂
19:23:18 <truebrain> for debug-builds, that is
19:23:47 <truebrain> from what I read, this allows WASM to talk to Javascript in 64bit; and for debugging there is a lot more code that might do this (I think?)
19:24:20 <andythenorth> has it been 24 hours since I mentioned unmentionable things?
19:24:27 <_glx_> can't really tell, debug build is slow 🙂
19:25:27 <_glx_> debug build doesn't even reach 1x
19:29:50 <_glx_> yesterday first try failed in 18m21s, second try failed in 15m33s, third try passed in 13m11s
19:30:14 <_glx_> the new version passed in 6m10s
19:30:59 <_glx_> skippin all the i64 to something else conversion really helps
19:32:23 <truebrain> I like proper solutions for actual problems 🙂
19:32:54 <truebrain> means I also feel safe changing Release to RelWithDebInfo 🙂
19:48:56 <_glx_> I reused the screenshots, they really help 🙂
19:51:58 <truebrain> right, made a test-setup on my fork for previews .. lets see how it works
20:03:02 <truebrain> _glx_: thinking back, already for a while we had that emscripten could have random compile-times, which always made me wonder a bit wtf it was doing
20:04:03 <_glx_> other targets have random compile-times too
20:05:11 <_glx_> I checked preview compile time before and after and it's still around 14m
20:05:33 <truebrain> `fatal error: 'nlohmann/json.hpp' file not found`
20:05:38 <truebrain> meh .. guess I have to do a full rebuild 😛
20:05:52 <_glx_> yeah that fixed it for me
20:06:36 <truebrain> (making the PR for RelWithDebInfo btw)
20:06:52 <truebrain> while my new Preview code is running on my fork .. at least it is compiling .. let's see if the rest works out too 😄
20:07:24 <_glx_> should build fine now in RelWithDebInfo (when I tried yesterday it OOM)
20:08:10 <truebrain> hmmmmmm ... still the above error
20:08:34 <_glx_> restarted the container too ?
20:11:03 <truebrain> mostly a bit odd that detection does work 😄
20:12:25 <truebrain> I think I know why it happens .. but .. hmm .. let's check
20:12:57 <truebrain> I am missing `-sUSE` statements in the compile line
20:13:05 <truebrain> so it means it only works if you run cmake in the same container instance run
20:13:46 <_glx_> but it should pass the -sUSE if I follow the FindXXX
20:15:18 <truebrain> but it did download and install the other libraries
20:17:18 <truebrain> argh, preview failed as I was using a cloudflare action .. but that is being run inside the container
20:17:25 <truebrain> so annoying you can't say: stop using the container 😄
20:17:45 <truebrain> Docker image had Node15 installed .. lol
20:19:54 <truebrain> hmm .. about the `-s`, it is just weird .. it is there for other files, but not for the network_survey .. how about other network files ..
20:20:33 <truebrain> just missing `-sUSE_NLHOMANN_JSON`
20:21:00 <truebrain> ah, was looking wrong, the `-s` are there, just not nlhomann
20:29:22 <truebrain> bug in our LinkPackage.cmake
20:29:34 <truebrain> not sure why other libraries don't really have that issue
20:31:50 <truebrain> well, no, and yes, hmm .. it is a problem how I patched nlohmann for emscripten
20:39:30 <truebrain> so now I can do what I actually wanted to do 😄
20:46:47 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:53:06 *** HerzogDeXtEr has joined #openttd
20:54:13 <_glx_> oh and it worked for LZMA because we link to LibLZMA::LibLZMA
20:57:25 <truebrain> owh, lol, RelWithDebInfo makes the WASM 201MiB in size
20:57:28 <truebrain> yeah .. that is not helping anyone
21:00:22 <truebrain> I am sure there is a way to split debug information from the main stuff, but .. I don't feel like diving into that now 🙂 Getting the preview to work is more important 😛
21:35:52 *** keikoz has quit IRC (Ping timeout: 480 seconds)
21:45:04 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
21:49:21 <_zephyris> I'm looking at the loading of the extra newgrf with basesets...
21:50:08 <_zephyris> This indicates its not loaded as a static newgrf, `FillGRFDetails(master, false, BASESET_DIR);` where `FillGRFDetails` takes the arguments `FillGRFDetails(GRFConfig *config, bool is_static, Subdirectory subdir = NEWGRF_DIR);`
21:51:39 <_zephyris> I'd have thought it should be actually handled as static newgrf - though would that mess up the load order?
21:52:14 <_glx_> static are loaded after everything
21:55:17 <_zephyris> So I've set up a settings newGRF for OpenGFX2 which is just sets some parameters, which the OpenGFX extra grf can read.
21:57:14 <_zephyris> But setting the settings newGRF as a static newgrf triggers a multiplayer async warning. Presumably because a static newgrf (in this case the settings newgrf) parameter is being read by a "non-static newgrf" (the base set extra grf). Even though the extra grf is really more of a static.
21:58:50 <_glx_> basesets are not static, they are outside _grfconfig
22:01:09 <_glx_> that's why it's better to have a dedicated way to set parameters for extra grf
22:03:17 <_glx_> maybe with extra stuff in `graphicsset` setting
22:04:13 <_glx_> similar to how it's done for frivers
22:16:00 <truebrain> funny, I need to upgrade emscripten to .42, as it has node16 (instead of node15), which I need to make uploading to Cloudflare Pages work 😄
22:16:05 <truebrain> guess we will be doing that too 😛
22:16:22 <truebrain> curious if the patches still apply
22:18:54 <_zephyris> _glx_: Makes sense, but well beyond my ability I suspect 🙂
22:48:36 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:07:21 *** urdh has quit IRC (Quit: Boom!)
23:23:59 <_glx_> RelWithDebInfo linking was flirting with danger
continue to next day ⏵
