Log for #openttdcoop.devzone on 29th May 2014:
Times are UTC Toggle Colours
01:13:44  *** frosch123 has quit IRC
01:45:06  *** gelignite has quit IRC
04:04:01  *** LSky` has joined #openttdcoop.devzone
06:38:04  <DevZone> Project 2ccts build #129-push: SUCCESS in 1 min 27 sec:
07:12:48  <planetmaker> juzza1, the answer is very simple: your offsets are totally wrong. See for correct ones
07:12:52  <planetmaker> mind the signs
07:14:28  <juzza1> the offsets look good to me, if the mask is not used
07:14:39  <juzza1> my sprite sources are not at all in the same format as pota
07:17:01  <planetmaker> additionally your 8bpp 1x does not correspond to the 32bpp in (scaled) size. That's also a prerequesite
07:18:29  <juzza1> did you check the source for that newgrf
07:18:37  <juzza1> the sprite and mask are of the same size
07:24:37  <planetmaker> yes, they are
07:26:14  <planetmaker> but still your offsets are wrong
07:26:33  <planetmaker> as you don't specify the sprite size, the whole file is used. which is WAY too large for a ground sprite
07:27:30  <juzza1> there is a commented line in test.nml where you can check the tile without the mask, it looks fine to me
07:27:45  <juzza1> and does it matter if the overlapping part is fully transparent?
07:28:03  <juzza1> but i will try without any overlapping parts, even transparent
07:28:36  <planetmaker> also fix it to supply a corresponding 8bpp with *the same relative* offsets
07:29:19  <planetmaker> (in principle the mask sprite can work as that)
07:29:55  <V453000> that looks wtf why dont you just animate the water tile?
07:30:31  <V453000> aka apply the mask in whatever program you use
07:30:42  <V453000> and export png sequence
07:31:03  <juzza1> water tiles can only be animated with action colors
07:31:56  <planetmaker> V453000, water can only be animated by action colours in the 8bpp mask
07:32:16  <V453000> oh god
07:32:53  <V453000> I guess chances that it is going to change are low?
07:33:14  <planetmaker> they're extremely low. Much lower than additional ground tile types
07:33:19  <V453000> y
07:33:31  <V453000> well that is quite bad :D
07:34:09  <planetmaker> though... hm... depends on how it's done, I guess
07:43:31  <planetmaker> juzza1, well, when I fix the offsets, everything works fine
07:44:23  <planetmaker> offsets for a ground tile are -32 0. And not -32 -16
07:45:40  <planetmaker> actually, rather -31, 0
07:47:12  <juzza1> did you change the sprites or code only? and could you paste it somewhere
07:48:08  <juzza1> i cant seem to get it working, removed all the extra from those sprites so that they are 256x127, and now only the top half of the sprites get animated
07:48:23  <juzza1> also changed the offsets
07:48:38  <planetmaker> both
07:49:01  <planetmaker> on closer inspection the top half, yes
07:49:20  <planetmaker> but I didn't yet fix the 8bpp sprite
07:52:43  <juzza1> i changed it to use the mask sprite, and also tried to use a downscaled (64x31) version of the mask sprite, no change
08:02:19  <juzza1> looks like the mask of the water tile is somehow affecting the mask of the water tile above it... as the water tiles with no flat water tile below them work ok
08:13:49  <juzza1> for example this situation the bottom water tile animates properly, but those two arent animated for the parts which overlap with the mask of the the tile below
08:13:50  <Webster> Title: imgur: the simple image sharer (at
08:16:20  *** Alberth has joined #openttdcoop.devzone
08:43:29  <planetmaker> o/
08:43:50  <V453000> ._.
08:51:09  *** Supercheese has quit IRC
08:59:11  <planetmaker> juzza1, besidest he offsets, I think there's an issue with your 32bpp sprite. It's not 100% transparent where it should be
09:00:02  <planetmaker> when I cut away everything non-tile in the 32bpp sprite it works for me
09:00:31  <Alberth> hi hi
09:05:05  <juzza1> planetmaker: thanks, that indeed fixed it!
09:06:17  <juzza1> will try to figure out what those pixels were
09:07:36  <planetmaker> Been there, done that. It happens when you use the eraser tool or a some paint tools instead of cutting away.
09:09:43  <V453000> :)
09:17:38  <juzza1> indeed the "transparent" pixels had an alpha value of one
09:30:45  <juzza1> also it seems that nml can also crop unneeded transparent pixels from 32 bit images, which is good
09:31:55  <planetmaker> yes, it does
09:33:22  <juzza1> nmlc help message could use some updating ;) wrt the -c parameter
09:36:04  <planetmaker> what should it say? skip the word 'blue'?
09:39:12  <juzza1> or "crop extraneous transparent blue from 8bpp realsprites, and fully transparent pixels from 32bpp realsprites"
09:39:58  <Alberth> the fun part is of course that 8bpp doesn't have transparency :)
09:40:40  <Alberth> in particular "blue transparent" is nice, how do you know it's blue when it's supposed to be transparent?  :p
09:41:20  <Alberth> (sorry, just posted a rant on git, still  in a somewhat bad mood)
09:42:31  <planetmaker> you can excuse yourself, if you give me the link to the rant :P
09:45:20  <Alberth>  apparently
09:45:22  <Webster> Title: Google Groups (at
09:45:49  <Alberth> ie "migrate to github" topic in that group
09:54:25  <planetmaker> hm, I wonder... whether rhodecode allows cross-server pull requests
09:54:46  <planetmaker> though in principle you can exercise pull requests always yourself by simply pulling from another repo and then merging
09:57:14  <planetmaker> hm, no. Also only rhodecode-rhodecode, if one uses its web interface
10:38:27  <Alberth> pull-requests are a bad feature :p
10:39:31  <planetmaker> :)
10:39:58  <planetmaker> I'm unsure about them tbh. I never really used any. But the problem with them is that one might want to make small amends here and there to the commits
10:40:06  <planetmaker> so... not sure
10:40:21  <Alberth> indeed, you need a simple way to twiddle them :)
10:40:38  <Alberth> git solution to that is rebase, of course
10:40:47  <planetmaker> they probably are better used with hg draft phase where you then can amend the single commits. And then merge the resultant queue to default
10:41:18  <Alberth> I think those are quite comparable
10:41:39  <Alberth> although I never experimented much with "rebase"-like techniques in hg
10:41:51  <planetmaker> depends on how you look at it. draft phase explicitly indicates 'mutable'. While this concept does not exist with git
10:42:16  <planetmaker> and it does not necessarily mean that you need rebase
10:42:22  <Alberth> isn't it just "not pushed" ?
10:43:07  <planetmaker> no. You can set a repository to "non-publishing". Then you can have commits with phase 'public' and phase 'draft'
10:43:17  <planetmaker> draft changesets are exchanged but still considered mutable
10:43:25  <planetmaker> only phase 'secret' is not exchanged
10:44:09  <planetmaker> such repo is more a working repo which allows to easily exchange changesets with collegues
10:44:20  <planetmaker> and to keep working on the queues while allowing updates which propagate
10:44:27  <Alberth> you see both hg and git struggle with the twiddling idea :)
10:44:31  <planetmaker> the old changesets will then be obsoleted (thus hidden)
10:44:39  <planetmaker> but the changesets remain
10:44:58  <Alberth> hg seems to move to a nicer solution
10:45:29  <planetmaker> I heard rumors that git will copy the phases idea :D
10:45:48  <Alberth> of course they do :)
10:46:02  <planetmaker> I think generally it's difficult to find a nice concept for WIP changesets
10:46:21  <planetmaker> the phases and obsolescence markers with hg go the right way, I think, too
10:46:31  <Alberth> yep, vcs is not designed for handling changes that change :)
10:46:32  <planetmaker> the handling of those is not yet finished with core hg
10:46:53  <planetmaker> but several facebook devs work on that
10:47:29  <planetmaker> (they basically hired 2/3 of the hg devs)
10:48:15  <planetmaker> but changes which change always require some form of rebasing. There's little way around that, I think
10:48:51  <planetmaker> as if you change a changeset in the middle, the children always need a rebaseing
10:48:51  <Alberth> and you probably even want that, you need to be able to go back to the previous state
10:49:29  <Alberth> yeah, but children are a bit too strict in accepting changes imho
10:49:39  <planetmaker> yeah. I'll be scared to *not* be able to go back. In case I mess up rebasing and only find out later or so
10:50:02  <planetmaker> what you mean with 'too strict in accepting changes'?
10:50:25  <Alberth> it's just silly that a patch queue dies because I added a line in a file that is later needed as context of a child patch
10:50:27  <planetmaker> you mean you need to rebase too often for too trivial changes├č
10:50:36  <planetmaker> *changes?
10:51:10  <Alberth> patch is designed to detect that  a source has changed since the patch was created
10:51:15  <planetmaker> ah. Well, that's a problem with MQ rather than with the newer concept of evolve. MQ handles the requires rebases / merges worse than it can be handled with full changesets
10:51:31  <planetmaker> s/requires/required/
10:51:43  <Alberth> which is good if you have unrelated modifications
10:52:04  <Alberth> but with a MQ you know exactly what patches come nexr
10:52:07  <Alberth> *next
10:52:50  <planetmaker> with changesets you do that, too. Just look at hg log :)
10:53:43  <Alberth> yep, if you stay in the same repository you can figure it all out
10:54:00  <planetmaker> from what I gathered in #mercurial, what is the 'problem' with MQ: it requires some sort of break in the concept in the thinking
10:54:04  <Alberth> although there is of course that problem that at some point you do break a change
10:54:37  <planetmaker> while the goal is to handle everything draft just like normal changesets. So you don't need to think about any difference in handling. Just that you can freely rebase or amend those changesets
10:55:06  <planetmaker> but of course... it doesn't change the fact, that some alterations of history necessarily break descendent changesets
10:55:20  <planetmaker> s/descendent/child/
10:55:26  * Alberth nods
10:55:57  <planetmaker> it's an inherent problem. Not all changes are compatible with eachother (without thinking)
10:56:13  <Alberth> with patch queues I fully expect that
10:57:02  <Alberth> even patch queues are not flexible enough in my experience
10:57:29  <Alberth> at work I had a queue of 12 patches or so, which I could only test after applying all of them
10:57:46  <Alberth> obviously, you break things at first, so you make changes
10:57:53  <planetmaker> sure
10:58:10  <Alberth> but those changes belong in earlier patches, often in several different ones
10:58:16  <planetmaker> yup
10:58:26  <Alberth> getting them there is a big job in itself
10:58:37  <planetmaker> yes, that's a bit of a pita
10:59:20  <Alberth> hmm, maybe mq should work the other way around, you push changes from the top down to the earlier patches
10:59:23  <planetmaker> I also often write a patch queue. Then I fiddle around and then are left with a 'last' patch which fixes everything and needs be distributed into various earlier patches (and completely be erased itself)
11:00:20  <planetmaker> what one can do in that case is: hg uncommit FILENAME
11:00:34  <planetmaker> hg record (to possibly re-add some hunks)
11:00:53  <planetmaker> hg up -rTARGETCHANGESET
11:00:55  <planetmaker> hg amend
11:01:00  <planetmaker> hg evolve -a
11:01:18  <planetmaker> and rinse and repeat for each patch in the queue until the last changeset is dissolved and distributed
11:01:23  <Alberth> right, "hg uncommit -h" fails :)
11:01:34  <planetmaker> yeah, it's part of the evolve / mutable history extension
11:02:55  <planetmaker> do you use the record extension, though?
11:03:12  <planetmaker> (or at least know)
11:05:24  <Alberth> I have heard of it :)
11:06:40  <Alberth> but usually, my coding problem is too complicated to be messing with vcs things, for me at least
11:07:26  <planetmaker> yeah. That's why I have a messy last commit in patch queues usually. Which then needs careful analysis and putting into the previous changesets. Which is tedious
11:07:47  <planetmaker> vcs indeed easily can distract from the real work
11:09:05  <planetmaker> and it's supposed to be a tool, not a purpose in itself
11:10:14  <planetmaker> thus it also happens half the time, that I get myself a summary patch of the whole queue in a file. And based on that I write it anew in separate patches to show for review (and final commit)
11:11:30  <Alberth>  I often make a fresh clone, and open gvimdiff for every file that I touch between the "old" and the "fresh" repo
11:11:55  <Alberth> after copying changes, you can qnew in the fresh one, and qpush in the old one
11:12:45  <Alberth> or do qpush -a and cherry-pick changes, of course
11:16:01  <planetmaker> similar workflow :)
11:16:37  <Alberth> indeed
11:17:00  <Alberth> working on anything?
11:17:54  <planetmaker> just started the centosVM to hopefully recreate windows building for VM now on the correct distro as CF has
11:18:15  <Alberth> always useful :)
11:18:28  <planetmaker> didn't have time as much as I hoped before
11:18:58  <Alberth> build stuff always takes ages to get right, so many bits that can go wrong
11:19:45  <Alberth> testing is always very slow due to long execution times
11:26:50  *** frosch123 has joined #openttdcoop.devzone
11:29:51  <planetmaker> \o
11:30:24  <Alberth> o/
11:30:52  <V453000> omg mutated horned ponies
12:20:19  *** yorick has joined #openttdcoop.devzone
12:45:15  <DevZone> Project opengfx-mars build #120-push: SUCCESS in 2 min 31 sec:
12:45:26  <DevZone> Project Townnames - German build #79-push: SUCCESS in 10 sec:
12:45:27  <DevZone> Project NML - NewGRF Meta Language build #335-push: SUCCESS in 3 min 30 sec:
13:17:19  *** oskari89 has joined #openttdcoop.devzone
13:29:22  *** gelignite has joined #openttdcoop.devzone
13:35:00  <planetmaker> hm... drat. I fail to re-create the python setup I managed to create on my machine which builds nml-py3
13:35:06  <planetmaker> even on my machine I fail to do so :P
13:36:22  <Alberth> :(
13:57:56  <planetmaker> I've the tar of the .wine dir of both, DevZone CF with py27. As well mine with py33, though... but if I copy my python33 to DevZone it crashes quite soundly...
13:59:46  <Alberth> it doesn't say anything?
14:00:18  <Alberth> python33 exists at centos?
14:00:27  <Alberth> sounds a bit too newish
14:00:48  <planetmaker> python33 does not need to exist there. It's the wine thingy
14:00:52  <planetmaker> so it only needs wine
14:00:56  <planetmaker> and the install therein
14:01:02  <Alberth> oh, right
14:02:21  <planetmaker> o-O. My local .wine dir is 290MB as .tgz
14:04:03  <Alberth> you may be missing a few bits then :)
14:21:57  <planetmaker> hm... probably there's for everything exactly one way. While they seem equivalent they are somehow subtly not
14:24:13  <planetmaker> oh, hilarious
14:24:49  <planetmaker> first install easy_install via linux command line: wine "C:\Python32\Pythonw.exe"
14:25:03  <planetmaker> then enter windows cmd. easy_install.exe pip
14:25:08  <planetmaker> pip install pillow
14:25:11  <planetmaker> pip install pillow
14:25:51  <planetmaker> beware, do not do differently. do things in windows as here, not calling it from linux cmd via wine "C:\Python32\Scripts\pip.exe" install pillow
14:25:59  <planetmaker> or similar. It makes a frigging difference...
14:27:04  <planetmaker> and yes, it needs easy_install in order to be able to install pip. Or so it seems :D
14:27:27  <planetmaker> but it needs pip to get the uncompressed modules installed
14:33:31  <planetmaker> haha. And now there's no pre-compiled windows binary for cx_freeze. And I definitely won't install a compiler within wine :)
15:02:43  * Alberth would expect \ in linux comandlines
15:10:12  <planetmaker> hm, maybe that's what made it fail
15:10:47  <planetmaker> however, in wine cmd it's not needed, so seems to work now somewhat.
15:10:56  <planetmaker> let's see how a copy of the .wine dir performs on CF
15:11:25  <planetmaker> uploading 150MB .xz file now :P
15:12:25  <planetmaker> xz really has a nice compression ratio... >~ 50% here
16:05:33  <DevZone> Project opengfx-mars build #121-push: SUCCESS in 2 min 14 sec:
16:05:46  <DevZone> Project Townnames - German build #80-push: SUCCESS in 12 sec:
16:05:47  <DevZone> Project NML - NewGRF Meta Language build #336-push: SUCCESS in 3 min 14 sec:
16:06:50  <planetmaker> right... 2.7. still works
16:07:18  <Alberth> phew :p
16:16:09  <planetmaker> and py3 fails on missing linux python modules :P
16:17:16  <planetmaker> and "phew" is justified if you consider the merging method: take wine-py2.7 and the copy wine-py3.3 onto it, overwriting everything where things are different ;)
16:20:58  <Alberth> wow :)
16:22:03  <DevZone> Project Japanese Buildings build #215-nightlies: SUCCESS in 18 sec:
16:34:12  <DevZone> Project Finnish Rail Infrastructure - Rails build #329-nightlies: SUCCESS in 8 min 27 sec:
16:41:22  <DevZone> Project road-hog build #215-nightlies: SUCCESS in 36 sec:
16:42:39  <planetmaker> right... I guess I'll create a fork repo for testing
16:45:57  <DevZone> Project nml-py3 build #1: FAILURE in 2.3 sec:
16:46:03  <planetmaker> aha :P
16:48:28  <DevZone> Project Iron Horse build #894-nightlies: SUCCESS in 1 min 31 sec:
16:49:10  <DevZone> Project Dutch Trainset build #176-push: SUCCESS in 1 min 32 sec:
16:49:38  <DevZone> Project ecs build #36-push: SUCCESS in 27 sec:
16:49:40  <DevZone> Project nml-py3 build #2: STILL FAILING in 2.3 sec:
16:50:00  <DevZone> Project 2ccts build #130-push: SUCCESS in 1 min 31 sec:
16:53:01  <DevZone> Project nml-py3 build #3: STILL FAILING in 2.2 sec:
16:56:27  <DevZone> Project nml-py3 build #4: STILL FAILING in 2.2 sec:
17:08:11  <DevZone> Project nml-py3 build #5: STILL FAILING in 2.4 sec:
17:09:18  <DevZone> Yippee, build fixed!
17:09:19  <DevZone> Project nml-py3 build #6-push: FIXED in 18 sec:
17:10:51  <planetmaker> hm...
17:24:21  <DevZone> Project NML - NewGRF Meta Language build #337-push: FAILURE in 6.4 sec:
17:32:04  <DevZone> Project opengfx-mars build #122-push: SUCCESS in 2 min 19 sec:
17:32:12  <DevZone> Project Townnames - German build #81-push: SUCCESS in 7.7 sec:
17:32:13  <DevZone> Yippee, build fixed!
17:32:14  <DevZone> Project NML - NewGRF Meta Language build #338-push: FIXED in 3 min 12 sec:
17:34:08  <DevZone> Project NML - NewGRF Meta Language build #339-push: FAILURE in 5.3 sec:
17:37:44  <DevZone> Project opengfx-mars build #123-push: SUCCESS in 2 min 13 sec:
17:37:52  <DevZone> Project Townnames - German build #82-push: SUCCESS in 7.8 sec:
17:37:54  <DevZone> Yippee, build fixed!
17:37:54  <DevZone> Project NML - NewGRF Meta Language build #340-push: FIXED in 3 min 9 sec:
17:59:30  <DevZone> Project nml-py3 build #7-push: FAILURE in 3.4 sec:
18:00:39  <planetmaker> Alberth, ^ can you make sense of that error? I don't get that locally...
18:02:52  <planetmaker> (the code is at ssh://
18:24:43  <Alberth> planetmaker:  one of the imported python files is shorter than normal?
18:25:36  <planetmaker> hm, not that I know... I would need to verify
18:26:31  <Alberth> I don't get it locally either
18:26:59  <planetmaker> hm, k
18:27:12  <planetmaker> thanks for testing
18:28:03  <Alberth> or perhaps the sound file is faulty, but I wouldn't expect that to happen on import
18:29:01  <Alberth> if you split the import in more lines, you may be able to get more precise information
18:29:11  <Alberth> as in which import fails exactly
18:30:12  <Alberth> but even then, if import is broken, you'd expect the first run to fail too, or do you make things in parallel?
18:33:16  <Alberth> planetmaker: hmm, maybe that's the trick indeed
18:33:32  <DevZone> Project nml-py3 build #8-push: STILL FAILING in 3.5 sec:
18:33:33  <Alberth> writes a parsetab.tbl file or so
18:33:51  <Alberth> which a second process may read before it is written entirely?
18:34:06  <planetmaker> hm, maybe
18:34:31  <planetmaker> funnily enough, when I ssh to the CF, and call that build script from console. Then it works, too...
18:34:44  <planetmaker> so it's something more elusive even
18:35:01  <Alberth> it's all about timing in that case
18:36:08  <Alberth>    perhaps try that patch?
18:37:01  <Alberth>  <-- that issue
18:40:10  <planetmaker> let's see. It's a test fork :)
18:40:38  <DevZone> Yippee, build fixed!
18:40:39  <DevZone> Project nml-py3 build #9-push: FIXED in 33 sec:
18:40:50  <planetmaker> :-O :-)
18:41:22  <planetmaker> so... will you also push it to the official repo?
18:42:03  <planetmaker> (or shall I?)
18:42:50  <Alberth> sure, one moment
18:46:37  <Alberth> pushed
18:49:29  <DevZone> Project opengfx-mars build #124-push: SUCCESS in 2 min 16 sec:
18:49:37  <DevZone> Project Townnames - German build #83-push: SUCCESS in 8.3 sec:
18:49:38  <DevZone> Project NML - NewGRF Meta Language build #341-push: SUCCESS in 3 min 10 sec:
18:49:41  <DevZone> Project nml-py3 build #10-push: FAILURE in 3.5 sec:
18:50:36  <planetmaker> eh
18:50:44  <planetmaker> can't say I get that now
18:51:56  <DevZone> Project nml-py3 build #11-push: STILL FAILING in 3.5 sec:
18:53:21  <Alberth> I wonder whether this can happen with generated python files too
18:53:53  <planetmaker> hm....
18:53:56  <Alberth> or, did you run out of disk space or disk quota ?
18:54:03  <DevZone> Yippee, build fixed!
18:54:04  <DevZone> Project nml-py3 build #12-push: FIXED in 32 sec:
18:54:07  <planetmaker> maybe not that
18:54:24  <planetmaker> but my terminal was still in the workspace dir. But the workspace dir is supposed to be deleted and re-created
18:54:52  <planetmaker> let's test that
18:55:22  <DevZone> Project nml-py3 build #13-push: SUCCESS in 33 sec:
18:55:54  <planetmaker> weired
18:56:04  <DevZone> Project nml-py3 build #14-push: SUCCESS in 32 sec:
18:56:52  <DevZone> Project nml-py3 build #15-push: SUCCESS in 32 sec:
19:00:27  <DevZone> Project nml-py3 build #16-push: FAILURE in 1 min 1 sec:
19:02:39  <DevZone> Yippee, build fixed!
19:02:39  <DevZone> Project nml-py3 build #17-push: FIXED in 1 min 5 sec:
19:05:21  <DevZone> Project nml-py3 build #18-push: SUCCESS in 47 sec:
19:13:59  <planetmaker> hm... ogfx-industries.grf seems to work, both ways, generated with the linux nmlc as well as the windows nmlc
19:14:09  <planetmaker> but the md5sums of the resulting grf is different :(
19:14:21  <planetmaker> but the used python version is different, too
19:19:22  <Alberth> also, it uses sets, and dictionaries, which are not fixed in order
19:19:33  <Alberth> unless someone fixed that in the past in nml
19:19:47  <planetmaker> so, little chance for identical output?
19:19:59  *** andythenorth has joined #openttdcoop.devzone
19:20:05  <Alberth> I think so
19:20:18  <planetmaker> then I'll not worry about it
19:20:20  <planetmaker> for now
19:20:24  <Alberth> you could run a grfcodec over it and compare differences
19:20:57  <planetmaker> yeah, I should do that, I guess
19:21:16  <Alberth> allocated numbers are hopefully the only difference
19:21:18  *** Supercheese has joined #openttdcoop.devzone
19:21:39  <Alberth> we could look into making nml provide more fixed order in the output
19:26:19  <planetmaker> <-- you're right though
19:26:56  <planetmaker> in the medium run we possibly could look at making it depend less on implementation
19:27:16  <planetmaker> But I'm not 100% sure how important that is... comparing different builds is always tricky with nml
19:27:19  *** ODM has joined #openttdcoop.devzone
19:28:39  <Alberth> :o string tables?
19:29:07  <planetmaker> seems so
19:33:55  <planetmaker> anyhow... except this thing... it looks like nml-py3 works. Surprisingly, but works
19:34:23  <Alberth> \o/
19:34:25  <planetmaker> the windows nmlc will only be able to read png images. No jpeg or other fancy formats, but that's acceptable, I think
19:34:31  <andythenorth> :)
19:34:43  <planetmaker> or something to worry about later, re-compiling pil with jpeg support when absolutely needed
19:34:50  <andythenorth> our big work app is still stuck on python 2.4 :P
19:34:51  <Alberth> jpeg is not useful anyway
19:34:51  <planetmaker> s/pil/pillow
19:35:00  <Supercheese> .jpeg is of the devil
19:35:14  * Supercheese crosses himself
19:35:35  <planetmaker> it's useful for photos. But not in this area
19:36:39  <planetmaker> so, Alberth, should we push the changes to the main NML repo?
19:36:44  <planetmaker> s/we/I/?
19:37:01  <Alberth> fine by me
19:37:19  <planetmaker> or run some timing tests first? :)
19:37:46  <Alberth> you make a branch for 2.7?
19:38:03  <planetmaker> I would/will do that when we have anything to backport, yes
19:38:28  <planetmaker> thus we'll be heading towards 0.4.0 then and the new branch would be 0.3
19:38:56  <Alberth> do we have any idea on slow acceptable nml compile speed is?
19:39:39  <planetmaker> different people have different thresholds, I guess
19:40:27  <planetmaker> ogfx-industries is 5.2s vs 4.5s (real time)
19:40:32  <planetmaker> one test
19:42:23  <planetmaker> firs is 1m:25.851 vs. 1m17.160s (real time, one run)
19:44:22  <Alberth> not too bad, I guess
19:44:31  <planetmaker> ho... one missing conversion?
19:45:12  <planetmaker> hm... I recall something like that already...
19:45:28  <Alberth> I changed some palette stuff indeed
19:46:49  <Alberth> but it is totally possible I missed one or more
19:47:24  <planetmaker> that was line 548. This is 200 lines further down
19:48:16  <planetmaker> c92497a4508adb5dd54c2668ddd0e7feec93bba3 is previous
19:48:30  <planetmaker> (my numeric revisions will be off quite a bit)
19:49:19  <planetmaker> I guess I can add a similar fix to the py2to3 conversion patch
19:52:52  <Alberth> translate_d2w = bytearray(v for v in palmap_d2w)  <-- that's what I have in my py3 branch
19:52:52  <Alberth> translate_d2w = ''.join(chr(v) for v in palmap_d2w) <-- that's from py3nml
19:53:52  <planetmaker> aye
20:02:24  <planetmaker> 3.384s vs. 3.170s for ogfxe_extra.grf
20:03:42  <Alberth> quite comparable imho
20:03:45  <planetmaker> win for py3 for big 32bpp: 4.956s vs. 7.220s for pota-ghat
20:03:52  <planetmaker> yes
20:04:09  <planetmaker> using cached times from repeated builds
20:06:05  <planetmaker> possibly the py3-pillow is more optimized
20:20:37  *** ODM has quit IRC
20:21:25  <planetmaker> hg ci -m "-Change: Convert from Python2 to Python 3.2+ (changes to .devzone /  by planetmaker)" -u "Alberth <>" <-- fine with that for a squashed commit?
20:21:39  <planetmaker> I see little way to split it
20:21:52  <Alberth> you cannot, imo
20:22:02  <Alberth> +1
20:22:40  <DevZone> Project NML - NewGRF Meta Language build #342-push: FAILURE in 5.9 sec:
20:23:56  <DevZone> Project NML - NewGRF Meta Language build #343-push: STILL FAILING in 5.3 sec:
20:24:06  <planetmaker> hm
20:26:11  <DevZone> Project NML - NewGRF Meta Language build #344-push: STILL FAILING in 5.3 sec:
20:27:55  *** LSky` has quit IRC
20:29:29  <DevZone> Project NML - NewGRF Meta Language build #345-push: STILL FAILING in 5.6 sec:
20:30:26  <Alberth> is it reproducable locally?
20:30:33  <planetmaker> no
20:30:47  <planetmaker> also not when I run the build script on the server. Same thing really as before...
20:31:04  <planetmaker> it seems to be another issue than
20:31:18  <Alberth> yeah, we eliminated that one :p
20:33:44  <Alberth> planetmaker:   ?
20:33:45  <Webster> Title: Comment #5 : Bug #1029683 : Bugs : Ubuntu (at
20:34:52  <planetmaker> Alberth, but why does it happen sometimes but not always?
20:35:03  <planetmaker> I expect that bug to be deterministic
20:35:40  <Alberth> your guess is as good as mine :)
20:35:51  <planetmaker> it then should also occur when I manually run the commands instead of in the script?
20:36:45  <planetmaker> hm... I forced -j1 on regression test now. That currently builds successful
20:37:03  <planetmaker> so there is something nasty racy on parallel usages of nmlc
20:37:19  <DevZone> Project opengfx-mars build #125-push: SUCCESS in 2 min 18 sec:
20:37:26  <planetmaker> but good enough fix for now. Just minimal longer build
20:37:27  <DevZone> Project Townnames - German build #84-push: SUCCESS in 7.9 sec:
20:37:28  <DevZone> Yippee, build fixed!
20:37:29  <DevZone> Project NML - NewGRF Meta Language build #346-push: FIXED in 3 min 32 sec:
20:39:23  <planetmaker> I guess we need to announce this fundamental change in requirements
20:39:52  <Alberth> seems useful :)
20:40:25  <Alberth> although people will generaly run just one nml
20:41:20  <Alberth> file system is at NFS?
20:41:41  <Alberth> perhaps something with locking?
20:42:53  <Alberth> but you'd again also get those problems if you run make by hand :(
20:44:01  *** andythenorth has left #openttdcoop.devzone
20:47:29  <planetmaker>
20:47:30  <Webster> Title: Transport Tycoon Forums Login (at
20:47:54  <planetmaker> the file system for the working dir is not on NFS, that's local to the build VM
20:49:33  *** oskari89 has quit IRC
20:50:39  <planetmaker> announcement ok with you?
20:50:47  <planetmaker> anything missing or too much?
20:59:29  <Alberth> that url is empty for me
21:00:44  <planetmaker> hm, can you reload?
21:01:16  <Alberth>   this one worked
21:01:17  <Webster> Title: Transport Tycoon Forums View topic - NML - a Newgrf Meta Language (at
21:01:21  <Alberth> seems ok to me
21:03:42  <Alberth> gn
21:03:58  *** Alberth has left #openttdcoop.devzone
21:52:48  *** frosch123 has quit IRC
22:58:32  *** yorick has quit IRC
23:50:53  *** gelignite has quit IRC

Powered by YARRSTE version: svn-trunk