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 https://github.com/OpenTTD/nml/pull/60#issuecomment-555688292 07:39:36 <DorpsGek_III> [OpenTTD/nml] andythenorth commented on pull request #59: Simplify pillow imports and version detection https://git.io/Jei54 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> https://firs-test-1.s3.eu-west-2.amazonaws.com/iron-horse/docs/html/tech_tree.html 10:41:12 <andythenorth> https://firs-test-1.s3.eu-west-2.amazonaws.com/iron-horse/docs/html/tech_tree_table_red.html 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 https://git.io/Jeipa 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 https://git.io/JeiaJ 14:02:58 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeKFk 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 https://git.io/JeipS 14:38:38 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #60: Avoid duplicating rail/road/tramtype table code https://git.io/JeKFk 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 https://git.io/Jeihf 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. https://git.io/Jei25 14:49:22 <DorpsGek_III> [OpenTTD/nml] FLHerne updated pull request #63: Allow PLY to generate parsing/lexing tables. https://git.io/Je6uy 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 https://git.io/Jeihk 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 https://git.io/JeKFk 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. https://git.io/JeihL 14:56:49 <DorpsGek_III> [OpenTTD/nml] LordAro merged pull request #63: Allow PLY to generate parsing/lexing tables. https://git.io/Je6uy 14:58:24 <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support https://git.io/fhpED 14:59:51 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #35: Fix ottd_display_speed to reflect changes done in OpenTTD https://git.io/Jeihq 15:00:19 <DorpsGek_III> [OpenTTD/nml] Eddi-z updated pull request #21: Eddi-nml branch for ActionC support https://git.io/fhpED 15:00:39 <DorpsGek_III> [OpenTTD/nml] glx22 commented on pull request #28: Fix: Allow access to towns as parent object https://git.io/Jeihm 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 https://git.io/fhpED 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> https://github.com/OpenTTD/nml/pull/21/checks#step:8:40 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 https://git.io/fhpED 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 https://git.io/Jei6E 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 https://git.io/JeiCF 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 https://git.io/Jei6E 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 https://git.io/Jeig0 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 https://git.io/Jeije 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 https://git.io/JeijL 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 https://git.io/Jeig0 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 parser.py, 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 https://git.io/JeiCF 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 https://git.io/Jeig0 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 https://dev.openttdcoop.org/attachments/download/9538/iron-horse.nml 16:02:58 <andythenorth> nfo https://dev.openttdcoop.org/attachments/download/9537/iron-horse.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> https://paste.openttdcoop.org/pk8vd24zh 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> https://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced#Using_procedures <-- 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> https://newgrf-specs.tt-wiki.net/wiki/VariationalAction2#Variable 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 https://git.io/Jeig0 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 https://www.flickr.com/photos/andythenorth/31469465448/ 19:51:35 *** tokai|noir has joined #openttd 19:51:35 *** ChanServ sets mode: +v tokai|noir 19:56:25 <andythenorth> now looks like https://www.flickr.com/photos/andythenorth/49117676521/in/dateposted-public/ 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> https://paste.openttdcoop.org/pitvvmta8 <-- 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 https://newgrf-specs.tt-wiki.net/wiki/VarAction2Advanced#Using_procedures 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> https://www.tt-forums.net/viewtopic.php?f=65&t=85867 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 https://git.io/JePq0 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