IRC logs for #openttd on OFTC at 2014-07-13
⏴ go to previous day
02:30:52 *** HerzogDeXtEr has joined #openttd
02:42:02 *** Myhorta has joined #openttd
03:50:47 *** KWKdesign has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
05:55:34 *** andythenorth has joined #openttd
06:48:02 <andythenorth> can I tell grfcodec to shut up about loading sprites?
06:48:37 <andythenorth> -s or -q don’t seem to do that
06:52:48 <andythenorth> oh, -s works, it just revealed the large number of warnings that I missed before :)
06:58:00 *** Progman has joined #openttd
07:01:31 *** theholyduck has joined #openttd
07:05:53 <andythenorth> nforenum --silent -w=+ generated/iron-horse.nfo
07:06:01 <andythenorth> should silence nforenum warnings?
07:13:26 <planetmaker> andythenorth, you're right, seems that nml didn't update itself properly on CF. I'll investigate
07:29:19 *** Pensacola has joined #openttd
07:29:43 <planetmaker> thought so, andy :)
07:34:17 <planetmaker> CF now has (again) nml tip. And should keep updating it properly, too
07:34:41 <planetmaker> 09:34:15 iron-horse:1: Warning: Found 13879 more sprites than sprite 0 reports. :P
07:35:45 <planetmaker> iron-horse built successfully
07:36:51 <andythenorth> planetmaker: I’m fixing the sprite warning :)
08:00:41 <andythenorth> can’t get nforenum to shut up
08:01:02 <andythenorth> dumping the stdout is a bit tricky because I’m calling nforenum from python
08:05:11 *** Pensacola has joined #openttd
08:07:37 <andythenorth> planetmaker: so that’s a working partial compile
08:07:52 <andythenorth> no nml patch needed
08:08:09 <andythenorth> I did bad things to the makefile, might need adjusted
08:29:58 *** Myhorta has joined #openttd
08:30:19 <andythenorth> this can’t be a good idea
08:30:20 <andythenorth> self.vehicle_module_path = inspect.stack()[2][1]
08:30:23 <andythenorth> why am I doing that?
08:31:36 <SpComb> andythenorth: you are forbidden from writing any more python code until you remove that
08:32:05 <andythenorth> “what could go wrong?”
08:48:30 *** tokai|mdlx has joined #openttd
09:30:33 *** Alberth has joined #openttd
09:30:33 *** ChanServ sets mode: +o Alberth
09:37:45 <andythenorth> self.vehicle_module_path = inspect.stack()[2][1]
09:37:59 <andythenorth> maybe I can just store the module __name__ in the objects that it creates?
09:43:13 <andythenorth> but __name__ can be changed
09:49:08 <Alberth> doing python magic eh? :)
09:50:27 <andythenorth> just writing a dep check
09:51:05 <andythenorth> I have vehicles (box_car_1, box_car_2 etc) generated from modules (box_cars.py etc)
09:51:32 <andythenorth> I just want the module name to check if the vehicles need re-generated
09:52:09 <Alberth> generate the name along with the vehicle?
09:52:22 <andythenorth> looks like the best route
09:53:45 <Alberth> although I am not sure why you differentiate between vehicles here
09:54:01 <Alberth> you have to regenerate all of them anyway, so why not keep them together
09:54:34 <andythenorth> that is a good question
09:55:26 <andythenorth> hmm Stack Overflow keeps telling me to use inspect.stack for this
09:55:33 <andythenorth> it seems to be the preferred answer
09:55:47 <andythenorth> surely that’s wrong :(
09:56:10 <Alberth> it tells you you shouldn't want it :)
09:57:09 <Alberth> kind of like the advice of some ubuntu forum: I am bothered with having python2 installed. Oh, that's easy to solve: rm /usr/bin/python :P
09:58:00 <andythenorth> I could rebuild the project so that [vehicle].nfo matches [generating_module].py
09:58:16 <andythenorth> but it seems a bit odd to rebuild that much just to get a dep check
09:58:41 <andythenorth> now I am confused
09:58:50 <andythenorth> apparently I can’t use __file__ safely
09:58:54 <andythenorth> and should also use inspect there
09:59:09 <Alberth> generate the dependencies from the .py too?
10:01:21 <andythenorth> I think I’m just going to pass __file__ in the args to the vehicle constructor
10:01:28 <andythenorth> then I can find out what goes wrong
10:01:30 <andythenorth> probably nothing
10:01:50 <Alberth> I never think about making those :)
10:03:19 <andythenorth> now I just have weight multiplier set to 1
10:03:28 <andythenorth> 12 tiles, straight up or down
10:04:01 <andythenorth> especially pipelines :P
10:04:39 <Alberth> especially early in the game that won't work with cargo from primary industry
10:05:00 <Alberth> going uphill @ 2km/h :p
10:05:22 *** EyeMWing has joined #openttd
10:05:30 <Alberth> yeah, it's great to have 2 steam engines in a train
10:08:36 <Alberth> yetis have been released into the world?
10:09:22 * andythenorth leaves the inspect.stack thing alone
10:12:38 <andythenorth> if it’s not broken, don’t make lots of work fixing it
10:14:09 <Alberth> it's called "making it future proof" :)
10:16:19 <andythenorth> I’ll just wait for the future to turn up
10:18:30 <andythenorth> it will be here soon
10:19:33 * Alberth checks the future weather
10:33:34 <Rubidium> Alberth: first a generally gradual increase in temperature (for about 2e18s), after that a gradual decrease in temperature and after that it's not really certain. Either it gets warmer again or the temperature keeps decreasing
10:37:21 <andythenorth> json is the antidote to horrible string splits
10:38:23 <Alberth> Rb: that's a pretty long time, I may not live that long
10:39:34 <Rubidium> Alberth: problem is that short term forecasts are more often very wrong ;)
10:40:26 <Alberth> depends on how serious you take them ;)
10:44:36 *** Myhorta[1] has joined #openttd
11:05:01 *** frosch123 has joined #openttd
11:25:00 <kero> Mmh. I tried to upgrade to nml-0.4, using python 3, but I can't manage to build FIRS anymore. Should I avoid ?
11:34:55 <Alberth> ie in what way can you not build firs
11:35:29 <Alberth> maybe you're using python3 for the firs python scripts?
11:38:12 <kero> Yes, i think it's the problem. The Firs scripts still uses python 2, and nml now uses python 3.
11:38:45 <kero> But I wouldnt know how to tell only to the Firs scripts to use python 2
11:39:22 <Alberth> using a Makefile, I assume?
11:39:36 <kero> Until know I had to use a bad hack: rm /usr/bin/python && ln -s /usr/bin/python2 /usr/bin/python
11:40:56 <kero> Obviously I revert the original symlink when done.
11:41:07 <Alberth> /usr/bin/python should be python2, in general
11:42:41 <Alberth> In the FIRS makefile, at line 117, it says PYTHON ?= python
11:42:53 <Alberth> make that PYTHON ?= /usr/bin/python2
11:42:57 <kero> so I change that to python2 ?
11:44:27 <Alberth> assuming you don't install things manually, I'd advice to never touch anything /usr
11:45:28 <Alberth> package managers and other applications get hopelessly confused if files go missing or don't are what they are supposed to be
11:46:18 <Alberth> unix is a true multi-user system, which means you can change things for you personally, without touching system files
11:47:08 <Alberth> ie at a unix system with more than 1 user, you typically don't want random users to mess up things everybody depends on :)
11:48:44 <kero> I didn't like to do that horrible hack. It was really that after hours of searching, I couldn't figure out another way.
11:49:03 <kero> and by the way, changing the Makefile doesn't work :/
11:50:23 <kero> (with the changed Makefile)
11:51:58 <Alberth> Makefile.in has a broken command: $(_V) python scripts/preprocess.py '${REPO_TITLE}' '${REPO_REVISION}' '${TEST_INDUSTRY}'
11:52:09 <kero> The feeling I had the last time, is that some parts of the scripts don't use the Makefile directive (ie: they use the default python3)
11:52:15 <Alberth> that should be $(PYTHON)
11:53:36 <Alberth> Makefile has been edited by several users with different ideas how to do things and different levels of knowledge about makes
11:54:07 <Alberth> let's see if I can reproduce your problem
11:54:18 <kero> Now it's better than before. Goes further. But still a mistake. Wait for the pastebin.
11:54:40 <kero> the problem comes when calling nml, I think
11:55:55 <Alberth> it runs nmlc, and uses python 3.4, so that's good
11:56:11 <Alberth> where is the 'nml' subdirectory?
11:56:20 <kero> Yes. Now it's no more a FIRS problem, but it's about my installation of nml.
11:56:27 *** gelignite has joined #openttd
11:56:34 <kero> when I run nml --version I have the same errors.
11:56:57 <Alberth> yes, it needs the 'nml' sub directory for everything
11:57:37 <kero> Well. nml source is in ~/openttd/hacking/nml (downloaded by hg clone [...]/nml) and I installed it by "python setup.py install"
11:57:50 <Alberth> there is no real need to do that, you can also just use the download location
11:57:55 <kero> the "binary" is in /usr/bin/
11:58:32 <kero> and actually, it was what I did on precedent installation. Just a simlink in /usr/local/bin.
11:58:53 <Alberth> you don't have a personal bin? ~/bin
12:00:00 <kero> Never thought having one.
12:00:23 <Alberth> that's very useful to have, you can drop custom links like above, or your own scripts
12:00:25 <kero> But that's not a bad idea :-)
12:00:46 <kero> I generally put everything in /usr/local/bin
12:01:04 <kero> (everything which is not package related)
12:01:13 <Alberth> does echo $PATH includes a path like /home/kero/bin (or wherever ~/bin is for you)
12:03:30 <Alberth> the lines are PATH=$HOME/bin:$PATH
12:03:49 <Alberth> ie always look first in the local bin
12:04:02 <Alberth> the trick is where to add it.
12:04:46 <kero> Ok, now the strange think. nml doesnt work when I install it with "python setup.py install", but it works when I just make a symlink from /usr/local/bin/nmlc to the downloaded nml.
12:05:04 <kero> well that's fine for me :). Just wondering why.
12:05:26 <Alberth> personal initialization files ~/.bash_profile, ~/.bash_login, or ~/.profile <- do you have any of these files?
12:05:48 <kero> Sure. I will explore this interesting idea ... another time :)
12:05:59 <Alberth> python setup.py install <-- which "python" was that?
12:06:35 <kero> "Copying nml-0.4.0.r5307_0be320b4fa1a-py3.4.egg to /usr/lib/python3.4/site-packages"
12:07:17 <kero> keikoz@kdesktop ~/openttd/hacking $ python --version
12:08:05 <kero> Anyway. Thanks for help and suggestions.
12:08:18 <Alberth> no idea why that fails
12:08:57 <kero> There probably is a good reason. But anyway, I prefer not using the setup.py way, so ... Everything is fine.
12:08:58 <Alberth> it moved the 'nml' directory to some weird place
12:09:21 <Alberth> but I don't really want to use setup, as I don't trust it
12:09:34 <kero> I should tell andy for that Makefile's $(PYTHON) problem.
12:10:13 <kero> Actually, I never trust so much using packages which I need to install in the main tree
12:11:11 <Alberth> you don't actually need to do that, it's just the default install path
12:11:26 <Alberth> you can specify a path inside your ~
12:12:43 <Alberth> in fact, I normally log in as a normal user where I don't even have rights to change anything outside my ~ :)
12:14:46 <kero> The good new, is that I don't need anymore to use the former horrible python hack.
12:15:24 <kero> Everything started because I wan't to understand what extra_callback_info2 is.
12:16:02 <Alberth> right, a symlink didn't work in messing up the firs build, how else to force it into using python3....
12:16:32 <kero> I notice that when I play OTTD, a similar pattern already occurs. I start playing, then something bothers me, then I wan't to change everything, and then I spend hours trying to code instead of actually playing.
12:16:59 <Alberth> yep, I have that with everything :)
12:17:13 <kero> It's (among others) in FIRS' script about industry_closure.
12:17:24 <Alberth> although I usually just skip the "play" part :p
12:17:41 <Alberth> yes, but in what file?
12:17:44 <kero> well generally there isn't time anymore to play
12:18:22 <kero> firs/src/templates/check_secondary_closure.pnml
12:19:44 <kero> in there, extra_callback_info2 is used to calculate a 50% probability. I wan't reduce this probability to 25% or even less.
12:20:16 <kero> But I have absolutely no idea how to do that :)
12:23:28 <Alberth> I wonder how big that variable is
12:23:49 <Alberth> you understand how that code works ?
12:24:45 <Alberth> why does nml have these hacky extra variables? it looks so unclean :(
12:25:35 <Alberth> oh, 32bits even, plenty of space :)
12:27:15 <Alberth> if you change that 32 to 0x60, you should get 25%
12:28:39 *** rambo is now known as Guest2504
12:41:22 <V453000> [14:27] <@Alberth> if you change that 32 to 0x60, you should get 25%
12:42:05 <Alberth> I thought this morning, but no
12:42:27 <V453000> nono I was gone since friday till now :)
12:42:37 <V453000> going to draw a few wagons and lets do it
12:43:25 <Alberth> V: yay, unleash the Yetis!
12:43:46 <V453000> guess I will need musa?
12:54:38 *** andythenorth has joined #openttd
12:54:58 <Alberth> kero: I just fixed the 'python' reference in Makefile.in, in FIRS
12:55:09 <Alberth> hi andy: ^ please pull
12:55:33 <kero> Alberth : to answer your question, I would say that I understand it partially?
12:56:13 <Alberth> so anything you want explained?
12:56:44 <kero> I understand what basically a & boolean is.
12:57:16 <kero> but when playing with bits, it's more complicated :)
12:57:35 <Alberth> nah, they're just a bunch of booleans :)
12:58:27 <kero> extra_callback_info2 is just a bunch of 32 random bits. That's clear.
12:58:35 <kero> (at least, in this context)
12:59:01 <Alberth> you decompose an int in powers of 2, eg 1+2+4+8+16 = 31
12:59:06 <kero> But given that, I absolutely don't understand how that interacts with & 32
13:00:11 <Alberth> so if you have a & b with both a and b a number, you decompose both numbers into powers of 2, the & says to only keep those powers of 2 that both numbers have
13:00:47 <Alberth> obviously, 32 is a power of 2 already, so no more decomposing needed
13:01:28 <Alberth> random & 32 thus is 0, if 32 is not in 'random' and it is 32 when 32 is also in 'random'
13:02:21 <Alberth> the switch tests whether or not the result of the & is 0 or not
13:02:56 <kero> But & is not a boolean, then ?
13:03:16 <Alberth> no, it's an 'and' over integers
13:03:34 <Alberth> also known as 'bitwise and'
13:03:49 <kero> Ok. Let me read about it some 20 times, thinking about it 30, and I probably will come back with questions :)
13:04:17 <Alberth> simple test what is 6 & 5 ?
13:06:23 <Alberth> and after applying the & on that?
13:07:05 <Alberth> indeed, the '4' is the only common power of 2, and that is the result thus
13:09:41 <Alberth> 15 & 9 == (1+2+4+8) & (1+8) == (1 + 8) == 9
13:11:27 <kero> You only take the common powers of 2, and you sum them up.
13:12:00 <Alberth> and if you have nothing in common, it's 0, eg 1 & 2
13:12:43 <Alberth> the reason that people switch to hexadecimal notation, is because the powers of 2 == the bits, are much easier there
13:13:35 <Alberth> 1 2 4 8 16 32 becomes 0x1 0x2 0x4 0x8 0x10 0x20 0x40 0x80 0x100 etc
13:13:38 <kero> Mmh. In a 32 bits variables, there's only 50% that there is 32 as power of 2 ?
13:14:14 <Alberth> yes, 1/2 the numbers has that bit on and the other 1/2 has it off
13:14:50 <kero> 32 = 00000000000000000000000000001111
13:15:10 <Alberth> you can easily see that with 1 (0=off, 1=on, 2=off, 3=on, 4=off, etc etc, we know it as even/odd
13:16:01 *** KWKdesign has joined #openttd
13:16:01 <Alberth> bits count from the back
13:16:15 <kero> No. I'm wrong. I still have in mind some sort of comparison between integers.
13:16:30 <Alberth> 01011 = 0x8 + 0x2 + 0x1 = 11
13:17:38 <Alberth> 32 = 0x20 == 0010 0000
13:17:54 <Alberth> or 00100000 if you leave out the spaces
13:19:25 <Alberth> btw you can ask Python about binary representation: bin(32) -> gives '0b100000'
13:22:58 <kero> Ok. I think I'm starting to understand.
13:25:39 <kero> 0x60 = 96 = 64+32, hence 25% probabilities
13:26:27 <Alberth> indeed, the & can result in 0, 32, 64, or 96, and only 0 closes the industry
13:27:37 <Alberth> bitwise operations are not that magical as you see :)
13:27:49 *** Pensacola has joined #openttd
13:28:32 *** HerzogDeXtEr has joined #openttd
13:28:54 <kero> It's not basically complicated to understand, but all of this needs a lot of mental mathematic automatisms to go through fast.
13:29:16 <kero> I uses hex once each two years :)
13:30:01 <Alberth> I see 0x20 when I read 32, and the same with other powers of 2 upto 4096
13:31:08 <Alberth> write everything in hex notation :)
13:34:04 <kero> half of the possible numbers also have 1 as possible power of two. Hence, "random_32byte" & 1 should also give 50% chances 1, no ?
13:34:54 <kero> So, what can be the point in using & 32 instead of another power of two ?
13:35:10 <peter1138> To test a different bit.
13:35:45 <peter1138> In OpenTTD that random bits are not random every time you check it.
13:36:14 <peter1138> They are persistent, and changed during certain events. Therefore you can repeatedly test a random bit and get the same result, until it changes.
13:37:01 <Alberth> say that you have a number of random things going on, if you use &1 for all, your 'random' either happens with all things or with none
13:37:07 <peter1138> If they were truely random, they'd be useless. Random graphics would just flicker :)
13:37:38 <andythenorth> now to apply partial compiles to FIRS
13:37:43 <andythenorth> not such a small job
13:38:33 *** Myhorta[1] has joined #openttd
13:38:53 <Alberth> perhaps instead change nml to handle that in a general way? :)
13:39:24 <andythenorth> I think it’s best I make some mistakes first
13:39:44 <andythenorth> doing it in a generally repeatable way is hard :)
13:39:53 <andythenorth> feel free to look at what I’m doing :P
13:40:05 <andythenorth> it’s 99% also what Eddi|zuHause was doing in CETS too
13:40:38 <andythenorth> the newgrf does have to be authored to support it, no hiding from that
13:41:19 <Alberth> not even in the general case, probably
13:41:44 <Alberth> but that's to be expected, if you want partial compile, you need at least 2 parts :)
13:42:07 <Eddi|zuHause> <andythenorth> nforenum --silent -w=+ generated/iron-horse.nfo <-- you can silence each individual warning of nforenum
13:42:35 <andythenorth> I figured out that after re-reading docs :D
13:43:41 *** Polleke has joined #openttd
13:47:58 *** Pensacola has joined #openttd
14:29:44 <Alberth> look on the bright side, sometimes you are connected :)
14:34:57 <andythenorth> specifically just putting header items and consists into a single list of ‘things to render'
14:38:46 <Alberth> I would move the 'render' thing into a function and call that twice ?
14:40:51 <kero> Alberth : And when I arrived in this place, it wasn't sure at all that it would be possible.
14:41:23 <Alberth> the Internet is an amazing place :)
14:41:35 <andythenorth> Alberth: that would be a good starting point
14:42:38 <Alberth> try to reduce code duplication by moving it into functions and calling it several times rather than trying to merge the call
14:43:09 <Alberth> the latter adds dependencies that are hard to revert in general
14:44:31 <andythenorth> I used to over function
14:44:35 <Alberth> in the former case, you can simply add a parameter, or add an extra step before or after, or if you really need to, duplicate the function again
14:44:53 <andythenorth> I was one of those people who would do “def add_numbers(first, second)”
14:45:17 <Alberth> you should do lisp :p
14:46:42 <Alberth> or functional programming in the extreme +(s(0), s(s(0)))
14:48:05 <Alberth> +(0, X) -> X and +(s(X), Y) -> +(X, s(Y))
14:52:24 <andythenorth> maybe another day :)
15:00:42 <V453000> halp! :D is there any simple way to get musa?
15:00:50 <V453000> or do I have to do the checkout at musa svn?
15:03:53 <frosch123> you can also use hg, you may already have that :)
15:12:17 *** pthagnar has joined #openttd
15:21:37 <andythenorth> Alberth: tidied that file, I could do more, but it’s probably ok
15:22:14 <Alberth> you must keep something to do for the future :)
15:22:26 <andythenorth> there is a small list for that
15:23:07 <andythenorth> a better way to split out the unwanted nfo would be good
15:23:15 <andythenorth> something like eddi-nml :P
15:24:23 <andythenorth> seen another place to unify
15:26:24 *** pthagnar has joined #openttd
15:29:41 <V453000> isnt pull meant to download the files?
15:29:59 <andythenorth> you have the checkout?
15:33:56 <V453000> meh managed to download it from the hg manually
15:34:10 <V453000> I guess actually using it isnt simple either
15:35:30 <V453000> aha I see (probably) :D
15:36:43 *** oskari89 has joined #openttd
15:40:55 <V453000> I have edited the example.ini
15:40:58 <V453000> what else do I need to do
15:41:31 <frosch123> hmm, ah, right you were using the nmlc binary
15:41:54 <frosch123> well, do you have python installed?
15:42:13 <V453000> if nml and tortoisehg works, I must have python?
15:42:31 <frosch123> not if you use nmlc.exe
15:42:54 <frosch123> how do you start nml?
15:43:12 <V453000> I run compile.bat in the repository
15:43:21 <V453000> I have python27 it looks like
15:44:58 <frosch123> what happens if you type "python musy.py" in console?
15:46:07 <V453000> python musa.py does nothing
15:46:21 <frosch123> does it find the "python" command?
15:46:25 <V453000> musa.py says error> you must pass a configuration file
15:46:46 <frosch123> ah, so it worked .)
15:47:10 <frosch123> continue with "python musy.py --help"
15:47:40 <V453000> that still throws an error, but simply using musa.py --help does give me a help thingy
15:48:39 <Eddi|zuHause> "<kero> Oh putain." <-- never would "pardon my french" have been more appropriate :p
15:49:51 <V453000> it keeps saying to give some configuration file, could settings.py.example be it?
15:50:09 <frosch123> it's the thing you edited
15:50:28 <V453000> I edited example.py which was specifically about the upload
15:50:31 <frosch123> that's not for you :p
15:50:38 <frosch123> but for the bananas server
15:50:51 <frosch123> yeah, that ini is the config file
15:51:09 <frosch123> rename it to yeti.ini or something
15:51:10 <V453000> so -c and give it that file
15:51:44 <V453000> did something, "packaging files... no grf file
15:52:06 <NGC3982> OpenTTD is still only uses one CPU core, right?
15:52:18 <frosch123> "musa -c yeti.ini -d -u v123456 -p nuts yeti.grf changelog.txt readme.txt" <- you should end up with something like
15:52:51 <V453000> and nuts is there why? :d
15:52:53 <frosch123> no, your bananas account
15:53:01 <frosch123> "nuts" your password, don't paste it here :)
15:53:13 <frosch123> at the end, all files you want to upload
15:53:21 <frosch123> at least the grf, but also readme/changelog if you have one
15:54:21 <frosch123> if it prints something useful, remove the "-d" to really upload ("-d" means dry-run, so it is not really uploaded)
15:54:49 <V453000> it answered me if I am author and spews shit about the dry run :)
15:56:34 <Alberth> yetis conqueror the bananas server!
15:57:16 <frosch123> yeah, let's see how many versions of yeti it needs for tb to notice the increased disk usage :p
15:58:38 <V453000> wait when I start doing animation :P
15:58:42 <V453000> no animation atm, 30mb
15:58:51 <V453000> all okay, content uploaded to bananas
15:59:45 <frosch123> your name is too long :p
16:07:27 <frosch123> something is wrong with your tile layouts
16:07:42 <frosch123> the bounding boxes are completely out of the place and beyond the industry bound
16:08:48 <V453000> yeah they look quite wtf
16:10:32 *** Supercheese has joined #openttd
16:11:17 <frosch123> lol, did you intentionally replace mail with clay?
16:11:25 <frosch123> all the houses produce/accept clay :)
16:11:37 <pthagnar> lots of home potters
16:14:43 <Eddi|zuHause> "test before uploading"?
16:14:50 <frosch123> pax, mail, goods, food, sweets, fizzy drinks
16:15:01 <V453000> Eddi|zuHause: I did I just didnt check buildings :)
16:16:17 *** XeryusTC_ is now known as XeryusTC
16:16:34 <andythenorth> I always end up writing some kind of dispatcher :P
16:19:39 <Alberth> without a Makefile that is to be expected :p
16:19:57 <V453000> just moved the two cargoes to slots 17 and 18 :)
16:21:26 <andythenorth> feel free to move this to a Makefile :)
16:22:20 <andythenorth> it’s maybe TMWFTLB, dunno
16:28:26 <andythenorth> partial compile FIRS is going to be a significant job
16:28:37 <andythenorth> all the CPP expects to be run on linked pnml
16:29:00 <andythenorth> that’s game over for partial compiling :D
16:29:19 <andythenorth> so about makefiles... :P
16:29:59 <andythenorth> if I want a directory full of generated nfo files, make can do that?
16:30:05 <andythenorth> and it can also then link them?
16:30:18 <V453000> 20 minutes after 0.0.1 :D
16:30:59 <Alberth> just 2000 minutes until yeti 0.0.99 :)
16:32:29 <Eddi|zuHause> <andythenorth> all the CPP expects to be run on linked pnml <-- running cpp on the individual pnml files is a simple change in the makefile.
16:32:42 <Alberth> andythenorth: a Makefile can compare time stamps from source and destination files, and execute a bunch of shell commands if the source is newer. So if you can produce a number of shell commands to execute to build a file Y from file X, yes
16:33:16 <andythenorth> how does it get the list of destination files?
16:33:34 <Eddi|zuHause> andythenorth: the makefile starts with a "target"
16:33:43 <Alberth> it works backwards from the thing you eventually want
16:34:15 <Eddi|zuHause> andythenorth: i.e. "target" is "cets.grf", then it looks for a rule "what do i need to get cets.grf? cets.nfo!"
16:34:23 <Alberth> ie a source in the last step can be a destination in the second to last step
16:34:27 <andythenorth> so how are the rules encapsulated?
16:34:32 <andythenorth> all in the makefile?
16:34:50 <Eddi|zuHause> andythenorth: then it looks what it needs to do to convert "cets.nfo" into "cets.grf"
16:35:01 <Eddi|zuHause> andythenorth: which is "call grfcodec!"
16:35:25 * Alberth leaves makes in the hands of Eddi
16:36:06 <andythenorth> the puzzle (it’s a practical puzzle, not a conceptual puzzle) is how make gets the rules
16:36:08 <Eddi|zuHause> andythenorth: then it goes on: "but i don't have cets.nfo, what do i need now?"
16:36:24 <Eddi|zuHause> andythenorth: and it finds "cets.nfo? cets.nml!"
16:36:29 <Alberth> andythenorth: you specify the rules
16:36:34 <andythenorth> epxressing foo.grf depends on foo.nfo is easy
16:36:54 <andythenorth> expressing that foo.nfo depends on linking 100 nfo files seems harder
16:37:10 <andythenorth> I guess that could just be a script that runs
16:37:25 <andythenorth> but then I break make afaict
16:37:46 <Alberth> foo.nfo: x1.nfo x2.nfo x3.nfo .... is the simple approach, there are commands to build such lists
16:38:40 <Alberth> this says that you make foo.nfo out of the x*.nfo files
16:38:41 <Eddi|zuHause> andythenorth: cets/scripts/Makefile.in has some examples
16:39:30 <andythenorth> I’m wondering if changing the makefile is the only viable route for FIRS
16:39:35 <Eddi|zuHause> it has a list of manual dependencies at the top
16:39:51 <andythenorth> it’s got so much CPP that the pure python compile will demand a large rewrite of FIRS src
16:39:58 <Eddi|zuHause> and it uses a file called "cets.src.dep" which provides additional autogenerated dependencies
16:40:27 <Eddi|zuHause> andythenorth: i think very little changes are needed for the makefile
16:40:46 <andythenorth> there’s already a directory of generated pnml in FIRS
16:42:04 <Eddi|zuHause> for makefile purposes, it's simpler if you change the file extension, instead of the directory
16:42:35 <Eddi|zuHause> well, you can easily change the directory as well, but make mostly operates on file extensions to determine what to do
16:42:36 <andythenorth> e.g. .onfo, .onml etc?
16:43:36 <Eddi|zuHause> the cets method is basically: generate->gnml->onml->onfo->nfo->grf
16:44:01 <andythenorth> onfo is nfo before linking?
16:44:30 <Eddi|zuHause> onfo is the partial files
16:44:39 <Eddi|zuHause> the "output" of nmlc
16:45:14 <andythenorth> make links them? Or you have a shell script I’m missing?
16:45:37 <Eddi|zuHause> the linking is in combine_engines.sh
16:45:42 <Eddi|zuHause> which is an autogenerated file
16:46:29 <andythenorth> that’s why I can’t find it
16:46:51 <Eddi|zuHause> run scripts/generate.py
16:47:20 <andythenorth> (I didn’t run it, but I get the idea)
16:47:59 <andythenorth> so it’s not insane to have make build dep lists, scripts etc dynamically during the make
16:48:35 <Eddi|zuHause> i'm no authority do decide on whether what i'm doing is "sane" :p
16:49:48 <andythenorth> so FIRS should continue using the python step primarilly for templating & docs generation
16:49:54 <Eddi|zuHause> "it works" is not a good criterium in any case
16:50:03 <andythenorth> and ${someone} should change the makefile
16:50:27 *** KWKdesign has joined #openttd
16:53:12 <andythenorth> so make can walk a dir, using a rule to generate .onfo from .pnml, including CPP step
16:53:34 <andythenorth> and then I need a standalone linker script which knows the file order for the grf
16:54:13 <andythenorth> the linker script can walk a list from the existing python stuff
16:54:30 <Eddi|zuHause> make uses the autogenerated file "cets.src.dep" to find which files to walk, it doesn't walk the directory to find files
16:54:45 <andythenorth> is directory walking discouraged?
16:54:57 <Eddi|zuHause> it's not reliable
16:55:05 <andythenorth> so explicit list
16:55:14 <andythenorth> I can provide a manifest
16:55:38 <andythenorth> firs.pypnml is close to that already
16:55:52 <andythenorth> and final step, makefile calls nforenum then grfcodec
16:56:17 <andythenorth> then, faster FIRS
16:56:57 <Eddi|zuHause> the content of cets.src.dep looks like this:
16:57:00 <Eddi|zuHause> cets.nfo: src/DR/212.onfo
16:57:02 <Eddi|zuHause> cets.nfo: src/DB_AG/440a.onfo
16:57:03 <Eddi|zuHause> cets.nfo: src/DRG/KoeII.onfo
16:57:33 <Eddi|zuHause> so when make is asked for providing cets.nfo, it looks for all these files
16:57:57 <Eddi|zuHause> and then it falls into the "%.onfo: %.onml" rule
16:58:19 <andythenorth> ok, that’s understandable
16:58:24 <Eddi|zuHause> which says "if you look for an onfo file, look for the file with the same name ending in onml"
16:58:30 <andythenorth> I’ll probably get smacked down by syntax etc
16:58:40 <andythenorth> I’ll try converting this shortly
16:58:51 <Eddi|zuHause> and this chains down further
16:58:56 <andythenorth> partial compiles won’t actually work until I refactor industries some more
16:59:03 <andythenorth> currently they depend on each other in location checks
16:59:10 <Eddi|zuHause> until it finds a rule which has actually existing (and up to date) files
16:59:27 <andythenorth> and make handles all the timestamp checks?
16:59:43 <Eddi|zuHause> that's the primary thing it does
17:00:35 <Eddi|zuHause> once it found this "root" file, it executes the commands for the rule, and then chains back to the previous rule, etc.
17:01:21 <Alberth> to test use "make -n" which means to run make, print the commands it would do, but don't actually do them
17:01:25 <andythenorth> and for something like a template file, which might have changed, but has no rules to compile it (it’s referenced by a different script)?
17:01:30 <andythenorth> is that what PHONY is for?
17:02:46 <Eddi|zuHause> i wouldn't use things like PHONY
17:02:58 <andythenorth> I think my question is a non-question
17:03:04 <Eddi|zuHause> a dep file can also look like this:
17:03:06 <andythenorth> the template files just go in a deps list?
17:03:11 <Eddi|zuHause> src/headers.src.dep: /usr/include/stdc-predef.h src/defines.pnml \
17:03:12 <Eddi|zuHause> src/defines.gnml src/parameters.pnml src/compatibility.pnml \
17:03:14 <Eddi|zuHause> src/glyphs.pnml src/cargo_definitions.pnml src/railtype_definitions.pnml
17:03:40 <andythenorth> so if any of those are changed, the rule is executed
17:03:41 <Eddi|zuHause> which is autogenerated by cpp
17:04:04 <Alberth> clean:\n\tblah <-- tries to construct a file called "clean" by doing the 'blah' commands below it. PHONY clean says "clean is not a file, but a virtual target"
17:05:06 <kero> Someone familiar with industrytype.h ? I can't understand what the variable "byte num_table" is in the struct IndustrySpec
17:05:12 <andythenorth> so keeping track of templates and stuff would be up to me, or I’d have to do that when they are called
17:05:17 * andythenorth thinking out loud
17:07:04 <Alberth> kero: there is no struct IndustrySpec in industry_type.h (you're talking about openttd source code right?)
17:07:27 <Eddi|zuHause> "Number of elements in the table" <- what's difficult to understand?
17:07:33 <Alberth> oh, sorry there is also a file industrytype.h missed that
17:07:58 <kero> Eddi|zuHause : I don't understand what elements it speaks about :)
17:08:22 <Alberth> const IndustryTileTable * const *table; <-- kero that one
17:08:44 <Alberth> pointers don't keep the length of allocated memory
17:09:07 <Alberth> so you need to keep the length (number of entries) as well
17:10:22 <Eddi|zuHause> kero: an "Industry" consists of multiple "IndustryTile"s
17:10:51 <kero> Ok, so it's the table of the tiles.
17:15:45 <andythenorth> ^ so I need to add to that
17:18:46 <andythenorth> or I need to edit the main Makefile
17:20:42 <Eddi|zuHause> andythenorth: you shouldn't edit the main makefile
17:21:51 <Eddi|zuHause> andythenorth: you possibly need to change a thing or two in Makefile_nml, but all modifications that you don't have to do to existing things should go into Makefile.in
17:22:36 <andythenorth> FIRS has no Makefile_nml
17:23:05 <andythenorth> seems like main Makefile would need changed to at least get a firs.nfo rule
17:23:33 <andythenorth> it seems quite attached to the idea of having firs.nml and building that with nmlc
17:24:29 <Eddi|zuHause> in the "core" makefile, this was changed from .nml to _nml because of file ending issues
17:24:46 <Eddi|zuHause> FIRS is using a much older version of the makefile than CETS
17:25:14 <andythenorth> perhaps changing that would be wise
17:25:20 <Eddi|zuHause> you can look at the file history in CETS to get a clue what i changed
17:33:18 <kero> I'm curious. What is CETS ?
17:33:46 <andythenorth> so FIRS is doing it wrong
17:33:54 <andythenorth> preprocess.py should be two scripts
17:34:01 <andythenorth> one should generate a list of depts
17:34:13 <andythenorth> which make uses as a rule
17:34:25 <andythenorth> the other script should simply template one file at a time from the list of deps
17:35:43 <andythenorth> I’m going to ignore the docs stuff, that can be a single python script
17:44:22 <Supercheese> Oh, we *are* there yeti
17:44:22 <Eddi|zuHause> it's not how i do it, though
17:44:38 <Eddi|zuHause> i output all nml files from one script run
17:44:52 <Eddi|zuHause> and only "outsource" the graphics templating
17:45:00 <Eddi|zuHause> i.e. the pixa call
17:45:21 <DorpsGek> Commit by translators :: r26686 trunk/src/lang/swedish.txt (2014-07-13 17:45:14 UTC)
17:45:22 <DorpsGek> -Update from WebTranslator v3.0:
17:45:23 <DorpsGek> swedish - 11 changes by spacejens
17:47:54 <Supercheese> ah must be because they're not animated yeti
17:50:00 <Eddi|zuHause> well, actually, your "render_pnml" is more like my cpp call? then yes, i do that separately.
18:05:35 *** andythenorth has joined #openttd
18:17:30 *** __ln__ is now known as __ln___
18:18:48 <andythenorth> Eddi|zuHause: in CETS Makefile.in, lines 5-9 do what?
18:18:59 <andythenorth> the first is obviously the nfo rule
18:19:10 <andythenorth> I’m trying to understand the order of execution
18:25:10 <Eddi|zuHause> those are: "if any of these files are modified, execute the whole generation step"
18:25:42 <andythenorth> so those are rules with no recipe?
18:26:01 <Eddi|zuHause> this is a variable definition
18:26:10 <Eddi|zuHause> the rule is further down where it says $(GENERATE)
18:26:39 <Eddi|zuHause> anything that doesn't have a ":" is not a rule
18:27:17 <Eddi|zuHause> the first 3 lines are rules without recipe. they only define dependencies
18:27:39 * andythenorth has been reading make docs
18:27:45 <Eddi|zuHause> you must have exactly one recipe for a target, but can have multiple dependencies
18:28:08 <andythenorth> so if any of the deps are outdated, the recipe runs?
18:28:33 <andythenorth> so what is GENERATE
18:28:41 <andythenorth> it’s not tab indented, so it can’t be a recipe
18:28:43 <Eddi|zuHause> GENERATE is a variable
18:29:01 <andythenorth> so that’s reused later with ${}
18:29:05 <Eddi|zuHause> $(GENERATE) gets replaced by the string right of the =
18:29:32 <andythenorth> you only use GENERATE once?
18:29:32 <Eddi|zuHause> the \ at the end of the line says "this string goes on on the next line"
18:29:50 <andythenorth> so it’s just a var for convenience
18:29:59 <Eddi|zuHause> better overview, etc.
18:31:03 <andythenorth> so the key entities are only: targets, deps, recipes, vars
18:31:14 <andythenorth> no other interesting concepts?
18:31:23 <andythenorth> loops and stuff?
18:31:31 * andythenorth doesn’t want to encounter loops
18:31:50 <Eddi|zuHause> you should avoid cyclic dependencies
18:32:28 <andythenorth> %.foo is a wildcard?
18:32:40 <andythenorth> or is it like %s in strings?
18:33:00 <Eddi|zuHause> yes, it's a wildcard
18:33:30 <andythenorth> so I need a rule for firs.nfo
18:33:30 <Eddi|zuHause> matches any file which ends in .foo, unless there is a specific "x.foo" rule that matches
18:33:49 <andythenorth> which has a recipe, which could be a script that handles all the pnml->nfo
18:34:20 <andythenorth> and I need a rule for %.pnml?
18:34:32 <andythenorth> which calls the python pre-processor script
18:35:39 <andythenorth> so currently it uses a phony target of firs-pnml
18:35:43 <andythenorth> instead of %.pnml
18:36:45 <andythenorth> and %.pypnml are deps for %.pnml
18:38:31 <kero> All of this is horribly complicated.
18:39:14 <andythenorth> .py deps need handling explicitly?
18:39:23 <Eddi|zuHause> "%.py" would look for a "bar.py" when you process a "bar.pnml"
18:39:39 <Eddi|zuHause> you need explicit "render_pnml.py"
18:39:49 <Eddi|zuHause> or like my "$(GENERATE)"
18:40:10 <Eddi|zuHause> list all the files that render_pnml imports
18:40:15 <andythenorth> so the case I have in mind is declaring the [industry_name].py files as deps for .pnml
18:40:24 <andythenorth> rather than the generation scripts
18:40:33 <andythenorth> every industry has an accompanying python module
18:41:45 <andythenorth> chaining all the deps together is the main reason I’ve been avoiding a make-based partial compile
18:42:18 <andythenorth> but it can’t be worse than inspect.stack[1][2] eh? :P
18:43:06 <Alberth> you're not chaining deps in Python otherwise?
18:43:08 <Eddi|zuHause> i don't even know what that's supposed to do
18:43:31 <andythenorth> Alberth: tbh the iron horse case is simple, and getting the deps with python is easy
18:43:46 <andythenorth> also I’m only running the partial compile when *I* know it’s safe
18:43:49 <Eddi|zuHause> andythenorth: generally, an output file must depend on all input files, and all scripts and programs used in the recipe
18:45:02 <andythenorth> so I do need to provide the .py files when they’re relevant
18:45:13 <Alberth> kero: learning something new is always complicated :)
18:45:40 * andythenorth thinks of a counter-case
18:46:08 <Alberth> by adding the .py file as dependency, the target gets rebuild when you change the conversion tool
18:46:16 <Eddi|zuHause> andythenorth: missing a dependency generally results in things not being recompiled when they are changed
18:46:56 <Alberth> leading to segmentation faults in c++ :p
18:47:07 <Eddi|zuHause> andythenorth: the industry_name.py files should be dependency of the generator script
18:47:53 * andythenorth needs to draw a picture
18:48:20 <andythenorth> or start FIRS from scratch
18:48:21 <Eddi|zuHause> andythenorth: if a file contains the line "import x", x must be a dependency of that file
18:48:54 <Eddi|zuHause> you can organize these dependencies separate from the recipe
18:48:57 <andythenorth> I don’t fancy manually maintaining all those deps
18:50:04 <andythenorth> I could write a script that reads all the python files, looking for imports?
18:50:11 <Eddi|zuHause> make a "dep_import" function that does the actual import, and writes the dependency to a file
18:50:33 <andythenorth> it needs to be recursive through all the modules
18:50:39 <Eddi|zuHause> i tried to write such a script once. but i didn't have the patience to follow through
18:51:01 <Eddi|zuHause> problem is to sort out system imports vs. own imports
18:51:28 <Alberth> own imports are not from x import y ?
18:51:29 <Eddi|zuHause> and working directories, import paths, etc. to find the actual file
18:52:10 <Eddi|zuHause> Alberth: no, i mean importing a file written by yourself or importing some library
18:52:30 <Eddi|zuHause> handling "from ... import" is easy
18:52:56 <Alberth> yeah, I always do "import re" for system import, and "from x import y" for my own files
18:54:03 <Alberth> so a match on ^from lines gives my own imported files
18:54:06 <Eddi|zuHause> Alberth: that's not a useful discrimination
18:56:08 <Eddi|zuHause> oh, also "x.py" vs. "x/__init__.py"
18:56:47 <andythenorth> to avoid a hokey python-based partial compile, I need Make and a hokey python-based dep generation script?
18:57:35 <Eddi|zuHause> andythenorth: i can give you a script that searches all "import" and "from...import"
18:58:18 <Eddi|zuHause> but it needs to figure out what file each import actually references, and then recursively descend into that
18:58:58 <andythenorth> I’m surprised there’s no library for this already
18:59:28 <andythenorth> all I’ve found is some stuff about make and code generators being a bad idea :P
18:59:35 <andythenorth> let’s ignore that
19:00:19 <Eddi|zuHause> did they firework yet?
19:00:24 <Alberth> like copy/paste is a good idea :)
19:01:18 <andythenorth> it describes race conditions
19:01:22 <Alberth> didn't the finals start just 15 minutes ago?
19:01:25 <Eddi|zuHause> andythenorth: all this import stuff was finally too complicated to waste effort on, so i just wrote down all the files manually. it doesn't change that often
19:01:39 <Eddi|zuHause> Alberth: 1 minute ago
19:01:56 * andythenorth might watch football
19:02:18 <Alberth> If you don't expect to change the program often, you can just depend on all Python files
19:02:19 <andythenorth> Iron Horse only tries a partial compile when I pass it a flag
19:02:24 <andythenorth> which seems safe
19:02:36 <andythenorth> can I depend on all python files limited to a certain dir?
19:02:53 <Alberth> some/dir/*.py probably
19:03:26 <andythenorth> I think it would have unwanted results unless I make it more fine-grained
19:03:47 <andythenorth> e.g. changing a single [cargo].py value would cause the entire grf to be recompiled
19:03:51 *** Progman has joined #openttd
19:04:36 <Eddi|zuHause> yes, because you don't know which industries use that cargo
19:04:45 <Eddi|zuHause> and might need to be changed
19:04:48 <andythenorth> ah, so that’s a bad example
19:05:17 <Alberth> it would indeed, it's a balance between effort of finding the exact dependencies versus rebuilding too much
19:05:28 <Eddi|zuHause> but what you can do: write into a .pnml.new, compare that with the existing one, and if no difference, delete the new file, otherwise delete the old file and move
19:05:48 <Eddi|zuHause> then make will pick up on the .pnml file not being changed, and skip the rest of that dependency tree
19:06:29 *** tparker has joined #openttd
19:06:45 <andythenorth> Eddi|zuHause that’s pretty smart
19:08:06 <Eddi|zuHause> i have that for some files in cets
19:08:16 <Eddi|zuHause> look in scripts/files.py or so
19:55:21 <peter1138> Hmm, petrol-vapour 'steam' engines, scary idea.
20:18:39 *** jpierre03_ has joined #openttd
20:31:19 *** djura-san has joined #openttd
20:37:09 <djura-san> so, i selected show area. when will the snow fall? :|
20:49:02 <djura-san> well i selcted snowy area when i generated new map. I expect some snow there :o)
20:52:50 <Eddi|zuHause> if you didn't select hilly as well, then you won't get much snow
20:53:57 <djura-san> this game never stops to amaze me :)
20:54:04 <djura-san> thank you for your answer Eddi|zuHause
20:54:34 <Eddi|zuHause> there are also newgrfs that get you more snow in the winter than in the summer
21:06:22 *** jpierre03_ has joined #openttd
21:27:07 <Eddi|zuHause> "champion countdown; 5 minutes"
21:36:28 <Eddi|zuHause> that was looooong 5 minutes
21:37:59 *** Progman has joined #openttd
continue to next day ⏵
