IRC logs for #openttd on OFTC at 2014-01-18
⏴ go to previous day
00:39:51 *** Midnightmyth has joined #openttd
01:48:03 *** gelignite_ has joined #openttd
01:58:59 *** HerzogDeXtEr has joined #openttd
02:32:26 *** Supercheese has joined #openttd
02:44:56 *** HerzogDeXtEr1 has joined #openttd
04:13:03 *** retro|cz has joined #openttd
05:22:57 *** Guest4148 has joined #openttd
05:56:16 *** Eddi|zuHause has joined #openttd
06:18:16 *** andythenorth has joined #openttd
06:34:23 *** Randominty has joined #openttd
06:50:38 *** Flygon_ has joined #openttd
06:52:45 *** sla_ro|master has joined #openttd
07:43:05 *** andythenorth has joined #openttd
08:04:16 *** andythenorth has joined #openttd
08:40:24 *** kais58 is now known as kais58|AFK
08:40:29 *** kais58|AFK is now known as kais58
08:42:33 *** Pensacola has joined #openttd
08:47:59 <andythenorth> this pixa stuff isn't crap
08:48:02 <andythenorth> it's just a bit mental
08:58:11 *** valhallasw has joined #openttd
09:08:02 <andythenorth> if you saw a codebase with pipelines and modules, what would you think their relationship was?
09:11:40 *** Midnightmyth has joined #openttd
09:16:55 *** oskari89 has joined #openttd
09:38:05 *** Progman has joined #openttd
09:38:28 *** andythenorth has joined #openttd
09:52:27 *** Alberth has joined #openttd
09:52:27 *** ChanServ sets mode: +o Alberth
10:02:07 <andythenorth> Alberth: does it sound like bad style to have a package called 'graphics_modules' :P
10:02:14 <andythenorth> it does strictly, tbh, contain modules
10:03:05 <Alberth> i'd probably call it "graphics" or so, but the name is not so bad imho
10:03:26 <andythenorth> it's kind of conflating modules
10:03:35 <andythenorth> I have a graphics pipeline, which is modular
10:03:56 <andythenorth> the modules happen to be implemented as python modules, which is a coincidence ;P
10:04:20 <andythenorth> I can't find a synonym for module
10:04:31 <Alberth> I have no problems with modules containing other modules, without giving meta-names, but I do a lot of recursive programming
10:05:45 <Alberth> you can also see it as a module providing you graphics. That is uses modules on its own is purely internal
10:07:32 <Alberth> but if you prefer to see it as a collection of graphics-thingies, that's a valid viewpoint as well
10:08:27 <andythenorth> I dislike naming confusions :)
10:08:32 <andythenorth> but I am short on words
10:08:38 <andythenorth> so graphics_modules will do
10:10:32 <andythenorth> I could call it 'arbitrarily_combinable_modular_graphics_processing_pipeline_components'
10:13:05 <Eddi|zuHause> just name them X, XX, ...
10:13:31 <Eddi|zuHause> i probably still have a disk with files like that :p
10:16:07 <andythenorth> I have employed people who name their variables 'a', 'b', 'c' etc
10:16:51 <andythenorth> because 'long variable names run slower'
10:18:47 <Eddi|zuHause> and if a black cat crosses your screen your program crashes?
10:21:48 <andythenorth> it was mostly flash actionscript, so quite plausibly yes
10:53:20 *** Extrems has joined #openttd
11:24:30 <andythenorth> improved auto-road construction - show the direction of build?
11:30:06 <Alberth> you can drive faster when you move in the same direction as it was built? :)
11:30:37 <Alberth> afaik we cheat, road and tracks are always laid in the same direction, no matter where you start or end
11:34:18 <Eddi|zuHause> <andythenorth> improved auto-road construction - show the direction of build? <-- someone posted sprites for roadbit highlighting on the forum, but nobody ever coded it
11:58:08 <andythenorth> ugh three levels of directory nesting
12:02:17 *** montalvo has joined #openttd
12:26:06 *** retro|cz has joined #openttd
12:32:05 *** Supercheese has joined #openttd
13:12:22 <andythenorth> maybe I've fork-bombed python :P
13:13:29 *** Djohaal has joined #openttd
13:14:36 *** Aristide has joined #openttd
13:14:57 <andythenorth> or maybe it just takes a long time to count to 999999999
13:18:12 <andythenorth> hmm. For an IO task (writing spritesheets to disk), is there likely to be negligible benefit from using MultiProcessing library?
13:18:17 <andythenorth> or does that depend on my OS and crap
13:19:13 <andythenorth> I guess it can't do any harm :P
13:19:26 <andythenorth> unless it blocks in some horrible unanticipated way, but I doubt it's significant
13:24:38 <Alberth> unless you write big data, you're mostly just filling disk cache which is kept in memory, so writing is quite fast
13:24:51 <Alberth> assuming you don't use a synchronized file system :p
13:28:09 <andythenorth> seems to work fine :P
13:33:55 <andythenorth> what did I do :)
13:34:13 <andythenorth> Pikka: for shame, one thing I did was cheat at Euro Truck Simulator
13:34:35 <Pikka> how can you cheat at euro truck simulator?
13:35:14 <Pikka> and I don't know what you did, but "seems to work fine :P" sound like famous last words
13:37:09 <andythenorth> I cheated money, I got bored
13:38:19 <Pikka> but the point of the game is to drive the truck... money is irrelevant D:
13:38:55 <andythenorth> child number 1 wanted a bigger truck ;)
13:39:12 <andythenorth> and we got a €48,000 fine on one delivery
13:39:27 <andythenorth> there were a few crashes
13:39:49 <andythenorth> I am hoping they do mac ETS 2 this year :P
13:39:52 <andythenorth> they promised it
13:40:01 <andythenorth> meanwhile, back to spriting :P
13:40:35 <Pikka> I realised just how many files my project is going to generate, so my task for the morning is making some kind of meaningful directory structure... fun.
13:43:21 *** frosch123 has joined #openttd
14:08:34 <andythenorth> Pikka: I like him
14:08:39 <andythenorth> also, you can do donuts in ETS
14:08:43 <andythenorth> it's not that fun though
14:09:13 <andythenorth> # check for __main__ because fork bombs are bad
14:09:14 <andythenorth> if __name__ == '__main__':
14:09:25 <andythenorth> but that means my code doesn't work when called from another module
14:11:17 <scshunt> why would checking for __main__ stop forkbombs?
14:22:53 <Xaroth|Work> if you don't do that
14:22:57 <Xaroth|Work> and that file gets included by something
14:23:02 <Xaroth|Work> your code will be executed
14:23:15 <Xaroth|Work> multiprocessing tends to load files, even if they aren't the intended run-file
14:23:20 <Xaroth|Work> which can cause issues
14:28:26 <andythenorth> so what's the correct thing to do?
14:28:34 <andythenorth> I need to import this module into another module
14:29:05 <Xaroth|Work> use if __name__ == '__main__' for the entrypoint of your software
14:29:09 <Xaroth|Work> where you do like ./main.py run
14:29:13 <Xaroth|Work> main.py needs that line
14:29:22 <Xaroth|Work> as long as they don't execute stuff by themselves
14:29:35 <andythenorth> so if other people come along and change stuff, and they miss the guard, that's their problem
14:30:02 <Xaroth|Work> the guard is only there to make sure that code doesn't run when you import it
14:30:14 <Xaroth|Work> they can always circumvent it by doing whatever is after the if themselves after they import
14:30:24 <Xaroth|Work> it's common practice that people call a main() function in that if
14:30:31 <Xaroth|Work> so it's still importable and runnable if that is wanted
14:30:38 <Xaroth|Work> it just doesn't do anything by itself
14:33:30 <andythenorth> so I call the module with the MP stuff with
14:33:33 <andythenorth> import render_graphics
14:33:39 <andythenorth> so I should wrap that in the guard?
14:33:52 <andythenorth> or I have to fuck around with a main() function in render_graphics?
14:34:41 *** tokai|mdlx has joined #openttd
14:35:11 <Xaroth|Work> I would say a main() function
14:39:10 <andythenorth> so if I have 50% of the functionality wrapped in main(), how do I run the script directly?
14:39:22 <andythenorth> currently I used python src/render_graphics.py
14:39:50 <andythenorth> which now fails to do 50% of what's needed
14:42:45 <Xaroth|Work> if you have the if __name__ == "__main__": thing
14:42:49 <Xaroth|Work> python path/to/file.py
14:43:15 <Alberth> or make it executable with a #!/usr/bin/python :)
14:44:02 <andythenorth> it already has a hash bang
14:44:22 <andythenorth> I had to add if __name__ == '__main__': main()
14:44:36 <andythenorth> which seems like excessive beauracracy
14:47:09 <Alberth> just main() will do, if you never want to import the file
14:47:30 <andythenorth> I do want to import it :)
14:47:54 <andythenorth> if I just do main() then I think I just have Even More Code, with the same fork bomb problem :(
14:48:35 <Alberth> then you're stuck with excessiveness, or you make a new file: from foo import main; main()
14:49:16 <andythenorth> I think I'll do without that
14:49:36 <andythenorth> as I don't understand the fork bomb issue, I'll just live with the excess stuff
14:50:25 *** Tom_Soft has joined #openttd
14:52:04 *** sla_ro|master has joined #openttd
14:54:09 <andythenorth> hg merges are non-functional
14:54:13 <andythenorth> just don't do them
14:54:46 <planetmaker> andythenorth, how are they 'non functional'?
14:55:12 <andythenorth> they are hopeless at resolving conflicts
14:55:30 <andythenorth> and the lack of stash makes it trivial to get into a conflict
14:55:50 <andythenorth> the process for marking a merge complete makes no sense to me
14:55:52 <planetmaker> s/lack of stash//
14:57:12 <andythenorth> maybe git has made me use version control non-defensively :(
14:57:47 <andythenorth> hg makes it harder to get into 'omg what have you done to the repo'
14:58:00 <andythenorth> but git workflow is much more productive imho
14:58:56 <planetmaker> andythenorth, you might want to use a different merge tool maybe?
14:59:10 <planetmaker> also there's histedit and rebase...
14:59:18 <planetmaker> and there is hg shelve
14:59:29 <planetmaker> to temporarily shelve your outstanding changes
15:00:21 <andythenorth> hg shelve looks handy o_O
15:02:03 <Alberth> I just make a new clone for every shelve
15:02:16 <planetmaker> I simply commit and update to the previous rev
15:02:33 <planetmaker> (and maybe add a bookmark)
15:02:41 <planetmaker> before updating to the previous rev
15:02:56 <andythenorth> I upped to a previous rev to check something, and screwed myself :P
15:03:08 <planetmaker> don't do that with outstanding changes
15:03:23 <planetmaker> merging graphics usually is a big pita
15:03:28 <andythenorth> it's hard to remember the right thing to do when you work with 3 different vcs
15:03:48 <andythenorth> I could install git -> hg front end, but I've heard they suck :P
15:04:06 <andythenorth> it's even worse with svn
15:04:17 <andythenorth> I try and totally avoid having to do any work on svn repos now
15:04:22 <planetmaker> hg -> git is also not exactly excellent
15:04:31 <andythenorth> "commit" is thoroughly likely to get me yelled at with svn
15:04:38 <planetmaker> hgsubversion (or was it hgsvn?) is quite ok
15:04:42 <Alberth> I use svn -> hg for making a local copy of the svn repo
15:19:26 *** Superuser has joined #openttd
15:19:28 *** retro|cz has joined #openttd
15:30:36 *** ChanServ sets mode: +v tokai
15:33:46 *** tokai|mdlx has joined #openttd
15:43:08 * andythenorth wonders when the overhead of starting python MP processes outweighs the benefits...
15:44:19 <Alberth> that's easy, when a single process is faster than a MP implementation
15:44:57 <Alberth> if you think in terms of programming effort, the balancing point is earlier
15:45:28 <andythenorth> I guess it's empirical then :P
15:46:17 <Alberth> it's not even constant at a single machine :)
15:46:35 <Alberth> `git co' is aliased to `checkout' <-- git is soooo helpful at times :)
15:47:15 <andythenorth> I am a convert to git
15:47:19 <andythenorth> it's obviously mad
15:47:24 <andythenorth> but it seems to work
15:47:40 <Alberth> depends on your definition of "work"
15:47:59 <Alberth> people also claim to be productive with a windows machine
15:48:07 <andythenorth> I've even met some
15:48:33 <Taede> does it count if i edit code on windows, but execute it in linux?
15:49:32 * Alberth wonders whether to start about productivity and editors
15:55:29 *** Flygon_ is now known as Flygon
15:55:49 <Flygon> I've worked with Mega Drive devs who dev on Win7 64-bit and Macs
15:55:57 <Flygon> To compile software for execution on the Mega Drive
15:56:16 <Flygon> Getting decent 68k compilers for Apple OS's is a huge pita though
15:58:10 <DorpsGek> andythenorth: 0.666666666667
15:58:17 <andythenorth> a bit faster with MP
16:08:18 <andythenorth> puzzling results
16:08:51 <andythenorth> if I run src/render_nml directly, templating takes 20s with MP, and 13s without
16:09:14 <andythenorth> if I run the makefile, which calls it via a chain of stuff, I get 8s instead of 12s
16:09:49 *** Djohaal_ has joined #openttd
16:11:20 <andythenorth> resulting puzzles
16:11:50 <planetmaker> Pikka, your new engines: can you make them look a bit more used?
16:12:25 <planetmaker> they look so clean :)
16:14:18 * andythenorth waves hands at anyone who knows how to python profile
16:14:24 <andythenorth> these results are odd
16:14:53 <Pikka> :o maybe, planetmaker. but given the size of the sprites you want them to be *reasonably* clean. noise will obscure the shapes.
16:17:26 <planetmaker> Pikka, I don't mean in a shape-obscuring way. Just more real-coloured (yes, I know, the bad r-word)
16:20:46 *** tokai|mdlx has joined #openttd
16:26:01 <frosch123> i think except for the pink, yellow and white one they look already quite dirty
16:26:40 <frosch123> dirt is only visible on bright colours
16:27:27 <planetmaker> oh, I also didn't see today's image
16:28:27 <Pikka> that bright spot on the corner of the roof is annoying me, I've removed it and am re-rendering, whee.
16:28:53 <Pikka> it wasn't as visible on the grey roof as it is on the black ones
16:36:02 <andythenorth> anybody care to school me in inter-process communication with python MP library?
16:36:10 <andythenorth> actually I could just write files to disk and join them :P
16:47:12 <planetmaker> isn't the roof a bit dark, Pikka ?
16:47:26 <planetmaker> especially with some colours?
16:47:41 <Pikka> I don't think so? Roofs should be dark, shouldn't they?
16:48:30 <planetmaker> dunno. I thought they were rather metal-ish
16:50:14 <Pikka> even metallish ones get dark when they're dirty. ;) but yeah.. the "some colours" have black roofs, and the others have metal ones
16:50:40 <Pikka> which are the same colour as, eg, the stripe on the side of the dark blue carriage, so if they look dark that'll be down to the lighting. :P
16:51:28 *** ChanServ sets mode: +v tokai
16:52:37 <planetmaker> ah, ok, so that's intended :)
16:52:44 *** DarkAceZ has joined #openttd
16:58:59 *** tokai|mdlx has joined #openttd
16:59:47 *** gelignite has joined #openttd
17:25:51 * andythenorth profiling hamfistedly
17:27:58 <andythenorth> think I'm about to get schooling about mult-processing problems
17:44:05 *** valhallasw has joined #openttd
17:48:22 <andythenorth> lack of environment vars :(
18:02:53 *** Cybertinus has joined #openttd
18:24:43 <andythenorth> I can't get the template engine to see the fricking cache directory when I run a module directly
18:24:59 <andythenorth> but it will see it when the module is called from another module
18:25:14 <andythenorth> some os.environment thing that I don't understand :(
18:26:01 <Alberth> what did you want to have refactored andy?
18:29:51 *** tokai|noir has joined #openttd
18:29:51 *** ChanServ sets mode: +v tokai|noir
18:38:57 <andythenorth> Alberth: biab - bath time
18:39:06 <andythenorth> although this environment var stuff is bugging me :)
18:39:55 <andythenorth> Alberth: do you have a checkout of IH?
18:45:18 <DorpsGek> Commit by translators :: r26264 trunk/src/lang/danish.txt (2014-01-18 18:45:12 UTC)
18:45:19 <DorpsGek> -Update from WebTranslator v3.0:
18:45:20 <DorpsGek> danish - 75 changes by Elyon
18:48:54 <andythenorth> Alberth: run src/build_iron_horse.py and watch the chameleon_cache dir fill...
18:49:04 <andythenorth> then clear the cache dir, and run src/render_nml.py
18:49:38 <andythenorth> for me, it doesn't produce any cache files
18:49:53 <andythenorth> the cache is an os.environment setting, which is set by iron_horse.py
18:50:02 <andythenorth> I've tried setting it in every file, but to no avail
18:51:13 <Alberth> do you use python2 or python3? i have 2 python-chameleon packages
18:53:39 *** Djohaal has joined #openttd
19:14:55 *** fjb is now known as Guest4187
19:22:24 *** andythenorth has joined #openttd
19:22:35 <andythenorth> I seem to have got bounced out :P
19:22:41 <Alberth> andythenorth: I have that too
19:22:58 <andythenorth> the same chameleon behaviour?
19:25:58 <Alberth> wouldn't chameleon read such a variable when importing chameleon?
19:26:56 <andythenorth> I would have thought so
19:27:06 <Alberth> src/iron_horse.py sets the os.environ['CHAMELEON_CACHE'] = chameleon_cache_path
19:27:44 <Alberth> src/render_nml.py import chameleon without setting that env var
19:28:07 <andythenorth> but it has imported iron_horse
19:28:16 <andythenorth> as does build_iron_horse.py
19:28:41 <andythenorth> I have just made a test
19:28:42 <Alberth> it imports iron_horse later
19:30:07 <Alberth> line 15, after line 11
19:30:22 <andythenorth> I am making a test of that too :)
19:30:49 <andythenorth> yeah changing the import order solves it :)
19:31:37 <Alberth> interesting programming style, using import as subroutine call :)
19:31:53 <andythenorth> using MP saves 5 or 6 seconds
19:32:00 <Alberth> too bad you can only run each file once :)
19:32:03 <andythenorth> it will save more proportionally as the set grows
19:32:26 <andythenorth> Alberth: I could convert them all to have a main() :P
19:32:34 <andythenorth> kind of works though :P
19:32:53 <Alberth> yeah, it's an interesting technique :)
19:33:44 <andythenorth> kind of dangerous with multiprocessing I guess
19:36:17 <andythenorth> ho I actually save 7 or 8 seconds without a bazillion print statements running
19:36:35 *** Andreas has joined #openttd
19:42:09 *** tokai|mdlx has joined #openttd
19:47:03 *** ChanServ sets mode: +v tokai
19:49:05 <andythenorth> planetmaker: today might be the day I need to add a 'build' dir or such
19:49:17 <andythenorth> I now have generated graphics, and intermediate nml files :P
19:49:24 <andythenorth> does that name make sense?
19:52:08 <frosch123> call it "generated"
19:52:13 <frosch123> easier to understand
19:56:06 *** Andreas has joined #openttd
20:08:02 *** oskari89 has joined #openttd
20:10:41 <andythenorth> I should move the generated lang in there
20:10:44 <andythenorth> and tell nml about it
20:12:15 <planetmaker> hm. you can define NML_FLAGS in Makefile.config and declare there a different lang dir
20:12:27 <planetmaker> Remember to also tell eints about different dir
20:12:37 <planetmaker> hm... that doesn't need a different dir as it doesn't change, yes?
20:14:50 <andythenorth> I could just leave it as is
20:15:07 <andythenorth> I would be happier if everything generated was in one location, but it could be a tidy mind problem
20:15:12 <andythenorth> no real-world issue
20:15:37 <planetmaker> suggestion: move the code thing first. And try that
20:15:52 <planetmaker> if that works: you can tidy your mind and try the lang move :)
20:16:06 <planetmaker> tidy structures don't hurt
20:16:24 <planetmaker> and NML_FLAGS purpose lies in exactly this reason...
20:18:03 <andythenorth> nml is done, doing graphics now
20:18:23 <andythenorth> I've left the final iron_horse.nml in root dir
20:18:46 <planetmaker> yes. That's makefile's default assumption
20:24:07 <andythenorth> planetmaker: I think for FIRS eints must already know about lang_src?
20:24:22 <andythenorth> Iron Horse sorry
20:26:40 <planetmaker> might be, yes. In .devzone/translations you can define that
20:27:51 <andythenorth> so I could sort that out and get rid of this ugly lang_src pattern
20:28:11 <andythenorth> graphics are done :)
20:34:15 *** Devroush has joined #openttd
20:35:42 <andythenorth> do I want to face down changing the lang :P
20:36:15 <andythenorth> presumably there's a makefile flag somewhere
20:37:25 <andythenorth> planetmaker: do NML_FLAGS need specified in Makefile.config ?
20:37:50 <planetmaker> no. But if you need something special, then you can re-define it
20:38:04 <planetmaker> By default it is defined as -c
20:39:04 <andythenorth> so to change lang dir...
20:39:57 <planetmaker> -c --lang-dir=PATH
20:40:14 <planetmaker> you should keep the -c. You'll overwrite it, it doesn't append
20:54:24 <andythenorth> planetmaker: that just leaves docs_src :)
20:54:32 <andythenorth> which I don't like :P
20:55:12 <andythenorth> graphics_sources is valid I think
20:55:35 <planetmaker> what's wrong with docs_src?
20:55:55 <andythenorth> nothing much, except the result is generated into /docs
20:56:02 <andythenorth> so then confusion arises :)
20:56:08 <planetmaker> instead of generated/docs?
20:56:13 <andythenorth> shall I move it there?
20:56:24 <andythenorth> I think docs are properly separate to grf, so /docs_src is valid ish
20:56:34 <andythenorth> I don't know what bundles does to expose it
20:56:52 <andythenorth> probably something simple
20:57:06 <planetmaker> well, I've some rules there as to what to copy
20:57:13 <planetmaker> that can be adopted
20:57:19 <planetmaker> and/or more generalized
20:57:47 <planetmaker> it's currently from docs: html, license.txt, readme.txt, changelog.txt
20:58:26 <andythenorth> it's controlled in .devzone/build/files afaict
20:58:54 <andythenorth> not sure how we'd mangle the path though
20:59:20 <planetmaker> for f in `ls -d *.zip *.gz *.nml *.nfo *.md5 *.txt lang docs/*.txt docs *.ob?`; do cp -r $f build; done
20:59:31 <planetmaker> ^ that's the files which I copy to bundles
21:00:23 <planetmaker> I'm aware that I copy the txt in docs twice. That's intentional
21:00:37 <andythenorth> shall I move the docs into generated and we see what happens? o_O
21:01:07 <planetmaker> I know that they won't be published unless I change the rules for bundle server :)
21:01:20 <planetmaker> but I can add that
21:03:08 <Alberth> everybody is committed
21:06:18 <Pikka> or at least they should be
21:08:51 <andythenorth> the makefile is sulking about docs path being wrong
21:08:56 <andythenorth> maybe I should leave this one be
21:10:05 <andythenorth> iirc something blows up if I comment the docs lines in Makefile.config
21:13:05 <andythenorth> hmm 'graphics' could go back into 'src' where I think it belongs
21:14:21 <planetmaker> no shit, trying to build iron-horse completely rendered my system unresponsive to all kind of input including external ssh access :S
21:15:11 <andythenorth> it hasn't brought down devzone?
21:15:34 <andythenorth> did it come back?
21:15:46 <planetmaker> I hard reset after two minutes
21:16:00 <andythenorth> that is umm...a problem
21:16:10 <andythenorth> it blocks CPU quite hard on my mine, for 10s or so
21:16:32 <andythenorth> planetmaker: it's not running windows?
21:16:50 <planetmaker> I'm used to allowing additional cores by using -jX. So make should use one core unless allowed differently
21:17:48 <planetmaker> they keyboard num led would still toggle :P
21:20:10 <andythenorth> I wonder why it does that :P
21:20:18 <andythenorth> it spawns 61 processes, not 1000s
21:20:30 <andythenorth> although I might have to go learn about pools
21:24:38 <planetmaker> devzone is not harmed as the VMs are CPU - limited and nothing is harmed when the build VM uses all of its CPU. So no worries there
21:26:15 <andythenorth> I might have a new version soon if you dare :P
21:26:55 <andythenorth> it's marginally faster for some reason :P
21:27:00 <andythenorth> despite fewer processes
21:27:10 <andythenorth> maybe there's an overhead to having 61 processes running :P
21:27:32 <planetmaker> definitely. No point to run more processes than there are CPUs
21:27:56 <andythenorth> planetmaker: I've just pushed one that is limited to 16
21:28:09 <andythenorth> doesn't block my laptop now either
21:29:41 <planetmaker> 534:fc9905f20ecc ?
21:30:22 <andythenorth> same hash, my rev is 533
21:30:41 <planetmaker> not odd. I might have used amend somewhen or so
21:30:57 <planetmaker> numeric revs are local only
21:31:27 <skyem123> Jenkins thinks it is 532
21:31:35 <planetmaker> see you in a minute, maybe :P
21:32:38 <planetmaker> but... didn't build the grf :P
21:33:22 <planetmaker> couldn't generate docs/license.txt
21:33:40 <planetmaker> let's purge and re-try
21:33:46 <andythenorth> did it generate a docs folder?
21:34:06 <planetmaker> seems to work after purge
21:34:45 <andythenorth> I am going to move lang into src I think, and tell eints about it
21:34:49 <planetmaker> I'd say built in 5 seconds or so
21:35:01 <planetmaker> that's pretty good :)
21:35:23 <andythenorth> takes about 20 for me
21:36:09 <planetmaker> all in all it's 17.1s, yes
21:36:32 <andythenorth> not as bad as FIRS :)
21:36:54 <planetmaker> would probably be 2ms faster, if it didn't say 'blah' :)
21:43:15 *** Djohaal has joined #openttd
21:47:27 <skyem123> The makefile doesn't know about the windows "py" command.
21:50:43 <planetmaker> I didn't change a thing, though
21:50:56 <andythenorth> planetmaker: yeah, I didn't change docs yet :)
21:51:04 <andythenorth> it tends to break the makefile in boring ways iirc
21:51:23 <andythenorth> it's not essential
22:00:29 *** Progman has joined #openttd
22:01:45 <andythenorth> handling failing code in multiprocessing is...harder
22:01:55 <andythenorth> the pool seems to eat errors
22:07:01 *** George|2 has joined #openttd
22:07:02 *** George is now known as Guest4202
22:07:02 *** George|2 is now known as George
22:12:48 *** gelignite has joined #openttd
22:17:36 <skyem123> uh oh... When i try to build it on windows, it goes in an infinite loop
22:27:32 <andythenorth> skyem123: iron horse?
22:27:51 <skyem123> A multi tasking one,
22:27:52 <andythenorth> how naughty of it
22:28:03 <andythenorth> there are known issues with multiprocessing on windows
22:28:12 <andythenorth> but I thought I'd done the correct thing to handle it :P
22:28:42 <skyem123> Can you add a disable multitasking option as a failsafe?
22:32:16 <andythenorth> skyem123: which rev / hash?
22:34:52 <skyem123> I'm on a6f658d0807115bec6a815d060528793ff07adbf
22:35:26 <skyem123> In that one the screen output is mutch cleaner.
22:36:34 <andythenorth> I was hopeful that I'd at least limited it to 16 processes, and also prevented the known windows issue
22:36:49 <andythenorth> changeset 7bedb75d28ce
22:43:40 <andythenorth> wonder why it does it :)
22:43:56 <skyem123> I can give you the console output.
22:44:12 <andythenorth> I need someone else to check my python I think
22:46:55 *** FLHerne has joined #openttd
22:46:56 <skyem123> it didn't log everything in the console.
22:47:10 <skyem123> how do i redirect stderror?
22:48:46 <planetmaker> command.sh 2>file
22:49:23 <glx> or 2>&1 to redirect stderr to stdout
22:49:29 <skyem123> 41kb for a few seconds!
22:49:37 <andythenorth> ok that somewhat makes sense
22:49:41 <andythenorth> dunno what to do about it
22:51:23 <skyem123> it seems to be trying to access the output nml file
22:52:25 <andythenorth> what's odd is the repeating of the [BUILD] stuff
22:52:35 <andythenorth> there's no cause for repeating that, it's called once
22:53:23 <skyem123> it does the same thing when i limit the processes to 1
22:53:54 <skyem123> except error about the file
22:54:19 <andythenorth> I think I understand that
22:54:51 <skyem123> so by limiting the processes to 1 it didn't have the file access error
22:57:34 *** Flygon_ has joined #openttd
23:00:10 <andythenorth> skyem123: can you run python files?
23:00:22 <andythenorth> if so, run src/render_nml.py
23:00:53 <andythenorth> should have the same issue
23:06:09 <andythenorth> same issue is good news in this case
23:06:14 <skyem123> it's doing somthing similar but differant
23:06:42 <skyem123> but the loop is still there
23:06:58 <andythenorth> skyem123: edit L 44 - reduce 16 to 1
23:07:07 <andythenorth> might still loop
23:08:09 <skyem123> it does an access is denied error using src/render_nml.py
23:08:31 <skyem123> using make it still loops
23:08:58 <andythenorth> it loops with 16 changed to 1?
23:09:48 <skyem123> (using make command)
23:10:03 <skyem123> with /src/render_nml, no
23:11:39 <skyem123> I think it loops in two places.
23:11:53 <andythenorth> it will also loop in render_graphics
23:12:14 <skyem123> It seems to loop in build_iron_horse
23:12:26 <andythenorth> that is what puzzles me
23:13:47 *** fjb is now known as Guest4205
23:15:31 <andythenorth> I won't solve it tonight :(
23:15:41 <skyem123> is it possible to remove the threading code?
23:16:50 <andythenorth> change 1 line, delete 3 others
23:17:05 <andythenorth> instead of pool.apply_async(render_consist_nml, args=( consist, ))
23:17:27 <andythenorth> use render_consist_nml(consist)
23:17:51 <andythenorth> and then delete the other nearby lines beginning 'pool'
23:18:21 <andythenorth> it will still fail on render_graphics probably
23:19:03 <skyem123> What does the threading DO?
23:19:25 <andythenorth> renders graphics and code faster
23:20:14 <skyem123> how? does it use one theread per module?
23:20:33 <skyem123> with a limit of 16 threads at a time?
23:20:55 <andythenorth> the pool() stuff is pretty much magic
23:21:42 <skyem123> it it getting permission errors
23:22:13 <skyem123> used by another process
23:23:10 <skyem123> is that the graphics erroring?
23:24:23 <planetmaker> sounds like race condtions
23:24:32 <andythenorth> open src/render_graphics.py
23:24:47 <skyem123> remove the pool code?
23:25:08 <andythenorth> shutil.copy(os.path.join(graphics_input, variant.get_spritesheet_name(consist)), graphics_output_path)
23:26:26 <skyem123> you mean to code in:
23:26:32 <skyem123> for variant, consist in variants.iteritems():
23:28:15 <skyem123> Traceback (most recent call last):
23:28:15 <skyem123> File "src/build_iron_horse.py", line 18, in <module>
23:28:15 <skyem123> File "i:\NewGRF Coding\Projects\Iron Horse\src\render_nml.py", line 24, in <mo
23:28:16 <skyem123> os.mkdir(generated_nml_path)
23:28:18 <skyem123> WindowsError: [Error 5] Access is denied: '.\\generated\\nml'
23:28:20 <skyem123> make: *** [iron-horse-nml] Error 1
23:29:10 <skyem123> is it the way you handle filenames?
23:29:15 <andythenorth> does Windows have permissions or something?
23:30:23 <andythenorth> replace generated_nml_path = os.path.join(iron_horse.generated_files_path, 'nml')
23:30:47 <andythenorth> with generated_nml_path = os.path.join(currentdir, 'generated', 'nml')
23:31:02 <andythenorth> shouldn't make any bloody difference :)
23:32:04 <skyem123> it seems to be working. for the nml at least
23:32:17 <skyem123> i THINK i know what is happening!
23:32:42 <andythenorth> if that change fixed it, then it's path issues
23:34:18 <andythenorth> the path throws a permissions error
23:34:36 <andythenorth> and the way windows handles python multiprocessing means it gets thrown over and over again
23:34:42 <skyem123> generated_files_path = os.path.join(currentdir, global_constants.generated_files_dir)
23:36:35 <skyem123> what is global_constants.generated_files_dir?
23:39:52 <andythenorth> it's just a string
23:40:35 <andythenorth> os.path() should be able to join previously joined paths, but maybe it fails
23:41:08 <skyem123> it seems to also have problems if the files already exist in the "generated" folder
23:41:21 <andythenorth> they're supposed to have been deleted
23:41:24 <andythenorth> there's code for that :)
23:41:29 <andythenorth> or run make clean
23:41:35 * andythenorth needs bed, but the path stuff is pretty easy to change if you want to try it
23:41:58 <skyem123> i think the code runs to fast
continue to next day ⏵
