IRC logs for #openttd on OFTC at 2014-07-20
⏴ go to previous day
02:05:54 *** luaduck is now known as luaduck_zzz
02:37:20 *** tokai|noir has joined #openttd
02:37:20 *** ChanServ sets mode: +v tokai|noir
02:40:35 *** HerzogDeXtEr has joined #openttd
04:05:28 *** Supercheese has joined #openttd
04:14:18 *** pthagnar has joined #openttd
04:43:17 *** Hazzard_ has joined #openttd
04:56:16 *** Eddi|zuHause has joined #openttd
05:42:41 *** trendynick has joined #openttd
05:57:56 *** andythenorth has joined #openttd
06:45:15 <andythenorth> one step forward, one step backward
06:46:46 *** Pensacola has joined #openttd
06:49:32 <andythenorth> planetmaker: is there a way to stop nmlc expanding the includes when reporting errors?
06:49:34 *** sla_ro|master has joined #openttd
06:49:41 <andythenorth> I just want the line number in the nml file
06:50:56 <planetmaker> I don't think you can easily do that. You will have to strip the include information in the nml file it processes so that it looks like an original nml file
06:53:37 <planetmaker> nml gets the include info from the typical lines which start with #
06:54:06 <planetmaker> those are generated by the preprocessor to help compilers pointing to the place of the error. Than stupidly giving the line in the preprocessed big file
06:54:23 <planetmaker> thus I don't quite understand why you want to remove this feature :)
06:54:36 <andythenorth> because the line numbers don’t correspond to anything useful
06:55:08 <Rubidium> just sed -i '/^#.*//' <nml file> ?
06:56:45 <andythenorth> I suspect it’s a valid error, and macro expansion is failing silently for some reason
06:57:09 <andythenorth> or rather, before I started changing the compile, I expected one specific failure
06:57:21 <andythenorth> and the line number being reported is where I expected that failure
06:57:34 <andythenorth> but I can’t see the problem in the processed nml
06:57:42 <andythenorth> and I’d rather have the line number in the processed nml
06:58:12 <planetmaker> yeah... remove the line info from the pnml like rubi suggested
06:58:53 <andythenorth> what’s wrong with this? o_O
06:58:54 <andythenorth> switch(FEAT_INDUSTRYTILES, SELF, THIS_ID(tile_nearby_industry), (nearby_tile_class( 1, 1) == TILE_CLASS_INDUSTRY) | (nearby_tile_class( 1, 0) == TILE_CLASS_INDUSTRY) | (nearby_tile_class( 1, -1) == TILE_CLASS_INDUSTRY) | (nearby_tile_class( 0, -1) == TILE_CLASS_INDUSTRY) | (nearby_tile_class(-1, -1) == TILE_CLASS_INDUSTRY) | (nearby_tile_class(-1, 0) == TILE_CLASS_INDUSTRY) | (nearby_tile_class(-1, 1) == TILE_CLASS_INDUSTR
06:58:55 <andythenorth> (nearby_tile_class( 0, 1) == TILE_CLASS_INDUSTRY)) { 1: return CB_RESULT_LOCATION_DISALLOW; return CB_RESULT_LOCATION_ALLOW; }
06:59:34 <andythenorth> THIS_ID(blah) macro expansion failed
06:59:35 <planetmaker> you're using currently bit math instead of boolean math
07:00:14 <andythenorth> it would take me 10 minutes to understand that switch :)
07:00:45 <planetmaker> then make one switch for each expression separated by |
07:00:58 <planetmaker> would take longer to understand then :P
07:01:06 <andythenorth> nah, I’ll leave it
07:01:12 <andythenorth> I might fix the broken macro though :P
07:11:06 * andythenorth break-fix coding :P
07:18:51 *** andythenorth has joined #openttd
07:19:29 *** Alberth has joined #openttd
07:19:29 *** ChanServ sets mode: +o Alberth
07:28:33 *** andythenorth has joined #openttd
07:50:34 *** Progman has joined #openttd
08:33:06 *** Polleke has joined #openttd
08:36:35 *** andythenorth has joined #openttd
08:37:48 *** shirish has joined #openttd
08:48:50 *** Pensacola has joined #openttd
08:57:03 *** andythenorth has joined #openttd
08:57:35 *** Myhorta has joined #openttd
09:11:49 *** Polleke has joined #openttd
09:16:25 *** frosch123 has joined #openttd
09:23:56 *** Pensacola has joined #openttd
09:27:39 *** Pensacola has joined #openttd
09:52:35 *** andythenorth is now known as Guest3273
09:52:36 *** andythenorth has joined #openttd
10:01:20 <andythenorth> nml, using ‘param[0]’ how do I read a specific bit?
10:04:50 <kero> Is there some way to set a wait time in depots in timetables ?
10:05:22 <kero> (I guess not but I hope I missed something ... ;) )
10:07:03 <kero> andythenorth : I might be wrong, but I think that the bitwise &, which Alberth explained to me the other day, should do that
10:07:11 <andythenorth> hasbit probably works
10:07:16 <andythenorth> it’s just a bool test
10:08:45 <Alberth> it's just wrapping (value & (1 << bitnumber)) != 0 for you :)
10:17:37 *** andythenorth has joined #openttd
10:17:59 <andythenorth> got one industry working on python -> pnml -> nml -> nfo
10:19:42 <andythenorth> if it works, a compile to test one industry will be ~10s instead of ~3m
10:21:35 <andythenorth> maybe 20s, depends on grfcodec
10:28:35 <andythenorth> FIRS codebase is bigger than it needs to be
10:28:41 <andythenorth> project isn’t that complicated :P
11:05:40 *** Polleke has joined #openttd
11:08:58 *** Polleke_ has joined #openttd
11:23:16 *** andythenorth has joined #openttd
11:54:01 *** andythenorth has joined #openttd
11:55:15 *** Pensacola has joined #openttd
12:00:46 * andythenorth fun with compiles
12:16:32 *** FLHerne has joined #openttd
12:29:30 *** Polleke has joined #openttd
12:32:07 *** andythenorth has joined #openttd
12:35:07 <andythenorth> specifically what happens if you inject chaos monkey and get out of an acceptable state
12:37:55 * FLHerne remembers having one of those
12:38:09 <FLHerne> It had yellow construction equipment though
12:40:11 *** SylvieLorxu has joined #openttd
12:40:44 <andythenorth> there are variants
12:40:47 <andythenorth> it’s an appalling toy
12:41:16 <FLHerne> They're fun to watch, and then fun to confuse :P
12:41:57 <FLHerne> Take too long to setup though, and the little balls get everywhere
12:45:00 <Eddi|zuHause> looks like sa rube goldberg machine
12:48:12 <andythenorth> wtf cargo code compilation
12:48:16 * andythenorth needs to fix that
12:51:45 *** Pensacola has joined #openttd
12:59:28 *** LadyHawk has joined #openttd
13:00:08 *** LadyHawk is now known as Guest3285
13:10:07 *** Polleke has joined #openttd
13:14:29 *** Polleke_ has joined #openttd
13:32:15 *** andythenorth has joined #openttd
13:47:40 *** Pensacola has joined #openttd
14:05:36 <andythenorth> running 16 nmlc processes makes my laptop hot
14:15:37 *** Myhorta has joined #openttd
14:25:58 *** Polleke has joined #openttd
14:33:36 <andythenorth> FIRS nfo compile _nearly_ works
14:39:28 <andythenorth> planetmaker: here? o_O
14:46:31 *** Pensacola has joined #openttd
15:53:19 *** HerzogDeXtEr has joined #openttd
16:10:37 *** Myhorta has joined #openttd
16:51:08 *** KWKdesign has joined #openttd
17:10:56 *** Hazzard has joined #openttd
17:11:36 <planetmaker> he's now here. somewhat
17:34:22 *** bdavenport has joined #openttd
17:46:02 <DorpsGek> Commit by translators :: r26697 /trunk/src/lang (3 files) (2014-07-20 17:45:54 UTC)
17:46:03 <DorpsGek> -Update from WebTranslator v3.0:
17:46:04 <DorpsGek> simplified_chinese - 6 changes by siu238X
17:46:05 <DorpsGek> norwegian_bokmal - 52 changes by eirik174
17:46:06 <DorpsGek> swedish - 49 changes by BerraGson
18:30:28 <planetmaker> new translators are busy it seems
19:00:05 <FLHerne> Are some of the minimally-completed and unmaintained ones ever going to be removed?
19:00:42 <FLHerne> It seems a bit pointless having <20% of a language translated for years
19:01:30 <Rubidium> FLHerne: which is *the* reason why those languages are not in binary releases
19:02:24 * FLHerne hasn't really looked through the in-game list when not trying to find something specific
19:02:28 <Rubidium> (also why they're not mentioned on openttd's main site)
19:03:31 <Rubidium> except persian; basically it lists everything between 100 and 1000 untranslated strings
19:04:56 <FLHerne> That reminds me - a setting to have station names in a different language to the GUI would be nice :-)
19:06:01 <FLHerne> Atm, I end up with daft naming like 'Koln Heights' unless the entire game is in German
19:06:36 <Rubidium> also, all languages with more than 25 missing strings show a warning (in testing/trunk releases)
19:07:27 <Rubidium> but given the fact that things are getting worse... maybe removing the 'release' check is worth it to get a few more translators
19:14:24 *** andythenorth has joined #openttd
19:25:54 <andythenorth> so make can’t automagically build the graph for my project? o_O
19:26:37 <glx> it does it in this step :)
19:31:52 <andythenorth> there must be python libraries for building dep graphs
19:33:09 *** luaduck_zzz is now known as luaduck
19:38:07 <frosch123> andythenorth: write a script that uses "strace" to log which files are accessed by which command :)
19:39:22 <andythenorth> what is a good strategy for deciding a dep has changed?
19:39:32 <planetmaker> modification time of file
19:39:49 * andythenorth looks at current method
19:40:24 <andythenorth> currently the compile stores mod. date of every dep in a json file
19:40:43 <andythenorth> then during next compile, I see if the file changed
19:40:53 <andythenorth> I wondered instead about checking the generated file
19:41:06 <andythenorth> if the generated file is older than the dep, or doesn’t exist, it needs building
19:41:18 <planetmaker> I'm really expecting py-make soon :)
19:41:55 <andythenorth> I am still +1 to converting more of this to make
19:42:10 <Alberth> depending on what that means, it may already exist; there are several python-based make derivatives, afaik
19:42:10 <andythenorth> I am certain the python compile can be split into components that make can call
19:42:32 <andythenorth> but I made no real progress with make, and I made progress with python :P
19:43:27 <andythenorth> goal “Allow writing some complicated build logic directly in Python instead of in shell.”
19:44:15 <Alberth> buildbot explicitly dropped that idea
19:44:39 <Alberth> but it may be a bit different in that case
19:45:23 <Alberth> they do not allow complicated build stuff in the build, judging that a project should also be buildable without advanced build magic
19:45:24 <andythenorth> can’t find a github project for it
19:45:46 *** oskari89 has joined #openttd
19:46:02 <Alberth> so they advocate having scripts as part of the project to store the magic
19:50:29 <andythenorth> I am a bit confused about the goal
19:51:01 <andythenorth> L143, L148, L154 show different build steps
19:51:15 <andythenorth> should I be trying to split those up and have make perform each one?
19:52:20 <Alberth> or combine them in one rule
19:53:10 <Alberth> but two separate rules is fine too
19:53:22 <andythenorth> currently that is the case
19:53:41 <andythenorth> I am a bit unsure of my aim
19:53:49 <andythenorth> basically I wanted to do it in make because make is correct
19:53:51 <Alberth> I mean pnml ... -> nfo in make
19:53:54 <andythenorth> and python is obviously wrong
19:54:42 <Alberth> ie the nml is just an intermediate file that you don't use for anything but the next step,right?
19:55:00 <andythenorth> and the pnml too
19:55:05 <andythenorth> they aren’t deps
19:55:28 <Alberth> handling build command dispatching in python is sub-optimal, I agree :)
19:55:51 <andythenorth> what’s actually wrong with it?
19:56:09 <andythenorth> - the multiprocessing pool could be dropped
19:56:23 <andythenorth> - the dep check I’m about to write is probably unreliable?
19:56:29 <andythenorth> - I’m reinventing the wheel?
19:56:53 <Alberth> python is a sequential general purpose programming language
19:57:12 <Alberth> you normally write input-compute-output code with it
19:57:50 <Alberth> and let the environment decide what to call in which order
19:59:00 <Alberth> you can also split build management and processing, basically writing your own dispatch program, so it becomes general purpose and re-usable
19:59:10 <Alberth> but make would be simpler probably
19:59:36 <Alberth> are your rules for dependencies that complicated?
19:59:56 <andythenorth> no comparable experience
20:00:05 <andythenorth> in any case, make won’t be able to figure them out
20:00:12 <planetmaker> dep rules for NewGRFs are a bit of a pain, when you want to put it into hard-written rules
20:00:13 <andythenorth> so I’ll have to write the dep checks
20:00:26 <andythenorth> I was hoping make was more magic
20:00:32 <planetmaker> it's easy to do the human way: getting all graphics. attaching them to items. And building a manual dep from that
20:00:37 <planetmaker> doesn't need updating too often
20:01:01 <Alberth> too many different ways to make one thing depend on another
20:01:17 <planetmaker> andythenorth, make does not help at all in figuring out the dependencies. You have to tell it about each dep
20:01:30 <andythenorth> I feel mis-sold :P
20:01:37 <Alberth> you cannot write a simpler text generator, based on a list of industries or so?
20:01:46 <andythenorth> Alberth: pretty trivially I could
20:01:53 <planetmaker> it helps you build the thing when you know the dependencies. And helps you re-build only what's needed.
20:02:07 *** FLHerne has joined #openttd
20:02:13 <andythenorth> the compile is already running from a list of industries
20:02:20 <Alberth> andythenorth: why not use that?
20:02:20 <andythenorth> so I could instead output a text file from that
20:02:27 <andythenorth> and then make could use that for deps
20:02:27 <planetmaker> thus it's of great help for partial compiles. When you tell it what depends on what
20:02:34 <andythenorth> and then call the compile script, passing the industry it wants
20:02:39 *** Myhorta has joined #openttd
20:02:44 <Alberth> unless you pattern is so simple you can code it in a make rule
20:03:29 <andythenorth> so make -> compile.py -> text -> make -> compile.py -> output
20:03:33 <Alberth> dep check is more useful if you don't actually know the dependencies, and have to find them by examining the source
20:04:42 <Alberth> nah, just make a script that generates deps in make format, and make that file dependent on all source files
20:05:35 <Alberth> when the depfile is out of date, because you touched a source file, make will detect it, run the script, and reload the depfile
20:05:47 <andythenorth> I’d probably just wrap that up in a compiler module, and pass an arg for which method to run
20:06:11 <andythenorth> compiler -> nfo, compiler -> deps etc
20:06:11 <Alberth> the only weird things is that it will also do that on "make clean" for example
20:06:20 <andythenorth> the compiler knows about all the deps
20:07:26 <Alberth> the alternative is to throw the compiler code in a package, and import that from two #!/bin/env python script files
20:07:35 <Alberth> but either solution is ok
20:08:00 <Alberth> hmm /usr/bin/env even
20:08:00 <andythenorth> so to be sure I’m not smoking crack....
20:08:12 <andythenorth> giving make the deps list will let make know whether to call the compiler
20:08:23 <andythenorth> make will handle checking for changed files, and I can drop that bit from the compiler?
20:09:03 <andythenorth> and if I give (for example) make -j14, it will spawn 14 threads, and I can ditch the multiprocessing pool?
20:09:34 <Alberth> within the capabilities of parallelizing of make sub-shells
20:09:58 <andythenorth> multiprocessing pool bombs horribly if a pool thread encounters an error
20:10:19 <andythenorth> and I am forcing 16 threads, which may be inappropriate for some environments
20:10:22 * planetmaker experienced that once :P
20:10:33 <Alberth> obviously, if you need to build one file first, there is nothing else you can do
20:10:52 <andythenorth> wrapping scripts around a compiler package is the way to do this
20:11:07 <andythenorth> it’s kind of going in that direction anyway
20:11:26 <Alberth> and there were some problems with parallel builds in different directories iirc, but no idea what the state is nowadays
20:11:38 <andythenorth> I could try it and find out :P
20:11:59 <Alberth> your argument thingie is fine too, it doesn't make a huge difference
20:12:08 <andythenorth> it’s important that all the pnml is built before any scripts try the nml step
20:12:15 <Alberth> except perhaps more separated use of code
20:12:39 <andythenorth> does make wait for a rule to complete in all threads before trying next rule?
20:13:04 <planetmaker> it waits for the dependencies of a target to be finished
20:13:12 <Alberth> only if it has a single dependency that needs to be build
20:13:40 <planetmaker> thus I have the phony targets which eddi so despises
20:13:50 <planetmaker> you can have e.g. pnml depend on all pnml files
20:14:06 <andythenorth> so I need to really break out the steps
20:14:43 <planetmaker> and then and nml depend on pnml and all nml files
20:15:16 <andythenorth> have we got any examples of deps being output?
20:15:24 <andythenorth> CETS does I guess
20:15:40 <planetmaker> well. the normal makefile does
20:15:53 <planetmaker> grf -> lng, nml -> pnml
20:16:06 <andythenorth> how outdated is the FIRS makefile?
20:17:25 <planetmaker> somewhat, I guess. But not entirely sure
20:18:59 <planetmaker> hard to say. 2013-09-04 seems to be the date
20:19:12 <planetmaker> or 0.3.0 of make-nml
20:19:45 <planetmaker> which is a year ago. So... well. could get an update. But not critical, I think. Though there's a lot of commits in make-nml since
20:20:03 <planetmaker> just checkout make-nml and copy the Makefile from that repo to FIRS and see?
20:21:08 <planetmaker> hm... with the phony targets like grf, pnml, nml there's some changed handling of those
20:21:22 <planetmaker> all my arguments might have been based on a slightly different Makefile than FIRS uses
20:21:26 <andythenorth> planetmaker: is there a make-nfo any more?
20:21:53 <planetmaker> though chips has it basically
20:22:10 <planetmaker> the make-nml can easily be adopted to nfo
20:22:20 <andythenorth> just seems I’m mangling it a bit
20:22:21 <planetmaker> though I don't want to put it in there
20:22:36 <andythenorth> no, I’m not suggesting you mix them :)
20:22:37 <planetmaker> too much generalisation leads to too much pain :)
20:23:26 <andythenorth> quitting while I’m ahead :P
20:23:31 <andythenorth> at least it compiles right now
20:24:25 <andythenorth> no major structural changes?
20:24:35 <planetmaker> that's the full diff, yes. No fundamental change, no
20:24:59 <Eddi|zuHause> which idiot programmed this minecraft? "it supports åäö" they say. but then it doesn't support ß...
20:25:09 <planetmaker> but the handling of nml / pnml phony targets differs. so it matters
20:26:15 <andythenorth> is that a diff against current FIRS tip in default?
20:26:56 <andythenorth> some of the phony target differences might be due to bad changes I made?
20:27:12 <andythenorth> I still don’t really understand what I’m doing
20:27:18 <andythenorth> I just change stuff until something works
20:27:41 <planetmaker> dunno. But those look like ones I might have made in make-nml as well
20:27:45 <Eddi|zuHause> everyone does that. the question is which level of nothing you understand
20:28:12 <andythenorth> are there countable and uncountable nothings?
20:28:39 <Eddi|zuHause> but nobody knows if there's something inbetween
20:29:11 <andythenorth> there’s probably nothing inbetween
20:29:21 <andythenorth> is nothing something?
20:29:34 <andythenorth> hmm, it’s like year 2 philosophy all over again :P
20:29:47 <planetmaker> oh, andythenorth, please adjust .hgignore. It's aweful, all those generated files spamming hg st
20:30:26 <andythenorth> planetmaker: I added generated/ yesterday or so
20:30:30 <andythenorth> is that not working for you?
20:30:36 <planetmaker> nope. I just built tip
20:31:03 <andythenorth> does it need generated/* ?
20:31:05 <planetmaker> you added generated/ but not generated/* as you wanted ;)
20:31:14 <planetmaker> it's set to glob. Not to regex
20:31:33 <andythenorth> translations/ is also wrong, but deprecated anyway
20:32:13 <planetmaker> well. I could fix it, I guess
20:32:26 <andythenorth> I pushed a change
20:32:35 <andythenorth> not all of them though
20:32:51 <andythenorth> you have firs.nfo in root?
20:34:42 <planetmaker> yup. But I'll try a clean repo and see what I get
20:35:00 <planetmaker> and push a commit to ignore everything hg st shows afterwards :)
20:35:26 <planetmaker> hg purge --all for the win. Destroys all work if not committed :P
20:39:06 *** dotwaffle has joined #openttd
20:43:30 *** jpierre03_ has joined #openttd
20:50:10 *** KWKdesign has joined #openttd
21:07:20 *** FLHerne has joined #openttd
21:08:07 *** FLHerne_ has joined #openttd
21:11:20 *** Myhorta has joined #openttd
21:36:33 *** jpierre03 has joined #openttd
22:07:06 *** Supercheese has joined #openttd
22:45:32 *** bdavenport has joined #openttd
22:46:26 *** zeknurn has joined #openttd
23:04:29 *** shirish has joined #openttd
23:27:15 *** Flygon_ has joined #openttd
continue to next day ⏵