IRC logs for #openttd on OFTC at 2024-03-05
⏴ go to previous day
00:19:13 <xarick> could someone take a look at this code?
00:19:13 <xarick> I need to know if I handled the passing of std::vector<TileIndex> dest_tiles correctly to the other functions. Thx in advance. I'll read replies tomorrow.
00:33:17 *** keeeek7218 has quit IRC (Quit: User went offline on Discord a while ago)
01:51:22 *** Leopold_ has quit IRC (Remote host closed the connection)
01:53:21 *** Leopold has joined #openttd
03:24:26 *** Wormnest has quit IRC (Quit: Leaving)
03:44:10 *** Eddi|zuHause2 has joined #openttd
03:47:26 *** debdog has quit IRC (Ping timeout: 480 seconds)
03:49:21 *** Eddi|zuHause has quit IRC (Ping timeout: 480 seconds)
03:49:47 *** gnu_jj_ has joined #openttd
03:52:56 *** gnu_jj has quit IRC (Ping timeout: 480 seconds)
03:58:54 *** Eddi|zuHause2 is now known as Eddi|zuHause
04:25:00 *** D-HUND is now known as debdog
06:24:46 *** keikoz has quit IRC (Ping timeout: 480 seconds)
07:23:50 *** menelaos[m] has quit IRC (Quit: Client limit exceeded: 20000)
07:26:37 <johnfranklin> Breakfast for Europe, Lunch for Asia, Dinner for Australia.
07:50:11 <dwfreed> and sleep for America
07:50:40 <johnfranklin> I guess west coast
07:55:37 <dwfreed> no, Central Standard Time, aka UTC-6
07:56:01 <dwfreed> but even on the west coast, most people would be asleep by now, as it's midnight there
09:31:02 <kuhnovic> xarick: You can pass the vector as a const reference instead of a pointer. Reference because it will always be there and can't be null. Const because you're only reading from the vector, not modifying it.
09:38:59 <orudge> truebrain: We've been granted access to the Azure signing programme :) I'll take a look into it soon and get things set up for testing
09:39:26 <truebrain> Nice! Let me know if you need any help 🙂
09:39:49 <truebrain> And lets please do this for master/15, not for 14. As we know 14 works as it is atm 🙂
10:22:17 <peter1138> I guess our sounds are quite small. 😄
10:23:08 <peter1138> Ah, that was original.
10:23:15 <peter1138> OpenSFX is a bit larger.
10:25:20 <andythenorth> my AWS bill arrived
10:25:31 <peter1138> More expensive than a MBP right?
10:48:51 *** Flygon has quit IRC (Quit: A toaster's basically a soldering iron designed to toast bread)
10:54:06 <xarick> kuhnovic: kuhnovic sorry, where exactly do I make the changes.
10:54:36 <andythenorth> peter1138: About the same price as a replacement keycap for a MBP
10:54:48 <andythenorth> also my MBP has started kernel panicking often
10:54:53 <andythenorth> so our infra might be unstable
10:55:14 <xarick> this topic is still alien to me
11:06:32 <xarick> I don't know how to do it. I'm really too dumb for this
11:15:46 <LordAro> we've been telling you for years to actually read a book, course, or other guide on how to write C++
11:16:08 <LordAro> none of us automatically knew it
11:16:43 <LordAro> not knowing something is fine
11:16:49 <LordAro> refusing to learn something is less fine
11:17:33 <peter1138> To be fair I never read a book on it 🙂
11:17:44 <peter1138> (Yes, I'm aware that shows...)
11:21:18 <kuhnovic> xarick: If you search for "std::vector<TileIndex>" in your commit you'll hit a number of function definitions. Those 😉
11:22:17 <xarick> oh, I passed as a pointer apparently
11:24:10 <kuhnovic> I think Effective C++ by Scott Meyers, although it being an old book, still covers most of the do's and don'ts of C++. And then Effective Modern C++ is a good follow up.
11:24:14 <xarick> `std::vector<WaterRegionPatchDesc> YapfShipFindWaterRegionPath(const Ship *v, TileIndex start_tile, int max_returned_path_length, const std::vector<TileIndex> &dest_tiles = nullptr);`
11:24:14 <xarick> this one complains, it doesn't like nullptr
11:24:48 <LordAro> what are you expecting it to do?
11:25:47 <xarick> it's an optional parameter in this function
11:26:00 <kuhnovic> xarick: If it's optional, make it a pointer
11:26:25 <kuhnovic> But why would it be optional? Don't you always need it?
11:26:43 <xarick> nop, ChooseShipTrack doesn't use it, at least yet
11:27:34 <xarick> maybe it will in future changes, undecided yet
11:28:51 <kuhnovic> Then pointer it is, for now
11:34:22 <xarick> sec, don't go away yet
11:42:39 <xarick> m_destTiles = std::move(dest_tiles); hmm it's different now
11:42:59 <xarick> dest_tiles remain with 523 entries
11:43:18 <LordAro> no, but dest_tiles is now invalid
11:43:27 <LordAro> like using a pointer after freeing it
11:43:39 <xarick> so i'm doing something wrong
11:43:53 <LordAro> how VS displays it is not necessarily an indication of validity
11:44:10 <xarick> ok let me try access it
11:44:19 <LordAro> you might even be able to access it
11:44:23 <LordAro> it's still wrong to do so
11:49:10 <xarick> clearly something went wrong
11:51:36 <xarick> problem: how to make it invalid, cus apparently it's not invalid
11:53:33 <_glx_> It is invalid after the move, nothing more to do
11:54:07 <LordAro> it happens to work with your specific build
11:54:13 <LordAro> most of the time, it will not
11:56:46 <_jgr_> xarick: This code makes no sense at all
11:57:40 <_jgr_> std::move will not cast dest_tiles into something that you can move assign from because it's a const reference
11:58:57 <_jgr_> If you want to do a move assignment here change the function parameter to be the value type or an rvalue reference
11:59:54 <LordAro> yeah, i was leaving aside the whole "what are you doing"
12:00:04 <LordAro> difficult to try to tackle multiple problems at once
12:02:34 <xarick> I don't know what I'm doing
12:04:26 <xarick> I have an idea of what I want to do: get a list of all ship depot tiles of a company way early, even before calling yapf, then pass it to both high level pf and low level pf. Translating this to code is where I have (mostly) no idea what I'm doing.
12:04:48 <xarick> I know I want to avoid doing copies
12:08:48 <xarick> actually, the high level pf only reads from it, it adds regions from the tiles in the list, so it's not exactly transmiting ownership. It's in the low level pf that it passes ownership
12:11:25 <xarick> as long as I keep it single attempt, there is no problem
12:21:05 <peter1138> Yeah, std::move() on const reference seems wrong.
12:25:38 <xarick> I asked Copilot what to do, doesn't work
12:25:50 <xarick> it suggested void SetShipDepotDestinations(std::vector<TileIndex> &&dest_tiles)
12:26:23 <peter1138> Hmm, why are my content-download files marked executable...
12:28:10 <_jgr_> xarick: That is a reasonable suggestion (it's what I said above), but if you don't understand what it means or why it suggested that you should probably just leave this alone for that time being
13:48:43 <peter1138> Why do you need to move it?
13:51:20 <xarick> at this point, dest_tiles already has the list of tiles in it.
13:52:31 <xarick> it's telling me my std::move is doing a copy because of const
13:52:46 <peter1138> Yeah that makes sense.
13:56:57 <peter1138> So if you want Tpf to contain a reference to dest_tiles, that needs to be set in the constructor of Tpf as a reference can't be changed later.
13:57:15 <peter1138> If you want Tpf to contain a copy, then it's simple enough.
13:58:17 <peter1138> If dest_tiles is a temporary before the FindNearestDepot() call, and doesn't need to be maintained, then you can remove const and use std::move.
14:00:33 <peter1138> If dest_tiles needs to be persisted between calls, or SetShipDepotDestinations() is optional, then using a const pointer instead of a reference is the way to go.
15:29:21 <Rubidium> _glx_: have you tried your suggestion for #12104? For me that fails to compile due a strgen fatal error about a duplicate index 0
15:30:19 <_glx_> I assumed it was possible (seems logical), but I didn't actually tested
15:31:56 <Rubidium> it indeed seems logical, which is why I knew it fails as I tried the exact same proposal yesterday
15:32:21 <_glx_> oh indeed I see how it can not be possible, because the type checks
15:33:11 <_glx_> {NUM} and {HEX} are different types and FormatString will show "(invalide parameter)" for the second use
15:34:58 <_glx_> I should know better as I was in this area recently 🙂
15:42:45 *** Wormnest has joined #openttd
15:58:10 <xarick> `static inline std::vector<TileIndex> &m_destTiles = *(new std::vector<TileIndex>);`
15:58:33 <xarick> it's in the CYapfDestinationTileWaterT constructor
15:59:00 <peter1138> Why is it static inline?
15:59:29 <xarick> performance? speed? i guess, not really sure
15:59:39 <LordAro> flail at keyboard until it works
16:01:53 <xarick> I needed a reference in the constructor?
16:03:17 <LordAro> you need to be able to answer, "what is each part of that line doing, and why is it there?"
16:03:58 <LordAro> that's: "static", "inline", "std::vector<TileIndex>", "&", "m_destTiles" (ok, this one's obvious), "=", "*", "new"
16:04:12 <LordAro> i believe at least 5 of them should not be there
16:07:56 <xarick> static for speed, inline because it doesn't let it be only static, & is reference, = *new because it doesn't let me have &m_destTiles;
16:19:51 *** HerzogDeXtEr has joined #openttd
16:20:26 <xarick> alright, I'm removing the static inline thing and the reference
16:20:41 <xarick> std::vector<TileIndex> m_destTiles; is the simplest form
16:24:32 <_glx_> I think you are abording the problem you intend to fix from the wrong side
16:25:22 <kuhnovic> static inline would imply that you only allocate the vector once + the amount of times the internal array has to resize. Without it you have to do these allocations every time you run the PF. And allocations are expensive.
16:28:30 <peter1138> That would assume you knew why you'd done it 😉
16:29:08 <_glx_> instead of trying to support multiple destination, I'm quite sure it would be simpler to reverse PF and use already existing multiple origin support
16:29:48 <xarick> difficult because I would not know the ship trackdir at the destination
16:32:01 <xarick> the trackdirs would then be in opposite directions too... hmm
16:36:13 <_jgr_> Given that your vector outlives the PF object, you could just make it a std::span instead
16:36:58 <_jgr_> You wouldn't need any fancy syntax to do that
16:40:57 <kuhnovic> TallTylerviaGitHub: Yup, haven't had the time look at it yet. Might take some time, the wife is sick 😉
17:05:01 <andythenorth> related-unrelated, would the river creation work better if we pathfound *from* a coast tile
17:05:12 <andythenorth> rather than **to** a coast tile
17:05:28 <andythenorth> (because we get sinkhole rivers currently)
17:16:20 <talltyler> andythenorth: Sinkholes are still coast tiles, though
17:16:39 <talltyler> Unless you mean pathfinding from a map edge
17:16:51 <talltyler> Also, rivers can end in lakes made of river tiles
17:37:19 <xarick> `m_destTiles = std::span(dest_tiles);`, is that it? sounds too good to be true
17:37:49 <xarick> and the constructor is `std::span<TileIndex> m_destTiles;`
17:38:23 <xarick> dest_tiles is still a `std::vector<TileIndex>`, did I do this right?
17:47:11 <andythenorth> talltyler: sinkholes 🙂
17:47:17 <andythenorth> they're not really lakes 🙂
17:48:00 <andythenorth> I don't know what my rational objection to them is BTW
17:49:45 <talltyler> Oh that’s what you dislike
17:50:01 <talltyler> Those are explicitly allowed in the code, it’s not a pathfinding direction issue
17:50:31 <andythenorth> well it was added by Rubi for rivers that couldn't reach a coast 🙂
17:50:35 <andythenorth> historical reasons
17:50:50 <talltyler> What bother me are the wide river systems that end in small sea-level holes
17:51:02 <andythenorth> on the plus side, that lake doesn't need FlatDocks
17:52:21 <_zephyris> The real fix is rivers integrated in terrain gen...
17:52:38 <andythenorth> I did draw a set of corner tiles once, but then I rage quite, and I deleted the repo
17:52:42 <andythenorth> bad andythenorth
17:56:37 <peter1138> Damn, £40 for a set of replacement batteries :S
18:26:56 <talltyler> Resolved, not won’tfix, I think 🙂
18:28:20 <truebrain> Pretty sure you are not going to fix it
18:28:35 <truebrain> But also: nobody cares; now you are just generating spam 😛
18:28:38 <talltyler> It doesn’t need fixing, it’s working as intended 🙂
18:28:47 <talltyler> I have nothing to say, so I might as well spam 😛
18:28:49 <truebrain> So you won't fix it!
18:29:08 <truebrain> So my state was more correct!
18:29:21 <talltyler> Yes honey, you win 😄
18:29:38 <truebrain> Yet you don't fix it 😢
18:29:58 <truebrain> Still absolutely no clue why github has these two states
18:30:14 <truebrain> Nowhere they do anything with it
18:30:38 <truebrain> Maybe some mind trick?
18:34:18 <peter1138> Hmm, when is the eints commit again? ;p
18:49:41 *** Wormnest has quit IRC (Ping timeout: 480 seconds)
18:52:08 <frosch123> eints already sent a furious email :p
18:53:17 <truebrain> Closed as won't fix or resolved?
18:55:07 <_glx_> Maybe eints could retry
18:55:30 <frosch123> or nightly could be built at 4am utc 🙂
18:55:41 <truebrain> _glx_: It does, tomorrow!
18:56:01 <peter1138> Oh did I mess it up?
18:56:04 <frosch123> we have no asian contributors, so 2tt goes to bed, it should be safe
19:28:20 *** Wormnest has joined #openttd
19:30:37 <frosch123> i am sure i messed up some time zone translation 🙂
19:32:59 <truebrain> `between 8 AM CEST (= 6 UTC) and 10 PM CST (= 4 UTC).` that is by far the weirdest shit I have read in a while 😄
19:33:08 <truebrain> well, I have some people blocked, so that might explain that statement
19:33:20 <truebrain> between CEST and CST .. sjees 😛
19:33:29 <truebrain> someone had too much fun 🙂
19:33:42 <peter1138> A nightly build at 5am is a bit weird 😉
19:35:17 <frosch123> 5am is as night as it gets
19:35:42 <frosch123> and yes, CST is way too close to CET
19:36:31 <wensimehrp> What does transfer credits even mean
19:40:23 <truebrain> talltyler: that is the wrong approval!
19:42:41 <talltyler> Yes, my check mark is grey! (which is fine, I’m not likely to touch workflows 🙂 )
19:43:00 <frosch123> nice, this is almost scientific. someone makes up a theory, someone else confirms it with measured data
19:43:14 <truebrain> you were not completely correct, but within margins, so what-ever
19:43:41 <talltyler> If you want to move it earlier, I promise not to merge things late at night 🙂
19:44:01 <truebrain> it is night for someone, so it is still a nightly no matter what the time is 😛
19:44:01 <frosch123> kids should not play in school
19:44:15 <talltyler> I don’t usually work on OpenTTD in the evenings anyway, my brain is too fried to write good code
19:44:32 <truebrain> I too know that issue .. doesn't mean I am not trying 😛
19:50:12 <truebrain> the lovely thing about frosch123 's commit, it doesn't matter when it is merged; there still will be only 1 nightly on a given date 🙂 Moving the date later in the day is more of a problem 😛
19:51:39 <frosch123> well, we can do that only so often :p
19:52:04 <frosch123> do you want 14 PRs which each move it by 1h?
19:52:19 <rutoks> talltyler: Late at night for whom?
19:52:20 <frosch123> also, i would not dare to touch the cursed hours 2am to 3am
19:58:48 <xarick> do i pass spans as references to functions?
20:02:17 <kuhnovic> A span is a lightweight wrapper, it can be passed by value
20:04:07 <xarick> it's gonna be fast now! I hope
20:08:49 <frosch123> is a static vector a std::array, or something else?
20:11:20 <xarick> not a static vector, should it be?
20:11:38 <LordAro> we've been through this
20:12:00 <LordAro> frosch123: we haven't been asking too many probing questions about what xarick is up to
20:14:38 <frosch123> oh, i am good in ignoring things. the "forum" at work has no unsubscribe feature
20:14:51 <frosch123> once you participate in a subject, you are all-in forever
20:16:57 <frosch123> today someone asked about the latest us-gov announcement to discourage usage of c and c++, to which i early replied with a cppnow talk about the subject. but that did not stop 50+ people argueing over c++/java/rust/cobol/fortran, and how they think they are good enough to handle memory
20:17:59 <frosch123> that's the danger of replying early in a thread, you never know whether it will derail
20:20:09 <_glx_> ha yes a constructive topic
20:27:16 <andythenorth> just throw in a python whitespace argument and retreat
20:27:18 <andythenorth> then turn off email
20:29:11 <frosch123> ah crap, yes there was also a python/java discussion today
20:29:26 <frosch123> someone linked some python library doing computations on the gpu
20:29:45 <frosch123> and people discussed how python can be so fast, and why they do not use java
20:29:52 <frosch123> as if the gpu would run either
20:30:55 <frosch123> but i did not participate, so i only saw it once, got no notifications, and did not have to restock popcorn
20:31:41 <truebrain> please ,no Python/Java talk tonight .. I have that enough at work 😛
20:32:29 <andythenorth> is it still a live debate? 😛
20:32:35 <frosch123> i assumed you were in the rust party
20:32:53 <andythenorth> my world is somewhat moving into 'but which commodity vendor can we buy this from'?
20:33:25 <andythenorth> not convinced that arguing whitespace or not is where it's at in 2024
20:33:33 <truebrain> in a professional job you always have to adjust to the majority; pushing a language nobody writes means you are always the person that needs to fix shit 😄
20:34:04 <frosch123> ah yes, i have a coworker who never learned that lesson
20:36:21 <frosch123> person A: i want to do X. person B: i can do that quickly with Y. person A: fine, you can maintain your solution. person B is busy doing unplanned shit
20:36:59 <frosch123> oh wait, wasn't michi warned the other day for using that word?
20:37:07 <andythenorth> generally, I try to avoid us writing code
20:37:20 <andythenorth> it tends to need maintenance
21:15:30 <kuhnovic> Is it too late to get #12219 into the upcoming release? Not trying to nag, just curious 🙂
21:16:04 <peter1138> I think so, bug fixes only.
21:17:13 <kuhnovic> Fair enough, it's kind of a feature, albeit a tiny one
21:22:36 <xarick> too bad they only last 1 year
21:25:17 <truebrain> kuhnovic: we learnt the hard way the effects of a "tiny" fix just before release 😄 😄
21:25:53 <truebrain> also, changes that impact languages are always a bit annoying. During backporting, they are not copied (as the scripts can't know whether the language changed due to a master change, or a backported change)
21:25:57 <truebrain> in this case not really relevant
21:26:03 <truebrain> but just to complete the picture for you 🙂
21:28:26 *** blathijs has quit IRC (Ping timeout: 480 seconds)
21:28:37 <xarick> how long would recessions last with the 2TallTyler days lasting longer?
21:30:39 <peter1138> Hmm, is there anything to nicely (briefly) cast an array (or vector/span) from one type to another...
21:32:25 <xarick> I used span and vector, check it out
21:37:30 <peter1138> I think this counts as type-punning and is technically forbidden.
21:40:51 *** nielsm has quit IRC (Ping timeout: 480 seconds)
21:44:19 <xarick> was it something I did?
21:46:16 <kuhnovic> I think he's referring to his array to vector / span shenanigans
21:49:06 <xarick> now I'm gonna do what glx recommends
21:49:32 <xarick> just not sure what kind of trouble I'm getting into
21:49:51 <peter1138> Yeah, I have a std::vector<byte> which I need to treat as `int16_t`s (half the number of them...)
21:51:18 <_jgr_> reinterpret_cast is there when you need it 😛
21:56:02 <peter1138> There is that, but it all starts to look like very C code (except with `reinterpret_cast<type *>` instead of `(type *)`)
22:01:32 <xarick> _glx_: , how do I add multiple origins?
22:01:44 <xarick> the code is not prepared!
22:04:24 *** Alkel_U3 has quit IRC (Quit: maintenance)
22:06:47 <kuhnovic> Then prepare it yourself 🙂 yapf_regions ship does it btw
22:07:47 <xarick> I wonder how am I supposedly returning a path
22:08:12 <xarick> when all trackdirs are in reverse
22:08:46 <xarick> "hey ship", walk backwards!
22:09:06 *** keikoz has quit IRC (Ping timeout: 480 seconds)
22:09:51 <xarick> got a feeling it's going to take a lot to make it work
22:18:32 <michi_cc> peter1138: Cast to uint16_t is of course VERBOTEN (at least if you apply strict aliasing rules). The reverse if the byte is actually `std::byte` would be allowed.
22:20:11 <peter1138> file->ReadWord() everywhere?
22:20:33 <michi_cc> No idea if any compiler out there actually cares about that strict aliasing 🙂
22:20:35 <peter1138> I reckon this is fine 😉
22:22:10 <peter1138> Read an array of bytes from file into memory. Treat as words instead of bytes.
22:23:19 <kuhnovic> xarick: trackdir = ReverseTrackdir(trackdir) ?
22:30:39 <Eddi|zuHause> how much breaks if it's an odd number of bytes?
22:34:25 <peter1138> Given there's an assert to check for that (although size_bytes() would be better then size())
22:36:34 <orudge> or, hm, what's the process for deploying the site these days?
22:40:04 <_glx_> orudge: it auto deploys on merge
22:41:43 <orudge> _glx_: Ah right. So if somebody is happy to approve it, I can merge it just after midnight
22:42:16 *** Wolf01 has quit IRC (Quit: Once again the world is quick to bury me.)
22:49:47 <truebrain> It has to be the 6th in UTC before it gets published
22:50:06 <truebrain> Just so you are not surprised if you merge earlier it not showing up 🙂
22:50:43 <orudge> Do you publish the Steam article manually?
22:53:07 <truebrain> Lot of clicking ......
22:53:19 <truebrain> And easy to miss a click or two 😦
22:54:29 <truebrain> Cloning an existing blog makes things easier. Just not to forget to replace the image on the second tab. Doesn't show up in preview, but when wrong, is shown to all users 😛
22:55:38 <orudge> If you can approve the review on the PR, I will merge it after midnight, though if you don't mind I would probably prefer to leave Steam to you :D
22:56:01 <truebrain> Haha; I will do Steam tomorrow early, that is okay 🙂
22:56:11 <truebrain> Sadly on mobile and not logged in, so cant approve
23:02:40 <_glx_> approved after midnight for me 😉
23:03:44 *** HerzogDeXtEr has quit IRC (Read error: Connection reset by peer)
23:19:39 <xarick> it is done! can't make it faster via feeding multiple depots as destinations, but ...
23:21:00 <xarick> probably not worthy of a PR, as my other method is still faster
23:22:24 <xarick> The other method doesn't know where the depot is, it does a Disjktra search or wtv until it finds a depot.
23:23:04 <xarick> This method becomes more expensive as more depots are in a company
23:23:34 <xarick> this savegame example has about ~500 ship depots per company
23:23:42 <xarick> so it's really an extreme case
23:25:14 <xarick> I should test a real game savegame, not these extreme cases :/
23:33:49 *** Alkel_U3 has joined #openttd
continue to next day ⏵
