IRC logs for #openttd on OFTC at 2024-04-10
⏴ go to previous day
00:54:35 *** yiffgirl has joined #openttd
00:54:35 <yiffgirl> so, now xz is back how long till release
00:55:01 *** reldred has joined #openttd
00:55:26 <yiffgirl> normally done is april fools
00:58:49 *** talltyler has joined #openttd
00:58:49 <talltyler> Feeling fooled yet?
01:39:08 *** Wormnest has quit IRC (Quit: Leaving)
02:05:46 *** herms has quit IRC (Quit: bye)
02:48:38 *** gnu_jj_ has quit IRC (Ping timeout: 480 seconds)
02:54:00 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:00:04 *** herms has quit IRC (Quit: bye)
04:03:50 <Eddi|zuHause> so, "a:;b" is like, a is a label, an empty statement, and b is taken from an unexpected context?
04:29:25 *** silent_tempest has joined #openttd
04:29:42 <silent_tempest> Is it just me or are the grayed out names hard to read? Color contrast is not good there
04:40:36 <DorpsGek> - Update: Translations from eints (by translators)
04:43:26 *** keikoz has quit IRC (Ping timeout: 480 seconds)
04:58:31 *** D-HUND is now known as debdog
05:55:32 *** keikoz1 has joined #openttd
05:56:21 *** keoz has quit IRC (Read error: Connection reset by peer)
06:02:12 *** keikoz has quit IRC (Ping timeout: 480 seconds)
06:15:43 *** berndj has quit IRC (Remote host closed the connection)
07:01:17 <kuhnovic> silent_tempest: Isn't that the whole point of having names grayed out 😛 ?
07:02:13 <silent_tempest> I dunno seem like hitting disable all then click coal and power plant is not a bad use case?
07:03:28 <LordAro> you're not wrong, it's not a great usage for greying out
07:04:18 <silent_tempest> Change the text color or dialog color?
07:05:45 <andythenorth> I suspect it's quite font dependent, this font there is no problem with the legibility
07:05:51 <andythenorth> it's heavier weight
07:06:18 <andythenorth> the earlier example, I agree, it's not very legible
07:06:31 <silent_tempest> Yours is more readable but I think that's mostly because it's much much bigger on my screen
07:06:35 <silent_tempest> Contrast is still bad
07:07:00 <andythenorth> 'disabled controls' are always a challenging UI design problem
07:07:16 <andythenorth> in web design, where WCAG 2.2 governs this, it's a specific provision
07:07:52 <andythenorth> there has to be enough contrast between the 'active' and 'disabled' states
07:08:06 <andythenorth> but the 'disabled' state is ideally still visible
07:09:03 <LordAro> suggestions that don't require changing the colour appreciated
07:09:18 <andythenorth> UI design is not aware of many
07:09:38 <andythenorth> the conformance criteria for WCAG includes 'disabled controls can fail contrast'
07:09:41 <silent_tempest> Okay I was using a non-standard font. Reverting the font back to normal and bumbping the size helps:
07:09:59 <silent_tempest> Contrast is bad but I can read it with out strain
07:09:59 <andythenorth> your desktop OS will have similar issues
07:11:50 <silent_tempest> This is a tangent but how long should a review take?
07:16:23 <silent_tempest> I know size is a relavent factor but
07:21:38 <truebrain> ghehehe, the "date" of a nightly can be "altered" by one day by having the last commit with a timezone 😄 Clearly most of us are EU, so we never noticed 😛
07:21:45 <truebrain> "git show", which we use, by default uses the TZ of the committer
07:21:48 <truebrain> not of the local system
07:29:20 <silent_tempest> LordAro: I guess I have two ideas?
07:29:36 <silent_tempest> Empty out the color box on the legend and or add an X over the box?
07:30:27 <silent_tempest> I like the X idea but I think it requires the boxes to go trans parent
07:53:53 <andythenorth> hatching the colour boxes with a grid pattern might also work
07:54:16 <andythenorth> we have that pattern for disabled UI controls already
08:04:09 <truebrain> `jgrpp-0.57.0~50^2~132`
08:04:43 <truebrain> not sure why FindVersion did that
08:05:32 <truebrain> (I also have JGRPP in my remotes, so I have the JGRPP tags)
08:05:38 <truebrain> seems because of merges or something silly 🙂
08:05:41 <truebrain> our tag-detection is shit 😛
08:07:36 <_jgr_> It uses the wrong git command
08:07:44 <truebrain> it absolutely does, yes
08:07:46 <peter1138> I tried to make SDL fail to start, by clearing DISPLAY.
08:07:52 <peter1138> > [2024-04-10 09:07:04] dbg: [driver:1] SDL2: using driver 'offscreen'
08:07:53 <truebrain> I just wonder why it does that, and not the most obvious command
08:08:13 <truebrain> well, an issue for another day to address 😄
08:14:01 <truebrain> push before opening a PR, helps
08:43:27 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
08:59:11 <peter1138> m2 is 16 bits, so unlikely.
08:59:55 <truebrain> `High CPU timing stddev detected: 4.40% after 13976.45 ms`
08:59:55 <truebrain> It really is a bit random if benchmarking on GitHub Runners is successful or not 😛
09:00:40 <Eddi|zuHause> silent_tempest: this was before PRs, but i once had a patch sit around for a year before it was included.
09:01:09 <peter1138> The RGB CC changeset is over 10 years old...
09:01:35 <truebrain> shitty developers, not wanting to include anything worth adding!
09:01:39 <Eddi|zuHause> but did you send it in for inclusion?
09:01:50 <peter1138> Oh should I have done that?
09:03:58 <Eddi|zuHause> no, but the question was "how long can a review take"
09:05:06 <Eddi|zuHause> in that case, it's not a valid datapoint if it hasn't been sent in for review :p
09:06:22 <peter1138> (We are probably quite different from other projects in that we don't mind rewriting (non-merged) history...
09:29:22 <peter1138> > return "the extmidi driver does not work when Allegro is loaded.";
09:29:27 <peter1138> I wonder what that is about.
09:30:09 <peter1138> Hmm, race condition.
09:32:07 <peter1138> #3272, such history imported from Flyspray 🙂
09:32:40 *** ahyangyi has joined #openttd
09:32:40 <ahyangyi> we use both Allegro and SDL...? Or only one of them at a time?
09:35:08 <peter1138> Only one at a time.
09:53:55 <truebrain> peter1138: it was finally useful?! 😛
09:54:33 <peter1138> I wouldn't say finally.
10:00:54 *** shloot_ has joined #openttd
10:03:38 <truebrain> running 200 individual benchmarks at once gives a bit of a CI backlog, as it turns out 😛
10:04:52 <truebrain> I keep finding small bugs and issues with my performance suite .. but it is getting there 🙂
10:06:22 <truebrain> telling you that CallVehicleTicks took 93% of the CPU time 😛
10:08:49 <truebrain> eports/2024/04/20240409/wentbourne.sav.cpu-prof.gz```
10:08:49 <truebrain> Or this massive command .. shows you how wentbourne changed over time
10:09:10 <truebrain> `InvalidateWindowClassesData` had a huge performance impact, as it turns out
10:09:14 <truebrain> 12% speed-up because of it
10:09:44 <truebrain> sorry, not 12% .. 4%
10:15:03 <truebrain> comparing two dates isn't all that accurate in terms of total CPU, as they most likely have been executed on different CPUs. But still, it shows a trend 🙂
10:15:41 <truebrain> next up, parsing the performance metrics, hoping we can normalize the CPU difference sufficiently to show trends over time 🙂
10:17:08 <andythenorth> will the tiny timing differences find the embedded coin miner we have so far missed?
10:17:13 <truebrain> ``` Segmentation fault (core dumped)
10:17:13 <truebrain> Failed to create CPU profile```
10:17:23 <truebrain> and sometimes, the CPU profiling just causes a segfault ... nice!
10:17:25 <peter1138> What did I break now?
10:17:50 <truebrain> of a set of savegames, just one causes a segfault ... interesting
10:20:19 <peter1138> If it's a recent version it could be something like a news message...
10:24:37 <truebrain> No, 2 year old version
10:24:44 <truebrain> Could still be a news message 😄
10:25:07 <truebrain> But it only segfaults during CPU profiling, not while running normally .. which is also weird
10:28:40 <xarick> poe players don't know what openttd is
10:41:53 <peter1138> I think you hang around in the wrong places :p
10:42:35 *** locosage has joined #openttd
10:43:47 <kuhnovic> Power over Ethernet :P?
10:45:12 <Eddi|zuHause> edgar allen ...?
10:45:25 <locosage> my first thought was a single poi but that's also poi...
10:47:58 <locosage> and I mean these poi
10:48:53 <Eddi|zuHause> i was thinking "point of interest"
10:50:22 <ahyangyi> kuhnovic: It might be recursive: PoE means "PoE over Ethernet"
10:50:29 *** bertvvvs has joined #openttd
11:07:11 <truebrain> takes ~45 minutes to run benchmarks on a single OpenTTD version, with the 19 savegames I have in the set now. 20 minutes of that are because of westbourne 😄
11:11:03 <kamnet> Random question. Any reason why this window needs to be fixed at this minimum width, with about half of the space being wasted?
11:12:22 <truebrain> You don't like green? 😦
11:13:15 <kamnet> The color is fine, but that takes up a lot of screen real estate
11:14:01 <truebrain> That window is just promoting the colour, showing off how awesome it is!
11:20:43 *** bertvvvs has quit IRC (Quit: You have a nice day.)
11:33:01 <peter1138> It's probably one (or more) of the industry types having lots of text at the bottom.
11:33:20 <peter1138> Default is not huge.
11:37:07 <kamnet> Ah, yes, so it seems. Its weird though since it appears that text can wrap to the next line.
11:38:39 <kamnet> Guess I'll go pester someone else! 🙂
11:39:05 <peter1138> Well, even with longer lists of cargos it's not that wide for me.
11:39:56 <kamnet> I'm guessing it has something to do with the bottom panel there, since there's no reason for that excessive vertical space to exist either
11:40:16 <peter1138> ```/* Reserve a few extra lines for text from an industry NewGRF. */
11:40:16 <peter1138> extra_lines_newgrf = 4;```
11:40:53 <_glx_> Isn't extra text only for built industries ?
11:53:34 <peter1138> It could also be your combination of font settings, NewGRFs, and interface scaling.
11:54:02 *** tabytac has joined #openttd
11:54:02 <tabytac> there are a few windows that feel that the minimum width is a bit wide, but that might just be strange scaling like you said, or JGRPP windows that i forget are not in vanilla
11:55:20 <kamnet> This is in 14.0 RC3, I had AXIS 2 loaded. I just tried with FIRS 4 and it does the same thing, so I think it's with the NewGRF. No issues when I'm running stock OpenTTD industries
12:01:00 <peter1138> It's wider if I set the medum font to Arial
12:02:47 <peter1138> Maybe the info box should be given the "set height when we know the width" treatment.
12:09:45 <kamnet> peter1138: Ahh, yes. I have mine set to Segoe UI. If I set it to the default sprite font then it goes away.
12:10:50 <peter1138> Not using OpenTTD Sans is heresy anyway :p
12:11:48 <kamnet> Yeah I should probably change all of that
12:13:23 <peter1138> After some tweaks...
12:14:01 <kamnet> Yep, width can now collapse down, it's just the vertical space
12:14:08 *** Ox7C5 has quit IRC (Ping timeout: 480 seconds)
12:14:23 <peter1138> The fixed 4 lines is...
12:14:38 <peter1138> But as it's a callback it "could" change.
12:15:38 <peter1138> Oh this is now weird, because the window is resizable, doing the deferred height thing now means it changes height when making it wider.
12:16:10 <peter1138> This is "fine" except the resize handle becomes out of sync with the cursor.
12:21:18 <peter1138> Hmm, I could use the minimum width of another widget instead of current width.
12:23:04 <peter1138> Highlights another bug...
12:28:03 <LordAro> bugs all the way down
12:44:19 <locosage> is there some way to see gs log on a dedicated server?
12:47:10 <_glx_> I think it depends on debug_level
12:47:46 <truebrain> `-d9` solves everything! 😛
12:50:23 <_glx_> ``` enum ScriptLogType {
12:50:23 <_glx_> LOG_SQ_ERROR = 0, ///< Squirrel printed an error.
12:50:23 <_glx_> LOG_ERROR = 1, ///< User printed an error.
12:50:23 <_glx_> LOG_SQ_INFO = 2, ///< Squirrel printed some info.
12:50:23 <_glx_> LOG_WARNING = 3, ///< User printed some warning.
12:50:24 <_glx_> LOG_INFO = 4, ///< User printed some info.
13:09:51 <locosage> yeah, -dscript=4 does the job, ty
13:10:12 <locosage> also, any way to restart a crashed script?
13:11:25 <_glx_> hmm probably won't work
13:25:01 <locosage> save-load does restore it
13:25:07 <locosage> this script has no state to save though
13:36:04 <xarick> There are 2 McAlpine & Co.'s
13:50:17 <andythenorth> have we discussed lunch?
13:50:35 <truebrain> I wonder how many similar CVEs exist 😄
13:50:48 <peter1138> But Rust is immune!
13:52:08 <andythenorth> Rust is immune like macOS is immune?
13:54:50 <truebrain> fun fact, the performance benchmarking would have told us about the introduction of a crash 😄 (the news thingy)
13:55:10 <truebrain> well, I would have to make it so it announces that
13:55:21 <truebrain> but that is good, at least means it would pick up things like that too 🙂
13:55:37 <truebrain> (means we don't need silly humans to tell us about it 😛 )
14:30:11 <truebrain> a game that used to take 21196 CPU seconds now taking 218 CPU seconds
14:30:16 <truebrain> you think something broke at that date?
14:30:43 <truebrain> ah, a crash report and everything
14:30:55 <truebrain> so why didn't my script pick that up ...
14:31:25 <truebrain> it still had a zero-exit-code
14:31:31 <LordAro> clearly actually just made the game 100 times faster
14:31:41 <truebrain> do we not set a non-zero exit code on crash? 😮
14:35:49 <LordAro> exit code 0, but with a signal?
14:40:56 *** gelignite has joined #openttd
14:40:57 <_glx_> fmt uses `terminate()` for assert
15:01:16 <LordAro> hang on, is that nearly 546 translators?
15:08:25 <FLHerne> a handful rejected for various reasons
15:09:12 <FLHerne> I don't think it's *that* high considering the number of languages
15:09:19 <_glx_> github says 263 in 64 teams
15:11:47 <LordAro> it was more of a "huh, neat" than suggesting anything was wrong
15:14:29 <truebrain> where did you see the number 546? (I am curious 😄 )
15:15:29 <truebrain> of that 546, there are also a few Pull Requests 😛
15:15:53 <truebrain> but yeah, doing GitHub registrations really helped in the amount of signups 😄
15:15:57 <_glx_> and some forever open because dumb users
15:23:56 <truebrain> right, what was I doing .. ah, yes, I couldn't depend on exit-code .. so .. check for a crash-log? Hmm
15:24:15 <truebrain> that might also have failed to generate, I guess
15:25:50 <truebrain> on Windows at least it is documented that abort() returns error code 3
15:27:21 <truebrain> lolz, it segfaults during the creation of the crash log
15:28:49 <truebrain> okay, and on linux I get return code 2 on a crash
15:29:08 <truebrain> so why do I get a zero back for these performance tests? 😄
15:31:09 <Eddi|zuHause> "fatal error: no error"?
15:33:26 <LordAro> shell exit code isn't necessarily the same as process exit code
15:33:41 <LordAro> depending how you're measuring
15:33:54 <truebrain> but for most crashes it has been at least non-zero
15:38:29 <truebrain> ah, it is `perf` that is not picking up on the crash
15:38:39 <truebrain> normally `perf` forwards the exit code of what it is testing
15:38:42 <truebrain> but not in this case!
15:39:32 <_glx_> so crash, but it's fine, just pretend nothing happened
15:40:35 <truebrain> `/usr/bin/time perf stat -r5 bash -c "exit 4"` for example says `Command exited with non-zero status 4`
15:40:51 <truebrain> but in this case, it just goes: NAH, all good bro!
15:41:52 <LordAro> `/usr/bin/time perf stat -r5 bash -c "kill -STOP $$"`
15:42:27 <LordAro> oh wait, that's not doing what i think it's doing
15:43:15 <LordAro> 'kill -ABRT $$' works though
15:43:29 <LordAro> well, errors and doesn't report it
15:49:07 <truebrain> okay, if I execute it via a bash script, it does work how I would expect it to 😛
15:49:25 <Eddi|zuHause> you use SIGSTOP with SIGCONT
15:49:38 <LordAro> yeah, i copied from the internet without thinking :)
15:50:14 <Eddi|zuHause> also, i'm lazy so i usually use killall instead of kill :)
15:50:54 <truebrain> funny .. if I use a script that does "bash -c ./openttd ..", it works, but if I do that inline, it doesn't 😛
15:51:05 <truebrain> shell interactions .. when you think you understand them
15:55:05 <_jgr_> Using exec in your script to get rid of the extra process may help with this?
15:57:46 <truebrain> can't get it to work without an extra shell-script even 😛
15:57:53 <truebrain> I can't promise I understand what is happening 🙂
16:01:17 <truebrain> `bash -c "trap '' SIGINT; ...` does the trick
16:21:12 <truebrain> for some reason, my brain was like: let's run a performance benchmark of each quarter .. so I did 2022-01-01, 2022-03-01, 2022-06-01 and 2022-09-01
16:21:17 <truebrain> as those are indeed all 4 3 months apart
16:21:23 <truebrain> /me goes sit in a corner now ... stupid math
16:23:54 <truebrain> `Performance measurement failed: savegame crashes the game.` at least I fixed the exitcode bug 😄
16:24:42 <_glx_> crash during loading or while running the save ?
16:24:59 <truebrain> I do not make that difference 🙂
16:25:02 <_glx_> hmm loading should not crash though
16:25:15 <truebrain> this is with OpenTTD as it was in 2023, to be clear
16:25:30 <_glx_> worst case should just fail to load
16:25:43 <truebrain> who knows what bugs we once had 😛
16:25:52 <truebrain> but my benchmarking tool at least deals with it correctly now 🙂
16:27:23 <truebrain> ugh; I forget to store what "yesterday" is .. as it might not be the day before, when there were days without commits 😛
16:27:28 <truebrain> such sloppiness ...
16:29:35 <_glx_> days without commits usually means we didn't noticed eints workflow was disabled 🙂
16:50:57 *** Wormnest has joined #openttd
17:41:08 *** _zephyris has joined #openttd
17:55:04 <kuhnovic> Time to run some of the X-files: the 70K ship saves from Xarick
17:59:27 <xarick> oh no... it was closed
17:59:50 *** keikoz1 has quit IRC (Ping timeout: 480 seconds)
18:01:30 <kuhnovic> Don't worry, it will come back... at least parts of it 🙂
18:22:37 <kuhnovic> xarick: I really hope you don't find any nasty edge cases this time 😛
18:24:31 *** HerzogDeXtEr has joined #openttd
18:30:54 <truebrain> and ... GitHub Actions are acting up 😛 I AM BUSY DESIGNING STUFF ffs 😛 😄
18:38:53 *** gelignite has quit IRC (Quit: Stay safe!)
19:07:02 <xarick> now starting the 70k save
19:09:14 *** SigHunter has joined #openttd
19:38:41 *** gelignite has joined #openttd
19:46:50 *** keikoz has quit IRC (Ping timeout: 480 seconds)
20:18:36 <xarick> a very busy canal with a depot
20:18:44 <xarick> can prevent ships from leaving depot
20:21:22 <_glx_> yes the free exit check catches a little too much
20:24:01 <xarick> can't spot any lost ship
20:28:47 <silent_tempest> okay I tried to rebase my changes on the update master branch and it thinks all of those changes are part of the PR despite them already being on the master branch?
20:30:55 <silent_tempest> Really expected it to just move the target of the PR to the update to date commit and only show the one actual commit I made that is not part of master
20:33:12 <_glx_> how did you rebase? your commits should be on top but they are not
20:33:26 <silent_tempest> they are on top in git log
20:33:35 <silent_tempest> Seems like I lost my branch tracking some how though
20:34:01 <silent_tempest> I used to be tracking origin/fixes now it's in a detached head state?
20:37:58 <silent_tempest> Man something is wrong my rebase
20:39:53 <silent_tempest> I'm really tempted to just close/delete everything and just start over with the actual commit I made on a fresh branch and then a fresh PR
20:40:11 <silent_tempest> Seems way easier then trying to untangle what ever the fuck is going on here
20:40:46 <_glx_> I'm ready to push (not squashed your commits but I can too)
20:42:23 <silent_tempest> Like literall how?
20:42:38 <silent_tempest> I typically can read docs and figure what's wrong
20:42:54 <silent_tempest> What I did to get into that state and then how not to do it again but I'm at a loss here
20:43:02 <_glx_> first I did `git reset b43910e798 --hard`
20:43:08 <silent_tempest> Log looks completely fine right now but it's fucked
20:43:57 <_glx_> then I removed the left over file (from a now discarded commit)
20:45:23 <_glx_> then the usual `git fetch upstream` followed by `git rebase upstream/master`
20:45:50 <silent_tempest> I think I did a git pull upstream first
20:46:02 <silent_tempest> And then I went back and tried a git pull --rebase later
20:48:08 <_glx_> anyway there's often a way to fix the mess 🙂
20:48:57 <silent_tempest> Yeah honestly this like a thing I'm sure I could learn on a whiteboard
20:49:04 <silent_tempest> But not maybe from a text chat lol
20:49:16 <truebrain> one thing that I advise most people when learning / working with git .. do not use `git pull`. Use `git fetch` + `git rebase` (or `git merge`). `git pull` is just a disaster of a command
20:50:29 <_glx_> yeah I only use pull when I'm in a clean fork (like for vcpkg)
20:51:00 <silent_tempest> git pull --rebase is fetch + rebase right?
20:51:07 <truebrain> I just banned the command from my memory 😛
20:51:18 <silent_tempest> I think I forgot the rebase flag once some where and that's what fucked me
20:51:22 <truebrain> the issue with `git pull` is: towards which branch does it rebase/merge?
20:51:33 <truebrain> I mean .. I am on my feature branch
20:51:36 <truebrain> so my upstream is my fork
20:51:40 <truebrain> not the upstream repo
20:51:54 <truebrain> so it becomes just a bit ... annoying, to handle that command cleanly
20:51:59 <silent_tempest> I would assume it follows the tracking right?
20:52:04 <truebrain> while a `git fetch upstream && git rebase upstream/master` is obvious what it is going to do
20:52:17 <_glx_> in your case it merged upstream on top of your fork
20:52:25 <silent_tempest> Yeah I see that now
20:52:31 <_glx_> which is exactly waht you did not want 🙂
20:52:40 <truebrain> git is not designed for mere mortals
20:52:54 <silent_tempest> I guess I never ever tried doing "git show origin/fixes" and surprising it worked
20:53:00 <silent_tempest> And yeah that log it messed up
20:53:21 <_glx_> but as said, nothing unfixable
20:53:28 <truebrain> been testing out jujutsu, which still uses git on the background. It solves more than a few of these annoying workflow problems. Does introduce a few others they need to fix first for it to become "mainstream" ready 🙂
20:53:40 <silent_tempest> I mean nothing is unfixable... There's always the black magic of the reflog
20:53:57 <silent_tempest> But I almost always get myself into deeper trouble when I open that pandora's box
20:54:04 <_glx_> yup, reflog to see where to reset to
20:54:29 <silent_tempest> Anyways, should I try to fix it or just let you do it?
20:55:27 <_glx_> I fixed it locally already, just waiting before using force push
20:56:00 <_glx_> (doing it without asking first is bad 😉 )
20:56:06 *** nielsm has quit IRC (Ping timeout: 480 seconds)
20:57:09 <silent_tempest> I am also kind of confused by Peter's last comment asking me to squash the 2 commits TBH.
20:57:31 <silent_tempest> I remember closing PR's at my last job with a "Squash and rebase" option
20:57:40 <_glx_> I just fixed the rebase, not squashed the commits
20:59:14 <silent_tempest> But that he asked me to squash them manually either means he doesn't know about that option or that he doesn't want me to do that for some reason. Or maybe it's been disabled by some github repo rull?
20:59:49 <silent_tempest> brb I'll try to squash them again in like an hour.
21:00:40 <_glx_> we can always squash on merge
21:01:36 <_glx_> here the comment was more about when reviewing at commit level, some code is added, then removed on the next commit
21:28:51 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
21:39:06 *** keoz has quit IRC (Ping timeout: 480 seconds)
21:41:33 *** gelignite has quit IRC (Quit: Stay safe!)
22:15:15 <truebrain> in case anyone feels like pressing buttons 🙂
22:15:44 <truebrain> did kuhnovic ever post his image in the post? Seems not .. sad 😛
22:15:48 <peter1138> And only one backport request 😉
22:32:40 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
22:37:00 <silent_tempest> Okay I think that PR is finally fixed up. Thanks _glx_
22:53:40 <truebrain> Awh, I did rebase before I pushed .. odd that the changes are no longer there. Even pushed with porcelain ... whatever, will fix tomorrow
22:54:37 <truebrain> Lol @ 12477 .. handling mouse events during handling of mouse events? Scary shit
22:54:57 <_glx_> yeah that's the weird part
22:57:34 <peter1138> Does it actually save the settings when you change the max competitors?
22:59:44 <_glx_> it's not supposed to reenter in window proc
22:59:55 <_glx_> it does not on my machine
23:01:18 <peter1138> SHFileOperation is a bit of a weird thing...
23:01:31 <_glx_> it doesn't finish writing anyway
23:01:52 <_glx_> only generic and private are done at this point
23:02:41 <peter1138> openttd.exe!IniFile::SaveToDisk(const std::string & filename) Ligne 112 C++
23:02:49 <peter1138> ` SHFileOperation(&shfopt);`
23:03:00 <_glx_> that's doing the private_ini one
23:03:28 <_glx_> "Copies, moves, renames, or deletes a file system object. This function has been replaced in Windows Vista by IFileOperation."
23:03:44 <_glx_> guess it's time to discard it and use the replacement
23:07:59 <_glx_> ha no, it's actually writing "secrets"
23:08:14 <_glx_> could be an affect of writing to dropbox
23:09:37 <_glx_> and we don't check return value
23:13:44 <peter1138> So SHFileOperation allows shell hooks do to things, so I guess anything could happen..
23:14:57 <peter1138> Something like co-operative multitasking that we haven't asked for at this point 😄
23:16:09 <peter1138> On the other hand, WndProcGdi is meant to be reentrant, I think.
23:17:24 <peter1138> Ours looks decidedly not reentrant.
23:22:50 <_glx_> IsLocalCompany() should return true (based on the value I can read
23:31:12 <_glx_> seems we don't set `hwnd` field in the structure, but the flags should prevent the need for it
23:31:57 <peter1138> It's basically because WndProc needs to be re-entrant. Ours is not. I think that might be a WontFix for 14.0 🙂
23:35:24 <peter1138> I think IFileOperation is still a shell thing so potentially doesn't change anything here.
23:45:39 <peter1138> > std::rename is a function in the <filesystem> header (C++17 and later) that renames or moves a file or directory within the same filesystem.
23:45:39 <peter1138> > It aims to be more modern and safer than the older rename from <cstdio>, offering platform-independent behavior and stricter error handling.
23:47:39 <peter1138> Looks like it specifies overwriting behaviour?
23:50:00 *** ChanServ sets mode: +v tokai
23:52:59 <peter1138> I have no idea, but worth a shot?
23:56:33 *** tokai|noir has quit IRC (Ping timeout: 480 seconds)
continue to next day ⏵
