Times are UTC Toggle Colours
00:09:51 *** Aurelia_ has left #openttd 00:24:01 *** andythenorth has quit IRC 01:30:32 *** WormnestAndroid has quit IRC 01:30:33 *** WormnestAndroid has joined #openttd 01:38:13 *** Compu has joined #openttd 01:39:46 *** Compu has quit IRC 02:03:11 *** Tirili has joined #openttd 02:19:46 *** Tirili has quit IRC 02:52:09 *** Wormnest has quit IRC 03:09:18 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #15344: Codechange: Make CMD_ERROR constexpr to avoid many copies in binary https://github.com/OpenTTD/OpenTTD/pull/15344 03:09:21 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #15345: Codefix: Fix duplicate copies of industry tables https://github.com/OpenTTD/OpenTTD/pull/15345 03:27:38 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #15344: Codechange: Make CMD_ERROR constexpr to avoid many copies in binary https://github.com/OpenTTD/OpenTTD/pull/15344#issuecomment-3976241824 03:41:26 *** WormnestAndroid has quit IRC 03:41:53 *** WormnestAndroid has joined #openttd 03:54:58 *** Flygon has joined #openttd 03:56:26 *** Tirili has joined #openttd 04:07:30 *** Zathras_11 has joined #openttd 04:07:58 *** Zathras_1 has joined #openttd 04:10:51 *** Zathras_7 has quit IRC 04:11:16 *** Zathras_4 has quit IRC 04:51:29 <DorpsGek> [OpenTTD/OpenTTD] eints-sync[bot] pushed 1 commits to master https://github.com/OpenTTD/OpenTTD/commit/e5c9025ad5bb4f3f576b418f490afe5757ef2857 04:51:30 <DorpsGek> - Update: Translations from eints (by translators) 06:09:49 *** wallabra2 has quit IRC 06:16:49 *** wallabra has joined #openttd 06:46:07 *** keikoz1 has quit IRC 06:47:44 *** keikoz has joined #openttd 07:09:14 *** andythenorth has joined #openttd 08:01:38 *** SigHunter_ has quit IRC 08:03:47 *** SigHunter has joined #openttd 08:31:38 *** Zathras_1 has quit IRC 08:32:10 *** Zathras_11 has quit IRC 08:36:33 *** Zathras_7 has joined #openttd 08:40:10 <DorpsGek> [OpenTTD/OpenTTD] Rito13 updated pull request #14637: Feature: [Script] Allow GS to implement custom engine preview behavior. https://github.com/OpenTTD/OpenTTD/pull/14637 08:47:41 <DorpsGek> [OpenTTD/OpenTTD] slashdevslashurandom opened issue #15346: [Bug]: Incorrect tooltips in link graph https://github.com/OpenTTD/OpenTTD/issues/15346 09:22:57 *** Flygon has quit IRC 09:25:58 *** Wolf01 has joined #openttd 09:37:43 <xarick> hi 09:44:18 <andythenorth> moin 09:44:32 <andythenorth> Horse is so slow to compile 09:49:22 <andythenorth> https://usercontent.irccloud-cdn.com/file/Kx79jRaC/image.png 09:49:29 <andythenorth> 4229 is more than 3919 eh 09:49:53 <andythenorth> 7% faster 09:50:12 <andythenorth> would save 1.5s maybe 09:53:16 <xarick> is the compiler multithreaded? 09:53:38 <xarick> ~100% cpu usage during compiling? 09:54:15 <rito12_51026> xarick: For cpp should be 09:54:31 <xarick> no, for horse, i guess generating newgrf? 09:56:19 <andythenorth> nmlc is single-threaded 09:56:34 <andythenorth> the Horse compile uses more than nmlc and is multi-threaded 09:57:19 <rito12_51026> How python is not multithreaded, is it? 09:57:44 <goddess_ishtar> you have to use async and await iirc 09:58:14 <goddess_ishtar> probably someone decided it wasn't worth the hassle 09:58:20 <andythenorth> python is not multi-threaded but has libs for threads or pools 09:58:28 <andythenorth> the overhead is relatively high 10:02:26 <andythenorth> as a rough guide, spawning a thread pool to save 1 or 2 seconds doesn't pay off 10:02:39 <andythenorth> this is obvs highly dependent on compute environment 10:02:53 <andythenorth> but a thread pool to save 10s is usually a good investment 10:16:45 <LordAro> goddess_ishtar: async/await didn't exist when it was written ;) 10:17:02 <LordAro> (not that those are the only ways of doing concurrency in python) 10:17:41 <LordAro> (python can do concurrency, not parallelism) 10:17:48 <goddess_ishtar> I don't really deal with it often, so my memory is foggy 10:18:59 <rito12_51026> ah The multiprocessing module, would it be a lot work to use that in nmlc? 10:20:49 <LordAro> probably 10:21:12 <LordAro> retrofitting multithreading is not historically an easy thing to do 10:21:15 <andythenorth> it would be very hard IMHO 10:21:37 <andythenorth> the AST would be unwieldy to share between pool workers 10:21:51 <LordAro> and the amount that andy complains about it, someone would've tried ;) 10:21:57 <andythenorth> the parse step could probably be async, on a sort of map-reduce basis 10:22:09 <andythenorth> but it might lose in overhead what it gains in parse speed 10:22:20 <LordAro> but yes, fundamentally most jobs do not lend themselves to to multithreading 10:22:45 <andythenorth> being able to shard grfs, but package them together would be the Horse solution :P 10:23:05 <LordAro> running many nmlc i s much easier 10:23:07 <andythenorth> or partial compiles of nml, similar to how a C++ compiler works 10:23:58 <goddess_ishtar> yeah algorithms why weren't written with multithreading in mind tend to be difficult to modify to add it later 10:25:14 <andythenorth> it's just compiler basics no? 10:25:26 <andythenorth> nmlc expects to parse a single input file, to a single AST 10:26:36 <andythenorth> it's not the writing grf part that is slow 10:27:04 <andythenorth> nmlc outputs 70MB of compiled Horse in 1 or 2 seconds 10:27:13 <rito12_51026> Does grf-py use multiprocessing? 10:27:25 <andythenorth> grf-py is a different approach 10:27:37 <andythenorth> because it's got no need to parse a clunky pseudo-code text format 10:27:57 <rito12_51026> true 10:28:16 <andythenorth> the AST, I'm guessing, is just the python structure 10:28:48 <andythenorth> so two specific proprietary steps are folded into one "it's just declared as a python object tree" step 10:29:05 <rito12_51026> We could use IronPython or something 10:29:37 <goddess_ishtar> transpile-to-nml is messy as hell but at least it's less labour-intensive to implement 10:30:49 <andythenorth> pypy3 significantly improves nmlc performance against python 3.13 10:38:04 <rito12_51026> IronPython uses JIT as like the pypy, but does not have GIL, that would help if nmlc uses concurrency 10:51:25 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1477256873391554764/image.png?ex=69a41a2c&is=69a2c8ac&hm=4f84f63e02db67405fc3e747443252f8e4b5df4ee9f7a2b5622935973d6320f0& 10:51:25 <xarick> FindSafeTile mismatch problem points towards this track/signal configuration 10:53:49 <xarick> btw, the yapf dump file writter keeps overwritting previous results with new ones 10:54:10 <xarick> couldn't this log all occurrences instead of refreshing it to the latest that occurred? 10:55:17 <andythenorth> The solution to slow nmlc is sometimes ‘make a smaller grf’ 10:56:10 <andythenorth> I believe that parse and processing time increases non-linearly with number of items, particularly allocating varact2 ids 10:56:22 <andythenorth> I don’t have any charts though 10:57:48 <andythenorth> Removing a few thousand vehicles from Horse was the best recent improvement to compile time 10:58:59 <xarick> Summon kuhnovic 11:00:40 *** kuhnovic has joined #openttd 11:00:40 <kuhnovic> I don't have time to look into this atm, sorry 11:01:03 <kuhnovic> Or figure out if it's a real issue or a Xarick-problem 11:01:34 <andythenorth> Maybe Horse should be split up? 11:03:05 <xarick> thx for passing by 11:05:16 <andythenorth> Horse 1860-1950 11:05:39 <andythenorth> Horse 1950-2020 11:05:41 <andythenorth> ?? 11:06:55 <rito12_51026> dunno, that will piss of some people, but the save games that only need 1950-2020 would load faster 11:08:55 <andythenorth> Compiles faster though 11:09:15 <reldred> future horse future horse future horse 11:09:30 <reldred> i wont stop believing s/believing/dreaming/ 11:10:17 <reldred> my fingers are covered in superglue residue again 11:10:54 <reldred> also kde's default pdf viewer has no business being this good 11:11:39 <andythenorth> hopefully M5 macbook pro next week, maybe fasteeer Horse with that 11:11:45 <reldred> ooooh 11:11:46 <reldred> shiny 11:12:06 <andythenorth> Unannounced as yet 11:12:10 <andythenorth> Runoured 11:12:20 <reldred> i would like a nice shiny black macbook but, i wouldn't really have any actual use for it 11:12:28 <reldred> it wouldn't replace my desktop, 11:12:42 <reldred> and it's too big and bulky to carry when i already have a work laptop 11:18:36 <andythenorth> Just it to compile Horse 11:22:11 <andythenorth> * use it 11:49:34 <ahyangyi> Horse pre-1830 11:49:37 <ahyangyi> non-iron Horse 12:04:05 <rito12_51026> Yep, pypy runs 2 times faster than python and IronPython does not run at all 12:07:35 <ahyangyi> IronPython 12:07:49 <ahyangyi> Isn't its newest version 3.4 beta or something 12:08:17 <ahyangyi> I doubt there are many python libraries left that can run with Python 3.4- 12:11:05 <rito12_51026> The main problem is that it only supports pure python libraries and pillow is written in c 12:27:01 <ahyangyi> I see 12:57:45 <DorpsGek> [OpenTTD/OpenTTD] JGRennison updated pull request #15345: Codefix: Fix duplicate copies of industry tables https://github.com/OpenTTD/OpenTTD/pull/15345 13:12:29 <DorpsGek> [OpenTTD/OpenTTD] JGRennison closed pull request #15344: Codechange: Make CMD_ERROR constexpr to avoid many copies in binary https://github.com/OpenTTD/OpenTTD/pull/15344 13:12:32 <DorpsGek> [OpenTTD/OpenTTD] JGRennison commented on pull request #15344: Codechange: Make CMD_ERROR constexpr to avoid many copies in binary https://github.com/OpenTTD/OpenTTD/pull/15344#issuecomment-3977150312 13:21:50 <andythenorth> it's parsing that's achingly slow in nmlc https://usercontent.irccloud-cdn.com/file/cWlJ8hQO/image.png 13:21:51 <andythenorth> I've never read the parse :P 13:23:09 <andythenorth> I don't really know how to instrument, but instrumenting parser.py and charting the result might be interesting 13:23:27 <andythenorth> https://github.com/OpenTTD/nml/blob/master/nml/parser.py 13:23:49 <andythenorth> possibly it's never going to be fast in python, and would be better as a C++ lib or rust or something 13:24:29 <andythenorth> but there's a chance we could find it's just doing something needlessly slow with string splits or something 13:25:28 <ahyangyi> Hmm 13:29:27 <xarick> could someone decipher <https://github.com/OpenTTD/OpenTTD/blob/master/src/pathfinder/yapf/yapf_rail.cpp#L335-L380> 13:29:27 <xarick> I question why in one of the results it tries to reserve path and in the other it does not. The bool argument isn't even about cache... 13:32:19 <ahyangyi> Because if you reserve path and find path again you are going to find a different one? 13:32:55 <ahyangyi> So you have to not reserve path when calculating the first path 13:33:15 <ahyangyi> TBH I don't have any context though, just reading the code loudly 13:33:39 <xarick> I see the problem is about here 13:34:14 <xarick> result1, which runs through TryReservePath 13:34:23 <xarick> returns a false 13:34:36 <xarick> result2 doesn't even bother and just returns true no matter 13:35:03 <ahyangyi> (I do find it weird that `result2` comes from `pf1` and `result1` comes from `pf2` though ... ) 13:35:43 <xarick> the results can't be compared if result1 returns false imo 13:36:24 <ahyangyi> Hmm 13:36:41 <ahyangyi> Seems you want a "try to reserve path but don't actually do that" flag or something 13:36:48 <ahyangyi> for that comparison to work? 13:38:31 <xarick> the dump matches in this case 13:38:44 <xarick> exact segments, exact path, trackdirs, etc... 13:38:51 <xarick> it's the TryReservePath that differs 13:39:31 <xarick> or rather, one runs the TryReservePath which fails and the other accepts true due to "dont_reserve" 13:40:22 <xarick> must think of a solution 13:49:24 <_glx_> I think it's fine, might be some corner case where there's actually no reservable path 13:50:31 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1477301948431728853/image.png?ex=69a44427&is=69a2f2a7&hm=0e8db3d2e2993ef8f4e2891cc1e4bd32b4203c744286f6cc8820e700b61fa3ab& 13:50:40 <xarick> green is the path found 13:50:46 <xarick> red is the tryresevepath 13:50:54 <xarick> fails when walking the path 13:51:17 <xarick> green also points to a tile which can be reserved, the target is not reserved 13:52:02 <xarick> in both cases, the path is the same 13:53:51 <xarick> the train at the top is actually lost, it wants to go to a station that is north of it, but he's currently heading south 13:57:01 <xarick> 2427 hits of FindSafeTile mismatch on that replay 13:57:10 <xarick> i only investigated the first 13:57:23 <xarick> is it safe to assume the others would be the same? 13:57:34 <xarick> or similar in nature 13:59:26 <_glx_> Lost train could be the cause yes 14:05:46 *** Wormnest has joined #openttd 14:16:54 *** Zathras_4 has joined #openttd 14:21:00 *** Mr_rough_ has joined #openttd 14:22:50 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1477310081237516348/message.txt?ex=69a44bba&is=69a2fa3a&hm=fe1e42b860b0e1d73e3965d5c191b0a40d36765c670f0372bc1de08b8ddc2db9& 14:22:50 <xarick> heh... 14:32:12 <xarick> https://cdn.discordapp.com/attachments/1008473233844097104/1477312436766773299/image.png?ex=69a44dec&is=69a2fc6c&hm=7b847febf51e3ae4916392c20c7c18762581d4be707956f9404664f4c58ce429& 14:32:12 <xarick> yeah, it seems it always involve trains going into the wrong tracks 14:32:48 <xarick> trains want to go to the station at the top, but they're in the south path 14:35:16 <xarick> oh, waypoint at the top 14:51:45 <xarick> without all the duplicates, it's just these: <https://gist.github.com/SamuXarick/2fa0698a01589960d084b7ca23361a8a> 14:58:22 *** Zathras_4 has quit IRC 15:10:16 <DorpsGek> [OpenTTD/OpenTTD] JGRennison opened pull request #15347: Codefix: Double-counting of object types when loading pre-147 savegames https://github.com/OpenTTD/OpenTTD/pull/15347 15:12:56 <DorpsGek> [OpenTTD/OpenTTD] Rito13 updated pull request #14798: Feature: Hidden and favourite rail/road/tram types. https://github.com/OpenTTD/OpenTTD/pull/14798 15:25:08 *** Flygon has joined #openttd 15:39:59 <DorpsGek> [OpenTTD/OpenTTD] glx22 approved pull request #15347: Codefix: Double-counting of object types when loading pre-147 savegames https://github.com/OpenTTD/OpenTTD/pull/15347#pullrequestreview-3870527808 16:02:29 <rito12_51026> Why trams are not accessible when the toolbar is splitted? 16:04:45 <_glx_> my guess is the toolbar splitting was forgotten 16:06:07 <rito12_51026> could it be removed? 16:07:51 <xarick> deleting code fixes the issue, I love it 16:08:08 <xarick> oh, no, i got a crash, didn't fix it 16:11:31 <xarick> actually, i caused a desync 16:12:41 <_glx_> indeed the button was added in <https://github.com/OpenTTD/OpenTTD/commit/c02ef3e4564b7b54d49f0827d2d7625cbc38f335#diff-7209f122341722118b8e0247ac6923a36d0f8cdde9ff7a696688b140a6012dd7> but only for "all" toolbar 16:12:44 <xarick> the path can't be reserved twice? 16:12:59 <_glx_> of course it can't 16:13:11 <_glx_> why would you reserve a path twice ? 16:13:28 <xarick> one testing for cache, the other testing without cache 16:19:51 <rito12_51026> There are also 3 more buttons that are hidden in splited toolbar. The two for GS (storybook and goal) and also the company league menu whose content is moved to graph menu 16:20:57 <_glx_> there are many layouts <https://github.com/OpenTTD/OpenTTD/blob/master/src/toolbar_gui.cpp#L1513-L1771> 16:21:27 <_glx_> depending on numbers of buttons per row 16:23:26 <rito12_51026> The league is only in all and the GS ones in 20 too but when window gets smaller they are gone 16:24:01 <_jgr_> I didn't even know this feature existed, do people actually play with windows narrow enough that the toolbar doesn't fit?