Log for #openttd on 30th November 2019:
Times are UTC Toggle Colours
00:00:21  *** nielsm has quit IRC
00:00:29  <LordAro> wouldn't normally have that affect
00:00:56  <glx> nice a segfault when rendering the docs
00:01:48  <glx> (graphviz crash I guess)
00:02:59  <glx> let's uninstall graphviz then
00:05:21  <glx> better without graphviz :)
00:06:05  <glx> language warnings and finally nmlc ERROR: "generated/firs.nml", line 7342: Syntax error, unexpected token "waiting_cargo_1"
00:06:23  <glx> so firs is broken :)
00:07:18  <glx> needs older nmlc I guess
00:07:28  *** Smedles has quit IRC
00:08:47  <glx> anyway for docs I needed to install python3-markdown
00:09:44  <glx> so using mingw it 'works'
00:10:06  <Flo> oh so dumb...i just noticed i installed setuptools and cameleon but forgot markdowns...
00:10:13  <glx> nmlc errors, but makefile just works
00:11:35  <glx> with mingw it's often easier to install python module via pacboy (pip should work but sometimes fails if there's a module to compile)
00:12:11  <glx> anyway if pip works it's ok too
00:12:31  <glx> I think it failed for pillow
00:13:25  <Flo> there added markdown now :) i though ive put the 3...but ive only put 2...
00:14:52  <Flo> ugh...
00:14:58  <Flo> same still happening
00:15:03  *** Flygon has joined #openttd
00:15:25  <glx> oh of course it needs python3 exe
00:15:37  <glx> try "pacboy -S python3"
00:15:52  <Flo> pacboy -S python3
00:16:01  <Flo> sh: pacboy: command not found
00:16:21  <glx> oh you're on the old mingw
00:16:39  <glx> ie mingw32
00:16:44  <Flo> yes
00:16:54  <glx> you should move to mingw-w64
00:16:57  *** Smedles has joined #openttd
00:17:03  <glx> mingw32 is outdated
00:17:12  <Flo> oh
00:17:24  <LordAro> i'm surprised you managed to get as far as you did
00:17:42  <LordAro> especially python3.8
00:18:14  <glx> it's using the windows installed python
00:18:37  <LordAro> ah, that makes sense
00:19:31  *** supermop_work_ has quit IRC
00:19:47  <glx> hmm typing python3 doesn't error in powershell, but it does nothing it seems
00:21:10  <glx> haha in cmd it opens windows store
00:21:11  <Flo> im installing the new mingw now
00:21:19  <Flo> oh wow
00:22:26  <Flo> buy python3, starting from only 199,99$. only available for windows proffesional
00:23:45  <LordAro> ?
00:23:54  <Flo> it was a joke
00:24:05  <Flo> when he said cmd took him to windows store
00:24:24  <LordAro> oh lol
00:24:24  <glx> yeah it's free, but it can be annoying :)
00:24:50  *** supermop_work_ has joined #openttd
00:25:03  <glx>
00:25:07  <glx> that's the page
00:25:59  <glx> it's a shortcut they added in the last major update IIRC
00:27:44  <Flo> there :) added new mingw
00:34:18  <glx> follow initial pacman -Syu steps ?
00:35:16  <Flo> yes i did that
00:35:43  <glx> you can close msys2 and open mingw
00:36:39  <glx> you'll need to do "pacboy -S python3"
00:38:06  <glx> and some other packages are needed too
00:38:47  <Flo> its doing python3 right now :)
00:39:06  <Flo> thx for the help btw
00:39:11  <Flo> its really apreciated
00:40:00  <glx> probably "pacboy -S make" too
00:41:16  <glx> that should be a good start
00:41:40  <glx> of course you'll need to install required python modules too
00:42:11  <Flo> i guess :)
00:42:19  <glx> via "pip install" or "pacboy -S python3-<module>" if pip fails
00:42:57  <LordAro> i'd start with the latter
00:43:24  <Flo> there, python3 and make added :)
00:45:18  <Flo> python3 command works but not make
00:45:45  <glx> what does it say ?
00:46:14  <Flo> $ make
00:46:15  <Flo> -bash: make: command not found
00:47:39  <glx> but it should be installed
00:47:44  <Flo> ik...
00:49:52  *** Progman has quit IRC
00:52:09  <Flo> it is there
00:52:11  <Flo> C:\msys64\var\lib\pacman\local\mingw-w64-x86_64-make-4.2.1-4
00:55:04  *** supermop_work_ has quit IRC
00:56:00  <glx>  pacboy packages | grep install | grep make
00:56:08  <glx> you should see it there too
00:57:22  <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel dismissed a review for pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load
00:57:23  <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel updated pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load
00:58:45  <glx> I can see I have the 3 variants installed mingw32 mingw64 and msys
01:00:04  *** supermop_work_ has joined #openttd
01:00:29  <Flo> theres nothing in C:\msys64\var\cache\pacboy
01:01:15  <Flo> idk how to check  pacboy packages | grep install | grep make
01:01:30  <glx> just type it in mingw shell
01:02:08  <Flo> oh wait i found it
01:02:11  <Flo> oh sorry
01:03:07  <glx> my output for this command contains:
01:03:07  <glx> mingw32 mingw-w64-i686-make 4.2.1-4 [installé]
01:03:07  <glx> mingw64 mingw-w64-x86_64-make 4.2.1-4 [installé]
01:03:07  <glx> msys make 4.2.1-1 [installé]
01:03:53  <glx> (and cmake and many automake but that's useless for you)
01:05:07  <Flo>  pacboy packages | grep install | grep make
01:05:07  <Flo> mingw32 mingw-w64-i686-make 4.2.1-4 [installed]
01:05:07  <Flo> mingw64 mingw-w64-x86_64-make 4.2.1-4 [installed]
01:05:17  <Flo> msysmake not there
01:05:35  <glx> so it's installed for mingw
01:06:26  <glx> I guess "which make" fails
01:06:49  <Flo> yes
01:07:44  *** WormnestAndroid has quit IRC
01:07:57  <Flo> there
01:08:02  <Flo> i added it for msys
01:08:06  <Flo> now the 3 are there :)
01:08:30  <glx> yeah it seems it's using msys one on my system
01:08:39  *** WormnestAndroid has joined #openttd
01:09:20  <Flo> yeah i added the msys one and now make is available
01:09:20  <glx> of I know why
01:09:48  <glx> it's because mingw make are called mingw64-make and mingw32-make
01:09:56  <Flo> oh
01:11:37  <glx> a bit silly but ok :)
01:12:02  <glx> so now you have make and python3
01:12:13  <Flo> yes :)
01:14:24  <glx> I don't know if pip is installed via python3
01:15:56  <glx> but it's easy to "pacboy -S python3-pip" if it's not
01:18:28  <Flo> installing pip
01:18:47  <glx> usual python modules are also available in packages
01:19:02  <Flo> installed
01:19:55  <Flo> there
01:20:02  <Flo> pip is now available
01:20:56  <glx> hmm first try "pacboy -S python3-<module>", I know pillow install fails with pip
01:22:20  <Flo> pacboy -S python3-<module>
01:22:21  <DorpsGek_III> [OpenTTD/OpenTTD] MingweiSamuel commented on pull request #7595: Possible fix for #7430: when train visits station, only reset time_since_pickup if has room to load
01:22:43  <Flo> $ pacboy -S python3-<module>
01:22:43  <Flo> -bash: syntax error near unexpected token `newline'
01:22:51  <glx> replace <module> with its name
01:22:56  <Flo> oh sorry
01:23:17  <glx> pacboy -S python3-ply python-pillow
01:23:38  <glx> *python3-pillow sorry
01:23:49  <glx> python3-markdown exists too
01:24:27  <glx> I think you'll need pip only for nml
01:24:50  <Flo> $ pacboy -S python3-pillow
01:24:50  <Flo> error: target not found: python3-pillow
01:26:11  <Flo> same with python3-markdown
01:27:13  <glx> but I have them
01:27:24  <glx> pacboy find pillow
01:27:41  <glx> it should show them (even uninstalled)
01:27:49  <Flo> oh I see why
01:27:58  <Flo> I was in msys
01:28:00  <glx> hehe
01:29:13  <Flo> there they added :)
01:29:32  <glx> if you want to install something for msys you can do it from mingw by just adding :m to the package name (pacboy -S make:m)
01:29:50  <Flo> oh thats cool to know :)
01:29:53  <Flo> thx for the info
01:30:18  *** supermop_work_ has quit IRC
01:31:27  *** supermop_work_ has joined #openttd
01:33:54  <glx> oh no sorry I miss read the help
01:34:16  <glx>         For 64-bit MSYS2, name:i means i686-only
01:34:16  <glx>         For 64-bit MSYS2, name:x means x86_64-only
01:34:16  <glx>         For MSYS shell, name:m means mingw-w64
01:34:42  <glx> so to install stuff in msys you need to be in msys
01:35:03  <Flo> oh
01:35:04  <glx> but from msys you can install in mingw using :m
01:35:04  <Flo> ok
01:35:07  <Flo> oh
01:35:32  <glx> use "pacman help" to see more details
01:36:09  <glx> anyway you rarely need to install stuff in msys
01:36:14  <Flo> oh
01:36:54  <glx> unless like make it doesn't work as expected
01:37:10  <Flo> right
01:37:15  <Flo> I still get this though:
01:37:17  <Flo> which: no dot in (/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/)
01:37:43  <glx> yeah, it's graphviz, ignore ite
01:37:45  <glx> *it
01:38:11  <Flo> oh ok
01:38:18  <glx> doc generation crashed for me when I installed graphviz ;)
01:38:37  <glx> it's optionnal anyway
01:38:41  <Flo> Oh
01:38:42  <Flo> Yeah
01:38:55  <Flo> Well then the last thing I get seems to be ModuleNotFoundError: No module named 'chameleon'
01:38:55  <Flo> make: *** [Makefile:75: generated/lang] Error 1
01:39:06  <Flo> But U got cameloan in my python... I think?
01:39:08  <Flo> I*
01:40:29  <Flo> Its in my python folder, but idk if it has to be in mingw
01:40:44  <glx> it's not the same python install
01:41:14  <Flo> oh
01:41:15  <glx> and it's not available as a mingw package, so pip install chameleon
01:41:34  <Flo> ok. how do I do pip install eacly?
01:41:57  <Flo> oh
01:41:59  <Flo> found it
01:45:35  <Flo> ok so I did pip install chameleon
01:45:44  <Flo> I still get no module called chameleon
01:45:45  <glx> usually for a missing python module you do "pacboy -S python3-<modulename>", and if it fails "pip install <modulename>"
01:46:28  <Flo> it said it installed chameleon with pip
01:46:41  <Flo> but I still get the module missing thing with make
01:46:52  <glx> installed in mingw ?
01:47:19  <glx> "pip list" should show all installed modules
01:47:58  <Flo> its in the list
01:49:30  <Flo> ModuleNotFoundError: No module named 'chameleon'
01:49:30  <Flo> make: *** [Makefile:78: docs] Error 1
01:49:30  <Flo> Florence@Flo-s-Laptop MINGW64 /c/Users/Florence/Downloads/firs-masterf/firs-master2
01:49:30  <Flo> $ pip list
01:49:30  <Flo> Package    Version
01:49:32  <Flo> ---------- ---------------------
01:49:32  <Flo> appdirs    1.4.3
01:49:34  <Flo> attrs      19.3.0
01:49:34  <Flo> Chameleon  3.6.2
01:49:38  <Flo> maybe the capital C?
01:49:50  <glx> no it's ok
01:49:55  <glx> it's installed
01:50:15  <Flo> oh...
01:50:41  <glx> hmm and ugrading my msys/mingw install removed nml
01:51:20  <glx> oh it remove all stuff I previously installed via pip
01:51:54  <Flo> wow...
01:52:25  <glx> so yeah using pacboy for python modules is a good idea :)
01:52:54  <glx> oh of course it upgrade python
01:53:05  <glx> I was on 3.7.4 and now it's 3.8
01:53:08  <glx> makes sense
01:53:37  <Flo> oh...
01:54:04  <Flo> so whats wrong with my chameleon?
01:54:56  <glx> reinstalling my local nmlc
01:55:14  <Flo> oh
01:55:46  <glx> and it works fine for me
01:56:05  <Flo> the chameleon?
01:58:53  <glx> I now get SyntaxWarnings during docs rendering (because python 3.8) but it works
01:59:05  <Flo> oh
02:01:36  *** supermop_work_ has quit IRC
02:08:04  <Flo> um
02:08:08  <Flo> maybe because C:\msys64\usr\lib\python3.7?
02:08:17  <Flo> chameleon location is in there
02:08:22  <Flo> but I use 3.8
02:15:09  <Flo> yes I found why
02:15:10  <glx> for mingw it should be in C:\msys64\mingw64\lib\python3.8
02:15:17  <Flo> oh
02:15:19  <Flo> thx
02:15:32  <glx> but pip installs it there
02:15:56  *** Thedarkb-X40 has joined #openttd
02:16:41  <glx> you ran "pip install" in mingw ?
02:16:51  <Flo> yes
02:18:51  <Flo> it puts it into msys
02:18:52  <Flo> Florence@Flo-s-Laptop MINGW64 ~
02:18:52  <Flo> $ pip install chameleon
02:18:52  <Flo> Requirement already satisfied: chameleon in /usr/lib/python3.7/site-packages (3.6.2)
02:19:34  <glx> oh it's the wrong pip
02:19:39  <Flo> oh...
02:20:43  <Flo> whats the right pip?
02:20:48  *** supermop_work_ has joined #openttd
02:21:16  <glx> pacboy find pip | grep install
02:21:48  <glx> I guess you have a pip in msys
02:22:08  <Flo> yeah your right
02:22:27  <glx> and none in mingw
02:22:48  <Flo> yep
02:22:49  <Flo> $ pacboy find pip | grep install
02:22:50  <Flo>     An easy_install replacement for installing pypi python packages (mingw-w64)
02:22:50  <Flo>     An easy_install replacement for installing pypi python packages (mingw-w64)
02:22:50  <Flo>     An easy_install replacement for installing pypi python packages (mingw-w64)
02:22:50  <Flo>     An easy_install replacement for installing pypi python packages (mingw-w64)
02:22:50  <Flo>     The PyPA recommended tool for installing Python packages
02:22:52  <Flo> msys/python3-pip 19.3.1-1 [installed]
02:22:52  <Flo>     The PyPA recommended tool for installing Python packages
02:23:33  <glx> pacboy -S python3-pip was done in the msys shell and not mingw shell :)
02:24:04  <Flo> yeah
02:24:09  <Flo> im very bad at this sorry
02:25:03  <Flo> Atleast after that ill be able compile my firs fork as many times as I want :D
02:25:58  <glx> well the clean firs doesn't compile for me, but I use the dev version of nmlc
02:26:10  <Flo> oh
02:29:26  <glx> ah yes it's because 16 input/output cargo
02:29:45  <Flo> oh...
02:30:01  <glx> my nmlc is too recent :)
02:31:07  <Flo> oof
02:31:10  <Flo> I get make: nmlc: Command not found
02:31:10  <Flo> make: *** [Makefile:93: generated/firs.grf] Error 127
02:31:18  <glx> pip install nml
02:31:29  <Flo> thx
02:32:22  <Flo>  Running install for nml ... error
02:32:22  <Flo>     ERROR: Command errored out with exit status 1:
02:33:17  <glx> I like when tools give very explicit messages :)
02:34:02  <Flo> ikr...
02:34:07  <glx> pip install -v nml
02:34:32  <glx> but I think I know why it fails
02:36:05  <Flo> ERROR: Command errored out with exit status 1: C:/msys64/mingw64/bin/python3.exe -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'C:/Users/Florence/AppData/Local/Temp/pip-install-dn_tymp4/nml/'"'"'; __file__='"'"'C:/Users/Florence/AppData/Local/Temp/pip-install-dn_tymp4/nml/'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);'"'"'\r\n'"'"',
02:36:05  <Flo> '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record C:/Users/Florence/AppData/Local/Temp/pip-record-ho7uyo_v/install-record.txt --single-version-externally-managed --compile Check the logs for full command output.
02:36:07  <Flo> Oh?
02:37:30  <Flo> Exception information:
02:37:30  <Flo> Traceback (most recent call last):
02:37:30  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\cli\", line 153, in _main
02:37:30  <Flo>     status =, args)
02:37:30  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\commands\", line 446, in run
02:37:30  <Flo>     installed = install_given_reqs(
02:37:30  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\req\", line 58, in install_given_reqs
02:37:32  <Flo>     requirement.install(
02:37:32  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\req\", line 886, in install
02:37:34  <Flo>     runner(
02:37:34  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\utils\", line 271, in runner
02:37:36  <Flo>     call_subprocess(
02:37:36  <Flo>   File "C:/msys64/mingw64/lib/python3.8/site-packages\pip\_internal\utils\", line 242, in call_subprocess
02:37:38  <Flo>     raise InstallationError(exc_msg)
02:38:12  <glx> for big copy/paste use ;)
02:38:39  <Flo> oh ok
02:38:41  <Flo> sorry
02:38:42  <glx> but I think "pacboy -S gcc" should do
02:39:34  <Flo> alright
02:40:41  <glx> it needs a compiler to build a lib
02:42:04  <Flo> oh
02:42:07  <glx> ahah and of course using this nml version fails too
02:42:09  <Flo> it worked :)
02:42:19  <glx> because pillow is too recent
02:42:34  <glx> and that's fixed in dev version
02:42:41  <Flo> oh
02:44:47  <Flo> oh oof I had ModuleNotFoundError: No module named 'ply'
02:45:04  <Flo> installing it
02:45:13  <Flo> there ;)
02:45:13  <glx> via pacboy ;)
02:45:20  <Flo> Oh I did with pip
02:45:43  <glx> works too
02:47:24  <Flo> um...
02:47:41  <Flo> I had Error:    (AttributeError) "module 'PIL.Image' has no attribute 'VERSION'".
02:47:57  <glx> yes pillow is too recent
02:48:15  <Flo> oh...
02:48:17  <Flo> welp
02:48:26  <Flo> how do I get an older pillow?
02:49:19  <Flo> or the version of firs that was fixed?
02:50:01  <glx> dev version of nmlc works with current pillow, but firs is not compatible with it
02:50:25  <Flo> oh...
02:50:41  <Flo> So what do I have to do?
02:51:00  *** supermop_work_ has quit IRC
02:51:37  <Flo> should I just get an older pillow?
02:53:40  *** supermop_work_ has joined #openttd
02:55:08  *** Wormnest_ has joined #openttd
02:57:24  <Flo> what version is compatible with it?
02:58:17  <glx> only dev version is compatible with pillow >6.0
02:59:21  <Flo> ill install pillow earlier than 6.0
02:59:27  <Flo> would that work?
02:59:35  <glx> I'm trying it
03:00:11  <Flo> ill put 5.4.1
03:00:33  <glx> I'm trying "pip install pillow\<6.0"
03:01:09  <Flo> oh
03:01:12  <glx> it's installing 5.4.1
03:02:27  <glx> and it failed
03:02:54  <Flo> same
03:03:01  <Flo> it failed to install it
03:03:32  <Flo> does not yet support python 3.7
03:03:35  <Flo> 3.8*
03:04:29  <glx> it fails to compile some stuff but I don't know why
03:05:03  <glx> same happens with >6.0
03:05:26  <glx> but the package is ok
03:05:52  <Flo> oh you got it installed on 3.8?
03:06:21  <glx> I mean 6.2.1 package, the one from pacboy
03:06:28  <Flo> oh
03:07:11  <Flo> seems like we would need to use python 3.7
03:08:31  <glx> ah yes I use python 3.7 on windows for that reason, because there a precompiled pillow package compatible
03:08:43  <Flo> oh
03:09:06  <Flo> well then I guess ill do everything again but in python 3.7
03:09:17  <Flo> atleast now i should be able do most of it alone
03:09:26  <glx> it's hard to change version on mingw
03:09:35  <Flo> oh?
03:10:16  <Flo> i mean, ill prob have to reinstall the packages
03:10:45  <glx> but without the pacman -Syu steps
03:11:08  <Flo> wym?
03:11:34  *** tokai has joined #openttd
03:11:34  *** ChanServ sets mode: +v tokai
03:11:43  <glx> because pacman -Syu upgrades the package list
03:12:07  <glx> but you could also use current nml
03:12:19  <Flo> oh?
03:14:01  <Flo> ill get 3.7 python to start with, and try put all dependencies
03:14:15  <Flo> unless theres a way to do it in 3.8...
03:14:38  <glx> you can get it with "git clone"
03:16:29  <Flo> can it compile firs?
03:17:03  <glx> not yet, and I think it's a bug
03:17:10  <Flo> oh...
03:17:53  <Flo> it can be solved?
03:22:37  *** debdog has joined #openttd
03:23:50  *** supermop_work_ has quit IRC
03:25:57  *** D-HUND has quit IRC
03:29:00  *** supermop_work_ has joined #openttd
03:32:54  <glx> hmm will be easier to fix FIRS
03:33:34  <Flo> nice
03:34:05  <Flo> still trying to figure out how to install nml from that github
03:34:41  <glx> just git clone and "pip install ."
03:34:48  <Flo> oh
03:35:10  <glx> or better "pip install -e ."
03:37:57  <Flo> $ pip install -e ?
03:40:33  <glx> pip install git+
03:44:10  *** HerzogDeXtEr has quit IRC
03:45:18  <glx> hmm and that fails
03:47:04  <Flo> i installed the nml
03:49:44  <Flo> yeah, failed for me to...
03:49:57  <Flo> as you said, it does seems like a firs issue: nmlc ERROR: "generated/firs.nml", line 7342: Syntax error, unexpected token "waiting_cargo_1"
03:50:29  <glx> yes major change between nml 0.4 and 0.5
03:50:40  <Flo> right
03:50:56  <glx> but that's fixable in firs
03:51:01  *** Thedarkb-X40 has quit IRC
03:51:21  <Flo> yeah, seems more like a syntax thing...some rewriting could possibly fix that
03:51:40  <glx> just the doc is not fully updated ;)
03:51:51  <Flo> oof
03:52:04  <Flo> wait you updating the firs right now
03:52:05  <Flo> ?
03:52:26  <glx> no I'm not touching firs
03:52:44  <Flo> oh
03:52:49  <glx> in Industry properties section is updated
03:52:56  <Flo> oh
03:53:00  <Flo> a fixed version
03:53:12  <glx> but Industry variables is not
03:53:27  <Flo> sad
03:54:22  <Flo> if you manage to get a working firs, let me know :)
03:54:32  <glx> should help
03:59:14  *** supermop_work_ has quit IRC
04:02:09  *** supermop_work_ has joined #openttd
04:02:59  *** Wormnest_ has quit IRC
04:08:48  *** Smedles has quit IRC
04:25:37  *** snail_UES_ has quit IRC
04:31:26  *** Smedles has joined #openttd
04:32:20  *** supermop_work_ has quit IRC
04:33:09  *** supermop_work_ has joined #openttd
05:03:23  *** supermop_work_ has quit IRC
05:04:59  *** glx has quit IRC
05:08:27  *** supermop_work_ has joined #openttd
05:38:34  *** supermop_work_ has quit IRC
05:40:44  *** supermop_work_ has joined #openttd
05:58:37  *** Flo has quit IRC
06:10:57  *** supermop_work_ has quit IRC
06:17:20  *** supermop_work_ has joined #openttd
06:43:26  *** sla_ro|master has joined #openttd
06:47:33  *** supermop_work_ has quit IRC
06:51:19  *** supermop_work_ has joined #openttd
07:03:28  *** Progman has joined #openttd
07:15:05  *** andythenorth has joined #openttd
07:21:31  *** supermop_work_ has quit IRC
07:24:09  *** supermop_work_ has joined #openttd
07:55:21  *** supermop_work_ has quit IRC
08:01:37  *** supermop_work_ has joined #openttd
08:01:39  <andythenorth> hmm
08:01:48  <andythenorth> why is python import perfomance so poor?
08:01:56  <andythenorth> and what can I do about it ? :P
08:02:11  <andythenorth> is using modules wrong?
08:02:30  <andythenorth> I could just write everything in one python file
08:03:20  *** dude[m] has quit IRC
08:03:55  <Eddi|zuHause> andythenorth: it depends on loads of things, like what kinds of initialisations the module does
08:04:05  <Eddi|zuHause> or whether it needs to be converted to .pyc first
08:04:20  <andythenorth> it scales horribly
08:04:32  <andythenorth> there are some core modules that I import hundreds of times
08:04:46  <andythenorth> they're only 0.02s or such
08:04:55  <andythenorth> but they scale up to delays of seconds
08:05:12  <andythenorth> then I use a multiprocessing pool, and every pool instance scales that delay
08:05:13  <Eddi|zuHause> im sure there are import optimizers :)
08:05:29  <andythenorth> it's interestingly a new problem in 3.7 or 3.8
08:05:41  <andythenorth> 3.5 does not show this behaviour
08:05:55  <Eddi|zuHause> "pool instance" sounds like loads of initialisation code
08:06:05  <andythenorth> it is, and there's a known problem of overhead
08:07:39  <andythenorth> this file takes 0.2s to run (python src/
08:07:48  <andythenorth> or 1.1s to import (import iron_horse)
08:08:32  <andythenorth> at least one problem appears to be that chameleon's PageTemplateLoader class is incredibly slow to import
08:09:03  <andythenorth> so I'll find a way around that :P
08:09:09  <Eddi|zuHause> i don't think i can help you here
08:09:15  <andythenorth> no, this is my mess
08:09:25  <andythenorth> but the 3.5 vs 3.8 degradation was shocking
08:09:31  <andythenorth> it's probably because 3.8 is faster
08:09:59  <andythenorth> so something in the implementation has changed, and is no longer caching modules or similar
08:14:24  <Eddi|zuHause> likely a side effect of some other fix
08:15:42  <andythenorth> 3.8 is generally faster for the cases I have, about 10%-20%
08:17:05  <andythenorth> also I learn some things this way :P
08:17:08  <andythenorth> mostly regrets
08:17:45  <planetmaker> moin, is it possibly worth reporting that as regression back to python? With the example as-is?
08:20:11  <andythenorth> not in the current form
08:20:20  <andythenorth> I'm using terrible python practices, like no main()
08:20:53  <andythenorth> I'll find out if the regression is legitimate, or just my bad style, then see :)
08:21:08  <andythenorth> shall we place a bet on who is more likely wrong? :P
08:26:09  <andythenorth> 3.8 vs 3.5 is measurably faster for nmlc
08:28:29  <Eddi|zuHause> andythenorth: step 1: make two test environments with 3.5 and 3.8 )and possibly some inbetween versions) to test whether the slowdown is real
08:28:38  <andythenorth> done
08:28:45  <Eddi|zuHause> 2a) comment out code, until the difference disappears
08:28:47  <andythenorth> yes
08:29:16  <Eddi|zuHause> 2b) work through the changelog which changes would be likely to cause a slowdown
08:29:34  <andythenorth> that's not done yet :P
08:30:10  <andythenorth> I've fixed some self-inflicted problems, and now have parity for total run time between 3.5 and 3.8
08:30:25  <andythenorth> but as 3.8 is generally faster, that masks some things that are slower :)
08:31:24  <andythenorth> general observation, Iron Horse nmlc run time is about 28s for py3.8 vs 35s for py3.5
08:31:48  *** supermop_work_ has quit IRC
08:32:07  <andythenorth> oh if I let the caches prime, my total 3.8 run time is now a few seconds less than 3.5
08:32:07  <Eddi|zuHause> so 20% faster
08:32:13  <andythenorth> yes
08:33:10  <andythenorth> the remaining interesting problem
08:33:20  <andythenorth> is why a specific module takes 0.2s to just run
08:33:23  <andythenorth> and 1.1s to import
08:33:47  *** supermop_work_ has joined #openttd
08:34:01  *** arikover has joined #openttd
08:36:04  <andythenorth> hmm, that's same behaviour on 3.5 also, but after the first import, it's cached
08:36:18  <andythenorth> whereas 3.8 seems to incur the 1.1s every time the module is imported
08:41:13  <andythenorth> very interesting :P
08:41:19  <andythenorth> where's that xkcd on time saved? :P
08:52:35  <andythenorth>
08:53:07  <andythenorth> python3.5 doesn't trigger multiple imports when Pool is used, python3.8 does
08:53:47  <andythenorth> (I knew this already, I just added timings to verify it)
09:01:36  <planetmaker> at your service ;)
09:02:13  <andythenorth> thx
09:03:22  <andythenorth> ok found it
09:03:47  <andythenorth> python mp fork inherits from parent, mp spawn initialises clean
09:03:59  *** supermop_work_ has quit IRC
09:04:12  <andythenorth> fork is unreliable, changed on macos, consensus couldn't be achieved to change it on *nix for 3.8
09:04:30  <andythenorth> may be changed for *nix in 3.9
09:04:37  <andythenorth> super :)
09:05:27  *** supermop_work_ has joined #openttd
09:06:31  <andythenorth>
09:07:52  <planetmaker> I hoped you were joking :D
09:08:56  <andythenorth> joke multithreading not do about I
09:19:18  <peter1138> "I didn't test my PR."
09:20:12  <peter1138> Is that how other developers do things?
09:20:26  <andythenorth> somewhat
09:20:48  <andythenorth> on certain days I think OpenTTD is well above the average on quality
09:29:35  * andythenorth duty calls :P
09:29:36  *** andythenorth has quit IRC
09:35:39  *** supermop_work_ has quit IRC
09:38:52  *** nielsm has joined #openttd
09:40:49  *** supermop_work_ has joined #openttd
10:06:59  *** arikover has quit IRC
10:11:01  *** supermop_work_ has quit IRC
10:12:06  *** Samu has joined #openttd
10:19:28  *** supermop_work_ has joined #openttd
10:49:42  *** supermop_work_ has quit IRC
10:58:40  *** HerzogDeXtEr has joined #openttd
11:02:01  *** supermop_work_ has joined #openttd
11:32:11  *** supermop_work_ has quit IRC
11:33:33  <nielsm>   <-- why doesn't it print the (full path) name of the log file it fails to open?
11:33:38  <nielsm> that would make diagnostics easier
11:34:40  *** supermop_work_ has joined #openttd
11:37:14  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh closed issue #7848: Cannot scroll when building on Android
11:37:14  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7848: Cannot scroll when building on Android
11:42:36  *** freu[m] has quit IRC
11:44:43  *** nielsm has quit IRC
11:52:52  <Samu> I'm so tempted to buy this
11:53:04  <Samu> at that price
11:53:23  <Samu> but it's last gen :( and next year, new stuff is coming out
11:57:17  <Samu> with about €370 i can upgrade cpu, mb, ram and still add a 1 TB SSD
11:57:31  <Samu> and a tower
11:57:47  <Samu> so undecided
12:04:53  *** supermop_work_ has quit IRC
12:05:20  *** supermop_work_ has joined #openttd
12:35:33  *** supermop_work_ has quit IRC
12:35:34  *** Wolf01 has joined #openttd
12:39:32  *** andythenorth has joined #openttd
12:40:15  <andythenorth> well
12:41:13  *** supermop_work_ has joined #openttd
12:49:26  <andythenorth> so why am I tickling "[Errno 24] Too many open files"
12:51:37  <andythenorth> ulimit reports 'unlimited'
12:51:37  <Wolf01> Close a file handler when you finish to use it?
12:51:56  <andythenorth> yes, I wonder where it is though
12:52:12  <andythenorth> and why this triggers with pypy but not python3
12:53:05  <Wolf01> I think that "unlimited" is like "free! (with a 4.99€ purchase)" or "you get unlimited call time (up to 200 minutes/month)"
12:53:49  <Wolf01> Maybe it depends on other things, like OS, ram, whatever
12:54:24  <Wolf01> "
12:54:24  <Wolf01> "Too many open files" errors are always tricky – you not only have to twiddle with ulimit, but you also have to check system-wide limits and OSX-specifics"
12:55:26  <andythenorth> ulimit -n 4096 solves it
12:55:40  <andythenorth> but I wonder if I should be closing files
12:56:51  <Wolf01> ^
12:58:07  <andythenorth> well I wonder where, to be more accurate :P
13:00:15  <Wolf01> Just after you finished to write/read it
13:00:22  *** andythenorth has quit IRC
13:03:42  *** andythenorth has joined #openttd
13:10:28  *** nielsm has joined #openttd
13:11:27  *** supermop_work_ has quit IRC
13:13:19  *** supermop_work_ has joined #openttd
13:16:18  *** Progman has quit IRC
13:21:20  <supermop_Home> can an industry distribute cargo to only 2 stations, or is it 2 station per cargo?
13:22:49  <nielsm> two per cargo
13:23:28  <nielsm> when a cargo packet is about to be distributed it searches for all stations in catchment and sorts them by rating for that cargo, then picks the top two
13:23:52  <supermop_Home> ah ok
13:24:25  <supermop_Home> with cdist i usually keep two stations, one for far destination and one for near
13:25:04  <supermop_Home> but in this case i think i want separate trains taking the vehicles vs the engineering supplies
13:32:34  *** Flygon has quit IRC
13:42:20  * andythenorth closes some file handles :P
13:43:30  *** supermop_work_ has quit IRC
13:44:36  <andythenorth> hmm
13:44:43  <andythenorth> closing file handles seems to have made the compile faster :P
13:44:56  <Wolf01> Ahahaha
13:45:30  <andythenorth> not sure why that would be
13:46:12  <andythenorth> plenty of RAM :P
13:48:09  *** supermop_work_ has joined #openttd
13:48:36  *** HerzogDeXtEr has quit IRC
13:50:00  *** HerzogDeXtEr has joined #openttd
14:00:36  <andythenorth> oh lol
14:00:52  <andythenorth> the py3.8 syntax errors were me not nml
14:00:57  <andythenorth> but the file handles are nml :P
14:04:55  <supermop_Home> hmm this GS wants 'raw energy' once a town is bigger than 10k
14:05:19  <supermop_Home> but in steeltown that only means coal, which means a coke oven
14:05:30  <andythenorth> oof
14:05:31  <andythenorth> which GS?
14:06:09  <supermop_Home> and the only coal mine, oven, and steelmill are conveniently all near eachother in the far corner of the map
14:06:43  <supermop_Home> so setting up a new oven in the middle of my big city makes no sense
14:06:58  <supermop_Home> think globally act locally
14:07:00  <andythenorth> rage quit!
14:07:06  <andythenorth> only solution ^
14:08:26  <supermop_Home> nothing makes me want to move to a new city like huge trains of coal being hauled in to be baked in town, just to be carried back out to where they came from
14:08:44  <andythenorth> I am trying Migrations GS
14:08:57  <andythenorth> when you serve an industry, it spams a new town and houses round it
14:09:19  <andythenorth> neat concept, probably not going to be a keeper for me :)
14:09:26  <supermop_Home> oooh
14:09:27  <supermop_Home> cool
14:10:26  <supermop_Home> i accidentally started this steeltown game in tropic, so now im setting up complex systems to serve vehicles to all towns to let them grow
14:10:45  <supermop_Home> because all but one town spawned in the desert
14:14:29  <andythenorth> oops
14:18:22  *** supermop_work_ has quit IRC
14:23:31  *** supermop_work_ has joined #openttd
14:41:30  * andythenorth wonders what happens to an open Image file when copy is called on it :P
14:41:34  <andythenorth> do I also need to close the copy?
14:53:42  *** supermop_work_ has quit IRC
14:55:32  *** supermop_work_ has joined #openttd
14:59:25  *** Progman has joined #openttd
15:02:42  *** WormnestAndroid has quit IRC
15:02:55  *** WormnestAndroid has joined #openttd
15:09:34  <andythenorth> hmmm when things work...
15:25:45  *** supermop_work_ has quit IRC
15:27:37  *** supermop_work_ has joined #openttd
15:27:42  *** gandi[m] has quit IRC
15:31:13  *** snail_UES_ has joined #openttd
15:39:04  <andythenorth> ho ho
15:39:29  <andythenorth> Iron Horse compile is reliably ~10 seconds faster with python 3.8 compared to a week ago with python 3.5
15:39:56  <andythenorth> BUT some of the gain is due to me removing broken/slow things that worked under 3.5 and don't in 3.8 :P
15:41:10  <andythenorth> @calc 55/68
15:41:11  <DorpsGek> andythenorth: 0.808823529412
15:57:50  *** supermop_work_ has quit IRC
15:59:43  *** supermop_work_ has joined #openttd
16:25:58  <Samu> it's 1958 in the debug test, 3 years away from the crash
16:26:33  <Samu> enabling autosaves
16:29:11  <FLHerne> andythenorth: PyPy doesn't use reference-counted GC
16:29:53  <FLHerne> So file handles are only closed whenever the GC feels like it, whereas in CPython they're usually closed when leaving their scope
16:29:54  *** supermop_work_ has quit IRC
16:30:23  <FLHerne> (or, of course, when actually closing them like the spec says to :P)
16:30:25  <andythenorth> oic :)
16:30:31  <andythenorth> that makes sense
16:30:42  <andythenorth> nmlc might want to Image.close()
16:30:45  <andythenorth> I didn't look where
16:31:08  <andythenorth> it's possibly a cause of reported RAM bloat as well, but dunno
16:31:18  <andythenorth> not sure the 2 are connected?
16:34:12  *** supermop_work_ has joined #openttd
16:34:28  <FLHerne> Might well be
16:36:05  <Eddi|zuHause> i wouldn't count "GC can free it" under "bloat"
16:36:43  <Eddi|zuHause> however, "GC can't figure out that it can be freed" is different
16:38:09  *** Wormnest_ has joined #openttd
16:43:47  <andythenorth> I stopped testing with pypy, it's faster for some cases, but slower than others
16:49:00  <andythenorth> hmm overall faster with pypy though
16:55:10  <andythenorth> 48s vs 55s
16:57:31  <andythenorth> if I could switch py38 and pypy I could save another 8 seconds :P
16:57:58  <andythenorth> but 'source' to swtich virtualenv doesn't seem to work from a makefile
16:59:39  <Eddi|zuHause> i've no clue what you're saying
17:00:31  *** lastmikoi_ has joined #openttd
17:01:31  *** lastmikoi has quit IRC
17:01:31  *** lastmikoi_ is now known as lastmikoi
17:02:20  <andythenorth> some python interpreters are faster than others
17:02:29  <andythenorth> which one is fastest depends on the code being run
17:02:58  <andythenorth> the compile is made up of discrete steps
17:03:14  <andythenorth> I could switch to the fastest interpreter for each step
17:03:26  <andythenorth> but it's unwise, and I can't get it to trivially work anyway
17:04:11  <snail_UES_> andythenorth: I just read your past messages…  just curious, how long does it take to compile IH?
17:04:26  *** supermop_work_ has quit IRC
17:04:31  <andythenorth> roughly 1 minute
17:04:43  <andythenorth> it's very slow
17:05:00  <snail_UES_> right… my set with m4nfo is much quicker
17:05:25  <Eddi|zuHause> CETS spends 1 minute in grfcodec alone
17:06:19  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
17:06:40  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
17:07:00  <andythenorth> I did consider switching to m4nfo
17:07:00  <Eddi|zuHause> it's about 300k lines of NFO
17:07:23  <Eddi|zuHause> and grfcodec cannot be parallelized
17:07:54  <Eddi|zuHause> so while it's only 20% of the work, it's 50% of the time
17:08:05  <snail_UES_> mine just compiled in 28 seconds, including something like A5F recoloring tables
17:08:11  <snail_UES_> without those, it’d take like 10 secs
17:08:39  *** supermop_work_ has joined #openttd
17:08:40  <andythenorth> how long does it take you to generate the m4nfo?
17:09:07  <snail_UES_> you mean, within those 28 seconds?
17:09:10  <snail_UES_> let me see
17:09:55  <andythenorth> no, I mean to get the input file?
17:10:08  <andythenorth> or you wrote it all by hand?
17:10:39  <snail_UES_> I wrote my code by hand… well, with lots of copy and paste :p
17:10:50  <snail_UES_> but all of the logic is done by hand
17:11:33  <andythenorth> @calc 38/55
17:11:33  <DorpsGek> andythenorth: 0.690909090909
17:11:54  <andythenorth> ok so about 30% of the Horse compile is code generation, graphics generation, docs generation, overhead
17:12:01  <Eddi|zuHause> andythenorth: my takes 6 seconds
17:12:37  <andythenorth> you should have parellelised it :P
17:12:50  <andythenorth> use 16 processes, it would be done in 5 seconds
17:13:10  <snail_UES_> you mean you don’t write your nml code by hand? then how do you do it?
17:13:15  <LordAro> andythenorth: what bit of it is being parallelised?
17:13:55  <andythenorth> snail_UES_: I don't even know how to write nml :)
17:13:59  <andythenorth> I have to look it up every time
17:14:06  <Eddi|zuHause> andythenorth: how would you parallelize reading a giant table? from a single file? :p
17:14:08  <andythenorth> LordAro: just graphics generation
17:14:23  <andythenorth> Eddi|zuHause: divide it into 16 chunks :P
17:14:30  <andythenorth> map reduce
17:14:35  <andythenorth> the overhead will kill you :P
17:14:53  <snail_UES_> andythenorth: so how are you coding your set? :p
17:14:59  <andythenorth> python
17:15:14  <LordAro> personally i'd like make deal with parallelising for me
17:15:23  <LordAro> s/like/let/
17:15:32  <snail_UES_> you write in python, then python generates nml, and then from nml you compile the newgrf?
17:15:35  <andythenorth> yes
17:15:44  <snail_UES_> alright… sounds a bit convoluted to me :)
17:16:08  <andythenorth> I really don't like nml
17:16:21  <andythenorth> if I could template nfo, I would, but I'm not smart enough
17:16:41  <andythenorth> the nml is actually compiled to nfo
17:16:45  <andythenorth> then grfcodec is used
17:16:49  <snail_UES_> omg...
17:16:51  <andythenorth> it's faster
17:17:00  <snail_UES_> python —> nml —> nfo —> newgrf? :D
17:17:12  <Eddi|zuHause> snail_UES_: it probably is convoluted in andy's case, but if you have any kind of theoretical background it's pretty clean and straightforward to generate code.
17:17:39  <Eddi|zuHause> snail_UES_: basically, you write one vehicle, and it does all the copy-paste for you
17:18:02  <snail_UES_> yes, but each vehicle has its own quirks...
17:18:10  <andythenorth> that's why it gets convoluted
17:18:19  <andythenorth> and that's why Iron Horse vehicles are all pretty much the same
17:18:20  <snail_UES_> it’s rare that 2 vehicles are coded exactly the same in any trainset
17:20:07  <snail_UES_> right… well, if your trains are coded the same, it would be easy to create templates in nfo
17:20:21  <Eddi|zuHause> snail_UES_: there are ways out of that dilemma. like you can extend the system to handle all these tiny differences, or you can restrucure them to minimize the differences
17:20:50  <snail_UES_> Eddi|zuHause: yeah, like bringing some degree of standardization
17:20:58  <snail_UES_> I will totally do it for my next sets...
17:21:09  <snail_UES_> the narrow gauge one was my first, so I had crazy ideas
17:21:16  <andythenorth> I did that for HEQS :P
17:21:32  <andythenorth> Iron Horse is probably my 8th or 9th attempt at templating
17:21:56  *** gelignite has joined #openttd
17:22:02  <snail_UES_> templating helps, but then the result might lack variety...
17:22:17  <Eddi|zuHause> i found templates to be too restrictive
17:22:48  <Eddi|zuHause> that's where the code generation comes in, you have more ways to fit in the variations
17:22:53  <snail_UES_> you need to find a compromise between standardization and diversity
17:23:11  <andythenorth> there's a gameplay aspect as well
17:23:34  <Eddi|zuHause> code generation is essentially just fancy templates
17:23:35  <andythenorth> too much variation is bad for e.g. AIs, coop etc
17:23:44  <andythenorth> not enough variation is dull as hell
17:24:02  <snail_UES_> what do you mean by "coop"?
17:24:10  <andythenorth> coop style gameplay
17:24:20  <snail_UES_> in multiplayer?
17:24:36  <andythenorth> anywhere
17:24:47  <andythenorth> they like all trains to have same performance
17:25:02  <andythenorth> or so
17:25:08  <snail_UES_> all trains to have the same performance??
17:25:14  <snail_UES_> then just buy the same model :p
17:25:19  <nielsm> can any language lawyers give a quick opinion on this? :)
17:25:52  <andythenorth> it it tonne-miles?
17:26:07  <nielsm> yes
17:26:20  <andythenorth> many
17:26:22  <nielsm> ok
17:26:56  * andythenorth wonders whether to try and make Iron Horse compile faster
17:27:07  <LordAro> much vs many is the same as less vs fewer
17:27:44  <Eddi|zuHause> LordAro: the problem is, if your native language uses the same word for both cases
17:28:16  <LordAro> Eddi|zuHause: true :)
17:28:18  <Eddi|zuHause> ... then you might lack the ability to distinguish these cases
17:28:36  <andythenorth> nmlc is so much faster under pypy
17:28:47  <andythenorth> maybe I do need to switch interpreter in the makefile
17:28:58  <LordAro> uncountable vs countable - how much water, there is less water. how many people, there are fewer people
17:29:01  <LordAro> e.g.
17:30:04  <Eddi|zuHause> LordAro: that may seem logical to you...
17:30:10  <snail_UES_> LordAro: this might look a bit complicated to anyone who wasn’t born English ;)
17:30:35  <snail_UES_> even lots of native-born Americans have an incredible trouble with that
17:30:46  <LordAro> quite a lot of British people too :p
17:30:48  <andythenorth> lego or legos :P
17:30:48  <Eddi|zuHause> LordAro: it's like a japanese person confusing "r" and "l", or a french person randomly sprinking "h" into a word
17:31:19  <snail_UES_> what pisses me off is native-born speakers who confuse “it’s” with “its”
17:31:22  <snail_UES_> you see that all the time...
17:31:29  <andythenorth> I do that all the time :)
17:31:33  <snail_UES_> :p
17:31:34  <andythenorth> it's really hard to not get wrong
17:31:57  <LordAro> "[wsc]ould of" gets me
17:31:58  <nielsm> and classic their/they're/there
17:32:02  <nielsm> that too
17:32:03  <andythenorth> that's classic
17:32:06  <Eddi|zuHause> that's the reverse case, because in most foreign languages there is no way to confuse these two things
17:32:06  <snail_UES_> that too...
17:32:12  <LordAro> "off of" particularly gets me
17:32:15  <andythenorth> I know all the rules, but I still make the mistakes
17:32:17  <Eddi|zuHause> so non-native speakers are less likely to make that mistake
17:32:19  <andythenorth> the language is stupid
17:32:31  <andythenorth> but flexible
17:32:59  <Eddi|zuHause> what i never could wrap my head around was peopple using "of" instead of "have"... what?? why?
17:33:10  <andythenorth> nmlc run time Iron Horse: py38 39s; pypy 20s
17:33:16  <andythenorth> ^ substantial saving
17:33:53  <nielsm> heh, Aircraft::GetCurrentMaxSpeed() is not used anywhere at all
17:33:59  <andythenorth> :P
17:34:03  *** glx has joined #openttd
17:34:03  *** ChanServ sets mode: +v glx
17:34:10  <andythenorth> so how do I change virtualenv in a makefile :P
17:34:11  <nielsm> and the point of GetSpeedOldUnits() is not explained anywhere as far as I can tell
17:34:12  * andythenorth wonderw
17:34:29  <LordAro> andythenorth: you really don't
17:34:58  <LordAro> Eddi|zuHause: probably due to contractions - "should've" -> "should of"
17:35:49  <andythenorth> LordAro: the speed though :P
17:35:55  <nielsm> "shuddef"
17:36:30  <LordAro> andythenorth: sure, but switching dev environments from within a makefile? ew ew ew
17:36:40  <Eddi|zuHause> andythenorth: excuse my ignorance, but the point of a virtualenv is that the program being run doesn't know about it?
17:36:47  <andythenorth> it's just an interpreter LordAro
17:36:58  <andythenorth> I used to have a mixed python3 / python2.7 compile :P
17:36:59  <LordAro> i'm guessing nml itself can't cope with pypy?
17:37:14  <andythenorth> Eddi|zuHause: somewhat yes
17:37:38  <LordAro> then call pypy as "pypy" ? why is the virtualenv a factor?
17:38:15  <nielsm> aircraft movement speed is deep magic
17:38:15  <andythenorth> I don't use system-wide python
17:38:21  <andythenorth> it's very fragile
17:38:28  <LordAro> sure, but your build system doesn't need to know that
17:38:36  <andythenorth> Makefile.local maybe
17:38:40  <LordAro> virtualenv sets up your environment
17:38:40  <Eddi|zuHause> yeah, i don't understand what the virtualenv has to do with it. you need a virtualenv with both interpreters in it
17:38:47  <nielsm> the virtualenv should have the python version used encoded in it
17:38:47  <LordAro> make runs in that environment
17:38:48  <LordAro> end of
17:38:52  *** supermop_work_ has quit IRC
17:39:00  <Eddi|zuHause> and then just call the interpreter in the makefile
17:39:10  <nielsm> by having an appropriate symlink from the venv's bin directory to the intended interpreter
17:39:19  <andythenorth> what nielsm said
17:39:45  <Eddi|zuHause> one virtualenv, two interpreters.
17:39:50  <andythenorth> that's not how it's done
17:40:01  <Eddi|zuHause> but that's the only way to do it
17:40:03  <andythenorth> that's just a particularly inventive way to break things
17:40:26  <nielsm> this is one good line: v->subspeed = (t = v->subspeed) + (byte)spd;
17:40:29  *** supermop_work_ has joined #openttd
17:40:41  <andythenorth> actually one virtualenv, two interpreters might be the best way to break things so far :)
17:40:44  <andythenorth> it's so subtle
17:40:52  <andythenorth> it would take ages to figure it out :)
17:41:20  <Eddi|zuHause> nielsm: if i were to work in QA, i'd immeddiately ban = in expressions
17:41:40  <Eddi|zuHause> nielsm: so many ways for it to go wrong
17:42:02  <LordAro> there are certain cases where it's acceptable
17:42:08  <Eddi|zuHause> and "t = subspeed; subspeed += spd" isn't even any longer
17:42:08  <LordAro> but those are vanishingly rare
17:42:36  <LordAro> e.g. while((foo = read())) {...}
17:42:51  <Eddi|zuHause> LordAro: iterator.
17:43:16  <Eddi|zuHause> LordAro: that's a for-loop
17:43:19  <nielsm> static void MaybeCrashAirplane(Aircraft *v);
17:43:22  <nielsm> yeah
17:45:06  <Eddi|zuHause> nielsm: there's a good chance you can trace these kinds of expressions back to the original decompile
17:45:12  <glx> andythenorth: you can have many venv, but you can have only one enabled per session
17:45:34  <andythenorth> yes
17:45:38  <andythenorth> one has to switch
17:45:49  <glx> that's the main use of venv
17:45:51  <andythenorth> yes
17:46:00  <andythenorth> doing that in the Makefile might be considered unwise :P
17:46:22  <glx> Makefile doesn't have to know about venv
17:46:32  <glx> it's the responsability of the user
17:46:54  <andythenorth> rock, hard place
17:47:03  <andythenorth> that game-overs switching interpreter
17:47:06  <Eddi|zuHause> Makefile MUST NOT know about virtualenv
17:47:41  <andythenorth> we have a work Makefile that actually creates virtualenvs
17:47:52  <Eddi|zuHause> that's different
17:47:53  <andythenorth> but it's for creating a build environment, not for the compile
17:48:11  <Eddi|zuHause> that makefile lives on a meta-environment
17:48:13  <andythenorth> yes
17:48:24  <glx> projects themself don't care
17:48:35  <nielsm> @todo    De-mystify the cur_speed values for helicopter rotors.  <- yeah that too
17:49:06  <andythenorth> well I could just install all the deps in system-wide pypy
17:49:19  <glx> you can use --user
17:49:19  <andythenorth> but I hate system-wide python installs, they break at no-notice
17:49:41  <glx> or use venv from the global install
17:50:25  <glx> on windows I can't install modules system wide if not in an admin shell
17:50:33  <Eddi|zuHause> i stand by my opinion that the only way to do what you want is to have both interpreters in the same virtualenv
17:50:45  <glx> but pip supports that easily
17:51:01  <andythenorth> Eddi|zuHause: that might work because pypy is tracking py3
17:51:06  <andythenorth> but it's very prone to breaking
17:51:26  <andythenorth> which package should be installed in the env for which interpreter?
17:51:38  <andythenorth> it defeats the point of the env
17:51:39  <glx> pip takes care of that
17:52:07  <andythenorth> are there interpreter-specific packages?
17:52:13  <glx> venv/bin is put in front of the path
17:52:24  <andythenorth> I'm confused now
17:52:59  <glx> so if you use python2 -m pip you install for python2, and python3 -m pip to install python3
17:53:54  <andythenorth> well I could try it
17:54:03  <andythenorth> I can always just delete the env if it breaks
17:54:36  <glx> venv/bin/pip on the other hand will use the latest interpreter added to the venv
17:55:33  * andythenorth looks what's in bin/activate
17:55:48  <glx> bin/activate just adds the path IIRC
17:55:59  <glx> basically
17:56:41  <andythenorth> so with two interpreters, I'm curious how it will know which one to activate
17:58:24  <glx> anyway it's probably easier to just do python2 -m venv venv2 and python3 -m venv venv3
17:59:01  <andythenorth> that results in 2 venvs though
17:59:13  <glx> but only one used at a time
17:59:21  <andythenorth> hmm
17:59:25  * andythenorth still confused
17:59:50  <andythenorth> the only solution seems to be system-wide install
18:00:06  <andythenorth> not doing that
18:02:32  <Samu> {type=VKI_STATION (0) id={station=1746 town=1746 sign=1746 } center=-48128 ...}
18:02:36  <andythenorth> is there a convention for naming pypy?
18:02:49  <Samu> the id being equal to station, town and sign, is that the way it works?
18:03:18  <andythenorth> probably the makefile needs to test if pypy exists?
18:06:40  <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE
18:07:45  <nielsm> Samu: the id there is a union, not a struct, so it's only the id for the appropriate item type
18:08:19  <nielsm> (it's not a StationID, TownID, SignID all at the same time, only the one type given by VKI_STATION/etc.)
18:08:24  <Samu> btw, it also crashed on master version
18:08:41  <Samu> ah, i see
18:08:48  <glx> of course, 1.10 is master ;)
18:09:24  <glx> not the more recent master, but still master
18:09:41  <Samu> master-gd865916a07
18:09:58  <glx> and no changes happened in this area since beta release
18:10:47  *** supermop_work_ has quit IRC
18:10:57  <glx> still no fast way to reproduce ?
18:11:12  <andythenorth> hmm maybe I can rewrite to be faster for pypy
18:11:14  <Samu> _viewport_sign_kdtree.Remove(ViewportSignKdtreeItem::MakeStation(this->index));
18:11:19  <andythenorth> seems that it needs code written for it
18:11:34  <andythenorth> or I could maybe switch template language
18:11:38  <Samu> it enters this part, and tries to find something, and reaches invalid_node
18:11:47  <glx> Samu: yes I know where the crash is, I posted the log in the issue ;)
18:12:27  <glx> at some point it takes the wrong branch of the tree I think
18:12:38  *** supermop_work_ has joined #openttd
18:13:05  <glx> now the question is why ?
18:13:48  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:14:19  <Samu> is there anything I can do to brute force a search?
18:14:27  <Samu> branch stuff
18:15:13  <andythenorth> hmm
18:15:14  <andythenorth> FIRS
18:15:34  <Samu> or maybe a failsafe when it fails to find, have it make some slower search
18:15:37  <andythenorth> py35: 59s; py38: 47s; pypy: 31s
18:15:56  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:16:11  <glx> FIRS (at least the one on github) needs a big update for current nmlc
18:16:24  <andythenorth> there's a branch
18:16:29  <andythenorth> v4-development or something
18:16:43  <andythenorth> main reason I switched it to git :)
18:16:53  <glx> luckily as you did it only one file needs changes ;)
18:17:17  <andythenorth> has something else changed? :P
18:20:32  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:22:03  <glx> ha yes v4-development-track compiles
18:22:16  <glx> I forgot to check branches last night
18:22:35  <andythenorth> I wonder if FIRS is suitable for stored procedures :P
18:23:09  <andythenorth> there are some truly horrible things for drawing the correct ground tile: snow, slope etc
18:23:15  <andythenorth> they are endlessly repetitive
18:23:18  <glx> it is if switches are based on the same calculations
18:23:42  <andythenorth> I am hoping that stored procedures might work for Iron Horse
18:23:58  <andythenorth> optimistically, I might remove 20k lines of 170k total
18:25:01  <andythenorth> FIRS :P
18:25:14  <andythenorth> I don't know if childsprite can use a stored procedure result
18:27:22  <andythenorth> that would be a trip deep into nml :P
18:27:25  <andythenorth>
18:27:43  <andythenorth> there's also an advanced format using registers :P
18:29:44  <andythenorth> this check is super, I wonder what it expands to in the final varaction 2 :P
18:32:35  <glx> I think childsprite can use a stored procedure result
18:32:59  <glx> I guesse the stuff is converted to a varact2 by nmlc
18:33:34  <andythenorth> maybe nml could consolidate them for me :P
18:34:06  <glx> it should be possible to use [STORE_TEMP(), procedure()]
18:34:54  <glx> and in the procedure you use LOAD_TEMP() to get the parameter
18:35:24  <andythenorth> :)
18:36:18  * andythenorth wonders how compilers optimise
18:37:15  <andythenorth> this expression is all keywords
18:37:20  <andythenorth> (climate != CLIMATE_TROPIC) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_DESERT)) || ((climate == CLIMATE_TROPIC) && (nearby_tile_terrain_type(0, 0) == TILETYPE_NORMAL) && ((nearby_tile_terrain_type( 1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type(-1, 0) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0, 1) != TILETYPE_DESERT) && (nearby_tile_terrain_type( 0,-1) !=
18:37:20  <andythenorth> TILETYPE_DESERT) ) )
18:37:26  <glx> and we could probably add something like function name(args..) { return <calculation>; } to let nmlc generate the varact2
18:37:31  <andythenorth> so presumably all instances of it could be resolved to one instance
18:37:36  <andythenorth> automatically :P
18:37:56  <andythenorth> do compilers construct tables of recurring patterns?
18:38:14  <glx> I don't think nmlc does :)
18:39:34  <andythenorth> :)
18:40:27  <Samu> it exists
18:40:40  <Samu> +		[2595]	{element={type=VKI_STATION (0) id={station=1746 town=1746 sign=1746 } center=-48128 ...} left=2597 right=...}	Kdtree<ViewportSignKdtreeItem,int (__cdecl*)(ViewportSignKdtreeItem const &,int),int,int>::node
18:40:49  <Samu> it's in the list of nodes
18:40:55  <Samu> it just fails to find it
18:41:24  <nielsm> does the cached position match the expected?
18:41:40  <nielsm> (cached position = the position stored in the tree)
18:42:02  <Samu> center, left and right?
18:42:05  <nielsm> yes
18:42:16  <Samu> not sure how to check, but let me try
18:42:51  *** supermop_work_ has quit IRC
18:44:00  <Samu>
18:44:29  *** supermop_work_ has joined #openttd
18:44:53  <Samu> nop, doesn't seem to match
18:45:07  <Samu> sec, i take another screenshot
18:45:18  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:46:09  <Samu>
18:46:16  <Samu> 2 screenshots
18:46:52  <Samu> the top for one is 43872, the top for the other is 43904
18:46:59  <Samu> they should have the same value, right?
18:47:09  <glx> I think I know what happened
18:47:35  <glx> dock removed, land raised, sign moved
18:47:44  <nielsm> ah yeah
18:48:06  <nielsm> so changing land height below a ghost station sign can trigger bugs
18:48:08  <nielsm> ugh
18:48:53  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh updated pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:48:59  <glx> let see if I can reproduce using these simple steps
18:49:06  <Samu> land lowered, it seems
18:49:35  <glx> whatever the sign moved
18:49:41  <andythenorth> maybe I can speed up PIL :P
18:50:06  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on pull request #7353: Feature: Measure vehicle capacity utilisation efficiency
18:50:40  <glx> it's annoying to not be able the batch replies to reviews ;)
19:11:13  <peter1138> Yeah
19:11:38  *** snail_UES_ has quit IRC
19:12:41  <nielsm> glx: you can if you go to the Files Changed tab first
19:14:43  *** supermop_work_ has quit IRC
19:20:06  *** supermop_work_ has joined #openttd
19:43:31  <glx> and write a new review ?
19:44:21  <Samu> i can't reproduce the crash glx
19:44:39  <Samu> raised land, lowered land, nothing seems to make it crash
19:50:19  *** supermop_work_ has quit IRC
19:51:31  *** supermop_work_ has joined #openttd
20:04:25  <Samu> strange, when I load an autosave from a month earlier
20:04:46  <Samu> i get top = 43904, and it's now node 171, instead of 2595
20:05:07  <nielsm> is the station already demolished at that time?
20:05:11  <Samu> yes
20:05:17  <nielsm> yeah
20:05:22  <glx> node changes when something is added removed, ignore the nod ;)
20:05:29  <nielsm> the tree is recalculated when the save is loaded
20:05:30  <glx> *node index
20:05:51  <Samu> so, gonna try load when the station is not yet demolished
20:06:06  <nielsm> so if you save and reload while the tree is in an inconsistent state, the state will be rebuilt to be consistent
20:06:13  <glx> the main issue is to find why the sign "moved"
20:06:49  <glx> or how we can move it without updating the tree
20:10:59  <Samu> top = 43872 with the station yet built
20:11:42  <Samu> if i delete the station, will i get the crash now?
20:11:43  <nielsm> how does the map look with the station in place?
20:11:59  <nielsm> compared to how it looks after it was deleted
20:12:10  <nielsm> sorry, demolished not deleted
20:12:48  <Samu> looks like this
20:13:42  <nielsm> so the AI demolishes the dock and also lower the land piece it sits on
20:13:59  <Samu> yes, but he's not demolishing now :(
20:14:18  <Samu> ais after load tend to do different than a straight run
20:14:41  <nielsm> yes they use the interactive random, not a game state random
20:21:42  *** supermop_work_ has quit IRC
20:24:56  *** supermop_work_ has joined #openttd
20:26:20  <Samu> yay, i think i found a more reproducible way to crash it
20:26:41  <Samu> gonna try again to confirm
20:29:02  <Samu> yes! it crashed
20:29:03  <Samu> gonna post
20:31:55  <DorpsGek_III> [OpenTTD/OpenTTD] SamuXarick commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE
20:34:23  <Samu> in autosave11 the top value is different than that in autosave12, because the dock still exists in 11, but not in 12
20:34:57  <Samu> if i load the autosave12 it won't crash
20:36:23  <Samu> do you want autosave12?
20:37:08  <nielsm> I wonder what the trigger for the sign moving it though
20:37:43  <Samu> if you don't lower the land after demolishing the docks, autosave11 won't crash either
20:37:50  <Samu> so it's something related to lowering land
20:38:07  * andythenorth wonders if grfcodec could be faster
20:38:08  <nielsm> normally ghost station signs don't move after modifying the land below them
20:38:28  <glx> the sign moves when the dock is removed but doesn't cause crash
20:39:37  <glx> and it moves because content changes
20:41:40  <glx> waiting for the sign to disappear at 7fps takes time :)
20:41:52  <nielsm> yeah...
20:41:57  <nielsm> but I reproduce it too with that save
20:42:11  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE
20:43:20  *** snail_UES_ has joined #openttd
20:48:04  <andythenorth> hmm
20:48:14  <andythenorth> I need to save 5s on generating the nml
20:49:20  <andythenorth> the overhead of starting the template engine is 1s
20:49:37  <andythenorth> so I don't think parallelising will help :(
20:55:09  *** supermop_work_ has quit IRC
20:57:33  <nielsm> okay the bug seems to occur already in demolishing the station
20:57:39  <nielsm> lowering the land is not required
20:58:44  *** supermop_work_ has joined #openttd
21:04:17  <glx> I tried building something similar but that doesn't trigger
21:04:32  <nielsm> yeah it depends on the rest of the map and signs
21:05:03  <nielsm> it has to be sufficiently large and positioned "correctly" so the station sign that moves ends up in a different position in the tree
21:05:24  <glx> ah yes it's the only station I have when I try
21:05:33  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE
21:09:53  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh commented on issue #7847: Crash - Assertion failed at line 213 of src\core\kdtree.hpp: next != INVALID_NODE
21:11:20  <nielsm> if you want to trace it, breakpoint in ClearTile_Station() and follow it into RemoveDock()
21:12:12  <nielsm> and stuff happens with the st->rect.AfterRemoveTile() until st->AfterStationTileSetChange() calls
21:15:11  <nielsm> the reason the sign moves is not because it gets moved, or the tile height changes, but because the way the tile z coordinate is calculated changes when the tile changes from a station tile to a clear tile
21:16:05  <glx> because it's a slope
21:16:49  <nielsm> yeah
21:26:56  <andythenorth> oof can't commit this to a public repo eh :D
21:26:58  <andythenorth> ../../pypy3/bin/nmlc -l generated/lang  --verbosity=4 --nfo=generated/iron-horse.nfo generated/iron-horse.nml
21:27:42  <glx> hardcoded path to an exe ?
21:27:50  <andythenorth> :(
21:28:09  <andythenorth> 39s vs 55s
21:28:58  *** supermop_work_ has quit IRC
21:30:48  *** supermop_work_ has joined #openttd
21:36:53  <andythenorth> Makefile.local and gitignore it? :P
21:43:56  <andythenorth> that seems to work fine
21:44:20  <andythenorth> @calc 39/68
21:44:20  <DorpsGek> andythenorth: 0.573529411765
21:44:28  <andythenorth> not a bad speed up
21:44:37  <andythenorth> overall
21:56:04  <Samu> Point pt = RemapCoords2(TileX(this->xy) * TILE_SIZE, TileY(this->xy) * TILE_SIZE);
21:56:16  <Samu> Point pt = RemapCoords(TileX(st->xy) * TILE_SIZE, TileY(st->xy) * TILE_SIZE, GetTileMaxZ(st->xy) * TILE_HEIGHT);
21:56:27  <Samu> could this be the issue?
21:56:51  <nielsm> no
21:56:56  <nielsm> I'm fixing that too, but it isn't
21:57:00  <nielsm> I know exactly what's going wrong
21:57:02  <Samu> oh, cool
21:57:04  <nielsm> and it's annoying to fix
21:58:01  <glx> I think it could be done in ViewportSign::UpdatePosition()
21:58:10  <supermop_Home> andythenorth: why do sliding wagons cost more than curtain sided?
21:58:25  <nielsm> glx yes and no
21:59:54  <glx> but it first needs to check it's already in the tree before maybe remove
22:01:01  *** supermop_work_ has quit IRC
22:03:38  <andythenorth> supermop_Home: not sure :D cost in code is the same for both
22:05:07  <supermop_Home> i mean at this point i can afford the sliding side wagon, running cost is the same
22:05:26  <supermop_Home> i figure it might look better for shipping vehicles
22:06:33  *** supermop_work_ has joined #openttd
22:08:09  <supermop_Home> its like 27 vs 51 for the large wagon
22:10:33  <andythenorth> mine all cost same :)
22:11:09  <andythenorth> oh the tarp wagon is cheaper
22:12:15  <supermop_Home> well the metal sided looks more like a car carrier
22:12:31  <supermop_Home> so im paying the premium for it
22:13:58  <andythenorth> I should finish the vehicle wagons :P
22:14:01  *** snail_UES_ has quit IRC
22:14:17  <andythenorth>
22:14:39  <nielsm> glx no doesn't fix it, I suspected that
22:15:06  <supermop_Home> if im dropping a town effect cargo off on the outskirts of town (at a black hole industry) does the TE go to the town with the station name, or closest by mht distance?
22:15:13  <nielsm> thing is the expected position of the sign changes behind the station code when the tile is modified after it stops being a station tile
22:16:07  <nielsm> really ViewportSignKdtreeItem::MakeStation() ought to use and .center for the position
22:16:18  <nielsm> but those aren't always valid when it gets called first, I think
22:18:41  <glx> ah yes ViewportSign::UpdatePosition() can't know the object containing it
22:21:06  <nielsm> I think I need to make a StationViewportSign inheriting ViewportSign and keeping track of its kdtree state
22:35:57  <supermop_Home> how many tiles away until luxury passenger car makes sense?
22:37:15  *** supermop_work_ has quit IRC
22:38:28  <nielsm> depends on train speed too I think
22:39:06  <nielsm> since the effect of luxury passenger cars is to make the trip "feel shorter"
22:39:39  <nielsm> if it's sufficiently long (too slow) then you'll hit the max cap I think exists
22:39:51  <supermop_Home> 185 kph… still haven't figured out all the livery easter eggs in IH
22:41:27  <andythenorth> in tests it's about 64 tiles or so
22:42:05  <andythenorth> the luxury pax cars actually do ~nothing
22:42:16  <andythenorth> the standard pax cars have to have a nerf
22:42:38  <supermop_Home> luxury in HST?
22:42:44  <andythenorth> the decay rate modifier is mostly useless
22:43:15  <supermop_Home> these are just 4 tile push-pulls with a fury on the back
22:43:24  <supermop_Home> and mail emu up front
22:43:35  <supermop_Home> look nice
22:44:54  <andythenorth> :)
22:46:39  *** supermop_work_ has joined #openttd
22:49:14  *** Progman has quit IRC
23:03:13  <DorpsGek_III> [OpenTTD/OpenTTD] nielsmh opened pull request #7849: Fix #7847: Use ViewportSign coordinates for sign Kdtree coordinates for stations
23:03:51  <nielsm> Samu: test that :)
23:13:42  <Samu> ok
23:15:55  <Samu> uhm, i forgot what was the command
23:16:03  <Samu> glx, to create a PR
23:16:13  <glx> git pr <number>
23:16:24  <glx> easy to remember :)
23:16:52  *** supermop_work_ has quit IRC
23:21:07  <Samu> waiting for sign to disappear
23:21:25  <Samu> is this the right way to test? load the savegame with the station?
23:21:34  <nielsm> yes
23:21:41  <Samu> remove it, and lower terrain
23:21:42  <Samu> ok
23:21:47  <nielsm> also it helped me to test by getting rid of all installed AIs
23:23:53  <Samu> yep, sign poof, no crash
23:24:00  <glx> code looks good and simplifies a lot of corner cases
23:24:19  *** supermop_work_ has joined #openttd
23:25:26  <Samu> gonna try restarting the world
23:25:34  <Samu> see if it passes 1961
23:25:42  <Samu> starting at 1935
23:25:47  *** Progman has joined #openttd
23:27:30  *** snail_UES_ has joined #openttd
23:27:41  <nielsm> glx: indeed after getting the idea it's quite a "why didn't I do that from the beginning" moment
23:27:55  <glx> I know the feeling
23:29:23  <Samu> i should be in bed, they don't let me stay up this late
23:30:05  <glx> then go to be, you can test tomorrow :)
23:30:12  <glx> *bed
23:30:30  <Samu> ok, take care
23:32:29  <Samu> 1940, come on, faster!!
23:32:35  *** Wolf01 has quit IRC
23:33:35  <Samu> meh, better go
23:33:37  <Samu> bye
23:36:12  <DorpsGek_III> [OpenTTD/nml] glx22 opened pull request #67: Minor changes in regression Makefile and .gitignore
23:38:02  <nielsm> and me too, gn
23:38:30  <andythenorth> bed
23:38:31  *** andythenorth has left #openttd
23:41:42  *** Samu has quit IRC
23:46:16  *** nielsm has quit IRC
23:51:03  <DorpsGek_III> [OpenTTD/nml] glx22 updated pull request #67: Minor changes in regression Makefile and .gitignore
23:54:32  *** supermop_work_ has quit IRC
23:55:26  *** supermop_work_ has joined #openttd

Powered by YARRSTE version: svn-trunk