IRC logs for #openttd on OFTC at 2024-01-05
⏴ go to previous day
00:06:36 <peter1138[d]> Yeah, with global params we never reset them.
00:06:49 <peter1138[d]> Hmm, #11680 doesn't seem to have fixed this hang I get.
00:12:56 <peter1138[d]> So template predicates are basically lambdas?
00:18:05 <_glx_> uses `void SetParam(size_t n, const std::string &str) { this->SetParam(n, str.c_str()); }`
00:19:41 <_glx_> so yeah most likely to be the one "corrupting" param 4, and with bad luck a news message requiring only param 0 to 3 was triggered
00:23:48 <peter1138[d]> Seems odd to be passing a string only for it to be changed to a pointer.
00:24:15 <peter1138[d]> But, something to avoid making copies I suppose.
00:24:49 <Rubidium> ugh... that's going to be a PITA. You can't easily clear all params after a GetString, as there might be multiple with the same few parameters... So maybe clear it just before those instances where the string params are backed up. Or maybe better, get rid of the string param backup and immediately write into the string parameter list that the current backups go to?
00:25:59 <peter1138[d]> So my idea was for News to have its own StringParameters, but that gets tricky with internal implementation stuff :/
00:29:58 <Rubidium> what about a subclass of StringParameters that has an array/vector with std::strings to backup to?
00:30:52 <_glx_> some kind of transforming to SCC_ENCODED string ?
00:30:58 <Rubidium> or just filling a vector<StringParameterBackup>?
00:31:28 <_glx_> hmm std:variant for param may solve it
00:31:50 <_jgr_> It isn't necessary to have a different type, StringParameters can already store string contents
00:31:51 <_glx_> no reading, just a copy of the value
00:33:23 <_jgr_> The backup function could change parameters from the non-stored to stored form to get around the lifetime issue
00:34:44 <Rubidium> _jgr_: the problem is that there is an unused parameter that's already lost its lifetime way before the backup is made, from a completely different location in the application
00:35:46 <Rubidium> but still it tries to make a backup, because at that point it doesn't really know how much parameters are actually valid/used
00:36:16 <_glx_> if StringParameters use std::variant you remove the weird "get a string, if it's not get a number" from CopyDOut
00:36:51 <_glx_> just check the alternative and transfer
00:37:55 <_glx_> the "broken" parameter is unused by the string causing the backup
00:38:12 <_glx_> else it would have been overwritten
00:38:52 <Rubidium> _glx_: that doesn't help, because you'd have std::variant<uint64_t, const char*, std::string> and you'd be working with the const char* in that case, which would be invalid...
00:39:29 <_glx_> oh right can't string_view from broken
00:39:35 <peter1138[d]> Is where I got with that, and then fixed something else.
00:39:36 <Rubidium> if we were to remove const char* and just always allocate a std::string it'd be fine
00:40:43 <peter1138[d]> This doesn't address the backup parameter stuff though, that's another patch.
00:41:36 <_glx_> we already copy non const std::string
00:41:47 <_glx_> we could also copy const ones
00:42:18 <peter1138[d]> also with that I'm not sure if std::unique_ptr<std::string> vs std::string is necessary
00:42:33 <Rubidium> we *move* non const std::string
00:42:42 <_jgr_> std::string is 24 bytes, std::unique_ptr is 8
00:43:14 <_jgr_> The std::variant will end up being the biggest type + 1, rounded up for alignment
00:43:50 <Rubidium> when I wrote it there was some bike shedding that I should avoid std::variant
00:44:09 <peter1138[d]> I... don't remember that.
00:44:39 <_jgr_> You could save a tiny bit of memory by doing the union stuff yourself, but it doesn't seem worth that hassle
00:44:54 <peter1138[d]> unions are bad in c++
00:45:06 <_jgr_> std::variant is a union inside
00:45:09 <peter1138[d]> You cannot put a unique_ptr in one, for instance.
00:45:56 <_jgr_> You can, you just have to write the union's constructor/destructor yourself
00:46:13 <_jgr_> Not really worth it here
00:46:52 <peter1138[d]> I'm not sure size is an issue anyway (as long as we're not dealing with 1000 parameters), but avoiding copies is useful.
00:48:44 <Rubidium> maybe the better solution would be to use a sub-class of StringParameters that always copies the string, and use that instead of CopyOutDParam. Then you have stricter control over what is copied, and you won't be copying too much
00:49:07 <Rubidium> not sure whether that's really viable though
00:49:45 <peter1138[d]> ```auto np = AddNewsItem(STR_NEWS_NEW_VEHICLE_NOW_AVAILABLE_WITH_TYPE, NT_NEW_VEHICLES, NF_VEHICLE, NR_ENGINE, index);
00:49:45 <peter1138[d]> np->SetParam(0, GetEngineCategoryName(index));
00:49:45 <peter1138[d]> np->SetParam(1, PackEngineNameDParam(index, EngineNameContext::PreviewNews));```
00:50:02 <Rubidium> as it sounds like a massive undertaking given the CopyOutDParam of the error GUI
00:50:20 <peter1138[d]> That is roughly where I went. Allocate news item, then add parameters directly to it.
00:50:47 <peter1138[d]> news item has its own StringParameters.
00:51:13 <peter1138[d]> Assignment in a lambda might be better.
00:51:15 <_glx_> yeah the backup is it's own 🙂
00:53:19 <peter1138[d]> Anything that calls GetString with it can use GetStringWithArgs, but all the gui stuff needs global parameters. So it might be a case of just using GetStringWithArgs there too and passing the std::string to gui.
00:54:09 <_glx_> all stuff using CopyOutDParam could be modified to directly set its own param
00:54:44 <peter1138[d]> News and errors and not a lot else, iirc.
00:55:10 <_jgr_> You could add a `StringParameters &` parameter to `Window::SetStringParameters` if you fancied a big diff
00:56:29 <_glx_> actually the main issue with CopyOutDParam is the number of copied parameters, it's always more than the string requires
01:00:49 <peter1138[d]> Oh, I spend up the ScriptList stuff a bit mroe.
01:00:50 <_glx_> a hacky solution could be to put the number of used parameters in param 0 and fill the data with an offset, then CopyDOutParam can read whats in 0 to know how much to copy and remove the offset during the copy
01:01:20 <peter1138[d]> A less hacky solution is to tell copydoutparam how many parameters to copy.
01:01:59 <_glx_> you would need to analyse the string to know
01:02:25 <peter1138[d]> No, the caller (who sets up the copied DParams) would know.
01:02:42 <_glx_> ha yes extra param to callee
01:02:44 <peter1138[d]> But I don't think that's a good solution.
01:05:45 <peter1138[d]> Hah regresion fails, I broked it.
01:07:56 <peter1138[d]> Oh, no, I had an unzipped GS which caused the duplicate warning :p
01:09:38 <_glx_> yeah it's annoying, some GS don't change internal version when they are updated on bananas
01:10:19 <peter1138[d]> I don't think bananas has anything to do with me unzipped a GS to test things 🙂
01:11:14 <_glx_> true, but usually it's stuff I got from bananas "breaking" regression for me
01:12:26 <_glx_> then I need to find the archive to delete, because of course the external name doesn't always match the internal one
01:13:14 <_glx_> (could be forks without change of the info)
01:14:29 <_glx_> oh I see the speed up, you cache deity and owner 🙂
01:16:09 <_glx_> wow it's crazy how it improves
01:17:50 <peter1138[d]> Yeah, all without groups caching vehicles 🙂
01:18:25 <peter1138[d]> Haha I was just wondering why my framerate was still high...
01:18:38 <peter1138[d]> It's because I'm running both old and new code to verify that it returns the same...
01:19:39 *** Tirili has quit IRC (Quit: Leaving)
01:23:27 <_glx_> just checked, we use the same `<whatever>->owner == ScriptObject::GetCompany() || ScriptCompanyMode::IsDeity()` for almost all lists
01:29:53 <_glx_> depotlist, stationlist and waypointlist
01:30:36 <peter1138[d]> dbg: [misc] [Default new] 1027 us [avg: 1027.0 us]
01:30:36 <peter1138[d]> dbg: [misc] [Default old] 1282 us [avg: 1282.0 us]
01:30:45 <peter1138[d]> Slight but not as marked improvement for that one.
01:31:26 <peter1138[d]> Hmm, I should be sensible and increase the averaging 🙂
01:39:30 <_glx_> at least the scripts are not responsible for gameloop duration
01:40:06 *** Smedles has quit IRC (Remote host closed the connection)
01:44:20 *** Smedles has joined #openttd
01:44:24 <_glx_> oh of course ScriptObject::GetCompany() uses at least 2 indirections, and ScriptCompanyMode::IsDeity() uses ScriptObject::GetCompany()
01:44:59 <_glx_> so yeah the "simple" `<whatever>->owner == ScriptObject::GetCompany() || ScriptCompanyMode::IsDeity()` can be pretty expensive
01:45:43 <_glx_> especially when a GS creates the lists
01:46:10 <_glx_> for AIs the deity part is skipped
01:46:43 <_glx_> oh no, not when they don't own the thing
01:49:42 <_glx_> peter1138[d]: it's still a 20% improvement
02:14:50 <peter1138[d]> That is quite significant considering it is just the locals.
02:15:12 <peter1138[d]> Of course, artificial test case, but.
02:31:17 <_glx_> but yeah that's a noticeable improvement for a small change
02:42:09 <peter1138[d]> I probably ought to sleep rather than trying to invert conditions without errors at 2:40am.
02:44:41 <peter1138[d]> But also code-duffing can be a separate commit/PR.
02:47:21 *** herms has quit IRC (Ping timeout: 480 seconds)
03:37:04 *** Wormnest has quit IRC (Quit: Leaving)
03:56:54 *** debdog has quit IRC (Ping timeout: 480 seconds)
04:04:19 *** D-HUND is now known as debdog
08:35:02 <andythenorth> TIL, autoreplace doesn't close all the buy menu variant trees when reload_newgrfs is used
08:35:18 <andythenorth> this is convenient for my testing
08:37:40 <peter1138[d]> Does the buy menu?
08:40:48 <peter1138[d]> Hmm, Xorg just crashed 😒
08:41:34 <peter1138[d]> Hmm, possibly drivers updated underneath or someting.
08:41:51 <peter1138[d]> > [2221968.943] (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
08:42:00 <peter1138[d]> Guess which file that's in...
08:42:30 <andythenorth> I read that as "Zorg crashed"
08:42:34 <andythenorth> phonetically, in my head
08:50:01 *** keikoz has quit IRC (Ping timeout: 480 seconds)
08:51:56 <truebrain> so after #11686, how much faster is #11676 still?
08:55:00 <peter1138[d]> But less text makes it faster 😉
08:56:05 <truebrain> I forgot, that is how compilers work; they are just people rented by the ltter 😄
08:56:45 <truebrain> btw, the last two inner-ifs could use a bit of DeMorgan I guess 🙂
08:57:03 <truebrain> and having continues makes it a lot more readable 😄
08:57:19 <andythenorth> how much text can I put in GS Storybook window now? 😛
08:57:34 <andythenorth> "same as before: not too much"
08:57:45 <LordAro> truebrain: funny how opinion has changed on that
08:58:06 <LordAro> no more one return at the bottom of the function
08:58:26 <truebrain> did people have other opinions about that?
08:58:38 <truebrain> I am a big fan of early-returns btw; just in general
08:58:46 <LordAro> it's required in various style guides
08:59:14 <LordAro> the older ones, anyway
08:59:23 <truebrain> I wrote software for the military for a while; what you learn there is to write defensive code. Code that can't possibly break, or be wrong. Rule #1 there is: early-returns
08:59:45 <truebrain> as it is 1000x easier to validate code when at the beginning of your function(block) you return for what-ever condition is not applying to your function
08:59:48 <truebrain> than any other form 😛
09:01:14 <truebrain> aaahghhh, whitespace ❤️
09:03:18 <peter1138[d]> Yeah, de Morgan would be... I've done that joke.
09:03:37 <truebrain> the 3rd one is a bit more tricky
09:03:53 <truebrain> well, I guess not, also a bit more readable 🙂
09:04:30 <truebrain> it is easier to review if you don't btw 😛 But as you did it for a few others already 🙂
09:04:36 * andythenorth googles 'early returns'
09:04:58 <andythenorth> I do early returns a lot, but I assumed that was because I'm not a programmer
09:05:11 <andythenorth> I can't evaluate lots of if / else, especially if it's nested
09:05:22 <peter1138[d]> Nesting if/else is bad.
09:05:27 <andythenorth> I don't do proper programming, I make too many mistakes
09:05:35 <andythenorth> I have to defend me against me
09:05:42 <truebrain> lot of SAST these days complain if you nest more than 3 times
09:05:48 <truebrain> either make a function or .. stop nesting 😛
09:06:13 <peter1138[d]> If ever I've used the "duff" as a verb in relation to code, it means to replace nested if/else with early returns.
09:06:43 <LordAro> peter1138[d]: and not in reference to duffs device? :p
09:06:55 <truebrain> now I am so curious why templating this makes it slower 😄
09:07:23 <peter1138[d]> The templated method was pretty understandable, but sadly slower.
09:07:32 <peter1138[d]> Ah, well, I'm probably doing that wrong.
09:07:35 <truebrain> an easy way for us to test it?
09:07:52 <truebrain> bit too complicated for godbolt I guess
09:07:54 <peter1138[d]> LordAro, well... better to overload terms and cause confusion, right?
09:12:33 <truebrain> do I have wentbournce savegame anywhere .. goooood question
09:13:30 <peter1138[d]> And you call yourself a developer...
09:13:39 <truebrain> on a "new" computer 😛
09:13:48 <truebrain> I did recover my savegame archive, but .. where did I recover it to 😄
09:14:08 <peter1138[d]> dbg: [misc] [template] 104 us [avg: 104.0 us]
09:14:08 <peter1138[d]> dbg: [misc] [template] 270 us [avg: 270.0 us]
09:14:08 <peter1138[d]> dbg: [misc] [template] 215 us [avg: 215.0 us]
09:14:08 <peter1138[d]> dbg: [misc] [template] 148 us [avg: 148.0 us]
09:14:08 <peter1138[d]> dbg: [misc] [template] 107 us [avg: 107.0 us]
09:14:09 <peter1138[d]> dbg: [misc] [template] 104 us [avg: 104.0 us]
09:14:16 <truebrain> not at a place it should be .. sad ..
09:14:25 <peter1138[d]> That isn't slower now...
09:15:02 <peter1138[d]> I wonder if the locals change helped....
09:15:39 <LordAro> although (based purely on the function signature you presented) i'm not sure it's actually better overall
09:15:41 <truebrain> owh, seriously, I did a lot of work to recover my "savegames" repository ... but not on this disk? I guess I did that on the other disk .. lol
09:17:46 <truebrain> I like how CoPilot wrote the whole function just based on your template definition 😄
09:20:10 <truebrain> I am very annoyed I again lost my archive of savegames 😛 Especially I remember I recovered it recently ... I am getting old 😦
09:21:30 <peter1138[d]> Oh I left a ticc/tocc in there lol
09:22:03 <truebrain> you did forget one too btw
09:22:43 <peter1138[d]> Yeah, I think that was giving up when it was slower.
09:23:40 <truebrain> could/should make `FindVehiclesWithOrder` static or inline, I guess
09:23:55 <truebrain> although I hope every compiler inlines this already
09:24:42 <peter1138[d]> dbg: [misc] [template] 364 us [avg: 364.0 us]
09:24:42 <peter1138[d]> dbg: [misc] [discrete] 172 us [avg: 172.0 us]
09:24:42 <peter1138[d]> dbg: [misc] [template] 441 us [avg: 441.0 us]
09:24:42 <peter1138[d]> dbg: [misc] [discrete] 171 us [avg: 171.0 us]
09:24:49 <peter1138[d]> Yeah, so that one is still slower.
09:25:11 <truebrain> one could argue it is still much faster than the old way 😛
09:25:12 <peter1138[d]> Maybe I should switch them around... might be cache related.
09:26:46 <peter1138[d]> dbg: [misc] [discrete] 366 us [avg: 366.0 us]
09:26:46 <peter1138[d]> dbg: [misc] [template] 174 us [avg: 174.0 us]
09:26:46 <peter1138[d]> dbg: [misc] [discrete] 389 us [avg: 389.0 us]
09:26:46 <peter1138[d]> dbg: [misc] [template] 301 us [avg: 301.0 us]
09:26:46 <peter1138[d]> dbg: [misc] [discrete] 431 us [avg: 431.0 us]
09:26:47 <peter1138[d]> dbg: [misc] [template] 184 us [avg: 184.0 us]
09:26:56 <peter1138[d]> I know what it is.
09:26:58 <truebrain> that is just funny 😄
09:27:12 <peter1138[d]> I do list->clear() between them.
09:27:30 <peter1138[d]> Let's add a shrink to fit.
09:28:59 <truebrain> what you simply could do, is not do a TICC/TOCC on a single run
09:29:05 <truebrain> but put a for around it, to do like 1000 runs
09:29:10 <truebrain> that way all cache issues etc disapate
09:29:20 <peter1138[d]> I don't want to click this 1000 times lol
09:29:26 <truebrain> you can program, can you?
09:29:38 <truebrain> let me help you: `for (int i = 0; i < 1000; i++) {`
09:30:51 <peter1138[d]> for (int i =0; i < 1000; i++) { ./openttd } didn't help
09:31:03 <truebrain> .... you ...... you ......
09:31:10 <peter1138[d]> Do I need to cache it in groups?
09:31:24 <truebrain> Original size: 15MB. gzip: 2.1MB. bzip2: 700KB. xz: 180KB
09:31:32 <truebrain> sometimes I am amazed what compression can do
09:31:51 <peter1138[d]> dbg: [misc] [discrete] 164204 us [avg: 164.2 us]
09:31:51 <peter1138[d]> dbg: [misc] [template] 159002 us [avg: 159.0 us]
09:31:51 <peter1138[d]> dbg: [misc] [discrete] 157986 us [avg: 158.0 us]
09:31:51 <peter1138[d]> dbg: [misc] [template] 153218 us [avg: 153.2 us]
09:31:51 <peter1138[d]> dbg: [misc] [discrete] 151552 us [avg: 151.6 us]
09:31:53 <peter1138[d]> dbg: [misc] [template] 146832 us [avg: 146.8 us]
09:32:00 <truebrain> normalized results \o/
09:32:08 <truebrain> so template is even SLIGHTLY faster 😛 😛
09:32:14 <truebrain> (pretty sure that is not true)
09:32:37 <peter1138[d]> Let me try another way 😄
09:33:15 <peter1138[d]> That was 1000 discrete + template.
09:33:52 <peter1138[d]> dbg: [misc] [discrete] 141774 us [avg: 141.8 us]
09:33:52 <peter1138[d]> dbg: [misc] [template] 153576 us [avg: 153.6 us]
09:33:52 <peter1138[d]> dbg: [misc] [discrete] 137523 us [avg: 137.5 us]
09:33:52 <peter1138[d]> dbg: [misc] [template] 147194 us [avg: 147.2 us]
09:33:52 <peter1138[d]> dbg: [misc] [discrete] 137457 us [avg: 137.5 us]
09:33:53 <peter1138[d]> dbg: [misc] [template] 147398 us [avg: 147.4 us]
09:33:57 <peter1138[d]> that is 1000 discrete then 1000 template.
09:34:15 <truebrain> that makes a tiny bit more sense 🙂
09:34:31 <truebrain> 5% slowdown, OWH NOOOOO
09:34:33 <peter1138[d]> Not all that much.
09:34:45 <truebrain> I would go for mister template; just easier to maintain
09:35:04 <peter1138[d]> The compiler might be making optimizations that only make sense because it's running 1000 times 🙂
09:46:33 <peter1138[d]> last nightly vs this PR
09:47:03 <peter1138[d]> Yes, sorry. This PR vs last nightly.
09:47:20 <truebrain> impressive difference for such a small change
09:47:22 <peter1138[d]> I'm... surprised.
09:47:26 <truebrain> and that without any caches!
09:47:31 <peter1138[d]> And no ... yeah.
09:47:43 <truebrain> in performance, nothing is ever what it appears 😛
09:49:30 <peter1138[d]> Only problem is the graph only shows 2 seconds now instead of 5s 😉
09:50:19 <peter1138[d]> Does the framerate monitor still run if the window isn't open?
09:50:33 <truebrain> that whole window is magic to me 😛
09:50:33 <peter1138[d]> Because there is a cost to it.
09:52:17 <peter1138[d]> It's the PerformanceAccumulators in the vehicle ticks that cause a slow down.
09:52:41 <truebrain> JGRPP players are weird. The starting-year ranges ... a lot
09:52:55 <truebrain> ranging from 1815 all the way up to 12024
09:53:07 <peter1138[d]> MIght be related to daylength?
09:53:18 <truebrain> I do not store correlation (yet) 🙂
09:53:30 <truebrain> I do have a sneaky idea how I can do that however 😄
09:54:14 <truebrain> some people autosave every 2 minutes, others every 120 minutes 🙂 Okay, this is fun 😛
09:55:25 <truebrain> most settings have different options .. some just one. So yeah, doing this over big numbers might allow us to remove some stuff 😛
09:55:45 <peter1138[d]> path finder penalties...
09:55:48 <truebrain> nobody enabled `keep_all_autosave` for example (on this small sample)
09:55:49 <peter1138[d]> That was the entire point 😉
09:56:23 <truebrain> similar with `newgrf_default_palette`
09:58:43 <truebrain> NoMusic isn't really popular on this single day with JGRPP
09:58:53 <truebrain> twice as many people use OpenMSX
09:59:52 <reldred> original_windows for me lmao
10:00:02 <truebrain> you are the minority
10:01:01 <peter1138[d]> I bet most are paused.
10:02:16 <peter1138[d]> Dunno what happened here... left it running.
10:02:46 <peter1138[d]> I think the GS/AI start doing lots more things at certain points, and then stop again. So the comparison isn't really fair.
10:03:15 <peter1138[d]> PR version is 5 months ahead.
10:04:07 <peter1138[d]> Yeah, each AI jumps up for a bit. The jump is of course much less now.
10:05:40 <peter1138[d]> Does the survey stuff take a savegame or something...
10:06:14 <peter1138[d]> I think the mutex changes didn't help.
10:06:25 <truebrain> attach gdb and find out!
10:07:30 <truebrain> stupid HTTP threads 😦
10:08:07 <truebrain> so the HttpThread is never shut down
10:08:43 <truebrain> it was rather simple when the HttpThread only had a mutex on the incoming requests .. but now it also has mutexes on the outgoing, which isn't making it any better 😛
10:09:03 <truebrain> does it always hang, or just sometimes?
10:09:23 <truebrain> and can you see what line in the HttpThread it is stuck at?
10:10:04 <peter1138[d]> I think it's only when it tries to transmit a survey, but I'm not 100% sure.
10:10:28 <LordAro> and does your PR contain the latest set of fixes?
10:11:10 <peter1138[d]> 555555ADE651: E8 EA 1F CB FF callq 0x555555790640 ; symbol stub for: std::condition_variable::wait(std::unique_lock<std::mutex>&)
10:11:10 <peter1138[d]> 555555ADE656: 48 8B 43 58 movq 0x58(%rbx), %rax
10:11:13 <truebrain> for sure it is the survey sending 🙂
10:11:26 <peter1138[d]> Release build so it's showing disassembly.
10:11:49 <peter1138[d]> (debug performance tests are lol)
10:14:09 <truebrain> without knowing what mutex the thread hangs on, it is a tiny bit more difficult to reason about this 🙂
10:15:35 <peter1138[d]> It can't be just me though, right?
10:15:35 <truebrain> in theory we could also block the stopping of OpenTTD till the survey is sent
10:15:57 <truebrain> but if that fails, it would block closing down the game
10:16:08 <peter1138[d]> Funnily enough... 😉
10:16:36 <truebrain> it now should be simply best effort: send out the result, and if it arrives before the game closes down: good for you!
10:16:38 <truebrain> if not .. who cares 🙂
10:18:54 <truebrain> peter1138[d]: I mostly have surveys disabled, as dev-results aren't all that interesting 🙂
10:19:25 <truebrain> okay, I do see that with the latest changes it blocks till the survey result is acknowledged
10:20:31 <truebrain> NetworkHTTPUninitialize is called after the survey is transmitted, even with a delay
10:20:51 <peter1138[d]> Oh dear, my UPS has crapped itself 😦
10:21:02 <truebrain> let me try a release build
10:21:52 <truebrain> peter1138[d]: can you reproduce this issue with frequent?
10:22:02 <peter1138[d]> Yes, debug or release does not matter.
10:22:23 <truebrain> okay, `http_curl.cpp`, line 283. Create a scope, and add `std::lock_guard<std::mutex> lock(_http_callback_mutex);` before the loop. Does that change anything?
10:23:27 <_jgr_> I ran this a few times, and it triggered once, blocking on the queue output mutex
10:23:31 <truebrain> (as for sure that is wrong, to iterate over the loop without mutex, but it might be not your issue 😄 )
10:23:36 <_jgr_> So my earlier fix was not right/correct
10:25:30 <peter1138[d]> Is there a timer for sending the survey?
10:25:34 <truebrain> I can't get it to hang here; I do see a weird delay .. but okay
10:25:44 <truebrain> peter1138[d]: no; new game, exit, always transmits a survey
10:25:51 <truebrain> the server does rate limit you btw
10:26:11 <truebrain> so you will see rate limit errors when you do that a lot in short frequency; that is expected
10:26:57 <truebrain> okay, the delay happens because it just takes a bit of time before `HTTPReceive` is called
10:27:15 <peter1138[d]> Hmm, seems to help.
10:27:32 <truebrain> if so, you manage to constantly hit a race 😛
10:28:02 <peter1138[d]> Ah, no, it's stuck now on the 4th or 5th time.
10:28:19 <truebrain> so a debug also does this you say? So you can tell me which mutex it is stuck at? 😄
10:31:43 <truebrain> ah, okay, I did write some code to delay just a tiny bit when transmitting a survey
10:31:52 <truebrain> and that now kinda fails for good reasons
10:31:55 <truebrain> let me fix that while I am at it
10:40:04 <truebrain> gives this a try peter1138[d]
10:41:22 <truebrain> _jgr_: on shutdown, you cleared the queue. I now changed that into processing the queue, which has a similar result (with the added bonus it might just so handle the pending survey transmission after all)
10:42:39 <truebrain> still not actually sure on what peter1138[d] 's games are racing
10:43:35 <peter1138[d]> If it could close the main window and then wait, I'd never notice 😉
10:45:49 <truebrain> peter1138[d]: do you have the confirmation dialog when you exit the game?
10:45:54 <truebrain> or did you change the setting it just exists?
10:46:44 <peter1138[d]> There's a red confirmation to exit window... There's a setting to disable that?
10:47:10 <truebrain> `autosave_on_exit` yes
10:47:19 <truebrain> not that I would think that that setting changes that behaviour
10:49:09 <_jgr_> On 11687, NetworkHTTPSocketHandler::HTTPReceive can't be called at all after/during NetworkHTTPUninitialize, unless I'm missing something?
10:49:31 <truebrain> no, you are right; it cannot
10:49:44 <truebrain> that if-statement change was more a pedantic statement change 😛
10:50:17 <truebrain> (initialize I intended to call HTTPReceive from the shutdown, instead of the individual callbacks 😛 I will revert that change)
10:51:33 <xarick> nice, more improvements, you worked overnight
10:51:48 <truebrain> still not a reason why the game should hang .. it all seems fine
10:53:33 <truebrain> well, at least this fixes a silly 2 second wait on shutdown; so there is that 🙂
11:04:00 *** keikoz has quit IRC (Ping timeout: 480 seconds)
11:04:03 <truebrain> okay, even without 11687, I fail to see how it can get stuck 😄
11:05:28 <truebrain> all mutexes appear to release on `_http_thread_exit`
11:08:39 <truebrain> ah, no, there is a single flow .. but that is extremely racy
11:09:14 <_jgr_> Only thing I can think of is if _http_callbacks doesn't (yet) contain the callback at all somehow
11:09:15 <truebrain> in theory, `_new_http_callbacks` could contain a callback which isn't moved to `_http_callbacks` yet
11:09:27 <truebrain> we only cancel the latter, not the first
11:09:31 <truebrain> so in theory, that could be the case
11:09:54 <truebrain> luckily, we can easily fix that now
11:12:56 <truebrain> okay ... now try that peter1138[d] 😛
11:13:25 <truebrain> that PR is actually 2 PRs in one ..
11:15:53 <_jgr_> Ah, I'd got confused with the windows version using _new_http_requests, as with that pattern the race wouldn't exist
11:16:27 <_jgr_> At leas how the windows version does it
11:17:05 <truebrain> but okay, as far as I can tell Windows cannot get locked like this; mostly as it uses a lot less locks 😛
11:17:27 <peter1138[d]> Yeah, it's best to avoid locks if possible.
11:18:17 <_jgr_> This makes me glad to have golang's channels at work 😛
11:18:43 <truebrain> this just became really messy ... I should just clean it up, honestly
11:18:53 <truebrain> also the fact libcurl can only process a single http request at the time is weird
11:19:10 <_jgr_> libcurl can, you just have to use the multi interface instead of the easy one
11:19:10 <truebrain> okay, 2 separate PRs, for 2 separate things 🙂
11:19:22 <truebrain> yeah, I know, but that was also .... painful
11:19:30 <truebrain> I tried that initially .... it hurt
11:19:48 <truebrain> but ... this hopefully is the last of these issues
11:21:48 <truebrain> _jgr_: do I see it correctly you didn't backport the latest survey stuff from vanilla? Not an issue, but I just notice some minor differences in the output of the both
11:22:22 <truebrain> in vanilla I refactored the whole thing to share with the crashlog the same information
11:22:31 <truebrain> that didn't hit your code yet (which is fine ofc)
11:22:36 <truebrain> but I also sneaked in some small changes 😄
11:22:48 <truebrain> most noticable: `survey["date"] = fmt::format("{:%Y-%m-%d %H:%M:%S} (UTC)", fmt::gmtime(time(nullptr)));` is missing in JGRPP
11:22:55 <_jgr_> Ah, if it was hiding in crashlog commits I probably missed it
11:23:54 <truebrain> also SurveyLibraries and SurveyCompiler are missing
11:24:05 <_jgr_> I will have another pass over it and check there are no discrepancies later
11:24:14 <truebrain> yeah, no worries; just so you are aware 🙂
11:27:27 <truebrain> the only other difference I can spot is in SurveyConfiguration, `survey["language"]["filename"]`
11:27:48 <truebrain> reason I mention that one, is because I am not sure if you added that code, or if that was our old code 😄
11:28:14 <truebrain> seems to be our old code
11:30:12 <truebrain> wow, we have players where their system report 256 GiB of RAM as being available
11:31:38 <xarick> i mean, real infrastructure server systems?
11:32:15 <reldred> truebrain: yeah that's bigger than my servers 😦
11:32:28 <reldred> betya they don't turn trees off
11:35:45 <peter1138[d]> With #11676 and #11686 (coincidental numbers), and Xaricks' corona test save, the GS part is quicker with a debug build than master as a release build. 😮
11:39:34 <peter1138[d]> I have no touched the header.
11:39:37 <truebrain> poor 7-zip.org .. it is unavailable 😦
11:40:05 <truebrain> the CI disagrees strongly
11:42:06 <peter1138[d]> Generating docs for compound GSTunnel...
11:42:06 <peter1138[d]> Generating docs for compound GSVehicle...
11:42:06 <peter1138[d]> Generating docs for compound GSViewport...
11:42:55 <merni> truebrain: Well I believe the evidence of my eyes which are seeing a perfectly good 7zip website :p
11:43:15 <merni> how does CI depend on 7-zip.org anyway? does it download 7-zip every time from there or something?
11:43:19 <_jgr_> Reachable in one place doesn't mean reachable everywhere 😛
11:44:00 <truebrain> Empirical evidence is no evidence .. "there are no purple elephants" .. well, proof it!
11:44:26 <xarick> i think @api all or something is missing?
11:46:11 <xarick> but it broke all lists related to vehicles
11:49:13 <peter1138[d]> Is it something about having two constructors...
11:50:29 <truebrain> that trick is used more often
11:54:04 <truebrain> okay, after filtering and parsing, 2 days ago there were 193 valid and useful survey reports from JGRPP and 63 from nightlies
11:54:35 <peter1138[d]> Proof that everyone plays JGRPP 😉
11:54:36 <truebrain> which means that over a week, there are enough results for not a single individual to actually stand out, I think 😛
11:54:52 <truebrain> shit, forgot lunch again
12:04:00 <peter1138[d]> truebrain: You'll waste away.
12:19:12 <xarick> template stuff is so funny
12:20:41 <peter1138[d]> ^ Xarick very nearly had this one...
12:21:19 <peter1138[d]> It is almost pointless though, but very simple.
12:23:48 <xarick> oh right... num_vehicle also exists
12:23:55 <xarick> there's another in the toolbargui then
12:24:30 <xarick> also some other in network somewhere
12:24:35 <peter1138[d]> I didn't see any other simple counts.
12:27:09 <peter1138[d]> Ah right, it's not a count, but could use the count instead.
12:50:15 <peter1138[d]> That autoclean test was super dumb.
12:50:23 <peter1138[d]> We only needed to know if the company had a vehicle, not how many.
12:50:40 <peter1138[d]> Pretty sure that's my code 🙂
12:54:18 *** dwfreed has quit IRC (Ping timeout: 600 seconds)
12:55:06 <peter1138[d]> Hmm, we do auto clean once a game month, AND once a game quarter.
12:56:35 *** dwfreed has joined #openttd
12:57:53 <LordAro> well one of those is redundant
12:58:50 <andythenorth> how much lunch was it?
12:59:28 <LordAro> chicken wrap from the local greek place
13:02:09 <peter1138[d]> If the monthly interval runs before the quarterly interval, yeah.
13:20:07 <peter1138[d]> Well, I can test 🙂
13:21:56 <xarick> i forgot how to create a list of vehicles in a group, and the documentation is missing... my day is ruined 🙂
13:22:58 <peter1138[d]> Such dependencies.
13:28:38 <_glx_> well the doc is available in openttd source 🙂
13:29:28 <andythenorth> are mixed-cargo consists fixed for 14.0? 🙂
13:31:42 <peter1138[d]> "mixed-cargo consists fixed" is very much lacking in context.
13:33:20 <andythenorth> specifically mixed cargo articulated engines 🙂
13:33:23 <andythenorth> seems to be fixed
13:37:46 <peter1138[d]> "mixed-cargo articulated engines fixed" is very much lacking in context.
13:40:00 <andythenorth> lol did I miss out the word "autoreplace" 😛
13:41:34 <_glx_> aarg it's annoying to use WSL to generate docs from a windows checkout
13:41:55 <_glx_> sh can't run doxygen_filter.sh because EOL
13:42:08 <peter1138[d]> Follow the path... Windows -> WSL -> native Linux.
13:43:04 <andythenorth> native Linux -> macOS -> toys out of pram -> Linux
13:43:08 <andythenorth> repeat every 7 years
13:43:24 *** virtualrandomnumber has joined #openttd
13:43:41 *** virtualrandomnumber has quit IRC ()
13:56:14 <truebrain> peter1138[d]: nice result with 11676 🙂
13:59:34 <truebrain> right .. what was I doing .. hopefully fixed the deadlock ... ah, yes, survey results .. where was I with that .. I love how easily I forgot shit in 2 hours 😛
14:03:16 <_glx_> ./doxygen_filter.sh GS script_vehiclelist.hpp > filtered.hpp
14:03:16 <_glx_> Classes nested too deep
14:04:44 <truebrain> something is missing 😛
14:05:37 <peter1138[d]> `#endif` -> `#endif /* DOXYGEN_API */`
14:06:02 <truebrain> `if("${LINE}" MATCHES "^#endif /\\* DOXYGEN_API \\*/")`
14:06:13 <truebrain> so yeah .. missing a comment 😄
14:06:23 <peter1138[d]> Yeah, I wasn't even joking 🙂
14:06:41 <truebrain> maybe we should error in SquirrelExport.cmake when the doxygen tag is not closed
14:08:21 <peter1138[d]> dbg: [misc] [StationList company] 19423 us [avg: 194.2 us]
14:08:21 <peter1138[d]> dbg: [misc] [StationList deity] 13294 us [avg: 132.9 us]
14:08:21 <peter1138[d]> dbg: [misc] [StationList company] 21799 us [avg: 218.0 us]
14:08:21 <peter1138[d]> dbg: [misc] [StationList deity] 14500 us [avg: 145.0 us]
14:08:54 <peter1138[d]> Hmm, it's consistently more expensive as non-deity, but it could just be querying a different station.
14:08:59 <truebrain> so you made a function ten times faster, and are now splitting hairs on making it even faster 😛 Now that is some nice bikeshedding 😄
14:19:08 <andythenorth> where is the nuclear reactor? 🙂
14:20:40 <peter1138[d]> Hmm, so the UPS is dying, but it doesn't report anything like "Replace Battery".
14:21:46 <peter1138[d]> I guess needing to replace the battery shouldn't make the UPS die, but these things are usually awkard.
14:21:49 <_glx_> hmm actually SquirrelExport is "broken"
14:22:41 <LordAro> rewrite in ~rust~python
14:23:13 <truebrain> I read great things about ~rust~python
14:23:23 <andythenorth> I heard PHP is the future
14:23:47 <LordAro> but you just emerged from your time machine from 2003?
14:23:47 <andythenorth> lol one can't google `~rust~python`
14:23:55 <andythenorth> it's an invalid search term
14:24:05 <andythenorth> at least in chrome
14:25:05 <_glx_> ah no, it works by luck because I used `ifdef DOXYGEN_API`
14:25:39 <truebrain> without luck, no life!
14:26:11 <_glx_> so the `#else` disabled the skip
14:35:53 <truebrain> hmm ... I need to bring some resources for the survey which I manually created under the management of the infrastructure tooling we use ... sadly, that is never actually simple 😛
14:36:03 <truebrain> just removing everything and recreating might just be easier
14:43:53 <truebrain> that indeed was the case 😛
14:44:39 <truebrain> now a very similar trick for the buckets themselves .. hmmmmm
15:12:47 <truebrain> hmm .. I need to merge a PR before I can test the GitHub workflow ...
15:12:56 <truebrain> I tested what I could, and it seems fine .. so yolo?
15:15:13 <truebrain> _glx_: mind checking if you see anything weird with that PR?
15:24:21 <_glx_> can't spot any weirdness
15:25:34 <truebrain> at least now I can test 😄
15:26:27 <_glx_> but the workflow looked fine 🙂
15:27:37 <truebrain> yeah, but there was a nasty typo
15:35:06 <truebrain> 2 errors in the end 🙂 And one in the infra
15:37:26 <truebrain> now to manually press those buttons 60 times .. lolz
15:37:47 <peter1138[d]> for (int i = 0; i < 60; i++) { ]
15:37:54 <truebrain> in GitHub Interface 😦
15:40:38 <truebrain> first PR of that kind that I am like: yeah, that motivation kinda makes sense 🙂
15:45:09 <peter1138[d]> Does inserting it in the middle cause any issues or is it all done the code.
15:45:39 <peter1138[d]> IIRC currency is local-settings-only.
15:51:20 <LordAro> is "exchange rate before converting to euro" what was used elsewhere?
15:52:12 <LordAro> "///< custom currency (add further languages below)"
15:57:01 *** virtualrandomnumber has joined #openttd
15:57:46 *** virtualrandomnumber has quit IRC ()
16:01:58 <Rubidium> there is AfterLoadGame code for currencies, and by the looks of it the currency is saved in the savegame except for network games
16:14:19 *** gelignite has joined #openttd
16:26:43 <xarick> why can't I use rawdelete?
16:27:46 <xarick> `list_of_vehicles_in_group[c].rawdelete();` - doesn't work
16:33:05 <xarick> nevermind, I found out why
16:33:23 <peter1138[d]> What kind of grammar is that?
16:33:23 <xarick> `list_of_vehicles_in_group.rawdelete(c);` - works
16:33:43 <xarick> squirrel documentation is wrong
16:34:11 <merni> peter1138[d]: The spelling is worse than the grammar
16:34:32 <merni> though "his" obviously points to a non-native speaker whose native language has grammatical gender :p
16:45:59 <_glx_> squirrel author is italian IIRC
17:48:21 <xarick> GSBase.RandRange works different than I expected
17:52:50 *** Wormnest has joined #openttd
17:53:22 <xarick> i doesn't include the max value
18:00:43 <peter1138[d]> Yeah, it's not BASIC 🙂
18:07:45 <xarick> 13.4 didn't have this yet?
18:09:32 <xarick> things really take a long time to roll out to the main game
18:09:44 <andythenorth> I know this question is silly, but when do we think 14.0 RC? 🙂
18:09:59 * andythenorth am using grf features that aren't in 13.x
18:21:09 <_glx_> xarick: properly set the api version
18:22:07 <_glx_> if you use new stuff set the api to 14
18:22:37 <xarick> I just did, I thought 13.4 already had the group functions available to gs
18:29:49 <truebrain> peter1138[d]: had a chance to test if the race still happens with my 2 PRs applied?
18:30:01 <peter1138[d]> Not yet. Too busy shaving yaks.
18:30:50 <truebrain> lol @ 11693 .. from 2ms to 0ms .. okay
18:31:01 <peter1138[d]> It looks bigger in µs
18:31:08 <peter1138[d]> (That's what she said)
18:31:10 <truebrain> I get that; but you are not getting that 😛
18:31:31 <peter1138[d]> Anyway it's good because it also removes a C array and memset 😉
18:32:16 <peter1138[d]> It's not just 2ms. It's 2ms every... minute?
18:32:26 <truebrain> omg, making the difference!
18:33:22 *** esselfe has quit IRC (Quit: 1000‰ Linux)
18:34:20 <peter1138[d]> truebrain: at least with the new timer system it's super easy to make that monthly thing happen every day so I could see it 😉
18:35:15 <Rubidium> at least three orders of magnitude improvement with a small patch that even reduces the code's complexity is definitely a win!
18:36:32 <Rubidium> and it's another multiplayer microstutter gone (or is it a millistutter ;))
18:38:43 <DorpsGek> - Update: Translations from eints (by translators)
18:42:06 <peter1138[d]> Could be more if you accidentally compiled your server a debug build... 😉
18:44:43 <peter1138[d]> #11688, it seems to fix the issue by removing code 😄
18:44:59 <peter1138[d]> truebrain: how many times have I run out now?
18:45:14 <truebrain> I think both 11688 and 11687 fix the issue, which ever you apply 😛
18:45:31 <truebrain> it is such a weird race-condition to hit; fun 🙂
18:45:49 <truebrain> 11688 fixes the actual issue, but 11687 triggers a part that avoids it ever being an issue 😄
18:45:50 <peter1138[d]> That's the thing with race conditions... they happen all the time.
18:46:50 <peter1138[d]> All those CPU side-channel bugs were just theoretical until not...
18:47:14 <truebrain> okay .. over the last 4 days (excluding today), JGRPP gave me 714 valid surveys results of 328 different savegames
18:47:33 <truebrain> a total of 4040249 seconds played
18:47:49 <truebrain> 1122 hours in 4 days
18:48:06 <truebrain> ~12 hours per hour 😛
18:48:12 <truebrain> these numbers feel weird as fuck
18:48:26 <Eddi|zuHause> how does that compare to nightly?
18:48:49 <truebrain> nightly I received 131 reports over 91 savegames for a total of 825471 seconds
18:49:10 <truebrain> very curious what 14.0 does ..
18:49:29 <truebrain> I am just wondering if those seconds are actually correct .. it sounds like a lot
18:49:51 <xarick> `if (std::any_of(std::begin(c->group_all), std::end(c->group_all), [](const GroupStatistics &gs) { return gs.num_vehicle != 0; })) SetBit(has_vehicles, c->index);` WOW, smart code!
18:49:52 <truebrain> average of 3.5 hours per savegame .. okay, that is not that much
18:50:05 <xarick> I'm learning some stuff along
18:50:39 <peter1138[d]> We're all learning.
18:51:49 *** esselfe has joined #openttd
18:52:08 <xarick> that might be the thing I need to stop making so many nested for loops
18:52:25 <peter1138[d]> Sometimes a range-for is clearer.
18:52:48 <peter1138[d]> But in this case std::any_of() makes it clear what the intention is.
18:53:38 <peter1138[d]> Okay, 11688 still blocks for a couple of seconds, 11687 does not visibly block (but it's not instant so who knows :D)
18:53:55 <truebrain> without 11687 is always stalls for 2 seconds
18:54:12 <truebrain> as there is no thread actually moving the information from the curl thread to the main thread 😛 So that lock is just ... well .. a lock 😄
18:58:26 <truebrain> it is not worth it, imo
18:58:36 <truebrain> such a micro-optimization
18:58:57 <peter1138[d]> Alexa, make a note for when its our biggest problem 😄
19:03:08 <truebrain> according to the survey, someone has been playing JGRPP on a 80486
19:07:44 <truebrain> 0.01% of the players was using 8bpp; everyone else 32bpp or better 🙂
19:10:05 <LordAro> that seems somewhat suspect
19:11:15 *** _zephyris has joined #openttd
19:11:15 <_zephyris> truebrain: Blitter or 32bpp baseset/newgrf?
19:11:28 <truebrain> ah, yeah, I should have mentioned that: blitter 🙂
19:14:32 <truebrain> okay ... I got the data ... now a frontend 😛
19:14:36 <truebrain> something for another day 🙂
19:16:51 <_zephyris> Super interesting, looking forward to seeing the data!
19:17:07 <_zephyris> Like you said, 14.0 will be _really_ interesting
19:17:44 <truebrain> absolutely; with this low amount of data you have the risk a single (group of) user influences the result a lot. I am hoping with 14.0 people enable it enough to make that a non-issue
19:19:13 <_zephyris> ie. People like me running a couple of instances in the background all day to check town growth with a new newgrf
19:19:32 <truebrain> stuff like that, yes 🙂
19:20:10 <truebrain> hmm ... for the results, I need to write Javascript ... brrrrrr 😛
19:29:22 <_zephyris> No action per minute counter or similar, right?
19:39:27 <LordAro> truebrain: the 80486, that is
19:46:35 <xarick> gonna test the new master
19:56:57 *** esselfe has quit IRC (Quit: restarting)
19:57:50 *** esselfe has joined #openttd
19:58:12 <xarick> FindVehiclesWithOrder breaks my stuff so bad, I have to rewrite
20:08:21 <xarick> oh peter, think i found a bug in your code... let me verify
20:10:06 <truebrain> _zephyris: Nope. Doesn't tell us anything really about the type of games people like to play, that kind of info
20:12:14 <xarick> it's missing the break;
20:12:51 <xarick> oh, nevermind, im too dumb for this
20:13:43 <xarick> was wondering if it should be this -> [&list](const Vehicle *v) { list->push_back(v); break; }
20:13:52 <xarick> with a break at the end
20:14:13 <_zephyris> truebrain: Fair enough. More intrusive, privacywise and implementationwise, anyway. Just handy for excluding idle/paused games.
20:15:28 <xarick> I see, it's the main function that does have the break in it
20:36:46 *** Flygon has quit IRC (Remote host closed the connection)
20:41:06 <xarick> I fail at adapting my code to this template predication
20:52:12 <xarick> i dont know how to do this... I don't iterate shared orders
20:53:36 <peter1138[d]> You can probably just replace it and not use it.
20:56:08 <xarick> I need to pass the list to the template function somehow
20:56:59 <_glx_> no need to use the template function
20:57:14 <xarick> ok, then that means deleting files :p
20:57:26 <peter1138[d]> If you don't need it, sure.
20:57:40 <_glx_> the template was added to reduce code duplication
21:01:47 <xarick> yay more conflicts to come
21:02:14 <peter1138[d]> That one already uses group statistics (hah!) so you can drop your changes there.
21:19:11 <xarick> dest_tile is 0, I dont think it pathfinds to that tile
21:19:26 <xarick> it choses some other routine
21:20:00 <xarick> individualvehiclecontroller handles that part
21:20:42 <peter1138[d]> And the only difference then is that it just won't try to find a depot every tick?
21:21:44 <xarick> yes, though I suspect there may be some side effects
21:22:36 <xarick> functions that check GO_TO_DEPOT orders... might treat that tile 0 as something they shouldn't
21:22:47 <_glx_> it just going from retrying every tick to retrying every day
21:23:02 <_glx_> and not all vehicles in the same tick
21:25:13 <xarick> I see some functions detect the depot order flag "go to nearest depot", but not sure if they all will handle that properly when they don't
21:25:39 <_glx_> in most case is to not consider it as a depot order
21:28:26 <xarick> essentially, without the change, they would still have a tile = 0
21:28:36 <xarick> and a go to nearest depot flag set
21:33:48 <andythenorth> goes it cargo compartments for trains?
21:34:04 <andythenorth> multiple cargos, but without articulated vehicles?
21:35:22 <andythenorth> vehicles in vehicles? 😛
21:35:38 <_glx_> it's called articulated vehicles 🙂
21:36:30 <_glx_> aircraft are kinda articulated 🙂
21:37:19 <_glx_> heli could carry 3 cargo in théory
21:39:46 *** georgevb has joined #openttd
21:39:46 <georgevb> Is that intended, that cargo_subtype is not changed for articulated vehicle parts on refit?
21:43:04 <andythenorth> nah ignore that, I misread
21:46:40 <truebrain> no clue if we do that consistently or not btw .. if not, ignore my comment
21:50:15 <xarick> without async, it would be 70000 ticks when mass building 70000 vehicles
21:51:21 <xarick> I can't seem to get a strict measurement of ticks
21:51:59 <peter1138[d]> Average them out.
21:52:08 <peter1138[d]> Oh, you mean game ticks.
21:55:33 <peter1138[d]> truebrain: We probably don't but using CompanyMask here was so obvious 🙂
21:55:45 <truebrain> yeah ... I should have said that instead 😄
21:57:35 <peter1138[d]> Dismissed over a tyop 😦
21:59:19 <_glx_> a bitbask is a bitmask with a cold 🙂
22:00:28 <peter1138[d]> Oh, the first go didn't pass CI.
22:01:58 <peter1138[d]> Can't see why though.
22:05:31 <peter1138[d]> Oh. I've never noticed it show as failed due to being cancelled before.
22:05:52 <truebrain> it is bloody annoying, but it is what it does 😦
22:07:33 <_glx_> it's mostly because we count the annotations
22:07:48 <_glx_> else it wouldn't be a fail
22:07:58 <truebrain> they could use a different icon for failure
22:08:55 <_glx_> the fail icon is from annotation check
22:09:09 <truebrain> owh, like that, fair fair
22:09:22 <truebrain> well you are solving problems, can you also make it NOT email me on cancel?
22:09:25 <truebrain> as really, I don't care 😛
22:10:13 <_glx_> I see my cancellation in notifications but I don't receive an email
22:10:50 <truebrain> I have it on Email me on failed workflows
22:10:56 <truebrain> which is an email when a cancellation happens
22:11:22 <_glx_> because check annotations I think
22:11:47 <truebrain> have it on all repos, including ones that have nothing to do with OpenTTD or its annotation check 🙂
22:12:20 <truebrain> you get mails like that
22:12:39 <truebrain> it nicely mentions "Run cancelled"
22:12:42 <truebrain> but if cancelled != failed
22:18:18 <xarick> increasing the number of repeated lists generated
22:36:29 <peter1138[d]> So basically if I keep updating a PR every minute I can 1) send Truebrain an email every minute and 2) get banned
22:47:28 <peter1138[d]> for (int i = 0; i < 1000; i++) { ...
22:53:35 <truebrain> happy I could help 😛
23:02:50 <xarick> without TICC TOCC overhead
23:03:14 <xarick> master does one thing faster than mine in 1 of the tests
23:03:57 <xarick> maybe I need to magnify the test
23:07:09 <xarick> those repeated tests show something strange
23:07:47 <peter1138[d]> The changes I did were not to be faster than your PR 🙂
23:08:44 <_glx_> the button rows are hardcoded to resize too
23:09:06 <peter1138[d]> You can change that 🙂
23:09:23 <_glx_> but the function generating them is used for many things
23:09:34 <peter1138[d]> Parameters are a thing 🙂
23:10:12 <_glx_> but is it a good design chang ?
23:10:55 <peter1138[d]> I don't think it changes much to be worth it.
23:11:02 <peter1138[d]> How about a single column down the side?
23:11:17 <peter1138[d]> Hmm, then it's got a minimum height which might be annoying.
23:12:28 <peter1138[d]> Hmm, that gives me an idea about my linkgraph legend change.
23:16:48 <xarick> the one about ScriptVehicleList_Depot was impressive
23:17:05 <xarick> 102 seconds vs 111 seconds
23:18:54 <xarick> and without using a cache, is impressive, to be only 9 seconds slower
23:18:56 <peter1138[d]> You group deletion is much slower.
23:18:59 <_glx_> the hole is still there, but it resize like I want
23:19:16 <peter1138[d]> Oh I'm looking the wrong way around 🙂
23:19:42 <peter1138[d]> You need a SetResize() on those buttons.
23:21:59 <_glx_> settings and reload have a SetResize()
23:26:08 <_glx_> this window has too many buttons, it's impossible to find a proper design
23:26:51 <xarick> I like the new small size for the company buttons
23:27:41 <xarick> don't forget those buttons can change the background color
23:29:38 <_glx_> seems clean, and a lot of space for the script name
23:30:32 <xarick> it could be used to display a bit more information
23:30:55 <xarick> API version being used maybe
23:31:10 <_glx_> API version is in the log
23:31:45 <xarick> until the log is filled
23:32:33 <xarick> or, maybe the company name
23:33:08 <_glx_> button colours is still visible
23:35:33 *** gelignite has quit IRC (Quit: Stay safe!)
23:37:40 <wensimehrp> zh_cn translation means "Enhanced fixed property maintenance" 😠
23:38:12 <wensimehrp> I have no idea how they got this result
23:42:12 <xarick> I wanted to export the results to excel...
23:43:16 <xarick> what tool do I use to extract a value from each line
23:44:32 <xarick> wanted to generate some nice graphs
23:44:38 <_glx_> peter1138[d]: and I was complaining about script debug, yours is worse
23:45:11 <Eddi|zuHause> awk '{ print $5 }' to select the 5th column
23:45:14 <peter1138[d]> Yes... ^ current.
23:45:46 <wensimehrp> peter1138[d]: I like this version more, mostly because the Chinese language takes less space
23:45:47 <Eddi|zuHause> awk can also do maths on it and stuff
23:46:28 <peter1138[d]> Also the icon mode...
23:46:31 <peter1138[d]> But it's still clumsy.
23:46:53 <_glx_> oh with the magic button in title bar
23:47:19 <peter1138[d]> With normal cargos it's not too bad.
23:48:08 <peter1138[d]> 11 cargos doesn't divide nicely 🙂
23:50:27 <_glx_> yeah and 5 lines because companies doesn't help
23:51:17 <xarick> > dbg: [misc] [CmdRemoveAllVehiclesGroup] 85 us [avg: 85.0 us]
23:51:17 <xarick> > dbg: [misc] [CmdRemoveAllVehiclesGroup] 0 us [avg: 0.0 us]
23:51:17 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:17 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:17 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:17 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:17 <xarick> > dbg: [misc] [CmdRemoveAllVehiclesGroup] 169 us [avg: 169.0 us]
23:51:19 <xarick> > dbg: [misc] [CmdRemoveAllVehiclesGroup] 0 us [avg: 0.0 us]
23:51:19 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:21 <xarick> > dbg: [misc] [GroupStatistics::CountVehicle] 0 us [avg: 0.0 us]
23:51:21 <xarick> Got these and others in 740k lines for each log. I wanted to extract the function used once, and then count the number of times it was found, and add the first value, not the average
23:52:09 <peter1138[d]> 5x3 for companies, and then 4x3 for cargos would fit better. but the saturation thing wouldn't fit.
23:52:32 <peter1138[d]> Anyway I'm fiddling to see if I can make it more dynamic.
23:52:36 *** keikoz has quit IRC (Ping timeout: 480 seconds)
23:53:42 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
23:54:51 <xarick> for example, I reccon I'd get a very nice graph for FreeUnitIDGenerator
23:55:14 <xarick> would start at 0 but as more vehicles are added, it starts rising
23:55:33 <xarick> it rises much quicker in master
23:55:45 <xarick> than in group-vehicle-list
23:56:16 <xarick> wanted to plot the 2 graphs comparing the growth of both
continue to next day ⏵
