Log for #openttd on 24th November 2019:
Times are UTC Toggle Colours
00:10:06  *** Wolf01 has quit IRC
00:11:54  *** supermop_work_ has quit IRC
00:12:27  *** supermop_work_ has joined #openttd
00:42:41  *** supermop_work_ has quit IRC
00:44:27  *** supermop_work_ has joined #openttd
00:54:22  *** Smedles has quit IRC
00:54:37  *** Smedles has joined #openttd
01:00:38  *** HerzogDeXtEr has quit IRC
01:14:41  *** supermop_work_ has quit IRC
01:16:28  *** supermop_work_ has joined #openttd
01:45:14  *** Wormnest has quit IRC
01:48:12  *** supermop_work_ has quit IRC
01:50:28  *** supermop_work_ has joined #openttd
02:20:43  *** supermop_work_ has quit IRC
02:21:47  *** supermop_work_ has joined #openttd
02:33:09  *** Wormnest has joined #openttd
02:39:39  *** Wormnest_ has joined #openttd
02:44:29  *** Wormnest has quit IRC
02:52:03  *** supermop_work_ has quit IRC
02:52:29  *** supermop_work_ has joined #openttd
03:22:44  *** supermop_work_ has quit IRC
03:24:31  *** supermop_work_ has joined #openttd
03:28:41  *** D-HUND has joined #openttd
03:32:07  *** debdog has quit IRC
03:32:09  *** Wormnest_ has quit IRC
03:41:11  *** tokai has joined #openttd
03:41:11  *** ChanServ sets mode: +v tokai
03:48:04  *** tokai|noir has quit IRC
03:49:02  *** snail_UES_ is now known as Guest8634
03:49:02  *** snail_UES_ has joined #openttd
03:54:44  *** supermop_work_ has quit IRC
03:54:55  *** glx has quit IRC
03:56:30  *** supermop_work_ has joined #openttd
04:09:04  *** nielsm has quit IRC
04:26:45  *** supermop_work_ has quit IRC
04:28:25  *** supermop_work_ has joined #openttd
04:39:06  *** daspork has quit IRC
04:39:50  *** daspork has joined #openttd
04:43:57  <Eddi|zuHause> oh, you can order transport fever 2 now (for -25% if you own the previous game)
04:45:19  *** Wormnest_ has joined #openttd
04:58:40  *** supermop_work_ has quit IRC
05:00:33  *** supermop_work_ has joined #openttd
05:30:46  *** supermop_work_ has quit IRC
05:31:52  *** supermop_work_ has joined #openttd
05:47:10  *** daspork has quit IRC
05:47:27  *** daspork has joined #openttd
06:02:07  *** supermop_work_ has quit IRC
06:02:53  *** supermop_work_ has joined #openttd
06:32:03  *** m1cr0man has quit IRC
06:33:07  *** supermop_work_ has quit IRC
06:33:54  *** supermop_work_ has joined #openttd
06:34:58  *** snail_UES_ has quit IRC
06:43:43  *** sla_ro|master has joined #openttd
06:45:36  *** FLHerne has quit IRC
06:46:39  *** FLHerne has joined #openttd
06:53:06  *** Eddi|zuHause2 has joined #openttd
06:54:01  *** Eddi|zuHause has quit IRC
06:56:34  *** ZirconiumY has joined #openttd
06:57:54  *** WormnestAndroid has quit IRC
06:58:09  *** Wormnest_ has quit IRC
06:58:56  *** Ammller has joined #openttd
06:59:06  *** nolep[m]1 has joined #openttd
06:59:31  *** Mek_ has joined #openttd
06:59:37  *** Heili has joined #openttd
06:59:43  *** seatsea0419211 has joined #openttd
06:59:50  *** WormnestAndroid has joined #openttd
07:00:29  *** Hobbyboy|BNC has joined #openttd
07:02:09  *** D-HUND has quit IRC
07:02:09  *** peter1138 has quit IRC
07:02:09  *** berndj has quit IRC
07:02:09  *** josef[m]1 has quit IRC
07:02:09  *** Darkvater has quit IRC
07:02:09  *** lpx has quit IRC
07:02:09  *** Hobbyboy has quit IRC
07:02:09  *** joey[m] has quit IRC
07:02:09  *** seatsea041921 has quit IRC
07:02:09  *** Heiki has quit IRC
07:02:09  *** urdh has quit IRC
07:02:09  *** tyteen4a03 has quit IRC
07:02:09  *** goodger has quit IRC
07:02:10  *** Meiki has quit IRC
07:02:10  *** johanna[m] has quit IRC
07:02:10  *** natalie[m] has quit IRC
07:02:10  *** argoneus has quit IRC
07:02:10  *** khavik[m] has quit IRC
07:02:10  *** ZirconiumX has quit IRC
07:02:10  *** Mek has quit IRC
07:02:10  *** patricia[m] has quit IRC
07:02:10  *** backtu[m] has quit IRC
07:02:10  *** avdg has quit IRC
07:02:10  *** ist5shreawf[m] has quit IRC
07:02:10  *** tops[m] has quit IRC
07:02:10  *** dag[m] has quit IRC
07:02:10  *** iarp[m] has quit IRC
07:02:10  *** nolep[m] has quit IRC
07:02:10  *** dude[m] has quit IRC
07:02:10  *** udo[m] has quit IRC
07:02:10  *** glothit7ok[m] has quit IRC
07:02:10  *** buggeas40d[m] has quit IRC
07:02:10  *** yoltid[m] has quit IRC
07:02:10  *** paulus[m] has quit IRC
07:02:10  *** Osai has quit IRC
07:02:10  *** Ammler has quit IRC
07:02:10  *** grossing has quit IRC
07:02:10  *** SpComb has quit IRC
07:02:10  *** XeryusTC has quit IRC
07:02:10  *** guru3 has quit IRC
07:02:10  *** dag[m]1 has joined #openttd
07:02:10  *** Ammller is now known as Ammler
07:02:10  *** Heili is now known as Heiki
07:02:37  *** guru3 has joined #openttd
07:02:56  *** avdg has joined #openttd
07:03:21  *** berndj has joined #openttd
07:03:26  *** Osai has joined #openttd
07:03:26  *** XeryusTC has joined #openttd
07:03:45  *** tyteen4a03 has joined #openttd
07:04:08  *** supermop_work_ has quit IRC
07:04:38  *** debdog has joined #openttd
07:05:03  *** peter1138 has joined #openttd
07:05:03  *** ChanServ sets mode: +o peter1138
07:05:06  *** grossing has joined #openttd
07:05:12  *** SpComb has joined #openttd
07:05:14  *** urdh has joined #openttd
07:05:44  *** Darkvater has joined #openttd
07:05:44  *** ChanServ sets mode: +o Darkvater
07:05:53  *** supermop_work_ has joined #openttd
07:13:01  *** joey[m] has joined #openttd
07:16:24  *** argoneus has joined #openttd
07:25:51  *** patricia[m] has joined #openttd
07:30:56  *** yoltid[m] has joined #openttd
07:32:26  *** iarp[m] has joined #openttd
07:35:10  *** andythenorth has joined #openttd
07:36:08  *** supermop_work_ has quit IRC
07:37:01  <andythenorth> o/
07:37:54  *** supermop_work_ has joined #openttd
07:37:55  *** johanna[m] has joined #openttd
07:38:13  <andythenorth> azure doesn't complete for nml? o_O
07:39:36  <DorpsGek_III> [OpenTTD/nml] andythenorth commented on pull request #59: Simplify pillow imports and version detection
07:46:37  <LordAro> interesting
07:46:49  <LordAro> needs glx to look into
07:47:07  <LordAro> (also, nml uses GH actions, not azure)
07:47:22  <LordAro> (though they're almost certainly running on the same thing)
07:48:34  <LordAro> it seems like it's just not actually started (yet?)
07:49:10  <LordAro> oh, derp - yeah, this comes from before Actions were added
07:57:20  *** glothit7ok[m] has joined #openttd
08:08:09  *** supermop_work_ has quit IRC
08:08:35  *** supermop_work_ has joined #openttd
08:17:54  *** backtu[m] has joined #openttd
08:27:18  *** Progman has joined #openttd
08:29:19  *** udo[m] has joined #openttd
08:38:48  *** Heiki has quit IRC
08:38:50  *** supermop_work_ has quit IRC
08:38:56  *** Heili has joined #openttd
08:39:15  *** supermop_work_ has joined #openttd
08:39:55  *** Heiki has joined #openttd
09:03:46  *** tops[m] has joined #openttd
09:09:30  *** supermop_work_ has quit IRC
09:09:56  *** supermop_work_ has joined #openttd
09:39:38  *** buggeas40d[m] has joined #openttd
09:40:11  *** supermop_work_ has quit IRC
09:40:36  *** supermop_work_ has joined #openttd
10:10:51  *** supermop_work_ has quit IRC
10:11:58  *** supermop_work_ has joined #openttd
10:40:06  *** khavik[m] has joined #openttd
10:40:53  <andythenorth> 1CC or 2CC for the tech tree?
10:41:04  <andythenorth>
10:41:12  <andythenorth>
10:41:27  <andythenorth> 1CC is much tidier and has the advantage that all trains look the same
10:42:13  *** supermop_work_ has quit IRC
10:42:38  *** supermop_work_ has joined #openttd
11:03:39  *** nielsm has joined #openttd
11:12:53  *** supermop_work_ has quit IRC
11:14:40  *** supermop_work_ has joined #openttd
11:15:31  *** Meiki has joined #openttd
11:31:32  *** Hirundo has quit IRC
11:31:32  *** planetmaker has quit IRC
11:31:32  *** fonsinchen has quit IRC
11:31:32  *** Ammler has quit IRC
11:31:32  *** avdg has quit IRC
11:31:32  *** ^Spike^ has quit IRC
11:31:32  *** Terkhen has quit IRC
11:31:32  *** Hazzard has quit IRC
11:31:32  *** SmatZ has quit IRC
11:31:32  *** Yexo has quit IRC
11:31:32  *** V453000 has quit IRC
11:31:32  *** tneo has quit IRC
11:31:32  *** XeryusTC has quit IRC
11:31:32  *** Osai has quit IRC
11:37:57  *** Samu has joined #openttd
11:44:53  *** supermop_work_ has quit IRC
11:45:30  *** supermop_work_ has joined #openttd
12:15:30  <Eddi|zuHause2> definitely 1cc
12:15:45  *** supermop_work_ has quit IRC
12:16:15  <andythenorth> any rationale?
12:16:31  *** Eddi|zuHause2 is now known as Eddi|zuHause
12:16:39  *** supermop_work_ has joined #openttd
12:33:54  *** planetmaker has joined #openttd
12:33:54  *** ChanServ sets mode: +o planetmaker
12:46:54  *** supermop_work_ has quit IRC
12:47:37  *** supermop_work_ has joined #openttd
13:02:22  *** tneo has joined #openttd
13:17:52  *** supermop_work_ has quit IRC
13:18:41  *** supermop_work_ has joined #openttd
13:26:44  *** Progman has quit IRC
13:42:51  <Eddi|zuHause> rationality died like 3 years ago
13:48:21  *** Hirundo has joined #openttd
13:48:55  *** supermop_work_ has quit IRC
13:49:50  *** supermop_work_ has joined #openttd
13:53:56  <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #60: Avoid duplicating rail/road/tramtype table code
13:53:58  *** Flygon has quit IRC
14:02:57  <DorpsGek_III> [OpenTTD/nml] FLHerne dismissed a review for pull request #60: Avoid duplicating rail/road/tramtype table code
14:02:58  <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code
14:20:05  *** supermop_work_ has quit IRC
14:20:42  *** supermop_work_ has joined #openttd
14:22:10  <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #60: Avoid duplicating rail/road/tramtype table code
14:38:38  <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code
14:39:21  *** glx has joined #openttd
14:39:21  *** ChanServ sets mode: +v glx
14:40:39  <glx> it was not easy to connect today
14:41:15  <glx> had to put the ip manually
14:41:46  <Eddi|zuHause> always have backup DNS servers...
14:41:57  <glx> it's not a DNS issue
14:42:10  <glx> I was always sent on a full server
14:42:30  <glx> so immediate closing of the connection
14:42:39  <FLHerne> At least we're not on SlashNet
14:42:59  <Eddi|zuHause> so malfunctioning load balancer?
14:43:12  <glx> I tried webchat and I was on an orphan server it seems
14:43:44  <FLHerne> (their DNS has been down for a couple of days, so everyone has to connect via IP or alternate domains)
14:43:47  <FLHerne> Hm, that's not good
14:43:49  <Eddi|zuHause> you can set up your client to try different servers directly, instead of the generic one
14:45:26  <glx> I tried that but only via IPv6, should have test IPv4 too
14:47:21  <DorpsGek_III> [OpenTTD/nml] glx22 approved pull request #60: Avoid duplicating rail/road/tramtype table code
14:48:13  <glx> btw FLHerne your other PR will need a rebase too (sorry for that)
14:49:22  <DorpsGek_III> [OpenTTD/nml] FLHerne dismissed a review for pull request #63: Allow PLY to generate parsing/lexing tables.
14:49:22  <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #63: Allow PLY to generate parsing/lexing tables.
14:50:57  *** supermop_work_ has quit IRC
14:52:42  *** supermop_work_ has joined #openttd
14:53:31  <LordAro> we're not concerned about commit messages for NML, are we?
14:53:38  <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #59: Simplify pillow imports and version detection
14:54:01  <glx> there's no commit checker for now
14:54:23  <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #60: Avoid duplicating rail/road/tramtype table code
14:54:32  <LordAro> i added a "Codechange:"
14:56:36  <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #63: Allow PLY to generate parsing/lexing tables.
14:56:49  <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #63: Allow PLY to generate parsing/lexing tables.
14:58:24  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support
14:59:51  <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #35: Fix ottd_display_speed to reflect changes done in OpenTTD
15:00:19  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support
15:00:39  <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #28: Fix: Allow access to towns as parent object
15:01:46  <glx> ah regression testing works very well :)
15:02:26  <glx> looks like failed conflict resolution Eddi|zuHause
15:02:53  <Eddi|zuHause> yeah, i forgot to remove a line
15:04:29  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support
15:04:53  *** WormnestAndroid has quit IRC
15:06:02  <Eddi|zuHause> this giant import line is a bit unwieldy
15:06:45  <glx> and now a missinb file
15:06:50  <glx> *missing
15:07:26  <FLHerne> Eddi|zuHause: It looks as though it was sorted alphabetically, once?
15:07:41  <FLHerne> Probably worth re-establishing that
15:08:02  <Eddi|zuHause> glx: hu, what?
15:08:20  <Eddi|zuHause> FLHerne: that wouldn't solve the conflicty-ness of the line
15:08:24  *** Hazzard has joined #openttd
15:08:39  <glx>
15:08:41  <FLHerne> Add a few linebreaks?
15:08:58  <glx> yeah the line could be split
15:09:34  <FLHerne> You can do `from foo import (aaa, bbb, ccc,  \n ddd, eee)`
15:10:03  <Eddi|zuHause> FLHerne: ideally, each module would be on a separate line
15:10:19  <FLHerne> Why? that would be a lot of lines
15:10:39  <Eddi|zuHause> we're not having a shortage of available lines
15:11:51  <FLHerne> I do wonder if a separate `comment()` thing is right
15:12:28  <FLHerne> How is that semantically different from an actual comment?
15:12:54  <FLHerne> (forgetting the parser implementation for now)
15:13:45  <Eddi|zuHause> FLHerne: the comment will be embedded in the resulting grf
15:13:49  <FLHerne> Well, yes
15:13:59  <Eddi|zuHause> i need that for further post-processing
15:14:04  <Eddi|zuHause> ... which is a major hack
15:14:31  <Eddi|zuHause> glx: i wonder if that file got lost, or never was there in the first place
15:14:46  <glx> missing git add ?
15:15:09  <FLHerne> But if we're putting comments into the grf for readability, then we should just put the actual comments in the grf
15:15:24  <Eddi|zuHause> yeah, i found it... in my old hg checkout
15:15:36  <FLHerne> I suppose major hacks are different, but is that the right thing to do?
15:15:58  <glx> -a----       19/10/2019     22:12           7003 030_house.nml
15:15:58  <glx> -a----       19/10/2019     22:12            628 031_aircraft.nml
15:15:58  <glx> -a----       19/10/2019     22:12            769 032_simple_house.nml
15:16:01  <Eddi|zuHause> FLHerne: i guess that question is the reason why it was never included
15:16:09  <glx> that's what I have here
15:16:25  <glx> no comment test
15:16:40  <Eddi|zuHause> glx: well, it should be added by my patch
15:17:01  * FLHerne was trying to figure out how to attach comments to the relevant syntax element in NML, mostly so that round-tripping wouldn't eat them
15:17:08  <Eddi|zuHause> glx: also, i should maybe renumber it :)
15:17:14  <FLHerne> (I haven't figured out how to make that not suck yet)
15:17:42  <FLHerne> What hack is it intended for?
15:18:15  <glx> action 0C comments are mainly for grf decompilation
15:19:04  <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support
15:19:24  <FLHerne> Ok, but for nml-generated grfs that doesn't seem useful
15:19:35  <Eddi|zuHause> FLHerne: i compile multiple grfs, and then cut out certain lines to combine them
15:20:44  <Eddi|zuHause> so i have multiple grfs of the format "<head><body><tail>", and want a resulting GRF containing <head><body1><body2><body...>
15:21:03  <Eddi|zuHause> so i need a recognizable pattern for "head ends here" and "tail starts here"
15:21:18  <Eddi|zuHause> that's what i use the actionC for
15:21:59  <FLHerne> Um
15:22:20  <Eddi|zuHause> it... works... but is not very elegant
15:22:39  <FLHerne> Wouldn't sticking the nml together like all andy's templates make more sense?
15:22:48  <FLHerne> Oh, you have stations or something?
15:22:57  *** supermop_work_ has quit IRC
15:23:10  <Eddi|zuHause> FLHerne: compiling the full grf in one go tended to crash from memory explosion in parsing
15:23:27  <FLHerne> That sounds like the bug to fix :P
15:24:14  <Eddi|zuHause> i guess the root of that problem is python's string handling, where modifying a string results in a full copy of the string
15:24:19  *** supermop_work_ has joined #openttd
15:24:24  <Eddi|zuHause> but i've never gone anywhere on debugging that
15:24:35  <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #65: Fix #57: Check coherency of GRF parameters limits
15:24:41  <FLHerne> I did have some ideas for speeding that up
15:25:28  <Eddi|zuHause> FLHerne: the main problem with that is that this would be inside lex/yacc code, and not nml itself
15:25:45  <FLHerne> Some sort of pre-parsing pass to split the input into blocks before giving it to the parser would probably help
15:26:14  *** WormnestAndroid has joined #openttd
15:26:31  <Eddi|zuHause> FLHerne: we're talking about some 100k lines of nml code here
15:26:51  <FLHerne> I think that means your grf is too big, but yes
15:27:13  <FLHerne> Oh, I was meaning to ask
15:27:21  <Eddi|zuHause> FLHerne: well, the generator is about 1k lines, and the vehicle table is another 1k lines... :)
15:27:30  <FLHerne> Does the line_directive import stuff in the parser actually work?
15:27:35  <FLHerne> I've never seen it used
15:27:49  <Eddi|zuHause> ?
15:28:44  <FLHerne> (or did I just completely fail to understand what that's about)
15:29:17  <Eddi|zuHause> i've no clue what you're talking about
15:29:41  <FLHerne> Oh, I see what it's for
15:30:34  <FLHerne> The parser understands directives of the form `#line linenum file`, so a preprocessor can tell it where the lines originally came from
15:31:04  <FLHerne> And the error output will show that instead of the original filename/linenumbering
15:31:11  <Eddi|zuHause> yes, that's for if you combine files via #include, the line can be traced back to the original file for error messages
15:32:13  <FLHerne> But it doesn't do the #include-ing itself, so that's no use for parsing the input in manageable chunks
15:32:15  <Eddi|zuHause> i think there's enough people using that so we would have heard about when it's not working
15:32:16  <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #64: Fix: enable VT100 sequences on windows
15:32:38  <Eddi|zuHause> FLHerne: no, all the #include-s are resolved before parsing
15:33:11  <FLHerne> Imprlementing a native #include that parsed the linked file separately would probably help
15:33:21  <FLHerne> Yeah
15:33:53  <Eddi|zuHause> yeah. we talked about that before, but that didn't sound like a project i was likely to tackle at any point
15:35:03  <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #65: Fix #57: Check coherency of GRF parameters limits
15:35:07  <Eddi|zuHause> (also, this would not adress the second part that my approach does, which is running several nmlc instances in parallel)
15:35:58  <FLHerne> Andy was suggesting that nmlc should use multiprocessing only the other day :P
15:36:02  <Eddi|zuHause> (the only single-thread bottleneck in my build process is grfcodec, which still takes significant amounts of time)
15:36:06  <glx> ah you parse many nml files then merge the nfo
15:36:40  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7842: Crash on one my save in every version of OpenTTD
15:38:11  <Eddi|zuHause> i think my last timing was like: complete build process (6 jobs in parallel) was 2 minutes, 1 minute of which was in grfcodec. and unfolding the parallel parts would result in 5 minutes total
15:40:01  <DorpsGek_III> [OpenTTD/nml] LordAro commented on pull request #64: Fix: enable VT100 sequences on windows
15:41:11  <Eddi|zuHause> <FLHerne> Andy was suggesting that nmlc should use multiprocessing only the other day :P <-- yeah, but i don't see how that could be accomplished
15:42:40  <DorpsGek_III> [OpenTTD/nml] LordAro approved pull request #65: Fix #57: Check coherency of GRF parameters limits
15:45:52  *** Terkhen has joined #openttd
15:45:53  *** ChanServ sets mode: +o Terkhen
15:46:11  *** XeryusTC has joined #openttd
15:46:51  *** Ammler has joined #openttd
15:47:22  *** V453000 has joined #openttd
15:47:51  *** Osai has joined #openttd
15:47:52  *** Yexo has joined #openttd
15:48:18  <andythenorth> what happens in the parse step?
15:48:52  *** avdg has joined #openttd
15:49:09  <andythenorth> it's relatively slow....
15:49:16  <Eddi|zuHause> andythenorth: how many years of computer science education do i have to give you before starting compiler construction 1 lecture? :p
15:49:22  *** fonsinchen has joined #openttd
15:49:36  *** ^Spike^ has joined #openttd
15:49:46  <andythenorth> just explain what it does in 3 lines, and we'll see how close my assumption was
15:50:23  <DorpsGek_III> [OpenTTD/OpenTTD] James103 commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs
15:50:51  *** SmatZ has joined #openttd
15:52:19  <andythenorth> or to put it another way, can an AST be constructed using multiple workers, similar to map:reduce?
15:52:27  <andythenorth> or is it fundamentally a single-worked process?
15:53:21  <andythenorth> hmm nmlc doesn't report how long the lexing takes
15:54:06  <Eddi|zuHause> andythenorth: typically it has to go through the file character by character, exactly once.
15:54:17  <andythenorth> maybe that's all inside, and reported as one timing
15:54:19  * andythenorth looks
15:54:33  *** supermop_work_ has quit IRC
15:54:54  <andythenorth> maybe I can insert more timing
15:55:02  <Eddi|zuHause> andythenorth: lexing is typically a pipe, so might be tricky to single out the timing
15:55:22  <andythenorth> hmm
15:55:47  <andythenorth> ok I'm not specifically interested in the lexer, just trying to get a handle on what's time consuming
15:55:54  <Eddi|zuHause> lexing reads a character, and tries to decide to put it into the current token, or start a new token
15:56:07  <andythenorth> parsing is 20-30% of a grf compile for me
15:56:43  *** supermop_work_ has joined #openttd
15:57:02  <Eddi|zuHause> i think there could be the problem, because python uses immutable strings, so adding a character to the token makes a copy of the string, instead of modifying it inplace
15:58:19  <Eddi|zuHause> it's not really THAT slow of an operation, but it could result in the memory explosion that i was experiencing
15:58:33  <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #64: Fix: enable VT100 sequences on windows
15:58:45  *** HerzogDeXtEr has joined #openttd
15:59:04  <andythenorth> unrelated: Iron Horse compiled grf is now ridiculously large
15:59:09  <andythenorth> ~19.5MB
15:59:23  <andythenorth> OpenTTD is 7.5MB
16:00:09  <glx> haha
16:00:39  <andythenorth> there are 93000 instances of this path 'generated/graphics/'
16:01:04  <andythenorth> the generated nfo is 17.9MB which seems insane
16:01:16  <LordAro> does the nfo contain the paths?
16:01:16  <andythenorth> the actual png files are only 4.3MB
16:01:25  <andythenorth> yes the nfo contains the paths
16:01:26  <glx> 17MB for a text file ?
16:01:33  <andythenorth> yup
16:01:51  <andythenorth> the nml is 10.7MB, so nml is somehow more efficient
16:02:04  <LordAro> @calc 93000 * (19 - 4)
16:02:04  <DorpsGek> LordAro: 1395000
16:02:16  <LordAro> well you could remove 1MB by replacing the path to be g/g/ :p
16:02:16  <DorpsGek_III> [OpenTTD/OpenTTD] Awizonosz commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs
16:02:26  <Eddi|zuHause> andythenorth: impressive, CETS is only 11MB
16:02:36  <andythenorth> presumably the final grf doesn't include the image paths though
16:02:41  <FLHerne> andythenorth: The problem is that it's an LR parser
16:02:52  <andythenorth> nml
16:02:58  <andythenorth> nfo
16:03:07  <FLHerne> Or LALR? something-rightmost, anyway
16:03:23  <Eddi|zuHause> FLHerne: almost all compilers ever are LALR(1)
16:03:24  <LordAro> andythenorth: you can run `strings` on the grf to see what text it contains
16:03:25  <andythenorth> at this filesize, Iron Horse needs splitting into separate grfs
16:03:31  <andythenorth> or I need to redesign it
16:03:57  <FLHerne> Eddi|zuHause: Ok, the problem is that and it's written in Python :P
16:04:00  <andythenorth> LordAro: how? o_O
16:04:10  <LordAro> `strings foo.grf | less`
16:04:32  <LordAro> if it contains the paths repeatedly, that'll show up
16:05:00  <FLHerne> Hm, nevermind, what I was saying is stupid
16:05:19  <Eddi|zuHause> andythenorth: modern games have 30GB patches...
16:05:37  <glx> after a 30GB install ;)
16:05:45  *** frosch123 has joined #openttd
16:06:10  <andythenorth> Eddi|zuHause: true, but there's no need for Horse to be this big
16:06:29  <andythenorth> and it will scale horribly if I add 4 more different rosters in the same grf
16:07:01  <glx> maybe it's the way you organise your stuff in the grf
16:07:16  <Eddi|zuHause> conversation from last night: "i can't play CoD, because of 20GB patch" – "that's just 1/6 of the total game size"
16:07:34  *** WormnestAndroid has quit IRC
16:07:36  <glx> I guess you have a lot of duplication in your nml
16:07:56  <andythenorth> there are hundreds or thousands of almost identical varact 2 chains
16:08:01  *** WormnestAndroid has joined #openttd
16:08:09  <glx> that's the issue
16:08:17  <andythenorth> but they end on a different realsprite, and there's no way to pass the target sprite along the chain
16:08:23  <andythenorth> the whole chain has to be duplicated
16:08:28  <Eddi|zuHause> glx: removing duplication is not trivial, as the number of parallel IDs is severely limited
16:08:53  <Eddi|zuHause> also, nml has no support for procedures
16:09:14  <glx> can't set a temporary parameter at the begining of the chain ?
16:09:30  <andythenorth> not to get a realsprite no
16:09:34  <andythenorth> afaict
16:09:58  <andythenorth> there's no equivalent of "with (spritesheet): long logic chain -> result"
16:10:10  <Eddi|zuHause> you would need a giant switch that contains "all" realsprites
16:10:24  <andythenorth> for every branch of the chain
16:10:28  <andythenorth> the saving would be dubious
16:10:45  <Eddi|zuHause> which would just be a mapping number->realsprite
16:10:46  <andythenorth> I already considered that and rejected it :P
16:11:07  <Eddi|zuHause> that would read the number from the temp parameter
16:11:27  <andythenorth> it would just be the vehicle ID no?
16:11:55  <Eddi|zuHause> no
16:12:51  <Eddi|zuHause> if any vehicle had more than one realssprite, it would have to be differentiated there
16:13:08  <Eddi|zuHause> and if it didn't you wouldn't need any varaction2 in the first place
16:13:15  <andythenorth> if we had functions :P
16:13:27  <andythenorth> it could just be a function call, yielding a number, and then switch realsprite on that
16:13:37  <Eddi|zuHause> yes
16:13:58  <glx> hmm but there are procedure calls
16:14:12  <Eddi|zuHause> glx: there are in nfo, but nml cannot create them
16:14:29  <glx> that's something to add I guess :)
16:14:38  <Eddi|zuHause> i tried to look into it, but got nowhere
16:16:18  *** Wormnest has joined #openttd
16:16:20  <Eddi|zuHause> 9. Sep 2014  nml-hg/nml_call_procedure.diff
16:17:44  <Eddi|zuHause>
16:18:11  <Eddi|zuHause> i _think_ that sort of worked, but you couldn't pass any nml expressions as parameter
16:20:30  <Eddi|zuHause> and parameter would need to be the name of a switch, iirc
16:21:06  <Eddi|zuHause> so you need a param_function that converts the name of a switch to its ID
16:22:21  <Eddi|zuHause> overall, it seems a bit hacky, and there's probably a better syntax
16:23:51  <Eddi|zuHause> i vaguely remember trying a second approach, but can't find any evidence of that
16:26:46  <glx> grf doc is not very clear, I need to check implementation in openttd :)
16:26:58  *** supermop_work_ has quit IRC
16:28:45  *** supermop_work_ has joined #openttd
16:33:21  <Eddi|zuHause> <-- not sure what's unclear
16:33:49  <glx> for me it's the nfo syntax ;)
16:34:23  <glx> it's not the most human friendly language
16:34:27  <FLHerne> I think NFO docs could do with a summary of what the different action types are for and how they're typically used together
16:34:42  <FLHerne> (unless I've missed it)
16:34:42  <Eddi|zuHause> glx: yeah, it's a little... low level
16:34:56  <andythenorth> action 0, 2, 3, 1
16:34:58  <andythenorth> simples
16:35:00  <FLHerne> All the information is /there/ in the individual action docs
16:35:13  <andythenorth> there's probably a tutorial somewhere
16:35:24  <andythenorth> but I've heard this question from too many programmers :)
16:35:41  <andythenorth> I have a feeling that nfo originates in the same place as perl :P
16:35:48  <andythenorth> someone like me, not a programmer
16:35:49  <FLHerne> But to piece together a high-level picture of how they fit together, I have to read all of them, and reading them is hard when I don't know what they're for :P
16:36:06  <Eddi|zuHause> andythenorth: i don't see the connection
16:37:08  <Eddi|zuHause> andythenorth: nfo is very clear and structured, if you come from a ttdpatch mindset
16:37:40  <FLHerne> AAUI, that was the point
16:38:00  <andythenorth> I don't know what my exact point is, but I've seen multiple people struggle to grok nfo
16:38:06  <FLHerne> NFO isn't a language/format created top-down to make logical sense
16:38:10  <andythenorth> there's something non-getttable about it for some programmers
16:38:33  <glx> oh there can be something between <variable> and <varadjust>
16:39:00  <Eddi|zuHause> glx: yeah, i was just looking for where that info is actually written
16:39:02  <FLHerne> It's a bottom-up collection of behaviours that people hacked incrementally into TTDPatch and then OTTD
16:40:11  <glx> "When the variable in a VarAction2 is 7E, the procedure given by the 60+x parameter is invoked." <-- I didn't see where the parameter could be
16:42:06  <Eddi|zuHause> "60+x	D		similar to 40+x variables, but the variable number must be followed by a byte, which will be given to the variable handler as parameter."
16:42:22  <Eddi|zuHause> it's a bit buried
16:43:15  <Eddi|zuHause>
16:43:27  <glx> yup found it
16:45:37  *** snail_UES_ has joined #openttd
16:48:04  <Eddi|zuHause> btw. do we meanwhile have syntax for 6x vars like var 61?
16:49:02  <Eddi|zuHause> CETS is still using the var[num, shift, mask, param] syntax
16:50:23  <glx> there are many varact2vars60x_
16:50:25  <FLHerne> Basic thing: when the docs say "You can add 80 to the operation number..." etc. I assume that's hex?
16:50:31  <glx> depending on feature
16:51:04  <Eddi|zuHause> FLHerne: yes
16:51:07  <glx> yes this 80 should be hex
16:51:12  <glx> setting a bit
16:51:25  <Eddi|zuHause> everything in NFO is hex, except for the sprite number and length
16:51:42  <glx> basically everything is hex unless otherwise specified
16:51:58  <FLHerne> Ok, thought so
16:57:41  <DorpsGek_III> [OpenTTD/OpenTTD] JGRennison commented on issue #7842: Linkgraph takes a very long time to recalculate on large save, causing hangs
16:58:59  *** supermop_work_ has quit IRC
17:00:48  *** supermop_work_ has joined #openttd
17:30:58  *** planetmaker has quit IRC
17:30:59  *** lpx has joined #openttd
17:30:59  *** josef[m]1 has joined #openttd
17:30:59  *** natalie[m] has joined #openttd
17:30:59  *** paulus[m] has joined #openttd
17:30:59  *** dude[m] has joined #openttd
17:30:59  *** ist5shreawf[m] has joined #openttd
17:30:59  *** goodger has joined #openttd
17:31:22  *** pm has joined #openttd
17:31:22  *** ChanServ sets mode: +o pm
17:32:35  *** gelignite has joined #openttd
18:06:28  *** Progman has joined #openttd
18:32:04  *** pm is now known as planetmaker
18:36:03  *** WormnestAndroid has quit IRC
18:36:22  *** WormnestAndroid has joined #openttd
18:36:38  *** Wormnest has quit IRC
18:37:15  *** Alkel_U3 has quit IRC
18:46:39  *** Alkel_U3 has joined #openttd
18:47:00  *** supermop_work_ has quit IRC
18:47:58  *** supermop_work_ has joined #openttd
19:32:52  <andythenorth> no wolf :P
19:33:10  * andythenorth has spent nearly two days just routing pneumatic pipes :P
19:33:12  <andythenorth> oof
19:34:46  <frosch123> irc is tricky to join today
19:35:24  <frosch123> didn't you scale down on lego? or was that wolf?
19:40:21  <andythenorth> I scaled down on Lego
19:40:27  <andythenorth> but there are unfinished things
19:40:33  <andythenorth> [aren't there always?]
19:40:58  <andythenorth> this
19:51:35  *** tokai|noir has joined #openttd
19:51:35  *** ChanServ sets mode: +v tokai|noir
19:56:25  <andythenorth> now looks like
19:56:56  <andythenorth> there's about 4 days of progress between the 2 :P
19:57:12  <andythenorth> lego is even slower than making OpenTTD stuff
19:58:29  *** tokai has quit IRC
20:00:07  <frosch123> plastic pixels
20:01:49  <supermop_work_> it's taken be a week to connect a limestone mine to this steel mill
20:02:47  <supermop_work_> get home from work, look at network plot alignment, get unsure how i want junction to look, or what else i want trains to do, give up
20:03:04  *** Wormnest has joined #openttd
20:06:25  <andythenorth> steeltown?
20:21:18  <andythenorth> hmm
20:21:30  <andythenorth> wonder if I could diff the vehicle properties
20:21:54  <andythenorth> if only action 0 is changed, I could modify the generated nfo directly, instead of generating nml then nfo
20:22:04  <andythenorth> I already skip nml if it's only sprites changed
20:30:46  * FLHerne experiments with various ways to improve NML's parsing performance
20:31:20  <FLHerne> (so far, no good :P)
20:32:52  <andythenorth> move the parse to C++
20:34:02  <glx> <-- seems to be enough for procedure calls (at least the NFO seems good)
20:34:46  <glx> (of course the regression change is just for testing)
20:36:07  <andythenorth> o_O
20:36:39  <glx> added the output in paste comment
20:46:09  <andythenorth> I've never used procedures, so I don't have a good test case trivially
20:46:42  *** supermop_work_ has quit IRC
20:46:57  <andythenorth> can we do a regression test or example for them?
20:47:14  *** supermop_work_ has joined #openttd
20:48:29  <glx> basically you write a swicth or random_switch, and you use its ID as a variable in another switch
20:48:54  <glx> that's how I understand the spec
20:49:00  <andythenorth> yes that makes sense
20:49:20  <glx> I think I need to add some safety checks
20:50:01  <andythenorth> do we know if stored procedures respect temp registers?
20:51:43  <andythenorth> not mentioned here afaict
20:52:03  <frosch123> they are in the same chain
20:52:28  <frosch123> so nml has to make sure to not use registers in the main chain, which are modified in the procedure
20:52:32  <andythenorth> if I understand them correctly, I might be able to cut down the code surface in some grfs by large amounts
20:52:54  <frosch123> if you have an expression in the procedure, nml will use registers to store intermediate values
20:53:14  <frosch123> if you use the procedure in an expression, that expression may also have temporary values
20:53:33  <frosch123> which probably should not get destroyed by the procedure
20:54:33  <andythenorth> for a given vehicle type, if I can consolidate to a shared varact 2 chain, there might be 40 vehicle instances that can use it
20:54:34  <frosch123> so, wherever nml allocates temporary registers, it needs to keep track of which are modified by procedures
20:57:18  <andythenorth> wonder how long I could spend making it compile faster? o_O
20:58:13  <frosch123> i guess nml could output an intermediate format instead of nfo, so you can somehow invoke it differently if the nml sources dont change
20:58:36  <frosch123> nml sprite encoding with sprite cache and stuff is better than grfcodec after all
20:58:59  <frosch123> so it would be worth it to support the nml+grfcodec split inside nml
20:59:18  <frosch123> without actually using grfcodec or nfo format
21:01:29  <andythenorth> pickle :P
21:01:37  <andythenorth> there's an AST or something?
21:01:49  <frosch123> too complicated, just the action list
21:02:14  <frosch123> same info as in nfo, but using json or whatever
21:03:07  <glx> after some testing, I clearly need safety checks
21:03:29  <FLHerne> Hm
21:03:45  <FLHerne> Dropping line-number tracking knocks 20% off the parse time
21:04:01  <andythenorth> the grfcodec compile for Iron Horse 400k loc is 6s
21:04:20  <andythenorth> teach nml nfo? :P
21:04:23  <FLHerne> Of course, people do like line numbers in their error messages
21:04:34  *** gelignite has quit IRC
21:04:38  <andythenorth> I could live with suppressing it FLHerne
21:04:45  <andythenorth> I will then act surprised that they're gone :P
21:04:52  <glx> line number is useful when you have 100k lines :)
21:05:01  <frosch123> andythenorth: nfo is horrible to parse. better use something with python-built-in parsers
21:05:21  <andythenorth> json would also permit evil :P
21:05:23  <FLHerne> I think the right thing would be to count lines up to a given lexpos as and when we need to give an error :P
21:05:39  <andythenorth> I could...for example...just skip the nml step :P
21:06:01  <andythenorth> this could be a good move
21:06:07  <FLHerne> frosch123: I don't see what you're trying to achieve with that
21:06:27  <FLHerne> If the actions haven't changed, why not just keep the NFO?
21:06:29  <frosch123> FLHerne: andy complains about compile time when only changing graphics
21:07:07  <andythenorth> it's not too bad now I added the grfcodec step
21:07:22  <frosch123> when grfcodec takes only 6s for horse, it may not be worth the effort
21:07:42  <frosch123> but for 32bpp grfs nml is multiple times faster than grfcodec with encoding sprites
21:08:39  <FLHerne> frosch123: Oh, so you don't want to /change/ the NFO, but you want to get the realsprite data without (re)parsing the NML?
21:09:31  <frosch123> currently andy makes nml generate nfo, and then used grfcodec for nfo+sprites=grf
21:09:45  <frosch123> then andy skips nml if only sprites change
21:10:13  <frosch123> that split is fine, but it would be even faster if grfcodec was replaced with something using the nml encoding
21:11:12  <andythenorth> it was suprisingly effective strategy
21:11:24  <andythenorth> and a lot less string than previous attempts like partially compiling nml
21:14:29  *** arikover has joined #openttd
21:17:27  *** supermop_work_ has quit IRC
21:18:53  *** supermop_work_ has joined #openttd
21:22:31  <FLHerne> There's no such thing as a multiline string in NML, is there?
21:23:28  <FLHerne> I think the answer is "yes there is" :-/
21:24:10  <frosch123> there are hardly any strings in nml?
21:24:14  <frosch123> not sure what you mean
21:24:39  <FLHerne> ...but that would throw the calculated line number off, so perhaps that's hypothetical if no-one cared
21:25:07  <frosch123> expressions can be split over multiple lines
21:25:29  <frosch123> nml is a token-based language, so linebreaks are like any other whitespace
21:25:39  <FLHerne> Yes, I got that
21:26:15  <FLHerne> The parser doesn't have anything that prevents a literal-string from containing newlines
21:26:44  <FLHerne> It may be that there are no circumstances in which a literal-string is semantically permitted to contain them :P
21:27:11  <FLHerne> In which case there's no problem if I mess those up
21:29:27  <andythenorth> ha ha
21:29:32  * andythenorth is using the Migrations GS
21:29:34  <andythenorth> it's quite interesting
21:29:48  <andythenorth> it builds towns near newly serviced industries and moves population there
21:30:06  <andythenorth>
21:30:26  <andythenorth> it ruins my industries for transport though, by surrounding them with houses :D
21:30:40  <FLHerne> Answer: yes, you can have newlines in (at least) town names
21:31:12  <frosch123> oh, i forgot town names :)
21:31:20  <frosch123> yeah, they are different to everything else
21:31:32  <frosch123> but i guess newlines are still invalid there
21:31:44  <frosch123> since ottd encodes newlines as \r instead of \n
21:32:36  <frosch123> so if nml actually creates \n in strings, then that is wrong anyway, so you can also forbid it :)
21:33:19  *** karoline[m] has joined #openttd
21:49:04  *** supermop_work_ has quit IRC
21:50:52  *** supermop_work_ has joined #openttd
22:06:48  <arikover> snail_UES_: Hello!
22:13:18  *** tokai has joined #openttd
22:13:18  *** ChanServ sets mode: +v tokai
22:13:37  *** snail_UES_ has quit IRC
22:16:57  *** snail_UES_ has joined #openttd
22:20:18  *** tokai|noir has quit IRC
22:21:05  *** supermop_work_ has quit IRC
22:21:50  *** sla_ro|master has quit IRC
22:22:53  *** supermop_work_ has joined #openttd
22:39:36  *** Arveen2 has quit IRC
22:45:34  *** WormnestAndroid has quit IRC
22:46:21  *** WormnestAndroid has joined #openttd
22:49:57  *** andythenorth has quit IRC
22:55:33  *** frosch123 has quit IRC
22:58:29  *** WormnestAndroid has quit IRC
22:58:53  *** WormnestAndroid has joined #openttd
23:03:26  *** arikover has quit IRC
23:06:40  *** Flygon has joined #openttd
23:17:36  *** Samu has quit IRC
23:28:52  <DorpsGek_III> [OpenTTD/nml] glx22 opened pull request #66: Add: allow use of switches and random switches as procedures
23:29:07  <glx> it's just a starting point
23:29:39  *** nielsm has quit IRC
23:38:31  *** Progman has quit IRC
23:39:34  *** WormnestAndroid has quit IRC
23:40:00  *** WormnestAndroid has joined #openttd
23:47:05  *** supermop_work_ has quit IRC
23:48:53  *** supermop_work_ has joined #openttd

Powered by YARRSTE version: svn-trunk